Métriques de qualité logicielle

LES MÉTRIQUES DE QUALITÉ LOGICIELLE
Youness BOUKOUCHI
ENSA d’Agadir
3ème année Génie Logiciel
y.boukouchi@gmail.com
PROF Y.BOUKOUCHI - ENSA D'AGADIR
Version 1.0 - 2017

QUALITÉ LOGICIELLE Définitions,

 Perte de la sonde ‘Mars Climate Orbiter’ en 1999 après 9 mois de voyage
 confusion dans le paramétrage entre pieds et mètres
 Le 22 décembre 2001, plus de 750 000 terminaux de paiement ne répondaient plus
 les serveurs de la société ATOS étaient saturés, les demandes d’autorisation mettaient 1/2 heure au
lieu de 10 secondes
 dans les grandes surfaces la plupart des clients ont abandonné leurs chariots pleins, les pertes
chiffrées ce jour là, se sont élevées à plus de 2 millions d’Euros, uniquement pour le groupe Leclerc
Jeudi 28 septembre 2017, une panne informatique d'Amadeus(un système de
réservations aériennes et d'enregistrement des passagers) utilisé par plus de 125
compagnies aériennes.
des perturbations dans plusieurs aéroports, de longues files d'attente se sont formées dans certains
aéroports.
LA NON-QUALITÉLA QUALITÉ LOGICIELLE >

La Qualité logicielle est
Selon l'IEEE : Le degré avec lequel un système, un composant ou un processus satisfait
aux besoins ou attentes de ses clients/usagers.
Selon AFNOR : C’est l’aptitude d’un produit ou d’un service à satisfaire les besoins
des utilisateurs
Selon ISO 9000: C’est l’ensemble des caractéristiques intrinsèques qui lui confère
l’aptitude à satisfaire les besoins et attentes exprimés ou implicites des clients et
autres parties intéressées.
DÉFINITIONSLA QUALITÉ LOGICIELLE >

La métrologie (science de la mesure) du logiciel est un ensemble de méthodes
et savoir-faire qui permettent d’effectuer des mesures et d’avoir une confiance
suffisante dans leurs résultats pour évaluer la qualité du logiciel.
Une mesure est une grandeur numérique, ou quantité, généralement exprimée
sous la forme d’un multiple d’une unité.
Les mesures peuvent remplir les différents rôles suivants :
• Rôle évaluatif, consistant à décrire l’objet de la mesure.
• Rôle vérificatif, consistant à vérifier que l’objet de la mesure est conforme à
ce qui est attendu.
• Rôle prédictif, consistant à prédire à partir du mesurage l’évolution future de
l’objet
LA MÉTROLOGIE DU LOGICIELLA QUALITÉ LOGICIELLE >

La qualité logicielle est la condition primordiale pour l’acceptation des logiciels au
cours de cycle de développement.
Tout projet doit avoir des métriques qui permettent de mesurer le degré de qualité
atteint au cours de développement des logiciels.
Une métrique est un moyen permettant de quantifier une propriété dans le monde
du logiciel, elles peuvent être explicites ou implicites, simples ou complexes (qui se
composent d’autres métriques).
les métriques sont classées en trois types:
Métriques du processus logiciel : orientées processus de développement (le coût, temps, etc.)
Métriques du produit logiciel : orientées produit logiciel (le code, la complexité, etc.)
Métriques du projet : orientées projet (nombre de développeurs, l’effort, etc.)
LES MÉTRIQUES DE QUALITÉLA QUALITÉ LOGICIELLE >

LES MODÈLES DE QUALITÉ LOGICIELLE

Dans le domaine informatique,
l’objectif d’un modèle de la qualité logicielle est d’établir une relation entre
les aspects mesurable d’un système et sa qualité.
le modèle est une fonction « f » de la forme: qualité ≈ f (attributs).
où la qualité est une valeur et les attributs sont les métriques décrivant le système.
la fonction dépend du type de relation qui relie la structure d'un système à
sa qualité.
Les modèles de qualité définissent la qualité à travers :
la qualité du produit,
la qualité du processus,
la qualité du service,
La qualité des ressources.
UN MODÈLE DE QUALITÉLES MODÈLES DE QUALITÉ LOGICIELLE>

Un modèle de qualité est basé sur un ensemble de
facteurs de qualité, où chaque facteur est décomposé
d’un ou plusieurs critères, dont chacun y a un ensemble
de métriques associées.
Un facteur est une caractéristique du logiciel, du
processus ou du service contribuant à sa qualité telle
qu'elle est ressentie par l'utilisateur (vision EXTERNE ).
Ils concernent les caractéristiques d’utilisation liées à
l’environnement d’exploitation, de suivi et de
maintenance.
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 (vision INTERNE ).
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é").
Qualité
Facteur 1
Critère A
Métriques
Critère B
Métriques
Facteur 2
Critère C
Métriques
Facteur N
Critère D
Métriques

Le modèle de Mc Call (1977)
détermine une approche de la qualité
à partir de la définition de
caractéristiques externes (facteurs de
qualité) et internes (critères de
qualité) qui soient mesurables (par
des métriques).
Il a défini 23 critères répartis sur 11
facteurs, chaque critère correspond à
au moins une métrique
 OPERATIONNEL : Conformité aux besoins ,
Fiabilité, Efficacité, Intégrité , Facilité d’emploi
 L'EVOLUTION : Maintenabilité, Souplesse,
Testabilité
 L'ADAPTABILITE: Portabilité, Réutilisabilité,
interopérabilité
UN MODÈLE QUALITÉLES MODÈLES DE QUALITÉ LOGICIELLE>
Le modèle Mc Call

 L’ISO a défini dans sa norme 9126 un modèle composé de six caractéristiques
générales (27 sous-caractéristiques) qui définissent la qualité globale d’une
application : la capacité fonctionnelle, la fiabilité, la facilité d’usage, l’efficacité, la
maintenabilité, la portabilité. Chacune de ces caractéristiques est décomposée en sous
caractéristiques.
Le modèle ISO9126:2001

Le modèle ISO/CEI 25010:2011 ou bien SQuaRE (Software QUAlity Requirements and
Evaluation), est une évolution de la norme ISO9126.
Le modèle SQuaRE propose 8 caractéristiques de qualité du produit logiciel: Capacité
fonctionnelle, Performances, Compatibilité, Utilisabilité, Fiabilité, Sécurité, Maintenabilité,
Transférabilité.
Le modèle SQuaRE

GQM (Goal, Question, Metric) est une
approche de la mesure des systèmes
logiciels qui a été promue par Victor
Basili,
GQM définit un modèle de mesure à trois
niveaux :
 Niveau conceptuel (Goal).
 Niveau opérationnel (Question).
 Niveau quantitatif (Metric).
Le modèle GQM

Processus d'évaluation (ISO9126) est composé de trois étapes
1. Définir les exigences en établissant un modèle de qualité (facteurs et critères). Ces exigences
peuvent varier d'un composant du produit à un autre.
2. Fixer les métriques de la qualité pour la préparation de l'évaluation
1. Sélection des métriques de qualité.
2. Définition des taux de satisfaction : Les échelles de valeurs doivent être divisées en portions
correspondant aux niveaux de satisfaction des exigences
3. Définition des références et des critères d'appréciation.
3. Procéder à l'évaluation:
 La mesure: Les métriques sélectionnées sont appliquées au produit, donnant ainsi des valeurs.
 La notation: Pour chaque valeur mesurée, une note (de satisfaction) est attribuée.
 L’appréciation: En utilisant les critères d'appréciation, un résultat global de l'évaluation du produit
est obtenu.
EVALUATION D’UN MODÈLE DE QUALITÉLES MODÈLES DE QUALITÉ LOGICIELLE>
« Ce qui n'est pas mesurable rendez le mesurable » Galilée 1564-1642

Les modèles de qualité attribuent des notes déterminant le niveau de qualité d’un logiciel
en se basant sur des métriques brutes.
Ceci demande de résoudre deux contraintes:
 composer des métriques entre elles et qui ne sont pas définies de manière similaire.
 agréger les résultats des métriques afin de déterminer une note globale pour une
caractéristique donnée.
Exemple: la norme ISO 9126 définit la sous-caractéristique : « facilité de modification »
comme la capacité d’un logiciel à intégrer de nouvelles implémentations".
Facilité de
modification
nombre de
lignes de code
(LOC)
la complexité
cyclomatique
le nombre de
méthodes par
classe
la profondeur
d’héritage
(DIT)PROF Y.BOUKOUCHI - ENSA D'AGADIR

En 1946, Stanley Smith Stevens a présenté une théorie des types de mesure employés jusqu’à
présent par des statisticiens:
1. Type Nominal : il correspond à des noms dont l’ordre n’a pas d’importance dans leur
présentation, par exemple : le sexe (féminin ou masculin), la profession (Etudiant, Enseignant,
etc.), etc.
2. Type Ordinal : il permet de rajouter la notion d’ordre au type nominal. Par exemple, le niveau
scolaire (Bac, Bac+2, Bac+3, Bac+5), le degré de satisfaction (très satisfait, satisfait,
insatisfait, très insatisfait), etc.
3. Type Intervalle : il permet de mesurer une propriété quantitative dont le zéro est fixé
arbitrairement, un zéro arbitraire est un zéro qui ne correspond pas à une absence comme par
exemple la température (-10°, 0, +10°), le temps (100 av. J.-C, 2015), etc.
4. Type Ratio (ou Rapport) : il permet aussi de mesurer une propriété quantitative mais cette
fois-ci dont le zéro correspond à une absence de la propriété, par exemple : l’âge, le salaire,
la taille, la vitesse (0km/h, 80km/h), etc.
5. Type Absolu : C’est un cas particulier de type rapport, ce type consiste généralement à
compter (1, 2, 3,…), par exemple : le nombre d’erreurs trouvées, le nombre de machine, etc.

Transformations:
– Soit x une entité et M(x) une mesure sur x
– Chaque type d’échelle autorise un certain type de transformations t sur M : t(M(x))
Exemple:
1. Échelle nominale :Uniquement les transformations un vers un
 Exemple – Java → 1, C++ → 2, C# → 3
2. Échelle ordinale : Toute transformation qui préserve l’ordre
 Exemple : transformation de labels dans une échelle de Likert (1 → très satisfait,
etc.)
3. Échelle intervalle : Toute transformation de la forme t(M(x)) = a × M(x) + b, a>0
 Exemple : conversion Celsius Fahrenheit F = 9/5 C + 32
4. Échelle ratio : Toute transformation de la forme t(M(x)) = a × M(x), a>0
 Exemple : Conversion de monnaie CAD = 0.6 EUR
5. – Échelle absolue : Uniquement la transformation « identité » t(M(x)) = M(x)
 Exemple : les nombre : 0, 1, 2 etc.

Exemples :
mesure Interprétation
1-10 Programme simple, sans véritable risque
11-20 Programme modérément complexe et risqué
21-50 Programme complexe et hautement risqué
> 50 Programme non testable et extrêmement risqué
Note
3
2
1
0
CC = E – N + p

Considérons les valeurs lues des métriques suivantes au cours de la phase de
développement du logiciel X :
 Commentaires: 10/100=10%
 Nom des variables: Incompréhensibles
 Nombre de si imbriqués: 3
 Nombre de lignes par module: >50 et < 100
Les valeurs des métriques sont obtenues de la façon suivante :
Métrique Valeurs mesurées Tranche Valeur de
la métrique
2 1 0
Commentaires 10/100=10% [100,20] ]20,10] ]10,0] 1
Nom des variables Incompréhensibles Significatifs Moyens Incompréhensibles 0
Nombre de si imbriqués 3 [0,3] ]3,5] ]5,…] 2
Nombre de lignes par module entre 50 et 100 [0,50] ]50,100[ ]100,…] 1
ETUDE DE CASLES MODÈLES DE QUALITÉ LOGICIELLE>

La composition et l’agrégation des critères-métriques :
Nom du critère Code métrique coefficient
Auto-documentation Commentaires 0,5
Auto-documentation Nom des variables 0,5
Simplicité Commentaires 0,4
Simplicité Nb de SI imbriqués 0,4
Simplicité Nb de lignes d’un module 0,2
La composition et l’agrégation des facteurs-critères :
Nom du facteur Nom du critère coefficient
Maintenabilité Simplicité 0,7
Maintenabilité Auto-documentation 0,3
Fiabilité Simplicité 1

Questions
Représenter l’arborescence de cette méthode d’évaluation.
Calculer la valeur de chaque critère
Calculer la valeur de chaque facteur
Calculer la valeur de la qualité mesurée du logiciel X
Calculer la valeur de la qualité totale du logiciel X

Qualitéduproduit
Maintenabilité
Simplicité
Commentaires
Nb de SI imbriqués
Nb de lignes d’un module
Auto-documentation
Commentaires
Nom des variables
Fiabilité Simplicité
Commentaires
Nb de SI imbriqués
Nb de lignes d’un module

Les critères:
 Valeur Auto-documentation = (1 * 0,5) + (0 * 0,5) = 0,5
 Valeur Simplicité = (1 * 0,4) + (2 * 0,4) + (1 * 0,2) = 1,4
Les facteurs:
 Valeur Maintenabilité = (0,5 * 0,7) + (1,4 * 0,3) = 0,77
 Valeur Fiabilité = (1,4 * 1) = 1,4
La qualité mesurée:
 Pour l'évaluation de la qualité du logiciel X les facteurs Maintenabilité et Fiabilité ont le même
poids. La valeur de la qualité du logiciel est :
 Qualité mesurée= (0,77 * 0,5) + (1,4 * 0,5) = 1,09
La qualité totale:
 Valeur Auto-documentation = (2 * 0,5) + (2 * 0,5) = 2
 Valeur Simplicité = (2 * 0,4) + (2 * 0,4) + (2 * 0,2) = 2
 Valeur Maintenabilité = (2 * 0,7) + (2 * 0,3) = 2
 Valeur Fiabilité = (2 * 1) = 2
 Qualité totale = (2 * 0,5) + (2 * 0,5) = 2
Qualité évaluée
54,5%PROF Y.BOUKOUCHI - ENSA D'AGADIR

LA NORME ISO9126

La norme Iso 9126 distingue 3 catégories de qualité :
la qualité interne qui qualifie la qualité du logiciel à partir de mesures statiques du
code.
la qualité externe qui repose sur les mesures externes. Il s’agit des mesures effectuées
lors de simulation d’exécution du logiciel, lors des phases de tests par exemple.
la qualité à l’utilisation qui est mesurée lors de l’utilisation du logiciel. Il s’agit de la
qualité ressentie par l’utilisateur dans des conditions spécifiques et dans un
environnement spécifique.
software product
effect of software
product
quality in use
metrics
quality in
use
internal
quality
internal metrics external metrics
external
quality
contexts of
usedepends on
influences influences
depends on
PRÉSENTATIONLA NORME ISO9126>

Les métriques internes peuvent être appliquées à un produit logiciel non exécutable pendant les
étapes de développement (telles que la définition des exigences, la spécification de conception ou le
code source). Les métriques internes permettent aux utilisateurs de mesurer la qualité des livrables
intermédiaires et de prédire ainsi la qualité du produit final. Cela permet à l'utilisateur d'identifier
les problèmes de qualité et d'initier des actions correctives le plus tôt possible dans le cycle de vie du
développement.
Les métriques externes peuvent être utilisées pour mesurer la qualité du produit logiciel en mesurant
le comportement du système dont il fait partie. Les métriques externes ne peuvent être utilisées que
pendant les phases de test et pendant toutes les étapes opérationnelles. La mesure est effectuée lors
de l'exécution du produit logiciel dans l'environnement système dans lequel il est destiné à
fonctionner.
Les métriques de qualité en utilisation mesurent si un produit répond aux besoins spécifiques
d'utilisateurs avec efficacité, productivité, sécurité et satisfaction dans un contexte d'utilisation bien
spécifié. Cela ne peut être réalisé que dans un environnement système réaliste.

Modèle de
qualité
caractéristiques
Sous-
caractéristiques
Mesure et
métriques
Qualité externe
Efficacité
Time behaviour
Métrique : Temps de réponse
Objectif : Quel est le temps nécessaire pour effectuer une tâche spécifique?
Formule: T = (temps d'obtention du résultat) - (heure d'entrée de la commande terminée)
Interprétation: 0 <T : Le plus tôt est le mieux.
Méthode: Démarrer une tâche spécifiée. Mesurez le temps nécessaire à l'échantillon pour
terminer son opération. Gardez un enregistrement de chaque tentative.

FACTEURS & CRITÈRESLA NORME ISO9126>
La norme ISO9126 propose :
• 6 caractéristiques,
• 27 sous-caractéristiques
• Plus de 100 métriques

Capacité fonctionnelle (Functionality) : est-ce que le logiciel répond aux
besoins fonctionnels exprimés ? La capacité du produit logiciel à fournir des fonctions
qui répondent aux besoins exprimés et implicites lorsque le logiciel est utilisé dans
des conditions spécifiées.
Pertinence(Suitability) : La capacité du produit logiciel à fournir un ensemble approprié de fonctions
pour des tâches et des objectifs utilisateur spécifiques.
Exactitude(Accuracy) : La capacité du logiciel à fournir les bons résultats ou les résultats convenus
avec le degré de précision requis.
Interopérabilité(Interoperability) : La capacité du produit logiciel à interagir avec un ou plusieurs
systèmes spécifiés.
Sécurité(Security) :La capacité du produit logiciel à protéger les informations et les données afin que
des personnes ou des systèmes non autorisés ne puissent pas les lire ou les modifier, et des personnes ou
des systèmes autorisés ne sont pas interdits d'accès.
Conformité(Functionality compliance) : La capacité du produit logiciel à respecter les normes,
conventions ou réglementations légales et les prescriptions similaires relatives à la fonctionnalité.

FIABILITE (Reliability) : est-ce que le logiciel maintient son niveau de service
dans des conditions précises et pendant une période déterminée ? La capacité du
produit logiciel à maintenir un niveau de performance spécifié lorsqu'il est utilisé
des conditions critiques.
Maturité (Maturity) : La capacité du produit logiciel à éviter les défaillances résultant de
défauts du logiciel.
Tolérance aux pannes(Fault tolerance) : La capacité du produit logiciel à maintenir un
niveau de performance spécifié en cas de défaillance du logiciel ou de violation de son interface
spécifiée.
Facilité de récupération(Recoverability ) : La capacité du produit logiciel à rétablir un
niveau de performance spécifié et à récupérer les données directement affectées en cas de
défaillance.

Facilité d'utilisation (Usability ) : est-ce que le logiciel requiert peu
d’effort à l’utilisation ? La capacité du produit logiciel à être compris, appris,
utilisé et attrayant pour l'utilisateur, lorsqu'il est utilisé dans des conditions
spécifiées.
Facilité de compréhension (Understandability ) : La capacité du produit logiciel à
permettre à l'utilisateur de comprendre si le logiciel est adapté et comment il peut être utilisé
pour des tâches et conditions d'utilisation particulières
Facilité d'apprentissage(Learnability) : La capacité du produit logiciel à permettre à
l'utilisateur d'apprendre son application.
Facilité d'exploitation(Operability) : La capacité du produit logiciel à permettre à
l'utilisateur de l'utiliser et de le contrôler.
Attraction (Attractiveness) : La capacité du logiciel à être attrayant pour l'utilisateur
(tels que l'utilisation des couleurs et la conception graphique).

Efficacité (Efficiency ) : est-ce que le logiciel requiert un dimensionnement
rentable et proportionné de la plate-forme d’hébergement en regard des autres
exigences ? La capacité du produit logiciel à fournir une performance
appropriée, par rapport à la quantité de ressources utilisées, en dessous les
conditions indiquées.
Comportement temporel (Time behaviour ) : La capacité du produit logiciel à fournir
des temps de réponse et de traitement et des débits de traitement appropriés lors de
l'exécution de sa fonction conformément aux conditions indiquées.
Utilisation des ressources(Resource utilisation) : La capacité du produit logiciel à
utiliser des quantités et des types de ressources appropriés lorsque le logiciel remplit sa fonction
conformément aux conditions définies.

Maintenabilité(Maintainability ) : est-ce que le logiciel requiert peu
d’effort à son évolution par rapport aux nouveaux besoins ? La capacité du
produit logiciel à fournir une performance appropriée, par rapport à la
quantité de ressources utilisées, en dessous les conditions indiquées.
Facilité d'analyse(Analysability ) : La capacité du produit logiciel à être diagnostiqué
pour des déficiences ou des causes de défaillances dans le logiciel, ou pour que les pièces à
modifier soient identifiées.
Facilité de modification(Changeability) : La capacité du produit logiciel à permettre
l’implémentation d'une modification spécifiée (l'implémentation inclut le codage, la conception et
la documentation des modifications).
Stabilité(Stability) : La capacité du logiciel à éviter les effets inattendus des modifications du
logiciel.
Testabilité(Testability) : La capacité du logiciel à valider les modification.

Portabilité (Portability ) : est-ce que le logiciel peut être transféré d’une
plate-forme ou d’un environnement à un autre ? La capacité du produit logiciel à
être transféré d'un environnement à un autre.
Facilité d'adaptation(Adaptability) : La capacité du produit logiciel à être adapté pour
différents environnements spécifiés sans appliquer d'actions ou de moyens autres que ceux
prévus à cet effet pour le logiciel considéré.
Facilité d'installation(Installability) : La capacité du produit logiciel à être installé dans un
environnement spécifié.
Coexistence(Co-existence) : La capacité du logiciel à coexister avec d'autres logiciels
indépendants dans un environnement commun partageant des ressources communes.
Interchangeabilité(Replaceability) : La capacité du produit logiciel à être utilisé à la place
d'un autre produit logiciel spécifié pour le même but dans le même environnement (par exemple,
la remplaçabilité d'une nouvelle version d'un produit logiciel est importante pour l'utilisateur lors
de la mise à niveau).

EXEMPLE DE MÉTRIQUESLA NORME ISO9126>
External interoperability metrics
Metric name Purpose of the metrics Method of application Measurement, formula and
data element computations
Interpretation of
measured value
Data
exchangeability
(Data format
based)
How correctly have the
exchange interface functions
for specified data transfer been
implemented?
Test each downstream interface
function output record format of the
system according to the data fields
specifications.
Count the number of data formats
that are approved to be exchanged
with other software or system
during testing on data exchanges in
comparing with the total number.
X= A / B
A= Number of data formats which
are approved to be exchanged
successfully with other software or
system during testing on data
exchanges,
B= Total number of data formats to
be exchanged
0<=X<= 1
The closer to
1.0 is the
better.
NOTE: It is recommended to test specified data transaction.
Data
exchangeability
(User’s success
attempt based)
How often does the end user
fail to exchange data between
target software and other
software?
How often are the data
transfers between target
software and other software
successful?
Can user usually succeed in
exchanging data?
Count the number of cases that
interface functions were used and
failed.
a) X= 1 - A / B
A= Number of cases in which user
failed to exchange data with other
software or systems
B= Number of cases in which user
attempted to exchange data
b) Y= A / T
T= Period of operation time
0<=X<= 1
The closer to
1.0 is the
better.
0<=Y
The closer to 0,
is the better.PROF Y.BOUKOUCHI - ENSA D'AGADIR

External maturity metrics
Metric name Purpose of the
metrics
Method of application Measurement, formula and
Interpretation of measured value
Test coverage
(Specified
operation
scenario testing
coverage )
How much of
required test
cases have been
executed during
testing?
Count the number of test
cases performed during
testing and compare the
number of test cases required
to obtain adequate test
coverage.
X= A / B
A= Number of actually performed
test cases representing operation
scenario during testing
B= Number of test cases to be
performed to cover requirements
0<=X<=1
The closer to 1.0 is the better test
coverage.
NOTE: 1. Test cases may be normalised by software size, that is: test density coverage Y= A / C, where C= Size of product to be tested.
The larger Y is the better. Size may be functional size that user can measure.
Test maturity Is the product
well tested?
(NOTE: This is to
predict the
success rate the
product will
achieve in future
testing.)
Count the number of passed
test cases which have been
actually executed and
compare it to the total number
of test cases to be performed
as per requirements.
X= A / B
A= Number of passed test cases
during testing or operation
B= Number of test cases to be
performed to cover requirements
0<=X<=1
The closer to 1.0 is the better.

External attractiveness metrics
Metric name Purpose of the metrics Method of application Measurement, formula and
Interpretation of measured value
Attractive interaction How attractive is the
interface to the user?
Questionnaire to
users
Questionnaire to assess the
attractiveness of the interface to
users, after experience of usage
Depend on its questionnaire scoring
method.
Interface
appearance
customisability
What proportion of
interface elements
can be customised
in appearance to the
user’s satisfaction?
Conduct user test
and observe user
behaviour.
X= A / B
A= Number of interface elements
customised in appearance to user’s
satisfaction
B= Number of interface elements
that the user wishes to customise
0 <= X <= 1

MÉTRIQUES DE CODE
" Vous ne pouvez pas gérer ce que vous ne contrôlez
pas, et vous ne pouvez pas contrôler ce que vous ne
mesurez pas " {DeMarco}

Etant donné un programme S, son graphe de contrôle, noté [S], est un graphe
orienté construit de la manière suivante :
les instructions correspondent aux nœuds (sommet)
les conditions (des tests et boucles) sont associées aux arcs correspondants
chaque graphe comporte un nœud «entrée» et un nœud « sortie»
a
b
séquentielle
a
b c
d
alternative
a
b
c
itérative
GRAPHE DE CONTRÔLEMÉTRIQUES DE CODE>

 Transformer un Programme P en un Graphe orienté [P]:
 e: un sommet entrée(A)
 s: un sommet sortie(J)
 Un sommet correspond à un bloc d’instructions
 Un arc correspond à la possibilité de transfert de
l’exécution d’un nœud à un autre
Begin
ReadLn(x);
if(x<=0) then x:=-x
else x:=1-x;
if (x=-1) then x:=1
else x:=x+1;
Writeln(x)
end
C
D E
f
B
G H
I
A
J
ReadLn(x);
if(x<=0)
x>0x<=0
x:=1-xx:=-x
if (x=-1)
x=-1 x!=-1
x:=x+1x:=1
WriteLn(x)

EXEMPLES
{
if(y<=0)
{y=x+1;}
else
{y=-x}
}
B
CD
A
F
if(y<=0)
y<=0
y=x+1
y>0
y=-x
{
if(y<=0)
{y=x+1;}
y=-x
}
B
C
D
A
F
if(y<=0)
y<=0
y=x+1
y>0
y=-x
{
while(y>=0)
{x=x*2;
y=y-1; }
}
B
C
D
A
F
while(y>=0)
x=x*2
y<0
y=y-1

CHEMIN DE CONTRÔLE
A chaque exécution correspond un chemin de contrôle dans le
graphe.
Une exécution possible correspond à un chemin de contrôle
dans le graphe de contrôle :
[A,B,C,D,F] est un chemin de contrôle exécutable.
[A,B,D,E,F] est un chemin de contrôle exécutable.
Une exécution non possible ne correspond pas à un chemin
de contrôle dans le graphe de contrôle:
[A,B,C,D,E,F] n’est pas un chemin exécutable.
[A,B,D,F] n’est pas un chemin exécutable.
B
C
D
E
A
F
if(y<=0)
y<=0
y>0
x=y+1
if (y>0)
y>=0
y>0
x=y-1
{
if(y<=0)
{x=y+1;}
if(y>0)
{x=y-1}
}

SWITCH-FOR-RETURN
1. Les switch sont considérés comme des if imbriqués.
2. Les boucles for sont considérées come des boucles while spéciales.
3. Les return sont considérés comme des sauts à la fin des fonctions.
4. Ces graphes sont planaires pour des programmes structurés (ils ne le
sont plus nécessairement avec des instructions de type goto).
5. Il est possible de simplifier ces graphes si seuls les chemins nous
intéressent. On peut fusionner les séquences d'instructions non composées
(et préserver le nombre de chemins).

EXERCICES
Construire les graphes de contrôle des fonctions suivantes :
int lcm(int p, int q)
{
while (p != q) {
if (p > q) {p = p - q; }
else {q = q - p;}
}
return p;
}
int compute(int[] a, int inf, int sup)
{
int sum, i;
sum = 0;
i = inf;
while (i <= sup) {
sum = sum + a[i];
i = i + 1;}
return sum;
}
int compute(int[] a, int inf, int sup)
{
int sum, i;
sum = 0;
for (i = inf; i<= sup; i++) {
sum = sum + a[i]; }
return sum;
}

Les mesures des lignes de code (LOC, Lines of Code) sont les mesures les plus
traditionnellement utilisées pour quantifier la complexité d’un logiciel. Elles sont
simples, faciles à compter et très faciles à comprendre.
Elles ne prennent cependant pas en compte le contenu d'intelligence et la
disposition du code.
On peut distinguer les types de lignes suivantes:
 LOCphy (Number of physical lines): le nombre total des lignes physiques dans tous
les fichiers source.
 LOCpro (Number of program lines): le nombre de lignes de programme comme : les
déclarations, les définitions, les directives et les code.
 LOCcom (Number of commented lines): le nombre de lignes de commentaires,
 LOCbl (Number of blank lines): le nombre de lignes vides.
LES MÉTRIQUES DES LIGNES DE CODEMÉTRIQUES DE CODE>

La complexité Cyclomatique également référée comme complexité de programme ou
complexité de McCabe, a été introduite par Thomas McCabe en 1976 (McCABE, 1976).
Elle est le calcul le plus largement répandu des métriques statiques, conçue pour être
indépendante du langage et du format de langage.
La complexité cyclomatique d’une méthode correspond au nombre de chemins
linéairement indépendants qu'il est possible d'emprunter dans cette méthode, elle est
définie par :
v(G)= E-N+2P
E = le nombre d'arêtes du graphe,
N = le nombre de nœuds du graphe,
P = le nombre de composantes connexes du graphe
(dans notre cas : P=1 un seul ensemble de nœuds).
Ici, N=8, E=11 et P=1 donc v(G)=11-8+2=5
COMPLEXITÉ CYCLOMATIQUE DE MCCABEMÉTRIQUES DE CODE>

Calcul direct du nombre de McCabe
– Produire un graphe de contrôle et l’analyser peut s’avérer long dans le cas de
programmes complexes
– Mc Cabe a introduit une nouvelle manière de calculer la complexité structurelle:
C = π + 1
avec π le nombre de prédicats(décisions) du code
Remarque:
Une instruction IF > compte 1 pour chaque décision
Une boucle FOR ou WHILE > compte 1 décision
Une instruction CASE traitant N cas > N-1décision
Ici, π =4 (4 décisions), donc C=4+1=5

Plus le nombre Cyclomatique est grand, plus il y aura de chemins d'exécution
dans la fonction, et plus elle sera difficile à comprendre et à tester.
Ce nombre est l'une des plus importantes mesures de complexité afin d’estimer
l’effort (nombre de tests) nécessaire pour tester un logiciel (la couverture du
code = Code coverage).
La complexité cyclomatique d'une méthode vaut au minimum 1, puisqu'il y a
toujours au moins un chemin.
La valeur maximum du nombre cyclomatique peut être définie comme un critère
de qualité dans le plan qualité.
Dans la pratique il semble que la limite supérieure du nombre cyclomatique soit
de 30 environ. Sinon si elle est supérieure à 30 il faut refactoriser la méthode.

Créer le graphe de programme ci-dessous et calculer le nombre cyclomatique
v(G)= E-N+2
v(G)= 7-6+2
alors v(G)=3
C = π + 1
C = 3 + 1
alors C=4

Calculer le nombre cyclomatique
v(G)= E-N+2
v(G)= 10-8+2
alors v(G)=4
C = π + 1
C = 3 + 1
alors C=4

EXERCICES Calculer le nombre cyclomatique des programmes suivants:
void sort(int *px, int n){
int i, j, temp;
for(i=2;i<n; i++){
for(j=1; j<i; j++){
if(px[i]<px[j]){
temp=px[i];
px[i]=px[j];
px[j]=temp;
}
}
}
}
void rech_dico (elem cle, elem t[], int taille, boolean &trouv, int &A)
{ int d, g, m; g=0; d=taille -1; A=(d+g) /2;
if (t[A]==cle) trouv=true;
else trouv=false;
while (g <=d && !trouv){
m= (d+g) /2;
if (t[m]= =cle)
{ trouv=true; A=m; }
else if (t[m]> cle) g=m+1;
else d=m-1;
}
}

Les métriques de complexité de Halstead ont été développées par l’américain
Maurice Halstead en 1977.
Elles procurent une mesure quantitative de complexité liée à la distribution des
variables et instructions.
Toutes les métriques d'Halstead sont dérivées du nombre d’opérandes ( jetons qui
contiennent une valeur) et d’opérateurs ( tout le reste: virgules, parenthèses,
operateurs arithmétiques, ...)
n1= nombre d’opérateurs uniques
n2= nombre d'opérandes uniques (termes, constantes, variables)
N1= nombre total d’apparition de ces opérateurs
N2= nombre total d’apparition de ces opérandes. Exemple : a := a + 1;
◦ 3 opérateurs + := ;
◦ 2 opérandes a 1
COMPLEXITÉ DE HALSTEADMÉTRIQUES DE CODE>

Une fois que le code a été écrit, cette mesure peut être appliquée pour prédire la
difficulté d’un programme et d’autres métriques, en employant les équations de
Halstead :
Vocabulaire du programme (Vocabulary size) n = n1 + n2
Taille observée du programme (Program length) N = N1 + N2
Volume du programme (Program volume): Estimation du nombre de bits
nécessaires pour coder le programme mesuré: V = N Log2 (n1 + n2)
Taille estimée du programme Le = n1Log2(n1) + n2Log2(n2)

Ces chiffres (n1, n2, N1, N2) sont aussi la base pour calculer les métriques suivantes:
Le Niveau de difficulté (Difficulty level), où D =
𝒏𝟏
𝟐
×
𝑵𝟐
𝒏𝟐
.
Niveau du programme (Program level), où L =
𝟏
𝑫
.
Effort d’implémentation (Effort to implement), où : E = V x D .
Temps d’implémentation (Implementation time), où : T =
𝑬
𝟏𝟖
.
Nombre de bugs estimés dans un module ou une fonction (Number of delivered
bugs), où : B =
𝑬 𝟐/𝟑
𝑺
, (S représente l'habileté du développeur).

Exercice : Calculer les mesures de Halstead pour le programme
suivant :
z = 0;
while x > 0
z = z + y;
x = x - 1;
end-while
print (z);
Solution:
– Opérateurs : = ; while/end-while > + - print ()
– Opérandes : = z 0 x y 1
– η1 = 8, η2 = 5 alors η=13
– N1= 13, N2=11 alors N=24
Opérateurs Opérandes
= 3 z 4
; 4 0 2
w/ew 1 x 3
> 1 y 1
+ 1 1 1
- 1
print 1
() 1

Volume de programme:
V = N×log2(η1+η2)
V = 24×log2(13)= 24 × 3.7 = 88.8
Le volume d’une fonction devrait être compris entre 20 et 1000.
Le Niveau de difficulté (Difficulty level):
D =
𝑛1
2
×
𝑁2
𝑛2
= (8/2)X(11/5)=8.8
Effort d’implémentation :
E = V x D = 88.8*8.8=781.44
Temps d’implémentation :
T =
𝑬
𝟏𝟖
= 781.44 =43.41 secondes
Estimation de la taille de programme
Le = η1log2(η1) + η2log2(η2)
Le = 8×log2(8) + 5×log2(5) = 8×3+5×2.32=35.6
Ici, Le >> N (35.6>>24)

Exercice2: Calculer les mesures de Halstead pour le programme suivant :
void sort(int *px, int n){
int i, j, temp;
for(i=2;i<n; i++){
for(j=1; j<i; j++){
if(px[i]<px[j]){
temp=px[i];
px[i]=px[j];
px[j]=temp;
}
}
}
} PROF Y.BOUKOUCHI - ENSA D'AGADIR

Chidamber et Kemerer‎‎(en 1994), ils proposent six métriques fortement liées aux
concepts orientés objets :
Méthodes pondérées par classe WMC (Weighted Methods per Class), Cette mesure
permet de pondérer le nombre des méthodes d'une classe par leurs propres complexités
internes, elle est formalisée par : WMC = 𝑪𝒊𝒏
𝒊=𝟏 , si la classe définit n méthodes, Ci
dénote la complexité individuelle de chaque méthode, le nombre de méthodes et leurs
complexités dans une classe permettra de prédire le délai et l'effort exigés dans la
construction et la maintenance de cette classe.
Profondeur de l’arbre d’héritage DIT (Depth of Inheritance Tree), c’est la distance
maximale entre un nœud et la racine de l’arbre d’héritage de la classe concernée. Une
classe ayant une valeur plus élevée impliquera une complexité plus grande et une
certaine difficulté à prédire le comportement de la classe;
Nombre d’enfants NOC (Number Of Children), c’est le nombre de sous-classes
dépendant immédiatement d’une classe donnée par une relation d’héritage. Un nombre
de classes descendantes plus élevé montrera certains problèmes qualitatifs et de
performance dans la conception du système.
MÉTRIQUES ORIENTÉES OBJETS DE CHIDAMBER ET KEMERERMÉTRIQUES DE CODE>

Couplage entre classes CBO (Coupling Between Object), La métrique est développée
pour mesurer la dépendance entre classes dans la conception du système, La mesure du
couplage d'une classe est représentée par le nombre de classes couplées avec ce1le-ci.
Un fort couplage représenté par une grande valeur indique que la classe sera plus
complexe et plus difficile à comprendre tout en ayant une réutilisabilité diminuée, moins
de facilité de modification et moins de facilité de maintenance.
Référence pour une classe RFC (Reference For Class), c’est l’ensemble des méthodes qui
peuvent être exécutées en réponse à un message reçu par un objet de la classe
considérée. Un nombre de méthodes invoquées plus élevé en réponse au message
signifie une complexité de classe plus élevée.
Manque de cohésion des méthodes LOC (Lack Of Cohesion Of Methods) , c'est le
nombre de méthodes prises deux à deux (paires de méthodes) ne partageant pas des
instances de variables de la classe. une cohésion élevée est favorable dans la
conception orientée objet, parce qu'elle tend à promouvoir l'encapsulation dans la
classe, ceci apportant une simplicité et une réutilisabilité élevées de la classe.
MÉTRIQUES ORIENTÉES OBJETS DE CHIDAMBER ET KEMERERMÉTRIQUES DE CODE>

L’ANALYSE QUALITATIVE DU LOGICIEL

L’analyse qualitative consiste à effectuer une série de revues du logiciel, la
plupart du temps manuellement.
la quantification de la qualité du logiciel est loin d’être aussi évidente et
efficace et nécessite une revue de l’architecture et du code du logiciel.
Cette analyse qualitative se fonde sur les informations recueillies au cours de
l’analyse quantitative afin de cibler les revues sur les points sensibles du
logiciel.
Une revue est un examen détaillé d’une spécification, d’une conception ou
d’une implémentation par une personne ou un groupe de personnes, afin de
déceler des fautes, des violations de normes de développement ou d'autres
problèmes.
DÉFINITIONSANALYSE QUALITATIVE DU LOGICIEL>

Les revues d’architecture consistent à analyser la structuration des composants
du logiciel de manière à détecter d’éventuels points d’inefficience pouvant être
corrigés par refactoring.
Pour analyser cette structuration, il est nécessaire de se fonder sur la
documentation du logiciel. Généralement, l’architecture d’un logiciel peut être
représentée efficacement au travers de diagrammes UML permettant de
s’abstraire du code et de dégager ainsi la structure du logiciel.
Les problèmes détectés par les revues d’architecture sont souvent très difficiles
à corriger, car ils touchent à la conception même du logiciel.
Malheureusement pour remédier à ce genre de problème, il faut généralement
effectuer une réécriture complète.
LES REVUES D’ARCHITECTUREANALYSE QUALITATIVE DU LOGICIEL>

Les revues de code peuvent être pour partie automatisées, mais elles
nécessitent toujours le jugement humain pour déterminer si du code doit être
refondu ou non.
Les revues de code automatisées
Il existe plusieurs outils capables d’analyser le code d’un logiciel pour
identifier de mauvaises pratiques de programmation.
Les revues de code manuelles.
Les revues de code manuelles consistent tout simplement à lire le code.
Idéalement, ces revues de code doivent être menées par une ou plusieurs
personnes d’expérience extérieures au projet:
l’expérience permet de détecter plus facilement les problèmes.
le fait d’être extérieur au projet permet d’avoir un œil neuf sur ce qui a été
fait.
LES REVUES DE CODEANALYSE QUALITATIVE DU LOGICIEL>

Parmi les défauts typiques détectés par la revue de code:
code mort : variables ou paramètres inutilisés, importations de packages inutiles.
règles de nommage : respect des bonnes pratiques dans le nommage des
différentes entités de programmation (classes, méthodes, packages, variables).
règles de formatage du code : lignes de code trop longues, mauvaise utilisation
des délimiteurs de code, etc.
règles sur la taille du code : classes ou méthodes trop longues, listes de
paramètres excessives, etc.
règles sur la gestion des exceptions : clauses catch sans contenu, utilisation
abusive de la classe Exception, etc.
règles sur la documentation javadoc : vérification de la présence de
documentation, vérification de l’exhaustivité de la documentation, etc.
DÉFAUTS TYPIQUESANALYSE QUALITATIVE DU LOGICIEL>

Programme 1
Trouver les 4 erreurs
Programme 2
Programme 3

MERCI DE VOTRE ATTENTION

Métriques de qualité logicielle

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Métriques de qualité logicielle

Similaire à Métriques de qualité logicielle (20)

Plus de Youness Boukouchi

Plus de Youness Boukouchi (10)

Métriques de qualité logicielle