开发方法
序列式开发法适用范围:
需求相当稳定;
设计直截了当,而且理解透彻;
开发团队对于这一应用领域非常熟悉;
项目风险小;
“长期可预测性”很重要;
后期改变需求、设计和编码的代价很可能较昂贵。
迭代式开发方法适用范围:
需求没有被理解透彻,或者出于其它理由你认为它是不稳定的;
设计很复杂,或者很有挑战性,或者两者兼具;
开发团队对于这一应用领域不熟悉;
项目包含许多风险;
“长期可预测性”不重要;
后期改变需求、设计和编码的代价很可能较低。
附:
1---核对表:前期准备
▲ 你是否辨明了自己所从事的软件的类型,并对所用的开发方法做出了相应的剪裁?
▲ 是否充分明确地定义了需求?而且需求足够稳定,能开始构建了?
▲ 是否充分明确地定义了架构,以便开始构建?
▲ 是否已经指出你的(当前)项目中都有的风险?(以避免构建活动面临不不要的风险)?
2---核对表:需求
针对功能的需求
▲ 是否详细定义了系统的全部输入,包括其来源、精度、取值范围、出现频率等?
▲ 是否详细定义了系统的全部输出,包括目的地、精度、取值范围、出现频率、格式等?
▲ 是否详细定义了所有输出格式(Web页面、报表,等等)?
▲ 是否详细定义了所有硬件及软件的外部接口?
▲ 是否详细定义了全部外部通信接口,包括握手协议、纠错协议、通信协议等?
▲ 是否列出了用户想要做的全部事情?
▲ 是否详细定义了每个任务所用的数据,以及每个任务得到的数据?
针对非功能需求(质量需求)
▲ 是否为全部必要的操作,从用户的视角,详细描述了期望响应时间?
▲ 是否详细描述了其他与计时有关的考虑,例如处理时间、数据传输率、系统吞吐量?
▲ 是否详细定义了安全级别?
▲ 是否详细定义了可靠性,包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略等?
▲ 是否详细定义了机器内存和剩余磁盘空间的最小值?
▲ 是否详细定义了系统的可维护性,包括适应特定功能的变更、操作环境的变更、与其他软件的接口变更能力?
▲ 是否包含对“成功”的定义?“失败”的定义呢?
需求质量
▲ 需求是用用户的语言书写的吗?用户也是这么认为的吗?
▲ 每条需求都不与其他需求冲突吗?
▲ 是否详细定义了相互竞争的特性之间的权衡——例如,健壮性与正确性之间的权衡?
▲ 是否避免在需求中规定设计(方案)?
▲ 需求是否在详细程度上保持相当一致的水平?有些需求应该更详细地描述吗?开发者也这么想吗?
▲ 每个条款都与待解决的问题及解决方案相关吗?能从每个条款上溯到它在问题域中对应的根源吗?
▲ 是否每条需求都是可测试的?是否可能进行独立的测试,以检验满不满足各项需求?
▲ 是否详细描述了所有可能的对需求的改动,包括各项改动的可能性?
需求的完备性
▲ 对于在开始开发之前无法获得的信息,是否详细描述了信息不完全的区域?
▲ 需求的完备度是否能达到这种程度:如果产品满足所有的需求,那么它就是可接受的?
▲ 你对全部需求都感到很舒服吗?你是否已经去掉了那些不可能实现的需求——那些只是为了安抚客户和老板的东西?
3---核对表:架构
针对各架构的主题
▲ 程序的整体组织架构是否清晰?是否包含了一个良好的架构全局观(及其理由)?
▲ 是否明确定义了主要的构造块(包括每个构造块的职责范围及与其他构造块的接口)?
▲ 是否明显涵盖了“需求”中列出的所有功能(每个功能对应的构造块不太多也不太少)?
▲ 是否描述并论证了那些关键的类?
▲ 是否描述并论证了数据设计?
▲ 是否详细定义了数据库的组织结构和内容?
▲ 是否指出了所有关键的业务规则,并描述其对系统的影响?
▲ 是否描述了用户界面设计的策略?
▲ 是否将用户界面模块化,使界面的变更不会影响程序的其余部分?
▲ 是否描述并论证了处理I/O的策略?
▲ 是否估算了稀缺资源(如线程、数据库连接、句柄、网络带宽等)的使用量,是否描述并论证了资源管理的策略?
▲ 是否描述了架构的安全需求?
▲ 架构是否为每个类、每个子系统、或每个功能域提出空间与时间预算?
▲ 架构是否描述了如何达到可伸缩性?
▲ 架构是否关注互操作性?
▲ 是否描述了国际化/本地化策略?
▲ 是否规定了容错的办法(如果需要)?
▲ 是否证实了各个部分的技术可行性?
▲ 是否详细描述了过度工程的方法?
▲ 是否包含了必要的“买 vs. 造”的决策?
▲ 架构是否描述了如何加工被复用的代码,使之符合其他架构目标?
▲ 是否将架构设计得能够适应很可能出现的变更?
架构的总体质量
▲ 架构是否解决了全部需求?
▲ 有没有哪个部分是“过度架构”或“欠架构”?是否明确宣布了这方面的预期指标?
▲ 整个架构是否在概念上协调一致?
▲ 顶层设计是否独立于用作实现它的机器和语言?
▲ 是否说明了所有主要决策的动机?
▲ 你,作为一名实现该系统的程序员,是否对这个架构感觉良好?