四、我公司的实际应用
在一个通信软件项目中，我公司采用了UCM来进行变更管理，至今已有近一年时间。所用的ClearCase和ClearQuest的版本为2001A.04.00。由于UCM的简单易用，开发人员只用了几天就掌握了使用方法，并且一直较为稳定地在运用。以下就UCM中的各个步骤，介绍一下在此项目中的实际应用。
1. 制定配置管理计划
在建立UCM项目之前，首先制定了一个详细的配置管理计划。该计划确定ClearCase网路的构成，ClearQuest数据库的结构，依软件系统架构定义所需各组件(vob),制定UCM项目的策略，等等。 
图4
ClearCase网路的构成如图4所示，名为LICENSE的电脑作为ClearCase和Suite的License Server，名为PDC3RASRV的电脑作为ClearCase之VOB/VIEW Server及Registry Server，名为VVTSERVE的电脑存储ClearQuest Schema Repository Database和User Database(采用SQL Server 7.0)。
ClearQuest之Schema是基于Enterprise,并作了一些定制。
2. 建立项目
首先用VOB Creation Wizard创建PVOB以及作为UCM Component的各个vob, 然后在ClearCase Project Explorer中创建UCM项目，设定该项目采用ClearQuest UCM集成(ClearQuest数据库已建立)。
图5为该UCM项目之UCM Component示意。
图5
3. 加入项目
开发者在ClearCase Explorer中，用Join Project精灵来加入到此UCM项目。每个开发者创建一个自己的开发流，一个开发视图(采用快照视图),一个项目集成视图(采用动态视图)。
4. 新增，分配任务
当有功能和设计变更要求时，项目经理在ClearQuest中新建变更需求记录，然后由开发团队或开发负责人对每一变更需求记录，分析需要有哪些开发者做哪些具体改动，然后由开发负责人在ClearQuest中新建对应到此变更需求记录的一个或多个BaseCMActivity,并分配给相关开发者。相关开发者在ClearCase Explorer之My Activities中，就可看到自己要处理的变更。 当测试人员发现缺陷时，在ClearQuest中新建缺陷记录，开发负责人经分析后，将此缺陷分配给相关开发者。相关开发者在ClearCase Explorer之My Activities中，就可看到自己要解决的问题点。另外，我们在ClearQuest之Email Rules中，定制记录使得当变更和缺陷被分配后，相关开发人员能够及时收到Email通知。图6为某一开发者当前的任务清单，可以看到，此开发人员有一界面变动和一个缺陷问题需要处理。 
图6
5. 针对任务进行工作
开发人员针对被分配的活动进行工作，需要检出(Check Out)和检入(Check In)相关文件，检出和检入既可在Rose, Rose RealTime, Visual C++这些建模和编码环境中进行，也可在ClearCase Explorer或Windows Explorer中完成。在检出文件时，把对应的活动设为当前要处理的任务，这样，UCM就会把以后检入产生的文件新版本所作的任何改动和此活动相关联起来，便于之后的活动交付和追溯比较。
图7为某一开发者在Rose RealTime中，检出一Capsule以修正某一缺陷。
图7
6. 提交活动
开发人员完成活动后，把所做工作提交到项目共享工作区。提交时，可选择提交哪些活动；对于目前还未完成的活动，或者暂时不用整合到项目中的活动，可选择不提交。
图8为某一开发者提交活动时的活动选择画面。
图8
7. 整合项目
当开发人员把需要整合集成的活动提交到项目集成流后，项目整合人员首先锁住集成流，然后在集成流上的某一视图中进行程序的编译，安装的制作。
8. 建立新基线
如果此Build可以作为后续开发的基准，则由项目管理员创建新的基线，然后解锁集成流，以允许后续的活动提交。新基线的创建可以针对实际有变更的UCM Component (vob)进行。
9. 从新基线Rebase
各开发人员从新的基线Rebase,更新其私有工作区，以包含此基线对应的目录和文件之版本，反映项目的当前最新状况。
10. 变更的追踪
此UCM项目使用了ClearQuest集成，通过直观的图形界面，对于任何变更活动，都可以方便地查看具体的变动内容。
图9为某一新增功能所涉及到的文件及其版本。可以看到，为了加入此功能，Rose模型的一个包(package)和若干C++源程序有变动，有的文件有一次以上的修改。
图10显示为了察看某一文件较之加入此功能前，有哪些具体修改所执行的操作。 
图9 
五、几点体会
采用UCM，使我们的配置管理工作变得简单而有效，提高了项目开发的效率，提升了产品的品质。当然，在实际使用中，我们也遇到了一些问题，通过自己的研究或Rational的技术支持，这些问题大多在较短的时间内得到了解决。
近一年的UCM使用下来，我们有以下一些体会：VOB的规划相当重要 建立UCM项目，首先要确定Component以及其下的目录结构，不当的Component规划会导致项目开发中不必要的新基线和rebase操作，也使得文档，模型，源程序和测试数据分布紊乱且不易查找。创建UCM项目前，软件的系统架构应已确定。根据软件的子系统，模块来建立相应的vob，使得属于不同子系统，模块的开发人员相互之间不会有干扰。 不同客户版本的处理 有时，开发的软件需要交付给不同的客户，这些客户对于产品有不同的需求。需要针对不同的客户创建不同的UCM项目，它们共享部份或全部的Component。 ClearCase命令行操作不可避免 然UCM提供了简便的图形用户界面，但对于ClearCase管理员，仍然需要用到基于ClearCase命令行的操作。因为UCM在提供简单，易用性的同时，也隐藏了一些Base ClearCase的内容。诸如license的管理，vob的备份和恢复，被损坏的view之删除，不同项目间的merge,等等，都需要项目的ClearCase管理员用ClearCase命令行来进行。 缺乏一定灵活性 UCM以活动和流的方式呈现给用户。每个UCM项目有一个集成流和多个开发流，开发者从其开发流交付活动到集成流，并从集成流更新其开发流以包含其他开发者的工作，各开发流相互之间无法归并。由ClearCase的分支被隐含，不少基于Base ClearCase的灵活功能无法使用。例如，有一 20人的开发团队，开发者A要用到开发者B新的源程序，需要B先提交包含新的源程序的活动到集成流，然后由项目管理员建立新基线，再由A从新基线上更新其工作区以获得开发者B新的源程序。而很可能此源程序还处在调试阶段，却被提交到了项目集成流。开发团队越大，此类现象就越多。
六、结束语
以上是对Rational UCM的介绍和我们在项目中的实际应用情况。现今为止，我们只在一个项目中采用了UCM，且不到一年，既使这样，我们已深切感受到UCM给软件开发带来的效益。 UCM的2002版功能更强大，也更灵活，提供了一些在2001.A版中无法实现的功能，相信在以后的项目开发中，使用它或更新的版本，将更大程度上提高我们的软件开发效率，提升我们的软件品质。
文章来源于领测软件测试网 https://www.ltesting.net/
