通过调查现存的配置管理（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系统的总的看法。

2.1 用户角色

就像1.3中的场景所描述的，一个CM系统有许多不同的用户，每一种用户都属于特定的角色，对CM系统也有不同的视角，因此对CM系统有不同的需求。图1说明了项目经理、配置经理、软件工程师、测试员、QA经理和客户对CM系统的期望，每一个方框代表了一个功能域，图1中的方框（审计、统计、控制、组件、结构和构建）是可以存在于任何CM系统的功能域，但是当与团队和过程功能结合后，就可以组成了一个全盘的（或者说是复杂的）CM系统。

　　　　　　　　　　　　　　　　　　 图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系统中概念的映射。

3,CM系统的概念

　前一小节简述了CM系统关注的需求，本小节将详细论述CM系统的功能。某种程度上讲，这部分将验证上一小节中提到的支持某些功能域的概念，这些概念通过对CM系统演进的表现来组织，每一种概念在一种特定的CM系统下描述。CM系统关心的将要讨论的功能域包括：组件、过程、结构组合、构建特性和团队概念。图2显示了CM系统的概念图谱，下面是对概念和优势的简要描述。这一部分以一个总结和一个对这些概念优势和限制的分析作为结束。

• 软件配置管理概念－3.1 警告
• 软件配置管理概念－3.2 组件概念
• 软件配置管理概念－3.3 过程概念
• 软件配置管理概念－3.4 结构和构建概念
• 软件配置管理概念－3.5 团队概念

4,CM系统的未来

图2展示的概念代表了典型的商用CM系统的概念，随着研究的继续，以及使用和组合概念的经验，许多新武器将会加入进来，这意味着有可能CM系统将会获取一组新的基础CM服务来满足用户的需求。但是，不考虑是否每个CM系统设计师正在努力实现相同的特性，始终有一些政治和技术问题影响着CM系统的未来。（政治问题关系到市场和标准；技术问题关注实现特定机制的可行性。）

　一个主要的政治问题是电脑辅助软件工程（CASE）工具的演进。例如，是否CASE工具零售商会回避用他们的工具范围内实现CM，并且假定环境零售商将会在它们的框架中提供CM支持？如果CASE零售商与其自己的CM工具支持绑定，当用户安装它们的CASE工具时，将需要解决集成不同CM 系统的问题。同样，从零售商的角度，他们会从本质上重复解决许多环境框架解决的问题吗？

　另一方面，如果CASE零售商不将CM工具组合到工具中，他们可以依赖CM环境工程提供合适的框架来集成CASE工具，并且同时提供一些全局性的CM功能吗？没有人知道这些问题的答案。在任何情况下，CM系统与环境的关系有一种隐含的标准，反之亦然。

　许多技术，研究问题影响CM系统的能力，类似的问题正在上升。构建CM系统基础的合适技术是什么？一个支持对象持久化的面向对象数据库是否合适？什么级别的环境是CM合适的？它在数据库中必须是基础级别，环境框架的集成部分吗？或者是将CM指定为架构中的较高等级？CM的机制是否可以与CM 功能分离，也就是是否有标准的CM原型可以用在所有的环境来支持所有的CM功能？是否有一个统一的CM模型？是否可以支持分布式的CM支持？地理位置分离的团队是否可以使用同一个CM系统来进行本地CM和系统集成？这是业界，特别是国防部的协议中的主要问题。是否有可能支持跨软件开发？工程师是否可以在主机开发一个产品，并在维护中同时发布到目标机器？标准是否扩大了CM系统的限制？是否CM同样的支持一个百万行代码的产品和一个上亿行代码的产品？是否可以对CM过程的所有方面，包括用户敏感的部分建模，并在CM系统中实现？

　以上问题的答案还不清晰，进展很有可能会源自各个方面－－从CM系统零售商，环境架构师和研究员，工具集成员，软件过程建模论坛和电脑辅助设计/工程，电脑集成生产商世界。

　5,结论

CM是对软件产品演进的管理，在CM系统的操作级别，CM是标识、控制、统计、审核、复审、加工、过程管理和团队协作。这是一个软件工程环境领域取得的进展，这显然是来自概念图谱，也是来自现存CM系统和其能力。本文展示的图谱是对许多不同CM系统实现的概念的快照，每一种系统专注不同的用户问题－－角色、集成、控制、自动化程度、过程对产品的支持和使用系统提供的功能进行CM的最佳开始时间。希望提供这个图谱可以辅助我们理解CM系统的能力，并且能够提供一个讨论CM工具支持的共同框架。

致谢

　十分感谢本文的评审者，特别是Peter Feiler, Grace Downey, Kurt Wallnau, Ed Morris, Bob Ellison, Chuck Weinstock, Mario Barbacci, Rick Green, Jim Tomayko, 技术作家Marie Elm和SCM3的评审者。