Différence entre VModel et Waterfall Model
- 2374
- 154
- Juliette Lacroix
Modèle VModel vs Waterfall
L'un des débats les plus anciens de l'ingénierie logicielle est le débat entre la cascade contre le modèle V. Ce débat tourne autour du meilleur modèle logiciel que les développeurs peuvent utiliser. Il existe différentes phases qui sont impliquées dans le processus de développement logiciel. Les phases sont similaires à la fois dans la cascade et le modèle V, et la seule chose qui a jusqu'à présent été controversée est l'approche à laquelle ces deux modèles peuvent être obtenus par.
Dans le modèle V, il y a beaucoup d'activités qui, lorsqu'elles sont tracées ensemble sur un diagramme schématique, forment une forme V. Chaque phase qui est dite a une phase correspondante impliquée dans les tests. Ce modèle en raison du nombre égal de tests et de développement est appelé le modèle de vérification et de validation. Le côté vérification traite de la fin du développement tandis que la validation traite des phases de test. Parmi les activités dans lesquelles la vérification tombe en cours d'inclusion, y compris l'analyse des exigences où les informations sont recueillies auprès de l'utilisateur final. Ces informations sont importantes dans le développement de la documentation logicielle.
La prochaine étape est la conception du système, qui vise à préparer la conception fonctionnelle des logiciels. La prochaine chose qui suit est la conception architecturale. Ceci est également appelé conception de haut niveau que la relation d'interface et les tables de base de données et les dépendances des tables. La dernière étape du processus de développement est le codage où l'ensemble du projet est divisé en petites sections de codage qui sont ensuite fusionnées pour créer l'ensemble du système.
Le côté validation, de l'autre côté, a quatre étapes comme au stade de vérification. Ces phases commencent par les tests unitaires, puis les tests d'intégration, les tests système et enfin les tests d'acceptation de l'utilisateur où l'ensemble du système est évalué dans son ensemble.
Le modèle de cascade est la première procédure de développement logiciel, avec son origine provenant des industries de la fabrication et de la construction. Le concept de base de ce processus est qu'il existe un flux séquentiel de processus qui s'allument les uns après les autres, comme on le voit dans une cascade. Ces phases du modèle de cascade comprennent la collecte et l'analyse des exigences où les exigences du client sont recueillies. Cette étape conduit à la phase de conception, où la plupart du logiciel est créé, puis la phase d'implémentation où le code logiciel est écrit. La phase qui suit est le test et le débogage, conduisant à la livraison et enfin à la phase de maintenance.
La principale différence notée entre les deux modèles est que les activités de test sont effectuées une fois le développement terminé. Le modèle V semble ressembler à un modèle qui a un début et une fin donnés tandis que le modèle de cascade est continuellement itératif. Le modèle V diffère en étant un processus simultané. À partir des différents logiciels qui ont été produits sur le marché, les logiciels produits en utilisant le processus V semblent plus bas, car il existe de nombreuses activités de test par opposition au modèle de cascade qui a une seule phase de test lorsque le projet est terminé.
On peut donc dire que l'utilisation du modèle V est préférée chaque fois qu'il y a des changements continus qui doivent être inclus. C'est pour une personne ou un développement qui a le client instable quant aux besoins de son projet, car il continue de changer ce qu'il perçoit comme étant idéal. Les personnes ayant des exigences fixes qui ne changeront pas dans la phase de développement du projet devraient se contenter du modèle de cascade. Il est également important de noter que les changements dans le modèle V sont bon marché à mettre en œuvre car le test est et le développement est effectué simultanément. Ce n'est pas le cas du modèle Waterfall, qui a tendance à être une affaire coûteuse, car les défauts logiciels ne peuvent pas être remarqués jusqu'à ce qu'il arrive à la phase de test.