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