Chapitre 8 - Informatique

Les revues de conception et de
code source - Survol
Les revues de
conception et de code
source
lQu’est-ce
que les revues de conception et de code
source?
lPourquoi
faire les revues de conception et de code
source?
lLe
Chapitre 8
PSP (Personnal Software Process)
–les stratégies de revue
–les principes de revue
–les mesures de revue
lLes
IFT514 - Gestion des systèmes informatiques Chapitre 8
considérations de la revue
1
IFT514 - Gestion des systèmes informatiques Chapitre 8
2
L’inspection
Qu’est-ce que les revues?
lL’inspection
fut introduite par Fagan chez IBM
en 1976.
lL’inspection suit un processus structuré
lUn
revue est une façon de reviser votre propre
travail.
lC’est un ensemble de méthodes
–réalisé par une équipe de révision
–les gestionnaires sont absents
–chaque participant a un rôle bien définie
–une phase de préparation est requise
–l’objectif est de détecter des problèmes
–les inspections
–les revues de projets «walkthroughs»
–les revues personnelles de produits
lCes
méthodes ont comme objectif de détecter et
de réparer les fautes le plus tôt possible dans le
cycle de développement des logiciels.
IFT514 - Gestion des systèmes informatiques Chapitre 8
lL’inspection
est utile pour toutes les phases du
cycle de développement des logiciels.
3
Revue de projet
(walkthrough)
walkthrough)
lLa
4
Revue personnelle du produit
revue de projet suit le format d’une réunion
lDans
–les développeurs expliquent à l’audience le produit
–l’audience peut être composé de collègues, de
gestionnaires ou d’autres personnes intéressées
–l’objectif est d’obtenir l’approbation de l’audience
–il n’y a pas de phase de préparation qui est requise
une revue personnelle
–chaque professionnel revise sont propre produit
–l’objectif est de détecter les fautes avant la première
compilation et les premiers tests
–les revues sont plus efficaces lorsqu’elles sont
structurées et mesurées
lLa
revue personnelle du produit peut être
utilisée pour l’analyse des besoins, la conception
et le code source
lLa
revue de projet est plus utile dans les phases
d’analyse de besoins et de conception
IFT514 - Gestion des systèmes informatiques Chapitre 8
IFT514 - Gestion des systèmes informatiques Chapitre 8
5
IFT514 - Gestion des systèmes informatiques Chapitre 8
6
1
Taux d'élimination des fautes
Pourquoi faire des revues? - 1
données démontrent que les revues sont
plus efficace que les tests pour détecter des
fautes
30
lLes
Fautes/heure
–les tests détectent de 2 à 4 fautes par heure
–les revues détectent en moyenne 10 fautes par heure
–des reviseurs de code expérimenté peuvent détecter
70% des fautes d’un produit
–les tests permettent rarement d’excéder un taux de
50%
20
15
Revue de code
5
1
7
lLa
correction des fautes trouvées lors des tests
est plus dispendieuse que la correction des fautes
trouvées lors des revues
–lors des tests intégrés, il faut de 10 à 40 h./personne
pour détecter et réparer chaque faute
–les inspections prennent moins d’une heure/faute
5
6
7
8
9
10
8
Pourquoi faire des revues? - 3
lÉlimination
des fautes le plus tôt possible
–chaque revue, inspection, compilation, et test détecte
seulement une fraction des fautes
–plus le code est propre en entrant dans une phase et
plus il sera propre en sortant de cette phase
tôt des fautes permet une économie
de temps et d’argent
–plus le processus de développement est avancé et plus
il est coûteux de détecter et de réparer les fautes
9
IFT514 - Gestion des systèmes informatiques Chapitre 8
10
Pourquoi les revues sont
efficaces - 2
des tests
lSi
le système produit un résultat incorrect lors
des tests, alors vous devrez
–vous débutez avec un problème
–alors vous devez détecter la faute
–ensuite, vous concevez une solution
–finalement, vous implantez et vous testez la solution
les revues et les inspections
–vous voyez la faute
–alors vous concevez une solution
–finalement, vous implantez et vous révisez la solution
IFT514 - Gestion des systèmes informatiques Chapitre 8
4
IFT514 - Gestion des systèmes informatiques Chapitre 8
Pourquoi les revues sont
efficaces - 1
lAvec
3
lÉlimination
données d’inspection
–O’Neil: il faut 25 min./faute dans 80-90% du temps
–Philips: il faut 15 min./faute par opposition à 8
heures par faute lors des tests
–Côté: entre 30 min. et 3h pour corriger 5 à 20 fautes
lLors
2
Programme
Pourquoi faire des revues? - 2
IFT514 - Gestion des systèmes informatiques Chapitre 8
test
Tests
0
PSP montre que les revues détectent de 2 à 5
fois plus de fautes par heure que les tests
lQuelques
revue de code
10
lLe
IFT514 - Gestion des systèmes informatiques Chapitre 8
Compilation
compilation
25
11
–détecter ce qui est incorrect
–résoudre le problème au niveau théorique
–détecter l’endroit dans le programme où implanter la
solution
–résoudre la faute qui a causé un tel comportement
lVous
êtes à la recherche de ce qui n’a pas été
planifié et cela peut prendre du temps
IFT514 - Gestion des systèmes informatiques Chapitre 8
12
2
Pourquoi les revues sont
efficaces - 3
lAvec
La stratégie de revue PSP
lL’objectif
du PSP est de produire des
programmes ayant un haut niveau de qualité à
chacune des phases du cycle de développement
lLa stratégie de revue qui permet d’atteindre cet
objectif consiste à
les revues et les inspections
–vous suivez votre propre logique
–lorsque vous détectez une faute, vous savez
exactement où vous êtes
–vous savez ce que le programme fait et ce qu’il ne
devrait pas faire
–donc, vous savez pourquoi c’est une faute
–vous êtes dans une bonne position pour concevoir
une solution complète et efficace
IFT514 - Gestion des systèmes informatiques Chapitre 8
–rassembler les données sur vos revues
–étudier les données
–juger quelles données sont utiles pour vous
–ajuster votre processus en conséquence
lProcessus
13
IFT514 - Gestion des systèmes informatiques Chapitre 8
PSP suit un processus rigoureux avec
–des critères d’entrée et des critères de sortie
–une structure de revue
–des directives, des listes de contrôle et des normes
lProduire
lLe
but du PSP est de détecter chaque faute
avant la première compilation ou le premier test
lPour atteindre cet objectif, il faut
–utiliser des normes de programmation
–utiliser des critères de conception
–mesurer et améliorer votre processus de revue
IFT514 - Gestion des systèmes informatiques Chapitre 8
conception révisable a
une stratégie de revue précise
lRevoir
la conception par étapes
lVérifier
que la logique implante correctement
les besoins des utilisateurs
IFT514 - Gestion des systèmes informatiques Chapitre 8
16
lLa
stratégie de revue spécifie l’ordre dans
lequel vous révisez les éléments de la conception
–cela dépend de la structure du produit
–par conséquent, la stratégie de revue doit être
considérée durant la conception
suggère que
lL’objectif
doit être de produire une conception
pouvant être
–les objectifs et les fonctions de la conception doivent
être clairement établis
–vous avez des critères de conception d’établies
–la conception est structurée d’une façon logique
IFT514 - Gestion des systèmes informatiques Chapitre 8
lSuivre
Suivre une stratégie de revue
précise
–un contexte définie
–une représentation précise
–une structure claire et consistante
lCela
une conception révisable
15
Produire une conception
révisable
lUne
14
Principes de revue de
conception
Principes de revue
lLe
d’apprentissage continue
–révisée par étapes
–testée par étapes
–intégrée par étapes
17
IFT514 - Gestion des systèmes informatiques Chapitre 8
18
3
Revoir la conception en
étapes - 1
Revoir la conception en
étapes - 2
lEn
révisant la conception par étapes, vous vous
assurez que tout est soigneusement vérifié
4. Vérifier la robustesse
5. Vérifier les appels de fonctions, de méthodes et
de procédures pour une utilisation correcte
Les étapes de revue suggérées
1. Vérifier que tout les éléments ont été conçues
6. Vérifier les variables spéciales, les paramètres,
les types et les fichiers pour une utilisation
correcte
2. Vérifier la structure et le flux d’ensemble du
programme
3. Vérifier l’exactitude de la logique
IFT514 - Gestion des systèmes informatiques Chapitre 8
19
Vérifier que la logique implante
correctement les besoins des
utilisateurs
lRevoir
les besoins des utilisateurs pour vous
assurer que chaque fonction qui est demandée
apparait dans la conception
lVérifier
mesures explicites
–la grandeur du programme qui est révisé
–le temps de révision
–le nombre de fautes trouvées
–le nombre de fautes non trouvées
21
mesures dérivées
IFT514 - Gestion des systèmes informatiques Chapitre 8
22
Rendement de la revue - 2
rendement (yield)
lLe
–mesure de la qualité du processus
–est le pourcentage de fautes trouvées dans un produit
à un temps de revue
–mesure l’efficacité de chaque étape du processus
lRendement
(pour une étape) = 100*(fautes
trouvées)/(fautes trouvées + non trouvées)
IFT514 - Gestion des systèmes informatiques Chapitre 8
lDes
–rendement (« Yield »)
–le nombre de LOC revue par heure
–le nombre de fautes trouvées par KLOC
–le nombre de fautes trouvées par heure de révision
–DRL (« Defect Removal Leverage »)
Rendement de la revue - 1
lLe
20
Les mesures de la revue
lDes
soigneusement les oublis
IFT514 - Gestion des systèmes informatiques Chapitre 8
IFT514 - Gestion des systèmes informatiques Chapitre 8
23
rendement peut être calculés seulement si
toutes les fautes ont été trouvées par les tests et
par l’utilisation du produit
lLe rendement peut être utile tôt dans le
processus de développement seulement si la
plupart des fautes ont été trouvées
lL’utilisation de paramètres potentiels de
contrôle peut nous assurer de faire des revues de
haut rendement
IFT514 - Gestion des systèmes informatiques Chapitre 8
24
4
«Defect Removal Leverage»:
Leverage»:
DRL (ratio productivité de revue vs testing)
testing)
mesure l’efficacité relative d’une étape
d’un processsus à enlever les fautes
lDRL est le nombre de fautes enlevées par heure
pour l’étape d’un processus relativement à un
processus de base
Contrôler le processus
lDRL
–la base habituelle est l’unité de test
–DRL(X/UT) est le DRL pour la phase X en
respectant l’unité de test
contrôler votre processus, vous avez
besoin de mesures disponibles durant
l’exécution de ce processus
lLe
rendement et le DRL sont très utiles, mais ils
sont disponibles seulement à la fin du processus
lOn
a besoin de mesures
–en corrélation avec le rendement
–qui sont disponibles lors du développement
DRL(X/UT) = (fautes par heure pour la phase
X) / (fautes par heure pour l’unité de test)
l
IFT514 - Gestion des systèmes informatiques Chapitre 8
lPour
25
IFT514 - Gestion des systèmes informatiques Chapitre 8
26
Rendement vs. LOC/Heure - étudiant
12
Paramètres potentiels de
contrôle
80
70
paramètres potentiels de contrôle pour le
rendement sont
Rendement
lLes
–Le nombre de LOC revue par heure
–Le nombre de fautes trouvées par heure
–Le nombre de fautes trouvées par KLOC
60
50
40
30
20
10
0
lLe
meilleur paramètres de contrôle est le
nombre de LOC revue par heure
IFT514 - Gestion des systèmes informatiques Chapitre 8
0
200
400
600
800
LOC/Heure
27
Les LOC revue par heure
IFT514 - Gestion des systèmes informatiques Chapitre 8
28
Les considérations de la revue
lLes
données des étudiant(e)s ont une variation
considérable
lCes exemples montrent que la revue structurée
peut être efficace si les étudiant(e)s
lLes
listes de contrôle
lRéviser
–suivent une procédure définie
–utilisent des listes de contrôle
–sont habitués aux fautes que font les gens
d’expérience
lLes
avant de compiler
relations entre les revues et les inspections
lLe
PSP suggère de ne pas réviser plus de 200
LOC par heure
IFT514 - Gestion des systèmes informatiques Chapitre 8
29
IFT514 - Gestion des systèmes informatiques Chapitre 8
30
5
Réviser avant de compiler - 1
Les listes de contrôle
lLe
PSP demande une révision du code avant la
première compilation
lLes raisons sont
lLors
de la réalisation d’une tâche précise, il est
difficile de bien faire plus d’une chose à la fois
lLa liste de contrôle définit les étapes à suivre
lors de la révision
lEn cochant chaque item, vous vous assurez de
réviser correctement
lVous pouvez établir une liste de contrôle en
considérant votre expérience personnelle
IFT514 - Gestion des systèmes informatiques Chapitre 8
–le temps requis pour la révision du code est le même
qu’elle soit faite avant ou après la compilation
–les revues de code vont permettre de détecter des
fautes de syntaxe que le compilateur va manquer
–les revues de code compilé ont tendance à être
beaucoup moins efficaces
–la compilation est également efficace avant ou après
la revue du code
31
Réviser avant de compiler - 2
lLe
PSP utilise la compilation pour évaluer la
qualité des revues
–s’il y a trop de fautes de compilation, alors une autre
revue est demandée
–si la compilation est adéquate, alors cela signifie que
la plupart des fautes ont été trouvées lors de la revue
lAprès
avoir complété le PSP, vous pouvez
rassembler des données sur vos revues (avant et
après la compilation) et identifier lesquelles sont
les plus efficaces pour vous
IFT514 - Gestion des systèmes informatiques Chapitre 8
IFT514 - Gestion des systèmes informatiques Chapitre 8
32
Les revues et les inspections
lL’objectif
principal des inspections doit être de
détecter les problèmes au niveau de l’analyse des
besoins et de la conception
lLorsque les programmes ont plusieurs petits
problèmes, les inspecteurs sont distraits et ils
manquent les problèmes les plus important
lPar conséquent, il faut réviser le code avant de
le faire inspecter, car cela
–procure un produit de qualité pour l’inspection
–montre un respect pour le temps de l’inspecteur
–produit des inspections de meilleure qualité
33
IFT514 - Gestion des systèmes informatiques Chapitre 8
34
Conclusion
lLes
revues de conception et de code vont
–améliorer la qualité de votre programme
–faire économiser du temps de développement
lPour
faire des revues efficaces, vous devez
–établir les objectifs de revue
–suivre un processus de revue discipliné
–mesurer et améliorer la qualité de vos revues
IFT514 - Gestion des systèmes informatiques Chapitre 8
35
6