配置管理系統中的概念

l         結構：表示產品的架構。

l         創建：支持產品的構建及其產品的附件。

l         審核：對產品及其過程的審核予以保留。

l         統計：采集與產品、過程相關的數據。

l         控制：控制產品變更的方式及時間。

l         過程：支持產品演變的管理。

l         團隊協作：促進項目組開發及產品維護。

以下將對這些功能區域的進一步探討。

u        對于元素的要求，用戶要：記錄元素的版本及其差異，差異的原因；確定構成配置及配置版本的組件群；標識出產品的基線及其外延產品，確定表示項目組件群及附件項目環境。而且，用戶需要數據庫來存取組件及CM信息，同時還有資源和對象編碼、執行情況、圖表、文檔和基線。

u        對于機構的要求而言，用戶要：通過表示產品組件庫的系統模型來模擬產品的結構；標明組件、版本、配置的界面使之可以重用；確定及維護組件間的關系；選擇兼容的組件使之形成有效的、一致的產品版本。

u        對構建的要求而言，用戶要：容易創建產品的手段；能隨時靜態分析產品的現狀；通過減少組件的堆積和節省區間來優化系統創建的機制；進行更改分析以預測因更改而導致的細小分化的手段；隨時都能對產品的任何部分、在任何階段容易得到更新。

u        對于審核的要求而言，用戶要：所有更改的歷史記錄；所有與產品相關的組件與其演變的追溯性；完成任務的所有細節的日志。

u        對于統計的要求而言， 用戶要：統計記錄的機制，產品現狀的檢驗，有關產品和過程的所有方面的報告能較易產生。

u        對于控制要求而言，用戶要：為避免不必要的變更或變更沖突對系統中的組件的獲取應予以控制，對于更改要求的表格及問題報告形成在線支持；錯誤查找的手段及何時對何人會產生什么影響；在不同但相關的產品版本之間以受控的方式進行更改告知；將產品進行分割的手段以限制更改影響。

u        對于過程要求而言，用戶要：對生命周期模型及組織方針予以支持；確定要完成的任務及如何完成、何時完成的能力；將相干的事務的訊息在適當的人員之間進行溝通的能力；將產品的經驗文檔化的手段。

u        對于團隊協作的要求而言， 用戶要：個人和小組的工作區間；在匯合時產生沖突的解決辦法；對產品的創建及其維護予以支持的手段。

注意：圖中過程方框與團隊方框代表功能區域極為重要的部分。這是因為它們影響所有其它區域或受到所有其它區域的影響。對于用戶來講，理想的CM系統隨團隊協作和過程的完全融合應當能支持所有的功能區域。但目前還沒有此類系統。

任何CM系統在某種程度上都能與它的環境融合。CM系統可與其它工具并存或完全融合。適合與不同環境方面融合的有：過程、工具組和數據庫。過程集成是將CM系統的使用模式（指CM過程）同環境的使用模式（指軟件生命周期過程）的結合；工具組的集成是將CM系統安裝在環境中使之至少能環境中其它所有工具共存。譬如，在編輯過程中， 每當用戶發出“SAVE”命令時，用戶就會要求CM功能能建立一新的版本。數據集成指的是CM數據庫的邏輯定位——它是否能與現存環境的數據庫能做某種方式的合并，或它的數據庫是否獨立存在的，或它能否利用其它數據庫中的信息。所有此類集成都是普通的工具集成和技術的轉換問題。但，由于CM將影響到環境中的絕大部分物件并貫穿每一物件生命周期的所有階段，CM系統的集成勢必對環境中的很多工具有重要影響。大多數CM系統能與其它工具共存，有些環境把CM看成其必不可少的一部分。

對于在開發和維護產品過程中, 項目組何時啟用CM系統是不定的。有些項目組選擇在產品經歷開發生命周期并準備發到用戶地時開始啟用。有的選擇在項目一開始就將一切置于CM下。二者都有各自的一般費用。譬如，項目組可能基于變更要求的費用上來決定何時啟用。如果有許多的手工程序（如：將變更申請表歸檔、尋求CCB的批準與確認可），項目組會選擇在大部分開發完成之后將軟件置于CM的控制之下。但如果變更要求程序能在線很快地得到處理，CM將在軟件生命周期的早期就被用上。理論上講，CM在產品的整個生命周期都能派上用場 —— 從創建、開發、產品發放、交付、使用到維護。在理想的情形下，CM能在較少的花費下對此予以支持，由此CM才能在項目中盡可能早地予以應用。

然而，現有的CM系統只關注生命周期的某一特定的階段，用戶因此受到限制。

文章來源于領測軟件測試網 http://www.kjueaiud.com/