企業(yè)配置管理策劃方案研究

1、 TOC o 1-3 h z HYPERLINK l _Toc17175550 第17章 配置治理 PAGEREF _Toc17175550 h 2 HYPERLINK l _Toc17175551 17.1 介紹 PAGEREF _Toc17175551 h 2 HYPERLINK l _Toc17175552 17.2 制定配置治理打算 PAGEREF _Toc17175552 h 4 HYPERLINK l _Toc17175553 17.2.1 目的 PAGEREF _Toc17175553 h 4 HYPERLINK l _Toc17175554 17.2.2 角色與職責(zé) PAGER

2、EF _Toc17175554 h 4 HYPERLINK l _Toc17175555 17.2.3 啟動(dòng)準(zhǔn)則 PAGEREF _Toc17175555 h 4 HYPERLINK l _Toc17175556 17.2.4 輸入 PAGEREF _Toc17175556 h 4 HYPERLINK l _Toc17175557 17.2.5 要緊步驟 PAGEREF _Toc17175557 h 4 HYPERLINK l _Toc17175558 Step1 確定配置治理的軟硬件資源 PAGEREF _Toc17175558 h 4 HYPERLINK l _Toc17175559 St

3、ep2 制定配置項(xiàng)打算 PAGEREF _Toc17175559 h 5 HYPERLINK l _Toc17175560 Step3 制定基線打算 PAGEREF _Toc17175560 h 5 HYPERLINK l _Toc17175561 Step4 制定配置庫備份打算 PAGEREF _Toc17175561 h 5 HYPERLINK l _Toc17175562 Step5 審批配置治理打算 PAGEREF _Toc17175562 h 5 HYPERLINK l _Toc17175563 17.2.6 輸出 PAGEREF _Toc17175563 h 5 HYPERLINK

4、 l _Toc17175564 17.2.7 結(jié)束準(zhǔn)則 PAGEREF _Toc17175564 h 6 HYPERLINK l _Toc17175565 17.2.8 度量 PAGEREF _Toc17175565 h 6 HYPERLINK l _Toc17175566 17.3 配置庫治理 PAGEREF _Toc17175566 h 6 HYPERLINK l _Toc17175567 17.3.1 目的 PAGEREF _Toc17175567 h 6 HYPERLINK l _Toc17175568 17.3.2 角色與職責(zé) PAGEREF _Toc17175568 h 6 HYP

5、ERLINK l _Toc17175569 17.3.3 啟動(dòng)準(zhǔn)則 PAGEREF _Toc17175569 h 6 HYPERLINK l _Toc17175570 17.3.4 輸入 PAGEREF _Toc17175570 h 6 HYPERLINK l _Toc17175571 17.3.5 要緊步驟 PAGEREF _Toc17175571 h 6 HYPERLINK l _Toc17175572 Step1 創(chuàng)建配置庫 PAGEREF _Toc17175572 h 6 HYPERLINK l _Toc17175573 Step2 分配權(quán)限 PAGEREF _Toc17175573

6、h 7 HYPERLINK l _Toc17175574 Step3 配置庫操作與治理 PAGEREF _Toc17175574 h 7 HYPERLINK l _Toc17175575 17.3.6 輸出 PAGEREF _Toc17175575 h 7 HYPERLINK l _Toc17175576 17.3.7 結(jié)束準(zhǔn)則 PAGEREF _Toc17175576 h 7 HYPERLINK l _Toc17175577 17.3.8 度量 PAGEREF _Toc17175577 h 7 HYPERLINK l _Toc17175578 17.3 版本操縱 PAGEREF _Toc17

7、175578 h 7 HYPERLINK l _Toc17175579 17.3.1 目的 PAGEREF _Toc17175579 h 7 HYPERLINK l _Toc17175580 17.3.2 角色與職責(zé) PAGEREF _Toc17175580 h 8 HYPERLINK l _Toc17175581 17.3.3 配置項(xiàng)狀態(tài)變遷規(guī)則 PAGEREF _Toc17175581 h 8 HYPERLINK l _Toc17175582 17.3.4 配置項(xiàng)版本號(hào)規(guī)則 PAGEREF _Toc17175582 h 8 HYPERLINK l _Toc17175583 17.3.4 配

8、置項(xiàng)版本操縱流程 PAGEREF _Toc17175583 h 9 HYPERLINK l _Toc17175584 Step1 創(chuàng)建配置項(xiàng) PAGEREF _Toc17175584 h 9 HYPERLINK l _Toc17175585 Step2 修改處于“草稿”狀態(tài)的配置項(xiàng) PAGEREF _Toc17175585 h 9 HYPERLINK l _Toc17175586 Step3 技術(shù)評(píng)審或領(lǐng)導(dǎo)審批 PAGEREF _Toc17175586 h 9 HYPERLINK l _Toc17175587 Step4 正式公布 PAGEREF _Toc17175587 h 9 HYPERL

9、INK l _Toc17175588 Step5 變更 PAGEREF _Toc17175588 h 9 HYPERLINK l _Toc17175589 17.4 配置項(xiàng)變更操縱 PAGEREF _Toc17175589 h 9 HYPERLINK l _Toc17175590 17.4.1 目的 PAGEREF _Toc17175590 h 9 HYPERLINK l _Toc17175591 17.4.2 角色與職責(zé) PAGEREF _Toc17175591 h 10 HYPERLINK l _Toc17175592 17.4.3 啟動(dòng)準(zhǔn)則 PAGEREF _Toc17175592 h

10、10 HYPERLINK l _Toc17175593 17.4.4 輸入 PAGEREF _Toc17175593 h 10 HYPERLINK l _Toc17175594 17.4.5 要緊步驟 PAGEREF _Toc17175594 h 10 HYPERLINK l _Toc17175595 Step1 變更申請(qǐng) PAGEREF _Toc17175595 h 10 HYPERLINK l _Toc17175596 Step2 審批變更申請(qǐng) PAGEREF _Toc17175596 h 10 HYPERLINK l _Toc17175597 Step3 安排變更任務(wù) PAGEREF _

11、Toc17175597 h 10 HYPERLINK l _Toc17175598 Step4 執(zhí)行變更任務(wù) PAGEREF _Toc17175598 h 10 HYPERLINK l _Toc17175599 Step5 對(duì)更改后的配置項(xiàng)重新進(jìn)行技術(shù)評(píng)審（或?qū)徟?PAGEREF _Toc17175599 h 10 HYPERLINK l _Toc17175600 Step6 結(jié)束變更 PAGEREF _Toc17175600 h 11 HYPERLINK l _Toc17175601 17.4.6 輸出 PAGEREF _Toc17175601 h 11 HYPERLINK l _Toc1

12、7175602 17.4.7 結(jié)束準(zhǔn)則 PAGEREF _Toc17175602 h 11 HYPERLINK l _Toc17175603 17.4.8 度量 PAGEREF _Toc17175603 h 11 HYPERLINK l _Toc17175604 17.5 實(shí)施建議 PAGEREF _Toc17175604 h 11第17章 配置治理配置治理（Configuration Management, CM）的目的是通過執(zhí)行版本操縱、變更操縱等規(guī)程，以及使用配置治理軟件，來保證所有配置項(xiàng)的完整性和可跟蹤性。配置治理是對(duì)工作成果的一種有效愛護(hù)。配置治理過程域是SPP模型的重要組成部分。本

13、規(guī)范闡述了配置治理過程域的四個(gè)要緊規(guī)程：制定配置治理打算 SPP-PROC-CM-PLANNING配置庫治理 SPP-PROC-CM-LIB配置項(xiàng)版本操縱 SPP-PROC-CM-VERSION配置項(xiàng)變更操縱 SPP-PROC-CM-CHANGE上述每個(gè)規(guī)程的“目標(biāo)”、“角色與職責(zé)”、“啟動(dòng)準(zhǔn)則”、“輸入”、“要緊步驟”、“輸出”、“完成準(zhǔn)則”和“度量”均已定義。本規(guī)范適用于國(guó)內(nèi)IT企業(yè)的軟件研發(fā)項(xiàng)目。建議用戶依照自身情況（如商業(yè)目標(biāo)、研發(fā)實(shí)力等）適當(dāng)?shù)匦薷谋疽?guī)范，然后推廣使用。17.1 介紹項(xiàng)目研發(fā)和治理過程中會(huì)產(chǎn)生許許多多的工作成果，例如文檔、程序和數(shù)據(jù)等，它們都應(yīng)當(dāng)被保存起來，以便查閱和

14、修改。假如把所有文件一股腦地塞進(jìn)計(jì)算機(jī)里，那么使用起來確信專門苦惱。毫無疑問，人們應(yīng)當(dāng)將文件分門不類、有條理地保存起來。凡是納入配置治理范疇的工作成果統(tǒng)稱為配置項(xiàng)（Configuration Item, CI），配置項(xiàng)要緊有兩大類：（1）屬于產(chǎn)品組成部分的工作成果，例如需求文檔、設(shè)計(jì)文檔、源代碼、測(cè)試用例等。（2）項(xiàng)目治理和機(jī)構(gòu)支撐過程域產(chǎn)生的文檔。這些文檔盡管不是產(chǎn)品的組成部分，然而值得保存。每個(gè)配置項(xiàng)的要緊屬性有：名稱、標(biāo)識(shí)符、文件狀態(tài)、版本、作者、日期等。所有配置項(xiàng)都被保存在配置庫里，確保可不能混淆、丟失。配置項(xiàng)及其歷史記錄反映了軟件的演化過程?；€（Baseline）由一組配置項(xiàng)組成，

15、這些配置項(xiàng)構(gòu)成了一個(gè)相對(duì)穩(wěn)定的邏輯實(shí)體。基線中的配置項(xiàng)被“凍結(jié)”了，不能再被任何人隨意修改（見變更操縱規(guī)程）?；€通常對(duì)應(yīng)于開發(fā)過程中的里程碑（Milestone），一個(gè)產(chǎn)品能夠有多個(gè)基線，也能夠只有一個(gè)基線?；€的要緊屬性有：名稱、標(biāo)識(shí)符、版本、日期等。通常將交付給客戶的基線稱為一個(gè)“Release”，為內(nèi)部開發(fā)用的基線則稱為一個(gè)“Build”。所有的項(xiàng)目成員都要使用配置治理軟件來愛護(hù)自己的工作成果。機(jī)構(gòu)應(yīng)當(dāng)采納統(tǒng)一的配置治理軟件，常見的配置治理軟件有Microsoft的Visual SourceSafe和Rational的ClearCase等。為了提高配置治理的效率和安全性，機(jī)構(gòu)應(yīng)當(dāng)有專門

16、的配置治理員（角色）。配置治理員為每個(gè)項(xiàng)目制定配置治理打算，創(chuàng)建和維護(hù)配置庫。鑒于配置治理的重要性和復(fù)雜性，機(jī)構(gòu)還應(yīng)當(dāng)設(shè)立配置操縱委員會(huì)（Configuration Control Board, CCB）。CCB是個(gè)虛擬小組，對(duì)配置治理各項(xiàng)活動(dòng)擁有決策權(quán)（例如審批打算，審批變更請(qǐng)求等）。關(guān)于配置治理而言，CCB是決策者，而配置治理員是執(zhí)行者。假如機(jī)構(gòu)的各個(gè)項(xiàng)目緊密相關(guān)（例如一個(gè)產(chǎn)品線下的多個(gè)項(xiàng)目），建議機(jī)構(gòu)設(shè)立公共的CCB，那個(gè)公共的CCB對(duì)所有項(xiàng)目的配置治理擁有決策權(quán)。假如機(jī)構(gòu)的各個(gè)項(xiàng)目相對(duì)獨(dú)立，那么每個(gè)項(xiàng)目能夠設(shè)立各自的CCB。CCB的決策采納“少數(shù)服從多數(shù)”原則。配置治理的流程如圖17-

17、1所示。配置審計(jì)變更操縱版本操縱制定配置治理打算配置庫治理圖17-1 配置治理流程圖一、制定配置治理打算配置治理員制定配置治理打算，要緊內(nèi)容包括配置治理軟硬件資源、配置項(xiàng)打算、基線打算、交付打算、備份打算等。CCB審批該打算。二、配置庫治理配置治理員為項(xiàng)目創(chuàng)建配置庫，并給每個(gè)項(xiàng)目成員分配權(quán)限。各項(xiàng)目成員依照自己的權(quán)限操作配置庫。配置治理員定期維護(hù)配置庫，例如清晰垃圾文件、備份配置庫等。三、版本操縱在項(xiàng)目開發(fā)過程中，絕大部分的配置項(xiàng)都要通過多次的修改才能最終確定下來。對(duì)配置項(xiàng)的任何修改都將產(chǎn)生新的版本。由于我們不能保證新版本一定比老版本“好”，因此不能拋棄老版本。版本操縱的目的是按照一定的規(guī)則保

18、存配置項(xiàng)的所有版本，幸免發(fā)生版本丟失或混淆等現(xiàn)象，同時(shí)能夠快速準(zhǔn)確地查找到配置項(xiàng)的任何版本。配置項(xiàng)的狀態(tài)有三種：“草稿”、“正式公布”和“正在修改”，本規(guī)程制定了配置項(xiàng)狀態(tài)變遷與版本號(hào)的規(guī)則。四、變更操縱在項(xiàng)目開發(fā)過程中，配置項(xiàng)發(fā)生變更幾乎是不可幸免的。變更操縱的目的確實(shí)是為了防止配置項(xiàng)被隨意修改而導(dǎo)致混亂。修改處于“草稿”狀態(tài)的配置項(xiàng)不確實(shí)是“變更”，無需CCB的批準(zhǔn)，修改者按照版本操縱規(guī)則執(zhí)行即可。當(dāng)配置項(xiàng)的狀態(tài)成為“正式公布”，或者被“凍結(jié)”后，現(xiàn)在任何人都不能隨意修改，必須依據(jù)“申請(qǐng)審批執(zhí)行變更再評(píng)審結(jié)束”的規(guī)則執(zhí)行。五、配置審計(jì)為了保證所有人員（包括項(xiàng)目成員、配置治理員和CCB）都遵

19、守配置治理規(guī)范，質(zhì)量保證人員要定期審計(jì)配置治理工作。配置審計(jì)是一種“過程質(zhì)量檢查”活動(dòng)，是質(zhì)量保證人員的工作職責(zé)之一。請(qǐng)參考質(zhì)量保證規(guī)范SPP-PROC-QA，此處不再論述。配置治理過程域產(chǎn)生的要緊文檔有：配置治理打算，模板見 SPP-TEMP-CM-PLAN。配置庫治理報(bào)告，模板見 SPP-TEMP-CM-LIB。配置項(xiàng)變更操縱報(bào)告，模板見 SPP-TEMP-CM-CHANGE。17.2 制定配置治理打算17.2.1 目的制定配置治理打算，以便有打算地開展配置治理工作。17.2.2 角色與職責(zé)配置治理員制定配置治理打算。CCB審批配置治理打算。CCB的人數(shù)視項(xiàng)目的規(guī)模而定。通常CCB由項(xiàng)目經(jīng)

20、理、資深項(xiàng)目成員等人組成，項(xiàng)目經(jīng)理為CCB負(fù)責(zé)人。CCB的決策采納“少數(shù)服從多數(shù)”原則。17.2.3 啟動(dòng)準(zhǔn)則項(xiàng)目打算差不多制定配置治理員和CCB差不多確定。17.2.4 輸入項(xiàng)目打算17.2.5 要緊步驟Step1 確定配置治理的軟硬件資源配置治理員依照項(xiàng)目的規(guī)模以及財(cái)力，確定配置治理軟件以及計(jì)算機(jī)資源（考慮內(nèi)存、外存、CPU等）。常用的配置治理軟件有Microsoft公司的Visual SourceSafe和Rational公司的ClearCase等。Step2 制定配置項(xiàng)打算配置治理員識(shí)不項(xiàng)目的要緊配置項(xiàng)。每個(gè)配置項(xiàng)都有唯一的標(biāo)識(shí)符，標(biāo)識(shí)符的參考格式為Project-TypeType-N

21、umber。能夠在Project（或Product）前面加上公司的標(biāo)識(shí)符。TypeType表示配置項(xiàng)類型，能夠采納多級(jí)縮寫。Number為3為數(shù)字，范圍從001到999，表示一個(gè)配置項(xiàng)有若干個(gè)文件。若配置項(xiàng)只有一個(gè)文件，則該項(xiàng)能夠省略。配置項(xiàng)打算的參考格式如下：類型要緊配置項(xiàng)標(biāo)識(shí)符可能正式公布時(shí)刻Step3 制定基線打算配置治理員確定每個(gè)基線的名稱（標(biāo)識(shí)符）及其要緊配置項(xiàng)，可能每個(gè)基線建立的時(shí)刻?；€打算的參考格式如下：基線名稱/標(biāo)識(shí)符基線所包含的要緊配置項(xiàng)可能建立時(shí)刻Step4 制定配置庫備份打算配置治理員制定配置庫備份打算，指明“何人”在“何時(shí)”（頻度）將配置庫備份到“何處”。Step5

22、審批配置治理打算CCB審批配置治理打算。若該打算被批準(zhǔn)，則請(qǐng)CCB負(fù)責(zé)人簽字認(rèn)可。否則，配置治理員按照CCB的意見修改配置治理打算，直到該打算被批準(zhǔn)為止。17.2.6 輸出配置治理打算17.2.7 結(jié)束準(zhǔn)則配置治理打算差不多制定并被CCB的批準(zhǔn)。17.2.8 度量配置治理統(tǒng)計(jì)工作量以及文檔的規(guī)模，匯報(bào)給項(xiàng)目經(jīng)理。17.3 配置庫治理17.3.1 目的所有人員依照配置治理規(guī)范和配置治理打算操作配置庫。17.3.2 角色與職責(zé)配置治理創(chuàng)建并維護(hù)配置庫。項(xiàng)目成員在權(quán)限之內(nèi)操作配置庫。17.3.3 啟動(dòng)準(zhǔn)則配置治理打算差不多制定。配置治理的軟件硬件差不多存在。17.3.4 輸入配置治理打算17.3.5

23、 要緊步驟Step1 創(chuàng)建配置庫配置治理員創(chuàng)建配置庫，同時(shí)至少創(chuàng)建配置庫的所有第一級(jí)目錄。Step2 分配權(quán)限配置治理員為每個(gè)項(xiàng)目成員分配操作權(quán)限。一般地，項(xiàng)目成員擁有Add, Checkin/Checkout, Download等權(quán)限，然而不能擁有“刪除”權(quán)限。配置治理員的權(quán)限最高。具體操作視所采納的配置治理軟件而定。Step3 配置庫操作與治理項(xiàng)目成員依照自己的權(quán)限操作配置庫，例如Add, Checkin/Checkout, Download等。配置治理員依照“基線打算”創(chuàng)建與維護(hù)基線，“凍結(jié)”配置項(xiàng)，操縱變更。配置治理員定期清除配置庫里的垃圾文件。配置治理員定期備份配置庫。交付治理。那個(gè)

24、地點(diǎn)“交付”是指從配置庫中提取配置項(xiàng)，交付給客戶或項(xiàng)目外的人員。交付出去的配置項(xiàng)必須有據(jù)可查，幸免發(fā)生混亂。流程如下：“索取人”向CCB提出交付申請(qǐng)。CCB審批該申請(qǐng)。假如該申請(qǐng)不合法（合理），則拒絕交付配置項(xiàng)。假如同意交付，CCB應(yīng)給出詳細(xì)的交付清單。配置治理員依據(jù)CCB的批示，從配置庫中提取配置項(xiàng)交付給“索取人”?！八魅∪恕彬?yàn)收后簽字。17.3.6 輸出配置庫治理報(bào)告（由配置治理員撰寫）17.3.7 結(jié)束準(zhǔn)則對(duì)配置庫的操作與治理將持續(xù)到項(xiàng)目結(jié)束。17.3.8 度量配置治理員統(tǒng)計(jì)工作量以及文檔規(guī)模。17.3 版本操縱17.3.1 目的按照一定的規(guī)則保存配置項(xiàng)的所有版本，幸免發(fā)生版本丟失或混淆

25、等現(xiàn)象，同時(shí)能夠快速準(zhǔn)確地查找到配置項(xiàng)的任何版本。17.3.2 角色與職責(zé)所有項(xiàng)目成員都必須遵照版本操縱規(guī)程操作配置庫。17.3.3 配置項(xiàng)狀態(tài)變遷規(guī)則配置項(xiàng)的狀態(tài)有三種：“草稿”（Draft）、“正式公布”（Released）和“正在修改”（Changing）。配置項(xiàng)狀態(tài)變遷如圖17-2所示。配置項(xiàng)剛建立時(shí)其狀態(tài)為“草稿”。配置項(xiàng)通過評(píng)審（或?qū)徟┖螅錉顟B(tài)變?yōu)椤罢焦肌?。此后若更改配置?xiàng)，必須依照“變更操縱規(guī)程”執(zhí)行，其狀態(tài)變?yōu)椤罢谛薷摹?。?dāng)配置項(xiàng)修改完畢并重新通過評(píng)審（或?qū)徟r(shí)，其狀態(tài)又變?yōu)椤罢焦肌?，如此循環(huán)。通過變更操縱正式公布否決評(píng)審或?qū)徟杂尚薷恼谛薷牟莞鍒D17-2 配

26、置項(xiàng)狀態(tài)變遷圖17.3.4 配置項(xiàng)版本號(hào)規(guī)則配置項(xiàng)的版本號(hào)與配置項(xiàng)的狀態(tài)緊密相關(guān)：（1）處于“草稿”狀態(tài)的配置項(xiàng)的版本號(hào)格式為：0.YZYZ數(shù)字范圍為01-99。隨著草稿的不斷完善，“YZ”的取值應(yīng)遞增。“YZ”的初值和增幅由用戶自己把握。（2）處于“正式公布”狀態(tài)的配置項(xiàng)的版本號(hào)格式為：X.YX為主版本號(hào)，取值范圍為1-9。Y為次版本號(hào)，取值范圍為1-9。配置項(xiàng)第一次“正式公布”時(shí)，版本號(hào)為1.0。假如配置項(xiàng)的版本升級(jí)幅度比較小，一般只增大Y值，X值保持不變。只有當(dāng)配置項(xiàng)版本升級(jí)幅度比較大時(shí)，才同意增大X值。（3）處于“正在修改”狀態(tài)的配置項(xiàng)的版本號(hào)格式為：X.YZ配置項(xiàng)正在修改時(shí)，一般只增

27、大Z值，X.Y值保持不變。當(dāng)配置項(xiàng)修改完畢，狀態(tài)重新成為“正式公布”時(shí)，將Z值設(shè)置為0，增加X.Y值。參見規(guī)則（2）。17.3.4 配置項(xiàng)版本操縱流程Step1 創(chuàng)建配置項(xiàng)項(xiàng)目成員依據(jù)配置治理打算，在配置庫中創(chuàng)建屬于其任務(wù)范圍內(nèi)的配置項(xiàng)?，F(xiàn)在配置項(xiàng)的狀態(tài)為“草稿”，其版本號(hào)格式為0.YZ。Step2 修改處于“草稿”狀態(tài)的配置項(xiàng)項(xiàng)目成員使用配置治理軟件的Checkout/Checkin功能，能夠自由修改處于“草稿”狀態(tài)的配置項(xiàng)（不受變更操縱規(guī)程約束），版本號(hào)格式為0.YZ。Step3 技術(shù)評(píng)審或領(lǐng)導(dǎo)審批假如配置項(xiàng)是技術(shù)文檔，則需要同意技術(shù)評(píng)審（參見技術(shù)評(píng)審規(guī)程SPP-PROC-TR）。假如配置項(xiàng)是“打算”這類文件，則需要項(xiàng)目經(jīng)理（或上級(jí)領(lǐng)導(dǎo)）的審批。若配置項(xiàng)通過了技術(shù)評(píng)審或領(lǐng)導(dǎo)審批，則轉(zhuǎn)向 Step4，否則轉(zhuǎn)向 Step2。Step4 正式公布配置項(xiàng)通過技術(shù)評(píng)審或領(lǐng)導(dǎo)審批之后，則配置項(xiàng)的狀態(tài)從“草稿”變遷為“正式公布”，版本號(hào)格式為X.Y。Step5 變更修改處于“正式公布”狀態(tài)的配置項(xiàng)，必須按照“變更操縱規(guī)程”執(zhí)行，要緊步驟如下（詳見變更操縱規(guī)程）：假如CCB同意變更，則配置項(xiàng)狀態(tài)從“正式公布”變遷為“正在修改”。項(xiàng)目成員使用Checkout/