Analyse : cas d'utilisations et activités

Qu'est-ce que l'Analyse ?

Les différentes phases du développement

Dans le cadre d'un projet, on peut distinguer différentes étapes :

  1. Analyse : déterminer ce qu'on veut faire.
  2. Conception : déterminer comment faire.
  3. Implémentation : traduire les étapes précédentes en code, i.e. faire,
  4. Intégration et Déploiement : intégrer le code produit (livrables) au projet puis le pousser en production.
  5. Maintenance : évolution du code après sa mise en production (e.g. correction de bugs, ajout de fonctionalités, etc).

À ces différentes étapes, on ajoute des phases de tests (vus en cours d'Automatisations et Tests en Programmation), afin de garantir la qualité et conformité du code produit.

La planification de ces différentes étapes dépend du cycle de développement (modèle en cascade, cycle en V, cycle itératif, etc) choisi. Les différents cycles de développement seront étudiés dans un autre cours.

Objectifs de l'Analyse

L'étape d'analyse, i.e. déterminer de ce qu'on veut faire permet de cadrer le projet afin d'éviter de partir dans tous les sens, voire dans la mauvaise direction. Elle sert notamment d'échanger avec le client autours de ses besoins et contraintes, afin de produire un cahier des charges qui spécifie ce qui devra être fait, et aura valeur contractuelle.

Lors de cette étape, il est important de distinguer les envies du client de ses besoins. Il est en effet important de ne pas trop anticiper d'hypothétiques besoins futurs, qui prendront du temps de développement, risquent de complexifier le code, et constitueront du code supplémentaire à maintenir. Cela impacte donc les phases de conception, implémentation, et maintenance. Il ainsi est souvent préférable d'implémenter de telles fonctionnalités par la suite, lorsque le besoin se manifeste réellement. C'est le principe YAGNI (You ain't gonna need it) : tu ne vas pas en avoir besoin.

Un projet informatique a des ressources limitées (temps, personnes), il est ainsi fréquent de ne pas pouvoir tout faire. Or, selon la loi de Pareto, ~20% des fonctionnalités répondent à ~80% des usages. Il est ainsi nécessaire de prioriser les besoins, afin de se concentrer sur les plus importants. Une stratégie est alors de déterminer l'ensemble minimal des fonctionnalités nécessaires au produit, le MVP (Minimum Viable Product), afin d'obtenir un produit exploitable le plus rapidement possible. Il est ensuite possible de faire évoluer le produit en fonction des retours, ou lui ajouter de nouvelles fonctionnalités par cycles itératifs.

Il est aussi possible de réaliser des maquettes, prototypes, ou preuves de concepts (PoC - Proof of Concept) pour faciliter les échanges avec le client sur la base d'éléments plus tangibles. On se concentre alors plus sur la structure visuelle de l'interface graphique, en simulant grossièrement les différentes actions. Par exemple, certaines maquettes pouvent se limiter à de simples slides de présentations.

UML

UML est un langage de modélisation graphique fournissant 14 types de diagrammes. Ces diagrammes sont utilisé à la fois pour réfléchir, communiquer, et documenter. Bien évidemment, ces diagrammes sont à utiliser en fonction des ressources et contraintes du projet. Un code de TP produit en 2 minutes dans le cadre d'un exercice, n'aura pas les mêmes contraintes qu'un code critique d'une centrale nucléaire.

Ainsi, même si UML est très utile en soit, tous les diagrammes ne le sont pas nécessairement pour tous les projets. Il convient donc de ne pas trop abuser de UML (death by UML fever).

Les cas d'utilisations

Le cahier des charges décrit, entres autres, les différentes fonctionnalités de système par le biais de cas d'utilisations. Un cas d'utilisations (use case) décrit, en langage non technique, un ensemble d'actions du système en vue d'une finalité. Il décrit notamment ses interactions avec les différents acteurs (≈ rôle assumé par une entité externe au système), e.g. :

"Passer commande : l'utilisateur rempli son panier, puis le valide avant de procéder au payement. Si l'utilisateur n'est pas connecté, une authentification lui sera demandée lors de la validation du panier."
⚠ Une action utilisateur, e.g. ajouter un produit au panier n'est pas une finalité en soit.

Dans ce cadre, UML fournit le diagramme de cas d'utilisation, afin de réfléchir aux différents usages et acteurs du système. Il permet une représentation graphique et synthétique de la liste des cas d'utilisations décrits dans le cahier des charges :

- expliquer formalisme de base

Astuce 1 : Vous pouvez utiliser des codes couleur, e.g. afin d'indiquer le niveau d'importance de chaque cas d'utilisation (e.g. pour le MVP).

Astuce 2 : Il est conseillé de préfixer les cas d'utilisations par une référence permettant d'en retrouver plus aisément la description dans le cahier des charges. e.g. "1.2 Visualiser un produit".

Astuce 3 : Ce diagramme doit rester visuel et lisible. Il ne faut ainsi pas hésiter à découper ce diagramme en plusieurs diagrammes, en regroupant les cas d'utilisations par acteurs, ou par groupes de fonctionnalités :

⚠ Bien évidemment, ce diagramme est peu utile si vous n'avez que peu de cas d'utilisations et/ou d'acteurs.

Activités

Pour décrire visuellement un cas d'utilisation, il est possible d'utiliser un diagramme d'activité où chaque noeud correspond à une action :

- expliquer formalisme de base Plus de détails https://laurent-audibert.developpez.com/Cours-UML/?page=diagramme-activites