Flux de travail

Nous allons apprendre à créer des applications personnalisées à travers un exemple. Nous allons développer une application simple de suivi des bogues. Nous supposerons la présence de deux équipes : les développeurs, qui corrigent les bogues, et l’équipe d’assurance qualité (AQ), qui teste les corrections apportées par les développeurs. Nous modéliserons le flux de travail de gestion des bogues suivant :

En termes simples, le diagramme se traduit par :

Lorsqu'un bug est signalé, il est à l'état « Nouveau ».
L'assurance qualité vérifie le bogue. S'il ne s'agit pas d'un bogue, il est marqué comme « Fermé » ; sinon, il est marqué comme « Vérifié ».
Un bug vérifié et corrigé par un développeur passe à l'état « Corrigé ».
Le correctif est ensuite testé par l'assurance qualité et le bogue passe à l'état « Réouvert » si le test échoue, ou « Fermé » si le test réussit.
Un bug rouvert et corrigé par le développeur passe à l'état « Corrigé ».

Chaque bulle représente une étape du cycle de vie d'un bug, tandis que chaque flèche représente une action de l'utilisateur final. À côté de chaque état, l'équipe responsable est indiquée. Notez également qu'un bug ne peut pas passer directement d'un état à un autre ; par exemple, un bug ne peut pas passer directement de…

Nous utilisons nous-mêmes notre propre application de suivi des bogues, mais elle comporte beaucoup plus d'états pour indiquer la présence d'un cas de test, la mise à jour de la documentation, l'ajout d'un cas de test, etc. De même, vous pouvez rendre le flux de travail aussi complexe ou simple que vous le souhaitez. Pour l'instant, concentrons-nous sur le flux de travail simple que nous avons évoqué précédemment.

Création d'une application

Pour créer une application, rendez-vous sur Menu principalAdministrateurApplications personnaliséesApplications et cliquez sur

Vous verrez un formulaire comportant plusieurs onglets. Nous allons les détailler un par un ci-dessous.

L'onglet Basique

Cet onglet définit certaines propriétés de base de l'application. De plus, il contrôle également certains comportements de l'application.

Nom	Nom de votre application. Nous indiquerons « Bug » ici.
Pluriel	Le pluriel du nom.
Initialement, affecter à	Sélectionnez l'utilisateur qui sera automatiquement affecté aux nouvelles instances.
Utiliser le champ du demandeur	Par défaut, le créateur d'un élément d'application en est également le demandeur. Cependant, il peut arriver que vous souhaitiez lancer une application pour le compte d'une autre personne et que les notifications et mises à jour lui soient envoyées, et non au créateur. Dans notre application, nous souhaitons que nos agents de support puissent signaler des bogues pour le compte d'un client, mais que les mises à jour soient envoyées à ce dernier. C'est pourquoi nous activons cette option. Une fois activée, un « Demandeur » apparaît lors de la création d'une nouvelle instance d'application.
Autoriser les journaux de temps	Autoriser ou non l'enregistrement du temps passé sur l'élément d'application. Nous souhaitons que nos développeurs et notre équipe d'assurance qualité enregistrent leur temps de travail ; nous avons donc coché cette option.
Les clients peuvent lancer cette application	Indiquez si vous souhaitez que vos clients puissent créer de nouvelles instances. Nous souhaitons que nos clients signalent les bogues, c'est pourquoi nous cochons cette option.
Description	Une brève description de votre application.
Abonnés	Sélectionnez les abonnés par défaut. Ces abonnés recevront des notifications en cas de réaffectation, de changement de statut ou de nouveaux commentaires.
Actif	Indiquez si vous souhaitez activer ou désactiver votre application. La désactiver ne supprimera pas les instances existantes de cette application.

L'onglet États

Cet onglet définit les états de l'application. Vous pouvez également indiquer les états de début et de fin du flux de travail. Nous avons répertorié tous les états de notre flux de travail de correction de bogues.

État initial	Lorsqu'un élément d'application est créé, il passe à cet état. Dans notre cas, il s'agit de « Nouveau ».
État final	Lorsqu'un élément d'application atteint cet état, le processus est considéré comme terminé. Dans notre cas, il est fermé.

L'onglet Flux de travail

Cet onglet définit tous les

Dans le diagramme de flux de travail, chaque flèche représente une action de l'utilisateur final. Nous verrons plus en détail son utilisation ultérieurement dans la documentation.

Action	Nom de l'action. Ce nom sera utilisé dans les menus d'actions pour les bogues.
Depuis	L'État d'origine de la flèche.
À	L'état où la flèche se termine. Une fois l'action effectuée, notre bogue passera à cet état.
Attribuer à	L'utilisateur auquel le flux de travail sera attribué une fois l'action effectuée. L'invite dans le rôle : Développeur indique que l'utilisateur effectuant la vérification du bogue se verra présenter une liste de développeurs parmi lesquels choisir le nouvel auteur de la tâche.
Autoriser l'utilisateur	Détermine si cette action peut être effectuée par un utilisateur. Dans certains cas, nous ne souhaitons pas que les utilisateurs finaux effectuent cette action. Par exemple, dans les systèmes de support technique, les tickets restés sans réponse sont automatiquement fermés après quelques jours d'inactivité.

L'onglet Déclencheurs

Dans notre application de suivi des bogues, nous n'avons pas besoin de déclencheurs. Prenons toutefois l' un flux de travail de support technique . Dans le cas de cette application, le demandeur est la personne qui a posé une question. Lorsqu'elle répond par e-mail, nous souhaitons que le ticket passe automatiquement à l' « Non résolu » , car il est alors porté à l'attention de l'équipe de support. Autrement dit, nous souhaitons que les de réouverture s'effectuent. Dans ce cas, nous définirions nos déclencheurs comme suit :

L'onglet Gestionnaires d'État

Un gestionnaire d'état est un utilisateur considéré comme un responsable lorsqu'une application se trouve dans un état particulier. Il est notifié des événements affectant un élément de cet état. Dans l'exemple ci-dessous, Mark est le responsable QA ; il est donc en charge des « Nouveau » et « Corrigé » , où l'équipe QA intervient. Vous pouvez remplacer les gestionnaires d'état au niveau du projet si la personne en charge de cet état est différente.

Et ensuite ?

Nous avons créé une application personnalisée pour notre flux de travail de gestion des bogues. Dans le chapitre suivant, nous ajouterons des champs personnalisés au bogue.