Conduite de projets, L’UC model, le glossaire et le modèle du domaine, entités métier
L’UC model
On va décrire les cas fonctionnels de l’application
Ce travail de modélisation se fait selon deux approches complémentaires, reposant chacune sur un modèle :
Modèle de Cas d’Utilisation (UC Model, dynamique)
Description des processus fonctionnels réalisés au travers des interactions entre le S.u.d. (System under design) et ses acteurs.
C’est un modèle dynamique.
Il donnera lieu ultérieurement à la description des UC detail (scénarios) et des Supporting Requirements.
Modèle du Domaine (statique)
Description des grands concepts d'information manipulés par le métier dans le cadre de l’utilisation du S.u.d. System under design (S.u.d.)
C’est un modèle statique.
Il donne lieu d’abord à la rédaction d’un Glossaire qui constitue un préambule au futur diagramme de Classes métier réalisé en Analyse.
UC MODEL
Comment élaborer un UC Model:
Identifier les UC et les acteurs
Décrire brièvement les UC et acteurs
la description des UC à ce stade est très succincte, quelques lignes; il ne s'agit que d'avoir une vision à haut niveau, le « brief » du UC.
Idem pour les acteurs.
Etablir les relations entre UC et entre acteurs
extends, includes, généralisations,…
Tracer le diagramme de UC
Structurer les UC en packages
Décrire les packages
Une question? Posez-la ici
Identification des Use-Cases, ou UC
Un Use-Case est un service rendu par le système à son utilisateur ou encore l'intention de l'utilisateur quand il manipule le système.
Il est toujours exprimé sous la forme d’un verbe à l’infinitif traduisant cette intention
Le product owner est très important, il nous oriente dans l’identification de ces uses cases
Chaque UC représente une façon d'utiliser le système, par exemple d'assister un utilisateur pendant le déroulement d'un processus métier. Leur description permet donc de définir ce que doit faire le système, les interactions acteur-S.u.d.
Le UC doit apporter une valeur ajoutée significative à l’utilisateur et à l’entreprise.
L'identification des UC requiert donc de connaître en détail les besoins des utilisateurs. Pour cela il faut comprendre le contexte du système (modélisation métier), interroger les utilisateurs, ...
Granularité des UC
Il est difficile de déterminer la bonne granularité d'un UC
Trop gros ?
Le UC représente une part très importante de l'utilisation du système. Sa modélisation sera alors lourde et il sera difficile de planifier son implémentation sur un cycle d'itérations courtes.
Trop petit ?
Le UC correspond à une séquence d'actions atomiques. On aurait alors des dizaines de UC par système sans vue d'ensemble.
Dans un système d’informations, le nombre théorique idéal : 15-20 UC significatifs par système ou sous-système.
Une question? Posez-la ici
Identification et Description des Acteurs
- Les utilisateurs identifiés dans le Vision Document peuvent servir de base à l’identification des acteurs.
- Il est nécessaire de distinguer les utilisateurs de leur rôle par rapport au système: Un même utilisateur peut avoir plusieurs rôles et on identifiera alors plusieurs acteurs.
- Les acteurs peuvent être modélisés avec des relations de généralisation/spécialisation.
- On distingue les acteurs humains des acteurs système (systèmes externes au S.u.d. mais interfacés avec celui-ci).
Acteur humain (A) à Acteur système (B)
Identification des Packages
Les UC sont structurés en packages selon plusieurs critères possibles:
- Par acteur
- Par cohérence fonctionnelle
GLOSSAIRE et MODELE DU DOMAINE: Description des entités métier
- L’approche par le modèle du domaine permet de repérer et décrire les grands concepts d’informations gérés par le système cible (ou existant).
- Cette approche offre aux utilisateurs, clients, développeurs, consultants, etc... un vocabulaire commun qui permet de s'accorder sur les termes principaux et ce qu'ils recouvrent, ce qui permet un partage des connaissances.
- La modélisation du domaine favorise donc la compréhension du problème que le système logiciel devra résoudre
Une question? Posez-la ici
Entités Métier
L’approche par le modèle du domaine repose sur l’identification et la description d’entités métier.
- Une entité métier (business entity) est un concept global d’information qui traduit un choix de gestion pertinent pour le domaine considéré.
- Il s’agit donc d’éléments manipulés dans le cadre d'une activité professionnelle: commande, facture, contrat, etc...
- On étudie également les relations entre les entités métier
On les identifie à partir de différentes sources
- Interviews des experts du domaine: utilisateurs ou direction
- Modèle statique établi lors de la réalisation du système existant
- IHM du système existant
- Documents opérationnels issus du système existant
Des analystes fonctionnels sont requis pour leur modélisation.
Le Glossaire
Ces entités sont d'abord décrites textuellement dans un Glossaire.
Description: Chaque entité identifiée donne lieu à une description textuelle libre. On peut choisir de préciser notamment les éléments suivants:
- Nom
- Type (gestion, référence ou reporting)
- Objet – Description globale de l’entité
- Information élémentaires associées
- Définition précise des informations élémentaires calculées
- Etats traversés (entités de gestion seulement)
- Règles de passage d’un état à l’autre (entités de gestion seulement)
- Liens avec les autres entités
Une question? Posez-la ici
Modèle du Domaine
Le Glossaire est un travail préparatoire qui doit pouvoir servir ensuite, en analyse et conception, à l’établissement d’un modèle du domaine qui permettra de découvrir les objets du système logiciel:
Diagramme de Classes Métier
Diagramme d’Etats/Transitions le cas échéant
Use-cases, UC DETAIL
- A partir de la phase « Elaboration », progressivement au fil des itérations et dans l’ordre de priorité défini, les UC identifiés sont décrits en détail.
- Chaque UC est d’abord décrit par un bordereau d’identification contenant notamment les informations suivantes (liste non exhaustive) :
Résumé : Le « brief » du UC (déjà décrit dans le UC model).
Déclenchement : Les évènements qui vont déclencher l’exécution du UC.
Objectif : Objectif visé par l’acteur sollicitant le UC.
Frequence d’utilisation : ---------------------------------------------------------------
Acteurs : Distinguer les acteurs primaires et secondaires s’il y a lieu.
Pre conditions : Etat dans lequel le système doit se trouver avant l’exécution du UC
Post conditions : Idem après l’exécution
Ces informations sont générales à tous les scénarios du UC (cf. page suivante)
Une question? Posez-la ici
Chaque UC est ensuite décliné en un ou plusieurs Scénarios
le scénario nominal représente le flot d'évènements qui s'exécute le plus fréquemment.
les scénarios alternatifs correspondent à d'autres cas où le UC s’exécute correctement.
les exceptions sont des cas où le UC ne s'exécute pas correctement jusqu'au bout.
Chaque scénario fait l’objet d’une description détaillée
un scénario est une séquence d'actions appelée flot d'évènements.
ce flot est exprimé textuellement. Il indique ce que fait le système et la façon dont il dialogue avec les acteurs lors de l'exécution du scénario.
Le niveau de détail requis pour cette description dépend du contexte du projet.
Il peut donc être extrêmement variable d’un projet à l’autre
Ces informations sont générales à tous les scénarios du UC
Une question? Posez-la ici
Des questions?