软件成熟度国军标GJB5000A

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

GJB5000A-2008 军用软件研制能力成熟度模型概述

谢新华

中科院计算所培训中心

2010 年 8 月北京

http://www.tcic.cn

1

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

目录

第一节 GJB-5000A能力成熟度基本概念 .......................................................................................... 3

1.1 软件过程的基本概念 ........................................................................................................ 3 1.2 能力成熟度模型的基本概念 ............................................................................................ 5 1.3军用软件研制能力成熟度模型框架 ................................................................................. 7 1.4 理解成熟度等级 .............................................................................................................. 10 1.5 共用目标和共用实践 ...................................................................................................... 11 1.6 善于书写良好的文档 ...................................................................................................... 13

第二节 过程域的基本框架 ................................................................................................................. 16

2.1 过程域部件 ...................................................................................................................... 16

2.2 过程管理类过程域之间的关系 ...................................................................................... 18 2.3 项目管理类过程域之间的关系 ...................................................................................... 19 2.4 工程类过程域之间的关系 .............................................................................................. 21 2.5 支持类过程域之间的关系 .............................................................................................. 25

第三节 已管理级成熟度的过程域 ..................................................................................................... 27

3.1项目策划（PP）过程域................................................................................................... 27

3.2 项目监控（PMC）过程域 ............................................................................................. 33 3.3测量与分析（MA）过程域 ............................................................................................. 39 3.4配置管理（CM）过程域 ................................................................................................. 43 3.5过程和产品质量保证（PPQA）过程域 ......................................................................... 47 3.6需求管理（ReqM）过程域 ............................................................................................. 52 3.7供方协议管理（SAM）过程域 ...................................................................................... 55

第四节过程改进计划 ............................................................................................................................. 62 结语 ........................................................................................................................................................ 63

http://www.tcic.cn

2

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

第一节 GJB-5000A能力成熟度基本概念

1.1 软件过程的基本概念

一个大型软件项目要成功，很大程度上依赖于正确而且合适的软件过程，首先的问题是什么 是软件过程呢？

1，软件过程的定义与概念

1）过程的定义 系统从一个状态（始态）变成另一个状态（终态），我们就说：发生了一个过程（Process）。

过程是一种手段，通过该手段可以把人、方法与规程、技术与工具进行集成，以产生一种所期望 的结果。

换句话说，过程就是人们使用相应的方法、规程、技术、工具等将原始材料（输入）转化成 用户需要的产品（输出）。过程与产品存在因果关系。即好的过程才能得到好的产品，而差的过 程只会得到差的产品。

2）过程的特征 任何过程都应该具备8 个特征：

? 任何一个过程都有输入和输出；

? 输入是实施过程的基础、前提和条件； ? 输出是完成过程的结果；

? 输出可能是有形产品，也可能是无形产品，如软件或服务； ? 过程本身是增值转换，不增值的过程没有意思；

? 完成过程必须投入适当的资源和活动，是换取过程增值或结果有效的代价 ? 过程存在可测量点；

? 所有的工作和活动都是通过过程来完成的。 若干目的上相互关联的过程系统,我们称之为过程域，广义的软件过程包括管理过程和生产 过程。主要的软件过程域如下：

? 工程类的主要过程域：需求开发、系统设计、软件实现、软件测试、软件维护等等； ? 管理类的主要过程域：项目规划、项目监控、需求管理、质量管理、配置管理等等。 上述过程域中的任何活动都会影响产品的质量、生产率和成本。

3）软件过程能力 软件过程能力描述通过遵循软件过程能够实现预期结果的程度。一个组织的软件过程能力提

供一种预测该组织承担下一个软件项目时最可能的预期结果的方法。软件过程性能表示遵循软件 过程所得到的实际结果。所以，软件过程性能关注已得到的结果，而软件过程能力则关注预期结 果。由于一个特定项目的属性和执行该项目的环境所限，该项目的实际性能可能并不充分反映组 织的整个过程能力，即项目的能力受限于它的环境。

http://www.tcic.cn

3

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

2，为什么要加强管理与过程能力呢？ 一个组织的成熟首先是从要强管理开始的。很多人尽管在口头上不得不承认，但内心里还是

认为只要我有了好的技术，照样能把产品做出来，但这不一样。 过去一谈创新往往想到的就是

技术创新，但仅仅有技术创新是不够的，我们还必须关注管理

创新和应用创新，没有这个层面的创新思想，就没有办法把技术手段转化为真正有用的东西，更 没有办法创造影响人类社会进程的伟大产品。

如果我们仅仅是做一个纸飞机，那我们就没有必要写下详细计划（花 20 分钟写计划再花 20 秒把飞机折出来，无疑是个愚蠢行为），你可以快速的修改，即使返工也是经济和高效的。但是， 如果你是制造一家大型客机，那么用纸飞机的方法来实现同样也是愚蠢的，如果没有详细的前期 设计，没有严密的管理，那整个飞机制造过程就是一个漫长、混乱和昂贵的过程。它将产生大量 应该避免的返工，甚至永远不可能完成，如下图所示。

为了加强管理与过程能力，现代软件工程学提供了一系列方法，包括： 1）基于工程规范的大型软件系统开发 由于大型项目的组件未必是同一个机构生产的，所以需要建立一些系统工程原则，来协调需

要精确协同工作的组件的开发。

2）引入标准和过程规范 为了解决这个问题，美国国防部开发了一系列的指导文档，为软件开发提供符合系统工程的

标准方法，这些规范和标准有如下特征：

? 重视定义良好的工作产品、验证和确认：软件系统工程认为，从需求到代码的过程中，

计划驱动的方法非常精确的依赖于明确的步骤，其中每个步骤中文档的完备性非常重 要，这种完备性可以保证每个步骤可验证，文档是可跟踪性的重要保证。 ?产品规范与过程定义和改进具有同等的联系：软件作为一种产品，其可塑性使过程需 要

经过多次改进，正因为如此，过程需要进行定义、标准化并需要逐步改进以提供对项 目的有效控制。

?过程提供可预见性、可重复性和基础设施的支持来缓解人员流动问题：标准化所带来 的

可比较和可重复性，使组织中的人都知道在哪里找信息，以及如何评估日常工作。这 种过程的一致性可以使管理人员在项目之间调动人员而不必要重新培训，也意味着关键 人员的的流失不再是项目的厄运。

3）项目越复杂，规范的意义就越重要 项目越复杂，规范的意义就愈重要。在一些非常大的项目中，很多人试图避开这个过程，结

果大多数都失败了。大量实践表明，规范方法尽管在管理上的成本提高了，但远远比不遵从这些 方法（游击队似的疯狂开发）更经济有效，因为它减少了意外和返工的工作量。更重要的是，它 可以保证每个人都知道自己该干什么事情，确保组织运转成为可能。严格的基线和工作产品的静 态测试，帮助人们提高了整体质量，并有助于人们尽早发现更多的缺陷。

http://www.tcic.cn

4

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

如果没有计划和规范，那一定是混乱和不一致的。尽管某些局部可能成功，但整体上可能永 远也不会完成，所带来的管理成本可能更高。管理层所做的事情可能就是周而复始的协调、协调、 再协调，这无疑是管理上的一场噩梦。

正确的规范化并不会抑止人们的创造力，相反它使得团队可以大规模地复用前人积累的智慧 和财富。这种方法非常适合于现代的工业化生产。 业界实践已经证明，走规范化之路是“成本 最低、见效最快、能持续发展”的软件过程改进方法，

1.2 能力成熟度模型的基本概念

1，能力成熟度（CMM）的历史诱因

软件工程管理引起广泛注意源于20世纪70年代中期，当时人们就发现软件项目的成功率很 低，一直到 20 世纪 90 年代中期，美国有$2,500 亿用于 IT 的 175,000 个软件项目，其中：

31% 在完成前被取消，其费用为$810 亿 53% 的费用是原估计费用的190%

只有 10%的软件项目能够在预定的费用和进度下交付。 美国国防部（DoD）发现，在失败的项目中，70%是因为管理不善而引起。这就是 DoD 建 立 CMU/SEI（卡内基梅隆大学软件工程研究所）的诱因。

CMM 模型在理论上基于 20 世纪 30 年代施瓦特（Walter Shewart）的统计质量控制原理， 已有60 多年历史。德明（Edwards Deming）和朱兰（Joseph Juran）在40 和50 年代发展了这些 原理并在实践中得到了证明，特别是在日本，获得了极大的成功。

20 世纪 70 年代末期，菲利普.克罗斯比（Philip Crosby）把这些原理用于构造成熟度框架， 首次提出五个进化层次。20 世纪 80 年代中期，IBM 在汉弗莱（Watts S. Humphrey）的指导下， 莱德斯（Ron Radice）等人把这个成熟度框架首次用于软件过程。

1986 年，汉弗莱（Humphrey） 把这些成果带到 CMU/SEI，并由他主持研究软件过程成熟 度模型，对这些原理进行了进一步的完善，并于1987 年6 月公布了过程成熟度框架的第一份研 究报告。到1993 年颁布了第一个成熟的版本CMM 1.1。

CMM 模型正在向纵深发展，目前CMM 家族包括： ? 软件能力成熟度模型(SW-CMM)

? 软件获取能力成熟度模型(SA-CMM) ? 人员能力成熟度模型(People-CMM) ? 系统工程能力成熟度模型(SE-CM)

? 集成产品开发能力成熟度模型(IPD-CMM) ? 个体软件过程(PSP)

? 群组软件过程(TSP)等。

? 最近正在试行和推广集成的能力成熟度模型(CMMI)。

2，过程改进的收益 1）过程改进的好处

从上个世纪80 年代到今天，软件工程界广泛推行CMM，获得了如下好处： ? 减少软件开发费用。 ? 提高软件开发生产率。 ? 缩短软件开发周期。 ? 改进软件开发质量。

? 能较好地控制费用和质量，有较好的可预测性。

http://www.tcic.cn

5

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

举例：

根据波音公司 120 个项目的统计，当成熟度由第一级上升到第三级以后，各方面的指标都有 大幅度改善。

SW- CMM 不同等级的可信度

一般来说，根据大部分的统计数据，实施CMM 的结果： ? 生产力约有10%到20%的提升。 ? 产品错误率降低一个数量级。

? 对项目的预估与控制能力提升40%到50%。

3，军用软件能力成熟度模型 正是由于军用软件的敏感性与严肃性，我军总装备部参考了国内外先进经验，根据我国军用

软件研制的实际情况，在2003年发布了GJB5000-2003《军用软件能力成熟度模型》，取得 了显著的成果。根据几年来应用的经验，到 2008 年又发布了改进版GJB 5000A-2008，用以取代 GJB5000-2003。

http://www.tcic.cn

6

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

可以预想，新版“军用软件能力成熟度模型”的推广实施，将对我军信息化建设发挥不可估 量的作用。在应用标准的时候，我们需要注意以下几个问题：

1）循序渐进的改良模式

GJB 5000A-2008 是一个循序渐进的改良模式，一个组织的软件开发由最初的无纪律状态， 逐渐学习到成熟而有制度的境界，是需要经过长期的努力的。国内有些机构以过级为目的，注重 短期效应，只在文档格式上下功夫，这是不可取的，这也是为什么很多企业级别虽然很高，但实 际表现却并没有那么好的根本原因。

GJB 5000A-2008 要求所有软件开发组织的评估一律从二级开始，打好基础逐步提升，这是 非常有道理的。

2）规范的实施 企业制定软件过程规范是为了帮助人们把工作做得更好，而不是存心与人们过不去。企业一

方面要用行政命令和奖罚措施来强制实施软件过程规范，另一方面又要设法使员工们乐于执行规 范从而避免流于形式。

SEPG 不要只是埋头写规范，写完了上缴了事。最好在内部网上开辟一个专栏，专门解释规 范。要对全员进行培训与考试，使机构中的每个人都熟悉与自己工作相关的规范。只有这样才能 防止有人拖后退，使团队发挥最大的力量。

质量保证人员监督实施。人都有惰性，如果没有人来监督员工们按照规范办事，那么自觉性 不强的员工就会回到“无序”的老路上。质量保证人员的职责就是周期性地检查项目成员的“工 作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量以及产品质量”。

SEPG 要及时收集员工们反映的问题和建议，不断地完善规范，但是不能频繁地变更规范的 版本，应当有计划地控制规范的版本。

1.3 军用软件研制能力成熟度模型框架

1，能力成熟度的表示方法

在 GJB 5000A-2008 中，把成熟度定义为五个等级，包含了 22 个过程域。等级用来描述组 织的进化路径。标准允许组织通过增量处理相继的过程域集合，来改进一组相关的过程。这种改 进路径用“成熟度等级”表示。

它的特点如下。

1）军用软件研制能力成熟度模型结构

http://www.tcic.cn

7

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

根据实践证明正确的过程组合和排序，提供一个预定义的路线图： ? 将过程域组织成2、3、4和5四个成熟度等级 ? 每个成熟度等级包括若干必须的过程域。

? 每个过程域包括若干个专用目标，每个专用目标包含若干个推荐的专用实践（活动），

以达到所期望的目的。

? 对于任何一个过程域，所有相关的共用目标和共用实践，是实现该过程域的不可分割的

整体。

注意，GJB 5000A-2008 中，有两个共同目标，以及相应的共同实践，这些实践保证了过程 域制度化所需要的基本建设与活动。

成熟等级、过程域、目标以及实践的相互关系如下图所示。

2）成熟度的阶梯式表示法 成熟度等级是一个己定义的、组织过程改进的进化台阶。每个成熟度等级表示组织过程的一

个重要部分己经成熟，并为它进入下一个成熟度等级做好准备。根据是否达到与每组己预先定义 过程域相关的专用目标和共用目标来判定是否满足相应的成熟度等级。每个等级构成了过程改进 基础的一个层次，是实现下一个成熟度等级的基础。

不同等级所包含的过程域如下图所示，这就是成熟度的阶梯式表示法。

http://www.tcic.cn

8

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

2）成熟度的连续式表示法： 软件开发一般包括过程管理、项目管理、工程和支持四个职能部分，可以把这些过程分布到

这四个部分中去，这就是成熟度的连续式表示方法，如下图所示。

在一个部分中，某些实践可能处于较低的能力等级，某些实践可能处于较高的能力等级，这 就为组织选择那些需要强调实现的过程提供最大的柔性。

GJB 5000A-2008 标准提供了一个从成熟度等级 l 到成熟度等级 5 的预先定义的改进路径， 例如，在成熟度等级 2 ，有一组过程域，组织在能够达到这些过程域的所有目标之前，可以应 用这些过程域来指导其过程改进。一旦组织通过这种方法达到了成熟度等级 2 ，该组织应将其 工作重点放在成熟度等级 3 的过程域上，以此类推。 在评估过程中，等级还可以用来判定活动

的结果。评估既可适用于整个（通常是小）组织，

也可适用于组织内较小的组（例如，项目组或组织中的某个部门）。 等级也描述了改进的特征，

这种改进从一个不良定义的状态改进到另一个状态，等级使用定

量信息来确定和管理所需的改进，以满足组织的业务目标。 要达到某个特定的等级，组织必须满

足预定改进的过程域或者过程域的所有目标。这个标准 还提供了为满足业务目标而实施过程改进的方法。

注意，GJB 5000A-2008 标准关注的是组织的整体成熟度，某个单一过程是已经实施了还是

http://www.tcic.cn

9

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

不完备，这一点并不是主要的关注点。标准把“初始级”作为成熟度模型的起点。成熟度等级可 用于基准对比、供方选择、合同项目监督、评估和评价活动。

1.4 理解成熟度等级

1，初始级， 过程通常都是随意、无序的。组织通常不提供支持过程的稳定环境。在这些组织中，成功依

赖于其中人员的能力和勤奋，而不依赖于使用已经证实的过程。尽管是这种随意、无序的环境， 组织常常仍能生产可用的产品，提供可接受的服务；不过，他们经常超出其项目的预算和进度。

成熟度等级 1 的组织的主要特征是过分承诺，在遇到困难时会放弃过程，并且不能重复他 们以往的成功。

2，已管理级 组织的项目已确保其过程按照方针进行策划并得到执行。这些项目聘用有专业技能的人员，

这些人员拥有足够的资源，以便产生受到控制的工作产品；这些项目吸纳利益相关方；这些项目 都受到监督、控制和评审；这些项目都受到评价，以保证符合其过程说明。

成熟度等级 2 反映的过程纪律有助于确保在有压力的情况下保持现有的实践。在这些实践 都到位的情况下，项目都能按照其文档化的计划进行实施和管理。

在成熟度等级 2 ，工作产品的状态和服务的交付在己定义的时间点（例如，在主要里程碑 和主要任务完成时）对管理者是可见的。在利益相关方之间建立承诺并在需要时进行修订。工作 产品受到适当的控制。工作产品和服务满足其已定义过程的说明、标准和规程。

3，已定义级 过程己经得到了很好的定义和理解，并用标准、规程、工具和方法进行了描述。作为成熟度

等级 3 的基础，组织的标准过程集己经建立，并随着时间的推移而不断改进。这些标准过程用 于建立整个组织的一致性。项目按照剪裁指南剪裁组织的标准过程集，以建立项目的己定义过程。

成熟度等级 2 和成熟度等级 3 的关键区别是标准、过程说明和规程的适用范围。在成熟度 等级 2 , 这些标准、过程说明和规程在过程的各个特定实例（例如，某个具体项目）之间可以有 很大差别。

在成熟度等级 3 ，一个项目的标准、过程说明和规程都是为了适合具体项目或组织的情况 而从组织的标准过程集甲剪裁出来的，因此，除了剪裁指南所允许的差别之外，这些标准、过程 说明和规程都是一致的。

另一个关键区别是：在成熟度等级 3 ，过程一般描述得比成熟度等级 2 更加严格。一个己 定义过程明确地阐述了其目的、输入、入口准则、活动、角色、测量、验证步骤、输出和出口准 则。

在成熟度等级 3 ，通过对过程活动的相互关系、过程的详细测量值、过程的工作产品和服 务的理解，使过程都得到更加积极主动的管理。

在成熟度等级 3 ，组织应使其成熟度等级 2 的过程域得到进一步的成熟。为了达到成熟度 等级 3 ，应使用在成熟度等级 2 中没有阐述的、与共用目标 3 有关的共用实践。

4，已定量管理级 组织和项目为质量和过程绩效建立了定量目标，并将其用作管理过程的准则。这些定量目标

是根据顾客、最终用户、组织和过程实现者的需要建立的。 质量和过程绩效都按统计术语进行

理解并在该过程生存周期间受到管理，对于所选择的子过

http://www.tcic.cn

10

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

说明：

每个高级的项目管理类过程域高度依赖于策划、监控该项目的能力。基本的项目管理类过程 域提供这种能力。

集成项目管理过程域建立和维护从组织的标准过程集剪裁得到的项目的已定义过程。项目使 用己定义过程进行管理，使用组织的过程资产并对其做贡献，按照组织工作环境标准建立和维护 项目工作环境。

项目管理确保项目利益相关方及时协调其工作。项目通过对吸纳利益相关方参与进行管理， 标识、协商和跟踪关键依赖关系，以及在项目内与利益相关方一起解决问题来实现协调。 虽然风险标识和监督包含在项目策划过程域和项目监控过程域中，但风险管理过程域采取持续、 前瞻的方法来管理风险。风险活动包括风险参数标识、风险评估和风险缓解等一系列活动。

定量项目管理过程域应用定量统计技术管理过程绩效和产品质量。项目的质量和过程绩效目 标基于组织建立的对应目标。项目的已定义过程包括部分过程绩效可预测的过程元素和子过程。 必须理解实现项目的质量和过程绩效目标至关重要的子过程所经历的过程变异，一旦标识出过程 变异的特殊原因，就采取纠正措施。

2.4 工程类过程域之间的关系

1，工程类过程域概述 工程类过程域覆盖跨工程学科共同的开发和维护活动、工程类过程域按通用的工程术语编

写，以便在软件产品开发过程中所含的技术学科都可用它们进行过程改进。 工程类过程域还将与各种工程学科相关的过程集成至单个产品开发过程中，支持面向产品的过程 改进策略。这种策略瞄准基本的业务目标，而不是特定的技术学科。这种处理方法有效地避免了 组织的“烟囱”式心理。

工程类过程域： 1）产品集成（PI)； 2）需求开发（RD)； 3）需求管理（ReqM)； 4）技术解决方案（TS)； 5）确认（Val)； 6）验证（Ver）。

http://www.tcic.cn

21

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

下图描述了工程类过程域之间的关系。

说明： 需求开发过程域标识顾客需要并将其转化为产品需求。对产品需求集进行分析，产生一个高

层概念解决方案。随后分配这组需求，以建立产品部件的初始需求集。导出有助于确定产品的其 他需求，并分配给产品部件。这组产品和产品部件需求集使用开发者理解和使用的术语清晰地描 述产品的性能、设计特征、验证要求等等。

需求开发过程域向技术解决方案过程域提供需求，后者将需求转换为产品体系结构、产品部 件设计和产品部件本身（例如，编码和成品）。需求也应用于产品集成过程域，产品集成过程域 将产品部件组装起来，并对产品部件集成接口予以验证以确保接口遵循由需求开发所导出的接口 需求。

需求管理过程域维护需求。它描述获得和控制需求更改的活动、并确保及时保存其他相关的 计划和数据。它保证从顾客到产品，以及到产品部件的需求可追溯性。

需求管理确保需求的更改在项目计划、活动和工作产品中得到反映。需求更改周期可能影响 所有其他工程过程域，于是需求管理是一种动态的且递归的事件序列。需求管理过程域是受控的 而且有纪律的工程设计过程的基础。

技术解决方案过程域开发产品部件的技术数据包，供产品集成过程域或供方协议管理过程域 使用。为选择恰当设计基于所建立准则检查备选方案。这些准则对于不同产品可能有显著差别， 它们取决于产品类型、运行环境、性能要求、支持要求和成本或交付进度。解决方案的最终选择 有赖于决策分析和决定过程域中的专用实践。

技术解决方案过程域依赖验证过程域中的专用实践，在设计期间和最终构造之前实施设计验 证和同行评审。

验证过程域确保所选的工作产品满足指定的需求。验证过程域选择待验证的工作产品和验证 方法，这些验证方法用于按指定的需求验证工作产品。验证一般是增量式过程，通常从产品部件 验证开始，以完全组装好的产品验证截止。

验证还要求同行评审。同行评审是一种在早期排除缺陷的方法，可对正在开发和维护的工作 产品和产品部件进行有价值的深入考察，且其有效性己得到证明。

确认过程域按顾客需求增量式地确认产品。确认可以在运行环境或仿真环境中进行。该过程 域的一个要素是与顾客就确认需求进行协商。

确认过程域的内容涵盖对产品、产品部件、所选中间工作产品和过程的确认。这些已确认的

http://www.tcic.cn

22

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

元素可能经常需要再验证和再确认。确认期间发现的问题通常在需求开发过程域或技术解决方案 过程域中解决。

产品集成过程域包含与创建最佳集成序列、集成产品部件和向顾客交付产品相关的专用实 践。在实施产品集成过程中产品集成使用验证和确认两方面的专用实践。验证过程域的验证实践 在产品集成过程域之前验证产品部件的接口及接口需求。这在集成过程中是基础性事件。在运行 环境中进行产品集成期间，使用确认过程域的专用实践。

2，工程过程的递归与迭代 工程过程存在两种过程实施方式，即递归和迭代。 1）递归式生命周期

递归（也称之为瀑布）发生在将过程应用到系统结构内部的系统元素的相继层次时。每次递 归的结果作为系统结构下一层次的输入。递归生命周期的主要阶段被正式的“门”隔开，这些们 允许定义基线。这是一种在管理上比较简单而且基本的生命周期，适合于需求比较确定的场合。

2）迭代式生命周期 在需求不是十分确定的场合，可以使用迭代生命周期。迭代发生在同一系统层次里重复一个

过程时。一个过程实施时产生新的信息，并被反馈到相关的过程，这些新的信息会提出一些在完 成过程之前必须解决的典型问题。例如迭代很可能会发生在需求开发和技术方案解决之间。过程 的重新应用能够解决所提出的问题。在应用下一个过程之前，迭代可确保阶段产品的质量。

3）增量式生命周期

http://www.tcic.cn

23

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

增量模型是综合了递归模型和原型化的产物，提倡以功能渐增方式开发软件，经验表明，这 种增量模型在特大型项目和小型项目中同样适用。增量模型描述了为系统需求排定优先级然后分 组实现的过程，每个后续版本都为先前版本增加了新功能。

4）在递归框架下的迭代生命周期 在极其复杂的环境下，例如，项目开始之初客户已经有大量的软件系统在运行，新系统需要

与这些老系统兼容，在这个过程中到底会发生什么事情无法预料。这种方法把项目分成若干工程 阶段，每个阶段又分成若干子阶段。

这种方法整体上主要采用递归周期，并且按照惯例分成四个阶段：调查、工程、验收与部署。 对于设计、开发和大部分测试使用了迭代方法。这种在递归过程中融入迭代方法的典型案例，如 下图所示。

我们来解释一下上面的图形。

1）整体上采用规范的递归生命周期:

如前所述，在整体上这个方法采用了递归生命周期，总共分成4 个阶段：

? 调查：在调查阶段，通过分析业确定解决方案的边界。对环境进行彻底的的搜索，这个

阶段的结束时得到了一个工程规划，这个规划确定了接下来的迭代工程周期的结构。 ?工程：工程阶段要执行多次。它遵行“发现、重构、生成和测试”这样一个过程，其中 伴

随着反馈。在这个阶段，对问题描述、解决方案和用于支持解决方案的模式进行增量 的精化。在每次迭代结束以后，需要把前面的估计重新进行修正。

? 验收：此阶段通过完成任何剩余的测试来执行正式的系统验收。重点应该放在验收和操

http://www.tcic.cn

24

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

作测试上。

? 部署：已验收的解决方案被移交给服务交付和应用程序维护人员。开始新解决方案的培

训和教育。此后解决方案开始运行。这个阶段的主要输出包括：应用程序维护移交包、 服务交付移交包。

2）在工程阶段采用迭代生命周期： 在工程阶段被分成很多子阶段（每个子阶段相当于一个迭代周期），每个子过程都具有内置

的迭代反馈机制。工程阶段每个迭代周期的简要描述如下：

? 发现：发现阶段重在寻求额外的信息，也可能会创建或找到额外的模式，以增加开发知

识的深度或广度。

?重构：在重构阶段中，根据“目标”状态与“目前”状态可能的不同，需要对一些模型 进

行重构，以便更好的适应解决方案。同时需要把来自比较早的工程周期的反馈考虑在 内。 生成：应用模式生成解决方案和测试案例，需要识别可以在本地纠正的缺陷或者遗漏的 信息，这些信息也会被反馈到下一个发现阶段。

? 测试：在每次工程迭代中，必须执行测试。通过这样的测试，可以得到一些反馈，以便

纠正遗漏了信息（发现），或者需要更新的视图（重构）。

工程类过程域（例如，需求开发过程域或验证过程域）重复实施于产品，以确保向顾客提供 产品之前这些工程过程已经得到充分应用。此外，工程过程被应用于产品部件。例如，一些由验 证过程域与确认过程域的相关过程引发的问题，可以通过与需求开发过程域和产品集成过程域的 相关过程解决。这些过程的递归和迭代使得项目在向顾客提交产品之前确保其所有部件的质量。

? 2.5 支持类过程域之间的关系

1，支持类过程域概述 支持类过程域包含支持产品开发和维护的活动。支持类过程域阐述在实施其它过程的关联中

使用的过程。一般说来，支持类过程域阐述针对项目的过程，或针对组织的一般应用过程。例如， 过程和产品质最保证可与所有过程域一同用以提供对所有过程域中所描述的过程和工作产品的 客观评价。

支持类过程域如下： 1）配置管理（CM)；

2）过程和产品质量保证（PPQA）； 3）测量与分析（MA)；

4）决策分析和决定（DAR)； 5）原因分析和决定（CAR）。

2，基本的支持类过程域 基本的支持类过程域（配置管理过程域、测量与分析过程域和过程和产品质量保证过程域）

阐述所有过程域共用的基本支持功能。尽管所有支持过程域都依靠其它过程域提供输入、但基本 的支持类过程域提供有助于实施一些共用实践的支持功能，如下图所示。

http://www.tcic.cn

25

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

说明： 测量与分析过程域通过提供专用实践来支持所有过程域，这些实践用能提供客观结果的测量

方法来指导项目和组织调整测量要求和目标。这些客观结果可作为灵活决策和采取适当纠正措施 的依据。过程和产品质量保证过程域提供专用实践来支持所有过程域，这些实践用以对照适当的 过程说明、标准和规程来客观地评价已实施过程、工作产品和服务，并确保这些评价所提出的所 有问题得到解决。过程和产品质量保证通过在项目整个生存周期，向项目成员和各级经理提供对 过程和相关工作产品的适当可视性及反馈意见，从而确保交付高质量的产品和服务。

配置管理过程域通过使用配置标识、配置控制、配置状态记实和配置审核，支持各过程域建 立并维护工作产品的完整性。置于配置管理下的工作产品包括交付给顾客的产品、指定的内部工 作产品、采购的产品、工具、以及用于创建和描述这些工作产品的其它项。可以置于配置管理下 的工作产品的例子，如计划、过程说明、需求、设计数据、图表、产品规格说明、代码、编译程 序、产品数据文件、以及产品技术出版物。

3，高级的支持类过程域 高级的支持类过程域（原因分析和决定过程域和决策分析和决定过程域）向项目和组织提供

高级支持能力。每个高级的支持类过程域都依赖其它过程域的特定输入或实践，如下图所示。

说明： 项目组成员利用原因分析和决定过程域表识所选定的缺陷和其他问题的原因，并采取行动防

止其将来再次出现。而项目的已定义过程是标识缺陷原因的主要对象，其创建的针对组织标准过 程集的过程改进建议书，将防止缺陷在整个组织重现。

决策分析和决定过程域通过确定哪些问题需要采用正式评价过程并实施正式评价过程来支 持所有过程域。

http://www.tcic.cn

26

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

第三节 已管理级成熟度的过程域

在已管理级成熟度（ML2）共包括 7 个过程域：项目策划、项目监控、测量分析、配置管理、 过程和产品质量保证、需求管理以及供方协议管理。

这个等级的目的在于：组织的项目已确保其过程按照方针进行策划并得到执行。这些项目聘 用有专业技能的人员，这些人员拥有足够的资源，以便产生受到控制的工作产品；这些项目吸纳 利益相关方；这些项目都受到监督、控制和评审；这些项目都受到评价，以保证符合其过程说明。 ML 2 反映的过程纪律有助于确保在有压力的情况下保持现有的实践。在这些实践都到位的 情况下，项目都能按照其文档化的计划进行实施和管理。

下面分别对这些过程域进行简要介绍，并提供一个宏观的工作画面。

3.1 项目策划（PP）过程域

项目策划（Project Planning）过程的目的，是为项目的研发和管理工作制定合理的行动纲领， 以便所有相关人员按照该计划有条不紊地开展工作。

项目的计划书可分两类：一是全局的计划书（OverallPlan），这里称为《项目计划》；二是一 些下属计划书（SubordinatePlan），例如《配置管理计划》、《质量保证计划》、一些开发计划和测 试计划等。下属计划书是对《项目计划》的补充，其内容不可与《项目计划》冲突。流程如下图 所示。

对于有效的项目管理来说，最重要的前提条件是出现在项目的开始阶段。在确定和安排任务， 或给那些任务分配资源（人力）之前，所有有关各方必须就项目范围达成一致意见。项目的范围 定义非常重要，直接关系到项目是否能够成功。

1，确定项目范围 项目的范围定义了一个项目的预期，也定义了一个项目的边界，哪部分业务被研究、分析、

设计、构造、实现并最终得到改进？哪些方面被认为是在项目之外的？

对以下五个问题的回答，将影响到项目范围的协商： 1，产品：你想要什么？ 2，质量：你希望它有多好？请用定量的方式回答，并且考虑这些量值能否达到？ 3，时间：你想什么时间得到它？ 4，费用：你愿意为它只付多少钱？

5，资源：开发方愿意或者能够拿出多少钱？

1）调查研究技术 调查研究事实上是一个需求获取过程，一定要注意不要把症状当成问题，我们必须关注真正

的问题到底在哪里，以期找到业务上的问题症结所在。所谓调查研究，是通过研究、面谈、调查 表、抽样以及其它技术来收集关于问题、需求、偏好等问题的正式过程。在分析阶段，系统分析

http://www.tcic.cn

27

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

员应该了解一个企业和系统的术语、问题、机会、约束条件，以及优先级。一般来说，不管项目 如何，都会有一个框架帮助我们在早期阶段收集事实，其主要方法如下

? 对现有的文档、表和文件进行抽样来收集事实。

? 通过观察工作环境甚至观察工作中的人来收集事实。 ? 通过精心制定的调查表来收集事实。

? 通过和可客户面谈来收集事实。 面谈是一种重要的收集事实的方法，我们必须选择被劫接见者，制订问题方案，在面谈中学 会聆听对方的表达，并且能够迅速抓住问题的本质。需求必须通过一种形式化的方法记录和表达， 以便于和客户沟通。

2）范围定义阶段 项目经理通常领导这个阶段，在范围定义阶段我们需要做的事情是：

?列出问题和机会：需要关注以下几个方面的问题：紧急程度（什么时间实现？），可见 性

（系统在多大程度上对客户或执行管理层是可见的？），收益（新方案会增加或者减 少多少支出？），优先权（那些问题是最重要的？如果预算出了问题，需要减掉哪些问 题？），可能方案。 ?协商项目的初步范围：包括什么类型数据描述了正被研究的系统？正被研究的系统包括 什

么业务过程？系统需要如何与其它用户、地点或者其它系统接口？注意，项目的范围 陈述可以描述成一个简单的列表，但不十分关心精确的需求分析，尤其不关心任何费时 的建模或者原型化。

?评估项目价值：在这个任务中我们必须回答这样的问题：“这个项目看上去是不是值

得？”项目的结果能够带来足够的价值低效开发费用吗？

?计划项目进度表和预算：如果项目值得做下去，就可以深入的规划项目了。初步的规划 至

少要包含以下几个部分：一个初步的主计划（包括进度和分配给整个项目的资源，这 个计划会在项目的每个阶段结束的时候更新，又称之为基线计划），用于完成项目下一 阶段（问题分析阶段）的详细计划和进度表。 3）问题分析阶段 问题分析阶段通常包含如下任务： ? 研究问题领域：首先必须了解当前开发的系统需要解决什么问题，可以通过系统所有者、

用户、系统分析人员的参与，从不同的侧面，不同的详细程度，不同的表述方式，不同 的感知，不同的观点详细研究这个领域的业务、机会、指示和约束。 ? 分析问题和机会：通过因果分析得出对问题的真正理解。

? 分析业务过程： 业务过程分析应该避免对信息技术本身问题的关注，可以使中提出这样的问题：“如果目前的流 程是完美的，还需要这个信息系统吗？”在这个过程中还需要了解诸如：通过过程的数据量，每 个过程的响应时间，系统中出现的任何延迟和瓶颈，这些问题对于系统改进是十分可贵的资料。

4）描述系统约束： 系统改进目标可能受到约束条件调节，比如： 进度：系统必须在4 月15 日前运行。

成本：系统成本不能超过 35 万。 技术：所有的新系统必须使用 Oracle 数据库。 政策：新系统必须使用“双倍递减余额”技术。 5）修改项目计划：

由于深入研究的结果，范围定义作出的的项目基线计划一般会做出更改，这种更改对计划的 完善是很重要的。

http://www.tcic.cn

28

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

6）汇报调查结果和建议 最后应该形成一个工作陈述文档。一个典型的工作陈述文档提纲如下：

工作陈述 一、目的 二、背景 1，问题、机会或者指示陈述 2，导致项目需求的历史 3，项目目标和目的 4，产品描述 三、范围 （注意信息系统组件的使用） 1，关联人员 2，知识 3，过程 4，通信 四、项目方法 1，开发路线 2，交付成果 五、管理方法 1，团队组建的考虑 2，管理者和经验 3，培训需求 4，会议进度 5，汇报方法和频率 6，冲突管理 7，范围管理 六、约束条件 1，启动日期 2，最后期限 3，预算 4，技术 七、大致估计 1，进度表 2，预算 八、满意条件 1，成功的准则 2，假设 3，风险 九、附录

2，管理项目的关键驱动因素、约束和浮动因素 项目的背景是由所在组织的关键因素决定的。项目的驱动因素是什么？是否存在约束？有没

有可能在驱动因素和约束之间进行折中？项目经理能否为自己争取更多的自由运作空间？ 因此，

在启动项目的时候，首先要写下客户的期望：从客户的角度来看，项目的驱动因素是 什么。这个列表中应该包括，客户想要什么（功能集合），他们期望何时收到交付物（发布时间）， 可交付物的质量如何（缺陷等级）。

1）约束决定了项目的规模、持续时间和质量 接下来，我们可以写下项目的约束。环境是什么样子的？能否灵活安排团队的位置？必须遵

守什么样的流程？手下的人有哪些？他们能做什么？预算有多少？这些约束是可以改变的（一般 只有项目出问题的时候才能改变）。

约束决定了项目的规模、持续时间和质量。好，现在让我们宏观的想一想，对比客户的期望 列表和项目的约束列表。你脑海里蹦出来的项目成功的必要因素有哪些？选择其一，比如发布时 间，这就是识别出来的项目的关键驱动因素。列表上还剩下什么？应该还能看到功能集合、低缺 陷率、发布成本等条目。

我们再考虑一下，在这些条目里，需要对哪些进行管理才能保证项目的成功？可以按重要性 排列这些关注点。客户会在这些方面对项目形成限制。从中选择两到三项，我们称之为项目的约 束。再看看剩下的条目。有些条目很重要，不过它们有很大的调整余地，我们称之为浮动因素。 一个项目至少要有三个浮动因素。然后看看还没选择的条目，是不是还有哪个比己经选择的更重 要呢？如果有，那就再调整一下；如果没有，这个项目的关键驱动因素、约束、浮动因素就都识 别出来了。

2）决定项目的关键驱动因素 在与客户的对话中，我们让客户说明他最看重的是什么。假定客户说一个大型计划会在十个

星期之后启动，很明显，日期就是这个项目的关键驱动因素。在项目早期，似乎一切皆有可能， 特别是没有估算任何工作的时候。客户可能会说：“我们想要这5个功能，在8月1日之前完 成，还不能有严重的问题。我们还想让你把成本控制在一百万元之下。给你这 6 个人。 OK ? \可别轻易说 OK。

在估算了工作量之后，我们才能够知道用这么多钱、这么长时间，这 6 个人能不能做完项

http://www.tcic.cn

29

中科院计算所培训中心 GJB5000A-2008 军用软件研制能力成熟度模型概述

目。要是可以，蛮好。不过也有可能没有办法按照客户对时间、金钱、人力的要求，在规定的工 作环境中，提供符合他们质量要求的产品。此时，客户就需要做出艰难的决策。

通过制定优先级列表可以解决这个问题，将所有可能的驱动因素列在左边，右边空出来等着 填数字。

项目驱动因素 排序 发布成本 5 发布日期 1 功能集合 2 减少缺陷 3 人员配备 4 工作环境 6

我们立刻可以发现在这个项目中，发布日期是最主要的驱动因素。如果产品今年不能发布， 这个项目就没有什么存在的意义了。但是完备的功能也很重要，如果功能不齐全，即使及时发布， 整个项目也没有价值了。而且，由于公司业务属于受政府管制的行业，产品的缺陷率必须很低。 接下来是人员配备，因为只要这些人能在十个星期之后参与下个项目计划就可以了。项目的成本 控制不太重要，因为项目的价值会很高。工作环境排在最后，为了保证及时交付，我可以灵活调 整某些事情。

3，编写项目章程，共享现有决策 项目章程会明确记录项目的需求和约束，还可以帮助项目经理思考如何进行项目规划。整个 团队和客户都可以查看项目章程，以此确保他们对项目有关的决策可以达成一致。在启动项目时， 编写项目章程可以让大家知道应该完成什么目标，以及项目相关人员提出的约束条件。即使不知 道完成项目需要的细枝末节，编写章程也有助于发现潜在的问题。

下面是一个典型的项目章程模板。 ? 远景 ? 需求 ? 目标

? 成功标准

? ROI 估算 项目章程是有意要设计成这么简短的，目的是帮助团队赶紧启动。它不会包含团队对于这个

项目“完成”的定义，也不会介绍团队如何组织项目，但是已经足够让大家着手开展工作了。

1）远景 每个项目背后总有一个缘由（或者两个、三个）。发起这个项目的缘由何在？项目的价值何

在？要用描述远景的句子来说明项目的价值。越早向大家阐明项目的价值，团队就越有可能告诉 你接手这个项目是否明智。也许他们会告诉你，囿于目前的约束、资源和他们的能力，这个项目 就不可能完成。要是不能明确阐明项目的远景何在，很可能这个项目就是“不可能完成的任务” 了（因为没有远景的项目无法结束）。实用的项目远景对团队来说不可或缺。

2）需求 某些情况下，项目唯一的需求就是要在某个特定日期到达之时发布某些功能。在章程中的需

求并不需要详细描述，而是需要一种宏观的表述。更多时候，需求掺杂在下而这样的语句之中： \月20日发布的主要版本中，我们需要这个又棒又炫的功能。”（当然这样的写法也太炫了一 些，这里只是表达需求的宏观性），这些需求才是项目的驱动因素，而不是列出复杂的功能列表。 描述这样的需求需要有一种迅速抓住问题本质的能力。

3）目标

http://www.tcic.cn

30

本文来源：https://www.bwwdw.com/article/luy5.html