Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3

L’outil open source et low code d’architecture logicielle Obeo Information System Designer (ISD) et sa méthode Graal, un fork agile d’UML, intègre les User Stories et les aspects statiques et dynamiques des IHM, le tout relier à un gestionnaire d'exigences.
Les matrices de traçabilité garantiront que les parties prenantes auront une compréhension complète du produit en cours de développement et que toutes les exigences seront satisfaites.

Exemple de la cartographie de la cinématique des écrans,
comprenant leur aspect et leur composition, ainsi que les actions assurant la navigation.
Une vue permet d'avoir la liste des exigences prises en compte par le workflow.

Le NoUML est apparu parce que les formalismes normalisés de modélisation comme UML n’ont jamais pris en compte les méthodes agiles, c’est ce que nous déplorions dans nos 2 précédents articles :

La méthode Graal d’Obeo a réparé cette erreur en intégrant, entre autres, les User Stories des méthodes agiles.

Un peu d’histoire sur les User Stories

En 1999, Kent Beck publie en premier le principe des User Stories (US) ou récits utilisateurs dans le cadre de la méthode « eXtreme Programming (XP) ».

Les US sont largement adoptées par les méthodes agiles comme Scrum, en raison du formalisme minimaliste et de l’amélioration de la communication MOA/MOE. Elles sont en parfaite adéquation avec des itérations courtes, car une US doit pouvoir être implémentée en une itération contrairement aux cas d'utilisation UML.

Une US illustre un besoin fonctionnel exprimé par la typologie d’utilisateurs. Cela permet d’assurer que l’on délivre bien pour eux de la valeur. Les avantages sont de permettre :

de coller au maximum au besoin et à la vision de l’utilisateur (car elles sont exprimées de manière simple, en langage courant) ;
d’engendrer un gain de temps considérable pour les équipes de développement dans leur compréhension de la fonctionnalité à développer (toujours grâce à sa forme synthétique) ;
d’aligner la vision, et de confirmer la compréhension du métier, du Product Owner, des développeurs, du Scrum Master, des testeurs et de toute autre partie prenante, en les rassemblant autour d’un langage commun.

Résumé des épisodes précédents

ISD de l’éditeur français Obeo est un environnement open source, low code et NoUML pour l’analyse, la conception et la génération de code d’applications, s’interfaçant avec l’outil d’Architecture d’Entreprise SmartEA du même éditeur.

Pour l'aspect dynamique du système, la démarche permet de modéliser les rôles des acteurs, puis les cas d'utilisation. Leur granularité étant toujours problématique, l'utilisateur sera aidé en ayant la possibilité de les décomposer suivant 2 niveaux de détails :

les scénarios (Tasks Graph),
les étapes (Actions Plan) d’un scénario.

Pour ceux qui le désirent, il est possible d'ajouter des diagrammes de séquence et d'états.

L'aspect statique se compose de diagrammes semblables à ceux d'UML, mais expurgés des éléments rarement utilisés :

les domaines métier (Namespaces), équivalent au diagramme de package UML avec la complexité des relations en moins,
les entités métier et leurs relations (Domain Classes), correspondant à un diagramme de classes UML pragmatique.

Si vous avez manqué le début, voici les 2 épisodes précédents :

Conception d’une User Story
à partir d'un Tasks Graph ou d’un Actions Plan

Dans notre article cité au début « Que faut-il garder d'UML... », nous proposions que les cas d'utilisation UML référencent plusieurs User Stories. C’est ce que propose la méthode Graal d’ISD. Une fois une User Story créée (voir en annexe la procédure), vous pouvez lui rattacher (lien de composition UML dans le métamodèle de la méthode Graal ?) des tâches d’un Tasks Graph ou des actions d’un Actions Plan, appartenant à un Use Case. Le principe fondamental de l’agilité consistant à simplifier et à faciliter l'analyse d'impacts est bien respecté.

Un ensemble d'actions de la tâche « Rechercher un assuré » sont liées à la User Story :
« US02 : En tant que Gestionnaire Prévoyance, je veux rechercher un assuré suivant des critères,
afin d'avoir l'historique des survenances et sinistres associés,
pour prendre la décision d'ouvrir un nouveau dossier de prestation. »

Gestion des exigences

Plus besoin de SysML, ISD est un studio « all inclusive »

A l’identique de ce qui précède, UML ne possède aucun diagramme pour modéliser les exigences. Si l’on veut rester dans la nébuleuse des normes de l’OMG, il faudra se tourner vers une autre notation, SysML.

Voir nos articles :

ISD possède un outillage de gestion des exigences, offrant un ensemble de fonctionnalités permettant d’intégrer la gestion d’exigences d’un projet dans le processus de modélisation. Il est composé d’un éditeur permettant de saisir ses exigences et d’une vue gérant le lien entre les modèles et les exigences du projet (voir les procédures en annexe).

Etude d'impacts : merci aux matrices de traçabilité de la méthode Graal d'ISD

La méthode Graal possède des matrices de traçabilité, offrant une vue consolidée, pour les tâches, les use case et une dernière rassemblant tous les éléments concernés par des exigences, comme les écrans et les workflows (voir les procédures en annexe).

Tout changement sur les 3 exigences impacterait la tâche « Rechercher assuré »,
ainsi que les actions qui la composent, représentées par le diagramme de plan d'actions.

Liste des exigences réalisées par un use case.

Les diagrammes de séquence et d’états UML ont été simplifiés dans la méthode Graal et l'on applaudit

Les principaux éléments standards d’un diagramme de séquence UML sont présents,
sauf ceux plus exotiques (voir en annexe la procédure de création).

On retrouve un diagramme d’états UML pragmatique ;
Obeo a élagué tous les concepts complexes des machines à états de la norme
et inutiles en informatique de gestion (voir en annexe la procédure de création).

Faites votre film en dessinant
l'enchaînement de vos écrans

Vous pouvez concrétiser vos US en modélisant la cinématique et les maquettes des écrans. ISD possède un outil de conception d'écrans d’application nommé Cinematic Designer, permettant de décrire la structure d’une IHM (modélisation statique) et son comportement (modélisation dynamique).

Cinematic Designer apporte le point de vue Cinematic Views qui permet de :

Modéliser des vues et leurs éléments comme les composants graphiques d’une IHM,
Modéliser la structure de la disposition graphique sous une structure de type « Grid Layout »,
Modéliser les états et le flot entre les états de l’application,
Organiser les Flows et les View Elements en packages.

Le directeur de la photo : Vue Statique ou View Container (maquette écran ou mockup)

Cette représentation apporte la modélisation de la disposition graphique des composants de l’IHM. Elle permet de créer et positionner les View Elements dans les View Containers.

Maquette d’écran représentant la User Story de recherche d'assuré par le gestionnaire prévoyance,
décrite précédemment (voir en annexe la procédure de création).

Le metteur en scène : Vue Dynamique ou Flow

Ce diagramme permet d'afficher :

Les états du Flow (InitialState, FinalState, ViewState, ActionState, DecisionState, AsyncEventState, SubflowState),
Les événements transitoires éventuellement conditionnés (guard entre crochets) qui font transiter d'un écran ou d'un état à un autre,
Un conteneur flottant nommé FlowEvents présente les FlowEvents génériques du flow de portée globale, qui représentent des événements logiques ou métier,
Les ViewContainers rassemblant les éléments d'un écran (boutons, tableaux, zones de formulaires...) référencés par les ViewState affichés.

Cinématique des écrans de la User Story de recherche d'assuré par le gestionnaire prévoyance décrite précédemment, avec les événements assurant la navigation. Le picto « clé » indique que l'élément est lié à des exigences. En double cliquant sur l'autre picto, on accède à la maquette d'écran.
Dommage qu'on ne puisse pas avoir une fonctionnalité identique avec les User Stories !

Le producteur : Vue Package

Ce diagramme permet de modéliser les Packages, Flows et ViewContainers.

Représentation du package contenant le ViewContainer et le Flow associé, abordés précédemment.

Le directeur du casting : Vue de la structure de l’interface utilisateur (UI Structure)

La représentation UI Structure fournit une vue d’ensemble complète de la structure des écrans de l’application modélisée, sous forme arborescente.

Vue hiérarchisée de la structure de l'écran « Synthèse des événements initiaux » de notre User Story.

Le réalisateur d'effets spéciaux : Création de toolkits

Un des objectifs du métamodèle Cinématique est de permettre de créer facilement de nouveaux toolkits. La création d’un toolkit consiste en la création de widgets, et, sous chaque widget, la création des types d'événements qu’il peut déclencher.

Cela est rendu possible par l’intégration du framework open source Sirius, permettant de créer ses propres outils de modélisation, en association avec le métamodèle Eclipse Ecore et l'éditeur EMF (Eclipse Modeling framework).

Si le sujet vous intéresse, consultez les 4 articles que nous avions consacrés à la réalisation d'un outil de modélisation DMN (Decision Model Notation) :

Les répétitions : le calque « Example » pour la valorisation des écrans

Une fonctionnalité intéressante est la valorisation des écrans avec des exemples permettant de concrétiser du storytelling, technique hyper efficace de communication entre les experts métier et la MOE.

Le calque Example modifie le label des View Elements, permettant de visualiser l’IHM
avec des données d’exemple. Le label est alors calculé tel que défini dans le toolkit.

Critique du film : dommage qu'on ne puisse pas lier des user stories à des exigences !

Si la fonctionnalité Flow représente la cartographie pour la navigation et les événements de transition d'un écran à un autre, il nous a été impossible d'associer des user stories, bien que le logiciel le laissait penser.

Par exemple en sélectionnant un élément « View », en cliquant sur l'onglet « User Stories » puis sur le picto +, une boîte de dialogue apparaît permettant de saisir une nouvelle US, une fois complétée et validée, mais l'onglet reste désespérément vide !

Générer la documentation

Finies les SFD (Spécifications Fonctionnelles Détaillées) et STD (Spécifications Techniques Détaillées), ISD va vous faciliter la vie (voir en annexe la procédure de génération de documentation).

Comme dans tout générateur de documentation, il faut un modèle variabilisé.

Conclusion

Avec ISD, les acteurs, qu’ils soient business analyst, product owner, concepteur, développeur, testeur... embarquent dans un train et se laissent conduire. Chacun apporte sa pierre à l’édifice. Le product owner conçoit les user stories, le testeur crée les exigences et les cas de tests à partir des cas d'utilisation, le concepteur modélise les interactions utilisateur et le business analyst les cas d'utilisation, le modèle conceptuel de données et les transitions d’états des entités métier.

Comme le montre notre étude de cas, avec les matrices de traçabilité des exigences avec les use case, les tâches, la cinématique et les maquettes des écrans, les liens sont bien tissés entre les besoins utilisateurs et les spécifications de l’application.

Lors de changements, le contrôle de cohérence entre tous ces éléments et les études d’impact en seront grandement facilités, principe cher aux méthodes agiles.

En couplant ISD avec l’outil SmartEA, vous obtiendrez des cartographies allant jusqu’à une granularité très fine et augmenterez le degré d’agilité de votre architecture d’entreprise.

Jusqu’ici, nous avons vu des équivalents de cartographie métier, fonctionnelle, applicative avec la cinématique et les représentations des écrans : il restera l’architecture technique, abordée dans notre prochain article. Nous verrons qu'ISD a plus d’un tour dans son sac, puisqu’il permet de modéliser une architecture SOA, comme une architecture micro-services.

Merci pour vos commentaires qui seront les bienvenus ainsi que vos retours d'expérience heureux ou malheureux qui pourront profiter à nos lecteurs.

Rhona Maxwel

urbanisation-si.com

@rhona_helena

« Quand les hommes ne peuvent changer les choses, ils changent les mots. »

Jean Jaurès

Annexe 1 : comment procéder ?

Gérer les User Stories (US)

Pour Graal, une user story permet de décrire un enchaînement de tâches
et un parcours dans un plan d'actions.

La procédure de création est la suivante :

Menu Window > Show View > Other… > Information System Designer > User stories

Dès qu’un élément Graal est sélectionné sur un diagramme ou dans la vue Model Explorer, les User Stories du système sont affichées dans la vue permettant de gérer le cycle de vie d’une US.
Pour créer un parcours de tâches à effectuer représentant la US :

faire une sélection multiple soit dans un Tasks Graph ou dans un Actions Plan,
cliquer sur le pictogramme +,
indiquer un nom et une description de la US,
cocher la case de la US nouvellement créée.

Association d'un workflow d'actions à une User Story.

Procédure d'association d'une tâche à une User Story :

Sélectionner la ou les tâche(s) « Créer un dossier de prestation prévoyance »
dans le Tasks Graph,
Cocher la US « Ouvrir un nouveau dossier de prestation ».

Une fois l'association activée, pour visualiser le parcours, double cliquer sur la US ou sélectionner le picto ampoule. Toutes les actions composant la tâche font automatiquement partie de la US. Remarque : Rechercher assuré n'est pas sélectionné, puisque c'est la tâche suivante dans le Tasks Graph.

Le fait d’avoir sélectionné une tâche dans un Tasks Graph (partie supérieure de l'illustration)
sélectionne automatiquement tous ses composants dans le diagramme Actions Plan
(partie inférieure de l'illustration) sauf l'élément représentant la tâche suivante dans le Tasks Graph.

Pour dissocier, sélectionner les éléments affichés par le picto ampoule et décocher la case correspondant à la User story.

Gérer les exigences (requirements)

Classer hiérarchiquement vos exigences en catégorie

Menu File > New > Other… > Requirement Model > sélectionner votre projet,
un Requirements Table est créé. Modifier son nom dans la vue Properties.
Dans l’onglet Requirements table, clic droit sur la première ligne > Create Category
ou dans la vue Properties, cliquer sur le +

Une fois une catégorie créée, de la même manière vous pouvez créer des sous-catégories.

Exemple d'organisation arborescente de catégories d'exigences

Gérer le référentiel d'exigences

Vous pouvez créer vos exigences dans un premier temps dans le modèle Requirements table :

Clic droit sur une catégorie ou sous-catégorie > Create Requirement ou +
dans la vue Properties > dans la vue Properties,
renseigner les différents champs : Id ; Name ; Version ; Status ; Statement.

ISD offre la possibilité de créer un référentiel d'exigences organisé en une arborescence de catégories. On retrouve le fonctionnement des outils de gestion d'exigences
où chacune est documentée avec un ensemble exhaustif de propriétés.

Le menu contextuel sur une ligne du tableau permet la gestion (créer, modifier, supprimer, copier, déplacer...) du référentiel d'exigences.

Associer des exigences à un use case, une tâche ou à une action

Une fois un use case décomposé en Tasks Graph et chaque tâche décomposée en Actions Plan, vous pouvez sélectionner un de ces éléments pour lui associer des exigences.
Activer la vue Linked Requirements : Menu Window > Show View > Other… > Linked Requirements.
Sélectionner un Tasks Graph > cliquer sur une tâche > cliquer sur Link Requirements with Selection de la vue Linked Requirements et sélectionner une ou plusieurs exigences.
Une clé jaune apparaît alors dans l’élément de modèle, signifiant que des exigences lui sont liées.

La procédure serait identique pour un use case ou une action d'un diagramme Actions Plan.

Association de 2 exigences à la tâche « Créer une survenance »

Créer une exigence liée à un élément de modèle, use case, tâche ou action

En sélectionnant un élément (use case, tâche, action), vous pouvez créer et associer
une exigence, en cliquant sur le + de la vue Linked Requirements.

Création d'une nouvelle exigence liée à la tâche « Rechercher un assuré »

Sélection de la catégorie de la nouvelle exigence

Détacher une exigence liée à un élément de modèle, use case, tâche ou action

Sélectionner l’élément de modèle avec une clé > dans la vue Linked Requirements,
sélectionner l’exigence à détacher > cliquer sur la croix rouge.

Créer des matrices de traçabilité pour les exigences

Sélectionner le point de vue d’exigences > clic droit > New Representation >
sélectionner Task Traceability Matrix ou Use Case Traceability Matrix.

Créer des diagrammes de séquence et d’états UML

Sur la méthode Graal, sélectionner le point de vue System > clic droit > New interaction >
new Sequence Diagram > nommer votre diagramme.

Sur la méthode Graal, sélectionner le point de vue System > clic droit > New state Machine > new State Machine Diagram > nommer votre diagramme.

La couche front-end (IHM) :
conception de maquettes et cinématique d'écrans

Créer un modèle d'IHM (Cinematic Model)

File > New > Other > IS Designer > Cinematic Model > Choisir un projet >
Saisir un nom de modèle.

Pour le Toolkit, on a le choix entre Web ou SWT (Standard Widget Toolkit de la fondation Eclipse). SWT est une boîte à outils de widget open source pour Java, conçue pour fournir un accès efficace et portable aux fonctionnalités de l'interface utilisateur des systèmes d'exploitation sur lesquels il est implémenté.
Pour Main container, on a le choix entre Page, Panel et Table.

Le modeleur Cinematic va créer un écran (View Container), une cartographie des transitions d'écrans (Flow), un diagramme de package pour organiser les éléments de l'IHM
et une vue hiérarchisée des widgets graphiques composant les écrans.

Fonctionnalités du modeleur Cinematic

Le modeleur Cinematic apporte les représentations suivantes :

View Container Mockup : diagramme permettant de modéliser l'aspect statique avec la structure et l’apparence des IHM.
Flow Diagram : diagramme permettant de modéliser la dynamique de l’IHM. Le Flow Diagram permet le dialogue entre l’analyste ou le product owner dans un contexte Scrum et le concepteur/développeur schématisant les vues.
Par contre, ce diagramme de flow ne permet pas de définir le contenu des écrans, ce qui se fait sur un diagramme de View Container Mockup.
Package Diagram : diagramme permettant de modéliser les Packages, Flows et ViewContainers.
UI Structure : représentation arborescente permettant de modéliser la description statique de l’IHM (écrans, panels, widgets...).
Layout Diagram : diagramme de consultation des composants et composites d’un layout.

View Container Mockup : dessiner une ébauche d'écran illustrant une User Story

L’objectif n’est pas de concevoir un écran WYSIWYG (What You See Is What You Get), mais de définir une maquette servant par exemple de base de réflexion pour un atelier d’un groupe de travail.

Menu contextuel sur View Container WenPage > New Representation > View Container Mockup

Une fois que l’on a assimilé les concepts, et pour ceux qui connaissent la plateforme Eclipse, le produit est relativement convivial.

ISD crée des images JPEG pour chaque version de la maquette.

Maquette (Mockup) de l'écran illustrant la User Story : « US02 : En tant que Gestionnaire Prévoyance, je veux rechercher un assuré suivant des critères afin d'avoir l'historique des survenances et sinistres associés pour prendre la décision d'ouvrir un nouveau dossier de prestation ».

Flow Diagram : cinématique de navigation, cartographie des événements système
et utilisateurs pour les transitions d'écrans.

Les états (States) View peuvent être représentés par leur Mockup (Maquette) et être lié avec leur View Container. Les transitions peuvent être des actions système ou utilisateur, comme cliquer sur un bouton.

Associer des écrans et des éléments d'IHM avec des exigences

Dans Cinematic > View Container > View Container Mockup > Sélectionner un composant (bouton, etc.) > dans la vue Linked Requirements cliquer sur le bouton jaune Link Requirements with selection > dans la fenêtre sélectionner un référentiel, puis une catégorie et enfin une ou plusieurs exigences.

Traçabilité d'une exigence avec les éléments d'IHM (Requirements Traceability Matrix)

Au chapitre « Classer hiérarchiquement vos exigences en catégorie », nous avions vu comment créer un Requirement Model dans lequel il y avait 3 matrices de traçabilité :

Requirements Task Traceability Matrix,
Requirements Traceability Matrix,
Requirements Use Case Traceability Matrix.

Les Requirements Task Traceability Matrix et Requirements Use Case Traceability Matrix ont été abordées. Reste la matrice Requirements Traceability Matrix. Cette matrice est complète, en indiquant pour une exigence tous les éléments de l'application qui lui sont liés. En plus des use cases, tâches et actions, elle indique les éléments d'IHM.

Requirements Traceability Matrix permet de voir les éléments d'IHM en lien avec une exigence.
Ici, le bouton « Rechercher, » la cinématique des écrans « Flow »
et l'écran « Synthèse des événements d'un assuré » sont liés à l'exigence Req01.

Générer une documentation

Sélectionner le projet dans Model Explorer > Menu File > New > Other… > M2Doc > New Generation > sélectionner un template, pour le test nous avons pris ceux de l’exemple E-BookStore (voir paragraphe suivant). Pour cela, il suffit de cliquer dans Browse workspace et de choisir un template. Plusieurs templates sont proposés :
- E-BookStore_Cinematic_template.docx pour les écrans
- E-BookStore_DataBase_template.docx pour les bases de données
- E-BookStore_GraalSystemAndRequirements_template.docx pour la méthode de spécifications fonctionnelles Graal et les exigences.
Sélectionner le fichier MyGeneration.genconf qui est apparu dans le projet > clic droit > Generate documentation.
Un document MyGeneration.generated.docx Word est généré.

Des modèles prêts à l'emploi sont proposés dans l'exemple complet E-BookStore fourni avec ISD.

Une étude de cas pédagogique couvrant l'ensemble des étapes d'un projet de réalisation d'une application avec ISD, allant de l'analyse à la génération de code

File > New > Example > Information System > E Book Store

Exemple complet d’un site de e-commerce d’une librairie en ligne,
illustrant toutes les couches applicatives de démonstration

Annexe 2 : liste des liens présents dans cet article

Les articles précédents consacrés à Obeo ISD :

Le site de référence :

Obeo Information System Designer (ISD)

Nos articles sur NoUML :

Le site de Kent Beck, l'inventeur des users stories :

Kent Beck

Diagramme d'exigences normalisé avec SysML de l'OMG :

Si vous voulez savoir comment est conçu ISD :

Annexe 3 : pour aller plus loin

Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information

ChatGPT, l’outil idéal de réalisation de modèles pour l’Architecture d’Entreprise et l’Urbanisation du Système d’Information ?

Démarche d’urbanisation du SI : les questions techniques, organisationnelles, voire existentielles

12/09/2023

2 J'aime 0 Poster un commentaire

A découvrir aussi

Retour aux articles de la catégorie Modélisation de système -

⨯

Inscrivez-vous au site

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 719 autres membres