配置管理基本概念、配置管理計劃、配置管理主要活動
一、概述
配置管理（Configuration Management， CM）的目的，在使用配置識別、配置控制、配置狀態記錄及配置審計，來達到建立與維護工作產品的完整性。
配置管理提供了結構化的，有序化的，產品化的管理軟體工程的方法。它涵蓋了軟體生命週期的所有領域並影響所有資料和過程。配置管理是指用於控制系統一系列變化的學科。通過一系列技術，方法和手段來維護產品的歷史，標識和定位產品獨有的版本，並在產品的開發和釋出階段控制變化。通過有序管理和減少重複性工作，配置管理保證了生產的質量和效率。可以說不懂軟體專案的配置管理，就不懂軟體開發管理，不對軟體專案進行配置管理，就沒有進行軟體專案開發管理。
二、配置管理的基本概念
1、配置標識
IEEE中的定義：識別產品的結構、產品的構件及其型別，為其分配唯一的識別符號，並以某種形式提供對它們的存取。
可以理解為：標識軟體系統的結構，標識獨立部件（工作產品），並使它們是可訪問的。配置標識的目的，是在整個生命週期中標識系統各部件並提供對軟體過程及其軟體產品的跟蹤能力。即：怎麼命名？版本如何設定？放到哪裡？哪些是受控的？受控的級別是什麼？讀寫的許可權是什麼？
2、配置變更控制
IEEE中的定義：通過建立產品基線，控制軟體產品的釋出和在整個軟體生命週期中對軟體產品的修改。
可以理解為：軟體生命週期中控制軟體產品的釋出和變更，目的是建立確保軟體產品質量的機制。即怎麼變更？誰控制變更？誰來分析變更的影響範圍？變更後如何驗證、入庫以及恢復？
3、配置狀態統計
可以理解為：記錄和報告變更過程，目標是不間斷記錄所有基線項的狀態和歷史，並進行維護。每次基線的生成和變更都能讓相關者知道變了什麼？為什麼變？變化前後的狀態是什麼？
4、配置審計
IEEE中的定義：確認產品的完整性並維護構件間的一致性，即確保產品是一個嚴格定義的構件集合。
可以理解為：驗證軟體產品的構造是否符合需求、標準、或合同的要求，目的是根據配置管理的過程和程式，驗證所有的軟體產品已經產生並有正確標識和描述，所有階段的工作產品都一致並滿足系統的需求，並且所有的變更需求都已解決。
三、配置管理計劃
1、配置管理活動的職責分配
a）配置管理員：識別和標識配置項，建立和維護配置庫；配置庫管理；執行配置審計
b）配置控制委員會（CCB）：批准基線庫的生成；評估和稽核變更請求，並確保批准的更改得到實施.
c）QA：配置管理活動審查
2、配置管理的資源
a）配置庫的伺服器
b）配置庫工具
c）配置庫的訪問方式3、識別配置項
對於配置項，可以給出一個比較簡單的定義，即軟體過程的輸出資訊可以分為4個主要類別：
a）計算機程式（原始碼及可執行程式）
b）描述計算機程式的文件（針對技術開發者和使用者）
c）資料（包含在程式內部或外部）
d）專案管理的有關檔案、資訊記錄等
在實際專案中，我們如何識別配置項？
a）《專案過程裁剪定義》中要產出的工作產品
b）原始碼、可執行程式
c）資料（包含在程式內部或外部）
d）客戶提供的文件、工具
e）需要提交給客戶的其他工作產品。
4、配置項的控制級別
IEEE中基線的定義是這樣的：已經正式通過稽核批准的某規約或產品，它因此可作為進一步開發的基礎，並且只能通過正式的變化控制過程改變。
在專案中我們一般把配置項分為3種控制級別：
a）資料項：資料項是指對變更不作控制的配置項；
b）受控項：受控項是指不需要進行基線控制但變更後需要得到相關人員確認或通知到相關人員的配置項。
c）基線項：基線項是指需要嚴格執行基線變更流程的配置項。
一般資料項就是我們大部分企業說的工作區。
5、配置項的標識與控制
在配置庫中，配置項都應該有一個合適的目錄去存放和分類。放入之特定目錄下的配置項也必須嚴格按照“檔案命名規則”來命名，並且這些配置項要按照“版本設定規則”來標識版本。
在配置庫中各種配置項的操作許可權都應嚴格管理。我們一般是通過目錄的訪問許可權來控制的，所以配置庫的目錄結構與配置項的訪問許可權也有著密切的關係，配置項的許可權設定的原則如下：
a）基線配置項：只有配置管理員有寫的許可權，專案組全員開放讀的許可權。
b）受控配置項：PM、CCB讀寫許可權，專案組全員或相關人員開放讀的許可權。
c）資料配置項：PM、CCB、配置項的責任人或開發小組開放讀寫許可權，專案組全員開放讀的許可權。
6、基線計劃
在配置管理中基線釋出是一個重要活動，基線釋出的時間點一般就是專案里程碑時間點。通常會有下列基線：需求基線、設計基線、程式碼基線、交付基線等。
在計劃中我們要依據《專案綜合管理計劃》的里程碑時間點，結合專案管理的需要，設定專案的基線計劃。即專案過程中釋出哪些基線，這些基線釋出的時間點，釋出的責任人。
同時我們也要明確定義基線的版本規則，因為基線也是在不斷變更的。
7、配置審計計劃
配置審計的時機：
a）一般基線釋出前對要進入基線的配置項進行配置審計。
b）如果2條基線的釋出時長超過2個月時，應該在時間2個基線釋出中適當安排配置審計，建議是1個月1次。
c）產品交付前必須要進行配置審計。
我們在計劃中要規劃好配置審計的概要時間。這樣有利於配置審計的及時開展。
8、配置管理計劃
定義各類配置項如庫、出庫的準則和操作流程。
定義基線變更的準則和操作流程。
明確配置庫的備份及維護的方法，當出現異常後如何恢復的預案等。
版本釋出的準則、釋出流程及釋出計劃，如測試版本、β版本、Release版本等。
四、配置管理的主要活動
1、配置狀態報告
配置狀態報告是一個配置管理中一個很重要的活動，多個開發組保持開發一致的重要活動。我們的配置狀態報告的主要物件是基線庫。
配置狀態報告要報告的內容有：基線庫的基線項的清單、基線項的名稱、版本、存放位置。
在每次基線變更後，狀態報告還要能說明。哪些基線項變了、為什麼變、變化前的版本是什麼、變化後的版本是什麼。
2、基線變更流程
一般專案管理中，基線變更的控制權限是CCB（配置變更委員會）。基線變更控制一般是由兩種變更方式，需求變更、內部變更。下圖是基線變更的流程。 
3、配置審計
在CMMI模型中明確將配置審計分為物理審計和功能審計，在定義中與IEEE是沒有衝突的。在CMMI模型中對物理審計和功能審計的定義如下：
a）物理審計：驗證已構建出的配置項符合定義和描述它的技術文件的審計行為。
b）功能審計：驗證配置項的開發已經被完全滿足的審計行為，即驗證配置項已經達到了在功能或已分配的配置標識中刻畫的效能和功能特性，並且其執行和支援文件是完整的和滿意的。
配置審計的範圍：物理審計的範圍是受控項和基線項，功能審計的範圍是基線項。
功能審計是驗收的前提條件，不同的角色所做的功能審計側重點不同。
配置審計的步驟：
a）準備《配置審計檢查單》，這個檢查單包含所有受控項和基線項的狀態，受控項清單包含受控項的命名、控制級別、存放位置、當前版本、控制權限等狀態資訊。基線項的狀態就是最新的《配置狀態報告》中配置項的狀態。
b）依據配置審計的計劃時間去執行配置審計。
c）根據《配置審計檢查單》對配置庫進行物理審計。責任人：CM發起並參與、CCB。
d）根據《配置審計檢查單》對配置庫進行功能審計。責任人：CM發起並參與、需求人員、CCB（PM、及各Leader）及相關人員。
e）QA監督配置審計是否按照標準流程來進行，並記錄不一致問題。
f）每次配置審計要將審計結果記錄到《配置審計報告》中，記錄和跟蹤配置審計檢查出的問題。
物理審計的方法：
根據《配置審計檢查單》去檢查，該有的配置項是否都有了？檔案命名與計劃中的命名規則是否一致？存放位置與計劃是否一致？版本設定與計劃中的版本設定規則是否一致？控制權限是正確？
功能審計的方法：
a）檢查與需求的一致性、完整性：根據《需求追蹤矩陣》對配置庫的基線項進行檢查，看看所有需求是否都已經不多不少地被實現了？並納入了基線庫？如果物理審計中基線項的審計沒有問題，我們也可以通過《需求追蹤矩陣》對《配置狀態報告》中基線項進行檢查，看看所有需求是否都已經不多不少地被實現了？
b）驗證工作產品與需求的符合程度：檢視所有基線項評審和測試報告，看看所有的基線項是否都已經通過各級評審及測試？
c）交付給客戶的文件與軟體的功能一致性：檢查交付客戶的文件是否與當前最新的基線中的需求一致？
4、配置管理活動的QA審查
配置管理過程的審查：
確保配置管理的記錄和配置項是完整的、一致的和準確的審查行為，客觀評價管理過程與其過程描述、標準和規程的符合性並處理不一致問題。
配置管理活動的QA檢查時機：
定期檢查配置管理工作，依據基線和配置審計計劃檢查這些基線的建立變更及配置審計活動。
檢查內容：
a）檢查配置管理的各種記錄、報告等與配置庫中的物理的配置項實體是否一致、完整、準確
b）是否每次新建和變更基線都有完整的申請記錄
c）每次基線新建和變更的稽核流程是否執行並有記錄
d）基線庫中的產品是否經過了功能審計
e）每次配置審計的問題是否都被跟蹤直到關閉
f）配置庫的許可權是否都是正確分配的
g）配置庫的目錄結構是否都與《配置管理計劃》一致