Vous êtes ici : Accueil UML La capture des besoins

La capture des besoins

C'est à mon humble avis l'une des phases les plus importante car elle doit permettre aux utilisateurs finaux et/ou au maître d'œuvre, qui ne sont pas toujours des informaticiens, de bien exprimer leurs besoins et de bien comprendre les fonctionnalités que le système va fournir.

C'est à l'occasion de cette phase que nous allons acquérir le vocabulaire métier du client et parfois même le construire avec lui quand le client ne dispose pas en interne d'un vocabulaire clair et transversal à tous les services impliqués.

La capture des besoins constitue le document de départ et le document de fin comme on peut le constater dans le cycle en V.

Il doit donc être exprimé de la manière la plus claire possible pour les tiers même si parfois cela implique quelques abus de langage UML / SysML comme nous le verrons plus loi

 Documents

Documents collectés :

Il est difficile de donner une liste précise des documents à collecter mais pour résumer il faut collecter un maximum de documents existants ou d'informations sur l'existant comme par exemple :

  • L'organigramme de la société qui utilisera l'ERP.
  • Les modèles de documents émis et reçus par la société (devis, factures, etc...).
  • Les procédures qualités et éventuellement la bible qualité de l'entreprise.
Tous les documents papiers et/ou informatiques en rapport avec le projet peuvent contenir une part d'information que le client ne soupçonne pas forcément.

Il est aussi intéressant quand c'est possible d'interroger les utilisateurs finaux du système car ils ne sont pas toujours impliqués dans le processus de conception.

Documents livrés :

Un cahier des charges contenant sous forme compréhensible :

  • Le modèle UML de cette partie.
  • La liste et la description des acteurs qui interagissent avec le système.
  • La liste des fonctionnalités à livrer.
  • La description du fonctionnement dynamique du système.

Démarche :

Bien entendu il n'y a pas qu'une seule démarche et c'est bien souvent au grè des disponibilités clients que se structure la démarche.

Par ailleurs, toutes les étapes décrites ci-dessous sont bien souvent menées en parallèle.

Définition du métier et du contexte :

Notre client la société ToutBio est ici un acteur majeur de l'industrie Agro Alimentaire qui est implanté dans toute l'Europe et l'Amérique du Nord.

Les filiales de chaque pays sont indépendantes et disposent de leur propres usines et réseaux de distribution, mais aucun pays ne produit l'intégralité de ce qu'il commercialise.

La logistique est assurée par un service interne à chaque filiale et par des contrats avec des sociétés de transports et logistiques.

Les stocks sont répartis entre les usines, les centres de logistique, les clients finaux et les distributeurs.
Si cela s'avère important ou utile il est possible d'utiliser le profil BPMN : http://www.bpmn.org/

Identification des acteurs

La première des missions est de bien identifier les acteurs qui vont interagir avec le système.

On entend par acteur, un humain, une machine, ou un système qui ne fait pas partie de la solution à réaliser mais qui participe au fonctionnement général de la solution par une interaction.

Dans notre cas nous avons typiquement des acteurs humains qui sont des collaborateurs, des partenaires, des clients et des fournisseurs.

Dans le cas d'un ERP il est important de travailler à partir de l'organigramme de l'entreprise et de créer les profils d'acteurs correspondant à des droits, des accès, des informations particulières.

Nous pourrions aussi avoir des acteurs non humains comme un système EDI permettant de passer des commandes de façon électronique ou des règlements bancaires mais ce n'est pas le cas aujourd'hui.

Nous introduirons des acteurs numériques dans la partie SysML un peu plus tard mais nous aurions tout à fait pu en introduire dans un projet UML.

Définir les acteurs consiste donc à définir les limites de notre projet mais surtout les profils des différentes personnes ou machines qui vont interagir avec notre système.

On peut parfois être tenté de définir tout ou partie de l'environnement d'exécution de la solution comme des acteurs. Par exemple le Fax qui permet d'émettre et qui sera en fait gérer comme une imprimante particulière dans le sens où il y aura un protocole précis pour vérifier la bonne émission des Fax.

Le but de la modélisation n'étant pas de reformuler forcément tous les détails de l'environnement d'un système, nous nous contenterons de spécifier en détail les points qui doivent l'être.

Ci-dessous les différents acteurs identifiés pour ce projet montre aussi certains héritages entre acteurs. Il est possible et souhaitable de commenter les rôles des différents acteurs en s'appuyant sur l'organigramme de la société et/ou sa charte qualité et les fiches de postes des collaborateurs.

Acteurs.jpg

Identification des cas d'utilisation (Capture des besoins fonctionnels)

Le fait d'avoir identifier tous les acteurs (ainsi que leur mission) qui vont interagir avec le système simplifie grandement la collecte des besoins fonctionnels car il suffit alors d'analyser acteur par acteur et de vérifier pour chacun qu'il dispose de toutes les fonctionnalités qui lui seront utiles au regard de sa mission et du périmètre du projet.

Les cas d'utilisation seront autant de fonctionnalités du système qui pourront avoir une portée transversale comme le traitement d'une commande ou verticale pour certaines tâches comptables.

Ci-dessous la décomposition d'une partie des fonctionnalités requises pour notre exemple.
Il a été choisi ici d'utiliser un verbe à l'infinitif (ce qui est une règle de base) dont le sujet est l'acteur initiant la fonctionnalité.

Il aurait aussi été possible de nommer tous les cas d'utilisation en prenant les verbes dont le sujet était notre système. Ainsi le cas d'utilisation « Recevoir des alertes » aurait été « Émettre des alertes ».

Par ailleurs, il semble difficile de donner une règle de granularité pour définir les cas d'utilisation.

La définition de cas d'utilisation très génériques va impliquer des descriptions dynamiques très complexes et des commentaires clairs pour bien comprendre tout se que fera le cas d'utilisation.

La définition de cas d'utilisation très fins peut multiplier leur nombre ainsi que les relations de dépendance entre ces derniers.

Il est cependant possible de définir plusieurs diagrammes de cas d'utilisation avec des niveaux de granularité différents afin de préciser le projet.
UseCaseFonctionnel.jpg

Identification de l'infrastructure technique

Les contraintes techniques sont très importantes et ne sont pas toujours exprimées clairement. De plus la mise en place d'un projet ERP est parfois l'occasion de redéfinir l'infrastructure technique.

Au delà des aspects physiques comme les serveurs, les réseaux, les imprimantes, les postes utilisateurs, il ne faut surtout pas négliger les besoins fonctionnels de la branche technique comme la sécurisation des accès, les procédures de sauvegardes et de reprise après crash.

Ci-dessous nous représentons l'infrastructure technique existante par un diagramme de déploiement qui pourra, si besoin, être affiné par des documentations techniques sur les capacités serveur.

DeployementDiagramUML.jpg

 

Ci-dessous quelques cas d'utilisation pour récapituler les principaux besoins techniques.

                   UseCases_BesoinsTechnique.jpg

Définition des besoins en IHM

Il n'y a pas de méthode particulière ni de diagramme particulier pour définir les besoins en IHM. Il est possible de réaliser des maquettes avec n'importe quel outil de Excel à OpenOffice en passant par Plone ou Photoshop.

La définition des besoins en IHM est tout à fait fondamentale qu'il s'agisse d'une évolution de système existant ou de la création d'un nouveau système.

Cette définition est très fortement liée au contexte technique du projet. Si on développe une application Web, une application mono-poste ou un client lourd, les contraintes sont à chaque fois totalement différentes.

Dans l'analyse dynamique qui va suivre avec les diagrammes de séquences il sera très important de connaître au maximum le fonctionnement de la future IHM car tout ne sera pas forcément possible en fonction de chaque technologie d'IHM.

Quand il s'agit de faire évoluer un système il est généralement préférable de préserver au maximum l'ergonomie et les usages de l'IHM existante afin de réduire les coûts de formation. De plus, en préservant au maximum les usages, l'adhésion des utilisateurs au nouveau système est d'autant plus grande.

En effet il est toujours beaucoup plus difficile de mettre en œuvre de nouvelles IHM que de préserver ou de faire évoluer les IHM existantes.

Ci-dessous l'exemple d'une IHM sachant que l'environnement de développement de l'ERP sera SIMAX ERP.

 

IHM.jpg

Préparation de la phase d'analyse (Phase suivante)

Bien qu'il ne faille pas mettre la charrue avant les bœufs, il serait dommage de ne pas bénéficier des avantages que présentent les environnements de modélisation UML.

Nous allons donc commencer à utiliser une classe générique qu'on appellera « Boite noire » et qui va nous permettre d'enregistrer les différentes méthodes que nous allons spécifier plus tard dans la phase d'analyse.

Cette « Boite noire » représente en fait le futur système tel qu'il sera vu par les utilisateurs le jour ou il sera livré.

Nous allons donc respecter parfaitement l'approche « Top Down » et le processus 2TUP en ne cherchant pas par avance à spécifier le contenu de cette boite noire même si c'est parfois très tentant quand on a une certaine vision de ce qui est possible ou existant.

 Définition dynamique du système.

Nous avons défini les acteurs qui vont interagir avec le système ainsi que les fonctionnalités attendues du système. Nous allons maintenant définir comment ces interactions ce déroulent dans le temps et ainsi enrichir progressivement la boite noire que nous venons de définir.

Nous disposons pour cela de 3 diagrammes ; le diagramme de séquence d'une part et les diagrammes d'états et d'activités d'autre part.

Le diagramme de séquence est particulièrement adapté pour la description de la chronologie des échanges entre acteur et système. Il nous permet de définir les messages synchrones et asynchrones qui seront échangés entre le système et les acteurs et se sera la boite noire qui collectera ces messages.

Les diagrammes d'activité et d'état sont particulièrement adaptés à la description des flux d'informations et du fonctionnement interne du système.

Dans le cadre de notre étude nous n'allons pas essayer de décrire toutes les possibilités d'exécution possible car la combinatoire serait tellement importante que l'étude n'en finirai pas.

Nous allons simplement décrire les interactions nécessaires à la description des besoins fonctionnels et celles relatives aux spécificités particulières de notre client.

Difficulté :

Cette phase de description du fonctionnement dynamique des cas d'utilisation nécessite de rester le plus générique possible tout en ayant une vision technique du fonctionnement futur du système. Plus le contexte de réalisation technique est connu, plus cet exercice est simple car les contraintes sont connues. Inversement si le contexte technique n'est pas encore clairement définit il faut essayer de rester le plus pragmatique possible par rapport aux axes stratégiques du projet : développement web, application mono-utilisateur, programme embarqué, etc....

Les diagrammes de séquences (Chronologie des traitements)

Ci-dessous nous décrivons le processus de traitement des non conformités.

Nous utilisons pour les diagrammes de séquence l'acteur « Collaborateur » qui est un acteur générique pour décrire le fait que n'importe quel collaborateur peut participer à la gestion d'une non conformité.

Nous utilisons par ailleurs l'acteur « Responsable qualite » qui est le seul à pouvoir créer et clôturer une non conformité et pour le distinguer des simples collaborateurs.

Cette description simplifiée du traitement des non conformités décrit uniquement la chronologie de traitement d'une non conformité mais ne permet pas de déterminer avec précision qui peut lire, modifier ou supprimer une non conformité.

Il contient d'une part une boucle « loop » qui se répète tant que la variable « nonConformite » de notre objet de type « BoiteNoire » reste vrai.

Et à l'intérieur de cette boucle nous avons deux exécutions possibles :

  • Soit le responsable qualité clôture la non conformité ce qui changera la valeur de la variable « non Conformité » à faux et interrompra ainsi la boucle.
  • Soit le responsable qualité transfert la non conformité à un collaborateur qui devra la traiter et la boucle continue.

Le fait d'utiliser ici une variable reste cependant relativement complexe dans une phase de capture des besoins car il ne faut pas oublier que dans cette phase ce ne sont pas des informaticiens habitués à la notion de variable qui vont collaborer au projet.

Nous pourrons donc nous autoriser des abus et utiliser à la place de cette notation technique
[ nonConformité==true ] une forme plus lisible comme [ tant que la non conformité n'est pas traitée ].

Il en va de même pour les noms des messages. Nous avons ici choisi de respecter la forme informatique d'un message « clotureNonconformite() » afin de pouvoir ultérieurement générer le code qui va en découler.

Il est cependant possible en phase de spécification d'exprimer les interactions dans un langage plus clair mais il faudra redéfinir toutes ces méthodes en phase d'analyse.

SequenceBlackBox.png

Ci-dessous nous décrivons la chronologie des actions liées à la création d'une commande à partir d'un devis. C'est l'un des processus de création de commande qui illustre bien ici que c'est l'assistante commerciale qui déclenche le processus.

Ensuite on voit que le système doit gérer automatiquement des réservations de stock et des demandes de prix à travers l'opération « controleStockDispo() » puis la demande d'ordre de fabrication (OF) à travers l'opération « controlePossibiliteProduction() » mais il s'agit là d'un abus de langage UML.

En effet, si le système doit émettre un signal pour signaler par exemple une réservation de stock à un utilisateur, il ne peut le faire qu'en lui envoyant un email ou tout autre procédé électronique d'émission d'information mais en aucun cas le système ne pourra faire appel à une opération « signaleReservation Stock() » sur un humain.

De même qu'une machine qui affiche un message ne va pas graver un message dans la rétine d'un humain, il serait plus juste de créer ici un auto-message sur le système pour signaler qu'il émet un signal au magasin, aux achats, à la production ou au client.

Pour les puristes si nous signalons par exemple nos évènements par email il faudrait représenter l'émission d'un signal asynchrone vers un serveur SMTP.

SequenceCreerCommande.jpg

Une fois ces diagrammes de séquence renseignés, notre boite noire a déjà commencé à collecter tous les messages que notre système devra traiter comme nous pouvons le constater ci-dessous.

boiteNoire.png

Nous avons ici utilisé le diagramme de séquence pour décrire les interactions entre le système et le reste du monde. Il nous sera possible plus tard de ré-utiliser cette logique entre un bloc particulier du système et les autres blocs avec lesquels il va interagir.

Les diagrammes d'activités (Flux d'informations)

Le diagramme d'activité est utilisé dans cette phase pour documenter le fonctionnement d'un cas d'utilisation et mettre en évidence les flots d'information contrairement aux diagrammes de séquence qui focalisent plus sur la chronologie des interactions entre le système et le reste du monde.
Dans notre exemple nous décrivons la création d'un devis qui commence par la réception dans le système d'une demande de prix client et termine par l'émission d'un devis client.
Il sera ensuite possible de décrire en détail le processus de consultation stock, fournisseur et production pour expliquer le fonctionnement attendu.

ActiviteDevisClient.jpg

Les diagrammes d'état (Comportement d'un cas d'utilisation)

Le diagramme d'état introduit la notion d'évènement de façon claire afin de mettre en évidence le traitement des signaux asynchrones que peut recevoir le système. En revanche, il ne permet pas de matérialiser les objets échangés comme la demande de prix ou le devis précédent.

Il est généralement utilisé pour décrire le fonctionnement d'un objet ou d'une opération mais nous l'utilisons en phase de capture des besoins pour décrire le fonctionnement d'un cas d'utilisation.

Le diagramme d'état appelé « Statechart » est la représentation d'un automate a état fini. Vaste sujet traité dans la littérature informatique depuis longtemps.

etatDevisClient.jpg

Cahier de description des besoins fonctionnels et techniques.

A l'issue de cette première grande phase de capture des besoins nous sommes capable de décrire :

  • Le contexte général et les limites du projet.
  • Avec qui et comment le système va interagir.
  • Les fonctionnalités attendues du système et leurs fonctionnements.
  • Le contexte et les impératifs techniques du projet.
  • Les besoins techniques d'exploitation du système.


L'ensemble de ces descriptions va être expliqué dans la première partie du cahier des charges et va éventuellement être présenté à travers un Intranet afin de lier entre elles les différentes explications et diagrammes pour offrir une lecture plus intuitive.

Ces descriptions vont être utilisées tout au long du projet jusqu'à la recette finale et même plus tard durant l'exploitation du système.

En effet, quand il faudra répondre aux demandes d'évolution du système, celles-ci pourront être exprimées et définies en reprenant le contexte initial de l'étude.

 

Actions sur le document
Références
 
Site réalisé et hébergé par www.optragroup.fr