配置管理系統中的概念
原著：Susan Dart
Software Engineering Institute
Carnegie-Mellon University
Pittsburgh, PA. 15123-3890
USA
dart@sei.cmu.edu
翻譯：luokz (MCM)
摘要：現在，軟件配置管理的環境及其工具越來越得到人們的重視。本文嘗試就現存的CM體系中的以用戶為主體的一些概念作詳細說明。就如一個光譜，某些概念可能是另一些概念的延伸或總結。由于在整個軟件工程家族中對于CM的功能性沒有共通的術語,且許多CM系統在概念的應用上也是千差萬別，因此要從CM系統中抽象出一些概念是難乎其難的事了。正因為這樣，本文陳述的每一概念是其在某一具體的CM系統中的概念。有一部分的概念陳述是針對CM體系的用戶極為重要的問題。沒有哪一個CM系統能提供CM體系不同用戶要求的所有功能。而且，每一CM系統解決的問題只是所有概念的一部分。為了完成本報告，對CM體系的功能以舉例的形式作了簡短的說明。
1 簡介
現在，軟件配置管理的環境及其工具越來越得到人們的重視，這一點從CM體系中提供的概念譜中就顯而易見。本文對這些概念進行了闡明。首先，在一典型的CM情形中，我們 對CM和CM體系做了更為廣泛的定義。
1.1 配置管理的定義
軟件配置管理是一控制軟件系統演變的學科。關于CM的經典討論在條文[3]、[4]中進行了闡述。IEEE標準729-1983就CM以下的內容進行了規范的定義。
在IEEE標準729-1983中，軟件配置管理的定義包括：
標識——識別產品的結構、產品的構件及其類型，為其分配唯一的標識符，并以某種形式提供對它們的存取。
控制——通過建立產品基線，控制軟件產品的發布和在整個軟件生命周期中對軟件產品的修改。例如，它將解決哪些修改會在該產品的最新版本中實現的問題。
狀態統計——記錄并報告構件和修改請求的狀態，并收集關于產品構件的重要統計信息。例如，它將解決修改這個錯誤會影響多少個文件的問題。
審計和審查——確認產品的完整性并維護構件間的一致性，即確保產品是一個嚴格定義的構件集合。例如，它將解決目前發布的產品所用的文件的版本是否正確的問題。
生產——對產品的生產進行優化管理。它將解決最新發布的產品應由哪些版本的文件和工具來生成的問題。
過程管理——確保軟件組織的規程、方針和軟件周期得以正確貫徹執行。它將解決要交付給用戶的產品是否經過測試和質量檢查的問題。
小組協作——控制開發統一產品的多個開發人員之間的協作。例如，它將解決是否所有本地程序員所做的修改都已被加入到新版本的產品中的問題。
軟件配置管理的解決方案涉及面很廣，將影響軟件開發環境、軟件過程模型、配置管理系統的使用者、軟件產品的質量和用戶的組織機構。
配置管理解決方案將影響過程模型和模型的使用者，是因為它強行推行組織的方針政策和工作規程，并對工作過程進行跟蹤。它從開發和維護的及時性方面影響產品的質量。例如，配置管理機制可以保證為每一個發布的版本提供內容清單，通過一致性維護提高產品的質量。配置管理解決方案通常在組織范圍內推行，實際上配置管理系統是組織內部信息交換的中心，它影響組織內的每一個成員及組織的業務流程。
總之，一個配置管理解決方案的制定包括配置管理計劃、過程的定義、與使用者的交流、自動化支持和做出管理決定等活動。
軟件組織應該提出不同層次的配置管理視角，這些層次包括：公司級、項目級、程序員級和應用級。公司級視角提供組織的全貌圖和配置管理過程的描述；項目級視角是與項目相關的各項目組可以使用不同的配置管理方案；程序員級視角是專門為程序員提供的且具有某些特定的配置管理功能；應用級視角關心的是配置管理如何應用到具體的問題中去。
1.2 CM系統的定義
至于怎樣才算是構成CM系統的，對此還沒有普遍接受的定義。例如：假如系統有版本控制功能，它是否就是一個CM系統呢？理想的CM系統是基于以上定義提供所有功能的系統。但是， 實際中的系統只能提供某種程度上實現的版本控制功能、配置識別功能、系統構建功能、系統建模功能，或某種程度上提供CM的意識就被軟件工程大家族認為是CM系統了。應注意的是， 現有的CM體系提供只是一種功能的綜和而不是一標準的體系。本報告提及15個CM系統，目前至少有40個系統可以為今所用。
這里，有必要將CM系統和CM工具兩概念區分一下。CM系統可看作是其支持環境的一部分且以這種形式被售出。譬如，在RATIONAL[14]環境下CM功能成為該環境必不可少的一部分。CM工具可看作是一獨立的工具。譬如，版本控制系統（RCS）只是一個工具，因為它可被安裝在一個現有環境中。由于這種區分在本文不是那么重要，術語CM系統就被用來表示這兩概念。
1.3 CM以用戶為導向的典型情形
在討論CM體系之前，我們描述了一個簡單、典型的、以用戶為導向的CM系統來作參考。在此情形下，包含了具有不同職責的人員：負責軟件小組的項目經理、負責CM規程和方針的配置經理、負責軟件產品開發與維護的軟件工程人員、負責驗證產品正確性的測試人員、負責確保產品高質量的質量保證經理、使用產品的用戶。
每一角色都有他們的目標和任務。對項目經理來講，其目標是確保產品在一定的時間框架里得以開發。因此，經理監控開發過程并發現問題，解決出現的問題。這些又必須通過對軟件系統的現狀形成報告并予以分析以及對系統進行審核才能完成。
配置經理的目標是確保用來建立、更改及編碼測試的規程和方針得以貫徹執行，同時使有關項目的信息容易獲得。為了對編碼更改形成控制，經理引入對正規請求更改的機制，評估更改的機制[通過更改控制機構（CCB），由它負責批準對軟件系統的更改]，和批準更改的機制。經理負責為工程人員創建并宣導任務單，基本上創建項目的框架。同時，經理還收集軟件系統中構件的相關數據，比如說用以判斷系統中出現問題的構件的信息。
對于軟件工程人員，他們的目標是有效地創造出產品。這就意味著工程人員在創建產品、編碼測試及支持文檔的產生中不必相互間干涉。與此同時，他們能有效地進行溝通與協作。他們利用工具以幫助創建性能一致的軟件產品，通過相互通知要求的任務和完成的任務來進行溝通與協調。做出的更改通過將它們進行融合、分散和沖擊而得知。產品中的所有元素的演變連同其更改的原因及實際更改的記錄都予以保留。工程人員在創建、變更、測試及編碼的匯合上有自己的工作范圍。在某一點上，編碼會形成一個基線，它使得進一步開發得以延續，為其它平行開發得以進行。
測試的目標是確保產品經過測試達到要求。這里包括產品某一特定版本的測試和對某個產品的某種測試及其結果予以記錄。將錯誤報告給相關人員并通過回歸測試進行修補。
質量保證經理的目標是確保產品的高質量。這意味著特定的規程和方針應當完成并得到相關的批準。錯誤應得到糾正并應對變化的部分進行充分測試�？蛻敉对V應予以跟蹤。
不同的客戶使用的產品版本也是不同的�？蛻艨偸亲裱巹t來做變更要求、錯誤顯示及產品改進。
理想的CM系統在這種情形下應能夠支持所有這些目標、角色和任務。這也意味著這些角色、任務和目標決定了一CM系統要求的功能。本文提出的一些概念就是為了解決這些問題。
1.4 本文的結構
在簡介中就CM和CM系統進行了定義，列出一典型的CM情形，這樣一來也就暗示了CM體系的要求。第二節描述了CM系統中以用戶為導向的一些問題。這些問題影響用戶對CM系統的期望。第三節描述了CM概念譜。第四對CM體系的未來做了探討，第五節是結論。附錄是本文CM體系索引的概覽。
2 CM體系用戶的有關問題
許多與CM有關的問題直接影響到CM系統的用戶�，F有的CM體系從不同的角度解決這些問題。盡管本文是為了就現有CM體系的特色進行探討，但對這些問題的闡述仍然有必要因為它們影響到用戶對一CM系統的期望。這些問題包括：
用戶的角色問題：
不同CM體系用戶對CM體系的功能的要求也就不同。
集成問題：
不同的集成問題影響到CM系統的功效。
啟用CM的時機問題：
一項目組何時啟用CM系統取決于該CM系統的能力。
控制水平問題；
一CM系統對產品及產品的管理的控制水平可以是不同的。
過程與產品問題：
一理想的CM系統提供CM的過程、產品及其附件。
自動化水平問題：
CM功能的實現總是手工與自動程序的統一。
功能問題：
CM體系具備實現CM眾多功能的許多特點。
以下將對此做進一步說明。
2.1 用戶的角色問題
正如1。3節中的情形表示的一樣，CM體系的用戶是多種多樣的。每一個用戶都有特定的角色，對CM也有不同的觀點，因此，對CM系統的要求也就不同。這種要求是很分明的同時又是互補的。圖1是一功能組描述了項目經理、配置經理、軟件工程人員、質量保證經理及客戶對CM系統的期望。圖1中的每一個方框代表的是一主要的功能區域。圖1顯示在方框外（審核、統計、構件、結構與創建）在任何CM系統中都可獨立存在的功能區域，但當與團隊和過程功能合并時，就得到一個完整的（或綜合的）CM系統了。
圖1：CM功能要求
功能區域有：
l 構件：標識、分類、存取構成產品的組件。
l 結構：表示產品的架構。
l 創建：支持產品的構建及其產品的附件。
l 審核：對產品及其過程的審核予以保留。
l 統計：采集與產品、過程相關的數據。
l 控制：控制產品變更的方式及時間。
l 過程：支持產品演變的管理。
l 團隊協作：促進項目組開發及產品維護。
以下將對這些功能區域的進一步探討。
u 對于元素的要求，用戶要：記錄元素的版本及其差異，差異的原因；確定構成配置及配置版本的組件群；標識出產品的基線及其外延產品，確定表示項目組件群及附件項目環境。而且，用戶需要數據庫來存取組件及CM信息，同時還有資源和對象編碼、執行情況、圖表、文檔和基線。
u 對于機構的要求而言，用戶要：通過表示產品組件庫的系統模型來模擬產品的結構；標明組件、版本、配置的界面使之可以重用；確定及維護組件間的關系；選擇兼容的組件使之形成有效的、一致的產品版本。
u 對構建的要求而言，用戶要：容易創建產品的手段；能隨時靜態分析產品的現狀；通過減少組件的堆積和節省區間來優化系統創建的機制；進行更改分析以預測因更改而導致的細小分化的手段；隨時都能對產品的任何部分、在任何階段容易得到更新。
u 對于審核的要求而言，用戶要：所有更改的歷史記錄；所有與產品相關的組件與其演變的追溯性；完成任務的所有細節的日志。
u 對于統計的要求而言， 用戶要：統計記錄的機制，產品現狀的檢驗，有關產品和過程的所有方面的報告能較易產生。
u 對于控制要求而言，用戶要：為避免不必要的變更或變更沖突對系統中的組件的獲取應予以控制，對于更改要求的表格及問題報告形成在線支持；錯誤查找的手段及何時對何人會產生什么影響；在不同但相關的產品版本之間以受控的方式進行更改告知；將產品進行分割的手段以限制更改影響。
u 對于過程要求而言，用戶要：對生命周期模型及組織方針予以支持；確定要完成的任務及如何完成、何時完成的能力；將相干的事務的訊息在適當的人員之間進行溝通的能力；將產品的經驗文檔化的手段。
u 對于團隊協作的要求而言， 用戶要：個人和小組的工作區間；在匯合時產生沖突的解決辦法；對產品的創建及其維護予以支持的手段。
注意：圖中過程方框與團隊方框代表功能區域極為重要的部分。這是因為它們影響所有其它區域或受到所有其它區域的影響。對于用戶來講，理想的CM系統隨團隊協作和過程的完全融合應當能支持所有的功能區域。但目前還沒有此類系統。
2.2 CM系統的集成
任何CM系統在某種程度上都能與它的環境融合。CM系統可與其它工具并存或完全融合。適合與不同環境方面融合的有：過程、工具組和數據庫。過程集成是將CM系統的使用模式（指CM過程）同環境的使用模式（指軟件生命周期過程）的結合；工具組的集成是將CM系統安裝在環境中使之至少能環境中其它所有工具共存。譬如，在編輯過程中， 每當用戶發出“SAVE”命令時，用戶就會要求CM功能能建立一新的版本。數據集成指的是CM數據庫的邏輯定位——它是否能與現存環境的數據庫能做某種方式的合并，或它的數據庫是否獨立存在的，或它能否利用其它數據庫中的信息。所有此類集成都是普通的工具集成和技術的轉換問題。但，由于CM將影響到環境中的絕大部分物件并貫穿每一物件生命周期的所有階段，CM系統的集成勢必對環境中的很多工具有重要影響。大多數CM系統能與其它工具共存，有些環境把CM看成其必不可少的一部分。
2.3 何時啟用CM系統
對于在開發和維護產品過程中, 項目組何時啟用CM系統是不定的。有些項目組選擇在產品經歷開發生命周期并準備發到用戶地時開始啟用。有的選擇在項目一開始就將一切置于CM下。二者都有各自的一般費用。譬如，項目組可能基于變更要求的費用上來決定何時啟用。如果有許多的手工程序（如：將變更申請表歸檔、尋求CCB的批準與確認可），項目組會選擇在大部分開發完成之后將軟件置于CM的控制之下。但如果變更要求程序能在線很快地得到處理，CM將在軟件生命周期的早期就被用上。理論上講，CM在產品的整個生命周期都能派上用場 —— 從創建、開發、產品發放、交付、使用到維護。在理想的情形下，CM能在較少的花費下對此予以支持，由此CM才能在項目中盡可能早地予以應用。
然而，現有的CM系統只關注生命周期的某一特定的階段，用戶因此受到限制。
2.4 CM的控制水平
很多的程序、方針和工具組合一塊來支持CM的應用。它們在對用戶的支持和產品的演變予以不同程度控制水平支持。譬如，它們會要求開發人員遞交正式的書面的更改請求。配置經理則會建立一個工作區間給軟件開發人員。配置經理可從受控庫存中抽取所要的文檔并將其置于該開發人員的工作區間里。當然，不同的程序、規定和工具事實上允許開發人員也可以通過電子郵件的方式將更改請求通知配置經理及CCB的其他成員。成員之間通過電子郵件予以迅速回應。一經批準，更改請求將被指派給開發人員，他可以直接從庫存中抽取相關的文件并作出更改。所有這些無需手工介入。由于CM系統會自動記錄所有的登入，更改過程的正式記錄就可創建。
前一種情形可被看成對行動具有積極的控制，后者較為松且被動。在前一種情形中由于手工耗費的原因，經常性的更改不予以主張，而后者恰恰相反。這種不同的控制水平在產品生命周期的特定階段有其適用性。譬如，前者更適合維護而后者適合開發。不管CM系統這么用，它對于用戶和產品的演變歷史都有一定程度的控制。它將驅動用戶的過程并將其加強�，F有的CM系統提供或松或緊的控制水平但很少能靈活地允許用戶選擇控制的種類。
2.5 過程與產品的區分
CM包括過程和產品。CM過程表示執行CM是所需的一系列工作任務。從根本上講，過程是一個計劃，它定義要做什么、誰來做及如何做。支持這過程是管理的功能。過程模型將組織的方針、程序和軟件開發生命周期模型通盤考慮。CM的產品是工程管理任務的結果。CM系統的功能需要為二者予以支持�，F有的CM系統提供一些產品及過程的支持，但在同一CM系統中一般不能形成對二者完全支持。
2.6 CM自動化水平
目前，CM一般是手工和自動程序二者兼而有之。無需任何在線支持來實施CM也是可能的。但這樣做的效率很低。我們的目標是將CM中非創造性的部分盡量多地自動化。譬如，書面更改表格和對此回應的監控一般只在組織方針里予以記錄，而不能在線獲取與加強。
2.7 CM系統功能
現有的CM系統提供的只是所有不同種類的用戶的部分功能。但隨時間的推移和用戶的需求和環境結構的能力得到更好理解后，這種情況將可能得以改進。以下部分描述的是現有CM系統概念范圍。
3 配置管理系統概念光譜圖
以上部分解釋了有關配置管理系統需求問題的范圍，本部分將細述配置管理系統的具體功能，并對于支持前文所述某些功能的概念特別加以考察。這些概念將被組織成一幅光譜圖來表示配置管理系統的演化過程。每個概念都將置于一個特定的配置管理系統中來描述。以下是要討論的我們感興趣的配置管理系統概念中的功能，包括：組件，過程，結構和特色架構的組合，團隊概念。圖2展示了整個概念光譜圖和它們對應的，有代表性的配置管理系統實例，然后給出每個概念的一個簡單描述并著重突出它的優勢。在本部分的末尾，將對概念和概念光譜圖的作用和局限性作一個分析總結。
圖例：
*表示本節點所示概念的系統實例
圖2：配置管理概念光譜圖
3.1 注意事項
值得指出的是要討論的概念和系統僅僅是現有系統的表示，而不是現有系統完整的評估和總結。對于每個概念，都用一個配置管理系統實例來討論。但是需要注意的是，許多配置管理系統實際上提供了不止一個光譜圖所示概念。既然談到配置管理系統自然形成的功能時沒有通用的術語，而這些概念是直接從特定配置管理系統中提取——所以每一個配置管理系統有自己的概念和定義。為了注意力集中，概念的描述都盡量簡化。這樣一來，就無法對所有概念的能力（不是它們的系統）面面俱到。但是，因為要提出概念光譜圖和精簡出一個配置管理系統概念集的緣故，簡化是必要的。本文參考的每種配置管理系統在附錄中都有一個簡評，它提供了每種系統配置管理能力一個更全面的清單。
3.2 組件的概念
組件的概念是與標明和訪問軟件產品的組件相關。它們包括下文所描述的庫和分布式組件。
3.2.1 庫
庫的概念是配置管理系統的根本。修訂控制系統(Revision Control System（RCS）)[15]提供了ASCII碼文件庫的概念。從效果上來說，庫是集中控制的文件庫并提供對庫中所存儲文件的版本控制。任何庫中的文件都被視為在確定的配置管理之下。庫中的文件是不會變的——它們不能被更改。任何更改被視為創建了一個新版本的文件。文件所有的配置管理信息和文件的內容都存貯在庫中。所以，任何配置的管理和控制都與庫中的文件相關聯。當工作于一個文件時，用戶將某個版本的文件導入工作目錄，然后開始工作，處理完了，然后將文件導回庫中。這樣就生成了這個文件的新版本。所以用戶不可能導出一個文件并同時在庫中修改源文件。
從庫的角度來看，導出的文件自動被鎖定直到文件重新被導入，一個版本號自動與新版本文件相關聯。這樣一來，用戶可以隨時根據特定的版本號來導出任何文件（缺省的是最新的版本）。對最新版本的修改的結果是產生一個新的，順序遞增的版本；而對更老版本的修改的結果是產生一個分支版本。在版本編號策略和使用模式共同作用下，產生了文件版本歷史樹，用來表示祖先和后代版本。庫中不但存儲了文件的不同版本，更改的理由，而且存儲誰在什么時候替換了某個版本的文件等文件歷史信息。請注意，對于每個不同版本文件，不是所有的代碼都存儲起來，而只是不同版本間實際的差異才存儲起來：這稱為增量。這種方法有利于節省空間和節省對最新文件版本的訪問時間。另外，可以根據狀態給文件加上標簽，然后基于狀態的值進行導出。它們同樣也可以根據修訂版本號，日期和作者進行導出操作。庫總是和文件所在的目錄相關聯�？偠灾�，庫捕捉配置管理信息并把不同版本的文件存儲為不可修改的對象。
3.2.2 分布式組件
Sherpa設計管理系統（The Sherpa Design System（DMS））[7]提供一個文件庫，其中的文件分散分布在不同的硬件平臺上。在邏輯上，庫是集中控制的，但在物理上，庫中的數據是分布的。Sherpa 設計管理系統自己知道數據的分散分布，并把這個因素考慮到配置管理系統中去，例如，在提供必要的文件格式轉換時提供一定的容錯能力。這樣，對于用戶來說，數據的分布是透明的——用戶對庫進行的任何工作感覺上和所有文件放在自己的本地工作站上一樣。一組地理上分散分布的用戶可以針對同樣配置的文件一起工作。多個文件的副本可以在不同的工作站上存在。Sherpa設計管理系統總是知道最新文件版本的位置。任何對從庫中所導出文件的更改會導致所有分散的本地工作站上的副本更新，因為系統知道所有本地副本放置的位置。更新可以是一步一步交互式樣地發生，也可以是批處理式地完成。有效的，分散分布的用戶能夠直接訪問集中控制的庫。對他們來說，配置管理能力看起來遍布整個異構網絡。
3.3 過程的概念
處理與過程相關的功能的概念有以下幾個：上下文管理，約定，變更請求和生命周期模型。以下是詳細描述。
3.3.1 環境管理
PowerFrame[13]是專為計算機輔助工程/設計領域而設計的系統。對于用戶，它實際上是把文件系統和配置管理底層的細節屏蔽起來。用戶只能夠看見和他們特定工作領域相關的，一個電路設計的世界，而PowerFrame管理工作中的上下文。項目的數據不是隱藏在目錄里而是顯式地用圖形表示出來。貫穿整個工作過程的始終，PowerFrame提供工作流管理，來引導團隊的成員。例如：工具—運行可能涉及電路的生成，置電路有效，然后通過進行仿真來決定他們的性能特點。在這一串的動作中，PowerFrame自動根據工具—運行提取相關的上下文，諸如數據集，命令文件和激活工具的選項等等。 等下一次，用戶僅僅需要選擇電路設計和工具功能就能開展工作。用戶所看到的是：針對特定任務的合適的工具，特定的數據表示表格：如邏輯圖和布局設計；與特定任務相關的數據；和特定工作領域相關的命令表。用戶可以在不同的尺度上執行不同的動作：如上下文數據中一個簡單的數據項或者到整個配置管理。用戶不必去操心象版本控制或文件之間的關系等這些任務，因為在屏幕背后，系統知道如何從不同版本的電路設計提取數據，系統完成了這些任務。從效果上來看，配置管理系統針對特定工作領域捕捉用戶工作的上下文，通過這樣的方式減少了用戶的工作，如記住如何到達某個具體工作狀態，所有的數據項和它們的關系是什么等。
3.3.2 約定
ISTAR[9]環境根據正式的約定提供對部分軟件開發過程的建模。所謂約定是指指定輸入和輸出條件下任務的執行。約定的產物被記錄下來作為配置項。一個約定把信息流，包括從任務的開始到完成，任務之間結果的傳遞和產品中組件的傳遞，進行建模。并且，約定之間也是可交換的。怎樣來滿足約定呢？約定的滿足是根據一定的接受標準，把輸出傳遞給過程模型中的特定的元素，如生命周期的不同階段，或人等。約定的產物活動被隨后記載下來。因為不同的約定產物（如通信）會被記載下來，所以約定中的工作過程是被監視的。從效果來看，約定表示一個工作團隊在一個配置項下的正式計劃和記錄。
3.3.3 需求變更
在LIFESPAN中,軟件需求變更表現在文檔的需求變更和相關過程模型的變更。LIFESPAN通過一系列的表單來實現需求變更的建模,在通過一系列狀態,任務和角色來實現過程的變更�？蛻艨梢蕴峤挥脕泶_認錯誤或請求為組件版本升級的在線軟件性能報告。這就允許此報告能被反饋給那些可以診斷出此問題的原始設計和編程人員來研究。對于軟件性能報告和改變沖突分析的反應,一個在線的設計變更被提交表決。確切的說這就詳細到什么組件被改變和怎樣改變的問題。LIFESPAN分析了誰將會被此變化影響。然后那些人就會被自動的選出組成控制變更委員會。關于設計變更的報告將會通過電子郵件來通知他們，不管他們是否同意這些變更，都必須在一定的時間內對此做出表決。一旦設計變更被通過，一種可變更的代碼的新開發版本就產生了。則設計變更就此開始使用而那種代碼的變更就被鎖定。在變更完成后，新的版本形成了，需要被提交給具有QA特權的人來檢測并批準。經過批準后代碼變更就需要一種確認狀態，設計變更的狀態也變為確認的，有關的用戶就被通過電子郵件來通知一種新的版本可以使用了。用戶收到軟件狀態報告表，這就取消了原始的軟件性能報告。因此，軟件性能報告，設計變更和軟件狀態報告不僅為用戶和維護人員提供了一種交流的方式，而且體現了這種特殊變更需求的歷史變更；在過程中變更的狀態報告；變更完成的最終審計結果；改變沖突分析的機制和確保相關人員按時完成任務。結果需求變更就促成了那種變更的過程。
3.3.4 生命周期模型
變更和配置控制提供了對一種特殊的生命周期模型的理解，此模型在某種程度上支持一個生命周期中的各階段及人員之間的轉變，而那些任務和數據管理能在那些階段被執行。他通過把這些階段分為對產品的開發，測試，鑒定和推出來實現。這種劃分允許象軟件工程師和測試員這樣不同種類的使用者能夠在同樣的代碼下同步的實行他們的工作。階段和獨立工作的劃分及其間的轉變通過貫穿于代表每一階段的獨立配置的代碼來實現。就是說，產品作為一系列的基線被開發。每一基線存在四種配置：開發，測試，鑒定和生產。配置是組件的一個層次。每一基線包括一種特殊的方法。代碼的開發就是開發配置，通過反復對配置進行的測試，然后確認配置，最后生產顧客使用的配置產品。為了順利到達下一階段，交互作用的草案必須要被不同的用戶（例如項目經理和測試經理）批準這一轉變。任何時候，對于一組件所通過的標準是由他所屬的配置體現的。結果，生命周期模型經過不同的配置狀態被實現。
3.4 結構和解釋的概念
所要了解的概念是：選擇一種結構的組件；獲得一組件和其結構的變更；描述一產品的結構；存取這種結構；構造這種產品以及保持這種結構的各個部件的一致性稱之為變化集，系統建模，子系統，對象池，屬性和一致性維修。見下述。
3.4.1 修改集合
ADC把在數據庫中的一個基本概念 — 各部件之間的版本的不同 — 抽象成一種不同的關系，這種關系對于用戶是可以訪問的。這樣不同的關系伴隨著與之相匹配的文件以及其它變化的細節組成了變化集。ADC把變化構造成變化集中的配置，變化集可用來構造某種配置的定制外形。這種變化集有一個名字，這意味著它可用在操作中，用戶制定一個公式來創建某個配置的特殊實例。這個公式指定一個被選中的變化集都適應的基本線。一個變化集可視為與以前的變化集是相聯系的（即版本的歷史的延續）或是相互獨立的（即歷史版本的可選部分被應用），特別是變化集。 因此，用戶要么從最延版本中工作，要么在一種配置定制版本下工作。由于某些變化以及誰，何時引起的這些變化等細節，這個變化集可以捕獲對在某個配置中所有文件的變化。用戶指定這種變化的范圍，ADC自動的紀錄這些變化的細節。例如，由于一個錯誤用戶想使主要變化適合某種配置。用戶指出一個變化集，對這些文件做出許多變化。在這個變化集中被捕獲的：由于對在配置中所有文件做出的變化所有原代碼都得改變（在這個配置中對每個文件來說是不同的）；所有有關文件的改變；以及誰，何時做出的改變。當用戶瀏覽每個文件或變化集時可以看見很多信息�？傊�，變化集表示對某種產品和創建一個配置的各種版本方式的邏輯變化。此配置不必依賴于本配置的最新版本信息。
3.4.2 系統模型
系統建模用來描述軟件產品—軟件產品的結構﹑組件和如何組建它。Jasmine系統建模就是用戶能變更的文本描述以及一些工具可以用這些描述來存取完成他們的任務。Jasmine系統建模是由體現以下四類信息的集和函數來描述的：（1）組件產品的關系，（2）綁定的信息版本，（3）構造規則，（4）驗證規則。關系描述為象子組件等級的產品模塊的分解，產品的獨立性（比如模塊組建的順序）和基于屬性的組件組（比如各種資源和對象模塊的分組）。通過關系描述的產品稱之為模板且獲得它的結構。通過這些函數操作和關系用戶可以使用簡單關系定義復雜關系。這就能使Jasmine工具來解決用戶定義的查詢，比如：通過改變一個特定的組件來影響那個組件。系統建模包括進一步了解該產品系列的歷史。此系列產品描述了該產品的后續版本。某種產品的用戶指定的版本構成了一個產品系列。和每一版本關聯的是創建日期﹑作者等屬性。構造規則記錄了現有的組件是如何生成的和將來的組件是如何構造的。比如記錄編譯器﹑版本和所需的編譯選項 。驗證規則指定合和記錄對產品的結構和組織的限制比如資源和綁定模塊必須匹配（意思是所有的綁定模塊都是由那些資源模塊編譯而成的）為了選擇一種組件版本，用于系列的選擇方式是避免使用體現查找模塊路徑的內容來評估的。被選定的結果模塊易把圖像的數據對象當作一種模塊。象瀏覽器﹑模塊查看器﹑調試器和模塊間的分析器等工具能引用和處理系統建模。最終，系統建模是來自于實例產品的抽象，為了全面描述產品，系統建模用工具來維護產品的完整性。
3.4.3 子系統
Rational環境提供了把一個很大的Ada產品分成多個小模塊以及限制變更影響范圍的功能。這些小模塊被稱為子系統，子系統包括接口說明書和實現主體并指出配置項目，因此，他們可被看為一個整體并通過他們的名稱被評價。在一個子系統內的組件不可被其他子系統內的組件所訪問除非為了被輸出而通過接口說明書將這些組件指明。Rational環境檢查實現主體完全匹配上接口說明書所需的運行時間。結果是，工作可以在實現主體上展開而獨立于當用戶想用時就可以被改變的接口說明書，到接口被改變時僅針對那個子系統中的組件會發生二次編譯。這時使用了這個接口產品的任何模塊都將進行二次編譯。對一個接口說明書所作的更改可能需要整個產品進行二次編譯。子系統對其組件進行了版本控制，子系統本身可以是一個特定版本。用戶可以用過組合匹配系統的版本來形成該品的一個特殊產品。概括的說，子系統為用戶指示了一種方法，它限制了變化和二次編譯所帶來的影響，并提供了檢查一個產品的各組成部分的有效性的環境。
3.4.4 對象池
運用系統建模的概念，DSEE已擁有一切必須的信息，此信息能夠確認產生一個生成對象的特殊版本需要些什么。生成的對象被放置在用戶們共享的對象池中。一旦用戶暗示了對對象屬性的需求DSEE就能夠共享。被產生的對象池包括一個由轉換工具生成的二進制代碼和其它對象組成的集合。每一個被產生的對象和其所有的信息有聯系,而這些信息是關于其包括原始版本的系統建模和與轉換項一起使用的轉換工具,被包括的用戶注釋的出處﹑日期﹑時間﹑人員和引出的位置.這個信息被認為是一個BCT.當DSEE構建一個系統時,會為系統中每一個組件計算需要得到的BCT數。DSEE在對象池中查找來看生成的對象和所需的一個已存在的對象是否匹配。如果匹配，它就被用；如果不匹配，它被構建。因此，任何時候一個用戶需要一個特殊的生成對象時（或是一個一致的對象）。DSEE能夠從對象池中再使用從而消除了生成這個對象的需要。用戶不需要知道生成現存對象要做的；DSEE作了全部的檢測。一旦池中的對象成為死亡的（基于一階段無作用）DSEE能夠刪除他們，從而釋放空間。這就節省了大量的編譯時所需的時間和空間，再使用的工作已經在進行。DSEE也提供了各種不同的對象池，例如從源文件中得到的對象仍是對提供給特殊用戶的庫的檢測。結果，CM系統使再生成組件的需求最佳化且最大數量的分享生成對象。
3.4.5 屬性
Adele系統通過用一個有數據建模能力的關系數據庫實體來普及庫和系統的建模。產品在一個數據模型方面被描述，Adele基于那個模型進行它的運算。產品的組件被描繪為擁有屬性和關系的數據庫對象。屬性和每一對象及那個對象的特性相關。屬性有一個名字和一個值。一個例子是名為delta的用于描繪對象是否存在于ASCΠ表中從而能夠被理解的屬性;它可以有一個為真或為假的值。有兩種屬性被區別：預先確定和用戶確定。前者被Adele管理而后者被用戶定義和聲明。一個預先確定，特殊的屬性是“類型“。這個命令屬性是強制的且對每一對象都是不可變的。它在Adele中表現為主要的的CM實體（例如對象的組成，文獻，修改和元素）。關系在對象間獨立定義，例如對象B源自對象A。用戶能夠按照對象的特性而不是按照一系列對象的特殊版本來描述一個配置。Adele例示和構建一個配置用來選取規則和強制圍繞屬性和關系為中心。用戶能夠按照所需特性對一產品定義任何結構。從而用戶能在一經由其特性的抽象的高水平描述一產品，其優于按照冗長的文件列表的組成來描述。
3.4.6 一致性維護
CMA提供了配置的釋義和確認，其是基于一個對于產品的抽象描述也是基于有關形成配置的組件的使用用法成功或不成功的信息。數據建模便利的包括預先確定用戶所描述的配置的屬性和關系�；谀切⿲傩院完P系的語義，CMA能夠決定一配置（就是一系列組件的實例）是否是可用的。成為可用的，一配置必須是完全的，無歧義的，一致的和沒有歪斜的版本。這意味著一個配置必須有全部組件所需的實例組成且不必包括多重的一個組件的實例。屬性的等級描述了象約束，類型和版本這樣的用戶定義的特性。關系的等級表現了各種依賴性，例如，合理性，兼容性，構成，實例和可繼承的獨立性。每次一個新的配置被組建，CMA就利用經由先前對形成配置的組件的使用在數據庫中積累的信息。這樣，CMA預見配置是否可用。這種新的配置為了將來分析可用性而加入數據庫。從而，用戶能夠依靠系統來識別任何不一致以及在構建和重復使用用配置時保護此不一致。
3.5 團隊概念
描述工作在一個工程項目上的軟件工程團隊間的獨立、合作、同步的術語是工作區，透明檢查和協調。描述如下：
3.5.1 工作空間
工作空間為開發人員提供獨立的工作空間。
在“形狀”中的工作空間是被設計用來防止用戶之間的相互干擾。它提供了在配置管理下的能在可調對象上持續的工作空間。工作空間是通過版本狀態模型來獲得的。這就意味著屬性“狀態”是和構件的版本相連系的。依靠那種狀態（例如狀態“忙”或“凍結”），構件或者被認為是一個私有的工作區或者被認為是一個公有的庫�！懊Α睒嫾强烧{的并且不能被其他人所使用，象“凍結”就是一個對公共使用來說能獲得的但不可調的例子。構件被提交給公共庫的同時使得它們在被適當的用戶證明后，對公共用途來說是可獲得的。在效力上，工作區提供工作的獨立性且建立在一個全局的、長期的為不可調對象的庫和一個為可調對象且私有的短期的庫之間的區別。
3.5.2 透明視圖
透明視圖提供從主配置庫到工作區的訪問機制，該機制具有防止非法存取的功能。
軟件管理系統通過使工作區成為一個透明（清晰）的對象和提供在那個工作區的庫的透明檢查來增強了工作區的術語。這就意味著僅僅用戶感興趣的文件版本能在工作區中看到，所有其他的版本都不可見（盡管它們在物理上是存在的）。例如，任何對最新公有版本的變化都不需在工作區里顯示出來，用戶從公有變化中分離出來，并且工作區提供給用戶一個特定庫的外表。相關工作區版本計數的版本控制提供在工作區中。新版本是私有的并且在從工作區中釋放出來之前是不可能被公共用戶所見的。一個配置從公有庫中檢測出來提供給工作區。用戶訪問分配給自己的工作區。工作區里的組件有效地屬于那個工作區而非一個用戶。僅僅在那個工作區已登記的用戶才能改變配置，且僅有那個工作區的構件能被訪問�？偟膩碚f透明檢查通過防止對一個配置的非授權訪問而提供了一個檢查機制。
3.5.3 協調控制
協調控制協調開發組成員對同一配置項的修改。
網絡軟件環境（NSE）[12]協調控制代表了一個工作協調單元。它反應了工程的結構并且支持工作的獨立性、用戶間的相互影響和合并變化。一個協調包含一個環境和一系列命令。環境提供了類似于工作區和透明檢查的術語。它顯示了用來存儲資源和派生對象的目錄結構。那些命令，例如“獲得”、“退后”、“重新同步”和“解決”，在不同環境中提供相互活動。它們代表了用來協調和同步用戶間活動的協議，也代表了實際變化的通信。用戶獨立地工作在他們自己的環境里，改變相同的或不同的配置。用戶用配置的新版本來更新庫。網絡軟件環境支持將變化合并到庫里。但是它檢查什么已存在于庫里（可能被其他用戶放置在那兒）而且不和正在進行的變化產生沖突。假如有沖突，網絡軟件環境提示用戶注意合并問題，同時提供減少沖突的幫助。對于任何庫的變化，用戶能請求進入他們自己的工作區�？偠灾�，協調同步和協作團隊們改變工程產品的相同或不同部份。
3.6 光譜摘要和分析
圖2代表了一個不同配置管理系統的配置管理術語光譜。這些術語和它們的目標是：捕獲不可調文件歷史的庫；在配置管理下數據分布的已分布構件；一個工作單元計劃的合同；一套捕獲配置變化和允許最新版本獨立配置選項；增強一個組織軟件進化過程變化的生命周期模型；完整地描述和記錄結構和建立工程的系統建模；使得重使用的派生對象的對象池能優化產品構建；允許基于特性的配置選擇屬性而非一長串文件列表；支持持續的自動檢查和配置組件之間非持續的預測；分離可調配置的私有變化工作區；一個查看配置和防止非授權訪問的可調配置的透明檢查；一個協調配置變化的團隊協調。這些術語代表了配置管理系統功能方面的先進性。
光譜拓樸的目的是顯示一個術語的進化過程。例如，圖2從左到右總的來說有不同過程的建模、捕獲組件、描述產品的構件，優化產品工程。特定構件間相互關聯的協調團隊工作。光譜的“臂”顯示了相關過程。例如，需求變化和生命周期模型（如本書描述的一樣）是相關聯的：生命周期模型小計了一個特定變化需求模型，同時變化需求操作了一個庫。
有一些術語在光譜上沒有顯示。那些不能顯示的術語如：構件的細微進化（例如從版本標識到配置標識到不同配置的不同版本）；系統建模過程（例如從命令文件的進化到創造文件到系統模型如版本對象）；“角色”的識別和不同類型的變化（例如增強反病毒功能，病毒出現提示）；目前的研究工作。
在本書上簡化了從配置管理系統是提煉出來的術語。相對于已實施的系統來說是為了找到一些共同的術語。沒有共同的詞匯來表達術語。術語和它們的實施之間的區別并不總是清晰的。例如，工作區的實施在不同配置管理系統中變化，同時為用戶提供不同的功能。此外，工作區的術語應該是所有實施的最低共同命名或相反？既然協調統計了工作區和檢查的術語，那么工作區、透明檢查、協調又真的是同一術語嗎？或者它們真的如在光譜上顯示的一樣是三個術語嗎？
另外一個在提煉術語時的難點是大多數配置管理系統都有過多的術語。那就是一個術語有許多目的（這些目的在配置管理系統中通常是不統一的）。例如，Rational子系統術語在光譜中被看作為限制變化范圍而提供支持。然而，子系統比那個術語提供了更多的功能。它們能：提供一個名字范圍邊界，支持系統分區，代表一個基線，一個工作區，代表一個意思（為工作在不同的配置或一個團隊的同一配置）。檢查接口提供的細微變化或代表一個不可調的可執行的組件（在Rational術語中的一個“裝載檢查”）。因此，為了討論子系統，在其一個特定方面的磨合是必要的。此外，過多的術語使得提煉基本的術語變得困難。同樣，組合不同術語的不同部份，或一個特定術語的實施副影響都使得術語的提煉更加困難。例如，當考慮一個變化需求時，角色（象配置經理和測試經理）和生命周期術語（如開發和測試）對那個術語是至關重要的，或者它們是獨立的？
無論如何，這些術語的光譜為開發提供了一個起始點，或者至少從已存在的配置管理系統中提煉出一個配置管理模型——一組基本的配置管理服務。此外，需要進一步的工作來決定：光譜的使用價值，是否還有其它的術語，怎樣定義、命名和表達這些術語以及它們的多種語義，并且怎樣將這些術語組合成一套有用的配置管理系統。
4 配置管理系統的未來
圖2所示配置管理概念光譜圖表示了商用配置管理系統的典型概念。我們預計，隨著研究的繼續，和不斷從這些概念的結合使用中獲取經驗，光譜圖上的許多分支將會互相連接。這意味著，每個配置管理系統最終都可能將提供一個基本的配置管理服務集，從而更好地適應用戶需求。但是，即使不考慮是否每個配置管理系統設計者都試圖實現這些共同的特征，還有政治和技術方面的因素都會影響未來的軟件配置管理系統。（政治層面的因素是指與市場和標準化相關，技術因素則是關乎實現某一特定機制的可行性。）
一個主要的政治因素是關于CASE（計算機輔助軟件工程）工具的發展。例如：CASE工具經銷商是否應該假設環境經銷商會在他們的框架內提供配置管理支持，所以他們自己可以避免在他們的工具中實現配置管理�；蛘�，是否應該由CASE工具開發商在他們的工具中提供配置管理支持。如果CASE經銷商合并他們自己的配置管理支持，那么當用戶安裝不同的CASE工具時，用戶將不得不自己解決如何集成不同的CASE工具的問題。同樣，從經銷商的視角看，他們會真正重復去做那些已經被整個環境框架嘗試過的工作嗎？
另一方面，如果CASE經銷商不把配置管理合并到他們的工具中去，他們能依賴環境集成商提供合適的環境框架，去集成CASE工具并同時提供某種通用的配置管理能力嗎？這些問題的答案都是未知的。我們都可以看到，任何一種情況都意味著，對于環境來說，配置管理系統需要一定的標準化。反之亦然。
許多技術、研究方面的問題都影響著配置管理系統的能力，冒出來了如下這些問題：
什么適當的技術可作為配置管理系統的基礎？對象命名約定不變的面向的對象數據庫技術是最合適的嗎？在環境體系結構中軟件配置管理是在哪一層？它是否應該作為環境框架中一部分，放在數據庫的基礎層，還是把配置管理看作一個過程，處于體系結構的較高層？配置管理的機制能否從所有的配置管理功能中分離出來？也就是說，是否有一個標準的配置管理本質部分，能夠在任何環境中使用，并支持所有的配置管理功能。存在一個統一的配置管理模型嗎？是否可能提供分布式的配置管理支持？在地理上分散的軟件開發組能否與本地配置管理和系統集成使用同樣的配置管理系統。這是工業界的一個主要難題，尤其是對于國防合同承包商來說。配置管理支持跨軟件開發嗎？工程師是否能夠在主機上開發產品，然后在保持對產品的配置管理控制的同時輕易地將它轉移到目標機上去嗎？規模是配置管理系統的一個限制性因素嗎？配置管理對一百萬線產品的支持和對一兆線產品的支持是一樣的嗎？有可能將配置管理過程中，包括勞力密集型的部分，所有方面都建模，并在配置管理系統中實現它嗎？
對以上這些問題的回答都不是顯而易見的。因為很可能要管理的過程有著不同的來源，從配置管理系統經銷商，開發環境集成商，研究人員，工具繼承商，軟件過程建模論壇，還有計算機輔助設計，計算機輔助工程，計算機集成制造等不同的領域。
5 結論
配置管理是對軟件產品發展演化進行的管理。從配置管理系統的操作層面上看，配置管理是認證，控制，狀態統計，審計，評估，制造，過程管理和團組合作。它是軟件工程領域的一部分。它的工作對象是這個領域中產生的過程。這從概念光譜圖可以明顯地看出來，同樣也可以從已有的配置管理系統的數量和它們的能力看出來。本文的光譜圖表示的是許多不同的配置管理系統經已實現的概念的一個快照。每個存在的系統的重點都不同，在用戶問題——包括角色，集成，控制，自動化層，過程等等，與產品支持，什么時候是開始使用配置管理的最佳時機，系統能提供哪些功能等之間進行競爭和權衡。希望提供這個光譜圖能夠有助于對配置管理系統能力的理解，并且提供一個討論配置管理支持工具的通用框架。
6 附錄：CM體系總覽
這個附錄給出了此份論文中前面章節提到的不同CM體系能力的總體印象。既不是整個體系的評估也不是完整描述，目的只是讓讀者對下列CM體系能力范圍有一個了解，這些是存在于今天的不同種類的CM體系的代表：Adele, ADC, CCC, CMA, DMS, DSEE, ISTAR, Jasmine, LifeSPAN, NSE, PowerFrame, Rational, RCS, “shape”, SMS。這些體系在下面描述。
6.1 Adele
Adele是一個來自于格勒諾布爾大學的配置管理體系。它的基本特征是數據模型，屆面檢查，展示產品系列，配置建立和工作現場控制。Adele是用來成為軟件工程環境的核心。Adele數據庫是一個實體關系，一個為物件提供定義，如界面和它們的實現（instances of bodies），配置和家族。物件有特性：描述它們的特點，和DEP關系：描述它們的從屬關系，Adele用這些功能來幫助組成配置。使用者可以指定一種基于合意的特性的配置。特性可以用戶定義或體系定義。用戶可以指定規則基于特征價值，局限和優先。Adele可以探測到不完整和不連續的配置描述。
6.2 Aide-De-Camp (ADC)
ADC, 來源于Software Maintenance and Development Systems, Inc.，由基本的ADC體系和一個看守系統組成�；镜腁DC提供了一個數據庫以獲取CM信息。用戶在文件內定義特征和關系。數據庫可以貯存資源和二進制碼，它貯存易變的(“塑料”)和不變的（“安裝的”）信息。ADC的列表處理語言有效地允許用戶在一個文件或一組文件上工作。ADC沖突解決方案在登陸（check-in）和標記時執行。改變設置俘獲改變了配置和允許用戶指定任何版本的通過一個改變設置清單從而創建它們自己的版本樹。報告可基于數據內容而產生。程序建立得到支持，結構的關系被自動得到。一些非—ADC的CM信息可以輸入至ADC數據庫。監管系統直接支持配置，集成問題報告，改變需求，和了解用戶，承擔分派工作指令和建立當地的工作站（“干凈房間”）的角色。這意味著當一個變化需求被送到CM經理并得到認可時，經理把工作分派給軟件工程師。當工程師執行那項活動時，一個被復制的本地的路徑和文件工作站建立了。一旦工程師完成那項工作，工作站自動刪除，變化被加入數據庫。
6.3 Change and Configuration Control (CCC)
Softool的CCC（稱為CCC/發展和維護）被作為一個監管系統或作為一個本地的產品出售。CCC提供一個變化控制方法論，配置標識和狀態會計，以及起源建筑。所有的這些被用來假定瀑布生命周期模型。CCC下的部件在適當的認可之后，經過了不同階段的生命周期。CCC支持一些文件化的標準。五個等級的客戶構成權限的層次列入數據庫。他們是數據庫管理員，CM經理，項目經理，開發者，及測試經理。一些層次的通道控制了存在，例如密碼控制，用戶等級，指定數據或改變需求分配。CCC數據庫層次，代表產品的結構，由多層次數據結構組成，包括數據庫，體系，配置，模塊和文本。編碼的平行版本可用于通過實質拷貝實現同時發展。這些可以合并或選擇，變化可跨配置運用。在合并中沖突可監測到。CCC的變化需求，如項目，可以處理一個部件的小變化，或產品的下一次發布所需的所有變化。電子郵件事件通知與變化需求相關。緊急變化繞過大多數的變化控制是允許的。
6.4 Configuration Mnanagement Assistant (CMA)
來自于TARTAN實驗室的CMA提供mechanism（無方針）創建CM系統。Mechanism使用的是實體關系特性數據庫。特性和關系的等級詳細說明了部件的特征，一個產品的分解和部件之間的相互依賴。特性的等級是分割，演示，和版本；關系的等級是邏輯從屬，一致性，兼容性，部件，立即和可繼承的從屬性。CMA用來錄制和獲取配置描述，部件的組成，錄制和獲取關于一個配置的部件之間已知的（不）一致性和從屬性。它預告新形成的配置的完整性，不明確，和一致性。任何數據庫的變化是通過對簡單“交易”的承諾產生的。每種配置可以有它自己的通道控制mechanism。配置之間的名字沖突通過使用間隔來避免。
6.5 Design Management System (DMS)
來自于SHERPA公司的DMS適用于電腦輔助設計/工程師市場和硬件的一部份，設計工程師環境。DMS提供邏輯的集中倉庫，內含清晰的分布的數據。文檔可包含任何種類的信息，如ASCII，圖形，以及設計數據。文檔的版本通過當地操作系統的版本控制來實現。所有信息（產品結構，發布程序，事件警告，用戶定義特性和關系）被集中在一個核心的數據庫�！鞍l布”的意見通過促銷水平（代表項目通過時的臺階）獲取。這些代表公司方針用于評審，確認或完畢信號。用戶可以指定誰可以獲得什么樣的數據，數據群，誰應該被告知狀態變化，完畢信號及促銷需要什么樣的確認和檢查。DMS通道控制是在用戶等級和promotion level of file的基礎上實現的，文檔名可以加密，實質的團隊可以定義（這些是地理上分散但分享同一數據庫的用戶）�？梢笞詣油礁禄蚍峙�。變化可以在小組成員間得到交流溝通。不管在網絡的哪個地方，文檔的最新版本都可以定位。DMS用這個結構來執行檢查。并可提供報告及預評審。變化需求（包括相關文件）確認后自動隨附。
6.6 Domain Software Engineering Environment(DSEE)
DSEE 提供版本控制、系統建模、配置發放、分散系統建立、物件組、用以查找要做的事務及已經完成任務的任務單、將特殊事件通知用戶的控制。版本控制置于一資源文檔庫中。一DSEE系統模型是對一產品或產品一部分的描述。它是一針對靜態和結構特點的公開描述，包括資源文檔、派生物件和從屬工具、組件的階層、創建規則、創建順序、數據庫及路徑的確定、轉換工具的選擇和一些控制過程規則。
6.7 ISTAR
ISTAR來自于imperial software technology ltd. 是一個環境設計的特別用來支持項目管理的。軟件項目個體之間的關系被模仿為合同。一個合同理論上是對期望產品的描述，并被構造成數據庫。一個配置是在合同之間移轉的單元，移轉時被認為是“凍結的”。合同的移轉暗示了一定的任務或階段已完成。CM為合同數據庫內的項目而存在，并在合同之間可交付。為數據庫內的部件提供繼承者和不同的控制。用戶可以定義CM部件之間的關系，可以為問題報告分配部件。這是對系統建立的支持。
6.8 JASMINE
JASMINE是應用于室內CM的XEROX信息系統分配上開發的大型程序設計系統。系統模型是其核心。它描述一個軟件系統，這個軟件系統使用在設置和功能上構建的代數模式。用戶能用這個代數模式來定義復雜的詢問和簡單的譯本。軟件結構則被定義在模板中，翻譯捆綁體由圖象支持，后繼的翻譯記錄在一個族中，這個族支持并行開發。專業譯文被分類后組織成特殊歷史記錄（如：一個項目專業歷史記錄）正文內容和這些族均被提供給譯本，同時定義它的語法結構和連貫性。
JASMINE工具利用系統模型信息拷貝文件并存檔，編譯源代碼，瀏覽并釋放空間。
6.9 LIFESPAN
生命期來自YARD軟件系統，嚴格支持變化控制。它適用于項目經理監控各種變化的情形，只有經過授權的用戶才能使用它。生命期使用相關的數據庫和詢問語言，存儲文字、二進制代碼和圖表，并為這些項目提供版本控制。
目標集BELONG TO。。。負責批準對包進行改動的管理人員被指派此包。生命期使用制圖辦公模型，這些模型建立在硬件設計方法論的基礎上。它識別狀態量，偏移量，偏移觸發器，命令行和用戶權限。電子郵件提供自動識別功能。報告建立在庫存項目基礎上，并可以進行改動。在安全方面，配置項目設有密碼和加密的文件名。它支持各種國際標準的問題的提出，跟蹤和正式改動控制。
一般認為測試信息也是一種配置項，它依賴于其它項目。生命期監控改動的一致性標準過程。它決定什么系統使用回顧性模塊，標識所有需要被納入回顧系統的開發人員并發布必要的控制文件。
改動一經批準，如何授權它并分配源代碼是一項管理策略。以上工作完成后，項目被從存儲區調出，模擬，以開發項的身份重新提交。此過程重復進行。
6.10 Network Software Environment（NSE）
由SUN軟件系統開發的NSE是管理操作系統目錄結構并從源代碼獲取附加文件的一套應用體，附帶一個數據庫。NSE為開發代碼的項目組提供工作空間。此工作空間通過一個合并并升級處于子空間和父空間之間的文件的協議來支持遞歸轉換。工作空間里的文件表示為一種結構體，它代表對這種結構體的多種版本，除了最后一種，其它的結構體都是不可變的。同一個工作空間的不同用戶在此工作時都得經過檢查并登記在文件中。合并交叉工作空間的沖突問題NSE提供了交互性支持。工作空間能夠高效地獲取目錄結構，這種目錄結構用于存儲源代碼并從產品，已建成的結構體和產品的邏輯結構中衍生構件。
6.11 PowerFrame
Powerframe這個工具來自EDA系統，對計算機輔助設計工作提供配置管理。它用一種統一的圖解接口把用戶屏敝在操作系統和文件系統之外。操作時，用戶拖出一個合適的工具菜單。POWERFRAME自動檢索所有相關數據，運行這個工具，在用戶使用完畢時保存所有的改動。POWERFRAME把在產品中數據的幾種組織方式合并起來以便用戶集中精力于那些僅適合于完成特定任務的數據，工程，一個展望，一個見解和一個數據包。一項工程是一個數據的集合，這些數據構成協作體的主題（如，一個包含了所有電流設計線路文件版本的產品）。一項展望是一套工作，專業工程師任何時間都可以使用這個裝置的文件版本。見解使用戶集中精力于設計的特定方向（如，那些僅與邏輯顯示和規劃布局有并的信息將被顯示），一個數據包是一個邏輯單元（如算術邏輯單元），這個邏輯單是正在設計的幾個組件的抽象。它允許諸如由不同工具產生的細節數據被隱蔽并在需要時獲得。在效果上，POWERFRAME把此摘要的所有相關信息分類。一部份對象由某版本控制，其它的在檢測中確定其版本。
6.12 Rational
RATIONAL的環境體支持開發大型ADA產品的軟件人員組。RATIONAL的計算機管理設備依賴于其子系統。ADA程序庫與它們的計算機管理系統交互相關，一個子系統代表ADA產品的一部份。子系統可以獨立于產品的其它部份僅由一個軟件工程師開發或者由一個工作組協同完成。一個子系統有一個版本標識符，可以被釋放回收。不同版本的子系統可以同時操作，其差異被合并，子系統之間也可以進行合并。通過活動桌面可以分辨出哪些子系統的哪些版本要進行合并。
RATIONAL提供對ADA單元重編譯最小化的機制。通過子系統ADA單元被放置在版本控制器中。用戶可以根據設計需要開啟，關閉版本控制器。
6.13 Revision Control System(RCS)
修訂控制系統（RCS）是一套由W.Tichy開發的，庫里的源文件提供版本控制器的工具。庫對每個文件建立一棵版本樹。樹上的一個分支代表文件里的一個變量。RCS對版本和分支的操作自帶一套計數方案，為了節省空間并且盡快獲取最近的版本，我們只存儲文件版本之間的差異。獲取文件庫的通常使用模式包括用戶檢索庫文件的特定版次（通過鎖定方式），修改文件。修改完畢后登記回原版本所在的出處。與此同時，RCS會記錄修改的細節，如作者，日期，時間和修改原因。如果需要，RCS可以自動將一個特有的標識放入文件。RCS能對比文件的不同版本，終止一項配置以及通過識別源代碼行的差別合并各個分支。庫文件標志（如配置標志或狀態標志）可以用于標識文件之間的關連。
6.14 SHAPE
SHAPE系統來自柏林大學，它借助版本狀態，配置標識符為我們提供一個帶有特定文件系統，版本控制器和工作間的庫。它集成系統模型設備并從中獲取二進制代碼池。我們可以通過用戶定義/系統定義的屬性模式描述各項配置。串行和并行的配置版本均支持開發組件。工作間由版本的狀態量激活。此版本還可以確定文件的不穩定性。工作間文件的狀態值“忙”“已保存”“激活”以及公用辦公數據庫使用的狀態值“已打印”“完成”和“終止”相互轉換。
6.15 Software Management System
軟件管理系統（SMS），提供版本控制，工作區管理，系統模擬，。。。改變庫探測方式，對接口說明書進行加工，以及對基于屬性的版本區進行加工。工作于與任務相關的版本時，工作區提供保護措施并支持對每個任何基底的認證和登陸。
一旦特殊事件發生，物件的變動就受到監控和跟蹤。已獲取的物件有一個連續狀態量，（“合法”“受保護”“廢止”“非法”）用來代表與已構成系統的關系；此物件還帶有一個程度狀態量（“同意”“警告”“嚴重錯誤”），用來指明版本的一致性。
（出處被我遺忘，以后補上 blueski）
文章來源于領測軟件測試網 http://www.kjueaiud.com/
