一． 軟件配置管理的目的
對于任何一個軟件組織（企業）來說，開發出滿足用戶需求的、高質量的軟件產品是其追求的目標。而要實現這一目標的關鍵是建立起一個穩定、可控、可重用的軟件流程（Software Process）。因為某一軟件產品的成敗可能維系于關鍵技術的突破和創新；但對于軟件組織而言，要想永葆競爭優勢并不斷取得成功，那就必須不斷地改進它的軟件流程。要進行軟件流程改進（Software Process Improvement）就需要有明確的、量化的對現狀的分析和對未來的預期，這些數據來源于對軟件過程的度量，而進行度量的前提和基礎就是軟件配置管理。
與一般制造業相類似，軟件流程就像是一條流水線，在它的各個環節上都會有“零部件”產生，它們就是我們所熟悉的程序、相關文檔以及數據。這些正是軟件配置管理的對象——（軟件）配置項。它們不僅是大量人力物力投入的結晶，更是開發經驗的積累，是軟件組織最寶貴的財富。軟件配置管理貫穿于軟件開發活動的始終，覆蓋了開發活動的各個環節，它的重要作用之一就是要全面的管理保存各個配置項，監控各配置項的狀態，并向項目經理及相關的人員報告，從而實現對軟件過程的控制。
那么我們對這些配置項進行管理只是為了保存這些信息嗎？眾所周知，人員的高流動性和知識和技術的快速更新是軟件業的重要特點。應對這樣的特點我們只有努力地把開發人員個人的成功經驗轉化為團隊的以及整個組織的經驗。在這樣的一個轉化過程中，軟件配置管理也起著極其重要的作用。因為對于一個大型的軟件企業來說，它的配置庫有如一個巨大的圖書館，隨著產品版本的不斷演進，越來越多的配置項會充斥其間，以至于沒有任何一個人能了解其中的全部內容。當我們需要在開發組織內部迅速的共享以往的成果時，配置管理就能發揮作用了。它就像常見的圖書編目法那樣，幫助圖書管理員（配置管理員）迅速的找出所需的資料（配置項），而不必徹底了解其中的確切內容。這樣工作效率大為提高，很多常見的容易引起混亂的問題都能盡量得以避免。
所以，我們在從事軟件配置管理工作時應以整個軟件流程的改進為目標，為軟件項目管理和軟件工程的其它領域打好基礎，以便于穩步推進整個軟件組織的能力成熟度。
二． 工具的選擇
古語有云：“工欲善其事，必先利其器�！避浖渲霉芾硎且豁検址爆嵉墓ぷ�，同時又和整個軟件的開發活動緊密地聯系在一起，所以在實際工作中更需要有得力的工具輔助。目前常用的配置管理工具主要有MS SourceSafe、Rational ClearCase等，這些工具各有所長，因而只有根據項目的預算和開發組織的些實際情況出發來選擇，正所謂“好用就好”。在這里，筆者提出一些個人的看法供大家參考。
首先，配置管理工具應該提供完善的版本管理的功能。在該工具的所管理的配置庫中，所有的配置項都應清晰、完整的得到保存，相應的操作紀錄完備，使得開發組織中的任何人員都能迅速的了解任一配置項的演進過程，并快捷的找到所需的資源。
其次，配置管理工具應具備一定的工作空間的管理功能。正如前文指出的那樣，一個軟件企業往往有多個項目同時進行著開發，為了最大程度的利用組織的經驗、共享成果，我們有必要在一個共同的配置庫里提供多視角的觀察手段，在邏輯上按照不同的角色分工來組織信息的選取規則和顯示方式，從而能根據需要，在開發人員間靈活的進行分工合作。
由于我們把配置管理工作立足于軟件過程的改進，那么我們所選用的工具最好能具有一定的過程控制的能力，能利用它按照企業本身的開發流程來靈活的建立相應的電子流，并在此過程中記錄用于過程度量的相關數據，整合軟件過程管理的各個環節，以便于客觀的發現問題，高效的解決問題。
另外，我們選取得工具一定要操作簡便，不能給開發人員增加過多的負擔，因為過多的形式化的約束往往帶來人們的反感，使得大家不約而同的選擇規避的措施，其結果只能是事倍功半，甚至和我們的目標南轅北轍。
三． 實現的策略
筆者所在的軟件組織從事的通信軟件的研發，我們把配置管理作為推進軟件過程改進的一個很重要的工作領域。我們明確定義了配置管理相關的角色、工作職責和工作流程，通過一段時間的努力，已經取得了明顯的效果。 1． 配置庫的設置
決定配置庫的結構是配置管理活動的重要基礎。一般常用的是兩種組織形式：按配置項類型分類建庫和按任務建庫。
按配置項的類型分類建庫的方式經常為一些咨詢服務公司所推薦，它適用于通用的應用軟件開發組織。這樣的組織一般產品的繼承性較強，工具比較統一，對并行開發有一定的需求。使用這樣的庫結構有利于對配置項的統一管理和控制，同時也能提高編譯和發布的效率。但由于這樣的庫結構并不是面向和各個開發團隊的開發任務的，所以可能會造成開發人員的工作目錄結構過于復雜，帶來一些不必要的麻煩。 而按任務建立相應的配置庫則適用于專業軟件的研發組織。在這樣的組織內，使用的開發工具種類繁多，開發模式以線性發展為主，所以就沒有必要把配置項嚴格的分類存儲，人為增加目錄的復雜性。因此，筆者認為特別是對于研發性的軟件組織來說，還是采用這種設置策略比較靈活。
2． 分支的劃分
在實際的開發活動中系統中，為了讓每個開發人員和各個開發團隊能更好的分工合作，同時又互不干擾，我們基本上為每個配置項從建立開始就劃分成3個不同的分支，讓它們分別對應3類工作空間。
l 私有分支
私有分支對應的是開發人員的私有開發空間。開發人員根據任務分工獲得對相應配置項的操作許可之后，他即在自己的私有開發分支上工作，他的所有工作成果體現為在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素。
l 集成分支
集成分支對應的是開發團隊的公共空間。凡是要為同組人員共享的配置項都從該分支獲得。即各開發人員必須將私有工作空間中的開發成果歸并（Merge）到該分支后才能進入下一個開發活動。所有涉及多人協調的開發工作（如集成測試等）都必須工作在這一空間中。該開發團隊擁有對該集成分支的讀寫權限，而其他成員只有只讀權限。該分支的管理工作由系統集成員及相關指定人員負責。
l 公共（主干）分支
公共分支對應的是整個軟件開發組織的公共空間。各個開發小組在現階段的任務完成后，將可以發布的版本歸并到該分支上，將來需要查閱相關資料時，以該分支上的版本為準。該分支對組織內的全體軟件人員開放只讀權限。該分支的管理工作由系統集成員負責。
上面定義的3類工作空間（分支）由配置管理員統一管理，根據各開發階段的實際情況定制相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。 3． 變更控制
對于大型的軟件開發項目，無控制的變更將迅速導致混亂，變更控制就是通過結合人的規程和自動化工具，以提供一個變化控制的的機制。本文所涉及的變更控制的對象主要指配置庫中的各基線配置項。變更管理的一般流程是：
A) 由開發人員或系統集成員提出變更需求；
B) 由SCCB（軟件變更控制委員會）審核并決定是否批準；
C) 配置管理員根據SCCB的決定臨時開放相應的權限，并備案；
D) 系統集成員執行相應的變更。
在這里，將要涉及的變更控制分為兩類：一類是基線的變更控制，另一類是軟件版本的變更控制。 l 基線的變更控制
基線的變更是指在一個軟件版本的開發周期內對基線配置項的變更，主要包括基線的應用和更新等活動。
基線變更所涉及的操作主要包括基線標簽的定義和標簽的使用�；�標簽屬于嚴格受控的配置項，它的命名必須嚴格按照相關的命名規范來進行�；�在建立時，按照角色職責的分工，須經SCCB同意并以正式的將該基線的標識和作用范圍通知系統集成員，由后者負責執行；基線一旦劃定，由該基線控制的各配置項的歷史版本均處于鎖定或嚴格受控狀態，任何對基線位置的變更請求都必須按變更控制流程，提交SCCB批準，然后由系統集成員執行。
l 軟件版本的變更
軟件版本的命名規范應事先制定，并按照開發計劃予以發布使用。在軟件版本的演進過程中既需要從以前的版本中繼承，又需要相對的獨立性。所以在對于一個子版本（例如某特定用戶的定制版本）就需要對一系列配置項從統一的開發起始基線所確定的版本上建立新的分支，然后在此分支上開發新的版本。因此在這樣的變更控制流程中，受控的對象還應包括特定的分支類型，以及工作視圖的選取規則，同時配置管理員將在這一過程中擔負更多的操作職責。
上述幾點是筆者在從事軟件配置管理過程中的一些心得體會，在此拋磚引玉，供大家參考。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
