此頁為模板文件本身的版本控制記錄表，按模板生成的正式文件中不需要此頁
目錄1. 簡介 5
1.1 目的 5
1.2 範圍 5
1.3 專業術語定義 5
1.4 參考資料 5
2. 組織和管理 5
2.1 配置管理組織架構 5
2.2 角色和職責 5
2.3 scm指導方針 6
3. scm活動 6
3.1 vss目錄結構說明 6
3.2 配置項的標識標準、說明標準和版本說明標準 6
3.2.1 配置項的標識標準 6
3.2.2 配置項的說明標準 6
3.2.3 配置項的版本說明標準 6
3.3 配置項定義 6
3.4 基線的標識標準、說明標準和版本說明標準 8
3.4.1 基線的標識標準 8
3.4.2 基線的說明標準 8
3.4.3 基線版本說明標準 8
3.5 基線定義 8
3.6 變更管理流程 9
3.7 配置狀態報告流程 9
3.7.1 配置管理記錄 9
3.7.2 配置狀態報告 9
3.8 產品發布流程 9
3.9 配置審計流程 9
4. 配置管理活動安排表 9
5. 工具和資源 10
6. scm里程碑 10
7. 培訓（可選） 10
8. 子承包方的支援（可選） 10
9. 計畫的維護 10
提供配置管理活動的簡單描述，以便受影響的人和組對scm計畫獲得清楚的理解。
簡短描述scm計畫的必要性和在專案生命週期的早期階段制定的原因。
scm的目的是保證軟體專案生成的產品在整個軟體生命週期中的完整性。說明在產品/專案生命週期中將執行的所有與 cm 相關的活動。 記錄如何計畫、實施、控制和組織與產品相關的 cm 活動。
描述scm計畫的適用性、限制和假設。
範圍和scm計畫內容是隨著專案的範圍、規模和型別變化的。包括：
專案配置項的概述
被放置或控制在配置管理系統中的軟體配置項的定義
定義scm計畫中包括的其它軟體（例如支援軟體或測試軟體）
描述專案配置管理活動與硬體或系統的關係
定義已知的假設條件、風險
/*本計畫中採用的專業術語和縮寫的解釋說明*/
/*定義編寫計畫引用的資料說明*/
/*計畫所影響的成員及成員組織方式，用組織結構圖表示*/
/*在配置管理活動中每乙個受影響的人員的職責*/
定義專案中使用的scm政策、過程、指南和模板
『制定計畫時可參考以下描述，可直接引用』
1. 公司所有軟體專案必須遵守scm政策。本專案組的scm的制定、管理遵守公司的scm政策，在
整個專案的生命週期中實施scm。
2、scm 涉及到過程包括：spi_scm01_配置管理計畫過程、spi_scm02_配置管理審批過程、spi_scm03_配置管理實施過程，
3、scm 涉及到流程包括：spi_scm03_p01_配置變更管理流程、spi_scm03_p02_配置狀態報告流程.doc
4．使用到的指南為：spi_scm01_g01_配置管理指南
5、使用到的摸板包括（三個）：
spi_scm03_p01_t01_變更申請表
spi_scm03_p02_t01_配置狀態報告
spi_scm02_t01_基線審計報告
具體根據專案實際情況制定符合專案使用的標準，如果使用者有特殊要求時，依據使用者標準
統一的字首+分隔符+文書名稱（如軟體需求規格說明書、設計說明書等）
統一的字首是：『×××』（注：字首為專案名稱，或是以專案名稱的縮寫替代
『例如：廣東省公安機關經偵資訊管理系統可簡寫成：經偵資訊管理系統或者jz***t等』
分隔符是：『-』（減號）
例如：×××-使用者需求說明書
配置項文書名稱為：×××-使用者需求說明書、×××-系統設計說明書、×××-源**及可執行系統等。
基線文書名稱為：**基線
版本控制採用vss的控制方法。採用v*.*.*的格式，分三層，按自然數增長。vss上每提交一次文件，則version號碼增加1。
當文件成為基線化時，使用vss的label標籤，形如v1.0.1。當所做的修改需要更改基線時，提公升為v1.1.0 。
大的版本公升級，由專案經理確定，如：當第2位已變更為9時，可以提公升大的版本；為滿足專案特定的要求，可以提公升大的版本。
具體可參考公司指南檔案：spi_spe_g01_軟體專案產出物版本標識及版本號公升級指南
/說明本專案中選擇的配置項/
具體根據專案實際情況制定符合專案使用的標準，如果使用者有特殊要求時，依據使用者標準
基線的標識標準：階段名稱（如需求、設計……）+統一的字尾（基線）；以資料夾的形式存放在vss發布區(受控區)中各階段下,具體請參照「3.5基線定義」表。
基線的說明標準：已經建立基線的,在每次check out 出來修改的時候請簡要說明修改原因,而在check in 的時候請簡要說明修改的內容。
版本控制採用vss的控制方法：使用vss的label標籤，形如「字首」-v 1.0.1。
其中「字首」如「rq」代表「需求」，「de」代表設計。「co」代表編碼，「re」代表產品。
當所做的修改不足以影響到下一階段的工作時，提公升v0.0.1,即v1.0.1,
當所做的修改影響到下一階段的工作時，提公升為v1.1.0 , 1.
2.0…… 大的版本公升級，由專案經理確定，如：當第2位已變更為9時，可以提公升大的版本；為滿足專案特定的要求，可以提公升大的版本。
/說明本專案中選擇的配置項/
具體參見「配置管理變更流程」
具體參見「配置狀態統計報告流程」
在配置管理活動中所產生的記錄
/*定期（什麼時候）向專案經理（所有需要的角色）提供各類彙總報告（何種報告），採用的報告模板*/
配置管理計畫
專案名稱 the english name 專案小組 修訂表審批記錄 目錄1.引言 4 1.1 目的 4 1.2 適用範圍 4 1.3 參考資料 4 1.4 術語和縮略語 4 2.人員與責任 4 3.用於配置管理的軟硬體資源 5 4.配置庫結構與許可權 5 4.1 配置庫列表 5 4.2 配置庫結構...
配置管理計畫
專案名稱 檔案修改記錄 變化狀態 c 建立，a 增加，m 修改，d 刪除 文件審批資訊 目錄1 概述 1 1.1 目的 1 1.2 適用範圍 1 1.3 背景 1 1.4 參考資料 1 2 資源描述 1 2.1 角色職責 1 2.2 軟體資源 2 2.3 硬體資源 2 3 配置管理活動 2 3.1 ...
配置管理計畫
2 2 任務 在軟體工程化生產的各個階段中，與本階段的階段產品有關的全部資訊在軟體開發庫存放，與前面各個階段的階段產品有關的資訊則在軟體受控庫存放。在研製與開發階段的階段產品的過程中，開發者和開發小組組長有權對本階段的階段產品作必要的修改 但是如果開發者或開發小組長認為有必要修改前面有關階段的階段產...