Après une introduction sur les base de ce concept, penchons-nous sur la question des stories en environnement industriel.
Et l’info indus ?
C’est la même chose qu’en IT… Avec probablement deux nuances de taille.
- l’Utilisateur est possiblement un autre système. Et suivant la complexité de l’ensemble, il sera pertinent d’envisager des sous-systèmes qui deviennent autant d’Utilisateurs potentiels. Cela suppose donc, certainement, une modélisation préalable en composants matériels-logiciels (HW-SW).
- De plus, un préalable non-dit des stories est que le contrôle du système se fait au travers des interactions avec l’extérieur. Autrement dit, l’intelligence embarquée est plus ou moins liée directement à une interaction avec un « Utilisateur » externe.
Ce qui est bien le cas généralement en IT (pas toujours, l’informatisation d’un workflow ou d’un traitement batch sont des contre-exemples ici) et pas forcément en info indus.
Modélisation agile
Notez qu’une modélisation agile, comme tout artefact, respecte les principes de « petits stocks » ou « feedback concret rapide ». Autrement dit, pas de « grosse modélisation » sans feedback concret qui valide au fur et à mesure. Par ailleurs, la conception émergente implique un refactoring qui permet d’adapter l’artefact aux évolutions. Autrement dit, la modélisation se fait progressivement, au fur et à mesure des nécessités et ce qui est déjà modélisé est éventuellement mis à jour pour autoriser les évolutions.
Un cas concret
Commençons par le diagramme de contexte. Prenons l’exemple d’un boitier « centrale incendie ». Il reçoit des données de capteurs (fumée, ouverture porte…) et, si nécessaire, actionne des dispositifs (ouverture d’aération, fermeture de porte…). Prenons le cas simple de deux features.
« Capteurs » constitue un Utilisateur, un « acteur » au sens UML. Nous pouvons donc envisager des stories du style
En tant que Capteur
J’envoie une donnée de température…
En effet, le composant ou sous-système en interface dialogue par définition avec les Utilisateurs.
Diagramme de sous-systèmes
Voyons maintenant un diagramme de composants*. Pourquoi ? Car la complexité du système fait que l’intelligence embarquée est bien plus « importante » que le nombre d’interactions. Une story implique probablement de nombreux tests d’acceptation.
Désormais, chacun de ces composants ou « sous-systèmes » devient « système » à son tour (le sens des dépendances <<use>> reste… pifométrique ici, peu importe).
Si nous considérons maintenant le (sous-)système « Interface Capteurs », nous pouvons rédiger des stories telles que (sachant que la modélisation comprend deux « utilisateurs » pour ce sous-système) :
En tant que Capteur
J’envoie une détection de fumée
ou bien
En tant que Superviseur
Je suis informé d’une détection de fumée
De même au niveau du (sous-)système « Contrôleur Actionneurs »
En tant que Superviseur
Je ferme une porte en stoppant l’électro-aimant
Nous pourrions d’ailleurs créer les diagrammes « contexte système » de chacun des sous-systèmes, par exemple :
Quand les stories ne sont pas adaptées…
Le concept de user story n’est pas toujours adapté. Ou bien au prix de découpages qui finissent par ne plus avoir aucun sens. Heureusement, il existe des concepts complémentaires. Nous verrons cela dans un futur billet.
* Il existe certainement de bien meilleures modélisations des sous-systèmes….