CMMI生命周期模型选用指南.doc

编码：SHZIM-O-OPD-P02 xxxx技术股份有限公司 生命周期模型选用指南 更改控制页 序号 版本号 更改时间 更改内容描述 填写人 1 2 目 录 1 目的 1 2 范围 1 3 模型介绍 1 3.1 瀑布模型 1 3.1.1 模型说明 1 3.1.2 模型分析 1 3.2 迭代模型 2 3.2.1 模型说明 2 3.2.2 模型分析 2 3.3 快速原型模型 3 3.3.1 模型说明 3 3.3.2 模型分析 3 3.4 精简模型 4 3.4.1 模型说明 4 3.4.2 模型分析 4 3.5 V模型 5 3.5.1 模型说明 5 3.5.2 模型分析 6 4 模型选择 7 4.1 模型选择原则 7 4.2 项目分类 7 4.3 模型选择指南 7 目的 描述适合公司现状、可供项目选择的组织级生命周期模型。 范围 公司所有软件项目。 模型介绍 瀑布模型 模型说明 图1 瀑布模型 对于需求比较明确的项目，可以使用瀑布模型进行项目开发，每个阶段的输入都是依靠上一个阶段的输出，每个阶段内都需要完成与最终产品相关的所有工作。 模型分析 优点： 可以明确划分项目的各个阶段，便于管理； 项目成员只需要在被安排的阶段开展项目工作，不需要全程参与； 阶段工作内容清晰，降低了开发难度。 缺点： 对项目的启动条件要求较高； 若出现需求不明确或设计开发技术瓶颈，将会影响后续阶段的工作启动； 最终产品提交给用户确认的时间比较晚，存在一定的风险。 模型参照 参见《瀑布模型》。 迭代模型 模型说明 图2 迭代模型 通常有许多项目不能在需求开发阶段提供准确的需求，对于这样的项目，可以选择迭代开发模型，将能够确定的需求分析确定下来。之后便可以对这部分确定的需求进行系统设计、编码和测试。整个项目可以进行多次迭代的过程，一般情况下迭代的起点从需求开发开始，然后进行设计、编码和测试，但是有时候也可能出现从设计或编码阶段安排新的迭代过程。 模型分析 优点： 项目的启动条件比较灵活、只要用户有基本的立项意向和需求范围就可以开始计划工作； 可以在项目早期识别和管理风险； 可以较快的展现项目开发的成果，有益于增强客户受信度和满意度。 缺点： 迭代过程和范围划分比较复杂，项目的过程管理难度较大； 产品的设计开发是迭代过程完成的，容易出现产品构件兼容性问题，如果处理不当会出大量返工的工作。 快速原型模型 模型说明 图3 快速原型模型 在很多时候，需求分析人员无法通过与用户交谈就能获得明确的、详细的需求。这种情况可以选择快速原型开发方法，它的主要目的就是获得与验证需求。首先由开发人员构造原型，然后让用户试验该原型。一般地，当用户面对一个可操作的软件时，他比较容易说清楚“需要什么”和“不要什么”。从而有助于分析人员获取更详细的需求，以及验证需求是否正确。不断迭代上述过程，直至满足用户的所有需求为止。 模型分析 优点： 可以直观地让用户确定其需求，降低了用户对其提供的需求的不确定性。 缺点： 原型开发需要较早投入开发成本，如果原型不能在产品开发过程中进行复用，将会导致项目成本的增加。 模型参照 参见《快速原型模型》。 精简模型 模型说明 图4 精简模型1 图5 精简模型2 对于一些规模较小、版本升级、或者是有大量可复用构件的项目，这些项目需求相对比较明确、产品架构比较成熟和稳定，因此可以选择精简生命周期模型。 根据项目的不同情况：可以将设计阶段和编码阶段精简为一个工程阶段（如图4）；也可将需求开发阶段和设计阶段精简为一个阶段、将编码阶段和测试阶段精简为一个阶段（如图5）。 模型分析 优点： 缩短开发周期、降低各阶段工作的衔接工作； 可以一定程度降低项目的成本。 缺点： 如果精简方式选择不合理，可能会造成产品质量降低。 模型参照 参见《精简瀑布模型-1》和《精简瀑布模型-2》。 V模型 模型说明 图6 V模型 V模型是在快速应用开发 (RAD，Rap Application Development)模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。 从水平对应关系看 左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动——审核的过程，也就是静态的测试过程；右边是对左边结果的验证，是动态