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.
