軟件配置管理流程

1、1        概述1.1      目的本文檔主要目的在于規(guī)范項(xiàng)目配置管理活動(dòng)，確保配置項(xiàng)正確地唯一標(biāo)識并且易于存取，保證基線配置項(xiàng)的更改受控，明確基線狀態(tài)，在整個(gè)軟件生命周期中建立和維護(hù)項(xiàng)目產(chǎn)品的完整性和可追溯性。1.2      適用范圍本文檔適用于不同類別的軟件產(chǎn)品和軟件項(xiàng)目開發(fā)工程的配置管理活動(dòng)，針對項(xiàng)目不同在流程上作適當(dāng)?shù)膭h減。配置管理可采用各種工具及手工辦法，本文件以CVS（并行版本系統(tǒng)）配置管理工具

2、為例，規(guī)定公司的配置管理辦法，使用其他工具時(shí)也可對應(yīng)本文件的要求參照執(zhí)行。1.3      術(shù)語和縮略語1.3.1    軟件配置管理（Software Configuration Management，SCM）軟件配置管理是對軟件修改進(jìn)行標(biāo)識、組織和控制的技術(shù)，用來協(xié)調(diào)和控制整個(gè)過程。是通過技術(shù)或行政手段對軟件產(chǎn)品及其開發(fā)過程和生命周期進(jìn)行控制、規(guī)范的一系列措施。配置管理的目標(biāo)是記錄軟件產(chǎn)品的演化過程，確保軟件開發(fā)者在軟件生命周期中各個(gè)階段都能得到精確的不同版本的產(chǎn)品配置。1.3.2  

3、60; 配置項(xiàng)（Configuration Item，CI）凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項(xiàng)，配置項(xiàng)邏輯上組成軟件系統(tǒng)的各組成部分，一般是可以單獨(dú)進(jìn)行設(shè)計(jì)、實(shí)施和測試的。每個(gè)配置項(xiàng)的主要屬性有：名稱、標(biāo)簽、文件狀態(tài)、版本、作者、日期等。所有配置項(xiàng)都被保存在配置庫里，確保不會(huì)混淆、丟失。配置項(xiàng)及其歷史記錄反映了軟件的演化過程。1.3.3    基線（Baseline）在配置管理系統(tǒng)中，基線就是一個(gè)配置項(xiàng)或一組配置項(xiàng)在其生命周期的不同時(shí)間點(diǎn)上通過正式評審而進(jìn)入正式受控的一種狀態(tài)，這些配置項(xiàng)構(gòu)成了一個(gè)相對穩(wěn)定的邏輯實(shí)體，而這個(gè)過程被稱為“基線化”。每一個(gè)基線都

4、是其下一步開發(fā)的出發(fā)點(diǎn)和參考點(diǎn)?；€確定了元素（配置項(xiàng)）的一個(gè)版本，且只確定一個(gè)版本。一般情況下，基線一般在指定的里程碑處創(chuàng)建，并與項(xiàng)目中的里程碑保持同步。每個(gè)基線都將接受配置管理的嚴(yán)格控制，基線中的配置項(xiàng)被“凍結(jié)”了，不能再被任何人隨意修改，對其修改要嚴(yán)格地按照變更控制的過程進(jìn)行。在一個(gè)軟件開發(fā)階段結(jié)束時(shí)，上一個(gè)基線加上增加和修改的基線內(nèi)容形成下一個(gè)基線?；€的主要屬性有：名稱、標(biāo)簽、版本、日期等。1.4      權(quán)限與職責(zé)1.4.1    研發(fā)總經(jīng)理助理1）  審核變更請求。1.4.2 &

5、#160;  項(xiàng)目經(jīng)理（Project Manager，PM）1)     審核批準(zhǔn)配置管理計(jì)劃；2)     接收或拒絕小范圍的變更申請；3)     召集評估變更；4)     提出配置管理的建議和要求；5)     配合配置管理員的工作。1.4.3    配置管理員（Configuration Management Officer，CMO）1)

6、0;    編寫配置管理計(jì)劃；2)     執(zhí)行版本控制和變更控制方案；3)     制定訪問控制策略；4)     負(fù)責(zé)項(xiàng)目的配置管理工作，包括搭建環(huán)境、權(quán)限分配、配置庫的建立、配置項(xiàng)的控制等；5)     配置管理工具的日常管理與維護(hù)；6)     配置庫的日常操作和維護(hù)；7)     負(fù)責(zé)配置審核并提交報(bào)告；8) 

7、;    根據(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ù)確定的配置管理計(jì)劃和相關(guān)規(guī)定，提交配置項(xiàng)和基線；2)     負(fù)責(zé)項(xiàng)目組內(nèi)部測試；3)   &#

8、160; 負(fù)責(zé)軟件集成和版本生成；4)     按照軟件配置管理工具的使用模型來完成開發(fā)任務(wù)。2         實(shí)施細(xì)則2.1      配置項(xiàng)管理2.1.1    配置項(xiàng)的范圍軟件配置可包括以下幾方面：開發(fā)文檔，代碼，第三方控件、插件，參考資料，測試文檔，用戶文檔，項(xiàng)目管理文檔，驗(yàn)收文檔等。l         項(xiàng)目

9、文檔主要指：立項(xiàng)建議書、可行性分析報(bào)告、技術(shù)建議書、用戶需求說明書、項(xiàng)目計(jì)劃、項(xiàng)目進(jìn)度計(jì)劃、項(xiàng)目階段性計(jì)劃、產(chǎn)品需求規(guī)格說明書、概要設(shè)計(jì)報(bào)告、詳細(xì)設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、界面設(shè)計(jì)、用戶操作手冊、用戶安裝手冊、培訓(xùn)文檔、驗(yàn)收報(bào)告以及上述文檔的評審記錄。l         代碼主要指：源代碼等。l         工具主要指：腳本文件、插件、第三方控件等。2.1.2    配置項(xiàng)基線管理結(jié)合SPP和ISO9000的相

10、關(guān)規(guī)定，配置管理員根據(jù)配置管理規(guī)范及配置管理計(jì)劃，對配置項(xiàng)進(jìn)行分階段管理，每一階段正式評審?fù)ㄟ^后納入受控庫，作為該項(xiàng)目的一個(gè)基線。l         項(xiàng)目啟動(dòng)：配置項(xiàng)包括技術(shù)建議書、可行性分析報(bào)告、用戶需求說明書等立項(xiàng)階段產(chǎn)生的文檔，評審或?qū)徟ㄟ^后建立發(fā)布基線。l         需求階段：系統(tǒng)調(diào)研后開發(fā)人員進(jìn)行需求分析，并整理產(chǎn)品需求規(guī)格說明書。產(chǎn)品需求規(guī)格說明書經(jīng)過客戶的確認(rèn)后，建立需求基線。如需升級版本則必須通過評審或?qū)徟⒌玫?/p>

11、客戶的確認(rèn)。l         項(xiàng)目計(jì)劃：需求分析完成后即可制定項(xiàng)目的開發(fā)計(jì)劃，包括項(xiàng)目計(jì)劃和主要下屬計(jì)劃。包括項(xiàng)目進(jìn)度計(jì)劃、配置管理計(jì)劃、質(zhì)量保證計(jì)劃、測試計(jì)劃、項(xiàng)目階段性計(jì)劃。項(xiàng)目開發(fā)計(jì)劃評審?fù)ㄟ^后，建立項(xiàng)目計(jì)劃基線。l         設(shè)計(jì)：系統(tǒng)設(shè)計(jì)可分為概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、數(shù)據(jù)庫字典、界面設(shè)計(jì)。針對用戶需求規(guī)格說明書進(jìn)行系統(tǒng)設(shè)計(jì)，配置時(shí)應(yīng)說明系統(tǒng)設(shè)計(jì)的版本與需求分析報(bào)告版本的對應(yīng)關(guān)系。設(shè)計(jì)說明書評審或?qū)徟ㄟ^后，建立

12、設(shè)計(jì)基線。l         編碼（設(shè)計(jì)實(shí)現(xiàn)）：編碼按功能模塊分子項(xiàng)目，即每個(gè)模塊記作一個(gè)配置項(xiàng)。代碼在提交項(xiàng)目組系統(tǒng)測試時(shí)建立Beta版本，系統(tǒng)測試產(chǎn)品正式發(fā)布后建立Version版本。l         測試：單元測試和系統(tǒng)測試。單元測試通過提交單元測試報(bào)告，項(xiàng)目啟動(dòng)后應(yīng)提交系統(tǒng)測試計(jì)劃，系統(tǒng)測試完成后應(yīng)提交系統(tǒng)測試報(bào)告。配置時(shí)應(yīng)說明測試的版本與編碼版本的對應(yīng)關(guān)系。系統(tǒng)測試完成后建立測試基線。l   &

13、#160;     版本發(fā)布：項(xiàng)目組提交部署表單，CMO根據(jù)部署表單進(jìn)行編譯，發(fā)布測試服務(wù)器上，并對版本進(jìn)行維護(hù)。同時(shí)將發(fā)布的版本上傳到文檔服務(wù)器上備份。l         交付與驗(yàn)收：在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關(guān)文檔配置項(xiàng)，包括交付文檔、代碼、工具等。l         產(chǎn)品部署：部署時(shí)應(yīng)包括操作手冊、安裝維護(hù)手冊、維護(hù)文檔以及必要的業(yè)務(wù)和技術(shù)培訓(xùn)文檔。l

14、0;        相關(guān)資料：相關(guān)資料也應(yīng)作為配置項(xiàng)納入配置管理，此部分包括：1) 相關(guān)法律、法規(guī)；必須遵照或項(xiàng)目組約定的技術(shù)規(guī)范；2) 與客戶或項(xiàng)目組內(nèi)部重要的交互信息記錄，如會(huì)議記錄、會(huì)談?dòng)涗?、e-mail和MSN記錄等；2.2      版本控制2.2.1    文檔的版本控制所有文檔的管理納入配置管理庫，用版本控制工具進(jìn)行統(tǒng)一管理。文檔的版本控制主要通過文檔的名稱、文檔控制頁及版本控制工具的標(biāo)簽來實(shí)現(xiàn)，主要分為以下幾類：2.2.1.1&#

15、160;    版本變化型文檔命名方式：文檔名稱+子系統(tǒng)名稱（可選）適用文檔：項(xiàng)目計(jì)劃、配置管理計(jì)劃、質(zhì)量保證計(jì)劃、項(xiàng)目進(jìn)度計(jì)劃、用戶需求規(guī)格說明書、產(chǎn)品需求規(guī)格說明書、體系結(jié)構(gòu)設(shè)計(jì)報(bào)告、數(shù)據(jù)庫設(shè)計(jì)報(bào)告、詳細(xì)設(shè)計(jì)報(bào)告、用戶操作維護(hù)手冊、測試用例等。示例：項(xiàng)目計(jì)劃.doc      詳細(xì)設(shè)計(jì)_SP門戶.doc標(biāo)簽結(jié)構(gòu)：大版本 + 子系統(tǒng)簡稱 + 版本號 + 日期 （標(biāo)簽控制說明版本信息）l         大版本： 可選 ，表示同一項(xiàng)目為

16、不同用戶定制的版本。l         子系統(tǒng)簡稱： 可選，當(dāng)一個(gè)項(xiàng)目有多個(gè)子系統(tǒng)時(shí)，為區(qū)分不同子系統(tǒng)而設(shè)置。l         版本號：采用Vs_x_y的形式。l         日期：納入基線管理的日期，用8位表示，如20071031說明：a.     文檔發(fā)布名稱采用文檔名+ Vs_x_y的形式，文檔的版本號應(yīng)該

17、和版本控制工具中相應(yīng)標(biāo)簽上的版本號一致。b.     對文檔的修改需要從配置管理庫中取到本地進(jìn)行。c.     對于文檔小的修改，如文字錯(cuò)誤，格式調(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)識通過在

18、相應(yīng)文檔加上s標(biāo)簽來表示（如：V2_0_0）。f.     對于納入基線庫的文檔的修改需要提交變更申請，經(jīng)批準(zhǔn)才能進(jìn)行修改，并且修改的內(nèi)容要經(jīng)再次評審才能重新納入基線庫，作為后續(xù)階段的參考文檔。2.2.1.2     時(shí)間區(qū)別型文檔命名方式：文檔名稱撰寫時(shí)間適用文檔：文檔名稱有明確的含義，需要用時(shí)間標(biāo)識的日常性文檔。如周例會(huì)會(huì)議紀(jì)要，項(xiàng)目月計(jì)劃，項(xiàng)目月總結(jié),階段性計(jì)劃等等。示    例：周例會(huì)會(huì)議紀(jì)要20030901.doc2.2.1.3    

19、 時(shí)間序號型文檔命名方式：文檔名稱+人員姓名（拼音）+撰寫時(shí)間+序列號適用文檔：測試報(bào)告示例：單元測試報(bào)告_lixiaohong_20071112_01.dco2.2.1.4     其他文檔：對于不能按照前四種類型進(jìn)行命名的文檔會(huì)議紀(jì)要：會(huì)議紀(jì)要YYYYMMDD (    )示   例：9月9日召開的項(xiàng)目啟動(dòng)會(huì)命名為：會(huì)議紀(jì)要20030909(項(xiàng)目啟動(dòng)).doc評審報(bào)告：評審報(bào)告YYYYMMDD (    )同”會(huì)議紀(jì)要”要求一致。示   例：10月9日

20、召開的項(xiàng)目總體方案評審命名為：評審報(bào)告20030910(總體方案).doc2.2.2    發(fā)行版本表示發(fā)行版本采用標(biāo)簽說明，結(jié)構(gòu)如下：大版本 + 版本類型 + 版本號 + 子系統(tǒng)簡稱(拼音)+日期 +序號大版本： 可選 ，表示同一項(xiàng)目為不同用戶定制的版本。子系統(tǒng)簡稱： 可選，當(dāng)一個(gè)項(xiàng)目有多個(gè)子系統(tǒng)時(shí)，為區(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-S

21、Pmenhu-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    

22、0; 配置庫管理2.3.1    配置庫的分類配置庫統(tǒng)一由配置管理員負(fù)責(zé)管理，服務(wù)器端使用cvsnt2.0.4，客戶端主要使用烏龜CVS。配置庫目錄結(jié)構(gòu)如下：2.3.2    配置庫的建立所有項(xiàng)目應(yīng)建立配置庫，以便管理各配置項(xiàng)，配置管理員組織建立配置庫。程序庫主要通過設(shè)置版本的分支來實(shí)現(xiàn)對配置項(xiàng)權(quán)限管理： 1)開發(fā)庫：開發(fā)人員相對比較自由的存儲(chǔ)空間，開發(fā)人員可以在自己的權(quán)限范圍內(nèi)任意取出提交。2)基線庫：配置管理員有最高權(quán)限，其余相關(guān)人員均為讀的權(quán)限，發(fā)生變更時(shí)變更人員須提交變更申請后方可修改基線庫內(nèi)的配置項(xiàng)。Ø 

23、        文檔評審?fù)ㄟ^后，文檔嚴(yán)格受控。由配置管理員將通過評審后的文檔移植到基線庫里同時(shí)將該配置項(xiàng)從開發(fā)庫移除。Ø         代碼一般在移交系統(tǒng)測試時(shí)納入基線庫受控，可根據(jù)項(xiàng)目的具體情況設(shè)置基線。3)產(chǎn)品庫：產(chǎn)品庫的產(chǎn)品均出自于基線庫，產(chǎn)品庫存儲(chǔ)的產(chǎn)品用于交付和存檔。配置三庫統(tǒng)一由配置管理員管理，根據(jù)各開發(fā)階段的實(shí)際情況定制相應(yīng)的版本選取規(guī)則，來保證開發(fā)活動(dòng)的正常運(yùn)作。在變更發(fā)生時(shí)，應(yīng)及時(shí)做好基線的推進(jìn)。2.3.3 

24、;   分配權(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      配置變更控制2.4.1    變更的分類軟件及其相關(guān)文檔的變更按照變更的

25、影響范圍進(jìn)行分類：1)A級：變更會(huì)影響系統(tǒng)級的需求、外部接口、產(chǎn)品價(jià)格或者交付期；這類變更必須經(jīng)過配置管理委員會(huì)審核并有客戶批準(zhǔn)和確認(rèn)。2)B級：變更會(huì)影響配置項(xiàng)間的功能接口、內(nèi)部功能的設(shè)計(jì)、組件；這類變更必須由項(xiàng)目經(jīng)理或配置管理委員會(huì)的批準(zhǔn)和認(rèn)可。3) C級：變更只會(huì)影響配置項(xiàng)內(nèi)部或?qū)UG問題的處理；這類變更可以由配置項(xiàng)的管理人員負(fù)責(zé)批準(zhǔn)。Ø         系統(tǒng)測試前變更控制流程： Ø        

26、 系統(tǒng)測試完畢發(fā)布release版本后變更控制流程  圖2 變更控制流程2.4.2    變更請求的提出a  由技術(shù)支撐中心匯集顧客意見，影響到需求變更則填寫配置項(xiàng)變更控制報(bào)告，并提交給配置管理員。b  配置管理員對申請表是否清晰、明確和完整性進(jìn)行審查，若發(fā)現(xiàn)變更不明確或不完整，應(yīng)返回申請者。對通過審查的變更申請分配變更ID，以便跟蹤和記錄變更信息。2.4.3    評估變更a  配置管理員將配置項(xiàng)變更控制報(bào)告發(fā)送給項(xiàng)目經(jīng)理（或者其他授權(quán)人員），由項(xiàng)目經(jīng)理負(fù)責(zé)對變更進(jìn)行評估。b

27、0; 項(xiàng)目經(jīng)理對變更進(jìn)行分解，一般的BUG修正不需要審批直接由項(xiàng)目經(jīng)理決定是否需要變更。新增功能或?qū)φ麄€(gè)項(xiàng)目影響重大的變更必須由研發(fā)總助審批通過后方可變更。變更評估文檔在完成變更評估后發(fā)送給配置管理員。2.4.4    變更實(shí)施和確認(rèn)a  變更被批準(zhǔn)后，項(xiàng)目經(jīng)理提交變更實(shí)施進(jìn)度計(jì)劃，開發(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  審核后，由配置管理員更新到基線庫