CMM 标准介绍

CMM 是软件过程能力成熟度模型（ Capacity Maturity Model ）的简称，是卡内基－梅隆大学软件工程研究院为了满足美国联邦政府评估软件供应 商能力的要求，于 1986 年开始研究的模型，并于 1991 年正式推出了 CMM 1.0 版。 CMM 自问世以来备受关注，在一些发达国家和地区得到了广泛应用，成为衡量软件公司软件开发管理水平的重要参考因素和软件过程改进事实上的工业标准。据了解，美国、印度、日本等国家已有数十家公司通过了 CMM 不同等级的认证。

1986 年 11 月， SEI 应美国联邦政府的要求，在 Mitre 公司的协助下，于 1987 年 9 月开发了一套软件能力成熟度框架和一套软件成熟度问卷，用来评估软件供应商的能力。这就是最早用于探索软件过程成熟度的一个工具。

四年以后，也就是 1991 年， SEI 自己总结了 CMM 成熟度框架和初版成熟度问卷的实践经验，并以此为基础推出民用 CMM1.0 版。

CMM1.0 版合用两年之后， 1992 年 4 月， SEI 举行了 CMM 一个的研讨会，参加研讨会的有大约 200 名富有经验的软件专家。 SEI 在广泛听取他们的意见之后，又于 1993 年推出 CMM1.1 版。这也是目前世界上比较流行和通用的 CMM 版本。

　　十几年来，此项工作一直在不断进行。按照 SEI 原来的计划， CMM 的改进版本 2.0 应该在 1997 年 11 月完成，然后在取得版本 2.0 得实践反馈意见之后，在 1999 年完成准 CMM2.0 版本。但是，美国国防部办公室要求 SEI 推迟发布 CMM2.0 版本，而要先完成一个更为紧迫得项目 CMMI 。

CMMI （ Capability Maturity Model Integration ）即能力成熟度模型集成，这也是美国国防部的一个设想，他们想把现在所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件获取方法的改革；第二，建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。

　　随着人们对 CMM 研究的不断深入，其他学科也结合本系统的特点，陆续推出了自己的 CMM 模型。例如，人力资源能力成熟度模型、系统工程能力成熟度模型等等。为了以示区别，国内外很多资料把 CMM 叫做 SW-CMM 。

　　软件过程成熟度的提高是一个渐进的过程，需要一个长远的、可持续发展的过程作为保证。为建立一个面向过程持续提高的基础和文化，有些软件企业可能要花费很大的精力和时间。但是这种努力对任何一个软件企业来说都是非常必要的。

CMM 目前代表着软件发展的一种思路，一种提高软件过程能力的途径。尽管它存在着某些不足。例如，成熟级别、关键过程域、公共属性和关键实践还需要在软件行业进一步深入地讨论和修订，但它确实为软件行业的发展提供了一个良好的框架，而且是浓度软件过程能力提高的有用工具。

　　增强我国软件企业的竞争力，提高国产软件的水平是国人的共同愿望，但目前我国软件水平，尤其是软件开发能力和软件生产能力还很差，这也是不争的事实。那么，如何提高我国软件的开发和生产能力，从而提高软件整体水平？软件企业实施 CMM 也许不失为一条有效的途径。

　　一个企业的软件能力更取决于该企业的过程能力，特别是在软件开发和生产中的成熟度。其过程能力越是成熟，该企业的软件生产能力 就越有保证。目前，我国已有一些软件企业正在尝试实施 CMM 。

　　当然， CMM 不是万能的，并不一定对所有的软件企业都适合，实施 CMM 的企业也有失败的例子。我们希望通过本专栏能使更多的企业了解 CMM ，尽快找到适合本企业的发展之路，从而提高中国软件企业的竞争力。

CMM 应用

基于 CMM 成熟度模型，包括中小企业在内的软件企业如何进行软件过程改造，如何在具体项目中引入并实施 CMM 的标准成为人们关注的重点。 CMM 的实施核心焦点不在于软件的开发技术层面，而在于工程过程层面和工程管理层面。所谓工程过程层面是指将工程开发的整个过程所涉及的相关议题作为过程学的体系来研究和执行。过程学本身既不同于通常所说的软件工程技术，（如编码，操作系统等等），也不同于一般所言的工程管理学，软件过程既是对软件工程这一领域中所涉及的流程按其独特特性进行专门描述。事实上，任何企业在开发工程产品的实践中，都有开发过程产生，虽然很多企业并未对其进行记录或关注。按照工程过程学派的观点，没有正确的过程就不可能有正确的产品产生，因此对开发组织的过程需要规范和改进。 　　由于软件过程必然与工程管理相关，因而它不象具体的开发技术问题那样容易规划并着手实施，特别是国内广大的中小软件企业和部门，在采纳某一过程体系进行开发流程的改造时，应特别注意如下几方面的问题，将其作为过程实施开端的要领加以掌握：

1 ．不可急于求成和盲目乐观。任何新体系的采纳和改进都必然涉及对旧有体系的重组和调整，需要投入相当的决心和时间。如果企业在充分评估后决定了以 CMM 工程标准来规范建构自身的软件开发行为，则应该在次序改进的前提下尽早实施企业开发过程调整以便有充裕时间理解和评估前期改造的成效。
2 ．必须懂得 CMM 作为一套标准，它指明的是该作什么（ What ）而非怎样去做（ How ），同时 CMM 也代表了一种对软件生产过程进行理解和分析的独到观点（ Philosophy ）。 CMM 着重于过程中的关键要素，而非面面俱到，它主要不是为了解决某个具体项目的问题，也不能保证在此框架下产品开发 100% 成功， CMM 所述的软件过程集合了工程过程和管理过程等方面，对它的过程改进要靠许多细小的阶段性的步骤而非一蹴而就的革新。
3 ． CMM1.1 版主要针对大型软件企业，这些企业的开发工作通常关涉软件生产过程的方方面面。对于 20 人以下的小型企业， 1.1 版中的一些环节可能并不适用。
4 ．企业在采纳 CMM 过程改进的同时，可以引入新技术与自动化工具帮助软件开发的实现，不过，对过程的改进要求企业全面投入并需较长周期，而技术引进则相对周期较短。但如果企业只是依靠技术改进而不注重过程改进，长远看来，企业可能收获甚少。
5 ． " 知己知彼，百战不殆 " 。实施改进之前，企业应对自身当前所有的软件能力水平及过程状态有尽可能的客观、详尽的了解。可以参考本文后附企业开发能力自测表进行初步诊断，在明了自身实际过程等级之后，企业应确定需要达到的等级目标并找到主要差距所在。企业要想达到的等级目标包括它所特定的过程目标及核心过程域（ KPA ）。这一等级应符合企业自身开发水平与项目特征。在企业明了了自身实际等级与目标等级之间的差距之后，应制定规划，决定改进次序及程度，可参考的决策因素包括：目标与能力的平衡，投入工期与质量的保证，企业总体发展与当前项目开发的平衡，员工素质条件，最薄弱环节与最急需改进环节，还有最易见效的环节，等等。
6 ．如有可能，在企业内部成立专门的过程改进规划组，并配合企业外聘的咨询机构或顾问，拟订出详细的过程实施方案，同时注意在实施过程中对计划进行修正和调节。在此，应将改进方案指定得尽量具体详细，这包括：
<1> 目标明确并可检验 , 有助于切实的检验标准；
<2> 有详细的实施步骤 , 有专人负责每一环节的落实 , 有协调方解决各环节之间的冲突；
<3> 如需采纳新技术和工具，应详细分析他们的作用及获取方式并准备对新技术和工具进 行改造，对员工进行培训以适应项目所需。
<4> 制定项目开发时间表，将每个过程环节的实施与此时间表挂钩。
<5> 对项目开发的投入工期进行预测并据此规划开发工作。
<6> 预先规划开发过程中相关数据的采集，分析和提供方式与时段；
<7> 所有过程，包括：需求分析、项目计划、项目验收和交付，都必须编档并保留，应有具体的监控和考核计划来监督过程的实施。这一计划应考虑到偏差的可能性及应对方案。
<8> 企业的高层和相关管理人员应参与过程的制定与实施并形成制度。领导层应负责对每一阶段改进的总结并制定出相应的后继方案，另外，凡涉及对已定计划和过程的调整必须事先申请备案并经领导层同意。
<9> 需强调的最重要的一条原则是，过程改进不可流于书面形式，所有员工都应理解并参与其中。

CMM 模式即可用于描述软件机构实际具备的能力成熟度水平，也可用于指明软件企业改进软件工程所需着力之处，它说明了努力的方向，又允许企业自己选择恰当的方式去达到这一目的。实施 CMM 的经验告诉软件工程人员，在软件项目开发中，更多的问题和错误来源于工程安排的次序，工程规划和工程管理而不是技术上的 how to do 。软件工程的过程学不断分析和改善已有工程经验，拟定出尽可能完善的开发过程，并按开发生命周期确定重点环节加以管理，最终达到以量化数据来建立能力成熟度等级的目标。良好的工程过程保证了有序的开发实施，避免了以往开发人员被动救火的方式，并将个人主观因素减低至最少。开发人员的个人创造性从独立任意的发挥消解并转移到如何创建性地运用和完善工程过程上来。

　　作为一种模型， CMM 实际上是对软件机构工程过程的理论和数据模拟，在对它的应用中，主要包括软件产品供应方和应用方两大类。

　　目前，世界范围内已采纳 CMM 标准的企业纷纷以此标准决定软件项目合同的承接与分包。实践中，许多中小企业在接纳 CMM 体系时，采纳了保留企业部分原有工程过程指标并加以修改的办法。

　　卡莱基·梅隆大学软件研究所提出了一套实施 CMM 标准的方法，按照他们的建议， IDEAL 是企业开始引入 CMM 体系的良好参照模式，它包括：
I-- 启动（ Initiating ） , 表示开发机构应为 CMM 的引入准备好前期基础设施和程序。
D-- 诊断（ Diagnosing ） , 明确机构目前所处的能力水平及目标等级所在。
E-- 建构（ Establishing ） , 制定如何实现目标等级的计划。
A-- 行动（ Acting ） , 具体实施该计划。
L-- 学习（ Learning ） , 积累以往经验并将其用于持续的改进过程之中，同时注意新技术和工具的引入以协助过程实施。

　　如有可能，企业在咨询机构或咨询师的协助下可以加快 CMM 体系引入的过程，但企业必须同时着力于培训自身理解工程过程的人才。较好的方法包括在开发组织内部分项目形成 CMM 研讨小组以促进开发组及开发人员之间的经验交流。显而易见，实施 CMM 的成效应根据机构自身特有的实际情况作判断，正确的实施应该从质和量两方面对过程的各环节发生作用。 CMM 体系在中小企业的应用中并未要求逐字照章对应每一项核心过程域和核心实践来进行，机构可以用裁减的办法对其应用程度作修正，也可选用阐述的办法将某项具体的实施工作等同为特定的核心实施。

　　根据 SEI 的研究数据，绝大多数软件项目的成功都遵循了下述的工程原则：
a, 将软件生命周期划分为若干阶段并进行严格的计划，包括项目计划，里程碑计划，质量检测计划，维护计划等。
b, 在开发过程中，分阶段进行复审和评估，以便尽早发现错误所在。
c, 项目组成员应注重包括技术和流程在内的培训，提高人员素质。
d, 软件过程的改进应是持续性的，不断调整的进程。
e, 尽可能采用度量数据来描述过程中的每一环节，从而提高可预测性和可控制性。
f, 对以往所有开发工作必须进行文档工作，积累经验以用于未来的开发之中。
g, 如果项目允许，尽可能采纳较为先进的技术与工具，例如，面向对象的编程方式 (OOP)