【能力成熟度模型集成】
各成熟度级别的特征。
能力成熟度模型集成（Capability Maturity Model Integration，简称CMMI）是一种改进过程的方法，其目的是协助提升组织的绩效。CMMI可用来引导一整个项目、一整个部门乃至一个完整的组织的过程改进。在软件工程和组织发展的领域中，CMMI能够向组织提供用于有效的过程改进的基本元素。CMMI由卡内基梅隆大学在美国专利和商标局（英文：U.S. Patent and Trademark Office）注册。
按照Software Engineering Institute（简写：SEI，2008）说法，CMMI能够协助“集成传统独立的组织功能，设置过程改进目标和优先级，为质量过程提供指引，并为评价当前过程提供一个参考点”。
==概述==
CMMI目前致力于三个感兴趣的区域：
#产品和服务开发——CMMI开发方面（英文：CMMI for Development，简称 CMMI-DEV），
#服务建立、管理和交付——CMMI服务方面（英文：CMMI for Service，简称 CMMI-SVC），以及
#产品和服务采购——CMMI采购方面（英文：CMMI for Acquisition，简称 CMMI-ACQ）。
CMMI由来自行业、政府和位于卡内基·梅隆大学的软件工程研究所的一组专家开发。CMMI模型为开发或改进用于达成一个组织的商业目标的过程提供指导。一个CMMI模型也可能被用作用于评价组织的过程成熟度的框架。
CMMI原先面向软件工程，但是近年已经被高度一般化，以包含其他兴趣范围，例如硬件产品的开发、所有种类的业务的交付，以及产品和服务的采购。“软件”这个词现在不出现在CMMI的定义中了。这个改进概念的一般化，使得CMMI极度抽象。它现在不像它的前身——软件能力成熟度模型（英文：Software CMM，参见下文）——一样为软件工程所特有了。
==历史==
CMMI是由CMMI项目开发的，它的目的是通过将许多不同的模型集成到一个框架中，来改进成熟度模型的可用性。该项目由行业、政府和卡内基·梅隆大学软件工程研究所（软工所）的成员组成。主要的发起者包括美国Office of the Secretary of Defense（简称OSD或“防长办”）和美国National Defense Industrial Association——也称“（美国）国家防务产业协会”。
CMMI是能力成熟度模型（Capability Maturity Model，简称CMM）的接替者。CMM自1987年开始开发，一直持续到1997年。在2002年，CMMI1.1版发布，随后1.2版本在2006年8月发布，而1.3版本则于2010年11月发布。
于2018年三月，“希迈2.0”正式问世，自此希迈不再是免费使用；最便宜的收费选项为一周期限的线上使用版，收费为150美金。
==CMMI话题==
===CMMI表现方式===
CMMI存在两种表现方式：“持续的”（continuous）和“分阶段的”（staged）。“持续的”的表现方式被设计为允许用户聚焦特定的、被认为对于企业眼下的商业目标而言非常重要的过程，或那些企业对其指派了一个高程度的风险的过程。“分阶段的”的表现方法同时提供了从“软件希姆”到CMMI的轻松迁移。
===CMMI模型框架===
根据所使用的CMMI系列集（采购、服务和开发），它所包含的过程区域将会改变。过程区域是那些将被组织的过程所覆盖的区域。下表列出了在所有CMMI系列集中出现的过程区域。这十六个过程的集合被称为CMMI核心过程区域。
===在“CMMI开发方面”中的成熟度级别===
CMMI实施时有连续式和阶段式两种改进实施方式。在阶段式中有五个等级。由于第一级“初始级”是组织的初始状态（可以认为每一个没有通过CMMI评估的公司或组织都处于“初始级”），故成熟度级别评定从2到5级被授予。下面的过程区域及其成熟度级别是为CMMI开发方面模型而列出的：
成熟度级别2 － 已管理
* CM - 配置管理（Configuration Management）
* MA - 度量和分析（Measurement and Analysis）
* PMC - 项目监控（Project Monitoring and Control）
* PP - 项目计划（Project Planning）
* PPQA - 过程和产品质量保证（Process and Product Quality Assurance）
* REQM - 需求管理（Requirements Management）
* SAM - 供应商协议管理（Supplier Agreement Management）
成熟度级别3 － 已定义
* DAR - 决策分析和决议（Decision Analysis and Resolution）
* IPM - 集成的项目管理（Integrated Project Management）
* OPD - 组织级过程定义（Organizational Process Definition）
* OPF - 组织级过程聚焦（Organizational Process Focus）
* OT - 组织级培训（Organizational Training）
* PI - 产品集成（Product Integration）
* RD - 需求开发（Requirements Development）
* RSKM - 风险管理（Risk Management）
* TS - 技术解决方案（Technical Solution）
* VAL - 验证（Validation）
* VER - 核查（Verification）
成熟度级别4 － 已量化地管理
* OPP - 组织级过程绩效（Organizational Process Performance）
* QPM - 量化的项目管理（Quantitative Project Management）
成熟度级别5 － 优化中
* CAR - 因果分析和决议（Causal Analysis and Resolution）
* OPM - 组织级绩效管理（Organizational Performance Management）
===CMMI服务方面中成熟度级别===
下面的过程区域及其成熟度级别是为CMMI服务方面模型列出的：
成熟度级别2 － 已管理
* CM - 配置管理（Configuration Management）
* MA - 度量和分析（Measurement and Analysis）
* PPQA - 过程和项目质量保证（Process and Product Quality Assurance）
* REQM - 需求管理（Requirements Management）
* SAM - 供应商协议管理（Supplier Agreement Management）
* SD - 服务交付（Service Delivery）
* WMC - 工作监控（Work Monitoring and Control）
* WP - 工作计划（Work Planning）
成熟度级别3 － 已定义
* CAM - 容量和可用性管理（Capacity and Availability Management）
* DAR - 决策分析和决议（Decision Analysis and Resolution）
* IRP - 突发事件解决和预防（Incident Resolution and Prevention）
* IWM - 集成的工作管理（Integrated Work Management）
* OPD - 组织级过程定义（Organizational Process Definition）
* OPF - 组织级过程聚焦（Organizational Process Focus）
* OT - 组织上的培训（Organizational Training）
* RSKM - 风险管理（Risk Management）
* SCON - 服务持续性（Service Continuity）
* SSD - 服务系统开发（Service System Development）
* SST - 服务系统转变（Service System Transition）
* STSM - 战略服务管理（Strategic Service Management）
成熟度级别4 － 已量化地管理
* OPP - 组织级过程绩效（Organizational Process Performance）
* QWM - 量化的工作管理（Quantitative Work Management）
成熟度级别5 － 优化中
* CAR - 因果分析和决议（Causal Analysis and Resolution）
* OPM - 组织级绩效管理（Organizational Performance Management）
===CMMI采购方面中的成熟度模型===
下面的过程区域及其成熟度级别为CMMI采购方面模型列出：
成熟度级别2 － 已管理
* AM - 协议管理（Agreement Management）
* ARD - 采购需求开发（Acquisition Requirements Development）
* CM - 配置管理（Configuration Management）
* MA - 度量和分析（Measurement and Analysis）
* PMC - 项目监控（Project Monitoring and Control）
* PP - 项目计划（Project Planning）
* PPQA - 过程和产品质量保证（Process and Product Quality Assurance）
* REQM - 需求管理（Requirements Management）
* SSAD - 诱导和供应商协议开发（Solicitation and Supplier Agreement Development）
成熟度级别3 － 已定义
* ATM - 采购技术管理（Acquisition Technical Management）
* AVAL - 采购验证（Acquisition Validation）
* AVER - 采购核查（Acquisition Verification)
* DAR - 决策分析和决议（Decision Analysis and Resolution）
* IPM - 集成的项目管理（Integrated Project Management）
* OPD - 组织级过程定义（Organizational Process Definition）
* OPF - 组织级过程聚焦（Organizational Process Focus）
* OT - 组织上的培训（Organizational Training）
* RSKM - 风险管理（Risk Management）
成熟度级别4 － 已量化地管理
* OPP - 组织级过程绩效（Organizational Process Performance）
* QPM - 量化的项目管理（Quantitative Project Management）
成熟度级别5 － 优化中
* CAR - 因果分析和决议（Causal Analysis and Resolution）
* OPM - 组织级绩效管理（Organizational Performance Management）
===CMMI模型===
CMMI最佳实践（best practices）被发布在称为模型的文档中，这些文档中的每一个都专注于一个不同的兴趣区域。CMMI的当前发行版本——1.3版——提供用于3个兴趣范围的模型：开发、采购和服务。
* CMMI开发方面，1.3版于2010年11月发行。它专注于产品和服务开发过程。
* CMMI采购方面，1.3版于2010年11月发行。它专注于政府和行业中的供应链管理、采购和外包过程。
* CMMI服务方面，1.3版于2010年11月发行。它专注于为在一个组织中的、向外部客户的交付服务的指导。
不管组织选择哪种模型，CMMI最佳实践应当被组织根据它的商业目标来适配。
===评价===
一个组织不能在CMMI中被认证（certified）；替代地，组织是被评价（appraised）。依赖评价的类型，这个组织可被授予一个成熟度等级评定（英文：maturity level rating）1～5，或能力等级达成概要（英文：capability level achievement profile）。
许多组织通过进行一个评价，在度量他们的过程期间发现价值。评价典型地因下面的一个或多个原因而进行：
# 确定相较于CMMI最佳实践，组织的过程好到什么程度，并识别那些可以做改进的区域。
# 告知外部客户和供应商，相较于CMMI最佳实践，组织的过程好到什么程度。
# 满足一个或多个客户的合同需求。
使用一个CMMI模型的组织的评价必须遵守定义在“CMMI评价需求”（英文：Appraisal Requirements for CMMI，简称ARC）文档中的需求。有三类评价——甲、乙和丙，它们聚焦于识别改进机会，并将组织的过程与CMMI最佳实践相比较。其中，甲类评价是最正式的，并且是唯一一个可以在一个等级评定中得到结果的。评价团队使用一个CMMI模型和CMMI评价需求相符的评价方法来指导他们对组织的评估以及他们的结论报告。评价结果随后可以被用于为组织（例如，通过一个过程组）来计划改进。
“Standard CMMI Appraisal Method for Process Improvement”（简称SCAMPI）是一个评价方法，它满足所有的CMMI评价需求。一个SCAMPI评价的结果会被发布在软工所的CMMI网站（如果被评价的组织同意的话）。SCAMPI还支持ISO/IEC 15504的管理——也称SPICE（软件过程改进和能力测定），评价等。
===达到CMMI符合性===
组织经常采用的来达到CMMI模型遵从性的传统的方法包括工程过程组（Engineering Process Group，简称EPG）和过程行动团队（PATs）的建立。这个方法要求：工程过程组和过程行动团队的成员经过在CMMI中的培训、一个非正式的评价（SCAMPI－丙）已被执行、以及过程区域被为改进而排列优先级。更多新的方法包括商业可用的开发、遵从CMMI的过程，可以显著地减少达到遵从的时间。软工所已为组织通过更早的软件希姆、并主要使用传统方法，维护对于“提升时间”的统计。这些统计表明，自1987年以来，从1级移动到2级的时间中值是23个月，而从2级到3级则外加20个月。这些统计尚未为CMMI而更新。
软件工程研究所（软工所）的“团队软件过程”（Team Software Process）方法论和对CMMI模型的使用可以被用于提升成熟度级别。
==应用==
于2006年指出，60个组织度量了在开销、安排、生产率、质量和客户满意度范畴内的绩效的提升。绩效的增长中值徘徊在14%（客户满意度）和62%之间。然而，CMMI模型大多数处理什么过程应当被实施，而对如何它们才能被实施却不多。这些结果不保证在任何组织中使用CMMI都将会提高绩效。一个拥有较少资源的小公司不太会从CMMI中得到好处；这个观点由过程成熟度概要支撑。对于小型组织（小于25名雇员），70.5%被评估在2级：已管理，而52.8%的拥有1001～2000名雇员的组织被评价为最高级（5：优化中）。
有趣的是，特纳和耆那（2002）争论说，尽管很明显在CMMI和敏捷方法之间有着巨大的不同，但两个方法拥有很多共同点。他们相信没有一条路是开发软件的“正确的”路，但是项目中存在一些一者或二者更适合的阶段。他们建议应该将这些方法的不同碎片结合到一个新的混合的方法。萨瑟兰等人（2007）断言“混战争球”和CMMI比任何单独一方能带来更多的适应性和可预测性。戴维·J·安德森（2005）给出了对于如何以敏捷方式解释CMMI的提示。其他关于使用CMMI和敏捷开发的观点可以在软工所网站上找到。
项目管理技术“挣值管理”（英文：earned value management，简称EVM）与CMMI的结合已经被描述。为了与CMMI的近似使用达成一致，“极限编程”（英文：Extreme Programming，简称XP）——一个软件工程方法——被按希姆/CMMI来评估（Nawrocki等人，2002）。例如，依靠口头交流的极限编程需求管理方法，被评估为不遵从CMMI。
CMMI可以被用两种不同的方法来评价：分阶段的和持续的。分阶段的方法产生五个成熟度级别之一的评价结果。持续的方法产生六个能力级别之一。这些方法的不同点仅会在评价时被感知，最佳实践是平等的并且导致平等的过程改进结果。
==引用==
==官方来源==
软工所报告
软工所网页
*  SCAMPI评价结果. 已发布的SCAMPI评价结果的完整软工所列表。