实际上项目集成流充当了所有开发人员的所有变更的协调点。为了更好地协调所有开发人员的变更集成，UCM引入了基线（baseline）的概念作为对项目进度的度量。基线是一次构建（build）或配置的抽象表示，它实际上是构件的一个版本，而构件是相关工件的集合。项目开发团队在开发过程期间不断地创建和提升基线。随着不同开发人员交付变更给集成流，他们交付的变更将被逐一收集到项目基线中。随着基线的构建、测试和批准，它们可以被逐步提升到不同的基线级别。


基线提升级别具有两方面的功能：第一，它使项目经理或项目管理人员可以建立软件质量标准。由于当基线达到某种预定义的质量标准时可以被标以某种基线级别，因此项目经理可以设置项目策略，标识出在哪一个基线级别（如"通过测试的"）开发人员可以执行变基操作。第二，基线提升级别具体的开发人员应该如何同其所开发的工件进行交互提供了指导。例如，根据某条基线通过某些冒烟测试的时间可以帮助测试人员确定什么时候开始测试。


构件基线


第二个UCM过程领域是将工件组织为构件。在第二代配置管理中，大多以文件版本形式来管理所有的文件，当一个复杂项目中包含成千个文件上万个版本时，整个项目的开发控制将变得相当复杂，因此对众多的文件进行合理分类以呈现系统的设计要素可以大大简化项目开发控制。


UCM通过将多个工件组织为构件（在UCM中构件指一个VOB的根目录或VOB的某个第一层子目录）从而扩展了软件工件管理的版本控制能力，并且UCM还提供了用于自动化构件管理的工具和过程。即用基线对构件而不是构件中众多的版本进行标识，然后用这一基线作为新的开发起点并更新开发人员的工作空间。


构件基线是在ClearCase标签（label）的基础上结合活动管理所做的扩展，即您可以知道一个UCM构件基线中包含了哪些开发活动，例如一条基线可能包含了三个开发活动，如BUG 101的修复、用户登录界面汉化以及新增打印特性的支持。


对于包含多个构件的复杂系统，UCM提供了基于多个构件的组合基线，即多个构件之间可以建立依赖关系，一旦底层构件的基线发生变化，例如生成一条新基线，其上层构件相应地也自动建立起一条基线，该基线自动包含底层构件基线。例如，一个较为复杂的MIS系统包含"数据库访问"，"业务逻辑处理"和"前端图形界面"三个构件，其中"前端图形界面"构件依赖于"业务逻辑处理"构件，而"业务逻辑处理"构件依赖于"数据库访问"构件。这样当"数据库访问"构件发生了变化并新建了一条新基线（如DB_BASELINE_Dec24）后，在"业务逻辑处理"构件和"前端图形界面"构件各自动建立了一条新基线（如BUSINESS_BASELINE_Dec24和GUI_BASELINE_Dec24）。这样上层构件的新基线可以自动跟踪底层构件的新基线。


构件管理的自动化对于高效无误地开发可能包含数千个源代码工件（还有其他相关的工件，如web内容，设计模型，需求说明和测试脚本等）的复杂软件系统而言意义重大。


构件基线提升


项目开发团队的成员工作在一个UCM项目（project）中，项目经理通过配置软件构件从而使项目成为由构件构成的体系结构。大多数组织将UCM管理的构件设计为可以反映出他们软件体系结构的方式（图4），即将所有相关工件按体系结构组织为有意义的子系统，进而放入不同的构件中。


图4：用UCM构件直接对软件体系结构建模

如上节所描述的，开发人员在交付变更到公共集成流时可以周期性地更新他们私有开发流中的构件。然后开发团队可以根据开发过程的当前阶段和质量级别对构件进行评级。项目策略确定了在开发人员变基之前构件基线必须达到的质量级别以及其他开发团队成员（如测试人员）应该如何同构件基线交互。在稍后会对项目以及项目策略做更多描述。 UCM提供了五种预定义的基线级别，它们包括被拒绝（rejected），初始（initial），通过构建（built），通过测试（tested）和已发布（released）。另外，UCM允许开发团队用他们自己的命名规范和提升策略对这些预定义基线级别进行定制。


变更集


第四个UCM过程领域是将独立的工件变更组织为可作为整体进行交付、跟踪和管理的变更集中。由于通常当开发人员工作在一个活动（例如缺陷修复）上时，他们很少只修改一个文件，因此用变更集可以表示用以完成某个具体活动的工件的所有变更，例如为修改一个编号为63的缺陷变动了50个目录/文件的120个版本，则缺陷63的变更集为相关的120个文件/目录版本。当开发人员同时工作在多个变更请求上的需要使得这一过程更加复杂。例如，一个开发人员在进行一个新发布版本的开发，这时由于当前发布版本的一个错误要求他不得不中断当前的开发工作转而去修复这一缺陷，这样该开发人员必须在同一工件上进行两种不同的变更，一种是在未来发布版本中的增强功能变更，另一种是在前一发布版本中修复缺陷的变更。


通过将同一个开发活动相关的所有变更收集到一个变更集中，UCM简化了管理多个工件变更或者多个工件版本的过程。UCM围绕具体的开发活动来进行工作组织，同时UCM还确保已完成的活动包含所有必要工件上发生的所有变更。


活动和工件管理


第五个UCM过程领域是通过使用一个可将活动及其相关工件集链接起来的自动化工作流（图5）将活动管理和工件管理集成起来。这给了开发团队极大的灵 活性来为不同类型活动的管理指定不同的工作流。UCM提供了常用活动类型的预定义工作流，包括缺陷修复和增强请求。


图5：UCM工作流概览

开发团队还可以使用ClearQuest Designer这一模块来对这些预定义过程进行定制，项目经理或者项目管理人员可以用它来创建所有需要的活动类型，包括缺陷修复，增强功能请求，文档变动以及Web网站变动等。使用ClearQuest Designer的图形用户界面，项目经理也可以定义字段，表单以及每个记录类型的状态转移。