Méthodes de modélisation

1. Présentation

UML n’est pas une méthode, c’est un langage de modélisation. Ici, pas de recette, d’explications "pas à pas" pour modéliser votre système. Il faudra cependant respecter la syntaxe. Un peu comme avec une langue, on apprend l’orthographe, la grammaire et on crée à partir des briques de base.

Les diagrammes peuvent être utilisés pour supporter la communication, supporter les développements ou même automatiser les développements des systèmes opérationnels.

Il existe quatorze diagrammes : diagramme de classes, diagramme d’objets, diagramme de cas d’utilisations, diagramme d’activités, diagramme de séquences, diagramme de composants, diagramme de déploiement, diagramme de paquets, diagramme de structure composite, diagramme de profils, diagramme d’états-transitions, diagramme de communication, diagramme global d’interactions, diagramme de temps.

Hiérarchie des diagrammes UML

1. Présentation

La modélisation par les buts permettra de faciliter l’élicitation, la spécification et la priorisation des besoins. L’idée de ces méthodologies est de prendre l’intention de l’organisation (la problématique que les parties prenantes tentent de résoudre), de la raffiner en une stratégie, des opérations et process, et des spécifications techniques.

L’approche par buts est utilisée dans nombre de méthodologies : EKD-CMM, KAOS, I*, MAPS… Le chapitre suivant vous présentera EKD qui est une méthode très complète de modélisation de la connaissance et de l’écosystème d’une solution. L’un des modèles d’EKD est l’arbre de buts, ainsi cette section le présentera. Il existe aussi des méthodologies (telles que MAPS) qui utilisent des réseaux de buts plutôt que des arbres.

Les buts répondent donc au "pourquoi" de l’élaboration de votre solution. Le premier but sera souvent simple, de haut-niveau. Cela peut être un but du business, un but provenant du marché, un but stratégique, technique, fonctionnel ou méthodologique…

Modèle de buts (aussi dit modèle d’objectifs).

1. Présentation

Cette méthode est née dans les années 1980 en Suède. Elle est issue de la recherche de Plandata puis continuée par le Swedish Institute for System Development. Cette méthode conceptualise pour la première fois le concept de business goals (objectifs métier, buts fonctionnels). Cette innovation permet pour la première fois de modéliser les intentions des parties prenantes et de l’organisation. On pourra donc également juger si les processus mis en place répondent aux besoins de l’organisation.

Le framework a évolué jusqu’au début des années 2000, puis s’est stabilisé. Il comporte deux composantes : un langage et un process de modélisation.

Le langage EKD est constitué de six sous modèles constituants un modèle : le Modèle de buts (Goals Model), le Modèle des règles fonctionnelles (Business Rules Model), le Modèle des concepts (Concepts Model), le Modèle des process fonctionnels (Business Process Model), le Modèle des ressources et des acteurs (Actors and Ressources Model), le Modèle des composants techniques et les exigences (Technical Components and Requirements Model). Le but de chaque modèle est de capturer une composante de la connaissance d’entreprise.

Nous allons décrire brièvement les intérêts de chacun de ces modèles. Il y a deux angles principaux qui peuvent avoir un impact dans un projet décisionnel. Le premier est la documentation du projet décisionnel lui-même, le second est la documentation des systèmes opérationnels. En effet, si votre système opérationnel et la structure de l’entreprise sont parfaitement documentés, une partie importante du recueil des besoins pour votre système décisionnel est réalisé. Il est cependant idéaliste de penser que tous les processus opérationnels, les rôles et les responsabilités opérationnels sont documentés au moment où le projet décisionnel débutera. Ainsi, loin de préconiser l’application de cette approche à...

1. Présentation

L’objectif est ici de simplifier les techniques de modélisation pour que la démarche puisse être amorcée par les parties prenantes fonctionnelles, puis continuée par les parties prenantes techniques. En effet, il est parfois difficile de réunir des parties prenantes avec des cultures si différentes et espérer qu’elles puissent arriver à communiquer efficacement.

Ainsi le processus pour créer un model Data Vault se décompose en trois étapes principales :

La méthode se base sur des workshops avec un mélange de collaboration et d’introspection (cf. Activités de recueil des besoins - Workshop et Les activités - Introspection).

Lister les concepts

La première étape pour identifier les concepts centraux est de lister chaque concept sur des post-it : cette activité s’appelle la "facilitation". Il ne s’agit...