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修改为“将涉众的需要转化为客户需求”，并强调对客户需求的排序管理。SP3.2修改为“建立需要的功能性及性能参数定义”，补充了对性能的要求，除此之外，模型还补充对需求定义的解释，现在将类似产品如何实现的设计考虑和约束也作为需求定义的一部分。
产品集成（Product Integration）过程域的目标由原来的“确保功能运行正常”变为“表现正常”，既包含了功能也包含了性能属性的检查。另外SP1.1由原来的“决定集成顺序”变为“建立集成策略”，范围扩大到接收、组装和评价产品组件的方法。
验证（Verification）中对于同行评审的例子中除了原有的审查和结构化走查外，还增加了敏捷开发中“重构”以及“结对编程”。前者指在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性，而后者指两位程序员在同一台电脑工作台前合作完成编码工作，其中一位键入代码而另一位评审。
技术解决（Technical Solutions）和确认（Validation）过程域都没有较大的修改。
3.3过程管理过程域
组织过程定义（Organizational Process Definition）过程域SP1.3建立裁剪准则和指南中对可裁剪项的选择提供了指导，模型认为对于直接与关键商业目标相关的过程应该定义为强制过程，而与关键商业目标关系较弱或者间接影响目标的过程可以允许裁剪。另外，该过程域增加了一个新实践——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更适合过程改进人员参考使用。
