L'HISTOIRE DE LA CASCADE DE DÉVELOPPEMENT

En 1970, Winston W. Royce a écrit un article dans lequel il décrit un modèle séquentiel pour développer des logiciels dans lesquels les flux de développement, chute d'eau-comme, par des phases de besoins, analyse, conception, implémentation, test et maintenance. Il a ensuite poursuivi en expliquant pourquoi ce modèle ne peut pas travailler et a décrit un processus itératif comme une bien meilleure solution. Inexplicablement, non seulement la communauté du logiciel raccrocher à la notion de "Waterfall", mais ils ont même crédité Royce de l'avoir proposé. Un trait commun des projets de cascade, c'est qu'ils ont tendance à échouer - 18% d'annulation, 53% vers la fin, plus de budget ou descoped - pire encore pour les grands projets (rapport Standish Group).

Cette approche, qui est ensuite devenu universellement utilisée et connue comme la méthode Waterfall, est fondé sur le principe de l'achèvement, en détail, chaque étape avant de passer à la suivante; l'hypothèse optimiste est que le client sait et peut exprimer les exigences détaillées à D'emblée, que les exigences de logiciels en tant que spécifié ne peut être mise en œuvre de façon prévisible et que les conditions ne changent pas au cours du développement.

Royce indique que la phase d'essai, qui survient vers la fin du cycle de développement, c'est la première fois que le système développé est connu, par opposition à analyser. Dans le cas où le système livré n'est pas ce qui était attendu ou certaines exigences ont été manquées, puis une refonte majeure n'est nécessaire. À tout le moins, la conception du système doit être révisé en réponse à des faiblesses ou des erreurs exposées dans le test, mais si des critères externes n'ont pas été satisfaits alors soit les exigences doivent être modifiées (descoped) ou l'ensemble du système doit être revu. Il commente «En effet, le processus de développement est de retour à l'origine et on peut s'attendre à un dépassement de 100% dans le calendrier et / ou les coûts".

Royce accepte que la séquence des événements est logiquement sain mais que le principe de la finalisation de chaque étape avant le début de la suivante est erronée. Sa proposition alternative contour comprend 5 étapes:

1) Insérez une phase préliminaire, la conception des programmes entre les exigences logicielles et de l'analyse, tandis que celle-ci doit être fondée sur des informations incomplètes (car il n'y a pas d'analyse), il sera en mesure de faire face aux besoins fondamentaux de non-fonctionnels tels que la performance et des volumes, établissant ainsi quelques contraintes pour analyse ultérieure.

2) Document de la conception afin que les phases ultérieures de travail vers une commune, caractéristique bien définie.

3) faire deux fois. Construction d'une version pilote du système, dont le contenu dépendra de l'ampleur et la nature des zones à problème critique. C'est la seconde version qui est livrée au client.

4) planifier, contrôler et surveiller les essais.

5) Faire participer le client afin qu'il s'engage à la direction du développement est à faire au stade le plus précoce.

En langage moderne, cette approche proposée serait décrit comme un risque-conduit et itératif.

La majorité des projets de logiciels sont aujourd'hui encore basées sur l'approche en cascade, peut-être avec quelques ajustements, et sont souvent accompagnés d'intimider les méthodes et les normes dont la complexité pure sophistication implique - cela peut être trompeur. Caractéristiques de ces projets comprennent généralement:

• Les principaux problèmes se produisent uniquement au cours de l'étape d'intégration, généralement trop tard pour être intégrés dans le calendrier du projet. L'effet a tendance à être soit un descoping du projet de la livrer à temps, une «compression» sur le temps imparti pour les tests pour tenter de frapper la date de fin, soit un dépassement ou d'une combinaison de tout ou partie de ces derniers.
• La tendance à construire des plans de projet détaillés, jusqu'à la fin du projet, à un stade aussi précoce que possible. Ces devenir rapidement obsolètes et sont généralement soumis à de fréquentes et longues révision consommateurs. Cela a un effet contingent en termes de perturbations aux horaires de travail de l'équipe et souvent le moral.
• Trop beaucoup d'optimisme dans les étapes précédentes en termes de quantité de retravailler qui seront éventuellement nécessaires et le manque de planification adéquate les retouches.
• Potentiel de déconnecter les utilisateurs entre les exigences de collecte et de livraison du fait du laps de temps.
et enfin, mais certainement pas moins --
• L'insistance par la direction que d'une estimation précise des coûts, les délais et les ressources nécessaires soit présentée avant le début des travaux, même

LES ALTERNATIVES ITERATIF

Royce le décor pour le développement itératif, mais il faut reconnaître que ce n'était pas un concept nouveau: les autres disciplines d'ingénierie scientifique et avait suivi une approche itérative pour les générations, bien que souvent de façon informelle. La raison est simple: si vous faites quelque chose de nouveau, d'abord explorer les limites et les contraintes techniques, par l'expérimentation ou d'autres moyens, alors, quand vous savez ce qui est techniquement viable, revoir la conception avec le client et de confirmer que les deux techniques et le contenu fonctionnel sont acceptables et justifiables. Il peut y avoir peu d'entre nous qui ne peuvent pas se rappeler un certain nombre de grands projets du secteur public, qui aurait été abandonné à un stade précoce avait les véritables coûts et les délais ultime été connu.

Bien sûr, beaucoup a changé depuis Royce écrit son article en 1970. Développement de logiciels langages et des outils, des concepts d'architecture, les composants réutilisables, le coût du matériel et de performance, des techniques sophistiquées de modélisation - et la maturité des techniques de développement itératif par un nombre relativement réduit (et relativement réussi) proportion de la communauté du développement.

Le processus itératif adopte la suite logique d'événements du modèle Waterfall mais il suit le cycle de vie complet plusieurs fois dans un seul projet. Chaque itération passe par les activités des besoins, analyse, conception, codage, intégration et tests de production et produit des logiciels de qualité à la fin de l'itération. Le contenu de chaque itération est déterminé en fonction du risque - le nouveau, le plus difficile, les éléments les plus critiques est bâti en premier, habituellement par une équipe de base des praticiens les plus qualifiés, de sorte que la vraie nature du projet et ses implications en termes du coût et de temps sont constamment sous examen. Par conséquent, augmente la certitude que le projet avance - ou, si le développement n'est plus viable, il peut être interrompue à un stade précoce et à un coût minimum.

Le nombre réel d'itérations pour un projet donné dépend de la nature du projet, en particulier la proportion du contenu qui est considéré comme risqué, mais il est susceptible d'être compris entre 3 et 10. Un aspect important de cette approche est que chaque itération est «dans un délai encadré» - si elle est prévue pour 4 semaines, puis il cessera à la fin de cette époque. L'itération subséquente doit englober tous les travaux non terminés mais avec le bénéfice des connaissances acquises durant l'exécution de son prédécesseur.

Le développement itératif RESUME

Développements itératifs afficher ces caractéristiques:

• Objets les plus à risque est bâti en premier
• Le changement est attendu et accueilli, mais contrôlé
• Testing se produit très tôt et souvent
• Itérations prennent beaucoup de temps en boîte de ne pas fonctionner en version boîte
• Deliver précoce, fournissent souvent
• Fournir des logiciels de production de qualité à chaque fois

Certains avantages sont les suivants:

• Début de la découverte et l'atténuation des risques
• Changement accueille et provoque une identification plus précoce des changements
• Complexité gérable
• Confiance dès le début, le succès répétés
• Anticipée incomplète de produits
• Un meilleur suivi des progrès et la prévisibilité
• Meilleure qualité, moins de défauts
• Logiciel correspond mieux aux besoins des utilisateurs
• Précoce et l'amélioration des processus réguliers
• Communication et engagement exigé
• Prototypage et a encouragé

Un procédé couramment utilisé repose sur l'approche itérative est IBM Rational Unified Process ®, communément appelé RUP ®.

Article original Winston Royce peut être téléchargé en format pdf de l'Université du Maryland site web:

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf.

Remerciements

«Gérer le développement de grands systèmes logiciels", Dr. Winston W. Royce, Université du Maryland.

CHAOS et les caractéristiques démographiques du projet Résolution 2004, Standish Group

Copyright FCSL 2006. Tous droits réservés.
http://www.fcslTech.com

Réimpression droits

Cet article mai être publié ou distribué librement dans sa totalité et doit inclure le nom de l'auteur, copyright et l'URL propriétaire du copyright ci-dessus.