配置管理的概念源于美國空軍，為了規范設備的設計與制造，美國空軍1962年制定并發布了第一個配置管理的標準“AFSCM375-1，CM During the Development & Acquisition Phases”。
而軟件配置管理概念的提出則在20世紀60年代末70年代初。當時加利福利亞大學圣巴巴拉分校的Leon Presser教授在承擔美國海軍的航空發動機研制合同期間，撰寫了一篇名為“Change and Configuration Control”的論文，提出控制變更和配置的概念，這篇論文同時也是他在管理該項目（這個過程進行過近一千四百萬次修改）的一個經驗總結。
Leon Presser在1975年成立了一家名為SoftTool的公司，開發了配置管理工具：Change and Configuration Control（CCC），這是最早的配置管理工具之一。
隨著軟件工程的發展，軟件配置管理越來越成熟，從最初的僅僅實現版本控制，發展到現在的提供工作空間管理、并行開發支持、過程管理、權限控制、變更管理等一系列全面的管理能力，已經形成了一個完整的理論體系。同時在軟件配置管理的工具方面，也出現了大批的產品，如：最著名的ClearCase；開源產品CVS；入門級工具Microsoft VSS；新秀Hansky Firefly。
在國外已經有30多年歷史的軟件配置管理，但在國內的發展卻是在21世紀這幾年的事。但是通過專家們的介紹，我們感受到，國內的軟件配置管理已經取得了迅速發展，并得到了軟件公司的普遍認可。
二、軟件配置管理的基本目標
軟件配置管理是在貫穿整個軟件生命周期中建立和維護項目產品的完整性。它的基本目標包括：
目標 1: 軟件配置管理的各項工作是有計劃進行的。
目標 2: 被選擇的項目產品得到識別，控制并且可以被相關人員獲取。
目標 3: 已識別出的項目產品的更改得到控制。
目標 4: 使相關組別和個人及時了解軟件基準的狀態和內容。
三、XSSC有關軟件配置管理的方針
為了達到上述目標， 如下的方針應該得到貫徹執行：
技術部門經理和具體項目主管應該使用和遵循XSSC的OSSP中所描述的軟件配置管理的工作過程。
施行軟件配置管理的職責應被明確分配。相關人員得到軟件配置管理方面的培訓。
技術部門經理和具體項目主管應該明確他們在相關項目中所擔負的軟件配置管理方面的責任。
軟件配置管理工作應該享有足夠的資金支持，這需要在客戶，技術部門經理和具體項目主管之間協商。
軟件配置管理應該實施于如下產品：對外交付的軟件產品，以及那些被選定的在項目中使用的支持類工具等。
軟件配置的整體性在整個項目生命周期中得到控制。
軟件質量保證人員應該定期審核各類軟件基準以及軟件配置管理工作。
使軟件基準的狀態和內容能夠及時通知給相關組別和個人。
四、常用的軟件配置管理工具
現在常用的軟件配置管理工具主要分為三個級別：
l Rational ClearCase，CA CCC/Havest
l Merant PVCS
l Microsoft VSS，CVS
五．軟件配置管理角色職責
對于任何一個管理流程來說，保證該流程正常運轉的前提條件就是要有明確的角色、職責和權限的定義。特別是在引入了軟件配置管理的工具之后，比較理想的狀態就是：組織內的所有人員按照不同的角色的要求、根據系統賦予的權限來執行相應的動作。因此，在本文所介紹的這個軟件配置管理過程中主要涉及下列的角色和分工：
項目經理（Project Manager，PM）：
項目經理是整個軟件研發活動的負責人，他根據軟件配置控制委員會的建議批準配置管理的各項活動并控制它們的進程。其具體職責為以下幾項：
1、制定和修改項目的組織結構和配置管理策略；
2、批準、發布配置管理計劃；
3、決定項目起始基線和開發里程碑；
4、接受并審閱配置控制委員會的報告。
配置控制委員會（Configuration Control Board，CCB）：
負責指導和控制配置管理的各項具體活動的進行，為項目經理的決策提供建議。其具體職責為以下幾項：
1、定制開發子系統；
2、定制訪問控制；
3、制定常用策略；
4、建立、更改基線的設置，審核變更申請；
5、根據配置管理員的報告決定相應的對策。
配置管理員（Configuration Management Officer，CMO）：
根據配置管理計劃執行各項管理任務，定期向CCB提交報告，告，并列席CCB的例會。其具體職責為以下幾項：
1、軟件配置管理工具的日常管理與維護；
2、提交配置管理計劃；
3、各配置項的管理與維護；
4、執行版本控制和變更控制方案；
5、完成配置審計并提交報告；
6、對開發人員進行相關的培訓；
7、識別軟件開發過程中存在的問題并擬就解決方案。
系統集成員（System Integration Officer，SIO）：
系統集成員負責生成和管理項目的內部和外部發布版本，其具體職責為以下幾項：
1、集成修改；
2、構建系統；
3、完成對版本的日常維護；
4、建立外部發布版本。
開發人員（Developer，DEV）：
開發人員的職責就是根據組織內確定的軟件配置管理計劃和相關規定，按照軟件配置管理工具的使用模型來完成開發任務。
六．軟件配置管理過程描述
一個軟件研發項目一般可以劃分為三個階段：計劃階段、開發階段和維護階段。然而從軟件配置管理的角度來看，后兩個階段所涉及的活動是一致，所以就把它們合二為一，成為“項目開發和維護”階段。
項目計劃階段：
一個項目設立之初PM首先需要制定整個項目的計劃，它是項目研發工作的基礎。在有了總體研發計劃之后，軟件配置管理的活動就可以展開了，因為如果不在項目開始之初制定軟件配置管理計劃，那么軟件配置管理的許多關鍵活動就無法及時有效的進行，而它的直接后果就是造成了項目開發狀況的混亂并注定軟件配置管理活動成為一種“救火”的行為。所以及時制定一份軟件配置管理計劃在一定程度上是項目成功的重要保證。
在軟件配置管理計劃的制定過程中，它的主要流程應該是這樣的：
CCB根據項目的開發計劃確定各個里程碑和開發策略；
CMO根據CCB的規劃，制定詳細的配置管理計劃，交CCB審核；
CCB通過配置管理計劃后交項目經理批準，發布實施。
項目開發維護階段：
這一階段時項目研發的主要階段。在這一階段中，軟件配置管理活動主要分為三個層面：（1）主要由CMO完成的管理和維護工作；（2）由SIO和DEV具體執行軟件配置管理策略；（3）變更流程。這三個層面是彼此之間既獨立又互相聯系的有機的整體。
在這個軟件配置管理過程中，它的核心流程應該是這樣的：（1）CCB設定研發活動的初始基線；（2）CMO根據軟件配置管理規劃設立配置庫和工作空間，為執行軟件配置管理就阿做好準備；（3）開發人員按照統一的軟件配置管理策略，根據獲得的授權的資源進行項目的研發工作；（4）SIO按照項目的進度集成組內開發人員的工作成果，并構建系統，推進版本的演進；（5）CCB根據項目的進展情況，審核各種變更要求，并適時的劃定新的基線，保證開發和維護工作有序的進行。
這個流程就是如此循環往復，直到項目的結束。當然，在上述的核心過程之外，還涉及其他一些相關的活動和操作流程，下面按不同的角色分工予以列出：
各開發人員按照項目經理發布的開發策略或模型進行工作；
SIO負責將各分項目的工作成果歸并至集成分支，供測試或發布；
SIO可向CCB提出設立基線的要求，經批準后由CMO執行；
CMO定期向項目經理和CCB提交審計報告，并在CCB例會中報告項目在軟件過程中可能存在的問題和改進方案；
在基線生效后，一切對基線和基線之前的開發成果的變更必須經CCB的批準；
CCB定期舉行例會，根據成員所掌握的情況、CMO的報告和開發人員的請求，對配置管理計劃作出修改，并向項目經理負責。
綜上所述，配置管理的工作流程如圖1所示：
七. 軟件配置管理的關鍵活動
1．配置項（Software Configuration Item，SCI）識別
Pressman對于SCI給出了一個比較簡單的定義：“軟件過程的輸出信息可以分為三個主要類別：（1）計算機程序（源代碼和可執行程序），（2）描述計算機程序的文檔（針對技術開發者和用戶），以及（3）數據（包含在程序內部或外部）。這些項包含了所有在軟件過程中產生的信息，總稱為軟件配置項�！�
由此可見，配置項的識別是配置管理活動的基礎，也是制定配置管理計劃的重要內容。
軟件配置項分類軟件的開發過程是一個不斷變化著的過程，為了在不嚴重阻礙合理變化的情況下來控制變化，軟件配置管理引入了“基線（Base Line）”這一概念。IEEE對基線的定義是這樣的：“已經正式通過復審核批準的某規約或產品，它因此可作為進一步開發的基礎，并且只能通過正式的變化控制過程改變�！�
所以，根據這個定義，我們在軟件的開發流程中把所有需加以控制的配置項分為基線配置項和非基線配置項兩類，例如：基線配置項可能包括所有的設計文檔和源程序等；非基線配置項可能包括項目的各類計劃和報告等。
配置項的標識和控制
所有配置項都都應按照相關規定統一編號，按照相應的模板生成，并在文檔中的規定章節（部分）記錄對象的標識信息。在引入軟件配置管理工具進行管理后，這些配置項都應以一定的目錄結構保存在配置庫中。
所有配置項的操作權限應由CMO嚴格管理，基本原則是：基線配置項向軟件開發人員開放讀取得權限；非基線配置項向PM、CCB及相關人員開放。
2．工作空間管理
在引入了軟件配置管理工具之后，所有開發人員都會被要求把工作成果存放到由軟件配置管理工具所管理的配置庫中去，或是直接工作在軟件配置管理工具提供的環境之下。所以為了讓每個開發人員和各個開發團隊能更好的分工合作，同時又互不干擾，對工作空間的管理和維護也成為了軟件配置管理的一個重要的活動。
一般來說，比較理想的情況是把整個配置庫視為一個統一的工作空間，然后再根據需要把它劃分為個人（私有）、團隊（集成）和全組（公共）這三類工作空間（分支），從而更好的支持將來可能出現的并行開發的需求。
每個開發人員按照任務的要求，在不同的開發階段，工作在不同的工作空間上，例如：對于私有開發空間而言，開發人員根據任務分工獲得對相應配置項的操作許可之后，他即在自己的私有開發分支上工作，他的所有工作成果體現為在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素；而集成分支對應的是開發團隊的公共空間，該開發團隊擁有對該集成分支的讀寫權限，而其他成員只有只讀權限，它的管理工作由SIO負責；至于公共工作空間，則是用于統一存放各個開發團隊的階段性工作成果，它提供全組統一的標準版本，并作為整個組織的Knowedge Base。
當然，由于選用的軟件配置管理工具的不同，在對于工作空間的配置和維護的實現上有比較大的差異，但對于CMO來說，這些工作是他的重要職責，他必須根據各開發階段的實際情況來配置工作空間并定制相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。
3．版本控制
版本控制是軟件配置管理的核心功能。所有置于配置庫中的元素都應自動予以版本的標識，并保證版本命名的唯一性。版本在生成過程中，自動依照設定的使用模型自動分支、演進。除了系統自動記錄的版本信息以外，為了配合軟件開發流程的各個階段，我們還需要定義、收集一些元數據（Metadata）來記錄版本的輔助信息和規范開發流程，并為今后對軟件過程的度量做好準備。當然如果選用的工具支持的話，這些輔助數據將能直接統計出過程數據，從而方便我們軟件過程改進（Software Process Improvement，SPI）活動的進行。
對于配置庫中的各個基線控制項，應該根據其基線的位置和狀態來設置相應的訪問權限。一般來說，對于基線版本之前的各個版本都應處于被鎖定的狀態，如需要對它們進行變更，則應按照變更控制的流程來進行操作。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
