赛宝认证中心/徐俊、毛明志

摘要

本文介绍了软件能力成熟度模型历史、发展与现状，阐述了该模型主要研究内容，分析了模型在确认与验证中的具体应用。对成熟度模型在中国、美国、印度公司的应用情况了简单比较。针对中国公司的应用情况进行了详细的阐述。对能力成熟度模型未来进行了展望。

关键字：软件能力成熟度模型，验证与确认，进展

1 绪论 

模型是真实世界的简化的表示，CMM是指“能力成熟度模型”，是一种用于评价软件承包能力并帮助其改进软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。是对于软件组织在定义、实施、度量、控制和改进其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。

能力成熟度模型SW-CMM包括多个学科的（BOK，Bodies of Knowledge)有效过程的必要元件，CMM基于众多软件专家的实践经验，是组织进行软件过程改进和软件过程评估的一个有效的指导框架，是以Deming、Juran以及Crosby的概念为基础所开发而来。CMM或CMMI不仅是一个模型，一个工具，它更代表了一种管理哲学在软件工业中的应用。SW-CMM的管理思想来源于已有60多年历史的历史的产品质量管理和全面质量管理。1930年，Walter Sheward 率先提出了一整套基于统计学原理的质量控制方法，这些方法后来经过W. Ewards Deming和Joseph Juran的发展和实践得到了广泛的应用。Philip Crosby在《质量是免费的》一书中率先提出将质量管理形成成熟度框架的概念，“质量管理成熟度坐标图表” 描述了进行质管实践的5个阶段，表达了质量管理的全部运作。Deming、Juran以及Crosby等人的做法后来被称为全面质量管理（TQM）理论。在Watts Humphrey和Ron Radice将这种全面质量管理的思想应用于软件工程过程，收到了很大的成效。

SEI的软件能力成熟度框架就是在以Humphrey为主的软件专家实践经验的基础上发展而来的。软件能力成熟度框架中融合了全面质量管理的思想，以5个不断进化的层次反映了软件过程定量控制中项目管理和项目工程的基本原则。SW-CMM所依据的想法是只要不断地对软件企业的软件工程过程的基础结构和实践进行管理和改进，就可以克服软件生产中的困难，增强开发制造能力，从而能按时地、不超预算地制造出高质量的软件。CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。

CMMI项目更为工业界和政府部门提供了一个集成的产品集，其主要目的是消除不同模型之间的不一致和重复，降低基于模型改进的成本。CMMI将以更加系统和一致的框架来指导组织改进软件过程，提高产品和服务的开发、获取和维护能力。 CMM同时为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟

CMM主要应用在两大方面：能力评估和过程改进。

1）能力评估

CMM是基于政府评估软件承包商的软件能力发展而来的，有两种通用的评估方法用以评估组织软件过程的成熟度：软件过程评估和软件能力评价。

软件过程评估：用于确定一个组织当前的软件工程过程状态及组织所面临的软件过程的优先改进问题，为组织领导层提供报告以获得组织对软件过程改进的支持。软件过程评估集中关注组织自身的软件过程，在一种合作的、开放的环境中进行。评估的成功取决于管理者和专业人员对组织软件过程改进的支持。

软件能力评价：用于识别合格的软件承包商或者监控软件承包商开发软件的过程状态。软件能力评价集中关注识别在预算和进度要求范围内完成制造出高质量的软件产品的软件合同及相关风险。评价在一种审核的环境中进行，重点在于揭示组织实际执行软件过程的文档化的审核记录。

2.）过程改进

软件过程改进是一个持续的、全员参与的过程。CMM建立了一组有效地描述成熟软件组织特征的准则。该准则清晰地描述了软件过程的关键元素，并包括软件工程和管理方面的优秀实践。企业可以有选择地引用这些关键实践指导软件过程的开发和维护，以不断地改进组织软件过程，实现成本、进度、功能和产品质量等目标。

CMMI分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。，CMMI是以增量方式逐步引入变化的。CMMI明确地定义了5个不同的“成熟度”等级，一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。

Ⅰ 初始级 软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。

Ⅱ 已管理级 建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。

Ⅲ 已定义级 已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。

Ⅳ 量化管理级 分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。

Ⅴ 优化管理级 过程的量化反馈和先进的新思想、新技术促使过程持续不断优化改进。国际标准化组织ISO9000系列质量保证体系用于制造业的是ISO9001(在软件行业的实施指南 为ISO9000-3)，与CMM均可作为软件企业的过程改进框架，前者面向合同环境，站在用户立场对 质量要素进行控制，而后者是对软件组织内部过程能力的逐步改进。 

ISO9001与CMM是强相关的，ISO9001不覆盖CMM，CMM也不完全覆盖ISO9000。一般言，通过ISO 9001认证的企业可达到CMM 2级或略高的程度，通过CMM 3级的企业只要稍做补充，就可较容易地 通过ISO 9001认证。粗略地说，ISO 9001近似于CMM “2.5级”。 ISO 9001约有80%的文件可以用于CMM 2级评估。

2 CMM/CMMI发展简介

为了保证软件产品的质量，80年代中期，美国联邦政府提出对软件承包商的软件开发能力进行评估的要求。1984年在美国国防部的支持下，卡内基梅隆大学成立了软体工程研究所（CMU/SEI）；于1986年11月，在Mitre公司的协助下，开始发展一套帮助软件企业改进软件过程过程成熟度架构（process maturity framework），SEI于1987年研究发布了软件过程成熟度框架，并提供了软件过程评估和软件能力评价两种评估方法和软件成熟度提问单。1991年SEI将软件过程成熟度框架进化为软件能力成熟度模型（Capability Maturity Model For Software，简称SW-CMM），并发布了最早的SW-CMM 1.0版。经过两年的试用，1993年SEI正式发布了SW-CMM1.1版，这是目前使用最为广泛的版本。按照SEI最初的计划，应该在1998年发表SW-CMM的2.0版。

目前，CMM已经发展到CMMI（Capability Maturity Model Integration，能力成熟度模型集成）阶段。由于软件过程评估（SPA）国际标准项目的进展，美国国防部下令暂时停止推进到SW-CMM 的2.0版，以便吸收SPA的长处，于是便产生了CMMI（集成CMM）。2000~2001年SEI发表了《系统工程和软件工程综合能力成熟度模型》（CMMI-SE/SW）1.0版和CMMI-SE/SW 1.1版以及《系统工程、软件工程和集成产品与过程开发的综合能力成熟度模型》（CMMI-SE/SW/IPPD）1.1版。就软件而言，CMMI是SW-CMM的修订本。事实上，它兼收了SW-CMM 2.0版C稿草案和SPA中更合理、更科学和更周密的优点。SEI不断地延展CMM意涵与适用性，如今的CMMI模式包含了系统工程（SystemsEngineering,SE）、软件工程（SoftwareEngineering,SW）、集成产品与过程开发（Integrated Productand Process Development,IPPD），以及外包管理（Supplier Sourcing,SS）四个专业领域。自20世纪80年代末以来，SEI开发了一系列涉及多个学科的CMM标准，包括系统工程、软件工程、软件获取、生产力实践及集成产品和过程开发，希望通过帮助组织提高人员、技术和过程的成熟度来改进组织整体软件生产能力。然而，多个模型的同时使用限制和阻碍了组织过程改进的能力。于是，SEI中止了对CMMI源模型的更新，开始集中开发CMMI项目。CMMI项目融合了SW-CMM v2.0 draft C、EIA/IS731、SECM以及IPD-CMM v0.98的内容，形成了组织范围内过程改进的单一集成模型。CMMI项目为工业界和政府部门提供了一个集成的产品集，主要目的是消除不同模型之间的不一致和重复，降低基于模型改进的成本。未来的CMMI将以更加系统和一致的框架来指导组织改进软件过程，提高产品和服务的开发、获取和维护能力。

SEI于2006 年发布了CMMI v1.2 for Dev，扩展新领域(如，服务、采购)至模型架构中； 发行集成的CMMI阶段式及连续式两种表现法的合订本；* 删除advanced practices and common features的概念；* 精简了集成的产品与过程开发材料,* 将供应商资源supplier sourcing (SS)纳入基础模型；* 增加硬件相关的范例。另外从CMMI v1.2 for Dev版本开始，1.3的SCAMPI方法明确规定评估有效期为3年。SEI于2010年10月28日发布了CMMI模型的新版本CMMI® for Development V 1.3，SCAMPI并宣布从2011年11月30日之后不再接受V1.2的评估数据，也就是说从2011年11月30日之后新的评估都要采用V1.3模型，评估有效期为3年。新版本V1.3模型取消了软件工程、硬件工程、系统工程等工程学科的单独描述，也不再有IPPD的概念。对成熟度4级和5级的过程域做了详细描述，并将原有的组织创新和部署（OID）改为组织绩效管理（OPM）。在CM, PI, PP, PPQA, RD, REQM, RSKM, TS和VER增加敏捷方法的描述。并在OPD增加SP1.7 建立团队的规则和指南，在IPM增加SP1.6 建立团队。并对原有模型不清楚的地方做了进一步澄清。

2012年5月CMU宣布将成立CMMI业务从SEI独立出来，成立新的CMMI Institute负责对CMMI模型的维护。

3 CMM研究的关键问题及与Ｖ＆Ｖ之间的关系

3.1 CMMI与敏捷过程的融合

CMMI与敏捷是两种不同的软件研发管理和过程体系，敏捷与CMMI共同的目标是：多快好省的做出产品，满足客户需求； 两者都是业界最佳实践总结，成功经验的积累和传播；CMMI模型包容性较强，推荐但不限于模型中提出的相关具体实践。区别在于前者属于重量级的项目过程控制，后者相对属于轻量级。敏捷开发包含了更多具体、实用的软件工程技术方法，而 CMMI 提供了更多以数学统计为基础的过程管理和质量控制技术方法。在适用条件下，轻量过程通常会带来了更高的开发效率。敏捷不但注重个人，也注重团队和组织。敏捷可以分为三个层次：敏捷个人、敏捷团队、敏捷企业。CMMI 与敏捷都注重组织、团队，敏捷 更强调发挥个人的主观能动性。由于价值观、出发点和适用条件不同，导致两者的具体做法和关注面有所不同。Agile和CMMI是两种比较常用的过程改进的模型或方法论。对于大多数中小型应用软件开发的企业，如何将两者结合，使过程既能发挥Agile的敏捷与持续交付特点，又能发挥CMMI等成熟过程的可预见性与可管理性的特点是一个研究的热点问题。

一项敏捷实践应该经过裁剪以适应组织实际的成熟度级别；实施敏捷不但可以获得敏捷带来的重要好处，还可以减少返工，并全面提高推行CMMI的积极性。如果实施的软件开发过程既能遵循CMMI规范，又能符合敏捷原则，我们就可以真正获得CMMI提出的可重复性和可预测性的好处。敏捷特意设计得非常灵活，因此它可以在不违反敏捷宣言所规定的主要目标的前提下，裁剪为遵循CMMI规范的软件开发过程。针对特定的项目，还要从组织的标准过程集中裁剪出相应的标准、过程描述及过程。因此，实施敏捷的主要工作就是为集成敏捷实践而修改那些标准过程。实施敏捷的风险集中在管理开销上，因为组织的管理模式可能会限制团队的自主决策权及灵活性。 

3.1.2有效实施CMMI的方法论研究

尽管CMMI模型只是提供了一套基本的过程改进的框架，提供了改进的一般性的指导原则，但是具体企业在实施CMMI时候还要结合具体的企业控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法进行结合。CMMI的有效实施，涉及到软件工程的很多研究领域及实际问题有关，主要相关领域和因素有：项目估算技术需求工程。软件复用，软件移植，知识管理，机器学习等。提供这些学科的融合可改进软件产品质量和生产率。还有软件检查、软件测量分析、软件可靠性研究、软件可维修性、软件工具评估和选择等。需要结合CMMI模型的相关实践要求，考虑建立一套实施的方法论。

3.1.3 CMMI中VER & VAL的问题讨论

为了确保工作产品能够满足用户的需求和产品实际运行环境的需求，需要建立和维护验证和确认的方法、流程、标准和验证环境。在整个产品开发周期中，在不同的时间点对各个工作产品进行同行评审，验证测试和确认，以确保产品符合用户需求。

验证与确认的关系如下图所示：

验证与确认的关系图

验证是按照既定的标准，检查工作产品是否符合要求。工作产品可能是文档也可能是软件本身。而检查的办法一般是同行评审或者是软件测试。

而确认强调的是，在真实的使用环境中，确保软件能够达到预期的效果。开发环境与真实环境是不可避免存在差异的，为了有效地避免在开发环境中没有问题，但一到真实环境就出现问题的情况，确认的工作是非常重要的。确认使用的方法与验证使用的方法相似，但是两者关注点是不同的。

验证的目的是保证选择的工作产品满足其指定的产品需求或者用户需求。验证活动贯穿于工作产品的整个开发过程中：从验证需求开始，然后对工作产品进行验证，最后对完成的产品进行验证。验证活动主要包括以下两个方法：同行评审及测试，这里的测试包括单元测试、集成测试、系统测试等。

确认的目的是证实工作产品和产品组件置于最终用户环境时满足预期的使用要求。确认活动应该尽量提早进行，并且贯穿于整个软件开发生命周期内。在需求开发阶段对需求开发的结果进行确认，在设计阶段对设计方法进行确认，在代码编写阶段对代码进行确认，在产品集成后对产品进行确认。确认的工作产品包括各开发阶段的相关产品和最终的交付产品。例如：需求分析报告书、功能设计阶段的设计文档、测试用例，测试结果、源代码。可以根据项目开发的实际情况，针对不同确认对象确定不同的确认活动方式。常用的确认方式有：评审、原型、仿真程序、测试、α测试、β测试、验收测试等。将确认结果和预先制定的确认标准进行比较，判断是否符合最终用户的需求。

4 CMM/CMMI应用

CMMI 作为专门针对软件行业的一个过程改进方法和规范，是衡量软件外包质量的重要标准之一，有如国内软件企业进入国际软件外包市场的通行证，CMMI 的引入和实施对于提高我国软件企业的管理水平和企业竞争力起着重要的作用。从 1999 年国内公司首次通过 CMM 二级评估，到今天的近千家企业维持CMMI的资格。

在1989年至1999年，在中国，北航软件工程研究所的周伯生教授开始对CMM进行研究。还有国防系统和大学的研究部门，他们跟踪美国及世界最新动向。尽管Motorola（中国）公司称他们在1993年开始实施CMM，并于1996年达到CMM三级，但在当时的中国，CMM框架 还未引起业界的普遍重视，还处于观察和研究期。1999年，由IBM和清华同方合资成立的北京鼎新信息系统开发有限公司在7月6日宣布通过CMM二级的评 估，在2000年，2000年国家发布的关于促进IT业发展的18号文件，明确指出“鼓励软件出口型企业通过GB／T19000－ISO9000系列质量保证体系评估和CMM评估。在中国CMM由以研究为主转为向企业推广实施。各地方政府依据中央精神，制定了不同的奖励制度，同时从政府项目招标，软件企业资格评估等方面对通过了CMM评估的企业进行倾斜。在行业的发展需 要、政府的及国内专家的技术支持下，一些业界领先企业首先实施了以CMM的过程改进和评估。2002年至2009年。在政策的引导和业界领先企业成功实施CMM的示范作用下，中国掀起了CMM/CMMI评估的高峰。看到了基于CMM进行的改进和评估的数量逐年成倍几增长，2001年以前总和18个,2002年100个. 截至到2012年5月26日，SEI公布的3年有效（2009.5.26-2012.5.26）的CMMI评估数据如下：

截至到2013年9月10日，CMMI Institute公布的3年有效（2010.9.10-2013.9.10）的CMMI DEV模型评估数据如下:

从上述数据对比来看，这里面CMMI企业中国还继续处于上升趋势，美国和印度呈现一定程度的下滑。现在中国的CMMI评估总数量已经远远超过发达中国家，且已经到达可全球第一。但是高成熟度中5级企业的数量还不如美国及印度。另外目前被评估企业主要集中在3级，2级企业相对美国数据偏少，这也说明坚持从基础2级开始实施的改进的企业相对比较少。

面对方兴未艾的 CMM/CMMI 评估认证热潮, 如果只是类似于 ISO9000 在中国的历程和现状, 则采用只片面追求证书的形式主义的跟进,这种做法必然只能给中国的企业带来更大的创伤。CMM/CMMI 虽然不是万能的, 但毕竟为中国软件企业走向规范化、 规模化、 成熟化创造了一个良好的契机。据《 2011 中国 CMMI咨询机构年度评选调查报告》有 23.72%的被调查者认为，企业实施 CMMI 能保证软件开发的质量与进度，规范开发过程。该项数据在2010年为 17.28%。企业选择 CMMI 咨询机构时，越来越注重咨询机构的口碑，有 30.29%的企业把其作为选择首要因素。该项数据在 2010 年为27.17%。地方政府出台了对企业通过CMMI评估进行资金补助等鼓励政策， 具体落实起来依然比较困难，但状况有所缓解，该项数据由2010 年的 39.27%降为 33.19%。拿政府的钱, 为自己贴金: 在 CMM/CMMI 评估热的前期, 各地政府均出台了不同的优惠和鼓励政策, 因此各地符合政策支持条件的软件企业都纷纷响应这个“投资少又能赚名誉” 的好事。但这时的许多企业领导者还有许多对 CMM/CMMI 到底是什么, 能有什么用都还没有搞清楚。

企业通过CMMI评估所花费的时间在缩短，如实施CMMI3级从10年的15个月缩短为9.2月。因此，CMMI实施质量问题值得关注。另外一个方面，企业希望通过CMMI评估来改进软件过程，提高开发和管理能力的期望却在提高,企业进行CMMI资讯评估工作的主要目的19.37%为仅为过级，34.15%为实施过程改进，提高企业开发能力,加强管理能力；46.48%为二者因素都有。推进CMMI实施过程中存在缺乏有经验的团队、领导支持力度不够，做形象工程、员工有抵触情绪、缺乏好的咨询机构支持、持怀疑态度、规范和流程往往不能有效执行等原因。但现在 CMM/CMMI 狂热的阶段已经过去, 逐渐进入了平静期，2010以后，目前各地对于基础级2-3级政策扶持的基本到期，大浪淘沙，以后只有真正的坚持改进的或者有一定实力规模的企业才会坚持维持CMMI资格。人们有了更多的认识与思考, 也从第一批通过评估认证的企业中看到了正面的、负面的榜样。毕竟, 软件过程改进是一个正确的方向, 是产业提升的必由之路, 因此软件企业仍然存在着这方面的需求。今后CMMI评估实施需求会更加趋于理性、更加趋于务实。

国内也推出基于CMMI的SPCA认证，又称“双模认证”。是软件过程能力评估和软件能力成熟度评估的统称。为了贯彻国务院18号文件精神，加快发展我国软件行业，提高国内软件企业的竞争力，信息产业部会同国家认证认可监督委员会，在研究了国际软件评估体制尤其是美国卡内基-梅隆大学SEI所建立的能力成熟度模型CMMI 1.0的基础上，考虑国内软件产业实际情况，于2001年建立了SPCA评估体系。SPCA所依据的评估标准是我国制定的SJ/T 11234《软件过程能力评估模型》和SJ/T 11235《软件能力成熟度模型》。但是由于政策性原因，目前国内企业实施SPCA的寥寥无几。

为解决军用软件研制过程中出现的问题，促使军用软件承制单位尽快提高其软件过程能力，降低军用软件的风险，总装备部于2008年3月30日发布了GJB5000A-2008标准《军用软件能力成熟度模型》，从2008年06月1日起开始实施。GJB5000A标准的制定旨在引进国外先进的管理经验，提高我国军用软件的质量，其目前已成为我国武器装备软件建设和发展的事实上的标准。GJB5000A标准的目标就是不断改进软件生产工艺，提高产品质量。GJB5000A标准是以CMMI-DEV 1.2版为基础制定的军用软件能力成熟度模型集成，不仅给出相关过程成熟度的描述内容，还给出改进模式的指导和评估/评价模式的指导，可以说是一个针对武器装备软件开发团队的过程改进体系。GJB5000A为国防单位提供了一个系统的软件开发过程改进框架，在实践过程中还需要具体管理和技术平台的支持，才能更有效的结合软件开发的生命周期和项目管理过程。目前国防系统嵌入式应用日趋复杂，而由于竞争要求产品快速上市，开发技术日新月异，而软件故障却日益突出。同时，由于来自上层的需求经常变化，导致应用系统的版本和变更管理的瓶颈日渐成为开发过程的瓶颈。国防单位要承接软件开发项目，需要通过GJB-5000A至少二级的成熟度要求，软件的流程管理逐渐引起人们的重视。

5 结论与展望

从SEI提出CMM模型以来，一直到现在CMMI 1.3模型，随着软件工程相关学科的进展，CMMI模型也呈现不断与时俱进的的改进趋势。随着越来越多的中国企业通过了CMMI评估以及各地政府支持政策的减弱，在一段时间内会有一定程度的降温，但是国内的软件企业在不断的发展壮大，管理的需求也会日益突出，而且不断有新的软件企业成立，所以，以CMMI为代表的管理规范化标准也会继续有市场。中国的软件企业已经开始走上标准化、规范化、国际化的发展道路，中国软件业已经面临一个整体突破的时代。过程改善工作是一把手工程这个关键因素外，还应认识到软件过程成熟度的升级本身就是一个过程，且有一个生命周期。过程改善工作需要循序渐进，不能一蹴而就，需要持续改善，不能停滞不前；需要联系实际，不能照本宣科；需要适应变革，不能凝固不变

参考文献

1,罗耀秋,运用Agile达到CMMI成熟度级别要求，http://www.uml.org.cn/SoftWareProcess/201006025.asp

2，CMMI评估结果公告，https://sas.村民米Itute.edu/pars/pars.aspx

3，张友生，徐 锋，CMM_CMMI在中国的实施状况调查报告，计算机工程与应用，2006.07

4，希赛顾问团，2011 中国 CMMI咨询机构年度评选调查报告 ，http://ccse.csai.cn/2011/cmmi.pdfhttp://ccse.csai.cn/2011/cmmi.pdf，2011.12

5，李华北等，过程改进基本原理及CMMI实施，中国标准出版社，2009.11

作者简介：

徐俊（1973-），男，籍贯江苏射阳，硕士，赛宝认证中心高级工程师，信息系统项目管理师，研究方向为软件工程、软件过程改进、软件质量管理。

毛明志（1966-），男，籍贯湖南，博士，中山大学副教授，研究方向为软件工程、CMMI、智能规划与应用。。