urbanisation-si.com

J'ai surpris un jour cette conversation téléphonique entre un analyste fonctionnel et un développeur.

Il essayait en vain de lui expliquer ce qui arrivait quand on annulait une annulation.

Tout le monde était plié de rire tellement cela devenait un dialogue surréaliste.

Du pure Devos ! Il était impossible de conserver le fil de pensée tellement les phrases étaient longues, pire que du Proust !

Cela ressemblait a peu près à ceci : "quand tu annules une annulation d'une ligne d'un dossier fermé, la ligne se réactive et peut passer dans l'état à traiter si avant d'avoir été annulée elle était calculée, mais si elle était révisée et si le batch est passé alors elle repasse à "à réviser" et sinon à "à payer" à moins que le gestionnaire ait demandé le calcul manuel, à ce moment là il faut demander la validation auprès du responsable de la gestion à moins qu'elle ait été bloqué et qu'on a forcé le calcul, ... , il ne faut oublier bien sur de ré-ouvrir le dossier ...

N'importe qui aurait perdu le fil au bout de la 2 ème ou 3 ème condition. Les capacités cognitives de l'esprit humain sont limités, d'autant plus si les règles sont énoncés par téléphone.

Comment une telle situation est-elle apparue ?

Par manque d'un langage formel de modélisation commun à tous les acteurs du projet, une sorte d'espéranto.

En l'occurrence ici, aucun diagramme d'état UML n'avait été réalisé.

Dans les spécifications Word, on avait certes la liste des états, dans certaines présentations Powerpoint quand on réussissait à mettre la main dessus, figuraient certaines transitions possibles mais sans les événements déclenchant les transitions donc inutilisables et en plus toujours incomplètes sur le plan des scénarios.

Un diagramme d'état permet pour une entité, de montrer toutes les transitions possibles entre ses états métiers, quels sont les événements produisant ces changements d'état et qu'elle est son comportement dans un état donné.

Cela n'a rien à voir avec un ésotérisme technique. Tout ce que représente le diagramme d'état relève bien du métier. 

Imposer l'utilisation d'un tel outil permet de se donner un cadre de pensée commun, de ne rien oublier et d'avoir sur un schéma (qui vaut mieux qu'un long discours, surtout au téléphone !) l'exhaustivité des transitions d'états avec leurs événements déclencheurs.

Le développeur aura alors un automate à états finis avec l'ensemble des règles sans aucune ambiguïté.

L'urbanisme du SI doit imposer entre autre que les transitions d'états complexes soient obligatoirement modélisées avec un diagramme d'état UML sans quoi on laisse la porte ouverte à l'imagination de chacun et la on peut s'attendre à tout !

"La règle d'or de la conduite est la tolérance mutuelle, car nous ne penserons jamais tous de la même façon, nous ne verrons qu'une partie de la vérité et sous des angles différents."
Gandhi

 Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/