Transcript Title EEE493 2000

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
[email protected]
roberge.segfaults.net
PPL02-cycle_vie_waterfall.pptx
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
2
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
3
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!
Automne 2014
GEF492
Code
approuvé
4
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):
Déclaration
du problème
L’analyse
L’implémentation
Automne 2014
GEF492
Code
approuvé
5
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
6
Modèle Chute d’eau
L’identification
des besoins du
système
L’identification
des besoins du
logiciel
L’analyse
Le design
Le codage
Le testage
Automne 2014
GEF492
La
maintenance
7
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
8
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?
Automne 2014
GEF492
9
Données empirique
Coût relatif d’une réparation au logiciel
aux points différents dans le cycle de vie
200
projets plus grands
100
50
20
projets plus petits
10
5
2
1
Besoin
Automne 2014
design
Codage Tests
Test
d’unité de réception
GEF492
En
service
10
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
11
Le Waterfall incrémentielle
design
incrémentiel
design du
produit
Codage
Testage
design
incrémentiel
Maintenance
Codage
Testage
design
incrémentiel
Maintenance
Codage
Testage
Maintenance
Automne 2014
GEF492
12
Waterfall simple par opposition au
Waterfall incrémentiel
Personnel requis
Profiles de dotation
Chute d’eau simple
Incrémentiel
Temps d’élaboration
Automne 2014
GEF492
13
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
Automne 2014
GEF492
14
Prochain cours:
LES MODÈLES
INCRÉMENTIELS ET
ITÉRATIFS
Automne 2014
GEF492
15