MESURE DE LA COMPLEXITÉ FONCTIONNELLE DES LOGICIELS - UQAM · Je tiens à remercier profondément...

UNIVERSITÉ DU QUÉBEC À MONTRÉAL

MESURE DE LA COMPLEXITÉ FONCTIONNELLE

DES LOGICIELS

THÈSE

PRÉSENTÉE

COMME EXIGENCE PARTIELLE

DU DOCTORAT EN INFORMATIQUE COGNITIVE

Par

DE TRAN-CAO

JUIN 2005

REMERCIEMENTS Cette thèse n’aurait pu être accomplie sans l’appui de ma famille, des professeurs de

l’Université du Québec à Montréal (UQÀM) et du personnel administratif du programme.

Je tiens donc à remercier toutes les personnes qui ont su me motiver à entreprendre cette

recherche et m’aider de leurs conseils.

Je tiens à remercier profondément Dr. Ghislain Lévesque, professeur à l’UQÀM, qui a

dirigé ma recherche. Ses précieux conseils de direction ont contribué de façon

significative à cette thèse. À titre de directeur du programme, son enthousiasme et sa

bonté m’ont beaucoup encouragé dans les moments difficiles.

Je tiens à remercier également:

!" Dr. Jean-Guy Meunier, professeur à l’UQÀM, mon co-directeur de recherche,

pour ses conseils sur le volet cognitif de la thèse.

!" Dr. Marc Bouisset, professeur à l’UQÀM, ex-directeur des études de l’Institut

Francophone pour l’Informatique de Hanoi, qui m’a motivé à faire mes études à

l’UQÀM.

!" Dr. Alain Abran, professeur à l’École de Technologie Supérieur de Montréal, ex-

directeur du Laboratoire de Recherche en Gestion des Logiciels (LRGL) de

l’UQÀM, qui m’a offert un stage de recherche au LRGL et m’a dirigé au début

de la recherche.

!" Dr. Robert Dupuis, professeur à l’UQÀM, directeur du LRGL, qui m’a permis

d’utiliser les ressources du LRGL et m’a fourni un ambiance de travail agréable

au LRGL.

La liste des personnes qui de près et de loin m’ont aidé et encouragé pendant ces années

de recherche serait trop longue à produire. Je tiens à remercier les amis du LRGL, le

personnel administratif du programme et mes amis vietnamiens à Montréal pour leurs

sentiments amicaux et leur appui indispensable.

Ces remerciements s’adressent à mes parents qui ont travaillé pour l’avenir de leur fils.

Enfin, je tiens à remercier ma femme et mes filles pour les sacrifices qu’elles ont consenti

à faire pendant plusieurs années sans jamais se plaindre.

Merci à tous !

TABLE DES MATIÈRES

TABLE DES MATIÈRES ..................................................................................... iii

LISTE DES FIGURES......................................................................................... viii

LISTE DES TABLEAUX....................................................................................... x

LISTE DES ACRONYMES ................................................................................. xii

RÉSUMÉ .................................................................................................. xiii

ABSTRACT .................................................................................................. xiv

INTRODUCTION .................................................................................................. 1

1. Concept de la complexité du logiciel .......................................................... 2

2. Objectif de la thèse...................................................................................... 2

3. Organisation de la thèse .............................................................................. 4

4. Problématique de recherche et démarches .................................................. 8

CHAPITRE 1 COMPLEXITÉ ET MESURE DE LA COMPLEXITÉ DU

LOGICIEL ................................................................................................... 10

1.1 Concepts utilisés dans la thèse .............................................................. 11

1.1.1 Logiciel ......................................................................................... 11

1.1.2 Génie logiciel ................................................................................ 12

1.1.3 Mesure du logiciel......................................................................... 12

1.1.4 Complexité .................................................................................... 13

1.1.5 Effort de développement du logiciel ............................................. 15

1.2 Définitions de la complexité ................................................................. 15

1.2.1 Approche des systèmes complexes ............................................... 15

1.2.2 Approche computationnelle .......................................................... 21

1.3 Complexité du logiciel .......................................................................... 24

1.3.1 Notion de la complexité du logiciel .............................................. 24

1.3.2 Définitions de la complexité du logiciel ....................................... 25

1.3.3 Deux aspects de la complexité du logiciel .................................... 27

1.3.4 Catégorisations des mesures de la complexité du logiciel ............ 28

iv

1.4 Résumé.................................................................................................. 31

CHAPITRE 2 MESURES BASÉES SUR LE CODE SOURCE ET LA

CONCEPTION DU PROGRAMME.................................................................... 32

2.1 Mesures de la taille du programme ....................................................... 32

2.1.1 Mesure de lignes de code .............................................................. 32

2.1.2 Science du logiciel de Halstead..................................................... 34

2.2 Mesures de la structure des programmes .............................................. 38

2.2.1 Mesure de McCabe ....................................................................... 39

2.2.2 Mesure de Henry et Kafura ........................................................... 40

2.2.3 Couplage et cohésion .................................................................... 42

2.2.4 Mesures de la compréhensibilité du programme .......................... 45

2.3 Explication de la complexité au point de vue psychologique ............... 49

2.3.1 Résultats principaux concernant l’architecture de l’esprit humain49

2.3.2 Explication de la complexité......................................................... 50

2.4 Résumé.................................................................................................. 51

CHAPITRE 3 MESURES DE POINTS DE FONCTION ............................... 53

3.1 Analyse de points de fonction (Function Points Analysis – FPA)........ 53

3.1.1 Concept de point de fonction (PF) ................................................ 53

3.1.2 Mesure de points de fonction ........................................................ 55

3.1.3 Structure de FPA........................................................................... 57

3.1.4 Limites majeures de FPA.............................................................. 58

3.2 Variantes de la méthode de points de fonction ..................................... 59

3.2.1 Mark-II .......................................................................................... 61

3.2.2 Feature Points................................................................................ 63

3.2.3 Asset-R.......................................................................................... 64

3.2.4 Points de fonction 3D (3D Function points) ................................. 66

3.2.5 COSMIC-FFP ............................................................................... 66

3.3 Cadre général de la complexité des méthodes de points de fonction.... 68

3.4 Utilisation des points de fonction.......................................................... 72

3.4.1 Productivité ................................................................................... 73

3.4.2 Estimation d’effort ........................................................................ 73

v

3.5 Problématique de recherche .................................................................. 76

3.5.1 Cadre d’analyse de la complexité fonctionnelle ........................... 77

3.5.2 Problème d’évaluer la complexité................................................. 77

3.6 Résumé.................................................................................................. 78

CHAPITRE 4 MODÈLE DE LA COMPLEXITÉ DE LA TÂCHE ................ 80

4.1 Complexité de la tâche .......................................................................... 80

4.2 Modèle de la complexité de la tâche de Wood ..................................... 84

4.2.1 Complexité des composants.......................................................... 86

4.2.2 Complexité de coordination .......................................................... 87

4.2.3 Complexité dynamique ................................................................. 88

4.2.4 Complexité totale de tâche ............................................................ 89

4.2.5 Remarques sur le modèle de la complexité de la tâche................. 90

4.3 Quelques modèles de la complexité du logiciel basés sur la complexité

de la tâche.......................................................................................................... 92

4.3.1 Mesure de la complexité de maintenance ..................................... 92

4.3.2 Mesure de la complexité de la conception .................................... 93

4.4 Résumé.................................................................................................. 94

CHAPITRE 5 NOUVELLE MÉTHODE DE MESURE DE LA

COMPLEXITÉ FONCTIONNELLE DU LOGICIEL ......................................... 96

5.1 Modélisation du logiciel........................................................................ 97

5.1.1 Modèle conceptuel du logiciel ...................................................... 97

5.1.2 Modèle fonctionnel du logiciel de COSMIC .............................. 100

5.1.3 Modèle fonctionnel du logiciel proposé pour mesurer la

complexité ................................................................................................... 104

5.2 Mesures de la complexité du logiciel.................................................. 107

5.2.1 Logiciel analysé comme une tâche ............................................. 108

5.2.2 Complexité fonctionnelle analysée comme la complexité de la

tâche ..................................................................................................... 109

5.2.3 Cadre de la complexité fonctionnelle.......................................... 110

5.2.4 Mesure de la complexité de données entrées/sorties................... 113

5.2.5 Mesure de la complexité structurelle des composants ................ 116

vi

5.2.6 Mesure de la complexité du système .......................................... 118

5.2.7 Résumé des mesures proposées pour mesurer la complexité du

logiciel ..................................................................................................... 120

5.3 Étude de cas ........................................................................................ 122

5.3.1 Spécification de l’application...................................................... 122

5.3.2 Comptage de la complexité du Cuiseur de riz ............................ 124

5.4 Résumé................................................................................................ 127

CHAPITRE 6 INVESTIGATION EMPIRIQUE ET VALIDATION DES

MESURES DE LA COMPLEXITÉ FONCTIONNELLE ................................. 130

6.1 Concept de validation de la mesure .................................................... 130

6.1.1 Validation d’une mesure ............................................................. 131

6.1.2 Validation d’un système de prédiction........................................ 132

6.1.3 Problèmes de validation d’une mesure ....................................... 133

6.2 Processus développement d’une méthode de mesure ......................... 134

6.3 Validation du processus de développement d’une méthode de

mesure ............................................................................................................. 136

6.4 Validations des mesures proposées dans cette thèse........................... 138

6.4.1 Validation de la conception de la méthode de mesure................ 138

6.4.2 Expérimentation sur les mesures de la complexité fonctionnelle

proposées..................................................................................................... 144

6.5 Résumé................................................................................................ 159

CONCLUSION ................................................................................................. 161

1. Cadre de la complexité fonctionnelle...................................................... 163

2. Problème d’évaluation de la complexité ................................................. 164

3. Problème de la validation de la méthode ................................................ 166

4. Conformité à la théorie de la mesure ...................................................... 166

5. Problème d’estimation d’effort ............................................................... 167

6. Perspectives futures de recherche ........................................................... 169

6.1. Exploitation de la mesure................................................................ 169

6.2. Automatisation de la mesure........................................................... 170

BIBLIOGRAPHIE .............................................................................................. 172

vii

ANNEXE 1 PUBLICATIONS .......................................................................... 182

ANNEXE 2 RAPPORT DE COMPTAGE DE 15 PROJETS .......................... 183

1. Case study 1: Project P6.......................................................................... 183

2. Case study 2: Project P17........................................................................ 185








10. Case study 10: Project P9.................................................................... 203

11. Case study 11: Project P14.................................................................. 205

12. Case study 12: project P7.................................................................... 209


14. Case study 14: Project P26.................................................................. 221


LISTE DES FIGURES

Figure 2.1: Exemple d’un graphe de flux (flowgraph). ...................................... 39

Figure 2.2: Exemple de fan-in et fan-out............................................................ 41

Figure 2.3: Graphe G. ......................................................................................... 46

Figure 2.4: a) Entropie=0. b) Entropie atteint la valeur maximale pour un

graphe de 5 nœuds (H=log5)............................................................ 47

Figure 3.1: Modèle global de la méthode de points de fonction (FPA). ............ 57

Figure 3.2: Modèle du logiciel de COSMIC. ..................................................... 67

Figure 3.3: Quatre types de mouvement de données de COSMIC..................... 67

Figure 3.4: Cadre général de la complexité basée sur les méthodes de points de

fonction. ........................................................................................... 69

Figure 4.1: Modèle de la tâche [177].................................................................. 84

Figure 4.2: Modèle de la complexité de la tâche de Wood. ............................... 85

Figure 5.1: Exemple d’un diagramme de flux et de ses niveaux d’abstraction

différents. ......................................................................................... 98

Figure 5.2: a) Montre numérique b) Diagramme d’état de la montre

numérique......................................................................................... 99

Figure 5.3: Modèle fonctionnel du logiciel. ..................................................... 101

Figure 5.4: Modèle d’un processus fonctionnel de COSMIC. ......................... 102

Figure 5.5: Modèle fonctionnel du logiciel caractérisant la manipulation de

données d’un processus fonctionnel. ............................................. 106

Figure 5.6: Modélisation de manipulation de données..................................... 106

Figure 5.7a: Modèle de traitement de l’information de tâche. ........................... 108

Figure 5.7b: Modèle de traitement de l’information de processus

fonctionnel. .................................................................................... 108

Figure 5.8: Modèle de la complexité de la tâche. ............................................. 110

Figure 5.9: Modèle de la complexité du logiciel. ............................................. 111

Figure 5.10: Comptage la taille fonctionnelle de deux processus A et B........... 114

ix

Figure 5.11: Exemple d’un graphe représentant la relation de données entre les

processus. ....................................................................................... 119

Figure 5.12: Panneau de contrôle du Cuiseur de Riz.......................................... 122

Figure 5.13: Température cible par mode. ......................................................... 123

Figure 5.14: Architecture du Cuiseur de riz. ...................................................... 124

Figure 5.15: Graphe représentant les dépendances de données entre les processus

fonctionnels du Cuiseur de riz. ...................................................... 127

Figure 6.1: Processus de mesure [93]. .............................................................. 134

Figure 6.2a: Modèle détaillé du processus de mesure [93]. ............................... 135

Figure 6.2b: Trois types de validation d’une méthode de mesure...................... 137

Figure 6.3: Qualité de la documentation pour identifier les concepts de mesure

de COSMIC [151]. ......................................................................... 143

Figure 6.4a: 15 projets ayant un effort inférieur de 24 homme-mois................. 145

Figure 6.4b: 10 projets ayant un effort supérieur à 24 homme-mois.................. 145

Figure 6.5 : Deux groupes des projets séparés. ................................................. 146

Figure 6.6: Analyse de performance du modèle de prédiction de l’effort utilisant

NOD et NOC.................................................................................. 152

Figure 6.7: Analyse de performance du modèle de prédiction d’effort utilisant

CFFP, NOD et NOC. ..................................................................... 152

Figure 6.8: Analyse de performance du modèle de prédiction d’effort utilisant

NOD, NOC et EOS. ....................................................................... 154

Figure 6.9: Résumé (graphique) sur la capacité de prédiction d’effort de NOD et

NOC. .............................................................................................. 157

Figure 6.10: Résumé (graphique) sur la capacité de prédiction d’effort de NOD,

NOC et EOS................................................................................... 158

LISTE DES TABLEAUX Tableau 2.1: Exemple des mesures de la complexité du logiciel....................... 30

Tableau 3.1: Type de fonctions élémentaires et les poids de complexité. ......... 55

Tableau 3.2: 14 caractéristiques générales du système (GSCs)......................... 55

Tableau 3.3: Six niveaux d’influence de 14 GSCs. ........................................... 56

Tableau 3.4: Critères et les poids de la complexité [97]. ................................... 64

Tableau 3.5: Analyse des mesures de points de fonction selon le cadre de la

complexité dans la figure 3.4. ....................................................... 71

Tableau 3.6: Utilisation des points de fonction dans l’industrie [67]. ............... 72

Tableau 3.7: Quelques modèles d’estimation d’effort et leur performance....... 76

Tableau 4.1: Mise en correspondance des concepts élémentaires de deux

modèles. ........................................................................................ 92

Tableau 4.2: Mise en correspondance des mesures de deux modèles................ 93

Tableau 5.1: Correspondance entre le modèle fonctionnel du logiciel et le

modèle de la tâche de Wood. ...................................................... 109

Tableau 5.2: Correspondance entre les termes utilisés dans le cadre de la

complexité et dans le modèle de la tâche de Wood. .................. 113

Tableau 5.3: Résumé des mesures proposées pour la complexité du logiciel. 121

Tableau 5.4: Légende de la figure 5.14............................................................ 124

Tableau 5.5: Complexité des composants (NOD) et la taille fonctionnelle de

COSMIC du Cuiseur de Riz........................................................ 125

Tableau 6.1: Ensemble de données utilisées dans l’expérimentation. ............. 147

Tableau 6.2: Corrélation linéaire (multiple) entre l’effort et les mesures

considérées. ................................................................................. 149

Tableau 6.3: Influence de chaque variable dans la régression multiple entre

l’effort et NOD et NOC............................................................... 151


l’effort et CFFP, NOD et NOC. .................................................. 151

Tableau 6.5: Comparaison de la performance des modèles (2) et (3).............. 152

xi


l’effort et NOD, NOC et EOS. .................................................... 153

Tableau 6.7: Comparaison de la performance des modèles (2) et (4).............. 154

Tableau 6.8: Amplitude d’erreur relative des tests croisés sur 15 couples NOD et

NOC. ........................................................................................... 156

Tableau 6.9: Amplitude d’erreur relative des tests croisés sur 8 triplets NOD,

NOC et EOS................................................................................ 156

Tableau 6.10: Résumé sur la capacité de prédiction d’effort............................. 157

LISTE DES ACRONYMES CMM Capacity Maturity Model

COCOMO Constructive Cost Model

COSMIC Common Software Measurement International Consortium

COSMIC-FFP COSMIC- Full Function Points

DFD Data Flow Diagram

DI Degree of Influence

EOS Entropy of System

FP Function Point

FPA Function Points Analysis

GQM Goal Question Metric

GSC General System Characteristic

IEEE Institute of Electrical and Electronics Engineers

IFPUG International Function Point User Group

ISO International Organization for Standardization

KLOC Thousand Lines of Code

LOC Lines of Code

MIS Management Information System

MMRE Mean Magnitude of Relative Error

MRE Magnitude of Relative Error

NOC Number of Conditions

NOD Number of Data Groups

PF Points de Fonction

PRED Prediction Quality

ROM Random Access Memory

SFC Software Functional Complexity

SFCM Software Functional Complexity Measure

SLIM Software Lifecycle Management

TCF Technical Complexity Factor

UFP Unadjusted Function Point

RÉSUMÉ Bien que plusieurs mesures de logiciels soient proposées, le domaine de la mesure du logiciel demeure encore immature. Les mesures existantes ne satisfont pas encore les utilisateurs. Plusieurs chercheurs ont constaté l’absence de théories de base servant à guider les méthodes de mesure. D’un point de vue pratique, nous avons besoin de mesures tôt dans le cycle de développement ou d’évolution afin de prévoir l’effort et le coût de développement ou de maintenance du logiciel avec une marge d’erreur étroite.

Les mesures basées sur la fonctionnalité du logiciel (c’est-à-dire, les méthodes de points de fonction) fournissent tôt des indices qui peuvent être utilisés pour estimer l’effort et le coût de développement du logiciel. Cependant, le taux d’erreurs des estimations avec ces mesures est encore élevé. Les limites majeures de ces mesures sont relatives à la complexité du logiciel. La plupart des mesures disponibles quantifient subjectivement la complexité. Certaines mesures ne couvrent pas suffisamment la complexité. Aucune mesure n’est fondée explicitement sur un modèle de la complexité.

Cette thèse propose une nouvelle méthode de mesure de la complexité des logiciels. La méthode est de type points de fonction. C’est-à-dire que la complexité est quantifiée à partir de la fonctionnalité du logiciel. Elle est donc appelée la complexité fonctionnelle du logiciel.

D’un point de vue fonctionnel, le logiciel est un ensemble de fonctions qui décrivent le problème à solutionner avec le logiciel. Le problème peut être considéré comme une tâche – la tâche à réaliser avec le logiciel. Dans cette thèse, la complexité fonctionnelle du logiciel est donc assimilée à la complexité de la tâche. Elle peut être analysée selon un modèle de la complexité de la tâche. Le modèle de la complexité de la tâche de Wood est introduit comme la base théorique pour comprendre et expliquer la complexité fonctionnelle du logiciel. En se basant sur ce modèle, un modèle conceptuel (un cadre) de la complexité fonctionnelle est proposé. Il se compose de la complexité des composants et la complexité du système. La première tient compte de la complexité intra-fonction qui est caractérisée par les données entrées et sorties et les manipulations internes. La seconde tient compte de la complexité inter-fonctions qui concerne les échanges de données entre les fonctions. Au point de vue théorique, le cadre conceptuel et les mesures proposées dans la thèse sont conformes aux idées philosophiques d’Ashby et de Simon sur la complexité. Ils sont aussi conformes au modèle de la complexité de la tâche de Wood parce qu’ils sont construits en se basant sur ce modèle. De plus, une investigation empirique sur 15 projets montre que les nouvelles mesures fournissent des indices adéquats pour estimer l’effort de développement du logiciel. Le taux d’erreurs moyen de l’estimation est très bas, 15% seulement. Ce taux est relativement plus faible que le taux d’erreurs moyen des estimations obtenues à partir de FPA et COSMIC-FFP qui se situent aux environs de 40%.

Mots Clés: Complexité de la tâche, complexité du logiciel, complexité cognitive, estimation d’effort, estimation de coût, mesure du logiciel, mesure de la complexité.

ABSTRACT Although many software measures have been proposed, the field of software measurement is still in its infancy. The existing measures do not satisfy the users yet. Many researchers have noted the absence of appropriate underlying theories to guide the measurement methods. From a practical point of view, users need a measure that is available early in the development or evolution cycle to predict the effort and the cost of development or maintenance of software with a narrow error margin.

The measures based on software functionality (i.e., the function point methods) provide early some indications that can be used to estimate the development effort and the cost of software. However, the error rate of the estimations using these measures is still high. The major limits of these measures are related to software complexity. Most of the available measures subjectively quantify complexity. Some of them do not sufficiently cover complexity. No measure is explicitly based on a software complexity model.

This thesis proposes a new method for measuring software complexity. The method is of function point type. This means that the complexity is based on the software’s functionality. Therefore, the complexity is called software functional complexity.

From a functional point of view, software is a set of functions that describe the problem to be resolved with software. The problem can be considered as a task – the task to be implemented with the software. In this thesis, the functional complexity of software is therefore assimilated to the complexity of the task. It can be analyzed after a task complexity model. The task complexity model of Wood is introduced as the underlying theoretical basis to better understand and explain software functional complexity. From this model, a conceptual model (framework) of functional complexity is proposed. It is composed of two aspects: the complexity of components and the complexity of system. The first takes into account the intra-function complexity which is characterized by the inputs and outputs data and the internal manipulations. The second takes into account the inter-functions complexity which refers to the data exchanged between the functions. From a theoretical point of view, the framework and the complexity measures proposed in the thesis conform to Ashby’s as well as Simon’s philosophical ideas about complexity. They also conform to Wood’s task complexity model because they are built upon this model. Moreover, an empirical investigation of 15 software projects shows that the new measures provide relevant indicators to estimate the software development effort. The mean magnitude of relative errors of the estimation is very low, 15% only. This margin is relatively smaller than the margin of errors of estimations using FPA or COSMIC-FFP, which is generally around 40%.

Key words: Task complexity, software complexity, cognitive complexity, effort estimation, cost estimation, software measurement, complexity measurement.

INTRODUCTION Les mesures jouent un rôle important dans plusieurs domaines scientifiques en général et

en génie logiciel en particulier. Lord Kelvin, physicien (1824-1907), disait:

«Quand vous pouvez mesurer ce dont vous parlez et l’exprimez en nombres, vous

pouvez savoir quelque chose à ce sujet; mais quand vous ne pouvez pas le mesurer et

l'exprimer en nombres, votre connaissance est en quelque sorte pauvre et

insuffisante» [100].

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. 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 ainsi que contrôler le budget.

Les mesures constituent une partie fondamentale des modèles de gestion de qualité du

produit logiciel. Les normes de qualité comme CMM [85] et ISO 9000 [91] proposent

toujours une approche quantitative selon laquelle les mesures sont utilisées pour

comprendre l’état actuel du projet et prévoir des caractéristiques futures du projet afin de

contrôler la qualité des processus de production ou la qualité du produit lui-même.

La présente thèse a pour but de contribuer à améliorer les approches de mesure pour

quantifier la complexité du logiciel. Cette mesure 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 les processus de production.

Introduction

2

1. CONCEPT DE LA COMPLEXITÉ DU LOGICIEL

Depuis le début de l’informatique, plusieurs méthodes de mesure ont été proposées pour

analyser et quantifier la complexité du logiciel. Le concept « complexité du logiciel »

n’est pas encore bien défini. La complexité est un terme général pour indiquer quelque

chose qui est difficile à conquérir, difficile à comprendre, difficile à réaliser, et par la

suite, on a besoin de ressources significatives (comme le temps, des connaissances…)

pour la maîtriser.

La complexité du logiciel est parfois utilisée pour indiquer la difficulté computationnelle

du logiciel. Dans ce cas, la complexité du logiciel fait référence aux ressources

matérielles (p.ex., le temps du processeur ou l’espace mémoire) requises pour exécuter le

logiciel (c-à-d, un programme). Alors, elle est appelée la complexité computationnelle

du logiciel. 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.

La complexité du logiciel est aussi 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

(p.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 encore appelée la complexité

psychologique ou la complexité cognitive. Une mesure de la complexité du logiciel dans

ce sens fournit un indice de l’effort humain (p.ex., homme-mois ou homme-heures) requis

pour réaliser une tâche. La tâche à réaliser peut être spécifique (p.ex., le codage, le

débogage, le test) ou plus générale comme le développement ou la maintenance du

logiciel.

Un des problèmes de la mesure de la complexité du logiciel vient du fait que le logiciel

n’est pas bien défini. Quand on dit « mesure de la complexité du logiciel », l’objet de la

mesure n’est pas clair. Et même si on mentionne explicitement qu’on mesure la

complexité du programme du logiciel, il y a encore des ambiguïtés car on ne sait pas à

quoi la mesure fait référence: la complexité computationnelle ou la complexité cognitive?

De ce fait, préciser le but de la mesure est important pour comprendre ce que la mesure

veut capturer.

2. OBJECTIF DE LA THÈSE

Cette thèse aborde la complexité cognitive. Le but principal de la recherche est d’établir

une nouvelle méthode de mesure de la complexité du logiciel qui quantifie la complexité

Introduction

3

à partir de la fonctionnalité du logiciel pour fournir un indice de l’effort de

développement du logiciel. Donc, elle est nommée « mesure de la complexité

fonctionnelle du logiciel ». De ce fait, ce terme n’est pas un concept à définir. Il est utilisé

pour préciser:

!" L’attribut de mesure: la complexité

!" L’objet de la mesure: le logiciel – ce qui est défini en se basant sur sa

fonctionnalité.

Comme déjà mentionné plus haut, la complexité dont on parle est la complexité cognitive

et la mesure à établir est un indice de l’effort de développement du logiciel. Le concept

d’effort de développement sera défini plus tard dans la thèse. Ici, il est compris comme le

temps en termes d’homme-mois requis pour réaliser un projet de développement ou de

maintenance du logiciel. Le temps est mesuré tout au long du processus de

développement ou de maintenance, à partir de l’identification des besoins de l’utilisateur

jusqu’à la livraison de produit.

Dans la littérature, il existe des mesures qui poursuivent le même but de mesure que cette

thèse. Ce sont les mesures de points de fonction, par exemple Function Points Analysis

(FPA) d’Albrecht [8,9], Feature Points de Jones [97], Mark-II de Symons [158], entre

autres. Ces méthodes permettent d’analyser le logiciel assez tôt dans son cycle de vie en

se basant sur sa fonctionnalité et d’établir une valeur qui s’appelle les points de fonction

du logiciel. Cette valeur est utilisée comme un indice de base pour des travaux de gestion

comme calculer la productivité (c-à-d, le nombre de points de fonction développés dans

une unité de temps par un programmeur), calculer le coût unitaire du logiciel ($/point de

fonction) et estimer l’effort (le nombre d’homme-mois) de développement du logiciel.

Bien que l’évaluation de la complexité des composants et des caractéristiques du logiciel

soit une tâche critique dans les méthodes de points de fonction, ces méthodes rencontrent

encore des problèmes majeurs dans la façon de tenir compte de la complexité. Aucune

méthode de points de fonction ne s’appuie sur un modèle explicite de la complexité. La

complexité est souvent évaluée de façon subjective (débats et essais). Il est difficile

d’appliquer ces méthodes de façon cohérente et répétable.

De plus, des publications récentes [153,2,165] sur l’utilisation de ces méthodes pour

estimer l’effort de développement du logiciel ont montré que le taux d’erreurs moyen des

estimations est encore élevé, de 40% et plus. Ceci implique que les mesures actuelles ne

reflètent pas bien la complexité qui est associée à l’effort de développement du logiciel.

Introduction

4

Ces deux limites des méthodes de points de fonction posent deux questions à étudier dans

cette thèse. C’est-à-dire que nous voulons chercher des mesures objectives basées sur

la fonctionnalité du logiciel qui permettent de mieux estimer l’effort de développent

du logiciel.

La thèse propose non seulement une nouvelle méthode de mesure de la complexité, mais

aussi une approche pour répondre à des questions fondamentales de la mesure qui

concernent la conception de la méthode de mesure et la validation de la méthode de

mesure, par exemple:

!" Quelle est la théorie sous-jacente qui guide la définition de la complexité

fonctionnelle du logiciel?

!" Est-ce que la mesure couvre les aspects importants de la complexité fonctionnelle

du logiciel?

!" Est-ce que la mesure est pertinente? Est-elle un bon indicateur de l’effort?

Nous essayons de chercher une théorie sous-jacente qui aide à étudier la complexité du

logiciel dès la phase de l’analyse et aide à répondre à ces questions. Ainsi, l’objectif

général de cette thèse est d’établir une méthode de mesure de la complexité fonctionnelle

du logiciel qui ait une base théorique solide. De plus, la nouvelle méthode doit fournir des

mesures simples et efficaces pour évaluer le niveau de complexité de la fonctionnalité du

logiciel. Donc, la mesure doit se baser sur la fonctionnalité du logiciel et fournir des bons

indices de l’effort de développement ou de maintenance du logiciel.

3. ORGANISATION DE LA THÈSE

La thèse est structurée de la façon suivante:

!" Le chapitre 1 introduit les concepts importants relatifs au sujet de recherche: le

logiciel, la mesure du logiciel, la notion de la complexité du logiciel, la

catégorisation des mesures de la complexité du logiciel, etc. Le but général de ce

chapitre est de répondre à deux questions: Qu’est-ce que la complexité? et

Qu’est-ce que la complexité du logiciel? Ces deux questions sont répondues par

la revue de la littérature qui se concentrent sur les différentes approches: les

systèmes complexes, la théorie de la computation, et le génie logiciel.

La revue de la littérature montre que deux aspects importants de la complexité

sont la taille et la structure du logiciel. De plus, la complexité de ces aspects peut

Introduction

5

être mesurée à partir du code source, de la conception et de la fonctionnalité du

logiciel. Ces dernières sont des niveaux d’abstraction différents du logiciel.

!" Le chapitre 2 présente une revue de la littérature sur les mesures de la complexité

qui se sont basées sur le code source et la conception du logiciel. Les mesures de

l’aspect « taille » sont souvent basées sur le code source, tandis que les mesures

de la complexité de la structure du logiciel sont souvent basées la structure du

code ou la conception du logiciel. La revue de la littérature vise à montrer

comment la complexité est mesurée et à quoi la complexité fait référence.

Les mesures de l’aspect « taille », comme le nombre des lignes de code [49], sont

intuitivement un indicateur de l’effort pour écrire le code. Les mesures de

l’aspect « structure », comme le nombre cyclomatique de McCabe [118], font

référence souvent à la facilité de compréhension du code. Ce facteur est considéré

comme la cause des erreurs faites par le programmeur pendant la composition du

code. De ce fait, les mesures de la complexité structurelle font référence à la

difficulté du programmeur (qui se manifeste dans le nombre d’erreurs, ou le

temps de débogage du code) et à la qualité du code ou à la qualité de la

conception. Elles ne reflètent pas directement l’effort de développement comme

les mesures de la taille, mais elles contribuent à s’accroître avec l’effort bien sûr.

Les mesures qui se basent sur le code source et la conception du logiciel ne sont

pas l’objet d’étude de cette thèse. Cependant, les idées retenues de ces mesures

sont utiles et applicables à des mesures de fonctionnalité du logiciel. Elles ont

surtout montré comment modéliser la structure du logiciel pour quantifier la

complexité structurelle d’un composant et la complexité de la relation entre les

composants.

!" Le chapitre 3 présente une revue de la littérature sur les méthodes de points de

fonction (PF). Ces méthodes correspondent à une famille des mesures qui sont

basées sur la fonctionnalité du logiciel décrite dans les spécifications. Elles sont

les plus proches de la mesure à construire dans cette thèse.

Les mesures de points de fonction sont analysées soigneusement dans ce chapitre

pour montrer ce qu’on veut mesurer et à quoi les points de fonction font

référence. En général, les points de fonction sont une valeur indiquant la

complexité des composants individuels et les caractéristiques du système entier.

Introduction

6

Ils sont une combinaison de deux aspects de la complexité du logiciel: la taille et

la complexité structurelle.

Dans ces méthodes, « la taille » fait référence au nombre de composants et au

nombre des entrées/sorties des composants. La complexité structurelle (d’un

composant) fait référence à la complexité de la manipulation interne qui est

réalisée sur les entrées pour produire les sorties du composant. Elle fait référence

aussi aux caractéristiques du logiciel concernant les relations entres les

composants dans un système, c’est-à-dire la structure du système entier.

Ce chapitre montre aussi les problèmes des méthodes de points de fonction. Cet

aspect constitue la problématique de recherche de cette thèse.

Premièrement, les méthodes de points de fonction existantes n’abordent pas

directement la complexité du logiciel. Il n’y a pas encore un modèle de la

complexité sur lequel une méthode de points de fonction est basée. Par

conséquent, les méthodes existantes ont des difficultés dans la façon d’évaluer la

complexité. Certaines méthodes proposent des façons subjectives, tandis que

d’autres ne couvrent pas suffisamment certains des aspects importants de la

complexité.

De plus, au point de vue pratique, les points de fonction ont pour but de fournir

un indice de l’effort. C’est-à-dire qu’ils sont utilisés pour estimer ou pour juger

de l’effort de développement du logiciel. Cependant, le taux d’erreurs moyen de

l’estimation d’effort est encore élevé, loin du seuil acceptable dans la pratique.

Ces limites montrent la nécessité d’une théorie sous-jacente qui aide à définir un

cadre conceptuel de la complexité et à établir des mesures efficaces dans le but

d’estimer l’effort de développement du logiciel. Elles sont à la base de la

problématique de cette thèse.

!" Le chapitre 4 introduit le modèle de la complexité de la tâche de Wood. Ce

modèle a son origine hors du domaine de la mesure du logiciel. Il provient du

domaine de la psychologie. Ce modèle est conforme aux idées philosophiques sur

la complexité représentées dans le chapitre 1, où la complexité devrait être

mesurée par le principe de la quantité d’information: plus il y a d’information,

plus c’est complexe.

Selon, le modèle de la tâche de Wood, une tâche est modélisée comme un

processus de traitement de l’information qui reçoit les informations d’entrées,

Introduction

7

puis les manipule par les actions requises pour produire les sorties de la tâche. La

complexité de la tâche est mesurée selon trois dimensions: la complexité des

composants, la complexité de coordination et la complexité dynamique. La

coordination est étudiée à deux niveaux:

o La coordination entre les entrées et les sorties.

o La coordination entre les actions requises dans la tâche.

Le logiciel peut être assimilé à une tâche que le logiciel doit accomplir. Si la

tâche est complexe, le logiciel sera complexe. De plus, au niveau de la

modélisation fonctionnelle, le logiciel est semblable à un processus de traitement

de l’information. Alors, la tâche et le logiciel font référence au même modèle.

Logiquement, la complexité du logiciel pourrait être analysée selon la complexité

de la tâche. Les mesures de la complexité de la tâche sont ensuite adaptées pour

mesurer la complexité fonctionnelle du logiciel.

!" Le chapitre 5 propose une nouvelle méthode de mesure de la complexité

fonctionnelle du logiciel. Les modèles traditionnels du logiciel sont introduits,

dont le modèle COSMIC [3]. Puis, ce dernier est modifié pour qu’il puisse

capturer plus d’aspects de la complexité, surtout la manipulation de données et la

relation entre les composants du système (c-à-d, la relation entre les processus

fonctionnels). Par la suite, le modèle modifié est mis en correspondance avec le

modèle de la tâche de Wood. Cet arrimage permet de modéliser la complexité du

logiciel d’après le modèle de la complexité de la tâche de Wood. Enfin, trois

mesures sont proposées pour capturer la complexité selon trois dimensions qui

correspondent à trois mesures de la complexité de la tâche de Wood.

!" Le chapitre 6 se concentre sur la validation de la mesure proposée dans le

chapitre 5. La validation suivra le cadre de Jacquet [93]. Le test empirique de la

méthode est réalisé en se basant sur 15 projets de maintenance du logiciel d’une

compagnie d’informatique professionnelle de la région de Montréal auxquels

nous avons eu accès. Les résultats d’investigation empirique conduisent à un

modèle d’estimation d’effort de développement du logiciel. Enfin, la performance

de prédiction de ce modèle est analysée et comparée avec des modèles

d’estimation de certaines autres mesures comme FPA et COSMIC-FFP. Ces

analyses et ces comparaisons confirment la pertinence de la nouvelle méthode

Introduction

8

ainsi que la performance du modèle d’estimation d’effort construit sur les

mesures de la nouvelle méthode.

!" La conclusion montre les contributions de la thèse et des perspectives de

recherche futures.

!" En annexe, on retrouvera le rapport de comptage des 15 projets utilisés dans le

chapitre 6 pour valider la mesure. La liste des articles publiés relatifs à cette thèse

est aussi présentée dans l’annexe.

4. PROBLÉMATIQUE DE RECHERCHE ET DÉMARCHES

L’objectif de la thèse est de proposer une nouvelle méthode de mesure de la complexité

du logiciel. Cette nouvelle méthode quantifie la complexité du logiciel à partir de la

fonctionnalité décrite dans les spécifications du logiciel. Elle fournit des indices simples

et efficaces pour l’estimation des attributs qui sont affectés par la complexité du logiciel,

par exemple l’effort de développement et le coût du logiciel.

Pourquoi faut-il proposer une nouvelle méthode? La réponse est simple: parce que les

mesures (en général) du logiciel ne satisfont pas encore les utilisateurs [180]. Au point de

vue théorique, les mesures actuelles manquent d’une base théorique qui guide la mesure.

Chaque auteur propose une mesure propre de la complexité du logiciel mais il y a très peu

d’explication sur la question de savoir « à quoi la complexité fait référence ». De plus, au

point de vue pratique, les mesures existantes qui supposent de mesurer des

caractéristiques du logiciel associées à l’effort de développement (p.ex., les méthodes de

points de fonction) ne reflètent pas très bien l’effort. Le taux d’erreurs moyen de

l’estimation avec ces méthodes est encore parfois si élevé que le seuil s’avère

inacceptable. Ces deux raisons principales motivent la recherche de nouvelles méthodes

plus solides et plus efficaces pour mesurer la complexité.

Alors, les grandes questions de la recherche concernent la conception et la validation de

la méthode. En voici quelques-unes:

!" Qu’est-ce qui doit être mesuré? C’est-à-dire, quels sont les aspects importants

de la complexité (en général) et de la complexité fonctionnelle du logiciel qui

sont associables à l’effort de développement du logiciel. La revue de la littérature

dans le chapitre 1 essaie d’expliquer ce qu’est la complexité du logiciel et ce

qu’est la complexité fonctionnelle du logiciel. Elle établit un cadre général de la

Introduction

9

complexité qui se compose de la taille des composants, la structure des

composants et la structure du système.

!" Comment mesurer la complexité du logiciel? C’est-à-dire, comment évaluer la

taille, la complexité des composants et la complexité du système? La revue de la

littérature dans les chapitres 2 et 3 montre deux approches de mesure. L’une est

basée sur le code et la conception du programme; l’autre est basée sur la

fonctionnalité du logiciel. La revue de la littérature montre aussi les points forts

et les points faibles des mesures existantes qui sont les leçons retenues pour

développer la nouvelle méthode.

Puis, le modèle de la complexité de la tâche de Wood représenté dans le chapitre

4 répond aux deux questions citées en haut. Il se conforme aussi aux idées

philosophiques introduites au chapitre 1. De ce fait, il est utilisé comme un

modèle sous-jacent (ou une théorie sous-jacente) pour la nouvelle méthode qui

est présentée au chapitre 5 de cette thèse.

!" Comment s’assurer de la validité et la pertinence de la nouvelle méthode?

Cette question est répondue dans le chapitre 6 en montrant que:

o Le processus de développement de la méthode est correct. Il suit le cadre

de développement d’une mesure du logiciel proposé par Jacquet [93].

o Les mesures sont pertinentes, c’est-à-dire qu’elles fournissent des bons

indices de l’effort et elles sont très efficaces dans l’estimation de l’effort

de développement du logiciel. Autrement dit, le taux d’erreurs de

l’estimation d’effort utilisant ces mesures est bas, acceptable dans la

pratique.

Ces trois questions seront répondues tout au long de la thèse afin de proposer une

nouvelle méthode de mesure de la complexité du logiciel qui est solide au point de vue

théorique et efficace au point de vue pratique.

CHAPITRE 1

COMPLEXITÉ ET MESURE DE LA COMPLEXITÉ DU LOGICIEL

Ce chapitre présente une revue de la littérature sur la notion de complexité, puis sur la

complexité du logiciel. Il vise à répondre aux deux questions suivantes:

!" Qu’est-ce que la complexité (en général)?

!" Qu’est-ce que la complexité du logiciel?

Tout d’abord, certains concepts utilisés dans la thèse sont clarifiés. Puis, des approches

différentes pour définir la complexité sont introduites.

La complexité du logiciel est souvent classifiée en deux catégories: computationnelle et

cognitive. La première catégorie fait référence aux ressources matérielles requises pour la

computation du programme, tandis que la deuxième catégorie fait référence à l’effort

humain requis pour réaliser une tâche sur le logiciel.

En gestion des logiciels, on intéresse à des mesures de la complexité cognitive, c’est-à-

dire, les mesures qui fournissent des indices de l’effort pour réaliser une tâche sur le

logiciel. Les mesures de ce type jouent un rôle important dans la planification de la

production et le contrôle du budget. Elles sont l’objet à étudier dans cette thèse.

La revue de la littérature dans ce chapitre montre que les deux aspects les plus souvent

traités de la complexité du logiciel sont la taille et la complexité structurelle du logiciel.

Ces deux aspects peuvent être mesurés à partir du code du programme, de la conception

du programme et de la fonctionnalité du logiciel. Les mesures de la taille du logiciel sont

intuitives relatives à l’effort, tandis que les mesures de la complexité structurelle sont

normalement associées à la qualité de la conception, à la qualité du code et à la facilité de

compréhension du programme. Ce dernier facteur affecte l’effort pour coder, tester et

déboguer le programme, et puis l’effort de développement du logiciel en général.

Complexité et mesure de la complexité du logiciel

11

1.1 CONCEPTS UTILISÉS DANS LA THÈSE

1.1.1 Logiciel

« Logiciel » est un terme général qui indique un ensemble d’instructions d’ordinateur, de

documents et de données. Ceux-ci décrivent un système de traitement de l’information

qui peut être exécuté sur un ordinateur réel. Un logiciel est non seulement constitué de

programmes (codes sources ou codes exécutables) mais aussi des documents pour décrire

le système, par exemple les spécifications de fonctionnalité du système, les contraintes de

qualité du système.

Un logiciel est conçu et construit pour une tâche ou un ensemble de tâches spécifiques,

c’est-à-dire qu’il résout un problème spécifique dans le mode réel. De ce fait, un logiciel

est encore appelé « un système », « une application ». La réalisation d’un logiciel est un

processus incluant la cueillette des besoins de l’utilisateur, l’analyse des besoins, la

définition des exigences (spécifications), la conception (design), le développement et

l’implémentation du système. Donc, le produit logiciel émerge au fur et à mesure ce

processus.

Le produit logiciel peut être considéré comme un objet abstrait qui est développé à partir

d’un énoncé des exigences pour se finaliser par le logiciel. Le produit logiciel donc

comprend tout aussi bien le code (objet ou source) que les formes diverses de documents

produits tout au long du processus de développement [128].

Quant à la définition de Boehm [30], un logiciel est un ensemble complet de programmes,

de procédures et de documents connexes associés à un système informatique.

Selon ces deux définitions, un produit logiciel se compose de tous les produits introduits

dans le processus de développement du logiciel. Elles font référence aux produits

tangibles du logiciel.

À un niveau plus abstrait, un logiciel est un ensemble des fonctionnalités livrées aux

utilisateurs [8]. Les documents tangibles (du logiciel) décrivent les fonctionnalités, tandis

que les codes les implémentent. Les produits tangibles varient selon le langage de

programmation utilisé et la façon d’écrire les spécifications du logiciel. Par contre, le

produit non-tangible du logiciel – la fonctionnalité – est invariable. Changer la

fonctionnalité d’un système conduira à un nouveau logiciel.

Dans cette thèse, la complexité du logiciel réfère à la complexité fonctionnelle du

logiciel. Elle est mesurée à partir de la fonctionnalité du logiciel. Elle indique la


12

complexité du problème (à résoudre) défini dans les spécifications du logiciel, de la tâche

ou des tâches que le logiciel doit réaliser plutôt que celle de l’algorithme ou

l’implémentation d’une solution concrète.

1.1.2 Génie logiciel

Le génie logiciel est un terme utilisé pour désigner une discipline de l’informatique qui

étudie les méthodes et les principes d’ingénierie pour développer un logiciel de qualité,

efficace et économique. Pressman [133] définit le génie logiciel comme suit:

« C’est l’établissement et l’utilisation de principes éprouvés d’ingénierie pour obtenir de

façon économique un logiciel qui est fiable et qui fonctionne efficacement sur des

machines réelles. »

Évidemment, le génie logiciel est une discipline scientifique et d’ingénierie. C’est

l’application de la science physique et des mathématiques grâce auxquelles les capacités

de l’équipement informatique sont rendues utiles à l’homme via des programmes

d’informatique, des procédures et des documents associés. Le génie logiciel comme toute

autre science doit être basé sur des mesures parce que les mesures font parties intégrantes

de la démarche scientifique.

1.1.3 Mesure du logiciel

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 de logiciel

possède un certain attribut. Dans le dictionnaire standard d’IEEE [87] le terme « mesure »

est défini comme une évaluation quantitative du degré auquel un produit logiciel ou un

processus possède un attribut.

Fenton [62] 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. Elle est une mise en correspondance entre le monde empirique (c-à-d, le monde

réel) et le monde formel (c-à-d, mathématique).

Pour certains auteurs (p.ex., Ejiogu [59], Fenton [62]), 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’un arrimage (mapping) entre

des entités et les caractéristiques sous observation.


13

Une mesure du logiciel, comme toutes les autres mesures, doit identifier l’entité et

l’attribut que l’on veut mesurer. Selon Fenton [62], l’entité d’une mesure du logiciel

peut être l’une des suivantes:

!" Processus: ce sont les activités relatives au logiciel, par exemple l’analyse, la

spécification, la conception;

!" Produits: ce sont les résultats des processus, par exemple les documents de

spécifications, l’architecture du système, le code source;

!" Ressources: ce sont les entités requises par les processus, par exemple le temps

requis pour l’analyse, les dollars du budget.

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

Une mesure peut être directe ou indirecte. La mesure directe d’un attribut d’une entité

est indépendante de mesures d’autres attributs ou 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.

1.1.4 Complexité

Le mot « complexité » est un nom formé à partir de l’adjectif « complexe » pour indiquer

la difficulté, le besoin d’un effort qui peut devenir considérable pour comprendre quelque

chose. Selon le dictionnaire Webster (Webster’s 3rd International Dictionary,

1981), « complex stresses the fact of combining or folding together with various parts

and suggests that considerable study, knowledge, or expense is needed for comprehension

or operation”. De ce fait, « complexité » est strictement un concept qualitatif avec la


14

connotation d’être compliqué et difficile. Cette définition fait appel à des idées

importantes:

!" Les sources de la complexité: les parties différentes et les relations qui existent

entre elles.

!" L’effet de la complexité sur les ressources: la complexité se manifeste dans les

ressources requises (par exemple, les connaissances, l’effort, etc.) pour la

conquérir. C’est-à-dire, elle se manifeste dans l’effort mis à comprendre un objet

ou à faire une opération sur un objet.

La complexité a été étudiée depuis longtemps avec l’approche mathématique. Cette

approche a conduit à la construction des mesures de la complexité en se basant sur la

théorie de l’information [142] et la théorie de la computation [169]. Ces travaux

mathématiques ont proposé les définitions de la complexité algorithmique ou

computationnelle de la machine de Turing ou l’entropie du système. Une mesure de la

complexité de ce type fait référence au temps requis pour exécuter un programme, à

l’ordre de grandeur du temps de calcul d’un algorithme ou à l’espace mémoire requis

pour l’exécution des calculs et l’entropie de l’information dans le système.

Par contre, en génie logiciel, la complexité (du logiciel) est interprétée différemment

selon l’objet et l’entité sous observation et la tâche à réaliser sur l’objet ou l’entité. La

complexité d’une entité est relative à la difficulté rencontrée quand on réalise une tâche

sur cette entité. Ce type de complexité est connu comme la complexité cognitive. Elle est

comprise comme le degré de la difficulté pour l’analyse, l’entretien, le test, la conception

et la modification du logiciel [180]. Une mesure de la complexité cognitive est une valeur

qui fournit un indice de l’effort humain requis pour réaliser un tel travail sur le logiciel.

En tenant compte de cette idée, dans cette thèse, la complexité du logiciel est définie

comme la difficulté de développement ou de maintenance du logiciel. De ce fait, la

complexité dont nous parlons est la complexité cognitive. Cependant, nous étudions la

complexité du logiciel dans un sens étroit – ce que nous appelons la complexité

fonctionnelle du logiciel. La complexité (fonctionnelle) du logiciel est évaluée à partir de

la fonctionnalité du logiciel et elle reflète l’effort de développement ou de maintenance

du logiciel. Le concept d’effort est précisé à la sous-section qui suit.


15

1.1.5 Effort de développement du logiciel

L’effort de développement indique les ressources humaines requises pour réaliser les

activités tout au long du processus de développement du logiciel. Ce processus

commence par l’acquisition des besoins (exigences) de l’utilisateur, l’analyse des

exigences, et se poursuit par la conception du logiciel, le codage, le test, l’intégration des

composants, l’installation et les tests d’acceptation. Alors, l’effort de développement du

logiciel est compris comme le temps total (heures de travail) de tous les membres de

l’équipe désignée pour le projet.

Il est évident que l’unité de temps n’est pas importante. Dans cette thèse, l’effort de

développement est compté par le nombre d’hommes-mois plutôt que la somme d’heures

de travail. La raison est que l’unité homme-mois est souvent utilisée dans la gestion du

projet plutôt que l’heure. Si nécessaire, une conversion simple entre ces deux unités

pourrait être établie.

Dans cette thèse, l’effort de développement est encore utilisé pour désigner le nombre

d’hommes-mois requis pour développer des nouvelles fonctions ou pour mettre à jour les

fonctions existantes dans un système à maintenir. Dans ce cas, l’effort de développement

indique l’effort pour ajouter des nouvelles fonctionnalités à un logiciel existant. Il

représente le temps relatif aux travaux de maintenance pour créer des nouvelles

fonctionnalités du logiciel.

1.2 DÉFINITIONS DE LA COMPLEXITÉ

1.2.1 Approche des systèmes complexes

Il n’existe pas de théorie de la complexité en propre bien qu’il existe une riche pensée sur

la complexité dont un grand nombre d’idées est basé sur la notion de « système

complexe ». Qu'est-ce qu'un système complexe? «Il s'agit d'un tout composé de parties,

mais dont la somme des parties n'équivaut pas au tout» [81]. Par exemple, aucune des

parties d'un ordinateur n'est capable de transférer un fichier, mais l’ordinateur (le système

entier) peut. Cette capacité est propre au tout et non à la partie. La théorie des systèmes

“Software entities are more complex for their size than perhaps any other human construct because no two parts are alike.” (Brooks, 1987)


16

généraux (dont Bertalanffy [26] et Ashby [11] sont les fondateurs) met l'emphase sur les

propriétés de ce tout plutôt que de le réduire à celles des parties.

La théorie des systèmes complexes propose une vue holistique des systèmes.

Contrairement au réductionnisme, l’analyse holistique tente de comprendre la mécanique

des systèmes en mettant l’emphase sur les entités qui les composent et, surtout, sur les

relations qui existent entre les entités. Chacune des entités a un rôle simple à jouer et

contribue au fonctionnement global du système. Le système forme un tout cohérent dont

la dynamique est intimement liée à la dynamique de ses entités et ne peut être comprise

sans y référer.

1.2.1.1 Caractéristiques des systèmes complexes Un système complexe peut être défini comme «un tout cohérent dont les éléments et leurs

interactions génèrent des structures nouvelles et surprenantes qui ne peuvent pas être

définies a priori» [22]. La complexité du système provient des propriétés suivantes: la

quantité et la diversité des éléments qui le composent, la non-linéarité, l’émergence,

l’auto-organisation et l’imprévisibilité. Ces caractéristiques sont expliquées en détail dans

les paragraphes qui suivent:

Tout d’abord, les systèmes complexes comptent un nombre important de composants

hétérogènes identifiables. Deuxièmement, les relations entre ces entités sont très souvent

non-linéaires. C’est-à-dire qu’elles ne peuvent s’exprimer par un simple facteur de

proportionnalité. Ainsi, une faible variation d’une entité A peut produire une variation

extrême de l’entité B à laquelle elle est liée. L’évolution du système est traduite par une

très forte sensibilité aux conditions initiales. Une légère perturbation de l’état initial du

système peut le faire diverger hors de sa trajectoire habituelle. Le logiciel est tout à fait un

système complexe. Il possède ces caractéristiques parce qu’il se compose d’un grand

nombre de composants (c-à-d, les modules, les fonctions) qui jouent des rôles différents

dans le système entier. Ces composants ont des relations intimes et des effets de l’un sur

l’autre. Une perturbation ou une erreur dans un composant affecte la fonctionnalité

d’autres composants et le comportement du système entier.

La propriété d’émergence réfère à l’apparition inattendue de patrons spatiaux et temporels

dans la dynamique et la structure du système [129]. L’émergence est fonction de la

synergie d’un système. En effet, le comportement global d’un système complexe ne peut

être compris par la somme simple des comportements individuels des entités qui le

composent. L’auto-organisation, quant à elle, est le mécanisme responsable de


17

l’émergence. Elle est le processus par lequel l’effet collectif des interactions locales entre

les entités du système forme une structure et un comportement ordonnés émanant au

niveau global [129]. L’auto-organisation peut aussi être expliquée comme une

collaboration entre les entités du système qui modifient leur structure interne dans le but

d’améliorer la viabilité et l’efficacité du système entier [115].

Finalement, la multitude et la disparité des entités du système en combinaison avec les

propriétés d’auto-organisation, d’émergence et de non-linéarité, produisent un

comportement global qui ne peut être anticipé. Ce système modifie ses échanges

d’énergie ou information et adapte ses interactions avec son environnement. Les relations

entre ses composants sont donc en constante évolution; de nouvelles entités sont créées et

d’autres se transforment. Ceci produit des changements inattendus dans la dynamique du

système qui échappe à tout équilibre et stabilité. Il a été remarqué par plusieurs

chercheurs que ces systèmes, malgré leur comportement évolutif, demeurent toujours

cohérents [83]. Ils se situent à la frontière du chaos. La nature imprévisible des systèmes

complexes est la raison pour laquelle leur évolution ne peut être prédite ni contrôlée

comme l’aurait voulu la science traditionnelle déterministe. Ces caractéristiques sont

associées aux systèmes biologiques et font référence à l’évolution du système. Certains

types de logiciel, par exemple les systèmes multi-agents adaptatifs, possèdent ces

caractéristiques. Cependant, nous ne nous intéressons pas beaucoup à un type spécifique

de logiciel, ce qui implique que ces caractéristiques sont donc loin des préoccupations de

notre thèse.

1.2.1.2 Complexité du point de vue des systèmes complexes Selon Morin [123], à première vue, « la complexité est un phénomène quantitatif,

l’extrême quantité d’interactions et d’interférences entre un très grand nombre d’unités».

Mais, la complexité ne comprend pas seulement des quantités et interactions qui défient

nos possibilités de calcul; elle comprend aussi des incertitudes, des indéterminations, des

phénomènes aléatoires. La complexité, dans ce sens, a aussi affaire avec le hasard [123].

La complexité n’est pas une propriété facilement quantifiable. Comment affirmer, par

exemple, qu’un système soit plus complexe qu’un autre? Les recherches sur la complexité

tentent de définir une mesure de la complexité qui soit réaliste, efficace et qui puisse

s’adapter facilement à divers domaines d’étude. Par exemple, Ashby [11] propose que la

complexité soit mesurée en se basant sur la quantité d’information requise pour décrire un

objet.


18

Il n’existe pas à ce jour de définition de la complexité qui rallie l’ensemble des

chercheurs oeuvrant dans ce domaine. Ceci n’est pas une conséquence de la jeunesse de

ce champ d’étude mais est principalement dû aux caractéristiques multidisciplinaires du

domaine. Chaque domaine scientifique étudie les systèmes complexes avec ses outils et

ses prérogatives de sorte que des définitions propres à plusieurs disciplines variées ont été

formulées. De ce fait, les méthodes pour caractériser la complexité (qualitative ou

quantitative) sont nombreuses. Herbert A. Simon [149] a classifié les méthodes pour

évaluer la complexité des systèmes en quatre catégories basées sur ce qui est utilisé pour

caractériser la complexité:

!" Les systèmes qui ont beaucoup de composants peuvent être considérés comme

complexes par rapport aux systèmes qui en ont peu. Ainsi, la cardinalité d’un

ensemble peut être prise comme une mesure de sa complexité. La complexité fait

alors référence à la taille (c-à-d, le nombre de composants) du système.

!" Les systèmes dans lesquels il y a beaucoup d’interdépendances entre les

composants sont généralement considérés plus complexes que les systèmes ayant

moins d’interdépendances entre les composants. La complexité donc fait

référence à l’interdépendance entre les composants. Alors, la complexité est

associée à la structure du système.

!" Les systèmes dont le comportement est considéré comme « indécidable » peuvent

être considérés comme complexes en les comparant à ceux dont le comportement

est déterminable. Dans cette catégorie, la complexité fait référence au

comportement dynamique et à la facilité de détermination du comportement du

système.

La dernière classe contient des méthodes de mesure se basant sur l’information du

système. La complexité est mesurée par une mesure de l’entropie qui reflète la quantité

d’information du système et le degré d’organisation du système. Un système avec une

entropie élevée est plus riche d’information qu’un système avec une basse entropie, c’est-

à-dire qu’on a plus de difficulté à déterminer le comportement du système.

La complexité mentionnée dans les travaux de Simon réfère principalement à

l’interdépendance des composants. Il ne parle pas beaucoup d’autres types de complexité.

Selon lui [150], un système complexe est un système quasi-décomposable, hiérarchique

(arborescent). Celui-ci peut être considéré comme un ensemble de sous-systèmes. Chaque

sous-système, à son tour, peut être décomposé en sous-systèmes. L’arborescence évolue


19

jusqu’au niveau détaillé où les sous-systèmes se composent d’éléments de base. Alors, on

peut distinguer:

!" la complexité de l’interaction entre les sous-systèmes (p.ex., la complexité inter-

modules ), et

!" la complexité de l’interaction interne entre les éléments d’un sous-système (p.ex.,

la complexité intra-module).

Simon a aussi précisé que le but de décomposer un système est de réduire la complexité

du système. De plus, le principe pour segmenter un système en sous-systèmes est de

minimiser l’information échangée entre les sous systèmes et entre les éléments.

Autrement dit, la complexité de l’interaction pourrait être mesurée en se basant sur la

quantité d’information échangée dans le système.

1.2.1.3 Complexité des programmes Parmi les idées philosophiques citées dans les paragraphes ci-dessus, les idées de Simon

sont plus proches des expériences faites dans le domaine informatique. Simon étudie la

complexité du logiciel au niveau du programme. Selon lui, les grands programmes

d’ordinateur sont eux-mêmes des structures complexes. En fait, le développement d’un

logiciel n’est pas seulement la composition du code, mais un processus bien défini et

suivi comportant certains principes d’analyse, d’allocation fonctionnelle et de

décomposition. Ces principes sont connus comme « la programmation structurée » ou

« les principes de modularité ». Ils permettent de structurer le programme en une structure

hiérarchique de sous-programmes et modules. Chaque module dans un programme bien

structuré peut être caractérisé par:

!" Les intrants qu’il demande

!" Les extrants qu’il produit et

!" Les transformations qu’il opère sur les intrants.

Simon ne propose aucune mesure pour la complexité du programme. Ses travaux

[149,150] vise à montrer qu’un programme d’ordinateur est un système complexe, quasi-

décomposable. Il montre aussi que la complexité du programme provient des intrants,

extrants et des transformations. Cette idée répond à la question « qu’est-ce qu’il faut

mesurer pour quantifier la complexité? » et propose une modélisation d’un système

complexe pour maîtriser la complexité.


20

1.2.1.4 Idées retenues de la philosophie des systèmes complexes Selon l’idée de Brooks [34], le logiciel peut être considéré comme un produit complexe.

Ensuite, les idées philosophiques d’Ashby et de Simon introduites plus haut répondent

aux questions suivantes:

!" Quelle est la source de la complexité?

!" Qu’est-ce qu’on doit mesurer pour quantifier la complexité?

Dans un système complexe, les interactions entre les composants et entre les éléments

sont des caractéristiques importantes [123]. La modélisation devrait être capable de les

capturer et les représenter. Les interactions peuvent être caractérisées par l’information

échangée entre les composants [11,150]. Donc, une réponse à la première question est

que la complexité vient des interactions entre les composants et qu’elle peut être

mesurée à partir de l’information échangée par ceux-ci dans le système.

Les travaux de Simon ont montré que la modularité est applicable aux programmes

d’ordinateur. Un programme peut être structuré en une hiérarchie de modules. Chaque

module est caractérisé par ses intrants, extrants et ses transformations. Autrement dit,

Simon a montré une façon de modéliser le programme pour maîtriser la complexité.

Pour la deuxième question, la réponse générale d’Ashby est de « mesurer

l’information » [11]. L’information dans le sens d’Ashby est l’information pour décrire

le système, y compris la description de chaque composant et les relations entre eux.

Cependant, Ashby ne propose aucune mesure explicite de la complexité. Le concept

« d’information » n’est pas bien défini dans les travaux d’Ashby, mais on peut trouver

certaines explications de ce concept dans les travaux de Simon [149,150]. Selon lui, les

informations pour décrire un composant sont les intrants, les extrants et les

transformations. De plus, il considère que les intrants et les extrants de tous les modules

dans le système sont des informations échangées entre les composants (modules).

Les idées d’Ashby et de Simon proposent une première vision de la complexité dans

laquelle elle se compose de la complexité des composants individuels et de la complexité

du système. De plus, la complexité est mesurée sur le principe de la quantité

d’information. La complexité d’un composant individuel est caractérisée par les intrants,

les extrants et les transformations (c-à-d, manipulations) opérées sur les intrants pour

produire les extrants, tandis que la complexité du système est caractérisée par les

échanges d’informations entre les composants.


21

1.2.2 Approche computationnelle

La complexité computationnelle origine de travaux mathématiques. Elle est construite en

se basant sur la théorie de l’information [142] et la théorie de la computation [169]. La

théorie de l’information définit la complexité en terme d’entropie d’information. Celle-ci

est une mesure de la « structuralité » et de « l’aléatoirité » d’un système. La théorie de la

computation et les techniques d’analyse de l’efficacité de l’algorithme définissent la

complexité du programme en terme du temps et de l’espace mémoire requis pour

l’exécution des calculs. Elle est une mesure de l’efficacité des algorithmes utilisés pour

implémenter un programme. Une mesure de la complexité computationnelle est une

valeur qui indique le niveau de ressources matérielles requises de la machine pour

exécuter un programme.

1.2.2.1 Entropie d’information En 1949, Shannon reprend les notions de thermodynamique statistique et les applique au

stockage et à la transmission d’information. Il considère que l’information mesure le

degré d’organisation d’un système, alors que l’entropie en mesure le caractère organisé

ou aléatoire, le niveau de désordre possible. Prenant en compte les notions statistiques, la

richesse en information est caractérisée par l’existence d’un état peu probable. C’est-à-

dire que l’information associée à un caractère X est élevée si sa probabilité d’apparition

est faible. Donc, le taux d’information est défini en nombre de bits:

I(x=X) = - log (P(x=X)).

De plus, le débit d’information d’un canal véhiculant de l’information est la somme des

sorties possibles:

H(x) = - # P(x=Xk)log(P(x=Xk)), où Xk est un caractère à la sortie.

H(x) est appelé l’entropie de l’information du canal et elle représente le nombre de bits

permettant de décrire la sortie. Selon la théorie de l’information, l’entropie est une mesure

de la complexité du canal de l’information. Un canal de plus haute entropie est plus riche

en information, c’est-à-dire qu’il est plus difficile de deviner ce qui sera obtenue à la

sortie.

1.2.2.2 Complexité algorithmique de Kolmogorov Historiquement, en 1960, Solomonoff a inventé la notion de la complexité algorithmique

de l’information. Il estime que la quantité absolue d’information d’une chaîne de


22

caractères est la taille en bits du plus petit algorithme qui est capable de la générer. Puis,

en 1965, Kolmogorov et Chaitin réinventèrent cette notion.

Kolmogorov a défini la complexité d’un objet comme la longueur minimale possible pour

le décrire en utilisant un langage. Le langage utilisé par Kolmogorov [109,44] est la

machine de Turing. La complexité de Kolmogorov, notée par K(x), d’un objet x est la

longueur (en bits) du plus court programme qui peut être exécuté par une machine

universelle de Turing pour produire x et ensuite s’arrêter.

Formellement:

K(x) = min (|mi(x)|), où mi(x) est une machine de Turing qui produit x comme sa

sortie et s’arrête.

Cette définition propose non seulement l’approche algorithmique de la complexité mais

aussi une mesure de la complexité. La complexité fait référence à la taille du programme

(en bits) et elle capture le débit d’information d’une expression plutôt que la difficulté de

l’expression. Ce type de complexité tient compte du caractère aléatoire (randomness)

d’une chaîne de caractères. Grosso modo, si un objet peut être décrit par une courte

description, le degré de sa complexité est bas.

La complexité de Kolmogorov ne capture pas la complexité structurelle de l’objet. Un

objet avec une structure régulière (qui peut être présentée par une formule) a une

description plus courte qu’un objet aléatoire qui ne peut être décrit que par l’exposition de

l’objet lui-même. Alors, une séquence aléatoire de lettres est plus complexe qu’une

poésie bien composée [24]! La complexité de Kolmogorov fait référence à la taille du

programme: un programme plus long est plus complexe. Elle ne reflète pas la complexité

structurelle et computationnelle qui se manifestent dans le temps d’exécution d’un

programme.

1.2.2.3 Complexité computationnelle de Bennett Bennett propose de faire la distinction entre la complexité aléatoire de Kolmogorov et la

complexité organisée – ce qu’il appelle la profondeur logique. La complexité organisée

tend à mesurer le niveau d’organisation d’un système et à cerner ce qui fait la différence

entre un objet complexe et un objet simple. La définition de la complexité de Bennett

(c-à-d, la profondeur logique) ne réside pas dans la taille de la description de l’objet. Elle

réside dans le temps de calcul d’un algorithme chargé de reconstruire l’objet à partir de sa

description effective, soit:


23

Profondeur logique = Temps de calcul de l'algorithme minimal décrivant l'objet

En d’autres termes, un objet est complexe parce que sa construction demande un temps

important et un nombre d’opérations importantes à accomplir. Le temps de calcul est

défini en se basant sur le nombre de transitions de la machine de Turing qui réalise

l’algorithme le plus effectif pour produire l’objet.

La profondeur logique de Bennett capture la complexité dérivée de la structure du

programme. L’idée de Bennett est basée sur le fait que le nombre $ rend une petite

complexité algorithmique (Kolmogorov) parce qu’il est bien défini mathématiquement.

Cependant, sa complexité computationnelle est grande parce qu’il requiert un temps

considérable pour le calculer avec une haute précision. Ce type de complexité est associé

aux « boucles » au lieu de la « longueur » du programme.

1.2.2.4 Complexité computationnelle avec la notion « O » Dans la science informatique [7], le temps et l’espace mémoire requis pour exécuter un

programme sont des mesures très utiles. Celles-ci sont des mesures quantitatives pour

juger si un programme ou un algorithme est réalisable dans la pratique. Ces mesures

fournissent des indices des ressources matérielles requises pour réaliser un programme

avec une entrée de taille n. Elles mesurent l’ordre de grandeur du temps ou de l’espace

mémoire requis dans le pire cas. Par exemple, la recherche séquentielle d’un élément x

dans une liste de n éléments requiert n comparaisons dans le pire cas, donc l’ordre

grandeur du temps pour exécuter un programme implémentant une telle recherche dépend

linéairement de n, et est noté par O(n).

La complexité de Bennett mesure le nombre d’étapes nécessaires à une machine de

Turing pour produire une sortie particulière. La complexité computationnelle avec la

notion « O » mesure le nombre d’opérations élémentaires nécessaires pour manipuler une

entrée de taille n dans le pire cas. La complexité avec la notion « O » tient compte des

étapes logiques de l’algorithme du programme plutôt que du nombre exact des opérations

dans le programme. Elle peut donc être calculée dès la phase de conception de

l’algorithme du programme. Elle est aussi indépendante de la machine et du langage de

programmation. Similaire à la mesure de Bennett, la complexité avec la notion « O » est

associée à la structure du programme, c’est-à-dire, aux « boucles d’itérations » que l’on

retrouve dans le programme.


24

1.2.2.5 Sommaire de la complexité computationnelle Les définitions de la complexité selon le volet computationnel introduites plus haut ont

montré des aspects importants de la complexité:

!" La définition de Shannon fait référence à l’information du système. Plus il y a

d’information dans système, plus le système est complexe, donc une notion de

quantité d’information.

!" La définition de Kolmogorov met l’emphase sur la taille de description de

l’objet. Un objet de taille plus long est plus complexe, donc une notion de

longueur et de diversité de l’information.

!" La définition de Bennett se concentre sur la complexité organisée de l’objet. Elle

fait référence à la structure de l’objet.

!" La complexité computationnelle avec la notion « O » se concentre aussi sur la

structure du programme. Elle est une mesure de l’efficacité de l’algorithme du

programme.

Les trois premières mesures définissent la complexité d’un objet général, dont le logiciel.

La complexité avec la notion « O » est conçue pour mesurer la complexité

computationnelle du programme. De ce fait, en génie logiciel, le terme « mesure de la

complexité computationnelle » fait toujours référence à cette mesure.

Cette thèse n’investigue pas davantage la complexité computationnelle. Elle se concentre

sur la complexité cognitive. Désormais, le terme « la complexité du logiciel » désignera

la complexité cognitive du logiciel. Elle fait référence à la difficulté et à l’effort pour

comprendre le logiciel ou réaliser une tâche sur le logiciel. Elle se reflète donc dans

l’effort de développement ou de maintenance du logiciel.

1.3 COMPLEXITÉ DU LOGICIEL

1.3.1 Notion de la complexité du logiciel

En génie logiciel, et surtout, dans le domaine de la mesure du logiciel, la complexité du

logiciel fait référence à la complexité cognitive. Ce type de complexité diffère totalement

de la complexité algorithmique ou computationnelle. La complexité algorithmique ou

computationnelle tient compte des dépenses de ressources « matérielles » comme le

temps d’exécution ou l’espace mémoire. La complexité cognitive est associée à la

difficulté rencontrée par l’individu qui réalise une tâche sur le logiciel, par exemple la


25

difficulté pour coder ou pour comprendre le code source du programme, ou la difficulté

de l’analyse ou de la conception du logiciel. La complexité cognitive fait référence aux

ressources « mentales » plutôt qu’aux ressources « matérielles». De ce fait, la complexité

cognitive est ce qui se manifeste dans l’effort humain requis pour faire une tâche sur le

logiciel.

Exemple: lire les deux morceaux de code suivants:

P 1: 100: i=1 200: IF i >100 GOTO 600 300: PRINT (i*i) 400: i=i+1 500: GOTO 200 600: END

P2: FOR i=1 TO 100 DO PRINT(i*i)

Il est évident que P1 et P2 implémente la même fonction (imprimer le carré des nombres

de 1 à 100). Les deux morceaux de code représentent le même algorithme. Le temps

requis pour les exécuter est le même. Cela signifie que la complexité computationnelle est

identique. Cependant, la difficulté de lire, de comprendre et d’écrire ces pièces de code

est différente. P1 est plus difficile à comprendre que P2. Et, à cause de cette difficulté, le

temps pour coder, tester et déboguer P1 est différent de celui pour P2. La complexité

cognitive fait référence à un tel phénomène. Elle se manifeste particulièrement lors de

l’écriture du code, lors de la conception du logiciel et aussi lors du développement des

spécifications et exigences du logiciel. La question est de savoir comment on peut la

quantifier au début d’un projet du logiciel?

1.3.2 Définitions de la complexité du logiciel

Bien qu’il y ait plusieurs mesures dites mesures « la complexité du logiciel », ce concept

n’est pas encore bien défini. Evangelisti [60] a écrit que « le terme de la 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 ».

“Complexity denotes the degree of mental effort required for comprehension.”

(Sullivan, 1975)


26

Dans la littérature, on peut trouver quelques définitions de points de vue similaires.

La définition de Curtis [51] insiste sur les caractéristiques du logiciel qui font appel aux

ressources nécessaires d’un autre système lorsque celui-ci interagit avec le logiciel:

“Software complexity is a characteristic of the software interface which

influences the resources another system will expend while interacting

with the software.”

Henderson-Sellers [80] propose une définition dans laquelle l’accent est mis sur les

caractéristiques du logiciel qui affectent le niveau de ressources de la personne pour

réaliser une tâche:

“The cognitive complexity of software refers to those characteristics of

software that affect the level of resources used by a person performing a

given task on it.”

Basili [18] définit la complexité du logiciel comme une mesure de ressources dépensées

par un système (humain ou autre) quand celui-ci interagit avec une pièce du logiciel:

“Software complexity is a measure of resources expended by a system

[human or other] while interacting with a piece of software.”

Le consensus à partir de ces définitions est que, d’une part, la complexité du logiciel est

un attribut intrinsèque basé sur les caractéristiques du logiciel. D’autre part, elle a un

effet sur les ressources requises (p.ex., l’effort) pour réaliser une tâche sur le logiciel.

Donc, pour mesurer la complexité du logiciel il est nécessaire de quantifier les

caractéristiques intrinsèques du logiciel pour déterminer le niveau de ressources requis

pour réaliser une tâche sur le logiciel.

Conceptuellement, on n’a pas une définition qui soit mesurable de la complexité

cognitive. Ce concept est utilisé pour indiquer la difficulté de comprendre un problème ou

un objet. Jones [96] considère la complexité comme la difficulté du problème auquel

l’équipe de développement fait face. Le vrai sens de la complexité fait toujours référence

au niveau d’effort requis pour la compréhension ou la réalisation d’une tâche. De ce fait,

la complexité cognitive n’est pas mesurable directement, mais elle est observable et

pourrait être évaluée par certaines mesures appropriées associées comme le temps de

réalisation d’une tâche ou le nombre d’erreurs faites pendant la réalisation d’une tâche.

Par conséquent, une mesure supposée mesurer la complexité cognitive devrait fournir des

indices cohérents avec les mesures observables de la complexité.


27

Dans notre recherche, l’effort de développement du logiciel est considéré comme une

mesure observable de la complexité. Alors, la condition a priori pour une mesure

pertinente de la complexité du logiciel est qu’elle soit un indicateur de l’effort requis pour

réaliser une tâche sur le logiciel. Généralement, la tâche à réaliser pourrait être une tâche

générale comme le développement du logiciel ou la maintenance du logiciel. Elle pourrait

être une tâche spécifique comme le test, le codage ou le débogage d’un programme ou un

module. Cependant, nous ne nous intéressons pas à une tâche spécifique. Ce que nous

voulons faire est de chercher une mesure (à partir de la fonctionnalité du logiciel) qui

fournit un indice de l’effort de développement ou de maintenance du logiciel.

1.3.3 Deux aspects de la complexité du logiciel

À ce jour, il existe déjà plusieurs mesures de la complexité dans la littérature du génie

logiciel (voir [43,62,80,180]). Chaque mesure concerne un ou plusieurs aspects de la

complexité. Les deux aspects ayant le plus de références à ce concept sont la taille et la

structure du logiciel (à un certain niveau d’abstraction) [62,80]. Ces deux aspects sont

vus comme ayant un grand effet sur l’effort de développement du logiciel.

!" La taille fait référence à la taille du programme (p.ex., les lignes de code) ou la

taille fonctionnelle (p.ex., les points de fonction). La taille du produit à

développer est souvent utilisée comme un indice de l’effort requis pour

développer le produit. Cependant, la taille ne reflète pas très bien la complexité.

L’expérience de développement des logiciels a permis de constater que pour des

modules de même taille, le niveau de difficulté rencontré pour les développer

peut être différent. Un module peut être plus difficile qu’une autre de même taille

à cause de sa structure interne. Donc, la complexité de la structure du logiciel

doit être étudiée.

!" La complexité de la structure du logiciel est interprétée via la complexité de la

structure déterminée à la conception du logiciel ou de la structure du code.

Les mesures de la taille du logiciel, par exemple, les lignes de code [49], les points de

fonction [8], font souvent référence à l’effort pour développer le logiciel. Il existe des

modèles d’estimation d’effort à partir de ces mesures, par exemple le modèle de

COCOMO [30,31], le modèle d’Albrecht et Gaffney [9]. Par contre, les mesures de la

structure du logiciel comme le couplage et la cohésion [179] et le nombre cyclomatique


28

de McCabe [118] sont souvent utilisées pour évaluer la qualité de la conception et estimer

le nombre d’erreurs potentielles du code.

La structure du logiciel peut être modélisée comme la structure intra-module et la

structure inter-modules. Une mesure de la complexité structurelle du logiciel est souvent

associée à la facilité de comprendre le logiciel. Elle reflète la difficulté de coder, de tester

et de déboguer le programme. Ces difficultés affectent la performance de l’individu qui

travaille sur le logiciel, et par conséquent, l’effort de développement. De ce fait, la

relation entre la complexité structurelle du logiciel et l’effort de développement est

évidente. 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 l’effort. En fait, un

programme de 300 lignes de code avec une structure simple (p.ex., séquentielle) pourrait

demander plus d’effort à coder qu’un programme de 20 lignes de code avec une structure

plus complexe. Cela explique pourquoi les mesures de la complexité structurelle sont

souvent considérées comme les vraies mesures de la complexité, mais aucun modèle

d’estimation d’effort n’est construit en se basant sur une mesure de la complexité

structurelle.

1.3.4 Catégorisations des mesures de la complexité du logiciel

Comme il a déjà été dit, le logiciel est un produit complexe. Il peut être considéré comme

un ensemble de produits tangibles ainsi qu’un ensemble des produits non-tangibles. Le

produit logiciel émerge au fur et à mesure du processus de développement du logiciel.

Une mesure du logiciel doit être associée à un niveau d’abstraction du logiciel. Par

conséquent, on peut trouver des mesures qui sont basées sur un niveau graduellement plus

élevé d’abstraction:

!" Le code source du programme;

!" La conception du logiciel ou du système;

!" La fonctionnalité du logiciel décrite dans les documents de spécification et

exigences du système.


29

Le tableau 2.1 illustre des mesures typiques pour chaque catégorie.

Catégorie Mesure Référence à Description de la mesure

Lignes de code (LOC) [49]

Taille du code, puis l’effort pour écrire le code

Compter le nombre de lignes de code (non vide et non commentaire) du programme.

Science du logiciel de Halstead [76]

Taille du code, puis l’effort pour écrire le code

Quatre indices de base sont:

!" le nombre d’opérateurs

!" le nombre d’opérandes

!" le nombre d’opérateurs uniques

!" le nombre d’opérandes uniques

Les autres mesures de Halstead (p.ex., le volume, la difficulté, l’effort) sont basées sur ces quatre mesures.

McCabe [118] Structure du code, puis la compréhensibilité du code

La mesure capture le nombre de branchements ou le nombre de nœuds de décision dans le code.

La mesure est applicable aussi à la conception du programme.

CODE

Entropie [54] Structure du code, puis la compréhensibilité du code

La structure du code est modélisée par un graphe de flux de données / de contrôle. Puis, la mesure d’entropie est appliquée.

CONCEPTION DU LOGICIEL

Fan-in et

fan-out [79]

Structure du module, puis la complexité du système.

Complexité = length*(fan_in + fan_out)2

Où: Fan_in et Fan_out est la somme de fan-in et de fan-out de tous les modules du programme.

(fan-in d’un module est le nombre de modules qui appelle un module; fan-out d’un module est le nombre de modules appelés par un module).


30

Couplage et Cohésion [179]

Structure du module et structure du système

(pas de mesure quantitative)

Points de fonction (FPA) [8,9]

Taille, structure, puis effort de développement du logiciel.

Identifier et assigner (subjectivement) les poids de la complexité aux fonctions fournies à l’utilisateur.

La somme totale des poids de fonction indique le nombre de fonctions offertes à l’utilisateur. Il est un indice de l’effort de développement.

MARK-II [158] Comme FPA Une variation de FPA qui permet de compter objectivement les points de fonction des transactions.

FONCTIONNALITÉ DU LOGICIEL

Autres: ASSET-R [137], Points de Fonction 3D [175], COSMIC-FFP [3].

Tableau 2.1: Exemple des mesures de la complexité du logiciel.

Une mesure de la complexité du logiciel est relative à une certaine forme du logiciel,

donc on parle de la complexité du code, de la complexité de la structure du code, de la

complexité fonctionnelle du logiciel, etc. Ces termes ne sont pas quelques choses à

définir. Ils sont utilisés pour préciser sur quoi la mesure est basée. L’essentiel est qu’une

mesure de la complexité du logiciel propose une méthode qui permet de quantifier des

caractéristiques du logiciel pour évaluer le niveau d’effort requis pour faire une tâche sur

le logiciel.

Dans cette thèse, le terme « la complexité fonctionnelle du logiciel » est désigné pour

référer à la complexité qui est évaluée à partir de la fonctionnalité du logiciel. Elle est un

indicateur de l’effort de développement du logiciel. Il faut noter que la complexité

fonctionnelle du logiciel n’est pas une mesure de l’effort. Elle n’est qu’une valeur

exploitable pour indiquer ou estimer l’effort.

Dans le chapitre 2, une revue de la littérature sur des mesures qui sont basées sur le code

source et la conception du logiciel est faite. Puis, le chapitre 3 est réservé à une revue de

la littérature sur les méthodes de points de fonction. À partir de ces revues de la

littérature, les questions de recherche sont établies. Puis elles sont répondues dans les

chapitres suivants.


31

1.4 RÉSUMÉ

Ce chapitre clarifie le concept de la « complexité du logiciel » de points de vue différents:

philosophique, algorithmique – computationnelle, et cognitive. Dans le volet

computationnel, la complexité du logiciel fait référence aux ressources requises pour

exécuter le programme. Par contre, dans le volet cognitif, la complexité fait référence à

l’effort pour comprendre ou faire une tâche sur le logiciel. Ces deux volets conduisent à

deux catégories de complexité: computationnelle et cognitive. Chacune fait référence à

une chose différente. La complexité computationnelle caractérise l’effort de calcul de la

machine tandis que la complexité cognitive reflète la difficulté à laquelle un individu fait

face quand il travaille sur le logiciel.

Le logiciel est un produit complexe et très riche de niveaux d’abstraction. Donc les

mesures du logiciel sont souvent associées à une modélisation du logiciel. La façon

commune pour mesurer la complexité est de faire la mesure des caractéristiques internes

du logiciel. Une mesure de la complexité du logiciel est une valeur qui pourrait être

dérivée du code, de la conception et de la fonctionnalité du logiciel. De ce fait, nous

utilisons le terme « la complexité fonctionnelle du logiciel » pour indiquer la complexité

qui est évaluée à partir de la fonctionnalité du logiciel. Elle fournit une valeur associée à

l’effort de développement du logiciel.

Ce chapitre se concentre sur le concept de complexité. Il essaie aussi de montrer les

aspects importants de ce concept. C’est-à-dire qu’il essaie de répondre à la question

« qu’est-ce qui doit être mesuré? ». Les idées philosophiques et les définitions dans ce

chapitre ont donné des réponses à cette question:

!" La complexité découle de la complexité des composants individuels et de la

complexité du système (c-à-d, la relation/l’interdépendance entre les

composants).

!" L’interdépendance peut être mesurée selon le principe de la quantité

d’information.

!" La taille et la structure sont deux aspects les plus référencés de la complexité.

Ces trois idées constituent un cadre préliminaire pour cette recherche et elles seront

retenues dans la nouvelle méthode proposée dans cette thèse.

La question de savoir comment mesurer la complexité n’est pas été abordée dans ce

chapitre. Elle est le sujet des chapitres 2 et 3.

CHAPITRE 2

MESURES BASÉES SUR LE CODE SOURCE ET LA CONCEPTION DU PROGRAMME

La revue de la littérature dans le chapitre précédent a montré des approches différentes

pour définir la complexité et la complexité du logiciel. En génie logiciel, les mesures de

la complexité sont établies pour capturer la difficulté à laquelle un individu fait face

quand il réalise une tâche sur le logiciel. Deux aspects les plus référencés de la

complexité sont la taille et la structure du logiciel. La complexité peut être mesurée à

partir du code source, de la conception et de la fonctionnalité du logiciel qui est décrite

dans les spécifications faites à l’analyse.

Ce chapitre présente une revue de la littérature sur les méthodes de mesure basées sur le

code source et la conception du programme. Il a pour but de répondre à la question

« comment mesure-t-on la complexité du logiciel? ». Les mesures introduites dans ce

chapitre concernent les deux aspects de la complexité: 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é via le temps 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 au nombre d’erreurs du code, à 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.

2.1 MESURES DE LA TAILLE DU PROGRAMME

2.1.1 Mesure de lignes de code

La mesure la plus simple en génie logiciel pourrait être la mesure de lignes de code

(LOC). Cette mesure est associée intuitivement à la taille du programme. La taille est

Mesures basées sur le code source et la conception du programme

33

définie comme le nombre de lignes de code du programme. Il existe quelques définitions

différentes du concept de « ligne de code » pour clarifier ce qui est compté comme une

ligne de code. Le consensus est que les lignes vides et les commentaires ne soient pas

comptés. Cependant, les auteurs et les organisations différentes peuvent proposer des

listes de vérification (check lists) différentes selon leurs besoins.

Selon Conte [49], une ligne de code est une ligne de texte (code) dans le programme qui

n’est pas une ligne vide ou un commentaire, peu importe le nombre d’instructions sur une

ligne. Cette définition inclut toutes les lignes de l’entête, les déclarations, les instructions

exécutables et non exécutables.

Chez Hewlett-Packard, Grady [70] définit une ligne de code comme une instruction

exécutable (c-à-d, une ligne qui n’est pas une déclaration, une entête, une ligne vide, etc.)

Bien que la mesure des lignes de code soit très simple et intuitive, il y a encore des débats

sur la façon de compter les lignes vides, les commentaires, et les déclarations de données.

Il semble que le but de la mesure soit le plus important et décidera de ce qui doit être

mesuré. Par exemple, si on compte l’effort pour coder un programme, les lignes vides ne

contribuent pas significativement au temps pour écrire le code. Par contre, si on veut

évaluer la facilité à comprendre le programme, les lignes vides peuvent faciliter la

lisibilité et la compréhension du code, puis faciliter le test et le débogage du programme.

Alors elles pourraient affecter l’effort (ou le temps total) de développement du logiciel.

Les lignes de code sont très intuitives pour représenter « la taille » du logiciel. Du fait

qu’elles peuvent être mesurées objectivement et automatiquement, les lignes de code sont

souvent utilisées dans la pratique. Il existe plusieurs modèles d’estimation de l’effort de

développement du logiciel qui utilisent le nombre de milliers de lignes de code (KLOC),

par exemple SLIM [135] et COCOMO [30,31]. Cela illustre que la taille du programme

peut être considérée comme un aspect pertinent de la complexité du logiciel et qu’elle

peut être associée à l’effort de développement du logiciel.

Les limites majeures de cette méthode sont les suivantes:

!" La mesure est dépendante du langage de programmation.

!" La mesure est dépendante de la technique de production du code (par exemple,

l’utilisation de générateurs du code).


34

!" La mesure est obtenue assez tard dans le cycle de vie du logiciel. Donc elle n’est

pas très utile pour planifier la production (p.ex., l’estimation de l’effort, la

prédiction du coût, la distribution des ressources).

!" Elle ne reflète pas la difficulté du code.

“There is a major problem with the lines of code measure: it is not

consistent because some lines are more difficult to code than others …

One solution to the problem is to give more weight to lines that have

more “stuff” in them” [49].

Cette limitation n’empêche pas l’utilisation des lignes de code. Cependant, il semble qu’il

faut y ajouter certaines mesures de la complexité qui reflètent la difficulté du code.

Le nombre de lignes de code n’est pas disponible avant le codage complet. Donc, il n’est

pas très utile dans la planification d’un projet de développement. Cependant, il est tout à

fait utile pour un projet de maintenance. Pour un tel projet, le nombre de lignes de code à

modifier et à re-tester est une mesure intuitive de l’effort de maintenance.

Les lignes de code sont encore utilisées comme une mesure de base pour évaluer la

productivité du programmeur et celle de l’équipe de travail. La productivité est mesurée

par le nombre de lignes de code développées par unité de temps. Parfois, le nombre de

lignes de code est encore utilisé comme un paramètre pour évaluer la qualité de

production du code, par exemple on compte le nombre de fautes sur mille lignes de

code [43].

2.1.2 Science du logiciel de Halstead

Halstead [76] a proposé des mesures basées sur le code source du programme mais elles

ne sont pas des mesures de lignes de code. Il a plutôt essayé d’intégrer les mesures

physiques aux mesures psychologiques pour mieux estimer certains attributs du logiciel,

comme la longueur, le volume du programme et la difficulté du code. Le concept de base

pour les mesures de Halstead est le « token ». Il y a deux types de « token » dans le code

source d’un programme: l’opérateur et l’opérande.

Les quatre mesures de base proposées par Halstead sont:

!" %1: nombre d’opérateurs uniques

!" %2: nombre d’opérandes uniques

!" N1: nombre total d’occurrences des opérateurs


35

!" N2: nombre total d’occurrences des opérandes.

Par exemple: le code « a = b + c » contient trois opérandes « a », « b », « c » et deux

opérateurs « = » et « + ».

Basée sur ces quatre mesures, Halstead a proposé les définitions suivantes:

!" La longueur du programme: N=N1+N2. Cette mesure est le nombre total de

tokens utilisés dans le programme. N est la taille du programme en terme de

tokens utilisés au lieu de lignes de code.

!" Le vocabulaire du programme: % = %1 + %2. Cette mesure est le nombre total de

tokens uniques dans le programme.

!" Le volume du programme: V = N log(%). 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 % tokens différents, alors le temps de recherche

dichotomique est log(%). La recherche est faite N fois pour un programme de N

tokens. Alors, le programmeur doit payer un effort total Nlog(%) pour réaliser les

recherches pendant la composition du code. Cette mesure est appelée le volume

du programme.

Suite à ces mesures, les indices plus abstraits comme la difficulté du programme, l’effort

et le temps requis pour écrire le programme sont définis comme suit:

Le niveau du programme (program level): L=V*/V, où V* est le volume potentiel – le

volume de la taille minimale pour implémenter le programme. V* est une valeur

empirique qui dépend du langage de programmation. Par exemple, pour FORTRAN, V*

est 11,6 [62, p. 252]. L’inverse du niveau du programme est définie comme la difficulté

du programme: D=1/L.

Selon la théorie de Halstead, le niveau du programme peut être estimé par:

N

µµ

L2

2

1

x2&

Et la longueur du programme (N) est estimée par:

)µlog(µ)µlog(µN 2211 '&


36

Puis l’effort requis pour composer le programme est:

2µ

NlogµNµLVE

2

21&&

L’unité de mesure E est la discrimination mentale (mental discrimination) requise pour

comprendre le programme. Selon le résultat d’études en psychologie faites par John

Stroud [155], un individu peut faire un nombre de 5 à 20 discriminations par seconde.

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.

L’exemple suivant illustre l’application des mesures de Halstead à un petit programme

FORTRAN. L’exemple est reproduit du livre de Fenton [62, p. 252]

SUBROUTINE SORT(A,N) INTEGER A (100), N, I, J, SAVE, M C ROUTINE SORTS ARRAY A INTO DESCENDING ORDER IF (N.LT.2) GO TO 40 DO 30 I=2, N M=I-1 DO 20 J=1, M IF (A(I) .GT. A(J)) GO TO 10 GO TO 20 10 SAVE = A(I) A(I) = A(J) A(J) = SAVE 20 CONTINUE 30 CONTINUE

40 RETURN END

L’application des mesures de Halstead donne ceci:

N = N1+N2 = 93

% = %1 + %2 = 27

V= N log(%) = 93 * 4,75 = 442

V* = 11,6 (valeur empirique pour le programme FORTRAN)

L= V* / V = 11,6 / 44,2 = 0,026


37

L peut être estimé par N

µµ

L2

2

1

x2& = 2/14 * 13/42 = 0,044

D = 1/L = 38,5

L’effort est estimé par 2µ

NlogµNµLVE

2

21&& = 442/0,044 = 10045

Le temps pour écrire le code T = E/18 = 558 secondes ou environ 10 minutes.

Ainsi, selon Halstead, le programme de cet exemple requiert environ 10 minutes pour son

écriture. Ce résultat est conforme à l’expérience de programmation.

Les trois premières mesures (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 [62, p. 251] indique que les attributs de mesure ne sont pas clairs. Il

n’y a pas de consensus sur des attributs comme volume, niveau du programme et

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

Cependant, Halstead estime que ses mesures sont testées empiriquement et qu’elles

donnent des résultats cohérents avec l’expérience pratique [76]. Ses travaux s’appuient

sur certains résultats de recherche sur la cognition humaine, par exemple le résultat

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 [19] 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%.

Bien que la science du logiciel de Halstead soit très connue dans la littérature du domaine

de la mesure du logiciel, elle semble n’être pas à un bon niveau de détail. Il semble que

les programmeurs et les concepteurs ne pensent pas en terme de tokens individuels [43].


38

2.2 MESURES DE LA STRUCTURE DES PROGRAMMES

Traditionnellement, un programme est souvent modélisé comme un ensemble de modules

de code. Puis la complexité structurelle du logiciel est considérée à deux niveaux:

!" la complexité intra-module qui fait référence à la complexité d’un module

individuel;

!" la complexité inter-modules qui vient de la complexité de relations entre les

modules dans un système. Deux relations inter-modules importantes qui sont les

plus étudiés dans la littérature sont:

o la relation dépendance de contrôle qui indique qu’un élément (une

instruction, un bloc de code ou un module) transfère le contrôle pour

provoquer l’exécution d’un autre élément.

o la relation de dépendance de données qui indique qu’un élément transfère des

données à un autre élément.

Selon Fenton [62], la complexité structurelle peut être décrite selon trois types:

!" La structure de flux de contrôle (control flow structure) qui reflète des

instructions de contrôle (nœuds de condition, boucles, etc.) dans le code.

!" La structure de flux de données (data flow structure) qui fait référence à des

communications (c-à-d, les transferts de données) entre les modules ou entre les

parties d’un programme.

!" La structure des données (data structure) qui tient compte de l’organisation de

données dans le programme.

Le flux de contrôle est modélisé par un graphe orienté (appelé graphe de flux (flowgraph)

– voir la figure 2.1) dont un nœud correspond à une instruction du programme et un arc

indique une dépendance de contrôle d’une instruction à l’autre.

Le flux de données est modélisé de façon similaire: un nœud représente un module ou un

bloc de code (chunk of code [54]) et un arc représente un transfert de données. De plus,

on peut établir les flux de contrôle et les flux de données du programme dès la phase de

conception détaillée. Dans ce cas, les graphes de flux de contrôle ou de données sont

basés sur les algorithmes du programme ou la conception du programme. Par conséquent,

les mesures de la structure du programme peuvent être appliquées indépendamment du

code source du programme.


39

Figure 2.1: Exemple d’un graphe de flux (flowgraph).

Les mesures de la structure du programme veulent capturer la difficulté d’écrire le code

du programme ou la facilité de compréhension du programme. La difficulté d’écrire un

programme affecte directement l’effort de développement du logiciel. La

compréhensibilité affecte l’effort pour tester et pour mettre à jour le logiciel. En général,

le degré de « structuralité » (structureness) du programme, le niveau d’emboîtement des

instructions, et le niveau de branchement du programme sont des facteurs qui causent les

difficultés auxquelles un individu fait face quand il travaille sur le programme.

2.2.1 Mesure de McCabe

McCabe [118] propose une mesure intitulée « le nombre cyclomatique » pour quantifier

la complexité du flux de contrôle. Son objectif à l’origine était de déterminer le nombre

de chemins dans un programme qui doivent être testés pour s’assurer de tester tous les

chemins.

Selon cette méthode, le graphe de flux représente les branchements du programme. Un

nœud du graphe représente une instruction de contrôle (IF, WHILE,…); un arc désigne un

branchement. Puis, la complexité du programme est définie comme le nombre de chemins

indépendants dans le graphe (appelé le nombre cyclomatique). La complexité du

programme est calculée par:

v = e - n+ 2.

Où: e est le nombre d’arcs du graphe de flux; n est le nombre de nœuds du graphe.

Par exemple: la complexité du graphe de la figure 2.1 est: v = 14-10+2 = 6.


40

Dans ce cas spécifique, si le graphe est connexe, le nombre cyclomatique est le nombre

de nœuds de décision binaire plus 1.

Par exemple, le nombre cyclomatique du graphe dans la figure 2.1 est 6. Ce nombre

indique qu’il y a six chemins indépendants linéaires dans le graphe: 2-11; 2-10-12-14; 1-

3-5-6-9; 1-3-5-6-7-8-9; 1-4-6-9; 1-4-6-7-8-9. Il peut être calculé par le nombre de

prédicats (nœuds de condition ou nœuds de branchement) plus 1. En fait, le graphe

3.1 contient cinq nœuds de décision (A, B, C, G, I), donc le nombre cyclomatique est 6.

Du point de vue théorique, il est très difficile de prouver la relation entre le nombre

cyclomatique et la complexité (c-à-d, la difficulté de la compréhension du code, la

difficulté de codage). Cependant, la mesure de McCabe est intuitivement associée à la

difficulté pour comprendre le code. De ce fait, d’autres chercheurs ont essayé d’associer

le nombre cyclomatique au nombre d’erreurs du code et cette mesure est devenue une

mesure de qualité du code (qualité d’un module). McCabe a aussi suggéré que si le

nombre cyclomatique d’un module est de 10 ou plus, le module est trop complexe, donc il

devrait être repensé (redesigned).

La mesure 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 est à bon

niveau de détail parce qu’elle capture la structure logique du code. Plusieurs autres

recherches ont été faites autour de l’idée de McCabe. Par exemple, Gilb [68] propose une

mesure similaire qui compte le nombre de nœuds de décision. Myers [127] a proposé une

extension pour tenir compte de conditions très complexes qui se composent de plusieurs

prédicats. Hansen [77] 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.

2.2.2 Mesure de Henry et Kafura

La mesure de McCabe s’adresse à la structure de contrôle intra-module. Un autre type de

complexité est la difficulté qui émerge de la relation entre les modules d’un système. La

relation de base est qu’un module appelle un autre module ou est appelé par un autre

module.


41

Figure 2.2: Exemple de fan-in et fan-out.

Henry et Kafura [79] 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 (voir figure 2.2). Puis,

Complexité du module = length x (fan-in x fan-out)2

Où length est la longueur du module en terme de milliers de lignes de code; fan-in, fan-

out sont la somme des fan-in et fan-out des divers modules du système respectivement.

Plusieurs autres recherches de la complexité basée sur fan-in et fan-out ont aussi été

publiées. Par exemple, Belady et Evangelisti [23] estiment que la complexité du système

dépend non seulement du nombre total de fan-out, mais aussi la distribution de fan-out

dans le système. Pour un nombre fixe de fan-out, un système dans lequel les invocations

se concentrent sur certains modules est plus complexe qu’un système dans lequel les

invocations sont distribuées. De ce fait, ils proposent une mesure de la complexité inter-

modules comme suit:

S = n

n

if(&1i

2

Où: S est la complexité inter-modules du système

fi est le nombre de fan-out du module i

n est le nombre total de modules du système.


42

Shepperd et Ince [143] simplifient la mesure de Henry et Kafura en proposant une mesure

qui se concentre sur les flux de contrôle seulement:

La complexité = (fan-in x fan-out)2

Sheppard estime que sa mesure est en bonne corrélation avec le temps de développement

du système. Cela implique que la complexité de la structure du système affecte

significativement la complexité cognitive qui se manifeste dans l’effort (total) de

développement du logiciel.

2.2.3 Couplage et cohésion

Le couplage est le degré d’interdépendance entre les modules dans un système.

La cohésion d’un module est le degré de cohérence entre les parties du module. Un

module est cohérent si ses parties aboutissent à résoudre une seule tâche. Le couplage et

la cohésion sont utilisés pour évaluer la qualité de la conception d’un logiciel ainsi que la

qualité du code. On croit qu’une bonne conception reflètera une haute cohésion dans un

module et un faible couplage entre les modules.

2.2.3.1 Couplage entre les modules 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, c’est-à-dire que 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. Le couplage est souvent évalué qualitativement sur une échelle

de six niveaux définis par Yourdon [179]:

!" Pas de couplage.

!" Couplage de données: deux modules communiquent par des paramètres qui sont

des éléments de données simples (par exemple, une variable de type élémentaire).

!" Couplage fort (stamp coupling): deux modules communiquent par des paramètres

de type d’enregistrement (record).

!" Couplage de contrôle: un module transfère un paramètre à un autre module pour

contrôler le comportement de celui-ci.


43

!" Couplage commun: deux modules 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.

!" Couplage de contenu: un module accède aux données d’un autre module et fait

des modifications de données directement.

Certains chercheurs proposent le couplage comme un attribut d’un module individuel

plutôt qu’un attribut de paire de modules. Par exemple, Troy et Zweben [170]

introduisent les mesures suivantes pour capturer le couplage d’un module avec d’autres:

!" La moyenne d’interconnections par module.

!" Le nombre total d’interconnections par module.

!" Le nombre de modules qui ont des interconnections de contrôle.

!" Le nombre de structures de données d’interconnections avec le module de la

racine (top-level module)

La recherche de Troy et Zweben a aussi montré que ces mesures offrent des indices

importants de la qualité de la conception du logiciel.

En cherchant une mesure de « couplage du système entier », Fenton [62] 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.

2.2.3.2 Cohésion du module La cohésion d’un module est le degré de cohérence entre les parties du module. De façon

idéale, un composant (module) devrait implémenter une seule fonction logique ou une

seule entité logique sachant que toutes les parties du composant doivent contribuer à cette

implémentation. Si un composant comporte des parties qui ne sont pas directement

relatives à sa fonction logique, ce composant n'a qu'un faible degré de cohésion. Yourdon

[179] propose une échelle de sept niveaux de cohésion présentés ci-après du plus fort au

plus faible:

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

!" La cohésion séquentielle: la sortie d'un élément est utilisée en entrée d'un autre.


44

!" La cohésion de communication: un module réalise plusieurs fonctions mais

manipule le même corps de données.

!" La cohésion procédurale: un module réalise plusieurs fonctions qui composent

une fonction générale du système.

!" La cohésion temporelle: un module réalise plusieurs fonctions qui doivent se

produire en même temps. Tous les éléments sont activés en même temps comme

par exemple à l'initialisation du programme ou encore à la fin de l'exécution.

!" La cohésion logique: un module réalise plusieurs fonctions qui ont des relations

logiques. Tous les éléments du module effectuent des opérations semblables

comme la prise en compte ou le traitement d'erreurs.

!" 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 éléments du module. Les éléments

sont simplement rassemblés dans le module.

Ces classes de cohésion ne sont pas définies de manière stricte; Yourdon donne

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

Le couplage et la cohésion ne sont pas mesurés de façon objective, cependant elles sont

des critères importants pour évaluer la qualité de la conception. Les méthodes de

conception du logiciel cherchent une balance entre bas couplage et haute cohésion (c-à-d,

cohésion fonctionnelle). Bien que la cohésion soit un attribut intra-module, 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:

Taux de cohésion = nombre de modules ayant une cohésion fonctionnelle /

nombre total de modules

Card et Glass [43] 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.

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.


45

2.2.4 Mesures de la compréhensibilité du programme

2.2.4.1 Modèle de la compréhension du programme Les mesures de la complexité relative à la structure du programme font référence à la

difficulté à laquelle un programmeur fait face quand celui-ci travaille sur le code du

programme. La complexité de la structure du programme est souvent interprétée comme

une mesure de la compréhensibilité du programme. Par exemple, si le nombre

cyclomatique de McCabe est plus grand que 10, le programme est jugé incompréhensible

donc il faut le réviser.

Plusieurs recherches essaient d’établir un modèle de la compréhension du programme

pour mieux mesurer la complexité. Miller [122], Shneiderman [145], Davis [54], Harrison

[78] ont suivi cette approche. Le consensus sur le processus de la compréhension du code

est que le programmeur ne comprend pas un programme par instruction mais par ‘chunk’

de code. Un chunk de code est un ensemble d’instructions qui ont des liens sémantiques

entre eux et qui peuvent être représentées par un seul état mental (c-à-d, un symbole). Par

exemple, le segment de code suivant peut être considéré comme un chunk:

T:= X; X:= Y; Y:=T;

Lorsqu’un programmeur compose le code, ces trois instructions forment une sémantique

unitaire qui est « échanger le contenu de deux variables X et Y ». La sémantique de ces

trois instructions est représentée par un seul état mental dans l’esprit du programmeur.

Lors du débogage d’un programme, le programmeur lit le code du programme et reforme

les chunks ainsi que les relations entre eux pour comprendre la sémantique du code. Ce

processus est connu comme le « tracing ». Alors, « chunking » et « tracing » sont deux

activités principales de la compréhension du code. De ce fait, le programme est modélisé

par les chunks, puis la structure du code est modélisée par un graphe de flux représentant

la relation entre les chunks. Un nœud représente un chunk de code, un arc orienté AB

représente une relation de chunk A à chunk B. La relation entre deux chunks de code peut

être une dépendance de contrôle (p.ex., A appelle B) ou une dépendance de données

(c-à-d, A transfère des données à B).

2.2.4.2 Mesure de l’entropie Dans la sous-section précédente, on a vu que la compréhension du programme est

modélisée par un graphe de flux de contrôle. Une mesure qui est basée sur le graphe

comme la mesure de McCabe pourrait donc être appliquée pour quantifier la complexité.


46

Une autre approche de mesure de la complexité de la compréhension du code est basée

sur la théorie de l’information. L’idée de base est que la complexité de la compréhension

du code du programme est la complexité de l’information dans le graphe représentant le

programme. La complexité de l’information est mesurée par la notion d’entropie qui a été

développée par Shannon [142]. L’entropie est interprétée comme une mesure

d’information en communication dans le système. On croit qu’un système de haute

entropie comporte plus d’informations qu’un système de basse entropie, le premier étant

donc plus complexe que le dernier.

Figure 2.3: Graphe G.

Davis et LeBlanc [55] proposent une mesure à base d’entropie pour capturer la

complexité du code. Leur mesure peut être décrite comme suit:

Le programme est modélisé par un graphe orienté. Un nœud est un chunk de code, un arc

orienté représente une relation de données ou une relation de contrôle. Un nœud a donc

un in-degré qui est le nombre d’arcs « entrées » et un out-degré qui est le nombre d’arcs

« sorties ». Les nœuds sont classifiés en classes d’équivalence dont chacune contient les

nœuds de même in-degré et out-degré. L’entropie du programme est définie en se basant

sur la probabilité d’appartenance d’un chunk à une classe d'équivalence:

H = - (&

n

1iii )))log(P(AP(A

Où, n est le nombre de classes d’équivalence et P(Ai) est la probabilité

d’appartenance d’un chunk à la classe Ai.

Par exemple, il y a quatre classes d’équivalence dans le graphe G de la figure 2.3: {a},

{b,c,e,f}, {d}, {g}. L’entropie du programme modélisé par le graphe G est:

H = - [1/7log(1/7)+ 4/7log(4/7) + 1/7log(1/7) + 1/7log(1/7)] = 1,664.

Le système est le plus complexe si le nombre de classes est égal au nombre de chunks,

c’est-à-dire une classe contenant un seul chunk. Dans ce cas, l’entropie atteint la valeur


47

maximale (figure 2.4b): H=log(n), où n est le nombre de chunks. Le système est le moins

complexe si tous les chunks sont dans une seule classe. Dans ce cas, l’entropie atteint la

valeur minimale (figure 2.4a): H=log(1) = 0.

Figure 2.4: a) Entropie=0. b) Entropie atteint la valeur maximale pour un graphe de 5 nœuds (H=log5).

La mesure de l’entropie comme telle mesure le degré de régularité du système. Un

système dont les relations entre les composants sont régulières (figure 2.4a) est moins

complexe qu’un système dont les relations entre les composants sont variées. L’entropie

du système reflète donc la richesse d’information du système. Cependant, cette mesure ne

reflète pas le degré d’interconnections entre les chunks. Si un chunk est un module, cette

mesure ne reflète pas le couplage entre les modules. Si on veut mesurer le degré

d’interconnections, les mesures se basant sur fan-in (in-degré) et fan-out (out-degré)

pourraient être plus pertinentes.

Davis et LeBlanc [54] estiment que leur mesure est meilleure que la mesure de McCabe à

cause de la capacité de discriminer les structures de contrôle en emboîtement et les

structures de contrôle en séquence. Pour deux graphes représentant deux programmes

ayant le même nombre de nœuds de décisions, celui qui a une structure d’emboîtement

est plus difficile que celui qui n’a qu’une structure séquentielle (voir la figure 2.5 et

l’exemple qui suit). La mesure de l’entropie est encore conforme à l’intuition: un système

homogène est moins complexe qu’un système hétérogène.

Par exemple, les deux graphes dans la figure 2.5 ont le même nombre de nœuds de

décision (trois nœuds: 1, 4, 7). La complexité mesurée par la mesure de McCabe est 4

pour les deux graphes. Cependant, la complexité mesurée par l’entropie du graphe a) est


48

plus petite que celle du graphe b). En fait, les nœuds du graphe a) sont catégorisés en 4

classes d’équivalence {1} {2, 3, 5, 6, 8, 9}, {10}, {4, 7}. Donc, son entropie est

H(a) = - [1/10*log(1/10) + 6/10*log(6/10) + 1/10*log(1/10) + 2/10*log(2/10)] = 1,57.

Les nœuds du graphe b) sont classifiés en 6 classes d’équivalence {1},{2, 3, 6, 8,

9},{5},{4}, {7}, {10}. Alors, l’entropie de ce graphe est:

H(b) = - [1/10*log(1/10) + 5/10*log(5/10) + 1/10*log(1/10) + 1/10*log(1/10) +

1/10*log(1/10) + 1/10*log(1/10)] = 2,16.

Figure 2.5: Deux graphes ayant le même nombre de nœuds de décision, mais b) est plus complexe que a) en terme d’entropie.

La figure 2.5a) représente trois structures SI … ALORS en séquence. Par contre, le

graphe 3.5b) représente trois structures SI … ALORS emboîtés. La mesure de McCabe ne

reflète cette différence, ce que la mesure de l’entropie fait. La mesure de l’entropie du

système est donc meilleure que la mesure de McCabe dans ce contexte. De plus, les

travaux expérimentaux de Davis et LeBlanc [54] ont montré que leur mesure est associée

au temps de débogage et au temps de construction du programme. Par conséquent, la

mesure de l’entropie est une mesure relative à l’effort total de développement du logiciel.


49

2.3 EXPLICATION DE LA COMPLEXITÉ AU POINT DE VUE PSYCHOLOGIQUE

Les recherches sur la complexité structurelle du logiciel font souvent référence à

l’architecture de l’esprit, surtout, la capacité limitée de la mémoire à court terme de l’être

humain. L’architecture de l’esprit humain est utilisée pour expliquer pourquoi un individu

rencontre des difficultés quand il résout un problème ou fait une tâche.

2.3.1 Résultats principaux concernant l’architecture de l’esprit humain

Les études en sciences cognitives ont postulé que l’esprit humain est composé de la

mémoire active (ou mémoire à court terme), et de la mémoire de stockage (ou mémoire à

long terme). La mémoire à court terme est la mémoire de travail dont la capacité est

limitée. Miller [122] a proposé le nombre « magique » 7)2 pour désigner la capacité de la

mémoire à court terme. Autrement dit, ce type de mémoire peut contenir environ sept

items différents. La limite de la mémoire à court terme dépend de l’individu et du type

d’information [104]. Par exemple, pour la compréhension d’un texte, la limite est

d’environ quatre concepts [36]. Par conséquent, une phase contenant plus de quatre

concepts pourrait ne pas être comprise immédiatement. La capacité de la mémoire à court

terme pourrait être réduite si l’on résout une tâche complexe [103]. De plus, l’oubli est

une caractéristique de la mémoire à court terme. Un nouveau concept appris pourrait être

oublié après 20-30 secondes [168,157]. L’oubli est expliqué par la durée de conservation

en mémoire qui est le temps nécessaire pour mémoriser un nouveau concept. Si la densité

du concept est élevée, le risque de perdre le concept est élevé [104].

La mémoire à long terme possède une capacité virtuellement illimitée. Le contenu de la

mémoire à long terme peut être accédé et récupéré à partir du contenu de la mémoire à

court terme [168]. Le contenu de la mémoire à court terme peut être transféré à la

mémoire à long terme et y être sauvegardé. La mémoire à long terme peut être décrite

comme un réseau de concepts. Le degré de connexion (dans le réseau) et la fréquence

d’exposition d’un concept jouent un rôle clé dans la mémorisation du concept. Si un

concept a plusieurs références, il est facile à mémoriser. Par contre, si un concept a très

peu d’utilisation, on l’oublie facilement.


50

2.3.2 Explication de la complexité

L’architecture de l’esprit (c-à-d, la mémoire à court terme et celle à long terme) est

utilisée pour interpréter certaines mesures de la complexité. Généralement, la mémoire à

court terme est considérée comme un conteneur pouvant contenir un nombre très limité

de concepts. S’il y a plusieurs concepts qui doivent être traités ensemble, alors le risque

d’erreurs est élevé ou le temps de traitement est long, et l’individu fait face à une

difficulté. Effectivement, Halstead [76] explique ses mesures de la façon suivante:

Le volume du programme estimé par V’ = %1log(%1) + %2log(%2) est interprété comme la

difficulté à gérer le programme. Lorsque le programmeur compose le programme, il fait

une recherche dichotomique pour récupérer les tokens (c-à-d, les opérateurs et les

opérandes). %1log(%1) est l’espace de recherche pour %1 opérateurs; %2log(%2) est l’espace

de recherche pour %2 opérandes. Alors V’ est l’espace de recherche total pour un

programme ayant %1 opérateurs et %2 opérandes. Un long programme (en termes de

nombre d’opérateurs et d’opérandes) est plus difficile à composer et à gérer qu’un

programme plus court parce que la mémoire à court terme n’est pas suffisante pour gérer

un grand volume de code.

Le nombre magique de Miller a été utilisé par McCabe pour expliquer son jugement sur

la complexité du module. McCabe propose qu’un programme ayant un nombre

cyclomatique plus grand que 10 soit trop complexe (trop difficile à comprendre), donc le

programme doit être repensé (redesigned). Selon la même approche, certains chercheurs

proposent d’autres limites. Grady [72] analyse 850000 lignes de code de Fortran et

conclut que 15 est le nombre cyclomatique maximal acceptable pour un module. Bennett

[25] constate qu’un module dont le nombre cyclomatique excède 20 doit être rejeté parce

qu’il est trop complexe.

Brièvement, la limite sur la capacité de la mémoire humaine est exploitable pour

expliquer certaines mesures de la complexité. Elle peut être utilisée pour répondre à la

question « pourquoi éprouve-t-on de la difficulté? ». Une mesure expliquée par certains

aspects cognitifs est plus plausible, plus convaincante parce que les explications

cherchent à démontrer « ce qui cause la difficulté ». Cependant, ces explications ne

peuvent pas remplacer la validation parce qu’elles ne peuvent pas répondre à la question

« est-ce que la complexité est quantifiée correctement? ».


51

2.4 RÉSUMÉ

Dans ce chapitre, nous avons fait une revue de la littérature sur les mesures de la

complexité qui sont basées sur le code source du programme ou la conception du logiciel.

Ces mesures de complexité font référence à la taille du logiciel ainsi qu’à la structure du

logiciel. Les mesures de la taille sont associées directement à l’effort de développement.

Cependant, elles ne reflètent pas bien les difficultés psychologiques du programmeur. Par

contre, les mesures de la complexité structurelle veulent capturer la facilité de la

compréhension du code, la difficulté d’écrire le code et la difficulté de tester le code.

Dans ce contexte, la complexité du logiciel fait référence aux difficultés psychologiques

auxquelles un programmeur fait face dans le processus de développement du code. Ces

difficultés affectent la performance du programmeur. Elles causent des erreurs de codage,

allonge le temps de débogage et puis augmente l’effort de développement du logiciel.

La revue de la littérature dans ce chapitre cherchait à répondre à certaines questions:

!" Qu’est-ce qui doit être mesuré pour caractériser la complexité du logiciel? La

réponse est la taille et la structure du logiciel. La structure du logiciel tient

compte de la structure des composants individuels et de la structure du système

entier.

!" Comment mesure-t-on la complexité du logiciel? Plusieurs façons de mesurer la

complexité du logiciel existent. Elles sont dépendantes de l’objectif de mesure.

Par exemple, les mesures de taille sont souvent reliées à l’effort de

développement, tandis que les mesures de la structure du logiciel font souvent

référence à la compréhensibilité du code et de la conception, puis à la qualité du

code.

!" Est-ce que la taille et la structure du logiciel sont des mesures pertinentes

associées à l’effort de développement du logiciel? La réponse est oui parce que

les mesures de la taille ont été conçues comme un indice de base de l’effort.

Cependant, elles ne sont pas suffisantes pour caractériser la complexité. Cette

dernière est encore liée à la structure du logiciel. C’est la structure du logiciel

(c-à-d, la structure du code ou de la conception) qui affecte la facilité de la

compréhension du code et la performance de programmeur. Elle consiste en un

aspect additionnel de l’effort en plus de la taille.


52

Les mesures présentées dans ce chapitre sont appliquées sur le code source et la

conception du programme. Cependant, l’idée générale à retenir de ces mesures est que la

structure des composants (p.ex., modules) et l’information du système sont des

dimensions importantes de la complexité structurelle de logiciel. Une mesure de la

complexité structurelle devrait en tenir compte. La mesure proposée dans cette thèse

s’inspirera de ces aspects, mais à un niveau d’abstraction plus élevé – le niveau des

fonctionnalités du logiciel.

CHAPITRE 3

MESURES DE POINTS DE FONCTION

Dans le chapitre précédent, on a vu comment la complexité est mesurée à partir du code

source et de la conception du logiciel. Une autre approche de mesure est l’approche

fonctionnelle avec laquelle la complexité est évaluée en se basant sur la fonctionnalité du

logiciel. Les mesures de ce volet sont connues comme les mesures de « points de

fonction ». Elles sont dérivées de la fonctionnalité du logiciel du point de vue de

l’utilisateur. Elles fournissent tôt des valeurs qui indiquent le nombre de fonctions du

logiciel livrées à l’utilisateur. Ces valeurs sont des indices directement liés à l’effort de


La revue de la littérature dans ce chapitre se concentre sur les méthodes de points de

fonction. Elle fournit une vision globale de la structure de ces méthodes et à partir de

celle-ci un cadre conceptuel de la complexité fonctionnelle du logiciel est construit. Ce

cadre, d’une part, aide à préciser la complexité fonctionnelle du logiciel. D’autre part, il

illustre des aspects de la complexité qui sont mentionnés implicitement ou explicitement

dans les mesures de points de fonction.

Ce chapitre montre aussi les problèmes des mesures de points de fonction existantes. Ces

problèmes sont des aspects dont il faudra tenir compte dans la proposition d’une nouvelle

méthode.

3.1 ANALYSE DE POINTS DE FONCTION (FUNCTION POINTS ANALYSIS – FPA)

3.1.1 Concept de point de fonction (PF)

En 1979, Albrecht [8] a proposé une méthode de mesure intitulée « l’analyse de points de

fonction » qui est connue sous l’abréviation FPA (Function Points Analysis). Selon cette

méthode, les fonctions du logiciel sont identifiées à partir des spécifications du logiciel.

Mesure de points de fonction

54

Chaque fonction individuelle est évaluée subjectivement pour sa complexité et une valeur

expérimentale (un poids) lui est assignée selon sa complexité. La somme totale des poids

est connue comme le nombre de points de fonction et elle est définie comme la taille

fonctionnelle du logiciel. Cette approche permet d’obtenir tôt dans le cycle de vie du

logiciel un indicateur de la grandeur du projet qui sert à planifier le projet, calculer la

productivité et estimer l’effort de développement et le coût du logiciel.

Historiquement, les points de fonction ont été développés pour répondre à l’analyse de

productivité. L’objectif était d’établir une méthode pour évaluer l’augmentation de

productivité de développement de 24 projets réalisés chez IBM de 1974 à 1978. Ces

projets avaient été développés avec des langages de programmation et des outils

différents. Alors, la méthode devrait être applicable quels que soient les langages et les

techniques utilisés. Les mesures de lignes de code ne satisfont pas cette exigence. Les

points de fonction sont conçus pour surmonter le problème. Voici les idées clés

d’Albrecht sur le concept de point de fonction [9] (texte tiré de la thèse

d’Abran [4, p.51]):

!" Les points de fonction sont une mesure du produit du processus de

développement et d’entretien basée sur la fonction usager du traitement de

l’information.

!" Les points de fonction mesurent une application en quantifiant la fonctionnalité

du traitement de l’information associée avec les principaux intrants des données

externes ou de contrôle, les sorties et les types de fichiers.

!" Ce traitement spécifique d’information est ensuite ajusté pour la fonction

générale du traitement de l’information en appliquant un ajustement basé sur les

caractéristiques générales de l’application.

Les points de fonction sont une mesure sans dimension du logiciel. C’est une mesure

abstraite, synthétique de la taille et de la complexité du logiciel. Jones [97] estime que

cette méthode est une mesure artificielle similaire à la notion de l’indice industriel Dow

Jones. Elle est utilisée pour estimer tôt l’effort de développement et le coût du logiciel.

Les points de fonction sont aussi considérés comme une mesure de la complexité du

projet [117] et interprété comme un paramètre pour quantifier des comportements

généraux [58].


55

3.1.2 Mesure de points de fonction

La mesure de points de fonction est née en 1979 sous le nom « d’analyse de points de

fonction » (FPA – Function Points Analysis). Le modèle initial [8] est assez simple. Une

version modifiée de la méthode fut présentée en 1983 [9]. Cette version devint la norme

de facto utilisée pour mesurer les points de fonction du logiciel. La méthode mentionnée

dans cette section est la version de 1983.

Item Poids Simple Moyen Complexe Entrées 3 4 6 Sorties 4 5 7 Requêtes 3 4 6 Fichiers externes 7 10 15 Fichiers internes 5 7 10

Tableau 3.1: Type de fonctions élémentaires et les poids de complexité.

# Termes d’Albrecht [9] Explications 1 Data communications L’application reçoit et/ou transmet des données en utilisant

des moyens de communication 2 Distributed data

processing Données et manipulations distribuées

3 Performance issues Répondre à des demandes de performance particulières 4 Heavily used

configuration L’application est exécutée sur un équipement très utilisé et très occupé

5 Transaction rate La fréquence de transactions est très haute. Elle affecte le design, le développement et l’installation de l’application

6 On-line data entry Données d’entrée et contrôle en direct 7 End user efficiency Fournir des fonctions en direct pour faciliter l’utilisation par

l’utilisateur 8 On-line update Mise à jour en direct des fichiers internes 9 Complex processing Plusieurs contrôles et points de décision; manipulation

mathématique complexe; manipulation d’un grand nombre d’exceptions

10 Reusability Design spécifique pour la réutilisation 11 Installation easy Facilité d’installation 12 Operational ease Facilité d’utilisation 13 Multiple sites Installations sur plusieurs sites 14 Facilitate change Flexible et facile à modifier

Tableau 3.2: 14 caractéristiques générales du système (GSCs).

Depuis son avènement, FPA est réputée être applicable aux systèmes d’information de

gestion (MIS). L’idée principale de FPA est que la taille fonctionnelle du logiciel est

quantifiée à partir de cinq types de fonctions élémentaires: entrées, sorties, requêtes,


56

fichiers externes et fichiers internes. Le processus de mesure commence par

l’identification des fonctions élémentaires (ou items) du logiciel. À chaque item est

assigné subjectivement un poids correspondant au niveau de sa complexité sur une

échelle de trois niveaux: simple, moyen et complexe (voir tableau 3.1). La somme de

poids de toutes les fonctions est appelée l’UFP (unadjusted function point) et interprétée

comme la taille brute ou les points de fonction non ajustés du logiciel. Le processus de

mesure se poursuit par l’identification de quatorze facteurs reflétant des caractéristiques

du système, dont la complexité du système (voir tableau 3.2). Ces facteurs sont calibrés

sur une échelle de six niveaux de complexité dans le tableau 3.3. Ensuite, la complexité

du système est calculée par la formule TCF = 0.65 + 0.01*(&

14

1iiF , où Fi prend la valeur

de 0 à 5 qui indique le degré d’influence du facteur Fi au système. Le TCF (technical

complexity factor) est interprété comme la complexité dérivée des caractéristiques du

système et de technique de développement du logiciel. Enfin, la taille fonctionnelle

(c-à-d, les points de fonction) du logiciel est calculé par: FP = UFP * TCF.

Degré d’influence [9] Échelle Degré d’influence (en français) Not present, no influence 0 Aucun Incidental influence 1 Accessoire Moderate influence 2 Modéré Average influence 3 Moyen Signification influence 4 Significatif Strong influence throughout 5 Fort

Tableau 3.3: Six niveaux d’influence de 14 GSCs.

Selon la conception de la méthode, les points de fonction non ajustés (UFP) représentent

la taille brute du logiciel. Elle doit être ajustée par les points des facteurs techniques du

logiciel (TCF). Ces derniers peuvent affecter jusqu’à )35% de la taille brute. La taille

finale (FP) est une mesure relative à la taille et à l’effort de développement du logiciel. En

fait, dans son article en 1983, Albrecht a établi un modèle de prédiction d’effort à partir

des points de fonction du logiciel.

“The thesis of this work is that the amount of function to be provided by theapplication can be estimated from the itemization of the major components datato be used or provided by it. Furthermore, this estimation of function should becorrelated to both the amount of LOC to be developed and the development effortneeded.”

(Albrecht and Gaffney, 1983)


57

L’approche fonctionnelle d’Albrecht permet de quantifier la taille du logiciel

indépendamment de la technique et du langage de programmation. Les points de fonction

peuvent être interprétés du point de vue de l’utilisateur qui ne comprend pas beaucoup la

technique de développement. De plus, la mesure étant obtenue tôt dans le cycle de vie du

logiciel, elle peut donc servir d’indice de base pour plusieurs tâches de gestion du projet

de logiciel. En fait, les poids de la complexité des éléments de base ont été choisis pour

que les points de fonction soient en corrélation avec l’effort de développement du

logiciel. De ce fait, les points de fonction deviennent un indice de l’effort qui permet

d’analyser la productivité de projet du logiciel, planifier la production et contrôler le

budget.

3.1.3 Structure de FPA

Figure 3.1: Modèle global de la méthode de points de fonction (FPA).

La figure 3.1 illustre le modèle global de FPA présenté par Symons [158]. La taille

fonctionnelle du logiciel est mesurée selon deux volets:

!" À partir de la complexité des fonctions individuelles du logiciel mesuré, et

!" À partir de la complexité des caractéristiques générales du système.

Ces deux volets correspondent à deux étapes de mesure. Dans la première étape, la taille

fonctionnelle brute est calculée à partir du pointage de la complexité des fonctions

individuelles. Dans la deuxième étape, les caractéristiques du logiciel sont identifiées et

évaluées pour leur complexité. La somme de la complexité de ces caractéristiques sert à

ajuster la taille brute pour établir la taille fonctionnelle (finale) du logiciel – une mesure

qui indique le nombre de fonctions livrées à l’utilisateur.


58

Au niveau plus détaillé, la taille fonctionnelle d’une fonction est mesurée à partir de la

complexité des fichiers logiques relatifs à la fonction et des transactions réalisées dans la

fonction. Les fichiers logiques sont les « groupes » de données qui sont associés à la

source de données interne ou externe, tandis que les transactions sont des entrées/sorties

et interrogations. Les fichiers de données représentent les groupes de données statiques

relatifs à la fonction mesurée. Par contre, les transactions représentent les « mouvements

de données », c’est-à-dire, la partie dynamique de la fonction mesurée. Une transaction

réalise une entrée ou une sortie d’un groupe de données ou fait référence à un groupe. Un

fichier logiciel peut être relatif à plusieurs transactions d’une fonction ou de différentes

fonctions du logiciel.

3.1.4 Limites majeures de FPA

La méthode de points de fonction d’Albrecht est conçue pour les logiciels de type MIS

(systèmes d’information de gestion). Elle est un standard de facto pour mesurer la taille

des logiciels de ce type. Les points de fonction sont utilisés pour établir la productivité et

pour estimer l’effort de développement. Cependant, plusieurs limites sont reconnues à

cette méthode:

!" Un problème d’assignation subjective: la complexité des fonctions élémentaires

et de quatorze facteurs techniques est évaluée subjectivement sur l’échelle

simple, moyen et complexe ou de zéro à cinq. Le poids pour chaque catégorie est

aussi déterminé subjectivement par « débat et essai » (debate and trial [8]).

!" Un problème de double comptage: Symons [158] montre que la méthode

d’Albrecht fait un double comptage de la complexité en utilisant les facteurs UFP

et TCF.

!" Un problème avec la précision: Kitchenham [105] estime que TCF n’améliore

pas significativement la mesure de taille pour prévoir l’effort. Autrement dit, la

taille du logiciel mesurée par les points de fonction, qui combine UFP et TCF,

“This gives a dimensionless number defined in function points which we have found to be an effective relative measure of function value delivered to our customers.”

(Albrecht, 1979)


59

n’est pas meilleure que celle avec UFP seule. Par conséquent, la méthode de

mesure pourrait être simplifiée.

!" Un problème avec le domaine d’application: plusieurs recherches

[158,137,175,5,3] montrent que l’analyse de points de fonction d’Albrecht (FPA)

ne s’applique qu’aux systèmes d’information de gestion (MIS). Elle n’est pas

applicable pour les autres types de logiciel (p.ex., temps réel, scientifique,

communication).

3.2 VARIANTES DE LA MÉTHODE DE POINTS DE FONCTION

Depuis la naissance de FPA, de nombreux efforts ont été consacrés au développement de

nouvelles méthodes visant à surmonter les limites de cette mesure. Les investigations

peuvent être catégorisées en deux volets:

!" Établir des guides détaillés qui aide à évaluer la complexité des fonctions

élémentaires de façon cohérente et répétable. Les guides ont pour but de réduire

des pointages subjectifs. Ce volet ne modifie pas la structure de la mesure

originale. Par exemple: GUIDE 1985 [74], GUIDE 1989 [75], et les guides de

l’IFPUG [88-90]. Le plus récent manuel de comptage des points de fonction fut

publié par l’IFPUG en août 2004 (www.ifpug.org). Ces manuels de comptage

essaient de définir les concepts et d’établir les règles normalisées pour calculer

les points de fonction.

!" Changer la structure de la méthode pour adapter la méthode à de nouveaux types

de logiciel et pour éviter des évaluations subjectives. Les travaux dans ce volet

ont conduit à proposer des méthodes ou des variantes sur des points de fonction.

Ces méthodes mesurent des logiciels à partir de la fonctionnalité, mais le terme

de point de fonction n’est pas identique au terme utilisé par Albrecht. Les

variations bien connues de FPA sont:

o Feature Points de Jones [96] qui ajoute un nouveau type de fonction,

appelée algorithme, pour tenir compte de la complexité algorithmique.

Cette méthode propose également qu’aux fonctions élémentaires soit

toujours assigné le poids de la complexité moyenne au lieu des trois

niveaux de complexité simple, moyenne et complexe du modèle

d’Albrecht.


60

o Mark-II de Symons [158] propose une façon de quantifier objectivement

les poids des fonctions élémentaires. Au lieu de faire une assignation

subjective, Mark-II compte le nombre de transactions réalisées par une

fonction.

o Asset-R de Reifer [137] et 3D Function Point de Whitmire [175]

proposent des méthodes pouvant être appliquées aux logiciels de type

MIS ainsi qu’aux logiciels temps réel et aux logiciels scientifiques.

o Full Function Points et COSMIC-FFP [5,1,3] proposent une

simplification de FPA. COSMIC-FFP a pour but de mesurer la taille

fonctionnelle des systèmes MIS et des systèmes temps réel aussi que

systèmes hybrides.

Conceptuellement, FPA et ses variantes ont intégré la complexité du système et la

complexité des composants individuels dans une seule mesure, appelée les points de

fonction ou, parfois, la taille fonctionnelle du logiciel. Cette mesure est utilisée comme un

indice de l’effort de développement du logiciel. Deux types de complexité sont sous-

entendus dans FPA:

!" La complexité des composants qui est la complexité des items élémentaires, et

!" La complexité du système qui est mesurée par les caractéristiques générales du

système.

Plusieurs recherches (p.ex., [62]) estiment que la complexité affecte significativement la

taille du projet du logiciel et, par conséquent, l’effort de développement ou de

maintenance du logiciel. Cependant, en simplifiant FPA, certaines méthodes de mesure

de points de fonction ne couvrent pas suffisamment la complexité du logiciel. Parmi les

variations de FPA, nous nous intéressons à COSMIC-FFP. Bien que cette méthode ait été

retenue comme un standard ISO (ISO 19761:2003 http://www.cosmicon.com/), les

recherches sont encore ouvertes pour améliorer la méthode. COSMIC-FFP ne couvre ni la

complexité de manipulation de données, ni la complexité du système [1,163]. Ces limites

ont motivé notre recherche. Nous espérons qu’en tenant compte de ces aspects, une

mesure de la complexité sera capable de fournir un meilleur indicateur de l’effort de


Les variantes importantes à la mesure d’Albrecht sont introduites dans le reste de ce

chapitre. Cette revue a pour but d’approfondir l’approche des points de fonction sur

laquelle notre recherche s’est concentrée.


61

3.2.1 Mark-II

Symons [158] a remis en question la façon de déterminer le poids d’un élément de base

dans le modèle d’Albrecht. Cette question a conduit à redéfinir la structure de base du

modèle. Mark-II est basé sur le concept de transaction logique qui est compris comme

une séquence de données entrées, de traitements et de données sorties. Une transaction est

comprise comme une lecture, une modification, une suppression de données; elle accède

à des entités différentes. Symons mesure la taille d’une transaction par le nombre

d’entités (-type) affectées par la transaction, puis la taille du logiciel est la somme de la

taille de toutes les transactions.

La taille du logiciel est un indice pour évaluer la productivité et estimer l’effort de

développement du logiciel. Autrement dit, l’échelle de la complexité d’une transaction

fait référence explicitement à l’effort de développement. Cette idée diffère de celle

d’Albrecht parce que Mark-II fournit une valeur qui présente « l’effort » plutôt que le

nombre de « fonctionnalités » livrées à l’utilisateur.

La grande différence entre Mark-II et FPA réside dans la façon de quantifier la

complexité des éléments de base. FPA évalue la complexité de ceux-ci de façon

subjective, tandis que dans Mark-II, la complexité d’une transaction est comptée

objectivement par le nombre des entités-types qui sont créés, lus, mis à jour et supprimés

dans la transaction.

Les étapes de comptage des points de fonction en Mark-II sont les suivantes:

!" Identifier les entités.

!" Identifier les transactions logiques.

!" Identifier les types d’éléments en entrée, les entités de référence (entités

consultées par la transaction) et les types d’éléments en sortie.

!" Compter le nombre d’entités pour chaque type d’éléments ci-dessus (c-à-d,

entrée, référence et sortie).

Puis, le nombre de points de fonction du logiciel est calculé en utilisant la formule:

It seems a reasonable hypothesis that a measure of processing complexity is to countthe number of entity-types referenced by the transaction-type, referenced meanscreated, updated, read or deleted.

(Symons, 1988).


62

UFP = NIWI + NEWE + NOWO

Où: UFP est la taille non-ajustée.

NI est le nombre de types d’éléments en entrée.

NE est le nombre de références.

NO est le nombre de types d’éléments en sortie.

WI, WE et WO sont les poids de type d’entrée, référence et sortie, respectivement.

Ces poids sont déterminés empiriquement en utilisant une base de données

historiques pour que la mesure de Mark-II soit bien corrélée avec les points de

fonction bruts (UFP) d’Albrecht, puis ensuite avec l’effort de développement du

logiciel.

Mark-II diffère de FPA dans la façon de voir les données. En fait, il dénombre l’usage de

données dans les transactions, tandis que FPA compte des groupes logiques de données,

indépendamment de leur utilisation. De plus, Mark-II tient compte de la complexité en

parlant de la complexité structurelle qui est basée sur les travaux de McCabe selon

lesquels la complexité est caractérisée par le nombre de branchements et de boucles. En

utilisant des résultats de Jackson [92], Symons estime qu’une fonction bien structurée

devrait correspondre à la structure logique présentée par le chemin d’accès de la

transaction à travers le modèle entité-relation de toute l’application. Chaque étape (le long

du chemin d’accès) implique une sélection ou un branchement ou une boucle. Alors, il est

raisonnable que la complexité d’une transaction soit mesurée par le nombre de types

d’entités qui sont accédées par la transaction. Comme FPA, Mark-II est applicable aux

systèmes de type MIS seulement.

Les idées à retenir de Mark-II sont les suivantes:

!" La taille du logiciel est basée sur les entrées et les sorties de la transaction et la

manipulation des données.

!" La manipulation de données dans la transaction est caractérisée par les entités

référencées par la transaction.

!" La complexité est basée sur l’idée de McCabe. C’est-à-dire, elle tient compte des

branchements dans la transaction.

Les idées de Symons sont très intéressantes car elles proposent une façon de mesurer

objectivement les points de fonction bruts. De plus, elles proposent aussi une façon

d’appliquer la mesure de McCabe pour mesurer les points de fonction. La complexité des


63

composants dans ce sens fait référence à la complexité de structure des composants

(c-à-d, des transactions). Ces idées constituent des pistes pouvant guider les propositions

pour mesurer la complexité dans cette thèse.

3.2.2 Feature Points

Une autre variante de FPA, afin de l’adapter aux systèmes temps réel et aux systèmes

incorporés (embedded system), est proposée par Jones [96]. Pour les systèmes de ce type,

Jones estime que le logiciel est complexe à cause de l’algorithme mais comporte peu

d’entrées et sorties. Aux cinq types de fonctions élémentaires de FPA, il ajoute un

nouveau type de fonction qui fait référence à des algorithmes, appelé algorithme. Un

algorithme est défini comme un ensemble des règles qui doivent être exprimées

complètement pour résoudre significativement le problème computationnel [96]. Dans

nos termes, les règles mentionnées par Jones sont des spécifications sur les manipulations

de données qui se produisent dans une fonction du logiciel. Ces règles précisent ce qu’il

faut faire (dans une fonction) pour obtenir les résultats désirés. Jones propose que le

nombre des étapes de calcul et le nombre des données élémentaires manipulées par

l’algorithme correspondent à la complexité de l’algorithme. Cependant, Whitmire [175] a

montré que la définition d’algorithme (-type) et les règles pour mesurer la complexité de

ce type de fonction ne sont pas suffisantes pour pouvoir identifier et mesurer ce type de

fonction.

Nous pensons que la définition de type algorithme de Jones n’est pas applicable à la

phase de l’analyse du logiciel parce que, à cette phase, l’algorithme de traitement des

données n’est pas bien spécifié. Les spécifications du logiciel n’expriment pas

complètement les étapes de calcul. Parfois, on ne connaît pas quel algorithme sera choisi

pour l’implémentation. Par exemple, à partir d’une spécification, on peut identifier un tri

d’une liste d’éléments, mais il est difficile de dire quel algorithme va être utilisé. Alors, la

complexité de l’algorithme en termes de Jones pourrait être indéterminable. Il est

nécessaire de chercher un niveau d’abstraction plus élevé pour définir la complexité de la

manipulation de donnée si la mesure n’est basée que sur les spécifications.


64

Poids Complexité du problème Complexité du code Complexité des données 1 Algorithmes et calculs

simples Non procédural (chiffrier) Données simples avec peu

de variables et de complexité 2 Majorité des algorithmes et

calculs simples Construit avec des squelettes de programmes et du code réutilisé

Beaucoup d’éléments de données mais avec des relations simples

3 Algorithmes et calculs de complexité moyenne

Bien structuré (petit module et logique simple)

Fichiers, indicateurs et interactions multiples

4 Quelques difficultés ou complexité des algorithmes ou calculs

Structure moyenne mais quelques modules et chemins complexes

Éléments de données et interactions de données complexes

5 Plusieurs algorithmes et calculs difficiles et complexes

Piètre structure et plusieurs modules et chemins complexes

Éléments de données et interactions très complexes.

Tableau 3.4: Critères et les poids de la complexité [97]1.

L’idée de la méthode est attrayante parce qu’elle confirme que la complexité des

manipulations de données doit être prise en compte. Malheureusement, cette méthode

n’est pas du domaine public. La méthode a aussi confirmé la contribution des interactions

et des relations entre les données et la complexité de la manipulation des données. Les

critères pour calibrer la complexité sont divisées en trois volets – problème, code et

données – comme dans le tableau 3.4.

Ces critères ne permettent pas de compter la complexité de façon objective. De ce fait,

Feature Points rencontre les mêmes limites que FPA à ce sujet. De plus, la base de

données expérimentales de Jones n’est pas du domaine public. Ni la base de données de

Jones, ni ses méthodes statistiques, ni ses méthodes d’analyse ne sont publiées. Cela

empêche de vérifier la validité de la méthode.

3.2.3 Asset-R

En 1990, Reifer [137] a proposé une méthode pour mesurer la taille des applications

scientifiques et des applications temps réel. Sa méthode est de type « points de fonction »,

c-à-d, les points dérivés des caractéristiques des applications. Cependant, on doit noter

que la méthode de Reifer est loin de la version originale d’Albrecht (FPA). Le terme

« point de fonction » utilisé par Reifer diffère de celui utilisé dans FPA, Mark-II et

Feature Points.

1 Le texte en français dans le tableau est extrait de [4], p.70.


65

Pour Asset-R, les points de fonction d’une application sont calculés sur des indices de

base comme les suivants:

!" nombre d’entrées

!" nombre de sorties

!" nombre d’interrogations

!" nombre de fichiers

!" nombre d’interfaces

!" nombre de nœuds

!" nombre de rendez-vous, et

!" nombre de relations stimulus/réponse

L’entrée, la sortie, l’interrogation et le fichier (-type) sont des termes définis dans FPA.

L’interface fait référence aux utilitaires communs, les librairies mathématiques, les

librairies de programmes et les bases de données. Les nœuds, les rendez-vous et les

stimulus/réponses sont des termes associés aux systèmes temps réel. La formule générale

de comptage des points de fonction d’une application est:

FPA = K

yw iin

1i*&

Où: FPA: points de fonction de Reifer.

yi est le nombre d’entrées/sorties, interrogations, etc., qui sont énumérées ci-

dessus.

wi est le poids qui correspond à chaque type de fonction (entrée, sortie, etc.)

K est le facteur ajusté de la complexité (une constante correspondant au type de

l’application).

Reifer a aussi proposé une formule mathématique pour estimer la taille de l’application en

terme de lignes de code à partir de son calcul des points de fonction:

SIZE = ARCH * EXPF * (FPA * LANG + MVOL) +

Où:

SIZE: taille en lignes de code

ARCH: constante d’architecture

EXPF: facteur d’expansion


66

FPA: points de fonction (de Reifer)

LANG: constante de langage (un facteur de conversion FPA en lignes de code)

MVOL: volume mathématique

+: facteur de réutilisation

Dans ses travaux, Reifer a fourni les constantes utilisées dans la formule ci-dessus.

Cependant, les concepts, les nouveaux types de fonction et les règles de mesure ne sont

pas définis clairement. Il n’est pas clair sur ce qu’il veut mesurer et sur le comment de la

mesure. Par conséquent, il est difficile de valider la méthode et de la mettre en pratique.

Dans la littérature, on peut trouver un certain nombre d’exemples de Reifer, mais aucune

validation de cette mesure n’a été publiée.

3.2.4 Points de fonction 3D (3D Function points)

Whitmire [175] propose une méthode de mesure de la taille du logiciel avec l’approche

des points de fonction. Sa méthode pourrait être considérée comme une adaptation de la

méthode de points de fonction originale aux systèmes temps réel. Les points de fonction

de Whitmire couvrent trois dimensions (3D) du logiciel: données, fonctions et contrôles.

Les points de fonction sont la somme du nombre des: entrées, sorties, interrogations,

structures de données internes, fichiers logiques externes, transformations et transitions.

Les cinq premiers caractérisent la dimension « données ». Le nombre de transformations

et le nombre de transitions caractérisent « fonction » et « contrôle » respectivement.

Whitmire estime que dans un environnement multi-langages et multi-infrastructures, les

lignes de code sont incohérentes. Les points de fonction 3D peuvent fournir de bonnes

mesures de la taille du logiciel de type scientifique ou temps réel. Cette méthode est aussi

valable pour la conception orientée objet. Cependant, nous ne trouvons aucune

publication qui confirme l’avantage ainsi que les problèmes rencontrés à l’utilisation de

cette méthode. La méthode demeure encore privée chez Boeing.

3.2.5 COSMIC-FFP

COSMIC-FFP est une méthode de points de fonction proposée par COSMIC2. Cette

méthode est applicable aux systèmes de type MIS ainsi qu’aux systèmes temps réel.

2 COSMIC: the Common Software Measurement International Consortium.


67

Selon COSMIC, un logiciel est un ensemble de processus fonctionnels dont chacun est un

ensemble de mouvements de données et un ensemble de manipulations de données

(figure 3.2).

Figure 3.2: Modèle du logiciel de COSMIC.

COSMIC définit le nombre de mouvements de données comme les points de fonction (ou

la taille fonctionnelle du logiciel). Cette méthode ne tient pas compte des manipulations

de données. Conceptuellement, un mouvement de données est un groupe logique de

données en entrée ou en sortie. Pour faciliter l’identification des mouvements de données,

COSMIC distingue quatre types de mouvement: Entrée (Entry), Sortie (Exit), Lecture

(Read), Écriture (Write) (figure 3.3).

Figure 3.3: Quatre types de mouvement de données de COSMIC.

!" Un groupe de données provenant de l’extérieur du système est une Entrée

!" Un groupe de donnée qui sort du système vers l’utilisateur ou vers un autre

système est une Sortie


68

!" Un groupe de données qui vient d’un équipement de stockage (p.ex., le disque, la

mémoire, etc.) est une Lecture.

!" Un groupe de données en sortie vers un équipement de stockage (p.ex., le disque,

la mémoire, etc.) est une Écriture.

Puis, la taille du logiciel = le nombre de mouvements de données

= le nombre d’Entrées + le nombre de Sorties

+ le nombre de Lectures + le nombre

d’Écritures.

Dans le manuel de COSMIC [3], les auteurs ont estimé que la méthode COSMIC-FFP est

conçue pour les systèmes riches en mouvements de données (movement-rich), mais elle

est limitée pour les systèmes avec des manipulations complexes. Cette méthode ignore

aussi la complexité dérivée de la relation entre les processus fonctionnels du logiciel.

Certains travaux [2,165] ont montré que la mesure de COSMIC pourrait être utilisée pour

estimer l’effort de développement du logiciel. Cependant, le taux d’erreurs d’estimation

est encore élevé. Dans une recherche antérieure [165], nous avons construit un modèle

d’estimation d’effort à partir de COSMIC-FFP. Le taux d’erreurs moyen de ce modèle est

40%, bien qu’il soit meilleur que certains autres modèles de même type. Une autre étude

empirique [2] utilisant 15 projets de maintenance a trouvé un résultat similaire au nôtre.

Le taux d’erreurs moyen de l’estimation d’effort pour COSMIC-FFP est 45%. Nous

voulons donc proposer une adaptation de COSMIC-FFP pour améliorer la performance

d’estimation de l’effort de développement du logiciel. Les améliorations se concentrent

sur la complexité de la manipulation de données dans un processus fonctionnel et la

complexité de relation entre les processus fonctionnels.

3.3 CADRE GÉNÉRAL DE LA COMPLEXITÉ DES MÉTHODES DE POINTS DE FONCTION

L’approche des points de fonction a des avantages par rapport à l’approche de mesure à

partir de code source. Premièrement, les méthodes de mesure basées sur la fonctionnalité

du logiciel peuvent fournir des résultats dès la phase de l’analyse et de spécifications du

logiciel. De plus, ces mesures sont indépendantes du langage de programmation et des

outils utilisés. Par conséquent, elles sont compréhensibles aux utilisateurs et aux clients

(qui commandent le logiciel et qui payent pour le logiciel).


69

Le point commun de toutes les méthodes de points de fonction est le concept de « taille »;

il est mis en relation avec l’effort de développement du logiciel. Les méthodes existantes

proposent toujours une échelle de mesure des points ajustés pour que la taille

fonctionnelle soit en bonne corrélation avec l’effort de développement. Aucune mesure

n’a pour but de mesurer l’effort, mais toutes les mesures existantes sont associées à leurs

propres modèles d’estimation d’effort (p.ex., les modèles d’estimation d’effort publiés

dans [9,2]).

Un autre point commun est que les points de fonction ne sont pas comptés

indépendamment de la complexité. Les méthodes de points de fonction, exceptée

COSMIC-FFP, essaient d’intégrer la complexité des composants et celle du système dans

les points de fonction. Deux aspects de la complexité mentionnée dans les méthodes de

points de fonction sont:

!" La complexité des composants qui fait référence à la complexité de chaque

composant individuel.

!" La complexité du système qui tient compte des caractéristiques générales du

système et de relations entre les composants.

La complexité des composants est évaluée à partir des données entrées/sorties et de la

manipulation des données des composants. De ce fait, ce type de complexité fait

référence à deux aspects d’un composant individuel: les entrées/sorties et la structure

interne du composant.

Ces caractéristiques communes des méthodes de points de fonction permettent de définir

un cadre général de la complexité fonctionnelle, illustré à la figure 3.4. Ce cadre répond à

la question: qu’est-ce qui doit être investigué pour obtenir un bon indice de l’effort de

développement, c’est-à-dire, pour quantifier la complexité fonctionnelle du logiciel?

Figure 3.4: Cadre général de la complexité basée sur les méthodes de points de fonction.


70

La figure 3.4 propose une image globale pour préciser ce qu’il faut cerner sur la notion de

complexité mentionnée dans les méthodes de points de fonction. Bien qu’il n’existe pas

de consensus sur comment mesurer ces aspects de la complexité, la famille des mesures

de points de fonction a montré clairement que les données entrées et sorties, la structure

de la manipulation interne de chaque composant individuel et les relations entre les

composants sont des dimensions pertinentes pour caractériser la complexité – mesure qui

peut être associée à l’effort de développement du logiciel.

Le tableau 3.5 représente une courte analyse des mesures de points de fonction pour

montrer comment la complexité est prise en compte par ces mesures. Dans ce tableau, la

première colonne contient le nom de la méthode. La deuxième et la troisième colonne

représentent deux aspects de la complexité des composants: les données entrées/sorties et

la structure des composants. La quatrième colonne représente la complexité du système.

La dernière colonne montre comment les points de fonction totaux sont établis.

Complexité des composants Méthode Données entrées/sorties

Structure des composants

Complexité du système (de relations entre les composants)

Points de fonction totaux

FPA Concepts

les intrants, extrants, et les requêtes, les fichiers internes, externes

« complex processing » (caractéristique 9 dans le tableau 3.2)

Data communication, distributed processing et complex processing (caractéristiques 1,2 et 9 dans le tableau 3.2)

Façon de mesurer

Subjective: utilise les guides et les tableaux de décision

Subjective en se basant sur les guides

Subjective en se basant sur les guides

Combinaison des mesures des composants (UFP) et des mesures des caractéristiques du système (DI – degré d’influence)

MARK-II Concepts

Entrées, sorties et les transactions – une combinaison d’entrées, sorties et manipulations

La structure de branchement et des boucles

Comme FPA - la taille brute (UFP) est une mesure objective à partir du nombre des


71

Façon de mesurer

Le nombre des entités en entrées et en sorties

Mesurée objectivement par le nombre d’entités concernant la transaction (les entités lues, mises à jour, modifiées, supprimées)

Comme FPA nombre des entités entrées, sorties et référencés - La taille ajustée (FP) est une combinaison de la taille brute et les caractéristiques du système (similaire à FP dans FPA)

Feature Points Concepts

La complexité des données

La complexité de l’algorithme

Comme FPA

Façon de mesurer

Subjective: utilise les guides

Subjective: utilise les guides

Comme FPA

Comme FPA

ASSET-R Concepts

entrées, sorties, interrogations, fichiers, interfaces

nœuds, rendez-vous

relations stimulus/ réponse

Façon de mesurer

nombre d’entrées, nombre de sorties, nombre d’interrogations, nombre de fichiers, nombre d’interfaces

nombre de nœuds, nombre de rendez-vous

nombre de relations stimulus/ réponse

Une combinaison des mesures objectives dans les colonnes à gauche

Points de fonction 3D Concepts

Données Fonction: la manipulation de données

Contrôle: relation de contrôle entre les fonctions

Façon de mesurer

Nombre des entrées, sorties, requêtes, fichiers internes, fichiers externes

Nombre de transformations

Nombre de transitions

Une combinaison des mesures objectives dans les colonnes à gauche

COSMIC-FFP Concepts

Mouvement de données

Manipulation de donnée

Pas mentionnée

Façon de mesurer

Le nombre total de mouvements de données: entrées, sorties, lectures et écritures

Pas mesurée

Nombre total de mouvements de données

Tableau 3.5: Analyse des mesures de points de fonction selon le cadre de la complexité dans la figure 3.4.


72

Chaque mesure est analysée en deux lignes. La première ligne montre le concept utilisé

par la méthode pour aborder la complexité. La deuxième ligne montre la façon de

mesurer la complexité.

L’analyse faite dans le tableau 3.5 montre qu’il n’y a pas de consensus sur ce qui doit être

mesuré et sur la façon de le mesurer. Chaque méthode propose des concepts propres et

une façon de les quantifier. Les termes « la taille du logiciel », « la taille fonctionnelle »,

« la complexité » n’ont pas un sens unique d’une méthode à l’autre. De ce fait, les points

de fonction du logiciel sont un concept associé à une mesure plutôt qu’un concept associé

au logiciel. Ainsi, quand on parle de points de fonction, il faut bien noter à quoi ce

concept réfère dans chaque méthode.

3.4 UTILISATION DES POINTS DE FONCTION

Bien que les mesures fonctionnelles du logiciel (c-à-d, les points de fonction) ne mesurent

pas la même chose, le but de la mesure est le même: chercher des mesures pour

caractériser la complexité du logiciel à partir de ses spécifications. De plus, ces mesures

doivent fournir des indices appropriés permettant de comparer des projets de logiciel et

d’estimer l’effort de développement du logiciel. Les points de fonction sont souvent

utilisés comme un indice de base qui indique le volume du logiciel, c’est-à-dire un indice

de la grandeur et de la complexité des fonctionnalités du logiciel. De ce fait, ils sont un

paramètre du modèle de productivité, d’estimation de l’effort et du coût du logiciel.

Garmus et Herron [67] ont fait un bilan de l’utilisation des points de fonction dans

l’industrie (tableau 3.6).

Type Mesures Description Productivité Points de fonction/effort Points de fonction par

homme-mois Capacité de développement (Responsiveness)

Points de fonction/durée Points de fonction par mois de calendrier

Qualité Nombre de défauts (defects)/ points de fonction

Nombre de défauts par point de fonction

Affaire (Business) Coût / point de fonction Coût unitaire d’un point de fonction

Tableau 3.6: Utilisation des points de fonction dans l’industrie [67].


73

3.4.1 Productivité

La productivité est une mesure de l’efficacité d’un processus. Elle correspond au ratio de

produit construit ou livré (selon une certaine unité de mesure) par unité de ressources

payées.

En génie logiciel, la productivité de développement du logiciel est définie comme le

rapport de la taille du logiciel sur l’effort payé pour développer ce logiciel.

Productivité = efforttaille

(1)

La taille pourrait être le nombre de lignes de code ou les points de fonction ou n’importe

quelle mesure de la taille (p.ex., les mesures de Halstead dans le chapitre précédent).

L’effort est le temps en termes d’homme-mois ou d’homme-heures. De ce fait, la

productivité indique l’efficacité du programmeur, l’efficacité de l’équipe de

développement et l’efficacité de la production. Si les points de fonction sont utilisés

comme formule de productivité, la productivité indique le nombre de points de fonction

produits dans une unité de l’effort.

La mesure de productivité (1) est une mesure postérieure, c’est-à-dire qu’elle n’est qu’une

valeur calculée après la production. Elle est utilisée pour réviser le processus de

production, comparer les projets et pour améliorer le processus de production.

Dans la pratique, on a besoin non seulement de mesures postérieures mais aussi de

mesures antérieures. Il est très utile de savoir que pour un projet de x points de fonction

on a besoin de combien de temps du calendrier ou combien d’effort (homme-mois) pour

le réaliser. Les mesures de ce type jouent un rôle important dans la planification de la

production pour compléter le projet dans le temps et le budget prévu.

3.4.2 Estimation d’effort

3.4.2.1 Techniques d’estimation et qualité d’estimation Pour des projets similaires – c’est-à-dire que les fonctionnalités des logiciels à développer

sont similaires, l’environnement est similaire – les points de fonction de ces projets sont

Productivity: the rate of output per unit input used especially in measuringcapital growth, and in assessing the effective use of labour, materials andequipment.

(Oxford English Dictionary, 2nd edition)


74

identiques. Donc, si on suppose que la productivité ne change pas, les points de fonction

peuvent être utilisés comme un indice de l’effort.

Effort = productivité x taille (2)

Cependant, la productivité n’est pas une constante parce qu’il n’y pas deux projets

identiques en réalité. De ce fait, l’analyse de régression linéaire est souvent utilisée pour

chercher une estimation de l’effort. Cette technique demande une base de données

historiques dans laquelle l’effort réel (Er) investi dans un projet et les points de fonction

(PF) de celui-ci sont collectés. L’analyse de régression linéaire entre Er et PF conduit à

établir une relation linéaire entre eux sous la formule:

E = a*PF + b (3)

Dans l’équation (3), E représente une estimation de Er – une valeur « proche d’Er ».

Idéalement, E est égale à Er pour tous les projets. C’est-à-dire que si l’équation (3) fournit

une estimation parfaite, le taux d’erreurs de l’estimation est nul. Cependant,

généralement, E et Er ne sont pas identiques. Alors, la qualité de l’estimation doit être

analysée. La qualité d’un modèle d’estimation construit en se basant sur une analyse de

régression linéaire est évaluée par deux mesures:

!" Le coefficient de corrélation (R2) qui indique la corrélation entre les deux

variables considérées (c-à-d, la force de relation entre les deux variables). Le

coefficient varie de 0 à 1 pour indiquer une corrélation de plus faible à plus forte.

!" La amplitude d’erreur relative (Magnitude of Relative Error –MRE)

MRE = r

r

EEE ,

(4)

L’amplitude d’erreur relative représente le taux d’erreurs relatives de l’estimation pour

chaque projet dans la base de données. Pour certains projets, ce taux d’erreurs est très

petit, mais pour certains autres, il est grand. De ce fait, l’important est de savoir:

!" Comment bonne ou mauvaise est l’estimation en général (c-à-d, en moyenne)?

!" Quel est le taux de projets avec une bonne (ou mauvaise) estimation?

La réponse à la première question est le taux d’erreurs relatives moyen ou simplement le

taux d’erreur moyen (Mean Magnitude of Relative Error):


75

MMRE = n

n

ii(

&1MRE

(5)

Où n est le nombre de projets dans la base de données, MREi est l’amplitude d’erreur

relative du projet i.

La réponse à la deuxième question conduit à l’analyse du taux de projets ayant une marge

d’erreur considérée. Dans le domaine de mesure du logiciel, cette analyse est basée sur

une mesure appelée la qualité du modèle de prédiction (PRED). Elle est définie comme

suit:

PRED (x) = n

x-MREayant projets de nombre le (6)

Où: n est le nombre de projets dans la base de données.

Dans la pratique, Conte [49] propose qu’un bon modèle d’estimation d’effort devant être

capable de fournir une estimation avec un taux d’erreurs de moins de 25% dans 75% des

cas, c’est-à-dire PRED(0,25) . 0,75.

La technique de régression linéaire est souvent utilisée pour établir un modèle de

prédiction. Quant aux mesures (4), (5) et (6), elles sont souvent utilisées pour analyser la

performance du modèle d’estimation. Les travaux publiés dans [2,9,49,102,165] donne de

bons exemples de l’utilisation de ces mesures pour analyser la performance de prédiction

de l’effort. Dans le chapitre 6, la régression linéaire est utilisée pour établir les modèles

de prédiction de l’effort. Ces modèles, ensuite, sont analysés et comparés selon les

mesures (4), (5) et (6).

3.4.2.2 Quelques modèles d’estimation d’effort à partir des points de fonction

Dans la littérature, il existe plusieurs modèles d’estimation d’effort à partir des points de

fonction. Les points de fonction sont mesurés en utilisant des méthodes différentes

comme FPA, Mark-II, COSMIC-FFP,… Dans cette section, certains modèles

d’estimation d’effort à partir des points de fonction mesurés par FPA et COSMIC-FFP

sont présentés. Il est difficile de ramasser tous les modèles d’estimation parce qu’ils sont

nombreux. De plus, chaque modèle est construit en se basant sur une base de données

empirique qui n’est souvent pas du domaine public. Le tableau 3.6 résume certains

modèles bien connus.


76

Modèle Effort Observations R2 PRED(0,25) MMRE référence E = 54*FPA – 13,39 Heures

de travail 24 0,85 0,52 0,35 [9]

E=0,355*FPA-88 Homme-mois

15 0,87 N/A 1,03 [102]

E=0,65*CFFP + 8,97 Application Web

Heures de travail

15 0,83 0,53 0,45 [2]

E=4,49*CFFP+ 83 Application temps réel

Heures de travail

18 0,84 0,555 0,40 [2]

E=0,72*CFFP0,81 Homme-mois

10 0,85 0,50 0,40 [165]

Tableau 3.7: Quelques modèles d’estimation d’effort et leur performance.

À partir de tableau 3.7, on peut observer que le taux d’erreurs d’estimation est encore

élevé. Il est beaucoup plus élevé que le seuil acceptable dans la pratique proposée par

Conte. Le taux d’erreurs moyen (MMRE) est environ 40% et la qualité de prédiction

(PRED) est environ 50%. Ces taux d’erreurs montrent que ces méthodes de points de

fonction ne capturent pas bien la complexité du logiciel – ce qui affecte l’effort de

développement. Une recherche d’Abran [2] estime que l’effort dépend non seulement de

la taille du logiciel (mesurée par COSMIC-FFP) mais aussi de la difficulté de

l’application. La question est de savoir comment on peut quantifier la difficulté (c-à-d,

complexité) comme une mesure additionnelle qui permet de mieux estimer l’effort.

3.5 PROBLÉMATIQUE DE RECHERCHE

La revue de littérature dans ce chapitre a montré des problèmes existants dans les mesures

de points de fonction actuelles. Le concept de point de fonction est toujours associé à la

complexité de la fonctionnalité du logiciel (c-à-d, la complexité fonctionnelle), mais

celle-ci n’est pas encore bien expliquée et bien capturée par les méthodes existantes. Par

conséquent, les points de fonction ne reflètent pas encore bien l’effort de développement.

De ce fait, chercher un cadre théorique pour ce concept et chercher une façon appropriée

pour capturer la complexité fonctionnelle du logiciel afin d’augmenter la précision de

l’estimation d’effort de développement du logiciel sont les problèmes à résoudre dans

cette thèse.


77

3.5.1 Cadre d’analyse de la complexité fonctionnelle

Les mesures de points de fonction essaient de déterminer une valeur qui reflète le volume

du logiciel. Intuitivement, les points de fonction font référence au nombre de

fonctionnalités du logiciel fournies à l’utilisateur. Cette valeur est appelée la taille

fonctionnelle du logiciel et, par sa conception, elle doit être cohérente avec l’effort de

développement du logiciel. La taille fonctionnelle est mesurée en évaluant la complexité

des composants du logiciel et les caractéristiques du logiciel. Comme illustré dans le

tableau 3.5, chaque mesure définit ses propres éléments de base et ses propres

caractéristiques du système. Chacune définit aussi sa propre façon d’évaluer la

complexité des éléments de base. De ce fait, les points de fonction ne sont pas

indépendants de la mesure de la complexité. Cependant, aucune mesure ne propose

explicitement un modèle de la complexité. Il semble que la complexité du logiciel n’est

pas encore expliquée et capturée de façon appropriée dans les méthodes de points de

fonction.

Un cadre de la complexité pourrait aider à mieux comprendre ce qu’on veut mesurer et

pourrait aider à chercher des mesures appropriées. Il guiderait le développement de

méthodes de mesure de plus en plus solides au point de vue théorique et il permettrait de

comparer les différentes méthodes et de valider une nouvelle méthode.

Les chapitres 4 et 5 visent à définir un tel cadre. Dans ces chapitres, l’approche de la

complexité de la tâche est utilisée pour établir un cadre général de la complexité du

logiciel. Le logiciel est considéré comme une tâche à réaliser par le logiciel et la

complexité du logiciel est modélisée d’après le modèle de la complexité de la tâche de

Wood.

3.5.2 Problème d’évaluer la complexité

Les méthodes de points de fonction bien connues dans le domaine public comme FPA,

Mark-II et Feature Points évaluent encore la complexité de façon subjective en se basant

sur les guides et l’expérience des mesureurs. C’est la plus grande limite de FPA et de ses

variantes. Il y a eu des essais pour surmonter le problème en proposant des méthodes dans

lesquelles la complexité est évaluée objectivement, par exemple, ASSET-R et Points de

fonction 3D. Malheureusement, ces méthodes ne sont pas du domaine public. Elles

appartiennent à des compagnies comme NASA et Boeing. Par conséquent, il est difficile

de discuter de la validité de ces méthodes.


78

La mesure de COSMIC ne s’intéresse qu’à des mesures objectives. Cependant, elle ne

s’intéresse pas à la complexité structurelle des composants et à la complexité du système,

ce qui est recherché dans les autres méthodes (voir le tableau 3.5).

Dans le but de chercher une mesure qui capture bien la complexité du logiciel et reflète

bien l’effort de développement du logiciel, nous pensons que les trois aspects de la

complexité relevés dans le tableau 3.5 sont des aspects nécessaires. C’est-à-dire qu’ils

sont des aspects à considérer dans la proposition d’une nouvelle méthode de mesure. La

nouvelle méthode proposée dans cette thèse cherchera à inclure ces trois aspects de la

complexité.

3.6 RÉSUMÉ

Dans ce chapitre, on a présenté des méthodes de mesure de points de fonction. Le but de

ces méthodes est de déterminer une valeur (les points de fonction), à partir de la

fonctionnalité du logiciel, qui reflète bien l’effort de développement.

Les points de fonction font référence au volume du logiciel à développer. Ils sont une

mesure pour indiquer quelle est la grandeur du logiciel en se basant sur la fonctionnalité

du logiciel, c’est-à-dire du point de vue de l’utilisateur. La revue sur les méthodes de

points de fonction dans ce chapitre supporte l’établissement d’un cadre général dans

lequel les points de fonction sont une mesure composée du nombre de composants, de la

complexité des composants individuels et de la complexité de relations entre les

composants du système.

Les points de fonction, en principe, sont une mesure de la complexité. En fait, ils sont

calculés en se basant sur l’évaluation de la complexité des composants et de la complexité

du système. Cependant, ces concepts sont implicites: aucune méthode ne s’appuie sur un

cadre théorique de la complexité. De ce fait, le terme « point de fonction » ne fait pas

référence à la même chose dans chacune des méthodes. La façon d’évaluer la complexité

est aussi différente. Certaines méthodes quantifient subjectivement la complexité (p.ex.,

FPA, Feature Points). D’autres méthodes quantifient objectivement les caractéristiques de

la complexité (p.ex., Mark-II). La revue de la littérature des méthodes de points de

fonction présentée dans ce chapitre se concentre sur ce qui est capturé par ces méthodes

plutôt que sur comment les quantifier. Elle conduit à définir un cadre général de la

complexité fonctionnelle (figure 3.4). Une méthode de points de fonction fait référence

plus ou moins à la complexité, mais elle respecte toujours le cadre de la figure 3.4. FPA,


79

MARK-II, ASSET-R et Points de fonction 3D font toutes référence aux trois dimensions:

données entrées et sorties, structure des composants et relations entre les composants. Par

contre, COSMIC-FFP se limite à une seule dimension, à savoir la complexité des

entrées/sorties.

Ce chapitre a aussi identifié notre problématique de recherche. Les problèmes de cette

recherche concernent la structure de la mesure de points de fonction. Les questions de

recherche sont reliées à la définition d’un cadre conceptuel de la complexité, c’est-à-dire,

chercher la réponse à la question: quels sont les aspects de la complexité qui doivent être

pris en compte dans une méthode de points de fonction? Ensuite, il s’agit de rechercher

une façon de quantifier objectivement ces aspects. L’évaluation subjective de la

complexité – un point faible de FPA et de certaines de ses variantes – devrait être évitée.

D’autres problèmes qui concernent la validation des mesures, la conformité de la méthode

à la théorie de la mesure et l’efficacité de la mesure doivent aussi être considérés comme

des cibles à atteindre pour cette recherche.

CHAPITRE 4

MODÈLE DE LA COMPLEXITÉ DE LA TÂCHE Dans ce chapitre, le modèle de la complexité de la tâche est introduit comme un modèle

cognitif pour décrire la complexité fonctionnelle du logiciel. Un logiciel peut être

décomposé en un ensemble de fonctions bien cohérentes pour accomplir une tâche dans le

monde réel (c-à-d, le problème à résoudre par l’ordinateur). Chaque fonction est

modélisée comme un processus de traitement de l’information et caractérisée par ses

entrées, ses manipulations (ou transformations) et ses sorties. Un logiciel est décomposé

en fonctions et sous-fonctions de la même façon qu’une tâche est décomposée en sous-

tâches et activités. Par cette modélisation, la complexité fonctionnelle du logiciel peut

être étudiée selon le modèle de la complexité de la tâche.

Le modèle de la complexité de la tâche de Wood est utilisé comme un guide théorique

pour définir un cadre d’analyse de la complexité du logiciel et des mesures permettant de

quantifier la complexité. Ce modèle répond aux deux questions:

!" Qu’est-ce qu’il faut mesurer pour quantifier la complexité de la tâche? et

!" Comment peut-on le mesurer?

Les réponses à ces deux questions sont adéquates pour répondre à des questions similaires

sur la complexité du logiciel parce que le logiciel est modélisé comme une tâche.

4.1 COMPLEXITÉ DE LA TÂCHE

La complexité de la tâche a été étudiée, surtout en psychologie, pour comprendre ce qui

cause cette complexité et pour pouvoir la réduire. Les recherches se sont développées en

deux approches:

!" L’approche psychologique qui définit la complexité en terme de capacité par

rapport au processus cognitif de l’individu qui réalise la tâche. Par exemple,

March et Simon [116] estiment que les tâches sont plus ou moins complexes

relativement aux capacités de l’individu qui réalise la tâche. Les mesures de la

Modèle de la complexité de la tâche

81

complexité de cette catégorie sont basées sur les caractéristiques psychologiques

de l’être humain plutôt que les caractéristiques de la tâche. Il est évident qu’une

tâche comme « chercher la racine carrée de 143 » est un problème dont la

difficulté (c-à-d, la complexité) varie une personne à l’autre, notamment entre un

novice et un expert. La complexité de ce type n’est pas reliée à la tâche mais

plutôt à la capacité ou à la connaissance de l’individu.

!" L’approche de la complexité objective définit la complexité de la tâche en se

basant sur des caractéristiques de la tâche. Cette approche offre des mesures

objectives de la complexité, indépendantes de la personne réalisant la tâche. Par

exemple:

Schwab et Cummings [139] proposent que la complexité de la tâche soit mesurée

par (a) la magnitude de la stimulation, (b) la variation de la stimulation et (c) le

nombre de modalités sensorielles affectées par la stimulation.

March et Simon [116] identifient trois aspects de la complexité. D’abord, les

tâches complexes sont caractérisées par les alternatives inconnues ou incertaines

et les conséquences de l’action. Ensuite, les tâches sont caractérisées par les

connexions entre les fins et les moyens (means-ends) inexactes ou inconnues.

Enfin, les tâches complexes sont caractérisées par l’existence d’un nombre de

sous-tâches qui pourraient ne pas être faciles à distribuer aux parties

indépendantes.

De façon similaire, Terborg et Miller [159] définissent la complexité en termes de

multiplicité de chemins-buts (c-à-d, plusieurs façons d’accomplir une tâche). La

complexité peut surgir de deux façons: (a) plusieurs possibilités à considérer mais

un seul chemin fonctionne; (b) plusieurs chemins conduisent au but, mais il faut

chercher un chemin optimal.

La recherche de Steinmann [153] sur les multi-éléments d’information (multi-

cues) a suggéré de définir la complexité par (a) le nombre d’éléments/sources

d’information (information-cues), (b) les interrelations entre les éléments

d’information, et (c) le principe de l’intégration d’information.

Pour l’approche psychologique, la complexité de la tâche est déterminée en se basant sur

des caractéristiques de l’individu qui réalise la tâche ainsi que celles de la tâche. La

connaissance et l’habileté de l’individu jouent un rôle important dans la détermination de

la complexité. Une tâche peut être plus ou moins complexe dépendant non seulement des


82

caractéristiques de la tâche mais aussi de l’individu qui réalise la tâche. Cette approche

explique la différence entre un novice et un expert.

Par contre, dans la deuxième approche, la complexité de la tâche est indépendante de la

personne. La complexité n’est dérivée que des caractéristiques de la tâche. Les tâches

similaires seront donc classifiées selon le même niveau de difficulté (complexité). Cette

approche facilite l’analyse de la complexité de la tâche de façon objective. Elle permet

aussi de comparer deux tâches ainsi que de juger ou d’estimer les ressources requises

pour réaliser une tâche.

Avec l’approche de la complexité objective, la tâche est souvent analysée et quantifiée en

se basant sur la description a priori de tâche [40,177] comme les entrées/sorties et le

processus de traitement d’information. Autrement dit, la complexité est quantifiée selon

le processus de traitement de l’information pour accomplir la tâche. L’information

relative à une tâche décrit la structure et les exigences de la tâche. Du point de vue

fonctionnel [95], l’information (pour décrire une tâche) peut appartenir à une des trois

classes:

!" Information du problème décrit les aspects spécifiques d’une tâche. Elle répond à

des questions relatives à une tâche particulière, par exemple: nom, adresse,

numéro de téléphone, etc.

!" Information du domaine décrit les aspects généraux d’une tâche. Elle répond à

des questions pour certaines tâches de même type. Fait, concept, loi et théorie

appartiennent à cette catégorie.

!" Information de problème-résolu (problem-solving) réfère aux aspects spécifiques

de traitement de la tâche. Elle décrit la structure et les exigences de la tâche. Elle

décrit les instructions pour accomplir la tâche.

Parmi les recherches sur la complexité de la tâche, la littérature sur le traitement de

l’information a établi le plus clairement un cadre de la complexité. Plusieurs recherches,

notamment celle de Schroder et al. [138], ont établi un consensus sur le fait que la

complexité de la tâche est directement reliée aux attributs de la tâche qui font augmenter

la charge d’information (information load), la diversité de l’information et la fréquence

de changement. Par conséquent, la complexité de la tâche peut être définie objectivement

et peut être déterminée indépendamment de la personne qui réalise la tâche. Schroder

estime que n’importe quelle caractéristique objective d’une tâche qui fait augmenter la

charge d’information, la diversité d’information et la fréquence de changement


83

d’information peut être considérée comme un facteur qui contribue à la complexité de la

tâche.

Dans sa revue de la littérature [40], Campbell indique que les quatre caractéristiques de

base de la complexité objective de tâche sont:

!" La présence de plusieurs chemins (multi-paths) potentiels pour arriver un état fini

(end-state) désiré.

!" La présence de plusieurs états finis à être atteints.

!" La présence d’interdépendances contradictoires entre les chemins qui conduisent

aux états finis possibles.

!" La présence de l’incertain et l’incertitude de liens entre les chemins et les états

finis.

Campbell a aussi noté que les recherches sur la complexité objective de tâche ont atteint

les consensus suivants:

!" La complexité de la tâche est basée sur des caractéristiques de la tâche. Elle est

intrinsèque à la tâche.

!" La complexité de la tâche est modélisée en se basant sur le traitement de

l’information de la tâche. Les éléments d’information (informations cues) et la

relation entre eux sont deux attributs caractéristiques clés de la complexité de la

tâche.

En génie logiciel, certaines recherches [17,53] ont développé des mesures de la

complexité basée sur la complexité de la tâche. Ces travaux font référence au modèle

de la complexité de la tâche de Wood. Ce modèle reflète les consensus mentionnés

ci-dessus.

Le modèle de Wood, d’un part, offre un cadre de la complexité au point de vue

systémique. D’autre part, il propose des mesures de la complexité objective de tâche qui

sont basées sur le traitement de l’information relatif à la tâche incluant les entrées, les

sorties désirées et les transformations. Un tel modèle pourrait être approprié pour la

recherche de la complexité fonctionnelle du logiciel parce qu’un logiciel est

essentiellement un système de traitement de l’information. En fait, comme on verra dans

la section 5.2.1, la tâche et le logiciel sont modélisés par le même modèle: le traitement

de l’information. De plus, les fonctionnalités d’un logiciel déterminent la tâche (ou

ensemble de tâches) que le logiciel doit accomplir. Elles sont dérivées des exigences de


84

l’utilisateur et décrites dans les spécifications du logiciel faites à l’analyse. C’est pourquoi

nous introduisons la complexité de la tâche de Wood comme une théorie sous-jacente

pour étudier la complexité fonctionnelle du logiciel.

4.2 MODÈLE DE LA COMPLEXITÉ DE LA TÂCHE DE WOOD

Le modèle de la complexité de la tâche de Wood est le modèle cognitif de base de notre

recherche. Ce modèle, d’une part, définit un cadre de la complexité qui se compose de

trois dimensions: la complexité des composants, la complexité de coordination et la

complexité dynamique. D’autre part, Wood a discuté des différentes façons de mesurer la

complexité identifiée selon ce cadre.

Dans le but de mesurer la complexité, Wood a modélisé une tâche comme un processus

de traitement de l’information. Généralement, la complexité de la tâche est la complexité

du traitement de l’information lorsque la tâche est réalisée. Plus il y a d’informations à

traiter (pendant la réalisation de la tâche), plus la tâche est complexe. La complexité dans

ce sens fait référence à l’effort. Une tâche complexe demande beaucoup d’efforts pour sa

résolution et elle peut causer des erreurs. L’idée de Wood est conforme à l’idée

philosophique d’Ashby [11] selon laquelle la complexité doit être mesurée par la quantité

d’information requise pour décrire un objet.

Wood propose trois éléments essentiels pour décrire une tâche: produits (products),

actions requises (required acts) et éléments d’information (information cues) voir la

figure 4.1.

Figure 4.1: Modèle de la tâche [177].

!" Les produits sont les entités créées ou produites par les comportements pouvant

être observés et décrits indépendamment des comportements ou actions qui les

produisent.

!" Une action est un patron (pattern) de comportements avec certaines directions et

des buts identifiables.


85

!" Les éléments d’information sont des parcelles d’information sur lesquelles un

individu peut émettre des jugements. Les éléments d’information fournissent des

renseignements afin de réaliser la tâche, y compris des renseignements sur les

entrées/sorties de la tâche et les renseignements nécessaires pour juger le produit

de la tâche. Ils sont des renseignements permettant de savoir si la tâche est

réalisée correctement et si elle a produit les sorties désirées.

Figure 4.2: Modèle de la complexité de la tâche de Wood.

En se basant sur ces trois éléments, Wood a défini trois types de complexité: la

complexité des composants, la complexité de coordination et la complexité dynamique

(voir figure 4.2).

Le cadre proposé par Wood considère que la complexité (totale) de la tâche se compose

de trois types de complexité. Elle se présente comme une fonction de trois paramètres ou

un vecteur de trois dimensions: la complexité des composants, la complexité de

coordination et la complexité dynamique. Wood ne propose pas de mesure pour la

complexité (totale) de tâche. Il discute seulement de la contribution de la complexité des

composants, la complexité de coordination et de la complexité dynamique à la complexité

(totale) de la tâche. Selon lui, si on considère la complexité totale comme la somme

linéaire de ces trois types de la complexité, alors le poids d’une unité de la complexité de

coordination doit être plus grand que le poids d’une unité de la complexité des

composants. Ainsi, le poids d’une unité de la complexité dynamique doit être plus grand

que celui de la complexité de coordination.


86

4.2.1 Complexité des composants

La complexité des composants (d’une tâche) est définie comme une fonction du nombre

d’actions distinctes à faire pour réaliser la tâche et du nombre d’éléments d’information

devant être traités dans le processus de réalisation de la tâche. Il faut insister sur le mot

« distinct » parce que la complexité ne change pas si les actions sont répétées plusieurs

fois. Wood estime que la complexité est augmentée avec l’augmentation du nombre

d’actions. Il propose une formule pour ce type de complexité.

Complexité des composants: TC1= ((& &

n

i

m

jijw

1 1

Où:

!" n: nombre de sous-tâches.

!" m: nombre d’actions dans une sous-tâche.

!" wij: nombre d’éléments d’information devant être traités dans l’action j de la

sous-tâche i.

Il est évident que la mesure de la complexité des composants définie par Wood fait

référence à la taille, c’est-à-dire, à la quantité d’information traitée dans la tâche. Cette

mesure est conforme à l’intuition et elle peut fournir une explication partielle à la

question de savoir pourquoi une tâche est plus difficile qu’une autre. La formule

TC1 implique que deux composants peuvent être comparés en se basant sur la quantité

d’information qu’ils doivent traiter. Les mesures de points de fonction du logiciel sont

basées sur la même idée. Cependant, les façons de quantifier l’information dans ces

méthodes sont différentes. Par exemple, FPA capture les groupes de données statiques et

ne tient pas compte de l’utilisation de ceux-ci. Mark-II et COSMIC-FFP capturent

dynamiquement les groupes de données; le nombre des groupes de données est compté

selon l’utilisation de ces groupes. Dans FPA, un groupe de données est compté une fois

par fonction. Par contre, dans Mark-II et COSMIC-FFP, un groupe de données peut être

compté plusieurs fois selon le nombre de fois que ce groupe est utilisé.

L’idée de Wood se situe quelque part entre ces deux extrêmes. Dans la formule de la

complexité des composants de Wood, un groupe de données peut être compté plusieurs

fois s’il introduit quelque chose de nouveau dans la tâche. Le terme « élément

d’information » (information cue) pourrait être meilleur que le terme « intrant, extrant »

(de FPA) ou « transaction » (de MARK-II) ou « mouvement de données » (de COSMIC-


87

FFP) pour caractériser la complexité. Le nombre d’éléments d’information pourrait être

plus approprié pour indiquer la quantité d’information à traiter dans une fonction.

4.2.2 Complexité de coordination

La complexité de coordination (d’une tâche) fait référence à la nature de la relation entre

les entrées et les sorties de la tâche. La forme et la force des relations entre les éléments

d’information, les actions, les produits et l’ordre des entrées (p.ex., la synchronisation)

sont des aspects de la complexité de coordination ([177], p.68]). Wood estime que la

mesure appropriée pour la complexité de coordination dépend des aspects spécifiques des

relations entre les entrées et des relations entre les entrées et les sorties. La relation

temporelle entre les actions est aussi un aspect de la complexité de coordination. En fait,

dans son article, Wood propose une mesure qui capture cette relation entre les actions. La

formule pour calculer la complexité est la suivante:

Complexité de coordination: TC2 = (&

p

iir

1

Où: p est le nombre d’actions dans la tâche; ri est le nombre d’actions qui précède

l’action i; ri représente la relation « précédente » entre l’action i et les autres

actions qui se produisent dans la tâche.

Selon Wood, il y a des cas où une action est réalisée après que d’autres actions aient été

accomplies. Par exemple, la lecture d’un fichier ne peut être réalisée qu’après l’ouverture

du fichier. Une tâche qui requiert une longue série d’actions pour s’accomplir est

considérée plus complexe qu’une tâche avec une courte série d’actions.

Wood a aussi discuté d’une autre alternative à la complexité de coordination: c’est la

relation entre les entrées et les sorties de la tâche. Wood estime que pour produire les

sorties, un individu doit traiter les entrées. Un ensemble d’entrées peut produire

différentes sorties. Par conséquent, l’individu a besoin des informations pour juger (ou

orienter) le processus de réalisation de l’action (p.ex., choisir un bon chemin pour obtenir

les sorties désirées). La coordination entre les entrées est mesurée par le nombre de

« points tournants » (turning points), le nombre de points de décision sur le chemin de

l’entrée à la sortie du processus. Les points de décision peuvent être considérés comme

les contraintes ou les conditions appliquées sur les entrées pour produire les sorties

différentes désirées. Cette idée est similaire à la mesure de McCabe [118].


88

Les deux aspects de la complexité de coordination mentionnés dans l’article de Wood

sont résumés dans deux ellipses attachées à la complexité de coordination dans la

figure 4.2. Cependant, il faut noter que ces deux aspects de la complexité de coordination

ne sont que deux exemples de la complexité de coordination. L’idée générale à retenir ici

est que la complexité de coordination devrait capturer les aspects pertinents des relations

entre les entrées et sorties et les relations entre les actions. Dans notre recherche (voir le

chapitre 5), la complexité de coordination est interprétée par:

!" La complexité structurelle des composants qui fait référence à la relation entre les

entrées et sorties des composants individuels. Elle est de type intra-composant.

!" La complexité dérivée de la relation entre les composants. Elle est de type inter-

composants.

4.2.3 Complexité dynamique

La complexité dynamique fait référence aux changements d’état du monde réel ayant des

effets sur la tâche. Le fait est que la réalisation de certaines actions peut causer des effets

sur le reste de la tâche. L’entrée d’une partie d’information particulière peut aussi

provoquer des changements de comportement dans la tâche. Généralement, la complexité

dynamique tient compte des changements de la complexité avec le temps dans le

processus de réalisation de tâche. Wood propose la formule suivante pour la complexité

dynamique:

TC3 = TCTCTCTC 2(t)1)2(t1t

1(t)1)1(t ,','

&'(

k

Où:

!" k est le nombre de périodes de temps sur lesquelles la tâche est mesurée (c-à-d, le

nombre d’unités de temps).

!" TC1t, TC2t est la complexité des composants et la complexité de coordination dans

la période t, respectivement.

Wood a également introduit le concept d’« autocorrélation » entre la complexité des

composants et la complexité de coordination d’une période de temps à la période qui suit.

L’autocorrélation et la complexité dynamique ont une relation négative. Si

l’autocorrélation est élevée, la complexité dynamique est basse. La formule de la

complexité dynamique avec la notion d’autocorrélation établie par Wood est:


89

TCs3 = )(1)(1 TC2

s2(t)

s1)2(tTC1

k

1t

s1(t)

s1)1(t !TCTC!TCTC ,,',, '

&'(

Où:

!" s1TC est la complexité des composants mesurée par une unité normalisée.

!" s2TC est la complexité de coordination mesurée par une unité normalisée.

!" s3TC est la complexité dynamique mesurée par une unité normalisée.

!" /TC1 est le coefficient d’autocorrélation de TC1.

!" /TC2 est le coefficient d’autocorrélation de TC2.

Ce type de complexité est ignoré dans notre recherche parce que nous étudions la

complexité du problème avec une hypothèse préliminaire à l’effet que cette complexité ne

change pas si le problème n’est pas changé. Autrement dit, la complexité de problème est

considérée invariable avec le temps. Nous savons cependant que, dans un projet logiciel,

les spécifications d’un projet évoluent tant que le projet n’est pas complété et qu’il existe

un volet de complexité dynamique que nous laissons de côté, pour le moment, avec cette

hypothèse.

4.2.4 Complexité totale de tâche

La complexité totale s’établit en fonction des trois types de complexité ci-dessus. Dans le

cas le plus simple, la fonction est une combinaison linéaire de ces trois paramètres, dont

chacune est exprimée dans une unité normalisée. Selon Wood, une unité de complexité

dynamique donne plus de contribution qu’une unité de complexité de coordination. Une

unité de complexité de coordination, à son tour, donne plus de contribution qu’une unité

de complexité des composants.

La complexité totale: TC = s3

s2

s1 TCTC TC "#$ ''

Où:

!" s1TC est la complexité des composants mesurée par une unité normalisée.

!" s2TC est la complexité de coordination mesurée par une unité normalisée.

!" s3TC est la complexité dynamique mesurée par une unité normalisée.


90

!" +, 0 et 1 sont les poids dont chaque type de complexité contribue à la complexité

totale. Ils doivent satisfaire l’inégalité + < 0 <1.

Wood a mis en garde sur le fait que les trois dimensions de la complexité de la tâche

pourraient varier indépendamment et que leur contribution à la complexité totale pourrait

ne pas être nécessairement linéaire comme dans la formule ci-dessus. La formule de TC

ci-dessus a pour but d’expliquer la notion de complexité totale. Wood recommande que

les trois dimensions de la complexité soient mesurées avec la même unité. Mais, une telle

unité existe-elle? Rien ne peut assurer qu’il existe une telle unité; Wood n’en proposait

aucune. De ce fait, dans cette thèse, nous représentons la complexité totale comme un

vecteur de trois dimensions plutôt qu’une valeur unique calculée à partir de trois mesures

élémentaires.

4.2.5 Remarques sur le modèle de la complexité de la tâche

Le modèle de la complexité de la tâche de Wood a montré des idées importantes sur la

modélisation de la tâche ainsi que sur les aspects principaux de la complexité. Ces idées

constituent un guide théorique pour élaborer notre méthode de mesure de la complexité

fonctionnelle du logiciel. Le modèle de Wood a montré que:

!" La tâche est modélisée en se basant sur l’information devant être traitée pendant

la réalisation de la tâche.

!" Au niveau conceptuel, la complexité de la tâche est la complexité du processus de

traitement de l’information. La mesure de la complexité peut être basée sur le

volume d’informations en entrée et en sortie de la tâche.

!" À un niveau plus détaillé, la complexité de la tâche se compose de trois types de

complexité: la complexité des composants, la complexité de coordination et la

complexité dynamique.

o La complexité des composants fait référence au volume d’informations

entrées et sorties et quantifiée par le nombre total d’éléments

d’information des composants individuels.

o La complexité de coordination fait référence aux relations entre les

entrées et les sorties (relation intra-composant) et aux relations entre les

composants (inter-composants).


91

o La complexité dynamique tient compte des changements de la

complexité avec le temps ou des changements qui interviennent dans la

description du problème dans le temps. Ce type de complexité nous

amène bien au-delà de la complexité intrinsèque du problème, à laquelle

nous avons choisi de nous limiter. Dans notre recherche, nous supposons

que le problème (c-à-d, la spécification du logiciel) ne change pas.

Changer le problème conduit à un nouveau problème.

Le modèle de la complexité de la tâche définit un cadre d’analyse de la complexité plutôt

que des mesures précises. Cependant, Wood a discuté des alternatives pour chercher des

mesures de la complexité. Le modèle de Wood et ses mesures ne sont pas encore validés

empiriquement. C’est une limitation retrouvée très souvent à la plupart des méthodes de

mesure de la complexité. La validation empirique est toujours difficile parce qu’on n’a

pas de valeur de la « vraie complexité » a priori pour juger si les mesures de la

complexité sont correctes. Dans son article, Wood a donné deux exemples pour montrer

comment son modèle fonctionne au lieu de faire une investigation empirique.

Une autre limite du modèle de Wood est qu’il n’y fait aucune interprétation des mesures

de la complexité. Il n’est pas clair à quoi la complexité de la tâche fait référence. Donc

cela rend difficile l’application des mesures. Wood ne touche pas le problème de

l’application de ses mesures ou l’exploitation de la complexité totale de tâche. Dans la

pratique, une mesure de la complexité est souvent utilisée comme un indice de base pour

certaines estimations comme l’effort ou le temps de réalisation de tâche, la productivité

de l’individu qui réalise la tâche. Si la tâche (ou le logiciel) A est plus complexe que la

tâche (ou le logiciel) B, on suppose que le temps pour réaliser la tâche A sera plus long

que celui de la tâche B. Ainsi, l’effort pour réaliser la tâche est considéré comme une

variable indépendante de la complexité. Par conséquent, une mesure de la complexité

devrait être cohérente avec l’effort réel pour réaliser la tâche.

Dans notre recherche, nous proposons un cadre conceptuel pour analyser la complexité

fonctionnelle du logiciel et des mesures selon le modèle de Wood. Les mesures de la

complexité sont interprétées via l’effort de développement du logiciel. C’est-à-dire, si la

complexité du logiciel A est plus grande que celle de B, l’effort de développement du

logiciel A est plus grand que celui de B. Nous validerons empiriquement les nôtres en

analysant la cohérence entre nos mesures avec l’effort réel de développement du logiciel


92

(voir le chapitre 6). Grosso modo, une mesure de la complexité sera valide si elle est un

bon indicateur de l’effort de développement du logiciel.

4.3 QUELQUES MODÈLES DE LA COMPLEXITÉ DU LOGICIEL BASÉS SUR LA COMPLEXITÉ DE LA TÂCHE

Dans cette section, nous présentons un court résumé de deux travaux qui sont basés sur le

modèle de la complexité de la tâche de Wood. Le premier est un modèle de mesure de la

complexité de maintenance du logiciel. Le deuxième est un cadre pour sélectionner un

ensemble de mesures de la complexité.

4.3.1 Mesure de la complexité de maintenance

Banker [17] a construit un modèle de la complexité du logiciel en utilisant l’approche de

la complexité de la tâche. La complexité dont il parle est la complexité de maintenance du

code du programme. Les tableaux 4.1 et 4.2 représentent l’interprétation du modèle de

Wood dans le contexte de maintenance du code source du programme [17]. Les concepts

clés dans le modèle de Wood sont mis en correspondance avec les éléments du

programme. Puis les mesures de la complexité du programme (dans la colonne de droite

du tableau 4.2) sont utilisées pour évaluer l’impact de deux techniques: la génération du

code et le paquetage du code du logiciel.

Éléments du modèle de la tâche Éléments du modèle du logiciel - action - unité du programme (module/ fonction/ classe) - produits - sorties d’unité du programme - éléments d’information (information cues) - décisions: nœud de décisions (McCabe [118])

- opérandes (Halstead [76]) Tableau 4.1: Mise en correspondance des concepts élémentaires de deux modèles.

Le résultat de sa recherche a montré que:

!" La génération du code réduit la complexité des composants et la complexité de

coordination mais elle fait augmenter la complexité dynamique. L’impact général

de cette technique est d’augmenter de 3,8% l’effort de maintenance du code.

!" Le paquetage du code augmente la complexité des composants et la complexité

de coordination mais la complexité dynamique est réduite. L’impact général de

cette technique est de réduire 6,5% l’effort de maintenance.


93

Mesures de la complexité de la tâche Mesures de la complexité du logiciel La complexité des composants La densité de données mesurées par la mesure N2

de Halstead (c-à-d, le nombre d’opérandes) [76] La complexité de coordination Mesure de McCabe [118] La complexité dynamique Le nombre de chemins de décision du logiciel. C’est

essentiellement le nombre de sous-procédures qui sont appelées dynamiquement pendant l’exécution du programme.

Tableau 4.2: Mise en correspondance des mesures de deux modèles.

Théoriquement, Banker ne propose pas des nouvelles mesures pour la complexité du

programme. Il utilise le modèle de la complexité de la tâche de Wood comme un guide

pour choisir les mesures appropriées pour mesurer la complexité et évaluer, par la suite,

les techniques de programmation.

Banker a appliqué le modèle de Wood à une tâche spécifique – la maintenance du logiciel

– et a montré trois mesures correspondant à trois types de complexité de la tâche. Il a

aussi considéré que l’effort de maintenance est une fonction de la complexité des

composants, la complexité de coordination et de la complexité dynamique. Dans son

article, l’effort de maintenance du logiciel est une fonction de plusieurs variables, y

compris les trois mesures de la complexité dans le tableau 4.2 et d’autres mesures comme

la densité de données, le nombre de points de fonction, l’expérience des programmeurs et

la complexité du code. Le but de la mesure de Banker est d’évaluer l’effet de deux

techniques de programmation (la génération du code et le paquetage du code). Les

mesures de Banker sont donc loin de nos considérations. Cependant, l’article a montré un

exemple d’application du modèle de la complexité de la tâche pour un problème de

mesure de la complexité du logiciel. De plus, les mesures de la complexité sont associées

à l’effort. Elles sont utilisées comme des indices de base pour étudier l’effort requis pour

une tâche spécifique.

4.3.2 Mesure de la complexité de la conception

Darcy [53] utilise le modèle de la complexité de la tâche de Wood comme un guide

théorique pour choisir un sous-ensemble de mesures de la complexité aux fins

d’évaluation, de prédiction et de gestion de la complexité du logiciel. Sa thèse a proposé

que le couplage entre les modules et la cohésion dans un module sont deux mesures

pertinentes pour mesurer la complexité du logiciel.


94

Darcy interprète la complexité des composants par la cohésion et la complexité de

coordination par le couplage. La complexité dynamique est ignorée. Selon lui, la

complexité du logiciel est la complexité de la conception du logiciel. Une bonne

conception va conduire à un bon codage et va réduire l’effort de maintenance. Son

résultat est loin de notre intérêt, cependant il a montré une possibilité d’utiliser le modèle

de la complexité de la tâche pour étudier la complexité du logiciel. Il a aussi donné un

exemple d’interprétation du modèle de la complexité de la tâche dans un contexte de

conception du logiciel. Encore une fois, la complexité est associée à l’effort (de

maintenance).

4.4 RÉSUMÉ

Dans ce chapitre, nous avons discuté de la complexité de la tâche, et surtout, de la

complexité objective de la tâche. L’approche pour mesurer objectivement la complexité

de la tâche est basée sur le principe du traitement de l’information. La complexité est

mesurée en se basant sur la quantité d’information à traiter. Ce principe est conforme aux

idées philosophiques d’Ashby et de Simon présentées au chapitre 1.

Le modèle de Wood est un modèle représentatif de la complexité objective de la tâche se

basant sur le principe du traitement de l’information. Ce modèle propose un cadre

d’analyse de la complexité qui se compose de la complexité des composants, la

complexité de coordination et la complexité dynamique.

La complexité des composants fait référence à la quantité d’information à traiter dans la

tâche. Plus il y a d’information à traiter, plus complexe est le composant. La complexité

des composants est mesurée en se basant sur les éléments d’information dans la tâche.

Dans notre interprétation, un élément d’information doit s’associer à une action dans la

tâche pour introduire quelque chose de nouveau à la tâche. Alors, les éléments

d’information devraient être identifiés dynamiquement par les actions qui se produisent

pendant la tâche plutôt que d’identifier des groupes de données statiques.

La complexité de coordination fait référence à la coordination entre les éléments

d’information et les produits, c’est-à-dire, entre les intrants et les extrants de la tâche. Ce

type de complexité a pour objet de caractériser comment complexe est le chemin à

parcourir de l’entrée à la sortie de la tâche. Wood propose que la complexité de cette

coordination soit mesurée par le nombre de points tournants (turning points) rencontrés le


95

long du chemin allant de l’entrée à la sortie. Cette mesure est totalement logique et

conforme à la mesure de McCabe [118].

Un autre aspect de la coordination est la relation entre les actions, c’est-à-dire, entre les

composants élémentaires d’une tâche. Wood propose que la complexité de ce type soit

mesurée par le nombre d’actions qui doivent être accomplies avant l’action considérée.

Cependant, il met en garde à l’effet qu’il s’agit d’un exemple seulement. L’essentiel est

qu’il faut tenir compte de la complexité dans la relation entre les composants. La question

de savoir comment la mesurer est répondue en se basant sur ce qu’on considère comme la

relation pertinente entre les composants. Dans notre recherche, nous utilisons l’idée de

Wood plutôt que la mesure qu’il a proposée. Nous ne pensons pas que la longueur d’une

série d’actions soit plus importante que la communication entre les actions. Nous croyons

que la dépendance de données entre les composants est plus pertinente et plus globale que

l’ordre d’exécution des composants.

La complexité dynamique est ignorée dans notre travail parce que ce type de problème

n’est pas déjà maîtrisé. Éventuellement, des solutions pour ce niveau de préoccupation

pourront faire l’objet de consensus, et alors la problématique de la complexité dynamique

pourra être prise en compte. De ce fait, la complexité des composants, la coordination

entre les intrants et extrants et la coordination entre les composants sont trois dimensions

de la complexité de la tâche qui nous intéressent. Dans le chapitre 5, nous développerons

une nouvelle méthode de mesure de la complexité fonctionnelle du logiciel d’après le

cadre de la complexité de la tâche de Wood. Puis dans le chapitre 6, nous montrerons que

les trois aspects mentionnés ci-dessus sont pertinents et caractérisent bien la complexité

du logiciel qui se manifeste dans l’effort de développement.

CHAPITRE 5

NOUVELLE MÉTHODE DE MESURE DE LA COMPLEXITÉ FONCTIONNELLE DU LOGICIEL

Ce chapitre propose une nouvelle méthode de mesure de la complexité fonctionnelle du

logiciel. La méthode est de type « point de fonction». C'est-à-dire qu’elle quantifie la

complexité à partir des fonctionnalités du logiciel, de façon similaire à FPA ou

COSMIC-FFP. Cependant, la méthode essaie de surmonter des limites majeures de FPA

et COSMIC-FFP dans la manière de quantifier la complexité.

Tout d’abord, le modèle conceptuel du logiciel est discuté. À la phase d’analyse, le

logiciel n’est qu’un ensemble de spécifications qui décrivent ce que le logiciel doit faire,

c’est-à-dire, les fonctionnalités du logiciel. Les fonctionnalités du logiciel déterminent les

tâches que le logiciel doit accomplir pour répondre aux exigences de l’utilisateur. De ce

fait, le logiciel peut être analysé selon la tâche que le logiciel doit faire. Si la tâche est

complexe, le logiciel qui la réalise est complexe. La complexité fonctionnelle du logiciel

(c-à-d, la complexité évaluée à partir de la fonctionnalité du logiciel) peut donc être

analysée d’après le modèle de la complexité de la tâche.

Ensuite, par similarité avec la complexité de la tâche, la complexité fonctionnelle est

définie selon trois dimensions:

!" La complexité des données entrées et sorties des composants.

!" La complexité structurelle des composants, et

!" La complexité du système.

Enfin, une nouvelle méthode de mesure qui se compose de trois mesures simples

correspondant à ces trois dimensions est proposée pour quantifier la complexité du

logiciel. La nouvelle méthode ne propose que des mesures objectives de la complexité.

Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel

97

De ce fait, elle tient compte des points faibles de FPA et de certaines variations de celle-

ci. La complexité des entrées et sorties est mesurée par le nombre de groupes de données

en entrées et en sorties du composant. La complexité structurelle d’un composant est

mesurée par le nombre de conditions sur les entrées pour produire les sorties désirées. La

complexité du système est mesurée par l’entropie du système.

En comparant à COSMIC-FFP, la nouvelle méthode couvre plus d’aspects de la

complexité. En fait, elle tient compte de la complexité des composants et de la complexité

du système entier. Celle-ci n’est pas mentionnée dans COSMIC-FFP. De plus, la

complexité des composants couvre tous les aspects d’un processus fonctionnel identifiés

dans COSMIC-FFP: les mouvements de données et la manipulation de données.

COSMIC-FFP ne tient compte que des mouvements de données; la manipulation de

données est ignorée.

Ce chapitre se concentre sur le modèle du logiciel et l’arrimage de ce modèle au modèle

de la tâche, puis sur la construction de la nouvelle méthode de mesure. La validation

empirique de la mesure est reportée au chapitre 6.

5.1 MODÉLISATION DU LOGICIEL

5.1.1 Modèle conceptuel du logiciel

« Logiciel » est un terme général qui indique un ensemble d’instructions d’ordinateur, de

documents et de données qui décrivent un problème à résoudre par l’ordinateur et

implémentent la solution à ce problème. La réalisation d’un projet de développement de

logiciel est un processus incluant l’acquisition des besoins de l’utilisateur, l’analyse des

besoins, la conception (design) du système, l’implémentation du système (codage), les

tests (vérification et validation),… Donc, le produit logiciel émerge au fur et à mesure de

ce processus.

En génie logiciel, il existe plusieurs modèles du logiciel dépendant du but de la

modélisation et de la phase dans le cycle de vie du logiciel. Les modèles représentent le

logiciel à des niveaux d’abstraction différents. Durant la phase d’analyse, les modèles du

système à développer sont créés. Ils se concentrent sur ce que le système doit faire,

c’est-à-dire, les fonctionnalités du système. La modélisation à cette phase vise à décrire

les fonctions qui doivent être réalisées pour que le système réponde aux besoins des

utilisateurs. Des notations graphiques sont souvent utilisées pour décrire les informations

entrées, sorties et les comportements du système. Deux modèles importants qui sont


98

souvent retrouvés à cette phase sont le modèle fonctionnel (functional model) et le

modèle de comportement (behavioral model).

Le modèle fonctionnel représente le processus de traitement de l’information du logiciel.

Il est le produit du processus de l’analyse de haut en bas (top-down decomposition).

Pendant l’analyse d’un système (logiciel), l’analyste se concentre sur le problème à

résoudre par le logiciel. Le problème (global) est décomposé en sous-problèmes et ce

récursivement jusqu’aux fonctions élémentaires. Chaque fonction joue un rôle précis dans

le système et elle est décrite par ses entrées, ses sorties et les instructions de traitement

des données (c-à-d, les règles d’opération pour manipuler des données) [133].

Figure 5.1: Exemple d’un diagramme de flux et de ses niveaux d’abstraction différents.

Le modèle fonctionnel est souvent représenté par un diagramme de flux de données (Data

flow diagram–DFD). Un DFD peut être un schéma global ou détaillé qui représente les

fonctions du système et les flux de données dans le système. Une fonction est représentée

par un nœud et un arc orienté représente un flux de données. Un diagramme au niveau

global peut être raffiné en d’autres diagrammes détaillés. Une fonction dans un

diagramme global peut être décomposée en un ensemble de fonctions dans un diagramme

raffiné. La figure 5.1 illustre plusieurs niveaux de détail d’un modèle fonctionnel. À un

haut niveau, le modèle représente une fonction générale F avec son entrée et sa sortie. Au

deuxième niveau, la fonction F est décomposée en cinq fonctions plus fines f1-f5. Puis la

fonction f4 est encore décomposée de façon plus détaillée. De ce fait, il y aurait plusieurs

modèles fonctionnels qui représentent le logiciel à des niveaux d’abstraction différents. Il

n’y a pas de norme pour décrire le niveau de détail d’un modèle fonctionnel. Une


99

méthode de points de fonction choisit son propre niveau d’abstraction, et propose son

propre modèle fonctionnel.

En réalité, chaque méthode de points de fonction est basée sur un modèle fonctionnel du

logiciel. Cependant, le modèle du logiciel de FPA diffère de celui de Mark-II et le modèle

de Mark-II diffère de celui de COSMIC-FFP. Autrement dit, on n’a pas uniquement un

modèle dit « modèle fonctionnel du logiciel », mais on peut modéliser le logiciel et

représenter sa fonctionnalité en spécifiant le rôle de fonctions, ses entrées, ses sorties et

les règles d’opération qui guident le processus de traitement de l’information.

Dans cette thèse, le modèle fonctionnel proposé par COSMIC [3] est utilisé. Ce modèle

est modifié pour que la manipulation de données soit bien capturée et mesurée.

Autrement dit, notre méthode de mesure est basée sur le modèle fonctionnel du logiciel

au même niveau d’abstraction que COSMIC-FFP a défini pour mesurer les points de

fonction du logiciel (ou la taille fonctionnelle du logiciel – le terme utilisé dans

COSMIC-FFP). La modification ne change pas le niveau abstraction du modèle, sauf que

la manipulation des données est capturée pour fournir une mesure additionnelle de la

complexité.

a)

b)

Figure 5.2: a) Montre numérique b) Diagramme d’état de la montre numérique.

Le modèle de comportement représente les réponses du logiciel aux événements du

monde externe. Les stimulus-réponses sont représentés dans un modèle de ce type.

Pendant son exécution, un logiciel (ou un programme d’ordinateur) existe dans un certain

état. Le logiciel change d’état quand un événement se produit. Un modèle de


100

comportement du logiciel est une représentation des états du logiciel et des événements

qui causent les changements d’état. De ce fait, le modèle de comportement est encore

connu comme un modèle de transition d’états du logiciel. La figure 5.2b illustre un

exemple de modèle de comportement de la montre numérique vue dans la figure 5.2a.

Dans cet exemple, un rectangle représente un état, tandis qu’un arc représente une

transition. L’étiquette d’un arc représente un événement (stimulus). Selon le diagramme

6.2b, il y a quatre états pour la montre de la figure 5.2a. Le bouton Mode provoque une

transition d’état pour naviguer entre les quatre états: l’affichage de l’heure et les trois

modifications d’un des paramètres de l’heure. Les boutons + et - provoquent aussi une

transition d’état pour la modification d’un des paramètres de l’heure.

Le modèle de comportement vise à représenter les changements d’états du système. Il

permet de savoir quand une fonction est déclenchée et qu’est-ce que le système doit faire

pour répondre à un événement.

Certains autres types de modèle concernant les données du logiciel peuvent être créés à la

fin de la phase d’analyse, par exemple, le modèle entité-relation, le modèle objet. Le

modèle entité-relation représente les entités et les relations entre elles qui existent dans le

domaine du problème réel. Le modèle objet (ou modèle de classe) est aussi une sorte du

modèle de données. Il représente les prototypes des objets (c-à-d., classe d’objets) dans le

monde réel ainsi que les relations entre eux. Ce type de modèle est associé à l’analyse et à

la conception orientée d’objet.

La mesure que nous voulons développer dans cette thèse est de type points de fonction.

Elle va être définie en se basant sur le modèle fonctionnel du logiciel. Les autres modèles,

par exemple le modèle de comportement, le diagramme entité-relation, sont utiles. Ils

pourraient aider à identifier les processus fonctionnels et les groupes de données entrées

et sorties de ceux-ci. Cependant, en principe, le modèle fonctionnel du logiciel est

suffisant. Et comme déjà dit, le modèle fonctionnel de COSMIC-FFP est utilisé, mais

modifié, dans notre recherche.

5.1.2 Modèle fonctionnel du logiciel de COSMIC

Parmi les méthodes de mesure basées sur la fonctionnalité du logiciel, COSMIC propose

explicitement un modèle du logiciel (figure 5.3). Au début de la phase d’analyse, le

logiciel est décrit dans un document qui spécifie les exigences pour le système à

développer. Les spécifications contiennent les exigences fonctionnelles auxquelles le


101

système doit répondre (c-à-d, la fonctionnalité du système) et les exigences non

fonctionnelles comme les contraintes de qualité et les contraintes relatives aux matériels

(hardware). Dans la phase d’analyse, l’analyste décompose les exigences en un ensemble

de processus fonctionnels qui assurent la fonctionnalité demandée. Certaines exigences

non-fonctionnelles s’ajoutent et peuvent provoquer la conception des processus

fonctionnels qui s’ajoutent à ceux qui sont déjà explicitement requis par l’utilisateur. Par

exemple, une spécification comme « le système doit répondre à la requête de l’utilisateur

le plus rapidement possible » peut conduire à concevoir un tampon (cache) en mémoire

vive et les processus fonctionnels qui manipulent ce tampon. De ce fait, à cette phase, le

logiciel n’est qu’un ensemble de processus fonctionnels bien conçus pour répondre aux

exigences de l’utilisateur ou du propriétaire du logiciel. Chaque processus fonctionnel est

caractérisé par ses intrants, ses extrants et les règles d’opération (c-à-d, les règles de

manipulation des données).

Figure 5.3: Modèle fonctionnel du logiciel.

Les intrants et les extrants sont souvent explicites dans une représentation fonctionnelle

du logiciel, par exemple dans un diagramme de flux de données (DFD). Par contre, la

manipulation de données est souvent une boîte noire car on ne connaît pas très bien

comment les entrées sont traitées. De ce fait, pour tenir compte de la manipulation de

données, certaines méthodes (p.ex., FPA [8,9], Feature Points [96]) proposent une

évaluation subjective. C’est le mesureur qui décide que cette boîte noire est ‘simple’ ou

‘complexe’ et qui assigne un poids approprié. Cette approche rend difficile

l’interprétation de la valeur de la mesure. La mesure n’est pas répétable d’un mesureur à


102

l’autre. Certaines mesures essaient de caractériser cette boîte noire via des éléments

observables de la manipulation des données. Par exemple, Mark-II [158] interprète la

manipulation de données via les fichiers consultés pendant le processus. Points de

fonction 3D [175] compte les transitions de données. Chaque mesure propose son propre

point de vue. Il n’y a pas encore un consensus sur ce qui doit être mesuré pour

caractériser la complexité de la manipulation de données. Alors, nous cherchons un cadre

général pour préciser ce type de complexité ainsi que la mesurer objectivement.

Figure 5.4: Modèle d’un processus fonctionnel de COSMIC.

Quant à COSMIC, les intrants et les extrants d’un processus fonctionnel sont interprétés

par les mouvements de données. Un mouvement de données fait déplacer un groupe de

données à travers la frontière du logiciel. À un niveau plus détaillé, COSMIC distingue

quatre types de mouvement de données (figure 5.4):

!" Une Entrée: un mouvement de données qui fait déplacer un groupe de données

du côté de l’utilisateur (dehors du système) vers l’intérieur du système. Un

groupe de données est une entité ou un ensemble d’attributs d’une entité dans le

monde réel.

!" Une Sortie: un mouvement de données qui fait déplacer un groupe de données de

l’intérieur du système vers l’extérieur du système. Une sortie réalise un

mouvement de données vers l’utilisateur du système, vers un autre système ou

vers un matériel externe (terminal device).


103

!" Une Lecture: un mouvement de données qui fait déplacer un groupe de données

disponible sur un matériel de stockage (p.ex., le disque dur, ROM) à l’intérieur

du système.

!" Une Écriture: un mouvement de données qui fait déplacer un groupe de donnée

de l’intérieur du système vers un matériel de stockage.

Exemple: le processus fonctionnel pour « chercher le profil d’un étudiant »

!" Saisir le code permanent d’étudiant (une entrée)

!" Lire le fichier d’index pour chercher l’indice d’étudiant dans la liste d’étudiants

(une lecture)

!" Sauvegarder temporairement l’indice d’étudiant (une écriture)

!" Chercher le profil de l’étudiant correspondant à l’indice (une lecture)

!" Afficher le profil à l’écran (une sortie).

En principe, un mouvement de données déplace un groupe de données entrant ou sortant

d’un processus fonctionnel. Un groupe de données est un ensemble d’attributs décrivant

un objet. Dans une application, un objet est représenté par un ensemble d’attributs. Un

sous-ensemble de celui-ci peut être considéré comme un groupe de données. Par exemple,

livre est un objet dans un système de gestion de bibliothèque. Il peut être décrit par un

ensemble d’attributs: titre, nom d’auteur, année de publications, nombre de pages, code

de classement. Dans le processus « recherche par titre », saisir le titre recherché

provoque un mouvement de données du côté de l’utilisateur vers l’intérieur du système.

Dans ce cas, le titre recherché est un groupe de données qui contient un seul attribut. Si

on fait une recherche sur le titre et le nom d’auteur, les données entrées seront le titre et le

nom d’auteur. Ceux-ci forment un seul groupe, pas deux. Un mouvement de données fait

donc référence à un objet dans l’application plutôt qu’au nombre d’attributs.

Un processus fonctionnel est défini comme un ensemble de mouvements de données qui

doivent être réalisés pour répondre à un événement qui se produit à l’extérieur la frontière

du système et qui provoque une série d’actions du système. COSMIC [3] définit ce

concept de la façon suivante:

« Un processus fonctionnel est un composant élémentaire d’un ensemble d’exigences

fonctionnelles de l’utilisateur. Il est composé d’un ensemble indépendamment exécutable

cohérent et unique de mouvement de données. Il est déclenché directement ou


104

indirectement via « un acteur » par un ou plusieurs événements. Il est complet quand il

exécute tout ce qui est demandé pour répondre à l’événement déclenché ».

COSMIC ne fournit aucune définition de la manipulation de données dans un processus

fonctionnel. Et dans la définition de processus fonctionnel ci-dessus, la manipulation de

données semble ignorée. De ce fait, nous reprenons le modèle général de COSMIC et

essayons de définir la manipulation de données de façon appropriée pour que sa

complexité puisse être mesurée.

5.1.3 Modèle fonctionnel du logiciel proposé pour mesurer la complexité

Tout d’abord, nous conservons les idées du modèle fonctionnel du logiciel illustré dans la

figure 5.3:

!" Un logiciel est un ensemble des processus fonctionnels.

!" Un processus fonctionnel est caractérisé par un ensemble ordonné de

mouvements de données et de manipulation de données.

!" Un processus fonctionnel est provoqué par un enclencheur (trigger). Quand il est

déclenché, il exécute des mouvements de données et manipule des entrées pour

produire les sorties.

Le problème est de préciser ce qu’est une manipulation de données.

La manipulation est une boîte noire. À la phase d’analyse, on ne connaît pas toujours

comment les données sont manipulées. On ne connaît pas non plus l’algorithme de

traitement de l’information dans le processus, ni les étapes de traitement. Cependant, si

on regarde attentivement la spécification de ce qui est à l’entrée et à la sortie de la boîte

noire, on peut voir une image générale de la complexité de cette boîte. En réalité, même si

on ne connaît rien de l’algorithme de manipulation de données, les spécifications doivent

décrire ce qu’on veut obtenir à la sortie et les conditions ou contraintes pour obtenir une

telle sortie. La manipulation de données tient souvent compte des règles

d’opération comme:

SI (conditions sur les entrées) ALORS (sortie désirée) Par exemple: considérez le processus qui calcule une taxation simple en se basant sur le

type de marchandise comme suit:

!" Nourriture: 0%


105

!" Essence: 15%

!" Alcool: 30%

!" Cigarette: 50%

Ces descriptions sont implicitement ou explicitement spécifiées comme quatre

contraintes de forme SI … ALORS:

Si (type = ‘nourriture’) ALORS (taxe = 0%)

Si (type = ‘essence’) ALORS (taxe = 15%)

Si (type = ‘alcool’) ALORS (taxe = 30%)

Si (type = ‘cigarette’) ALORS (taxe =50%) Ces contraintes sont importantes non seulement dans l’analyse, la conception et le

codage, mais encore dans les tests d’acceptation. L’absence de contraintes de ce type rend

difficile la vérification du logiciel développé pour répondre à ce que l’utilisateur voulait

ou non, c’est-à-dire qu’il est difficile de confirmer qu’on développait la bonne chose. Les

règles SI … ALORS ne reflètent pas l’algorithme de manipulation de données dans le

processus fonctionnel. Cependant, elles reflètent la structure du processus. En fait, chaque

règle conduit à certains nœuds de décision dans le diagramme de flux de contrôle, puis

dans le code du programme qui implémente le processus fonctionnel. Les règles de

manipulation de données permettent d’évaluer tôt la complexité de la structure du

processus fonctionnel. De ce fait, nous proposons que la manipulation de données soit

caractérisée par les règles d’opération. Autrement dit, nous définissons un seul type de

manipulation: règle d’opération. Une règle d’opération est une règle SI … ALORS qui

spécifie une sortie spécifique et la condition pour obtenir une telle sortie. Alors le modèle

de la figure 5.3 peut être représenté comme celui de la figure 5.5.

Ici, nous utilisons le terme « entrées/sorties » au lieu de mouvement de données.

Cependant, les « entrées/sorties » équivalent aux mouvements de données dans la

figure 5.3. La raison est simplement que nous voulons formuler le modèle le plus près

possible du modèle de Wood.


106

Figure 5.5: Modèle fonctionnel du logiciel caractérisant la manipulation de données d’un processus fonctionnel.

Le modèle dans la figure 5.5 est une extension du modèle de COSMIC pour caractériser

la manipulation de données. Le logiciel est modélisé comme un système de traitement de

l’information. Il peut se décomposer en un ensemble de sous-systèmes. Chaque sous-

système est ensuite décomposé en un ensemble de processus fonctionnels. Puis, un

processus fonctionnel est défini de la même façon que COSMIC le fait, c’est-à-dire, il est

constitué par un ensemble de mouvements de données entrées et sorties et les

manipulations (ou les traitements de ces données). Un processus est déclenché par (au

moins) un événement déclencheur (stimulus). Cependant, le stimulus ne fait pas partie du

processus de traitement de l’information (c’est pourquoi nous utilisions les présentations

en pointillé dans la figure 5.5). Il n’est qu’un événement provoquant l’exécution d’un

processus.

Figure 5.6: Modélisation de manipulation de données.

La différence entre le modèle 6.5 et le modèle 6.3 est que la manipulation de données est

caractérisée par les règles d’opération: SI (conditions sur les entrées) ALORS (sortie


107

désirée). Ces règles guident la manipulation de données pour produire les sorties

désirées. Formellement, une règle d’opération peut être définie comme un prédicat sur

les données entrées. L’espace des données entrées est divisé en classes d’équivalence.

Chaque classe correspond à un type de sortie désirée (figure 5.6) et elle est caractérisée

par sa condition d’appartenance (memberships condition). Par exemple, dans le problème

de l’équation « ax+b=0 », l’espace des paramètres entrés est divisé en trois classes

correspondant aux conditions d’appartenance: « a 2 0 », « a=0 et b 2 0 » et « a=0 et

b=0 ». Ces trois classes correspondent aux trois types de sortie: « la solution = -b/a »,

« pas de solution » et « solution indéfinie ».

La modélisation de la manipulation de données se concentre sur le nombre de cas séparés

où les données entrées sont traitées. Elle ne tient pas compte de l’algorithme de

manipulation qui n’est pas précisé à la phase de l’analyse du logiciel. Alors la

modélisation dans la figure 5.5 caractérise la manipulation de données via des entrées, des

sorties et la relation entre elles (c-à-d, les règles d’opération) plutôt que l’algorithme de

traitement de l’information. Cette modélisation est tout à fait appropriée parce que:

!" L’algorithme de la manipulation n’est pas connu à la phase de l’analyse. De plus,

le changement de l’algorithme de la manipulation ne fait pas changer la

fonctionnalité du logiciel (par exemple, on peut employer Quicksort ou

Bubblesort pour faire le tri, leur fonctionnalité est la même) au point de vue de

l’utilisateur.

!" Les cas séparés et spécifiés à manipuler dans le processus fonctionnel sont

pertinents parce qu’ils sont indépendants de l’algorithme, et reflètent

intuitivement ce que le processus doit faire ainsi que l’effort de développement.

Supprimer ou ajuster les cas à manipuler fait changer la fonctionnalité du logiciel

au point de vue de l’utilisateur.

5.2 MESURES DE LA COMPLEXITÉ DU LOGICIEL

Cette section vise à proposer des mesures simples pour quantifier la complexité du

logiciel. Le logiciel est considéré comme une tâche définie par le problème à résoudre par

le logiciel. Le modèle fonctionnel du logiciel (figure 5.5) est mis en correspondance avec

le modèle de la tâche de Wood. Puis le modèle de la complexité de la tâche de Wood est

utilisé pour guider la définition des mesures de la complexité du logiciel.


108

5.2.1 Logiciel analysé comme une tâche

Du point de vue de la fonctionnalité, le logiciel peut être considéré comme une tâche: la

tâche à réaliser par le logiciel qui est définie dans les spécifications du logiciel. Le

logiciel est comme une grande tâche qui se compose de sous-tâches. Alors,

essentiellement, le logiciel est un ensemble de fonctions réalisant une (des) tâche(s) du

monde réel. Les spécifications du logiciel décrivent la tâche à réaliser par le logiciel, y

compris les données entrées, les manipulations et les sorties désirées (voir la figure 5.5).

Du point de vue de la modélisation, le logiciel est modélisé comme un système de

traitement de l’information dans lequel un processus fonctionnel est un processus de

traitement de l’information. Une tâche est aussi modélisée comme un processus de

traitement de l’information. Alors, le processus fonctionnel est essentiellement une tâche

élémentaire de la modélisation. La figure 5.7 illustre une comparaison entre un processus

fonctionnel et une tâche. Le modèle du processus fonctionnel est dérivé du modèle 6.5 et

le modèle de la tâche de Wood est reproduit du chapitre 4.

Figure 5.7a: Modèle de traitement de l’information de tâche.

Figure 5.7b: Modèle de traitement de l’information de processus fonctionnel.

À partir de la modélisation, un processus fonctionnel est décrit de la même façon qu’une

tâche. Il reçoit des informations à l’entrée, puis les manipule pour produire des sorties. Ce

processus peut être considéré comme le processus à réaliser par la tâche que le processus

fonctionnel doit accomplir. Si la tâche est complexe, ce processus est complexe et le

logiciel est complexe.


109

5.2.2 Complexité fonctionnelle analysée comme la complexité de la tâche

La sous-section précédente a montré que le logiciel est assimilé à une tâche, la tâche

globale qui correspond au problème que le logiciel doit résoudre. Puis un processus

fonctionnel, le composant de base du logiciel, est semblable à une tâche élémentaire qui

résout un problème spécifique, une partie de la tâche globale. Par conséquent, la

complexité fonctionnelle du logiciel peut être analysée d’après le modèle de la

complexité de la tâche. La complexité fonctionnelle du logiciel donc est définie d’après la

complexité du problème ou la complexité de la tâche que le logiciel doit accomplir. Si la

tâche est complexe, le logiciel est complexe. Alors la question qui se pose ici est de

savoir comment utiliser le modèle de la complexité de la tâche pour analyser la

complexité du logiciel.

Le modèle de la complexité de la tâche de Wood (chapitre 4) identifie trois types de

complexité:

!" La complexité des composants fait référence à la complexité des informations et

est mesurée par le nombre d’éléments d’information (information cues).

!" La complexité de coordination fait référence à la coordination entre les éléments

d’information et la coordination entre les actions élémentaires pour accomplir la

tâche. La complexité du premier type de coordination est mesurée par le nombre

de points tournants (turning points) pour obtenir des sorties différentes de la

tâche. Et la complexité du deuxième type de la coordination est mesurée par le

nombre d’actions réalisées antérieurement à une action de la tâche.

!" La complexité dynamique fait référence aux changements de la complexité des

composants et la complexité des coordinations avec le temps.

Concepts du modèle fonctionnel du logiciel Concepts du modèle

Logiciel Tâche globale

Processus fonctionnel Tâche élémentaire

Entrées/sorties Éléments d’information (information cues)

Relations entre entrées et sorties (règles d’opération)

Coordination entre les éléments d’information

Relation entre les processus fonctionnels Coordination entre les actions Tableau 5.1: Correspondance entre le modèle fonctionnel du logiciel et

le modèle de la tâche de Wood.


110

Le tableau 5.1 représente une mise en correspondance entre les concepts dans le modèle

du logiciel (figure 5.5) et les concepts dans le modèle de la tâche de Wood.

Les entrées et les sorties d’un processus fonctionnel introduisent des éléments

d’information à l’entrée et à la sortie du processus fonctionnel (ou de la tâche). Donc, le

concept « éléments d’information » de Wood peut être interprété via le concept

« entrées/sorties » dans le modèle du logiciel. La coordination entre les éléments

d’information dans le modèle de Wood est interprétée par les règles d’opération du

processus fonctionnel. Enfin, la coordination entre les actions qui fait référence à la

relation entre les actions est mise en correspondance avec la relation entre les processus

fonctionnels.

5.2.3 Cadre de la complexité fonctionnelle

La mise en correspondance dans le tableau 5.1 a précisé comment un logiciel est modélisé

comme une tâche. Cet arrimage permet d’interpréter le modèle de la complexité de la

tâche en utilisant les termes du modèle du logiciel. Trois des éléments de la complexité de

la tâche, représentés dans trois ellipses de la figure 5.8, peut être mis en correspondance

avec trois éléments de la complexité du logiciel représentés dans les trois rectangles plus

bas dans la figure 5.9.

Figure 5.8: Modèle de la complexité de la tâche.


111

Figure 5.9: Modèle de la complexité du logiciel.

Tout d’abord, la complexité de la tâche est la complexité fonctionnelle du logiciel.

Ensuite, la complexité des composants, qui est évaluée en se basant sur des éléments

d’information, devient la complexité des données entrées/sorties des composants. La

complexité de coordination entre les éléments d’information et les produits est mise en

correspondance avec la complexité dans la relation entre les entrées et les sorties. Cette

relation est caractérisée par la manipulation de données, c’est-à-dire les règles d’opération

SI …ALORS. Donc elle est considérée comme la complexité de la structure des

composants. Enfin la complexité de coordination entre les actions dans le modèle de

Wood est mise en correspondance avec la complexité du système qui fait référence aux

relations entre les composants dans le système entier.

La complexité de la relation entre les entrées et les sorties reflète partiellement la

complexité d’un composant individuel, donc elle peut être considérée comme un aspect

de la complexité des composants. Le concept de complexité des composants dans la

figure 5.9 couvre deux aspects de la complexité qui sont associés aux composants

individuels: la complexité des données entrées/sorties et la coordination entre elles. Alors

le terme de la complexité des composants dans la figure 5.9 n’a pas le même sens que le

terme de la figure 5.8. En fait, la complexité des composants dans le modèle de Wood

(figure 5.8) réfère à la complexité des éléments d’information seulement, tandis qu’elle

réfère à la complexité des composants individuel, y compris la complexité des entrées et

sorties et la coordination des données entre elles, dans notre modèle (figure 5.9). Cette

modification n’affecte pas l’essentiel du modèle de la complexité de la tâche ou celui de

la complexité du logiciel. Ici, nous faisons un regroupement des trois aspects de la

complexité du logiciel (la complexité des entrées et sorties, la coordination entre les

entrées et les sorties, et la coordination entre les processus fonctionnels) en deux

catégories: la complexité des composants et la complexité du système. Le modèle de


112

Wood se limite aussi à deux catégories qu’il appelle la complexité des composants et la

complexité de coordination. L’essentiel est que la complexité de la tâche et donc la

complexité fonctionnelle du logiciel est évaluée en trois dimensions: la complexité des

entrées et sorties, la complexité des relations entre les entrées et les sorties et la

complexité des relations entre les composants.

Ce cadre de la complexité fonctionnelle est conforme aux idées retenues de la famille des

mesures de points de fonction qui sont représentées dans le chapitre 3. La complexité

fonctionnelle du logiciel doit couvrir la complexité des composants ainsi que la

complexité du système. La complexité des composants fait référence à deux

aspects identifiés dans les modèles 6.3 et 6.5: les entrées et les sorties du processus et la

manipulation de données.

Il faut noter que la complexité des entrées et sorties du processus est la difficulté relative

à des actions d’entrées et de sorties. C’est-à-dire qu’elle fait référence au nombre de

groupes de données plutôt qu’au volume de données. Alors, la complexité des données

entrées sorties est similaire au concept de la complexité des composants de Wood (c-à-d,

le nombre d’éléments d’information). Elle est aussi similaire à la taille fonctionnelle de

COSMIC – le nombre de mouvements de données entrées, sorties. Elle indique le nombre

d’intrants et d’extrants des composants.

La complexité de la structure des composants fait référence à des branchements ou des

points de décisions dans le processus de manipulation de données et au nombre de cas

séparés à traiter. Elle est donc similaire à la mesure de McCabe et à la complexité de

coordination qui est mesurée par le nombre de points tournants (turning points) dans le

modèle de Wood.

Enfin, la complexité du système fait référence à la relation entre les composants. Ici nous

utilisons le même terme de Wood pour indiquer que ce type de complexité tient compte

des relations entre les composants. Cependant, pour le logiciel, le couplage de données

entre les composants revêt sensiblement la même signification que la séquence d’actions

du modèle de Wood.

Le tableau 5.2 présente la correspondance entre les concepts dans le cadre de la

complexité de la figure 5.9 et ceux de Wood de la figure 5.8. Les termes de COSMIC

sont utilisés dans la troisième colonne pour expliquer les concepts utilisés dans notre

modèle.


113

Concept dans le cadre de la complexité du logiciel

Concept dans le modèle de la complexité de la tâche de Wood

Interprétation en utilisant les terminologies de COSMIC

Processus fonctionnel Composant Processus fonctionnel (un composant de base du logiciel)

Entrées, sorties Éléments d’information Mouvement de données

Complexité de données entrées, sorties

Complexité des composants Pour tenir compte de mouvements de données

Complexité de structure des composants

Coordination entre les entrées et les sorties

Pour tenir compte de la manipulation de données

Complexité du système Coordination entre les actions ou les tâches élémentaires

Pour tenir compte de la relation entre les processus fonctionnels

Tableau 5.2: Correspondance entre les termes utilisés dans le cadre de la complexité et dans le modèle de la tâche de Wood.

La section qui suit propose trois mesures pour quantifier les trois types de complexité

établis dans le cadre de la figure 5.9.

5.2.4 Mesure de la complexité de données entrées/sorties

5.2.4.1 Nombre de groupes de données (NOD) La complexité de données entrées et sorties fait référence à la complexité des

mouvements des intrants et des extrants. Ce type de complexité coïncide avec la

complexité des composants dans le modèle de Wood. Par similarité à l’idée de Wood, le

nombre d’entrées et sorties est défini comme la complexité des données entrées et sorties

du processus fonctionnel. Une entrée ou une sortie est définie de façon similaire à

COSMIC, c’est-à-dire, elle est associée à un mouvement de données. Cependant, nous ne

comptons pas tous les mouvements de données comme COSMIC le fait. Nous comptons

seulement les mouvements de données qui introduisent quelque chose de nouveau (c-à-d,

un élément nouveau d’information) dans le processus fonctionnel. De cette façon, les

entrées et sorties sont équivalentes aux éléments d’information dans le modèle de Wood.

COSMIC-FFP compte tous les mouvements de données en entrées et en sorties. Un

mouvement de données fait un déplacement d’un groupe de données entrant ou sortant du

processus fonctionnel peu importe le fait que le groupe soit modifié ou non. Alors, un

groupe de données peut être compté plusieurs fois. Cette situation peut conduire à


114

certaines incohérences si on veut que la mesure reflète l’effort. Considérons les deux

processus suivants:

!" Processus A: recevoir un nombre entier du clavier, sauvegarder ce nombre

temporairement dans la mémoire et l’afficher sur l’écran. Ce processus

correspond à trois points de fonction avec la méthode COSMIC-FFP (voir la

figure 5.10a: E, W et X).

a) processus A b) processus B

Figure 5.10: Comptage la taille fonctionnelle de deux processus A et B.

!" Processus B: recevoir une chaîne de bits du canal d’entrée-sortie (I/O stream),

sauvegarder cette chaîne sur le disque en format Unicode de 16 bits. Ce processus

correspond à deux points avec COSMIC-FFP (voir la figure 5.10b: E, W).

Il est évident que ces comptages ne sont pas cohérents avec l’effort investi pour

développer ces deux processus. Si les points comptés pour les processus A et B sont

utilisés comme des indices de l’effort de développement de deux processus, cela implique

que le processus A est plus complexe que B parce qu’il a besoin de plus d’effort. Ce n’est

pas le cas. Intuitivement, le processus A est très simple et on peut le coder par une ou

deux instructions dans la plupart de langage de programmation de quatrième génération.

Cependant, le processus B est plus complexe en entrée et en sortie. Le comptage des

groupes de données distincts pourrait donc être plus approprié. Dans la figure 5.10, les

nombres de groupes de données distincts du processus A et B sont 1 et 2, respectivement.

En fait, dans le processus A, il y a un seul groupe de données: le nombre entier i. Par

contre, dans le processus B, la chaîne binaire à l’entrée et la chaîne en format Unicode à

la sortie sont deux choses différentes qui sont deux groupes de données ou deux éléments

d’information différents.

Nous proposons de compter le nombre de groupes de données distincts (NOD) au lieu

du nombre de mouvements de données. Les règles pour identifier les mouvements de

données et les groupes de données de COSMIC-FFP sont réutilisées pour compter NOD.


115

La seule différence est qu’un groupe de données non-modifié relatif à plusieurs

mouvements (comme dans la figure 5.10) est compté une seule fois.

5.2.4.2 Règles de comptage du nombre de groupes de données Nous utilisons les règles de COSMIC-FFP [1,3] pour identifier la frontière de

l’application (c-à-d, le logiciel), les processus fonctionnels, les stimuli et les mouvements

de données. Un processus fonctionnel est un ensemble ordonné de mouvements de

données. Un mouvement de données déplace d’un groupe de données entrant ou sortant.

Un groupe de données pourrait être une Entrée, une Sortie, une Lecture ou une Écriture.

Voici nos règles de comptage:

!" Compter un point pour chaque groupe de données relatif à une Entrée ou une

Lecture. Un mouvement de données de ces types apporte quelque chose de

nouveau au processus fonctionnel. Donc, il est considéré comme un « élément

d’information ».

!" Compter un point pour chaque groupe de données relatif à une Sortie ou une

Écriture si ce groupe de données est modifié depuis son dernier mouvement. Si le

groupe de données est compté déjà dans un mouvement et qu’il n’a pas été

modifié depuis ce mouvement, la Sortie ou l’Écriture de ce groupe ne donne pas

un élément nouveau d’information.

Le nombre de groupe de données (NOD) défini ci-dessus est plus proche de l’idée de

Wood pour mesurer la complexité des composants que le nombre de mouvements de

données de COSMIC-FFP. La complexité des composants dans les termes de Wood fait

référence aux éléments d’information, c’est-à-dire, aux groupes de données distincts

plutôt qu’aux actions à faire (c-à-d, déplacer) sur ces groupes. Avec les règles

d’identification ci-dessus, la complexité des données entrées et sorties est essentiellement

le nombre de groupes de données et non pas le nombre de mouvements de données. Un

mouvement de données n’est qu’un moyen pour introduire un « élément d’information »

au processus. Alors NOD est une partie de mesure de COSMIC-FFP. Il peut être défini en

termes de mouvements de données de COSMIC-FFP comme suit:

NOD = le nombre de mouvements de données qui font entrer ou sortir un élément

nouveau d’information du processus fonctionnel.

Cette définition vise à comparer NOD avec COSMIC-FFP. Il n’est pas nécessaire de

calculer le nombre de mouvements de données de COSMIC pour déterminer NOD.


116

5.2.5 Mesure de la complexité structurelle des composants

5.2.5.1 Nombre de conditions (NOC) Dans la figure 5.9, la complexité structurelle fait référence aux manipulations requises

pour produire les sorties désirées. Nous avons défini un seul type de manipulation de

données: règle d’opération. Une règle d’opération est une condition ou un prédicat qui

spécifie la relation entre les entrées et les sorties d’un processus. Elle représente une règle

que le traitement de données doit respecter pour produire les sorties désirées. Inspirés de

la mesure de McCabe et de l’idée de Wood, nous proposons que la complexité

structurelle des composants soit mesurée par le nombre de règles d’opération ou le

nombre de conditions (NOC).

Les règles d’opération peuvent être identifiées à partir de la spécification du logiciel. La

figure 5.6 présente la façon d’identifier ces règles. En fait, les spécifications du logiciel

doivent préciser ce qu’on veut obtenir à la sortie et la condition sur les entrées pour

obtenir une telle sortie. Autrement dit, une sortie est toujours associée à un sous-ensemble

d’entrées et à une condition d’appartenance à ce sous-ensemble. À l’inverse, une

condition d’appartenance définit un sous-ensemble des entrées qui doivent être

manipulées séparément pour produire une sortie désirée. Alors, le nombre de conditions

va fournir le nombre de cas à traiter dans la manipulation de données. Ceci peut être

considéré comme une mesure de la complexité de la manipulation parce que,

intuitivement, plus il y a de cas à traiter, plus il y a d’effort requis. De plus, chaque

condition conduit à (au moins) un nœud de décision dans le diagramme de flux de

données du logiciel, puis est associée à des instructions de contrôle (branchement) dans le

code du programme. De ce fait, le nombre de conditions fournit une image de la

complexité de la structure du processus. C’est pourquoi NOC est similaire à la mesure de

McCabe [118].

Dans la littérature, la mesure de McCabe est connue comme une bonne mesure de la

complexité structurelle du module. Elle est un bon indice de la facilité de compréhension

du programme – un facteur qui affecte l’effort pour comprendre le code ainsi que l’effort

de développement ou d’entretien du code. Par conséquent, NOC peut être considéré

comme une mesure de la complexité structurelle qui est associée à l’effort.


117

5.2.5.2 Règles de comptage du nombre de conditions Dans la pratique, NOC équivaut au nombre de sorties désirées. Cependant, pour compter

sans ambiguïté NOC, nous suggérons d’identifier les sous-ensembles d’entrées plutôt que

les sorties. NOC peut être calculé en se basant sur la cardinalité de la partition minimale

de l’espace des entrées pour obtenir les sorties désirées. Par exemple, la partition

minimale du problème « chercher la racine de x » comporte deux ensembles

correspondant aux conditions « x >=0 » et « x<0 ». Une partition comme « x >0 »,

« x=0 » et « x<0 » n’est pas une partition minimale. Dans cet exemple, la cardinalité de la

partition minimale est deux au lieu de trois.

Si l’espace des entrées se compose d’une seule classe, la condition d’appartenance de

cette classe est triviale. Par exemple, pour la fonction f(x) = x2, toutes les valeurs de x

appartiennent à une catégorie et sont traitées de la même façon, donc la condition

d’appartenance n’est pas nécessaire. Alors, NOC =0.

Si l’espace des entrées est divisé en deux classes ou plus, il pourrait exister des classes

qui n’exigent pas de manipulation Si une classe d’entrées n’est pas manipulée, la

condition d’appartenance de cette classe n’est pas comptée. Par exemple, pour la fonction

f(x) = x , l’espace des entrées est divisée en deux classes qui correspondent aux

conditions « x>=0 » et « x<0 ». Normalement, on veut chercher la racine de x, donc on

s’intéresse à la première classe. Si la deuxième classe (x<0) n’est pas manipulée, la

condition de cette classe n’est pas comptée, donc NOC = 1. Cependant, si cette classe est

manipulée pour produire une sortie significative (un message d’erreur, par exemple), elle

est alors comptée.

En se basant sur ces règles de comptage, NOC pourrait être interprété comme le nombre

minimal de chemins indépendants de l’entrée à la sortie du processus. En fait, comme

illustré dans la figure 5.6, chaque sous-ensemble de la partition de l’espace des entrées est

manipulé comme un cas particulier pour produire une sortie désirée. La condition

d’appartenance associée à chaque sous-ensemble pourrait être un prédicat simple ou

complexe. Cependant, nous ne nous intéressons pas à la complexité de l’expression du

prédicat. Ce qui nous intéresse est « combien y a-t-il cas différents à traiter dans le

processus fonctionnel?». De ce fait, NOC fournit une image globale de la structure de

branchement sans référence à la structure de contrôle d’une implémentation spécifique.


118

5.2.6 Mesure de la complexité du système

La complexité du système fait référence aux relations entre les processus fonctionnels

dans le système. Généralement, ce type de complexité tient compte de la complexité

associée aux relations entre les composants du système. Dans la littérature, deux relations

sont plus discutées soit: la relation de données (la dépendance de données) et la relation

de contrôle (la dépendance de contrôle). Les deux types de relation pourraient être

modélisés par le même modèle. C’est le diagramme de flux (diagramme de flux de

données ou diagramme de flux de contrôle). Le graphe orienté est le modèle

mathématique de base pour représenter le diagramme de flux. De ce fait, plusieurs

mesures (voir [180]) ont été développées en se basant sur la théorie des graphes.

Les mesures de la complexité basées la théorie de graphe peuvent être classifiées en deux

catégories. La première catégorie fait référence à la complexité du graphe qui représente

le système. Autrement dit, la complexité du système est étudiée via la complexité du

graphe et quantifiée via les notions associées au graphe comme:

!" Le nombre de nœuds (V).

!" Le nombre d’arcs (E).

!" Le nombre de nœuds de décisions (D).

!" Fan-in: le nombre d’arcs d’entrée d’un nœud.

!" Fan-out: le nombre d’arcs de sortie d’un nœud.

!" Le nombre de chemins.

!" Le nombre de cycles, etc.

Par exemple:

!" La mesure de la complexité de McCabe [118] est E-V+2

!" La mesure de la complexité de Shepperd [143] est (fan-in x fan-out)2

La deuxième catégorie contient les mesures qui sont basées sur la théorie de

l’information. Ces mesures tiennent compte de l’information échangée dans le système.

Les mesures typiques de ce genre sont la mesure de Davis et Leblanc [54], et celle de

Harrison [78]. Pour cette catégorie, la complexité du système est mesurée par l’entropie

de l’information dans le système. Les relations de données et de contrôle entre les

composants sont modélisées comme un graphe, puis l’entropie de l’information dans le

graphe devient une mesure de la complexité.


119

Dans notre thèse, les relations de données et de contrôle entre les processus fonctionnels

sont modélisées comme un graphe orienté auquel à chaque arc est assigné un nombre qui

indique le nombre de groupes de données transférés. La modélisation est la suivante:

!" Un nœud du graphe représente un processus fonctionnel. Donc, la cardinalité de

l’ensemble de nœuds est le nombre de processus fonctionnels du logiciel.

!" Un arc orienté de A à B représente un transfert de données d’un processus A à un

processus B. À un arc est assigné un poids qui indique le nombre de groupes de

données transférées.

Les concepts suivants sont définis:

!" In-arc d’un nœud A: un arc orienté vers A.

!" Out-arc d’un nœud A: un arc dont l’origine est A.

!" In-degré d’un nœud A: le nombre d’in-arcs du nœud A.

!" Out-degré d’un nœud A: le nombre d’out-arcs du nœud A.

L’ensemble de nœuds est divisé en classes d’équivalence. Chaque classe contient des

nœuds de même in-degré et out-degré. Supposons que P est l’ensemble de tous les

processus (c-à-d, les nœuds), {P1,P2, …,Pn} est une partition de P en classes

d’équivalence. L’entropie du système (EOS) est:

EOS = - PP

PP i

n

i

i log1(&

où X est la cardinalité de X (ici X est un ensemble discret et

fini)

Figure 5.11: Exemple d’un graphe représentant la relation de données entre les processus.

Par exemple, les nœuds du graphe G dans la figure 5.11 sont classifiés en cinq classes

d’équivalence: {a}, {b,f},{c,e},{d} et {g}. Donc, l’entropie du système modélisé par le

graphe G est:

EOS = -[1/7log1/7 + 2/7log2/7 + 2/7log2/7 + 1/7log1/7 + 1/7log1/7] = 2,24.

EOS est la complexité du système (inter-processus) et elle fait référence à la

communication entre les processus fonctionnels. L’entropie ne reflète pas le volume


120

d’information transféré entre les processus, mais le degré d’organisation du système. Un

système dont tous les processus sont identiques, c’est-à-dire qui ont tous le même nombre

de relations entre eux, est moins complexe qu’un système dont les processus sont

différents. L’entropie est nulle quand tous les processus sont dans une seule classe, c’est-

à-dire que tous les processus sont identiques dans la forme de relation avec d’autres

processus. Par contre, si les processus sont tous différents, alors chaque classe contient un

seul processus et l’entropie du système prend la valeur maximale: EOS= log(n), où n est

le nombre de processus fonctionnels du système.

Cette mesure est similaire à la mesure de Davis et LeBlanc [54]. Cependant, Davis et

LeBlanc étudient séparément les dépendances de données et les dépendances de contrôle

entre les « chunks » de code. De plus, la mesure de Davis et LeBlanc est appliquée au

code source du programme. Dans notre thèse, la mesure de l’entropie est appliquée au

système dès la phase de l’analyse pour quantifier le degré de structure (ou d’organisation)

entre les composants du système. Un système ayant une entropie plus élevée offre moins

de régularité (ses composants sont différents) qu’un système avec une entropie plus basse.

Autrement dit, dans un système de basse entropie, les processus ont des relations

semblables avec les autres processus, et par conséquent, le système est plus régulier,

moins complexe.

5.2.7 Résumé des mesures proposées pour mesurer la complexité du logiciel

Dans la section précédente, trois mesures pour quantifier les trois aspects de la

complexité représentés dans le cadre de la figure 5.9 ont été proposées. Le tableau 5.3

résume les trois mesures proposées dans ce chapitre pour quantifier la complexité

fonctionnelle du logiciel. Ce tableau résume aussi les interprétations de ces mesures et

liste des mesures similaires.

Le nombre de groupes de données (NOD) est proposé comme une mesure de la

complexité des données entrées et sorties. Cette mesure tient compte de la taille des

composants en termes de groupes de données entrées/sorties. Elle ne tient pas compte de

la grandeur (ou volume) des données et de la structure de celles-ci. Cette mesure est

similaire au nombre de mouvements de données de COSMIC. Elle est aussi similaire au

nombre d’entrées et de sorties de Mark-II plutôt qu’aux points de fonction non-ajustés

(UFP) d’Albrecht parce que dans la méthode d’Albrecht, le poids pour chaque


121

entrée/sortie est évalué en se basant sur le volume de données (le nombre

d’enregistrements et le nombre de champs, voir IFPUG 98 [90]). De plus, la mesure

proposée se conforme totalement à la nature de la complexité des composants dans le

modèle de Wood. Un groupe de données correspond à un élément d’information dans le

modèle de Wood.

Dimension de la complexité

Mesure Référence à Similaire à

Complexité des entrées, sorties.

NOD – nombre de groupes de données.

!" La taille des composants.

!" La complexité en entrée et en sortie.

!" Le nombre

d’éléments d’information de Wood.

!" COSMIC FFP- nombre de mouvements de données.

Complexité de la structure des composants.

NOC – nombre de conditions.

!" La complexité de branchements des composants.

!" Nombre de cas à traiter.

!" La complexité de la manipulation des données.

!" Nombre de « points tournants » (turning points) de Wood.

!" Nombre cyclomatique de McCabe.

Complexité du système.

EOS – Entropie de l’information en communication.

!" La complexité de communication entre les composants.

!" La coordination entre les processus.

!" La régularité dans le système.

Mesure de l’entropie proposée par Davis et LeBlanc.

Tableau 5.3: Résumé des mesures proposées pour la complexité du logiciel.

Le nombre de conditions (NOC) est proposé comme une mesure de la complexité

structurelle des composants. Elle fait référence à la complexité de la manipulation des

données dans un processus fonctionnel. Elle capture le nombre de cas à traiter pour

produire les sorties désirées. Elle ne tient pas compte de la complexité algorithmique ou

computationnelle du processus.

NOC est similaire à la mesure de McCabe parce qu’elle reflète la structure des

composants – les branchements du chemin de l’entrée à la sortie des composants

individuels. Cette mesure est conforme aussi à l’idée de Wood sur la complexité de


122

coordination entre les entrées et les sorties de la tâche parce qu’elle fait référence au

nombre de décisions pour produire les sorties désirées – ce que Wood appelle les points

tournants (turning points).

Enfin, l’entropie du système est proposée comme une mesure de la complexité du

système. Elle fait référence à la complexité des relations de données (couplage de

données) entre les processus fonctionnels. Si les relations entre les composants sont

régulières (semblables), on peut percevoir moins de désordre, donc le système est moins

compliqué.

Le logiciel est un système de traitement de l’information dans lequel les processus

fonctionnels doivent bien coopérer pour offrir la fonctionnalité du système, ce qu’Ashby

considère comme le « tout » – le tout est plus grand que la somme des parties [11]. De ce

fait, la coopération de données entre les processus doit être mesurée pour mieux

caractériser la complexité du système.

5.3 ÉTUDE DE CAS

Cette section représente une étude de cas pour les mesures proposées. L’étude de cas a

pour but de montrer comment appliquer les mesures à un problème réel. L’application à

étudier ici est une application en temps réel. Il s’agit un logiciel qui simule un « Cuiseur

de Riz (« Rice Cooker »).

5.3.1 Spécification de l’application

La spécification suivante est simplifiée de la spécification d’un « Rice Cooker » publiée

dans [84]. La figure 5.12 représente le panneau de contrôle du Cuiseur de Riz.

Figure 5.12: Panneau de contrôle du Cuiseur de Riz.


123

Figure 5.13: Température cible par mode.

!" Le Cuiseur peut cuire du riz selon trois modes: rapide (fast), normal et gruau

(gruel).

!" Le Cuiseur commence à cuire le riz quand le bouton Start est appuyé.

Normalement, un mode est sélectionné avant d’appuyer sur le bouton Start, alors

le Cuiseur fonctionne dans ce mode. Si aucun mode n’est sélectionné, le Cuiseur

fonctionne en mode normal, par défaut. Quand le Cuiseur est en train de cuire le

riz, le mode de cuisson ne peut pas être changé.

!" Quand le riz est cuit, le Cuiseur entre dans l’état chauffage (warming).

!" Une lampe appropriée doit être allumée pour indiquer l’état de Cuiseur: cuisson

(cooking) ou chauffage (warming).

!" Le chauffage est contrôlé selon le mode sélectionné et la température effective du

Cuiseur. Celle-ci est ajustée comme suit:

o La température du Cuiseur pour un mode donné et un point à un temps

donné est prédéfinie par les courbes de la figure 5.13. La température

cible (target temperature) est établie pour 30 secondes à la fois. Et,

o À toutes les cinq secondes, la température effective du Cuiseur est

mesurée à partir d'un détecteur. Cette valeur est comparée avec la

température cible. Si la valeur cible est plus haute que la valeur effective,

le chauffage doit être mis en état de marche (ON). À l’opposé, si la

valeur cible est plus basse, le chauffage doit être mis dans l’état arrêt

(OFF).


124

5.3.2 Comptage de la complexité du Cuiseur de riz

Figure 5.14: Architecture du Cuiseur de riz.

Légende de notations utilisées dans la figure 5.14:

Un groupe de données qui joue le rôle d’un événement

Un groupe de données

Un processus

Un composant matériel (hardware)

La frontière de l’application

Tableau 5.4: Légende de la figure 5.14.

Selon la spécification, quatre processus fonctionnels sont identifiés:

!" Choisir un mode qui permet à l’utilisateur de choisir un mode pour le Cuiseur. Ce

processus est déclenché quand un bouton de mode est appuyé.

!" Mesurer le temps écoulé (elapsed time) qui compte le temps écoulé depuis la

mise en marche du Cuiseur. Ce processus génère les signaux pour signaler

l’arrivée des événements 5 secondes et 30 secondes. Il est déclenché lorsque

l’utilisateur appuie sur le bouton Start.

!" Contrôler le chauffage qui s’occupe de mettre en marche le chauffage ou

d’arrêter le chauffage selon la température cible et la température effective du

Cuiseur. Ce processus est déclenché toutes les cinq secondes, c’est-à-dire quand

l’événement 5 secondes arrive.


125

!" Établir la température cible qui s’occupe de mettre à jour la température cible

pour le Cuiseur à chaque 30 secondes. Il est déclenché quand l’événement 30

secondes arrive.

Les processus identifiés de l’application de Cuiseur de riz et les relations entre eux sont

présentés dans la figure 5.14.

5.3.2.1 La complexité des composants (NOD) # Processus Déclenché par Groupe de données (NOD) Taille mesurée par COSMIC-

FFP 1 Choisir un mode Appuie sur un

mode 1. mode choisi NOD = 1

!" E: mode choisi !" W: mode choisi

Cfsu = 2

2 Établir la température cible

Événement 30s 1. temps écoulé 2. mode 3. temps total pour cuire 4. tableau de

températures prédéfinies (figure 5.13)

5. température cible 6. état de Cuiseur NOD=6

!" R: temps écoulé !" R: mode !" R: temps total pour

cuire !" R: tableau de

températures prédéfinies (figure 5.13)

!" W: température cible !" X: état du Cuiseur

Cfsu = 6

3 Contrôler le chauffage

Événement 5s 1. température cible 2. température actuelle 3. état du chauffage

(marche/arrêt) NOD=3

!" R: température cible !" E: température actuelle !" X: état du chauffage

(marche/arrêt) Cfsu =3

4 Mesurer le temps écoulé

Appuie sur le bouton Start

1. signal de l’horloge 2. temps écoulé 3. événement 30s 4. événement 5s NOD=4

!" E: signal de l’horloge !" W: temps écoulé !" X: temps écoulé !" X: événement 30s !" X: événement 5s

Cfsu = 5

Total NOD = 14 Total Cfsu = 16 Tableau 5.5: Complexité des composants (NOD) et la taille fonctionnelle de COSMIC du

Cuiseur de Riz.

La complexité des composants mesurée par le nombre de groupes de données est analysée

dans le tableau 5.5. La mesure de COSMIC (c-à-d., COSMIC-FFP) est aussi appliquée à


126

cette spécification. Le comptage utilisant COSMIC-FFP est présentée aussi dans ce

tableau pour illustrer la différence entre NOD et COSMIC-FFP.

Notez que, dans le processus « Choisir un mode », le mode choisi est compté deux fois

selon COSMIC-FFP. Cependant, il est compté une seule fois dans NOD parce qu’il ne

change jamais. Similairement, le « temps écoulé » est compté deux fois dans COSMIC

mais il est compté une seule fois dans NOD.

5.3.2.2 La complexité de manipulation de données (NOC) !" Pour le processus «Choisir un mode », il n’y a aucune condition, donc NOC=0.

!" Pour le processus « Établir la température cible », NOC = 2, parce qu’il y a deux

conditions qui correspondent à deux sorties différentes:

Si (temps écoulé < temps total pour cuire) Alors état du cuiseur = cuisson.

Si (temps écoulé >= temps total pour cuire) Alors état du cuiseur = chauffage.

!" Pour le processus « Contrôler le chauffage », NOC = 2, parce qu’il y a deux


Si (température effective < température cible) Alors état du chauffage = marche

(ON).

Si (température actuelle >= température cible) Alors état du chauffage = arrêt

(OFF).

!" Pour le processus « Mesurer le temps écoulé », NOC = 2, parce qu’il y a deux


Si (le temps écoulé MOD 30 = 0) Alors émettre un élément « 30s »

Si (le temps écoulé MOD 5 = 0) Alors émettre un élément « 5s ».

Donc, la complexité de la structure de l’application « Cuiseur de riz » est 6 (NOC=6).

5.3.2.3 La complexité du système Les relations de données et de contrôle entre les processus du Cuiseur de riz sont

représentées dans la figure 5.14. Les flèches continues à l’intérieur de la frontière du

logiciel représentent les dépendances de données, tandis que les flèches pointillées

représentent les dépendances de contrôle entre les processus fonctionnels. Alors, le

graphe représentant la relation de données entre les processus fonctionnels du Cuiseur de

riz est illustré dans la figure 5.15.


127

Figure 5.15: Graphe représentant les dépendances de données entre les processus

fonctionnels du Cuiseur de riz.

Les quatre processus du cuiseur sont classifiés en trois classes comme suit:

!" {Choisir un mode, Mesurer le temps écoulé} avec in-degré = 0,

!" out-degré = 1.

!" {Établir la température cible} avec in-degré = 2, out-degré = 1.

!" {Contrôler du chauffage} avec in-degré = 1, out-degré = 0.

Alors l’entropie du système est:

EOS = - [2/4log(2/4) + 1/4log(1/4) + 1/4log(1/4)] = 1,5.

La complexité de l’application « Cuiseur de riz » est donc représentée par un vecteur

comptant mesures NOD, NOC et EOS, soit (14; 6; 1,5).

5.4 RÉSUMÉ

Dans ce chapitre, le modèle du logiciel de COSMIC est introduit comme un modèle de

base pour modéliser le logiciel. Un logiciel est modélisé comme un ensemble de

processus fonctionnels. Un processus fonctionnel est représenté par un ensemble ordonné

de mouvements de données et un ensemble de manipulation de données. COSMIC ne

précise pas les manipulations de données. Par conséquent, la complexité des

manipulations de données n’est pas encore capturée et quantifiée dans COSMIC-FFP. De

plus, la méthode ignore aussi les relations entre les processus fonctionnels.

Notre recherche a porté sur ces limites. Grâce au modèle de la complexité de la tâche de

Wood, on peut dire que la complexité des manipulations de données et la complexité des

relations entre les processus fonctionnels sont pertinentes. Elles correspondent aux deux

types de complexité de coordination dans le modèle de Wood.


128

En se basant sur le modèle de la complexité de la tâche de Wood, la complexité des

manipulations de données est définie comme la coordination entre les entrées et les

sorties. Elle est caractérisée par les règles d’opération. Une règle d’opération prend le

format «SI … ALORS…» qui décrit un cas à traiter dans une manipulation de données.

Quant aux relations entre les composants, nous nous intéressons à un seul type de

relation, à savoir la relation des données entre les processus, parce qu’au niveau de la

fonctionnalité, seul ce type de relation est clair. Ces améliorations permettent de créer un

cadre conceptuel de la complexité fonctionnelle du logiciel plus complet et bien conforme

au modèle de la complexité de la tâche de Wood. Le cadre de la complexité couvre trois

aspects de la complexité: la complexité de données entrées et sorties, la complexité de la

manipulation de données et la complexité de coordination entre les processus fonctionnels

Nous proposons trois mesures correspondant à ces trois aspects:

!" Le nombre de groupe de données (NOD) qui capture la complexité des données

entrées et sorties. Cette mesure fait référence aux éléments d’information présents

(idée de Wood) plutôt qu’au nombre de mouvements de données (idée de

COSMIC).

!" Le nombre de conditions (NOC) capture la complexité des manipulations de

données dans un processus fonctionnel. Cette mesure fait référence au nombre de

cas à traiter dans le processus. Elle reflète aussi la structure du processus

fonctionnel parce que les conditions conduiront à des points de décisions dans le

code source du programme qui implémente le processus.

!" L’entropie du système est proposée pour mesurer le niveau de régularité (ou celui

de désordre) des relations entre les processus du système. Un système est plus ou

moins complexe dépendamment des relations entre ses composants. Si les

processus sont semblables dans la forme de relations, le système est perçu comme

moins compliqué.

Les mesures proposées dans ce chapitre sont aussi conformes aux idées philosophiques

introduites au chapitre 1. Au point de vue systémique, ces trois mesures couvrent la

complexité des composants individuels et la complexité du système. La complexité des

composants, mesurée par NOD et NOC, couvre les deux aspects de la modélisation d’un

processus fonctionnel: les données entrées et sorties et les manipulations. De ce fait, les

mesures proposées sont nécessaires dans le sens qu’elles couvrent des aspects

importants. Le chapitre 6 va présenter les résultats d’une étude empirique qui permet de


129

conclure que ces mesures sont pertinentes et suffisantes dans le sens qu’elles reflètent

bien l’effort de développement du logiciel.

CHAPITRE 6

INVESTIGATION EMPIRIQUE ET VALIDATION DES MESURES DE LA COMPLEXITÉ FONCTIONNELLE

Dans ce chapitre, une investigation empirique est faite pour illustrer la pertinence des

mesures proposées dans le chapitre précédent. D’abord, certains concepts relatifs à la

validation d’une méthode de mesure sont présentés. Puis, le cadre de validation de

Jacquet est utilisé pour guider notre processus de la validation.

Notre investigation empirique utilise 15 projets de maintenance du logiciel. Nous

n’étudions que les fonctions à développer ou à modifier. Les travaux pour maintenir la

base de données ou pour supprimer des fonctions ou re-tester le système sont ignorés.

Autrement dit, nous ne nous intéressons qu’à la partie nouvelle à développer plutôt qu’à

tous les travaux de maintenance. Cette restriction permet de généraliser le résultat de

l’expérimentation qui est faite sur des projets de maintenance pour l’appliquer à de

nouveaux projets de développement.

Pour vérifier la pertinence des mesures proposées, l’effort réel de développement des

nouvelles fonctions et de modifications des fonctions est utilisé comme une variable

indépendante. Les techniques de l’analyse de régression et de régressions multiples sont

appliquées. Une simple mesure est considérée valide si elle est en bonne corrélation avec

l’effort de développement du projet ou si elle est associée à d’autres mesures pour obtenir

une bonne corrélation avec l’effort de développement. De plus, les tests croisés sont

utilisés pour confirmer la pertinence des mesures proposées et la qualité des modèles de

prédiction d’effort contruits à partir des analyses de régressions multiples.

6.1 CONCEPT DE VALIDATION DE LA MESURE

Grosso modo, la validation d’une méthode de mesure vise à s’assurer que la mesure est

correcte. Fenton distingue la validation d’une mesure du logiciel et la validation d’un

système de prédiction (du logiciel).

Investigation empirique et validation des mesures de la complexité fonctionnelle

131

6.1.1 Validation d’une mesure

La validation d’une mesure est le processus assurant que la mesure est une caractérisation

numérique adéquate de l’attribut mesuré en démontrant que la condition de représentation

est satisfaite [62, p.105]. Alors la validation concerne deux aspects:

!" la mesure capture la bonne chose, c’est-à-dire qu’elle capture ce que l’on veut

mesurer, et

!" la mesure est correcte, c’est-à-dire que les résultats de mesures sont conformes

aux relations empiriques de l’attribut mesuré.

Par exemple: on veut mesurer la longueur d’un programme. Donc, « programme » est

l’entité et « longueur » est l’attribut. Une mesure m est correcte si elle n’est pas contraire

aux attentes sur la longueur du programme. Au moins, elle doit satisfaire l’intuition sur la

longueur et la concaténation de deux programmes. C’est-à-dire que les deux conditions

suivantes doivent être satisfaites:

!" m(P1+ P2) = m(P1) + m(P2), où (P1 + P2) est la concaténation de P1 et P2.

!" m(P1) > m(P2), si P1 est plus grand que P2.

Une mesure qui satisfait ces deux conditions peut être considérée comme une mesure

correcte de la longueur du programme. Dans ce sens, le nombre de caractères du texte du

programme est une mesure correcte; le nombre de lignes de code est aussi une mesure

correcte de la longueur du programme.

Ce type de validation est basé sur la théorie de la mesure [62]. La validation se concentre

sur la préservation de relations empiriques. Elle est associée à des axiomes parce que les

axiomes sont des représentations formelles de relations empiriques. Par exemple, les deux

conditions établies plus haut pourraient être considérées comme deux axiomes pour une

mesure de la longueur d’un programme.

Une validation se basant sur la théorie de la mesure rencontre des obstacles si le système

empirique n’est pas bien compris. Alors, pour des attributs vagues comme la complexité,

la qualité du logiciel, la validation de ce type est applicable à condition que l’on ait un

Validating a software measure is the process of ensuring that the measure is a proper numerical characterization of the claimed attribute by showing that the representation condition is satisfied.

(Fenton, 1997)


132

ensemble d’axiomes sur l’attribut mesuré. Un ensemble d’axiomes pour la complexité est

encore une cible à atteindre dans le domaine de la mesure. Parmi les axiomes proposés

pour la complexité du logiciel, les neufs axiomes de Weyuker [174] sont souvent cités.

Cependant, ils ont subi plusieurs objections (voir [62,180]) car ils font référence parfois à

la longueur du code, parfois à la structure du code. Il y a aussi des objections en rapport

avec l’échelle de mesure à laquelle les axiomes de Weyuker font référence [107].

Actuellement, aucun système d’axiomes n’est accepté comme un système normalisé pour

valider les mesures de la complexité du logiciel. La validation basée sur la théorie de la

mesure est donc encore loin d’être applicable.

6.1.2 Validation d’un système de prédiction

La validation d’un système de prédiction dans un environnement est le processus qui

établit l’exactitude du système en utilisant des moyens empiriques, c’est-à-dire en

comparant la performance du modèle de prédiction aux données réelles [62, p.104].

Ce type de validation concerne l’expérimentation et le test des hypothèses pour les

confirmer ou les rejeter. Des techniques statistiques sont utilisées pour la validation. Dans

le domaine de la mesure du logiciel, ce type de validation est fréquemment appliqué.

L’exactitude d’un modèle de prédiction est évaluée via la marge d’erreur des prédictions

faites par le modèle.

Les mesures utilisées pour analyser la marge d’erreur ont été présentées dans le chapitre 3

de cette thèse. Les mesures les plus importantes sont:

!" MRE: l’amplitude d’erreur relative qui est la valeur absolue de la différence entre

la valeur réelle (Er) et la valeur estimée (E) sur la valeur réelle.

MRE = r

r

EEE ,

(1)

!" MMRE: la moyenne des amplitudes d’erreur relative (ou simplement le taux

d’erreurs moyen).

MMRE = n

n

(&1i

iMRE (2)

!" PRED(x): le taux des cas d’estimation ayant MRE-x.


133

PRED (x) = nxMREayant projets de nombre le -

(3)

La marge d’erreur acceptable dépend de l’attribut considéré. En général, une marge

d’erreur de 25% pour 75% des cas de prédiction (c-à-d, PRED(0,25) .0,75) est

acceptable [49]. Quelques attributs ont besoin d’une estimation de haute précision. Par

exemple, plusieurs chercheurs demandent que la marge d’erreur de l’estimation du coût

de développement du logiciel soit à 20% et moins. La marge d’erreur acceptable proposée

pour le modèle COCOMO d’estimation des coûts, est de 20% [31].

6.1.3 Problèmes de validation d’une mesure

Dans le domaine de mesure du logiciel, une mesure n’est pas souvent validée directement

parce que, pour la plupart des mesures, on n’a pas un système empirique pour juger si la

mesure préserve la relation empirique pertinente à l’attribut mesuré. L’approche

commune pour valider une méthode de mesure est de valider le système de prédiction

construit sur cette mesure. Si le modèle de prédiction est valide pour estimer un attribut

externe (p.ex., l’effort) qui est associé avec un attribut interne (p.ex., la complexité du

code), la mesure est considérée valide pour mesurer l’attribut interne.

Par exemple: on ne peut pas valider directement (c-à-d, valider en se basant sur la théorie

de la mesure) si la mesure des lignes de code (LOC) est une mesure de la complexité du

code du logiciel parce qu’on ne connaît pas ce qu’est la complexité du code. Le monde

empirique de la complexité n’est pas bien connu. Cependant, on peut analyser la

corrélation entre LOC et l’effort pour écrire le code, par exemple. De l’analyse de

corrélation, un modèle de régression linéaire entre LOC et l’effort est établi. Ce modèle

peut être considéré comme un modèle de prédiction de l’effort à partir de LOC. Puis, la

performance de ce modèle peut être analysée. Si la performance est élevée, c’est-à-dire si

la marge d’erreur de la prédiction est basse, le modèle de prédiction est « valide ». Alors

on dira que LOC est une mesure valable pour estimer l’effort. Si on interprète la

complexité strictement en termes d’effort pour écrire le code, LOC peut être interprété

comme une mesure de la complexité. De ce fait, le terme de complexité, dans ce cas,

réfère à un aspect très étroit de la complexité du logiciel. Cette approche est critiquée par

plusieurs chercheurs du domaine [62,106]. Malheureusement, elle est encore l’approche

principale de validation d’une mesure. La validation de ce type aura encore sa place tant

qu’un consensus sur la complexité du logiciel ne sera pas établi.


134

Une autre approche de validation d’une méthode de mesure est proposée par Jacquet [93].

Cette approche analyse complètement le processus de développement d’une méthode de

mesure: de la conception de la méthode jusqu’à l’utilisation de la méthode. La validation

dans ce sens est la validation du processus de développement d’une mesure, dont la

validation de la mesure est une partie.

6.2 PROCESSUS DÉVELOPPEMENT D’UNE MÉTHODE DE MESURE

Le logiciel est un produit complexe qui se compose d’entités tangibles et non tangibles.

Par conséquent, le développement d’une méthode de mesure du logiciel est souvent relatif

à la modélisation. Le logiciel doit être modélisé adéquatement pour que les entités

considérées et leurs attributs puissent être capturés. Une méthode de mesure se compose

d’un modèle du logiciel et des règles d’assignation numérique qui assurent une mise en

correspondance entre le monde empirique et le système formel.

Dans la pratique, les mesures sont développées afin de quantifier certains attributs du

logiciel. Elles sont utilisées, par la suite, par certains modèles de prédiction. Ceux-ci

estiment les ressources nécessaires pour développer le logiciel ou d’autres

caractéristiques futures du logiciel. Les mesures sont aussi utilisées pour interpréter des

caractéristiques du logiciel, par exemple la densité d’erreurs dans le code, la difficulté à

tester le logiciel, etc.

Étape 1 Construction de la méthode de mesure

3

Étape 2 Application de la méthode

3

Étape 3 Obtention des résultats

3

Étape 4 Exploitation des résultats

Figure 6.1: Processus de mesure [93].

De ce fait, le développement d’une méthode de mesures comprend non seulement la

proposition de la méthode mais aussi l’application de la méthode et l’exploitation des

résultats de mesure. Le processus de développement d’une méthode de mesure proposé

par Jacquet [93] est présenté dans la figure 6.1. Chacune de ces étapes est détaillée en

sous étapes dans la figure 6.2a.

Étape 1: Conception de la méthode de mesure

!" Définition des objectifs: l’objectif de mesure, l’objet (entité) et l’attribut mesuré

doivent être précisés.


135

!" Caractérisation de l'attribut mesuré: après que l’attribut de mesure ait été précisé,

une définition opérationnelle empirique de cet attribut doit être établie. Pour un

attribut concret (p.ex., ligne de code), une telle définition ne serait pas difficile à

construire. Cependant, pour un attribut abstrait (p.ex., la compréhensibilité du

programme, la complexité structurelle du programme), une telle définition ne

sera pas évidente. Dans ce cas, la définition devrait indiquer le sens du concept

utilisé. Elle est relative aussi à la modélisation du concept et du logiciel.

!" Construction ou sélection d’un méta modèle: cette étape concerne la modélisation

du logiciel pour que l’attribut mesuré soit capturé. Les types d’entité élémentaire

qui seront utilisés pour décrire le logiciel sont définis à cette étape.

!" Définition des règles d'assignation numérique: les règles d’assignation numérique

sont établies pour que l’attribut mesuré soit quantifié de façon cohérente. C’est-à-

dire, elles préservent les relations empiriques de cet attribut. Par exemple, pour la

longueur du code, les règles d’assignation numérique doivent s’assurer qu’à un

programme plus long (par l’intuition) est assigné un nombre plus grand.

Figure 6.2a: Modèle détaillé du processus de mesure [93].

Étape 2: Application de la méthode de mesure

!" Les documents nécessaires à l'application de la mesure sont rassemblés. Par

exemple les codes sources doivent être collectés pour une mesure de lignes de


136

code; les spécifications du logiciel doivent être collectées pour une mesure de

points de fonction.

!" Le logiciel à mesurer est modélisé en utilisant les règles qui caractérisent les

attributs à mesurer. Par exemple, pour la mesure de lignes de code, les lignes

vides et les commentaires pourraient être éliminés pour retenir seulement les

lignes contenant de véritables instructions.

!" Les règles d'assignation numérique sont appliquées. Il faut s’assurer que les

règles sont appliquées correctement.

Étape 3: L'application de la méthode de mesure fournit un résultat qui pourra être

analysé. Cette étape concerne la gestion des résultats de mesure plutôt que la technique de

mesure. Les résultats obtenus à la deuxième étape sont documentés et révisés

soigneusement pour assurer la qualité. Parmi d’autres, le rapport du processus de mesure

et la description de l’équipe (p.ex., l’expérience, la familiarité de l’équipe avec la mesure)

de mesure sont nécessaires.

Étape 4: Les résultats fournis par la méthode sont exploités dans les modèles analytiques,

qualitatifs ou quantitatifs. Dans cette étape, les résultats de mesure sont utilisés pour

analyser les caractéristiques du logiciel, par exemple les facteurs de qualité du logiciel. Ils

sont aussi utilisés pour les travaux de gestion du projet, par exemple, l’estimation du

budget et du temps de calendrier pour réaliser le projet ou l’estimation de l’effort de

développement/maintenance du logiciel.

6.3 Validation du processus de développement d’une méthode de mesure

Le modèle des figures 6.1 et 6.2a met l’accent sur la modélisation du logiciel, la

définition des règles de comptage et l’utilisation de la mesure. De plus, il implique

qu’une mesure est utile si elle est exploitée par un modèle de prédiction avec une haute

précision. Pratiquement, une bonne mesure doit aider à évaluer l’état futur du logiciel ou

à prévoir les ressources nécessaires pour développer le logiciel.

Le modèle dans la figure 6.2a propose non seulement un processus de développement

d’une méthode de mesure mais aussi un cadre conceptuel pour valider une méthode de

mesure. Jacquet [94] ont proposé trois types de validation d’une méthode de mesure tout

au long de son processus de développement (figure 6.2b):


137

!" Validation de la conception (design) de la méthode de mesure: ce type de

validation est relatif à l’étape 1 de la figure 6.2b. Elle vérifie si la méthode

capture et mesure exactement ce qu’on veut mesurer.

!" Validation de l’application d’une méthode de mesure: cette validation a pour but

d’assurer que la méthode de mesure est appliquée (étape 2 et 3 de la figure 6.2b)

correctement et que les résultats obtenus sont fiables.

!" Validation du système de prédiction: cette validation tient compte de la qualité du

modèle de prédiction qui utilise les résultats de mesure. Par exemple, le nombre

de lignes de code est utilisé pour estimer l’effort de développement et le coût du

logiciel dans le modèle COCOMO [31]; la validation doit montrer la qualité de ce

modèle.

Validation de la conception de la méthode de mesure

Validation de l’application d’une méthode de mesure

Validation du système de prédiction

Figure 6.2b: Trois types de validation d’une méthode de mesure.

Des techniques statistiques sont souvent utilisées à cette étape pour établir le modèle de

prédiction et analyser la performance du modèle établi. La performance du modèle de

prédiction est évaluée par l’analyse de corrélation et la marge d’erreur de prédiction

(c-à-d, l’analyse basée sur les mesures MRE, MMRE et PRED).


138

6.4 VALIDATIONS DES MESURES PROPOSÉES DANS CETTE THÈSE

Le cadre de validation de la figure 6.2b est utilisé comme un prototype de la validation.

Les trois types de validation représentés dans la section 7.3 sont appliqués pour valider

les mesures de la complexité fonctionnelle qui sont proposées dans le chapitre 5 de cette

thèse.

6.4.1 Validation de la conception de la méthode de mesure

6.4.1.1 Définitions de l’objectif de mesure La nouvelle méthode de mesure proposée dans le chapitre 5 a pour but de quantifier la

complexité fonctionnelle du logiciel. Le cadre de la complexité est établi en se basant sur

le modèle de la complexité de la tâche de Wood. L’objectif final de la méthode de mesure

est de chercher un ensemble de mesures simples qui reflètent la complexité générale

du système qui se manifeste dans l’effort de développement ou de maintenance du

logiciel. De ce fait, les mesures doivent être cohérentes avec l’effort de développement ou

de maintenance. Une mesure simple ou une combinaison de mesures simples doit être

bien corrélée avec l’effort. Autrement dit, l’objectif de mesure est de chercher une valeur,

à partir de la fonctionnalité du logiciel, qui reflète la difficulté de la fonctionnalité du

logiciel qui se manifeste dans l’effort de développement. La mesure n’est pas une mesure

de l’effort, mais elle est un indicateur de l’effort.

6.4.1.2 Caractérisation de l’attribut de mesure et construction d’un méta modèle

Le modèle de la tâche de Wood (voir le chapitre 4) a montré les trois dimensions à

considérer pour décrire la complexité de la tâche: la complexité des éléments

d’information, la complexité de coordination entre les éléments d’information et les

produits et la coordination entre les actions ou les tâches élémentaires.

Le logiciel est analysé comme une tâche, et la complexité fonctionnelle est analysée

d’après la complexité de la tâche. Alors, la complexité fonctionnelle est caractérisée selon

trois dimensions qui correspondent à ce qui a été utilisé pour caractériser la complexité de

la tâche.


139

!" La complexité des données entrées et sorties, qui fait référence à la difficulté

des entrées et des sorties d’un processus fonctionnel. Elle est similaire à la

complexité des éléments d’information dans le modèle de Wood.

!" La complexité de la manipulation de données, qui fait référence aux relations

entre les entrées et les sorties d’un processus fonctionnel. Elle est similaire à la

complexité de coordination entre les éléments d’information et les produits de la

tâche dans le modèle de Wood.

Le nombre de conditions appliquées sur les entrées pour produire les sorties

désirées est proposé pour mesurer la complexité de la manipulation de données.

Cette mesure est essentiellement le nombre de cas différents à traiter dans le

processus fonctionnel. De plus, elle fournit un indice des branchements sur le

chemin de l’entrée à la sortie du processus fonctionnel. Elle est conforme au

nombre de points tournants (turning points) dans le modèle de Wood.

!" La complexité du système, qui fait référence à la complexité de relations de

données (data dependency) entre les processus fonctionnels. Elle correspond à la

coordination entre les actions élémentaires dans le modèle de Wood.

Généralement, nous utilisons le modèle de la complexité de la tâche de Wood comme un

guide théorique qui aide à caractériser la complexité du logiciel et à établir un cadre de la

complexité du logiciel. La description de la complexité fonctionnelle du logiciel n’est pas

proposée de façon subjective, mais elle est basée sur une théorie sous-jacente, la

complexité de la tâche. Nous mesurons la complexité du logiciel par la façon de mesurer

la complexité de la tâche en faisant l’adaptation des termes utilisés.

6.4.1.3 Définition des règles d’assignation numérique Les règles d’assignation numériques sont bien définies pour chaque caractéristique

mesurée. Dans le chapitre 5, ces règles sont bien précisées. Ici, nous approfondissons

l’analyse pour montrer que ces mesures capturent bien ce que nous voulons mesurer.

Le nombre de groupes de données (NOD) est identifié en se basant sur les mouvements

de données en entrée et en sortie du processus fonctionnel. Nous ne comptons que les

mouvements de données qui déplacent un élément nouveau d’information. Nous ne

comptons pas les mouvements de données qui font un déplacement d’un « ancien »

groupe de données car ce groupe ne fournit pas un élément nouveau d’information. De ce

fait, cette mesure est tout à fait conforme au nombre d’éléments d’information dans le


140

modèle de Wood. Elle est conforme aussi aux idées philosophiques présentées dans le

chapitre 1; la mesure de la complexité est basée le principe de l’information: plus il y a

d’informations à traiter est, plus complexe est le processus.

Quant au nombre de conditions (NOC), les règles de comptage sont aussi bien définies

dans le chapitre 5. L’espace des entrées est divisé en classes d’équivalence dont chacune

correspond à un type de sortie. Il y a une condition d’appartenance associée à chaque

classe. Le nombre de telles conditions est compté comme une mesure de la complexité. Si

une condition, c’est-à-dire une classe d’équivalence, ne correspond pas à une sortie, la

classe n’est pas manipulée dans le processus. Par conséquent, elle n’est pas comptée dans

le nombre de conditions. De ce fait, le nombre de classe indique exactement combien il y

a de cas différents à manipuler dans le processus fonctionnel. Ce nombre reflète le

nombre de chemins de l’entrée à la sortie du processus, donc il fait référence au même

attribut que la mesure de McCabe [118] utilisée pour quantifier complexité du module. La

mesure de McCabe est connue comme une mesure qui reflète bien la complexité

structurelle du module. Par similarité, le nombre de conditions (NOC) reflète aussi la

structure du processus fonctionnel. Elle est donc une mesure pertinente pour la

complexité de la structure des composants.

Quant à la mesure de l’entropie du système, la modélisation du système et la formule de

calcul sont bien définies dans le chapitre 5. Cette mesure fait référence à la régularité (ou

au désordre) dans la relation entre les processus fonctionnels. Elle est basée sur la théorie

de l’information et la mesure de l’entropie de Shannon [142]. Cette théorie estime que

l’entropie est une mesure du niveau d’organisation d’un système, c’est-à-dire du degré de

structuralité du système. En réalité, on peut observer que dans un système, si ses

composants ont des relations semblables, le système semble moins complexe qu’un

système dont les relations sont très variées.

La mesure d’entropie a été appliquée pour mesurer la structure du code du programme.

Selon des expérimentations de Davis et LeBlanc [54], l’entropie est une mesure

pertinente pour la structure du code source. Elle reflète bien la complexité parce qu’elle

se conforme à l’expérience de programmation: une structure séquentielle est moins

compliquée qu’une structure de branchement ou d’emboîtement. Ce résultat motive

l’application de la mesure d’entropie à un niveau plus abstrait du logiciel: le niveau de la

fonctionnalité du logiciel.


141

En résumé, les trois étapes de validation ci-haut décrites permettent de conclure que la

conception de la méthode de mesure de la complexité fonctionnelle proposée est correcte

et explicative. Les mesures proposées capturent ce qui est déclaré à mesurer. Elles sont

basées sur les théories sous-jacentes comme le modèle de la complexité de la tâche de

Wood et la théorie de l’information. Elles sont aussi conformes à des expériences de

McCabe et à celles de Davis et LeBlanc sur la complexité du logiciel. Ce sont les points

forts de cette méthode par rapport aux autres mesures de type points de fonction.

6.4.1.4 Validation de l’application de la méthode de mesure Ce type de validation se concentre sur l’application de la méthode de mesure pour assurer

que la méthode est appliquée correctement et que les résultats obtenus sont fiables. La

validation concerne le processus de collecte de données. La qualité des documents et des

données collectés sont des caractéristiques importantes parce qu’elles affectent

directement le résultat de l’application de la méthode de mesure. Ce résultat, par la suite,

est exploité dans les modèles de prédiction. Donc, la qualité du modèle de prédiction est

fortement dépendante non seulement de la méthode de mesure, mais aussi du processus

d’application de la méthode.

6.4.1.4.1 Collecte de données et la qualité des documents La collecte des données a été faite par une compagnie informatique de la région de

Montréal. Dans le cadre d’un projet de recherche entre le Laboratoire de Recherche en

Gestion des Logiciel (LRGL) de l’Université du Québec à Montréal (UQÀM) dirigé par

monsieur Lévesque et la compagnie, un ensemble de données sur 26 projets a été rendu

disponible pour fins de recherche. Cet ensemble de données n’est pas du domaine public,

alors le droit d’accès à celui-ci demeure limité. Seulement les membres du projet de

recherche et les étudiants ayant un droit d’accès peuvent le consulter. Un rapport de

recherche [151] sur ces projets a aussi été préparé au LRGL mais il n’est pas du domaine

public. Les résultats de ce rapport introduits ci-après dans cette thèse sont:

!" Le poids relatif de chaque type de travail de maintenance des logiciels dans

l’ensemble de données.

!" La qualité de la documentation représentée dans la figure 6.3.

!" La taille fonctionnelle des projets mesurée selon la méthode COSMIC-FFP – qui

est introduite dans la colonne CFFP du tableau 6.1.


142

Les vingt six projets de l’ensemble de données sont des projets de maintenance de

logiciel. Ces projets ont pour but d’entretenir les différentes applications (logiciels) d’une

compagnie du domaine des télécommunications. Les logiciels sont de deux types:

système d’informatique de gestion (MIS – Management Information System) et système

temps réel (real time system).

Les projets de maintenance étaient achevés au moment de la collecte des données, donc

l’effort réel pour réaliser un projet indiqué dans ces données est le nombre exact

d’homme-mois investis pour le projet. L’effort est ramassé à toutes les phases du

processus pour réaliser un projet. Ce travail a été fait sous la responsabilité d’un

gestionnaire de la compagnie. L’effort est le temps de travail de tous les membres dans

l’équipe de maintenance du logiciel tout au long du processus de maintenance, y compris

l’acquisition des besoins, l’analyse, la conception, le codage, le test, l’installation et les

tests d’acceptation. C’est-à-dire toutes les phases nécessaires pour développer un nouveau

logiciel ont été traitées.

Il faut noter que les projets analysés sont des projets de maintenance. Cependant, il y a de

nouvelles fonctions à développer pour fournir de nouvelles fonctionnalités à une

application en service. Le processus de maintenance est le même que le processus de

développement pour un nouveau logiciel. Les travaux principaux de la maintenance sont

le développement des nouvelles fonctions ou la mise à jour des fonctions spécifiées pour

obtenir les nouvelles fonctionnalités. Le rapport de recherche ci-haut [151] mentionné a

montré que plus de 50% des travaux de maintenance sur les projets analysés ont pour but

de développer de nouvelles fonctions, environ 30% des travaux concernent des mises à

jour des fonctions existantes et environ 10% des travaux sont relatifs la suppression

d’anciennes fonctions.

Les spécifications des travaux de maintenance pour chaque projet ont aussi été collectées.

Les spécifications, l’effort réel et le coût réel de chaque projet sont des données

importantes recueillies par la compagnie d’informatique. Cette collecte de données a été

utilisée par un groupe de recherche qui a fait des comptages de la taille fonctionnelle du

logiciel en utilisant COSMIC-FFP. Ce groupe a produit un rapport statistique (figure 6.3)

dans [151] sur la qualité de la documentation, c’est-à-dire le niveau de détails des

documents, pour calculer la taille avec COSMIC-FFP.


143

La qualité de la documentation

documentation complète

34%

incomplète56%

manque de documentation

2%

implicite8%

Figure 6.3: Qualité de la documentation pour identifier

les concepts de mesure de COSMIC [151].

Selon ce rapport, il y a 34% de processus fonctionnels qui sont bien documentés, 56% des

processus sont listés mais ne sont pas documentés de façon assez détaillée, 2% des

processus ne sont pas documentés du tout et 8% des processus sont implicites (sont

déduits par les mesureurs). Alors, environ 80% des processus fonctionnels sont identifiés

directement en se basant sur les spécifications du projet du logiciel. Nous pensons que ce

taux est acceptable pour dire que la qualité de l’ensemble de données est adéquate pour

faire des investigations expérimentales.

6.4.1.4.2 Application de la méthode de mesure En utilisant la taille fonctionnelle des logiciels de cet ensemble de données, nous avons

réalisé des recherches plus poussées pour établir des modèles de prédiction de l’effort et

du coût (voir [165]) à partir des points de fonction de COSMIC-FFP (c-à-d, la taille

fonctionnelle du logiciel mesurée en utilisant COSMIC-FFP). Ces modèles de prédiction

de l’effort et du coût sont bien établis et bien analysés quant à leurs performances de

prédiction. Le taux d’erreurs moyen de prédiction de ce modèle est environ 40%. Bien

que ce taux soit meilleur que la performance de certaines autres prédictions de FPA (voir

[165] pour plus de détails), ce taux est encore trop grand que dans la pratique. Ce

problème a conduit à proposer des changements dans la structure de la mesure de

COSMIC pour tenir compte davantage de la complexité. La taille du logiciel (mesurée

par COSMIC-FFP) semble ne pas bien refléter les aspects qui affectent l’effort de

développement ou de maintenance du logiciel. Cela a motivé cette thèse. Le projet a

démarré d’un problème théorique au départ, le modèle de COSMIC-FFP laissant de côté

les manipulations de données. Les résultats obtenus dans [165] montrent l’intérêt de

chercher à mieux caractériser et mesurer la complexité. En fait, nous voulons établir des


144

mesures qui témoignent de la complexité fonctionnelle du logiciel pour bien caractériser

l’effort de développement du logiciel. Nous voulons construire une nouvelle méthode de

mesure qui se concentre beaucoup plus sur la complexité, pas seulement sur la taille du

logiciel. La méthode de mesure de la complexité présentée dans le chapitre 5 assure une

meilleure couverture des aspects de la complexité que ne le fait la méthode COSMIC-

FFP.

L’ensemble de données mentionné plus haut est utilisé pour vérifier notre nouvelle

méthode. Le comptage de la complexité de chaque projet a été réalisé manuellement par

nous-même et discuté dans le groupe de recherche. Le processus de comptage respecte

bien les règles de comptage de la méthode. Le résultat du comptage a été révisé

soigneusement par notre directeur de recherche. Le comptage est présenté à l’annexe 2 et

il peut-être suivi pas à pas à partir des spécifications de chaque projets faisant partie de

l’ensemble de données.

6.4.1.4.3 Validation du système de prédiction Ce type de validation concerne l’exploitation des résultats de mesures pour estimer les

caractéristiques du projet du logiciel. L’effort, le coût, la qualité du logiciel sont les

caractéristiques les plus pertinentes et les plus importantes du logiciel. Une mesure du

logiciel est considérée utile si et seulement si elle peut aider à évaluer (objectivement ou

subjectivement) des indices relatifs à ces caractéristiques. L’investigation expérimentale

présentée dans la section qui suit va montrer la pertinence et la performance de nos

mesures.

6.4.2 Expérimentation sur les mesures de la complexité fonctionnelle proposées

Dans cette section, nous présentons de façon détaillée l’ensemble de données. Cet

ensemble est à la base de l’analyse statistique pour montrer la pertinence de nos mesures.

À partir de l’analyse de régressions multiples, des modèles différents de prédiction sont

établis, analysés et comparés. Ces modèles ne sont pas l’objectif de cette thèse, ils sont

établis pour montrer que les mesures de la complexité sont adéquates et significatives.

C’est-à-dire qu’elles sont bien corrélées avec l’effort et qu’elles fournissent des bons

indices pour estimer l’effort.


145

6.4.2.1 Ensemble des données Le processus de collecte des données a été présenté dans la validation de l’application de

la mesure plus haut. Vingt six projets de maintenance du logiciel nous sont disponibles.

Voici les observations faites sur la collecte des projets:

!" Pour un projet, les travaux de maintenance ont pour but de retirer complètement

une application. Ce projet est éliminé parce qu’il ne correspond pas avec le but de

recherche.

15 projets ayant un effort inférieur de 24 homme-mois

05

10152025

Figure 6.4a: 15 projets ayant un effort inférieur de 24 homme-mois.

10 projets ayant un effort suppérieur à 24 homme-mois

0100200300400500

Figure 6.4b: 10 projets ayant un effort supérieur à 24 homme-mois.

!" Les 25 autres sont divisés en deux groupes:

o Un groupe qui contient 15 projets dont l’effort de maintenance est 24

homme-mois et moins. L’effort moyen sur ce groupe est 8,8 homme-

mois et la médiane est 7,8 (voir la figure 6.4a).

o Un groupe qui contient 10 projets dont l’effort de maintenance est 24

homme-mois ou plus. L’effort moyen sur ce groupe est 86,3 homme-


146

mois et la médiane est 54 (voir la figure 6.4b). Il y a un projet avec un

effort extrême (436,3 homme-mois). Si ce projet est éliminé, l’effort

moyen et la médiane sur les neuf projets qui restent sont 47,4 et 53,7

respectivement.

Figure 6.5 : Deux groupes des projets séparés.

Parce que l’écart entre l’effort moyen (ou la médiane de l’effort) des deux groupes est très

large, nous supposons que l’ensemble de données est naturellement divisé en deux

groupes qui correspondent à deux niveaux de difficulté différente (voir la figure 6.5) . Le

premier contient 15 projets plus simples avec un effort inférieur à 24 homme-mois. Le

deuxième contient 9 projets (sans compter le projet avec un effort extrême) beaucoup plus

complexes avec un effort supérieur à 24 homme-mois. Le premier groupe est retenu pour

nos analyses. Le deuxième groupe contenant 9 projets semble trop limité pour répondre à

nos besoins.

Le tableau 6.1 représente l’ensemble de données de 15 projets considérés dans cette

investigation empirique.

Dans ce tableau, les logiciels de ces 15 projets sont de même type. Ce sont des systèmes

d’informatique de gestion (MIS). Les données recueillies sont:

!" Effort représente l’effort réel. Il est fourni par la gestionnaire de projet qui réalise

le projet de maintenance.

!" CFFP représente la taille du logiciel en termes de point de fonction de COSMIC.

Le comptage est réalisé par une étudiante de maîtrise en utilisant la version

« test » (trial version) de COSMIC [1]. Le comptage de cette étudiante a été


147

révisé par un expert qui a travaillé plus de cinq ans avec les mesures de points de

fonction comme FPA, FFP et COSMIC-FFP.

Les données dans la colonne CFFP du tableau 6.1 sont extraites du document

déjà cité [151]. Elles sont introduites uniquement pour fins de comparaison et

pour montrer que NOD et CFFP ne sont pas identiques. Cependant, ces

comparaisons n’ont rien à voir avec la validation de notre méthode.

!" NOD, NOC et EOS représentent les trois mesures de la complexité du logiciel

proposées dans cette thèse. Elles sont comptées pour toutes les nouvelles

fonctions à développer et pour toutes les fonctions à mettre à jour. Les fonctions

supprimées du système ne sont pas comptées. Les résultats dans ces trois

colonnes ont été comptés par nous et vérifiés par notre directeur de recherche en

utilisant la méthode et les règles de mesure présentées dans le chapitre 5.

# Effort (homme-mois) CFFP NOD NOC EOS3

1 1,6 47 18 3 0 2 1,79 40 12 4 0 3 2,56 24 24 0 ** 4 2,72 98 23 3 0 5 6,3 23 39 12 0,67 6 6,45 48 31 17 ** 7 7,15 248 51 0 ** 8 7,8 116 60 10 ** 9 7,84 24 36 6 0,44 10 9,3 34 10 74 ** 11 9,5 70 54 26 0,48 12 12,6 129 106 0 ** 13 14,4 93 116 8 ** 14 20,7 272 71 41 0,68 15 21,7 148 119 24 0 Tableau 6.1: Ensemble de données utilisées dans l’expérimentation.

Les spécifications des projets logiciels sont assez détaillées pour identifier et compter

NOD et NOC. Cependant, il y a huit projets dont les spécifications ne sont pas assez

détaillées pour déterminer les relations entre les processus fonctionnels, donc l’entropie

du système ne peut pas être comptée. En fait, ces projets réalisent des travaux sur des

fonctions différentes dans le système mais l'architecture générale de ces systèmes n'est

pas disponible. L’entropie du système de ces projets est indiquée par deux étoiles dans la 3 Les projets dont les spécifications sont incomplètes et qui ne permettent pas de calculer EOS sont marqués par deux étoiles.


148

colonne EOS. De plus, pour certains projets, les travaux de maintenance sont réalisés sur

des fonctions situées dans des parties différentes du logiciel, mais nous ne voyons pas de

relations directes entre les processus, alors l’entropie du système est 0.

6.4.2.2 But de l’expérimentation L’expérimentation a pour but de vérifier si les mesures NOD, NOC et EOS sont

pertinences pour mesurer la complexité fonctionnelle du logiciel. Par sa conception, la

complexité fonctionnelle du logiciel fait référence à l’effort de développement ou de

maintenance du logiciel. Une mesure de la complexité fonctionnelle est un indicateur de

l’effort. De ce fait, nous considérons qu’une mesure est adéquate pour la complexité

fonctionnelle si elle est bien corrélée avec l’effort ou si elle est associée avec d’autres

mesures ayant obtenues une bonne corrélation avec l’effort. C’est-à-dire qu’elle doit être

un indicateur complet ou partiel de l’effort.

Par la suite, les mesures de la complexité sont utilisées pour estimer l’effort de

développement/maintenance du logiciel. Le modèle est établi en se basant sur les projets

de maintenance du logiciel. Cependant, seulement les nouvelles fonctions à développer

et les fonctions à mettre à jour pour fournir les nouvelles fonctionnalités qui répondent

aux nouvelles exigences de l’utilisateur sont considérées. Alors le résultat établi sur les

projets de maintenance pourrait aussi être appliqué à un nouveau projet de

développement. Autrement dit, nous espérons que le modèle d’estimation d’effort établi

dans cette expérimentation pourra être utilisé pour estimer l’effort de développement des

nouveaux projets.

6.4.2.3 Méthodes statistiques utilisées Tout d’abord, les techniques de l’analyse de corrélation sont utilisées pour tester la

corrélation entre les mesures de la complexité et l’effort réel. La corrélation linéaire et la

régression multiple sont deux techniques adéquates pour ce type d’analyse. Nous testons

aussi la signification de la corrélation par le test d’hypothèse nulle avec un degré de 95%.

Deux mesures pour évaluer la corrélation (linéaire ou multiple) sont le coefficient de

corrélation (R2) et la possibilité de l’hypothèse nulle.

La régression univariée est un cas spécifique de la régression multiple. En général, la

régression multiple est une technique pour chercher une relation linéaire entre une

variable Y avec un ensemble de variables {X1,…,Xn}. Y est appelé la variable


149

dépendante et X1,…,Xn sont les variables indépendantes. La relation entre Y et X1,…, Xn

prend la forme:

Y=01X1 + … + 0nXn + 00. (1)

Si n=1, on a une régression linéaire entre deux variables.

Le coefficient de corrélation (R2) est une valeur comprise de 0 à 1 qui représente le degré

de la relation entre Y et X1,…,Xn. Plus la valeur de R2 est grande, plus la corrélation est

élevée. Par exemple, la valeur R2 =0,80 confirme que dans 80% des cas, il y a une

relation entre la variable dépendante Y et les variables indépendantes X1,…, Xn. Le test

de l’hypothèse nulle est nécessaire pour confirmer la signification de la corrélation.

Dans la pratique, si le coefficient de corrélation est grand (à partir de 0,75), la formule de

régression (1) est souvent considérée comme une estimation d’Y. Cependant, une grande

valeur de R2 confirme seulement que la régression est significative; elle n’assure pas que

l’estimation est exacte. L’analyse de l’exactitude de l’estimation en utilisant MRE,

MMRE et PRED est donc nécessaire. Dans notre recherche, nous utilisons les trois

mesures MRE, MMRE et PRED pour analyser la qualité d’un modèle de prédiction de


6.4.2.4 Résultats de l’expérimentation

Corrélation Taille d’échantillon

Coefficient de Corrélation (R2)

Probabilité d’hypothèse nulle (p-value)

Effort vs. CFFP 15 36% 0,0189 Effort vs. NOD 15 65% 0,0003 Effort vs. NOC 15 18% 0,1183 Effort vs. EOS 8 11% 0,4253 Effort vs. CFFP, NOC 15 51% 0,0147 Effort vs. NOD, NOC 15 89% <0,0001 Effort vs. NOD, NOC, EOS 8 95% 0,0041 Effort vs. CFFP, NOD, NOC 15 92% <0,0001 Tableau 6.2: Corrélation linéaire (multiple) entre l’effort et les mesures considérées.

Le tableau 6.2 présente les résultats de l’analyse de régression entre l’effort réel et les

mesures du logiciel, y compris, la taille fonctionnelle du logiciel (c-à-d, CFFP) et la

complexité fonctionnelle du logiciel (c-à-d, NOD, NOC et EOS).

Les analyses de régression linéaire qui concernent la mesure EOS sont basées sur 8

projets pour lesquels EOS est déterminée. Les autres régressions linéaires sont établies en


150

se basant sur les données des 15 projets du tableau 6.1. Les résultats de l’analyse des

corrélations dans le tableau 6.2 montrent que:

!" L’effort réel est corrélé très faiblement avec les mesures CFPP, NOD, NOC,

EOS. Aucune mesure simple parmi elles ne peut être utilisée toute seule comme

un indicateur de l’effort réel.

!" La combinaison entre CFFP – une mesure qui fait référence à la taille du

logiciel – et NOC – une mesure qui fait référence à la complexité structurelle du

logiciel – n’est pas une bonne combinaison pour indiquer l’effort de


!" Les trois dernières lignes du tableau 6.2 montrent que:

o L’effort est bien corrélé avec NOD et NOC. Le coefficient de cette

régression multiple est 89%. Le test d’hypothèse nulle confirme que cette

relation est significative (p-value<0,0001).

o L’effort est bien corrélé avec NOD et NOC, EOS. Le coefficient de la

régression multiple entre l’effort et ces trois mesures est très élevé

(R2=95%). La probabilité de l’hypothèse nulle est 0,0041, donc la

corrélation est significative.

o L’effort est bien aussi corrélé avec CFFP, NOD et NOC (R2 = 92%). Le

test d’hypothèse nulle confirme que cette relation est significative.

Cependant, à partir de la conception de la méthode de mesure (dans le

chapitre 5), NOD est une modification de CFFP. Ces deux mesures sont

associées à la complexité des entrées et des sorties du processus

fonctionnel. Alors, est-ce que CFFP est vraiment significatif dans cette

régression? Pour répondre à cette question, quelques analyses plus

poussées sur cette régression sont nécessaires.

Le tableau 6.3 illustre le coefficient de chaque variable dans la formule de régression

multiple entre l’effort et NOD et NOC. Le tableau 6.4 vise le même but, mais pour la

régression multiple entre l’effort et CFFP, NOD et NOC.


151

Terme Coefficient

Probabilité d’hypothèse nulle(p-value)

Constante d’intersection -0,9397 0,4190 NOD 0,1446 <0,0001 NOC 0,1542 0,0002

Tableau 6.3: Influence de chaque variable dans la régression multiple entre l’effort et NOD et NOC.

Terme Coefficient


Constante d’intersection -1,4666 0,1812 CFFP 0,0159 0,0631 NOD 0,1276 <0,0001 NOC 0,1479 0,0002

Tableau 6.4: Influence de chaque variable dans la régression multiple entre l’effort et CFFP, NOD et NOC.

Les valeurs dans la colonne Coefficient du tableau 6.3 permettent d’établir la formule de

régression suivante:

EFFORT = 0,14*NOD + 0,15*NOC -0,94 (2)

De plus, l’impact de NOD et NOC est significatif parce que la probabilité de l’hypothèse

nulle (p-value) est presque 0.

Le tableau 6.4 montre qu’en présence de NOD et NOC, CFFP n’affecte pas de façon

significative l’effort. La probabilité de l’hypothèse nulle est 0,06 (c-à-d, 6%). Cette

probabilité n’est pas très grande mais elle confirme l’hypothèse nulle. Donc CFFP n’est

pas nécessaire dans cette régression. Autrement dit, la régression de l’effort avec trois

variables CFFP, NOD et NOC pourrait être simplifiée à une régression multiple entre

l’effort et NOD et NOC.

La colonne Coefficient dans le tableau 6.4 permet d’établir la formule de régression entre

l’effort et CFFP, NOD et NOC comme la suivante:

EFFORT = 0,016*CFFP + 0,13*NOD + 0,15*NOC -1,5 (3)

L’analyse de la performance de prédiction de deux modèles (2) et (3) dans le tableau 6.5

confirme aussi que CFFP n’est pas nécessaire dans la régression (3). Les modèles (2) et


152

(3) ont la même capacité d’estimation. Les représentations graphiques de deux modèles

(2) et (3) sont illustrées dans la figure 6.6 et 6.7, respectivement.

Modèle pred(0,25) pred(0,35) pred(0,50) R2 MMRE (2) sans CFFP 73% 93% 100% 88% 15% (3) avec CFFP 66% 93% 100% 92% 20%

Tableau 6.5: Comparaison de la performance des modèles (2) et (3).

MRE de l'estimation utilisant NOD et NOC

73%

20%

7%

0%0<=MRE<=25%

25%<MRE<=35%

35%<MRE<=50%

MRE>50%

Figure 6.6: Analyse de performance du modèle de prédiction de l’effort utilisant NOD et NOC.

Figure 6.7: Analyse de performance du modèle de prédiction

d’effort utilisant CFFP, NOD et NOC.

!" Si on utilise le modèle (2) pour estimer l’effort de développement, la qualité de la

prédiction est très élevée. En fait, 73% des cas d’estimation ont un taux d’erreurs

de moins de 25% (PRED(0,25) = 73%) et 93% des cas d’estimation sont dans la

marge d’erreur de 35% (PRED(0,35) = 93%). Le taux d’erreurs moyen est 15%.

MRE de l'estimation utilisantFFP, NOD and NOC

66%

27%

7%0%

0<=MRE<=25%

25%<MRE<=35%

35%<MRE<=50%

MRE>50%


153

!" La performance du modèle (3) est un peu plus faible que celle du modèle (2). Il y

a seulement 66% des cas qui ont une marge d’erreur de 25%, et 93% des cas qui

ont une marge d’erreur de 35%. Le taux d’erreurs moyen de ce modèle est 20%.

Ainsi, l’intégration de CFFP à NOD et NOC ne résulte pas en une meilleure estimation.

Le modèle (2), sans CFFP, est mieux que le modèle (3) avec CFFP. La régression

multiple (3) doit être réduite à la régression multiple (2).

De plus, la première ligne du tableau 6.5 montre que la combinaison de NOD et NOC

dans la formule (2) donne un très bon indice de l’effort de développement du logiciel. Le

taux d’erreurs de l’estimation du modèle (2) atteint le seuil proposé par Conte [49]

(PRED(0,25)>=75%) Par leur conception, NOD et NOC sont donc deux mesures

adéquates pour la complexité fonctionnelle du logiciel.

Terme Coefficient


Constante d’intersection -1,4307 0,4217 NOD 0,1515 0,0203 NOC 0,2146 0,1524 EOS 0,7511 0,8524

Tableau 6.6: Influence de chaque variable dans la régression multiple entre l’effort et NOD, NOC et EOS.

Les analyses ci-haut ne mentionnent pas encore la troisième mesure de la complexité,

l’entropie du système (EOS). La taille de l’échantillon de cette mesure est huit. Elle ne

facilite pas les analyses statistiques. Le tableau 6.6 présente l’analyse de l’influence de

chaque variable dans la régression multiple entre l’effort et NOD, NOC et EOS.

Cependant, à cause du nombre limité de données dans l’échantillon, le test d’hypothèse

nulle manifeste une probabilité très élevée pour NOC et EOS. Nous ne voulons donc pas

tirer de conclusion en nous basant sur la statistique présentée dans le tableau 6.6. Pour

tirer des conclusions, nous aurons besoin de plus de données d’expérimentation. Ici, nous

introduisons quelques observations découlant de cette mesure, observations qui pourront

s’avérer utiles pour les travaux futurs.

!" Tout d’abord, la corrélation entre l’effort et NOD, NOC et EOS est très élevée

(R2=95%).

!" La formule de régression multiple entre l’effort et ces mesures est:

EFFORT = 0,15*NOD + 0,21*NOC + 0,75*EOS - 1,4 (4)


154

La performance de ce modèle est présentée dans le tableau 6.7 et dans la figure 6.8. Une

comparaison de ce modèle avec le modèle (2) y est aussi faite.

Modèle Pred(0,25) Pred(0,35) Pred(0,50) R2 MMRE (2) avec NOD et NOC 73% 93% 100% 88% 15% (4) avec NOD, NOC et EOS 62% 100% 100% 95% 18%

Tableau 6.7: Comparaison de la performance des modèles (2) et (4).

MRE de l'estimation utilisant NOD, NOC et EOS

62%

38%

0%

0%

0<=MRE<=25%25%<MRE<=35%35%<MRE<=50%MRE>50%

Figure 6.8: Analyse de performance du modèle de prédiction

d’effort utilisant NOD, NOC et EOS.

La comparaison dans le tableau 6.7 montre que la capacité d’estimation des modèles (2)

et (4) n’est pas différente de façon remarquable. Cependant, pour le modèle (4) avec

EOS, dans 100% des cas, l’effort peut être estimé avec une marge d’erreur de 35%

(PRED(0,35)=100%). Si cette tendance est retenue, l’utilisation de la mesure EOS avec

NOD et NOC pourrait donner une estimation stable, c’est-à-dire que le taux d’erreurs

n’est pas trop élevé pour tous les cas. Il serait donc intéressant d’approfondir les

recherches sur cette mesure.

6.4.2.5 Validation croisée Les analyses dans le tableau 6.7 montre non seulement la cohérence entre NOD, NOC et

EOS avec l’effort de développement du logiciel, mais aussi la qualité de prédiction

d’effort de ces mesures. Elles incitent à considérer que le couple NOD et NOC et le triplet

NOD, NOC et EOS sont candidats pour des modèles de prédiction de haut précision.

Cependant, compte tenu de la taille limitée de l’échantillon, nous utilisons les tests

croisés (c-à-d, tester un élément avec les éléments qui restent dans l’échantillon) pour

analyser en profondeur la capacité de prédiction d’effort du couple NOD et NOC, et celle

du triplet NOD, NOC et EOS.


155

Les tests croisés ne visent pas à établir les modèles de prédiction comme on peut faire

avec l’analyse de régression dans la section précédente. Ces tests servent plutôt à savoir

qu’est-ce qui se passe si l’on élimine un ou quelques éléments dans l’échantillon utilisée

pour construire le modèle de prédiction. Les éléments exclus sont utilisés pour vérifier la

qualité du modèle formulé en se basant sur les éléments retenus.

La validation croisée est souvent connue comme un algorithme d’apprentissage supervisé

[160]. Cependant, l’idée de cet algorithme peut être appliquée pour analyser le taux

d’erreurs des estimations ou le taux d’erreurs des modèles de prédiction. Dans cette

section, nous employons le terme « validation croisée » simplement pour indiquer que

nous utilisons les tests croisés pour tester la capacité de prédiction d’effort des mesures

proposées dans le cas où un projet est éliminé de l’échantillon (tableau 6.1). Les tests

dans cette section sont de type leave-one-out [38,140,160]. On recommande d’appliquer

cette technique à un échantillon de petite taille [160]. Elle peut être décrite de la façon

suivante:

Supposons que l’on a un échantillon (ou une base de données) qui contient n éléments.

Par exemple, dans notre ensemble de données, l’échantillon contient 15 éléments (15

projets de logiciel) pour le couple NOD et NOC et 8 éléments pour le triplet NOD, NOC

et EOS. Notons les éléments par X1, X2,…, Xn. La validation croisée de type leave-one-

out est un processus itératif de n fois pour lequel chaque itération est un test croisé entre

Xi et les autres projets dans l’échantillon. Au ième test, on utilise Xi comme l’exemple pour

tester le modèle de prédiction d’effort établi en se basant sur les (n-1) projets qui restent

et on calcule le taux d’erreurs de ce test.

Supposons que:

Fi est le modèle établi au ième test (en se basant sur les projets dans la base de données sauf

Xi).

Fi(Xi) est l’effort estimé pour le projet Xi avec le modèle Fi.

Ei est l’effort réel pour réaliser le projet Xi.

Donc, l’amplitude d’erreur relative (MRE) d’ième test est:

iMRE =i

iii

EE)(XF ,

Puis le taux d’erreurs relatives moyen (MMRE) de tous les tests croisés est:


156

MMRE = (&

n

n 1iiMRE1

Pour analyser la capacité d’estimation d’effort, la mesure de qualité de prédiction (PRED)

est utilisée:

PRED(x)= n1

(le nombre de tests ayant MRE - x)

Test Projet de test Effort réel Effort estimé MRE 1 #1 1,60 2,16 35% 2 #2 1,79 1,44 20% 3 #3 2,56 2,42 5% 4 #4 2,72 2,76 1% 5 #5 6,30 6,35 0% 6 #6 6,45 5,91 8% 7 #7 7,15 6,14 14% 8 #8 7,80 9,65 24% 9 #9 7,84 5,06 35% 10 #10 9,30 19,59 111% 11 #11 9,50 10,82 14% 12 #12 12,60 14,9 18% 13 #13 14,40 18,46 28% 14 #14 20,70 14,38 31% 15 #15 21,70 19,72 9%

Taux d’erreurs relatives moyen (MMRE) 24%

Tableau 6.8: Amplitude d’erreur relative des tests croisés sur 15 couples NOD et NOC.

Test Projet de test Effort réel Effort estimé MRE 1 #1 1,60 2,12 33% 2 #2 1,79 0,92 49% 3 #4 2,72 2,64 3% 4 #5 6,30 8,96 42% 5 #9 7,84 3,92 50% 6 #11 9,50 13,76 45% 7 #14 20,70 12,17 41% 8 #15 21,70 23,84 10%

Taux d’erreurs relatives moyen (MMRE) 34%

Tableau 6.9: Amplitude d’erreur relative des tests croisés sur 8 triplets NOD, NOC et EOS.


157

Le tableau 6.8 représente le résultat des tests croisés sur les 15 couples NOD et NOC

listés dans le tableau 6.1, tandis que le tableau 6.9 représente le résultat des tests croisés

sur les 8 triplets NOD, NOC, EOS présentées dans le tableau 6.1.

Capacité de prédiction d'effort de NOD et NOC

67%

26%

0%

7%

0%<=MRE<=25%

25%<MRE<=35%

35%<MRE<=50%

MRE>50%

Figure 6.9: Résumé (graphique) sur la capacité de prédiction d’effort de NOD et NOC.

À partir des résultats obtenus dans les tableaux 6.8 et 6.9, on peut calculer la capacité

d’estimation d’effort (PRED) du couple NOD et NOC ainsi que du triplet NOD, NOC et

EOS. Les calculs sont résumés dans le tableau 6.10. Les résultats à la première ligne du

tableau montre que: NOD et NOC sont deux mesures efficaces pour estimer l’effort car le

taux de prédiction avec une marge d’erreur de 25% est assez élevé, se situant à 67%

(PRED(0,25) = 67%). De plus, le taux d’erreurs relatives moyen est bas, se situant à 24%

(MMRE=24%). Ces indices sont assez comparables à ceux obtenus dans l’analyse de

régression multiple présentée dans le tableau 6.7: PRED(0,25) = 73% et MMRE = 15%.

De plus, NOD et NOC semblent ne pas être sensibles à l’élimination d’éléments de

l’échantillon. Sauf le cas extrême du projet #10, les tests croisés sur les autres projets

donnent des amplitudes d’erreurs relatives plutôt basses, de moins de 35%. Si on ne

compte pas le cas extrême (projet #10), le taux d’erreurs relatives moyen est encore plus

bas, soit de 17% au lieu de 24%.

Variables PRED(0,25) PRED(0,35) PRED(0,50) PRED(50+) MMRE NOD et NOC 67% 93% 93% 100% 24%

NOD, NOC et EOS 25% 38% 100% 100% 34% Tableau 6.10: Résumé sur la capacité de prédiction d’effort.


158

Capacité de prédiction d'effort de NOD, NOC et EOS

25%

13%62%

0%<=MRE<=25%

25%<MRE<=35%

35%<MRE<=50%

Figure 6.10: Résumé (graphique) sur la capacité de prédiction d’effort de

NOD, NOC et EOS.

Quant au triplet NOD, NOC et EOS, la capacité de prédiction d’effort analysée avec la

validation croisée est beaucoup moins bonne que celle obtenue par l’analyse de

régression multiple. Le résumé sur la capacité de prédiction d’effort du triplet est présenté

dans la deuxième ligne du tableau 6.10 et encore une fois par le graphique de la

figure 6.10. Ces résumés illustrent qu’il semble que le triplet NOD, NOC et EOS est trop

sensible à l’élimination d’éléments de l’échantillon. La qualité du modèle de prédiction

obtenu par régression multiple entre Effort et NOD, NOC et EOS est de très bonne

qualité: PRED(0,25%) = 62% et MMRE = 18% (voir le tableau 6.7). Cependant, la

qualité de prédiction d’effort est diminuée de façon sensible avec les tests croisés:

PRED(0,25)=25% et MMRE=34%. Il semble que l’ajoute d’EOS (dans 8 projets

seulement) réduit sensiblement la capacité de prédiction par rapport au couple NOD et

NOC. Cependant, compte tenu que la taille d’échantillon est limitée à 8 projets, il est

difficile de tirer une conclusion définitive sur cette base. Nous proposons donc de

poursuivre les travaux en vue de la validation sur des échantillons de plus grande taille

pour des logiciels ayant beaucoup de relations entre les composants.

6.4.2.6 Conclusion de l’expérimentation Le résultat de l’analyse de régression multiple entre l’Effort et NOD, NOC et EOS (c-à-d,

les modèles (2) et (4) de section précédente) montre que la combinaison de NOD et NOC

est en bonne corrélation avec l’effort pour le développement du logiciel. Ces deux

mesures sont donc adéquates pour quantifier la complexité fonctionnelle du logiciel. Les

tests croisés dans la section précédents confirment fortement cette conclusion.


159

La combinaison de NOD, NOC et EOS est aussi en bonne corrélation avec l’Effort réel.

Donc, EOS est aussi une mesure adéquate. L’analyse a aussi montré que la mesure de

l’entropie du système (EOS) pourrait être utilisée en supplément pour obtenir une

estimation de l’effort plus stable. Cependant, les tests croisés ne confirment pas cette

conclusion. Compte tenu de la taille limitée de l’échantillon de test, nous proposons de

poursuivre les recherches sur cette mesure.

Ces résultats empiriques supportent le cadre de la complexité établi dans le chapitre 5. La

complexité du logiciel peut être caractérisée par la complexité des données entrées et

sorties, la complexité des manipulations de données et la complexité du système. Ces

trois aspects ont été analysés dans le chapitre 5 comme des aspects « nécessaires » pour

mesurer la complexité du logiciel. Les résultats empiriques dans ce chapitre montrent

qu’ils sont « suffisants » pour indiquer la complexité du logiciel qui se manifeste dans


Le but de l’expérimentation était de montrer que notre modèle de la complexité

fonctionnelle et les mesures proposées qui sont établies théoriquement en se basant sur un

modèle de la complexité de la tâche sont validés sur un ensemble des projets réels. Le

modèle de la complexité du logiciel a été bien construit et testé empiriquement. Il satisfait

le but de recherche de la thèse: chercher une théorie sous-jacente pour mesurer la

complexité du logiciel. La complexité de la tâche de Wood a bien répondu à ce but. Elle

aide à définir un cadre conceptuel de la complexité fonctionnelle du logiciel ainsi que des

mesures de celle-ci.

6.5 RÉSUMÉ

Dans ce chapitre, le cadre de la complexité fonctionnelle du logiciel et les mesures

associées à ce cadre ont été validés en se basant sur le prototype de la validation proposé

par Jacquet. La validation est réalisée en suivant le processus de développement d’une

méthode de mesure, y compris la conception de la méthode, l’application de la méthode

et l’exploitation des résultats obtenus pour estimer l’effort de développement du logiciel.

Ce chapitre a montré que notre méthode de mesure est bien conforme au cadre de

développement d’une méthode de mesure.

L’investigation empirique avait pour but de montrer que le modèle de la complexité

fonctionnelle du logiciel qui est construit en se basant sur le modèle de la complexité de

la tâche de Wood est adéquat, c’est-à-dire qu’il capture bien des aspects importants de la


160

complexité du logiciel. De plus, les mesures qui sont inspirées des mesures de la

complexité de la tâche sont adéquates pour quantifier la complexité fonctionnelle du

logiciel. Elles reflètent bien la complexité qui se manifeste dans l’effort de

développement.

Établir un modèle d’estimation de l’effort de développement du logiciel n’est pas le but

principal de l’investigation empirique. Cependant, pour analyser la pertinence des

mesures, certains modèles d’estimation sont construits et analysés. L’analyse de

l’exactitude de ces modèles a montré que la mesure proposée dans cette thèse est très

efficace dans l’estimation d’effort. En fait, le taux d’erreurs moyen de 15%

(MMRE=15%) et la qualité de prédiction de 73% (PRED(0,25)=0,73) sont beaucoup

mieux que le taux d’erreurs et la qualité de certaines méthodes de points de fonction

publiées par d’autres chercheurs (voir la chapitre 3). L’exactitude de l’estimation utilisant

la nouvelle méthode de mesure est très proche du seuil exigé dans la pratique. Autrement

dit, la nouvelle méthode proposée dans cette thèse est tout à fait prometteuse pour une

application dans la pratique.

CONCLUSION Au cours des six chapitres précédents, la complexité et la mesure de la complexité du

logiciel ont été analysées selon différents points de vue. La complexité du logiciel est un

terme commun qui est utilisé pour indiquer la difficulté de calcul ou l’effort humain

requis pour travailler sur le logiciel. Au point de vue computationnel, ce terme fait

référence à la difficulté de computation du logiciel. La complexité du logiciel est

interprétée comme l’effort de la machine pour réaliser les calculs. Elle est mesurée par

des mesures qui sont associées au temps de calcul ou à l’espace mémoire requis pour

réaliser un algorithme du programme. Dans ce sens, la complexité est catégorisée comme

étant la complexité computationnelle du logiciel. La mesure avec la notion grand « O »

est une mesure typique de cette catégorie. Une mesure computationnelle d’un algorithme

ne reflète ni l’effort humain à implémenter cet algorithme, ni l’effort de la compréhension

du code.

En génie logiciel, et surtout, en gestion des logiciels, on s’intéresse à la complexité

cognitive, c’est-à-dire, à la difficulté rencontrée par l’individu qui travaille sur le logiciel.

Cette difficulté est souvent interprétée par l’effort humain requis pour réaliser une tâche.

Elle est mesurée via le temps pour réaliser la tâche ou le nombre d’erreurs faites pendant

la réalisation de la tâche. Ce type de complexité est donc associé aux caractéristiques du

problème, de la conception, de la structure du code et à la longueur de code source. Les

mesures de la complexité cognitive ne reflètent pas l’effort de calcul de la machine mais

l’effort de l’équipe de développement (c-à-d, le nombre d’hommes-mois) pour réaliser le

projet de logiciel.

D’un point de vue pratique, le problème important est de chercher des mesures qui aident

à comprendre les caractéristiques et l’état futur du produit logiciel. Les mesures du

logiciel, quelles soient computationnelles ou cognitives, doivent fournir des résultats qui

facilitent l’analyse du logiciel, du processus de production, et qui facilitent la prise de

Conclusion

162

décision. Une mesure comme grand « O » est un bon outil pour choisir un algorithme

approprié à implémenter. Par contre, une mesure qui aide à estimer l’effort de

développement ou de maintenance du logiciel (p.ex., FPA) est très utile dans la

planification de la production pour obtenir le produit à l’intérieur du calendrier et du

budget prévu.

La revue de la littérature dans le chapitre 2 a montré comment la complexité du logiciel

est mesurée à partir du code et de la structure du logiciel. Les mesures de la taille

capturent la grandeur (ou la longueur) du code source. Elles sont donc associées

directement à l’effort de développement du logiciel. Les mesures de la complexité de la

structure sont associées à la difficulté dérivée de la structure des composants individuels

ou du système entier. Ces mesures capturent les caractéristiques affectant la facilité de

compréhension du code et la qualité de la conception du logiciel. Elles sont donc des

mesures additionnelles de l’effort.

La revue de la littérature dans le chapitre 3 a montré comment la complexité du logiciel

est mesurée à partir de la fonctionnalité du logiciel. La complexité est quantifiée par les

points de fonction. Ces derniers sont comme une mesure composée de la taille, de la

structure des composants et de la structure du système. Cette mesure est sans dimension;

elle est une valeur numérique dérivée de la fonctionnalité du logiciel et des

caractéristiques du système. Elle reflète le volume du logiciel à développer du point de

vue de l’utilisateur. Elle est donc associée directement à l’effort de développement du

logiciel.

Les mesures de points de fonction ont des grands avantages par rapport aux mesures qui

sont basées sur le code source ou la conception. Tout d’abord, elles fournissent tôt dans le

cycle de développement des mesures qui permettent d’estimer l’effort de développement

du logiciel. Elles sont indépendantes du langage et des techniques de programmation. Les

points de fonction reflètent la complexité du problème du logiciel plutôt que la

complexité d’une solution concrète. Ils sont donc compréhensibles par l’utilisateur.

Cependant, la revue a montré aussi certaines limites des mesures de points de fonction.

Deux grands problèmes sont:

!" La façon d’évaluer la complexité: certaines mesures évaluent subjectivement la

complexité des composants élémentaires du logiciel et assignement à ceux-ci des

valeurs empiriques pour que les points de fonction puissent être bien corrélés à

l’effort de développement. Certaines mesures essaient d’évaluer objectivement la

Conclusion

163

complexité des composants élémentaires du logiciel. Mais, aucune méthode ne

s’appuie sur un modèle de la complexité pour expliquer clairement ce qu’on veut

mesurer.

!" L’exactitude des modèles d’estimation d’effort: la marge d’erreur des estimations

d’effort est encore élevée. Un taux d’erreurs moyen de 40% est retrouvé dans

plusieurs rapports pour attester de l’exactitude des estimations.

Ces limites des méthodes de points de fonction ont motivé cette thèse. Le but principal de

la thèse était de proposer une nouvelle méthode de type points de fonction qui peut

surmonter les limites mentionnées. La nouvelle méthode doit quantifier la complexité du

logiciel de façon objective et fournir de bons indicateurs de l’effort. La nouvelle mesure

peut être utilisée pour estimer l’effort de développement du logiciel avec un taux

d’erreurs acceptable dans la pratique. Les questions de recherche pour arriver à cet

objectif ont été présentées à la fin du chapitre 3. Elles sont résolues dans les trois

chapitres 4, 5, et 6. Ici, elles sont résumées pour montrer que le but de la thèse a été

atteint et pour préciser la contribution de la thèse.

1. CADRE DE LA COMPLEXITÉ FONCTIONNELLE

Dans la thèse, le logiciel a été analysé comme une tâche – la tâche à réaliser avec le

logiciel. La complexité fonctionnelle du logiciel est donc la complexité de la tâche. Si la

tâche est complexe, le logiciel pour réaliser la tâche est complexe et il a besoin de plus

d’effort pour son développement.

Cette idée n’est pas nouvelle. Les méthodes de points de fonction se sont développées sur

cette idée. La chose nouvelle dans cette thèse est d’introduire le modèle de la complexité

de la tâche de Wood comme un modèle théorique de base pour analyser

systématiquement la complexité fonctionnelle du logiciel. Ce modèle a été choisi pour

plusieurs raisons:

!" Il fournit une vision globale de la complexité de la tâche. La vision est conforme

aux idées générales sur les systèmes complexes. En fait, la complexité de la tâche

n’est pas la somme de la complexité des composants individuels. Elle doit refléter

un « tout » qui est plus grand que la somme des « parties ». Le modèle de la

complexité de la tâche de Wood couvre non seulement la complexité des

composants mais aussi la complexité du système – le tout.

Conclusion

164

!" La complexité est mesurée en se basant sur le principe de l’information. Plus il y

a d’information à traiter, plus complexe est la tâche. Ce principe est conforme

aux idées philosophiques d’Ashby [11] et de Simon [149,150].

!" La complexité est mesurée par des mesures objectives. En fait, selon le modèle de

Wood, la complexité de la tâche est mesurée selon trois dimensions:

o La complexité des composants qui fait référence aux éléments

d’information.

o La complexité de coordination entre les entrées et les sorties, et la

coordination entre les composants.

o La complexité dynamique.

En se basant sur ce cadre de la complexité de la tâche de Wood, le cadre de la complexité

fonctionnelle du logiciel est proposé aussi selon trois dimensions:

!" La complexité des entrées et sorties.

!" La complexité de la manipulation qui est associée à la coordination entre les entrées

et les sorties.

!" La complexité du système qui est associée à la coordination entre les processus

fonctionnels.

Ces trois dimensions peuvent être retrouvées dans la plupart des méthodes de points de

fonction. Autrement dit, le cadre de la complexité fonctionnelle est conforme aussi aux

idées des méthodes de points de fonction. La chose nouvelle est d’établir une théorie sous

jacente de la complexité fonctionnelle du logiciel. La complexité fonctionnelle du logiciel

est définie selon la complexité de la tâche.

2. PROBLÈME D’ÉVALUATION DE LA COMPLEXITÉ

La plus grande limite de FPA et de la plupart de ses variations est la façon d’évaluer la

complexité. La complexité y est évaluée de façon subjective. Cela rend difficile

l’application cohérente et répétable de la mesure d’un mesureur à l’autre. Chercher une

façon objective pour quantifier la complexité est le but de cette thèse. Ce but est aussi

recherché dans certaines méthodes de points de fonction. En fait, Mark-II a essayé de

quantifier la complexité des transactions via le nombre d’entrées/sorties et le nombre de

références à des données. ASSET-R et la méthode de Points de fonction 3D ont aussi

proposé des mesures objectives. Cependant, ces deux dernières méthodes ne sont pas du

Conclusion

165

domaine public. Il est donc difficile de discuter de la validité de ces méthodes. La mesure

de COSMIC ne comporte que des mesures objectives. Mais, elle ne couvrent pas la

complexité structurelle des composants et la complexité du système. Ces types de

complexité sont très significatifs dans les autres méthodes de points de fonction.

Dans cette thèse, la complexité fonctionnelle du logiciel est mesurée par trois mesures

objectives:

!" La complexité des entrées/sorties est mesurée par le nombre des groupes de

données entrées/sorties du processus fonctionnel. Les groupes de données

peuvent être identifiés en se basant sur des mouvements de données en entrée et

en sortie du processus.

!" La complexité de la manipulation de données fait référence à la relation entre les

entrées et les sorties du processus fonctionnel. Elle est mesurée par le nombre de

conditions sur les entrées pour produire les sorties désirées. Intuitivement, cette

mesure capture le nombre de cas distincts à traiter. Les conditions appliquées sur

les entrées pour produire les sorties reflètent la structure du processus

fonctionnel. Il s’agit des branchements ou des nœuds de décision sur les chemins

de l’entrée à la sortie du processus fonctionnel. De ce fait, le nombre de

conditions est une mesure similaire à celle de McCabe. Elle capture la complexité

structurelle d’un processus fonctionnel de la même façon que la mesure de

McCabe fait pour la structure d’un module.

!" La complexité du système fait référence à la relation des données

(c-à-d, la dépendance de données) entre les processus fonctionnels. Elle est

mesurée par l’entropie du système. Cette mesure capture le niveau de régularité

(ou de désordre) du système.

Les mesures proposées dans cette thèse, d’un côté, sont guidées par le cadre de la

complexité de la tâche de Wood. D’un autre côté, elles couvrent des aspects importants

de la complexité du logiciel qui sont retenus des méthodes de points de fonction. Elles

sont des mesures objectives pour caractériser les aspects qui sont considérés nécessaires

dans les méthodes de points de fonction: les entrées, sorties, la manipulation et la relation

de données entre les processus.

Conclusion

166

3. PROBLÈME DE LA VALIDATION DE LA MÉTHODE

La nouvelle méthode proposée dans la thèse a été validée selon le cadre de validation

d’une méthode de mesure proposé par Jacquet [93]. Dans le chapitre 6, la validation est

faite de la construction de la mesure à l’exploitation de la mesure.

Au niveau de la conception, la nouvelle méthode est conforme au modèle de la

complexité de la tâche de Wood. Le cadre de la complexité fonctionnelle n’est pas

proposé de façon subjective mais en se basant sur le modèle de la complexité de la tâche.

Les mesures de la complexité fonctionnelle sont dérivées des mesures de la complexité de

la tâche.

Au niveau de l’application des mesures, le processus de collecte des données est bien

défini et réalisé indépendamment de la validation. Les règles de comptage définies dans

la nouvelle méthode sont bien précises pour qu’elles puissent être appliquées

correctement. En conséquence, les résultats obtenus de l’application de la mesure sont

fiables, traçables et analysables.

Enfin, la validation du modèle de prédiction a été faite. Les modèles de prédiction

d’effort ont été établis à partir des nouvelles mesures de la complexité fonctionnelle. La

performance de ceux-ci a été analysée. Cette analyse a montré que les mesures proposées

sont pertinentes pour mesurer la complexité du logiciel dans le sens qu’elles fournissent

des bons indicateurs de l’effort.

À partir de la validation présentée dans le chapitre 6, on peut dire que la nouvelle

méthode de mesure développée dans cette thèse est conforme au cadre de développement

d’une méthode de mesure. Elle est valide dans le sens qu’elle couvre des aspects

importants de la complexité fonctionnelle et elle fournit des mesures pertinentes pour

l’estimation de l’effort de développement du logiciel. La validation a montré que les trois

mesures NOD, NOC et EOS sont pertinentes pour capturer la complexité qui se manifeste

dans l’effort de développement du logiciel.

4. CONFORMITÉ À LA THÉORIE DE LA MESURE

La conformité à la théorie de la mesure signifie que la méthode de mesure établie dans la

thèse évite de combiner des mesures d’échelles différentes comme le font parfois

certaines méthodes de points de fonction. FPA et certaines de ses variantes combinent des

mesures d’échelles différentes dans une mesure unique, sans dimension. Par exemple, la

complexité des éléments de base est calibrée sur une échelle ordinale (simple=3,

Conclusion

167

moyenne=4, complexe=7), tandis que le nombre d’éléments est basé sur une échelle

absolue ou cardinale (p.ex., le nombre d’entrées, sorties). Selon la théorie de la mesure

[62], la combinaison des mesures faites selon des échelles différentes n’est pas

significative et, à la limite, est invalide.

Ce problème est résolu dans cette thèse, car nous ne proposons pas une seule valeur

comme la mesure de la complexité du logiciel, mais un ensemble des mesures simples: le

nombre de groupes de données (NOD), le nombre de conditions (NOC) et l’entropie du

système (EOS). Ce sont trois dimensions de la complexité. Elles pourraient être

exploitées indépendamment l’une de l’autre pour juger des aspects différents du logiciel.

Par exemple, NOD pourrait être utilisée pour comparer la complexité des entrées/sorties

de deux processus. NOC, similaire à la mesure de McCabe, pourrait être utilisée pour

comparer la complexité structurelle de deux processus fonctionnels et pour comparer la

complexité de la manipulation de données de deux processus. Enfin, deux systèmes

pourraient être comparés en se basant sur la mesure d’entropie (EOS).

Ces trois mesures simples pourraient être utilisées comme trois paramètres d’un modèle

de prédiction des caractéristiques du logiciel. Par exemple, le couple NOD et NOC ou le

triplet NOD, NOC et EOS est utilisé pour estimer l’effort de développement du logiciel

(modèle (2) ou (4)). Avec la même technique, on peut établir d’autres modèles de

prédiction (p.ex., prédiction de coût) à partir de ces mesures, si on a une base de données

historiques appropriée. Autrement dit, la complexité fonctionnelle du logiciel peut être

exploitée par plusieurs modèles d’estimation différents selon les besoins. Chaque modèle

est représenté dans une formule comprenant l’une ou l’autre des trois mesures de la

complexité. Une telle formule peut fournir une valeur combinée des mesures de la

complexité pour caractériser l’attribut estimé. Cette valeur combinée peut être considérée

comme une « mesure de la complexité » pour un but précis. Ainsi, la mesure de la

complexité est indépendante de son utilisation. On peut l’utiliser selon les besoins.

5. PROBLÈME D’ESTIMATION D’EFFORT

Le problème d’estimation d’effort est un problème important pour le développement des

logiciels. Plusieurs recherches ont été consacrées à ce sujet. On essaie de chercher les

meilleures façons d’estimer l’effort à partir des mesures existantes. Traditionnellement,

l’effort a été estimé à partir des mesures de la complexité en se basant sur des modèles de

régression linéaire (simple ou multiple) [9,2]. Parfois, on doit combiner la transformation

Conclusion

168

logarithmique [165] avec l’analyse de régression pour chercher des modèles non-

linéaires. Certains modèles d’estimation utilisent aussi des techniques d’intelligence

artificielle, comme des réseaux de neurones [153], la logique floue [86], etc. Cependant,

il semble que le taux d’erreurs des estimations est encore élevé.

Le modèle d’estimation d’effort le plus connu et le plus appliqué dans la pratique est le

modèle COCOMO [31]. Il s’agit d’un modèle d’estimation d’effort à partir de la taille du

code source (c-à-d, les lignes de code). La taille du logiciel en KLOC est utilisée pour

estimer un indice de base de l’effort (ou du coût) du logiciel. Cet indice est ensuite ajusté

par 15 facteurs (cost drivers) pour mieux indiquer l’effort (ou le coût – terme utilisé dans

COCOMO). Le degré d’influence de ces facteurs est déterminé par régression en utilisant

la base de données de COCOMO. Cela rend difficile l’application de la méthode et le

transfert à un novice.

Une autre approche est de chercher de meilleurs indices de l’effort, qui vont permettre de

produire des modèles simples et efficaces. Cette approche est prise dans cette thèse. Nous

voulons établir des mesures qui reflètent bien la complexité du logiciel et qui sont bien

corrélées à l’effort. Le modèle de la complexité de la tâche nous aide à déterminer des

aspects pertinents de la complexité et à établir les mesures y correspondant. En tenant

compte d’une vision globale de la complexité de la tâche, la complexité fonctionnelle du

logiciel pourrait bien refléter l’effort. Cette hypothèse est vérifiée dans l’investigation

empirique.

Dans le chapitre 6, un ensemble de 15 projets a été utilisé pour établir des modèles de

prédiction de l’effort. La performance de ces modèles a été analysée. Elle confirme que

les mesures NOD, NOC et EOS sont pertinentes pour mesurer la complexité du logiciel et

qu’elles sont bien cohérentes avec l’effort de développement. L’investigation empirique a

montré que NOD et NOC sont efficaces pour prédire l’effort. Le modèle d’estimation

d’effort construit à partir de l’analyse de régression multiple entre Effort et NOD et NOC

donne une prédiction de haute précision, près du seuil jugé acceptable pour ce type de

prédiction. Les tests croisés ont aussi confirmé l’efficacité de ces mesures. De plus, en

ajoutant EOS à NOD et NOC, l’analyse de régression multiple confirme qu’on pourrait

obtenir un modèle de prédiction plus fiable. Toutefois, les tests croisés ne confirment pas

cette conclusion pour le moment. La taille de l’échantillon utilisé (8 projets) semble trop

limitée pour l’attester. Nous proposons donc de poursuivre cette validation avec un

échantillon plus grand.

Conclusion

169

6. PERSPECTIVES FUTURES DE RECHERCHE

6.1. Exploitation de la mesure

La thèse a établi une nouvelle méthode de mesure de la complexité à partir de la

fonctionnalité décrite dans les spécifications du logiciel. Cette mesure est de type points

de fonction. Elle possède donc les points forts d’une méthode de points de fonction:

l’indépendance relativement de la programmation, la possibilité d’estimer tôt l’effort de

développement, la compréhensibilité pour les utilisateurs…

La nouvelle méthode a résolu de façon significative des problèmes latents des méthodes

de points de fonction, surtout:

!" Le problème d’évaluation subjective de la complexité,

!" L’absence d’un cadre explicatif de la complexité, et

!" La qualité de prédiction de l’estimation d’effort.

Les mesures proposées dans cette thèse sont simples à appliquer mais tout à fait efficace

pour répondre au but d’estimation de l’effort. À son tour, l’effort est un paramètre de base

pour plusieurs autres estimations. Les travaux empiriques dans le chapitre 6 ont montré la

validité et l’applicabilité de la nouvelle méthode. La thèse s’est arrêtée à la conception et

la validation de la méthode de mesure. Les recherches futures pourraient se concentrer sur

l’exploitation de la mesure. Cette dernière implique d’établir des modèles d’estimation

d’autres attributs du logiciel à partir des mesures de la complexité. Ce travail est très

significatif pour que les mesures deviennent utiles. En général, les modèles d’estimation

sont construits en se basant sur un ensemble de données historiques. Cela prend un temps

considérable à réaliser, mais demeure réalisable.

Certains modèles d’estimation importants dans la gestion des logiciels qui sont montrés

dans le cadre de développement d’une mesure [93,94] sont:

!" Le modèle de qualité

!" Le modèle de productivité

!" Le modèle budgétaire

!" Le modèle d’estimation de coût / de l’effort.

Ces modèles pourraient être le sujet de recherches à venir en relation avec la mesure de la

complexité.

Conclusion

170

6.2. Automatisation de la mesure

L’automatisation de la mesure n’est pas le sujet de cette thèse. Cependant, elle pourrait

être un sujet intéressant de recherche future. Actuellement, les méthodes de points de

fonction, y compris la nouvelle méthode présentée dans cette thèse, sont appliquées

manuellement. Les mesureurs analysent des spécifications, identifient les composants du

logiciel (p.ex., les processus fonctionnel, les mouvements de données…) puis calculent

les points de fonctions. La difficulté de l’automatisation d’une mesure de points de

fonction est liée au fait que les spécifications sont souvent écrites en langage naturel, sans

normalisation. Les représentations formelles d’un logiciel ne sont pas disponibles au

début de la phase d’analyse.

Les approches communes pour automatiser les mesures de points de fonction sont:

!" Proposition d’un formalisme spécifique qui permette d’écrire les spécifications

du logiciel en termes de concepts de la mesure. Pour automatiser une mesure, on

propose, d’abord, une norme pour écrire la spécification. Puis, à partir de ce

format spécifique, un outil (analyseur) peut analyser les spécifications et faire des

comptages automatiques. Cette approche est celle de la recherche de Diab

et al. [57]. Dans les travaux de celui-ci, les spécifications sont écrites sous un

format spécifique, appelé B-spécification, qui facilite l’identification des concepts

de COSMIC-FFP et les compte automatiquement.

!" Utilisation d’un formalisme normalisé, par exemple le modèle entité-relation ou

le modèle UML (Unified Modeling Language). Selon cette approche, les

concepts du formalisme normalisé sont mis en correspondance avec les concepts

de mesures. Grâce à cet arrimage, les points de fonction sont comptés

automatiquement. Cette approche est utilisée dans plusieurs tentatives

d’automatisation de mesure. En fait, Gramantieri [73] a proposé un formalisme

(en Prolog) permettant d’identifier les concepts de FPA à partir d’un diagramme

entité-relation. Uemura [171] avec ses collègues ont proposé un formalisme

permettant l’identification des concepts de FPA à partir d’une spécification

réalisée avec l’outil CASE Rational Rose. Torres [162] a développé un outil

automatique pour FPA, appelé Oliva Nova Function Point Counter, qui compte

les points de fonction de FPA à partir d’une spécification de format XML. Bévo

et Lévesque [27] ont proposé un formalisme général basé sur le concept

d’ontologie qui permet la mise en correspondance d’une spécification du logiciel

Conclusion

171

en UML/XML avec les concepts d’une mesure de points de fonction quelconque

(FPA, COSMIC-FFP et autres).

Actuellement, il n’existe pas encore d’outil bien connu pour mesurer automatiquement les

points de fonction. Le problème d’automatisation est encore un sujet de recherche.

Cependant, les approches actuelles pour automatiser une mesure de points de fonction

sont applicables à la méthode proposée dans cette thèse. De plus, notre méthode peut

faciliter l’automatisation parce qu’elle est simple et bien définie. En fait, la méthode

proposée dans cette thèse est une modification de COSMIC-FFP. Le nombre de groupes

de données est une partie des mouvements de données. Logiquement, si on peut

automatiser la mesure de COSMIC, NOD peut être automatisée. Quant au nombre de

conditions, cette mesure correspond au nombre de sorties désirées. Dans notre

conception, pour éviter des ambiguïtés dans l’identification des sorties à partir des

spécifications en langage naturel, nous proposons de compter le nombre de conditions

d’appartenance associées à des classes d’équivalence plutôt que le nombre de sorties.

Cependant, avec des spécifications formelles, les sorties peuvent être définies sans

ambiguïtés, le nombre de conditions pouvant être remplacé par le nombre de sorties.

Donc, elles peuvent faciliter l’automatisation. Dans le cas général, NOC peut aussi être

compté automatiquement à partir des conditions formulées dans les diagrammes de

séquences en UML.

Enfin, le comptage de l’entropie du système demande un modèle des dépendances de

données du système. Ce type du modèle n’est pas disponible dans les formalismes

normalisés comme UML. Alors, le comptage d’EOS peut avoir besoin de travaux

additionnels pour établir un tel modèle. Cependant, l’important est que ce modèle peut

être construit en se basant sur le modèle fonctionnel et l’architecture générale du système.

Autrement dit, il est possible de créer un outil pour construire automatiquement un

modèle des dépendances de données du système à partir d’un modèle normalisé.

Les discussions ci-dessus montrent une possibilité d’automatisation de la mesure. La

création et l’implémentation d’un outil automatique pour notre mesure sont donc

réalisables en principe. La vérification et la validation de tel outil pourrait re-utiliser les

comptages de la complexité dans cette thèse comme une base de données historiques.

Donc, théoriquement, le problème d’automatisation de notre méthode de mesure est

résolu.

BIBLIOGRAPHIE

1. Abran A., Desharnais J.-M., Oligny S., St-Pierre D., Symons C., COSMIC FFP –

Measurement Manual – Field Trials Version, Montreal, May, 2001.

2. Abran A., Silva I., Primera L., Field Studies Using Functional Size Measurement in Building Estimation Models for Software Maintenance, Journal of Software Maintenance and Evolution: Research and Practice, 2002, Vol.14, pp. 31-64.

3. Abran A., Desharnais J.-M., Oligny S., St-Pierre D., Symons C., COSMIC FFP – Measurement Manual – the COSMIC Implementation Guide for ISO/IEC 19761:2003, January, 2003.

4. Abran A., Analyse du processus de mesure des points de fonction, thèse de doctorat, École Polytechnique de Montréal, 1994.

5. Abran A., Desharnais J.-M., Oligny S., St-Pierre D., Bourque P., Design of a Functional Size Measurement for Real-Time Software, Research report, pp. 13-23, 1998.

6. Adamov R., Richter L., A Proposal for Measuring the Structural of Complexity Programs, Journal of Systems and Software, Vol. 12, pp. 55-70, 1990.

7. Aho, A.V., Hopcroft J.E., Ullman J.D., The Design and Analysis of Computer Algorithms, Addison-Wesley, 1974.

8. Albrecht A., Measuring Application Development Productivity, presented at the IBM Applications Development Symposium, 1979.

9. Albrecht A., Gaffney J., Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation, IEEE Transactions on Software Engineering, Vol. SE-9, No. 6, pp. 639-648, November 1983.

10. Anderson J.R., Reder L.M., Lebriere C., Working Memory: Activation Limitations on Retrieval, Cognitive Psychology, Vol. 30, pp. 221-256, 1996.

11. Ashby W.R., Some Peculiarities of Complex Systems, Cybernetic Medicine, Vol. 9, pp.1-8, 1973.

12. Atlan H., Les théories de la complexité, Seuil, 1991.

13. Baker A.L., Beiman J.M., Fenton N., Gustafson D.A., Melton A., Whitty R., A Philosophy of Software Measurement, Journal of System Software, Vol. 12, pp. 277-281, 1990.

14. Balzer R., What We Do and Don’t Know About Software Process, Software Process Symposium, Washington, September, 1990.

15. Banker R.D., Slaughter S.A, The Moderating Effects of Structure on Volatility and Complexity in Software Enhancement, Information Systems Research, Vol.11, pp. 219-240, 2000.

16. Banker R.D., Datar S.M., Kemerer C.F., Zweig D., Software Complexity and Maintenance Costs, Communications of ACM, Vol. 36(11), pp. 81-94, 1993.

Bibliographie

173

17. Banker R.D., Davis G.B., Slaughter S.A, Software Development Practices, Software Complexity, and Software Maintenance Performance: A Field Study, Management Science, Vol. 44, No. 4, pp. 433-450, 1998.

18. Basili V.R., Tutorial on Models and Metrics for Software Management and Engineering, IEEE Computer Society Press, New York, 1980.

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

20. Basili V.R., Weiss D., A Methodology for Collecting Valid Software Engineering Data, IEEE Transactions on Software Engineering, SE-10(6), pp. 728-738, 1984.

21. Basili V.R., Rombach H.D., The Tame Project: Towards Improvement-Oriented Software Environments, IEEE Transaction on Software Engineering, 14(6), pp. 758-773, 1988.

22. Batty M., Torrens P.M., Modeling Complexity: The Limits to Prediction, Cybergeo, No. 201, 2001. http://www.cybergeo.presse.fr/ectqg12/batty/articlemb.htm

23. Belady L.A., Evangelisti C.J., System Partitioning and its Measure, Journal of System and Software, No. 2, pp. 23-39, 1981.

24. Bennett C.H., Logical Depth and Physical Complexity, in The Universal Turing Machine- a half Century Survey, pp. 227-257, Oxford University Press, 1988.

25. Bennett P.A., Software Development for Channel Tunnel: A summary, High Integrity System, 1(2), pp. 213-220, 1994.

26. Bertalanffy L., Théorie Générale des Systèmes, traduction par Jean Benoît Chabrol, Dunod, Paris, 1982.

27. Bevo V., Lévesque G., Meunier J-G., Toward an Ontological Formalisation for Software Functional Size Measurement Method’s Application Process: The FPA Case, Hanoi, Vietnam, February 2-5, 2004.

28. Bieman J.M, Ott L.M., Measuring Functional Cohesion, IEEE transaction on Software Engineering, 20(8), pp. 644-657, 1994.

29. Boetticher G., Srinivas K., Eichmann, D., A Neural Net-Based Approach to Software Metrics, Proceedings of the 5th International Conference on Software Engineering and Knowledge Engineering, pp. 271-274, June 1993.

30. Boehm B.W., Software Engineering Economics, Prentice-Hall, 1981.

31. Boehm B.W., Clark B., Horowitz et al., Cost Model for Future Life Cycle Processes: COCOMO 2.0, Annals of Software Engineering 1 (1), 1-24, Nov. 1995.

32. Briand L.C., Morasca S., Basili V.R., Property-Based Software Engineering Measurement, IEEE Transactions on Software Engineering, Vol. 22, No. 1, pp. 68-86, January 1996.

33. Briand L., Ikonomovski S., Lounis H., A Comprehensive Investigation of Quality Factor in Object-Oriented Design: An Industrial Case Study, International Software Engineering Research Network, ISERN-98-29, 1998.

34. Brooks F.P., The Mythical Man-Month, Addison-Wesley, New York, 1975.

35. Brooks F.P., No Silver Bullet: Essence and Accidents of Software Engineering, Computer, Vol. 20, pp. 10-19, 1987.

Bibliographie

174

36. Broadbent D.E., The Magic Number Seven After Fifteen Year, In A. Kennedy & A. Wilkers (Eds.) Studies in long-term memory, pp. 3-18, Wiley, London, 1975.

37. Budgen D., Software Design, Addison-Wesley, 1994.

38. Burman P., Chow E., Nolan D., A cross-validatory method for dependent data. Biometrika, 81(2), pp. 351-358, 1994.

39. Campbell D.J., Gingrich K., The Interactive Effects of Task Complexity and Participation on Task Performance: A Field Experiment, Organizational Behaviour and Human Decision Processes, Vol. 38, 1986, pp. 162-180.

40. Campbell D.J., Task Complexity: A Review and Analysis, Academy of Management Review, Vol. 13, pp. 40-52, 1988.

41. Cant S.N., Jeffrey D.R., Henderson-Seller B., A Conceptual Model of Cognitive Complexity of Elements of the Programming Process, Information and Software Technology, Vol. 37, pp. 351-362, 1995.

42. Card S.K., Moran T.P., Newell A., The Psychology of Human Computer Interaction, Hillsdale, 1983.

43. Card D.N., Glass R.L., Measuring Software Design Quality, Prentice Hall, 1990.

44. Chaitin G.J., Algorithmic Information Theory, Cambridge University, 1987.

45. Chaitin G.J., Information, Randomness, and Incompleteness, Singapore, World Scientific, 1992.

46. Cherniavsky J.C, Smith C.H., On Weyuker’s Axioms for Software Complexity Measures, IEEE Transactions on Software Engineering, No. 17, pp. 636-638, 1991.

47. Chidamber S.R., Kemerer C.F., A Metrics Suite for Object Oriented Design, IEEE transactions on software engineering, 20 (6), pp. 476-498, 1994.

48. Chulani S., Boehm B., Steece B., Bayesian Analysis of Empirical Software Engineering Cost Models, IEEE Transactions on Software Engineering, 25 (4), July, 1999.

49. Conte S.D., Dunsmore H.E., Shen V.Y., Software Engineering Metrics and Models, Benjamin/Cummings, Menlo Park, CA, 1986.

50. Cordero R., Costramagna M., Paschetta E., A Genetic Algorithm Approach for the Calibration of COCOMO like Models, 12th COCOMO Forum, 1997.

51. Curtis B., In Search of Software Complexity, Workshop on Quantitative Software Models, IEEE, New York, pp. 95-106, 1979.

52. Curtis B., Fifteen Years of Psychology In Software Engineering: Individual Differences and Cognitive Science, Proceedings of the 7th international conference on Software engineering, pp. 97-106, 1984.

53. Darcy D.P., Kemerer C.F., Software Complexity: Toward a Unified Theory of Coupling and Cohesion, Ph.D Friday Workshops, Spring 2002, University of Minnesota.

54. Davis J.S, Chunks: A Basis for Complexity Measurement, Information Processing and Management, Vol. 20, pp. 119-127, 1984.

55. Davis J.S., LeBlanc R.J, A Study of The Applicability of Complexity Measures, IEEE Transactions on Software Engineering, Vol. 14, No. 9, pp. 1366-1372, 1988.

Bibliographie

175

56. DeMarco T., Controlling Software Projects: Management, Measurement, and Estimation, New York, NY: Yourdon Press, 1982.

57. Diab H., Frappier M., St-Denis R., A Formal Definition of Function Points for Automated Measurement of B Specifications. Formal Methods and Software Engineering. Lecture notes in Computer Science, Vol. 2495, pp. 483-494, Springer, Berlin, Germany, 2002.

58. Dunn R.H., Software Quality – Concepts and Plans, Prentice Hall, 1990.

59. Ejiogu L.O., Beyond structured programming: an introduction to the principles of applied software metrics, Structured Programming, 11 (1), pp. 27-43, 1990.

60. Evangelisti W.M., Software Complexity Metric Sensitive to Program Structured Rules, The Journal of System and Software, No. 3, pp. 231-243, 1983.

61. Fenton N.E., Software Measurement: A Necessary Scientific Basis, IEEE Transaction on Software Engineering, Vol. 20, No. 3, pp. 199-206, Mar. 1994.

62. Fenton N.E., Pfleeger S.L., Software Metrics: A Rigorous and Practical Approach, second edition, 1997.

63. Fenton N.E., Neil M., Software Metrics: Successes, Failures and New Directions, The Journal of Systems and Software, Vol. 47, No. 2-3, pp. 149-157, 1999.

64. Fenton N.E., Neil M., A Critique of Software Defect Prediction Models, IEEE Transactions on Software Engineering, Vol. 25, pp. 675-689, 1999.

65. Finnie G.R., Wittig G.E., Desharnais J.M., Estimating software development effort with case-based reasoning, Proceedings of International Conference on Case-based Reasoning, p. 13-22, 1997.

66. Fortin R., Comprendre la Complexité, Les presses de l’université Laval, 2000.

67. Garmus D., Herron D., Measuring the Software Process, Upper Saddle River: Yourdon Press, 1996.

68. Gilb T., Software Metrics, Winthrop Publishers, Inc., Cambridge, Massachusetts, 1977.

69. Gill G.K., Kemerer C.,F., Cyclomatic Complexity Density and Software Maintenance Productivity, IEEE Transaction on Software Engineering, Vol.17 (9), pp. 1284-1288, 1991.

70. Grady R.B., and Caswell D.L., Software Metrics, Prentice Hall, 1987.

71. Grady R.B., Practical Software Metrics for Project Management and Process Improvement, New Jersey: Prentice Hall, 1992.

72. Grady R.B, Successfully Applying Software Metrics, IEEE computer, 27(9), pp. 18-25 September 1994.

73. Gramantieri, F., Lamma, E., Riguzzi, F., Mello, P., A system measuring function points from specification, 1997. http://dcm.cl.uh.edu/capf01gp4/delivers/gramantieri97system.pdf

74. GUIDE International Corp., Estimating Using Function Point Handbook, 1985.

75. GUIDE Publications GPP-134, Reprint 1989.

76. Halstead M.H., Element of Software Science, New York, Elsevier North-Holland, 1977.

77. Hansen W., Measurement of Program Complexity by Pair (Cyclomatic Number, Operator Count), ACM SIGPLAN notices, Vol. 13, No. 3, pp. 29-33, Mars 1978.

Bibliographie

176

78. Harrison W., An Entropy-Based Measure of Software Complexity, IEEE Transactions on Software Engineering, Vol. 18, No. 11, pp. 1025-1029, 1992.

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

80. Henderson-Sellers B., Object-Oriented Metrics – Measures of Complexity, Prentice Hall, New Jersey, 1996.

81. Heylighen F., Joslyn C., What is Systems Theory?, in: F. Heylighen, C. Joslyn and V. Turchin (editors), Principia Cybernetica, Brussels, 1992.

82. Hodgkinson A.C., Garratt P.W., A neurofuzzy Cost Estimator, Proceedings of the 3rd International Conference on Software Engineering and Applications, pp.401-406, 1999.

83. Holland J.H., Hidden Order: How Adaptation Builds Complexity, Addison-Wesley, 1996.

84. Case Study: Rice Cooker, UQAM Software Engineering Management Research Laboratory, version 2.1, edited by Ho T.V., 14 Jan. 2000.

85. Humphrey W.S, A Discipline for Software Engineering, Addition-Wesley, MA, 1995.

86. Idri A., Abran A., Khoshgoftaar T.M., Robert S., Evaluating Software Project Effort by Analogy Based on Linguistic Values, World Congress on Computational Intelligence, Hawaii, May 2002 .

87. IEEE, Standard Dictionary of Measures to Produce Reliable Software, The Institute of Electrical and Electronics Engineers, IEEE Standard Board, 1989.

88. IFPUG (International Function Point Users Group), Function Point Counting Practices Manual, Release 1.1, Westerville, Ohio, April 1986.



91. ISO 9001 ComplianceTM – Quality Manual + SOP's + Forms, ISO, 2000.

92. Jackson M., Principles of Program Design, London: Academic, 1975.

93. Jacquet J.P., Abran A., From Software Metric to Software Measurement Method: A Process Model, The Third International Symposium and Forum on Software Engineering Standards, ISESS’97, IEEE, 1997.

94. Jacquet J.P., Abran A., Metrics Validation Proposals: A Structure Analysis, The 8th International Workshop on Software Measurement, Magdeburg, Germany, September, 1998.

95. Jarvelin K., Information Technology and Development of Society: An Information Science Perspective, In Information technology and Information Use: Towards a Unified view of information and information Technology. London: Taylor Gramham, pp. 35-55, 1986.

96. Jones C., Estimating Software Cost, Second edition, New York, McGraw-Hill Inc, 1998.

97. Jones C., Building a Better Metric, Computerworld Extra, 20 June 1988.

98. Jones C., Applied Software Measurement – Assuring Productivity and Quality, New York, McGraw-Hill Inc, 1991.

Bibliographie

177

99. Kearney K.J., Sedmeyer R.L., Thompson W.B, Gray M.A., Adler M.A., Software Complexity Measurement, Communications of the ACM, Vol. 29, No. 11, 1986.

100. Kelvin L., Popular Lectures and Addresses, Vol. 1, pp. 73, 1891-1894.

101. Kemerer C.F., Software complexity and Software Maintenance: A Survey of Empirical Research, Annals of Software Engineering, Vol. 1, No. 1, pp. 1-22, 1995.

102. Kemerer C.F., An Empirical Validation of Software Cost Estimation Models, Communication of ACM, Vol. 30, No. 5, pp. 416-429, 1987.

103. Kintsch W., Memory and Cognition, John Wiley, New York, 1977.

104. Kintsch W., Comprehension: a Paradigm for Cognition, Cambridge University Press, 1998.

105. Kitchenham B., Känsälä K., Inter-item Correlations among Function Points, Proceedings of the 15th International Conference on Software Engineering, pp. 477-480, 1993.

106. Kitchenham B.A., Pfleeger S.L., Fenton N.E., Towards a Framework for Software Measurement Validation, IEEE Transactions on Software Engineering, Vol. 21, No. 12, pp. 929-943, 1995.

107. Kitchenham B.A., John G.S., The Danger of Using Axioms in Software Metrics. IEEE Proceedings Software 144(5-6): 279-285, 1997.

108. Kolmogorov A.N., Three Approaches to the Quantitative Definition of Information, Problem in Information Transmission, Vol. 1, pp. 1-7, 1965.

109. Kolmogorov A.N., Logical Basis for Information Theory and Probability Theory, IEEE Transaction on Information Theory, IT 14, pp. 662-664, 1968.

110. Legasto A.A., Forrester J.W., Lyneis J.M., System Dynamics, North Holland, 1980.

111. Le Moigne J-L., La Théorie du Système Général, Paris: PUF, 1994.

112. Le Moigne J-L., La Modélisation des Systèmes Complexes, Paris (Dunod) 1995.

113. Levy-Leblond J-M., La Physique, une Science sans Complexe?, dans « Les Théories de la complexité. Autour de l’œuvre d’H. Atlan ». Paris: Seuil, 1991.

114. MacDonell S.G., Rigor in Software Complexity Measurement Experimentation, Journal of Systems Software, Vol. 16, No. 2, pp. 141-149, October, 1991.

115. Manson, S. M., Simplifying Complexity: A Review of Complexity Theory. Geoforum No. 32, pp. 405-414, 2001.

116. March J., Simon H., Organizations, New York: Wiley, 1958.

117. Martin J., Rapid Application Development, McMillan Publishing, NY, 1991.

118. McCabe T.J., A Complexity Measure, IEEE Transactions on Software Engineering, Volume SE-2, No. 4, pp. 308-320, December 1976.

119. McCabe T.J., Butler C.W., Design Complexity Measurement and Testing, Communications of the ACM, Vol. 32, No. 12, pp. 1415-1425, December, 1989.

120. Melton A.C., Gustafson D.A., Bieman J.M., and Baker A.L., A Mathematical Perspective For Software Measures Research, IEEE Software Engineering Journal, Vol. 5, pp. 246-254, 1990.

121. Mendonca M.G., Basili V.R., Validation an approach for improving existing measurement frameworks, Transactions on Software Engineering, Vol. 26, pp. 484-499, 2000.

Bibliographie

178

122. Miller G.A., The Magical Number Seven Plus Or Minus Two: Some Limits on Our Capacity for Processing Information, Psychological Review, 63, 81-97, 1956.

123. Morin E., Introduction à la Pensée Complexe, ESF éditeur, 1990.

124. Morin E., La Méthode, Quatre volumes, Paris: Seuil, 1977-1991.

125. Morin E., Le Système, Paradigme Ou/Et Théorie, dans AFCET: Modélisation et maîtrise des systèmes techniques, économiques et sociaux, Paris: Hommes et Techniques, T1, pp.44-53, 1997.

126. Mugur-Schächter M., A Method of Relativized Conceptualization, From Quantum Mechanics toward a Formalized Epistemology, M. Mugur-Schächter and A. Van Der Merwe (Eds) Kluwer, 2000.

127. Myers G.J., An Extension to the Cyclomatic Measure of Program Complexity, ACM SIGPLAN notices, Vol.12, No.10, pp. 61-64, October 1977.

128. Naur P., Randell B., Software Engineering: A report on a Conference sponsored by the NATO Science Committee, NATO, 1969.

129. Parrott L., Complexity and the Limits of Ecological Engineering, Transactions of the ASAE, No. 45, pp. 1697-1702, 2002.

130. Paulk M.C., Curtis B., Chrissis M.B., Weber C.V., The Capability Maturity Model for Software, IEEE Software, Vol. 10, No. 4, pp. 18-27, July 1993.

131. Peters J.F., Pedrycz W., Software Engineering: An Engineering Approach, John Wiley & Son, Inc., 1999.

132. Pfleeger S.L., Jeffery R., Curtis B., Kitchenham B., Status Report on Software Measurement, IEEE Software, pp. 33-43, 1997.

133. Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill, 1987.

134. Prietula M.J., Vincinanza S.S., Mukhopadhyay T., Software Effort Estimation With Case-Based Reasoner, Journal Experimental & Theoretical Artificial Intelligence 8, pp. 341-363, 1996.

135. Putnam, L.H., A General Empirical Solution to the Macro Software Sizing and Estimating Problem, IEEE Transactions on Software Engineering, Vol. 4, No. 4, pp. 345-361, July 1978.

136. Ramamoorthy C.V, Tsai W., Yamaura T., Bhide A. , Metrics Guided Methodology, COMPSAC 85, pp. 111-120, 1985.

137. Reifer D.J., Asset-R: A Function Point sizing Tool for Scientific and Real-Time Systems, Journal of systems software, Vol. 11, No. 3, pp. 159-171, 1990.

138. Schroder H., Driver M., Streufert S., Human Information Processing, New York: Holt, Rinehart and Winston, 1967.

139. Schwab D., Cummings L., A Theoretical Analysis of The Impact of Task Scope on Employee Performance, Academy of Management Review, No. 1, pp. 23-35, 1976.

140. Shao J., Linear model selection by cross-validation, Journal of the American Statistical Association, No. 88, pp. 486-494, 1993.

141. Shao J., Wang Y., A new Measure of Software Complexity Based on Cognitive Weights, Canadian Journal Electronic and Computer Engineering, Vol. 28, No. 2, pp. 69-74, April 2003.

Bibliographie

179

142. Shannon C.E., Weaver W., The Mathematical Theory of Communication, University of Illinois Press, Urbana, 1949.

143. Shepperd M.J., Ince D., The Use of Metrics in the Early Detection of Design Errors, Proceedings of the European Software Engineering Conference, pp. 67-85, 1990.

144. Shepperd M.J., Schofield C., Kitchenham B.A., Effort Estimation Using Analogy, 18th International Conference on Software Engineering, Berlin, IEEE Computer Press, 1996.

145. Shneiderman B., Mayer R., Syntactic / Semantic Interactions in Programmer Behavior: A Model and Experimental Results, International Journal Computer and Information Sciences, Vol. 8, No. 3, pp. 219-238, 1979.

146. Simon H.A., From Substantive to Procedural Rationality, in S. Latsis (ed) Method and Appraisal in Economics Cambridge: Cambridge UP, pp.129-148, 1976.

147. Simon H.A, Models of Thought: Volume I, New Haven, Connecticut: Yale University Press, 1979.

148. Simon H.A, Models of Thought: Volume II, New Haven, Connecticut: Yale University Press, 1989.

149. Simon H.A., Les introuvables en langue française de H.A. Simon, dans La revue internationale de systémique, Vol. 4, No. 2, pp. 125-145, 1990.

150. Simon H.A., Sciences des Systèmes, Sciences de l’artificiel, Ch.7 l’architecture de la complexité, Dumod, Paris, 1991.

151. Ndagijimana S., Rapport de stage: Observations sur le terrain, document non-publié du Laboratoire de Recherche en Gestion des Logiciels, Université du Québec à Montréal, Février, 2002.

152. Solomonoff R.J., A formal Theory of Inductive Inference, Information and Control, Vol. 7, pp. 1-22, 224-254, 1964.

153. Srinivasan, K., Fisher D., Machine Learning Approaches to Estimating Software Development Effort, IEEE Transactions Software Engineering, Vol. 21, No. 2, pp. 126-137, February 1995.

154. Steinmann D., The Effects of Cognitive Feedback and Task Complexity in Multi-Cue Probability Learning, Organizational Behavior and Human Decision Processes, Vol. 15, No. 2, pp.168-179, 1976.

155. Stroud J., The Fine Structure of Psychological Time, Annals of New York Academy of Science, Vol. 138, No. 2, pp. 623-631, 1967.

156. Sullivan J.E., Measuring the Complexity of Computer Software, Mitre Corporation, P.O Box 208, Bedfort, MA 01730, 1975.

157. Sutcliffe A., Human-Computer Interface Design, Springer-Verlag, New York, 1989.

158. Symons C., Function Point Analysis: Difficulties and Improvements, IEEE Transactions on Software Engineering, Vol. 14, No. 1, pp. 2-11, January, 1988.

159. Terborg J., Miller H., Motivation, Behavior And Performance: A Closer Examination of Goal-Setting and Monetary Incentives, Journal of Applied Psychology, Vol. 63, pp. 29-39, 1978.

160. Turney P., A Theory of Cross-Validation Error, Journal of Experimental and Theoretical Artificial Intelligence, No. 6, pp. 361-391, 1994.

Bibliographie

180

http://arxiv.org/ftp/cs/papers/0212/0212029.pdf

161. Tian J., Zelkowitz M.V., A Formal Program Complexity Model and Its Application, Journal of Systems and Software, Vol. 17, pp. 253-266, 1992.

162. Torres I., Calatrava F., Automatic Function Point Counting on Conceptual Models, CARE technologies, 2003. http://www.care-t.com/technology/doc/WP-ONFuntionPoints.pdf

163. Tran-Cao D., Abran A., Levesque G., Functional Complexity Measurement, Proceedings of the 11th International Workshop on Software Measurement, Montreal, Canada, IWSM 2001, pp. 173-181, 2001.

164. Tran-Cao D., Levesque G., Abran A., Measuring Software Functional Size: Towards an Effective Measurement of Complexity, Proceedings of IEEE Conference on Software Maintenance, Montreal, Canada, pp. 370-376, October 2002.

165. Tran-Cao D., Levesque G., Maintenance Effort and Cost Estimation Using Software Functional Sizes, International Workshop on Software Measurement, Montreal, Canada, September 2003.

166. Tran-Cao D., Levesque G., Meunier J-G, Software Functional Complexity Measurement with the Task Complexity Approach, Proceedings of RIVF’04, Hanoi, Vietnam, February 2004.

167. Tran-Cao D., Lévesque G., Meunier J-G. A Field Study of Software Functional Complexity Measurement, Proceedings of the 14th International Workshop on Software Measurement, pp.175-194, Berlin, Germany, 2004.

168. Tracz, W.J., Computer Programming and the Human Thought Process, Software Practice and Experience, No. 9, pp. 127-137, 1979.

169. Turing A.M., Computing Machinery and Intelligence. Mind, Vol. 59, No. 263, pp.433-460, 1950. http://www.loebner.net/Prizef/TuringArticle.html

170. Troy D.A., Zweben S.H., Measuring the Quality of Structured Design, Journal of Systems and Software, Vol. 2, No. 2, pp. 113-120, 1981.

171. Uemura T., Kusumoto S., Inoue K., Function-Point Analysis Using Design Specification Based on the Unified Modeling Language, Journal of software maintenance and evolution: Research and practice, Vol. 13, pp. 223-243, June 2001.

172. Wang Y., On Cognitive Informatics: Keynote Lecture, Proceedings of the 1st IEEE Conference Cognitive Informatics (ICCI’02), Calgary, Alberta, Canada, pp. 34-42, August 2002.

173. Walston C.E., Felix C.P., A Method of Programming Measurement and Estimation, IBM Systems Journal, Vol. 16, No. 1, pp. 54-73, 1977.

174. Weyuker E.J., Evaluating Software Complexity Measures, IEEE Transactions on Software Engineering, Vol. 14, No. 9,pp. 1357-1365,1988.

175. Whitmire S.A., An Introduction to 3D Function Points, Software Development, pp. 43-53, April, 1995.

176. Wittig G., Finnie G., Estimating Software Development Effort with Connectionist Models, Information and Software Technology, Vol. 39, No. 7, pp. 469-476, 1997.

177. Wood R.E., Task Complexity: Define of the Construct, Organisational Behaviour and Human Decision Process, Vol. 36, pp. 62-82, 1986.

Bibliographie

181

178. Yatchinovsky A., L’approche Systémique pour Gérer l’Incertitude et la Complexité, ESF éditeur, 1999.

179. Yourdon E., Constantine L.L., Structure design, Prentice Hall, NJ, 1979.

180. Zuse H., Software Complexity Measures and Methods, Walter de Gruyter, Berlin - New York, 1991.

ANNEXE 1

PUBLICATIONS

Références des publications

1 TRAN-CAO De, LÉVESQUE Ghislain, MEUNIER Jean-Guy, Measuring Software Complexity for Early Estimating Development Effort, (accepted at) CMEM’05, Malta, Italy, 20-22 June 2005.

2 TRAN-CAO De, LÉVESQUE Ghislain, MEUNIER Jean-Guy, A Function Point Method for Software Complexity Measurement, 3è Conférence Internationale en Informatique, Recherche, Innovation et Vision du Futur (RIVF’05), Cantho, Vietnam, 21-24 February 2005.

3 TRAN-CAO De, LÉVESQUE Ghislain, MEUNIER Jean-Guy, A Field Study of Software Functional Complexity Measurement, proceedings of the 14th International Workshop on Software Measurement, pp.175-194, IWSM/METRIKON’04, Berlin, Germany 3-5 November 2004.

4 TRAN-CAO De, LÉVESQUE Ghislain, MEUNIER Jean-Guy, Software Functional Complexity Measurement with the Task Complexity Approach, 2è Conférence Internationale des chercheurs Vietnamiens et Francophones (RIVF’04), Hanoi, Vietnam, 2-5 February 2004.

5 TRAN-CAO De, LÉVESQUE Ghislain, Maintenance Effort and Cost Estimation Using Software Functional Sizes, Proceedings of the 13th International Workshop on Software Measurement, IWSM’03, Montreal, Canada, 23-25 September 2003.

6 TRAN-CAO De, LÉVESQUE Ghislain, ABRAN Alain, Measuring Software Functional Size: Towards an Effective Measurement of Complexity, proceedings of the IEEE International Conference on Software Management, pp.370-376, ICSM’02, Montreal, Canada, 3-6 October 2002.

7 TRAN-CAO De, ABRAN Alain, LÉVESQUE Ghislain, Functional Complexity Measurement, Proceedings of the 11th International Workshop on Software Measurement, pp. 268-283, IWSM’01, Montreal, Canada, 28-29 August 2001.

ANNEXE 2

RAPPORT DE COMPTAGE DE 15 PROJETS

1. Case study 1: Project P6

Document source - System Design, version 1.1, December 20th 2000

Document quality Not enough detail Complexity Counting Functional processes Information cues

Conditions Hypothesis

Create a new table entry

- entry: effective date and latest table entry - write & exit (copy): new table entry NOD=2

Not count Write and Exit.

Miscellaneous discount

- Read & exit: old discount value. - Entry, Write & Exit: new discount value. NOD=2

Count 1 Read and 1 Entry.

Domestic NOD=2 As above Gold service NOD=2 As above Canada rate NOD=2 As above U.S rate NOD=2 As above Intra rate NOD=2 As above Miscellaneous rates NOD=2 As above Report NWA889 - Read: gold data.

- Write & exit: summary sections

NOD=2

- Day - evening - night or

weekend. NOC=3

TOTAL NOD=18 NOC=3 System complexity:

Rapport de comptage de 15 projets

184

- All screens share the same database with the following model:

There is no send-receive data from one screen to other. Therefore, these screens are independent.

EOS = 0


185


Document source - System specification, System Architecture, version 1.1, September 13th 2000

Document quality Detail Complexity Counting: Functional process NOD NOC Hypothesis Determine facility status of a TN

-Read: data table. - Write & Exit: TN status. NOD=2

- Leased - Working - Vacant - Other

NOC=4

Write and Exit is count as one because TN status is unchanged.

Count number of release

NOD=2

Count number of working TN

NOD=2

Count number of Vacant TN

NOD=2

Count number of TN by other

NOD=2

Count number of TN by remark

NOD=2

Each counting process is counted as 2 pts. (one Read data and one Write of counting result).

TOTAL NOD=12 NOC=4 System complexity: EOS=0 These requests are independent (see the diagram on p. 5)


186


The specification of this project is lost. Reuse the counting in [148]: NOD = CFFP. NOC = 0. EOS = **.


187


Document source System Design, version 1.0, November 21st 2000 Document quality Detail Complexity Counting Functional processes Information cues


Toll free service SIF-A 1.1.2 and 1.1.3 is the same functional process with two different interfaces.

- Used Language

- customer - telco info. - Activity - Order - Features - Conversion - Add row - Remarks - Technical inf. NOD=10

- IF lang=EN then interface in English. NOC=1

Each data group is entered and saved in DB without modified there fore count as 1 for each. * Interface in French is defaut.

Toll free service 1.1.4-1.1.5

- Customer - Virtual

transfer - Validation

list - Speed dial

list - remarks - Language - Add row

NOD=7

IF lang=EN then interface in English. NOC=1

- Similar to the counting as above. - Counting is based on the design detailed in 800A_V02E.dot and 800A_V02F.dot

Toll-free service SIF-H 1.1.6-1.1.7

- Used Language

- customer - Feature

options - DB

validation list- Speed dial

list - Remarks

IF lang=EN then interface in English.

Similar to the counting above.


188

- Add row NOD=6

NOC=1

Toll-free H 1.1.8-1.1.9

No descriptions: NOT COUNT

I suppose that this function is still not designed in the system.

TOTAL NOD=23 NOC=3 System complexity These forms are independent, EOS = 0.


189


Document source System Requirement Specification, version 2.0, October 25th 2000 Detailed design. Document quality Enough detail Complexity Counting Functional processes Information cues

Conditions remark

Create Access Circuits

record (p.6-7)

Entries: 1 Information from LPAG (CLLIA, bay position, status, protocol, due date, CID, customer, speed) Reads: 2 - customer ID

(query) - port ID (query) Write: 2 - Circuit ID - Access circuit

record Total: 5

Rules to create circuit ID (p.6): 3

- SWITCH_CLLI

- Bay position - NPANXXD

NNN Total: 3

This function is not counted in CFFP [SOL02].

Connection Bulk

creation (p.9-11)

Entry: 1 - Bell path ID Reads: 9 - connection record - segment record - terminal point

record - parameter record - VPI VCI

assignment record. - VPI was used

throughout the PVP connection

- Customer name - Service type - Service description

This function is not counted in CFFP [SOL02].


190

- NCO - ATM service

category. Write: Bulk connection Total: 11

Create connection

record (p.12-13)

Entries: 4 - Bell path Id - Service Id - service

description - Client ID - NCOid Reads: 2 - Order status -

Order action - ALT Write: 1 - Connection record Total: 7

Create segment record

(p.14-15)

Entries: 1 - Circuit ID

Writes: 3 - Segment type - Protocol - FAC_ID

Total: 4

- Rules to assign segment type: 4 (4 segment types)

Total: 4

Create termination

point record (p.16-17)

Entries: 1 - Service cat. Id

Writes: 5 - Segment ID - TP_ordinal - Port ID - Node ID - Protocol ID

Total: 6

- rules for termination point records: 5

Total: 5

Create service

parameter records

Entries: 3 - manufacturer


191

parameter records

(p.18-19)

- protocol - service

read: 1 - parameter and

value from template.

Write: 1 - parameter et

value.

Total: 4 VPIVCIassignment Entries: 1

- terminal point write: 1

- record for VPIVCI

Total: 2

Total 7 39 12

System entropy

Equivalent classes 0-1: {1} 1-1: {6,7} 1-2: {3,4} 1-3: {5} 4-0: {2} EOS = 3/7log(1/7) + 4/7log(2/7) = 0.67


192


Document source - Octopus project ASOC/CRS704/Genval: this document specifies the existing

system, nothing is identified as new function to developed. Therefore, the counting is not based on this document.

- MD & Q2 pricing describes billing rules (first rate) to adjust. There are some new functions to develop.

- Billing BRS/ SRS document describes billing rules (Real & Realplus) to adjust. There are some new functions to develop.

Document quality Not enough detail Complexity Counting Functional processes Information cues


3.2.1 USOC-SAC update (P.8 -Billing)

- Read & show old value

- Entry & Write new value

NOD=2

Suppose that there is a process used to update database, even if the DB is updated using a DBMS.

CBSS update NOD=2 Similar to update USOC

Invoice Preparation - Update legend for Real plus, Real plus extra. - Update images portrait and landscape

- Delete old legend, landscape: count as 1 pt because there is a write on old data.

- Enter new legend and write into database: count 1 pt, because there is a write new data.

NOD=2

Three conditions to show three types of legends + images …

- French - English - Both

NOC=3

Similar to two updates above.

CBSS pricing Pricing Adjustments - Real Plus

- Read customer info. - Write 3 top numbers selected - Read old discount

- Real plus code OK (USOC = realp, Rplus; account based …) - Discount 15%

Suppose that this is a new function of system to convert pricing tables.


193

table. - Write new discount (adjusted) NOD=4

for top 3 numbers - Discount 10% off the rest when 15$ is reached - PIC Bell - eligible calls - 5% additional

NOC=6

Pricing Adjustments - Real Plus Extra

- Read customer info. - Write 3 top numbers selected - Read old discount table. - Write new discount (adjusted) NOD=4

0-14.99 15-39.99 40+ 40% discount 15% discount PIC Bell NOC=6

Removal USOC Realp from CBSS tables (P.16)

- Read pricing table

- Write (delete) the data satisfied the condition

NOD=2

Check condition (USOC=RealP & Rplus, account based, …)

NOC=1

Removal USO XNB from CBSS (P.16)

- Read pricing table

- Write (delete) the data satisfied the condition

NOD=2

Check condition (USOC=XNB, account based, …)

NOC=1

18 17 This counting part is based on MD & Q2 specification

USOC/Sac update NOD=2 Similar to Real & realp


194

CBSS update NOD=2 Pricing adjustments - project Q2 and MD

NOD=9 Each updated rate is counted as one data group.

TOTAL NOD = 31 NOC = 17 This project is not relevant to analyze the system complexity. System complexity: EOS=**


195


Document source System design release 2, version 1.0, October 11th 2000 Document quality Not functional document, not detail enough.

Complexity Counting Functional processes Number of data

groups (Information cues)


3.2.2 Screen windows -program list

R: List of program W: List of program (if add more programs) NOD=2

NOC=0

Next and previous buttons do not add more function

Add new program Counted in 3.2.3 Edit Counted in 3.2.3 Find Counted in 3.2.3 3.2.3 Program definition

Entries - Manager ID- Program ID

Read: - program

options Exit

- program options (send to sever to update)

NOC = 4

NOC=0

Program options can be modified by used and updated therefore Read and Exit refer to two NOD rather than one. SAVE has been counted in Exit NEXT has been counted in Read

DELETE Already counted in 3.2.3

3.2.4 Program level product financial

Entry: - program ID

Read & Show on screen

- channel, volume

Exit (save) - channel,

volume NOC=3

NOC=0

Read and show on screen count as one because, the data group is not modified SAVE: data can be updated by user and sent to serve to save, therefore it must be counted.

3.2.5 Program Entries


196

product financial details 2 Load default attrition rate

- program ID Entry and save

- product - sales,

customers, revenue

- channel, - attrition

rates - promotional

conditions NOD =6 Read & show on screen: rates NOD =1 Total: NOD=7

NOC=0

3.2.6 Reports & data files

Entries - report name

exits: (submit) - report

name, regions

NOD=2

NOC=0

3.2.7 Report/ document - program financial summary

- individual - visual call - simple

connection - total

NOD =4

NOC=0

3.2.8 product level financial summary

- individual - visual call - simple

connection - total

NOD =4

NOC=0

3.2.9 User list Read and show: user list. NOD=1

NOC=0

Next and previous buttons don’t add new function.

3.2.10 Add new user list

Entry and Exit (save) New user NOD=1

3.2.11 segment list NOD =1 NOC=0 Similar to 3.2.9 3.2.12 segment detail - Save

NOD=1

NOC=0

Similar to 3.2.10

DELETE Entry: - Segment ID


197

Write: - segment

details NOD=2

NOC=0

3.2.13 product details Read: - portfolio

code - revenue

type - calc. option

Entry & save - product

info. - Chanel,

volume NOD=5

NOC=0

3.2.14 Revenues Read: - Program,

Revenue Write / exit:

- Revenues summary

NOD=2

NOC=0

3.2.15 Core and non core revenues

NOD=2 NOC=0 Similar to 3.2.14

3.2.16 New RPC report 3.2.17, 18, 19, 20

NOD=2x5=10 NOC=0 Not clear, but suppose that it is similar to 3.2.14

3.2.1 Home page NOD=0 Not counted because it is a home page that that have been already there.

Total NOD=51 NOC=0 Not enough detail for counting EOS, EOS = **.


198


Document source - System specification, version 2.4, July 13th 2000

Document quality Not detail enough Complexity Counting Functional processes Information cues


Monthly LD results reports (p.7)

Entry: - specified

input criteria (p.8)

Read: history data - 3 tables

(p.8) Write and Exit:

- history summary

NOD= 5

Input criteria: summary for business or residence NOC=1

Write the summary and Exit to screen or printer. The Exit data is not modified since they are created. Therefore, “history summary” is counted as 1 pt.

Top Country with history

E: - Criteria - Country - Month

R: history W & X: summary NOD=5

Criteria NOC=1

Families - 1A-7A, 1B Read: - history data

Writes: - summary

file for PACT and PAVG

- SASSUM file

- Text and delimited file

Exit: - telco view

NOC=5

8 conditions to create 8 different reports NOC=8

Master Read - history data

Writes: - Master 01


199

report - DDST

report - Summary

file for PACT and PAVG

- SASSUM Exit:

- telco view NOD = 6

NOC=0

Master 16 4 0 The counting is similar to Master.

Master 54 5 0 As above Master 65 6 0 As above Master 66 4 0 As above Master 70 5 0 As above Calling card-national 5 0 As above Calling card telco 4 0 As above MAPS-national 3 0 As above MAPS-telco 3 0 As above APP-National Not count (not

running)

APP- telco: copy and load APP.

Not count (not running)

NOD=60 NOC=10 System complexity: EOS=**


200


Document source Conceptual system flow, version 1.0, May 22th 2000 Document quality Detail Complexity Counting Functional processes Information cues


3.1.1 Dataload component

Entry: - directory - file

write: - validate file- archive file - update MS-

SQL server - event log

Exit: - confirm to

Oracle Unix.

NOD =7

Event OK Error NOC =2

3.1.2 Update file cleanup

Read: - x number

of days - Archive

directory Write:

- delete old files

NOD = 3

- if older than x days

NOC=2

WEB client Entry: - user code

Exit: - HSE

request Entry:

- HSE request result

Exit: - Show HSE

request result (not count)

NOD = 3

NOC=0


201

HSE Winning Connection Web Site Access - ASP page (web server)

Entry: - User code

Exit: - HSE

qualification request

Entry: - HSE

qualification result

- HSE to Web client (count)

NOD =4

- number valid - service type valid

NOC = 2

IVR APP Entry: - HSE

service request

- Telephone number

Exit: - Send MSG

to MQ Entry:

- Response MSG on the receiver Channel

Exit: - HSE

qualification playback

NOD = 5

NOC =0

MQ series Entry: - request

MSG exit:

- Request MSG

Entry: - TN

qualification result

Exit: - response

MSG NOD =4

NOC =0

MQ series

NOD=5 NOC=0

Read Post Queue NOD=5 NOC=0


202

36 6 System complexity:

Data communication in the system Equivalent classes: In-degree = 0, out-degree = 0: 2 {data load component, cleanup component} In-degree = 1, out-degree = 2: 2 {IVR APP}{Web client} In-degree = 2, out-degree = 2: 5 {data component, Read/post, MQ series, MQ series trigger},{Wining connection ASP page} EOS = -[4/9*LOG(2/9)+5/9*LOG(5/9)] = 0.44


203


Document source Product Specification, version 2.8, March 10th 2000 Document quality Detail Data groups:

- Centrex package - Customer status code - Change field - Order standard (flag) - Critical condition (flag) - Special status code

Complexity Counting Functional processes Information cues


CEI process Entry: - Centrex

package Read:

- customer existing status code

write: - standard status

code - critical

condition - special status

codes - change fields - change

customer status - input into CEI

database exit:

- order to Small Centrex module

NOD = 8

SMCX Entry: - order from CEI

write: - Datafill

generation

NOD=10 NOC=74 (count


204

in the spec.) Not detail enough to count the system complexity, EOS = **


205


Document source

- System Functional design, version 1.1 February 28th 2000 Document quality Detail Complexity Counting Functional processes Information cues

Conditions hypothesis

1. Batch processing

file header processing (p.5)

Entry: - billing

input file Write:

- Trace number

Read: - Billing

CTRtbl Exit: - log error

Check trace #

File processing is described on the first line of diagram on p.5. The process gets an input file, parses the file to extract Trace number, compare this number to that on billing CTRtbl. Billing data sent to parse is not counted here. It is counted as an entry of parsing process.

NOD = 4 NOC=1 1.2 parse data billing file

Entries: - billing data

Write (in temp. file)

- file header - record

details

Parse billing file data box

NOD=3 NOC=0 1.3 load data from temp to billing table

Read: - billing data

(temp. file) Exits:

- account - log error

(not balance)

- log error (not successful)

Write: - billing data

- balance with file trailer

- check if account exits

- check successful


206

(updated, new entry)

NOD= 5 NOC=3

2. Payment input file

2.1 file header processing

Entries: - balancing

batch. - Envelop

inf., - account

inf. Write:

- Trace number

Read: - Billing

CTRtbl Exit: - log error

Check integrity (#trace)

First line in the diagram on p.11

NOD=6 NOC=1 2.2 parse file of BOM Entry:

- payment input file

Exits: - balance file- batch info.

Writes: (not count for NOD)

- update balance,

- batch info (clear)

- Check if file is BOM

- 15 Checks on p.12

NOD=5 NOC=16 2.3 load data from temp to payment table

Read: - billing data

exits:

- account - log error

(not balance)

- log error (not successful)

Writes: - Payment

data - Table

- Check document type = C

- type =D - account

exist? - Successful?


207

cheques - Unmatched

table

NOD=7 NOC=4 2.4 Audit and control table

Entry: - entry in

temp table writes:

- payment batchCtl

- audit feed - payment

control table (trace number)

exit: - log error

- successful?

NOD=5 NOC=1 3. extract file Entry:

- payment history data

exists: - two payment files (BIP, unmatched)

NOD=3 NOC=0 3. report 4.1 sorting (p.22)

NOD=2 (in, put)

4.2 exporting (p.22) NOD=2 (in, put) 4.3 Audit and control report (p.25)

NOD=2

4.4 audit and control monthly report

NOD=2

4.5 daily report NOD=2 4.6 unmatched report NOD=2 Unmatched monthly report

NOD=2

Unmatched daily report

NOD=2

Total 54 26


208

System complexity: (preference to the diagram on p.5, p.11 and p. 21.

classification: 0 in, 1 out: 2 processes 1 in, 1 out: 2 processes 2 in, 11 out: 2 processes 1 in, 0 out: 10 processes Entropy of system= -(1/8*LOG(1/8,2) + 1/8*LOG(1/8,2) + 1/8*LOG(1/8,2) + 5/8*LOG(5/8,2)) = 0.48


209

12. Case study 12: project P7

Document source - System Specification, version 1.4.

Document quality In this project, we count the complexity of modified functions (M*) or new functions (NP). Removal function (R*) and testing (T) are not counted. Complexity Counting

FUNCTION / HIGH LEVEL PROCESS

SUBPROCESS Platform IMPACT NOD NOC

1. Reformat 1.1 Pre-reformat processing

MF RJ, RP *

1.2 Monthly Reformat processing

MF RJ, MJ, RP

Read and write data in a new format Count as one data group NOD=2

NOC=0

1.2.1 Create Trans PC files for next month feed

MF MP Read and write data NOD=2

NOC=0

1.2.2 Datapac monthly processing

MF MP NOD=2

2. Update 2.1 Monthly update processing

2.1.1 Generate current month universal files

MF RJ, MJ NOD=2

2.1.2 Process monthly Concert data feed

MF MP NOD=2

2.1.3 VNET and CVNS monthly update process

MF RJ, MJ NOD=2

2.1.4 Generate Call Plan and Generic Revenue reports

MF RJ, MJ Read: data input Write

- Call plan

- Revenue report

NOD=3

2.1.5 Download universals (CL0x) files to DW

MF/DW RJ, MJ Entry and write the same data NOD=1

2.1.6 Download Signature Trans38 to DW

MF/DW MJ NOD=1

2.1.7 Monthly load of universals (CL0x)

DW MOP Entry and write the same data NOD=1

3. Customer Grouping / CPC

3. 1 CPC Interface 3.1 Customer Grouping Weekly

3.1.1 Process weekly input from CPC

MF MP Read data and write a report NOD=2

3.1.1.1 Apply Telus Filter on Account input from CPC

MF MP - Entry: account input

- Read data

- Write


210

data after filtering

NOD=3

3.1.1.2 Process Customer input from CPC

MF T *

3.1.2 Process monthly input from CPC

MF MP NOD=2

3.2 Customer Build 3..2.1 Build Customer Grouping extract files for download to DW (account.txt, customer.txt)

MF MP Write account Write customer NOD=2

3.2.2 Download Customer Grouping extract files.

MF/DW MP NOD=1

3..2 .3 Load Customer table

DW T *

3..2 .4 Update Customer table

DW T *

3..2 .5 Customer Table Conversion - Re-assign Telco Prime

DW NP Read old value Write new conversion NOD=2

3.3 View Customer Data

3..3 Customer Customized Screens and Reports

NAV MP Read and write customized:

- Screen - Report

NOD=2

3..3.1 Customer Selection screen

NAV NI 0

3..3.2 Customer Hierarchy screen

NAV MP Modify to create a hierarchy screen NOD=1

3..3.3 Customer drill down screens & reports

NAV NI 0

3..3.4 Customer PIC Loss Report

NAV MP Read and exit (report) the same data group NOD=1

4. PIC 4.1 PIC Daily Processing

4.1 PIC Daily Processing MF RJ *

4.1.1 Process daily PIC/CARE input transaction files

MF RJ *

4.1.2 Split Toll PIC / Local PIC data

MF NI 0

4.1.3 Transmit daily WOR file to Telcos

MF RJ *

4.2 Toll PIC Weekly Processing

4.2 Toll PIC Weekly Processing

4.2.2 Build PIC Transaction Summary (PTS)

MF RJ , MJ Read and write a summary NOD=2

4.2.3 Download PTS extract file

MF / DW RJ *

4.2.4 Load PTS table extract file

DW MOP NOD=1

4.3 Toll PIC Monthly Processing

4.3 Toll PIC Monthly Processing

NOD=2

4.3.1 Toll WTN Master Month end update

MF RJ *

4.3.2 Create Toll WTN Master extracts (split into Bus / Res and Matched /

MF RJ *


211

Unmatched 4.3.3 Download WTN

Master Extracts MF/DW RJ *

4.3.4 Load WTN Master Matched tables

DW MOP NOD=1

4.3.5 DQ WTN Master Matched table loads

DW RJ *

4.3.6 Load WTN Master Unmatched tables

DW MOP NOD=1

4.3.7 DQ WTN Master Unmatched table loads

DW RJ *

4.3.8 Toll Equal Access Month end Update

MF RJ *

4.3.9 Build EA extract for Pic’d accounts

MF RJ *

4.3.9 Download EA Extract

MF/DW RJ *

4.3.2 Load Toll EA Table DW MOP NOD=1 4.4 View PIC Data 4.4 Toll PIC Navigator

Reporting

4.4.1 Toll PIC Transaction Summary Reporting

NAV MP Read and write a summary NOD=2

4.4.2 Toll PIC Account Loss Summary Reporting

NAV MP NOD=2

5. Sales 5. 1 Sales Territory 5.1.1 Process Telco

monthly input MF MJ MOD=2

5.1.2 Build Sales extract for download to DW

MF MJ MOD=2

5.1.3 Download Sales extract file

MF/DW RJ, MJ NOD=1

5.1.4 Load Sales table DW MOP NOD=1 5. 2 National Sales Directory

5.2.1 Summarize Sales input

MF MJ NOD=1

5.2.2 Download NSD extract file

MF/DW T *

5.2.3 Load NSD Customer Sales and Sales Profile tables

DW MOP NSD customer slaes Selaes profile NOD=2

5.2.4 Update NSD tables - Remove Telus Records (one time conversion)

DW NP Read: data Conersion and update: data NOD=2

5.3 View National Sales Data

5.3 NSD Customized Screen & Reporting

NAV T *

6. CDMA 6.1 CDMA monthly processing

MF MJ NOD=2

7. Calling Card 7.1 Process Calling Card monthly input data

MF MP NOD=2

7.2 Download Calling Card extract file

MF/DW T *

7.3 Load Calling Card Telco tables

DW MOP NOD=1

7.4 Load Calling Card National table

DW MP NOD=1

7.5 Convert Calling Card history (remove Telus data)

DW NP NOD=2

7.6 Calling Card Customized Screen and Reporting

NAV Read data and write Screen and reporting NOD=2

7.6.1 Calling Card Telco NAV T *


212

specific views 7.6.1 Calling Card

National Views NAV MP NOD=2

8. SIC 8.1 SIC Monthly Processing??? Bell only???

MF MJ???

9. Call Detail 9.1 Call Detail monthly processing

MF MJ NOD=2

9.2 Download Call Detail extract file

MF/DW NI *

9.3 Load Call Detail tables DW MOP NOD=1 9. 800 Service 9.1 800 Service Monthly

Processing MF RJ , MJ NOD=2

10. Downstream Interfaces

10.1 Advantage Toll Free

10.1 Advantage Toll Free interface monthly processing

MF O/S Scope NOD=2

10.2 CDC 10.2 CDC interface monthly processing

MF MI NOD=2

10.3 CND National 10.2 CND National interface monthly processing

MF MI NOD=2

10.4 Resporg 10.3 Resporg weekly / monthly processing

10.3.1 Process input from SMS

MF MP NOD=2

10.3.2 Generate output for external interface

MF MI Read and write in a new format for external interface NOD=2

10.3.3 Transmit output to external interface

MF NI *

10.5 SHOCS 10.4 SHOCS monthly processing

NOD=2

10.4.1 Extract Toll Detail and PIC Status

MF MI Read data Extract (write)

- toll detail

- PIC status

NOD=3

10.4.2 Summarize data for all Telcos

MF MI Read and summary NOD=2

10.4.3 Transmit output to external interface

MF NI *

10.6 Sales Management System

10.5 SMS monthly processing

MF MI NOD=2

10.7 XWAVE Solutions

10.6 XWAVE Solutions (MTT Interface)

10.6.1 Extract PIC WTN Master data

MF MI Read and write (new) NOD=2

10.6.2 Transmit output to external interface (MTT)

MF NI *

10.8 Customer Grouping

10.7 Weekly Customer Grouping Extract for Telus

10.7.1 Extract and transmit Customer and Account data to Telus

MF RI *

10.9 TIC 10.8 Monthly TIC Extract 10.7.1 Extract and

transmit TIC file to Telus MF RI *

11. Data Warehouse Monthly Loads

11.1 Monthly Startup load script

DW MP NOD=1

11.2 Monthly Load


213

Sequence 11.2.1 Load MSC, NSB

ref tables (Telco specific) DW MOP NOD=2

11.2.2 Load account profile table (Telco specific)

DW MOP NOD=1

11.2.3 Load account detail tables (Telco specific)

DW MOP NOD=1

11.2.4 Load account summary tables (Telco specific)

DW MOP NOD=1

11.2.5 Load account summary tables (national)

DW MP NOD=1

11.2.1 Load Cust Acct Xref table

DW MP NOD=1

11.2.6 Load Customer level summary tables

DW MOP NOD=1

11.3 DQ Table Loads DW MP NOD=1 11.4 Monthly Navigator

Cutover load script DW MP NOD=1

NOD=106

System complexity EOS = * *


214


Document source System Design Specification, version 3.1, august 7th 2000 Document quality Not enough detail Complexity Counting Functional processes Information cues

Conditions Hypothesis -remark

Receive and record data on current status, location and changes

Entry: - External

Event (from CALRS, FSOS, LEGOS)

Writes - Centracs

event - Text logs

Reads - create time - pickup time- referral

time - close time - finalize

time Exit /write:

- stamped status

NOD = 9

NOC = 0

Align status between CENTRACS and all associated downstream systems: TLOG and FLOG

Entry: - status

criteria Write:

- status of filtering tickets

Exits: - status of

filtering ticket to real tine control.

This is a modified function not be counted in the report of Solange.


215

NOD = 3 NOC=0 Search facility on TLOG

Entry: - filter

criteria read

- text file write:

- push/pull files on a scheduled and on demand basis.

exit: - filtered

events NOD = 4

NOC = 0

Receive PVC data Populate to PVC data: Entry:

- Data from SODB

Entry: - Data from

alternate sources (???)

Write: - write data

to PVC database

Exits: - to high

speed page - feed back

to SODB. NOD = 5

NOC = 0


216

Code a data exchange interface in OARS (p.18): read:

- PVC data write:

- Data coding

Exit: - data coding

to Centracs NOD =3 x 6 protocols = 18

If data need on-the -wire encryption NOC = 1

1 process to code data has 1 entry or read one write the encoded data and one exit. There are 6 protocols, therefore the complexity is 3 x 6. *Not counted by Solange.

Code a data exchange interface in CENTRACS: read:

- PVC data write:

- Data coding

Exit: - data coding

to PVC NOD =3 x 6 protocoles = 18

NOC =1

As above *Not counted by Solange.

Identification of appointment time

Read: - time stamp - read MLR

type exit:

- appointment time

NOD =3

- 48 hrs time stamp

- MLRT = ADP

NOC =2

* Not counted by Solange.

Input multiple “deferral time value”

Entry - selected

time value read:

- data from CENTRAC database

Write: - deferral

time value - update

MTTR exit:


217

- to update Deferral Maintennace in FOCUS

- to show on screen

- Categorization events

- NAT - DMT - ACS - WFR - NA - DM

NOD = 15

NOC = 0

Pass Bay, Slot and Shelf …

Entry: - bay, slot

and shelf from SODB

- Cable pairs - OE change

Read: 1 - bay, slot

and shelf from CENTRACS

Write: 1 - bay, slot

and shelf from SODB \ CENTRACS

Exit: - show data

on screen (not count)

NOD = 5

NOC = 0

Populate access time Entry - customer

access time write:

- access time to text logs

exit: - access time

to CALRS


218

downstream

NOD = 3

NOC =0

Pass CENTRACS and DSSC resolution

Entry - Resolution

codes Write:

- resolusion codes (modify)

Exits: - code

translated - 2 err. msg

NOD = 5

NOC =0

Support forecasted number of service records

Enhancement, not development of new functions This part needs 15 person - days.

NOT COUNTED

Pass deferred time details from CENTRACS to FOCUS

Read: - Deferred

time Write

- total deferred time (modify)

Exit: - Pass

Deferred time to FOCUS

- Total deferred time

NOD = 4

NOC = 0

Populate work force Entry: - WFR

(DSSC user or external update)

Write: - WFR

(record) Exit

- WFR (to CALRS)


219

NOD = 3 NOC =0 Identify modem type Entry:

- data from USOC

write & Exit: - modem

type exit:

- modem type (not count)

NOD =2

NOC =0

Indentify and adresse premium USOC

Entry: - USOC data

Read - scan USOC

write: - MLR type

Exit: - show

USOC NOD =4

NOC =0

Simply customer records

Enhancement part This part need 20 person days

NOT COUNTED

Expand TTI to encompass TTS

Enhancement part 95 person-days

NOT COUNTED

Create a ADSL network trouble report

Entry: - Network

trouble request

Read: - network

trouble in CENTRACS

Write: - Network

trouble report

- modify of user

Exit: - TTS server

log update (Err. Msg or audit)

- Show on screen fro user

- If the transmission is successful

- If unsuccessful


220

NOD =6 NOC = 2 Pass ADSL network trouble report updates to CENTRACS

Entry - trouble

report Write:

- troupe report

- update log file

NOD =3

NOC= 0

Pass ADSL network trouble report to COPS-TM via CENTRACS

Entry - trouble

report Write:

- troupe report

- update log file

NOD =3

- update or not NOC=2

Pass ADSL network trouble report updates to FOCUS via CENTRACS

Entry - trouble

report Write:

- troupe report

- update log file

NOD =3

NOC=0

Total: 14.4 man-month

NOD=116 NOC =8

Cannot count the EOS EOS=**


221


Document source - System Design, version 2.0, March 6th 2001

Document quality Detail Complexity Counting Functional processes Information cues


Forms: volunteer Grant Request & Census (client)

Entries: - User

profile - action code

Exit: - request to

server

There 2 forms: - Grant

Request - Census

2 forms have the same pts, including 2 entries and one exit.

NOD=3 x 2 forms = 6

NOC=0

Forms: volunteer Grant Request & Census (server)

Enties: - submitted

parameters Read:

- database Write:

- user profile (update)

Exit: - request

results - email

Action code: A, C, P, S

Two server scripts to manipulate forms parameters submitted. Read database to search user profile Write to database in case add, delete or update user profile

NOD=5x 2 forms =10

NOC=4 x 2 forms = 8

List of participant (client) - add / delete / update

Entry: - user profile

Exit: - request to

server - request

results (audit or error msg)

NOD=3 NOC=0 List of participant Entries: select an action:


222

(server) - add / delete / update

- user profiles submitted

- action Write:

- user profile Exit:

- feed back to client side.

add, delete or update

NOD=4 NOC=3 Authentification client side

Entries: - PEIN - Audit/

error msg Exit: PEIN (not count)

NOD=2 NOC=0 Authentification LDAP

Entry: PEIN Read: LDAP Exit: audit yes/ no

Check if PEIN is correct

NOD=3 NOC=1 Email delivery Entry:

- empl. Info. Exit:

- email to client

NOD=2 NOC=0 PART 2.2.1.1.5 THIS IS A

SOLUTION. It is counted below

PART 2.2.1.2 Entry: - parameters

describe object

exit: - object

Not clear to count But suppose that to create an object the process will receive some parameters and stretch out the object.

NOD=2 NOC=0 2.2.2.1 is not a functional description

Opening a form Entry: - form

record (user profile)

Read - lockinfo

Lockinfo=’’ Lockinfo # user ID


223

Write: - Lockinfo

Exit: - error

NOD=4 NOC=2 Saving form Entry:

- form record (user profile)

Read - timestamp

(in memory)

Write: - lockinfo - form

record Exit:

- error

Check time stamp

NOD=4 NOC=1 Closing form Entry:

- form record

read: - lockinfo - user ID

write: - lockinfo

(update)

Lockinfo=user

NOD=4 NOC=1 2.2.2.4 Generation of .DOC and .XLS

Entry: type of document (DOC or XLS …) Read: reported data Exit: a document

7 conditions respecting to 7 types of document.

NOD= 3 NOC = 7 2.2.3 user defined reports

CANNOT COUNT

This part counts for the section 2.2.1.1.5

THIS PART IS A LOW LEVEL OF THE SOLUTION. - IT IS NOT THE SAME ABSTRACTION LEVEL WITH OTHER PARTS.

Search charity Orgs Entry: - search

parameters

- check parameters input (non


224

Read: - Database

Exit: - request result - msg error

blank) - check if

operation is success

NOD=4 NOC=2 Search profile Entry:

- search parameters

Read: - Empl. Profile - Read LDAP

Exit: - request result

msg error

- Check vntEmpNumber (contain PEIN) - Check if the operation is success

NOD=5 NOC=2 Search Grant Reqs Entry:

- search parameters

Read: - Database

Exit: - request result - msg error

- check parameters input (non blank)

- check if operation is success

NOD=4 NOC=2 Create Grant Req Entry & write: 3

groups in 3 record sets:

- volunteer Grant Req form fields

- list of Bell participant

- list of other participants

Exit: - output value

- ten conditions respecting to 10 output values

- check vntParticipant (at least one row)

NOD=4 NOC=11 Create a empty record set & new record set

Read: 3 tables - structure of

table write: 3

- record set structure

exit: - operation

result (0,1)

Check if the operation is success


225

NOD=7 NOC=1 71 41 System complexity:

Hypothesizes:

ActiveX component is a module at low level that offers the services for higher level. It is a library, therefore the application on the higher level call it as a black box with 1 entry and one exit (return value). We suppose that Volunteer Grant req., Census form, list participants (add, update, delete) have a one-one relation with ActiveX. That means, each application calls ActiveX then receives a result.

Classes: 0 in - 0 out: 1 process: generate reports 1 in - 1 out: 5 processes: Volunteer GR client, census form client, list of part. client, authentification client, authentification server. 2 in - 0 out: 1 process: email. 2 in - 3 out: 2 processes: Volunteer GR server, census form server 2 in - 2 out: 1 processes: list of participants server, 3 in - 3 out: 1 process: Activex EOS = 0.68


226


Document source

- System Specification, version 1.20, May 16th 2000 - Product requirement document, version 2.3, May 12th 2000.

Document quality Not enough detail. Complexity Counting Functional processes Number of data groups

(Information cues)


Load_merlin: Import data from Merlin

- R: merlin_location

- R: telco NOD =2

NOC = 0

Import without modifying data.

Load_location Load locations from some where

- R: locations - R:

hist_locations NOD = 2

NOC = 0

Read Locations without modifying this data group.

Update_from_merlin Update data from Merlin

- W:locations - W: merlin

locations NOD = 2

NOC = 1

It is similar to import data from Merlin, but there is at least one condition to decide that is an Update or a Delete.

Frames (p.17-18) NOD = 49 (Counted directly in the document)

NOC = 0 o Each frame is as a SQL request.

o An R is count as a data group.

o An U is counted as one data group.

Screen 00 NOD=1 NOC=0 It just a minor modifying to show the last image update date. No change in requirement is marked in the specification.

Screen 03 - Retrieve and show: information for region.

NOD = 1

No modify the retrieval date


227

Screen 04 - add Region profile

NOD=0

NOC=0

add a third choice is a screen design so it is not count as a function.

Screen 06 - Read: USER

ID. - Read USER

audit. - Read and

show: list of host (from IPS-TDS table)

- Write: switch CLLIs and remotes

NOD=4

o If telbec user.

o If the telebec has a groups permission

NOC = 2

Screen 21 Screen design: not count

Screen 86, 91, 99 E: user ID R:

- list of Telebec host

- list of common hosts

NOD = 3

Verify: if a Telbec user NOC=1

Modify to show only Telbec host and CLLI common host for Telbec user The same function one of these three screens is counted.

Screen 67 Entry: - user id

Read: - list of host

Telebec - list of common

hosts. Exit:

- error msg when accessing to screen 111.

- error msg when accessing to screen 120.

NOD = 5

If (user = telebec) If (user = telebec) and (hosts<>telebec host) If (lang=French) then show msg in french. NOD =3.

Screen 77 Entry: - user ID

Read: - list of

If Telbec user


228

components and qualifiers

- list of CLLI NOD = 3

NOC=1

Screen 75,81,83 The same as screen 77: not count

Screen 76 Entry - user ID

Read - component

pick list - remote CLLI - New

component list

NOD = 4

If (ID=telebec) then ownership = telebec If (ID=bell) then ownership=bell. NOC = 2

Screen 101 Read & Exit - new qualifier

NOD = 2

NOC =0

Tag change when changing qualifier name: one entry and one exit

Screen 22 Read & exit - ownership

NOD=2

NOC=0

Tag change when changing CLLI


Reads: - components - qualifiers

NOD = 3

If Telbec user NOC=1

Screen 87 Entry: - User ID - CLLI

Reads: - components - qualifiers - telebec hosts - common hosts

NOD = 6

If Telbec user If (pick CLLI==1) NOC=2


Reads: - CLLI - Components - Qualifiers

NOD = 4

If telbec user NOC=1


If Telbec user


229

- component selected

read: - qualifiers

NOD = 3

NOC=1

Screen 53 The same as 88: not count

Screen 111 Entry - user ID

Read: - CLLI

Write - Add new

telbec CLLI NOD = 3

If Telbec user NOC=1

Report 84 Entry - user ID

Reads: - telbec host - common hosts - components - qualifiers

NOD = 5


Report 89 Same as report 84

Not count

Report 90 Entries - user ID - CLLI selected

Read: - telbec hosts

NOD = 3

If telbec host NOC=1

Report 94, 96,97,98 Similar to 90

NOD = 3 NOC=1 Count only one time for 4 reports because they are essentially the same.

Report 118 Entry - user ID

Read - telbec hosts

NOD = 2


Screen 36 Screen design: not count

Screen 122 The same as 118

Not count

Screen 123, 124 Entry - user ID

Read - CLLIhosts

If Telbec user If Bell user


230

NOD = 2 NOC=2 Screen 07 Entry

- user ID Reads:

- telbec hosts - remote CLLI - error msg

Write: - number of

access NOD =5

If (first access)

If (user =telebec) and (lick on report) NOC = 2

Screen 37 Not count TOTAL 119 24 System complexity:

- All screen share the same database with the following model:

There is no send-receive data from one screen to other, therefore these screens are independent: EOS = 0.

MESURE DE LA COMPLEXITÉ FONCTIONNELLE DES LOGICIELS - UQAM · Je tiens à remercier profondément...

Documents

Transcript of MESURE DE LA COMPLEXITÉ FONCTIONNELLE DES LOGICIELS - UQAM · Je tiens à remercier profondément...