urbanisation-si.com

urbanisation-si.com

Modélisation métier


Comment vérifier un modèle ? Exemple de simulation d’un processus métier BPMN

La simulation de modèle donne vie à vos modèles dynamiques grâce à une exécution instantanée et en temps réel. 
Couplé avec des outils pour gérer les déclencheurs, les événements, les contraintes, les règles, les points d'arrêt et les variables de simulation, ainsi que la possibilité de suivre visuellement l'exécution, le simulateur est un moyen puissant de regarder les roues tourner et de vérifier l'exactitude de vos modèles. 

 

theorie-modelisation-simulation

 

(“Theory of Modeling and Simulation” Bernard P. Zeigler)

 

Objectifs de la simulation de modèle

Le principe fondamental de la simulation de modèle est la séparation du modèle et du simulateur. 

 

Le simulateur est défini comme un moteur de règles qui, en fonction d’un référentiel de règles, exécute un modèle qui sert à l’analyse du comportement. 

La relation de simulation permet de vérifier qu’en obéissant aux règles définies dans le modèle de simulation, le simulateur reproduit le comportement spécifié.

Le cadre expérimental spécifie les conditions d’observations du système et les objectifs de la simulation. 

Le système source (le système à modéliser) est une spécification et il peut être réel ou virtuel : il constitue la source de données observables.

Ces données observables forment la base de données de comportement. 

La relation de modélisation permet ainsi d’établir la validité de l’expérience.

 

La simulation a comme objectifs de :

  • tester une hypothèse du modèle du système de référence, de le vérifier ou d’accréditer la théorie qui a servi à le construire,

  • montrer l'aspect dynamique du système de référence,

  • comprendre le fonctionnement du système de référence, en considérant le modèle comme une réplique miniature, qui pourra être étudiée plus facilement,

  • prévoir les évolutions possibles du système de référence en fonction d’évolutions ou de perturbations spécifiques,

  • reproduire artificiellement le fonctionnement d’un système,

  • valider ou d’invalider des hypothèses, 

  • obtenir des informations quantitatives,

  • valider certaines approximations, 

  • évaluer la sensibilité d’un modèle à certaines hypothèses ou à certains paramètres,

  • explorer le comportement d’un système lorsque celui-ci est mal connu ou incompris.

 

 

BPSim

Le WfMC (Workflow Management Coalition) a réalisé la norme BPSim. 
Il définit une spécification pour le paramétrage et l'échange de données d'analyse de processus permettant l'analyse structurelle d'un modèle de processus, permettant l'optimisation de la pré-exécution et de la post-exécution.

BPSim se compose d'un métamodèle et d'un format d'échange pour faciliter la sauvegarde et le transfert de ces données entre différents outils.
Le métamodèle BPSim est réalisé en UML et le format d’échange en XSD.

 

 

Exemple pratique de simulation d’un processus BPMN avec l’outil Enterprise Architect

Environnement prérequis


JRE/JDK Java 8 (version supérieure non testée).
Enterprise Architect (EA) 15.2 (version d’évaluation Ultimate) Sparx Systems

 

 

Modèle BPMN utilisé dans notre illustration de simulation

Conception du modèle BPMN dans EA

Le but est d’illustrer concrètement une simulation BPSim, le modèle BPMN inclut les éléments les plus utilisés sous forme générique.

Comme nous l’avons vu en théorie, on doit relier le simulateur externe au modèle.

Avec EA, il  suffit que le modèle BPMN et l'artefact "Business Process Simulation" de la toolbox se trouve dans un même package. Ainsi à l'exécution de cet artefact correspondant au simulateur, EA trouvera automatiquement le modèle BPMN. 

 

1) Créer un nouveau projet, par exemple “bpsim-simulation-bpmn.eapx”.

 

2) Puis, dans le “root node Model ”, créer un package (clic droit Add View, Package Only), par exemple “BPSim-Simulation-BPMN”.

 

3) Dans ce package, clic droit, Add Diagram, Type : BPMN, BPMN 2.0, Diagram Types : Collaboration.

Au message, sélectionner “Create this Diagram within a new Collaboration Model”, conserver le nom par défaut.

 

Pour cette démonstration, nous prendrons un modèle BPMN générique, comportant 2 pools (P1 et P2), envoi et réception de messages entre les 2, et à l’intérieur de chacun, des séquences d’activités avec des gateways, ce qui peut déjà correspondre à bons nombres de cas réels :

 

modele-bpmn-utilise-pour-la-simulation-bpsim

 

 

Illustration pratique de la simulation

Objectifs

Pour cette illustration BPSim, nous prendrons un entier n, initialisé à 10 au début et qui sera modifié par les activités en ajoutant des valeurs constantes.

 

Les branches des gateways exclusives seront des conditions selon que n soit supérieur ou égal ou bien strictement inférieur à une valeur donnée.
Pour visualiser le chemin parcouru et les activités traversées, nous initialisons le simulateur avec un contrôle de type TriggerCount.
Le TriggerCount définit le nombre de fois que l'objet ou le connecteur doit être traité pendant une exécution de la simulation, de sorte que le cycle de traitement correspond à la demande type pour une chaîne d'actions particulière.

Il est généralement défini pour les éléments Start Event.
Ce TriggerCount définit le nombre de fois que l'élément ou le connecteur doit être traité dans une simulation normale ou personnalisée.

La matérialisation des artefacts activés par la simulation se fait par l’affichage en rouge de la valeur du TriggerCount sur chaque élément traversé. 

 

Création du simulateur BPSim

On a vu précédemment qu'il faut ajouter l'artefact "Business Process Simulation".

 

Sélectionner le package “BPSim-Simulation-BPMN” > Toolbox > Artifacts > Drag & Drop de "Business Process Simulation" dans le package, laisser le nom par défaut > double cliquer dessus pour ouvrir la fenêtre “Configure BPSim”

 

business-process-simulation-fenetre

 

 

L’onglet “Configure” est sélectionné, laisser les valeurs par défaut. 


Ces valeurs représentent :

  • la date de démarrage,
  • la durée qui doit être supérieure à la durée estimée, ici 999 Days, 
  • l’unité de temps (ici minute),
  • le nombre de réplications (1), 
  • la valeur d’initialisation du générateur aléatoire (n’est pas utilisé ici),
  • le langage d’expression (XPath) pour analyser le XML représentant textuellement le modèle BPMN grâce à la norme XMI,
  • les répertoires d’installation de Java 8 (JRE/JDK),
  • le port de communication du simulateur (1799), attention à que ce port ne soit pas déjà occupé.
  • un timestamp.

 

Paramétrage des éléments de modélisation

Dans le pool P1

1) Sélectionner Debut1 > Configure BPSim > onglet Configure > Category > sélectionner Control > dans la colonne à coté Parameter, sélectionner TriggerCount > et enfin dans la colonne Values, saisir 1

 

configuration-debut1-TriggerCount

 

2) Ajouter une propriété n de type entier (int)

Cliquer sur l'icône "Properties" > New Property, saisir n, puis dans Type, sélectionner int

 

configure-bpsim-configure-propriete

 

3) Sélectionner Debut1 > Configure BPSim > onglet Configure >

Category > en dessous de Control, New Parameter, sélectionner Property > n > pour la valeur, cliquer sur le bouton … à droite,  saisir 10 dans Expression

 

configuration-debut1-property-n

 

 

4) De la même manière, sélectionner Activite1 et compléter les 3 colonnes :
Property > n > Values > …. > Expression {n} + 100

 

5) Sélectionner le sequence flow de Passerelle1 à Fin1 
Control > Condition > Values > …. > Expression {n} >= 50

 

6) Sélectionner le sequence flow de Passerelle1 à Fin2 
Control > Condition > Values > …. > Expression {n} < 50

 

Dans le pool P2

7) Sélectionner Activite2 :
Property > n > Values > …. > Expression {n} + 10

 

8) Sélectionner le séquence flow de Passerelle2 à Activite3 
Control > Condition > Values > …. > Expression {n} >= 15

 

9) Sélectionner le séquence flow de Passerelle2 à Activite4 
Control > Condition > Values > …. > Expression {n} < 15

 

10) Sélectionner Activite3 :
Property > n > Values > …. > Expression {n} + 10

 

11) Sélectionner Activite4 :
Property > n > Values > …. > Expression {n} + 1

 

Sauvegarde de la configuration

Cliquer sur l’icône disquette.

 

Pour vérification, cliquer sur l’icône Property (point bleu), vous devez obtenir toutes les propriétés et les conditions appliquées sur les différents éléments du modèle BPMN :

 

fenetre-proprietes-et-conditions-de-la-simulation-bpsim

 

 

Exécution de la simulation BPSim

Dans la partie “Configure BPSim”, sélectionner l’onglet Execute, puis la première icône en dessous à gauche (Run Simulation)

 

 

execution-de-la-simulation-bpsim-du-modele-bpmn

 

Une fois la simulation terminée, vous pouvez arrêter l'affichage, en cliquant sur l'icône représentant un carré (Stop). L'affichage des "TriggerCount" disparaît.

 

Explication :

 

EA indique les éléments activés, accompagnés d’un "1" rouge (TriggerCount 1) et en sombre les autres.

 

Si l'on vérifie manuellement :

  1. P1
  2. n = 10 on envoie n dans P2
  3. Activite1 n = 10 + 100 = 110
  4. P2 reçoit n = 10
  5. Activite2 n = 10 + 10 = 20
  6. Comme n >= 15, on arrive dans Activite3 : n = 20 + 10 = 30
  7. On envoie n dans P1
  8. P1 reçoit n = 30
  9. Comme n < 50, on termine dans Fin2.

 

Exécution pas à pas de la simulation

 

Pour suivre pas à pas l'exécution de la simulation à des fins par exemple de mise au point, il suffit de sélectionner l'onglet Step, pour trouver les boutons de démarrage, d'avancement, de pause et d'arrêt.

 

On peut aussi (3 ème icône en partant de la droite), générer un diagramme de timing et juste à coté, celle pour générer un fichier CSV.

 

A noter que l'onglet Review permet de générer des rapports.

 

 

execution-pas-a-pas-de-la-simulation-bpsim-du-modele-bpmn

 

Validation du modèle BPMN

A côté de la disquette, on peut cliquer sur l’icône de validation, ce qui ouvre un nouvel onglet “System Output”

 

validation-de-la-simulation-bpsim-et-du-modele-bpmn

 

Conclusion

Le simulateur BPSim d’Enterprise Architect nous a permis de voir concrètement une exécution d’un modèle auquel on a associé aux éléments des propriétés, instructions et conditions.

Bien sûr, le simulateur d’EA possède de nombreuses distributions de probabilités (Binomial, Erlang, Gamma, Normal, Poisson, TruncatedNormal, Uniform…) permettant d’avoir des scénarios proches de la réalité.Les ressources, rôles (acteurs), peuvent être associées à des minis-écrans interactifs. 

Enfin, des calendriers permettent de planifier et gérer les durées et le déclenchement des activités pour plus de réalisme.


Le simulateur supporte aussi la norme DMN (Decision Model and Notation) pour la modélisation des règles métier.

Et pour être complet, on pourrait simuler un processus BPMN avec des tâches de type “Business Rule” qui seraient par exemple un modèle DMN avec des tables de décision et des règles de calculs.

 

N’hésitez pas à partager votre expérience sur le sujet de la simulation BPMN et à nous dire quels outils vous utilisez en postant un commentaire à la fin de cet article.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 


Il dit non avec la tête
mais il dit oui avec le cœur

et malgré les menaces du maître
sous les huées des enfants prodiges
avec les craies de toutes les couleurs
sur le tableau noir du malheur
il dessine le visage du bonheur.

 "Le cancre", Jacques Prévert

 

 

Pour en savoir plus sur 

BPMN

BPMN 2 : les concepts de base des processus métiers

 

BPMN pour les nuls : les collaborations

 

BPMN : l'antisèche pour rester incollable en modélisation de processus

 

BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

 

BPMN

 

 

DMN

DMN - L'antisèche de la notation complète des composants d'un DRD (Decision Requirement Diagram) : notation de la décision

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions

 

DMN

 


01/12/2022
0 Poster un commentaire

Méta-physique ? Non, méta-modélisation !

La sortie récente de la version 5 du Camunda Modeler, permettant de modéliser les processus métier avec la notation BPMN, nous donne l’occasion de faire un rappel sur la notion de méta-modèle, qui se cache souvent derrière le modèle.

 

four-russian-dolls

 

Un méta-modèle pour quoi faire ?

 

3U

 

Les 3U pour la Modélisation, l’Exécution et le Pilotage d’un processus métier

 

  • Un modèle est Utile.
    Si vous n’en êtes pas convaincu, alors vous ne butinez pas sur le bon site ! Car la mise en œuvre de l’Urbanisation du Système d’Information et de l’Architecture d’Entreprise avec méthode, pour une entreprise agile et résiliente, prônée par urbanisation-si.com, est basée sur la modélisation.

 

  • Un modèle doit être Utilisable.
    C’est cet aspect d’un modèle qui est détaillé plus bas dans cet article et qui s’appuie, selon nous, sur la normalisation grâce à un méta-modèle. Et cela permet de passer éventuellement de la modélisation statique à la modélisation dynamique.

 

  • Un modèle est-il Utilisé ?
    Un modèle de processus métier peut être directement utilisé avec la plate-forme adéquate. Souvent, il est toutefois nécessaire d’ajouter quelques artefacts, comme des formulaires de saisie.
    Utiliser un modèle reste la manière la plus efficace de s’assurer que la pratique du processus métier correspond à la théorie. Le modèle de processus est alors indissociable de la réalité. Le processus métier va pouvoir être piloté.
    Un dispositif optionnel comme le BAM – Business Activity Monitoring – permet de compter le nombre d’instances d’un processus métier (combien sont terminés, combien sont en cours, combien sont en erreur, etc.) et de mesurer leurs durées.

 

 

Utilisabilité d’un modèle

 

Intéressons nous plus particulièrement ici à l’utilisabilité d’un modèle. L’utilisation d’un langage ou une notation de modélisation normalisée facilite la réalisation, le partage, la compréhension d’un modèle. Ceci est particulièrement vrai avec la notation BPMN, qui permet notamment aux analystes métier et aux informaticiens de partager des modèles de processus métier et permet même directement leur exécution grâce à un BPMS.

 

Pyramide de modélisation

 

Concernant les langages et les notations de modélisation, la normalisation ne s’appuie pas seulement sur la publication de spécifications détaillées, pour diffuser et partager les éléments de représentation : elle repose également sur un système pyramidal complexe, mais cohérent, de (méta) modélisation.

 

PyramideModélisation

 

La pyramide de modélisation de l’OMG

 

La largeur de chaque niveau est proportionnelle à son nombre d’occurrences. En fait, le nombre d’occurrences se réduit de façon drastique quand le niveau augmente.

 

Niveau M0 : C’est le monde réel (ou imaginé), constitué d’instances qui doivent être représentées par le modèle de niveau 1. Si l’on veut représenter les êtres humains, cela fera plus de 7 milliards d’instances.

 

Niveau M1 : C’est le modèle que nous connaissons tous. Ce modèle représente généralement une partie du monde réel, par exemple, un diagramme de collaboration BPMN qui représente un processus métier. Ce modèle peut également représenter un système qui n’existe pas encore). Il existe sans doute dans le monde entier des centaines de milliers de modèles.

 

Niveau M2 : Le méta-modèle est beaucoup moins connu. Les modèles utilisant un langage ou une notation normalisée respectent généralement un méta-modèle. Tous les langages et notations de l’OMG – Object Management Group – notamment sont fournis avec un méta-modèle. Par exemple, celui de la notation BPMN. Ce méta-modèle est surtout utilisé par les éditeurs de logiciel. Il existe plusieurs dizaines de méta-modèles.

 

Niveau M3 : Le méta-méta-modèle est encore moins connu. Il fixe les règles de représentation des méta-modèles. Il existe très peu de méta-méta-modèles : je n’en connais que deux Ecore et MOF.

 

Pas de niveau M4 : A nos lecteurs qui seraient taraudés par l’idée qu’un méta-méta-méta-modèle (oui, je compte le nombre de « méta » sur mes doigts) serait sans doute nécessaire pour fixer les règles de représentation des méta-méta-modèles, soyez rassurés ! En effet, les méta-méta-modèles possèdent une caractéristique appelée méta-circularité, qui leur permet de se définir eux-mêmes. « Seulement » 4 niveaux numérotés de 0 à 3, donc.

 

Pas de méta-modèles dans les applications de dessin

 

Vous pouvez réaliser un diagramme de collaboration BPMN avec l’application Microsoft PowerPoint (vous trouverez quelques formes simples dans la section Organigrammes), mais vous serez rarement certain que votre modèle BPMN est conforme au méta-modèle. En effet, PowerPoint est, pour la partie graphique, une simple application de dessin qui vous permet d’agencer puis de relier les symboles BPMN n’importe comment. Parmi les applications Microsoft, il vaudra mieux utiliser Visio Professionnel pour réaliser des diagrammes BPMN sérieux, car validés par le méta-modèle BPMN.

 

Utilisation du méta-modèle

 

Les vraies applications de modélisation utilisent le méta-modèle de deux façons différentes :

 

  • En temps réel, pour déduire automatiquement la nature de certains éléments de modélisation. Ainsi, avec un outil de modélisation BPMN, quand on relie deux tâches, la connexion se fera automatiquement avec un flux de séquence (trait plein) si ces deux tâches sont dans le même pool ou bien avec un flux de message (trait pointillé), si ces deux tâches sont dans deux pools différents,

 

  • A postériori, pour valider le modèle avec le méta-modèle. La plupart des outils de modélisation BPMN disposent d’une fonction de validation du modèle et il est fortement conseillé de l’utiliser, afin de ne partager que des modèles valides, ce qui contribue grandement à la compréhension et à la diffusion d’un langage ou d’une notation normalisée.

 

Bonnes pratiques

 

Certains outils vont plus loin que la validation avec le méta-modèle. Signavio Process Manager par exemple peut vérifier également si les bonnes pratiques sont bien appliquées, en l’occurrence celles définies dans le livre de référence de Bruce Silver : BPMN method and style: with BPMN implementer’s guide (2. edition), Cody-Cassidy Press (2011).

 

Le sens critique des utilisateurs humains est toutefois toujours nécessaire pour peaufiner la modélisation. Par exemple, il est recommandé que chaque tâche soit renseignée avec un verbe d’action, suivi d’un complément d’objet direct (Exemple : Préparer commande). Le validateur contrôle que chaque tâche est renseignée (c.-à-d. non vide), mais n’effectue pas une analyse syntaxique du contenu.

 

Validation BPMN avec Camunda Modeler

 

Camunda Modeler, outil gratuit et largement utilisé, dont nous apprécions la facilité d’installation, même quand on ne dispose pas des droits Administrateur sur son PC, ne dispose pourtant pas d’une fonction de validation. Les utilisateurs motivés pourront remédier à cette lacune en installant le module d’extension Linter.

 

Il convient, en plus du Camunda Modeler, d’installer git et node.js, puis à partir du sous-répertoire ..\camunda-modeler\resources\plugins\, de lancer la commande suivante pour installer ce module :

npx degit github:camunda/camunda-modeler-linter-plugin camunda-modeler-linter-plugin

 

Dans le menu Plugins de Camunda Modeler, il suffit d’activer BPMN Linter qui effectue la validation en temps réel. Les erreurs les plus courantes sont alors aussitôt signalées et affichées directement sur l’élément concerné. Mais il est parfois préférable d’attendre la fin de la modélisation (on peut désactiver provisoirement BPMN Linter).

 

BPMN_KO

 

BPMN_OK

Diagramme de collaboration BPMN réalisé avec Camunda Modeler et le plugin Linter

 

Conclusion

 

Ce principe général de méta-modélisation, illustré dans cet article avec la notation BPMN, s’applique à d’autres notations et langages, notamment UML. Pour passer facilement de la théorie à la pratique, il suffit d’avoir un outil de modélisation adapté, qui va masquer la complexité du méta-modèle, grâce à sa fonction de validation des diagrammes notamment.

 

Thierry BIARD

 

“Il importe en peinture, que le portrait ressemble au modèle, mais non pas le modèle au portrait.” (Paul-Jean Toulet)
(Note de Thierry Biard : Il est amusant de noter qu’en peinture, sculpture et photographie, le modèle est le personnage du monde réel lui-même et non sa représentation – le portrait)

 

Compléments de lecture

MOF - ECORE - MDA

Métamodèle TOGAF - ArchiMate

Application des métamodèles

Les critères d'un bon modèle

   


01/06/2022
0 Poster un commentaire

Le PILI était-il un bon modèle ?

En fin d’année 2021, la RATP a mis en vente aux enchères du mobilier réformé, au profit d’une œuvre caritative (belle initiative). Parmi les 215 lots mis en vente figuraient quatre PILI :

Panneaux Indicateurs Lumineux d’Itinéraires.

Rien à voir avec la sauce piquante à base de piment pour relever le goût de votre pizza, donc.

 

image003

 

Lorsque j’étais enfant, j’aimais beaucoup appuyer sur l’un des 300 boutons chromés, un pour chaque station de métro de destination, afin d’allumer l’itinéraire le plus direct pour s’y rendre (à partir de la station où je me trouvais) :

 

image004

 

Positionnées sur le plan du métropolitain parisien, plus de 300 ampoules et, derrière ce plan, sans doute plusieurs kilomètres de câble électrique !

 

Après l'évocation de ce bon souvenir, empreint de nostalgie, la déformation professionnelle a rapidement repris le dessus :

Le PILI était-il un bon modèle ?

Voici une définition concise : un bon modèle doit représenter au mieux une partie du monde réel.
Sur quels critères plus précis peut-on s'appuyer pour déterminer un bon modèle ?

 

En 2017, j’avais publié une liste de 7 critères établie par Mader et al. 2007 pour qualifier un bon modèle :

 

- Il a un objet de modélisation clairement spécifié :

Oui, modéliser le réseau du métropolitain parisien.


- Il a un objectif clairement spécifié :

Oui, afficher l'itinéraire le plus rapide pour se rendre d'une station à une autre.


- Il est simple (le critère le plus difficile ?) :

Oui, pas besoin de mode d'emploi. Un seul "clic" sur le bouton de la station de destination suffit.

 

- Il est véridique :

Oui, la réalité du terrain est bien représentée.

(les ampoules pour représenter les différentes correspondances d'une seule station sont toutefois décalées. Exemple ci-dessus : Châtelet Les Halles)


- Il est traçable :
Oui, mais ce critère n'est pas primordial ici (peu d'évolutions du réseau)


- Il est extensible et réutilisable :

Non, le PILI n'était pas extensible : difficile d'ajouter une nouvelle station, voire une nouvelle ligne.

Par contre, il était réutilisable : près de 200 PILI furent déployés (soit dans 2 stations de métro sur 3)

 

- Il est conçu pour l’interopérabilité et le partage :

Non pour l'interopérabilité : pas d’actualisation possible pour signaler un incident ou une station fermée

Oui pour le partage : les PILI connurent un grand succès populaire, sans doute grâce à leur simplicité.

 

Les PILI obtiennent une note de 6/7 avec cette liste de critères ! Belle performance. 

 

Les PILI possédaient d'autres propriétés :

  • Maintenance très délicate en cas de panne,

mais malgré cet inconvénient, apparemment gérable :

  • Longévité exceptionnelle, de 1937 à 2016 approx.
    (sans doute liée à la stabilité du réseau)

 

Qui d'autre conçoit des modèles compris par les utilisateurs finaux
et utilisés pendant presque 80 ans ?image002

Panneau métropolitain de style Guimard

 

Il y a quelques années, la RATP avait repris le principe du panneau interactif sur son site web : le plan complet du réseau s’affichait et il suffisait de poser le pointeur de sa souris sur une ligne pour que leurs autres lignes s’estompent aussitôt.

 

Aujourd’hui, ce plan complet est complètement statique... Et chaque ligne (avec ses stations et ses correspondances) s’affiche désespérément à l’horizontale, sans rapport avec la réalité du terrain :

 

Plan metro ligne 4, agrandir le plan

La réponse est donc oui, le PILI était un bon modèle

Sans aucun doute meilleur que le modèle actuel publié sur le site web.

 

 

Malgré leurs caractéristiques impressionnantes (hauteur : 160 cm ; largeur 185 cm ; poids : 120 kg) nécessitant un grand salon, ces quatre PILI - sans aucune garantie de bon fonctionnement - ont tous trouvé acquéreurs à des prix compris entre 2.650 et 2.850 € ! Le prix qu’une très grande TV 4K UHD.

 

L’un des rares inconvénients du PILI, présenté dans le post ci-dessus, était son manque d’interopérabilité : pas d’actualisation possible pour signaler un incident ou une station fermée. Cet inconvénient a disparu grâce aux sites web, aux applications mobiles et aux réseaux sociaux : il est possible désormais d’actualiser rapidement les informations auprès des usagers (info trafic). Mais cette possibilité ne conduirait-elle pas vers certains excès ? Voici un exemple, réel et extrême.

 

Le 21 septembre 2022, des travaux sur la ligne D du RER ont entrainé la fermeture de 8 stations. Une douzaine de bus, voire le RER C, étaient proposés pour se substituer au RER D. Voici le plan avec les itinéraires de substitution qui ont été proposés aux usagers sur le réseau social Twitter :

  

PILI-vs-application-mobile

 

Plusieurs qualificatifs, la plupart flatteurs, peuvent s’appliquer à ce plan : spectaculaire, coloré, exhaustif, détaillé, précis, voire extravagant, limite usine à gaz, non ?

 

Par contre, euh, comment dirais-je : il valait mieux ne pas avoir à se déplacer en transport en commun à ce moment-là ! Un indice pour tenter de vous y retrouver : la légende est incomplète ; un fin trait noir semble relier une seule et même station de bus. C’est d’ailleurs étonnant que les représentations des lignes de bus 401 et 402 soient scindées en trois tronçons. En fin connaisseur du protocole de communication HTTP, j’aurais personnellement évité la ligne de bus 404, de peur de ne pas arriver à destination 😉

 

Pour reprendre le refrain à la mode actuellement, il convient (parfois) de privilégier la marche ou le vélo !

 

 

urbanisation-si_logo

 

Thierry Biard

urbanisation-si.com

 

 

« L’artiste imprime à son œuvre un sceau de personnalité alors que l’ingénieur est amené à se considérer comme l’artisan d’une œuvre impersonnelle. »

Fulgence Bienvenüe (1852-1936), père du Métropolitain

 


18/02/2022
0 Poster un commentaire

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 : 

https://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