LE CYCLE DE DEVELOPPEMENT EN V





  
.: Le cycle en V :.

Une des modélisations des cycles de développement courrament uyilisées est le cycle en V. Cette modélisation permet aisément de faire correspondre les étapes de conceptions aux étapes de tests et de validations. Sur la branche de gauche, on spécifie les étapes de conceptions jusqu’à l’implémentation (ou codage : écriture des modules en langage informatique) des modules. Sur la branche de droite, on peut voir les étapes de tests qui sont associées à une étape de conception. Par exemple, on contrôle que le système possède bien les fonctionnalités attendues ( Spécification système) lors de la phase de validation système.









  .: Détail des phases de conceptions :.

Spécification système : « Les fonctions que doit réaliser le système »
On établit un document permettant de traduire les besoins exprimées par le clients dans le cahier des charges en une listes d’exigences à la fois matériel et logiciel.



Spécification logiciel : « Les fonctions que doit réaliser le logiciel »
On répartit les exigences identifiées lors de la spécification systèmes entre les fonctionnalités qui devront être réalisées soit par le matériel soit par le logiciel.



Conception logiciel : « La manière dont est structuré le logiciel »
Cette conception est constituée de deux parties : la conception de haut niveau et la conception de bas niveau. La conception de haut niveau présente la structure générale du logiciel, quelle fonctionnalité est traitée par quel module. La conception de bas niveau détaille très précisément par quels moyens les fonctionnalités vont être traitées.



Codage : L’étape de codage n’est que la traduction des conceptions de bas niveau en un langage compréhensible par la machine.





  .: Détail des phases de tests :.

Tests unitaires : « Quel est le comportement du module ? »
On teste les modules un à un et séparément les un des autres. Le but est de vérifier si le comportement du module est conforme à la fonctionnalité attendue.



Intégration : « Le logiciel réagit-il correctement lorsqu’il est intégré au matériel ? »
Cette étape permet de vérifier si le logiciel s’adapte correctement sur la carte destinée à l’accueillir. On vérifie notamment que l’acquisition et la transmission des données sont correctes.



Validation logiciel : « Le logiciel répond il totalement aux besoins ?»
Cette étape permet de vérifier si le logiciel réalise toutes les fonctionalitées pour les quels il a été conçu.



·Validation système : « Les résultats sont-ils conformes aux spécifications systèmes ? »
On teste le calculateur sur un banc d’essai. Le banc permet de simuler les informations reçues par le calculateur dans l’avion. En effectuant les tests sur des plages de valeurs permettant de tester chaque fonctionnalité, on vérifie que les exigences établies lors de la conception système sont réalisées.





  .: Les risques de dérive :.

Les risques majeurs lors du développement sont, soit d’oublier une fonctionnalité, soit de mal l’implémenter. Pour minimiser le risque on crée des matrices de traçabilités, permettant d’obtenir la « généalogie » du projet. A chaque étape on précise quels sont les liens entre les éléments précédents et la redécomposition effectuée lors de la phase en cour.

De cette manière on évite d’oublier ou d’inventer une fonctionnalité. On peux descendre dans le cycle pour savoir comment une exigence a été décomposée pour être traitée, et inversement pour connaître l’utilité de chaque module. De plus il existe des matrices entre les phases de conception et leur équivalent en phase de tests, permettant de savoir par quel test l’exigence est validée.