SDLC - Modèle en cascade

Le modèle Waterfall est un modèle SDLC classique largement connu, compris et couramment utilisé. Il a été introduit par Royce en 1970 et est toujours utilisé comme une approche commune pour le développement de logiciels dans diverses organisations de l'industrie.

Dans le modèle Waterfall, chaque phase du cycle de vie ne peut démarrer qu'après la fin de la phase de cycle de vie précédente. Il s'agit donc d'un modèle linéaire sans boucles de rétroaction.

Cycle de vie de la cascade

Modèle de cascade - Forces

Les points forts du modèle Waterfall sont -

  • Facile à comprendre, facile à utiliser.
  • Fournit une structure à une équipe de développement inexpérimentée.
  • Les jalons sont bien compris.
  • Définit la stabilité des exigences.
  • Idéal pour le contrôle de gestion (planification, suivi, reporting).
  • Fonctionne bien lorsque la qualité est plus importante que le coût ou le calendrier.

Modèle de cascade - Faiblesses

Les faiblesses ou les inconvénients du modèle Waterfall sont -

  • Idéalisé - Il ne correspond pas bien à la réalité.

  • Irréaliste - ne peut pas s'attendre à des exigences précises au début du projet.

  • Ne reflète pas la nature itérative du développement exploratoire qui est plus courante.

  • Difficile et coûteux de faire des changements.

  • Le logiciel n'est livré qu'à la fin du projet. Pour cette raison -

    • Retarde la découverte de défauts graves.

    • Possibilité de livraison d'exigences obsolètes.

  • Frais généraux de gestion importants, qui peuvent être coûteux pour les petites équipes et les petits projets.

  • Nécessite des ressources expérimentées à chaque phase - analystes, concepteurs, développeurs, testeurs.

  • Les tests ne commencent qu'une fois le développement terminé et les testeurs ne sont impliqués dans aucune des phases précédentes.

  • L'expertise des équipes transverses n'est pas partagée car chaque phase est exécutée en silos.

Quand utiliser le modèle Waterfall?

Vous pouvez utiliser le modèle Waterfall si -

  • Les exigences sont très bien connues.

  • La définition du produit est stable.

  • La technologie est bien comprise.

  • Nouvelle version d'un produit existant.

  • Portage d'un produit existant vers une nouvelle plateforme.

  • Grande organisation avec des équipes structurées et interfonctionnelles.

  • Les canaux de communication sont bien établis au sein de l'organisation et avec le client également.

Modèle de prototypage évolutif

Dans le développement de logiciels utilisant le modèle de prototypage évolutif, les développeurs construisent un prototype pendant la phase des exigences. Les utilisateurs finaux évaluent ensuite le prototype et donnent leur avis. Les commentaires peuvent être des corrections du prototype ou des fonctionnalités supplémentaires. Sur la base des commentaires, les développeurs affinent davantage le prototype.

Ainsi, le produit évolue à travers Prototype → Feedback → Refined Prototype Cycles et donc le nom Evolutionary Prototyping. Lorsque l'utilisateur est satisfait de la fonctionnalité et du fonctionnement du produit, le code prototype est mis aux normes requises pour la livraison finale du produit.

Livraison du produit final

Modèle de prototypage évolutif - Forces

Les forces ou les avantages d'un modèle de prototypage évolutif sont -

  • Les clients / utilisateurs finaux peuvent visualiser les exigences du système lorsqu'ils sont rassemblés en regardant le prototype.

  • Les développeurs apprennent des clients et donc aucune ambiguïté concernant le domaine ou l'environnement de production.

  • Permet une conception et un développement flexibles.

  • L'interaction avec le prototype stimule la prise de conscience des fonctionnalités supplémentaires nécessaires.

  • Les exigences inattendues et les modifications des exigences sont facilement prises en compte.

  • Des signes de progrès réguliers et visibles se produisent.

  • Livraison d'un produit final précis et maintenable.

Modèle de prototypage évolutif - Faiblesses

Les faiblesses ou les inconvénients du modèle de prototypage évolutif sont les suivants -

  • Tendance à abandonner le développement structuré dans le développement code-and-fix, bien que ce ne soit pas ce qui est prescrit par le modèle.

  • Ce modèle a reçu une mauvaise réputation pour les méthodes rapides et sales.

  • La maintenabilité globale peut éventuellement être négligée.

  • Le client peut éventuellement demander la livraison du prototype en tant que final, sans donner aux développeurs la possibilité d'exécuter la dernière étape, à savoir la standardisation du produit final.

  • Le projet peut se poursuivre indéfiniment (avec un fluage de portée continu) et la direction peut ne pas l'apprécier.

Quand utiliser le modèle de prototypage évolutif?

Vous pouvez utiliser le modèle de prototypage évolutif -

  • Lorsque les exigences sont instables ou doivent être clarifiées
  • Comme étape de clarification des exigences d'un modèle en cascade
  • Développer des interfaces utilisateurs
  • Pour des manifestations de courte durée
  • Pour un développement nouveau ou original
  • Pour la mise en œuvre d'une nouvelle technologie