Ce titre peut susciter des questions : pourquoi chercherait-on à produire quelque chose d'incomplet? Le but n'est-il pas plutôt d'avoir un modèle juste, correct, correspondant à ce que l'on cherche à réaliser?
Cet article présente une notion simple : le but des modèles est de représenter de manière visuelle le problème, ce pour favoriser les échanges entre les participants. Cette notion est compatible avec les méthodes itératives et agiles ; un modèle n'est pas produit pour être figé, mais pour évoluer au fur et à mesure de cycles ou itérations. Dans certains cas, un modèle aura uniquement pour but de se mettre d'accord sur ce que l'on cherche à réaliser, sans pour autant répercuter les changements sur ses diagrammes.
Il est donc fort probable que la première version d'un modèle ou diagramme soit incorrecte ou "fausse". Lorsque l'on créé puis présente un diagramme, l'on ne cherche pas à avoir tout juste dès le départ ; le but est de susciter des réactions de la part des interlocuteurs MOA ou MOE, pour corriger et affiner les modèles (en direct lors d'un atelier par exemple avec un outil de modélisation comme Enterprise Architect, ou à postériori).
Les modèles nous permettent alors de se rapprocher d'une vision commune et partagée, ce qui va demander plus ou moins d'itérations et d'efforts selon le contexte et les besoins du projet. Une mise à jour itérative des modèles présente l'avantage de capitaliser sur les choix qui ont été pris par rapport aux impacts sur des évolutions et corrections ultérieures, sur de la maintenance, etc.
Retours d'expériences :
Pas plus tard qu'hier, un de mes collègues était ravi de l'utilité de mon diagramme BPMN "faux" dont l'objectif était de formaliser un processus global en vue d'une décision GO/NOGO : "le diagramme a déjà permis de lever des lièvres et de discuter avec le responsable fonctionnel". A ce stade du projet, les retours des divers responsables peuvent être pris en compte pour arriver vers une vision partagée par tous, ce afin de pouvoir justifier la décision qui sera prise par la suite.
Les exemples sur l'utilité de diagrammes incomplets et non aboutis ne manquent pas ; j'ai eu l'occasion d'établir une cartographie fonctionnelle en travaillant avec deux équipes MOE travaillant sur deux produits en interaction. Chaque équipe m'a décrit et argumenté ses choix d'architecture, identifiant les échanges de données entre leurs applications et systèmes. Chacune de ces équipes avait également un avis plus ou moins abouti sur les choix faits par l'autre équipe. Les modèles UML générés à l'issue de cette étude ont permis non seulement de poser la vision aboutie d'un produit par son équipe de développeurs et d'architectes, mais aussi de mettre à disposition le fonctionnement du produit en interaction avec le leur.
C'est donc en partant d'un diagramme "évidemment" incomplet, que de nombreux échanges constructifs ont donné lieu à la représentation globale et transverse des produits existants, ce en vue de décisions d’architecture pour optimiser et améliorer certains aspects.