一、CMMI 2.0 模型内容

CMMI2.0模型引入“能力域”和“实域”的概念，将CMMI13的开发(DEV)、服务(SVC)、采购(ACQ)和人力管理(PPL)等种模型中的所有实践整合在一个模型中。CMMI2.0中共有12个能力域，这12个能力域被分为4类:Doing(执行)、Managing(管理)、Enabling(使能)和Improving(提高)。每个能力域中包含一组相关的实践域。项目可以构建自己的自定义视图。

二、过程改进的根本在于在组织文化中灌输纪律。

这包括工作被理解、完成和改进的方式。下图显示了组织在实施过程改进时通常会经历的过程纪律的四个阶段。

三、下面重点说一下“确保质量”能力域，包括四个实践域：需求开发和管理RDM、过程质量保证PQA、验证和确认VV、同行评审PR。

1、需求开发和管理 RDM

2.0的RDM不是简单的RD与ReqM的结合，从它对实践域的解释来看，它和前版这两个过程域有以下大的变化：

变化1：需求的范围不同。前版中需求只分为客户需求和产品需求；2.0版中需求分为客户需求、解决方案需求和接口或连接描述三种需求。其中解决方案需求代替了原来的产品需求，这同PI实践域一样，表明2.0版本不仅适应于软件产品，也同样适用于系统或服务；将接口需求与解决方案需求并列，也是一如PI实践域那样，表明2.0非常重视接口。

变化2：需求开发活动要在整个开发周期内一直进行，而不只是在设计之前。2.0中明确：在整个项目过程中持续识别和细化需求。

关键点

需求优先级、需求用例模型、业务对象模型、功能需求、非功能性需求

需求全周期跟踪评估管理、需求评审管理、需求变更管理

与需求提供者就需求的含义达成共识（涉及需求有效性分析）

与项目参与者达成共识，即他们可以落实这些需求，减少延误和返工

维护需求和活动、工作产品之间的双向可追溯性，确保需求与解决方案之间的一致性，从而提高客户满意度

分层次评审、分阶段评审、正式评审与非正式评审结合、需求评审检查单、评审前的准备（核对评审的进入条件，比如提前纠正资料中的明显问题、提前发资料给评审人员、要求评审人员提前阅读并记录问题)。

需求必要且充分，相关期望要平衡，管理承诺可追溯，场景分析确认清。

2、过程质量保证PQA

第 2 级

PQA 2.1 根据历史质量数据开发、持续更新并遵循质量保证方法和计划。

质量保证计划可以简单也可以完备，最简单的QA计划可以就是一页纸，一张表。

PQA 2.2 在整个项目过程中，根据记录的过程和适用标准客观评价选定的已执行过程和工作产品。

检查单：包括检查项、检查结果。

PQA 2.3 沟通质量和不合规问题并确保解决问题。

问题跟踪表或禅道等工具。

PQA 2.4 记录并使用质量保证活动的结果。

QA质量保证报告。

第 3 级

PQA 3.1 在质量保证活动中识别并记录改进机会。（从定性提升到度量与分析）

对于发生频率比较高的不符合问题要进行反思，分析是否是标准规范定义的不合理，从而识别出标准规范的改进点，也有可能不修改标准规范，而是加强标准规范在组织内的培训、推广力度。

质量保证人员与项目组打交道比较多，可以听到、看到很多好的或坏的现象，从中可以识别出改进的机会。

识别的改进机会要提交到EPG，进行评价、筛选以确定是否纳入组织级改进。

3、同行评审PR

Peer（同行）一般是做同样工作的人，或者是相关领域专家，同行评审也可以叫专家评审。

同行评审是在软件开发完成之前，通过技术专家发现潜在缺陷的一种有效手段，和在代码完成之后进行的软件测试可以相辅相成，提升软件的质量。而同行评审发现缺陷的成本低、修改缺陷的效率高，在开发中更值得投入。

需求评审

客户评审、内部专家评审

设计评审

正式的专家评审

代码评审

核心代码做代码走查，代码走查的核心是提升开发人员的编程习惯和能力。

一般代码，比如用户界面那种可以不查或简单走查。

必须要质量计划(或项目计划)里面预先定好评审方式，然后按照计划去做。同行评审作用大，缺陷去除在头甲，制订准则和计划，合理使用老专家。

4、验证和确认VV

验证和确认从不同的角度来解决问题：

验证针对的是工作产品和解决方案是否能正确地反映指定的需求，即“创建方式是正确的”。

确认针对的是解决方案是否能在目标环境下实现其预期用途，即“创建对象是正确的”。

验证确认不可缺，哪怕初级也要得，方法标准多助力，分析有益好结果。

注：部分描述引用了互联网上的文章，如有侵权请及时联系作者，谢谢。