CMMI

CMMI全稱是Capability Maturity Model Integration，即能力成熟度模型整合（也有稱為：軟體能力成熟度整合模型）  [1]  ，是美國國防部的一個設想，1994年由美國國防部（United States Department of Defense）與卡內基-梅隆大學（Carnegie-Mellon University）下的軟體工程研究中心（Software Engineering Institute，SEISM）以及美國國防工業協會（National Defense Industrial Association）共同開發和研製的，他們計劃把現在所有現存實施的與即將被髮展出來的各種能力成熟度模型，整合到一個框架中去，申請此認證的前提條件是該企業具有有效的軟體企業認定證書。 其目的是幫助軟體企業對軟體工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟體。其所依據的想法是：只要集中精力持續努力去建立有效的軟體工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟體開發中的困難。CMMI為改進一個組織的各種過程提供了一個單一的整合化框架，新的整合模型框架消除了各個模型的不一致性，減少了模型間的重複，增加透明度和理解，建立了一個自動的、可擴充套件的框架。因而能夠從總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。  

中文名

軟體能力成熟度整合模型

外文名

Capability Maturity Model Integration

簡    稱

CMMI

別    名

軟體能力成熟度模型整合

目錄

1. 1 版本介紹
2. 2 過程域
3. ▪ 過程管理
4. ▪ 專案管理
5. ▪ 工程管理
6. ▪ 支援管理
7. 3 發展歷史
8. ▪ CMMI的起源

1. ▪ 發展簡介
2. ▪ 研發背景
3. ▪ 關鍵元素
4. 4 評估
5. ▪ 預備工作
6. ▪ 評估方法
7. ▪ 專案管理
8. 5 等級

1. 6 實施要點
2. ▪ 基本思想
3. ▪ 源模型
4. ▪ 原則
5. ▪ 目標
6. ▪ 方法
7. ▪ 內容
8. ▪ 工具

1. ▪ 人員素質
2. ▪ 實施流程
3. 7 模型差別
4. 8 名詞術語
5. 9 CMMI的價值
6. 10 區別

 

版本介紹

編輯 CMMI是一套融合多學科的、可擴充的產品集合， 其研製的初步動機是為了利用兩個或多個單一學科的模型實現一個組織的整合化過程改進。CMMI的本質是軟體管理工程的一個部分。軟體過程改善是當前軟體管理工程的核心問題， 50多年來計算機的發展使人們認識到要高效率、高質量和低成本地開發軟體，必須改善軟體生產過程。基於模型的過程改進是指採用能力模型來指導組織的過程改進，使之過程能力穩定的進行改善，該組織也能變得更加成熟。 CMMI的成功促使其他學科也相繼開發類似的過程改進模型，例如系統工程、需求工程、人力資源、整合產品開發、軟體採購等等，從CMM衍生出了一些改善模型，比如：SW－CMM,SE-CMM,IPD-CMM等。不過，在同一個組織中多個過程改進模型的存在可能會引起衝突和混淆。CMMI就是為了解決怎麼保持這些模式之間的協調。 CMMI 1.3是2010年11月SEI 釋出的CMMI模型的最新版本。CMMI 1.3包括CMMI採購模型1.3版、CMMI開發模型1.3版、CMMI服務模型1.3版。 CMMI開發模型1.3版（CMMI-DEV 1.3）與CMMI開發模型1.2版相比，做了如下改進： 1）將過程域“組織級創新與部署”（Organizational Innovation and Deployment,OID）更名為“組織績效管理”（Organizational Performance Management, OPM),並增加了一個新的特定目標與幾個新的特定實踐。 2）對模型架構進行了改進，簡化對多個模型的使用。  

過程域

編輯 Process Area：過程域。簡單的說就是做好一個事情的某一個方 面，對應軟體開發來說，就是做好軟體開發的某一個方面。 2、3級共有18個過程域（PA）,主要內容如下，分四大類：  

過程管理

1． OPD：（Organizational Process Definition）組織級過程定義。建立和維護有用的組織過程資產。 2． OPF：（Organizational Process Focus）組織級過程焦點。在理解現有過程強項和弱項的基礎上計劃和實施組織過程改善。 3． OT：（Organizational Training）組織培訓管理。增加組織各級人員的技能和知識，使他們能有效地執行他們的任務。  

專案管理

4． PP：（Project Plan）專案計劃。保證在正確的時間有正確的資源可用。為每個人員分配任務、協調人員。根據實際情況，調整專案。 5． PMC：（Project Monitoring and Control）專案監督與控制。通過專案的跟蹤與監控活動，及時反映專案的進度、費用、風險、規模、關鍵計算機資源及工作量等情況，通過對跟蹤結果的分析，依據跟蹤與監控策略採取有效的行動，使專案組能在既定的時間、費用、質量要求等情況下完成專案。 6．SAM：（Supplier Agreement Management）供應商協議管理。旨在對以正式協定的形式從專案之外的供方採辦的產品和服務實施管理。 7．IPM：（Integrated Project Management）整合專案管理。根據從組織標準過程剪裁而來的整合的、定義的過程對專案和利益相關者的介入進行管理。 8． RSKM：（Risk Management）風險管理。識別潛在的問題，以便策劃應對風險的活動和必要時在整個專案生存週期中實施這些活動，緩解不利的影響，實現目標。  

工程管理

9．RD：（Requirement Development）需求開發。需求開發的目的在於定義系統的邊界和功能、非功能需求，以便涉眾(客戶、終端使用者)和專案組對所開發的內容達成一致。 10．REQM（Requirement Management）需求管理。需求管理的目的是在客戶和軟體專案之間就需要滿足的需求建立和 維護一致的約定。 11．TS：（Technical Solution）技術解決方案。在開發、設計和實現滿足需求的解決方案。解決方案的設計和實現等都圍繞產品、產品元件和與過程有關的產品。 12．PI：（Product Integration）產品整合。從產品部件組裝產品，確保整合產品功能正確並交付產品。 13．VAL：（Validation）確認。確認證明產品或產品部件在實際應用下滿足應用要求。 14．VER：（Verification）驗證。驗證確保選定的工作產品滿足需求規格。  

支援管理

15． CM：（Configuration Management）配置管理。建立和維護在專案的整個軟體生存週期中軟體專案產品的完整性 。 16．PPQA：（Process and Product Quality Assurance）過程和產品質量保證。為專案組和管理層提供專案過程和相關工作產品的客觀資訊。 17．MA：（Measurement and Analysis）測量與分析。開發和維持度量的能力，以便支援對管理資訊的需要。作為改進、瞭解、控制決策。 18． DAR：（Decision Analysis and Resolution）決策分析與解決。應用正式的評估過程依據指標評估候選方案，在此基礎上進行決策。 第4級除第2、3級所涵蓋的18個流程領域外，增加 19. OPP ：（Organizational Process Performance）組織過程效能。建立與維護組織過程效能的量化標準，以便使用量化方式的管理專案。 20. QPM（Quantitative Project Management) 量化的專案管理，量化管理專案已定義的專案過程，以達成專案既定的質量和過程效能目標。。 第5級包含第2級到第4級的20個流程領域外，增加， 21. OPM：(Organizational Performance and Management）組織的績效與管理，選擇並推展漸進創新的組織過程和技術改善，改善應是可度量的，所選擇及推展的改善需支援基於組織業務目的的質量及過程執行目標。 22. CAR：（Causal Analysis and Resolution）因果分析與解決。識別缺失的原因並進行矯正，進一步的防止未來再次發生。 其他術語： Life Cycle：（Software Life Cycle Model）專案管理的生命週期。關注的是專案的過程管理。 MA：（Measurement & Analysis）。開發並持續發展度量能力以滿足專案管理的資訊需求。 Milestone Review：（Milestone Review）階段評審。在階段結束時評審專案的狀態並確定專案是否應該進入下一階段。 Process Tailoring：（Process Tailoring）過程裁剪。為了使組織定義的標準過程能夠適合於組織專案管理，不論該專案是提供產品還是服務。 Review：（Review）評審。可以有效提高系統，軟體及產品的質量。 Testing：軟體測試。  

發展歷史

編輯  

CMMI的起源

隨著人們對CMM研究的不斷深入，其他學科也結合本系統的特點，陸續推出了自己的CMM模型。例如，人力資源能力成熟度模型、系統工程能力成熟度模型等等： （1） SW-CMM (Software CMM) 軟體CMM （2） SE-CMM (System Engineering CMM) 系統工程CMM （3） SA-CMM (Software Acquisition CMM) 軟體採購CMM （4） IPT-CMM (Integrated Product Team CMM) 整合產品群組CMM （5） P-CMM (People CMM) 人力資源能力成熟度模型 為了以示區別，國內外很多資料把CMM叫做SW-CMM。按照SEI原來的計劃，CMM的改進版本2.0應該在1997年11月完成，然後在取得版本2.0得實踐反饋意見之後，在1999年完成準CMM2.0版本。  

發展簡介

自從1994 年SEI正式釋出軟體CMM以來，相繼又開發出了系統工程、軟體採購、人力資源管理以及整合產品和過程開發方面的多個能力成熟度模型。雖然這些模型在許多組織都得到了良好的應用，但對於一些大型軟體企業來說，可能會出現需要同時採用多種模型來改進自己多方面過程能力的情況。這時他們就會發現存在一些問題，其中主要問題體現在： n 不能集中其不同過程改進的能力以取得更大成績； n 要進行一些重複的培訓、評估和改進活動，因而增加了許多成本； n 遇到不同模型中有一些對相同事物說法不一致，或活動不協調，甚至相抵觸。 於是，希望整合不同CMM 模型的需求產生了。1997 年，美國聯邦航空管理局（FAA）開發了FAA-iCMMSM（聯邦航空管理局的整合CMM），該模型集成了適用於系統工程的SE-CMM、軟體獲取的SA-CMM 和軟體的SW-CMM 三個模型中的所有原則、概念和實踐。該模型被認為是第一個整合化的模型。CMM與CMMI最大的不同點和區別： CMMISM-SE/SW/IPPD/SS 1.1 版本有四個整合成分，即：系統工程(SE)和軟體工程(SW)是基本的科目，對於有些組織還可以應用整合產品和過程開發方面(IPPD)的內容，如果涉及到供應商外包管理可以相應的應用SS(Supplier Sourcing)部分。 CMMI有兩種表示方法，一種是大家很熟悉的，和軟體CMM 一樣的階段式表現方法，另一種是連續式的表現方法。這兩種表現方法的區別是：階段式表現方法仍然把CMMI中的若干個過程區域分成了5 個成熟度級別，幫助實施CMMI的組織建議一條比較容易實現的過程改進發展道路。而連續式表現方法則通過將CMMI中過程區域分為四大類：過程管理、專案管理、工程以及支援。對於每個大類中的過程區域，又進一步分為基本的和高階的。這樣，在按照連續式表示方法實施CMMI的時候，一個組織可以把專案管理或者其他某類的實踐一直做到最好，而其他方面的過程區域可以完全不必考慮。  

研發背景

CMMI的成功促使其他學科也相繼開發類似的過程改進模型，例如系統工程、需求工程、 人力資源、整合產品開發、軟體採購等等，從CMM衍生出了一些改善模型，比如： （1） SW-CMM (Software CMM) 軟體CMM （2） SE-CMM (System Engineering CMM) 系統工程CMM （3） SA-CMM (Software Acquisition CMM) 軟體採購CMM （4） IPT-CMM (Integrated Product Team CMM) 整合產品群組CMM （5） P-CMM (People CMM)人力資源能力成熟度模型 美國國防部辦公室要求SEI推遲釋出CMM2.0版本，而要先完成一個更為緊迫的專案CMMI，原因是在同一個組織中多個過程改進模型的存在可能會引起衝突和混淆， CMMI就是為了解決怎麼保持這些模式之間的協調。 CMMI（Capability Maturity Model Integration）即能力成熟度整合模型，這是美國國防部的一個設想，他們想把所有的以及將被髮展出來的各種能力成熟度模型，整合到一個框架中去。這個框架有兩個功能，第一，軟體採購方法的改革；第二，建立一種從整合產品與過程發展的角度出發、包含健全的系統開發原則的過程改進。就軟體而言，CMMI是SW-CMM的修訂本。 它兼收了SW-CMM 2.0版C稿草案和SPA中更合理、更科學和更周密的優點。SEI在發表CMMI-SE/SW 1.0版時，宣佈大約用兩年的時間完成從CMM到CMMI的過渡。 CMMI專案更為工業界和政府部門提供了一個整合的產品集，其主要目的是消除不同模型之間的不一致和重複，降低基於模型改善的成本。CMMI將以更加系統和一致的框架來指導組織改善軟體過程，提高產品和服務的開發、獲取和維護能力。 由業界、美國政府和卡內基·梅隆大學軟體工程研究所率先倡導的能力成熟度模型整合（CMMI）專案致力於幫助企業緩解這種困境。 與原有的能力成熟度模型類似，CMMI也包括了在不同領域建立有效過程的必要元素，反映了業界普遍認可的"最佳"實踐；專業領域覆蓋軟體工程、系統工程、整合產品開發和系統採購。在此前提下，CMMI為企業的過程構建和改進提供了指導和框架作用；同時為企業評審自己的過程提供了可參照的行業基準。  

關鍵元素

CMMI自出道以來，它所達到的目標就沒有變過，第一個是質量，第二個是時間表，第三就是要用最低的成本。不過特別強調的是，CMMI不是傳統的、僅侷限於軟體開發的生命週期，它應該被運用於更廣泛的一個範疇——工程設計的生命週期。TSP的建立，也是為了支援CMMI的這樣一個系統。那麼CMMI究竟是什麼呢？它並不是一個過程，也不是告訴你怎麼去做一件事情。如果用一句話來概括什麼是CMMI，它就是各個程序的一個關鍵的元素，在很多領域裡面一個整合的點。它是這樣的一個基本架構，能夠用來度量你的有效性和實用性；能夠找出這樣的一些機會，繼續改進的機會，包括在商業目標、策略還有降低專案的風險等方面。  

評估

編輯  

預備工作

評估實踐證明：在進行CMMI評估之前，制定一個正確的評估計劃並將其文件化，確保有一個富有經驗的、受過培訓且具有適當資格的小組能被用來評估，為執行評估過程做準備，是十分必要的。 我們所說的文件化CMMI評估計劃的結果，包括：要求，協定，估價，風險，剪裁方法，以及與評估相關的實際考慮（例如：日程安排，後勤，組織的背景資訊）。此外，還應當獲取並記錄發起方對於CMMI評估計劃的正式批准。在制定評估計劃之前，應對CMMI評估輸入中反映出來的協議文件化，該協議將有助於CMMI評估目標和關鍵評估計劃引數的共同理解。在對驅動計劃過程的關鍵引數達成共同理解的基礎上，CMMI評估發起方和SCAMPI主任評估師應就評估計劃達成一致；發起者和評估小組領導應就已計劃的評估中技術和非技術細節達成一致。這個計劃在執行其他的計劃和準備階段活動中需要進一步細化。 而通過CMMI評估小組的準備工作，將產生一支富有經驗的、受過培訓的且定位準確的小組準備執行CMMI評估任務。該小組的成員都應當獲得了完成他們各自的任務所必備的知識，或者他們之前所擁有的知識被證實足以完成相關任務。評估小組領導者已經給每一個人提供了為完成他們各自的任務所需的對技能進行實踐的機會，或者證實這些技能在過去已經得到了示範。小組成員相互瞭解，同時開始計劃他們如何協調一致的工作。還應該做到：準備好的小組是為評估目標而服務的，小組的成員已提供培訓且培訓結果被記錄，在必要的時候，對他們所做的因知識或技能不足的補救工作已經完成。我們認為，無論CMMI評估小組領導者是從頭培訓一支全新的評估小組，還是通過從富有經驗的小組成員中選擇來組建一個小組，確保他們與CMMI評估小組領導者能組成一個成功的集體是其責任。此外，在對CMMI評估進行的預備工作的過程中，我們還應當對模型剪裁的原則有所瞭解： 1.在某些應用中，計劃模板和例行的程式能夠根據評估的需要進行調整，這和當地的過程所有權一樣，有助於交流； 2.一個結構化的計劃工藝組有利於只有有限的評估經驗的組織，這樣一個工藝就像緩和策略樣，對於發現風險是一個很有價值的機會； 3.案例研究材料提供了各種各樣的選擇來擴充小組培訓內容以增強那些更需要培訓的重點； 4.富有經驗的評估小組領導者在沒有案例分析的情況下，同樣可以管理和模擬評估行為； 5.在小組所有已獲得培訓成員的集合中，對小組的建立工作進行管理以確保其團隊凝聚力是十分重要的，因此，很多的小組建立練習是可以利用的，小組的規模、技能、組成部分都是本方法的裁剪內容； 6.所採用工具可以包括評估計劃模板，樣例，和計劃模板中嵌入式的程式上的幫助，此外，為了估計評估約束的影響，估算工作表和方法也是很有用處的。 總之，CMMI評估是一個十分複雜的過程，更由於其具有的不確定性，在評估的實踐中，一定要做到有備無患。真理來自於實踐，我們相信，隨著越來越多的軟體組織著手CMMI評估，越來越多的成功經驗將為我們所利用和借鑑。  

評估方法

SEI將CMMI的評估過程分為Class A、B 、C三種類型： Class A類評估：是正式的標準過程，目的是獲得評估等級，評估過程需執行所有的評估步驟 ，在CMMI標準中需要滿足ARC要求 ( Appraisal Requirement for CMMI ) ，需要組建正式評估小組，並需要SEI授權的主任評估師領導評估組進行評估。根據被評估的CMMI的不同級別，評估組人數通常為4-9人，評估天數為5-10天，被評估企業派人蔘加ATM。評估方式為檔案審查和人員訪談，評估輸出物為最終評估報告，並由主任評估師向SEI註冊評估結果。具體評估過程詳細描述參見SCAMPI ( Standard CMMI Appraisal Method for Process Improvement) “標準的CMMI評估方法”。企業做CMMI評估並向SEI註冊，都是採用本類評估。 Class B類評估：只需要滿足部分的ARC要求，並可以只收集更少的資訊，但必須包括從訪談方式獲得的資訊，不需要最終產生組織的成熟度級別，評估組的負責人既可以是SEI授權主任評估師，也可以由組織內部有經驗的成員擔當，可以認為是組織內部的評估過程，可以在過程改進過程中的診斷過程中使用，也可以在組織發展過程中進行階段性評估審計時使用。 Class C類評估：是一種非正式評估過程，滿足更少的ARC要求，組織快速瀏覽過程，只確定相對較少過程域，不需要SEI授權評估師給出組織成熟度級別。一般是針對特定少數或一個專案，或針對少數過程、或一個過程在組織中執行的情況進行評估，通常是在組織發展過程中進行。 自1991年起，CMM出現了很多模型，覆蓋了各種各樣的專業領域。其中著名的模型有系統工程·軟體工程·軟體採購·整合產品和流程開發等。然而當企業想要在組織內不同專業領域的流程改進，這些針對不同專業領域的模型在架構·內容和方法上的不同限制了組織成功實施改進的能力。此外，將這樣模型在組織內部整合也提高了培訓·認證和改進的費用。一套包括多個專業領域的模型加上整合的培訓和認證支援將解決這些問題。 CMMI(Capability maturity model integration)是為了合併三個模型到一個框架中 Capability Maturity Model for Software (SW-CMM) v2.0 draft C, Electronic Industries Alliance Interim Standard (EIA/IS) 731 Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 正如其他CMM模型，CMMI提供了流程改進的指導，而不是流程或流程的描述。組織使用的實際流程取決於很多因素，包括應用領域·組織框架和規模。CMMI將許多經過驗證的方法加入架構中，來幫組組織評價成熟度·某個軟體流程的能力度，並且建立改進的優先順序和實施改進。 從CMMI框架可以產生不同的CMMI模型，因此必須首先確定那種模型最適合企業流程改進的需要。 階段式描述 or 連續式描述 階段式描述：階段式表述提供系統化與結構化的方式，一次一個階段達到以模型為基礎的過程改進。達成每一個階段可確保有足夠的過程基礎建設，可作為下一個階段過程改進的基礎。過程域是以成熟度等級組織，並且對過程改進做一些推測工作。階段式表述根據成熟度等級規定執行過程改進的順序，它定義一個組織由初始級到已優化級的改進路徑。達到每一個成熟度等級可確保有足夠的過程基礎建設，可作為下一個成熟度等級的基礎，並且允許持續與漸進的改進。假如你不知道要選擇哪一個過程開始進行改進，階段式表述對你而言是一個好的選擇。它給你一組特定的過程，針對每一個階段進行改進。這組過程的決定，是來自於十多年過程改進的研究和經驗。 連續式描述：當使用CMMI 模型進行過程改進時，連續式表述可提供最大的彈性。一個組織可以選擇改進單一過程相關的問題點的績效，或是可以使用多個領域以密切配合組織的經營目標。連續式表述也允許一個組織將不同的過程改進至不同的等級。但組織在選擇上仍有一些限制，因為有一些過程域是彼此相依的。假如你知道在你的組織中需要改進的過程，以及瞭解CMMI 中過程域間的相依性。對你的組織而言，連續式表述是一個好的選擇。 系統工程 or 軟體工程 or 兩者皆有 使用連續式描述可以根據企業需要選擇流程改進順序，降低企業風險，這給通過ISO做流程改進提供了一個方便的比較。使用能力度(Capability)來衡量。 階段式描述提供了已經過驗證的流程改進順序，方便從CMM移植過來。使用成熟度(Maturity)來衡量流程改進。 系統工程包括整個系統的開發，可能包括軟體也可能不包括。 軟體工程用於軟體系統的開發，主要集中在使用系統的·科學的·量化的方法來開發·執行·維護軟體。  

專案管理

由美國卡內基梅隆大學的軟體工程研究所(SEI)創立的CMM(Capability Maturity Model軟體能力成熟度模型)認證評估，在過去的十幾年中，對全球的軟體產業產生了非常深遠的影響。CMM共有五個等級，分別標誌著軟體企業能力成熟度的五個層次。從低到高，軟體開發生產計劃精度逐級升高，單位工程生產週期逐級縮短，單位工程成本逐級降低。據SEI統計，通過評估的軟體公司對專案的估計與控制能力約提升40%到50%；生產率提高10%到20%，軟體產品出錯率下降超過1/3。 對一個軟體企業來說，達到CMM2就基本上進入了規模開發，基本具備了一個現代化軟體企業的基本架構和方法，具備了承接外包專案的能力。CMM3評估則需要對大軟體整合的把握，包括整體架構的整合。一般來說，通過CMMI認證的級別越高，其越容易獲得使用者的信任，在國內、國際市場上的競爭力也就越強。因此，是否能夠通過CMMI認證也成為國際上衡量軟體企業工程開發能力的一個重要標誌。 CMMI是世界公認的軟體產品進入國際市場的通行證，它不僅僅是對產品質量的認證，更是一種軟體過程改善的途徑。參與CMM評估的博科負責人表示，通過CMM的評估認證不是目標，它只是推動軟體企業在產品的研發、生產、服務和管理上不斷成熟和進步的手段，是一種持續提升和完善企業自身能力的過程。如果一家公司最終通過CMMI的評估認證，標誌著該公司在質量管理的能力已經上升到一個新的高度。  

等級

編輯 1． 初始級 軟體過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，成功取決於個人努力。管理是反應式的。 2．可管理級 建立了基本的專案管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律，能重複早先類似應用專案取得的成功經驗。 3． 已定義級 已將軟體管理和工程兩方面的過程文件化、標準化，並綜合成該組織的標準軟體過程。所有專案均使用經批准、剪裁的標準軟體過程來開發和維護軟體，軟體產品的生產在整個軟體過程是可見的。 4． 量化管理級 分析對軟體過程和產品質量的詳細度量資料，對軟體過程和產品都有定量的理解與控制。管理有一個作出結論的客觀依據，管理能夠在定量的範圍內預測效能。 5． 優化管理級 過程的量化反饋和先進的新思想、新技術促使過程持續不斷改進。 每個等級都被分解為過程域，特殊目標和特殊實踐，通用目標、通用實踐和共同特性： 每個等級都有幾個過程區域組成，這幾個過程域共同形成一種軟體過程能力。每個過程域，都有一些特殊目標和通用目標，通過相應的特殊實踐和通用實踐來實現這些目標。當一個過程域的所有特殊實踐和通用實踐都按要求得到實施，就能實現該過程域的目標。 能力度等級：屬於連續式表述，共有六個能力度等級(0~5)，每個能力度等級對應到一個一般目標，以及一組一般執行方法和特定方法。 0　不完整級 1　已執行級 2　已管理級 3　已定義級 4　量化管理級 5　最優化級  

實施要點

編輯  

基本思想

1、解決軟體專案過程改進難度增大問題 2、實現軟體工程的並行與多學科組合 3、實現過程改進的最佳效益  

源模型

軟體能力成熟度模型2.0版，C稿；電子行業協會臨時標準（EIA/IS）731；整合產品開發能力成熟度模型（IPD-CMM）v0.98。  

原則

（1）、強調高層管理者的支援。過程改進往往也是由高層管理者認識和提出的，大力度的、一致的支援是過程改進的關鍵。 （2）、 仔細確定改進目標，首先應該對給定時間內的所能完成的改進目標進行正確的估計和定義並制定計劃。選擇能夠達到的目標和能夠看到對組織的效益。 （3）、 選擇最佳實踐，應該基於組織現有的軟體活動和過程財富，參考其他標準模型，取其精華去其糟粕，得到新的實踐活動模型。 （4）、 過程改進要與組織的商務目標一致，與發展戰略緊密結合。  

目標

綜述 （1）為提高組織過程和管理產品開發、釋出和維護的能力提供保障。 （2）幫助組織客觀評價自身能力成熟度和過程域能力，為過程改進建立優先順序以及執行過程改進。 初步目標 CMMI專案初步的目標（在2000年已達到，其釋出的版本是CMMI-SE/SW和CMMI-SE/SW/IPPD模型）是整合三個特殊的過程改進模型：軟體CMM、系統工程能力評估標準以及整合化產品和過程開發模型。 這項整合的目的是通過一種手段減少實現基於多學科模型的過程改進成本。 長期目標 CMMI專案長期的目標是為今後把其他學科（如獲取過程和安全性）新增到CMMI中奠定基礎。為了促進模型整合，CMMI產品開發組建立了一個自動的、可擴充套件的框架，其中可放入構件、培訓資料構件以及評估資料。在已定義的規則控制下，更多的新學科能被加入到該框架中。  

方法

（1）、決定哪個CMMI模型等級最適合組織過程改進需要。 （2）、 選擇模型的表示法是連續式還是階段式。 （3）、 決定組織需要用到的模型中的知識領域。 （4）、 類似CMM提出的過程改進6步，整合化過程改進分成：開始整合過程改進,建造整合改善平臺，整合傳統過程，啟動新過程，進行改進評估。  

內容

CMMI內容分為“Required”（必需的）、“Expected”（期望的）、“Informative”（提供資訊的）三個級別，來衡量模型包括的質量重要性和作用。最重要的是"要求"級別，是模型和過程改進的基礎。第二級別"期望"在過程改進中起到主要作用，但是某些情況不是必須的可能不會出現在成功的組織模型中。 "提供的資訊"構成了模型的主要部分，為過程改進提供了有用的指導，在許多情況下他們對"必需"和"期望"的構件做了進一步說明。 "必需"的模型構件是目標，代表了過程改進想要達到的最終狀態，它的實現表示了專案和過程控制已經達到了某種水平。當一個目標對應一個關鍵過程域，就稱為"特定目標"；對應整個關鍵過程域就稱為"公用目標"。整個CMMI模型包括了54個特定目標，每個關鍵過程域都對應了一到四個特定目標。每個目標的描述都是非常簡捷的，為了充分理解要求的目標就是擴充套件"期望"的構件。 "期望"的構件是方法，代表了達到目標的實踐手段和補充認識。每個方法都能對映到一個目標上，當一個方法對一個目標是唯一就是"特定方法"；而能適用於所有目標時就是"公用方法"。CMMI模型包括了186個特定方法，每個目標有兩到七個方法對應。 CMMI包括了10種"提供的資訊"：目的，概括和總結了關鍵過程域的特定目標；介紹說明，介紹關鍵過程域的範圍、性質和實際方法和影響等特徵；引用，關鍵過程域之間的指向是通過引用；名字，表示了關鍵過程域的構件；方法和目標關係，關鍵過程域中方法對映到目標的關係表；註釋，註釋關鍵過程域的其他模型構件的資訊來源；典型工作產品集，定義關鍵過程域中執行方法時候產生的工作產品；子方法，通過方法活動的分解和詳細描述；學科擴充，CMMI對應學科是獨立的，這裡提供了對應特定學科的擴充套件；公用方法的詳細描述，關鍵過程域中公用方法應用實踐的詳細描述。 CMMI提供了階段式和連續式兩種表示方法，但是這兩種表示法在邏輯上是等價的。我們熟悉的SW-CMM軟體能力成熟模型就是是階段式的模型，SE-CMM系統工程模型是連續式模型，而IPD-CMM整合產品開發模型結合了階段式和連續式兩者的特點。 階段式方法將模型表示為一系列"成熟度等級"階段，每個階段都有一組KPA指出一個組織應集中於何處以改善其組織過程，每個KPA用滿足其目標的方法來描述，過程改進通過在一個特定的成熟度等級中滿足所有KPA的目標而實現的。 連續式模型沒有像階段式那樣的分散階段，模型的KPA中的方法是當KPA的外部形式，並可應用於所有的KPA中，通過實現公用方法來改進過程。它不專門指出目標，而是強調方法。組織可以根據自身情況適當裁剪連續模型並以確定的KPA為改進目標。 兩種表示法的差異反應了為每個能力和成熟度等級描述過程而使用的方法，他們雖然描述的機制可能不同，但是兩種表示方法通過採用公用的目標和方法作為"必需"的和"期望"的模型元素，而達到了相同的改善目的。 CMMI面臨的一個挑戰就是建立一個單一的模型，可以從連續和階段兩個角度進行觀察，包含相同的過程改進基本資訊；處理相同範圍的一個CMMI過程能夠產生相同的結論。統一的CMMI（U-CMMI）是指產生一個只有公用方法和支援他們的KPA組成的模型。當按一種概念性的可伸展的方式編寫，併產生了用於定義組織的特定目標過程模版，定義的模版構件將定義一個模型以適用於任何工程或其他方面。  

工具

組織在實踐CMMI過程中，提升和改進研發管理能力的同時，也面臨著輔助過程改進工具的挑戰，缺少工具支撐，CMMI的規程、流程，尤其量化資料分析的推行成本非常高，往往使很多組織望而生畏；實踐證明能夠很好支撐CMMI落地的工具有：微軟Project Server、IBM Rational系列工具、青銅器RDM研發管理系統、Techexcel DevSuite。CMMI工具至少要滿足如下特點： 1. 以專案運作為主線條，至少包含計劃進度管理、工時管理、文件管理、變更管理、風險問題管理、量化管理。 2. 強大的流程自定義能力，能夠支撐不同組織根據自己的要求自定義相應的流程。 3. 量化資料收集與分析能力，能夠自定義專案質量目標，根據專案質量資料自動彙總組織的能力基線；同時要有智慧報表能力。 4. 知識管理能力，尤其要實現情境化知識管理，能夠將專案歷史實際資料直接作為知識進行分享、重用，知識管理要與操作人的行為關聯。 5. 工程技術要全覆蓋，至少要涵蓋需求分析與需求管理、測試管理（測試計劃、測試用例、測試執行）、需求跟蹤管理、文件管理、評審與驗證管理。  

人員素質

1、明白什麼是有價值的積累，先是對你個人，然後才是順便幫公司做了積累。 2、深入一線，發現她們並忠實地記錄它們。CMMI裡的SP、GP，只是幫助你，提醒你在哪個環節，哪些東西可能是有價值了。你去收集一下，別視而不見了。因為還有一個企業和你個人的角度不同，立場不同的問題。例如，REQM裡收集需求，對個人技術方面的積累雖然不多，但對企業是至關重要的，一次需求變更，沒詳細寫清楚，忘記了到客戶那裡去簽字落實，可能就會給企業造成很大的損失。做為一個合格的EPG，是需要有這份責任和義務把每個環節都做到最好，這是職業道德所在。同時也是對自我延伸的一個好機會，學會一些和人的溝通，傾聽，把專業的東西以平易的方式表達。這些也都算是EPG額外的收穫。 通常情況下，為了按時按量完成專案，一線的骨幹，對寫日報、週報、文件都很不屑。EPG也很遷就，事後再補，這也不失為一個提高效率的好辦法。但過去一個月半年了，我們正常人的記憶都能想象，很難記住細節。無非就是敷衍。這也在情理之中。你總不能讓一個明天就要交東西的小組，今天晚上在通宵努力解決BUG的同時，還寫什麼報告，這也不盡人情。但作為EPG不能只把眼光集中在這婦人之心上。要想的更遠。為什麼會把專案推到這麼晚，BUG還沒解決完?難道要永遠這樣下去嗎?專案中是有很多不可預測的因素，甚至是開發人員常說的"手氣問題"，"人品問題"。但這些是需要控制的，也是通過經驗可以控制的，所謂藝高人膽大。藝的高低，就是經驗的積累決定的。 那怎麼解決這種兩難的問題呢?逼著技術骨幹寫心得，人家沒時間也的確壓力很大。不寫，公司又得不到有效積累，積累的都是垃圾流水。有個公司的辦法和經驗到可以借鑑一下： 公司內部搞了個BBS，把不同型別的工作分成不同的組，有純技術的，JAVA組，C++組等，也有PPT組，甚至動畫組，介面組。大家把自己平時的工作積累FTP上去，甚至製作方法，遇到問題和解決方法的文件都丟上去，開始怎麼想，用了多少套方案，最後選擇了什麼。自我感覺如何。把這些心路歷程都寫成文件。丟到陽光下，大家評論。用點選率和"頂"的人數來說明誰寫的是心得，誰在寫垃圾。大家都是一個公司的，很容易實名。直接納入考核機制中。做為一線人員，大家也有動力來寫，自己的聰明才智有了展現的平臺，虛榮心和荷包都得到了相應的滿足。何樂而不為呢? EPG適時的評估大家的成果，並把他們分到專案裡。幫助專案總結，甚至在平時遇到問題時，直接幫助技術人員做必要記錄。專案進度鬆時，再督促專案人員完善內容。以達到對個人和公司積累的最大化。 EPG應該明白學習和積累是個終身的過程，對公司如此，對個人也是如此。CMMI是個輔助，輔助我們對公司做積累，也幫助我們個人做必要的積累。公司需要逐步走向更高的管理水平，發展平臺。  

實施流程

階段1：CMMI專案啟動會 明確企業實施CMMI的商業目標，建立CMMI專案實施的溝通機制。 階段2：CMMI基礎培訓和過程改進小組（EPG）組建 進行CMMI基礎概念講解，指導企業建立核心的過程改進小組。 階段3：診斷 充分了解企業研發過程現狀，識別企業現有軟體過程與企業現階段理應達到的CMMI成熟度級別的差距，提交診斷報告，進行過程改進的策劃。 階段4：過程域培訓和檔案定義 結合企業過程現狀進行CMMI過程域培訓，通過舉例、案例分析等方式，讓企業的EPG掌握過程檔案定義技巧，結合企業實際情況有針對性的定義組織的研發過程，並確定過程產出物（如：需求報告） 階段5：專案試點 選擇代表公司核心業務的專案或者典型專案進行試點，通過試點來完善過程檔案，從而為企業全面推廣過程檔案打下基礎。 階段6：組織推廣 全員參與全面匯入與執行CMMI。 階段7：預評估 驗證組織推廣的結果，識別企業尚存缺陷並制定再次改善方案，準備充分，以便企業能夠更好進行正式SCAMPI評估。 階段8：SCAMPI A 正式評估 由SEI授權的主任評估師領導，採用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)評估方法，對企業的能力成熟度進行正式的評估，頒發證書，通過SEI網站向全球釋出企業資訊。 CMMI主要內容及各過程域的相互關係 CMMI 2、3級共有18個過程域（PA）,主要內容如下，分四大類：
　　一、過程管理：
　　1． OPD：組織級過程定義。
　　2． OPF：組織級過程焦點。
　　3． OT：組織培訓管理。
　　二、專案管理：
　　4． PP：專案計劃。
　　5． PMC：專案監督與控制。
　　6． SAM：供應商協議管理。
　　7． IPM：整合專案管理。
　　8． RSKM：風險管理。 三、工程管理: 9． REQM：需求管理。 10． RD：需求開發。 11． TS：技術解決方案。
　　12． PI：產品整合。
　　13． VER：驗證。
　　14． VAL：確認。
　　四、支援管理：
　　15． CM：配置管理。
　　16． PPQA：過程和產品質量保證。
　　17． MA：測量與分析。
　　18． DAR：決策分析與解決。
　　CMMI 4級除第2、3級所涵蓋的18個過程域外，增加以下兩個過程域：
　　19. OPP ：組織過程效能。
　　20. QPM：量化的專案管理 。 CMMI 5級包含第2級到第4級的20個過程域外， 增加以下兩個過程域：
　　21. OPM：組織績效與管理。
　　22. CAR：因果分析與解決方案。 CMMI模型表述階段式：
　　1、階段式表述提供系統化與結構化的方式，一次一個階段達到以模型為基礎的過程改進。達成每一個階段可確保有足夠的過程基礎建設，可作為下一個階段過程改進的基礎。
　　2、連續式：連續式表述可提供最大的彈性。一個組織可以選擇改進單一過程相關的問題點的績效，或是可以使用多個領域以密切配合組織的經營目標。  

模型差別

編輯 CMMI 模型的前身是 SW-CMM 和 SE-CMM，前者就是我們指的CMM。CMMI與SW-CMM的主要區別就是覆蓋了許多領域；到目前為止包括四個下面領域： （1）軟體工程（SW-CMM） 軟體工程的物件是軟體系統的開發活動，要求實現軟體開發、執行、維護活動系統化、制度化、量化。 （2）系統工程（SE-CMM） 系統工程的物件是全套系統的開發活動，可能包括也可能不包括軟體。系統工程的核心是將客戶的需求、期望和約束條件轉化為產品解決方案，並對解決方案的實現提供全程的支援。 （3）整合的產品和過程開發（IPPD-CMM） 整合的產品和過程開發是指在產品生命週期中，通過所有相關人員的通力合作，採用系統化的程序來更好地滿足客戶的需求、期望和要求。如果專案或企業選擇IPPD程序，則需要選用模型中所有與IPPD相關的實踐。 （4）採購（SS-CMM） 採購的內容適用於那些供應商的行為對專案的成功與否起到關鍵作用的專案。主要內容包括：識別並評價產品的潛在來源、確定需要採購的產品的目標供應商、監控並分析供應商的實施過程、評價供應商提供的工作產品以及對供應協議和供應關係進行適當的調整。 在以上模組中，企業可以選擇軟體工程，或系統工程，也可以都選擇。整合的產品和過程開發和採購主要是配合軟體工程和系統工程的內容使用。例如，純軟體企業可以選擇CMMI中的軟體工程的內容；裝置製造企業可以選擇系統工程和採購；整合的企業可以選擇軟體工程、系統工程和整合的產品和過程開發。CMMI中的大部分內容是適用各不同領域的，但是實施中會有顯著的差別，因此模型中提供了"不同領域應用詳解"。 CMM的基於活動的度量方法和瀑布過程的有次序的、基於活動的管理規範有非常密切的聯絡，更適合瀑布型的開發過程。而CMMI相對CMM更一步支援迭代開發過程和經濟動機推動組織採用基於結果的方法：開發業務案例、構想和原型方案；細化後納入基線結構、可用釋出，最後定為現場版本的釋出。雖然CMMI保留了基於活動的方法，它的確集成了軟體產業內很多現代的最好的實踐，因此它很大程度上淡化了和瀑布思想的聯絡。 在 CMMI 模型中在保留了CMM階段式模式的基礎上，出現了連續式模型，這樣可以幫助一個組織以及這個組織的客戶更加客觀和全面的瞭解它的過程成熟度。同時，連續模型的採用可以給一個組織在進行過程改進的時候帶來更大的自主性，不用再象CMM 中 一樣，受到等級的嚴格限制。這種改進的好處是靈活性和客觀性強，弱點在於由於缺乏指導，一個組織可能缺乏對關鍵過程域之間依賴關係的正確理解而片面的實施過程，造成一些過程成為空中樓閣，缺少其他過程的支撐。兩種表現方式（連續的和階段的）從他們所涵蓋的過程區域上來說並沒有不同，不同的是過程區域的組織方式以及對成熟度（能力）級別的判斷方式。 CMMI 模型中比CMM 進一步強化了對需求的重視。在CMM 中，關於需求只有需求管理這一個關鍵過程域，也就是說，強調對有質量的需求進行管理，而如何獲取需求則沒有提出明確的要求。在CMMI的階段模型中，3 級有一個獨立的關鍵過程域叫做需求開發，提出了對如何獲取優秀的需求的要求和方法。CMMI 模型對工程活動進行了一定的強化。在CMM中，只有3級中的軟體產品工程和同行評審兩個關鍵過程域是與工程過程密切相關的，而在CMMI中，則將需求開發，驗證，確認，技術解決方案，產品整合這些工程過程活動都作為單獨的關鍵過程域進行了要求，從而在實踐上提出了對工程的更高要求和更具體的指導。CMMI中還強調了風險管理。不像在CMM 中把風險的管理分散在專案計劃和專案跟蹤與監控中進行要求，CMMI3級裡單獨提出了一個獨立的關鍵過程域叫做風險管理。  

名詞術語

編輯 1-20 1 AT Assessment Team 評審小組 2 ATM Assessment Team Member 評審小組成員 3 BA Baseline Assessment 基線評審 4 CAR Causal Analysis and Resolution 原因分析與決策 5 CBA CMM-Based Appraisal 基於CMM的評價 6 CBA-IPICMM-Based Appraisal for Internal Process Improvement 為內部過程改進而進行的基於CMM的評價（通常稱為CMM評審） 7 CC Configuration Controller 配置管理員 8 CF Common Feature 公共特性 9 CFPS Certified Function Point Specialist 註冊功能點專家 10 CI Configuration Item 配置項 11 CM Configuration Management 配置管理 12 CMM Capability Maturity Model 能力成熟度模型 13 CMMI Capability Maturity Model Integration 能力成熟度整合模型 14 COTS Commerce off the shelf 商業現貨供應 15 DAR Decision Analysis and Resolution 決策分析與制定 16 DBD Database Design 資料庫設計 17 DD Detailed Design 詳細設計 18 DP Data Provider 資料提供者 19 DR Derived Requirement 派生需求 20 EPG Engineering Process Group 工程過程小組 21-40 21 FP Function Point 功能點 22 FPA Function Point Analysis 功能點分析 23 FR Functional Requirement 功能性需求 24 GA Gap Analysis 差距分析 25 ID Interface Design 介面設計 26 IFPUG International Function Point Users Group 國際功能點使用者組織 27 IPM Integrated Project Management 整合專案管理 28 IR Interface Requirement 介面需求 29 KPA Key Process Area 關鍵過程域 30 KR Key Requirements 關鍵需求 31 LA Lead Assessor 主任評審員 32 MA Measurement and Analysis 測量與分析 33 MAT Metrics Advisory Team 度量諮詢組 34 MCA Metrics Coordinator and Analyst 度量專員 35 ML matreraty library 度量資料庫 36 NFR Non-functional Requirement 非功能性需求 37 OC Operational Concept 操作概念 38 OID Organizational Innovation and Deployment 組織革新與部署 39 OPD Organizational Process definition 組織過程定義 40 OPF Organizational Process focus 組織過程焦點 41-60 41 OPL Organizational Process Assets 組織過程財富 42 OPP Organaizational Process Perormance 組織過程效能 43 OSSP Organization’s Set of Standard Process 組織標準過程集合 44 OT Organizational Training 組織級培訓 45 PA Process Areas 過程域 46 PAT Process Action Team 過程行動小組 47 PAL Process Assets Library 過程財富庫 48 PD Preliminary Design 概要設計 49 PDSP Project Defined Standard Processes 專案定義標準過程 50 PI Produce Integration 產品整合 51 PLC Product Life Cycle產品生命週期 52 PMC Project Monitoring and Control 專案監控 53 PP Project Planning 專案策劃 54 PPQA Process and Product Quality Assurance 過程與產品質量保證 55 PPR Price Performance Ratio 效能價格比 56 SQA Software Quality Assurance軟體質量保證 57 QA Quality Assurance 質量保證 58 QAP Software Quality Assurance Plan 質量保證計劃 59 QPM Quantitative Project Management 量化專案管理 60 RD Requirements Development 需求開發 61-80 61 RM/ReqM Requirements Management 需求管理 62 RSKM Risk Management 風險管理 63 RTM Requirement Traceability Matrix 需求跟蹤矩陣 64 SAM Supplier Agreement Management. 供應協議管理 65 SC Steering Committee 指導委員會 66 SCAMPI Standard CMMI Assessment Method for Process Improvement 過程改進CMMI標準評審方法 67 SCCB Software Configuration Control Board軟體配置管理控制委員會 68 SCM Software Configuration Management 軟體配置管理 69 SDP Software Development Plan 軟體開發計劃 70 SEI Software Engineering Institute (美國)軟體工程學院 71 SEPG Software Engineering Process Group軟體工程過程組 72 SPI Software Process Improvement軟體過程改進 73 SPP Software Project Planning 軟體專案策劃 74 SPTO Software Project Tracking and Oversight 軟體專案跟蹤與監控 75 SR System Requirements 系統需求 76 SRS Software Requirement Specification軟體需求規格 77 SSM Software Subcontract Management 軟體分包管理 78 SSR Software System Requirement 軟體系統需求 79 TS Technical Solution 技術解決方案 80 UC Use Case 用例 81-89 81 UID User Interface Design使用者介面設計 82 VAL Validation 確認 83 VER Verification 驗證 84 WBS Work Breakdown Structure工作分解結構 85 WP Work Products 工作產品 86 Pre-assessment 預評審 87 Baseline 基線 88 Quality Attribute 質量屬性 89 Scenario 場景