CMMI是什麼?

CMMI(Capability Maturity Model Integration)將軟體開發流程視為一種工程(製造)流程，利用控制、量測、改善(control, measure, and improve)等循序漸進的方法，達到軟體流程改善的一個框架。CMMI是在美國國防部DoD以及國防工業協會(NDIA)的支持下，CMU的軟體工程學院(Software Engineering Institute, SEI)發展出來的模型。CMMI中許多的概念與原理來自於創立SEI軟體流程計畫(software process program)，並曾任職於IBM、領導大型系統軟體開發的Watts Humphrey。根據IBM與SEI的經驗，Humphrey將廣泛運用在製造流程中的統計流程控管(Statistical process control, SPC)的概念，加以修正、擴充後運用於軟體流程管理中。

在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。CMMI將軟體開發相關活動的實務作法分為25個流程領域(process area, PA)，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。

依性質來分，這些PA分屬於流程管理、專案管理、工程、與支援等四大類

流程管理：CMMI的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。

專案管理：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。

工程：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。

支援：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。

CMMI有連續式(continuous)與階段(staged)式兩種表示法。採用連續表示法者，可依據企業軟體開發的實際需求，自由選擇為數恰當且最相關的PA進行導入工作。採用階段表示法者，則須依據SEI規範，在一期間內同時導入若干相關PA。在連續表示法中，每一PA執行程度被規範成0至5等六個能力等級(capability level)；在階段表示法中，則有1至5等五個成熟等級(maturity level)。連續表示法近似於循序漸進的流程改善(同一時間僅處理少數PA，逐級推升能力等級)，而階段表示法則較屬於跳躍式的流程改善(同一期間內處理多個PA，同步達到該成熟等級所規範PA所需達到的能力等級)。由於階段表示法的成熟等級相當容易描述並能簡短的表達企業軟體開發能力，採用者較多。簡言之，

ML 1 (initial)：企業有開發軟體產品的能力，但掌控專案時程、成本、流程的能力不佳。

ML 2 (managed)：具備ML 1的能力，且對於專案的需求、流程、產出物具有管理能力，能在特定時間點(如專案里程碑到達時)交付產出物。但流程則可能因專案而異，仍未加規範。

ML 3 (defined)：具備ML 1、ML 2的能力，且企業對常用的流程以及其修改方式均加以定義。因此，雖專案採用流程可能有所不同，其不同處均被清楚定義。

ML 4 (quantitatively managed)：具備ML 1、ML 2、ML 3的能力，且以統計方法進行流程控管，了解其實施作法的變異性，以供採取因應措施。

ML 5 (optimized)：具備ML 1、ML 2、ML 3、ML 4的能力，且具有調整與修正流程的能力，使其達到最佳化。

值得注意的是，階段表示法首重專案的規劃、執行與控管。這並不意味著工程與技術領域並不重要，相對的，正確的解讀方式應為：唯有在組織的專案進行方式足夠結構化並得到掌控之後，方能有效的探討與解決工程領域與流程領域的問題。此一安排可看出CMMI成熟等級規劃上的務實性。

SEI從ML2開始給予企業能力成熟度評等；評鑑由SEI認證的主任評鑑員主持。如果你決定要採用CMMI，則最常見的做法是引進顧問的協助，而如果你的企業想獲得評等，顧問中最好能包含經SEI認證的主任評鑑員。在時程上，SEI並無一定的要求。從實務經驗上來看，以階段式表示法為例，跨越每一個成熟等級約需18到24個月。跳級雖被允許(例如直攻 ML 3或由ML 3跳攻ML 5)，一般而言這意味著冒著未能深入落實CMMI作法的風險：儘管獲得評等，組織內部可能仍有相當比例的做法不符合CMMI的要求。這也突顯評鑑實施方式的一個無法完全避免的問題：為使評鑑經濟而可行，SEI的官方評鑑方法SCAMPI採取事前資料準備、資料檢視與面談查證的方式進行。在有限的時間與資源投入的情況下，企業有可能可以透過刻意安排專案、準備相關資料與讓人員彩排面談的方式，使企業軟體流程管理看起來像是符合CMMI規範。顯而易見的，這樣的作法並無法獲得流程的改善。縱使因獲得評等而一時接獲專案，企業終將因無法提供具高品質的軟體產品 — 而這正是採用CMMI的主要目標 — 而失敗。