le modèle de cascade est une approche classique du développement logiciel qui décrit une méthode de développement linéaire et séquentielle. Il se compose de cinq à sept phases, chaque étape est définie par des tâches et des objectifs différents, ainsi toutes les phases décrivent le cycle de vie du logiciel jusqu'à sa livraison. Une fois qu'une étape est terminée, la prochaine étape de développement suit et les résultats de l'étape précédente sont reportés à l'étape suivante.
Antécédents
le modèle de cascade (ou modèle en cascade en anglais) a été la première méthode largement utilisée dans l'industrie du logiciel. En tant qu'approche traditionnelle, elle n'est pas répétitive contrairement aux modèles agiles avec des sprints simples, mais elle peut être complétée par des boucles de rétroaction et des bouclages. Il est encore utilisé aujourd'hui dans différentes versions si les exigences et les fonctionnalités d'un logiciel peuvent être clairement définies lors de la phase de conception.
Informations générales
La première mention d'un modèle progressif remonte à Winston Royce. Dans son essai "Managing the Development of Large Software Systems", il décrit une méthode de développement pour les grands projets logiciels, qui se divise en phases dès 1970. Il critique encore cette approche et propose une alternative qui s'apparente au prototypage. Royce faisait référence au " Nine Phase Stage-Wise Model " de Herbert Benington , sorti en 1956. Alors que Benington envisageait neuf phases, Royce l'a réduit à sept. Le terme modèle de cascade il n'a été utilisé par aucun d'eux. Son utilisation est basée sur un livre de 1976, qui traite principalement des exigences pour les logiciels[1]
Comment ça marche
Le modèle en cascade original se compose de sept phases successives :[2]
- Configuration requise: La première étape traite des exigences qui ne sont pas liées au produit numérique lui-même, mais plutôt aux aspects pertinents pour l'entreprise tels que le prix et la disponibilité. Les aspects de documentation et de sécurité sont également spécifiés ici. En général, les exigences non fonctionnelles sont mentionnées ici.
- Logiciels requis: Les exigences fonctionnelles du logiciel sont définies dans la deuxième étape. La question de savoir ce que le logiciel doit être capable de faire est répondue ici et clarifiée dans le "spécifications", qui comprend également les résultats de la première étape.
- Analyse des besoins: Dans la phase d'analyse des exigences, les fonctions logicielles sont disséquées et structurées de manière à ce que les éléments fonctionnels individuels et les unités fonctionnelles puissent être séparés les uns des autres. L'analyse des besoins vise à évaluer la faisabilité et l'importance des fonctions. Les résultats de cette étape sont les spécifications qui contiennent les exigences qui existent pour être développées.
- conception du programme: La conception technique est maintenant mise en œuvre à l'aide de ce cahier des charges. Les composants de cette étape comprennent également des décisions sur l'architecture de l'information et les technologies appliquées, telles que les langages de programmation, les bibliothèques de classes et les scripts de programme. Le résultat de la conception du programme est généralement enregistré dans des diagrammes qui décrivent le comportement théorique du logiciel.
- Mise en œuvre: Lors de la mise en œuvre, les structures et les flux de travail sont mis en œuvre en tenant compte des conditions-cadres et des objectifs systémiques. La conception logicielle devient un programme directement lié à un système d'exploitation, à un ou plusieurs langages de programmation et à l'infrastructure. Le résultat est généralement un logiciel fonctionnel, souvent en version bêta.
- Essai: L'étape de mise en œuvre est suivie du test de tous les composants logiciels, des modules et de l'ensemble du système. De plus, l'intégration dans des systèmes d'exploitation spécifiques est vérifiée. Si des erreurs et des conflits se produisent, ils doivent être corrigés immédiatement. Cela pourrait entraîner une augmentation des coûts globaux, car les erreurs éventuelles peuvent être attribuées à différentes phases et ne se produisent pas toujours à l'étape précédente.
- Lancement: Le logiciel est mis en œuvre après acceptation par le client. Des mises à jour et une maintenance peuvent être nécessaires avant que le produit n'entre dans un magasin ou ne soit livré au client.
Différentes équipes et experts travaillent sur ces étapes. Les sous-traitants, la gestion de projet et les développeurs seniors sont souvent impliqués jusqu'à la phase de mise en œuvre. Après la mise en œuvre, les développeurs font le travail, de sorte que les tests logiciels sont souvent gérés séparément, par exemple par des laboratoires de test indépendants. Des experts du marketing et du service sont en partie impliqués dans son lancement. Dans les grandes entreprises et les grandes entreprises, la méthode SDLC (System Development Life Cycle) plus précisément structurée et modifiée est utilisée, qui est basée sur le modèle de cascade.[3]. Il existe également d'autres versions de ce modèle qui, par exemple, introduisent des éléments répétitifs sous forme de boucles pour détecter et corriger les erreurs et les défaillances dans les phases précédentes.
Avantages / Inconvénients
Quelques avantages et inconvénients de modèle de cascade:[4][5][6]
avantage
- En raison de la structure logique du modèle, les erreurs conceptuelles peuvent souvent être évitées.
- Le modèle conduit à une documentation technique complète, ce qui est un soulagement pour les nouveaux programmeurs et développeurs et est également utile pour les tests.
- L'avancement du projet peut être suivi à l'aide d'objectifs.
- Le coût total peut être estimé avec une précision relative s'il n'y a pas de conflits.
Inconvénients
- Les conflits, les bugs et les erreurs de programmation entraînent parfois une augmentation des coûts et un temps considérable. Il en va de même si les clients ne sont pas satisfaits.
- Les spécifications qui sont faites initialement sont souvent difficiles à comprendre pour les clients car elles sont plus abstraites que ce que le logiciel est censé faire. Surtout dans les projets externalisés, cela peut être un inconvénient décisif, car la date de lancement doit être reportée et le marché peut avoir changé pendant cette période.
- La livraison de logiciels prend plus de temps car les départements ne travaillent pas simultanément et chaque étape ne peut démarrer que lorsque l'étape précédente est terminée.
Importance pour la programmation
le modèle de cascade C'est l'un des modèles procéduraux les plus connus en développement logiciel. Il a été utilisé avec succès pendant des décennies, mais n'est maintenant utilisé que pour des projets plus petits où les spécifications sont claires. Cependant, les inconvénients susmentionnés ont également conduit les analystes et les développeurs à concevoir des modèles alternatifs appelés développement logiciel agile.[7]. Le principal problème de modèle de cascade c'est que les changements et les révisions ne sont pas nécessairement prévus par les séquences logiques. Les commentaires des clients, des testeurs et des ingénieurs tout au long du développement sont largement absents, et l'incorporation du logiciel dans un système existant se produit dans un big bang. Ces inconvénients peuvent être évités en modifiant les phases du projet, comme c'est le cas du Spiral Model. Mais depuis quelques années, les méthodes agiles qui utilisent d'autres éléments structurels sont beaucoup plus populaires (par exemple, les rôles et les sprints avec Scrum ou des principes de programmation extrêmes). Ils sont généralement moins chers, conduisent à des résultats plus rapides et sont plus transparents pour les clients.
liens web
- Définition du modèle en cascade
- Qu'est-ce que le modèle en cascade dans les tests de logiciels et quels sont les avantages et les inconvénients du modèle en cascade
