神马文学网配置管理系统中的概念
来源：百度文库 编辑：神马文学网 时间：2024/04/27 09:53:02
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），由它负责批准对软件系统的更改]，和批准更改的机制。经理负责为工程人员创建并宣导任务单，基本上创建项目的框架。同时，经理还收集软件系统中构件的相关数据，比如说用以判断系统中出现问题的构件的信息。
对于软件工程人员，他们的目标是有效地创造出产品。这就意味着工程人员在创建产品、编码测试及支持文档的产生中不必相互间干涉。与此同时，他们能有效地进行沟通与协作。他们利用工具以帮助创建性能一致的软件产品，通过相互通知要求的任务和完成的任务来进行沟通与协调。做出的更改通过将它们进行融合、分散和冲击而得知。产品中的所有元素的演变连同其更改的原因及实际更改的记录都予以保留。工程人员在创建、变更、测试及编码的汇合上有自己的工作范围。在某一点上，编码会形成一个基线，它使得进一步开发得以延续，为其它平行开发得以进行。
测试的目标是确保产品经过测试达到要求。这里包括产品某一特定版本的测试和对某个产品的某种测试及其结果予以记录。将错误报告给相关人员并通过回归测试进行修补。
质量保证经理的目标是确保产品的高质量。这意味着特定的规程和方针应当完成并得到相关的批准。错误应得到纠正并应对变化的部分进行充分测试。客户投诉应予以跟踪。
不同的客户使用的产品版本也是不同的。客户总是遵循规则来做变更要求、错误显示及产品改进。
理想的CM系统在这种情形下应能够支持所有这些目标、角色和任务。这也意味着这些角色、任务和目标决定了一CM系统要求的功能。本文提出的一些概念就是为了解决这些问题。
1.4 本文的结构
在简介中就CM和CM系统进行了定义，列出一典型的CM情形，这样一来也就暗示了CM体系的要求。第二节描述了CM系统中以用户为导向的一些问题。这些问题影响用户对CM系统的期望。第三节描述了CM概念谱。第四对CM体系的未来做了探讨，第五节是结论。附录是本文CM体系索引的概览。
2 CM体系用户的有关问题
许多与CM有关的问题直接影响到CM系统的用户。现有的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系统这么用，它对于用户和产品的演变历史都有一定程度的控制。它将驱动用户的过程并将其加强。现有的CM系统提供或松或紧的控制水平但很少能灵活地允许用户选择控制的种类。
2.5 过程与产品的区分
CM包括过程和产品。CM过程表示执行CM是所需的一系列工作任务。从根本上讲，过程是一个计划，它定义要做什么、谁来做及如何做。支持这过程是管理的功能。过程模型将组织的方针、程序和软件开发生命周期模型通盘考虑。CM的产品是工程管理任务的结果。CM系统的功能需要为二者予以支持。现有的CM系统提供一些产品及过程的支持，但在同一CM系统中一般不能形成对二者完全支持。
2.6 CM自动化水平
目前，CM一般是手工和自动程序二者兼而有之。无需任何在线支持来实施CM也是可能的。但这样做的效率很低。我们的目标是将CM中非创造性的部分尽量多地自动化。譬如，书面更改表格和对此回应的监控一般只在组织方针里予以记录，而不能在线获取与加强。
2.7 CM系统功能
现有的CM系统提供的只是所有不同种类的用户的部分功能。但随时间的推移和用户的需求和环境结构的能力得到更好理解后，这种情况将可能得以改进。以下部分描述的是现有CM系统概念范围。
3 配置管理系统概念光谱图
以上部分解释了有关配置管理系统需求问题的范围，本部分将细述配置管理系统的具体功能，并对于支持前文所述某些功能的概念特别加以考察。这些概念将被组织成一幅光谱图来表示配置管理系统的演化过程。每个概念都将置于一个特定的配置管理系统中来描述。以下是要讨论的我们感兴趣的配置管理系统概念中的功能，包括：组件，过程，结构和特色架构的组合，团队概念。图2展示了整个概念光谱图和它们对应的，有代表性的配置管理系统实例，然后给出每个概念的一个简单描述并着重突出它的优势。在本部分的末尾，将对概念和概念光谱图的作用和局限性作一个分析总结。
演化的方向
概念
图例：
*系统实例
*表示本节点所示概念的系统实例
系统建模
对象池
库
文本管理
分布式组件
生命周期模型
需求变更
属性
工作空间
透明视图
事务
一致性维护
子系统
更改集
约定
LIFESPAN*
PowerFrame*
SherpaDMS*
NSE*
SMS*
Shape*
DSEE*
Adele*
CMA*
Jasmine*
Rational*
ADC*
ISTAR*
CCC*
RCS*
图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提供了配置的释义和确认，其是基于一个对于产品的抽象描述也是基于有关形成配置的组件的使用用法成功或不成功的信息。数据建模便利的包括预先确定用户所描述的配置的属性和关系。基于那些属性和关系的语义，CMA能够决定一配置（就是一系列组件的实例）是否是可用的。成为可用的，一配置必须是完全的，无歧义的，一致的和没有歪斜的版本。这意味着一个配置必须有全部组件所需的实例组成且不必包括多重的一个组件的实例。属性的等级描述了象约束，类型和版本这样的用户定义的特性。关系的等级表现了各种依赖性，例如，合理性，兼容性，构成，实例和可继承的独立性。每次一个新的配置被组建，CMA就利用经由先前对形成配置的组件的使用在数据库中积累的信息。这样，CMA预见配置是否可用。这种新的配置为了将来分析可用性而加入数据库。从而，用户能够依靠系统来识别任何不一致以及在构建和重复使用用配置时保护此不一致。
3.5 团队概念
描述工作在一个工程项目上的软件工程团队间的独立、合作、同步的术语是工作区，透明检查和协调。描述如下：
3.5.1 工作空间
工作空间为开发人员提供独立的工作空间。
在“形状”中的工作空间是被设计用来防止用户之间的相互干扰。它提供了在配置管理下的能在可调对象上持续的工作空间。工作空间是通过版本状态模型来获得的。这就意味着属性“状态”是和构件的版本相连系的。依靠那种状态（例如状态“忙”或“冻结”），构件或者被认为是一个私有的工作区或者被认为是一个公有的库。“忙”构件是可调的并且不能被其他人所使用，象“冻结”就是一个对公共使用来说能获得的但不可调的例子。构件被提交给公共库的同时使得它们在被适当的用户证明后，对公共用途来说是可获得的。在效力上，工作区提供工作的独立性且建立在一个全局的、长期的为不可调对象的库和一个为可调对象且私有的短期的库之间的区别。
3.5.2 透明视图
透明视图提供从主配置库到工作区的访问机制，该机制具有防止非法存取的功能。
软件管理系统通过使工作区成为一个透明（清晰）的对象和提供在那个工作区的库的透明检查来增强了工作区的术语。这就意味着仅仅用户感兴趣的文件版本能在工作区中看到，所有其他的版本都不可见（尽管它们在物理上是存在的）。例如，任何对最新公有版本的变化都不需在工作区里显示出来，用户从公有变化中分离出来，并且工作区提供给用户一个特定库的外表。相关工作区版本计数的版本控制提供在工作区中。新版本是私有的并且在从工作区中释放出来之前是不可能被公共用户所见的。一个配置从公有库中检测出来提供给工作区。用户访问分配给自己的工作区。工作区里的组件有效地属于那个工作区而非一个用户。仅仅在那个工作区已登记的用户才能改变配置，且仅有那个工作区的构件能被访问。总的来说透明检查通过防止对一个配置的非授权访问而提供了一个检查机制。
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体系和一个看守系统组成。基本的ADC提供了一个数据库以获取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，图形，以及设计数据。文档的版本通过当地操作系统的版本控制来实现。所有信息（产品结构，发布程序，事件警告，用户定义特性和关系）被集中在一个核心的数据库。“发布”的意见通过促销水平（代表项目通过时的台阶）获取。这些代表公司方针用于评审，确认或完毕信号。用户可以指定谁可以获得什么样的数据，数据群，谁应该被告知状态变化，完毕信号及促销需要什么样的确认和检查。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），提供版本控制，工作区管理，系统模拟，。。。改变库探测方式，对接口说明书进行加工，以及对基于属性的版本区进行加工。工作于与任务相关的版本时，工作区提供保护措施并支持对每个任何基底的认证和登陆。
一旦特殊事件发生，物件的变动就受到监控和跟踪。已获取的物件有一个连续状态量，（“合法”“受保护”“废止”“非法”）用来代表与已构成系统的关系；此物件还带有一个程度状态量（“同意”“警告”“严重错误”），用来指明版本的一致性。
现在，软件配置管理的环境及其工具越来越得到人们的重视，这一点从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），由它负责批准对软件系统的更改]，和批准更改的机制。经理负责为工程人员创建并宣导任务单，基本上创建项目的框架。同时，经理还收集软件系统中构件的相关数据，比如说用以判断系统中出现问题的构件的信息。
对于软件工程人员，他们的目标是有效地创造出产品。这就意味着工程人员在创建产品、编码测试及支持文档的产生中不必相互间干涉。与此同时，他们能有效地进行沟通与协作。他们利用工具以帮助创建性能一致的软件产品，通过相互通知要求的任务和完成的任务来进行沟通与协调。做出的更改通过将它们进行融合、分散和冲击而得知。产品中的所有元素的演变连同其更改的原因及实际更改的记录都予以保留。工程人员在创建、变更、测试及编码的汇合上有自己的工作范围。在某一点上，编码会形成一个基线，它使得进一步开发得以延续，为其它平行开发得以进行。
测试的目标是确保产品经过测试达到要求。这里包括产品某一特定版本的测试和对某个产品的某种测试及其结果予以记录。将错误报告给相关人员并通过回归测试进行修补。
质量保证经理的目标是确保产品的高质量。这意味着特定的规程和方针应当完成并得到相关的批准。错误应得到纠正并应对变化的部分进行充分测试。客户投诉应予以跟踪。
不同的客户使用的产品版本也是不同的。客户总是遵循规则来做变更要求、错误显示及产品改进。
理想的CM系统在这种情形下应能够支持所有这些目标、角色和任务。这也意味着这些角色、任务和目标决定了一CM系统要求的功能。本文提出的一些概念就是为了解决这些问题。
1.4 本文的结构
在简介中就CM和CM系统进行了定义，列出一典型的CM情形，这样一来也就暗示了CM体系的要求。第二节描述了CM系统中以用户为导向的一些问题。这些问题影响用户对CM系统的期望。第三节描述了CM概念谱。第四对CM体系的未来做了探讨，第五节是结论。附录是本文CM体系索引的概览。
2 CM体系用户的有关问题
许多与CM有关的问题直接影响到CM系统的用户。现有的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系统这么用，它对于用户和产品的演变历史都有一定程度的控制。它将驱动用户的过程并将其加强。现有的CM系统提供或松或紧的控制水平但很少能灵活地允许用户选择控制的种类。
2.5 过程与产品的区分
CM包括过程和产品。CM过程表示执行CM是所需的一系列工作任务。从根本上讲，过程是一个计划，它定义要做什么、谁来做及如何做。支持这过程是管理的功能。过程模型将组织的方针、程序和软件开发生命周期模型通盘考虑。CM的产品是工程管理任务的结果。CM系统的功能需要为二者予以支持。现有的CM系统提供一些产品及过程的支持，但在同一CM系统中一般不能形成对二者完全支持。
2.6 CM自动化水平
目前，CM一般是手工和自动程序二者兼而有之。无需任何在线支持来实施CM也是可能的。但这样做的效率很低。我们的目标是将CM中非创造性的部分尽量多地自动化。譬如，书面更改表格和对此回应的监控一般只在组织方针里予以记录，而不能在线获取与加强。
2.7 CM系统功能
现有的CM系统提供的只是所有不同种类的用户的部分功能。但随时间的推移和用户的需求和环境结构的能力得到更好理解后，这种情况将可能得以改进。以下部分描述的是现有CM系统概念范围。
3 配置管理系统概念光谱图
以上部分解释了有关配置管理系统需求问题的范围，本部分将细述配置管理系统的具体功能，并对于支持前文所述某些功能的概念特别加以考察。这些概念将被组织成一幅光谱图来表示配置管理系统的演化过程。每个概念都将置于一个特定的配置管理系统中来描述。以下是要讨论的我们感兴趣的配置管理系统概念中的功能，包括：组件，过程，结构和特色架构的组合，团队概念。图2展示了整个概念光谱图和它们对应的，有代表性的配置管理系统实例，然后给出每个概念的一个简单描述并着重突出它的优势。在本部分的末尾，将对概念和概念光谱图的作用和局限性作一个分析总结。
演化的方向
概念
图例：
*系统实例
*表示本节点所示概念的系统实例
系统建模
对象池
库
文本管理
分布式组件
生命周期模型
需求变更
属性
工作空间
透明视图
事务
一致性维护
子系统
更改集
约定
LIFESPAN*
PowerFrame*
SherpaDMS*
NSE*
SMS*
Shape*
DSEE*
Adele*
CMA*
Jasmine*
Rational*
ADC*
ISTAR*
CCC*
RCS*
图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提供了配置的释义和确认，其是基于一个对于产品的抽象描述也是基于有关形成配置的组件的使用用法成功或不成功的信息。数据建模便利的包括预先确定用户所描述的配置的属性和关系。基于那些属性和关系的语义，CMA能够决定一配置（就是一系列组件的实例）是否是可用的。成为可用的，一配置必须是完全的，无歧义的，一致的和没有歪斜的版本。这意味着一个配置必须有全部组件所需的实例组成且不必包括多重的一个组件的实例。属性的等级描述了象约束，类型和版本这样的用户定义的特性。关系的等级表现了各种依赖性，例如，合理性，兼容性，构成，实例和可继承的独立性。每次一个新的配置被组建，CMA就利用经由先前对形成配置的组件的使用在数据库中积累的信息。这样，CMA预见配置是否可用。这种新的配置为了将来分析可用性而加入数据库。从而，用户能够依靠系统来识别任何不一致以及在构建和重复使用用配置时保护此不一致。
3.5 团队概念
描述工作在一个工程项目上的软件工程团队间的独立、合作、同步的术语是工作区，透明检查和协调。描述如下：
3.5.1 工作空间
工作空间为开发人员提供独立的工作空间。
在“形状”中的工作空间是被设计用来防止用户之间的相互干扰。它提供了在配置管理下的能在可调对象上持续的工作空间。工作空间是通过版本状态模型来获得的。这就意味着属性“状态”是和构件的版本相连系的。依靠那种状态（例如状态“忙”或“冻结”），构件或者被认为是一个私有的工作区或者被认为是一个公有的库。“忙”构件是可调的并且不能被其他人所使用，象“冻结”就是一个对公共使用来说能获得的但不可调的例子。构件被提交给公共库的同时使得它们在被适当的用户证明后，对公共用途来说是可获得的。在效力上，工作区提供工作的独立性且建立在一个全局的、长期的为不可调对象的库和一个为可调对象且私有的短期的库之间的区别。
3.5.2 透明视图
透明视图提供从主配置库到工作区的访问机制，该机制具有防止非法存取的功能。
软件管理系统通过使工作区成为一个透明（清晰）的对象和提供在那个工作区的库的透明检查来增强了工作区的术语。这就意味着仅仅用户感兴趣的文件版本能在工作区中看到，所有其他的版本都不可见（尽管它们在物理上是存在的）。例如，任何对最新公有版本的变化都不需在工作区里显示出来，用户从公有变化中分离出来，并且工作区提供给用户一个特定库的外表。相关工作区版本计数的版本控制提供在工作区中。新版本是私有的并且在从工作区中释放出来之前是不可能被公共用户所见的。一个配置从公有库中检测出来提供给工作区。用户访问分配给自己的工作区。工作区里的组件有效地属于那个工作区而非一个用户。仅仅在那个工作区已登记的用户才能改变配置，且仅有那个工作区的构件能被访问。总的来说透明检查通过防止对一个配置的非授权访问而提供了一个检查机制。
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体系和一个看守系统组成。基本的ADC提供了一个数据库以获取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，图形，以及设计数据。文档的版本通过当地操作系统的版本控制来实现。所有信息（产品结构，发布程序，事件警告，用户定义特性和关系）被集中在一个核心的数据库。“发布”的意见通过促销水平（代表项目通过时的台阶）获取。这些代表公司方针用于评审，确认或完毕信号。用户可以指定谁可以获得什么样的数据，数据群，谁应该被告知状态变化，完毕信号及促销需要什么样的确认和检查。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），提供版本控制，工作区管理，系统模拟，。。。改变库探测方式，对接口说明书进行加工，以及对基于属性的版本区进行加工。工作于与任务相关的版本时，工作区提供保护措施并支持对每个任何基底的认证和登陆。
一旦特殊事件发生，物件的变动就受到监控和跟踪。已获取的物件有一个连续状态量，（“合法”“受保护”“废止”“非法”）用来代表与已构成系统的关系；此物件还带有一个程度状态量（“同意”“警告”“严重错误”），用来指明版本的一致性。