項目管理綜合管理：軟件配置管理

申請免費試用、咨詢電話：400-8352-114

在筆者進行CMMI咨詢時，當問及軟件技術人員什么是“配置管理”的時候，很多人的回答就是“版本管理”，而且很多人都會說出各種各樣的版本管理工具，例如：VSS、TFS、CVS或SVN等等。但這樣的回答是不正確、不全面的。版本管理只是軟件配置管理的一個小的部分，在CMMI中配置管理分為 “配置項和基線的管理”、“變更控制管理”和“基線的完整性”三個部分。 凡是提到軟件“配置管理”（Configuration Management），我會先給它下個定義：“它是軟件工程的核心部分，是CMMI中最基礎的PA”。為什么它會如此重要呢？首先配置管理的工作就是確保軟件項目時時保持條理清晰，隨時想要任何工作產(chǎn)品都可以迅速找到，并且工作產(chǎn)品的內(nèi)容不會出錯，這也就是大家常講的可回溯性、完整性和正確性；其次軟件配置管理活動始終貫穿整個軟件項目的生命周期。因此說軟件配置管理是最基礎、最核心的管理工作一點都不夸張。
　　(一) 軟件配置項
　　在CMMI的“配置管理”過程域CM中SP1.1首先提到的就是“配置項”的概念，在大家開展配置管理工作前應該先識別哪些是本項目的配置項。“配置項”就是配置管理的對象，簡單來講它符合以下任意一個特點：
　　1、 它會被兩個或兩個以上的項目成員共同使用。
　　2、 它會隨著項目的開展而發(fā)生變化。
　　3、 對項目重要的工作產(chǎn)品。
　　4、 一些工作產(chǎn)品之間的關系非常緊密，一個變化其他的就會受到影響。
　　通過以上定義大家會發(fā)現(xiàn)項目中的很多東西都屬于配置項，例如：各種需求文檔、設計文檔等都會經(jīng)常變更；程序的代碼是大家共享的，而且代碼文件之間又有較高的相互依賴性。那大家也許會發(fā)現(xiàn)還有一些工作產(chǎn)品不符合以上定義，例如：各種周報、會議記錄等。這些也是配置項嗎？很顯然，它們不符合以上特點，那么這些工作產(chǎn)品就不屬于配置項的范圍，但有時在進行CMMI實施時，項目組也往往會將其一并進行管理。 既然配置項是“配置管理”的基礎，那么大家還需要給每一個配置項起一個唯一標識，這樣才能夠做到清晰不混淆。舉個例子：“今晚大家一起出去聚餐，到中山一路的‘東北人’吃飯”，這里的‘東北人’餐廳是特指中山一路的，因此這唯一確定了就餐的地點；“我們訂的包房叫‘靠山屯’”，這里具體的就餐房間也被唯一標識了出來，是‘靠山屯’而不是‘瘦狗嶺’；服務員拿來的菜單上每個菜的名字也是唯一的，這樣送上來的菜就不會重樣，當我們吃完結(jié)賬的時候就不會算錯價錢，這些都是典型的唯一標識配置項的例子。假如配置項沒有被唯一識別出來，那么大家去聚會就會找錯地方，點的菜也可能會上錯，結(jié)賬的時候也可能會算錯，那么將是一團糟，因此在項目管理中一定要將識別配置項重視起來。配置項本身的變化可以使用“版本管理”對其進行控制。通常像大家的程序代碼已經(jīng)被各種版本管理工具進行控制，但大家千萬不要忘記對文檔也要進行版本管理。
　　(二) 軟件的基線
　　前面提到“配置項”的其中一個定義就是“配置項可能會隨著項目的開展而發(fā)生變化”，那么單個的配置項是通過版本管理工具進行管理的，每次變化都會產(chǎn)生一個新的版本號。但是對于一組配置項該如何進行管理呢？根據(jù)CMMI配置管理過程域的SP1.3中的要求，這就需要使用基線管理的方法。簡單來講就是將一組配置項拿“線”穿起來作為一個整體進行統(tǒng)一命名，并將其作為一個新的配置項進行管理。在上面聚餐的例子中，最后結(jié)賬時的賬單就是一條基線，它將所有菜肴集中起來一起買單。
　　(三) 配置庫的劃分
　　配置庫就是指各種版本管理工具所創(chuàng)建的用于管理配置項的數(shù)據(jù)庫，也就是大家常用的VSS或CVS等工具創(chuàng)建的數(shù)據(jù)庫或文檔庫。筆者在以往進行的CMMI咨詢時常常發(fā)現(xiàn)項目組對配置庫的目錄結(jié)構(gòu)沒有進行功能的劃分，為了確保項目永遠不會出現(xiàn)混淆，簡單來說按照權限應該將配置庫劃分為三大類：
　　1、 開發(fā)庫
　　2、 受控庫
　　3、 基線庫
　　各種控制庫的劃分是根據(jù)其訪問權限來定義的，在沒有進行CMMI認證的公司，通常項目組的配置庫只起到“開發(fā)庫”的作用。以CMMI配置管理SP1.2中的理論為依據(jù)，“開發(fā)庫”對項目組成員具有比較寬松的“CheckIn”和“CheckOut”的權限。不會給大家的工作帶來不便，根據(jù)大家的需要隨時都可以對其保管的配置項進行各種操作?！笆芸貛臁睂椖拷M成員來說是沒有“CheckIn”和“CheckOut”的權限的。對“受控庫”的操作只能由配置管理員來完成。因為受控庫中存放的是等待評審的文檔或待測試的程序。假如有份文檔要送去評審，會議的主持人已經(jīng)將其進行了分發(fā)，可是這份文檔卻保存在“開發(fā)庫”中，如果這時被別人修改了，那么之前所分發(fā)的文檔就是舊的，那隨后的評審也就沒有意義了，這就是“受控庫”存在的意義。“基線庫”就是對“受控庫”中通過驗證的工作產(chǎn)品所形成的基線進行統(tǒng)一管理，并且新的基線將按照要求發(fā)送給項目的相關人員并與其分享項目的狀態(tài)和信息。大家回想一下以往發(fā)布給客戶的版本是否可以找到全部的程序和文檔，如果找不到那就請從現(xiàn)在開始使用“基線庫”進行管理吧：）
　　(四) 軟件變更管理軟件開發(fā)項目經(jīng)常出現(xiàn)變更，但大家千萬不要對項目中的變更產(chǎn)生恐懼，在項目管理的先進理念中“變化是永恒的，不變是短暫的”，“沒有計劃就沒有變化”。大家應該正視軟件變更的存在，它是軟件世界中客觀存在的一種現(xiàn)象，就像初一、十五大海的潮汐一樣。在CMMI配置管理的SP2.1中就變更管理的流程和規(guī)范進行了定義。
　　軟件變更的起因為什么會出現(xiàn)軟件變更呢？這要從軟件項目的性質(zhì)出發(fā)進行探討。PMP定義的項目特點是“臨時性”和“獨特性”，大家就算把已經(jīng)完成的項目重新再做一遍，其過程也不可能是一模一樣的。其實軟件開發(fā)就是將客戶腦子里主觀的思想轉(zhuǎn)換為客觀的代碼行，主觀的東西都是虛無縹緲的，根據(jù)人的意識會經(jīng)常改變的；另外軟件開發(fā)就是將企業(yè)的最佳實踐轉(zhuǎn)化為客觀的產(chǎn)品，接受需求調(diào)研的客戶一般都是他們行業(yè)中的佼佼者，他的思想就是企業(yè)的最佳實踐，這些最佳實踐也許連他的同事都不一定完全理解，何況是我們這些做軟件開發(fā)的技術人員。通過以上軟件開發(fā)項目的特點進行分析，大家應該也理解了為什么軟件開發(fā)會有那么多的變更了吧。除了應該理解變更的起因外，還應該讓我們的客戶對變更的起因有所認識，做到大家互相理解，和諧的項目才是共贏的。另外大家不要以為變更給項目帶來很多麻煩，有時變更也會為項目帶來效益，技術的革新就是一種特殊的變更，在我國實現(xiàn)現(xiàn)代化建設的過程中不知道有多少技術革新為國家?guī)砘蛲旎財?shù)以億計的財富，在我們的軟件項目中一些新的技術或架構(gòu)，也一樣會減少項目的開發(fā)周期和成本。
　　軟件變更的必要性變更會有其相應的流程，有流程就會有工作量，有人會覺得變更太麻煩沒有必要，在筆者進行CMMI咨詢時往往推薦兩種級別的變更：“一般變更”和“重大變更”。“重大變更”常指里程碑的延誤、項目組成員的變化、項目成本的變化，具體每種變化有多大才算是重大變更呢？這就要針對不同公司的不同情況來定義。為什么重大變更沒有定義軟件范圍也就是需求的變更呢？因為需求的變更可以通過項目里程碑的延誤或項目成本的增加來判斷。重大變革要走正規(guī)的變更流程，并且要通過“變更控制委員會”CCB的評審通過后才能實施。除了“重大變更”以外的都屬于“一般變更”，例如項目進度雖然有延遲，但是不會影響項目里程碑?！耙话阕兏辈辉傩枰狢CB的評審，項目負責人就可以全權處理。通過對變更級別的劃分，給項目負責人一定的權利，這樣項目變更就不會讓人覺得繁瑣了?？荚嚧筇峁?BR>　　(五) 配置管理的審計
　　配置審計的目的是配置管理員要確保配置庫中的配置項和基線的完整性和正確性，這就是CMMI配置管理SP3.2所提到的概念。在“開發(fā)庫”中的配置項是不需要進行審計的，一旦帶有缺陷的配置項進入“受控庫”或“基線庫”，那么將會給項目帶來不小的負面影響。配置管理的審計分為“物理審計”和“功能審計”兩種。
　　“物理審計”比較簡單，配置管理員只需根據(jù)項目組提交的“入庫清單”逐一檢查文檔或程序是否存在，命名規(guī)則是否符合規(guī)范既可。
　　“功能審計”的理解會相對比較復雜一點，“功能審計”是對配置項的內(nèi)容是否正確進行檢查。但配置管理員有可能是不懂技術的，那么他將如何開展功能審計呢？進入“受控庫”或“基線庫”的文檔肯定是經(jīng)過并通過評審的，代碼程序也肯定要經(jīng)過并通過測試的，因此配置管理員可以利用這些驗證的結(jié)果來間接對其入庫的內(nèi)容進行檢查。這樣配置管理員就可以保證其功能的正確。
　　(六) 總結(jié)
　　通過以上內(nèi)容的介紹，相信大家應該對CMMI配置管理的概念和重點有所認識了。配置管理工作是貫穿整個項目生命周期的核心工作之一，只有利用配置管理的理論把項目條理化、清晰化，那么才能開展例如需求、設計、開發(fā)、測試等其他工作。通過本篇文章筆者希望大家知道什么是配置項和基線，配置庫是如何劃分的，為什么軟件項目會有變更，同時我們也要正視和接受變更的存在，以及配置管理員是如何進行功能和物理審計的。