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

 

  1. Les utilisateurs identifiés dans le Vision Document peuvent servir de base à l’identification des acteurs.
  1. 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.
  1. Les acteurs peuvent être modélisés avec des relations de généralisation/spécialisation.
  1. 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

              

  1. 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).
  1. 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.
  1. 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. 

  1. Une entité métier (business entity) est un concept global d’information qui traduit un choix de gestion pertinent pour le domaine considéré.
  1. Il s’agit donc d’éléments manipulés dans le cadre d'une activité professionnelle: commande, facture, contrat, etc...
  1. 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

 

  1. 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.
  1. 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?