MILY: 黑體; mso-bidi-font-size: 10.0pt; mso-ascii-font-family: 'Times New Roman'">目錄

1.    目的

2.    適用范圍

3.    術語和縮略語

4.    規范內容

5.    引用文件

1.        目的

指導配置管理人員如何建立配置庫，并利用配置庫管理所有配置項，從而提供配置項的存取和檢索功能，有利于配置項的更改控制，保證配置項的完整性和可跟蹤性。

2.        適用范圍

適用于所有軟件產品和軟件項目的配置項管理。配置管理可采用各種工具及手工辦法，本文件以Source safe配置管理工具為例，規定公司的配置管理辦法，使用其他工具時也可對應本文件的要求參照執行。

3.        術語和縮略語

本文件采用NP601100《配置管理》程序使用的術語和縮略語的定義。

4.        規范內容

4.1         配置管理的范圍

軟件配置可包括以下幾方面：項目文檔，源代碼，執行程序，相關設備及資料等。

1）  項目文檔主要指：立項建議報告、項目啟動計劃、可行性分析報告、開發計劃、需求分析報告、軟件功能規格說明書、系統設計報告、數據庫表結構、技術報告、總結報告、驗收報告以及上述文檔的評審記錄。

2）  相關設備主要指項目開發和運行環境（包括硬件和軟件），以及項目開發和測試過程中使用的專用儀器設備，如讀卡機、掃描儀等。

3）  相關資料主要指客戶提供的行業法規，標準及其調研期間提供的業務單據，往來會議記要，傳真，電子郵件，重要的電話記錄等。

4.2         各配置項的獲得

項目立項之后，軟件配置管理負責人SCML即可建立項目配置庫，并著手收集各配置項。

1）  項目文檔。開發各階段結束時，軟件配置管理負責人SCML可向開發人員索要相關文檔及對應評審記錄，歸到配置庫。

2）  開發人員在出差前應帶好與客戶會談的準備材料。根據出差的任務不同，還應準備客滿意度調查表，交付書，驗收報告等。返回之前應和客戶確認，并在出差回來時交給軟件配置管理負責人SCML一份備份，如有客戶提供的文獻資料、有關設備儀器須進行登記。對于任何正在進行的項目，如有客戶來訪須做好會議紀要。

3）  開發部門發給客戶的傳真件或客戶發來傳真至少應在項目檔案中保存一份備份。

4）  對于源代碼和執行程序的管理最好使用工具，條件不具備時，要注意對配置庫的目錄分配。各開發人員分別建立自己的工作目錄，完成后的模塊再放到項目相關目錄下。

5）  在項目結束歸檔時電子郵件也應作為項目的相關資料進行歸檔。

4.3         配置庫的建立

所有項目應建立一配置庫，以便管理前面提到的各配置項。一般的可視化開發環境都有自帶的配置管理工具，可以用管理工具來建立配置庫，也可以在機器的某目錄下建立配置庫，手工管理。下面以Source Safe為例描述配置管理庫的建立及各配置項的控制方法。各項目在開始時，均應建立以下幾項子項目，進行分階段管理。

       4.3.1      項目啟動

配置項包括立項建議報告及其評審結果、合同草案及評審結果、合作協議、項目任務書等。項目立項通過后應封鎖該子項目，如后期須增加或修改應征得軟件配置管理負責人SCML的認可，并作好標記。項目啟動計劃部門內部評審通過后，版本為0.7版，當啟動計劃生效執行后，版本升為1.0。

       4.3.2      需求分析

針對合同項目，按系統所處理的業務不同，需求分析可分為客戶業務描述、業務流程圖、系統功能點提取、系統數據流圖等子項目。系統調研后開發人員進行系統分析，并整理需求分析報告。需求分析報告通過部門內部評審時，版本定為0.7，取得客戶的確定后為1.0版本。在需求分析報告取得客戶的確認后，封鎖該子項目，如后期需要修改，須征得管理員的認可，并作好修改說明，如需升版則必須通過部門評審并得到客戶的確認，以1.0版本為基準按0.1單位增加版本。

       4.3.3      軟件功能規格說明書

針對公司自立項目，在項目啟動階段需要編寫軟件功能規格說明書，通過內部評審后，版本定為0.7，公司評審通過后版本定為1.0，如無須公司評審，則由0.7版自動升為1.0版，如后期需要修改，須征得軟件配置管理負責人SCML的認可，并作好修改說明，如需升版則必須通過部門評審，以1.0版本為基準按0.1單位增加版本。

       4.3.4      開發計劃

需求分析或軟件功能規格說明書完成后即可制定項目的開發計劃，包括項目總體進度說明，及進度跟蹤，計劃修改，配置管理計劃等。開發計劃的修改按項目文檔來處理。進度跟蹤一般使用Project管理編制，由于修改較頻繁，可只對作為進度基準的進度標記修改說明。開發計劃通過部門內部評審后版本為0.7，批準執行后版本為1.0。

       4.3.5      系統設計

系統設計可分為CDM、PDM和數據字典設計，功能模塊劃分及算法描述等部分。針對需求分析報告或軟件功能規格說明書進行系統設計，系統設計報告部門評審通過后的版本為0.7，系統測試修改完成后其版本升為1.0，配置時應說明系統設計的版本與需求分析或軟件功能規格說明書版本的對應關系。

4.3.6            編碼

編碼可分為前臺業務處理和后臺過程，也可按功能模塊或人員再分子項目。編碼實現過程應注意與客戶需求系統設計相一致，否則須修改設計報告。在配置管理活動中工程項目的源程序代碼版本控制一般指內部版本，新項目的系統測試結束后其版本為0.7，試運行階段驗收通過后版本為1.0，并以此版本為基準將來每次升級時，以0.1為單位增加。產品項目的源代碼版本控制也可參照執行。

       4.3.7      測試

功能測試階段應提供測試問題卡與測試總結；系統測試階段應提供測試大綱、測試用例、測試所發現的問題和修改說明，及測試總結報告等。

       4.3.8      驗收與項目總結

項目驗收最好能分為兩個階段，即安裝試運行驗收和項目最終驗收。除驗收報告外，驗收期間與客戶會談紀要也應作為驗收材料之一。項目總結由項目組成員共同編制，并應經過部門內部評審。

4.3.9      相關資料與培訓

此部分包括相關法律、法規，必須遵照或項目組約定的技術規范，必要的業務或技術培訓等。

       4.3.10    分承包商（可選）

如果項目需要分包，須要提供分包方的背景說明，分包協議要求，以及分包括商合格評定材料等。

       4.3.11    日常事務

與項目相關的日常事務，如項目組內的規定，項目周報、日報、人員的增減、出差事務等。

5.        引用文件

（無）

文章來源于領測軟件測試網 http://www.kjueaiud.com/