Le diagramme de bénéfices de la phase E Solutions et opportunités de TOGAF - étape 40 de l’exemple Modelio
Le diagramme de bénéfices modélise les possibilités d’amélioration avec leurs avantages et leurs inconvénients et participe à l'initialisation d'un nouveau cycle ADM (Architecture Development Method) de TOGAF.
Ce modèle est réalisé par les architectes applicatifs avec comme référents les experts métier à destination de la Direction Générale, DSI, responsables de domaine métier.
La phase E Solutions et opportunitésde TOGAF a été abordée dans notre article :
Cette phase réutilise les éléments de modélisation des phases précédentes, avec peu de modèles spécifiques.
Pour plus de précisions sur les éléments de modélisation avec UML des phases précédentes de TOGAF, voir les articles :
- Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation
- Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
- Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
- Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio
Le diagramme de bénéfices se base sur le diagramme de communication des applications de la phase C (voir l’article : “ Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel “).
Les améliorations envisagées sont modélisées sous forme de commentaires UML.
Le commentaire détaille la fonctionnalité et sa contribution en terme d'ajout de valeur à l'entreprise.
Pour aider les décideurs à arbitrer, on doit dans le commentaire préciser la complexité de réalisation et l’estimation de la charge de développement.
Sur le composant d’application d’interaction modélisant le site internet “TripReservationSite”, il est envisagé d’exploiter et d’analyser finement les précédentes visites des clients et prospects afin de leur présenter éventuellement des remises ou des cadeaux.
Pour cette évolution, la complexité est évaluée à “forte” et l’estimation de la charge de développement à 2000 lignes de codes.
Un nouveau stéréotype est défini, le composant d’application intermédiaire (T).
Par exemple “Client history management” est un composant sophistiqué pouvant faire appel à du Big Data ou de l’Intelligence Artificielle.
Il consiste ici à analyser l’historique des actions du client comme ses anciennes commandes, ses consultations récentes, …
L’objectif est de lui proposer des promotions et orienter ses choix en accord avec ses goûts.
Pour cette évolution, la complexité est évaluée à “moyenne” et l’estimation de la charge de développement à 5000 lignes de codes.
Pour le composant d’application entité “Client history” l’évolution consiste ici à stocker l’historique du client ce qui n’avait pas été réalisé dans la précédente itération car non prioritaire face aux autres fonctionnalités.
Pour cette évolution, la complexité est évaluée à “simple” et l’estimation de la charge de développement à 2000 lignes de codes.
Pour le composant d’application entité “Client” l’évolution consiste à gérer les prospects et à gérer leur historique.
La gestion des prospects n'avait été jugée prioritaire lors de la précédente itération.
Pour cette évolution, la complexité est évaluée à “simple” et l’estimation de la charge de développement à 2000 lignes de codes.
Conclusion
Le diagramme de bénéfices modélise les évolutions possibles et se positionne comme une base de travail pour étudier :
- les apports en terme de valeur pour l’entreprise
- le niveau de complexité
- l’estimation de réalisation
- les risques
Ce modèle participe à l’initialisation d’une nouvelle itération ADM.
Une analyse d’impacts sur la précédente itération doit être effectuée.
Les changements, les impacts et les objectifs seront répartis en nouveaux projets..
Rhona Maxwel
@rhona_helena
“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
Annexe : les précédentes étapes de notre étude de cas TOGAF
- Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio
- Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation
- Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)
- Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM
- Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst
- Comment modéliser les objectifs stratégiques et opérationnels en phase A Vision de la méthode ADM TOGAF ? (étape 3.2 de notre étude de cas)
- Cas complet de mise en œuvre TOGAF : l’artefact « catalogue d’objectifs » (étape 3.3 de notre didacticiel)
- Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas
- Le diagramme SysML des exigences de la phase A Vision de TOGAF : étape 4.2 de l’étude de cas
- Le diagramme d’évènements de la phase A Vision de TOGAF : étape 5 de l’étude de cas Modelio
- Le diagramme des concepts de la solution de la phase A Vision de TOGAF : étape 6 de l’étude de cas Modelio
- Le diagramme de chaîne de valeur de la phase A Vision de TOGAF : étape 7 de l’étude de cas Modelio
- Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
- Le dictionnaire métier de la phase B Architecture métier de TOGAF - étape 9 de l’étude de cas
- Le diagramme d’organisation des acteurs de la phase B Architecture métier de TOGAF - étape 10 de l’étude de cas
- Comment modéliser les flux échangés entre une entreprise et les acteurs externes en phase B architecture métier de TOGAF ? – étape 11 de l’étude de cas
- Diagramme des rôles joués par les acteurs en phase B architecture métier de TOGAF ? – étape 12 de l’étude de cas
- Diagramme d’organisation et de localisation en phase B architecture métier de TOGAF – étape 13 de l’étude de cas
- Diagramme de localisation en phase B architecture métier de TOGAF – étape 14 de l’étude de cas
- Diagramme de décomposition fonctionnelle en phase B architecture métier de TOGAF – étape 15 de l’étude de cas
- Diagramme objectifs-services métier en phase B architecture métier de TOGAF – étape 16 de l’étude de cas
- Diagramme de processus métier en phase B architecture métier de TOGAF – étape 17 de l’étude de cas
- Les règles métier en phase B architecture métier de TOGAF – étape 18 avec l’outil Enterprise Architect de Sparx Systems
- Diagramme de cas d’utilisation métier en phase B architecture métier de TOGAF – étape 19 de l’étude de cas Modelio
- Diagramme information - service métier en phase B architecture métier de TOGAF - étape 20 de l’étude de cas Modelio
- Diagramme supervision métier en phase B architecture métier de TOGAF – étape 21 de l’exemple complet emprunté à Modelio
- Diagramme des entités métier en phase B architecture métier de TOGAF - étape 22 du didacticiel
- Diagramme de cycle de vie des entités métier en phase B architecture métier de TOGAF - étape 23 de l'étude de cas
- Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
- Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel
- Le diagramme de migration applicative de la phase C Architecture des Systèmes d'Information de TOGAF - étape 26 du cas complet Modelio
- Le diagramme de localisation des applications et des utilisateurs de la phase C Architecture des Systèmes d'Information de TOGAF - étape 27 de notre cas d’étude
- Le diagramme de cas d’utilisation applicatifs de la phase C Architecture des Systèmes d'Information de TOGAF - étape 28 de notre cas d’étude
- Le diagramme de réalisation des processus de la phase C Architecture des Systèmes d'Information de TOGAF - étape 29 du didacticiel
- Le diagramme de gestion d’entreprise de la phase C Architecture des Systèmes d'Information de TOGAF - étape 30 de l’exemple complet Modelio
- Le diagramme logique de données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 31 de l’exemple complet Modelio
- Le diagramme de dissémination de données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 32 du cas d’étude
- Le diagramme de sécurité des données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 33 du cas pratique
- Le diagramme de migration des données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 34 du tutorial Modelio
- Le diagramme des données de service de la phase C Architecture des Systèmes d'Information de TOGAF - étape 35 du tutorial Modelio
- Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio
- Le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF - étape 37 de l’exemple Modelio
- Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio
- Le diagramme de matériel informatique en réseau de la phase D Architecture technique de TOGAF - étape 39 du tutorial Modelio
A découvrir aussi
- Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- Le diagramme de localisation des applications et des utilisateurs de la phase C Architecture des Systèmes d'Information de TOGAF - étape 27 de notre cas d’étude
- Le diagramme de matériel informatique en réseau de la phase D Architecture technique de TOGAF - étape 39 du tutorial Modelio
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 719 autres membres