质量改进的第一个职责，也是等级4 的关注焦点是过程控制。对软件过程进行管理以致
它能稳定运行在质量控制带内。虽然必定还有一些经常性的浪费，测量结果中可能还有尖锋
信号需要控制，但是系统在整体上是稳定的。正是在这些地方，控制变化的特殊原因这个概
念开始起作用。因为过程既稳定又可测，所以当出现某些例外情况时，能够识别出并阐述变
化的“特殊原因”。
质量改进的第二个职责，也是等级5 的关注焦点，是过程的不断改进。为了提高质量，
变更软件过程，随后质量控制带移动。建立新的能减少经常性浪费的性能基线。在改进这样
一个过程中所得到的经验教训被运用到规划未来的过程中去。正是在这些地方，消除变化的
一般原因这个概念开始引人注目。仅仅由于随机变化，在任何系统中均以返工的形式存在经
常性的浪费。浪费是不能容忍的；有组织地减少浪费的努力导致更改系统，也就是通过克服
造成低效性的“一般原因”来改善过程以防止出现浪费。
我们期望，达到CMM 最高成熟度等级的组织，具有能在预测的成本和进度的限制下
生产出极端可靠的软件的过程。随着对较高成熟度等级理解的加深，将对已有的关键过程区
域加以提炼，也可能给模型添加些内容。CMM是从制造业中所产生的过程思想推导出的，
但是软件过程不像制造过程那样以重复问题占主导地位。软件过程以设计问题占主导地位，
而且是知识密集性的活动[CrutiS 88].

2.3 软件过程的可视性
软件工程师们对项目状态有详细而深入的了解，因为他们掌握有关项目状态和性能的第
一手材料。可是，对大项目而言，他们的洞察力常来源于在其职责范围内的个人经验。项目
以外的不掌握第一手材料的人，例如高级经理，对项目过程缺乏可视性，为得到他们监控进
程所需要的信息只得依靠定期的评审。图2-3 显示在过程成熟度的每个等级上，提供给管理
者的对项目状态和性能的可视性等级。每个后继的成熟度等级逐步增加地提供软件过程更好
的可视性。

2.3 软件过程的可视性
软件工程师们对项目状态有详细而深入的了解，因为他们掌握有关项目状态和性能的第
一手材料。可是，对大项目而言，他们的洞察力常来源于在其职责范围内的个人经验。项目
以外的不掌握第一手材料的人，例如高级经理，对项目过程缺乏可视性，为得到他们监控进
程所需要的信息只得依靠定期的评审。图2-3 显示在过程成熟度的每个等级上，提供给管理
者的对项目状态和性能的可视性等级。每个后继的成熟度等级逐步增加地提供软件过程更好
的可视性。

本文的目的
本文对软件能力成熟度模型进行技术性综述，反映版本1.1。具体讲，本文描述五个成
熟度等级的过程成熟度框架、组成CMM的结构成分、在实践中如何运用CMM、及CMM
的未来发展方向。本文是了解CMM 的最好材料之一，并能澄清与SEI 所提倡的软件过程成
熟度有关的一些误解。
SEI 一直与工业部门和政府一起提炼和扩展该模型，鼓励软件组织关注CMM而不是成
熟度提问单。为了促进这种关注，SEI 已经研究并正在制定一套过程产品。本文〔Paulk 93a〕
和“能力成熟度模型的关键实践1．1 版” 〔Paulk 93b〕一起构成CMM V1.1。后者描述
CMM 每一等级的关键实践。本文叙述软件过程成熟度的基础原理，并打算帮助软件组织运
用CMM V1.1 作为改进其软件过程成熟度的指南。
本文的对象
本文介绍CMM 及其相关产品。所以，任何打算学习CMM的人都应阅读本文。可是本
文假定，读者已具有开发和（或）维护软件的某些知识和经验，并对当前软件界所面临的问
题有所了解。
本文可有以下几种用途：
??任何人用来了解开发和维护软件的有效过程中的关键实践，
??任何人用来识别为达到CMM 下一个成熟等级所必须的关键实践，
??组织用来了解和改进其有效开发软件的能力，
??采购组织或主承包商用来了解让某个具体组织完成合同工作的风险，
??SEI 采用本文作为拟定成熟度提问单中提问的基础，
??指导者用来指导群组（team）为执行软件过程评估或软件能力评价作好准备。
本文的组织方式
本文共有五章
第一章定义那些为理解CMM 及其动机和目的所需要的概念。
第二章描述CMM 的五个等级和它们的基础原理。
第三章描述CMM如何被构造成一些关键过程区域，按共同特点进行组织，用关键实践
加以刻画。
第四章在高层次上综述CMM 如何指导软件评估、软件能力评价和过程改进大纲。
第五章作为本文的结束，描述了CMM 及其相关产品的未来发展方向。
CMM 的其它产品
虽然孤立地阅读本文是可以的，但按照设计，本文是其它产品的出发点。本文及其相
关．产品能帮助读者理解和使用CMM。所有这些基于CMM的产品都已经或将被系统地从
此模型中导出。在写本文时，虽然产品的初始版本都已处在先导性试验和发布等各种阶段，
但这些产品中的绝大多数尚未形成最终可用产品。

1 过程成熟度框架
人们关于通过应用新的软件方法和技术能提高生产率和质量的希望，经过了20 年仍未
实现，于是工业和政府组织意识到，他们的基本问题是不能管理其软件过程〔DoD 87]。在
无纪律的、混乱的项目状态下，组织不可能从较好的方法和工具中获益。许多组织中、项目
常极度迟后、预算翻番〔Siegel 90〕。在这些情况下，组织经常不提供帮助项目避免这些问
题所需要的基础设施和资助。
可是，即使在无纪律的组织中，个别软件项目仍能生产出优质产品。这些项目的成功一
般是通过工作组的杰出努力，而不是通过重复使用具有成熟软件过程的组织的经过验证的方
法。在没有全组织范围的软件过程的条件下，重复结果的取得完全取决于能使同样人员去做
下一个项目。仅仅建立在可得到特定人员上的成功不能为全组织生产率和质量的长期提高打
下基础。只有通过在建立有效软件工程和管理实践等过程基础设施方面，坚持不懈的努力，
才能取得不断改进。

2.4 过程能力和性能预测
一个组织的软件过程成熟度能帮助预测一个项目达到其目标的能力。等级1 组织中的不
同项目在达到成本、进度、功能和质量等指标的能力上差别很大。正如图2．4 中的例子所
示，随着组织软件过程成熟，在满足预定目标方面能观察到三个改进之处。
④这

序，使每个阶段上的改进能为下一阶段的改进打下基础。所
以，从软件过程成熟度框架导出的改进策略，对过程不断改进的历程提供了一份导引图。它
指导组织前进并识别出其缺陷，但它并不企图对有问题的项目提供快速修复措施。
软件能力成熟度模型绘软件组织提供如何增加对其开发和维护软件过程的控制，如何向
软件工程和管理的优秀文化进化等方面的指导。设计CMM是为了指导软件组织，通过确定
当前过程的成熟度和通过识别出对软件质量和过程改进至关重要的少数问题，来选择其过程
改进策略。通过关注一组有限的活动，并为实现它们而积极工作，组织能稳步地改善其全组
织的软件过程，使其软件过程能力持续不断地增长。
CMM 分阶段的结构基于已有60 多年历史的产品质量原理。Walter Shewart 于30 年代
公布了统计质量控制原理。W·Edward。Deming〔Deming 86〕和Joseph Juran[Jura 88，Juran89]
的著作又进一步发展了和成功地论证了该原理。SEI 已将这些原理改编成为成熟度框架，
该框架为软件过程定量控制建立了项目管理和项目工程的基本原则，这是过程不断改进的基
础。
ITT 的phil ip Crosby 在其书“Quality is Free” 〔Croshy 79）中首先提出将质量原理改
编为成熟度框架的思想。Crosby 的质量管理成熟度网格描述了采用质量实践时的五个进化
阶段。该成熟度框架又由IBM 的Ron Radice 和他的同事们在Watts Humphrey 指导下进一
步改进以适应软件过程〔Radice 85]。1986 年， Humphrey 将此成熟度框架带到软件工程
研究所加上了成熟度等级的概念，研制成当前整个软件产业界所使用的框架的基础。
HumPhrey的成熟度框架早期版本发表在SEI 技术报告〔Humphrey 87a，Humphrey 87b]、
文章[Humphrey 88]和书“Managing the software Process”〔Humnhrey 89）中。1987 年发表
了初步的成熟度提问单[Humphrey 87b〕，它作为工具给组织提供软件过程特征化的一种方
法。1987 年又进一步研制出软件过程评估和软件能力评价两个方法，以便估计软件过程成
熟度。自1990 年以来，在政府和工业部门许多人的帮助下，SEI 基于几年来将框架运用到
软件过程改进方面的经验，已经进一步扩展和精炼了该模型。

首先，随着成熟度增长，所有项目的预定目标结果与实际结果间的差异减小。例如，如
果有十个相同规模的项目预定在5 月1 日交付，那么随着组织的成熟，它们交付的平均日
期会越来越靠近5 月1 日。等级1 组织常常远迟后于其进度表规定的交付日期，而等级5
的组织应该能相当精确地满足预定日期要求。这是因为等级5 上组织采用仔细构造的、在已
知参数范围内运行的软件过程，而且确定预定日期是基于他们所具有的有关其过程的大量数
据，以及运用数据时的性能。（在图2.4 中，用预定日期线右边曲线下的面积大小表示这一
点。）
其次，随着成熟度增长，实际结果相对预定目标结果的偏差范围减小。例如，等级1
组织中，对具有类似规模项目的交付日期是不可预测的，其变化很大。而等级5 组织中的类
似项目的交付日期在小得多的范围内变化。在最高成熟度等级上变化范围很小的原因是所有
的项目实际上均在接近组织的有关成本、进度、功能和质量等过程能力的受控参数的范围内运行。（图2．4 中，以集中于预定目标线附近的面积大小说明这点。）
第三，随着组织成熟度的增加，预定目标结果得到改善。这就是说，随着软件组织的成
熟，成本降低，开发时间缩短、生产率和质量提高。在等级1 上的组织，其开发时间可能十
分长，因为必须完成大量的用以纠正错误的返工。相反，等级5 组织采用不断改进过程和缺
陷预防技术增加过程有效性和消除费钱的返工，使得开发时间得以缩短。（图2．4 中，这点
反映在预定目标线在指向原点方向上的水平移动。）
图2-4 之中所表示的在预测项目结果方面的改进基于以下假定，即随着噪声（通常以返
工形式出现）从软件过程中消除，软件项目结果更加可以预测。但是，无先例的系统会使情
况复杂化，因为新的技术和应用问题增加可变性，从而降低过程能力。即使在无先例系统的
情况下，与比较不成熟的组织相比，较成熟的组织管理和工程实践的特征能在开发周期的较
早阶段帮助识别和阐述问题。由于较早识别出缺陷，能消除后面阶段的返工，从而提高项目
的稳定性和性能。风险管理是成熟过程中项目管理的必不可少部分。在某些情况下，一个成
熟过程意味着在软件生命周期的早期识别出“失败”项目，使得在徒劳无功的事情上的投资
最小。

2．5 跳越成熟度等级
CMM 中的成熟度等级描述在一个成熟度等级上组织的特征。每一等级均为接连的几个
等级奠定基础，为有效地且效率高地实施过程提供支持。可是，在有益时，组织也可以使用
比它们所在等级高的那些成熟度等级中所描述的过程。例如，虽然CMM 中在等级3 以前不
讨论工程过程——诸如需求分析、设计、编码和测试，但是甚至等级l 组织都必须进行这些。
活动。在有利可图时，等级1 或等级2 组织可以进行同行评审（等级3 的）、Pareto 分析（等
级4 的）、或者引入新技术（等级5 的）。在讨论为了从等级1 提高到等级2 一个组织应采取
何种步骤时，一个经常性的建议是建立软件工程过程小组，而这是等级3 组织的属性。虽然
度量是等级4 的关注焦点．但它也是较低成熟度等级的必备部分。
可是这些过程的潜力只有在建立适当基础之后才能得到完全的发挥。例如，同行评审不
可能完全有效，除非始终一致地实施这种评审，即使对非常紧急的项目也是如此。成熟度等
级只描述一个等级上占主导地位的问题。等级1 组织的占主导地位的问题是管理；策划和
管理软件项目的困难掩盖了其它问题。
因为每个等级形成一个必要的基础，从此基础出发才能达到下一个等级，因此，跳越等
级是违反生产规律的。CMM识别几个等级，一个组织必须逐步经历这些等级才能建立优秀
的软件工程文化。没有合适基础的过程，在正是最需要它们的时刻——即处于压力下——不
起——作用，它们也不提供未来改进的基础。

等级1 组织，在尚未建立可重复过程（等级2）之前，试图去实施已定义的过程，通常
不会成功，因为项目经理会被进度和成本的压力压垮。这是在关注工程过程之前应首先集中
注意力于管理过程的基本原因。看起来定义和实施一个工程过程似乎要比定义和实施管理过
程容易（特别在技术人员眼中），但是如果没有管理规定，工程过程会成为进度和成本等压
力的牺牲品[Humphrey 88）。
一个尚无已定义过程作为基础就试图实施已管理过程（等级4）的组织通常是不成功的，
因为没有已定义的过程就没有解释度量的共同基础。虽然对于一个个项目能采集数据，但几
乎没有什么度量对本项目之外的其它项目有重大意义，也不能显著地增加组织对软件过程的
理解。缺少已定义过程时，由于被测过程的变化，要鉴别出有意义的质量是困难的。
一个尚无已管理过程（等级4）作为基础就试图实施优化过程（等级5）的组织，由于
缺乏对过程更改所产生的后果的了解，多半会失败。在不能控制过程使它处于统计意义上狭
窄的范围内（即过程度量中仅有小的变化）的情况下，数据中有太多的噪声以致不能客观地
确定某项具体的过程改进是否有效。因为几乎没有定量基础用于作出理性的、有信息依据的
决策，决策可能退化为宗教式的争斗。
过程改进工作应该把焦点集中在经营环境的上下文中组织的需要。具有实施较高成熟度
等级的过程的能力并不表示可以跳越成熟度等级。

3 CMM 的可操作定义
CMM 是一个框架，描述推荐给试图提高其软件过程能力的组织的一条改进路径。为了
支持使用CMM 的多种方法，特设计了CMM的操作细节。至少有四种CMM的用法受到支
持：
?? 评估组运用CMM 去识别组织中的强项和弱项。
?? 评价组运用CMM去确定选择承包商授予经营权的风险，并运用CMM 监控合同。
?? 经理和技术人员运用CMM 去理解那些对于规划和实施其软件过程改进大纲来说
必不可少的活动。
?? 过程改进组，例如SEPG，运用CMM 作为指南，帮助他们定义和改进其组织的软
件过程。
因为CMM 有多种用法，所以必须将它分解得足够细，使得能从成熟度等级的结构中导
出有关实际过程的建议。这种分解也指出那些能对软件过程成熟度和软件过程能力进行特征
描述的过程及其结构。

3．2 成熟度等级
一个成熟度等级是一个妥善定义的、朝着实现成熟软件过程目标的进化途中的平台。正
如图2.1 所示，每个成熟度等级指示过程能力的一个等级。例如，在等级2 上，通过建
立健全的项目管理控制，组织的过程能力已经从无序的提高到有纪律的。

3．3 关键过程区域
除等级1 外，每个成熟度等级被分解成几个关键过程区域，指明为了改进其软件过程组
织应关注的区域。关键过程区域识别出为了达到某个成熟度等级所必须着手解决的问题。
每个关键过程区域识别出一单相关活动，当这些活动全部完成时．能达到一组对增强过
程能力至关重要的目标。如图3．2 所示，每个关键过程区域按定义存在在单个成熟度等级

形容词“关键”的使用蕴含着存在对于实现一个成熟度等级来说并不关键的过程区域（和
若干过程）。CMM 并不仔细描述所有与开发和维护软件有关的过程区域。已经鉴别出某些
过程为过程能力的关键的决定因素；CMM 中描述的就是这些因素。
尽管其它问题也影响过程性能，但我们只鉴别出关键过程区域，这是因为它们在改进组
织软件过程能力上最有效。可以认为它们是达到一成熟度等级的必要条件。图3．2 显示每
一成熟度等级的关键过程区域。为了达到一个成熟度等级，必须实现该等级上的全部关键过
程区域。为了实现一个关键过程区域,必须达到该关键区域的每一个目氛目标概括一个关键
过程区域的关键实践，可用来确定是否一个组织或一个项目已有效地实现该关键过程区域。
目标表明每个关键过程区域的范围、边界和意图⑥。

容上将有所发展。例如，等级2 上软件项目策划关键过程区域所描述的项目估计能力中的许
多项必须进化以便能处理在等级3、4、5 上可得到的、附加的项目数据。当采用已定义软件
过程来管理项目时，等级2 的软件项目策划及软件项目跟踪和监督进化为等级3 上的集成软
件管理。
CMM 的关键过程区域表示一种描述组织如何成熟的方法。确定这些关键过程区域是基
于多年来在软件工程和软件管理方面的经验和五年多在软件过程评估和软件能力评价方面
的经验。
等级2 上的关键过程区域集中关注软件项目所关心的、与建立基本项目管理控制有关的
事情。下面列出对等级2 上每个关键过程区域的描述：
?? 需求管理目的是在顾客和软件项目之间建立对顾客需求的共同理解，顾客需求将由