圖2代表了一個不同配置管理系統的配置管理術語光譜。這些術語和它們的目標是：捕獲不可調文件歷史的庫；在配置管理下數據分布的已分布構件；一個工作單元計劃的合同；一套捕獲配置變化和允許最新版本獨立配置選項；增強一個組織軟件進化過程變化的生命周期模型；完整地描述和記錄結構和建立工程的系統建模；使得重使用的派生對象的對象池能優化產品構建；允許基于特性的配置選擇屬性而非一長串文件列表；支持持續的自動檢查和配置組件之間非持續的預測；分離可調配置的私有變化工作區；一個查看配置和防止非授權訪問的可調配置的透明檢查；一個協調配置變化的團隊協調。這些術語代表了配置管理系統功能方面的先進性。
光譜拓樸的目的是顯示一個術語的進化過程。例如，圖2從左到右總的來說有不同過程的建模、捕獲組件、描述產品的構件，優化產品工程。特定構件間相互關聯的協調團隊工作。光譜的“臂”顯示了相關過程。例如，需求變化和生命周期模型（如本書描述的一樣）是相關聯的：生命周期模型小計了一個特定變化需求模型，同時變化需求操作了一個庫。
有一些術語在光譜上沒有顯示。那些不能顯示的術語如：構件的細微進化（例如從版本標識到配置標識到不同配置的不同版本）；系統建模過程（例如從命令文件的進化到創造文件到系統模型如版本對象）；“角色”的識別和不同類型的變化（例如增強反病毒功能，病毒出現提示）；目前的研究工作。
在本書上簡化了從配置管理系統是提煉出來的術語。相對于已實施的系統來說是為了找到一些共同的術語。沒有共同的詞匯來表達術語。術語和它們的實施之間的區別并不總是清晰的。例如，工作區的實施在不同配置管理系統中變化，同時為用戶提供不同的功能。此外，工作區的術語應該是所有實施的最低共同命名或相反？既然協調統計了工作區和檢查的術語，那么工作區、透明檢查、協調又真的是同一術語嗎？或者它們真的如在光譜上顯示的一樣是三個術語嗎？
另外一個在提煉術語時的難點是大多數配置管理系統都有過多的術語。那就是一個術語有許多目的（這些目的在配置管理系統中通常是不統一的）。例如，Rational子系統術語在光譜中被看作為限制變化范圍而提供支持。然而，子系統比那個術語提供了更多的功能。它們能：提供一個名字范圍邊界，支持系統分區，代表一個基線，一個工作區，代表一個意思（為工作在不同的配置或一個團隊的同一配置）。檢查接口提供的細微變化或代表一個不可調的可執行的組件（在Rational術語中的一個“裝載檢查”）。因此，為了討論子系統，在其一個特定方面的磨合是必要的。此外，過多的術語使得提煉基本的術語變得困難。同樣，組合不同術語的不同部份，或一個特定術語的實施副影響都使得術語的提煉更加困難。例如，當考慮一個變化需求時，角色（象配置經理和測試經理）和生命周期術語（如開發和測試）對那個術語是至關重要的，或者它們是獨立的？
無論如何，這些術語的光譜為開發提供了一個起始點，或者至少從已存在的配置管理系統中提煉出一個配置管理模型——一組基本的配置管理服務。此外，需要進一步的工作來決定：光譜的使用價值，是否還有其它的術語，怎樣定義、命名和表達這些術語以及它們的多種語義，并且怎樣將這些術語組合成一套有用的配置管理系統。
4 配置管理系統的未來圖2所示配置管理概念光譜圖表示了商用配置管理系統的典型概念。我們預計，隨著研究的繼續，和不斷從這些概念的結合使用中獲取經驗，光譜圖上的許多分支將會互相連接。這意味著，每個配置管理系統最終都可能將提供一個基本的配置管理服務集，從而更好地適應用戶需求。但是，即使不考慮是否每個配置管理系統設計者都試圖實現這些共同的特征，還有政治和技術方面的因素都會影響未來的軟件配置管理系統。（政治層面的因素是指與市場和標準化相關，技術因素則是關乎實現某一特定機制的可行性。）
一個主要的政治因素是關于CASE（計算機輔助軟件工程）工具的發展。例如：CASE工具經銷商是否應該假設環境經銷商會在他們的框架內提供配置管理支持，所以他們自己可以避免在他們的工具中實現配置管理�；蛘�，是否應該由CASE工具開發商在他們的工具中提供配置管理支持。如果CASE經銷商合并他們自己的配置管理支持，那么當用戶安裝不同的CASE工具時，用戶將不得不自己解決如何集成不同的CASE工具的問題。同樣，從經銷商的視角看，他們會真正重復去做那些已經被整個環境框架嘗試過的工作嗎？
另一方面，如果CASE經銷商不把配置管理合并到他們的工具中去，他們能依賴環境集成商提供合適的環境框架，去集成CASE工具并同時提供某種通用的配置管理能力嗎？這些問題的答案都是未知的。我們都可以看到，任何一種情況都意味著，對于環境來說，配置管理系統需要一定的標準化。反之亦然。
許多技術、研究方面的問題都影響著配置管理系統的能力，冒出來了如下這些問題：
什么適當的技術可作為配置管理系統的基礎？對象命名約定不變的面向的對象數據庫技術是最合適的嗎？在環境體系結構中軟件配置管理是在哪一層？它是否應該作為環境框架中一部分，放在數據庫的基礎層，還是把配置管理看作一個過程，處于體系結構的較高層？配置管理的機制能否從所有的配置管理功能中分離出來？也就是說，是否有一個標準的配置管理本質部分，能夠在任何環境中使用，并支持所有的配置管理功能。存在一個統一的配置管理模型嗎？是否可能提供分布式的配置管理支持？在地理上分散的軟件開發組能否與本地配置管理和系統集成使用同樣的配置管理系統。這是工業界的一個主要難題，尤其是對于國防合同承包商來說。配置管理支持跨軟件開發嗎？工程師是否能夠在主機上開發產品，然后在保持對產品的配置管理控制的同時輕易地將它轉移到目標機上去嗎？規模是配置管理系統的一個限制性因素嗎？配置管理對一百萬線產品的支持和對一兆線產品的支持是一樣的嗎？有可能將配置管理過程中，包括勞力密集型的部分，所有方面都建模，并在配置管理系統中實現它嗎？
對以上這些問題的回答都不是顯而易見的。因為很可能要管理的過程有著不同的來源，從配置管理系統經銷商，開發環境集成商，研究人員，工具繼承商，軟件過程建模論壇，還有計算機輔助設計，計算機輔助工程，計算機集成制造等不同的領域。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
