5.1 CMM 不包括什么
CMM 不是无所不包的[Brooks 87），它并不阐述所有的对成功项目来说是重要的问题。
例如，当前CMM 并未谈及特定应用领域内的专门知识、鼓吹具体的软件技术、或者就如何
选择、顾用、激励和留住有能力的人，提出建议。虽然这些问题对项目的成功至关重要，其
中一些已在其它上下文中，进行了分析〔Curtis 90〕，可是尚未将这些问题综合到CMM 中。
CMM 是为了提供一个有秩序的、有纪律的框架，以便在此框架内阐述软件管理过程和工程
过程的问题而专门研制的。

第二篇能力成熟度模型的关键实践1．11
版

GAO-92-48 Em5edded Computer Systems：significant software Problem'On C－17 Must
Be Addressed， GAO ／IMTEC-92-48， May 1992．
HumPhrey87a W· S · HumPhrey ， Charactrerzing the Software Process ： A Maturity
Framework，Software Engineering Institute，CMU／SEI －87－TR－11，
ADA182895， June 1987．
Humphrey87b W． S． Humphrey and W．L， Sweet， A Method fer Assessing the Software
Engineering Capability of Contractors，Software Engineering Institute， CMU
／SEI－87－TR－23， ADA187320， September 1987．
Humphrey88 W．S．Humphrey， characterizing the Software Process，IEEE Software，
Vo1． 5， No． 2，March， 1988， pp． 73－79．
Humphrey89 W． S· Humphrey，Managing the SOfrtware Process，Addison－Wesley，
Readin g，MA，1989．
Humphrey91a W．S·Humphrey，D．H．Kitson，and J．Gale ，”A Comparison of U．S． and
Japanese Software Process Maturity，”Proceedings of the 13th International
Comference on Software Engineering Austin，TX，13-17 May 1991，PP38-49·
Humphrey91b W．S．Humphrey，’Process Fitness andFidelity，”Proceedings of the Seventh
International Software Process WOrkshop， 16－18 October 1991
IEEE-STD-610 ANSI／IEEE Std 610、12－1990，’’IEEE Standard Clossary of Software
Engineering Terminology，’February 1991·
Imai86 M． Imai， Kaizen：The Kny to Japan’s Competitive Success， McGraw-Hill，
New York， NY， 1986
Juran88 J.M.Juran，Juran on Planning for quality, Macmlllan， New York,NY，1988．
Juran89 M.Juran，Juran on Leadership for Quality,The Free Press,New York,NY，1989．
Kitson92 D． H． Kltson and S． Masters， An Analysis。of SEI Software Process。
Assessment Results： 1987-1991． Software Engineering Instittute， CMU／
SEI－92－TR－24，JUly 1992．
Panlk91 M． C． Paulk， B． Curtis， M． B． Chrissis ， et al， Capability
Maturity Model for Software，Software，Engineeing Institute， CMIU／
SEI-91-TD-24，ADA240603，Atgtst 1991．
Paulk93a M．C．Paulk，B．Curtis，M．B．Chrlssls ，and C．V．Weber，CapabilltyMaturity
Model for Software， Verion 1． 1， Software EngineeringInstitUte， CMU
／SEI93-TR-24， February 1993·
Paulk93b M．C．Paulk， C．V．Weber， S．Garcia， M．B.Chrissis， and M．Bush，
Key Practices of the Capability Maturity Model， Version 1． 1， Software
Engineering Institute，CMU/SEI－93-TR-25 February 1993.
Radice85 R．A．Radice，J．T．Harding，P．E．Munnis，and R·W·PhillPs，‘A Programming
PrOCeSS StUdy，’IBM systems；journal，VO1．24，no．2， 1985．
Siegel90 J.A.I.Siegel，etal，National software Capacity：Near-Term Study，Software
Engineering Institute CMU／SEI－90－TR－12， ADA226694， May 1990.
Weber91 V． Weber， M． C． Paulk， C．J． WIse， and J． V． Withey，
Key Practices of the Capability Maturity model， Software Engineering
InstltUte，cmU／Sei 一91-Tr-25，AdA244644 August 1991·

4 运用CMM
CMM 建立一组公用、有效的描述成熟软件组织特征的准则。组织能运用这些准则去改
进其开发和维护软件的过程，政府或商业组织能用它们去评价与一特定公司签订软件项目合
同时的风险。
本章集中精力于两个SEI 研制的用以评估组织实施软件过程的成熟度的方法：软件过程
评估和软件能力评价。
?? 软件过程评信用于确定一个组织的当前软件过程的状态，确定组织所面临的具
有高优先级的与软件过程有关的问题，和获得组织对软件过程改进的支持。
?? 软件能力评价用于识别合格的能完成软件工作的承包商或者监控现有软件工
作中所运用的软件过程的状态。
仅本概述本身文才于读者进行评估或评价均是不充分的。任何希望通过这两个方法去运
用CMM 的人应该请求得到有关评估和评价培训的进一步的信息。
CMM 是软件过程评估和软件能力评价的共同基础。可是这两种方法的目的十分不同，
因此在所用的具体方法上存在重大差异。但是两者又都基于CMM 模型及从它导出的产品。
CMM 和基于CMM 的产品一起，使得可靠地、一致地使用这些方法成为可能。

5.2 近期活动
在遍及美国的主要会议和讨论班上经常举办短训班及讲课，以保证软件产业界对CMM
及其相关联的产品有足够的了解。正在研制基于CMM 的工具（例如，成熟度提问单），软
件过程评估培训和软件能力评价培训，和（或）正在修改它们以便纳入到CMM 中去。
CMM 开发活动的近期关注焦点是那些经剪裁的CMM版本，例如适用于小项目和（或）
小规模组织的CMM。CMM V1.1 是用适宜于大的政府签约组织的标准实践表达的，这些
实践必须加以剪裁才能适合不同于这个样板的组织的需要。
5.3 长期活动
在以后的几年内，通过在软件过程评估和软件能力评价中不断使用CMM，CMM 将继
续经受广泛的检验。适当时，将研制和修定基于CMM 的产品和培训资料。CMM 是一个将
得到改进的、正在使用的文件，但是预期至少直到1996 年CMM V1． 1 将仍然是基线。
这样就在稳定性和连续不断改进的需要之间提供合适的和切合实际的平衡。

5．4 结论
正如连续改进运用到软件过程一样，连续改进也运用到成熟度模型和实践。虽然，应该
认真考虑CMM 的更改对软件界的潜在影响，但是CMM、成熟度提问单、和软件过程评估
及软件能力评价等方法将随着有关软件过程改进方面经验的不断积累而不断地进化。SEI 打
算在进行此项进化工作上继续与工业部门、政府和学术界紧密合作。
CMM 提供了一种以有纪律的和一致的方式改进软件产品的管理和开发的概念结构。但
是它并不能保证软件产品将成功地构造出来，或者保证恰当地解决全部软件工程中的问题。
虽然CMM 能标识一个成熟软件过程的实践和提供某些当前最高实践水平的（并且在某种情
况下，是当前最高技术水平）的例子，但是这并不意味着它是详尽无漏的或是可以强制执行
的。CMM 只标识出有效软件过程的特征，但是成熟组织必须致力于对成功项目来说是必不
可少的全部问题，包括人、技术和过程。
6.参考文献
Brooks87 F.P.Brooks ”No Sliver Bullet ： Essence and Accldents of Software
Engineering”IEEE Ccomputer，Vo1.20，No.4，April 1987，pp.10-19
Crosby79 P.B.Crosby， Quality is Free， McGraw－Hill，New York，NY，1979．
Curtis90 B.Curtls, “Managing the Real Leverage In software Productivity and Quality, ”
American Programmer，Vo1.3，NO.7，July 1990，PP．4－14．
Deming86 W．Edwards Deming，Out of the Crisis ， MIT Center for Advanced
Engineering Study， Cambridge， MA， 1986·
DoD87 Report of the Defense Science Board Task Force on Military Software，Office of
the Under Secretary of Defense for Acqulsltion，Washington，D.C，September
1987．
Fagan86 M．E．Fagan，’Advances In software lnsPectlons，"IEEE Transactions on
Software Engineering， Vo1． 12， No· 7， July， 1986， PP． 744-751．
Fowler90 P． Fowler and S．Rifkin， Software Engineering Process Groop Guide，
Software Engineering Institute ， CMU／ SEI-9O-TR-24 ， ADA235784 ，
September，1990．
Freedman 90 D.P.Freedrnan and G.M.Welnberg，Handbook of Walkthrughs ， Inspections ，
and Technical Reviews，Third Edition， Dorset Hbuse，New York，NY，1990。
Gabor90 A.Gabor，The Man who Discovered Quality，Random House，New York，NY，

1．1 致读者
对许多软件组织来说，要在预算内按时开发出可靠和可用的软件是一项困难的工作。软
件产品延期交付、或超出预算、或不能如预期的那样工作也给软件组织的顾客带来麻烦。随
着项目规模和重要性不断增长，这些难题日益严重。但是通过在建立有效软件工程实践和管
理实践的过程基础设施方面集中而又持续不断的努力，这些困难能得以克服。
为了构造这个过程基础设施，生产软件的组织需要有办法评价他们成功地执行其软件过
程的能力。他们也需要有指南帮助他们去改进其过程能力。诸如国防部（DOD）这样的顾
客需要有方法更有效地评价一个组织成功地执行软件工程合同的能力。主承包商需要有手段
去评价潜在子承包商的能力。
为了帮助软件组织、像DoD 那样的顾客、以及主承包商，软件工程研究所（SEI）已经
开发出软件能力成熟度模型（CMM），它描述一个成熟的、有能力的软件过程的特征。此模
型还按成熟度等级描述了从一个不成熟、不可重复的软件过程到成熟的、已妥善管理的软件
过程的进展状态。
CMM 可用于：
?? 软件过程改进，为此组织策划、设计和实施对其软件过程的更改；
?? 软件过程评估，为此一个经培训的软件专业人员组确定组织当前软件过程的状态、
确定组织所面临的具有高优先级的软件过程一有关问题，并获得组织上对软件过程
改进的支持；
?? 软件能力评价，为此一个经培训的软件专业人员组鉴别合格的能完成软件工作的承
包商或监控现有软件工作中所用软件过程的状态。
本文件描述与CMM 中每个成熟度等级相对应的关键实践。它详尽阐述在CMM的每一
等级上成熟度的含义，并且是一份可用于软件过程改进、软件过程评估、和软件能力评价的
指南。
CMM 的关键实践是用那些进行大的、政府合同工作的组织应该具有的标准实践来描述
的。因此，在任何一种运用CMM 的上下文中，必须采用有关如何运用这些实践的合理解释。
本文件的第四章中包含有关解释CMM的指南。当组织的经营环境明显不同于大的签约
组织的经营环境时，必须恰当地解释CMM。必须承认在有根据地使用CMM 方面专业判断
的作用。

2．3 CMM 的结构
CMM 由五个成熟度等级组成。除了等级1 外，每个成熟度等级由几个关键过程区域组
成。每个关键过程区域又划分为五个称作共同特点的部分。共同特点规定一些关键实践，当
这些关键实践群体得到认真执行，能实现关键过程区域的目标。图2．1 中显示了CMM 的
这个结构。
CMM

CMM 的成分包括：
成熟度等级
（Maturitylevels）
一个成熟度等级是在朝着实现成熟软件过程进化选中的一个妥善
定义的平台。五个成熟度等级提供CMM 的顶层结构。
过程能力
（ProcessCapability）
软件过程能力描述通过遵循软件过程能实现预期结果的程度。一个
组织的软件过程能力提供一种预测组织承担下一个软件项目时预

期的最可能结果的方法。
关键过程区域
（KeyProcessareas）
每个成熟度等级由若干关键过程区域组成。每个关键过程区域标识
出一串相关的活动，当它们作为群体完成时，就达到一组目标，此
组目标对建立该过程成熟度等级是至关重要的。关键过程区域是分
别定义在各个成熟度等级并与之相连在一起的。例如，等级2 的一
个关键过程区域是软件项目策划。
目标
（Goals）
目标概括一个关键过程区域中的关键实践，并可用于确定一个组织
或项目是否已有效地实施该关键过程区域。目标表示每个关键过程
区域的范围、边界和意图。例如，软件项目策划关键过程区域的一
个目标是“软件估计已文档化，供策划和跟踪软件项目使用。”参
见“软件能力成熟度模型，1．1 版”[Paulk93a]和本文的4．5 节（即
运用专业判断），能得到更多的有关解释目标的信息。
共同特点
（CommonFeatures）
将关键实践分别归入下列五个共同特点中：执行约定、执行能力、
执行的活动、测量和分析、及验证实施。共同特点是一种属性，它
能指示一个关键过程区域的实施和规范化是否是有效的、可重复的
和持久的。执行的活动这个共同特点描述实施活动。其余四个共同
特点描述规范化因素，它们使得过程成为组织文化的一部分。
关键实践
（KeyPractices ）
每个关键过程区域用若干关键实践加以描述，当实施这些关键实践
时，能帮助实现该关键过程区域的目标。关键实践描述对关键过程
区域的有效实施和规范化贡献最大的基础设施和活动。例如，软件
项目策划这个关键过程区域的一个关键实践是“按照已文档化的规
程制定项目的软件开发计划”。

每个成熟度等级为连续过程改进提供一层基础。每个关键过程区域包含一组目标，当这
组目标实现时，就使得软件过程的一个重要成分稳定。达到成熟度模型中的每一个等级，都
使得软件过程的一个不同的成分规范化，导致组织过程能力的整体增长。

2.4.1 等级1——初始级
在初始级上组织一般不能提供开发和维护软件的稳定环境。当组织中缺乏健全的管理实
践时，无效的策划和反应驱动的保证体系会削弱好的软件工程实践所带来的受益。
在危机时刻，项目一股抛弃预定的规程，回复到仅作编码和测试。成功完全依赖于有一
个杰出的经理及一支有经验的、战斗力强的软件队伍。偶尔，有能力的、坚强的软件经理能
经受住要他们在软件过程中走捷径的压力，但是当他们离开项目后，他们能使过程稳定的影
响也随之消失。甚至一个强的工程过程也不能克服由于缺乏健全的管理实践所造成的不稳
定。
等级1 组织的过程能力是不可预测的，因为随着工作进展软件过程经常被改变或修定
（即过程是无秩序的（adhoe))。进度、预算、功能性和产品质量一般是不可预测的。性能

依赖于个人的能力，且随个人固有的技能、知识和动机的不同而变化。等级1 组织几乎没有
明显的稳定的软件过程，只能通过个体的能力而不是组织的能力去预测性能。

2.4.2 等级2——可重复级
在可重复级上，已建立管理软件项目的方针和实施这些方针的规程。基于在类似项目上
的经验对新项目进行策划和管理。达到等级2 的目的是使软件项目的有效管理过程制度化，
这使得组织能重复在以前项目上所开发的成功实践，尽管项目所实施的具体过程可能不同。
一个有效过程可特征化为实用的、已文档化的、已实施的、已培训的、已测量的和能改进的。
等级2 组织中的项目已设置基本的软件管理控制。实际可行的项目约定是基于对以前项
目的观察结果和当前项目的需求。项目的软件经理跟踪软件成本、进度和功能；识别在满足
约定方面出现的问题。对软件需求和为实现需求所开发的工作产品建立基线，并控制其完整
性。软件项目标准已确定，并且组织能保证准确地执行它们。如果有子承包商的话，软件项
目与他们一起努力建立一种强有力的顾客一供应商关系。
等级2 组织的过程能力可概括为有纪律的，因为软件项目的规划和跟踪是稳定的，能重
复以前的成功。由于遵循实际可行的基于以前项目性能的计划，项目过程处在项目管理系统
的有效控制之下。

2.4.3 等级3——已定义级
在已定义级上，全组织的开发和维护软件的标准过程已文档化，包括软件工程过程和软
件管理过程，而且这些过程被集成为一有机的整体。在CMM中的所有地方，均称此标准过
程为组织标准软件过程。运用等级3 上所建立（适当时，经更改）的过程，以帮助软件经理
和技术人员工作得更有效。组织在使其软件过程标准化时，利用有效的软件工程实践。存在
一个负责组织软件过程活动的组，例如软件工程过程组（SEPG）[Fowle90]。实施全组织的
培训计划以保证职员和经理具有履行其职责所必须的知识和技能。
项目通过剪裁组织标准软件过程去建立他们自己定义的软件过程，它说明项目独有的特
征。在CMM 中，这种剪裁后的过程称作项目定义软件过程。一个已定义软件过程包含一组
协调的、集成的、妥善定义的软件工程过程和管理过程。妥善定义的过程可特征化为具有准
备就绪判据、输入、标准、进行工作的规程、验证机制（例如同行评审）、输出以及完成判
据。因为软件过程已妥善定义，管理者就能洞察所有项目的技术进展。
等级3 组织的软件过程能力可概括为标准的和一致的，因为无论软件工程活动还是管理
活动，过程都是稳定的和可重复的。在所建立的各种产品线（Productlines）内，成本、进度
和功能性均受控，对软件质量也进行跟踪。这种过程能力建立在整个组织范围内对已定义过
程中的活动、角色和职责的共同理解之上。