您知道何时使用 IBM Rational ClearQuest MultiSite 以及何时使用 ClearQuest Web 么？何时电子邮件规则是相关的，以及何时它们仅仅是更多的垃圾邮件？如何将分离的用户数据库集中为一个用户数据库？一位变更管理的专家将向您提供 ClearQuest 实施方面的建议。

IBM® Rational® ClearQuest® 为生产企业级的 Software Change Management (SCM) 提供了一个十分强大和用户定制的平台。但是您应该何时使用 ClearQuest MultiSite 和 ClearQuest Web 呢？何时电子邮件规则是相关的，以及何时它们仅仅是更多的垃圾邮件？如何将分开的用户数据库合并为一个用户数据库？

本文列举了我克服苦难并成功实施 ClearQuest 的十个技巧。

是 MultiSite 还是不用 Multisite？

随着 ClearQuest MultiSite 2002 版的引入，ClearQuest 的配置又增加了一个选项，那就是地理分布的定位。但是您如何决定到底是应该将时间和金钱等资源投入到潜在的复杂的 MultiSite 实施呢，还是只是简单的使用 ClearQuest Web 接口？

答案是由多方面因素决定的，包括地理分布的团队使用本地配置的客户端的需要（用于 Windows 的 ClearQuest 和 ClearQuest Eclipse Rich Client Platform (RCP)），以及机构在不同地点之间所能提供的带宽。通常来说，如果地理分布的团队中的用户需要使用本地配置的客户端的话，您就需要 MultiSite。如果您仅仅是需要向地理分布的用户提供访问 ClearQuest 从而实施那些不需要本地客户端的操作的话，那么您就不需要 ClearQuest Web 了。无论如何，ClearQuest 和 IBM Rational ClearCase® 之间的结合，将使通过 ClearQuest Web 来利用新的 ClearQuest Test Management 性能变得更加困难。参见图 1。

随着 ClearQuest 和 ClearCase 7.0.1 的发布，需要 ClearQuest MultiSite 来推动集成的 Unified Change Management (UCM) 环境的强制情形应该被重新考查。ClearCase Remote Client (CCRC) 和 ClearQuest Web 之间紧密的集成允许用户在一个 “Web 为中心的” 环境下进行操作，利用 Rational Web Platform （ClearCase Web 和 ClearQuest Web）。然而，CCRC 内动态视图的缺乏将成为大多数机构的一个破坏者，唯一的解决方法就是允许 ClearCase 和 ClearQuest MultiSite 达到团队所需要的特性集。

ClearQuest Test Manager 对于不在现场的测试人员来说，会使 ClearQuest Multisite 的配置变得复杂

在 7.0 版本中引入的 ClearQuest Test Management (CQTM) 包也可能成为决定配置 MultiSite 的一个因素。如果一个机构有远程位置使用 CQTM 来维护 IBM Rational ManualTester、IBM Rational FunctionalTester、或者 IBM Rational PerformanceTester 所进行的测试方案、测试用例、以及测试结果记录的话，MultiSite 将是唯一合理的解决方案。将测试工具和 Eclipse ClearQuest Perspective 结合起来以及记录测试结果的能力，对于测试人员来说是一项必不可少的要求。ClearQuest Web 为执行测试计划功能和生成报告提供了足够的支持；然而，对于一个严谨的测试环境来说，ClearQuest Web 将不能提供所需要的全部功能。

每一个 ClearQuest 都有其位置（并且每一个 ClearQuest Client 也都有其位置）

ClearQuest 7.0.1 为结合应用程序提供了四种不同的用户选项：用于 Windows 的 ClearQuest、ClearQuest Web、ClearQuest Eclipse Plug-In、和 ClearQuest Eclipse RCP。您必须考虑清楚哪一种客户端应该被用于哪一种功能。表1列出了 ClearQuest 的不同的“风味”，并展示了它们都提供了哪些功能。

在创建您的软件发行方案时，记得回顾不同的 ClearQuest 客户端的性能以及您所在的机构是如何配置的。如果您在一个独立的、无需结合的环境中的使用 ClearQuest，那么您可以将 ClearQuest Web 配置为主要客户端。然而，即使在一个“以 Web 为中心的环境”中，还是有一部分用户将要求用于 Windows 的 ClearQuest 客户端同 Crystal Reports 一起生成报告格式，这是标准化改变管理系统所带给机构的价值的一部分。

在一个更具结合性的设置中，您将需要将您的环境划分为“类”，从而决定哪一些客户端配置到用户系统中。“开发者类”将需要 Eclipse 的插入来同它们的 Eclipse Integrated Development Environment (IDE) 环境进行整合。“分析师类”可能需要用于 Windows 的 ClearQuest 客户端允许 同它们的 用于 Windows 的 RequisitePro 客户端进行整合，以及提供追溯 ClearQuest 中保存的需求和变更需求（许多情况下）的能力。

使用开发者论坛

不要重复发明轮胎。对于一位新的 ClearQuest 管理员来说，Rational ClearQuest 论坛是最值得访问的站点，它的网址是：IBM developerWorks。该论坛提供了寻找用户贡献的 hook 例子的去处，并且可以寻找您在配置过程中所遇到的问题的答案。

除了讨论，在 ClearQuest hooks index 里还有许多 hook 执行的例子。如果您试图添加一个 Choicelist、添加 auditing functions、或者使用 ClearQuest 来加强特定域的约束或者验证，那么这里有许多例子可以帮助您完成您的个性化定制。

在 ClearQuest hooks index 中浓缩了数百小时的开发时间。应用别人的经验来加强您的执行将是一个不错的选择。

给予用户创建报告格式的权限

ClearQuest 和 Crystal Reports 之间的关系有时将会使该工具的初始配置变得混淆，对于新人来说尤其如此。最简单的解释就是，在其当前形式下，每一个客户端的所有用户都能够运行报告。该报告是报告格式和定义需求的结合体。然而，问题在于细节，并不是每一个客户端都能够制作 Report Formats。

只有用于 Windows 的 ClearQuest 客户端，并且在其系统中加载了 Crystal Reports 的支持版本，才能够创建出生成报告所需要的 Report Formats。由于 Crystal Reports 是一个单独的应用程序（需要额外的许可证费用和额外的产品安装），所以经常有人向管理员出售 Crystal Reports 许可证，并且为 Report Formats 建立一个“票据交换所”。

这种事情您应该避免。只需不到 600 美元，您就能购买到 Crystal Reports 的一个副本。对于机构来说，一个更有利的情景就是“培训和培训者”模型。ClearQuest 管理员培训不同项目团队中的核心成员，这些成员购买 Crystal Reports 并且在其系统上装载了 ClearQuest Windows 客户端。这样一来，ClearQuest 管理员将有能力使得团队使用任何满足其需要的方式，利用储存在 ClearQuest 中的数据来生成报告。

永远不要与低级别的用户群联合行动

这或许听起来像是一个技术之外、无关痛痒的话题然而，这正是许多新的 ClearQuest 设计者经常掉进的一个陷阱。

当使用 ClearQuest Designer 的时候，选择一个操作，经验欠缺的开发者往往会添加一个用户群到操作中。假定该操作是 Approve。您或许创建了一个名为 Java_Project_Approvers 的用户组，并向其中添加了三位管理者。然后您将那个 Java_Project_Approvers 用户组连接到 Group Permission，在图表中核查，并且更新数据库。

一周以后，C# 项目发送了一封电子邮件，要求他们的管理团队获得 Approve 操作同样地约束。于是您必须重复所有的步骤；即连接 C#_Project_Approvers 用户组到 Group Permission，在图表中核查，并且更新数据库。

更好的方法是创建一个名为 Approvers 的“顶级”用户组。。然后，根据需要添加单独的、特定项目的用户群，作为与该操作相关联的子用户群。

在我们的例子中，我们创建一个名为 Approvers 的“顶级”用户群，它有两个子群，分别叫做 Java_Project_Approvers 和 C#_Project_Approvers。然后，当 C++ 用户群在第二周时再次申请时，您就能够不用再进行在图表中核查、添加用户群和更新图表的工作了。Group Permissions 的管理现在仅仅是一个用户和用户群的管理功能了。

通过连接被称作 Approvers 的高级别用户群的约束，向约束中添加额外的用户或者用户群仅仅需要您在用户管理工具中修改 Approvers 用户群的成员，而不是修改图表和更新数据库（请见图2）。这一过程帮助我们避免了频繁地更新图表和数据库所产生的大量的推理。

图 2: 通过同高级别的群体联合行动，您能够将“团队特定的”子群体添加到行动中，而且不需要对计划做出改变

交流和沟通的规则是发送电子邮件而非制造垃圾邮件

由于 ClearQuest 的强大功能和简单易用，经验并不丰富的设计者频繁的试图过度改造 ClearQuest 的电子邮件规则功能性。我曾经遇到过一个超过 100 条电子邮件规则记录的配置，其中 90% 都是基于查询的。这样做不仅产生了大量的电子邮件，而且会动态的影响任何操作的执行。

由于基于查询的电子邮件规则都是基于主要的 Defect 记录的，每一次进行操作，这 90 多条规则就将决定该查询条件是否曾经被满足过。无疑，客户端将会非常疑惑为什么在点击 Apply 按钮后需要等待这么长时间才能得到 ClearQuest 的回应，完成修改记录的操作。

对于新近配置 ClearQuest 的机构，我的建议是制定在 ClearQuest 以及 State 和 Action 工作流中将要跟踪的角色，并且决定在过程中需要布告的重要阶段何时发生。经验欠缺的 ClearQuest 用户试图在每一次状态变更时发送提交布告。Submitter 域在提交时期被填满，将 Submitter 参考域添加到 CC 中非常简单：让电子邮件规则排队。

然而，容易完成并不意味着就应该完成。想一想个体所提交的缺陷将收到多少非 ClearQuest 的电子邮件规则。使用一个基本的 Defect 工作流，他们就有可能收到 6 至 7 封基于状态变更的电子邮件。将您自己置身于提交者的位置，您应该能够就能够快速的将布告降至两至三个动作。

对于提交者来说，最明显的布告就是提交动作。这将影响到检验他们的缺陷已经进入到系统中，为他们提供一个系统为该缺陷指派的 ID，并让他们有机会回顾一下他们所提交的细节，开发团队将会使用它来分析该缺陷。一旦缺陷被提交，您可以选择再一次通知提交者（仅仅是提交者）通过或者终止该缺陷。这样的话，当该缺陷被成功解决之后，提交者将被告知他们的请求正在被处理（或者被拒绝，或者标记为副本，等等）。

基于这些“里程碑”状态变更的电子邮件通知将为提交者提供价值。持续不变的电子邮件通知，比如缺陷被开发人员指派或者打开、或者记录被升级，将会被提交者当作“背景噪声”，甚至是垃圾邮件。

应当仔细的思考和计划，从而确保在整个 Defect 周期中所有收到通知的活动者都能通过电子邮件收到相关的细节的同时，最小限度的向那些已经被淹没在要求他们详审的电子邮件中的用户发送通知。

基于 hook 的电子邮件规则的危害

新的甚至是有一定经验的 ClearQuest 设计人员可能被 API Guide 中所略述的，利用一个操作的通知特性直接在 ClearQuest 的图表内部执行电子邮件通知这一功能所困惑。

经常有人尝试使用内部的基于 hook 的电子邮件规则，并且绕过电子邮件包和相应的电子邮件规则所提供的“即时可用”的通知功能。这是典型的“三思而后行”，因为执行基于 hook 的电子邮件规则反映了您的 ClearQuest 实施的复杂性中的重要跳跃。

有一种情况是，与我一起工作的客户端想要一封电子邮件，其内容是定制的，而不是“即时可用”的包可以完成的。由于用户要提交变更要求，所以他们想要发送给用户一封措辞更好的电子邮件。比如 “亲爱的 <提交者姓名>, 您的请求号 <ID 号码> 已经被收到。您的请求将被好好处理。如果需要额外信息的话，会有一名团队成员与您取得联系。谢谢您使用 Acme ClearQuest Change Management 系统”。

在这个例子中，对于那些“即时可用”的通知所提供的被称之为 “秘密的” 格式没有其他选择，基于 hook 的规则被使用。

然而，这个例子是该规则的一个例外。在大多数情况下，基于 hook 的电子邮件规则同基于电子邮件规则包的规则的目的是一样的。基于 hook 的规则的灵活性（以及更新规则所要求的烦人的图表变更）应当同前面所提的“即时可用”的电子邮件规则包的易用性相比较。（请见图3）

图 3: 基于 hook 的电子邮件能够通过功能强大的 ClearQuest API 被定制。

现在比较一下，哪一个能够不费力的将域添加到一个无状态的电子邮件规则记录中。简单的方法允许您将一个电子邮件规则记录设置为活动的或者非活动的。每一种对于基于 hook 的规则的简单变更都将需要描述图表和更新用户数据库。如果您从另外一个设计者那里 “继承了” 图表，并且对您的前任所编写的 hook 并不熟悉的话，您就会增加一个额外的复杂级别。

在用户数据库之间移动数据（不，不仅仅是您）

这几年来，我经常遇到这样的情况：一些 IBM Rational FAQ 引发新手犯错误。经验欠缺的 ClearQuest Administrators 将会在以下两种情景下开始配置 ClearQuest：

1. “我们对于每一个项目都将从用户数据库起步。如果管理层决定将这些数据库同一个企业级用户数据库（基于报告或者数据管理方面的原因）结合起来将会有价值的话，那么我们就会将它们结合起来。”

或者

2. “我们对于所有项目都将从同一个用户数据库起步。如果该项目要求特定的定制，或者该数据库变得太笨拙了，那么我们就创建一个为项目定做的用户数据库，并且从用户数据库中引入相应的数据。”

这两种理由充分的选项都是基于同一件事：在不同的 ClearQuest 用户数据库之间可以轻易的移动数据。如果了解到该过程有时会提出挑战的话，您就会为您的机构设定一个更加合理的预期。

使用所提供的 ClearQuest Import 和 Export 功能，您就肯定可以从一个用户数据库导出数据（即使是基于一个查询），并且将其导入到另一个用户数据库中（即使这些用户数据库是基于不同的图表的）。只要在源和目的数据库中都支持您所要求的源和目的域，该导入工具就将支持它。

然而，和许多情形中所出现的情况一样，细节最令人头疼。如果您拥有一个多行的域——例如 Description （请见图4）——多行字符串中的每一个回车符都扮演了一个记录分隔符的角色，这就意味着源数据库中所呈现的域的格式最终和目的数据库中的不一样。

图 4: 使用导入向导可以很容易的完成映射。允许数据被导入所要求的格式需要计划和测试。

请记住，由于记录 ID 是系统创建的域，所以无法在用户数据库之间移植 ID。为了缓解这一矛盾，您可以创建一个新的域，例如可将其称作 old_id，并且从源用户数据库中将原来的 ID 导入到目的数据库中，同时将所有相关的信息也一并导入。参考信息域同样需要在不同数据库之间加以区别。如果我的登录 ID 在源数据库中是 giliod 而在目的数据库中是 dg1111，那么诸如拥有者和提交者之类的参考信息域就将变得没有意义了。

在不同的用户数据库之间移植数据当然是可以做到的，但是做起来会很痛苦。最好事先与出资方就数据的限制和变更问题进行沟通（您的 Notes_Log 域此刻看起来毫无用处），并且执行若干数据导入的试验来确保您拥有所有获得一个可以接受的结果的格式变更的文档。

避免掉入陷阱：工具只反应过程，但并不驱动它

IBM Rational Unified Process® (RUP®) 声称，“Tool Specialist” 的角色就是负责在项目中支持工具，包括选择和获得工具；配置和设置工具；以及检验工具的工作。实际上，ClearQuest 管理员就是在变更管理系统中扮演了 Tool Specialist 的角色。

在大多数情况下，服务于一个复杂的变更管理系统的企业级配置的机构，最希望拥有设计和贡献该进程的利益相关者，该过程应当在工具中被反映出来。无论是不是一个正式的过程团队，Project Management Office 或者 Quality Assurance 部门，都经常有各种将同变更管理系统发生交互的用户。

您应当避免尝试设计或者重新设计您的变更管理过程；相反，您应当用该工具执行您预先定义的过程。我所见过的最好的方法，就是您按照配置其他业务应用程序的方式来配置 ClearQuest。对该应用程序的需求将从业务利益相关者流到执行操作的开发团队。

我在若干场合所采用的一种有趣的方式是，实际利用 IBM Rational Suite 来配置 IBM 工具。在 RequisitePro 中将您的缺陷和增强要求集中起来。使用一个基于企业级图表的用户数据库来创建 Enhancement Requests，并且对系统的缺陷加以记录。这样的话，您就成为过程机构中的一员，并且任何使其进入 ClearQuest 的需求都被记录在 RequisitePro 中。

即使在一个不太正式的环境中，一个包含业务利益相关者的需求的 Excel 电子数据表也能够满足我们的要求。它提供了两个好处：一方面提供了您作为 ClearQuest 管理员所期望的清晰的方向，另一方面当“为什么当您转移到 Approved 状态时需要 Owner 域？”这一不可回避的问题提出时，它提供了到接合需求的回溯。通过记录完整的需求，您能够提供答案：“这是由 SOX 依从团队指定的需求，对于他们的报告来说需要这些数据。”

隔离 ClearQuest 计划开发

我的十项提示的最后一项是：伴随频繁的图表变更而来的继承的问题。一位新手 ClearQuest 管理员也许在更新一个用户数据库到新的图表版本时（请见图5），不会理会弹出的提示窗口。该窗口中显示：“该操作不能被撤销。请确认您已经备份了图表仓库和用户数据库。是否继续？”

图 5: 请回答“是”，因为如果您没有准备好的话，那么您的 ClearQuest 的实施将面临潜在的灾难。

经验丰富的 ClearQuest 管理员每当网络在用户数据库升级期间出现“小故障”时都会被召回数次，也许是因为丢失了设计者客户端和数据库服务器之间的连接，或者是因为在升级期间他们的 Windows 系统出现“蓝屏”。他们还会被迫寻找一名数据库管理员，要求他将图表和用户数据库恢复到其升级之前的状态。

一种可行的解决方案是使用 ClearQuest Designer 所提供的 Test Database 功能。然而，这可能像是一位拉紧绳索的行人在没有网的情况下工作。如果出现任何问题，您就像是步履蹒跚的高高走在没有安全网保护的中心环之上，因为该方法掩盖了一个关键的概念。如果您将您的当前生产图表同一个测试数据库连接起来，对图表进行变更并且将其应用到测试数据库中，您就将在其被用于生产环境的同时编辑您的生产图表。

这同当赛车绕圈行驶在赛道上时变换其轮胎的情景十分相似。当更新一个数据库时，您将收到如图5所示的警告消息。您可能会问：如果在升级时出现图表“不一致状态”的问题会怎么样？我的生产用户数据库没有问题，它仅仅影响我的测试数据库，不是么？最好的答案就是：永远不会。由于图表和用户数据库之间的复杂关系，图表的变坏——无论您在升级（测试与否）哪一个用户数据库——都可能要求图表的恢复，这又将要求所有相连接的数据库（包括生产数据）的恢复来保持一致性。

除了修改生产图表所带来的问题之外，如果您的图表利用了动态列表或者无状态列表，那么您也许还要花费大量的时间用于在生产服务器上重新下载数据到一个新创建的空的测试数据库。如果您的图表异常复杂的话，您将到达一个更高层的上限，而且 Microsoft Access 将不再是一个快速创建测试数据库的选项。

一种行之有效的方法是，利用 ClearQuest 所提供的命令行指令 “installutil” 来创建您将会修订的图表和用户数据库的备份。软件开发人员通常将他们的开发努力隔离在不同的物理系统或者实例（开发、系统测试、用户容忍测试）上，同样地，该方法允许您在隔离状态下开发您的 ClearQuest 图表变更。

一旦图表变更被验证，您就能够使用 “cqload” 命令导出图表的修订版本，并且执行一个受控的导入到生产中。这样，您就能够以环境中其他任何生产系统相同的控制级别来计划升级操作。您可以联系您的数据库管理员，要求一个备份，通告您的用户中断操作的消息，并且生产发布提示那些可能会受到影响的终端用户关于变更的详细信息。

通过使用该方法来更新 ClearQuest 图表（以及相关联的用户数据库），当您采取这一措施来更新数据库并且收到令人不安的警告消息的时候，请不必担心，您将拥有一套十五分钟前的安全备份，而且在一些无法预料的事件扰乱升级操作时，您只需请求 Database Administrator 来恢复图表和用户数据库的备份即可。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章

讨论

• 参与论坛讨论。
• 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击这里开始。
• 全球 Rational 用户组社区