Techniques de pré-modélisation : stratégie pour éviter l’échec

Philippe Desfray, Softeam.JPGComment obtenir une synergie entre les différents acteurs de l’entreprise, pour avoir une vision commune des objectifs, du métier, des procédures, de l’organisation, du système existant et des évolutions en cours sur le SI ?

Le problème n’est pas mince : il se heurte à la diversité des domaines et des expertises, et plus encore aux problèmes de communication entre acteurs de cultures et de préoccupations différentes.

Il n’est pas simple en effet de faire une synthèse entre la vision des dirigeants, des utilisateurs, des spécialistes métier (MOA) et des équipes informatiques (MOE).

Certains ont des réticences à formaliser le fonctionnement de l’entreprise : après tout, l’organisme humain fonctionne sans que l’on ait une claire perception de ses mécanismes. Il est par ailleurs vain, voire contre-productif de présenter un diagramme de classes UML à un dirigeant ou à un utilisateur.

La pré-modélisation consiste à fournir les moyens informels, notamment à destination des acteurs non techniques, pour permettre une première formalisation, sur laquelle des décisions et orientations peuvent être prises, à partir de laquelle des modèles plus détaillés peuvent être bâtis, eux-mêmes pour des objectifs spécifiques (MOA, MOE, etc.). Ces « pré-modèles » ne se traduisent pas de manière mécanique en modèles plus détaillés et formels (sur lesquels on peut par exemple faire des simulations, des générations de code, etc.). Ils constituent plutôt une référence justifiant et guidant la construction de modèles détaillés. Ils fournissent une base terminologique, un guide sur la structuration, sur lesquels s’appuieront les éléments de modèle plus précis. Nous allons présenter quelques exemples de ces pré-modèles, qui sont des éléments compréhensibles sans nécessiter d’explications complexes sur le formalisme.

Le succès ou l’échec d’un développement se jouent essentiellement lors des phases amont de la construction d’un système, étape où la pré-modélisation joue un rôle essentiel. C’est là où les acteurs principaux qui déterminent les choix fondamentaux – les décisionnaires, les utilisateurs, les maîtres d’ouvrage – bâtissent l’objectif stratégique ; c’est là où le contour du domaine à traiter, et où les engagements fonctionnels, budgétaires, de planning, et architecturaux apparaissent. À ce stade, l’enjeu est de définir des objectifs compris par tous, réalistes, recouvrant exhaustivement la vision initiatrice du projet.

Face à une analyse préliminaire réussie, à une liste d’exigences bien formalisée et à une définition du domaine suffisamment complète sur laquelle les acteurs se sont accordés, la réalisation du développement permet d’isoler et de réduire les risques qui pourront être maîtrisés.

Les phases préliminaires, cibles de la pré-modélisation

Il est nécessaire de définir les domaines d’application sur lesquels un système doit être mis en place et les processus que le système doit instrumenter. La portée du système doit être illustrée, en termes de domaine couvert, de décomposition initiale en sous systèmes, d’interface avec l’extérieur, etc. La terminologie, les définitions et le contour du domaine sont clarifiés, afin de poser le problème dans un contexte clair. Dans ce domaine, les modes de fonctionnement doivent être explicités, sous forme de procédures métier, mais aussi sous forme de règles et contraintes métiers. L’existant doit être analysé, en étant représenté comme un système dont on montre la structure, les rôles, les responsabilités et échanges d’informations internes ou externes. On cherche à collecter toute l’information préliminaire, que celle-ci soit sous forme de documents, de modèles, de formulaires ou de toute autre représentation. On explicite la nature des produits élaborés par les processus.

Face à cette analyse, il faut ensuite identifier les points faibles, les points à améliorer ou les nouveaux points à introduire constituant la base de la définition du futur système. Le terme « système » est à prendre ici dans son sens le plus large : c’est l’ensemble de l’organisation permettant de fournir un service, d’effectuer des traitements et opérations.

Il s’agit d’une organisation humaine, matérielle, dont seule une partie est assumée par le logiciel. La définition des fonctions à assumer par le logiciel, qui peut être développé spécifiquement ou repris sur étagère, ainsi que l’articulation des responsabilités entre le logiciel et les autres acteurs appartient à la phase préliminaire.

À ce stade, les représentations de l’existant sont reprises, pour présenter le système conformément à la vision et aux objectifs d’évolution.

Dans la phase préliminaire, un enjeu majeur consiste à utiliser des représentations permettant un dialogue entre les parties impliquées comme les utilisateurs, les analystes, les responsables hiérarchiques et les experts du domaine.

L’emploi exagéré de techniques de modélisation comme UML constitue un obstacle à la compréhension pour certains intervenants, et ira à l’encontre de leur implication dans la modélisation ou les revues.

A contrario, l’absence d’une méthode rigoureuse de représentation empêchera la collecte d’une information précise, cohérente et pertinente, que l’on peut abstraire ou détailler selon les niveaux de dialogue. On en viendra donc à combiner plusieurs techniques, pour adresser spécifiquement chaque type de problème, mais aussi pour fournir des représentations compréhensibles par les diverses catégories de personnes impliquées dans les phases amont.

La phase préliminaire fournira des représentations qui constitueront la base d’un contrat pour les acteurs de l’évolution d’un SI : MOA et MOE.

Cette dimension contractuelle renforce encore la nécessité que tous puissent comprendre et partager ce que le contrat exprime. Elle introduit un mode de gestion très particulier des livrables issus de cette phase :

– On ne modifie pas un contrat impunément. Chaque modification nécessite un accord partagé, tant sur sa nature que sur ses conséquences. L’historique des changements contractuels doit être préservé ;
– On doit se référer constamment au contrat pour justifier le travail réalisé par la suite. Il faut ainsi garantir que chacun des termes du contrat a été satisfait par l’application développée, et que les constituants de l’application sont tous justifiés par un lien avec le contrat initial. À ce stade, la « traçabilité » devient un facteur clé pour maîtriser le développement.

Le rappel « littéraire » de l’expression de besoin initiale est une partie importante de ce contrat : il sera souvent nécessaire de s’y référer pour faire des choix (et reposer les pieds sur le sol) lorsque l’on sera accaparé par les difficultés techniques et pratiques de la réalisation.

Techniques de pré-modélisation

Vue générale

Il est dangereux de produire prématurément des modèles. La modélisation impose une vision « formelle » du problème, détermine des choix qui peuvent s’avérer prématurés, et produit facilement un assemblage de boîtes et de liens non représentatifs de la réalité du problème et des objectifs. Il est avant tout fondamental de répertorier une information pertinente sur la nature du problème à traiter et sur les objectifs.

En revanche, il est très intéressant de réaliser des modèles, car ils formalisent le problème, structurent le cadre du développement, et permettent d’identifier des manques de l’analyse préalable en contraignant l’analyste à décrire l’implicite, et à considérer les aspects significatifs du processus. Ils permettent de rendre cohérente une base initiale trop informelle. Outre la formalisation nécessaire à la réalisation du logiciel, le modèle apporte aussi au métier la maîtrise de ses propres concepts et l’explicitation de ses procédures.

La Figure 1 montre qu’il est ainsi nécessaire d’associer plusieurs techniques informelles ou formelles de modélisation, pour pouvoir saisir toutes les facettes d’un problème sans le dénaturer, et ensuite les détailler dans un modèle central, qui peut être raffiné et retravaillé jusqu’à l’implémentation.

Softeam_Figure1.jpg

À titre d’exemple, la construction d’un modèle peut débuter par le recueil des objectifs, des exigences et du dictionnaire d’un système, pour se poursuivre par un modèle initial des procédures métier et un modèle des notions du domaine, qui seront tracées par rapport au dictionnaire et exigences initiales. Ensuite, un modèle de cas d’utilisation permettra par exemple d’isoler l’exploitation du système d’information au sein du système global, tracé et déduit des procédures métiers et des exigences. Enfin, le modèle applicatif sera lui-même tracé sur ces modèles initiaux.

La Figure 2 illustre un cycle de développement pouvant être pratiqué pour itérer des modèles les plus informels au modèle complet et formel. Des intervenants non informaticiens peuvent intervenir sur les représentations informelles.

Softeam_Figure2.jpg

Sans prétendre à l’exhaustivité, les techniques les plus fréquemment utilisées sont présentées ci-dessous. En pratique, elles sont employées selon un grand nombre de variantes, y compris dans leur dénomination. On assiste cependant, et pour chacune d’entre elles, à des mouvements d’uniformisation et de consolidation, se traduisant soit par des outillages ayant des fonctionnalités similaires, soit par des livres dédiés à ces pratiques, ou même des efforts de standardisation comme ceux de l’OMG1 sur l’approche « system engineering », « business rules », ou encore « Business Motivation Metamodel ».

Dictionnaire : termes et définitions pertinentes relatifs au système. Le dictionnaire est un moyen très simple et efficace pour décrire le domaine de l’application.
Approche systémique : représentation globale du système présent et futur. Fournit les responsabilités du système. Derrière les préoccupations de cette approche, on retrouvera les techniques de l’analyse systémique déjà connues dans l’approche Merise, et des techniques de modélisation organisationnelle.
Analyse des objectifs et des besoins : classifiés, formalisés, maintenus, tracés, on trouve des pratiques très similaires fournies par plusieurs ateliers et préconisés par plusieurs démarches.
Identification préalables de processus : Les processus métier peuvent être identifiés à un niveau macroscopique : ils créent de la valeur ajoutée, et correspondent aux grands types d’activités que doit supporter l’entreprise.
Règles métier : description des règles fondamentales régissant le fonctionnement d’une organisation. Leur identification initiale et leur description textuelle apportent une base essentielle sur le mode de fonctionnement que doit respecter le système.
Cas d’utilisation : description des grands cas d’utilisation internes au système. Très utilisée par les praticiens de UML, cette technique est sous-tendue par des démarches de modélisation communément utilisées.
Modèles conceptuels : UML permet de représenter les notions saillantes d’un domaine ou d’un système, et ainsi de formaliser les connaissances préliminaires du système, notamment par l’exploitation des diagrammes de classes.

L’ensemble des informations recueillies par le biais de ces techniques permet d’initier le référentiel du système. Le référentiel permet d’identifier les éléments présents dans le système d’information, ainsi que de fournir des nomenclatures et les identifiants qui seront constamment exploitées et référées sur l’ensemble du cycle de vie des développements et évolutions du système.

Un effort particulier doit être entrepris pour obtenir, de la part de l’ensemble des parties prenantes relatives au système et à ses évolutions, la validation et l’appropriation des modèles et informations recueillis. Des outils spécifiques sont nécessaires pour présenter le modèle aux divers niveaux des responsables hiérarchiques des métiers de l’entreprise, ainsi que pour le présenter aux utilisateurs finals et leur permettre de comprendre l’organisation du système ainsi que le rôle que chacun des utilisateurs doit remplir.

La gestion de la traçabilité est un élément important dans l’ensemble de l’approche. La mise en oeuvre simultanée de techniques différentes impose en effet de gérer la cohérence globale, de garantir la complétude de chacune des facettes, et de permettre des vérifications croisées.

Les standards de modélisation UML et BPMN apportent une assistance importante pour la prémodélisation. Cependant, ces modèles ne couvrent pas tous les besoins pour ces phases, où des extensions et des techniques complémentaires sont nécessaires. Le Tableau ci-dessous montre de manière synthétique le degré de support que UML et BPMN fournissent pour les techniques de modélisation des phases amont. Il existe des ateliers supportant l’ensemble, UML, BPMN et les parties non couvertes par ces standards. La technique des profils UML permet par ailleurs d’avoir des extensions et des supports dédiés à la prémodélisation.

Softeam_Tableau.jpg

 

Dictionnaire

La technique du dictionnaire est la plus simple et la plus immédiate à appliquer. Bâtir un dictionnaire, c’est tout simplement répertorier les termes propres à un domaine d’application, et en produire la définition. C’est un travail fondamental, toujours utile, pouvant être entrepris dès le début. La terminologie d’un domaine est une connaissance essentielle, préliminaire à toute décision fonctionnelle et tout choix d’implémentation, qui bénéficie d’une très grande stabilité une fois finalisée. Il n’appartient pas aux développeurs mais bien plus aux spécialistes du domaine de définir la terminologie d’un domaine. Une fois établi, le dictionnaire est un guide précieux pour les développeurs, qui pourront en extraire un nommage cohérent du modèle. Il constitue un outil de mesure de complétude et de pertinence des modèles, en exploitant la traçabilité entre un dictionnaire et un modèle. Le dictionnaire peut être tolérant dans son recueil de terminologie : il accueille la diversité des vocabulaires qui coexistent dans l’organisation ou le domaine. Le modèle devra opérer une réduction terminologique en choisissant de ne nommer qu’une seule fois une même chose ou un même concept.

Analyse des objectifs et des besoins

La notion d’objectif est à distinguer de celle de besoin. Un objectif est défini en général qualitativement sur du long terme, en ayant une portée large et pouvant être obtenu de nombreuses manières différentes. Un objectif fournit des moyens de mesurer sa satisfaction, mais n’exprime pas par qui ou quoi il doit être appliqué. Un besoin doit être satisfait par quelque chose d’identifié, il intervient a un niveau plus bas que les objectifs. La décomposition des objectifs est un moyen d’identifier des besoins. Formalisé sous forme d’un identifiant (nom, numéro…) et de quelques phrases courtes exprimant le besoin, il possède un ensemble de propriétés (priorité, origine, etc.) qui permettent de le gérer. Les besoins ont très souvent une nature contractuelle : leur identification, gestion, traçabilité est fondamentale pour gérer leur évolution, et pour mesurer la couverture et le respect d’un modèle relativement aux besoins. La traçabilité exprimée entre des besoins et un modèle permet par ailleurs d’établir des mesures d’impact pour, par exemple, connaître les modifications induites par l’évolution d’un besoin.

L’expression des besoins peut par exemple aider à identifier ou à justifier la présence des processus. On identifiera des besoins externes, comme par exemple les besoins des clients relatifs aux services d’une organisation, des besoins internes comme par exemple respecter des contraintes de qualité, légales, de traçabilité, et des besoins dit « non fonctionnels » relatifs aux performances du système, à leur disponibilité, aux taux d’erreur toléré, etc. L’analyse des besoins peut être conduite suivant des méthodologies spécifiques, qui procureront des classifications en types de besoins (exemple : fonctionnels, non fonctionnels, ergonomiques, etc.), et attacheront de nouvelles propriétés à un besoin. S’appuyant sur une définition du domaine et du métier apportée par le dictionnaire, sur les règles métier, et sur la modélisation des processus métiers, l’analyse des besoins exprime les motivations conduisant au développement ou à l’évolution d’un système.

Approche systémique

Pour les systèmes de grande ampleur, où bien souvent un existant est à prendre en compte, il est nécessaire de construire des schémas généraux qui transcrivent une vision globale des constituants d’un système, et de leur mode de coopération. Sur ces schémas, il est important de construire un dialogue et d’avoir l’approbation de tous. Le modèle d’organisation représente les structures de l’entreprise impliquées dans les processus métier avec les échanges d’information. Il met en valeur les responsabilités des sous-systèmes représentés.

Softeam_Figure3.jpg

UML2 introduit la notion de « flot d’information », apportant de nouvelles capacités pour présenter la coopération des sous-systèmes. La Figure 3 est une extension spécifique d’UML2, qui représente l’organisation d’une agence de voyage, avec ses différentes unités d’organisation, et les flux principaux d’information échangés entre ces unités d’organisation et des acteurs essentiels.

Softeam_Figure4.jpg

La Figure 4 représente les rôles dans l’entreprise et leurs types de liens. Outre le lien hiérarchique, il est utile d’indiquer les relations de travail nécessaire (communication), et d’annoter des responsabilités. Ce type de représentation peut être complété par une vision générale des processus, et une indication des éléments manipulés et communiqués entre processus.

Softeam_Figure5.jpg

Dans la Figure 5, les processus ont été structurés par les unités d’organisation, ce qui permet de leur assigner une entité responsable.

Modélisation des processus métier

Cette technique est très fréquemment utilisée dans le cadre de développement de systèmes d’information.

Un processus métier est constitué par un ensemble d’activités réalisées par des acteurs afin d’atteindre un but précis. Par exemple, « Souscrire un nouveau compte » pour un système bancaire ou « Traiter un sinistre » pour un système d’assurance sont des processus métier.

Un processus métier décrit le métier, et non le système informatique. Les tâches d’un processus métier peuvent cependant être liées au système d’information, mais c’est une décision qui intervient ultérieurement. On cherche à formaliser les flux et la synchronisation des différentes tâches impliquées dans la réalisation d’un service.

Il est préalablement nécessaire d’obtenir un accord sur la liste des processus relevant du domaine à modéliser. Il faut s’appuyer sur les points fondamentaux, comme typiquement les processus externes, dans lesquels le client ou les partenaires sont impliqués, avant de présenter les processus « internes » parfois plus sujets à débats.

Plusieurs niveaux de représentation peuvent exister, permettant de progresser depuis une première identification comme indiqué en Figure 5, pour ensuite définir une procédure générale non liée à une organisation particulière et enfin aboutir à un processus détaillé, identifiant les responsabilités des tâches dans un processus, les informations échangées, et les conditions de choix précises.

Ici, la pré-modélisation permet d’affiner l’identification des processus et leur positionnement, avant de débuter les activités de modélisation détaillées qui induiront de nombreux choix et décisions.

Règles métier

Les règles métier sont constituées d’un ensemble de règles déterminant le fonctionnement du métier. Ce peut être des règles qui empêchent, provoquent ou permettent le déclenchement de processus, comme par exemple une assertion qui définit ou contraint certains aspects du métier, un terme ou un fait (assertion structurelle) qui fournit des informations sur le métier ou une contrainte régissant les actions et processus au sein du système.

Une règle doit être « atomique », c’est-à-dire qu’elle ne peut pas être re-découpée en « sous règles ».

On peut par exemple considérer le code civil comme un ensemble de règles métier régissant la société. Les règles métier apportent un modèle abstrait, relativement stable1 et indépendant des choix techniques sous-jacents. Elles constituent une vision complémentaire des autres techniques employées en phase préliminaire.

UML fournit la notion de « contrainte », permettant d’associer des contraintes à toutes parties d’un modèle. En adaptant cette notion aux différents types de règles métier (profil UML dédié), UML peut ainsi supporter la représentation des règles, avec l’avantage de les situer dans le contexte des éléments sur lesquels elles s’appliquent.

En préalable à la modélisation UML, les règles métier peuvent être répertoriées, classifiées et structurées, pour être ensuite tracée sur les modèles concernés.

Cas d’utilisation

Softeam_Figure6.jpg

La technique des Cas d’utilisation (Use Case) est très populaire chez les praticiens UML. Son cadre d’utilisation s’applique au système à développer une fois celui-ci identifié. Son utilisation intervient donc après celle de la modélisation des processus métier, de la définition du dictionnaire, et de la description des règles métier. Par exemple, pour toute activité d’un processus métier qui utilise le système, on doit trouver un ou plusieurs cas d’utilisation permettant de la réaliser.

De nombreux ouvrages ont été publiés sur la mise en oeuvre du modèle des cas d’utilisation, assurant un support méthodologique bien documenté. L’avantage de la modélisation des cas d’utilisation est de permettre une définition externe du système, en identifiant les acteurs pouvant intervenir, et les grands cas de figure de mise en oeuvre du système futur. Un modèle de cas d’utilisation est structurant pour l’activité d’analyse, et pour la modélisation future en UML.

Le modèle des cas d’utilisation s’applique dans un contexte bien défini : le périmètre fonctionnel du système est identifié, et les exigences globales, les objectifs généraux du système sont connus. Son emploi doit se limiter à la découverte « gros grain » des cas d’utilisation, chaque fois associés à au moins un acteur externe, et réalisant à chaque fois une fonction complète (« transaction fonctionnelle »). Parfois, des modèles de cas d’utilisation dérapent en de véritables décompositions fonctionnelles des services du système, ce qui in fine nuira à une bonne modélisation et conception du système. Un modèle général de cas d’utilisation est compréhensible par tous, et peut permettre un cadrage et une validation générale, avant de poursuivre dans une description détaillée de chaque cas d’utilisation.

Ordonnancement de ces techniques de modélisation

L’ordonnancement précis de ces techniques de modélisation s’appuiera sur une méthodologie relevant du contexte de mise en oeuvre. Cela dépend du domaine d’application, de la taille et de l’importance du problème à traiter, et de nombreux autres facteurs. Fréquemment, seule une partie des techniques mentionnées est mise en oeuvre. Plusieurs types de représentation peuvent être construits en parallèle, par une démarche itérative.

La règle est de partir des aspects les mieux connus, les plus généraux, les plus immédiats et les plus stables, pour ensuite détailler progressivement, en recherchant constamment le consensus et l’appropriation des représentations par les autres intervenants. Il importe d’une part de procéder selon l’ordre « top down », en couvrant couche par couche l’intégralité du processus considéré, chaque couche correspondant à une modélisation plus fine que la précédente, et d’autre part de s’interdire de réaliser de façon prématurée une modélisation partielle et détaillée d’un aspect du processus.

Le dictionnaire peut toujours être défini en premier. Il permet de recueillir les définitions existantes sans apporter d’interprétation. L’analyse des besoins intervient également très en amont. Menée conjointement avec l’élaboration du dictionnaire, elle permet de cadrer la terminologie requise.

L’approche systémique offre le moyen de fournir rapidement une vision globale du système.

La définition des modèles conceptuels peut ensuite précéder ou être menée conjointement avec la modélisation des processus métiers. En effet, les processus exploitent les données. Ils se justifient par les produits réalisés, et permettent d’identifier la nécessité de certaines données intermédiaires. Les règles métier viennent enrichir les modèles conceptuels, et les modèles des processus. Les cas d’utilisation interviennent en dernier lieu, en détaillant ce que le système d’information doit effectuer au sein d’un système global.

Conclusion

Une pré-modélisation correctement construite fournit aux acteurs du SI une référence initiale sobre, stable et pertinente.

Le cadrage offert par ces techniques apporte à l’entreprise la maîtrise de ses propres concepts, de son propre langage, ainsi que la clarté sur les priorités : la documentation du dictionnaire, du référentiel, des règles métier, leur appropriation par les utilisateurs, leur validation par les dirigeants, précisent et stabilisent l’informatisation de l’entreprise, améliorent la qualité des réflexions sur son rôle et son évolution.

La pré-modélisation est ainsi à la fois une étape utile à la réalisation technique du logiciel, et une phase nécessaire à la maturité de l’entreprise en matière de système d’information. Intégrée à une démarche d’entreprise, elle assure une vision d’ensemble sur le système non technique et facile d’appréhension, pour permettre à tous d’être partie prenante.

Auteur: Philippe DESFRAY, Directeur Général Délégué, 

Techniques de pré-modélisation : stratégie pour éviter l’échec