王 夢， 王飛飛， 劉 鈺

（濰柴動力股份有限公司， 山東濰坊 261061）

CMMI是由卡內(nèi)基梅隆大學(xué)軟件工程研究所指定和發(fā)布的用來評價開發(fā)商過程能力和組織成熟度的一套標(biāo)準(zhǔn)， 也可以作為廠商提升產(chǎn)品開發(fā)過程中管理水平的參考模型。CMMI框架的模型包含CMMI服務(wù)、 CMMI開發(fā)、 CMMI采購，其中CMMI開發(fā)包含16個過程域， 配置管理過程域 （CM）為CMMI開發(fā)的核心過程域之一， 它貫穿軟件開發(fā)工作全生命周期， 與軟件品質(zhì)有著緊密關(guān)系， 做好軟件配置管理，能夠有效保障軟件品質(zhì)。

1 配置管理內(nèi)容

1.1 目的

配置管理的主要目的是保證項目和產(chǎn)品的整個生存周期內(nèi)， 工作產(chǎn)品處于受控狀態(tài)、 為項目參與者提供準(zhǔn)確的信息、 實現(xiàn)歷史版本維護(hù)、 在項目需要時能 “返回” 過去的狀態(tài)， 保證產(chǎn)品可追溯性。

1.2 配置管理三要素

配置管理三要素： 配置項、 基線、 配置庫。

1） 配置項是工作產(chǎn)品的集合， 可以作為單個實體進(jìn)行處理， 配置項的版本和標(biāo)識具有唯一性， 即一個項目中某一配置項具有唯一的版本和標(biāo)識， 可采用版本樹實現(xiàn)追溯。

2） 基線是一組正式評審?fù)ㄟ^的工作產(chǎn)品， 基線內(nèi)的產(chǎn)品作為進(jìn)一步開發(fā)的基礎(chǔ)， 只有通過更改控制過程方可進(jìn)行修改， 為配置項連續(xù)演變提供穩(wěn)定的基礎(chǔ)。 常見的基線有3條， 分別為功能基線、 分配基線、 產(chǎn)品基線。

功能基線主要包含輸入至項目的協(xié)議文件與軟件研制任務(wù)書文件， 功能基線的建立， 標(biāo)志著需求已被理解和確認(rèn)。

分配基線在功能基線基礎(chǔ)上增加需求規(guī)格說明文件，分配基線的建立， 標(biāo)志著需求已被分解為具體條目化軟件需求， 可直接指導(dǎo)軟件開發(fā)與設(shè)計。

產(chǎn)品基線包含分配基線及需要交付至客戶的配置項，產(chǎn)品基線的建立， 標(biāo)志著產(chǎn)品已通過測試及驗證， 可被客戶獲取與使用。

3） 配置庫用于存放項目生命周期中產(chǎn)生的配置項與數(shù)據(jù)， 是用于支持項目開發(fā)、 保護(hù)項目資產(chǎn)的過程資產(chǎn)庫。 項目應(yīng)當(dāng)具備3 個配置庫， 分別為開發(fā)庫、 受控庫和產(chǎn)品庫。

開發(fā)庫主要用于存放項目中所有配置項與數(shù)據(jù)項， 所有項目組成員均具有開發(fā)庫的讀寫權(quán)限， 開發(fā)庫是軟件研發(fā)時項目組成員信息交互的主要場所， 應(yīng)當(dāng)保證其公開性。

受控庫主要用于存放已通過產(chǎn)品測試或者評審的配置項， 作為階段性產(chǎn)品的集合。 受控庫需具有嚴(yán)格的權(quán)限管理， 通常僅有配置管理員 （執(zhí)行配置管理操作的人員） 具有寫權(quán)限， 項目組所有成員具有讀權(quán)限， 且配置項進(jìn)行受控庫出入庫前， 要經(jīng)過項目級CCB （配置控制委員會）的審批授權(quán)， 此角色通常由本項目的項目經(jīng)理承擔(dān)。 此外，基線也納入受控庫進(jìn)行配置管理。

產(chǎn)品庫用于存放已定型 （鑒定） 且供交付、 生產(chǎn)、 檢驗驗收的配置項。 產(chǎn)品庫應(yīng)當(dāng)具有嚴(yán)格的權(quán)限管理， 僅有配置管理員具有產(chǎn)品庫的讀寫權(quán)限， 項目組成員及客戶具有讀權(quán)限， 客戶只具有產(chǎn)品庫的讀權(quán)限， 不具有受控庫和開發(fā)庫的讀寫權(quán)限， 以此保證開發(fā)過程對外具有保密性。只有在產(chǎn)品基線建立完成后， 才將產(chǎn)品基線內(nèi)的工作產(chǎn)品納入產(chǎn)品庫進(jìn)行管理。 產(chǎn)品庫內(nèi)配置項的出庫及更改必需由公司級CCB進(jìn)行審批授權(quán) （一般為部門領(lǐng)導(dǎo)）， 且必需征得客戶同意， 產(chǎn)品庫內(nèi)配置項出庫需嚴(yán)格按照變更控制的要求執(zhí)行。

1.3 配置管理的過程

配置管理過程主要有以下幾個步驟。

1.3.1 制定 《配置管理計劃》

《配置管理計劃》 需按照 《軟件開發(fā)計劃》 中對配置管理的要求來制定， 需明確配置庫、 配置項、 基線、 項目組成員權(quán)限、 配置管理工具等內(nèi)容， 《配置管理計劃》 經(jīng)過利益相關(guān)方評審確定后， 方可由配置管理人員按照該計劃內(nèi)容開展配置管理活動， 若有 《配置管理計劃》 發(fā)生變更，應(yīng)按照變更管理要求執(zhí)行， 變更后的文件在評審?fù)ㄟ^后方可生效。

1.3.2 建立并維護(hù)配置庫

在建立配置庫前， 應(yīng)選取合適且成熟的配置管理工具，常見的配置工具有： IBM公司的ClearCase系統(tǒng)、 SVN系統(tǒng)，或其它本地化開發(fā)管理工具。 根據(jù)項目成員角色設(shè)置對應(yīng)配置庫的讀寫權(quán)限， 根據(jù)項目階段及各過程域設(shè)置配置庫結(jié)構(gòu)， 并在整個項目生命周期內(nèi)進(jìn)行維護(hù)， 確保配置項按照配置管理要求進(jìn)行管理。

1.3.3 配置項出入庫及基線的建立

按照 《配置管理計劃》 中明確的配置項明細(xì)與入庫時機(jī)， 開展配置項入庫， 并根據(jù)配置管理規(guī)程執(zhí)行出庫操作。 出入庫申請單按配置管理規(guī)程審批通過后， 才可由配置管理員執(zhí)行出入庫操作， 且執(zhí)行出入庫前需對配置項版本、 標(biāo)識、 名稱和實際內(nèi)容符合性進(jìn)行審核， 并檢查配置項是否完好無損壞。 出入庫操作完成后， 需及時將出入庫明細(xì)記錄在配置項狀態(tài)表中， 以便后續(xù)追溯配置項變更情況。

基線的建立按照 《配置管理計劃》 執(zhí)行， 需按照明確的時機(jī)及納入的配置項清單完成建立。 基線建立前需要向?qū)?yīng)的項目級CCB或公司級CCB進(jìn)行申請， 申請通過后方可執(zhí)行基線建立。 基線建立完成后應(yīng)當(dāng)進(jìn)行基線發(fā)布， 可以采用郵件、 會議等方式通知利益相關(guān)方。

配置項出入庫及基線建立的時機(jī)均需在配置管理體系文件中明確， 以便指導(dǎo)配置管理員準(zhǔn)確執(zhí)行操作。

1.3.4 配置活動審核

配置活動審核主要包含功能配置審核、 物理配置審核、配置管理審核。

1） 功能配置審核主要審核配置項的功能、 性能是否達(dá)到功能基線文件中提出的需求， 開展功能配置審核時， 可通過測試及評審結(jié)果輔助審核。

2） 物理配置審核包含入庫前審核與基線建立或變更時審核。 入庫前主要審核版本、 標(biāo)識及配置項內(nèi)容與文檔是否一致且正確可用； 在基線建立及變更時開展的物理配置審核需對配置庫內(nèi)的配置項進(jìn)行全面檢查， 確保入庫的配置項內(nèi)容與其文檔一致且正確可用。

3） 配置管理審核主要審核配置管理工作是否按配置管理相關(guān)標(biāo)準(zhǔn)與 《配置管理計劃》 執(zhí)行， 配置管理活動是否有效。

1.3.5 變更的控制

變更在項目開發(fā)中無法避免， 變更發(fā)生時會產(chǎn)生大量工程及管理工作。 由于軟件是看不見摸不著， 內(nèi)部又錯綜復(fù)雜， 配置項之間也有著密切關(guān)系， 針對變更造成的潛在影響一旦未被識別， 將會給測試、 使用、 維護(hù)造成風(fēng)險和困難。 為保證項目變更有效準(zhǔn)確進(jìn)行， 必需制定變更控制規(guī)程， 并對變更影響模板進(jìn)行定制式出具。 常見的變更影響分析主要考慮以下幾方面： 對開發(fā)進(jìn)度的影響、 對發(fā)布進(jìn)度的影響、 對人員安排的影響、 對成本的影響、 對現(xiàn)有功能的影響、 風(fēng)險分析、 對其他工作產(chǎn)品的影響、 對基線的影響。

2 配置管理常見問題及建議

配置管理是軟件項目管理的核心， 如果配置管理工作做不好， 會造成軟件開發(fā)過程中多代碼多版本混亂， 無法準(zhǔn)確地進(jìn)行追溯、 增加產(chǎn)品返工的風(fēng)險。 在配置管理工作中， 常見問題如下。

2.1 配置管理人員問題

在軟件研制項目中， 部分項目任命未接受過專業(yè)培訓(xùn)的項目開發(fā)人員擔(dān)任配置管理員， 由于該人員未經(jīng)過系統(tǒng)學(xué)習(xí)， 缺少配置管理工作經(jīng)驗， 在配置管理過程中易導(dǎo)致配置項受控時機(jī)不準(zhǔn)確， 配置審核有效性差， 不能及時發(fā)現(xiàn)問題及糾正。

建議任命經(jīng)過專業(yè)培訓(xùn)的專人承擔(dān)配管工作， 若由于人力資源緊張， 則可以由一個專業(yè)配置管理員承擔(dān)多個項目的配管工作。 若缺少具備專業(yè)能力的配置管理員， 建議由項目助理或集成人員兼職， 項目助理需參與項目全生命周期， 需整體掌握項目進(jìn)度及交付物情況； 集成人員在集成前需要準(zhǔn)確提取模型代碼， 需具備對配置項準(zhǔn)確識別的能力， 并在開展系統(tǒng)測試前， 需有能力檢查模型及代碼是否完整。 此外， 項目品質(zhì)保證人員需要保證對配置管理工作的審核能力， 并根據(jù)關(guān)鍵節(jié)點多頻次、 全方位開展審核工作。

2.2 配置管理計劃不合理問題

由于 《配置管理計劃》 制定后評審不足， 與實際工作要求不符， 工作中未按照計劃開展配置管理工作及建立基線， 導(dǎo)致實際工作與計劃沖突， 出現(xiàn)未及時對計劃進(jìn)行變更， 漏入庫或者多入庫的情況。

建議軟件配置管理計劃完成后組織有效的同行評審，確保計劃準(zhǔn)確、 與工作實際相符。 配置管理員執(zhí)行入庫時需嚴(yán)格按照計劃執(zhí)行， 當(dāng)計劃無法滿足工作實際時， 應(yīng)及時對 《配置管理計劃》 進(jìn)行修訂。 進(jìn)行物理配置審核時，按照計劃內(nèi)容對入庫的明細(xì)與計劃入庫明細(xì)進(jìn)行對比， 確保工作產(chǎn)品完整入庫。

2.3 變更問題

變更管理是配置管理的難點所在， 常出現(xiàn)問題有： 實際變更內(nèi)容與申請變更內(nèi)容不一致； 配置項變了， 基線未變； 變更不完整或錯誤； 變更審批有效性差。

建議出具專業(yè)的變更申請單及變更報告單模板， 當(dāng)發(fā)生變更時， 按照模板內(nèi)容進(jìn)行填寫、 執(zhí)行評審， 明確本次變更的配置項及對應(yīng)內(nèi)容， 明確變更后要重新建立的基線明細(xì)， 變更后需開展的審核及對應(yīng)審核的執(zhí)行人員和時間。配置管理員在執(zhí)行變更出庫時， 應(yīng)核對變更申請單和出庫申請單內(nèi)容， 確認(rèn)無誤后再執(zhí)行出庫操作， 變更后入庫時對變更報告單及入庫申請單進(jìn)行核對， 確認(rèn)無誤后再執(zhí)行入庫操作。 不同類型變更由不同級別CCB審核， 并制定對應(yīng)檢查項列表， 審核變更時采取會議形式， 按照檢查項列表逐條進(jìn)行審核， 減少不必要的變更， 確保變更審批有效性。

3 結(jié)論

本文通過介紹配置管理過程的內(nèi)容、 常見問題及改進(jìn)建議， 旨在有效降低軟件項目版本管理中存在的風(fēng)險， 提升軟件管理水平， 保證軟件品質(zhì)， 推動軟件研制過程標(biāo)準(zhǔn)化， 使配置管理過程能更好地服務(wù)于科研生產(chǎn)。