生命周期模型指南

CMMI生命周期模型变更记录修改点说明的内容有如下几种：创建、修改（+修改说明）、删除（+删除说明）目录1前言 (5)1.1目的 (5)1.2适用范围 (5)1.3术语 (5)2带回溯的瀑布模型 (5)2.1项目策划 (6)2.2需求分析（需求开发） (8)2.3概要设计 (9)2.4详细设计 (9)2.5编码和单元测试 (10)2.6软件集成和集成测试 (11)2.7系统测试 (12)2.8验收和安装 (13)2.9裁剪指南 (13)3USDP生命周期模型 (14)3.1初始阶段 (15)3.2细化阶段 (17)3.3构造阶段 (18)3.4移交阶段 (20)3.5裁剪指南 (21)4原型法 (21)4.1项目策划 (24)4.2需求分析 (26)4.3快速设计 (27)4.4原型评价 (27)4.5最终系统设计 (28)4.6最终系统实现 (30)4.7验收和部署 (31)4.8裁剪指南 (32)5其他生命周期模型 (32)5.1螺旋模型 (32)5.2增量模型 (33)5.3RAD模型 (34)6生命周期模型选择指南 (35)1 前言软件生命周期是指软件产品或软件系统从产生、投入使用到被淘汰的全过程。

在计算机技术发展的初期，人们把软件开发简单地理解为编写程序。

随着软件复杂性的增长，人们认识到软件开发活动应划分为需求分析、设计、实现、测试等若干个活动，并将这些活动以适当的方式分配到不同的阶段中去完成。

软件生命周期模型是描述软件开发全部过程、活动和任务的结构框架。

比较常见的软件生命周期模型是瀑布模型、增量模型、原型模型和螺旋模型等。

1.1 目的本文档规定了公司适用的软件生命周期模型，作为项目经理在制定项目计划时根据项目特点确定采用何种开发过程的依据。

1.2 适用范围本文档适用于公司的所有软件项目。

1.3 术语CMMI 能力成熟度模型集成PP 项目计划PMC 项目监控PPQA 过程和产品质量保证CM 配置管理SOW 工作说明书WBS 工作分解结构SRS 软件需求规格说明书2 带回溯的瀑布模型带回溯的瀑布模型是最常用的软件开发模型，它的各个阶段是按线性序列组织并可以回溯到上一级，克服了标准瀑布模型缺乏灵活性的缺点。

开发过程中的阶段划分为项目策划、需求分析、概要设计、详细设计、编码和单元测试、软件集成和集成测试、系统测试、验收和安装等（图1）。

尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行的，阶段间的依赖性由入口准则来确定。

带回溯的瀑布模型的每个阶段均具有以下特征：●从上一阶段接受本阶段工作的对象，作为输入；●对上述输入实施本阶段的活动；●给出本阶段的工作成果，作为输出传入下一阶段；●对本阶段工作进行评审，如果本阶段工作得到确认，那么继续下阶段工作，否则返回前一阶段，甚至更前阶段。

●本阶段可以回溯至上一阶段，并可以逐级向上回溯。

●各阶段之间可以有重叠。

瀑布模型为软件开发与维护提供了一种有效的管理模式，根据这一管理模式制订开发计划、进行成本预算、组织开发人员，以阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品的质量。

优点：适用于需求稳定，且无其它不确定因素；易于理解和使用；每个阶段的产出物形成稳定的基线；变更被认为很少发生或是严格受控的。

缺点：对于需求不稳定或存在其它不确定因素的项目适用性差，变更实现困难且成本高；一般在最后阶段才能看到产品。

2.1 项目策划项目策划是每个项目的初始阶段，目的是为开发过程和过程管理做好必要的准备。

项目策划的主要工作是进行可行性分析和研究，进行估计和制定管理项目的计划。

2.2 需求分析（需求开发）需求分析阶段的主要目的是生成一个正确说明客户所有需求的文档。

软件需求规格说明书（SRS）是该阶段的主要输出。

需求分析的主要工作是需求提炼及分析、需求归档和需求评审等。

需求分析阶段执行的活动主要集中在两个领域：问题分析和产品描述。

问题分析活动分准备、采集需求和分析等，而产品描述活动分准备SRS和评审SRS等。

策划”阶段完成，也可以横跨“项目策划”和“需求开发”阶段。

2.3 概要设计概要设计阶段是从实现的角度开发针对客户需求的解决方案。

在这个阶段给出的是高级的抽象方案，这个方案包含两个主要部分，即应用的功能体系结构和数据库设计。

设计阶段的第一项工作是，细化“设计”“编码和单元测试”阶段的计划。

2.4 详细设计在详细设计阶段，概要设计阶段开发的整体应用被分成几个模块和程序。

为每个程序进行逻辑设计，然后归档作为程序规格。

同时，为每个程序生成一个单元测试计划。

详细设计阶段的活动包括通用例程和程序的确定（如数据有效性例程、框架程序的开发及用于提高生产率的实用程序和工具的开发）。

2.5 编码和单元测试在编码阶段，根据详细设计用编程语言和合适的编码规范产生源代码、可执行代码和数据库。

这个阶段的输出是随后测试和验证的主体。

2.6 软件集成和集成测试软件集成是把设计阶段制定的，已通过单元测试的模块构建成一个完整的软件结构的系统方法。

在该阶段，同时要进行集成测试，以发现和接口相关的缺陷。

集成按集成计划中制定的顺序进行，并执行每个集成阶段的相应测试用例。

2.7 系统测试系统测试是依据需求规格说明书验证软件产品有效性的活动。

这个阶段是为了发现那些只有通过测试整个系统才能暴露的缺陷，像外部接口、性能、安全和可靠性等只有在这个阶段才能判断其是否有效。

2.8 验收和安装在验收和安装阶段，软件产品被集成到它的操作环境中，并在这个环境中经受测试，以确保它按需求执行。

这个阶段包括两个基本任务：使软件得以验收和在客户处安装。

验收指的是用户根据早期准备的验收测试计划而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。

当分析结果满足验收准则时，用户接受软件。

安装指的是把接受的软件置于实际的产品环境中。

2.9 裁剪指南在实际的使用过程中，根据软件项目的特点可以对瀑布模型进行裁剪。

一般而言，以下几种裁剪是经常存在的，只要EPG同意即可：●概要设计阶段、详细设计阶段合并成一个阶段，称为设计阶段。

活动和工作产品也作相应合并；●软件集成和集成测试、系统测试阶段合并成一个阶段，称为测试阶段。

活动和工作产品也作相应合并；●项目策划阶段并入需求分析阶段。

前提是该阶段前期，制定一个粗略的项目整体计划和当前阶段的详细计划，并且在该阶段后期，制定出相对比较实用的项目整体计划。

●根据项目的人员配置情况，在有替代的活动来验证相应工作产品的可测试性时，测试计划和测试用例的编制时间可以适当的后延。

不过，必须确保测试计划和测试用例经过有效的评审以后，才可以开始实际的测试活动。

根据项目需要，在经EPG审核并获得高层经理的批准下，也可对瀑布模型做出其他方式的裁剪。

3 USDP 生命周期模型从概括上讲，统一软件开发过程（USDP ）把生命周期分为两个阶段：工程阶段和生产阶段（如图 3-1）。

工程阶段进行设计和综合活动，它由可预测性小、规模也比较小的群组所驾驭；生产阶段进行构造、测试和实施活动，它由可预测性大、规模也较大的群组所驾驭。

移交阶段构造阶段细化阶段初始阶段生产阶段工程阶段完成产品发布形成初步可运行能力构造构架基线启动项目图 3-1 统一软件开发过程的生命周期示意图仅仅把软件开发过程归结为两个阶段，显得过于简单，也不利于软件开发过程的管理。

为此，我们把工程阶段分解为初始阶段和细化阶段，把生产阶段分解为构造阶段和移交阶段。

在早期的文献中，这四个阶段也被称为：先启、精化、构建和产品化。

● 初始阶段的目标是确定系统的可行性，启动项目；● 细化阶段需要构件一个稳定的构件基线，用于在后续过程中指导系统的开发；● 构造阶段的目标是具有基本的可操作能力，建造出能进行beta 测试的产品；● 移交阶段伴随着Beta 版本的产生而开始，随着正式版本的产生和发布而结束。

为了控制每个阶段项目实施的风险，逐步细化项目的需求，减低软件产品的不确定性，对于每一个阶段的目标，可以通过多次迭代来实现（如图 3-1）。

在USDP 开发过程中，过程活动由9个主要的工作流组成：业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境。

其中，管理工作流主要关心3个规范：计划、项目控制和组织。

在生命周期中，随着项目的进展，这些活动以不同的等级的工作量和重点并发执行。

图 3-2表示一个迭代的工作流。

图 3-3表示生命周期阶段的工作流的分布情况。

图3-2 一个迭代的工作流图3-3生命周期阶段的工作流分布情况3.1 初始阶段初始阶段的基本目标是使项目相关人员对项目目标取得一致。

初始阶段主要对新的开发工作具有重大意义，新工作中的重要业务风险和需求风险问题必须在项目继续进行之前得到解决。

对于重点是扩展现有系统的项目来说，初始阶段较短，但重点仍然是确保项目值得进行而且可以进行。

3.2 细化阶段细化阶段的目标是建立系统构架的基线，以便为构造阶段的主要设计和移交工作提供一个稳定的基础。

构架是基于对大多数重要需求（对系统构架有很大影响的需求）的考虑和风险评估发展而来的。

构架的稳定性是通过一个或多个构架原型进行评估的。

3.3 构造阶段构造阶段的目标是阐明剩余的需求，并基于已建立基线的构架完成系统开发。

构造阶段从某种意义上来说是一个制造过程，在此过程中，重点在于管理资源和控制操作，以便优化成本、进度和质量。

从这种意义上说，从初始和细化阶段到构造和移交阶段，管理上的思维定式经历了从知识产权开发到可部署产品开发的转变。

3.4 移交阶段移交阶段的重点是确保最终用户可以使用软件。

移交阶段可跨越几个迭代，包括测试处于发布准备中的产品和基于用户反馈进行较小的调整。

在生命周期中的该点处，用户反馈应主要侧重于调整产品、配置、安装和可用性问题，所有较大的结构上的问题应该在项目生命周期的早期阶段就已得到解决。

在移交阶段生命周期结束时，目标应该已经实现，项目应处于将结束的状态。

某些情况下，当前生命周期的结束可能是同一产品另一生命周期的开始，从而导致产生产品的下一代或下一版本。

对于其他项目，移交阶段结束时可能就将工件完全交付给第三方，第三方负责已交付系统的操作、维护和扩展。

3.5 裁剪指南多数项目的迭代次数介于4到9次之间。

典型的项目会有以下的6次迭代序列（如图4-1）：●初始阶段的1次迭代：一个构架原型●细化阶段的2次迭代：构架原型和构架基线●构造阶段的2次迭代：alpha版和beta版●移交阶段的1次迭代：产品发布有先例的、且具有一个已定义了的框架项目，或者小规模的项目，可以将初始和细化阶段合并为一个迭代，这样可以只用4次迭代过程的开销有效地生产产品。

一个非常大型或无先例的、拥有众多项目相关人员的项目，可能需要2次初始阶段迭代和4次构造阶段迭代，这样一共是9次迭代。