GEF Modèles de cycle de vie incrémentiels et itératifs

Présentation au sujet: "GEF Modèles de cycle de vie incrémentiels et itératifs"— Transcription de la présentation:

1 GEF492 - 03 Modèles de cycle de vie incrémentiels et itératifs
Automne 2013 Les modèles incrémentiels et itératifs GEF492A - Automne 2014 [HvV § ] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique roberge.segfaults.net PPL03-incremential_iteratif.pdf Sylvain P. Leblanc

2 GEF492 - 03 Modèles de cycle de vie incrémentiels et itératifs
Automne 2013 Aperçu Faiblesses du modèle Waterfall Prototypage pour besoins Prototypage pour design Prototypage évolutionnaire Automne 2014 GEF492 Sylvain P. Leblanc

3 Révision: modèle Waterfall
GEF Modèles de cycle de vie incrémentiels et itératifs Automne 2013 Révision: modèle Waterfall L’identification des besoins du système L’identification des besoins du logiciel L’analyse Le design Le codage Décrivez les transitions entre les étapes: Complétion d’un produit (habituellement un document) Révision et approbation formelle Ligne de base Le testage La maintenance Automne 2014 GEF492 Sylvain P. Leblanc

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 Automne 2014 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 Automne 2014 GEF492

6 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: collection des besoins du client réalisation du prototype évaluation du prototype par le client amélioration design rapide Automne 2014 GEF492

7 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 Gather requirements from customer Build prototype Customer evaluates Refine Quick design Le design Automne 2014 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 Automne 2014 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 Automne 2014 GEF492

10 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 Identify critical design criteria Build prototype Review critical design criteria Refine Quick design Le codage Automne 2014 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 Automne 2014 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) Automne 2014 GEF492

13 Le prototypage évolutive
GEF Modèles de cycle de vie incrémentiels et itératifs Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

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 Automne 2014 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? Automne 2014 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 Automne 2014 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? Automne 2014 GEF492

18 L’observation de Boehm (1988)
GEF Modèles de cycle de vie incrémentiels et itératifs Automne 2013 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é Automne 2014 GEF492 Sylvain P. Leblanc

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 Automne 2014 GEF492

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

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

22 GEF492 - 03 Modèles de cycle de vie incrémentiels et itératifs
Automne 2013 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, .... On peut faire spirale à jamais! Automne 2014 GEF492 Sylvain P. Leblanc

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 Automne 2014 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 Automne 2014 GEF492

25 Le modèle Spiral «Gagnant Gagnant»
GEF Modèles de cycle de vie incrémentiels et itératifs Automne 2013 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 Met l'emphase sur l'entente entre développeur et clients aux étapes 1 – 3 (qui étaient combinées dans la spirale simple). Appliqué par Boehm au program STARS du DOD qui développait un ensemble d'environnement de génie logiciel prototypes. Les coûts de TRW ont diminuées de moitié et la qualité (bogues/ligne) a augmenter d'un facteur de 100. 6. Validez le produit et le processus 5. Élaborez le prochain niveau du produit et du processus, incluant les cloisons. Spirale Automne 2014 GEF492 Sylvain P. Leblanc

26 GEF492 - 03 Modèles de cycle de vie incrémentiels et itératifs
Automne 2013 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 Automne 2014 GEF492 Sylvain P. Leblanc

27 Les difficultés mise au contrat compétence en estimation des risques
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 Automne 2014 GEF492

28 Développement d’applications rapide
GEF Modèles de cycle de vie incrémentiels et itératifs Automne 2013 Prochain cours: Développement d’applications rapide Automne 2014 GEF492 Sylvain P. Leblanc