图1

这些功能域有：

组件：识别、分类、保存和访问组成产品的组件。
结构：代表了产品的架构。
构建：支持制品和产品的构建。
审计：保持产品和过程的审计轨迹。
统计：收集产品和过程的统计信息。
控制：控制如何和何时进行变更。
过程：支持产品功能正确性的管理。
团队：支持项目团队开发和维护一系列产品。
这些功能的需求会在下面详谈。
对于组件的需求包括：记录组件的版本，区别和区别的原因；标识组成一个配置的组件，其中包括各个版本的组件；标识产品和其扩展的基线；确定代表特定项目组件和制品集合的项目环境。此外，用户需要版本库或运行库来保存和捕获组件和CM信息，例如保存源代码、对象代码、可执行程序、图表、文档和基线等。
对于结构需求，用户需要：通过代表产品组件的列表来建立产品的模型；指出组件、版本和配置的分界点，以此使之可重用；标识和维护组件的关系；选择兼容的组件来组成正确和一致版本的产品。
对于构建需求，用户需要：简化构建和编译产品的过程；在任何时间对产品的状态进行快照和冻结的能力；通过减少重新编译的组件和节约空间来优化构建系统的机制；利用变更影响分析预测衍生物发生的更改；在任何给定时间更方便的重新生成任何阶段或部分的产品。
对于审计需求，用户需要：所有变更的历史；在产品和他们的演化中能够追踪所有相关的组件。所有所作工作的详细日志。
对于统计需求，用户需要：记录统计数据来检验产品状态的机制，更容易的生成关于产品和过程的各个方面的报告。
对于控制需求，用户需要：小心的访问系统的组件防止未保证的变更和变更冲突；在线的变更请求表单和问题报告支持；也意味着要追踪问题原因、时间和处理的负责人。用一种控制的方式传递变更，贯穿不同但是相关的产品版本；分割产品达到减少变更影响的方法。
对于过程需求，用户需要：支持他们的生命周期模型和组织政策；识别将要做的任务，以及这些这些任务何时和如何完成的能力；与正确的人交流相关信息的能力；和记录产品知识的工具。
对于团队需求，用户需要：单独的和组的工作空间；合并修改时解决冲突的方法；支持创建和维护产品族的工具。
需要注意过程框和团队框被表示成重要的功能，这是因为它们会和所有其它部分互相影响。对一个用户来说，一个理想的CM系统应该支持所有的集成了团队和过程的功能域，目前没有一个单独的系统支持所有这些功能域。

2.2 CM系统的集成
任何一个CM系统都有与环境集成程度的概念，一个CM系统可以与其他工具共存或完全集成。集成包括了环境的各个方面：过程、工具集和数据库。过程集成意味着CM系统使用模式（组成了CM过程）的结合。工具集集成意味着在环境中安装所有的CM系统，至少是与环境中的其他工具可以共存。举个例子，用户希望CM系统能够在编辑器中执行“保存”时创建一个新的版本。数据库集成关注CM数据库的逻辑位置－－是否与现存环境的数据库以某种方式合并，或者是它是一个独立的实体，或者是它利用了其它数据库的信息。所有这类集成都是普通的工具集成和技术迁移问题。但是自从CM系统尝试影响环境中的大多数对象和对象的整个生命周期的所有阶段时，CM系统的集成开始对环境中的许多工具产生了重要的影响。大多数CM系统与其他工具共存，而且有一些环境让CM成为他们自身的一部分。

2.3 何时开始使用CM系统
这要看项目组何时在开发和维护的产品上开始使用CM系统。一些小组选择在产品经过了开发周期并准备好交付给客户方时，另一方面，一些小组选择从项目的一开始就将所有的事情放在CM之下。两种方式都有各自的成本，举个例子，团队会根据变更的成本作出选择，如果需要许多手工的过程（例如填写变更请求单，获得CCB的通过和确认），团队一般会选择在开发的主要过程结束后纳入CM控制，但是如果变更请求过程可以在线操作，只需要花费较少的时间和人力，CM将会在较早的时间被引入。理论上讲，CM适应于产品的整个生命周期－－从概念、开发、产品发布、客户交付、客户使用到维护。理想情况下，CM系统必须尽可能将成本最小化，因此应该尽早将CM应用到项目。然而，现存的CM系统，容易将精力集中在产品生命周期的特定阶段，所以用户会被功能限制。

2.4 CM控制的级别
有许多辅助CM执行的步骤、政策和工具，他们会对用户和产品的演进提供不同程度的控制。例如，它们会要求工程师提交正式的书面的变更请求，接着是CCB的评估和对变更的授权。然后配置经理为软件工程师创建工作区，从受保护的版本库选取特定的文件放置到这个工程师独立的工作区。另一方面，另一种不同的步骤、政策和工具或许允许工程师直接用电邮通知配置经理和CCB的其他成员他的变更请求，然后这些成员立刻反馈，经过批准，变更请求指派给一个工程师，然后这个工程师直接从版本库得到代码并进行修改，所有这些操作不需要手工的干预，因为CM系统可以自动的记录所有的访问，一个正式的修改过程记录会被创建。
第一个场景被认为是对任何活动都非常严格和积极的控制，而后一个场景则是对活动宽松和被动的控制。最好不要在第一种场景进行经常性的修改，因为人力成本很大，而第二种情况鼓励频繁的修改，因为这很容易。不同级别的控制可能更适合于产品生命周期的一定阶段，例如，第一种适合维护阶段，而第二种适合开发阶段。无论使用何种CM系统，在产品的演进的某个时间点上都有特定级别的控制，它会限制，加强用户过程或者两者皆有。现存的CM系统提供了各自的控制级别，或松或紧，很少具备允许用户选择控制级别的灵活性。

2.5 区分过程和产品
CM包括了过程和产品，一个CM过程代表了一系列依序执行的CM任务，本质上讲，这个过程是将要做的事情、及其执行者和执行方式的计划，对过程的支持是一种管理功能。过程模型会考虑组织和软件开发生命周期模型的策略和步骤。CM产品是工程任务过程的结果，一个CM系统需要同时提供这两个方面的功能。现存的系统提供了一些产品和过程的支持，但是同时支持通常并不是很简单。

2.6 CM的自动化程度
如前所述，CM通常是手工和自动步骤的组合，有可能在不需要任何即时辅助的情况下执CM，但这是没有效率的，我们的目标是在CM的非创造性部分尽可能的自动化。例如，即使已经有系统可以提供完整的完整的自动变更请求，仍可以用在组织的策略文件夹中写文档的方式来填写变更请求表单和反馈，而不是即时捕捉和执行。尽管每一种CM系统都提供了不同程度的CM自动化功能，仍需要用户用手工手段来作为自动步骤所不能完成任务的补充。

2.7 CM系统的功能
现存的CM系统提供了CM部分必须的一些功能，但是没有一种系统提供了满足所有不同用户需求的功能，改进需要时间，需要随着用户对环境架构更好的理解来完成。下一部分重点介绍现存CM系统中概念的映射。

1,介绍
通过调查现存的配置管理（CM）系统可以发现支持CM的环境和工具已经大大改进，这可以通过CM系统提供的概念范围来证明，本文就是要强调这个范围，首先介绍一下广义的CM定义和一个典型的CM场景。
1.1 配置管理的定义

软件配置管理是控制软件系统演进的学科，经典的CM讨论如[3]和[4]，IEEE标准729-1983[16]中的定义列出了CM操作的几个方面：
标识：一种标识模式反映了产品的结构，标识了组件及其类型，使之唯一并且可以通过某种方式访问。
控制：控制产品的发布，并通过创建基线产品来保持软件的连续性以达到整个生命周期的变更控制。
状态记录：记录和报告组件的状态和修改请求，并且收集产品中组件的重要统计。
评审和复查：验证产品的完整性，通过确保产品是定义良好组件的组合来维护组件的连续性。
定义也包扩配置项、基线、发布和版本等术语，大多数CM系统通过组合不同程度上的功能来支持这些方面，一些CM系统提供的功能超越了以上的定义，这归因于（抛去其他原因）多个方面的认识，如不同的用户角色（在1.3和2.1部分有进一步讨论）、异种平台的不同操作环境、建立软件工程师在其中以和谐方式工作的大项目的支持。为了捕获这些额外的功能，有必要拓宽CM的定义：
制造：以一种透明的方式管理产品的构建。
过程管理：确保执行组织的过程、政策和生命周期模型。
团队协作：控制同一产品多个用户的工作和交互。

1.2 CM系统的定义
对于CM系统的组成，没有一种普遍接受的定义。举个例子，版本控制系统是CM系统吗？理想情况下，一个CM系统应该能够提供上面定义的所有功能，但是实践中，任何提供某种形式的版本控制、配置标识、系统构建、系统建模和企图提供CM（某种程度）功能的系统都会被软件工程（和销售）社区当作CM系统。必须注意到存在的CM系统都提供了它们独有的功能组合，而不是标准的。这个报告只包括了15个CM系统，目前至少有40种可以获取并使用的CM系统。
本文有必要阐明一个概念，CM系统和CM工具。一个CM系统可以看作是环境的一部分，CM支持的是集成环境的一部分，并且CM是以包的形式销售，一个CM工具可以被认为一个独立的工具。举个例子，Revision Control System(RCS) [15]是一种CM工具，因为它企图安装到现有的环境，但是因为这一点区别对本文并不重要，我们会用CM系统这一术语来表示这两种概念。

1.3 一个典型的CM用户场景
在开始讨论CM系统之前，为了展示一个参考的框架，我们首先介绍一个组织的CM用户场景。这个场景包括了许多具备不同职责的人：一个负责软件组的项目经理，一个负责CM过程和策略的配置管理经理，一个负责开发和维护软件产品的软件工程师，一个验证产品正确性的测试员，确保产品高质量的质量保证（QA）人员和一个使用产品的客户。
每一个角色都有自己的目标和任务，对于项目经理，目标是保证产品按计划开发，因此，经理监督开发过程，通过分析生成的软件状态报告，执行系统复审，及时发现问题并处理。
配置经理的目标是确保代码的产生、修改和测试的过程和策略是可追踪的，同时保证项目的信息是可访问的。为了实现维护代码变更的控制的技术，这个经理引入了一种对变更进行正式请求的机制，以达到评估变更（通过一个负责确认变更的变更控制委员会（CCB））和授权变更的目的。这个经理要为工程师创建和分发任务列表并创建项目环境，另外，这个经理还要收集软件系统组件的统计信息，例如确定这个系统的哪些组件可能会出问题。
对于软件工程师，目标就是有效率的创建产品，这意味着工程师不应该被非必要的工作打扰，例如他人创建和测试代码，支持产品文档等，但是与此同时，他们还要保持有效率的交流和协作。他们借助工具创建协调一致的产品，通过通知其他人关于任务需求和结束的信息来交流和协作，通过合并代码并解决冲突来将变更传递到所有人的工作中去。产品中的每个组件的演进历史都会保存，通过记录修改的内容和记录的修改原因。每个工程师都在自己的工作区域创建、修改、测试和集成代码，在特定点上，代码会纳入基线，也就是作为进一步开发的开始，也是针对其他目标机器的并行开发的改变的开始。
测试员的目标是保证产品经过测试且达到满意，这包括了测试特定的版本，并且保存对应测试的记录，任何报告的错误会被反馈到合适的人，并在修正后进行回归测试。

QA经理的目标是保证产品的高品质，这意味着特定过程和策略必须通过合适的确认，产品的缺陷必须被修正并且分发到产品的变体中，并经过进一步测试。客户对产品的抱怨也必须要跟进。
客户使用产品，不同客户使用不同的版本和变体，客户依据一定的过程来请求变更以指出缺陷和改进产品。
理想情况下，一个符合这个场景的CM系统必须支持所有这些目标、角色和任务，这意味着这些角色、任务和目标决定了CM系统的功能需求，这篇文章尝试展示完成这些特性的概念。

1.4 本文的组织
介绍是对CM和CM系统的一个定义和CM场景的一个典型例子，因此提示了CM系统的需求。第二部分描述了对CM系统用户十分重要的CM问题，这些问题影响了用户对CM系统的期望。第三步分描述了CM概念。第四部分，展望了未来的CM系统，第五部分作出了结论。附录给出了本文参考的CM系统的总的看法。