人月神话（附国内实战体验精华册32周年中文纪念版）

作者简介

Freder ick P.Brooks，Jr.曾荣获美国计算机领域最具声望的图灵奖（A.M.TURINGAWARD）桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。 　　Brooks博士是北卡罗莱纳大学KENAN-FLAGLER商学院的计算机科学教授。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理，以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献，他与BobEvarls和Erich BIocll在1985年荣获了美国国家技术奖（NationalMedal of TecPlnoIogy）。Brooks博士早期曾担任IBM公司stretcPl和Harvest计算机的体系结构设计师。 　　Brooks博士创立了北卡罗莱纳大学的计算机科学系，并在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。Brooks博士目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。

内容简介

是什么。项目工作手册不是独立的一篇文档，它是对项目必须产出的一 系列文档进行组织的一种结构。 项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明 、接口说明、技术标准、内部说明和管理备忘录。 为什么。技术说明几乎是必不可少的。如果某人就硬件或软件的某一部 分，去查看一系列相关的用户手册。他发现的不仅仅是思路，而且还有能追 溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设 计。对于技术作者而言，文章的剪裁粘贴与钢笔一样有用。 基于上述理由，再加上“未来产品”的高质量手册将诞生于“今天产品 ”的备忘录，所以正确的文档结构非常重要。事先将项目工作手册设计好， 能保证文档的结构本身是规范的，而不是杂乱无章的。另外，有了文档结构 ，后来书写的文字就可以放置在合适的章节中。 使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了 限制信息，而是确保信息能到达所有需要它的人的手中。 项目手册的第一步是对所有的备忘录编号，从而每个工作人员可以通过 标题列表来检索是否有他所需要的信息。还有一种更好的组织方法，就是使 用树状的索引结构。而且如果需要的话，可以使用树结构中的子树来维护发 布列表。 处理机制。同许多其他的软件管理问题一样，随着项目规模的扩大，技 术备忘录的问题以非线性趋势增长。10人的项目，文档仅仅通过简单的编号 就可以了。100人的项目，若干个线性索引常常可以满足要求。1000人的项 目，人员无可避免地散布在多个地点，对结构化工作手册的需要和手册规模 上的要求都增加了许多。那么，用什么样的机制来处理呢? 我认为OS／360项目做得非常好。O．S．Locken强烈要求制定结构良好 的工作手册，他本人在他的前一个项目14lO一70lO操作系统中，看到了工作 手册的效果。 我们很快决定了每一个编程人员应该了解所有的材料，即在每问办公室 中应保留一份工作手册的拷贝。 工作手册的实时更新是非常关键的。工作手册必须是最新的，如果每次 变更都要重新打印所有的文档，那将很难做到。不过，如果采用活页夹的方 式，则仅需更换变更页。我们当时拥有计算机文本编辑系统，它对实时维护 有不可思议的帮助。编辑、排版、打印的工作直接在计算机和打印机上完成 ，周转时间不到一天。但即便如此，所有接收的人员还是会面临消化理解的 问题。当他第一次收到更改页时，他需要知道，“修改了什么?”迟些时候 ，当他就问题进行咨询时，他需要知道，“现在的定义是什么?” 后一种需要可以通过不问断的文档维护来解决。文档变更的强调有若干 个步骤。首先，必须在页面上标记发生改变的文本，例如，使用页边上的竖 线标记每行变化的文字；第二，分发的变更页附带简短、独立的总结性文字 ，对变更的重要性以及批注进行记录。 这种机制在我们项目中碰到别的问题之前，稳定运行了6个月。工作手 册大约厚达5英尺!如果将我们在曼哈顿Time—Life大厦办公室里所使用的 100份手册叠在一起，它们比这座大厦还要高。另外，每天分发的变更页大 约有2英寸厚，归入档案的页数大概有150页。工作手册的日常维护工作占据 了每个工作日的大量时间。 这个时候，我们换用了微缩胶片，在为每个办公室配备了微缩胶片阅读 机之后，节约了大量金钱，工作手册的体积减少了18倍。更重要的是，对数 百页更新工作的帮助——微缩胶片大量地减轻了归档问题。 微缩胶片有它的缺点。从管理的角度而言，笨拙的文字归档工作确保了 所有变更都会被阅读，这正是工作手册要达到的目的。微缩胶片使工作手册 的维护工作变得过于简单，除非列举变化的文字说明和变更胶片一起分发。 另外，读者不能在微缩胶片上做强调、标记和批注。对作者来说，采用 文档方式与读者沟通更加有效；对读者来说，文档也更加方便使用。 总之，我觉得微缩胶片是非常好的一种方法。对于大型项目，我建议把 它作为文字工作手册的补充。 现在如何入手?在当今很多可以应用的技术中，我认为一种选择是采用 可以直接访问的文件。在文件中，记录修订日期记录和标记变更标识条。每 个用户可以从一个显示终端(打印机太慢了)来查阅。每日维护的变更小结以 “后进先出”(LIFO)的方式保存，在一个固定的地方提供访问。编程人员可 以每天阅读，但如果错过了一天，他只需在第二天多花一些时间。在他查看 小结的同时，他可以停下来，去查询变更的文字。 注意工作手册本身没有发生变化。它还是所有项目文档的集合，根据某 种经过细致设计的规则组织在一起。唯一发生改变的地方是分发机制和查询 方法。斯坦福研究院的D．C．Engelbart和同事开发了一套系统，并用它在 ARPA网络项目中建立和维护文档。 Carnegie—MelIon大学的D．L．Parnas提出了更彻底的解决方法。他认 为，当编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工 作效率最高。这种方法的先决条件是精确和完整地定义所有接口。这的确是 一个彻底的解决方法。如果能处理得好，的确是能解决很多“灾难”。一个 好的信息系统不但能暴露接口错误，还能有助于改正错误。 P76-80