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