Assurance Qualité. Cours de génie logiciel. Renaud Marlet. LaBRI / INRIA (d'après A.-M. Hugues) màj 23/04/2007

Transcription

1 1 Cours de génie logiciel (d'après A.-M. Hugues) Assurance Qualité Renaud Marlet LaBRI / INRIA màj 23/04/2007

2 2 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)

3 3 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

4 4 Terminologie 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)

5 5 Terminologie 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)

6 6 Qualité : Approche de MacCall Caractéristiques «externes» facteurs de qualité Caractéristiques «internes» critères de qualité Caractéristiques mesurables métriques

7 7 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)

8 Facteurs de qualité (1) : 8 Qualité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.

9 Facteurs de qualité (2) : 9 Facilité à 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)

10 Facteurs de qualité (3) : Facilité à 10 faire 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

11 Influence des facteurs de qualité 11 les 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é

12 12 Critères de qualité Opérabilité Communicabilité Apprentissage Volume et taux d'e/s Contrôle d'accès Consommation mémoire Vitesse d'exécution Traçabilité Complétude Précision Cohérence Tolérance aux fautes Simplicité Modularité Concision Auto-description Instrumentation Généralité Evolutivité Indépendance machine Indépendance système Communications banalisés Données banalisées

13 Exercice : trouver les (>40) liens entre 13 facteurs de qualité et critères de qualité Critères de qualité (caractéristiques internes) Opérabilité Communicabilité Apprentissage Volume et taux d'e/s Contrôle d'accès Consommation mémoire Vitesse d'exécution Traçabilité Complétude Précision Cohérence Tolérance aux fautes Simplicité Modularité Concision Auto-description Instrumentation Généralité Évolutivité Indépendance machine Indépendance système Facilité d'emploi Intégrité Efficacité Conformité Fiabilité Maintenabilité Testabilité Flexibilité Portabilité Réutilisabilité Facteurs de qualité (caractéristiques externes) Communications banalisés Données banalisées Interopérabilité

14 Liens entre facteurs de qualité et 14 critères de qualité Critères de qualité (caractéristiques internes) Question Y a-t-il un critère «majeur»? Opérabilité Communicabilité Apprentissage Volume et taux d'e/s Contrôle d'accès Consommation mémoire Vitesse d'exécution Traçabilité Complétude Précision Cohérence Tolérance aux fautes Simplicité 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é Facteurs de qualité (caractéristiques externes)

15 Liens entre facteurs de qualité et 15 critères de qualité Critères de qualité (caractéristiques internes) Impact fort de la modularité Opérabilité Communicabilité Apprentissage Volume et taux d'e/s Contrôle d'accès Consommation mémoire Vitesse d'exécution Traçabilité Complétude Précision Cohérence Tolérance aux fautes Simplicité Modularité Concision Auto-description Instrumentation Généralité Évolutivité Indépendance machine Indépendance système Facilité d'emploi Intégrité Efficacité Conformité Fiabilité Maintenabilité Testabilité Flexibilité Portabilité Réutilisabilité Facteurs de qualité (caractéristiques externes) Communications banalisés Données banalisées Interopérabilité

16 Métriques associées aux 16 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»

17 Exemples de mesures de 17 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

18 Exemples de mesures de 18 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

19 19 Mé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,...

20 20 Exemple : 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)

21 21 Métrique de McCabe : exemple C1 C2 X2 nb entrées = 1 nb sorties = 1 nb noeuds (blocs) = 5 nb arcs (branches) = 6 nb cyclomatique = = 3 (nb décisions = 2) X1 X3

22 22 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 ( )

23 23 Assurance qualité et gestion projet (1) Le contrôle qualité aide la gestion projet : mesure de l'avancement meilleure estimation des coûts

24 24 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)

25 25 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

26 26 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

27 27 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

28 28 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

29 29 Coût des inspections (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 lignes/h (Selon moi : effort trop faible dans les phases amont effort difficile et peu productif dans les phases aval)

30 30 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

31 31 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é

32 32 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é

33 Méthodes de relecture : 33 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 3. suivi examen des défauts prise de décision vérification des corrections ou nouvelle inspection

34 Méthodes de relecture : 34 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é)

35 Méthodes de relecture : 35 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é

36 Méthodes de relecture : 36 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

37 Méthodes de relecture : 37 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

38 38 Et maintenant... Quelques exercices d'inspection de code... (et de correction)

39 Exercice 1 : trouver 4 erreurs 39 (Elles sont typiques) int factorielle(int n) { int f; while (n >= 0) { n = n-1; f = f*n; } return n; }

40 Exercice 1 : les 4 erreurs 40 (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)

41 41 Exercice 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)

42 42 Exercice 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)

43 Exercice 2 : trouver 5 erreurs 43 (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);...

44 Exercice 2 : les 5 erreurs 44 (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);... variable au lieu de pointeur sur variable case manquant break oubliés copy/paste non ou mal adapté default manquant

45 45 Exercice 2 (suite) : corriger les erreurs... /* Entrée pt cardinal */ printf("direction : "); scanf("%c", direction); switch (direction) { case 'N' : y++; case 'O' : x--; case 'S' : x++; } deplacer(x,y);... variable au lieu de pointeur sur variable case manquant break oubliés copy/paste non ou mal adapté default manquant

46 46 Exercice 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

47 Exercice 3 : trouver 5 erreurs 47 (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; }

48 Exercice 3 : les 5 erreurs 48 (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; } oubli d'un cas d'indice cas d'indice hors borne test par = au lieu de == dandling else accolades manquantes

49 49 Exercice 3 (suite) : corriger les erreurs 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; } oubli d'un cas d'indice cas d'indice hors borne test par = au lieu de == dandling else accolades manquantes

50 50 Exercice 3 (suite) : version corrigée 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; } pas d'indice oublié pas d'indice hors borne test par '==' et non '=' accolades appropriées

51 Exercice 4 : trouver une erreur 51 (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; }

52 Exercice 4 : l'erreur 52 (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 > 2 31 compte + montant < 0 underflow non maîtrisé : si compte=-500 et montant=-2 31 alors compte + montant > 0! (= )

53 53 Exercice 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 > 2 31 compte + montant < 0 underflow non maîtrisé : si compte=-500 et montant=-2 31 alors compte + montant > 0! (= )

54 54 Exercice 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; }

55 Exercice 5 : trouver 3 erreurs 55 (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)...

56 Exercice 5 : les 3 erreurs 56 (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)... expression évaluée ne devant pas l'être précédence des opérateurs logiques comparaison factorisée

57 57 Exercice 5 (suite) : corriger les erreurs /* 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)... expression évaluée ne devant pas l'être précédence des opérateurs logiques comparaison factorisée

58 58 Exercice 5 : version corrigé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)... expression évaluée que si nécessaire parenthésage des opérateurs logiques comparaison non factorisée

59 Exercice 6 : trouver 3 erreurs 59 (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; }

60 Exercice 6 : les 3 erreurs 60 (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; } 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

61 61 Exercice 6 (suite) : corriger les erreurs 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; } 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

62 62 Exercice 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

63 Inspection de code : 63 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

64 Inspection de code : 64 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

65 Inspection de code : 65 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

66 Inspection de code : 66 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) {...}

67 Inspection de code : 67 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

68 Inspection de code : 68 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. */

69 Inspection de code : 69 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

70 70 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

71 71 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

72 72 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,......

73 73 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

74 74 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

75 75 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

76 76 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

77 77 Vé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 (< LOC) nécessité de faire des abstractions états avec certaines approches, et même plus

78 78 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

79 79 Outils 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

80 80 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

81 81 Test 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)

82 82 Test Voir cours spécifique sur le test

83 83 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?

84 84 À 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