1986年11月，美国联邦政府委托卡内基梅隆大学（Carnegie-Mellon）软件工程研究所（SEI）开发一套用于评估软件承包商能力的方法。SEI于1987年9月发布了一套软件过程成熟度框架和一套成熟度问卷。1991年，SEI将软件过程成熟度框架发展成为软件能力成熟度模型（Capacity Maturity Model，CMM），诞生了CMM 1.0。1993年，SEI推出了CMM 1.1，这是目前世界上应用最广泛的CMM版本。

十几年来，CMM的改进工作一直不断地进行。美国国防部希望把现在所有的、以及将被开发出来的各种能力成熟度模型，集成到一个框架中去。到2000年，CMM演化成为CMMI（Capability Maturity Model Integration，能力成熟度模型集成）。CMMI不仅适合软件，而且适合于软件硬件结合的系统，这是对CMM最大的改进。

从20世纪90年代至今，软件过程改进成为软件工程学科的一个主流研究方向，其中CMM和CMMI是该领域举世瞩目的重大成果。CMM/CMMI是世界范围内用于衡量软件（硬件）过程能力的事实上的标准，同时也是软件（硬件）过程改进最权威的指南。

CMM将能力成熟度分为5个级别，这5个成熟度等级为评价机构软件过程能力提供了一个有序的级别，如图1-2所示。同时也为机构的软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一步地改进过程能力而不是企图跳跃式地前进。

图1-2 CMM的5个能力成熟度等级

人们往往搞不清楚CMM和软件过程改进的关系，将二者混为一谈。下面作个比喻来解释：

把“软件过程改进”比喻为“学英语，提高英语能力”，那么CMM就好比是“英语等级评估标准（考试大纲）”。一般情况下，英语等级考试的成绩反映了英语能力。但是，在特别擅长应试的中国，英语考试成绩很好并不见得英语能力很好，甚至可能差到“哑巴英语”的程度。这种“特性”传染到软件领域，不少企业虽然通过了高级别的CMM等级评估，但是其实际能力却非常低下。

软件过程改进的真正目的是提高机构的软件过程能力，而不是为了达到CMM高等级。“汝果欲写诗，功夫在诗外”，这是很好的启示。

2000年至2003年，我在上海贝尔有限公司负责CMM/CMMI的研究和推广工作，公司的每个事业部都有软件（硬件）过程改进人员。公司在CMM/CMMI过程改进方面的投入巨大，取得一些成效，但是没有达到我的期望值。感慨很多，一言难尽。此处，我对CMM/CMMI过程改进做个简要的评论，供同行企业参考。

一、CMM等级评估：从狂热回归理性

2000－2003年是国内IT企业搞CMM等级评估最狂热的时期，主要原因有：

（1）2000年，CMM刚刚在国内兴起，感兴趣（学习、研究）的人非常多。近几年国内出版了不少关于CMM、软件过程改进的书籍，相关论坛、会议也比较多。有良好的群众基础。

（2）那个时候ISO9000认证已经被国人搞臭了，而当时国内CMM 等级评估还很少见，企业达到CMM 2级、3级是很荣耀的事情。物以稀为贵，人们把认证的目光从ISO9000转向了CMM。

（3）为了扶持当地软件企业，鼓励软件出口，各地方政府相继出台了“资助企业搞CMM等级评估的政策”。最先搞CMM评估的企业尝到了甜头，自己拿到了比较吃香的CMM等级证书，昂贵的评估费用大多由政府支付了。这一剂催化剂，进一步激发了企业搞CMM评估的热情。

2000－2003年期间，国内有数百家企业通过了CMM 2级、3级评估，大部分企业搞CMM评估是“为了拿证书”而不是“真正提高软件过程能力”。

到2004年，国内CMM评估从狂热回归理性。主要原因有：

（1）地方政府基本上不再资助企业搞CMM等级评估了。企业自己掏钱搞CMM评估就舍不得了，要掂量是否值得（理性的表现）。

（2）由于国内通过CMM 2级、3级评估的企业已经很多，而且评估时“放水”现象严重，CMM评估的声誉已经大不如2000年。

（3）最让人失望的是，虽然有些企业通过了CMM 2级、3级评估，但是实际的软件过程能力却依然底下。有些企业实施CMM后，质量没有明显提高，进度更落后了，成本增加了，人员更累了。

现在软件业界普遍关注的是：企业如何以比较低的代价有效地提高软件过程能力。CMM等级评估则退居次要地位。

二、CMM的盲区和常见应用问题

用CMM指导企业的软件过程改进工作是相当不错的，但是企业要做的重要事情显然不仅是软件过程改进。企业最关注的是生存和发展问题，一切离不开赚钱。

CMM本身不谈如何赚钱的问题。它假设了美好的前提条件，即企业有充足的人员、资金、时间从事软件过程改进，当软件过程能力提高了，那么产品的质量、生产率自然上去了（同时成本也下降了），企业自然能够获取更多的利润。软件过程改进对企业经济效益的贡献是间接的，从投入到产出，时间相对比较长。

遗憾的是，国内大部分企业没有能力提供那么好的前提条件，企业最缺乏的资源往往就是人员、资金和时间，企业领导当然想把资源用在“刀刃”上，即赚钱最多最快的地方。当软件过程改进和其它直接赚钱的事情“发生资源冲突”时，只好“拆东墙，补西墙”，往往减少软件过程改进的资源。

如果完全按照CMM的要求遍历“18个关键过程域和百余个关键实践”的话，无疑会占用大量的资源，资源冲突在所难免，失败的风险很高。所以切勿照搬CMM，一定要根据企业的实际情况（企业发展战略、产品特征、资源状况）给出软件过程改进的措施。

CMM对软件项目管理和机构过程管理论述很深入，但是对软件开发的核心工作即“需求开发、软件设计、编程、测试、维护”论述非常少，CMM把它们压缩为一个过程域叫做“产品工程”（Product Engineering），近乎一笔带过。所以导致一个怪现象，管理人员觉得CMM真是好，而大量开发人员学了CMM后却很是迷惘，感觉CMM对他们的开发工作没有直接的指导。

CMM方法论有个明显的倾向，即“管理的规范化”重于“开发的规范化”。CMM 2级的6个关键过程域全部是论述项目管理的，而唯一论述“需求开发、软件设计、编程、测试、维护”的“产品工程”关键过程域则放在CMM 3级。

对于国内大多数软件项目而言，技术开发占总工作量的80％以上，而项目管理占总工作量的20％以下，因为企业销售的是软件产品，而不是管理。明眼人都看得出，技术开发的规范化要比项目管理的规范化尤为重要与迫切（至少也是同等吧）。

由于CMM强调过程改进要循序渐进，不要跳跃式前进。人们自然而然地会先把精力集中在CMM 2级的6个关键过程域上，而忽视了技术开发的规范化，这显然是误导。如果这样做的企业通过了CMM 2级评估，然后声称他们能够把产品做得又快又好，无疑是自欺欺人。

三、对应用CMM/CMMI的建议

在软件过程能力比较低的企业里，经常会发生项目开发过程混乱、产品质量低下、进度延误、成本高昂等问题。一批人马累死累活地做完产品后，马上又因质量问题被折腾得焦头烂额。这种现象反反复复地发生，让人疲惫不堪。

有远见的企业领导应当下决心去改进软件过程能力。提高软件过程能力实际上就是“练内功”，“练内功”没有捷径可走，唯有走“规范化”之路。即：制定适合于本企业的软件过程规范，并按照此规范执行。

CMM是衡量企业软件过程能力的国际标准，它对软件过程改进有很多有益的指导。CMM仅仅对等级评估做了强制要求，但是对企业“如何进行软件过程改进”没有强制要求，CMM的数百页文本并不是“放之四海皆准”的，企业可以采纳也可以不采纳。

对于软件过程改进而言，CMM/CMMI和ISO等等都是用来参考的，而不是用来迷信的。企业在参考业界推荐的标准或规范时，要舍弃那些听起来很先进但是对本企业无益处的东西，只选取对企业有实用价值的东西。