第二章 文獻探討
第二節 能力成熟度整合模型
一、CMM 與 CMMI 模型發展演進
1970 年代中期，美國國防部研究軟體專案做不好的原因，結果發現 70%的專案都是由於管理不善而引起，而非技術實力不夠，也因此，為 有效提升軟體專案的成功率，由美國國防部委託美國卡內基美隆大學
（Carnegie-Mellon University）之軟體工程學院（Software Engineering Institute, SEI），參考戴明博士 Deming（1986）提出的全面品質管理觀 念，訂定一系列軟體開發流程改進之成熟度架構，最後於 1993 年 2 月，
發表「Capability Maturity Model for Software 軟體能力成熟度模式 1.1 版
（SW-CMM V1.1）」及「能力成熟度模型之關鍵作業領域 Key Process Area1.1 版」。其後針對軟體系統發展之人、事、物衍生出：
(1) 以人為主之管理階層成熟度模式
People Capability Maturity Model（P-CMM），P-CMM 之目的是希 望人力資源部門可以做到如何吸引且留住優秀之員工、如何能提昇員工 之工作技術、如何提供良好之工作環境。
(2) 以涵括整個系統發展生命週期為主之系統工程成熟度模式 System Engineering Capability Maturity Model（SE-CMM），
SE-CMM 可以包括或未包括軟體之系統發展，系統設計階段應
(3) 以採購軟體為方向之軟體籌獲成熟度模式
Software Acquisition Capability Maturity Model（SA-CMM），重 要在於採購管理，包含：供應商評選，以及進行履約管理。
(4) 以整合諸多平行發展系統之整合發展管理成熟度模式
Integrated Product Development Capability Maturity Model
（IPD-CMM），IPD-CMM 係針對多系統平行發展條件下，如 何由組織 Integrated Product Team（IPT），規劃及掌握各系統間 之互動關係。
正因為 CMM 有許多模型，如此一來同一個組織針對上下游不同部 門都要做不同 CMM 的評鑑，這樣下來耗費太多成本，故 SEI 於 2000 年推出整合性的 CMM，稱作 Capability Maturity Model for Integration：
CMMI V1.02，作為組織軟體提升之參考依據。
二、CMMI 的兩種表述方式 (一) 階段式表述方法
階段式表述的方式將組織的流程成熟度等級分為五級：初始級 (Initial) 、 管 理 層 (Managed) 、 定 義 層 (Defined) 、 量 化 管 理 層 (Quantitatively Managed)、最佳化層(Optimizing)，強調組織流程改 善是循序漸進的，隨著成熟等級的提高，軟體組織可降低軟體開發
Level 3 已定義（Defined） 組織已建立書面化的標準作業流程 Level 4 已量化管理
（Quantitatively Managed）
流程績效可被量化的度量與分析
Level 5 最佳化（Optimizing） 差異產生的因果分析與預防創的技術 與流程
為了協助組織成功導入 CMMI，SEI 制訂了 CMMI 整體之一般 目標（Generic Goals, GG）、一般執行方法（Generic Practices, GP），
以及針對每個流程領域之特定目標（Specific Goal, SG）與特定執行 方法（Specific Practices, SP），詳述了哪些目標需要被達成，以及 怎樣做才可以達成目標（洪文堅，2011）。
第二等級以上的成熟度等級（Maturity Level, ML）都包含數個 流程領域，而每個流程領域下都含有一般目標與特定目標，在一般 目標項目裡面另外有一般執行方法；特定目標項目裡面另外有特定 執行方法，整體架構圖如下：
圖 2-1 階段式流程目標架構圖
(二) 連續式表述方法
在連續式表述方法的架構中，每個流程領域都是獨立且都有代 表自己的能力等級(Capability Level, CL)。而每個流程領域下也是含 有特定目標與一般目標，且在特定目標下含有特定實務，在一般目 SG (Specific Goals)
一般目標 GG (Generic Goals)
特定執行方法
SP (Specific Practices) 執行承諾 CO GP (Generic Practices)
共通特性 Common Features
圖 2-2 連續式流程目標架構圖 Managed
找出規劃管理的共 通性，建立基本的 專案管理程序，可 以重複施行於日後 的專案。
CM Configuration
Management 構型管理 MA Measurement and
Analysis 度量與分析 PPQA Process and
Product Quality
流程與產品品質 SG (Specific Goals)
一般目標 GG (Generic Goals)
特定執行方法 SP (Specific Practices)
能力等級
一般執行方法 GP (Generic Practices)
專案管理 支援 工程
階段 成熟度特徵 流程領域（Process Area, PA）
Assurance
PMC Project Monitoring
and Control 專案監督與管制 PREQM Requirement
Management 需求管理 Defined
組織已建立書面化
Organizational Process Definition
組織流程定義
OPF Organizational
Process Focus 組織流程焦點 OT Organizational
Training 組織訓練 DAR Decision Analysis
and Resolution
決策分析與解決 方案
IPM Integrated Project
Management 整合專案管理 RSKM RiSK Management 風險管理 RD Requirement
Development 需求發展 TS Technical Solution 技術解決方案 PI Product Integration 產品整合
階段 成熟度特徵 流程領域（Process Area, PA）
VER VERification 驗證 VAL VALidation 確認
ML 4 已定義 Defined
流程績效可被量化
的度量與分析 OPP
Organizational Process
Performance
組織流程績效
QPM Quantitative Project Management
數量化專案管理
ML 5 Optimizing 最佳化
差異產生的因果分 析與預防創的技術 與流程
OID
Organizational Innovation and Deployment
組織創新與推展
CAR Causal Analysis and Resolution
原因分析與解決 方案
有關 CMMI 22 個流程之說明，條列說明如下：
(1)原因分析與解決方案（Causal Analysis and Resolution, CAR）
主要是判斷造成缺失與其它問題的原因，並採取適當的方法來避免再次 發生。
(2)組織創新與推展（Organizational Innovation and Deployment, OID）
主要目的是選擇和推廣有增值性且創新效果良好的各種改善措施，並做 為組織流程與技術改善的測量方法。
(3)量化專案管理（Quantitative Project Management, QPM）
主要目的是以量化的方式來管理專案已調適的流程，以達到專案既定的 品質及流程績效目標。
(4)組織流程績效（Organizational Process Performance, OPP）
主要目的是建立和維護量化的組織標準流程績效，提供流程績效資料、
基準和模式，以便以量化的方式來管理組織的專案。
(5)確認（Validation, VAL）
主要目的是去確認產品或產品組件在預期的情狀下是否滿足使用的需 求。
(6)驗證（Verification, VER）
主要目的是確保工作產品符合使用者特定的需求。
(7) 產品整合（Product Integration, PI）
主要目的是整合產品元件，並確保所整合的產品能被運作且交付。
(8)技術解決方案（Technical Solution, TS）
主要目的是針對需求發展、設計與實作的解決方案，去設計且實作所有 產品、產品元件及產品有關的流程。
(9)需求發展（Requirements Development, RD）
主要目的是產出所分析之客戶、產品與產品組件的需求。
(10)風險管理（Risk Management, RSKM）
主要目的是在風險發生之前，識別出潛在的問題，以便規劃風險的控管 措施，並在專案生命週期啟動時就降低對專案的有害影響。
(11)整合專案管理（Integrated Project Management, IPM）
主要目的是從組織的標準流程所調適之整合且已定義的流程來建立和 管理專案，並且納入相關的利害關係人。
(12)決策分析與解決方案（Decision Analysis and Resolution, DAR）
主要目的是分析可能的決策使用一個正式的評估流程，並且使用已建立 的準則來評估各種已識別的方案，最後進行決策。
(13)組織訓練（Organizational Training, OT）
主要目的是加強人員的技能與知識，讓他們可以有效率的做好自己該做
的事。
(14)組織流程焦點（Organizational Process Focus, OPF）
主要目的是建立和維護對於組織流程和資產的瞭解，並且識別、規劃及 執行組織流程的改善活動。
(15)組織流程定義（Organizational Process Definition, OPD）
主要目的是建立並且維護有用的組織資產。
(16)供應商協議管理（Supplier Agreement Management, SAM）
主要目的是管理和專案訂定正式協議的外部供應商，他們所提供的產品 與服務。
(17)專案規劃（Project Planning, PP）
主要目的是建立且維護已定義專案的相關活動計畫。
(18)需求管理（Requirement Management, REQM）
主要目的是管理專案產品及產品組件之間的需求，並且指出這些需求與 專案計畫、工作產品之間的差異。
(19)專案監控（Project Monitoring and Control, PMC）
主要目的是瞭解專案的進度，以防止當專案發生與原定計畫有重大偏離 時才能適時的採取補救措施。
(20)流程與產品品質保證（Process and Product Quality Assurance, PPQA）
主要目的是提供專案成員與管理階層人員客觀地瞭解專案流程與相關 的工作產品。
(21)度量與分析（Measurement and Analysis, MA）
主要目的是發展和維持度量的能力以用來支援管理資料的需求。
(22)建構管理（Configuration Management, CM）
主要目的是使用建構識別、建構控制、建構狀態及建構稽核來建立並維 護工作產品的完整性。
上述是 CMMIv1.3 流程領域的簡短介紹，而 CMMI 的兩種架構所包
CMMI 的評鑑方式 SCAMPI（Standard CNNI Appraisal Method for Process Improvement）：由主任評鑑員帶領一個數個人員組成之評鑑小 組進行 CMMI 評鑑，評鑑過程主要分成三個階段：準備階段、評估階段 CMMI PIID（Process Improvement Indicator Description，流程改善指 導者描述）文件，並進行所有專案執行歷程文件之審閱，以及進行成
明確指出軟體流程有效地執行與尚未執行之處，且只有所有評鑑人員 一致通過的情況下，這個評鑑報告才會生效。
(3)報告階段：
評鑑小組在完成評鑑報告後，會得到最終評鑑結果。評鑑結果必須 與相關的關鍵流程領域和目標相對應。最後的評鑑報告與結果會送 交所有相關人員並往上呈報 SEI。
目前 CMMI 的評鑑方式總共分為 3 等級，將針對不同等級在個特徵 屬性下作詳細說明：
表 2-3 CMMI 評鑑等級
五、CMMI 之流程改善
近年來組織流程改善越來越受到重視，已經有許多有關流程改善的 研究陸續被提出，針對流程改善對組的效益說明如下。
根據 SEI 於 2005 年第一次公布 CMMI 導入績效資訊，此效益資訊 是根據 18 家取得 CMMI 認證之組織所回報的效益資料整理而成，共分 為：成本（Cost）、時程（Schedule）、品質（Quality）、客戶滿意度
（Customer Satisfaction)、投資報酬率）Return on Investment）及生產力
（Productivity）等六個構面，共計 29 個量化績效指標。
至於各國導入 CMMI 的組織進行效益調查，由 SEI 公布之調查結果 發現：CMMI 的導入對組織帶來正面的效益。
表 2-4 2005 年 SEI 公布之 CMMI 導入效益
效益構面 中位數 樣本數 最小值 最大值
成本 20% 87% 3% 21
時程 37% 90% 2% 19
生產力 62% 255% 9% 17
品質 50% 132% 7% 20
客戶滿意度 14% 55% -4% 6
投資報酬率 4.7:1 27.7:1 2:1 16
資料來源：Performance Results of CMMI-Based Process Improvement
六、小結
依據以上學者對於能力成熟度整合模型的定義，本研究認為能力成 熟度整合模型即「一種提升軟體產品品質、縮短開發週期、提高工作效 率的軟體工程模式與標準規範」。