人月神话（四）削足适履、提纲挈领、未雨绸缪

第8章 胸有成竹

系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？

① 先前，我推荐了用于计划进度、编码、构件测试和系统测试的比率。

(1) 需要指出的是，仅仅通过对编码部分的估计，然后应用上述比率，是无法得到对整个任务的估计的。

(2) 必须声明的是，构建独立小型程序的数据不适用于编程系统产品。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。

② 在将上述观点抛开之前，尽管不是为了进行严格的比较，即使在不考虑相互交流沟通，开发人员仅仅回顾自己以前工作的情况下， 这些数字仍然显示出工作量是规模的幂函数。

Part 1 Portman的数据

项目估算对每个人年的技术工作时间数量做出了不现实的假设

日志显示事实上他的团队仅用了50%的工作周，来进行实际的编程和调试，估算上的失误完全可以由该情况来解释。其余的时间包括机器的当机时间、 高优先级的无关琐碎工作、会议、文字工作、公司业务、疾病、事假等等。

Part 2 Aron的数据

大型项目（简要地说，大型意味着程序员的数目超过 25 人，将近 30,000 行的指令）

Part 3 Harr的数据

Part 4 OS/360的数据

① 控制程序组的经验而言，生产率的范围大约是 600～800（经过调试的指令）/人年。语言翻译小组所达到的生产率是2000～3000（经过调试的指令）/人年。这包括了小组的计划、代码构件测试、系统测试和一些支持性活动。

② 生产率会根据任务本身复杂度和困难程度表现出显著差异。 在复杂程度估计这片“沼泽” 上的指导原则是： 编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍

Part 5 Corbato的数据

① 高级语言系统编程，平均生产率是 1200 行经调试的 PL/I 语句（大约在 1 和 2 百万指令之间）/人年。

② 意味着两个重要的结论 ：

（1）对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。

（2）使用适当的高级语言，编程的生产率可以提高 5 倍。

作者总结

8.1 仅仅通过对编码部分的估计， 然后乘以任务其他部分的相对系数， 是无法得出对整项工作的精确估计的。

8.2 构建独立小型程序的数据不适用于编程系统项目。

8.3 程序开发呈程序规模的指数增长。