软件成熟度标GJB5000A(精选.)

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

GJB5000A-2008 军用软件研制能力

成熟度模型概述

谢新华

中科院计算所培训中心

2010 年 8 月 北京

word.

中科院计算所培训中心 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

word.

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

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

1.1 软件过程的基本概念

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

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

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

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

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

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

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

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

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

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

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

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

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

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

word.

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

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

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

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

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

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

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

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

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

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

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

计划驱动的方法非常精确的依赖于明确的步骤，其中每个步骤中文档的完备性非常重 要，这种完备性可以保证每个步骤可验证，文档是可跟踪性的重要保证。

 产品规范与过程定义和改进具有同等的联系：软件作为一种产品，其可塑性使过程需 要

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

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

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

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

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

word.

中科院计算所培训中心 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，获得了如下好处：  减少软件开发费用。  提高软件开发生产率。  缩短软件开发周期。  改进软件开发质量。

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

word.

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

举例：

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

SW- CMM 不同等级的可信度

一般来说，根据大部分的统计数据，实施 CMM 的结果：  生产力约有 10%到 20%的提升。  产品错误率降低一个数量级。  对项目的预估与控制能力提升 40%到 50%。

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

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

word.

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

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

1）循序渐进的改良模式

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

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

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

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

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

质量保证人员监督实施。人都有惰性，如果没有人来监督员工们按照规范办事，那么自觉性 不强的员工就会回到“无序”的老路上。质量保证人员的职责就是周期性地检查项目成员的“工 作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量以及产品质量”。 SEPG 要及时收集员工们反映的问题和建议，不断地完善规范，但是不能频繁地变更规范的 版本，应当有计划地控制规范的版本。

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

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

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

它的特点如下。

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

word.

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

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

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

以达到所期望的目的。

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

整体。

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

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

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

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

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

word.

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

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

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

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

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

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

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

这种改进从一个不良定义的状态改进到另一个状态，等级使用定 量信息来确定和管理所需的改进，以满足组织的业务目标。 要达到某个特定的等级，组织必须满

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

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

word.

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

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

1.4 理解成熟度等级

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

赖于其中人员的能力和勤奋，而不依赖于使用已经证实的过程。尽管是这种随意、无序的环境， 组织常常仍能生产可用的产品，提供可接受的服务；不过，他们经常超出其项目的预算和进度。 成熟度等级 1 的组织的主要特征是过分承诺，在遇到困难时会放弃过程，并且不能重复他 们以往的成功。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

word.

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

程，收集并统计分析该过程绩效的详细测量值。将质量和过程绩效测量值纳入组织的测量库以支 持基于事实的决策。标识过程变异的特殊原因，并在适当时纠正特殊原因的根源以防再现。

成熟度等级 3 和成熟度等级 4 之间的关键区别是过程绩效的可预测性。

在成熟度等级 4 ，过程绩效使用统计技术和其它定量技术加以控制，并且是可定量地预测 的。在成熟度等级 3 ，过程通常只是定性地可预测的。

5，优化级 根据对过程中固有变异的共因的定量理解，组织持续地改进它的过程。这个级别关注通过增

量式和创新式的过程和技术改进来持续地改进过程绩效。 建立组织的定量过程改进目标，持续

地修订过程改进目标以反映日益变化的业务目标，并将 这些目标用作管理过程改进的准则。 对照定量的过程改进目标，测量并评价已部署的过程改进的

效果。无论是项目的已定义过程， 还是组织的标准过程集，它们都是可测量的改进活动的对象。

成熟度等级 4 和成熟度等级 5 之间的关键区别是所涉及的过程变异类型。

在成熟度等级 4 ，组织关注过程变异的特殊原因，并提供结果的统计可预测性。虽然过程 可以产生可预测的结果，但是，这些结果可能不足以实现己确定的目标。

在成熟度等级 5 ，组织关注过程变异的共因，并且改变过程（移动过程绩效的均值或者减 少过程的固有变异）以改进过程绩效并实现已确定的定量过程改进目标。

6，成熟度等级的提升 组织首先通过实现项目级的控制，然后利用定量和定性两种数据进行决策继续发展到最高等

级，以实现整个组织范围的持续过程改进，进而实现组织成熟度的逐步改进。

在成熟度等级 2 ，组织通过建立合理的项目管理己经从随意、无序状况提高到有纪律状况。 每个成熟度等级是下一个等级的必要基础，所以试图跳越成熟度等级通常是达不到预期目标 的。在尚未建立能支持更有纪律和广泛改进的基础设施时，成熟度等级 1 的过程改进活动可能 主要依赖于过程组成员的洞察力和能力。不过组织应明白，这些改进的成功是有风险的，因为成 功地制度化这些改进的基础尚未建立。没有适当基础的过程在面临很大压力时，可能会失败。例 如，成熟度等级 1 的组织实施需求分析、设计、集成和验证．可是，这些活动在成熟度等级 3 才进行描述，因为有了一致的和妥善集成的工程过程，就不会由于即兴无序的管理过程而失败。

成熟度等级 3 组织的特征是过程己定义，如果成熟度等级 2 的管理实践有缺陷，就可能将 已定义过程置于很大风险中。例如，管理者可能作出计划不当的进度承诺，或者不能控制基线化 需求的吏改。类似地，许多组织过早地收集成熟度等级 4 特性的详细数据，结果发现因为与过 程和测量的定义中的数据不一致而导致无法解释。

过程改进工作应关注组织在其业务环境中的需要，而更高成熟度等级的过程域可能满足组织 或项目的当前需要。例如，常常鼓励试图从成熟度等级 1 发展到成熟度等级 2 的组织建立一个 过程组，而建立过程组是成熟度等级 3 中组织过程焦点过程域处理的问题。过程组不是成熟度 等级 2 中组织的必要特征，但它可能是组织达到成熟度等级 2 的有用方法。

1.5 共用目标和共用实践

共用目标是应用于所有过程域的必需内容。下图说明了它包含哪些部分。

word.

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

共用目标 2 制度化已管理过程 共用实践 2 2.1 制定组织方针 2.2 策划过程 2.3 提供资源 2.4 指派职责 2.5 培训人员 2.6 管理配置 2.7 标识并吸纳利益相关方 2.8 监督并控制过程 2.9 客观评价遵循性 2.10 与更高层管理者一起评审状态 注：共用目标 3 及其实践并不应用于成熟度等级 2 的等级评定，但必须应用于成熟度等级 3 和更高等级 的等级评定。 共用目标与共用实践 共用目标 3 制度化已定义过程制度化 共用实践 3 3.1 建立已定义过程 3.2 采集改进信息 值得指出的是，没有使用共用目标 4 、共用目标 5 及其相关的共用实践。对于成熟度等级 2 ，只需满足共用目标 2 ；但对于成熟度等级 3 到成熟度等级 5 的各个过程域，则除了应满 足共用目标 2 之外，还应满足共用目标 3 。

过程域和共用实践的关系 共用实践 共用实践 2.2 过程域在实现共用实践中的作用 共用实践如何递归地用于其相 关过程域 共用实践 2.3 共用实践 2.4 共用实践 2.5 共用实践 2.6 项目策划：项目策划过程对所有与项目有关的过 用于项目策划过程的共用实践 程域（除了项目策划本身）能够全部实现共用实 2.2，可特征化为“策划此计划”， 践 2.2 并覆盖策划项目策划活动。 项目策划：通过标识所需的过程、角色和职责， 实现项目策划过程专用实践 2.4“实施此项目所 需资源的计划”，对所有与项目有关过程域支持 实施共用实践 2.3 和共用实践 2.4 （可能最初 项目策划本身除外），以确保项目所需的合适人 员、设施、装备和其它资产是可靠的。 组织培训：组织培训过程当用于所有过程域时， 用于组织培训过程域的共用实 通过使实施或支持此过程的那些人员得到涉及 践 2.5 覆盖为实施组织培训活 战略或组织范围内培训需要的培训，支持实施共 动所进行的培训活动所进行的 用实践 2.5。 项目策划：项目策划过程部分的培训，它涉及管理、创建和完成 实施项目策划的 专用实践 2.5“实施项目所需此培训所需的技能。 的知识和技能的计 划”与组织培训过程一起，支持所有与项目有关 的过程域用实践 2.5 的全部实施。 配置管理：配置管理过程能对所有与项目有关的 用于配置管理过程域的共用实 过程域和某些组织的过程域全部实施共用实践 践 2.6，覆盖由配置管理活动产 2.6。 生的工作产品的更改和版本控 制。 word.

中科院计算所培训中心

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

项目策划：项目策划过程部分的实施项目策划的 用于项目策划过程的共用实践 专用实践 2.6 “策划利益相关方参与”，能对所 2.7 覆盖利益相关方参与项目策 有与项目有关的过程域全部实施共用实践 2,7 划活动。 用于项目监控过程的的利益相关方标识部分（前两个子过程）。 项目共用寒践 2.7 覆盖利益相关方参监控：项目监控过程部分的实施项目监控的 专与项目监 控活动． 用于集成项用实践 1.5 “监督利益相关方参与，能帮助所 目管理过程的共用 实践 2.7 覆有与项目有关的过程域实施共用实践 2.7 的第 盖利益相关方参与 集成项目管三个子过程。 集成项目管理；集成项目管理过理活动。 程部分的实施集 成项目管理的专用实践 2.1“管理利益柑关方参 与”，能帮助所有与项目有关的过程域实施共用 实践 2.7 的第三个子过程。 项目监控：项目监控过程能对所有与项目有关的 用于项目监控过程的共用实践 过程域全部实施共用实践 2.8。 测量与分析：对2.8 覆盖监督和控制项目监控活 所有过程（不仅是与项目有关的 过程）测量与动。 分析过程域指导有关测量、分析和 记录能用于建立监督此过程实际绩效的信息。 过程和产品质量保证：过程和产品质量保证过程 过程和产品质量保证所用的共 可对所有过程域全部实现共用实践 2.9（可能过 用实践 2.9 覆盖质量保证活动 程和产品质量保证本身除外）。 的客观评价。 项目监控：项目监控过程部分的实施项目监控专 用实践 1.6 “执行进展评审”和专用实践 1.7 执 行里程碑评审”，支持与项目有关的所有过程域 实施共用实践 2.10 ，或许是全部，取决于更高 层管理在这些评审中的参与情况。 集成项目管理：集成项目管理过程部分的实施集 集成项目管理过程所用的共用 成项目管理专用实践 1.1 “从项目起步始遍及项 实践 3.1 覆盖对集成项目管理 目的生存周期，建立和维护项目的己定义过程”， 活动建立己定义过程。 能对与项目有关的所有过程域全部实施共用实 践 3.1。 组织过程定义：对所有过程不仅是与项目有关的 过程建立实施共用实践 3.1 所需的组织过程资 产。 集成项目管理：集成项目管理过程部分的实施集 成项目管理的专用实践 1.6 “向组织的过程资产 贡献工作产品、测度和文档化的经验”的能对与 项目有关的所有过程域部分或全部实施共用实 践 3.2 。 组织过程焦点：组织过程焦点过程部分的实施组 织过程焦点的专用实践 3.4 “将由策划和实施此 过程所导出的与过程有关的工作产品、测度和改 进信息纳入组织的过程资产”，能对所有过程域 部分或全部实施共用实践 3.2 。 组织过程定义：组织过程定义过程对所有过程建 立实施共用实践 3.2 所需的组织过程资产。 集成项目管理过程所用的共用 实践 3.2 覆盖由策划和实施集 成项目管理活动所导出的改进 信息。 共用实践 2.8 共用实践 2.9 共用实践 2.10 共用实践 3.1 共用实践 3.2 当一个共用实践与一个过程域的关系不太直接时，混淆的风险就降低了，所以在表中未描述所有递归关 系（例如，共用实践 2.3、2.4 和 2.10 ）。

1.6 善于书写良好的文档

1，为什么要书写文档 很常见的情况是，开发人员对于书写文档有种种非议，但是一个正规的软件项目，即使带来

了表面上的工作效率降低，也必须花费精力书写文档，为什么呢？

word.

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

任何时候，只要是两个人以上参与项目，都离不开口头交流，但是每个人在传递这个口头交 流的内容的时候，都会把原来的意思歪曲一点点，人类的记忆能力就是这样的。一个软件项目永 远离不开口头交流，我们不必要去停止这种交流方式，但是当开发人员比较多的时候，就可能带 来很多麻烦，解决的办法就是把所有的情况记录下来，或者是要强调书写文档。利用文档记录有 五个好处：

1）拓展人脑所掌握的记忆范围 在任何一个大到必须编写需求文档的项目中，信息的含量都会超过一个人可以掌握的规模，

书面文字可以供将来参考，而不会像记忆一样慢慢的褪去。 2）为项目团队所有成员提供相同的

信息 书面文档阅读的时候内容是相同的，所有的人员都阅读相同的材料，这是任何人对人的口头

交流无法达到的效果。

3）减少项目人员流动的困难 项目中发生人事变动是正常的，当老成员离开，新成员加入的时候，任何口头交流都很难让

人很快地掌握情况，一份很好的文档可以让他花更少的时间融入到团队中去。 4）保护智力资

产 在大多数情况下，项目中只有少数的人理解问题域，他们知道是否需要变更，软件是否存在

某些漏洞，内心中对软件是不是有什么新观点。如果这些人把他们掌握的信息以正规的方式记录 下来，项目对他们的依赖就会减小，如果他们获得了更好的机会，他们的智力资产也不会被带走。

5）帮助书写人员更好的理解问题域 书面形式描述以比口头交流更标准和更准确的方式表达。人们在写作过程中可以发现自己对

问题理解存在漏洞，甚至概念上也是不完整的。难怪人们说：“文档本身并不重要，重要的是写 文档的过程。”当然，这样写出来的文档对别人也是重要的。

2，防止编写成智力拼图 许多文档写成了类似智力拼图的玩具，很多不同的相关定义与内容

散落在文档的不同地方。

读者不会预料到在文档的其它地方会不会还有相关说明。为了阅读这样的文档，人们需要把一切 都记在脑子里，智力拼图是把散落在各处的小块拼在一起，但人的大脑很难做到这一点。

要记住，任何大的文档都不同程度的具有智力拼图性质，但我们的任务是减少智力拼图块的 数量。不要让用户在一个地方看到的信息块做出了推论，而在另一个地方才发现这个理解是错误 的，这就很危险。

组织文档的原则，大多数情况下是防止出现智力拼图的情况，如果需要，可以把文档中对某 个名称的定义和描述都找出来，统一放在某个固定的、唯一的位置上，必要的时候还可以建立术 语表。如果无法将相关信息都集中在一个章节，就需要增加引用页面，这样读者就不会迷惑了。 在书写方式上，要以读者为中心，力求通俗易懂、内容连贯、条理清楚。在内容组织上，力 图减少不必要的拼图游戏，减少不必要的前后查阅。相似的概念和名词，只要在各个章节中，都 力图自成逻辑体系，使得读起来省力清晰。

3，不要为了文档而文档 为了保持一致的软件质量，我们需要一套定义的质量准则，所以，过程的定义与文档规

范就成为很多组织很关注的内容。但也会发生文档的使用与功能正确实现无关的情况，由于文档 记录要与文档标准保持一致，结果使用起来将非常繁琐而散乱。我们来看一下下面的描述：

R-461 机票预定数据验证函数应该验证机票预定数据。 这样的句子确实使人莫名其妙，这到底是什么意思？如何测试它？这很容易使人联想到一种

鸭叫演讲，单调、温顺、平庸、符合官方标准，但是叫人提不起精神，看起来描述了很多，但实

word.

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

际上什么也没有描述。 这种书写文档的理念只是为了应付检查，而不是促进效率与更好的开发，

是为了文档的本身，

是为了文档而文档的书写方式。书写这种文档的目的只有一个，那就是证明我们正在做和官方保 持一致的事情，如果有什么差错，那不是我的责任。至于项目能不能完成，那不是我考虑的问题。

很多公司实际上是很严肃地对待文档的，但他们并没有从文档中得到好处，相反在实践中口 头交流仍然是主要手段，其关键原因是所书写的文档并不是为了开发而是为了应付检查。从格式 上看很漂亮，内容面面俱到，但在文档组织上把信息分散到各个地方，不容易查找，使文档提供 的好处尽失。如果我们希望项目开发小组很好的使用文档中的信息，就需要考虑什么内容是开发 小组最关注的，怎么组织文档才是对开发来说最容易查找，如何编写才是最容易阅读和有效的。 很多文档都没有被相关人员阅读，其原因是人们无法理解他，不适合开发人员的习惯，也没 有办法把文档与自己的开发工作联系起来。当然，确实很多评审只关注文档格式而不是文档有效 性，只关注文档字数多少而不是内容的思想性，这样的文档是没有什么意义的。

把自己写的句子大声念出来，如果发现自己写了很多毫无疑义的句子，只是一味的迎合标准 要求，就要考虑重新框定问题，使文档写出来具有精神，读者读起来也有精神。

4，文档太多怎么办 在推广软件过程规范时，员工们抱怨最多的就是“文档太多了”！甚至很多人把进度延误归 罪于写文档。

如果过程规范是适合于本企业的，那么该规范所要求的文档工作量也应该是比较适宜的。之 所以员工们抱怨“文档太多了”，那是因为他们以前文档写得太少了，一下子不习惯正常的文档 工作量。应该想办法降低写文档的难度，提高写文档的效率。基本措施有：

 机构要下功夫制定出结构良好的文档模板，给出充足的提示和示例。这样使用者就可以

“依葫芦画瓢”，总比他自己琢磨怎样写要方便得多。

 提高开发人员的写作能力，这是练内功。一是要学习好的写作方法，二是要不断地练笔

（其实写文档就是在练笔）。 做好任何事情都需要有伟大的理想，确实，有了伟大理想不一定总能成功，但是没有理想肯

定不会成功。如果你也是有伟大理想的，那么好，现在让我们踏上征程。

word.

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

第二节 过程域的基本框架

2.1 过程域部件

GJB 5000A-2008 是一个模型。模型是一种抽象，它需要一系列的部件，并且用一种格式化 方式装配起来，模型主要关注的是这些部件之间的关系。GJB 5000A-2008 中基本的部件是过程 域，每个过程域部件又包括若干子部件，下面分别加以介绍。

1，必需的、期望的和资料性的部件 本标准中的模型部件分为必需部件、期望部件和资料性部件三类，其中：

 必需的部件：是组织为满足过程域必须达到的目标。必需的部件包括专用目标和共用目

标。在评估中，满足目标是确定过程域是否已实现且己满足的基础。

 期望的部件：是组织为了实现必需的部件通常应该实施什么。期望的部件包括专用实践 和

共用实践。期望的部件用于指导过程改进和评估。在可以认为目标已经满足之前，在 组织已计划并已执行的过程中，应具有所规定的实践或者可以接受的替代实践。  资料性的部件：提供了有助于组织开始考虑如何处理必需部件和期望的部件的细节。资 料

性部件包括子实践、典型工作产品、共用实践详细说明、目标和实践的标题、目标和 实践的注释、以及参考等。

2，过程域的组成 过程域的组成见下图。

1）过程域 过程域是一个领域内的一组相关的实践，当这些实践被全部实现，就能满足对于改进该领域十分重要的一组目标。本标准包括 22 个过程域。

2）目的 目的部分描述了该过程域的目的，是资料性的部件。

例如，组织过程定义过程域的目的陈述是“组织过程定义的目的是建立和维护一个可用的组织过 程资产集和工作环境”。

3）序言 序言部分描述了该过程域所涉及的主要概念，是资料性的部件。

word.

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

例如，项目策划过程域的序言是“策划从定义产品和项目的需求开始”。

4）相关过程域 相关过程域部分列出了有关过程域的参考、反映了过程域之间高层次的关系，是资料性的部

件。例如，出现在项目策划过程域的相关过程域中的“关于风险标识和管理的更多信息，参见风 险管理过程域”。

5）专用目标 专用目标部分描述满足该过程域必须呈现的一些独特特征，是必需的部件。在评估中，专用

目标用来确定是否己满足过程域。例如，配置管理过程域的一个专用目标是“建立和维护基线的 完整性。

只有专用目标的陈述是必需的部件，专用目标的标题、编号以及与该目标有关的任何解释都 应视为资料性的部件。

6）共用目标 共用目标部分描述了使所实现过程域的过程制度化必须呈现的特征，是必需的部件，在评估

中用来确定是否已满足过程域。共用目标之所以称为“共用”，是因为同一个日标陈述应用于多 个过程域。

例如，“已定义过程制度化”。只有共用目标的陈述是必需的部件，共用日标的标题、编号以 及与该目标有关的任何解释都是资料性的部件。

7）专用目标和专用实践概述 专用目标和专用实践概述部分提供了必需的部件和期望的部件的高层次概括性描述，是资料 性的部件。

8）专用实践 专用实践部分是对在达到相关专用目标的过程中被认为是重要的活动的描述，是期望的部

件。专用实践部分描述为了取得过程域专用目标的成绩所期望进行的一些活动。例如，项目监控 过程域的一个专用实践是“对照项目计划中所标识的承诺，监督这些承诺”。

只有专用实践的陈述是期望的部件。专用实践的标题、编号以及与该专用实践有关的任何解 释应视为资料性部件。

9）典型工作产品 典型工作产品部分列出了专用实践的输出示例，是资料性的部件。这些例子称为“典型工作

产品”是因为常常还有其它同样有效的工作产品。例如，在项目监控过程域中，专用实践“对照 项目计划，监督项目策划参数的实际值”的典型工作产品是“显著偏离记录”。

10）子实践 子实践部分是为解释和实施专用实践或共用实践提供指导的详细说明，是资料性的部件。子

实践仅提供对过程改进可能有用的观点。

例如，在项目监控过程域中，专用实践 2.2 “对所标识的问题，采取纠正措施”的子实践 1 是“为解决所标识问题，确定并文档化必须采取的适当措施”。

11）共用实践 共用实践描述为达到相关共用目标的活动，是期望的部件。共用实践之所以称为“共用”，

是因为同一实践应用于多个过程域。 例如，共用目标“制度化己管理过程”的一个共用实践是

“提供足够的资源，以实施过程、 开发工作产品并提供过程服务”。 只有共用实践的陈述是期望的部件，共用实践的标题（为之所

加的编号）和与该共用实践有 关的任何解释都应视为资料性的部件。为了减少信息的重复以及保留出现信息的页码，在过程域 中只出现共用实践的标题、陈述和详细说明。有关共用实践的完整描述，参见第 5 章“共用目 标和共用实践”。

word.

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

12）共用实践详细说明 共用实践详细说明部分在过程域中出现在共用实践之后，提供关于如何将该共用实践唯一地

应用于该过程域的指导，是资料性的部件。 例如，出现在共用实践“建立和维护用于策划和执

行项目策划过程的组织方针”之后的共用

实践详细说明是“这个方针确定组织对估计策划参数、建立内部和外部承诺、以及制定该项目管 理计划的期望”。

2.2 过程管理类过程域之间的关系

1，过程域的类别 过程域之间的关系包括两个方面。一方面是单个过程域间的关系，描述过

程域之间的信息和

产品的流向。另一方面是各组过程域间的关系。过程域分为基本过程域与高级过程域，基本过程 域应在高级过实施，以确保满足高级过程域成功实施所需的先决条件。

过程域可分为以下四类： 1）过程管理类； 2）项目管理类； 3）工程类；

4）支持类。 了解过程域之间的关系以及过程域是属于基本过程域还是高级过程域，有助于有效且高效地

应用军用软件研制能力成熟度模型。

2， 过程管理类过程域概述 过程管理类过程域一般包括跨项目的定义、策划、资源分配、部署、实施、监督、控制、评

估、测量和改进过程等相关的活动。过程管理类过程域如下：

1）组织创新和部署（OID）； 2）组织过程定义（OPD）； 3）组织过程焦点（OPF）； 4）组织过程绩效（OPP）； 5）组织培训（OT）。

3，基本的过程管理类过程域 基本的过程管理类过程域（组织过程焦点过程域、组织过程定义过程域和组织培训过程域）

向组织提供一种将整个组织的最佳实践、组织过程资产和经验教训文档化并予以共享的基本能 力，如下图所示。

word.

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

说明： 组织过程焦点过程域帮助组织根据对过程和过程资产当前强项和弱项的了解，来策划、实施

和配置组织过程改进。 组织的备选过程改进可用多种方式提出，包括过程改进建议书、过程测量

值、过程实施中的

经验教训、以及过程评估和产品评价活动的结果。 组织过程定义过程域要求组织根据组织的过

程耍求和组织目标建立并维护组织的标准过程

集、工作环境标准以及包括生存周期模型说明、过程剪裁指南、过程相关的文档及数据在内的其 它资产。实施已定义过程所获得的测量数据、过程说明、过程制品、经验教训，应纳入组织的标 准过程集和其它资产中。

组织培训过程域标识组织的战略培训需要以及项目和支持组公共的战术培训需要。特别要开 展旨在学习实施组织标准过程集所需技能的培训。培训的主要要素包括一项受控的培训大纲、文 档化的计划、具有相应知识的人员以及测量培训大纲有效性的机制。

4，高级的过程管理类过程域 高级的过程管理类过程域（组织创新和部署过程域、组织过程绩效过程域）向组织提供在质

量和过程绩效方面实现其定量目标的高级能力。每个高级过程管理类过程域又依赖于基本的过程 管理类过程域所提供的开发和部署过程及支持资产的能力，如下图所示。

说明： 组织过程绩效过程域由组织的业务目标导出质量和过程绩效的定量目标。组织向项目和支持

组提供公共测量项、过程绩效基线和过程绩效模型。这些附加的支持性组织资产支持对项目和支 持组二者的关键子过程的定量项目管理和统计管理。组织通过分析由已定义过程采集的过程绩效 数据，以增进对产品质量、服务质量和组织的标准过程集的过程绩效的定量理解。

组织创新和部署过程域选择并部署所建议的增量式和创新式改进，提升组织达到其质量和过 程绩效目标的能力。对有前景的增量式和创新式改进的标识工作，应吸收己授权的、具有组织的 业务价值观和目标的工作人员参与。对要部署的改进措施，要对可能发生的费用和获得的效益进 行定量分析。

2.3 项目管理类过程域之间的关系

1，项目管理类过程域概述 项目管理类过程域覆盖与项目策划、监督和控制有关的项目管理活动。 项目管理类过程域如下：

word.

中科院计算所培训中心 1）集成项目管理（lPM )； 2）项目监控（PMC)； 3）项目策划（PP);

4）定量项目管理（QPM)； 5）风险管理（RskM)； 6）供方协议管理（SAM）。

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

2，基本的项目管理类过程域 基本的项目管理类过程域（项目策划过程域、项目监控过程域和供方协议管理过程域）包括

制定和维护项目计划、建立和维护承诺，对照计划监督进展、采取纠正措施以及管理供方协议等 有关的活动，如下图所示。

说明： 项目策划过程域包括制定项目计划、适当地吸纳利益相关方、获得对计划的承诺、以及维护

计划。策划从定义产品和项目的需求开始。项目计划覆盖该项目将实施的各种项目管理活动和开 发活动。项目从各利益相关方的角度评审影响本项目的其他计划，并建立针对利益相关方的承诺。 例如，这些计划覆盖配置管理、验证、测量与分析。

项目监控过程域包括监督活动和采取纠正措施。项目计划规定适当的项目监督等级、进展评 审的频率以及监督进展所用的测量方法。主要通过比较项目状态与项目计划来确定进展情况。当 实际状态显著偏离预期值时，采取适当的纠正措施，例如，重新策划等。

供方协议管理过程域涉及项目获取供方产品的要求。要前瞻地标识可满足项目需求的产品 源。选择供方，井建立供方协议以管理供方。借助监督所选工作产品和过程跟踪供方的进展和绩 效，并在合适时修订供方协议。对供方生产的产品部件进行验收评审和测试。

3，高级的项目管理类过程域 高级的项目管理类过程域（集成项目管理过程域、定量项目管理过程域和风险管理过程域）

包括建立己定义过程，按照组织工作环境标准建立项目工作环境、与利益相关方协调和合作、管 理风险，以及定量管理项目定义过程等活动。

word.

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

说明：

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

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

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

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

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

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

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

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

word.

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

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

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

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

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

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

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

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

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

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

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

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

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

word.

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

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

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

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

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

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

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

3）增量式生命周期

word.

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

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

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

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

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

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

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

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

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

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

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

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

word.

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

作测试上。

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

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

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

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

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

识的深度或广度。

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

行重构，以便更好的适应解决方案。同时需要把来自比较早的工程周期的反馈考虑在 内。

 生成：应用模式生成解决方案和测试案例，需要识别可以在本地纠正的缺陷或者遗漏的

信息，这些信息也会被反馈到下一个发现阶段。 测试：在每次工程迭代中，必须执行测试。通过这样的测试，可以得到一些反馈，以便 纠正遗漏了信息（发现），或者需要更新的视图（重构）。

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

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

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

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

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

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

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

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

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

word.

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

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

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

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

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

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

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

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

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

word.

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

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

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

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

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

3.1 项目策划（PP）过程域

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

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

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

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

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

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

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

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

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

word.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

word.

中科院计算所培训中心 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 个人能不能做完项

word.

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

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

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

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

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

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

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

 成功标准

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

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

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

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

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

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

3）目标

word.

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

项目目标是希望通过项目要达成的目的，不过客户可能并不赞同这些目标，这就需要平衡。 谁来撰写项目章程呢？

撰写章程，可以帮助团队早点形成凝聚力。要让尽量多的团队成员参与编写章程。要是还没 有为项目分配人员，那就先自己写章程吧。如果不是单匹马，就跟大家一起写．在项目启动会 议中，把章程跟大家过一遍，确保每个人都知道其中的内容及其缘由。

目标与需求不同。项目并不一定必须交付它的目标。我们我们的项目必须遵循传统爆布式开 发过程的项目，它的产品里面就会有比较严重的技术债务。通过重新设计解决技术债务、添加更 多的自动化测试等等，这些都是可能的项目目标。客户有时会提出一些特定的要求：“如果目前 的时间安排允许，我想要一个电子签名。”作为一个注重实效的项目经理，你可以说： \" OK ， 我们会把它加到项目目标里面去。要是有时间的话。”当然必须要询问清楚，客户所指的电子签 名到底指的是什么。

4）成功标准 成功标准是围绕客户能基于完成的产品做什么给出的定义。成功的标准并不涉及缺陷而只关 注能力，比如：

 要包括功能 1 、 2 、 3 ，这样我们的产品就可以打入目标市场了。  客户不需要访问我们的网站，就可以打开安装包、加载软件。

 在第一季度发布。 很多项目通常在正式开工之前就已经启动了．也许有人已经开始了原型化的工作；也许有人

已经预想了一些功能；也许管理层已经跟首席架构师探讨了项目在技术上的可行性．这些都是项 目的组成部分。由于项目在你思考之前就已经开始了，所以大可不必因项目章程、项目规划和项 目日程的反复修改而烦恼。作为一个注重实效的项目经理，在项目前期，虽然有些工作已经开始 了，你还是应该张开双臂拥抱项目，接受眼前的一切。在项目中期，你应该不断评估项目进程和 风险，从而掌控整个项目．项目收尾阶段，如果你是注重实效的，那就没什么好担心的了。项目 经理和团队不能控制别人做什么，只能控制自己和团队的行动。要确保成功标准在项目经理的掌 控之中。

5）RO I

很少有客户会去度量 ROI （投资回报率）。毕竟，要得到数字太难，而操纵数字又太容易 了。不过，如果管理层要求的话，项目经理可以试着估算项目的回报，试着计算一下 ROI 。在 项目完成后，可以看看是否达到了当初预计的数字。

4，开发项目规划

1）开发项目规划的模板 项目经理要用项目规划来整理想法，最好选择能在组织的更多项目中重用的形式。下面是建 议的项目规划模板：

 产品意图  历史记录  发布条件  项目组织  日程总览

 人员配备（人员曲线）  建议日程  风险列表

2）制订发布条件 发布条件会告诉你项目中“完成”的含义。有些项目经理会在下面这些状况下发布软件：某

word.

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

个资深经理说该发布了、测试人员“核准”了，或者是人们觉得时机成熟了。问题是大家对于“完 成”的定义各不相同。制订发布条件不是为了责怪哪个组的人，而是要为产品是否可以发布提供 一些客观的评判标准。客户可以用发布条件作出合理的决策，对产品的质量和风险做出判断。 制订发布条件时，要先判断当前项目的关键因素是什么。当项目经理与组织各个职能部门的 人共同商讨“成功”的含义时，他们会意识到自己不只是完成了分内的工作，而且也为项目经理 指明了成功的方向。项目经理一旦知道了成功的含义，就可以定义这个项目最重要的因素：发布 条件了。使用下列步骤来制订和使用发布条件。

 确定当前发布最重要的因素，这样可以将监控发布条件的活动贯穿项目始终。  草拟发布条件。

 让发布条件符合以下原则：确定的、可测量的、可达成的、相关的和可跟踪的。  获得项目团队与高层管理人员认可。 到产品发布的时候，发布条件只能有“满足”或“未满足”两种状态。不可能部分满足某项

条件，其实这就是没有满足。在项目经理与高层管理者讨论软件产品目前的状况时，这种二元的 方式是很有用的。如果说完成了，他们会认为你己经完全搞定了；如果说还没有满足某个条件， 他们就会认为你还在努力工作。

在必要时变更发布条件使用发布条件，可以让项目关于“完成”的定义保持稳定。不过，在 下列情况发生时，项目经理要考虑改变发布条件：进一步了解了这个项目中“完成”的含义时； 认识到无法在预定发布日期前满足所有发布条件时。

如果进一步了解了“完成”的含义，不妨问问自己之前关于发布条件的问题：我们是不是必 须要满足发布条件？要是没有满足发布条件，会发生什么？假设项目经理所在的项目无法满足发 布条件。首先，要跟团队确认为什么无法满足条件。接下来，向管理层解释无法满足条件的原因。

本过程域的结构如下表所示。

目的 1 建立估计值 专用实践 1 1.1 估计项目的范围 1.2 建立工作产品和任务属性的估 计值 1.3 定义项目生存周期 1.4 建立工作量和成本的估计值 项目策划（PP）过程域 序言 专用目标 2 制定项目计划 专用实践 2 2.1 编制预算和进度表 2.2 标识项目风险 2.3 制定数据管理计划 2.4 制定项目资源计划 2.5 策划所需的知识和技能 2.6 制定利益相关方参与的计划 2.7 制定项目计划 共用目标 3 制度化已定义过程 共用实践 3 3.1 建立已定义过程 3.2 采集改进信息 相关过程域 3 建立完整性 3 获得对计划的承诺 3.1 评审影响该项目的计划 3.2 使工作与资源水平相协调 3.3 获得计划承诺 2 制度化已管理过程 共用实践 2 2.1 制定组织方针 2.2 策划此过程 2.3 提供资源 2.4 指派职责 2.5 培训人员 2.6 管理配置 2.7 标识并吸纳利益相关方 2.8 监督并控制此过程 2.9 客观评价遵循性 2.10 与更高层管理者一起评审状态 注： 共用目标 3 及其实践并不应用于 成熟度等级 2 的等级评定，但必须 应用于成熟度等级 3 和更高等级 的等级评定。 word.

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

3.2 项目监控（PMC）过程域

项目经理面临的绝大多数问题最终都会归结到：“我们的进度怎么样了？ \" 问题可能来自于 高层，他们想知道你能否在截止日期来临之时交付产品；也可能来自项目团队，他们想知道自己 的进度如何。

我们不要期望有了好的计划就可以高枕无忧，也不要期望计划是一成不变，项目经理的责任 是不断的监控项目的进展，在动态过程中去调整。项目监控至少有以下几个好处：

 避免原本合理的计划在实施时落空；

 避免“执迷不悟”地按照不合理的计划行事；

 将监控过程产生的数据保存起来，为机构持续的过程改进提供有价值的数据。 因此我们需要建立一个恰当的控制系统，以确保过程的控制是有效的。

1，过程控制、管理和报告 进展的汇报（书面或者口头）应该足够频繁以便于管理，但又不能太频繁而成了项目开发的

负担和阻碍。下表是一个进展报告的模版。

项目进展报告 一、封面 四、以前的问题和结果 1，项目名称或者标识 1，采取的行动和问题现状 2，项目经理 2，新的和改进的行动 3，汇报日期 a) 建议 二、进展总结 b) 责任分配 1，进度分析 c) 最后期限 五、新的问题和结果 2，预算分析 3，范围分析 1，问题 （描述任何可能对未来进展有影响的项目范围 （实际的或者预期的） 变化） 2，结果 （实际的或者预期的） 4，过程分析 （描述策略和方法学遇到的任何问题） 3，可能的解决办法 三、活动分析 a) 建议 1，从上次汇报以来完成的任务 b) 责任分配 2，当前任务和交付成果 c) 最后期限 六、附件 3，短期内的任务和交付成果 （包括相应的来自项目管理软件的打印输出材 料） 2，任务管理 有效的项目监控重点应该集中于项目的偏差管理。即计划指标（范围/进度/成

本/质量）与实

际指标之间的差异是否在可接受、可控制的范围之内，比如下面的公式所示： 项目偏差=计划

指标—实际指标 这种偏差的管理恰恰应该是项目监控管理的重点，流水账式的管理往往侧重于实际完成的工

作范围、进度、成本和质量，而忽略了应该完成的内容。因此我们强调要对项目进行有效的管理 与监控，首先应该把监控的重点集中于项目的偏差控制上。

时间超支往往就是项目处于危险的信号，所以在项目监控的时候，我们首先应该观察项目时 间是不是发生了滞后。我们可以把预定的总开发时间平均分成 12 段，查看已经结束的最近 3 个 时间段。检查滞后时间是不是随着时间的流逝稳定增长？目前的总滞后时间是否大于总项目时间 的 25%？这个 25%数字是一个报警临界点，如果超过这个值，就可以认为项目严重滞后。下图 是一个典型的例子。

word.

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

观察这样的数据，我们需要检查进度趋势：

（1）滞后程度：把总滞后时间除以已经逝去的时间，是否在增长？具体地说一个月前的滞 后时间，是不是大于两个月前的滞后时间？在这个月，滞后时间会不会再次增长呢？

（2）滞后时间是否稳定：滞后是具体的事件，还是稳定的增长？

（3）目前的总滞后时间是否大于 25%？ 如果上面三个问题都是“真”，那么把项目停下来进行重新评估是个好主意。25%是一个预 警信号，但并不等于项目就是陷入了灾难。

3，成本管理 对于任何项目来说，控制成本都是最重要的任务之一。在软件开发项目中，由于这是一个智

力活动，项目成本几乎都由项目成员的支出构成。我们通常都是通过减少某项活动的完成时间， 或者通过减少和避免返工来控制和减少员工成本。为了正确的理解项目成本，我们可以根据 WBS 来设置和管理项目的成本帐目，它为项目的成本测量提供了基础。

1）成本基准 对于任何项目，每一阶段的成本情况大约如下图（A）所示。

由上图（B）还可以知道，累计成本应该是一条 S 曲线。在上图中 Z 点为成本基准，成本基 准代表了按照时间对整个项目做的成本估计，也就是需要 X 时间使用 Y 元完成项目，在后面研 究挣值管理的时候，我们可以看到成本基准是非常有用的表示方法。

2）建立成本基准 为了建立成本基准，我们可以在计算现金流的基础上，按照每个阶段的总计时来再次计算基

准。对于使用的每个资源，可以为下列内容指定资源成本：

（1）标准费用：元/小时。 （2）加班费用：元/小时。

（3）单位使用成本：通常是使用某种消费品的总体费用。 对于时间较长的活动，可以分成开始、中间和结束三个阶段分配成本。我们可以根据 WBS

按照每个活动建立预算，这样更便于理解每个活动、阶段或者任务分组的成本。然后把这些数据

word.

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

适当的分发给部门或者成本中心，以用于制定预算和跟踪。下图说明了 WBS 活动内容到成本预 算的一般情况。

在已经根据 WBS 把所有资源成本映射到成本帐目以后，通过与图 5-17 类似的根据时间绘制 的曲线，就可以得到成本测量基线（PMB）。对时间很长的项目来说，可以先仅仅为少数几个后 面的里程碑创建工作包的详细成本帐目，而后面的资金先堆积到更大的 WBS 计划包中，随着项 目的开展，成本中心将逐步了解这些成本。图 5-18 是典型的成本两因素跟踪图表。

4，项目存在严重问题的判断准则 一般来说，进度、预算、质量这三个方面任何一个都可能

引发严重灾难，但是当灾难发生的

时候，往往三个方面都存在严重的问题。评估数据可以利用我们已经得到的监控数据，如果数据 显示，在监控点上时间、资金或者质量发生严重问题，而且按这个趋势发展在最后会产生无法接 受的结果，即使在以后的时间上即使采取措施也没有办法挽回，就可以考虑项目存在严重问题了。

1）从时间监控数据上判断 时间超支往往就是项目处于危险的信号，所以在项目监控的时候，首先要观察项目时间是不

是发生了严重滞后。我们可以把预定的总开发时间平均分成 12 段（检查点），查看已经结束的最 近 3 个时间段，检查进度趋势：

 滞后程度：把总滞后时间除以已经逝去的时间，是否在增长？具体地说一个月前的滞后

时间，是不是大于两个月前的滞后时间？在这个月，滞后时间会不会再次增长呢？  滞后时间是否稳定：滞后是具体的事件，还是稳定的增长？  目前的滞后时间是否大于相对总时间的 25%？ 如果上面三个问题都是“真”，那么把项目停下来进行重新评估是个好主意。 下面我们来看一个例子，一个项目假定时间是 12 个月，已经用去了项目原定总时间的 7/12， 项目的时间使用情况如下表所示。

时间段（原计划时长的 1/12） 1 2 3 4 5 6 →7 时间超支情况示例 状态 按时 滞后 滞后 滞后 滞后 滞后 滞后 累计超支（超支时间/每时间段时长） 0% 50% 110% 160% 160% 165% 170% word.

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

我们研究一下第四个时段之前的情况：

在第二时段：累计超支 50%，也就是相对于已逝去的时间，项目滞后 1/4（50/200）。在第四 个时段结束的时候，项目滞后 40%（160/400）这种滞后已经很严重了。时间超支相对于项目总 长为 13%（160/1200），并没有达到阈值，但可以看出发展的趋势很不好。

这里要注意的问题是，项目在早期阶段出现进度滞后问题，若不加以处理，项目的滞后程度 将会随着时间的流逝而增加，到了项目后期阶段，滞后程度很难消减，越晚越难消减。在这个项 目中，在第四个时段以后进行了问题和处理，有效的改善了项目滞后状况。

我们再检查进度趋势：在项目第四个时段到第七个时段，项目滞后增加值开始减小，大约在 5%左右，那么沿着这个趋势推论，在项目结束的时候总的时间超支应该在 15%（195/1200）。16% 的超支尽管不是个很好的结果，但绝不能视为灾难。

现在我们的结论是：这个项目还处于可控状态，不过这个项目需要密切监视。因为项目后期 的任务比前半段艰巨（资产、复杂度、压力都会增长），以确保不会滑进超支增长的状态。 需要特别提示的是：当项目中的任务没有按时完成的时候，项目进度就会滑移。但是，任务 负载在整个项目时间段是不均衡的，项目开始的时候一般负载比较轻，项目后期负载会越来越大。 所以，项目前期的滑移比后期更容易消除。

2）从预算监控数据上判断 预算检查是把项目剩余工作的成本与项目收支平衡点（或称盈亏平衡点）进行比较。收支平

衡点是一个从机构财政利益出发的确定的值。这样，如果项目剩余工作的预期成本超过了收支平 衡值，那么预算报警器就发出警告。

怎样计算收支平衡值呢？对于企业来说是公司预期的投资回报率（Return On Investment， ROI）的函数。具体的说，如果项目的开发成本是 X，那么项目产生的收入应该不低于 Y，而且 必须在时间 Z 内获得。Y 是 X 的一个函数（例如，Y=3X）。Z 依赖于各种金融因素（利率、产 品预期寿命等），通常是 3～5 年之内。

对于非商业机构（例如国防部）来说，项目的收支平衡是根据项目（例如一个防空系统）所 产生的利益来推测，它可能很难量化（例如：花费了 250 亿美元的 F22 战斗机项目）。在这 样的案例中，项目制订有一份详细的预算，并期望在该预算内完成，尽管这个预算经常被修改。 在制订预算警报器的时候要考虑如下一些问题：

 项目进度检查结果是不是进入灾难？如果是，有没有必要对剩余工作的成本进行预算？  如果项目进度检查结果显示在可控范围之内，那么根据项目在最近三个时段的预算超支

情况，按照相似的超支增长率，推测项目在新的时间表结束时的预算超支，这个超支费 用是不是在机构承受范围之内？

 项目的客户和用户最近是不是提供了反馈？市场调查的数据是不是做了更新？项目原 来

的成本/价值和 ROI 分析是不是依然有效？ 我们来看一个简单的例子，再次以前面 12 个月的项目来讨论（注意：预算不是平均分配在 每个时间段上的），如下表。

时间段 1 2 3 4 5 →6 0% -3% 10% 40% 50% 60% 预算超支示例项目 各时间段的预算超支 0% -2% 4% 19% 28% 35% 累计预算超支 表中数据显示，第 6 个月当月指出超预算 60%，前 6 个月总支出超过 35%。 从预算方面来看，项目有个不错的开头，从第 3 个月开始出现超支问题，一直到第 6 个月， 超支情况持续加重。

word.

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

我们从最近 3 个时段计算超支增长率，来看看预算超支增长的状况，增长率的计算公式为： （本时间段增长率-上一时间段增长率）/上一时间段增长率*100% 我们以低 6 时间段为基点考虑，这样我们来计算一下 第四个月增长率（4%～19%）：375%； 第五个月增长率（19%～28%）：47%； 第六个月增长率（28%～35%）：25%；

可以看出来，在第四个月有一个增长率急剧的上升，我们得调查这个急剧的上升是如何造成 的？原因在什么地方？而第五个月以后增长率实际上在逐步下降，这就随着问题的发展对趋势有 了一个基本的判断。

进一步的分析我们可以考虑下面监控表。注意一下，项目监控并不需要多么好的工具，象 Excel 这种电子表格有很强的计算能力，可以方便的帮助我们对数据进行分析。

注意一下第 F 列，从第 7 个时间段开始，我们利用 Excel 的回归分析能力，对已有的累计超 支情况作了预测。相应的计算在第 G 列上自动实现了。从这个表中我们看到了什么呢？

整个项目原定预算 200 万元，到第 6 个月结束的时候，已经花去了： 720000+252000=972000 元

预测到项目结束的时候，要花去： 2000000+10000=30000 元 那么，预计从第 6 个时间段开始到项目结束的时候，我们还需要花去： 30000-972000=2668000 元

我们的问题是，再花去 270 万把这个项目完成值还是不值？如果不值，这就是报警信号！ 预算警报发出以后是不是这个项目就不值得开发了（撤销项目）？那也不一定。通过消减项 目范围可以把开支减少到可接受的程度，消减项目其他开支也可以做到这一点，在项目拯救过程 中我们会讨论这个问题。

3）从质量监控数据上判断 进度和预算的报警相对是比较容易的，而质量的警报如何来定义呢？项目的问题列表是一个

可行的指示器，我们对项目的问题一般可以分成三类：

 危急：如果不纠正这个问题，产品可能无法使用；

 严重：如果不纠正这个问题，可能会损害到软件产品一个或者多个主要功能；  轻微：如果不纠正这个问题，软件产品的主要功能也能运行。 我们在分析数据的时候，应该对如下几点进行考虑：

word.

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

危急类问题的列表是不是在变长？问题是不是正在被解决？新问题的增加速度如何？ 如果严重类问题的数量很多，而且没有变小的趋势，那么情况也很严重。

根据组织的历史和外部专家的评估，对于克服危急类问题所需要的时间，是不是有客观 的估计？

 质量问题列表是不是做了正确的归类？问题是不是草率的被删除了？是不是新问

题加入列表？

下面我们来看一个案例，在第 8 个时段结束的时候，对项目进行评价。各质量问题的严重程 度如何？我们是否需要担忧？

时间段 1 2 3 4 5 6 7 →8 9 10 11 12 0 18 14 10 25 45 25 63 项目问题列表 轻微类问题数量 严重类问题数量 0 0 1 8 4 12 9 14 危急类问题数量 0 0 0 1 3 2 5 8 如果问题解决了，就要把它从表上移除，从而使问题的数量减少。如果发现新的问题，问题 的数量就会再次增长。所以这里我们关注的还是问题发展的趋势。并且利用机构的历史数据（如 果有的话）来估计克服问题所需要的时间。从表中来分析：

危急类问题：第 6 时段减少了 1 个，第 8 时段又增加了 3 个，由于问题列表的活跃性在后期 （9～12 时段）还会增加，可见，危急类问题的数量正在增长，可能会失控。在组织的历史中， 这种规模的增加需要花费多少时间呢？这决定了我们需不需要担忧。

严重类问题：第 6 时段增加了 8 个，第 7 时段减少了 3 个，在第 8 时段又增加了 5 个，这种 波动性的状态表示问题在不断解决，应该不需要担忧。

这张表虽然表明了问题在不可控的增长，但不一定就是触发了警报，那么灾难警报的数据又 是什么样子呢？我们来看下面这张表。

时间段 1 2 3 4 5 6 7 →8 9 10 11 12 0 18 14 10 25 45 25 63 项目问题列表 轻微类问题数量 严重类问题数量 0 0 1 0 8 14 16 18 危急类问题数量 0 0 0 1 0 3 5 8 在过去三个时段，严重类和危急类的问题都在稳定增长，如果这个趋势继续下去，项目很可 能会陷入灾难。还需要注意，轻微类问题对项目失败影响非常小，尽管他通常是超支（时间、预 算）的帮凶，但是，在考虑质量的时候，一般不去考虑它。

本过程域的结构如下表所示。

word.

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

项目监控（PMC） 过程域 序言 专用目标 2 管理纠正措施直到结束 专用实践 2 2.1 分析问题 2.2 采取纠正措施 2.3 管理纠正措施 目的 1 对照计划监督项目 专用实践 1 1.1 监督项目策划参数 1.2 监督承诺 1.3 监督项目风险 1.4 监督数据管理 1.5 监督利益相关方的参与 1.6 实施进展评审 1.7 实施里程碑评审 2 制度化已管理过程 共用实践 2 2.1 制定组织方针 2.2 策划此过程 2.3 提供资源 2.4 指派职责 2.5 培训人员 2.6 管理配置 2.7 标识并吸纳利益相关方 2.8 监督并控制此过程 2.9 客观评价遵循性 2.10 与更高层管理者一起评审状态 相关过程域 共用目标 3 制度化已定义过程 共用实践 3 3.1 建立已定义过程 3.2 采集改进信息 注： 共用目标 3 及其实践并不应用于 成熟度等级 2 的等级评定，但必须 应用于成熟度等级 3 和更高等级 的等级评定。

3.3 测量与分析（MA）过程域

对于追求开发高质量软件系统的企业而言，可预测、可重复、准确地控制软件开发过程和软 件产品质量成为非常重要的问题。

1，软件工程领域的疏漏 在软件工程领域，往往大量使用定性讨论而不是定量讨论，结果带来了很大的问题，具体的

我们可以发现存在如下一些情况。

1）没有为产品设定可测量的目标 比如要求用户界面友好、可靠、可维护，但没有具体的含义。这样在软件收尾的时候，没有 办法判断是否达到了既定目标。

2）不了解软件项目的成本 很多项目没有办法对设计成本、编码成本以及测试成本进行量化，结果引起项目超支。如果

你没有办法测量成本组成，就没有办法指望对成本进行控制。 3）

没有对产品质量进行量化处理 因此就不能对用户下面的问题给出一个满意的答复： 从特定使用周期的失效可能性来说，系统的可靠性到底如何？ 将产品移植到另一种环境，需要的工作量是多大？ 4）以传闻为决策依据 如果使用一种新的性的开发方法，这种方法是否真的有效？很多新的工具的厂家推广宣 传材料，大多数情况下没有提供内容中科学依据的说明。

2，软件工程中的软件度量

word.

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

1）软件度量的应用方面 软件度量是良好的软件工程技术的关键要素。它的用途十分广泛，主要在如下的领域中：  评估状况。

 跟踪进展情况。  评价产品有效性。

 改进设计和过程的质量

2）软件度量的三个维度 软件度量贯穿整个软件开发生命周期，是软件开发过程中进行理解、预测、评估、控制和改 善的重要载体。软件度量包括 3 个维度，即项目度量、产品度量和过程度量。

度量维度 项目度量 产品度量 侧重点 具体内容 理解和控制当前项目的状况；项目度量具有战 规模、成本、工作量、进度、生产力、风 术性意义，针对具体的项目进行。 险、顾客满意度等。 侧重理解和控制当前产品的质量状况，用于对 以质量为中心，包括功能性、可靠性、易 产品的质量的预测和控制。 用性、效率、可维护性、可移植性等。 理解和控制当前情况和状况，还包含了对过程 如成熟度、管理能力、生命周期、生产率、 的改善和未来过程的能力预测；过程度量具有 缺陷植入率等。 战略意义，在整个组织范围内进行。 过程度量 3）从不同的角度看待属性 用户和管理者关心外部属性，但在开发过程中无法直接管理和控制。由于外部属性是由内部 属性决定的，因此必须建立外部属性与内部属性的关系，并通过内部属性的度量去度量外部属性， 我们可以从如下几个角度来看待属性。

从产品的角度看：

 产品的内部属性：程序代码长度、程序功能、模块化、重用性。控制流、数据流、模块

耦合度与内聚度。 产品的外部属性：程序的可靠性、可用性、可维护性。软件的可理解性、有效性、可移 植性。

从过程的角度看：

 过程的内部属性：工作量、计划和进度、一段时间内某类事件发生的次数。  过程的外部属性：成本、可控制性、可观察性、稳定性。 从资源的角度看：

 资源的内部属性：人、软硬件环境、方法、经验。

 资源的外部属性：成本、时间。 定性分析是重要的，它给我们提供了一种迅速的判断力，但是，没有定量分析给定性分析提

供依据，没有定量分析的支撑，定性的结果和趋势的判断，甚至决策，都成了无目之本，很可能 做出错误的或者劣质的设计、判断和决策。

测量是一项名副其实的工程活动，所有的测量活动必须是由具体的目标或者需求引起的，这 些目标或者需求必须定义清晰，而且应该易于理解。对于测量的目标，从管理人员和开发人员的 角度是不一样的，下面我们来讨论这两种不同背景测量需求：



3，管理人员的测量目标

1）每个过程所消耗的成本是多少？ 我们可以对软件生产的各个过程所需的时间和工作量进行测量。例如： 给出确定需求所需要的成本，详细说明所需要的成本，系统设计所需要的成本，编码和测试

所需要的成本，这样就可以算出总成本已经各个分项在总成本中所占用的比例。 2）所有成员的

生产力如何？ 可以对项目成员在详细说明系统、设计、编码和测试中所花费的时间进行测量。于是根据规

word.

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

格说明、设计文档、代码和测试计划的规模各个度量，从而确定出所有成员在各项活动中表现出 的生产力。在提出变更建议的时候，这些信息极其有用，因为管理人员可以利用这些数据对变更 的成本和期限作出估计。

3）正在开发的代码质量如何？ 通过对发生故障、失效和变更当时的记录，不但有利于软件质量的测量，同时有利于对不同

产品进行比较，对变更效果作出预测，对新的实践效果作出评估，对过程和产品改进设定目标。

4）用户对产品是否会满意？ 可以通过确定“所提出的需求是否真正得到正确的实现”来对功能性进行测量。 也可以通过测量可使用性、可靠性、响应时间和其它特性，表明客户对功能和性能是否满意。 5）如何进行改进 测量花费在主要开发活动上的时间，计算它对质量和生产率的影响，来权衡每个活动的成本

和收益，以此来判定投入的成本是不是值得。也可以在变换实践活动活动的形式方面进行尝试， 通过对结果分别进行测量，来判定哪一种更好，看看哪一种方法产生的代码质量更高。

4，软件设计人员的测量目标

1）需求是不是可以测试的？ 我们可以通过对每一项需求进行分析来判断他是不是以一种可测量的、客观的方式来表达， 比如某项需求要求系统必须是可靠的，表述方式应该为：平均无失效运行时间必须大于 15 个 CPU 小时。

2）是否发现了所有的故障？ 我们可以测量在规格说明、设计文档、代码和测试计划中发现的故障数，并查找产生故障的

根本原因。这里可以借助预期故障检测率模型，获得的信息有助于我们确定下列内容：

 审查和测试活动是否有效。

 是否可以把产品转入到下一个开发阶段。

3）是否实现了产品和过程的目标？ 我们可以通过对产品和过程特性进行测量，来判断自己受否已经达到了标准，满足了需求，

达到了过程的目标。比如我们可以给出这样的标准：

 登录的时候，在给定时间内，失效次数应该少于 20 次。  任何模块的代码不得超过 100 行。  单元测试的语句覆盖率应该达到 90%。

4）今后还会出现什么情况？ 通过对产品当前过程的属性进行测量，可以对今后的情况进行预测。比如：

 对规格说明描述的系统规模进行测量，可以预测出目标系统的规模。  通过对设计文档中系统结构特性进行测量，可以预测今后的维护问题。  通过对测试阶段软件可靠性进行测量，可以预测软件实际使用过程中的可靠性。 研究上面的讨论我们可以发现：软件度量的目标可大致 概括为两类。 其一，我们使用度量来进行估计。这使得我们可以同步地跟踪一个特定的软件项目 。 其二，我们应用度量来预测项目的一些重要的特性。但是，值得指出的是，我们不能过分夸

大这些预测。因为它们并不是完全正确的。有些人认为只要使用合适的模型和工具，所获得的预 测可以精确到只需使用极少的其他度量，这种期望是不现实的。

5，测量的作用：了解、控制与改进 综上所述，不论是管理人员还是设计人员，测量对于三种基本活动来说是非常重要的。 1）了解在开发和维护过程中所发生的情况

word.

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

对当前境况进行评估的同时，我们通过建立基线，来为今后的行为设定目标，也就是说，测 量可以把过程和产品的各个方面更加直观地呈现在我们面前，使我们对于活动所影响的实体有更 加深入地了解。

2）对项目发生的情况进行控制 通过利用基线、目标以及对关系的了解，不但可以预测今后的情况，而且还可以通过对过程

和产品进行变更，来帮助我们实现自己的目标。比如，在对代码模块复杂性进行监控的过程中， 只对那些复杂性超过可接受范围的模块进行全面评审。

3）进行过程和产品改进 根据规格说明中质量的测量，以及通过对可能的设计质量进行预测，我们可以增加自己进行 设计评审的次数和类型。

6，软件度量的基本要素 实际情况是很多要素很难用一个准确的定量数据描述，因此，一个有效的软件度量模型应该

包括“定量的”和“定性的”两部分，如下图所示。

1）定量要素 定量数据包括：产品功能规模、交付软件所需的工作量、整体工程周期、缺陷总数、项目人

力成本、以及产品上市时间等。性能生产力水平是根据这些定量数据计算的。性能水平通常包括 相对于软件规模的生产力和质量的描述。

2）基线（baseline） 在测量软件项目的时候，我们会建立一种被称之为基线（baseline）的东西，基线为我们提

供了根据不同的生产力和质量属性整理出来的各种性能等级的项目数据点。 我们应该认识到，

一个组织内的项目性能比率是不一样的，例如，我们要把交付速率作为一

种对性能进行的测量，下图表达了从多个不同项目中收集到的生产力水平并不一样。

word.

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

3）定性要素 对于我们而言，承认不同类型的软件开发性能程度不同，并最终理解导致性能差异的原因是

十分重要的，定性数据在这个时候就显得尤其重要，定性数据描述了我们如何建立并如何维护我 们的系统，并且用来分析开发性能的差异。

定性数据是按照我们所使用的软件过程、职员技术水平、开发环境的自动化程度以及商业环 境的性质来决定的，这些因素被称之为影响因子（influencer），利用影响因子来修正已有的定量 数据，将会使我们的度量更加准确而符合现实情况。

本过程域的结构如下表所示。

目的 1 安排测量与分析活动 专用实践 1 1.1 确定测量目标 1.2 指明测量项 1.3 指明数据采集和存储规程 1.4 指明分析规程 2 制度化已管理过程 共用实践 2 2.1 制定组织方针 2.2 策划此过程 2.3 提供资源 2.4 指派职责 2.5 培训人员 2.6 管理配置 2.7 标识并吸纳利益相关方 2.8 监督并控制此过程 2.9 客观评价遵循性 2.10 与更高层管理者一起评审状态 测量与分析（MA）过程域 序言 相关过程域 专用目标 2 提供测量结果 专用实践 2 2.1 采集测量数据 2.2 分析测量 2.3 存储数据和结果 2.4 交流结果 共用目标 注： 3 制度化已定义过程 共用实践 3 共用目标 3 及其实践并不应用于 3.1 建立已定义过程 成熟度等级 2 的等级评定，但必须 3.2 采集改进信息 应用于成熟度等级 3 和更高等级 的等级评定。

3.4 配置管理（CM）过程域

什么是配置管理呢？简而言之，就是在动态变化的环境中，当整个软件系统的最终版本被制 造出来以后，SCM 规范被用于确保所有的系统构件能符合要求的连接在一起，使它们按照工作 次序组织起来，不会彼此失调。

1，软件配置管理的基本概念

配置管理（Configuration Management, CM）的目的是通过执行版本控制、变更控制等规程， 以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种 有效保护。软件配置管理（SCM）简而言之就是管理软件的变化，它应用于软件工程过程，通 常由相应的工具、过程和方法学组成，在整个软件开发活动中占有很重要的位置。

SCM 通过如下手段来提高软件的可靠性和质量：  在整个软件生命周期中提供标识和控制文档、源代码、接口定义和数据库等工件的机制。  提供满足需求、符合标准、适合项目管理及其它组织策略的软件开发和维护的方法学。  为管理和产品发布提供支持信息，如基线的状态，变更控制、测试、发布、审计等。 凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项主要有两 大类：

word.

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

属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。 项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得 保存。

每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都 被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中 的配置项被“冻结”了，不能再被任何人随意修改。基线通常对应于开发过程中的里程碑 （Milestone），一个产品可以有多个基线，也可以只有一个基线。 所有的项目成员都要使用配

置管理软件来保护自己的工作成果，机构应当有专门的配置管理 员（角色）。配置管理员为每个项目制定《配置管理计划》，创建和维护配置库。 鉴于配置管理的

重要性和复杂性，组织还应当设立配置控制委员会（Configuration Control Board, CCB）。CCB 是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更 请求等）。对于配置管理而言，CCB 是决策者，而配置管理员是执行者。

配置管理的工作流程如下图所示。

它的目标是：

 软件配置管理活动有计划。

 所选择的软件工作产品得到标识、控制而且可用。  对所标识的软件工作产品的改变得到控制。

 把软件基线的状态和内容告知相关的群体和个人。

2，软件配置的问题及解决 成功 SCM 的标志并不是庞大而复杂的规范，而是对于当前组织和项目的特征有效，应该尽 可能接受更多的变更，同时不失去对软件的控制，这是一个关键点。

软件配置管理主要解决如下常见问题：

1）多人开发综合症 如果项目需要多人开发，多个人在同一个产品基础上工作，就可能出现问题，这个基础可能

是测试计划、需求规范或者代码，当多个人修改同一个文档的时候，只有最后一个人的信息得到 了保留，其他人的信息都丢失了。

2）多发布版本 对基本产品的增强，可能会导致包含最新变化的额外产品的发布。比如新产品更新了一个组

件，那么多种使用这个老版本组件的的产品都成了老版本，我们需要用 SCM 来管理这些可能的 发布版本。当有错误报告的时候，我们必须对所有已经发布的版本作发布改变，如果产品中有新 特点，必须让所有的当前客户使用这些新特点，而不管他的发布版本是哪一天的。

3）产品家族 当建立同样功能的产品系列，跨越不同种类的硬件平台的应用时，不论是共同的还是平台相

关的基础软件都要得到管理。如果一种产品在 4 种 Windows 版本、3 种 UNIX 版本和 Red Hat Linux 上运行，用户手册在很大程度上都是一样的，但这 8 种平台，安装过程可能是完全不一样的。如 果没有 SCM，就必须编写 8 种用户手册，有了 SCM 以后，只需要一个带有 8 种版本的文档配置

word.

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

项就可以了，版本之间仅仅在安装过程有不同。

4）需求变化 软件工程的特征是不论我们愿不愿意，系统和软件都是会发生变化的，改变系统的要求一直

会持续到生命周期的结束。应对这些变化，对我们管理水平提出了挑战。具备了 SCM，就可以 使对产品需求变化管理变得简单，SCM 可以容易的标识出特性组，这些特性组将对产品版本和 发布版本的需求进行分组，在开发中将会对这些特性组作跟踪，直到交付。

5）进度计划变化 随着需求的变化，进度计划也会变化。把版本的特性组和进度计划对应起来，可以让项目经

理更准确的估计生成下一个发布版本需要的工作量。有了 SCM，项目经理可以查看生成新发布 版本的历史工作量水平，这对于和新客户交谈或者给其他客户提供定制方案的时候正确估计。

6）软件变化 和需求变化和进度变化一起，随着这些方面的变化软件也会变化，软件不是静态的，这是软

件的内在力量，它可以改变，所以它就会改变。SCM 系统跟踪这些变化，如果变错了，就可以 使用以前的版本。如果开发人员在开发中常尝试用其它的解决方案但没有成功，单单 SCM 的这 种能力就可以节省大量的时间，使开发很快地回到有效的版本上来。

7）员工变化 团队成员有人提升，有人转到其它的岗位，也有人离开。如果这一切发生在开发项目中间，

所失去的就不光是技术知识。长期学来的如何做事的知识也失去了，当新手接替他们的时候，他 可能知道技术，但没有 SCM 过程的烙印，他们并不真的知道如何开发产品。所以新员工加入团 队以前，需要了解 SCM 为项目提供的运行于其上的框架和技术基础。

8）系统/用户文档变化 所有的产品开发人员都要使用不受他们控制的硬件、操作系统、工具和文档的，当操作

系统发生变化的时候，SCM 就可以对所有受变化影响的配置项、组件以及字系统进行跟踪，可 以把变化孤立起来，也可以对响应变化的工作量作出估计，这就对组织控制以外的状况更新提供 了可靠的计划。

3，SCM 的 4 种基本要求

标识、控制、审计和状态记账是软件配置管理的 4 种基本要求。不管 SCM 过程中自动化程 度有多高，这 4 种要求都应该得到满足。一般来说，需要通过自动化工具和手工过程的结合来完 成 SCM 系统的这 4 种要求。

1）标识 所有软件部件都有标签，这样就可以识别它。更进一步，随着时间的推移，软件部件会有不

同的版本，这样部件版本的修订号也应该与部件联系起来，这里的关键，是要能够确定构成发布 版本配置项的任何一个或者所有的产物。

2）控制 在 SCM 中，“控制”是指对打算改变的 CI 进行检查，如果得到了批准，就合并进软件配置， 目标是仅仅执行告知过的决定，并且接受与系统变化相关的反应。

这些变化可能影响预算、进度计划以及与其它组件变化相关。如果发布的软件产品有问题报 告，软件工程师必须快速行动，评估它的影响。因为修改个别用户产品的发布版本对于其它用户 来说很危险，SCM 系统控制可以告诉我们，哪些发布版本包含了这个有缺陷的组件。

3）审计

对 SCM 进行审计指的是，得到批准的变化请求必须实际实施。 项目经理通过审计可以确定软件的进展是否遵循对于软件的需求，并且合乎逻辑。SCM 必

须记载每个配置项所有组件的变化、版本和发布信息。如果有了这样的文档，审计就直接了当的

word.

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

分析工作。

4）状态记账 由状态记账功能生成的报告和文档，都可以成为审计的入口。软件配置项中所有得到批准的

组件都必须记账，所有列出的软件组件都必须反映出从配置项 n 到配置项 n+1 的转化。 这种

记账为确定软件项目“什么时候发生了什么”提供了历史信息。状态记账使对 SCM 的

审计要求成为可能。状态记账保留着产品整个生命周期中开发和维护工作的大量数据，这对项目 经理给予历史数据预估新系统极其重要。

4，SCM 过程的效益

SCM 可以在如下 4 个领域给组织带来效益：控制、管理、节省成本与质量。当作出决策把 SCM 工具引入组织内部对时候，这 4 种效益就对应到组织总体的目标上，而 SCM 工具的能力 将更进一步支持这些效益（如下图所示）。

1）控制

在 SCM 中，控制提供检查、批准以及把变化和并进配置项的能力。必须有一套 SCM 控制 工具，项目的所有人都需要使用这个工具，工具中固有的变化过程是标准化和可度量的，在产品 的整个生命周期，配置项的完整性维护得到保持。

2）管理

SCM 从配置项整个生命周期中进行自动化标识指导，到最后装配成产品交付，管理一直参 与其中。项目状态报告以清晰、一致的格式进行。

3）节省成本

利用 SCM，在产品的整个开发生命周期中都能实现节约成本，通过确定的、留有标记的以 及经过审计的配置项来维护产品的完整性，能够给客户提供管理良好的关于发布版产品的材料。 成本节约的程度，因使用 SCM 的状况和应用的交叉情况而异。

4）质量 软件开发是人为因素比较多的活动，最终接收产品的的客户，要对产品进行度量，以确信通

过整个生命周期中对产品的改变的跟踪，得以实现产品的高质量。以文档方式记载和以度量方式 进行的可重复的管理和变化控制，使人们可以准确的估计将来的工作。质量是一个持续进行的过 程，在一个产品中学到的经验教训，必然传递到整个相关产品和整个产品家族中。

配置管理过程域的结构如下图所示。

目的 1 建立基线 专用实践 1 1.1 标识配置项 1.2 建立一个配置管理系统 1.3 生成或发布基线 2 制度化已管理过程 配置管理（CM）过程域 序言 专用目标 2 跟踪和控制更改 专用实践 2 2.1 跟踪更改申请 2.2 控制配置项 相关过程域 3 建立完整性 专用实践 3 3.1 建立配置管理记录 3.2 执行配置审核 共用目标 3 制度化已定义过程 注： word.

中科院计算所培训中心

共用实践 2 2.1 制定组织方针 2.2 策划此过程 2.3 提供资源 2.4 指派职责 2.5 培训人员 2.6 管理配置 2.7 标识并吸纳利益相关方 2.8 监督并控制此过程 2.9 客观评价遵循性 2.10 与更高层管理者一起评审状态 GJB5000A-2008 军用软件研制能力成熟度模型概述

共用实践 3 3.1 建立已定义过程 3.2 采集改进信息 共用目标 3 及其实践并不应用于 成熟度等级 2 的等级评定，但必须 应用于成熟度等级 3 和更高等级 的等级评定。 3.5 过程和产品质量保证（PPQA）过程域

传统的质量管理体系能够帮助企业增强顾客满意度，它鼓励分析顾客要求、规定相关的过程， 并且使其持续受控，以增加顾客和其它方面满意的机会。它的质量控制流程为：建立标准、建立 质量检查评分表、实施检查、检查记录、数据统计、分析、反馈。这种检查已得到广大工程管理 者的认可。对于软件产品质量工程，我们需要进一步分析软件工程的特点，以得到建立现代大型 软件开发过程的质量管理体系的方法。

1，软件产品质量的特点 软件产品的质量与其它产品相比有明显的特殊性。

1）很难制定具体的、数量化的产品质量标准，所以没有相应的国际标推、国家标准或行业 标淮。对软件产品而言，无法制定诸如“合格率”、“一次通过率”、“寿命”之类的质量目标。至 于软件的可扩充性、可维护性、可靠性等，也很难量化不好衡量。

2）软件产品质量没有绝对的合格／不合格界限，软件不可能做到\"零缺陷\"，对软件的测试 不可能穷尽所有情况，有缺陷的软件仍然可以使用。

3）软件产品之间很难进行横向的质量对比，很难说这个产品比那个产品好多少。不同软件 之间的质量也无法直接比较，所以没有什么“国际领先”、“国内领先”的提法。

4）满足了用户需求的软件质量就是好的软件质量。如果软件在技术上很先进，界面很漂亮， 功能也很多，但不是用户所需要的，仍不能算软件质量好。客户的要求需双方确认，而且这种需 求一开始可能是不完整、不明确的，随着开发的进行不断调整。

5）软件的类型不同，软件质量的衡量标准的侧重点也不同。例如，对于实时系统而言，效 率会是衡量软件质量的首要要素，对于一些需要软件使用者与软件本身进行大量交互的系统，对 可用性就提出了较高的要求。

2，软件产品质量管理的特点 正是软件产品质量的这些特殊性，其质量管理上就具有很多特点，具体归纳如下。 1）软件质量管理应该贯穿软件开发的全过程：软件质量不仅仅是一些测试数据、统计数据、

客户满意度调查回函等等，衡量一个软件质量的好坏，应该首先考虑完成该软件生产的整个过程 是否达到了一定质量要求。在软件开发实践中，软件质量控制可以依靠流程管理（如缺陷处理过 程、开发文档控制管理、发布过程等），严格按软件工程执行来保证质量。 2）对开发文档的评审是产品检验的重要方式：由于软件是在计算机上执行的代码，离开软 件的安装、使用说明文档等则寸步难行，所以开发过程中的很多文档资料也作为产品的组成部分， 需要像对产品一样进行检验，而对文档资料的评审就构成了产品检验的重要方式。

3）运用技术手段保证质量：建议利用多种工具软件进行质量保证的各种工作，如用 CVS 软

word.

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

件进行配置管理和文档管理、用 MR 软件进行变更控制。尽可能采用先进的系统分析方法和软件 设计方法（OOA、OOD、软件复用等）来促进软件质量的提高。

4）应用质量管理思想满足顾客需要：这里首先需要注意缺陷预防。也就是通过分析过去遇 到过的缺陷并采用响应的措施，以避免这些类型的缺陷以后再次出现。我们需要有目的的规划缺 陷预防活动，找出并确定引起缺陷的通常原因，对引起缺陷的原因划分优先级并系统地消除。

3，软件质量管理体系 软件质量应该作为一个系统来管理，用系统工程的方法进一步分析软件质量的管理体系的构

建原则，从而建立一套现代的软件质量管理体系，这样就可以对软件质量进行全面的、综合的系 统性管理，一个典型的软件质量管理体系如下图所示。

我们可以基于这样的模型来建立相应的软件质量标准和软件质量管理规范，并且配以相应的 软件质量分析技术、工具等，把质量控制、质量保证和质量管理有效的集成在一起，降低质量成 本和质量风险，从而系统的解决质量问题。

4，软件质量工程体系的构成 软件质量工程体系，是通过相应的系统方法，对软件质量管理体系进行实施并且有效的控制

和优化。从而实现优化的质量结构和组织功能体系，最终达到预期的质量目标。软件质量工程体 系揭示了软件质量计划、质量标准、质量控制以及质量保证之间的关系。其构成的层次可以清晰 地分为 5 层，如下图所示。

word.

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

这 5 层的基本作用如下：

1）软件质量指标，软件质量影响因素 2）软件质量模型，软件质量度量

3）软件质量标准和规范，并且与之配套的培训体系、技术、工具、模版等 4）软件质量方针，软件质量控制，软件质量保证和软件质量管理

5）软件质量成本的控制，软件质量风险的控制，客户满意度 软件质量工程规范，规定了一系列的质量活动，这些活动又得遵循相应的流程，也就是说软

件质量工程规范约束了软件开发人员的行为模式，软件开发人员的的行为，通过一套规范有效的 得到控制。

5，PDCA 质量控制法 软件质量控制的目标是，确保不在验收阶段出现严重的质量问题，导致整个项目的失败。也

就是说把开发过程的质量控制定义成一个全面的、长期的、主动的、可以预测的过程。质量控制 不但涉及软件开发的各个部门，也贯穿于项目开发过程的所有环节。根本的目的是获得更高的开 发效率，避免返工，提高市场的竞争力。常用的软件质量控制方法是 PDCA 质量控制法。下图 所示为一个典型的软件质量控制模型及其组成要素。

PDCA 的四个部分说明如下：

1）计划：计划就是分析当前现状，发现问题，找出原因和主要原因，制定质量方针、质量 计划书和管理原则等，比如管理原则有“过程方法”、“管理的系统方法”以及“持续改进”等。

2）执行：执行是计划的履行和实现，主要按计划实施去做，去落实具体对策，并且实施过 程的监控，以达到计划设定的目标。

3）检查：检查时对执行后效果的评估，检查是伴随着实施过程自始至终的，不过收集数据、 获取信息，并且通过数据分析、结果度量来完成检查。比如内部审核就是一项主要的检查工作。

4）行动：重点在于检查完结果以后，要采取措施，亦即总结成功的经验，吸取失败的教训， 实施标准化，以后依据标准执行。行动是 PDCA 的升华过程，没有行动就不可能有提高。

PDCA 循环方法是闭合的，同时具有螺旋上升的必然趋势，这种持续的过程改进，就可以保 证控制体系有效运行，也可以保证持续、稳定的开发高水品的产品。

过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”而“差 的过程”将产生“差的产品”。人们销售的是产品而不是过程，用户关心的是最终产品的质量， 而开发者（团队）既要关心过程质量又要关心产品质量。提高产品质量有三种基本方法：

 质量保证：质量保证人员通过有计划地检查“工作过程以及工作成果”是否符合既定的

规范，来监控和改进“过程质量”与“产品质量”。

 技术评审：请同行专家、技术人员对工作成果进行评审，尽早发现工作成果中的缺陷。  测试：通过运行测试用例来找出软件中的缺陷。例如单元测试、集成测试、系统测试、

验收测试等。

word.

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

质量保证既关心过程质量又关心产品质量。如果“工作过程以及工作成果”不符合既定的规 范，那么产品的质量肯定有问题。基于这样的推理，质量保证人员即使不是技术专家，他也能够 客观地检查和监控产品的质量。这是质量保证方法富有成效的一面。但是“工作过程以及工作成 果”符合既定的规范却并不意味着产品的质量一定合格，因为仅靠规范无法识别出产品中可能存 在的大量缺陷。这是质量保证方法的不足之处。所以单独的“质量保证”其实并不能“保证质量”。

技术评审与测试关注的是产品质量而不是过程质量，两者的技术强度比质量保证要高得多。 技术评审和测试能弥补质量保证的不足，三者是相辅相成的质量管理方法。我们在实践中不能将 质量保证、技术评审和测试混为一谈，也不能把三者孤立起来执行。让质量保证人员参加并监督 重要的技术评审和测试工作，把三者有机地结合起来，可提高工作效率，降低成本。

6，软件质量保证的任务 软件质量反映了以下三方面的问题：

首先，软件需求是度量软件质量的基础，不符合需求的软件就不具备质量。 其次，在各种标准中定义了一些开发准则，用来指导软件人员用工程化的方法来开发软件。

如果不遵守这些开发准则，软件质量就得不到保证。 最后，往往会有一些隐含的需求没有明确

地提出来。如果软件只满足那些精确定义了的需求 而没有满足这些隐含的需求，软件质量也不能保证。

软件质量保证（Software Quality Assurance，SQA）是建立一套有计划，有系统的方法，来 向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进 行评审和审计来验证软件是合乎标准的。

软件质量保证组在项目开始时就一起参与建立计划、标准和过程。质量保证的基本目标是：  软件质量保证工作是有计划进行的。

 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。  将软件质量保证工作及结果通知给相关组别和个人。  高级管理层接触到在项目内部不能解决的问题。 软件质量保证包括了以下 5 个主要活动相关的任务。

1）应用技术方法：应该把软件质量控制融合到软件产品开发与软件系统中去，而不是在事 后再施加质量保证。由于这个原因，软件质量保证首先从选择一组技术方法和工具开始，这些方 法和工具帮助分析人员形成高质量的规格说明和高质量的设计。

2）进行正式的技术评审：一旦形成了规格说明和设计，就要对它们进行质量评估。完成质 量评估的中心活动是正式的技术评审。正式的技术评审是一种由技术人员实施的程序化会议，其 唯一的目的是揭露质量问题。在多数情况下，评审能像测试一样有效地揭露软件中的缺陷。

3）测试软件：软件测试组合了多种测试策略，这些测试策略带有一系列有助于有效地检测 错误的测试用例设计方法。许多软件开发人员把软件测试用作质量保证的“安全网”，也就是说： 开发人员以为通过测试能揭露最多的错误，借此减轻对其它软件质量保证活动的需要。遗憾的是， 即使是完成得很好的测试也不会像人们所期望的那样揭露所有的错误种类。

4）标准的实施：对软件工程过程应用正式的开发标准和过程的程度在各公司中是不同的。 多数情况标准由客户或者某些章程确定。在某些场合下标准也可能是自己确定的。如果存在正式 的标准，软件质量保证活动必须保证遵循这些标准。与标准是否一致的评估可以被软件开发作为 正式技术评审的一部分来进行。

5）控制变更：对软件质量的主要威胁来自“变更(change)\"。对软件的每次变更都有可能引 入错误或者引起传播错误的副作用。变更控制过程通过对变更的正式申请、评价变更的特性和变 更的影响等直接提高软件的质量。变更控制应用于软件开发期间和较后的软件维护阶段。

word.

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

7，软件质量保证的工作内容

质量保证小组（Quality Assurance Group，QAG）有如下特点：  质量保证小组在行政上于任何项目。这种性有助于质量保证小组客观地检查和

监控“过程以及产品的质量”。

 质量保证小组有一定的权利，可以对质量不合格的工作成果做出处理。这种权利使得质 量

保证小组的工作不会被轻视，并有助于加强全员的质量意识。需要强调的是，提高产 品质量是全员的职责，并非只是质量保证小组的职责。  质量保证过程包括 3 个主要过程：“制定质量保证计划”、“过程与产品质量检查”和“问

题跟踪与质量改进”，如下图所示。

1）制定质量保证计划 质量保证小组为每个项目指定一名质量保证员（即接口人）。质量保证员撰写《质量保证计 划》，项目经理和质量经理审批该计划。《质量保证计划》的主要内容是“过程与产品质量检查计 划”、“参与技术评审计划”和“参与测试计划”。制定 SQA 计划应当注意如下几点：  有重点：依据企业目标以及项目情况确定审计的重点

 明确审计内容：明确审计哪些活动，那些产品  明确审计方式：确定怎样进行审计

 明确审计结果报告的规则：审计的结果报告给谁

2）过程与产品质量检查 产品质量表现为产品的属性和行为是可以辨识，而且可以科学的描述的。软件产品质量是构

建在过程质量基础之上的，只有保证软件过程质量，才能能够保证稳定的软件产品质量，从这个 意义上说，软件过程质量更重要，它可以帮助企业大大降低软件开发成本，保证软件及时发布， 并且可以帮助发布高质量的软件产品。

质量保证员客观地检查项目成员的“工作过程”和“工作成果”是否符合既定的规范，并与 项目成员协商改进措施。质量保证员记录本次检查的结果和经验教训，并及时通报给所有相关人 员。依据 SQA 计划进行 SQA 审计工作，按照规则发布审计结果报告。注意审计一定要有项目 组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。 审计的内容包括：是否按照过程 要求执行了相应活动，是否按照过程要求产生了相应产品等。

3）问题跟踪与质量改进 对审计中发现的问题，要求项目组改进，并跟进直到解决。质量保证员设法先在项目内部解

决质量问题，如果在项目内部难以解决，则提交给上级领导处理。质量保证小组分析机构内共性 的质量问题，给出质量改进措施。

质量保证人员应该具备如下素质：

 以过程为中心：站在过程的角度来考虑问题，只要保证了过程实施，QA 就尽到了责任。  服务精神：为项目组服务，帮助项目组确保正确执行过程

 了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识  了解开发：对开发工作的基本情况了解，能够理解项目的活动

word.

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

沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。

8，软件质量保证的活动 软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含一种质量管理方法、有效 的软件工程技术（方法和工具）、在整个软件过程中采用的正式技术评审、一种多层次的测试策 略、对软件文档及其修改的控制、保证软件遵从软件开发标准以及度量和报告机制。

SQA 与两种不同的参与者相关：做技术工作的软件工程师和负责质量保证的计划、监督、 记录、分析及报告工作的 SQA 小组。软件工程师通过采用可靠的技术方法和措施，进行正式的 技术评审，执行计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动。SQA 小组的职责是辅助软件工程小组得到高质量的最终产品，他们负责完成以下任务：

 为项目准备 SQA 计划。该计划在制定项目计划时确定，由质量相关部门评审。  参与开发项目的软件过程描述。评审过程描述以保证该过程与组织，内部软件标准，

外界标准以及项目计划的其他部分相符。

 评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。记录、跟踪项目工

程活动与过程的偏差。  审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。对产品进行评审，

识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理 者报告。

 确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。  记录所有不符合的部分并报告给高级领导者。 本过程域的结构如下表所示。

目的 1 客观地评价过程和工作产品 专用实践 1 1.1 客观地评价过程 1.2 客观地评价工作产品和服务 2 制度化已管理过程 共用实践 2 2.1 制定组织方针 2.2 策划此过程 2.3 提供资源 2.4 指派职责 2.5 培训人员 2.6 管理配置 2.7 标识并吸纳利益相关方 2.8 监督并控制此过程 2.9 客观评价遵循性 2.10 与更高层管理者一起评审状态 过程和产品质量保证（PPQA）过程域 序言 相关过程域 专用目标 2 提供客观深入的了解 专用实践 2 2.1 交流并确保解决不符合项 2.2 建立记录 共用目标 注： 3 制度化已定义过程 共用实践 3 共用目标 3 及其实践并不应用于 3.1 建立已定义过程 成熟度等级 2 的等级评定，但必须 3.2 采集改进信息 应用于成熟度等级 3 和更高等级 的等级评定。

3.6 需求管理（ReqM）过程域

需求管理（Requirement Management, ReqM）的目的在客户与开发方之间建立对需求的共同 理解，维护需求与其他工作成果的一致性，并控制需求的变更。

1，需求工程概述

word.

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

我们把所有与需求相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于 需求开发，另一类属于需求管理。下图为需求工程的结构图

需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。所谓需求分析， 是把软件系统的功能表示成单一的信息变换过程，需求分析也是一个分解的过程。

需求的表达常常是抽象的，以一种与技术无关的方式表达，这样做的目的是为了避免解决方 案对技术产生影响，需求是对业务方面的说明，而不能有任何技术实现上的偏好。

2，需求开发 需求开发与需求管理的流程如下。

需求开发主要包括需求调查与产品需求定义两部分，主要的输出是“用户需求说明书”和“产 品需求规格说明书”，整个过程有一系列的技术和技巧，但只在 ML 3 级才需要严格定义。

3，需求管理（Requirement Management, ReqM） 需求管理的目的，是在客户与开发方之间

建立对需求的共同理解，维护需求与其他工作成果

的一致性，并控制需求的变更。需求管理过程域主要有 3 个规程：需求确认、需求跟踪与需求变 更控制。

1）需求确认 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承

诺，使需求文档具有商业合同效果，主要活动如下。

 非正式需求评审：项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显

的错误和分歧。

 正式需求评审：项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文

档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。

 获取需求承诺：当需求文档通过正式的评审之后，开发方负责人（项目经理）和客户对

需求文档作书面承诺。

还需要声明：我明白需求的变更将导致双方重新协商成本、资源和进度，如果需求发生变化， 我们将按照“需求变更控制规程”执行。

word.

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

2）需求跟踪 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩 阵”，确保产品依据需求文档进行开发。需求跟踪矩阵保存了需求与后续工作成果的对应关系， 矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂， 最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪 矩阵。主要活动如下。

 建立与维护需求跟踪矩阵：检查需求文档中的每个需求是否都能在后续工作成果中找到

对应点（正向跟踪）。检查设计文档、代码、测试用例等工作成果是否都能在需求文档 中找到出处（逆向跟踪）。正向跟踪和逆向跟踪合称为“双向跟踪”。  查找不一致：使用需求跟踪矩阵发现需求文档与后续工作成果之间的不一致之处，例如：

后续工作成果没有实现需求文档中的某些需求？后续工作成果实现了需求文档中的不 存在的需求？后续工作成果没有正确实现需求文档中的的需求？ 项目经理将发现的 “不一致性”记录在《需求跟踪报告》之中，并通报给相关责任人。

 消除不一致：相关责任人给出消除“不一致”的措施和计划，项目经理将该措施和计划 记

录到《需求跟踪报告》之中。相关责任人消除“不一致性”之后，项目经理更新“需 求跟踪矩阵”。

3）需求变更控制 需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保

需求的变更不会失去控制而导致项目发生混乱，主要活动如下。

 需求变更申请：需求变更申请人撰写“需求变更申请书”，递交给项目经理或客户方负

责人。“需求变更申请书”必须阐述：变更原因、变更的内容以及此变更对项目造成的 影响。

 审批需求变更申请：开发方负责人（项目经理）和客户共同审批“需求变更申请书”：

如果任何一方不同意变更，则退回变更请求，项目按照“原需求文档”执行。如果双方 都同意变更，转向下一步。

 更改需求文档：需求分析员根据“变更申请”和“审批结果”更改“原需求文档”，产

生新的需求文档。

 重新进行需求确认：重新进行需求评审，重新获取书面的需求承诺。 需求管理过程域产生的主要文档可以有：《需求评审报告》、《需求跟踪报告》以及《需求变 更控制报告》。本过程域的结构如下表所示。

目的 1 管理需求 专用实践 1 1.1 获得对需求的理解 1.2 获得对需求的承诺 1.3 管理需求更改 1.4 维护需求的双向可追溯性 1.5 标识项目工作与需求之间的不一致性 2 制度化已管理过程 共用实践 2 2.1 制定组织方针 2.2 策划此过程 2.3 提供资源 2.4 指派职责 2.5 培训人员 共用目标 3 制度化已定义过程 共用实践 3 3.1 建立已定义过程 3.2 采集改进信息 注： 共用目标 3 及其实践并不应用于 成熟度等级 2 的等级评定，但必须 应用于成熟度等级 3 和更高等级 的等级评定。 需求管理（ReqM）过程域 序言 专用目标 相关过程域 word.

中科院计算所培训中心

2.6 管理配置 2.7 标识并吸纳利益相关方 2.8 监督并控制此过程 2.9 客观评价遵循性 2.10 与更高层管理者一起评审状态 GJB5000A-2008 军用软件研制能力成熟度模型概述

3.7 供方协议管理（SAM）过程域

供方协议管理很大程度上牵涉到软件外包，也可能牵涉到硬件的生产，这里谈一下有关软件 外包的有关问题。

外包（Outsourcing）是指一个组织，为了整合利用外部资源优势，把传统上由内部开展的非 核心、非优势、而且可以跨组织管理的业务，以契约的形式委托给外部企业，从而达到降低 成本、提高效率、集中培养自己的核心竞争力，以及增强组织对外部环境的快速应变能力的一种 管理模式。

1，软件外包的价值链 软件外包的不同形式，大多数情况下都与对软件外包价值链的理解有关。软件价值链可以根

据软件工程学对于软件生产过程的划分进行，软件外包可能发生于价值链的任何层次： 1）外包

关系基础层（低端） 这一层次的特点是利用的是低工资人力资本，重点集中在劳动密集型任务，比如编码和测试。 在这个层次的外包中，承包商不参与需求分析和系统设计，仅负责整个系统中某些子模块的编程， 或者把计算结果转换为可执行的代码，或者从事套装软件的本地化和产品测试环节。这是早期软 包最常见的形式。

2）外包关系第二层（中端） 这一层次承包商开始加入一定的高端成分，用于参与软件商业产品设计和制造，其特点是对

设计人员的要求比较高，对产品设计的参与度也比较高。其重点是标准化（并常常是劳动密集型） 或成熟（有限附加值）产品的生产系统，常常收到规模经济回报的效果。这一层次承包商不参与 需求分析，只参与系统设计活动，包括概要设计、详细设计和产品编码，外包服务提供商需要把 大量的软件开发人员按照制造业企业的模式来设计工作流程，并对项目过程进行质量管理和监 控，保证软件产品按时保质的进行开发。

3）外包关系第三层（高端） 这一层次称之为技术外包开发，重点是在低工资国家或地区建立的最新工艺水平的研发中，

雇佣高技能的科学和工程技术人员。主要表现在软件的技术研发方面。这一层的技术含量很高， 发包方主要并不完全看中成本，而是更看中承接方技术研发能力。承包方参与客户整个软件开发 全过程，包括需求分析，系统设计，软件编码等。其重要特点是参与客户的需求分析过程，包括 问题分析与需求分析。

3，外包方式的有利方面

1）可能很快的完成新项目 把软件开发承包给第三方厂商而不是在公司内部开发，由于承包方在特定的领域有比较丰富

的经验，能够在给定的时间内投入足够的开发人员，并且备有一个大的程序库可提供原码重用。 在这样的背景下，外包有可能很快完成一个新项目，并且能够节约开发成本。

2）企业专注核心业务 外包代表着今天企业运用模式的一种趋势，也就是根据自己的能力进行业务专业化。这种专

业化可以让一个企业主要专注于自己的核心业务。这一核心业务功能表现了其主要的业务专长、

word.

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

发展方向和业务策略。核心业务以外的任务通常外包给第三方来提供实际的支援和交付，每个第 三方再将重点放在提高自身的核心服务上。

3）评价外包方法的效果 在大多数情况下，我们可以这样来评价外包方法的效果：

 缩短原定进度的潜力：极好  过程可视性的改善：无

 对项目进度风险的影响：风险增大  一次成功的可能性；大  长期成功的可能性：很大 4）外包的原因归纳 外包的原因通常归纳为：

 从面向市场的外包供应商不断进行的改进中获益。  服务成本有固定成本模式转变为可变成本模式。  避免在技术升级和过程改进中付出巨大资金。

 获得资产结构之外的“非生产性”资产，提高投资回报率。  把管理人员的时间和精力重新集中到核心业务上。 必须指出的是，是否选择外包和是否选择离岸外包是两个不同的问题。

4，了解外包方式弊的方面 外包对公司很有用，但它在整个公司范围内也有风险，具体表达如下： 1）失去了可视性

与外包相关的最重要的风险是有关项目进度可视性的丢失。在报告中说他们很好地按照计划 进度要求进行开发，而到时他们可能会比计划推迟好几个月才交付产品。这样的现象在软件项目 开发中很常见。所以在与承包商的合同中应该提供及时而又有意义的进度评估。

2）专门技术流出公司 外包的一个主要风险是把该领域相关的专门知识流出到公司外部的组织中去。由于这种原 因，会有两种事情发生：

 一种是本公司开发这种软件的能力下降；

 另一种是承包商增加了关于你的数据和算法的知识。 这种情况是否会出现，主要看我们外包的软件产品是否是公司的商业核心。如果是，在短期

内外包是有利的，但是从长期来看，外包会降低本公司的竟争力。这里有一些关于怎么来判断一 个产品是否为商业核心的指导：

 在这个领域保持开发这种软件项目的技术能力对我们公司是否重要？  目前这种软件是否使我们公司有很大的竞争优势？  如果现在我们公司决定退出这个领域软件项目的开发，在将来我们重新进人该领域的机

会有多大？

 在将来重新进人该领域的机会的成本有多大？  软件是否包括商业机密或其他一些保密数据？

 我们公司出售的产品是否基于这个软件所具有的独有的特点？  本公司软件开发效率是否比竞争者强很多？能否获得竞争优势？  在我们公司软件产品投人市场的时间上如何与竞争者相比？

 我们公司软件的质量水平是否比竟争者高？ 如果对于大部分问题回答“是”，那么从长期来看外包该软件并不最有利。如果大部分的问 题回答是“不”，那么这个项目是外包的候选者。

word.

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

3）松懈士气 如果我们公司要外包的项目是我们本公司开发人员想要开发的软件，那么把这软件项目交给

外部公司来开发就会影响其他项目上的开发。外包给开发人员有一种好像他们的工作处于危机之 中的感觉，也给整个开发部门罩上了一种无开发能力的阴影。

4）对进一步开发失去控制 把软件开发项目转交给外部的一家公司，公司本身可能会失去在将来进一步开发该程序的能

力。公司的开发人员不愿意去熟悉承包商的源代码。承包商可能会做出将来能更改的决定。 这要看合同如何规定，我们公司可能会失去对外包的代码进行修改的权利。或者我们公司将对项 目的设计和源代码都没有所有权。因此，在签讨合同时要确保合同提供我们公司所需要的灵活性。 5）损害公司的机密信息 在签订合同时，一定要明确机密数据和算法的知识产权能得到保

护。 从公司的角度来看，有效的外包是项目管理和风险管理的一种实际练习，我们公司要特别谨

慎地对待这些管理活动，因为外包是极具规范式的商业活动，但不应该对适合敏捷方法的项目， 例如研究型项目产生影响。尽管关于外包成功或者失败的统计数据不是很多，但是大部分的报告 多是正面的。从大多数的经验来看，成功应用外包的关键有：

 仔细选择外包承包商。

 与外包承包商仔细签订合同。

 至少要像自行开发项目那样来管理好外包软件项目。  把与承包商交流放到优先位置（电子方式及面谈方式）。

 至少要像自行开发项目那样明确需求（除非需求说明是承包商的强项）。

 确保外包快速开发项目是公司的长期兴趣。 在决定采用外包方式开发软件的时候，我们应该对以失去控制和削弱公司内部的开发能力， 换来降低成本和提高开发速度的影响进行权衡。

5，采用外包方式提高开发效率 一个软件开发项目通常要经历需求分析、设计、编程、测试等几个大的阶段。如果这些工作

实现了相对的性，就有可能通过专业化的外包服务有效的提升开发效率与降低成本。外包开 发有如下一些特点：

1）重用性 外包软件提供商在这个行业已经形成一定的规模经济，而其他公司就做不到。例如，如果用

3 倍以上的成本去开发一个可重用的部件程序库，就有些不划算。但是一个需要开发几十个库存 管理软件的外包软件提供商，不去开发一个重用部件的程序库就不能完成任务。虽然他第一次开 发的成本可能是一般开发的 3 倍，但是以后开发的库存管理程序的成本只是第一次的小部分。 即使没有可重用的部件库，外包也从其他几个方面支持有效开发。

2）员工的灵活性 外包软件提供商能够投人更多的开发人员。他们公司的开发人员也比较肯主动超时工作。 3）经验 如果这个应用领域对公司来说是全新的，或者有不熟悉的技术的话，外包软件提供商可能比 我们有更多的经验。

4）更好地制定需求说明 依据公司与外包软件提供商的合同细则，需要公司制作一份比平时更详细的需求说明。一份

高质量的需求分析说明，无论对外包还是自制都能够节约时间，但是当外包时，公司会更注重需 求分析的质量。

5）减少性能蔓延

word.

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

性能蔓延的成本在自行开发中可能会被隐藏或被混淆，但是外包软件提供商对这些成本的变 化非常敏感。就像高质量的需求说明一样，减少性能蔓延也能节约时间（无论对外包还是自制）， 但是外包时，需更加注意。

假如公司在技术方面领先的话，一般不会考虑外包，但是公司应该知道外包包括些什么？上 级管理部门可能会要我们来评估是应该项目外包还是自行开发。外包最有趣的一件事是，我们会 被当做软件开发的客户来对待，这样就可以让我们体验一下当客户的经历。

6，外包项目管理需要关注的问题

1）制定一个包括风险管理的管理计划 外包就好像自行开发一样，同样需要制定一个管理计划。在这个计划中应该包括：供应商选

择、合同洽谈、开发需求、控制需求变化、跟踪供应商进度、监督质量并且审核交付的产品是否 满足需求等。我们可以和所选择的供应商一起制定这些管理计划。

要在风险管理下多花费点时间。要注意项目由第三方开发所带来的风险，这些可能公司以前 没有经历过。

2）了解合同管理 管理好外包工作需要具备成熟的合同管理知识体系。 3）优先与供应商沟通

即使觉得与供应商没什么可以沟通时也要定期地与他们沟通。内部开发的软件项目往往采用 “走动方式”进行管理，当采用外包时，就应该考虑采用“打电话的方式”管理。

充分利用互联网的能力，常常是项目成功的关键。

4）依靠一些公司内部的技术资源 公司有时想外包是因为为他们没有开发这个软件项目所需要的技术。外包明显地减少了对技

术员工的需求，但是不能完全排除他们，需要在产品说明上多花一点时间。产品说明一般来讲是 外包合同的一部分，并且只有我们要求时才能获得。如果我们忘记了要求，很少有供应商会出于 好心而为我们提供。同样一也要安排一定的技术资源以备供应商提出问题、测试产品质量和接受 交付的产品。

5）留神不稳定的需求 除了在很少的一些案例里，一般承包方在没做好准备工作前，都不可能精确地对项目投标。

如果我们坚持以含糊的需求说明为基础而开出标价的话，我们就不会让投高标而具有竞争力的承 包商中标，最后我们只能选中那低标价的承包商，而他们并不非常理解软件开发，也不知道需求 说明不全的软件隐含多少风险。

无论软件项目是外包还是自行开发，第一步是应该全力投人来确定一个稳定的需求，这样在 项目的总价格上就不会出现更多的追加。

一些承包商擅长原型法和快速需求确定。他们能帮助我们缩短计划，即使我们不很明确需求。 有些承包商也会做设计和实施，但如果你要他们为你节约时间，你首先要敲定需求。

6）如果需要的话把工作拿回公司自行开发 考虑到很多因素会使外包工作失败，所以应该有一个后备计划。 7）对原有系统进行再次改进的项目 对原有系统进行再次改进的项目是可以首先考虑外包。用户花了长时间才得到他们想要的系 统，他们通常不想做任何改动，需求一般是稳定的。原有系统的维护人员一般都已经厌烦了，所 以感谢有人对它再次进行改进，他们也可得到解脱。

改进项目的系统测试是开发工作的主要内容，同样也要把侧试考虑成外包的一个重要部分。 当外包软件项目交付回公司后，要制定一个计划，处理与改进后的软件相关的问题，如改进后的 代码是否要公司开发人员维护？谁对缺陷进行修改和增强？

word.

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

8）避免给外包制定双重标准 公司有时给外包软件承包商和公司内开发人员制定不同的标准。如果我们考虑进行外包的

话，那么就应该想到公司内部开发人员与承包商掌握的标准是一样的，特别是在质量和计划进度 方面。

7，对承包商的评估 打算采用外包软件项目时，我们需要面对的一个任务是对承包商进行评估。 如果我们认为该承包商的能力很差的话，我们肯定意识到通过他能获得的利益，会比我们期

望的要小得多。对于承包商评估，可以采用下面的调查问卷，从三个方面考虑。

1）管理方面的考虑

 承包商有什么能力来满足他的计划和预算承诺？在满足客户承诺方面有什么可跟踪的

记录？

 承包商目前客户（包括长期客户）的满意度怎么样？承包商是杏有长期客户？  承包商的项目管理能力怎样？他是否有软件项目管理所有方面的专业知识（包括规模预

测、成本预测、项目规划、项目跟踪和项目控制）?

 你能否完全信任承包商？承包商是否还为你的对手服务？将来谁来提供产品的技术支

持？是你还是承包商？你是否想要承包商为你的客户提供支持？  是否有针对承包商的未了结的任何法律诉讼？ 2）技术方面的考虑

 承包商有什么能力保证项目取得成功？

 承包商的软件开发能力是否已经被你公司的开发人员或第三方公司评估过？技术工作

产品和开发过程是否都包括在评估中？

  承包商在该应用领域的技术水平怎样？

对承包商其他软件的质量是否可以接受？承包商是否有大量的数据来支持他的质量声 明？

 承包商的工作质量是否能够进一步提高？ 3）一般方面的考虑

 承包商的财政是否稳定？如果承包商遇到严重财政困难对你的项目会发生什么影响？  承包商在以前开发软件项目时是否有外包的能力？承接外包软件项目是否是他的主要

商业活动？承包商承诺外包的水平怎样？

8，合同方面的考虑 在公司与外包承包商打交道时，需要签订合同来描述外包双方同意的一些条款，一般来讲，

合同应该包括承包商将要提供的软件产品？什么时候提供？付给承包商多少钱和什么时候付？ 合同可能还包括一些在双方不能完成时的处罚条款。除以上这些基本要考虑的因素外。以下列出 了在签订合同时其他一些需要考虑的问题。

 除软件外，合同还应说明要提供其他哪些工作产品？如体系结构描述、设计描述、资源 代

码、在线文档、外部文档、测试计划、测试案例、测试结果、质量度量标准、用户义 档、维护计划等。

 合同是否包括允许周期性复审和评价承包商进度的条款？  是否把需求的详细描述作为合同的一部分？  合同是否包括需求的变动？  谁拥有项目源代码的所有权？

 谁拥有承包商从他的代码库中提供的代码的所有权？

word.

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

 谁拥有从你的代码库中提供的代码的所有权？  承包商是否提供从代码库里提供的代码的文档？  谁负责维护代码，包括公司最初提供的代码？

 承包商是否负责纠正产品缺陷，合同中是否说明了修复概要及响应时间？

 承包商是否有权利把为你公司开发的软件产品卖给其他的客户？如果我们为承包商提 供

了参杂到我们的产品中的源代码（为我们的产品所用），承包商是否可以把这些代码 重用到其他的一些产品中或者把这些源代码卖给其他客户？

 如果承包商破产了，源代码的所有权是谁的？假如这种情况发生了，可否可以把这些源

代码由第三方暂先保存？一旦发生破产情况，公司可以提取。

 我们是否需要为承包商提供具有版权的工具？而我们对该工具的权利能否受到保护？  如果承包商应用工具来开发产品，在项目结束后这些工具还要交还给我们的公司吗？如

果交还回来，谁拥有工具的所有权？  与承包商一起工作的本公司内部的开发人员需要签订保密协议吗？承包商这么做的用 意是什么？这样是否会我们公司将来开发自己产品的能力？  承包商是否从我们公司雇佣开发人员？

 我们公司是否从承包商那里雇佣开发人员？即使在承包商已经破产的情况下  承包商是否要求包含他们公司名称的许可证信息在开始屏幕、帮助窗口或在打印义档中

出现？

 最终产品的接受标准是什么？由谁来确定能否接受的标准？当接受产况的标准出现分

歧时由什么机构来保护双方的权益？  如果产品被转售对获得的费用如何处理？对未来的更高版本，承包商是否可以要求增加

许可证费用？如果是，费用是多少？

外包合同对项目成功如此重要，以至于我们必须用一个专门的章节来讨论有关问题。

9，制定外包管理业务流程 在进行具体的产品设计之初，合作双方认真地研究一下为完成外包业务需要处理的业务流程

十分必要。原则上，基于外包的软件开发过程与自主开发的软件过程本质上并没有多少区别，但 是，外包项目有很多职责是在双方企业分开的，有一些职责又有一些重叠，因此，双方协商制定 业务流程，指明每一阶段各自的职责十分重要。其中尤其是里程碑点的确认和在里程碑点上各自 需要完成的工作，对于项目最终成功是关键性的。

另一方面，对于以新产品设计为特征的项目，设计变更可能会随时出现，因此如何处理设计 变更也是需要仔细考虑的问题（但是应该争取变更点与里程碑点重合），这可能是双方都不愿意 接触的话题，但是与其后来发生争执，还不如事先把方法想清楚。

本过程域的结构如下表所示。

目的 1 建立供方协议 专用实践 1 1.1 确定获取方式 1.2 选择供方 1.3 建立供方协议 供方协议管理（SAM）过程域 序言 相关过程域 专用目标 2 满足供方协议 专用实践 2 2.1 执行供方协议 2.2 监督所选择的供方过程 2.3 评价所选择的供方工作产品 2.4 接收所获取的产品 2.5 移交产品 共用目标 注： 3 制度化已定义过程 共用实践 3 共用目标 3 及其实践并不应用于 2 制度化已管理过程 共用实践 2 word.

中科院计算所培训中心

2.1 制定组织方针 2.2 策划此过程 2.3 提供资源 2.4 指派职责 2.5 培训人员 2.6 管理配置 2.7 标识并吸纳利益相关方 2.8 监督并控制此过程 2.9 客观评价遵循性 2.10 与更高层管理者一起评审状态 GJB5000A-2008 军用软件研制能力成熟度模型概述

3.1 建立已定义过程 3.2 采集改进信息 成熟度等级 2 的等级评定，但必须 应用于成熟度等级 3 和更高等级 的等级评定。 word.

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

第四节 过程改进计划

重要的是，我们应该非常清楚地认识到，进行 GJB 5000A-2008 的评估不是目的，而是手段。 是希望通过这个评估，极大的改进军用软件研制的水平。因此，我们的工作重点应该放在过程改 进上，而不是仅仅关注文档格式，更不应该为了编写文档而文档。

对于基于 GJB 5000A-2008 第二级的过程改进来说，一个基本的计划任务一般包括四个里程 碑，具体的任务如下图所示。

word.

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

结语

本课程虽然仅仅从 ML 2 级的角度，与大家一起分享了对 GJB 5000A-2008 的理解，但仅此 冰ft一角，我们也可以看出 GJB 5000A-2008 内容非常丰富，观念十分现代。如果从组织层面认 真对待，将会极大地提升我用软件产品的质量和品质。ML 2 级的核心是管理过程，这也是 各个级别的基础，无数事实都证明了管理出效益这个真理。下决心把 ML 2 级做好做扎实了，上 升到更高的级别难度就会大大减少。一个组织的过程改进周期与下列因素有关：

 原有基础  投资力度

 过程改进内部成员的水平和积极性  主任评估师的水平和服务质量

 外部咨询人员的水平和服务质量。

为了成功实施 GJB 5000A-2008，要注意实现软件组织过程改进的几个关键因素： 1，高级管理层的重视 过程改进必须为组织的业务目标服务，因而必须调动一个组织上上下下、方方面面、内内外

外的力量来为这个目标服务。只有高层经理才具有这样的能力和权威来推动过程改进工作。 高

层管理应该把更多的注意力放在过程改进上，宣传过程改进的意义，为过程改进建立一支 稳定称职的、力度足够的过程改进队伍。

把这支队伍是自己推行 GJB 5000A-2008 标准进行管理的重要助手，是实现企业评估活动的 具体组织者，是制订软件过程改进计划的主要参与者和起草者，是企业与主任评估师和评估小组 外部成员之间的桥梁，是企业过程改进活动的监控者，又是企业进行定期过程诊断的内部评估师。

2，要建立过程改进的四支队伍 一个组织是否有一支有高质量的过程改进队伍，是实现过程改进的另一个关键因素。

 要有高素质的主任评估师队伍；

 要有相当规模的、合格的过程培训队伍；

 应逐步建立一支合格的过程改进咨询队伍，他们不仅应具有过程诊断能力，而且应能提

出过程改进建议；

 各个组织都要培养过程改进的专职队伍。

3，测量数据是进行过程改进的基础 任何工程学科只有当能用“数据说话”时才能上升为科学，因此要重视过程与产品的测量工 作。

在项目的整个开发过程中，要定期地(特别是在软件生命周期的基线和里程碑处)收集过程的 执行数据，以准确地了解一个过程的实际结果(叫做过程性能)以及该过程偏离期望结果（叫做过 程能力）的范围。

过程测量不仅为当前项目的测量和分析提供数据，而且作为历史数据保留下来，作为今后进 行过程改进的参考。

4，过程改进需要结合实际并不断革新

GJB 5000A-2008 是在一定的主客观条件下由人们总结出来的，都需要在实践中总结经验， 去粗取精，去伪存真，不断充实、提高。

根据目前已有的经验，在 GJB 5000A-2008 评估工作中，要提倡将 GJB 5000A-2008 与企业 已有的经验有机地结合起来，同时密切注意过程改进的新动向。

如何将过程管理与人员管理和知识管理结合起来，如何在虚拟企业的环境下进行过程改进，

word.

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

使过程改进真正产生经济效益，都要继续进行研究、实践与创新。 5，要提高对过程改进的认

识 过程成熟度升级本身就是一个过程，本身就有一个生命周期。过程改进工作必然具有一切过

程所具有的固有特征，不能急功近利。

因此： 需要循序前进，不能一蹴而就； 需要持续改进，不能停滞不前； 需要联系实际，不能照本宣科； 需要适应变革，不能凝固不变。

制定规程并不要追求高、大、全，而是要简约、有效、有用，根据实际情况制定有本单位特 色的规程，并在实践中发挥作用才是好的规程。事实上，要通过标准的认证并不太难，但是要让 这个标准真正发挥作用，就需要付出艰苦的努力了，为了中国软件工程向更高水平的发展，让我 们共同努力吧！

最新文件 仅供参考 已改成word文本 。 方便更改

word.