Métriques de qualité logicielle

LES MÉTRIQUES DE QUALITÉ LOGICIELLE

Youness BOUKOUCHI

ENSA d’Agadir

3ème année Génie Logiciel

[email protected]

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ÉFINITIONS LA 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 LOGICIEL LA 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 CAS LES 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



Qua

lité d

u pro

dui

t

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 producteffect 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ÉSENTATION LA 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ÈRES LA 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ÉTRIQUES LA 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ÔLE MÉ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>0 x<=0

x:=1-x x:=-x

if (x=-1)

x=-1 x!=-1

x:=x+1 x:=1

WriteLn(x)




EXEMPLES

{

if(y<=0)

{y=x+1;}

else

{y=-x}

}

B

C D

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 CODE MÉ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 MCCABE MÉ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 HALSTEAD MÉ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 KEMERER MÉ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 KEMERER MÉ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ÉFINITIONS ANALYSE 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’ARCHITECTURE ANALYSE 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 CODE ANALYSE 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 TYPIQUES ANALYSE QUALITATIVE DU LOGICIEL>



Programme 1

Trouver les 4 erreurs

Programme 2


Programme 3









MERCI DE VOTRE ATTENTION
