【摘要】本文分析了 CMM 到 CMMI 的各级映射，指出了 CMM 与 CMMI 的差异之所在，讨论了 CMM 升级到 CMMI 所需做的各项工作及过渡方法。对实施 CMM 的各级软件组织顺利升级到 CMMI 有一定的借鉴作用。
【关键词】KAP 、 CMM 、 CMMI 、 SCAMPI 、 KP
1 引言
自 1990 年起美国卡耐基梅隆大学软件工程研究所发布 SW-CMM v1.0 （软件能力成熟度模型）以来， SEI 针对不同领域的要求对 SW-CMM 先后进行改进，并衍生出了一系列成熟度模型。其中比较重要的包括：系统工程能力成熟度模型（ SE-CMM ） , 软件采购能力成熟度模型（ SA-CMM ），集成产品开发能力成熟度模型（ IPD-CMM ）等。 但是这些具有针对性的模型又带来了一些新的问题。软件公司的业务一般都不是单一的，有的公司可能同时从事软件开发、硬件开发、还可以进行软件采购。此时采取多个模型必定会使很多关键过程域，关键实践产生重叠，增加了开发费用。
2001 年 11 月 SIE 推出 CMMI V1.1 ，将以上模型集成，解决了多模型之间的重叠问题。同时 SEI 发表了针对 CMMI 的一套评估体系 SCAMPI SM V1.1 ，替代 CBA IPI and SCE SM 并打算 CMMI 取代 CMM 。已有许多组织开始向 CMMI 过渡。
CMMI 的基础源模型包括：软件 CMM 2.0 版（草稿 C ） , EIA-731 系统工程，以及 IPD CMM (IPD) 0.98a 版，它涵盖了系统工程，软件工程，集成的产品和过程开发（ IPPD ）和供应商来源四个知识领域。它有阶段式（ staged ）和连续式（ continuous ）两种表示法。本文为了方便和 CMM 进行对比，将 CMM 和 CMMI 均采用阶段式表示。
关于 CMM 和 CMMI 本文不做详细介绍，相关资料较多，对 CMM 和 CMMI 不太了解的读者可见参考书 [1] 、 [2] 。
2 从 CMM 到 CMMI 的映射
CMM 到 CMMI 的映射是一个复杂的体系，它涉及到 KPA 重构， KP 的再组织。图 1 只是从总体上描述了 CMM 到 CMMI 的映射关系。
图 1 CMM 到 CMMI 的各级映射
关于 CMM 和 CMM 的映射关系的细节描述见参考文献 3。
3 映射分析
CMMI 虽然是建立在 CMM 基础之上，两者大部分相似，但还是有很大差异。从总体上讲， CMMI 更加清晰的说明各过程域和类属实践（ generic practice ）如何应用实施，并指出如何将工作产品纳入相应等级的配置和数据管理基线，风险管理策略，验证策略等。 CMMI 包含更多工程活动，如需求开发，产品集成，验证等过程域；过程内容的定义更加清晰，较少强调文档化规程。
如图 1 ，在 CMMI2 级中增加了测量和分析 KPA （ Measurement and analysis ），将各测量分析实践（ KP ）归结为一个正式的关键过程域，而在 CMM 中测量分析实践是散落在各等级中的。因此在 CMMI 中更加强调了量化管理，管理的透明度和软件开发的透明度得到了升级。
CMMI3 级中增加了需求开发（ Requirements Development ）、技术解决方案（ Technical Solution ）、产品集成（ Product Integration ）、验证（ Verification ）、确认（ Validation ）、风险管理（ Risk Management ）、决策分析和决定（ Decision Analysis and Resolution ） KPAs 。 CMM 中的软件产品工程 KPA 被需求开发，技术解决方案，产品集成，验证，确认 KPAs 所取代；同行评审 KPA 被融入到验证 KPA 中； CMM 中集成软件管理 KPA 所阐述的风险管理在 CMMI3 中形成了一个独立风险管理 KPA 。同时集成软件管理和组间协调 KPAs 合并成集成项目管理 KPA 。合成团队、决定分析和解决方案、组织的一体化环境 KPAs 是全新的，其过程内容在 CMM 中没有提及。
CMMI4 中没有新的过程域，只是对原来的定量过程管理，软件质量管理 KPAs 重新构建为定量项目管理和组织过程性能 KPAs 。
CMMI5 中的技术变更管理和过程变更管理 KPAs 合并为组织革新与技术推广 KPA ，缺陷防范 KPA 重新构建为原因分析和解决方案 KPA 。