Um modelo de estado efetivo deve endereçar estas questões na fase de design.
Você deve se certificar de que não existam estados no modelo para o qual um pedido de alteração possa ser transicionado e, em seguida, omitido. Por exemplo, se o modelo possuir um estado Adiado, e ninguém está designado para processar registros neste estado, alguns pedidos de alterações podem nunca serem observados ou corrigidos.
As causas deste problema podem ser sutis. Três engenheiros podem ser designados para manipular os pedidos de alterações em um estado Aberto, em que o valor no campo do componente seja vermelho, verde e azul, respectivamente. Os pedidos de alterações cujo o valor do campo do componente é amarelo ou branco podem nunca serem observados.
Você deve considerar os intercâmbios entre o modelo que possui poucos estados com mais atividades de desenvolvimento para cada um e um modelo que possui muitos estados com poucas atividades de desenvolvimento. Por exemplo, se ocorrer uma atividade de verificação em diversos pontos no ciclo de vida de um pedido de alteração, você pode desejar ter um estado de verificação em vez de incorporar atividades de verificação nos outros estados. O agrupamento destas atividades em um estado torna mais fácil garantir que a verificação seja manipulada adequadamente. Mas a criação de muitos estados torna o modelo mais difícil de controlar e manter.
A ação Duplicar fornece um meio para marcar um registro em um conjunto de registros duplicados como o registro ativo e marcar os outros como duplicatas; registros marcados como duplicatas não podem ser modificados. Esta ação garante que todo o trabalho neste pedido de alteração seja rastreado por um registro. Esta ação utiliza campos integrados; ela pode ser incluída em um esquema incluindo os controles Duplicar Dependente e Duplicar Base em um formulário e com a criação de ações Duplicar e Desfazer Duplicação. A ação Desfazer Duplicação retorna o registro ao seu estado antes dele ter sido marcado como uma duplicata.
Estão disponíveis vários esquemas predefinidos que incorporam determinados recursos ou configurações. Você pode utilizá-los como um ponto de partida para o desenvolvimento de um esquema, mas você deve comparar cuidadosamente os recursos do esquema predefinido com seu requisitos.
Alguns pontos-chave a serem considerados sobre esses esquemas predefinidos:
Pode ser desafiante projetar um esquema para suportar o desenvolvimento paralelo de vários produtos (ou variantes de produtos) que compartilham artefatos comuns. O design deve antecipar e acomodar situações como capturar e manipular informações quando um defeito reportado é rastreado para artefatos compartilhados que requerem correções para vários produtos e como rastrear o estado atual do defeito quando várias construções (em planejamentos potencialmente diferentes) são requeridas.
Utilizar um único registro para rastrear estes diferentes esforços não é uma abordagem efetiva.
Uma abordagem alternativa é enviar vários registros para cada produto afetado, o que permite que o status de cada atividade seja rastreado de forma independente. Se você utilizar o mecanismo Salvar Valores Padrão no primeiro registro inserido e utilizar Load em registros subseqüentes, você poderá evitar a duplicação da entrada de dados em cada cópia. (Este recurso não está disponível para o Rational ClearQuest Web Client.) A desvantagem é que cada registro fica isolado dos outros; esforço pode ser desperdiçado se o trabalho em outras questões relacionadas não for coordenado.
Uma abordagem mais efetiva é utilizar uma estrutura hierárquica, na qual o registro pai caracteriza o problema e os registros filho são utilizados para rastrear o problema para cada produto, variante ou versão. O registro pai pode ser de um tipo diferente dos registros filho, ou ele pode ser o mesmo. Alguns esquemas utilizam o mesmo tipo de registro para os registros pai e filho para que todas as informações possam estar contidas no filho (o que reduz a navegação entre pai e filho). Outros esquemas utilizam um tipo de registro filho simples para implementar um tipo de lembrete para administrar o mesmo problema para os produtos, variantes ou versões afetados e rastrear seus status.