La modélisation système consiste en ATDD à représenter visuellement des éléments d’un système, jusqu’à enchaîner :
- Des UC : le Product Owner (PO) devra à ce niveau tester l’intégration des UC pour répondre aux objectifs de chaque macro-fonctionnalité (MUC)
– Des MUC : pour former de bout en bout des “parcours utilisateur” ou une partie (une activité par exemple). Là encore le PO sera sollicité.
D’un autre côté, une équipe de testeurs IT (des Business Analystes par exemple) peuvent vouloir s’assurer de l’intégration de “tâches métiers” dans une UC. En agile ces tâches sont des US INVEST ou des US INVEST ayant subi des modifications successives de détail (au niveau d’une ou plusieurs règles de gestion).
Principes de modélisation graphique
On a une représentation visuelle, dans chaque cas, de “fonctionnalités” qui s’enchaînent au sein d’un élément fonctionnel plus vaste. Le principe de modélisation est le même pour chaque niveau, avec la même palette d’objets graphiques (syntaxe) :
- Un point de départ
- Un, voire plusieurs, point(s) de sortie
- Des éléments qui doivent s’intégrer à la macro-fonctionnalité (de niveau supérieur)
- Des décisions (un losange)
- Des flèches appelées “transitions” qui enchaînent :
- Des éléments
- Un élément vers une décision
- Une décision vers un élément
- des alternatives qui fournissent des affirmations. Elles peuvent se visualiser comme des “OU” sur une transition, ou comme des transitions alternatives entre un même couple d’objets graphiques (par exemple d’un élément A vers un élément B).
Voilà les 6 notions qui suffisent pour modéliser avec les métiers.
On pourra toujours ajouter des commentaires.
Prenons un exemple pour illustrer :
Différentier modélisation métier et modélisation d’automatisation d’un processus
Dans la représentation choisie, nous avons simplifié la notation à l’extrême. Elle suffit cependant à spécifier. Les cas complexes (ex: les ET de synchronisation pour indiquer qu’un traitement ne peut démarrer qu’en ayant les résultats de 2 traitements ou plus) sont transformés en règles de gestion.
Souvent l’erreur de l’IT est de proposer aux métiers de discuter sur un modèle BPMN (Business Process Model Notation). Or celui-ci a une palette précise, mais très/trop riche. C’est en fait un langage de programmation graphique pour automatiser in fine le processus décrit.
Nous conseillons d’éviter l’usage du BPMN pour ne pas perturber le dialogue avec le métier. Rester compréhensible de tous est une posture qui doit prédominer en agile.
Ceci implique que le schéma de modélisation métier doit être repris par les programmeurs de la couche BPM pour automatiser le processus : lancement des traitements, changement des statuts, historique et avancement des instances de processus, etc.. C’est l’attitude à adopter, de la même manière qu’on ne mélange pas spécification et code pour les autres parties de la solution !
Cibles d’un modèle
On voit bien que, dans un modèle, il y a des éléments à identifier qui vont nous servir de “cibles” pour les tests. Dans notre exemple :
- 1 point d’entrée, 2 de sorties et 5 éléments (notés de A à E) , soit 8 “boîtes”
- 15 transitions (les flèches, dont 7 en gras donnant le scénario nominal)
- Et enfin certaines transitions portent des alternatives (sur les flèches, séparées par un “OU”), d’où 19 alternatives.
Les alternatives en gras sont les plus représentatives de la transition associée (ex: sur la transition TR2, X>=0 est l’alternative la plus courante).
Les “boîtes” sont toutes homogènes : soit des tables de décisions (cas de tâches métiers : US INVEST), soit des modèles graphiques de détail (sous-fonctionnalités du produit considérées par l’utilisateur à l’instant T). Elles ont donc une représentation interne “boîte blanche”. La modélisation graphique, quant à elle, montre leur vision “boîte noire”, en retenant les résultats majeurs et les directions suivies après exécution.
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
