CMMI

生命周期模型

1.1术语

CMMI  能力成熟度模型集成

PP    项目计划

PMC   项目监控

PPQA   过程和产品质量保证

CM   配置管理

SOW   工作说明书

WBS   工作分解结构

SRS    软件需求规格说明书

2带回溯的瀑布模型

带回溯的瀑布模型是最常用的软件开发模型，它的各个阶段是按线性序列组织并可以回溯到上一级，克服了标准瀑布模型缺乏灵活性的缺点。开发过程中的阶段划分为项目策划、需求分析、概要设计、详细设计、编码和单元测试、软件集成和集成测试、系统测试、验收和安装等（图1）。尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行的，阶段间的依赖性由入口准则来确定。

带回溯的瀑布模型的每个阶段均具有以下特征：

●从上一阶段接受本阶段工作的对象，作为输入；

●对上述输入实施本阶段的活动；

●给出本阶段的工作成果，作为输出传入下一阶段；

●对本阶段工作进行评审，如果本阶段工作得到确认，那么继续下阶段工作，否则返回前一阶段，甚至更前阶段。

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

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

                            图1 瀑布模型

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

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

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

2.1项目启动

建立项目，并且确认相关的项目干系人并且取得相关干系人的关系依赖，做好相关的准备工作和进行对项目的估算，准备项目的任务书和进行项目的启动。

2.2项目计划

项目策划是每个项目的初始阶段，目的是为开发过程和过程管理做好必要的准备。项目策划的主要工作是进行可行性分析和研究，进行估计和制定管理项目的计划。

需求分析阶段的主要目的是生成一个正确说明客户所有需求的文档。软件需求规格说明书（SRS）是该阶段的主要输出。需求分析的主要工作是需求提炼及分析、需求归档和需求评审等。需求分析阶段执行的活动主要集中在两个领域：问题分析和产品描述。问题分析活动分准备、采集需求和分析等，而产品描述活动分准备SRS和评审SRS等。

2.4分析与设计

概要设计阶段是从实现的角度开发针对客户需求的解决方案。在这个阶段给出的是高级的抽象方案，这个方案包含两个主要部分，即应用的功能体系结构和数据库设计。

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

在编码阶段，根据详细设计用编程语言和合适的编码规范产生源代码、可执行代码和数据库。这个阶段的输出是随后测试和验证的主体。

软件集成是把设计阶段制定的，已通过单元测试的模块构建成一个完整的软件结构的系统方法。在该阶段，同时要进行集成测试，以发现和接口相关的缺陷。集成按集成计划中制定的顺序进行，并执行每个集成阶段的相应测试用例。

系统测试是依据需求规格说明书验证软件产品有效性的活动。这个阶段是为了发现那些只有通过测试整个系统才能暴露的缺陷，像外部接口、性能、安全和可靠性等只有在这个阶段才能判断其是否有效。

在验收和安装阶段，软件产品被集成到它的操作环境中，并在这个环境中经受测试，以确保它按需求执行。这个阶段包括两个基本任务：使软件得以验收和在客户处安装。验收指的是用户根据早期准备的验收测试计划而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。当分析结果满足验收准则时，用户接受软件。安装指的是把接受的软件置于实际的产品环境中。

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

下几种裁剪是经常存在的，只要EPG同意即可：

●概要设计阶段、详细设计阶段合并成一个阶段，称为设计阶段。活动和工作产品也作相应合并；

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

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

●根据项目的人员配置情况，在有替代的活动来验证相应工作产品的可测试性时，测试计划和测试用例的编制时间可以适当的后延。不过，必须确保测试计划和测试用例经过有效的评审以后，才可以开始实际的测试活动。

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

3迭代生命周期模型

从概括上讲，统一软件开发过程（USDP）把生命周期分为两个阶段：工程阶段和生产阶段（如图 31）。工程阶段进行设计和综合活动，它由可预测性小、规模也比较小的群组所驾驭；生产阶段进行构造、测试和实施活动，它由可预测性大、规模也较大的群组所驾驭。

图 31 统一软件开发过程的生命周期示意图

仅仅把软件开发过程归结为两个阶段，显得过于简单，也不利于软件开发过程的管理。为此，我们把工程阶段分解为初始阶段和细化阶段，把生产阶段分解为构造阶段和移交阶段。在早期的文献中，这四个阶段也被称为：先启、精化、构建和产品化。

●初始阶段的目标是确定系统的可行性，启动项目；

●细化阶段需要构件一个稳定的构件基线，用于在后续过程中指导系统的开发；

●构造阶段的目标是具有基本的可操作能力，建造出能进行beta测试的产品；

●移交阶段伴随着Beta版本的产生而开始，随着正式版本的产生和发布而结束。

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

在USDP开发过程中，过程活动由9个主要的工作流组成：业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境。其中，管理工作流主要关心3个规范：计划、项目控制和组织。在生命周期中，随着项目的进展，这些活动以不同的等级的工作量和重点并发执行。图 32表示一个迭代的工作流。图 33表示生命周期阶段的工作流的分布情况。

图 32 一个迭代的工作流

图 33生命周期阶段的工作流分布情况

3.1初始阶段

初始阶段的基本目标是使项目相关人员对项目目标取得一致。初始阶段主要对新的开发工作具有重大意义，新工作中的重要业务风险和需求风险问题必须在项目继续进行之前得到解决。对于重点是扩展现有系统的项目来说，初始阶段较短，但重点仍然是确保项目值得进行而且可以进行。

细化阶段的目标是建立系统构架的基线，以便为构造阶段的主要设计和移交工作提供一个稳定的基础。构架是基于对大多数重要需求（对系统构架有很大影响的需求）的考虑和风险评估发展而来的。构架的稳定性是通过一个或多个构架原型进行评估的。

构造阶段的目标是阐明剩余的需求，并基于已建立基线的构架完成系统开发。构造阶段从某种意义上来说是一个制造过程，在此过程中，重点在于管理资源和控制操作，以便优化成本、进度和质量。从这种意义上说，从初始和细化阶段到构造和移交阶段，管理上的思维定式经历了从知识产权开发到可部署产品开发的转变。

移交阶段的重点是确保最终用户可以使用软件。移交阶段可跨越几个迭代，包括测试处于发布准备中的产品和基于用户反馈进行较小的调整。在生命周期中的该点处，用户反馈应主要侧重于调整产品、配置、安装和可用性问题，所有较大的结构上的问题应该在项目生命周期的早期阶段就已得到解决。 

在移交阶段生命周期结束时，目标应该已经实现，项目应处于将结束的状态。某些情况下，当前生命周期的结束可能是同一产品另一生命周期的开始，从而导致产生产品的下一代或下一版本。对于其他项目，移交阶段结束时可能就将工件完全交付给第三方，第三方负责已交付系统的操作、维护和扩展。

多数项目的迭代次数介于4到9次之间。典型的项目会有以下的6次迭代序列（如图4-1）：

●初始阶段的1次迭代：一个构架原型

●细化阶段的2次迭代：构架原型和构架基线

●构造阶段的2次迭代：alpha版和beta版

●移交阶段的1次迭代：产品发布

有先例的、且具有一个已定义了的框架项目，或者小规模的项目，可以将初始和细化阶段合并为一个迭代，这样可以只用4次迭代过程的开销有效地生产产品。一个非常大型或无先例的、拥有众多项目相关人员的项目，可能需要2次初始阶段迭代和4次构造阶段迭代，这样一共是9次迭代。

对于一些特殊的软件项目，可以根据实际需要，增加或者减少迭代次数。

4原型法

原型模型的使用一般从需求采集开始，开发者和客户一起定义软件的总体目标，标识出已知需求并规划出进一步定义的范围。然后是进行快速设计，快速设计集中于软件中那些对客户可见部分的表示（如输入方式和输出格式）。快速设计导致原型的建造。原型由客户进行评价，并进一步精化待开发的软件需求。逐步调整原型使其满足客户的要求，同时也使开发者对将要做的事情有更好的理解，这个过程是迭代的。

原型法的出现及其应用，主要基于软件开发过程中的几个特点：

并非所有需求都能预先定义：正确的需求定义是系统成功的关键。预先定义的策略假设不经过在系统上实践的过程，用户就能预先精确地提出所有的系统需求，但是大多数情况下，用户对其目标和需求只有模糊笼统的认识，许多细节说不清楚。

项目参加者之间存在通信障碍：大型软件的开发有一个队伍：系统分析员、系统设计员、软件工程师、硬件工程师、用户等。由于各自的文化层次、所处的环境等不同，给各方的交流带来障碍。

有快速建造原型的工具：通用的超高级语言是基本的工具，还有一些常见的软件工具，以及能把某种形式的需求说明转变为可执行程序的专用工具。

在获取一组基本的需求定义后，利用高级软件工具和开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改的过程，应用系统的“最初版本”就逐步演变为系统的“最终版本”。 

在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括那些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产品。 

在演示原型期间，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发者重新定义需求。该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。在这期间，用户和开发者都不要为程序算法或设计技巧等枝节问题分心，而是要确定开发者是否理解了用户的意思，同时试验实现它们的若干方法。 

有了满意的系统原型，同时也积累了使用原型的经验，用户常会提出新目标，从而进一步重新原型周期。新目标的范围要比修改或补充不满意的原型大。

图 41原型模型

软件原型是软件的最初版本，以最少的费用、最短的时间开发出的、以反映最后软件的主要特征的系统。它具有以下特征： 

A、它是一个可实际运行的系统；

B、它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用）；另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其中（每一版本扔掉一点，增加一点，逐步完善至最终产品）；

C、从需求分析到最终产品都可作原型，即可为不同目标作原型；

D、它必须快速、廉价；

E、它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。

原型模型在克服瀑布模型缺点、减少由于软件需求不明确给开发工作带来风险方面，确有显著效果。

软件系统的原型法有多种形式：

●丢弃型——原型开发之后，已获取了更为清晰的需求信息，原型无需保留而废弃；

●演示型——开发原型仅以演示为目标；

●样品型——原型规模与最终产品相同，只是原型仅供研究用；

●增长式演式型——原型作为软件最终产品的一部分，可以满足用户的部分需求，进一步在此基础上开发，则可增加需求，实现后再交付使用；

●粗陋型——用较短时间开发的简易原型。

软件系统的原型法的评价：

●优点

A、原型法在得到良好的需求定义上比传统生存周期法好得多，可处理模糊需求，开发者和用户可充分通信；

B、原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程；

C、原型给用户以机会更改心中原先设想的、不尽合理的最终系统；

D、原型可低风险开发柔性较大的计算机系统；

E、原型增加使系统更易维护、对用户更友好的机会；

F、原型使总的开发费用降低，时间缩短。  

●缺点

A、“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型；

B、原型迭代不收敛于开发者预先的目标。即每次更改，为了消除错误，次要部分越来越大，“淹没”了主要部分；

C、原型过快收敛于需求集合，而忽略了一些基本点；

D、资源规划和管理较为困难，随时更新文档也带来麻烦；

E、长期在原型环境上开发，只注意得到满意的原型，容易“遗忘”用户环境和原型环境的差异。

软件系统原型法适用范围：客户能提出一般性的目标，但不能标出详细的输入、处理及输出需求；或开发者不能确定算法的有效性、操作系统的适应性及人机交互的形式。

●适合

A、特别适用需求分析与定义规格说明 ；

B、设计人机界面；

C、充作同步培训工具；

D、“一次性”的应用；

E、低风险引入新技术

●不适合

F、嵌入式软件的开发；

G、实时控制软件的开发；

H、科技数值计算软件的开发

4.1项目策划

项目策划是每个项目的初始阶段，目的是为开发过程和过程管理做好必要的准备。项目策划的主要工作是进行可行性分析和研究，进行估计和制定管理项目的计划。

需求分析阶段的主要目的是生成一个正确说明客户所有需求的文档。软件需求规格说明书（SRS）是该阶段的主要输出。需求分析的主要工作是需求提炼及分析、需求归档和需求评审等。需求分析阶段执行的活动主要集中在两个领域：问题分析和产品描述。问题分析活动分准备、采集需求和分析等，而产品描述活动分准备SRS和评审SRS等。

快速设计是从实现的角度开发针对客户现阶段已经明确的需求的原型实现或改进方案。该方案既包括高级的抽象方案（如应用的功能体系结构和数据库设计），也包括通用例程和程序的确定（如数据有效性例程、框架程序的开发及用于提高生产率的实用程序和工具的开发），但不要求很完善。快速设计的重点在于客户可见部分系统的实现方式，如系统与用户的人机交互的界面部分。

最终系统设计是在经过前阶段的需求分析、快速设计和原型评价后，整个系统目标已经确定，需求已经明确，并形成了完整的用户需求规格说明书（SRS），开始从整体的角度对系统进行设计，也就是整合并完善前期的快速设计，补充底层的关键技术的设计。

最终系统实现阶段是根据最终设计用编程语言和合适的编码规范产生源代码、可执行代码和数据库。这个阶段的输出是随后测试和验证的主体。

在验收和部署阶段，软件产品被集成到它的操作环境中，并在这个环境中经受测试，以确保它按需求执行。这个阶段包括两个基本任务：使软件得以验收和在客户处安装。验收指的是用户根据早期准备的验收测试计划而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。当分析结果满足验收准则时，用户接受软件。部署指的是把接受的软件置于实际的产品环境中。

在实际的使用过程中，根据软件项目的特点可以对原型法进行裁剪。一般而言，以下几种裁剪是经常存在的，只要PPQA工程师同意即可：

●采用原型法时项目策划阶段的相关输出可以不十分准确和全面，等到原型DEMO通过用户认可后再重新界定项目范围和内容；

●最终设计阶段根据项目的实际情况和规模可以细化为概要设计阶段和详细设计阶段，细化后的活动和出入口准则可以参考瀑布模型的相关阶段；

●如果采用增长式原型，则系统的最终设计和最终实现可以省略。系统的开发过程变成了一边开发，一边试用，然后修正，如此反复，直到用户满意。

根据项目需要，在高层经理的批准下，也可对原型模型做出其他方式的裁剪。

5敏捷生命周期模型

5.1模型介绍

敏捷方法是一种以人为核心、迭代、循序渐进的开发方法，适用于一开始并没有或不能完整地确定出需求和范围的项目，或者需要应对快速变化的环境，或者需求和范围难以事先确定，或者能够以有利于干系人的方式定义较小的增量改进

5.2开发方式

主要的敏捷方法有极限编程（eXtreme Programming，XP）、自适应软件开发（Adaptive Software Development，ASD）、水晶方法（Crystal）、特性驱动开发（Feature Driven Development，FDD）、动态系统开发方法（Dynamic Systems DevelopmentMethod，DSDM）测试驱动开发（Test-DrivenDevelopment，TDD）、敏捷数据库技术（AgileDatabase Techniques，AD）和精益软件开发（LeanSoftware Development）和Scrum等。虽然这些过程模型在实践上有差异，但都是遵循了敏捷宣言或者是敏捷联盟所定义的基本原则

5.3认知角度

在敏捷方法中，从开发者的角度来看，主要的关注点有短平快的会议、小版本发布、较少的文档、合作为重、客户直接参与、自动化测试、适应性计划调整和结对编程；从管理者的角度来看，主要的关注点有测试驱动开发、持续集成和重构。

5.4使用场景

与RUP/UP相比，敏捷方法的周期可能更短。敏捷方法在几周或几个月的时间内完成相对较小的功能，强调的是能尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强，并且更加强调团队中的高度协作。相对而言，敏捷方法主要适用于以下场合：（1）项目团队的人数不能太多，适合于规模较小的项目。（2）项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合。（3）高风险项目的实施。 （4）从组织结构的角度看，组织结构的文化、人员、沟通性决定了敏捷方法是否适用。与这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但是精干、开发人员所作的决定得到认可、环境设施满足团队成员之间快速沟通的需要

6其他生命周期模型

6.1螺旋模型

参螺旋模型是将瀑布模型与进化模型相结合，并增加了两者所忽略的风险分析。它将软件项目开发分别划分为四类活动, 沿着螺线旋转，在笛卡儿坐标的四个象限上分别表达了四个方面的活动，即：

●制订计划——确定软件目标，选定实施方案，弄清项目开发的条件；

●风险分析——分析所选方案，考虑如何识别和消除风险；

●实施工程——实施软件开发；

●客户评估——评价开发工作，提出修正建议。

沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。

螺旋模型通常用以指导大型软件项目的开发，如果开发风险过大，开发者和客户无法承受，项目有可能因此终止。多数情况下会沿着螺线继续下去，自内向外逐步延伸，最终得到满意的软件。

如果对所开发项目的需求已有了较好的理解或较大的把握，无需开发原型，便可采用普通的瀑布模型。这在螺旋模型中可认为是单圈螺线。与此相反，如果对所开发项目的需求理解较差，需要开发原型，甚至需要不止一个原型的帮助，那就要经历多圈螺线。在这种情况下，外圈的开发包含了更多的活动。也可能某些开发采用了不同的模型。

和其它模型相比螺旋模型的优越性较为明显，但要求许多客户接受和相信进化方法并不容易。本模型的使用需要具有相当丰富的风险评估经验和专门知识。如果项目风险较大，又未能及时发现，势必造成重大损失。

图3  螺旋模型

6.2增量模型

增量模型融合了瀑布模型的基本成分和原型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。每一个增量的处理流程均可以采用原型模型。在使用增量模型时，第一个增量往往是核心产品，以后每次交付可使用的部分功能，每次交付包含前一次交付的功能和一些新功能，最后一次交付一个完整的系统。增量模型适用于业务高速发展的用户应用系统。使用该模型时，首次交付的内容通常完成了最基本的需求，其它需求通过交付内容的使用情况和评价来制定下一次交付内容的开发计划，此过程不断重复，直到满足整个系统需求。这种模型适用于需求逐渐清晰的软件项目。

4 增量模型

6.3RAD模型

快速应用开发模型（RAD模型）是瀑布模型的一个“高速”变种，强调极短的开发周期。通过使用基于构件的建造方法获得快速开发。如果需求理解的好，且约束了项目范围，RAD过程使得项目组能够在很短时间内（如60到90天）创建出功能完善的系统。

RAD主要用于信息系统应用软件的开发，它包含如下几个开发阶段：

●业务建模：业务活动中的信息流被模型化，以回答如下的问题：什么信息驱动业务流程？生成什么信息？谁生成信息？该信息流往何处？谁处理它？

●数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需要的数据对象。标识出每个对象的特征，并定义这些对象之间的关系。

●处理建模：数据建模阶段定义的数据对象变换成为要完成一个业务功能所需的信息流。创建处理描述以便增加、修改、删除或获取某个数据对象。

●应用生成：RAD是复用已有的程序构件（如果可能的话）或是创建可复用的构件（如果需要的话）来创建软件。

●测试及反复：由于RAD过程强调复用，许多程序构件已经是测试过的，这样就减少了测试时间。但新的构件必须测试，所有接口也必须测试到。

RAD方法的缺陷是：

●对于大型的、但可伸缩的项目，RAD需要足够的人力资源以创建足够多的RAD组。

●RAD要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统，如果两方中的任何一方没有完成约定，都会导致RAD项目的失败。

RAD方法并不适用于所有的应用软件的开发。如果一个系统难以被适当地模块化，那么建造所需要的构件就会有问题。如果高性能是一个指标，且该指标必须通过调整接口使其适当应系统构件才能赢得，RAD方法就可以失败。此外，RAD方法不适合技术风险很高的情况，当一个应用需要采用很多新技术，或者当新软件要求与已有计算机程序有很高的互操作性时，RAD方法就不适用。

7生命周期模型选择指南

在选择软件生命周期模型的时候，需要考虑以下因素：

●项目需求清晰性、完整性、稳定性

●项目规模

●项目类型

●软件系统复杂度

●项目用到的新技术

●项目成员的技能

●其它因素。

本文提到的三种主要的软件开发生命周期模型的选择可以参照下表（表格 61）。表格中列出的是典型情况，在实际工作中，需要根据实际情况进行权衡。

表格 61中“指标较好”含义是指：就项目需求清晰性、项目需求完整性、项目需求稳定性而言，指标为“高”时较好；就系统复杂度、新技术应用而言，指标为“小”或“少”时较好。下载本文