CMM升级到CMMI的研究

   张亚军  赵岳松

（武汉理工大学计算机学院）

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

CMM2

需求管理 软件项目计划 软件项目跟踪和监督 软件子合同管理 软件质量保证 软件配置管理

CMM3

组织过程焦点 组织过程定义 培训大纲 集成软件管理   软件产品工程   组间协调 同行评审

CMM4

定量过程管理 软件质量管理

CMM5

缺陷防范 技术变更管理 过程变更管理

CMMI2

需求管理 项目计划 项目监督和控制 供应商合同管理 产品过程质量保证 配置管理 测量分析

CMMI3

需求开发 技术解决方案 产品集成 验证 确认 组织过程焦点 组织过程定义 组织培训 集成项目管理 风险管理 合成团队 决策分析和决定 组织的一体化环境

CMMI4

组织过程性能 定量项目管理

CMMI5

原因分析和解决方案 组织创新和推广应用

 

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）

测量分析KPA重组见表1所示。

表1 测量分析KPA重组

测量分析KPA的目标	CMM共同特征∕目标
SG1	QPM Co 2 Ac1,3,4,5,6 SPT&O Ac 5,6,7,8,9,11
SG2	TCM Ab 4 QPM Ac 4,5,6 ODP Ac 5 SPP Ac 15 SPT&O Ac11
GG2	QPM Co 1 Ab 2,3,4 OPF Ac 1 Ab 2,3 SQM Ac 1,2 Ab 1,2,3

 

 

 

 

 

 

 

 

 

 

 

 

            

 表示符说明：QPM Co 2 Ac1,3,4,5,6表示定量过程管理（Quantitative Process Management）过程域执行的约定（Commitment to perform）2和执行活动（Activities to perform）1,3,4,5,6。

Co表示执行的约定；Ab表示执行的能力；Ac表示执行的活动；SG表示特殊目标（Special Goal）；GG表示一般目标（Generic Goal）；其他可类推。

（3）CMMI3级

①将CMM软件产品工程KPA分解为需求开发、技术解决方案、产品集成、认证、确认KPAs，并进行扩充。

②了解CMMI3级中新增的决定分析和解决方案、合成团队，组织一体化环境KPAs，并填补。

③迭代CMM2级的工作。

 

6 结束语

卡内基梅隆大学软件工程研究所推出CMM Version 2.0 draft C后就停止了在CMM的改进。CMM被CMMI所取代是大势所趋。许多正在运用CMM模型进行软件过程改进的组织纷纷向CMMI升级。而CMMI模型迄今还没有成熟，卡内基梅隆大学软件工程研究所推出了CMMI-SE/SW 1.1和CMMI-SE/SW/IPPD，在目前的产品集中没有关于软件采购方面的内容，估计以后还会推出这个科目。而且从CMM向CMMI升级也只是处于尝试阶段。组织升级的操作过程，运用CMMI模型所带来的效益等信息还很匮乏，这些信息也为未能及时反馈到卡内基梅隆大学软件工程研究所，这也给CMMI模型的改进及向CMMI的升级工作带来了一定的难度。

参考文献：

[1] 郑人杰，王纬，王方德，蔡愉祖等. 基于软件能力成熟度模型（CMM）的软件过程改进 —— 方法与实施.  清华大学出版社，  2003 . 3

[2]CMU/SEI-2002-TR-004 CMMISM for System Engineering / Software Engineering/ Integrated Product and Process Development, Version 1.1 (CMMISM-SE/SW/IPPD, V1.1), Staged Representation.

[3]USAF Software Technology Support Center (STSC). Mapping CMMI-SE/SW/IPPD V1.1 to SW-CMM V1.1 2002.1

 [4] Mark C Paulk, Charles V Weber, Suzanne M Garcia, et al. Key Practices of the Capability Maturity Model . version 1.1. CMU/SEI, 1993

[5] Mark C Paulk , Charles V Weber, et al. The Capability Maturity Model Guideline for Improving the Software Process. Reading, MA： Addison-Wesley Publishing Company. 1995