le modèle de cascade est une approche linéaire et séquentielle du cycle de vie du développement logiciel (SDLC) qui est populaire dans l’ingénierie logicielle et le développement de produits. Le modèle en cascade met l’accent sur la progression des étapes. À l’instar de la direction de l’écoulement de l’eau sur le bord d’une falaise, des points d’extrémité ou des objectifs distincts sont fixés pour chaque phase de développement et ne peuvent pas être revus après l’achèvement. Le terme a été introduit pour la première fois dans un article publié en 1970 par le Dr Winston W., Royce et continue d’être utilisé dans des applications de design industriel.
la méthodologie waterfall est composée de sept étapes qui ne se chevauchent pas:
- exigences: exigences potentielles, délais les lignes directrices pour le projet sont analysées et placées dans une spécification fonctionnelle. Cette étape gère la définition et la planification du projet sans mentionner de processus spécifiques.
- analyse: les spécifications du système sont analysées pour générer des modèles de produits et les entreprises guideront la production. C’est également à ce moment que les ressources financières et techniques sont vérifiées pour en vérifier la faisabilité.,
- conception: un document de spécification de conception est créé pour décrire les exigences techniques de conception telles que le langage de programmation, le matériel, les sources de données, l’architecture et les services.
- codage / mise en œuvre: la source développée en utilisant les modèles, les exigences logiques désignées dans les étapes précédentes. En règle générale, le système est conçu en composants plus petits, ou unités, avant d’être mis en œuvre ensemble.
- Test: c’est à ce moment que des tests d’assurance Qualité, unitaires et bêta ont lieu pour signaler les problèmes qui pourraient devoir être résolus. Cela peut entraîner une répétition forcée de l’étape de codage pour le débogage., Si le système réussit les tests, la cascade continue vers l’avant.
- Fonctionnement/Déploiement: Le produit ou l’application est considéré comme entièrement fonctionnel et est déployé dans un environnement réel.
- Maintenance: la maintenance Corrective, adaptative et perfective est effectuée indéfiniment pour améliorer, mettre à jour et améliorer le produit final. Cela pourrait inclure la publication ou la publication de nouvelles versions.,
Avant de passer à la phase suivante, il est généralement un examen et d’approbation afin de garantir que tous les objectifs définis ont été atteints.
l’approche en cascade est idéale pour les projets qui ont une documentation spécifique, des exigences fixes, des ressources suffisantes, un calendrier établi et une technologie bien comprise. Les Alternatives au modèle en cascade comprennent le développement conjoint d’applications (JAD), le développement rapide d’applications (RAD), la synchronisation et la stabilisation, la gestion de projet Agile (APM) et le modèle spiral.,
avantages du modèle waterfall
bien que les méthodes agiles ou dynamiques remplacent souvent le modèle waterfall, il existe certains avantages:
- Les étapes initiales de documentation et de planification permettent aux équipes importantes ou changeantes de rester informées et d’avancer vers un objectif commun.
- Forces, organisation disciplinée.
- est simple à comprendre, à suivre et à organiser les tâches.
- facilite la départementalisation et le contrôle de gestion en fonction du calendrier ou des délais.
- renforce les bonnes habitudes de codage à définir avant la conception, puis le code.,
- permet d’effectuer facilement des modifications précoces de conception ou de spécification.
- définit Clairement les étapes et les délais.
les Inconvénients du modèle en cascade
Les inconvénients du modèle en cascade immanquablement les risques associés à un manque de révision, y compris:
- n’est pas adaptative; souvent, quand une faille est trouvée, l’ensemble du processus doit recommencer.
- ignore la possibilité de recevoir des commentaires d’utilisateurs ou de clients en milieu de processus et d’apporter des modifications en fonction des résultats.
- retarde les tests jusqu’à la fin du cycle de vie du développement.,
- ne considère pas la correction d’erreur.
- ne gère pas bien les demandes de modifications, d’ajustements de portée ou de mises à jour.
- réduit l’efficacité en ne permettant pas aux processus de se chevaucher.
- aucun produit fonctionnel n’est disponible avant les étapes ultérieures du cycle de vie.
- pas idéal pour les projets complexes, à haut risque, en cours ou orientés objet.