Modélisation du périmètre

Objectif

Le modèle de périmètre sert à trancher, avant tout travail d'élicitation, ce qui relève de l'analyse et ce qui n'en relève pas. Il pose une frontière et lui adjoint un jugement: chaque processus, chaque acteur, chaque système et chaque donnée est déclaré à l'intérieur ou à l'extérieur, avec le critère qui justifie ce classement. De cette frontière découlent trois décisions que rien d'autre ne fournit aussi tôt. Elle fixe une base contractuelle et d'estimation: on ne chiffre un effort et on n'écrit des obligations que sur un périmètre arrêté. Elle règle les litiges d'appartenance: la question « est-ce dans le périmètre? » se tranche selon des critères écrits plutôt qu'à l'opinion du jour. Elle mesure la complétude: confronter les exigences recueillies au périmètre annoncé fait apparaître les zones oubliées et les débordements.

Le livrable combine trois formes: un ou plusieurs diagrammes des relations entre éléments, une ou plusieurs matrices de dépendances et un texte qui énonce les éléments retenus, les critères d'inclusion et les hypothèses critiques sur lesquelles le tracé repose. Décrit par phases lorsque la livraison est phasée, il porte une frontière par phase.

Usage

Quand l'utiliser

• Début d'une initiative: fixer la frontière avant l'élicitation des exigences, pour que les décisions d'inclusion aient une base.
• Cadrage d'un contrat ou d'un mandat: donner une ligne défendable pour les obligations, l'estimation et la maîtrise des changements.
• Litiges récurrents d'appartenance: un modèle partagé tranche « est-ce dans le périmètre? » selon des critères écrits.
• Changement pluripartite ou inter-organisations: nommer les unités, systèmes et agents externes que le changement touche.
• Livraison par phases ou itérations: décrire le périmètre par phase, pour que chaque incrément porte sa propre frontière.

Quand ne pas l'utiliser

• Frontière déjà fixée et stable: sur un petit changement bien compris, un énoncé d'une ligne suffit, le modèle complet est un surcoût.
• La difficulté est la décomposition: recourir à la décomposition fonctionnelle pour ouvrir le côté intérieur en parties.
• Frontière en « horizon », dépendante de la position de la partie prenante: un modèle statique induit en erreur, préférer une planification adaptative par jalons.

Deux axes de classification

Un modèle de périmètre se range sur deux axes indépendants. Le premier axe dit ce que la frontière montre. Vue de l'intérieur, elle affiche les éléments qu'elle contient; vue de l'extérieur, elle affiche les éléments qu'elle exclut; vue des deux côtés, elle porte des éléments de part et d'autre. À chacune de ces vues correspond une forme d'artefact éprouvée.

Le second axe, indépendant du premier, dit quel périmètre le modèle éclaire. Le périmètre de contrôle délimite ce qui est analysé, les rôles et responsabilités et ce qui est interne ou externe à l'organisation. Le périmètre de besoin cerne les besoins des parties prenantes, la valeur à livrer et les unités à explorer. Le périmètre de solution couvre les exigences satisfaites, la valeur livrée et l'impact du changement. Le périmètre de changement énumère les actions à mener, les parties prenantes touchées et les événements à provoquer ou à empêcher. Un même diagramme relève des deux axes: il se voit d'un côté et éclaire un périmètre. Les deux lectures se combinent.

Choisir le modèle et sa forme

Le choix de la notation découle de ce que la frontière doit montrer. Quand l'enjeu est de dire ce qui reste dehors, le diagramme de contexte est l'outil: il pose le système comme un unique processus au centre, l'entoure des entités externes qui lui parlent et ne dessine que les flux qui franchissent la frontière. Il est la forme la plus économique d'un périmètre et le niveau supérieur d'un jeu de diagrammes de flux de données. Quand l'enjeu est au contraire de détailler ce qui se trouve dedans, la décomposition fonctionnelle ouvre le côté intérieur en fonctions et sous-fonctions. Quand la frontière doit montrer les deux côtés en même temps, le modèle de cas d'utilisation place les acteurs dehors et les cas d'utilisation dedans, dans une boîte qui figure le système. Le diagramme de Venn, lui, oppose deux ensembles et leur intersection.

Chacune de ces représentations se double des deux autres formes de résultat. Le texte décrit les éléments et, surtout, les critères qui rendent une décision d'inclusion défendable. La matrice expose les dépendances entre éléments de périmètre, celles qu'un diagramme laisse dans l'ombre. Un modèle de périmètre complet combine les trois, à la mesure de la décision qu'il sert.

Les relations à explorer

Vérifier qu'un périmètre est complet revient à explorer les relations entre ses éléments, car une dépendance oubliée cache un élément oublié. Cinq familles de relations méritent d'être explorées, chacune associée à une famille de diagrammes. La relation parent-enfant décompose un élément en ses parties, par un organigramme, des sous-processus ou un modèle de données. La relation fonction-responsabilité rattache une fonction à l'agent qui l'exécute, par un modèle de processus, un diagramme de séquence ou un modèle de cas d'utilisation. La relation fournisseur-consommateur relie les éléments par la donnée ou la matière qu'ils s'échangent, par un diagramme de flux de données ou un modèle de processus. La relation cause-effet enchaîne les éléments par contingence logique, par un diagramme d'Ishikawa. Restent les propriétés émergentes, ces résultats qu'une interaction produit et qu'aucun composant pris seul ne laissait prévoir, qu'un tracé de frontière statique peine à capturer.

Le niveau de détail

La difficulté récurrente est de choisir à quelle granularité décrire les éléments. Le but de l'analyse fixe ce niveau. Un même sujet de changement se décrit de trois manières: en énumérant les éléments un à un, en se plaçant à un niveau de décomposition choisi ou en regroupant les éléments en ensembles logiques. Un lot de processus figure ainsi comme une liste de processus nommés, comme un processus de haut niveau qui les englobe ou comme une fonction générique.

Deux fautes symétriques guettent ce choix. Trop grossier, le modèle laisse les éléments de frontière dans le flou. C'est sur ces éléments-limites qu'un périmètre mal défini coûte le plus cher: la zone grise se révèle après la signature, quand elle devient un litige. Trop fin, le modèle bascule dans la paralysie d'analyse: on décompose au-delà de ce que la décision de périmètre exige, et l'exercice cesse de réduire l'incertitude pour devenir un inventaire. Le bon niveau réduit l'incertitude de manière utile sans franchir ce seuil.

Les hypothèses et la durée de vie du périmètre

La validité d'un modèle de périmètre repose sur des hypothèses: la définition des besoins, la causalité des effets attendus, l'impact du changement, la faisabilité de la solution. Ces hypothèses sont le plus souvent tacites, et un modèle qui paraît accepté peut ne reposer que sur des croyances que personne n'a énoncées. La discipline consiste à écrire les hypothèses critiques et leurs implications à même le modèle, à côté du tracé qu'elles soutiennent. Une frontière acceptée sur une hypothèse fausse est un litige différé.

Un périmètre vieillit. Une fois arrêté, il devient difficile à modifier, pour des raisons politiques autant que contractuelles, alors même que plusieurs forces en érodent la validité: une hypothèse initiale démentie, une situation qui change, des besoins qui évoluent, une innovation technique. Traiter le modèle comme figé est donc une faute: il se relit et se révise, en tout ou en partie, chaque fois qu'une de ces forces se manifeste. Reste une confusion à éviter, entre le périmètre de changement, qui dit ce qui est modifié, et le périmètre de solution, qui dit ce que la solution doit couvrir: une même initiative les distingue, et les fondre produit un modèle qui ment sur l'un ou sur l'autre.

Considérations IA

Deux emplois sont solides. Le premier est le premier jet: à partir de documents de processus, de cartes d'acteurs ou de schémas d'intégration existants, un modèle de langage propose une liste d'éléments internes et externes, un jeu d'entités externes candidates et un diagramme de contexte à corriger. Il remplace la page blanche par un brouillon, ce qui a de la valeur sur un système hérité dont la circulation réelle s'est perdue. Le second est le contrôle croisé: confronter un modèle de périmètre à la liste des exigences recueillies pour faire remonter les éléments présents d'un côté et absents de l'autre et proposer les paires de dépendances qui alimenteront la matrice.

Trois décisions échappent à l'outil. La décision d'inclusion elle-même est un arbitrage politique et contractuel qu'aucune donnée d'entrée ne contient. Les hypothèses critiques supposent de savoir ce que l'organisation tient tacitement pour acquis, ce qu'un modèle entraîné sur des textes génériques ignore. Les éléments de frontière, où se loge toute la difficulté, demandent le jugement que la technique existe pour exercer. Une réserve enfin sur la donnée: soumettre des cartes de processus internes, où figurent les noms de partenaires et de fournisseurs, à un service externe est une question de confidentialité et de protection des données au sens de la nLPD. La frontière est l'endroit où ces noms sensibles apparaissent.

Exemples

Un canton met en ligne un portail de déclaration de changement d'adresse, par lequel un habitant annonce son déménagement sans passer au guichet. La question de périmètre est de savoir ce que le portail prend en charge et ce qu'il laisse aux systèmes en place. Le diagramme de contexte y répond d'un seul tracé: le portail est la bulle centrale, et autour de lui se tiennent l'habitant qui déclare, le fournisseur d'identité qui l'authentifie, le contrôle des habitants de la commune qui reçoit l'annonce validée et le prestataire de paiement qui encaisse l'émolument. Chaque flux qui franchit la frontière, la déclaration soumise, l'identité vérifiée, l'annonce validée, la confirmation de paiement, est une interface à étudier.

La décision d'inclusion se consigne ensuite élément par élément, avec son critère. Le critère de tri est le rapport de l'élément au changement: ce que le portail crée ou modifie est dedans, ce avec quoi il ne fait qu'échanger est dehors. Cette ligne, tracée et justifiée avant l'élicitation, est ce que le contrat chiffrera et ce que la recette vérifiera.

Coût

Outils

Le choix de l'outil suit l'usage attendu du modèle. Pour une discussion de frontière entre personnes réunies, le tableau blanc ou le papier suffisent, et leur caractère éphémère est un atout au moment où l'on cherche encore où passe la ligne. Un éditeur de schémas (diagrams.net, Lucidchart, Visio) porte le diagramme de contexte et le modèle de cas d'utilisation dès qu'ils doivent être partagés, versionnés et retouchés. Le tableur tient la matrice des dépendances et la table des décisions d'inclusion, là où le tri et le filtre valent mieux qu'un dessin. Un outil de modélisation (Enterprise Architect, Sparx) s'impose quand le modèle de périmètre alimente un modèle plus vaste, d'exigences ou d'architecture, avec lequel il doit rester cohérent. Un espace documentaire ou un wiki enfin porte l'énoncé textuel du périmètre et le registre des hypothèses, qui doivent rester lisibles et horodatés au fil de leurs révisions.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.41 Scope Modelling: la classification des modèles de périmètre selon ce que la frontière montre et le périmètre qu'elle éclaire, les éléments à déterminer, le niveau de détail, les hypothèses et les limites de la technique.
• Tom DeMarco, Structured Analysis and System Specification, Yourdon Press, 1978: l'origine du modèle de flux à niveaux dont le niveau supérieur, le diagramme de contexte, pose le système comme un seul processus face à ses entités externes, la frontière du périmètre vue de l'extérieur.
• Chris Gane et Trish Sarson, Structured Systems Analysis: Tools and Techniques, Prentice-Hall, 1979: la seconde notation d'analyse structurée pour le diagramme de contexte, portant la même idée de frontière.
• Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992: l'origine du modèle de cas d'utilisation, dont la boîte du système place les acteurs dehors et les cas d'utilisation dedans, un périmètre vu des deux côtés.
• Object Management Group, Unified Modeling Language (UML), v2.5.1: la norme actuelle du diagramme de cas d'utilisation et de la frontière du sujet (système).