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 suivi 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'une fois la phase précédente du cycle de vie terminée. Il s'agit donc d'un modèle linéaire sans boucles de rétroaction.

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é - Cela 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 d'apporter des modifications.
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 projets.
Nécessite des ressources expérimentées à chaque étape - analystes, concepteurs, développeurs, testeurs.
Les tests ne démarrent 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 de cascade?

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 sur une nouvelle plateforme.
Grande organisation avec des équipes transversales structurées.
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 retours 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 les Cycles Prototype → Feedback → Refined Prototype et d'où 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 du produit final.

Modèle de prototypage évolutif - Forces

Les points forts ou les avantages d'un modèle de prototypage évolutif sont:

Les clients / utilisateurs finaux peuvent visualiser les exigences du système au fur et à mesure qu'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 et les changements d'exigences inattendus sont facilement adaptés.
Des signes de progrès constants et visibles sont produits.
Livraison d'un produit final précis et maintenable.

Modèle de prototypage évolutif - Faiblesses

Les faiblesses ou 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 version finale, ne donnant pas la possibilité aux développeurs d'exécuter l'étape finale c'est-à-dire la standardisation du produit final.
Le projet peut continuer indéfiniment (avec un fluage continu de la portée) 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
En tant qu'étape de clarification des exigences d'un modèle en cascade
Pour développer des interfaces utilisateur
Pour des démonstrations éphémères
Pour un développement nouveau ou original
Pour mettre en œuvre une nouvelle technologie