变更管理和ibm rational clearquest
在变更管理领域，使用软件工具并定义工具提供的自动化操作过程可以提供巨大的好处，从而可以帮助联系和协调开发组织内部不同的小组和团队，不管他们是在同一个写字楼，还是分布在世界各地。
比如，如果一个客户与一个产品支持代表谈话并提出一个需要请求变更的问题，那么这个变更管理解决方案不仅能使这个支持代表可以提交一个变更请求，还能够让这个开发组织中适当的涉众自动接受到这个提交的通知，这样使他们能够进行优先级划分并尽可能高效地响应这些问题，从而提出一个合适的解决方案。
ibm rational 在变更管理方面的需求
像许多其它全球性企业的开发小组一样，ibm rational开发组织也需要一个能够在分布式环境中工作的cm系统。这个系统必须不仅能为开发者服务，还要能够服务于质量工程师、管理人员、客户支持人员、信息开发者，以其他任何与缺陷或者增强需求(rfe)相关的变更请求(cr)有关的涉众。
ibm rational 利用 clearquest 来管理它自己的和 clearquest 产品本身相关的变更请求。我们的cm系统是著名的 ratlc，是由 ibm rational 内部部署小组开发的，它的名字来源于用户数据库的主方案。
有了这个系统，变更请求可以是来自各种涉众的。比如：
这些仅仅是 ibm rational 开发组织中的小组成员利用 clearquest 创建变更请求的众多方法中的一部分。每个变更请求随后都会经过评估、分配、处理、然后被解决、修正和关闭的过程
ratlc 的使命
ibm rational 开发组织的cm需求应该都属于 ratlc 的使命，ratlc 的使命是建立在两个组织的观点基础上的：
从组织的观点来看，ratlc 使命是(1)为所有的 ibm rational 开发建立一个完整的共同工作流程;(2)设计一个最适合使用 clearquest 技术的方案;(3)在发布之前提供产品的真实使用环境。
从操作的观点来看, ratlc 使命是(1)为所有的 ibm rational 提供一个24 x 7的cm(或者产品变更请求跟踪)系统;(2)在客户使用之前找出我们软件的问题;(3)利用他们所开发的工具为 clearquest 开发组织提供直接经验。
ratlc 方案包含了这两个方面。它配置为遍布全球的若干个数据库镜像，以便为开发小组和涉众提供一个分布式环境。方案的部署提供了一个关于 ibm rational clearquest 的开发组织是如何利用 clearquest 来管理变更从而取得更大成功的可靠的操作案例。
整合客户支持 -- retain ratlc bridge
象很多规模比较大的、分布式软件开发组织的案例一样，为了不复制在理论上储存在原本可以直接连接到变更管理系统的分离数据库中的数据，对我们来说就必需利用其它的应用软件来对 ibm rational 进行整合。
尤为特别地是，ibm rational 支持组织利用一个叫做retain(远程技术援助信息网络)的呼叫中心(呼叫中心)应用软件来进行记录和跟踪客户问题。技术支持人员和ibm客户都是用这个系统来查看和跟踪产品问题的。在这个系统中，每个具体的问题报告涉及一个特定的产品和发布版本，并有唯一问题管理记录(pmr)号的相关授权项目分析报告(authorized program analysis report (apar))。
pmr 和 apar 是存储在 与 clearquest 变更管理系统分离的存储库中的。因此，当时没有直接的方法来确保这些客户的请求或者问题能够在开发小组的 clearquest 系统中被记录并作为变更需求。最终的结果就是支持组和开发组之间的分离。
开发组和支持组都需要一个集成的系统，以使输入到 retain 的数据就会转移到 clearquest 的相应字段，反之亦然。比如，一在呼叫中心应用软件中创建了一个客户请求，而一个具有相同数据的 clearquest 变更请求应该会自动地从呼叫中心用户请求传递过来。此外，当 clearquest 变更请求被解决了，相应的呼叫中心信息就应该被自动更新。
名为 retain ratlc bridge 的集成系统可以满足这些需求。这个系统能够利用现有的变更请求跟踪系统使开发者和支持人员以及客户进行沟通。有了这种集成，支持人员和开发者之间的信息流就能自动形成并且是双向的。支持人员可以在呼叫中心应用软件中记录客户的请求，这个请求可以触发一个新的ratic变更请求的提交。类似地，开发者也可以解决一个apar关联的变更请求，这个apar可以直接在clearquest记录中更新呼叫中心信息。
作为集成的一部分，在ratlc方案中，一个变更请求包括一个客户信息表和一个apar信息表。一些填入到apar表中字段的信息将会被客户通过呼叫中心应用软件查看到。
图1描述了确保问题解决的角色，同时还显示了 retain ratlc bridge 自动操作的过程。
图 1: 自动化客户变更请求跟踪的流程
如图1所示：
一旦这个呼叫中心记录被解决，一个触发器就会通知这个客户什么时候可以得到他的问题的解决方案。有了这个集成，ibm rational 能够对客户的问题或者请求提供更快速、更高效的解决。同时 retain ratlc bridge 还能够改进组织的目标--更高效的客户解决过程，并使客户、支持人员和开发者之间有更紧密的沟通。
客户变更请求的解决
在这个部分中我将阐述 clearquest 开发组织是如何利用它自己的产品来解决客户变更请求的。
开发人员和涉众被列为小组的成员，这些小组成员按照特定的产品或组件被指定为变更请求的默认开发(dev)、测试(qe)，以及文件(doc)所有者。有了 clearquest 邮件通知，涉众能够接受到变更请求邮件，这些请求与他们相关，因此他们需要对这些变更请求进行评估。
有了retain ratlc bridge，一个新客户变更请求提交到这个 retain 呼叫中心应用软件，就会触发一个新的 clearquest 客户请求，并产生一个apar编号，从而涉众就会接受到对客户请求的自动邮件通知。这种自动操作缩短了客户、支持人员、开发人员以及管理人员之间的间隔，并且改善了通信实效。
下面就是这个场景：
一旦这个变更请求解决，retain ratlc bridge 就可以确保呼叫中心应用软件中的信息被更新，这样支持人员和客户都能够看到变更请求的状态。需要注意的是集成还能够进行相反的工作流程，也就是支持人员也可以提交一个 ratlc cr，然后自动产生 retain 呼叫中心记录(或者apar)。
要记住十分重要的一点是，一个变更请求可以由内部客户或者外部客户来提交，也就是说，这个变更请求来自创建这个产品的组织内部的客户，或者来自购买这个产品的客户。更进一步说，一个变更请求可以是一个缺陷或者一个改进请求(rfe),但是从工作流程的角度来看，无论哪一种情况都能够用相同的方法进行处理。
认识到客户和涉众可能分布在世界各地的情况也是很有好处的，这样 ibm rational clearquest multisite 解决方案还有一些潜在的利益，我将在下面部分更详细地讨论这一点。
|||
利用 clearquest multisite 支持一个分布式环境
由于 ibm rational 的客户众多，ibm rational 开发团队需要一个支持分布式环境的变更管理也是十分正常的事。ibm rational clearquest multisite 提供了一个解决方案。针对 ratlc 我们使用了这个方案，在这个方案中我们定义了数据库镜像(database replicas)和 主控权(mastership) 策略支持分布在世界各地的部署，支持以及测试组。
图2描述了 ibm rational 利用 clearquest multisite 进行的 ratlc 数据库镜像的内部开发。(数据库镜像的真实名称在这个图中已经被更改。)
图2.一个 clearquest multisite 部署的样例
这篇文章的目的不是要详细阐述如何安装和支持一个分布式 clearquest multisite 环境，我将谈论一些如何处理主控权(mastership)问题的基本思想以及乐观锁定(optimistic locking)。
clearquest multisite 主控权
clearquest multisite 主控权的功能就是确保一个 clearquest 记录只能够同一时间在一个数据库镜像站点更新。一个登陆到站点的用户如果没有记录的主控权，只能查看记录信息，而不能够对它进行修改。要想进行记录更新，用户必须登陆到拥有主控权的站点。
考虑这样一个场景，客户在伦敦，支持代表在班加罗尔，开发人员在罗利，测试人员在北京。如果这个变更请求的确认发生在北京，这也是一个数据库镜像的地点，这个记录所有者可能要从一个站点更换到另一个站点，比如这个记录的状况从活动变更到解决以及修正需要确认的情况。(注意：用户可以登陆到任何一个镜像中来读取信息，但是必须登陆到一个拥有主控权的镜像才能变更这个记录。)
乐观锁定
当两个人要更新同一个记录时，clearquest 就可以利用乐观锁定来处理这种情况。第一个保存记录更新的人——并不是第一个为了更新而打开记录的人——会成功。其它的变更就不会被保存。因此，第二个试图更新记录的人将需要重新得到这个记录并重新进行他或者她的更新。
我可以推荐一个减少这些麻烦的技术，因为 ibm rational 内部也使用它，就是利用一个叫作 record_script_alias 的 clearquest scripted action 类型创建一个记录。这个 action 在一个远程的或者同时正在进行更新的记录上执行。它可以创建一个新的记录并且在这个带有 action 记录 id 的新记录上更新一个新的字段。clearquest 然后创建一个从这个新的记录 id 到这个 action 记录的 反向引用(back-reference)，不管是否设置了主控权。这两个记录都是对方的相关扩展——直接在当前站点，接下来就镜像到其他站点。这个反向引用确保相连接的记录能够合适地更新。也就是说，当您创建一个记录并更新涉及的字段时，这个反向引用将会更新相关的记录，不管主控权还是乐观锁的争用。
这里还有一个更进一步的提示：当创建子记录作为创建父记录的副产品时，使用您创建的父记录的 commit event 来创建这个子记录。
所有权(ownership)的角色
由于镜像的局限性，对于 clearquest 来说不能实时地确定记录是否在更多的站点被创建或者变更。因此，如果记录在多个站点被创建并反向引用，对于用户来说是不可能在事前知道这些情况的。您可以通过分配所有权和确定最有可能执行 action 的人(或者唯一的人员)来进行限制。这样就缩减了与记录相关的冗余的过程，更有效地创建一个虚拟调度机制。
这个方法同时还简化了主控权和乐观锁争用问题的解决。就是说，您即可以象上面所描述的一样来创建一个记录然后用反向引用连接记录，也可以用所有者指派的隐含更新来构建记录。您不必同时使用两种方法。
基于角色的用户体验
为了设计、实现和管理变更管理系统，clearquest 产品支持基于角色的模型 。
为了我们的中心目的，同时也为了说明 clearquest 文档的目的，ibm rational 已经确定了三个常见(实际上非常普遍)角色。大多数其它您可能确定的角色都是这三个中的具体实例：用户、管理员，以及方案开发者。
用户角色覆盖了所有 clearquest 客户端可用的任务，这些任务用来在用户数据库中重新恢复、创建或者修改数据。普通用户任务包括从一个用户数据库中获取信息和对这些记录进行操作，提交变更请求、处理变更请求、修改记录中的信息，以及运行查询。用户可能是提交客户请求的支持代表，也可能是一个开发人员，质量工程师，信息开发人员，或者提交，分配，处理，解决，以及为一个产品特定发布版本进行变更请求确认的管理者。
管理员的角色用来对数据库、用户，小组进行管理，同时还包括安全策略的管理。一个管理员的常见任务包括配置和维护数据库、管理用户帐号，以及设置轻量级目录访问协议(ldap)的授权。
方案开发者的角色包括大多数 clearquest designer 中用建立方案的功能，这些方案将定义用户在 clearquest 程序用户界面工作的数据库。一个被执行的常见任务包含所有的方案设计以及开发，包括开发状态转变模型、记录、字段和动作类型，以及每个记录类型、字段和动作的行为，包括钩子(hook) 和脚本，同时还为 clearquest 客户端的用户开发窗体。
在许多变更管理的实现中，可能只有少数的方案开发人员和管理员，但是却有相当多客户端程序的用户——可能有几千的用户。在 ibm rational 内部开发小组中的确是这样的，然而只有少数方案开发人员和管理员对 ratlc 方案进行支持，并继续进行完善。事实上我们许多客户的开发团队也是这样的。
然而，这些角色之间的界限是模糊的。比如，同一个人经常会同时担任着管理员和方案开发者的双重角色。类似地，钩子的编写者或者窗体的设计者也可能是安全策略的设计者或者管理用户组和许可(也叫做用户权限)的管理员。在 ibm rational 也有这样的情况，可能有些用户有管理员权限可以创建查询并将它们保存到公共文件夹中，另外他们能够管理一些数据库，或者副本，或者用户和团队。
内部和外部的用户
在许多cm实现中，给定的角色可能要分配给内部和/或者外部的用户。对于各种不同的用户，像这样的角色从补充用例文档中受益是非常有可能的。
ibm rational 内部的一个用户，属于 ibm 软件小组或者 ibm 内部的任何人，这些人可能在产品开发部门工作，创建新的用户界面，对 clearquest 产品或者组件进行集成工作，或者依靠 clearquest 核心功能或者服务进行软件应用的工作。维护 ibm rational 的 ratlc 的开发人员他们本身就是 clearquest 方案 开发和管理人员角色文档的内部用户，作为其它地区的开发人员他们利用 ratlc 数据副本为 clearquest 的功能开发新的或者增强用户界面，或者进行测试产品的工作。对于 ibm rational 的现场代表也是这样的，他们支持一个客户变更管理解决方案并需要方案开发的信息，或者一个客户支持代表可能会在用户管理部门回答一个客户的问题或者争论。一个新的雇员需要通过用户角色文档学习如何使用 clearquest 并成为一个很好的内部用户。
外部用户包括拥有自己的方案开发人员、管理人员的客户，或者合作伙伴，或者能为客户创建解决方案的独立软件开发商(isv)。方案开发人员角色文档的目的是支持那些服务提供者或者技术专家，他们为客户开发方案，在有些情况下应用于一个内部小组，比如为他们的组织运行这个变更管理系统的内部全体it小组。在有些情况下，对于规模大且高度自定义的配置，客户会为他们的客户端应用程序的用户文档创建一个附加层，这个应用程序可以提供一些详细信息，即不但可以用通用方式使用 clearquest，还可以进行一些特殊的实现。比如，产品本身能够提供关于创建和运行查询的信息，但是作为一个客户可能会对工作时的特殊查询创建更详细的文档，这个查询适用于特别的记录类型、字段、状态，或者在他们特定方案中定义的行为。
使角色更加具体化
从 ibm rational clearquest 7.0.0 版本中开始，文档就是基于角色的，以便用来增加用户对每一个角色的体验。文档中定义的用户、管理员，以及方案开发人员的角色对于大多数行业--如果不是所有的--的cm系统是十分有用的。
但是cm系统中的这些通用角色是与行业无关的，在一个方案中定义的记录类型，及其状态和行为(状态转变模型)与安全的定义级别一样，都是高度自定义的，并可以用于多种行业和组织中——像角色本身一样。虽然用户的角色可能通用性的描述，但是它并没有详细地阐述具体的工作，比如数据输入人员、银行出纳员、贷款人员，或者客户支持代表。
例如，在 ibm rational 软件开发组织中，一个用户角色的定义包括所有世界各地 ratlc 数据库镜像的用户。用户包括开发人员、测试人员、技术专家、产品和项目经理、处理客户解决方案的现场代表，核查正在进行的变更并且根据客户需求提交变更请求的客户支持代表，有时还包括合作伙伴或者那些能够有限制地访问变更管理系统信息的用户。
一些 cm 系统不但可以从不同角色的“个性化”用例中获得利益，同样可以从 clearquest 方案中的更专业化的角色中获得利益。
新闻热点
疑难解答
