|
Un modèle exprimé doit décrire complètement le contenu
fonctionnel d’un programme informatique. Le langage UML, bien adapté à la
technologie objet, définit sur ce modèle des vues graphiques, ou diagrammes,
qui doivent être complétées par une documentation en langage naturel.
La réalisation du modèle doit progresser par étapes
caractérisées chacune par la confection d’un diagramme, la démarche procédant
par enrichissement progressif selon un ordre « top down ». Il ne convient pas de
bousculer l’ordre des étapes : il ne faut pas se lancer dans la modélisation
proprement dite sans disposer de l’expression de besoin, ni documenter les cas
d’utilisation avant d’avoir produit le diagramme d’activité etc. Chaque étape de
la démarche doit avoir été réalisée entièrement avant que l’on ne passe à la
suivante : l’une des erreurs les plus courantes en modélisation est de
s’engouffrer de façon précoce dans des travaux détaillés qu’il faudra détricoter
par la suite.
Il est nécessaire d’associer plusieurs techniques
informelles et formelles pour saisir les diverses facettes d’un problème sans le
dénaturer, puis pour le détailler dans un modèle central que l’on pourra préciser et
modifier jusqu’à l’implémentation. L'utilisation conjointe de ces diverses
techniques permet de s'adresser à des interlocuteurs qui diffèrent tant par la
forme de leur intuition que par le niveau de visibilité et de lecture des
modèles.
Il se peut que les contraintes que l’on découvre
lors de la réalisation de l’étape n de la démarche obligent à réviser les
résultats des étapes antérieures. Ainsi, alors que la démarche doit progresser
sans que l'on n'anticipe le travail à faire dans les étapes ultérieures, elle ne peut pas exclure les retours en arrière. Il faut
d'abord réviser l’étape la plus en amont parmi celles qui sont à revoir, puis
revenir vers l’aval jusqu’à l’étape en cours. Un modèle bien fait facilite ces
révisions : si la documentation est correcte, si les outils facilitent la
cohérence entre les diverses étapes, si le modèle est convenablement modulaire,
le travail nécessaire aux révisions reste raisonnable.
Le processus de réalisation du modèle peut se représenter
par la boucle suivante :
Chaque étape aboutit à un « livrable » spécifique qui
doit être dûment validé, ce qui évite l’effet de tunnel dans la
modélisation.
Une fois l’expression des besoins précisée et validée, il
convient d’établir en premier le dictionnaire du domaine considéré ; ensuite,
une approche systémique en fournit une vue globale. La définition des modèles
conceptuels peut accompagner la modélisation des processus métier,
enrichie par la prise en compte des règles de gestion. Enfin, les cas
d’utilisation détaillent ce que le modèle doit effectuer au sein du système
global.
Expression de besoin
Toute modélisation informatique doit partir d’une
expression de besoin écrite, claire, validée par les responsables.
Elle servira de référence tout au long de la réalisation du projet.
La première formulation de l’expression de besoin est trop
souvent inadéquate : le client dit qu’il a besoin de telle et telle
fonctionnalité, alors qu’il faudrait qu’il expliquât ce qu’il a l’intention de
faire, qu’il décrivît l’action qu’il s’agit de réaliser.
Lorsque l’expression de besoin part comme il se doit d’une action, elle comporte naturellement la description d’un
processus : toute action se ramène en effet à un processus (plus ou moins complexe
et ramifié) selon lequel, partant d’une situation initiale ou input, et par
l’application de certaines ressources, on aboutit à un résultat ou
output.
L’expression de besoin doit
essentiellement décrire l’input et l’output, la définition des ressources
relevant le plus souvent d’une étape ultérieure.
Il faut dire aussi ce qu’il conviendrait de faire en
cas de défaillance : la modélisation du processus doit comporter la description
des cas de panne et des solutions à adopter en régime dégradé.
Dictionnaire
Le dictionnaire rassemble les définitions des termes
relatifs au système considéré. On doit être tolérant lors du recueil de la
terminologie du métier et accepter de noter les homonymes et synonymes qui
coexistent dans l’organisation. Cependant la construction du modèle apportera une
réduction terminologique, en n’associant plus qu’un nom et un seul à une même
chose ou à un même concept : l'amélioration du vocabulaire est l’un des
apports de la modélisation.
Approche systémique
Il est utile de produire un schéma général, validé par les
acteurs, mettant en évidence les structures de l’entreprise impliquées, leurs
responsabilités et leur mode de coopération. La notion de « flot d’information »
introduite dans UML 2.0 est ici utile.
Règles métier
La notion de « contrainte » dans UML permet de modéliser
des règles de gestion qui autorisent, provoquent ou empêchent le déroulement
d’un processus (exemples : « une direction départementale ne doit pas comporter
plus de dix agences », « un client ne peut commander via le Web que s’il
a été enregistré au préalable », « un employé marié ne doit être muté qu’en
dernier recours » etc.)
Modélisation du processus
Décrire un processus, c’est décrire l’événement qui le
déclenche, les étapes (ou activités) par lesquelles il doit passer, les
ressources qu’il doit consommer et l’événement final auquel il doit aboutir. Ces informations sont rassemblées et documentées dans le diagramme d’activité
: il décrit la succession des activités, les messages qu’elles échangent, les
éventuels sous-processus et les livrables intermédiaires que ceux-ci fournissent.
Le diagramme d’activité est, des diverses vues sur le
modèle, la plus lisible et la plus facilement compréhensible pour les personnes
qui ne participent pas à son élaboration. Il joue donc un rôle important lors de
sa validation.
Cas d’utilisation
L’étape suivante consiste à décrire les cas
d’utilisation, chaque activité en comportant un ou plusieurs. Un cas
d’utilisation regroupe des opérations que l’acteur exécute et qui forment un
ensemble cohérent : recevoir des messages, consulter des données ou du texte,
saisir des données ou du texte, lancer des traitements, envoyer des messages. On
a défini le cas d’utilisation lorsque (1) on l’a nommé et désigné par sa
finalité au sein de l’activité, (2) on a décrit son contenu en définissant les
données consultées, saisies ou traitées, la nature des traitements, les messages
échangés, (3) on a identifié les composants applicatifs qu'il met en oeuvre au
sein du système informatique.
Il arrive que des cas d’utilisation divers comportent des
éléments semblables, ou qu’ils soient des cas particuliers de cas d’utilisation
plus généraux : on peut alors définir une hiérarchie de cas d’utilisation qui,
par abstraction, simplifie le modèle : c’est le diagramme des cas
d’utilisation.
Pour valider un cas d’utilisation, on présente aux
utilisateurs futurs une succession d’écrans simulant l’exécution du processus.
« Modèle métier » et « modèle complet »
La MOA est responsable du modèle métier, qui n’est
rien d’autre qu’une expression de besoin précise et ne considère les contraintes
techniques que de façon approximative.
Pascal Roques et Franck Vallée ont proposé le schéma en Y
de la modélisation.
La réalisation du modèle métier occupe la branche gauche ; la prise en compte
des contraintes techniques occupe la branche droite ; la réalisation du modèle
complet est la branche verticale.
Le modèle métier ne peut être que provisoire : il
arrive que l’on doive le réviser pour tenir compte des contraintes techniques ou
du coût que fait apparaître l’élaboration du modèle complet.
Quelle est l’utilité du modèle métier ?
Le modèle métier est susceptible d’être modifié par la
prise en compte des contraintes techniques. Est-il inutile pour autant ?
Supposer le modèle métier inutile, cela reviendrait à dire
que l’informatique peut travailler à partir d’une expression de besoin sommaire,
avec les ambiguïtés du langage naturel, et qu’il lui reviendrait de modéliser
les processus des métiers et de déterminer leurs concepts structurants.
C’est ainsi que les choses se sont passées lorsque
l’informatique équipait les grandes applications de support de l’entreprise
(paie, comptabilité, gestion des stocks etc.) qui, tout en étant complexes,
varient peu d’une entreprise à l’autre. Il ne peut en être de même lorsque
l’informatique pénètre les processus de production, lorsqu’elle équipe le cœur
de métier sur lequel l’entreprise possède des compétences spécifiques et
« pointues ».
La modélisation du processus prendra d’ailleurs des formes
diverses selon que celui-ci :
(1) met en œuvre un automate pur (cas du logiciel embarqué dans une machine),
(2) associe l’automate à des êtres humains pour mettre en oeuvre les procédures
internes à l’entreprise (back-office),
(3) reçoit des messages provenant d’acteurs externes, et qu'il faut transcrire
dans le système d'information de l'entreprise (cas de la
première ligne face à des clients, fournisseurs, partenaires),
(4) traverse les frontières de l’entreprise pour pénétrer chez des partenaires,
fournisseurs ou clients (interopérabilité).
En outre dans chaque cas il faudra tenir compte d’exigences
spécifiques de synchronisme, qualité des données et homogénéité des codages.
Considérons par exemple les processus qui prennent leur
source à la première ligne. La modélisation doit définir conjointement les
tâches qui reviennent à l’être humain et celles qui reviennent à l’automate. Un
des points délicats est alors de placer raisonnablement la frontière de
l’automatisation :
cela suppose une connaissance très fine des pratiques professionnelles.
La modélisation est par ailleurs pour un métier l’occasion
d’une réflexion sur les procédures et d’une révision des processus. Elle permet
de mettre à plat des habitudes qui se sont stratifiées dans l’histoire de l’entreprise et
dont certaines ont perdu leur raison d’être, de détecter et corriger des défauts
(bras mort où se perdent les dossiers, redondances, erreurs d’adressage etc.),
de rétablir la qualité des référentiels qui se dégrade toujours au long de
la vie de l’entreprise.
Il arrive même que la modélisation incite l’entreprise à relancer la réflexion stratégique
sur son positionnement, la diversification de son offre et la définition
de ses partenariats.
Ainsi s’élabore la pertinence de l’expression de
besoin, son adéquation aux besoins pratiques du métier. La mise en lumière des
priorités du métier permet d’apporter au modèle la
sobriété.
La restauration de la qualité des référentiels garantit la cohérence du
SI.
Ces qualités cruciales, observons-le, dépendent toutes
trois de la maîtrise d’ouvrage. Elles sont conditions nécessaires de la qualité
du SI – mais non conditions suffisantes : il faut encore que la faisabilité
technique soit élaborée par la maîtrise d’œuvre, qui doit vérifier si
l’automate pourra exécuter les opérations qui lui sont demandées et si
l’interopérabilité avec les autres entreprises sera assurée.
Le modèle métier devra donc être révisé pour tenir compte des
contraintes techniques et élaborer le modèle complet. Le plus souvent, les
modifications n’excèdent pas 10 à 20 % de la documentation du modèle métier, qui
n’est donc pas remis en question de fond en comble.
Il n’est donc pas inutile que la maîtrise d’ouvrage
produise le modèle métier : d’une part cela l’incite à tirer au clair ses
propres processus et priorités ; d’autre part, même si elle doit soumettre le
modèle métier à une critique portant sur sa faisabilité technique, cette critique
n’aboutit pas en général à la destruction d’une part importante du modèle.
Par la suite, le modèle métier
devra s'adapter aux évolutions de l'entreprise. Il est utile de distinguer ici
divers niveaux de stabilité. Les choix techniques ont le niveau de stabilité le
plus bas, car ils doivent évoluer rapidement pour assurer le maintien de
l'entreprise à l'état de l'art ; le découpage des domaines de légitimité de
l'entreprise, que l'on nomme souvent « organisation », un peu plus stable que
les choix techniques, est cependant évolutif. Le référentiel des données et des
notions que le modèle manipule, étant pour l'essentiel indépendant des choix
techniques comme de l'organisation, est la partie la plus stable du modèle et
sera le socle sur lequel on peut le bâtir.
Modélisation et évaluation du coût
L’évaluation du coût du projet progresse à mesure que se
précise la définition de celui-ci.
Considérons les étapes successives dans un cas type,
sachant qu’il est susceptible de variantes selon la taille du projet, la
maturité de la maîtrise d’ouvrage, la nature interne ou externe de la MOE etc. :
1) au début, l’expression de besoin n’est accompagnée
d’aucune évaluation du coût ; on peut tout au plus lui associer une indication
qualitative comme « petit projet », « projet moyen », « gros » ou « très gros ».
2) si l’expression de besoins passe le cap de la première
sélection, une « étude préalable »
est lancée. La maîtrise d’œuvre fournit alors, en s’appuyant sur son expérience
et sur des « règles de pouce », une esquisse de solution et une première
évaluation du coût. La marge d’erreur est de 50 % (si l’on estime le coût à 10
M€, le coût véritable se situera vraisemblablement dans une fourchette de 5 à 20
M€ : les deux bornes de la fourchette sont donc dans un rapport 4). Tout imprécise
qu’elle soit, cette estimation sert à évaluer la rentabilité du projet
(l’estimation des gains que l’on peut en attendre est d’ailleurs, à ce stade,
tout aussi imprécise).
3) Si l’étude préalable est convaincante, l’entreprise
lance la première modélisation, opération d’un coût significatif. La réalisation
du modèle complet permet de resserrer la fourchette d’évaluation :
- le modèle métier permet de mieux évaluer les gains ainsi que le coût de la
maîtrise d’ouvrage (formation, déploiement etc.) ;
- la prise en compte des contraintes techniques lors de la construction du
modèle complet permettent de mieux évaluer le coût de la réalisation.
Le modèle ainsi enrichi, comportant une évaluation plus précise des gains, des
coûts et de la rentabilité ainsi qu’un ou deux scénarios d’architecture,
constitue le cœur du cahier des charges de la réalisation.
4) Si l’entreprise décide de lancer le projet au vu du
modèle complet, la MOE consulte des entreprises. Leurs réponses permettront de
préciser encore le scénario d’architecture ainsi que l’évaluation du coût.
5) Il arrive enfin souvent que l’on soit contraint de réviser
l’évaluation du coût lors de la réalisation : on ne connaîtra vraiment celui-ci
qu’à la fin du projet.
L’évaluation du coût du projet est donc continue ; floue
dans les premières étapes, elle gagne progressivement en précision. Il est bien
sûr souhaitable d’utiliser des méthodes aussi rigoureuses que possible, un
« modèle de coût » étalonné et condensant l’expérience des informaticiens. Cela
ne supprime pas l’incertitude, mais cela peut la réduire et améliorer d’autant
la qualité des décisions relatives au lancement des projets. Il est d’ailleurs
salubre, lorsque les décisions sont prises sur la base d’une évaluation
imprécise, que cette imprécision soit considérée comme l’un des risques associés
au projet.
Voir
Outils pour la modélisation.
|
