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