图2代表了一个不同配置管理系统的配置管理术语光谱。这些术语和它们的目标是：捕获不可调文件历史的库；在配置管理下数据分布的已分布构件；一个工作单元计划的合同；一套捕获配置变化和允许最新版本独立配置选项；增强一个组织软件进化过程变化的生命周期模型；完整地描述和记录结构和建立工程的系统建模；使得重使用的派生对象的对象池能优化产品构建；允许基于特性的配置选择属性而非一长串文件列表；支持持续的自动检查和配置组件之间非持续的预测；分离可调配置的私有变化工作区；一个查看配置和防止非授权访问的可调配置的透明检查；一个协调配置变化的团队协调。这些术语代表了配置管理系统功能方面的先进性。
光谱拓朴的目的是显示一个术语的进化过程。例如，图2从左到右总的来说有不同过程的建模、捕获组件、描述产品的构件，优化产品工程。特定构件间相互关联的协调团队工作。光谱的“臂”显示了相关过程。例如，需求变化和生命周期模型（如本书描述的一样）是相关联的：生命周期模型小计了一个特定变化需求模型，同时变化需求操作了一个库。
有一些术语在光谱上没有显示。那些不能显示的术语如：构件的细微进化（例如从版本标识到配置标识到不同配置的不同版本）；系统建模过程（例如从命令文件的进化到创造文件到系统模型如版本对象）；“角色”的识别和不同类型的变化（例如增强反病毒功能，病毒出现提示）；目前的研究工作。
在本书上简化了从配置管理系统是提炼出来的术语。相对于已实施的系统来说是为了找到一些共同的术语。没有共同的词汇来表达术语。术语和它们的实施之间的区别并不总是清晰的。例如，工作区的实施在不同配置管理系统中变化，同时为用户提供不同的功能。此外，工作区的术语应该是所有实施的最低共同命名或相反？既然协调统计了工作区和检查的术语，那么工作区、透明检查、协调又真的是同一术语吗？或者它们真的如在光谱上显示的一样是三个术语吗？
另外一个在提炼术语时的难点是大多数配置管理系统都有过多的术语。那就是一个术语有许多目的（这些目的在配置管理系统中通常是不统一的）。例如，Rational子系统术语在光谱中被看作为限制变化范围而提供支持。然而，子系统比那个术语提供了更多的功能。它们能：提供一个名字范围边界，支持系统分区，代表一个基线，一个工作区，代表一个意思（为工作在不同的配置或一个团队的同一配置）。检查接口提供的细微变化或代表一个不可调的可执行的组件（在Rational术语中的一个“装载检查”）。因此，为了讨论子系统，在其一个特定方面的磨合是必要的。此外，过多的术语使得提炼基本的术语变得困难。同样，组合不同术语的不同部份，或一个特定术语的实施副影响都使得术语的提炼更加困难。例如，当考虑一个变化需求时，角色（象配置经理和测试经理）和生命周期术语（如开发和测试）对那个术语是至关重要的，或者它们是独立的？
无论如何，这些术语的光谱为开发提供了一个起始点，或者至少从已存在的配置管理系统中提炼出一个配置管理模型——一组基本的配置管理服务。此外，需要进一步的工作来决定：光谱的使用价值，是否还有其它的术语，怎样定义、命名和表达这些术语以及它们的多种语义，并且怎样将这些术语组合成一套有用的配置管理系统。
4 配置管理系统的未来图2所示配置管理概念光谱图表示了商用配置管理系统的典型概念。我们预计，随着研究的继续，和不断从这些概念的结合使用中获取经验，光谱图上的许多分支将会互相连接。这意味着，每个配置管理系统最终都可能将提供一个基本的配置管理服务集，从而更好地适应用户需求。但是，即使不考虑是否每个配置管理系统设计者都试图实现这些共同的特征，还有政治和技术方面的因素都会影响未来的软件配置管理系统。（政治层面的因素是指与市场和标准化相关，技术因素则是关乎实现某一特定机制的可行性。）
一个主要的政治因素是关于CASE（计算机辅助软件工程）工具的发展。例如：CASE工具经销商是否应该假设环境经销商会在他们的框架内提供配置管理支持，所以他们自己可以避免在他们的工具中实现配置管理。或者，是否应该由CASE工具开发商在他们的工具中提供配置管理支持。如果CASE经销商合并他们自己的配置管理支持，那么当用户安装不同的CASE工具时，用户将不得不自己解决如何集成不同的CASE工具的问题。同样，从经销商的视角看，他们会真正重复去做那些已经被整个环境框架尝试过的工作吗？
另一方面，如果CASE经销商不把配置管理合并到他们的工具中去，他们能依赖环境集成商提供合适的环境框架，去集成CASE工具并同时提供某种通用的配置管理能力吗？这些问题的答案都是未知的。我们都可以看到，任何一种情况都意味着，对于环境来说，配置管理系统需要一定的标准化。反之亦然。
许多技术、研究方面的问题都影响着配置管理系统的能力，冒出来了如下这些问题：
什么适当的技术可作为配置管理系统的基础？对象命名约定不变的面向的对象数据库技术是最合适的吗？在环境体系结构中软件配置管理是在哪一层？它是否应该作为环境框架中一部分，放在数据库的基础层，还是把配置管理看作一个过程，处于体系结构的较高层？配置管理的机制能否从所有的配置管理功能中分离出来？也就是说，是否有一个标准的配置管理本质部分，能够在任何环境中使用，并支持所有的配置管理功能。存在一个统一的配置管理模型吗？是否可能提供分布式的配置管理支持？在地理上分散的软件开发组能否与本地配置管理和系统集成使用同样的配置管理系统。这是工业界的一个主要难题，尤其是对于国防合同承包商来说。配置管理支持跨软件开发吗？工程师是否能够在主机上开发产品，然后在保持对产品的配置管理控制的同时轻易地将它转移到目标机上去吗？规模是配置管理系统的一个限制性因素吗？配置管理对一百万线产品的支持和对一兆线产品的支持是一样的吗？有可能将配置管理过程中，包括劳力密集型的部分，所有方面都建模，并在配置管理系统中实现它吗？
对以上这些问题的回答都不是显而易见的。因为很可能要管理的过程有着不同的来源，从配置管理系统经销商，开发环境集成商，研究人员，工具继承商，软件过程建模论坛，还有计算机辅助设计，计算机辅助工程，计算机集成制造等不同的领域。
文章来源于领测软件测试网 https://www.ltesting.net/
