IT行業(yè)配置管理

配置管理，ConfigurationManagement,CM,的目的是通過執(zhí)

行版本控制、變更控制等規(guī)程，以及使用配置管理軟件，來保證所

有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有

效保護。配置管理過程域是SPP模型的重要組成部分。本規(guī)范闡

述了配置管理過程域的四個主要規(guī)程：

?制定配置管理計劃[SPP-PROC-CM-PLANNING]?配置庫管理

[SPP-PROC-CM-LIB]

?配置項版本控制[SPP-PROC-CM-VERSION]?配置項變更控制

[SPP-PROC-CM-CHANGE]上述每個規(guī)程的“目標”、“角色不職

責”、"啟勵準則”、“輸入”、“主要步驟”、“輸出”、

“完成準則”和“度量”均已定義。本規(guī)范適用于國內(nèi)IT企業(yè)

的軟件研發(fā)項目。建議用戶根據(jù)自身情況，如商業(yè)目標、研發(fā)實

力等，適當?shù)匦薷谋疽?guī)范，然后推廣使用。17.1介紹

項目研發(fā)和管理過程中會產(chǎn)生許許多多的工作成果，例如文檔、

程序和數(shù)據(jù)等，它們都應(yīng)當被保存起來，以便查閱和修改。如果把

所有文件一

股腦地塞進計算機里，那么使用起來肯定很麻煩。毫無疑問，人們

應(yīng)當將文件分門別類、有條理地保存起來。

凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項，

Configurationitem,

CI,,配置項主要有兩大類:

,1,屬于產(chǎn)品組成部分的工作成果，例如需求文檔、設(shè)計文檔、

源代碼、測試用例等。

,2,項目管理和機構(gòu)支撐過程域產(chǎn)生的文檔。這些文檔雖然不

是產(chǎn)品的組成部分，但是值得保存。

每個配置項的主要屬性有：名稱、標識符、文件狀態(tài)、版本、蚱

者、日期等。所有配置項都被保存在配置庫里，確保不會混淆、

丟失。配置項及其歷史記錄反映了軟件的演化過程。

基線，Baseline,由一組配置項組成，這些配置項構(gòu)成了一個相

對穩(wěn)定的逡輯實體。基線中的配置項被“凍結(jié)”了，不能再被任

何人隨意修改，見變更控制規(guī)程，?；€通常對應(yīng)于開發(fā)過程中

的里程碑，Milestone,,一個產(chǎn)品可以有多個基線，也可以只有

一個基線?；€的主要屬性有：名稱、標識符、版本、日期等。

通常將交付給客戶的基線稱為一個“Release”，為內(nèi)部開發(fā)用

的基線則稱為一個"Build”。

所有的項目成員都要使用配置管理軟件來保護自己的工作成果。

機構(gòu)應(yīng)當采用統(tǒng)一的配置管理軟件，常見的配置管理軟件有

Microsoft的

VisualSourceSafe和Rational的ClearCase等。為了提高

配置管理的效率和安全性，機構(gòu)應(yīng)當有與門的配置管理員，角

色，。配置管理員為每個項目制定《配置管理計劃》，創(chuàng)建和維

護配置庫。

鑒于配置管理的重要性和復(fù)雜性，機構(gòu)還應(yīng)當設(shè)立配置控制委員

會，ConfigurationControlBoard.CCB,。CCB是個虛擬小組，

對配置管理各項活勵擁有決策權(quán)，例如畝批計劃，審批變更請求

等，。對于配置管理而言，CCB是決策者，而配置管理員是執(zhí)行

者。

如果機構(gòu)的各個項目緊密相關(guān)，例如一個產(chǎn)品線下的多個項目，

建議機構(gòu)設(shè)立公共的CCB,這個公共的CCB對所有項目的配置管

理擁有決策權(quán)。如果機構(gòu)的各個項目相對獨立，那么每個項目可

以設(shè)立各自的CCB,CCB的決策采用“少數(shù)服從多數(shù)”原則0

一、制定配置管理計劃

配置管理員制定《配置管理計劃》，主要內(nèi)容包括配置管理軟硬

件資源、配置項計劃、基線計劃、交付計劃、備份計劃等。CCB

審批該計劃。二、配置庫管理

配置管理員為項目創(chuàng)建配置庫，并紿每個項目成員分配權(quán)限。各

項目成員根據(jù)自己的權(quán)限操作配置庫。配置管理員定期維護配置

庫，例如清楚垃圾文件、備份配置庫等。

三、版本控制

在項目開發(fā)過程中，絕大部分的配置項都要經(jīng)過多次的修改才能

最終確定下來。對配置項的任何修改都將產(chǎn)生新的版本。由于我

們不能保證新版本一定比老版本“好”，所以不能拋棄老版本。

版本控制的目的是按照一定的規(guī)則保存配置項的所有版本，避免

發(fā)生版本丟失戒混淆等現(xiàn)象，并可可以快速準確地查找到配置項

的任何版本。

配置項的狀態(tài)有三種：“草稿”、“正式發(fā)布”和“正在修改”，

本規(guī)程制定了配置項狀態(tài)變遷不版本號的規(guī)則。

四、變更控制

在項目開發(fā)過程中，配置項發(fā)生變更幾乎是不可避免的。變更控

制的目的就是為了防止配置項被隨意修改而導致混亂。

修改處于“草稿”狀態(tài)的配置項不算是“變更”，無需CCB的批

準，修改者按照版本控制規(guī)則執(zhí)行即可。

當配置項的狀態(tài)成為“正式發(fā)布”，戒者被“凍結(jié)”后，此時任何

人都不能隨意修改，必須依據(jù)“申請，審批，執(zhí)行變更，再評審，結(jié)

束”的規(guī)則執(zhí)行。

五、配置審計

為了保證所有人員，包括項目成員、配置管理員和CCB,都遵守

配置管理規(guī)范，質(zhì)量保證人員要定期審計配置管理工作。配置審

計是一種“過

程質(zhì)量檢查”活勵，是質(zhì)量保證人員的工作職責之一。請參考質(zhì)

量保證規(guī)范SPP-PROC-QA,此處不再論述。

配置管理過程域產(chǎn)生的主要文檔有：

?《配置管理計劃》，模板見［SPP-TEMP-CM-PLAN］。

?《配置庫管理報告》，模板見［SPP-TEMP-CM-LIB］。

?《配置項變更控制報告》，模板見［SPP-TEMP-CM-CHANGE］。

17.2制定配置管理計劃

17.2.1目的

1制定配置管理計劃，以便有計劃地開展配置管理工作。

17.2.2角色與職責

1配置管理員制定《配置管理計劃》。

1CCB審批《配置管理計劃》。CCB的人數(shù)視項目的規(guī)模而定。通

常CCB由項目經(jīng)理、資深項目成員等人組成，項目經(jīng)理為CCB負

責人。CCB的決策采用“少數(shù)服從多數(shù)”原則。

17.2.3啟動準則

1《項目計劃》已經(jīng)制定

1配置管理員和CCB已經(jīng)確定。

17.2.4輸入

1《項目計劃》

17.2.5主要步驟

［Stepl］確定配置管理的軟硬件資源

1配置管理員根據(jù)項目的規(guī)模以及財力，確定配置管理軟件以及計

算機資源，考慮內(nèi)存、外存、CPU等，。常用的配置管理軟件有

Microsoft

公司的VisualSourceSafe和Rational公司的ClearCase

等。［Step2］制定配置項計劃

1配置管理員識別項目的主要配置項。每個配置項都有唯一的標

識符，標識符的參考格式為Project-Type…Type-Number。

?可以在Project,戒Product,前面加上公司的標識符。

?Type…Type表示配置項類型，可以采用多級縮寫。

?Number為3為數(shù)字，范圍從001到999,表示一個配置項有若干

個文件。若配置項只有一個文件，則該項可以省略。

1配置項計劃的參考格式如下：

類型主要配置項標識符預(yù)計正式發(fā)布時間

[Step3]制定基線計劃

1配置管理員確定每個基線的名稱，標識符，及其主要配置項，估

計每個基線建立的時間。基線計劃的參考格式如下：

基線名稱/標識符基線所包含的主要配置項預(yù)計建立時間

[Step4]制定配置庫備份計劃

1配置管理員制定配置庫備份計劃，指明“何人”在“何時”，頻

度，將配置庫備份到“何處”。

[Step5]審批《配置管理計劃》

1CCB審批《配置管理計劃》。若該計劃被批準，則請CCB負責人

簽字認可。否則，配置管理員按照CCB的意見修改《配置管理計

劃》，直到該計劃被批準為止。

17.2.6輸出

1《配置管理計劃》

17.2.7結(jié)束準則

1《配置管理計劃》已經(jīng)制定并被CCB的批準。17.2.8度量

1配置管理統(tǒng)計工作量以及文檔的規(guī)模，匯報給項目經(jīng)理。

17.3配置庫管理

17.3.1目的

1所有人員依照配置管理規(guī)范和《配置管理計劃》操作配置庫。

17.3.2角色與職責

1配置管理創(chuàng)建并維護配置庫。

1項目成員在權(quán)限之內(nèi)操作配置庫。

17.3.3啟動準則

1《配置管理計劃》已經(jīng)制定。

1配置管理的軟件硬件已經(jīng)存在。

17.3.4輸入

1《配置管理計劃》

17.3.5主要步驟

［Stepl］創(chuàng)建配置庫

1配置管理員創(chuàng)建配置庫，井可至少創(chuàng)建配置庫的所有第一級目

錄。［Step2］分配權(quán)限

1配置管理員為每個項目成員分配操作權(quán)限。一般地，項目成員擁

有Add,Checkin/Checkout,Download等權(quán)限，但是不能擁有

“初除”權(quán)限。配置管理員的權(quán)限最高。具體操作視所采用的配

置管理軟件而定。［Step3］配置庫操作與管理

1項目成員根據(jù)自己的權(quán)限操作配置庫，例如

Add,Checkin/Checkout,

Download等。

1配置管理員根據(jù)“基線計劃”創(chuàng)建不維護基線，“凍結(jié)”配置項,

控制變更。

1配置管理員定期清除配置庫里的垃圾文件。

1配置管理員定期備份配置庫。

1交付管理。這里“交付”是指從配置庫中提取配置項，交付給客

戶戒項目外的人員。交付出去的配置項必須有據(jù)可查，避免發(fā)生

混亂。流程如下：

,1,“索取人”向CCB提出交付申請。

,2,CCB審批該申請。如果該申請不合法，合理，，則拒絕交付

配置項。如果同意交付，CCB應(yīng)給出詳細的交付清單。

,3,配置管理員依據(jù)CCB的批示，從配置庫中提取配置項交付給

“索取人”。

,4,“索取人”驗收后簽字。

17.3.6輸出

1《配置庫管理報告》，由配置管理員撰寫，

17.3.7結(jié)束準則

1對配置庫的操作不管理將持續(xù)到項目結(jié)束。

17.3.8度量

1配置管理員統(tǒng)計工作量以及文檔規(guī)模。

17.3版本控制

17.3.1目的

1按照一定的規(guī)則保存配置項的所有版本，避免發(fā)生版本丟失戒混

清等現(xiàn)象，并丐可以快速準確地查找到配置項的任何版本。

17.3.2角色與職責

1所有項目成員都必須遵照版本控制規(guī)程操作配置庫。

17.3.3配置項狀態(tài)變遷規(guī)則

配置項的狀態(tài)有三種：“草稿”，Draft,、“正式發(fā)布”，

Released,和“正在修改"，Changing,。

配置項狀態(tài)變遷如圖17-2所示。配置項剛建立時其狀態(tài)為“草

稿”。配置項通過評審，戒審批，后，其狀態(tài)變?yōu)椤罢桨l(fā)

布“。此后若更改配置項，必須依照“變更控制規(guī)程”執(zhí)行，其狀

態(tài)變?yōu)椤罢谛薷摹?。當配置項修改完畢并重新通過評審，戒審

批，時，其狀態(tài)又變?yōu)椤罢桨l(fā)布”，如比循環(huán)。

17.3.4配置項版本號規(guī)則

配置項的版本號不配置項的狀態(tài)緊密相關(guān)：

,1,處于“草稿”狀態(tài)的配置項的版本號格式為：0.YZ?YZ數(shù)字

范圍為01-99o

?隨著草稿的不斷完善，“YZ”的取值應(yīng)遞增?！癥Z”的剃值和增

幅由用戶自己把握。

,2,處于“正式發(fā)布”狀態(tài)的配置項的版本號格式為：X.Y

?X為主版本號，取值范圍為1-9。Y為次版本號，取值范圍為1-

9o?配置項第一次“正式發(fā)布”時，版本號為1.0o

?如果配置項的版本升級幅度比較小，一般只增大Y值，X值保持

不變。只有當配置項版本升級幅度比較大時，才允許增大X值，

,3,處于“正在修改”狀態(tài)的配置項的版本號格式為：X.YZ?配

置項正在修改時，一般只增大Z值，X.Y值保持不變。

?當配置項修改完畢，狀態(tài)重新成為“正式發(fā)布”時，將Z值設(shè)置

為0,增加X.Y值。參見規(guī)則，2,o

17.3.4配置項版本控制流程

[Step1]創(chuàng)建配置項

1項目成員依據(jù)《配置管理計劃》，在配置庫中創(chuàng)建屬于其任務(wù)范

圍內(nèi)的配置項。此時配置項的狀態(tài)為“苴稿”，其版本號格式為

0.YZo[Step2]修改處于“草稿”狀態(tài)的配置項

1項目成員使用配置管理軟件的Checkout/Checkin功能，可以

自由修改處于“草稿”狀態(tài)的配置項，不受變更控制規(guī)程約束，

版本號格式為0.YZo

[Step3]技術(shù)評審或領(lǐng)導審批

1如果配置項是技術(shù)文檔，則需要接受技術(shù)評審，參見技術(shù)評審規(guī)

程[SPP-PROC-TR],o如果配置項是“計劃”這類文件，則需要

項目經(jīng)理，戒上級領(lǐng)導，的審批。

1若配置項通過了技術(shù)評審戒領(lǐng)導審批，則轉(zhuǎn)向[Step4],否則轉(zhuǎn)

向[Step2]o

[Step4]正式發(fā)布

1配置項通過技術(shù)評審戒領(lǐng)導審批之后，則配置項的狀態(tài)從“芭

稿”變遷為“正式發(fā)布”，版本號格式為X.Y。

[Step5]變更

1修改處于“正式發(fā)布”狀態(tài)的配置項，必須按照“變更控制規(guī)

程”執(zhí)行，主要步驟如下，詳見變更控制規(guī)程，：

?如果CCB同意變更，則配置項狀態(tài)從“正式發(fā)布”變遷為“正在

修改”。

?項目成員使用Checkout/Checkin功能，可以修改處于“正在

修改”狀態(tài)的配置項，版本號格式為X.YZ。

?修改完畢后，該配置項要重新接受技術(shù)評審戒領(lǐng)導審批，轉(zhuǎn)向

[Step3]o17.4配置項變更控制

17.4.1目的

1防止配置項被隨意修改而導致混亂。

17.4.2角色與職責

1CCB對審批變更申請。

17.4.3啟動準則

1待變更的配置項吠態(tài)為“正式發(fā)布"，戒者該配置項已經(jīng)成為某

個基線的一部分，即被“凍結(jié)”，。

17.4.4輸入

1待變更的配置項

17.4.5主要步驟

[Stepl]變更申請

1變更申請人向CCB提交變更申請，重點說明“變更內(nèi)容”和

“變更原因”。

[Step2]審批變更申請

1CCB審批該申請，分析此變更對項目造成的影響。如果同意變更,

則轉(zhuǎn)向[Step3],否則終止本規(guī)程。

補充說明：一個配置項的變更可能導致其它配置項也發(fā)生變

更，CCB在審批變更申請時一定要考