1 前言
自从1994年SEI正式发布软件CMM以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。2000年，为了解决组织因为同时采用多种模型带来混乱等情况，SEI发布了CMMI模型。之后模型不断的改进发展，大量组织从2006年开始使用CMMI-DEV V1.2模型进行过程改进，而在使用该模型时，使用者也发现模型存在着高成熟度描述不明确、某些细节不符合组织需要等问题。SEI从2008年开始策划编写CMMI-DEV V1.3，经过三年的时间，在2010年11月发布了最新的模型。
模型的更新中除了明确了高成熟度要求外，还包含了二、三级过程域的修改，为CMMI模型的使用者提供了更清晰、更新的指导。本文的目的是介绍二、三级过程域的变化，为熟悉CMMI模型、基于CMMI-DEV V1.2模型制定组织开发过程的人员提供参考。
2 模型变化综述
CMMI-DEV V1.2版之前，各过程域能能力等级分为0至5共六级，通过评价是否满足通用目标4（GG4）及通用目标5（GG5）判断各过程域是否到达高成熟度。在本次V1.3版本更新中，SEI将GG4及GG5从模型中去除，通过判断各过程域是否达到能力等级三（Capability Level3）以确定组织成熟度等级是否达到成熟度四级或五级（Maturity Level 4 and 5）。
除此以外，模型对GP2.6和GP3.2进行了修改。GP2.6从原来的“管理配置项”变为“控制工作产品”，以免模型使用者误以为该实践要求使用配置管理工具管理所有选定的工作产品，关于模型对于“配置项”的描述变化，请见后文的配置管理过程域。
GP3.2从原来的“收集改进信息”变为“收集过程相关经验”，实践的说明不再是“收集工作产品、度量、度量结果和改进信息”，而将其作为“过程相关经验”的例子，也就是针对特定的过程域，管理人员可以选择性地收集相关信息。
另外，需求管理过程域（REQM）从原来的工程类过程域变为项目管理类的过程域，其内容没有较大的改变。
3 二、三级过程域变化
3.1 项目管理过程域
项目策划（Project Planning）过程域SP1.2建立工作产品及任务属性的估计中，V1.2给出的参考都只与产品特征有关，例如功能数、输入与输出数、类与对象数等，而在V1.3中增加了与“人”相关的因素，例如项目参与人的经验、团队稳定性与复杂度、与客户达成一致的难度等。而根据项目管理的经验，以上的人为因素确实可能严重导致项目工作量，因此在估算时增加该方面的资料有助于提升估算的可靠性。
项目策划 SP1.3从原来的“定义项目生命周期”修改为“定义项目生命周期阶段”。V1.2中该实践的描述是定义“生命周期”，而根据该实践的详细描述，实际上是“生命周期阶段”，所以V1.3并不是修改了要求，而是明确了这一要求。另外，该实践中又新增了对生命周期阶段的解释，说明定义阶段的目的是在项目的关键点评估项目计划和策略的持续可靠性以及对重要资源进行承诺。
项目监督与控制（Project Monitoring and Control）过程域的SP1.6开展进展评审及1.7开展里程碑评审中说明了两者关注点的不同。“项目进展评审”是项目运行到一个特定的时间点时涉众（Stakeholder）通过对结果和影响的评审决定是否出现重要问题或不足。而“里程碑评审”是指在预先策划的时间点进行评审了解涉众需求的满足情况。V1.3模型中更说明了进展评审和里程碑评审不一定要分开开展。
综合项目管理（Integrated Project Management）SP1.2使用组织过程财富策划项目活动中增加了描述，强调了“有可用的资料时”，这些资料可用于帮助判断估算工作量的相应范围和风险。
综合项目管理还增加了一个特定实践——“SP1.6建立团队”。该实践的描述的是关于建立团队愿景以及结构，以确保相关涉众的协调与合作。
供方协定管理（Supplier Agreement Management）过程域在本次修改中说明对于现货（commercial off-the-shelf）采购是不适用的，但如果存在对于现货或免费软件的修改，并且该修改对于项目有重大的价值或风险，则需要使用该过程。同时V1.3中也说明该过程域同样不适用于项目的客户同时也是供应商的情况（例如项目组使用客户提供的组件进行产品制作）。供方协定管理过程域删除了原SP2.2监督选定的供应商过程和SP2.3评价选定的供应商工作产品两个特定实践，通过原SP2.4接受获得的产品特定实践完成采购的检查、测试等工作，避免了以往在某些商业环境下难以实施的情况。
风险管理（Risk Management）和需求管理（Requirement Management）过程域都没有较大的修改。
3.2 工程过程域
需求开发（Requirement Development）过程域SP1.2修改为“将涉众的需要转化为客户需求”，并强调对客户需求的排序管理。SP2.2修改为“建立需要的功能性及性能参数定义”，补充了对性能的要求，除此之外，模型还补充对需求定义的解释，现在将类似产品如何实现的设计考虑和约束也作为需求定义的一部分。
产品集成（Product Integration）过程域的目标由原来的“确保功能运行正常”变为“表现正常”，既包含了功能也包含了性能属性的检查。另外SP1.1由原来的“决定集成顺序”变为“建立集成策略”，范围扩大到接收、组装和评价产品组件的方法。
验证（Verification）中对于同行评审的例子中除了原有的审查和结构化走查外，还增加了敏捷开发中“重构”以及“结对编程”。前者指在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性，而后者指两位程序员在同一台电脑工作台前合作完成编码工作，其中一位键入代码而另一位评审。
技术解决（Technical Solutions）和确认（Validation）过程域都没有较大的修改。
3.3 过程管理过程域
组织过程定义（Organizational Process Definition）过程域SP1.2建立裁剪准则和指南中对可裁剪项的选择提供了指导，模型认为对于直接与关键商业目标相关的过程应该定义为强制过程，而与关键商业目标关系较弱或者间接影响目标的过程可以允许裁剪。另外，该过程域增加了一个新实践——SP1.7建立团队规则及指南，与综合项目管理过程域新增的建立团队紧密相连。该实践的目的是通过制定团队结构、组成和运作方式的规则促进团队的沟通与协作。
组织过程关注（Organizational Process Focus）和组织培训（Organizational Training）过程域都没有较大的修改。
3.4 支持过程域
配置管理（Configuration Management）过程域SP1.1识别配置项的描述中对配置项进行了重新定义，V1.2中的配置项包括了类似规格说明书、接口文档和测试结果等文档和软件，而V1.3中扩大了配置项的范围，还包括硬件、设备和实体存在的资产。在SP1.3建立和发布基线的实践中也提到了硬件产品也应该是基线的一部分。因此，在进行项目的配置管理时需要考虑软件、文档、硬件和设备之间的状态及关系，以便在开发过程中维护关键工作产品的一致性。
测量与分析（Measurement and Analysis）过程域在简介中补充说明了“测量目标”和“项目、组织和商业目标”的区别和关联。前者描述的是收集和分析某些数据的目的，而后者则描述的是项目、组织期望实现的具体目标和利益，前者来源于后者。例如商业目标是“缩短交付周期”，则可能引入“提供项目进度偏差数据”的测量目标。从测量与分析过程域的修改可以看出模型对测量与商业目标一致性的关注。
过程与产品质量保证（Process and Product Quality Assurance）和决策分析与解决（Decision Analysis and Resolution）过程域都没有较大的修改。
4 结论
CMMI-DEV，V1.3的修改明确了模型中的要求以降低使用者对其产生误解的可能，并为部分实践提供了更详细有益的例子，同时通过修改部分过程域中的实践，为组织提供了更多的指导，删除了部分在特定环境下难以实现的实践。作为时隔4年的升级，CMMI-DEV，V1.3更适合过程改进人员参考使用。
5 参考文献
[1]SEI，"CMMI-DEV，V1.3”
[2] Mike Phillips，“CMMI Representations: Past and Future”
[3] Kerievsky，Joshua，“Refactoring to Patterns”
[4] Williams，Laurie，Kessler，Robert，“Pair Programming Illuminated”
