1. 模型介绍

1.1 前言

制定软件生命周期（Software Lift Cycle, SLC）的目的是确定项目应该采用的软件生命周期模型
，统筹规划项目的整体开发流程。

软件生命周期是组织软件标准过程模型的重要组成部分
。本文档阐述了周期模型选择的规程，该规程的“目标”
、“角色与职责”、“启动准则”、“输入”

、“主要步骤”
、“输出”
、“结束准则”和“度量”在CMMI相关文档中均已定义
。

1.2 说明

软件生命周期是指从设想软件产品开始到软件不再供使用为止的时间间隔

。对生命周期细分阶段进行管理称为周期模型，典型的几种生命周期模型包括瀑布模型、瀑布迭代模型
、原型迭代模型
、XP模型等。项目组应在软件项目启动阶段认真考虑项目的特征和目标的基础上参考原有模型和组织软件标准过程，运用《过程裁减指南》为项目开发裁减出一个软件生命周期模型
。

无论选择何种模型，都要包括下列一般软件工程过程必须包含的内容：

1.需求

2.设计

3.编码

4.集成

5.测试

2. 软件生命周期定义

2.1 目标

本规程的制定是为了在项目实施过程中能够有一个统一的方法来分析项目需求预先识别项目特征并提供可供项目选择的软件生命周期模型
，使其可以和OSSP结合在一起使用。

2.2 角色与职责

角色	职责	说明
项目经理	1） 归纳软件项目实施需求 2） 根据类似项目的开发经验 ，识别项目特征 3） 提出项目实施参考模型 4） 与项目成员一起讨论裁剪模型
项目成员	1） 总结类似项目的开发经验，识别项目特征 2） 裁剪项目实施参考模型

2.3 启动准则

从项目启动阶段开始

2.4 输入

《需求规格说明书》

2.5 主要步骤

软件生命周期模型一般都是在原有的软件生命周期模型基础上根据客户的需求范围和目标实现来判断项目的特征

，进而进行模型裁剪后产生。一般包括四个步骤
：需求识别分析、原型参考
、裁剪定义和模型实施。

图 2-1生命周期选型流程

2.5.1 需求识别分析

从需求被识别，并且明确了需求目标开始

，就进入项目启动阶段，这个时候项目组开始组建，同时开始收集需求，项目经理应积极配合业务代表或者商务经理一起参与需求研讨和项目的策划，安排有经验的人员进入项目组，迅速对需求进行初步分析，概括项目的特征
。

此部分的需求分析还应该包括对历史项目的回顾，总结成功实施经验和吸取失败教训，并归档备案作为组织的知识库。

2.5.2 原型参考

当项目需求目标确定，同时识别出项目特征，从常用软件生命周期模型中挑选出一个模型以供参考
，该周期原型必须在很大程度上适合项目的具体特征以及能够结合组织标准软件过程一起使用
。

项目一开始
，挑选后的软件生命周期模型仅作参考，下一步还必须结合实际的越来越丰富的需求进行裁剪以形成最终的项目指导模型。最终的项目指导模型可以归档成为下一个类似项目的原始参考模型。

原型的描述主要包括软件生命周期模型的原理、优缺点

、选用规则。

2.5.3 裁剪定义

Ø 裁剪基于项目特征

项目特征是裁剪工作的出发点，包括项目规模（如大、中、小等）、项目类型（如新开发、外包、升级等），以及技术难易度、产品类型、项目的时间和质量要求等要素。

Ø 明确可裁剪的对象

可裁剪对象确定了裁剪的内容范围
，可裁剪对象不仅仅限于过程元素和活动，还包括参照标准、方法和工具、输出成果物及模板等
。

Ø 确定裁剪所考虑的要素

裁剪要素界定了裁剪的方向和尺度。例如，对于某个裁剪对象，其范围
、频度等都是裁剪要素
。对于有开发经验的小项目，可以适当减少对于技术方面的评审的频度
。

Ø 裁剪的决定要基于风险进行考虑

基于风险可检验裁剪的适当性

。对过程或活动的调整或放弃需要通过分析其所带来的风险和影响再做决定
。

2.5.4 模型实施

裁剪后的新周期模型
，是个适应项目特征的项目标准软件过程
，该过程包含软件生命周期模型的原理
、优缺点等描述，能够帮助软件开发人员更好地理解和运用此生命周期进行项目开发
。

新周期模型对于项目开发具有指导意义，必须将该模型下达通知到项目组所有成员，项目经理必须监督保证此模型的实施与推广
，实现“项目可控，质量可靠”的最终目标。

2.5.5 输出

《项目已定义过程》（PDP）

2.6 结束准则

项目结项。

2.7 度量

度量的目的是统计用裁减后的软件生命周期模型指导项目过程进展后，此项目产生的所有工作量。

同样的软件项目，实施不同的周期模型
，项目的总的工作量也是不同的，好的周期模型不仅能够大大缩减工作量，同时也保证代码的质量。不合理的周期模型则会因为保证质量的需要引入重复的各类阶段审查
，进而产生更多
、更冗长的无法跟踪维护的文档导致项目失败，或者忽略关键性的阶段审查而带来需求的不明确及代码的重复返工，同样也导致了项目失败。

软件生命周期模型的引入，将对项目过程划分成几个不同的阶段
，规模较大的项目则阶段内还分更多小的阶段，每个阶段都将对本阶段内产生的成果物进行审查。因此，如何估算审查的工作量也必须包含在此度量活动中
。

3. 常用软件生命周期模型

软件项目生命周期是指从软件产品的设想开始到软件不再使用而结束的时间
。软件项目生命周期一般包括售前阶段
、需求阶段、设计阶段、实现阶段、测试阶段、部署上线阶段
、运行和维护阶段等。由于软件实施组织是为不同的商业客户生产软件，所以传统的软件项目生命周期不可能适用于公司所有软件项目的实施情况，为此EPG在软件工程学科的传统生命周期的基础上，综合了组织所有项目的特征
，定义出了一个大而全的生命周期模型。每个软件项目可以在可选择软件周期参考模型的过程中，结合组织标准软件过程
，运用过程裁减标准进行裁减
，从而成为项目的实施标准过程。

3.1 产品或定制型项目生命周期模型

标准瀑布生命周期模型

3.1.1 标准瀑布生命周期模型（V）

标准瀑布生命周期模型适用于公司内部研发项目、为客户开发系统的项目

、二次开发和推广移植的项目。模型用图形的方式来描述
，显示了它们应用的阶段及其输入/输出

。描述了在何种条件下使用该模型
，需要注意风险和应用裁剪的指导
。

当开发的系统规模和复杂度较高，达到需要采用多层设计时
，推荐使用标准的生命周期
。最终的系统被分解为多于一个的子系统。每个子系统由一个或多个模块组成。每个模块由一个或多个单元
。一个单元是最小的可独立测试的单位。用于集成测试的模块测试计划和集成测试计划中的模块就是从单元而来
，子系统从模块而来。

使用指南:

Ø 需求很好地被理解了且期望是相对稳定的。

Ø 解决方案的技术和架构被很好地理解。

Ø 高可维护的和可支持的解决方案的需要。

Ø 所有中间交付物受控的基线具有良好的可视性和可靠性。

优点:

Ø 对管理层提供实施可视性
。

Ø 由于需求相对稳定度较高
，其时间表具有很好的稳定度
。

注意事项:

Ø 在不清晰、不稳定的需求和技术条件下不能很好工作
。

Ø 由于在一个阶段结束时要做很多文档并要所有的干系人签字，有很大的开销
。

Ø 所有的干系人都要在每一个阶段结束时进行说明或签字。

Ø 根据工作量和时间分析
，由于项目范围的改变而导致的中途更正是花很大代价的。

裁剪指南:

Ø 模块测试计划和集成测试计划可以组合在一个文档中。

Ø 这个模型中的阶段和检查点都不能做变更
。

3.1.2 V-瀑布生命周期为关键产品(VC)

瀑布生命周期为关键产品

该模型是经过裁剪的模型。推荐在中等复杂度和规模的项目中使用，在这些项目中解决方案可以用两层来表示

。系统由多于一个模块组成
，同时每个模块又是由一个或多个单元组成。这种模型在软件可靠性要求很高是被选择
，要求除开发者以外的人来进行测试。对这个生命周期来说，单元测试是必要的 。

使用指南:

Ø 安全/任务关键软件开发

Ø 整个开发过程中的可跟踪性和透明性的需求

Ø 控制开发的需求（成本、范围和时间表）

优点:

Ø 正规化保证了经过高度测试后形成可靠的系统

注意事项:

Ø 在开发过程中
，最终用户不可视
。

Ø 在测试计划评审中包括顾客。

裁剪指导:

Ø 这个模型中的阶段和检查点都不能做变更。

3.1.3 阶段V-瀑布生命周期 (V4)

阶段V-瀑布生命周期

该模型适合于对正规化程度低的小到中型项目。系统的规模和复杂度低，可以用一层设计来表示。最终的系统可以用一个或多个单元来构成。在这个生命周期中单元测试是必要的。

使用指南:

Ø 项目的工作量, 周转时间中等

Ø 产品复杂度和团队规模中等

Ø 需求和技术比较好地被理解

Ø 比V瀑布在周转时间的性能上要更好。

优点:

Ø 对时间表有中等的控制

Ø 中等的开销

Ø 对交付的解决方案有合理控制

注意事项:

Ø 在开发过程中，最终用户不可视。

Ø 对很复杂的项目不建议使用，因为它只提供了一层设计。

裁剪指导:

Ø 这个模型中的设计阶段是由VC模型中的概要设计和详细设计组合而成的。只有一层设计和测试的文档是必需的。

Ø 在V模型需要测试计划同所测试的开发一同被评审和基线化时
，一个项目可以在每个测试计划被评审和基线化时裁剪和设置检查点
。然而测试计划活动一定要在阶段指示的地方启动

，如ST计划一定要在RA&P阶段启动
。

3.1.4 演示生命周期(D)

演示生命周期

这个模型仅适合用于一个演示的系统开发，最终其将会被丢弃
，它形成的成果将是对开发概念的证明。如果在其原型出来之后需要对此项目进行产品化，需要对这个开发的软件进行详细评估。

调查阶段是在SC检查点之前的所有阶段的合并
。调查、分析
、计划和设计活动都在这个阶段进行
。

使用指南:

Ø 很小范围和团队规模 – 可能1或2人的团队
。

Ø 低开发成本，高周转时间。

Ø 不能提供训练有素的经历和开发者。

Ø 项目失败影响低


。

优点:

Ø 很低 (可能最低) 成本。

Ø 中途修正是容易和便宜的
。

注意事项

Ø 不可靠的时间表。

Ø 产品不可靠或没有扩展项。

Ø 对管理层和顾客几乎都是不可见的
。

裁剪指导:

Ø 根据产品的需要在发布阶段的交付物要在整个SVW交付集中选择。要建立这些交付物一致的基线


。

3.1.5 进化开发模型（EVO）:

进化开发模型

进化开发模型 (EVO)是一种迭代的模型，可用来降低大项目的风险
。 风险可以有很多种类

，这个模型的每一个迭代或发布都针对了特定的风险集合。风险可以是对需求理解不清楚
、新技术的使用、架构的可行性
、潜在的性能问题等。每一个迭代都有不同的模型作为基础。

使用指南:

Ø 中到大项目, 可靠性和最终用户的可视性很重要。

Ø 需求
、架构和技术都没有很好地理解
。

Ø 最终产品要有好的扩展性

。

优点:

Ø 对管理层和顾客有很高的可视性
。

Ø 风险管理容易
。

Ø 中等的成本，至少提供了相对稳定的时间表。

注意:

Ø 需要有很有经验的和成熟的管理。

Ø 对每个周期的管理和文档都有成本

。

Ø 中途修改要明确定义
，包括对原型周期
。

Ø 在迭代过程中发生巨大的变化会导致成本花费和缺乏可靠性及扩展性。

裁剪指导:

Ø 每一个迭代都有不同的模型作为基础
，这些模型是从前面几种基本瀑布模型选出的
，遵循它们的裁剪指导
。在每个迭代中可以使用不同的模型
。

3.1.6 生命周期模型裁剪说明

裁剪项	类型（活动或工作产品）	裁减要素（增加、删除、修改）	裁减条件
标准瀑布生命周期模型模块测试计划	工作产品	删除	模块测试计划与集成测试计划可合并在一个文档中 。
进化开发模型	活动	修改	每一个迭代可使用不同的基本瀑布模型，并遵循其裁剪指导 。

3.1.7 生命周期模型使用指南汇总

生命周期模型	使用指南	优点	注意事项
标准瀑布生命周期模型	1.安全/任务关键软件开发 2.整个开发过程中的可跟踪性和透明性的需求 3.控制开发的需求（成本、范围和时间表）	正规化保证了经过高度测试后形成可靠的系统	1.在开发过程中 ，最终用户不可视 。 2.在测试计划评审中包括顾客。
V瀑布模型为关键产品（VC）	1.安全/任务关键软件开发 2.整个开发过程中的可跟踪性和透明性的需求 3.控制开发的需求（成本、范围和时间表）	正规化保证了经过高度测试后形成可靠的系统	1.在开发过程中 ，最终用户不可视。 2.在测试计划评审中包括顾客。
阶段V-瀑布生命周期 (V4)	1.项目的工作量, 周转时间中等 2.产品复杂度和团队规模中等 3.需求和技术比较好地被理解 4.比V瀑布在周转时间的性能上要更好 。	1.对时间表有中等的控制 2.中等的开销 3.对交付的解决方案有合理控制	1.在开发过程中 ，最终用户不可视。 2.对很复杂的项目不建议使用，因为它只提供了一层设计 。
演示生命周期（D）	1.很小范围和团队规模 – 可能1或2人的团队 。 2.低开发成本，高周转时间。 3.不能提供训练有素的经历和开发者 。 4.项目失败影响低。	1.很低 (可能最低) 成本。 2.中途修正是容易和便宜的。	1.不可靠的时间表。 2.产品不可靠或没有扩展项 。 3.对管理层和顾客几乎都是不可见的 。
进化开发模型（EVO）	1.中到大项目, 可靠性和最终用户的可视性很重要。 2.需求、架构和技术都没有很好地理解。 3.最终产品要有好的扩展性。	1.对管理层和顾客有很高的可视性 。 2.风险管理容易。 3.中等的成本 ，至少提供了相对稳定的时间表。	1.需要有很有经验的和成熟的管理。 2.对每个周期的管理和文档都有成本 。 3.中途修改要明确定义 ，包括对原型周期。 4.在迭代过程中发生巨大的变化会导致成本花费和缺乏可靠性及扩展性。

3.2 升级维护型项目生命周期模型

本模型描述了修补一个缺陷开展的活动。当缺陷修补活动需要作为一个独立的项目时，建议采用本项目生命周期模型。

缺陷分类

分析

修补

测试

补丁/修补版本

单个缺陷的活动遵循缺陷管理的过程，该过程根据缺陷跟踪机制/工具的不同而改变
。

本活动的指南和在本生命周期可能的裁剪在脚注中提供。

表1缺陷修补项目生命周期模型

注：表格中对应的数字标号，请参考表格后的裁减指南
；

阶段	分类	分析 ⑹	修补	测试	补丁/修补版本 ⑼
输入	●服务要求/变更要求 ●市场评审 ⑿	●区分优先次序的 CR ●充足的信息展开分析 ●调试工具	●源代码 ●数据库 ●分析阶段输出 ●依赖信息	●修补阶段输出 ●测试用例组	●分支代码的顶部 ●构造环境 ●测试用例组 补丁工具
任务	●初步分析⑵ ●初步估计⑶ ●区分优先次序的CR ⑷ ●更新 CR ⑸	●调查并模拟缺陷⑺ ●调试代码 ●设计测试用例⑻ ●更新 CR ⑸	●编制修补代码 ●单元测试修补代码 ●更新回归测试用例 ●同行评审 ●更新 CR ⑸	●回归测试 ●由提交者验证 (如果可行) ●登记已修改的代码 ●更新CR ⑸	●构造项目 ●回归/ 整合/系统测试 ●准备补丁 ●评审补丁文档 ●补丁/修补版本 ●更新 CR⑸
输 出	●分类并更新的CR	●缺陷隔离和用户推荐的分析完成 ●更新 CR	●包含修补的代码 ●单元测试后的代码 ●测试用例组 ●同行评审日志 ●更新的 CR	●测试结果 ●测试后的代码基线	●测试结果 ●补丁评审日志（如果可行） ●补丁 ●补丁样板/检查列表 (如果可行) ●更新 CR

注：任务/活动指南和裁剪指南：

1. 该模型也可以用于小的功能增强型项目 (小于1个月的工作量)。

2. 初步分析用于判断缺陷的相关信息。比如

，缺陷是否属于另一个项目/部件
，是否和已经存在的缺陷重复，是否由一个操作者的失误引起或是一个增加要求
，或者需要被作为技术攻关项目来处理。

3. 初步估计用于初步评估修复缺陷需修改规模、工作量
、成本等。

4. 为缺陷指定修复的优先级。

5. 缺陷修补过程中需要适当地更新CR状态。同样，在生命周期的每个阶段需要更新相关CR信息
。

6. 根据CR优先级进行缺陷修补问题的分析。

7. 作为分析阶段的第一步，缺陷需要在开发环境或客户的测试环境里再次形成。这可能需要提交缺陷者提供更多的信息
。在这个阶段，如果缺陷被确认为不可重新形成的，同样的缺陷可能被关闭或者分析可能使用跟踪和核心等，他们可能被用来引起一个缺陷。依赖于业务影响，有些缺陷可以在不能被重新构造的情况下修补。

8. 如果缺陷被成功地复制，那么单元测试也相应地将被增进
。然后测试缺陷的用例将组合到回归测试中

，如果存在，和测试计划一致
。

9. 每一个缺陷修补可能不会导致一个补丁。通常一个补丁用来修补一段时间内积累的多个缺陷
。但是有时 (一个热点修补)一个补丁可能只修补一个缺陷。当一个修补被捆绑到一个完成的产品版本后
，项目管理生命周期的版本发布阶段应随之开始。