本文介绍了笔者在某美资企业 IT 部门实施 UCM 项目的过程，着重描述了在此过程中总结的经验教训，包括提倡的“循序渐进 - 先 ClearCase UCM，再 ClearQuest 流程，最后 ClearCase 和 ClearQuest 集成方式”，务求能让读者直观认识到 UCM 实施项目的风险和应该采取的对应策略，以提高 UCM 项目在其它企业成功实施的机率。

前言

本文介绍了笔者在某美资企业 IT 部门实施 UCM 项目的过程，着重描述了在此过程中总结的经验教训，包括提倡的“循序渐进 - 先 ClearCase UCM，再 ClearQuest 流程，最后 ClearCase 和 ClearQuest 集成方式”，务求能让读者直观认识到 UCM 实施项目的风险和应该采取的对应策略，以提高 UCM 项目在其它企业成功实施的机率。

为了读者理解方便，本文首先讲述了 UCM 的一些概念；接着介绍此实施项目的背景和实施过程，以及实施过程总结的经验教训，最后对项目的实施进行了总结。

UCM 基本概念

统一变更管理（Unified Change Management, UCM）是第三代的配置管理解决方案，是用于管理软件开发过程（包括从需求到版本发布）中所有变更的 " 最佳实践 " 流程。UCM 定义了一个可以立即用于软件开发项目的一致并基于活动的变更管理流程。通过 Rational ClearCase 和 ClearQuest 的支持，UCM 已成为 Rational 用于软件开发最佳实践的全面框架 —— Rational 统一过程（RUP）的关键组成部分。UCM 通过抽象层次的提升简化了软件开发，从而使得软件开发团队从更高的层次根据活动（activity）来管理变更。

ClearCase UCM 对配置管理中的分支，标签，超链接，元素，视图和版本对象库等概念作出了更高级别的抽象，这包括：

UCM 项目（Project）

项目用于为一组人在一个单一的项目上提供工作。它一般通过开发项目团队或者待开发系统进行划分。项目包含了一个集成流和零个和多个开发流。

UCM 流（Stream）

流类似于分支，但是流比分支包含了更多的信息，包括基线和在此基线上的活动集。基线加上活动集决定流里包括元素的哪些版本。

UCM 基线（Baseline）

基线是 UCM 流的基础，是发布版本的重要依据。

活动（Activitiy）

在 ClearCase UCM 项目里对任何 ClearCase 管理的资产的变更都必须关联到一个活动。活动是由缺陷或者新需求触发的开发活动。需要注意的是，如果使用的是 ClearCase 与 ClearQuest 集成的方式实现 UCM，活动必须和 ClearQuest 上创建和管理的记录关联，通过 ClearQuest 的流程严格控制。如果只是使用 ClearCase 实现 UCM，活动不需要和 ClearQuest 的记录管理，活动从而也不需要走流程和具有状态。

UCM 构件（Component）

构件允许你组建一组相关的目录和文件元素在一起，并且把它们和 UCM 项目进行绑定。一个构件被开发、集成，并且其所有的部分是一起发布的。所有的项目必须有一个和多个构件，并且在项目间可以共享构件。

项目背景介绍

此次 UCM 项目实施的所在企业是大型美资生产企业，业务遍及世界 80 多个国家和地区，其开发团队的规模达到近百人，每年需要负责几十项软件项目的开发工作。该公司的开发项目包括自主开发的项目，半外包型的项目和全外包型的项目，开发的类型比较复杂，新项目上线比较频繁。

该企业软件开发中心以往的开发模式是每个项目组都有自己的代码库，分支、基线策略比较零散，由项目组自己定，难以确保软件发布的正确性；同时，变更流程也比较分散，每个项目组基本上都是通过项目经理来控制变更，变更不走流程，也鲜有记录，导致无法评估变更对软件质量的影响，万一生产系统有问题出现，也难以追溯。

随着业务的不断扩大，软件开发团队和软件开发项目的日益庞大，该公司在软件开发过程中出现的挑战越来越明显，出现了如下的几个主要问题：

• 软件资产的完整性和可管理性问题日益加剧：随着版本和文档数据的增长，不能很好的将原来版本与最新版本的比较和回溯
• 对变更和业务的流程控制不够力度：对流程的控制的审计功能不够严格，可能因为某个角色的疏忽，将流程搁置在某一个阶段
• 变更请求和资产管理脱节，变更请求往往通过口头、邮件方式传达，无法记录到具体的资产变更当中
• 存在多种开发工具，导致开发团队的开发和沟通出现障碍，不能很好地达成一致

为了很好地应对这些挑战和适应业务的快速发展的要求，开发中心决定采用大集中方式来进行软件开发环境的整合，建立一个稳定的软件开发平台，对目前及今后的项目进行统一管理。

中心在 2007 年初进行了一次方案选型工作，将 ClearCase UCM 方案和 VSS, Subversion 等进行了比较。由于 Rational 软件的统一变更管理（UCM）通过 Rational ClearCase 和 Rational ClearQuest 所提供的开发平台实现了贯穿整个软件开发周期的配置管理过程，开发中心最后决定采用 ClearCase UCM 方案。

实施过程

在实施之前，我针对上述在软件开发中凸显的问题进行了具体的方案设计。

针对软件资产的完整性和可管理性问题，将通过 ClearCase 实施统一的资产管理平台来解决。也就是通过 ClearCase 集中管理软件资产，包括源代码、项目文档和二进制文件，并通过严格授权的方式来管理用户的访问。

针对变更控制力度不够的问题，将首先制定好统一的变更流程，并通过 ClearQuest 固化，通过固化的流程管理资产的变更，并将变更转化为开发任务、测试任务、部署任务等等，分配给相应的团队成员。

针对变更请求和资产管理脱节的问题，将采用 ClearCase 和 ClearQuest 集成的方式以实现变更请求和资产变化相关联，实现双向追溯，即能从变更请求追踪到资产的具体变化，或者从资产的具体变化回溯到当初的变更请求。

针对开发工具无法集成的问题，将通过 ClearCase 和 ClearQuest 与主流开发工具的插件来解决。

在方案设计的基础上，我们确定了 ClearQuest 和 ClearCase 同时设计、定制和试点的策略，并由此制定了规划 - 设计 - 实施 - 收尾四部分组成的计划表。具体可参考下表，以下是对每部分的简要描述：

第一步是进行环境评估和规划，此步骤的目的是了解开发中心的现状，包括硬件、网络、操作系统和应用软件方面，并和 ClearCase 和 ClearQuest 环境要求进行对照，尽早发现需要改善的地方，以在工具真正使用之前予以解决，不至于影响后面工具实施的进度；同时将诸如 ClearCase Region 等预先进行定义，方便后面实施时候使用。此工作预计需时一周左右。

第二步是配置管理策略及变更管理流程的分析设计，此步骤的目的是将开发中心的开发团队原有习惯和 ClearCase 及 ClearQuest 的最佳实践结合，务求找到较佳的结合点，减小对现有开发团队的冲击，同时带入先进的配置和变更管理理念。这里的工作包括从 ClearCase UCM 的最佳实践角度出发规划 UCM 的项目、构件、流、基线策略等等，从 ClearQuest 的内嵌流程出发，设计开发中心应用的变更流程。此工作预计需时一个月左右。

第三步是 ClearCase 和 ClearQuest 定制。此步骤就是将第二步分析设计的结果在工具上进行固化，这涉及了通过 ClearCase Project Explorer 界面进行 UCM 项目、构件、流、基线和 ClearQuest 基础等设置以及通过 ClearQuest Designer 进行变更流程设置。此工作预计需时一个月左右。

第四步是试运行，培训及验收。在第三步定制成功以后，这一步主要是将定制好的 ClearCase 项目和 ClearQuest 流程交给试点项目使用，并通过用户培训教会项目开发人员使用，并持续地监控项目的运行，及时收集反馈，及时进行修正。最后达到目标进行项目验收。此工作预计需时一个月左右。

实施经验教训

UCM 项目实施总体控制方面

项目结束比原计划晚了一个多月，主要是因为对 UCM 项目实施经验不足，不了解 ClearCase 和 ClearQuest 的实施风险，导致在前期分析设计使用时间太多，在后期发现 ClearQuest 流程需要不断变更时，所剩时间已无几，需要延迟项目时间才能交付。同时，由于通过 ClearCase 和 ClearQuest 集成的方式将 UCM 导入到开发团队，开发人员需要同时学习配置和变更管理的概念和工具，短时间难以理解和掌握，在此情况下强行部署工具，对开发团队的日常工作造成较大的冲击。

我们建议在 UCM 的实施项目中，通过我们称为“循序渐进”的方式进行，这种方式在早期导入 UCM 的时候，对开发团队的冲击最小。首先在开发团队中实施 ClearCase UCM，通过 ClearCase 自身来管理 UCM 活动，而不是通过 ClearQuest；在实施 ClearCase UCM 的同时，逐渐把握企业项目团队的开发方式，如项目团队组织方式，项目发布策略等等，有助于下一步 ClearQuest 的实施；在此基础上实施 ClearQuest，将开发团队的变更管理流程固化到工具中；最后，将 ClearCase 和 ClearQuest 集成，通过 ClearQuest 来管理 UCM 活动

这种“循序渐进”方式的好处在于：

1. 因为 ClearCase 部分的实施不涉及流程，变更也比较少，容易出效果；而 ClearQuest 实施往往涉及企业内部开发流程，复杂度较高；
2. 由于一般开发团队都有配置管理的基本概念，所以首先实施 ClearCase UCM 的方式容易被开发团队接受，抗拒心理也没那么强；
3. 通过 ClearCase 自身来管理 UCM 活动，使得开发人员可以以比较轻松的方式接受变更管理。如果一开始就通过 ClearQuest 来管理活动，而每个活动都必须走变更管理流程，这样对开发团队冲击较大。

ClearCase 实施部分

在实施中我们发现，ClearCase 的一下几个方面设计规划非常重要，直接影响到 ClearCase 实施的成败。包括：UCM 构件 (Component)，权限设置和与开发工具集成。

因为 UCM 的对象互相关联，变更比较麻烦，如删除操作就需要按顺序做。所以在创建 UCM 项目和构件之前必须做好规划。当中，构件的设计尤其重要。构件的设计涉及多方面的因素，包括软件系统本身的架构，开发团队的工作分配习惯等外，还有一个重要的因素，就是系统的发布计划。在此次实施项目里面有个需求，就是要求针对某些目录需要能单独打基线，以便发布时候可以单独发布。因此我们根据这个需求，将此系统原有的目录结构切分成了相应独立的构件。

在权限分配方面，由于 ClearCase 是通过类似于 UNIX 操作系统（如 777）的方式对目录或者文档进行授权，因此不建议用户对 ClearCase 管理的资产进行太严格的权限设置。一般将某个项目的资产设成为此项目组所有人能读写，其它人或者是可读，或者是不可读即可。

在于开发工具集成方面，该公司的开发和测试工具比较复杂，有 WSAD, RAD, Jbuilder, C++, Eclipse 和 Robot 等等，由于对所有开发工具不是都熟悉，要将它们分别集成到 UCM 的工具上确实也是比较复杂，而且还要将以前的工作成果都倒进来就费时了，有的工具集成时还需要重新卸载后再安装，所以只能是该人员下班后安装，不能影响其正常的工作时间．有些甚至还存在版本过低不能集成的问题等，如给某个开发人员的 Eclipse 做与 ClearCase 集成时，他的 Eclipse 的版本是低于 3.0，而现在 ClearCase7.0 之后的需要是 Eclipse3.0 以上的版本。总得来说，与其他工具的集成问题，应特别注意各软件的版本兼容问题，免得集成后发现不能达到共享工作的作用．关于与 UCM ClearCase 集成的文档可以参照 IBM Rational ClearCase plug-ins 网站，几乎可以集成的软件资料都可以查到（参见 参考资料）。

ClearQuest 实施部分

根据该公司内部流程需求、结合 CMMI 所推荐的最佳变更、需求管理最佳流程，分析项目的需求，制定符合 UCM 规范的 ClearQuest 的规范流程控制，包括有：新建项目流程，需求变更流程，开发流程，测试流程，缺陷流程和部署流程，将整个软件生命周期中所有的流程都经过严格的审计控制

由于项目初期的需求调研做得不够充分，实施过程中沟通不善，刚开始与客户商定的流程只有开发流程，测试流程和缺陷流程，等到初步流程交付时，由于该公司的项目流程是由三个不同项目组共同使用，所以出现不统一的异议，TAL 组希望流程越详细越细致到每个人的每个操作，对于流程的控制需要从项目一产生就开始控制；PO 组又希望尽可能的简单直接，不需要复杂的流程，对于流程的控制只需要从进入开发阶段才开始控制；TOUTS 又觉得只要流程控制好外包的时间和效率，不需要太细节的操作，而且还存在半外包的形式，同时又不希望外包组进入他们的流程操作中

各个项目组要求不同，一时难于取舍，只能是成立临时的变更委员会（CCB）与我们项目实施组进行商讨做出裁决．期间经过了大约漫长的一周，不断地与各组间进行沟通和博弈，比较流程繁简的优劣，与之前成功案例中使用的最佳实践的介绍，最后由变更委员会暂定了符合各个组不同实际的流程，虽然还存在部分分歧，但为了不影响后期的工作进展，大家也就变更委员会的决策达成了初步的一致．

总得来说，做 UCM ClearQuest 流程一定要做好初期的调研和确认，如果这步做不好，后头发现方向不对了，会浪费很多的时间和精力，客户的需求是不断地在变化的，可能今天的需求明天就变了，因此每次确认下来的需求最好有个邮件或者文件上的确认以便日后的反馈和沟通工作．如遇到不同项目组的意见分歧，要充分发挥沟通的力量，同时利用好变更管理委员会（CCB）的作用，然后与项目组的项目经理进行沟通和博弈，用其他项目的实际经验和成功的案例说服他们

在 ClearCase 和 ClearQuest 集成方面

因为一般项目开发都会有两种类型，一种类型是新项目，一种是维护项目。针对这两种项目类型，我们分别采取了不同的集成策略进行。

在新项目中，由于项目初期需求较不确定及系统的架构未稳定，开发人员需要进行大量的变更操作，而这些操作并不需要严格的控制，因此我们建议在新项目的开发早期不进行 ClearCase 和 ClearQuest 的集成，只是通过 ClearCase 自身的方式管理变更活动。如果此时进行集成的话，每此作出修改，开发人员都得要跑一趟变更流程，不利于项目的快速开发。开发人员的抗拒心很大，最终导致项目放弃这种一开始集成方式。当新项目开发阶段结束进入集成测试阶段时候，我们才将 ClearCase 和 ClearQuest 集成，严格控制这以后的变更。

在维护项目中，由于每次变更都涉及生产系统，我们要求 ClearCase 和 ClearQuest 集成，每个变更都要走严格的变更控制流程，防止随意的变更导致系统不稳定。

总结

在这些经验教训的基础上，我们在项目收尾的阶段进行了项目总结，并制作出了一个改善后的计划，并将之与原有计划进行了比较以供大家参考。

如果我们重头实施此项目，我们会将计划调整为以下的“循序渐进”的方式，首先在试点项目组实施 ClearCase UCM，边实施边了解项目的特点；在 ClearCase UCM 成功实施以后，在项目组持续使用 UCM 的同时，迅速进行 ClearQuest 流程的实施。最后，将 ClearCase 和 ClearQuest 集成，并根据项目的特点在项目中推广。

因此，我们建议读者在以后的 UCM 实施项目中考虑“循序渐进”的策略，通过“先易（ClearCase）后难 (ClearQuest) 再集成”，“及早试点，及早收集，反馈及早改善”的模式提高 UCM 项目实施的成功机率。

参考资料

• 关于与 UCM ClearCase 集成的文档：IBM Rational ClearCase plug-ins
• 访问 IBM Rational 软件交付平台 V7专题，了解 Rational V7 产品的方方面面。
• 访问 IBM developerWorks 中国网站 Rational 专区 了解更多关于 Rational 产品的信息。