共用方式為

CMMI 的背景

  • 發行項

美國的軟體工程學院 (Software Engineering Institute) 出版一本關於 Capability Maturity Model Integration (CMMI) for Development 的完整指南，書名為《CMMI: Guidelines for Process Integration and Product Improvement》。這本書專門在說明 CMMI for Development (CMMI-DEV) 1.2 版，該版本是本文撰寫當時 CMMI 產品套件內其中一個模型。 這個模型極為穩定，而且在 2010 年以後應該會繼續流通。 此外，《CMMI Distilled: A Practical Introduction to Integrated Process Improvement》也是一本與本主題有關的實用易懂書籍。 如需這兩本書籍的詳細資訊，請參閱本主題後面的其他資源。

CMMI 在 1987 年以 Capability Maturity Model (CMM) 的名稱首度現身，這是軟體工程學院 (這是設於美國卡內基美隆大學 (Carnegie-Mellon University) 的研究中心) 所進行的一項專案。 這間中心是由美國國防部所成立和資助。 1991 年則首次發表了 CMM for Software 模型，這套模型是以 70 年代末與 80 年代初軟體開發專案的關鍵成功因素檢查清單為依據， 並參考 IBM 公司的研究成果與 20 世紀在品質保證方面的頂尖專家 Philip Crosby 和 W. Edwards Deming 提出的建言。 Capability Maturity Model 這個名稱和階段式表述 (Staged Representation) 五個層級 (本主題稍後會有相關討論) 的靈感皆啟發自 Crosby 的 Manufacturing Maturity Model。 CMM 主要用於國防程式，已歷經相當多次的採用以及數次的修訂與改進。 其成功經驗使得超越軟體主題的各種 CMM 如雨後春筍般興起。 到處出現的新模型令人眼花撩亂，因此政府資助了一項為期兩年的專案，由 200 多位產業和學術界的專家參與其中，來建立一套整合系統工程、軟體工程和產品開發的可延伸架構。 CMMI 於焉誕生。

請務必了解 CMMI-DEV 是一個模型， 而不是一套必須遵循的流程或規則。 它是一套經過組織的行為，經證實能夠對於軟體開發和系統工程帶來實質幫助。 為何要使用這樣的模型？ 其目的為何？ 該如何善用它？ 這些都是關鍵問題，而且或許是 CMMI 最常被誤解的問題。

本主題內容

  • 為何要使用模型？

  • 使用 CMMI 模型的目的為何？

  • 該如何善用 CMMI 模型？

  • CMMI 模型的要素

  • 其他資源

為何要使用模型？

組織若是沒有一套關於組織本身運作方式、其所需功能和這些功能間之互動方式的模型，就很難有所改進。 模型可讓我們對於組織中的各項要素有所認識，並協助我們形成一套共通語言，來探討有何需要改善之處和如何達成改善目標。 模型具備下列優點：

  • 提供有利溝通進行的共通架構和語言

  • 利用過去多年來的經驗

  • 讓使用者不會因為專心於改善，而迷失整體方向

  • 通常有訓練人員和顧問可提供支援

  • 有助於提供對於分歧意見的解決標準

使用 CMMI 模型的目的為何？

教科書會告訴您使用這套模型的目的在於評估組織的流程成熟度，以及提供可使產品獲得改善的流程改善指引。 若與軟體工程學院的人員直接交談，您可能會聽見他們表示 CMMI 是一套與風險管理有關的模型，可為組織管理風險的能力提供指標。 這個指標指出組織能夠按照協議來提供產品，或提供吸引市場之高品質產品的可能性。 從另一個角度來看，這個模型可為組織在壓力下的表現提供良好的預測指標。 高度成熟、處理能力足夠的組織能夠從容面對充滿壓力的突發事件、進行應變，然後繼續前進。 低成熟度、處理能力不足的組織在壓力下則很容易驚慌失措、盲目遵循預防程序，或是全盤推翻所有流程而倒退回混亂的狀態。

CMMI 尚未證實是組織經濟表現的良好預測指標。 雖然成熟度較高的組織可以更妥善管理風險且其行為更可預期，但有證據顯示成熟度較高的公司會對風險培養較為厭惡的態度。 這可能會讓組織缺乏創新或是變得更為官僚化，因而讓前置時間變長而缺乏競爭力。 成熟度較低的公司則比較容易創新和富創造力，但其組織很混亂且其行為是不可預期的， 而且一旦達到了什麼成就，通常是因為個人或管理者的突破性作為所致。

該如何善用 CMMI 模型？

這套模型是設計做為流程改善方案的基礎，以在評估過程中的具體使用形式而言，它只是一套可測量改善程度的支援系統。 此種用法成敗摻半。 人們很容易誤認這套模型是在定義一套流程而亦步亦趨地在遵循，而不是一個讓人知道現有流程中有哪些缺口需要填補的藍圖。 CMMI 的基本建置組塊是流程區域，其中定義了目標和數個常用來達成該目標的活動。 「流程與產品品質保證」即為流程區域的一例。 「組態管理」則為流程區域的另一例。 重點是要了解流程區域並不是流程。 一個流程可以橫跨多個流程區域，而一個流程區域可以牽涉到多個流程。

CMMI-DEV 實際上是兩個共用相同基礎要素的模型。 第一個 (也是最為人熟知的一個) 模型便是階段式表述 (Staged Representation)，這個模型呈現 22 個對應至五個組織成熟度層級的流程區域。 對組織的評鑑即在評估組織運作時展現的層級，而這個層級會成為該組織能否管理風險進而按照協議來提供產品的指標。

CMMI 階段性表示

層級 4 和 5 通常稱為成熟度較高的層級。 成熟度較高的組織 (會實施量化管理和最佳化行為) 與成熟度較低的組織 (只是有管理制度或遵循既定流程) 通常有很明顯的差異。 成熟度較高的組織會展現較低的流程變動性，且通常會在以統計資料為基礎的管理方法中納入頂尖指標。 因此，成熟度較高的組織比較容易展現可預測的行為，而且可以更快速地回應新資訊 (只要其他行政體系並未進來阻撓)。 但是不像低成熟度的組織容易展現突破性作為，高成熟度的組織在面對壓力時可能會盲目遵循流程，而忘記改變流程可能是更適當的應變方式。

第二個模型是連續式表述 (Continuous Representation)，這個模型會個別處理這 22 個流程區域內的處理能力，讓組織能夠將其改善工作放在能夠提供最高商業價值的流程上。 這種表述比較吻合 Crosby 的原始模型。 以這個模型為基礎的評鑑結果，會是與處理能力有關的基本資料，而非單一數字。 當然，因為組織成熟度層級是大多數管理者和執行者比較了解的層級，所以也有方法可以將連續式模型評估的結果對應至五個階段。

CMMI 持續性表示

將階段式模型當做流程改善方案的基礎可能比較危險，因為實作者很容易會忘記 CMMI 並不是個流程或工作流程模型，而是要讓人知道流程或工作流程所要達成的目標。 達成這些目標將能提高組織的成熟度以及對於事件發展的預測能力。 最大的錯誤模式或許就是單純為了通過評鑑，而將達到某個層級變成目標來建立流程和基礎結構。 不論是什麼流程改善活動，都應該以可測量的改善程度 (而不是一個數字) 為目標。

在流程改善上，使用連續式模型成功的機會似乎比較大，因此有些顧問公司乾脆只從連續式模型的角度出發來提供建議。 最明顯的差異就是，以連續式模型的角度出發來設計的流程改善方案，並沒有以成熟度層級決定的人為目標。 連續式模型自然也比較容易讓組織在最能帶來經濟效益的區域中套用流程改善。 因此，遵循連續式模型的人比較可能會從以 CMMI 模型為基礎的計畫得到正面結果， 而這樣的正面結果也更容易帶動良性的循環改善。

CMMI 模型的要素

CMMI 模型分為 22 個流程區域，如下表所列：

縮寫

流程區域

CAR

原因分析與解決

CM

組態管理

DAR

決策分析與解決

IPM

整合式專案管理

MA

測量與分析

OID

組織創新與部署

OPD

組織流程定義

OPF

組織流程重點

OPP

組織流程效能

OT

組織訓練

PI

產品整合

PMC

專案監控

PP

專案規劃

PPQA

流程與產品品質保證

QPM

量化專案管理。

RD

需求定義

REQM

需求管理

RSKM

風險管理

SAM

供應商合約管理

TS

技術方案

VER

驗證

VAL

驗證

在階段式表述中，流程區域會對應至各個階段，如下圖所示。

顯示流程區域的階段表示

在連續式表述中，流程區域則會對應至功能性群組，如下圖所示。

顯示流程區域的持續性表示

每個流程區域都包含必要、預期與資訊性的元件。 在以模型為基礎的評鑑過程中，實際上只有必要元件是需要評估的元件。 必要元件是每個流程區域的特定與一般目標。 預期元件是每個特定或一般目標的特定與一般作法。 請注意，因為預期元件只是預期而非必要的元件，所以這些特定或一般的作法可以由相等的作法所取代。 預期作法的存在是為了指引實作者和評鑑者一個方向。 如果選擇替代的作法，實作者可自行決定是否要通知評鑑者並解釋替代作法為何比較合適的原因。 資訊性元件則可在實作者開始進行以 CMMI 模型為基礎的流程改善計畫時，提供輔助性的詳細資料。 資訊性元件包含一般與特定作法的子作法，以及標準的工作成品。

請務必了解，只有一般與特定目標是必要的。 其他一切全都是用來指引方向。 在 CMMI 文獻中所提供的預期與資訊性元件範例，經常是取自大型的太空與國防系統整合專案。 這些專案是由資助和支持卡內基美隆大學軟體工程學院的公司所執行。 這些專案可能無法反映貴組織所從事的專案類型，也無法反映業界的最新趨勢，例如新興的敏捷式軟體開發 (Agile Software Development) 方法。

其他資源

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

請參閱

概念

MSF for CMMI Process Improvement v5.0