Anda di halaman 1dari 31

Chapitre I:

Qualité et
Assurance qualité
I- Introduction :
• L'information est aujourd'hui une ressource stratégique pour
la plupart des entreprises, dans lesquelles de très
nombreuses activités reposent sur l'exploitation
d'applications informatiques. Pour ces entreprises, la
fiabilité de leur système informatique et la qualité des
logiciels utilisés sont donc cruciales.
• Parallèlement, on constate que :
– la part du logiciel est aujourd'hui prépondérante dans le coût
total d'un système informatique,
– la demande d'applications nouvelles, et de plus en plus
complexes, ne cesse de croître,
– les utilisateurs sont de plus en plus exigeants en termes de
fiabilité et de sécurité.
Il est donc nécessaire :
– d'accroître la qualité du produit logiciel, tant dans les
domaines de la satisfaction des utilisateurs, de la fiabilité, des
performances, que dans les domaines contractuels de respect
des délais et des budgets.
– d'accroître la productivité et de réduire les coûts, non
seulement de production du logiciel, mais aussi de l'ensemble
des activités mises en œuvre au cours de son cycle de vie.
II- LA QUALITÉ DU LOGICIEL :
1- Définition :
• La qualité du logiciel est définie par son aptitude à
satisfaire les besoins des utilisateurs.
• Elle est définie par l'ANSI comme "l'ensemble des
attributs et caractéristiques d'un produit ou d'un service
qui portent sur sa capacité à satisfaire des besoins
donnés".
2- Qualité :
• Aptitude d'un produit ou d'un service à satisfaire les
besoins des utilisateurs. (AFNOR - juillet 1982).
• Aptitude, attribut, caractère, propriété, d'un bien ou d'un
service susceptible de faire l'objet d'une évaluation au
regard de certains critères tels que l'usage à l'état normal
durant la vie du produit, sa disponibilité, son prix d'achat,
etc.
A- La mise en place des procédures qualité :
• L’organisation du processus: découper le processus pour
le maîtriser (QUOI ?)
• Les ressources humaines: les équipes doivent être
motivées pour mettre en place des procédures de qualité
(QUI ?)
• L’utilisation de techniques, méthodes, outils reconnus
(COMMENT?)
• Considérations managériales, politiques et économiques:
évaluer le retour sur investissement par une analyse
coûts-bénéfices (POURQUOI ?).
B- Organiser le processus
• Découpage en activités
– Séquentielles (verticales): Spécification, conception, . . .
– Parallèles (horizontales): Gestion de projet, gestion des configurations, . .
.
• Le projet doit être découpé en éléments maîtrisables
– Efficacité
– Correction
– Motivation

• Pour chaque activité, il faut définir


– Qui fait
– Qui approuve
– Qui vérifie
– Qui valide
C- Maîtrise de la qualité :
• La maîtrise de la qualité passe par :
– une planification systématique de ce qui doit arriver.
– la mesure des écarts entre ce plan et la réalité (Tests).
– la correction de la trajectoire.
• Pour chaque projet, il faut donc :
– Prévoir ce que l’on doit faire.
– Écrire ce que l’on a prévu.
– Faire ce qu’on a écrit.
– Vérifier que le système qualité est adéquat et que tout se déroule
comme prévu.
– Corriger les écarts.
– Conserver une trace de tout ce qu’on fait (Documentation).
3- L’assurance qualité :
• C’est l’ensemble des mesures, procédures,
méthodes utilisées dans le cadre du processus de
développement du logiciel afin d’obtenir le niveau
de qualité souhaitée.
• La mise en œuvre d’une politique d’assurance
qualité passe par la rédaction d’un Manuel Qualité
présentant toutes les procédures qui pourront
(devront) être utilisées dans le cadre de l’activité
informa
• Ce Manuel Qualité est ensuite validé par une
organisme indépendant de l’entreprise qui délivre à
l’entreprise une certification. Il existe plusieurs
niveaux de certification .
5- Niveaux de certification :
– ISO9001 (de la conception à l’après-vente)
– ISO 9002 (achats et production)
– ISO 9003 (contrôles)
• Le Manuel qualité est très général, c’est pour cela que
l’on rédige un Plan Qualité Logiciel (PQL) au moment du
lancement d’un nouveau projet, qui précise les différents
intervenants sur le projet (noms, rôles), et les procédures
à appliquer dans le cadre de ce projet particulier.
EXEMPLE DE SOMMAIRE DE PQL :
– But du projet
– Organisation du projet (Décrit la structure du projet, fixe les responsabilités de
management etc.)
– Documents (Décrit les documents qui seront produits au cours de ce projet)
– Standard (Méthodes à utiliser, normes, procédures à suivre)
– Qualité (Définitions des moyens qui seront mis en place pour mesurer la
qualité du logiciel.
– Suivi des problèmes (Méthodes pour suivre les problèmes, les demandes
d’actions correctives).
– Etc.
III- Type de qualités logiciel :
• La norme iso 9000 définit la qualité comme
"L'aptitude d'un ensemble de caractéristiques
intrinsèques à satisfaire des exigences"… Dans
la pratique, la qualité se décline sous deux
formes :
– La qualité externe : c'est lorsqu'un produit ou
service répond parfaitement aux besoins et attentes
des clients. Au quotidien, de nombreuses entreprises
perdent des parts de marchés, car elles ne
parviennent pas répondre efficacement aux
exigences clients.
– La qualité interne : C'est la maîtrise et
1- La qualité externe : qualité perçue et
workflow
• La qualité externe se rapporte à la valeur perçue
par l'utilisateur mais aussi à la fluidité de
l'enchaînement des processus lors de l'utilisation
de la solution.
• La qualité perçue correspond à des critères de
fiabilité et de stabilité du logiciel alors que
l'enchaînement des processus se rapporte à la
façon dont la solution résout un problème lié aux
tâches quotidiennes de l'utilisateur, compte tenu
des spécificités de son secteur d'activités. Les
interfaces ont, pour ce dernier point, un rôle
2- Qualité interne : qualité de la conception et
aptitude à évoluer:
• La qualité interne se focalise sur la capacité de l'entreprise à
apporter des modifications à une solution existante.
– Ce peut être l'élimination de défauts constatés (bugs) mais aussi
l'ajout de nouvelles fonctionnalités.
• Ce niveau de qualité est directement lié à la phase de conception
du logiciel et au choix du langage de programmation, compte
tenu de la taille du logiciel et de son environnement sectoriel.
• Une qualité interne dégradée ne permet pas aux développeurs
d'estimer précisément le temps nécessaire à l'ajout de nouvelles
fonctionnalités, ni d'éviter que ces ajouts ne génèrent des bugs
additionnels, eux-mêmes sources de coûts supplémentaires.
• Si la qualité externe est essentielle à l'adoption du produit par le
client, la qualité interne permet à l'entreprise de respecter ses
budgets et, par là même, se garder sa position dans un marché
donné.
• C'est un aspect des choses trop souvent négligé.
IV- L'ÉVALUATION DE LA QUALITÉ DU
LOGICIEL
1- La métrologie du logiciel
• La métrologie du logiciel est un ensemble de
méthodes qui permettent d'évaluer la qualité du
logiciel.
• Elle a pour objet :
– De définir un ensemble de caractéristiques mesurables du
logiciel,
– De définir des méthodes d'évaluation,
– De définir des outils d'évaluation (analyseurs, jeux de tests),
– Enfin, d'évaluer les logiciels par la mise en oeuvre de ces
méthodes et l'utilisation de ces outils.
2- Le modèle d’évaluation
• Ce modèle définit la qualité du logiciel à travers
la qualité du produit, du processus et du service
rendu. On peut représenter ce modèle sous la
forme d’une arborescence.
3- Notions Principales :
• Une métrique est la mesure d'une propriété d'un critère. (par
exemple, la taille d’un module pour le critère "Simplicité").
• Un facteur est une caractéristique du logiciel, du processus
ou du service contribuant à sa qualité telle qu'elle est
ressentie par l'utilisateur.
• Un critère est un attribut du logiciel par l'intermédiaire
duquel un facteur peut être obtenu. C'est également une
caractéristique du logiciel sur laquelle le développeur peut
agir. (par exemple, sa simplicité)
A- Métrique :
• Une métrique logicielle est une mesure d'une
propriété d'une partie d'un logiciel ou de ses
spécifications.
• Il n'existe pas de métrique "ultime" : la
pertinence de chaque métrique dépend de la
qualité de l'interprétation qui en est faite et du
projet.
• Certaines métriques sont couramment utilisées
dans les développements logicielles, pour
estimer une charge de travail ou comme
indicateur de la taille d'un projet par exemple.
- Les métriques de code :
• Il existe un nombre considérable de métriques et certaines d’entre elles
ne sont pas calculées de la même manière selon l’outil utilisé. C’est
pourquoi il convient de déterminer quelles métriques seront utiles et
comment elles doivent précisément être calculées On peut classer les
métriques en deux grandes catégories :
– Les métriques primitives : Il s’agit des métriques qui mesurent des propriétés de
base du code source telles que le nombre de lignes de code, la complexité
cyclomatique ou encore les métriques de Chidamber et (profondeur d’héritage,
nombre de sous classes, etc.) ou les métriques de Lorenz et Kidd (nombre de
méthodes, nombre de méthodes héritées, etc.).
– Les métriques de design : Elles déterminent si le code source respecte les
principes de conception préalablement définies. Il s’agit de métriques telles que
les métriques de couplage ou de cohésion de classes, ou encore les métriques
d’architecture de packages comme les métriques de couplage.
• A chaque critère on doit associer une métrique afin de pouvoir mesurer
l’atteinte du critère. Chaque exigence qualité traduite en critère doit
être contrôlé par la maîtrise d’ouvrage (équivalent à la recette
fonctionnelle).
- Exemple d'indicateurs :
– Nombre total de lignes de codes SLOC.
– Nombre de lignes de codes par objet.
– Nombre de méthodes par objet.
– Nombre total de méthodes.
– Ratio lignes de codes/nombre de méthodes.
– Ratio lignes de codes/nombre d'objets.
– Ratio lignes de commentaires/lignes de codes.
- Comment mesurer ces métriques :
• Il est bien évidemment impossible d'effectuer ses mesures
manuellement, en particulier si l'on souhaite surveiller leur évolution.
Quelque que soit le langage objet utilisé pour le projet, il existe une
offre logicielle commerciale fournie, et souvent haut de gamme, qui
permet de calculer ces métriques (et bien d'autres) et de générer des
tableaux de bords très complets.
• Dans le cas des projets Java, la communauté OpenSource a développé
des outils simples d'utilisation et d'une grande efficacité à destination
des développeurs. ( par exemple: se présentent sous la forme de plug-
in pour Eclipse).
• On retiendra en particulier :
– Metrics fournit plus de 20 mesures de la qualité du code. Des plus
simples, tel le nombre de lignes de code, aux plus sophistiquées comme
l'index de spécialisation de classe. Le plug-in Eclipse permet de
paramétrer des seuils d'alerte sur le respect de valeurs minimales et
maximales des métriques.
– JDepend et son plug-in eclipse JDepend4Eclipse sont spécialisés, comme
leur nom l'indique, dans l'analyse des dépendances et des couplages entre
les paquetages.
Exemple 1: complexité cyclomatique de McCabe.
Définition
• La complexité cyclomatique d'une méthode est définie
par le nombre de chemins linéairement indépendants qu'il
est possible d'emprunter dans cette méthode.
• Plus simplement, il s'agit du nombre de points de décision
de la méthode (if, case, while, ...) + 1 (le chemin
principal).
• La complexité cyclomatique d'une méthode vaut au
minimum 1, puisqu'il y a toujours au moins un chemin.
Interprétation
• La complexité cyclomatique d'une méthode augmente
proportionnellement au nombre de points de décision.
Une méthode avec une haute complexité cyclomatique est
plus difficile à comprendre et à maintenir.
• Une complexité cyclomatique trop élevée (supérieure à
30) indique qu'il faut refactoriser la méthode.
• Une complexité cyclomatique inférieure à 30 peut être
Calcul :
Si on compte le nombre de chemins linéairement indépendant qu'il
est possible de suivre, on trouve 6. C'est également le nombre de if de
la méthode + 1. La complexité cyclomatique de cette méthode vaut
donc 6.
B- FACTEURS DE QUALITÉ D'UN
LOGICIEL :
• Au vu de son utilisateur, un logiciel de qualité doit donc
présenter ces caractéristiques sans que son efficacité, ses
performances (temps de réponse, place mémoire minimum,
...) en pâtissent.
• Les principaux facteurs de qualité d'un logiciel sont :
– Disponibilité
– Ergonomie
– Fiabilité
– Flexibilité
– Intégrité
– Maintenabilité
- Disponibilité
• Aptitude du logiciel à assurer sa fonction pendant une période de temps donnée.
- Ergonomie
• Etude scientifique de l'homme au travail sous les aspects physiologiques, anatomiques,
psychologiques et sociaux. D'une manière générale, l'ergonomie vise l'adaptation des
machines et du travail à l'homme en permettant la conception d'outils qui puissent être
utilisés avec le maximum de confort, d'efficacité et de sécurité. On considère que la
convivialité, la facilité d'apprentissage pour l'utilisateur font partie de l'ergonomie.
- Fiabilité
• Aptitude du logiciel à accomplir sans défaillance l'ensemble des fonctions spécifiées, à
fonctionner dans des conditions anormales sans mettre en cause ni les informations du
système, ni leur cohérence.
- Flexibilité
• Caractère d'un logiciel qui définit la facilité avec laquelle des fonctions peuvent être
ajoutées, supprimées ou modifiées dans un programme opérationnel.
- Intégrité
• Faculté d'un logiciel à être protégé contre des altérations ou contre l'accès par des
utilisateurs non autorisés. Cf. Sécurité
- maintenabilité
• Caractère d'un logiciel qui définit la facilité avec laquelle un défaut peut être localisé,
identifié et corrigé.
C- CRITÈRES DE QUALITÉ D'UN LOGICIEL :
- Cohérence
• Etat du logiciel tel que les conventions préétablies ont été respectées.
- Complétude
• Etat du logiciel tel que toutes les exigences spécifiées sont réalisées.
- Compréhensibilité
• Facilité avec laquelle un programme peut être compris par la lecture de son code
source.
- Contrôle des accès
• Existence de dispositifs qui permettent une protection contre les accès non autorisés.
- Modularité
• Aptitude d'un logiciel à être structuré en composants ou modules indépendants.
Evaluer la modularité revient à juger de la pertinence de la fonction de chaque module
et de ses interactions avec les autres modules.
- Protection des accès
• Existence de dispositifs destinés à protéger le code et les données contre toutes
dégradations.
- Simplicité
• Caractéristique d'un logiciel qui exprime la manière (avec simplicité ou complexité)
dont sont implémentées ses différentes fonctions et qui représente la difficulté que peut
rencontrer un individu pour analyser et comprendre un programme.
Exercice :
• Une SI doit fournir à un client un logiciel de gestion
commerciale spécifique. Pour juger de la qualité de
ce logiciel on a retenu les facteurs ou critères
suivants :
– Élaboration de jeux et scénarios de tests, efficacité, prototypage, prix,
respect des délais conception-réalisation, respect du budget conception-
réalisation, formation des utilisateurs, qualité de la documentation, délai
d'intervention (maintenance), utilisation d'un AGL, efficacité d'une
intervention (maintenance), organisation et gestion des ressources en
matériel et personnel, utilisation de méthodes de conception et de
développement des systèmes d'information, conformité des procédures au
plan d'assurance qualité,
• Classer les critères de qualité du logiciel en :
– Caractéristiques de qualité du produit en développement (qualité telle
qu'elle peut être perçue par le client),
– Caractéristiques de qualité du processus de production du logiciel
(facteurs et critères de qualité internes à la SI),
Chapitre ii :
Les Tests
I- Définitions:
• «Le test est l'exécution ou l'évaluation d'un
système ou d'un composant par des moyens
automatiques ou manuels, pour vérifier qu'il
répond à ses spécifications ou identifier les
différences entre les résultats attendus et les
résultats obtenus »
IEEE (Standard Glossary of Software Engineering Terminology)

• «Tester, c'est exécuter le programme dans


l'intention d'y trouver des anomalies ou des
défauts »
G. Myers (The Art of Software testing)

• Le test est une méthode dynamique visant à


trouver des bugs
II- utilité des tests :
• Le test ne peut pas prouver au sens formel la
validité d’un programme
Testing can only reveal the presence of errors
but never their absence.
E. W. Dijkstra (Notes on Structured Programming, 1972)

• Par contre, le test peut “augmenter notre


confiance” dans le bon fonctionnement d’un
programme correspond au niveau de validation
des systèmes non informatiques
• Un bon jeu de tests doit donc :
– exercer un maximum de “comportements différents” du
programme (notion de critéres de test)
III- Vérification & Validation
• Deux aspects de la notion de qualité :
– Conformité avec la définition : VALIDATION
• Réponse à la question : faisons-nous le bon produit ?
• Contrôle en cours de réalisation, le plus souvent avec le client
• Défauts par rapport aux besoins que le produit doit satisfaire
– „Correction d’une phase ou de l’ensemble : VERIFICATION
• Réponse à la question : faisons-nous le produit correctement ?
• Tests
• Erreurs par rapport aux définitions précises établies lors des
phases antérieures de développement.
IV- Erreur, défaut et anomalie :
• Une anomalie(ou défaillance) est un
comportement observé différent du
comportement attendu ou spécifié.
• Chaîne de causalité :
Erreur => défaut => anomalie
• Le terme bug est malheureusement utilisé pour
désigner aussi bien défaut qu’une anomalie.
Défaut ≠ anomalie
• Comme le test est en aval de l’activité de
programmation, les erreurs (humaines) déjà
commises. Nous porterons notre attention sur les