【IT168 技术文章】
本篇文章阐述了统一变更管理（UCM），一个由Rational结合我们的用户开发的特殊的变更管理过程。
术语变更管理（CM）涉及到一个组织或项目用来计划、执行和跟踪一个软件系统变更的过程和工具。统一变更管理（UCM），是由Rational结合我们的用户而开发的一个特定的变更管理过程。UCM支持软件项目团队管理文件、目录、构件和系统的产生和修改。从理论上讲，变更管理过程由两个流程组成：
.软件配置管理（SCM）
.缺陷和变更追踪（DCT）1
SCM涉及到版本控制、工作空间管理、软件集成、软件构造、软件部署和发布过程。缺陷和变更追踪处理缺陷、增强请求和新功能被提交、评估、实施，验证和完成的过程和流程。
Rational提供了两个工具来分别支持这两个流程。首先是Rational ClearCase®，自动化软件配置管理相关的过程。其次是Rational ClearQuest，自动化缺陷和变更跟踪相关的过程。这两个工具合在一起，你就可以自动化统一变更管理（UCM）了。实际上，你使用ClearCase和ClearQuest几乎可以自动化任何变更管理过程，但是如果你希望更容易地支持变更管理，UCM是你非常好的的选择。
在Rational，我们已经用各种方法回答了这个问题，“什么是UCM过程？”（参见下面的参考）。我们提供产品文档，一本关于ClearCase和UCM的书，以及一张多媒体CD，可以从这里free免费预定。因此，如果你已经知道一些有关UCM的内容，你可能会问，“是什么使得UCM比其它的变更管理过程更好？”在这里我将尝试回答此问题。
让我们从解释一个过程开始，它不可能适合所有的软件项目。然而，实际上如果不放在一个实际的软件开发项目环境中，将UCM描述为优于其它变更管理过程是没有实际意义的。因此，我将描述什么使得UCM不同于传统的变更管理过程。接下来你就可以自己确定这些区别如何应用到你自己的软件开发项目里。
使用UCM进行更高级别的抽象
如果你看一下软件语言的发展，很明显，在计算机科学和工程十多年来，机器代码的抽象级别有了很大的提高。在最低级别上，所有都是1和0，并且我认为非常早期的开发工程师就工作在这个级别上。很快有了汇编语言，它将1和0抽象成基本的机器指令，例如用值Y加载寄存器X。接下来的语言例如Pascal and C，它们提供了更高次序的结构例如“if-then-else”语句。并且现在，在今天，我们开始认识到可视化“编程”的潜力。通过模型化软件系统的行为，我们可以让代码为我们而产生。通过引入这些抽象，开发者进行更复杂软件系统的编程会变得更容易和更快速。
类似的事情发生在配置管理工具的演变上。最初，配置管理工具只是由保存版本的存储库组成：一个文件和目录的内容在给定的时间点上存储和确定，并且在需要时可以重现取回。然后到了允许用户管理工作空间的工具：一个特殊任务或活动所选择的文件和目录的特定版本集。并且，随着较作为低级别的抽象，例如存储库和工作空间，变得普通和广泛被接受，较高等级功能可以放在顶端，以简化变更管理过程。UCM正是做这些。让我们看看UCM包括的三个关键抽象：项目，构件基线，和活动。
项目
通常，软件开发团队被组织成项目。这些项目，依次还有子系统，等等，因此一个项目可能非常大，或者是非常小。从变更管理的观点来看，项目的组织有三个目的：
.首先，项目定义了团队成员。这对安全目的和协助目的很有用，这两点对好的变更管理非常关键。
.其次，项目限制了团队需要知道的文件和目录的范围。也就是说，所有的文件和目录保存在库里，项目确定了开发者被分配的精确子集，那是项目需要考虑的方面。
.第三，项目为团队成员所执行的工作确定了一个公共集成点。
这些听上去非常平凡，但是UCM关键的优势在于在ClearCase和ClearQuest执行时，项目是一个物理对象在这个配置管理系统里，它规划了实际的项目，允许一个比可能的更高程度的自动化和安全，如果project项目不是配置管理工具的概念之一。例如，当新的开发者加入到一个UCM项目时，他们自动地被给定一个预先配置好他们所需要的文件和目录的正确版本的工作空间。
构件和构件基线
UCM里第二个关键的抽象是构件和构件基线。大多数版本控制系统包括存储库的概念，存储库是文件和这些文件版本的集合。一些工具，例如ClearCase，也将这些文件组织到目录并保存目录和目录版本。几乎所有重大的开发工作都包含大量的文件，这些文件包含的代码需要在开发下构造该系统。这些文件组织到目录里，并且这些组织经常列成系统的软件架构。在传统的配置管理系统中，这些关键的目录和其它的目录是不会被看成是同样的。然而，为了区别并保存这些目录，UCM引入了一个component构件的概念。一个UCM构件简单来说，是一个由同一个构件根目录下的文件和目录组成的目录树。
