前言

卡耐基美隆大學軟體工程學院(Software Engineering Institute-SEI)已經於2010年11月公佈發行CMMI-DEV V1.3，CMMI-DEV V1.2 將於於2011年11月30走入歷史。自12月1日起，SEI將全面推行CMMI-DEV V1.3相關的訓練及評鑑活動。

CMMI-DEV V1.3主要的調整內容是將高能力成熟度(High Maturity Level-包括ML4 及 ML5)做更清楚的說明，將原本分佈於各流程領域之內的“共同目標(Generic Goal)”及“共同執行方法(Generic Practice)”集中到各流程領域之前，其內容沒有太大的改變。 對於每個流程領域的“典型工作產品(Typical Work Products)”改稱為“工作產品舉例(Example Work Products)”。對於每個流程領域的內容描述，也有改進及調整，並且增加了關於“敏捷式開發方法(Agile Programming)”的內容。

建構管理在CMMI 模式中歸類為成熟度第二級的支援類流程領域。本文主要的目的是轉載V1.3 中建構管理流程領域的特定目標(Specific Goal)及特定執行方法(Specific Practice) 的中譯版內容，其中與V1.2 不同處將以紫色字體標註，希望讀者能洞悉其沿革的重點，全文將分上下兩篇刊登。

簡介

建構管理流程領域，包含下列活動：
1.界定所選定之工作產品的建構，這些工作產品在特定的時點會組成基準
2.管制建構項目的變更
3.建立或提供規格，以便從建構管理系統建造工作產品
4.維護基準的完整性
5.提供正確的狀態和目前的建構資料給發展人員、最終使用者及客戶

納入建構管理的工作產品，包含交付客戶的產品、指定的內部工作產品、取得的產品、工具，以及其他用以產生或描述這些工作產品的項目。可納入建構管理的工作產品，舉例如下：

• 硬體及設備
• 圖表
• 產品規格
• 工具設定
• 程式碼及公用程式庫
• 編譯器
• 測試工具及測試腳本
• 安裝紀錄
• 產品資料檔
• 產品技術文件
• 計畫
• 使用者使用情境
• 迭代備錄
• 流程說明
• 需求
• 架構文件及設計資料
• 產品線計畫，流程及核心資產

供應商和專案可能都需要將取得的產品納入建構管理。供應商協議中應建立執行建構管理的規定。應建立並維護用以確保資料之完整性和一致性的方法。

請參考「供應商協議管理」流程領域，以獲取更多有關建立及維護供應商的協議資訊。

工作產品的建構管理可以在許多不同層次的精細度上執行。建構項目可分解為建構組件和建構單元。本流程領域只使用「建構項目」這個術語。因此，在這些執行方法中，在適當的時候，建構項目可詮釋為「建構組件」或「建構單元」。

基準是建構項目持續演進的穩定基礎。舉例來說，已核可的產品說明是一個基準，它包含需求、需求追溯表、設計、特定專業項目及使用者文件，成為內部一致的版本。

當基準發展完成，就會納入建構管理系統。基準的變更與自建構管理系統所建造之工作產品的發行，經由建構管理的建構管制、變更管理及建構稽核等功能，進行有系統的管制與監督。

本流程領域不只適用於專案的建構管理，也適用於組織工作產品如標準、程序、及其他共用的支援性資產。

建構管理著重於工作產品(包含已交付的產品或服務)在管理面和技術面的嚴格管制。

建構管理流程領域涵蓋執行建構管理功能的執行方法，也適用於已納入建構管理的所有工作產品。

對於產品線，需增加考量如何共用跨產品線的核心資產以及不同版本的核心資產與產品間的建構管理問題。

在敏捷式開發環境，由於必須支援頻繁的變更及頻繁的建置(通常每天都進行)、多重基準、多重的工作空間(例如個人、團隊，甚或是雙人組式的程式設計)，建構管理(CM)是非常重要的。如果組織不能夠:1)實施自動化的建構管理(例如建置腳本、狀態紀錄、完整性檢查)以及 2)將建構管理當作一組單獨實施的標準服務性流程，敏捷開發團隊將可能會陷入泥沼。一開始時，敏捷式開發團隊就要指定人選負責確保建構管理能夠正確施行。在每一次的迭代開始之前都要再次確認需要建構管理的支援。建構管理活動很謹慎的整合進入每一個團隊的律動之中，以使團隊的分心程度降到最低並順利完成工作任務。

特定目標(Specific Goal – SG) 及執行方法(Specific Practice – SP)

摘要

SG 1建立基準

SP 1.1 界定建構項目
SP 1.2 建立建構管理系統
SP 1.3 建立或發行基準

SG 2追蹤並管制變更

SP 2.1 追蹤變更申請
SP 2.2 管制建構項目

SG 3建立完整性

SP 3.1 建立建構管理紀錄
SP 3.2 實施建構稽核

特定目標1 (Specific Goal-SG1) 建立基準

SG1為建立由已界定的工作產品所組成的基準。本特定目標涵蓋用以建立基準的特定執行方法。「追蹤並管制變更」特定目標所涵蓋的特定執行方法用以維護基準，而「建立完整性」特定目標的特定執行方法則用以記錄和稽核基準的完整性。

一.特定執行方法1.1 (Specific Practice– SP1.1) 界定建構項目

界定將納入建構管理的建構項目、組件及相關的工作產品。 建構識別為下列項目的選擇及說明：

• 交付客戶的產品
• 指定的內部工作產品
• 取得的產品
• 工具及其他專案工作環境的資本資產
• 其它用以產生或說明這些工作產品的項目

建構項目可能硬體，儀器，有形的資產，軟體及文件。文件可能包括需求的規格和介面文件；其他用來界定產品或服務的建構性的文件，例如：測試結果，也可能納入。

「建構項目」是被指定要納入建構管理的實體，它可能包含組成某基準的數個相關工作產品。這種邏輯上的編組，提供較容易的識別和存取控制。應根據規劃時所定的準則，選取需納入建構管理的工作產品。

二.工作產品舉例

• 已界定的建構項目

三.細部執行方法

(1)根據文件化的準則，選擇建構項目和組成這些項目的工作產品。在適當的工作產品層次中，選擇建構項目的準則，舉例如下：
• 可以被兩個(含)以上小組共用的工作產品
• 會隨著時間而變更的工作產品，其變更原因可能是發生錯誤或變更需求
• 數個相互依存的工作產品(例如當其中一個改變時，其他的也須調整)
• 對專案的成功具有極高重要性的工作產品
可組成建構項目的工作產品，舉例如下：
• 設計
• 測試計畫和程序
• 測試結果
• 介面說明
• 圖表
• 原始碼
• 使用者故事情境或故事卡
• 已聲明的企業案例，邏輯或價值
• 工具(如編譯器)
• 流程說明
• 需求

(2)指定每個建構項目唯一的識別碼。

(3)界定每個建構項目的重要特性。建構項目的特性，包含作者、文件格式或檔案格式，程式碼所使用的語言，基本的可銷售特質，以及建構項目服務的目的。

(4)界定每個建構項目納入建構管理的時間點。何時將工作產品納入建構管理的準則，舉例如下：
• 當工作產品準備好可進行測試的時候
• 在專案生命週期的各階段
• 工作產品需要某種程度控制的時候
• 成本和時程的界限
• 關鍵人員的需求

(5)界定每個建構項目的負責人。

(6)釐清建構項目間的關係。將建構項目間關係的型態(例如父子，依存等)納入建構管理結構(例如建構管理資料庫)， 有助於管理變更的影響及衝擊。

特定執行方法1.2 (Specific Practice – SP1.2) 建立建構管理系統

建立並維護一個建構管理與變更管理的系統，以便管制工作產品。

建構管理系統包含：儲存媒體、運作程序，以及存取建構系統的工具。依照建構管理環境的適用狀況，建構管理系統可由數個分別以不同方式運作的子系統組成。

變更管理系統包含：儲存媒體、運作程序，以及記錄和存取變更申請的工具。

工作產品舉例：

• 建構管理系統，內含被管制的工作產品
• 建構管理系統的存取控制程序
• 變更申請資料庫

細部執行方法：

(1)在建構管理中，建立多重管制層級的機制。通常會根據專案目標，風險及/或資源來選擇管制層級。管制層級可能因專案生命週期、發展時的系統種類及特定專案需求而異。管制層級，舉例如下:

• 建立-由作者管制
• 工程-當變更發生時，通知相關的關鍵人員
• 發展-由低階建構管制委員會管制
• 正式-由與客戶參與的高階建構管制委員會管制
• 不管制:任何人都可以變更
• 工作進行中:由作者進行變更管理
• 已發行:指定權限進行變更.當變更完成時通知關鍵人員

管制層級可從簡易追蹤發展中建構項目變更的非正式管制到正式建構管理流程變更基準的正式建構管制。

(2)提供建構管理系統存取權限的管控。

(3)在建構管理系統中，存取建構項目。

(4)在建構管理系統的不同程度管制機制下，分享和移轉建構項目。

(5)儲存和復原已歸檔保存的建構項目版本。

(6)儲存、更新及取出建構管理紀錄。

(7)從建構管理系統中，產生建構管理報告

(8)保存建構管理系統的內容。建構管理系統的保存功能，舉例如下：

• 建構管理檔案的備份和復原
  
• 建構管理檔案的歸檔保存
• 建構管理錯誤的復原

(9)必要時，修訂建構管理結構。

特定執行方法1.3 (Specific Practice – SP1.3) 建立或發行基準

建立或發行供內部使用和交付給客戶的基準。

基準是在特定的時間點，藉由對一個或是一組建構項目及相關存在實體，指定其識別名稱來表示。

在產品或是服務的演進過程中，有幾個基準可用來控制其的發展與測試。(有關「基準」的定義，請見詞彙)

基礎環境的建構設定基準(例如軟體，硬體) ，以及準備系統測試(包括硬體與軟體的介面)時，硬體產品，軟體及文件均應包括在內。

基準共通的地方包含系統層次的需求、系統元件層次的設計需求，以及發展結束/製造前的產品定義。這些被稱為「功能基準(functional baseline)」、「配置基準(allocated baseline)」及「產品基準(product baseline)」。

軟體基準可以是已指定唯一識別碼的一組需求、設計、程式碼檔案以及相關的可執行碼、版次檔和使用者文件(相關的項目)。

工作產品舉例：

• 基準
• 基準說明

細部執行方法：

• 在建立或發行建構項目的基準之前，取得建構管制委員會的授權。
• 只有來自建構管理系統的建構項目，才能建立基準或發行基準。
• 記錄基準所含的建構項目。
• 使目前最新的基準，隨時可供使用。

結語

CMMI-DEV V1.3 對於各流程領域在有更清楚及具體的舉例說明. 本文先就建構管理流程領域中第一項特定目標及其特定執行方法的中譯內容以及與V1.2的差異部分提出標示比對說明供讀者參考，正式的中文版本預期在不久後會由資策會領導的翻譯團隊完成並公佈發行。

參考資料

1.SEI. CMMI For Development Version 1.2, CMMI-DEV V1.2, 2007
2.適用於發展的能力成熟度整合模式(CMMI-DEV) 1.2 版,August 2006
3.SEI. CMMI For Development Version 1.2, CMMI-DEV V1.3, Nov 2010