功能
并行開發支持
因開發和維護的原因，要求能夠實現開發人員同時在同一個軟件模塊上工作，同時對同一個代碼部分作不同的修改，即使是跨地域分布的開發團隊也能互不幹擾，協同工作，而又不失去控制。
修訂版管理
跟蹤每一個變更的創造者、時間和原因，從而加快問題和缺陷的确定。
版本控制
能夠簡單、明确地重現軟件系統的任何一個曆史版本。
産品發布管理：管理、計劃軟件的變更，與軟件的發布計劃、預先定制好的生命周期或相關的質量過程保持一緻。項目經理能夠随時清晰地了解項目的狀态。
管理過程
建立管理
基于軟件存儲庫的版本控制功能，實現建立（build）過程自動化。
過程控制
貫徹實施開發規範，包括訪問權限控制、開發規則的實施等。
變更請求管理：跟蹤、管理開發過程中出現的缺陷（Defect）、功能增強請求（RFE）或任務（Task），加強溝通和協作，能夠随時了解變更的狀态。
代碼共享
提供良好的存儲和訪問機制，開發人員可以共享各自的開發資源。
實施
實施配置管理系統，一般的步驟和需要考慮的問題如下：
規劃、調整網絡開發環境
一個規劃良好的開發環境，是實施配置管理系統的前提。在此階段我們要對配置管理系統做出規劃，主要考慮以下問題：
網絡的帶寬、拓撲結構
服務器的選擇、命名規範
存儲區的定位
開發人員及組的命名規約等
設計配置管理庫
根據項目開發的要求，設計開發資源的存儲模式，良好的存儲模式有利于減輕管理上的負擔，增強配置管理庫的訪問性能，同時便于控制訪問權限，保護軟件資産。
定義配置管理系統的角色
在此階段，我們需要确定與配置管理相關的所有角色，包括他們的相應的活動。在開發過程中，一個開發人員可能兼任多種角色，但一項任務在同一時刻隻能由一個角色來執行。
一般配置管理中的角色主要包括：
項目經理：項目經理在配置管理方面的職責是依靠配置管理員、系統管理員和系統體系結構設計人員的幫助，制定項目的組織結構和配置管理策略。這些工作包括：定制開發子系統，定制訪問控制，制定常用策略，制定集成裡程碑，以及進行系統集成。
配置管理員：配置管理員的職責是根據項目經理制定的開發組織結構和策略，實施、維護配置管理的環境。其主要職責如下：創建配置管理庫，對存儲庫進行日常備份和恢複，維護配置管理環境，及管理配置管理相關的用戶。
軟件開發人員：軟件開發人員依據項目的開發和配置管理策略，創建、修改和測試開發工件。
集成人員：對軟件進行歸并，形成相應的基線或發布版本。
QA人員：需要對軟件配置管理有較深的認識，其主要工作是跟蹤當前項目的狀态，測試，報告錯誤，并驗證其修複結果。
制定配置管理流程
這是配置管理實施的一個重要階段，其主要目的是根據項目開發的需要，制定相應的配置管理流程，以更好地支持開發，主要活動包括：
定制并行開發策略：合理的并行開發策略應該具有以下特點：協調項目的複雜性和需求，統一創建分支類型和元數據，為開發過程中的變更集成制定有效的規範，适時反映開發過程中方法和需求的變化。
發布版本管理：軟件開發過程中的一個關鍵活動是提取工件的相關版本，以形成軟件系統的階段版本或發布版本，我們一般将其稱為穩定基線。一個穩定基線代表新開發活動的開始，而一系列定制良好的活動之後又會産生一個新的穩定基線。有效地利用此項功能，在項目開發過程中可以自始至終管理、跟蹤工件版本間的關聯。
一般來講，實施配置管理系統，相關人員需要接受以下培訓：
管理員培訓：針對配置管理員，主要學習配置管理工具管理相關内容。
開發人員培訓：針對開發人員，主要學習配置管理工具與開發相關的常用操作。
管理流程培訓：針對全體人員，目的是了解配置管理策略和流程，以及如何與開發管理、項目管理相結合。
經驗
圍繞配置管理,世界一些緻力于軟件工程研究的公司在深入理解ISO9000的基礎上,推出了各種符合ISO9000配置管理标準的工具軟件,如INTERSOLV公司的PVCS,Rational公司的ClearCase等。這些配置管理工具面向軟件規範化、工程化、自動化的需要,幫助開發團隊提高科學管理水平,從而提高工程效率,降低工程成本。
現以PVCS為例,結合我們的實際經驗,談談我們實施配置管理的益處:
節約費用
(1)縮短開發周期
利用PVCS的VersionManager對程序資源進行版本管理和跟蹤,建立公司的代碼知識庫,保存開發過程中每一過程版本,這樣大大提高了代碼的重用率,還便于同時維護多個版本和進行新版本的開發,防止系統崩潰,最大限度地共享代碼。同時項目管理人員可以通過VersionManager查看項目開發日志,測試人員可以根據開發日志和不同版本對軟件進行測試,工程人員可以從VersionManager上得到不同的運行版本,并且VersionManager可以安裝在WebServer供外地施工人員存取最新版本,無需開發人員親臨現場。
利用Tracker組建開發團體之間的問題跟蹤及消息通迅,通過其Notify模塊與電子郵件結合起來大大加強了開發團體之間的溝通,Reporter模塊可對發現的問題進行整理、以報表方式分類報出,作為開發的指導。
以上為PVCS的兩個主要模塊,科學地應用可以大大提高開發效率,避免了代碼複蓋、溝通不夠、開發無序的混亂局面,如果利用了公司原有的知識庫,則更能提高工作效率,縮短開發周期。
(2)減少施工費用
利用PVCS進行軟件配置管理後,建立開發管理規範,把版本管理檔案挂接在公司内部的Web服務器上,内部直接通過Netscape訪問VersionManager,工程人員通過遠程進入内部網,獲取所需的最新版本。開發人員無需下現場,現場工程人員通過對方系統管理員收集反饋意見,書面提交到公司内部開發組項目經理,開發組内部讨論決定是否修改,并作出書面答複。這樣做,可以同時響應多個項目點,防止開發人員分配到各個項目點、分散力量、人員不夠的毛病,同時節約大量的旅差費用。
有利于知識庫的建立
(1)代碼對象庫
軟件代碼是軟件開發人員腦力勞動的結晶,也是軟件公司的寶貴财富,長期開發過程中形成的各種代碼對象就像一個個零件坯一樣,是快速生成系統的組成部分。長期的一個事實是:一旦某個開發人員離開工作崗位,其原來所作的代碼便基本成為垃圾,無人過問。究其原因,就是沒有專門對各人的有用對象進行管理,把其使用範圍擴大到公司一級,進行規範化,加以說明和普及。VersionManager為對象管理提供了一個平台和倉庫,有利于建立公司級的代碼對象庫。
(2)業務及經驗庫
通過PVCSVersionManager的注釋及Tracker,可形成完整的開發日志及問題集合,以文字方式伴随開發的整個過程,不依某個人的轉移而消失,有利于公司積累業務經驗,無論對版本整改或版本升級,都具有重要的指導作用。
規範管理
(1)量化工作量考核
傳統的開發管理中,工作量一直是難以估量的指标,靠開發人員自己把握,随意性相當大;靠管理人員把握,主觀性又太強。采用PVCS管理後,開發人員每天下班前對修改的文件CheckIn,其中記述當天修改細節描述,這些描述可以作為工作量的衡量指标。
(2)規範測試
采用PVCS以後,測試有了實實在在的工作,測試工作人員根據每天的修改細節描述對每一天的工作做具體的測試,對測試人員也具有可考核性,這樣環環相扣,大大減少了其工作的随意性。
(3)加強協調與溝通
采用PVCS後,通過VersionManager文檔共享及其特定鎖機制、Tracker與電子郵件的集成,大大加強了項目成員之間的溝通,做到有問題及時發現、及時修改、及時通知,但又不額外增加很多的工作量。
精髓
具體來講，配置管理包含如下内容：
¾标識：識别産品的結構、産品的構件及其類型，為其分配唯一的标識符，并以某種形式提供對它們的存取。
¾控制：通過一定的機制控制對配置項的修改。
¾狀态報告：記錄并報告配置項以及元數據的狀态。
¾配置審計：确認産品的完整性并維護配置項間的一緻性。
從上面的描述，我們知道，配置管理的基本單位是配置項。
從“哲學”意義上講，它記錄配置項的三個方面：
¾從哪裡來？此項可歸結為WWW的問題，（Who）誰創建的？（When）什麼時間創建的？（Why）為什麼創建此配置項？
¾當前在哪裡？此項紀錄配置項當前的存儲位置以及狀态。
¾将到哪裡去？通過配置控制來把配置項“組裝”到正确的版本中去。
配置項可以是大粒度的，也可以是小粒度的。如果跟蹤個别需求，那麼不必要把整個需求規格說明文檔定義為一個配置項，可以把每個需求定義為配置項。如果把軟件開發工具也放入配置管理系統，那麼把配置項定義為文件級就不合适了，隻需要跟蹤開發工具的版本，即把整個配置工具定義為一個配置項就足夠了。
簡而言之，配置項可以是文件級粒度的，也可以是文件版本級粒度的。當然，粒度越小管理的成本越高，但是配置的精度也就越高。
一個完整的SCM系統要具有三個核心功能：版本控制、變更控制、配置控制以及兩個支持功能：狀态統計和配置審計。
版本控制
版本，亦稱配置标識，是指某一特定對象的具體實例的潛在存在。這裡的某一特定對象是指版本維護工具管理的軟件組成單元，一般是指源文件。具體實例則是指軟件開發人員從軟件庫中恢複出來的某軟件組成單元的具有一定内容和屬性的一個真實拷貝。例如，對源文件的每一次修改都生成一個新版本。
版本控制就是對在軟件開發過程中所創建的配置對象的不同版本進行管理，保證任何時候都能取到正确的版本以及版本的組合。
當前，這方面典型的工具有如VSS和CVS。
變更控制
變更控制是通過對變更請求（ChangeRequest，簡稱CR）進行分類、追蹤和管理的過程來實現的。
變更的起源有兩種：功能變更和缺陷修補（Bug-Fix）。功能變更是為了增加或者删除某些功能。缺陷修補則是對已存在的缺陷進行修補。
對變更進行控制的機構稱為變更控制委員會（ChangeControlBoard，簡稱CCB）。變更控制委員會要定期召開會議，對近期所産生的變更請求進行分析、整理，并做出決定。而且要遵循一定的變更機制。
下面是一個典型的變更機制：
我們可以随着變更過程的推進，提升配置項的狀态。這方面的工具有Bugzilla。
配置控制
配置控制使用戶能夠通過對适當版本的選擇來組成特定屬性（配置）的軟件系統，這種靈活的“組裝”策略使得配置管理系統象搭積木似的使用已有的積木（版本）組裝成各種各樣、不同功能的模型。
軟件産品的每個版本都是一組配置項（源代碼、文檔、數據）的集合。配置控制就是要保證每個配置的完整性和精确性。
舉個例子來說，我們要發布軟件的32.6版本，那麼我們就要把源代碼、文檔、數據中所有這個應該包含到這個版本中的正确配置項檢出。
在開發過程中，我們在不同階段要建立各種基線。基線的建立是配置控制功能的典型應用。所以說，基線是具有裡程碑意義的一個配置。
一般的商業軟件配置管理工具都具有配置控制的功能，隻是靈活性和精确性有差别。
狀态報告
狀态報告要回答所謂4W的問題：
What：發生了什麼事？
Who：誰做的此事？
When：此事是什麼時候發生的？
Why：為什麼做此事？
狀态報告還要能夠報告所有配置項以及變更請求的狀态。
配置審計
配置審計要審查整個配置管理過程是否符合規範，配置項是否與需求一緻，記錄正确，配置的組成是否具有一緻性等等。
由于現在軟件行業越來越重視質量，許多項目專門成立質量保證部門專門來進行配置審計。所以現在也可以說，配置審計是一個SQA（軟件質量保證）活動。
配置管理的商業模型
配置管理的實施包括兩部分：工具和規範。
在軟件開發過程自動化的今天，沒有工具的支持而實施配置完整的配置管理是不能想象的。因此選擇一個符合公司或項目的工具至關重要。在配置管理系統中，我們可歸納出四種模型。當前商業工具一般采用其中一種或幾種模型。
我們通過對商業模型的理解可以幫助我們了解某種工具是否适合我們公司或項目。
CICO模型
CICO模型主要關注的是單個文件的版本控制。圖顯示了一個支持CICO模型的CM系統的工作過程。用戶利用庫和文件系統來進行工作。文件被版本化并存儲到庫中，新版本的産生是由庫工具控制的。然而，文件在庫中不是可以直接存取的，用戶必須去檢出（即CheckOut）一個文件的版本到工作空間中以便讀取它的内容。更改後的文件可以被檢入庫中（即Checkin）,産生文件的一個新版本。
此模型的代表工具是SCCS和CVS。
組織模型
組織模型由CICO模型自然導出，建立于構件版本圖的基礎之上，同時依賴于存儲庫和工作空間的概念，可以通過對構件加鎖進行并發控制。組織模型的重點是在CM系統支撐下加強了對創建配置、對有關的曆史信息的管理和使用他們作為工作環境的支持。
組織模型中的配置由系統模型和版本選擇規則組成。系統模型列出了組成系統的所有的構件。版本選擇規則指出了組成配置的每一個構件選擇版本。選擇規則用于系統模型，選擇構件版本，即綁定一構件到某一版本。這個模型的操作方式是：開發員根據模型的構件定義整個系統，并在每一步驟中給每個構件選擇合适的版本。版本操作的工作方式如圖所示。
CM支持主要關心的是維護系統和其構件的版本曆史，并選擇符合一緻性配置的構件版本。隻有在所選構件的版本與所選其它構件版本一緻時才認為一個配置版本。
此模型的代表工具是CCC。
長事務模型
長事務模型主要支持包括一系列原子變更的全系統演變和由團隊開發員對系統變更的協調。開發員主要操作配置而非單獨的構件。事務提交的結果是新配置版本，一系列連續的變更結果生成一系列的配置版本，稱為開發路徑。
在長事務模型中，開發員主要的工作對象時配置，開發員首先選擇系統配置版本，接下來把關注重點放在系統結構上。構件的版本由配置隐式決定。長事務由兩個概念組成：工作空間和并發控制方案。工作空間來源于存儲庫或一個封閉工作空間中的一個固定配置。工作空間由工作配置和一系列已保存的配置組成。工作配置代表構件和系統結構能夠被動态更改的配置。提供通過工作空間進行的透明庫訪問、将高效的庫存儲技術應用于工作空間和管理派生構件的版本。
此模型的代表系統是NSE。
變更集模型
主要集中于對系統配置的邏輯變更的支持。在這個模型中引入的變更集表示組成邏輯變更的對不同構件修改的集合，它是創建變更的活動完成後對邏輯變更的記錄。支持這個模型的CM系統用戶可以直接操作變更集。在變更集模型中，配置可描述為由基線和一組變更集組成。
變更傳播給其它配置可通過包含各自變更集來進行。開發員使用不同的集成策略将邏輯變更集包含到一個新的系統發行中。這樣的好處非常明顯，例如，我們現在維護10個不同版本的産品，現在要對所有的版本修改一個缺陷（Bug）。如果相同的工具簡單的重複10次顯然是不可接受的。而通過變更集把這個邏輯變更從一個版本自由的傳到另外一個版本。
開發員可跟蹤邏輯變更和确定這些變更是否屬于特定配置。這種配置管理的方法，因為其将重點放于邏輯變更上，所以被稱作面向變更的配置管理。它不同于現在的其他3種CM模型，因為其它3種CM模型使用的面向版本的方法把重點放在構件和配置版本上。
在單一構件的情況下，變更集是兩個文件版本之間區别的集合，通常指的是增量内容。對配置來說，變更集就是兩個配置版本之間區别的集合。這組區别就是兩個配置版本間的修改構件增量集合，即變更構件集的增量。
面向變更的觀點不同于面向版本的觀點。這有兩點不同，一是邏輯變更的顯式表示允許對與單個構件和配置有關的變更集進行跟蹤。二是引用單個變更集并有選擇地将它們納入配置管理中的這種能力提供了對系統演化管理的支持，這種演化是基于将邏輯變更傳播到維護的系統配置進行的。
此模型的代表工具是UCM和SABLIME。
