摘要：支持软件配置管理（CM）的环境和工具已经取得了相当可观的进展，本文将重点介绍业已存在的配置管理工具所提供的一些概念，包括了对这些概念的扩展或泛化。提取这些概念也并不简单，因为软件工程社区的许多CM工具的术语不尽相同，对许多概念的实现也有所不同。因此，每一个展示的概念都是存在于特定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系统的总的看法。
来自于：
http://www.ad0.cn/netfetch/article.asp?id=645