CMMI的全称为Capability Maturity Model Integration，即能力成熟度模型集成。CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD），SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。 [1]
概述
编辑
CMMI是一种流程改进方法，为组织提供了有效流程的基本要素。它可用于指导项目、部门或整个组织的流程改进。CMMI还为评估当前流程提供了一个参考点 [2]。CMMI及其前一版本 CMM 适用于软件开发、解决了软件开发项目中的一个关键问题，即通常缺乏完善的管理框架来处理软件项目 [2-3]。
软件过程改进（SPI）的 CMMI模型是过去不断努力开发和实施的软件开发过程策略的重要组成部分，这些策略有可能降低软件开发失败的风险并提高所开发软件产品的质量。在这一方向上迈出的第一步是软件 CMMI 方法论的开发，该方法论为软件组织提供了如何控制其软件开发和维护过程的指导[4]。CMMI 方法论基于与软件开发相关的四个知识体系：
- 系统工程 (SE)
- 软件工程（SW）
- 集成产品与流程开发 (IPPD)
- 供应商采购（SS）
CMMI方法包括一个可生成多个集成模型的框架、培训课程、一种内部评估和外部评价方法 [5]。
20世纪90 年代初，最初的CMM 开发所遵循的方法是持续的流程改进应基于小步演进，而不是引入革命性的创新 [4]。作为流程评估和改进的事实标准，CMMI 被用来识别有效流程的关键要素，并对软件流程的成熟度进行评估。因此，CMMI 规定了流程改进的渐进过程，并将这一广泛的活动组织成一个循序渐进的过程，分为五个成熟度等级：初始、已管理、已定义、已量化管理和持续优化 [4]。这些成熟度等级代表了一个顺序标尺，它定义了一个组织的软件开发过程的成熟度。
在成熟度的初始阶段，软件流程的特点是临时流程，可能比较混乱。在这一阶段，几乎没有对过程进行定义，成功与否主要取决于个人努力。软件开发过程没有系统化的管理，从一个项目到另一个项目的经验传承也是杂乱无章的。在已管理级别，有一些基本的项目管理流程。由于这些方法要求采用系统的方法来管理软件开发，因此组织能够在类似的应用中重复以前的成功。在这个层次上，知识和经验是可以传递的，因此组织可以在以往项目经验的基础上，使下一个软件开发项目更加成功。在达到已定义级别的组织中，软件流程是标准化和文档化的，此外，所有项目都使用经批准的定制版流程。这种更加严格的方法论应用使知识更加针对特定的开发方法，从而在软件开发项目之间进一步传递知识和经验。已量化管理级别除了包括已定义的步骤外，还包括收集软件过程和产品质量的详细衡量标准，并对其进行定量分析。在成熟度的最高级别，持续优化级继续通过量化反馈来改进流程 [6]。
CMMI模型组件
所有的 CMMI模型都生成自 CMMI框架。该框架包括了所有的目标与实践，用以生成属于 CMMI 群集的 CMMI 模型。 所有的 CMMI 模型都包含 16 个核心过程域。这些过程域论及的基本概念对任一关注领域（即采购、开发、服务）的过程改进来说都是基础。
模型组件被分为三类——必需的、期望的与说明性的——这种分类体现了应如何对它们进行解读。 [24]
图 CMMI模型组件
过程域
过程域是某一领域内的一组相关实践，当它们共同得到实施时，能满足一组对于在本领域作出改进较为重要的目标。
22 个过程域按字母顺序排列如下：
• 原因分析与解决（Causal Analysis and Resolution：CAR）
• 配置管理（Configuration Management：CM）
• 决策分析与解决（Decision Analysis and Resolution：DAR）
• 集成项目管理（Integrated Project Management：IPM）
• 度量与分析（Measurement and Analysis：MA）
• 组织级过程定义（Organizational Process Definition：OPD）
• 组织级过程关注（Organizational Process Focus：OPF）
• 组织级绩效管理（Organizational Performance Management：OPM）
• 组织级过程性能（Organizational Process Performance：OPP）
• 组织级培训（Organizational Training：OT）
• 产品集成（Product Integration：PI）
• 项目监督与控制（Project Monitoring and Control：PMC）
• 项目计划（Project Planning：PP）
• 过程与产品质量保证（Process and Product Quality Assurance：PPQA）
• 量化项目管理（Quantitative Project Management：QPM）
• 需求开发（Requirements Development：RD）
• 需求管理（Requirements Management：REQM）
• 风险管理（Risk Management：RSKM）
• 供方协议管理（Supplier Agreement Management：SAM）
• 技术解决方案（Technical Solution：TS）
• 确认（Validation：VAL）
• 验证（Verification：VER） [24]
CMMI（Capability Maturity ModelIntegration For Software，软件能力成熟度模型集成）是在CMM（Capability Maturity Model ForSoftware，软件能力成熟度模型）的基础上发展而来的。CMMI是由美国卡耐基梅隆大学软件工程研究所（Software Engineering Institute，SEI）组织全世界的软件过程改进和软件开发管理方面的专家历时四年而开发出来的，并在全世界推广实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。
CMM模型自20世纪80年代末推出，并于20世纪90年代广泛应用于软件过程的改进以来，极大地促进了软件生产率的提高和软件质量的提高，为软件产业的发展和壮大做出了巨大的贡献。
图：CMM的历史
然而，CMM模型主要用于软件过程的改进，促进软件企业软件能力成熟度的提高，但它对于系统工程、集成化产品和过程开发、供应商管理等领域的过程改进都存在缺陷，因而人们不得不分别开发软件以外其他学科的类似模型。
最初，CMMI是一个结合了以下三个源模型的模型：软件能力成熟度模型（CapabilityMaturity Model for Software，SW-CMM）2.0版草稿C，系统工程能力模型（Systems Engineering Capability Model，SECM）［EIA 2002a ］，和集成产品开发能力成熟度模型（IntegratedProduct Development Capability Maturity Model，IPD-CMM）0.98版。选择以上三个源模型是由于它们在组织中的成功应用或者是它们采用的过程改进方法具有前景。第一个CMMI 模型（1.02版）设计给从事企业级过程改进的开发型组织使用。它于2000年发布。两年后1.1版发布，又过了四年1.2版发布。到发布1.2版时，另外两个CMMI模型又处在了酝酿之中。由于此次计划中的扩增，第一个CMMI 模型的名称需要进行改变，成为了CMMI 开发模型，群集的概念也自此产生。 [24]
CMMI采购模型于2007年发布。由于它建立在 CMMI 开发模型1.2版的 基础之上，因而也被命名为1.2版。两年后，CMMI服务模型发布。它建立在另外两个模型基础之上，并且也被命名为1.2版。2008年开始计划制订1.3版，以确保三个模型之间的一致性，并改进所有模型中高成熟度的资料。1.3版的CMMI 采购模型［Gallagher 2011，SEI 2010b］、CMMI开发模型［Chrissis 2011］和CMMI 服务模型［Forrester 2011，SEI 2010a］于2010年11月发布。 [24]
自从引入基于模型的过程改进之后，工程界至少在三个重要领域已经有了变化。
首先，执行工程的环境已经变得更加复杂。工程量更大、需要更多的人员、需要跨越公司界限、发布范围更宽更广，而且必须继续加快实现的进度，以满足客户的需要。这样导致各种协调工作的大量增加。
其次，执行工程任务的方式已经有了进化。交叉学科群组、并行工程、高度自动化的过程以及多国标准等都影响到工程实践。这样一来，一个工程项目可能要涉及到几个国际标准。
第三，软件工程研究所的软件能力成熟度模型（CMM）的成功，导致了各种模型的衍生，而每一种模型都探讨了某一特定领域中的过程改进问题。各机构也已采用多种改善模型分别处理各自的关键过程问题。在工程组织中模型的繁衍导致了过程改进目标和技术的冲突，也导致了实践人员在应用各种不同的模型来实现特定的需求时容易产生混淆，这就要求培训工作也随之增长。
所有这些变化都表明，有必要将各种过程改进工作集成起来。包含在当代工程中各种各样的学科和过程是密切交叉在一起的。在应用不同模型时，效率低下且容易混淆，常常要付出极其昂贵的代价。因而需要有一种单一的过程改进框架而又能跨越多种学科的工具。软件能力成熟度模型集成（CMMI）就是用来解决这三类问题的。 [7]
开发和应用CMMl的主要原因有三点：一是软件项目的复杂性的快速增长使过程改进的难度增大，二是软件工程的并行与多学科组合，三是实现过程改进的最佳效益。
（1）解决软件项目的过程改进难度增大问题。CMM成功实施以后，极大地提高了软件企业的开发效率和软件产品的质量，从而也提高了软件产品的可靠性和软件产业的信誉，这样人们就对软件寄予了更大的希望。人们希望软件能够完成更多、更大、更复杂的任务。
（2）实现软件工程的并行与多学科组合。CMM模型的成功实践，促进了工程和产品开发的组织发生了巨大的变革，变革的目标主要是为了消除与分段开发有关的低效。在分段开发过程中，中间产品传给下一阶段的工作人员时，有可能要进行大量的返工，以纠正原先的理解错误。并行工程、交叉学科群组、交叉功能群组、集成化产品群组以及集成化产品和过程开发等，都代表了在产品或服务的整个生命周期的合适时间内处理这类问题的不同方法。这种倾向意味着设计人员和客户要与制造人员、测试人员和用户共同工作，以支持开发需求的制造组织。这种工作方式蕴涵着所有关键的相关人员要支持产品或服务开发的所有阶段。
（3）实现过程改进的最佳效益。尽管过程改进存在复杂化的因素，但软件管理专家们相信，其中的许多障碍可以通过一个集成过程改进的公共模型来克服。这种信念反映了在集成方面所进行的工作和CMMl项目的作者和评审人员的经验。人们相信，正如通过CMM的过程改进能够产生显著的效益一样，集成过程改进也能产生更大的效益。
从根本上来说，过程改进集成主要影响四个领域：成本、侧重点、过程集成和灵活性。其中某些变化可能比另一些变化容易量化，但所有这些都体现了过程改进集成的真正优势。 [7]
CMMI开发模型推荐使用渐进的路径供组织改进其开发产品或服务的过程， 并采用级别来描述这一渐进的路径。级别也可以是评估中评定活动的结果。评估可应用于整个组织或小一些的组，如一组项目或一个部门。
CMMI支持两种使用级别的改进路径。一条路径使组织能够逐步改进其选定的单个过程域（或一组过程域）所对应的过程。另一条路径使组织能够以增量方式应对层次相继的过程域集合来改进相关的过程集。
这两种改进路径与两种类型的级别相关联：能力等级与成熟度级别。这些等级或级别对应至两种过程改进方法，称作“表示法”。这两种表示法被称为“连续式”与“阶段式”。使用连续式表示法使你能够达成“能力等级”。使用阶段式表示法使你能够达成“成熟度级别”。为达到某一特定的级别，不管是能力等级或成熟度级别，组织都必须满足预定进行改进的过程域或过程域集合中的所有目标。
这两种表示法都能够提供对过程进行改进的方式，以达成业务目标，两者也都提供了相同的要素，并使用相同的模型组件 [24]。
阶段式表示法相对于模型整体，使用成熟度级别来描述组织过程总体状态的特征；而连续式表示法则相对于单个过程域，使用能力等级来描述组织过程状态的特征。
（1）阶段式表示法
软件CMM是一种阶段式模型，该模型经过多年的成功使用已经被证明是有效的，这为选择阶段式表示法模型提供了最强有力的证据。考虑从不成熟组织向成熟组织的发展过程，阶段式表示法具有两方面优势。
首先，阶段式模型为支持组织的过程改进提供了一个过程平台，该模型将软件组织的软件能力成熟度描述为5级。对于着眼于改善过程成熟度的组织来说，
阶段式表示法提供了一条从成熟度级别1级到成熟度级别5级的改进之路。这条道路要求达成各成熟度级别中的过程域的目标。为了支持那些使用阶段式表示法的组织，过程域按照成熟度级别来分组，用以指明达成各成熟度级别需要实施的过程域。例如，成熟度级别2级包含了一系列的过程域，组织可以使用这些过程域来指导它的过程改进，直到组织达成所有这些过程域中的所有目标。一旦达成成熟度级别2级，组织就将关注点转移到成熟度级别3级的过程域，依此类推。适用于每个过程域的通用目标也已预设完成。通用目标2适用于成熟度级别2级，通用目标3适用于成熟度级别3级到5级 [24]。
其次，阶段式模型可以为组织定义一个过程成熟度等级，便于进行跨组织的比较。在阶段式模型中，每一个过程域都被指定归属到一个成熟度等级中。因此，基于阶段式模型为组织所定义的成熟度等级中，过程域的预期范围和应用将变得非常清晰。这样，在对不同的组织进行比较时，只要对比组织所达到的不同的成熟度等级，即可知道不同组织在执行过程域方面所存在的差别。
阶段式表示法存在两方面的缺点：一是阶段式表示法采用分组形式，将过程域划分到五个等级中。在一般情况下，一个组织要到达某一个等级，必须满足该等级及其低等级的所有过程域，因而缺乏灵活性。另外，阶段式表示法的每个等级都会出现同时进行多个过程改进的情况，因而工作量大，所花费的成本也很大。
图 阶段式表示法过程域
图 阶段式表示法
（2）连续式表示法
连续式表示法通过选择过程域或者一系列相互关联的过程域，使得组织能够选择其过程改进工作的关注点，从而最大程度上有益于组织及其业务目标。尽管过程域之间的依赖关系会给组织的选择带来一些限制，组织在选择时仍然具有相当程度的自由度。为方便那些使用连续式表示法的组织，过程域被划分为四类：过程管理类，项目管理类，工程类与支持类。这些类别突出了过程域之间的一些关键性联系。
有时会提到一种非正式的过程域分组：高成熟度过程域。四个高成熟度的过程域分别是：组织级过程性能，量化项目管理，组织级绩效管理与原因分析与解决。这些过程域专注于改进已实施过程的性能，这些过程性能与组织的业务目标紧密相连。一旦选好了过程域，必须选定与过程域关联的那些过程要成熟到何种程度（即选择适当的能力等级）。能力等级、通用目标与通用实践支持的是与单个过程域关联的过程的改进。例如，组织可能希望这个过程域达到能力等级2级，而另一个过程域达到能力等级3级。当组织达到某一能力等级，就将目光转向同一过程域的下一个能力等级，或者决定扩展范围，实施更多的过程域。在大多数过程域都达到能力等级3级之后，组织就能将其注意力转向高成熟度过程域，并追踪其中各个过程域的能力直至能力等级3级。对过程域与能力等级组合的选择一般通过目标概览图进行描述。目标概览图定义了需要应对的所有过程域以及每一个目标能力等级。概览图决定了组织过程改进活动中需要应对的目标与实践。大多数组织对其所选的过程域，至少会选择能力等级1级作为目标，这要求达成所有选定过程域的特定目标。然而，将目标定于高于能力等级1级的组织会通过实施通用目标与通用实践，来专注于组织内所选过程的制度化 [24]。
采用连续式模型也有如下两方面的优势：首先，连续式模型为用户进行过程改进提供了比较大的自由度。如同上面所说，阶段式模型确定了组织进行过程改进的最佳次序，但同时也限定了用户在进行过程改进时必须遵循单一的改善路径。而连续式模型则允许用户根据组织的业务目的来选择过程改进活动的次序。在连续式模型中，用户可以选择定义组织的成熟度等级，同时还可以选择定义更适合于自身业务环境的过程域的次序。组织可以在一个自己选择的次序中使过程域达到给定的能力等级，而不必遵循单一的阶段式模型的原则。
其次，基于连续式模型对组织的过程进行评估，其评估结果具有更好的可见性。在连续式模型中，可以为每个过程域定义多个能力等级，从而可以增强对过程改进中强项和弱点的认识。由于连续式模型是对每个个别的过程域进行单独的评定，并给出个别过程域的能力等级特征图，这样更便于观察。
连续式表示法也存在两方面的缺点：一是由于连续式表示法没有规定过程域应用的顺序，因而组织的过程改进需要软件过程改进专家的指导，以便确定组织需要改进的过程和改进的先后次序。另外，尽管组织应用连续式表示法进行了过程改进，但难以与其他软件组织进行组织间过程能力的比较。 [7]
图 连续式表示法过程域
图 连续式表示法
（3）连续式表示法和阶段式表示法的对比
两者有很多相同的组件（如：过程域、特定目标、特定实践等），并且这些组件拥有相同的层级与配置。 从概要视图中不能立即清楚了解的是，连续式表示法的关注点在于由能力等级度量的过程域能力，而阶段式表示法的关注点在于由成熟度级别度量的总体成熟度。CMMI的这一尺度（能力／成熟度尺度）被用于 基准比较与评估活动，并且用于指导组织的改进工作。能力等级适用于组织在单个过程域的过程改进达成情况。这些等级作为一种手段，增量式地改进与给定过程域相对应的过程。四个能力等级用数字0至3进行编号。成熟度级别适用于组织内横跨多个过程域的过程改进达成情况。这些级别作为一种手段，改进与一组给定过程域相对应的过程（即成熟度级别）。五个成熟度级别用数字1至5进行编号。
表将四个能力等级与五个成熟度级别进行对比。注意在两种表示法中，有两个等级的名称是相同的（即已管理级与已定义级）。区别在于不存在成熟度级别 0级、没有能力等级4级或5级；另外在1级时，能力等级1级与成熟度级别1级所使用的名称不同。
表 能力等级与成熟度级别的对比
连续式表示法涉及选择一个特定的过程域进行改进，以及确定对这个过程 域预期达到的能力等级。在这种情况下，过程已得到执行或仍不完整，这一点是重要的。因此，采用名称“不完整级”作为连续式表示法的起点。阶段式表示法涉及选择某一成熟度级别下的多个过程域进行改进；单个过程已得到执行或仍不完整就不是首要关注点。因此，采用名称“初始级” 作为阶段式表示法的起点。能力等级与成熟度级别都提供了一种改进组织过程的方式，并对组织能够并切实改进其过程的程度进行度量。然而，与过程改进相关联的途径却有所不同 [24]。
（1）能力等级
为支持对连续式表示法的使用，所有的CMMI模型在其设计与内容方面都体现了能力等级。四个能力等级定名为 0 级至3 级，每一级是一个层次，作为继续进行过程改进的基础。
0. 不完整级
1. 已执行级
2. 已管理级
3. 已定义级
当某等级下的所有通用目标都得到满足时，过程域的该能力等级就被达成。事实上，能力等级2 级与3 级使用的名称和通用目标2 与通用目标3 相同 是有意为之，因为这些通用目标与实践的每一条都反映了目标与实践的能力等级的意义。对每一能力等级的简短描述如下。
能力等级 0 级：不完整级 不完整的过程是没有得到执行或部分得到执行的过程。过程域的一个或多个特定目标没有得到满足，并且该等级下通用目标也不具备，这是因为没有理由对一个部分执行的过程进行制度化。
能力等级 1 级：已执行级 能力等级1 级的过程被描述为已执行的过程。已执行的过程是完成所需工作而产生工作产品的过程；过程域的特定目标得到满足。尽管能力等级1 级会取得重要改进，但如果未得到制度化，那些改进经过一段时间后可能会丢失。利用制度化（CMMI能力等级2 级与3 级的通用实践）有助于确保改进得以保持。
能力等级 2 级：已管理级 能力等级2 级的过程被描述为已管理的过程。已管理的过程是一种已执行的过程，这种过程按照方针得到计划和执行；雇用有技能的人，具备充分的资源以产生受控的输出；使相关干系人参与其中；得到监督、控制与评审；并且对其过程描述的遵守程度得到评价。能力等级2 级所体现的过程规范有助于确保现有实践在有压力的情况下得以保留。
能力等级 3 级：已定义级 能力等级3 级的过程被描述为已定义的过程。已定义的过程是一种已管理的过程，这种过程按照组织的裁剪指南，从组织的标准过程集中裁剪得到；它具有受维护的过程描述；并且将过程相关经验贡献给组织级过程资产。能力等级2 级与3 级之间的关键区别在于标准、过程描述与规程的范围。在能力等级2 级中，标准、过程描述与规程在过程的每个特定实例中（如在某一特定项目中）都可能有很大的不同。在能力等级3 级中，项目的标准、过程描述与规程是从组织的标准过程集中裁剪得来，以适应特定的项目或组织级单位，因而就更为一致，除非是裁剪指南所允许的差别。另一关键区别在于能力等级3 级的过程描述往往比能力等级2 级更为严谨。已定义的过程清晰地陈述了目的、输入、入口准则、活动、角色、度量项、验证步骤、输出与出口准则。在能力等级3 级中，通过使用对过程活动之间相互关系的理解，并使用过程及其工作产品的详细度量项，过程得到了更为积极的管理。
能力等级的提高
过程域的能力等级的达成通过应用了通用实践、或应用了与过程域相关联过程的合适替代实践来实现。达到过程域的能力等级1 级等同于说与该过程域相关联的过程是已执行的过程。
达到过程域的能力等级 2 级等同于说具备方针表明将执行过程。具备执行的计划，资源得到了提供，职责得到了分派，执行过程的培训得到了提供，与执行过程相关的所选工作产品得到了控制，等等。换而言之，能力等级2 级的过程能够如同任何项目或支持活动那样得到计划与监督。达到过程域的能力等级3 级等同于说存在与该过程域相关联的组织级标准过程，该过程可根据项目的需要被裁剪。组织内的过程现在得到了更为一致的定义与应用，因为它们的基础都是组织级标准过程。组织在其选定进行改进的过程域达到能力等级3 级之后，可以继续其改进旅程来应对高成熟度过程域（组织级过程性能，量化项目管理，原因分析与解决与组织级绩效管理）。高成熟度过程域关注于改进那些已实施过程的性能。高成熟度过程域描述了使用统计与其它量化技术来改进组织级过程与项目过程，以便更好达成业务目标。当组织以这种方式继续其改进旅程时，能够通过首先选择OPP 与QPM 过程域来获得最大收益，并将这些过程域带到能力等级1 级，2 级与3 级。这样，项目与组织能够将过程的选择和分析与其业务目标更加紧密地保持一致。在OPP与QPM过程域达到能力等级3级之后，组织能够选择CAR与OPM过程域来继续其改进道路。这样，组织能够使用统计与其它量化技术来分析业务绩效以确定性能方面的不足，并识别与部署有助于满足质量与过程性能目标的过程改进与技术改进。项目与组织使用原因分析来识别并解决影响性能的问题，并且促进最佳实践的传播。
（2）成熟度级别
为支持对阶段式表示法的使用，所有的CMMI模型在其设计与内容方面都体现了成熟度级别。成熟度级别由可改进组织整体绩效的、预先定义好的过程域集合中相关的特定实践与通用实践组成。组织的成熟度级别提供了描述其绩效特征的方式。经验表明，当组织每次过程改进工作所专注的过程域在数量上易管理时，组织能够做到最好；那些领域随着组织的改进，也需要不断成熟。成熟度级别是组织级过程改进的预定义的演进平台。每一个成熟度级别使组织过程中重要的子集合成熟，并为其走向下一个成熟度级别做准备。成熟度级别通过与预先定义好的过程域集合相关联的特定目标与通用目标的达成情况进行度量。
五个成熟度级别定名为 1 级至 5 级，每一级是一个层次，作为继续进行的 过程改进的基础。
1. 初始级
2. 已管理级
3. 已定义级
4. 已量化管理级
5. 持续优化级。
成熟度级别 2 级与 3 级使用和能力等级 2 级与 3 级相同的名称。这种名称上的一致性是有意而为之，因为成熟度级别与能力等级的概念是互补的。成熟度级别被用于描述相对于一个过程域集合的组织级改进特征，而能力等级被用于描述相对于单个过程域的组织级改进特征。
成熟度级别 1 级：初始级 处于成熟度级别1 级时，过程通常是随意且混乱的。组织往往不能提供一个稳定的环境来支持过程。这些组织的成功依赖于组织内人员的能力与英雄主义，而不是使用经过实践证明的过程。尽管有这些混乱的情况，成熟度1 级的组织也常常能产出能用的产品与服务，但它们经常超出在计划中记录的预算与成本。成熟度级别1 级的组织的特征是具有过度承诺的倾向，他们在危机情况下会舍弃他们的过程，而且没有能力去复制他们的成功。
成熟度级别 2 级：已管理级 处于成熟度级别2 级时，项目确保其过程按照方针得到计划与执行；项目雇用有技能的人，具备充分的资源以产生受控的输出；使相关干系人参与其中；得到监督、控制与评审；并且对其过程描述的遵守程度得到评价。成熟度级别2 级体现的过程规范有助于确保现有实践在有压力的情况下得以保留。当具备了这些实践时，项目的执行与管理能够根据其文档化的计划来进行。另外在成熟度级别2 级，工作产品的状态在定义好的时间点（如，在主要里程碑点，在完成主要任务时）对管理层是可视的。相关干系人之间承诺得到建立并在必要时得到修改。工作产品得到了适当的控制。工作产品与服务满足其规定的过程描述、标准与规程。
成熟度级别 3 级：已定义级 处于成熟度级别3 级时，过程得到清晰的说明与理解，并以标准、规程、工具与方法的形式进行描述。作为成熟度级别3 级的基础，组织的标准过程集得到了建立并随时间进行改进。这些标准过程被用于在整个组织中确立一致性。项目根据裁剪指南，通过对组织的标准过程集进行裁剪来建立已定义的过程。成熟度级别2 级与3 级的关键区别在于标准、过程描述与规程的范围。在成熟度级别2 级中，标准、过程描述与规程在过程的每个特定实例中（如在某一特定项目中）都可能有很大的不同。在成熟度级别3 级中，项目的标准、过程描述与规程是从组织的标准过程集中裁剪得来，以适应特定的项目或组织级单位，因而就更为一致，除非是裁剪指南所允许的差别。另一关键区别在于成熟度级别3 级的过程描述往往比成熟度级别2 级更为严谨。已定义的过程清晰地陈述了目的、输入、入口准则、活动、角色、度量项、验证步骤、输出与出口准则。在成熟度级别3 级中，通过使用对过程活动相互关系的理解，并使用过程、其工作产品及其服务的详细度量项，过程得到了更为积极的管理。在成熟度级别3 级，组织进一步改进与成熟度级别2 级过程域相关的过程。在成熟度级别2 级时没有解决的与通用目标3 相关联的通用实践得到应用，以达成成熟度级别3 级。
成熟度级别 4 级：已量化管理级 在成熟度级别4 级，组织与项目建立了质量与过程性能的量化目标并将其用作管理项目的准则。量化目标基于客户、最终用户、组织、过程实施人员的需要。质量与过程性能以统计术语的形式得到理解，并在项目的整个生命期内得到管理。针对选定的子过程，过程性能的具体度量项得到了收集与统计分析。在选择需要分析的子过程时，理解不同子过程之间的关系及其对达成质量与过程性能目标所产生的影响十分关键。这种方法有助于确保使用统计与其它量化技术的子过程监督能应用于对业务最有整体价值的地方。过程性能基线与模型能用于帮助设定有助于达成业务目标的质量与过程性能目标。成熟度级别3 级与4 级的关键区别在于对过程性能的可预测性。处于成熟度级别4 级时，项目绩效与选定的子过程的性能得以使用统计与其他量化技术进行控制，预测则部分地基于对精细粒度的过程数据的统计分析。
成熟度级别 5 级：优化级 处于成熟度级别5 级时，组织基于对其业务目标与绩效需要的量化理解，不断改进其过程。组织使用量化的方法来理解过程中固有的偏差与过程结果的原因。成熟度级别5 级关注于通过增量式的与创新式的过程与技术改进，不断地改进过程性能。组织的质量与过程性能目标得到建立，然后被不断修改体现变化的业务目标与组织级绩效，并被用来作为管理过程改进的准则。部署的过程改进的效果通过使用统计与其它量化技术来进行度量，并与质量与过程性能目标进行比较。项目已定义的过程、组织标准过程集与作为支撑的技术都是可度量的改进活动的目标。成熟度级别4 级与5 级的关键区别在于管理与改进组织级绩效的关注点。处于成熟度级别4 级时，组织与项目关注于子过程层面对性能的理解与控制，并使用其结果来管理项目。处于成熟度级别5 级时，组织使用从多个项目收集来的数据对整体的组织级绩效进行关注。对数据的分析识别出绩效方面的不足与差距。这些差距用于驱动组织级过程改进，并产生绩效方面的可度量的改进。
成熟度级别的提高
组织可以实现其成熟度的累进式进步，从实现对项目级的控制开始，直至最高级别，即在整个组织范围的绩效管理与持续的过程改进，并使用定性的与定量的数据进行决策。提高了的组织级成熟度与组织能够达成的预期范围内的改进结果相关联，因而，成熟度也是预测组织今后项目大致结果的一种方法。例如，在成熟度级别2 级，通过建立扎实的项目管理，组织已经由随意的状态提升到规范的状态。随着组织达成某一成熟度级别中一系列过程域的通用目标和特定目标，组织在提升组织级成熟度的同时也收获了过程改进带来的收益。由于每一成熟度级别都为下一级别打下必要的基础，因此，在成熟度级别上的跳级尝试往往会导致反效果。同时，需要认识到的是，过程改进活动应该关注于以组织的业务环境为背景的组织需要上，并认识到更高的成熟度级别中的过程域可以应对组织或项目的当前的与未来的需要。例如，试图从成熟度级别1 级迈向成熟度级别2 级的组织常常被鼓励成立一个过程组，而过程组的建立由成熟度级别3 级的过程域“组织级过程关注”所应对。虽然过程组并非成熟度级别2 级组织的必要特征，但是它可以成为组织达成成熟度级别2 级途径中的有用部分。这个情形有时被描述成建立一个成熟度级别1 级的过程组来引导成熟度级别 1 级的组织走向成熟度级别2 级。成熟度级别1 级的过程改进活动可能主要依赖于过程组人员的洞察力与能力，直到具备了能够支持更规范与更大范围改进的基础。组织可以选择任何时间开始过程改进，即使还没有准备好迈向某些特定实践所处的成熟度级别。然而，在这种情况下，组织应该理解这些改进的成功存在风险，因为进行成功制度化的基础尚未完成。缺乏适当基础的过程有可能在最需要它们的时候被舍弃——当面临压力时。当成熟度级别2 级的管理实践有所缺失时，作为成熟度级别3 级组织特征的已定义的过程可能处于较大风险之中。例如，管理层可能对一个计划得很糟糕的进度安排去作出承诺，或者不能控制已形成基线的需求的变更。类似地，很多组织过早地去收集具有成熟度级别4 级特征的数据，却发现由于过程和度量定义的不一致导致这些数据难以解读。使用与较高成熟度级别相关联过程域中过程的另一个例子存在于构建产品的过程中。我们当然期望成熟度级别1 级的组织会进行需求分析、设计、集成与验证。然而，这些活动直到成熟度级别3 级时，才会得到描述，并被定义为紧密结合的、融为一体的工程类过程。成熟度级别3 级的工程类过程与已具备的正在逐渐成熟的项目管理能力互为补充，这样，工程类改进就不会因随意的管理过程而丢失 [24]。
在美国，很多企业通过CMMI评估一方面为了满足承包国防工程或一些大企业的工程的要求，另一方面也是为了提高企业自身的管理能力。美国政府的工程项目，绝大多数都要求承包商具有一定的CMMI级别作为参加投标的资格。越来越多的大型企业业开始要求其工程承包商具有一定的CMMl级别。级别高的企业在赢得项目的竞标中具有一定的优势。因此，如果没有CMMI的等级评估，企业就会失去很多商机。 [1]
CMMI通过提供一套全面的框架和实践，帮助组织提高软件质量和项目管理效率，具体作用如下：
（1）过程改进和质量控制：CMMI模型强调软件过程的持续改进，通过定义和实施一系列成熟度等级，帮助组织识别和改进其软件开发过程中的弱点。这包括需求管理、软件设计、代码开发、测试和维护等各个阶段的质量管理方法 [8]。通过这种方式，CMMI模型使软件质量具有可控性和可测性，从而促进高质量软件的开发 [9]。
（2）项目管理效率提升：CMMI模型通过建立适合企业业务模式的软件生命周期模型和管理机制，支持复杂多变的软件设计和研发过程。这包括采用灵活的应用WBS（工作分解结构）和分类管理软件开发的原则，以快速响应市场和内部管理需求。此外，CMMI模型还促进了企业管理能力的提升，激活了企业高效运转的动力 [10]。
（3）融合现代开发方法：CMMI模型与DevOps等现代开发方法的融合，进一步提高了产品交付质量和用户体验。这种融合适应了当前市场需求的快速更新，使得单一的管理体系能够适用于所有项目实施 [11]。
（4）提高敏捷性和纪律性：通过将Scrum方法论与CMMI成熟度模型结合，CMMI模型不仅提高了软件开发的敏捷性，还增强了纪律性。这种方法通过将Scrum实践映射到CMMI的成熟度等级上，同时为Scrum未充分覆盖的实践添加新的实践，以改善实际的软件开发过程 [12]。
（5）提高客户满意度：通过应用CMMI的最佳实践来改进管理过程，如需求、验证和确认，组织能够提高其过程的质量，从而减少缺陷并提高客户满意度 [13]。
（1）认证
CMMI是一个庞大的过程元模型，自发布以来在世界软件界产生了巨大的影响。CMMI等级评估已经成为业界公认的标准，CMMI的证书成了一个企业或组织能力和形象的标志，没有这个证书不仅难以获得国外项目，甚至也难以在国内一些项目的竞标中获胜。CMMI适合企业操作，避免了某些管理体系只重理论而忽视实践的缺陷。在我国，随着媒体的宣传和政府的支持，许多企业引入了CMMI咨询和认证，对于整个软件行业的管理提升及研发效率提高起到了很大的帮助作用。但也有一些企业引入CMMI体系后，只留下一些形式上的开发流程和文档模板，在管理上并无实质性改进。对于CMMI，业界一直存在着两种 声音，有人认为CMMI执行过度，得不偿失；也有人说它过于通用，实用价值不大；但多数人还是认同它，并根据需要加以应用。 [14]
（2）优势
在当今的高科技商业环境中，几乎所有企业都在制造日益复杂的产品和服务。因此，产品开发生命周期变得更加难以管理和控制--企业经常会遇到成本超支、影响质量和客户期望的缺陷以及因返工而错过最后期限等问题。
CMMI开发是一套集成的最佳实践，可提高企业开发优质产品和服务的能力，满足客户和最终用户的需求。
主要优点：
缩短产品上市时间--确保快速高效地交付产品和服务，几乎没有返工。
提高质量 - 提高产品开发质量和一致性，减少缺陷。
降低成本--通过改进计划、调度和预算流程来降低成本。
改进产品生命周期管理--满足客户对从交付到维护和运营的整个产品生命周期的期望。
获得组织灵活性 - 利用增加收入和削减成本的机会，快速、有效、持续地交付产品和服务。 [15]
（3）难题
CMMI在小型软件企业中存在实施难题，面临的主要挑战包括资源有限、人员能力不足、项目周期短和成本控制等问题。以下是几个具体的解决方案：
(1)采用敏捷开发方法与CMMI结合：敏捷开发方法如Scrum可以有效解决CMMI在小型软件企业中实施时遇到的问题，同时满足特殊需求 [16]。通过结合Scrum和CMMI，可以构建新的项目管理框架，这有助于小型和中型组织在遵循CMMI标准的同时获得新的能力价值。
(2)裁剪和重定位CMMI关键实践：针对小型软件企业的特点，对CMMI的关键实践进行裁剪和重定位，使其更加适合小型企业的实际情况 [17]。这种方法已经在实践中证明了其可行性和经济性能。 [18]
(3)实施基于CMMI的风险管理：在CMMI的第一级就包括风险管理活动，特别是对于小型软件企业来说，这是非常重要的。风险管理可以帮助识别和评估可能影响软件开发进度和成功部署的风险 [19]。
(4)采用定制的Web-based工具：使用定制的Web-based工具，如Keymind Measurement ReportingTool，可以帮助小型组织更有效地实现和维护CMMI成熟度等级 [20]。
(5)快速有效的CMMI实施方案：针对小型软件企业的特点，提出一套快速有效的CMMI实施方案，以期降低成本、提升管理水平 [21]。
(6)结合其他过程标准：通过融合CMMI与其他过程标准（如PMBP、LESAT、ISO 9001等），可以使CMMI更加完善，更好地满足小型软件企业的特定需求 [17]。
(7)提供实施建议和过程改进框架：针对小型软件企业应用CMMI时面临的困难，提出实施建议和过程改进框架，以帮助这些企业更好地理解和应用CMMI [22]
8.1CMMI 1.3
CMMI-DEV1.3版中的重大改进有：
• 对高成熟度过程域进行了重大的改进，以体现业界的最佳实践，改进包括：将过程域“组织级创新与部署”（Organizational Innovation and Deployment，OID）更名为“组织级绩效管理”（Organizational Performance Management，OPM），并增加了一个新的特定目标与几个新的特定实践。
• 对模型架构进行了改进，简化对多个模型的使用。
• 对说明性的资料进行了改进，包括修改了工程类实践来体现产业界的最佳实践，并增加了对使用敏捷方法的组织的指南。
• 改进了术语表中的定义与模型术语，以加强模型的清晰性、准确性与 易用性。
• 删除了 4 级与 5 级的通用目标与通用实践，并且取消了能力等级 4 级与 5 级，以便将高成熟度适当专注于业务目标的达成之上。其实现可通过将能力等级1级至3级应用于高成熟度过程域（原因分析与解决、量化项目管理、组织级绩效管理与组织级过程性能）。
CMMI1.3版本的通用目标与通用实践
（1）过程制度化
制度化是过程改进中的一个重要概念。当制度化在通用目标与通用实践的描述中被提及时，就意味着该过程已根植于工作的执行方式中，并且具有过程履行（即执行）的承诺与一致性。
已制度化的过程在有压力的情况下更可能得到保持。然而，当过程的需求与目标发生变化时，过程的实施可能也需要改变，以确保其依然有效。通用实践描述了应对有关制度化的这些方面的活动。
制度化的程度通过通用目标进行具体化，并通过如表所示的、与各目标相关联的过程名称予以表达。
|
通用目标
|
过程的进步
|
|
GG1
|
已执行的过程
|
|
GG2
|
已管理的过程
|
|
GG3
|
已定义的过程
|
（2）通用目标与通用实践
|
通用目标
|
说明
|
||
|
GG 1
|
|
达成特定目标
|
过程域的特定目标得到过程的支持，过程的支持通过将可识别的输入工作产品转换
为可识别的输出工作产品来实现。
|
|
|
GP 1.1
|
执行特定实践
|
执行过程域的特定实践，以开发工作产品并提供服务来达成过程域的
特定目标。
|
|
GG2
|
|
制度化为已管理的过程
|
过程得到制度化为已管理的过程。
|
|
|
GP 2.1
|
建立组织级方针
|
建立并维护组织级方针，以计划并执行过程。
|
|
|
GP 2.2
|
计划过程
|
建立并维护计划，以执行过程。
|
|
|
GP 2.3
|
提供资源
|
提供充分的资源，以执行过程、开发工作产品并提供过程的服务。
|
|
|
GP 2.4
|
分派职责
|
分派职责与职权，以执行过程、开发工作产品并提供过程的服务。
|
|
|
GP 2.5
|
培训人员
|
必要时，培训过程的执行或支持人员。
|
|
|
GP 2.6
|
控制工作产品
|
将所选择的过程工作产品置于适当的控制级别。
|
|
|
GP 2.7
|
识别相关干系人，并使之参与
|
识别过程的相关干系人，并使之按计划参与。
|
|
|
GP 2.8
|
监督并控制过程
|
对照执行过程的计划，监督并控制过程，并采取适当的纠正措施。
|
|
|
GP 2.9
|
客观评价遵守程度
|
对照过程描述、标准与规程，对过程与所选工作产品的遵守程度进行
客观评价，并处理不符合的情况。
|
|
|
GP 2.10
|
与上级管理层一起进行状态评审
|
与上级管理层一起对过程的活动、状态与结果进行评审，并解决问题。
|
|
GG 3
|
|
制度化为已定义的过程
|
过程得到制度化为已定义的过程
|
|
|
GP 3.1
|
建立已定义的过程
|
建立并维护已定义过程的描述。
|
|
|
GP 3.2
|
收集与过程相关的经验
|
收集源于过程的计划与执行的、与过程相关的经验，以支持组织过程
与过程资产未来的使用与改进。
|
2018年7月17日，CMMI 研究院正式发布了 CMMI 2.0 中文版。CMMI 2.0 版本是一个全球公认的软件、产品和系统开发优良实践过程改进模型，能够帮助组织提升绩效。
与此同时，CMMI中国卓越中心也宣布正式成立，该中心位于北京，将支持 CMMI 2.0 版本和未来更多升级，致力于推动软件、服务、数据管理和网络安全的新兴实践，通过教育、咨询、评估、对标和研究为中国企业提供服务。CMMI开发2.0版本是 CMMI 研究院针对软件、产品和系统优良实践发布的过程改进模型。
CMMI的较早版本已被用于评估和提升全球领先组织和企业的绩效，惠及数千家中国组织。CMMI开发2.0版本让经过验证的方法能适应不断变化的技术环境，更精简易用，确保决策者更好地应对新挑战，极大限度提高业绩。
CMMI2.0版本产品套件包括成熟度模型、使用指南、系统与支持工具、培训、认证和评估方法。与前期版本一样，CMMI2.0 版本使用五个级别代表提高能力成熟度以改进业务绩效的途径。
CMMIV2.0 模型的设计目的是在不断变化的全球环境中优化业务绩效，它是一套经过验证的全球最佳实践，使组织能够建立和基准化关键能力，以应对最常见的业务挑战，包括 [15]：
确保质量
工程设计与产品开发
交付和管理服务
选择和管理供应商
规划和管理工作
管理企业复原力
劳动力管理
支持实施
保持习惯和毅力
提高绩效
CMMI2.0版本具备以下优势 [15]：
(1)改善业务绩效- 商业目标直接与运营相关联，达到在时间、质量、预算、客户满意度和其他关键驱动因素的性能方面实现可衡量的提升。
(2)利用当前的优良实践- CMMI2.0 版本是经过验证的优良实践的可靠来源，并会在新的在线平台上持续更新，能够反映不断变化的业务需求。
(3)构建敏捷弹性和规模化- 在整个企业范围内以绩效为焦点，为加强使用Scrum的敏捷项目过程提供直接的指导。
(4)对能力和性能进行对标- 新的性能导向的评估方法提高了基准评估的可靠性和一致性，同时缩短了准备时间，降低了生命周期成本。
(5)加速采用- 通过在线平台和应用指南，更容易获得 CMMI 提供的帮助 [15]。
CMMI2.0 的变化 [25]
（1）思想的变化
1）进一步强调商业目标对过程改进的驱动作用、
在 CMMI V1.3 版本中，只是在5 级中强调了围绕商业目标进行过程改进，但是在 2.0中，无论哪个等级都强调了围绕商业目标进行改进，这是 2.0的一个基本思想，也是过程改进的本质。对于每条实践的描述，在 2.0中增加了一个构件，即实践的价值，这就是围绕商业目标进行改进的体现。
2）要通过性能变化衡量改进效果
是否围绕商业目标进行改进，要体现在组织级的能力变化上，要通过度量数据体现出来而不能仅仅是主观的判断。在CMMIV2.0 的评估方法中，要求每次评估都要提交组织的性能报告，要通过定量的数据说明组织级能力的变化。
3）高层经理对过程改进参与情况的具体化描述
在 CMMI V1.3 版本中，高层经理对过程改进、项目管理的参与是通过共性实践来体现的，而在CMMI V2.0中，将高层需要参与的活动提炼为GOV实践域，进一步强调高层参与过程改进的重要性。
4）员工的行为要固化为工作习惯
确保过程发挥作用，需要体现在具体的工作人员按照过程要求在实践中切实执行，即使在面临工期压力的情况下，也不能放弃。从混乱到规范，从有意识到养成习惯。最高的境界就是体系规范的执行深入到每个人的意识中，按照本能反应、按照规范做事情。
5）过程灵活映射到模型。
CMMI模型中的实践定义了 What to do，而 How to do 是由每个组织自己去定义的而且要紧紧围绕着组织的商业目标来定义。在能满足组织级的商业目标后，再来判断是否可以将组织的 How to do 映射到 CMM 模型的 What to do。How to do 可以有很多不同的做法，相当灵活。软件组织执行的一系列过程并不是生搬硬套模型，正相反，型恰恰是为组织过程来服务的。
6）随机抽样检查有助于过程固化。
按照 CMMI 评估方法的要求，所有参与评估的项目应该是随机抽样的，在 CMMI V1.3的评估方法中是由主任评估师与Sponsor 协商确定，而在CMMIV2.0 中，则是由被评估的组织上报所有可能的参评项目，由CMMI研究所的评估系统自动随机抽取参评项目。这种抽样方法的变化，重点在于要求企业真正能够将自己的体系推广到每个项目，而不是仅仅在参评项目中按照规范的方法做事情。
（2）关键术语的变化
1）过程域修改为实践域，简写仍然是 PA.
当提到过程的概念时，过程中的实践之间是有先后顺序关系的，但是其实 CMMI 模型中的实践是没有顺序关系的，修改为实践域则避免了这个误解。
2）新增了能力域的概念
在模型中对能力域有一个正式的定义:
Acapability area (CA) is a group of related practice areas that can provide improvedperformance in the skills and activities of an organization or project. A capabilityarea view is a subset of the CMMl V2.0 model that describes a predefined set ofpractice areas that make up a specific capability area. Capability areas are a typeof a view.
通俗地讲，能力域就是针对组织要解决的特定问题的一组相关实践域。能力域的名字就是针对要解决问题的一种概括描述。CMMIDEV V2.0 的能力域有:确保质量、工程和开发产品、选择和管理供应商、策划并管理工作、管理业务弹性、管理人力、支持实施、建立并维持能力、改进性能等。
3）过程域类型修改为了能力域类型
在 CMMI V1.3 的连续式表示方法中，是将过程域分为了四种类型:工程类、支持类。项目管理类、过程管理类。而 CMMI V2.0 中的能力域归为 4类,称为能力域类型，即:doing、managing、enabling,、improving.
可以将两种分类方法做一个近似对等映射，即:
工程类 -->doing;
项目管理类 -->managing;
支持类 -->enabling;
过程管理类-->improving;
4）新增了视图(view)的概念,
视图是由最终用户选择的或 CMMI研究所预定义的、对模型的最终用户很重要的一组实践域及实践组的集合。
CMMI研究所预定义的视图有:
CMMlDevelopment V2.0;
CMMlService V2.0;
CMMlSupplier Management V2.0;
CMMlPlanning and Managing Work Capability Area;
最终用户选择的视图如:
CMMIDEV 和CMMI SVC 2.0;
其他任意的 PA 或能力域或实践组的组合
（3）结构与描述方式的变化
1）采用平实的语言描述
V2.0模型尽量采用平实的语言进行描述,通俗易懂,还原到最初 CMM 模型的描述风格更加易于理解和学习，对模型的英文原文进行词频统计发现仅有 3500 多个单词。
2）整合了 People CMM 等多个模型。
除了 CMMI V1.3 中的开发、服务、采购三个系列仍然包含在在 CMMI模型中，2.0 的模型中还集成了 People CMM 模型。People CMM 模型虽然在全球的评估数量不多，但是作为一个优秀的人力资源管理模型，仍然值得推广，在企业的能力提升中同样扮演着重要的角色，所以集成 People CMM 进来是一个明智的决策!另外，V2.0 的模型还计划增加关于安全与保密相关的实践域。
3）不再对实践域划分等级，而是对实践划分等级。
这是一个很显著的变化，这个变化更符合实际、更合理。比如对于 CAR 而言，2、3 级的企业也应该做根因分析，只是与4、5 级的企业相比进行根因分析的方法手段有差别而已.在一个 PA 中的不同等级的实践集合称为一个实践组。
在 20 个实践域中，只有 CM 仅包含1、2 级的实践，而 PLAN，PCM，SAM 三个过程域包含了 1、2、3、4 级的实践，CAR与 MPM 包含5个等级的实践，其他实践都是包含了1、2、3 级的实践。
2级的实践累计有 79 条，3 级的实践累计有 73 条，4 级的实践累计有 10 条，5 级的实践累计有 4条。CMMI DEV V2.0 的实践统计如表
|
实践域简写
|
实践域名称
|
实践个数小计
|
Level 1
|
Level 2
|
Level 3
|
Level 4
|
Level 5
|
|
CAR
|
原因分析域解决方案
|
11
|
1
|
2
|
5
|
2
|
1
|
|
CM
|
配置管理
|
7
|
1
|
6
|
|
|
|
|
DAR
|
决策分析域解决方案
|
8
|
2
|
5
|
1
|
|
|
|
EST
|
估算
|
6
|
1
|
3
|
2
|
|
|
|
GOV
|
治理
|
7
|
1
|
4
|
2
|
|
|
|
II
|
实施设施
|
7
|
1
|
2
|
3
|
1
|
|
|
MPM
|
管理性能与度量元
|
22
|
2
|
6
|
6
|
5
|
3
|
|
MC
|
监督和控制
|
10
|
2
|
4
|
4
|
|
|
|
OT
|
组织级培训
|
9
|
1
|
2
|
6
|
|
|
|
PR
|
同行评审
|
6
|
1
|
4
|
1
|
|
|
|
PLAN
|
策划
|
15
|
2
|
8
|
4
|
1
|
|
|
PAD
|
过程资产开发
|
11
|
1
|
3
|
7
|
|
|
|
PCM
|
过程管理
|
12
|
3
|
2
|
6
|
1
|
|
|
PQA
|
过程质量保证
|
6
|
1
|
4
|
1
|
|
|
|
PI
|
产品集成
|
10
|
1
|
6
|
3
|
|
|
|
RDM
|
需求开发与管理
|
14
|
1
|
6
|
7
|
|
|
|
RSK
|
风险和机会管理
|
8
|
1
|
2
|
5
|
|
|
|
SAM
|
供应商合同管理
|
10
|
3
|
4
|
2
|
1
|
|
|
TS
|
技术解决方案
|
10
|
1
|
3
|
6
|
|
|
|
VV
|
验证与确认
|
7
|
2
|
3
|
2
|
|
|
|
合计
|
|
196
|
29
|
79
|
73
|
10
|
4
|
4） PA 的目的修改为PA 的意图与价值。
PA的意图描述了该实践域期望的输出结果。PA 的价值描述了通过实施本 PA 的实践所实现的业务价值，即收益。这个变化更强调了模型的实施要聚焦于为组织带来商业利益，提升企业的业务能力。
5） 为每个实践域、每个能力域设计了图标。为了便于模型的理解、记忆与推广，每个实践域、每个能力域都有自己的图标，这些图标简单易记，很形象，有助于理解模型的含义。
6） 不再区分特定实践与共性实践,
所有的共性实践被整合到 2个 PA 中，即 GOV与 I。GOV 描述了高层管理者在过程改进、过程实施中需要做的活动。"描述了过程改进、过程实施所需要的基础设施。这2个 PA都是为了确保过程规范能够在组织中固化为习惯。
7） 区分了内核信息与特定场景内容。
每个实践域都分解为一个共通描述章节(内核信息)与可适用的特定场景描述章节，目前提供的针对 Scrum 的特定场景描述，以后还会灵活增加其他特定场景。
8） 模型展示工具的变化。
CMMI研究对于模型的展示提供了 Model viewer 工具，可以在线査阅模型，也可以下载 pdf 格式的模型供个人使用。主任评估师与教员可以全年使用该工具，对于接受 Intro培训课程的学员，则提供了7天的时间窗口可以使用该工具阅读模型、下载模型。下载的模型印有中有学员账号信息，不经过CMMI研究所授权的非法传播都是禁止的。
（4）过程域的变化
CMMIDEV V1.3 中有 22 个过程域,而目前发布的 CMMI DEV V2.0 中有 20 个实践域其中有些实践域保留了原来的名字，如 CAR，CM，DAR，OT，PI，SAM 等;有些实践域对名字做了微调，如 MC，PLAN，PAD，RSK，PQA等;有些实践域是新增或者剥离出来的，如 EST，PR,GOV,等;有些实践域则是由原来的多个 PA 合并而来,如 MPM,RDMVV。与 1.3 版本的映射可以参见表。
|
CMMI V2.0的实践域
|
CMMI V1.3的过程域
|
备注
|
|
CAR
|
CAR
|
|
|
CM
|
CM
|
|
|
DAR
|
DAR
|
|
|
EST
|
|
新增PA，从PP中剥离出来
|
|
GOV
|
|
定义了公司高层经理的活动。来自于V1.3的共性实践
|
|
II
|
|
来自于V1.3的共性实践
|
|
MPM
|
MA
|
所有定量管理的实践都合并到MPM中
|
|
QPM
|
||
|
OPP
|
||
|
OPM
|
||
|
MC
|
PMC
|
风险跟踪的实践剥离到RSK中
IPM中有关跟踪的实践汇总到本PA，如管理关键依赖、环境等。
里程碑评审不再出现在实践名字中
|
|
OT
|
OT
|
|
|
PR
|
|
新增PA，从VER中剥离出来
|
|
PLAN
|
PP
|
名称修改
估算的实践剥离成为一个单独的PA
数据管理的实践剥离到CM中
风险管理的实践剥离到RSK中
IPM中与策划有关的实践汇总到本PA
增加对移交活动的计划
|
|
PAD
|
OPD
|
名称修改
删除了建立团队运作规则指南的实践
|
|
PCM
|
OPF
|
有些实践来自于OPM，改了名字
|
|
PQA
|
PPQA
|
名称修改
|
|
PI
|
PI
|
|
|
RDM
|
RD
|
所有的需求工程实践都合并到RDM中
|
|
|
REQM
|
|
|
RSK
|
RSKM
|
RSK是风险和机会管理，增加了机会管理
|
|
SAM
|
SAM
|
|
|
TS
|
TS
|
|
|
VV
|
VER
|
合并为VV。同行评审独立成为一个PA
|
|
VAL
|
||
|
IPM
|
IPM拆分到PLAN和MC中
|
（5）评估方法的变化
1）抽样规则的变化。
这是评估方法中最显著的变化。通过提前 60 天由系统自动随机抽样参评的项目，确保了抽样的代表性，更能客观地考察组织是否达到了CMMI的某个等级，同时也降低了企业为了获得证书，而临时编制证据的可能性。
2）新增了维持性评估。
在 1.3 版本中，区分了 Class A,B,℃ 三种不同严格程度的评估，而在 2.0 中，则区分为了标杆对比评估(Benchmark appraisals)，维持型评估(Sustainment appraisals)，评价评估(Evaluationappraisals)，行动计划复评(Action plan reappraisals)。其中标杆对比评估类似原来的 Class A评估，有效期仍然是3年。评价评估可以映射为原来 B、C类评估，而行动计划评估也是原来V1.3 的评估方法所有的。变化比较大的是维持型评估，维持型评估的要点如下:
维持型评估最少2个评估员，包含评估师。
有效期为 2年。
1/3的实践域要深入分析，其他可以概要分析。如果是高成熟度的评估，则包含高成熟度实践的实践域是一定要深入分析的。
评估时对上一次评估发现的弱项(实践)要考察。比如某个实践有弱项，则下次维持型评估时，该实践要深入分析。这是除 1/3 深入分析的 PA 之外附加的。
最多可以连续做3次维持型评估。即第1次标杆对比评估，第2、3、4 次可以做维持型评估。第5次就必须是标杆对比评估了。
最新的维持型评估结论将替代上次评估的结论。如果上一次评估的到期日是 2022年5月1日，是成熟度等级3级，而该组织在2022年的1月1日完成了一次维持型评估评级为成熟度等级 2级，则该组织的等级就是2级，原来的3级结论作废。
最新的维持型评估将中止上次评估的有效期。如果上一次评估的到期日是 2022(7)年5月1日，该组织在 2022年的1月1日完成了一次维持型评估，则该组织的评估有效期就是 2024 年的1月1日。
不能比上一次评估的级别更高。即如果上一次评估是3级，维持型评估不能是 4、5 级。如果要评 4、5 级，必须是标杆对比评估
满足了以下条件才可以做维持型评估：
i) 抽样因子类型和上一次评估相同或是其子集。
ii）抽样因子取值和上一次评估相同或是其子集。
iii)评估的单位不变或是其子集。
iv)至少有一个项目是上一次评估延续过来的,
v)模型范围和上一次评估一样或更小。
如果成熟度等级原来是3级，维持型评估可以是2级或3级;如果原来评估了 SAM维持型评估也要评SAM;如果原来是对 10 个 PA 评价能力等级，维持型评估可以减少 2个 PA 或多个 PA.
3）一次评估可以包含多个视图。
每个组织在评估时，可以选择CMMI 研究所预定义的视图，也可以自己定义视图。自定义视图时，可以自由组合预定义的视图，也可以自己选择实践域组合视图。评估选择的视图是针对组织的商业目标而来的，是针对组织的业务能力而来的。这种自由组合的视图，更有针对性，同时也降低了组织的评估成本，
4）每次评估要提交性能报告
性能报告是一组度量数据，是由被评估组织自定义的、表征组织的过能能力的数据，这组数据并非由 CMMI 研究所指定，不会被公开、不会用于横向比较各个组织的差别、也不会用来评价被评估组织的能力高低，仅仅是提供给Sponsor 的数据。帮助 Sponsor 客观了解过程改进带来的组织性能的变化，并提醒 Sponsor 要通过定量数据关注组织的能力变化。
5）评估组成员要通过认证考试。
在 1.3 版本的评估方法,只要求 ATM成员接受了 Introduction to CMM!的培训和评估方法的培训，在 2.0 版本中要求 ATM 成员在完成两天的模型基础课程后要通过认证考试督促 ATM 成员要真正学习并掌握 CMM 模型，理解了CMMI 模型的要求，能够和被评估组织的实际做法建立一个有效的映射，从而保证评估的价值。而后再参加一天关于 DEV 模型的培训课程.
CMMI3.0是CMMI（Capability Maturity Model Integration，能力成熟度模型集成）的最新版本，由国际信息系统审计协会（ISACA）下属的CMMI研究院于2023年4月6日发布。这一版本在架构上没有大的变化，但引入了一些新的内容和调整，以适应不断变化的组织管理需求。
CMMI3.0包含12个能力域，31个实践域，276个实践，覆盖了开发、服务、供应商管理、人员管理、安全、数据管理、远程交付等多个领域。具体来说，它新增了数据管理（Managing Data）领域。数据管理域包括数据管理和数据质量两个实践域，旨在帮助企业更好地管理和利用数据，提升决策的有效性和沟通的一致性。
此外，CMMI 3.0还对一些现有实践进行了更新和调整。例如，策划（PLAN）域的2.6实践更新了描述，强调通过估算与能力和资源可用性的协调来确保计划的可行性。虚拟交付域则采取一致的系统化方法去识别、评估并解决虚拟/远程/混合交付的需求、限制及灵活性等问题。
CMMI3.0认证评估将于2024年1月正式开始接受，而CMMI 2.0版本的评估将延续至2024年6月30日。企业在选择和实施CMMI 3.0时，应充分考虑其新增内容和调整，以确保能够有效利用这一模型提升组织绩效。
在CMMI 3.0中，新增的三个实践域具体包括以下内容：
-
人员赋能（Workforce Empowerment, WE）：这个实践域属于“人员管理”这个能力域的一部分，旨在通过人员建立整体能力。其目的是指导企业做好员工管理，以提升员工的自主性和创新能力。
-
DevSecOps：这是在特定背景（contextspecific）内容中新增的实践域，旨在将开发（Development）、安全（Security）和运营（Operations）整合在一起，以提高软件开发的安全性和效率。
-
敏捷开发（Agile Development）：在特定背景（contextspecific）内容中，敏捷从Agile with Scrum变成了Agile Development，这表明CMMI 3.0对敏捷开发方法进行了扩展和改进。
全文详细更新情况 [23-24]:
针对语法、格式、通俗语言、可翻译性、清晰度以及与《CMMI 样式指南》和 CMMI 绩效解决方案生态系统的一致性进行了小幅更新。与《CMMI 样式指南》和 CMMI 性能解决方案生态系统保持一致，例如更新所有 V2.0 参考资料，将 CMMI 产品套件更名为 CMMI 绩效解决方案生态系统，更新外部链接以确保准确性。
-实践领域：删除了“供应商来源选择 (SSS)”，并摘录其主要内容，将其纳入"供应商协议管理 (SAM)
-新增能力领域：管理数据
-新增实践领域
数据管理 (DM)
数据质量 (DQ)
人员赋能 (WE)
-原业务领域： 启用虚拟解决方案交付（EVSD）更名为启用虚拟工作（EVW），并根据社区意见进行更新，以反映虚拟交付之外的虚拟工作。
-更新了整个视图/领域信息，以反映以下领域：数据、开发、人员、安全、安保、服务、供应商和虚拟
供应商管理视图更名为供应商
-图形已更新，以反映CMMI 绩效解决方案生态系统的最新更新，包括域的更新、新增能力领域以及实践领域的更新
-更新了“模型查看器说明”，以与模型查看器的当前功能保持一致
-更新了“模型查看器”下拉菜单，除各领域、各能力领域和医疗器械发现鉴定计划 (MDDAP)外。
-更新了特定情境信息
在核心和领域实践领域中添加数据、DevSecOps 和人员的特定情境信息。
敏捷与 Scrum 指导特定情境信息更名为敏捷开发，并更新了所有内容，使其更加清晰。
供应商管理特定上下文信息更名为“供应商”，以便与“供应商”领域保持一致。
CMMI3.0与前一版本（CMMI2.0）在架构和实践上存在多个主要差异：
（1）架构和模块化：CMMI 3.0相对于CMMI 2.0来说，更加模块化和灵活。CMMI 3.0采用了CMMI模型框架，将不同领域的最佳实践组织成了不同的模块。
（2）成熟度模型概念的精简：CMMI 3.0对成熟度模型概念进行了精简，并新增了三个模型领域——数据管理、DevSecOps和人员领域。
（3）实践域的扩展：CMMI 3.0新增了31个实践域，并且特定场景信息扩展到包含数据、DevSecOps和人员领域。
（4）能力域的分类：CMMI 2.0将能力域归为四类，即doing、managing、enabling和improving。而CMMI 3.0则进一步细分了这些能力域，使其更加具体和模块化。
（5）视图的概念：CMMI 2.0引入了“视图”的概念，即一组实践域及实践组的集合，由最终用户选择或预定义。
（6）商业目标的强调：在CMMI 2.0中，商业目标对过程改进的驱动作用被进一步强调，无论哪个等级都强调了围绕商业目标进行改进。
（7）性能的重视：CMMI 2.0在所有成熟度等级中都增加了新的性能实践，以强调和关注组织性能的提升，以适应现代商业环境对性能的重视。
