Le modèle V est une extension du modèle Waterfall, alors ne vous attendez pas à ce qu'il soit extrêmement différent.
Fondamentalement, vous suivez le modèle V de gauche à droite , tout comme dans le modèle Waterfall. Dans Waterfall, vous faites les exigences, la conception, la mise en œuvre, la vérification et enfin la maintenance. De la même manière, en V-model, vous faites les exigences, la conception, l'implémentation, la vérification et la maintenance: mêmes étapes dans les deux cas.
Les principales différences avec Waterfall sont la façon dont il est présenté et l'accent mis sur les tests.
Représenter le flux sous forme de V permet de faire la différence entre tout ce qui précède le codage (exigences, architecture et conception) et tout ce qui suit le codage (essentiellement les tests). Bien que les tests ne soient qu'une des cinq étapes de Waterfall, cela ressemble à pratiquement la moitié du processus dans le modèle V.
Le schéma de votre question est un peu plus compliqué. Ce qu'il essaie de montrer, c'est que, par exemple, l'étape de conception du système conduit non seulement au document de conception du système, comme le suggère le modèle Waterfall, mais également à la conception des tests du système, qui aidera plus tard à écrire des tests du système. Le diagramme met encore plus l'accent sur les tests . Enfin, la conception de tests système aide à la conception d'architecture (il serait difficile de faire la conception d'architecture indépendamment de la conception de test du système).
En cherchant quelles autres explications sur Internet, je ne peux pas éviter de citer l'article suivant de Bhakti Satalkar :
La principale différence entre le modèle en cascade et le modèle V est que dans le modèle en cascade, les activités de test sont effectuées après la fin des activités de développement. En revanche, dans le modèle V, les activités de test commencent par la première étape elle-même. En d'autres termes, le modèle en cascade est un processus continu, tandis que le modèle V est un processus simultané. Par rapport à un logiciel créé en utilisant un modèle en cascade, le nombre de défauts dans le logiciel créé en utilisant le modèle V est moindre. Cela est dû au fait qu'il existe des activités de test, qui sont effectuées simultanément dans le modèle V. Par conséquent, le modèle en cascade est utilisé, lorsque les exigences de l'utilisateur sont fixes. Si les exigences de l'utilisateur sont incertaines et changent constamment, le modèle V est la meilleure alternative.
Cette explication est trompeuse . Ce ne serait vrai que si vous remplacez «modèle V» dans le devis par une méthode Agile.
Contrairement aux états de l'article, dans le modèle V, les tests sont effectués après le codage; par exemple, voir Wikipedia :
une critique pratique courante du V-Model est qu'il conduit à des tests serrés dans des fenêtres étroites à la fin du développement lorsque les étapes précédentes ont dépassé, mais la date de mise en œuvre reste fixe.
Alors que, dans le modèle V, la conception des tests système suit la conception du système sans attendre la mise en œuvre du produit, cela ne signifie pas que les tests eux-mêmes sont effectués avant le codage. L'auteur confond V-modèle avec des approches Agiles comme le Test Driven Development (TDD) dans Extreme Programming (XP).
V