【正文】 基線， “凍結(jié)”配置項，控制變更。? 配置管理員定期清除配置庫里的垃圾文件。? 配置管理員定期備份配置庫。? 交付管理。這里“交付”是指從配置庫中提取配置項，交付給客戶或項目外的人員。交付出去的配置項必須有據(jù)可查，避免發(fā)生混亂。流程如下：（1） “索取人”向 CCB 提出交付申請。（2） CCB 審批該申請。如果該申請不合法（合理） ，則拒絕交付配置項。如果同意交付，CCB 應給出詳細的交付清單。（3） 配置管理員依據(jù) CCB 的批示，從配置庫中提取配置項交付給“索取人” 。（4） “索取人”驗收后簽字。 輸出? 《配置庫管理報告》 （由配置管理員撰寫） 結(jié)束準則? 對配置庫的操作與管理將持續(xù)到項目結(jié)束。 度量? 配置管理員統(tǒng)計工作量以及文檔規(guī)模。 版本控制 目的? 按照一定的規(guī)則保存配置項的所有版本，避免發(fā)生版本丟失或混淆等現(xiàn)象，并且可以快8 / 12速準確地查找到配置項的任何版本。 角色與職責? 所有項目成員都必須遵照版本控制規(guī)程操作配置庫。 配置項狀態(tài)變遷規(guī)則配置項的狀態(tài)有三種：“草稿” （Draft ） 、 “正式發(fā)布” （Released）和“正在修改”（Changing） 。配置項狀態(tài)變遷如圖 172 所示。配置項剛建立時其狀態(tài)為“草稿” 。配置項通過評審（或?qū)徟┖?，其狀態(tài)變?yōu)椤罢桨l(fā)布” 。此后若更改配置項，必須依照“變更控制規(guī)程”執(zhí)行，其狀態(tài)變?yōu)椤罢谛薷摹?。當配置項修改完畢并重新通過評審（或?qū)徟r，其狀態(tài)又變?yōu)椤罢桨l(fā)布” ，如此循環(huán)。圖 172 配置項狀態(tài)變遷圖 配置項版本號規(guī)則配置項的版本號與配置項的狀態(tài)緊密相關：（1）處于“草稿”狀態(tài)的配置項的版本號格式為：? YZ 數(shù)字范圍為 0199。? 隨著草稿的不斷完善， “YZ”的取值應遞增。 “YZ”的初值和增幅由用戶自己把握。（2）處于“正式發(fā)布”狀態(tài)的配置項的版本號格式為：? X 為主版本號，取值范圍為 19。Y 為次版本號，取值范圍為 19。? 配置項第一次“正式發(fā)布”時，版本號為 。? 如果配置項的版本升級幅度比較小，一般只增大 Y 值，X 值保持不變。只有當配置項版本升級幅度比較大時，才允許增大 X 值。（3）處于“正在修改”狀態(tài)的配置項的版本號格式為：? 配置項正在修改時，一般只增大 Z 值， 值保持不變。? 當配置項修改完畢，狀態(tài)重新成為“正式發(fā)布”時，將 Z 值設置為 0，增加 值。參見規(guī)則（2） 。變更控制正式發(fā)布 正在修改自由修改草稿 評審或?qū)徟駴Q通過9 / 12 配置項版本控制流程[Step1] 創(chuàng)建配置項? 項目成員依據(jù)《配置管理計劃》 ，在配置庫中創(chuàng)建屬于其任務范圍內(nèi)的配置項。此時配置項的狀態(tài)為“草稿” ，其版本號格式為 。[Step2] 修改處于 “草稿”狀態(tài)的配置項? 項目成員使用配置管理軟件的 Checkout/Checkin 功能，可以自由修改處于“草稿”狀態(tài)的配置項（不受變更控制規(guī)程約束） ，版本號格式為 。[Step3] 技術評審 或領導審批? 如果配置項是技術文檔，則需要接受技術評審（參見技術評審規(guī)程[SPPPROCTR]） 。如果配置項是“計劃”這類文件，則需要項目經(jīng)理（或上級領導）的審批。? 若配置項通過了技術評審或領導審批，則轉(zhuǎn)向 [Step4]，否則轉(zhuǎn)向 [Step2]。[Step4] 正式發(fā)布? 配置項通過技術評審或領導審批之后，則配置項的狀態(tài)從“草稿”變遷為“正式發(fā)布” ，版本號格式為 。[Step5] 變更? 修改處于“正式發(fā)布”狀態(tài)的配置項，必須按照“變更控制規(guī)程”執(zhí)行，主要步驟如下（詳見變更控制規(guī)程）：? 如果 CCB 同意變更，則配置項狀態(tài)從 “正式發(fā)布”變遷為“正在修改” 。? 項目成員使用 Checkout/Checkin 功能，可以修改處于“正在修改”狀態(tài)的配置項，版本號格式為 。? 修改完畢后，該配置項要重新接受技術評審或領導審批，轉(zhuǎn)向[Step3]。 配置項變更控制 目的? 防止配置項被隨意修改而導致混亂。10 / 12 角色與職責? CCB 對審批變更申請。 啟動準則? 待變更的配置項狀態(tài)為“正式發(fā)布” ，或者該配置項已經(jīng)成為某個基線的一部分（即被“凍結(jié)” ） 。 輸入? 待變更的配置項 主要步驟[Step1] 變更申請? 變更申請人向 CCB 提交變更申請，重點說明 “變更內(nèi)容”和“變更原因” 。[Step2] 審批變更申請? CCB 審批該申請，分析此變更對項目造成的影響。如果同意變更，則轉(zhuǎn)向 [Step3]，否則終止本規(guī)程。補充說明：一個配置項的變更可能導致 其它 配置項也發(fā)生變更， CCB 在審批變更申請時一定要考慮這些問題。[Step3] 安排變更任務? CCB 指定變更執(zhí)行人，安排他們的任務。CCB 需要和變更執(zhí)行人就變更內(nèi)容達成共識。補充說明：變更執(zhí)行人可能是變更申請人，也可能不是。[Step4] 執(zhí)行變更任務? 變更執(zhí)行人根據(jù) CCB 安排的任務，修改配置項。? CCB 監(jiān)督變更任務的執(zhí)行，如檢查變更內(nèi)容是否正確、是否按時完成工作等。[Step5] 對更改后的配置項 重新進行技術評審（或?qū)徟? 如果配置項是技術文檔，則需要接受技術評審（參見技術評審規(guī)程[SPPPROCTR]） 。如11 / 12果配置項是“計劃”這類文件，則需要項目經(jīng)理（或上級領導）的審批。? 若配置項通過了技術評審或領導審批，則轉(zhuǎn)向 [Step6]，否則轉(zhuǎn)向 [Step4]（即重新修改）。[Step6] 結(jié)束變更? 當所有變更后的配置項都通過了技術評審或領導審批，這些配置項的狀態(tài)從“正在修改”變遷為“正式發(fā)布” 。CCB 在 《配置項變更控制報告》中簽字，結(jié)束變更。 輸出? 本規(guī)程的所有信息都記錄在《配置項變更控制報告》中。 結(jié)束準則? CCB 簽字結(jié)束變更。 度量? CCB 統(tǒng)計變更工作量。 實施建議? 要求所有人員對其工作成果進行配置管理。? 對全員進行配置管理培訓。? 由于配置庫里保存的是項目的所有工作成果，應當選擇“責任心強、可靠”的人員擔任配置管理員。? 選用合適的軟件工具，盡量減少配置管理過程的工作