CMMI全稱是Capability Maturity Model Integration，即能力成熟度模型集成（也有稱為：軟體能力成熟度集成模型），是美國國防部的一個構想，1994年由美國國防部（United States Department of Defense）與卡內基-梅隆大學（Carnegie-Mellon University）下的軟體工程研究中心（Software Engineering Institute，SEISM）以及美國國防工業協會（National Defense Industrial Association）共同開發和研製的，他們計畫把現在所有現存實施的與即將被發展出來的各種能力成熟度模型，集成到一個框架中去，申請此認證的前提條件是該企業具有有效的軟體企業認定證書。
其目的是幫助軟體企業對軟體工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟體。其所依據的想法是：只要集中精力持續努力去建立有效的軟體工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟體開發中的困難。CMMI為改進一個組織的各種過程提供了一個單一的集成化框架，新的集成模型框架消除了各個模型的不一致性，減少了模型間的重複，增加透明度和理解，建立了一個自動的、可擴展的框架。因而能夠從總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。
基本介紹
- 中文名：軟體能力成熟度集成模型
- 外文名：Capability Maturity Model Integration
- 簡稱：CMMI
- 別名：軟體能力成熟度模型集成
版本介紹,過程域,過程管理,項目管理,工程管理,支持管理,發展歷史,CMMI的起源,發展簡介,研發背景,關鍵元素,評估,預備工作,評估方法,項目管理,等級,實施要點,基本思想,源模型,原則,目標,方法,內容,工具,人員素質,實施流程,模型差別,名詞術語,CMMI的價值,區別,
版本介紹
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：風險管理。
一、過程管理：
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：量化的項目管理 。
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：因果分析與解決方案。
21. OPM：組織績效與管理。
22. CAR：因果分析與解決方案。
CMMI模型表述階段式：
1、階段式表述提供系統化與結構化的方式，一次一個階段達到以模型為基礎的過程改進。達成每一個階段可確保有足夠的過程基礎建設，可作為下一個階段過程改進的基礎。
2、連續式：連續式表述可提供最大的彈性。一個組織可以選擇改進單一過程相關的問題點的績效，或是可以使用多個領域以密切配合組織的經營目標。
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 場景
CMMI的價值
CMMI為企業帶來價值主要體現在以下幾個方面：
第一、能保證軟體開發的質量與進度，能對“雜亂無章、無序管理”的項目開發過程進行規範。
第二、有利於成本控制。因為質量有所保證，浪費在修改、解決客戶的抱怨方面的成本會降低很多。絕大多數情況是缺少規範制度，只是求快。項目完成後，要花很多時間修修補補，費用很容易失控。
第三、有助於提高軟體開發者的職業素養。每一個具體參與其中的員工，無論是項目經理，還是工程師，甚至一些高層管理人的做事方法逐漸變得標準化、規範化。
第四、能夠解決人員流動所帶來的問題。公司通過過程改進，建立了財富庫以共享經驗， 而不是單純依靠某些人員。
第五、有利於提升公司和員工績效管理水平，以持續改進效益。通過度量和分析開發過程和產品，建立公司的效率指標。
第一、能保證軟體開發的質量與進度，能對“雜亂無章、無序管理”的項目開發過程進行規範。
第二、有利於成本控制。因為質量有所保證，浪費在修改、解決客戶的抱怨方面的成本會降低很多。絕大多數情況是缺少規範制度，只是求快。項目完成後，要花很多時間修修補補，費用很容易失控。
第三、有助於提高軟體開發者的職業素養。每一個具體參與其中的員工，無論是項目經理，還是工程師，甚至一些高層管理人的做事方法逐漸變得標準化、規範化。
第四、能夠解決人員流動所帶來的問題。公司通過過程改進，建立了財富庫以共享經驗， 而不是單純依靠某些人員。
第五、有利於提升公司和員工績效管理水平，以持續改進效益。通過度量和分析開發過程和產品，建立公司的效率指標。
區別
很多初識CMMI評估的朋友都搞不清CMMI證書到底是哪裡管理，是由哪個機構頒發的，什麼樣的證書才是正宗的，會不會有假證書，是不是也跟ISO一樣都是由認證機構頒發的等等一系列的疑問。
先說ISO的管理辦法：接觸過ISO9001認證的朋友都知道，ISO9001是國際標準，企業可以根據自己的認可需求選擇合適的認證機構，比如CQC，BSI，DNV等等這樣的認證機構審核發證，而這些認證機構同時受到國家或國際等組織的監管，比如說認可機構的監管，在中國的認可機構就是CNAS，在英國的就是UKAS，美國的ANAB。就是說，企業的ISO9001證書要從認證機構發出來，而認證機構要得到認可機構的授權，這是國際通用的管理辦法。另外說一下，而在中國的認可機構及在中國審核發證的國內外認證機構又是受政府監管如CNCA。就我們國家而言，你要得到一張有效的ISO證書，是要通過CNCA授權的國內外認證機構才可以審核並發證書。
CMMI評估，也有人稱是CMMI認證，“認證”是國內的叫法習慣。要獲得正宗的CMMI證書，是要經過主任評估師對企業的軟體項目評估通過後才會頒發證書，這裡要強調的是，發證書是以主任評估師的個人名義簽發的，並不是由認證機構發的。而主任評估師是通過自己的努力參考SEI（ Software Engineering Institute）的考試才獲得資質的，有資質的主任評估師到企業去評估，評估結果符合SEI的要求才會把評估報告提交到SEI，SEI審核完評估報告後，才表明企業最終獲得了有效的CMMI證書，SEI會把評估結果公布在SEI網站上供用戶查詢。因此，SEI是管理CMMI證書的唯一機構，SEI授權給評估師去開展評估工作。這裡要說明一下，SEI本身是沒有證書這個概念的，他只有註冊這個概念，就是說，證書在中國才有這樣的做法，對於SEI來說，SEI沒有統一印發證書。
