軟件配置管理系統

(1)庫

庫是軟件配置管理系統的根本。庫是集中控制的文件庫，並提供對庫中所存儲文件的版本控制。任何庫中的文件都被視為在確定的軟件配置管理之下。庫中的文件是不會變的，即它們不能被更改。任何更改都被視為構造了一個新版本的文件。文件所有的軟件配置管理信息和文件的內容都存儲在庫中。所以，任何配置的管理和控制都與庫中的文件相關聯。當工作於一個文件時，用户將某個版本的文件導入到自己的工作目錄，然後開始工作；處理完後再將文件導回到庫中。這樣就生成了這個文件的新版本。因此，用户不可能導出一個文件並同時在庫中修改源文件。

從庫的角度來看，導出的文件被自動鎖定直到文件重新被導入，一個版本號自動與新版本文件相關聯。這樣一來，用户可以隨時根據特定的版本號導出任何文件。最新版本修改的結果將產生一個新的、順序遞增的版本；而對老版本修改的結果將產生一個分支版本。在版本編號策略和使用模式的共同作用下，產生了文件版本歷史樹，用來表示原始和更新後的版本。庫中不但存儲了文件的不同版本、更改的理由，而且存儲了誰在什麼時候替換了某個版本的文件等文件歷史信息。注意，對於每個不同的版本文件，不是所有的代碼都能被存儲起來，而只是將不同版本間的差異進行存儲，這稱為增量。這種方法有利於節省空間以及節省對最新文件版本的訪問時間。另外，可以根據狀態給文件加上標籤，然後基於狀態的值進行導出。同樣也可以根據修訂版本號、日期和作者進行導出操作。因為，庫總是和文件所在的目錄相關聯的。

總之，庫控制軟件配置管理信息，並把不同版本的文件存儲為不可修改的對象。

(2)分佈式組件

根據下面給出的例子闡述分佈式組件。

Sherpa設計管理系統提供一個文件庫，其中的文件分散地分佈在不同的硬件平台上。在邏輯上，庫是集中控制的；但在物理上，庫中的數據是分散的。Sherpa設計管理系統自己知道數據的分散分佈，並把這個因素考慮到軟件配置管理系統中，如在提供必要的文件格式轉換時提供一定的容錯能力。

這樣，對於用户來説，數據的分佈是透明的。一組在地理上分散分佈的用户可以針對同樣配置的文件一起工作。多個文件的副本可以存在於在不同的工作站上。Sherpa設計管理系統知道最新文件版本的位置。對從庫中所導出文件的任何更改都會導致所有分散在本地工作站上的副本更新，因為系統知道所有本地副本放置的位置。更新可以是一步一步交互式地發生，也可以是批處理式地完成。有效、分散分佈的用户能夠直接訪問集中控制的庫。對他們來説，軟件配置管理能力看起來遍佈整個異構網絡。

軟件配置管理系統的發展經歷了兩代。第一代軟件配置管理系統僅僅只是處理文件版本控制的工具。它們是基於單一文件的工具，將各獨立文件改變存儲在特殊的文檔文件之中，一般支持恢復提交模式，並提供分支。最早的這類工具是源代碼控制系統，這些都是面向開發而並非管理的、簡單的和獨立的工具。

第二代軟件配置管理系統則是基於項目數據庫的，其最顯著的特徵是軟件開發項目的源代碼與它們的文檔分離，而存儲在一個數據庫中，該數據庫稱為項目數據庫或軟件庫。它們能夠處理複雜的元素，提供不同的版本模型，是一個集成版本管理和項目組建功能的工具。例如，領域軟件工程環境在實現對文件進行版本管理的基礎上，應用了系統模型的描述和版本綁定等策略來支持項目組建，但這些工具僅僅是支持編碼階段的工具。

在項目實際工作中，可以用VSS、CVS等工具來建立配置庫。VSS(Visual SourceSafe)是Microsoft公司推出的配置管理工具，是Visual Studio的套件之一。CVS(Concurrent Version System，並行版本系統)是著名的開放源代碼的配置管理工具，許多軟件機構根據CVS官方提供的編程接口開發了各色各樣的CVS客户端軟件，最有名的當推Windows環境的CVS客户端軟件——WinCVS，WinCVS是免費的，但是並不開放源代碼。

1．建立配置管理系統的步驟

建立配置管理系統的步驟如下：

(1)組建配置管理方案構造小組。這個小組負責構造配置管理過程中的所有工作，包括瞭解本組織的現有開發、管理現狀，選擇配置管理工具，制訂配置管理規範，安排試驗項目的實施，溝通部門間關係，獲得管理者支持和開發人員的認同。配置管理方案構造小組的成員應該包括：小組負責人、技術支持專家、配置管理技術專家、配置管理系統用户代表。

(2)對目標機構進行了解、評估。目標機構的調查評估工作由配置管理技術專家領導，配置管理系統用户代表參與，提供基本信息，並由小組負責人協調，對相關部門人員進行深入調查獲得較全面的數據。對目標機構的瞭解、評估應從這幾個方面入手：人員、技術、工作流程、現有項目和期望值。

(3)配置管理工具及其提供商評估。通過對組織的評估，瞭解該組織的現狀和需求後，就需要選擇適合該組織的配置管理工具。市場上現有的配置管理工具不下數十種，它們各有所長，在功能、性能等方面有較大的差別，只有經過仔細地對產品及其提供商進行分析評估，核對目標機構的需求，才能挑選出合適的工具，實現一個理想的配置管理過程。

(4)制訂實施計劃。

(5)定義配置管理流程。配置管理流程是軟件開發機構進行配置管理的依據，也是配置管理構造小組的最重要的工作成果。配置管理流程規定開發過程中需要做哪些配置管理方面的工作，由誰做、如何做。

(6)試驗項目的實施。這一階段的任務是選取目標機構中的一個現有項目，按既定的配置管理流程去進行開發和配置管理工作。這種試驗的目的是在一定風險範圍內，通過實地運作來確定所選配置管理工具、所制訂的配置管理規範是否能滿足目標機構的需要。

(7)全面實施。經過試驗項目證實、校正後的配置管理流程就可以在目標機構的各個項目、各個相關工作環節中去應用、實施，最終使配置管理過程日常化、規範化。

2．配置庫的分類

配置庫也稱配置項庫，是配置管理的有力工具。在軟件工程中，主要有4類配置庫：

(1)開發庫(動態庫、程序員庫、工作庫)。存放開發過程中需要保留的各種信息(新模塊、文檔、數據元素或進行修改的已有元素等)，供開發人員個人專用，是開發人員的工作區，由開發人員(工程師)控制。庫中的信息可能有較為頻繁的修改，只要開發庫的使用者認為有必要，無需對其做任何限制。因為這通常不會影響到項目的其他部分。

(2)受控庫(主庫、系統庫)。用於管理當前基線和控制對基線的變更。受控庫包括配置單元和被提升並集成到配置項中的構件。軟件工程師和其他人員可以自由地複製受控庫中單元或構件。然而，必須有適當的權限授權變更。受控庫中的單元或構件用於創建集成、系統和驗收測試或對用户發佈的構建版。在開發的某個階段工作結束時，將工作產品存入或將有關的信息存入。

(3)產品庫(靜態庫、軟件倉庫、軟件產品庫)。在開發的軟件產品完成系統測試之後，作為最終產品存入庫內，等待交付用户或現場安裝。產品庫用於存檔各種廣泛使用的已發佈的基線，控制、保存和檢索主媒介，庫內的信息也應加以控制。

(4)備份庫。用來存放配置項備份版本的庫，包括製作軟件和相關架構、數據和文檔的不同版本的拷貝時的複製品。在各時點的備份，例如，可以每天、每週或每月執行備份。

3．配置庫的建庫模式

決定配置庫的結構是配置管理活動的重要基礎。一般常用的是兩種組織形式：按配置項類型分類建庫和按任務建庫。

按配置項的類型分類建庫的方式經常為一些諮詢服務公司所推薦，它適用於通用的應用軟件開發組織。這樣的組織往往產品的繼承性較強，工具比較統一，對並行開發有一定的需求。使用這樣的庫結構有利於對配置項的統一管理和控制，同時也能提高編譯和發佈的效率。但由於這樣的庫結構並不是面向各個開發團隊的開發任務的，所以可能會造成開發人員的工作目錄結構過於複雜，帶來一些不必要的麻煩。

而按任務建立相應的配置庫則適用於專業軟件的研發組織。在這樣的組織內，使用的開發工具種類繁多，開發模式以線性發展為主，所以就沒有必要將配置項嚴格地分類存儲，人為增加目錄的複雜性。因此，對於研發性的軟件組織來説，還是採用這種設置策略比較靈活。 ^[1]