为了方便开发人员更容易地标识活动和项目代码库中工件间的关系，UCM自动将活动和其相关的变更集链接起来（图6）。当在一个UCM项目中工作时，开发人员所交付的是活动（见开发人员隔离和协作一节）而不是文件形式的工件。类似的，当开发人员变基时，他们根据新构件基线提供的活动（而不是文件形式的工件）来重审将要在他们的私有开发流中接收的变更内容。这样，开发人员不仅可以看到所有相关工件完整的版本历史，而且可以看到实现每个变更的所有活动。这给了开发团队一个项目是如何从一个阶段演进到下一个阶段 演进的全面视图，当需要标识出一个工件版本的变更是如何影响另一个版本时，这一优点所带来的价值是无法估计的。


使用UCM一致、可重复的用于活动管理的过程，通过活动管理和工件管理的集成可以帮助开发团队减少错误，开发人员还可以避免许多通常需要手工作业的单调工作，从而更有效率地完成开发任务。


图6：UCM将活动和相关的工件链接起来

项目和项目策略


UCM中的项目可以和实际软件开发中的各种项目对应，每个UCM项目包含一个集成工作流和若干个私有开发流，项目可由一组构件构成。这里需要强调的是一个构件可以被多个项目共享，进而项目A中的开发人员可以对一个构件进行修改，创建新的构件基线；而项目B的开发人员可以参照同一构件以及该构件在项目A中生成的基线，但不能对该构件进行任何改动。因而UCM项目从代码级提供了软件共享及重用的良好基础。例如某系统集成公司的湖北分公司刚刚结束了为某银行开发的客服系统1.0的开发（我们可以将终交付的版本称之为XBANK_CRM_HuBei_1.0），与此同时该系统集成公司的北京分公司正准备为另一家银行进行类似系统的开发。另外XBANK_CRM_HuBei_1.0在推广过程中出现了一些问题，亟待解决。还有该客服系统2.0版XBANK_CRM_HuBei_2.0的需 求分析准备在下月开始。此时如果利用UCM的多项目机制则可以为在北京的开发团队建立一个新项目CRM_Beijing_1.0，但该项目并不是从零开始的，它可以从XBANK_CRM_HuBei_1.0开始，有选择地借鉴XBANK_CRM_HuBei_1.0中可共享的部分。同时原有的XBANK_CRM_HuBei_1.0的开发人员可以继续进行2.0版的研制工作。而为了解决XBANK_CRM_HuBei_1.0中在推广中出现的问题又可以新建一个XBANK_CRM_HuBei_1.0版的维护项目XBANK_CRM_HuBei_1.0_BUGFIX，部分原有开发人员既可以加入该项目进行原有1.0版的错误修复，又可以互不干扰地在原有项目中进行2.0版的需求分析。


UCM在项目上另一个突出特点是不同项目中的开发流之间可以进行跨项目的工作交付。即一个项目可以将一条构件基线中包含的工件交付给另一个项目，也可以将一个开发流上的活动变更集交付给另一个项目。紧接上例，假设过了三个月后项目XBANK_CRM_HuBei_1.0_BUGFIX修复了8个缺陷，而项目CRM_Beijing_1.0也根据北京用户的特点实现了3个不同的新特性，这时如果需要可以在恰当时机将这两个项目中的成果有选择地交付给正在湖北进行的客服2.0版的开发，从而使得2.0版不仅修复了前一版本中的错误，而且具备了3个新特性。


可以看出项目从一个更高层次上支持了传统意义上基于分支的并行开发，这对于软件开发组织从面向项目到面向产品的转变，合理利用软件开发人力资源，改善软件产品体系结构从而支持更为复杂的软件开发具有重大意义。


由于同一代码构件上多项目开发的引入，相应地UCM加入了多种项目策略来进行支持，用户可以根据需要灵活定义项目策略。例如上面提到的基线级别，可以定义只有基线级别提升到"Tested"才能作为其他开发工作流的推荐基线。另外，对于多项目间的代码交付和共享，还可以定义是否允许接受其他项目的变更等。除了项目一级的策略以外，在工作流一级UCM也有类似的访问策略，如某个工作流是否允许接受来自本项目或其他项目的工作流上的变更，是否允许向本项目或其他项目的工作流交付变更等等。


开发团队采用


成功的软件配置管理需要同时重视人的活动和得到整个开发团队的全体接受。如果开发团队成员不能或不采用SCM方法论的话，SCM实现将会失败。Rational软件多年来从成功的软件开发团队和自身的软件开发中吸取佳实践经验，将UCM作为一个可为开发团队采用的优化过程来进行设计。UCM的功能已全部嵌入到Rational统一开发过程管理（Rational Unified Process，RUP）中，RUP是在软件开发的各个生命周期应用佳软件开发经验的一个实用框架。软件开发团队通过直接访问RUP并通过Rational ClearCase，Rational ClearQuest和Rational Suite的工具专家可以得到关于UCM过程及其详细描述。


UCM通过使开发人员可以完成下面的工作而简化了他们的工作：


快速准确地访问正确工件的正确版本
在他们的工作空间中相互隔离地进行各自的工作，但可以选择什么时候交付自己的工作及接收其他人员的变更
使用项目策略来标识什么时候质量达到了可以接受的级别从而可以在自己的私有工作空间中接收其他人员的变更
从他们自己的桌面透明地访问SCM工具。使用可同他们常使用的工具（如Visual C++）进行集成的工具来进行他们的工作--在开发活动上没有附加不适当约束或增加工作时间
自动而透明地将变更集同活动进行集成
自动进行活动的跟踪、管理和报告。
另外，UCM还减轻了项目经理的负担，从而项目经理可以


通过一个预定义的生命周期工作流在任何时间标识一个具体活动的状态
用统一的报告来监控新的项目状态
将精力集中在高优先级或紧急的事件（活动）上
确定工作负载并平衡任务分配
贯穿生命周期的工件
到现在为止，本文主要集中在源代码和其相关工件上，如对象文件和头文件等。但是使用UCM时贯穿生命周期的变更也可以由非开发人员进行管理，这样佳实现了统一变更管理的全部好处。这些非开发人员包括分析人员，设计人员以及测试人员（图7）。相应的工件包括他们在相关领域产生的工件，例如分析人员所创建的需求文档和用例（use cases），设计人员所建立的设计模型和用例，测试人员建立的测试脚本，测试数据和测试结果。


为了高效地通信和协作工作，开发团队成员需要有效地共享这些工件。Rational Suite包含有一个集成平台，通过这一公共平台可以访问贯穿多个领域的所有类型的开发工件。作为Rational Suite的一部分，UCM提供了一个用于管理贯穿软件开发生命周期的信息共享的过程层。现在每个Rational Suite产品套件中均包含了这两个产品，这样每个Rational Suite产品都包含了对UCM过程的支持。非软件开发人员（如分析人员、设计人员以及测试人员）可以应用UCM原理象控制代码变更一样来控制他们生产的工件（如需求文档，用例，设计模型，测试脚本及测试数据）。Rational ClearQuest工作流引擎强化了活动管理，另外一致的工作流使得所有的团队成员都可以容易地标识优先级，而ClearQuest提供的工作列表（to do list）特性可以使每个人均可从他们的桌面透明访问待进行的工作（活动）列表，从而容易地标识出他们下一步需要进行的工作。同样构件基线是新工作（分析、设计、开发及测试）的基础并指导团队成员什么时候更新他们工作空间。


图7：开发团队成员在生命周期的不同阶段产生不同的工件

来自分析的工件


分析人员扮演着定义项目范围的重要角色，分析人员需要确定解决方案是什么以及系统边界。在分析期间这些专业人员创建了多种不同的工件来帮助解释说明所建议的解决方案，这些工件包括需求文档，用例以及可视化模型。开发团队在整个开发过程中不断使用这些工件来管理项目变更是必不可少的。