軟件配置管理（Software Configuration Management，SCM）作爲CMM 2級的一個關鍵域（Key Practice Area，KPA），在整個軟件的開發活動中佔有很重要的位置。正如Pressman所說的：“軟件配置管理是貫穿於整個軟件過程中的保護性活動，它被設計來（1）標識變化，（2）控制變化，（3）保證變化被適當的發現，以及（4）向其他可能有興趣的人員報告變化。” 所以，我們必須爲軟件配置管理活動設計一個能夠融合於現有的軟件開發流程的管理過程，甚至直接以這個軟件配置管理過程爲框架，來再造組織的軟件開發流程。
之前介紹了SCM的一些基本知識，今天我們來分享一下配置管理主要活動及實現方法。
【配置管理策劃/計劃】
在項目策劃/計劃時，CME應當與PM協商確定項目的 《配置管理計劃》，《配置管理計劃》 需考慮內容如下：
-
配置管理工具，如VSS、SVN、ClearCase等，一般應遵從組織標準
-
配置庫結構和權限，一般應在組織標準的基礎上進行裁剪或者定製，典型的配置庫結構示例請參加筆者的後續文章《配置管理漫漫談之典型配置庫結構》
-
CCB的層次、組成、權限，一般應結合項目情況根據組織標準進行定製
-
配置項識別及標識，一般應遵從組織標準，常見配置項標識規範請參見筆者的後續文章《配置管理漫漫談之標識規範》
-
配置管理活動，一般應結合項目情況根據組織標準進行裁剪確定項目使用的配置管理活動
-
配置管理活動進度安排，應根據項目進度計劃確定各項配置管理活動如基準建立、產品發佈、配置審計等的進度安排
“配置管理計劃”完成後，應由PM審覈後隨項目管理計劃一起提交評審，評審後建立基準並指導項目配置管理活動。
項目進行過程中，CME應根據項目情況調整《配置管理計劃》，調整標準見【基準變更控制】活動中的描述。
【配置管理系統建立】
CME應根據 《配置管理計劃》 建立配置管理系統，如配置管理系統在《配置管理計劃》之前建立，則需根據《配置管理計劃》進行調整。
建立配置管理系統應包括以下內容：
-
配置管理服務端環境：指配置管理服務器的安裝、配置，配置庫結構的實現，需要考慮不同情況下的配置管理服務端環境，異地開發和同地開發的配置管理服務器環境一般是不一致的
-
配置管理客戶端環境：指導項目成員使用相同版本的配置管理客戶端並對客戶端使用進行培訓
-
配置管理環境維護計劃：對配置管理環境的維護計劃，主要針對服務端，重點在於備份策略
一般來說，組織應設立專人處理配置管理系統建立和維護的問題，以便提高效率。
【基準建立】
CME應根據《配置管理計劃》建立基準，基準的建立一般步驟如下：
-
相應配置項負責人將經過 評審/測試/覈准 的配置項提交給CME
-
CME對配置項進行審計
-
CME將配置項提交給相應級別的CCB審批
-
CME將配置項放入受控庫(受控庫的概念請參見筆者之前的文章《配置管理漫漫談之SCM基本知識》，受控庫的實例請參見筆者的文章《配置管理漫漫談之典型配置庫結構》)並進行標識
-
CME維護配置狀態記錄(維護內容參見本文的【配置狀態記錄維護和發佈】一節)
-
CME發佈基準建立通知
基準建立後的配置項將指導後續的開發/管理工作，並需對這些配置項進行監控以應對變更。
【基準變更控制】
當需要變更基準時，應由相應配置項負責人提出變更請求，CME負責跟蹤和管理變更的執行過程、跟蹤變更請求狀態直至變更結束
，確保變更後的內容只有在經過 評審/測試/覈准 後才生效。基準變更的一般步驟如下：
-
相應配置項負責人向PM提出變更請求，說明變更原因
-
PM指定相關人員對變更影響請求進行分析，分析內容一般爲變更對範圍、規模、工作量、質量等的影響
-
PM將分析結果提交相應級別CCB審批
-
如CCB認爲可以變更，則由PM指定相關人員實施變更；如CCB認爲不可變更，則變更結束
-
變更完成後的配置項需進行 評審/測試/審覈 通過後提交CME
-
CME對配置項進行審計
-
CME將配置項放入受控庫並進行標識
-
CME維護配置狀態記錄(維護內容參見本文的【配置狀態記錄維護和發佈】一節)
-
CME發佈基準變更通知
基準變更後後的配置項將指導後續的開發/管理工作，並需對這些配置項進行監控以應對變更。
【產品創建】
產品創建的一般步驟如下：
-
CME根據《產品發佈計劃》從受控庫取出相應的配置項版本進行加工(如Build)
-
CME對加工後的配置項進行審計
-
CME將經審計的待發布產品放入靜態庫(靜態庫的概念請參見筆者之前的文章《配置管理漫漫談之SCM基本知識》，靜態庫的實例請參見筆者的文章《配置管理漫漫談之典型配置庫結構》)並進行標識
-
CME維護配置狀態記錄(維護內容參見本文的【配置狀態記錄維護和發佈】一節)
-
PM根據《產品發佈計劃》進行(內部/外部)產品發佈
-
CME發佈產品發佈通知
用於創建產品的配置項必須從受控庫取出，以保證正確性。
【配置審計】
配置審計不同於SQA針對配置管理活動進行的配置管理過程審計，由CME執行，審計對象是工作產品/配置項，審計重點爲完整性、一致性、正確性。
配置審計的目的是配置管理員要確保配置庫中的配置項和基準的完整性、一致性和正確性，這就是CMMI配置管理SP3.2所提到的概念。在開發庫中的配置項是不需要進行審計的，一旦帶有缺陷的配置項進入受控庫，將有可能給項目帶來很大的負面影響。 配置審計一般分爲功能配置審計(Functional Configuration Audit)和物理配置審計(Physical Configuration Audit )。
物理配置審計驗證已構建出的配置項符合定義和描述它的技術文檔，重點在於配置項的完整性，如配置項包含的工作產品是否存在？配置項的標識是否正確等。
功能配置審計驗證配置項的開發已經被完全滿足的審計行爲，即驗證配置項已經達到了在功能或已分配的配置標識中刻畫的性能和功能特性，並且其運行和支持文檔是完整的和滿意的，重點在於一致性和正確性，主要表現爲配置項的對應關係是否正確，如詳細設計是否對應了概要設計、相應的變更請求是否全部被執行、待發布版本是否與發佈計劃內容一致、數據庫配置是否與需求一致等等重點還在於工作產品與需求的一致性。
物理配置審計的範圍是開發配置項和基準配置項，功能配置審計的範圍是基準配置項。
物理配置審計一般由CME獨立完成，功能配置審計一般由CME藉助評審、測試等活動的結果完成。
物理審計的方法：
根據《配置審計檢查單》去檢查，該有的配置項是否都有了？文件命名與計劃中的命名規則是否一致？存放位置與計劃是否一致？版本設置與計劃中的版本設置規則是否一致？控制權限是正確？
功能審計的方法：
a) 檢查與需求的一致性、完整性：根據《需求追蹤矩陣》對配置庫的基準項進行檢查，看看所有需求是否都已經不多不少地被實現了？並納入了基準庫？如果物理審計中基準項的審計沒有問題，我們也可以通過《需求追蹤矩陣》對《配置狀態報告》中基準項進行檢查，看看所有需求是否都已經不多不少地被實現了？
b) 驗證工作產品與需求的符合程度：查看所有基準項評審和測試報告，看看所有的基準項是否都已經通過各級評審及測試？
c) 交付給客戶的文檔與軟件的功能一致性：檢查交付客戶的文檔是否與當前最新的基準中的需求一致
【配置狀態記錄維護和發佈】
CME在執行配置管理活動時需進行記錄以保證其可追溯性。其內容包括：
-
配置管理記錄維護：需要被記錄的配置管理活動及內容如下：
-
基準建立情況：記錄基準建立時間、基準版本、基準(變更)內容、提交者、配置者、變更請求編號
-
變更請求情況：變更請求編號、變更來源、變更對象(含變更內容、變更前後版本)、變更影響分析、變更實施日期
-
配置審計情況：審計日期、審計時機、審計對象(含版本)、審計不符合項、不符合項類別、不符合項糾正情況
-
配置狀態報告發布：CME應每週/月發佈配置狀態報告，以便高層管理者、SQA、PM、項目成員及其它受影響的組織/個人通過配置狀態瞭解項目狀態。報告內容主要爲受控庫，報告內容應側重於報告週期內基準建立、變更、產品發佈情況及相應的統計分析。
對於基準建立和基準變更都需要記錄基準建立情況，基準變更需要額外記錄變更請求跟蹤情況。基準變更的本質是變更請求流程+基準建立流程，兩者通過 變更請求編號 進行關聯。
配置管理工作是貫穿整個項目生命週期的核心基礎工作之一，只有利用配置管理的理論把項目條理化、清晰化，才能將如需求、設計、開發、測試等其他工作納入正確的軌道，保證整個項目的順利進行。配置管理策劃/計劃是實施其它配置管理活動的前提條件，基準建立和基準變更控制是配置管理的核心工作，配置管理活動提供的狀態報告和數據統計也爲軟件度量提供了決策依據。配置管理活動爲項目管理提供了各種監控項目進展的視角，爲項目經理確切掌握項目進程提供了保證。配置管理也爲開發人員提供了一個協作的平臺，在此平臺上，大家能夠更有效率的交流和協作。可以說，配置管理活動是軟件開發的基石！