Propriétaire de l'état

Chaque état non terminal d'un workflow possède un propriétaire unique. Le propriétaire est le rôle, dans l'organisation, qui a la responsabilité d'agir sur un incident se trouvant dans un certain état. Prenons l'exemple d'une anomalie non vérifiée : l'utilisateur qui confirme ou rejette un incident logiciel non vérifié est, le plus probablement, une personne assurant le rôle QA. Par conséquent, le propriétaire d'une anomalie non vérifiée est le rôle QA.

Un état terminal dans un workflow n'a pas de propriétaire, car personne n'est responsable d'une action à effectuer pour ce type d'état.

Dans Issue Manager vous avez le choix entre quatre propriétaires possibles pour un état non terminal :

Remarque : Un propriétaire d'état n'est pas un ingénieur QA spécifique ni une boîte de réception particulière ; il n'est pas lié à une application, un composant, une release ou une plate-forme. Un propriétaire d'état est la désignation générale d'une responsabilité fonctionnelle par rapport à un état.

Le propriétaire est une propriété importante d'un état, car il détermine, avec les règles de routage, la boîte de réception qui doit recevoir un incident (les règles de routage sont décrites dans la rubrique Configuration des règles de routage). L'exemple qui suit illustre la façon dont Issue Manager utilise les règles de routage, les états et les propriétaires d'état pour placer un incident dans une boîte de réception spécifique.

Supposons que vous décidiez que le propriétaire de l'état Non Vérifié soit le rôle QA pour toutes les anomalies logicielles, quels que soient l'application, le composant, etc. Les personnes qui remplissent ce rôle doivent confirmer si un incident signalé est vraiment une anomalie. Ainsi, dans la boîte de dialogue Propriétés de l'État de l'état Non Vérifié, vous sélectionnez le bouton radio QA gère cet État. La boîte de dialogue Propriétés de l'État, est disponible en accédant à Incidents > Configuration > Workflows et en cliquant sur Modifier l'État.

Considérons maintenant les règles de routage pour des applications particulières. Lorsque vous configurez des règles de routage (Incidents > Configuration > Règles de Routage), vous spécifiez quatre boîtes de réception pour chaque combinaison d'application, de composant, de release et de plate-forme. Chacun des quatre boutons radio de propriétaire d'état correspond à une des quatre boîtes de réception de la page Règles de Routage : QA, Développement, Évolution et Documentation.

Exemple

Une règle de routage stipule : si une anomalie concerne le composant Courriel pour toutes les releases de l'application Product C sur toutes les plates-formes, alors router l'anomalie vers une de ces boîtes de réception : Mike - QA, Sonja - Dev, Dan - Dev (Product C), ou Judy - Doc.

Une de ces quatre boîtes de réception est sélectionnée en fonction de deux facteurs : l'état actuel de l'incident et le propriétaire de cet état. En supposant que l'état actuel de l'incident soit Non Vérifié et que vous avez spécifié que le rôle QA est propriétaire des incidents non vérifiés, l'incident est alors routé automatiquement dans la boite de réception de Mike : Mike - QA.

L'action de Mike sur cet incident aura pour effet de faire passer celui-ci dans un autre état de son cycle de vie, et cet état aura un autre propriétaire. Issue Manager déterminera à nouveau la boîte de réception appropriée en fonction de l'état de cet incident, du propriétaire de cet état et de la règle de routage applicable pour ces application, composant, release et plate-forme spécifiques.