assurance qualité -...
TRANSCRIPT
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 1
Cours de génie logicielCours de génie logiciel
Assurance QualitéAssurance Qualité
Renaud Marlet
LaBRI / INRIA
http://www.labri.fr/~marlet
(d'après A.-M. Hugues)
màj 23/04/2007
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 2
Les deux facettes de la qualitéLes deux facettes de la qualité
● Conformité avec la définition
(contrôlable en cours de fabrication ainsi qu'en maintenance)
● Réponse à l'attente du client
(contrôlable à la livraison principale ainsi que lors des livraisons intermédiaires)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 3
Contrôle qualitéContrôle qualité
Activité tout au long du cycle de vie– plus de 50% des erreurs sont découvertes en phase
d'exploitation– le coût de réparation croît exponentiellement avec
l'avancée dans le cycle de vie
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 4
TerminologieTerminologie
● Validation– Faisons-nous le bon produit ?
● Vérification– Faisons-nous le produit correctement ?
☛ Attention, en pratique– souvent confondus, ou pris l'un pour l'autre– on parle de « V&V » (validation et vérification)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 5
Terminologie IEEETerminologie IEEE
● Erreur :– commise par le développeur– conduit à un défaut
● Défaut :– imperfection dans le logiciel– conduit ou non à une panne
● Panne :– comportement anormal d'un programme
Terme courant mais ambigu : bogue (bug)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 6
Qualité : Approche de MacCallQualité : Approche de MacCall
● Caractéristiques « externes »– facteurs de qualité
● Caractéristiques « internes »– critères de qualité
● Caractéristiques mesurables– métriques
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 7
Facteurs de qualitéFacteurs de qualité
Facteurs de qualité classés en 3 catégories :– qualités opérationnelles
(product operation)
– facilité à changer ou à corriger (product revision)
– facilité à faire des transitions d'environnement (product transition)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 8
Facteurs de qualité (1) :Facteurs de qualité (1) :Qualités opérationnellesQualités opérationnelles
Conformité aux besoins :● le produit fait-il ce qu'on souhaite ?
Fiabilité :● le fait-il correctement dans tous les cas ?
Efficacité :● utilise-t-il au mieux les ressources matérielles / logicielles ?
Intégrité :● est-il protégé contre les intrusions ?
Facilité d'emploi :● ... au niveau de l'apprentissage, de la mise en œuvre, de la
fourniture des données, de l'interprétation des résultats, etc.
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 9
Facteurs de qualité (2) :Facteurs de qualité (2) :Facilité à changer ou à corrigerFacilité à changer ou à corriger
Maintenabilité :● facilité avec laquelle on peut localiser et corriger les
erreurs
Flexibilité :● facilité de modification et d'évolution
Testabilité :● effort requis pour tester (après modification)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 10
Facteurs de qualité (3) : Facilité à Facteurs de qualité (3) : Facilité à faire des transitions d'environnementfaire des transitions d'environnement
Portabilité :● peut-on utiliser le logiciel sur une autre machine ?
Réutilisabilité :● peut-on réutiliser des parties du logiciel dans d'autres
applications ?
Interopérabilité :● facilité d'interfaçage avec d'autres systèmes
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 11
Influence des facteurs de qualité Influence des facteurs de qualité les uns sur les autresles uns sur les autres
Ex. facteurs qui diminuent l'efficacité– intégrité (nécessité d'introduire des vérifications)– maintenabilité (sacrifice de l'efficacité pour la lisibilité)– portabilité (moindre efficacité des structures portables)– testabilité, flexibilité, réutilisabilité, interopérabilité, ...
Ex. facteurs qui diminuent l'intégrité– flexibilité, réutilisabilité, interopérabilité
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 12
Critères de qualitéCritères de qualité
Opérabilité
Apprentissage
Volume et taux d'E/S
Communicabilité
Contrôle d'accès
Consommation mémoire
Vitesse d'exécution
Traçabilité
Complétude
Cohérence
Tolérance aux fautes
Simplicité
Précision
Modularité
Concision
Auto-description
Instrumentation
Généralité
Evolutivité
Indépendance machine
Indépendance système
Communications banalisés
Données banalisées
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 13
Tolérance aux fautes
Exercice : trouver les (>40) liens entre Exercice : trouver les (>40) liens entre facteurs de qualité et critères de qualitéfacteurs de qualité et critères de qualité
Opérabilité
Apprentissage
Volume et taux d'E/S
Communicabilité
Contrôle d'accès
Consommation mémoire
Vitesse d'exécution
Traçabilité
Complétude
Cohérence
Simplicité
Précision
Modularité
Concision
Auto-description
Instrumentation
Généralité
Évolutivité
Indépendance machine
Indépendance système
Communications banalisés
Données banalisées
Facilité d'emploi
Intégrité
Efficacité
Conformité
Fiabilité
Maintenabilité
Testabilité
Flexibilité
Portabilité
Réutilisabilité
Interopérabilité
Crit
ères
de
qual
ité(c
arac
téris
tique
s in
tern
es)
Facteurs de qualité
(caractéristiques externes)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 14
Liens entre facteurs de qualité et Liens entre facteurs de qualité et critères de qualitécritères de qualité
Opérabilité
Apprentissage
Volume et taux d'E/S
Communicabilité
Contrôle d'accès
Consommation mémoire
Vitesse d'exécution
Traçabilité
Complétude
Cohérence
Tolérance aux fautes
Simplicité
Précision
Modularité
Concision
Auto-description
Instrumentation
Généralité
Évolutivité
Indépendance machine
Indépendance système
Communications banalisés
Données banalisées
Facilité d'emploi
Intégrité
Efficacité
Conformité
Fiabilité
Maintenabilité
Testabilité
Flexibilité
Portabilité
Réutilisabilité
Interopérabilité
QuestionY a-t-il
un critère « majeur » ?
Crit
ères
de
qual
ité(c
arac
téris
tique
s in
tern
es)
Facteurs de qualité
(caractéristiques externes)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 15
Liens entre facteurs de qualité et Liens entre facteurs de qualité et critères de qualitécritères de qualité
Opérabilité
Apprentissage
Volume et taux d'E/S
Communicabilité
Contrôle d'accès
Consommation mémoire
Vitesse d'exécution
Traçabilité
Complétude
Cohérence
Tolérance aux fautes
Simplicité
Précision
Modularité
Concision
Auto-description
Instrumentation
Généralité
Évolutivité
Indépendance machine
Indépendance système
Communications banalisés
Données banalisées
Facilité d'emploi
Intégrité
Efficacité
Conformité
Fiabilité
Maintenabilité
Testabilité
Flexibilité
Portabilité
Réutilisabilité
Interopérabilité
☛
Impactfort de la
modularité
Crit
ères
de
qual
ité(c
arac
téris
tique
s in
tern
es)
Facteurs de qualité
(caractéristiques externes)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 16
Métriques associées aux Métriques associées aux critères de qualitécritères de qualité
● Mesure des caractéristiques « internes »– mesures objectives
● ex. : taille, complexité du flot de contrôle, cohésion modulaire / couplage entre modules, ...
● Mesure des caractéristiques « externes »– évaluations stochastiques (statistiques)
● ex. : délai moyen de réponse à une requête, nombre de requêtes simultanées sans « écrouler » un serveur, ...
☛ Ce sont des mesures a posteriori→ arrivent parfois « trop tard »
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 17
Exemples de mesures deExemples de mesures decritères de qualité (1)critères de qualité (1)
● Fiabilité :– mesures stochastiques :
● temps moyen de réparation● temps moyen entre deux pannes● taux de disponibilité
● Portabilité :– mesure objective :
● nb d'instructions dépendant de la plate-forme cible
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 18
Exemples de mesures deExemples de mesures decritères de qualité (2)critères de qualité (2)
● Facilité d'utilisation :– mesures objectives :
● nb de paramètres ayant une valeur par défaut (pertinente)● nb d'écrans d'aide
– mesures stochastiques :● nb de fausses manipulations par jour● nb de jours d'apprentissage● temps de lecture / interprétation des résultats affichés
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 19
MétriquesMétriques
● Métriques– de Halstead, de McCabe, de Henry et Kafura, ..
● Quantités mesurées– concision (taille programme / taille de l'algorithme),
complexité textuelle, difficulté, effort, complexité des liaisons inter-modules (ou -classes), encombrement d'une classe, complexité structurelle, ...
● Implémentées par des outils– Logiscope, ...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 20
Exemple : Métrique de McCabeExemple : Métrique de McCabe
● Analyse du graphe de contrôle● Mesure de la complexité structurelle● Nombre cyclomatique
= nb de noeuds (blocs d'instructions séquentielles)
− nb d'arcs (branches de programme)
+ nb points d'entrée
+ nb points de sortie● Représente le nombre de chemins indépendants
~ nb conditions + 1 (si les décisions sont binaires)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 21
Métrique de McCabe : exempleMétrique de McCabe : exemple
C1
C2 X2
X3X1nb entrées = 1nb sorties = 1nb noeuds (blocs) = 5nb arcs (branches) = 6nb cyclomatique = 6 – 5 + 1 + 1 = 3(nb décisions = 2)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 22
Qualité : comment faire ?Qualité : comment faire ?
Un grand nombre de métriques– difficile de les connaître toutes, et souvent discutables
(vision partielle/artificielle du problème)
L'important, c'est la démarche :– définir un plan qualité adapté au contexte– détailler une mesure des différents critères– s'interroger sur la validité des métriques (pertinence)
Problème des mesures a posteriori– trop tard, mais forge l'expérience (☺)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 23
Assurance qualité et gestion projet (1)Assurance qualité et gestion projet (1)
Le contrôle qualité aide la gestion projet :– mesure de l'avancement– meilleure estimation des coûts
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 24
Assurance qualité et gestion projet (2)Assurance qualité et gestion projet (2)
Mais (écueils) :
● dilemme : moins cher ou plus sûr ?– souvent prééminence du planning sur la qualité
● sous-estimation des ressources qui sont nécessaires à l'assurance qualité– par les développeurs (activité jugée marginale)– par les managers (réticence à prévoir un budget
maintenance)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 25
Moyens de l'assurance qualitéMoyens de l'assurance qualité
● Méthodes statiques a priori (sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification
● analyse statique de programme● vérification de modèle (model checking)● outils de preuves formelles
● Méthodes dynamiques a posteriori (en exécutant le logiciel)– test
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 26
Moyens de l'assurance qualitéMoyens de l'assurance qualité
● Méthodes statiques a priori (sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification
● analyse statique de programme● vérification de modèle (model checking)● outils de preuves formelles
● Méthodes dynamiques a posteriori (en exécutant le logiciel)– test
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 27
Examen critique de documents (1)Examen critique de documents (1)
● Avoir un point de vue différent de l'auteur
→ quelqu'un d'autre
● Avoir différents points de vue
→ compétences multiples
● Avoir des points de vue objectifs
→ participants hors de l'équipe de développement
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 28
Examen critique de documents (2)Examen critique de documents (2)
● Critiquer les aspects techniques, pas l'auteur (!)● Juger la forme
– format [voir cours sur la documentation], structure, satisfaction des normes du plan qualité...
● Juger le fond– précision, non-ambiguïté, complétude, cohérence
(pas de référence imprécise ou inexistante)– conformité par rapport aux documents amont, au
plan projet
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 29
Coût des inspectionsCoût des inspections(ordres de grandeur)(ordres de grandeur)
● Cahier des charges 5-10 pages/h● Spécifications fonctionnelles 10 pages/h● Conception globale 5-15 pages/h● Conception détaillé 10 pages/h● Code 20-50 lignes/h
(Selon moi :– effort trop faible dans les phases amont– effort difficile et peu productif dans les phases aval)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 30
Méthodes de relecture (1)Méthodes de relecture (1)
● Auto-correction (desk-checking)– relecture personnelle– bilan : efficacité quasi nulle pour les documents
amont, faible pour le code● Lecture croisée (author-reader cycle)
– un collègue recherche des ambiguïtés, oublis, imprécisions
– bilan : efficacité faible pour les documents amont, plus adapté pour la relecture du code
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 31
Méthodes de relecture (2)Méthodes de relecture (2)
● Revue (walkthrough)– discussion informelle au sein d'un groupe– un lecteur résume paragraphe par paragraphe– bilan : contribution moyenne à l'assurance qualité
(évaluation très liée à la prestation du lecteur)● Revue structurée
– constitution pendant le débat d'une liste de défauts, utilisation d'une liste de défauts typiques (checklist)
– direction des débats par un secrétaire– bilan : bonne contribution à l'assurance qualité
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 32
Méthodes de relecture (3)Méthodes de relecture (3)
● Inspection– cadre de relecture plus formel– recherche des défauts avant les débats– suivi des décisions et corrections– bilan : excellente contribution à l'assurance qualité
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 33
Méthodes de relecture :Méthodes de relecture :Inspection (1)Inspection (1)
Organisation
1. préparation● recherche des défauts● rédaction d'un rapport de défauts basé sur des fiches type
2. cycle de réunions● examen des défauts● prise de décision
3. suivi● vérification des corrections ou nouvelle inspection
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 34
Méthodes de relecture :Méthodes de relecture :Inspection (2)Inspection (2)
Planification – pour chaque type de document :– dates de début et de fin par rapport au plan projet– critères de sélection des inspecteurs– plan d'inspection (parties à inspecter)– types de défauts les plus communs (checklist)– formulaires d'inspection (description de défauts)– critères de succès de l'inspection
(Ce plan figure en partie dans le plan qualité)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 35
Méthodes de relecture :Méthodes de relecture :Inspection (3)Inspection (3)
Responsabilités– inspecteurs :
● responsables de la qualité du produit final● responsables du respect des principes de qualité
– auteur :● mise à disposition des documents à la date prévue● fournit une opinion sur chaque défaut signalé
– ...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 36
Méthodes de relecture :Méthodes de relecture :Inspection (4)Inspection (4)
Responsabilités– ...– secrétaire :
● enregistre les défauts considérés et les décisions prises ● assiste le modérateur
– modérateur :● responsable du bon déroulement des réunions
– convocation, tenue, suspension● veille au maintien des objectifs et aux facteurs humains● préside la prise de décision
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 37
Méthodes de relecture :Méthodes de relecture :Inspection (5)Inspection (5)
● Conséquence– la formalisation oblige à planifier et à observer les
principes de qualité● Bilan
– excellente contribution à l'assurance qualité– amélioration du cycle de vie (contrôle au plus tôt)– influence positive sur la communication et la
formation dans le projet
☛ la meilleure des méthodes de relecture
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 38
Et maintenant...Et maintenant...
Quelques exercices d'inspection de code...
(et de correction)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 39
Exercice 1 : trouver 4 erreursExercice 1 : trouver 4 erreurs(Elles sont typiques)(Elles sont typiques)
int factorielle(int n){ int f; while (n >= 0) { n = n-1; f = f*n; } return n;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 40
Exercice 1 : les 4 erreursExercice 1 : les 4 erreurs(Elles sont typiques)(Elles sont typiques)
int factorielle(int n){ int f; while (n >= 0) { n = n-1; f = f*n; } return n;}
● variable f non initialisée (à 1)
● tour de boucle en trop (n = 0)
● opération sur un mauvais indice (n-1 et non n)
● retour d'une mauvaise variable (ici n)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 41
Exercice 1 (suite) : corriger les erreursExercice 1 (suite) : corriger les erreurs
int factorielle(int n){ int f; while (n >= 0) { n = n-1; f = f*n; } return n;}
● variable f non initialisée (à 1)
● tour de boucle en trop (n = 0)
● opération sur un mauvais indice (n-1 et non n)
● retour d'une mauvaise variable (ici n)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 42
Exercice 1 (suite) : version corrigéeExercice 1 (suite) : version corrigée
int factorielle(int n){ int f = 1; while (n > 0) { f = f*n; n = n-1; } return f;}
● variable f initialisée (à 1)
● pas de tour de boucle en trop
● opération sur un bon indice (n)
● retour de la variable correcte (f)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 43
Exercice 2 : trouver 5 erreursExercice 2 : trouver 5 erreurs(Elles sont typiques)(Elles sont typiques)
.../* Entrée pt cardinal */printf("Direction : ");scanf("%c", direction);switch (direction){ case 'N' : y++; case 'O' : x--; case 'S' : x++;}deplacer(x,y);...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 44
Exercice 2 : les 5 erreursExercice 2 : les 5 erreurs(Elles sont typiques)(Elles sont typiques)
● variable au lieu de pointeur sur variable
● case manquant● break oubliés● copy/paste non
ou mal adapté● default
manquant
.../* Entrée pt cardinal */printf("Direction : ");scanf("%c", direction);switch (direction){ case 'N' : y++; case 'O' : x--; case 'S' : x++;}deplacer(x,y);...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 45
Exercice 2 (suite) : corriger les erreursExercice 2 (suite) : corriger les erreurs
● variable au lieu de pointeur sur variable
● case manquant● break oubliés● copy/paste non
ou mal adapté● default
manquant
.../* Entrée pt cardinal */printf("Direction : ");scanf("%c", direction);switch (direction){ case 'N' : y++; case 'O' : x--; case 'S' : x++;}deplacer(x,y);...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 46
Exercice 2 (suite) : version corrigéeExercice 2 (suite) : version corrigée
.../* Entrée pt cardinal */printf("Direction : ");scanf("%c",&direction);switch (direction) { case 'E' : x++; break; case 'N' : y++; break; case 'O' : x--; break; case 'S' : y--; break; default : error();}deplacer(x,y);
● pointeur sur variable
● tous les case présents et corrects
● break présents● pas d'erreur de
copy/paste● default présent
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 47
Exercice 3 : trouver 5 erreursExercice 3 : trouver 5 erreurs(Elles sont typiques)(Elles sont typiques)
int tab[]; /*de taille size*/int indiceTqTabNul(int size){ int i; if (size > 0) for(i=1; i <= size; i++) if (tab[i] = 0) return i; else printf("tab est vide"); error(); return -1;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 48
Exercice 3 : les 5 erreursExercice 3 : les 5 erreurs(Elles sont typiques)(Elles sont typiques)
● oubli d'un cas d'indice
● cas d'indice hors borne
● test par = au lieu de ==
● dandling else● accolades
manquantes
int tab[]; /*de taille size*/int indiceTqTabNul(int size){ int i; if (size > 0) for(i=1; i <= size; i++) if (tab[i] = 0) return i; else printf("tab est vide"); error(); return -1;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 49
Exercice 3 (suite) : corriger les erreursExercice 3 (suite) : corriger les erreurs
● oubli d'un cas d'indice
● cas d'indice hors borne
● test par = au lieu de ==
● dandling else● accolades
manquantes
int tab[]; /*de taille size*/int indiceTqTabNul(int size){ int i; if (size > 0) for(i=1; i <= size; i++) if (tab[i] = 0) return i; else printf("tab est vide"); error(); return -1;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 50
Exercice 3 (suite) : version corrigéeExercice 3 (suite) : version corrigée
● pas d'indice oublié
● pas d'indice hors borne
● test par '==' et non '='
● accolades appropriées
int tab[]; /*de taille size*/int indiceTqTabNul(int size){ int i; if (size > 0) { for(i=0; i < size; i++) if (tab[i] == 0) return i; } else { printf("tab est vide"); error(); } return -1;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 51
Exercice 4 : trouver une erreurExercice 4 : trouver une erreur(Elle est typique)(Elle est typique)
int compte = ...;int decouvert_max = -1000;void transact(int montant)/* débit: montant < 0 * crédit: montant > 0 */{ if (compte + montant < decouvert_max) printf("Refusé"); else compte += montant;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 52
Exercice 4 : l'erreurExercice 4 : l'erreur(Elle est typique)(Elle est typique)
int compte = ...;int decouvert_max = -1000;void transact(int montant)/* débit: montant < 0 * crédit: montant > 0 */{ if (compte + montant < decouvert_max) printf("Refusé"); else compte += montant;}
● overflow non maîtrisé : compte + montant > 231 → compte + montant < 0
● underflow non maîtrisé : si compte=-500 et montant=-231 alors compte + montant > 0 !(= 231-500)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 53
Exercice 4 (suite) : corriger l'erreurExercice 4 (suite) : corriger l'erreur
int compte = ...;int decouvert_max = -1000;void transact(int montant)/* débit: montant < 0 * crédit: montant > 0 */{ if (compte + montant < decouvert_max) printf("Refusé"); else compte += montant;}
● overflow non maîtrisé : compte + montant > 231 → compte + montant < 0
● underflow non maîtrisé : si compte=-500 et montant=-231 alors compte + montant > 0 !(= 231-500)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 54
Exercice 4 (suite) : version corrigéeExercice 4 (suite) : version corrigée
void transact(int montant)
{
if (montant > 0 && compte > 0 && compte+montant < 0)
printf("Overflow");
else if (montant<0 && compte<0 && compte+montant>0)
printf("Underflow");
else if (compte+montant < decouvert_max)
printf("Refusé");
else
compte += montant;
}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 55
Exercice 5 : trouver 3 erreursExercice 5 : trouver 3 erreurs(Elles sont typiques)(Elles sont typiques)
/* Si p non nul pointe sur * un entier positif */if (p != NULL & *p >= 0) ...
/* Si x est pair et * de valeur absolue >= 5 */if (x%2 == 0 && x <= -5 || 5 <= x) ...
/* Si x et y sont positifs * ou nuls */if (x && y >= 0) ...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 56
Exercice 5 : les 3 erreursExercice 5 : les 3 erreurs(Elles sont typiques)(Elles sont typiques)
● expression évaluée ne devant pas l'être
● précédence des opérateurs logiques
● comparaison factorisée
/* Si p non nul pointe sur * un entier positif */if (p != NULL & *p >= 0) ...
/* Si x est pair et * de valeur absolue >= 5 */if (x%2 == 0 && x <= -5 || 5 <= x) ...
/* Si x et y sont positifs * ou nuls */if (x && y >= 0) ...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 57
Exercice 5 (suite) : corriger les erreursExercice 5 (suite) : corriger les erreurs
● expression évaluée ne devant pas l'être
● précédence des opérateurs logiques
● comparaison factorisée
/* Si p non nul pointe sur * un entier positif */if (p != NULL & *p >= 0) ...
/* Si x est pair et * de valeur absolue >= 5 */if (x%2 == 0 && x <= -5 || 5 <= x) ...
/* Si x et y sont positifs * ou nuls */if (x && y >= 0) ...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 58
Exercice 5 : version corrigéeExercice 5 : version corrigée
● expression évaluée que si nécessaire
● parenthésage des opérateurs logiques
● comparaison non factorisée
/* Si p non nul pointe sur * un entier positif */if ((p != NULL) && (*p >= 0)) /* Si x est pair et * de valeur absolue >= 5 */if (x%2 == 0 && (x <= -5 || 5 <= x)) ...
/* Si x et y sont positifs * ou nuls */if (x >= 0 && y >= 0) ...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 59
Exercice 6 : trouver 3 erreursExercice 6 : trouver 3 erreurs(Elles sont typiques)(Elles sont typiques)
typedef struct lst { int elem; struct lst *reste;} *list;
int dernierElem(list l){ do { l = l->reste; } while (l->reste != NULL); return l->reste->elem;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 60
Exercice 6 : les 3 erreursExercice 6 : les 3 erreurs(Elles sont typiques)(Elles sont typiques)
● cas d'un argument pointeur nul (liste vide) non traité
● premier élément non traité (liste à un élément)
● déréférence d'un pointeur nul au terme de l'itération
typedef struct lst { int elem; struct lst *reste;} *list;
int dernierElem(list l){ do { l = l->reste; } while (l->reste != NULL); return l->reste->elem;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 61
Exercice 6 (suite) : corriger les erreursExercice 6 (suite) : corriger les erreurs
● cas d'un argument pointeur nul (liste vide) non traité
● premier élément non traité (liste à un élément)
● déréférence d'un pointeur nul au terme de l'itération
typedef struct lst { int elem; struct lst *reste;} *list;
int dernierElem(list l){ do { l = l->reste; } while (l->reste != NULL); return l->reste->elem;}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 62
Exercice 6 : version corrigéeExercice 6 : version corrigée
typedef struct lst { int elem; struct lst *reste;} *list;
int dernierElem(list l){ if (l == NULL) error(); while (l->reste != NULL) l = l->reste; return l->elem;}
● cas d'un argument pointeur nul (liste vide) traité
● premier élément traité correctement
● déréférence du bon pointeur au terme de l'itération
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 63
Inspection de code :Inspection de code :Défauts typiques à examiner (1)Défauts typiques à examiner (1)
Référence aux données :– variables non initialisées
☛ savoir si le langage initialise par défaut et quand
☛ dans les cas douteux, initialiser explicitement
– indices de tableaux hors bornes☛ principale source des failles de sécurité (!)
– accès à des structures/records à champs variables ou à des unions
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 64
Inspection de code :Inspection de code :Défauts typiques à examiner (2)Défauts typiques à examiner (2)
Référence aux données :– confusion entre donnée et pointeur vers la donnée – déréférence de pointeurs nuls– pointeurs sur des données désallouées ou pas
encore allouées– pointeurs sur des données devenues inutiles mais
non libérées
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 65
Inspection de code :Inspection de code :Défauts typiques à examiner (3)Défauts typiques à examiner (3)
Calculs :– conversions de type (implicites et explicites)– underflow/overflow (dépassement de capacité du type)– division par zéro– précédence des opérateurs
☛ dans le doute (pour la lisibilité), toujours parenthéser
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 66
Inspection de code :Inspection de code :Défauts typiques à examiner (4)Défauts typiques à examiner (4)
Comparaisons :– incohérence des types
● mélanges d'entiers et de booléens
– inclusion ou non des bornes incorrecte● < au lieu de <=, >= au lieu de >, ...
– inversion du test● == au lieu de !=, > au lieu de <, ...
– confusion en égalité (==) et affectation (=)● if (x = y) {...} au lieu de if (x == y) {...}
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 67
Inspection de code :Inspection de code :Défauts typiques à examiner (5)Défauts typiques à examiner (5)
Comparaisons :– confusion entre opérateurs binaires (bits) et logiques
● et (&, &&, and), ou (|, ||, or), négation (~, !, not)
– négation incorrecte d'une condition logique● !(x ==1 && (y < 2 || !z)) équiv. x !=1 || (y >= 2 && z)
– précédence des opérateurs booléens● x || y && z équiv. x || (y && z)
☛ dans le doute (pour la lisibilité), toujours parenthéser
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 68
Inspection de code :Inspection de code :Défauts typiques à examiner (6)Défauts typiques à examiner (6)
Contrôle :– switch
● ensemble de case incomplet● cas default manquant● break oublié
– rattachement du else au if (« dandling else »)1. if (a) if (b) x=0; else x=1;
2. if (a) {if (b) x=0;} else x=1; /* diff. de 1. */
3. if (a) {if (b) x=0; else x=1;} /* idem 1. */
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 69
Inspection de code :Inspection de code :Défauts typiques à examiner (7)Défauts typiques à examiner (7)
Contrôle :– terminaison du programme
● boucles et récursions sans fin
– boucles● conditions initiales (indices, ...) incorrectes● itérations en plus ou en moins● incohérences après une sortie de boucle anticipée● incohérences après une sortie de boucles emboîtées
– procédures et fonctions● incohérences après une sortie anticipée
– exceptions non rattrapées
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 70
Moyens de l'assurance qualitéMoyens de l'assurance qualité
● Méthodes statiques a priori(sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification
● analyse statique de programme● vérification de modèle (model checking)● outils de preuves formelles
● Méthodes dynamiques a posteriori(en exécutant le logiciel)– test
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 71
Analyse statique de code (1)Analyse statique de code (1)
● Définition générale :– étude d'un programme (généralement source) sans
exécution● Attention, deux sens pour « analyse statique » :
– inspection manuelle (humaine) du code– outil d'analyse automatique
→ messages d'erreur comme ceux d'un compilateur
● Dans tous les cas– effectuée avant les tests, car élimine des erreurs de
« logique », coûteuses à corriger si découvertes tard
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 72
Analyse statique de code (2)Analyse statique de code (2)
Exemples de propriétés vérifiées :– typage– variables non initialisées– déréférence de pointeurs nuls– débordement de tableaux– fuites mémoire– problèmes d'interopérabilité– problèmes de sécurité : fuite de secrets, ...– ...
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 73
Analyse statique de code (3)Analyse statique de code (3)
● Outils– très high-tech– encore peu répandus
● Réussites– bug d'Ariane 5
● Difficultés– faux positifs (avertissement injustifiés)
erreur certaine
erreur possible
pas d'erreur
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 74
Limites théoriques (1)Limites théoriques (1)
● Notion d'indécidabilité– propriété indécidable = qu'on ne pourra jamais prouver
dans le cas général (pas de procédé systématique)
● Exemples de propriétés indécidables– l'exécution d'un programme termine– deux programmes calculent la même chose– un programme n'a pas d'erreur
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 75
Limites théoriques (2)Limites théoriques (2)
● Quand un propriété est indécidable, juste dire que c'est possible et laisser l'humain juger
● Erreur possible ≠ outil pas assez puissant
erreur certaine
erreur possible
pas d'erreur
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 76
Moyens de l'assurance qualitéMoyens de l'assurance qualité
● Méthodes statiques a priori(sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification
● analyse statique de programme● vérification de modèle (model checking)● outils de preuves formelles
● Méthodes dynamiques a posteriori(en exécutant le logiciel)– test
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 77
Vérification de modèleVérification de modèle
● Vérification– qu'un état est accessible ou non (vivacité)– qu'un état est accessible en un temps fini (équité)
● Application– programmes pas trop gros (< 10000 LOC)– nécessité de faire des abstractions– 1020 états avec certaines approches, et même plus
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 78
Moyens de l'assurance qualitéMoyens de l'assurance qualité
● Méthodes statiques a priori(sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification
● analyse statique de programme● vérification de modèle (model checking)● outils de preuves formelles
● Méthodes dynamiques a posteriori(en exécutant le logiciel)– test
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 79
Outils de preuves formellesOutils de preuves formelles
● Preuves de– correction (par rapport à une spécification)– terminaison de l'exécution– propriétés spécifiques (sûreté, sécurité, ...)
● Assistants de preuve (theorem prover)– systèmes : Coq, PVS, Isabelle / HOL, ...– encore difficiles d'usage pour des non spécialistes
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 80
Moyens de l'assurance qualitéMoyens de l'assurance qualité
● Méthodes statiques a priori(sans exécuter le logiciel)– examen critique de documents et de code– analyse automatique (ou assistée) de code / spécification
● analyse statique de programme● vérification de modèle (model checking)● outils de preuves formelles
● Méthodes dynamiques a posteriori(en exécutant le logiciel)– test
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 81
TestTest
● Vérification (conformité aux spécifications)– tests unitaires– tests d'intégration
● Qualification– validation par rapport aux contraintes non
fonctionnelles● tests de performance● tests de capacité de charge
– validation par rapport aux besoins● bêta-test (chez l'utilisateur final)
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 82
TestTest
☛ Voir cours spécifique sur le test
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 83
Et au stade de recherche avancée...Et au stade de recherche avancée...
● Génération automatique de programmes à partir des spécifications
→ programmes corrects par construction
● Mais– méthode encore trop mathématique pour le public
des développeurs– problème d'efficacité du code généré– problème de rendement (malgré l'automatisation)
● beaucoup de choses à spécifier avec soin● dilemme bien connu : moins cher ou plus sûr ?
Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet 84
ÀÀ retenir retenir
● Contrôle qualité : durant tout le cycle de vie● L'important, c'est la démarche
– définir un plan qualité adapté au contexte
– détailler les mesures des critères (a posteriori ☹)
– s'interroger sur la pertinence des métriques● Méthodes statiques (sans exécuter) :
– inspection : par des extérieurs, checklist de défauts– analyse automatique (ou assistée) de programme
● Méthodes dynamiques (en exécutant) : test