Modèle en V (développement de logiciels)

Dans le développement de logiciels , le modèle en V représente un processus de développement qui peut être considéré comme une extension du modèle en cascade et est un exemple du modèle en V plus général . Au lieu de se déplacer de manière linéaire vers le bas, les étapes du processus sont courbées vers le haut après la phase de codage , pour former la forme en V typique. Le modèle en V démontre les relations entre chaque phase du cycle de vie du développement et sa phase de test associée . Les axes horizontaux et verticaux représentent respectivement le temps ou l'achèvement du projet (de gauche à droite) et le niveau d'abstraction (abstraction la plus grossière en haut).

Dans la phase d'analyse des exigences , première étape du processus de vérification, les exigences du système sont collectées en analysant les besoins des utilisateurs . Cette phase vise à établir les performances du système idéal. Cependant, elle ne détermine pas la manière dont le logiciel sera conçu ou construit. En général, les utilisateurs sont interrogés et un document appelé document des exigences utilisateur est généré.

Le document des exigences utilisateur décrit généralement les exigences fonctionnelles, d'interface, de performances, de données, de sécurité, etc. du système telles qu'attendues par l'utilisateur. Il est utilisé par les analystes commerciaux pour communiquer leur compréhension du système aux utilisateurs. Les utilisateurs examinent attentivement ce document car il servira de ligne directrice aux concepteurs du système dans la phase de conception du système. Les tests d'acceptation utilisateur sont conçus dans cette phase. Voir également Exigences fonctionnelles .

Il existe différentes méthodes pour recueillir les exigences des méthodologies souples et dures, notamment : les entretiens, les questionnaires, l'analyse de documents, l'observation, les prototypes jetables, les cas d'utilisation et les vues statiques et dynamiques avec les utilisateurs.

La conception des systèmes est la phase au cours de laquelle les ingénieurs système analysent et comprennent le fonctionnement du système proposé en étudiant le document des exigences de l'utilisateur. Ils déterminent les possibilités et les techniques permettant de mettre en œuvre les exigences de l'utilisateur. Si l'une des exigences n'est pas réalisable, l'utilisateur est informé du problème. Une solution est trouvée et le document des exigences de l'utilisateur est modifié en conséquence.

Le document de spécifications du logiciel qui sert de modèle pour la phase de développement est généré. Ce document contient l'organisation générale du système, les structures de menus, les structures de données , etc. Il peut également contenir des exemples de scénarios commerciaux, des exemples de fenêtres et des rapports pour faciliter la compréhension. D'autres documents techniques tels que des diagrammes d'entités et des dictionnaires de données seront également produits au cours de cette phase. Les documents pour les tests du système sont préparés.

La phase de conception de l'architecture informatique et de l'architecture logicielle peut également être appelée conception de haut niveau. La base de sélection de l'architecture est qu'elle doit réaliser tout ce qui se compose généralement de la liste des modules, des fonctionnalités brèves de chaque module, de leurs relations d'interface , des dépendances , des tables de base de données , des diagrammes d'architecture, des détails technologiques, etc. La conception des tests d'intégration est réalisée dans cette phase particulière.

La phase de conception du module peut également être appelée conception de bas niveau. Le système conçu est divisé en unités ou modules plus petits et chacun d'eux est expliqué afin que le programmeur puisse commencer à coder directement. Le document de conception de bas niveau ou les spécifications du programme contiendront une logique fonctionnelle détaillée du module , en pseudo-code :

• tables de base de données, avec tous les éléments, y compris leur type et leur taille
• tous les détails de l'interface avec des références API complètes
• tous les problèmes de dépendance
• listes de messages d'erreur
• entrées et sorties complètes pour un module.

La conception des tests unitaires est développée à ce stade.

Dans le modèle en V, chaque étape de la phase de vérification a une étape correspondante dans la phase de validation. Voici les phases typiques de validation dans le modèle en V, bien qu'elles puissent être connues sous d'autres noms.

Dans le modèle en V, les plans de tests unitaires (UTP) sont développés pendant la phase de conception du module. Ces UTP sont exécutés pour éliminer les bugs au niveau du code ou de l'unité. Une unité est la plus petite entité qui peut exister indépendamment, par exemple un module de programme. Les tests unitaires vérifient que la plus petite entité peut fonctionner correctement lorsqu'elle est isolée du reste des codes/unités.

Les plans de tests d'intégration sont élaborés lors de la phase de conception architecturale. Ces tests vérifient que les unités créées et testées indépendamment peuvent coexister et communiquer entre elles. Les résultats des tests sont partagés avec l'équipe du client.

Les plans de tests système sont élaborés pendant la phase de conception du système. Contrairement aux plans de tests unitaires et d'intégration, les plans de tests système sont élaborés par l'équipe métier du client. Les tests système garantissent que les attentes de l'application développée sont satisfaites. L'ensemble de l'application est testé pour sa fonctionnalité, son interdépendance et sa communication. Les tests système vérifient que les exigences fonctionnelles et non fonctionnelles ont été respectées. Les tests de charge et de performance, les tests de stress, les tests de régression , etc., sont des sous-ensembles des tests système.

Les plans de test d'acceptation utilisateur (UAT) sont élaborés au cours de la phase d'analyse des exigences. Les plans de test sont élaborés par les utilisateurs professionnels. L'UAT est effectué dans un environnement utilisateur qui ressemble à l'environnement de production, à l'aide de données réalistes. L'UAT vérifie que le système livré répond aux exigences de l'utilisateur et que le système est prêt à être utilisé en temps réel.

Le modèle en V a été critiqué par les partisans d'Agile et d'autres comme étant un modèle inadéquat de développement logiciel pour de nombreuses raisons. Les critiques incluent :

1. Il est trop simple de représenter avec précision le processus de développement logiciel et peut donner aux gestionnaires un faux sentiment de sécurité. Le modèle en V reflète une vision de gestion de projet du développement logiciel et répond aux besoins des chefs de projet, des comptables et des avocats plutôt qu'aux besoins des développeurs ou des utilisateurs de logiciels.
2. Bien que ce modèle soit facilement compris par les novices, cette compréhension précoce n'est utile que si le novice acquiert par la suite une compréhension plus approfondie du processus de développement et de la manière dont le modèle en V doit être adapté et étendu dans la pratique. Si les praticiens persistent dans leur vision naïve du modèle en V, ils auront beaucoup de mal à l'appliquer avec succès.
3. Il est inflexible et encourage une vision rigide et linéaire du développement logiciel et n’a aucune capacité inhérente à répondre au changement.
4. Il ne s'agit que d'une légère variante du modèle en cascade et est donc sujet aux mêmes critiques que ce dernier. Il met davantage l'accent sur les tests, et en particulier sur l'importance de la planification des tests en amont. Cependant, une critique pratique courante du modèle en V est qu'il conduit à insérer les tests dans des fenêtres étroites à la fin du développement, lorsque les premières étapes ont dépassé leur date d'implémentation, mais que celle-ci reste fixe.
5. Elle est cohérente avec les approches inefficaces et peu efficientes des tests et les encourage donc implicitement. Elle encourage implicitement la rédaction de scripts de test à l'avance plutôt que les tests exploratoires ; elle encourage les testeurs à rechercher ce qu'ils s'attendent à trouver, plutôt que de découvrir ce qui s'y trouve réellement. Elle encourage également un lien rigide entre les niveaux équivalents de chaque branche (par exemple, les plans de test d'acceptation utilisateur dérivés des documents d'exigences utilisateur), plutôt que d'encourager les testeurs à sélectionner la manière la plus efficace et la plus efficiente de planifier et d'exécuter les tests.
6. Il manque de cohérence et de précision. Il existe une confusion générale sur ce qu'est exactement le modèle en V. Si on le réduit aux éléments sur lesquels la plupart des gens s'accordent, il devient une représentation banale et inutile du développement logiciel. Les désaccords sur les mérites du modèle en V reflètent souvent un manque de compréhension commune de sa définition.

Les partisans du modèle en V affirment qu'il a évolué et qu'il favorise la flexibilité et l'agilité tout au long du processus de développement. Ils soutiennent qu'en plus d'être une approche hautement disciplinée, il favorise une conception, un développement et une documentation méticuleux nécessaires à la création de produits logiciels stables. Dernièrement, il est adopté par l'industrie des dispositifs médicaux.