Gen Log Assurance Qual It e

Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet
Cours de génie logiciel

(d'après A.-M. Hugues)
Assurance Qualité
Renaud Marlet
LaBRI / INRIA
http://www.labri.fr/~marlet
màj 23/04/2007
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
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
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
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
Qualité : Approche de MacCall
●
Caractéristiques « externes »
– facteurs de qualité
●
Caractéristiques « internes »
– critères de qualité
●
Caractéristiques mesurables
– métriques
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) :

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

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

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é

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

facteurs de qualité et critères de qualité
Opérabilité
Communicabilité Facilité d'emploi
Apprentissage
Volume et taux d'E/S Intégrité
(caractéristiques externes)
(caractéristiques internes)
Contrôle d'accès
Consommation mémoire Efficacité
Traçabilité Conformité
Complétude
Précision
Fiabilité
Cohérence
Maintenabilité
Simplicité
Modularité
Testabilité
Concision
Auto-description Flexibilité
Instrumentation
Généralité Portabilité
Évolutivité
Indépendance machine
Réutilisabilité
Indépendance système
Interopérabilité
14
Liens entre facteurs de qualité et

critères de qualité
Opérabilité
Apprentissage
Contrôle d'accès
Complétude
Précision
Fiabilité
Cohérence
Maintenabilité
Simplicité
Modularité
Testabilité
Concision
Instrumentation
Question Évolutivité
Y a-t-il Indépendance machine
Réutilisabilité
un critère Indépendance système
« majeur » ? Communications banalisés
Interopérabilité
15
Liens entre facteurs de qualité et

Opérabilité
Apprentissage
Contrôle d'accès
Complétude
Précision
Fiabilité
Cohérence
Maintenabilité
Simplicité
☛ Modularité
Testabilité
Concision
Instrumentation
Impact Évolutivité
fort de la Indépendance machine
Réutilisabilité
modularité Indépendance système
Interopérabilité
16
Métriques associées aux

●
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
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
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
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
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
Métrique de McCabe : exemple
C1
C2 X2
nb entrées = 1 X1 X3
nb sorties = 1
nb noeuds (blocs) = 5
nb arcs (branches) = 6
nb cyclomatique = 6 – 5 + 1 + 1 = 3
(nb décisions = 2)
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
Assurance qualité et gestion projet (1)
Le contrôle qualité aide la gestion projet :

– mesure de l'avancement
– meilleure estimation des coûts
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
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
●
●
●
●
●
– test
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
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
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 20-50 lignes/h
(Selon moi :
– effort trop faible dans les phases amont
– effort difficile et peu productif dans les phases aval)
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
●
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
●
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 :
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
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
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
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
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
Et maintenant...
Quelques exercices d'inspection de code...

(et de correction)
39
Exercice 1 : trouver 4 erreurs

(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

●
variable f non
initialisée (à 1)
{
int f;
●
tour de boucle
en trop (n = 0)
while (n >= 0) {
n = n-1;
●
opération sur un
mauvais indice
f = f*n;
(n-1 et non n)
}
return n;
●
retour d'une
mauvaise
}
variable (ici n)
41
Exercice 1 (suite) : corriger les erreurs
●
variable f non
initialisée (à 1)
{
int f;
●
tour de boucle
en trop (n = 0)
while (n >= 0) {
n = n-1;
●
opération sur un
mauvais indice
f = f*n;
(n-1 et non n)
}
return n;
●
retour d'une
mauvaise
}
variable (ici n)
42
Exercice 1 (suite) : version corrigée
int factorielle(int n) ●
variable f
{ initialisée (à 1)
int f = 1; ●
pas de tour de
while (n > 0) { boucle en trop
f = f*n; ●
opération sur un
n = n-1; bon indice (n)
} ●
retour de la
return f; variable
} correcte (f)
43

...
/* Entrée pt cardinal */
printf("Direction : ");
scanf("%c", direction);
switch (direction)
{
case 'N' : y++;
case 'O' : x--;
case 'S' : x++;
}
deplacer(x,y);
...
44

...
●
variable au lieu
printf("Direction : "); de pointeur sur
variable
switch (direction) ●
case manquant
{ ●
break oubliés
case 'N' : y++; ●
copy/paste non
case 'O' : x--;
ou mal adapté
case 'S' : x++;
}
●
default
manquant
deplacer(x,y);
...
45

...
●
variable au lieu
printf("Direction : "); de pointeur sur
variable
switch (direction) ●
case manquant
{ ●
break oubliés
case 'N' : y++; ●
copy/paste non
case 'O' : x--;
ou mal adapté
case 'S' : x++;
}
●
default
manquant
deplacer(x,y);
...
46

...
●
pointeur sur
printf("Direction : "); variable
scanf("%c",&direction); ●
tous les case
switch (direction) { présents et
case 'E' : x++; break; corrects
case 'N' : y++; break; ●
break présents
case 'O' : x--; break; ●
pas d'erreur de
case 'S' : y--; break; copy/paste
default : error();
●
default présent
}
deplacer(x,y);
47

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

int tab[]; /*de taille size*/ ●
oubli d'un
int indiceTqTabNul(int size){ cas d'indice
int i;
if (size > 0)
●
cas d'indice
for(i=1; i <= size; i++) hors borne
if (tab[i] = 0) ●
test par = au
return i; lieu de ==
else
●
dandling else
error(); ●
accolades
return -1; manquantes
}
49
int tab[]; /*de taille size*/ ●

oubli d'un
int indiceTqTabNul(int size){ cas d'indice
int i;
if (size > 0)
●
cas d'indice
for(i=1; i <= size; i++) hors borne
if (tab[i] = 0) ●
test par = au
return i; lieu de ==
else
●
dandling else
error(); ●
accolades
return -1; manquantes
}
50
int tab[]; /*de taille size*/

int indiceTqTabNul(int size){ ●
pas d'indice
int i; oublié
if (size > 0) { ●
pas d'indice
for(i=0; i < size; i++)
hors borne
if (tab[i] == 0)
return i; } ●
test par '=='
else { et non '='
printf("tab est vide"); ●
accolades
error(); }
appropriées
return -1;
}
51
Exercice 4 : trouver une erreur

(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
(Elle est typique)
int compte = ...; ●
overflow non
int decouvert_max = -1000; maîtrisé : compte
void transact(int montant) + montant > 231 →
/* débit: montant < 0 compte + montant
* crédit: montant > 0 */ <0
{ ●
underflow non
if (compte + montant < maîtrisé : si
decouvert_max) compte=-500 et
printf("Refusé"); montant=-231
else alors compte +
compte += montant; montant > 0 !
} (= 231-500)
53
Exercice 4 (suite) : corriger l'erreur
int compte = ...; ●

overflow non
int decouvert_max = -1000; maîtrisé : compte
void transact(int montant) + montant > 231 →
/* débit: montant < 0 compte + montant
* crédit: montant > 0 */ <0
{ ●
underflow non
if (compte + montant < maîtrisé : si
decouvert_max) compte=-500 et
printf("Refusé"); montant=-231
else alors compte +
compte += montant; montant > 0 !
} (= 231-500)
54
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

/* 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

●
expression
if (p != NULL & *p >= 0) ... évaluée ne
devant pas
/* Si x est pair et l'être
* de valeur absolue >= 5 */ ●
précédence
if (x%2 == 0 && des opérateurs
x <= -5 || 5 <= x) ...
logiques
●
comparaison
* ou nuls */ factorisée
if (x && y >= 0) ...
57

●
expression
if (p != NULL & *p >= 0) ... évaluée ne
devant pas
/* Si x est pair et l'être
* de valeur absolue >= 5 */ ●
précédence
if (x%2 == 0 && des opérateurs
x <= -5 || 5 <= x) ...
logiques
●
comparaison
* ou nuls */ factorisée
if (x && y >= 0) ...
58
Exercice 5 : version corrigée

●
expression
if ((p != NULL) && (*p >= 0)) évaluée que si
nécessaire
/* Si x est pair et ●
parenthésage
* de valeur absolue >= 5 */ des opérateurs
if (x%2 == 0 && logiques
(x <= -5 || 5 <= x)) ...
●
comparaison
/* Si x et y sont positifs non factorisée
* ou nuls */
if (x >= 0 && y >= 0) ...
59

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

typedef struct lst { ●
cas d'un argument
int elem;
pointeur nul (liste
struct lst *reste;
vide) non traité
} *list;
●
premier élément
int dernierElem(list l) non traité (liste à un
{ élément)
do { ●
déréférence d'un
l = l->reste; pointeur nul au
} while (l->reste != NULL); terme de l'itération
}
61
typedef struct lst { ●

cas d'un argument
int elem;
pointeur nul (liste
struct lst *reste;
vide) non traité
} *list;
●
premier élément
int dernierElem(list l) non traité (liste à un
{ élément)
do { ●
déréférence d'un
l = l->reste; pointeur nul au
} while (l->reste != NULL); terme de l'itération
}
62
Exercice 6 : version corrigée
typedef struct lst {

int elem; ●
cas d'un argument
struct lst *reste; pointeur nul (liste
} *list; vide) traité
●
premier élément
int dernierElem(list l) traité correctement
{ ●
déréférence du bon
if (l == NULL) error();
pointeur au terme de
while (l->reste != NULL)
l'itération
l = l->reste;
return l->elem;
}
63
Inspection de code :
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
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
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
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
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
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
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
●
●
●
●
●
– test
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
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
●
Outils
– très high-tech
– encore peu répandus
erreur certaine
●
Réussites erreur possible
– bug d'Ariane 5 pas d'erreur
●
Difficultés
– faux positifs (avertissement injustifiés)
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
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
●
●
●
●
●
– test
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 (< 10000 LOC)
– nécessité de faire des abstractions
– 1020 états avec certaines approches, et même plus
78
●
●
●
●
●
– test
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
●
●
●
●
●
– test
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
Test
☛ Voir cours spécifique sur le test

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

Gen Log Assurance Qual It e

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Gen Log Assurance Qual It e

Transféré par

Droits d'auteur :

Formats disponibles

Génie logiciel – Assurance Qualité © 2005-2007 Renaud Marlet

Cours de génie logiciel

Les deux facettes de la qualité

Activité tout au long du cycle de vie

Qualité : Approche de MacCall

Facteurs de qualité classés en 3 catégories :

Facteurs de qualité (1) :

Facteurs de qualité (2) :

Facteurs de qualité (3) : Facilité à

Influence des facteurs de qualité

Ex. facteurs qui diminuent l'efficacité

Ex. facteurs qui diminuent l'intégrité

Exercice : trouver les (>40) liens entre

Liens entre facteurs de qualité et

Liens entre facteurs de qualité et

Métriques associées aux

☛ Ce sont des mesures a posteriori

Exemple : Métrique de McCabe

Métrique de McCabe : exemple

Qualité : comment faire ?

Un grand nombre de métriques

Assurance qualité et gestion projet (1)

Le contrôle qualité aide la gestion projet :

Assurance qualité et gestion projet (2)

Moyens de l'assurance qualité

Moyens de l'assurance qualité

Examen critique de documents (1)

Examen critique de documents (2)

Coût des inspections

Méthodes de relecture (1)

Méthodes de relecture (2)

Méthodes de relecture (3)

(Ce plan figure en partie dans le plan qualité)

Quelques exercices d'inspection de code...

Exercice 1 : trouver 4 erreurs

Exercice 1 : les 4 erreurs

Exercice 1 (suite) : corriger les erreurs

Exercice 1 (suite) : version corrigée

Exercice 2 : trouver 5 erreurs

Exercice 2 : les 5 erreurs

Exercice 2 (suite) : corriger les erreurs

Exercice 2 (suite) : version corrigée

Exercice 3 : trouver 5 erreurs

Exercice 3 : les 5 erreurs

Exercice 3 (suite) : corriger les erreurs

int tab[]; /*de taille size*/ ●

Exercice 3 (suite) : version corrigée

int tab[]; /*de taille size*/

Exercice 4 : trouver une erreur

Exercice 4 (suite) : corriger l'erreur

int compte = ...; ●

Exercice 4 (suite) : version corrigée

void transact(int montant)

Exercice 5 : trouver 3 erreurs

Exercice 5 : les 3 erreurs

Exercice 5 (suite) : corriger les erreurs

/* Si p non nul pointe sur

Exercice 5 : version corrigée

/* Si p non nul pointe sur

Exercice 6 : trouver 3 erreurs

Exercice 6 : les 3 erreurs

Exercice 6 (suite) : corriger les erreurs

typedef struct lst { ●

Exercice 6 : version corrigée

int tab[]; /de taille size/ ●

int tab[]; /de taille size/