Un modello di stato efficace deve prendere in considerazione queste problematiche nella fase di progettazione.
È necessario verificare che nel modello non vi siano stati a cui sia possibile trasferire una richiesta di modifica che successivamente viene ignorata. Ad esempio, se il modello dispone di uno stato Postponed e l'elaborazione dei record in questo stato non è stata assegnata a nessuno, è possibile che alcune richiese di modifica non vengano mai rilevate o risolte.
Le cause di questo problema possono non essere immediatamente evidenti. È possibile che tre sviluppatori siano stati incaricati di gestire le richieste in uno stato Open, dove il valore del campo del componente è rispettivamente in rosso, verde e blu. Le richieste di modifiche il cui valore del campo del componente è giallo o vuoto potrebbero non essere mai rilevate.
È necessario considerare il bilanciamento tra un modello che ha meno stati con più attività di sviluppo per ciascuno di essi e un modello che ha molti stati con meno attività di sviluppo. Ad esempio, se un'attività di verifica viene eseguita su diversi punti durante una richiesta di modifica, è possibile avere uno stato di verifica singolo invece di includere attività di verifica in altri stati. Il raggruppamento di queste attività rende più semplice la gestione corretta della verifica. Mentre, la creazione di molti stati rende il modello poco maneggevole e difficile da gestire.
L'azione Duplicate consente di contrassegnare un record in una serie di record duplicate come record attivi e gli altri come duplicati; i record contrassegnati come duplicati non possono essere modificati. Questa azione garantisce che tutto il lavoro su questa richiesta di modifica viene memorizzato da un record. Questa azione utilizza i campi integrati; può essere aggiunta ad uno schema aggiungendo i controlli dipendente duplicato e base duplicata in un modulo e creando le azioni Duplicate e Unduplicate. L'azione Unduplicate restituisce il record nello stato in cui si trovava prima di essere contrassegnato come duplicato.
È disponibile una varietà di schemi predefiniti che includono funzioni specifiche o configurazioni. È possibile utilizzarli come punto iniziale per lo sviluppo di uno schema, ma è necessario confrontare con attenzione le funzioni dello schema predefinito con i requisiti.
Alcuni punti chiave da considerare su questi schemi predefiniti:
Progettare uno schema in maniera tale che supporti lo sviluppo parallelo di più prodotti (o varianti del prodotto) che condividono artefatti comuni richiede molto impegno. La progettazione deve anticipare ed adeguarsi a situazioni come ad esempio l'acquisizione e la gestione delle informazioni quando un difetto riportato viene memorizzato in artefatti condivisi che richiedono correzioni per più prodotti e la memorizzazione dello stato corrente del difetto quando sono necessarie più build (in pianificazioni potenzialmente differenti).
L'utilizzo di un record singolo per memorizzare questi lavori differenti non è un metodo efficace.
Un metodo alternativo è l'invio di più record per ogni prodotto interessato, che consente di memorizzare in maniera indipendente lo stato di ogni attività. Se si utilizza il meccanismo Save Default Values al primo record immesso e Load sui record successivi, è possibile evitare la duplicazione dell'immissione dati su ogni copia. (Questa funzionalità non è disponibile per il Client Web Rational ClearQuest). L'aspetto negativo è che ogni record viene isolato dagli altri; lo sforzo può risultare vano se il lavoro eseguito sulle altre problematiche non viene coordinato.
Un metodo più efficace è rappresentato dall'utilizzo di una struttura gerarchica, in cui il record principale caratterizza la problematica e i record secondari vengono utilizzati per memorizzare la problematica relativa ad ogni prodotto, variante o versione. Il record principale può essere di tipo diverso rispetto ai record secondari oppure coincidere. Alcuni schemi utilizzano lo stesso tipo di record per i record principali e secondari, in modo tale che tutte le informazioni possano essere contenute nell'elemento secondario (riducendo la navigazione tra principale e secondario). Gli altri schemi utilizzano un tipo di record secondario semplice per implementare un tipo di promemoria per rivolgere la stessa problematica alle altre varianti, versioni o prodotti interessati e per memorizzare il relativo stato.