1、1, 基本概念,配置管理培訓,工程技術中心應用軟件質控部 徐麗君,2,課程內容,配置管理的目的 配置管理的基本概念 配置管理的職責劃分 配置管理的活動,3,配置管理目的,配置管理過程的目的是： 配置管理活動是有計劃的 計劃中要確定工作產品的基線 通過變更控制和配置審計來建立和維護工作產品的完整性。,4,配置管理的基本概念,CM：配置管理（Configuration Management）是指對項目生存期過程中的各階段產品和最終產品演化和變更的管理。 CCB：變更控制組（Change Control Board）是配置項變更的監(jiān)管組織。 配置項：指哪些應該納入配置管理之下，成為受控的工作產品最小

2、單位項。 基線：基線是經(jīng)過正式評審和認可，作為后續(xù)工作依據(jù)的配置項集合。 配置審計：配置審計主要是驗證配置項的完整性和配置項的一致性。,5,配置管理的職責劃分,6,配置管理活動,活動1：制定配置管理計劃及計劃審批,7,配置管理計劃內容： CCB組成 配置管理工具 配置庫結構及訪問權限 變更項的檢入頻率 配置項標識規(guī)則 識別出的配置項和基線 變更流程 配置審計和狀態(tài)報告機制 配置庫備份方案,8,CCB組成,CCB組一般由中層經(jīng)理、項目經(jīng)理、關鍵的開發(fā)人員、測試經(jīng)理、配置管理員、質量保證人員和客戶代表等有關人員組成。 CCB組長一般由中層經(jīng)理擔任，中層經(jīng)理可授權給項目經(jīng)理，但是中層經(jīng)理要承擔責任。

3、,9,配置庫結構,項目經(jīng)理與配置管理員一起確定配置庫結構。 一般情況下，配置管理庫分為三個區(qū)： 開發(fā)區(qū)：供開發(fā)人員使用的配置區(qū)。 受控區(qū)：保存已被批準的配置項（包括基線）或項目統(tǒng)一管理的過程資產記錄。 產品區(qū)：將通過系統(tǒng)測試后的產品作為最終產品存放，等待交付客戶運行和現(xiàn)場測試。,10,開發(fā)區(qū)、受控區(qū)合二為一，通過標簽來識別受控項 目錄結構包括： 源程序 模塊A 模塊B 模塊C 文檔 需求、設計、手冊、產品集成、測試、 各種計劃、對外接口、其它 工具,標簽由配置管理員 創(chuàng)建和維護,MACSV的控制器程序和SmartPro共用,11,配置庫結構,產品區(qū)單獨分開，存放在空間較大的服務器上。 產品區(qū)存

4、放的內容包括： 安裝盤 制作安裝盤所用的工程 發(fā)布單及相關的發(fā)布資料 映像文件 安裝文件 產品區(qū)由配置管理員管理與維護。,12,訪問權限,配置服務器口令由配置管理員或指定人員掌握。 不同角色的人員對配置庫的訪問權限不同。 產品區(qū)只有CM人員有讀寫權，其他人只能查看。 受控區(qū)和開發(fā)區(qū)合二為一，其中的內容，根據(jù)需要分配權限。一般情況下，一個模塊由一個人負責維護。,核心資產建一個單獨的構件,一個項目的公共服務建一個構件,構件的內容： 需求、設計、代碼、變更記錄、構建腳本,13,配置項的粒度,一般情況下，建議配置管理控制的最小層次是： 程序模塊文件或文檔，也就是說，一個程序模塊所包含的各個文件不單獨進

5、入配置管理的范圍，只作為程序模塊整體的一部分被增加、刪除或更新。,14,配置項的粒度,例1：一個數(shù)據(jù)庫創(chuàng)建腳本，由一個目錄下的多個sql文件組成，這些sql文件被作為一個整體看待。 例2：將項目的需求庫中的每個需求文檔看作為一個配置項。,15,變更項的檢入頻率,對于基線產品，當發(fā)布基線和變更基線時必須將配置項檢入； 對于非基線產品，在階段結束時必須將配置項檢入； 對于代碼，建議一周至少要檢入一次。,16,識別配置項,在配置管理計劃中，要識別出項目可能的配置項 配置項“是什么”、“什么時候置于配置管理之下” 包含多個文件的配置項要定義“由什么組成” 可以使用一個說明性的readme文件或配置項清

6、單文件來反映每個配置項所包含的內容,17,基線劃分的原則,基線就是經(jīng)過正式評審和認可的工作產品 它作為以后進一步開發(fā)的基礎 只有通過正式的變更控制流程才能對它進行變更 如果控制要求嚴格，則定義多條基線 如果控制相對不太嚴格，則可只定義一條需求基線,18,常見基線,需求分析,軟件設計,編碼,測試,運行系統(tǒng),測試計劃、流程、測試數(shù)據(jù),代碼,設計,軟件需求,客戶需求,19,推薦的基線,20,配置管理活動計劃,制定配置管理活動計劃列表，明確執(zhí)行配置管理活動的時間點,21,22,配置管理活動,活動2： 創(chuàng)建和維護配置庫,23,創(chuàng)建和維護配置庫,按照計劃建立配置庫，并分配相應的訪問權限。,定期（至少每月一

7、次）檢查配置庫的訪問權限分配情況，及時收回無權限人員擁有的權限。,檢查配置庫，及時發(fā)現(xiàn)和糾正非法操作。,不定期變更配置庫訪問口令，以免口令的泄密。,及時刪除不再需要的、廢除的配置項。,24,配置管理活動,活動3： 發(fā)布基線和打標簽,25,26,發(fā)布基線前一定要給相應的配置項的正確版本打標簽，打完標簽后，要把標簽鎖上，以防止他人對標簽進行修改，避免造成混亂。 也可以對某些中間版本打標簽。 創(chuàng)建標簽時要說明標簽的用途。,打標簽,27,配置管理活動,活動4： 變更控制,28,非基線產品的變更由項目經(jīng)理控制： 變更申請人提出變更請求，項目經(jīng)理確認后即可對通知配置管理員開通權限，進行修改。 配置管理員開

8、通權限，如果配置項升版，則需對原版本打標簽。 變更實施人修改配置項時，應記錄修改信息，修改完成后通知配置管理員收回權限。 添加或刪除配置項時，應通知配置管理員。 配置管理員更新配置項狀態(tài)清單。,變更控制,29,變更控制-流程圖,基線產品的變更控制,CCB,QC驗證人員,30,基線產品的變更： 變更申請人向項目經(jīng)理提交變更申請表。 項目經(jīng)理對變更申請進行初步審核后，提交給CCB評審。 CCB組織評估其影響，然后審批，指定變更實施人，并把配置變更申請表交給配置管理員。 配置管理員將批準的配置變更申請表納入配置管理庫 變更實施人員完成修改后，由指定的人員進行驗證。 配置管理員更新基線，保證基線產品中

9、的配置項均已被check in，鎖定需要進行變更的基線及其產品，提升基線到變更狀態(tài)（即，將基線版本升級）。 配置管理員填寫配置項狀態(tài)清單表，并將變更情況通知相關人員。,31,配置管理活動,活動5： 創(chuàng)建版本分支,32,創(chuàng)建版本分支,當一個新的功能版本衍生時，項目經(jīng)理要寫一個說明給配置管理員，說明要創(chuàng)建一個版本分支，創(chuàng)建分支的目的是什么，以主線上的哪個版本為基礎創(chuàng)建分支，分支與主線的關系，以及將在什么時間點與主線合并，誰在分支上工作。,33,創(chuàng)建版本分支,不建議創(chuàng)建太多分支。 分支多會造成管理的混亂和困難。 分支多，合并的工作量就會很大。 如果建了很多分支，而不進行合并，開發(fā)人員維護分支的工作量

10、就很大。,34,創(chuàng)建版本分支,版本規(guī)劃是項目經(jīng)理（實際上是產品經(jīng)理）的重要職責。 版本規(guī)劃決不是配置管理員所能作好的。,35,配置管理活動,活動6： 配置審計和狀態(tài)報告,36,配置審計,配置審計的目的是，維護配置基線的完整性。 配置審計由CM人員按照計劃定期執(zhí)行。 配置審計在基線的重大變更前或者里程碑處進行 隨著項目的進展，審計工作頻率和深度會逐步增加。,37,配置審計,功能審計： 確認基線配置項標識的正確性。 驗證基線的完備性。完備性是指該有的都有。 驗證基線的完整性。（完備性和一致性） 驗證基線產品內容的正確性。檢查評審記錄，確認評審中發(fā)現(xiàn)的問題確實在相應的文件中進行了修改。,38,配置審計,物理審計： 確認應受控配置項和基線的更改是受控的 驗證配置管理系統(tǒng)與系統(tǒng)備份的有效性和一致性 驗證配置管理活動與相應記錄之間的一致性 驗證配置管理工作是否符合適用的標準和過程,39,配置審計和狀態(tài)報告,配置管理員審計前準備基線審計檢查表 根據(jù)檢查表進行審計 更新和完善配置項狀態(tài)表 將審計結果記錄于基線審計報告中 將配置項狀態(tài)表和基線審計報告