d’évaluation du software pour l’amélioration de la
TRANSCRIPT
REPUBLIQUE ALGÉRIENNE DÉMOCRATIQUE ET POPULAIRE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITÉ HADJ LAKHDAR « BATNA » FACULTÉ DES TECHNOLOGIES
DEPARTEMENT GENIE INDUSTRIEL
MÉMOIRE
EN VUE DE L’OBTENTION DU DIPLÔME DE MAGISTÈRE
SPÉCIALITÉ
GÉNIE INDUSTRIEL ET PRODUCTIQUE
Par
Lazhar OURLIS
Ingénieur d'État en Informatique
Thème
Analyse des indicateurs nécessaires au processus d’évaluation du software pour l’amélioration de la
qualité du logiciel Application – Logiciel de gestion de l'État civil
Leila Hayet MOUSS, MCA, Université de Batna Présidente
Hacen SMADI, MCA, Université de Batna Examinateur
Moussa ZOUAOUI, MCA, Université de Sétif Examinateur
Athmane MECHENENE, MCA Université de Batna Rapporteur
Samir ABDELHAMID, MCA Université de Batna Corapporteur
Année 2011-2012
i
Résumé. L'importance des évaluations de produits logiciels va croître avec la prise de conscience de
la nécessité de développer des logiciels de qualité qui offrent un service stable et qui peuvent
facilement évoluer sans engendrer des coûts importants pour ceux qui les maintiennent. Le processus
de mener de telles évaluations, tel que celui décrit dans l’ISO 14598, est important pour obtenir des
résultats d'évaluation qui peuvent être appliqués et répondre aux attentes des clients. Or, d’après la
norme ISO 9126, la qualité du logiciel peut être évaluée selon plusieurs indicateurs. Parmi ces
indicateurs, nous nous intéressons particulièrement à l’aspect maintenabilité dans notre étude
d’évaluation de la qualité logicielle. Malgré l’intérêt porté à la maintenance du logiciel, il n’existe pas
de modèles d’évaluation de la maintenabilité prédictifs appuyés par des lois acceptées par tous. C’est
dans ce cadre précis que nous proposons un modèle basé sur les normes (ISO 9126, ISO 14598) fondé
sur l’analyse du code source où les mesures utilisées sont indépendantes de la technologie et
permettent l’analyse des causes des problèmes liés à la maintenabilité.
Mots-clés: Evaluation du produit logiciel, ISO 14598, la qualité du logiciel, ISO 9126, Maintenabilité.
Abstract. The importance of evaluations of software products will grow with the awareness of the
need to develop quality software that offer a stable service that can easily evolve without incurring
significant costs for those who maintain them. The process to conduct such evaluations, as described
in ISO 14598, is crucial to get evaluation results that can be applied and meet customers’ expectations.
As stated in ISO 9126 standard, software quality can be evaluated according to several indicators.
Among these indicators, we are particularly interested in the maintainability aspect in our study to
evaluate software quality. Despite the interest in software maintenance, there are no predicting models
for evaluating the maintainability accepted by all. Within this context, we propose a specific model
based on standards (ISO 9126, ISO 14598) grounded in source code analysis where measures are
technology independent and enable root-cause analysis.
Keywords: Software product evaluation, ISO 14598, software quality, ISO 9126, Maintainability.
ii
Dédicaces
Ce modeste travail de recherche est dédié à mes parents auxquels je
dois tout et à toutes personnes ayant contribué de prêt ou de loin à la
réalisation de ce mémoire.
iii
REMERCIEMENTS
Je remercie tout d’abord les deux directeurs de mon mémoire
M. Athmane MECHENENE et M. Samir ABDELHAMID.
Mes remerciements vont également à Mme la présidente Leila Hayet MOUSS, et à
tous les membres de jury d’avoir accepté de participer à cette soutenance.
Je remercie tous ceux sans qui cette thèse ne serait pas ce qu’elle est : aussi bien par
leurs suggestions ou contributions. Je pense ici en particulier à mon oncle M. Ourabah
OURLIS et mon frère M’hand.
Mes sincères remerciements et ma vive gratitude s’adressent à tous ceux et celles qui
sont restés à mes côtés durant la recherche. Je pense ici en en particulier à ma chère mère et
ma femme.
Nous remercions profondément notre famille qui, par le biais de contributions
diverses, nous a aidée, encouragée et soutenue.
iv
Liste des tableaux
Tableau 1 – Résultats des enquêtes du Standish Group 16
Tableau 2 – Améliorations des projets mitigés entre 1994 et 2000 16
Tableau 3 – Les 11 caractéristiques de McCall 18
Tableau 4 – Caractéristiques et sous- caractéristiques qualité du logiciel
(d’après la norme ISO/IEC 9126 :1991) 19
Tableau 5 – Caractéristiques de la qualité du logiciel en cours d’utilisation 20
Tableau 6 – Techniques SCOPE : Choix des techniques pour chaque niveau 23
Tableau 7 – Types d'échelles 50
Tableau 8 – Résultats d'évaluation de la qualité des exigences 54
Tableau 9 – Exemples des entités logicielles [Fenton & Pfleeger 97] 56
Tableau 10 – Exemple de mesure de la taille d’un programme (écrit en C) 56
Tableau 11a – Opérateurs de l'exemple 80
Tableau 11b – Opérandes de l'exemple 80
Tableau 11c – Résultats des mesures d’Halstead de l'exemple 80
Tableau 12 – Structures de contrôle (VISUAL BASIC) 83
Tableau 13 – Les branches conditionnelles et leurs impacts sur la valeur de CC
(cas du langage VISUAL BASIC) 85
Tableau 14 – Produits logiciels choisis pour l'évaluation selon le modèle de
Maintenabilité MM6P_ISO9126 138
Tableau 15 – Le modèle de maintenabilité MM6P_ISO9126 145
Tableau 16 – Function point Languages Table 148
v
Liste des figures
Figure 1.1 - Relations entre les attributs logiciels - Exemple de CUPRIMDA 10
Figure 1.2 - Représentation simplifiée du processus de développement en cascade 10
Figure 1.3 - Éléments clés de la gestion de la qualité totale TQM 13
Figure 1.4 - Organisation des normes SQuaRE 24
Figure 2.1 - Domaines de la mesure du logiciel 34
Figure 2.2 - Les entités de base pour le domaine des produits 38
Figure 2.3 - Approche de mesure 45
Figure 2.4 - Classification de la complexité logicielle 60
Figure 2.5 - Différentes approches pour la distribution du code source 62
Figure 3.1 - Exemple de graphe de flot de contrôle 82
Figure 3.2 - Exemple de graphe de couplage 90
Figure 4.1 - Relation entre ISO 9126 et ISO 14598 — ISO 9126-1:2001 108
Figure 4.2 - La qualité dans le cycle de vie du logiciel — ISO 9126-1:2001 109
Figure 4.3 - Modèle de qualité pour la qualité externe et interne: caractéristiques et
sous-caractéristiques — ISO 9126-1:2001 110
Figure 4.4 - Modèle de qualité pour la qualité en cours d’utilisation ISO 9126 – 1 110
Figure 4.5 - Caractéristiques, sous caractéristiques et attributs de qualité —
ISO 9126 – 1:2001 111
Figure 4.6 - Processus d’évaluation — ISO/IEC 14598-1 114
Figure 4.7 - Niveaux d’évaluation pour les métriques — ISO/IEC 14598-1 :1999
(Valeurs de référence avec une échelle de mesure et une échelle d'interprétation) 115
Figure 4.8 - La méthode W-Process pour l’évaluation du produit logiciel 123
Figure 4.9 - Informations nécessaires sur les objectifs et les ressources pour réaliser
un compromis 128
Figure 4.10 - Moments de feedback et de compromis dans la méthode W-process 129
Figure 4.11 - Processus d’évaluation de la qualité du logiciel
(Yann-Gaël Guéhéneuc – IFT3903, Université de Montréal 2006) 129
Figure 4.12 - Modèle de référence général SQuaRE 131
vi
Figure 4.13 - L’approche GQM 133
Figure 4.14 - La hiérarchie GQM 133
Figure 5.1 - le modèle de maintenabilité MMP6_ISO9126 143
Figure 5.2 – La facilité de modification dans le modèle MM6P_ISO9126 144
Tables des matières
viii
Table des matières
Introduction 1
Chapitre 1. La qualité du logiciel
Introduction 5
1.1. Qualité: vues populaires 5
1.2. Qualité: points de vue professionnels 6
1.2.1. Le rôle du client 7
1.3. La qualité du logiciel 8
1.4. Gestion de la qualité totale 11
1.5. La crise du logiciel 15
1.6. Raisons du manque de qualité des logiciels 17
1.7. Evaluation de la qualité du logiciel : référentiels normatifs 18
1.7.1. Les 11 caractéristiques de McCall (1977) 18
1.7.2. Norme ISO/IEC 9126 :1991 19
1.7.3. Norme ISO/IEC 14598 :1999 20
1.7.4. SCOPE projet européen ESPRIT 21
1.7.5. Deuxième génération de standards de qualité – Norme ISO/IEC 25000:2005 24
1.7.6. CISQ 25
Conclusion 25
Tables des matières
ix
Chapitre 2. La mesure du logiciel
Introduction 29
2.1. L’histoire et le développement de la mesure du logiciel 29
2.2. Contexte prévu de la mesure du logiciel 34
2.3. Problèmes et enjeux de la mesure du logiciel 35
2.4. Application de la mesure du logiciel 37
2.4.1. Domaines de mesure du logiciel 38
2.4.2. Le processus de mesure 39
2.5. Les métriques logicielles 40
2.5.1. Utilisation des métriques logicielles 41
2.6. La théorie de la mesure du logiciel 44
2.6.1. Introduction à la théorie de la mesure 44
2.6.2. Les échelles de mesure 49
2.6.3. Les mesures objectives et subjectives 53
2.6.4. Problèmes de mesure au niveau pratique 54
2.7. Les mesures logicielles: Outils pour les produire 55
2.8. L’entité code du logiciel 56
2.8.1. Les attributs du code source 57
2.9. Mesure de la complexité du code source 57
2.9.1. Différentes perspectives de la complexité du logiciel 58
2.9.2. Mesure de la complexité du code source 61
2.10. La complexité vs la distribution du code source 61
Conclusion 64
Tables des matières
x
Chapitre 3. Mesure des attributs internes du produit logiciel -
les métriques statiques du code source
Introduction 66
3.1. La taille du programme 67
3.1.1. Les lignes de code 68
3.1.2. Les constructions de programmation 70
3.1.3. Quelles sont les limites acceptables ? 72
3.1.4. Les nouvelles approches pour la mesure du code source 73
3.1.5. La réutilisation 74
3.2. La distribution du code 76
3.2.1. La mesure du code distribué 76
3.2.2. Les métriques pour la mesure du code distribué 76
3.3. La complexité du code (les métriques de Halstead) 77
3.3.1. Science du logiciel de Halstead 77
3.3.2. Les métriques de complexité de Halstead 78
3.3.3. Commentaires sur les métriques de Halstead 81
3.4. La complexité du flot de contrôle 81
3.4.1. Graphe du flot de contrôle 82
3.4.2. Les métriques simples du flot de contrôle 83
3.4.3. La complexité cyclomatique (CC) 83
3.5. Les métriques de Henry et Kafura 87
3.6. Couplage et cohésion 88
3.6.1. Couplage entre les modules 89
3.6.2. Cohésion du module 91
3.7. L’index de maintenabilité (Maintainability Index MI) 92
3.8. Les métriques logicielles orientées objet 94
3.8.1. Caractéristiques de la méthode de conception orientée objet 94
3.8.2. Les recherches antérieures sur les métriques logicielles orientée objet 95
3.8.3. Les métriques objets de Chidamber et Kemerer (CK) 99
3.8.4. Les autres métriques objets 103
Conclusion 104
Tables des matières
xi
Chapitre 4. Processus d’évaluation de la qualité du logiciel
Introduction 107
4.1. Processus d’évaluation selon les normes ISO 9126/ ISO 14598 107
4.1.1. Analyse des modèles ISO 9126 : les modèles (quantitatives) 107
4.1.2. Le modèle de référence standard 109
4.1.3. Métriques, attributs et choix des critères de mesure 111
4.1.3.1. Attributs internes et externs 111
4.1.3.2. Métriques internes et externes et la relation entre elles 112
4.1.3.3. Choix des métriques et des critères de mesure 112
4.1.4. Interprétation du modèle ISO 9126 pour l'évaluation et la prise de décision 113
4.1.5. Métrologie dans l’ISO 9126 : Les mesures de base et les mesures dérivées 116
4.1.6. Les liens manquants – de la métrologie à l'analyse quantitative 117
4.1.6.1. Aperçu 117
4.1.6.2. Analyse des mesures de “Maturité” 118
4.1.6.2.1. Perspectives en métrologie 118
4.1.6.2.2. Perspectives du modèle d'analyse de la norme ISO 9126 119
4.1.6.2.3. Les liens manquants 120
4.2. W-Process pour l’évaluation du produit logiciel 120
4.2.1. Problèmes liés à la norme ISO 14598 121
4.2.2. Extension de la norme ISO 14598 avec la méthode W-process 122
4.3. Processus d’évaluation de la qualité du logiciel 129
4.4. Processus d’évaluation selon la norme ISO/IEC 25000 ou SQuaRE 130
4.5. Le Goal/Question/Metric (GQM) 132
Conclusion 134
Tables des matières
xii
Chapitre 5. La maintenabilité du produit logiciel (Le modèle
MM6P_ISO9126) : Analyse & Evaluation
Introduction 137
5.1. Mesure de la maintenabilité selon l’ISO 9126 139
5.2. Limites de l’index de maintenabilité dans l’évaluation de la qualité du logiciel 140
5.3. Le modèle de maintenabilité MMP6_ISO9126 142
5.3.1. Le «mapping » des caractéristiques de maintenabilité sur les propriétés du code
Source dans le modèle MMP6_ISO9126 144
5.3.2. Les métriques associées aux propriétés du code sources choisies 147
5.3.2.1. La taille du programme 147
5.3.2.2. La taille de la fonction/méthode 149
5.3.2.3. La complexité du code source 149
5.3.2.4. La lisibilité du code source 151
5.3.2.5. La duplication du code source 152
5.3.2.6. Les tests unitaires du code source 153
5.4. Etudes de cas : Mesure et interprétation selon MMP6_ISO9126 154
5.4.1. Projet : SDCC – Small Device C Compiler (C) 156
5.4.2. Projet : eMule ( C++)
157
5.4.3. Projet : 7 Zip ( C& C++
) 158
5.4.4. Projet : NStudio (C#) 160
5.4.5. Projet : WDents (Delphi) 161
5.4.6. Projet : LGL_Etat_Civil (Delphi) 162
Conculsion 163
CONCLUSION 165
BIBLIOGRAPHIE
ANNEXES
Introduction
1
Introduction.
Le terme « qualité » est de plus en plus utilisé dans les entreprises, et en particulier
dans le monde informatique. La norme ISO 8402 définit la qualité comme « l’ensemble des
caractéristiques d’une entité qui lui confèrent l’aptitude à satisfaire des besoins exprimés et
implicites ». En génie logiciel, la qualité est une appréciation globale d'un logiciel, basée sur
de nombreux indicateurs [April & Laporte, 11]. La norme ISO 9126 définit six groupes
d'indicateurs de qualité du logiciel : la capacité fonctionnelle, la facilité d'utilisation, la
fiabilité, la performance, la maintenabilité et la portabilité.
L’évaluation de la qualité logicielle vise à déterminer dans quelle mesure un produit
logiciel particulier remplit ses caractéristiques spécifiées (indicateurs spécifiés dans l’ISO
9126) ou ses propriétés (la prédisposition aux défauts, la cohésion ou la structuration), ou
systématiquement examine la mesure dans laquelle le logiciel est capable de remplir des
critères spécifiés (ISO 8402, 1994). Les enquêtes menées par plusieurs chercheurs [Miller &
Dunn, 97] et [Punter & Lami, 98] montrent qu'environ 50 % des organisations qui effectuent
des évaluations de produits logiciels ne sont pas satisfaites de leurs résultats : l'évaluation
n'aboutit pas à des réponses qui correspondent à leurs attentes. D’autre part, les organisations
ne sont pas capables d'appliquer les résultats de l'évaluation pour définir des actions efficaces
à entreprendre pour améliorer la qualité de leurs produits. L'origine de l'insatisfaction à l'égard
des évaluations est souvent diagnostiquée comme étant un problème de mesure où il faut
définir ou trouver les métriques logicielles appropriées pour prédire ou déterminer les
caractéristiques de qualité ou les propriétés du produit. Basées sur cette perception, beaucoup
de recherches ont été menées sur le choix ou la définition de nouvelles métriques appropriées.
Comme exemple, on peut citer les travaux de [Briand et al, 99] « Utilisation des mesures de
couplage pour l'analyse d'impact dans les systèmes orientés objet. » ou encore les travaux de
[Koshgoftaar & Allen, 1998] et [Cartwright & Shepperd, 2000]. Nous soutenons l’idée de ces
chercheurs que l'évaluation devrait être basée sur la mesure. Toutefois, se concentrant
uniquement sur cet aspect est insuffisant pour améliorer l’évaluation du produit logiciel. Il est
également nécessaire d’impliquer les parties prenantes lors de la formulation des objectifs et
pendant les activités d'évaluation. Par conséquent, pour améliorer l’évaluation, nous devrions
Introduction
2
également inclure le processus d'évaluation au lieu de nous limiter aux mesures seulement. De
nombreuses descriptions des processus d'évaluation existent dans la littérature, voir, par
exemple, [Mayrand et Coallier, 96 ;. Kazman et al, 98]. Souvent, l'objectif principal n'est pas
le processus d'évaluation en tant que tel, mais l'application d'une technique ou un outil
spécifique, ou la description d'une procédure de travail. Une publication qui se concentre sur
le processus d'évaluation d’une façon explicite est la norme « ISO/IEC 14598 : Technologies
de l'information - Évaluation de produits logiciels ». En raison de sa référence explicite dans
la définition du processus d'évaluation, nous l’utiliserons comme point de départ dans notre
analyse des indicateurs nécessaires au processus d'évaluation du produit logiciel. Nous nous
intéresserons, en particulier, à l’indicateur maintenabilité.
Un logiciel ne s'use pas pourtant sa maintenance absorbe une très grande partie des
coûts de son développement. Selon le Gartner Group, 60 % à 80 % du budget annuel de
développement d'applications IT (Information Technology) est consacré à la maintenance des
applications existantes. Le degré avec lequel un système est facile ou difficile à maintenir
n'est pas fixe, mais peut être influencé. Par conséquent, il est important que ce degré (qui n’est
rien d’autre que la maintenabilité du système) puisse être mesuré. L’IEEE (IEEE 610.12-90)
définit la maintenabilité comme l’aisance avec laquelle un logiciel peut être maintenu,
amélioré, adapté ou corrigé pour satisfaire aux exigences spécifiées. L’ISO/IEC définit la
maintenabilité comme l’une des caractéristiques de qualité (ISO9126-01). Les sous-
caractéristiques de la maintenabilité doivent être spécifiées, revues et contrôlées durant les
activités de développement du logiciel pour réduire les coûts de maintenance.
La norme ISO 9126 est un bon cadre de référence pour l’évaluation de la qualité du
produit logiciel, mais ne propose aucun modèle pour évaluer la maintenabilité par observation
directe de son code source. D’autre part, l’index de maintenabilité MI a été proposé pour
estimer la maintenabilité du logiciel, mais cette métrique ne fournit pas de traçabilité. Se
basant sur les limites des métriques, et en tenant compte des exigences minimales qui doivent
être remplies par un modèle de maintenabilité fondé sur l’analyse du code source, nous avons
élaboré un modèle, en l’occurrence le modèle MMP6_ISO9126, dans lequel un ensemble
bien choisi de mesures du code source sont liées aux caractéristiques de la maintenabilité
selon l’ISO 9126. Ce modèle est utilisé, par la suite, dans notre étude d’évaluation pour
estimer la maintenabilité de plusieurs applications IT.
Introduction
3
Ce mémoire est organisé en cinq (05) chapitres. Le premier chapitre traite de la
définition de la qualité des deux points de vue populaire et professionnelle, et décrit la gestion
de la qualité totale (TQM) en ce qui concerne la qualité des logiciels. Les référentiels
normatifs pour l’évaluation du produit logiciel tels que l’ISO 9126, l’ISO 14598 et l’ISO
25000 étant présentés brièvement.
Le chapitre (2) est une introduction à la théorie de la mesure ; des notions telles les
métriques logicielles, les échelles de mesure et la mesure du logiciel sont présentées. Compte
tenu de l’importance de la complexité du code source et son impact direct sur la qualité et le
coût du logiciel, une grande partie de ce chapitre lui est consacrée.
Le chapitre (3) présente une revue de la littérature sur les méthodes de mesure basées
sur le code source (utilisation des métriques statiques extraites du code). Les mesures
introduites dans ce chapitre concernent les deux aspects : la taille et la structure du
programme.
Dans le chapitre (4), nous avons passé en revue le processus d'évaluation du produit
logiciel selon les normes ISO 9126/ ISO 14598. D’autres processus d’évaluation, basés sur
ces normes, ont été présentés, à savoir ; W-process (ROB KUSTERS, JOS TRIENEKENS, THEO
BEMELMANS and AARNOUT BROMBACHER, Netherlands) et le Processus d’évaluation de la qualité
du logiciel (Yann-Gaël Guéhéneuc - Université de Montréal). Ces processus utilisent la méthode
GQM (qui dérive les mesures de logiciels à partir des questions de mesure et des objectifs) et
d’autres méthodes pour pallier les insuffisances constatées dans la norme.
Le chapitre (5) est une étude d’évaluation du produit logiciel en termes de
maintenabilité. Un modèle étant proposé et appliqué sur plusieurs logiciels développés avec
des technologies différentes.
La qualité du logiciel
5
Chapitre 1.
La qualité du logiciel
La qualité doit être définie et mesurée dans le but de l'améliorer. Pourtant, un
problème majeur en ingénierie et en gestion de la qualité, est que le terme «qualité» est
ambigu et souvent mal compris. Sa définition concrète est problématique comme le confirme
Garvin « la qualité est un concept extrêmement nébuleux car facile à visualiser mais
exaspérant à définir » [Garvin, 88]. La confusion est due à plusieurs raisons. Premièrement, la
qualité n'est pas une seule idée, mais plutôt un concept multidimensionnel. Les dimensions de
la qualité incluent l'entité d'intérêt, le point de vue sur cette entité, et les attributs de qualité de
cette entité. Deuxièmement, pour tout concept il existe des niveaux d'abstraction, quand on
parle de la qualité, certains font allusion à celle-ci dans son sens le plus large, tandis que
d’autres font allusion à son sens précis. Troisièmement, le terme «qualité» fait partie de notre
langage courant et les usages populaires et professionnels de celui-ci peuvent être très
différents.
1.1 Qualité: vues populaires
Un point de vue populaire de la qualité, est qu'elle est un bien immatériel. On peut en
discuter, la juger mais pas la mesurer de manière absolue. Des termes comme de bonne
qualité, de mauvaise qualité, très bon rapport qualité/prix, et la qualité de la vie illustrent la
façon dont les gens parlent de quelque chose de vague, dont ils n'ont pas l'intention de définir.
Ce point de vue reflète le fait que les gens perçoivent et interprètent la qualité de différentes
manières. Il est en contraste frappant avec la définition de la qualité dans son cadre
professionnel (Ingénierie de la qualité) : la qualité peut, et doit être définie de façon
opérationnelle, mesurée, contrôlée, gérée et améliorée.
Un autre point de vue populaire est que la qualité connote le luxe, la classe, et le goût.
Les produits chers, bien élaborés, et plus complexes sont considérés comme offrant un niveau
de qualité plus élevé que leurs homologues plus modestes. Selon ce point de vue, la qualité est
limitée à une catégorie de produits coûteux avec des fonctionnalités sophistiquées alors que
les produits simples, de bon marché ne peuvent guère être considérés comme des produits de
qualité.
La qualité du logiciel
6
1.2 Qualité: points de vue professionnels
Les idées fausses et les allusions qui font référence à une réalité souvent postulée,
considérée comme universelle, floue et mal définie ne contribuent pas à l'effort d'amélioration
de la qualité dans l’industrie. À cette fin, la qualité doit être décrite dans une définition
pratique. Crosby définit la qualité comme «la conformité aux exigences» [Crosby, 79]. Juran
et Gryna la définissent comme «l’aptitude à l'emploi » [Juran & Gryna, 70]. Ces deux
définitions sont liées et cohérentes, et ont été adoptées et utilisées par de nombreux
professionnels de la qualité.
La « conformité aux exigences » implique que les exigences doivent être clairement
indiquées de telle sorte qu'elles ne soient pas mal comprises. Puis, dans le processus de
développement et de production, les mesures sont prises régulièrement pour déterminer la
conformité à ces exigences. Les non-conformités sont considérées comme des défauts -
absence de qualité. Par exemple, une exigence (spécification) pour un poste radio peut être la
capacité de recevoir certaines fréquences au delà de 50 km de la source de diffusion. Si la
radio est incapable de recevoir de telles fréquences, alors elle ne répond pas aux exigences de
qualité et doit être rejetée. De même, si une Cadillac est conforme à toutes les exigences d'une
Cadillac, elle est donc une voiture de qualité. Si une Chevrolet est conforme à toutes les
exigences d'une Chevrolet, elle est aussi une voiture de qualité. Les deux voitures peuvent être
très différentes en style, performance et économie. Mais si les deux sont à la hauteur des
normes établies pour elles, alors les deux sont des voitures de qualité.
La définition «l’aptitude à l'emploi » ou encore « l'aptitude à l'usage » tient en compte les
exigences et attentes des clients, qui impliquent l’adaptation des produits et/ou des services à
leur utilisation. Depuis que les clients peuvent utiliser les produits de différentes manières,
cela signifie que les produits doivent posséder de multiples éléments d'aptitude à l’utilisation.
Selon Juran, chacun de ces éléments est une caractéristique de qualité et ils peuvent tous être
classés dans des catégories connues en tant que paramètres d'aptitude à l'utilisation. Les deux
paramètres les plus importants sont la qualité de la conception et la qualité de la conformité.
La qualité de la conception dans la terminologie populaire est connue sous le nom de
modèles, qui sont liés au spectre du pouvoir d'achat. Les différences entre ces modèles sont le
résultat des différentes conceptions. Par exemple, tous les modèles des voitures offrent à
La qualité du logiciel
7
l'utilisateur un service de transport. Toutefois, ces modèles diffèrent par la taille, le confort, la
performance, le style,…etc. En revanche, la qualité de la conformité est la satisfaction du
produit aux exigences de conception spécifiée.
Les deux définitions de la qualité (la conformité aux exigences et l’aptitude à
l'emploi), sont essentiellement similaires. La différence est que l'aptitude à l'emploi implique
un rôle plus important des besoins et attentes des clients.
1.2.1 Le rôle du client
Le rôle du client, tel qu’il est rattaché à la qualité, ne peut jamais être trop exagéré. Du
point de vue client, la qualité est la valeur perçue par le client du produit qu'il a acheté, basé
sur une variété de variables telles que son prix, sa performance, sa fiabilité et la satisfaction de
ce dernier. Dans le livre de John Guaspari « je la reconnais quand je la vois !»[Guaspari, 85],
il discutait de la qualité dans le contexte client [Guaspari, 88] comme suit:
Vos clients sont dans une position parfaite pour vous parler de la qualité, parce que c'est tout
ce qu'ils ont vraiment acheté. Ils n’ont pas acheté un produit. Ils ont acheté votre assurance
que leurs attentes pour ce produit seront satisfaites.
Et vous n'avez pas vraiment quelque chose à leurs vendre, que ces assurances. Vous n'avez
pas vraiment quelque chose d’autre à vendre, hormis la qualité.
De la définition d'un concept de haut niveau à la définition opérationnelle d'un produit,
de nombreuses étapes sont impliquées, dont chacune peut être vulnérable à des défauts. Par
exemple, pour atteindre l'état de conformité aux exigences, les exigences des clients doivent
d'abord être recueillies et analysées, les spécifications pour répondre à ces exigences doivent
être établies, et le produit doit être développé et fabriqué en conséquence. Dans chaque phase
du processus, des erreurs peuvent se produire qui affecteront la qualité du produit fini. Les
exigences peuvent être erronées (ce qui est particulièrement le cas pour le développement de
logiciels), le processus de développement et de fabrication peut être soumis à des variables
qui provoquent des défauts, et ainsi de suite. Du point de vue du client, la satisfaction après
l'achat du produit est l'ultime validation que le produit est conforme aux exigences et est apte
à être utilisé. Du point de vue du producteur, une fois les exigences sont spécifiées, le
développement et la fabrication du produit en conformité avec le cahier des charges est le
La qualité du logiciel
8
chemin pour atteindre la qualité. Habituellement, les mesures de base pour la qualité des
produits sont l'absence de défauts et une bonne fiabilité.
En raison de ces deux perspectives de la qualité (satisfaction du client comme l'ultime
validation de la qualité et le respect des exigences du producteur pour atteindre la qualité), la
définition de facto de la qualité se compose de deux niveaux. Le premier est la qualité
intrinsèque du produit, souvent sur le plan opérationnel limitée au taux de défauts du produit
et sa fiabilité. Cette définition étroite est appelée le " petit q " (q pour la qualité). La
définition élargie de la qualité comprend la qualité des produits, la qualité des processus et la
satisfaction du client, elle est appelée "grand Q". Cette approche à deux niveaux dans la
définition de la qualité est utilisée dans de nombreuses industries, y compris l'industrie
automobile, l'industrie informatique (logiciels et matériel), et l'industrie électronique grand
public.
Le concept à deux niveaux de qualité est censé former un cycle en boucle fermée: besoins des
clients exigences et spécifications produits conçus, développés et fabriqués
conformément aux exigences, tout en adoptant une démarche d'amélioration continue du
processus produit d'excellente qualité, ainsi qu'une bonne distribution et un bon service des
processus satisfaction totale du client. Cependant, ce n'est toujours pas le cas dans de
nombreuses industries, et en particulier avant la fin des années 1980 quand l'ère moderne de la
qualité a commencée. Les exigences du produit sont souvent exprimées sans prendre en
considération les besoins des clients, et la satisfaction du client n'a pas toujours été un facteur
dans la prise de décisions. Bien que le produit final soit conforme aux exigences, il peut ne
pas correspondre aux attentes des clients. Par conséquent, le rôle des clients devrait être
explicitement indiqué dans la définition de la qualité: la conformité aux exigences des clients.
1.3 La qualité du logiciel
Dans le domaine du logiciel, le sens le plus étroit de la qualité du produit est
généralement reconnu comme le manque de "bugs" dans le produit. Il est aussi le sens
fondamental de conformité aux exigences, parce que si le logiciel contient trop de défauts de
fonctionnement, les exigences de base de la fonction souhaitée ne sont plus remplies. Cette
définition est généralement exprimée de deux manières: le taux de défauts (par exemple, le
nombre de défauts par million de lignes de code source KLOC, ou par point de fonction FP,
La qualité du logiciel
9
ou autre unité) et la fiabilité (par exemple, le nombre de défaillances par heure de
fonctionnement, la durée moyenne de fonctionnement avant la première panne MTTF, ou la
probabilité de fonctionnement sans défaillance dans un délai déterminé). La satisfaction du
client est généralement mesurée par un taux de satisfaction à partir des enquêtes menées
auprès des clients. Pour réduire les préjugés, des techniques telles que les enquêtes dites
aveugles (blind surveys) où l'enquêteur et les clients ne se connaissent pas, sont généralement
utilisées. En plus de la satisfaction globale des clients du produit logiciel, des attributs
spécifiques de la qualité doivent être également satisfaits et mesurés. Par exemple, IBM
surveille la satisfaction de ses produits logiciels aux niveaux CUPRIMDSO1 (la capacité
[fonctionnalité], la facilité d'utilisation, la performance, la fiabilité, l’installabilité, la
maintenabilité, la documentation / l’information, le service, et de l'ensemble). Hewlett-
Packard se concentre sur FURPS2 (la fonctionnalité, la facilité d'utilisation, la fiabilité, la
performance et la facilité de maintenance). Autres sociétés utilisent les mêmes dimensions de
la satisfaction du client logiciel. Juran appelle ces paramètres les attributs de la qualité, ou les
paramètres d'aptitude à l'utilisation.
Pour accroître la satisfaction globale des clients ainsi que la satisfaction des différents
attributs de la qualité, ces attributs doivent être pris en compte lors de la planification et la
conception du logiciel. Toutefois, ces attributs ne sont pas toujours congruents les uns avec
les autres. Par exemple, plus la complexité fonctionnelle du logiciel est importante, plus il
devient difficile d'atteindre la maintenabilité. Selon le type du logiciel et les clients visés, la
pondération des différents facteurs est nécessaire pour les différents attributs de la qualité.
Pour les gros clients (Applications réseaux et traitement en temps réel) la performance et la
fiabilité peuvent être les attributs les plus importants. Pour les clients avec des systèmes
autonomes, la facilité d'utilisation, la facilité d’installation, et la documentation peuvent être
les attributs les plus importants. La figure 1.1 montre les relations possibles de certains
attributs de la qualité. Certaines relations s’entraident, d'autres sont négatives, et d'autres
encore ne sont pas claires, selon les types des clients et d'applications. Pour les logiciels grand
public, il est difficile de fixer les objectifs pour les différents attributs de la qualité et de
répondre aux exigences des clients.
1 CUPRIMDSO (capability [functionality], usability, performance, reliability, installability, maintainability,
documentation/information, service, and overall).
2 FURPS (functionality, usability, reliability, performance, and serviceability).
La qualité du logiciel
10
Compte tenu de ces discussions, la définition mise à jour de la qualité (c.-à-d conformité aux
exigences des clients) est particulièrement pertinente pour l'industrie du logiciel. Il n'est pas
surprenant que les erreurs de prescriptions constituent l'une des catégories de problèmes
majeurs dans le développement du logiciel. Selon Jones, 15% ou plus de tous les défauts du
logiciel sont des erreurs d’exigences [Jones, 92]. Un processus de développement qui ne tient
pas compte de la qualité des exigences est voué à produire des logiciels de mauvaise qualité.
Une autre vue de la qualité du logiciel est la qualité des processus par rapport à la
qualité du produit final. A partir des exigences du client à la livraison du produit logiciel, le
processus de développement est assez complexe et implique souvent une série d'étapes,
chacune avec des feed-back. Dans chaque étape, un livrable intermédiaire est produit pour un
utilisateur intermédiaire de la prochaine étape. Chaque étape reçoit également un livrable
intermédiaire de l'étape précédente. Chaque livrable intermédiaire a certains attributs de la
qualité qui affectent la qualité du produit final. Par exemple, la figure 1.2 montre une
représentation simplifiée du processus de développement du logiciel le plus courant, le
processus en cascade.
Figure 1.1. Relations entre les attributs logiciels - Exemple de CUPRIMDA
Expression du besoin
Spécifications
Conception
Développement
Tests
Maintenance
Figure 1.2. Représentation simplifiée du processus de développement en cascade
La qualité du logiciel
11
Curieusement, si l'on étend la notion de client dans la définition de la qualité en
incluant à la fois les clients externes et internes, la définition s'applique également aux
processus de la qualité. Si chaque étape du processus de développement répond aux exigences
de son utilisateur intermédiaire (l'étape suivante), le produit final ainsi développé répondra
aux exigences spécifiées. Cette déclaration, bien sûr, est une simplification de la réalité, parce
que dans chaque étape de nombreux facteurs existent qui influent sur la capacité de ce stade
pour satisfaire ses exigences. Pour améliorer la qualité au cours du développement, nous
aurons besoin de modèles du processus de développement, et pour le processus nous aurons
besoin de sélectionner et de déployer des méthodes et des approches spécifiques, et utiliser
des outils appropriés et des technologies. Enfin, nous aurons besoin de mesures des
caractéristiques et des paramètres de la qualité du processus de développement et ses étapes,
ainsi que des indicateurs et des modèles afin de s'assurer que le processus de développement
est sous contrôle et se dirige vers les objectifs de la qualité du produit.
1.4 Gestion de la qualité totale
Le terme gestion de la qualité totale TQM a été inventé en 1985 par le Naval Air
Systems Command pour décrire son approche de gestion de style japonais pour l'amélioration
de la qualité. C’est une démarche de gestion de la qualité dont l'objectif est l'obtention d'une
très large mobilisation et implication de tous les membres de l’organisation ou l'entreprise
pour parvenir à une qualité parfaite en réduisant au maximum les gaspillages et en améliorant
en permanence les éléments de sortie (outputs). Plusieurs méthodes spécifiques pour la mise
en œuvre de la philosophie TQM se trouvent dans les œuvres de Crosby (1979), Deming
(1986), Feigenbaum (1961, 1991), Ishikawa (1985), et Juran et Gryna (1970).
Depuis les années 1980, de nombreuses entreprises américaines ont adopté l'approche
TQM à la qualité. Le Malcolm Baldrige National Quality Award (MBNQA), établi par le
gouvernement des États-Unis en 1988, souligne l'acceptation d'une telle philosophie et le style
de gestion. L'adoption de la norme ISO 9000 comme norme de gestion de la qualité par la
communauté européenne et l'acceptation de ces normes par le secteur privé américain ces
dernières années illustrent en outre l'importance de la qualité dans l’environnement des
affaires d'aujourd'hui. Dans l'industrie informatique et électronique, des exemples de mise en
œuvre réussie de TQM incluent, le contrôle de la qualité totale de Hewlett-Packard (TQC), la
stratégie Six Sigma de Motorola, et les marchés émergents d’IBM axés sur la qualité. En fait,
La qualité du logiciel
12
Motorola a remporté le premier prix MBNQA en 1988 et la Division AS/400 d'IBM l’a
remporté en 1990 à Rochester, Minnesota.
Le contrôle de la qualité totale de Hewlett-Packard se concentre sur des domaines clés
tels que l'engagement de gestion, le leadership, l'orientation client, la participation totale, et
l'analyse systématique. Chaque secteur a des stratégies et des plans pour l'amélioration de la
qualité, l'efficacité et la réactivité, avec l'objectif final de parvenir au succès à travers la
satisfaction du client [Shores, 89]. Dans le domaine de développement du logiciel, le
programme (SQPA) Software Quality and Productivity Analysis (Zimmer 1989) est l'une des
approches pour améliorer la qualité.
La méthode Six Sigma se base sur une démarche fondée à la fois sur la voix du client
(enquêtes, etc.) et sur des données mesurables et fiables. Six Sigma n'est pas seulement une
mesure du niveau de la qualité; inhérente à la notion d'amélioration de conception de produits
et la réduction de la variabilité dans les processus [Harry & Lawson, 92]. Elle a été appliquée
en premier lieu à des procédés industriels avant d'être élargie à tous types de processus,
surtout administratifs, logistiques, commerciaux et d'économie d'énergie.
«Le client est l'arbitre final» est la clé de la stratégie des marchés d'IBM axés sur la
qualité. La stratégie comprend quatre initiatives: l’élimination des défauts, la réduction des
temps de cycle, la satisfaction des clients et des partenaires, et l’adhérence à la discipline
d’évaluation BALDRIGE.
En dépit des variations dans sa mise en œuvre, les éléments clés d'un système TQM
peuvent être résumés comme suit:
Orientation client: L'objectif est d'atteindre la satisfaction totale du client.
L'orientation client comprend l'étude des besoins et désirs des clients, la collecte des
exigences des clients, et enfin la mesure de la satisfaction des clients ;
Processus: L'objectif est de réduire la variabilité dans les processus et de parvenir à
une amélioration continue des processus. Cet élément comprend à la fois le processus
de développement d’un produit ou d’un service. Grâce à l'amélioration des processus,
la qualité des produits se voit améliorée ;
Une culture de la qualité: L'objectif est de créer et d’élargir une culture de la qualité à
tous les membres de l'entreprise : le leadership, l’engagement de la direction,
l’implication totale du personnel, la responsabilisation des employés, et d'autres
facteurs sociaux, psychologiques et humains ;
La qualité du logiciel
13
Mesure et analyse: L'objectif est de favoriser l'amélioration continue de tous les
paramètres de la qualité par un système de mesure axé sur les buts.
En outre, une organisation qui pratique TQM doit avoir une direction, doit se concentrer sur
les infrastructures, la formation et l'éducation, et doit avoir une planification stratégique de la
qualité.
La figure 1.3 est une représentation schématique des éléments clés de TQM. De toute
évidence, la mesure et l'analyse sont des éléments fondamentaux pour mesurer l'amélioration
continue.
Plusieurs structures organisationnelles avaient été proposées pour améliorer la qualité
qui peut être utilisée pour appuyer la philosophie TQM. Des exemples spécifiques
comprennent Plan-Do-Check-Act (Deming, 1986; Shewhart, 1931), Quality Improvement
Paradigm/ Experience Factory Organization (Basili, 1985, 1989; Basili et Rombach, 1987,
1988; Basili et al, 1992.), Software Engineering Institute SEI Capability Maturity Model
CMM ou Modèle de Maturité des Aptitudes (Humphrey, 1989; Radice et al, 1985.), et le
Lean Enterprise Management - système d'organisation industrielle (Womack et al, 1990.).
Plan-Do-Check-Act est basé sur un cycle de rétroaction pour optimiser un processus ou une
ligne de production. Il utilise des techniques, telles que des boucles de rétroaction et le
contrôle statistique de la qualité, pour améliorer et construire des modèles prédictifs du
produit. Le processus consiste à répéter sans cesse la planification, la réalisation, la
Figure 1.3. Éléments clés de la gestion de la qualité totale TQM [Stephen, 02]
La qualité du logiciel
14
vérification et la correction, de sorte que les modèles de données peuvent être construits et
permettent de prédire les résultats du processus.
Quality Improvement Paradigm/ Experience Factory Organization vise à construire une
organisation qui s'améliore continuellement, en fonction de l’évolution de ses objectifs et une
évaluation de son statut par rapport à ces objectifs. L'approche utilise des évaluations internes
par rapport aux objectifs propres à l'organisation et des techniques telles que Goal/ Question/
Metric GQM, la construction de modèles, et l’analyse qualitative/quantitative pour améliorer
le produit à travers le processus. Les six étapes fondamentales du paradigme de l'amélioration
de la qualité sont (1) caractériser le projet et son environnement, (2) fixer les objectifs, (3)
choisir le processus approprié, (4) exécuter le processus, (5) analyser les données, et (6)
capitaliser l’expérience en vue d'une réutilisation ultérieure. Factory Experience Organisation
sépare le développement de produits de l'activité de capitaliser l'expérience. Parmi les bases
de cette approche, la nécessité d'apprendre à travers les multiples projets de développements.
Le CMM Capability Maturity Model est un modèle d'évaluation et d'évolution des processus
logiciels. Il a été élaboré en 1987 par Watts Humphrey, du SEI (Software Engineering
Institute) de l'université Carnegie Mellon de Pittsburgh (Pennsylvanie). Il comporte cinq
niveaux de maturité : initial, reproductible, défini, maîtrisé et optimisé. Ces niveaux
constituent autant d'étapes sur le chemin menant à des processus matures, c'est-à-dire
conformes à un ensemble de bonnes pratiques observées à travers le monde dans des
entreprises réputées pour bien gérer leurs processus. La conformité au modèle CMM est
notamment requise pour contracter avec le département américain de la défense.
Chacun des cinq niveaux de maturité est divisé en plusieurs secteurs clés. A titre d'exemples,
en voici certains pour les niveaux de 2 à 5 (le niveau 1 n'en contient pas) :
- Niveau 2 : planification de projet, assurance qualité.
- Niveau 3 : définition des processus, ingénierie des produits logiciels.
- Niveau 4 : gestion quantitative des processus et de la qualité logicielle.
- Niveau 5 : gestion des changements technologiques et des changements de processus.
Chaque secteur clé est décrit par un ensemble de caractéristiques communes qu'il convient de
remplir si l'on veut satisfaire aux exigences d'un secteur clé. Les caractéristiques communes
contiennent des pratiques clés dont la réalisation est nécessaire pour atteindre les objectifs.
Pour passer d'un niveau à l'autre, il faut obtenir la certification du SEI.
La qualité du logiciel
15
Le CMM évolue et a récemment donné naissance au CMMI Capability Maturity Model
Integrated qui concerne, outre l'aspect logiciel, les aspects « systèmes » des développements.
Le CMM se décline sinon en quatre sous-modèles. Le SW-CMM (SW signifiant software),
modèle le plus connu et qui s'applique aux logiciels. Le SA-CMM (Software Acquisition
CMM) concerne la normalisation des processus d'acquisition des progiciels. Le SE-CMM
(Systems Engineering CMM) est propre à l'ingénierie système tandis que l'IPD-CMM
(Integrated Product Development CMM) touche la conception et la production de produits.
Enfin, le P-CMM semble lui aussi émerger, il s'applique à la gestion du personnel
[journaldunet.com].
Lean Enterprise Management est basée sur le principe de la concentration de la production
sur la «valeur ajoutée» des activités et l'élimination ou la réduction des «non-valeur ajoutée»
des activités. L'approche a été utilisée pour améliorer la production des usines. L'objectif est
de créer des logiciels avec le minimum nécessaire des activités, puis d'adapter le processus
aux exigences du produit. L'approche utilise des concepts tels que la gestion de la technologie,
une organisation décentralisée, la gestion de la qualité, l'intégration du fournisseur et des
clients, etc. l’idée de base de cette approche est l'hypothèse que le processus peut être adapté
aux classes de problèmes.
1.5 La crise du logiciel
Dans le début des années 80, une étude du DOD (U.S Department of Defense) sur 9
gros projets montre que :
2% des logiciels livrés sont utilisés directement ;
3% des logiciels livrés sont utilisés après quelques modifications mineures ;
19% des logiciels livrés sont utilisés après de fortes modifications ;
47% des logiciels livrés ne sont jamais utilisés ;
29% sont payés et pas livrés.
Et depuis, les logiciels à concevoir sont beaucoup plus complexes: (taille, type, architecture,
portabilité, standardisation, intégration, …)
Un phénomène de baisse des prix du matériel informatique et d'augmentation des prix
du logiciel, accompagné d'une baisse de la qualité des logiciels a été identifié à la fin des
années 1960 et nommé « la crise du logiciel ». Selon Alfred [Alfred, 00], cette crise
s'apparente aujourd'hui à une maladie chronique de l'industrie du logiciel, dont les symptômes
sont les suivants:
La qualité du logiciel
16
Le coût de développement d'un logiciel est presque impossible à prévoir et le délai de
livraison n'est que rarement respecté. On cite ainsi dans la littérature des dépassements
moyens du coût budgété et du délai prévu respectivement de 70% et 50% ;
La qualité du logiciel livré est souvent déficiente. Le produit ne satisfait pas les
besoins de l'utilisateur, il consomme plus de ressources que prévu et il est à l'origine
de pannes ;
La maintenance du logiciel est difficile, coûteuse et souvent à l'origine de nouvelles
erreurs. Mais en pratique, il est indispensable d'adapter les logiciels car leurs
environnements d'utilisation changent et les besoins des utilisateurs évoluent ;
Il est rare qu'on puisse réutiliser un logiciel existant ou un de ses composants pour
confectionner un nouveau système, même si celui-ci comporte des fonctions
similaires. Tout amortissement sur plusieurs projets est ainsi rendu impossible.
D’après le Standish Group [standishgroup.com], le coût du logiciel en 1965 représentait
50% du coût total d'un système informatique. En 1985 la part du logiciel est de 80% et les
coûts dus à la correction des défauts dans les logiciels (maintenance) représentent jusqu'à trois
quarts du coût total d'acquisition, un excédent dû uniquement à la mauvaise qualité du logiciel
lors de sa livraison.
Selon une étude réalisée en 1994 toujours par le Standish Group:
16% de projets sont réussis (le projet a été achevé dans les délais, dans le cadre du
budget fixé, et est conforme aux caractéristiques et fonctionnalités spécifiés) ;
31% de projets sont ratés (le projet a été abandonné pendant le développement) ;
53% des projets créés sont une réussite mitigée : le logiciel est opérationnel,
cependant le délai de livraison n'a pas été respecté, les budgets n'ont pas été tenus, et
certaines fonctionnalités ne sont pas disponibles. Le dépassement des coûts est en
moyenne de 90%, et celui des délais de 120%, et la qualité moyenne est estimée à
60%.
Dans le tableau 1, on reprend les résultats des enquêtes successives menées par le Standish
Group. Le tableau 2 donne l’amélioration des projets mitigés entre 1994 et 2000.
La qualité du logiciel
17
1.6 Raisons du manque de qualité des logiciels
Perrin a identifié dans son ouvrage [Perrin, 01] quelques raisons de la fiabilité très
limitée et de la non-qualité des logiciels que nous présentons ci-après sans qu’un ordre de
prépondérance puisse être dégagé.
L’aspect immatériel du logiciel constitue une de ces causes importantes et typiques. Le
logiciel n’est, en effet, observable que par ses différentes formes de présentation dont les plus
usuelles sont le code source, l’exécution du programme, ou les différentes formes de
documentation utilisées avant, pendant et après la production du programme. L’explosion
combinatoire des comportements possibles des logiciels (actions de l’utilisateur ou
événements extérieurs) rendent la plupart du temps une détection exhaustive des erreurs
impossible avant utilisation. En construisant des jeux de test pertinents, on peut améliorer
grandement la détection des bugs, mais il reste généralement impossible de garantir à 100%
que toutes les situations « exotiques » ont été prévues et validées.
Une autre raison majeure est la non-séparation claire entre les macro et micro
décisions et donc macro et micro erreurs. S’il n’est pas possible d’arrêter un train avec une
allumette, il est tout à fait possible par une simple modification d’une instruction d’arrêter
l’exécution d’un programme tout entier (un phénomène largement exploité par les virus
informatiques). Des exemples célèbres comme celui de l’explosion en vol du lanceur Ariane
en sont malheureusement de flagrants révélateurs.
On ne se trouve pas non plus dans le contexte classique où l’effort (coût) de
destruction est proportionnel à l’effort de construction (d’un pont par exemple). En effet, si la
destruction d’un pont coûte approximativement le même montant que sa construction, la
destruction d’un programme ne coûte rien, il suffit de s’asseoir sur la disquette ou de rayer le
CD-ROM, ou plus subtilement d’apporter une modification à l’environnement du logiciel
(système d’exploitation, périphérique…) voir de le confronter à un virus informatique.
Un logiciel ne s’use pas, il ne peut donc pas exister d’erreurs dues à un
fonctionnement trop fréquent. Les causes de dysfonctionnement doivent être cherchées au
niveau de la conception voir des spécifications ou du cahier des charges.
La qualité du logiciel
18
Enfin, pour être considéré comme produit de qualité par l'usager, un logiciel doit
répondre aux besoins exprimés explicitement par l'usager aussi bien qu'aux besoins implicites
(non exprimés). Or les vœux implicites évoluent avec le marché, et il arrive bien souvent que
des vœux implicites des usagers ne soient pas connus des ingénieurs logiciels [Dugerdil, 05].
1.7 Evaluation de la qualité du logiciel : référentiels normatifs
L’évaluation consiste fondamentalement à comparer ce qui est observé à ce qui est
existant ou désiré afin de porter un jugement de valeur sur son état. Plus d’un point de vue est
nécessaire.
Le logiciel, bien que produit relativement récent n’échappe pas au champ
d’investigation des instances normatives. Les normes ISO 9000 relatives au management de la
qualité sont applicables à tout organisme, y compris les organismes qui conçoivent, fabriquent
et vendent du logiciel. Les instances internationales ont aussi rédigé des normes spécifiques,
adaptées pour l’évaluation du logiciel dont nous résumons les principales. Il s’agit
essentiellement des normes ISO/IEC 9126 et ISO/IEC 14598, dont l’une (9126) définit les
caractéristiques qualité du logiciel, et l’autre (14598) montre comment ces caractéristiques
peuvent être utilisés pour l’évaluation de la qualité du produit logiciel. L’utilisation de ces
deux normes complémentaires a ensuite donné naissance à la norme ISO 25000 ou SQuaRE.
1.7.1 Les 11 caractéristiques de McCall (1977)
McCall a définit en 1977 les 11 principales caractéristiques (ou facteurs) à utiliser
pour analyser la qualité du logiciel. Les caractéristiques sont les grands axes à vérifier pour
savoir si le logiciel est de bonne ou mauvaise qualité. Pour l’analyse, on utilise des données
quantifiables (métriques) que nous rattacherons, par la suite, aux différents facteurs.
Tableau 3 - Les 11 caractéristiques de McCall
Adaptabilité Maniabilité Testabilité
Conformité Réutilisabilité Interopérabilité
Efficacité Sécurité Portabilité
Maintenabilité Robustesse
Toutefois, le modèle de McCall est critiqué, car il demande un très grand nombre de
métriques pour être pris dans son intégralité. C’est ainsi qu’apparaît la norme ISO 9126
(définition de 06 caractéristiques de qualité).
La qualité du logiciel
19
1.7.2 Norme ISO/IEC 9126 :1991
La norme ISO/IEC 9126, relative à « l’évaluation des produits logiciels -
Caractéristiques de qualité et directives d’utilisation », a été publiée par l’AFNOR en octobre
1992 (indice de classement Z 67-133). Cette norme constitue le modèle qualité pour les
produits logiciels. Elle contient deux parties, l’une définit les six (06) caractéristiques qualité
et vingt et une sous- caractéristiques qualité, constituant les bases pour l’évaluation de la
qualité des produits logiciels. L’autre les quatre (04) caractéristiques définissant la qualité du
produit logiciel en cours de son utilisation.
Caractéristiques et sous- caractéristiques qualité du logiciel
Tableau 4 – Caractéristiques et sous- caractéristiques qualité du logiciel (d’après la norme ISO/IEC 9126 :1991)
Caractéristiques Sous- caractéristiques
Capacité fonctionnelle
Capacité du logiciel à proposer des fonctionnalités couvrant les besoins spécifiées et implicites des utilisateurs.
— aptitude ;
— exactitude ;
— interopérabilité ;
— conformité réglementaire ;
— sécurité.
Fiabilité
Capacité du logiciel à garder le niveau de performance spécifié durant son utilisation.
— maturité ;
— tolérance aux fautes ;
— possibilité de récupération.
Facilité d’utilisation
Facilité d'utilisation, d'apprentissage, de prise en main et niveau d'attractivité du logiciel.
— facilité de compréhension ;
— facilité d’apprentissage ;
— facilité d’exploitation.
Rendement (Efficacité)
Capacité du logiciel à atteindre les performances spécifiées par rapport au niveau d'utilisation des ressources.
— comportement vis-à-vis du temps ;
— comportement vis-à-vis des ressources.
Maintenabilité
Facilité de modification du logiciel en termes de correction, amélioration ou d'adaptation à un changement d'environnement.
— facilité d’analyse ;
— facilité de modification ;
— stabilité ;
— facilité de tests.
Portabilité
Capacité d'adaptation du logiciel dans un environnement spécifié à un autre, sans que l'utilisateur n'ait à faire d'autres actions que celles données par le logiciel pour réaliser ce changement.
— facilité d’adaptation ;
— facilité d’installation ;
— conformité aux règles de portabilité ;
— interchangeabilité.
La qualité du logiciel
20
Qualité d’utilisation
La qualité d'utilisation du logiciel est la capacité du logiciel à permettre aux
utilisateurs d’atteindre les objectifs spécifiés avec efficacité, productivité, sécurité, et
satisfaction dans un contexte d’utilisation spécifié (Figure 1.4). Elle apparaît comme une
combinaison des 06 caractéristiques qualité lorsque le produit est en cours d’utilisation dans
un contexte bien déterminé.
Tableau 5 – Caractéristiques de la qualité du logiciel en cours d’utilisation
Efficacité Capacité du logiciel à permettre à l'utilisateur d'atteindre l'objectif spécifié avec précision et complétude dans un contexte d'utilisation spécifié.
Productivité Capacité du logiciel à permettre à l'utilisateur de ne pas dépenser que le minimum de ressources nécessaires pour atteindre l'objectif spécifié en fonction du niveau d'efficacité dans un contexte d'utilisation spécifié.
Sécurité Capacité du logiciel à présenter un niveau de risque acceptable dans un contexte d'utilisation spécifié.
Satisfaction Capacité du logiciel à satisfaire les utilisateurs dans un contexte d'utilisation spécifié.
La norme offre ainsi une terminologie commune entre les utilisateurs et leurs fournisseurs
pour la définition des exigences et l’évaluation de la qualité du produit et définit des séries de
mesures pour chacune de ces caractéristiques [Pinet ,01] & [Laudrel, 08].
1.7.3 Norme ISO/IEC 14598 :1999
Cet ensemble normatif constitue le modèle d’évaluation de produits logiciels et
s’appuie sur le cadre de référence des caractéristiques qualité définies dans les normes
ISO/IEC 9126. Il regroupe plusieurs visions d’évaluations en fonction des besoins du
commanditaire de l’évaluation (acquéreur, développeur, évaluateur). Les différents documents
disponibles sont :
Aperçu général (ISO/IEC 14598-1) ;
Planification et gestion (ISO/IEC 14598-2) ;
Procédés pour développeurs (ISO/IEC 14598-3) ;
Procédés pour les acquéreurs (ISO/IEC 14598-4) ;
Procédés pour les évaluateurs (ISO/IEC 14598-5) ;
Documentation des modules d’évaluation (ISO/IEC 14598-6).
La qualité du logiciel
21
L’originalité de cette norme réside dans la structuration du processus d’évaluation, présentée
dans le tableau 4, et qui va servir de guide méthodologique.
Déroulement d’une évaluation (d’après la norme ISO/IEC 14598)
Étape Action
1 Établir :
— les exigences ;
— les responsabilités du demandeur ;
— les responsabilités de l’évaluateur.
2 Analyser des exigences de l’évaluation.
3 Spécifier l’évaluation.
4 Concevoir l’évaluation.
5 Exécuter l’évaluation.
6 Conclure l’évaluation.
L’évaluation se pratique en suivant des métriques définies dans le référentiel. Les valeurs
observées lors du « mesurage » sont comparées aux valeurs standard définies ou aux plages de
valeurs tolérées. En fonction des résultats obtenus, l’évaluateur tirera les conclusions de
l’évaluation qui s’imposent.
En matière de qualité du logiciel, l’étalon3 utilisé pour effectuer des mesures dans le cadre
d’une évaluation, est celui du modèle de produit logiciel (ISO/IEC 9126) avec ses
caractéristiques et sous-caractéristiques [Pinet, 01].
1.7.4 SCOPE (Software CertificatiOn Programme in Europe) projet européen ESPRIT
La technologie d'évaluation et de certification de la qualité du produit logiciel est le
résultat principal de SCOPE projet européen ESPRIT. Les principales questions étudiées sont
les suivantes:
L'importance croissante du logiciel dans tous les secteurs de l'économie et la
préoccupation croissante au sujet du coût de la non-conformité aux exigences;
L'harmonisation continue des règles techniques en Europe qui nécessitent une
évaluation du produit logiciel et une technologie de certification matures;
La demande de clarification dans les relations client/fournisseur qui serait facilité par
une large utilisation des clauses quantitative de la qualité dans les contrats.
3 Un étalon est une réalisation de la définition d'une grandeur donnée, avec une valeur déterminée et une incertitude de
mesure associée, utilisée comme référence. JCGM - Joint Committee for Guides in Metrology, « Vocabulaire international
de métrologie — Concepts fondamentaux et généraux et termes associés (VIM) », 2008.
La qualité du logiciel
22
SCOPE le projet ESPRIT a commencé en Mars 1989 et a pris fin en Juin 1993. Avec
un consortium composé de 12 partenaires et 4 partenaires associés de 8 pays de la CE et
l'AELE (Association Européenne de Libre-Échange), ils ont développé la méthodologie et la
technologie associée à l'évaluation de produits logiciels et de certification. L'accent a été mis
sur l'expérimentation des techniques reconnues à travers plus de 20 études de cas industriels.
L'approche choisie par SCOPE consiste à utiliser les techniques de mesure et de les
combiner afin d'évaluer les produits logiciels. La notion d'un produit logiciel a été considérée
dans son sens le plus large: elle comprenait tout document résultant du processus de
développement, tels que la documentation utilisateur, le code exécutable, le code source ou
les produits intermédiaires, mais aussi toutes les traces, tels que les cas de test, les rapports
d'examen ou le plan qualité.
La philosophie SCOPE consiste à évaluer la conformité du produit aux exigences
indiquées, c à d pour chaque caractéristique de qualité définie dans la norme ISO 9126. Pour
démontrer l'applicabilité de la méthode proposée, deux campagnes d'expérimentation ont été
réalisées avec 6 et 21 études de cas, respectivement. Les études de cas couvraient un large
éventail de domaines d'application (traitement de données, temps réel, les
télécommunications, les réseaux informatiques, les systèmes embarqués ...).
Le projet SCOPE défini un processus d'évaluation encapsulé dans une procédure
d'évaluation en cinq étapes, qui a été soumis à la normalisation internationale et a évolué dans
le guide de l'évaluateur. Deux des six parties de la norme ISO14598 sont directement issues
des résultats du projet SCOPE.
Les fondements de ce processus d'évaluation sont les niveaux d'évaluation et les
modules d'évaluation. SCOPE a choisi de définir les niveaux d'évaluation au moyen des
techniques d'évaluation pertinentes classées des plus indulgentes (niveau D) aux plus strictes
(niveau A). Les niveaux d'évaluation peuvent être choisis de façon indépendante pour
chacune des caractéristiques de la qualité. Lorsque les risques augmentent en raison de la non-
conformité du produit aux exigences relatives à une caractéristique de la qualité, un niveau
plus strict devrait être choisi. Par exemple, les relations entre les risques et les niveaux à
sélectionner en considérant les aspects de la sécurité peuvent être les suivantes:
La qualité du logiciel
23
niveau D: Petits dégâts à la propriété, pas de risque pour les personnes.
niveau C: Dommages des biens, peu de personnes touchées.
niveau B: Menace pour les vies humaines.
niveau A: Beaucoup de personnes tuées.
Les modules d'évaluation documentent quelles sont les métriques et les techniques liées à
l'évaluateur mises à sa disposition. Ce concept de module d'évaluation est utile pour fournir à
l'évaluateur des packagings prêts à l'emploi, qui décrivent la technique d'évaluation, les
conditions de son utilisation, le standard à utiliser pour son application et le résultat qu'elle
peut fournir. Ce concept a l'avantage de permettre des évaluations reproductibles et facilite les
évolutions (le cadre doit être capable d'évoluer avec l’évolution des techniques d'évaluation et
les nouvelles pratiques de développement logiciel qui apparaissent).
La faisabilité et la rentabilité d'une évaluation dépendent de la disponibilité des
techniques d'évaluation appropriées. L'approche choisie par SCOPE est de mettre en pratique
les techniques d'évaluation qui ont déjà fait leurs preuves plutôt que d'essayer de développer
de nouvelles techniques. Pour diminuer la subjectivité d'un résultat, l'objectif était de rendre
les techniques d'évaluation produisant des informations quantitatives. Le tableau ci-dessous
propose quelques techniques d'évaluation pour les différents niveaux:
Tableau 6 - Techniques SCOPE : Choix des techniques pour chaque niveau
Niveau D Niveau C Niveau B Niveau A
Capacité fonctionnelle
test fonctionnel (boîte noire)
"+" inspection des documents (listes de contrôle)
"+" test des composants
"+" preuve formelle
Fiabilité facilités des langages de programmation
"+" analyse de la tolérance aux fautes
"+" modèle de croissance de la fiabilité
"+" preuve formelle
Facilité d'utilisation
inspection des interfaces utilisateur
"+" conformité aux normes sur les interfaces
"+" test en laboratoire "+" modèle mental de l'utilisateur
Rendement mesurage du temps d'exécution
"+" test avec bancs d'essais (benchmarks)
"+" complexité algorithmique
"+" analyse des performances
Maintenabilité inspection des documents (listes de contrôle)
"+" analyse statique "+" analyse du processus de développement
"+" évaluation de la traçabilité
Portabilité analyse de l'installation
"+" conformité avec les règles de programmation
"+" évaluation des contraintes de l'environnement
"+" évaluation de la conception des programmes
[cse.dcu.ie/essiscope]
La qualité du logiciel
24
1.7.5 Deuxième génération de standards de qualité – Norme ISO/IEC 25000:2005 ou
SQuaRE (Ingénierie du logiciel - Exigences de la qualité du produit logiciel et évaluation)
La norme ISO SQuaRE (Software Quality Requirements and Evaluation) offre un
cadre pour l’intégration des évolutions des normes ISO 9126 et ISO 14598. Elle donne une
référence à la définition des exigences qualité d’un logiciel (basée sur la norme ISO 9126) et à
la manière dont sera évaluée la qualité du logiciel par rapport à cette référence (basée sur la
norme ISO14598). Ella a pour objectifs de répondre aux besoins des utilisateurs
(développeurs, évaluateurs, acquéreurs), d’unifier les documents normatifs couvrant les trois
processus qualité (Spécification des exigences, Mesure, Evaluation), de fournir un support à
l’aide d’instrument d’ingénierie qualité, et d’inclure des critères pour spécifier les exigences
et leurs évaluations.
La stratégie développée pour concevoir SQuaRE consiste en la :
Fusion des deux séries de standards ISO /IEC 9126 et ISO /IEC 14598 ;
Introduction d’une nouvelle organisation des standards ;
Introduction d’un modèle général de références;
Introduction des guides utilisateur détaillés ;
Introduction des standards sur les «primitives de mesure » ;
Introduction d’un standard sur les exigences qualité ;
Introduction des guides sur la manière d’appliquer le standard ;
Coordonner et harmoniser le modèle de mesure logiciel avec la norme ISO 15939
(ISO/IEC-15939 : Ingénierie du logiciel — Méthode de mesure des logiciels).
L’architecture SQuaRE préconise les 4 étapes suivantes : (1) Fixer les exigences de la
qualité ; (2) Etablir un modèle de la qualité ; (3) Fixer les métriques de la qualité ; (4)
Conduire les évaluations.
SQuaRE comprend cinq (05) divisions comme illustré dans la figure 1.4.
Figure 1.4. Organisation des normes SQuaRE
La qualité du logiciel
25
SQuaRE a été retenu par le SEI pour l'associer aux objectifs de l'amélioration des
performance de processus du CMMI [cse.dcu.ie/essiscope]. Lors de la rédaction de ce
mémoire, certaines normes de la série ISO/IEC 25000 (par exemple, ISO/IEC 25042, 25043
et 25044) sont toujours en instance de publication par l’ISO.
1.7.6 CISQ
Les deux acteurs influents du génie logiciel, Carnegie Mellon SEI (Software
Engineering Institute) et l'OMG (Object Management Group), ont crée le CISQ
(Consortium of IT Software Quality) en 2009, en se basant sur la nouvelle norme ISO 25000.
Développer un étalon standard de points de contrôle pour mesurer la qualité des gros
systèmes n-tiers4. C'est le défi qu'ont décidé de relever l'institut d'ingénierie logicielle de
Carnegie Mellon SEI et l'OMG à travers le CISQ. Leur objectif est de définir dans un
standard unique un ensemble de métriques pour mesurer finement la qualité logicielle, puis
proposer à terme des labels et certifications. Un projet qui vient combler un manque sur le
marché.
Ces deux acteurs du génie logiciel, très actifs dans la qualité des processus, tentent de
fédérer les grands intégrateurs, éditeurs et outsourceurs autour de la qualité des
développements sur des systèmes multi-tiers. Soit en environnement hautement hétérogène,
où s'entremêlent les technologies multi-vendeurs et de multiples langages de programmation
différents. Et où les développements peuvent également être externalisés. C'est pour adresser
cette complexité grandissante des systèmes, garantir un ensemble cohérent et limiter les
risques que le CISQ a été créé.
D’après le site web du CISQ (http://www.it-cisq.org), la publication du standard
“Initial draft of IT Software Quality Standard” a vu le jour le 4e trimestre de l’année 2010, et
la première licence d’évaluation IT de la qualité du logiciel “Initial licensing of IT software
quality evaluation service providers” devrait voir le jour fin 2011 [lemagit.fr].
4 un système n-tiers est un système réparti entre deux ou plusieurs ordinateurs distincts dans un réseau distribué.
La qualité du logiciel
26
Conclusion
Ce chapitre traite de la définition de la qualité des deux points de vue populaire et
professionnelle, et décrit la gestion de la qualité totale (TQM) en ce qui concerne la qualité
des logiciels. Du point de vue populaire, la qualité est un certain type de choses qui ne
peuvent être quantifiées: « je la reconnais quand je la vois !». Du point de vue professionnel,
la qualité est définie comme «la conformité aux exigences des clients » ou encore « l'aptitude
à l'usage ». Dans le domaine du logiciel, ainsi que dans d'autres industries, la définition de
facto de la qualité opérationnelle se compose de deux niveaux: la qualité intrinsèque du
produit (petit q) et la satisfaction des clients (grands Q).
La philosophie TQM vise le succès à long terme en reliant la qualité à la satisfaction
du client. En dépit des variations dans sa mise en œuvre, un système TQM comprend quatre
principaux éléments communs: (1) l'orientation client, (2) l'amélioration des processus, (3)
côté humain de la qualité, et (4) mesure et analyse.
Il n'est pas surprenant que la définition de la qualité professionnelle s'inscrit
parfaitement dans le contexte de TQM. Cette définition est étroitement corrélée avec les deux
premiers éléments de la TQM (orientation client et l'amélioration des processus). Pour
atteindre la qualité, tous les éléments TQM doivent absolument être abordés.
En informatique et en particulier en génie logiciel, la qualité logicielle est une
appréciation globale d'un logiciel, basée sur de nombreux indicateurs (Caractéristiques de la
qualité indiquées dans la norme ISO/IEC 9126). Le sens le plus étroit de la qualité du produit
logiciel est généralement reconnu comme le manque de "bugs" dans le produit. Il est aussi le
sens fondamental de conformité aux exigences, parce que si le logiciel contient trop de
défauts de fonctionnement, les exigences de base de la fonction souhaitée ne sont pas
remplies. Cette définition est généralement exprimée de deux manières: le taux de défauts et
la fiabilité. En plus de la satisfaction globale des clients, des attributs spécifiques de la qualité
tels que la complétude des fonctionnalités, la précision des résultats, la facilité d’utilisation,
l'extensibilité, la compatibilité et la portabilité, l'intégrité des informations qu'il contient,...etc.,
doivent être également satisfaits et mesurés.
La qualité du logiciel
27
Les problèmes de qualité des logiciels, connus depuis les années 1960, sont par
ailleurs à l'origine du génie logiciel : la science de la création de logiciels, y compris toutes les
difficultés qui y sont liées - respects des coûts, des délais, du cahier des charges et du niveau
de qualité [Marylène & Medard, 02]. L’aspect immatériel du logiciel constitue l’une des
causes importantes et typiques de manque de qualité. Les seules représentations observables
du logiciel sont le code source, l'interface utilisateur et la documentation (spécification). La
quantité du code source (nombre de lignes) est rarement connue, ce qui entraîne souvent une
sous-estimation de la complexité du logiciel. Une autre raison est qu'il n'y a pas de lien entre
un défaut mineur et majeur, et une modification mineure ou majeure. Et l'effort de
détérioration d'un logiciel n'est pas proportionnel à l'effort de construction sans oublier la
combinaison des différentes conditions de son utilisation (l’environnement).
Le logiciel, bien que produit relativement récent n’échappe pas au champ
d’investigation des instances normatives. Il doit être évalué en comparant ce qui est observé à
ce qui est existant ou désiré afin de porter un jugement de valeur sur son état. Des normes
spécifiques, adaptées pour l’évaluation du logiciel ont été rédigées. Il s’agit essentiellement
des normes ISO/IEC 9126 (définit les caractéristiques qualité du logiciel) et ISO/IEC 14598
(montre comment ces caractéristiques peuvent être utilisés pour l’évaluation de la qualité du
logiciel) que nous utiliserons par la suite dans notre étude d’évaluation. Ces deux normes ont
été remplacées par la norme ISO/IEC 25000 (SQuaRE) mais elles restent toujours utilisées
dans l’industrie du logiciel. Les documents sur la norme ISO 25000 sont pour l’instant
difficile d’accès à moins de les commander en ligne sur le site de l’ISO. Un autre cadre
d'évaluation et de certification de la qualité du produit logiciel est le résultat principal de
SCOPE projet européen ESPRIT. Le processus d’évaluation selon les normes ISO/IEC 9126
et 14598 sera présenté en détail en chapitre 4.
La mesure du logiciel
29
Chapitre 2.
La mesure du logiciel
En génie logiciel, les mesures sont utilisées pour contrôler la qualité du produit
logiciel et mieux gérer les projets de développement afin de contrôler le coût de production
« Vous ne pouvez pas prévoir ni contrôler ce que vous ne pouvez pas mesurer. » [Fenton &
Pfleeger, 97]. Elles offrent, d’une part, des indices de base pour définir les mesures de la
qualité du logiciel comme la fiabilité (reliability), la maintenabilité (maintainability),
l’extensibilité (extendibility), l’utilisabilité (usability) et la réutilisabilité (reusability). D’autre
part, elles constituent des paramètres pour estimer et gérer l’effort, pour contrôler le processus
de développement et le budget [DE TRAN, 05].
Les mesures constituent une partie fondamentale des modèles de gestion de qualité du
produit logiciel. Les normes de qualité comme CMM (Capacity Maturity Model) et ISO 9000
proposent toujours une approche quantitative selon laquelle les mesures sont utilisées pour
comprendre l’état actuel du projet et prévoir les caractéristiques futures du projet afin de
contrôler la qualité des processus de production ou la qualité du produit lui-même. Sans
mesure, il ne peut y avoir de politique de qualité.
2.1 L’histoire et le développement de la mesure du logiciel
L'idée de créer et de définir des métriques du logiciel a commencé dans les années
1960 et 1970 et a été principalement développée dans les années 1980 et 1990.
Les informations suivantes sur l'histoire et le développement des mesures du logiciel ont été
principalement recueillies à partir du livre de Horst Zuse, “A Frame work of Software
Measurement” [Zuse, 98].
1950 – 1970
Probablement, la première étape dans le domaine de la mesure du logiciel a été
franchie en 1955 par John Backus. Il a proposé la métrique logicielle LOC (Lines of Code)
qui a utilisé pour analyser la taille d'un compilateur FORTRAN [Zuse, 98]. Compter les lignes
d'un programme est un processus assez simple et a donc fait de LOC la métrique la plus
utilisée. Toutefois, le problème de la métrique LOC réside dans les variations possibles dans
La mesure du logiciel
30
le comptage des lignes de code [Khan, 02]. Par exemple, en incluant ou excluant les
commentaires. Malgré cela, LOC est devenue la base de plusieurs autres métriques logicielles
telles que présentées dans le chapitre 3. Plus tard, dans les années 1960, les premières
méthodes de prévision des coûts dans le domaine du génie logiciel ont été introduites; la
méthode Delphi et la méthode Nelson’s SDC [Zuse, 98]. Probablement le premier document
dans le domaine de la mesure du logiciel qui a traité de la complexité du logiciel est
“Quantitative Measurement Program Quality” en 1968 par R. J. Rubey et R. D. Hartwick.
.
1970 – 1980
Dans les années 1970 et 1980, le domaine de la mesure du logiciel a été développé,
plusieurs articles et livres ont été publiés ainsi que de nouvelles métriques logicielles ont été
introduites, et tout particulièrement celles utilisées dans la quantification de la complexité du
code source. L'aspect de la complexité du logiciel est présenté dans les chapitres 2 et 3.
En 1971, Akiyama publia ce que nous croyons être la première tentative d'utiliser des
métriques pour la prédiction de la qualité des logiciels en proposant un modèle basé sur la
régression pour mesurer la densité des défauts dans un module (nombre de défauts par KLOC
« milliers de lignes de code »). En d'autres termes il utilisait KLOC comme une mesure de
substitution de la complexité du programme [Fenton & Neil, 99].
L'une des premières métriques, basée sur la métrique LOC, utilisée pour quantifier la
productivité du programmeur a été proposée par RW Wolverton en 1974. Wolverton a
proposé les instructions objet par homme-mois comme une mesure de la productivité et a
suggéré des intervalles de seuil pour cette métrique. Les inconvénients évidents de l'utilisation
d'une telle mesure brute telle que LOC comme mesure de substitution pour les différentes
notions telles que la taille, l'effort, la fonctionnalité, et la complexité du programme ont été
reconnus dans les milieux des années 1970 [Fenton & Neil, 99]. La nécessité de trouver des
mesures discriminantes est devenue particulièrement urgente. Ainsi, dans la même décennie
plusieurs métriques de complexité sont apparues. En 1976, la métrique de complexité
cyclomatique a été introduite par Thomas McCabe [Zuse, 98]. Cette mesure tente de
quantifier la complexité d'un programme en mesurant le nombre de chemins linéairement
indépendants contenus dans ce dernier (le code source). Un an plus tard, Maurice Halstead
[Halstead, 77] a introduit un ensemble de métriques visant la complexité d'un programme; en
particulier la complexité de calcul [Doren, 97]. Les métriques d’Halstead sont basées sur le
La mesure du logiciel
31
nombre d’opérateurs et d'opérandes contenus dans le code source d'un programme comme
expliqué dans son livre “Elements of Software Science, 1977 ”. Plusieurs firmes et
compagnies dont IBM et General Motors, ont utilisé cette série de métriques dans leur
processus de mesure du logiciel. Aujourd'hui, les métriques d’Halstead sont encore largement
utilisées, y compris la longueur, le volume, la difficulté et l'effort d’Halstead qui sont les plus
communes. D’autres métriques de complexité ont été rajoutées par Hecht en 1977 et par
McClure en 1978.
Le premier livre qui portait entièrement sur la mesure du logiciel est “Software
Metrics” par Tom Gilb, publié en 1976. Aussi, dans les années 1970, les termes la physique
du logiciel et la science du logiciel ont été introduits afin de construire systématiquement des
programmes informatiques. Le premier terme a été proposé par Kolence en 1975 et le second
a été proposé par Halstead en 1977 dans son livre déjà mentionné “Elements of Software
Science”. Puis, vers la fin des années 1970 (1979), Alan Albrecht a présenté son idée de
points de fonction au sein d'IBM [Zuse, 98]. La métrique points de fonction (FP) capture la
taille d'un système basé sur les fonctionnalités offertes à l'utilisateur afin de quantifier la
productivité de développement des applications.
1980 – 1990
Dans les années 1980 plusieurs mesures de complexité ont été introduites, y compris
la métrique du diagramme de Ruston, qui décrit l’organigramme d'un programme à l'aide des
éléments et de la structure sous-jacente de l'organigramme. En 1981, Harrison a introduit des
métriques pour déterminer le niveau d'imbrication des graphes de flux. Un an plus tard, Troy
a défini un ensemble de métriques dans le but de quantifier la modularité, la taille, la
complexité, la cohésion et le couplage d'un programme [Zuse, 98].
En plus de la méthode des points de fonction 1979, une autre métrique d’estimation
des coûts largement répandue avec COCOMO (Constructive Cost Model) [Boehm, Clark, et
al, 00] a été introduite deux ans plus tard en 1981. La méthode COCOMO, basé sur la
métrique LOC, estime le nombre d’homme-mois qu'il faudra pour terminer un produit
logiciel. Une métrique supplémentaire d’estimation des coûts est la métrique Bang proposée
par DeMarco six ans plus tard [Zuse, 95].
La mesure du logiciel
32
En 1984, la NASA a été l'une des premières institutions à utiliser la mesure du
logiciel. Dans la même année la méthode GQM (Goal Question Metric) a été développée par
Victor Basili et le Software Engineering Laboratory de la NASA. GQM est un paradigme
basé sur l'idée que la mesure doit être guidée par un objectif pour le développement de
logiciels applicable à tous les niveaux du cycle de vie des produits, des processus et des
ressources [Park, Goethert & Florac, 96] [Fenton & Pfleeger, 97].
En 1987, Grady et Castwell discutaient la mise en place d’un programme corporatif de
la mesure du logiciel chez Hewlett Packard. Les résultats de ce programme sont publiés dans
“Software Metrics: Establishing a Company-Wide Program” [Grady & Caswell, 87].
Depuis lors, peu d'attention avait été accordée à la programmation orientée objet dans le
domaine de la mesure des logiciels. Néanmoins, en 1988, Rocacher [Zuse, 95] a réalisé les
premières recherches sur la mesure des conceptions orientées objet, en établissant les
métriques logicielles pour le langage de programmation orientée objet Smalltalk. Un an plus
tard, Kenneth Morris a poursuivi en discutant des métriques logicielles d'un système orienté
objet dans sa publication “Metrics for Object-Oriented Software Development Environments
” [Zuse, 95]. D’importantes recherches dans les mesures orientées objet ont été faites dans les
années 1990.
Depuis1990
Comme la programmation orientée objet est devenue la méthode de programmation la
plus répondue dans les années 90 [Henderson, 96], l'accent a également changé dans la
mesure des logiciels vers les programmes orientés objet. Ainsi, plusieurs études et ouvrages
sur la mesure de logiciels orientés objets ont été publiés et de nombreuses métriques orientées
objet ont été ajoutées [Purao & Vaishnavi, 03]. En plus, des méthodes pour quantifier les
attributs externes comme la maintenabilité, la lisibilité et la qualité ont été introduites. Ce qui
suit est une brève présentation des événements liés au domaine de la mesure des logiciels
depuis 1990.
En 1992, le premier Standard IEEE pour les métriques de la qualité, à savoir “IEEE
Std 1061-1992 IEEE Standard for a Software Quality Metrics Methodology” a été mis en
place [Zuse, 95]. Le standard décrit les méthodes pour établir les spécifications de la qualité
ainsi que l'identification, l'analyse et la validation des métriques de la qualité.
La mesure du logiciel
33
En 1994, le premier livre discutant des métriques logicielles orientées objet, écrit par
Lorenz, a été publié [Zuse, 95]. Dans la même année, Chidamber et Kemerer ont introduit un
ensemble de métriques orientées objet, connu sous le nom des métriques CK [Chidamber &
Kemerer, 94]. Les métriques CK sont largement utilisées pour quantifier les approches de
conceptions orientées objet. L'ensemble des métriques MOOD, introduit par Abreu
[Abreu ,95], a suivi en 1995. Le chapitre 3 donne une description plus détaillée des métriques
CK, l’ensemble des métriques MOOD et bien d’autres métriques orientées objet.
Beaucoup de documents et livres portant sur la mesure des logiciels et les meilleures
pratiques en matière de mesure sont apparus dans le milieu des années 1990. Cependant,
moins de nouvelles métriques logicielles ont été rajoutées. Exemples de livres parus dans la
fin des années 1990 sont “Object-oriented metrics: measures of complexity” de Henderson-
Sellers [Henderson, 96], “A Framework of Software Measurement” par Zuse [Zuse, 98] et
tout particulièrement “Software Metrics: A Rigorous Approach” par Fenton et Pfleeger
[Fenton & Pfleeger, 97]. Malgré les nouvelles approches dans les années 1980 et 1990, bon
nombre de métriques appliquées dans l'industrie ont été créées dans les années 1970 [Fenton
& Neil, 99J].
Comme mentionné ci-dessus, Albrecht et ses collègues ont introduit la métrique Point
de Fonction (FP) qui mesure la taille d'un logiciel en quantifiant les fonctionnalités offertes
aux utilisateurs, en se basant seulement sur la modélisation logique (la description de la
structure du logiciel) et les spécifications fonctionnelles (la description des fonctions du
logiciel). Cette approche a pour avantage la possibilité d'être appliquée dès le début du cycle
de développement du logiciel afin de prédire certains attributs du logiciel tels que l'effort et le
temps de développement. En 1984, IFPUG (International Function Point Users' Group) a été
établi pour maintenir l'approche FP de Albrecht. Le groupe IFPUG a publié le manuel
“Counting Practices Manuals” qui fournit les règles standards pour l'application des FP
[IFPUG 94; IFPUG 99]. Ce manuel avait pour objectif de clarifier les règles de l'approche
originale d'Albrecht. En 1997, Saint-Pierre a proposé une approche des points de fonction
étendus (FFP) comme une extension de (IFPUG FP 4.0) [St-Pierre, 97]. L'objectif derrière
cette extension est de capturer la taille fonctionnelle des applications à temps réel. Par la suite,
le groupe COSMIC (Common Software Measurement International Consortium) a été formé
en 1998 pour développer une méthode améliorée de mesure de la taille fonctionnelle sur la
La mesure du logiciel
34
base de l'approche FFP [COSMIC FFP Measurement Manual, 01]. En mars 2003, la méthode
COSMIC-FFP est devenue une norme internationale (ISO/IEC 19761).
Entre 1991 et 2008, les métriques points de fonction sont devenues l’instrument de
mesure dominant pour la mesure des logiciels aux États-Unis, au Canada, en Australie, à la
Nouvelle-Zélande, en Afrique du Sud, et une grande partie de l'Europe. Elles sont aussi en
pleine expansion en Inde, et en Amérique du Sud. La métrique point de fonction peut être
utilisée pour une variété de fins utiles économiques, y compris dans des études de la
production du logiciel, des études de l’utilisation du logiciel et enfin dans des études de la
qualité logicielle [Jones ,08].
2.2 Contexte prévu de la mesure du logiciel
Dans la pratique, il y a plusieurs raisons pour mesurer le logiciel. Les principaux
avantages de telles mesures peuvent être classés comme suit [Park, Goethert & Florac, 96]:
• Compréhension
• Évaluation
• Prévision
• Amélioration
Selon Fenton et Pfleeger, l'évaluation et la prévision peuvent être combinées pour le
contrôle, le contrôle étant essentiel à toute activité importante « Nous devons contrôler nos
projets, et pas seulement les exécuter ».
Toutefois, seulement les projets logiciels en cours nécessitent le contrôle. L'état d’un
projet réalisé ne change pas et n'a donc pas besoin d'être contrôlé, mais peut être comparé à
d'autres projets. Dans notre étude, on s’intéresse au code source du logiciel et non pas à son
processus de création, l'accent est donc mis sur les aspects de la compréhension et
l'amélioration du logiciel.
Contrôle [Fenton & Pfleeger 97]
Figure 2.1 Domaines de la mesure du logiciel
La mesure du logiciel
35
Avant de savoir comment améliorer un attribut (où va-t-on), nous devons d'abord
comprendre le sens de l'attribut et ses caractéristiques actuelles (où sommes-nous).
« Si vous ne savez pas où vous êtes, un plan ne peut vous aider » [Pandian, 03].
Dans le contexte de mesure du code source, la compréhension est défini ici comme étant des
informations utiles à recueillir à propos des attributs du code (comme illustré dans la figure
2.1). Avec la compréhension des caractéristiques du code dans leur état actuel, les domaines
d'amélioration [Park, Goethert & Florac, 96] peuvent être identifiés et les intervalles de seuil
peuvent être définis. Un intervalle de seuil définit une plage de valeurs dans laquelle les
mesures devraient se produire.
2.3 Problèmes et enjeux de la mesure du logiciel
Les principaux problèmes et enjeux dans le domaine de la mesure du logiciel peuvent
être décris comme suit:
Interprétation des mesures
Le problème avec chaque mesure est celui de l’interprétation de la valeur qu’elle fournit : que
représente véritablement cette valeur ? Pour prendre des mesures utiles du logiciel dont
l'expérience a démontré la nécessité, des informations sur le contexte dans lequel les mesures
ont été produites est nécessaire [Zuse, 98]. Pour notre analyse d’évaluation, la mesure de la
complexité cyclomatique d'un programme pourrait avoir une valeur x. Cependant, cette
mesure doit être interprétée dans le contexte de la taille du programme, car un programme
plus long est susceptible d'être plus complexe, avant que l'information sur la complexité
puisse être recueillie. Ce point est discuté dans le chapitre 3.
Types d’échelle
Des précautions doivent être prises sur les types d'échelle concernés. Selon la théorie de la
mesure [Briand, El Emam & Morasca, 96], chaque type d'échelle a un ensemble différent de
statistiques applicables. Par exemple, l'ensemble des statistiques de l'échelle intervalle ne
comprend pas de multiplication. Par conséquent dire que la température d'aujourd'hui est deux
fois plus chaude que celle d'hier n'est pas une déclaration valable pour Fahrenheit et Celsius,
qui utilisent dans leurs mesurages de température des échelles fondées sur l'échelle intervalle
[Fenton & Pfleeger, 97]. Dans le contexte de la mesure du logiciel, cela signifie que la
La mesure du logiciel
36
comparaison et l'analyse des mesures du produit doit se faire avec prudence. Plus
d'informations sur les types d'échelle de mesure sont présentés dans le paragraphe 2.6.2.
L’absence de normes spécifiques
Selon Munson, le plus grand problème dans le domaine de la mesure du logiciel, pour chaque
objet à mesurer, est l'absence de normes [Munson, 03]. « Le NIST5 n'est pas motivé pour
établir des normes dans le domaine de la mesure du logiciel » Par conséquent, les mesures
recueillies pour la même entité logicielle ne sont pas comparables, à moins d’avoir des
informations supplémentaires sur les méthodes utilisées et la façon dont elles ont été
quantifiées.
Mesure de la productivité des programmeurs
L'unité la plus utilisée pour mesurer la productivité d'un programmeur est la quantité de
travail qu'il peut fournir dans un temps donné : le nombre de lignes de code source écrites, par
programmeur pendant une période de travail de 30 jours (un mois) ou par homme-mois.
Comme le souligne Jones (1978), cette mesure de productivité pose un certain nombre de
problèmes. Le plus fondamental consiste à définir exactement une ligne de code. Les
programmes sont constitués de déclarations, d'instructions et de commentaires. Ils peuvent
aussi contenir des macro-instructions qui correspondent à plusieurs lignes de code source.
Différentes mesures ont été proposées. Dans certains cas, on ne compte que les instructions
exécutables, dans d'autre cas les instructions et les déclarations, et parfois même toute ligne
non vide dans le programme. Du fait de ces différences, il est difficile de comparer la
productivité des programmeurs.
Il n'est pas évident qu'une mesure soit meilleure que les autres. Mais il n'est possible
d'effectuer des comparaisons que si la même technique de mesure a été utilisée. Cependant,
un autre problème se pose encore lorsque les langages de programmation sont différents. Pour
éviter ce genre de problèmes liés à la tâche de codage (l'écriture des lignes de code) on peut
utiliser le nombre d'instructions en code objet générées par programmeur et par mois. Bien
que cette unité soit plus objective que les lignes de code source, elle présente également des
inconvénients. Tout d'abord, il est difficile d'estimer le taux d'expansion code-source/code-
objet lié à un compilateur particulier. Cela signifie qu'il est difficile de faire des estimations
5 National Institute of Standards and Technology
La mesure du logiciel
37
avant la fin du codage. De plus, la quantité de code généré par un compilateur dépend très
largement du style de programmation [J.P Fournier].
Validité et fiabilité des données
Le fait de rassembler des mesures n'est pas suffisant pour obtenir des résultats de mesure
fiables, car la façon dont les données sont collectées et analysées à une grande influence sur le
résultat. Comme le signale M. Moroney J. (1950) : « Les données doivent être recueillies avec
un objectif clair en tête. Non seulement un objectif clair, mais une idée claire quant à la façon
précise dont elles seront analysées de manière à donner l'information souhaitée. »
Dans notre étude, l'objectif de collecte de données est d'obtenir des informations sur la taille,
la structure, la complexité et la qualité du code source disponible.
2.4 Application de la mesure du logiciel
Cette section se concentre sur l'application de la mesure du logiciel; les domaines de
mesure et leurs entités, et le processus de mesure lui-même.
En modélisation, une entité est caractérisée par un ensemble d’attributs. Un attribut
pourrait être une propriété inhérente à l’entité (attribut interne) ou une propriété associée à
l’entité (attribut externe). Par exemple, la longueur d’un module (en nombre de lignes de
code) est un attribut interne du module. Cependant, la difficulté à comprendre le code est un
attribut externe qui est dépendant de la personne qui lit le code et de sa familiarité avec le
langage de programmation. Un attribut externe est souvent plus difficile à mesurer qu’un
attribut interne. Il est aussi difficile de définir les attributs externes d’une entité de façon
mesurable [Henderson, 96].
Dans leur livre Software Metrics, Fenton et Pfleeger nous disent qu’ « il y a des
mesures qui nous aident à comprendre ce qui se passe durant le développement et la
maintenance d’un logiciel. Nous évaluons la situation courante en établissant des points de
repères (baselines) qui nous aident à établir des objectifs pour le comportement futur du
logiciel . En ce sens, les mesures rendent certains aspects des processus et des produits plus
visibles à nos yeux, nous donnant ainsi une meilleure compréhension des liens entre les
activités et les entités qu’elles affectent » [Fenton & Pfleeger, 97].
La mesure du logiciel
38
Fenton et Pfleeger affirmaient qu’il faut connaître une entité et ses attributs avant de
pouvoir la mesurer.
2.4.1 Domaines de mesure du logiciel
Les entités logicielles peuvent être classées en entités produits, entités processus et
entités ressources [Fenton & Pfleeger, 97]. Comme la mesure du logiciel tente de quantifier
ces entités logicielles, les domaines d'application peuvent être classées en conséquence
comme le montre la figure 2.1.
Le domaine des processus détient les entités logicielles qui représentent des étapes dans le
processus du génie logiciel. La quantification et la prédiction des attributs dans ce domaine
(comme le temps, l’effort et le coût) sont particulièrement d'intérêt pour les gestionnaires et
les chefs d'équipe [Fenton & Pfleeger, 97 ; Zuse, 98]. La méthode COCOMO de Boehm
[Boehm, Clark & et al, 00] et le modèle point de fonction d'Albrecht, qui sont introduits dans
la section 2.1 (histoire et développement de la mesure), accomplissent ce travail.
Le domaine des ressources contient les entités logicielles, qui sont utilisées ou requises par
les entités logicielles du domaine des processus (telles que le personnel, logiciels et matériel)
[Fenton & Pfleeger, 97]. À cet égard, le personnel est requis pour compléter un processus de
développement. Les attributs d'intérêt pour cette entité sont par exemple le nombre
d'ingénieurs logiciels impliqués, leurs compétences et leurs performances. Munson qualifie
ce domaine comme un domaine particulier appelé domaine de la mesure des personnes
[Munson, 03].
Le domaine des produits détient les entités logicielles qui résultent du processus d'activité (et
donc une entité du domaine des processus). La figure 2.2 présente les entités logicielles de
base de ce domaine selon Fenton.
Spécifications Conception Code Test des données
D o m a i n e des produits
Figure 2.2 Les entités de base pour le domaine des produits [Fenton & Pfleeger, 97]
La mesure du logiciel
39
Dans notre étude, la mesure du logiciel est appliquée dans le domaine des produits,
l’accent est mis sur l'entité code et ses attributs. La mesure de l’entité code et ses attributs sont
examinés avec plus de détails dans le chapitre 3.
2.4.2 Le processus de mesure
Le terme processus de mesure du logiciel peut être défini comme suit:
« Cette portion du processus logiciel qui fournit l'identification, la définition, la collecte et
l'analyse des mesures qui sont utilisées pour comprendre, évaluer, prévoir, ou contrôler les
processus ou les produits logiciels. » [McAndrews, 93].
Selon McAndrews, le processus de mesure du logiciel peut être divisé en quatre
activités: la planification, la collecte de données, l'analyse des données et l'évolution du
processus. Durant la planification, un but et un plan de mesure doivent être définis. En outre,
les entités logicielles et les attributs d'intérêt doivent être identifiés et les métriques logicielles
appropriées doivent être sélectionnées ou de nouvelles métriques doivent être définies. Au
cours de la phase de collecte de données, les métriques choisies sont appliquées manuellement
ou par l'utilisation d'outils de mesure du logiciel [Florac, Park & et al, 97]. Les mesures et les
données produites sont ensuite analysées selon les objectifs de mesure définis au préalable.
Dans de nombreux cas, les mesures sont groupées ou liées d'une certaine façon. Par
exemple, la productivité peut être mesurée en termes de la taille et de l'effort. Le plan de
mesure défini pendant la planification doit expliquer comment la taille et l'effort sont définis
et comment ils sont combinés pour calculer la productivité. Au même temps, le plan doit
indiquer où et quand les mesures seront prises durant le processus de mesure. Certaines
mesures seront prises une fois, tandis que d'autres seront collectées d’une façon répétée et
suivies pendant tout le processus. Le temps et la fréquence de la collecte sont liés aux
objectifs et aux besoins du projet, et ces relations doivent être explicitement indiquées.
Comme, il est important de décrire les outils qui seront utilisés pour la capture et le stockage
de données, et indiquer clairement quels types d’analyse à effectuer sur les données, et qui
seront chargés d’analyser ces données [MK. Donyaee, 01].
Dans notre étude, le processus de mesure est divisé en deux phases: une phase de
mesure et une phase d'analyse. La phase de mesure comprend la planification et la mesure du
La mesure du logiciel
40
code source. Dans la phase d'analyse, les mesures produites sont analysées et interprétées
pour une utilisation ultérieure dans l’évaluation du logiciel en vue de l’améliorer.
2.5 Les métriques logicielles
Comme nous l’avons déjà signalé, les métriques logicielles sont des instruments
appliqués dans le processus de mesure pour quantifier les attributs des entités logicielles.
Chaque métriques logicielle contient des informations sur son attribut cible (ou ses attributs
cibles) ainsi que la façon dont la mesure peut être appliquée pour quantifier cet attribut (ou
ces attributs). Par exemple, LOC est une métrique qui cible l’attribut taille du code source.
Comme on le verra dans le chapitre3, LOC quantifie la taille en comptant les lignes de code.
Selon ISO 9126, une métrique6 de qualité logicielle est définit comme une échelle
quantitative et une méthode qui peuvent être employées pour déterminer la valeur que prend
un attribut d’une entité d’un logiciel.
Le standard IEEE 1061 de 1992 définit les métriques mesurant la qualité d‘un logiciel
comme suit: « Une métrique de qualité logicielle est une fonction dont les entrées sont les
données du logiciel et la sortie est une valeur numérique unique qui peut être interprétée
comme la mesure dans laquelle le logiciel possède un attribut donné qui affecte sa qualité »
[IEEE 1061, 92].
Les métriques logicielles du code source peuvent être classées en deux grandes
catégories:
(1) Des métriques statiques du code source qui tentent de quantifier les attributs du code à
partir du texte du programme [Static code analysis, Wikipedia] et [Munson, 03]. Ces
métriques peuvent quantifier des graphes de contrôle de flux, des flux de données et
éventuellement des plages de données. On classe généralement ces métriques par:
• celles mesurant le processus de développement ;
• celles mesurant des ressources ;
• et celles de l‘évaluation du produit logiciel.
6 Le terme métrique est remplacé par le terme mesure dans l’ISO/IEC 25000
La mesure du logiciel
41
Les métriques de produits mesurent les qualités du logiciel. Parmi ces métriques, on distingue
les métriques traditionnelles et les métriques orientées objet. Les métriques orientées objet
prennent en considération les relations entre éléments de programme (classes, méthodes). Les
métriques traditionnelles se divisent en deux groupes : (a) Les métriques mesurant la taille et
la complexité. Les métriques les plus connues dans ce groupe sont les métriques de ligne de
code et les métriques d’ Halstead. (b) Les métriques mesurant la structure du logiciel comme
la complexité cyclomatique de McCabe en se basent sur des organigrammes de traitement ou
des structures de classe. Dans le chapitre 3, vous trouverez des explications sur les métriques
traditionnelles (les métriques de lignes de code, le nombre cyclomatique de McCabe et les
métriques d’Halstead) et l’index de maintenabilité ainsi que leurs utilisation dans la mesure de
la qualité du logiciel [Lambertz].
(2) Des métriques dynamiques du code source qui tentent de quantifier les caractéristiques
d'un système en cours d’exécution et montrent comment il interagit avec d'autres processus.
Par rapport à l'utilisation des métriques statiques, la mesure d'un système en cours d’exécution
est plutôt gourmande en ressources en raison de la surcharge massive des données. Toutefois,
les métriques dynamiques sont d’une grande utilité dans la détection des erreurs, les aspects
de la sécurité et les interactions du programme [Munson, 03].
2.5.1 Utilisation des métriques logicielles
Le terme «métrique logicielle» englobe de nombreuses activités, qui impliquent un
certain degré de mesure du logiciel. D’après Fenton [Fenton & Pfleeger, 97], les métriques
logicielles peuvent être utilisées pour :
Estimation du coût et de l'effort
Les chefs de projets informatiques voulaient être en mesure de prédire les coûts du projet
pendant les premières étapes du cycle de vie de développement du logiciel. En conséquence,
de nombreux modèles pour l’estimation du coût et de l'effort pour les projets logiciels ont été
proposés et utilisés. Les exemples incluent le modèle de Boehm COCOMO (Boehm, 1981), le
modèle de Putnam SLIM (Putnam, 1978) et le modèle d’Albecht Points de fonction (Albecht,
1979). Ces modèles et d'autres partagent souvent une approche commune: l'effort est exprimé
comme une fonction (prédéfinie) d'une ou plusieurs variables telles que la taille du produit, la
capacité des développeurs et le niveau de réutilisation. La taille est généralement définie
La mesure du logiciel
42
comme le nombre de lignes de code ou le nombre de points de fonction (qui peut être dérivé
de la spécification des produits).
Les mesures de la productivité et modèles
Les besoins urgents de la gestion ont également donné lieu à de nombreuses tentatives de
définir des mesures et des modèles pour évaluer la productivité du personnel au cours des
différents processus de développement du logiciel et dans différents environnements.
La collecte de données
La qualité de tout programme de mesure dépend clairement de la collecte de données. Cette
tâche devient plus difficile si les données doivent être recueillies à travers un ensemble
diversifié de projets. Ainsi, la collecte de données est devenue une discipline en soi, où des
spécialistes travaillent à s'assurer que les mesures soient définies sans ambiguïté, que la
collecte est cohérente et complète, et que l'intégrité des données soit préservée.
Les modèles de qualité et mesures
La productivité ne peut être considérée isolément. Sans une évaluation d'accompagnement de
la qualité du produit, la vitesse de production est dénuée de sens. Cette observation a conduit
les ingénieurs logiciels à développer des modèles de qualité dont les mesures peuvent être
combinées avec celles des modèles de productivité. Par exemple, le modèle avancé
d'estimation des coûts COCOMO de Boehm est lié à un modèle de qualité [Boehm et al, 78].
De même, le modèle de qualité de McCall [McCall et al, 77], communément appelé FCM
(Facteur de critères métriques) est lié à la productivité.
Les modèles de fiabilité
Les modèles de fiabilité sont des modèles mathématiques qui permettent d'évaluer les mesures
caractérisant la fiabilité du logiciel en évolution, à l'aide d'expressions relativement peu
complexes. Littlewood (1988) et d'autres donnent un exemple rigoureux et efficace de la
façon dont la fiabilité, un attribut important de qualité des produits, a conduit à une meilleure
compréhension et un meilleur contrôle de nos produits.
L'évaluation des performances et modèles
La performance est un autre aspect de la qualité. Son évaluation inclut des caractéristiques de
performance du système, observables de l’extérieur, tels que les temps de réponse et les taux
d'achèvement [Ferrari et al, 1978 - 1983 ; Kleinrock, 1975].
La mesure du logiciel
43
Métriques de complexité et de structures
Certains attributs de la qualité comme la fiabilité et la maintenabilité ne peuvent être mesurés
que lorsqu’une version opérationnelle du code soit disponible. Pourtant, nous voulons être en
mesure de prédire quelles parties du système logiciel sont susceptibles d'être moins fiables,
plus difficiles à tester, ou nécessitent plus de maintenance que les autres, avant même que le
système ne soit terminé. En conséquence, nous mesurons les attributs structurels des
représentations du logiciel qui sont disponibles à l'avance (ou qui ne nécessitent pas
l'exécution du logiciel), puis nous essayons d'établir empiriquement les théories prédictives
pour soutenir l'assurance qualité, le contrôle de la qualité, et la prédiction de la qualité.
Halstead (1977) et McCabe (1976) sont deux exemples classiques de cette approche, chacun
définit les mesures qui sont dérivées des représentations appropriées du code source.
La gestion par les métriques
Les mesures sont devenues une partie importante dans la gestion des projets informatiques.
Celles à base de diagrammes et de graphiques sont utilisées davantage pour nous aider à
décider si le projet est sur la bonne voie. Elles doivent être présentées d'une manière qui
indique à la fois au client et au développeur l’avancement du projet.
Evaluation des méthodes et outils
De nombreux organismes réalisent des expériences, mènent des études et des sondages pour
les aider à décider si une méthode ou un outil est susceptible de faire la différence dans des
situations spécifiques. Ces études et expériences ne peuvent être réalisées en l’absence de
mesures contrôlées.
Maturité et évaluation des aptitudes
Il s’agit essentiellement du modèle d’évaluation et d’évolution des processus logiciels (CMM)
du SEI [Humphrey, 89]. Il peut être utilisé comme référentiel formel lors d’audits de
fournisseurs, pour juger de leur capacité de réaliser un certain projet informatique. On peut
vouloir aussi évaluer en interne sa propre maturité en matière de processus logiciel en vue de
développer un plan d’amélioration. D'autres organisations, inspirées par l'objectif du SEI, ont
développé d’autres modèles d'évaluation, dans l'espoir d'encourager l'amélioration des
pratiques en matière de développement et de maintenance du logiciel.
La mesure du logiciel
44
2.6 La théorie de la mesure du logiciel
« Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer » DeMacro (1982) ;
« Ce qui n’est pas mesurable, rendez-le mesurable » Galilei (1564 – 1642).
Afin de mesurer les logiciels, la théorie de base sur la théorie de la mesure doit être
connue et comprise.
La théorie de la mesure est une branche des mathématiques appliquées qui définit une
base théorique pour la mesure. Selon Zuse, les principaux avantages de cette théorie sont les
hypothèses sur la réalité, les études empiriques des mesures produites, et la compréhension du
monde réel à travers l’interprétation des propriétés numériques [Zuse, 95].
La mesure est une quantification directe, le calcul est une quantification indirecte.
Mesurer permet de mieux comprendre et donc de mieux mesurer [Guéhéneuc, 06].
2.6.1 Introduction à la théorie de la mesure
Une mesure du logiciel est définie comme une méthode permettant de déterminer
quantitativement l’ampleur avec laquelle un processus, un produit ou un projet logiciel
possède un certain attribut. Dans le dictionnaire standard d’IEEE le terme « mesure » est
défini comme une évaluation quantitative du degré auquel un produit logiciel ou un
processus possède un attribut [IEEE Std Broad, 89].
Fenton indique qu’une mesure est un processus par lequel les nombres ou les
symboles sont assignés aux attributs des entités du monde réel d’après des règles bien
définies. Il s’agit d’une mise en correspondance entre le monde empirique (c à d, le monde
réel) et le monde formel (c à d, les mathématiques) [Fenton & Pfleeger, 97].
Pour certains auteurs (p.ex., Ejiogu, Fenton), les mesures du logiciel doivent être
basées sur la discipline mathématique et la théorie de la mesure. Les mesures doivent être
associées à un processus de modélisation. Une mesure n’est pas en soi un nombre mais une
assignation d’un nombre à une entité. Il s’agit d’une mise en correspondance (mapping) entre
des entités et les caractéristiques sous observation.
Comme avec d'autres disciplines de mesure, la mesure du logiciel doit être également
basée sur la théorie de la mesure [Fenton ,94]. Dans le domaine de la mesure du logiciel, la
théorie de mesure comprend: (1) une définition claire de la terminologie, (2) une base solide
La mesure du logiciel
45
pour les métriques logicielles, (3) des critères pour l'expérimentation, (4) des conditions pour
la validation des métriques logicielles et (5) des critères pour les échelles de mesure [Zuse,
98]. Henderson-Sellers souligne que la théorie de la mesure introduit, en outre, une
compréhension des variances, d’intervalles, et les types d'erreurs dans les données de mesure
par l'utilisation des probabilités et des statistiques [Henderson, 96].
Dans la littérature, la théorie de mesure du logiciel a été discutée en détail. Pour ce
mémoire, les travaux de Zuse, Fenton et Henderson-Sellers ont été utilisés pour mieux
comprendre les aspects de cette théorie. Les principaux aspects de la mesure du logiciel sont
brièvement présentés ci-dessous :
Les relations empiriques
« L’être humain n’est pas toujours capable de formuler des relations empiriques correctes.»
(Barrière de l’intelligence, Kirz 1988)
L'aspect des relations empiriques traite de la compréhension intuitive ou empirique
des relations d'objets dans le monde réel. Les relations peuvent être exprimées dans un
système de relations formelles [Henderson, 96]. Par exemple, on peut observer la relation
entre deux personnes en termes de taille. Les comparaisons « plus grand que », « plus petit
que »,… sont des relations empiriques de la taille [Fenton & Pfleeger, 97]. Si un terme, tel
que la complexité ou la qualité, a des significations différentes pour différentes personnes,
définir un système de relation formelle devient presque impossible [Fenton & Pfleeger, 97 ;
Henderson, 96].
Figure 2.3 Approche de mesure [Guéhéneuc, 06]
La mesure du logiciel
46
La relation empirique doit être aussi représentée par des nombres ou des symboles.
Cependant, il faut s’assurer que ce choix de représentation doit préserver la relation empirique
(s’assurer que toutes les relations du système empirique sont préservées dans le système
formel « ou numérique »). Si on reprend la relation entre deux personnes en termes de taille,
la mesure de la taille par la valeur en kilogrammes de l’individu ne préserve pas la relation
empirique.
Les règles de mise en correspondance des mesures (mapping)
Il existe différentes approches pour la mise en correspondance d'un attribut du monde
réel dans un système mathématique. Cette mise en correspondance doit suivre des règles
spécifiques afin de rendre les mesures reproductibles et comparables [Fenton & Pfleeger, 97].
A titre d'exemple, plusieurs approches pour quantifier la taille d'un logiciel existent toutefois,
ces mesures ne sont pas comparables, à moins d'avoir des informations claires sur la façon
dont les mesures ont été produites.
Les types d’échelle
Les différences résultant de la mise en correspondance des attributs pourront limiter
les moyens à utiliser pour l'analyse d'une mesure donnée [Fenton & Pfleeger, 97 ; Zuse, 98].
Les types d'échelle de mesure (nominal, ordinal, intervalle, ratio, absolu ou autres) existent
pour nous aider à identifier le niveau des statistiques applicables. Les types d'échelle sont
discutés dans la section 2.6.2.
Les mesures directes et indirectes
Une mesure peut être directe ou indirecte. La mesure directe d’un attribut d’une entité
est indépendante des mesures des attributs d’autres entités. Par contre, la mesure indirecte
d’un attribut d’une entité est définie en se basant sur d’autres mesures. Par exemple, le
nombre de caractères est une mesure directe de la longueur d’un fichier; le nombre de pages
d’un texte est une mesure indirecte parce qu’elle est définie par le nombre de lignes du texte
et le nombre de lignes imprimées sur une page. Les attributs externes sont souvent mesurés
indirectement via des attributs internes en se basant sur un modèle construit.
Validité et fiabilité des mesures
La validation d’une mesure du logiciel consiste à s’assurer que la mesure est une
caractérisation numérique correcte de l’attribut mesuré [Guéhéneuc, 06]. Par exemple, une
La mesure du logiciel
47
mesure de la taille d’un programme ne doit pas contredire toute notion intuitive sur la taille,
autrement dit :
– Si un programme P1 est plus grand qu’un programme P2 alors M(P1) > M(P2)
– Si P1 ; P2 alors M(P1;P2) = M(P1) + M(P2)
– Si M(P1) = 9 et M(P2) = 7 alors M(P1;P2) = 16
Où M est une mesure sur l’entité programme.
Une façon efficace de valider une mesure est de montrer qu’elle fait partie d’un
système de prédiction valide. La validation d’un système de prédiction, dans un
environnement donné, consiste à montrer que les prédictions faites par le système en utilisant
des moyens empiriques sont correctes. En d’autres termes, il s’agit de comparer les
prédictions avec les données connues [Guéhéneuc, 06].
Par quelque bout que l'on prenne le problème, une mesure est effectuée pour prendre
une décision. Or, si le résultat de mesure est erroné, il y aura une forte probabilité pour que la
décision le soit aussi. D'où la nécessité d'avoir des résultats de mesure fiables. Il est donc
nécessaire de faire attention aux nombres qui sont faux ou tout fabriqués. Un commentaire
énonçait « qu’aucun estimé n’est correct, sauf par chance ». Grady (1994) parle d’utiliser des
données d’anciens projets pour vérifier les estimés. Ces remarques portent également à se
poser des questions sur la validité des mesures utilisées en génie logiciel. En effet, il ne suffit
pas de mesurer pour obtenir un nombre. Il faut aussi que les résultats de la mesure
représentent quelque chose qui pourra aider à améliorer les développements futurs des
logiciels. Beaucoup d’articles critiquent la validité des outils et des méthodes de mesures dans
ce domaine. Des mesures telles que le nombre de lignes de code ou les points de fonction sont
souvent utilisées en génie logiciel mais reçoivent cependant beaucoup de critiques quant à
leur valeur réelle.
Deux facteurs pouvant affecter la validité des résultats des mesures sont décrits dans
l’article de Weller “Using Metrics to Manage Software Projects”. Ce sont la validité et
l’absence des données. En effet, si les données de base sont erronées, il est difficile d’obtenir
des résultats fiables. D’un autre côté, si les données ne sont pas encore disponibles, on ne peut
pas fournir de résultat. Cela représente une autre incertitude, celle de savoir si, dans de
nombreux cas, nous n’avons pas affaire à des données erronées ou à un manque de données?
Fenton et Pfleeger (1997) le disent aussi en mentionnant que la « qualité d’un programme de
La mesure du logiciel
48
mesure dépend clairement d’une collecte attentive des données ». Cependant, ils pensent aussi
que c’est quelque chose de plus facile à dire qu’à faire.
Une autre incertitude concernant la validité des données, est celle de savoir si les
mesures accomplissent réellement les tâches qui leur sont assignées. En d’autres mots, à quel
point la validité interne des mesures utilisées en génie logiciel est respectée, celle-ci étant
définie comme le degré de confiance qu’on a en la véracité des résultats pour une situation
d’étude spécifique [Davis, 96]. Selon Davis, ce type de validité n’est jamais complètement
mesurable. La raison en est que les sources d’invalidité sont trop nombreuses pour que le
chercheur les mesure et même les identifie. Fenton et Pfleeger (1997) posent d’autres
questions concernant la validité interne des données, à savoir (1) En utilisant les mesures,
quelle affirmation sensée peut on faire à propos des attributs et des entités qui les possèdent
(par exemple, est-il sensé de parler de doubler la qualité de la conception)? (2) Quelles
opérations sensées peut-on effectuer sur les mesures? (Par exemple, peut-on calculer la
productivité moyenne d’un groupe de développeurs?) Par « opération sensée », Fenton et
Pfleeger entendent qu’il est nécessaire de savoir à quel type d’échelle de mesure appartient
une entité et qu’il est impératif d’utiliser uniquement les opérations statistiques permises avec
ce genre d’échelle.
Les erreurs de mesure et l’imprécision
Les erreurs peuvent survenir lors de mesures, même dans de simples mesures
[Pandian, 03 ; Rabinovich, 05]. Les erreurs de mesure du logiciel concernent l'écart et
l'imprécision des mesures produites à partir des caractéristiques de logiciels dans le monde
réel. Plusieurs classifications pour les erreurs de mesure existent [Rabinovich, 05 ; Laird &
Brennan, 06]. Ici, nous nous intéressons aux erreurs occasionnées par les outils et instruments
de mesure et celles causées par les personnes qui proposent la mesure. La première classe
d’erreurs comprend les erreurs causées par des imperfections dans l’outil ou l'instrument de
mesure utilisé pendant le processus de mesure. Quant aux erreurs personnelles sont causées
par des erreurs humaines pendant le processus de mesure. Ces erreurs peuvent inclure la
sélection incorrecte des métriques logicielles, l'ajustement et l'application incorrectes des
outils de mesure ainsi que l'interprétation erronée des mesures produites. Le choix des
métriques, dans notre étude de cas, est discuté en chapitres 5.
La mesure du logiciel
49
Les mesures sont très dépendantes des instruments utilisés et de la précision des
mesures de ces instruments [Briand, El Emam & Morasca, 96 ; Glass, 96 ; Rabinovich, 05].
Pour la mesure des logiciels la précision ou l’exactitude des métriques disponibles est un sujet
souvent discuté. Certains attributs de logiciels sont plus difficiles à quantifier précisément que
les autres. La complexité du logiciel par exemple est difficile à quantifier [Zuse, 91 ; Fenton,
94] parce que cet attribut logiciel est influencé par plusieurs autres facteurs qui ne sont pas
toujours vérifiables. Les facteurs eux-mêmes peuvent, en outre, dépendre d'autres aspects,
rendant ainsi l'attribut cible difficile à quantifier. Le problème de la quantification de la
complexité des logiciels et la précision des métriques sont discutés dans la section 2.8.
2.6.2 Les échelles de mesure
« Il faut se faire une échelle pour y rapporter les mesures qu'on prend » J. J. ROUSS.
D’après Fenton et Pfleeger, une mesure directe d’un attribut est l’assignation de la
correspondance d’un système de relation empirique en un système de relation numérique
(mapping), de telle sorte que les nombres obtenus représentent les caractéristiques du monde
réel. Cependant, les mises en correspondance des mesures ne sont pas toujours les mêmes et
peuvent dépendre étroitement de la nature de l’analyse effectuée. Pour comprendre ces
différences, nous introduisons la notion d'échelle de mesure, puis nous utiliserons ces échelles
pour nous aider à comprendre quelles sont les analyses appropriées [Fenton & Pfleeger, 97].
La notion de type d’échelle est importante car elle permet de mettre en évidence les
propriétés empiriques associées à l’attribut mesuré [Sellami, 05]. « On appelle échelle de
mesure l’ensemble constitué de la méthode de mesure M et les systèmes des relations
empiriques et numériques» [Guéhéneuc, 06]. Cependant, il y a trois questions importantes
concernant les échelles:
1. Comment déterminer si un système de relations numériques est meilleur qu’un autre ?
2. Peut-on toujours trouver un système de relations numériques ?
3. Comment faire quand il existe différentes représentations possibles (et donc de
nombreuses échelles) dans le même système de relations empiriques ?
D’après Fenton, la réponse à la première question est pragmatique « il faut utiliser des
nombres réels quand c’est possible ». Car, la manipulation des symboles peut être beaucoup
La mesure du logiciel
50
plus lourde que la manipulation numérique. La deuxième question est connue comme un
problème de représentation, elle ne concerne pas seulement les ingénieurs du logiciel, mais
tous les scientifiques qui sont intéressés par la mesure ; Pour certains problèmes (systèmes de
relations empiriques) une seule représentation est possible, pour d’autres, différentes échelles
de mesure peuvent être appliquées. Plus il y a de relations empiriques à préserver, moins il y a
de possibilités de représentions. Une échelle A est dite plus riche qu’une échelle B si les
caractéristiques de B sont incluses dans celles de A [Guéhéneuc, 06]. La troisième question
est connue comme un problème d'unicité, cette question porte sur notre capacité à déterminer
la représentation la plus appropriée pour mesurer un attribut d'intérêt [Fenton & Pfleeger, 97].
La communauté du génie logiciel utilise souvent les cinq types d’échelle proposés par
Stevens (1946) : nominale, ordinale, intervalle, ration et absolue [Stevens, 46]. Chaque type
d’échelles autorise certains types de transformations. Le tableau 7 montre la classification
des types d’échelle, l’ensemble des transformations admissibles qui peuvent être appliquées à
un type d’échelle donné et des exemples. Les propriétés des échelles de mesure sont
hiérarchiques. Chaque échelle possède les propriétés de l’échelle d’un niveau plus bas. Ainsi,
l’échelle absolue possède toutes les propriétés des échelles précédentes [Sellami, 05].
Les types d’échelle sont ainsi définis par les transformations mathématiques admissibles et
décrits par les propriétés empiriques de l’attribut mesuré (les applications statistiques
applicables sur les valeurs de l’échelle, les unités associées aux échelles, le type des
affirmations significatives dans l’échelle). Le type d’échelle nous indique le type d’opérations
qu’on peut accomplir. Par exemple, on peut calculer les moyennes des mesures de type
d’échelle ratio, mais pas celles de type ordinal.
La mesure du logiciel
51
L’échelle nominale
C’est la plus élémentaire des formes de mesure. Comme son nom l’indique, elle
consiste essentiellement à « nommer » les caractéristiques mesurées. Elle est donc
essentiellement qualitative et permet de regrouper dans un même ensemble les observations
possédant au moins une caractéristique commune. Ainsi, l'échelle nominale possède deux
caractéristiques principales:
• Le système de relation empirique se compose de classes différentes, il n'y a pas de notion
d'ordre entre les classes ;
• Toute numérotation distincte ou représentation symbolique des classes est une mesure
acceptable, même si les classes sont numérotées de 1 à n, il n'y a pas de notion de
grandeur associés aux numéros ou aux symboles.
Exemples :
– Sexes : mâle (1), femelle (2), Couleurs, Religions, Processus de développement, etc.
Propriétés :
– Les classes doivent être conjointement exhaustives. Pour la religion, par exemple, utiliser
une classe «autre» pour être exhaustif ;
– Les classes doivent être mutuellement exclusives. Une personne ne peut pas être en même
temps catholique et protestante.
L’échelle ordinale
Cette échelle de mesure consiste à mettre en rang les observations, d’où son nom
« échelle ordinale ». Elle rajoute donc la notion d’ordre (qui peut être établie aussi bien entre
les nombres que les symboles) à l’échelle nominale.
Exemples :
– Classes sociales, Niveaux CMM, Tailles (petit, moyen, grand), etc.
Propriétés
– Transitivité : en considérant la relation > qui définit un ordre entre les entités, si P1 > P2
et P2 > P3 alors P1 > P3.
– Complétude : pour deux entités P1 et P2, il faut toujours avoir soit P1 > P2 soit P2 > P1.
La mesure du logiciel
52
L’échelle intervalle
Dans cette échelle de mesure, il existe une unité constante de mesure de sorte que
l’intervalle entre chaque valeur de l’échelle est le même. Cette échelle possède les mêmes
propriétés que l’échelle ordinale mais permet en plus de considérer que les intervalles ou
écarts entre les valeurs ne changent en aucun point de l’échelle. Avec une échelle
d’intervalles, il devient possible d’affirmer qu’un écart de 10 entre un score de 40 et un score
de 50 à un test est équivalent à un écart de 10 entre un score de 83 et un score de 93.
L’échelle d’intervalles possède une limite importante du point de vue métrique: elle
ne possède pas de point d’origine absolu ou, si l’on préfère, aucun véritable zéro. Obtenir zéro
à un test d’intelligence ne signifie pas que l’on mesure le «vide» d’intelligence. Cette valeur
est donc purement arbitraire, comme c’est le cas du zéro dans l’échelle de température. En
degrés centigrades de l’échelle Celsius, la valeur zéro correspond au point de congélation de
l’eau au niveau de la mer. Il aurait pu tout aussi bien s’agir du point d’ébullition de l’eau ou
de toute autre convention. A titre d’exemple, la valeur 0 de l’échelle Fahrenheit ne correspond
pas au point de congélation: sur cette échelle, il se situe à 32. En plus d’avoir des points
d’origine différents, les échelles Celsius et Fahrenheit possèdent une autre différence: l’unité
de mesure de température est différente. Un changement d’une unité centigrade correspond à
un changement de 1,8 unités à l’échelle Fahrenheit.
Exemples :
– Température en Celsius, Nombre de fautes par KLOC, etc.
L’échelle ratio
On retrouve dans cette échelle de mesure toutes les propriétés d’une échelle à
intervalles égaux avec, en plus, un véritable point d’origine, le zéro. Elle est surtout l’apanage
des sciences physiques où les mesures de masse, poids, volume sont constituées d’intervalles
égaux et possèdent un véritable zéro. En effet, 0 litre signifie absence de volume, tout comme
0 kilogramme représente une masse nulle. Il existe une échelle proportionnelle de mesure de
température: c’est l’échelle des degrés Kelvin. L'échelle Kelvin est la seule qui ne possède pas
de valeurs négatives et commence par le zéro absolu. Le zéro absolu est en théorie la
température la plus basse qu'une substance puisse atteindre. Il correspond à une température
de -273,15 °C. Les molécules qui atteignent cette température se figent ; il n'y a plus
d'agitation moléculaire. Le zéro de l'échelle Celsius est choisi arbitrairement et correspond au
point de congélation de l'eau.
La mesure du logiciel
53
Exemples :
– Température en Kelvin, Nombre de fautes, etc.
L’échelle absolue
C’est l’échelle la plus restrictive de toutes les échelles, elle consiste uniquement à
compter. Pour deux mesures M et M', il n'y a qu'une seule transformation admissible: la
transformation identité. Il n' y a qu'une seule façon pour réaliser la mesure de sorte que M et
M' doivent être égales.
Exemple :
– Nombre d’erreurs trouvées lors d’un test d’intégration, Nombre de voitures dans le
stationnement, etc.
Propriétés :
– La mesure dans une échelle absolue se fait simplement en comptant le nombre d'éléments
dans l'ensemble d’entités ;
– L'attribut prend toujours la forme "nombre d'occurrences de x dans l'entité." ;
– Il n'y a qu'une seule mise en correspondance (mapping) possible pour la mesure ;
– Toutes les analyses arithmétiques résultant de l’opération de comptage sont significatives.
2.6.3 Les mesures objectives et subjectives
Lors de la mesure des attributs d'entités, nous nous efforçons de maintenir nos mesures
objectives. En faisant ainsi, nous veillons à ce que différentes personnes produisent les mêmes
mesures, indépendamment du fait qu'ils mesurent un produit, un processus ou des ressources.
Cette cohérence de la mesure est très importante. Bien qu'aucune mesure ni véritablement
objective (parce qu’il existe toujours un certain degré de subjectivité sur les entités et les
attributs) nous trouvions des mesures nettement plus subjectives que d’autres. Les mesures
subjectives dépendent de l'environnement dans lequel elles sont produites. Elles peuvent
varier selon la personne qui propose la mesure, et elles reflètent le jugement de cette
personne. Ce qu’une personne estime mauvais, une autre peut le considérer bon, et il peut être
difficile de parvenir à un consensus sur des attributs tels que le processus, le produit ou la
qualité des ressources.
Néanmoins, il est important de reconnaître que des mesures subjectives peuvent être
utiles, aussi longtemps que nous comprenions leur imprécision. Supposons, par exemple, que
nous voulions mesurer la qualité des exigences avant de soumettre les spécifications à l'équipe
La mesure du logiciel
54
de test, en vue d’établir le plan de test. Par exemple, on peut demander à l'équipe de test de
lire et d’évaluer (de noter) chacune des exigences sur une échelle de 1 à 5, où «1» signifie
«Je comprends entièrement cette exigence et je peux écrire un script de test pour déterminer
si cette exigence est satisfaite» à «5»: «Je ne comprends pas cette exigence et je ne peux pas
écrire un script de test». Les résultats de cette évaluation peuvent être semblables à ceux du
tableau 8.
Même si la mesure est subjective, les mesures recueillies (le tableau 8) nous montrent
que nous puissions avoir des problèmes avec les exigences d'interface, peut-être elles doivent
être réexaminées et réécrites avant d’établir un plan de test. C'est le jugement dans sa globalité
qui est important, plutôt que l'exactitude des mesures individuelles. Ainsi, la subjectivité,
malgré ses inconvénients, ne nous empêche pas de recueillir des informations utiles sur
l'entité [Fenton & Pfleeger, 97].
2.6.4 Problèmes de mesure au niveau pratique
Plusieurs chercheurs ont traité la problématique de la mesure de logiciels selon
différentes perspectives avec peu de discussion sur les instruments de mesure et la qualité de
mesures de ces instruments. Les propositions sont souvent décrites au niveau utilisation des
mesures. Par exemple :
Kitchenham et d’autres. recommandent un cadre préliminaire de validation de
mesure du logiciel [Kitchenham, Pfleeger & Fenton, 95] ;
Schneidewind propose un corpus de connaissance qui consiste en une liste de
thèmes (issues) de mesure de la qualité du logiciel [Schneidewind, 02] ;
Fenton et Pfleeger suggèrent qu’une mesure valide doit nécessairement obéir aux
conditions de représentation de la théorie de mesure de telle sorte que la
compréhension intuitive de certain attributs est préservée lors de sa mise en
correspondance dans un système de relation numérique [Fenton & Pfleeger, 97] ;
La mesure du logiciel
55
Zuse définit les mesures du logiciel par la mise en correspondance des propriétés
empiriques et les propriétés numériques par un homomorphisme7 [Zuse, 98].
La plupart de ces auteurs s’intéressent particulièrement au domaine théorique des
connaissances de la mesure. Cependant, les aspects théoriques et pratiques de la mesure sont
importants sans avoir à privilégier l’un de l’autre ou chercher à placer l’un ou l’autre en
position dominante. Comment peut-on vérifier que les mesures utilisées dans le contexte
industriel soient robustes ?
L'industrie s'intéresse généralement a l'utilisation des mesures afin d'optimiser la
qualité du logiciel, le délai de livraison, améliorer les relations avec les clients, etc. sans tenir
compte de la vérification de la mesure en-soi. En effet, les gestionnaires préfèrent manipuler
plusieurs chiffres pour avoir une flexibilité au niveau de la gestion des projets logiciels en
ignorant les fondements sur lesquels les chiffres ont été obtenus. Les approches les plus
utilisées de quantification des aspects de qualité du logiciel relatifs au produit, au processus et
aux ressources sont les mesures de code de Halstead, la densité de défauts de McCabe, les
méthodes des points de fonction d'Albrecth, le modèle COCOMO [Boehm, Clark & et al, 00],
etc. Une question qui se pose : les approches les plus utilisées sont-elles nécessairement les
« bonnes » approches de mesure? Et, quels sont les critères de sélection parmi ces approches
pour prendre les meilleures décisions? [Sellami, 05].
2.7 Les mesures logicielles: Outils pour les produire
Les outils de mesure du logiciel existent pour simplifier et automatiser l'application
des métriques logicielles durant le processus de mesure. Il existe un grand nombre d’outils
logiciels de mesure disponibles [Pohjolainen, 02], dont la plupart sont de nature commerciale.
Certains de ces outils se concentrent sur un domaine spécifique de la mesure du logiciel, tels
que les processus ou les ressources. Dans ce mémoire, l'accent est mis sur les outils
appropriés pour l'analyse statique du code. Une liste détaillée des outils de mesure du logiciel
est donnée en annexe.
7 homomorphisme ou morphisme est une application entre deux ensembles munis d'une même espèce de structure, qui
respecte cette structure. Cette notion de morphismes est fondamentale en mathématique. Elle permet de comparer et de relier
les objets mathématiques entre eux.
La mesure du logiciel
56
2.8 L’entité code du logiciel
Pourquoi mesurer la qualité du code source? La qualité d'un logiciel dépend en
grande partie de la qualité de son code source. La mesure de la qualité du code source peut
nous permettre, par exemple, de se faire une idée quant à la maintenabilité du logiciel
mesuré. Nous pouvons encore, imaginer réaliser une revue de qualité du code pour des
développements qui ont été sous-traités. La mesure de la qualité du code source peut
également permettre d'indiquer la capacité du logiciel à accepter de futurs changements ou
évolutions. Enfin, ce type de mesures peut être utile aux décideurs dans le cadre du choix d'un
logiciel open source.
Les entités logicielles peuvent être classées dans les trois domaines de la mesure du
logiciel comme illustré dans le tableau 9. Chaque entité logicielle a des attributs spécifiques,
qui sont d'intérêt pour la mesure. Comme nous l’avons déjà expliqué en section 2.4, les
attributs logiciels peuvent être classés en attributs internes et attributs externes. Les attributs
internes peuvent être mesurés directement par le biais de leur entité, tandis que les attributs
externes sont mesurés dans l'environnement des entités. Pour les attributs externes nous
intéressons plutôt à leur comportement qu’à l'entité elle-même [Fenton & Pfleeger, 97].
Le code source est le produit logiciel créé par l'association des entités logicielles des
domaines des processus et des ressources. Il se compose d'une séquence d'instructions et / ou
de déclarations écrites dans un ou plusieurs langages de programmation. Le code source
représente l’implémentation du programme logiciel.
La mesure du logiciel
57
2.8.1 Les attributs du code source
Ces attributs représentent les traits caractéristiques du code source et seront aussi
classés en attributs internes et attributs externes.
Les attributs internes du code sources
Les attributs internes du code source détiennent des informations sur le code lui-même.
Les attributs internes suivants sont d'un intérêt particulier pour ce projet: la taille, le
contrôle de flux et autres aspects internes qui sont impliqués dans la structure du code
source. Il existe plusieurs métriques logicielles pour quantifier ces attributs. La mesure des
attributs internes du code source peut être effectuée de manière objective [Henderson, 96]
en raison de leur indépendance par rapport à autres entités logicielles. « LOC » par
exemple est une métrique logicielle qui permet de quantifier l'attribut interne « taille » de
l'entité code. Comme il sera expliqué dans le chapitre 3, LOC quantifie la taille en
comptant les lignes de code.
Les attributs externes du code sources
Les attributs externes du code source détiennent des informations sur le code et le
comportement du code (ses caractéristiques) au sein de son environnement [Fenton &
Pfleeger, 97]. Ces attributs doivent être quantifiés tout en considérant la façon dont le
code se rapporte à d'autres entités [Fenton & Pfleeger, 97]. Ainsi, les attributs externes du
code source sont difficiles à appréhender. Dans notre étude, nous intéressons à la
complexité et la maintenabilité du code source.
2.9 Mesure de la complexité du code source
La complexité du code est un facteur ayant un impact direct sur la durée de vie et
l’exploitation d’un logiciel, notamment sur son taux de défauts, sa testabilité et sa
maintenabilité. Par conséquent, la complexité a une influence directe sur la qualité et le coût
du logiciel [McCabe 76, Boehm, Clark, et al, 00 ; Sommerville, 04].
L’intérêt de quantifier la complexité du code est né après les années 1970 [Henderson,
96] et un certain nombre de mesures de complexité ont été proposées. Afin de mesurer cet
attribut, les chercheurs devaient d'abord comprendre ce que la complexité du logiciel.
La mesure du logiciel
58
Voici différentes définitions de la complexité du code dans la littérature du génie logiciel, ce
qui indique que les aspects de cet attribut ne sont pas encore bien compris.
2.9.1 Différentes perspectives de la complexité du logiciel
Bien qu’il y ait plusieurs mesures de la complexité du logiciel, ce concept n’est pas
encore bien défini. Evangelisti a écrit que «le terme de complexité n’est pas encore bien
défini, mais il est utilisé très souvent pour noter ce qui est appelé la complexité
psychologique: des caractéristiques du logiciel qui affectent la performance du programmeur
» [Evangelisti, 83]. Dans la littérature du génie logiciel, la complexité du logiciel est définie
comme suit :
IEEE définit la complexité du logiciel comme « le degré selon lequel un système ou un
composant a une conception ou une implémentation qui est difficile à comprendre et à
vérifier » [IEEE, 90].
Basili a défini la complexité du logiciel comme «une mesure des ressources dépensées
par un système (humain ou autre), tout en interagissant avec une pièce du logiciel pour
effectuer une tâche donnée» [Henderson, 96].
Pour Zuse, la complexité logicielle est «la difficulté à maintenir, modifier et comprendre
le logiciel» [Zuse, 91].
Ainsi, le terme complexité du logiciel est difficile à définir avec précision, mais peut-on
toujours mesurer la complexité du logiciel? D’après Fenton la quantification de la complexité
en une seule mesure est pratiquement impossible [Fenton ,94]. Au lieu de cela, les métriques
de complexité se concentrent sur certains aspects de la complexité : En quoi consiste la
complexité ? Qu’est ce qui influe sur la complexité d'un système? Comme le concept
«complexité du logiciel» n’est pas encore bien défini, les opinions divergent également quant
aux différents aspects de la complexité des logiciels.
Fenton a classé les aspects de la complexité en 4 classes: (1) Complexité du problème ;
(2) Complexité algorithmique (ou computationnelle) ; (3) Complexité structurelle (ou
complexité du produit) ; et (4) Complexité cognitive (ou psychologique). Tous ces aspects de
la complexité seront décrits dans le paragraphe ci-après.
La mesure du logiciel
59
L'approche d’Henderson Sellers [Henderson, 96] est discutée ici avec un peu plus de
détails. Il a classé la complexité du logiciel comme le montre la figure 2.4 en utilisant les
trois aspects suivants:
La complexité computationnelle fait référence aux ressources matérielles (par.ex, le temps du
processeur ou l’espace mémoire) requises pour exécuter le logiciel (c à d, un programme)
[Henderson, 96 ; Jones, 97]. Une mesure de la complexité du logiciel dans ce sens fournit un
indice du temps ou de l’espace mémoire requis pour exécuter le logiciel. Les algorithmes qui
sont difficiles à comprendre ne sont pas nécessairement computationnellement complexes
[Laird & Brennan, 06].
La complexité psychologique est liée à la difficulté de comprendre et de vérifier le logiciel
pour une personne / un programmeur [Zuse, 91 ; Henderson, 96]. Elle est utilisée pour
indiquer la difficulté d’une tâche sur le logiciel – ce qui exige une ressource humaine pour
réaliser des travaux sur le logiciel (par.ex, le codage, le test…). Dans ce cas, la complexité du
logiciel fait référence à l’effort de l’individu qui travaille sur le logiciel. De ce fait, elle est
appelée la complexité psychologique ou encore la complexité cognitive. Une mesure de la
complexité du logiciel dans ce sens fournit un indice de l’effort humain (par.ex, homme-mois
ou homme-heures) requis pour réaliser une tâche. La tâche à réaliser peut être spécifique
(par.ex, le codage, le débogage, le test) ou plus générale comme le développement ou la
maintenance du logiciel. Cet aspect de la complexité est donc très dépendant de la difficulté
du problème, la complexité du produit y compris les caractéristiques du logiciel (comme la
taille, le flux de contrôle ou le couplage) et les caractéristiques du programmeur [Henderson,
96].
la complexité du problème renvoie à la difficulté inhérente du problème, par exemple,
l’espace des échecs du problème. Il est supposé que les problèmes complexes sont
plus difficiles pour une personne / un programmeur de comprendre que les problèmes
simples. Ce type de complexité n'est pas contrôlable et difficiles à mesurer.
La complexité du produit (ou complexité structurelle) se préoccupe de la structure du
logiciel, par exemple la complexité du design. La complexité structurelle du logiciel
est considérée à deux niveaux: (1) la complexité intra-module qui fait référence à la
complexité d’un module individuel; et (2) la complexité inter-modules qui vient de la
complexité de relations entre les modules dans un système. Elle est souvent associée à
La mesure du logiciel
60
la facilité de comprendre le logiciel, et reflète la difficulté de coder, de tester et de
déboguer un programme. Ces difficultés affectent la performance de l’individu qui
travaille sur le logiciel et par conséquent l’effort de développement. Cependant, une
mesure de la structure du programme ne suffit pas à caractériser l’effort. Elle ne peut
être qu’une mesure additionnelle pour l’évaluer [DE TRAN, 05].
Les caractéristiques du programmeur traitent des traits individuels du programmeur
qui sont impliqués lors de l'exécution de tâches sur les produits logiciels. Quantifier
les caractéristiques du programmeur est difficile, surtout en l’absence de subjectivé
[Henderson, 96].
La complexité représentationnelle traite des compromis de représentation entre les notations
graphiques et les notations textuelles pour des représentations claires du système logiciel, son
environnement et les interactions au sein du système [Henderson, 96].
Dans cette approche de complexité du logiciel (présenté ci-dessus), Henderson Sellers a
considéré la vue de Zuse [Zuse, 91] et a introduit la complexité psychologique comme un
La complexité
La complexité
computationnelle
La complexité
psychologique
La complexité
représentationnelle
La complexité
du problème
Caractéristiques
du programmeur
La complexité
du produit =
La complexité
structurelle.
Les attributs
externes
Les attributs
internes est une sorte de relation
est composée de relation
Figure 2.4 Classification de la complexité logicielle
La mesure du logiciel
61
aspect important dans la complexité du logiciel. Comme le montre la figure 2.4, la
complexité psychologique se compose désormais des caractéristiques individuelles du
programmeur de la complexité du problème et la complexité structurelle. Ces deux dernières
composantes ont été perçues dans d'autres publications (par.ex, [Fenton & Pfleeger, 97] et
[Jones ,97]) en tant que composantes directes de la complexité du logiciel. Un modèle de
complexité du code appliqué à la complexité du produit comme un attribut interne est
présenté dans la section suivante.
2.9.2 Mesure de la complexité du code source
La structure d'un programme est mesurable à travers les attributs internes de son code
source (comme la taille et le couplage). Plusieurs métriques [Zuse, 91], appelé métriques de
complexité structurelle, ont été proposées afin d'atteindre cet objectif. Dans la littérature du
génie logiciel, la complexité structurelle est souvent désignée comme la complexité du produit
(le code source) [Fenton & Pfleeger, 97]. Une structure complexe rend difficile à comprendre
et à maintenir un produit logiciel. Les métriques de complexité structurelle proposées offrent
une surveillance (monitoring) de la complexité structurelle à travers l'évaluation d'une variété
d'aspects structurels. Ces aspects et par conséquent les métriques elles-mêmes peuvent être
classées comme suit: la taille, la structure logique, la structure de données, la cohésion, le
couplage et le flux d'information [Henderson, 96]. Grâce à la combinaison de ces métriques,
une prédiction de la complexité du produit peut être faite [Bauer, 99]. Cependant, elles
doivent être interprétés comme des indicateurs. [Henderson, 96 ; Fenton, 94]. Le chapitre 3
présente les métriques logicielles qui captent les aspects structurels du code source. Ainsi par
exemple, la métrique LOC mesure la taille d'un programme et la métrique de complexité
cyclomatique est utilisée pour quantifier la complexité structurelle logique.
2.10 La complexité vs la distribution du code source
Ici, par la distribution de code, on entend la façon dont le code source d'un programme
est organisé (distribué), dans son ensemble, sur un certain nombre de fichiers, de classes et de
méthodes (ou fonctions). A titre d'exemple, le code source d'un programme peut être placé
dans son intégralité dans une seule méthode dans un seul fichier, alors que pour le même
programme, dans une approche de distribution de code différente, le code peut être réparti sur
plusieurs méthodes dans différents fichiers. La figure 2.5 illustre ce concept.
La mesure du logiciel
62
L’approche de distribution du code source la plus appropriée est très dépendante du
projet, du langage de programmation utilisé, et de l'environnement [Khan, 02]. Ainsi, il
n'existe aucune approche optimale clairement définie pour la longueur textuelle des méthodes,
des classes et des fichiers. Néanmoins, différentes vues sur la longueur textuelle existent dans
la littérature du génie logiciel [Khan, 02 ; Emam, 02]. Dans ce mémoire, la discussion autour
d'un idéal possible de la longueur maximale (taille) n'est pas d'intérêt. Ce qui est intéressant
est le choix réel de la taille et la distribution du code. Avant d’expliquer la relation entre la
distribution et la complexité du code, deux points importants sur la distribution du code
doivent être examinés:
(1) Les fichiers, les classes et les méthodes de taille importante8 (taille exprimée en lignes de
code) sont potentiellement difficiles à comprendre [Klemola, 00]. Pour le cerveau humain, il
est plus facile de comprendre des information relatives à un sujet information par information
plutôt que l’ensemble des ces informations à la fois [Klemola, 00]. Toutefois, pour être en
8 A quel point un fichier, une classe, ou une méthode doivent être considérés comme long (de taille importante) est difficile
de se prononcer [McConnell, 04]. Comme exposé ci-dessus, le but de l'aspect de distribution du code source dans ce mémoire
n'est pas de définir une longueur (ou taille) optimale, mais plutôt de comprendre quelle distribution du code est utilisée par un
programme particulier.
Figure 2.5 Différentes approches pour la distribution du code source
La mesure du logiciel
63
mesure de diviser ces informations en morceaux appropriés, un aperçu global et raisonnable
de celles-ci doit être construit. A titre d'exemple, les livres et les articles scientifiques sont
organisés en plusieurs chapitres et sections. Ainsi, les auteurs présentent les informations
complètes dans des unités de présélectionne pour aider les lecteurs à suivre leur argument.
Combien, il est difficile de suivre et de comprendre un chapitre ou une section (ou un
morceau de code source) dépend aussi du lecteur et donc quelque peu subjectif.
(2) L'utilisation d'un grand nombre de fichiers, de classes et de méthodes peut aider à diviser
l'information (le code source d'un programme) en petits morceaux facilement gérables. Plus
ce nombre est grand, la longueur textuelle de ces morceaux se voit réduite davantage,
conduisant ainsi à de petites sections de code facile à comprendre. Cependant, une telle
division (distribution du code) rend plus difficile l'organisation d’un programme. On entend
par là que si le code est distribué sur un seul fichier, les programmeurs responsables de la
maintenance du système savent exactement où regarder pour le code. Quand un programme
est constitué d'un grand nombre de fichiers, la tâche de trouver un fichier particulier, peut très
vite devenir difficile et sera fortement dépendante de la façon dont ces fichiers sont organisées
(dans des répertoires et sous répertoires…,etc.). Un grand nombre de classes conduit à une
conception relativement complexe et difficile à comprendre. Il en va de même avec un grand
nombre de méthodes au sein d'une classe ou un fichier.
En résumé, un équilibre entre la longueur textuelle des sections et la distribution du
code devrait être trouvé. Les longues sections de code sont moins souhaitables, mais d'autre
part, les courtes sections ne fournissent pas toujours une solution idéale [McConnell, 04].
Cependant, pour comprendre la complexité d'une section de code, l'organisation effective du
code entre les méthodes, les classes et les fichiers, autrement dit la distribution du code, doit
être connue à l'avance.
Les métriques de complexité mesurent particulièrement les aspects quantifiables du
code source d’un programme, d’un fichier, d’une classe ou d’une méthode. Ainsi, la valeur de
la mesure est attribuée en conséquence ; à un programme, à un fichier, à une classe ou une
méthode. Pour comprendre la mesure individuelle, la mesure doit être considérée en relation
avec l'environnement du champ d'application connexe. En considérant, par exemple, la
mesure du poids d'une personne inconnue, on ne peut pas se prononcer sur la valeur de cette
mesure sans avoir vu la personne ou sans avoir envisagé d’autres mesures de celle-ci, par
La mesure du logiciel
64
exemple, la hauteur de la personne, son âge ou son sexe. Ainsi, nous avons consulté d'autres
caractéristiques de la personne physique avant de pouvoir porter un jugement sur la valeur de
cette mesure (ici le poids). Il en va de même pour la mesure de la complexité d’un
programme. En effet, une valeur de 500 pour la mesure de la complexité d’un programme
donné, ne veut absolument dire grand-chose, à moins de consulter ce programme en détail ou
d’envisager d’autres mesures décrivant l’environnement de ce dernier. La distribution du code
d’un programme peut ainsi être considérée comme analogue à l'information de la hauteur de
la personne dans l’exemple de la mesure du poids.
Conclusion
Une métrique de qualité logicielle est définit comme une échelle quantitative et une
méthode qui peuvent être employées pour déterminer la valeur que prend un attribut d’une
entité d’un logiciel (ISO/IEC 9126). Une échelle de mesure étant l’ensemble constitué de la
méthode de mesure et les systèmes des relations empiriques et numériques [Guéhéneuc, 06].
La mesure du logiciel est le processus d'application des métriques logicielles dans le but de
quantifier les attributs spécifiés d'entités logicielles pour obtenir des informations utiles sur
l'entité elle-même.
Les principaux avantages de la mesure du logiciel sont le contrôle, la compréhension
et l'amélioration. Les inconvénients sont l'absence de normes et le manque d'expérience pour
obtenir des informations significatives.
Les aspects de la théorie de la mesure, les attributs internes et externes du code source
constituent les fondations pour les chapitres suivants. La définition et la signification d'une
métrique logicielle particulière doivent être présentes à l'esprit lors de l’interprétation de la
mesure produite.
L’une des difficultés de mesure des attributs internes est la complexité du code. La
complexité du code ne peut être capturé en une seule mesure [Fenton & Pfleeger 97, Fenton
94]. Pour décrire la complexité du code, des métriques logicielles ciblant différents aspects
de la complexité du logiciel doivent être combinées. En outre, les aspects de la distribution du
code d'un programme doivent être considérés lors de l’interprétation des mesures produites.
Les métriques statiques du code source
66
Chapitre 3.
Mesure des attributs internes du produit logiciel -
les métriques statiques du code source
Les attributs internes du produit logiciel (spécification, conception, code source et
données de test, voir figure 2.2) décrivent les produits logiciels d'une manière qui ne dépend
que du produit lui-même. Ils peuvent être mesurés très tôt dans le cycle de développement du
logiciel et ont un impact direct sur ses attributs externes. Avoir une bonne structure interne
résulte en une bonne qualité du produit. Autrement dit, agir sur la structure interne permet de
contrôler la qualité du produit. L'attribut le plus évident et le plus utile est la taille du logiciel,
qui peut être mesurée de façon statique, sans avoir à exécuter le logiciel. Fenton et Pfleeger
[Fenton & Pfleeger, 97] ont suggéré que la taille du logiciel peut être décrite avec trois
attributs clé : la longueur (la taille physique du produit), la fonctionnalité (mesure des
fonctions fournies par le produit à l'utilisateur) et la complexité (peut être interprétée de
différentes manières, en fonction de notre point de vue ; il peut s’agir de la complexité du
problème, de la complexité algorithmique, de la complexité structurelle ou encore de la
complexité cognitive. (cf. 2.9 Mesure de la complexité du code source).
Dans le cadre de notre étude, nous nous intéressons à l’entité code source du produit
logiciel. Nous examinerons différentes façons de mesurer l’attribut la taille du programme
(code source). Nous commençons par examiner les approches traditionnelles de mesure de la
taille, en soulignant les pièges de cette approche. Nous examinerons par la suite d'autres
approches comme l'orientation objet et la programmation visuelle. Nous considérons
également la réutilisation (dans la mesure où le logiciel est vraiment nouveau), car elle est
généralement exprimée en termes de taille de produit réutilisé. Pour chacun de ces attributs,
nous décrivons une série de mesures appropriées.
En plus de l’attribut taille du logiciel, il existe d'autres attributs internes utiles. Les
praticiens et les chercheurs pensent qu'il peut y avoir un lien entre la structure des produits et
leur qualité, beaucoup essaient de mesurer les propriétés structurelles du logiciel. En d'autres
termes, la structure des besoins, de la conception et du code qui peuvent nous aider à
Les métriques statiques du code source
67
comprendre la difficulté que nous avons parfois lors de la conversion d'un produit à un autre
(comme, par exemple, l’implémentation d’une conception sous forme de code), ou dans le test
d'un produit (par exemple, le test du code source ou la validation des exigences) ou encore
pour prédire les attributs externes du logiciel à partir des mesures internes du produit. Bien
que les mesures structurelles varient en ce qu'elles mesurent et comment elles mesurent, elles
sont souvent appelées « métriques de complexité». La structure du produit logiciel se
compose, d’après Fenton, de trois 03 parties : (1) la structure du flot de contrôle (la séquence
d’exécution des instructions du programme), (2) la structure du flot de données
(comportement des données en interagissant avec le programme) et (3) la structure de
données (l’organisation des données, indépendamment du programme). Pour le reste de notre
étude, nous nous limiterons uniquement à la structure du flot de contrôle du code.
Nous terminons le chapitre par la discussion des métriques utilisées pour la mesure
des structures orientées objet.
3.1 La taille du programme
Le code source est une entité physique; en tant que telle, elle peut être décrite en
termes de sa taille. Les objets physiques sont facilement mesurables (en termes de longueur,
de volume, de masse, ou autre mesure standard), mesurer la taille du code devrait être simple,
relativement simple et compatible avec les principes de la théorie de mesure. Toutefois, en
pratique, la mesure de la taille présente de grandes difficultés. D’après Fenton [Fenton &
Pfleeger, 97], des notions comme l'effort, la fonctionnalité, la complexité, la redondance et la
réutilisation sont liées aux mesures choisies et la façon dont ces mesures sont utilisées. Les
mesures simples de la taille sont souvent rejetées parce qu'elles ne reflètent pas correctement:
• l'effort: elles ne tiennent pas compte de la redondance et de la complexité;
• la productivité: elles ne tiennent pas compte de la fonctionnalité réelle et de l'effort;
• et le coût: elles ne tiennent pas compte de la complexité et la réutilisation.
Par exemple, Conte, Dunsmore, et Shen affirment que:
« … il y a un problème majeur avec la mesure des lignes de code: la consistance, car
certaines lignes sont plus difficiles à coder que d'autres .... Une solution au problème est
d’attribuer plus de poids aux lignes qui ont plus de complexité en matière de codes… »
[Conte, Dunsmore & Shen, 86]
Les métriques statiques du code source
68
Rejetant les mesures simples de la taille pour ces motifs témoigne d'une
méconnaissance des principes de base de la mesure. Ceux qui rejettent une mesure parce
qu'elle ne fournit pas suffisamment d'information, ils attendent peut être trop d'une mesure
unique. Considérons l'analogie suivante:
Si la taille d’une personne est mesurée avec un seul attribut, par exemple la hauteur, alors
nous pouvons l'utiliser pour prédire si une personne peut franchir une porte sans s’abaisser.
Cette application de la définition de la hauteur permet une mesure utile. Cependant, nous ne
pouvons pas utiliser cette mesure pour affirmer si une personne est obèse ou non. De même, si
on utilise le nombre de lignes de code pour mesurer la taille du code, cette mesure n'est pas
utile pour mesurer la qualité du code. Cependant, on ne peut nier sa valeur pour prédire
l'espace fichier dont on a besoin pour le sauver sur disque.
Maintenant, si la taille de la personne est mesurée en termes de deux attributs, par exemple la
hauteur et le poids, alors nous pouvons utiliser cette mesure pour dire (sur la base d'une
compréhension empirique) si une personne est obèse. Cependant, nous ne pouvons pas
l'utiliser pour déterminer avec quelle vitesse une telle personne peut se déplacer. De même,
les modèles qui définissent un attribut en fonction de plusieurs attributs internes peuvent être
utiles, même s’ils ne sont pas complets.
Le code peut être produit de plusieurs façons. L'approche la plus traditionnelle
consiste à utiliser un langage procédural. Mais, il existe d'autres alternatives, comme
l'orientation objet et la programmation visuelle, qui rendent difficile la mesure traditionnelle.
3.1.1 Les lignes de code
La mesure la plus couramment utilisée pour le code source est le nombre de lignes de
code LOC (Line Of Code). Mais les lignes de code sont souvent différentes les unes des
autres. Par exemple, beaucoup de programmeurs utilisent des lignes d'espacement et des
blancs pour rendre leurs programmes plus faciles à lire. Si les lignes de code sont utilisées
pour estimer l’effort de codage, alors une ligne vierge ne contribue pas de la même façon dans
l’estimation de cet effort qu'une ligne qui implémente un algorithme difficile. De même, les
lignes de commentaires améliorent la compréhension d’un programme, et elles demandent
certainement un effort pour les écrire. Mais ils ne peuvent pas exiger autant d'efforts que le
code lui-même. Nous devrons donc prendre grand soin de préciser ce que nous comptons et
Les métriques statiques du code source
69
comment nous le comptons. En particulier, nous devrons expliquer comment chacun des
éléments suivants sera traité:
• les lignes vides ;
• les lignes de commentaires ;
• les déclarations de données ;
• et les lignes qui contiennent plusieurs instructions séparées.
Jones rapporte que la taille d’un programme peut être jusqu'à cinq fois plus grande que la
taille d’un autre, tout simplement en raison de la différence dans la technique de comptage
utilisée [Jones, 86].
Il existe un consensus général sur le fait d’ignorer les lignes vides et les commentaires
dans le calcul de LOC. Conte, Dunsmore, et Shen définissent une ligne de code comme une
ligne de texte du programme qui n'est pas un commentaire ou une ligne vide, quel que soit le
nombre de déclarations ou de fragments de déclarations sur la ligne. Cette définition inclut en
particulier toutes les lignes contenant les entêtes du programme, les déclarations et les
instructions exécutables et non-exécutables [Conte, Dunsmore & Shen, 1986]. Grady et
Caswell reportent que Hewlett-Packard définit une ligne de code comme "a non-commented
source statement9" : toute instruction dans le programme excepté les commentaires et les
lignes vides [Grady & Caswell, 87].
La définition de Hewlett-Packard d'une ligne de code est la plus largement acceptée.
Pour insister sur le fait qu'une ligne de code selon cette définition est en fait une ligne de code
non commentée, nous utilisons l'abréviation NCLOC (Non-Comment Lines of Code), parfois
aussi appelées lignes de code effectives ELOC (Effective lines of code). Le modèle associé à
cette définition voit un programme comme un simple fichier, avec les commentaires et les
lignes vides supprimés.
9 Statement : The smallest executable entity within a programming language.
Microsoft Computer Dictionary - Microsoft Press; 5th ed. edition (March 22, 2002).
Statement :a single instruction in a computer programming language. One statement may consist of several operations, such
as X = Y+Z/W (a division, an addition, and an assignment).
Dictionary of Computer and Internet Terms, Tenth Edition - (Apr. 1, 2009) by Douglas Downing Ph.D., Michael
Covington Ph.D., Melody Maudlin Covington and Catherine Anne Covington
Les métriques statiques du code source
70
Dans un sens, des informations utiles sur la taille du programme (le code source) sont
perdues lorsque cette définition est utilisée. Dans de nombreuses situations, la taille effective
du programme (y compris les blancs et les commentaires) est importante pour décider
combien d’espace disque est requis pour son stockage dans un fichier, ou combien de pages
sont nécessaires pour une éventuelle impression de ce fichier. Ici, la taille du programme doit
tenir compte des lignes vides et commentées. Ainsi, NCLOC n'est pas une mesure valide dans
ce sens. Maintenant, si la taille du programme est liée à l’effort d’un point de vue évaluation
de la productivité, alors NCLOC peut être une entrée valide. En guise de compromis, nous
recommandons que le nombre de lignes de commentaire de texte du programme CLOC
(Comment Lines of Code) soit mesurée et enregistrée séparément. Ensuite, on peut définir :
Et quelques mesures utiles indirectes suivront. Par exemple, le rapport:
qui mesure la densité de commentaires dans le programme, ce qui donne une indication de la
façon dont le code est auto-documenté.
3.1.2 Les constructions de programmation
La taille du programme peut également être mesurée en termes de nombre de
constructions de programmation utilisées dans le code. Le nombre de constructions est
indépendant du nombre de lignes, car plusieurs constructions peuvent apparaître sur une
même ligne :
Nombre d’instructions (Statements) #STAT
La métrique # STAT compte le nombre total d’instructions dans le programme. Une ligne de
code source peut contenir plusieurs instructions. Par conséquent, le nombre d’instructions
peut être plus élevé que le nombre de lignes de code non commentées NCLOC.
La longueur de Halstead du programme (Halstead lenght HL)
Il s'agit d'une métrique textuelle, elle vise à évaluer la taille d'un programme en fournissant
une alternative au calcul du nombre de lignes de code source. La métrique HL est basée sur
La longueur totale (LOC) = NCLOC + CLOC
CLOC / LOC
Les métriques statiques du code source
71
l'interprétation du code comme une séquence de marqueurs, classifiés chacun comme étant un
opérateur10
ou une opérande11
. HL est définie comme suit :
Où
· (N1) est le nombre total d'opérateurs;
· (N2) est le nombre total d'opérandes.
Ainsi, HL est une métrique bien définie. Elle est définie en termes de nombre total
d'opérateurs et d'opérandes (N1 et N2) qui sont calculés en collectant les fréquences de
chacun des opérateurs et opérandes pris dans le programme source.
La taille du programme en octets (bytes) et en nombre de caractères (CHAR)
Pour définir la longueur du code différemment, il nous reste encore deux solutions à explorer :
1- Nous pouvons mesurer la longueur en termes du nombre d'octets (bytes) de stockage
nécessaire pour le texte du programme. Cette approche a l'avantage d'être sur la
même échelle que la mesure normale de la taille du code objet. Elle est aussi bien
comprise que LOC, et facile de collecter.
2- Nous pouvons mesurer la longueur en termes du nombre de caractères (CHAR) dans
le texte du programme.
Ces mesures de longueur, ainsi que le nombre de lignes de code, sont acceptables par la
théorie de la mesure en tant que des mesures de type ratio, nous pouvons donc passer d’une
mesure à une autre en multipliant par une constante empirique appropriée. En effet, si α est le
nombre moyen de caractères par line de code, alors nous pouvons exprimer le nombre de
caractères CHAR en termes de ligne de code LOC comme suit :
De même, nous pouvons utiliser n'importe quel multiple constant des mesures proposées
comme alternative de mesure valide de la longueur. Ainsi, nous pouvons utiliser
KLOC (milliers de lignes de code) ou KDSI (milliers d'instructions source livrées) pour
mesurer la taille d’un programme. Cependant, de nombreuses personnes soutiennent qu’une
ligne de code dépend du langage de programmation utilisé, ainsi une ligne code APL ou LISP
est très différente d'une ligne de code BASIC, C ++ ou Ada. Certains praticiens utilisent les
10 Les opérateurs sont tous les mots clés d'un langage de programmation (comme par.ex, While, For , Switch, …) et les
symboles, qui représentent une action (comme par.ex, =, +, &, …).
11 Les opérandes sont tous les éléments du code qui représentent les données (par.ex, les variables et les constantes).
HL = N1 + N2
CHAR = α LOC
Les métriques statiques du code source
72
facteurs de conversion, de sorte qu’un module de k lignes de code APL est considéré comme
équivalent à α k lignes de code C, pour une certaine valeur appropriée de α .Cette conversion
est important si nous devrions utiliser LOC pour mesurer la fonctionnalité et l'effort, plutôt
que la longueur d’un programme.
3.1.3 Quelles sont les limites acceptables ?
La longueur des fonctions devrait être de 4 à 40 lignes de programme. Une définition
de fonction contient au moins un prototype, une ligne de code, et une paire d'accolades, qui
font 4 lignes. Une fonction plus grande que 40 lignes de programme implémente
probablement beaucoup de fonctions. Les fonctions contenant un état de sélection avec
beaucoup de branches sont une exception à cette règle. Les décomposer en des fonctions plus
petites réduit souvent la lisibilité.
Les fonctions trop longues pourraient être décomposées en plusieurs fonctions plus
petites. Les fonctions de longueur inférieure à 40 ont une taille correcte. La longueur du
fichier devrait être de 4 à 400 lignes de programme. La plus petite entité qui peut
raisonnablement occuper un fichier source complet est une fonction, et la longueur minimum
d'une fonction est de 4 lignes.
Les fichiers plus longs que 400 lignes de programme (10..40 fonctions) sont
habituellement trop longs pour être compris en totalité. Au minimum 30 % et au maximum
75 % d'un fichier devrait être commenté. Si moins d'un tiers du fichier est commenté, le
fichier est soit très trivial, soit pauvrement expliqué. Si plus de trois quarts du fichier est
commenté, le fichier n'est plus un programme, mais un document. Dans un fichier header
correctement commenté, le pourcentage de commentaires peut parfois dépasser 75%
[Lambertz].
Les métriques statiques du code source
73
3.1.4 Les nouvelles approches pour la mesure du code source
Il existe un autre aspect de dépendance du langage de programmation qui pose un
problème. En effet, La plupart des mesures de code supposent que le code se compose
uniquement de texte. Jusqu'aux années 1990, cette hypothèse a été presque toujours vrai.
Cependant, l'avènement de la programmation visuelle et les environnements de fenêtrage (et
pour le moins, l'orientation objet et les langages de quatrième génération12
) a radicalement
changé notre notion de ce qu’un programme est.
Dans l'environnement de programmation Visual Basic ™, nous pouvons créer un
programme Windows sophistiqué, avec des menus, des icônes, et des graphiques, avec
presque aucune ligne de code dans le sens traditionnel du terme. Par exemple, le code
exécutable pour produire une barre de défilement est généré et inséré automatiquement après
avoir glissé l'objet barre de défilement dans la fenêtre de l’application. Nous nous contentons
seulement d’écrire le code pour effectuer des actions spécifiques qui résultent par exemple
d’un clic sur un bouton de commande spécifique.
Dans de tels environnements, il n'est pas du tout clair comment on pourrait mesurer la
longueur du programme. A cela, s’ajoute le fait que la longueur du code classique peut être
négligeable, par rapport à la longueur des objets fournis par l'environnement et d'autres objets
graphiques. Ainsi, un programme avec seulement cinq lignes de code comportant des
instructions simples peut facilement générer un programme exécutable de 200 Ko.
Ces nouvelles approches de programmation soulèvent le problème de mesure suivant:
Comment peut-on compter dans nos mesures de longueur les composants construits en
externe et référencés à partir du programme (cas des objets ActiveX, des plug-ins ou du code
généré automatiquement par l’environnement)?
Ici, il s’agit d’un aspect de réutilisation du code et il sera discuté dans la section 3.1.5.
12 Les langages de quatrième génération (4GL), conçus pour l’interaction avec le programmeur, qualifient souvent les
langages propres aux bases de données. Se situant un cran au-dessus des langages tels que le C++ ou le COBOL (langages de
troisième génération), ils se composent d’un jeu d’instructions s’apparentant à des macro-instructions, séquences
d’instructions prédéfinies auxquelles on accède par une commande très simple. Toutefois, ces langages conservent un aspect
hybride, dérivant le plus souvent des langages évolués. Exemples : Microsoft Access, Visual FoxPro (propriétaire,
abandonné en 2007), WinDev, …
Les métriques statiques du code source
74
Le développement orienté objet suggère également de nouvelles façons de mesurer la
longueur. Pfleeger a constaté que le comptage des objets et des méthodes conduit à des
estimations plus précises de la productivité que celles utilisant les lignes de code [Pfleeger,
89]. Lorenz a trouvé de ses recherches à IBM qu’une classe contient en moyenne 20
méthodes, et la longueur moyenne d’une méthode était de 8 lignes de code pour Smalltalk et
24 lignes pour C++. La classe contient 6 attributs d'objet ou d'instances variables
[Lorenz, 93].
Il note également que la taille diffère avec le système et le type d'application. Par exemple,
les classes de prototype ont de 10 à 15 méthodes, chacune de 5 à 10 lignes de code, alors que
les classes de production ont de 20 à 30 méthodes, chacune avec 10 à 20 lignes de code. Les
systèmes C++ nécessitent deux à trois fois plus de code que les systèmes Smalltalk.
Williams, au Space Telescope Science Institute à Baltimore, Maryland, a étudié la taille des
logiciels orientés objet dans le cadre d'une étude approfondie pour identifier les principaux
facteurs dans la mesure de la fonctionnalité et la productivité. Il recommande d'utiliser le
nombre de classes, les fonctions et les interactions de classe pour exprimer la taille
[Williams, 94].
3.1.5 La réutilisation
Les générateurs de programmes, les langages de quatrième génération 4GL, les
environnements de fenêtrage, et d'autres techniques profitent de la répétitivité de certaines de
nos tâches. Nous n’avons pas besoin d'écrire une autre routine de tri ou un OCR13
s’ils
existent déjà dans d'autres produits. Nous utilisons régulièrement des systèmes d'exploitation,
des compilateurs, des systèmes de gestion de base de données SGBD, et des bibliothèques de
routines mathématiques, plutôt que d’écrire nos propres routines. Cette réutilisation de
logiciels (y compris les exigences, la conception, la documentation, les données de test et les
scripts ainsi que le code) améliore la productivité et la qualité, ce qui nous permet de se
concentrer sur les vrais (nouveaux) problèmes, plutôt que de continuer de résoudre des
anciens problèmes pour lesquels des solutions fiables existent déjà.
13
OCR (Optical Character Recognition) Reconnaissance Optique de Caractère. Désigne une technique par laquelle des
caractères d'un document digitalisé, considérés comme des images, sont récupérés comme caractères. On rencontre souvent le
terme lorsqu'il est question de scanners.
Les métriques statiques du code source
75
Compter le code réutilisé n'est pas aussi simple qu'il paraît. Il est difficile de définir
formellement ce que nous entendions par un code réutilisé. Parfois nous réutilisons des
programmes entiers sans modification, mais le plus souvent on réutilise certaines unités de
code (un module, une fonction ou une procédure) sur lesquelles nous portons des
modifications plus au moins importantes. Cependant, nous devrions prendre compte dans nos
mesures de longueur du code réutilisé. Nous voulons distinguer un module avec une ligne
modifiée d'un module avec 100 lignes modifiées. A cet effet, nous considérons la notion de
l’étendue de la réutilisation (extent of reuse), mesurée sur une échelle ordinale par la
NASA/Goddard's Software Engineering Laboratory de la façon suivante (Software
Productivity Consortium, 1995) :
1. Réutilisation textuelle « «mot par mot » (Reused verbatim): le code de l'unité a été
réutilisé sans aucune modification ;
2. Légèrement modifiée (Slightly modified): moins de 25% des lignes de code dans
l'unité ont été modifiées ;
3. Largement modifiée (Extensively modified): 25% ou plus des lignes de code ont été
modifiées ;
4. Nouvelle (New): ici le code ne provient d'aucune des unités construites précédemment.
Cette classification peut être simplifiée et réduite à deux niveaux, nouvelle (niveaux 3 et 4)
ou réutilisée (niveaux 1 et 2).
Hewlett-Packard considère trois niveaux de code: le nouveau code écrit (new code), le code
réutilisé (reused code) et le code modifié (leveraged code). Dans cette terminologie, le code
réutilisé est utilisé tel quel, sans modification, tandis que le code modifié est le code existant
qui est modifié d'une certaine façon. Pour Hewlett-Packard le taux de réutilisation de code
comprend à la fois le code réutilisé et le code modifié en tant que le pourcentage total du code
livré.
Pour un programme donné, on peut donc définir la taille du code en termes de taille
totale et de proportion de réutilisation.
Les métriques statiques du code source
76
3.2 La distribution du code
La section 2.10 illustre l'importance de considérer les aspects de distribution du code
pour l'interprétation des mesures du produit logiciel. Cette section donne un bref aperçu sur la
façon dont la distribution du code peut être quantifiée.
3.2.1 La mesure du code distribué
La distribution du code d'un programme peut être mesurée en termes de la taille (la
longueur) des fichiers considérés individuellement, des classes et méthodes, des classes et
méthodes ensemble avec le nombre de ces fichiers. Les fichiers, les classes et les méthodes
sont considérés comme les sections de code qui détiennent les parties du code. Les métriques
suivantes mesurent pour un groupe de sections définies (par exemple, toutes les méthodes) la
distribution du code à travers ces sections de code.
3.2.2 Les métriques pour la mesure du code distribué
Le nombre de sections du programme
Pour compter le nombre de sections d’un programme (code source) spécifique, nous utilisons
les métriques suivantes :
- Le nombre de fichier (# files) ;
- Le nombre de classes (#classes) ;
- Le nombre de méthodes (# methods).
Combinées avec la métrique taille du programme LOC, ces mesures peuvent nous fournir des
informations utiles sur l'organisation du programme. Par exemple, le rapport
LOC / #files donne le nombre moyen de lignes de code par fichier. Même dans le cas d’un
programme monolithique, où tout le code est contenu dans un seul fichier, ce rapport reste
valable.
Taille par section du programme
Les métriques de mesure de la taille par section du programme mesurent la taille (longueur)
pour des sections particulières de code (par exemple les méthodes). Comme métrique de
taille, nous pouvons choisir l'une des métriques de la taille du programme listées en 3.1. Par
exemple, le nombre d’instructions (#STAT) par méthode. Ici, des méthodes extrêmement
Les métriques statiques du code source
77
longues peuvent être difficiles à comprendre. Reportez-vous à la section 2.10 pour les aspects
de distribution du code.
Les métriques de distribution du code sont simples à comprendre et à calculer. Afin de
comprendre la distribution du code d'un programme spécifique, d’autres paramètres, hormis
les valeurs moyennes (par exemple, la valeur moyenne de LOC par fichier), doivent être
considérés.
3.3 La complexité du code (les métriques de Halstead)
La complexité du code est un facteur ayant un impact direct sur la durée de vie et
l’exploitation d’un logiciel, notamment sur son taux de défauts, sa testabilité et sa
maintenabilité. Par conséquent, la complexité a une influence directe sur la qualité et le coût
d’un logiciel [Lambertz].
3.3.1 Science du logiciel de Halstead
Les métriques de complexité de Halstead ont été développées par l’américain Maurice
Halstead, elles ont été introduites en 1977 et ont été utilisées et expérimentées intensivement
depuis ce temps-là. Elles procurent une mesure quantitative de complexité et font partie des
plus vieilles mesures de complexité de programme.
Elles sont basées sur l’interprétation du code comme une séquence de marqueurs
(appelés aussi jetons ou tokens en Anglais), classifiés comme un opérateur ou une opérande.
Halstead ira jusqu’à corréler ses formules avec le calcul du nombre d’hommes-mois
nécessaires au développement d’un programme. Du fait qu'ils soient appliqués au code, ils
sont plus souvent utilisés comme une métrique de maintenance. Il est évident que les mesures
Halstead sont aussi utiles durant le développement, pour accéder à la qualité du code dans les
applications denses. Puisque l'entretien devrait être un souci pendant le développement, les
mesures de Halstead devraient être utilisées durant le développement du code, afin de suivre
les tendances de complexité [Lambertz].
Les métriques de Halstead sont un bon exemple de la façon dont un ensemble de
métriques dérivées peuvent être créés à partir d'un ensemble de métriques simples. Dans la
section suivante, nous présenterons les différentes métriques de Halstead.
Les métriques statiques du code source
78
3.3.2 Les métriques de complexité de Halstead
La base des mesures est fournie par le vocabulaire utilisé. On évalue le nombre
d’opérateurs et d’opérandes.
n1 = nombre d’opérateurs uniques ;
n2 = nombre d'opérandes uniques ;
N1 = nombre total d’apparition de ces opérateurs ;
N2 = nombre total d’apparition de ces opérandes.
Basée sur ces quatre mesures, Halstead a proposé les définitions suivantes:
La longueur du programme HL (expliquée en 3.1.2 et reprise brièvement ici):
Cette mesure est le nombre total de tokens utilisés dans le programme. N est la taille du
programme en termes de tokens utilisés au lieu de lignes de code.
Le vocabulaire du programme (Hvoc):
Cette mesure est le nombre total de tokens uniques dans le programme.
Le volume du programme (HV):
Selon Halstead, V est l’effort mental requis pour faire les comparaisons lorsqu’on écrit un
programme de longueur N. Halstead estime que pendant la composition d’un programme de
taille N, le programmeur réalise une recherche dichotomique pour chaque token utilisé et le
récupère de sa mémoire. S’il y a n tokens différents, alors le temps de recherche dichotomique
est log2(n). La recherche est faite N fois pour un programme de N tokens. Alors, le
programmeur doit fournir un effort total N*log2(n) pour réaliser les recherches pendant la
composition du code. Cette mesure est appelée le volume du programme.
Le calcul de V est basé sur le nombre d'opérations effectuées et d'opérandes gérées dans
l'algorithme. Par conséquent V est moins sensible à la disposition du code que les mesures de
lignes de code. Le volume d'une fonction devrait être au moins de 20 et au plus de 1000. Le
volume d'une fonction, d'une ligne et sans paramètres, qui n'est pas vide est d'environ 20. Un
N = N1 + N2
n = n1 + n2
V = N log2(n)
Les métriques statiques du code source
79
volume plus grand que 1000 indique de la fonction comporte probablement trop de choses. Le
volume d'un fichier devrait être d'au moins 100 et au plus 8000. Ces limites sont basées sur
les volumes mesurés pour les fichiers pour lesquels ELOC (Effective lines of code) et v(G)
sont près de leurs limites recommandées [Bouttery, 07].
Si, nous considérons que le vocabulaire reste stationnaire à un certain degré de complexité, et
tout particulièrement pour les grands programmes. Dans ce cas, la formule est modifiée
comme suit : V’=N.
La difficulté du programme (HD):
La difficulté d'un programme D est définie comme le produit du nombre d'opérateurs uniques
n1 par le nombre total d’opérandes utilisés N2, le tout divisé par deux fois le nombre
d’opérandes uniques n2.
La difficulté du programme est destinée à mesurer la difficulté pour implémenter le
programme.
Dans le cas de grands programmes, nous supposons que les valeurs n1 et n2 deviennent
constantes: kd. Dans ce cas, la formule est modifiée de la manière suivante : D’ = kd×N2
Nous considérons ainsi que la difficulté d'écriture du programme est basée sur le nombre total
d'opérandes N2 !
L’effort requis pour composer le programme (HE):
L'effort d'un programme E est défini comme le produit de la difficulté D et le volume V du
programme. L’unité de mesure E est la discrimination mentale requise pour comprendre le
programme. Selon le résultat d’études en psychologie faites par John Stroud, un individu peut
faire un nombre de 5 à 20 discriminations par seconde [Stroud, 67]. Halstead estime que dans
le contexte de composer un programme, un programmeur peut faire 18 discriminations par
seconde, donc un programme qui a besoin d’un effort E peut être écrit dans E/18 secondes.
D = (n1×N2)/2×n2
E = D×V
Les métriques statiques du code source
80
Si, nous considérons que, pour les grands programmes : D’ = kd×N2 et V’ = N alors
E’ = D’×V’ = kd×N2 × N = (N1 + N2) × kd × N2
Ce qui montre l’impact de N, et tout particulièrement N2 dans le calcul de l’effort requis.
L’exemple suivant illustre l’application des mesures de Halstead à un petit programme Java.
L’exemple est reproduit de l’article de Robin Mueller-Bady [Robin.M].
Les résultats des mesures de Halstead de l’exemple sont donnés dans le tableau suivant :
Les métriques statiques du code source
81
3.3.3 Commentaires sur les métriques de Halstead
Les métriques logicielles de Halstead sont basées sur des mesures quantifiables et
peuvent donc être calculées facilement. Toutefois, les règles pour identifier les opérateurs et
les opérandes doivent être déterminées pour chaque langage de programmation.
Les trois premières mesures (N, n et V) pourraient être considérées comme des
mesures raisonnables pour la taille, mais les deux dernières (D et E) sont très difficiles à
interpréter. Fenton indique qu’il n’y a pas de consensus sur des attributs comme le volume et
la difficulté. Et la relation entre le système de relation empirique (le monde réel) et le modèle
mathématique n’est pas claire. Donc, les deux mesures D et E de Halstead ne satisfont pas la
théorie de la mesure [Fenton & Pfleeger, 97]. Cependant, Halstead estime que ses mesures
sont testées empiriquement et qu’elles donnent des résultats cohérents avec l’expérience
pratique [Halstead, 77]. Ses travaux s’appuient sur certains résultats de recherche sur la
cognition humaine tels les résultats d’études en psychologie de John Stroud.
Les mesures de Halstead font référence à la taille plutôt que la complexité du code. En
fait, la formule de l’effort dépend du volume du programme, c’est-à-dire, du nombre de
tokens traités par le programmeur plutôt que de la relation entre les tokens. De ce fait, la
mesure d’effort (E) de Halstead n’est pas très bien corrélée avec l’effort réel de
développement. Basili a comparé la mesure d’effort de Halstead avec certaines autres
mesures, y compris les lignes de code. Le résultat d’analyse de corrélation obtenu est
surprenant: la mesure d’effort de Halstead est pire que LOC ! Le coefficient de corrélation
n’est que de 66%, tandis que les lignes de code obtiennent une corrélation à 76% [Basili, 81].
Certains auteurs affirment que lorsque les inconvénients sont connus et pris en
compte, les métriques logicielles de Halstead peuvent donner de bons résultats [Oman, 91].
3.4 La complexité du flot de contrôle
En l’absence de structures de contrôle14
(flot de contrôle), un programme traite ses
instructions du début à la fin. L'écriture de certains programmes très simples peut comprendre
uniquement ce flux unidirectionnel. Toutefois, la puissance et l'utilité d'un langage de
14
Une structure de contrôle est une commande qui contrôle l'ordre dans lequel les différentes instructions d'un algorithme
ou d'un programme informatique sont exécutées.
Les métriques statiques du code source
82
programmation proviennent principalement de la possibilité de modifier l'ordre d'exécution
grâce à des instructions de contrôle et à des boucles.
Les structures de contrôle permettent de réguler le flux de l'exécution du programme.
Elles permettent d'écrire du code qui prend des décisions ou qui répète des actions. D'autres
structures de contrôle permettent de garantir la mise à disposition d'une ressource ou
d'exécuter une série d'instructions sur la même référence d'objet.
3.4.1 Graphe du flot de contrôle
Le graphe de flot de contrôle est une représentation abstraite et simplifiée de la
structure logique d’un module15
où chaque nœud représente un segment de code strictement
séquentiel (sans choix ou boucle) et chaque arc dénote un lien de contrôle (possibilité d’aller
d’un nœud à l’autre). Il est utile pour calculer la complexité cyclomatique et déterminer le
nombre de cas de tests à définir pour assurer une couverture acceptable16
.
Le graphe de flot de contrôle est un graphe orienté :
• Noeud = instruction du programme ;
• Arc = flot de contrôle entre instructions ;
• Degré d’entrée d’un noeud = nombre d’arcs incidents ;
• Degré de sortie d’un noeud = nombre d’arcs sortants ;
• Noeud procédure = un noeud de degré de sortie 1 ;
• Noeud prédicat = un noeud de degré de sortie > 1 ;
• Chemin = une séquence d’arcs consécutifs ;
• Chemin simple = chemin sans répétition.
15 Un module correspond à une seule fonction ou sub-routine dans les langages typiques [Watson, 95].
16
Les cas de tests structurels de type boite blanche ou fonctionnels de type boite noir ainsi que les niveaux de couvertures
sont spécifiques au test du logiciel, sujet non abordé dans notre étude.
Figure 3.1 Exemple de graphe de flot de contrôle
Les métriques statiques du code source
83
3.4.2 Les métriques simples du flot de contrôle
Les métriques présentées ici, en combinaison avec les métriques de complexité
(comme la complexité cyclomatique CC ou la difficulté de Halstead HD), nous aident à
obtenir des informations utiles sur la structure et la complexité d’un programme.
La profondeur d’imbrication des blocs de code (Nested block depth NBD)
La profondeur d’imbrication des blocs de code est une métrique déterminée pour
chaque méthode. Elle est calculée simplement en déterminant les niveaux d’imbrication des
structures de contrôle au sein de la méthode. Cette métrique révèle rapidement les méthodes
dont le code est rendu difficilement lisible par une trop forte imbrication des structures de
contrôle.
Cette métrique est très utile pour mettre en évidence les méthodes dont le code est
rendu illisible à cause d’un nombre important d’imbrications au niveau des structures de
contrôles. Pourtant elle n’offre pas la même vision que la complexité cyclomatique
puisqu’elle ne s’intéresse qu’à l’imbrication la plus profonde de la méthode et ne donne pas
une vue d’ensemble de cette dernière [Rapport TER, 09].
Pourcentage des branchements (Branch percentage BP)
Cette métrique considère le pourcentage des instructions (# STAT) qui provoquent
une rupture dans l'exécution séquentielle du programme (la création d'un branchement dans le
graphe de flot du programme). Un pourcentage élevé de branchements indique un flot de
contrôle complexe du programme.
3.4.3 La complexité cyclomatique (CC)
La complexité cyclomatique, également référée comme complexité de programme ou
complexité de McCabe a été introduite par Thomas McCabe en 1976. Elle est le calcul le plus
Les métriques statiques du code source
84
largement répandu des métriques statiques. La métrique est conçue pour être indépendante du
langage et du format du langage. La métrique de McCabe indique le nombre de chemins
linéaires indépendants dans un module de programme et représente finalement la complexité
des flux de donnés. Il correspond au nombre de branches conditionnelles dans
l’organigramme d’un programme [Lambertz].
Pour un programme qui consiste en seulement des états séquentiels, la valeur pour
v(G) est 1. 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. Le nombre cyclomatique v(G)
est l'une des plus importantes mesures de complexité afin d’estimer l’effort nécessaire pour
les tests du logiciel.
Du fait que le nombre cyclomatique décrive la complexité du flot de contrôle, il est
évident que les modules et les fonctions ayant un nombre cyclomatique élevé auront besoin de
plus de cas de tests que les modules ayant un nombre cyclomatique plus bas. Comme principe
de base, chaque fonction devrait avoir un nombre de cas de tests au moins égal au nombre
cyclomatique.
Le nombre cyclomatique de McCabe v(G) est calculé à partir des définitions de
fonctions (ou membres) et des déclarations de classes/ structures. Voici les branches (appelées
aussi décisions) entrant en compte dans le calcul de v(G) :
chaque if-statement introduit une nouvelle branche au programme et, par conséquent,
incrémente v(G) ;
chaque itération (une boucle for ou while) introduit des branches et par conséquent
augmente le facteur v(G) ;
chaque switch-statement incrémente v(G). Une branche de cas n'augmente pas la
valeur de v(G), car il ne doit pas augmenter le nombre de branches dans le flot de
commande. S'il y a deux ou plus de cas... : qui n'ont pas de code entre eux, la mesure
de McCabe est augmentée uniquement une fois pour l'ensemble des cas.
chaque morceau (...) capté dans un bloc d'essai (try-block) incrémente v(G) ;
les constructions exprl ? expr2 : expr3 incrémente v(G).
Il faut noter que v(G) est insensible aux branches inconditionnelles comme goto-,
return-, et les break-statements bien qu'ils augmentent sûrement la complexité. En résumé, les
constructions de langage suivantes incrémentent le nombre cyclomatique: if(...), fo (...),
Les métriques statiques du code source
85
while(...), case ...:, catch(...), &&, ||, ?, #if, #ifdef, #ifndef, #elif. Le calcul commence toujours
avec la valeur 1. A ceci on ajoute le nombre de nouvelles branches (décisions). Autrement dit
Le calcule de v(G) repose sur une représentation du programme sous forme de graphe
de flot de contrôle du programme comme suit :
Pour un graphe de flot de contrôle G comportant n noeuds (dont d noeuds prédicats), e arcs
et r régions (une région est une suite d’instructions strictement consécutives), il existe trois
façons de mesurer la complexité :
Ainsi, pour le graphe de flot de contrôle de la figure 3.1 :
• v(G) = e – n + 2 = 12-11+2 = 3
• v(G) = 1 + d = 1+2 = 3
• v(G) = r = 3
• v(G) = e – n + 2
• v(G) = 1 + d
• v(G) = r
CC = v(G) = nombre de décisions + 1
Le calcul de v(G) du fichier entier commence également avec la valeur 1. Pour chaque
fonction on ajoute la valeur v(G) de chaque fonction –1.
v
Les métriques statiques du code source
86
Quelles sont les limites acceptables pour v(G) ?
McCabe a suggéré la valeur de 10 [v(G)=10] comme un bon indicateur de complexité
d’un module (ici un module correspond à une seule fonction ou sub-routine). Si le nombre
cyclomatique d’un module est plus de 10, ce dernier est trop complexe et devrait être repensé
(redesigned). En 1994, Grady a conclu que la valeur du v(G) pour un module en cours de
maintenance ne doit pas dépasser 15 [Fenton & Pfleeger, 97]. La limite raisonnable maximum
du nombre cyclomatique d'un fichier est de 100 [Lambertz].
Il existe deux autres variantes de complexité cyclomatique dépendant de ce qui doit
être compté comme décision :
La complexité cyclomatique étendue (ECC) : extended cyclomatic complexity
(Cyclomatic complexity with Booleans) ECC = CC + Opérateurs booléens.
ECC étend la métrique originale CC en incluant les opérateurs booléens dans le comptage
de décisions [Spinellis, 06] ; en augmentant le nombre de complexité à chaque fois qu'un
opérateur booléen (AND, OR, XOR, NOT) est rencontré dans une instruction
conditionnelle. Dans les outils de mesure logiciels, ECC est souvent utilisée à la place de
CC.
Exemple 1 if( y < 5)
//do something…
Example 2 if( y < 5 AND y > 1 )
//do something…
Dans l’exemple 1, la valeur de la complexité est de 1+ 1 = 2 pour les deux métriques CC
et ECC. Dans l'exemple 2, la métrique CC résultera toujours en 2 mais ECC sera de 3 en
raison de la présence de l'opérateur booléen AND dans la structure de contrôle if.
La complexité essentielle (EC) : Essential Complexity
En 1977, McCabe a proposé une autre métrique de complexité : la complexité essentielle.
Cette métrique mesure le niveau de la structure logique dans un programme [Fenton &
Pfleeger, 97]. Pour le calcul de EC, la complexité cyclomatique du graphe de flot réduit
du programme est évaluée. Pour la réduction du graphe de flot de contrôle, les primitives
Les métriques statiques du code source
87
de programmation structurées (les nœuds séquentiels, les nœuds de sélection et
d’itération) sont éliminées jusqu'à ce que le graphe ne peut plus être réduit davantage
[Watson & McCabe, 96]. Par conséquent, le graphe de flot réduit ne pourra, en aucun cas,
avoir une valeur plus élevée que la valeur CC du graphe de flot de contrôle d'origine ; EC
est toujours inférieure ou égale à CC. Ainsi la définition de EC se présente comme suit:
EC = CC – m = v(G) – m
Où m est le nombre de sous-graphes (dans le graphe de contrôle) ayant un seul point
d’entrée et un seul point de sortie [Fenton & Pfleeger, 97]. La complexité essentielle est
traitée minutieusement dans l’ouvrage “Structured testing: A testing methodology using
the cyclomatic complexity metric, H. Watson and T. J. McCabe, 1996.” [Watson &
McCabe, 96].
Commentaire sur la métrique de McCabe
La métrique de McCabe est si utile qu’on croit qu’elle est une vraie mesure de la
complexité. Pour les analystes et les programmeurs, la mesure de McCabe étant bien détaillée,
capture la structure logique du code. Plusieurs autres recherches ont été faites autour de l’idée
de McCabe. Par exemple, Gilb propose une mesure similaire qui compte le nombre de noeuds
de décision [Gilb, 77]. Myers a proposé une extension pour tenir compte des conditions très
complexes qui se composent de plusieurs prédicats [Myers, 77]. Hansen a présenté une
combinaison entre la mesure de McCabe et une mesure de Halstead (le nombre d’opérateurs)
pour une mesure hybride de la complexité du programme. L’idée de Hansen est de combiner
une mesure de la taille (mesure de Halstead) avec une mesure de la structure (la mesure de
McCabe) pour mieux caractériser la complexité – ce qui se manifeste dans l’effort [Hansen,
78].
Cette métrique, qui connaît un certain succès notamment pour prédire le nombre de
défauts d'un programme, a suscité deux critiques. D'une part, la complexité mesurée est celle
de la solution qui a été trouvée et qui, selon les compétences des concepteurs, peut être plus
ou moins différente de la complexité du problème posé initialement. D'autre part, cette
mesure ne tient pas compte de la complexité des données ; or, selon certains auteurs la
complexité d'un programme vient principalement de la complexité des données qu'il doit
traiter [Jones, 86]. On citera par exemple la construction switch du langage C (ou case des
langages Pascal et Ada) dont le nombre cyclomatique peut s'avérer catastrophique (liée à la
taille du switch) et dont la compréhension est pourtant fort simple.
Les métriques statiques du code source
88
La métrique de McCabe s’adresse à la structure de contrôle intra-module. D’autres
types de complexité inter-modules existent telles que la difficulté qui émerge de la relation
entre les modules d’un système (les métriques de Henry et Kafura 1981) et le degré
d’interdépendance entre ces modules (le couplage). Ces métriques et d’autres (la cohésion
d’un module) feront l’objet des sections 3.5 et 3.6.
3.5 Les métriques de Henry et Kafura
Cette métrique, introduite par Henry et Kafura en 1981 et à été largement testée sur
UNIX, prend en compte les liaisons inter-modules. La relation de base est qu’un module
appelle un autre module ou est appelé par un autre module. Elle propose de calculer pour
chaque module sa complexité à partir de sa taille length, son fan in et son fan out.
Henry et Kafura définissent le « fan in » d’un module par le nombre de modules qui
appellent un module et le « fan out » d’un module par le nombre de modules appelés par un
module. Puis,
Où length est la longueur du module en terme de milliers de lignes de code KLOC; fan in,
fan out sont la somme des fan in et fan out des divers modules du système respectivement
[Henry & Kafura, 81].
Contrairement à la métrique proposée par McCabe, ici le module est analysé en
fonction de son contexte. Une métrique élevée indique une certaine complexité d'intégration
du module et une compréhensibilité douteuse. Cette métrique s’adapte bien dans le contexte
orienté objets.
3.6 Couplage et cohésion
D'une manière générale, la modularité (la facilité de gestion) est considérée comme un
critère important de la qualité du logiciel. Sommerville présente la modularité comme étant un
facteur important pouvant influer sur les différentes caractéristiques de qualité comme
l'efficacité, la flexibilité, l'interopérabilité, la facilité de maintenance et la facilité de
réutilisation [Sommerville, 95]. Un produit logiciel est dit modulaire si ses composants
présentent un degré élevé de cohésion ainsi qu'un faible degré de couplage [Constantine &
Complexité du module = Length × (fan in × fan out)2
Les métriques statiques du code source
89
Yourdon, 79]. Un module possède un degré élevé de cohésion si tous ces éléments sont reliés
entre eux. Ces éléments collaborent pour réaliser un objectif commun qui est « la fonction du
module ». Le couplage quant à lui, concerne les relations qu'entretient un module avec les
autres modules du système. La mesure de ce couplage détermine l'interdépendance entre deux
modules. Intuitivement, un faible degré de couplage entre les modules est souhaitable. En
effet, un module qui est relativement peut relié aux autres est facile à comprendre, à modifier,
à tester et enfin à réutiliser. De plus, les chances de propagation des erreurs d'un module à un
autre se trouvent d'autant plus diminuées que le nombre de liens entre ces deux modules est
petit.
3.6.1 Couplage entre les modules
Le couplage est défini par Yourdon et Constantine (1979) comme « le degré
d'interdépendance entre les modules». Plus cette interdépendance est forte et plus le couplage
est fort. L'interdépendance entre les modules est définie non seulement en fonction du nombre
d'interconnexions, mais aussi en fonction de leur type.
Le couplage est un attribut de paire de modules. C'est un concept pour indiquer la
force d'interconnexion des composants (c.-à-d., modules) d'un système. Les systèmes
fortement couplés ont des interconnexions fortes, autrement dit, les unités de programme sont
fortement dépendantes. Les systèmes faiblement couplés sont constitués d'unités
indépendantes ou presque indépendantes. Une règle générale est que les composants sont
fortement couplés lorsqu'ils utilisent des variables partagées ou lorsqu'ils échangent des
informations de contrôle [DE TRAN, 05].
Types de couplage entre deux modules m1 et m2 (du moins mauvais au plus mauvais)
Le couplage est souvent évalué qualitativement sur une échelle de six niveaux définis par
Yourdon [Constantine & Yourdon, 79]:
1. Pas de couplage : m1 et m2 sont indépendants ;
2. Couplage de données: les modules m1 et m2 communiquent par des paramètres qui
sont des éléments de données simples (par exemple, une variable de type
élémentaire) ;
3. Couplage fort (stamp coupling): m1 et m2 communiquent par des paramètres de type
enregistrement (record) ;
Les métriques statiques du code source
90
4. Couplage de contrôle: un module transfère un paramètre à un autre module pour
contrôler le comportement de celui-ci. Par exemple, m1 passe un paramètre à m2 qui
influence le flot de contrôle de m2 ;
5. Couplage commun: m1 et m2 partagent des données globales. Si le format de données
globales change, tous les modules impliqués dans le couplage commun doivent être
changés ;
6. Couplage de contenu: un module accède aux données d’un autre module et opère des
modifications de données directement. Par exemple, m1 modifie des données ou des
instructions à l'intérieur de m2.
Graphe de couplage
Mesure de couplage
La mesure de couplage entre deux modules m1 et m2 est définie par :
Où i est la pire relation de couplage et n le nombre d’interconnexions entre m1 et m2. Par
exemple, le couplage entre les modules m2 et m4 de la figure 3.2 est calculé, selon la formule
précédente, comme suit :
Pour un système S comportant les modules M1, …, Mm, la mesure globale du
couplage C(S) est la médiane de {c(Mi, Mj) | 1 <= i <= j <= m}. Fenton propose la
moyenne de couplage entre toutes les paires de modules du système comme une mesure du
couplage du système. Il estime que cette mesure peut être utilisée comme une simple mesure
pour évaluer la qualité de la conception du logiciel [Fenton & Pfleeger, 97].
Figure 3.2 Exemple de graphe de couplage [Guéhéneuc, 06].
Les métriques statiques du code source
91
3.6.2 Cohésion du module
La cohésion d’un module est le degré de cohérence entre les composants du module.
De façon idéale, un module devrait implémenter une seule fonction logique ou une seule
entité logique sachant que tous les composants doivent contribuer à cette implémentation. Si
un module comporte des composants qui ne sont pas directement relatifs à sa fonction
logique, ce module n'a qu'un faible degré de cohésion. Par exemple, si nous devions écrire une
fonction C pour calculer soit le sinus, le cosinus ou la tangente d'un angle donné en paramètre,
un deuxième paramètre étant fourni pour indiquer la nature du calcul à effectuer. Le degré de
cohésion de ce module (qui est réduit ici à une seule fonction) est évidemment faible car
chaque segment du code dans le module étant dédié au calcul d’une seule fonction
trigonométrique. En effet, parfois, un segment du code de ce module est exécuté pour calculer
le sinus et renvoie cette valeur; parfois, un autre segment est exécuté pour calculer la tangente
et renvoie cette valeur; etc. Chacun des segments est exploité plus ou moins indépendamment
des autres.
Constantine et Yourdon (1979) proposent une échelle de classification de sept
niveaux de cohésion présentés ci-après par ordre dégressif:
1. La cohésion fonctionnelle : tous les éléments du module servent à calculer une seule
fonction. C'est ce type de cohésion qui doit être recherché ;
2. La cohésion séquentielle : la sortie d'un composant est utilisée en entrée d'un autre ;
3. La cohésion de communication : un module réalise plusieurs fonctions mais manipule
le même corps de données ;
4. La cohésion procédurale : un module réalise plusieurs fonctions qui composent une
fonction générale du système ;
5. La cohésion temporelle : un module réalise plusieurs fonctions qui doivent se produire
en même temps. Tous les composants sont activés en même temps comme par
exemple à l'initialisation du programme ou encore à la fin de l'exécution ;
6. La cohésion logique : un module réalise plusieurs fonctions qui ont des relations
logiques. Tous les composants du module effectuent des opérations semblables
comme la prise en compte ou le traitement d'erreurs.
7. La cohésion par coïncidence : un module réalise plusieurs fonctions qui sont
indépendantes. Il n'y a pas de relation entre les composants du module. Les
composants sont simplement rassemblés dans le module.
Ces classes de cohésion ne sont pas définies de manière stricte; Yourdon et
Constantine écrivent que l'on peut associer une valeur numérique aux niveaux de cohésion (0
Les métriques statiques du code source
92
pour la cohésion accidentelle, jusqu'à 10 pour la cohésion fonctionnelle) mais ils donnent
simplement des exemples pour expliquer les concepts. Il n'est donc pas toujours facile de
décider à quelle catégorie de cohésion appartient une unité.
Mesure de la cohésion
La mesure de cohésion est de type ordinale. On caractérise un module par sa cohésion
la moins désirable (la cohésion fonctionnelle). Une mesure simple de la « cohésion du
système » pourrait être définie comme le taux de modules ayant une cohésion fonctionnelle
dans le système:
Card et Glass ont introduit des résultats statistiques qui indiquent que le taux de
cohésion et la moyenne de couplage sont deux mesures très pratiques pour évaluer la qualité
de la conception et pour estimer le nombre d’erreurs du code [Card & Glass, 90]. Le couplage
et la cohésion font référence à la qualité de la conception plutôt que de fournir des indices de
l’effort. Cependant, il est évident qu’une bonne conception va faciliter la compréhension et
réduire les erreurs. Cela affecte la performance du programmeur, puis l’effort de
développement [DE TRAN, 05].
3.7 L’index de maintenabilité (Maintainability Index MI)
Une métrique intéressante est celle qui permet de décider si on peut continuer à
maintenir un module ou s'il vaut mieux le réécrire : C'est l'index de maintenabilité. Il aide à
réduire ou à renverser la tendance d'un système vers l'entropie de code ou l'intégrité dégradée,
et indique quand il devient moins cher et moins risqué de réécrire le code plutôt que de le
corriger [Lambertz].
Selon ISO/IEC 9126-1 (cf. Tableau 4), la maintenabilité est une caractéristique de la
qualité interne et externe mais n'apparaît pas dans la qualité de fonctionnement: ce qui est
naturel car la maintenabilité concerne surtout les réalisateurs du logiciel et indirectement (par
la qualité externe) le personnel qui réalise les essais.
Les métriques statiques du code source
93
L'index de maintenabilité est calculé à partir des résultats de mesures de lignes de
code, de pourcentage de commentaires, des métriques de McCabe et des métriques de
Halstead. Il y a trois variantes de l’index de maintenabilité :
La maintenabilité calculée sans les commentaires (MIwoc, Maintainability Index without
comments) :
MIwoc = 171 - 5.2 × ln(aveV) -0.23 × aveG - 16.2 × ln(aveLOC)
aveV = valeur moyenne du volume de Halstead (V) par module ;
aveG = valeur moyenne de la complexité cyclomatique v(G) par module ;
aveLOC = nombre moyen de lignes de code (LOCphy ‘sans commentaires’) par module.
la maintenabilité concernant les commentaires (MIcw, Maintainability Index comment
weight) :
MIcw = 50 × sin(sqrt(2.4 × perCM))
perCM = le pourcentage des lignes de commentaires par module.
l’Index de maintenabilité (MI, Maintainability Index) est la somme de deux précédents :
MI = MIwoc + MIcw
Différentes valeurs de seuil pour MI ont été proposées. Ici, on reprend celles dérivées
des recherches effectuées par Hewlett-Packard [14], souvent utilisées comme référence. Les
premières versions de la métrique MI comprenaient la métrique effort de Halstead mais plus
tard a été modifiée pour inclure uniquement la métrique volume. Les valeurs de seuil
suivantes pour MI d’un module (dérivées du code Fortran, C et Ada) ont été proposées:
• MI <65 => maintenabilité pauvre;
• 65 = <MI <85 => maintenabilité modérée;
• MI> = 85 => excellente maintenabilité.
Ainsi, une valeur de 85 ou plus indique une bonne maintenabilité, une valeur entre 65 et 85
une maintenabilité modérée. Des modules avec un MI inférieur à 65 sont difficiles à
maintenir: il est donc préférable de réécrire ces parties du code.
Les métriques statiques du code source
94
Le calcul de la métrique MI est considéré comme simple et directe. En plus, grâce à la
combinaison des métriques de McCabe et de Halstead, MI cible les aspects individuels de la
complexité du logiciel (la complexité structurelle et lexicale). Cependant, la métrique MI est
dérivée de trois ou quatre (en considérant les commentaires) métriques non liées, un
changement de la valeur de MI implique donc un examen de toutes les métriques utilisées
dans le calcul pour expliquer ce changement [Kuipers &Visser, 07].
3.8 Les métriques logicielles orientées objet
La popularité de l'approche orientée objet pour le développement de logiciels a créé
un intérêt intense et plus de problèmes difficiles au développement et à l’évaluation des
métriques. L’approche orientée objet est basée sur la modélisation du monde réel en termes
d'objets, en revanche, les approches traditionnelles se basent sur une vue axée sur la fonction
qui sépare les données et les procédures. Dans l'approche objet, les données et les instructions
sont encapsulés dans une seule entité unique. Par conséquent, même si les métriques
logicielles traditionnelles sont modifiées pour évaluer les systèmes orientés objet, elles sont
insuffisantes ou inadéquates pour couvrir tous les aspects de cette approche. Ainsi, de
nouvelles métriques qui reflètent les caractéristiques de ce paradigme17
sont définies.
3.8.1 Caractéristiques de la méthode de conception orientée objet
Le terme «orienté objet» signifie que le logiciel est organisé comme une collection
d’objets dissociés qui encapsulent la structure des données et le comportement [Rumbaugh et
al, 91]. En général, les caractéristiques requises par une approche orientée objet comprend
quatre aspects: l'identité, la classification, le polymorphisme et l'héritage.
L’identité signifie que les données sont quantifiées en entités discrètes, que l’on peut
distinguer et que nous nommons objet. On construit généralement cette identité pour un
objet grâce à un identifiant découlant naturellement du problème (par exemple un produit
17
La programmation orientée objet (POO), ou programmation par objet, est un paradigme de
programmation informatique élaboré par Alan Kay dans les années 1970. Il consiste en la définition et
l'interaction de briques logicielles appelées objets ; un objet représente un concept, une idée ou toute entité du
monde physique, comme une voiture, une personne ou encore une page d'un livre. Il possède une structure
interne et un comportement, et il sait communiquer avec ses pairs. Il s'agit donc de représenter ces objets et leurs
relations ; la communication entre les objets via leurs relations permet de réaliser les fonctionnalités attendues,
de résoudre le ou les problèmes.
Les métriques statiques du code source
95
pourra être repéré par un code, une voiture par un numéro de série, ...) ce qui permet de le
distinguer des autres objets, indépendamment de son état.
La classification signifie que les objets avec la même structure de données (attributs) et le
comportement (opérations) sont regroupés en une seule classe. Chaque classe décrit un
ensemble éventuellement infini d’objets individuels. Chaque objet est une instance de sa
classe.
Le polymorphisme signifie que la même opération peut se comporter différemment à
travers différentes classes. L’opération déplacer, par exemple, peut se comporter
différemment sur les classes Fenêtre et Pièce de jeu d’échecs. Une opération est une
action ou une transformation qu’un objet effectue ou subit : justifier à droite, afficher et
déplacer sont des exemples d’opération. L’implémentation spécifique d’une opération par
une certaine classe est appelée méthode. Parce qu’un opérateur orienté objet est
polymorphe, il peut être implémenté par plus d’une méthode.
L’héritage est le partage des attributs et des opérations entre des classes s’appuyant sur
une relation hiérarchique. Une classe peut-être définie à grands traits et ensuite raffinée
dans des sous-classes et y ajoute ses propres et uniques propriétés. Chaque sous-classe
incorpore, ou hérite, toutes les propriétés de sa super-classe et y ajoute ses propres et
uniques propriétés. Les propriétés de la super-classe n’ont pas besoin d’être répétées dans
chaque sous-classe. Par exemple, FenêtreDéroulante et FenêtreFixe sont des sous-classes
de Fenêtre. Les deux sous-classes héritent des propriétés de Fenêtre, telles que la zone
visible à l’écran. FenêtreDéroulante ajoute une barre de défilement et un déplacement. La
possibilité de factoriser des propriétés communes à plusieurs classes dans une super-classe
commune et d’hériter les propriétés de la super-classe peut réduire de façon significative
les répétitions dans la conception et dans les programmes. C’est l’un des principaux
avantages d’un système orienté objet.
3.8.2 Les recherches antérieures sur les métriques logicielles orientée objet
Les recherches sur les métriques logicielles orientées objet ont couvert plusieurs
aspects, tels que le modèle de l'évolution des métriques, la définition de nouvelles métriques,
la validation des métriques OO, etc.
Les métriques statiques du code source
96
Gowda et Winslow [Gowda & Winslow, 94] ont proposé une approche pour dériver
les métriques orientées objet. Cette approche est centrée sur la division de la procédure de
développement de logiciels en plusieurs phases, et la définition des différentes catégories de
métriques basées sur les points essentiels de chaque phase. Toutes les métriques doivent être
classées dans des sous-systèmes, collaboration au niveau sous-système, les niveaux classe, le
flux de messages aux niveaux classe/objet, etc. Par exemple, dans la phase de modélisation
objet de la méthode OMT (Object Modeling Technique), les métriques de classe, les
métriques du sous-système concernant les classes, les sous-classes, les attributs et les
méthodes seront convenables. Cependant, dans la phase de modélisation dynamique, le
système de métriques qui mesure les transitions, les flux de données, etc. sera d’une grande
utilité. Le modèle GQM peut également être utilisé dans l'évolution des métrologies orientées
objets.
Plus que jamais, d'importants travaux dans ce domaine sont désormais centrés sur la
définition de nouvelles métriques logicielles orientées objet et l'analyse de ces métriques.
Chidamber et Kemerer ont défini une suite de métriques pour la conception orientée objet
[Chidamber & Kemerer, 91]. Ces métriques ont ensuite été raffinées et analytiquement
évaluées selon les principes de mesure de Weyuker [Chidamber & Kemerer, 94]. Ces
métriques sont largement utilisées dans la métrologie OO. Basili, Briand et Melo ont évalué
cette suite de métriques par la collecte de données de huit projets de développement en
informatique de gestion de taille moyenne basés sur des besoins identiques. Basé sur l'analyse
empirique et quantitative, les avantages et les inconvénients de ces métriques OO sont
discutés. Leur conclusion est que, excepté pour la métrique LCOM (Lack Of Cohesion in
Methods), les autres métriques dans cette suite sont utiles pour prédire les erreurs au niveau
classe (class fault-proneness) durant les premières phases du cycle de vie du logiciel [Basili et
a1, 96].
Churcher et Shepperd [Churcher & Shepperd, 95] ont indiqué qu'il était prématuré
d'appliquer les métriques de Chidamber et Kemerer, tant qu’il reste des incertitudes quant à la
définition précise de bon nombre des quantités à observer et leur impact sur les métriques. Par
exemple, la métrique WMC (Weighted Methods per Class), ne compte que les méthodes avec
des noms distincts, les méthodes avec le même nom mais avec des paramètres et/ou type de
retour différents, tels que les constructeurs redéfinis, pourraient être ignorées. L'ensemble des
méthodes héritées pose le même problème. Par conséquent, il est très important de préciser les
Les métriques statiques du code source
97
mises en correspondances à partir d'un langage indépendant d’un ensemble de métriques vers
des langages de programmation spécifiques et des séries d'observations. L'utilité de n’importe
quel ensemble de métriques ne sera pas atteinte que si leur application à des langages
spécifiques est clairement spécifiée, comme indiqué par [Basili et a1, 96].
Graham a indiqué qu'il n'est pas clair si la métrique NOC (Number of Children) peut
être utilisée pour des schémas de classification dynamique. Il est évident que NOC change au
cours de l'exécution. Il a suggéré que les valeurs minimum, maximum, moyenne et mode de
NOC devraient être collectées dans de telles circonstances [Graham, 96]. Graham a également
constaté des incohérences dans la métrique LCOM. Cette métrique mesure le non-
chevauchement des ensembles de variables d'instance utilisées par les méthodes d'une classe.
IL a montré que LCOM semble augmenter avec la cohésion, là où il est prévu qu’elle
diminue. Par conséquent, il a donné une nouvelle définition de LCOM qui surmonte le
problème ci-dessus (une définition qui fournit une métrique dont la valeur diminue lorsque la
cohésion augmente).
Gowda et Winslow ont analysé les métriques de Chidamber et ont conclu que
ces métriques concernent principalement les structures de classe, leurs attributs et méthodes,
mais n'évaluent pas la conception du système dans sa globalité, ce qui est souvent recherché
par les managers [Gowda & Winslow, 94].
Abreu et al ont proposé les métriques MOOD (Metrics for Object Oriented Design).
Le but de développer cette série de métriques centrées sur la façon d'améliorer le processus de
conception orienté objet est d’atteindre la maintenabilité. Ces métriques permettent
l'utilisation des mécanismes du paradigme orienté objet à évaluer. Elles permettent de
quantifier: l’encapsulation, l’héritage, le polymorphisme et la transmission de messages.
Les métriques de Kim ont été proposées pour le calcul de la complexité d'un
programme orienté objet. Elles sont utilisées pour examiner la complexité d’un programme de
trois points de vue dimensionnels: la syntaxe, l'héritage, et l'interaction (Kim et al, 94 – Kim
et al ,96).
Les métriques statiques du code source
98
D'autres ensembles de métriques comprenant les métriques d’Ebert et Morschel pour
l’analyse de la qualité et l’amélioration des logiciels orientés objet ont été implémentées en
utilisant SmallTalk [Ebert & Morschel, 97]. Hitz et Montazeri ont proposé trois métriques.
Leur travail est axé sur la sélection appropriée des attributs pour la mesure de logiciels
orientés objet [Hitz & Montazeri, 95]. Martin a décrit un ensemble de métriques qui peuvent
être utilisées pour mesurer la qualité d'une conception orientée objet en termes
d'interdépendance entre les sous-systèmes de cette conception [Martin, 95]. Les métriques de
Milankovic-Atkinson et Georgiadou peuvent être utilisées pour évaluer les règles de
conception pour améliorer la qualité des logiciels orientés objet, principalement pour
permettre une meilleure réutilisation [Milankovic & Georgiadou, 97].
Il y a eu également un certain nombre de publications qui ont abordées la question de
la validation des métriques logicielles. Weyuker a discuté les métriques de complexité et a
proposé neuf propriétés qu'elle pensait que toute mesure de complexité syntaxique doit
satisfaire. La liste est largement connue sous « l’approche analytique formelle » [Weyuker,
98]. Chidamber, Kemerer, Kim se sont référés à ces propriétés dans l’évaluation de leurs
métriques orientées objet (Chidamber & Kemerer, 94 - Kim et al, 94).
Cependant, les propriétés de Weyuker ne sont pas sans critiques. Par exemple,
Cherniavsky et Smith ont suggéré que ces propriétés doivent être utilisées avec précaution du
moment où elles donnent seulement les conditions nécessaires mais pas suffisantes pour les
métriques de complexité [Cherniavsky & Smith, 91]. Fenton a suggéré que Weyuker a tenté
de caractériser des vues incompatibles de complexité [Fenton & Pfleeger, 97]. Cette
discussion montre que de nouvelles mesures seront justifiées selon des critères contestés. Sur
la base de cette pensée, Kitchenham, Pfieeger et Fenton ont proposé une plateforme de
validation qu’ils croient pouvoir surmonter les problèmes ci-dessus [Kitchenham, Pfleeger &
Fenton, 95]. Leur plateforme comprenait un modèle structurel qui décrit les objets impliqués
dans la mesure et leurs relations, différents modèles et protocoles sont utilisés pour définir les
éléments de mesure, et les issues théorique et empirique de validation en questions pour
s’assurer si les mesures sont appropriées ou non. Les propriétés de Weyuker et la plateforme
de Kitchenham sont adaptés, non seulement pour le paradigme orienté objet, mais aussi pour
le paradigme fonctionnel.
Les métriques statiques du code source
99
Kim a proposé une plateforme d'analyse des métriques orientées objets [Kim et al ,94].
La plateforme évalue la portée ou la capacité des métriques de complexité des programmes
orientées objet (Kim et al , 94 – Kim et al ,96). Bansiya et Davis ont mis au point un outil
automatisé qui supporte les métriques orientées objet, appelé QMOOD ++ [Bansiya &
Davis, 97]. Malheureusement, cet outil est fortement lié à un certain ensemble de métriques,
développées par Etzkorn, Bansiya et Davis [Etzkorn, Bansiya & Davis, 98].
3.8.3 Les métriques objets de Chidamber et Kemerer (CK)
L’ensemble des métriques pour la conception orientée objet (Metric Suite for Object
Oriented Design) de Chidamber et Kemerer a été conçu pour permettre d’effectuer une
évaluation des classes d’un système. La plupart des métriques sont calculées classe par
classe : aucune n’évalue le système comme un tout et le passage au système global n’est pas
clair car il n’est généralement pas approprié de calculer une moyenne pour l’ensemble des
classes.
M1 : Méthodes pondérées par classe
WMC : Weighted Methods per Class
avec C un ensemble de n classes comportant chacune Mi méthodes dont la complexité (le
Poids) est notée ci. En fonction de la validation empirique de la métrique qui est effectuée par
Chidamber et Kemerer, 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. Plus
il y a de méthodes définies dans la classe, plus il y aura d'impact sur leurs classes
descendantes qui héritent de toutes les méthodes de la classe parente. En plus, une classe
avec un grand nombre de méthodes indique qu'elle est plus spécialisée, ce qui réduit la
possibilité de réutilisation de la classe dans la construction.
M2 : Profondeur de l'arbre d'héritage
DIC : Depth of Inheritance Tree
Ceci permet de mesurer la longueur du chemin représentée par les niveaux entre une classe et
la classe racine dans la hiérarchie d'héritage de la conception du système; dans le cas
d'héritage multiple (cas du langage C++) d'une classe, on prend en compte la longueur
Les métriques statiques du code source
100
maximum. Une classe ayant une valeur plus élevée impliquera une complexité plus grande et
une certaine difficulté à prédire le comportement de la classe; un arbre d'héritage plus profond
suggère non seulement une conception de système plus compliquée, mais aussi plus de
réutilisations des méthodes héritées.
M3 : Nombre d'enfants
NOC : Number Of Children
Cette métrique est le nombre des sous classes immédiates d'une classe donnée, par une
relation d’héritage. On veut aussi mesurer l'influence d'une classe sur la conception du
système; en d'autres termes, on quantifie la portée des sous classes impliquées qui héritent des
méthodes de la classe parente. Un nombre de classes descendantes plus élevé montrera
certains problèmes qualitatifs et de performance dans la conception du système. Ces derniers
comprennent la réutilisation de la classe parente par le plus grand nombre de sous classes qui
sont liées directement, une abstraction inacceptable de la classe parente et une exigence
d'effort augmentée pour tester cette classe.
M4 : Le couplage entre des classes d'objets
CBO : Coupling Between Object
La métrique est développée pour mesurer la dépendance entre classes dans la conception du
système; le concept de couplage entre deux classes est défini comme l'interaction d'une classe
avec une autre par invocation des méthodes ou accès aux variables d'instance définies dans la
deuxième classe. 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. En revanche,
un faible couplage de classe est favorable en amenant plus de modularité et en améliorant
l'encapsulation de la classe.
M5 : Références à une classe
RFC : Reference For Class
La métrique est définie comme le nombre de toutes les méthodes accessibles qui peuvent être
invoquées et exécutées lors de la réception d'un message; il s'agit d'un ensemble de méthodes
comprenant des méthodes appelées en interne (au sein de la même classe), ainsi que des
méthodes invoquées dans d'autres classes. Cette mesure est exprimée sous la forme suivante:
Les métriques statiques du code source
101
Où RS représente l'ensemble des méthodes impliquées en réponse à un message reçu par la
classe; il est défini par la formule suivante:
tels que M représente l'ensemble de toutes les méthodes invoquées dans la classe C , Ri est
l'ensemble des méthodes dans les autres classes qui sont appelées par une méthode i de la
classe C.
La métrique permet de mesurer non seulement la complexité interne de la classe par le
nombre de méthodes invoquées, mais elle quantifie encore les interactions essentielles en
considérant des méthodes des autres classes directement appelées par une méthode de la
classe. En effet, la mesure tente d'introduire la complexité de la classe en mêlant la
complexité dans la classe et celle de ses interrelations avec d'autres classes. Un nombre de
méthodes invoquées plus élevé en réponse au message signifie une complexité de classe plus
élevée. Ceci exige également plus d'effort et plus de temps au testeur de logiciel pour
comprendre, inspecter et déboguer le programme.
M6 : Manque de cohésion des méthodes
LOCM : Lack Of Cohesion in Methods
La cohésion dans une classe représente la similarité des méthodes de classe qui possèdent un
accès aux mêmes variables d'instance dans la classe. Le degré de similarité est défini comme
le nombre de variables d'instance qui sont partagées par une paire de méthodes dans la classe.
LCOM tente de mesurer l'absence de ce facteur :
Posons
- Ii l'ensemble des variables d'instance utilisé es par la mé thode i ; - P l'ensemble des paires de (Ii; Ij) ayant une intersection vide (degré de similarité des
méthodes i,j = 0); - Q l'ensemble des paires de (Ii; Ij) ayant une intersection non vide.
LCOM peut ê tre visualisé comme un graphe bi-partite où le premier ensemble de
noeuds correspond aux n diffé rents attributs et le second aux m diffé rentes
mé thodes. Un attribut est lié à une fonction si elle y accè de ou modifie sa valeur.
L'ensemble des arcs est Q. Il y a n × m arcs possibles et |P| = n × m – Q.
Les métriques statiques du code source
102
Chidamber et Kemerer énoncent qu'une cohésion élevée est favorable dans la conception
orientée objet, parce qu'elle tend à promouvoir l'encapsulation dans la classe, en apportant une
simplicité et une réutilisabilité élevées de la classe. En revanche, une faible cohésion dans la
classe accroît sa complexité de conception augmentant ainsi le risque d'avoir plus d'erreurs
durant l'implantation de la classe. Chidamber et Kemerer suggèrent que la division de cette
classe en plusieurs sous classes avec une cohésion plus élevée est une solution possible pour
résoudre la faible cohésion de classe.
Les valeurs de seuil pour les métriques de Chidamber et Kemerer
Chidamber et Kemerer [Shyam, Chidamber & Kemerer, 94] ont effectué une étude de
validation de ces métriques à partir de systèmes commerciaux écrits en C++ et SmalItalk. Ils
ont remarqué que les métriques sont utiles durant le développement du système. En effet, en
utilisant les métriques telles que WMC, DIT et NOC, on pourra identifier la quantité de
classes définies au niveau de la racine dans la conception du système, un nombre de classes
excessif signifie peu d'héritage dans le système et produit de nombreuses méthodes dans le
premier niveau de la conception du système réduisant ainsi la réutilisation des méthodes. D'un
autre coté, les métriques RFC et CBO vérifient s'il y a des interconnexions inadéquates entre
des classes dans la conception. Linda, Laird et Brennan ont proposé une directive quantitative
en spécifiant les seuils qualitatifs dans la conception orientée objet [Linda, Laird & Brennan,
06]; cependant, si les métriques orientées objets atteignent leurs propres valeurs de seuil, la
modification devra être faite dans la conception de classe. On présente ci-dessous les critères
numériques définis pour chaque métrique.
Réponse pour une classe RFC = 100 ;
Réponse pour une classe = 5 fois le nombre de méthodes dans la classe ;
Couplage entre objets CBO = 5 ;
Nombre pondéré de méthodes par classe WMC = 100 ;
Nombre de méthodes = 40.
3.8.4 Les autres métriques objets
Les métriques statiques du code source
103
Beaucoup de métriques orientées objet ont été proposées mais ne sont pas aussi
répandues et analysées comme les métriques CK et MOOD [Abounader & Lamb, 97]:
MOOD (Metrics for Object Oriented Design)
Ensemble de métriques pour mesurer les attributs des propriétés suivantes : encapsulation,
héritage, couplage et polymorphisme.
MHF: Method Hiding Factor (10-30%)
MIF: Method Inheritance Factor (65-80%)
CF: Coupling Factor (5-30%)
PF: Polymorphism Factor (3-10%)
Li et Henry
Li et Henry ont réutilisé cinq des six métriques de Chidamber Kemerer et ont introduit cinq
nouvelles mesures. Ces cinq nouvelles métriques sont énumérées ci-dessous:
MPC: Message Passing Coupling
DAC: Data Abstraction Coupling
NOM: The Number of Methods
SIZE1: The number of semicolons
SIZE2: The number of properties
Chen et Lu
Chen et Lu ont développé un ensemble de métriques orientées objet, qui se concentrent
principalement sur la complexité de la classe. Ces métriques sont les suivantes:
OpCom : Operation Complexity
OAC: Operation Argument Complexity
AC : Attribute Complexity
Re : Reuse
OpCpl : Operation coupling
ClCpl: Class Coupling
Coh : Cohesion
CH : Class Hierarchy
Moreau et Dominick
MVS: Message Vocabulary Size
IC: Inheritance Complexity
IS : Interface Size
Abbott, Korson et McGreggor
IL: Interaction Level IS: Interface Size
Hitz et Montazeri
OLC: Object Level Coupling CLC: Class Level Coupling
Conclusion
Les métriques statiques du code source
104
Ce chapitre présente une revue de la littérature sur les méthodes de mesure basées sur
le code source. A cet effet, des métriques dites statiques, extraites du code source, d’un
programme sont utilisées. Par opposition aux métriques dynamiques, qui requièrent
l’exécution du programme pour être comptabilisées et ne sont valables que pour une seule
exécution, les métriques statiques restent valables pour toutes les exécutions et ne tiennent pas
compte des valeurs décidées dynamiquement. Selon Jackson et Rinard, le futur des métriques
se trouve plutôt du côté statique [Jackson & Rinard, 00].
Les mesures introduites dans ce chapitre concernent les deux aspects: la taille et la
structure du programme. Une mesure de la taille est souvent associée à la longueur du code,
donc elle reflète intuitivement l’effort (observé pour écrire le code). Par contre, une mesure de
la structure tient compte de la structure du module ou de la structure du code. Ces structures
affectent la facilité de compréhension du code. De ce fait, la complexité de la structure est
associée à la qualité du code, à la qualité de la conception, à l’effort de test du programme
ainsi qu’à l’effort de développement en général. Bien que les mesures structurelles varient en
ce qu'elles mesurent et comment elles mesurent, elles sont souvent appelées « métriques de
complexité». "Controlling complexity is the essence of computer programming." (Brian
Kernighan).
La mesure de la complexité est utilisée comme un paramètre pour estimer l’effort
de développement ou de maintenance du logiciel, et contrôler ensuite la qualité requise dans
le processus de production. Les métriques de complexité de Halstead qui procurent une
mesure quantitative de complexité pour des logiciels, et la complexité cyclomatique de
McCabe qui s’adresse à la structure de contrôle intra-module, indique le nombre de chemins
linéaires indépendants dans un module et représente finalement la complexité des flux de
données, ont été discutées.
D’autres types de complexité inter-modules existent telles que la difficulté qui émerge
de la relation entre les modules d’un système (les métriques de Henry et Kafura) et le
degré d’interdépendance entre ces modules (le couplage). Si le couplage est une
caractéristique propre au système, la cohésion est une caractéristique propre à chaque module
du système. Le couplage est une mesure de l'indépendance d'un module donné par rapport à
son environnement qui se restreint aux autres modules faisant partie du même système et la
cohésion est la mesure de l'indépendance des éléments d'un module donné. La mesure de la
Les métriques statiques du code source
105
cohésion représente la force structurelle et fonctionnelle liant les éléments internes d'un
module.
L’apparition des langages orientés objet a causé un certain bouleversement dans la
communauté des métriques. Il faut bien le dire, la programmation objet n’est pas simplement
un ensemble de fonctionnalités ajoutées aux langages de programmation fonctionnels, c’est
une approche complètement différente pour concevoir des logiciels [Budd, 91]. On ne peut
donc pas s’attendre à ce que des métriques conçues pour les langages fonctionnels
traditionnels puissent être appliquées directement aux langages orientés objet. La première
tentative sérieuse de définir des métriques orientées objets ayant une certaine base théorique
fut les métriques de Chidamber et Kemerer. En s’appuyant solidement non seulement sur la
théorie de la mesure, mais aussi sur certaines notions philosophiques et sur les propriétés de
Weyuker [Weyuker, 98], ils proposent six métriques fortement liées aux concepts orientés
objet. D’autres métriques orientées objet ont été proposées mais ne sont pas autant répandues
et analysées comme les métriques CK et les métriques MOOD.
Processus d’évaluation de la qualité du logiciel
107
Chapitre 4.
Processus d’évaluation de la qualité du logiciel
La qualité du produit logiciel est exprimée comme un ensemble de caractéristiques de
qualité, comme la fiabilité ou la facilité d’utilisation (ISO 9126, 1991), ou des propriétés,
comme la prédisposition aux défauts, la cohésion ou la structuration. L’évaluation du produit
logiciel vise à déterminer dans quelle mesure un produit logiciel particulier remplit ses
caractéristiques spécifiées ou ses propriétés, ou systématiquement examine la mesure dans
laquelle le logiciel est capable de remplir des critères spécifiés (ISO 8402, 1994). Plusieurs
approches pour l’évaluation des produits logiciels existent: l’évaluation de l'architecture
[Kazman et al, 98], l’évaluation de la conformité [Pivka & Potocan, 96], et l'analyse statique
de code source [Mayrand & Coallier, 96]. Ce chapitre examine le processus d'évaluation le
plus usité (suivant l’approche analyse statique de code source): Evaluation selon les normes
ISO 9126 / ISO 14598.
4.1 Processus d’évaluation selon les normes ISO 9126/ ISO 1459818
4.1.1 Analyse des modèles ISO 9126 : les modèles (quantitatives)
En 1991, l'ISO a publié son premier consensus international sur la terminologie
utilisée pour les caractéristiques de la qualité pour l'évaluation des produits logiciels: ISO/IEC
9126 - Software Product Evaluation — Quality Characteristics and Guidelines for their Use
« Evaluation des produits logiciels - Caractéristiques de qualité et directives d’utilisation »
De 2001 à 2004, l'ISO a publié quatre parties complémentaires, contenant à la fois les
modèles de qualité ISO (ISO/IEC 9126 - 1) et les inventaires des mesures proposées pour ces
modèles (ISO/IEC 9126 – 2, 3, 4).
18 Dans cette partie, nous avons résumé le processus d’évaluation du produit logiciels (ISO 9126/ISO 14598) en utilisant :
-Les normes ISO/IEC 9126 & ISO/IEC 14598 (documents) et;
- Le livre d’Alain Abran – Software Metrics and Software Metrology, Copyright 2010 by IEEE Computer Society.
Processus d’évaluation de la qualité du logiciel
108
Ces modèles de qualité ISO 9126 sont de loin la couverture la plus complète en génie
logiciel sur la qualité du logiciel:
• Les experts nationaux et internationaux des normes ont investi beaucoup d'énergie au cours
des deux dernières décennies pour les améliorer, et travaillent toujours à les améliorer
davantage.
• Ces modèles de qualité ISO sont beaucoup plus détaillés que les modèles de qualité
proposés depuis les années 1980 par des auteurs individuels.
La version actuelle de l'ISO 9126 se compose de:
• Une norme internationale (ISO 9126 Partie-1/ISO 9126_1) qui documente la structure des
modèles de qualité ISO pour les produits logiciels, et
• Trois rapports techniques (TR ISO 9126 parties 2 à 4):
• ISO 9126_2 propose une liste de mesures externes dérivées de la qualité des logiciels;
• ISO 9126_3 propose une liste de mesures internes dérivées de la qualité du logiciel;
• ISO 9126_4 propose une liste de mesures qui en découlent pour la qualité dans le
modèle d'utilisation.
Cette version est complétée par un ensemble de guides méthodologiques ISO 14598.
La relation entre les normes ISO 9126 et ISO 14598 est illustrée dans la figure 4.1.
Figure 4.1 - Relation entre ISO 9126 et ISO 14598 — ISO 9126-1:2001
Processus d’évaluation de la qualité du logiciel
109
4.1.2 Le modèle de référence standard
Le premier document de la série ISO 9126 - Modèle de qualité du produit logiciel -
contient ce qui peut être considéré comme le modèle standard de référence ISO pour la qualité
des produits logiciels. Ce modèle de référence comprend trois vues de la qualité d'un produit
logiciel (figure 4.2):
• la qualité interne du logiciel;
• la qualité externe du logiciel;
• la qualité en cours d'utilisation du logiciel.
Figure 4.2 – La qualité dans le cycle de vie du logiciel — ISO 9126-1:2001
L’évaluation du produit logiciel afin de satisfaire les besoins de qualité du logiciel est
l'un des processus dans le cycle de développement du logiciel. La qualité du produit logiciel
peut être évaluée en mesurant les attributs internes (mesures généralement statiques de
produits intermédiaires), ou en mesurant les attributs externes (généralement en mesurant le
comportement du code en cours d’exécution), ou par la mesure des attributs de la qualité en
cours d'utilisation. L'objectif pour le produit est d’avoir l'effet requis dans un contexte
particulier d'utilisation (figure 4.2).
La qualité du produit logiciel doit être évaluée en utilisant un modèle de qualité défini.
Le modèle de qualité doit être utilisé après avoir défini les objectifs de qualité du produit
logiciel et les produits intermédiaires. La qualité du produit logiciel doit être hiérarchiquement
décomposée en un modèle de qualité composé de caractéristiques et sous-caractéristiques qui
peuvent être utilisées comme une liste de contrôle de la qualité.
Processus d’évaluation de la qualité du logiciel
110
Il est pratiquement impossible de mesurer toutes les sous-caractéristiques internes et externes
pour toutes les parties d'un produit logiciel. De même, on ne peut pas mesurer la qualité
d'utilisation pour tous les scénarios d’utilisation possibles. Les ressources pour l'évaluation
doivent être réparties entre les différents types de mesure en fonction des objectifs, de la
nature du produit et des processus de conception.
L’ISO 9126-1 présente deux structures de modèles de qualité pour la qualité du produit
logiciel :
Figure 4.3 - Modèle de qualité pour la qualité externe et interne: caractéristiques et sous-caractéristiques — ISO 9126-1:2001
Figure 4.4 – Modèle de qualité pour la qualité en cours d’utilisation — ISO 9126 – 1
•Une 1ère
structure pour les deux modèles de qualité interne et externe (figure 4.3), et
•Une 2ème
structure pour le modèle de la qualité d'utilisation (figure 4.4);
Processus d’évaluation de la qualité du logiciel
111
• La 1ère
structure comprend six caractéristiques, subdivisés en 27 sous- caractéristiques pour
la qualité interne et externe ;
• La 2ème
structure comprend quatre caractéristiques de «qualité d'utilisation » : l’efficacité,
la productivité, la sécurité et la satisfaction.
Cependant, il faut noter que la norme ISO 9126 ne fournit aucune valeur de référence
pour les caractéristiques et les sous-caractéristiques de qualité.
4.1.3 Métriques, attributs et choix des critères de mesure
4.1.3.1 Attributs internes et externes
Certains attributs internes influencent certains attributs externes, de sorte qu'il y est à
la fois un aspect externe et un aspect interne de la plupart des caractéristiques. Par exemple, la
fiabilité «reliability» peut être mesurée de l'extérieur en observant le nombre de défaillancess
dans une période donnée de temps d'exécution pendant l’essai du logiciel, et en interne par
l'inspection des spécifications et du code source afin d'évaluer le niveau de tolérance aux
pannes. Les attributs internes sont considérés comme des indicateurs des attributs externes.
Un attribut interne peut influencer une ou plusieurs caractéristiques, et une caractéristique
peut être influencée par plusieurs attributs (figure 4.5). Dans ce modèle, la totalité des
attributs de qualité du produit logiciel sont classés dans une arborescence hiérarchique de
caractéristiques et sous-caractéristiques. Le plus haut niveau de cette structure se compose des
caractéristiques de qualité et le niveau le plus bas se compose des attributs de qualité
logicielle. La hiérarchie n'est pas parfaite : certains attributs peuvent contribuer dans plusieurs
sous-caractéristiques.
Figure 4.5 - Caractéristiques, sous caractéristiques et attributs de qualité — ISO 9126 – 1:2001
Processus d’évaluation de la qualité du logiciel
112
Les sous-caractéristiques peuvent être mesurées par des métriques internes ou externes.
4.1.3.2 Métriques internes et externes et la relation entre elles
Les métriques internes peuvent être appliquées à un produit logiciel non-exécutable
(cas de spécifications ou de code source) durant la conception ou le codage. L'objectif
principal de ces métriques internes est de s'assurer que la qualité externe requise et la qualité
d'utilisation sont atteintes: des exemples sont donnés dans ISO 9126-3. Les métriques
externes utilisent des mesures d'un produit logiciel dérivées des mesures du comportement du
système, par des essais, ou en exploitant et en observant le logiciel exécutable ou le système:
des exemples sont donnés dans ISO 9126-2. Lorsque les exigences de qualité du produit
logiciel sont définies, les caractéristiques et les sous-caractéristiques de qualité qui
contribuent aux exigences sont à définir. Ensuite, les métriques externes appropriées et les
plages de références acceptables sont spécifiées pour quantifier les critères de qualité, ce qui
nous permet de savoir (valider) si le logiciel répond aux besoins des utilisateurs. Enfin, les
attributs internes de qualité du logiciel sont définis et précisés. Ils permettent d’atteindre la
qualité externe requise et la qualité d'utilisation et à les intégrer dans le produit pendant le
développement. Il est recommandé d’utiliser les métriques internes qui ont une relation forte
avec les métriques externes cibles, de sorte qu'elles puissent être utilisées pour prédire les
valeurs des métriques externes. Cependant, il est généralement difficile de concevoir un
modèle théorique rigoureux qui met en correspondance les métriques internes et externes qui
sont fortement liées.
4.1.3.3 Choix des métriques et des critères de mesure
La base sur laquelle les métriques sont sélectionnées dépendra de l’objectif
d’évaluation du produit et les besoins de l'évaluateur. Les besoins sont spécifiés par les
critères de mesures. Le modèle dans cette partie de l'ISO 9126 prend en charge une variété
d'exigences d'évaluation, par exemple:
• Un utilisateur pourrait évaluer la capacité d'un produit logiciel en utilisant des
métriques de qualité d’utilisation;
Processus d’évaluation de la qualité du logiciel
113
• Un acquéreur pourrait évaluer un produit logiciel par rapport à des valeurs de critère
de mesures externes de la fonctionnalité, de la fiabilité, de la facilité d’utilisation et de
l'efficacité, ou de la qualité d’utilisation;
• Une personne responsable de maintenir le produit logiciel peut l’évaluer à l'aide de
métriques de maintenabilité;
• Une personne responsable d’implémenter le logiciel dans des environnements
différents peut évaluer un produit logiciel en utilisant des métriques de portabilité;
• Un développeur peut évaluer un produit logiciel par rapport à des valeurs de critère
en utilisant des mesures internes de l'une des caractéristiques de la qualité.
4.1.4 Interprétation du modèle ISO 9126 pour l'évaluation et la prise de décision :
(ISO/IEC 14598 Information technology - Software product evaluation)
Pour l'application des modèles de qualité ISO à des logiciels spécifiques au sein d'une
organisation, un contexte organisationnel de référence serait typiquement mis en place et
utilisé. Comment appliquer ces modèles est décrit dans la norme ISO 1459819
, de différents
points de vue:
• Développement (amélioration) : ISO/IEC 14598-3;
• Acquisition : ISO/IEC 14598-4;
• Evaluation indépendante (y compris l'évaluation de tiers) : ISO/IEC 14598-5.
L'application de ce modèle d'analyse (qui correspond à l'évaluation et la prise de
décision sur la base de critères de décision dans la norme ISO 9126) est généralement
effectuée en quatre étapes (quatre processus de quantification): d'abord établir les exigences
d'évaluation, puis spécifier, concevoir et exécuter l'évaluation (figure 4.6).
19
ISO / IEC 14598 comprend les parties suivantes sous le titre général Technologies de l'information - Évaluation de
produits logiciels:
- Partie 1: Présentation générale
- Partie 2: Planification et gestion
- Partie 3: Procédés pour les développeurs
- Partie 4: Procédé pour les acquéreurs
- Partie 5: Procédés pour les évaluateurs
- Partie 6: Documentation des modules d'évaluation
Processus d’évaluation de la qualité du logiciel
114
Figure 4.6 – Processus d’évaluation — ISO/IEC 14598-1
1. Identification de la qualité - exigences relatives (Établir les exigences d'évaluation) : c'est
la sélection des parties des modèles de qualité ISO qui sont pertinentes à un contexte
particulier d’évaluation de la qualité. Trois activités sont menées au cours de ce sous-
processus, à savoir: établir les objectifs d’évaluation, identifier les types de produits, et
préciser le modèle de qualité.
2. Identification du contexte d'interprétation (Spécifier l'évaluation), qui implique la
spécification:
• Des métriques pour l'évaluation doivent être sélectionnées en fonction des exigences
d'évaluation définies à l'étape précédente;
• La sélection des valeurs de référence (ces valeurs peuvent être génériques ou des
valeurs de seuils spécifiques), ou
• La détermination des échelles spécifiques à un contexte particulier: ces échelles
doivent être divisées en niveaux de satisfaction des exigences.
3. (Conception de l’évaluation) la troisième phase concerne la documentation des procédures
qui seront utilisées par l'évaluateur dans ces mesures (plan d'évaluation: ISO/IEC 14598-2,
donné en Annexe I): utilisation des mesures dérivées de la phase de préparation de données en
considérant le modèle de qualité déterminé à l'étape 1.
Processus d’évaluation de la qualité du logiciel
115
4. La comparaison des résultats de l'étape 3 avec l'ensemble des valeurs de référence ou les
cibles déterminées à l'étape 2 pour prendre une décision fondée sur les informations fournies
et toutes les informations pertinentes en la possession du décideur (Exécuter l'évaluation).
Ceci est illustré dans la figure 7, avec:
• Des valeurs de référence pour les critères de décision (ou critères d'évaluation) pour ce
contexte organisationnel ;
• Les valeurs cibles (ou une échelle d'évaluation) pour les logiciels spécifiques à mesurer.
Enfin, un rapport d'évaluation est produit. Pour cette phase, la norme fournit également des
lignes directrices (ISO/IEC 14598-6).
Figure 4.7 - Niveaux d’évaluation pour les métriques — ISO/IEC 14598-1 :1999 (Valeurs de référence avec une échelle de mesure et une échelle d'interprétation)
Alors que les modèles de qualité ISO 9126 sont décrits à un niveau très détaillé, les
relations entre les modèles, les caractéristiques et sous-caractéristiques de qualité ne sont pas
bien comprises et mal décrites.
Par conséquent, utiliser en pratique l'une des relations décrites textuellement dans la norme
ISO 9126 constitue une "tentative de quantification" sans aucun cadre normatif prescrit ou
référence contextuelle organisationnelle ni fondation empirique vérifiée. Quelques solutions
aux problèmes relatifs à ce sujet seront exposées ultérieurement.
De plus, ni les normes ISO 9126 et ISO 14598 (y compris la future norme ISO 25000)
proposent "des modèles de référence d'analyse" spécifiques, ni un inventaire des "contextes
de référence organisationnels" avec des valeurs de référence et des critères de décision existe.
Chaque organisation doit définir ses propres modèles et critères de décision, limitant ainsi les
possibilités de comparaisons industrielles.
Processus d’évaluation de la qualité du logiciel
116
4.1.5 Métrologie dans l’ISO 9126 : Les mesures de base et les mesures dérivées
L’implémentation des modèles d'analyse, y compris ceux de la norme ISO 9126, doit
être basée sur la collecte de données de mesures de base (et des mesures dérivées, le cas
échéant). Les mesures disponibles pour la collecte de données pour les modèles de qualité
ISO 9126 sont proposées et décrites dans les trois rapports techniques dans la série ISO 9126.
Ces rapports proposent:
• Un inventaire de plus de 250 mesures dérivées pour chaque caractéristique ou sous-
caractéristique de qualité;
• 80 mesures de base (et 80 attributs correspondants) qui sont utilisées pour former les
mesures dérivées ci-dessus,
• Des explications sur la façon de les appliquer et de les utiliser, et
• Quelques exemples qui montrent comment les appliquer au cours du cycle de vie du
produit logiciel.
Une question clé se pose: quelle est la qualité, dans une perspective de mesure, dans cette
longue liste de plus de 250 mesures proposées? Autrement dit, les praticiens devraient-ils
faire confiance et utiliser ces mesures proposées?
Mesures dérivées ISO 9126 -2001 + Chacune des +250 mesures dérivées proposées dans l’ISO 9126 est généralement définie comme une formule composée de
mesures de base. Considérant l’exemple de l'ISO 9126 Partie 4: La qualité en cours d’utilisation:
• 1ère mesure de base (B1): Nombre de défaillances détectées (Number of detected failures).
• 2ème mesure de base (B2): Nombre de cas de tests effectués (Number of test cases performed).
• Mesure dérivée: B1 / B2 avec les unités de mesure suivantes:
Dans cet exemple, tiré de la norme ISO 9126, la mesure dérivée (avec les unités de mesure correspondantes ci-dessus) se voit
attribuer le nom suivant: “la densité de défaillances par cas de test. ” (“ Failure density against test cases.”)
Cependant, si les règles d'attribution numériques (des formules pour les mesures dérivées) pour chaque mesure dérivée sont
décrites comme des opérations mathématiques (ici, une division), ni B1 ni B2 est décrit avec une clarté suffisante pour
assurer la qualité (précision, répétabilité20 et reproductibilité21) des résultats de mesure des:
• mesures de base, et, bien sûr,
• des mesures dérivées obtenues à partir de ces mesures de base.
En général, cela est une fondation assez faible dans une perspective de mesure, et les praticiens et les chercheurs devraient
être très prudent dans l’implémentation, l'utilisation et l'interprétation des chiffres qui résultent de l'utilisation de ces modèles
quantitatifs de la norme ISO.
Malgré les commentaires ci-dessus, ces documents ISO demeurent la référence dans la mesure du logiciel, des efforts sont
toujours en cours pour les améliorer.
20 Qualité d'une mesure qui donne le même résultat si on la répète dans des conditions identiques et dans un court intervalle
de temps.
21 Fidélité des résultats d'une même opération ou expérimentation répétée à des moments, en des lieux ou avec des opérateurs
différents.
Processus d’évaluation de la qualité du logiciel
117
4.1.6 Les liens manquants – de la métrologie à l'analyse quantitative
4.1.6.1 Aperçu
Dans l'ISO 9126, il y a une prétention implicite que les mesures proposées (mesures
de base ou dérivées) captent le concept destiné à être quantifié. Cependant, il n' y a pas de
prétention explicite jusqu’où ces mesures captent quantitativement ce concept. Au mieux,
chaque mesure proposée dans la norme ISO 9126 est considérée comme un contributeur non
spécifié d'une telle quantification pour l'évaluation et la prise de décision. Autrement dit:
• Ces mesures ne sont pas considérées comme contributeurs pour la mesure du concept
cible en termes d'une échelle spécifique ou d'un étalon standard;
• mais seulement en tant que contributeurs (dans une certaine proportion) pour sa
quantification (sans échelle de référence largement reconnue et un étalon standard).
En d'autres termes, dans les modèles d’analyse ISO 9126, la solution pratique (quand un
critère de décision ne peut être mesuré directement) est de le quantifier par une association ou
une mise en correspondance (directe ou indirecte).
Un exemple est présenté ci-après avec certaines mesures de base combinées à des mesures
dérivées associés à d'autres concepts (caractéristiques et sous-caractéristiques du modèle ISO
de la qualité du produit logiciel).
Cette section illustre les liens manquants entre les modèles quantitatifs proposés dans la
norme ISO 9126 et les mesures proposées comme contributeurs à cette quantification.
L'exemple choisi est celui de la sous-caractéristique maturité «maturity» et ces 7 mesures
dérivées proposé pour cette sous-caractéristique.
Pour la sous-caractéristique maturité comme exemple:
• Les relations entre l'attribut mesuré par la mesure dérivée “la densité de défaillances
par cas de test ” (“ Failure density against test cases”) et la sous-caractéristique
maturité et la caractéristique fiabilité «reliability» ne sont ni identifiés, ni décrites dans
la norme ;
• Aucun modèle de ces relations qu’il soit est proposé.
Processus d’évaluation de la qualité du logiciel
118
4.1.6.2 Analyse des Mesures de “Maturité”
Le modèle proposé par l'ISO 9126 pour quantifier la qualité externe d'un produit
logiciel contient - comme montré dans la figure 4.3 - six caractéristiques et 27 sous-
caractéristiques de qualité:
• L'une des six caractéristiques de la qualité est la fiabilité « reliability », qui est
composée de 4 sous-caractéristiques;
• Une de ces quatre sous-caractéristiques est la maturité « maturity », qui est choisie
ici comme exemple.
Pour quantifier cette sous-caractéristique « maturity », ISO 9126-3 propose une liste de sept
mesures distinctes dérivées:
1. Failure density against test cases
2. Estimated latent fault density
3. Fault Density
4. Fault removal
5. Mean time between failures (MTBF)
6. Test coverage
7. Test maturity
Definitions ISO 9126 relatives
Fiabilité: La capacité du produit logiciel à maintenir un certain niveau de performance lorsqu'il est utilisé dans des
conditions spécifiques. Maturité: La capacité du produit logiciel à éviter les défaillances en raison de failles dans le logiciel.
4.1.6.2.1 Perspectives en métrologie
Chacune de ces sept mesures dérivées est présentée à un niveau assez abstrait comme
des formules composées à partir d'un ensemble de mesures de base, elles-mêmes manquent
des descriptions détaillées, y compris les attributs qu'ils visent à mesurer.
Ce qui rend ces mesures très sensibles à des interprétations individuelles: ni les mesures de
base pour ces opérations, ni les attributs correspondants ne sont décrits avec suffisamment de
clarté pour assurer la qualité des résultats de mesure.
Elles ne sont pas documentées à un niveau suffisamment détaillé pour fournir des indications
suffisantes pour assurer la précision, la répétabilité et la reproductibilité des résultats de
mesures, dans le cas où le même logiciel est mesuré par différentes personnes, ce qui entraîne
des résultats potentiellement très différents.
Processus d’évaluation de la qualité du logiciel
119
Table de mesure dérivée «Densité de défaillance par cas de test» pour quantifier la sous-caractéristique "Maturité" (ISO/IEC 9126-2)
Chacune des sept mesures dérivées proposées sont décrites individuellement comme illustré
dans le texte encadré ci-après et la table ci-dessus avec comme exemple «densité de
défaillances par cas de test ».
Exemple: "Densité de défaillances par cas de test" Objectif de cette mesure dérivée de la norme ISO 9126: Quel est le nombre de défaillances détectées pendant une
période d'essai définie? Méthode d'application de cette mesure dérivée: Compter le nombre de défaillances détectées et le nombre de cas
de test effectué.
Cependant, aucune des mesures de base utilisées ne sont définie précisément dans la norme ISO 9126,
y compris les notions de défaillance et les cas de test.
4.1.6.2.2 Perspectives du modèle d'analyse de la norme ISO 9126
Il n'y a pas de contexte ISO défini ou de valeurs pour un tel contexte. Chaque groupe
au sein de chaque organisation doit construire son propre ensemble de valeurs pour l'analyse
dans un contexte spécifique. Quelle est la contribution spécifique de chacune des sept mesures
ci-dessus dans la quantification de la sous-caractéristique maturité?
• Y a t-il des chevauchements dans les relations de l'une de ces sept mesures dérivées,
et si oui, jusqu'à quel point?
• Si ce n'est pas toutes les sept mesures dérivées sont nécessaires, quelles sont celles
les plus représentatives de la maturité, et si oui, dans quelle mesure?
Nous demandons maintenant à quel point la mesure dérivée «densité de défaillances par cas
de test » décrit (quantifier) la hiérarchie des concepts du modèle de la qualité du produit
logiciel de la norme ISO 9126: A quel point la sous- caractéristique maturité est évaluée par
ces mesures dérivées?
Processus d’évaluation de la qualité du logiciel
120
• En pratique, la mesure dérivée «densité de défaillances par cas de test » n'est qu'un
contributeur, qui est un indicateur22
dans cette partie de la hiérarchie de la qualité
relative à ces concepts.
• Comment peut-on quantifier cette contribution? La réponse n'est pas donnée dans la
norme ISO 9126 - 4, ou même identifié comme un problème !
4.1.6.2.3 Les liens manquants
Aucun des liens prévus entre cette base de métrologie (faible) pour la mesure des
attributs de base ou dérivés et la quantification de la qualité de la sous-caractéristique «p.ex.
Maturité » et la caractéristique «p.ex. Fiabilité » n’est décrit dans la norme ISO 9126.
Nous espérons que ces liens seront décrits, mais il faudra des années de recherche et de
développement afin de mieux cerner ce problème et de développer des modèles d'analyse
basés sur des preuves empiriques solides.
4.2 W-Process pour l’évaluation du produit logiciel:
Une méthode axée sur les objectifs pour l’implémentation de la norme ISO 1459823
L'origine de la non-satisfaction dans l’évaluation du produit logiciel est souvent
diagnostiquée comme étant un problème de mesure. La solution au problème consiste donc à
définir les métriques appropriées pour prédire ou déterminer les caractéristiques de qualité ou
les propriétés du produit. Basé sur cette perception, beaucoup de recherches axées sur le choix
ou la définition de nouvelles métriques appropriées ont été menées. Comme exemple, on peut
citer les travaux de [Briand et al, 99] : les relations entre les métriques couplage/cohésion et
la prédisposition aux fautes des classes orientée objet (OO).
Les auteurs de la méthode W-Proceess soutiennent l’idée que l'évaluation devrait être
basée sur la mesure. Ceci est également suggéré par l’emploi du terme «examen
22 Un indicateur est une mesure qui donne une estimation ou une évaluation d’attributs spécifiés dérivés d'un modèle par
rapport aux besoins d'information. Les indicateurs sont le fondement de l'analyse et la prise de décision. C’est ces indicateurs
qui devraient être présentés aux utilisateurs de mesure. [ISO/IEC 15939]
Un indicateur est le résultat de l’application d’un modèle analytique à une ou plusieurs variables en relation avec les critères
de décision ou un besoin d’information. [ISO/IEC 27004]
23
Software Quality Journal, 12, 137–158, 2004/ TEADE PUNTER, Fraunhofer IESE, Sauerwiesen 6, 67661 Kaiserslautern, Germany
ROB KUSTERS, JOS TRIENEKENS, THEO BEMELMANS and AARNOUT BROMBACHER Eindhoven University of Technology, Den Dolech 2, 5600 MB Eindhoven, The Netherlands
Processus d’évaluation de la qualité du logiciel
121
systématique» indiqué dans la définition ISO d’évaluation. Toutefois, se concentrant
uniquement sur cet aspect est insuffisant pour améliorer les évaluations de produits logiciels.
Il est également nécessaire de gérer les attentes des parties prenantes lors de la formulation
des objectifs ainsi que de les impliquer pendant les activités d'évaluation. Par conséquent, on
devrait considérer également le processus d'évaluation en plus du processus de mesure.
4.2.1 Problèmes liés à la norme ISO 14598
Bien que la norme « ISO 14598_5 - Procédés pour les évaluateurs » soit une
amélioration par rapport à la situation où il n'existe aucune définition, la norme n'a pas le
soutien qui rend son application dans la pratique un succès. Cette section décrit quatre
problèmes qui ne sont pas abordés avec suffisamment de détails par la norme, à savoir:
Objectifs insuffisamment formulés : La norme ISO 14598 commence avec l'activité «Établir
les exigences d’évaluation». Lors de la réalisation d'une évaluation, il y aura toujours le défi
de définir les objectifs (but d’évaluation) d'une manière qui est suffisamment abstraite pour
bien couvrir ce qui est ciblé par ces objectifs ainsi que les définir concrètement afin qu'ils
puissent être opérationnalisés. Cependant, la norme ISO 14598 ne donne pas beaucoup
d’informations sur la façon de définir les objectifs d'évaluation de cette façon. Comme elle
n’indique pas comment impliquer les parties prenantes dans la formulation de ces objectifs.
La norme ISO 14598 ne donne également aucune indication face à l'évolution des objectifs :
des objectif formulés comme importants pourraient avoir moins de poids après un certain
temps. Ceci est particulièrement un problème pour les évaluations qui durent plus longtemps,
environ un an ou plus.
Relations implicites entre les activités : La norme ISO 14598 donne un aperçu clair des
activités qui doivent être menées et ce qui devrait être fait dans ces activités. Cependant, la
norme ne spécifie pas de relations claires entre les activités. La figure 4.6 (Processus
d’évaluation ISO/IEC 14598) exprime clairement que les activités se rapportent à l'une des
quatre phases du processus d’évaluation, mais que dire des relations entre les activités?
L'absence de ces relations cause que les activités doivent être menées de façon isolée, sans
prendre en compte les sorties des activités antérieures, tandis que des incertitudes existent
quant à l’exploitation des sorties des activités actuelles par les activités qui les succèdent. La
gestion des processus basée sur l’objectif d’évaluation n'est pas possible, parce que les
relations entre l'objectif et les activités ne sont pas spécifiés explicitement. Cela pourrait, par
Processus d’évaluation de la qualité du logiciel
122
exemple, conduire à des évaluations dans lesquelles les métriques sont sélectionnées (Pendant
l’activité sélection des métriques) basé sur une argumentation erronée, faute d'informations
suffisantes sur les propriétés de la qualité (définie lors de l'activité spécifier le modèle de
qualité).
Aucun compromis entre objectifs et ressources: Les ressources sont nécessaires pour
effectuer une ou plusieurs activités d'évaluation. Des ressources appropriées devraient être
choisies pour réaliser les objectifs d'évaluation. Un mécanisme qui pourrait être utilisé est
appelé «Compromis entre objectifs et ressources». La norme ISO 14598 traite la notion de
ressources avec le concept de modules d'évaluation. Toutefois, la norme ne traite pas la notion
de compromis en tant que telle, car il est souvent impossible de tracer les objectifs
d'évaluation pour les modules d'évaluation. Par exemple, sachant qu'un module d'évaluation
consiste à déterminer la maintenabilité du logiciel n'est pas suffisant pour lui faire
correspondre une formulation qui exprime uniquement l’objectif maintenabilité. Une relation
explicite avec les objectifs est également nécessaire pour aborder les questions de coût, de
temps et de l’effort du module d'évaluation.
Attention insuffisante accordée aux feedback : Mener des évaluations avec succès exige
également un monitoring de ses processus. Les feedback sont nécessaires pour savoir si les
résultats des processus des activités sont conformes avec les sorties spécifiées afin de pouvoir
réaliser l'objectif d’évaluation. La norme ISO 14598 ne traite pas explicitement le monitoring
et les feedback dans sa définition du processus d'évaluation. Cela implique des évaluations
dont les résultats ne sont évalués qu’à la fin du processus.
4.2.2 Extension de la norme ISO 14598 avec la méthode W-process
Cette section décrit la méthode W-process, qui est une méthode pour mener des
processus d'évaluation d'une manière axée sur les objectifs. La méthode commence par une
restructuration du processus ISO 14598 afin de résoudre les problèmes d'insuffisance de
relations implicites entre les activités ainsi que les compromis explicites insuffisants entre les
objectifs et les ressources. La restructuration se fait sur trois niveaux, à savoir: les niveaux
Objectif, Questions et Métriques. Le principe GQM [Basili & Weiss, 84] a été utilisé pour ces
fins. Ce principe stipule que les objectifs de mesure doivent être formulés comme des
questions. Les réponses à ces questions doivent permettre d’atteindre ces objectifs. Chaque
question doit être raffinée en un ensemble de métriques associées (cf. 4.5 La méthode GQM).
Processus d’évaluation de la qualité du logiciel
123
Avec le principe GQM nous reconnaissons que plusieurs compromis existent dans un
processus de mesure. Premièrement, les objectifs sont opérationnalisés par des questions dont
les réponses devraient nous permettre d'atteindre les objectifs spécifiés. Deuxièmement, les
questions sont opérationnalisées par des métriques dont les valeurs de mesure obtenues
devraient fournir des données pour répondre aux questions.
Ces deux compromis entre l’objectif, les questions et le niveau métrique sont appliqués pour
restructurer le processus d'évaluation ISO 14598. Le résultat de cette restructuration est
présenté dans la figure 4.8. En raison de sa forme, le processus est appelé W-process.
W-process est composé de deux V qui sont en fait deux mouvements différents et
complémentaires, à savoir: la définition-V et l'exécution-V. La définition-V commence avec
l'activité "Déterminer l'objectif d'évaluation" et se termine avec l'activité "Produire un plan
d'évaluation." L'exécution -V commence avec l'activité "Produire un plan d'évaluation" et se
termine par "Déterminer les résultats". Les deux mouvements commencent au niveau objectif
et descendent jusqu’au niveau métrique. Enfin, les deux reviennent au niveau objectif.
Figure 4.8 - La méthode W-Process pour l’évaluation du produit logiciel
Une des hypothèses des auteurs dans la restructuration du processus d’évaluation ISO 14598
est de préserver les activités ISO existantes autant que possible. Les activités ne sont
modifiées seulement si leur examen (review) l’exige. Les activités sont décrites ci-dessous.
Définir les objectifs d'évaluation
Principalement, cette activité a le même but que l'activité «Établir les objectifs d'évaluation»
défini par l'ISO 14598, mais pour résoudre le problème des objectifs insuffisamment
formulés, des directives supplémentaires sont formulées, à savoir:
Processus d’évaluation de la qualité du logiciel
124
• Identifier les objectifs stratégiques (les objectifs qui définissent ce que l'organisation
souhaite atteindre);
• Identifier et impliquer les parties prenantes24
. L’ISO 14598 aborde les divers
intervenants lors d'une évaluation en distinguant différentes perspectives sur le
processus d'évaluation, à savoir développeur, acquéreur et évaluateur. Basé sur leurs
expériences, les auteurs de W-Proceess pensent que les intervenants suivants sont
importants pour l'évaluation : le fournisseur du logiciel – est préoccupé par le résultat
d’évaluation, le client - est intéressé par le résultat d’évaluation, l'évaluateur - est
préoccupé par les questions techniques d’évaluation et la clientèle d’évaluation - est
préoccupée par le coût d’évaluation et l'applicabilité des informations qui en résultent;
• Définir l'objectif d'évaluation selon un modèle de mesure d’objectifs générique. Cette
directive permet de s’assurer que la formulation de l'objectif sera aussi explicite que
possible. Le modèle générique de mesure d’objectifs est un modèle proposé par
l'approche GQM [Solingen & Berghout, 99] qui décrit un objectif donné en abordant
cinq éléments, à savoir: l'objet, le but, la focalisation qualité, le point de vue, et le
contexte. L’utilisation de ce modèle facilitera la définition des objectifs d'évaluation.
• Classer les objectifs d'évaluation par ordre de priorité. Selon les objectifs d'évaluation
qui sont définis ainsi que les informations concernant le temps et les efforts qui peuvent
être consacrés à l'évaluation, les objectifs devraient être priorisés.
Définir le modèle qualité
Cette activité conduit à la définition des propriétés du produit (attributs de qualité,
caractéristiques) qui doivent être remplies par le produit logiciel. L'activité devrait fournir la
même sortie (le même résultat) que celle définie par son équivalent dans le processus
ISO 14598, à savoir un modèle de qualité qui éclate la qualité du logiciel, dans son niveau le
plus bas, à des attributs. Nous distinguons essentiellement deux approches pour définir un
modèle de qualité, notamment par un profil qualité ou par une feuille d'abstraction.
Un profil qualité présente le modèle qualité comme un ensemble de (sous-) caractéristiques
qualité ISO 9126 avec leur degré d'importance: le niveau d'évaluation s'applique à l'une des
24
Une partie prenante est une personne, une équipe ou une organisation ayant un intérêt ou des préoccupations concernant
l'évaluation (IEEE 1471, 2000).
Processus d’évaluation de la qualité du logiciel
125
quatre catégories suivantes: faible (D), moyennes (C), élevé (B) et excellent (A), pour assurer
la sécurité ou pour assurer l'approbation [Rae et al, 95].
Une feuille d'abstraction résume les principales questions et les dépendances d'un objectif
d'évaluation sur quatre quadrants dans une feuille, à savoir:
• Les facteurs qualité: quelles sont les propriétés mesurables de l'objet comme spécifié
dans le modèle générique de mesure d’objectifs?
• Hypothèse de base: quelles sont nos connaissances actuelles des propriétés mesurées?
• Les facteurs de variation: ce qui va influer les facteurs qualité?
• Impact sur l'hypothèse de base: comment ces facteurs de variation influent le modèle
qualité?
Les feuilles d’abstraction proviennent de la méthode GQM où elles sont utilisées pour
soutenir la communication entre les intervenants lors de la définition des questions et des
hypothèses. Avec l'abstraction, les auteurs de la méthode W-Process sont en mesure de
proposer des facteurs qualité pour les intervenants afin qu'une discussion puisse commencer
sur leur pertinence pour le produit en cours d'évaluation. L'avantage est que ces feuilles
peuvent être réutilisées pour définir des modèles de qualité pour de nouvelles évaluations.
Définir un modèle de qualité à l'aide de feuilles d'abstraction peut être comparé au profil
qualité. La différence est qu’en plus des attributs qualité, des hypothèses et leur impact sont
définis. Cette connaissance de mesure facilite le transfert à l'activité suivante «Choix des
métriques».
Choisir les métriques
Durant cette activité, les métriques devraient être définies pour les caractéristiques de qualité
qui ont été définies dans l'activité précédente. La question est de savoir comment définir ces
métriques. Cela peut se faire en regardant les plans de mesure qui existent déjà et en essayant
d'obtenir des idées à partir de mesures basées sur des facteurs semblables. Comme on peut se
référer à une base de données métriques comme celle définie dans le projet SQUID25
« Software Quality in the Development Process » (Boegh et al, 1999). Souvent, les métriques
doivent être soigneusement adaptées selon le contexte, par exemple, pour un langage de
programmation particulier.
25
L’un des grands projets de recherche européens dans le domaine de la qualité logicielle. SQUID a développé son approche
de modélisation de la qualité en parallèle avec les feedback continus à partir des tests réalisés sur le projet «Telescience».
Processus d’évaluation de la qualité du logiciel
126
S'il n'existe pas de références, les métriques et les caractéristiques doivent être définies de la
même manière que nous définissons notre propre-modèle [Fenton & Pfleeger, 97], comme
dans la méthode GQM. Les facteurs dans les feuilles d'abstraction sont alors considérés
comme équivalents aux questions. Par exemple, le facteur « Facilité d’analyse » est lié à des
questions comme: «Quelle est la facilité de modification du logiciel? ».
Un autre problème dans le choix des métriques est la mesure subjective par rapport à la
mesure objective. Dans la mesure du logiciel, les métriques sont souvent considérées comme
étant seulement des métriques de code source. Cependant, pour les évaluations de produits,
une liste d’éléments (peuvent être des métrique appropriées) de vérification peut être utilisée.
Bien évidemment, ces métriques doivent satisfaire aux exigences de mesure de base: la
reproductibilité et la validité. L'avantage de la liste de vérification est que ces éléments
peuvent souvent avoir une portée plus large (sur l'objet, la focalisation qualité) que les
métriques de code source.
Déterminer les critères d’appréciation
Cette activité consiste à déterminer les critères pour les métriques qui sont spécifiées dans
l'activité précédente. La définition des critères d’appréciation est nécessaire pour interpréter
les valeurs réelles des métriques durant l'activité «Comparer avec les critères» au cours du
mouvement exécution-V. Cette activité couvre les activités «Établir les niveaux
d’évaluation» et «Établir les critères d'évaluation» du processus d’évaluation ISO 14598.
Les critères peuvent être définis en établissant des hypothèses pour les facteurs de qualité, la
définition des indicateurs [Park, Goethert & Florac, 96], et enfin commencer des mesures-
pilotes pour déterminer si ces critères ont un sens pour le produit. En pratique, de telles
mesures-pilotes ne peuvent être souvent offertes en raison du coût et du temps limités. Par
conséquent, les critères sont souvent établis implicitement (vaguement), de sorte qu'ils
peuvent être déterminés lors de l'exécution. Une autre possibilité consiste à réutiliser les
critères d'évaluations précédentes. Dans le projet SQUID [Boegh et al, 99], une structure pour
la réutilisation des mesures ainsi que les valeurs cibles (les critères) a été proposée.
Cependant, cette proposition n'a pas été appliquée à grande échelle et sa faisabilité
économique est inconnue. Par conséquent, un critère est toujours une question d'essais et
d'erreurs: démarrer des mesures-pilotes et analyser les données sérieusement.
Processus d’évaluation de la qualité du logiciel
127
Produire un plan d'évaluation
Durant cette activité, l'objectif(s) d'évaluation, le modèle qualité, les métriques et les critères
sont déterminés. Outre ces informations, des techniques de collecte de données ou
d’évaluation sont sélectionnées pour être appliquées lors de l'exécution-V. Un compromis
entre les objectifs et les ressources devraient être établi lors de cette activité. Des informations
sur les efforts sont indispensables pour appliquer les techniques, ceci étant nécessaire pour ce
compromis. Cela en résulte dans le format suivant pour décrire les techniques d'évaluation:
• L’objet - l'objet ciblé par la technique, par exemple, le code, la conception, le système
implémenté ou la documentation (Hausen & Welzel, 93; Fenton & Pfleeger, 97) ;
• Les caractéristique de la qualité – les propriétés du produit qui sont visées par la
technique. Cela peut être réalisé selon la norme ISO 9126, mais aussi des schémas
alternatifs pourraient également être appliqués [Dromey, 96] ;
• Le niveau d’évaluation - défini comme la capacité de la technique pour obtenir un
résultat correct sur la propriété qui doit être évaluée ;
• L’effort - les expériences concernant le temps et les compétences requises des
personnes impliquées dans l'application de la technique. Les sous-caractéristiques pour
définir l'effort sont: le temps, le nombre et les compétences des personnes impliquées.
Le mécanisme de compromis dans lequel les objectifs et les ressources sont impliqués est
exprimé dans la figure 4.9. La figure montre deux techniques principales (qui en tant que
telles sont une sous-catégorie de ressources d'évaluation), à savoir: les feuilles d'abstraction
(qui sont applicables lors de la définition-V) et les techniques d'évaluation (appliquées lors de
l'exécution-V).
Avec l'activité «Produire le plan d'évaluation » la définition-V est terminée. A ce point, des
feedback devraient être présentés au client. S'il n'y a pas d'adéquation entre les attentes du
client et le contenu du plan d'évaluation, la définition-V devrait être effectuée de nouveau.
Processus d’évaluation de la qualité du logiciel
128
Figure 4.9. Informations nécessaires sur les objectifs et les ressources pour réaliser un compromis.
Exécution-V
La méthode W-process a un impact particulier sur les premières phases du processus
d’évaluation de la norme ISO 14598: la définition-V. Par conséquent, ses activités ont été
modifiées par rapport au processus d’évaluation de la norme. Cependant, les activités décrites
durant l'exécution-V sont similaires à celles présentées par la norme ISO. Les auteurs ne
proposent pas de changements pour ces activités. L'activité «Prendre des mesures» concerne
la collecte de données. L'activité «Comparer aux critères » porte sur l'interprétation des
données trouvées pendant l'activité précédente. Enfin, des réponses aux questions/objectifs à
l'origine d’initiation d'évaluation doivent être données. Ceci est réalisé pendant l'activité
«Déterminer les résultats». Les parties 3 et 5 de la norme ISO 14598 fournissent des
directives pour la conduite de ces activités avec succès. Des directives supplémentaires pour
la collecte de données et leur interprétation peuvent être trouvées [Fenton & Pfleeger, 97].
Moments de feedbacks et de compromis
Normalement, notre connaissance va s’enrichir dans la conduite des évaluations et en passant
la méthode W-process de gauche à droite. Il sera préférable de conduire des feedback pendant
plusieurs étapes du processus ainsi que de se focaliser sur les compromis entre objectifs et
ressources. La figure 4.10 donne un aperçu de ces moments où il est plus susceptible de
conduire des feedback ou de définir un compromis. Cet aperçu est destiné à planifier des
feedback et des compromis lors de la conduite d'un processus d'évaluation.
Processus d’évaluation de la qualité du logiciel
129
Figure 4.10. Moments de feedback et de compromis dans la méthode W-process.
4.3 Processus d’évaluation de la qualité du logiciel
(Yann-Gaël Guéhéneuc - IFT3903, Université de Montréal 2006)
Le processus d’évaluation proposé est construit autour des normes ISO 9126 et ISO
14598 qui tracent les grandes lignes et proposent un cadre pour l’évaluation du produit
logiciel. Ce processus est complété par la méthode GQM pour le choix des indicateurs
adéquats et QIP26
pour les améliorer. Comme alternative, le projet SCOPE (cf. 1.7.4 SCOPE
projet européen ESPRIT), qui définit un cadre complet pour l’évaluation, peut être utilisé.
Figure 4.11. Processus d’évaluation de la qualité du logiciel (Yann-Gaël Guéhéneuc - IFT3903, Université de Montréal 2006)
26 Le Quality Improvement Paradigm (QIP) a été proposée par le Software Engineering Laboratory (SEL) de l’Université de
Maryland afin d’offrir un support pour la mise en oeuvre de l’amélioration du processus en six étapes : caractérisation,
définition des objectifs, choix du processus, exécution, analyse et consolidation. Le QIP indique comment mettre en place
un processus continu d’amélioration qui prend en compte les expériences précédentes. Deux outils sont utilisés par la QIP : le
Goal/Question/Metric (GQM) et l’Experience Factory(EF).
Processus d’évaluation de la qualité du logiciel
130
4.4 Processus d’évaluation selon la norme ISO/IEC 25000 ou SQuaRE
(Software Quality Requirements and Evaluation)
Comme indiqué en (1.7.5 ISO/IEC 25000 « SQuaRE ») Cette norme offre un cadre
pour l’intégration des évolutions des normes ISO 9126 la qualité logicielle, et ISO 14598
l’évaluation de la qualité logicielle. Elle est organisée en 5 divisions (figure 1.5).
La série 2504n «Division d'évaluation de la qualité» se compose actuellement des normes
internationales suivantes:
• ISO / IEC 25040 - Modèle d'évaluation de référence et guide: contient les exigences
générales pour la spécification et l'évaluation de la qualité du logiciel et clarifie les
concepts généraux. Fournit une description du processus d'évaluation27
de la qualité du
produit logiciel et énonce les conditions pour l'application de ce processus (ISO / IEC
9126-1 et 14598-1);
• ISO / IEC 25041 - Modules d'évaluation: définit la structure et le contenu de la
documentation qui sera utilisé pour décrire un module d'évaluation. Ces modules
d'évaluation contiennent la spécification du modèle de qualité (caractéristiques, sous-
caractéristiques et les mesures28
correspondantes interne, externe ou de qualité
d'utilisation). Des modules d'évaluation appropriés sont sélectionnés pour chaque
évaluation. Dans certains cas il peut être nécessaire de développer de nouveaux modules
(ISO/IEC 14598-6) ;
• ISO / IEC 25042 - Processus d'évaluation pour les développeurs: fournit des
exigences et des recommandations pour évaluer des produits logiciels lorsque
l'évaluation est menée en parallèle avec les développements (ISO/IEC 14598-3) ;
• ISO / IEC 25043 - Processus d'évaluation pour les acquéreurs: contient des
exigences, des recommandations et des directives pour la mesure systématique,
27
Certaines normes de la série ISO/IEC 25000 sont toujours en cours d’édition par l’ISO et celles disponibles restent hors de
notre portée (à moins de les commander en ligne sur le site de l’ISO http://www.iso.org/). A titre indicatif, la norme ISO/IEC
25040 Systems and software Quality Requirements and Evaluation (SQuaRE) -- Evaluation process, qui révise et remplace la
norme ISO/IEC 14598_1 :1999 Software product evaluation, est éditée en Mars 2011. Alors que les autres normes qui la
complètent (ISO/IEC 25042, 25043, 25044 exceptée ISO/IEC DIS 25041) et qui font toutes partie des normes de la division
2504n Evaluation de la qualité ne sont toujours pas disponibles. Pour ces raisons, on est dans l’incapacité de décrire le
processus d’évaluation du produit logiciel selon la nouvelle norme ISO/IEC 25000.
28
Le terme mesure dans l’ISO 25000 remplace le terme métrique employé dans l’ISO 9126 et l’ISO 14598.
Processus d’évaluation de la qualité du logiciel
131
l'évaluation de la qualité des produits logiciels lors de l'acquisition, pour des produits
logiciels personnalisés, ou pour des modifications apportées aux produits logiciels
existants (ISO/IEC 12119 et 14598-4) ;
• ISO / IEC 25044 - Processus d'évaluation pour les évaluateurs: fournit des exigences
et des recommandations pour l'évaluation des produits logiciels, lorsque plusieurs
parties ont besoin de comprendre, d'accepter et d’avoir confiance dans les résultats de
l'évaluation (ISO / IEC 14598-5).
Pour conduire des évaluations sous SQuaRE, un modèle de référence générale (figure
4.12) a été créé pour aider les utilisateurs à naviguer à travers les différentes normes de la
série SQuaRE. Le choix des normes appropriées et des documents de la série SQuaRE dépend
du rôle de l'utilisateur et les besoins d'information. Il est recommandé de tous les utilisateurs
de consulter d’abord (ISO / IEC 25000) en plus des parties qui sont pertinentes à leur besoin
d'information et leur rôle spécifiques.
Figure 4.12. Modèle de référence général SQuaRE
Processus d’évaluation de la qualité du logiciel
132
4.5 Le Goal/Question/Metric (GQM)
Goal-Question-Metric (GQM) est un concept de la façon de procéder lors de la
mesure. Il a été créé par Basili et Weiss 1984. La mesure est nécessaire pour contrôler le
processus de développement logiciel et le produit logiciel. L'idée de base de GQM est de
dériver des mesures de logiciels à partir des questions de mesure et des objectifs.
GQM est utilisé pour définir des objectifs (buts) mesurables, qui peuvent être utilisés
d’une manière isolée ou dans le cadre d’une démarche d’amélioration [Basili et al. 94]. Le
résultat de l’application de GQM est la spécification d’un système de mesures visant un
ensemble particulier de problèmes ainsi qu’un ensemble de règles dédiées à l’interprétation
des données issues de ces mesures. Ce système de mesure (Approche GQM) est organisé en
trois niveaux : « Goal » le niveau conceptuel, « Question » le niveau opérationnel et
«Metric » le niveau quantitatif.
1. Goal (niveau conceptuel) : Au niveau conceptuel un objectif(s) est défini pour un
objet, pour différentes raisons, par rapport à différents modèles de qualité, depuis
différents points de vue et relativement à un environnement particulier. Les objets
peuvent être des produits, des processus ou bien des ressources.
2. Question (niveau opérationnel) : A ce niveau un ensemble de questions est défini afin
de caractériser la manière dont les objectifs vont être atteints. Les questions essayent
de caractériser l’objet de la mesure par rapport à un problème de qualité ainsi que de
déterminer sa qualité depuis un point de vue choisi.
3. Metric (niveau quantitatif) : Au niveau quantitatif un ensemble de données est associé
à chaque question afin d’y répondre d’une manière quantitative. Les données peuvent
être objectives : dépendant seulement de l’objet qui est mesuré et non pas d’un point
de vue (par exemple le numéro des versions d’un document) ; ou bien subjectives :
dépendant de l’objet qui est mesuré ainsi que du point de vue de la mesure (par
exemple la lisibilité d’un texte, le niveau de satisfaction de l’utilisateur).
L'approche GQM définit quelques objectifs, raffine ces objectifs en un ensemble de questions.
Ces questions à leur tour sont raffinées dans des métriques. Pour illustrer ces concepts, on
reprendra ici, l’exemple donné dans le livre de Fenton [Fenton & Pfleeger, 97] :
Processus d’évaluation de la qualité du logiciel
133
Figure 4.13. L’approche GQM [Ebert et al, 05]
Considérant comme objectif «Evaluer l’efficacité de coder selon la norme ». Pour décider si
la norme est efficace, nous devons vérifier certaines questions. Une question peut-être « qui
sont les développeurs qui utilisent la norme lorsqu’ils écrivent du code » car il est important
de savoir quelle est la proportion des développeurs qui utilisent la norme. La métrique
pourrait être « la proportion de développeurs utilisant la norme », et ainsi de suite. Plusieurs
mesures peuvent être nécessaires pour répondre à une seule question; d'autre part, une seule
mesure peut être appliquée à plus d'une question. La figure suivante montre comment
différentes métriques peuvent être générées à partir d'un seul objectif.
Figure 4.14. La hiérarchie GQM [Fenton & Pfleeger, 97]
Processus d’évaluation de la qualité du logiciel
134
Il est possible, et souvent très utile, de combiner deux approches, par exemple, GQM
avec CMM(Capability Maturity Model) ou CMMI (CMM intégré) qui accorde encore plus
d'attention à la mesure. Un modèle CMM ou CMMI aide les organisations à améliorer la
maturité de leurs processus logiciels ce qui permet de diminuer le niveau du risque dans la
performance. L’approche CMM suggère que nous pourrions mesurer seulement ce qui est
visible. L’utilisation, à la fois, de CMM et GQM nous donne ainsi une image plus complète
des mesures qui seront les plus utiles. GQM permet de nous répondre pourquoi nous
mesurons un attribut, et CMM nous renseigne si nous sommes capables de le mesurer d’une
manière significative [Ebert et al, 05].
Conclusion
L'importance d’évaluation du produit logiciel va croître avec la prise de conscience de
la nécessité d'une meilleure qualité des logiciels. Le processus de mener de telles évaluations
est essentiel pour obtenir des résultats qui peuvent être appliqués et répondent aux attentes des
clients. Dans ce chapitre, nous avons passé en revue le processus d'évaluation du produit
logiciel selon les normes ISO 9126/ ISO 14598.
L'évaluation et la prise de décision sur la base de critères de décision dans les normes
ISO 9126/ISO 14598 est généralement effectuées en quatre étapes (quatre processus de
quantification): d'abord établir les exigences d'évaluation, puis identifier le contexte
d'interprétation qui implique la spécification, enfin concevoir et exécuter l'évaluation.
Les modèles de qualité ISO 9126 sont décrits à un niveau très détaillé mais les relations entre
les modèles, les caractéristiques et sous-caractéristiques de qualité ne sont pas bien comprises
et mal décrites. En plus, les normes ISO 9126 et ISO 14598 (y compris la future norme ISO
25000) ne proposent pas « de modèles de référence d'analyse» spécifiques, ni un inventaire
des "contextes de référence organisationnels" avec des valeurs de référence et des critères de
décision. Chaque organisation doit donc définir ses propres modèles et critères de décision.
Les mesures disponibles pour la collecte de données pour les modèles de la qualité ISO 9126
sont proposées et décrites dans les trois rapports techniques ISO 9126_2/3/4 : plus de 250
mesures dérivées pour chaque caractéristique ou sous-caractéristique de la qualité et 80
mesures de base étant recensées. Des explications sur la façon de les appliquer sont également
Processus d’évaluation de la qualité du logiciel
135
fournies par la norme. Les mesures dérivées sont présentées à un niveau assez abstrait comme
des formules composées à partir d'un ensemble de mesures de base, elles-mêmes manquent
des descriptions détaillées, y compris les attributs qu'ils visent à mesurer.
Aucun des liens prévus entre la base de métrologie dans l’ISO 9126 pour la mesure des
attributs de base ou dérivés et la quantification de la qualité des (sous-) caractéristiques ni
décrit dans la norme.
D’autres processus d’évaluation, basées sur les normes ISO 9126/ ISO 14598, ont été
présentés, à savoir ; W-process (ROB KUSTERS, JOS TRIENEKENS, THEO BEMELMANS and
AARNOUT BROMBACHER - Eindhoven University of Technology, Den Dolech 2, 5600 MB Eindhoven, The
Netherlands) et le Processus d’évaluation de la qualité du logiciel (Yann-Gaël Guéhéneuc - IFT3903,
Université de Montreal 2006). Ces processus utilisent la méthode GQM (qui dérive des mesures de
logiciels à partir des questions de mesure et des objectifs) et d’autres méthodes pour palier les
insuffisances constatées dans la norme.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
137
Chapitre 5.
La maintenabilité du produit logiciel (Le modèle
MM6P_ISO9126) : Analyse & Evaluation
En raison de son impact économique "la maintenabilité" est largement acceptée
comme un attribut important de la qualité des systèmes logiciels. 80% des coûts d'un système
logiciel ne vont pas dans son développement initial, mais dans sa maintenance [Pigoski, 96].
L'effort nécessaire pour maintenir un système logiciel est lié à la qualité technique du code
source de ce système. IEEE définit la maintenabilité comme étant «la facilité avec laquelle un
système ou un composant logiciel peut être modifié pour corriger des défauts, améliorer les
performances ou d’autres attributs, ou pour s'adapter à un environnement modifié.» Le
modèle de qualité ISO 9126 du produit logiciel reconnaît la maintenabilité «maintainability»
comme l'une des six principales caractéristiques de la qualité du produit logiciel, avec la
facilité d’analyse « analysability », la facilité de modification «changeability», la stabilité
« stability » et la facilité de tests «testability» comme sous-caractéristiques de la
maintenabilité (figure 4.3). La norme ISO 9126 ne fournit pas de mesures (consensuelles)
pour estimer la maintenabilité sur la base du code source d'un système logiciel. D'autre part,
l'index de maintenabilité a été proposé pour calculer un nombre unique qui exprime la
maintenabilité d'un système sur la base de son code source [Oman & Hagemeister, 94] et
[Coleman et al, 94].
Dans ce chapitre, nous exposerons une étude d’évaluation de la maintenabilité du
logiciel. Comme logiciels de démonstration, nous considérons à la fois une application
industrielle (closed source) LGL-Etat Civil, et plusieurs autres applications (open source)
SDCC, eMule, NStduio, 7 zip, et WDents (tableau 14). Pour cela, nous proposerons un
modèle de maintenabilité qui assure la mise en correspondance des caractéristiques de
maintenabilité au niveau système avec les mesures au niveau de son code source. Un modèle
alternatif dans lequel un ensemble de métriques bien choisies sont liées « mapped on »
directement sur les sous-caractéristiques de la maintenabilité selon l’ISO 9126.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
138
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
139
5.1 Mesure de la maintenabilité selon l’ISO 9126
Selon la norme ISO 9126 (figure 4.3), la caractéristique maintenabilité, est subdivisée
en (sous-caractéristiques):
• la facilité d’analyse: combien il est facile ou difficile de diagnostiquer des
déficiences ou d'identifier les parties qui ont besoin d'être modifiés dans le système?
• la facilité de modification: combien il est facile ou difficile d’apporter des
adaptations au système?
• la stabilité: combien il est facile ou difficile de garder le système dans un état
cohérent lors de modifications?
• la facilité de tests: combien il est facile ou difficile de tester le système après des
modifications?
• conformité de la maintenabilité: combien il est facile ou difficile pour le système de
respecter les normes ou les conventions en matière de maintenabilité?
La norme, dans ses rapports techniques accompagnant le modèle de qualité standard,
définit 16 mesures de qualité externes (ISO/IEC 9126_2) et 9 mesures de qualité internes
(ISO/IEC 9126_3) pour la caractéristique maintenabilité (voir annexe II).
1) Les métriques externes: les métriques externes suggérées par la norme sont calculées en
mesurant la performance de l'activité de maintenance29
par le personnel technique. Par
exemple, pour mesurer la sous-caractéristique facilité de modification «changeability», le
"temps écoulé pour un changement d’implémentation" est suggéré. Un paramètre de cette
mesure est le temps moyen qui s'écoule entre le moment du diagnostic et le moment de
correction d'une déficience. Pour mesurer la sous-caractéristique facilité de tests «testability»,
le "re-test d’efficacité" est proposé comme mesure, calculé à partir du temps écoulé pour
obtenir la certitude qu'une déficience a en effet été corrigée. Ainsi, la maintenabilité du
logiciel est estimée par le timing des durées des tâches d'entretien.
29 La maintenance est le processus de modification d’un logiciel après la livraison pour corriger les fautes, pour améliorer la
performance ou les autres attributs ou pour adapter le produit à un environnement modifié. IEEE Std 610. 12-1990.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
140
2) Les métriques internes: certaines métriques internes proposées par l’ISO 9126_3 sont
basées sur une comparaison des fonctionnalités requises et les fonctionnalités implémentées.
Par exemple, pour mesurer la sous-caractéristique facilité d’analyse «analysability», la
mesure "activité d’enregistrement" est proposée, elle est définie comme le rapport entre le
nombre d'éléments de données pour lesquels l'enregistrement est effectué par rapport au
nombre d'éléments de données dont les spécifications nécessitent de les enregistrer. D'autres
mesures internes se basent sur les mesures de l'activité de maintenance. Par exemple,
"l'impact du changement" qui mesure la facilité de modification «changeability». Il est
calculé à partir du nombre de modifications apportées et le nombre de problèmes causés par
ces modifications.
Ces mesures internes et externes suggérées ne sont pas (exclusivement) basées sur
l'observation directe du produit logiciel, mais plutôt sur des observations basées sur
l'interaction entre le produit et son environnement: son personnel technique, ses testeurs, ses
administrateurs, ou sur la comparaison du produit à ses spécifications, qui elles-mêmes
pourraient être incomplètes, dépassées, ou incorrectes. Par conséquent, pour mesurer la
maintenabilité par observation directe du code source d’un système, les normes s’avèrent
insuffisantes (rien n’est mentionné à ce sujet dans la norme ISO 9126 ni dans la nouvelle
norme ISO 25000).
5.2 Limites de l’index de maintenabilité dans l’évaluation de la qualité du logiciel
L'index de maintenabilité (Maintainability Index MI) a été proposé pour déterminer
objectivement la maintenabilité des systèmes logiciels en se basant sur le code source
correspondant [Oman & Hagemeister, 94] et [Coleman et al, 94]. MI est un nombre
composé, basé sur plusieurs métriques différentes (cf. 3.7 l’index de maintenabilité). Il est
basé sur le volume de Halstead (aveV), la complexité cyclomatique (aveC), le nombre moyen
de lignes de code par module (aveLOC), et éventuellement le pourcentage de lignes de
commentaires par module (perCM). Le volume de Halstead, à son tour, est composé des
métriques basées sur un nombre (distinct) d’opérateurs et d’opérandes dans le code source.
MI = 171 - 5.2 × ln(aveV) -0.23 × aveG - 16.2 × ln(aveLOC) + 50 × sin(sqrt(2.4 × perCM))
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
141
Cette formule est le résultat de collecte de données sur un grand nombre de systèmes, calibrés
avec l'avis d'experts du personnel technique qui les maintient. Un système avec une valeur de
MI inférieure à 65 est considéré plus maintenable, en se référant aux valeurs de seuil
proposées par Hewlett-Packard [14] (cf. 3.7 l’index de maintenabilité). Cependant, de
nombreuses études d’évaluation menées par de nombreux chercheurs sur différents systèmes
ont montrées un certain nombre de limitations importantes de MI dans le contexte de
l’évaluation de la qualité du logiciel :
A. l'analyse des causes : compte tenu que MI est un nombre composé, il est très difficile de
déterminer ce qui provoque une valeur particulière pour MI. En effet, la formule est
entièrement basée sur des corrélations statistiques, il ne peut donc y avoir aucune relation
causale entre les différentes valeurs des métriques qui sont impliquées dans le calcul de MI. Si
MI a une valeur particulièrement faible, indiquant une maintenabilité faible, il n'est pas du
tout clair quelles mesures peuvent être prises pour l'augmenter. Il faut donc passer en revue
toutes les métriques utilisées pour le calcul de MI.
B. la complexité moyenne : l’une des métriques utilisées dans le calcul de MI est la
complexité cyclomatique. La valeur moyenne de la complexité cyclomatique (aveG) par
module est imparfaite et tout particulièrement pour les systèmes utilisant la technologie
orientée objet [Ilja et al, 07]. En général, l'utilisation de la moyenne à des mesures globales
sur des parties du système individuel tend à masquer la présence d'un risque élevé de ces
parties.
C. la calculabilité : les métriques de Halstead sont difficiles à définir et à calculer. Il n'existe
aucune définition consensuelle de ce qui constitue un opérateur ou un opérande pour certains
langages (comme Java ou C #). Pour cette raison et d'autres [Al-Qutaish & Abran, 05] et
[Jones, 94], le volume de Halstead est une mesure qui demeure contestée dans l'ingénierie
logicielle.
D. la facilité de compréhension : La formule de calcule de MI est difficile de comprendre et
d’expliquer et il n'existe pas d’argument logique qui explique la présence de constantes
particulières, des variables et autres symboles dans la formule. En effet, pourquoi la formule
comporte deux mesures de volume (aveG et aveLOC) comme paramètres? Pourquoi la
complexité cyclomatique est multipliée par 0,23? Et pourquoi le nombre de lignes de
commentaires (perCM) apparaît sous une racine carrée et une fonction sinus?
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
142
E. le contrôle : l’utilisation de MI s'avère difficile, tant sur le plan gestion, que sur le plan
technique/développement. Le manque de contrôle sur la valeur de MI ne facilite pas la tâche
des développeurs pour des fins d'évaluation de la qualité logicielle. Ayant une telle mesure à
notre disposition est évidemment plus utile que de ne rien savoir sur l'état de votre système.
5.3 Le modèle de maintenabilité MM6P_ISO9126 (Modèle de Maintenabilité basé sur 06 propriétés du code source – conforme à la norme ISO 9126)
Basé sur les limites des métriques telle que MI, une bonne compréhension des
exigences minimales, qui doivent être remplies par un modèle de maintenabilité fondé sur
l’analyse du code source, est nécessaire. En particulier, nous voulons que les exigences
suivantes soient respectées par les différentes mesures qui peuvent être utilisées dans le
modèle:
• Les mesures doivent être indépendantes de la technologie, le mieux possible. En
conséquence, elles peuvent être appliquées aux systèmes conçus autour d’architectures
différentes utilisant différents langages de programmation;
• Certaines mesures doivent permettre l'analyse des causes en donnant des indices clairs
concernant les relations de causalité entre les propriétés au niveau code et la qualité au
niveau système.
• Chaque mesure devrait avoir une définition simple qui est facile à calculer. En
conséquence, peu d’effort est nécessaire pour effectuer les mesures;
• Chaque mesure doit être simple à comprendre et à expliquer, ce qui devrait faciliter la
communication entre les différents intervenants dans le système.
En tenant compte de ces exigences, nous avons commencé à élaborer un modèle alternatif de
maintenabilité dans lequel un ensemble bien choisi de mesures du code source sont liées
«mapped» aux caractéristiques de la maintenabilité selon l’ISO 9126, Ce n'est en aucun cas
un modèle complet et mature, des ajustements et des améliorations sont donc à prévoir.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
143
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
144
5.3.1 Le «mapping » des caractéristiques de maintenabilité sur les propriétés du code
source dans le modèle MM6P_ISO9126
Dans le modèle de maintenabilité que nous proposons (Fig. 5.1), les caractéristiques de
maintenabilité30
au niveau-système sont liées aux mesures au niveau-code en deux étapes.
Premièrement, ces sous-caractéristiques au niveau système sont liées à des propriétés
au niveau du code source, par exemple la sous-caractéristique facilité de
modification «changeability» d'un système est liée à des propriétés telles que la
complexité et la duplication du code source ;
Deuxièmement, pour chaque propriété une ou plusieurs métriques de code source sont
déterminées. Par exemple, la complexité du code source est mesurée en termes de
complexité cyclomatique, la complexité du flot de contrôle (NBD) et le FAN-OUT des
fonctions/méthodes. La propriété duplication du code source est mesurée soit par les
occurrences des lignes de code identiques (en se basant sur des critères syntaxiques)
soit (au niveau sémantique) par les résultats de l’exécution du code cloné (Fig. 5.2).
Figure 5.2 – La facilité de modification dans le modèle MM6P_ISO9126.
30 On utilise indifféremment les termes : (1) caractéristiques de maintenabilité et (2) sous-caractéristiques de qualité en
termes de maintenabilité.
Function/Method Calls (FAN-OUT) FAN OUT par fonction/méthode
Cyclomatic complexity /Func (or method)
Complexité cyclomatique/Fonc (méthode)
Nested bloc depth (NBD) La profondeur d’imbrication des blocs
Source code duplication La duplication du code source
Source code complexity La complexité du code source
% Duplicated code percentage Pourcentage du code dupliqué
CHANGEABILITY La facilité de modification
Indiquent
Indique
Influence
Influence
Peut être mesurée
Peut être mesurée
Peut être causée par
Peut être causée par
(1) La facilité de modification est liée aux propriétés du code source : complexité & duplication
(2) La propriété du code source complexité est déterminée par les métriques : CC, NBD, Funcion/Method Calls, et la propriété duplication du code source par le pourcentage du code dupliqué.
NIVEAU SYSTEME
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
145
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
146
Notre sélection des propriétés du code source, et le « Mapping » des caractéristiques
de maintenabilité du système sur ces propriétés sont illustrées dans la (Fig. 5.1). Le choix de
fonctions (ou de méthodes, cas des langages orientés objet) comme unités de code source joue
un rôle important dans les différentes propriétés sélectionnées. En effet, par ce choix, nous
voulons considérer la plus petite unité (morceau) de code qui peut être exécutée et testée
individuellement pour la plupart des langages de programmation31
. Dans les langages orientés
objet tels que Java, C #, C++, Visual Basic, Delphi, …, une unité est une méthode, et dans
les langages procéduraux tels que Assembleur, C, Clipper, …, une unité est une procédure
ou fonction.
L'influence des différentes propriétés du code source sur les caractéristiques de la
maintenabilité d'un système logiciel est comme suit (Fig. 5.1 & Tableau 15):
1. La taille du programme: le volume global du code source influence la facilité
d’analyse du système.
2. La taille de la fonction/ la méthode: la longueur de la fonction/méthode en termes
d’instructions exécutables (#statements) influence la facilité d’analyse et la facilité de
tests du système ;
3. La complexité du code source: la complexité du code source par fonction/méthode
influence la facilité de modification et la facilité de tests du système ;
4. La lisibilité: la lisibilité du code source influence la facilité d’analyse du système ;
5. La duplication: le degré des blocs de code source dupliqués influence la facilité
d’analyse et la facilité de modification;
6. Les tests du code source: les unités de test ou plus précisément le degré de couverture
du code source par ces unités influence la facilité d’analyse, la stabilité et la facilité
de tests du système.
Cette liste non exhaustive de propriétés du code source est destinée à fournir des
estimations (non controversées) des relations de causalité principales entre les propriétés
du code source et les différentes caractéristiques de maintenabilité du système.
31 Pour un langage comme COBOL, il n'y a pas de petites unités à considérer hormis le programme dans son intégralité.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
147
5.3.2 Les métriques associées aux propriétés du code sources choisies
Dans ce qui suit, nous allons discuter des métriques associées à chaque propriété du
code source d’une manière plus détaillée:
5.3.2.1 La taille du programme
La taille du programme a un impact négatif sur la facilité d'analyse, car le diagnostic
des défauts ou des parties susceptibles d'être modifiées est d’autant plus difficile et fastidieux
quand un plus grand volume de code source doit être analysé. Cette propriété est déterminée
par les métriques suivantes :
1 - LOC - Exprime la longueur du code en incluant les commentaires et les lignes vides. Un
système peut être évalué en termes de taille suivant la table ci-après, issue des différentes
expériences de recherche, notamment celles du Software Improvement Group [www.sig.eu] :
2 - Physical SLOC - Elle est le plus souvent définie comme le comptage des lignes de code à
l'exclusion des lignes de commentaires et les lignes vides (les blancs). Le SEI (Software
Engineering Institute) dans son rapport sur la taille du logiciel déclare que:
"Counts of physical lines describe size in terms of the physical length of the code as it appears
when printed for people to read." (C.-à-d. le code tel qu'il apparaît lors de l'impression).
Cette métrique est parmi les plus faciles à mesurer, car elle consiste à compter les marqueurs
de fin de ligne plutôt que la syntaxe spécifique à chaque langage de programmation. Nous
devrions seulement spécifier comment reconnaître ce qui est à exclure du comptage, par
exemple, les lignes de commentaires et les lignes vides (non utilisée dans MM6P_ISO9126).
3 - Logical SLOC (#Statements) - Mesure le nombre de constructions de programmation
«statements» qui peuvent s’étaler sur plusieurs lignes physiques. Le compteur idéal examine
la syntaxe du langage et compte explicitement les types de constructions (par exemple, les
déclarations de données). Les règles de comptage des constructions devraient préciser la façon
de reconnaître et de compter les constructions spécifiques pour chaque langage de
programmation.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
148
Logical SLOC est moins sensible aux conventions de formatage et de style que physical
SLOC. Selon toujours le même rapport technique du SEI: “The count of logical statements is
an attempt to characterize size in terms of number of software instructions, irrespective of the
physical format in which they appear.” (C.-à-d. Logical SLOC caractérise la taille en termes
de nombre de constructions, en faisant abstraction du format physique dans lequel elles
apparaissent). Les lignes logiques de code source contiennent les instructions de
programmation et de déclarations de données, converties en un code exécutable et des
données. Elles ne sont rien d’autre que l’implémentation réelle de la conception du logiciel.
Par conséquent, le comptage des lignes logiques est la meilleure mesure de la taille du
logiciel.
Cependant, il est tout à fait possible qu'un programme de 1 KLOC (mesuré en utilisant l’une
des métriques précédentes Physical SLOC ou Logical SLOC) écrit en Assembleur peut être
fonctionnellement équivalent à un autre programme de 200 LOC écrit en Cobol. Cela nous
amène à considérer d’autres métriques indépendantes des langages de programmation pour
estimer la taille d’un programme donné telles que les points de fonction (FP).
4 – La taille en termes de points de fonction/ Function points (FP) - Pour que notre méthode
d’évaluation soit aussi indépendante que possible du langage de programmation, nous
utiliserons les points de fonction d’Alan Albrecht (FP): une métrique indépendante de la
technique de développement qui n’a pas les inconvénients du comptage du nombre de lignes
de code. Elle doit aider à prévoir la taille d’un projet, son effort de développement et la
productivité du développement informatique. A cet effet, nous utiliserons la table des
langages de programmation du SPR (Software Productivity Research). Cette table indique,
pour un langage de programmation donné, combien de lignes de code logique (#stat) en
moyenne correspondant à un point de fonction (FP) en utilisant ce langage.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
149
5.3.2.2 La taille de la fonction/méthode
La taille de la fonction/méthode à partir de laquelle un système est composé pourrait
faire la lumière sur sa maintenabilité. Intuitivement, les grandes fonctions/méthodes sont plus
difficiles à maintenir parce qu'elles demandent plus de temps pour les analyser et les tester.
1 - #Stat/Function (Method) – Ici encore, on utilise les lignes logiques de code source
comme métrique pour estimer la taille de chaque fonction/méthode qui compose le système.
D’après Verifysoft Technology [verifysoft.com], les valeurs recommandées pour une
fonction se situent entre 4 et 40 LOCpro (nombre de lignes avec du code programme :
déclarations, définitions, directives et code).
5.3.2.3 La complexité du code source
La propriété complexité du code source se réfère au degré de complexité interne des unités
(fonctions ou méthodes) à partir desquelles il est composé. Les unités complexes sont
difficiles à comprendre (analyser) et difficile à tester, la complexité d'une unité a donc un
impact négatif sur la facilité d’analyse et la facilité de tests du système.
1 – La complexité cyclomatique par fonction/méthode CC/Function (Method)
Comme la fonction (ou la méthode) est la plus petite unité du système qui peut être exécutée
et testée individuellement, il est logique de calculer la complexité cyclomatique pour chaque
fonction (ou méthode) du système « les unités ayant des valeurs de CC supérieures à 10
doivent être réécrite cf. 3.4.3 ». Comme déjà mentionné en paragraphe 5.2, l’utilisation de
la valeur moyenne de la complexité cyclomatique des fonctions (ou méthodes) tend à masquer
la présence d’un risque élevé de quelques fonctions (ou méthodes). D’autre part, la
sommation des complexités de ces unités fournit un certain nombre qui reflète la complexité
de l'ensemble du système. Cependant, cette somme est fortement corrélée avec la taille du
programme, par conséquent, elle n'a pas de sens comme mesure de la complexité
[Shepperd, 98]. Une autre méthode pour calculer la complexité doit être utilisée, abstraction
faite du volume de ces unités. Pour cela, (i) nous considérons d’abord la table du SEI qui
donne le niveau de risque de chaque unité suivant sa catégorie de complexité.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
150
(ii) Ensuite, nous effectuons une agrégation des complexités par unité en comptabilisant pour
chaque niveau de risque le pourcentage des lignes logiques de code correspondant. Par
exemple, si, dans un système de 10.000 (#Stat), les ensembles d’unités ayant les niveaux de
risque (modéré, élevé, plus élevé) représentent (4900, 1200, 600 #stat) alors le nombre total
que nous calculons pour chaque catégorie de risque est de (49%, 12%, 6%).
(iii) Enfin, pour déterminer la complexité globale du système nous redéfinirons la table
proposée par le Software Improvement Group dans leur modèle d’évaluation de la
maintenabilité [Ilja et al, 07] en utilisant la métrique Logical SLOC (#Statements) au lieu de
LOC (lignes de codes y compris les blancs et les commentaires).
Ainsi, pour qu’un système soit noté + +, il ne doit pas avoir plus de 25% de code avec un
risque modéré, et aucun code avec un risque élevé ou très élevé. Pour être noté +, le système
ne peut pas avoir plus de 30% de code avec un risque modéré, pas plus de 5% de code avec
risque élevé, et aucun code avec un risque très élevé. Un système qui a plus de 50% du code
avec un risque modéré ou plus de 15% du code avec un risque élevé ou plus de 5% du code
avec un risque très élevé sera noté - - (cas de systèmes trop complexes à maintenir).
2 – La profondeur d’imbrication des blocs de code par fonction (méthode) -
Nested Bloc Depth/Function (method) –
Cette métrique calcule les niveaux d’imbrication des blocs de contrôle au sein d’une fonction
(ou méthode). Au début de chaque module ou fichier, le niveau d’imbrication du bloc est égal
à 0. Les méthodes ou fonctions ayant plus de 09 niveaux32
d’imbrications sont considérées
trop complexes, il faut donc les réécrire.
32 09 niveaux d’imbrication est la valeur max utilisée dans SourceMonitor [version 3.1.5.190, Sept 2011]. D’autres logiciels
de calcul des métriques utilisent des valeurs de seuil inférieures à 09. Par exemple, cette valeur est de l’ordre de 5 dans
Metrics [Plug-in pour Eclipse, version 1.3.6, 2005].
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
151
3 – Le FAN-OUT par fonction (ou méthode) /Function (or method) calls – Cette métrique
indique le nombre de fonctions appelées par une fonction donnée. La modification de cette
dernière peut provoquer des effets secondaires dans les fonctions qui sont appelées par celle-
ci (la fonction modifiée). Ainsi, pour d’éventuelles modifications de cette fonction, le
développeur doit comprendre toutes les autres fonctions ce qui demande beaucoup de temps et
rend la maintenance plus délicate. Par conséquent, les fonctions avec des valeurs de FAN-
OUT élevées seront plus difficiles à maintenir.
5.3.2.4 La lisibilité du code source
En programmation, la lisibilité désigne la facilité avec laquelle un lecteur peut
comprendre un programme (le code source). Elle affecte les aspects de la qualité, y compris la
portabilité, la facilité d’utilisation et surtout la maintenabilité [Set Laboratories, 94].
Aggarwal affirme que la lisibilité du code source ainsi que la lisibilité de la documentation
sont critiques pour la maintenabilité d’un projet [Aggarwal et al, 02]. D’autres chercheurs ont
noté que l'acte de lecture du code est la composante qui consomme le plus de temps de toutes
les activités de maintenance [Deimel Jr, 85] et [Raymond, 91].
En adoptant un style de programmation cohérent permet souvent d’améliorer la
lisibilité. Une étude [Elshoff & Marcotty, 82] a montré que de simples transformations en
matière de lisibilité réduisent considérablement le temps de comprendre un
programme. Toutefois, la lisibilité est plus qu'un simple style de programmation. De
nombreux facteurs contribuent à la lisibilité du code source tels que la vitesse de perception,
la visibilité, la vitesse de lecture, …etc. Certains de ces facteurs comprennent:
Différents styles d’indentation33
(whitespace) ;
Les lignes de commentaires ;
La décomposition34
;
Les conventions de nommage pour les objets (telles que les variables, les classes, les
méthodes, etc.).
33
Le style d'indentation décrit les différentes manières que les programmeurs utilisent pour faire ressortir un bloc de code.
L’indentation se définit par la manière d'arranger les blocs de code, mais surtout par le nombre d'espaces utilisés à chaque
niveau. Par exemple, en langage C, on retrouve les styles K&R, Whitesmiths et le style GNU. 34
La décomposition en informatique (factoring) se réfère au processus par lequel un problème ou un système complexe est
décomposé en parties qui sont plus faciles à concevoir, à comprendre, à programmer, et à maintenir. Par exemple, la
décomposition orientée objets, décompose de gros systèmes en petites unités faciles à comprendre et à maintenir (les classes).
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
152
1 – Pourcentage des lignes de commentaires/ Comments Percentage (CP)
Les commentaires sont le plus souvent utilisés pour expliquer le code. On se sert aussi des
commentaires pour masquer du code, mais aussi pour préciser des contraintes ou des
propriétés, notamment des préconditions, des postcondictions et des invariants comme cela se
fait dans la programmation par contrat (le déroulement des traitements est régi par des règles,
appelées des assertions. Cas du langage Eiffel). Le pourcentage des lignes de commentaires
%CP se calcule par la formule suivante :
Le Software Assurance Technology Center SATC de la NASA ont suggéré la valeur
d’environ 30% comme valeur effective pour %CP.
2 – Fog Index35
Est une mesure de la longueur moyenne des mots et des phrases dans les documents. Plus la
valeur de cet indice est grande, plus le texte est difficile à lire et à comprendre (non utilisée
dans MM6P_ISO9126).
5.3.2.5 La duplication du code source
Différents chercheurs rapportent que la quantité du code dupliqué (ou code cloné) dans les
systèmes logiciels varie de 6,4% - 7,5% à 13% - 20% [Roy & Cordy, 07]. Le code dupliqué
peut se produire en raison de:
la programmation copier-coller, dans laquelle une section de code est copiée, "car
elle fonctionne". Dans la plupart des cas, cette opération implique de légères
modifications dans le code cloné comme renommer des variables ou insérer/supprimer
des fragments de code ;
35 The Gunning Fog Index Readability Formula, or simply called Fog Index, is attributed to American textbook publisher,
Robert Gunning, who was a graduate from Ohio State University. Gunning observed that most high school graduates were
unable to read. Much of this reading problem was a writing problem. His opinion was that newspapers and business
documents were full of “fog” and unnecessary complexity. In 1952, Gunning published a book, The Technique of Clear
Writing and created an easy-to-use Fog Index.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
153
La fonctionnalité très similaire à celle qui se trouve dans un autre programme
existant. En effet, les développeurs systématiquement copient du code existant qui a
résolu un problème similaire à celui qu’ils tentent de résoudre actuellement ;
Le plagiat, où le code est simplement copié sans autorisation ou attribution.
La duplication de code peut être un inconvénient important, conduisant à une mauvaise
conception et une augmentation de la probabilité d'occurrence de propagation de bugs. En
conséquence, elle peut augmenter considérablement les coûts de maintenance (par exemple,
les bugs dans le code original doivent être fixés dans tous les codes dupliqués). Il est ainsi
nécessaire de parvenir à la détection des parties de code dupliquées. Si la détection de clones
exacts est relativement aisée pour une représentation donnée du code, la recherche de
correspondances approchées nécessite l’utilisation d’algorithmes36
de complexité plus
importante ou alors l’emploi de certaines heuristiques [Chilowicz, 10] .
Les techniques de détection du code dupliqué peuvent être classées selon plusieurs critères.
Le code peut être considéré comme similaire basé sur des critères syntaxiques (en effectuant
des comparaisons de textes basées, par exemple, sur les occurrences de lignes de code
identiques) ou au niveau sémantique (du point de vue des effets d'exécution).
Une technique permettant d'éviter la duplication de code dans le cas des clones exactes est la
factorisation des clones, elle consiste à rassembler les suites d'instructions identiques
dispersées dans un programme en une fonction, pour améliorer la lisibilité du code et en
faciliter la correction et les modifications ultérieures. Cette approche n’est pas possible dans
le cas des clones rapprochés car nécessitant un degré de compréhension sémantique.
36 - Duplicate code detection using anti-unification by Peter Bulychev, Marius Minea.SYRCOSE, 2008 (paper describes
an algorithm for finding software clones. It is conceptually independent of the source language of the analyzed programs);
- Archeology of code duplication: Recovering duplication chains from small duplication fragments by Richard Wettel,
Radu Marinescu, copyright 2005 (paper describes an approach that provides support for proper refactoring “language
independent”) .
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
154
1 – Le taux du code dupliqué/ Duplicate code percentage
Pour évaluer un système logiciel en matière du code dupliqué, nous définirons la table
suivante, d’après les résultats de l’étude “A Survey on Software Clone Detection Research,
2007” [Roy & Cordy, 07].
Ainsi, un système bien conçu ne devrait pas avoir plus de 6.4% du code dupliqué. Lorsque le
code dupliqué dépasse 20%, le code source est hors contrôle.
5.3.2.6 Les tests unitaires du code source
En programmation, les tests unitaires sont de petits programmes écrits par les
développeurs pour automatiser le test de leur code source. Ces tests unitaires sont appliqués
sur des unités individuelles, indépendamment du reste du programme, afin de s'assurer
qu'elles répondent aux spécifications fonctionnelles et qu’elles fonctionnent correctement.
L’unité est la plus petite partie d'un système logiciel qui peut être testée. En programmation
procédurale, une unité peut être un module complet, mais le plus communément une fonction
individuelle ou une procédure. Dans la programmation orientée objet une unité est souvent
une interface entière, comme une classe, mais pourrait être une méthode individuelle.
Dans les applications non critiques, l'écriture de tests unitaires a longtemps été considérée
comme une tâche secondaire. Cependant, la méthode Extreme programming (XP) a remis les
tests unitaires au centre de l'activité de programmation. La méthode XP préconise d'écrire les
tests en même temps, ou même avant la fonction à tester (Test Driven Development). Des
Framework de tests unitaires, qui peuvent être intégrés dans des environnements de
développement, sont disponibles pour les principaux langages de programmation. Les
exemples sont CUnit pour les tests unitaires du code C, CPPUnit pour C++ et NUnit pour les
langages .Net tel que C#. La présence extensive de tests unitaires dans le code a un impact
positif sur la maintenabilité. Ils augmentent la facilité de tests, la stabilité et la facilité
d’analyse.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
155
1 – Le taux de couverture du code par les tests unitaires/ Unit tests coverage
Le taux de couverture du code par des tests unitaires peut être mesuré avec des outils dédiés
tel que CovregeMeter pour les langages C/C++. Ces outils n’effectuent pas d’analyse
statique de code source, mais plutôt une analyse dynamique qui implique l’exécutions des
tests. Pour la mesure de la couverture des tests unitaires, nous reprenons ici la table proposée
par le Software Improvement Group [Ilja et al, 07].
Ainsi, une excellente couverture de tests unitaires couvre entre 95 et 100% de l'ensemble du
code source du système logiciel. Une couverture inférieure à 60% est considérée comme
pauvre.
5.4 Etudes de cas : Mesure et interprétation
(Analyses de produits logiciels selon le modèle MM6P_ISO9126)
Plusieurs outils commerciaux et open source de mesure de logiciels sont disponibles,
mais la majorité des outils d'analyse statique de code source se concentrent principalement sur
un langage de programmation spécifique. L’implémentation des métriques logicielles se
diffère d'un outil à l'autre [Munson, 03], il faut donc éviter d’utiliser plusieurs outils pour le
calcul de la même métrique. Pour l’évaluation des produits logiciels donnés dans le tableau
14, un outil d'analyse qui supporte les langages C, C++, C# et Delphi est nécessaire. Or, le
langage Delphi est très rarement supporté par ces outils (freeware ou shareware). Nous
sommes donc limités dans le choix de l’outil pour le calcul des métriques choisies dans le
modèle de maintenabilité proposé. SourceMonitor [Version 3.1.5.190, Sept 2011] de
Campwood Softwanre, nous paraît le choix unique pour le calcul de la plupart des métriques
proposées. Les métriques de couverture des tests unitaires et du code dupliqué ne seront pas
calculées faute d’absence d’outils de mesure.
Ci-après, nous allons résumer les résultats d’évaluation pour les produits logiciels du
tableau 14. Les résultats détaillés sont sauvés dans des fichiers au format Excel (.xls) sur le
CD accompagnant le travail.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
156
5.4.1. Projet : SDCC – Small Device C Compiler ;
Fichier Excel (résultats détaillés de l’évaluation) : SDCC project.xls ;
Version du projet : 3.0.0 ;
Date de réalisation : 03/06/2011 ;
Langage de développement : C.
Nombre de fichiers (#Files) = 1748 ;
Nombre de fonctions (#Functions) = 6732 ;
Indice de conversion (Ave Stats ↔ FP) = 148.
Projet relativement important (taille ≈ 630 KLOC), bien commenté (%CP = 19.3%), mais la
taille moyenne de ses fonctions (#stat = 29.7) complique son analyse. La complexité du projet
en termes de CC est (-) ce qui rend difficile d’opérer des modifications sur le système. Cette
complexité couplée à la taille des fonctions complique la vérification et le test du système.
Pour améliorer la maintenabilité, il faut refactoriser37
les fonctions ayant des valeurs de CC
ou de FAN OUT supérieures. Ce qui devrait revoir la taille moyenne des fonctions à la baisse.
37 La refactorisation (anglicisme venant de refactoring) est une opération de maintenance du code informatique. Elle
consiste à retravailler le code source non pas pour ajouter une fonctionnalité supplémentaire au logiciel mais pour améliorer
sa lisibilité, simplifier sa maintenance, ou changer sa généricité (on parle aussi de remaniement).
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
157
5.4.2. Projet : eMule ;
Fichier Excel (résultats détaillés de l’évaluation) : eMule project.xls ;
Version du projet : 0.50a ;
Date de réalisation : 07/04/2010 ;
Langage de développement : C++.
Nombre de fichiers (#Files) = 717 ;
Nombre de fonctions (#Functions) = 839 ;
Nombre de méthodes (#Methods) = 8136 ;
Indice de conversion (Ave Stats ↔ FP) = 59.
Projet relativement facile à analyser (taille ≈ 250 KLOC, longueur des méthodes/fonctions
#stat = 12.61, plus au moins commenté %CP = 15.3%). Il faut juste refactoriser les méthodes
ou fonctions ayant des valeurs de CC ou FAN OUT supérieures ce qui devrait améliorer sa
maintenabilité en termes des sous-caractéristiques facilité de modification et facilité de tests.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
158
5.4.3. Projet : 7 Zip ;
Version du projet : 9.22 Beta ;
Date de réalisation : 18/04/2011 ;
Langages de développement : C & C++.
7 Zip (partie écrite en langage C);
Fichier Excel (résultats détaillés de l’évaluation) : 7 Zip project (C part).xls ;
Nombre de fichiers (#Files) = 499 ;
Nombre de fonctions (#Functions) = 2382 ;
Indice de conversion (Ave Stats ↔ FP) = 148.
7 Zip (partie écrite en langage C++);
Fichier Excel (résultats détaillés de l’évaluation) : 7 Zip project (C++ part).xls ;
Nombre de fichiers (#Files) = 859 ;
Nombre de fonctions (#Functions) = 1944 ;
Nombre de méthodes (#Methods) = 5448 ;
Indice de conversion (Ave Stats ↔ FP) = 59.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
159
Le projet 7 Zip dans sa globalité (les deux parties) est évalué selon le modèle
MM6P_ISO9126 comme suit :
Projet de taille moyenne (taille ≈ 280 KLOC), mal commenté (%CP ≈ 6%) ce qui devrait
compliqué un peu son analyse vu que le projet est noté (+) en termes de taille de ses méthodes
ou fonctions. Il est donc impératif d’ajouter des lignes de commentaires pour bien documenter
le code. D’autres parts, le projet est noté (++) en termes de NBD et FAN OUT. Il suffit de
refactoriser les méthodes ou fonctions ayant des valeurs de CC supérieures. Ce qui devrait
faciliter les modifications au niveau du code.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
160
5.4.4. Projet : NStudio ;
Fichier Excel (résultats détaillés de l’évaluation) : NStudio project.xls ;
Version du projet : 0.1 Beta ;
Date de réalisation : 17/09/2007 ;
Langage de développement : C#.
Nombre de fichiers (#Files) = 82 ;
Nombre de méthodes (#Methods) = 1767 ;
Indice de conversion (Ave Stats ↔ FP) = 58.
Projet de petite taille (30 KLOC) facile à analyser (5.53 stat/méthode, 4.6% de commentaires
et 15.7% de lignes de documentation), de lui porter des changements ou modification (3% de
méthodes ayant des valeurs de CC>10, seulement 02 méthodes ayant des blocs de
profondeurs > 9 et 0.28% de méthodes ayant des valeurs de FAN OUT supérieures à 50) et
facile de tester. Ce projet est facilement maintenable mais cela est dû en grande partie à sa
taille relativement petite.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
161
5.4.5. Projet : WDents ;
Fichier Excel (résultats détaillés de l’évaluation) : WDents project.xls ;
Version du projet : 2.4 ;
Date de réalisation : 17/07/2009 ;
Langage de développement : Delphi.
Nombre de fichiers (#Files) = 1020 ;
Nombre de subroutines (#Subroutines) = 3232 ;
Nombre de méthodes (#Methods) = 17977 ;
Indice de conversion (Ave Stats ↔ FP) = 29.
Malgré que le projet est noté (+) en termes de constructions par méthode (#stat = 8.6) et
subroutine (#stat = 13), il reste difficile à analyser compte tenu de sa taille (400 KLOC) et le
taux des lignes de commentaires (%CP = 10.7%). D’autres parts, la complexité du projet en
termes de CC (-) a un impact négatif sur les sous-caractéristiques facilité de modifications et
facilité de tests. Un remaniement du code au niveau des méthodes et subroutines ayant des
valeurs de CC élevées et une meilleure documentation du code source devront augmenter
considérablement la maintenabilité du système.
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
162
5.4.6. Projet : LGL_Etat_Civil ;
Fichier Excel (résultats détaillés de l’évaluation) : LGL_Etat_Civil project.xls ;
Version du projet : 3.0 ;
Date de réalisation : 2009 ;
Langage de développement : Delphi.
Nombre de fichiers (#Files) = 157 ;
Nombre de subroutines (#Subroutines) = 55 ;
Nombre de méthodes (#Methods) = 2791 ;
Indice de conversion (Ave Stats ↔ FP) = 29.
Le taux faible de lignes de commentaires dans le code (%CP moins de 5%) et le nombre de
constructions de programmation particulièrement élevé par subroutine (Ave stats/subroutine =
144) complique énormément la tâche d’analyse du système et cela malgré le nombre modéré
de constructions par méthode (Ave stats/method = 10). Le projet est noté (-) en termes des
sous-caractéristiques facilité de modifications et facilité de tests. Cela est dû au nombre
important de méthodes ou subroutines ayant des blocs de code dont NBD est supérieur à 50
La maintenabilité du logiciel (Le modèle MM6P_ISO9126): Analyse & Evaluation
163
(plus de 12%) auquel il faut ajouter les méthodes (subroutines incluses) ayant des valeurs de
CC supérieures (environ 5%). Une refactorisation du code au niveau des méthodes et
subroutines ayant des valeurs de CC ou NBD élevées et une meilleure documentation du code
source devront augmenter significativement la maintenabilité du système.
Conclusion
La norme ISO 9126 est un bon cadre de référence pour l’évaluation de la qualité du
produit logiciel, mais ne propose aucune méthode applicable dans la pratique pour évaluer la
maintenabilité d’un software par observation directe de son code source. Les mesures
énumérées par les rapports techniques accompagnement la norme peuvent, au mieux, établir
le degré de maintenabilité d'un système à partir d’observations basées sur l'interaction entre le
produit et son environnement. D’autre part, la littérature sur les métriques logicielles, propose
de nombreux moyens de mesurer le logiciel mais sans fournir de traçabilité. En particulier,
l'index de maintenabilité souffre de graves limitations concernant l'analyse des causes, la
facilité de calcul, l'indépendance du langage, la compréhension, et le contrôle.
Le modèle proposé ne souffre pas de problèmes tels que ceux identifiés pour l'index de
maintenabilité. Les métriques utilisées dans le modèle MM6P_ISO9126 sont sélectionnées
pour correspondre le mieux possible aux exigences formulées dans la section 5.3. Elles sont
faciles à calculer et à expliquer et presque complètement indépendantes du langage de
programmation utilisé, ce qui garantit leur applicabilité aux systèmes qui utilisent des
technologies différentes (cas du projet 7 Zip développé avec les langages C et C++). La
compréhension des mesures et la traçabilité du processus d’évaluation permettent l'analyse
des causes des problèmes de maintenabilité en donnant des indices clairs concernant les
relations de causalité entre les propriétés au niveau code et la qualité au niveau du système
(fig. 5.1).
Conclusion
165
Conclusion.
Nous venons de passer en revue, dans ce mémoire, le processus d’évaluation de la
qualité du logiciel de la norme ISO 14598. L'application de ce modèle d'analyse (qui
correspond à l'évaluation et la prise de décision sur la base de critères de décision dans la
norme ISO 9126) est généralement effectuée en quatre étapes (quatre processus de
quantification): d'abord établir les exigences d'évaluation, puis spécifier, concevoir et enfin
exécuter l'évaluation. Ensuite nous avons décrit les problèmes liés au processus d’évaluation
qui ne sont pas abordés avec assez de détails par la norme tels que les objectifs d’évaluation
qui ne sont pas suffisamment formulés ou l’absence de relations implicites entre les activités
qui doivent être menées pendant l’évaluation. D’autres processus d’évaluation (comme par ex,
W-process), basées sur les normes ISO 9126/ ISO 14598, utilisant la méthode GQM et
d’autres méthodes pour pallier les insuffisances constatées dans les normes ont été présentés.
A la lumière de cette revue, nous avons essayé d’évaluer la qualité du produit logiciel
en termes de maintenabilité par observation directe de son code source. Nous avons ainsi
proposé le modèle MM6P_ISO9126 comme modèle alternatif pour évaluer la maintenabilité
d’un software, en se basant sur les propriétés du code source suivantes : la taille du
programme, la longueur de la méthode/fonction, la complexité du code, la lisibilité du code,
la duplication du code, et les tests unitaires du code source. Une éventuelle implémentation
de ce modèle est tout a fait envisageable et cela en dépit de la contrainte «Les mesures doivent
être indépendantes de la technologie, le mieux possible, afin qu’elles puissent être appliquées
aux systèmes conçus autour d’architectures différentes utilisant différents langages de
programmation» que nous avons imposée lors de la construction du modèle
MM6P_ISO9126.
Bibliographie
167
Références bibliographiques [Abreu, 95] F. B. Abreu, “The MOOD metrics set,” in ECOOP'95, 1995.
[Abounader & Lamb, 97] J. R. Abounader and D. A. Lamb, “A data model for object oriented design metrics,”
Department of Computing and Information Science Queen's University, Kingston, Ontario, Canada, Tech. Rep.
ISSN-0836-0227-1997-409, 1997.
[Aggarwal et al, 02] K. Aggarwal, Y. Singh, and J. K. Chhabra, “An integrated measure of software
maintainability,” Reliability and Maintainability Symposium, pp. 235–241, Sep. 2002.
[Alfred, 00] Alfred Strohmeier, Cycle de vie du logiciel, Laboratoire de Génie Logiciel - Département
d’Informatique, Ecole Polytechnique Fédérale de Lausanne, Mars 2000.
[Al-Qutaish & Abran, 05] R. E. Al-Qutaish and A. Abran, “An analysis of the design and definitions of
Halstead?s metrics,” in 15th Int. Workshop on Software Measurement (IWSM’2005). Shaker-Verlag, 2005, pp.
337–352.
[April & Laporte, 11] Alain April et Claude Laporte, Assurance qualité logicielle 1: concepts de base,
Lavoisier, 2011, (ISBN 9782746231474), page 387.
[Bansiya & Davis, 97] J. Bansiya and C. Davis. "Automated Metrics and Ob ject-Oriented Development" ,
Dr.Dobb's Journal, pp. 42-48, Decenaber 1997.
[Basili, 81] Basili V.R., Evaluating Software Development Characteristics: Assessment of Software Measures
in The Software Engineering Laboratory, Proceedings of Sixth Annual Software Engineering Workshop, SEL-
81-013, 1981.
[Basili et al. 94] V.R. Basili, G. Caldiera et H.D. Rombach “The Goal Question Metric Approach”,
Encyclopedia of Software Engineering, Wiley 1994
[Basili, Briand & Melo, 96] V.R. Basili, L. Briand, and W.L. Melo. "A Validation of Object-Oriented Design
Metrics as Quality Indicators", IEEE Bansactions on SoJtware Engineering, Vol.22, No.10, pp. 751-761,
October 1996.
[Basili & Weiss, 84] Basili, V. and Weiss, D. 1984. “A methodology for collecting valid software engineering
data”, IEEE Transactions on Software Engineering 10: 728–738.
[Bauer, 99] M. Bauer, “Analyzing software systems using combinations of metrics,” in Proceedings of the
ECOOP Workshop on Experiences in Object-Oriented Re-Engineering, 1999.
[Boehm, Clark, et al, 00] B.W.Boehm, Clark, et al., Software Cost Estimation with Cocomo II with Cdrom.
Upper Saddle River, NJ, USA: Prentice Hall PTR, 2000.
[Boegh et al, 99] Boegh, J., Depanfilis, S., Kitchenham, B. and Pasquini, A. 1999. “A method for software
quality, planning, control and evaluation”, IEEE Software 16: 69–77.
[Bouttery, 07] Jean-Yves Bouttery, Test et Validation du logiciel / OUTILS D’ANALYSE STATIQUE, Mai
2007.
[Briand, El Emam & Morasca, 96] Lionel Briand, Khaled El Emam,Sandro Morasca, “On the application of
measurement theory in software engineering,” International Software Engineering Research Network, Tech.
Rep. #ISERN-95-04, 1996.
[Briand et al, 99] Briand, L., Wüst, J. and Lounis, H. 1999. Using coupling measurement for impact analysis in
OO systems, Proceedings of International Conference on Software Maintenance (ISCM), pp. 475–482.
[Budd, 91] Budd T. Object Oriented Programming. Addison-Wesley, Reading, Massachusetts, 1991.
Bibliographie
168
[Card & Glass, 90] Card D.N., Glass R.L., Measuring Software Design Quality, Prentice Hall, 1990.
[Cartwright & Shepperd, 00] Cartwright, M. and Shepperd, M. 2000. An empirical investigation of an object-
oriented software system, IEEE Transactions on Software Engineering 26: 786–796.
[Chidamber & Kemerer, 91] S.R. Chidamber and C.F. Kemerer. "Towards a Metrics Suite for Object-
Oriented Design", OOPSLA '91, Phoenix, Aeizona, USA, pp. 1 97-211, 1991.
[Chidamber & Kemerer, 94] S. R. Chidamber and C. F. Kemerer. "A Metncs Suite for Object-Oriented
Designn”, IEEE Transactions on Software Engineering, Vol.20, No.6, pp. 4 76-493 June 1994.
[Chilowicz, 10] Michel CHILOWICZ, “Recherche de similarité dans du code source,” Thèse de doctorat de
l’Université Paris-Est, Novembre 2010
[Cherniavsky & Smith, 91] J.C. Cherniavsky and C.H. Smith. "On Weyuker's Axioms for Software Complexity
Measures" , IEEE Bansactions on Software Engineering, Vol. 1 7, No. 6, pp. 636- 638, June 1991.
[Churcher & Shepperd, 95] N.I. Churcher and M.J. Shepperd. Comments on 'A Metrics Suite for Object
Oriented Design' " , IEEE Pansactions on Software Engineering, Vol.21, No.3, pp. 263-265, March 1995.
[Coleman et al, 94] D. M. Coleman, D. Ash, B. Lowther, and P. W. Oman, “Using metrics to evaluate software
system maintainability.” IEEE Computer, vol. 27, no. 8, pp. 44–49, 1994.
[Constantine & Yourdon, 79] Constantine and E. Yourdon. "Structured Design". Prentice-Hall, Englewood
Cliffs, NJ, 1979.
[Conte, Dunsmore & Shen, 86] Conte, S.D., Dunsmore, H.D. and Shen, V.Y., Software Engineering Metrics
and Models, Benjamin-Cummings, Menlo Park, CA, 1986.
[COSMIC FFP Measurement Manual, 01] Abran.A, Desharnais, J.M, Oligny, St-Pierre D & Symons (2001).
COSMIC FFP Measurement Manual.
[Crosby, 79] Crosby, P. B., Quality Is Free: The Art of Making Quality Certain, New York: McGraw-Hill,
1979.
[DE TRAN, 05] DE TRAN-CAO, ‘Mesure de la complexité fonctionnelle des logiciels,’ Thèse de Doctorat en
informatique cognitive, Université du Québec à MONTRÉAL, Juin 2005.
[Deimel Jr, 85] L. E. Deimel Jr., “The uses of program reading,” SIGCSE Bull., vol. 17, no. 2, pp. 5–14, 1985.
[Doren, 97] E. V. Doren, “Halstead Complexity Measures” January 1997.
[Dromey, 96] Dromey, G. 1996. “Cornering the Chimera”, IEEE Software 13: 33–43.
[Dugerdil, 05] Philippe Dugerdil, Impact des décisions informatiques: Introduction à l'informatique pour
décideur non informaticien, PPUR presses polytechniques - 2005, (ISBN 9782880746100), page 201.
[Ebert et al, 05] Christof Ebert, Reiner Dumke, Manfred Bundschuh & Andreas Schmietendorf. “Best
Practicesin Software Measurement” - Springer 2005.
[Ebert & Morschel, 97] C. Ebert and 1. Morschel. "Metrics for Quality Analysis and Improvement of Object-
Oriented Software”, Information and Software Technology 39 (1997) pp. 497-509, 1997.
[Elshoff & Marcotty, 82] James L. Elshoff et Michael Marcotty, "Amélioration de la lisibilité du programme
informatique pour faciliter la modification," Communications of the ACM, V.25 n.8, P.512-521, août 1982.
[Emam, 02] K. E. Emam, S. Benlarbi, N. Goel, W. Melo, H. Lounis and S. N. Rai, “The Optimal Class Size for
Object-Oriented Software,” IEEE Trans. Softw. Eng., vol. 28, pp. 494-509, 2002.
Bibliographie
169
[Etzkorn, Bansiya & Davis, 98] L. Etzkorn, J. Bansiya, and C. Davis. "Design and Code Complexity Met&s for
OO Classes", Accepted for publication in Journal of Object-Oriented Progmmming, January 1998.
[Evangelisti, 83] Evangelisti W.M., ‘Software Complexity Metric Sensitive to Program Structured Rules,’ The
Journal of System and Software, 1983.
[Fenton, 94] N. Fenton, “Software Measurement: A Necessary Scientific Basis,” IEEE Trans. Software Eng.,
vol. 20, pp. 199-206, 1994.
[Fenton & Neil, 99J] N. E. Fenton and M. Neil, “Software Metrics: Successes, Failures and New Directions”
Journal of Systems and Software, vol. 47, pp. 149-157, 1999.
[Fenton & Pfleeger, 97] N. E. Fenton and S. L. Pfleeger, Software Metrics: A Rigorous & Practical Approach. Boston 1997.
[Florac, Park & et al, 97] W. A. Florac, R. E. Park and et al., “Practical software measurement: Measuring for
process management and improvement,” Tech. Rep. CMU/SEI-97-HB-003, 1997.
[Garvin, 88] Garvin, D. Managing Quality. New York: Free Press, 1988.
[Gilb, 77] Gilb T., Software Metrics, Winthrop Publishers, Inc., Cambridge, Massachusetts, 1977.
[Glass, 96] R. L. Glass, “The relationship between theory and practice in software engineering,” Commun
ACM, vol. 39, pp. 11-13, 1996.
[Gowda & Winslow, 94] R.G. Gowda and L.E. Winslow. "An Approach for Deriving Object-Oriented
Metrics",Proceedings of the IEEE 1994 National Aerospace and Electronics Conference NACON, V01.2, pp.
897-904, 1994.
[Grady & Caswell, 87] R. B. Grady and D. L. Caswell, Software Metrics: Establishing a Company-Wide
Program. Upper Saddle River, NJ, USA: Prentice-Hall, Inc, 1987.
[Graham, 96] I. Graham. "Making Progress in Metrics", Object Magazine, Vol. 6, Iss.8, pp. 68-73, Octo ber
1996.
[Guaspari, 85] Guaspari, J., I Know It When I See It: A Modern Fable About Quality, New York: American
Management Association, 1985.
[Guaspari, 88] Guaspari, J., The Customer Connection: Quality for the Rest of Us, New York: American
Management Association, 1988.
[Guéhéneuc, 06] Yann-Gaël Guéhéneuc - IFT 3903 - Qualité du logiciel & Metriques, 2006. Ptidej Team –
OO Programs Quality Evaluation and Enhancement using Patterns, University of Montreal
[Halstead, 77] Halstead M.H., “Element of Software Science”, New York, Elsevier North-Holland, 1977.
[Hansen, 78] Hansen W., Measurement of Program Complexity by Pair (Cyclomatic Number, Operator Count),
ACM SIGPLAN notices, Vol. 13, No. 3, pp. 29-33, Mars 1978.
[Harry & Lawson, 92] Harry, M. J., and J. R. Lawson, Six Sigma Producibility Analysis and Process
Characterization, Reading, Mass.: Addison-Wesley, 1992.
[Hausen & Welzel, 93] Hausen, H. and Welzel, D. 1993. “Guides to software evaluation”, Arbeitspapiere der
GMD 746.
[Henderson, 96] B. Henderson-Sellers, Object-Oriented Metrics: Measures of Complexity. Upper Saddle River,
N.J.: Prentice Hall, pp. 234, 1996.
Bibliographie
170
[Henry & Kafura, 81] Henry S.M., Kafura D.G., Software Structure Metric Based on Information Flow, IEEE
Transactions on Software Engineering, Vol.7, No. 5, pp. 510-518, September 1981.
[Hitz & Montazeri, 95] M. Hitz and B. Montazeri. "Measuring Product Attributes of Object-Oriented
Systems",Proceedings of the 5th European Software Engineering Conference, Barcelona, Spain, pp. 124-136,
September 1995.
[IEEE 1061, 92] IEEE Std. 1061, Software Quality Metrics Methodology, 1992.
[IEEE Std Broad, 89] IEEE, Standard Dictionary of Measures to Produce Reliable Software, The Institute of
Electrical and Electronics Engineers, IEEE Standard Board, 1989.
[IEEE, 90] IEEE Computer Society, “IEEE Glossary of Software Engineering Terminology,” 1990.
[IFPUG, 94] IFPUG. (1994). Function Point Counting Practices Manual. Westerville, Ohio: International
Function Point Users Group (IFPUG), Version 4.0.
[IFPUG, 99] IFPUG. (1999). Function Point Counting Practices Manual. Westerville, Ohio: International
Function Point Users Group (IFPUG), Version 4.1.
[Ilja et al, 07] Ilja Heitlager, Tobias Kuipers and Joost Visser – “A Practical Model for Measuring
Maintainability” - IEEE Computer 2007, ISBN: 0-7695-2948-8
[Jackson & Rinard, 00] Daniel Jackson et Martin Rinard. Software analysis : a roadmap. Dans ICSE ’00
:Proceedings of the Conference on The Future of Software Engineering, pages 133– 145, New York, NY, USA,
2000. ACM Press. ISBN 1-58113-253-0.
[Jones, 92] Jones, C., "Critical Problems in Software Measurement," Version 1.0, Burlington, Mass.: Software
Productivity Research (SPR), August 1992.
[Jones, 94] C. Jones, “Software metrics: Good, bad and missing,” Computer, vol. 27, no. 9, pp. 98–100, 1994.
[Jones, 97] C. Jones, Applied Software Measurement: Assuring Productivity and Quality. 2nd ed., New York:
McGraw-Hill, pp. 618, 1997.
[Jones, 86] Jones.C., Programmer Productivity. McGraw-Hill, New York, 1986.
[Jones, 08] Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality,
3rd
Edition, McGraw-Hill 2008.
[Juran & Gryna, 70] Juran, J. M., and F. M. Gryna, Jr., Quality Planning and Analysis: From Product
Development Through Use, New York: McGraw-Hill, 1970.
[Kazman et al, 98] Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lipson, H. and Carrière, J. 1998. “The
architecture tradeoff analysis method”,Proceedings of the 4th International Conference on Engineering of
Complex Computer Systems, pp. 68–78.
[Khan, 02] S. H. Khan, Metrics and Models in Software Quality Engineering. Addison-Wesley Professional,
2002.
[Kim et al , 94] E.M. Kim, O.B. Chang, S. Kusumoto, and T. Kikuno. "Analysis of Metrics for Object-Orient ed
Program Complexity", Proceedings of COMPSA C '94, pp. 201 -207, 1994.
[Kim et al , 96] E.M. Kim, S. Kusumoto, T. Kikuno, and O.B. Chang. "Heuristics for Cornputhg Attribute
Values of Cf+ Program Complexity Metrics", 1996 IEEE 20th Annval International Compter Software and
Applications Conference, Seoul, Korea, pp. 104-1 09, August 1996.
Bibliographie
171
[Kitchenham, Pfleeger & Fenton, 95] B. Kitchenham, S.L. Pfleeger, and N. Fenton. "Towards a F'ramework
for Softwme Measurement Validation", IEEE Transactions on Software Engineering, Vol. 21, No. 12, pp. 929-
5744, Decem ber 1995.
[Klemola, 00] T. Klemola, "A cognitive model for complexity metrics," in 4th International ECOOP Workshop
on Quantitative Approaches in Object-Oriented Software Engineering, 2000.
[Koshgoftaar & Allen, 98] Koshgoftaar, T.M. and Allen, E.B. 1998. Predicting the order of fault-prone modules
in legacy software, IEEE Transactions on Software Engineering 24: 344–353.
[Kuipers &Visser, 07] T. Kuipers and J. Visser, “Maintainability index revisited,” in 11th European Conference
on Software Maintenance and Reengineering, 2007.
[Laird & Brennan, 06] L. M. Laird and M. C. Brennan, Software Measurement and Estimation: A Practical
Approach (Quantitative Software Engineering Series). Wiley-IEEE Computer Society Pr, 2006.
[Langelier, 06] Guillaume Langelier, « Visualisation de la qualité des logiciels de grandes tailles », Mémoire
présenté à la Faculté des études supérieures en vue de l’obtention du grade de Maître ès sciences (M.Sc.) en
informatique 2006 - Université de Montréal.
[Laudrel, 08] Sévrine Laudrel, Référentiels dans l’ingénierie logicielle – version 3, Mars 2008.
[Linda, Laird & Brennan, 06] Linda M. Laird, M. Carol Brennan. 2006. Software measurement and
estimation: a pratical approach. John Wi1ey & Sons,.; Chapter 5, pp. 55-78; Chapter 10, pp. 181-195
[Lorenz, 93] Lorenz, M., “Object-Oriented Software Development: A Practical Guide”, Prentice Hall,
Englewood Cliffs, NJ, 1993.
[Martin, 95] R. Martin, "OO Design Quality Metrics", Report on Object Anaiysis and Design 2,
Novernber/December 1995.
[Marylène & Medard, 02] Marylène Micheloud et Medard Rieder, Programmation orientée objets en C++:
Une approche évolutive, PPUR presses polytechniques, 2002, (ISBN 9782880745042), page 259.
[Mayrand & Coallier, 96] Mayrand, J. and Coallier, F. 1996. “System acquisition based on software product
assessment”,Proceedings of International Conference on Software Engineering (ICSE), pp. 210–219.
[McAndrews, 93] D. R. McAndrews, “Establishing a software measurement process,” Software Engineering
Institute, Tech. Rep. CMU/SEI-93-TR-16, 1993.
[McCabe, 76] T. J. McCabe, “A Complexity Measure,” IEEE Transactions on Software Engineering, vol. 2, pp.
308-320, 1976.
[McConnell, 04] S. McConnell, Code Complete, Second Edition. Redmond, WA, USA: Microsoft Press, 2004.
[Milankovic & Georgiadou, 97] M. Milankovic-Atkinson and E. Georgiadou. "Metrics for Reuse of Ob ject-
Oriented Software”, Software Quality Management IV. Improving Quality, pp. 363-374, 1997.
[MK. Donyaee, 01] Mohammad K. Donyaee,Towards an Integrated Mode1 for Specifying and Measuring
Quality in Use, A Thesis in Computer science - Concordia University Montreal, Quebec, Canada - March 2001.
[Munson, 03] J. C. Munson, “Software Engineering Measurement,” Boca Raton, FL: Auerbach Publications,
2003.
[Myers, 77] Myers G.J., An Extension to the Cyclomatic Measure of Program Complexity, ACM SIGPLAN
notices, Vol.12, No.10, pp. 61-64, October 1977.
[Oman, 91] P. Oman, “HP-MAS: A tool for software maintainability, software engineering,” Moscow, ID: Test
Laboratory, University of Idaho, Tech. Rep. (#91-08-TR), 1991.
Bibliographie
172
[Oman & Hagemeister, 94] P. W. Oman and J. R. Hagemeister, “Construction and testing of polynomials
predicting software maintainability.” Journal of Systems and Software, vol. 24, no. 3, pp. 251–266, 1994.
[Pandian, 03] C. R. Pandian, Software Metrics: A Guide to Planning, Analysis, and Application. Boca Raton,
FL, USA: Auerbach Publishers, 2003.
[Park, Goethert & Florac, 96] R. E. Park, W. B. Goethert,W.A.Florac, “Goal-Driven Software Measurement –
A Guidebook” 1996.
[Perrin, 01] Conception entre sciences et art : Regards multiples sur la conception - Broché (juin 2001) de
Collectif et Jacques Perrin
[Pfleeger, 89] Pfleeger, S.L., “An Investigation of Cost and Productivity for Object-Oriented Development”,
PhD dissertation, George Mason University, Fairfax, VA, 1989. Contains a history of cost models, including
comparison and critique. Suggests new model based on average productivity, adjusted by user-created cost
factors. For object orientation, shows that a count of objects and methods as size measure yields more accurate
estimate than COCOMO or Ada-COCOMO.
[Pinet, 01] Claude Pinet, Qualité du logiciel : référentiels normatifs. Référence H4028 Techniques de
l’ingénieur (www.techniques-ingenieur.fr) – Aout 2011.
[Pivka & Potocan, 96] Pivka, M. and Potocan, V. 1996. “How can software packages certification improve
software process”, Proceedings of International Conference on Software Quality, Additional paper N. 3, 9 pages.
[Pigoski, 96] Thomas M. Pigoski. Practical Software Maintenance. Wiley Computer Publishing, 1996.
[Pohjolainen, 02] P. Pohjolainen, “Software testing Tools,” Department of Computer Science and Applied
Mathematics, University of Kuopio, 2002.
[Purao & Vaishnavi, 03] S. Purao and V. Vaishnavi, “Product metrics for object-oriented systems” ACM
Comput. Surv., vol. 35, pp. 191-221, 2003.
[Rabinovich, 05] S. Rabinovich, Measurement Errors and Uncertainties: Theory and Practice. Springer, 2005.
[Rae et al, 95] Rae, A., Hausen, H. and Robert, P. 1995. “Software Evaluation for Certification. Principles,
Practice and Legal Liability”. London, McGraw-Hill.
[Raymond, 91] D. R. Raymond, “Reading source code,” in Conference of the Centre for Advanced Studies on
Collaborative Research. IBM Press, 1991, pp. 3–16.
[Roy & Cordy, 07] C. K. Roy, J. R. Cordy. “A Survey on Software Clone Detection Research,” 2007.
[Rumbaugh et al , 91] Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. “Object-On'ented
Modeling and Design.” Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[Schneidewind, 02] Schneidewind, N. E. (2002). Body of Knowledge for Software Quality Measurement. IEEE
Transactions on Software Engineering, 35(2), 77-83.
[Sellami, 05] Asma Sellami, Processus de vérification des mesures de logiciels selon la perspective de
métrologie, Thèse de doctorat, MONTREAL 2005.
[Set Laboratories, 94] Set Laboratories, UX Metrics, 1994.
[Shepperd, 98] M. Shepperd, “A critique of cyclomatic complexity as a software metric,” Softw. Eng. J., vol. 3,
no. 2, pp. 30–36, 1988.
[Shores, 89] Shores, D., "TQC: Science, Not Witchcraft," Quality Progress, April 1989, pp. 42–45.
Bibliographie
173
[Shyam, Chidamber & Kemerer, 94] Shyam R. Chidamber, Chris F. Kemerer. 1994. A metrics suite for object
oriented design. IEEE Transactions on Software Engineering, Vol. 20; No. 6.
[Solingen & Berghout, 99] van Solingen, R. and Berghout, E. 1999. “The Goal/Question/Metric Method—A
Practical Guide for Quality Improvement of Software Development”. London, McGraw-Hill.
[Sommerville, 04] I. Sommerville, Software Engineering. 7th ed., Pearson Addison Wesley, 2004.
[Sommerville, 95] I. Sommerville. "Software Engineering". Addison-Wesley, fifth edition, 1995.
[Spinellis, 06] D. Spinellis, Code Quality: The Open Source Perspective. Addison Wesley, 2006.
[St-Pierre, 97] St-Pierre D, Maya, Abran, Desharnais, J.M & Bourque, (1997). Full Function Points : Countting
Practices Manual. Montreal (Canada) : Software Engineering Management Reserch Laboratory, UQAM.
[Stephen, 02] Stephen H. Kan, “Metrics and Models in Software Quality Engineering (2nd Edition)”, Addison-
Wesley Professional; 2 edition (September 26, 2002).
[Stevens, 46] Stevens S.S.(1946). On the Theory of Scales and Measurement. Science Journal, 103, 677-680.
[Stroud, 67] Stroud J., “The Fine Structure of Psychological Time”, Annals of New York Academy of Science,
Vol. 138, No. 2, pp. 623-631, 1967.
[Watson, 95] Watson , A.H. ( 1995 ) “ McCabe Complexity , ” Software Development Systems Management
Development, Auerbach.
[Watson & McCabe, 96] A. H. Watson and T. J. McCabe, “Structured testing: A testing methodology using the
cyclomatic complexity metric,” National Institute of Standards and Technology, 1996.
[Weyuker, 98] E. J. Weyuker. "Evaluat ing Software Complexity Measures" , IEEE Transactions on Software
Engineering, Vol. 14, No. 9, pp. 1357-1 365, Septem ber 1988.
[Williams, 94] Williams, J.D., "Metrics for object oriented projects," Proceedings of OOP-94, Munich, pp. 253-
258, 1994.
[Zuse, 91] H. Zuse, Software Complexity: Measures and Methods. New York: Walter de Gruyter, 1991.
[Zuse, 95] H. Zuse, “History of Software Measurement,” 14. September 1995.
[Zuse, 98] H. Zuse, A Framework of Software Measurement. Berlin: Walter de Gruyter, 1998.
Bibliographie
174
Références Web (sitographie) [cse.dcu.ie/essiscope] http://www.cse.dcu.ie/essiscope/sm2/atwork/scope.html accédé, le 12/02/2011.
[Fenton & Neil, 99] Norman Fenton and Martin Neil, New Directions in Software Metrics, 1999
http://www.eecs.qmul.ac.uk/~norman/papers/new_directions_metrics/HelpFileHistory_of_software_metrics_as_
a.htm accédé, le 10/01/2011.
[J.P Fournier] Professeur Jean-Pierre FOURNIER http://www.infeig.unige.ch/support/se/lect/prj/gp/node4.html
accédé, le 06/03/2011.
[journaldunet.com] http://www.journaldunet.com/solutions/0306/030624_faq_cmm.shtml accédé, le
02/02/2011.
[Lambertz] Klaus Lambertz, ‘Complexité et qualité – Comment mesurer la complexité d’un logiciel’ http://www.verifysoft.com/fr_cmtpp_mscoder.pdf accédé, le 17/03/2011.
[lemagit.fr] http://www.lemagit.fr/articldeveloppement-tests-gouvernance-qualite/4188/1/consortium-cisq-
qualite-logicielle-veut-elle-aussi-son-thermometre/ accédé, le 04/02/2011.
[Rapport TER, 09] Rapport TER 2009 : “Etude qualitative et Reengineering d'un framework”, p25 ,
Université Montpellier II.
www.lirmm.fr/~leclere/enseignements/TER/2009/Rapport/N.pdf accédé, le 20/04/2011.
[Robin.M] Robin Mueller-Bady, Fachhochschule Frankfurt am Main – “The Halstead Metric Illustration of
Measures and Problems” - University of Applied Sciences Frankfurt am Main, Germany
http://scssummary.googlecode.com/svn-history/r2/trunk/Papers/Halstead_Paper.pdf accédé, le 12/04/2011.
[standishgroup.com] http://www.standishgroup.com
The Standish Group based in Boston, Massachusetts is a market research and advisory firm specializing in
mission-critical software and electronic commerce. The group provides critical information and active solutions
to project managers, application development managers, and IT executives concerned with developing and
implementing business solutions.
[verifysoft.com] http://www.verifysoft.com
Verifysoft Technology basée à Offenbourg en Allemagne, près de la frontière française. Cette société a pour
objectif de fournir des solutions et des conseils dans le domaine des tests et d’analyse des logiciels.
[www.sig.eu]
Software Improvement Group (SIG), 30-year-old mainframe system, is a consultancy firm that provides
impartial, objective, verifiable and quantitative assessments of risks related to corporate software systems. Their
analysis software allows to measure quality, to lay bare the underlying architecture and to assess the risks related
to a system.
Annexe I
176
Annexe I : Plan d’évaluation selon l’ISO 14598
ISO/IEC FDIS 14598-2
Annex A
(normative)
Quantitative Evaluation Plan Template
A Quantitative Evaluation Plan should include the following chapters. If any chapter is not applicable it should
be so indicated.
A.1 Chapter 1 Introduction The following should be described:
the purpose of the plan
the audience of the plan
the intended use of the plan
A.2 Chapter 2 Evaluation objectives This chapter should provide a clear statement about the objective(s) of the evaluation and the intended
application of the software. This can be stated in terms of business needs. However, they should be useable for
the purpose of setting quality objectives and respective criteria, (e.g. the application of safety critical systems to
be used for automated landing of aircraft where these requirements are to be specifically stated).
A.3 Chapter 3 Applicable quality characteristics This chapter should provide statements of the quality characteristics (e.g. ISO/IEC 9126 series) which support
the objectives prescribed in A.2
The stated quality objectives may be both product and process oriented, (e.g. reliability or maintainability as
product quality characteristics; all testers have proven test harnesses and were trained in the use of test tools as
process quality targets).
A.4 Chapter 4 List of priorities This chapter should prioritize the above characteristics and should provide a supporting rationale for these
priorities. NOTE - Priorities may cover process requirements, (e.g. from the point of view of the business, training of staff may be
deemed a higher priority than the introduction of a new method or tool).
A.5 Chapter 5 Quality objectives (characteristics) This chapter should provide quantifiable quality objectives which are measurable at interim or final phases of the
project development, (e.g. number of errors per lines of code during final testing, or number of faults per total
entry which is under the control of the latest version of the configuration management system). It may state the
maximum down-time of an installed product or system. This is further explained in ISO/IEC 9126 parts 1 and 2.
A.6 Chapter 6 Schedules This chapter should provide a clear plan of objectives with milestones and stated deliverables.
A.7 Chapter 7 Definition of responsibilities This chapter should define all envisaged responsibilities associated with the implementation of the Plan. This
includes all data collection, analysis tasks, implementation of other supporting requirements, reporting, follow up
and similar requirements.
A.8 Chapter 8 Measurement categories This chapter should define the various measurements which are planned to be carried out. If both product and
process measurements are taken these should be categorised and carried out as follows:
Annexe I
177
a) Product quality measurements
Include measurements such as performance, reliability and portability. State at what stage of the development
these measurements are to be carried out, how often they are repeated, what techniques or tools are used to aid
data capture and analysis, and what actions are envisaged if there are divergences from the stated objectives.
These measurements can be final or intermediate and they can be obtained through the use of sub-characteristics.
b) Process quality measurements
Describe how process measurements are to be carried out. Include the monitoring of the effectiveness of
standards, tools usage, project management, etc. (Refer to ISO/IEC 9000 series)
These measurements can also be carried out at various phases of the project life cycle. Define and document how
process related corrective actions are to be carried out if corrective action is deemed necessary.
A.9 Chapter 9 Using and analysing data This chapter should define how data is to be analysed, what, if any, statistical methods are to be employed and
what presentation techniques are to be used.
It should make references to previously stated responsibilities, supporting tools and forms. It should also state
how the information is envisaged to be integrated into the progress tracking process or into the product
acceptance process.
A.10 Chapter 10 Reporting This chapter should define whether the analysed results are to be reported within or outside the project or
product evaluation and should also define how to resolve all outstanding items.
A.11 Chapter 11 Other requirements This chapter (or a number of chapters) can be used to include requirements not covered previously, e.g. it can
include the following information.
a) Techniques and methods employed
Provide a full description (or provide references to other material) of the techniques and methods used, (e.g.
method for sizing; development maturity assessment; inspection method for error detection; defect removal
model for predicting error rates).
The section or the referred material should be clear and complete so that it can be easily understood and used by
all nominated personnel.
b) Supporting tools
Describe or provide references - as in item a) above - but covering the tool support requirements. This can
include guides for the use of databases, spreadsheet and statistical packages.
c) Relevant standards and guides
Refer to applicable standards and supporting guides. Describe their use and benefits relevant to the purchasing
and acquisition processes (e.g. ISO/IEC 9126; ISO/IEC 9001; ISO/IEC 9000-3).
d) Suppliers' evaluation
Include evaluation and measurement procedures for the effective quantitative assessment of the software product
suppliers.
This can cover the number of released copies, current error status, surveys about post installation support
performance, statistics about past and current users satisfaction, management performance and financial stability.
Related parameters relevant to the application, which have been obtained from other suppliers, can be
incorporated in the suppliers’ evaluation plan.
Annexe II
178
Annexe II : Mesures de la maintenabilité selon l’ISO 9126
ISO/IEC TR 9126-3:2002(E) 8.5 Maintainability metrics Internal maintainability metrics are used for predicting the level of effort required for modifying the software product. 8.5.1 Analysability metrics Internal analyzability metrics indicate a set of attributes for predicting the maintainer’s or user’s spent effort or spent resources in trying to diagnose for deficiencies or causes of failure, or for identification of parts to be modified in the software product. 8.5.2 Changeability metrics Internal Changeability metrics indicate a set of attributes for predicting the maintainer’s or user’s spent effort when trying to implement a specified modification in the software product. 8.5.3 Stability metrics Internal stability metrics indicate a set of attributes for predicting how stable the software product would be after any modification. 8.5.4 Testability metrics Internal testability metrics indicate a set of attributes for predicting the amount of designed and implemented autonomous test aid functions present in the software product 8.5.5 Maintainability compliance metrics Internal compliance metrics relating to maintainability indicate a set of attributes for assessing the capability of the software product to comply to such items as standards, conventions or regulations of the user organisation in relation to software maintainability.
Annexe II
179
Annexe II
180
Annexe II
181
Annexe II
182
Annexe II
183
Annexe II
184
ISO/IEC TR 9126-2
7.5 Maintainability metrics
An external maintainability metric should be able to measure such attributes as the behavior of maintainer, user, or system including the software, when the software is maintained or modified during testing or maintenance.
7.5.1 Analyzability metrics
An external analyzability metric should be able to measure such attributes as maintainer’s or user’s effort or spent resources when they try to diagnose for deficiencies or causes of failures, or for identification of parts to be modified.
7.5.2 Changeability metrics
An external changeability metric should be able to measure such attribute as maintainer’s or user’s effort by measuring the behavior of maintainer, user or system including the software when they try to implement a specified modification.
7.5.3 Stability metrics
An external stability metric should be able to measure attributes related to unexpected behavior of system including the software when the software is tested or operated after modification.
7.5.4 Testability metrics
An external testability metric should be able to measure such attributes as maintainer’s or user’s effort by measuring the behavior of maintainer, user or system including software when they try to test the modified or non modify software.
7.5.5 Compliance metrics
An external maintainability compliance metric should be able to measure an attribute such as the number of functions with, or occurrences of compliance problems, which is of the software product to failing to adhere to standards, conventions or regulations relating to maintainability which are required to be adhered.
Annexe II
185
Annexe II
186
Annexe II
187
Annexe II
188
Annexe II
189
Annexe II
190
Annexe II
191
Annexe II
192
Annexe III
193
Annexe III : Maintenability Models
1. Relationships between McCall’s quality factors and metrics
Roger S. Pressman, “Software Engineering: A Practitioner’s Approach” (European Adaptation), Ch. 19, Fifth Edition, 2000.
2. Relationships between internal and external software
Copyright © 2011 Ian Sommerville, Software Engineering, 9th edition. Chapter 27/page 670.
Annexe III
194
3. Maintainability Metrics Hierarchy (according to ISO/IEC-9126)
Annexe III
195
4. Software Improvement Group Maintainability model (model version: January 2011) 1090 GX Amsterdam, The Netherlands - www.sig.eu
The assignment of evaluation results at the level of quality sub-characteristics based on the evaluation results at the level of product properties takes the following relationships into account.
The volume of source code negatively impacts its analyzability, since the diagnosis of faults or parts to be modified is more difficult or time-consuming when a larger volume of source code needs to be taken into consideration.
The duplication of source code negatively impacts its analyzability, since the diagnosis of faults or parts to be modified is more difficult or time-consuming when the same or similar parts occur multiple times in different places of the source code.
The duplication of source code negatively impacts its changeability, since the implementation of a modification is more difficult or time-consuming when it involves making changes to the source code in multiple locations.
The unit size of source code negatively impacts its analyzability, since the diagnosis of faults or parts to be modified is more difficult or time-consuming when the source code is grouped into a low number of large units rather than into a high number of small units.
The unit size of source code negatively impacts its testability, since validation of modified parts of source code is more difficult or time-consuming when the source code is grouped into a low number of large units rather than into a high number of small units.
The unit complexity of source code negatively impacts its changeability, since the implementation of a modification in a specific part of the source code is more difficult or time-consuming when this part is complex.
The unit complexity of source code negatively impacts its testability, since the validation of modifications to a software unit requires more test cases when the unit is complex.
The unit interfacing of source code impacts its stability, since it is more difficult to avoid unexpected effects of modifications when the interfaces of units are large.
The module coupling of source code impacts its changeability, since the modification of modules with many incoming dependencies is more difficult or time consuming.
The module coupling of source code impacts its stability, since it is more difficult to avoid unexpected effects of modification for modules with many incoming dependencies.
Annexe IV
196
Annexe IV - Metrics Tools
One starting point for software tools, and there are many is the Software Measurement
Laboratory at the University of Magdeburg.
There are a growing number of metrics tools. Here's a partial list.
Cantata - Cantata is a software verification product which offers developers a
complete solution to the verification of C software in a single package. The tool
provides automated facilities for Dynamic Testing, Coverage and Static analysis in
a totally integrated environment. The product has been designed to offer high
productivity and is exceptionally easy to use in both host and target environments.
CMT++ - by Testwell is a vendor of testing tools for C, C++ and Ada languages.
The tools are applicable in code-level unit testing (test harnessing, test coverage),
systems testing (test coverage) and static analysis (code metrics) sub-phases of
testing.
Codecheck – Abraxas Software Version 9.0 is a programmable tool for managing
all C and C++ source code on a file or project basis. CodeCheck is input
compatible with all variants of K&R, ANSI C and C++ ( Microsoft, Metaware,
Borland, Intel, Vax/Vms-Ultrix, HP/Apollo, Microtec, Watcom, Symantec, Apple
MPW, CodeWarrior, AT&T, and GNU ). CodeCheck is designed to solve Portability,
Maintainability, Complexity, Reusability, Quality Assurance, Style Analysis,
Library/Class Management, Code Review, Software Metric, Standards Adherence,
and Corporate Compliance Problems
Charismatek – is an Australian company specializing in function point tools such as
the Function Point Workbench (FPW) which is widely distributed in other countries.
The Function Point Workbench is not a full software cost estimating tool, but does
assist in enumerating costs based on function points by allowing effort and costs
to be distributed. The tool includes full function point sizing capabilities and a
repository of projects that have been sized. The Function Point Workbench is often
used in addition to other forms of software cost estimation such as CHECKPOINT
or KnowledgePlan.
Chis Pty Ltd – The FP Recorder is a tool for Function Point Analysis.
GlobalMANAGER™ This tool collects and displays real-time managerial and
technical data generated during the software development process. As a web-
based Graphical User Interface, it displays critical information needed to
proactively manage the software development process. An online demonstration of
the tool is available.
Goel-Okumoto Software Reliability Model An automated version of the Goel-
Okumoto Nonhomogeneous Poisson Process Software Reliability Model which runs
on an IBM-PC. Distributed by the DACS. Hindsight – Code-cyclomatic complexity.
Krakatau – I've used this one for several years on a large Java project. The
current version (released in May of 2001) is an updated version of our "beta" tools
suite.
Annexe IV
197
McCabe & Associates McCabe & Associates was founded by Tom McCabe, Sr., the
president and inventor of a widely used complexity metric. McCabe & Associates is
the developer of the McCabe Visual ToolSets (TM). This includes The Visual Quality
ToolSet, The Visual Testing ToolSet, and The Visual Reengineering ToolSet.
Metamata Metrics – Code-the Chidamber & Kemerer suite in its entirety, LOC,
cyclomatic complexity, fan out and several others.
Metrics ONE – Four categories of metrics are calculated: class metrics, package
metrics, operation metrics and use case metrics. The metrics are actually
calculated on the Rational Rose model rather than the native code, hence the
Rational Rose requirement.
Metre v2.3 Metre is a freely distributable ANSI/ISO Standard C parser. Reports
Halstead metrics, various line and statement counts, backfired function points,
control depth, identifier count, number of functions and modules, and a call graph.
Metrics4 [FORTRAN | Pascal | Project] – Code-LOC, cyclomatic complexity and fan
out.
MetricCenter Distributive Software develops and markets MetricCenter, a suite of
applications that provide enterprise-wide measurement and metrics. MetricCenter
supports all aspects of an organizational measurement process and is in use by
organizations rated in the software and systems CMM (up to Level 5) and ISO-
9000.
Object Detail – Code-encapsulation, inheritance, polymorphism, DIT, WMC, CBO.
OOMetric/Developer –Metrics specific to VisualAge.
Panorama – Code-cyclomatic complexity, WMC, DIT, NOC, CBO, RFC.
PC-Metric – Code-cyclomatic complexity & Halstead measures.
PRICE Systems PRICE-S is a well-known software cost estimating model provided
by Martin Marietta
Process Focus Software Process Focus Software provides software tools supporting
process improvement activities, including an interactive interface to the Software
Engineering Institute's Capability Maturity Model (CMM).
Programs for C Source Code Metrics Some free programs to count lines of code,
cyclomatic complexity, Halstead metrics, backfired Function Points, etc. for C
code. The tools can be compiled on SunOS.
QA Family – Code-cyclomatic complexity, providing deep flow static analysis tools
QA C, QA C++, and QA Fortran. These tools detect various aspects of your code
including language implementation errors and incorrect programming practice.
Each product offers extensive reporting functions.
Annexe IV
198
QualGen – Calculates approximately 200 metrics, after parsing Ada 83, Ada 95,
FORTRAN 77, FORTRAN 90, K&R C, ANSI C and C++ source code to reverse
engineer, automatically document, calculate code metrics, and help the user
understand, navigate and maintain source code that has grown too large for one
person (or even a group) to understand.
Quantitative Software Management (QSM) Lawrence Putnam is the president of
QSM. QSM offers their clients Software Lifecycle Management (SLIM) processes
and tools for software cost estimating, reliability modeling, schedule estimating,
planning, tracking, and benchmarking.
Resource Standard Metrics – Project and code. The code measures seemed to be
largely focused around LOC.
SET Laboratories, Incorporated SET Laboratories, Inc. has been a leading provider
of software measurement products and services since 1987.
Scientific Toolworks Inc.; QualGen is a software metrics system that can derive
200 metrics from Ada or C source code.
Software Metrics – Code. A wide range of metrics are calculated and can be found
described on their website. They fall under the following 6 categories: McCabe
metrics, Halstead metrics, date metrics, LOC metics, the Chidamber and Kemerer
suite (except for CBO) and other OO metrics.
SoftEST Software Estimation Model SEPO has made available version 1.1 of the
SoftEST which was developed by MCR Federal Inc. on behalf of the Air Force Cost
Analysis Agency. SoftEST is the follow-on to the REVIC software estimation model
and is Windows-based. SoftEST is also Y2K compliant.
Softstar Systems Developers of Costar, an automated implementation of COCOMO
II.
Software Productivity Research Information Center A leading provider of software
measurement, assessment, and estimation products and services. Capers Jones is
SPR's chairman and founder.
SourceMonitor (Campwood Software)
The freeware program SourceMonitor lets you see inside your software source
code to find out how much code you have and to identify the relative complexity of
your modules. For example, you can use SourceMonitor to identify the code that is
most likely to contain defects and thus warrants formal review. SourceMonitor,
written in C++, runs through your code at high speed, typically at least 10,000
lines of code per second. SourceMonitor provides the following:
Collects metrics in a fast, single pass through source files.
Measures metrics for source code written in C++, C, C#, VB.NET, Java,
Delphi, Visual Basic (VB6) or HTML.
Includes method and function level metrics for C++, C, C#, VB.NET, Java,
and Delphi.
Offers Modified Complexity metric option.
Saves metrics in checkpoints for comparison during software development
projects.
Displays and prints metrics in tables and charts, including Kiviat diagrams.
Annexe IV
199
Operates within a standard Windows GUI or inside your scripts using XML
command files.
Exports metrics to XML or CSV (comma-separated-value) files for further
processing with other tools.
Telelogic A developer and vendor of CASE tools, including the measurement tool
Logiscope and object oriented tools.
TychoMetrics TychoMetrics is a web based, open system, metric management tool
for the enterprise. TychoMetrics automates the collection of data from anywhere
around the world via the Internet. It uses measurement modeling technology to
assure data integrity and repeatability of measurement. TychoMetrics provides
report generation that can automatically publish selected reports to the web. Users
can define their own metrics or use standard metrics that have been encapsulated
in Metric Analysis Paks (MAPs). Time series charts provide trend forecasting and
statistical process control. When control limits are exceeded TychoMetrics can
display your organization's appropriate policy and procedures.
Testworks METRIC – Code-LOC, cyclomatic complexity, Halstead measures.
TestWorks, an integrated suite of software test tools, is the broadest test tool
suite available. TestWorks tools help automate and streamline the software
development and testing process with product lines that work independently or as
an integrated tool suite. TestWorks is the only tool suite that offers Regression
Testing, Test Suite Management, and Test Coverage support for Web and Windows
and UNIX Platforms.
Total Metric for Java – Code-cyclomatic complexity, Halstead measures.
Web-Integrated Software Environment (WISE) WISE is a WWW-based project
management and metrics system available on the WWW. Programmers and
managers can log issue reports, track the status of issues, and view project
metrics using standard WWW browsers.