【代码大全】第3章 三思而后行：前期准备

第三章 三思而后行：前期准备

准备工作的中心目标就是降低风险。
造成准备不周全的常见原因是，那些分配去做前期准备活动的开发人员并不具备完成这一任务的专业技能。或者，他们不能抵抗“尽快进行编码”的欲望。或者，管理者的对前期准备的漠视。
在开始构建之前要做前期准备的绝对有力且建明的论据：诉诸逻辑，诉诸类比，诉诸数据。
辨明你所从事的软件的类型，三种常见的软件项目种类：商业系统，使命攸关的系统，使命攸关的嵌入式系统。
迭代开发往往能够减少“前期准备不足”造成的负面影响，但不能完全消除。首先，每一轮迭代仍然要到最后才能检测到缺陷，修正成本较高，其次，迭代开发的成本在项目过程中分次支付，但总的成本是相似的。
一条有用的经验是：计划好预先对80%的需求做出详细说明，并给“稍后再进行详细说明的额外请求”分配一定的时间。另一种替代方案是，预先只对最重要的20%的需求详细说明，并计划以小幅增量开发软件的剩余部分，随着项目的进行，对额外的需求和设计做出详细说明。
选择序列化开发方法的情况：需求相当稳定、设计直截了当、开发团队对这一领域非常熟悉、项目的风险小、“长期可预测性”很重要、后期改变需求设计和编码的代价很昂贵。
选择迭代开发的情况：需求未被理解或不稳定、设计复杂有挑战、开发团队对这一领域不熟悉、项目诸多风险、后期改变需求设计和编码的代价很低。
问题定义的先决条件：对这个系统要解决的问题要有清楚的陈述，不涉及任何可能的解决方案。
需求的先决条件：需求详细描述软件应该做什么。如果没有好的需求，你可能对问题有总体的把握，但却没有击中问题的特定方面。
在构建期间处理需求变更：评估你的需求的质量、确保每个人都知道需求变更的代价、建立一套变更控制程序、使用能适应变更的开发方法、放弃这个项目、注意项目的商业案例。
需求---核对表：
针对功能需求：

n 是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率等

n 是否详细定义了系统的全部输出，包括来源、精度、取值范围、出现频率等

n 所有输出文档的格式

n 所有软硬件的外部接口

n 全部外部通信借口，包括握手协议、纠错协议、通信协议

n 用户想做的所有事情

n 每个任务所用的数据，以及每个任务得到的数据
针对非功能需求（质量需求）

n 全部必要的操作，从用户视角，期待响应时间？

n 其他与计时有关的考虑，例如处理时间、数据传输率、系统吞吐量

n 安全级别

n 可靠性，包括软件失灵的后果，发生故障时要保护的信息、错误检测与恢复策略

n 内存和剩余磁盘空间的最小值

n 系统的可维护性，适应特定功能的变更、操作环境的变更、软件借口的变更

n 包含对“成功”“失败”的定义
需求的质量

n 需求是用用户的语言书写的吗

n 需求之间不冲突？

n 是否详细定义了相互竞争的特性之间的权衡？如健壮性和正确性

n 是否避免在需求中规定设计？

n 需求在详细程度上保持相当一致？

n 每个条款都与待解决大问题有关吗？

n 每条需求都是可测试的？

n 是否详细描述了所有可能的对需求的改动？
需求的完备性

n 对于开发之前无法获得的信息，是否详细描述了信息不完全的区域？

n 需求的完备度是否达到这种程度：如果产品满足所有需求，那他就是可接受的？

n 你对全部需求都感到很舒服吗？
架构的先决条件：架构是对整个系统范围的设计约束，决定了系统的概念完整性。离开了好的软件架构，你可能瞄准了正确的问题，却使用了错误的解决办法。
构建的典型组成部分：程序组织、主要的类、数据设计、业务规则、用户界面、资源管理、安全性、性能、可伸缩性、互用性、本地化/国际化、输入输出、错误处理（检测or纠正，主动or被动，如何传播错误，在哪一层次上处理错误）、容错性、架构的可行性、过度工程、关于“买”还是“造”的决策、复用的策略、变更策略、架构的总体质量（满足全部需求，过度架构，概念上一致，独立于机器和语言，说明了主要的决策和动机）。