2.5 Phases de la modélisation, cycle en V

    précédent     suivant 

Le schéma présente le cycle en V du développement d’un système informatique. Le cycle en V vous est déjà familier car vous l’avez rencontré pour la programmation procédurale lors du module CSC3502. Il est également utilisé en orienté objet. L’informatisation débute par l’établissement du cahier des charges avec le client suivi de l’analyse qui a pour but de modéliser le problème. Puis, la conception modélise la solution technique ; elle est suivie par la réalisation du logiciel conforme à la solution. UML est un langage graphique aisément compréhensible par le client ; le client peut donc comprendre la modélisation du problème, même s’il ne comprend pas toute la modélisation de la solution qui peut être plus « technique ». Ainsi se termine la partie gauche du cycle en V. La partie droite consiste en la vérification du logiciel construit par une série de tests et la recette par le client du produit fini. Il est important de noter que les différentes phases sont souvent réalisées par des équipes ou des personnes différentes. Par exemple, les vérifications par les tests ne sont en général pas effectuées par les mêmes personnes que celles ayant réalisées le logiciel à tester : cela renforce la confiance dans le produit fini en évitant le biais de l’auto-vérification. Le plus souvent, les différents tests sont spécifiés par les équipes qui modélisent le problème et conçoivent la solution, mais ils sont exécutés par les équipes qui opèrent les vérifications. À titre indicatif, il existe une méthodologie appelée « développement conduit par les tests » (en anglais, test-driven development) qui consiste, dans la phase d’implantation, à « écrire » les tests avant d’écrire les fonctions à tester. Par ailleurs, le code écrit est évalué qualitativement lors de ce que l’on appelle une revue de code.

Dans le cadre du module CSC4002, dans les cours (UML et Java) puis lors des bureaux d’étude UML et des travaux pratiques Java, nous étudions toutes les phases allant de l’analyse à la validation avec les mêmes cas d’étude : « système de vote Studs » pour le cours et « gestion d’une médiathèque » pour les bureaux d’étude et les travaux pratiques. L’unicité du cas d’étude dans le cours puis dans les bureaux d’étude et les travaux pratiques permet de renforcer la cohérence entre les différentes séances et de montrer sur un exemple quelque peu réaliste, c’est-à-dire d’une taille non négligeable, la méthodologie.

Avertissement : il est important de garder en mémoire tout au long de ce module que la méthodologie proposée n’est qu’une parmi beaucoup d’autres et que des choix différents peuvent être effectués quant à l’utilisation dans telle ou telle phase du processus de développement de tel ou tel type de diagramme.

Cf. le glossaire pour la définition du terme « processus de développement ».

D. Conan, C. Taconet, C. Bac, Télécom SudParis, CSC 4002, Octobre 2015