功能成熟度模型整合的背景 （CMMI）
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
軟體工程研究所發佈的《功能成熟度模型整合（CMMI）開發能力成熟度模型整合（CMMI）最終指南》是「CMMI：程式整合與產品改進指導方針」。這本書特別描述 CMMI for Development （CMMI-DEV） 1.3 版，這是 CMMI 產品套件內的其中一個模型。 您也可以找到「CMMI 已提煉：整合程式改進的實用簡介」，以成為有關 CMMI 的實用且無障礙書籍。
注意
此處提供的指引是以 CMMI 1.3 版為基礎，並支援 Azure DevOps 提供的 CMMI 程式。 目前沒有任何方案可更新此內容以支援更新版本。
歷程記錄筆記
CMMI 始於 1987 年，作為軟體工程研究所（SEI）的專案的能力成熟模型（CMM）。 SEI是卡內基-梅隆大學的研究中心，由 美國 國防部成立和資助。 CMM於 1991 年首次發佈，開始作為關鍵成功因素的檢查清單。 該模型還建立在國際商業機器（IBM）公司和20世紀品質保證領導者，如菲力浦·克羅斯比和W.愛德華茲·德明的研究的基礎上。 名稱、 功能成熟度模型和 分段表示 法五個層級都受到 Crosby 的製造成熟度模型啟發。 主要適用於防禦計劃，CMM 取得了相當大的採用，並進行了幾項修訂。 其成功導致 CMM 針對軟體以外的各種主題開發 CMM。 新模型的激增令人困惑。 對此，政府資助了為期兩年的專案，建立整合系統工程、軟體工程和產品開發的單一可延伸架構。 這項工作涉及200多名行業和學術專家。 結果為 CMMI。
CMMI-DEV 是模型。 這不是一個過程，也不是遵循處方。 相反地，CMMI-DEV 會提供一組已證明在軟體開發和系統工程中使用的組織行為。 為什麼要使用這類模型？ 其用途為何？ 它應該使用得有多好？ 這些關鍵問題也許是 CMMI 最誤解的問題。
為什麼要使用模型？
改進工作需要組織的運作方式、所需的功能，以及這些函式如何互動的模型。 模型可讓您了解組織元素，並協助討論如何和應該改進哪些專案。
模型提供下列優點：
- 提供通用架構和語言來協助溝通
- 運用多年的經驗
- 協助用戶考慮大型圖片，同時專注於改進
- 經常受到教練和顧問的支援
- 藉由提供已同意的標準來協助解決分歧
CMMI 模型的用途為何？
CMMI 模型的目的是評估組織程式的成熟度，並提供改善程序的指導，目標是改善產品。 此外，CMMI 是風險管理的模型，並提供方法來測量組織管理風險的能力。 能夠將風險因素因素管理到組織提供高品質產品的能力。 管理風險的另一個觀點是組織在壓力下的表現。 高成熟度、高功能組織可以輕鬆地回應非預期且緊張的事件。 低成熟度和較低的能力組織往往在壓力下恐慌，盲目遵循被遺棄的程式，或完全扔掉所有程式，並重新回到混亂。
不過，CMMI 並不是組織經濟效能的經證實指標。 雖然較高的成熟度組織可能會更好地管理風險，而且更容易預測，但有證據表明，較高的成熟度公司往往與風險相反。 風險厭惡可能導致缺乏創新或證明更大的官僚作風，導致長時間的領先時間和缺乏競爭力。 成熟度較低的公司往往更具創新和創造性，但混亂和不可預知。 實現結果時，通常是個人或經理的英勇努力的結果。
使用 CMMI 模型的最佳方式為何？
該模型的設計目的是作為程式改進計劃的基礎，其只用於評估的支持系統來測量改進。 此使用方式取得了混合的成功。 將模型誤認為程式定義並嘗試遵循，而不是識別可能需要填滿之現有程式中差距的對應，這一點太容易了。 CMMI 的基本建置組塊是定義目標和數個經常用來符合目標的流程區域。 流程區域的其中一個範例是 Process 和 Product Quality Assurance。 另一個是組態管理。 請務必瞭解進程區域不是進程。 單一進程可能會跨越多個進程區域，而個別進程區域可能會涉及多個進程。
CMMI-DEV 實際上是兩個共用相同基礎元素的模型。 第一個且最熟悉的是分段表示法，其呈現對應到五個組織成熟度層級之一的 22 個進程區域。 對組織的評估將評估其運作程度，而這個層級將是其管理風險能力以及履行承諾的能力指標。
層級 4 和 5 通常稱為較高的成熟度層級。 較高成熟度組織通常有明顯的差異，其示範量化管理和優化行為，以及低成熟度組織，這些組織只是管理或遵循定義的程式。 較高的成熟度組織在流程中顯示較低的變異性，而且通常會使用前置指標作為統計可防禦管理方法的一部分。 因此，較高的成熟度組織在回應新資訊時往往更可預測且更快速，假設其他官僚作風不會妨礙。 當低成熟度組織傾向於表現出英勇的努力時，高成熟度組織可能會在壓力下盲目地遵循程式，且無法辨識程序變更可能是更適當的回應。
連續表示模型在22個進程區域內的每個程式功能，可讓組織針對提供最高商業價值的程式量身打造其改進工作。 這個表示法更符合克羅斯比的原始模型。 此模型的評估會產生功能配置檔，而不是單一數位。 因為組織成熟度層級是大部分經理和主管所瞭解的水準，因此有一些方法可將連續模型評估的結果對應到五個階段。
當實作者忘記 CMMI 不是程式或工作流程模型時，使用分段模型作為程式改進計劃的基礎可能會很危險。 相反地，CMMI 是設計來提供流程和工作流程的目標。 達成這類目標可改善組織的成熟度，以及事件按計劃展開的可能性。 也許最大的失敗模式是達到目標層級，然後建立流程和基礎結構，只是通過評估。 任何程式改進活動的目標應該是可測量的改進，而不是數位。
連續模型作為流程改進的指南，已享有成功。 一些諮詢公司只選擇提供連續模型的指導。 最明顯的差異在於，針對連續模型所設計的程式改進計劃並沒有由成熟度層級決定的人工目標。 持續模型也適合在最有可能利用組織經濟效益的領域套用程序改進。 因此，遵循連續模型的人更有可能從以CMMI模型為基礎的計劃收到正面意見反應。 此外，積極的反饋更有可能導致改善的良性循環的發展。
CMMI 模型的元素
下表列出組成 CMMI 模型 （1.3 版） 的 22 個行程區域：
| 縮略字 | 處理區域 |
|---|---|
| CAR | 因果分析與解析 |
| 喀麥隆 | 組態管理 |
| DAR | 決策分析與解決 |
| Ipm | 整合式專案管理 |
| MA | 測量和分析 |
| OID | 組織創新與部署 |
| OPD | 組織程序定義 |
| OPF | 組織程序焦點 |
| Opp | 組織程式效能 |
| OT | 組織訓練 |
| PI | 產品整合 |
| PMC | 項目監視與控制 |
| PP | 專案規劃 |
| PPQA | 程式與產品質量保證 |
| QPM | 量化專案管理 |
| RD | 需求定義 |
| REQM | 需求管理 |
| RSKM | 風險管理 (Risk Management) |
| SAM | 供應商合約管理 |
| TS | 技術方案 (Technical Solution) |
| VER | 驗證 |
| 瓦爾 | 驗證 |
在分段表示法中，進程區域會對應至每個階段，如下圖所示。
在連續表示法中，進程區域會對應至功能群組，如下圖所示。
每個進程區域都是由必要、預期和資訊化元件所組成。 實際只需要必要的元件，才能滿足模型的評估。 必要的元件是每個程序區域的特定和一般目標。 預期的元件是每個特定或泛型目標的特定和泛型做法。 請注意，由於預期的元件只是預期而不需要，這表示特定或泛型做法可以由對等的做法取代。 預期的做法是引導實作者和評估者。 如果選擇替代做法，則由實作者提供建議評估員，並證明為什麼替代做法是適當的。 資訊元件提供詳細數據，可協助實作者開始使用 CMMI 模型引導的程式改進計畫。 資訊元件包括泛型和特定做法的子專案，以及一般工作產品。
只需要泛型和特定目標。 其他一切都以指南的形式提供。 如需預期和資訊元件的範例，CMMI 文獻會從大型空間和防禦系統專案提取數據。 這些專案可能不會反映貴組織中所承擔的專案類型，也可能不會反映業界的最新趨勢，例如敏捷式軟體開發方法的出現。