配置管理是為了系統地控制配置變更，在系統的整個生命周期中維持配置的完整性和可跟蹤性，而標識系統在不同時間點上配置的學科。

在GB/T 11457- -2006中， 將“配置管理”正式定義為:“應用技術的和管理的指導和監控方法以標識和說明配置項的功能和物理特征，控制這些特征的變更，記錄和報告變更處理和實現狀態并驗證與規定的需求的遵循性。”

配置管理包括6個主要活動:

------制訂配置管理計劃、配置標識、配置控制、配置狀態報告、配置審計、發布管理和交付-----

如何進行配置管理計劃
配置控制任務主要有兩個:①涉及程序的狀態轉移管理??②涉及必須被實現的變更申請的管理

1. 配置項

? ? ? ? GB/T 11457—2006（軟件工程術語）對配置項的定義為：“為配置管理設計的硬件、軟件或二者的集合，在配置管理過程中作為一個單個實體來對待。”配置項的例子有：交付的軟件產品和數據，用于創建或支持軟件產品的支持工具，供應商提供的軟件和客戶提供的設備/軟件，各類文檔，源代碼，可執行代碼，測試用例，運行軟件所需的各種數據等。

? ? ? ? 在信息系統的開發過程中需加以控制的配置項可以分為基線配置項和非基線配置項兩類。? 例如，基線配置項可能包括所有的設計文檔和源程序等；非基線配置項可能包括項目的各類計劃和報告等。

? ? ? 所有配置項的操作權限應由CMO（配置管理員）嚴格管理，基本原則是：基線配置項向開發人員開放讀取的權限；非基線配置項向PM、CCB及相關人員開放。

典型的配置項有哪些：
需求規格、設計文檔、源代碼、測試計劃、測試腳本、測試規程、測試數據、項目使用的標準(例如編碼規范和設計規范)、驗收計劃、CM計劃和項目計劃之類的文檔、用戶手冊之類的用戶文檔、培訓材料文檔、合同文檔(包括支持工具，如編譯器或內部使用的工具)、質量記錄(評審記錄、測試記錄)和CM記錄(發布記錄、狀態跟蹤記錄)。

2.?配置項狀態

配置項的狀態可分為“草稿”“正式”和“修改”

?3.?配置項的版本號

(1)處于“草稿”狀態的配置項的版本號格式為0.YZ, YZ的數字范圍為01~99。隨著草稿的修正，YZ 的取值應遞增。YZ的初值和增幅由用戶自己把握。.

(2)處于“正式”狀態的配置項的版本號格式為X.Y，X為主版本號，取值范圍為1~9。Y為次版本號，取值范圍為0~9。

配置項第一次成為“正式”文件時，版本號為1.0。

如果配置項升級幅度比較小，可以將變動部分制作成配置項的附件，附件版本依次為1.0，1.1，.。當附件的變動積累到一定程度時，配置項的Y值可適量增加，Y值增加一定程度時，X值將適量增加。當配置項升級幅度比較大時，才允許直接增大X值。

(3) 處于“修改”狀態的配置項的版本號格式為X.YZ。配置項正在修改時，- -般只增大Z值，X.Y值保持不變。當配置項修改完畢，狀態成為“正式”時，將Z值設置為0，增加X.Y值。參見上述規則(2)。

4. 基線

? ? ?基線通常對應于開發過程中的里程碑(Milestone)， 一個產品可以有多個基線，也可以只有一個基線。交付給外部顧客的基線一般稱為發行基線( Release)，內部開發使用的基線一般稱為構造基線( Build)。

? ? ? ? 基線（baseline）是項目生存期各開發階段末尾的特定點，也稱為里程碑（milestone），在這些特定點上，階段工作已結束，并且已經形成了正式的階段性產品。

? ? ? ? 建立基線的概念是為了把各開發階段的工作劃分得更加明確，使得本來連續開展的開發工作在這些點上被分割開，從而更加有利于檢驗和肯定階段工作的成果，同時有利于進行變更控制。有了基線的規定就可以禁止跨越里程碑去修改另一開發階段的工作成果，并且認為建立了里程碑，有些完成的階段成果已被凍結。

? ? ? ? 作為階段工作的正式產品，基線應該是穩定的，如作為設計基線的設計規格說明應該是通過評審的。如果還只是設計草稿，就不能作為基線，不能被凍結。
? ? ? ? 如果把軟件看作是系統的一個組成部分，以下3種基線最受人們關注的：功能基線、分配基線、產品基線。

? ? ? ? （1）分配基線（指派基線）：指在軟件需求分析階段結束時，經過正式評審和批準的軟件需求的規格說明。指派基線是最初批準的指派配置標志。

? ? ? ? （2）功能基線：指在系統分析與軟件定義階段結束時，經過正式評審和批準的系統設計規格說明書中對待開發系統的規格說明；或是指經過項目委托單位和項目承辦單位雙方簽字同意的協議書或合同中所規定的對待開發軟件系統的規格說明；或是由下級申請經上級同意或直接由上級下達的項目任務書中所規定的對待開發軟件系統的規格說明。功能基線是最初批準的功能配置標志。

? ? ? ? （3）產品基線：指在軟件組裝與系統測試階段結束時，經過正式評審批準的有關所開發的軟件產品的全部配置項的規格說明。產品基線是最初批準的產品配置標志。

? ? ? ? 另外，交付給外部顧客的基線一般稱為發行基線，內部使用的基線稱為構造基線。釋放是指在軟件生存周期的各個階段結束時，由該階段向下階段提交該階段產品的過程。它也指將集成與系統測試階段結束時所獲得的最終產品向用戶提交的過程。后面這個過程也稱為交付。

? ? ? ? 提出基線的概念本來是為了更好地實現變更控制，但如果把每個基線都當成一個整體來看待會造成麻煩。因為一個變更很可能只涉及基線的很小部分。例如，假定某個大型軟件中的一個模塊修改了，如果將這一變更當做整個軟件產品基線的變更，就很不方便。

5.?配置庫

配置庫可以分開發庫、受控庫、產品庫3種類型。
?

6. 配置控制委員會(Configuration Control Board, CCB),

? ? ? 負責對配置變更做出評估、審批以及監督已批準變更的實施。
? ? ? ? CCB建立在項目級，其成員可以包括項目經理、用戶代表、產品經理、開發工程師、測試工程師、質量控制人員、配置管理員等。CCB不必是常設機構，完全可以根據工作的需要組成，例如按變更內容和變更請求的不同，組成不同的CCB。小的項目CCB可以只有一個人，甚至只是兼職人員。? 通常，CCB不只是控制配置變更，而是負有更多的配置管理任務，例如:配置管理計劃審批、基線設立審批、產品發布審批等。

7. 配置管理關鍵活動

1.配置項(Software Configuration Item，SCI) 識別

“軟件過程的輸出信息可以分為三個主要類別: (1) 計算機程序(源代碼和可執行程序)(2)程序的文檔(針對技術開發者和用戶)，(3)數據(包含在程序內部或外部)。

建立基線控制-打lable
IEEE對基線的定義是這樣的:“已經正式通過復審核批準的某規約或產品，它因此可作為進一步開發的基礎，并且只能通過正式的變化控制過程改變。”我們在軟件的開發流程中把所有需加以控制的配置項分為基線配置項和非基線配置項兩類，例如:基線配置項可能包括所有的設計文檔和源程序等;非基線配置項可能包括項目的各類計劃和報告等。

2.工作空間管理
在引入了軟件配置管理工具之后，所有開發人員都會被要求把工作成果存放到由軟件配置管理工具所管理的配置庫中去，或是直接工作在軟件配置管理工具提供的環境之下。
- -般來說，比較理想的情況是把整個配置庫視為一個統-的工作空間，然后再根據需要把它劃分為個人(私有)、團隊(集成)和全組(公共)這三類工作空間(分支)，從而支持并行開發的需求。
每個開發人員按照任務的要求，在不同的開發階段，工作在不同的工作空間上，例如:對于私有開發空間而言，開發人員根據任務分工獲得對相應配置項的操作許可之后，他即在自己的私有開發分支.上工作，他的所有工作成果體現為在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素，而集成分支對應的是開發團隊的公共空間，該開發團隊擁有對該集成分支的讀寫權限，而其他成員只有只讀權限，它的管理工作由SIO負責;至于公共工作空間，則是用于統-存放各個開發團隊的階段性工作成果，它提供全組統- -的標準版本，并作為整個組織的Knowledge Base。

3.版本控制
版本控制是軟件配置管理的核心功能。所有置于配置庫中的元素都應自動予以版本的標識，并保證版本命名的唯- -性。?Improvement, SPI) 活動的進行。

4.變更控制
在對SCI的描述中，我們引入了基線的概念。從IEEE對于基線的定義中我們可以發現，基線是和變更控制緊密相連的。也就是說在對各個SCI做出了識別，并且利用工具對它們進行了版本管理之后，如何保證它們在復雜多變得開發過程中真正的處于受控的狀態，并在任何情況下都能迅速的恢復到任一歷史狀態就成為了軟件配置管理的另-重要任務。因此，變更控制就是通過結合人的規程和自動化工具，以提供一個變化控制的機制。
在本文的前面的部分中，已經把SCI分為 基線配置項和非基線配置項兩大類，所以這里所涉及的變更控制的對象主要指配置庫中的各基線配置項。

變更管理的一般流程是:

A) 提出變更請求;
B)由CCB審核并決定是否批準;
C) (被接受) 修改請求分配人員為，提取SCI， 進行修改;
D)復審變化;
E)提交修改后的SCI;
F)建立測試基線并測試;
G)重建軟件的適當版本;
H)復審(審計)所有SCI的變化;
|)發布新版本。

5.配置狀態報告

配置狀態報告應根據報告應著重反映當前基線配置項的狀態，以作為對開發進度報告的參照。同時也能從中根據開發人員對配置項的操作記錄來對開發團隊的工作關系作一定的分析。
配置狀態報告應該包括下列主要內容:
(1)每個受控配置項的標識和狀態。一旦配置項被置于配置控制下，就應該記錄和保存它的每個后繼進展的版本和狀態。
(2)每個變更申請的狀態和已批準的修改的實施狀態。
(3)每個基線的當前和過去版本的狀態以及各版本的比較。
(4)其他配置管理過程活動的記錄。
?

6. 配置審計

配置審計(Configuration Audit)也稱配置審核或配置評階，包括功能配置審計和物理配置審計，分別用以驗證當前配置項的一-致性 和完整性。

配置審計的實施是為了確保項目配置管理的有效性，體現了配置管理的最根本要求一-不允許出現任何混亂現象，例如:

• 防止向用戶提交不適合的產品，如交付了用戶手冊的不正確版本。
• 發現不完善的實現，如開發出不符合初始規格說明或未按變更請求實施變更。找出各配置項間不匹配或不相容的現象。
• 確認配置項已在所要求的質量控制審核之后納入基線并入庫保存。確認記錄和文檔保持著可追溯性。

1)功能配置審計(Functional Configuration Audit)
??審計配置項的一致性(配置項的實際功效是否與其需求一致)，具體驗證以下幾個方面。

• 配置項的開發已圓滿完成。
• 配置項已達到配置標識中規定的性能和功能特征。---功能和性能
• 配置項的操作和支持文檔已完成并且是符合要求的。

2)物理配置審計(Physical Configuration Audit)
? ?審計配置項的完整性( 配置項的物理存在是否與預期一致)，具體驗證如下幾個方面。

• 要交付的配置項是否存在。
• 配置項中是否包含了所有必需的項目。.

總結

以上是生活随笔為你收集整理的项目配置管理CM(Configuration Management)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。