ClearQuest如何进行定制开发1

前言

    ClearQuest是业界优秀的变更管理工具，为很多软件开发团队的管理提供服务。IBM Rational为ClearQuest提供了很多开箱即用的模式，使开发团队能很快的上手，使用ClearQuest。但目前越来越多的软件企业希望定制满足企业需要的流程（如为了过CMMI的需要），通过ClearQuest提供的定制开发功能可以满足这类软件企业的需要。本文通过一个具体的实例来帮助读者了解如何进行定制，以期帮助从事相关工作的人员能更好的掌握这门工具。


对流程定制开发的准备 

    在这里笔者使用了一个大家都熟悉的缺陷流程的例子（图1），虽然ClearQuest提供此开箱即用的模式，但现在我们可以考虑自己定制此过程，通过此过程加深对ClearQuest定制开发的理解。在考虑定制时，我们需要注意以下几点：

图1

对流程的考虑 

    对流程的考虑主要来自于两个方面，一是状态，一是动作或操作。流程中某个阶段性的结果，我们以状态来表示，通过动作将一系列的状态连接起来构成流程，可参考图1。
我们可通过场景来验证所定制的状态是否合适，针对不合适的状态可做适当的调整，保证定制的流程符合实际的需要，本例的场景如下： 

    1、 已提交状态：缺陷的创建，测试人员在测试中发现Bug提交缺陷，填写缺陷记录单，完成后提交缺陷，该缺陷记录进入系统并标识此时的缺陷状态为已提交。 

    2、 已分配状态：项目经理针对提交上来的缺陷进行评估，确定责任人负责修改此缺陷，并进行人员分配，此时的缺陷状态为已分配。 

    3、 已打开状态：缺陷处理人（通常是开发人员）接到分配给自己的缺陷修改任务，对缺陷记录进行初步分析评估，开始进行缺陷的处理，此时的缺陷状态为已打开。已打开状态的来源分为三种情况： 

    -来自已分配状态，表示当前是项目经理新分配的任务。 

    -来自已解决状态，表示修改的缺陷被测试人员验证时没有通过，需要重新修改。 

    -来自于已关闭状态，表示缺陷没有修改完全，需要继续修改。 

    4、 已解决状态：当缺陷处理人（通常是开发人员）已修改当前的缺陷，并在自测通过后，希望测试人员进行验证，此时的缺陷状态为已解决。 

    5、 已关闭状态：测试人员对于缺陷处理人已修改的结果进行确认，验证通过后，将缺陷状态变为已关闭，表示此缺陷已处理完。 

    6、 已推迟状态：此状态可以来自于多个源状态，表明在当前阶段无法解决此缺陷，需要在后续某个阶段再对此缺陷进行修改。 

    7、 已重复阶段：表示当前提交的缺陷和以前某个缺陷相类似，可参考先前缺陷的处理结果。 



    和状态相对应的动作描述，如表1：

对使用流程人员的考虑 

    流程是需要不同的人员协同工作才能完成的，所以在流程中需要确定角色，哪些角色执行流程中要求的哪些动作。在本例中，我们考虑如下的角色划分。 


    角色描述：
测试人员：发现缺陷，提交缺陷记录，验证缺陷的处理结果，关闭缺陷。
项目经理：分析处理提交的缺陷，把该缺陷分配给相应的开发人员进行处理。
开发人员：接受项目经理所分配的缺陷修改任务，对缺陷进行修改，并将修改的结果提交缺陷提交人进行验证。 


    将角色和动作、状态相结合形成表2 

对流程所提交信息的考虑 

    一般在手工流程的传递的过程中，我们习惯于打印出一系列的表格，当表格流转到不同人的手中时，填写表格中相应的项并签字，实际上这些就是我们在流程中所提交的信息。在考虑所提交的信息时，一方面我们要考虑一些通用的信息，如标题、描述等，另一方面我们要考虑和流程相关的一些属性信息，如本例的优先级、严重性等，供日后统计分析时使用。在本例中，我们考虑如下要提交的信息，见表3。