1、1 基本概念基本概念 2 配置管理的目的 配置管理的基本概念 配置管理的職責劃分 配置管理的活動3配置管理過程的目的是：配置管理活動是有計劃的計劃中要確定工作產品的基線通過變更控制和配置審計來建立和維護工作產品的完整性。4 CM：配置管理（Configuration Management）是指對項目生存期過程中的各階段產品和最終產品演化和變更的管理。 CCB：變更控制組（Change Control Board）是配置項變更的監管組織。 配置項：配置項：指哪些應該納入配置管理之下，成為受控的工作產品最小單位項。 基線：基線：基線是經過正式評審和認可，作為后續工作依據的配置項集合。 配置審計：配

2、置審計：配置審計主要是驗證配置項的完整性和配置項的一致性。5角角 色色職責職責CCB批準建立基線和標識配置項。批準基線的發布。評審與批準基線的更改。批準由基線庫生成產品。項目經理協助配置管理員制定配置管理計劃。定義基線和配置項。提出發布申請。推動項目的配置管理工作。項目組成員提交配置項產品。針對變更（修改，新增，刪除等），提交配置變更申請表。配置管理員制定和維護配置管理計劃。建立和維護配置管理系統。標識配置項。發布基線。執行基線審計。標識、保存并分發配置狀態報告。從基線庫發布產品。質量保證人員（QA）按照計劃和過程檢查配置管理活動及其工作產品。報告檢查中發現的問題，追蹤問題直至關閉。6活動1：

3、制定配置管理計劃及計劃審批7配置管理計劃內容： CCB組成 配置管理工具 配置庫結構及訪問權限 變更項的檢入頻率 配置項標識規則 識別出的配置項和基線 變更流程 配置審計和狀態報告機制 配置庫備份方案8 CCB組一般由中層經理、項目經理、關鍵的開發人員、測試經理、配置管理員、質量保證人員和客戶代表等有關人員組成。 CCB組長一般由中層經理擔任，中層經理可授權給項目經理，但是中層經理要承擔責任。 9 項目經理與配置管理員一起確定配置庫結構。一般情況下，配置管理庫分為三個區： 開發區：供開發人員使用的配置區。 受控區：保存已被批準的配置項（包括基線）或項目統一管理的過程資產記錄。 產品區：將通過系

4、統測試后的產品作為最終產品存放，等待交付客戶運行和現場測試。10開發區、受控區合二為一，通過標簽來識別受控項目錄結構包括： 源程序 模塊A 模塊B 模塊C 文檔需求、設計、手冊、產品集成、測試、各種計劃、對外接口、其它 工具MACSV的控制器程序和SmartPro共用11 產品區單獨分開，存放在空間較大的服務器上。 產品區存放的內容包括：安裝盤制作安裝盤所用的工程發布單及相關的發布資料映像文件安裝文件 產品區由配置管理員管理與維護。12 配置服務器口令由配置管理員或指定人員掌握。 不同角色的人員對配置庫的訪問權限不同。 產品區只有CM人員有讀寫權，其他人只能查看。 受控區和開發區合二為一，其中

5、的內容，根據需要分配權限。一般情況下，一個模塊由一個人負責維護。 核心資產建一個單獨的構件 一個項目的公共服務建一個構件構件的內容：需求、設計、代碼、變更記錄、構建腳本13 一般情況下，建議配置管理控制的最小層次是：程序模塊文件或文檔，也就是說，一個程序模塊所包含的各個文件不單獨進入配置管理的范圍，只作為程序模塊整體的一部分被增加、刪除或更新。 14 例1：一個數據庫創建腳本，由一個目錄下的多個sql文件組成，這些sql文件被作為一個整體看待。例2：將項目的需求庫中的每個需求文檔看作為一個配置項。 15 對于基線產品，當發布基線和變更基線時必須將配置項檢入； 對于非基線產品，在階段結束時必須將

6、配置項檢入； 對于代碼，建議一周至少要檢入一次。16 在配置管理計劃中，要識別出項目可能的配置項配置項“是什么”、“什么時候置于配置管理之下”包含多個文件的配置項要定義“由什么組成”可以使用一個說明性的readme文件或配置項清單文件來反映每個配置項所包含的內容 17 基線就是經過正式評審和認可的工作產品它作為以后進一步開發的基礎只有通過正式的變更控制流程才能對它進行變更如果控制要求嚴格，則定義多條基線如果控制相對不太嚴格，則可只定義一條需求基線18常見基線需求分析軟件設計 編碼 測試 運行系統測試計劃、流程、測試數據代碼設計軟件需求客戶需求19推薦的基線基線基線何時建立何時建立控制者控制者需

7、求進入設計環節之前 CCB設計進入測試環節之前 CCB產品進入現場試用環節前CCB20 制定配置管理活動計劃列表，明確執行配置管理活動的時間點2122活動2： 創建和維護配置庫23按照計劃建立配置庫，并分配相應的訪問權限。定期（至少每月一次）檢查配置庫的訪問權限分配情況，及時收回無權限人員擁有的權限。檢查配置庫，及時發現和糾正非法操作。不定期變更配置庫訪問口令，以免口令的泄密。及時刪除不再需要的、廢除的配置項。24活動3： 發布基線和打標簽25提出發布申請，填寫基線版本發布版本描述文件配置審計、生成審計報告提交質量審核、CCB審批項目經理解決測試問題 完成發布項目經理配置管理員開始結束NOye

8、s26發布基線前一定要給相應的配置項的正確版本打標簽，打完標簽后，要把標簽鎖上，以防止他人對標簽進行修改，避免造成混亂。也可以對某些中間版本打標簽。創建標簽時要說明標簽的用途。27活動4： 變更控制28非基線產品的變更由項目經理控制：變更申請人提出變更請求，項目經理確認后即可對通知配置管理員開通權限，進行修改。配置管理員開通權限，如果配置項升版，則需對原版本打標簽。變更實施人修改配置項時，應記錄修改信息，修改完成后通知配置管理員收回權限。添加或刪除配置項時，應通知配置管理員。配置管理員更新配置項狀態清單。29變更控制-流程圖基線產品的變更控制30基線產品的變更：變更申請人向項目經理提交變更申請

9、表。項目經理對變更申請進行初步審核后，提交給CCB評審。CCB組織評估其影響，然后審批，指定變更實施人，并把配置變更申請表交給配置管理員。配置管理員將批準的配置變更申請表納入配置管理庫變更實施人員完成修改后，由指定的人員進行驗證。配置管理員更新基線，保證基線產品中的配置項均已被check in，鎖定需要進行變更的基線及其產品，提升基線到變更狀態（即，將基線版本升級）。配置管理員填寫配置項狀態清單表，并將變更情況通知相關人員。31活動5： 創建版本分支32 當一個新的功能版本衍生時，項目經理要寫一個說明給配置管理員，說明要創建一個版本分支，創建分支的目的是什么，以主線上的哪個版本為基礎創建分支，

10、分支與主線的關系，以及將在什么時間點與主線合并，誰在分支上工作。33不建議創建太多分支。分支多會造成管理的混亂和困難。分支多，合并的工作量就會很大。如果建了很多分支，而不進行合并，開發人員維護分支的工作量就很大。34版本規劃是項目經理（實際上是產品經理）的重要職責。版本規劃決不是配置管理員所能作好的。35活動6： 配置審計和狀態報告36配置審計的目的是，維護配置基線的完整性。配置審計由CM人員按照計劃定期執行。配置審計在基線的重大變更前或者里程碑處進行隨著項目的進展，審計工作頻率和深度會逐步增加。37功能審計：確認基線配置項標識的正確性。驗證基線的完備性。完備性是指該有的都有。驗證基線的完整性。（完備性和一致性）驗證基線產品內容的正確性。檢查評審記錄，確認評審中發現的問題確實在相應的文件中進行了修改。38物理審計：確認應受控配置項和基線的更改是受控的驗證配置管理系統與系統備份的有效性和一致性驗證配置管理活動與相應記錄之間的一致性驗證配置管理工作是否符合適用的標準和過程39 配置管理員審計前準備基線審計檢查表 根據檢查表進行審計 更新和完善配置項狀態表 將審計結果記