# wiki-Capability Maturity Model Integration
Date: 2019-10-15


这是 [CMMI的wiki](https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration)

能力成熟度模型集成（CMMI）是一个过程级改进培训和评估程序。 它是由ISACA的子公司CMMI Institute管理的，由卡内基梅隆大学（CMU）开发。 许多美国国防部（DoD）和美国政府合同都要求这样做，尤其是在软件开发方面。 CMU声称CMMI可用于指导整个项目，部门或整个组织的流程改进。 CMMI为流程定义了以下成熟度级别：初始，已管理，已定义，已量化管理和优化中。 2.0版于2018年发布（1.3版于2010年发布，是此Wiki文章中其余信息的参考模型）。 CMMI由CMU在美国专利商标局注册。

### 概述

![avatar](https://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Characteristics_of_Capability_Maturity_Model.svg/1024px-Characteristics_of_Capability_Maturity_Model.svg.png)

> _成熟度水平的特征 picture from wiki_

最初，CMMI涉及三个感兴趣的领域：

- 产品和服务开发-CMMI for Development（CMMI-DEV）;
- 服务的建立，管理，—CMMI for Services (CMMI-SVC);
- 产品和服务获取— CMMI for Acquisition（CMMI-ACQ）。

在2.0版中，这三个区域（以前每个区域都有一个单独的模型）被合并为一个模型。

CMMI由行业，政府和CMU的软件工程学院（SEI）组成的小组开发。 CMMI模型为开发或改进满足组织业务目标的流程提供了指导。 CMMI模型也可以用作评估组织流程成熟度的框架。 到2013年1月，整个CMMI产品套件已从SEI转移到卡耐基梅隆大学新成立的组织CMMI研究所。

### 历史

CMMI由CMMI项目开发，旨在通过将许多不同的模型集成到一个框架中来提高成熟度模型的可用性。该项目由行业，政府和卡内基梅隆软件工程学院（SEI）的成员组成。主要赞助商包括国防部长办公室（OSD）和国防工业协会。

CMMI是功能成熟度模型（CMM）或软件CMM的后继产品。 CMM是从1987年到1997年开发的。2002年发布了1.1版，随后在2006年8月发布了1.2版，并在2010年11月发布了1.3版。CMMIV1.3的一些重大更改是对敏捷软件开发的支持， 对高成熟度实践的改进和实施流程的改进。

根据软件工程学院（SEI，2008）的说法，CMMI帮助 " 整合传统上独立的组织功能，设置流程改进目标和优先级，为质量流程提供指导，并为评估当前流程提供参考点。"

2016年3月，CMMI研究所被ISACA收购。

### CMMI主题

#### 表示

在1.3版中，CMMI有两种表示形式：连续表示和分段表示。 连续表示的目的是使用户可以专注于对组织的近期业务目标重要的特定过程，或组织为之分配高度风险的特定过程。 分阶段的表示旨在提供标准的改进顺序，并且可以用作比较不同项目和组织的成熟度的基础。 分阶段的表示还提供了从SW-CMM到CMMI的轻松迁移。

在2.0版中，以上表示分离已被取消，现在只有一个内聚模型。

#### 模型框架（v1.3）

取决于所使用的关注领域（收购，服务，开发），其包含的过程领域将有所不同。 流程区域是组织的流程将覆盖的区域。下表列出了版本1.3中所有感兴趣的CMMI领域共有的17个CMMI核心过程领域。

| 缩写 | 名称 | 领域 | 成熟度 |
| --- | --- | --- | --- |
| OT | Organizational Training | Process Management | 3 |
| OPP | Organizational Process Performance | Process Management | 4 |
| OPM | Organizational Performance Management | Process Management | 5 |
| OPF | Organizational Process Focus | Process Management | 3 |
| OPD | Organizational Process Definition | Process Management | 3 |
| RSKM | Risk Management | Project Management | 3 |
| REQM | Requirements Management | Project Management | 2 |
| QPM | Quantitative Project Management | Project Management | 4 |
| PP | Project Planning | Project Management | 2 |
| PMC | Project Monitoring and Control | Project Management | 2 |
| IPM | Integrated Project Management | Project Management | 3 |
| SAM | Supplier Agreement Management | Support | 2 |
| PPQA | Process and Product Quality Assurance | Support | 2 |
| MA | Measurement and Analysis | Support | 2 |
| DAR | Decision Analysis and Resolution | Support | 3 |
| CM | Configuration Management | Support | 2 |
| CAR | Causal Analysis and Resolution | Support | 5 |

#### 服务的成熟度级别

针对服务模型CMMI，列出了以下过程域及其成熟度级别：

##### 成熟度等级2-已管理

- CM - 配置管理
- MA - 测量和分析
- PPQA - 过程和质量保证
- REQM - 需求管理
- SAM - 供应商协议管理
- SD - 服务交付
- WMC - 工作监控
- WP - 工作计划

##### 成熟度级别3-已定义

- CAM - 容量和可用性管理
- DAR - 决策分析与解决
- IRP - 事件解决与预防
- IWM - 综合工作管理
- OPD - 组织过程定义
- OPF - 组织过程重点
- OT - 组织培训
- RSKM - 风险管理
- SCON - 服务连续性
- SSD - 服务系统开发
- SST - 服务系统过渡
- STSM - 战略服务管理

##### 成熟度级别4-已量化管理

- OPP-组织过程绩效
- QWM-定量工作管理

##### 成熟度级别5-优化中

- CAR-因果分析和解决。
- OPM-组织绩效管理

#### 模型V1.3

CMMI最佳实践发布在称为模型的文档中，每个模型都针对不同的关注领域。1.3版为三个感兴趣的领域提供了模型：开发，采购和服务。

CMMI for Development（CMMI-DEV）v1.3于2010年11月发布。它解决了产品和服务开发流程。 CMMI for Acquisition（CMMI-ACQ）v1.3于2010年11月发布。该版本解决了政府和行业中的供应链管理，收购和外包流程。 CMMI for Services（CMMI-SVC）v1.3于2010年11月发布。它解决了在组织内部以及向外部客户提供服务的指南。

#### 模型V2.0

在2.0版DEV中，ACQ和SVC合并为一个模型，其中每个过程区域都可能对这三个方面中的一个或多个有特定的引用。为了与行业保持同步，该模型还明确引用了某些过程领域中的敏捷方面。

#### 评价

组织不是通过CMMI认证；而是对组织进行评估。根据评估的类型，可以为组织授予成熟度等级等级（1-5）或能力等级成就概况。

许多组织通过进行评估来衡量其进度，从而发现价值。通常出于以下一个或多个原因进行评估：

1. 确定组织的流程与CMMI最佳做法的比较程度，并确定可以改进的地方
2. 告知外部客户和供应商组织流程与CMMI最佳做法相比的情况
3. 满足一个或多个客户的合同要求

使用CMMI模型的组织的评估必须符合CMMI（ARC）评估要求中定义的要求。评估分为A，B和C三类，重点是确定改进机会，并将组织的流程与CMMI最佳做法进行比较。在这些评估中，A级评估是最正式的评估，也是唯一可以达到等级评估的评估。评估团队使用CMMI模型和符合ARC的评估方法来指导他们对组织的评估和结论报告。然后可以使用评估结果（例如，由过程组）来计划组织的改进。

用于过程改进的标准CMMI评估方法（SCAMPI）是满足所有ARC要求的评估方法。 SCAMPI评估结果可以在SEI的CMMI网站上发布（如果被评估组织批准）：已发布的SCAMPI评估结果。 SCAMPI还支持ISO/IEC 15504的行为，也称为SPICE（软件过程改进和能力确定），评估等。

这种方法鼓励在CMMI中对EPG和PATS的成员进行培训，进行非正式（SCAMPIC）评估，并优先考虑过程领域以进行改进。涉及部署可购得的，符合CMMI要求的流程的更现代的方法，可以大大减少实现法规遵从的时间。 SEI维护了采用早期软件CMM和CMMI的组织的“上升时间”的统计信息。这些统计数据表明，自1987年以来，从1级迁移到2级的平均时间为23个月，从2级迁移到3级的平均时间又是20个月。自CMMI发布以来，从级别1迁移到级别2的中值时间为5个月，而从级别1迁移到级别2的中值时间又是21个月。这些统计信息每六个月更新一次，并在到期日摘要中发布。

软件工程学院（SEI）团队的软件处理方法和CMMI模型的使用可用于提高成熟度。一种名为加速改进方法（AIM）的新产品结合了CMMI和TSP的使用。

#### 安全

为了解决用户安全问题，提供了两个非官方的安全指南。 考虑到CMMI for Services中安全内容的情况，只有一个过程域，即安全管理。1.3版的CMMI for Development的设计安全性具有以下过程区域：

- OPSD - 安全开发的组织准备
- SMP - 项目中的安全管理
- SRTS - 安全要求和技术解决方案
- SVV - 安全验证和确认

尽管它们不影响成熟度或能力水平，但是可以在评估结果中报告这些过程区域

#### 应用领域

SEI公布，有60个组织在成本，进度，生产力，质量和客户满意度类别中衡量了绩效的提高。绩效的中位数提高介于14％（客户满意度）和62％（生产力）之间。但是，CMMI模型主要处理应实施哪些流程，而与如何实施无关紧要。这些结果不能保证应用CMMI可以提高每个组织的绩效。一个资源很少的小公司可能不太可能从CMMI中受益；流程成熟度配置文件支持该视图（第10页）。在小型组织（少于25名员工）中，有70.5％的评估为第2级：已管理，而在拥有1,001–2,000名员工的组织中，有52.8％的评估为最高级别（5：优化中）。

Turner＆Jain（2002）认为，尽管很明显CMMI和敏捷软件开发之间存在很大差异，但这两种方法有很多共同点。他们认为，这两种方法都不是开发软件的“正确”方法，但是，在项目的某些阶段中，两种方法之一更适合。他们建议应该将方法的不同片段组合成一种新的混合方法。 Sutherland等。 （2007）断言，Scrum和CMMI的组合比任何一个单独组合都具有更大的适应性和可预测性。 David J. Anderson（2005）给出了如何以敏捷的方式解释CMMI的提示。

CMMI路线图是一种以目标为导向的方法，用于从CMMI-DEV模型中选择和部署相关的过程域，可以为有效采用CMMI提供指导和重点。有几个用于连续表示的CMMI路线图，每个路线图都有一组特定的改进目标。例如CMMI项目路线图， CMMI产品和产品集成路线图以及CMMI流程和度量路线图。这些路线图结合了分阶段和连续表示的优势。

已经描述了项目管理技术挣值管理（EVM）与CMMI的结合（Solomon，2002）。作为对CMMI的类似使用的总结，已经使用CMM/CMMI评估了一种软件工程方法极限编程（XP）（Nawrocki等，2002）。例如，依赖于口头交流的XP需求管理方法被评估为不符合CMMI。

CMMI可以使用两种不同的方法进行评估：分阶段和连续。分阶段方法得出的评估结果是五个成熟度级别之一。连续方法产生四个能力级别之一。这些方法的差异只有在评估中才能感受到。最佳做法是等效的，并且会导致等效的过程改进结果。