为什么不能从编码估计外推整个项目？
- 编码占比小: 编码大约只占问题的六分之一, 对它的估计错误会被放大成荒谬结果;
- 小项目数据不可外推: 构建独立小型程序的数据不适用于编程系统产品;
- 反例: Sackman 等人测得规模 3200 指令的程序约需 178 小时, 外推得每年 35,800 语句; 规模减半的程序只花四分之一时间, 外推得每年 80,000 语句;
- 类比: 就像把 100 码短跑成绩外推, 得出人类 3 分钟跑完 1 英里;
工作量随程序规模如何增长？
- 幂函数: 工作量 = (常数) × (指令数量)^1.5;
- 数据来源: Nanus 和 Farr 在 System Development Corporation 的研究给出指数 1.5, Weinwurm 的 SDC 报告指数接近 1.5;
- 20 年后的修正: Boehm 的数据不完全一致, 指数在 1.05 到 1.2 之间变化;
- 用途: 用于提醒"规模翻倍不等于工作量翻倍", 而是超线性增长;
现实中程序员的有效工作时间有多少？
- Portman 的观察: ICL 软件部门的队伍落后约 1/2, 每项工作花费约为估计的两倍;
- 原因: 日志显示团队仅用 50% 的工作周进行实际的编程和调试;
- 其余时间: 机器当机、高优先级琐碎工作、会议、文字工作、公司业务、疾病、事假;
- 结论: 项目估算对"每人年的技术工作时间"做了不现实的假设;
- 旁证: 一份未发表研究指出程序员实际生产时间占 27%;
各机构测得的生产率数据说明了什么？
- Aron 的数据（按模块间交互程度划分, 仅设计与编程）:
| 交互程度 | 生产率 |
|---|
| 非常少 | 10,000 指令/人年 |
| 少量 | 5,000 指令/人年 |
| 较多 | 1,500 指令/人年 |
- Harr 的 Bell 实验室数据（含编程、构件测试和系统测试）: 控制程序约 600 指令/人年, 语言翻译约 2200 指令/人年;
- OS/360 数据: 控制程序组 600-800 指令/人年, 语言翻译组 2000-3000 指令/人年;
- 共同结论: 生产率随任务复杂度和困难程度显著变化;
- 复杂度经验比例: 编译器的复杂度是批处理程序的三倍, 操作系统的复杂度是编译器的三倍;
高级语言能带来多少提升？
- Corbato 的 MULTICS 数据: 平均 1200 行经调试的 PL/I 语句/人年;
- 换算关系: 每条语句约对应手写代码的 3 至 5 个指令;
- 两个结论:
- 在基本语句级别, 生产率看上去是个常数;
- 使用适当的高级语言, 编程生产率可以提高 5 倍;
估算问题有哪两条解决路径？
- 数据路径: 开发并推行生产率图表、缺陷率、估算规则, 让整个组织共享这些数据;
- 意志路径: 在可靠数据出现之前, 项目经理挺直腰杆坚持自己的估计, 确信经验和直觉强于从期望派生的结果;
- 两者关系: 数据是长期解, 坚持是短期自保, 缺一不可;