由於工作太忙，好久沒有寫點東西了，今天無意中發現通過例子講解CMMI不同級別的區別的文章，感覺還不錯，貼出來給大家看看。
------------------------------------------------------正文-----------------------------------------------------------

CMMI等級一共分5級，分別是：

Ø   CMMI 1初始級

Ø   CMMI 2管理級

Ø   CMMI 3可定義級

Ø   CMMI 4量化級

Ø   CMMI 5持續改進級

下面就通過例子具體講下這5個級別的不同。

瞭解了CMMI的身世，我們再來看一下CMMI的不同級別。嚴格來講，CMMI級別有連續式和階段式兩種描述方式。雖然方式不同，但所表達的意思是一樣的。我們以最常用的階段式進行描述。先來看下邊這個故事：

1.   CMMI 1初始級

公司剛剛拿到一筆訂單，公司讓小張主要負責開發這個專案。小張是名牌大學畢業高材生，一個人可以幾天幾夜不休息寫出幾千行程式碼，在公司 屬於大俠級人物。

接到上司的任務，小張不敢怠慢，仔細閱讀了專案合同，並和使用者方通了電話，仔細詢問了使用者希望實現的需求。經過一番深思熟慮，他的腦海裡已經有了大概的構思。於是，小張開啟電腦，開始了他非常熟悉的編碼工作。

一週過去了，老闆過來詢問專案的進展，小張說如果不出意外的話，一個月應該差不多能完成。老闆很高興，誇獎小張很能幹。

可接下來的事情並不像小張想象的那麼順利，他突然發現：由於一時疏忽，竟然忘掉了一個很重要的功能；如果將其加進去，需要推翻以前編寫的大部分程式碼。想到已經跟老闆誇下海口，沒有辦法的小張只好連續加班好幾個晚上，最後終於把程式碼修改完成了。雖然經過了這樣一次挫折，但是小張感覺還是比較慶幸：幸虧自己發現得早，要不然就死定了。

接下來的開發一切順利，小張還是重複著夜以繼日的編碼工作。眼看就要大功告成，小張很高興得把喜訊告訴了老闆，於是老闆也很高興得通知了客戶，說下週你們就可以過來看產品了。

使用者高高興興來到公司之後，當小張跟他們介紹產品時，使用者卻挑出了很多毛病。原來小張當初沒有完全理解使用者的意圖，此後也沒有與使用者進行太多溝通，他以為自己已經完全理解了使用者需求，因此就按照心目中的想像把產品開發完成了。

看到使用者提的那麼多問題，小張別無選擇。於是，他又開始沒日沒夜地修改起了程式碼。這次小張吸取上次的教訓，跟使用者進行了多次溝通，最後終於完成了產品。但是整個開發進度卻延遲了一個月。雖然老闆沒有批評他，但是小張心裡的滋味也不好受，可又能怪誰呢？只能怪自己運氣不好，在專案中碰到了這麼多倒黴的事情。

真的是小張那麼倒黴嗎？當然不是，而且他運氣還算不錯了。按照他這樣的開發過程，只發生這兩件事情已經是非常幸運了。在開發之前沒有完全弄清楚使用者的需求，也沒有備忘錄以免發生遺漏，更沒有預先估計風險並採取預防措施，而只是碰運氣，走一步算一步，你說能不出問題嗎？所以，小張的開發過程還停留在CMMI第一級，也就是初始級的水平。

2.   CMMI 2管理級

如果用CMMI 2管理級水平進行改進，小張的這個專案應該怎麼做呢？

在真正動手做之前，先別忙著程式設計序，應該先考慮一下怎麼做才能把事情辦好，並且儘可能想得周全一些。我們不妨從下邊幾個方面幫助小張分析一下：

(1) 使用者的需求是什麼？怎樣確保真正理解了使用者的需求呢？那就先做個系統的需求調研吧。

(2) 為了避免遺忘某個需求，我還應該把這些需求都記錄下來才行。（REQM需求管理）

(3) 對了，這個功能技術難度太大，要不跟老闆申請外包吧。（SAM供應協議管理）

(4) 剩下的任務老闆讓我一個月完成這個任務，我得先計劃一下，要是完不成，我得提前跟老闆說啊。（PP專案計劃）

(5) 計劃出來了，還不錯，可以完成。不行，還不能高興的太早，我每週還得跟計劃對照一下，看計劃完成得怎麼樣。（PMC專案跟蹤）

(6) 要是我的程式碼下次也能用就好了，而且以後維護也得用啊，我得找個工具把程式碼管理起來。（CM配置管理）

(7) 老闆不太放心，安排了一個人來監督我，呵呵，我做的很好，儘管彙報吧。（PPQA質量保證）

(8) 任務完成了，真累啊，不行，我得算算我在這個專案上花了多長時間，加了幾次班，遇到了哪些問題，這些問題是怎麼產生的，下次的專案我得提前做好打算。（MA度量）

經過了這樣的考慮和計劃，小張順利開發完了第二個專案，產品拿到使用者那裡正式使用了，小張也因為出色的表現受到了領導的表揚。

可是產品上線不久，就因為負荷壓力過大引起宕機，給使用者造成了很大的影響。這個問題迅速反饋到了公司老闆那裡。老闆找到了小張。呵呵，看來小張真夠倒黴的，什麼事情都讓他碰上了，小張百思不得其解，為什麼我這麼努力，還是出問題了呢？

原來，小張開發完之後，由於測試人員出差，他就自己測了一下，覺得沒問題就交給了使用者。使用者對產品也很放心，認為應該沒什麼問題，產品就上線了。但由於使用者實際使用環境遠比小張的開發環境複雜得多，而這些小張之前並沒有意識到，也根本沒有進行這方面的考慮和設計。所以才發生了這樣的一幕。

3.   CMMI 3可定義級

那麼小張應該吸取什麼教訓呢？我們用CMMI 3 可定義級來幫著分析一下。

(1) 在瞭解使用者需求之後，編碼之前其實還要做很多工作。首先，應該把需求分析一下，看看哪些是功能需求，哪些是非功能需求，如何進行模組劃分，不同模組之間會有哪些介面需求等等。由於小張缺少這樣的分析過程，也沒有形成最終的需求規格說明書，所以他最終還是遺漏了非功能需求，以至於產生上邊的問題。（RD需求開發）

(2) 需求分析完成之後，小張還應該進行設計，把使用者所有的功能需求和非功能需求進行統一考慮，形成設計說明書，然後再進行編碼。這樣才會保證程式碼結構合理，並且會全面滿足使用者的需求。（TS技術解決方案）

(3) 在開始編碼之前，小張還應該考慮一下不同模組和元件之間整合的順序，必要的話，還應該跟使用者商量一下，根據使用者需求的優先順序來決定模組元件開發和整合的順序。（PI產品整合）

(4) 為了保證設計和編碼質量，部門還應該組織一些經驗比較豐富的人員來幫助小張發現一些問題，因此，在開發過程中，還應進行設計評審和編碼走查方面的工作。小張自己也應該進行一些單元測試，以便及時發現問題，減少影響和損失。開發完成之後，小張必須交給測試人員進行系統測試，因為自己檢查自己的程式碼往往是檢查不出什麼問題來的。（VER驗證）

(5) 測試人員測試完成之後，在產品真正上線之前還應該進行驗收和試執行。試執行一段時間，一切都沒有問題之後，再將產品正式切換上線。這樣即使在這個階段發現Bug，也不會造成太大影響。為了確保驗收效率，小張可以事先準備一份驗收大綱。（VAL確認）

在CMMI 3 可定義級中，把以上5項作為工程流程領域，無論做怎樣的裁減，這5項都是不能裁減的。它們之間的關係在CMMI 1.2中文版中用下圖來表示：

經過這樣一番分析之後，小張終於明白：看來自己是少做了很多工作。於是他決定下一個專案一定按照該流程好好做。

小張的專案引起了公司極大重視，為了避免類似問題產生，公司專門進行了以下工作的改進：

(1) 公司過程改進部門分析了問題產生原因，找出了不足，並針對不足制定了相應的改進計劃。（OPF組織過程焦點）

(2) 結合成功專案經驗，經過認真分析和考慮，公司內部制定了軟體開發生命週期規程指南，同時還制定了相應的文件模板。（OPD組織過程定義）

(3) 為了保證各部門相關人員密切配合，團結協作，各負其責，公司專門定義了軟體開發不同角色以及角色職責，確保各種角色充分發揮其作用，保證整個團隊的協作開發。（IPM整合專案管理）

(4) 為了減少專案風險，組織了有經驗的專案經理和開發經理，總結歸納專案風險，建立部門風險知識庫，並要求在專案過程中進行風險管理。（RSKM風險管理）

(5) 為避免重大決策失誤，成立了專家團，制定決策分析依據，在一些專案的重要決策上，幫助專案進行決策分析，以減少風險。（DAR決策分析與解決方案）

(6) 為了便於大家理解和吸收，公司專門組織了相應培訓，同時還進行了需求開發、設計、單元測試方面的培訓，這些培訓使大家受益匪淺。（OT組織訓練）

經過這樣的改進之後，公司整體的開發和管理水平都上了一個很高的臺階。專案成功的機率也大大提高了，公司還專門請來了CMMI評估師，並且順利通過了3級的正式評估，客戶的訂單也就紛至沓來。從這點來說，公司真的應該感謝小張才對啊！

4.   CMMI 4量化級

過了CMMI 3級，公司各方面工作井然有序，一切都很正常。看上去似乎沒有什麼需要改進的了。就這樣過了一年的時間，年底將至，公司正在加緊統計一年來的利潤和成本，統計的結果卻讓人吃了一驚：雖然公司的合同額非常大，利潤卻不是很多，這是什麼原因呢？原來公司雖然在軟體開發上做了很多工作，保證了專案順利的開發完成並上線，但是每個專案的真正資料並沒有進行記錄和統計分析。一個專案實際花費了多少工作量，產生了多少費用，到底什麼專案利潤比較大，可複用性比較強，什麼專案個性化需求太多，成本比較大，可複用性較弱。這些都沒有相應的資料進行支援。

發現了這個問題之後，公司又召開了一次經理會議，做出瞭如下改進措施：

(1)  建立公司內部統一的過程管理平臺，所有專案和產品的開發都要通過過程管理平臺進行管理；

(2) 根據平臺的資料積累，公司制定了統一的量化目標以及相應度量活動。（OPP組織過程績效）

(3) 根據公司的量化目標，每個專案定義自己的量化目標，並且定期進行偏差分析，分析偏差產生的原因，制定相應改進措施.（QPM量化專案管理）

經過一段時間，平臺中積累了大量資料。每個專案實際成本、專案進度、風險以及曾經發生過的問題在平臺上都能夠一目瞭然。在這些歷史資料的幫助下，銷售人員對專案的報價充滿了信心；開發經理做專案計劃的偏差率也越來越小，對專案問題的預測和掌控能力也更加強大。這不，公司正準備進軍CMMI 4呢！

5.   CMMI 5持續改進級

雖然小張所在的公司剛準備向CMMI 4級發起進攻，不妨先了解下5級也沒有關係，它並沒有我們想象的那麼可怕。5級只有兩個域，分別叫組織創新與發展（OID）、原因分析與解決方案（CAR）。這兩個域的主要意思，就是在度量的基礎之上，選擇循序漸進的創新與改善活動，逐步改善，從而達到企業制定的各項指標；同時對發生的問題以及產生的缺陷進行分析，並採取積極預防措施，避免類似問題再次發生。