一、 CMMI-DEV1.3的主要变化
2010年12月，CMMI DEV1.3正式发布。在CMMIV1.3发布前，SEI作了大量的宣传，称1.3有很大的改进。的确如SEI遵循的原则，CMMI模型要体现业内的最佳实践(Best Practice)。CMMI DEV1.3在吸纳目前业内的一些好的实践的同时，还吸纳了ISO以及PMI的一些新的成果。其主要变化包括：
1、 吸收了敏捷软件开发的实践。在配置管理（CM）、技术解决方案（TS）、产品集成（PI）、验证（VER）、确认（VAL）、需求管理（REQM）、质量保证（PPQA）等过程域中，对敏捷软件开发相关一些实践作了说明；
2、 对高成熟度的4个过程域作了较大优化，以“反应业界的最佳实践”。感觉现在这几个过程域的实践不再像之前那样高不可攀，很多解释似乎不再像从前那样机械，而且把过程改进目标与组织商务目标相联系，增加了一些具体的例子，对实践有一定指导作用。同时，该版本中删掉了原来高成熟度等级中的共性目标。连续型模型中只包含了3个级别，不再有高成熟度等级。
3、 更加重视需求管理：该版本将需求管理（REQM）过程域从工程组（Engineering）移至项目管理组（Project Management）。
4、 更加关注结果。这表现在一些名词的提法，如：
Ø “管理过程(Manage Process)”变成“管理项目(Manage Project)”；
Ø 共性实践GP2.6的标题从“管理配置项”更改为“控制工作产品”，虽然内容基本没有变化；
Ø 共性实践GP2.9 “客观评价依从性”中将原来“客观评价过程的依从性”，更改为“客观评价过程和工作产品的依从性”；
5、 吸纳了ISO、PMBOK等的一些最新成果。例如：
Ø 原来的“需求”变成了“功能需求和质量属性（Quality Attributes）”;
Ø 增加了架构评审的一些实践
Ø 更加强调各过程与组织商务目标的关系
6、 其他：删除了所有IPPD（Integrated Product and Process Development）的相关内容。（事实上，IPPD是在1.2版中强塞进去的，与模型的其它部分融合度很差。）
下面按照成熟度等级对各PA的变化进行简要说明。
二、 二级过程域的主要变化
|
1 |
CM(Configuration Management) ——配置管理 |
|
|
² 变化点
ü 在配置项的例子中增加硬件、环境配置、工具等内容
ü 强调了基于核心产品的产品线开发中，多分支配置管理的复杂性
ü 强调了在敏捷开发环境中进行频繁变更、持续集成，导致配置管理工作的复杂性和重要性
|
|
|
² 敏捷开发
在Agile环境中，配置管理非常重要。由于要支持经常性变更、经常性构建(通常是每日)、多重基准、以及多重工作场所(例如，对个人、团队、甚至是结对程序)，如果配置管理做不到下列各项，则Agile团队可能陷入泥沼：1) 自动化CM (例如，build scripts、状态记述、完整性检查)；2)将CM当成标准服务执行：在启动的时候，Agile团队应明确配置管理负责人；在每一个迭代周期开始，需要重新确认配置管理的支持是否到位。而配置管理责任人的目标是将配置管理工作谨慎地整合到团队的工作节奏，最小化开发人员重点工作外的其它工作量。
|
|
2 |
PPQA (Process and Product Quality Assurance) —过程和产品质量保证 |
|
|
² 变化点
ü 在SP2.2中增加评估工作产品的时机的例子。
ü 增加敏捷开发模式下的质量保证活动建议
|
|
|
² 敏捷开发
在Agile环境中，团队倾向于将焦点聚集在本迭代的立即需要上，忽略较长期的且更广泛的组织利益需要。为了确保客观评估的效果，使之具有价值和效率，需尽早确定：(1)客观评估如何完成；(2)要评估哪些过程与工作产品；(3)评估的结果要如何整合到团队的节奏中(例如，融合到每日例行会议、检查表、同行评审、工具、持续集成等等活动中)。
|
|
3 |
PP (Project Planning) —— 项目规划 |
|
|
² 变化点：
ü 增加对计划的解释，既可以集中在一个文档中，又可以分散
ü 在SG1中删掉了影响估算因素的项目属性的具体说明
ü SP1.3标题“定义项目生命周期”改为“定义项目生命周期阶段”，计划内容中增加“里程碑”
ü 在项目进展状态评审中强调对客户满意度度量结果的评审
ü 估算方面作了较多修改
|
|
|
² 敏捷开发
|
| |
