作業: 建立配置管理 (CM) 原則
這項作業說明如何開發 CM 原則,包括「配置確認慣例」、「基準線設定慣例」、「保存慣例」及「配置報告需求」。
規範: 配置 變更管理
目的

這項作業的目的是建立專案配置管理原則,用來監督和保護專案資產,以及實施軟體開發慣例。 專案原則應該改善團隊成員之間的溝通,同時減少整合工作時所遭遇的問題。 

關係
步驟
定義配置確認慣例
目的:確認工作成果並儲存在安全的儲存庫中 
工具輔助: 使用 Rational ClearCase 建立基準線 

配置確認是一項核心的配置管理工作,由 IEEE 定義為「配置管理的一項元素,包括選取系統的配置項目,並將功能和實體性質記錄在技術文件中」。 以軟體配置管理而言,配置確認是指有能力迅速輕鬆地找出並確認任何專案工作成果的正確版本。 對於無效率的配置確認系統,以時間和品質的喪失來衡量負面影響。

標籤可識別工作成果的特定版本。構成一個子系統版本的工作成果,可以全體和個別地透過特定版本和標籤來識別。 因此,標籤很合合重複使用或參照最初的版本化工作成果集。

以下是建議的產品層次工作成果標示慣例,適用於產品目錄結構中標示路徑和工作成果。

<SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<SYSTEM> 代表系統

<A> 代表三個縮寫字母 (TLA!). 適用於建立系統時所用的各種工作成果。例如,

PLN  專案計劃 
REQ  需求檔 
USC  使用案例 
MOD  模型檔 
SRC  程式碼檔案 
INT  公用介面 
TST  測試 Script 和結果 
DOC  文件(使用者、版本注意事項) 
BIN  執行檔 

<SUBSYSTEM> 代表每一個子系統

<A> 代表三個縮寫字母,用於建立子系統時所用的各種工作成果。與上表一致。

R|A|B  代表 Release(版本)、Alpha(內部測試版)或 Beta(外部測試版) 
<X>  整數,代表主要版本(例如 1) 
<Y>  整數(選用),代表次要版本 
<Z>  整數(選用),代表替代版本(修補程式、埠等) 
BL  代表基本層次(內部版本) 
整數,用於內部版本 

以下是一些範例:

T2K_R1.0  Thorn 2000 系統版本 1 
T2K_GUI_R2.0.BL5  GUI 系統內部版本,預計於版本 2 發佈 
T2K_B1.1  Thorn 2000 系統測試版 1.1 
T2K_R2.0.BL16  Thorn 2000 內部系統基準線 #16,用於建立版本 2 
T2K_R1.0.5  Thorn 2000 的維護版本 
定義基準線設定慣例

基準線提供專案工作成果的一個固定點和 Snapshot。概念:設定基準線描述在專案生命週期內何時需要建立基準線。此步驟提供進一步的慣例指引。

基準線代表檔案和目錄版本的固定組合,且是在特定的專案里程碑上建立。 子系統或整個系統可以建立基準線。基準線應該依照前一個流程步驟(定義工作成果標示慣例)所描述的方法來定義。

建立基準線時必須釐清您是否要建立:

  • 「子系統基準線」,包含子系統中已修改的檔案和目錄的「全部」版本。
  • 「系統基準線」,包含所有子系統中所有檔案和目錄的「單一」版本。

一般而言,在主要和次要專案里程碑上建立「系統基準線」,以及視需要或經常建立「子系統基準線」,將有助於版本管理。 根據「經驗法則」,當子系統中有 30% 以上的元素變更時,最好建立基準線。

定義保存慣例

這個步驟的目的是確保專案軟體及相關資產(主要文件)將備份、分類並轉送至指定的儲存位置。 保存工作在重複使用上或發生災難時會發揮作用。因此,必須定期且在主要和次要里程碑上執行保存工作。

建立保存標籤時,可以採用稍早在流程步驟「定義工作成果標示慣例」中說明的標示準則。 然而,可能需要其他資訊來表示實際的媒體要存放何處。例如:

序號  123456789 
卷  1 / 3 
儲藏室  B5 
儲存日期  99/06/21 

所有產品相關資訊應該存放在資料庫上,以利於發行和重複使用。

定義配置狀態報告需求
目的 變更活動是專案狀態和趨勢的重大指標。此流程步驟的目的是讓「專案經理」定義要報告產品的哪些相關的變更資料、由誰報告及報告頻率。 
子步驟:  
工具輔助:  

配置狀態報告(如果使用)描述建立「配置狀態報告」的各種來源。

選取以變更要求為主的報告 頁面頂端

在此,您應該選擇可從已送至專案的變更要求中所衍生的報告。 有許多有用的「變更要求」報告。

在「經歷時間」種類下,可以按照一週或一個月期間的變更要求數量,依據下列準則來要求報告:

  • 已提出
  • 已指派
  • 已解決
  • 優先順序

依狀態列出問題,有助於研判專案接近完工的程度如何。比方說,如果已解決大多數問題,則比大多數問題仍停留在提出狀態下更接近完工。

在「分佈」種類下,可以要求報告回答下列幾種問題:

  • 誰在專案的什麼時候發現何種缺失?
  • 問題指派給誰處理?
  • 某位工程師有多少未解決的問題?
  • 發現的缺失有多嚴重?
  • 流程的何處造成問題(起因)?
  • 何時解決問題?
  • 有多少缺失?
  • 這些缺少有多嚴重?

這些測量值有助於分析工作量、誰正在處理最嚴重的問題,以及多快可以解決問題。

在「趨勢」種類下,可以要求報告回答下列幾種問題:

  • 本日、本週或本月有多少未解決的缺失?
  • 本日、本週或本月已解決多少缺失?

這項資料有利於評估修復率,可顯示工程效率。

定義報告頻率 頁面頂端

確定適時收到報告,以提供有效的意見做為決策參考。可依據下列期間來要求報告:

  • 每日 - 不太可能以此頻率來要求報告
  • 每週 - 趨勢、分佈和計數報告、建置報告
  • 每月 - 趨勢、分佈和計數報告、建置報告
  • 依反覆 - 趨勢、分佈和計數報告、建置報告、版本說明
  • 依階段 - 趨勢、分佈和計數報告、審核、建置報告、版本說明
  • 專案結束 - 趨勢、分佈和計數報告、審核、建置報告、版本說明


詳細資訊