urbanisation-si.com

urbanisation-si.com

TOGAF

Mise en oeuvre des modèles d'architecture d'entreprise

Le diagramme SysML des exigences de la phase A Vision de TOGAF : étape 4.2 de l’étude de cas

Le diagramme des exigences de TOGAF a pour but de montrer qu’une exigence garantit un objectif, qu’elle est satisfaite par un composant applicatif et qu’elle sera vérifiée par des cas d’utilisation/de test.

 

exemple-de-projet-togaf-diagramme-d-exigences-avec-differents-types-de-liens.PNG

 

Pour préciser la sémantique des liens entre les classes stéréotypées UML "Objectifs", "Exigences", "Composants applicatifs" et "Cas d’utilisation/test", la norme SysML utilise les stéréotypes sur les dépendances UML suivants :

 

  • <<Part>> : décompose une exigence en exigences élémentaires.
     
  • <<Refine>> : décrit la manière dont un élément du modèle ou un ensemble d’éléments peut être utilisé pour affiner une exigence.
     
  • <<Guarantee>> : garantit l'atteinte de l'objectif
     
  • <<Satisfy>> : détermine qu’un élément de modèle permet de satisfaire l’exigence en supportant la fonction demandée, ou en répondant à la contrainte formulée. Par exemple un composant applicatif satisfait une exigence.
     
  • <<Verify>> : définit la manière dont un cas de test (dérivé d’un cas d’utilisation) vérifie une exigence. Par exemple, un cas d’utilisation peut exprimer des séquences de test qui vérifient si une exigence est satisfaite.

 

Voir l’annexe 1 à la fin de cet article, consacrée à notre étude de cas exhaustive SysML.

 

Exemple, l’exigence "IS access via website" :
. Affine et détaille l’exigence "Client autonomy"
. Garantit l’objectif "Reservation via the internet".
. Est satisfaite par le composant applicatif "TripReservationSite".
. Est vérifiée par les cas de test/utilisation "Cancel trip" et "Reserve trip".

 

Conclusion

Le diagramme SysML est certainement l’outil le plus rigoureux et formel pour modéliser les exigences.

 

Les différents stéréotypes de dépendances permettent de tisser des liens vers les objectifs, les composants applicatifs et les tests.

Les exigences seront justifiées par leurs liens avec les objectifs, elles seront réalisées par les composants applicatifs et vérifiées par les cas de test/utilisation.

 

Rhona Maxwel

@rhona_helena

 

"Ne pensez pas. La pensée est l’ennemie de la créativité. C’est conscient, et tout ce qui est conscient est mauvais. Vous ne pouvez pas essayer de faire des choses. Vous devez simplement faire ces choses."

Ray Bradbury

 

 

Annexe 1 : l’étude de cas SysML

 

 

 

 

Annexe 2 : 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


04/06/2018
1 Poster un commentaire

Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas

Réalisé par les analystes métier, les experts métier, les responsables métier et les architectes applicatifs et destiné aux architectes métier, aux architectes applicatifs et aux concepteurs logiciels, le catalogue des exigences a pour but d’expliciter les objectifs en besoins détaillés sur les composants de l’architecture d’entreprise et de concevoir le cahier des charges des évolutions du SI et de l'architecture métier.

 

exemple-mise-en-oeuvre-togaf-matrice-exigences-objectifs-strategiques-1.PNG
 

L’identification des exigences et relations avec les objectifs

Elle débute par l’analyse des objectifs stratégiques (le pourquoi et le quoi) et opérationnels (le comment).

 

Les exigences répondent à la question des caractéristiques fonctionnelles (Business Requirements) et non fonctionnelles (IS requirements)  (comme par exemple le RGPD : Règlement Général sur la Protection des Données, très à la mode en ce moment en Europe ou bien encore les aspects portant sur la sécurité). 

 

Voir en annexe à la fin de cet article la liste complète des exigences regroupées en IS requirements et Business Requirements.

 

Le profil UML pour TOGAF créé par Modelio, utilise le stéréotype de dépendance <<Guarantee>> signifiant que la satisfaction des objectifs est obtenue par les exigences qui devront être remplies.

 

Par exemple l’exigence « Trip reservation process automation » garantie l’atteinte de l’objectif « Reduce file processing times ».

 

Un objectif et une exigence ne peuvent pas être confondus. Le premier à une portée générale alors que la seconde est une solution du premier.

 

Deux autres stéréotypes de dépendance :

  • <<Assigned>> signifie qu’un objectif opérationnel est assigné à un acteur ou à une unité organisationnelle ou bien encore à un service métier, mais par contre il ne le sera jamais à un composant de SI.
  • <<Satisfy>> signifie qu’une exigence est satisfaite par un composant du SI.

 

La bonne pratique de rédaction veut qu’une exigence corresponde à une spécification de comportement et non comme un but à atteindre.

On peut utiliser les cas d’utilisation UML qui ont spécialement été inventés pour modéliser l’aspect fonctionnel du système (le système stockera les informations clients de manière persistante).

Voir l’article :

 

Un autre sur l’art de l’interview pour recueillir les exigences :

 

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 :

  

Les règles de vérification des exigences

Pour chaque exigence identifiée, on doit s’assurer qu’elle vérifie les critères suivants :

 

  • Atomique: autonome et pouvant être compris indépendamment des autres exigences ou élément de conception.
     
  • Complète :  elle doit être suffisamment détaillée pour que l’implémentation puisse se faire. Le niveau de complétude requis peut dépendre du point de vue, de la méthodologie, ainsi que l’état dans le cycle de vie, par exemple lorsque l'exigence est en cours d'examen ou de représentation.
     
  • Cohérence : aligné sur les besoins identifiés des parties prenantes et n’entre pas en conflit avec d'autres exigences.
     
  • Concision : ne contient aucun contenu superflu et détail inutile.
     
  • Réalisable : raisonnable et possible dans les limites du risque, du délai de réalisation et du budget alloué, ou considéré comme suffisamment réalisable pour persévérer dans l’analyse à travers d’expériences ou de prototypes (POC).
     
  • Non ambiguë : l'exigence doit être clairement énoncée de manière à préciser si une solution répond ou non aux exigences et si on l’exigence est liée à d’autres besoins.
     
  • Testable : a-t-on la capacité de vérifier que l'exigence a été remplie. Les niveaux acceptables de vérification de l'exécution dépendent du niveau d'abstraction de l'exigence ou de la conception.
     
  • Priorité : classée, groupée ou négociée en termes d'importance et de valeur apportée par rapport à toutes les autres exigences.
     
  • Compréhensible : explicitée avec la terminologie spécifique utilisée par les experts métier.

 

Référentiel d’exigences et leurs propriétés dans Modelio

 

exemple-mise-en-oeuvre-togaf-catalogue-des-exigences-0.PNG
 

  • Nom/Id : permet d’avoir un groupe nominal court résumant l’exigence. L’identifiant, sert à référencer les exigences dans le repository de l’AGL et à éviter les doublons.
     
  • Definition : décrit l’exigence
     
  • Benefit (Critical / Strong / Low) : type de bénéfice obtenu. Il s’agit de caractériser l'avantage qui revient aux parties prenantes à la suite de la mise en œuvre des exigences, mesuré par rapport aux buts et objectifs pour le changement. L'avantage fourni peut faire référence à une fonctionnalité spécifique, qualité souhaitée, ou objectif stratégique ou objectif métier. S'il y a plusieurs parties prenantes, chaque groupe peut percevoir les avantages différemment. Les techniques de résolution de conflit et la négociation peuvent être utilisés pour parvenir à un consensus sur le l’avantage global.
     
  • Cost : l'effort et les ressources nécessaires pour mettre en œuvre l'exigence.
  • Les informations sur les coûts proviennent généralement de l'équipe de mise en œuvre (MOE). On changer la priorité d'une exigence en fonction du coût et du risque. Le coût est souvent utilisé en conjonction avec d'autres critères, tels comme l’analyse coûts-bénéfices.
     
  • Risk (Strong / Medium / Low) : probabilité et impact qu’aura le risque s’il arrive. Il s’agit de la possibilité que l'exigence ne puisse pas fournir la valeur attendue, ou ne pas être réalisée du tout. Cela peut inclure de nombreux facteurs tels que la difficulté de la mise en œuvre d'une exigence ou la possibilité que les parties prenantes n’acceptent pas un composant de solution. S'il y a un risque que la solution ne soit pas techniquement réalisable, l'exigence la plus complexe est à prioriser « Strong » en haut de la liste afin de minimiser les ressources qui seront dépensées, avant d'apprendre qu'une solution proposée ne peut pas être livrée. Un POC (Proof Of Concept), c’est-à-dire un prototype ayant pour but de prouver qu’une solution fonctionne, peut être développé pour établir que les options à haut risque sont possibles.
     
  • Stability (Strong / Medium / Low) : les parties prenantes ne savent pas ce qu’ils veulent, on ne connait pas au début toutes les difficultés pour satisfaire l’exigence. Uune exigence n’est donc pas stable au moment où elle a été identifiée. La stabilité représente la probabilité pour que l'exigence change, soit parce qu'elle nécessite une analyse plus approfondie ou parce que les parties prenantes n'ont pas atteint un consensus à ce sujet. Si une exigence n'est pas stable, elle peut avoir une priorité « Low » afin de minimiser les retouches imprévues et les efforts inutiles.
     
  • Target Release : est ce que l’exigence va être prise en compte dans la version cible. La décision dépend du l’analyse entre le rapport des 3 critères :  Benefit, Cost, et Risk.
     
Par exemple une exigence avec un bénéfice faible pour un coût élevé et un risque fort aura une priorité faible.

 

BABOK (Guide to the Business Analysis Body of Knowledge)

Si vous aimez les cadres verbeux, comme l'est du reste TOGAF, et bien concernant l'analyse métier vous allez être servi avec l’institut IIBA (voir le lien : International Institute of Business Analysis ) qui vous a concocté un petit guide de 514 pages, le « BABOK (Guide to the Business Analysis Body of Knowledge) », qui se veut être une référence pour l’analyse métier.

 

L'objectif principal du Guide BABOK est de définir la profession d’analyste métier et de fournir un ensemble de bonnes pratiques.

BABOK est donc un cadre commun pour toutes les perspectives, décrivant les tâches d'analyse métier qui sont effectuées pour analyser correctement un changement ou évaluer la nécessité d'un changement.

Les six domaines de connaissance du Guide BABOK :

  • Planification et contrôle de l’analyse métier
  • Elicitation et collaboration
  • Gestion du cycle de vie des exigences
  • Analyse de la stratégie
  • Analyse des exigences et Définition de la conception (RADD)
  • Évaluation de la solution

Ces domaines décrivent la pratique de l'analyse métier telle qu'elle est appliquée dans les limites d'un projet ou à travers l'évolution de l'entreprise et de l’amélioration continue.

 

Conclusion

Une exigence spécifie un besoin ou une règle qui doit être satisfaite.

Une exigence peut spécifier une fonction qu'un système doit exécuter ou des critères de performance à atteindre.

 

Avec TOGAF, les exigences peuvent changer tout au long des phases ADM, voir l'article :

 

 

Un nombre important de facteurs externes ou internes peuvent impacter les exigences durant le projet : les lois changent, la concurrence est de plus en plus agressive, les utilisateurs ne savent pas ce qu’ils veulent, des nouvelles technologies apparaissent à des fréquences de plus en plus réduites …

La solution est d’itérer le processus et d’intégrer à chaque nouvelle itération, la gestion des exigences et étudier s’il y des changements.

 

La modélisation des exigences est destinée à fournir une passerelle entre des outils de gestion d'exigences traditionnels et les autres modèles.

On pourra ainsi réutiliser des exigences dans d'autres produits ou projets.

Les scénarios typiques sont des exigences réglementaires, statutaires, ou contractuelles applicables à des produits et à des projets.

On doit pouvoir faire référence à une exigence qui peut donc se trouver dans des contextes multiples ou bien mettre à jour l'exigence d'origine et propager les modifications aux exigence réutilisées.

 

Le meilleur moyen, ayant largement fait ses preuves dans les projets même les plus complexes, pour décrire les exigences textuelles de manière graphique, tabulaire, ou arborescente et qui permet de les relier à d'autres éléments de modélisation est le diagramme d'exigences SysML (norme OMG).

Nous verrons cela dans le prochain article.

 

Rhona Maxwel

@rhona_helena

 

"Nous appellerons émotion une chute brusque de la conscience dans le magique."

Jean-Paul Sartre

 

  

Articles conseillés :

 

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)

 

Annexe : Liste complète des exigences dans Modelio

IS requirements

Accounting ERP connection

The system must be linked to the existing accounting ERP. It must be compatible with stored data.

 

Client memorization

DISCOUNT TRAVEL wishes to retain its clients contact information (title, surname, first name, address, telephone number), and envisages subsequently developing its client follow-up. In particular, accompanying people declared in a file are potential clients for whom an address and telephone number are required.

 

Insurance range extendability

Other types of insurance (repatriation, flight, ?) are also being studied. The system must be able to evolve to take into account several types of insurance for a file.

 

Date of birth targeting evolution

Furthermore, DISCOUNT TRAVEL would like in future to be able to target its range of trips on the basis of the participant's age.

 

File memorization

However, DISCOUNT TRAVEL does not want to keep files once trips have taken place.

 

Business Requirements

IS access via website

The information system must allow the client to place and track his/her orders on the internet at any time and from any location in the world.

 

Client autonomy

The client must be able to place his/her trip orders from start to finish without the intervention of a sales representative.

 

Purchase automation

This activity will be automated in the new website through a direct connection with the "GIE" credit card server.

 

Trip reservation process automation

The order taking and order follow-up processes must be able to be carried out without human intervention.

 

Security

Confidentiality and reliability must be guaranteed. A representative of the company must be able to compensate for possible system dysfunctions at all times.

 

Client relationship management

Client contacts will be retained (greeting, first name, surname, addresse, telephone number, ...), in order to be able to perform client follow-up activities. In particular, people accompanying clients on trips are future potential clients, and contact with them must also be managed.

 

Marketing campaign management

Marketing campaigns will be put in place (e-mailing campaigns), in order to propose new offers. Alongside these campaigns, telephone campaigns will take place. For the most part, client service representatives will be responsible for these operations.

 

Satisfaction poll management

Satisfaction surveys will be set up. These will take place via email, or by completing forms during telephone interviews.  This must take place no later than a few days after the end of client trips. A monthly satisfaction report will constitute part of the overall company performance reporting schedule.

 

Load monitoring and personal satisfaction

An employee workload level indicator and satisfaction index will constitute part of the reporting schedule monitored by the general management team.


01/06/2018
0 Poster un commentaire

Cas complet de mise en œuvre TOGAF : l’artefact « catalogue d’objectifs » (étape 3.3 de notre didacticiel)

Dans l’étape précédente, nous avions abordé les diagrammes d’objectifs, dans cet article nous présentons l’artefact « catalogue d’objectifs » de la méthode ADM TOGAF. L’objectif est de décrire les propriétés de chacun des objectifs.

 

exemple-mise-en-oeuvre-togaf-catalogue-d-objectifs-0.PNG

 

Descriptions des propriétés d’un objectif

 

Nom/Id : permet d’avoir un groupe nominal court résumant l’objectif. L’identifiant, sert à référencer les objectifs dans le repository de l’AGL et à éviter les doublons.

 

Definition : décrit l’objectif

 

Scope (portée) : Strategic / Operational

 

IsCorporate : spécifie s’il est global à l’entreprise, comme c’est le cas des objectifs stratégiques ou s’il doit être alloué plus précisément.

 

Kind (Type) : Qualitative / Quantitative. Les objectifs quantitatifs (opérationnels) sont mesurables, par exemple : pourcentage d’augmentation de visiteurs au site internet sur un an. Les objectifs qualitatifs (stratégiques) sont évalués par des humains.

 

Requested Satisfaction : Soft / Hard. Un objectif « Soft » est évalué lorsque par exemple les objectifs le décomposant ont des facteurs de satisfaction supérieurs aux facteurs d’échec. Les objectifs « Hard » sont binaires, l’objectif est atteint ou pas.

 

Unit Of Measurement : unité de mesure pour connaître le niveau d’atteinte de l’objectif.

 

Goal Value : valeur à atteindre pour satisfaire l’objectif.

 

Current Value : valeur courante mesurée à la date de la définition de l’objectif

 

Problems : tout ce qui peut empêcher l’atteinte de l’objectif.

 

Source : décrit l’origine de la définition de l’objectif.

 

Conclusion

Ces propriétés des objectifs relèvent de la gouvernance.

Les AGL possèdent un repository qui va gérer le cycle de vie et servira d’aide au pilotage et de suivi.

La prochaine étape consacrée à l’artefact « catalogue des exigences » présentera aussi son lot de propriétés.

 

Rhona Maxwel

 

@rhona_helena

 

"Le plus important en matière de communication est d'entendre ce qui n'est pas dit."

Peter Drucker

 

 

Articles conseillés :

 

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)

 

Annexe 1 : Liste complète des objectifs dans Modelio

 

exemple-mise-en-oeuvre-togaf-liste-d-objectifs-1.PNG

 

Annexe 2 : Ensemble complet des définitions des objectifs

 

Reservation via the internet

Propose a reservation service on the internet

 

Improve quality image

Improve the image of the quality of both products and services (support, sales)

 

Sales campaign management

The company intends to implement sales campaigns (called e-mailing campaigns) which will propose trips to all clients registered in its database. These campaigns will be run alongside telephone campaigns (telephone calls to clients by DISCOUNT TRAVEL) to sell available trips. Client consultants make these calls when they are availabile, in other words during times when incoming calls are less numerous.

 

Client satisfaction monitoring

DISCOUNT TRAVEL also plans to implement client satisfaction surveys, sent by email or completed during telephone interviews with a selected group of clients, a few days after their trip. The aim of these surveys is to measure the rate of client satisfaction, and to better target future offers. A monthly summary of these surveys will be included in the reporting schedule monitored by the general management team.

 

Financial optimization

Manage the company's accounts by optimizing the company's cashflow and margins.

 

Improve payment management

Payment times must be reduced, and payments secured. The implementation of remote payment mechanisms through credit cards must be systematized.

 

Improve client follow-up

Better understand our clients, their tastes and preferences, and their loyalty. Inform them of the status of their order, and or new offers and promotions.

 

Obtain ISO 9000 certification

In particular, process mapping must be better managed, and key processes must be more closely checked.

 

Map and control all processes

 

Cash flow optimization

 

Maximize personnel productivity

 

Increase number of trips reserved per day

The average volume of trips sold per day must be increased. This volume will be measured for a full year. This increase must take place based on average prices and margins which are either constant or growing.

 

Optimize client transformation rate

When a prospect consults our offers, the rate of clients proceeding with a purchase must be increased

 

Reduce file processing times

Client order-taking processing times must be as short as possible

 

Increase turnover and profits

 

Improve business process management

Map business processes, analyze and optimize their performances

 

Improve client follow-up

The client must be accompanied during provision of the entire service, from the moment he/she places his order to the moment the service is complete. In particular, any problems encountered during the trip must be dealt with as quickly as possible.

 

Render products more attractive

 

Increase sales presence

Sales presence, in terms of opening times, availability and geographical presence, must be increased.

 

Facilitate order-taking

Access to sales representatives and GUI ergonomics must simultaneously incite and facilitate order taking.

 

Render products more attractive


28/05/2018
0 Poster un commentaire

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)

Destiné aux sponsors du cycle d’architecture, à la direction générale, DSI, architectes métier et applicatifs ainsi qu’aux analystes, le diagramme d’objectifs permet de guider les changements à réaliser pour l’entreprise et son Système d’Information, quantifier les objectifs, les allouer et avoir une approche rationnelle pour les prioriser.

 

tutorial-exemple-d-etude-de-cas-togaf-diagramme-d-objectifs-0.PNG

 

Des études marketing préalables, une analyse avec la méthode SWOT (évaluation des forces, faiblesses, opportunités et menaces) et l’identification des objectifs vitaux de l’entreprise, doivent être réalisées.

 

Le stéréotype <<Part>> pour structurer un objectif stratégique

Le diagramme est une structure arborescente dont les liens sont stéréotypés <<Part>> signifiant qu’un objectif se décompose en un autre.

 

Par exemple l’objectif stratégique « Increase turnover and profits » se décompose en objectif opérationnel comme « Increase number of trips reserved per day » qui lui-même se décompose en « Increase sales presence », « Optimize client transformation rate » et « Render products more attractive ».

 

Les stéréotypes <<+ influence>> et <<- influence>> pour tisser des liens d'impacts positifs ou négatifs entre objectifs

L’objectif « Reservation via the internet » décompose l’objectif « Increase sales presence » et influence positivement les objectifs (<<+ influence>> et <<- influence>> dans le cas contraire) « Optimize client transformation rate » et « Reduce file processing times ».

Cette capacité est un objectif stratégique permettant de répondre et de se différencier de la concurrence, qui va modifier les processus métier des domaines marketing, ventes et comptabilité.

 

Voici à titre indicatif l'organisation du sous projet d'analyse avec le conteneur Goals dans lequel sont représentés tous les objectifs et les 2 diagrammes détaillés dans cet article.

 

tutorial-exemple-d-etude-de-cas-togaf-diagramme-d-objectifs-1.PNG

 

N’oublions pas que ces diagrammes font partie d’un profil UML qui offre la possibilité de tisser des dépendances entre les artefacts de modélisation.

 

Les stéréotypes <<assigned>> et <<guarantee>>

Le diagramme ci-dessous, représente l’affectation des objectifs avec des liens stéréotypés pour signifier de quel type il s’agit :

  • <<assigned>> pour allouer un objectif à un acteur, une unité organisationnelle ou un processus métier.
  • <<guarantee>> pour indiquer que la satisfaction d’une exigence contribuera à l’atteinte de l’objectif.

 

exemple-mise-en-pratique-togaf-affectation-d-objectifs-liens-avec-les-exigences-2.PNG

 

Conclusion

Les diagrammes d’objectifs permettent de représenter la décomposition arborescente des objectifs et leurs liens avec les exigences, processus métier et acteurs internes.

Les stéréotypes des dépendances : <<Part>>, <<+ influence>>, <<- influence>>, <<assigned>> et <<guarantee>> apportent les compléments sémantiques nécessaires.

La prochaine étape 3.3 de notre étude de cas a pour but de formaliser le catalogue des objectifs.

 

Rhona Maxwel

@rhona_helena

 

 "Si le seul outil dont vous disposez est un marteau, vous aurez tendance à voir tout problème comme un clou."

Abraham Maslow

 

 

Articles conseillés :

 

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


07/05/2018
0 Poster un commentaire

Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst

Le module Togaf Architect fournit les fonctionnalités suivantes :

  • Paysage et modélisation des entreprises et de leurs systèmes d'information au niveau métier, architectural et technologique.

  • Modélisation des données métiers.

 

Modelio BA, organise un projet TOGAF en 2 sous-projets de type « Analyst project » et « UML project ».

Voir l'article consacré à la création du projet TOGAF : 

 

 

01_tutorial-togaf-mode-operatoire-sous-projet-conteneur-01.PNG

    

Organisation du modèle

L'architecture TOGAF est organisée au sein de cette structure :

  • L'architecture métier est définie dans la couche métier.
  • L'architecture des données est divisée entre un niveau métier, où le niveau conceptuel des données est défini (Entités métier sous couche de gestion) et le niveau technique, où le modèle de données persistantes est défini (niveau application / architecture de données).

Au niveau des entités métier, le modélisateur s'intéresse aux concepts et à leurs propriétés, mais pas aux aspects logiques et physiques tels que les référentiels, les modèles relationnels, etc.

 

Il est recommandé de modéliser d'abord les notions importantes de l'entreprise, et ensuite, définissez l'organisation de l'entreprise, les processus métier et les autres éléments de l'architecture métier.

  • L'architecture de l'application est structurée en deux domaines d'application: les données de service pour modéliser les données échangées entre les services métier et les cas d'utilisation système pour modéliser des cas d'utilisation liés aux principaux composants applicatifs du SI.
  • L'architecture technologique .

 

L'explorateur Modelio 

Les règles de modélisation

L'explorateur Modelio centralise et organise chaque élément du modèle créé lors de la modélisation.

 

Chaque élément de modèle peut apparaître dans un ou plusieurs diagrammes.

 

Des éléments de modèle peuvent être créés dans l'explorateur, ou dans des types de diagrammes adaptés, où une palette prend en charge la création de tous les éléments pertinents.

 

Toute modification appliquée à un élément de modèle sera transférée dans chaque diagramme où cet élément apparaît.

 

Dans un modèle d'architecture d'entreprise, un élément de modèle apparaît très fréquemment dans plusieurs diagrammes.

Par exemple, le même acteur peut apparaître dans un diagramme de décomposition d'organisation, un diagramme d'événements, un diagramme de sécurité de données, un diagramme d'emplacement et de nombreux autres types de diagrammes.

Pour afficher un élément de modèle existant dans un diagramme, il suffit de le faire glisser de l'explorateur vers le diagramme ciblé.

 

Ne créez jamais deux fois le même élément.

Une fois créé, faites-le glisser de l'explorateur pour le laisser apparaître dans un autre diagramme.

 

Gérer le déploiement

Le déploiement doit être modélisé principalement pour représenter la distribution géographique d'une entreprise, ou pour représenter la distribution de l'application sur des serveurs dans l'architecture technologique.

 

Comme un même élément de modèle peut être déployé à plusieurs endroits différents, une occurrence (instance) de l'élément déployé doit être créée dans l'élément d'emplacement de déploiement.

 

Vous pouvez créer une instance (ou une partie) dans l'élément d'emplacement de déploiement, puis saisir cette instance à l'aide de l'élément déployé.

 

Une façon plus simple de le faire est simplement de glisser et déposer l'élément déployé (de l'explorateur) dans l'emplacement de déploiement (apparaissant dans un diagramme): une instance est automatiquement créée.

 

Créer des sous-projets

Remarque : pour créer d’autres sous-projets : sélectionner le projet « Discount Travel » -  clic-droit – Sous-projets – sélectionner par exemple « Sous projet ArchiMate »

 

Dans le sous projet « Analyst project » - clic-droit, on peut créer des diagrammes de traçabilité, des matrices de traçabilité et des éléments :

  • Conteneur d’exigences
  • Conteneur de règles métiers
  • Conteneur d’objectifs
  • Conteneur de risques
  • Conteneur de tests
  • Dictionnaire

 

Dans le sous projet « UML project », - clic-droit, on peut créer des diagrammes de traçabilité, des matrices de traçabilité et des éléments de type "Package".

 

Liste des conteneurs du sous projet "Analyst project"

 

01_tutorial-togaf-mode-operatoire-sous-projet-conteneur-01.PNG

 

Exemple de conteneur : le dictionnaire

 

02_tutorial-togaf-dictionnaire-02.PNG

  

Créer un diagramme, par exemple d’objectifs

Sélectionner le conteneur Goals – clic-droit – Créer un diagramme – Diagramme d’objectifs

 

03_tutorial-togaf-mode-operatoire-diagramme-d-objectifs-03.PNG

 

Créer par exemple un objectif ou un autre conteneur

Sélectionner le conteneur Goals – clic-droit – Objectif (ou Conteneur d’objectifs).

 

Créer un diagramme dans le package TOGAF Model du sous projet UML project

Sélectionner TOGAF Model – clic-droit – Créer un diagramme - choisir un diagramme

 

04_tutorial-togaf-mode-operatoire-diagramme-uml-bpmn-togaf-04.PNG
 

Créer un élément dans le package TOGAF Model du sous projet UML project

Sélectionner TOGAF Model – clic-droit – Créer un élément - choisir un élément

 

10_tutorial-togaf-creer-un-element-uml-10.PNG

 

Créer la structure (Business Layer, Application Layer et Technology Layer) du package TOGAF Model du sous projet UML project

Sélectionner TOGAF Model – clic-droit – Togaf Architect by Modeliosoft – choisissez :

  • Niveau métier
  • Niveau applicatif
  • Architecture technique

 

05_tutorial-togaf-mode-operatoire-niveau-metier-applicatif-technique-05.PNG

 

Transformation de modèles

 

06_tutorial-togaf-transformation-de-modele-06.PNG

 

Génération de documentation

Les matrices

 

07_tutorial-togaf-generation-de-documentation-matrices-07.PNG

 

Les catalogues

 

08_tutorial-togaf-generation-de-documentation-catalogues-08.PNG

 

Les matrices de traçabilité

 

09_tutorial-togaf-generation-de-documentation-matrices-de-tracabilite-09.PNG

    

Structure de « Business Layer »

"Business Entities" et "Business Architecture"

 

11_tutorial-togaf-structure-business-layer-11.PNG

 

Créer les conteneurs de "Business Layer"

 

16_tutorial-togaf-business-layer-togaf-architect-modelio-16.PNG

 

Créer un diagramme de classe dans "Business Entities"

 

17_tutorial-togaf-business-entities-creer-un-diagramme-17.PNG

 

Créer un diagramme d'information/service métier

 

18_tutorial-togaf-business-architecture-creer-un-diagramme-18.PNG

 

Structure de « Application Layer »

"Application Architecture" et "Data Architecture"

 

12_tutorial-togaf-structure-application-layer-12.PNG

13_tutorial-togaf-structure-application-layer-13.PNG

 

Exemple : créer un diagramme de bénéfices dans le conteneur "Application Architecture"

 

19_tutorial-togaf-application-architecture-creer-un-diagramme-19.PNG

 

Exemple : créer un diagramme de migration de données dans le conteneur "Data Architecture"

 

20_tutorial-togaf-data-architecture-creer-un-diagramme-20.PNG

 

Structure de « Technology Architecture »

Les conteneurs de "Technology Architecture"

 

14_tutorial-togaf-structure-technology-architecture-14.PNG

15_tutorial-togaf-structure-technology-architecture-15.PNG

 

Conclusion

L'utilisation hétérogène de l'architecture d'entreprise à travers différentes méthodes, outils et modèles est un obstacle indéniable à sa généralisation.

 

Et pourtant les standards existent, aussi bien pour l'approche elle-même (TOGAF, DODAF, Praxeme, ...) que pour la modélisation (BPMN,  DMN, BMM, UML, SysML, ...), et les pratiques d'architecture d'entreprise sont bien connues (analyse de processus, des règles métiers, analyse des besoins, ...).

 

Cependant, chacune de ces normes est une boîte à outils générique.

 

Toute tentative de les mettre en œuvre de manière coordonnée afin de modéliser l'architecture d'entreprise nécessite beaucoup d'efforts, ce qui dépasse la plupart des utilisateurs.

 

L'architecture d'entreprise est largement utilisée dans les grandes entreprises, mais elle a encore beaucoup de chemin à parcourir.

 

Rhona Maxwel

@rhona_helena

 

"L'amplitude des contradictions à l'intérieur d'une pensée constitue un critère de sa grandeur."

Friedrich Nietzsche

 

 

Articles conseillés :

 

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles 

 

Les points de vue et les vues TOGAF ou comment montrer que les préoccupations et les exigences des parties prenantes sont prises en compte

 

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


01/05/2018
0 Poster un commentaire

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

La stratégie d'entreprise est le fait de se fixer des objectifs en fonction de la configuration de l'environnement et des ressources disponibles dans l'organisation puis à allouer ces ressources afin d'obtenir un avantage concurrentiel durable et défendable

 

tutorial-exemple-d-etude-de-cas-togaf-analyser-les-objectifs-0.jpg

 

Dans l’article suivant, je présentais le métamodèle de la vue stratégique de la démarche d’urbanisation du SI :

 

 

J’avais aussi consacré une série d’articles à la stratégie d’entreprise notamment sur les outils de représentation :

 

Rappels sur la "phases préliminaire", "la phase A Vision" et "l’extension  Motivation" de TOGAF

Phase préliminaire 

Cette phase ne fait pas partie du cycle ADM (Architecture Development Method).

La phase préliminaire de TOGAF dont le but est de mettre l’organisation en capacité de maîtriser la gestion et les transformations de son architecture et de préparer le déclenchement d’un cycle ADM avec le procès-verbal de démarrage : « Demande de mise en chantier de l’architecture (Request for Architecture Work) ».

Les questions « où, quoi, pourquoi, qui et comment » trouvent réponses dans ce document spécifiant entre autres les objectifs stratégiques, les sponsors, les moyens financiers, les contraintes, …

 

 

Phase A Vision

Grâce à cette phase préliminaire, les objectifs sont connus en Phase A Vision du cycle ADM (Architecture Development Method).

 

 

Ils vont être retravaillés et finalisés en phase B Métier.

 

 

L’extension « Motivation »

TOGAF possède extension appelée "Motivation" qui a pour but de permettre une modélisation structurée supplémentaire de l’environnement impactant, des buts et des objectifs qui influencent une organisation à fournir des services métier à ses clients.

Ceci permet une définition plus efficace des contrats de service et une meilleure mesure de la performance de l'entreprise.

 

 

Identifier les objectifs selon TOGAF

TOGAF fait la différence entre les objectifs stratégiques (goals) et les objectifs opérationnels (objectives).

 

Si on reprend le diagramme d’Ishikawa, les objectifs stratégiques (le « quoi », c’est-à-dire les résultats souhaités) correspondent à des objectifs de premiers niveaux (axe horizontal), voir l’exemple de notre article cité plus haut (Modélisation métier : méthode des processus métier orientés objectifs), « Etre le numéro 1 du service en informatique », et les objectifs opérationnels (déterminent le « comment ») décomposent un objectif stratégique en sous-objectifs ou étapes pour atteindre les résultats souhaités, pour fixer un jalon déterminé dans le temps, et correspondre à un progrès relativement à l’objectif stratégique.

 

Les objectifs opérationnels définissent donc des cibles intermédiaires pour les objectifs stratégiques de manière à mesurer leur niveau de réalisation.

 

Réciproquement, l’identification d’un objectif de niveau inférieur (opérationnel) amène à la question : « à quel objectif stratégique va-t-il apporter sa contribution ? ».

 

A chaque décomposition d’un objectif de haut niveau, il est utile de poser la question des décompositions alternatives : « quels obstacles y a-t-il à la réalisation des objectifs courants ?

N’y a-t-il pas d’autres moyens pour parvenir à l’objectif stratégiques ? ».

La décomposition se poursuit jusqu’à ce qu’un ensemble d’objectifs élémentaires et faisables ait été identifiés.

 

L’analyse du diagramme d’Ishikawa permet de mettre en évidence des incohérences entre objectifs ou au contraire des renforcements.

 

Toujours par rapport à l’exemple de notre article sur le diagramme d’Ishikawa, les objectifs opérationnels permettant d’atteindre l’objectif stratégique précédent sont : « Réduire les coûts de production » qui a comme sous-objectif « Accroître la réutilisation des composants logiciels ». Par contre l’objectif « Attirer les meilleurs profils par des rémunérations valorisantes » peut rentrer en conflit avec « Réduire les coûts de production ».

 

Comme partout, il s’agira de positionner le curseur à un juste milieu entre ces objectifs.

 

La définition des objectifs stratégiques s’appuie en particulier sur l’estimation des capacités de progrès de l’entreprise, et sur la prise en compte des moteur (drivers) du métier, les « moteurs » étant des conditions externes à l’entreprise, liées au secteur d’activité comme des contraintes concurrentielles (baisse des coûts, montée en gamme de la concurrence, …) ou des contraintes légales (par exemple dans le domaine des mutuelles, les directives européennes imposent l'ouverture à la concurrence et à plus de transparence, …).

Les objectifs stratégiques se présentent sous forme informelle et sont toujours le déclencheur d’un cycle ADM.

 

Comme dans tout projet, on commencera en phase A Vision à formaliser, structurer, hiérarchiser et rationaliser les objectifs.

 

L’identification des objectifs doit suivre la méthode SMART :

 

S - Spécifique : Quel est notre objectif SMART ? Qu’est qui doit être fait dans notre métier ?

           

M -  Mesurable : Comment allons-nous mesurer nos progrès ? (Quelles métriques ?)

           

A - Atteignable : Comment allons-nous atteindre notre objectif ? (Segmenter le problème, fournir les bases des solutions)    

           

R - Réaliste : Comment savons-nous qu’il s’agit là d’un objectif réaliste ? (Échéances en tenant compte des limites de délai, des coûts et des capacités de l’entreprise)

           

T – Temporellement borné : Quand comptons-nous avoir atteint cet objectif ?

 

tutorial-exemple-d-etude-de-cas-togaf-analyser-les-objectifs-00.PNG

 

Les objectifs stratégiques sont au niveau corporate (l’entreprise dans sa globalité).

Les objectifs opérationnels sont affectés à des personnes, comme par exemple le responsable d’un domaine métier, d’une unité organisationnelle, …

 

Prioriser les objectifs

Les objectifs opérationnels doivent être mesurables.

La mesure permet la quantification des avantages atteints pour le métier après satisfaction de l’objectif.

Le ratio entre les résultats et l’effort pour les avoir doit être effectué pour déterminer les priorités. 

 

Conclusion

Je vous recommande vivement d’établir un diagramme d’Ishikawa, qui, de manière informelle car il n’est pas normalisé, il ne fait pas partie de toute l’armada de l’OMG, consiste à identifier l’objectif final, stratégique puis les sous-objectifs (opérationnels) permettant de l’atteindre et ainsi de suite de manière récursive.

A partir de ce diagramme, vous pourrez déterminer les alternatives pour satisfaire un objectifs, les éventuels conflits, affecter les objectifs à des responsables et enfin de les prioriser en fonction de métriques.

 

Rhona Maxwel

@rhona_helena

 

"Il suivait son idée. C'était une idée fixe, et il était surpris de ne pas avancer."

Jacques Prévert

 

 

Articles conseillés :

  

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)

 

TOGAF pour les nuls.

 

La méthode top-down dans l'urbanisme du Sytème d'Information


03/04/2018
0 Poster un commentaire

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)

Connaître les préoccupations des participants oriente les choix de création et conception des artefacts. Les rôles des participants et leurs tâches dans le cycle ADM doivent être déterminés. La granularité des modèles seront établies de manière à être compréhensible par les destinataires.

 

Lors de notre précédent article, au paragraphe "Les propriétés des artefacts TOGAF", nous avions abordé les méta-informations des artefacts :

 

 

Méta-informations de l'artefact "Matrice des parties prenantes"

Voici celles pour la "Matrice des parties prenantes" de notre étude de cas "Discount Travel" : 

 

  • Experts : CEO, Marketing director, Marketing officer, Sales director, Account Manager, Finance manager, Financial director, Information systems director, IT Officer
  • Concepteurs : Business analyst
  • Destinataires : toutes les personnes participant à l’architecture d’entreprise
  • Objectifs : identifier les acteurs participant à l’architecture d’entreprise afin de déterminer les artefacts à produire et par qui.
  • Informations en entrée : HR manager

 

Matrice des parties prenantes

  

matrice-des-parties-prenantes-phase-A-vision-etude-de-cas-exemple-togaf.png

 

Conclusion

Cette matrice permet de connaître l’intérêt que porte chaque partie prenante à la réalisation de l’architecture d’entreprise.

L’exemple de l’étude de cas est volontairement très générique, tout le jeux consiste l’adapter au contexte de votre entreprise.

Le prochain article sera consacré à l'analyse, diagramme et catalogue des objectifs.

 

Rhona Maxwel

@rhona_helena

 

"C'est ce que nous pensons déjà connaître qui nous empêche souvent d'apprendre."

Claude Bernard

 

 

Articles conseillés :

 

Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

 

Les points de vue et les vues TOGAF ou comment montrer que les préoccupations et les exigences des parties prenantes sont prises en compte

 

La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

TOGAF pour les nuls.


26/03/2018
0 Poster un commentaire

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

La phase préliminaire de la méthode ADM (Architecture Development Method) de TOGAF (The Open Group Architecture Framework) identifie les acteurs participant aux travaux d’architecture d’entreprise et par rapport à leurs préoccupations spécifiques, on détermine les points de vue et artefacts importants dans le cadre d’une entreprise.

 

elements-de-modelisation-phase-A-vision-etude-de-cas-exemple-TOGAF.png
 

Pour comprendre ce que sont les points de vues et les vues TOGAF, voir l’article qui leurs sont consacrés  :

 

 

Les propriétés des artefacts TOGAF

Rappelons le, les artefacts TOGAF sont les supports de communication exposant une vue particulière de l'architecture.

Ils se décomposent en :

  • Catalogues,
  • Matrices
  • Modèles (diagrammes)

Un artefact doit avoir :

  • Nom
  • Participants : la phase préliminaire de la méthode ADM (Architecture Development Method) de TOGAF (The Open Group Architecture Framework) identifie les acteurs participant aux travaux d’architecture d’entreprise.
    Parmi ceux-ci, il faut indiquer pour chacun des artefacts lesquels participent à leur élaboration. 
    L’usage veut qu’on considère 3 niveaux : 
    - Experts métiers 
    - Concepteurs des artefacts (analystes étiers, AMOA)
    - Destinataires des artefacts (modèles, matrices).
  • Objectif : chaque artefact comporte sa raison d’être, la justification de sa réalisation, quel est son intérêt, son objectif, bénéfices par rapport à son coût de réalisation.
  • Informations en entrée servant à la conception de l'artefact.

 

L’AGL (Atelier de Génie Logiciel) Modelio propose un profil UML « Analyste » et un profil « TOGAF ».

Par exemple les point de vue sont représentés par des packages UML stéréotypés.

 

Pour l’installation et des informations sur Modelio voir l’article :

 

Création d’un projet TOGAF avec Modelio

Pour créer un projet, menu :

  • Fichier – Créer un projet – sélectionner Enterprise Architect Togaf – nommer le « Discount Travel for TOGAF »

 

creer-un-nouveau-projet-togaf-modelio-00.PNG

 

Modelio crée à l’intérieur du projet, 2 sous-projets.

Le premier est un « Sous-projet Analyste » et le deuxième « Sous-projet UML ».

 

structure-d-un-nouveau-projet-togaf-modelio-01.PNG

structure-d-un-nouveau-projet-togaf-modelio-02.PNG
 

Description de l’étude de cas

Système d'Information existant

L’entreprise « Discount Travel » est un HUB pour les agences de voyages qui veulent écouler leur stock de voyages invendus grâce à des remises ne pouvant pas excéder 50 %.

Le client n’a pas le choix des dates de départ et de retour et doit être prêt à partir dans un maximum de 15 jours.

L’entreprise dispose d’un call center ouvert de 8h à 20h du lundi au vendredi.

Un conseiller de clientèle répond au client qui choisit le voyage qui l’intéresse.

Le marketing envoie quotidiennement aux conseillers des fiches papier sur les produits disponibles en fonction du stock.

Le site web permet aux clients d’enregistrer des commandes qui sont ensuite traitées manuellement par un gestionnaire.

Les commandes sont ensuite gérées par une application accédée par les commerciaux.

 

Système d'Information cible

La décision de refondre le système d’information a été pris en comité de direction.

La direction a décidé :

  • de proposer son service de réservation sur internet,
  • d’améliorer le suivi de clientèle.

 

Ce nouveau SI doit proposer des formules complète, « clé en main » incluant l’avion, l’hôtel, la voiture, une destination et une prestation d’hébergement.

Une destination concerne un continent et un pays.

Un voyage concerne un unique pays.

Le marketing est en relation avec les agences de voyage, il décide des voyages prioritaires parmi ceux disponibles afin de constituer les offres les plus attrayantes pour les clients.

 

La modélisation de la phase A Vision s’effectue dans le premier sous-projet « Analyst project ».

 

Les éléments de modélisation mis en œuvre

 

elements-de-modelisation-phase-A-vision-etude-de-cas-exemple-TOGAF.png

 

Conclusion

Ces éléments de modélisation font partie d’un profil UML

Un profil UML contient des :

  • icône
  • stéréotype : sémantique d'un élément, c’est-à-dire que l’on catégorise un élément UML, par exemple une classe, peut être stéréotypée « Goal » (but, objectif stratégique) ou « Requirement » (exigence) ou bien un acteur des use case UML peut être stéréotypé « Acteur interne » ou « Acteur externe», tous les éléments UML peuvent stéréotypés (les relations, ...)
  • tagged value (paire clé/valeur) permettant d’ajouter des méta-informations (priorité, auteur, informations pour l’outil de dérivation de modèle, pour le générateur de code, …) à un élément de modélisation UML

 

Ce profil peut aisément être recréé dans n’importe quel outil de modélisation UML open source comme Eclipse Modeling Tools.

Normalement un profil s'exporte en XMI (XML for Interchange) qui est une norme de l'OMG pour l'interopérabilité des modèles, par exemple entre les différents outils de modélisation.

Un outil de modélisation peut posséder la fonctionnalité de création de profil et son exportation au format XML/XMI puis un autre pourra offrir l'importation à condition de respecter les versions de XMI, mais ça c'est une autre histoire.

 

Le prochain article sur l'étape 2 de "Comment modéliser la phase A Vision de la méthode ADM" sera consacré à la "matrice des parties prenantes (stakeholder)".

 

Rhona Maxwel

@rhona_helena

 

"L'oreille est le chemin du cœur"

Voltaire

 

 

Articles conseillés :

 

TOGAF pour les nuls.

 

Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise

 

Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architectur

 

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles


20/03/2018
0 Poster un commentaire

Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

Après la théorie sur le framework d’architecture d’entreprise, standard du marché, TOGAF, voici, des exemples complets et bien concrets illustrant la modélisation des phases du cycle de la méthode ADM (Architecture Development Method).

Les différentes études de cas sont fournies par l’outil de modélisation français, open source, Modelio.

 

exemples-tutorials-etudes-de-cas-architecture-d-entreprise-TOGAF-0.PNG

 

Installation de Modelio

 La version open source est téléchargeable à l’adresse :

 

 

Cette version permet de modéliser en UML, BPMN, supporte les modules TOGAF Architect et Archimate mais ne possède pas la partie « Analyse ».

Pour pouvoir créer des sous-projets d’analyse permettant de modéliser la stratégie, les objectifs et les exigences, il faut télécharger la version d’essai valable 10 jours, Modelio Business Analyst à l’adresse :

 

 

Cette version complète permet en plus des fonctionnalités de la version open source, de modéliser avec SysML, SOAML, de générer des documentation, du code Java, C++, C#, d’utiliser des outils MDA, et bien d’autres encore.

 

Installation des exemples

Une fois Modelio lancer, aller dans le menu Aide – Page d’accueil

 

Il suffit ensuite de sélectionner chacun des 5 projets d’exemples, et cliquer sur « Deploy » pour déployer les projets dans l’outil.

 

exemples-tutorials-etudes-de-cas-architecture-d-entreprise-TOGAF.PNG

 

Les 5 études de cas proposées par Modelio

« ArchiMetal »

Cette étude de cas démontre la valeur du langage de modélisation ArchiMate 2.1 pour planifier et exprimer une transformation commerciale complexe.

L'étude de cas porte sur un fabricant fictif nommé ArchiMetal.

Grâce à la modélisation d'architecture de haut niveau, le langage ArchiMate éclaire la cohérence entre une organisation, ses processus, ses applications et son infrastructure.

Cette étude de cas présente des exemples de modèles ArchiMate qui peuvent être élaborés au besoin pour l'analyse, la communication, l'aide à la décision et la mise en œuvre.

 

« Archisurance »

Un exemple de compagnie d'assurance fictive.

 

« Discount Travel for TOGAF »

Le projet « Discount Travel for TOGAF » est un projet montrant comment modéliser en utilisant les normes UML et BPMN, l'architecture d'entreprise d'une agence de voyage pour gérer un système de réservation.

 

Cette étude de cas utilise un profil UML c’est-à-dire un ensemble d’icônes, de tagged value et de contraintes OCL personnalisant les artefacts UML pour s'appliquer aux concepts TOGAF, sans en changer la sémantique.

 

Exemple d'article sur OCL :

 

Cette possibilité de personnalisation d’UML pour créer son propre langage fait pleinement partie de la norme UML.

 

Cet exemple constituera notre fil conducteur tout au long des prochains articles.

 

L’agence de voyage est à l’architecture d’entreprise ce que la bibliothèque est à UML ou le « Hello world » aux langages de programmation, c’est-à-dire l’exemple par lequel tout débutant se doit de commencer.

 

Ce projet de Modelio reprend l’exemple de la fameuse « agence de voyage », véritable étude de cas open source, maintes fois utilisée, qui est apparu pour la 1ère fois, illustrant le livre bestseller de Christophe Longépé « Le projet d'urbanisation du système d'information : Démarche pratique avec cas concret » (Dunod), qui est encore aujourd’hui considéré comme la bible de la démarche d’urbanisation du SI.

 

« Discount Travel for ArchiMate »

Le projet « Discount Travel for ArchiMate »est identique au projet précédent mais utilise le langage Archimate créé par l’Open Group.

 

« Shopping Cart »

Ce projet contient le modèle pour le système de panier en ligne, y compris tous les modèles utilisés pour spécifier et réaliser le système informatique.

Ce modèle porte sur le développement d'un système de panier en ligne, qui permet aux fournisseurs de vendre leurs produits directement en ligne pour les clients.

Il est fourni à titre d'exemple UML couvrant l'analyse du contexte et des processus métiers, et la conception et le déploiement d'une mise en œuvre possible.

L'objectif est de montrer la puissance qu'UML apporte à l'analyse et la conception d'un système robuste qui correspond aux exigences initiales.

 

Pour modéliser les phases de l’ADM de TOGAF, ma préférence va vers UML et BPMN, voici 2 articles parmi les catégories  UML et  BPMN consacrées à ces normes :

 

Mais pour ne pas être en reste avec Archimate, notez qu’il existe un outil open source nommé Archi (The Free ArchiMate Modelling Tool) de bonne facture que vous pouvez télécharger à l’adresse :

Il n’y a malheureusement aucun exemple livré avec !

 

Le module TOGAF Architect

Il s’agit d’une extension de Modelio dédié à la modélisation basée sur le standard des cadres d’architecture d’entreprise TOGAF.

 

En fournissant un profil dédié à la modélisation TOGAF, le module TOGAF Architect vous permet de réaliser un panorama complet des systèmes d'information d'une entreprise.

 

Il fournit les fonctionnalités suivantes :

  • Paysage et modélisation des entreprises et de leurs systèmes d'information au niveau métier, architectural et technologique.
  • Modélisation des données métiers.

 

Organisation du modèle selon le module TOGAF Architect  

 

organisation-du-modele-d-architecture-d-entreprise-TOGAF-2.PNG

 

L'architecture TOGAF est organisée au sein de la structure suivante :

  • L'architecture métier est définie dans la couche métier.
    L'architecture des données est divisée entre un niveau métier, où le niveau conceptuel des données est défini (Entités métier sous couche de gestion / entités métiers) et le niveau technique, où le modèle de données persistantes est défini (niveau application / architecture de données).
    Au niveau des entités métiers, le modélisateur s'intéresse aux concepts et à leurs propriétés, mais pas aux aspects logiques et physiques tels que les référentiels, les modèles relationnels, etc.
    Il est recommandé de modéliser d'abord les notions importantes de l'entreprise, et ensuite, de définir l'organisation de l'entreprise, les processus métier et les autres éléments de l'architecture métier.

  • L'architecture de l'application est structurée sous l'architecture de couche application.
    Il a deux domaines d'application :
       - les données de service pour modéliser les données échangées entre les services métiers
       - les cas d'utilisation système pour modéliser les cas d'utilisation liés aux principaux composants applicatifs du SI.

  • L'architecture technologique est structurée dans le domaine technologique de l'architecture technologique.

 

Conclusion

Ce projet classique d’agence de voyage modélisé avec un profil UML et BPMN, nous permettra de mettre en œuvre les phases ADM de TOGAF :

  • la phase A « Vision » avec la modélisation de la stratégie, des objectifs, des exigences
  • la phase B « Métier » avec le diagramme d’entités métier, les diagrammes d’organisation et de localisation, les diagrammes BPMN pour les processus métier
  • la phase C « Architecture des Systèmes d’Information » avec les diagrammes de communication, de cas d’utilisation applicatifs, de réalisation
  • la phase D « Architecture Technique » avec ls diagrammes d’environnement, de traitements, de matériel et réseau
  • la phase E Solutions et Opportunités avec les diagrammes de contexte de projets et les diagrammes de bénéfices.

 

Rhona Maxwel

@rhona_helena

 

"Nos problèmes ne proviennent pas de ce que nous ignorons.

Ils proviennent de ce que nous croyons savoir, et qui en fait est faux."

Mark Twain

 

 

Articles conseillés :

 

TOGAF pour les nuls. 

 

Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

 

Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

 

Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

 

La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)


13/03/2018
2 Poster un commentaire

Les points de vue et les vues TOGAF ou comment montrer que les préoccupations et les exigences des parties prenantes sont prises en compte

TOGAF recommande en phase préliminaire d'identifier les vues architecturales et les points de vue pertinents pour le cycle ADM (Architecture Development Method) afin de satisfaire les préoccupations et les exigences des différentes parties prenantes

 

diagramme-de-classe-uml-concepts-de-base-architecture-entreprise-togaf-01.PNG

 

Les « parties prenantes » (individus, des équipes ou organisations) ont des rôles clés dans le système ou des préoccupations à ce sujet ; par exemple, en tant qu'utilisateurs, développeurs ou gestionnaires.

Les différentes parties prenantes ayant des rôles différents dans le système, ils auront des préoccupations différentes.

 

Les « préoccupations » sont les intérêts clés qui sont d'une importance cruciale pour les parties prenantes du système et déterminent l'acceptabilité du système.

Les préoccupations peuvent concerner tout aspect du fonctionnement, du développement ou de l'exploitation du système, y compris des considérations telles que la performance, la fiabilité, la sécurité, la distribution et l'évolutivité.

 

Définition d’une vue

Une « vue » est une représentation d'un système entier du point de vue d'un ensemble connexe de préoccupations.

 

En capturant ou en représentant la conception d'une architecture de système, l'architecte créera généralement un ou plusieurs modèles d'architecture, en utilisant éventuellement différents outils.

Une vue comprendra des parties sélectionnées d'un ou de plusieurs modèles, choisis de manière à démontrer à un intervenant ou à un groupe de parties prenantes que leurs préoccupations sont prises en compte de manière adéquate dans la conception de l'architecture du système.

 

Définition d’un point de vue

Un "point de vue" définit la perspective à partir de laquelle une vue est prise.

Plus spécifiquement, un point de vue définit : comment construire et utiliser une vue (au moyen d'un schéma ou d'un modèle approprié) ; les informations qui devraient apparaître dans la vue ; les techniques de modélisation pour exprimer et analyser l'information ; et une justification de ces choix (par exemple, en décrivant le but et le public cible de la vue).

 

Une vue est ce que vous voyez.

Un point de vue est l'endroit où vous regardez - le point de vue ou la perspective qui détermine ce que vous voyez.

 

Les points de vue sont génériques et peuvent être stockés dans des bibliothèques pour être réutilisés.

Une vue est toujours spécifique à l'architecture pour laquelle elle est créée.

Chaque vue a un point de vue associé qui la décrit, au moins implicitement.

 

Préoccupations et exigences

Les termes « préoccupation » et « exigence » ne sont pas synonymes.

Une préoccupation est un domaine d'intérêt.

Ainsi, la fiabilité du système pourrait être une préoccupation / un domaine d'intérêt pour certaines parties prenantes.

 

La raison pour laquelle les architectes doivent identifier les préoccupations et les associer aux points de vue, est de s'assurer que ces préoccupations seront traitées d'une manière ou d'une autre par les modèles de l'architecture.

 

Par exemple, si le seul point de vue sélectionné par un architecte est un point de vue structurel, les problèmes de fiabilité ne sont presque certainement pas traités, car ils ne peuvent pas être représentés dans un modèle structurel.

 

Dans ce contexte, les parties prenantes peuvent avoir de nombreuses exigences distinctes : différentes catégories d'utilisateurs peuvent avoir des exigences de fiabilité très différentes pour les différentes capacités du système.

Les préoccupations sont la racine du processus de décomposition en exigences.

Les préoccupations sont représentées dans l'architecture par ces exigences.

Les exigences doivent être SMART (Specific Measurable Achievable Realistic Time-bound).

 

Voir notre article sur la modélisation des exigences,

 

Conclusion

Les vues d'architecture sont donc des représentations de l'architecture globale en termes significatifs pour les parties prenantes.

Ils permettent à l'architecture d'être communiquée et comprise par les parties prenantes, afin qu'ils puissent vérifier que le système répondra à leurs préoccupations.

 

Rhona Maxwel

@rhona_helena

  

"Toutes les choses intelligentes ont déjà été pensées.

Ce qu’il faut à présent, c’est essayer de les repenser."

Johann von Goethe

 

 

Articles conseillés :

 

SysML : tutoriel ( tutorial - didacticiel ) Le diagramme de package (partie 2) 

 

Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles

 

Le Big-Mac de l'urbanisation SI

 

Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture

 

TOGAF pour les nuls.


09/03/2018
0 Poster un commentaire