能力成熟度模型整合

各成熟度級別的特徵。

能力成熟度模型整合（Capability Maturity Model Integration，簡稱 CMMI）是一種改進過程的方法，其目的是協助提升組織的績效。CMMI 可用來引導一整個專案、一整個部門乃至一個完整的組織的過程改進。在軟體工程和組織發展的領域中，CMMI 能夠向組織提供用於有效的過程改進的基本元素。CMMI 由卡內基梅隆大學在美國專利和商標局（英文：U.S. Patent and Trademark Office）註冊。

按照（簡寫：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 專案開發的，它的目的是透過將許多不同的模型整合到一個框架中，來改進成熟度模型的可用性。該專案由行業、政府和卡內基・梅隆大學軟體工程研究所（軟工所）的成員組成。主要的發起者包括美國（簡稱 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 話題

3.1 CMMI 表現方式

CMMI 存在兩種表現方式：“持續的”（continuous）和 “分階段的”（staged）。“持續的” 的表現方式被設計為允許使用者聚焦特定的、被認為對於企業眼下的商業目標而言非常重要的過程，或那些企業對其指派了一個高程度的風險的過程。“分階段的” 的表現方法同時提供了從 “軟體 CMM” 到 CMMI 的輕鬆遷移。

3.2 CMMI 模型框架

根據所使用的 CMMI 系列集（採購、服務和開發），它所包含的過程區域將會改變。過程區域是那些將被組織的過程所覆蓋的區域。下表列出了在所有 CMMI 系列集中出現的過程區域。這十六個過程的集合被稱為 CMMI 核心過程區域。

3.3 在 “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）

3.4 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）

3.5 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）

3.6 CMMI 模型

CMMI 最佳實踐（best practices）被髮布在稱為模型的文件中，這些文件中的每一個都專注於一個不同的興趣區域。CMMI 的當前發行版本 ——1.3 版 —— 提供用於 3 個興趣範圍的模型：開發、採購和服務。

CMMI 開發方面，1.3 版於 2010 年 11 月發行。它專注於產品和服務開發過程。
CMMI 採購方面，1.3 版於 2010 年 11 月發行。它專注於政府和行業中的供應鏈管理、採購和外包過程。
CMMI 服務方面，1.3 版於 2010 年 11 月發行。它專注於為在一個組織中的、向外部客戶的交付服務的指導。

不管組織選擇哪種模型，CMMI 最佳實踐應當被組織根據它的商業目標來適配。

3.7 評價

一個組織不能在 CMMI 中被認證（certified）；替代地，組織是被評價（appraised）。依賴評價的型別，這個組織可被授予一個成熟度等級評定（英文：maturity level rating）1～5，或能力等級達成概要（英文：capability level achievement profile）。

許多組織透過進行一個評價，在度量他們的過程期間發現價值。評價典型地因下面的一個或多個原因而進行：

確定相較於 CMMI 最佳實踐，組織的過程好到什麼程度，並識別那些可以做改進的區域。
告知外部客戶和供應商，相較於 CMMI 最佳實踐，組織的過程好到什麼程度。
滿足一個或多個客戶的合同需求。

使用一個 CMMI 模型的組織的評價必須遵守定義在 “CMMI 評價需求”（英文：Appraisal Requirements for CMMI，簡稱 ARC）文件中的需求。有三類評價 —— 甲、乙和丙，它們聚焦於識別改進機會，並將組織的過程與 CMMI 最佳實踐相比較。其中，甲類評價是最正式的，並且是唯一一個可以在一個等級評定中得到結果的。評價團隊使用一個 CMMI 模型和 CMMI 評價需求相符的評價方法來指導他們對組織的評估以及他們的結論報告。評價結果隨後可以被用於為組織（例如，透過一個過程組）來計劃改進。

“”（簡稱 SCAMPI）是一個評價方法，它滿足所有的 CMMI 評價需求。一個 SCAMPI 評價的結果會被髮布在軟工所的 CMMI 網站（如果被評價的組織同意的話）。SCAMPI 還支援 ISO/IEC 15504 的管理 —— 也稱 SPICE（軟體過程改進和能力測定），評價等。

3.8 達到 CMMI 符合性

組織經常採用的來達到 CMMI 模型遵從性的傳統的方法包括工程過程組（Engineering Process Group，簡稱 EPG）和過程行動團隊（PATs）的建立。這個方法要求：工程過程組和過程行動團隊的成員經過在 CMMI 中的培訓、一個非正式的評價（SCAMPI－丙）已被執行、以及過程區域被為改進而排列優先順序。更多新的方法包括商業可用的開發、遵從 CMMI 的過程，可以顯著地減少達到遵從的時間。軟工所已為組織透過更早的軟體 CMM、並主要使用傳統方法，維護對於 “提升時間” 的統計。這些統計表明，自 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）—— 一個軟體工程方法 —— 被按 CMM/CMMI 來評估（Nawrocki 等人，2002）。例如，依靠口頭交流的極限程式設計需求管理方法，被評估為不遵從 CMMI。

CMMI 可以被用兩種不同的方法來評價：分階段的和持續的。分階段的方法產生五個成熟度級別之一的評價結果。持續的方法產生六個能力級別之一。這些方法的不同點僅會在評價時被感知，最佳實踐是平等的並且導致平等的過程改進結果。