凡是有軟件開發主營業務的企業，我相信都應該聽過CMMI(能力成熟度模型集成)，但是很多企業對于這一塊，理解的意思只是用來招投標需要的一個認證，而且認為它很貴。

　　是的，以上的兩個都是大多數軟件開發企業都認同的，如果沒有需要招投標，誰又會去做又麻煩，又貴的一個認證呢?

　　就來談談什么是CMMI，盡量用最直白的語言來告訴各位什么是“能力成熟度模型集成”

慧捷科技股份通過CMMI3認證評估并獲取證書

什么是CMMI能力成熟度模型集成

CMM軟件過程改進前常見問題解答

CMM實施中的戰略問題

CMM與CMMI的區別

CMMI評估流程

CMMI目標和實踐匯總

CMMI V1.3

什么是CMMI能力成熟度模型集成　
CMMI能力成熟度模型集成
  CMMI全稱是Capability Maturity Model Integration，即能力成熟度模型集成（也有稱為：軟件能力成熟度集成模型），是美國國防部的一個設想，1994年由美國國防部與卡內基-梅隆大學下的軟件工程研究中心（Software Engineering Institute，SEISM）以及美國國防工業協會共同開發和研制的。其目的是幫助軟件企業對軟件工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟件。 。
自從1994年SEI正式發布軟件CMM以來，

CMM軟件過程改進前常見問題解答
隨著國務院第18號文件明確鼓勵軟件進出口型企業通過國際質量方面的認證，并在省市政府、科委以及軟件園發布鼓勵政策的大力配合下，越來越多的企業希望改進軟件過程來提高企業的競爭力。雖然很多軟件企業得到了ISO 9000質量認證，但ISO 9000不是專門為軟件企業設計的，因此有些地方不能真正為軟件企業解決問題。最近，越來越多的軟件企業希望通過實施基于CMM的軟件過程改進提高自身競爭力，原因就是CMM是專門為軟件企業設計的。軟件企業的國際化進程也隨之加快，一些大型軟件企業完成CMM認證的同時，也為相當多的中小軟件企業帶來了希望，但他們在實施CMM的過程中，特別是在向CMM2前進時往往存在很多困惑和疑問。
那么什么是CMM呢？
CMM是指“軟件能力成熟度模型”，其英文全稱為Capability Maturity Model for Software，英文縮寫為SW-CMM，簡稱CMM。CMM的定義是：對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述。CMM的核心是把軟件開發視為一個過程，并根據這一原則對軟件開發和維護進行過程監控和研究，以使其更加科學化、標準化、使企業能夠更好地實現商業目標。CMM分成了5個成熟度級別，其中任何軟件企業都可以認為是成熟度級別為1級的組織。換句話說，1級的企業在軟件過程方面有很多問題。隨著成熟度級別的升高，企業的軟件過程能力越強。
但是，俗話說：“萬事開頭難”。對于很多企業的決策層，在啟動CMM改進項目以前，特別是向CMM 2級前進的時候，往往會有各種各樣的問題和困惑，也會有各式各樣的錯誤理解。比如：在CMM實施前和過程中經常會出現什么問題？這些問題應該怎么面對和解決？在CMM的實施過程中應該有一個什么心態等等。這些問題在下面的文章中您都可以找到答案。我將對一些CMM實施過程中最常見的、決策層最關心的問題給出一些觀點、解釋和建議，希望能夠通過這篇文章使大家對CMM的認識再上一個臺階，對今后想實施CMM的企業有一個初步的指導。
關于實施時間
Q：我們公司已經決定按照CMM 2級的要求實施過程改進，最快需要多久達到2級的水平？
A：這個問題就像一個病人充滿希望地向醫生詢問：“你看我的病什么時候能好？”。雖然這是很多準備實施CMM的企業非常關心的一個問題，但是這個問題讓任何人都會感到很難回答。這是因為過程改進所需要的時間與很多因素有密切關系，特別表現在以下方面：
★ 企業決定進行軟件過程改進的目標和商業需要（如：改善軟件開發管理；提高軟件產品質量；降低軟件開發工作成本；提高企業在業界的知名度和信譽等）：不同的目標需要不同的工作方向去實現，改進的難度也不同，必然會影響時間進度。
★ 企業當前的過程情況：一個企業如果在軟件開發過程方面已經比較規范，很多過程均已得到了良好的定義，并形成了文檔，質量保證體系也很完善，則達到CMM 2級的要求應該容易一些，相對來說改進的時間也能夠短一些。
★ 企業實施的范圍：一個企業的哪些部門實施基于CMM的過程改進，或者說涉及過程改進的人員有多少，會影響時間進度。可以說，實施的范圍越小、涉及的人員越少，實施越簡單，時間越短。
★ 企業的文化：對于一個存在多年的企業，變化對它來說可能是非常困難的；一個企業是否愿意主動去接受變化，很大程度上將影響過程改進的難度和進度。通常情況下，一個剛成立不久的公司，實施過程改進的阻力要小得多，這就是“船小好掉頭”的道理。
★ 將來要作為試點項目的周期：一般情況下，我們建議一個按照CMM 2級實施過程改進的企業選擇3~5個生命周期比較完整的軟件開發或維護類型的項目作為試點項目并參加CMM的評估。這些項目可以并發進行，但通常我們希望能有2個左右的項目能夠在評估的時候達到試運行或正式交付的階段。如果企業選取的項目周期都在一年以上，這也會影響進入評估的時間。
★ 10個月左右的時間比較常見：根據SEI官方發布的統計報告（截止到2002年8月份），從大多數進行評估的組織情況來看，組織從1級向2級改進通常需要23個月左右，我們可以通過下面這個圖表來了解各個向高級別演進所需要的時間。大家不要被這個接近兩年的時間嚇壞了，這樣的平均時間主要是因為大多數國外實施CMM的公司規模都比較大，項目周期也相對比較長。國內大多數軟件企業的規模都不大，加上咨詢公司的幫助，用10個月左右的時間達到CMM 2級要求還是比較常見的。
★ 實施時間上能不能再短一點呢？任何一個夠資格的SEI授權主任評估師都遵從一個原則，一個組織中的過程在定義、形成文檔并發布之后，需要一個至少六個月的穩定運行期。因此，可以說一個組織在實施按照CMM 2級要求的過程改進時，至少需要8個月左右的時間（2個月過程以及文檔化加上6個月的穩定運行期）。除非有專業人員深入了解企業現狀，可能會根據實際情況作少量調整。 （待續）
下期預知：
提示軟件企業在資源投入方面應做的準備：人員、崗位及設備工具。 

關于評估范圍
Q：我們將來需要什么樣的項目參加評估比較合適？
A：這必須慎重，否則可能會對評估結果、實施效果及企業獲益影響很大。原則上說，CMM 2級評估沒有對試點項目做出什么特別的要求。一般只要是生命周期比較完整，項目組成員人數在5~10人，周期在3~6個月的項目均可，當然這也不是一定的。
對于很多企業來說，通常會有兩類項目，即自主研發的產品類項目和基于客戶具體需求的工程類項目。究竟使用哪類項目進行試點，是很多企業決策者爭論和考慮的地方。這兩類項目在作為試點項目方面各自的優勢可見表1：
顯然，產品類項目風險比較小，可控度比較高；然而，工程類項目往往是最容易管理混亂的。因此，把工程類項目作為試點項目企業收益會更高。有一家公司就曾經懷著嘗試的態度在兩個金融領域的工程類項目中進行CMM試點，這兩個項目的客戶都是銀行相關業務科室的人員。令他們非常意外的是，當他們告訴客戶正在做CMM改進時，客戶顯示出了非常濃厚的興趣。對于參加需求規格說明書評審會這樣的CMM建議的活動，他們也積極配合；質量保證方面，客戶還專門派了一個人配合。到了項目驗收的時候，客戶在驗收單上簽字的工作比他們歷次任何一個項目都順利，因為客戶在項目開發的整個過程中很清楚地了解項目的進展和問題，并且對于項目的結果有很強的信心。這家公司的高層經理，也因為客戶滿意度非常高而認識到了過程改進的好處，并決心加大這方面投入的力度。相反，有些公司為了減少過程改進的實施難度，用產品研發類項目作試點，結果現在大家抱怨因為管理產生的工作量太多了而產生抵觸情緒，反而影響了實施效果。
我們一般還建議選擇生命周期比較完整的項目作試點，這是因為：在CMM 2級的配置管理KPA中，有些要求是關于測試和產品構建的，如果沒有一個試點項目在評估的時候能夠進入集成測試或者產品發布這樣的產品開發后期階段，就有可能因為找不到評估證據而被主任評估師要求延期評估。所以，如果一家企業選擇了多個項目作為試點的話，可以不必所有的項目都能夠非常完整的到達后期階段，有1~2個項目即可。
對于試點項目的規模，特別是人數，應注意這樣一個問題：如果一個企業希望在整個公司內實施CMM并進行評估的話，那么每個和軟件開發、維護相關的部門都應有半數以上的人參與試點項目。對于不打算在整個公司范圍實施的企業，大量實際情況表明，5~10人規模的中小項目在實施效果和難度方面都是值得推薦的。
目前對于大多數國內的軟件開發項目來說，還是3~6個月的最多。為期6個月的項目剛好可以滿足6個月的過程穩定期，在這個基礎上時間長點、短點問題都不大。至于說項目開發地點是否在公司本地，其實影響不大。而項目經理是否能夠認同過程改進的價值，高層經理能否真正保證項目組有足夠的資源來實施新的過程，也應是此時考慮的一個重點問題。
Q：既然CMM 2級是項目級別的，我們用一個規模很小的項目去實施過程改進，并參加評估，豈不是很容易？
A：選擇小規模的項目作為試點在理論上是可以的，因為SEI并沒有規定這樣做不允許，但我們強烈建議大家不要這樣去做。規模小的項目溝通方便、風險小，是否需要按照CMM的要求和建議去管理應該根據具體情況去分析。如果一個1、2個人月工作量的項目要花費大量精力去形成管理文檔，會讓人覺得是一種罪惡。曾經有一家公司，希望在該公司一個部門實施CMM，但該部門絕大多數項目都是基于一個已經很成熟的核心產品，只需根據客戶定制的一部分額外需求進行開發，因此開發工作量很小。而對于該部門來說，在客戶現場將老系統切換成為新系統，并保證新系統能夠穩定運行倒是非常重要。雖然這方面的工作每次只需要一、二人，二周時間就足夠了，而且有關人員因為對這方面業務非常熟悉，項目失敗的風險并不大，項目組也不會留下什么文檔，但他們希望能夠通過過程改進加強這類項目的管理，減少人員流動為該部門帶來的損失。但是，這個公司定義出來的過程文檔主要是用于開發類型的項目，而他們又沒有足夠的數據對過程進行分析和裁剪，結果造成幾乎管理工作量比工程活動工作量還要多，項目組有關人員均對這套過程表示了懷疑，并開始對過程改進活動產生抵觸情緒。
關于試點項目的數量，一般來說1個是不夠的。有的主任評估師認為CMM 2級的特點是repeatable，即可重復的，就需要一套成文的過程應該在至少2個項目中使用。如果一個項目規模很大（100人以上），周期很長（2年以上），通常被拆分成若干個子項目進行開發，并且能夠充分的體現實施CMM的有關證據，那么可以允許僅有1個項目參加評估。如果是一般規模或規模較小的項目，一定是不允許的。
規模小、數量少確實可減少實施難度，但企業如為了真正實現商業目標，通過改進獲益，他們是不會這樣做的。
Q：我們可不可以只在公司下面的某一個部門實施CMM，以便減少實施的難度？
A：可以，因為CMM中“組織”一詞，它既可以代表一家完整的公司，也可以代表一個或多個部門。因此，即使在評估CMM 5級的時候，也可以只對某一個部門進行。CMM 2級是面向項目級別的，實施的時候這方面靈活性更大。不過主任評估師向SEI提交評估結果時會明確寫明評估是在企業的什么范圍內進行的（多少部門納入評估范圍，參與的軟件開發人員和管理人員的數量等）。現在很多企業宣傳時，有意無意掩蓋了這一點，只是泛泛說：XX公司已經達到了CMM 2級的要求，久而久之造成了很多錯誤的認識。不過，如果企業希望通過過程改進真正獲益的話，最好還是能夠在整個企業中所有與軟件活動有關的部門實施。
雖然2級是面向項目級別的，但我們非常歡迎和支持在整個公司的范圍內實施CMM 2級。這樣，公司積累大量不同項目的寶貴經驗，有利于向3級邁進。
我個人認為，如果一家公司希望能夠成為CMM 3級的公司的話，如果在2級的階段投入比較多，實施的效果比較好，那么3級的實施難度會下降很多；反之，3級的實施難度會增加；因此可以說，一個公司在從1級到3級這個過程中所投入的資源總數基本上是一個固定值。既然如此，為什么不早一點把工作做到實處，早一點獲得成效呢？
關于評估方法
Q：CMM的評估方法是怎樣的？
A：基于CMM的正式評估有一個專用的名稱：CBA IPI（CMM Based Appraisal for Internal Process Improvement - 用于內部過程改進的基于CMM的評估）。如果用一句話來介紹這種評估活動的話，可以這樣說：它是通過抽取一個組織中的采樣數據和信息，通過文檔審閱、同組織中各個不同角色的人員以訪談、討論的形式獲取數據和信息，對這些收集到的信息進行整合、分析、確認，形成最終的結果。正式評估之前的一段時間，通常還會組織預評估（Pre-assessment），絕大多數SEI授權的主任評估師都會采用迷你評估（Mini-assessment）的方式。
下面詳細一點地介紹這套評估方法。評估過程中的活動可以分成2大類：前現場活動（Pre-On-Site Activities）和現場活動（On-Site Activities）。
☆ 評估小組：每次評估的時候都需要有一個評估小組，人數大約是4~8人。其中組長由SEI授權的主任評估師擔任。對于級別高（如4級或5級）的評估，往往需要2個主任評估師。其他的人員多數來自被評估的公司內部，這主要是希望評估結果能夠更容易被公司大多數人接受。至于說這些人是否能夠在評估中保持客觀性是至關重要的，這個方面可以由主任評估師來保證。另外，評估小組成員的知識技能背景會對評估結果產生顯著的影響，因此要求評估小組成員熟悉CMM。
☆ 前現場活動：前現場活動實際上也是在現場完成的，只不過更多的是在正式評估開始前要完成的工作，一般是在預評估最后的時候完成，主要包括識別評估范圍、制定評估計劃、填寫成熟度問卷等。其中識別評估范圍非常重要，這項工作主要分為2個方面：一是在公司的什么范圍進行這次評估，是整個公司還是其中某些部門？二是這次評估評的是CMM幾級？要知道，如果是2級的，那么對于3級和更高級別的KPA根本不予考慮。不存在這種可能：我們先在整個公司范圍進行評估，如果發現某些部門做得不好，就從評估范圍中剔除，退一步可以評幾個部門的。在正式評估的時候，評估范圍是不允許調整的。成熟度問卷是SEI提供的標準問卷，但它并不被看成是一個重要的工作，因為該問卷基本上就是把模型中的要求用陳述句換成了一般疑問句，幾乎所有答卷人都能夠判斷出來填“是”會比其他的選項要好，于是這份問卷更多地變成了一種形式。唯一被認為有價值的東西是問卷中每個問題后面可能填寫的補充或注釋。
☆ 現場活動：現場活動遵循SEI要求的標準流程執行，如圖2所示：
其中，重點是訪談和評級過程。訪談是整個評估工作中非常重要的一個數據來源。參與訪談的人員一般分為3種類型：項目經理、中（高）層經理以及功能區域代表。中（高）層經理直接聽取項目經理匯報項目情況，他們可以在項目組出現無法解決的問題時負責協調和處理。功能區域代表是具體的實踐人員的代表，包括系統分析設計人員、編碼人員、測試人員、配置管理員以及質量保證人員等。對于項目經理，需要進行單獨的訪談，會根據評估要考察KPA一一提出問題，每個人平均約有1~2個小時的時間。中（高）層經理和功能區域代表分成組來參加訪談，回答相應的問題。評估小組的成員在訪談過程中會做筆記，參加訪談的人員基本上就是根據自己親身經歷如實介紹情況即可，因此回答是沒有標準答案的。不過很多參加訪談的人員會感到非常緊張，特別是單獨接受提問的項目經理們，曾經有的項目經理正在回答一個問題的時候，說著說著突然停下來問：“你剛才問的問題是什么來著？”其實大可不必，因為評估小組會嚴守保密性的原則，在評估工作結束后還會銷毀所有的紀錄。每天訪談工作結束之后，評估小組整理和分析，和CMM的每條關鍵實踐分別對應，寫出結論（這樣的結論性語句稱為“觀察項”）。
在所有的評估活動中，大家最關心的恐怕就是評估的結果是如何確定的了。其實有了評估時前面數天的成果，最終的結論是很容易做出的。評估小組根據作出的一條條觀察項，逐條檢查用詞是否合理恰當，是否得到了多個數據來源的反復確證，是否有不同觀察項之間存在矛盾的情況。如果這些觀察項都得到了檢查并被確認無誤，評估小組會對找到的不足之處（發現的弱點）進行分析，看是否對KPA下面的目標實現有顯著的影響。評級的思路可以參見圖3： 在CMM中，每個KPA下面都有若干個目標，并有數條關鍵實踐與目標對應。如果一個目標對應的關鍵實踐沒有明顯的弱點阻礙該目標的實現，則認為該目標得到了滿足。如果一個關鍵過程區域下面的所有目標都滿足了，則該KPA也就是滿足的。當某個成熟度級別之下所有的KPA都是滿足的，則被評估的公司成熟度級別就是此級別。這句話必須要正確的理解：一方面，如果一家公司希望成為CMM 3級的組織，則必須在評估中把2級和3級包含的所有關鍵過程區域都做到滿足才能實現這一目標。另外，即便某家公司已經在正式評估中達到了2級的要求，一段時間后該公司希望進行3級的評估，2級的內容同樣要在評估中檢查。另一方面，舉個極端的例子來說，如果一家公司做3級的評估，評估結果是3級的所有KPA均得到了滿足，但2級中如果有不滿足的KPA，則該公司的成熟度級別為1級。雖然這情況幾乎不可能出現，因為如果該公司2級有做得不好的KPA，3級的KPA幾乎不可能全都做得很好。圖4是比較常見的一種情況，因為2級中有沒有做好的KPA，雖然是做3級的評估，但結果是1級：
◆ 預評估與正式評估的區別：參照上期圖2，預評估（即迷你評估）主要的區別在從第六步之后的內容簡化成了一步：預評估結果展示。預評估通常作4天左右，檢查的樣本數據會比正式評估時少一些。還有一點非常重要的區別是：預評估時不評級，結果中不會提及當前組織的CMM成熟度級別的情況，但對于所有KPA下的目標，都會給出一個1-10分之間的分數。不同的分值代表的意思是：
▲1-3分：不滿足
▲4-6分：部分滿足
▲7分：基本滿足，但有少許不足
▲8分：滿足
▲9分：非常出色
▲10分：世界級的實踐，非常完美
如果所有被評的KPA的目標都是7分或8分的話，可以說正式評估的結果極有可能是比較樂觀的。但如果有目標還在3分或4分附近徘徊的話，那可能就需要再經過幾個月的時間努力改進，否則正式評估很有可能會得到失敗的結果。
Q： ISO9000質量體系認證定期需要復審，CMM是否也是這樣？
A： ISO9000質量體系認證一般每年都需要復審，但CMM是不需要的。因為CMM的評估主要目的是找出與被評估企業的軟件過程相關的問題，從而使該企業針對這些發現的問題進行企業內部的自發的改進。因此SEI強調CMM評估不是一種認證，SEI也從來沒有向任何一家組織發過這樣的證書。既然不是認證，就不必進行復審，無論評估的結果是好是壞。目前國內企業在評估之后得到的證書格式都不是統一和標準的，但SEI授權的主任評估師會在證書上簽字，并把評估結果發送到SEI的數據庫中。

有關ISO與CMM的比較
Q：我們已經拿到了ISO9000的質量體系認證，這對實施CMM有什么影響？
A： 國內軟件公司采用的ISO 9000系列質量體系認證通常有ISO9001的1994年版和2000年版。ISO9001和CMM非常相似的是，兩者都共同著眼于質量和過程管理，而且它們都是基于戴明博士的全面質量管理產生的，因此不存在任何矛盾的地方。但是，它們的基礎是不同的：ISO9001（ISO9000標準系列中關于軟件開發和維護的部分）確定一個質量體系的最少需求，而CMM強調持續過程改進。在1994年版的ISO 9001中，CMM 2級的6個關鍵過程區域所涉及的部分，基本上都比較明確的做出了要求；而CMM 3級的7個關鍵過程區域中所涉及的內容大多數都提到了，但做出的要求不是非常詳細。很多實施了94版ISO的企業在了解了SW-CMM以后，普遍反映CMM比ISO的要求明確、詳細得多。如果94版ISO實施的效果很好的話，實施CMM 2級工作量是可以減少很多的。而2008版的ISO則更多的和CMM有直接對應的關系，甚至是大量CMM 4級和5級的要求。
目前我看到的大多數已經實施了ISO9000質量體系認證的軟件企業，在實施CMM的時候在以下方面會有一定的優勢：
★ 都擁有已經形成文檔的程序文件。但因為ISO 9001的高度抽象性，有些程序文件定義的不是很具體，CMM中有些關鍵實踐無法體現，但也有些企業花費了不少精力將ISO 9001的條款和軟件工程相關的實踐進行了很好的結合，相對來說就能夠體現絕大多數的CMM要求的實踐。這樣的話，按照CMM要求建立過程體系的工作量就可以減少很多了。
★ 對于過程改進的概念已經比較熟悉了。如果ISO實施的比較認真到位的話，過程改進方面的理念應該在企業中比較深入人心，無論是高層經理還是開發人員都會對這方面的工作比較認同和支持。
★ 絕大多數擁有ISO9001質量體系認證的企業都已經配備了和質量保證相關的工作人員，質量目標、方針和意識都比較明確。
有利就有弊，某些企業如果ISO實施的不是很到位的話，在實施CMM的時候也可能遇到這些問題：
★ 通過ISO 9001質量認證的實施過程，企業過分強調認證本身的重要性，證書拿到之后定義的過程就不再全面、認真地實施了，公司的員工發現過程改進工作變成了走形式、走過場。因此在整個企業中彌漫著一種對于過程改進非常抵觸和消極的情緒，絕大多數人員普遍對CMM表示懷疑、信心不足。
★ 高層經理對實施CMM難度認識不足，他們通常會覺得：9000的認證不是很簡單么？幾個人花上幾個月的時間不就搞好了，CMM想必也是差不多的，實施以后公司也沒有什么特別明顯的效果和收益。于是他們覺得CMM這件事情很容易，不需要花很多的心思和人力就可以輕松過關，這樣對于SEPG的過程改進工作難度就很大了。
上述情況對于CMM強調的持續過程改進帶來的負面影響是非常巨大的。除了企業過分強調證書以外，產生這些問題的原因還有以下幾個方面：
★ CMM分成了5個成熟度級別，每個級別都是更高級別的基礎。而ISO 9001要求企業把所有的條款一次性做好，其中當然也包括一些CMM高級別中的類似要求。對于任何一家企業，在剛剛開始進行過程改進的時候，想很好地實現這些要求是非常不容易的。
★ ISO 9001中沒有明確的制度化方面的要求，盡管定期地對企業進行復審，但很多企業仍然不清楚到底如何去更好地把這些流程制度化。在CMM中，有4類和制度化相關的關鍵實踐。簡單說來“制度化”的意思是：把企業中已經定義好的過程在相當長的時間和相對廣泛的范圍內保持良好、到位的實施。CMM每個KPA都有關于制度化方面的要求，比如：通過組織方針來約束所有人去遵循過程的要求；通過提供充足的資源和資金、培訓以及分配明確的職責來保證大家的使用過程；通過收集數據和量化的分析來判斷過程是否仍有不足，如何改進、如何提高過程的效率；通過不同級別的管理人員以及質量保證人員的檢查和監督確保大家按照要求的流程去做事等。
★ CMM只關注軟件，而ISO 9001有更大的范圍，對于制造業非常合適，即使是IT領域，也包括了硬件、軟件和服務。因為ISO 9001的咨詢師和審計員不一定是軟件方面的專家，加上ISO 9001的高度抽象性，審計員可以以不同的方式解釋實踐的合理性，這就使一些拿到認證的企業仍然是CMM 1級的組織。另外，軟件企業實施ISO的過程中，遇到了一些以軟件企業角度去理解相關條款的問題時，可能無法從咨詢師和審計員那里獲得滿意的答案。我曾經看到這樣一家企業，他們實施ISO9000:2008版已經半年多了，此時決定實施CMM。我看了他們的程序文件，感覺定義的非常好，項目計劃、配置管理、質量保證方面幾乎已經達到了CMM 2級的要求，但通過和部門經理、項目經理以及開發人員代表座談，發現大家實際的做法和過程要求的完全不一樣。究其根源，就在于當項目經理和開發人員對于公司流程要求的做法和實踐表示不理解或不明白的時候，負責定義流程的人員無法給出令人信服的解釋，久而久之，流程的執行變成了形式化的東西。
有關CMM實施困難
Q：實施過程改進時，最容易忽略的問題是什么？
A：最容易忽略的問題其實就是一個：CMM一直強調的持續的過程改進。
★ 在我看來，CMM 2級的6個關鍵過程區域的121條關鍵實踐其實在實施的時候并不是真正的難點。相對來說，真正的核心是建立過程改進的基礎，也就是說要讓企業中所有的相關人員能夠建立過程改進的意識，要能夠主動發現組織中的各種問題并且對其進行改進。如果真的能夠達到這個目標，到了正式評估的時候，即使在2級的關鍵實踐中有一些做得還不是很好，有經驗的主任評估師也會認為基本上達到了CMM 2級的要求。
★ 如果想達到CMM強調的過程改進的持續性，就必須要注意：在開始實施過程改進前，一定要以商業目標為基礎。也就是說，不要總想著我們只要過了CMM，就可以爭取市場上的更大的份額，就可以簽下更多的訂單；而應該廣泛的收集企業中所有人員關于改進軟件開發流程的建議和呼聲，高層經理根據這些改進的呼聲確定企業中存在的問題有哪些，通過過程改進能夠解決哪些問題，能夠幫助我們的企業實現什么樣的商業目標。絕大多數的企業可能會把商業目標確定在以下幾個方面：
▲提高軟件產品和項目的質量，降低缺陷率
▲提高客戶滿意度，減少客戶投訴
▲降低軟件開發成本
▲提高軟件開發進度，減少延期交付產品的情況
▲提升企業知名度，增加企業市場競爭力
可以看出，上述商業目標實際上是相互影響的，在實施過程改進開始的時候，不要把目標定得過高過大，只要把過程改進認真落實，并且保持著組織中對于過程改進的焦點和關注，經過一段時間后，勢必會在上述這些方面獲益。
★ 對于持續的過程改進，可以采取SEI推薦的IDEAL模型為參照。IDEAL是下列5個英文單詞的縮寫，代表著組成軟件過程改進周期的5個階段：
▲初始化 (Initiating)
▲診斷 (Diagnosing)
▲建立 (Establishing)
▲行動 (Acting)
▲擴充 (Leveraging)
詳細內容可參見左圖。

 


由圖可見，一般企業非常重視的評估工作，只不過是IDEAL模型中的診斷階段“評估當前實踐情況”所對應的內容。每次評估活動，其實是一輪過程改進較早期的活動，因此不少有經驗的主任評估師特別強調，如果你不打算繼續作過程改進，那你就不要做評估。因為CMM評估的目的就是幫助企業發現過程中的問題，并為新一輪的過程改進提供輸入，企業根據評估的結果以及主任評估師給出的建議制定相應的過程改進計劃，并且相應實施。因此，請不要過分看重CMM評估，而忽略了更重要的東西。
Q：在實施基于CMM的過程改進時，難度最大的KPA是哪些？
A：根據SEI在2002年8月份發布的統計數據來看，如下圖：
上圖是根據全球496次正式評估得到的統計圖表，其中我們重點關注CMM 2級的6個關鍵過程區域的情況。圖中對于每一個關鍵過程區域都有2個數據，分別表示在這496次評估中完全達到要求的比例和進行了評估的比例。換句話說，在2級的6個KPA中紅色柱最短的應該就是實施難度最大的KPA，這樣看來子合同管理似乎是實施難度最大的KPA。但我們發現產生這種情況的原因是：在絕大多數的軟件企業中沒有需要進行子合同管理的情況，這樣，子合同管理這個KPA在60%以上的評估中被定為“不適用”或者“不評級”。除去這個KPA，在90%以上的評估中，二級中的其他5個KPA都進行了評估，而只有10%多一點的評估中SQA（軟件質量保證組）能夠做到完全達到要求，這足以說明SQA是CMM 2級實施過程中難度最大的KPA，需求管理的實施難度最小。具體分析，原因如下：
★ 和各企業對于不同KPA的重視程度有關系，需求管理幾乎是所有軟件企業都非常重視的內容，畢竟需求管理不好，需求變更頻繁對項目組的工作量、進度和成本等方面影響是巨大的，于是各企業無論是否進行基于CMM的過程改進，都努力在找出使項目組和用戶就將來產品的功能、性能等達成一致理解的方法，并盡一切辦法減少客戶提出需求變更的可能。相對來說，質量保證的工作就不那么引人注意了。
★ SQA的工作帶有一定的預防性質。大家都知道，在軟件公司里面，評判一個人是不是“高手”的準則是他能不能解決其他人都解決不了的問題，就像給人治病的醫生，能夠治療疑難雜癥的是“神醫”；不知道大家有沒有想過，如果有個醫生在病人剛剛出現輕微癥狀的時候就能把別人的病治好，對于病人來說是莫大的幸事，但這樣的醫生恐怕一般人不會認為他是個好醫生，同樣，SQA也是如此。
★ 很多國內的軟件企業一邊在抱怨他們的客戶成熟度低，對于軟件什么也不懂，每天都在提出一大堆的需求變更，另一方面卻在充分的利用客戶什么都不懂，在軟件產品的質量上睜一只眼閉一支眼，畢竟高質量的產品需要更高的成本來換取，既然用戶也沒有那么高的質量要求，何必費那么大的力氣呢。可是他沒有想過，這種做法和一些黑作坊里面生產“三無”食品并沒有什么本質上的區別。好在越來越多的軟件企業已經加強了質量意識，也使SQA的地位得到了不少的提升。
★ SQA要在組織中得到認同。很多CMM 2級實施不到位的組織經常出現的問題就是無論是高層經理還是項目組有關的人員，大家都認為SQA可有可無，沒有必要。如果不是CMM有這樣的KPA，才不會安排專人去做這些事情呢。SQA做得好的企業通常有這樣的特征，組織中的所有人員能夠充分認識到SQA的價值，而項目組中發生的問題都能夠在SQA的幫助下友善的解決。
★ 根據CMM的要求可以看出，對SQA溝通能力的要求是比較高的。現在有不少企業的SQA成了“收賬的”，根據公司的規定到什么時候項目組應該出什么文檔，SQA就沖到項目組那里，大喊：“該交XX文檔了！”。項目經理就像老鼠看見貓一樣，求饒著說：“項目組現在太緊張了，能不能過幾天再說？”到底能不能再說就看SQA的心情了。久而久之，所有的文檔都改成了項目結束的時候再統一提交，而到那個時候文檔的質量也沒有人關心了。CMM要求的SQA可不是這樣的，SQA要成為項目組的好朋友，而不是“貓和老鼠”的關系，一方面SQA要執行必要的質量檢查和過程檢查，這是保證公司的整體利益而必須要做的；另一方面，SQA在執行檢查的同時，要通過發現的問題了解項目現在有什么麻煩，在項目組的級別上能不能解決，是否需要向高層經理匯報。要想做好這些事情，要求SQA對上面的高層經理，對下面的項目組反復的溝通，必要的時候還需要請一些技術經驗豐富的專家協助執行技術檢查，沒有相當的溝通技巧是很難做好這些事情的。
對于SQA能否有效的發現問題也是一個不小的考驗。如果SQA沒有比較豐富的軟件開發和項目管理方面的經驗，又不具備足夠的威望邀請一些有這些經驗的人員來協助進行檢查的話，項目組就可以隨心所欲的“蒙”SQA了。有的公司舍不得讓經驗豐富的人員來做SQA，結果可想而知；有的公司在實施CMM以后，充分認識到了SQA的價值，將這個崗位采取輪崗制，要求每個項目經理在正式上崗以前都必須先做半年的SQA，以便充分理解這個崗位的難處和重要性，以后可以更好的配合他們的工作，這真是一個很好的想法，值得推薦。
下期預知：
分析不同國籍主任評估師及咨詢公司的作用。


有關實施中具體問題
Q：不同國籍的主任評估師資質方面有什么不同？
A：據不完全統計，目前在全球范圍內SEI授權的主任評估師有300多位，不過不同的主任評估師在資質上面并不是全都相同。這要從如何成為主任評估師說起：如果要成為主任評估師，除了自身要有相當豐富的軟件工程、項目管理等相關知識背景外，還要參加大量的SEI組織的CMM相關知識的官方培訓。在正式成為主任評估師以前，必須親自主持一次正式評估工作，由已經得到授權資格的主任評估師進行考察，如果這次評估工作經過考察沒有出現嚴重的問題和錯誤，SEI將頒發主任評估師的授權認證。這樣的證書在2年內是有效的，有效期內主任評估師可以主持正式評估，其結果SEI認可，也可以監控其他主任評估師候選人主持正式評估的工作。
本來這樣的做法可以使成為主任評估師的“門檻”很高，但是還是存在一定的漏洞：如果一個人有個好朋友是主任評估師，他也想成為主任評估師，而他的朋友又不能很好的堅守原則，這樣就很容易“混入”主任評估師的隊伍。另外，目前很多主任評估師在給客戶作評估之前，往往還提供一些相關的咨詢服務，這種“既當教練又當裁判”的情況也難免會使一些主任評估師在作評估的時候放松尺度，使得進行過程改進的企業所有的過程改進工作變成了“花錢買認證”，而沒有真正從中獲益。
基于上述情況，目前國內一些比較有實力的咨詢公司為了保證自己的服務質量，也為了能使國內的軟件企業在進行基于CMM的過程改進的時候達到真正的效果，在主任評估師的選擇上堅持高標準和嚴要求。他們去請在歐美國家知名度很高、信譽很好的主任評估師來國內主持正式評估工作。這些主任評估師中很多都是SEI首批授權的主任評估師，有些人甚至就是參與制定CMM的人員。這些主任評估師經驗豐富，對于CMM的理解非常深刻，而且堅持原則，雖然這對國內的企業來說實施難度也增加了一些，但能夠在這樣的要求下達到CMM 2級以上的評價才是貨真價實的。
還有一點，目前很多國內的軟件企業也希望和印度的軟件企業一樣，通過實施CMM提高自身過程的能力成熟度，以便在海外市場上獲得更多的外包訂單。這個時候不同的主任評估師也會產生不同的效果。比如，當一家國內的軟件企業在和一家美國的企業洽談外包業務時，告知對方我們已經于某個時間達到了CMM 2級以上的成熟度，對方很可能要了解是由哪位主任評估師來做的評估，如果這位評估師在美國知名度很高，對方可能對這家企業“刮目相看”，后面的洽談可能就會容易很多。這就像在日常生活中，同樣是碩士學位，但知名度高的導師帶出來了學生更容易被人接受是一樣的道理。
Q：咨詢公司對我們實施CMM有什么幫助？
A：目前有不少的軟件企業希望通過自身的努力進行過程改進，然后進行正式評估，這是很常見的一種做法。不過，如果希望在實施的過程中困難少一點兒，時間短一點兒的話，最好還是與經驗豐富的咨詢公司合作。主要的原因在于：
★ CMM作為一個模型，具有高度的抽象性。因此CMM中并沒有提出一家軟件組織必須如何去做才算是達到了要求，它提出的只是“做什么”。舉個日常生活中的例子來說，CMM提出的要求就好像一家公司要求地面要保持清潔，至于是用掃把掃還是用吸塵器吸并不重要。同樣對于CMM中的要求，可以有很多種不同的實踐來滿足。可是，到底什么實踐在自己的企業中實施起來既比較有效，還能達到CMM的要求，對于剛開始實施CMM的軟件企業來說，這種判斷和選擇是很難把握的。而經驗豐富的咨詢公司結合了大量國內軟件公司的實踐、業內的最佳實踐以及主任評估師推薦的實踐，幫助企業達到CMM的要求，而且還比較簡單易行，實施效果已經經過了很多次的證明，自然能夠達到“事半功倍”的效果。
★ 咨詢公司對于企業在實施過程中出現的問題經驗豐富，可以有效的減少做錯事情的可能性。比如高層經理對過程改進不夠重視或者有一些誤解，特別是資源方面的問題，咨詢公司都可以及時發現，并協助參與實施的人員減少隨之帶來的負面影響。
★ 如果有些企業希望在一個既定的時間目標下達到某個成熟度級別，咨詢公司可以幫助實施企業監控進度，對于發現進度落后的情況，根據咨詢師的經驗也可以及時發現，及時采取糾正措施跟上進度。
★ 如果企業自己實施CMM，還需要自己聯系主任評估師，這樣在費用上可能會開銷很大，咨詢公司如果提供評估服務，他們可以根據企業的需求（包括資質和成本等多方面）幫助企業聯系到合適的主任評估師，減少企業自己聯系的麻煩和額外的成本。
下期預知：
如何公布自己的CMM成熟度級別。

Q：如果我們已經達到了CMM 2級的要求，有什么辦法可以公布我們的成熟度級別呢？
A：SEI反復的強調，CMM正式評估的結果不是認證，它只是一種企業內部進行過程改進時的一個步驟，找出自己的問題以便于持續地進行改進。因此，對于正式評估的結果，不論成熟度級別是幾級，主任評估師都要把評估結果提交給SEI的數據庫，便于SEI統計全球評估活動的情況。但是，有些企業并不希望他們的成熟度級別被公布，一方面可能是認為自己的成熟度級別還不夠高，認為公布出去不夠光彩；另一方面，有的企業擔心自己的競爭對手會了解這方面的市場信息，本來自己希望通過過程改進提高競爭力，競爭對手知道了也可以做過程改進，這樣就不能提高自己的優勢了。所以，SEI在缺省條件下是不會公開哪家企業當前是什么成熟度級別的，它只會定期公布一些匯總的數字。不過有些企業希望在SEI的官方網站上公開自己的成熟度級別，這也是可以做到的。具體方法如下：進入SEI的信息資源庫：http://seir.sei.cmu.edu/pml/，該頁面上方的部分主要說明了SEI提供自愿公開成熟度級別的功能的目的和用途，并重點強調了CMM正式評估結果不是一種認證，不要把公開成熟度級別看成是一種“證書”等內容。在該頁面的下方，分別是自愿公開成熟度級別要填寫的申請表格和察看當前已經公開了成熟度級別的組織名單，如圖7。
如果是希望加入此名單，則在點擊上圖中的鏈接后進入下一頁面，該頁面的主要內容就是一份申請表格，用英文填寫相關內容即可，如圖8所示。
該表格較長，因篇幅關系無法全部列出。當申請成功之后，就可以在列表中看到相關的名單了。如圖9所示。
在這里可以查看軟件CMM或CMMI兩種模型的情況，還可以查看不同的成熟度級別。在軟件CMM成熟度級別為2級的組織名單中，我們還可以看到一些來自中國的組織，如圖9的中國民航結算中心的信息。



入世后，軟件企業的國際化進程也隨之加快，一些大型軟件企業完成CMM認證的同時，也為相當多的中小軟件企業帶來了希望，但他們在實施CMM的過程中，特別是在向CMM2前進時往往存在很多困惑和疑問。本文特別側重對處于這一過程的軟件企業碰到的各種疑難問題進行答疑解惑。
有關CMM與CMMI的比較
Q：聽說SEI最新推出的CMMI是什么？我們是應該選擇CMMI還是CMM？
A：CMMI的全稱為：Capability Maturity Model Integration，即能力成熟度模型集成。自從1994年SEI正式發布軟件CMM以來，相繼又開發出了系統工程、軟件采購、人力資源管理以及集成產品和過程開發方面的多個能力成熟度模型。雖然這些模型在許多組織都得到了良好的應用，但對于一些大型軟件企業來說，可能會出現需要同時采用多種模型來改進自己多方面過程能力的情況。這時他們就會發現存在一些問題，其中主要問題體現在：
不能集中其不同過程改進的能力以取得更大成績；
要進行一些重復的培訓、評估和改進活動，因而增加了許多成本；
不同模型對相同事物說法不一致，或活動不協調，甚至相抵觸。
于是，希望整合不同CMM模型的需求產生了。1997年，美國聯邦航空管理局（FAA）開發了FAA-iCMMSM（聯邦航空管理局的集成CMM），該模型集成了適用于系統工程的SE-CMM、軟件獲取的SA-CMM和軟件的SW-CMM三個模型中的所有原則、概念和實踐。該模型被認為是第一個集成化的模型。
CMMI與CMM最大的不同點在于：
CMMISM-SE/SW/IPPD/SS 1.1版本有四個集成成分，即：系統工程(SE)和軟件工程(SW)是基本的科目，對于有些組織還可以應用集成產品和過程開發方面(IPPD)的內容，如果涉及到供應商外包管理可以相應地應用SS(Supplier Sourcing)部分。
CMMI有兩種表示方法，一種是大家很熟悉的，和軟件CMM一樣的階段式表現方法，另一種是連續式的表現方法。這兩種表現方法的區別是：階段式表現方法仍然把CMMI中的若干個過程區域分成了5個成熟度級別，幫助實施CMMI的組織建議一條比較容易實現的過程改進發展道路。而連續式表現方法則通過將CMMI中過程區域分為四大類：過程管理、項目管理、工程以及支持。對于每個大類中的過程區域，又進一步分為基本的和高級的。這樣，在按照連續式表示方法實施CMMI的時候，一個組織可以把項目管理或者其他某類的實踐一直做到最好，而其他方面的過程區域可以完全不必考慮。
軟件CMM 2級共有6個關鍵過程區域，在CMMI增加了1個：度量和分析。原來的6個關鍵過程區域的名稱和內容在CMMI中作了部分改進，但是主體內容沒有大幅調整。軟件CMM 4級共有2個關鍵過程區域，在CMMI中仍是2個，只是名稱和內容有所改進。軟件CMM 5級共有3個KPA，在CMMI中進行了合并，改為2個，但主要內容未變。變化最顯著的在CMMI 3級上，原有的7個KPA變成了14個，其中原來對工程活動進行要求的KPA－軟件產品工程進行了詳細的拆分，并結合常見的軟件生命周期模型進行了映射。CMMI中新增的過程區域中還涉及到過去未曾提到的內容，比如決策分析和解決方案、集成團隊等。
到底是選擇CMM還是CMMI主要基于以下幾個方面進行考慮：
實施企業的業務特點：如果企業的規模不是很大，業務又集中在軟件開發為主，那么還是軟件CMM比較適用。如果企業的規模比較大（開發人員100人以上），并且業務不僅僅集中在軟件開發，還包括硬件開發哪怕是硬件代理（采購）都可以考慮實施CMMI。
實施企業對過程改進的熟悉程度：如果企業已經實施過ISO 9000，并且取得了較好的效果，那么可以考慮實施CMMI。如果企業雖然沒有實施過CMM，但是對于過程改進一直比較關注，接受過不少相關培訓，甚至能夠自發的進行一些過程改進，那么也可以考慮實施CMMI。如果過去沒有接觸過類似的工作，那么最好先從軟件CMM 2級開始，首先建立持續過程改進的思路。另外，軟件CMM的要求也比CMMI要稍低一些。可以適當降低實施的難度。
實施企業對過程改進項目的預算：不論怎樣，幾乎可以肯定地說，實施CMMI的費用肯定要比實施CMM高出一些。而就模型本身來看，CMMI的2級7個過程區域在內容上并不比軟件CMM的2級6個關鍵過程區域多多少。這樣的話，我們完全可以“少花錢、多辦事”，也就是說可以采用CMM的實施和評估方法，但可以在過程改進的時候參考CMMI的要求，這樣就經濟很多。
實施企業是否可以使用階段式的演進路線： 如果企業只希望單方面的提高自己在項目管理、工程活動、支持活動或者過程管理四個方面中的某些方面的能力，那么就只能應用CMMI的連續表示方法。如果實施企業可以接受成熟度級別的思路（目前看國內大多數企業還是比較習慣于成熟度級別的），那么就不一定必須選擇CMMI了。
實施CMM與CMMI可以平滑的轉換。
一來，CMMI并不要求一家企業必須先做CMMI的2級然后再向更高的成熟級別演進，評估的時候也沒有這樣的要求。
另外，CMMI的評估都會根據被評估的成熟度級別，檢查所有不高于該級別的過程區域。換句話說，一個企業在CMM正式評估中達到了2級的成熟度，將來改為基于CMMI進行過程改進。在CMMI 3級的正式評估時，CMMI 2級的內容同樣要進行檢查。如果我們能夠在做CMM 2級的時候就按照CMMI的要求實施，效果沒有任何的折扣，但對于實施企業來說，會節省很多在培訓和評估方面的“額外”費用。（此處的“額外”費用是指CMMI收費比CMM高出的部分）

CMM實施中的戰略問題
   影響CMM成功實施的主要原因并不僅僅是技術問題，更多的是實施戰略問題。分析眾多企業實施CMM的過程，在其CMM實施戰略上存在的問題主要有以下三點。
1. SEPG小組孤立工作
企業在決定實施CMM之前，組織一個小組進行研究探討是很有必要的，但在決定實施之后，SEPG的組成和工作方式將更為重要。考察國內軟件企業實施CMM的過程，我們發現，一些企業在組成SEPG之后就讓其潛心制定規范，并在完成之后交給項目組實施，其結果是行不通或效果不好，從而導致CMM實施失敗。
那么，問題究竟出在何處？實際上，CMM只陳述了要做什么，但并沒有講清楚怎么做？因此CMM的實施必須由有過程管理經驗的人員參與，他們應當對軟件生命周期各階段的過程管理都相當熟悉，并且具備軟件生命周期各階段的實際開發和維護經驗。沒有這些經驗，就無法很好地組織和管理開發與維護過程。其次，在實施CMM之后，過程管理工作應在原來的軟件開發維護工作基礎上盡量透明，這就要求負責軟件開發維護的人員，特別是負責人，必須參與過程管理流程的制定，因為原有的軟件開發維護經驗并不一定能很好地適應現在的環境。只有軟件開發人員和過程管理人員很好地協同工作，才可能使過程管理工作盡可能透明化。此外，制定的規范首先必須是切合實際的，最初的規范不一定是最好的，但必須是可行的，然后在持續的實踐中不斷完善。
2. 全面展開CMM工作
另一種情況是：SEPG提供了一組看來可行的規范，企業據此全面展開CMM工作。企業的愿望是在盡可能短的時間里完成CMM的實施，但實際情況卻可能事與愿違。我們知道，CMM2級所有關鍵過程域之間都有很多聯系，并且貫穿于整個軟件生命周期。因此，在實施之初就全面展開CMM工作存在兩個弊端：其一，在實施過程中肯定會發現所制定的規范本身有許多地方不適，但因為覆蓋面太廣而不易確定改進點，結果是欲速則不達；其二，過程管理工作在相當長一段時間內可能會掩蓋原來基本軟件工程中存在的問題，這將增加發現問題、分析問題和持續改進的難度。因此，CMM的實施應該選擇一個著眼點，有計劃、分階段、定程度地進行，這不僅不會延長實施周期，相反還會加快實施的步伐，眾多企業的成功實踐也說明了這一點。
3. 照搬CMM實施模板
照搬其他企業的CMM實施模板是不可取的。首先，CMM實施模板屬于企業的知識產權，除非合法獲取，否則就是侵權；其次，其他企業的模板未必適合本企業，因為軟件產品的特性、開發方法、開發環境、開發工具以及企業文化的不同都會影響CMM模板的適用性，因此根據自己企業的實際情況草擬一個模板遠比直接采用其他企業的模板有意義。

CMMI為企業帶來的價值

  第一、能保證軟件開發的質量與進度，能對“雜亂無章、無序管理”的項目開發過程進行規范。
  第二、有利于成本控制。因為質量有所保證，浪費在修改、解決客戶的抱怨方面的成本會降低很多。絕大多數情況是缺少規范制度，只是求快。項目完成后，要花很多時間修修補補，費用很容易失控。
  第三、有助于提高軟件開發者的職業素養。每一個具體參與其中的員工，無論是項目經理，還是工程師，甚至一些高層管理人的做事方法逐漸變得標準化、規范化。
  第四、能夠解決人員流動所帶來的問題。公司通過過程改進，建立了財富庫以共享經驗， 而不是單純依靠某些人員。

CMMI評估流程
　　SEI根據ARC和ISO 15504的要求，以及CMMI的模型給出了A類評估的方法描述SCAMPI ( Standard CMMI Appraisal Method for Process Improvement) 。A類描述是根據CMMI模型，確定組級范圍內若干過程域 ( PA，Process Area ) 的CMMI評估，并確定組織的成熟度級別，A類描述必須在SEI授權的主任評估師為組長的領導下完成。就CMMI評估過程而言，其目的是如何能夠客觀地確定組織所處的工作狀態，因此最為重要的是如何采集信息以及據此進行判斷。SCAMPI將整個評估分成三個階段：
階段1：CMMI評估過程計劃和準備
完成CMMI評估過程的準備和設定，其中確定目標(評估等級)、建立責任人(評估組)、工作范圍(CMMI評估組織范圍和過程域范圍)、CMMI評估計劃 (時間、進度和資源)等活動。
階段2：執行CMMI評估
根據第1階段制定的計劃進行數據采集和分析、確定發現的問題以及進行評級。主要是采集覆蓋所有過程域、項目生命周期整個階段，同時能夠表征級織的過程能力的數據。在此過程中，需要多次重復采集和分析活動，直至達到相應目標，然后確定相應的發現，確認每一個過程域的初中的評定，這是過程能力級別評定和組織成熟度評定的基礎。
階段3：報告結論
CMMI評估組向評估發起人和被CMMI評估組織遞交相應的評估結論。根據組織要求，歸檔相應評估資料，并按計劃要求對部分信息進行保密處理。將CMMI評估結論遞交給CMMI標準化組織。

CMMI目標和實踐匯總
CMMI通用目標（GG）和通用實踐（GP）匯總
GG1Achieve Specific Goals 完成特定目標
GP 1.1Perform Specific Practices 執行特定實踐
GG2Institutionalize a Managed Process 使已管理的過程制度化
GP 2.1Establish an Organizational Policy 建立組織政策
GP 2.2Plan the Process 過程計劃
GP 2.3Provide Resources 提供資源
GP 2.4Assign Responsibility 分配職責
GP 2.5Train People 人員培訓
GP 2.6Manage Configurations 管理配置項
GP 2.7Identify and Involve Relevant Stakeholders 識別并引入相關的利益相關者
GP 2.8Monitor and Control the Process 監督和控制過程
GP 2.9Objectively Evaluate Adherence 堅持客觀的評價
GP 2.10Review Status with Higher Level Management 更高層領導審核狀態
GG3Institutionalize a Defined Process 使已定義的過程制度化
GP 3.1Establish a Defined Process 建立一個已定義的過程
GP 3.2Collect Improvement Information 收集（經驗）改進信息
CMMI特定目標（SG）和特定實踐（SP）匯總
CMMI 2：REQM 需求管理
SG1Manage Requirements 管理需求
SP 1.1Obtain an Understanding of Requirements 獲得對需求的理解
SP 1.2Obtain Commitment to Requirements 獲得對需求的承諾
SP 1.3Manage Requirements Changes 管理需求的變更
SP 1.4Maintain Bidirectional Traceability of Requirements 維護需求的雙向可追溯性
SP 1.5Identify Inconsistencies Between Project Work and Requirements 識別項目工作與需求的不一致之處
CMMI 2級過程域：項目規劃
SG1Establish Estimates 項目估算
SP 1.1Estimate the Scope of the Project 估算項目的范圍
SP 1.2Establish Estimates of Work Product and Task Attributes 估算項目屬性
SP 1.3Define Project Lifecycle 定義項目生存周期階段
SP 1.4Determine Estimates of Effort and Cost 估算工作量和成本
SG2Develop a Project Plan 制定項目計劃
SP 2.1Establish the Budget and Schedule 編制預算和進度
SP 2.2Identify Project Risks識別項目風險
SP 2.3Plan for Data Management 項目數據的管理計劃
SP 2.4Plan for Project Resources 規劃項目資源
SP 2.5Plan for Needed Knowledge and Skills 知識和技能的計劃
SP 2.6Plan Stakeholder Involvement “項目干系人”的介入計劃
SP 2.7Establish the Project Plan 制定項目計劃
SG3Obtain Commitment to the Plan 獲得對計劃的承諾
SP 3.1Review Plans That Affect the Project 審查從屬計劃
SP 3.2Reconcile Work and Resource Levels協調工作與資源配置
SP 3.3Obtain Plan Commitment 獲得計劃承諾
CMMI 2：PMC 項目監控
SG1Monitor Project Against Plan 依據計劃監督項目
SP 1.1Monitor Project Planning Parameters 監督項目計劃的參數
SP 1.2Monitor Commitments 監督承諾
SP 1.3Monitor Project Risks 監督項目風險
SP 1.4Monitor Data Management 監督數據管理
SP 1.5Monitor Stakeholder Involvement 監督干系人的介入
SP 1.6Conduct Progress Reviews 項目進展審查
SP 1.7Conduct Milestone Reviews 里程碑審查
SG2Manage Corrective Action to Closure 管理糾正措施
SP 2.1Analyze Issues 分析問題
SP 2.2Take Corrective Action 采取糾正措施
SP 2.3Manage Corrective Action 管理糾正措施
CMMI 2：ISM 供應商協議管理
SG1Establish Supplier Agreements 簽定供應商協議
SP 1.1Determine Acquisition Type 確定采購方式
SP 1.2Select Suppliers 選擇供應商
SP 1.3Establish Supplier Agreements 簽定供應商協議
SG2Satisfy Supplier Agreements 滿足供應商協議
SP 2.1Execute the Supplier Agreement 執行供應商協議
SP 2.2Monitor Selected Supplier Processes 監督選定的供應過程
SP 2.3Evaluate Selected Supplier Work Products 評價供應商產品
SP 2.4Accept the Acquired Product 驗收采購的產品
SP 2.5Transition Products 移交產品
CMMI 2：MA 度量分析
SG1Align Measurement and Analysis Activities 協調度量和分析活動
SP 1.1Establish Measurement Objectives 確定度量目標
SP 1.2Specify Measures 細化度量
SP 1.3Specify Data Collection and Storage Procedures 確定數據收集和存儲規程
SP 1.4Specify Analysis Procedures 確定分析規程
SG2Provide Measurement Results 提供度量結果
SP 2.1Collect Measurement Data 收集度量數據
SP 2.2Analyze Measurement Data 分析度量數據
SP 2.3Store Data and Results 存儲數據和度量結果
SP 2.4Communicate Results 通報度量結果
CMMI 2：PPQA 過程和產品質量保證
SG1Objectively Evaluate Processes and Work Products 客觀地評價過程和工作成果
SP 1.1Objectively Evaluate Processes 客觀地評價過程
SP 1.2Objectively Evaluate Work Products and Services 客觀地評價工作成果和服務
SG2Provide Objective Insight 提供客觀的洞察
SP 2.1Communicate and Ensure Resolution of Noncompliance Issues
通報不符合項，并確保得到解決
SP 2.2Establish Records 建立記錄
CMMI 2：SCM 配置管理
SG1Establish Baselines 建立基線
SP 1.1Identify Configuration Items 識別配置項
SP 1.2Establish a Configuration Management System 建立配置管理系統
SP 1.3Create or Release Baselines 創建或發布基線
SG2Track and Control Changes 跟蹤并控制變更
SP 2.1Track Change Requests 跟蹤變更請求
SP 2.2Control Configuration Items 控制變更
SG3Establish Integrity 建立完整性
SP 3.1Establish Configuration Management Records 建立配置管理記錄
SP 3.2Perform Configuration Audits 執行配置審計
CMMI 3：RD 需求開發
SG1Develop Customer Requirements 開發客戶需求
SP 1.1Elicit Needs 獲取客戶的需要
SP 1.2Develop the Customer Requirements 生成客戶需求
SG2Develop Product Requirements 開發產品需求
SP 2.1Establish Product and Product Component Requirements
建立產品需求和構件需求
SP 2.2Allocate Product Component Requirements 分配產品構件需求
SP 2.3Identify Interface Requirements 確定接口需求
SG3Analyze and Validate Requirements 分析和確認需求
SP 3.1Establish Operational Concepts and Scenarios 建立操作概念和場景
SP 3.2Establish a Definition of Required Functionality 定義功能需求
SP 3.3Analyze Requirements 分析需求
SP 3.4Analyze Requirements to Achieve Balance 平衡需求
SP 3.5Validate Requirements 確認需求
CMMI 3：TS 技術方案
SG1Select Product Component Solutions 選擇產品構件方案
SP 1.1Develop Alternative Solutions and Selection Criteria 開發候選方案和選擇準則
SP 1.2Select Product Component Solutions 選擇產品構件方案
SG2Develop the Design 設計
SP 2.1Design the Product or Product Component 設計產品或構件
SP 2.2Establish a Technical Data Package 建立技術數據包
SP 2.3Design Interfaces Using Criteria 設計接口
SP 2.4Perform Make, Buy, or Reuse Analyses 分析“制作、購買或重用”
SG3Implement the Product Design 實現產品設計
SP 3.1Implement the Design 實現構件的設計
SP 3.2Develop Product Support Documentation 編寫產品支持文檔
CMMI 3：PI 產品集成
SG1Prepare for Product Integration 準備產品集成
SP 1.1Determine Integration Sequence 確定集成次序
SP 1.2Establish the Product Integration Environment 建立產品集成環境
SP 1.3Establish Product Integration Procedures and Criteria 建立產品集成規程和準則
SG2Ensure Interface Compatibility 確保接口兼容
SP 2.1Review Interface Descriptions for Completeness 審查接口描述的完備性
SP 2.2Manage Interfaces 管理接口
SG3Assemble Product Components and Deliver the Product 組裝產品構件和交付產品
SP 3.1Confirm Readiness of Product Components for Integration
確認產品集成已準備就緒
SP 3.2Assemble Product Components 組裝產品構件
SP 3.3Evaluate Assembled Product Components 核查組裝的產品構件
SP 3.4Package and Deliver the Product or Product Component 打包并交付產品或構件
CMMI 3：VER 驗證
SG1Prepare for Verification 準備驗證
SP 1.1Select Work Products for Verification 選擇待驗證的工作成果
SP 1.2Establish the Verification Environment 建立驗證環境
SP 1.3Establish Verification Procedures and Criteria 建立驗證規程和準則
SG2Perform Peer Reviews 執行同行評審
SP 2.1Prepare for Peer Reviews 準備同行評審
SP 2.2Conduct Peer Reviews 執行同行評審
SP 2.3Analyze Peer Review Data 分析同行評審數據
SG3Verify Selected Work Products 驗證選定的工作成果
SP 3.1Perform Verification 執行驗證
SP 3.2Analyze Verification Results 分析驗證結果
CMMI 3：VAL 確認
SG1Prepare for Validation 準備確認
SP 1.1Select Products for Validation 選擇待確認的產品
SP 1.2Establish the Validation Environment 建立確認環境
SP 1.3Establish Validation Procedures and Criteria 建立確認規程和準則
SG2Validate Product or Product Components 確認產品或構件
SP 2.1Perform Validation 執行確認
SP 2.2Analyze Validation Results 分析確認結果
CMMI 3：OPF 組織過程焦點
SG1Determine Process Improvement Opportunities 確定過程改進機會
SP 1.1Establish Organizational Process Needs 建立組織過程的需要
SP 1.2Appraise the Organization’s Processes 評估組織過程
SP 1.3Identify the Organization's Process Improvements 識別組織的過程改進機會
SG2Plan and Implement Process Improvements 規劃和實施過程改進
SP 2.1Establish Process Action Plans 制定過程行動計劃
SP 2.2Implement Process Action Plans 實施過程行動計劃
SG3Deploy Organizational Process Assets and Incorporate Lessons Learned
部署組織過程財富
SP 3.1Deploy Organizational Process Assets 部署組織過程財富
SP 3.2Deploy Standard Processes 部署標準過程
SP 3.3Monitor Implementation 監督實施
SP 3.4Incorporate Process-Related Experiences into the Organizational Process Assets將過程相關的經驗納入組織過程財富
CMMI 3：OPD 組織過程定義
SG1Establish Organizational Process Assets 創建組織過程財富
SP 1.1Establish Standard Processes 建立標準過程
SP 1.2Establish Lifecycle Model Descriptions 建立生存周期模型描述
SP 1.3Establish Tailoring Criteria and Guidelines 建立裁剪準則和指南
SP 1.4Establish the Organization’s Measurement Repository 建立組織度量庫
SP 1.5Establish the Organization’s Process Asset Library 建立組織過程財富庫
SP 1.6Establish Work Environment Standards 建立工作環境標準
CMMI 3：OT 組織培訓
SG1Establish an Organizational Training Capability 建立組織級培訓能力
SP 1.1Establish the Strategic Training Needs 確定戰略培訓需求
SP 1.2Determine Which Training Needs Are the Responsibility of the Organization
確定由組織負責的培訓需求
SP 1.3Establish an Organizational Training Tactical Plan 建立組織培訓計劃
SP 1.4Establish Training Capability 建立培訓能力
SG2Provide Necessary Training 提供必要的培訓
SP 2.1Deliver Training 交付培訓
SP 2.2Establish Training Records 建立培訓記錄
SP 2.3Assess Training Effectiveness評價培訓效果
CMMI 3：IPM 集成化項目管理
SG1Use the Project’s Defined Process 應用項目定義過程
SP 1.1Establish the Project’s Defined Process 建立項目定義過程
SP 1.2Use Organizational Process Assets for Planning Project Activities
利用組織過程財富規劃項目活動
SP 1.3Establish the Project's Work Environment 建立項目工作環境
SP 1.4Integrate Plans 集成計劃
SP 1.5Manage the Project Using the Integrated Plans 利用集成計劃管理項目
SP 1.6Contribute to the Organizational Process Assets 充實組織過程財富
SG2Coordinate and Collaborate with Relevant Stakeholders 與相關干系人協調和合作
SP 2.1Manage Stakeholder Involvement 管理干系人的介入
SP 2.2Manage Dependencies 管理依存關系
SP 2.3Resolve Coordination Issues 解決協調問題
CMMI 3： RKSM 風險管理
SG1Prepare for Risk Management 風險管理準備
SP 1.1Determine Risk Sources and Categories 確定風險來源和類別
SP 1.2Define Risk Parameters 定義風險參數
SP 1.3Establish a Risk Management Strategy 建立風險管理策略
SG2Identify and Analyze Risks 識別和分析風險
SP 2.1Identify Risks 識別風險
SP 2.2Evaluate, Categorize, and Prioritize Risks 風險評估、分類和確定優先級
SG3Mitigate Risks 緩解風險
SP 3.1Develop Risk Mitigation Plans 制定風險緩解計劃
SP 3.2Implement Risk Mitigation Plans 實施風險緩解計劃
CMMI 3： DAR 決策分析與解決方案
SG1Evaluate Alternatives 評價候選方案
SP 1.1Establish Guidelines for Decision Analysis 建立決策分析指導原則
SP 1.2Establish Evaluation Criteria 建立評價準則
SP 1.3Identify Alternative Solutions 確定候選解決方案
SP 1.4Select Evaluation Methodsc 選擇評價方法
SP 1.5Evaluate Alternatives 評價候選方案
SP 1.6Select Solutions 選擇解決方案

CMMI V1.3

2011年是敏捷和CMMI結合的元年，在2010年底發布的CMMI V1.3正式把敏捷的內容寫到了CMMI模型中，而之前只是在技術報告中提及。對于CMMI規范這類原先軟件工程中作為"重載"的過程規范，和以"輕量級"著稱的敏捷方法，終于正式擁抱。

我們的咨詢特點就是要有效結合這兩者，將敏捷的方法真正地和CMMI模型結合，這種結合不是把兩種方法簡單的疊加，是有一定的順序的，并要根據不同的場景來決定的。對于一個不會走路的孩子，如果我們直接教他跑步，那他一定會摔得很慘，所以不同基礎的對象，應該有不同的教育方法和順序。

實際的效果才是最重要的，證書不是我們唯一想要的。