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