軟體組態管理過程及其關鍵活動 [引]

http://www.51testing.com/html/36/662.html

文章出處：《共創軟體》 作者：PMT 陳越 發布時間：2005-11-10
	隨著軟體產業的崛起，軟體工程技術正吸引著越來越多關注的目光。特別是以CMM為代表的先進的軟體工程理念在國內也正日益受到業界廣泛的重視。   軟體組態管理（Software Configuration Management，SCM）作為CMM 2級的一個關鍵域（Key Practice Area，KPA），在整個軟體的開發活動中佔有很重要的位置。正如Pressman所說的：“軟體組態管理是貫穿於整個軟體過程中的保護性活動，它被設 計來（1）標識變化，（2）控制變化，（3）保證變化被適當的發現，以及（4）向其他可能有興趣的人員報告變化。” 所以，我們必須為軟體組態管理活動設計一個能夠融合於現有的軟體開發流程的管理過程，甚至直接以這個軟體組態管理過程為架構，來再造組織的軟體開發流程。   本文參照了CMM 2級中軟體組態管理的相關的要求，充分考慮了在CASE工具的輔助下實現自動的軟體組態管理的可能性，描述了在一個比較理想的軟體研發組織中軟體組態管理的流程及其關鍵活動。   一． 角色職責   對於任何一個管理流程來說，保證該流程正常運轉的前提條件就是要有明確的角色、職責和許可權的定義。特別是在引入了軟體組態管理的工具之後，比較理想的狀態 就是：組織內的所有人員按照不同的角色的要求、根據系統賦予的許可權來執行相應的動作。因此，在本文所介紹的這個軟體組態管理過程中主要涉及下列的角色和分 工：   專案經理（Project Manager，PM）：   專案經理是整個軟體研發活動的負責人，他根據軟體組態控制委員會的建議批准組態管理的各項活動並控制它們的進程。其具體職責為以下幾項：   制定和修改項目的組織圖和組態管理策略；   批准、發布組態管理計劃；   決定項目起始基準和開發裡程碑；   接受並審閱組態控制委員會的報告。   組態控制委員會（Configuration Control Board，CCB）：   負責指導和控制組態管理的各項具體活動的進行，為專案經理的決策提供建議。其具體職責為以下幾項：   定製開發子系統；   定製存取控制；   制定常用策略；   建立、更改基準的設定，審核變更申請；   根據組態管理員的報告決定相應的對策。   組態管理員（Configuration Management Officer，CMO）：   根據組態管理計劃執行各項管理工作，定期向CCB提交報告，告，並列席CCB的例會。其具體職責為以下幾項：   件組態管理工具的日常管理與維護；   提交組態管理計劃；   各配置項的管理與維護；   執資料列版本設定和變更控制方案；   完成配置審計並提交報告；   對開發人員進行相關的培訓；   識別軟體開發過程中存在的問題並擬就解決方案。   系統整合員（System Integration Officer，SIO）：   系統整合員負責產生和管理項目的內部和外部發布版本，其具體職責為以下幾項：   整合修改；   構建系統；   完成對版本的日常維護；   建立外部發布版本。   開發人員（Developer，DEV）：   開發人員的職責就是根據組織內確定的軟體組態管理計劃和相關規定，按照軟體組態管理工具的使用模型來完成開發工作單位。   二．流程說明   一個軟體研發項目一般可以劃分為三個階段：計劃階段、開發階段和維護階段。然而從軟體組態管理的角度來看，後兩個階段所涉及的活動是一致，所以就把它們合二為一，成為“項目開發和維護”階段。   專案計劃階段：   一個項目設立之初PM首先需要制定整個項目的計劃，它是項目研發工作的基礎。在有了總體研發計劃之後，軟體組態管理的活動就可以展開了，因為如果不在項目 開始之初制定軟體組態管理計劃，那麼軟體組態管理的許多關鍵活動就無法及時有效進行，而它的直接後果就是造成了項目開發狀況的混亂並註定軟體組態管理活 動成為一種“救火”的行為。所以及時制定一份軟體組態管理計劃在一定程度上是項目成功的重要保證。   在軟體組態管理計劃的制定過程中，它的主要流程應該是這樣的：   CCB根據項目的開發計劃確定各個裡程碑和開發策略；   CMO根據CCB的規劃，制定詳細的組態管理計劃，交CCB審核；   CCB通過組態管理計劃後交專案經理批准，發布實施。   項目開發維護階段：   這一階段時項目研發的主要階段。在這一階段中，軟體組態管理活動主要分為三個層面：（1）主要由CMO完成的管理和維護工作；（2）由SIO和DEV具體執行軟體組態管理策略；（3）變更流程。這三個層面是彼此之間既獨立又互相聯絡的有機的整體。   在這個軟體組態管理過程中，它的核心流程應該是這樣的：（1）CCB設定研發活動的初始基準；（2）CMO根據軟體組態管理規劃設立配置庫和工作空間，為 執行軟體組態管理就阿做好準備；（3）開發人員按照統一的軟體組態管理策略，根據獲得的授權的資源進行項目的研發工作；（4）SIO按照項目的進度整合組 內開發人員的工作成果，並構建系統，推進版本的演化；（5）CCB根據項目的進展情況，審核各種變更請求，並適時的劃定新的基準，保證開發和維護工作有序 的進行。   這個流程就是如此迴圈往複，直到項目的結束。當然，在上述的核心過程之外，還涉及其他一些相關的活動和操作流程，下面按不同的角色分工予以列出：   各開發人員按照專案經理發布的開發策略或模型進行工作；   SIO負責將各分項目的工作成果歸併至整合分支，供測試或發布；   SIO可向CCB提出設立基準的要求，經批准後由CMO執行；   CMO定期向專案經理和CCB提交審計報告，並在CCB例會中報告項目在軟體過程中可能存在的問題和改進方案；   在基準生效後，一切對基準和基準之前的開發成果的變更必須經CCB的批准；   CCB定期舉行例會，根據成員所掌握的情況、CMO的報告和開發人員的請求，對組態管理計劃作出修改，並向專案經理負責。     三. 關鍵活動   1．配置項（Software Configuration Item，SCI）識別   Pressman對於SCI給出了一個比較簡單的定義：“軟體過程的輸出資訊可以分為三個主要類別：（1）電腦程式（原始碼和可執行程式），（2）描述 電腦程式的文檔（針對技術開發人員和使用者），以及（3）資料（包含在程式內部或外部）。這些項包含了所有在軟體過程中產生的資訊，總稱為軟體配置項。”   由此可見，配置項的識別是組態管理活動的基礎，也是制定組態管理計劃的重要內容。   軟體配置項分類軟體的開發過程是一個不斷變化著的過程，為了在不嚴重阻礙合理變化的情況下來控制變化，軟體組態管理引入了“基準（Base Line）”這一概念。IEEE對基準的定義是這樣的：“已經正式通過複審核獲批准的某規約或產品，它因此可作為進一步開發的基礎，並且只能通過正式的變化 控制過程改變。”   所以，根據這個定義，我們在軟體的開發流程中把所有需加以控制的配置項分為基準配置項和非基準配置項兩類，例如：基準配置項可能包括所有的設計文檔和來源程式等；非基準配置項可能包括項目的各類計劃和報告等。   配置項的標識和控制   所有配置項都都應按照相關規定統一編號，按照相應的模板產生，並在文檔中的規定章節（部分）記錄對象的標識資訊。在引入軟體組態管理工具進行管理後，這些配置項都應以一定的目錄結構儲存在配置庫中。   所有配置項的操作許可權應由CMO嚴格管理，基本原則是：基準配置項向軟體開發人員開放讀取得許可權；非基準配置項向PM、CCB及相關人員開放。   2．工作空間管理   在引入了軟體組態管理工具之後，所有開發人員都會被要求把工作成果存放到由軟體組態管理工具所管理的配置庫中去，或是直接工作在軟體組態管理工具提供的環 境之下。所以為了讓每個開發人員和各個Team Dev能更好的分工合作，同時又互不干擾，對工作空間的管理和維護也成為了軟體組態管理的一個重要的活動。   一般來說，比較理想的情況是把整個配置庫視為一個統一的工作空間，然後再根據需要把它劃分為個人（私人）、團隊（整合）和全組（公用）這三類工作空間（分支），從而更好的支援將來可能出現的並行開發的需求。   每個開發人員按照任務的要求，在不同的開發階段，工作在不同的工作空間上，例如：對於私人開發空間而言，開發人員根據任務分工獲得對相應配置項的操作許可 之後，他即在自己的私人開發分支上工作，他的所有工作成果體現為在該配置項的私人分支上的版本的推進，除該開發人員外，其他人員均無權操作該私人空間中的 元素；而整合分支對應的是Team Dev的公用空間，該Team Dev擁有對該整合分支的讀寫權限，而其他成員只有唯讀許可權，它的管理工作由SIO負責；至於公用工作 空間，則是用於統一存放各個Team Dev的階段性工作成果，它提供全組統一的標準版本，並作為整個組織的Knowledge Base。   當然，由於選用的軟體組態管理工具的不同，在對於工作空間的配置和維護的實現上有比較大的差異，但對於CMO來說，這些工作是他的重要職責，他必鬚根據各 開發階段的實際情況來配置工作空間並定製相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基準的推進。   3．版本控制   版本控制是軟體組態管理的核心功能。所有置於配置庫中的元素都應自動予以版本的標識，並保證版本命名的唯一性。版本在產生過程中，自動依照設定的使用模型 自動分支、演化。除了系統自動記錄的版本資訊以外，為了配合軟體開發流程的各個階段，我們還需要定義、收集一些中繼資料（Metadata）來記錄版本的輔 助資訊和規範開發流程，並為今後對軟體過程的度量做好準備。當然如果選用的工具支援的話，這些輔助資料將能直接統計出過程資料，從而方便我們軟體流程改善 （Software Process Improvement，SPI）活動的進行。   對於配置庫中的各個基準控制項，應該根據其基準的位置和狀態來設定相應的存取權限。一般來說，對於基準版本之前的各個版本都應處於被鎖定的狀態，如需要對它們進行變更，則應按照變更控制的流程來進行操作。   4．變更控制   在對SCI的描述中，我們引入了基準的概念。從IEEE對於基準的定義中我們可以發現，基準是和變更控制緊密相連的。也就是說在對各個SCI做出了識別， 並且利用工具對它們進行了版本管理之後，如何保證它們在複雜多變得開發過程中真正的處於受控的狀態，並在任何情況下都能迅速的恢複到任一曆史狀態就成為了 軟體組態管理的另一重要任務。因此，變更控制就是通過結合人的規程和自動化工具，以提供一個變化控制的機制。   在本文的前面的部分中，已經把SCI分為基準配置項和非基準配置項兩大類，所以這裡所涉及的變更控制的對象主要指配置庫中的各基準配置項。   變更管理的一般流程是：   A) （獲得）提出變更請求；   B) 由CCB審核並決定是否批准；   C) （被接受）修改請求分配人員為，提取SCI，進行修改；   D) 複審變化；   E) 提交修改後的SCI；   F) 建立測試基準並測試；   G) 重建軟體的適當版本；   H) 複審（審計）所有SCI的變化；   I) 發布新版本。   在這樣的流程中，CMO通過軟體組態管理工具來進行存取控制和同步控制，而這兩種控制則是建立在前文所描述的版本控制和分支策略的基礎上的。   5．狀態報表   組態狀態報告就是根據配置項操作資料庫中的記錄來向管理者報告軟體開發活動的進展情況。這樣的報告應該是定期進行，並盡量通過CASE工具自動產生，用資料庫中的客觀資料來真實的反映各配置項的情況。   組態狀態報告應根據報告應著重反映當前基準配置項的狀態，以作為對開發進度報告的參照。同時也能從中根據開發人員對配置項的操作記錄來對Team Dev的工作關係作一定的分析。   組態狀態報告應該包括下列主要內容：   A) 配置庫結構和相關說明；   B) 開發起始基準的構成；   C) 當前基準位置及狀態；   D) 各基準配置項整合分支的情況；   E) 各私人開發分支類型的分布情況；   F) 關鍵元素的版本演化記錄；   G) 其它應予報告的事項。   6．配置審計   配置審計的主要作用是作為變更控制的補充手段，來確保某一變更需求已被切實實現。在某些情況下，它被作為正式的技術複審的一部分，但當軟體組態管理是一個正式的活動時，該活動由SQA人員單獨執行。   總之，軟體組態管理的對象是軟體研發活動中的全部開發資產。所有這一切都應作為配置項納入管理計劃統一進行管理，從而能夠保證及時的對所有軟體開發資源進 行維護和整合。因此，軟體組態管理的主要任務也就歸結為以下幾條：（1）制定項目的配置計劃；（2）對配置項進行標識；（3）對配置項進資料列版本設定； （4）對配置項進行變更控制；（5）定期進行配置審計；（6）向相關人員報告配置的狀態。   在此，我想特別指出的是：由於軟體組態管理覆蓋了整個軟體的開發過程，因此它是改進我們的軟體過程、提高流程能力成熟度等級的理想的切入點。希望本文所描述的 這個軟體組態管理的角色指派和工作流程能在實踐中不斷地得到完善，從而使我們的軟體開發活動能夠更加有序、高效的進行！