引用：http://baike.baidu.com/view/23524.htm
早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是應用于軟體業項目的管理方法，SEI在部分國家和地區開始推廣和試用。随着應用的推廣與模型本身的發展，演繹成為一種被廣泛應用的綜合性模型。
目錄
<dl></dl>
<dd></dd>
<dd>展開</dd>
CMMI是什麼，CMM與CMMI的不同 關鍵字:CMMI,CMMI是什麼,CMM與CMMI的不同
<a href="http://baike.baidu.com/picview/23524/23524/0/34fae6cd7b899e510729d25f42a7d933c9950dd1.html" target="_blank"> </a>
什麼是CMMI？
CMMI是一套融合多學科的、可擴充的産品集合， 其研制的初步動機是為了利用兩個或多個單一學科的模型實作一個組織的內建化過程改進。 CMMI的本質是軟體管理工程的一個部分。軟體過程改善是目前軟體管理工程的核心問題， 50多年來計算機的發展使人們認識到要高效率、高品質和低成本地開發軟體，必須改善軟體生産過程。基于模型的過程改進是指用采用能力模型來指導組織的過程改進，使之過程能力穩定的進行改善，該組織也能變得更加成熟。
CMM的成功促使其他學科也相繼開發類似的過程改進模型，例如系統工程、需求工程、人力資源、內建産品開發、軟體采購等等，從CMM衍生出了一些改善模型，比如：SW－CMM,SE-CMM,IPD-CMM等。不過，在同一個組織中多個過程改進模型的存在可能會引起沖突和混淆。CMMI就是為了解決怎麼保持這些模式之間的協調。
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．VER：（Verification）驗證。驗證確定標明的工作産品滿足需求規格。 14．VAL：（Validation）确認。确認證明産品或産品部件在實際應用下滿足應用要求。 支援管理： 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個流程領域外，增加OPP ：（Organizational Process Preformace）組織過程性能。建立與維護組織過程性能的量化标準，以便使用量化方式的管理項目。QPM（Quantitative Project Management) 量化的項目管理，量化管理項目已定義的項目過程，以達成項目既定的品質和過程性能目标。。
第5級包含第2級到第4級的20個流程領域外，增加，OID：(Organizational Innovation and Deployment）組織的創新與推展，選擇并推展漸進創新的組織過程和技術改善，改善應是可度量的，所選擇及推展的改善需支援基于組織業務目的的品質及過程執行目标。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：軟體測試。
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各個程序的關鍵元素
CMMI自出道以來，它所達到的目标就沒有變過，第一個是品質，第二個是時間表，第三就是要用最低的成本。不過特别強調的是，CMMI不是傳統的、僅局限于軟體開發的生命周期，它應該被運用于更廣泛的一個範疇——工程設計的生命周期。TSP的建立，也是為了支援CMMI的這樣一個系統。那麼CMMI究竟是什麼呢？它并不是一個過程，也不是告訴你怎麼去做一件事情。如果用一句話來概括什麼是CMMI，它就是各個程序的一個關鍵的元素，在很多領域裡面一個內建的點。它是這樣的一個基本架構，能夠用來度量你的有效性和實用性；能夠找出這樣的一些機會，繼續改進的機會，包括在商業目标、政策還有降低項目的風險等方面。
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版本。但是，美國國防部辦公室要求SEI推遲釋出CMM2.0版本，而要先完成一個更為緊迫的項目CMMI。
CMMI分5個級别
CMMILevel 1，完成級。在完成級水準上，企業對項目的目标與要做的努力很清晰，項目的目标得以實作。但是由于任務的完成帶有很大的偶然性，企業無法保證在實施同類項目的時候仍然能夠完成任務。企業在一級上的項目實施對實施人員有很大的依賴性。
CMMILevel 2，管理級。在管理級水準上，企業在項目實施上能夠遵守既定的計劃與流程，有資源準備，權責到人，對相關的項目實施人員有相應的教育訓練，對整個流程有監測與控制，并與上級機關對項目與流程進行審查。企業在二級水準上展現了對項目的一系列的管理程式。這一系列的管理手段排除了企業在一級時完成任務的随機性，保證了企業的所有項目實施都會得到成功。
CMMILevel 3，定義級。在定義級水準上，企業不僅能夠對項目的實施有一整套的管理措施，并保障項目的完成；而且，企業能夠根據自身的特殊情況以及自己的标準流程，将這套管理體系與流程予以制度化這樣，企業不僅能夠在同類的項目上升到成功的實施，在不同類的項目上一樣能夠得到成功的實施。科學的管理成為企業的一種文化，企業的組織财富。
CMMILevel 4，量化管理級。在量化管理級水準上，企業的項目管理不僅形成了一種制度，而且要實作數字化的管理。對管理流程要做到量化與數字化。通過量化技術來實作流程的穩定性，實作管理的精度，降低項目實施在品質上的波動。
CMMILevel 5，優化級。在優化級水準上，企業的項目管理達到了最高的境界。企業不僅能夠通過資訊手段與數字化手段來實作對項目的管理，而且能夠充分利用資訊資料，對企業在項目實施的過程中可能出現的次品予以預防。能夠主動地改善流程，運用新技術，實作流程的優化。 企業在實施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)來衡量流程改進。
系統工程包括整個系統的開發，可能包括軟體也可能不包括。
軟體工程用于軟體系統的開發，主要集中在使用系統的·科學的·量化的方法來開發·運作·維護軟體。
對一個軟體企業來說，達到CMM2就基本上進入了規模開發，基本具備了一個現代化軟體企業的基本架構和方法，具備了承接外包項目的能力。CMM3評估則需要對大軟體內建的把握，包括整體架構的整合。一般來說，通過CMM認證的級别越高，其越容易獲得使用者的信任，在國内、國際市場上的競争力也就越強。是以，是否能夠通過CMM認證也成為國際上衡量軟體企業工程開發能力的一個重要标志。
軟體過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，成功取決于個人努力。管理是反應式的。
分析對軟體過程和産品品質的詳細度量資料，對軟體過程和産品都有定量的了解與控制。管理有一個作出結論的客觀依據，管理能夠在定量的範圍内預測性能。
過程的量化回報和先進的新思想、新技術促使過程持續不斷改進。
每個等級都有幾個過程區域組成，這幾個過程域共同形成一種軟體過程能力。每個過程域，都有一些特殊目标和通用目标，通過相應的特殊實踐和通用實踐來實作這些目标。當一個過程域的所有特殊實踐和通用實踐都按要求得到實施，就能實作該過程域的目标。
能力度等級：屬于連續式表述，共有六個能力度等級(0~5)，每個能力度等級對應到一個一般目标，以及一組一般執行方法和特定方法。
0 不完整級
1 已執行級
2 已管理級
3 已定義級
4 量化管理級
5 最佳化級
自我評估：用于本企業上司層評價公司自身的軟體能力。
主任評估：使本企業上司層評價公司自身的軟體能力，向外宣布自己企業的軟體能力
CMMI的評估類型：
軟體組織的關于具體的軟體過程能力的評估。
軟體組織整體軟體能力的評估（軟體能力成熟度等級評估）。
1、解決軟體項目過程改進難度增大問題
2、實作軟體工程的并行與多學科組合
3、實作過程改進的最佳效益
CMM的成功促使其他學科也相繼開發類似的過程改進模型，例如系統工程、需求工程、
為了以示差別，國内外很多資料把CMM叫做SW-CMM。按照SEI原來的計劃，CMM的改進版本2.0應該在1997年11月完成，然後在取得版本2.0得實踐回報意見之後，在1999年完成準CMM2.0版本。
它兼收了SW-CMM 2.0版C稿草案和SPA中更合理、更科學和更周密的優點。SEI在發表CMMI-SE/SW 1.0版時，宣布大約用兩年的時間完成從CMM到CMMI的過渡。
CMMI項目更為工業界和政府部門提供了一個內建的産品集，其主要目的是消除不同模型之間的不一緻和重複，降低基于模型改善的成本。CMMI将以更加系統和一緻的架構來指導組織改善軟體過程，提高産品和服務的開發、擷取和維護能力。
由業界、美國政府和卡内基·梅隆大學軟體工程研究所率先倡導的能力成熟度模型內建（CMMI）項目緻力于幫助企業緩解這種困境。CMMI為改進一個組織的各種過程提供了一個單一的內建化架構，新的內建模型架構消除了各個模型的不一緻性，減少了模型間的重複，增加透明度和了解，建立了一個自動的、可擴充的架構。因而能夠從總體上改進組織的品質和效率。CMMI主要關注點就是成本效益、明确重點、過程集中和靈活性四個方面。
與原有的能力成熟度模型類似，CMMI也包括了在不同領域建立有效過程的必要元素，反映了業界普遍認可的"最佳"實踐；專業領域覆寫軟體工程、系統工程、內建産品開發和系統采購。在此前提下，CMMI為企業的過程建構和改進提供了指導和架構作用；同時為企業評審自己的過程提供了可參照的行業基準。
軟體能力成熟度模型2.0版，C稿；電子行業協會臨時标準（EIA/IS）731；內建産品開發能力成熟度模型（IPD-CMM）v0.98。
（1）、強調高層管理者的支援。過程改進往往也是由高層管理者認識和提出的，大力度的、一緻的支援是過程改進的關鍵。
（2）、 仔細确定改進目标，首先應該對給定時間内的所能完成的改進目标進行正确的估計和定義并制定計劃。選擇能夠達到的目标和能夠看到對組織的效益。
（3）、 選擇最佳實踐，應該基于組織現有的軟體活動和過程财富，參考其他标準模型，取其精華去其糟粕，得到新的實踐活動模型。
（4）、 過程改進要與組織的商務目标一緻，與發展戰略緊密結合。
（1）、 為提高組織過程和管理産品開發、釋出和維護能力提供保障。
（2）、 幫助組織客觀評價自身能力成熟度和過程域能力，為過程改進建立優先級以及執行過程改進。
（1）、決定哪個CMMI模型等級最适合組織過程改進需要。
（2）、 選擇模型的表示法是連續式還是階段式。
（3）、 決定組織需要用到的模型中的知識領域。
（4）、 類似CMM提出的過程改進6步，內建化過程改進分成：開始內建過程改進,建造內建改善平台，內建傳統過程，啟動新過程，進行改進評估。
CMMI内容分為“Required”（必需的）、“Expected”（期望的）、“Informative”（提供資訊的）三個級别，來衡量模型包括的品質重要性和作用。最重要的是"要求"級别，是模型和過程改進的基礎。第二級别"期望"在過程改進中起到主要作用，但是某些情況不是必須的可能不會出現在成功的組織模型中。 "提供的資訊"構成了模型的主要部分，為過程改進提供了有用的指導，在許多情況下他們對"必需"和"期望"的構件做了進一步說明。
"期望"的構件是方法，代表了達到目标的實踐手段和補充認識。每個方法都能映射到一個目标上，當一個方法對一個目标是唯一就是"特定方法"；而能适用于所有目标時就是"公用方法"。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 模型的前身是 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級裡單獨提出了一個獨立的關鍵過程域叫做風險管理。
CMMI模型是建立在CMM模型基礎之上，CMMI的基礎源模型包括：軟體CMM 2.0版，EIA-731系統工程，以及IPD CMM (IPD) 0.98a版。CMMI相對于CMM模型具有更好的可擴充性，通過學科（軟體工程、系統工程、內建化産品和過程開發以及供應商管理）進行模型的擴充，組合形成各種CMMI模型，如CMMI-SW、CMMI-SE/SW、CMMI-SE/SW/IPPD、CMMI-SE/SW/IPPD/SS。
在CMMI 1.2版本中，CMMI-SE/SW模型被CMMI-DEV所取代。以後，還會通過增加新的學科領域擴充形成新的模型，如SEI 計劃釋出的CMMI-SVC模型和CMMI-ACQ模型。
在CMM中，該模型隻有一種表示法，即階段式表示法。CMM的階段式表示法将軟體組織的成熟度劃分為5個等級。在CMMI中，該模型采用了兩種表示法：階段式表示法和連續式表示法。為了保持軟體組織之間的能力成熟度比較，CMMI保留了CMM中的階段式表示法。但是，為了促進軟體組織更加切合實際地進行内部軟體過程改進，CMMI增加了連續式表示法。
CMM有18個關鍵過程域（Key Process Area，KPA），用于促進軟體過程的改進。在CMMI中删去了“關鍵”，而僅稱“過程域”。
CMM中的度量分析實踐分布在每個關鍵過程域中，而CMMI增加了度量分析（MA）過程域。
CMM第3級中的軟體産品工程（SPE）關鍵過程域，在CMMI 中被分為需求開發（RD ）、技術解決（TS）、産品內建（PI）、驗證（VER）和确認（VAL）5個過程域。
CMM第3級的同行評審（PR）關鍵過程域被融入到CMMI的驗證（VER）過程域。
CMM第3級的內建軟體管理（ISM）關鍵過程域所闡述的風險管理，在CMMI中形成了一個獨立的風險管理（RSKM）過程域。同時CMM第3級的內建軟體管理（ISM）群組間協調（IC）合并成為CMMI的內建化項目管理（IPM）。
CMMI第3級增加了決策分析和解決方案（DAR）過程域，其内容在CMM 中沒有提及。
CMM第4級的定量過程管理（QPM）和軟體品質管理（SQM）轉變為CMMI的定量項目管理（QPM）群組織過程績效（OPP）。
CMM第5級的缺陷預防（DP）轉變為CMMI的原因分析和解決方案（CAR）。CMM第5級的技術變革管理（TCM）和過程變更管理（PCM）合并為CMMI的組織革新與部署(OID)。
CMM的評估方法有二種，一種是CBA-SCE（CMM-Based Appraisal for Software Capability Estimation），它是基于CMM對組織的軟體能力進行評估，是由組織外部的評估小組對該組織的軟體能力進行的評估。另一種是CBA-IPI（CMM-Based Appraisal for Internal Process Improvement），它是基于CMM對内部的過程改進進行的評估，是由組織内部的小組對軟體組織本身進行評估以改進品質，評估結果歸組織所有。這兩種評估均由SEI授權的主任評估師上司，參考CMM架構來進行，都要審查正在使用和将來使用的檔案/文檔，并對不同的組織員工進行采訪。
CMMI的評估方法隻有一種，即SCAMPI（Standard CMMI Appraisal Method for Process Improvement）評估方法。SCAMPI評估方法包括了A、B和C三種不同的級别。隻有SCAMPI-A評估，才需要由SEI授權的主任評估師上司。
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-IPI
CMM-Based Appraisal for Internal Process
Improvement
為内部過程改進而進行的基于CMM的評價（通常
稱為CMM評審）
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 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 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 産品內建
52 PMC Project Monitoring and Control 項目監控
53 PP Project Planning 項目策劃
54 PPQA Process and Product Quality Assurance 過程與産品品質保證
55 PPR Price Performance Ratio 性能價格比
57 QA Quality Assurance 品質保證
58 QAP Software Quality Assurance Plan 品質保證計劃
59 QPM Quantitative Project Management 量化項目管理
60 RD Requirements Development 需求開發
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标準評審方法
68 SCM Software Configuration Management 軟體配置管理
69 SDP Software Development Plan 軟體開發計劃
70 SEI Software Engineering Institute (美國)軟體工程學院
73 SPP Software Project Planning 軟體項目策劃
74 SPTO Software Project Tracking and Oversight 軟體項目跟蹤與監控
75 SR System Requirements 系統需求
77 SSM Software Subcontract Management 軟體分包管理
78 SSR Software System Requirement 軟體系統需求
79 TS Technical Solution 技術解決方案
80 UC Use Case 用例
82 VAL Validation 确認
83 VER Verification 驗證
85 WP Work Products 工作産品
86 Pre-assessment 預評審
87 Baseline 基線
88 Quality Attribute 品質屬性
89 Scenario 場景
現在很多企業因某種原因想做CMMI了，大體做法
1、決定實施CMMI
2、EPG接受教育訓練，了解CMMI
3、EPG根據自己了解的CMMI和實際情況開發一大堆漂漂亮亮的過程文檔、流程圖、表格、模闆、檢查單、作業指南。
4、大家邊聽着EPG的解釋(包括教育訓練、答疑)，邊執行這些過程标準，然後審計(内、外)
将目前的最佳實踐記錄下來、寫下來、文檔化下來。
很多新的EPG在做了一段時間後無奈的發現自己居然淪落成了一個過程标準解說員、甚至文檔管理者。自己工作大部分時間是面對文檔，或者督促别人寫文檔
EPG最主要的工作應該深入到研發第一線，幫助研發人員解決研發過程中面臨的最嚴重的實際問題(當然是解決方案要上升到過程高度，而不應是單個問題或個人)，甚至哪怕是一些不嚴重但以你的項目經驗知道該如何解決的問題上。總體說來就是掌握項目進展中的任何細微的技術難點要點，并主動記錄下來。
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網站向全球釋出企業資訊。
<dt>參考資料</dt>
<dt>擴充閱讀：</dt>
1
企業在實施CMMI的時候，路要一步一步地走。一般地講，應該先從二級入手。在管理上下功夫。争取最終實作CMMI的第五級。
<dt>開放分類：</dt>
<dt></dt>
<a href="http://baike.baidu.com/view/8110.htm?func=retitle" target="_blank">CMM</a>
![項目品質管理-知識領域[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)