解读CMMI-DEV1.2到1.3的变化（三）
三级过程域的主要变化
1 OPD(Organizational Process Definition ) —— 组织过程定义
ü 组织过程定义的目标从原来“建立和维护组织过程资产和工作环境标准”扩充到“建立和维护组织过程资产、工作环境标准以及团队规则和指导方针”；
ü 增加SP1.7“建立团队建设的规则和指导方针”，目标是通过建立和维护组织级的规则和指导方针用以进行项目团队的组织、建设和管理。其实践包括项目的组织架构、项目经理和成员的权利和责任、团队行为准则、内部的计划任务分配检查机制、沟通方式，对外部和客户的汇报方式等等。旨在建立组织级的准则用以指导各项目团队管理。
ü SP1.3中增加一节强调对标准过程裁减的重要性。强调对于存在特殊需求的项目，对标准过程进行裁减以满足项目特殊的商务目标是非常关键的。
ü SP1.4增加对度量库的功能描述 —— 有利于项目之间进行有效的比较；在建立新项目时，可以通过度量库快速获得类似项目的基线或历史数据作为参照；可以通过类似项目历史数据提高估算精度；有助于统计管理。
2 OPF(Organizational Process Focus ) —— 组织过程焦点
ü SP1.3，组织在对需要改进的过程排优先级时，需要从成本收益进行考虑。
3 OT(Organizational Training ) —— 组织培训
ü 在培训需求中增加了领导力培训、团队建设培训以及沟通技巧培训的例子。
4 IPM (Integrated Project Management) —— 集成项目管理
ü SP1.6前插入新的特定实践“组建项目团队”：包含了原来IPPD中的大部分内容
ü SP1.5增加子实践“对影响项目目标达成的问题进行根源分析”，目的是在项目或组织范围内采取适当的纠正或预防措施。
5 RSKM (Risk Management) —— 风险管理
ü 基本无变化
6 DAR (Decision Analysis and Resolution) —— 决策分析和解决方案
ü 基本无变化
7 RD (Requirements Development) —— 需求开发
ü 增加了质量属性需求及说明 —— 质量需求，即质量属性的开发，贯穿于整个需求开发过程域中；例如，分解需求中也提到架构设计与质量属性的关系，强调产品质量特性的满足是通过架构设计实现的。
ü 增加在Agile环境下需求存在的形式及文档详细程度的说明；
² 敏捷开发
在Agile环境中，会在每一个迭代周期内反复引导、细化、分析和确认客户需求。需求通过用例、场景甚至迭代结果(在软件情况下为程序代码)的形式记录。哪些需求项会在给定的迭代周期中予以处理，是以风险评估和后续功能列表中的优先级驱动的。需求(及其他工作产品)文档的详细程度，是由团队成员间、团队间、以及前后迭代周期之间协作的需要以及项目或组织遗失相关成果的风险之间平衡的结果决定的。即使客户加入团队，仍然会有独立的客户和产品文件，用于多种解决方案的并行探索。当最终的解决方案确定后相应的需求会分配给适当的团队。
8 TS (Technical Solution) —— 技术解决方案
ü 在需求前增加形容词“功能和质量属性” —— 更加强调对产品的质量要求；
ü 产品的性能用质量属性代替——质量属性具有更宽泛的概念；
ü 在解决方案的选择准则中增加对关键质量属性的考虑，如产品时间特性、安全性、可靠性和可维护性等；
ü 删除了对“Data Package”的具体内容描述。
² 敏捷开发
在Agile环境中，TS的焦点在于对解决方案进行探索。让解决方案的选择准则及选择过程透明，有助于提高决策的质量。解决方案可从功能、特征集、发布版本、或任何其它能产品开发组件的角度来定义。当团队外的某个人在未来为这个产品工作时，产品的发布信息、维护日志、以及其他数据，通常会包含于该已安装的产品中。为支持产品更新，关于接口设计、组件采购和开发的决策准则的记录将有助于后续支持人员对该产品的理解。不过，如果所选解决方案存在的风险越小，则正式进行决策的需要也就越低。
9 PI (Product Integration) —— 产品集成
ü SP1.1“确定集成顺序（Determine Integration Sequence）”更改为“建立集成策略（Establish an Integration Strategy ）”。集成策略的涵盖的内容更多，除集成顺序外，还包含了对环境、工具、方法以及验证的策略。
² 敏捷开发
在Agile环境中，产品集成是一个经常性、通常是每日进行的活动。例如，对于软件开发，程序代码持续地以称为“持续集成”的过程，加入到程序代码库中。除了进行持续集成之外，产品集成策略还应说明，第三方所提供的组件如何集成到产品中，功能性将如何构建（横向分层还是纵切片)，以及在何时重构(refactor)。集成策略应在项目早期制定，并逐渐修订以以反映组件接口、外部依赖、数据交换、以及应用程序编程接口的演化。
10 VER (Verification) —— 验证
ü 验证方法中增加架构评审；
ü 同行评审方法中增加重构、结对编成
ü 验证方法的举例中增加了“架构评审、架构实现与架构设计的一致性检查”
ü 验证方法的举例中增加了“持续集成（用于早期识别集成问题的敏捷方法）”
ü 同行评审数据分析举例时增加“与缺陷相关的用例、与缺陷相关的客户或最终用户”
² 敏捷开发
在Agile环境中，由于客户的参与和频繁发布版本，验证和确认两个过程需要交替进行，互相支持。例如一个缺陷可能导致一个原型或一个早期发布的版本失效。反之，尽早的持续的确认有助于帮助验证过程应用于正确的产品。验证和确认过程能确保用系统化的方法选择工作产品进行评审和测试，有助于尽早识别缺陷。产品越复杂，越需要用系统化的方法验证需求、解决方案及其最终使用之间的一致性和兼容性
11 VAL (Validation) —— 确认
ü 在sp2.2“分析确认结果”中增加子实践：提供信息说明确认过程中的（遗留）缺陷如何解决，并发起纠正措施。