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

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é?

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.

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.

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.

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é.

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.

À 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.