LES MÉTRIQUES DE QUALITÉ LOGICIELLE
Youness BOUKOUCHI
ENSA d’Agadir
3ème année Génie Logiciel
PROF Y.BOUKOUCHI - ENSA D'AGADIR
Version 1.0 - 2017
QUALITÉ LOGICIELLE Définitions,
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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 >
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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 >
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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 >
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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 >
PROF Y.BOUKOUCHI - ENSA D'AGADIR
LES MODÈLES DE QUALITÉ LOGICIELLE
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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é").
UN MODÈLE DE QUALITÉ LES MODÈLES DE QUALITÉ LOGICIELLE>
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
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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.
UN MODÈLE DE QUALITÉ LES MODÈLES DE QUALITÉ LOGICIELLE>
Le modèle ISO9126:2001
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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é.
UN MODÈLE DE QUALITÉ LES MODÈLES DE QUALITÉ LOGICIELLE>
Le modèle SQuaRE
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
UN MODÈLE DE QUALITÉ LES MODÈLES DE QUALITÉ LOGICIELLE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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".
EVALUATION D’UN MODÈLE DE QUALITÉ LES MODÈLES DE QUALITÉ LOGICIELLE>
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.
EVALUATION D’UN MODÈLE DE QUALITÉ LES MODÈLES DE QUALITÉ LOGICIELLE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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.
EVALUATION D’UN MODÈLE DE QUALITÉ LES MODÈLES DE QUALITÉ LOGICIELLE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
EVALUATION D’UN MODÈLE DE QUALITÉ LES MODÈLES DE QUALITÉ LOGICIELLE>
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
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
ETUDE DE CAS LES MODÈLES DE QUALITÉ LOGICIELLE>
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
ETUDE DE CAS LES MODÈLES DE QUALITÉ LOGICIELLE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
ETUDE DE CAS LES MODÈLES DE QUALITÉ LOGICIELLE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
ETUDE DE CAS LES MODÈLES DE QUALITÉ LOGICIELLE>
Qualité évaluée
54,5% PROF Y.BOUKOUCHI - ENSA D'AGADIR
LA NORME ISO9126
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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.
PRÉSENTATION LA NORME ISO9126>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
PRÉSENTATION LA NORME ISO9126>
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
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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é.
FACTEURS & CRITÈRES LA NORME ISO9126>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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.
FACTEURS & CRITÈRES LA NORME ISO9126>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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).
FACTEURS & CRITÈRES LA NORME ISO9126>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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.
FACTEURS & CRITÈRES LA NORME ISO9126>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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.
FACTEURS & CRITÈRES LA NORME ISO9126>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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).
FACTEURS & CRITÈRES LA NORME ISO9126>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
EXEMPLE DE MÉTRIQUES LA NORME ISO9126>
External maturity metrics Metric name Purpose of the
metrics
Method of application Measurement, formula and
data element computations
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.
PROF Y.BOUKOUCHI - ENSA D'AGADIR
EXEMPLE DE MÉTRIQUES LA NORME ISO9126>
External attractiveness metrics Metric name Purpose of the metrics Method of application Measurement, formula and
data element computations
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
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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}
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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)
GRAPHE DE CONTRÔLE MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
GRAPHE DE CONTRÔLE MÉTRIQUES DE CODE>
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
PROF Y.BOUKOUCHI - ENSA D'AGADIR
GRAPHE DE CONTRÔLE MÉTRIQUES DE CODE>
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}
}
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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).
GRAPHE DE CONTRÔLE MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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;
}
GRAPHE DE CONTRÔLE MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
COMPLEXITÉ CYCLOMATIQUE DE MCCABE MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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.
COMPLEXITÉ CYCLOMATIQUE DE MCCABE MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
COMPLEXITÉ CYCLOMATIQUE DE MCCABE MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
COMPLEXITÉ CYCLOMATIQUE DE MCCABE MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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;
}
}
COMPLEXITÉ CYCLOMATIQUE DE MCCABE MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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)
COMPLEXITÉ DE HALSTEAD MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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).
COMPLEXITÉ DE HALSTEAD MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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
COMPLEXITÉ DE HALSTEAD MÉTRIQUES DE CODE>
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
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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)
COMPLEXITÉ DE HALSTEAD MÉTRIQUES DE CODE>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
Exercice2: Calculer les mesures de Halstead pour le programme suivant :
COMPLEXITÉ DE HALSTEAD MÉTRIQUES DE CODE>
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
L’ANALYSE QUALITATIVE DU LOGICIEL
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
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>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
DÉFAUTS TYPIQUES ANALYSE QUALITATIVE DU LOGICIEL>
Programme 1
Trouver les 4 erreurs
Programme 2
Trouver les 5 erreurs
Programme 3
Trouver les 5 erreurs
PROF Y.BOUKOUCHI - ENSA D'AGADIR
DÉFAUTS TYPIQUES ANALYSE QUALITATIVE DU LOGICIEL>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
DÉFAUTS TYPIQUES ANALYSE QUALITATIVE DU LOGICIEL>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
DÉFAUTS TYPIQUES ANALYSE QUALITATIVE DU LOGICIEL>
PROF Y.BOUKOUCHI - ENSA D'AGADIR
MERCI DE VOTRE ATTENTION
PROF Y.BOUKOUCHI - ENSA D'AGADIR