關于軟件配置管理 軟件測試
一、軟件配置管理的基本概念
在配置管理中有幾個常用的基本概念是需要弄清楚它們之間的聯系和區別的。這些概念是配置項、里程碑、基線、受控庫、基線庫、產品庫等。
軟件配置項是軟件生存期內，能相對獨立開發的一個程序實體或文檔。
里程碑即通常所說的軟件開發過程中的“階段”，如果說它們之間有 區別的話，那么“階段”強調的是過程，而“里程碑”則強調過程的終點和終點的標識。這些階段可以是需求分析階段、概要設計階段、詳細設計階段等等。
基線 是軟件開發過程中最重要的里程碑，不過基線更強調的是一個開發階段到達里程碑時的結果及其內容，如功能基線是 經過評審和批準的需求規格說明書；產品基線是經集成和確認測試后，經正式審批可交付客戶的軟件產品的全部配置項（包括軟件實體和所有的文檔）。 [Page]
正如清華大學鄭仁杰教授所說 在一個開發階段結束后，要對相應的配 置項進行基線化并形成各類基線�；�就是一個配置項（或一組配置項）在其生命期的不同階段完成時，通過評審而進入受控狀態的一組文檔和程序實體，這個過程被稱為 “基線化”。每個基線都是其下一步開發的基點和參考 點；它們都將接受配置管理的嚴格控制。因此，基線必須通過評審過程建立；基線存在于基線庫中，接受更高權限的控制；基線是進一步開發和修改的基準和出發點。
受控庫 是軟件開發過程中，其修改權限受到控制的文檔庫和程序庫，其中基線庫和產品庫，特別是產品庫的修改權限將受到嚴格的控制，即使是授權修改的人，在修改前還必須得到批準。
基線庫 是受控庫中一些特別重要的庫，如需求（基線）庫和產品（基線）庫。
產品庫 是存放軟件最終產品（即產品基線）的庫，基于它的重要性，對它的修改將受到特別的控制。 產品基線是最初批準的產品配置標識。
二、軟件配置管理計劃
預則立，不預則廢”，軟件配置管理計劃對于配置管理實施的重要性毋庸多言。大家想看看別人做的配置管理計劃或者模板，無非是想學學別人的成功經驗，避免自己走一些彎路。
但是我想，在這方面，更應該學習的應該是計劃軟件配置管理實施的思路，畢竟，各個開發團隊不同的地方太多了。下面是我觀察和思考的一些成果，和大家分享。
像你的老板一樣思考
作為一個配置管理實施的執行人員，你怎么樣才能夠保證這項活動的成功呢？
說起來很簡單、但是也是最重要的第一步，就是定義“成功”。
很多負責配置管理實施的人員都是技術人員出身，我經常能在他們身上觀察到的一種現象就是：出于對技術的熱愛，他們希望把軟件配置管理學習、理解得很透徹，然后同樣出于對技術的熱情，希望能把所有在技術上很“誘人”的東西都實踐起來。
我絕對沒有貶低這種熱情的意思（事實上，我自己也經常被這種熱情所導引）；但是，我們一定要小心地提防這種熱情把我們引離了通向成功的方向。
為什么要實施軟件配置管理？因為有效的配置管理可以幫助我們提高軟件產品質量、提高開發團隊工作效率。
什么是“成功”的配置管理實施？很簡單，只要比較配置管理實施活動前后，軟件產品的質量是不是得到了提高、開發團隊是不是能夠工作在一個有助于提高整體工作效率的配置管理平臺上。
軟件配置管理活動在整個開發活動中是一項支持性、保障性的工作，它本身并不直接為企業產出可以直接贏利的工作成果；而配置管理每一項活動都需要消耗企業的人力資源，有些還需要購置專門的工具來支持活動的進行，這些都會導致企業生產成本的增加。
所以，在我們計劃實施配置管理時要做哪些事情的時候，要小心地界定每一項活動，取舍的標準就是：從事這項活動是不是真正有助于我們實施活動的成功？它對于提高我們產品的質量有多大的幫助？能否幫助開發團隊更高效率地工作？
大多數情況下，你的老板花錢讓你來做配置管理，并不是來讓你學習配置管理或者研究配置管理，而是希望你的工作能幫助他改變些什么；他的投資成功與否，是用投資回報率（ROI，return-on-investment）來衡量，而不是你對于配置管理技術研究的程度。
評估開發團隊當前配置管理現狀
計劃配置管理實施的基礎，是搞清楚開發團隊當前配置管理的現狀。知道自己現在站在哪里，才明白自己下一步要往哪里走。
對于配置管理現狀的評估，可以自己進行，也可以引入外部專業咨詢人員來完成評估活動。 [Page]
自己進行評估的話，可以參照SW-CMM中關于軟件配置管理這個關鍵過程域的資料；也可以利用PMT編寫的《軟件組織配置管理能力自我評估問題集》，來完成自我評估的工作。
引入外部專業咨詢人員進行評估有兩個好處，一是通常這樣的咨詢人員有比較豐富的配置管理實施經驗，評估工作可以進行得更加細致，而且通常咨詢人員會在評估結果的基礎上提出實施的建議；二是引入外部人員，通常評估結果會比內部自我評估更客觀。壞處是要花錢，而且如果該咨詢人員與具體的配置管理工具廠商有利益關系的時候，也可能會出現評估過程受到這種利益關系影響的情形。
不管以何種方式進行，評估這個步驟的工作是一定要仔細進行的。有了評估的結果，才談得上改進。做好這個工作，比到處去找一份配置管理計劃的模板更有意義。
定義實施的范圍
對于沒有正式實施過軟件配置管理的開發團隊來說，在配置管理方面存在的問題可能會比較多；經過評估，會找出來很多需要改進的點，那么，怎么樣來計劃改進的工作步驟呢？
曾經有一位朋友向我展示他撰寫的軟件配置管理計劃，從基本的版本控制、基線管理、變更管理，到軟件構建的管理（Build Management）、配置審核（Auditing）、配置狀態的報告，洋洋灑灑，什么都做在計劃里了。他的團隊以前沒有太多配置管理的概念，因而也出現了很多一直困擾他的問題，在我向他介紹配置管理可以幫助他改善或解決這些問題以后他變成了一個配置管理技術的愛好者。我想他一定仔細研讀了RUP配置管理工作流、IEEE軟件配置管理標準之類的資料然后寫出了這份計劃。我對他的計劃提了一個問題：“你覺得按照日程安排我們做得完這么多事情嗎？”
這就是前邊說過的，熱愛技術的朋友最容易出現的情況，為技術而技術、為流程而流程；我記得一位朋友跟我說過一句非常有意義的話：流程改進應該是以結果為導向的（Result Oriented）。配置管理的實施也是如此，應當在當前評估的基礎上，抓住團隊最頭疼的幾個問題，努力想辦法解決這些問題。
大家都知道管理學里有一個黃金法則：80/20法則。在這里我們也可以套用一下，想一想：我如何才能找出20％的問題，在當前這個階段，這20％的問題給我的團隊帶來80％的困擾和痛苦，然后，我們集中80％的精力來解決這些問題。
一句話，不要企圖一口吃個胖子。流程改進是一個持續的歷程，一個階段會有一個階段改進的重點，抓住重點、做出成績，才是有效的改進之道。
計劃資源要素
俗話說，兵馬未動，糧草先行。配置管理的實施需要消耗一定的資源，在這個方面一定要預先規劃。
具體來說，配置管理實施主要需要兩方面的資源要素：一是人力資源，二是工具。下面分別論述。 [Page]
人力方面，因為配置管理是一個貫穿整個軟件生命周期的基礎支持性活動，所以配置管理會涉及到團隊中比較多的人員角色。比如，項目經理、配置管理員、開發人員、測試人員、集成人員、維護人員等。但是，工作在一個良好的配置管理平臺上并不需要開發人員、測試人員等角色了解太多的配置管理知識，所以，配置管理實施的主要人力資源會是集中在配置管理員上。
配置管理員是一個比較奇妙的角色，對于一個實施了配置管理、建立了配置管理工作平臺的團隊來說，他是非常重要的，整個開發團隊的工作成果都在他的掌管之下，他負責管理和維護的配置管理系統如果出現問題的話，輕則影響團隊其他成員的工作效率，重則可能出現丟失工作成果、發布錯誤版本等嚴重的后果。然而，由于傳統不了解配置管理重要性的原因，在國內的開發團隊中，通常大家都不愿意去做配置管理員。我遇到很多情況，都是項目經理找來找去，選出來一個不喜歡做開發工作的女孩，來擔任配置管理員。
在國外一些比較成熟的開發組織中，配置管理員被稱為CMO（Configuration Management Officer），或者是配置經理；他們被稱為是項目經理的左手。從這兩個稱謂我們可以看出他們對于配置管理員的重視。在選拔配置管理員的時候，也有相當高的要求，比如，有一定的開發經驗，對于系統（操作系統、網絡、數據庫等方面）比較熟悉，掌握一定的解決問題（trouble shooting）的技巧，在個人性格上，要求比較穩重、細心。
在配置管理員這個資源配置方面，要注意后備資源（Backup）的培養。在大家越來越重視配置管理的大環境下，經驗豐富的配置管理員會成為搶手的人才；而配置管理員的離開可能會給團隊的工作進度帶來一定的影響，所以聰明的管理者會為自己留好備份。
選擇什么樣的配置管理工具，一直是大家關注的熱點問題。確實，與其他的一些軟件工程活動不一樣，配置管理工作更強調工具的支持；缺乏良好的配置管理工具的話，要做好配置管理的實施會非常困難。
具體來說，我想在配置管理工具的選型上，可以綜合考慮下邊的一些因素。
首先是經費。市場上現有的商業配置管理工具，大多價格不菲。到底是選用開放源代碼的自由軟件、還是采購商業軟件，如果采購商業軟件的話，選擇哪個檔次的軟件，這些問題的答案，取決于你能從老板那兒拿到多少錢。
一般來說，如果經費充裕的話，采購商業的配置管理工具會讓實施過程更順利一些，商業工具的操作界面通常更方便一些，與流行的集成開發環境（IDE）通常也會有比較好的集成，實施過程中出現與工具相關的問題也可以找廠商解決。
如果經費有限的話呢，就不妨采用自由軟件，如CVS之類的工具。其實無論在穩定性還是在功能方面，CVS的口碑都非常好，我看到過很多組織成功地在CVS上完成配置管理的工作。如果你（或者你的配置管理員）不是一個依賴性很強的人，喜歡自己鉆研、自己去尋找資料解決問題，CVS會是一個不錯的選擇。 [Page]
如果準備選擇商業配置管理工具，就應當重點考慮下面幾個因素。
（一）、工具的市場占有率。大家都選擇的東西通常會是比較好的東西。而且市場占有率高也通常表明該企業經營狀況會好一些，被人收購或者倒閉的可能性小一點。
（二）、工具本身的特性，如穩定性、易用性、安全性、擴展能力等。你應當在投資以前仔細地對工具進行試用和評估。這兒比較容易忽略的是工具的擴展能力（Scalability），你現在可能只是在幾個人、十幾個人的團隊中部署這個工具，但是以后可能會有幾十個、幾百個人要在依賴這個工具建立的平臺上工作，到時候這個工具能不能提供這樣的支持能力？如果到時候要換一個工具的話，你一定會后悔今天的選擇。
（三）、廠商支持能力。工具使用過程中一定會出現這樣那樣的問題，有些是因為你使用不當引起的，有些則是工具本身的毛病。這樣的問題會影響到開發團隊的工作進度，你一定希望能隨時找到廠商的專業技術人員幫助你解決這些問題。
配置管理工具不是用一次兩次的工具，因此，選擇配置管理工具其實是選擇和哪個廠商來建立一種長期的關系；如果你不信任或者干脆就是不喜歡這個廠商的技術代表，那么，不管他把他的東西吹得怎么個天花亂墜，還是趕緊讓他走吧。
三、配置管理變更的關鍵路徑的方法
配置管理來源于硬件系統。例如PC行業中，每一臺PC由主機和顯示器等構成，而主機又由CPU、主板等構成，對這些構件配置情況進行管理，就是硬件的配置管理。在軟件行業，計算機軟件由編譯后的代碼和相關的一系列文檔組成。但構成軟件的部件的變化是跟隨軟件產品的開發周期而不斷變化的。就頻率和程度來說，軟件的變化遠遠大于硬件。因此，軟件配置管理是一套管理軟件開發和軟件維護的方法和規則，其最終體現的是維護軟件產品的一致性和完整性。
變更常有
筆者所在銀行科技部已經建立了比較完善的項目管理體系和質量保障體系，但要應對分行或支行需求變更和相關軟件版本配置管理的問題，如果沒有一整套的解決措施和工具的支持，就會出現以下問題：
1)分行反映的缺陷更改不能快速響應，不能快速分配缺陷到指定的開發人員，只能依靠口頭或文檔的傳輸，缺乏一個整合開發商服務人員、產品經理(或項目經理)、開發團隊領導、開發人員、分行領導的信息傳遞和交流的平臺。
2)分行的需求變更不能快速響應。分行的需求變更和軟件版本配置只能依靠手工備份，因而，自身不能快速有效地管理各系統的版本，缺乏版本基線的管理策略。
針對以上問題，可以考慮采用軟件配置管理這一關鍵域的思路系統地解決以上問題。配置管理是整個集成軟件項目正常運作的一個管理支撐平臺，其目的就是將有關該項目的客戶、客戶服務人員、產品經理(或項目經理)、開發團隊領導、開發人員、高層領導等項目干系人的工作協同起來，實現高效的溝通，及時地共享工作成果。
配置管理的基本功能包括配置標識、變更控制、配置狀態發布和配置審計。變更控制是配置管理的重要內容，其目的是為了在動態中保證配置項的完整性、一致性和可回溯性，保證配置項的變更過程規范、受控、有完整記錄，受影響的各方均能及時了解情況，并協調一致。
控制不可少
變更控制是通過創建產品基線，在產品的整個生存周期中控制它的發布和變更。配置控制指在配置項標識正式確定之后，對配置項特別是對已提交的代碼、相關文檔和數據等的變更進行系統地跟蹤和控制的過程，主要包括變更的提出、確定配置項的控制等級、變更的評價、變更的處置、實施經批準的變更、對變更進行驗證和結束變更。變更控制的目的是建立一套控制軟件修改的機制，保證生產符合質量標準的軟件和保證每個版本的軟件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以確定在變更控制過程中控制什么，如何控制，誰控制變更、何時接收變更、批準和檢驗。
配置項級別
1)已基線化的配置項是指已完成該配置項的審核和批準，并且成為創建或修改其他配置項的輸入。例如：一個設計文檔已審核、通過、簽發，并且成為編碼活動的基礎。
2)受管理和受控的配置項是指已提交審核，但還沒有批準通過的配置項。例如：一個正在進行審核的設計文檔。
3)受控的配置項指已置于版本控制，但項目組不能直接進行改動的配置項。例如：用戶提供的軟件、購買的工具、產品標準等等。
變更請求的狀態
軟件變更、軟件優化和軟件bug都是產生變更的原因。變更申請人(用戶或產品經理)提出變更時，首先要對受控的配置項的修改提出一個變更請求，說明對軟件變更的需求。這是因為變更控制過程是通過變更請求的流動來實現的，而且對軟件的任何請求都必須和相應的變更請求對應。
變更請求的狀態包括：
1)提交：變更請求提交給配置管理員；
2)拒絕：變更控制委員會拒絕變更請求；
3)接受：變更控制委員會接受變更請求；
4)掛起：變更請求被掛起，以后再作決定； [Page]
5)已驗證：更改已執行和驗證；
6)關閉：驗證并歸檔配置項，更新的配置項提交給用戶(例如：通過版本發布)。
變更請求的類型
1)增強型：變更請求要求對已批準的項目功能進行增強。
2)改進型：變更請求不會造成功能更改，但使配置項的維護更加有效率。
3)糾錯型：變更請求對錯誤進行修正(諸如bug)。
變更請求的優先級
在評價變更請求的優先級時，要對請求變更的配置項進行系統的分析，確定變更影響范圍和修改的程度，確定變更的級別，為確定是否有必要記錄變更提供參考依據。變更請求的優先級可分為三類：
1)高：嚴重地影響一些用戶或許多用戶。
2)中：對用戶造成不方便，或是可以采取相應的變通方法處理的主要問題。
3)低：小問題。
修改完后簽入（Check in）
對變更的處理，要按照變更控制規程，將變更請求及其相關附件提交軟件配置控制委員會審批。配置管理組根據審批意見處理變更請求。
只有配置管理員具有Check in權限。在進行Check in之前，確認下面的事項：
1)所有對配置項所做的修改被批準；
2)所有的更改都經過審核或驗證；
3)所對應的變更請求已經被保存起來；
4)所有相關的審核記錄被保存；
5)Check in時須注明Check in原因，如對應的變更請求。
從數據庫中簽出（Check out）
1)對于文檔，配置管理員在更改審批人同意后，從配置庫中Check out配置項，發給項目組成員修改。
2)Check out時須注明Check out原因，如將要修改的問題。
3) 配置管理員一定要在配置狀態發布中跟蹤被Check out出來的配置項。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
