生命周期模型选用指南重点.docVIP

生命周期模型选用指南 版本1.0 发布时间： 烟台海颐软件股份有限公 文件变更记录 *A - 增加 M - 修订 D - 删除 变更 版本号 日期 变更类型（A*M*D） 修改人 变更摘要 备注 目的 本文档统一规范描述了组织内软件开发过程中可以使用的各种生命周期模型，供项目策划时根据项目的具体情况，由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序 机构： 产品部、开发部、工程部、质量部。 业务： 本指南适用于组织内的全部软件项目。 名词术语 软件生命周期： 软件生命周期，是指从开始策划软件产品到软件不再使用为止这段时间。典型的软件生命周期包括策划阶段、需求阶段、分析与设计阶段、实现阶段（构造阶段）、测试阶段、实施和维护阶段。 软件生命周期模型 软件生命周期模型是对软件工程活动的组织方式。软件生命周期模型通过确定软件开发活动的顺序和相互制约关系来保证软件工程活动的流程化。 软件生命周期模型 瀑布模型(Waterfall) 模型定义 该模型首先由Royce[1970]提出，又称线性顺序模型， 模型图 模型特点 优点 瀑布模型是一种文档驱动模型，主要的工作产品通过文档从一个阶段传递到下一阶段，瀑布模型的每个活动的完成都是以该活动的评审通过作为标志的。当项目有着明确的产品定义以及易于理解的技术方案的情况下，瀑布模型有助于及早发现问题，降低阶段成本。 瀑布模型的主要特点： · 简单、易于理解 · 要求严格的管理，包括周密的项目计划、明确的交付物、严格的质量控制手段（如阶段的评审）等 · 客户在项目的后期才可以见到的产品以及判断产品的质量 · 强调产品的测试 缺点： · 缺乏灵活性 瀑布模型要求在项目的初期明确定义全部需求，然而客户在项目初期很难明确描述所有的需求，这种不确定性难以满足模型要求的“稳定的、明确定义的需求”的要求。事实上，在设计完成和代码完成之前很难充分描述需求，因为客户只能在最后阶段看到产品，产品是否满足客户的真正需求只有此刻才可以得以检验。因此是否满足客户真正需求的风险往往只能在开发过程后期才显露，相应的修改成本巨大。 · 很难反映实际的开发过程 实际的开发过程很难象瀑布模型中所有活动按照既定的顺序执行的设想一样，因为很多活动是重复进行的。 · 对于要求快速开发的项目，瀑布模型可能导致过多的文档 · 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； · 用户的反馈只有到项目后期才看得到。 适用场景 适合前期需求比较明确,且项目管理能力比较欠缺的的项目； 适合有稳定的产品定义和易于掌握的技术方案的项目 适合处理易于理解但复杂的项目 适合质量需求高于进度和成本需求的项目 适合项目的开发队伍的技术力量比较薄弱或缺乏经验的情况 适合于小型项目 带反馈的瀑布模型(Waterfall Model With Feedback) 模型定义 该模型 模型特点 带反馈的瀑布模型在保持原有瀑布模型活动阶段自上而下、相互衔接、逐级下落的次序的同时，增加了反馈环节，当某阶段发现上游缺陷时可通过追溯予以消除或改进。 使用场景 适用于需求比较明确，各环节间反馈更新信息较少的项目。针对烟台海颐软件股份有限公司而言，本模型适合于小型的、推广性质的网站、县级客服、营销管理系统等项目。 V型模型(V-shaped Model) 模型定义 V 形模型也是连续开发模型的一种，有时也被成为快速应用开发模型(RAD)，类似于瀑布模型。区别在于每个开发阶段有一个测试阶段与之匹配：需求同系统测试，架构设计同集成测试，子系统设计同单元测试。V 模型是瀑布模型的改进。 模型图 模型特点 优点 应用和管理简单：为开发阶段定义的进入准则和出口准则可以清楚的定义，对项目进行有效管理的相关评判尺度也可以清楚的定义。同时，由于软件开发过程的任何一个时间点，相应的文档和代码等都只有一个基线，所以对于配置管理也是一件比较轻松的事情。 强调测试阶段/过程与开发过程的对应关系：从模型中也可以看出，软件测试是V 模型的重点。在V 模型生命周期模型中，软件测试的活动是和开发的每个阶段活动对应的。 可以不考虑过程的反复 不必随时列出管理和支持过程 缺点： V 模型在处理风险方面存在不足：假如存在风险或者软件需求方面的大的变更，我们回头去修改前面阶段的框架、设计、代码或测试文档和测试用例等，将需要极大的成本，同时难度也较大。 软件产品在开发过程中对用户是不可见的：在开发阶段中，用户没有直观的工作产品可以体验，只能是在产品交付之后才能使用。这导致用户在开发过程中参与的力度不足。 适用场景 ??﹡ 需求是稳定可靠的 ??﹡ 软件实现方法是成熟的 ??﹡ 软件结构清晰，模块间的界限