Post on 15-Mar-2020
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
3. Case study 3: Project P21........................................................................ 186
4. Case study 4: Project P20........................................................................ 187
5. Case study 5: Project P2.......................................................................... 189
6. Case study 6: Project P18........................................................................ 192
7. Case study 7: Project P11........................................................................ 195
8. Case study 8: Project P13........................................................................ 198
9. Case study 9: Project P8.......................................................................... 200
10. Case study 10: Project P9.................................................................... 203
11. Case study 11: Project P14.................................................................. 205
12. Case study 12: project P7.................................................................... 209
13. Case study 13: Project P3.................................................................... 214
14. Case study 14: Project P26.................................................................. 221
15. Case study 15: Project P1.................................................................... 226
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
Tableau 6.4: Influence de chaque variable dans la régression multiple entre
l’effort et CFFP, NOD et NOC. .................................................. 151
Tableau 6.5: Comparaison de la performance des modèles (2) et (3).............. 152
xi
Tableau 6.6: Influence de chaque variable dans la régression multiple entre
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
Complexité et mesure de la complexité du logiciel
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.
Complexité et mesure de la complexité du logiciel
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
Complexité et mesure de la complexité du logiciel
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.
Complexité et mesure de la complexité du logiciel
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)
Complexité et mesure de la complexité du logiciel
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
Complexité et mesure de la complexité du logiciel
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.
Complexité et mesure de la complexité du logiciel
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
Complexité et mesure de la complexité du logiciel
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é.
Complexité et mesure de la complexité du logiciel
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.
Complexité et mesure de la complexité du logiciel
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
Complexité et mesure de la complexité du logiciel
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:
Complexité et mesure de la complexité du logiciel
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.
Complexité et mesure de la complexité du logiciel
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
Complexité et mesure de la complexité du logiciel
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)
Complexité et mesure de la complexité du logiciel
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é.
Complexité et mesure de la complexité du logiciel
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
Complexité et mesure de la complexité du logiciel
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.
Complexité et mesure de la complexité du logiciel
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).
Complexité et mesure de la complexité du logiciel
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.
Complexité et mesure de la complexité du logiciel
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).
Mesures basées sur le code source et la conception du programme
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
Mesures basées sur le code source et la conception du programme
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 '&
Mesures basées sur le code source et la conception du programme
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
Mesures basées sur le code source et la conception du programme
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].
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception 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.
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception du programme
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é.
Mesures basées sur le code source et la conception du programme
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
Mesures basées sur le code source et la conception du programme
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
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception du programme
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? ».
Mesures basées sur le code source et la conception du programme
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.
Mesures basées sur le code source et la conception du programme
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
développement du logiciel.
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].
Mesure de points de fonction
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,
Mesure de points de fonction
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)
Mesure de points de fonction
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.
Mesure de points de fonction
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)
Mesure de points de fonction
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.
Mesure de points de fonction
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
développement du logiciel.
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.
Mesure de points de fonction
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).
Mesure de points de fonction
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
Mesure de points de fonction
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.
Mesure de points de fonction
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.
Mesure de points de fonction
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
Mesure de points de fonction
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.
Mesure de points de fonction
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
Mesure de points de fonction
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).
Mesure de points de fonction
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.
Mesure 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
Mesure de points de fonction
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.
Mesure de points de fonction
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].
Mesure de points de fonction
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)
Mesure de points de fonction
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):
Mesure de points de fonction
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.
Mesure de points de fonction
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.
Mesure de points de fonction
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.
Mesure de points de fonction
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,
Mesure de points de fonction
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
Modèle de la complexité de la tâche
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
Modèle de la complexité de la tâche
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
Modèle de la complexité de la tâche
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.
Modèle de la complexité de la tâche
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.
Modèle de la complexité de la tâche
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-
Modèle de la complexité de la tâche
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].
Modèle de la complexité de la tâche
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:
Modèle de la complexité de la tâche
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.
Modèle de la complexité de la tâche
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).
Modèle de la complexité de la tâche
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
Modèle de la complexité de la tâche
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.
Modèle de la complexité de la tâche
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.
Modèle de la complexité de la tâche
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
Modèle de la complexité de la tâche
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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 à
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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).
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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%
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle 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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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 à
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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é.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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).
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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 à
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
conditions qui correspondent à deux sorties différentes:
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
conditions qui correspondent à deux sorties différentes:
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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.
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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
Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel
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)
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
Investigation empirique et validation des mesures de la complexité fonctionnelle
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):
Investigation empirique et validation des mesures de la complexité fonctionnelle
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).
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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-
Investigation empirique et validation des mesures de la complexité fonctionnelle
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é
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
l’effort de développement du logiciel.
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
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
développement du logiciel.
!" 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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
Probabilité d’hypothèse nulle (p-value)
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
Investigation empirique et validation des mesures de la complexité fonctionnelle
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%
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
Probabilité d’hypothèse nulle (p-value)
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)
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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:
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
Investigation empirique et validation des mesures de la complexité fonctionnelle
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
l’effort de développement du logiciel.
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
Investigation empirique et validation des mesures de la complexité fonctionnelle
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.
89. IFPUG (International Function Point Users Group), Function Point Counting Practices Manual, Release 2.0, Westerville, Ohio, April 1988.
90. IFPUG (International Function Point Users Group), Function Point Counting Practices Manual, Release 4.1, Westerville, Ohio, April 1998.
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
Rapport de comptage de 15 projets
185
2. Case study 2: Project P17
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)
Rapport de comptage de 15 projets
186
3. Case study 3: Project P21
The specification of this project is lost. Reuse the counting in [148]: NOD = CFFP. NOC = 0. EOS = **.
Rapport de comptage de 15 projets
187
4. Case study 4: Project P20
Document source System Design, version 1.0, November 21st 2000 Document quality Detail Complexity Counting Functional processes Information cues
Conditions Hypothesis
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.
Rapport de comptage de 15 projets
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.
Rapport de comptage de 15 projets
189
5. Case study 5: Project P2
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].
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
192
6. Case study 6: Project P18
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
Conditions Hypothesis
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.
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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=**
Rapport de comptage de 15 projets
195
7. Case study 7: Project P11
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)
Conditions Hypothesis
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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 = **.
Rapport de comptage de 15 projets
198
8. Case study 8: Project P13
Document source - System specification, version 2.4, July 13th 2000
Document quality Not detail enough Complexity Counting Functional processes Information cues
Conditions Hypothesis
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
Rapport de comptage de 15 projets
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=**
Rapport de comptage de 15 projets
200
9. Case study 9: Project P8
Document source Conceptual system flow, version 1.0, May 22th 2000 Document quality Detail Complexity Counting Functional processes Information cues
Conditions Hypothesis
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
203
10. Case study 10: Project P9
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
Conditions Hypothesis
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
Rapport de comptage de 15 projets
204
in the spec.) Not detail enough to count the system complexity, EOS = **
Rapport de comptage de 15 projets
205
11. Case study 11: Project P14
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
Rapport de comptage de 15 projets
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?
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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 *
Rapport de comptage de 15 projets
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 *
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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 = * *
Rapport de comptage de 15 projets
214
13. Case study 13: Project P3
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.
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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:
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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)
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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=**
Rapport de comptage de 15 projets
221
14. Case study 14: Project P26
Document source - System Design, version 2.0, March 6th 2001
Document quality Detail Complexity Counting Functional processes Information cues
Conditions Hypothesis
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:
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
226
15. Case study 15: Project P1
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)
Conditions Hypothesis
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
Rapport de comptage de 15 projets
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
Rapport de comptage de 15 projets
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
Screen 110 Entry: - user ID
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
Screen 70 Entry: - user ID
Reads: - CLLI - Components - Qualifiers
NOD = 4
If telbec user NOC=1
Screen 88 Entry: - user ID
If Telbec user
Rapport de comptage de 15 projets
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
If telbec user NOC=1
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
If telbec user NOC=1
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
Rapport de comptage de 15 projets
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.