La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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.

Présentations similaires


Présentation au sujet: "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."— Transcription de la présentation:

1 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 roberge.segfaults.net PPL02-cycle_vie_waterfall.pptx

2 2 Automne 2014GEF492 Aperçu Modèles de cycle de vie Le modèle chute d'eau (Waterfall) Transitions Le modèle Waterfall incrémentiel

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

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

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

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

7 7 Automne 2014GEF492 Modèle Chute d’eau L’identification des besoins du système L’identification des besoins du logiciel L’analyse Le design Le testage Le codage La maintenance

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

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

10 10 Automne 2014GEF492 Données empirique BesoindesignCodageTests d’unité Test de réception En service Coût relatif d’une réparation au logiciel aux points différents dans le cycle de vie projets plus petits projets plus grands

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

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

13 13 Automne 2014GEF492 Waterfall simple par opposition au Waterfall incrémentiel Chute d’eau simple Incrémentiel Profiles de dotation Personnel requis Temps d’élaboration

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

15 LES MODÈLES INCRÉMENTIELS ET ITÉRATIFS Prochain cours: 15 Automne 2014GEF492


Télécharger ppt "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."

Présentations similaires


Annonces Google