urbanisation-si

urbanisation-si

Modélisation métier


Modélisation métier : méthode des processus métier orientés objectifs

modelisation-metier-diagramme-ishikawa.png

 

La méthode des processus métier orientés objectifs ( http://urbanisation-si.eklablog.com ) utilise les concepts du diagramme d’Ishikawa (plus connu sous le nom de diagramme d’arrêtes de poisson ou encore diagramme de cause à effet) qui consiste à identifier l’objectif final puis les sous-objectifs permettant de l’atteindre et ainsi de suite de manière récursive. 

Ne subissez plus les changements extérieurs, mais soyez en mesure de les accueillir à tout instant !

Les plus performants d’entre nous sont conscients du fait qu'avantage concurrentiel et service de premier ordre ne résultent pas de ce qu’on fait, mais de la manière de le faire. Et que les positions de force peuvent s’inverser rapidement du fait de l’évolution constante des environnements financier, réglementaire et métier. Le BPM (Business Process Management) permet une amélioration notable du retour sur investissement. Parmi les sociétés qui ont mis en œuvre des solutions de BPM :

• 100 % ont amélioré leur productivité,

• 95 % ont amélioré la qualité de leur service,

• 82 % ont réduit leurs coûts d’exploitation,

• 82 % ont réduit la durée de leurs cycles de traitement.

Le climat opérationnel actuel est très imprévisible. Les entreprises se préparent pour un type de situation, et c’est une autre qui se présente. Le coût de cette préparation (ou de l’absence de préparation) à des situations difficiles peut être extrêmement élevé. Une solution consiste à adopter la gestion des processus métier orientée objectifs permettant par la mise en œuvre d’une méthodologie efficace et de la technologie associée d’offrir aux entreprises toute la souplesse requise pour s’adapter aux environnements fonctionnels imprévisibles. Elle apporte d’énormes avantages, notamment :

• création plus rapide et à moindre frais des processus via la réutilisation des composants,

• implication des utilisateurs fonctionnels dans la conception des processus,

• contexte plus favorable pour le contrôle des processus,

• souplesse permettant de résoudre les problèmes au moment où ils se produisent, plutôt qu’après,

• possibilité d’adaptation dynamique aux nouvelles conditions de fonctionnement.

La méthode des processus métier orientés objectifs utilise les concepts du diagramme d’Ishikawa (plus connu sous le nom de diagramme d’arrêtes de poisson ou encore diagramme d’objectifs/sous-objectifs) qui consiste à identifier l’objectif final puis les sous-objectifs permettant de l’atteindre et ainsi de suite de manière récursive. A chaque sous-objectif va correspondre des composants de processus que l’on pourra réutiliser à la manière de composants objets ou de services dans SOA (Service Oriented Architecture). On peut ainsi réorchestrer le processus en appliquant des règles exécutées par un moteur. Les composants peuvent avoir des contraintes d’ordonnancement comme des tâches dans un projet classique ainsi que des durées maximales d’exécution.

Cette agilité suprême existe et n’est pas de la science-fiction mais pour réussir le projet et parvenir au retour sur investissement escompté encore faut-il une réelle implication de la direction capable de mobiliser et de fédérer tous les acteurs du SI.

 

"On ne possède jamais réellement les choses. On ne fait que les tenir un instant. Si l’on est incapable de les laisser aller, ce sont elles qui nous possèdent."
Antony de Mello

 

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/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


17/09/2015
0 Poster un commentaire

Modélisation métier : outils mindmap, mon préféré

outil-mindmap-freeplane-fonctions-2.jpg

 

On a vu dans l'article précédent : 

http://www.urbanisation-si.com/modelisation-metier-mindmap-ne-vous-perdez-plus-dans-votre-cheminement-de-pensee-mettez-de-l-ordre-dans-vos-idees

l'intérêt à utiliser les cartes mentales ( mindmap ) pour organiser, comprendre et mémoriser des concepts complexes et nouveaux. C'est généralement ce qu'on doit faire en ingénierie des exigences ou l'on doit modéliser les processus métier et identifier les besoins en adéquation avec la stratégie de l'entreprise.

C'est bien beau de faire des mindmap avec des crayons de couleur et une gomme mais c'est quand même mieux d'utiliser un outil informatique.

Parmi les outils open source gratuits, j'en ai retenu 3 :

Historiquement le 1er outil digne de ce nom a été FreeMind qui a imposé son format repris par l'ensemble des outils concurrents. L'outil est intuitif, ergonomique, on peut directement concevoir des mindmap sans lire de documentations rébarbatives.

Un fork, c'est à dire un groupe de développeurs de FreeMind est parti pour créer un concurrent XMind. Des fonctionnalités nouvelles ont été apportées et l'environnement a été légèrement relooké. Je trouve cependant que les 2 produits se ressemblent comme 2 frères jumeaux. Si vous tenez au standard autant prendre l'original, le vrai, l'unique FreeMind.

Je gardais le meilleur pour la fin, car ma préférence va à Freeplane. L'outil est 100 % compatible FreeMind, mais son ergonomie est nettement plus moderne. Il utilise tous les widgets tendances que l'on retrouvent dans l'ensemble des "clicodromes". La prise en main est immédiate.

Nous verrons prochainement différents métamodèles de mindmap glanés de ci de la sur internet pour pouvoir les transformer vers d'autres métamodèle comme KAOS, SysML, UML, ... 

 

"La vie est un défi à relever, un bonheur à mériter, une aventure à tenter."
Mère Teresa

 

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/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


08/09/2015
0 Poster un commentaire

Modélisation métier : Mindmap, ne vous perdez plus dans votre cheminement de pensée, mettez de l'ordre dans vos idées !

urbanisation-si-mindmap-definition-interet-1.png

 

Une des difficultés majeures de l'ingénierie logicielle est de comprendre les processus métier qui constituent le milieu dans lequel vont évoluer les futurs systèmes et de capturer les besoins des utilisateurs.

Le gouffre entre les métiers et les techniciens entraîne des incompréhensions de part et d'autre et donc de potentiels dysfonctionnements ou un mauvais alignement sur les exigences.

Il existe une technique éprouvée lisible par l'ensemble des protagonistes d'un projet, permettant d'organiser de nombreux concepts complexes : les Mind Map.  

Les Mind Map sont considérés, tant par le monde académique que par le monde industriel, comme de puissants outils pour l’élicitation des exigences.

L’ingénierie des exigences est reconnue comme un processus social qui se caractérise par des prises de décisions permanentes entre de nombreux participants (gestionnaires, utilisateurs finaux, et analystes du système).

Lors de la phase de recueil des exigences, le développement logiciel est plus un travail artisanal qu’une réelle discipline d’ingénierie. À cet égard, la cognitive humaine joue un rôle essentiel pour la compréhension des problèmes humains et organisationnels dans l’ingénierie des exigences, et sert à identifier les moyens d’amélioration de la qualité de la perception visuelle du modèle de spécification produit

Une Mind Map, encore appelée topogramme, schéma heuristique ou carte mentaleest un diagramme utilisé pour voir, classifier et organiser des concepts, ainsi que pour générer de nouvelles idées. Elle est utilisée pour connecter des mots, des idées et des concepts à une idée ou un concept central. Elle est similaire à un réseau sémantique ou à une carte cognitive, mais sans les restrictions sur les types de connections utilisées.

Toutes les Mind Map sont articulées autour d'un noyau central, elles mettent en œuvre des lignes, des symboles, des mots, des couleurs et des images illustrant des concepts simples et faciles à mémoriser. L'élaboration d'une Mind Map permet de transformer une longue liste de données rébarbatives en un diagramme attrayant, coloré, logique et hautement structuré, en harmonie avec le fonctionnement naturel du cerveau.

Une Mind Map est un diagramme radial qui, à l’aide d’un vocabulaire (c’est à dire d’un ensemble de mots-clés), peut représenter et modéliser de manière cognitive un concept ou un domaine spécifique.

Les principaux bénéfices de l’utilisation de ce type de représentation sont :

  • organisation des idées et des concepts,
  • mise en accent de mots significatifs,
  • association entre éléments d’une branche,
  • regroupement d’idées,
  • support à la mémoire visuelle et à la créativité,
  • déclenchement d’innovations.
  • rend plus facile pour l’esprit humain le traitement de l’information, tout en réduisant la charge cognitive nécessaire pour absorber les concepts du domaine et leurs objectifs.

La Mind Map constitue un miroir externe de votre propre réflexion naturelle, facilitée par un processus graphique puissant, lequel fournit une clé universelle permettant de débrider le plein potentiel du cerveau humain.

Les cinq caractéristiques essentielles d'une Mind Map sont les suivantes:

  • Le sujet ou thème de la Mind Map est symbolisé par une image centrale.
  • Les idées ou rubriques principales sont disposées autour de l'image centrale sous forme de branches.
  • Chaque branche s'accompagne d'une image-clé ou d'une expression-clé dessinée ou imprimée sur la ligne qui lui est associée.
  • Les idées périphériques sont représentées en tant que "rameaux" de la branche connexe.
  • L'ensemble des branches forme un arbre dont les nœuds sont liés les uns aux autres.

 

"L'homme sans patience, c'est comme une lampe sans huile."

Alfred De Musset

 

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/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


07/09/2015
0 Poster un commentaire

Modélisation de système : quand un analyste fonctionnel parle chinois avec un développeur

modelisation-metier-diagramme-etat-uml-dialogue-sourd.png

J'ai surpris un jour cette conversation téléphonique entre un analyste fonctionnel et un développeur.

Il essayait en vain de lui expliquer ce qui arrivait quand on annulait une annulation.

Tout le monde était plié de rire tellement cela devenait un dialogue surréaliste.

Du pure Devos ! Il était impossible de conserver le fil de pensée tellement les phrases étaient longues, pire que du Proust !

Cela ressemblait a peu près à ceci : "quand tu annules une annulation d'une ligne d'un dossier fermé, la ligne se réactive et peut passer dans l'état à traiter si avant d'avoir été annulée elle était calculée, mais si elle était révisée et si le batch est passé alors elle repasse à "à réviser" et sinon à "à payer" à moins que le gestionnaire ait demandé le calcul manuel, à ce moment là il faut demander la validation auprès du responsable de la gestion à moins qu'elle ait été bloqué et qu'on a forcé le calcul, ... , il ne faut oublier bien sur de ré-ouvrir le dossier ...

N'importe qui aurait perdu le fil au bout de la 2 ème ou 3 ème condition. Les capacités cognitives de l'esprit humain sont limités, d'autant plus si les règles sont énoncés par téléphone.

Comment une telle situation est-elle apparue ?

Par manque d'un langage formel de modélisation commun à tous les acteurs du projet, une sorte d'espéranto.

En l'occurrence ici, aucun diagramme d'état UML n'avait été réalisé.

Dans les spécifications Word, on avait certes la liste des états, dans certaines présentations Powerpoint quand on réussissait à mettre la main dessus, figuraient certaines transitions possibles mais sans les événements déclenchant les transitions donc inutilisables et en plus toujours incomplètes sur le plan des scénarios.

Un diagramme d'état permet pour une entité, de montrer toutes les transitions possibles entre ses états métiers, quels sont les événements produisant ces changements d'état et qu'elle est son comportement dans un état donné.

Cela n'a rien à voir avec un ésotérisme technique. Tout ce que représente le diagramme d'état relève bien du métier. 

Imposer l'utilisation d'un tel outil permet de se donner un cadre de pensée commun, de ne rien oublier et d'avoir sur un schéma (qui vaut mieux qu'un long discours, surtout au téléphone !) l'exhaustivité des transitions d'états avec leurs événements déclencheurs.

Le développeur aura alors un automate à états finis avec l'ensemble des règles sans aucune ambiguïté.

L'urbanisme du SI doit imposer entre autre que les transitions d'états complexes soient obligatoirement modélisées avec un diagramme d'état UML sans quoi on laisse la porte ouverte à l'imagination de chacun et la on peut s'attendre à tout !

 

"La règle d'or de la conduite est la tolérance mutuelle, car nous ne penserons jamais tous de la même façon, nous ne verrons qu'une partie de la vérité et sous des angles différents."
Gandhi

 

 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/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


09/07/2015
0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 9ème partie - Domaines métiers – UML – Diag. Package

 

blog-modelisation-uml-pack.gif

 

 

Détails Domaines métiers – UML – Diag. Package

blog-modelisation-uml-pack2.gif

 

L'urbanisme des Systèmes d'Information impose d'organiser la vue fonctionnelle en blocs autonomes communiquant par messages. Une zone avec un quartier spécifique pour les données à cycle de vie court (comme des prestations d'assurance) et un quartier référentiel de données pour celles à cycle de vie long (des produits commercialisés), doit être représentée dans le Plan d'Occupation des Sols (POS).du SI.

Si on zoom sur ces 2 quartiers, on obtient des diagrammes de classes modélisant les entités métiers (voir l'article sur le modèle métier dans la méthode ultime de modélisation des besoins). Ces entités métiers sont regroupées par appartenance à des domaines fonctionnels (référentiel Individus, référentiel contrats, domaine prestation, cotisation, ...). En UML on représente ces domaines métier par des packages.

Les packages peuvent contenir n'importe quels éléments UML (acteurs, cas d'utilisation, classes, ...) et il appartient au modélisateur de leur donner une sémantique. En modélisation métier ce sont bien sur les domaines fonctionnels et en conception ce sont les packages de compilation et d'exécution.

A part rassembler des entités d'un même domaine fonctionnel, le diagramme de package permet de représenter les dépendances.

Par exemple, le domaine contrat dépendra du domaine produits, le domaine prestation dépendra du domaine contrat, ...

Cette vue offre la possibilité aux experts métiers de vérifier les dépendances entre les domaines fonctionnels. Par exemple les référentiels constituent des socles, ils ne peuvent pas dépendre de domaines fonctionnels qui ne soient pas référentiels..

Ce modèle peut aussi faire apparaître les dépendances  bidirectionnelles ou cycliques (A dépend de  B ; B dépend de C et C dépend de A). Il faudra alors déplacer les entités ambigües situées aux frontières des domaines pour diminuer le couplage. On constate souvent qu'une dépendance entre 2 domaines peut être uniquement la cause d'une relation entre 2 entités situées dans chaque domaine. Cela aurait peut être un sens métier de déplacer une de ces entités dans l'autre domaine ce qui aurait pour effet de supprimer complètement la dépendance entre les 2 packages. En pratique il y a des entités pour lesquelles dés le départ on hésite à les mettre dans tel ou tel domaine. La bonne pratique est donc de les mettre dans le package qui aura pour effet d'introduire le moins de dépendance possible et surtout de supprimer les bidirectionnelles ou les interdépendances.

Le diagramme de packages est donc l'outil de base du cartographe dans la démarche d'urbanisation. La notion d'échelle est donnée par la hiérarchie de packages, limitée par les règles d'urbanisme à 3 ou 4 niveaux. 

Les packages permettent aussi de regrouper les exigences en domaines fonctionnels c'est ce que nous verrons dans un prochain article.

 

"La connaissance s'élabore en détruisant une connaissance antérieure."

Gaston Bachelard

 

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/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


14/05/2015
0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 8ème partie - Etats métiers – UML – Diag. Etats

blog-modelisation-uml-etat.gif

 

 

Détails Etats métiers – UML – Diag. Etats

blog-modelisation-uml-et2.gif

 

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


14/05/2015
0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe

blog-modelisation-diag-clas.gif

 

 

Détails Domaine métier – UML – Diag. Classe

blog-modelisation-metier-2.gif

 

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


13/05/2015
0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 6ème partie - Rule Flow – UML – Diag. Activité

Rule Flow – UML – Diag. Activité

blog-modelisation-ruleflow-.gif

 

 

Détails du Rule Flow – UML – Diag. Activité

blog-modelisation-ruleflow.gif

 

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. 

La bonne pratique consiste pour chaque tâche à associer des packages de règles, ce qui permet d’en ajouter/modifier/supprimer sans avoir à le faire dans les tâches, elles sont prises en comptes automatiquement. 
L'outil UML utilisé est le diagramme d'activité dans lequel est représenté les tâches (activités) et leur orchestration. L'AGL permet d'assurer la traçabilité entre les règles définies dans le modèle statique et les tâches. Il suffit de mettre des liens de dépendances entre les règles (ou les package de règles) et les activités. 
La vue traçabilité de l'AGL montre toutes les dépendances de manière bidirectionnels et des mesures d'impacts peuvent ainsi être effectuées.
Les règles du Plan d'Occupation des Sols de la vue fonctionnelle imposées par la cadre d'urbanisme du Système d'Information imposent de représenter le référentiel de règles métiers dans un quartier spécifique au coté de celui du référentiel de données métiers transverses situés tous les deux dans la zone référentielle. Faire cette modélisation des règles métiers systématiquement ajoute un peu de charge au départ mais tous les retours d'expérience prouve que l'on peut s'attendre à un retour sur investissement de l'ordre de 20%.

 

"Le commencement de toutes les sciences, c'est l'étonnement de ce que les choses sont ce qu'elle sont."

Aristote


12/05/2015
0 Poster un commentaire

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

blog-modelisation-regles.gif

 

 

Détails de Règles métiers – UML – Profil spécifique

blog-modelisation-regles-2.gif

 

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


11/05/2015
0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 4ème partie - Processus métiers - UML - Diag. Activité

Processus métiers - UML - Diag. Activité

urbanisation-si-blog-UML.gif

 

Détails du Diagramme d'Activité UML

blog-UML-diag-activite.gif

 

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.

 

Une première étape consiste à identifier l'évènement déclencheur et le but du processus. On détermine l'enchaînement des activités. 
blog-urbanisation-si-activite.png
Les activités sont représentées sous forme de graphe :
  • 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é
 
Nœud de décision :
blog-urbanisation-si-activite-decision.png
  • 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)
Activités parallèles
blog-urbanisation-si-activite-parallele-1.png
 
  • 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
Noeuds finaux

blog-urbanisation-si-activite-parallele-3.png

  • 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é.

 

Signaux
  • Envoi d’un signal : blog-urbanisation-si-activite-envoi.png
  • Réception d’un signal (événement) : blog-urbanisation-si-activite-reception.png
  • Événement de temps (peut être relatif) : blog-urbanisation-si-activite-at.pngblog-urbanisation-si-activite-after.png

Modéliser “Qui” exécute les tâches

blog-urbanisation-si-activite-partition.png

 

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.
 
Flot de données : identifier et modéliser  les objets métiers en entrées et en sorties des activités.
blog-urbanisation-si-activite-objet.png
Nœud d’objet
  • Représente un objet généré par une action et utilisé par une autre
  • Peut être nommé et typé
 
blog-urbanisation-si-activite-pin.png
On peut aussi utiliser les « pin » d’entrée et de sortie
  • Permet d’exprimer précisément les entrées et sorties
  • Permet d’exprimer la gestion des exceptions
Les entités métier sont des parties significatives de données manipulées par les acteurs métiers.
  • 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.
L’outil UML pour créer des modèles du domaine métier est le diagramme de classe (voir l'étape "3 - Domaine métier – UML – Diag. Classe" de la méthode ultime).
Lorsqu'on modélise les entrées/sorties des activités, il est alors aisé de se demander si l'état d'un objet a changé. On peut faire figurer l'état l'intérieur de l'objet entouré de crochets (voir plus haut Détails du Diagramme d'Activité UML). Concernant les états/transitions, le diagramme d'activité accentue la vue évènements/transitions qui sont représentés dans des rectangles alors que les états sont un peu cachés entre les crochets à l'intérieur de l'objet. Pour avoir une vue inverse et mettre en évidence les états représentés sous forme de rectangle et les transitions sous forme de flèche, il faut concevoir un diagramme d'états (voir l'étape "4 - Etats métiers – UML – Diag. Etats" de la méthode ultime).

Tout ceci peut paraître technique à la MOA. C'est la qu'elle entre en jeux. L'interface entre le fonctionnel d'une part et la modélisation/technique de rédaction d'autre part est réalisé par la MOAD.
La cellule urbanisme du SI doit édicter les règles de modélisation, les bonnes pratiques de cartographie et de documentation. Un "kit de démarrage" avec des templates et un exemple de projet déjà réalisé, permet aux nouveaux acteurs de s'approprier le cadre d'urbanisme. Entre vouloir trop modéliser et tout détailler ou bien au contraire de dire la modélisation ça ne sert à rien et on documentera quand on aura le temps", il y a comme toujours un juste milieu.
A vous de voir à comment régler le curseur.
 
"Il faut d'abord apprendre à vivre soi-même avant de faire la leçon aux autres !"
Fedor Dostoïevski

10/05/2015
0 Poster un commentaire