1、軟件配置管理規(guī)范編號：SUNNHOO-SP-TEC-01 (C)2011,2012 商狐網(wǎng)絡(luò)文檔修訂版本日期作者描述目 錄1概述31.1 目的31.2 適用范圍31.3 術(shù)語和縮略語3軟件配置管理 （SCM）31.3.2 配置項(xiàng)（CI）3基線（Baseline）31.4 權(quán)限與職責(zé)4研發(fā)總經(jīng)理助理41.4.2 項(xiàng)目經(jīng)理（PM）41.4.3 配置管理員（CMO）41.4.4 開發(fā)人員（Developer）52 實(shí)施細(xì)則52.1 配置項(xiàng)管理5配置項(xiàng)的范圍52.1.2 配置項(xiàng)基線管理62.2 版本控制72.2.1 文檔的版本控制72.2.2 發(fā)行版本表示92.3 配置庫管理102.3.1 配置庫的分

2、類102.3.2 配置庫的建立10分配權(quán)限102.4 配置變更控制11變更的分類112.4.2 變更請求的提出112.4.3 評估變更112.4.4 變更實(shí)施和確認(rèn)122.5 配置狀態(tài)報告12目的12記錄內(nèi)容122.5.3 生成報告132.6 配置審核132.6.1 類別132.6.2 執(zhí)行時機(jī)132.6.3 不符合項(xiàng)處理132.7 發(fā)行管理14交付管理141概述1.1 目的本文檔主要目的在于規(guī)范項(xiàng)目配置管理活動，確保配置項(xiàng)正確地唯一標(biāo)識并且易于存取，保證基線配置項(xiàng)的更改受控，明確基線狀態(tài)，在整個軟件生命周期中建立和維護(hù)項(xiàng)目產(chǎn)品的完整性和可追溯性。1.2 適用范圍本文檔適用于不同類別的軟件產(chǎn)品

3、和軟件項(xiàng)目開發(fā)工程的配置管理活動，針對項(xiàng)目不同在流程上作適當(dāng)?shù)膭h減。配置管理可采用各種工具及手工辦法，本文件以CVS（并行版本系統(tǒng)）配置管理工具為例，規(guī)定公司的配置管理辦法，使用其他工具時也可對應(yīng)本文件的要求參照執(zhí)行。 術(shù)語和縮略語.1軟件配置管理 （SCM）軟件配置管理是對軟件修改進(jìn)行標(biāo)識、組織和控制的技術(shù)，用來協(xié)調(diào)和控制整個過程。是通過技術(shù)或行政手段對軟件產(chǎn)品及其開發(fā)過程和生命周期進(jìn)行控制、規(guī)范的一系列措施。配置管理的目標(biāo)是記錄軟件產(chǎn)品的演化過程，確保軟件開發(fā)者在軟件生命周期中各個階段都能得到精確的不同版本的產(chǎn)品配置。1.3.2 配置項(xiàng)（CI）凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項(xiàng)，配

4、置項(xiàng)邏輯上組成軟件系統(tǒng)的各組成部分，一般是可以單獨(dú)進(jìn)行設(shè)計、實(shí)施和測試的。每個配置項(xiàng)的主要屬性有：名稱、標(biāo)簽、文件狀態(tài)、版本、作者、日期等。所有配置項(xiàng)都被保存在配置庫里，確保不會混淆、丟失。配置項(xiàng)及其歷史記錄反映了軟件的演化過程。.3基線（Baseline）在配置管理系統(tǒng)中，基線就是一個配置項(xiàng)或一組配置項(xiàng)在其生命周期的不同時間點(diǎn)上通過正式評審而進(jìn)入正式受控的一種狀態(tài)，這些配置項(xiàng)構(gòu)成了一個相對穩(wěn)定的邏輯實(shí)體，而這個過程被稱為“基線化”。每一個基線都是其下一步開發(fā)的出發(fā)點(diǎn)和參考點(diǎn)?；€確定了元素（配置項(xiàng)）的一個版本，且只確定一個版本。一般情況下，基線一般在指定的里程碑處創(chuàng)建，并與項(xiàng)目中的里程碑保持

5、同步。每個基線都將接受配置管理的嚴(yán)格控制，基線中的配置項(xiàng)被“凍結(jié)”了，不能再被任何人隨意修改，對其修改要嚴(yán)格地按照變更控制的過程進(jìn)行。在一個軟件開發(fā)階段結(jié)束時，上一個基線加上增加和修改的基線內(nèi)容形成下一個基線。基線的主要屬性有：名稱、標(biāo)簽、版本、日期等。1.4 權(quán)限與職責(zé)研發(fā)總經(jīng)理助理1）審核變更請求。1.4.2 項(xiàng)目經(jīng)理（PM）1) 審核批準(zhǔn)配置管理計劃；2) 接收或拒絕小范圍的變更申請；3) 召集評估變更；4) 提出配置管理的建議和要求；5) 配合配置管理員的工作。1.4.3 配置管理員（CMO）1) 編寫配置管理計劃；2) 執(zhí)行版本控制和變更控制方案；3) 制定訪問控制策略；4) 負(fù)責(zé)項(xiàng)

6、目的配置管理工作，包括搭建環(huán)境、權(quán)限分配、配置庫的建立、配置項(xiàng)的控制等；5) 配置管理工具的日常管理與維護(hù)；6) 配置庫的日常操作和維護(hù)；7) 負(fù)責(zé)配置審核并提交報告；8) 根據(jù)配置部署表單編譯發(fā)布版本，并維護(hù)版本；9) 對開發(fā)人員進(jìn)行相關(guān)的培訓(xùn)；10) 對配置審核中發(fā)現(xiàn)的不符合項(xiàng)，擬訂糾正措施，要求相關(guān)責(zé)任人進(jìn)行糾正。11) 監(jiān)督項(xiàng)目組成員規(guī)范的執(zhí)行情況。1.4.4 開發(fā)人員（Developer）1) 根據(jù)確定的配置管理計劃和相關(guān)規(guī)定，提交配置項(xiàng)和基線；2) 負(fù)責(zé)項(xiàng)目組內(nèi)部測試；3) 負(fù)責(zé)軟件集成和版本生成；4) 按照軟件配置管理工具的使用模型來完成開發(fā)任務(wù)。2 實(shí)施細(xì)則2.1 配置項(xiàng)管理配

7、置項(xiàng)的范圍軟件配置可包括以下幾方面：開發(fā)文檔，代碼，第三方控件、插件，參考資料，測試文檔，用戶文檔，項(xiàng)目管理文檔，驗(yàn)收文檔等。l) 項(xiàng)目文檔主要指：立項(xiàng)建議書、可行性分析報告、技術(shù)建議書、用戶需求說明書、項(xiàng)目計劃、項(xiàng)目進(jìn)度計劃、項(xiàng)目階段性計劃、產(chǎn)品需求規(guī)格說明書、概要設(shè)計報告、詳細(xì)設(shè)計、數(shù)據(jù)庫設(shè)計、界面設(shè)計、用戶操作手冊、用戶安裝手冊、培訓(xùn)文檔、驗(yàn)收報告以及上述文檔的評審記錄。2) 代碼主要指：源代碼等。3) 工具主要指：腳本文件、插件、第三方控件等。2.1.2 配置項(xiàng)基線管理結(jié)合SPP和ISO9000的相關(guān)規(guī)定，配置管理員根據(jù)配置管理規(guī)范及配置管理計劃，對配置項(xiàng)進(jìn)行分階段管理，每一階段正式評

8、審?fù)ㄟ^后納入受控庫，作為該項(xiàng)目的一個基線。1) 項(xiàng)目啟動：配置項(xiàng)包括技術(shù)建議書、可行性分析報告、用戶需求說明書等立項(xiàng)階段產(chǎn)生的文檔，評審或?qū)徟ㄟ^后建立發(fā)布基線。2) 需求階段：系統(tǒng)調(diào)研后開發(fā)人員進(jìn)行需求分析，并整理產(chǎn)品需求規(guī)格說明書。產(chǎn)品需求規(guī)格說明書經(jīng)過客戶的確認(rèn)后，建立需求基線。如需升級版本則必須通過評審或?qū)徟⒌玫娇蛻舻拇_認(rèn)。3) 項(xiàng)目計劃：需求分析完成后即可制定項(xiàng)目的開發(fā)計劃，包括項(xiàng)目計劃和主要下屬計劃。包括項(xiàng)目進(jìn)度計劃、配置管理計劃、質(zhì)量保證計劃、測試計劃、項(xiàng)目階段性計劃。項(xiàng)目開發(fā)計劃評審?fù)ㄟ^后，建立項(xiàng)目計劃基線。4) 設(shè)計：系統(tǒng)設(shè)計可分為概要設(shè)計、詳細(xì)設(shè)計、數(shù)據(jù)庫設(shè)計、數(shù)據(jù)庫字典

9、、界面設(shè)計。針對用戶需求規(guī)格說明書進(jìn)行系統(tǒng)設(shè)計，配置時應(yīng)說明系統(tǒng)設(shè)計的版本與需求分析報告版本的對應(yīng)關(guān)系。設(shè)計說明書評審或?qū)徟ㄟ^后，建立設(shè)計基線。5) 編碼（設(shè)計實(shí)現(xiàn)）：編碼按功能模塊分子項(xiàng)目，即每個模塊記作一個配置項(xiàng)。代碼在提交項(xiàng)目組系統(tǒng)測試時建立Beta版本，系統(tǒng)測試產(chǎn)品正式發(fā)布后建立Version版本。6) 測試：單元測試和系統(tǒng)測試。單元測試通過提交單元測試報告，項(xiàng)目啟動后應(yīng)提交系統(tǒng)測試計劃，系統(tǒng)測試完成后應(yīng)提交系統(tǒng)測試報告。配置時應(yīng)說明測試的版本與編碼版本的對應(yīng)關(guān)系。系統(tǒng)測試完成后建立測試基線。7) 版本發(fā)布：項(xiàng)目組提交部署表單，CMO根據(jù)部署表單進(jìn)行編譯，發(fā)布測試服務(wù)器上，并對版本進(jìn)

10、行維護(hù)。同時將發(fā)布的版本上傳到文檔服務(wù)器上備份。8) 交付與驗(yàn)收：在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關(guān)文檔配置項(xiàng)，包括交付文檔、代碼、工具等。9) 產(chǎn)品部署：部署時應(yīng)包括操作手冊、安裝維護(hù)手冊、維護(hù)文檔以及必要的業(yè)務(wù)和技術(shù)培訓(xùn)文檔。10) 相關(guān)資料：相關(guān)資料也應(yīng)作為配置項(xiàng)納入配置管理，此部分包括：11) 相關(guān)法律、法規(guī)；必須遵照或項(xiàng)目組約定的技術(shù)規(guī)范；12) 與客戶或項(xiàng)目組內(nèi)部重要的交互信息記錄，如會議記錄、會談記錄、e-mail和MSN記錄等；2.2 版本控制2.2.1 文檔的版本控制所有文檔的管理納入配置管理庫，用版本控制工具進(jìn)行統(tǒng)一管理。文檔的版本控制主要通過文檔

11、的名稱、文檔控制頁及版本控制工具的標(biāo)簽來實(shí)現(xiàn)，主要分為以下幾類：2.2.1.1 版本變化型文檔命名方式：文檔名稱+子系統(tǒng)名稱（可選）適用文檔：項(xiàng)目計劃、配置管理計劃、質(zhì)量保證計劃、項(xiàng)目進(jìn)度計劃、用戶需求規(guī)格說明書、產(chǎn)品需求規(guī)格說明書、體系結(jié)構(gòu)設(shè)計報告、數(shù)據(jù)庫設(shè)計報告、詳細(xì)設(shè)計報告、用戶操作維護(hù)手冊、測試用例等。標(biāo)簽結(jié)構(gòu)：大版本 + 子系統(tǒng)簡稱 + 版本號 + 日期 （標(biāo)簽控制說明版本信息）l 大版本： 可選 ，表示同一項(xiàng)目為不同用戶定制的版本。l 子系統(tǒng)簡稱： 可選，當(dāng)一個項(xiàng)目有多個子系統(tǒng)時，為區(qū)分不同子系統(tǒng)而設(shè)置。l 版本號：采用Vs_x_y的形式。l 日期：納入基線管理的日期，用8位表示，

12、如20071031說明：a. 文檔發(fā)布名稱采用文檔名+ Vs_x_y的形式，文檔的版本號應(yīng)該和版本控制工具中相應(yīng)標(biāo)簽上的版本號一致。b. 對文檔的修改需要從配置管理庫中取到本地進(jìn)行。c. 對于文檔小的修改，如文字錯誤，格式調(diào)整，變更Vs_x_y中的y來區(qū)別（如：V1_0_1）。d. 文檔內(nèi)容沒有大的增加和刪節(jié)，意思表述沒有發(fā)生重大的變化，版本標(biāo)識通過版本工具中加上x標(biāo)簽來表示（如：V1_1_0），以及在文檔內(nèi)部控制頁標(biāo)注變化來表示。e. 文檔有重大增加和刪節(jié)，意思表述有重大變化的，版本標(biāo)識通過在相應(yīng)文檔加上s標(biāo)簽來表示（如：V2_0_0）。f. 對于納入基線庫的文檔的修改需要提交變更申請，經(jīng)批

13、準(zhǔn)才能進(jìn)行修改，并且修改的內(nèi)容要經(jīng)再次評審才能重新納入基線庫，作為后續(xù)階段的參考文檔。2.2.1.2 時間區(qū)別型文檔命名方式：文檔名稱撰寫時間適用文檔：文檔名稱有明確的含義，需要用時間標(biāo)識的日常性文檔。如周例會會議紀(jì)要，項(xiàng)目月計劃，項(xiàng)目月總結(jié),階段性計劃等等。2.2.1.3 時間序號型文檔命名方式：文檔名稱+人員姓名（拼音）+撰寫時間+序列號適用文檔：測試報告2.2.1.4 其他文檔：對于不能按照前四種類型進(jìn)行命名的文檔會議紀(jì)要：會議紀(jì)要YYYYMMDD ( )示 例：9月9日召開的項(xiàng)目啟動會命名為：會議紀(jì)要20030909(項(xiàng)目啟動).doc評審報告：評審報告YYYYMMDD ( )同”會議

14、紀(jì)要”要求一致。示 例：10月9日召開的項(xiàng)目總體方案評審命名為：評審報告20030910(總體方案).doc2.2.2 發(fā)行版本表示發(fā)行版本采用標(biāo)簽說明，結(jié)構(gòu)如下：大版本 + 版本類型 + 版本號 + 子系統(tǒng)簡稱(拼音)+日期 +序號大版本： 可選 ，表示同一項(xiàng)目為不同用戶定制的版本。子系統(tǒng)簡稱： 可選，當(dāng)一個項(xiàng)目有多個子系統(tǒng)時，為區(qū)分不同子系統(tǒng)而設(shè)置。版本類型：分為3種Beta表示項(xiàng)目組內(nèi)部測試，標(biāo)簽：B1_0_0-20071015-01Release系統(tǒng)測試，標(biāo)簽：Release1_0_0-SPmenhu-20071112-01Version正式發(fā)行版，標(biāo)簽：Version1_0_0-SP

15、menhu-20071112-01版本號 對于Version正式發(fā)行版 是必須要注明的，而其它可選。發(fā)行產(chǎn)品基線在版本號前加Version，如 Version_1, Version_2, Version_3.表示分支；Version_1_0, Version_1_1, Version_1_2 表示在分支Version_1上的標(biāo)簽；Version_0_0, Version_0_1, Version_0_2 表示在主線上的標(biāo)簽。2.3 配置庫管理2.3.1 配置庫的分類配置庫統(tǒng)一由配置管理員負(fù)責(zé)管理，服務(wù)器端使用cvsnt2.0.4，客戶端主要使用烏龜CVS。配置庫目錄結(jié)構(gòu)如下：2.3.2 配置庫

16、的建立所有項(xiàng)目應(yīng)建立配置庫，以便管理各配置項(xiàng)，配置管理員組織建立配置庫。程序庫主要通過設(shè)置版本的分支來實(shí)現(xiàn)對配置項(xiàng)權(quán)限管理： 1)開發(fā)庫：開發(fā)人員相對比較自由的存儲空間，開發(fā)人員可以在自己的權(quán)限范圍內(nèi)任意取出提交。2)基線庫：配置管理員有最高權(quán)限，其余相關(guān)人員均為讀的權(quán)限，發(fā)生變更時變更人員須提交變更申請后方可修改基線庫內(nèi)的配置項(xiàng)。 文檔評審?fù)ㄟ^后，文檔嚴(yán)格受控。由配置管理員將通過評審后的文檔移植到基線庫里同時將該配置項(xiàng)從開發(fā)庫移除。代碼一般在移交系統(tǒng)測試時納入基線庫受控，可根據(jù)項(xiàng)目的具體情況設(shè)置基線。3)產(chǎn)品庫：產(chǎn)品庫的產(chǎn)品均出自于基線庫，產(chǎn)品庫存儲的產(chǎn)品用于交付和存檔。配置三庫統(tǒng)一由配置管

17、理員管理，根據(jù)各開發(fā)階段的實(shí)際情況定制相應(yīng)的版本選取規(guī)則，來保證開發(fā)活動的正常運(yùn)作。在變更發(fā)生時，應(yīng)及時做好基線的推進(jìn)。分配權(quán)限項(xiàng)目開始后配置管理員編寫配置庫目錄結(jié)構(gòu)表明確項(xiàng)目組成員以及相關(guān)人員的權(quán)限。在wincvs里有三種權(quán)限，讀（r）、寫（w）、添加刪除（c）權(quán)限。在開發(fā)庫內(nèi)，文檔部分項(xiàng)目組成員有rcw權(quán)限，其他相關(guān)人員只r權(quán)限；代碼部分項(xiàng)目組成員有rcw權(quán)限，其他相關(guān)人員沒有任何權(quán)限。在基線庫內(nèi)，項(xiàng)目組成員僅有r權(quán)限，其他相關(guān)人的權(quán)限視情況而定。在產(chǎn)品庫內(nèi)，所有人沒有任何權(quán)限。配置管理員在三庫內(nèi)均擁有最高權(quán)限。2.4 配置變更控制變更的分類軟件及其相關(guān)文檔的變更按照變更的影響范圍進(jìn)行分類

18、：A級： 變更會影響系統(tǒng)級的需求、外部接口、產(chǎn)品價格或者交付期；這類變更必須經(jīng)過配置管理委員會審核并有客戶批準(zhǔn)和確認(rèn)。B級：變更會影響配置項(xiàng)間的功能接口、內(nèi)部功能的設(shè)計、組件；這類變更必須由項(xiàng)目經(jīng)理或配置管理委員會的批準(zhǔn)和認(rèn)可。1) C級：變更只會影響配置項(xiàng)內(nèi)部或?qū)UG問題的處理；這類變更可以由配置項(xiàng)的管理人員負(fù)責(zé)批準(zhǔn)。2.4.2 變更請求的提出a 由技術(shù)支撐中心匯集顧客意見，影響到需求變更則填寫配置項(xiàng)變更控制報告，并提交給配置管理員。b 配置管理員對申請表是否清晰、明確和完整性進(jìn)行審查，若發(fā)現(xiàn)變更不明確或不完整，應(yīng)返回申請者。對通過審查的變更申請分配變更ID，以便跟蹤和記錄變更信息。2.4

19、.3 評估變更a 配置管理員將配置項(xiàng)變更控制報告發(fā)送給項(xiàng)目經(jīng)理（或者其他授權(quán)人員），由項(xiàng)目經(jīng)理負(fù)責(zé)對變更進(jìn)行評估。b 項(xiàng)目經(jīng)理對變更進(jìn)行分解，一般的BUG修正不需要審批直接由項(xiàng)目經(jīng)理決定是否需要變更。新增功能或?qū)φ麄€項(xiàng)目影響重大的變更必須由研發(fā)總助審批通過后方可變更。變更評估文檔在完成變更評估后發(fā)送給配置管理員。2.4.4 變更實(shí)施和確認(rèn)a 變更被批準(zhǔn)后，項(xiàng)目經(jīng)理提交變更實(shí)施進(jìn)度計劃，開發(fā)人員開始實(shí)施變更，并詳細(xì)記錄變更的內(nèi)容；質(zhì)量部對變更的實(shí)施進(jìn)行跟蹤。b 對于代碼變更，必須進(jìn)行回歸測試，以確保變更沒有引入新的Bug。另外與變更相關(guān)的文檔必須修訂，以反映變更。當(dāng)變更以及測試完成后，進(jìn)行提交。c 通過測試后，質(zhì)保人員需對變更進(jìn)行審核，審核的范圍一般涉及以下方面：測試記錄；變更請求；配置項(xiàng)的檢入及檢出；文件的命名；版本的編號。a 審核后，由配置管理員更新到基線庫中。2.5 配置狀態(tài)報告目的記錄和報告整個軟件生命周期演化狀態(tài)。記錄內(nèi)容配置狀態(tài)報