编码：SHZIM-O-OPD-P02 xxxx技术股份有限公司
生命周期模型选用指南
更改控制页
目录
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模型分析 (3)
3.3快速原型模型 (3)
3.3.1模型说明 (3)
3.3.2模型分析 (4)
3.4精简模型 (4)
3.4.1模型说明 (4)
3.4.2模型分析 (5)
3.5V模型 (6)
3.5.1模型说明 (6)
3.5.2模型分析 (6)
4模型选择 (8)
4.1模型选择原则 (8)
4.2项目分类 (8)
4.3模型选择指南 (9)
1目的
描述适合公司现状、可供项目选择的组织级生命周期模型。
2范围
公司所有软件项目。
3模型介绍
3.1瀑布模型
3.1.1模型说明
图1 瀑布模型
对于需求比较明确的项目，可以使用瀑布模型进行项目开发，每个阶段的输入都是依靠上一个阶段的输出，每个阶段内都需要完成与最终产品相关的所有工作。
3.1.2模型分析
优点：
1.可以明确划分项目的各个阶段，便于管理；
2.项目成员只需要在被安排的阶段开展项目工作，不需要全程参与；
3.阶段工作内容清晰，降低了开发难度。
缺点：
1.对项目的启动条件要求较高；
2.若出现需求不明确或设计开发技术瓶颈，将会影响后续阶段的工作启动；
3.最终产品提交给用户确认的时间比较晚，存在一定的风险。
3.1.3模型参照
参见《瀑布模型》。
3.2迭代模型
3.2.1模型说明
图2 迭代模型
通常有许多项目不能在需求开发阶段提供准确的需求，对于这样的项目，可以选择迭代开发模型，将能够确定的需求分析确定下来。
之后便可以对这部分确定的需求进行系统设计、编码和测试。
整个项目可以进行多次迭代的过程，一般情况下迭代的起点从需求开发开始，然后进行设计、编码和测试，但是有时候也可能出现从设计或编码阶段安排新的迭代过程。
优点：
1.项目的启动条件比较灵活、只要用户有基本的立项意向和需求范围就可以
开始计划工作；
2.可以在项目早期识别和管理风险；
3.可以较快的展现项目开发的成果，有益于增强客户受信度和满意度。
缺点：
1.迭代过程和范围划分比较复杂，项目的过程管理难度较大；
2.产品的设计开发是迭代过程完成的，容易出现产品构件兼容性问题，如果
处理不当会出大量返工的工作。
3.3快速原型模型
3.3.1模型说明
图3 快速原型模型
在很多时候，需求分析人员无法通过与用户交谈就能获得明确的、详细的需求。
这种情况可以选择快速原型开发方法，它的主要目的就是获得与验证需求。
首先由开发人员构造原型，然后让用户试验该原型。
一般地，当用户面对一个可操作的软件时，他比较容易说清楚“需要什么”和“不要什么”。
从而有助于分析人员获取更详细的需求，以及验证需求是否正确。
不断迭代上述过程，直至满足用户的所有需求为止。
优点：
1.可以直观地让用户确定其需求，降低了用户对其提供的需求的不确定性。
缺点：
1.原型开发需要较早投入开发成本，如果原型不能在产品开发过程中进行复
用，将会导致项目成本的增加。
3.3.3模型参照
参见《快速原型模型》。
3.4精简模型
3.4.1模型说明
图4 精简模型1
图5 精简模型2
对于一些规模较小、版本升级、或者是有大量可复用构件的项目，这些项目需求相对比较明确、产品架构比较成熟和稳定，因此可以选择精简生命周期模型。
根据项目的不同情况：可以将设计阶段和编码阶段精简为一个工程阶段（如图4）；也可将需求开发阶段和设计阶段精简为一个阶段、将编码阶段和测试阶段精简为一个阶段（如图5）。
3.4.2模型分析
优点：
1.缩短开发周期、降低各阶段工作的衔接工作；
2.可以一定程度降低项目的成本。
缺点：
1.如果精简方式选择不合理，可能会造成产品质量降低。
3.4.3模型参照
参见《精简瀑布模型-1》和《精简瀑布模型-2》。
3.5 V模型
3.5.1模型说明
图6 V模型
V模型是在快速应用开发 (RAD，Rap Application Development)模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。
V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。
对于一些规划较小、版本升级、或者是有大量可复用构件的项目，这些项目需求相对比较明确、产品架构比较成熟和稳定，因此亦可以选择V模型。
（如图6）。
3.5.2模型分析
从水平对应关系看
左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动——审核的过程，也就是静态的测试过程；右边是对左边结果的验证，是动态测试的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。
如：
·需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例(Use Case)并策划测试活动。
·当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可以设计系统的测试方案和测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采购。
因为这些准备工作，实际上是要花去很多时间。
·当设计人员在做在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例以开发测试脚本。
·在编程的同时，进行单元测试，是一种很有效的办法，可以尽快找出程序中的错误，充分的单元测试可以大幅度提高程序质量、减少成本。
从中可以看出，V模型使我们能清楚地看到质量保证活动和项目同时展开, 项目一启动，软件测试的工作也就启动了,避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行。
从垂直方向看
水平虚线上部表明，其需求分析、定义和验收测试等主要工作是面向用户，要和用户进行充分的沟通和交流，或者是和用户一起完成。
水平虚线下部的大部分工作，相对来说，都是技术工作，在开发组织内部进行，主要是由工程师、技术人员完成。
从垂直方向看，越在下面，白盒测试方法使用越多，到了集成、系统测试，更多是将白盒测试方法和黑盒测试方法结合起来使用，形成灰盒测试方法。
而在验收测试过程中，由于用户一般要参与，使用黑盒测试方法。
3.5.3模型参照
参见《V模型》。
4模型选择
4.1模型选择原则
●能够满足公司“开发管理方针”的要求；
●不会降低项目开发过程和工作产品的质量；
●不会失去对工作进展的（跟踪）可视性；
●不会失去对软件工作产品的配置管理和控制，也不会额外增加无益的工作；
●不会降低工程师的开发效率；
●在维持现有人力资源的情况下，能够按计划如期完成工作；
●项目资金可以控制在目标成本范围内。
4.2项目分类
4.3模型选择指南
公司的项目生命周期选择参见下表:。