本文主要從CMM和CMMI的要求出發，介紹了標準主要涉及的配置管理內容，并對相應內容進行初步地說明，最后提供了一個配置管理在項目實施的指南和一個在組織中部署配置管理的模型。
1 配置管理內容的邏輯關系
在CMM和CMMI中，將配置管理的目的定義為“建立和維護產品的完整性”，這個目標沒有提到對項目管理的支持，也就是說，它定義的配置管理的目標 比當前業界對配置管理的認識有些縮小。但是，仔細分析可以發現“建立和維護產品的完整性”是其他配置管理目標的基礎。下面就從這個目標出發進行分析。邏輯 關系見下圖：
配置完整性（對標準的理解）
1. 產品完整性：就是項目提交的工作成果是“產品集合完整、子產品的正確”的
2. 產品集合完整：產品包含的子產品（配置項）是完整的
3. 子產品的正確：子產品（配置項）達到了需求要求，滿足標準、規程的要求
邏輯關系分析
1. “基線管理”支持“產品集合完整”，明確產品的“子產品”（配置項）集合，并進行管理和控制
2. “配置項管理”，提供了了對子產品（配置項）的控制管理，支持“子產品的正確”
3. “變更管理”，同時支持“產品集合完整、子產品的正確”，用于控制子產品（配置項）和產品（基線）的變更
4. “配置標示”，建立對配置項（子產品）的識別、命名，支持“配置項管理”
5. “版本控制”，控制配置項（子產品）生命歷程，保留配置項（子產品）演進歷史
6. “過程管理”，就是對配置項、基線的建立、變更的狀態標示、過程控制，保證產品（或子產品）按照規定的流程進行了操作；例如“配置項”進入“基線”的過程包括：配置項標示、產品驗證、進入配置、配置審計等
7. “配置計劃”、“配置庫管理”、“配置審計”、“配置報告”等是整個配置管理得支持系統。提供了配置管理“可視性”和監督管理
2 配置和配置項
在配置管理中，“配置”和“配置項”是重要的概念，“配置”是在技術文檔中明確說明并最終組成軟件產品的功能或物理屬性。因此“配置”包括了即將受 控的所有產品特性，其內容及相關文檔，軟件版本，變更文檔，軟件運行的支持數據，以及其他一切保證軟件一致性的組成要素，相對與硬件類配置，軟件產品的 “配置”包括更多的內容并具有易變性。
受控軟件經常被劃分為各類配置項（Configuraion items, CIs），這類劃分是進行軟件配置管理的基礎和前提，CIs是邏輯上組成軟件系統的各組成部分。比如一個軟件產品包括幾個程序模塊，每個程序模塊及其相關 文檔和支撐數據可能被命名為一個CI。一個系統包括的CIs的數目是一個與設計密切相關的問題。一個純軟件的CI通常也稱之為軟件配置項（CSCI）。
現在所有的配置管理工具均提供對配置項的管理工具，包括(Check in和Check out機制的 )版本管理和版本標號功能。由于版本和標號管理比較繁瑣，一般推薦使用配置管理工具，減少事務性工作。
3 基線
在配置管理系統中，基線就是一個CI或一組CIs在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態，而這個過程被稱為“基線化”。 每一個基線都是其下一步開發的出發點和參考點。基線確定了元素（配置項）的一個版本，且只確定一個版本。一般情況下，基線一般在指定的里程碑處創建，并與 項目中的里程碑保持同步。
一般地，第一個基線包含了通過評審的軟件需求，因此稱之為“需求基線”，通過建立這樣一個基線，受控的系統需求成為進一步軟件開發的出發點，對需求的變更被正式初始化、評估。受控的需求還是對軟件進行功能評審的基礎。
每個基線都將接受配置管理的嚴格控制，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟件開發階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線，這就是“基線管理”的過程。
基線具有以下屬性：
通過正式的評審過程建立
基線存在于基線庫中，對基線的變更接受更高權限的控制
基線是進一步開發和修改的基準和出發點
進入基線前，不對變化進行管理或者較少管理
進入基線后，對變化進行有效管理，而且這個基線作為后繼續工作的基礎
不會變化的東西不要納入基線
變化對其他沒有影響的可以不納入基線 |
建立基線的好處：
重現性：及時返回并重新生成軟件系統給定發布版的能力，或者是在項目中的早些時候重新生成開發環境的能力。當認為更新不穩定或不可信時，基線為團隊提供一種取消變更的方法。
可追蹤性：建立項目工件之間的前后繼承關系。目的是確保設計滿足要求、代碼實施設計以及用正確代碼編譯可執行文件。
版本隔離：基線為開發工件提供了一個定點和快照，新項目可以從基線提供的定點之中建立。作為一個單獨分支，新項目將與隨后對原始項目（在主要分支上）所進行的變更進行隔離。 |
4 基線、配置、配置項的關系
基線的組成，以及配置項和配置的關系如下圖：
基線管理的步驟：
1、在開發前確定基線的“配置”
2、基線批準前，根據“配置”檢查配置項是否齊備
3、對各個配置項，確認其版本的正確性
4、對每個配置項建立基線標志，
例如上圖為：測試基線=（配置項A=1，配置項B=1，配置項C=1）
alpha版=（配置項A=2，配置項B=1，配置項C=1）
beta版=（配置項A=3，配置項B=3，配置項C=2）
產品基線=（配置項A=4，配置項B=4，配置項C=4）
5、基線變更管理
6、基線的各類報告和審計信息 |
針對某個具體得項目，可以根據基線的內容，建立一個基線信息的跟蹤表，例如如下：
[注]：被色塊覆蓋的表示，此配置項屬于對應列的基線
[注]：在色塊的欄目填寫對應配置項的版本號
5 變更管理
在有效標示了配置并進行了管理之后，如何保證它們在復雜多變得開發過程中真正的處于受控的狀態，并在任何情況下都能迅速的恢復到任一歷史狀態就要依賴有下的變更管理。
缺乏有效的變更請求管理會導致的問題：
軟件產品質量低下，對一些缺陷的修正被遺漏
項目經理不了解開發人員的工作進展，缺乏對項目現狀進行客觀評估的能力
開發人員不了解手頭工作的優先級別，可能出現將緊急的事情放在一邊、而工作在一般優先級任務上的情況
可能錯誤使用和引用已經變更的產品，引起開發工作混亂 |
變更管理的流程：
（獲得）提出變更請求；
由CCB審核并決定是否批準；
為（被接受）修改請求分配人員，提取SCI，進行修改；
提交修改后的SCI，并測試（或者評審）；
重建軟件的適當版本；
復審（審計）所有SCI的變化；
發布新版本。 |
為了更好的指導變更范圍的影響分析，可以通過兩種表格來幫助發現受到變更影響的內容，一種是《需求跟蹤表》，一種是《配置項依賴關系表》，分別如下：
6 配置庫管理
在實際的開發活動中系統中，為了讓每個開發人員和各個開發團隊能更好的分工合作，同時又互不干擾，必須規劃好工作空間的管理。主要的手段是設置配置庫（即文件夾設置），和設置版本的分支，來實現對配置項權限管理。
設置版本分支
基本上要為每個配置項從建立開始就劃分成3個不同的分支：私有分支、集成分支、公共（主干）分支。讓它們分別對應3類工作空間。
私有分支：
私有分支對應的是開發人員的私有開發空間。開發人員根據任務分工獲得對相應配置項的操作許可之后，他即在自己的私有開發分支上工作，他的所有工作成果體現 為在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素。 |
集成分支：
集成分支對應的是開發團隊的公共空間。凡是要為同組人員共享的配置項都從該分支獲得。即各開發人員必須將私有工作空間中的開發成果歸并（Merge）到該 分支后才能進入下一個開發活動。所有涉及多人協調的開發工作（如集成測試等）都必須工作在這一空間中。該開發團隊擁有對該集成分支的讀寫權限，而其他成員 只有只讀權限。該分支的管理工作由系統集成員及相關指定人員負責。 |
公共（主干）分支：
公共分支對應的是整個軟件開發組織的公共空間。各個開發小組在現階段的任務完成后，將可以發布的版本歸并到該分支上，將來需要查閱相關資料時，以該分支上 的版本為準。該分支對組織內的全體軟件人員開放只讀權限。該分支的管理工作由系統集成員負責。 |
上面定義的3類工作空間（分支）由配置管理員統一管理，根據各開發階段的實際情況定制相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。
配置庫的設置
決定配置庫的結構是配置管理活動的重要基礎。一般常用的是兩種組織形式：按配置項類型分類建庫和按任務建庫。
按配置項的類型分類建庫的方式經常為一些咨詢服務公司所推薦，它適用于通用的應用軟件開發組織。這樣的組織一般產品的繼承性較強，工具比較統一，對 并行開發有一定的需求。使用這樣的庫結構有利于對配置項的統一管理和控制，同時也能提高編譯和發布的效率。但由于這樣的庫結構并不是面向和各個開發團隊的 開發任務的，所以可能會造成開發人員的工作目錄結構過于復雜，帶來一些不必要的麻煩。
而按任務建立相應的配置庫則適用于專業軟件的研發組織。在這樣的組織內，使用的開發工具種類繁多，開發模式以線性發展為主，所以就沒有必要把配置項嚴格的分類存儲，人為增加目錄的復雜性。因此，筆者認為特別是對于研發性的軟件組織來說，還是采用這種設置策略比較靈活。
配置庫的日常工作
配置庫的日常工作是一些事務性的工作，主要保證配置庫的安全性，包括：
對配置庫的定期備份
清除無用的文件和版本
檢測并改進配置庫的性能等
7 配置報告
配置狀態報告就是根據配置項操作的記錄來向管理者報告軟件開發活動的進展情況。這樣的報告應該是定期進行，并盡量通過CASE工具自動生成，用數據庫中的客觀數據來真實的反映各配置項的情況。
配置狀態報告應著重反映當前基線配置項的狀態，以作為對開發進度報告的參照。為了說明項目狀態對變更的情況也應當進行報告。有時，對配置庫的情況也 進行說明，例如備份次數，磁盤占用空間等等。只要是關心的信息，均可作為狀態報告的內容。這些信息進行有效記錄，往往可以作為項目度量的重要數據來源。
8 配置審計
配置審計的主要作用是作為變更控制的補充手段，來確保某一變更需求已被切實實現。在某些情況下，它被作為正式的技術復審的一部分，但當軟件配置管理 是一個正式的活動時，該活動由SQA人員單獨執行。 審計機制保證修改的動作被完整地記錄，也就是說，記錄了誰修改了這個工件，什么時候做的修改，為什么原因做出這個改動，以及修改了哪些地方。 在版本控制過程中，如果利用一些配置管理工具（或者版本控制工具）的支持，則可以自動地記錄審計工作所需的四個“W”（Who、When、Why、 What）。 同時配置審計工作應當可以說明如下信息。
配置審計應當說明的信息：
1. 變更要求被完成，并且對附加的修改已經執行了
2. 采用了正確的正式驗證手段
3. 遵循了標準的要求
4. 變更的4W信息被完整記錄，并和相關配置項關聯 |
9 項目實施指南
一個軟件研發項目一般可以劃分為三個階段：計劃階段、開發階段和維護階段。然而從軟件配置管理的角度來看，后兩個階段所涉及的活動是一致，所以就把它們合二為一，成為“項目開發和維護”階段。
一個項目設立之初項目經理首先需要制定整個項目的計劃，它是項目研發工作的基礎。在有了總體研發計劃之后，軟件配置管理的活動就可以展開了，因為如 果不在項目開始之初制定軟件配置管理計劃，那么軟件配置管理的許多關鍵活動就無法及時有效的進行，而它的直接后果就是造成了項目開發狀況的混亂并注定軟件 配置管理活動成為一種“救火”的行為。所以及時制定一份軟件配置管理計劃在一定程度上是項目成功的重要保證。
在“開發階段和維護階段”，軟件配置管理活動主要分為三個層面，這三個層面是彼此之間既獨立又互相聯系的有機的整體。
（1） 主要由配置人員完成的管理和維護工作；
（2） 由系統集成員和開發人員具體執行軟件配置管理策略；
（3） 變更流程。
| 軟件階段 | 活 動 | 活動說明 |
| 計劃階段 | 制定軟件計劃
| 一個項目設立之初，項目經理首先需要制定整個項目的計劃 |
| 確定配置策略 | 配置管理委員會（CCB）根據項目的開發計劃確定各個里程碑和開發策略 |
| 制定配置計劃 | 配置人員根據CCB的規劃，制定詳細的配置管理計劃，交CCB審核 |
| 批準配置計劃 | CCB通過配置管理計劃后交項目經理批準，發布實施 |
| 開發階段和維護階段 | 確定初始基線 | CCB設定研發活動的初始基線 |
| 配置庫管理 | 配置人員根據軟件配置管理規劃設立配置庫和工作空間，為執行軟件配置管理做好準備；并定期進行備份和清理工作 |
| 授權開發 | 開發人員按照統一的軟件配置管理策略，根據獲得的授權的資源進行項目的研發工作 |
| 集成 | 系統集成員按照項目的進度集成組內開發人員的工作成果，并構建系統，推進版本的演進 |
| 管理基線 | CCB根據項目的進展情況，并適時的建立基線，批準基線變更，保證開發和維護工作有序的進行。 |
| 產品發布 | 系統集成員進行產品集成，由CCB批準，進行發布 |
| 其 他 | 配置會議
| CCB定期舉行例會，根據成員所掌握的情況、配置人員的報告和開發人員的請求，對配置管理計劃作出修改，并向項目經理負責。 |
| 配置報告和審計 | 配置人員定期向項目經理和CCB提交審計報告，并在配置管理例會中報告項目在軟件過程中可能存在的問題和改進方案 |
| 變更管理 | 事件觸發執行，由CCB批準、項目組執行，并執行審計 |
10 配置管理部署模型
基本過程
| 序號 | 階段 | 活動 | 備注 |
1
| 獲得相應管理權 |
|
|
| 1.1 |
| 建立相應負責團隊
|
|
| 1.2 |
| 獲得授權和資源 | 可召開啟動會 |
2
| 評估配置管理現狀 |
|
|
| 2.1 |
| 繪制和評估當前過程的控制圖 | 可采用CMM標準 |
| 2.2 |
| 了解員工對配置管理的態度 |
|
| 2.3 |
| 了解組織的配置管理技術水平 |
|
| 2.4 |
| 了解領導期望 |
|
| 2.5 |
| 編制并評審評估報告 | 獲得“現狀信息” |
3
| 配置工具選擇 |
|
|
| 3.1 |
| 編制、評審《評估評分表》
|
|
| 3.2 |
| 評估配置工具和供貨商 |
|
| 3.3 |
| 收集其他用戶的使用經驗 |
|
4
| 配置過程定義 |
| 制定配置管理過程草案 |
| 4.1 |
| 利用“現狀信息”和收集的經驗
|
|
| 4.2 |
| 制定新的過程 |
|
| 4.3 |
| 評審新過程，并建立新的過程基線 |
|
5
| 試點 |
|
|
| 5.1 |
| 選定試點項目 |
|
| 5.2 |
| 確定試點負責小組 |
|
| 5.3 |
| 定義試點成功標準和進度 |
|
| 5.4 |
| 試點項目人員培訓 |
|
| 5.5 |
| 試點改進 | 同時對草案進行改進 |
| 5.6 |
| 試點總結/推廣 | 完成正式過程的發布 |
6
| 全面實施 |
|
|
| 6.1 |
| 組建相應部門和團隊
|
|
| 6.2 |
| 制定各個項目的實施計劃 |
|
| 6.3 |
| 配置管理知識、過程、工具的培訓 |
|
| 6.4 |
| 幫助各個項目向新過程遷移 |
|
| 6.5 |
| 日常監督、抽查、溝通 |
|
| 7 | 結束 |
| 總結、獎勵 |
相應操作文件
對應過程：2.2了解員工對配置管理的態度建立一個CHECKLIST，來進行調研，如下
| 序號 | 調查內容 | 調查結果 |
| 1 | 原來是否有過類似嘗試，成功或者失敗了 |
|
| 2 | 是否有由于配置管理不好造成的痛苦經歷 |
|
| 3 | 對建立配置管理過程是否支持 |
|
| 4 | 是否覺得配置管理過程會壓抑創造性 |
|
| 5 | 是否覺得配置管理過程太繁瑣 |
|
| 6 | 對配置管理是否有不合理的期望 |
|
| 7 | 是否有些急功近利 |
|
| 8 | 是否對實施配置管理工具感興趣 |
|
| 9 | 個人英雄主義和分工協作那個是主流 |
|
對應過程：2.3了解組織的配置管理技術水平建立一個CHECKLIST，來進行調研，如下
| 序號 | 調查內容 | 調查結果 |
| 1 | 是否已經有了配置管理過程，運作時間
|
|
| 2 | 是否使用了配置管理工具，使用時間 |
|
| 3 | 是否接受了配置管理的專門培訓，培訓時間 |
|
| 4 | 對配置管理過程的認識程度 |
|
| 5 | 對配置管理工具的使用程度 |
|
| 6 | 企業員工的基本素質和學習能力 |
|
對應過程：3.2評估配置工具供應商建立一個CHECKLIST，來進行調研，如下
| 序號 | 調查內容 | 調查結果 |
| 1 | 工具可以解決當前問題，滿足當前需求嗎？
|
|
| 2 | 產品的市場地位 |
|
| 3 | 產品價格 |
|
| 4 | 與現有環境的兼容程度 |
|
| 5 | 運行能力（峰值情況、成熟性、穩定性） |
|
| 6 | 是否支持未來需求 |
|
| 7 | 是否具備：工作空間管理 |
|
| 8 | 是否具備：版本控制 |
|
| 9 | 是否具備：配置報告 |
|
| 10 | 是否具備：過程支持 |
|
| 11 | 是否具備：安全和保護 |
|
| 12 | 是否具備：工具集成 |
|
| 13 | 是否具備：構造支持 |
|
| 14 | 是否具備：圖形界面 |
|
| 15 | 是否具備：自定義支持 |
|
| 16 | 是否具備：發行管理 |
|
| 17 | 是否具備： WEB支持 |
|
對應過程：3.2評估配置工具供應商建立一個CHECKLIST，來進行調研，如下
| 序號 | 調查內容 | 調查結果 |
| 1 | 配置管理服務從業時間
|
|
| 2 | 成功案例數量和質量 |
|
| 3 | 培訓、技術支持隊伍 |
|
| 4 | 提供的培訓和指導，以及其他服務 |
|
| 5 | 近期關于配置服務的商譽、資產、銷售額 |
|
| 6 | 地理位置、服務及時性 |
|
對應過程：4.2制定新的過程1. 配置管理過程至少應當包括的內容：配置標示、配置控制、報告、審計2. 在考慮工具納入配置過程中應當考慮下表內容
| 序號 | 考慮內容 |
| 1 | 從配置過程中分解出那些是事務性、那些是創造性的工作 |
| 2 | 考慮事務性工作的繁重程度和精度要求程度，理出一個“自動化優先級” |
| 3 | 根據過程，確定工具可以運用的地方 |
| 4 | 根據“自動化優先級”選擇那些工具功能進行自動化 |
| 5 | 考慮使用工具功能自動化的前提和結果 |
| 6 | 劃分出“自動化”和“人工”的接口，并清晰描述 |
| 7 | 調整過程要素，適應工具，從而形成一個納入了工具的配置管理過程 |
| 8 | 考慮這個過程的適用性和效益 |
對應過程：6.1組建相應部門和團隊負責配置管理部署和實施的團隊必須包括
| 序號 | 團隊成員 | 職責和要求 |
| 1 | 組長
| 負責管理小組，并負責配置管理的部署和實施 |
| 2 | 技術人員 | 負責考慮將要和配置工具集成的各類工具之間的接口 |
| 3 | 配置專家 | 配置工具精通、配置管理理論知識熟悉 |
| 4 | 過程專家 | 負責過程建模和主要的過程分析工作 |
| 5 | 配置管理人員 | 負責評審新過程，并提供原來配置管理的經驗 |
| 6 | 項目經理 | 負責評審新過程，并提供配置管理適應于項目的參考 |
對應過程：6.2制定各個項目的實施計劃計劃應當包括的內容：
| 序號 | 計劃內容 |
| 1 | 目標和完成標準 |
| 2 | 投資和收益分析 |
| 3 | 階段劃分和進度安排 |
| 4 | 資源投入安排 |
| 5 | 人員分工和組織 |
| 6 | 風險管理 |