CM 系統的主要範疇通常包括:
-
變更要求管理
-
配置管理 (CM)
-
變更追蹤
-
版本選擇
CM 系統也可能包括:
下列 CM 方塊描繪出 CM 系統的主要範疇,並顯示其各方面的相互關係。
-
變更要求管理 (CRM) - 探討在評估現有產品的變更要求所產生的成本、時程,及衝擊時,所需的組織架構。「變更要求管理」主要討論「變更審查小組」或「變更控制委員會」的工作。
-
配置狀態記錄(測量) - 在產品開發期間發現和修正的問題,根據問題的類型、數量、比率及嚴重性,描述產品的「狀態」。在這方面取得的測量值,不論是經由審核或採用原始資料,對於判定專案的整體完成狀態都很有幫助。
-
配置管理 (CM) - 說明產品結構和識別組成的配置項目,在配置管理過程中,這些項目被視為可控制版本的單一實體。CM 包括定義配置、建置和命名,以及將版本化工作成果收集成為構成集合,並維護這些版本的追蹤性。
-
變更追蹤 - 說明對元素採取的動作、原因及時間。可做為變更的歷程和理由。完全不同於「變更要求管理」中對提出的變更所做的影響評估。
-
版本選擇 - 良好「版本選擇」的目的是為了確保選擇正確的配置項目版本來變更或實作。版本選擇依賴穩固的「配置識別」基礎。
-
軟體製造 - 包含軟體發行前的編譯、測試及包裝等步驟的自動化需求。
Rational Unified Process 描述一套綜合性的 CM 系統,涵蓋完整的 CM 範疇。目的是提供有效的 CM 流程,以利於:
-
導入軟體開發流程中。
-
協助管理軟體開發工作成果的進展。
-
讓開發人員在儘可能不干擾開發流程的情況下執行 CM 作業。
Rational CM 流程的目標之一為鼓勵對開發工具中取得之工作成果施以版本控制,同時儘量避免浪費資源來製作印刷文件。
Rational CM 流程的另一個目標是確保能依據工作成果的成熟度探行適當的控制層次。隨著工作成果愈趨成熟,變更權限會從實作人員移轉至子系統或系統整合人員,再移轉至專案管理人員,最後落在客戶身上。
為確保流程的效率,必須確定「變更要求管理」流程相關的行政體系開銷與產品的成熟度保持一致。
例如,在早期的循環階段,「變更要求管理 (CRM)」流程可能比較不正式。在開發生命週期的後期,CRM
流程會愈來愈嚴格,以確保必要測試和文件資源足以應付變更,以及評估變更可能引發的不穩定現象。在開發期間無法調整控制層次的專案,將無法達到最高效率。
|