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系统中概念的映射。
相关阅读：
