人月神话（13,14,15）整体部分 祸起萧墙与另外一面

人月神话（13,14,15）整体部分 祸起萧墙与另外一面

思维导图

整体部分

剔除bug的设计

关键的工作是产品定义。许许多多的失败完全是因为那些产品未精确定义的地方而导致的

细致的功能定义，仔细的规格说明、规范化的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量

测试规格说明

在编写任何代码之前，规格说明必须提交给外部测试小组，以详细地检查说明的完整性和明确性

自上而下的设计

作用：尽管他的理念是为程序设计，也完全适用于复杂的系统的软件开发设计。他将系统开发划分为体系结构设计，设计实现和物理编码实现，每个步骤都可以使用自上而下的方法实现

精化步骤

• 他通过比较粗略的任务定义和大概的解决方案得到主要结果
• 对该定义和方案进行细致的检查，以判断结果与预期之间的差距
• 将上诉步骤的解决方案在更细的步骤中进行分解，每项任务定义的精华变成了解决方案中算法的精化，还可能伴随着数据表达方式的精化

如何避免bug

• 清晰的结构和表达方式更容易对需求和模块功能进行精确地描述
• 模块分割和模块独立性避免了系统级的bug
• 细节的抑制是结构上的缺陷更加容易识别
• 设计在每个精化步骤上都是可以测试的，所以测试可以尽早开始，并且每个步骤的重点可以放在合适的级别上

结构化编程

• 设计程序的控制结构基本上仅包含语句形式的循环结构和条件判断结构
• 通过GO TO 不加限制的分支跳转，会产生导致自身逻辑错误的结构
• 多条件的CASE语句，和异常跳转都是十分实用的控制结构

关键的地方和构建无bug程序的核心，是把系统的结构作为控制结构来考虑，而不是独立的分支语句

构建单元测试

本机调试

• 在一次机器交互会话中尽可能多地包含实验性操作
• 程序员仔细地设计他的调试过程——计划停止的地点，检查内存的位置，需要检查的东西以及如果没有预期结果时的对策
• 把程序划分成测试阶段和对执行终止位置进行计划

内存转存
当出现bug时候，保存下当前程序的内存信息是十分必要的

快照
允许将快照插入程序，无需重新汇编和编译，它是快照技术方向的终极产品

交互式调试
保证机器的使用率，由于调度监控程序和相关语言解释编译器的出现而带来便利，具有和本机调试一样的操作实时性

测试用例

系统集成调试

软件开发过程中出乎意料的困难部分是系统集成测试

• 系统调试花费的时间会比预料的更长
• 的困难证明了需要一种完备系统化和可计划的方法

具体实现可计划的方法

• 使用经过调试的构建单元
• 搭建充分的测试平台
• 控制变更
• 一次添加一个构建
• 阶段化，定期变更

祸起萧墙

项目进度经常以一种难以察觉，但残酷无情的方式慢慢落后

里程碑还是沉重的负担

制定进度表。进度表上的每一件事都称为“里程碑”，他们都有一个日期。选择日期是一个估计技术的问题

针对大型开发项目中的估计行为

• 如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订。这样，随着时间的临近，无论最后情况会变得如何糟糕，它都不会有太大的变化
• 活动期间，对时间长短的过高估计会随着活动的进行持续而下降
• 过低估计在活动中不会有太大变化，一直到计划的结束日期前大约三周左右

其他的部分反正会落后

• 进取是很多优秀队员和团队不可缺少的心理素质
• 必须关心每一天的滞后，他们是大灾祸的基本组成元素
• PERT的准备工作是PERT图使用中最有价值的部分。它包括整个网状结构展开，任务之间依赖关系的识别和各个任务链的估计，这些都要求在项目早期进行非常专业的计划

地毯的下面

一线经理担心如果回报了问题，老板会采取行动，这些行动会取代经理的作用，降低自己的威信，搞乱其他计划。所以，只要项目经理认为自己可以独立解决问题，他就不会告诉老板

掀开毯子的两种方式

• 一种是减少角色冲突和估计状态共享
• 另一种是猛然拉开地毯

减少角色的冲突

• 首先老板必须却别行动信息和状态信息。他必须规范自己，不对项目经理可以解决的问题作出反应，并且决不在检查转台报告的时候作出安排
• 当项目经理了解到老板收到报告之后不会惊慌，或者不会越俎代庖时，他就逐渐会提交真实的结果

猛然拉开地毯

• 不论协作与否，拥有能了解状态真相的评审机制是必要的
• PERT图以及频繁、明确的里程碑式这种评审的基础
• 大型项目中，可能需要每周对某些部分进行评审，大约一个月左右进行整体评审

总结

• 计划日期是项目经理的工作产物，代表了经协调后的项目整体工作计划，它是否合理计划之前的判断
• 估计日期是最基层经理的工作产物，基层经理对所讨论的工作有着深刻的了解，估计日期代表了在现有资源和已得到了作为先决条件的必要输入的情况下
• PERT图的准备是老板和要向他进行汇报的经理们的职责。需要一个小组（1~3人）来关注它的更新，修订和报告，可以将这个小组看做是老板的延伸

另外一面

需要什么样的文档

使用程序

• 目的。主要的功能是什么，开发程序的原因是什么？
• 环境。程序运行在什么样的机器、硬件配置和操作系统上？
• 范围。输入的有效范围是什么？允许显示的合法输出范围是什么？
• 实现功能和使用的算法。精确地阐述它做了什么？
• “输入——输出”格式。必须是确切和完整的
• 操作指令。包括控制台及输出内容中正常和异常结束的行为
• 选项。用户的功能选项有哪些？如何在选项之间进行挑选？
• 运行时间。在指定的配置下，解决特定规模问题所需要的时间？
• 精度和校验。期待结果的精确程度？如何进行精度的检测？

验证程序

• 除了程序的使用方法，还需要附带一些程序正确运行的证明，即测试用例
• 用例根据输入数据的范围分成三个部分
• 针对遇到的大多数常规数据对程序主要功能进行测试的用例
• 数量相对较少的合法数据测试用例，对输入数据范围边界进行检查，确保最大可能值，最小可能值和其他极值数据下保证正常工作用例
• 数量相对较少的非法数据测试用例，边界外的值，确保无效输入能有正确的数据诊断提示

修改程序

• 流程图或子系统的结构图
• 对所有算法的完整描述，或者是类似算法的参考资料
• 对所有文件规划的解释
• 数据流处理的概要描述
• 初始设计中，对已预见修改的讨论；特性、功能回调以及出口的位置

流程图

流程图是被吹捧得最过分的一种程序文档

自文档化的程序

源代码和程序文档的“合并文件“，即把文档整合到源程序

系列索引

人月神话（1）焦油坑
人月神话（2）人月神话
人月神话（3）外科手术队伍
人月神话（4）系统设计
人月神话（5）画蛇添足
人月神话（6）贯彻执行
人月神话（7）巴比伦塔为什么失败
人月神话（8，9）胸有成竹与削足适履
人月神话（10）提纲挈领
人月神话（11）未雨绸缪
人月神话（12）干将莫邪
人月神话（13,14,15）整体部分 祸起萧墙与另外一面