前言
配置管理（Configuration Management, CM）的目的是通過執行版本控制、變更控制等規程，以及使用配置管理軟體，來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。
配置管理過程域是SPP模型的重要組成部分。本規範闡述了配置管理過程域的四個主要規程：
◆ 制定配置管理計劃 [SPP-PROC-CM-PLANNING]
◆ 配置庫管理 [SPP-PROC-CM-LIB]
◆ 配置項版本控制 [SPP-PROC-CM-VERSION]
◆ 配置項變更控制 [SPP-PROC-CM-CHANGE]
上述每個規程的“目标”、“角色與職責”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。
本規範适用于國内IT企業的軟體研發項目。建議使用者根據自身情況（如商業目标、研發實力等）适當地修改本規範，然後推廣使用。
17.1 介紹
項目研發和管理過程中會産生許許多多的工作成果，例如文檔、程式和資料等，它們都應當被儲存起來，以便查閱和修改。如果把所有檔案一股腦地塞進計算機裡，那麼使用起來肯定很麻煩。毫無疑問，人們應當将檔案分門别類、有條理地儲存起來。
凡是納入配置管理範疇的工作成果統稱為配置項（Configuration Item, CI），配置項主要有兩大類：
（1）屬于産品組成部分的工作成果，例如需求文檔、設計文檔、源代碼、測試用例。
（2）項目管理和機構支撐過程域産生的文檔。這些文檔雖然不是産品的組成部分，但是值得儲存。
每個配置項的主要屬性有：名稱、辨別符、檔案狀态、版本、作者、日期等。所有配置項都被儲存在配置庫裡，確定不會混淆、丢失。配置項及其曆史記錄反映了軟體的演化過程。
基線（Baseline）由一組配置項組成，這些配置項構成了一個相對穩定的邏輯實體。基線中的配置項被“當機”了，不能再被任何人随意修改（見變更控制規程）。基線通常對應于開發過程中的裡程碑（Milestone），一個産品可以有多個基線，也可以隻有一個基線。基線的主要屬性有：名稱、辨別符、版本、日期等。通常将傳遞給客戶的基線稱為一個“Release”，為内部開發用的基線則稱為一個“Build”。
所有的項目成員都要使用配置管理軟體來保護自己的工作成果。機構應當采用統一的配置管理軟體，常見的配置管理軟體有Microsoft的Visual SourceSafe和Rational的ClearCase等。為了提高配置管理的效率和安全性，機構應當有專門的配置管理者（角色）。配置管理者為每個項目制定《配置管理計劃》，建立和維護配置庫。
鑒于配置管理的重要性和複雜性，機構還應當設立配置控制委員會（Configuration Control Board, CCB）。CCB是個虛拟小組，對配置管理各項活動擁有決策權（例如審批計劃，審批變更請求等）。對于配置管理而言，CCB是決策者，而配置管理者是執行者。
如果機構的各個項目緊密相關（例如一個産品線下的多個項目），建議機構設立公共的CCB，這個公共的CCB對所有項目的配置管理擁有決策權。如果機構的各個項目相對獨立，那麼每個項目可以設立各自的CCB。CCB的決策采用“少數服從多數”原則。
配置管理的流程如圖17-1所示。
圖17-1 配置管理流程圖
一、制定配置管理計劃
配置管理者制定《配置管理計劃》，主要内容包括配置管理軟硬體資源、配置項計劃、基線計劃、傳遞計劃、備份計劃等。CCB審批該計劃。
二、配置庫管理
配置管理者為項目建立配置庫，并給每個項目成員配置設定權限。各項目成員根據自己的權限操作配置庫。配置管理者定期維護配置庫，例如清楚垃圾檔案、備份配置庫等。
三、版本控制
在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最終确定下來。對配置項的任何修改都将産生新的版本。由于我們不能保證新版本一定比老版本“好”，是以不能抛棄老版本。版本控制的目的是按照一定的規則儲存配置項的所有版本，避免發生版本丢失或混淆等現象，并且可以快速準确地查找到配置項的任何版本。
配置項的狀态有三種：“草稿”、“正式釋出”和“正在修改”，本規程制定了配置項狀态變遷與版本号的規則。
四、變更控制
在項目開發過程中，配置項發生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被随意修改而導緻混亂。
修改處于“草稿”狀态的配置項不算是“變更”，無需CCB的準許，修改者按照版本控制規則執行即可。
當配置項的狀态成為“正式釋出”，或者被“當機”後，此時任何人都不能随意修改，必須依據“申請－審批－執行變更－再評審－結束”的規則執行。
五、配置審計
為了保證所有人員（包括項目成員、配置管理者和CCB）都遵守配置管理規範，品質保證人員要定期審計配置管理工作。配置審計是一種“過程品質檢查”活動，是品質保證人員的工作職責之一。請參考品質保證規範SPP-PROC-QA，此處不再論述。
配置管理過程域産生的主要文檔有：
◆《配置管理計劃》
◆《配置庫管理報告》
◆《配置項變更控制報告》
17.2 制定配置管理計劃
17.2.1 目的
制定配置管理計劃，以便有計劃地開展配置管理工作。
17.2.2 角色與職責
配置管理者制定《配置管理計劃》。
CCB審批《配置管理計劃》。CCB的人數視項目的規模而定。通常CCB由項目經理、資深項目成員等人組成，項目經理為CCB負責人。CCB的決策采用“少數服從多數”原則。
17.2.3 啟動準則
《項目計劃》已經制定
配置管理者和CCB已經确定。
17.2.4 輸入
《項目計劃》
17.2.5 主要步驟
[Step1] 确定配置管理的軟硬體資源
配置管理者根據項目的規模以及财力，确定配置管理軟體以及計算機資源（考慮記憶體、外存、CPU等）。常用的配置管理軟體有Microsoft公司的Visual SourceSafe和Rational公司的ClearCase等。
[Step2] 制定配置項計劃
配置管理者識别項目的主要配置項。每個配置項都有唯一的辨別符，辨別符的參考格式為Project-Type…Type-Number。
◆ 可以在Project（或Product）前面加上公司的辨別符。
◆ Type…Type表示配置項類型，可以采用多級縮寫。
◆ Number為3為數字，範圍從001到999，表示一個配置項有若幹個檔案。若配置項隻有一個檔案，則該項可以省略。
配置項計劃的參考格式如下：
| 類型 | 主要配置項 | 辨別符 | 預計正式釋出時間 |
[Step3] 制定基線計劃
配置管理者确定每個基線的名稱（辨別符）及其主要配置項，估計每個基線建立的時間。基線計劃的參考格式如下：
| 基線名稱/辨別符 | 基線所包含的主要配置項 | 預計建立時間 |
[Step4] 制定配置庫備份計劃
配置管理者制定配置庫備份計劃，指明“何人”在“何時”（頻度）将配置庫備份到“何處”。
[Step5] 審批《配置管理計劃》
CCB審批《配置管理計劃》。若該計劃被準許，則請CCB負責人簽字認可。否則，配置管理者按照CCB的意見修改《配置管理計劃》，直到該計劃被準許為止。
17.2.6 輸出
《配置管理計劃》
17.2.7 結束準則
《配置管理計劃》已經制定并被CCB的準許。
17.2.8 度量
配置管理統計工作量以及文檔的規模，彙報給項目經理。
17.3 配置庫管理
17.3.1 目的
所有人員依照配置管理規範和《配置管理計劃》操作配置庫。
17.3.2 角色與職責
配置管理建立并維護配置庫。
項目成員在權限之内操作配置庫。
17.3.3 啟動準則
《配置管理計劃》已經制定。
配置管理的軟體硬體已經存在。
17.3.4 輸入
《配置管理計劃》
17.3.5 主要步驟
[Step1] 建立配置庫
配置管理者建立配置庫，并且至少建立配置庫的所有第一級目錄。
[Step2] 配置設定權限
配置管理者為每個項目成員配置設定操作權限。一般地，項目成員擁有Add, Checkin/Checkout, Download等權限，但是不能擁有“删除”權限。配置管理者的權限最高。具體操作視所采用的配置管理軟體而定。
[Step3] 配置庫操作與管理
項目成員根據自己的權限操作配置庫，例如Add, Checkin/Checkout, Download等。
配置管理者根據“基線計劃”建立與維護基線，“當機”配置項，控制變更。
配置管理者定期清除配置庫裡的垃圾檔案。
配置管理者定期備份配置庫。
傳遞管理。這裡“傳遞”是指從配置庫中提取配置項，傳遞給客戶或項目外的人員。傳遞出去的配置項必須有據可查，避免發生混亂。流程如下：
（1） “索取人”向CCB提出傳遞申請。
（2） CCB審批該申請。如果該申請不合法（合理），則拒絕傳遞配置項。如果同意傳遞，CCB應給出詳細的傳遞清單。
（3） 配置管理者依據CCB的批示，從配置庫中提取配置項傳遞給“索取人”。
（4） “索取人”驗收後簽字。
17.3.6 輸出
《配置庫管理報告》（由配置管理者撰寫）
17.3.7 結束準則
對配置庫的操作與管理将持續到項目結束。
17.3.8 度量
配置管理者統計工作量以及文檔規模。
17.3 版本控制
17.3.1 目的
按照一定的規則儲存配置項的所有版本，避免發生版本丢失或混淆等現象，并且可以快速準确地查找到配置項的任何版本。
17.3.2 角色與職責
所有項目成員都必須遵照版本控制規程操作配置庫。
17.3.3 配置項狀态變遷規則
配置項的狀态有三種：“草稿”（Draft）、“正式釋出”（Released）和“正在修改”（Changing）。
配置項狀态變遷如圖17-2所示。配置項剛建立時其狀态為“草稿”。配置項通過評審（或審批）後，其狀态變為“正式釋出”。此後若更改配置項，必須依照“變更控制規程”執行，其狀态變為“正在修改”。當配置項修改完畢并重新通過評審（或審批）時，其狀态又變為“正式釋出”，如此循環。
圖17-2 配置項狀态變遷圖
17.3.4 配置項版本号規則
配置項的版本号與配置項的狀态緊密相關：
（1）處于“草稿”狀态的配置項的版本号格式為：0.YZ
◆ YZ數字範圍為01-99。
◆ 随着草稿的不斷完善，“YZ”的取值應遞增。“YZ”的初值和增幅由使用者自己把握。
（2）處于“正式釋出”狀态的配置項的版本号格式為：X.Y
◆ X為主版本号，取值範圍為1-9。Y為次版本号，取值範圍為1-9。
◆ 配置項第一次“正式釋出”時，版本号為1.0。
◆ 如果配置項的版本更新幅度比較小，一般隻增大Y值，X值保持不變。隻有當配置項版本更新幅度比較大時，才允許增大X值。
（3）處于“正在修改”狀态的配置項的版本号格式為：X.YZ
◆ 配置項正在修改時，一般隻增大Z值，X.Y值保持不變。
◆ 當配置項修改完畢，狀态重新成為“正式釋出”時，将Z值設定為0，增加X.Y值。參見規則（2）。
17.3.4 配置項版本控制流程
[Step1] 建立配置項
項目成員依據《配置管理計劃》，在配置庫中建立屬于其任務範圍内的配置項。此時配置項的狀态為“草稿”，其版本号格式為0.YZ。
[Step2] 修改處于“草稿”狀态的配置項
項目成員使用配置管理軟體的Checkout/Checkin功能，可以自由修改處于“草稿”狀态的配置項（不受變更控制規程限制），版本号格式為0.YZ。
[Step3] 技術評審或上司審批
如果配置項是技術文檔，則需要接受技術評審（參見技術評審規程[SPP-PROC-TR]）。如果配置項是“計劃”這類檔案，則需要項目經理（或上級上司）的審批。
若配置項通過了技術評審或上司審批，則轉向 [Step4]，否則轉向 [Step2]。
[Step4] 正式釋出
配置項通過技術評審或上司審批之後，則配置項的狀态從“草稿”變遷為“正式釋出”，版本号格式為X.Y。
[Step5] 變更
修改處于“正式釋出”狀态的配置項，必須按照“變更控制規程”執行，主要步驟如下（詳見變更控制規程）：
◆ 如果CCB同意變更，則配置項狀态從“正式釋出”變遷為“正在修改”。
◆ 項目成員使用Checkout/Checkin功能，可以修改處于“正在修改”狀态的配置項，版本号格式為X.YZ。
◆ 修改完畢後，該配置項要重新接受技術評審或上司審批，轉向[Step3]。
17.4 配置項變更控制
17.4.1 目的
防止配置項被随意修改而導緻混亂。
17.4.2 角色與職責
CCB對審批變更申請。
17.4.3 啟動準則
待變更的配置項狀态為“正式釋出”，或者該配置項已經成為某個基線的一部分（即被“當機”）。
17.4.4 輸入
待變更的配置項
17.4.5 主要步驟
[Step1] 變更申請
變更申請人向CCB送出變更申請，重點說明“變更内容”和“變更原因”。
[Step2] 審批變更申請
CCB審批該申請，分析此變更對項目造成的影響。如果同意變更，則轉向 [Step3]，否則終止本規程。
補充說明：一個配置項的變更可能導緻其它配置項也發生變更，CCB在審批變更申請時一定要考慮這些問題。
[Step3] 安排變更任務
CCB指定變更執行人，安排他們的任務。CCB需要和變更執行人就變更内容達成共識。
補充說明：變更執行人可能是變更申請人，也可能不是。
[Step4] 執行變更任務
變更執行人根據CCB安排的任務，修改配置項。
CCB監督變更任務的執行，如檢查變更内容是否正确、是否按時完成工作等。
[Step5] 對更改後的配置項重新進行技術評審（或審批）
如果配置項是技術文檔，則需要接受技術評審（參見技術評審規程[SPP-PROC-TR]）。如果配置項是“計劃”這類檔案，則需要項目經理（或上級上司）的審批。
若配置項通過了技術評審或上司審批，則轉向 [Step6]，否則轉向 [Step4]（即重新修改）。
[Step6] 結束變更
當所有變更後的配置項都通過了技術評審或上司審批，這些配置項的狀态從“正在修改”變遷為“正式釋出”。CCB在《配置項變更控制報告》中簽字，結束變更。
17.4.6 輸出
本規程的所有資訊都記錄在《配置項變更控制報告》中。
17.4.7 結束準則
CCB簽字結束變更。
17.4.8 度量
CCB統計變更工作量。
17.5 實施建議
要求所有人員對其工作成果進行配置管理。
對全員進行配置管理教育訓練。
由于配置庫裡儲存的是項目的所有工作成果，應當選擇“責任心強、可靠”的人員擔任配置管理者。
選用合适的軟體工具，盡量減少配置管理過程的工作量。
附錄一：《配置管理計劃》
目錄
1. 人員及職責
提示：
（1）根據《項目計劃》中的角色配置設定，确定配置管理者，CCB（配置控制委員會）成員。
（2）CCB的人數根據項目規模而定。一般地，項目經理是CCB的負責人。
| 角色 | 人員 | 職責、工作範圍 |
| 配置管理者 | （1）制定《配置管理計劃》 （2）建立和維護配置庫 | |
| CCB負責人 | （1）審批《配置管理計劃》 （2）審批重大的變更 | |
| CCB成員 | 例如：審批某些配置項或基線的變更 |
2. 用于配置管理的軟硬體資源
提示：
（1）配置管理者确定本項目的配置管理軟體。例如采用Microsoft公司的Visual SourceSafe或者Rationa公司的l ClearCase。
（2）配置管理者根據所采用的配置管理軟體，确定計算機資源（考慮記憶體、外存、CPU等）。
| 配置管理軟硬體資源 | 說明 |
| 計算機名稱 | 記憶體、外存、CPU等 |
3. 配置項計劃
提示：配置管理者辨別配置項，估計每個配置項的正式釋出時間。辨別符的參考格式為Project-Type…Type-Number。例如：
| 類型 | 主要配置項 | 辨別符 | 預計正式發表時間 |
| 計劃 | 《項目計劃》 | ||
| 《品質保證計劃》 | |||
| 《配置管理計劃》 | |||
| 需求 | 《使用者需求說明書》 | ||
| 《軟體需求規格說明書》 | |||
| 《需求跟蹤報告》 | |||
| 設計 | 《體系結構設計報告》 | ||
| 《資料庫設計報告》 | |||
| 《子產品設計報告》 | |||
| 《使用者界面設計報告》 | |||
| 程式設計 | 源程式 | ||
| 二進制庫 | |||
| 測試 | 《測試計劃》 | ||
| 《測試用例》 | |||
| 《測試報告》 | |||
| …… |
4. 基線計劃
| 基線名稱/辨別符 | 基線所包含的主要配置項 | 預計建立時間 |
5. 配置庫備份計劃
提示：配置管理者制定配置庫備份計劃，指明“何人”在“何時”（頻度）将配置庫備份到“何處”。
| 備份頻度、時間 | 備份人 | 備份内容、目的地、方式等 |
附錄：本計劃審批意見
| CCB 審批意見： CCB 負責人簽字 日期 |
附錄二：《配置庫管理報告》
目錄
1. 基本資訊
| 配置管理者 | |
| CCB | 負責人和成員 |
| 配置管理計算機 | |
| 配置管理軟體 | |
| 配置庫名稱 | |
| …… |
2. 項目成員的操作權限
提示：配置管理者為每個項目成員配置設定操作權限。一般地，項目成員擁有Add, Checkin/Checkout, Download等權限，但是不能擁有“删除”權限。配置管理者的權限最高。具體操作視所采用的配置管理軟體而定。
| 項目成員 | 權限，說明 |
3. 配置項記錄
提示：配置管理者記錄主要配置項的版本資訊。
| 主要配置項 | 正式釋出日期 | 作者 | 版本變化曆史 |
4. 基線記錄
| 基線名稱、版本 | 建立日期 | 包含的配置項 | 備注 |
5. 配置庫備份記錄
提示：配置管理者周期性地備份配置庫。
| 批次 | 備份日期 | 備份内容、說明 | 備份到何處 | 責任人 |
6. 配置項傳遞記錄
提示：配置管理者依據CCB的批示，從配置庫中提取配置項傳遞給接受人。
| 批次 | 傳遞日期 | 傳遞内容、說明 | CCB批示 | 接受人 |
7. 配置庫重要記錄檔
提示：配置管理者記錄自己和他人對配置庫的重要操作，例如删除檔案等。
| 日期 | 人員 | 事件 |
附錄三：《配置項變更控制報告》
| 1. 變更申請 | |||
| 申請變更的 配置項 | 輸入名稱，版本，日期等資訊 | ||
| 變更的内容 及其理由 | |||
| 估計配置項變更将對 項目造成的影響 | |||
| 變更申請人簽字 | |||
| 2. 審批變更申請 | |||
| CCB審批意見 | 審批意見 CCB負責人簽字 日期 | ||
| 準許變更的配置項 | 變更執行人 | 時間限制 | |
| 3. 變更配置項 | |||
| 變更後的配置項 | 重新評審結論 | 完成日期 | 責任人 |
| 4. 結束變更 | |||
| CCB簽字 | CCB負責人簽字 日期： |