配置管理規(guī)范
配置管理規(guī)范 |文件編號： |生效日期： |受控編號： | |NW601103 |2000.3.20 | | |密級：秘密 |版次：Ver1.0 |修改狀態(tài)： | |總頁數(shù) |7 |正文 |7 |附錄 |0 | |編制：馬云生 |審核：王宇 |批準(zhǔn)：孟莉 | 沈陽東大阿爾派軟件股份有限公司 （版權(quán)所有，翻版必究） 文件修改控制 |修改記錄編號 |修改 |修改頁碼及條款 |修改人|審核人|批準(zhǔn)人|修改日期 | | |狀態(tài) | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 目錄 1. 目的 2. 適用范圍 3. 術(shù)語和縮略語 4. 規(guī)范內(nèi)容 5. 引用文件 目的 指導(dǎo)配置管理人員如何建立配置庫，并利用配置庫管理所有配置項，從而提供配置項 的存取和檢索功能，有利于配置項的更改控制，保證配置項的完整性和可跟蹤性。 適用范圍 適用于所有軟件產(chǎn)品和軟件項目的配置項管理。配置管理可采用各種工具及手工辦法 ，本文件以Source safe配置管理工具為例，規(guī)定公司的配置管理辦法，使用其他工具時也可對應(yīng)本文件 的要求參照執(zhí)行。 術(shù)語和縮略語 本文件采用NP601100《配置管理》程序使用的術(shù)語和縮略語的定義。 規(guī)范內(nèi)容 4.1 配置管理的范圍 軟件配置可包括以下幾方面：項目文檔，源代碼，執(zhí)行程序，相關(guān)設(shè)備及資料 等。 1. 項目文檔主要指：立項建議報告、項目啟動計劃、可行性分析報告、開發(fā)計 劃、需求分析報告、軟件功能規(guī)格說明書、系統(tǒng)設(shè)計報告、數(shù)據(jù)庫表結(jié)構(gòu) 、技術(shù)報告、總結(jié)報告、驗收報告以及上述文檔的評審記錄。 2. 相關(guān)設(shè)備主要指項目開發(fā)和運行環(huán)境（包括硬件和軟件），以及項目開發(fā)和 測試過程中使用的專用儀器設(shè)備，如讀卡機、掃描儀等。 3. 相關(guān)資料主要指客戶提供的行業(yè)法規(guī)，標(biāo)準(zhǔn)及其調(diào)研期間提供的業(yè)務(wù)單據(jù)， 往來會議記要，傳真，電子郵件，重要的電話記錄等。 4.2 各配置項的獲得 項目立項之后，軟件配置管理負(fù)責(zé)人SCML即可建立項目配置庫，并著手收集各 配置項。 1. 項目文檔。開發(fā)各階段結(jié)束時，軟件配置管理負(fù)責(zé)人SCML可向開發(fā)人員索要 相關(guān)文檔及對應(yīng)評審記錄，歸到配置庫。 2. 開發(fā)人員在出差前應(yīng)帶好與客戶會談的準(zhǔn)備材料。根據(jù)出差的任務(wù)不同，還 應(yīng)準(zhǔn)備客滿意度調(diào)查表，交付書，驗收報告等。返回之前應(yīng)和客戶確認(rèn)， 并在出差回來時交給軟件配置管理負(fù)責(zé)人SCML一份備份，如有客戶提供的 文獻資料、有關(guān)設(shè)備儀器須進行登記。對于任何正在進行的項目，如有客 戶來訪須做好會議紀(jì)要。 3. 開發(fā)部門發(fā)給客戶的傳真件或客戶發(fā)來傳真至少應(yīng)在項目檔案中保存一份備 份。 4. 對于源代碼和執(zhí)行程序的管理最好使用工具，條件不具備時，要注意對配置 庫的目錄分配。各開發(fā)人員分別建立自己的工作目錄，完成后的模塊再放 到項目相關(guān)目錄下。 5. 在項目結(jié)束歸檔時電子郵件也應(yīng)作為項目的相關(guān)資料進行歸檔。 4.3 配置庫的建立 所有項目應(yīng)建立一配置庫，以便管理前面提到的各配置項。一般的可視化開發(fā) 環(huán)境都有自帶的配置管理工具，可以用管理工具來建立配置庫，也可以在機器 的某目錄下建立配置庫，手工管理。下面以Source Safe為例描述配置管理庫的建立及各配置項的控制方法。各項目在開始時，均 應(yīng)建立以下幾項子項目，進行分階段管理。 4.3.1 項目啟動 配置項包括立項建議報告及其評審結(jié)果、合同草案及評審結(jié)果、合作協(xié)議、項 目任務(wù)書等。項目立項通過后應(yīng)封鎖該子項目，如后期須增加或修改應(yīng)征得軟 件配置管理負(fù)責(zé)人SCML的認(rèn)可，并作好標(biāo)記。項目啟動計劃部門內(nèi)部評審?fù)ㄟ^ 后，版本為0.7版，當(dāng)啟動計劃生效執(zhí)行后，版本升為1.0。 4.3.2 需求分析 針對合同項目，按系統(tǒng)所處理的業(yè)務(wù)不同，需求分析可分為客戶業(yè)務(wù)描述、業(yè) 務(wù)流程圖、系統(tǒng)功能點提取、系統(tǒng)數(shù)據(jù)流圖等子項目。系統(tǒng)調(diào)研后開發(fā)人員進 行系統(tǒng)分析，并整理需求分析報告。需求分析報告通過部門內(nèi)部評審時，版本 定為0.7，取得客戶的確定后為1.0版本。在需求分析報告取得客戶的確認(rèn)后， 封鎖該子項目，如后期需要修改，須征得管理員的認(rèn)可，并作好修改說明，如 需升版則必須通過部門評審并得到客戶的確認(rèn)，以1.0版本為基準(zhǔn)按0.1單位增 加版本。 4.3.3 軟件功能規(guī)格說明書 針對公司自立項目，在項目啟動階段需要編寫軟件功能規(guī)格說明書，通過內(nèi)部 評審后，版本定為0.7，公司評審?fù)ㄟ^后版本定為1.0，如無須公司評審，則由 0.7版自動升為1.0版，如后期需要修改，須征得軟件配置管理負(fù)責(zé)人SCML的認(rèn) 可，并作好修改說明，如需升版則必須通過部門評審，以1.0版本為基準(zhǔn)按0. 1單位增加版本。 4.3.4 開發(fā)計劃 需求分析或軟件功能規(guī)格說明書完成后即可制定項目的開發(fā)計劃，包括項目總 體進度說明，及進度跟蹤，計劃修改，配置管理計劃等。開發(fā)計劃的修改按項 目文檔來處理。進度跟蹤一般使用Project管理編制，由于修改較頻繁，可只 對作為進度基準(zhǔn)的進度標(biāo)記修改說明。開發(fā)計劃通過部門內(nèi)部評審后版本為0 .7，批準(zhǔn)執(zhí)行后版本為1.0。 4.3.5 系統(tǒng)設(shè)計 系統(tǒng)設(shè)計可分為CDM、PDM和數(shù)據(jù)字典設(shè)計，功能模塊劃分及算法描述等部分。 針對需求分析報告或軟件功能規(guī)格說明書進行系統(tǒng)設(shè)計，系統(tǒng)設(shè)計報告部門評 審?fù)ㄟ^后的版本為0.7，系統(tǒng)測試修改完成后其版本升為1.0，配置時應(yīng)說明系 統(tǒng)設(shè)計的版本與需求分析或軟件功能規(guī)格說明書版本的對應(yīng)關(guān)系。 6. 編碼 編碼可分為前臺業(yè)務(wù)處理和后臺過程，也可按功能模塊或人員再分子項目。編 碼實現(xiàn)過程應(yīng)注意與客戶需求系統(tǒng)設(shè)計相一致，否則須修改設(shè)計報告。在配置 管理活動中工程項目的源程序代碼版本控制一般指內(nèi)部版本，新項目的系統(tǒng)測 試結(jié)束后其版本為0.7，試運行階段驗收通過后版本為1.0，并以此版本為基準(zhǔn) 將來每次升級時，以0.1為單位增加。產(chǎn)品項目的源代碼版本控制也可參照執(zhí) 行。 4.3.7 測試 功能測試階段應(yīng)提供測試問題卡與測試總結(jié)；系統(tǒng)測試階段應(yīng)提供測試大綱、 測試用例、測試所發(fā)現(xiàn)的問題和修改說明，及測試總結(jié)報告等。 4.3.8 驗收與項目總結(jié) 項目驗收最好能分為兩個階段，即安裝試運行驗收和項目最終驗收。除驗收報 告外，驗收期間與客戶會談紀(jì)要也應(yīng)作為驗收材料之一。項目總結(jié)由項目組成 員共同編制，并應(yīng)經(jīng)過部門內(nèi)部評審。 4.3.9 相關(guān)資料與培訓(xùn) 此部分包括相關(guān)法律、法規(guī)，必須遵照或項目組約定的技術(shù)規(guī)范，必要的業(yè)務(wù) 或技術(shù)培訓(xùn)等。 4.3.10 分承包商（可選） 如果項目需要分包，須要提供分包方的背景說明，分包協(xié)議要求，以及分包括 商合格評定材料等。 4.3.11 日常事務(wù) 與項目相關(guān)的日常事務(wù)，如項目組內(nèi)的規(guī)定，項目周報、日報、人員的增減、 出差事務(wù)等。 [pic] 引用文件 （無） ----------------------- [pic]
配置管理規(guī)范