Quelqu'un peut-il expliquer le processus du modèle V? Pourquoi est-il différent du modèle Waterfall?
Il semble que le modèle V soit juste le modèle Waterfall avec la moitié inférieure de la cascade pliée vers le haut pour former un V. Je ne vois pas comment cela ajoute quelque chose de nouveau.
D'après les diagrammes, je ne comprends pas non plus le flux. Il y a des flèches pointant dans toutes les directions et je ne comprends pas ce qui vient en premier. Suivons-nous le V en haut à gauche, en bas au centre puis en remontant en haut à droite? Ou progressons-nous sur le V en faisant tout plus haut avant que l'élément ne baisse?
Internet manque d'une explication suffisante de ce modèle. Ce serait génial si quelqu'un pouvait l'expliquer sous une vraie forme StackExchange :)
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 dans 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 simplement 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 système).
En cherchant quelles autres explications sur Internet, je ne peux pas éviter de citer l'article suivant par Bhakti Satalkar :
La principale différence entre le modèle en cascade et le modèle en 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 coincés dans des fenêtres étroites à la fin du développement lorsque les étapes précédentes ont dépassé mais que le 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-model avec des approches Agiles comme le Test Driven Development (TDD) dans Extreme Programming (XP).