Les modèles incrémentiels et itératifs GEF492A - Automne 2014 [ HvV § 3.2.1-2 ]

1. Les modèles incrémentiels et itératifsGEF492A - Automne 2014[HvV§ 3.2.1-2] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique Vincent.roberge@rmc.ca roberge.segfaults.net PPL03-incremential_iteratif.pdf

2. Aperçu • Faiblesses du modèle Waterfall • Prototypage pour besoins • Prototypage pour design • Prototypage évolutionnaire GEF492

3. Révision: modèle Waterfall L’identification des besoins du système L’identification des besoins du logiciel L’analyse Le design Le codage Le testage La maintenance GEF492

4. Les faiblesses du modèle Waterfall • supposition inhérente: il est possible de trouver tous les besoins et de créer un bon design dès le premier essai • vrai pour quelques projets • pour la plupart des projets, il est très difficile de comprendre tous les besoins avant de faire le design ou la réalisation • les premiers designs sont presque toujours fautifs ou non optimaux • lorsqu’il faut revisiter des phases déjà complétées, il faut lutter contre beaucoup d’inertie administrative • ça réduit le «génie récursif» • il est très difficile de faire des ajustements de parcourt si les décisions prise tôt dans le processus sont inopportunes GEF492

5. Il faut projeter de jeter la première version.... Dans la plupart des projets, le premier système réalisé est à peine utilisable. Il est tantôt trop lent, tantôt trop gros, trop malcommode à utiliser, voire même les trois. Il n’y a alors pas d’alternative: il faut recommencer, utiliser l’expérience acquise, et concevoir une nouvelle version qui corrige ces problèmes… Quand on utilise un nouveau concept ou une nouvelle technologie, il faut construire un système qu’on devra jeter, car nul n’est omniscient et ne peut tout prévoir. La question que doit donc se poser le management n’est pas de savoir s’il faut construire un système pilote puis le jeter. Cela se fera, soyez-en certain. La seule question est de savoir s’il faut prévoir de faire un brouillon à jeter, ou s’il faut promettre de livrer le brouillon au client… — Fred Brooks, Le mythe du mois-homme GEF492

6. collection des besoins du client réalisation du prototype design rapide évaluation du prototype par le client amélioration du prototype Le prototypage pour définir les besoins • le problème • le client précise les objectifs généraux mais n’est pas en mesure d’identifier les besoins détaillés des entrants, du traitement, ou des sortants • une solution: GEF492

7. Gather requirements from customer Build prototype Quick design Customer evaluates prototype Refine prototype Le prototypage pour définir les besoins L’identification des besoins du système But: le prototypage des besoins lors de l’analyse aide à réduire le risque de faire un design basé sur des besoins incorrects ou incomplets. L’identification des besoins du logiciel L’analyse Le design GEF492

8. Les dangers du prototypage pour définir les besoins • le client voit un "système qui fonctionne", et ne réalise pas que le système • est probablement difficile à maintenir • est presque certainement de mauvaise qualité et le client exige qu’on "répare le prototype" et qu’on le livre • quelques solutions • assurez vous que le client comprend pourquoi on crée un prototype et expliquez bien le processus de prototypage • utilise des technologies (matériel, système d’exploitation, langage de programmation, etc.) qui ne conviennent clairement pas au produit final GEF492

9. Le prototypage pour définir le design • le problème • quelques aspects de la conception ne sont pas très bien compris, ce qui les rends très risqués • une solution: identification des critères essentiels de la conception réalisation du prototype conception rapide évaluation par rapport aux critères amélioration du prototype GEF492

10. Identify critical design criteria Build prototype Quick design Review critical design criteria Refine prototype Le prototypage pour définir la conception L’identification des besoins du système But: on crée et raffine les prototypes de design jusqu’à ce qu’ils répondent aux critères essentiels. Ceci réduit le risque que le design est insuffisant ou qu’il est inadéquat. L’identification des besoins du logiciel L’analyse Le design Le codage GEF492

11. Les dangers du prototypage pour définir la conception • pour réaliser un prototype rapidement, les programmeurs utilise des raccourcis • les langages de programmation, les algorithmes, les bases de données, les trousses à outils d’interface utilisateurs, etc. qui sont inopportuns pour le système final et ils oublient que ces choix représentaient des compromis et les réutilisent dans le système final • quelques solutions • documentez les compromis de design quand ceux-ci sont choisis • insistez sur une validation totale du design finale, portant attention particulière aux restants de prototypes GEF492

12. Une observation • Pour quelques logiciels, un prototype peut être suffisant pour les besoins du client. Ces logiciels sont caractérisés par: • un risque technique assez bas • le fait qu’on en a besoin immédiatement • qu’on peut impliquer l’utilisateur très intimement • qu’on a un système de développement • dans lequel les programmeurs peuvent travailler assez vite pour soutenir le prototypage rapide • mais qui est en même temps assez petit, efficace, et robuste pour être déployer • Souvent on peut utiliser les langages de quatrième génération (4GL), les composants de disponibilité immédiat, ou les cadriciels d’applications (e.g., SAP, Peoplesoft) GEF492

13. Le prototypage évolutive Collection des besoins du client réalisation du prototype Design rapide Évaluation du prototype par le client Extraction du design amélioration du prototype Ajustement au système Exploitation et maintenance GEF492

14. Les dangers du prototypage évolutive • le processus ne possède pas de phase de design exhaustive, le système peut donc manquer d’intégrité conceptuelle • il faut que les développeurs soient conscients de la nécessité pour intégrité conceptuelle • clarifiez ou re-factorisez le design pendant la phase d’extraction du design • il peut être impossible d’ajuster la performance du système une fois que celui-ci est complété • La gestion sera tenté de sauter les phases d’extraction du design et d’ajustement • sans un fort contrôle de gestion, il est possible d’avoir des itérations interminable GEF492

15. Rappelez: justification économique du Waterfall Barry Boehm a dit: • Il faut faire toutes ces étapes de toute façon • probablement vrai pour tous systèmes sauf les plus petits • Les mêmes étapes en ordre différent coûteraient plus chères • vrai ou faux? • pourquoi? GEF492

16. Rappelez: données empirique Coût relatif d’une réparation au logiciel aux points différents dans le cycle de vie projets plus grands 200 100 50 20 10 5 2 1 Supposition inhérente: Le processus utilisé était le Waterfall! projets plus petits Besoin Conception Codage Tests d’unité Test de réception En service GEF492

17. Les démarches prototypage • La caractéristique clé des démarches de prototypage est le développement rapide de modèles simples du système pour • obtenir les réactions immédiates des clients et clarifier les besoins, ou • augmenter le niveau de confiance au sujet des aspects de design qui ne sont pas bien compris • La question clé pour le prototypage efficace est: • Avec quoi est-ce qu’on commence? GEF492

18. L’observation de Boehm (1988) • le but des modèles Waterfall et du prototypage est de réduire le risque • le Waterfall réduit le risque de changement continuel des besoins et du design en insistant que ceux-ci soient mis au point tôt dans le processus • le prototypage évolutif réduit le risque des malentendus de besoins usager par un système de rétroactions (sous forme de prototypes) pendant le design du système • chaque projet a des risques différents, et ceux-ci changent pendant le cycle de vie du projet • on a donc besoin de reconnaître le risque comme idée clé GEF492

19. La spirale et le risque • Le modèle spirale est là spécifiquement pour s'occuper du risque • la gestion de risques est au cœur du modèle • Le modèle spirale n'est pas un modèle de développement du logiciel au même titre que le Waterfall ou le prototypage; • il s'agit plutôt d'un modèle s'occupant de risques, peu importe le modèle de cycle de vie suivit GEF492

20. Le modèle spiral 2. Évaluez les alternatives pour les produits et le processus; identifiez et résoudre les risques 1. Établir les objectifs, limitations, et alternatives du prochain niveau 5. Examinez le progrès, confirmez l’engagement à continuer 3. Élaborez et vérifiez le produit du prochain niveau 4. Planifiez les prochaines phases GEF492

21. Exemple d’un projet utilisant le modèle Spiral GEF492

22. Commencez et arrêtez • commencez avec une hypothèse • on peut rencontrer un besoin de l’utilisateur de façon rentable par l’élaboration d’un logiciel • arrêtez quand • le système est achevé et qu'il est livré au client • il faut tester l’hypothèse en vérifiant que le logiciel remplit réellement le besoin • ou on détermine que l’hypothèse est fausse • le système est trop coûteux, le système n’est pas nécessaire, une autre solution devient disponible, .... GEF492

23. La maintenance • le modèle Spiral soutient très bien la maintenance • pour la maintenance, l’hypothèse est • une modification au système actuel est un moyen rentable de rencontrer un besoin particulier de l’utilisateur GEF492

24. Les aspects clés • L’élaboration de la documentation et autres produits n’est pas uniforme • on adresse les éléments du système le plus risqué en premier, et on les documente de façon plus rigoureuse • Incorpore le prototypage comme activité de réduction du risque • Donne une structure permettant de remettre en question et réviser les décisions précédentes GEF492

25. Le modèle Spiral «Gagnant Gagnant» Gagnant pour le client et le développeur 2. Identifiez les conditions gagnantes des parties prenantes 3a. Conciliez les conditions gagnants 1. Identifiez les parties prenantes du prochain niveau 3b. Établissez les objectifs, limitations, et alternatives du prochain niveau 7. Examinez le progrès, confirmez l’engagement de continuer 4. Évaluez les alternatives pour les produits et les processus; identifiez et résoudre les risques 6. Validez le produit et le processus 5. Élaborez le prochain niveau du produit et du processus, incluant les cloisons. Spirale GEF492

26. Les avantages • la flexibilité • le modèle permet différentes démarches d’élaboration et peut être appliqué a beaucoup de types de logiciels • précise les options tôt dans le processus • surtout les options visant la réutilisation du logiciel existant • permet la préparation pour l’évolution du cycle de vie et pour la croissance et les changements de produit logiciel • donne un mécanisme pour incorporer les objectifs de qualité du logiciel au processus d’élaboration • facilite l’élimination des erreurs et des alternatives peu attrayantes tôt dans le processus • permet de décider « quand assez est assez » pour chaque source d’activité ou de dépense • donne une démarche unifiée pour l’élaboration et la maintenance • donne une structure viable pour l’élaboration intégrée des systèmes logiciel et matériel GEF492

27. Les difficultés • mise au contrat • le modèle Spiral est difficile à utiliser dans une situation de conclusion de marché, pour le client et pour l’entrepreneur • difficile à satisfaire toute la flexibilité • difficile à contracter sans une spécification de données livrables à l’avance • compétence en estimation des risques • il faut identifier et résoudre les risques, et la plupart des directeurs et des programmeurs n’ont aucun entraînement ou expérience dans ce domaine • le modèle n’est pas assez détaillé • comme définie, le modèle est très général et c’est difficile de l’appliquer sans beaucoup d’expertise GEF492

28. Prochain cours: Développement d’applications rapide GEF492