REPUBLIQUE DU BENIN

**
UNIVERSITE DABOMEY-CALAVI (UAC)

**
INSTITUT DE FORMATION ET DE RECHERCHE EN INFORMATIQUE (IFRI)

**
Licence 3 Gnie Logiciel

SUJET :

Mesure et Evaluation de la
Qualit dUn Logiciel

PRSENT PAR :
ENSEIGNANT :

GBOYOU Lewis M.
Jean-Pierre KOUKPAKI
HOUESSOU Parisius
HOUSSOU Cdric

Anne Acadmique | 2016-2017 |

Introduction
En informatique et en particulier en gnie logiciel, la qualit logicielle
est une apprciation globale dun logiciel, base sur de nombreux
indicateurs. La compltude des fonctionnalits, la prcision des rsultats, la
fiabilit, la tolrance de pannes, la facilit et la flexibilit de son utilisation, la
simplicit, lextensibilit, la compatibilit et bien dautres sont des facteurs
de qualit.
Quelles sont les diffrents outils de mesures de qualit dun logiciel ? Et quel
est le processus dvaluation de la qualit logiciel ?
Nous allons vous apporter un lment de rponse dans la suite de notre
expos.

La Qualit dUn Logiciel

De manire gnrale, un logiciel de qualit sentend comme un logiciel

capable de rpondre parfaitement aux attentes du client, le tout sans dfaut
dexcution. Ainsi, on dtermine la qualit logicielle comme un ensemble de
rgles et de principes suivre au cours du dveloppement dune application
afin de concevoir un logiciel rpondant ces attentes.

PAGE 1
Des Outils Pour Mesurer La
Qualit dUn Logiciel

En Java, un grand nombre d'outils libres sont disponibles.

- Cobertura
- Crap4J
- PMD
- FindBugs
- Eclipse Metrics
- JDepends
Crap4J
Utilise une formule spcifique :

Une mthode doit tre refactoris si elle possde un indice de

crappiness au dessus de 30.
Crap4J autorise les complexits cyclomatiques leves si le code est
bien couvert par les tests.

PAGE 2
PMD
Dtection d'un certain nombre d'anti patterns, connus pour poser
problme.
L'ensemble des rgles que PMD vrifie est disponible l'adresse
suivante :
http://pmd.sourceforge.net/rules/index.html

Vrifie normment de choses

EmptyCatchBlock
DontImportSun
UnnecessaryParentheses
CallSuperInConstructor
FindBugs
Semblable PMD dans le principe : dtection d'anti patterns.
Liste des bugs dtects disponible sur le web :
http://findbugs.sourceforge.net/bugDescriptions.html

PAGE 3
 Exemple d'anti-pattern dtect :
Null pointer dereference
Method does not check for null argument
Read of unwritten field

Eclipse Metrics
Permet de calculer beaucoup de metrics:
Complxit cyclomatique
Nombre de ligne de codes
Indice de spcialisation
Indice d'instabilit
Niveau d'abstraction
Distance from the main sequence

Les Modles de Qualit

Un modle de qualit se compose dun certain nombre de rgles et de

principes, rparties en diffrentes catgories. Appliquer un modle de
qualit consiste mesurer ces rgles. Pour y parvenir, le modle collecte un
certain nombre dinformations issues du projet dont des mtriques de code.

Les Mtriques de Code

Les mtriques primitives. Il sagit des mtriques qui mesurent des

proprits de base du code source telles que le nombre de lignes de
code, la complexit cyclomatique ou encore les metriques de
Chidamber et Kemerer (profondeur dhritage, nombre de

PAGE 4
 sousclasses, etc.) ou les mtriques de Lorenz et Kidd (nombre de
mthodes, nombre de mthodes hrites, etc.).
Les mtriques de design. Elles dterminent si le code source respecte
les principes de conception pralablement dfinies. Il sagit de
mtriques telles que les mtriques de couplage ou de cohsion de
classes, ou encore les mtriques darchitecture de packages comme
les mtriques de couplage affrent et effrent de Martin.

Les principaux modles de qualits hirarchiques

Les modles les plus connus actuellement sont des modles
hirarchiques qui recensent les principes de qualit en partant des exigences
globales et des principes les plus gnraux pour descendre vers les
mtriques qui permettent de les mesurer. Ceci implique que la mesure de la
qualit ne peut dbuter quune fois le modle totalement spcifi et que les
premiers rsultats ne peuvent tre obtenus quune fois la collecte des
donnes suffisante.
ISO 9126. ISO 9126 est une norme standard internationale visant valuer la
qualit logicielle. Elle normalise et classifie un certain nombre de principes
qualit. Ralise par le comit technique JTC 1 de lISO/CEI, cette norme
volue pour tre enrichie et intgre dans la norme SquaRE (Software
product Quality Requirement and Evaluation, exigences et valuation de la
qualit du logiciel). Elle est compose de six caractristiques gnrales qui
dfinissent la qualit globale dune application : la capacit fonctionnelle, la
fiabilit, lefficacit, la maintenabilit, la facilit dusage, la portabilit.
Chacune de ces caractristiques est dcompose en sous caractristiques.
Cette norme semble tre une bonne approche pour dterminer la qualit
dun logiciel dans son ensemble et fournir une vue globale satisfaisante.
Cependant, la norme ne prcise pas de manire explicite comment mesurer
les caractristiques qualits dfinies et comment les relier aux mtriques de
bas niveau. Il ny a aucun continuum entre ces deux niveaux. Ainsi, le modle
reste trop abstrait : bien que constituant une base thorique solide, le fait de
devoir ladapter chaque cas de figure sans avoir de guide prcis pour le
faire augmente dautant sa difficult de mise en uvre.

PAGE 5
SquaRE. La norme SquaRE dfinie depuis 2005 est la norme qui succde au
standard ISO 9126. Elle a t dfinie partir de ISO 9126 et de la partie
valuation de la norme ISO 14598.
Le systme SquaRE dcrit deux modles distincts. Un modle de qualit li
lutilisation du logiciel et un modle de qualit propre la production
logicielle. Nous nous intresserons ici uniquement ce dernier.
Suivant le mme principe que la norme ISO 9126, le modle est constitu de
huit caractristiques, dcomposes en sous caractristiques :

Adquation fonctionnelle : degr partir duquel un produit offre les

fonctions rpondant aux besoins exprims et implicites dans des conditions
dutilisation spcifies.

Performances : performances par rapport aux ressources utilises dans des

conditions dtermines.

Compatibilit : degr partir duquel un produit peut changer des

informations avec dautres produits et/ou remplir ses fonctions, tout en
partageant les mmes environnements matriel et logiciel.

Facilit dutilisation : degr partir duquel un produit peut tre utilis pour
atteindre les buts identifis, avec efficacit, efficience et satisfaction, dans un
contexte spcifi.

Fiabilit : degr partir duquel un produit excute les fonctions spcifies

dans des conditions spcifies pour une priode de temps spcifie.

Scurit : degr partir duquel un produit protge les informations et

donnes de manire ce que les personnes ou autres produits aient un
accs ces derniers qui corresponde leur niveau dautorisation.

PAGE 6
Maintenabilit : degr defficacit et defficience partir duquel un produit
peut tre modifi par les personnes adquates.

Portabilit : degr defficacit et defficience partir duquel un produit peut

tre transfr depuis un environnement matriel ou logiciel vers un autre,
ou dun usage un autre.

Issue de la norme ISO 9126, la norme SquaRE redfinit de manire beaucoup

plus judicieuse les caractristiques qualits dun logiciel. Le fait, par exemple,
davoir distingu la partie scurit comme tant dsormais une
caractristique part entire, ou encore davoir fait une distinction entre la
portabilit et la compatibilit rendent le modle plus pertinent. Cependant,
l encore, ce modle gnraliste est difficile mettre en uvre ; il nexiste
aucun lien explicite entre les caractristiques et les mtriques. De plus, ces
normes dfinissent des modles de qualit gnraux qui visent qualifier un
logiciel dans son ensemble. Pour ce faire, ces modles qualifient la fois des
notions externes adquation fonctionnelle ou encore facilit dutilisation
avec des notions internes de qualification du code source proprement
parl maintenabilit ou compatibilit , ce qui rend lapplication du
modle dans son intgralit souvent beaucoup trop complexe mettre en
uvre.

Le Modle de Mc Call: Facteurs Critres Mtriques (FCM). Mc Call a dfini

un modle appel facteurs-critres-mtriques pour valuer la qualit dun
systme. Il a identifi cinquante facteurs et a slectionn les onze principaux
reprsentant une vision externe globale de la qualit. Ces facteurs sont
caractriss par vingt-trois critres qui reprsentent la vision interne de la
qualit : le point de vue du programmeur. Bien que complet, ce modle est
difficile mettre en uvre du fait des 300 mtriques qui le composent. Il est
toutefois implment dans quelques outils commerciaux mais la
correspondance entre les mtriques et les critres manque de clart. Ce
modle prsente galement une faiblesse importante : le manque de
lisibilit. En effet, lorsquun critre obtient une faible note, il est difficile,
voire impossible de relier cette note directement au problme quelle pointe,

PAGE 7
surtout lorsque le critre est compos de plusieurs mtriques. Dans ce cas il
devient difficile de trouver comment remdier au problme existant.
GQM (Goal-Questions-Metrics). Il sagit dune approche de la qualit
logicielle qui a t promu par Basili. Il dfinit la mesure de la qualit sur trois
niveaux : le niveau conceptuel (the goal level), le niveau oprationnel (the
question level), et le niveau quantitatif (the metric level).
Le niveau conceptuel fixe les objectifs de mesure savoir, ce qui doit
tre mesur, le niveau atteindre en terme de qualit, les objectifs viss par
lentreprise.
Le niveau oprationnel dfinit pour sa part quelles sont les questions
se poser pour dterminer si les objectifs dfinis au niveau prcdent sont
atteints.
Le niveau quantitatif dtermine quelles mtriques doivent tre
utilises pour mesurer le niveau prcdent.
Mme si ce modle est largement diffus dans lindustrie, il pose tout
de mme le problme de ne pas expliciter clairement comment intgrer les
stratgies et les buts spcifiques aux entreprises dans le modle. De plus, ce
modle ne spare pas clairement les diffrents points de vue entre les
managers et les dveloppeurs et ne permet donc pas une lecture claire
systmatique et aise des rsultats obtenus.

QMOOD. Le modle Quality Model for Object-Oriented Design (QMOOD) est

galement un modle hirarchique bas sur la norme ISO 9126. Il est
compos de quatre niveaux : les attributs de la qualit du design, les
proprits du design orient-objet, les mtriques du design orient objet et
les composants du design orient objet. Ces attributs de haut niveau sont
valus en utilisant un ensemble de proprits empiriquement identifis et
pondrs. Ce modle est conu pour des applications orientes objet et ne
peut sappliquer pour dautres paradigmes. Plus encore, il ne qualifie que la
conception des programmes : il ne prend pas en compte la qualit de
limplmentation ou le respect des rgles de programmation par exemple.
Facteur-Stratgie. Marinescu et Ratiu sont partis de la question suivante
Comment pouvons-nous travailler en partant des rsultats ? Leur ide est de

PAGE 8
relier clairement les facteurs de qualit au code source en utilisant une
stratgie de dtection.Ils dfinissent cette stratgie de dtection comme un
mcanisme gnrique permettant danalyser le code source en utilisant des
mtriques. Les mtriques sont soumises des mcanismes de filtrage et de
composition. Ils prsentent un nouveau modle de qualit appel facteur-
Stratgie partir de cette stratgie. Ce modle est pertinent pour mesurer
les concepts orientes objets mais tout comme le modle prcdent il ne
peut sappliquer pour dautres concepts et ne couvre pas lintgralit des
proprits dune application.
SourceInventory. Bakota et Guymthy ont prsent un modle appel
SourceInventory qui collecte des mesures telles que des mtriques et des
informations de couverture de tests. Ce modle fournit une aide pour
interprter les donnes collectes mais demeure toutefois un modle de bas
niveau qui ne fournit pas une vue globale et de haut niveau de la qualit.
The Sqale Quality Model. Le modle de qualit SQALE est un modle
hirarchique qui en suit les principes : trois niveaux allant du plus gnral
les caractristiques au plus dtaill les mesures des points de contrle.
Les caractristiques de Sqale ont t dtermines partir dun modle
gnrique du cycle de vie dun logiciel. Elles sont reprsentes selon un
modle en couche qui implique que chaque caractristique doit tre valide
pour passer la suivante, tout comme chaque tape de dveloppement dun
logiciel doit tre valide pour continuer. Les valuations des caractristiques
sont bases sur des index de remdiation calculant la distance entre le code
analys et lobjectif qualit atteindre. Calcul pour chaque composant du
code, cet index reprsente leffort de remdiation ncessaire pour corriger le
composant mesur. Lindex dun composant se calcule par addition des
index de ses constituants. De mme, lindex dune caractristique se calcule
partir de la somme de ses sous caractristiques.
Ce modle a t cr pour mesurer la qualit du code produit et
lvalue en terme deffort de remdiation uniquement. Il est
particulirement adapt aux dveloppeurs pour lesquels il a t conu. En
revanche, il ne tient pas compte de la qualit fonctionnelle du logiciel.

PAGE 9
Processus dEvaluation de la
Qualit dUn Logiciel

Evaluer la qualit
Les modles pyramidaux attribuent des notes dterminant le niveau de
qualit dun logiciel en se basant sur des mtriques brutes. Par exemple, la
norme ISO 9126 dfinit la sous-caractristique facilit de modification
comme "la capacit dun logiciel intgrer de nouvelles implmentations".
Pour mesurer cette proprit, les mtriques telles que le nombre de lignes
de code (SLOC), la complexit cyclomatique, le nombre de mthodes par
classe, la profondeur dhritage (DIT) sont combines de manire
dterminer partir de toutes ces mesures une seule et unique note pour
cette caractristique.

Les mesures utilises sont dfinies et mesures au niveau des

composants du logiciel : la mtrique SLOC par exemple est calcule pour une
mthode donne ou encore la mtrique DIT calcule pour une classe
donne. De plus, chaque mtrique possde sa propre chelle de valeurs.
Dterminer une note de haut niveau pour mesurer une exigence qualit
demande donc de rsoudre deux problmes :
composer des mtriques entre elles et qui ne sont pas dfinies de
manire similaire (par exemple SLOC et la complexit cyclomatique) ;
agrger les rsultats des mtriques afin de dterminer une note
globale pour une caractristique donne (par exemple pour la
caractristique facilit de modification), tout en conservant
linformation livre par chaque note brute.

Exploiter les mesures

Pour obtenir une note de haut niveau pertinente il faut donc composer et
agrger des mtriques. En thorie, ces deux tapes peuvent tre menes

PAGE 10
dans nimporte quel ordre. En effet, la composition de mtriques peut
seffectuer diffrents niveaux : pour chaque composant partir de chacune
des mtriques obtenues ou au niveau du projet partir de mtriques dj
agrges.

Cependant, il est plus pertinent de composer les mtriques au plus bas

niveau. Prenons lexemple de lexigence qualit taux de commentaires qui
cherche dterminer si le code est suffisamment comment. Calculer une
note uniquement au plus haut niveau ne possde pas de rel intrt. En
effet, pour tre significative, cette exigence qualit doit galement pouvoir
se lire au niveau de chaque mthode : ceci permet de dterminer
directement la mthode qui ne correspond pas aux exigences. De plus, une
mthode dficiente peut se retrouver masque par dautres mthodes sur
commentes lorsque lon exprime le rsultat uniquement au niveau du
projet. Ainsi, calculer les notes au niveau du projet mais galement au
niveau des composants permet de dterminer prcisment les composants
dficients et les amliorations apporter au code pour en augmenter la
qualit.

Ltape de composition des mtriques implique de tenir compte des

intervalles de mesures de celle-ci. Par exemple, calculer le taux de
commentaires dune mthode implique dassocier la mtrique de complexit
cyclomatique avec la mtrique de nombre de ligne de commentaires pour
traduire le fait quune mthode complexe doit tre mieux commente
quune mthode plus simple. Ramener ces mtriques dans un intervalle de
valeurs commun doit galement prendre en considration le fait de garder le
sens des mtriques les unes par rapport aux autres. Pour y parvenir, la
composition des mtriques doit tre labore spcifiquement pour chaque
pratique calcule.
Ltape dagrgation des mesures doit elle aussi tre effectue de
manire ne pas perdre les informations fournies au niveau de chaque
composant. Comment faire ressortir le fait quun lment ne rpond pas aux
exigences de qualit lorsquon se situe au niveau le plus haut ?

PAGE 11
 Utiliser des notes globales pour dfinir la qualit pose galement un
problme crucial pour les dveloppeurs : comment retrouver les
informations livres par les donnes brutes travers une seule note
globale ? Comment traduire cette note en un problme concret de
conception/dveloppement ? Cet cueil empche nombre de dveloppeurs
de sintresser un modle de qualit dans son ensemble et ils lui prfrent
encore souvent les mtriques de code brutes.
Dans le reste de cette section nous dtaillons en quoi les mthodes de
composition et dagrgation utilises le plus couramment ne permettent pas
de rpondre de manire satisfaisante aux exigences. Puis nous regarderons
comment lagrgation de mtriques est aborde aujourdhui dans la
littrature scientifique.

Les piges des calculs classiques

Pour composer des mtriques et obtenir une chelle de valeur commune,
une technique classique consiste transposer de manire discrte les
valeurs dans un intervalle commun. Cependant, les rsultats obtenus ne sont
pas satisfaisants comme expliqu dans la section Normaliser un rsultat.
De mme, la mthode la plus communment employe pour agrger
des mtriques consiste calculer une moyenne, simple ou pondre.
Cependant, mme si utiliser des moyennes semble tre la rponse la plus
vidente pour dterminer une note partir de plusieurs rsultats, ce nest
pas sans problme, comme expliqu dans la Section Agrger des mtriques.

- Normaliser un rsultat
Transposer des valeurs quelconques dans un intervalle donn consiste le
plus souvent appliquer des transformations discrtes sur ce jeu de valeurs.
La Table 1 nous montre

PAGE 12
un exemple dans lequel les valeurs cibles normalises sont toujours 0, 1, 2
ou 3.
Un tel systme prsente lavantage dtre trs simple implmenter et
facile lire mais il nest pas adapt toutes les mesures. Il constitue certes le
meilleur moyen de traduire une expertise humaine telles que celles qui
constituent les mesures manuelles du modle Squale mais ne convient
absolument pas pour traduire des mtriques de code telles que le nombre
de lignes de code ou la complexit cyclomatique.
Transposer des notes continues en intervalle discret pose les
problmes suivants :
Les modifications sont masques. Utiliser des formules discrtes
introduit des paliers et des effets de seuil, ce qui masque certains
dtails et peut fausser linterprtation des rsultats. De plus, lorsque
lon souhaite surveiller lvolution de la qualit dans le temps, ces
valeurs discrtes masquent les fluctuations plus faibles, dans un sens
comme dans un autre.

Par exemple, si lon prend les valeurs de la Table 1, pour un projet donn
contenant des mthodes dune moyenne de 150 lignes de code, chaque
mthode a une valeur normalise de 1. Si les dveloppeurs rcrivent
certaines mthodes pour les porter un nombre de 80 lignes de code, la
qualit du projet aura alors globalement augment ce qui ne sera pas traduit
dans la note globale qui reste inchange du fait des transpositions discrtes
appliques.

Une mauvaise influence sur les dcisions de r-ingnierie. Travailler sur

les composants dont la note est proche dune valeur seuil ncessite
moins de charge de travail et permet daugmenter plus facilement la

PAGE 13
 note globale de la qualit. En revanche, les composants dont la note
est plus loigne dune valeur seuil ncessitent beaucoup plus deffort
pour que le bnfice soit visible dun point de vue note. Pourtant, dun
point de vue purement qualitatif et indpendamment de la note, il est
plus judicieux de se consacrer aux plus mauvais composants pour
augmenter rellement la qualit et corriger les problmes rels.

Agrger des Mtriques

Pour fournir une reprsentation de la qualit un niveau lev, le modle
ISO 9126 sappuie sur des mtriques. Cependant cette description ne donne
aucune indication prcise quant la manire dagrger les diffrentes
mtriques cites. Une moyenne simple ou pondre reste souvent le moyen

le plus utilis pour y parvenir. Et pourtant, les moyennes ne donnent pas

entirement satisfaction puisquelles perdent de linformation comme cela
est soulign par Bieman et dautres.
Moyenne simple. La mthode employe pour calculer une note globale sans
perdre les informations fournies par les notes individuelles des composants
du projet cristallise souvent les points faibles des modles de qualit.
Calculer une simple moyenne nest pas assez prcis puisque cela ne permet
pas de dterminer lcart type dune population comme illustr ensuite.

La Table 2 prsente le nombre de mthodes par classe pour deux

projets. Dans cet exemple, la moyenne du nombre de mthodes est de 12.75
pour le projet 1 et de 12.25 pour le projet 2, ce qui pourrait amener croire

PAGE 14
que le second projet est de meilleure qualit que le premier (puisque la
moyenne est moins leve). Mais cette moyenne masque le fait que le
second projet possde une classe A qui est trs clairement en dehors des
normes. Cest pourquoi, bien que la note moyenne soit meilleure, le dtail
des notes montre que ce second projet est pourtant le moins bon. La
moyenne, parce quelle lisse les rsultats ne reprsente pas toujours la
ralit. Pour donner une note globale qui ait du sens, un modle doit
prendre en compte ses plus mauvais composants et reflter les carts entre
eux. Dans lexemple prcdent, un indicateur de qualit appropri devrait
pointer du doigt le mauvais rsultat de la classe A en fournissant une note
globale plus basse. Mesurer la qualit ne consiste pas uniquement calculer
de simples moyennes mais doit mettre en avant les mauvais composants et
les faiblesses dune application. Pour tre utile, un modle de qualit doit
tre un modle dvaluation mais galement un guide pour augmenter la
qualit. Un dveloppeur doit pouvoir connaitre les composants amliorer
et un manager doit connatre les points faibles du projet. Une simple
moyenne ne pointe pas les mauvais composants et mme pire : elle les
masque.
Pour remdier ce dfaut, on peut dcider dutiliser une moyenne
pondre. Cependant, cette mthode a aussi ses dfauts comme indiqu
ensuite.

Moyenne pondre. Lide principale derrire lutilisation dune moyenne

pondre est de mettre en avant les mauvais composants et de dtecter sil
existe des composants critiques. Intuitivement, il sagit dutiliser lagrgation
de mtriques comme une alarme : donner une mauvaise note globale
lorsquun composant est mauvais. Le poids est appliqu aux notes
individuelles et reprsente linfluence de la note compare

PAGE 15
aux autres. Une premire version du modle Squale mettait ce principe en
application : plus une note tait mauvaise, plus elle avait un poids fort.
Pour illustrer le problme attenant une telle dmarche, considrons
lexemple suivant : la Table 3 dcrit les poids donns pour la mtrique SLOC
dans la premire version de Squale. Il indique que les mauvaises notes
obtenues pour cette mtrique taient pondres avec une valeur de 27 pour
augmenter leur influence lors du calcul de la moyenne. La Table 4 contient
les poids correspondants aux mesures de SLOC. Par exemple, les poids
appliqus pour la mthode C sont diffrents du fait de la note diffrente
obtenue. Ce que cet exemple met en valeur et qui prouve que la mthode
utilise ne convient pas est illustr grce aux mthodes B et C. Alors que la
valeur de la mtrique SLOC diminue et donc que la qualit augmente, les

PAGE 16
poids appliqus aux valeurs produisent un effet totalement inverse sur le
calcul de la note globale : celle-ci diminue ! Dans cet exemple, la moyenne
pondre passe de 222,75 259,53 pour la seconde version. Le rsultat
augmente alors mme que la qualit du code est globalement amliore.
Cet exemple montre que lutilisation dune moyenne pondre nest pas la
mthode adquate et peut mme savrer totalement inapproprie pour un
modle de qualit : la moyenne diminue la note attribue alors mme que la
qualit du code est en augmentation ! Un modle de qualit doit reflter
tous les changements le plus finement possible et avec fiabilit.

Conclusion
Mesurer la qualit dun logiciel est plus complexe quil ny parait. Il
faut tout dabord dfinir clairement ce que sous-entend le mot qualit pour
chaque entreprise, chaque quipe et chaque logiciel mesur. Une fois les
objectifs qualits clairement tablis, encore faut-il savoir comment les
mesurer. Il ne suffit pas simplement de collecter des rsultats de mtriques
mais surtout de donner du sens ces diffrentes mesures.

PAGE 17