Modélisation métier
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 8ème partie - Etats métiers – UML – Diag. Etats
Dans une modélisation métier digne de ce nom, les processus métier sont cartographiés avec le profil Eriksson Penker puis on zoom avec un diagramme d'activité montrant la séquence des activités. Pour chaque activité, on peut spécifier les entités en entrée et en sortie et pour une même entité ses changements d'états. L'aspect évènement ou transition est mis en évidence. Grace à cette vue, on peut se poser la question quel doit être l'état d'une entité en entrée de l'activité et quel est son état en sortie.
UML permet d'avoir différentes vues d'un système. Le diagramme d'état est l'inverse du diagramme d'activité dans le sens ou ce sont cette fois les états qui sont mis en évidences par des rectangles et les évènements/transitions par des flèches.
Le diagramme d'activité permet d'identifier les évènements (acte de gestion par exemple) et le diagramme d'état, les états d'une entité métier qui peut être déjà identifiée dans un diagramme de classe.
La MOA/MOAD ou les experts métiers ne doivent pas avoir peur du diagramme d'état après tout ne font-ils pas ces même diagrammes avec Power Point. Ne sont-ils comme M. Jourdain qui faisait de la prose sans le savoir, mais eux ne feraient-ils pas de l'UML sans le savoir ?
"Ferme tes yeux de chair pour contempler d'abord ton image avec l’œil de l'esprit."
Auguste Rodin
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe
L'urbanisme des Systèmes d'Information (SI) édicte comme règle que la cartographie fonctionnelle comporte une zone données. L'objectif est de modéliser les entités cœur de métier en faisant attention à rester au niveau macroscopique. Cela signifie de ne s'intéresser qu'aux concepts primaires comme par exemple une "Personne" et de ne pas retenir à ce niveau tout ce qui est secondaire comme "Adresse".
L'outil UML correspondant pour cette modélisation est bien évidemment le diagramme de classe mais utilisé avec parcimonie.
L'expert métier ou plus volontiers la maîtrise d'ouvrage déléguée (MOAD) ne doit représenter que les entités métiers (classes), les données (attributs) de ces entités, les relations (associations) et les cardinalités (multiplicités).
Et rien d'autres ! Tout les autres raffinements d'UML seront écartés et réservés aux étapes ultérieures plus techniques de la modélisation comme par exemple l'héritage en analyse et les méthodes en conception.
Attention toutefois à ce que ce formalisme ne soit pas rejeté par la MOA (cela ne concerne pas la MOAD qui par définition fait l'interface entre la MOA et la MOE et se doit d'être accompli dans l'art de la modélisation). Si dans le cadre d'urbanisme du SI ou d'un projet, les templates de modèles UML (modèle de modèle = méta-modèle), sont trop abstraits ou trop techniques, s'ils demandent trop d'effort, s'ils ne rentrent pas dans la culture de l'entreprise ou dans la politique de certains dirigeants qui confondent réussite personnelle et réussite du projet, on aura alors un risque non négligeable de rejet de la part des utilisateurs.
Le piège est d'être trop technique. Comme les utilisateurs ont souvent des préjugés erronés dans certains domaines, la clé de la réussite passera par l'omission des termes à connotation technique (UML, classe, objet, attribut, ...) et par leurs remplacements par des termes plus neutres et proches du jargon métier (cadre, entité, valeur, donnée, ...).
Cette méthode avec les outils l'accompagnant doit être conçue et appliquée dès le départ du projet (d'urbanisation du SI ou applicatif), avoir obtenu l'adhésion de tous les acteurs et bien sur cela va sans dire le soutien de la direction générale qui doit montrer sa totale implication.
"Quand on aime la vie, on aime le passé, parce que c'est le présent tel qu'il a survécu dans la mémoire humaine."
Marguerite Yourcenar
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 6ème partie - Rule Flow – UML – Diag. Activité
Dans un précédent article, nous avons vu l'importance de modéliser de manière statique les règles métiers en utilisant les profils qu'offrent les AGL.
Mais ce n'est que 50 % du travail car il reste la modélisation dynamique, c'est ce qui s'appelle le rule flow.
Le rule flow permet l’orchestration des règles c’est la partie qui varie le moins possible.
"Le commencement de toutes les sciences, c'est l'étonnement de ce que les choses sont ce qu'elle sont."
Aristote
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 5ème partie - Règles métier- UML - Profil spécifique
Le Plan d'Occupation des Sols de l'urbanisation des SI, considère les règles métiers comme un quartier à part entière dans la zone des référentiels de la cartographie fonctionnelle.
En effet, la formalisation sous forme de règles permet de capitaliser le savoir-faire des experts. Elle apporte aussi une standardisation et une auditabilité de ces règles « métier », facilitant leur consultation et leur maintenance par le plus grand nombre.
De plus si vous décidez dans l'architecture technique d'intégrer un BRMS (Business Rule Management System intégrant un moteur de règles) permettant d'automatiser l'exécution et l'enchaînement des règles, l'étape de "phase de conception / paramétrage du BRMS" est déjà réalisée. La définition des concepts métier en lien avec le modèle métier, du modèle de règles et de l'ordonnancement des règles seront modélisés dans le référentiel de l'AGL.
Cette modélisation métier d'un projet doit prendre en compte la représentation des règles de manière statique et dynamique.
Pour la partie statique, les règles sont modélisées par un stéréotype UML spécifique car le concept de règle n'existe en standard dans la norme UML. On peut alors utiliser toute la panoplie des relations qu'offre UML comme les associations, les agrégations, les compositions et l'héritage (on peut imaginer des règles abstraites "chapeau" permettant d'être factorisées dans des sous-règles).
Les règles sont très souvent ordonnancées dans un "rule flow" qui est ni plus ni moins qu'un diagramme d'activité UML ou chaque activité est liée à des règles. Pour passer à l'activité suivante, il faut que toutes les règles liées soient vérifiées. C'est la bonne pratique qui permet d'éviter de mettre des priorités dans un BRMS.
On verra dans le prochain article comment modéliser un "rule flow" dans un AGL ("Ruleflow - UML - Diag. Activité)
Une fois le "rule flow" modélisé, on assure la traçabilité entre les règles du modèle statique et les tâches du modèle dynamique avec des dépendances (voir le diagrmm ci-dessus : Détails de Règles métiers – UML – Profil spécifique).
Intégrer un BRMS avec un BPM (Business Process Managment ensemble d'outils de gestion de processus métier intégrant notamment un moteur de processus) permet de faire du routage dynamique dans un processus métier. Le moteur de règles ajoute encore plus d'agilité au moteur de processus.
La modélisation de règles métier fait partie des référentiels du Plan d'Occupation des Sols de la cartographie fonctionnelle et doit donc être réalisée au même titre que le modèle du domaine modélisant les concepts métier par exemple.
"Le temps d'apprendre à vivre, il est déjà trop tard."
Louis Aragon
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 4ème partie - Processus métiers - UML - Diag. Activité
Un processus métier est composé d'activités qui peuvent à leur tour être constituées de sous-activité. Le diagramme d'activité UML convient donc parfaitement pour la représentation des processus métier.
Tous les diagrarmmes UML sont génériques et peuvent être utilisés pour modéliser ce qu'on veut. Par exemple, le diagramme d'activité UML peut aussi bien être utilisé pour les processus métier de la discipline "Modélisation métier", pour la représentation d'un scénario d'un cas d'utilisation de la discipline "Expression des besoins" ou bien encore pour la représentation d'un algorithme de code de la discipline "Implémentation". Ces diagrammes n'ont pas le même niveau de granularité, de technicité, les buts diffèrent et les profils vont de l'expert métier non technicien au concepteur/développeur hyper pointu dans les dernières technologies.
Pour la modélisation des processus métier avec le diagramme d'activité UML, l'expert métier ou la MOAD (Maîtrise d'Ouvrage Déléguée qui possède à la fois les connaissances fonctionnelles et et techniques, un vrai métier en plein essor) ne doit pas utiliser tous les raffinements techniques complexes qu'offre UML.
- Les nœuds représentent des actions ou des activités
- Les transitions expriment le passage d’une activité à une autre
- Un nœud initial indique le début du flot
- Un nœud final (éventuellement plusieurs) indique sa fin
- Une activité peut éventuellement être structurée et composée de sous activités (symbole infini à l'intérieur du rectangle).
- Être décrite par un diagramme d’activité
- Peut éventuellement être sécurisé par une garde ou expression booléenne [else]
- Valide si aucune autre garde n’est valide
- Peut servir aussi de nœud de fusion (recevoir plusieurs transitions)
- Représentées par des chemins concurrents
- Utilisation de nœud de bifurcation / union
- Nœud de terminaison de flot
- L’activité continue pour les chemins concurrents
- Nœud final d'activité termine l'ensemble d'une activité. Tous les jetons qui arrivent sont détruits, et l'exécution de tout autre nœud est interrompue.
- Nœud final de flux termine un chemin partiel d'exécution mais pas l'ensemble de l'activité.
- Envoi d’un signal :
- Réception d’un signal (événement) :
- Événement de temps (peut être relatif) :
Modéliser “Qui” exécute les tâches
Les acteurs externes (clients, partenaires, ...) et internes (gestionnaires, vendeurs, ...) qui exécutent les activités sont représentés par des partitions verticales ou horizontales pouvant se décomposer en sous-partitions.
- Représente un objet généré par une action et utilisé par une autre
- Peut être nommé et typé
- Permet d’exprimer précisément les entrées et sorties
- Permet d’exprimer la gestion des exceptions
- Elles sont passives et ne créent par d'interactions spécifiques de leur fait propre.
- Elles peuvent être utilisées par plusieurs processus métier.
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 3ème partie - Processus métiers - BPMN
Le langage BPMN (Business Process Model & Notation) est une norme de l'OMG (Object Management Group) comme UML (Unified Modeling Language).
UML est un langage de modélisation générique avec lequel on peut tout modéliser à condition de bien maîtriser ses concepts et ses techniques d'extension alors que BPMN est un langage plus concret spécialement conçu pour les experts métiers afin qu'ils puissent représenter leurs processus métiers avec la terminologie qu'ils connaissent.
La modélisation des processus métiers avec UML (diagramme d'activité, ...) à toujours été rejetée par les experts métiers, trouvant UML trop technique et réservé à une élite d'informaticiens.
Un des objectifs de la norme BPMN est de faciliter la communication entre tous les acteurs impliqués dans un projet informatique tant au niveau cartographie des processus métier que sur le plan de la modélisation des besoins d'une application.
BPMN est censé être un véritable "espéranto"pour les processus métier depuis l'expert métier jusqu'au développeur.
Il permet d'avoir une représentation visuelle du fonctionnement d'un processus et ce, autant pour les expert métiers, les techniciens qui mettent en œuvre la solution technologique exécutant le processus et les utilisateurs, qui gèrent et contrôlent les processus.
Les éléments essentiels sont faciles à maîtriser. L'un des avantages du BPMN, c'est qu'il propose différents niveaux de compréhension ce qui permet de communiquer efficacement avec les équipes techniques qui, grâce à leur connaissance avancée du BPMN, sauront rajouter les éléments nécessaires pour rendre les processus exécutables.
Le BPM (Business Process Management) s'occupe de la gestion des processus comme un moyen d'améliorer la performance opérationnelle. Il existe des plate-formes logicielles permettant d'outiller la démarche BPM depuis la découverte du processus jusqu'à son optimisation via sa définition, son automatisation et son analyse.
La notation consiste en un ensemble de symboles graphiques représentant des actions, des flux ou des comportements dans un processus.
En version 2.0 tous les diagrammes BPMN ont une représentation normalisée XML, ce qui permet d'interpréter ces sources de code au moyen de moteur de processus exécutable.
L'expert métier peut dessiner son processus, décider des activités automatisées et humaines (gestion d'un workflow avec une corbeille de tâches) et ensuite le déployer dans le moteur de BPM pour être directement exécuter.
N'est ce pas la ce que tout le monde recherche depuis des années, pouvoir passer directement des exigences métiers à l'application sans être passé par les sacros saintes phases d'analyse, conception et implémentation.
"La vérité d'un homme, c'est d'abord ce qu'il cache."
André Malraux
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/
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 2ème partie - Processus métiers - Profil UML Eriksson Penker
En urbanisation SI, la vue métier représente les processus métier sur lesquels repose la stratégie de l'entreprise et la chaîne de valeur.
Dans le cadre de l'urbanisme SI, la bonne pratique est de représenter les processus métiers de manière macroscopique.
En UML (Unified Modeling Language, norme de l'OMG Object Management Group), il n'y a pas de diagramme spécifique pour les processus métier. Cependant UML est extensible avec parcimonie. En effet, les profils UML permettent d'ajouter des métas informations aux artefacts de modélisation existants sans en changer la sémantique. Ce concept offre la possibilité de concevoir de nouveaux éléments de modélisation dans des domaines spécifiques (SysML, Java, ...).
Le profil Eriksson Penker est un profil UML, un standard du marché (sans être une norme) pour la modélisation des processus métier.
Un profil est un ensemble de stéréotypes, de paire clés/valeurs (tagged/value) et de contraintes OCL (Object Constrait Language).
Un stéréotype est l'attribution d'un nouveau nom, d'une définition et d'un dessin à un artefact UML, lui ajoutant ainsi des informations supplémentaires ce qui permet d'étendre sa portée sémantique. Par contre la sémantique de base de l'artefact UML ne doit pas être changée sous peine d'avoir des aberrations les plus totales.
Le profil Eriksson Penker est une enveloppe du diagramme d'activité UML. En effet par définition, un processus est un ensemble d’activités composites ou élémentaires.
Un stéréotype d'une activité UML nommé <<Process>>, symbolisé par une flèche pleine dont la pointe représente la dynamique du processus et l'atteinte du but, permet de créer une cartographie à forte granularité .
L'acteur est au sens UML, une entité externe qui déclenche le processus. L'acteur peut être un humain ou un système.
L'évènement déclencheur se défini par la réception d'une entité ou est de type temporel avec l'arrivée d'une date ou l'expiration d'une durée.
Un stéréotype <<goal>> est défini pour le but du processus c'est à dire la raison principale pour laquelle on exécute ce processus.
Un autre <<outcome>> représente le résultat du processus, les nouvelles entités métiers créées en sortie.
Les entités métiers manipulées en entrée uniquement (lecture) et en entrée/sortie (lecture/modification) sont modélisées par les stéréotypes sur les relations de dépendance (<<input>>, <<uses>> et <<supply>>).
La sortie d'un processus devient souvent l'évènement déclencheur d'un autre processus.
Un AGL (Enterprise Architect, MEGA, CaseWise, Modelio, ...) gère un référentiel de modèles. La traçabilité est mise en œuvre avec les relations UML (dépendance <<trace>>, implémentation, ...). On peut ainsi vérifier par exemple comment est réalisé la stratégie. Pour un objectif stratégique modélisé dans l'AGL, l'outil montre tous les processus réalisant cet objectif. Pour un processus donné, on a tous les cas d'utilisation l'implémentant dans une application et ainsi de suite.
On pourrait se laisser à rêver d'assurer la traçabilité de tous les éléments de modélisation jusqu'aux modèles de code.
"Un bon maître a ce souci constant : enseigner à se passer de lui."
André Gide
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/
La modélisation métier permet de faciliter la compréhension des processus métiers afin d'être capable de les faire évoluer et de spécifier les besoins.
Modélisation métier : quelques conseils pour réaliser un glossaire dont plus personne ne pourra se passer.
- Construire le dictionnaire dès l’analyse du cahier des charges (et des autres sources de documentation)
- Se limiter à l’étude et à la terminologie métier
- Les modèles et leur description utilisent en priorité les termes du dictionnaire
- Le dictionnaire doit « vivre » tout au long du projet
- Les descriptions textuelles associées aux modèles et particulièrement celles des cas d’utilisation (libellé et description) doivent faire référence aux termes décrits dans le dictionnaire
- Le dictionnaire est un document de référence, qui fait foi au cours du projet
- On peut mener conjointement la constitution du dictionnaire avec l’élaboration des modèles : processus, use-case, … qui contribueront à l’alimentation du dictionnaire
- Sans négliger cette activité, il n’est pas non plus nécessaire d’y consacrer une charge trop importante.
Modélisation métier : on ne dira jamais assez toute l'importance du glossaire.
En urbanisation SI, quand il s'agit de modéliser les processus métiers et par la suite quand on passera à la vue fonctionnelle puis applicative il est primordiale d'avoir constituer un glossaire dignement outillé et constamment mis à jour. La réalisation d'un glossaire n'est pas une tâche que l'on donne à un jeune stagiaire pendant les vacances d'été à la fin d'un projet. C'est le ciment des projets et du SI de l'entreprise, qui servira à tous les acteurs MOA ou MOE et à toutes les activités d'urbanisation SI ou de réalisation projet. J'ai assisté maintes fois à des réunions entre experts métiers qui exprimaient leur désaccord sur tel ou tel aspect métier. En fait un observateur neutre se rendait bien compte qu'ils utilisaient les mêmes termes mais qu'ils en avaient des définitions différentes. Et les analystes qui tentent de trouver des solutions applicatives en utilisant des entités auxquelles ils ne donnent pas le même sens que les experts métiers. On utilise des termes métier, mais on sont les définitions précises unanimement reconnus et partagées par tous ?
Un glossaire est un outil de dialogue, informel, évolutif, simple à réaliser permettant d'établir et de figer la terminologie employée.
La structure consiste à préciser pour un terme sa définition, ses alias et par la suite dans la vue applicative à donner la correspondance informatique si l'entité à été informatisée.
La définition doit être précise, non ambiguë et peut exprimer des liens avec d'autres termes. Pour lever toute ambiguïté, on réalise un diagramme de classe UML. Des liens seront établis plus tard entre les termes du dictionnaire et les éléments de modélisation (package, classe, ...) du système.
Attention aux synonymes, aux polysémie.
Prévoir 3 colonnes : terme ; définition ; correspondance informatique.
Cette colonne permet la traçabilité entre le métier et les applications.
N'est ce pas la un début pour réduire l'incommunicabilité entre MOA et MOE ?
"Le véritable lieu de naissance est celui où l'on a porté pour la première fois un coup d'oeil intelligent sur soi même."
Marguerite Yourcenar
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/