过程模型
ClearCase和ClearQuest实现了两种过程模型：Base和UCM（Unified Change Management，即统一变更管理），其中UCM是被推荐的方式。
Base模型基于配置管理解决方案的第二代理论，只能处理文件和目录。它使用分支（Branch）和视图（View）来支持并行开发，使用标签（Label）来标记每一次发布。
UCM基于第三代理论，引入了一些新的概念：活动（activity）、变更集（change set）、基线（baseline）、流（stream）等。它管理变更集和活动，而不是针对文件。
下表示两个模型的概念对比：
| Base | UCM |
|---|---|
| Base View | UCM View |
| / | Component |
| Branch | Stream |
| / | Activity |
| Label | Baseline |
| Element | Element |
| / | Change Set |
UCM概念简介：
- VOB (Version Object Base)：是一个仓库，容纳文件、目录以及任何与产品或开发相关的资源。
- Project VOB：保存VOB的元数据（Metadata）。例如项目、流、基线、活动、变更集等。
- Components VOB：保存与开发、集成、发布等真正工作相关的文件、目录等信息。
- Stream：“流”为开发者提供独立的工作区。它包含一组基线，用于替代Base中分支的概念。开发人员可基于某一条基线创建一条开发流（Development Stream），而分支却只能创建单个文件的分支。
- Baseline：“基线”可理解成快照，指明了某时刻组建的版本。它包含一个活动集，用于取代Base中的标签概念。
- Activity：“活动”用于记录一项单独的任务，例如修复一个缺陷、添加一项新功能等。
- Change Set：“变更集”与“活动”相关连，记录开发者为了完成活动中描述的任务而创建或修改的一系列文件。
- Element：元素是版本库中的单个文件或目录，一个元素包含一到多个版本。
UCM工作流
一个UCM典型的处理流程如下：
ClearCase管理员创建VOBs
ClearCase管理员创建一个用于容纳所有开发相关资源的仓库。
项目主管创建UCM项目
项目主管在仓库中创建一个自己的项目，包含相关的组件，此时ClearCase自动自动生成项目的集成流（Integration Stream）。
开发人员加入（join）UCM项目
开发人员参与到项目中，并创建私人的工作区（开发流）。
执行开发任务
开发人员创建或委任一个活动，一个活动应该只用于一个开发任务！
开发人员交付（deliver）自己的成果到共享区
当开发人员完成了自己的开发任务，并完成相应的测试，就可以把自己的工作成果交付到集成流上。
发行工程师（Release engineering）构建项目
项目中专门负责构建的工程师会周期性地到集成流上构建最新的可执行文件，使其能包含开发人员交付的代码。
项目主管创建一条新的基线
如果项目构建成功，项目主管会打一条新的基线，然后由质量保证组的工程师们基于新的基线做集成测试。
项目主管把基线提升为里程碑
经过反复地修复、构建、测试、发布等过程，基线会稳定下来，此时项目主管可以去推荐（recommended）这条基线为项目里程碑。
开发人员把私人的工作区更新到最新状态
开发人员把私人的工作区更新到推荐的基线上，然后重复上述步骤继续新的开发任务。
用于产品紧急修复（hot fix）的流程如下：
开发人员创建一条用于紧急修复的开发流
开发人员基于发布的基线（不是最新的基线）创建一条用于紧急修复的开发流。
执行开发任务
把补丁打到新的开发流中。
项目主管在该开发上打基线
在开发人员完成测试后，项目主管在该开发流上创建一条新的基线，它仅包含已发布的代码和补丁代码，不会包含那些仍然处于开发过程中的未发布代码。因此把这条基线提升为里程碑作为紧急发布版本。
开发人员把补丁交付到集成流中。
根据上述流程，整合补丁代码到当前开发中。