配置管理計劃模板20120806

1、XXXX項目配置管理計劃 <項目名稱>項目配置管理計劃京東世紀貿(mào)易有限公司XXXX年XX月XX日 文檔編號： 版 本 號：產(chǎn)品名稱：XXXX項目文檔名稱：配置管理計劃版本號修改內(nèi)容描述修改人日期變更請求號批準人： 日期：審核人： 日期：目錄1引言41.1 目的41.2 術語定義41.3 參考資料52軟件配置52.1 軟件配置環(huán)境52.2 軟件配置項52.3 組織、職責和接口72.4 配置管理過程73軟件配置管理計劃83.1 建立示例配置庫83.2 配置標識管理93.3 配置庫控制93.4 配置的審查和評審113.5 配置庫的備份123.6 配置管理計劃的修訂123.7 配置管理計劃

2、附屬文檔124. 里程碑13附錄1 文檔命名規(guī)則14受配置庫文件命名規(guī)則14非受控配置庫文件命名規(guī)則14提交文檔文件命名規(guī)則14附錄2 賬號及權限管理15賬號管理15權限管理15附錄3 配置庫使用規(guī)定161引言1.1 目的 本文檔目的在于對XXXX項目進行軟件配置管理，提高軟件質量，降低軟件開發(fā)成本。本文檔內(nèi)容主要參考研發(fā)中心相關ISO程序和制度文檔，并在這基礎上整理成適合本項目的軟件配置管理，為項目經(jīng)理、配置管理員及相關人員提供日常的配置管理操作步驟。1.2 術語定義軟件配置管理：簡稱SCM（Software Configuration Management 的縮寫），是在項目開發(fā)中，標示、

3、控制和管理軟件變更的一種管理。配置管理的使用取決于項目規(guī)模和復雜性以及風險水平。軟件的規(guī)模越大，配置管理就顯得越重要?；€：（BaseLine）是項目存儲庫中每個工作版本在特定時期的一個“快照”。它提供一個正式標準，隨后的工作基于此標準，并且只有授權后才能變更這個標準。建立一個初始基線后，以后每次對其進行的變更都將記錄為一個差值，直到建成下一個基線。配置管理員：項目組中負責配置管理工作的角色。在某一開發(fā)階段通過評審或某一質量檢查點通過審核后，配置管理員負責統(tǒng)一添加或修改相關文檔的最新有效版本以及審批人簽字。SCCB：（Software Configuration Control Board ,

4、軟件配置控制委員會）一般由項目經(jīng)理、各功能組代表（包括產(chǎn)品組、系統(tǒng)分析組、設計組、開發(fā)組、測試組、SCM組）、中高層管理者代表等組成，也即SCCB可以由項目經(jīng)理、產(chǎn)品管理、程序管理、SCM人員、測試經(jīng)理、部門主管、總經(jīng)理室代表組成。組織也可以指派管理者或專家參與。SCCB組長由固定人員承擔，可以是項目經(jīng)理，也可以是組織指派的管理者或專家。）代表項目經(jīng)理和所有可能受到軟件基線的更改影響的組的利益；批準設置基線產(chǎn)品；審查并批準對基線產(chǎn)品的更改并確保批準的更改得到實施；批準軟件基線庫生成的產(chǎn)品庫。配置標識：（Configuration Identification,CI）對軟件項目在開發(fā)過程中的資源

5、進行標識，以便識別。配置項：（Configuration Items,CIs）軟件生存周期各個階段活動的產(chǎn)物經(jīng)審批后即可稱之為軟件配置項。 軟件配置項包括：與合同、過程、計劃和產(chǎn)品有關的文檔和資料；源代碼、目標代碼和可執(zhí)行代碼；相關產(chǎn)品，包括軟件工具、庫內(nèi)的可重用軟件、外購軟件及顧客提供的軟件等。配置檢查：（Configuration Audit）對軟件配置管理過程中的行動進行檢查。 1.3 參考資料 列出要用到的參考資料，如:a. 計劃任務書b. 本項目已發(fā)表的文件c. 需要引用的文件，資料，包括所用到的軟件開發(fā)標準2軟件配置2.1 軟件配置環(huán)境 2.1.1服務器軟件環(huán)境軟件名稱作用Cent

6、OS5操作系統(tǒng)Win2003操作系統(tǒng) 2.1.2硬件環(huán)境名稱規(guī)格說明網(wǎng)絡局域網(wǎng)服務器PC服務器客戶機普通PC機項目組成員各自的計算機 2.1.3配置管理工具 名稱說明hudson持續(xù)集成工具，測試構建工具subversion源代碼管理工具sharepoint文檔管理工具confluence文檔管理工具jira缺陷跟蹤管理工具 2.1.4配置管理客戶端 項目成員在各自的計算機安裝TortoiseSVN客戶端，項目組成員以分配的賬號登陸和訪問配置服務器，根據(jù)配置管理員設定的用戶權限進行配置管理活動。2.2 軟件配置項 在本項目的實施過程中，將配置庫分為受控配置制庫和非受控配置庫兩種。 2.2.1受

7、控配置庫 在本項目開發(fā)實施的整個過程中，根據(jù)不同階段的配置管理劃分12個受控配置目錄，只有配置管理員擁有增加和修改的權限，其他用戶只有只讀權限。受控配置庫的目錄為： 00 初始配置：包含配置文件清單，項目組人員清單，SCCB人員組成清單，也可放置舊的范例文檔或文檔模版 01 啟動：包含立項文檔、項目計劃等初始項目文檔 02 需求分析：包含業(yè)務需求、系統(tǒng)需求和產(chǎn)品需求等 03 設計：包含產(chǎn)品設計，如：概要設計，數(shù)據(jù)庫設計，架構設計，詳細設計，模型設計，原型設計，安全設計 04 編碼：包含源代碼和安裝包管理 05 測試：包含測試計劃，測試用例，測試報告 06 發(fā)布：包含發(fā)布計劃，發(fā)布版本控制表 0

8、7 總結：包含會議紀要，項目周報，結項報告等 08 變更：包含變更申請表，變更跟蹤統(tǒng)計表 09 項目管理：包含項目管理相關文檔，如評審報告，項目狀態(tài)報告，支持資源調(diào)整計劃，立項申請，立項通知等 10 環(huán)境配置：包含開發(fā)環(huán)境，測試環(huán)境，線上環(huán)境配置清單 11 開發(fā)工具：包含開發(fā)過程中使用到的全部工具 初始配置庫的根目錄中包含XXXX項目的配置文件清單，該文檔包括本項目開發(fā)過程中應該提交的文檔和清單，在實際開發(fā)過程中，根據(jù)實際情況，可以在清單中酌情修改、增加和刪除需要提交的文檔。具體內(nèi)容參見本文3.3的“配置文件清單的維護”。 各個配置目錄內(nèi)應該包含的文檔，請參見“XXXX項目配置文件清單.xls

9、” 在根據(jù)項目開發(fā)過程中，根據(jù)實際需要，可以酌情修改非受控配置目錄。 2.2.2非受控配置目錄 在本項目開發(fā)過程中，設立了非受控配置目錄。設立非受控配置目錄的是為了統(tǒng)一管理和存放開發(fā)過程中產(chǎn)生的臨時文檔和過程性文檔，沒有格式及命名上的嚴格要求，使項目組成人員在思考、設計時不受太多的限制和約束，能夠有效的發(fā)揮個人能力，符合以人為本的原則。 在項目的初期設立了以下兩個目錄：目錄名稱用途及說明小組工作區(qū)用于保存小組成員協(xié)作編寫的文檔，每個小組都有自己獨立的工作目錄文檔提交區(qū)作為非受控配置庫和受控配置庫之間的緩沖，用于提交已經(jīng)定稿的文檔和代碼，在評審通過后，再由配置管理員取出并提交到受控制配置庫中 在

10、根據(jù)項目開發(fā)過程中，根據(jù)實際需要，可以酌情增加非受控配置目錄。2.3 組織、職責和接口 項目配置管理員人員：職責：負責制定項目配置管理計劃；按照計劃實施項目配置管理活動；將配置狀態(tài)報告及時提交給相關人員。SCCB人員：成員1、成員2、成員3、。 負責人: 職責：在配置管理員提交配置項后，CCB檢查并批準/不批準配置項。檢查和批準項目基線。在得到變更請求的影響分析后，CCB檢查和批準/不批準該變更請求。變更審定配置項的基線建立。定期舉行工作會議。 項目經(jīng)理人員：職責：負責審批項目配置管理計劃，支持項目配置管理人員工作。QA人員： 職責：負責檢查項目配置管理過程執(zhí)行的有效性。2.4 配置管理過程a

11、 建立配置控制組（SCCB）；b 確定各個配置基線；c 制訂評審與檢查軟件配置管理計劃和規(guī)程；d 制訂相關的軟件開發(fā)、測試和支持工具的配置管理計劃和規(guī)程；e. 嚴格按照配置管理計劃執(zhí)行。3軟件配置管理計劃 關于XXXX項目軟件配置管理的文檔提交計劃請參見XXXX項目配置文件清單.xls。 關于配置庫的日常使用的規(guī)定參見附件4配置庫使用規(guī)定。3.1 建立示例配置庫配置管理員在制定完計劃后，根據(jù)公司建議的配置庫建立符合本項目的配置管理庫。配置庫建立在sharepoint、subversion上，目錄結構可按照示例的配置庫提供的目錄。對于本項目來說，需要劃分多個子系統(tǒng)，因此要在確定子系統(tǒng)的劃分后，在

12、不同階段下分別建立各自系統(tǒng)的配置目錄。源代碼管理參見源代碼策略。XXXX項目其配置管理（文檔）目錄結構如下圖所示：配置管理庫建立完畢后，可根據(jù)配置管理庫的人員計劃建立相應的用戶權限，并將這些用戶分發(fā)給指定的開發(fā)人員或用戶。具體的賬號及權限管理參加附錄3賬號及權限管理。配置管理員應該保管好配置管理工具的管理權限。3.2 配置標識管理 1. 文檔 根據(jù)配置管理計劃和配置庫中的文檔清單，配置管理員要檢查需要提交的文檔是否都按時提交，文檔數(shù)目是否符合，文檔的標識、命名以及版本等是否符合程序規(guī)定。關于文檔的命名請參見附件1 文件命名規(guī)定，文檔標示及版本參見附件2 文檔編碼規(guī)范2 程序 所有屬于該項目的程

13、序、分程序、模塊和程序單元，都要按照由項目組和配置管理員制訂的軟件系統(tǒng)的命名約定的規(guī)定來標識。 要求所有模塊的源代碼都需記錄模塊編號，且模塊編號在整個系統(tǒng)中是唯一的。模塊編號在系統(tǒng)設計完成之后，由項目組和配置管理員共同根據(jù)系統(tǒng)設計進行編制。3 基線 所有屬于本項目及其各子系統(tǒng)的各類基線，首先要按照計劃書、軟件需求規(guī)格說明書、軟件項目詳細分析設計說明書的規(guī)定確定其技術內(nèi)容，在整個軟件項目開發(fā)過程中定義以下三類基線：文檔基線：本項目的文檔基線的定義以里程碑的定義為準，將到達各階段的里程碑時的文檔作為基線，具體里程碑的定義參見第 4 節(jié)“里程碑”。代碼基線：依據(jù)公司源代碼策略和開發(fā)計劃設立源代碼基線

14、。（我的策略：分為三個步驟，第一是現(xiàn)在沒有實現(xiàn)配置管理階段：最初的開發(fā)在主干上，新特性的開發(fā)在分支上，如果新特性是有完整的階段性，及這一新特性階段完成才開始下一階段開發(fā)，則可以設立固定分支，如果是同步開發(fā)，則需要開多分支，主干的合并最好由配置管理員定期或根據(jù)計劃操作，測試可以在分支上進行，版本穩(wěn)定后可拉發(fā)布版本基線，然后再合并到主干上，及發(fā)布不一定非要從主干上提取代碼，分支上的代碼要與主干保持一致，分支和主干的持續(xù)集成計劃可不同，比如主干是定期，分支是按開發(fā)需求或測試發(fā)布需求集成（對于測試部分，需要跟測試組了解下，包括測試流程，使用工具，測試環(huán)境）；第二是配置管理推廣過程中依據(jù)推廣計劃和項目計

15、劃確立項目的源碼基線，期間完善成熟期的源碼策略；第三是配置管理成熟期：公司研發(fā)部使用統(tǒng)一的成熟的源碼策略，實現(xiàn)對源碼和程序包的配置管理）。產(chǎn)品基線：產(chǎn)品基線包含兩個，一個是系統(tǒng)上線時，一個是系統(tǒng)經(jīng)過客戶驗證測試時，基線包含那時的所有程序代碼和文檔。 配置管理員負責在項目開發(fā)的每一個里程碑處、每一個階段性的版本發(fā)布時負責為整個配置庫設立書簽，劃定配置管理基線，并以文檔的方式記錄下這些書簽的定義3.3 配置庫控制權限控制配置管理員根據(jù)賬號及權限管理.xls設置和調(diào)整項目組成員對配置項的權限。配置庫的控制 在項目的各個開發(fā)階段，應建立起各階段各子系統(tǒng)的軟件開發(fā)庫（軟件開發(fā)工作區(qū)），同時建立起想對應的

16、有關該系統(tǒng)及其子系統(tǒng)的軟件受控庫。在每個階段結束或里程碑，需讓各子系統(tǒng)提交相關的產(chǎn)品并送入軟件受控庫，由配置管理員統(tǒng)一管理，以后再有對產(chǎn)品的變更需求，應按照正常的變更程序來控制并檢查相關的變更文檔。當全部開發(fā)工作結束，需建立起軟件產(chǎn)品庫，將所有可交付的產(chǎn)品都送入軟件產(chǎn)品庫。軟件配置更改 軟件配置的更改管理適用于全部項目的所有文檔和代碼，其中包括整個項目的各個運行軟件，也包括為項目專門開發(fā)的支持軟件。l 對該項目各個子系統(tǒng)及其專用支持軟件的基線及其集成系統(tǒng)的任何修改，必須得 到項目負責人的批準并在本項目軟件質量管理專員處備案才能進行配置更改；l 更改完成后的文檔和代碼等，需得到項目負責人認可，提

17、交給配置管理員后，由配置管理員簽入受控配置庫；l 受控配置庫中的文檔，在文檔末尾必須有修改記錄部分，包括修改人、修改日期、修改內(nèi)容等項，每次對于受控配置庫中文檔的修改，必須填寫這些項。 配置文件清單的維護l 配置文件清單的維護由配置管理員維護；l 項目初期，配置管理員與項目組成員一起對開發(fā)過程中可能產(chǎn)生的文檔的進行預計，并在配置文件清單中列出這些文檔及其大致的計劃提交時間；l 在實際開發(fā)過程中，文檔提交可能會產(chǎn)生一些變化，如新增某些文檔、原計劃的一些文檔不再單獨產(chǎn)生、文檔計劃提交日期的變更等，項目組應該及時通知配置管理員，由配置管理員及時更改配置文件清單中的相應項。3.4 配置的審查和評審 配

18、置的檢查和評審可通過研發(fā)中心配置管理制度的審核內(nèi)容來進行檢查。相關的審核內(nèi)容如下表：審核分類審核內(nèi)容檢查情況 發(fā)布審核發(fā)布文檔是否清楚地定義發(fā)布的范圍，包括應被納入的更改請求？所有已知缺陷/毛病(bug)是否已文檔化？是否有適當?shù)奈臋n，它標識重建該發(fā)布所需的環(huán)境（編譯器版本、OS 版本、compilation flags，等等）？是否有適當?shù)奈臋n，它說明構成該發(fā)布的成分及成分的版本？發(fā)布的所有項是否彼此同步（在時間上一致）？是否采用正確存儲庫中的正確成分的正確版本生成發(fā)布？ 存儲庫/配 置項審核存儲庫是否按 SCM 計劃定義？配置項是否已經(jīng)進入正確的庫？是否按 SCM 計劃中規(guī)定的命名約定項命

19、名？是否按照 SCM 計劃，規(guī)定項的版本號？是否按照 SCM 計劃中規(guī)定的事件已經(jīng)將所有項入庫？例如：測試完成、客戶的評審意見已采納是否有所要求的文檔以識別項、版本和更改歷史？ 更改實施 審核是否全部所要求的更改請求均已結束？是否更改請求標識出全部擬更改的項？更改請求中所標識的全部要更改的配置項均已更改，被 QC 和在所要求的 QC 后入庫？是否可能在項的任何兩個版本中間區(qū)分更改？配置項的文檔是否足夠，能向后追蹤更改到相應的更改請求？是否有恰當方法能回到以前的版本？ 審核的其 他方面是否對庫作了恰當?shù)膫浞?？是否已測試過從備份中恢復？在群組成員的工作目錄中是否有任何未經(jīng)許可的成分？是否有恰當?shù)谋?/p>

20、密/批準手續(xù)以保證只有經(jīng)授權的群組成員才能進行入庫/出庫？ 配置管理員應配合研發(fā)中心產(chǎn)品管理部定期對項目進行配置管理的審核。在審核過程中，提供所需要的配置管理計劃及相關資料，在項目開發(fā)結束后，需提交所有關于項目的軟件配置庫。3.5 配置庫的備份 在項目開發(fā)實施過程的各個階段，配置管理員應定期做好軟件配置庫的備份，以防造成勞動成果的丟失而給整個項目及公司帶來的嚴重損失。 備份可按照公司的要求定期（按周或月）進行。在每個階段或里程碑處在做完基線工作后應進行備份。備份文件應存放在不同的地方。 本項目的備份按如下方式進行：ü 定期備份時間為每個月備份一次，備份方式同公司研發(fā)中心一致，定于每個

21、月的最后一個星期二；ü 當在月末（大于當月 20 日）達到一個里程碑時，對配置庫進行一次備份，取消當月月備份；ü 當在月中（大于當月 10 日，小于等于當月 20 日）達到一個里程碑時，對配置庫進行一次備份，當月月備份不變；ü 當在月初（小于當月 10 日）達到一個里程碑時，不需要對配置庫再進行一次備份，當月月備份不變；ü 備份的文件要明確標明備份日期，刻錄成光盤，在外地封閉開發(fā)，現(xiàn)場尚未配備刻錄機時，應保存在可靠的計算機中；3.6 配置管理計劃的修訂 初始的配置管理計劃在項目開始的初期進行制定，由于此時只能大致確定整個開發(fā)過程中的一些活動及其會產(chǎn)生的文

22、檔，在實際開發(fā)過程中，可能會與此有些差異，因此，配置管理計劃也需要根據(jù)開發(fā)過程的實際情況，及時進行修訂，使之能夠有效地對本項目的配置管理活動進行指導。 在一般情況下，進行配置管理計劃修訂的時機選在到達各個階段的里程碑時。如果在一個階段的實施過程中，配置管理計劃不能適應實際過程的變更，則由配置管理員與項目管理人員一起根據(jù)實際情況修訂配置管理計劃。 配置管理計劃的修訂，需要通過 XXXX 項目項目的項目負責任、軟件配置控制委員會成員、配置管理員的共同審核，一致簽字同意后方能作為此后階段的配置管理計劃。3.7 配置管理計劃附屬文檔配置文件清單 ：記錄項目開發(fā)過程中應該產(chǎn)生的一些文檔、描述及其提交計劃

23、等內(nèi)容，是執(zhí)行配置管理及檢查的重要依據(jù)。該文檔在項目開始的初期建立，確定開發(fā)過程中需要提交的大部分文檔，并在項目開發(fā)過程中根據(jù)實際情況稍做更新。模塊清單 ：模塊清單記錄了系統(tǒng)各個子系統(tǒng)、程序模塊的名稱并分別進行項目內(nèi)的唯一編號，是所有模塊的源代碼需記錄模塊編號的依據(jù)。模塊清單在系統(tǒng)設計完成之后，由 項目組和配置管理員共同根據(jù)系統(tǒng)設計進行編制。文檔命名規(guī)定 ： 參加附錄1 文檔命名規(guī)定賬號及權限管理 ： 參加附錄2 賬號及權限管理配置庫日常使用規(guī)定 ： 參加附錄3 配置庫日常使用規(guī)定4. 里程碑本項目主要分為以下幾個里程碑：里程碑特點1，需求分析已確立ü 系統(tǒng)（或所有已確定子系統(tǒng)）的需

24、求分析全部完成ü 已形成相應的需求分析說明書及其它附屬文檔ü 需求分析說明書已通過公司評審或與客戶一致認為需求分析階段已結束，可以進入設計階段2. 概要設計完成ü 系統(tǒng)（或所有已確定子系統(tǒng)）的概要設計全部完成ü 已形成相應的概要設計說明書及其它附屬文檔ü 概要設計說明書已通過公司評審或與客戶一致認為概要設計階段已結束，可以進入詳細設計階段3. 詳細設計完成ü 系統(tǒng)（或所有已確定子系統(tǒng)）的詳細設計全部完成ü 已形成相應的詳細設計說明書及其它附屬文檔ü 詳細設計說明書已通過公司評審或與客戶一致認為詳細設計階段已結束，可

25、以進入編碼階段4. 編碼完成ü 系統(tǒng)（或所有已確定子系統(tǒng)）的編碼全部完成ü 系統(tǒng)所有程序已經(jīng)經(jīng)過調(diào)試并確定可以運行ü 已通過公司評審或與客戶一致認為編碼階段已結束，可以進入系統(tǒng)測試階段5. 測試計劃完成ü 測試需求已經(jīng)確定并完成；ü 已形成相應的測試計劃說明書及其它附屬文檔6. 測試設計完成ü 測試用例已經(jīng)覆蓋所有測試需求ü 已形成相應的測試用例說明書及其它附屬文檔7. 系統(tǒng)測試完成ü 系統(tǒng)測試完成，所發(fā)現(xiàn)的所有缺陷已得到妥善處理ü 符合系統(tǒng)測試退出條件ü 已完成測試分析報告8. 項目結束

26、52; 上線成功ü 已得到客戶的確認并通過驗收測試ü 與客戶一致認為該項目已結束附錄1 文檔命名規(guī)則本命名規(guī)定主要是針對文檔的，不包含源代碼文件和最終程序的命名規(guī)則。本規(guī)定主要包含以下三個方面的命名規(guī)則： 1. 受控配置庫文件命名規(guī)則 2. 非受控配置庫文件命名規(guī)則 3. 提交文檔文件命名規(guī)則受配置庫文件命名規(guī)則受控配置庫中的配置項文檔（不含源代碼和最終工作產(chǎn)品）名稱應該按照如下格式命名：項目編號 + 文檔名稱 + V<發(fā)布版本號>.擴展名項說明項目名稱XXXX項目項目編號XXXXXX資料名稱開發(fā)計劃書系統(tǒng)方案書需求分析說明書概要設計說明書詳細設計說明書測試計劃

27、模塊清單撰寫或修改日期第一次撰寫完成日期或修改完成日期例如：2012年7月23日定稿開發(fā)計劃書：XXXXXX-軟件開發(fā)計劃書V1.0.doc。 2012年7月28日定稿的子系統(tǒng)一需求分析說明書：XXXXXX-子系統(tǒng)一需求分析說明書V1.0.doc。非受控配置庫文件命名規(guī)則 非受控配置庫主要用于存放項目成員工作時產(chǎn)生的臨時文檔等，只要求提交時不致出錯，對命名規(guī)則沒有其它限制，由項目成員根據(jù)自己習慣對文檔命名。 推薦命名方式： 文件名 + 日期.擴展名提交文檔文件命名規(guī)則同受控配置庫的文件命名規(guī)則。 項目成員提交文檔到文檔提交區(qū)前，應該按照受控配置庫的文件命名規(guī)則對文檔命名，然后才提交道文檔提交區(qū)中。附錄2 賬號及權限管理賬號管理 根據(jù)公司的erp賬戶建立用戶賬號權限管理 權限管理分為兩大部分的權限管理：1，受控配置庫的權限管理2，非受控配置庫的權限管理1、111、 、 受控配 配置管理員對受控配置庫擁有所有權限； 項目組其