沒有變更就沒有配置
配置管理是通過技術及行政手段對產品及其開發過程和生命週期進行控制、規範的一系列措施和過程。資訊系統開發過程中的變更以及相應的返工會對產品的質量有很大的影響。如果不從配置管理方面加以控制，必將導致嚴重的後果。
配置管理的乙個重要內容就是對變更加以控制，使變更對成本、工期和質量的影響降到最小。
15.1配置管理的概念
15.1.1配置項（進行配置管理的乙個物件）
配置項主要有兩大類：
●屬於產品組成部分的工作成果，例如需求文件、設計文件、源**、測試用例等。
●屬於專案管理和機構支撐過程域產生的文件，例如工作計畫、專案質量報告、專案跟蹤報告等
每個配置項的主要屬性有：名稱、識別符號、檔案狀態、版本、作者、日期等。所有配置項都被儲存在配置庫里，配置項及其歷史記錄反映了專案產品的演化過程。
15.1.2配置管理
2. cmmi中的定義
配置管理（configuration management)的目的在於運用配置標識、配置控制、配置狀態統計和配置審計，建立和維護工作產品的完整性。
配置管理流程主要包括9大部分：制訂配置管理計畫、識別配置項、建立配置管理系統、建立或發行基線、跟蹤變更、控制變更、建立配置管理記錄、執行配置審核、版本控制等
它是採用技術手段和行政手段進行管理和監督的一套規範化方法；對配置項的功能特性和物理特性加以標識，並將其文件化；控制這些特性的變更；報告變更進行的情況和變更實施的狀態以及驗證與規定需求的一致性。
4.專案配置管理的任務
制定專案配置管理計畫。確定配置標識規則。實施變更控制。報告配置狀態。進行配置審核。進行版本管理和發行管理。
一、15.2 配置管理計畫
配置管理計畫的主要內容包括配置管理軟硬體資源、配置項計畫、基線計畫、交付計畫、備份計畫等。由配置控制委員會（configuration control board，c c b )審批該計畫。
制訂配置管理計畫，以便於配置管理人員按計畫開展配置管理工作，並保持配置管理工作的一致性。
制訂配置管理計畫的主要步驟如下：
（1）建立並維護配置管理的組織方針(2)確定配置管理需使用的資源(3)分配責任(4)培訓計畫(5)確定「配置管理」的專案干係人，並確定其介入時機(6)制訂識別配置項的準則(7)制訂配置項管理表(8)確定配置管理軟硬體資源(9)制訂基線計畫(10)制訂配置庫備份計畫(11)制訂變更控制流程(12)制訂審批計畫
二、15.3 配置標識與建立基線
配置標識是配置管理的基礎性工作，是管理配置的前提。
基線（baseline)由一組配置項組成，這些配置項構成了乙個相對穩定的邏輯實體。基線中的配置項被「凍結」了，不能再被任何人隨意修改（可以修改但是要經過流程需要手段）基線通常對應於開發過程中的里程碑（milestone), —個產品可以有多個基線，也可以只有乙個基線。基線的主要屬性有：
名稱、識別符號、版本、日期等
產品的乙個測試版本（可能包括需求分析說明書、概要設計說明書、詳細設計說明書、已編譯的可執行**、測試大綱、測試用例、使用手冊等）也可作為基線。
15.3.1識別配置項
識別配置項即識別將置於配置管理之下的配置項和有關的工作產品。選擇、建立和規範配置項的識別主要包括：將交付給顧客的產品，指定的內部工作產品，採辦的產品，工具，其他用於建立和描述這些工作產品的實體。
識別配置項的主要步驟如下：
(1) 識別配置項（是配置管理員cmo做的）(2) 為每個配置項指定唯一性的標識號( 3 )確定每個配置項的重要特徵( 4 )確定配置項進入配置管理的時間( 5 )確定每個配置項的擁有者的責任( 6 )填寫《配置項管理表》( 7 )審批《配置項管理表》
15.3.3建立基線或發行基線
這裡所說的基線是一組經過正式審查並且達成一致的規範或工作產品，是開發工作的基礎。對基線的更改必須遵循變更控制規程。基線反映分配給配置項的標識號及其相應的實體。
一組擁有唯一標識號的需求、設計、源**文捲以及相應的可執行**、構造文捲、和使用者文件（相關的實體)，可以認為是乙個基線。基線一經發布，就可以作為從配置管理系統檢索源**文捲（配置項）和生成可執行文捲的工具。交付給外部顧客的基線一般稱為發行基線，內部使用的基線一般稱為構造（用的）基線。
建立基線或發行基線的主要步驟如下：
(1) 獲得ccb的授權(2) 建立構造基線或發行基線(3) 形成檔案(4) 使基線可用
三、15.3.2 建立配置管理系統
配置管理系統用於控制工作產品的配置管理和變更管理。該系統包括儲存**、規程和訪問該配置系統的工具、用於記錄和訪問變更請求的工具。
建立和管理配置管理系統的主要步驟如下：
（1）建立適用於多控制等級配簟管理的管理機制
(8) 許可權分配
配置管理員為每個專案成員分配對配置庫的操作許可權。一般地，專案成員擁有add，checkin/checkout, download等許可權，但是不能擁有「刪除」許可權。配置管理員的許可權最高。
建立配置管理系統用什麼方法可以建立呢：vss cvs svn 手工也可以
四、15.4 變更管理
3. 變更管理的任務
變更管理簡單地說就是控制修改，使之不出現改錯、改亂的現象。變更管理的任務如下：
●分析變更：研究變更的必要性，經濟可行性（成本-效益比是否合算）和技術可行性（能否實現)。
●記錄和追蹤變更。
●採取措施保證變更在受控狀態下進行。
因此，ieee解釋變更管理時說，它是配置管理的乙個重要組成部分，涉及到在給配置項建立了正式的配置標識後變更的評價、協調、審批與實現諸方面的活動。
15.4.1配置庫
1. 配置庫的作用（存放配置項的倉庫）
2. 三類庫
配置庫有三類。
●開發庫（development library)（也叫做程式設計師庫或者動態庫）存放開發過程中需要保留的各種資訊，
供開發人員個人專用。庫中的資訊可能有較為頻繁的修改，只要開發庫的使用者認為有必要，無需對其做任何限制。
●受控庫（controlled library)。在資訊系統開發的某個階段工作結束時，將工作產品存入或將有關的信
息存入。存入的資訊包括計算機可讀的以及入工可讀的文件資料。應該對庫內資訊的讀寫和修改加以控制。
（讀取不可以）
●產品庫：一般也不做修改。修改走流程
15.4.2變更控制
1. 變更控制委員會
變更控制委員會（change control board, ccb)也稱為配置控制委員會（configuration control board),是配製項變更的監管組織。其任務是對建議的配製項變更做出評價、審批以及監督已批准變更的實施。
這個組織不必是常設機構，他可以由不同的人組成，小的專案ccb可以只有1人，甚至只是兼職人員。
2. 變更請求與變更控制
五、15.5 版本管理
版本管理的目的是按照一定的規則儲存配置項的所有版本，避免發生版本丟失或混淆等現象，並且可以快速準確地查詢到配置項的任何版本。
配置管理員負責版本編號及控制工作。
15.5.1配亶項狀態變遷規則
配置項的狀態有三種：草稿（draft)、正式發布（released)和正在修改（changing)。
15.5.2配置項版本號規則
●處於「草稿」狀態的配置項的版本號格式為：o.yz。
●y z數字範圍為0199。
●隨著草稿的不斷完善，y z的取值應遞增。y z的初值和增幅由開發者自己把握。
●處於「正式發布」狀態的配置項的版本號格式為：x.y。
●x 為主版本號，取值範圍為19。y 為次版本號，取值範圍為19。
●配置項第一次「正式發布」時，版本號為1.0。
●如果配置項的版本公升級幅度比較小，一般只增大y 值，x 值保持不變。只有當配置項版本公升級幅度比較大
時，才允許增大x 值。
●處於「正在修改」狀態的配置項的版本號格式為：x.yz。
●配置項在修改時，一般只增大z 值，x.y值保持不變。
●當配置項修改完畢，狀態重新成為「正式發布」時，將z 值設定為0，增加x .y值。
例：0.99草稿 1、13正在修改 1.14 正在修改修改幅度小 3.5正式發布 1.0第一次正式發布
15.5.3 配置項版本控制流程
(1) 建立配置項( 2 )修改處於「草稿」狀態的配置項(3) 技術評審或領導審批(4) 正式發布(5) 變更
六、15.6 配置審核
15.6.1配置審核定義
配置審核的任務便是驗證配置項對配置標識的一致性。資訊系統開發的實踐表明，儘管對配置項做了標識，實踐了變更控制和版本控制，但如果不做檢查或驗證仍然會出現混亂。這種驗證包括：
●對配置項的處理是否有背離初始的規格說明或已批准的變更請求的現象。
●配置標識的準則是否得到了遵循。
●變更控制規程是否已遵循，變更記錄是否可供使用。
●在規格說明、專案產品和變更請求之間是否保持了可追溯性。
兩個方面，一是功能，實際功效是與其需求一致的；二是物理，物理介質**形式
15.6.2實施配置審核的意義
●防止出現向使用者提交不適合的產品，如交付了使用者手冊的不正確版本。
●發現不完善的實現，如開發出不符合初始規格說明或未按變更請求實施變更。
●找出各配置項間不匹配或不相容的現象。
●確認配置項已在所要求的質量控制審查之後作為基線入庫儲存。
●確認記錄和文件保持著可追溯性。
七、15.7 配置狀態報告
15.7.1什麼是配置狀態報告
配置狀態報告（configuration status reporting)也稱配置狀態說明與報告（configuration status accounting & reporting),它是配置管理的乙個組成部分，其任務是有效地記錄和報告管理配置所需要的資訊，目的是及時、準確地給出軟體配置項的當前狀況，供相關人員了解，以加強配置管理工作。
ppt：
如果把軟體系統看作系統的乙個組成部分，以下3種基線是最受人們關注的。
（1）功能基線：是指在系統分析和軟體定義階段結束時，經過正式評審批准的系統設計規格說明中對被開發軟體系統的規格說明；或是指經過專案委託單位和專案承辦單位雙方簽字同意的協議或合同中所規定的對被開發軟體系統的規格說明；或是指由下級申請上級同意或直接由上級下達的專案任務中所規定的對待開發軟體系統的規格說明。
（2）分配基線。分配基線是指在軟體需求分析階段結束時，經正式評審和批准的軟體需求規格說明。
（3）產品基線。產品基線是指在軟體組裝與系統測試階段結束時，經正式評審和批准的有關所開發的軟體產品的全部配置項的規格說明。
各角色在配置管理活動中的許可權:
配置管理中的角色和分工：
要使配置管理活動在資訊系統的開發和維護中得到貫徹執行,首先要明確確定配置管理活動的相關人員及其職責和許可權。配置管理過程的主要參與人員如下：
(1)專案經理（project manager, pm )專案經理是整個資訊系統開發和維護活動的負責人，他根據配置控制委員會的建議，批准配置管理的各項活動並控制它們的程序。其具體工作職責如下：
制訂專案的組織結構和配置管理策略；決定專案起始基線和軟體開發工作里程碑；接受並審閱配置控制委員會的報告。
(2)配置控制委員會（configuration control board, ccb)負責指導和控制配置管理的各項具體活動的進行，為專案經理的決策提供建議。其具體工作職責如下：
批准配置項的標誌，以及軟體基線的建立；制訂訪問控制策略；建立、更改基線的設定，審核變更申請；根據配置管理員的報告決定相應的對策。
(3)配置管理員（configuration management officer, cmo)根據配置管理計畫執行各項管理任務，定期向ccb 提交報告，並列席ccb的例會，其具體工作職責如下：
軟體配置管理工具的日常管理與維護；提交配置管理計畫；各配置項的管理與維護；執行版本控制和變更控制方案；完成配置審計並提交報告；對開發人員進行相關的培訓；識別開發過程中存在的問題並制訂解決方案。
(4)開發人員（developer, dev)開發人員的職責就是根據專案組織確定的配置管理計畫和相關規定，按照配置管理工具的使用模型來完成開發任務。
專案管理配置管理計畫
專案名稱 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....
專案配置管理計畫範本
x專案 這裡填寫公司名稱 x年xx月xx日 文件編號 xx 版本號 1.00 產品名稱 x專案專案 文件名稱 配置管理計畫 這裡填寫公司位址 等 目錄1.引言 1 1.1 目的 1 1.2 術語定義 1 1.3 參考資料 1 2.軟體配置 2 2.1 軟體配置環境 2 2.2 軟體配置項 2 2.3...
09軟體專案配置管理計畫
韓萬江姜立新，軟體專案管理案例教程 機械工業出版社 2005 02 叢書名 國家示範性軟體學院系列教材 第8章介紹了質量管理計畫可以幫助提高產品的質量，而軟體配置管理也可以輔助提高專案的質量管理。同時，有效的配置管理還可以提高開發團隊的工作效率。本章就進入路線圖的第8站 配置計畫，如圖9 1所示。圖...