ALM dans un environnement ClearQuest MultiSite

Les types d'enregistrement basés sur les rôles dans un schéma ALM permettent d'obtenir un développement distribué global plus efficace. Une équipe d'utilisateurs peut travailler sur des enregistrements spécifiques associés à une demande ou à une tâche en fonction de leurs rôles. Cela empêche tout conflit lorsque plusieurs utilisateurs doivent mettre à jour le même enregistrement.

Outre l'établissement d'un système de gestion des changements basé sur les rôles, un flux de travaux commun permet de traiter les requêtes de maîtrise et de réplication dans un environnement distribué. Par exemple, si un utilisateur se connecte à une réplique située à Bangalore, lorsque l'utilisateur crée une nouvelle tâche, la tâche est maîtrisée à l'endroit où se trouve le développeur propriétaire. La tâche est créée sur le site de Bangalore, puis répliquée. La maîtrise de tâche initiale est déterminée par le développeur propriétaire par défaut, quel que soit l'endroit où la requête est maîtrisée. Notez ce qui suit :
  • Une demande doit être répliquée dans tous les sites pour devenir visible.
  • Une demande contient des références aux tâches associées, et les tâches contiennent une référence à la demande.
  • Chaque tâche est maîtrisée au niveau du site du développeur propriétaire par défaut une fois que la tâche possède l'état Opened. La tâche est maîtrisée au niveau du site du responsable qualité une fois que la tâche possède l'état Activated.
  • L'activité d'une tâche associée est maîtrisée au niveau du site du propriétaire une fois que la tâche possède l'état Opened ou Submitted. Le développeur affecté est le propriétaire de l'activité du développeur. Le développeur propriétaire par défaut peut être déterminé par la valeur de la zone Project, Component ou Subcomponent. Le propriétaire Doc par défaut est le propriétaire de l'activité d'évaluation de la documentation, et l'ingénieur qualité propriétaire par défaut est le propriétaire de l'activité de test.

Le paradigme du flux de travaux ALM fournit une prise en charge claire du développement parallèle distribué. Par exemple, les tâches créées pour traiter les demandes peuvent être révisées par les demandeurs lorsque les activités du développeur ont été réalisées, mais pas encore testées ou évaluées au niveau de la documentation. Certaines activités de développeur peuvent posséder l'état Completed et d'autres conserver l'état Opened lors du test sur le travail réalisé jusqu'à présent.

Le tri d'enregistrements dans un clan MultiSite ne permet pas aux utilisateurs exécutant la même demande sur différents sites de voir la même séquence d'enregistrements si les zones de tri d'une requête possèdent plus d'un enregistrement avec la même clé de tri ou des valeurs de clé de tri concaténées. Par exemple, si vous effectuez un tri par nom et que deux enregistrements possèdent le même nom, les utilisateurs de chaque site peuvent ne pas voir les deux enregistrements dans le même ordre. Si vous utilisez l'enregistrement ID comme deuxième zone de tri, notez que les ID se voient allouer des blocs d'ID qui peuvent ne pas suivre l'ordre des enregistrements soumis. Si vous utilisez les filtres d'historique (History.action_name dans ('Copy_Record, 'Import')OR History.old_state = 'no_value'), vous pouvez obtenir le premier enregistrement d'historique pour tout enregistrement afin de trouver l'ordre absolu dans lequel les deux enregistrements intègrent un clan. Utilisez le code History.expiration_timestamp IS NULL pour obtenir la dernière occurrence History.Action.


Retour d'informations