Modèle en V également appelé modèle de vérification et de validation. En cela, chaque phase du SDLC doit être terminée avant le début de la phase suivante. Il suit un processus de conception séquentiel identique à celui du modèle en cascade. Les tests du dispositif sont prévus parallèlement à une étape de développement correspondante.
Vérification: Il s’agit d’une méthode d’analyse statique (révision) réalisée sans exécuter de code. Il s'agit du processus d'évaluation du processus de développement de produits visant à déterminer si les exigences spécifiées sont respectées.
Validation: Il s'agit d'une méthode d'analyse dynamique (fonctionnelle, non fonctionnelle), les tests se font en exécutant du code. La validation est le processus permettant de classer le logiciel une fois le processus de développement terminé afin de déterminer si le logiciel répond aux attentes et aux exigences du client.
Ainsi, le V-Model contient des phases de vérification d'un côté et des phases de validation de l'autre côté. Le processus de vérification et de validation est accompagné d'une phase de codage en forme de V. Il est donc connu sous le nom de modèle V.
Il existe les différentes phases de la phase de vérification du modèle en V :
| Analyse des besoins métiers : | Il s'agit de la première étape où les exigences du produit sont comprises du côté du client. Cette phase contient une communication détaillée pour comprendre les attentes et les exigences exactes du client.
| Conception du système : | À ce stade, les ingénieurs système analysent et interprètent les activités du système proposé en étudiant le document sur les exigences des utilisateurs.
| Conception architecturale : | La base de la sélection de l'architecture est qu'elle doit comprendre tout ce qui comprend généralement la liste des modules, les brèves fonctionnalités de chaque module, leurs relations d'interface, leurs dépendances, les tables de base de données, les diagrammes d'architecture, les détails technologiques, etc. Le modèle de test d'intégration est réalisé dans une phase particulière.
| Conception des modules : | Lors de la phase de conception des modules, le système se décompose en petits modules. La conception détaillée des modules est spécifiée, connue sous le nom de conception de bas niveau.
| Phase de codage : | Après la conception, la phase de codage est lancée. Sur la base des exigences, un langage de programmation approprié est décidé. Il existe certaines lignes directrices et normes pour le codage. Avant d'être archivé dans le référentiel, la version finale est optimisée pour de meilleures performances et le code passe par de nombreuses révisions de code pour vérifier les performances.
Il existe les différentes phases de la phase de validation du modèle en V :
| Tests unitaires : | Dans le modèle V, les plans de tests unitaires (UTP) sont développés pendant la phase de conception du module. Ces UTP sont exécutées pour éliminer les erreurs au niveau du code ou au niveau 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.
| Tests d'intégration : | Les plans de test d'intégration sont élaborés au cours de la phase de conception architecturale. Ces tests vérifient que des groupes créés et testés indépendamment peuvent coexister et communiquer entre eux.
| Test du système : | Les plans de tests du 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 composés par l'équipe commerciale du client. System Test garantit que les attentes d’un développeur d’applications sont satisfaites.
| Tests d'acceptation : | Les tests d'acceptation sont liés à la partie analyse des besoins métier. Cela comprend le test du produit logiciel dans une atmosphère utilisateur. Les tests d'acceptation révèlent les problèmes de compatibilité avec les différents systèmes disponibles dans l'environnement utilisateur. Il découvre également les problèmes non fonctionnels tels que les défauts de charge et de performances dans l'atmosphère réelle de l'utilisateur.
Quand utiliser le modèle V ?
- Lorsque l’exigence est bien définie et non ambiguë.
- Le modèle en forme de V doit être utilisé pour les projets de petite à moyenne taille où les exigences sont clairement définies et fixées.
- Le modèle en forme de V doit être choisi lorsque des exemples de ressources techniques possédant une expertise technique essentielle sont disponibles.
Avantage (avantages) du modèle V :
- Facile à comprendre.
- Les méthodes de test telles que la planification et la conception des tests se déroulent bien avant le codage.
- Cela fait gagner beaucoup de temps. D’où des chances de succès plus élevées par rapport au modèle en cascade.
- Évite le flux descendant des défauts.
- Fonctionne bien pour les petits plans où les exigences sont facilement comprises.
Inconvénient (Inconvénients) du modèle V :
- Très rigide et moins flexible.
- Pas bon pour un projet complexe.
- Le logiciel est développé pendant la phase de mise en œuvre, de sorte qu'aucun premier prototype du logiciel n'est produit.
- Si des changements surviennent à mi-chemin, les documents de test ainsi que les documents requis doivent être mis à jour.
