CMMI 的背景

Capability Maturity Model Integration (CMMI) for Development 的最後指南是由 Software Engineering Institute 發佈為 "CMMI: Guidelines for Process Integration and Product Improvement"。本書特別描述 CMMI for Development (CMMI-DEV) 1.3 版，這是撰寫時，在目前 CMMI 產品套件內的其中一種模型。 此模型極為穩定，而且應該繼續為 2010 之後的最新版本。 您也可能會發現 "CMMI Distilled: A Practical Introduction to Integrated Process Improvement" 是有關本主題的有用且可存取的書籍。 如需這兩本書的詳細資訊，請參閱本文章後面的其他資源。

CMMI 與 Capability Maturity Model (CMM) 都是在 1987 年誕生，而 CMM 是 Software Engineering Institute (位於 Carnegie-Mellon University 的研究中心) 的一個專案。 此中心是由美國國防部所建立。 CMM for Software 第一次在 1991 年發行，並且根據 70 年代晚期和 80 年代早期期間軟體開發專案中的重大成功因素檢查清單。 下列人員也會收到此模型的通知：International Business Machines (IBM) Corporation 研究中心和 20 世紀品質保證領導者 Philip Crosby 和 W. Edwards Deming。 名稱 Capability Maturity Model 以及 Staged Representation (在本主題後面討論) 中的五個層級是受到 Crosby 的 Manufacturing Maturity Model 所啟發。 CMM 主要套用至防禦程式，已達成大量採用而且經歷數個修訂和反覆項目。 它的成功導致開發軟體以外的各種主題的 CMM。 新模型的擴散會造成混淆，因此政府建立一個兩年的專案，牽涉 200 個以上的產業和教育專家，以建立整合系統工程、軟體工程和產品開發的單一可擴充架構。 結果就是 CMMI。

對於 CMMI-DEV 一定要了解的資訊就是它是模型。 它不是要遵循的流程或指示。 它是一組證明為十分適合軟體開發和系統工程的組織行為。 為什麼使用這類模型？ 它的目的是什麼？ 以及如何最有效地使用它？ 這些是 CMMI 的重大問題，而且可能是最容易遭到誤解的問題。

為什麼使用模型？

如果是沒有組織運作方式、其所需功能以及那些功能互動方式的模型，則很難改善投入的努力。 模型可讓我們了解組織中的個別項目，並協助我們制訂語言和需要改善項目的討論，以及如何達成這類改善。 模型提供下列優點：

• 提供可協助進行通訊的一般架構和語言

• 利用多年的經驗

• 協助使用者記住大方向，同時特別聚焦於改善

• 訓練人員和顧問通常會予以支援

• 可以提供標準來協助解決不一致

CMMI 模型的目的為何?

本書將告訴您模型的目的是評定組織流程的成熟度，並提供有關改善可改善產品的流程的指引。 直接與 Software Engineering Institute 的人員談話時，您可能會聽到他們提及 CMMI 是進行風險管理的模型，並指出組織管理風險的能力。 這項指示是組織可能對其承諾提供或提供對市場有吸引力之高品質產品的證據。 另一種考量此問題的方式，是模型提供組織如何在壓力下執行的良好指標。 高成熟度、高能力組織將會在其分散、回應、變更和繼續進行中取得非預期的具壓力事件。 低成熟度和低能力組織通常會受壓力所苦、盲目地遵循排除的程序，或擲出所有流程並造成混亂。

CMMI 未證明是組織經濟效能的良好指標。 雖然高成熟度的組織可能會更適當地管理風險而且較容易預測，但是可證明高成熟度公司之間的風險規避。 這項規避可能會導致缺乏導致長提前期的較大科層體制的創新或證據，以及缺乏競爭力。 低成熟度公司通常較具創新和創造力，但是混亂且無法預期。 達到結果時，通常是個人或經理英勇行為的結果。

使用 CMMI 模型的最佳方式為何？

模型是設計成用做流程改善開發案的基礎，而且用於僅評定進行測量改善的支援系統。 這項使用的成功率一半一半。 很容易就會將模型誤認為流程定義並嘗試遵循它，而不是識別現有流程中可能需要填滿之缺口的地圖。 CMMI 的基礎建置組塊是一個流程區域，可定義目標以及數個經常用來符合它們的活動。 其中一個流程區域範例是「流程和產品品質保證」。 另一個是「建構管理」。 請一定要了解流程區域不是流程。 單一流程可能跨多個流程區域，而一個個別流程區域可能涉及多個流程。

CMMI-DEV 實際上是兩個共用相同基礎項目的模型。 第一個和最熟悉的是 Staged Representation，其呈現 22 個對應至其中一個組織成熟度等級 (共五個) 的流程區域。 組織評價將評定它所操作的等級，而且此等級會是其管理風險能力的指標，因此，是根據其承諾所提供。

等級 4 和 5 通常稱為高成熟度等級。 高成熟度組織 (表現量化管理和最佳化行為) 與低成熟度組織 (只是接受管理或遵循定義的流程) 通常會有清楚的差異。 高成熟度組織在流程中的變化性低，而且通常會使用前置指標做為統計可防禦管理方法的一部分。 因此，高成熟度組織在回應新資訊時通常較容易預測且快速，但假設其他科層體制未妨礙。 低成熟度組織通常會表現英勇行為，而高成熟度組織在壓力下可能是盲目地遵循流程，因此無法辨識流程變更可能是較適當的回應。

第二個是 Continuous Representation，分別在 22 個流程區域內建立個別流程能力模型，讓組織可以調整對流程投入的改善心力，以提供最高商務價值。 這項呈現與 Crosby 的原始模型較為一致。 對此模型的評價會導致能力設定檔，而不是單一數字。 當然，因為組織成熟度等級是大部分經理和主管所了解的等級，所以有方法可以將連續模型評定的結果對應至五個階段。

使用階段性模型做為流程改善方案的基礎可能十分危險，因為實作者可能會忘記 CMMI 不是流程或工作流程模型，而是提供要達成的流程和工作流程目標。 符合這些目標將會改善組織的成熟度，以及事件展開為已規劃的機率。 最大失敗模式可能是達成目標的某個等級，然後建立流程和基礎結構只是為了通過評價。 任何流程改善活動的目標都應該是可測量的改善，而不是數字。

Continuous 模型似乎較適合做為流程改善的指南，因此有些顧問公司選擇只提供有關 Continuous 模型的指引。 最明顯差異是針對 Continuous 模型設計的流程改善方案沒有透過成熟度等級所決定的人為目標。 Continuous 模型也會較自然地讓它自己在最可能利用組織經濟效益的區域中套用流程改善。 因此，遵循 Continuous 模型的人員比較可能接收到來自根據 CMMI 模型的開發案的正面回饋意見。 甚至，正面回饋意見較可能會導致開發改善的正向循環。

CMMI 模型的項目

CMMI 模型分成下表列出的 22 個流程區域：

在 Staged Representation 中，每個階段都有對應的流程區域 (如下圖所示)。

在 Continuous Representation 中，流程區域會對應至功能分組 (如下圖所示)。

每個流程區都是由必要、預期和資訊性元件所構成。 實際上只需要必要元件，就可以滿足對模型的評價。 必要元件是每個流程區域的特定和一般目標。 預期元件是每個特定或一般目標的特定和一般做法。 請注意，因為預期元件只是預期而非必要項目，所以這表示特定或一般做法可能會取代為對等做法。 預期做法是引導實作者和評價者。 如果選擇替代做法，則是由實作者建議評價者，並證明為何替代做法較為適當。 資訊元件提供詳細資料，協助實作者開始進行透過 CMMI 模型所指引的流程改善開發案。 資訊元件包括一般和特定做法以及一般工作產品的子做法。

最重要的是了解只有一般和特定目標才是必要項目。 其他所有項目都是提供做為指引。 CMMI 文獻中提供的預期和資訊元件範例通常都是取自大型空間和防禦系統整合專案。 這些專案是由贊助和支援 Software Engineering Institute (位於 Carnegie-Mellon University) 的公司所執行。 這些專案可能不會反映您組織中進行的專案類型，也不會反映產業中的最近趨勢 (例如敏捷式軟體開發方法的緊急性)。

其他資源

如需詳細資訊，請參閱下列 Web 資源：

• CMMI for Development 1.3 版改善開發較佳產品和服務的流程 軟體工程流程管理方案 (英文)

• CMMI Institute (英文)

• CMMI：流程整合和產品改善的指導方針 (第 2 版) (英文) Mary Beth Chrissis、Mike Konrad 和 Sandy Shrum；Addison-Wesley Professional, 2006

• CMMI Distilled：整合流程改善做法簡介 (第 3 版) (英文) Dennis M. Ahren、Aaron Clause 和 Richard Turner；Addison-Wesley Professional, 2008

請參閱

概念

MSF for CMMI Process Improvement (適用於 Visual Studio ALM)