1、基于CMM和CMMI的配置管理（一）1 配置管理內容的邏輯關系在CMM和CMMI中，將配置管理的目的定義為“建立和維護產(chǎn)品的完整性”，這個目標沒有提到對項目管理的支持，也就是說，它定義的配置管理的目標比當前業(yè)界對配置管理的認識有些縮小。但是，仔細分析可以發(fā)現(xiàn)“建立和維護產(chǎn)品的完整性”是其他配置管理目標的基礎。下面就從這個目標出發(fā)進行分析。邏輯關系見下圖：配置完整性（對標準的理解）1. 產(chǎn)品完整性：就是項目提交的工作成果是“產(chǎn)品集合完整、子產(chǎn)品的正確”的2. 產(chǎn)品集合完整：產(chǎn)品包含的子產(chǎn)品（配置項）是完整的3. 子產(chǎn)品的正確：子產(chǎn)品（配置項）達到了需求要求，滿足標準、規(guī)程的要求邏輯關系分析1.

2、“基線管理”支持“產(chǎn)品集合完整”，明確產(chǎn)品的“子產(chǎn)品”（配置項）集合，并進行管理和控制2. “配置項管理”，提供了了對子產(chǎn)品（配置項）的控制管理，支持“子產(chǎn)品的正確”3. “變更管理”，同時支持“產(chǎn)品集合完整、子產(chǎn)品的正確”，用于控制子產(chǎn)品（配置項）和產(chǎn)品（基線）的變更4. “配置標示”，建立對配置項（子產(chǎn)品）的識別、命名，支持“配置項管理”5. “版本控制”，控制配置項（子產(chǎn)品）生命歷程，保留配置項（子產(chǎn)品）演進歷史6. “過程管理”，就是對配置項、基線的建立、變更的狀態(tài)標示、過程控制，保證產(chǎn)品（或子產(chǎn)品）按照規(guī)定的流程進行了操作；例如“配置項”進入“基線”的過程包括：配置項標示、產(chǎn)品驗證、

3、進入配置、配置審計等7. “配置計劃”、“配置庫管理”、“配置審計”、“配置報告”等是整個配置管理得支持系統(tǒng)。提供了配置管理“可視性”和監(jiān)督管理2 配置和配置項在配置管理中，“配置”和“配置項”是重要的概念，“配置”是在技術文檔中明確說明并最終組成軟件產(chǎn)品的功能或物理屬性。因此“配置”包括了即將受控的所有產(chǎn)品特性，其內容及相關文檔，軟件版本，變更文檔，軟件運行的支持數(shù)據(jù)，以及其他一切保證軟件一致性的組成要素，相對與硬件類配置，軟件產(chǎn)品的“配置”包括更多的內容并具有易變性。受控軟件經(jīng)常被劃分為各類配置項（Configuraion items, CIs），這類劃分是進行軟件配置管理的基礎和前提，C

4、Is是邏輯上組成軟件系統(tǒng)的各組成部分。比如一個軟件產(chǎn)品包括幾個程序模塊，每個程序模塊及其相關文檔和支撐數(shù)據(jù)可能被命名為一個CI。一個系統(tǒng)包括的CIs的數(shù)目是一個與設計密切相關的問題。一個純軟件的CI通常也稱之為軟件配置項（CSCI）?，F(xiàn)在所有的配置管理工具均提供對配置項的管理工具，包括(Check in和Check out機制的 )版本管理和版本標號功能。由于版本和標號管理比較繁瑣，一般推薦使用配置管理工具，減少事務性工作。3 基線在配置管理系統(tǒng)中，基線就是一個CI或一組CIs在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)，而這個過程被稱為“基線化”。每一個基線都是其下一步開發(fā)

5、的出發(fā)點和參考點?；€確定了元素（配置項）的一個版本，且只確定一個版本。一般情況下，基線一般在指定的里程碑處創(chuàng)建，并與項目中的里程碑保持同步一般地，第一個基線包含了通過評審的軟件需求，因此稱之為“需求基線”，通過建立這樣一個基線，受控的系統(tǒng)需求成為進一步軟件開發(fā)的出發(fā)點，對需求的變更被正式初始化、評估。受控的需求還是對軟件進行功能評審的基礎。每個基線都將接受配置管理的嚴格控制，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟件開發(fā)階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線，這就是“基線管理”的過程?；€具有以下屬性：通過正式的評審過程建立基線存在于基線庫中，對基線的變更接

6、受更高權限的控制基線是進一步開發(fā)和修改的基準和出發(fā)點進入基線前，不對變化進行管理或者較少管理進入基線后，對變化進行有效管理，而且這個基線作為后繼續(xù)工作的基礎不會變化的東西不要納入基線變化對其他沒有影響的可以不納入基線建立基線的好處：重現(xiàn)性：及時返回并重新生成軟件系統(tǒng)給定發(fā)布版的能力，或者是在項目中的早些時候重新生成開發(fā)環(huán)境的能力。當認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法?？勺粉櫺裕航㈨椖抗ぜg的前后繼承關系。目的是確保設計滿足要求、代碼實施設計以及用正確代碼編譯可執(zhí)行文件。版本隔離：基線為開發(fā)工件提供了一個定點和快照，新項目可以從基線提供的定點之中建立。作為一個單獨分支

7、，新項目將與隨后對原始項目（在主要分支上）所進行的變更進行隔離。4 基線、配置、配置項的關系基線的組成，以及配置項和配置的關系如下圖：基線管理的步驟：1、在開發(fā)前確定基線的“配置”2、基線批準前，根據(jù)“配置”檢查配置項是否齊備3、對各個配置項，確認其版本的正確性4、對每個配置項建立基線標志，例如上圖為：測試基線=（配置項A=1，配置項B=1，配置項C=1）alpha版=（配置項A=2，配置項B=1，配置項C=1）beta版=（配置項A=3，配置項B=3，配置項C=2）產(chǎn)品基線=（配置項A=4，配置項B=4，配置項C=4）5、基線變更管理6、基線的各類報告和審計信息針對某個具體得項目，可以根據(jù)基

8、線的內容，建立一個基線信息的跟蹤表，例如如下：注：被色塊覆蓋的表示，此配置項屬于對應列的基線注：在色塊的欄目填寫對應配置項的版本號5 變更管理在有效標示了配置并進行了管理之后，如何保證它們在復雜多變得開發(fā)過程中真正的處于受控的狀態(tài)，并在任何情況下都能迅速的恢復到任一歷史狀態(tài)就要依賴有下的變更管理。缺乏有效的變更請求管理會導致的問題：軟件產(chǎn)品質量低下，對一些缺陷的修正被遺漏項目經(jīng)理不了解開發(fā)人員的工作進展，缺乏對項目現(xiàn)狀進行客觀評估的能力開發(fā)人員不了解手頭工作的優(yōu)先級別，可能出現(xiàn)將緊急的事情放在一邊、而工作在一般優(yōu)先級任務上的情況可能錯誤使用和引用已經(jīng)變更的產(chǎn)品，引起開發(fā)工作混亂變更管理的流程：

9、（獲得）提出變更請求；由CCB審核并決定是否批準；為（被接受）修改請求分配人員，提取SCI，進行修改；提交修改后的SCI，并測試（或者評審）；重建軟件的適當版本；復審（審計）所有SCI的變化；發(fā)布新版本。 為了更好的指導變更范圍的影響分析，可以通過兩種表格來幫助發(fā)現(xiàn)受到變更影響的內容，一種是需求跟蹤表，一種是配置項依賴關系表，分別如下：6 配置庫管理在實際的開發(fā)活動中系統(tǒng)中，為了讓每個開發(fā)人員和各個開發(fā)團隊能更好的分工合作，同時又互不干擾，必須規(guī)劃好工作空間的管理。主要的手段是設置配置庫（即文件夾設置），和設置版本的分支，來實現(xiàn)對配置項權限管理。書簽設置版本分支基本上要為每個配置項從建立開始就

10、劃分成3個不同的分支：私有分支、集成分支、公共（主干）分支。讓它們分別對應3類工作空間。私有分支：私有分支對應的是開發(fā)人員的私有開發(fā)空間。開發(fā)人員根據(jù)任務分工獲得對相應配置項的操作許可之后，他即在自己的私有開發(fā)分支上工作，他的所有工作成果體現(xiàn)為在該配置項的私有分支上的版本的推進，除該開發(fā)人員外，其他人員均無權操作該私有空間中的元素。集成分支：集成分支對應的是開發(fā)團隊的公共空間。凡是要為同組人員共享的配置項都從該分支獲得。即各開發(fā)人員必須將私有工作空間中的開發(fā)成果歸并（Merge）到該分支后才能進入下一個開發(fā)活動。所有涉及多人協(xié)調的開發(fā)工作（如集成測試等）都必須工作在這一空間中。該開發(fā)團隊擁有對

11、該集成分支的讀寫權限，而其他成員只有只讀權限。該分支的管理工作由系統(tǒng)集成員及相關指定人員負責。 公共（主干）分支：公共分支對應的是整個軟件開發(fā)組織的公共空間。各個開發(fā)小組在現(xiàn)階段的任務完成后，將可以發(fā)布的版本歸并到該分支上，將來需要查閱相關資料時，以該分支上的版本為準。該分支對組織內的全體軟件人員開放只讀權限。該分支的管理工作由系統(tǒng)集成員負責。 上面定義的3類工作空間（分支）由配置管理員統(tǒng)一管理，根據(jù)各開發(fā)階段的實際情況定制相應的版本選取規(guī)則，來保證開發(fā)活動的正常運作。在變更發(fā)生時，應及時做好基線的推進。配置庫的設置決定配置庫的結構是配置管理活動的重要基礎。一般常用的是兩種組織形式：按配置項類

12、型分類建庫和按任務建庫。按配置項的類型分類建庫的方式經(jīng)常為一些咨詢服務公司所推薦，它適用于通用的應用軟件開發(fā)組織。這樣的組織一般產(chǎn)品的繼承性較強，工具比較統(tǒng)一，對并行開發(fā)有一定的需求。使用這樣的庫結構有利于對配置項的統(tǒng)一管理和控制，同時也能提高編譯和發(fā)布的效率。但由于這樣的庫結構并不是面向和各個開發(fā)團隊的開發(fā)任務的，所以可能會造成開發(fā)人員的工作目錄結構過于復雜，帶來一些不必要的麻煩。而按任務建立相應的配置庫則適用于專業(yè)軟件的研發(fā)組織。在這樣的組織內，使用的開發(fā)工具種類繁多，開發(fā)模式以線性發(fā)展為主，所以就沒有必要把配置項嚴格的分類存儲，人為增加目錄的復雜性。因此，筆者認為特別是對于研發(fā)性的軟件組

13、織來說，還是采用這種設置策略比較靈活。配置庫的日常工作配置庫的日常工作是一些事務性的工作，主要保證配置庫的安全性，包括：對配置庫的定期備份清除無用的文件和版本檢測并改進配置庫的性能等7 配置報告配置狀態(tài)報告就是根據(jù)配置項操作的記錄來向管理者報告軟件開發(fā)活動的進展情況。這樣的報告應該是定期進行，并盡量通過CASE工具自動生成，用數(shù)據(jù)庫中的客觀數(shù)據(jù)來真實的反映各配置項的情況。配置狀態(tài)報告應著重反映當前基線配置項的狀態(tài)，以作為對開發(fā)進度報告的參照。為了說明項目狀態(tài)對變更的情況也應當進行報告。有時，對配置庫的情況也進行說明，例如備份次數(shù)，磁盤占用空間等等。只要是關心的信息，均可作為狀態(tài)報告的內容。這些

14、信息進行有效記錄，往往可以作為項目度量的重要數(shù)據(jù)來源。8 配置審計配置審計的主要作用是作為變更控制的補充手段，來確保某一變更需求已被切實實現(xiàn)。在某些情況下，它被作為正式的技術復審的一部分，但當軟件配置管理是一個正式的活動時，該活動由SQA人員單獨執(zhí)行。 審計機制保證修改的動作被完整地記錄，也就是說，記錄了誰修改了這個工件，什么時候做的修改，為什么原因做出這個改動，以及修改了哪些地方。 在版本控制過程中，如果利用一些配置管理工具（或者版本控制工具）的支持，則可以自動地記錄審計工作所需的四個“W”（Who、When、Why、What）。 同時配置審計工作應當可以說明如下信息。 配置審計應當說明的信

15、息：1. 變更要求被完成，并且對附加的修改已經(jīng)執(zhí)行了2. 采用了正確的正式驗證手段3. 遵循了標準的要求4. 變更的4W信息被完整記錄，并和相關配置項關聯(lián) 9 項目實施指南一個軟件研發(fā)項目一般可以劃分為三個階段：計劃階段、開發(fā)階段和維護階段。然而從軟件配置管理的角度來看，后兩個階段所涉及的活動是一致，所以就把它們合二為一，成為“項目開發(fā)和維護”階段。一個項目設立之初項目經(jīng)理首先需要制定整個項目的計劃，它是項目研發(fā)工作的基礎。在有了總體研發(fā)計劃之后，軟件配置管理的活動就可以展開了，因為如果不在項目開始之初制定軟件配置管理計劃，那么軟件配置管理的許多關鍵活動就無法及時有效的進行，而它的直接后果就是

16、造成了項目開發(fā)狀況的混亂并注定軟件配置管理活動成為一種“救火”的行為。所以及時制定一份軟件配置管理計劃在一定程度上是項目成功的重要保證。在“開發(fā)階段和維護階段”，軟件配置管理活動主要分為三個層面，這三個層面是彼此之間既獨立又互相聯(lián)系的有機的整體。（1） 主要由配置人員完成的管理和維護工作；（2） 由系統(tǒng)集成員和開發(fā)人員具體執(zhí)行軟件配置管理策略；（3） 變更流程。 軟件階段活 動 活動說明計劃階段制定軟件計劃一個項目設立之初，項目經(jīng)理首先需要制定整個項目的計劃確定配置策略配置管理委員會（CCB）根據(jù)項目的開發(fā)計劃確定各個里程碑和開發(fā)策略制定配置計劃配置人員根據(jù)CCB的規(guī)劃，制定詳細的配置管理計劃

17、，交CCB審核批準配置計劃CCB通過配置管理計劃后交項目經(jīng)理批準，發(fā)布實施開發(fā)階段和維護階段確定初始基線CCB設定研發(fā)活動的初始基線配置庫管理配置人員根據(jù)軟件配置管理規(guī)劃設立配置庫和工作空間，為執(zhí)行軟件配置管理做好準備；并定期進行備份和清理工作授權開發(fā)開發(fā)人員按照統(tǒng)一的軟件配置管理策略，根據(jù)獲得的授權的資源進行項目的研發(fā)工作集成系統(tǒng)集成員按照項目的進度集成組內開發(fā)人員的工作成果，并構建系統(tǒng)，推進版本的演進管理基線CCB根據(jù)項目的進展情況，并適時的建立基線，批準基線變更，保證開發(fā)和維護工作有序的進行。產(chǎn)品發(fā)布系統(tǒng)集成員進行產(chǎn)品集成，由CCB批準，進行發(fā)布其 他配置會議CCB定期舉行例會，根據(jù)成員

18、所掌握的情況、配置人員的報告和開發(fā)人員的請求，對配置管理計劃作出修改，并向項目經(jīng)理負責。配置報告和審計配置人員定期向項目經(jīng)理和CCB提交審計報告，并在配置管理例會中報告項目在軟件過程中可能存在的問題和改進方案變更管理事件觸發(fā)執(zhí)行，由CCB批準、項目組執(zhí)行，并執(zhí)行審計10 配置管理部署模型基本過程 序號 階段活動備注1獲得相應管理權1.1建立相應負責團隊1.2獲得授權和資源可召開啟動會2評估配置管理現(xiàn)狀2.1繪制和評估當前過程的控制圖可采用CMM標準2.2了解員工對配置管理的態(tài)度2.3了解組織的配置管理技術水平2.4了解領導期望2.5編制并評審評估報告獲得“現(xiàn)狀信息”3配置工具選擇3.1編制、評

19、審評估評分表3.2評估配置工具和供貨商3.3收集其他用戶的使用經(jīng)驗4配置過程定義制定配置管理過程草案4.1利用“現(xiàn)狀信息”和收集的經(jīng)驗4.2制定新的過程4.3評審新過程，并建立新的過程基線5試點5.1選定試點項目5.2確定試點負責小組5.3定義試點成功標準和進度5.4試點項目人員培訓5.5試點改進同時對草案進行改進5.6試點總結/推廣完成正式過程的發(fā)布6全面實施6.1組建相應部門和團隊6.2制定各個項目的實施計劃6.3配置管理知識、過程、工具的培訓6.4幫助各個項目向新過程遷移6.5日常監(jiān)督、抽查、溝通7 結束總結、獎勵相應操作文件 對應過程：2.2了解員工對配置管理的態(tài)度建立一個CHECKL

20、IST，來進行調研，如下 序號 調查內容調查結果1原來是否有過類似嘗試，成功或者失敗了2是否有由于配置管理不好造成的痛苦經(jīng)歷3對建立配置管理過程是否支持4是否覺得配置管理過程會壓抑創(chuàng)造性5是否覺得配置管理過程太繁瑣6對配置管理是否有不合理的期望7是否有些急功近利8是否對實施配置管理工具感興趣9個人英雄主義和分工協(xié)作那個是主流對應過程：2.3了解組織的配置管理技術水平建立一個CHECKLIST，來進行調研，如下 序號 調查內容調查結果1是否已經(jīng)有了配置管理過程，運作時間2是否使用了配置管理工具，使用時間3是否接受了配置管理的專門培訓，培訓時間4對配置管理過程的認識程度5對配置管理工具的使用程度6企業(yè)員工的基本素質和學習能力對應過程：3.2評估配置工具供應商建立一個CHECKLIST，來進行調研，如下 序號 調查內容調查結果1工具可以解決當前問題，滿足當前需求嗎？2產(chǎn)品的市場地位3產(chǎn)品價格4與現(xiàn)有環(huán)境的兼容程度5運行能力（峰值情況、成熟性、穩(wěn)定性）6是否支持未來需求7是否具備：工作空間管理8是否具備：版本控制9是否具備：配置報告10是否具備：過程支持11是否具備：安全和保護12是否具備：工具集成13是否具備：構造支持14是否具備：圖形界面15是否具備：自定義支持16是否具