Réflexion sur la méthodologie en V


Méthodologie en V

Méthodologie en V

Voici une amélioration de la méthodologie Waterfall (ou cascade). Donc en résumé, on prend la méthodologie Waterfall, qu’on découpe en 9 étapes au lieu de 7 et chacune des étapes est relier à une autre. Si l’étape échoue, on est redirigé vers une autre étape précise. Tout le restant de la méthodologie n’a pas été modifié. L’objectif étant de pallier au problème que si une étape est mal faite, les autres étapes subissent les conséquences.

Introduction

Bon, je ne réexpliquerai pas l’introduction qui est la même que le Waterfall, donc allé plutôt lire à cet endroit. Par contre, voici les différences. Habituellement je mets une image pour faire jolie dans les articles, mais ce coup-ci, vous en aurez de besoins pour bien comprendre le fonctionnement.

Le diagramme se lit de gauche à droite et forme un V. Ce sont les 9 itérations : Analyse et Faisabilité, Spécifications, Conception architecturale, Conception détaillée, Codage, Tests unitaires, Tests d’intégration, Tests de validation et Recette. Comme on peut déjà voir, certaines étapes ont été subdivisées en 2 et les tests ont été grandement améliorés. En plus d’avoir amélioré le nombre d’étapes à suivre, un nouveau concept de problème est apparu. Si un problème apparait sur l’une des étapes à droite du V, le projet sera retourné à l’itération située à sa gauche. Donc si le test d’intégration est échoué, c’est que probablement le problème arrive de la conception architecturale. Le problème peut arriver d’une des étapes supérieures, mais au minimum le problème arrive de cette étape. Donc, la personne responsable devra revérifier et ensuite renvoyer de nouveau à la phase suivante dans le V. On peut vite se rendre compte qu’un projet en problème risque de rester pris dans la base du V. Si un projet passe trop de fois au codage, quelqu’un devrait finir par avertir un supérieur de la situation.

Avantages

  • Très facile à comprendre
  • Simple à expliquer aux clients
  • Un livrable doit être fait qui est débuté à l’étape 1 et qui est complété après chacune des étapes
  • Évite la problématique d’une étape manquée qui est présente au Waterfall
  • Quantité de tests grandement augmentée
  • Excellent pour des projets internes

Désavantages

  • Difficile à gérer pour éviter les bouchons de travail, surtout à la base du V
  • Impossibilité au client de demander une modification
  • Impossibilité de gérer plusieurs projets en série ou en parallèle, sinon une congestion aura lieu

Conclusion

Exactement la même conclusion que pour le Waterfall. Problème d’optimisation. Malgré que la méthodologie est adaptée pour des projets internes, elle est trop lourde à mettre en place et ne rivalise pas avec une méthodologie Agile comme Scrum.

Avez-vous déjà travaillé avec cette méthode ?

Maxime Savard

Liste des différentes méthodologies

Advertisements

Laisser un commentaire

Entrer les renseignements ci-dessous ou cliquer sur une icône pour ouvrir une session :

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l’aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s