Loading AI tools
来自维基百科，自由的百科全书
能力成熟度模型集成（英語：Capability Maturity Model Integration，简称CMMI）是一种改进过程的方法，其目的是协助提升组织的绩效。CMMI可用来引导一整个项目、一整个部门乃至一个完整的组织的过程改进。在软件工程和组织发展的领域中，CMMI能够向组织提供用于有效的过程改进的基本元素。CMMI由卡内基梅隆大学在美国专利和商标局（英文：U.S. Patent and Trademark Office）注册。
 | 此條目需要精通或熟悉相关主题的编者参与及协助编辑。 (2015年12月14日) |
按照软件工程研究所（简写：SEI，2008）说法，CMMI能够协助“集成传统独立的组织功能，设置过程改进目标和优先级，为质量过程提供指引，并为评价当前过程提供一个参考点”。[2]
CMMI目前致力于三个感兴趣的区域：
CMMI由来自行业、政府和位于卡内基·梅隆大学的软件工程研究所的一组专家开发。CMMI模型为开发或改进用于达成一个组织的商业目标的过程提供指导。一个CMMI模型也可能被用作用于评价组织的过程成熟度的框架。[1]
CMMI原先面向软件工程，但是近年已经被高度一般化，以包含其他兴趣范围，例如硬件产品的开发、所有种类的业务的交付，以及产品和服务的采购。“软件”这个词现在不出现在CMMI的定义中了。这个改进概念的一般化，使得CMMI极度抽象。它现在不像它的前身——软件能力成熟度模型（英文：Software CMM，参见下文）——一样为软件工程所特有了。
CMMI是由CMMI项目开发的，它的目的是通过将许多不同的模型集成到一个框架中，来改进成熟度模型的可用性。该项目由行业、政府和卡内基·梅隆大学软件工程研究所（软工所）的成员组成。主要的发起者包括美国国防部长办公室（简称OSD或“防长办”）和美国国防产业协会——也称“（美国）国家防务产业协会”。
CMMI是能力成熟度模型（Capability Maturity Model，简称CMM）的接替者。CMM自1987年开始开发，一直持续到1997年。在2002年，CMMI1.1版发布，随后1.2版本在2006年8月发布，而1.3版本则于2010年11月发布。 於2018年三月，CMMI 2.0正式問世，自此CMMI不再是免費使用；最便宜的收費選項為一週期限的線上使用版，收費為150美金。
CMMI存在两种表现方式：“持续的”（continuous）和“分阶段的”（staged）。[1]“持续的”的表现方式被设计为允许用户聚焦特定的、被认为对于企业眼下的商业目标而言非常重要的过程，或那些企业对其指派了一个高程度的风险的过程。“分阶段的”的表现方法同时提供了从“软件CMM”到CMMI的轻松迁移。[1]
根据所使用的CMMI系列集（采购、服务和开发），它所包含的过程区域将会改变。过程区域是那些将被组织的过程所覆盖的区域。下表列出了在所有CMMI系列集中出现的过程区域。这十六个过程的集合被称为CMMI核心过程区域。
| 缩写 | 区域 | 成熟度模型 | |
| CAR | 因果分析和解决（Causal Analysis and Resolution） | 支持（Support） | 5 |
| CM | 配置管理（Configuration Management） | 支持（Support） | 2 |
| DAR | 决策分析和解决（Decision Analysis and Resolution） | 支持（Support） | 3 |
| IPM | 集成的项目管理（Integrated Project Management） | 项目管理（Project Management） | 3 |
| MA | 度量和分析（Measurement and Analysis） | 支持（Support） | 2 |
| OPD | 组织上的过程定义（Organizational Process Definition） | 过程管理（Process Management） | 3 |
| OPF | 组织上的过程聚焦（Organizational Process Focus） | 过程管理（Process Management） | 3 |
| OPM | 组织上的绩效管理（Organizational Performance Management） | 过程管理（Process Management） | 5 |
| OPP | 组织上的过程绩效（Organizational Process Performance） | 过程管理（Process Management） | 4 |
| OT | 组织上的培训（Organizational Training） | 过程管理（Process Management） | 3 |
| PMC | 项目监控（Project Monitoring and Control） | 项目管理（Project Management） | 2 |
| PP | 项目计划（Project Planning） | 项目管理（Project Management） | 2 |
| PPQA | 过程和产品质量保证（Process and Product Quality Assurance） | 支持（Support） | 2 |
| QPM | 量化的项目管理（Quantitative Project Management） | 项目管理（Project Management） | 4 |
| REQM | 需求管理（Requirements Management） | 项目管理（Project Management） | 2 |
| RSKM | 风险管理（Risk Management） | 项目管理（Project Management） | 3 |
CMMI实施时有连续式和阶段式两种改进实施方式。在阶段式中有五个等级。由于第一级“初始级”是组织的初始状态（可以认为每一个没有通过CMMI评估的公司或组织都处于“初始级”），故成熟度级别评定从2到5级被授予。下面的过程区域及其成熟度级别是为CMMI开发方面模型而列出的：
成熟度级别2 － 已管理
成熟度级别3 － 已定义
成熟度级别4 － 已量化地管理
成熟度级别5 － 优化中
下面的过程区域及其成熟度级别是为CMMI服务方面模型列出的：
成熟度级别2 － 已管理
成熟度级别3 － 已定义
成熟度级别4 － 已量化地管理
成熟度级别5 － 优化中
下面的过程区域及其成熟度级别为CMMI采购方面模型列出：
成熟度级别2 － 已管理
成熟度级别3 － 已定义
成熟度级别4 － 已量化地管理
成熟度级别5 － 优化中
CMMI最佳实践（best practices）被发布在称为模型的文档中，这些文档中的每一个都专注于一个不同的兴趣区域。CMMI的当前发行版本——1.3版——提供用于3个兴趣范围的模型：开发、采购和服务。
不管组织选择哪种模型，CMMI最佳实践应当被组织根据它的商业目标来适配。
一个组织不能在CMMI中被认证（certified）；替代地，组织是被评价（appraised）。依赖评价的类型，这个组织可被授予一个成熟度等级评定（英文：maturity level rating）1～5，或能力等级达成概要（英文：capability level achievement profile）。
许多组织通过进行一个评价，在度量他们的过程期间发现价值。评价典型地因下面的一个或多个原因而进行：
使用一个CMMI模型的组织的评价[6]必须遵守定义在“CMMI评价需求”（英文：Appraisal Requirements for CMMI，简称ARC）文档中的需求。有三类评价——甲、乙和丙，它们聚焦于识别改进机会，并将组织的过程与CMMI最佳实践相比较。其中，甲类评价是最正式的，并且是唯一一个可以在一个等级评定中得到结果的。评价团队使用一个CMMI模型和CMMI评价需求相符的评价方法来指导他们对组织的评估以及他们的结论报告。评价结果随后可以被用于为组织（例如，通过一个过程组）来计划改进。
“用于过程改进的标准CMMI评价方法”（简称SCAMPI）是一个评价方法，它满足所有的CMMI评价需求[7]。一个SCAMPI评价的结果会被发布在软工所的CMMI网站（如果被评价的组织同意的话）[8]。SCAMPI还支持ISO/IEC 15504的管理——也称SPICE（软件过程改进和能力测定），评价等。
组织经常采用的来达到CMMI模型遵从性的传统的方法包括工程过程组（Engineering Process Group，简称EPG）和过程行动团队（PATs）的建立[9]。这个方法要求：工程过程组和过程行动团队的成员经过在CMMI中的培训、一个非正式的评价（SCAMPI－丙）已被执行、以及过程区域被为改进而排列优先级。更多新的方法包括商业可用的开发、遵从CMMI的过程，可以显著地减少达到遵从的时间。软工所已为组织通过更早的软件CMM、并主要使用传统方法，维护对于“提升时间”的统计[10]。这些统计表明，自1987年以来，从1级移动到2级的时间中值是23个月，而从2级到3级则外加20个月。这些统计尚未为CMMI而更新。
软件工程研究所（软工所）的“团队软件过程”（Team Software Process）方法论和对CMMI模型的使用可以被用于提升成熟度级别。
軟體工程研究所於2006年指出，60个组织度量了在开销、安排、生产率、质量和客户满意度范畴内的绩效的提升[11]。绩效的增长中值徘徊在14%（客户满意度）和62%之间。然而，CMMI模型大多数处理什么过程应当被实施，而对如何它们才能被实施却不多。这些结果不保证在任何组织中使用CMMI都将会提高绩效。一个拥有较少资源的小公司不太会从CMMI中得到好处；这个观点由过程成熟度概要[12]支撑。对于小型组织（小于25名雇员），70.5%被评估在2级：已管理，而52.8%的拥有1001～2000名雇员的组织被评价为最高级（5：优化中）。
有趣的是，特纳和耆那（2002）争论说，尽管很明显在CMMI和敏捷方法之间有着巨大的不同，但两个方法拥有很多共同点。他们相信没有一条路是开发软件的“正确的”路，但是项目中存在一些一者或二者更适合的阶段。他们建议应该将这些方法的不同碎片结合到一个新的混合的方法。萨瑟兰等人（2007）断言“混战争球”和CMMI比任何单独一方能带来更多的适应性和可预测性。戴维·J·安德森（2005）给出了对于如何以敏捷方式解释CMMI的提示。其他关于使用CMMI和敏捷开发的观点可以在软工所网站[13]上找到。
项目管理技术“挣值管理”（英文：earned value management，简称EVM）与CMMI的结合已经被描述[14]。为了与CMMI的近似使用达成一致，“极限编程”（英文：Extreme Programming，简称XP）——一个软件工程方法——被按CMM/CMMI来评估（Nawrocki等人，2002）。例如，依靠口头交流的极限编程需求管理方法，被评估为不遵从CMMI。
CMMI可以被用两种不同的方法来评价：分阶段的和持续的。分阶段的方法产生五个成熟度级别之一的评价结果。持续的方法产生六个能力级别之一。这些方法的不同点仅会在评价时被感知，最佳实践是平等的并且导致平等的过程改进结果。
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
