需求工程——软件建模与分析阅读笔记05

人月

1. 用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的；
2. 当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。无论哪位母亲，孕育一个生命都需要10个月；
3. 对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量；
4. 沟通所增加的负担由两个部分组成：培训和相互的交流；
5. 所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用。从而，添加更多的人手，实际上是延长了而不是缩短了时间进度；

系统测试

1. 由于我们的乐观主义，通常实际出现的缺陷数量比预料的要多得多。因此，系统测试进度的安排常常是编程中最不合理的部分；
2. 多年经验的软件任务的进度安排：1/3计划，1/6编码，1/4构件测试，1/4系统测试；
3. 大多数项目的测试实际上是花费了进度中一半的时间。特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难；

空泛的估算

1. 某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。就像在两分钟内完成一个煎蛋，看上去可能进行得非常好，但当它无法在两分钟内完成时，顾客只能选择等待或者生吃煎蛋；
2. 项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多；
3. 重复产生的进度灾难。在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表；
4. 向进度落后的项目中增加人手，只会使进度更加落后；
5. 项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量；