Cycle en V

AGGIL à la capacité de réaliser un projet en utilisant la méthode traditionnelle du cycle en V. Cette méthode est efficace quand les besoins utilisateurs sont clairement définis et que les interactions entre le client et les équipes de développement sont peu fréquentes. Si ces conditions ne sont pas réunies, il est préférable de mettre en place les méthodes agiles qui reprend le principe du cycle en V mais avec un autre séquencement.

Le cycle en V permet de tracer les besoins utilisateurs ou marketing, sur l'ensemble des étapes de réalisation et de vérification, et de façon chronologique dans tout le cycle de développement logiciel.

Les étapes de réalisation

Le cahier des charges

Ce document est essentiel pour la réussite d'un projet en cycle en V. Ce document est réalisé en général par le client, et peut éventuellement être sous traité dans le cadre d'une prestation de conseil en assistance à maitrise d'ouvrage, dans une prestation "d'assistance à la rédaction de cahier des charges"

Le cahier des charges décrit l'ensemble des exigences fonctionnelles attendues par le système. Ces exigences sont la description du besoin utilisateur vis à vis du système final.

La Spécification

Il est souvent nécessaire de préciser avec exactitude le besoin utilisateur en reprenant les éléments du cahier des charges et en décrivant les exigences de façon exhaustive, et sans ambiguïté. Des méthodes de notations sont utilisées comme les cas d'utilisation UML, ou simplement un document word avec des exigences numérotés.

La Conception Général

Le document de conception général décrit l'ensemble de l'architecture du futur logiciel. Il décompose en grands modules, ou composants le fonctionnement du logiciel, ainsi que l'interaction des composants entre eux. En programmation objets, (.net C#, C++, Java, php objet...), les notations UML "Diagramme de séquence", et "diagramme de classe" sont généralement utilisées.

La conception détaillée

Souvent utilisée dans la réalisation de logiciels industriels critiques (mettant en jeu la vie de l'homme), cette étape consiste à rédiger un document formel qui décrit l'algorithme, c'est à dire l'enchainement des instructions, qui seront par la suite codée lors des développements. La conception détaillée est très rarement utilisée en développement de systèmes d'information, mais essentielle lors de la réalisation de tests unitaires dits "boites noir".

Le codage

Ultime étape de la réalisation, le codage ou développement informatique, est la transcription en langage interpretable par un compilateur, ou un exécuteur de script, de la conception détaillée, en utilisant un langage normé comme le Java, le C++, PHP...

A la fin du codage, le logiciel pourrait être terminé, mais il contient toujours un ensemble de dysfonctionnements (bugs) qu'il est nécessaire de détecter et de corriger. La phase de test est la deuxième partie montante chronologiquement, du V.

Les étapes de vérification

A chacune des étapes de réalisation descendante de la première partie du V est associée une méthodologie de test permettant de vérifier que chaque étape de réalisation a bien les résultats attendue.

Les tests unitaires

Les tests unitaires permettent de vérifier qu'il n'existe pas d'erreur entre la transcription de la conception détaillée vers le code. Il existe une vaste possibilité de test unitaires :

• Les tests unitaires non formalisés

Le développeur ne réalise pas de document, ni de script spécifique pour vérifier que le code fonctionne bien. Il doit imaginer des scénarios de test qu'il va faire fonctionner sur son code compilé, en fixant des valeurs spécifiques à ses variables, pour que le programme exécute un cheminement dont le développeur doit prévoir le résultat dans les variables de sortie de ses algorithmes. Pour ce faire, il réalise des IHM temporaires, ou réalise des bouchons, c'est à dire le codage en dur de variables, et il vérifie d'après ses calcul que le résultat attendu est bien le résultat prévu. Ce type de TU (Test Unitaires) ne peut être exhaustif, et ne permet pas de prouver que les test unitaires ont bien été réalisés.

• Les Test unitaires boite grise

On parle de boite grise lorsque l'on formalise les tests unitaires par une document ou par des scripts, mais que le développeur à besoin du code pour coder sont test. Le principe est de rajouter du code dédié aux tests unitaires à l'intérieur du code fonctionnel. Ce nouveau code est une "sonde" permettant d'injecter des valeurs spécifiques aux variables d'entrées d'une fonction à tester et de pouvoir lire par une "sonde" de sortie le résultat des valeurs calculées par la fonction. Un système de script permet généralement d'utiliser ces sondes pour jouer des scénarii de test et vérifier automatiquement que les résultats obtenus sont conformes aux résultats attendus. Les technologies NUnit (.net), CPPUnit (C++), JUnit (Java), DUnit (Delphi) sont généralement utilisées pour ces méthodologies de test par surcharge des classes.

• Tests Unitaires boite Noire

Rarement utilisés en Système d'information, mais obligatoire en informatique critique notamment en aéronautique (DO-178B), ferroviaire (EN 50128) ou nucléaire, les tests boites noir permettent d'écrire le test sans avoir accès au code. Ces tests permettent de démontrer que la couverture de test est atteinte à 100%. Il est indispensable d'avoir dans ce cas, un document de conception détaillée qui permette de déterminer - sans regarder le code- toutes les branches d'exécution du code, et pour chaque chemin, les conditions d'entrées dans la branche, et les valeurs de sortie estimées. Ces dernières valeurs ne doivent en aucun cas être calculées par le code, mais calculée d'une autre façon (calcul mental, excel, Matlab...) Une fois tous les cas de tests définis, on prend le code source, et on remplace les variables des fonctions codées par des bouchons en dur permettant de forcer l'affectation des variables par les conditions d'entrées initialement définies dans les cas de test. De la même façon on insère dans le code des sondes permettant de lire le résultat des fonctions. La fonction bouchonnée est alors compilée séparément et on procède à la vérification du résultat des valeurs obtenues par l'algorithme compilé, en regards aux résultats estimés calculés.

Les tests d'intégration

Cette étape permet de vérifier qu'il n'existe pas d'erreur entre le document de conception générale et le document de conception détaillée. Le but de ces tests est de vérifier toutes les possibilités de communication entre les différents composants ou modules définis dans l'architecture. Dans la pratique des vrais tests d'intégration avec une couverture de test à 100% sont quasiment impossible vu le nombre de possibilité de cas de test. Ainsi, même en informatique embarquée critique, les tests d'intégration se limitent à la compilation de l'ensemble des sources du référentiel, et au passage de quelques tests d'intégration qui ne mettent en œuvre qu'un chemin d'arborescence conditionnelle au travers chaque composant.

Les tests de validation

Ces tests permettent de vérifier qu'il n'existe pas d'erreur entre le document de spécification des exigences et le document de conception générale. Chaque exigence de la spécification doit être couverte par un test fonctionnel. Ce test fonctionnel est réalisé en suivant un scénario qui décrit les manipulation à réaliser avec le logiciel testé et le résultat attendu.

Les tests de recette

La recette est un ensemble de tests fonctionnels de haut niveau en regard avec les exigences décrites dans le cahier des charges. Le passage avec succès de ces tests permettent la validation du projet, et du paiement (la recette) de l'échéance financière associée.