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

目的 描述适合公司现状、可供工程选择的组织级生命周期模型。 范围 公司所有软件工程。 模型介绍 瀑布模型 模型说明 图1 瀑布模型 对于需求比较明确的工程，可以使用瀑布模型进行工程开发，每个阶段的输入都是依靠上一个阶段的输出，每个阶段内都需要完成与最终产品相关的所有工作。 模型分析 优点： 可以明确划分工程的各个阶段，便于管理； 工程成员只需要在被安排的阶段开展工程工作，不需要全程参与； 阶段工作内容清晰，降低了开发难度。 缺点： 对工程的启动条件要求较高； 假设出现需求不明确或设计开发技术瓶颈，将会影响后续阶段的工作启动； 最终产品提交给用户确认的时间比较晚，存在一定的风险。 模型参照 参见?瀑布模型?。 迭代模型 模型说明 图2 迭代模型 通常有许多工程不能在需求开发阶段提供准确的需求，对于这样的工程，可以选择迭代开发模型，将能够确定的需求分析确定下来。之后便可以对这局部确定的需求进行系统设计、编码和测试。整个工程可以进行屡次迭代的过程，一般情况下迭代的起点从需求开发开始，然后进行设计、编码和测试，但是有时候也可能出现从设计或编码阶段安排新的迭代过程。 模型分析 优点： 工程的启动条件比较灵活、只要用户有根本的立项意向和需求范围就可以开始方案工作； 可以在工程早期识别和管理风险； 可以较快的展现工程开发的成果，有益于增强客户受信度和满意度。 缺点： 迭代过程和范围划分比较复杂，工程的过程管理难度较大； 产品的设计开发是迭代过程完成的，容易出现产品构件兼容性问题，如果处理不当会出大量返工的工作。 快速原型模型 模型说明 图3 快速原型模型 “需要什么〞和“不要什么〞。从而有助于分析人员获取更详细的需求，以及验证需求是否正确。不断迭代上述过程，直至满足用户的所有需求为止。 模型分析 优点： 可以直观地让用户确定其需求，降低了用户对其提供的需求的不确定性。 缺点： 原型开发需要较早投入开发本钱，如果原型不能在产品开发过程中进行复用，将会导致工程本钱的增加。 模型参照 参见?快速原型模型?。 精简模型 模型说明 图4 精简模型1 图5 精简模型2 对于一些规模较小、版本升级、或者是有大量可复用构件的工程，这些工程需求相比照拟明确、产品架构比较成熟和稳定，因此可以选择精简生命周期模型。 根据工程的不同情况：可以将设计阶段和编码阶段精简为一个工程阶段〔如图4〕；也可将需求开发阶段和设计阶段精简为一个阶段、将编码阶段和测试阶段精简为一个阶段〔如图5〕。 模型分析 优点： 缩短开发周期、降低各阶段工作的衔接工作； 可以一定程度降低工程的本钱。 缺点： 如果精简方式选择不合理，可能会造成产品质量降低。 模型参照 参见?精简瀑布模型-1?和?精简瀑布模型-2?。 V模型 模型说明 图6 V模型 V模型是在快速应用开发 (RAD，Rap Application Development)模型根底上演变而来，由于将整个开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。 对于一些规划较小、版本升级、或者是有大量可复用构件的工程，这些工程需求相比照拟明确、产品架构比较成熟和稳定，因此亦可以选择V模型。〔如图6〕。 模型分析 从水平对应关系看 左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动——审核的过程，也就是静态的测试过程；右边是对左边结果的验证，是动态测试的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。如： ·需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例(Use Case)并筹划测试活动。 ·当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以设计系统的测试方案和测试方案，并事先准备系统的测试环境，包括硬件和第三方软件的采购。因为这些准备工作，实际上是要花去很多时间。 ·当设计人员在做在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试方案，并基于这些测试用例以开发测试脚本。 从中可以看出，V模型使我们能清楚地看到质量保证活动和工程同时展开, 工程一启动，软件测试的工作也就启动了,防止了瀑布模型所带来的误区——软件测试是在代码完成之后进行。 ? 从垂直方向看 模型参照 参见?V模型?。 模型选择 模型选择原那么 能够满足公司“开发管理方针〞的要求； 不会降低工程开发过程和工作产品的质量； 不会失去对工作进展的〔跟踪〕可视性； 不会失去对软件工作产品的配置管理和控制，也不会额外增加无益的工作； 不会降