d’évaluation du software pour l’amélioration de la

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


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


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


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


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

http://fr.wikipedia.org/wiki/G%C3%A9nie_logiciel

http://fr.wikipedia.org/wiki/ISO_9126

http://fr.wikipedia.org/wiki/Fiabilit%C3%A9

http://fr.wikipedia.org/wiki/Maintenabilit%C3%A9

http://fr.wikipedia.org/wiki/Portabilit%C3%A9

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é 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é.


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 à


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


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,


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).


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


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,

http://fr.wikipedia.org/wiki/Gestion_de_la_qualit%C3%A9


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 ;


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]


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.


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:

http://www.google.com/url?sa=t&source=web&cd=1&ved=0CB8QFjAA&url=http%3A%2F%2Fwww.defense.gov%2F&rct=j&q=DOD&ei=3yBJTdoNlK_xA-nkhNkO&usg=AFQjCNHvKvPkmHYKerfPVK7fjuOQYdgnng&cad=rja


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.


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.

http://fr.wikipedia.org/wiki/Virus_informatique

http://fr.wikipedia.org/wiki/Virus_informatique


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é).


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é.


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).


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.

http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf

http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf


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:


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]


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

http://www.numeraladvance.com/Role_des_Normes/Normes_pour_SI/ISO_9126/L_ISO_9126.htm


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é.

http://www.it-cisq.org/


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.


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.

http://fr.wikipedia.org/wiki/Sp%C3%A9cification_%28informatique%29

La mesure du logiciel

29

Chapitre 2.


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


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


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].


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é.


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

http://fr.wikipedia.org/wiki/Logiciel


http://fr.wikipedia.org/wiki/Sp%C3%A9cifications_fonctionnelles



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


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


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


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].


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]


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


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


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


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].

../Thesis%20-%20Chap2/Nouveau%20dossier/Modeles%20Fiabiliأ©/glossaire.html#FiabLog


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.


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


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]


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


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


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.


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


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.


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.


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.


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


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] ;


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.

http://fr.wikipedia.org/wiki/Application_%28math%C3%A9matiques%29

http://fr.wikipedia.org/wiki/Ensemble

http://fr.wikipedia.org/wiki/Structure_%28math%C3%A9matiques%29


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.


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.


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.


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 à


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


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.


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


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


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 à


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]


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


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


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


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


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].


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, …

http://fr.wikipedia.org/wiki/Microsoft_Access

http://fr.wikipedia.org/wiki/Visual_FoxPro


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.


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.


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


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.


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)


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


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 :


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.

http://fr.wikipedia.org/wiki/Algorithmique

http://fr.wikipedia.org/wiki/Programme_informatique


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


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


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 (...),


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


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


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.


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


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) ;


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].


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


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.


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.


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.

http://fr.wikipedia.org/wiki/Paradigme_(programmation)

http://fr.wikipedia.org/wiki/Programmation_informatique

http://fr.wikipedia.org/wiki/Alan_Kay

http://fr.wikipedia.org/wiki/Objet_(informatique)


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.


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


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).


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.


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


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:


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.


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


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


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

http://fr.wikipedia.org/wiki/Logiciels


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.


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.


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


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é.


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);


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


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;


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


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.


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.


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.


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é.


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.


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?


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


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


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).


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:


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).


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».


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.


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.


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.


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).


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.

http://www.numeraladvance.com/Role_des_Normes/Normes_pour_SI/ISO_9126/L_ISO_9126.htm

http://www.iso.org/


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


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] :


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]


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


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.


138


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.


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))


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?


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.


143


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


145


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é.


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.


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.


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é.


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].


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).

http://en.wikipedia.org/wiki/Indentation_style

http://en.wikipedia.org/wiki/Comment_(computer_programming)

http://en.wikipedia.org/wiki/Decomposition_(computer_science)

http://en.wikipedia.org/wiki/Naming_conventions_(programming)

http://fr.wikipedia.org/wiki/Programmeur


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.

http://fr.wikipedia.org/wiki/Programmation_par_contrat

http://fr.wikipedia.org/wiki/Assertion


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”) .

http://fr.wikipedia.org/wiki/Factorisation_du_code

http://fr.wikipedia.org/wiki/Instruction

http://fr.wikipedia.org/wiki/Fonction_%28informatique%29


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.

http://fr.wikipedia.org/wiki/Sp%C3%A9cification_%28informatique%29

http://fr.wikipedia.org/wiki/Extreme_programming

http://fr.wikipedia.org/wiki/Test_Driven_Development


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.


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).

http://fr.wikipedia.org/wiki/Anglicisme

http://fr.wikipedia.org/wiki/Programme_informatique


157

5.4.2. Projet : eMule ;

Fichier Excel (résultats détaillés de l’évaluation) : eMule project.xls ;

Version du projet : 0.50a ;


Langage de développement : C++.



Nombre de méthodes (#Methods) = 8136 ;


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.


158

5.4.3. Projet : 7 Zip ;

Version du projet : 9.22 Beta ;


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 ;




7 Zip (partie écrite en langage C++);

Fichier Excel (résultats détaillés de l’évaluation) : 7 Zip project (C++ part).xls ;






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.


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 ;


Langage de développement : C#.




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.


161

5.4.5. Projet : WDents ;

Fichier Excel (résultats détaillés de l’évaluation) : WDents project.xls ;

Version du projet : 2.4 ;


Langage de développement : Delphi.


Nombre de subroutines (#Subroutines) = 3232 ;



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.


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 subroutines (#Subroutines) = 55 ;



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


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.

http://fr.wikipedia.org/wiki/Sp%C3%A9cial:Ouvrages_de_r%C3%A9f%C3%A9rence/9782746231474

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.

http://www.amazon.fr/Conception-entre-sciences-art-conception/dp/2880744806/ref=sr_1_1?ie=UTF8&qid=1296658969&sr=1-1

http://www.techniques-ingenieur.fr/

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.

http://www.amazon.com/Stephen-H.-Kan/e/B001HD09XW/ref=sr_ntt_srch_lnk_2?qid=1323848854&sr=8-2

http://www.amazon.com/Metrics-Models-Software-Quality-Engineering/dp/0201729156/ref=sr_1_2?ie=UTF8&qid=1323848854&sr=8-2

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.

http://www.cse.dcu.ie/essiscope/sm2/atwork/scope.html

http://www.eecs.qmul.ac.uk/~norman/papers/new_directions_metrics/HelpFileHistory_of_software_metrics_as_a.htm

http://www.eecs.qmul.ac.uk/~norman/papers/new_directions_metrics/HelpFileHistory_of_software_metrics_as_a.htm

http://www.infeig.unige.ch/support/se/lect/prj/gp/node4.html

http://www.journaldunet.com/solutions/0306/030624_faq_cmm.shtml

http://www.verifysoft.com/fr_cmtpp_mscoder.pdf

http://www.lemagit.fr/articldeveloppement-tests-gouvernance-qualite/4188/1/consortium-cisq-qualite-logicielle-veut-elle-aussi-son-thermometre/

http://www.lemagit.fr/articldeveloppement-tests-gouvernance-qualite/4188/1/consortium-cisq-qualite-logicielle-veut-elle-aussi-son-thermometre/

http://www.lirmm.fr/~leclere/enseignements/TER/2009/Rapport/N.pdf

http://scssummary.googlecode.com/svn-history/r2/trunk/Papers/Halstead_Paper.pdf

http://www.standishgroup.com/

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.

http://www.sig.eu/

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.

http://www-ivs.cs.uni-magdeburg.de/sw-eng/us/

http://www-ivs.cs.uni-magdeburg.de/sw-eng/us/

http://www.iplbath.com/p13.htm

http://www.testwell.sci.fi/cmtdesc.html

http://www.pitt.edu/~ddarcy/isprof/tools.html#Codecheck

http://www.charismatek.com/

http://www.chispl.com/

http://www.globalmanager.org/

http://www.dacs.dtic.mil/about/services/goel.shtml

http://www.integrisoft.com/

http://www.power-soft.co.uk/

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.

http://www.mccabe.com/

http://www.metamata.com/

http://www.metamata.com/

http://www.lysator.liu.se/c/metre-v2-3.html

http://plus-one.com/

http://www.distributive.com/

http://www.pitt.edu/~ddarcy/isprof/tools.html#ObjectDetail

http://www.pitt.edu/~ddarcy/isprof/tools.html#Hatteras

http://www.pitt.edu/~ddarcy/isprof/tools.html#Panorama

http://www.pitt.edu/~ddarcy/isprof/tools.html#PCMetric

http://www.pricesystems.com/

http://www.concentricmc.com/toolsreport/vendor.html#Martin%20Marietta

http://www.processfocus.com/

http://www.qucis.queensu.ca/Software-Engineering/Cmetrics.html

http://www.prqa.co.uk/

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.

http://www.scitools.com/

http://www.qsm.com/

http://www.pitt.edu/~ddarcy/isprof/tools.html#M2Tech

http://www.molalla.net/~setlabs/

http://www.scitools.com/qualgen.html

http://www.pitt.edu/~ddarcy/isprof/tools.html#McCabe

http://sepo.spawar.navy.mil/sepo/estimation.html

http://www.softstarsystems.com/

http://www.spr.com/

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.

http://www.csverilog.com/

http://www.predicate.com/tmds.html

http://www.soft.com/TestWorks/

http://www.cigital.com/products/

http://research.ivv.nasa.gov/projects/WISE/index.html

Documents

d’évaluation du software pour l’amélioration de la