凡是有軟件開發主營業務的企業，我相信都應該聽過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標準系列中關于軟件開發和維護的部分）確定一個質量體系