您必须确保模型中不存在变更请求可过渡到并随后被忽略的状态。例如,如果模型具有“已延期”状态,而且没有分配任何人来处理处于这种状态的记录,那么某些变更请求可能从来都不会有人注意或处理。
造成这个问题的原因比较难以捉摸。可能会分配三个工程师来处理处于“已打开”状态的变更请求,这些变更请求的组件字段的值分别为红色、绿色和蓝色。 可能从来不会有人注意到组件字段值为黄色或空白的变更请求。
您必须在具有较少的状态而针对每种状态具有较多的活动的模型和具有较多状态而每种状态具有较少开发活动的模型间做出权衡。例如,如果验证活动在变更请求生命周期的多个时间点发生,您可能希望具有一种验证状态,而不是将验证活动合并到其他状态中。将这些活动分组到一种状态可以更方便地确保验证得到正确处理。但是,创建许多状态会使模型难以控制,并且更难以维护。
“重复”操作提供了一种方法,用于在一组重复的记录中,将一条记录标记为活动记录,将其他记录标记为重复项;不能修改标记为重复项的记录。该操作确保针对该变更请求的所有工作都可由一条记录进行跟踪。该操作使用内置的字段;可通过将“重复从属项”和“重复基本项”控件添加到表单以及创建“重复”和“消除重复”操作,将该操作添加到模式。在将记录标记为重复前,“消除重复”操作会恢复该记录的状态。
我们提供了已合并特定功能或配置的多种预定义模式。您可以将它们作为开发模式的起点,但是必须将预定义模式的功能和自己的需求进行仔细比较。要了解有关预定义模式的更多信息,请参阅 Rational ClearQuest 预定义模式。
设计模式以支持多个共享通用工件的产品(或产品变体)的并行开发是一项颇具挑战的任务。设计必须预见到并满足一些情况,比如,针对共享工件跟踪已报告的缺陷(需要针对多个产品进行修正)时如何捕获并处理信息,如何在需要多个构建(可能按不同的计划实施)时跟踪缺陷的当前状态。
使用单一记录来跟踪这些不同的操作不是一种有效的方法。
另一种方法是针对每个受影响的产品提交多条记录,这样就能单独跟踪每项活动的状态。如果您针对输入的第一条记录使用“保存缺省值”机制,并对随后的记录使用“装入”机制,那么就能避免每个副本中存在重复的数据项。(该功能对于 Rational ClearQuest Web 客户机不可用。) 这种方法的缺点是每条记录都与其他记录隔离;如果没有协调好针对其他相关问题的工作,那么可能会浪费很多精力。
一种更有效的方法是采用分层结构,父记录用于确定问题的特征,而子记录用于针对每个产品、变体或版本跟踪这些问题。父记录和子记录可以是不同的类型,也可以是相同的类型。某些模式针对父记录和子记录采用相同的记录类型,因此所有信息都可以包含在子记录中(从而减少了父记录与子记录之间的导航操作)。其他模式使用一种简单的子记录类型,用于实施一种提示,以便为其他受影响的产品、变体或版本解决相同的问题并跟踪它们的状态。要了解有关采用分层结构的模式的更多信息,请参阅针对使用 Rational ClearQuest ALM模式的文档。