UML软件工程组织

 
更多技术资源 文章，讲座 ,培训，咨询 请访问 www.uml.org.cn

 
IBM Rational 的变更管理 —— 第 2 部分：增强 IBM Rational 变更管理解决方案
 
作者：Robert Pierce　来源：IBM
 

本文内容包括:

本文来自于 Rational Edge：本文是两部分系列文章中的第二篇，探究了对 IBM Rational 变更管理系统的潜在增强能力，该系统可以进一步整合涉众的关注。第 1 部分讨论了 IBM Rational ClearQuest 开发团队如何使用 ClearQuest 产品及相关的集成及最佳实践。

本系列两部分文章例举了一些 IBM Rational ClearQuest? 开发团队所使用的变更管理中的最佳实践，还提供了一个变更管理通用工作流过程的概念实例。

在 第 1 部分中，我详细介绍了 ClearQuest 和 Rational 开发团队如何使用 ClearQuest 及相关的集成和过程连接涉众的关注，并且更好地服务于客户及开发团队成员。在此第 2 部分中，我将介绍进一步增强现有过程的方法。该方法中的概念被描述为通用工作流，尽管许多概念是与任意形式的变更或应用程序生命周期管理有关的。这些思想会给希望进一步优化其变更管理过程，从而更好地服务于所有涉众的所有软件开发组织带来潜在的利益。

编者提示：本文（两部分系列文章中的第 2 部分）中的图片，是延续第 2 部分， Rational Edge 2006 年 12 月刊中的序号。

工作流的增强

维护变更管理解决方案是持续进行的、迭代的开发过程。举例来说，随着系统或过程的变更，ClearQuest 方案可能需要变更。可能需要创建集成，或者可能需要在已知的记录类型中添加新的字段。或者，过程可能需要修正为适应性程序的一部分。

对于 RATLC 方案，需要一个解决方案，帮助将客户支持应用程序与开发团队的变更管理解决方案连接起来。这通称为 RETAIN RATLC Bridge，第 1 部分中已介绍过了。

IBM Rational 的 CM 系统是良好的，但不是完美的。例如，一旦评估、分配、处理，并解决了变更请求（change request，CR），那么 CR 的结束自动触发 RETAIN Call Center 应用程序中的更新信息，以便支持中心及客户可以看到解决状态。但我们想让它做更多事情。尤为特别地是，除非有方法可以追踪客户所确认的产品或项目之间的关系，否则，当在共享组件中处理该问题时，关于客户报告的问题什么时候及在哪里得到处理可能有些混乱。这里有一个实例说明我的意思：

  • 客户打电话给支持中心，叙述他们在 IBM Rational Installed Product Release 中遇到了问题。
  • 问题确定为软件缺陷，而支持中心在 RATLC 中创建了一个变更请求，生成了授权项目分析报告（Authorized Program Analysis Report，APAR）。
  • 开发团队试图分析出问题发生在哪里，以及确认在哪里处理该问题。
  • 设置 RETAIN Call Center APAR 关闭代码，通知用户该问题将在某个即将出版的产品版本中得到解决。然而，没有办法跟踪客户什么时候能用上该产品版本。

解决上面问题的一种方法是建立一个方法，定义并自动化找到问题的位置，以及客户获得该问题解决方案的时间和位置之间的相关性。这一点可能通过将 RETAIN Call Center 版本字段映射到产品版本或定义的项目的 RATLC 字段上来实现。

对此类型的考虑形成了对 RATLC 方案及 IBM Rational 开发组织的整个 ClearQuese 变更管理系统的未来的增强的基础。IBM Rational Internal Deployment 团队负责此项工作。他们提出的一些增强的想法与我们下面要讨论的，称之为通用工作流（common workflow）的内容相关。

设计通用工作流

通用工作流的目标是设计并实现方案，方案作为模板，不仅可以解析变更请求，而且还可以改进向用户或客户传达的关于变更和如何利用它，或者对于它采取什么行动的信息流。换句话说，工作流对所有的涉众的关注（即，角色）是“通用的”—— 不仅是那些开发团队的成员。

举例来说，在通用的工作流中，变更可以表现为问题。变更及其所影响的角色，可能是变更管理系统所在的组织内部的或外部的。此外，因为用户可能会担当一个或多个角色（例如，提交者、开发人员，或测试人员），所以通用工作流打算考虑角色间更容易的转换。

正如管理变更的通用工作流可能是为已知的产品团队、公司或行业建立的一样，它还可以为 ClearQuest 产品团队中的开发团队，为 IBM Rational 软件，为了整个 IBM 软件团队，或者 IBM 的所有地方而建立。

IBM Rational 的通用工作流目标

ClearQuest 中的通用工作流方案设计从状态和动作的概念映射、记录类型、字段及行为，以及所有确定的对象如何为 ClearQuest 用户数据库的用户工作开始。方案开发人员（Schema Developer）和管理员（Administrator）角色使用与支持变更管理系统所需的所有设计、实现，及部署任务的完成相关的用例。

对于 IBM Rational 开发组织来说，通用工作流设计增强了的更新 CM 系统理论上应该可以：

  • 客户报告与他们所安装的产品相关的问题。
  • 开发团队处理客户不可见的组件中的问题，例如，共享组件。
  • 通告客户什么时候及在哪里可以使用已修补处理过的软件。
  • 当我们知道了客户所报告的问题在软件的新版本中得到处理时，IBM Rational 要对客户进行追踪。

另外的目标包括：

  • 提供跨企业的过程一致性
  • 支持组件化工作
  • 提供一致、可靠的规格报告
  • 排除主控权问题，并减少复制时间（下面进行更多介绍）
  • 提高应用程序性能
  • 提供基于工件或活动的管理
  • 确定并利用基于角色的过程模型
  • 支持集成，或对其他系统的数据输入

通用工作流中的角色

通用工作流是基于角色的变更管理系统设计。开发通用工作流的一个关键步骤是定义一组基于角色的记录类型，而不是依靠更一般的（并统一的）记录类型。基于角色的记录类型让用户经历更流线型的 CM 过程。比起更广泛且更一般的记录类型，它们还表现出对变更管理系统的维护者更少的约束。其中一些好处包括与每个记录类型相关联的操作集更小，每个记录类型中的 ClearQuest hook 编码更少，并且由于刚刚提到的流线化所导致的更好的性能。在复制的环境中，一个更大的优势是排除了主控权问题，因为基于角色的记录类型将记录所有权和主控权与变更请求解决过程联系在一起，因此恰当的所有者和位置总是拥有主控权。

通用工作流依靠一些主要的、相关的记录类型来确保问题或变更请求的评估、分配、追踪、处理，及解决（利用确保完成可溯性和追踪的过程进行）。通用工作流的主要角色是：

  • 提交者（TSE、Dev/QE/Doc/Mgrs）
    提交者可以是任意一个人 —— 例如，任意的支持工程师（Support engineer，TSE）、开发人员（ Developer，Dev）、质量工程师（ Quality engineer，QE）、技术文档作者（Doc），或经理（manager，Mgr）。提交者可以：
    • 提交问题
    • 检查问题状态
  • 工程或项目经理（Eng/Proj Mgrs）
    这些角色能够筛选问题，并确定版本目标。例如：
    • 检查问题状态，并在适当时关闭
    • 查看开发人员的工作负载是否是均衡的
    • 运行报告（问题规格、发现/关闭、导入、版本状态，等等）
  • 评估者（Doc Assess/Dev/QE）
    这些角色要：
    • 找到分配给他们的问题
    • 处理并解决问题
  • 产品支持的经理
    这些角色要：
    • 运行报告（问题规格、发现、关闭、导入、版本状态）
    • 检查问题及版本状态

上面介绍的角色不仅在软件产品开发行业的通用工作流中具有意义，而且还可以应用到开发并维护软件的其他环境中具有意义，例如卫生保健或金融服务行业中的 IT 部门。尽管用户可能在任意已知时刻填充多个角色，通用工作流也能考虑到这些角色之间更明显的确定转换。例如，一个用户，正巧是开发人员，可以提交问题，然后为自己分配相关的活动，并解决。

在通用工作流过程中，变更可以表现为问题。变更请求可以是内部的，或者外部的，换句话说，可以根据客户请求、内部开发工作、测试结果，或管理层决策来提交变更请求。

通用工作流记录类型

图 3 例举出一种可行的整体通用工作流架构。该图显示了从问题开始的记录类型之间的父子关系，这代表所提交的变更请求。

图 3：通用工作流架构 —— 主要的记录类型

变更请求从问题开始。问题可以拥有与其相关的一个或多个任务，而每个任务可以拥有与其相关的一个或多个活动。问题描述了变更请求，并且由提交者所拥有，而任务和活动是追踪为了解决该问题所分配的且必须完成的工作的记录。此处有这些关系的速记：

  • 问题（Issue）—— 报告问题的记录。
  • 任务（Task）—— 将问题与目标版本相关联的记录。多个任务可以联系到一个且唯一一个问题上。（注意，在该场景中，任务与其他产品中定义的任务无关。）
  • 活动（Activity）—— 获取支持任务的活动的记录。多个活动可以联系到一个任务上。
  • 注释（Comment）—— 用于与记录所有者沟通的东西。注释与问题、任务，和活动相关联，并且用于问题、注释，及响应。

通用工作流过程

图 4 例举了一个可能的通用工作流过程。每个箭头代表记录之间的父子关系。

图 4：通用工作流过程

问题记录是该通用工作流过程中的起始点。提交者负责提交问题，按周期查看状态，并且响应所有的问题或注释。方案的用户特权设置决定谁（更确切地说，用户、团队，或角色）可能提交新的问题。问题：

  • 包含与发现问题的位置和方法相关的所有信息。
  • 受控于提交者站点。
  • 由提交者所有。
  • 可以添加注释（和问题）。
  • 包含指向所有与其相关的任务的指针。任务包括有关处理问题位置的信息。

问题提交过程流

图 5a 展示了可能的问题状态，突出了主过程流的简单性。图 5b 例举了工作流从打开状态的问题开始。当接受了解决方案时，记录就转到完成状态。提交者创建问题记录。然后记录位于打开状态。提交者可以撤销问题，或者审阅相关的任务状态。如果任务完成了，并且提交者赞成该决议，那么可以选择接受动作，将记录转到完成状态。

图 5a：问题状态

图 5b：提交问题的过程流

如果提交者不赞同该决议，那么选择拒绝动作，将记录转到拒绝状态。如果有新的信息可用，审阅者可以重新考虑问题的状态，然后，接受新的信息，选择接受动作将记录转到完成状态。类似地，提交者可以通过选择撤销动作，并将记录转到撤销状态来撤销问题。允许提交者从撤销、完成，或拒绝状态开始重新打开问题。

提交者审阅相关（子）任务的状态。如果提交者赞同所提供的解决方案（举例来说，完成状态的相关任务，及处理的解决代码），那么提交者会选择接受动作将记录转到完成状态。完成状态是最终的状态。

筛选问题

通用工作流的工程/项目经理角色筛选问题并确定版本目标的。该角色可能由工程、产品和项目经理、QE，或文档编制部门来代表。该角色的职责是评估问题，然后通过创建任务追踪决议来处理问题。一旦任务为激活的，那么就创建并分配活动来完成该任务。活动记录是任务记录的子记录，正如任务记录是问题的子记录一样。问题可以拥有一个或多个与之相关的任务。

任务

图 6 展示了可能的任务状态。

图 6：任务状态

在任务的主要流中，任务从打开状态开始。当工作完成时，任务记录转到激活状态。当决议接受时，记录转到完成状态。

任务记录的所有权可以随记录状态的变更而改变。举例来说，当任务处于打开状态时，默认的开发人员领导是任务的所有者，记录受控于开发人员领导的数据库镜像站点。当任务转到激活状态时，QE/测试人员领导成为任务所有者，并且任务受控于 QE 领导的站点。

任务记录：

包含所有关于处理问题位置的信息。
首先受控于开发人员领导的数据库镜像站点（打开状态），然后当任务处于激活状态时，受控于 QE 领导的站点。
考虑添加注释及问题。
包含指向所有相关激活和相关父问题的指针。
管理任务

开发人员领导（可能与工程/项目经理角色一样）处理任务的工作流。图 7 例举出工作流过程，其中创建，然后分配了要解决的任务的活动。

图 7：管理任务的过程流

激活动作自动地为开发部门（Development，Dev）、测试部门（Testing，QE），和文档编制部门（Documentation，Doc）创建独立的活动。

追踪并关闭任务包括：

  • 审阅任何相关的活动状态。对于完成状态的活动，工程工作完成了。
  • 设置完成动作，关闭任务（完成状态）。

QE 领导角色依照图 8 中所示的过程进行工作。

图 8：测试任务完成的过程流

活动

图 9 展示了活动主要流中的状态。

图 9：活动状态

提交的状态是质量工程师（QE）或 Doc 活动的起始点，在此首先进行评估。对于开发人员（Dev）角色来说，活动开始于打开状态。

当完成工作时，活动记录转到激活状态。当解决方案完成时，记录转到完成状态。

开发人员（Dev）、信息开发人员（Doc），及质量工程师（QE）都评估并处理活动。评估/Dev/Doc/QE 角色审阅分配给他们的活动记录，然后完成对活动的处理工作。三种类型的活动记录是：

  • Dev 活动。开发人员处理分配给他们的打开状态的活动。
  • Doc 评估活动。信息开发人员评估文档编制需求，并且审阅活动中的信息，看看是否需要文档编制。如果需要文档编制工作，那么他们创建开发活动来解决文档编制的影响。
  • QE 活动。质量工程师测试并考察开发（Dev）活动是否合格。QE 活动包括所有测试信息及结果。

可以向任意类型的活动中添加注释、问题，及响应。

为什么开发通用工作流？

使用通用工作流有许多好处 —— 对于 IBM Rational 软件开发组织及其他开发和 IT 组织来说。例如，管理人员可以确定并创建一组客户可以安装的全都支持的产品版本（或项目），例如：

  • 完整发布版本、修正包，及其他修正或特性。
  • 产品资源包（Bundles） 1 、提供品（offerings） 2 、集合（collections） 3 、部件（assemblies） 4 、通用组件（common components） 5 ，及共享的通用组件（ shared common components） 6 。

在 IBM Rational 的情况中，当客户联系支持部门，提出问题时，会要求客户运行特殊的公用程序来确认发生问题的机器上安装了什么软件。然后参照 RETAIN Call Center 记录 ID 可以创建通用工作流问题。

如果该问题的 RETAIN Call Center 记录生成，并且与 RATLC 问题关联了，那么可以为每个问题自动地生成通用工作流任务。一个任务可以包含关于以下内容的信息：

  • 要解决问题的产品版本或项目。
  • 确认的单个产品，其与共享组件的关系由 Baseline 记录所追踪。（Baseline 记录包含考虑到束或提供品及通用组件之间关系可溯性的字段。）

项目记录类型可以用于追踪实际产品版本的生产，以及向客户提供可以下载并安装新产品版本的 Web 站点的交付产品。项目可能包括产品名、版本信息，及一组与项目相关的所有迭代。例如，ClearQuest Web 开发项目可能涉及 Web 客户端用户界面的确定的组件及子组件。

通用工作流 Baseline 和 Build 记录可以通过 IBM Rational ClearCase/ClearQuest Unified Change Management (UCM) 集成与项目一起使用，并且可以不通过 IBM Rational ClearCase/ClearQuest Unified Change Management (UCM) 集成与项目一起使用。Baseline 和 Build 记录还可以用于确保项目或产品版本的成功交付，或者对客户的信息的成功交付。例如，Baseline 和 Build 记录可以让信息自动地从开发部分传递到 QE/测试部门，告诉 QE 什么产品包含对具体问题的处理。

将通用工作流与 UCM 模型一起使用对基于组件的开发提供了支持，并且增强了关于什么修正可用、要下载什么版本，以及更新在哪里可用的信息流。

在此场景中，当已经评估任务记录的活动充分地完成了，并且赞成任务对外公开时：

  • 可以将任务解决代码设置为处理过的。
  • 可以设置关闭代码，根据值的集合，RETAIN RATLC Bridge 会立即，或者当产品在项目记录中表示为已交付时，触发与问题相关的 APAR 成为关闭状态。

额外的增强可以让任意位置的用户察觉到产品版本中的补丁什么时候是可用的，不管在哪里处理的。要使之生效，可以将版本信息关联到产品版本或项目上，以便用户知道什么时候问题在随后的产品版本（也就是，找到问题之后的版本）中得到处理。此外，已知项目名称或 ID，用户可以看到更新版本是否可用，如果可用，可以在哪里安装。

通用工作流项目记录可以作为已知产品版本所有问题的容器或父记录。项目记录可能包括必要的字段，例如 Name、Unique ID、DefaultDev、DefaultDoc、DefaultQE、Program Manager、ProductManager，及 TriageAdmin。可选的字段可能包括：指示项目是否使用 ClearCase/ClearQuest UCM 集成来完成变更文件的交付的值，对其他通用工作流项目，或 UCM 项目的反向引用（例如 PriorProject 或 ProjectsRelated），以及可以为开发团队（例如，Component Team）而设置的字段。

ClearQuest MultiSite 环境中的通用工作流

除了帮助建立基于角色的变更管理系统，通用工作流还可以帮助处理分布式环境中的主控权和复制问题。例如，如果一个用户连接 Bangalore 中部署的镜像，当用户创建新任务时，任务受控于开发人员（Dev）所有者所在的位置。任务在 Bangalore 站点上创建，并且被复制。初始的任务主控权由默认的 Dev 所有者所决定，不管问题受控于哪里。

注意：

  • 问题要复制到所有位置以便显示。
  • 问题包含对相关任务的引用，并且任务包含对问题的引用。
  • 一旦任务是打开的，每个任务受控于默认的 Dev 所有者的站点。一旦任务是激活的，任务受控于 QE 领导的站点。
  • 一旦活动处于打开或提交状态，与任务相关的活动就受控于所有者的站点。所分配的开发人员是 Dev 活动的所有者。默认的 Dev 所有者可以由项目、组件或子组件字段的值决定。默认的 Doc 所有者是 Doc 评估活动的所有者，而默认的 QE 所有者是测试活动的所有者。

结束语

RATLC 方案及其在 IBM Rational 软件开发组织中的使用为分布式软件开发环境中的 ClearQuest 变更管理提供了理想的用例。该工作模型还例举出了开发用于在系统集成中处理客户请求的过程设计中的最佳实践中的思想指引。

以我们的许多客户让内部的团队开发并部署解决方案同样的方式，IBM Rational 开发组织让内部的部署团队设计并实现以及管理，对 RATLC 的方案变更，及其相关的用户数据库。IBM Rational Internal Deployment 团队请用户给出反馈，不论他们是什么角色，并且通过在 IBM Rational 中开发并部署通用工作流来试图提供思想、设计和实现指引。

如我们在第 1 部分中所提到的，当客户打电话或电邮支持中心时，过程就开始了。支持中心在 Call Center 应用程序中提交记录，RETAIN RATLC Bridge 触发 ClearQuest 系统中提交的新变更请求，以及来自于 RETAIN Call Center 记录中的相关信息。RETAIN RATLC Bridge 将两个追踪系统的各自变更请求之间的连接自动化。默认的 ClearQuest 所有者（可能是客户组）得到关于新变更请求提交的自动邮件通知。CR 由默认的所有者筛选，并分配出去。当解决 CR 时，解决方案的一部分是在 ClearQuest 的 Customer 和 APAR 选项卡上更新信息。任务完成状态触发 RETAIN RATLC Bridge 来更新 RETAIN APAR 的信息和状态。

本文中所说的通用工作流的概念可以视为是具有广泛，跨行业适应性的一般的变更管理模板及过程。它还可以看作是更针对行业的设计及实现环境，在该环境中一般化的通用工作流方案可以裁减为卫生保健、金融、银行或汽车业 CM 的解决方案，每种都有其自己相关的记录类型、确定的策略及治理，以及具体行业的用户角色。然而，ClearQuest 角色（第 1 部分中介绍的）在大范围变更管理环境中是足够的，因为不管具体的实现细节是什么，设计、实现，及管理对用户的 ClearQuest 系统通常会需要方案开发人员和管理人员用例。

IBM Rational ClearQuest 和 Rational 开发组织使用 ClearQuest 变更管理系统来增强它们开发的产品。对 RATLC 方案继续的增强，包括集成，例如 RETAIN RATLC Bridge，令共享不同存储库中数据的涉众与问题处理人员之间的连接更快更有效。我们不断的提高工作的重点是更快地响应客户对产品中变更的请求，不论该请求是一个问题，还是增强的请求。在这种情况下，通用工作流试图通过指导对变更追踪过程未来的增强，以及通过确保所有涉众随时知道问题的状态，不论时区和位置，提高变更请求解决的过程。

特别感谢 Robert W. Myers 和 Rational Internal Deployment 团队（Shirley Dango、 Chibuzo Obi、 Barb Purchia 和 Kathy Ludlow）为这篇文章提供了大量的技术信息。Robert 对 IBM Rational 开发组织的 CM 系统的 IBM Rational 内部部署的领导起了很重要的作用。

注释

1 产品资源包（bundle） 是绑定在一起的产品的集合（但不是通用组件）。

2 供应产品(offering) 是客户购买的产品。它可以是产品资源包、单个组件产品，或包含多个组件，和/或一个或多个通用组件的产品。

3 集合（collection） 是一组部件（assembly）和单个模块的集合。

4 部件（assembly） 是提供供应产品(offering)所需要使用的两个或多个组件的集合。

5 通用组件（common component） 包括不只一个供应产品(offering)使用的代码。它拥有对于其消耗的供应产品(offering) 的运行时接口，而非编译时接口，并且只对使用的供应产品(offering)中的客户有效（换句话说，分离时它不是有效的）。

6 共享通用组件（shared common component） 是一种通用组件，组件实例由运行在单个机器上的多个供应产品(offering) 或部件（assembly） 共享，与之相对的是，每个供应产品(offering)使用其自己的（冗余的）组件副本。

 

 

 

 

 

 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号