La méthodologie de développement du logiciel Waterfall est-elle toujours viable?


14

D'après mon expérience, il semble que le modèle Waterfall se soit avéré trop rigide et non réactif aux changements d'exigences pour être considéré comme une méthode viable dans le monde moderne du développement logiciel. La croissance et les antécédents éprouvés de méthodes itératives plus agiles semblent indiquer qu'il n'y a aucune raison pour que quiconque suive un processus de blocs rigides qui suppose peu ou pas de changements depuis le début du projet jusqu'à la livraison du produit.

La méthodologie de développement en cascade est-elle toujours viable pour fournir des systèmes logiciels, en termes de temps, de coût et de qualité?


3
Donc, si vous ne l'avez pas expérimenté et que vous ne voulez pas en faire l'expérience, cela le rend-il mort? Non pas que je le préconise, mais cela semble une prémisse étrange.
thursdaysgeek

9
Ce n'est pas mort. Ce n'est tout simplement pas la mode / tendance / "acceptable" actuelle
Paul

2
@GrandmasterB Par "mort", je voulais dire "suffisamment prouvé pour ne pas être le meilleur moyen"
CFL_Jeff

3
@Rachel Veuillez ne pas continuer à lire la balise de développement logiciel. Il s'agit d'une balise META prévue pour un nettoyage futur .
Thomas Owens

3
Ce n'est pas mort, c'est juste au repos. Pining for fjords. ;)
FrustratedWithFormsDesigner

Réponses:


20

Le modèle de cascade auquel vous faites référence n'a jamais été conçu comme un modèle de processus utilisé dans un projet réel. Au lieu de cela, c'est un homme de paille. Il identifie les phases et activités clés qui existent dans les projets logiciels et le flux le plus élémentaire entre eux. Cette simplification excessive de la façon de développer un logiciel est erronée, et elle a même été présentée de cette façon.

De l'article Wikipedia:

La première description formelle du modèle de cascade est souvent citée comme un article de 1970 par Winston W. Royce, bien que Royce n'ait pas utilisé le terme «cascade» dans cet article. Royce a présenté ce modèle comme un exemple de modèle défectueux et non fonctionnel.

Le document discuté s'intitule Gestion du développement de grands systèmes logiciels . Dans ce document, Royce présente ce modèle sur la deuxième page. Cependant, le texte immédiatement en dessous de la représentation picturale se lit comme suit:

Je crois en ce concept, mais la mise en œuvre décrite ci-dessus est risquée et invite à l'échec.

Il suit cela avec une discussion des problèmes avec les tests après la "fin" de la phase de développement, et comment les échecs ici peuvent conduire à des remaniements majeurs et des changements de code, et comment ceux-ci peuvent conduire à des dépassements majeurs de coût et de calendrier. Tout au long du document, il affine le modèle original en un modèle qui est en effet viable sur un projet. En fin de compte, il se retrouve avec un modèle qui introduit le prototypage, l'interaction avec le client et le raffinement des artefacts - des idées qui finiront par devenir critiques pour le mouvement agile qui a commencé à la fin des années 1990 et au début des années 2000.

Pour répondre à votre question: la cascade dont vous parlez n'est pas, et n'a jamais été, une méthode viable pour livrer des projets logiciels avec une quantité raisonnable de qualité dans les délais et le budget. Cependant, il existe d'autres méthodologies axées sur les plans qui sont opposées à l'agilité et qui peuvent travailler sur les projets.


De nombreux articles sur l'agile utilisent des "méthodes traditionnelles" pour mentionner la cascade, et cela impliquait que la cascade était utilisée au 20ème siècle tout le temps. Maintenant je sais que je me trompe.
Ming-Tang

@ThomasOwens Pourriez-vous en citer quelques-uns other plan-driven methodologies that lie opposite of agile that can and do work on project?
Laiv

@Laiv Le modèle Spiral a tendance à être plus axé sur les plans que les approches agiles - vous faites plus de planification et d'analyse avant de développer un logiciel fonctionnel. Cap Gemini SDM est un autre exemple, bien que des révisions ultérieures aient ajouté un cycle de planification, de vérification et d'action, mais là encore, une quantité décente de planification et d'analyse initiales est intégrée au processus. Beaucoup sont probablement une variante d'une cascade, mais avec une sorte de boucle de rétroaction intégrée. Si vous avez une bonne compréhension du domaine et des exigences relativement stables, vous n'aurez peut-être pas besoin des boucles de rétroaction serrées des méthodes agiles et pourrez mieux planifier.
Thomas Owens

9

Les gens n'utilisent pas le modèle de cascade de manuels et ne l'ont probablement jamais fait.

Il s'agit d'une construction théorique idéalisée dont le but est de vous faire réfléchir aux étapes du développement des systèmes. Le point principal est que vous voulez que les changements les plus importants se produisent le plus tôt possible, car vous n'aurez jamais le temps ni l'argent pour effectuer un grand changement une fois que beaucoup de code sera construit.

En dépit du fait qu'il s'agit davantage d'une façon de penser que d'un processus, c'est toujours la façon dont beaucoup - probablement la plupart des organisations procèdent à la construction de logiciels (ou de maisons, ou de sous-marins, ou quoi que ce soit d'autre ...).

Dans le monde réel, vous n'avez pas de coupures totalement strictes entre les phases, et vous retournez parfois aux phases précédentes pour les petits sous-projets. Ce que la méthodologie vous dit n'est pas que "ces choses ne sont pas autorisées". Ce que cela vous dit, c'est que "ces choses vous coûtent de l'argent et / ou du temps" - essayez donc d'éviter cela à l'avenir.

C'est bien beau pour Agile Snobs (TM) de regarder dans le nez les développeurs "à l'ancienne" et leur méthodologie de cascade pittoresque et impraticable, mais le fait est qu'Agile n'est pas une panacée non plus. Certains projets ne peuvent pas être construits en utilisant Agile et beaucoup d'équipes qui pensent qu'elles sont Agiles sont en fait simplement bâclées et non organisées.

La méthodologie n'est pas la question. Il s'agit de réfléchir à ce que vous faites et aux raisons pour lesquelles vous le faites de cette manière - et à obtenir le plus de valeur pour le client dans les plus brefs délais.


Vous avez évidemment eu une expérience très différente des «gens» pour moi. Au cours des 30 dernières années, j'ai travaillé dans une succession d'entreprises qui ont toutes utilisé (et utilisent toujours) la méthode de la cascade de manuels. Sans surprise, cela ne fonctionne pas.
David Arno

@DavidArno Le plus proche que j'ai jamais vu "à l'état sauvage" du manuel Waterfall dans un contexte logiciel était dans un logiciel de construction d'entreprise qui contrôlait la commutation des trains. La motivation était de ne pas voir quelqu'un mourir littéralement à cause d'un bug. J'imagine que cela pourrait également se produire dans des endroits faisant de la programmation intégrée où vous ne voulez pas créer un million de quelque chose juste pour découvrir qu'il échoue en raison d'un bogue. J'ai tendance à penser que même dans ces cas, Waterfall est plus un idéal qu'une pratique qui se réalise avec perfection. Comme vous le faites remarquer - les résultats sont inévitablement un échec à un certain niveau.
Joel Brown

8

Le processus de cascade mythique le plus souvent comparé à l'agile n'a jamais existé et ne peut donc pas être considéré comme mort. Les vrais processus en cascade sont toujours bien vivants et excellent pour livrer à temps un logiciel budgétaire qui répond aux attentes des utilisateurs.


5
Je ne sais pas quelle est la différence entre le processus de cascade «mythique» et le «vrai». Pourriez-vous expliquer cela?
CFL_Jeff

6
Souvent, le processus Waterfall décrit par les partisans Agile est un homme de paille fr.wikipedia.org/wiki/Straw_man
jfrankcarr

11
Ce serait une meilleure réponse si vous expliquiez dans votre réponse comment les partisans Agiles créent un processus de paille qui ne fonctionnera pas, mais qui n'est pas correctement Waterfall.
Robert Harvey

4
-1 pour la déclaration, "Ils excellent dans la livraison ..." La vérité est que c'est un lavage. Comme toutes les méthodologies logicielles, parfois cela fonctionne, parfois non. J'ai vu les deux dans le cas de la méthode de la vraie cascade.
riwalk

2
Je vais devoir dire, [citation nécessaire] sur cette réponse. Et -1 jusqu'à ce qu'il soit fourni. Surtout le "excellant à livrer à temps sur un logiciel budgétaire qui répond aux attentes des utilisateurs" Le rapport CHAOS n'est pas d'accord avec vous.
Malfist

5

Peut-être une meilleure façon de demander à quoi vous voulez en venir est «quand est-ce moins itératif et plus formel mieux?

Il y a des situations où c'est le cas:

  • Quand les exigences ne changeront pas.

  • Pour répondre à de nouvelles exigences, il est moins important que de toucher 100% des exigences originales.

  • Lorsque tous les composants technologiques sont matures et bien compris.

Dans un sens, vous pouvez prendre le contraire de ce qui pourrait vous pousser à être agile.

Très peu de techniques sont applicables partout. Très peu n'ont aucune utilité.


1
Qu'est-ce qui, dans le monde, est "moins informatif" ou "morenformal"?
Aaronaught

1
@Aaronaught - "moins itératif" et "plus formel" tapé par de gros pouces sur un iPhone. :-)
MathAttack

1
Je n'ai jamais travaillé dans un projet qui a rempli même une de ces conditions préalables. :)
Theodor

3

Oui, il est très vivant, mais aujourd'hui c'est le " modèle V " le plus courant qui est utilisé.

Dans les deux cas, le problème d'Agile est que la solution ne se termine presque jamais, le client peut continuer à demander des modifications et le développement continuera à les résoudre de manière itérative. Pour un projet basé sur le coût du temps et des matériaux, cela fonctionne très bien. Pour un projet qui a un coût fixe, ce n'est pas le cas.

Pour ces projets à coûts fixes, le client s'attend presque toujours à ce que des jalons prédéfinis démontrent les progrès, cependant, il s'agit davantage de la variété écrite formelle que du code de travail. Pour des clients comme celui-ci, les spécifications écrites deviennent le projet, celui où le développement logiciel est une considération secondaire (comme ils le supposent, si vous avez un projet bien défini, le logiciel devrait être facile à développer). Ces sociétés sont également celles qui font un usage intensif de ressources de développement externalisées bon marché.

Donc, si vous avez un pot d'argent ou de temps fixe, ne vous attendez pas à ce que les exigences changent ou n'êtes pas autorisé à changer les exigences, et vous êtes censé fournir un ensemble solide de documentation écrite, alors les modèles en cascade sont les seuls qui faire sens.

Agile peut être introduit au milieu de ces projets pour faire le développement, mais vous avez toujours une phase de montée en puissance où les spécifications sont créées à partir des exigences, et une phase de descente où le logiciel est installé et testé in situ. Agile ne répond pas bien à ces cas.


Agile peut très bien fonctionner avec un pot d'argent ou de temps fixe, à condition que la portée ne soit pas également fixe. L'autre point est que le client / entrepreneur peut choisir le type de contrat (T&M, coût fixe ou quelque chose entre les deux) pour être cohérent avec une méthodologie de développement particulière (agile ou cascade) - il n'est pas prédéterminé.
DNA

1

À qui? La plupart des gestionnaires avec lesquels j'ai eu affaire utilisent encore le processus de développement logiciel Waterfall pour la planification, et les niveaux supérieurs semblent l'aimer pour une planification facile.

Pratiquement, très peu de développeurs que je connais pensent que cela fonctionne ou est même valide.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.