【摘要】本文分析了 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 。

4 CMM 到 CMMI 的升级
4.1 升级前的准备工作
(1) 回顾 CMMI 模型和其他的 CMMI 信息，确定如何使 CMMI 最好的满足组织需要（ 2 ）拟订升级策略。（ 3 ） 在升级过程中确保以前用于 CMM 改进的投资得到维持和运用（ 4 ）将升级事项通告客户（ 5 ）将对现有过程域和新增过程域的改进费用编入预算，并提供有关改进需要的培训。（ 6 ）确定组织升级计划的风险表并管理这些风险，关键要识别 CMM 和 CMMI 之间的差异以及这些差异如何得到支持。

4.2 升级的方法：
一旦做好了升级前的准备工作，弄清了升级可带来的利益和成本，可执行下列活动进行升级，这些活动是迭代的。

（ 1 ） 选择适合组织最好的 CMMI 模型。 CMMI 覆盖各种知识体，包括项目管理，软件工程，系统工程，集成产品，过程开发供应商来源。按组织的商业目标选择模型。

（ 2 ）选择最适合组织的表示法。 CMMI 有阶段式表示法和连续式表示法，由于 CMM 采用的是阶段式的表示法，许多组织都采取 CMMI 阶段式表示法，若组织对连续式表示法较熟悉，也可以采取连续式表示法。

（ 3 ）将选择的 CMMI 模型与 CMM 对比，确定需要变更的范畴。具体的对比见上文。 变更的主要活动是对 CMMI 中重组的 KPA 及 CMMI 中新增的 KPA 进行更新。

（ 4 ） 确定升级会带来的影响。

（ 5 ）向 CMMI 升级因该报高级管理层的认可。

（ 6 ）变更组织目前的过程改进计划以支持 CMMI 升级。过程改进计划要反映出工作的优先级、组织所需增加的新部门。将该计划送交评审，得到关键储金保管者（ key stakeholders ）的许诺和认可，计划要说明升级可能带来的管理风险和进度风险，所需的培训，工具，和服务支持。传达这个计划并保持更新。

（ 7 ）确保对工程过程组，技术工作组及其他相关的员工进行 CMMI 的培训。

（ 8 ）获取 SCAMPI 评估支持。

（ 9 ） 修改每个项目已定义的过程使其与项目改进计划一致。

（ 10 ）给每个项目制定升级进度表 不同的项目升级进度表可能不同，如果有的升级工作已经完成则该工作可以抛弃。

（ 11 ）执行 SCAMPI 评估，看是否所有的目标过程域和目标得到支持。

5 处于 CMM 不同成熟等级的组织所做的具体工作：
（ 1 ） CMM1 级：
如果组织正使用 CMM 模型致力于过程改进而并处于 CMM1 级，那么组织应该继续用 CMM 模型。在改进的同时，组织将 CMM2 与 CMMI2 进行对比和差异确认，分析这些差异中哪些是对组织有价值的。当组织刚达到 CMM2 级时其主要工作时立即从 CMM2 向 CMMI2 升级。

（ 2 ） CMM2 级，
组织应该把其当前的过程改进向 CMMI2 级映射，填补两者之间的差距，从 CMM2 升级到 CMMI2 完成后，在下一步的工作中采用 CMMI 模型进行过程改进。主要有一下几方面
(1) 将 CMM 中分散的测量分析活动集中到 CMMI2 级测量分析 KPA 中，形成一个独立的过程域，提高开发的透明度。

(2) 重定位测量分析 KPA （ Measurement and Analysis ）的共同特征（ common feature ）