第三代配置管理解决方案统一变更管理UCM.docx

第三代配置管理解决方案统一变更管理UCM.docx

《第三代配置管理解决方案统一变更管理UCM.docx》由会员分享，可在线阅读，更多相关《第三代配置管理解决方案统一变更管理UCM.docx（18页珍藏版）》请在冰豆网上搜索。

第三代配置管理解决方案统一变更管理UCM

第三代配置管理解决方案：

统一变更管理（UCM）

一种基于活动的配置管理过程

RationalSoftware,China

Oct2002

前言.............................................................3

软件开发过程中的变更.............................................5

变更是非常频繁并且是不可避免的！

...............................5

管理变更的能力是项目成败的关键！

...............................5

统一变更管理.....................................................6

活动和工件.....................................................6

贯穿生命周期的工件............................................19

总结............................................................23

2

前言

二十多年来，Rational软件一直致力于提供全面可靠的软件开发管理解决方案，其中软件配置管理（softwareconfigurationmanagement，SCM）解决方案集成了两个业界领先的工具：

用于软件工件管理（softwareartifactmanagement，SAM）的RationalClearCase和用于缺陷及变更跟踪的RationalClearQuest。

这两个工具合在一起构成了一个市场领先的软件配置管理系统，提供了真正用于加速软件开发周期和流程的解决方案，这一方案已连续四年居市场第一位（摘自IDC报告：

“Rational´sSCMsolutioncontinuedtodominatethesoftwareconfigurationmanagementmarketin2001,witha36.5percentshare.Rational´sSCMsolutionmarketsharegrewin2001despiteadeclineinrevenueintheoverallSCMmarketduringtheyear.”）。

在大量软件工程实践经验和用户反馈的基础上，Rational软件提出了第三代的配置管理解决方案–统一变更管理（UCM）。

这里，首先，让我们简单回顾一下软件配置管理的发展历程：

软件配置管理在其不长的发展历史中不断进行演化，从七十年代基于文件（FileBased）以版本控制、支持check-out/check-in模型和简单分支为主要特征的第一代软件配置管理，到基于项目库（ProjectBased）将元数据与配置项分开存储管理从而更好地支持并行开发、团队协作以及过程管理的第二代软件配置管理，发展到今天基于文件访问透明（FileTransparencyBased，即开发人员可以在不保留本地副本的情况下直接访问受控配置项）、全面结合变更请求管理（SoftwareChangeManagement）、软件系统分析设计以及软件测试等等各个软件开发环节的完整的软件配置管理方案。

而Rational配置管理解决方案UCM正是体现这一趋势的代表。

以前两代配置管理方法为基础上，Rational软件提出的统一变更管理（UCM）是用于管理软件开发过程（包括从需求到版本发布）中所有变更的“最佳实

3

践”流程。

UCM定义了一个可以立即用于软件开发项目的一致并基于活动的变更管理流程。

通过RationalClearCase和ClearQuest的支持，UCM已成为Rational用于软件开发最佳实践的全面框架——Rationial统一过程（RUP）的关键组成部分。

根据软件开发团队的具体需要，可以使用相应的过程模型来加速软件开发进度，提高软件质量并优化开发过程。

UCM通过抽象层次的提升简化了软件开发，从而使得软件开发团队从更高的层次根据活动（activity）来管理变更。

通过UCM，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，这样避免了管理人员手动跟踪所有文件变更。

使用UCM还可以获得以下好处：

•预定义的工作流程：

可以直接采用预定义的UCM工作流程，快速提升开发组织的软件配置管理水平；

•项目的跟踪和组织：

项目管理人员可以实时掌握项目的最新动态，合理分配资源和调度开发活动；

•协作自动化：

通过将许多耗时较多的任务自动化处理，UCM使得开发人员更多地将注意力集中在更高层次的开发活动上；

•轻松管理基线：

UCM将开发活动嵌入到各个基线中，这样测试人员确切地知道他们将测试什么，而开发人员则确切地知道其他开发人员做了什么；

•支持跨功能开发组：

UCM已成为RationalSuite产品中的核心部分，从而可以将从需求到测试各个阶段的工件（例如需求文档、设计模型、应用源代码、测试用例以及HTML及XML内容等）在UCM框架下进行统一集成，简化了贯穿整个软件开发周期的变更过程；

•基于同一代码构件可以进行多项目开发，简化了多项目开发管理，增大了代码共享，节省了开发资源；

•可扩展性：

小型团队可以从ClearCaseLT和UCM开始，而大型团队可以结合ClearCase的高级构建管理（buildmanagment）功能，以及ClearCaseMultiSite和ClearQuestMultiSite跨地域的使用UCM。

4

本文第三代配置管理解决方案：

一种基于活动的配置管理过程详细描述了统一变更管理（UCM）的概念、优点以及开发团队如何通过使用RationalClearCase，RationalClearQuest和RationalSuite来受益。

软件开发过程中的变更

变更是非常频繁并且是不可避免的！

今天的软件开发团队面临着巨大的挑战：

一方面Internet驱动下的市场要求以空前的速度来开发高质量的软件应用；另一方面，软件应用需求随着开发环境和结构的日趋复杂而变得更加复杂；加上分布式开发、高性能要求、多平台、更短和连续的发布周期——这些及其他一些因素加重了软件开发一直承受的压力，实际上现在许多软件开发团队经常在能否成功开发一个新型应用上“赌博”。

由于软件开发不同于传统意义的工程技术（如建筑、机械等），市场变化以及技术上的高速更新都注定了软件变更是非常频繁并且是不可避免的，可以说变更是软件开发的基石。

一方面在软件开发环境下的内部活动以新特性、新功能增强以及缺陷修复等方式不停地制造着变更；另一方面外部因素——例如新操作环境，新工具的集成，工程技术和市场条件的改善等以另一种力量驱动着变更。

管理变更的能力是项目成败的关键！

既然变更是不可避免的，那么如何管理、追踪和控制变更就显得尤为重要。

尽管有多种方式可以帮助开发团队提高变更处理能力，但其中最重要的一点是整个团队的协作性，这是因为以一种可重复和可预测的方式进行高质量软件的开发需要一组开发人员相互协作。

随着系统变得越来越大和越来越复杂，尽管个人生产率依然十分重要，但是决定项目成败更多的是作为一个整体的开发团队的生产率。

5

而软件开发团队的生产率很大程度上是由其相互协作和组织活动的能力决定的，并且开发团队的成功同其如何高效地响应不断变化的环境因素紧密相连。

对在竞争激烈的市场下想占有一席之地的开发团队而言拒绝变更无疑是行不通的，只有积极面对变更，采取有效的工具、方法和流程有机地管理、追踪和控制变更才是保证开发团队成功的关键。

另外，由于各种因素的变更，原来采用的工具、方法和流程也会随着组织的成长和不停变化的需求而逐步演化，因此对软件开发团队来说另一个关键的成功因素是其扩展能力。

统一变更管理

随着开发团队的成长、产品发布周期的加速以及对软件资产（包括代码、文档等）控制的加强，对基于第三代配置管理工具和过程的需要变得越来越大。

Rational软件的统一变更管理（UCM）通过RationalClearCase，RationalClearQuest以及RationalSuite所提供的开发平台实现了贯穿整个软件开发周期的配置管理过程，即基于活动对软件构件和项目进行变更管理。

活动和工件

随着软件系统和开发团队在规模和复杂性上的不断增长，对开发团队来说如何围绕周期性的版本发布来合理地组织开发活动以及高效地管理用于实现这些活动的工件变得日益重要。

活动（activity）可以是在现有产品中修复一个缺陷或者新加一个增强功能。

工件（artifact）可以是在开发生命周期中涉及的任何东西，例如需求文档，源代码，设计模型或者测试脚本等。

实际上软件开发过程就是软件开发团队执行活动并生产工件（图1）。

UCM集成了由RationalClearQuest提供的变更请求活动管理和RationalClearCase提供的工件管理功能。

6

图1：

UCM集成了RationalClearQuest提供的活动管理能力和RationalClearCase提供的工件管理功能

活动管理

UCM中的活动管理是由RationalClearQuest提供的，RationalClearQuest是一个高度灵活和可扩展的缺陷及变更跟踪系统，它可以捕获和跟踪所有类型的变更请求（例如产品缺陷、增强请求、文档变动等）。

在UCM中这些变更均以活动出现。

RationalClearQuest为活动的跟踪和管理提供了可定制的工作流，这使得开发团队可以更容易地：

•将活动分配给某个具体的开发人员

•标识同活动相关的优先级、当前状态和其他信息（如负责人、估计工期、影响程度等）

•自动产生查询、报告和图表

7

根据开发团队或开发过程需求可以灵活地调整ClearQuest工作流引擎：

如果开发团队需要快速部署，那么也可以不进行定制，直接使用ClearQuest预定义的变更过程、表单和相关规则（图2）；当开发团队需要在预定义的过程上进行定制时，可以使用ClearQuest对他们的变更过程的各个方面——包括缺陷和变更请求的状态转移生命周期，数据库字段，用户界面（表单）布局，报告，图表和查询等进行定制。

贯穿整个开发过程用于管理和跟踪缺陷和其他变更的一个高效工作流对于满足当今高质量标准及紧迫的产品工期的需要是非常重要的。

UCM提升了这些变更的抽象层次以便可以从活动的角度来观察变更，然后RationalClearQuest工作流引擎将活动同相关的开发工件连接在一起。

图2：

RationalClearQuest提供了一个现成的过程框架用于缺陷和变更跟踪工作流

工件管理

RationalClearCase提供了一个软件工件管理（SAM）框架，开发团队可以使用这一框架来管理贯穿项目生命周期的所有工件。

UCM将RationalClearCase基础框架同RationalClearQuest中的活动管理结合在一起，从而提供了对工件和活动的集成管理。

RationalClearCase提供了：

•安全的工件存储和版本化

8

•并行开发基础框架——无限分支能力和强大的合并功能

•自动代码共享

•用于选择正确工件版本的工作空间管理

•完全的可延展性——从小型本地项目工作组到大型全球分布式开发团队

另外，RationalClearCase提供了灵活的SCM的基础框架，通过使用灵活的元数据，如标签、分支、属性、触发器（trigger）和超级链接（hyperlinks）等，开发团队可以定制他们自己的SCM过程。

由此可见，不同开发团队和项目可以通过RationalClearCase使用不同的策略，开发团队可以从这种灵活性中受益。

而UCM是基于一个经过验证的、成功的开发过程，因此UCM为希望快速启动高效SCM的开发团队也可以直接使用这一过程来自动实现项目策略。

UCM具体在以下六个方面提供了开发过程。

UCM：

六个过程领域

UCM在六个具体领域提供了所定义的过程：

•开发人员在共享及公共代码工件上的隔离和协作；

•将一起开发、集成和发布的相关工件组按构件（component）进行组织；

•在项目里程碑创建构件基线（baseline）并根据所建立的质量标准来提升基线；

•将变更组织为变更集（changeset）；

•将活动管理和工件管理集成在一起；

•按项目来组织软件开发并支持多项目之间的代码共享；

开发人员的隔离和协作

开发人员需要相互隔离的工作环境以隔离彼此的工作，避免其他组成员的变更潜在地影响其工作的稳定性。

RationalClearCase提供了两种方式来访问工件的正确版本并在私有工作空间中在这些工件上进行工作。

这两种方式是静态视图和独特的基于MVFS的动态视图，它们可以据本地或网络使用而分别进行实施。

9

静态视图为开发人员提供了在断开网络连接的情况下进行工作的灵活性，另外开发人员也可以容易地将他们的工作同开发主线进行同步。

动态视图则通过一个独特的虚拟文件系统（MVFS）来实现，它使得开发人员可以透明地访问正确工件的正确版本而无需将这些工件版本复制到本地硬盘驱动器上。

另外由于动态视图可以实时进行自动更新，因此紧密工作在同一分支上的开发团队无需手动更新/复制文件即可立即看到其他人员所做的变动。

不管使用何种方式，开发人员都可以并行工作在多个发布版本上。

例如，一个开发人员工作在发布版本2上，同时他也可以修复发布版本1中的一个缺陷，而不用担心自己的两个活动涉及的代码互相干扰或受其他开发人员的干扰。

隔离不稳定的变更对于将错误最小化是非常关键的，但是将所有的变更集成到一个所有开发团队成员均可访问的公共工作区域却是团队开发环境下的一个基本要求。

今天基于构件的软件开发方法论的广泛应用以及代码变更频率和幅度的增加都要求开发团队能经常和较早地将各个开发人员的工作进行集成。

以便在尽早解决可能出现的问题。

使用RationalClearCase，开发团队可以实现多种项目策略来同时进行工作的隔离和协作。

通过强大的分支和合并功能RationalClearCase可以支持大规模的并行开发。

在ClearCase中可以根据不同用途来建立分支，如开发人员分支，新特性分支、缺陷修复分支、新需求分支等等，从而开发团队可以根据需要建立适于自身情况的分支模型，灵活实现软件配置管理流程。

但对于希望能快速利用成熟的软件开发流程的开发团队而言，UCM则提供了一个直接可用的分支模型。

实际上在UCM中，在分支基础上对其在更高层次上进行了抽象，从而形成了一个新概念——流（stream）。

流表示一个私有或共享的工作空间，它定义了项目版本的一致配置并在UCM项目中的隔离和有效协作之间提供了一种平衡。

熟悉ClearCase的读者可以将流理解为开发人员分支，UCM中既有为每个开发人员配置的私有开发流，同时为负责集成所有交付工作的集成人员配置的公共集成流

10

（图3）。

由于UCM紧密结合了活动管理，因此其他分支用途，如特性分支、缺陷修复分支等将作为活动出现并附加到相应的工作流中。

图3：

UCM提供了公共集成工作区和私有工作区

私有开发流为开发人员提供了相互隔离的工作空间，该空间在最开始由满足一定质量标准的公共工件进行初始化。

开发人员使用这些私有工作空间来进行工件的变更，构建和测试。

当开发人员对他们的变更感到满意时，他们可以将这些变更交付（deliver）到公共集成流上。

为了使开发人员同其他人员的进度同步，开发人员也可以用来自项目公共集成流上最新的稳定基线来变基（rebase）他们的私有工作流。

使用UCM，开发人员可以选择什么时候进行交付和变基。

实际上项目集成流充当了所有开发人员的所有变更的协调点。

为了更好地协调所有开发人员的变更集成，UCM引入了基线（baseline）的概念作为对项目进度的度量。

基线是一次构建（build）或配置的抽象表示，它实际上是构件的一个版本，而构件是相关工件的集合。

项目开发团队在开发过程期间不断地创建和提升基线。

随着不同开发人员交付变更给集成流，他们交付的变更将被逐一收集到项目基线中。

随着基线的构建、测试和批准，它们可以被逐步提升到不同的基线级别。

11

基线提升级别具有两方面的功能：

第一，它使项目经理或项目管理人员可以建立软件质量标准。

由于当基线达到某种预定义的质量标准时就可以被标以某种基线级别，因此项目经理可以设置项目策略，标识出在哪一个基线级别（如“通过测试的”）开发人员可以执行变基操作。

第二，基线提升级别就具体的开发人员应该如何同其所开发的工件进行交互提供了指导。

例如，根据某条基线通过某些冒烟测试的时间可以帮助测试人员确定什么时候开始测试。

构件基线

第二个UCM过程领域是将工件组织为构件。

在第二代配置管理中，大多以文件版本形式来管理所有的文件，当一个复杂项目中包含成千个文件上万个版本时，整个项目的开发控制将变得相当复杂，因此对众多的文件进行合理分类以呈现系统的设计要素可以大大简化项目开发控制。

UCM通过将多个工件组织为构件（在UCM中构件指一个VOB的根目录或VOB的某个第一层子目录）从而扩展了软件工件管理的版本控制能力，并且UCM还提供了用于自动化构件管理的工具和过程。

即用基线对构件而不是构件中众多的版本进行标识，然后用这一基线作为新的开发起点并更新开发人员的工作空间。

构件基线是在ClearCase标签（label）的基础上结合活动管理所做的扩展，即您可以知道一个UCM构件基线中包含了哪些开发活动，例如一条基线可能包含了三个开发活动，如BUG101的修复、用户登录界面汉化以及新增打印特性的支持。

对于包含多个构件的复杂系统，UCM提供了基于多个构件的组合基线，即多个构件之间可以建立依赖关系，一旦底层构件的基线发生变化，例如生成一条新基线，其上层构件相应地也自动建立起一条基线，该基线自动包含底层构件基线。

例如，一个较为复杂的MIS系统包含“数据库访问”，“业务逻辑处理”和“前端图形界面”三个构件，其中“前端图形界面”构件依赖于“业务逻辑

12

处理”构件，而“业务逻辑处理”构件依赖于“数据库访问”构件。

这样当“数据库访问”构件发生了变化并新建了一条新基线（如DB_BASELINE_Dec24）后，在“业务逻辑处理”构件和“前端图形界面”构件各自动建立了一条新基线（如BUSINESS_BASELINE_Dec24和GUI_BASELINE_Dec24）。

这样上层构件的最新基线可以自动跟踪底层构件的最新基线。

构件管理的自动化对于高效无误地开发可能包含数千个源代码工件（还有其他相关的工件，如web内容，设计模型，需求说明和测试脚本等）的复杂软件系统而言意义重大。

构件基线提升

项目开发团队的成员工作在一个UCM项目（project）中，项目经理通过配置软件构件从而使项目成为由构件构成的体系结构。

大多数组织将UCM管理的构件设计为可以反映出他们软件体系结构的方式（图4），即将所有相关工件按体系结构组织为有意义的子系统，进而放入不同的构件中。

图4：

用UCM构件直接对软件体系结构建模

13

如上节所描述的，开发人员在交付变更到公共集成流时可以周期性地更新他们私有开发流中的构件。

然后开发团队可以根据开发过程的当前阶段和质量级别对构件进行评级。

项目策略确定了在开发人员变基之前构件基线必须达到的质量级别以及其他开发团队成员（如测试人员）应该如何同构件基线交互。

在稍后会对项目以及项目策略做更多描述。

UCM提供了五种预定义的基线级别，它们包括被拒绝（rejected），初始（initial），通过构建（built），通过测试（tested）和已发布（released）。

另外，UCM允许开发团队用他们自己的命名规范和提升策略对这些预定义基线级别进行定制。

变更集

第四个UCM过程领域是将独立的工件变更组织为可作为整体进行交付、跟踪和管理的变更集中。

由于通常当开发人员工作在一个活动（例如缺陷修复）上时，他们很少只修改一个文件，因此用变更集可以表示用以完成某个具体活动的工件的所有变更，例如为修改一个编号为63的缺陷变动了50个目录/文件的120个版本，则缺陷63的变更集为相关的120个文件/目录版本。

当开发人员同时工作在多个变更请求上的需要使得这一过程更加复杂。

例如，一个开发人员在进行一个新发布版本的开发，这时由于当前发布版本的一个错误要求他不得不中断当前的开发工作转而去修复这一缺陷，这样该开发人员必须在同一工件上进行两种不同的变更，一种是在未来发布版本中的增强功能变更，另一种是在前一发布版本中修复缺陷的变更。

通过将同一个开发活动相关的所有变更收集到一个变更集中，UCM简化了管理多个工件变更或者多个工件版本的过程。

UCM围绕具体的开发活动来进行工作组织，同时UCM还确保已完成的活动包含所有必要工件上发生的所有变更。

活动和工件管理

第五个UCM过程领域是通过使用一个可将活动及其相关工件集链接起来的自动化工作流（图5）将活动管理和工件管理集成起来。

这给了开发团队极大的灵

14

活性来为不同类型活动的管理指定不同的工作流。

UCM提供了最常用活动类型的预定义工作流，包括缺陷修复和增强请求。

图5：

UCM工作流概览

开发团队还可以使用ClearQuestDesigner这一模块来对这些预定义过程进行定制，项目经理或者项目管理人员可以用它来创建所有需要的活动类型，包括缺陷修复，增强功能请求，文档变动以及Web网站变动等。

使用ClearQuestDesigner的图形用户界面，项目经理也可以定义字段，表单以及每个记录类型的状态转移。

为了方便开发人员更容易地标识活动和项目代码库中工件间的关系，UCM自动将活动和其相关的变更集链接起来（图6）。

当在一个UCM项目中工作时，开发人员所交付的是活动（见开发人员隔离和协作一节）而不是文件形式的工件。

类似的，当开发人员变基时，他们根据新构件基线提供的活动（而不是文件形式的工件）来重审将要在他们的私有开发流中接收的变更内容。

这样，开发人员不仅可以看到所有相关工件完整的版本历史，而且可以看到实现每个变更的所有活动。

这给了开发团队一个项目是如何从一个阶段演进到下一个阶段

15

演进的全面视图，当需要标识出一个工件版本的变更是如何影响另一个版本时，这一优点所带来的价值是无法估计的。

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

图6：

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

项目和项目策略

UCM中的项目可以和实际软件开发中的各种项目对应，每个UCM项目包含一个集成工作流和若干个私有开发流，项目可由一组构件构成。

这里需要强调的是一个构件可以被多个项目共享，进而项目A中的开发人员可以对一个构件进行修改，创建新的构件基线；而项目B的开发人员可以参照同一构件以及该构件在项目A中生成的基线，但不能对该构件进行任何改动。

因而UCM项目从代码级提供了软件共享及重用的良好基础。

例如某系统集成公司的湖北分公司刚刚结束了为某银行开发的客服系统1.0的开发（我们可以将最终交付的版本称之为XBANK_CRM_HuBei_1.0），与此同时该系统集成公司的北京分公司正准备为另一家银行进行类似系统