CMMI 与 SW-CMM 对比研究.doc

CMMI 与 SW-CMM 对比研究 万永刚，洪玫，刘月钟 （四川大学 计算机学院，四川 成都 610065 ） 摘要： CMMI （ Capability Maturity Model Integration ）是美国卡内基梅隆大学软件工程研究所（ CMU SEI ）提出的新一代的能力成熟度模型。文中简单介绍了 CMMI ，并将其与其前辈 SW-CMM （ Capability Maturity Model for Software ）从多个方面和层次上进行了对比，探讨了其演变的动因，并对其发展趋势做出了预测。 关键词： CMMI ； SW-CMM Comparison between CMMI and SW-CMM Wan Yong-gang, Hong Mei, Liu Yue-zhong (College of Computer Science, Sichuan University, Chengdu Sichuan 610065, China) Abstract: CMMI (Capability Maturity Model Integration) is a new generation of capability model which is developed by the Software Engineering Institute (SEI) of Carnegie Mellon University in America. This paper makes a brief introduction to CMMI, as well as a comparison between CMMI and SW-CMM (Capability Maturity Model for Software), its ancestor, in several respects and different levels. The root cause of the difference and the prospect of CMMI are also discussed. Key Words: CMMI ； SW-CMM 引言 CMMI 是由美国卡内基梅隆大学软件工程研究所（ SEI ）于 1999 年发布的新一代能力成熟度模型。那么 CMMI 相对于人们熟悉的 SW-CMM 有些什么异同？其变化的原因是什么？ SW-CMM 到 CMMI 的过渡是势在必行的吗？针对这些问题，本文将 SW-CMM 与 CMMI 从多个方面和不同的层次进行了对比，剖析了其演变的原因，探讨了其发展前景，并对于企业从 SW-CMM 到 CMMI 的过渡提出了切实可行的建议。 模型的演变 第一个 CMM 版本于 1991 年发布，是面向软件的，称为 SW-CMM. 。从此以后， SEI 在原有的基础上又衍生出了一系列能力成熟度模型。其中比较重要的包括：系统工程能力成熟度模型（ System Engineering Capability Maturity Model, SE-CMM ） , 软件获取能力成熟度模型（ Software Acquisition Capability Maturity Model, SA-CMM ），人力资源成熟度模型（ People Capability Maturity Model, P-CMM ），集成产品开发能力成熟度模型（ Integrated Product Development Capability Maturity Model, IPD-CMM ）。 这些模型各自面向不同的领域，具有不同的用途。但因为是在同一个模型的基础上发展起来的，它们在过程域（ Process Area ）等方面有一定重叠，而表现形式却又有不同之处。系统工程能力成熟度模型是“连续式”（ Continuous ），而其它能力成熟度模型采用了“阶段式”（ Staged ）。尽管这些模型都非常有用，但当一个组织（ Organization ）使用了其中多个模型的时候，会随之带来一些问题。首先，组织往往希望将自身持续改进的努力集中在组织内部所有的领域上，而这些各自有特定领域的模型之间的区别（包括体系结构、内容和方法）将会使这种努力落空。其次，在一个组织内部实施多个模型，而不将它们集成到一起，将会导致培训、评估和改进等方面的开销增加。 另外，在实际应用中对于 CMM 诸模型本身也存在很多争议。其一， CMMs 的关键过程域（ Key Process Area ， KPA ）主要的关注点是活动（ Activities ），而不是开发结果（软件产品）或记录真正目标产品的相关工程结果，也不强调体系结构、设计过程、评估过程和使用过程等。其二，有人认为 CMMs 过度地强调了同级评审（ Peer Review ）、检查（ Inspection ）和传统的质量保证控制方法，这些方法虽然有用，但难以发现体系结构等方面的重大缺陷。其三，实施了 CMMs 的组织产生了更多的文件、检查点、结果、可追溯性、以及更多的检查和计划、更厚的文档，这与当今降低复杂性和减少“人造”材料等提高软件经济效益的途径格格不入。虽然这些是 CMMs 作为一种重载（ Heavy-load ）软件过程的必然产物，但 CMMs 的使用者们仍然期望着在这方面能有所改进。在这样的环境下，融入了软件工程领域新的经验和理论的 CMMI 应运而生。 CMMI 的体系框架 源模型 CMMI 的源模型有三个： （ 1 ） 软件能力成熟度模型 V2.0 版， C 草案； （ 2 ） 电子行业协会临时标准 731 （ Electronic Industries Alliance Interim Standard 731 ）； （ 3 ） 集成产品开发能力成熟度模型 V0.98 版； 此外， SEI 在开发 CMMI 时还注意到了与国际标准化组织和国际电工委员会的 15504 技术报告（ ISO/IEC 15504 ）相兼容和一致。 知识领域 CMMI 框架的内容涉及四个知识领域： 系统工程： 系统工程涵盖了一个系统所有的开发工作，其中可能包括、也可能不包括软件。它关注于将客户提出的需求、期望以及限制条件转化到产品的解决方案中，并且在产品的整个生命周期中对解决方案给予始终的支持。 软件工程： 软件工程的对象是软件系统的开发。它关注于将系统的、条理的、可量化的方法应用到软件的开发、运行和维护中。 集成的产品和过程开发（ IPPD ）： IPPD 是一种系统的方法，指在产品的生命周期中通过所有相关人员和部门的合作，更好地满足客户的需要、期望和要求。支持 IPPD 的过程都是与组织中其它的过程紧密结合的，仅仅只有 IPPD 的过程域、特定目标（ Specific Goals ）、特定实践（ Specific Practices ）是无法实现 IPPD 的。 供应商来源（ Supplier Sourcing ）： 随着工作越来越复杂，项目有时候需要特定的供应商来实现功能或对产品进行修改。当这一点对于项目很关键的时候，如果项目能够增强对供应商的分析，并在产品交付以前对供应商的行为进行监督，那么项目将受益匪浅。供应商来源（ SS ）关注的就是如何在这种情况下从供应商处获得合格产品。 在以上知识领域中，企业可以任意选择，也可以都选择。 IPPD 和 SS 主要是配合软件工程和系统工程的内容使用。例如，纯软件商可以选择软件工程的内容；设备制造商可以选择系统工程和软件工程的内容；系统集成商可以选择系统工程、软件工程和 IPPD 的内容。相对 SW-CMM 只涉及软件工程来说， CMMI 的覆盖面和适应面更广、更全面、更灵活。这种演变基于这样一种思想：在适当抽象的前提下，项目管理和过程管理的理论其实可以用于多个学科，软件工程的过程也可以用于多种其它工程形式。 表达方式 SW-CMM 的表达方式（ Presentation ）是阶段式的，而 CMMI 的表达方式包括了阶段式和连续式两种。 CMMI 的阶段式类似于 SW-CMM ，将所有的过程域按 5 个成熟度等级来组织，从低到高分别为：初始级（ Initial ）（第 1 级）、已管理级（ Managed ）、已定义级（ Defined ）、量化管理级（ Quantitatively Managed ）和优化级（ Optimizing ）（第 5 级）。整体来看，这样的组织方式除了名称略为有些变化之外，各个成熟度模型等级代表的能力成熟度与 SW-CMM 对应等级相比都是大同小异的。 CMMI 的连续式则使用能力等级来衡量单个的过程域，从低到高分别有：未完成级（ Incomplete ）（第 0 级），已实施级（ Performed ），已管理级（ Managed ），已定义级（ Defined ），量化管理级（ Quantitatively Managed ）和优化级（ Optimizing ）（第 5 级）等 6 个等级。 连续式与阶段式所包含的过程域是完全一致的。两者的区别主要在于过程域的组织方式不同，阶段式是用来描述组织整体上的成熟度，而连续式关注的是组织单个过程域的能力。如果组织注意力主要集中在某几个过程域上时，则采用连续式比较合适。 在 CMMI 框架内，由不同的知识领域和不同的表达方式可以构成多个 CMMI 模型。当组织需要选择一种 CMMI 模型时，必须要根据自己的过程改进的实际情况确定使用那一种表达方式，并且要确定需要用到哪一个或者哪一些知识领域。 模型构成成分构成成分 阶段式 阶段式的模型构成成分构成成分主要有：能力成熟度等级、过程域、一般目标（ Generic Goal ）、特定目标（ Specific Goal ）、一般实践（ Generic Practice ）、特定实践（ Specific Practice ）以及用于组织一般实践的公共特性（ Common Feature ）。 从图 1 中我们可以清楚地看到阶段式表达方式各构成成分之间的关系： 图 1 CMMI 阶段式模型构成成分 与 SW-CMM 的结构相比， CMMI 的模型结构显得更加复杂与精细。 CMMI 从过程域所有的实践提炼出了多个过程域所共有的实践，称为一般实践，将其目标称为一般目标，其余特定于某个过程域的实践与目标称为特定实践与特定目标。这样模型取得了相对 SW-CMM 更高的抽象度与适应范围。目标（一般目标与特定目标）首次作为模型构成成分出现，这表明 CMMI 对过程活动的结果投入了更多的关注。 在 CMMI 中删除了 SW-CMM 中的公共特性度量与分析（ Measurement and Analysis ），并用一个单独过程域组织相关的内容。这样既避免了 SW-CMM 中对每个关键过程域都有度量要求所带来的不一致和精力的浪费，又 降低了对度量的要求和实施的难度，且更具有全局性和可实施性。 SW-CMM 的模型构成成分图如下：图2 SW-CMM 模型构成成分 关键过程域 连续式 连续式的模型构成成分与阶段式的主要构成成分差别不大，只是成熟度等级换成了能力等级，没有公共特性，并且由于连续式是针对单个过程域，因此构成成分不是围绕等级来组织的，而是围绕过程域来组织的。图 3 显示了它们之间的关系：图3 CMMI 连续式模型构成成分 过程域 CMMI 总共有 25 个过程域，连续式与阶段式的过程域完全一致，与 SW-CMM 相比，数量上多了 7 个过程域。虽然大部分的过程域都有所变化，但主要的改动集中在等级 3 的过程域中。这一层新增加了 7 个过程域，与原来 SW-CMM 等级 3 中的过程域一起进行了重新划分，形成了一个更细致，更实际，更符合软件工程发展方向的成熟度等级。图 4 将 CMMI 和 SW-CMM 各等级的过程域进行了一个对比： CMMI 加强了对工程化过程的重视，将软件产品过程细分为 5 个单独的过程域。需求的重要性在 CMMI 中得到了进一步的强调。除了等级 2 中需求管理（ Requirements Management ）过程域外，在等级 3 中新增加了需求开发（ Requirements Development ）过程域。它是从 SW-CMM 软件产品工程（ Software Product Engineering ）过程域中的一个实践提升而成的。 CMMI 对比 SW-CMM 更加强调了对风险的管理，在 SW-CMM 中风险只是关键过程域软件项目计划（ Software project planning ）中的一个活动，而在 CMMI 中风险管理成为一个单独的过程域。 CMM 中的一个关键过程域组间协调（ Intergroup coordination ），在 CMMI 中地位下降，只是作为综合项目管理（ Integrated Project Management ）中的一个目标。 SW-CMM 中的关键过程域同级评审（ Peer Review ），在 CMMI 中得到了更高的抽象，对应 CMMI 的验证（ Verification ）。 实施 CMMI CMMI 取代 SW-CMM 和其它一些模型是大势所趋。那么对于一个企业来说，什么时候比较合适实施 CMMI 呢？如果企业还没有实施 SW-CMM 或者其它的一些模型，那么可以立即开始着手 CMMI ，这样避免了以后再从其它模型转换过来的麻烦。如果企业正在实施其它模型，并且即将达到预期的目标，那么等到目标实现以后再转换到 CMMI 比较合适，并且当前模型的许多东西可以在今后的