軟件配置管理規(guī)范

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

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

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

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

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

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

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

8、審通過后納入受控庫，作為該項目的一個基線。1) 項目啟動：配置項包括技術建議書、可行性分析報告、用戶需求說明書等立項階段產生的文檔，評審或審批通過后建立發(fā)布基線。2) 需求階段：系統(tǒng)調研后開發(fā)人員進行需求分析，并整理產品需求規(guī)格說明書。產品需求規(guī)格說明書經過客戶的確認后，建立需求基線。如需升級版本則必須通過評審或審批并得到客戶的確認。3) 項目計劃：需求分析完成后即可制定項目的開發(fā)計劃，包括項目計劃和主要下屬計劃。包括項目進度計劃、配置管理計劃、質量保證計劃、測試計劃、項目階段性計劃。項目開發(fā)計劃評審通過后，建立項目計劃基線。4) 設計：系統(tǒng)設計可分為概要設計、詳細設計、數據庫設計、數據庫字典

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

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

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

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

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

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

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

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

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

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

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