关于UCM(统一变更管理)的体会[二]---整合
进入正题前先来看一幅图：
这是IBM Rational使用频率很高的一幅宣传UCM的图片，当第一眼看到它的形
状，你想到了什么？它的形状很象阴阳、太极。
UCM提高了抽象的层次，把开发看成是“进行开发活动，开发工件“。这里活动
（activity）是泛指一切开发中的活动，工件（artifact）则包括测试脚本、文
档、代码等一切开发资产。这样，开发过程的管理的关键就是如何管理活动和工
件。
把这两件事情整合在一起确实是非常有意义的。我们在日常开发工作中经常碰
到这样的情况：
－项目经理把任务分派给了开发人员，但是却无法及时准确的验证真正的开
发情况，往往都是靠“自觉”，由开发人员自己上报。
－开发人员得到开发任务，却在寻找对应代码的时候浪费了很多时间，尤其
是刚刚加入的人员或变动频繁的复杂项目。
－测试用例发生了变更，不知道什么版本的测试用例对应哪些测试执行和缺
陷。
－项目开发中需求频繁发生变更，找不到代码因什么而更改，正确的代码版
本被覆盖。
－回归测试时所谓“已修正”的bug再次出现。
出现这些问题的原因是因为开发活动和开发工件无法建立起对应关系，被割
裂了，虽然对于两者都会去管理，但是往往出现遗漏和损失。
在IBM Rational中使用ClearCase管理工件，使用ClearQuest管理活动。
ClearCase是众所周知的功能最为全面和强大的配置管理工具，ClearQuest通过内
置的设计器则可以适用于管理各种活动并定制活动流程。（甚至可以定制来管理
办公审批流程）。
更有趣的是两者通过变更集（change set）整合在了一起。在ClearQuest里
面可以通过变更集直接找到对应于某个开发活动的工件。你可以轻而易举的在系
统中查到和维护活动的相关信息、描述、状态、优先级甚至附件和历史（可定制
的），并通过变更集直接关联到一个组工件的具体版本。通过使用UCM日常的开发
工作被组织成为了更为合理的“工作单元”，“工作单元”包含了开发工作所需要的
活动/变更信息、对应工件，以及集成和追溯的能力。它不但使得开发工作的过程
在一定程度上自动化还改变了原有的工作方式，当你的工作成果被提交的时候，
你不再提交“文件”，而是提交包含一组特定版本工件的“活动”。于是对于开发活
动的管理就更加有效并紧密的与开发产物结合在了一起，这样上面出现的问题就
迎刃而解了。
UCM平衡了工件和活动，确实让人感觉到有点象阴阳平衡。如果你学习了UCM
以及ClearCase和ClearQuest的细节后也许你会发现更多的平衡，比如在工作空间
管理上，stream对独立工作空间和共享的平衡等。。。
