【使用者名稱】
神州數碼資訊系統****
密級：普通
***專案
軟體配置管理計畫
v0.1
修訂文件歷史記錄
目錄1 前言 5
1.1 目標 5
1.2 適用範圍 5
1.3 術語與簡寫 5
1.4 參考檔案 5
2 組織結構和職責 5
2.1 ccb成員及職責 5
2.2 配置管理組 6
3 配置管理工具、技術和方法 6
3.1 配置管理工具 6
3.2 配置管理策略 6
4 配置管理庫 7
4.1 配置庫結構 7
4.2 配置庫許可權 7
4.3 基線配置項 7
4.4 其他配置項 8
4.4.1 管理文件或過程記錄 8
4.4.2 專案環境 9
5 檔案命名與版本控制 9
5.1 檔案命名規範 9
5.1.1 基線命名規範 9
5.1.2 其他配置項命名規範 10
5.2 版本標識 10
6 變更管理 11
6.1 變更原因 11
6.2 變更流程 12
6.3 變更跟蹤 14
7 版本製作與發布流程 16
8 安全與備份 16
8.1 備份 16
8.2 安全防護 17
9 配置狀態發布 17
本計畫是資訊平台專案配置管理活動的基準，對資訊平台專案的配置管理活動進行策劃。
本計畫是資訊平台專案整體計畫的一部分，適用於資訊平台專案的配置管理活動。
ccb：變更控制委員會
sqa：質量保證
scm：配置管理
dcg-scm-p-01-配置管理規範。
專案內部ccb成員：章某（ccb組長）、陳、小偉、小明、玲玲。
ccb組職責：決定ccb成員中對變更確認審批級別，協調ccb成員對變更達成一致，並確認變更的結果。
專案總監
章某：負責對專案的總體調控。
專案經理
小偉：負責對專案中計畫的變更等進行確認，並對變更所涉及的資源變更進行評估，負責變更的執行。
需求調研
陳：負責專案的整體需求。
技術經理
小明：負責專案技術支援及專案的執行。
scm人員
玲玲：負責變更，配置庫日常管理和許可權控制。
測試經理
？：負責評估變更中測試方面的問題。
sqa 人員
？：過程審計。
配置管理員 ：負責搭建配置庫，制定並執行配置管理計畫、培訓專案組成員、執行日常配置管理工作。
伺服器ip位址： \\192.168.8.000
文件管理
配置管理工具：svn
配置庫名稱：ws
源**管理
配置管理工具：svn
配置庫名稱：ws
配置庫分為工作庫、受控庫和基線庫。
工作庫：儲存專案的所有工作產品中間結果，即正處於開發中的**和編寫中的文件，其內容可能進行頻繁的修改。
受控庫：儲存專案的所有準備生成基線的工作成果，待評審的文件、部署程式的中間版本、以及專案管理類文件等。
基線庫：儲存專案的所有基線化了的工作成果，評審通過的階段產出物、具有路標性質的對外發布版本等。
工作庫：專案組所有成員均有讀寫許可權。
受控庫：配置管理員和專案經理有讀寫許可權，其他專案組成員有唯讀許可權。
基線庫：配置管理員有讀寫許可權，其他人員經授權可調閱。
（注：共通**由專人管理）
[專案名稱]+[子系統名]+[文件名稱]+[vx.y]（版本號）
專案名稱定義為：資訊平台（英文縮寫：ws）
子系統名：若沒有子系統可以省略
舉例：資訊平台-工作說明書v1.0；
與時間相關的文件命名：
[專案名稱][文件名稱][ yyyymmdd]（注：其中如果是週報yyyymmdd以結束日期為準）
備註：yyyymmdd為「年月日」時間格式
舉例：資訊平台-專案週報20100607； （結束日期）
資訊平台-會議紀要20100602；
與時間沒有直接關係的文件命名：
直接以[專案名稱][文件名稱]命名。
舉例：資訊平台初驗階段報告；
資訊平台專案總結報告；
文件發布的版本遵循x.y（主版本.副版本）形式：
1、 版本標識定義原則
版本標識必須唯一標識不同的版本；
版本標識必須反映不同級別版本的層次關係；例如採用x.y（主版本.從版本）的定義規則
必須定義不同級別版本號增加的規則。
2、 版本設定規則
新起草編寫的檔案定為v0.1版；逐步完善還沒有通過評審的檔案版本公升級為v0.y版；
通過內部正式審批的檔案版本公升級為v1.0版，可對外發布；
稱為內部基準的檔案如有少量修改，可公升級為v1.x版；
如有通過客戶的評審，檔案版本可公升級為v2.0，以此類推。
**發布的版本遵循x.y（主版本.副版本）形式：
build<####>為build順序號，每build一次號碼加1；永遠不清零。
p為fat順序號，每提交fat測試號碼加1，fat測試由公司人員測試。
z為uat順序號，每提交uat測試號碼加1，uat測試有使用者或監理參加。
x,y以使用者確定為準。使用者版本號增加時p和z清零。
yyyyymmdd代表發布版本日期
1、評審、審計、測試和驗證發現問題引起配置的配置項變更，配置項的版本需要更新。
更改源是《評審報告》、《整合測試分析報告》或《審計報告》。
2、客戶、專案組填寫的變更申請引起配置項變更，變更申請表是更改源。
3、出現下列情況時引起的配置項變更，不需要填寫變更申請表：
計畫級的文件更改——wbs計畫；
《軟體配置管理計畫》、《軟體質量保證計畫》；
測試工具或測試指令碼（不屬於提交給使用者）。
4、當專案範圍發生變化、風險發生並且採用了專案計畫中沒有指定的糾正措施、專案計畫與實際情況偏離20%以上、由內部與外部審計而導致的糾正活動、專案計畫中的任何修改條件滿足等事件發生時，由專案經理組織相應的配置控制委員會成員對要發生的變更進行評審
1. 變更申請
1) 變更申請人通過多種渠道提出對配置項的變更請求。驅動因素主要包括使用者需求變更、評審、測試以及配置審計等。
2) 變更申請人負責填寫《需求設計變更申請表》，並提交配置控制委員會實施變更評估。
2. 變更評估
1) 針對變更申請人提交的變更請求，配置控制委員會在評估該變更的影響範圍及對專案進度、成本、質量等指標的影響程度後，決定是否實施該變更。
2) 配置控制委員會將針對該變更做出的決定（接受或拒絕）通知變更申請人。
3. 變更實施
1) 變更申請獲得批准後，配置控制委員會將該變更分配給相應執行人實施。
2) 專案配置管理員將該變更涉及的所有配置項從配置庫中簽出並提交給變更執行人。
3) 變更執行人實施該變更；
4. 變更驗證
1) 配置控制委員會對變更後的工作產品進行驗證，以確定變更是否正確完成。
2) 在變更完成並經過驗證後，專案配置管理員將經批准的配置項簽入配置庫。
1、 客戶需求變更：
1) 與使用者之間變更流程：專案組需要依據專案管理規範中的需求管理要求，結合專案使用者實際情況制定需求變更流程，填寫《需求設計變更申請表》並按照流程要求執行申請和審批過程，保留期間使用者的簽字確認檔案。
2) 內部審批流程：10人天以內的變更專案經理確認，10人天以上，20人天以內需要工程總監確認，20人天以上的變更需要事業部總經理確認。配置管理員跟蹤變更審批狀態，維護《基線狀態報告—變更跟蹤表》。
軟體開發 軟體配置管理計畫編寫規範
專案名稱 作者完成日期 簽收人簽收日期 修改情況記錄 目錄1 引言 1 1.1 目的 1 1.2 定義和縮寫詞 1 1.3 參考資料 1 2 管理 1 2.1 機構 1 2.2 任務 2 2.3 職責 2 2.4 介面控制 2 2.5 實現 2 2.6 適用的標準 條例和約定 3 2.6.1 指明 ...
ISO軟體開發全套 配置管理計畫編寫指南
產品 專案系統名稱 配置管理計畫 北京 x 200 年 月 編寫的目的主要在於對所開發的軟體系統規定各種必要的配置管理條款，以保證所開發出的軟體能滿足使用者需求。a.開發的軟體系統的名稱 列出本軟體系統的中文全稱 英文全稱及英文表示簡稱。b.開發的軟體系統的終端使用者或適用的領域 c.專案 主管部門...
規範軟體開發過程 軟體配置管理實踐
2010 05 19 網路 隨著軟體系統的規模 複雜度日益上公升，軟體開發過程管理已經成為保證軟體系統開發效率 質量 成本的關鍵性因素。作為軟體開發過程中質量保障的重要組成部分，行之有效的軟體配置管理 以下簡稱scm，software configuration management 能夠顯著提高軟...