cascade

Cet article est consacré à la méthode classique de la gestion de projet « Waterfall » ou « Cascade » en français.

Cette méthode traditionnelle implique des phases séquentielles tout au long du projet. C’est-à-dire qu’on ne peut pas commencer une nouvelle étape sans finir la précédente.

Ce modèle a été décrit en 1970 dans l’article de Winston Walker Royce, informaticien américain. Et en 1976 ce sont Thomas Bell et Thomas Thayer qui l’ont nommé Waterfall.

Comme nous l’avons déjà mentionné dans l’article « Introduction à la méthodologie Agile » cette méthode a été utilisé par les développeurs pour les militaires. Elle a ensuite cédé sa place à Agile, bien sûr la méthode de Cascade n’est pas totalement morte, elle est utilisée dans les projets de développement qui nécessitent une phase de conception avant développement et les projets qui ne sont pas sujet à d’innombrables changements. Aujourd’hui cette méthode classique est toujours utilisée dans la médecine, le domaine militaire, dans l’aéronautique, dans le secteur financier, dans la construction des bâtiments.

Selon W.W.Royce un projet en cascade se déroule généralement en cinq étapes :

  • Exigences et analyse : le client exprime ses besoins au prestataire, le chef de projet cherche l’équipe qualifié pour le projet, évalue le délai et calcule son coût. Ensuite il rédige le cahier des charges qui est signé par les deux parties et qui est le document principal de la réalisation de projet 
  • Conception : le chef de projet accompagne son équipe dans la création des éléments graphiques et textuels à partir desquels le produit sera développé 
  • Développement : l’équipe crée le produit à partir des éléments réalisés en phase de conception 
  • Tests : pendant cette étape on regarde si le produit répond aux exigences exprimées dans le cahier des charges, on élimine les bugs 
  • Déploiement : le produit est livré conformément aux attentes du client et il suffit de maintenir ou de le faire évoluer.

Toutes ces étapes vont l’une après l’autre et il est interdit d’omettre une étape. La séquence de processus, le respect des délais, la réalisation des tâches dans le modèle Cascade sont mieux présentés par le diagramme de Gantt ou par le graphique de barres horizontales.  

Avantages de la méthodologie de la Cascade

La méthodologie de la cascade est une méthodologie complexe de tenue de registres. Mais cette documentation fera aussi gagner un temps précieux.

  • La cascade est un processus séquentiel et bien structuré.
  • Il s’agit d’un modèle de développement simple et facile à comprendre et à utiliser.
  • Il n’est modifiable à aucune étape et est facile à gérer en raison de sa cohérence.
  • Les exigences sont très claires et faciles à appréhender avant même le développement.
  • Chaque partie divisée est terminée dans la période de temps spécifiée.
  • La mise en œuvre est facile en raison du modèle linéaire.
  • Moins de ressources sont nécessaires pour utiliser le modèle de cascade.
  • La qualité du développement est meilleure grâce à une documentation appropriée.
  • Ce processus nécessite des exigences clairement définies.
  • Dans la méthode Cascade, les clients connaissent la taille, le coût et le calendrier des projets.
  • En raison d’une documentation solide, tout type de roulement de personnel n’affectera pas le projet.
  • Cette méthodologie est très utile pour gérer les dépendances.

Inconvénients de la méthodologie de la Cascade

  • En cascade, les problèmes d’une phase ne sont jamais entièrement résolus pendant cette phase. De nombreux autres problèmes concernant une phase particulière surviennent après sa validation, ce qui se traduit par un système mal structuré.
  • Ce processus ne permet pas d’implémenter des modifications pendant le processus de développement en cours.
  • La mise en œuvre ne peut être testée qu’une fois le projet terminé. Cela peut coûter plus cher en cas de détection de bugs.
  • La cascade est un mauvais modèle de développement pour les projets en cours et de longs termes.
  • La cascade dépend des exigences initiales, si ces exigences sont défectueuses, tout le projet échoue.
  • Dans cette méthodologie, l’ensemble du projet est finalement testé. Si un bug est détecté lors des tests, il y a des chances que toute l’équipe doive recommencer dès le début le processus.
  • Il est coûteux d’apporter des modifications au programme.
  • L’équipe est moins motivée et investie que dans une méthode agile.
  • L’ensemble du projet est terminé dans une séquence, il n’y a donc aucune chance de lancer le programme plus tôt.
  • Habituellement, cette technique est coûteuse en raison des coûts de replanification. Vers la fin du projet les besoins du client ou d’utilisateurs finaux ont changés et le produit perd de sa valeur.

agile apdev brumatinale carpentras cascade clean-up day crm developpement erp foire d'automne gestion de projet humour logiciel logiciel standard logiciel sur-mesure monteux méthodologie nouveaux locaux projet travail webdev windev windev mobile

Un projet à étudier ? Des questions ?

N’hésitez pas à nous contacter.