Introduction au modèle de cascade

Issu des industries de la construction et de la fabrication, il s'agit d'un environnement physique hautement structuré destiné aux processus de conception et de développement. Le modèle Waterfall est également connu sous le nom de modèle de cycle de vie de développement logiciel. Il s'agissait du premier modèle de processus introduit comme modèle de cycle de vie linéaire-séquentiel. Le modèle en cascade indique simplement au phénomène de terminer complètement une phase avant de commencer la nouvelle phase de développement afin qu'il n'y ait pas de chevauchement des phases. Dans le domaine du développement logiciel, le modèle en cascade a d'abord été utilisé comme approche SDLC. Pour travailler sur le modèle de la cascade, nous devons comprendre son approche d'application basée sur des facteurs internes et externes qui peuvent être les suivants:

  • Aucune exigence ambiguë dans l'application.
  • Stabilité de la définition du produit
  • C'est la technologie comprise
  • Ce n'est pas dynamique
  • De grandes ressources avec l'expertise appropriée sont disponibles pour soutenir le produit
  • Projet Vey de courte durée
  • Le bon document, des exigences claires et fixes.

Pour commencer avec l'histoire du modèle en cascade, je voudrais dire que le premier échantillon du modèle en cascade a été introduit en 1970 par Winston w Royce dans un article. Depuis lors, le modèle en cascade stipule que l'on ne doit passer à une autre phase que lorsque les phases précédentes sont complètement testées, revues et vérifiées. Il met l'accent sur la progression logique des étapes de phase. Sa fonctionnalité est similaire à l'eau qui coule sur le bord de la falaise. Cette approche du développement logiciel a reçu le nom de cascade car elle évolue systématiquement d'une phase à l'autre de façon descendante. Depuis sa publication par Winston W. Royce en 1970, le modèle en cascade a été largement utilisé dans le domaine du développement logiciel. Dans le cycle du processus de développement logiciel, les modèles de programmation sont utilisés pour planifier les différentes étapes du développement d'une application. Un de ces modèles est le modèle de la cascade.

Modèle de phases de cascade

Parlons maintenant des phases du modèle de cascade, qui peuvent être expliquées clairement à travers cette infographie de démonstration.

Avec les infographies ci-dessus, nous pouvons comprendre que le modèle en cascade a un total de 7 phases de cycle logiciel de conception et de développement qui sont les suivantes:

  1. Exigences
  2. Une analyse
  3. Conception
  4. Codage / implémentation
  5. Essai
  6. Fonctionnement / déploiement
  7. Entretien

Nous pouvons donc voir que le modèle en cascade fonctionne de la hiérarchie de haut en bas avec une phase terminée avec des vérifications complètes, puis en passant à une autre phase, y compris des processus de phase tels que la conception, l'initiation, l'analyse, la conception, la construction, les tests, la production / mise en œuvre et la maintenance. Afin d'obtenir une connaissance plus brève du modèle de la cascade, nous devons comprendre tous ses processus en profondeur avec son modèle de travail. Il y a une phase préalable de base qui doit être comprise avant de commencer les phases profondes de la connaissance. Il s'agit de l'étude de faisabilité du produit logiciel. Il traite des aspects financiers et techniques des exigences du projet. Cette phase traite de la correction des mesures en fonction des avantages et des inconvénients analysés. Ainsi, la meilleure solution est choisie.

  1. Exigences: Comme spécifiques par des mots, nous devons savoir et comprendre ce que nous devons concevoir, ce que nous devons développer, ses processus, quelle sera sa fonctionnalité, etc. Il fournit du matériel d'entrée au produit fabriqué et donc au produit à venir est étudié, finalisé et marqué. Il nous donne également l'extension pour décider des exigences matérielles ou logicielles du produit qui seront conçues, développées et capturées dans toutes les phases.
  2. Analyse: elle aboutit à la conception de modèles, de schémas et de règles métier. Non seulement cette exigence est divisée en deux parties:
  • Collecte et analyse des exigences: D'abord, toutes les informations et les exigences pour le développement du produit sont recueillies auprès du client, puis elles sont traitées pour analyse. Le rôle principal de cette partie est d'éradiquer l'incomplétude et les incohérences liées au développement de produits logiciels.
  • Spécification des exigences: les exigences analysées ci-dessus sont ensuite documentées dans un document SRS (Software Requirements Specification). Il sert de chemin entre le client et l'équipe de développement SRS. Tout litige futur sera géré et réglé uniquement par le biais de cette documentation SRS.
  1. Conception: Une fois la première phase terminée et vérifiée, c'est la prochaine phase la plus importante à étudier car elle est utilisée pour la conception du système. Il aide à spécifier les exigences logicielles et matérielles pour la conception du produit. Il contribue également à l'architecture globale de la conception du système. Ainsi, la spécification des exigences est principalement étudiée et vérifiée dans cette phase. Il est également utile pour transformer le document SRS en conception fonctionnelle et développement du produit logiciel. On peut donc dire qu'en phase de conception, on fait l'architecture globale du projet de développement logiciel.
  2. Mise en œuvre: la conception du système étant entièrement vérifiée, la phase de mise en œuvre vient dans la rangée. Dans cette phase, les entrées de la conception du système sont prises, et il est d'abord développé dans de petits programmes appelés unités, qui est testé et mis en œuvre dans la phase à venir. Chaque unité dans la phase de mise en œuvre subit un développement et sa fonctionnalité complète est testée, également connue sous le nom de test unitaire. Ainsi, dans cette phase, la conception du système est convertie en code source avec des modules de programmes entièrement fonctionnels. Cela comprend le développement, la vérification et l'intégration du logiciel.
  3. Intégration et test: chaque conception d'unité et développée dans les phases précédentes est incorporée à partir de la phase de mise en œuvre qui est intégrée dans un module ou un système pour un test divers comme le test de charge, le test de plomb, etc. L'environnement de test subit un contrôle logiciel constant pour savoir s'il y a des flux ou des erreurs dans la conception ou le code. Les tests sont effectués pour maintenir la stabilité et la faisabilité du logiciel afin que le client ne soit confronté à aucune perturbation ou bogue pendant sa production. Ainsi, dans cette phase après la mise en œuvre, l'ensemble du système est testé de manière approfondie pour détecter les éventuels défauts et pannes. Les tests du système se composent de trois types d'activités différents qui peuvent être expliqués comme suit:
  • Tests Alpha (α): Il s'agit des tests effectués par l'équipe de développement.
  • Tests bêta (β): il s'agit des tests effectués par une équipe amicale de clients et d'utilisateurs.
  • Test d'acceptation: il est effectué après le test alpha et le test bêta. Fondamentalement, ce test est effectué après livraison par les clients. Après les tests effectués par le client, la décision est prise de savoir si ce logiciel est acceptable ou de le rejeter. Donc, dans cette phase, le débogage des bogues est essentiellement effectué.
  1. Déploiement du système / Opérations: une fois les tests non fonctionnels, fonctionnels, alpha et bêta terminés, le produit du logiciel est déployé sur le système utilisateur ou client ou il est commercialisé. La phase de déploiement comprend l'installation, la migration et la prise en charge du système complet vers l'environnement utilisateur ou client.
  2. Maintenance: C'est la dernière mais la phase la plus importante du modèle de workflow en cascade. Cette étape intervient juste après l'installation et comprend la modification appropriée du produit ou du système, ou l'amélioration, le changement ou la modification d'attributs liés à un problème de performances lié au système. son rôle principal est d'améliorer les performances du système avec le résultat de précision maximale de la sortie du logiciel. Ces changements soulevés pendant la phase de maintenance sont principalement liés aux changements initiés à effectuer par le client ou les utilisateurs après la phase d'installation et de test, qui incluent des bogues tels que des défauts découverts lors des utilisations en direct du système ou une demande soulevée par les clients. Ainsi, le client bénéficie d'une maintenance et d'un support opportuns et planifiés pour le produit développé. Vous serez vraiment étonné de savoir que l'effort fourni dans la phase de conception et de développement du produit logiciel n'est que de 60% par rapport aux efforts déployés dans la phase de maintenance. Il existe essentiellement trois types de maintenance qui sont expliqués ci-dessous:
  • Maintenance corrective: Pendant la phase de conception et de développement, certaines erreurs ne sont pas découvertes, elles ne sont prises en compte que lorsque le client utilise. Il s'agit uniquement de maintenance corrective qui signifie la correction de problèmes ou d'erreurs qui n'ont pas été découverts lors de la phase de développement.
  • Maintenance parfaite: ce type de maintenance est effectué à la demande du client pour augmenter et améliorer les fonctionnalités du système ou du logiciel.
  • Maintenance adaptative: c'est la maintenance nécessaire à la commutation de l'environnement système. Généralement requis pour le portage du système existant vers un nouvel environnement ou un nouvel ordinateur ou système ou peut-être avec un nouveau système d'exploitation. Cette phase est trop importante car elle conduit à de meilleures performances du système.

Ainsi, dans la discussion ci-dessus, nous avons appris à connaître chaque phase du modèle en cascade avec des spécifications complètes. Nous pouvons donc dire que le modèle en cascade est très important dans le domaine des logiciels également par rapport aux industries mécaniques, car chaque phase a sa propre importance, elle conduit à générer un logiciel plus productif et stable.

Les avantages

Non seulement ce modèle en cascade présente également de nombreux autres avantages dans le cycle de vie du développement logiciel, qui peuvent être examinés ci-dessous:

  • Il permet la départementalisation et le contrôle.
  • Un calendrier peut être défini avec des délais pour chaque étape de développement et un produit peut passer par les phases du modèle de processus de développement une par une.
  • Comme il subit des phases facilement compréhensibles et explicables, il surmonte de nombreux problèmes, il est donc très facile à utiliser.
  • En raison de la rigidité du modèle de workflow, il est très facile à gérer car chaque phase du modèle en cascade a des processus spécifiques d'examen et de livrables.
  • Le modèle en cascade fonctionne bien pour les petits projets où les exigences sont très bien comprises.
  • Le calendrier peut être défini avec des délais pour chaque étape du développement et un produit peut passer une par une à travers les phases du modèle de processus de développement.
  • Des étapes clairement définies.
  • Jalons bien compris.
  • Tâches faciles à organiser.
  • Le processus et les résultats sont bien documentés.
  • Renforce les bonnes habitudes: définir avant la conception,
  • Conception avant code.
  • Le modèle fonctionne bien pour les petits projets et les projets où les exigences sont bien comprises.

Désavantage

Comme nous savons que chaque pièce a deux faces, donc avec le large accès aux avantages du modèle en cascade, le modèle en cascade a également des inconvénients ou vous pouvez dire des inconvénients qui sont discutés ci-dessous:

  • Pas un bon modèle pour des projets complexes et orientés objet.
  • Ne convient pas aux projets où les exigences présentent un risque modéré à élevé de changement.
  • Il est difficile d'estimer le temps et les coûts pour chaque phase du processus de développement.
  • Pas un bon modèle pour des projets complexes et orientés objet.
  • Aucun logiciel fonctionnel n'est produit avant la fin du cycle de vie.
  • Ne peut pas s'adapter aux exigences changeantes.
  • Il est difficile de mesurer les progrès par étapes.
  • Risques et incertitudes élevés.
  • Mauvais modèle pour les projets longs et en cours.
  • Ajuster la portée pendant le cycle de vie peut mettre fin à un projet.
  • Aucun chemin de rétroaction
  • Pas de chevauchement des phases
  • Difficile de répondre aux demandes de changement.
  • le risque et l'incertitude sont élevés avec ce modèle de processus.

Où utiliser le modèle Waterfall

Maintenant, après avoir encerclé tous les scénarios, nous arrivons à un point où nous voulons savoir où utiliser le modèle en cascade.

  • Le modèle majoritairement en cascade est utilisé dans un projet de défense car là-bas, l'exigence est claire car avant de passer en phase de développement, ils l'analysent bien.
  • Cela peut également être utilisé dans des projets de migration où les exigences seront les mêmes, seule la plateforme ou les langues peuvent varier / changer.

Conclusion

Donc, dans l'ensemble, je peux dire que le modèle en cascade est le mieux adapté aux petits projets de développement de logiciels par rapport aux grands projets car la conception, le développement et la mise en œuvre sont plus faciles dans le petit projet lorsque vous travaillez sur le modèle en cascade car dans ce modèle, toutes les phases précédentes ont besoin à compléter lors du passage aux phases à venir. Ainsi, dans le grand projet, les problèmes et les erreurs surviennent fréquemment car il a un grand modèle, donc à chaque fois la phase de test se poursuivra si elle est mise en œuvre via le modèle en cascade, ce qui entraînera une optimisation et une précision moindres du logiciel.

Articles recommandés

Ceci a été un guide pour le modèle de cascade. Ici, nous avons discuté des phases, des avantages et des inconvénients du modèle en cascade. Vous pouvez également consulter nos autres articles suggérés pour en savoir plus -

  1. Qu'est-ce qu'AWS?
  2. Qu'est-ce que Bootstrap?
  3. Qu'est-ce qu'une ruche?
  4. Qu'est-ce qu'Unix?
  5. Scrum vs Waterfall | Comparaison