Cycle de vie: « Waterfall » GEF492A Automne 2014 [HvV § 3.1] GEF492 - 2 Modèles de cylce de vie "Waterfall" Automne 2012 Cycle de vie: « Waterfall » GEF492A Automne 2014 [HvV § 3.1] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique Vincent.roberge@rmc.ca roberge.segfaults.net PPL02-cycle_vie_waterfall.pptx Sylvain P. Leblanc

GEF492 - 2 Modèles de cylce de vie "Waterfall" Automne 2012 Aperçu Modèles de cycle de vie Le modèle chute d'eau (Waterfall) Transitions Le modèle Waterfall incrémentiel Automne 2014 GEF492 Sylvain P. Leblanc

Les modèles de cycle de vie Les modèles de cycle de vie identifient les activités clés en élaboration du logiciel, ainsi que les relations entre celles-ci Ceci diffère d’une méthodologie d’élaboration, qui nous donne une approche particulière pour chacune des activités clés Exemple: un modèle de cycle de vie peut dire qu’il y a une activité qui s’appelle le «testage» et que le testage vient après une autre activité qui s’appelle «l’implémentation» une méthodologie dirait exactement comment il faut accomplir le testage Automne 2014 GEF492

Modèle de cycle de vie primitif Déclaration du problème Deux activités: l’implémentation l’analyse Écrit le code pour avoir une solution au problème Code Trouve pourquoi le code n’est pas une bonne solution au problème Répare La remarque clé: Ces deux activités sont dans le mauvais ordre! Code approuvé Automne 2014 GEF492

Modèle «Chute d’eau» simple Communément appelé Waterfall, même en français Alors, le cycle de vie le plus simple possible: (Winston Royce, 1970): L’analyse L’implé-mentation Code approuvé Déclaration du problème Automne 2014 GEF492

Mise à l’échelle Pour les projets assez petits, le Waterfall simple est parfois adéquat Pour les projets plus grands, on a besoin d’autres activités pour compléter l’analyse et le codage: la définition des besoins du système l’attribution des besoins aux composantes du système design aux niveaux hautes et détaillé le testage la maintenance Automne 2014 GEF492

GEF492 - 2 Modèles de cylce de vie "Waterfall" Automne 2012 Modèle Chute d’eau L’identification des besoins du système L’identification des besoins du logiciel L’analyse Le design Le codage Les noms des étapes peuvent changer, mais ceci donne une bonne idée. On peut faire rétroaction d’une activité à son prédécesseur Le testage La maintenance Automne 2014 GEF492 Sylvain P. Leblanc

Les points de transition La transition d’une activité à une autre demande typiquement qu’on ait: achevé un produit bien définit (généralement un document) évalué formellement et approuvé le produit établi une ligne de base officielle Quand il est nécessaire de refaire les activités précédentes il faut que: le produit soit mis à jour les révisions soient évaluées et approuvées les révisions soient pistées possiblement comme delta a la ligne de base Automne 2014 GEF492

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 cher vrai ou faux? pourquoi? Il faut revisiter les étapes précédentes. Automne 2014 GEF492

Données empirique Coût relatif d’une réparation au logiciel aux points différents dans le cycle de vie 200 100 50 20 10 5 2 1 projets plus grands C’est la magnitude qui est importante, pas les données exactes projets plus petits Besoin design Codage Tests d’unité Test de réception En service Automne 2014 GEF492

Exécution couronnée de succès (Royce) le design du logiciel constitue le départ du processus une phase de design préliminaire entre la phase d’identification des besoins du logiciel et la phase d’analyse Faites les taches critiques deux fois une équipe spéciale utilise une version miniature du processus pendant la phase de design Planifiez, contrôlez et suivez de près le testage la phase du testage représente le plus haut niveau de risque, et elle a lieu à la fin du projet quand il est très difficile d’adresser les problèmes; planifiez bien le faire Impliquez le client il faut que le client fasse partie intégrale du processus pour éviter les malentendus vis-à-vis les buts du système Automne 2014 GEF492

Le Waterfall incrémentielle Testage Codage Maintenance design incrémentiel design du produit Testage Codage Maintenance design incrémentiel Testage Codage Maintenance design incrémentiel Automne 2014 GEF492

Waterfall simple par opposition au Waterfall incrémentiel GEF492 - 2 Modèles de cylce de vie "Waterfall" Automne 2012 Waterfall simple par opposition au Waterfall incrémentiel Profiles de dotation Ce n’est pas plus rapide, mais on requiert moins de monde Chute d’eau simple Personnel requis Incrémentiel Notez que le Waterfall incrémentiel n’est pas plus rapide que le Waterfall simple; mails il requière moins de personnel Temps d’élaboration Automne 2014 GEF492 Sylvain P. Leblanc

Les avantages du processus Chute d’eau GEF492 - 2 Modèles de cylce de vie "Waterfall" Automne 2012 Les avantages du processus Chute d’eau Encourage les révisions périodiques, la validation et la vérification, et donne d’habitude un produit de performance supérieure qui correspond mieux aux besoins documentés Le résultat de chaque phase est un document qui aide à clarifier les décisions, donne une trace de vérification, et sert comme point clé (jalon) La transition formelle d’une phase à la prochaine aide à stabiliser le produit; ce qui réduit les changements inutiles Le Waterfall peut être utile Automne 2014 GEF492 Sylvain P. Leblanc

Les modèles incrémentiels et itératifs Prochain cours: Les modèles incrémentiels et itératifs Automne 2014 GEF492