前言

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

特定目標2 (Specific Goal-SG2) 追蹤並管制變更

追蹤並管制已納入建構管理工作產品的變更。本特定目標所涵蓋的特定執行方法用來維護基準，這些基準是由「建立基準」特定目標所涵蓋的特定執行方法所建立。

特定執行方法2.1 (Specific Practice – SP2.1) 追蹤變更申請

追蹤建構項目的變更申請不只用於新的需求或需求的變更，也可用於工作產品的故障或缺失。

分析變更申請，以決定此變更對工作產品、相關工作產品、時程及成本的影響。

工作產品舉例

1.變更申請

• 已界定的建構項目

細部執行方法

1.啟動變更申請，並記錄於變更申請資料庫。

2.分析變更建議和所需的修改所造成的影響。藉由活動來評估變更，以便確保此變更與所有的技術需求和專案需求的一致性。評估變更所造成的影響，也應考慮目前專案或合約之外的需求。如建構項目被數個產品所使用，則該建構項目的改變或許可以解決目前的問題，但也可能造成其他應用上的新問題。在發行計畫中記載對變更影響的評估結果。

3.對於變更請求進行分類及排序。辨識緊急的請求並與以適當的緊急授權。變更需加入後續的基準之中。

4.如果變更申請會影響其他基準，應與相關的關鍵人員一起審查這些變更申請，並取得他們的同意。執行變更申請審查時，讓合適的人參與決定，並記錄每一變更申請的處理方法和決策理由，包含成功的準則、簡單的行動計畫及變更是否符合需要等。執行處理方法所提的行動，並將結果告知相關的關鍵人員。

5.追蹤變更申請的狀態直到結案。系統的變更申請，應該用有效和即時的方式處理。一旦開始處理變更申請，重要的是，當已核准的行動已產生作用，應儘速將之結案。若行動一直不結案，結果將不只是更長的待處理狀態清單，它可能導致成本和困擾的增加。

特定執行方法2.2 (Specific Practice – SP2.2) 管制建構項目

需要管制工作產品基準的建構，管制包含追蹤每一建構項目的建構、必要時核准新的建構，並更新基準。

工作產品舉例

• 建構項目的修訂歷史紀錄
• 基準的保存檔(archives)

細部執行方法

• 在整個產品或服務的生命週期，管制建構項目的變更。
• 變更後的建構項目，在納入建構管理系統之前，必須獲得適當的授權。
• 針對同時受某些變更影響的建構項目，在簽入或簽出建構管理系統時，必須設法維護這些建構項目的正確性和完整性。簽入和簽出的步驟，舉例如下：
  • 確認這些修訂已取得授權
  • 更新建構項目
  • 將舊基準歸檔保存，並取出新基準
  • 於建構項目的變更予以說明
  • 將變更連結到相關的工作產品如需求，使用者故事及測試
  
  
• 執行審查，以確保該變更沒有對基準造成意料外的影響。例如：確保變更沒有影響系統的安全及(或)機密。
• 適當記錄建構項目的變更和變更的理由。
  
  如果接受對工作產品的變更建議，則須界定完成修改工作產品及其他受影響部分的時程表。
  
  建構管制機制可以調適成多種變更類別。例如：有些不影響其他組件的組件變更，其核准流程可以較簡化。
  
  已變更的建構項目，須經審查和核准後才能發行。若未經發行，變更並不算正式生效。

特定目標3 (Specific Goal – SG3) 建立完整性

本特定目標為建立並維護基準的完整性。「建立基準」特定目標的流程用於建立基準，「追蹤並管制變更」特定目標的流程用於維護基準，而本特定目標所涵蓋的特定執行方法則用以記錄和稽核基準的完整性。

特定執行方法3.1 (Specific Practice – SP3.1) 建立建構管理紀錄

本特定執行發法為建立並維護描述建構項目的紀錄。

工作產品舉例：

• 建構項目的修訂歷史紀錄
• 變更過程的紀錄
• 變更申請的紀錄
• 建構項目的狀態
• 不同基準間的差異

細部執行方法

1.詳細記錄建構管理活動，使他人知道每個建構項目的內容和狀態，並能復原建構項目的先前版本。
2.確保相關的關鍵人員，能存取和瞭解建構項目的建構狀態。溝通建構狀態資訊的活動，舉例如下：

• 提供存取權限給經授權的最終使用者
• 備妥基準的備份，以供經授權的最終使用者使用
• 當建構項目簽入、簽出、改變或是對於變更請求有所決定時，自動提醒相關關鍵人

3.標示基準的最新版本。
4.界定組成某基準之建構項目的版本。
5.描述前後版本基準間的差異。
6.必要時修訂建構項目的狀態和歷史紀錄(指變更及其他行動)。

特定執行方法3.2 (Specific Practice – SP3.2) 實施建構稽核

實施建構稽核以維護建構基準的完整性。

建構稽核確認最終的基準和文件有遵照特定標準或需求。建構項目相關的紀錄可以存在於多數個資料庫或是建構管理系統中。在這種情況建構稽核應該適當地延伸到這些資料庫中以確保建構項目資訊的正確，持續及完整。

稽核種類舉例如下：

• 功能建構稽核(FCAs):稽核的執行是在驗證建構項目已經圓滿達成其功能基準文件所指定的功能性及品質特質，而且操作及支援文件已完整及滿足。
• 實體建構稽核(PCAs):稽核的執行是在驗證建置的建構項目遵照技術文件的定義。
• 建構管理稽核:稽核的執行是在確認建構管理紀錄及建構項目的完整性、一致性及正確性。

工作產品舉例

• 建構稽核結果
• 待辦

細部執行方法
1.評量基準的完整性。
2.確認建構管理紀錄已正確界定建構項目。
3.審查建構管理系統中，建構項目的結構和一致性。
4.確定建構管理系統中，建構項目的完整性、正確性和一致性。依據計畫中所述的需求和已核准之變更申請的處理為基礎，來判斷內容的完整性和正確性。
5.確定符合適用的建構管理標準和程序。
6.追蹤稽核的行動項目直到結案。

結語

建構管理流程領域在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