能力成熟度模型（CMM）是在研究從與美國國防部簽約的組織收集的數據之後創建的開發模型，該組織為研究提供資金。 “成熟度”一詞涉及流程的形式和最佳化程度，從臨時實踐到正式定義的步驟，到管理結果指標，再到流程的主動最佳化。
該模型的目標是改進現有的軟體開發過程，但它也可以套用於其他過程。
基本介紹
- 中文名：能力成熟度模型
- 外文名：Capability Maturity Model
- 支持者：美國國防部
- 相關大學：卡內基美隆大學
- 相關事件：成立了軟體工程學院
概觀,歷史,軟體過程先驅,先導,軟體工程研究所的發展,CMMI,適應其他流程,思想,“成熟度”等級,
概觀
能力成熟度模型最初是作為客觀評估政府承包商流程實施契約軟體項目能力的工具而開發的。 該模型基於IEEE軟體中首次描述的流程成熟度框架，後來在1989年出版的Watts Humphrey的“管理軟體過程”一書中進行了描述。 它後來在1993年的一份報告中發表並於1995年作為同一作者的一本書出版。
雖然該模型來自軟體開發領域，但它也被用作一般模式來輔助業務流程，並且在全球範圍內廣泛用於政府辦公室，商業和工業。
歷史
軟體過程先驅
在20世紀60年代，計算機的使用變得更加廣泛，更靈活，成本更低。組織開始採用計算機化信息系統，對軟體開發的需求顯著增長。許多軟體開發過程都處於起步階段，很少有標準或“最佳實踐”方法。
結果，增長伴隨著成長的痛苦：項目失敗很常見，計算機科學領域仍處於早期階段，項目規模和複雜性的雄心超出了在計畫預算內提供足夠產品的市場能力。Edward Yourdon，Larry Constantine，Gerald Weinberg，Tom DeMarco，和David Parnas等人開始發表研究成果的文章和書籍，試圖使軟體開發過程專業化。
在20世紀80年代，涉及軟體分包商的幾個美國軍事項目超預算，並且完成得比計畫的要晚得多。為了確定這種情況發生的原因，美國空軍資助了SEI的一項研究。
先導
向IT部門首次套用階段性成熟度模型不是由CMU / SEI，而是由Richard L. Nolan，他在1973年發布了IT組織增長模型的階段。
Watts Humphrey在他27年職業生涯的後期階段開始發展他的流程成熟度概念。
軟體工程研究所的發展
美國國防部軟體工程研究所（SEI）積極開發該模型始於1986年，當時Humphrey從IBM退休後加入位於賓夕法尼亞州匹茲堡卡內基梅隆大學的軟體工程研究所。應美國空軍的要求，他開始正式確定其過程成熟度框架，以幫助美國國防部評估軟體承包商的能力，作為授予契約的一部分。
空軍研究的結果是軍方用作客觀評估軟體分包商過程能力成熟度的模型。 Humphrey將這個框架建立在Philip B. Crosby在他的“質量是免費的”一書中開發的早期質量管理成熟度格線上。漢弗萊的方法不同，因為他獨特的洞察力，即組織基於以特定順序解決流程問題而分階段地成熟他們的流程。 Humphrey將他的方法基於組織內軟體開發實踐系統的分階段演化，而不是獨立地衡量每個獨立開發過程的成熟度。因此，CMM被不同的組織用作理解並隨後改進一般業務流程性能的通用且強大的工具。
Watts Humphrey的能力成熟度模型（CMM）於1988年出版，並於1989年出版，出版於管理軟體過程。組織最初使用由Humphrey及其同事在軟體工程研究所設計的過程成熟度問卷和軟體能力評估方法進行評估。
能力成熟度模型作為一套確定的過程域和實踐在五個成熟度級別中的每一個的完整表示始於1991年，1.1版本於1993年1月完成。CMM於1995年由其主要作者Mark C. Paulk，Charles V. Weber，Bill Curtis和Mary Beth Chrissis作為一本書出版。
CMMI
CMM模型在軟體開發中的套用有時會出現問題。在培訓，評估和改進活動中，套用未在組織內部和組織內部集成的多個模型可能成本很高。形成能力成熟度模型集成（CMMI）項目是為了解決使用多個模型進行軟體開發過程的問題，因此CMMI模型已經取代了CMM模型，儘管CMM模型仍然是一個通用的理論過程能力模型。
適應其他流程
CMM最初旨在作為評估政府承包商執行契約軟體項目的能力的工具。雖然它來自軟體開發領域，但它可以，一直並且繼續被廣泛套用為IS / IT（和其他）組織中過程成熟度（例如，IT服務管理過程）的一般模型。
思想
CMM的基本思想是，因為問題是由我們管理軟體過程的方法引起的，所以新軟體技術的運用不會自動提高生產率和利潤率。CMM有助於組織建立一個有規律的、成熟的軟體過程。改進的過程將會生產出質量更好的軟體，使更多的軟體項目免受時間和費用的超支之苦。
軟體過程包括各種活動、技術和用來生產軟體的工具。因此，它實際上包括了軟體生產的技術方面和管理方面。CMM策略力圖改進軟體過程的管理，而在技術上的改進是其必然的結果。
“成熟度”等級
必須牢記，軟體過程的改善不可能在一夜之間完成，CMM是以增量方式逐步引入變化的。CMM明確地定義了5個不同的“成熟度”等級，一個組織可按一系列小的改良性步驟向更高的成熟度等級前進。
成熟度等級1：初始級(Initial)。處於這個最低級的組織，基本上沒有健全的軟體工程管理制度。每件事情都以特殊的方法來做。如果一個特定的工程碰巧由一個有能力的管理員和一個優秀的軟體開發組來做，則這個工程可能是成功的。然而通常的情況是，由於缺乏健全的總體管理和詳細計畫，時間和費用經常超支。結果，大多數的行動只是應付危機，而非事先計畫好的任務。處於成熟度等級1的組織，由於軟體過程完全取決於當前的人員配備，所以具有不可預測性，人員變化了，過程也跟著變化。結果，要精確地預測產品的開發時間和費用之類重要的項目，是不可能的。
成熟度等級2：可重複級(Repeatable)。在這一級，有些基本的軟體項目的管理行為、設計和管理技術是基於相似產品中的經驗，故稱為“可重複”。在這一級採取了一定措施，這些措施是實現一個完備過程所必不可缺少的第一步。典型的措施包括仔細地跟蹤費用和進度。不像在第一級那樣，在危機狀態下方行動，管理人員在問題出現時便可發現，並立即採取修正行動，以防它們變成危機。關鍵的一點是，如沒有這些措施，要在問題變得無法收拾前發現它們是不可能的。在一個項目中採取的措施也可用來為未來的項目擬定實現的期限和費用計畫。
成熟度等級3：已定義級(Defined)。在第3級，已為軟體生產的過程編制了完整的文檔。軟體過程的管理方面和技術方面都明確地做了定義，並按需要不斷地改進過程，而且採用評審的辦法來保證軟體的質量。在這一級，可引用CASE環境來進一步提高質量和產生率。而在第—級過程中，“高技術”只會使這一危機驅動的過程更混亂。
成熟度等級4：已管理級(Managed)。一個處於第4級的公司對每個項目都設定質量和生產目標。這兩個量將被不斷地測量，當偏離目標太多時，就採取行動來修正。利用統計質量控制，管理部門能區分出隨機偏離和有深刻含義的質量或生產目標的偏離(統計質量控制措施的一個簡單例子是每千行代碼的錯誤率。相應的目標就是隨時間推移減少這個量)。
成熟度等級5：最佳化級(Optimizing)。—個第5級組織的目標是連續地改進軟體過程。這樣的組織使用統計質量和過程控制技術作為指導。從各個方面中獲得的知識將被運用在以後的項目中，從而使軟體過程融入了正反饋循環，使生產率和質量得到穩步的改進。
整個企業將會把重點放在對過程進行不斷的最佳化，採取主動的措施去找出過程的弱點與長處，以達到預防缺陷的目標。同時，分析各有關過程的有效性資料，作出對新技術的成本與效益的分析，並提出對過程進行修改的建議。達到該級的公司可自發的不斷改進，防止同類缺陷二次出現。
