MESURE DE LA COMPLEXITÉ FONCTIONNELLE DES LOGICIELS

Transcription

1 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

2 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, exdirecteur 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!

3 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 Concept de la complexité du logiciel Objectif de la thèse Organisation de la thèse Problématique de recherche et démarches... 8 CHAPITRE 1 COMPLEXITÉ ET MESURE DE LA COMPLEXITÉ DU LOGICIEL Concepts utilisés dans la thèse Logiciel Génie logiciel Mesure du logiciel Complexité Effort de développement du logiciel Définitions de la complexité Approche des systèmes complexes Approche computationnelle Complexité du logiciel Notion de la complexité du logiciel Définitions de la complexité du logiciel Deux aspects de la complexité du logiciel Catégorisations des mesures de la complexité du logiciel... 28

4 iv 1.4 Résumé CHAPITRE 2 MESURES BASÉES SUR LE CODE SOURCE ET LA CONCEPTION DU PROGRAMME Mesures de la taille du programme Mesure de lignes de code Science du logiciel de Halstead Mesures de la structure des programmes Mesure de McCabe Mesure de Henry et Kafura Couplage et cohésion Mesures de la compréhensibilité du programme Explication de la complexité au point de vue psychologique Résultats principaux concernant l architecture de l esprit humain Explication de la complexité Résumé CHAPITRE 3 MESURES DE POINTS DE FONCTION Analyse de points de fonction (Function Points Analysis FPA) Concept de point de fonction (PF) Mesure de points de fonction Structure de FPA Limites majeures de FPA Variantes de la méthode de points de fonction Mark-II Feature Points Asset-R Points de fonction 3D (3D Function points) COSMIC-FFP Cadre général de la complexité des méthodes de points de fonction Utilisation des points de fonction Productivité Estimation d effort... 73

5 v 3.5 Problématique de recherche Cadre d analyse de la complexité fonctionnelle Problème d évaluer la complexité Résumé CHAPITRE 4 MODÈLE DE LA COMPLEXITÉ DE LA TÂCHE Complexité de la tâche Modèle de la complexité de la tâche de Wood Complexité des composants Complexité de coordination Complexité dynamique Complexité totale de tâche Remarques sur le modèle de la complexité de la tâche Quelques modèles de la complexité du logiciel basés sur la complexité de la tâche Mesure de la complexité de maintenance Mesure de la complexité de la conception Résumé CHAPITRE 5 NOUVELLE MÉTHODE DE MESURE DE LA COMPLEXITÉ FONCTIONNELLE DU LOGICIEL Modélisation du logiciel Modèle conceptuel du logiciel Modèle fonctionnel du logiciel de COSMIC Modèle fonctionnel du logiciel proposé pour mesurer la complexité Mesures de la complexité du logiciel Logiciel analysé comme une tâche Complexité fonctionnelle analysée comme la complexité de la tâche Cadre de la complexité fonctionnelle Mesure de la complexité de données entrées/sorties Mesure de la complexité structurelle des composants

6 vi Mesure de la complexité du système Résumé des mesures proposées pour mesurer la complexité du logiciel Étude de cas Spécification de l application Comptage de la complexité du Cuiseur de riz Résumé CHAPITRE 6 INVESTIGATION EMPIRIQUE ET VALIDATION DES MESURES DE LA COMPLEXITÉ FONCTIONNELLE Concept de validation de la mesure Validation d une mesure Validation d un système de prédiction Problèmes de validation d une mesure Processus développement d une méthode de mesure Validation du processus de développement d une méthode de mesure Validations des mesures proposées dans cette thèse Validation de la conception de la méthode de mesure Expérimentation sur les mesures de la complexité fonctionnelle proposées Résumé CONCLUSION Cadre de la complexité fonctionnelle Problème d évaluation de la complexité Problème de la validation de la méthode Conformité à la théorie de la mesure Problème d estimation d effort Perspectives futures de recherche Exploitation de la mesure Automatisation de la mesure BIBLIOGRAPHIE

7 vii ANNEXE 1 PUBLICATIONS ANNEXE 2 RAPPORT DE COMPTAGE DE 15 PROJETS Case study 1: Project P Case study 2: Project P Case study 3: Project P Case study 4: Project P Case study 5: Project P Case study 6: Project P Case study 7: Project P Case study 8: Project P Case study 9: Project P Case study 10: Project P Case study 11: Project P Case study 12: project P Case study 13: Project P Case study 14: Project P Case study 15: Project P

8 LISTE DES FIGURES Figure 2.1: Exemple d un graphe de flux (flowgraph) Figure 2.2: Exemple de fan-in et fan-out Figure 2.3: Graphe G Figure 2.4: a) Entropie=0. b) Entropie atteint la valeur maximale pour un graphe de 5 nœuds (H=log5) Figure 3.1: Modèle global de la méthode de points de fonction (FPA) Figure 3.2: Modèle du logiciel de COSMIC Figure 3.3: Quatre types de mouvement de données de COSMIC Figure 3.4: Cadre général de la complexité basée sur les méthodes de points de fonction Figure 4.1: Modèle de la tâche [177] Figure 4.2: Modèle de la complexité de la tâche de Wood Figure 5.1: Exemple d un diagramme de flux et de ses niveaux d abstraction différents Figure 5.2: a) Montre numérique b) Diagramme d état de la montre numérique Figure 5.3: Modèle fonctionnel du logiciel Figure 5.4: Modèle d un processus fonctionnel de COSMIC Figure 5.5: Modèle fonctionnel du logiciel caractérisant la manipulation de données d un processus fonctionnel Figure 5.6: Modélisation de manipulation de données 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 Figure 5.8: Modèle de la complexité de la tâche Figure 5.9: Modèle de la complexité du logiciel Figure 5.10: Comptage la taille fonctionnelle de deux processus A et B

9 ix Figure 5.11: Exemple d un graphe représentant la relation de données entre les processus Figure 5.12: Panneau de contrôle du Cuiseur de Riz Figure 5.13: Température cible par mode Figure 5.14: Architecture du Cuiseur de riz Figure 5.15: Graphe représentant les dépendances de données entre les processus fonctionnels du Cuiseur de riz Figure 6.1: Processus de mesure [93] Figure 6.2a: Modèle détaillé du processus de mesure [93] Figure 6.2b: Trois types de validation d une méthode de mesure Figure 6.3: Qualité de la documentation pour identifier les concepts de mesure de COSMIC [151] Figure 6.4a: 15 projets ayant un effort inférieur de 24 homme-mois Figure 6.4b: 10 projets ayant un effort supérieur à 24 homme-mois Figure 6.5 : Deux groupes des projets séparés 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 Figure 6.8: Analyse de performance du modèle de prédiction d effort utilisant NOD, NOC et EOS Figure 6.9: Résumé (graphique) sur la capacité de prédiction d effort de NOD et NOC Figure 6.10: Résumé (graphique) sur la capacité de prédiction d effort de NOD, NOC et EOS

10 LISTE DES TABLEAUX Tableau 2.1: Exemple des mesures de la complexité du logiciel Tableau 3.1: Type de fonctions élémentaires et les poids de complexité Tableau 3.2: 14 caractéristiques générales du système (GSCs) Tableau 3.3: Six niveaux d influence de 14 GSCs Tableau 3.4: Critères et les poids de la complexité [97] Tableau 3.5: Analyse des mesures de points de fonction selon le cadre de la complexité dans la figure Tableau 3.6: Utilisation des points de fonction dans l industrie [67] Tableau 3.7: Quelques modèles d estimation d effort et leur performance Tableau 4.1: Mise en correspondance des concepts élémentaires de deux modèles Tableau 4.2: Mise en correspondance des mesures de deux modèles Tableau 5.1: Correspondance entre le modèle fonctionnel du logiciel et le modèle de la tâche de Wood 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 Tableau 5.3: Résumé des mesures proposées pour la complexité du logiciel. 121 Tableau 5.4: Légende de la figure Tableau 5.5: Complexité des composants (NOD) et la taille fonctionnelle de COSMIC du Cuiseur de Riz Tableau 6.1: Ensemble de données utilisées dans l expérimentation Tableau 6.2: Corrélation linéaire (multiple) entre l effort et les mesures considérées Tableau 6.3: Influence de chaque variable dans la régression multiple entre l effort et NOD et NOC Tableau 6.4: Influence de chaque variable dans la régression multiple entre l effort et CFFP, NOD et NOC Tableau 6.5: Comparaison de la performance des modèles (2) et (3)

11 xi Tableau 6.6: Influence de chaque variable dans la régression multiple entre l effort et NOD, NOC et EOS Tableau 6.7: Comparaison de la performance des modèles (2) et (4) Tableau 6.8: Amplitude d erreur relative des tests croisés sur 15 couples NOD et NOC Tableau 6.9: Amplitude d erreur relative des tests croisés sur 8 triplets NOD, NOC et EOS Tableau 6.10: Résumé sur la capacité de prédiction d effort

12 LISTE DES ACRONYMES CMM COCOMO COSMIC COSMIC-FFP DFD DI EOS FP FPA GQM GSC IEEE IFPUG ISO KLOC LOC MIS MMRE MRE NOC NOD PF PRED ROM SFC SFCM SLIM TCF UFP Capacity Maturity Model Constructive Cost Model Common Software Measurement International Consortium COSMIC- Full Function Points Data Flow Diagram Degree of Influence Entropy of System Function Point Function Points Analysis Goal Question Metric General System Characteristic Institute of Electrical and Electronics Engineers International Function Point User Group International Organization for Standardization Thousand Lines of Code Lines of Code Management Information System Mean Magnitude of Relative Error Magnitude of Relative Error Number of Conditions Number of Data Groups Points de Fonction Prediction Quality Random Access Memory Software Functional Complexity Software Functional Complexity Measure Software Lifecycle Management Technical Complexity Factor Unadjusted Function Point

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

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

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

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

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

18 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

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

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