MESURE DE LA COMPLEXITÉ FONCTIONNELLE DES LOGICIELS



Documents pareils
Exemple PLS avec SAS

Forthcoming Database

Macroscope et l'analyse d'affaires. Dave Couture Architecte principal Solutions Macroscope

Préparer un état de l art

RÉSUMÉ DE THÈSE. L implantation des systèmes d'information (SI) organisationnels demeure une tâche difficile

- Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK

BIG Data et R: opportunités et perspectives

Logiciel Libre & qualité. Présentation

Le génie logiciel. maintenance de logiciels.

Agile&:&de&quoi&s agit0il&?&

Editing and managing Systems engineering processes at Snecma

THÈSE. présentée à TÉLÉCOM PARISTECH. pour obtenir le grade de. DOCTEUR de TÉLÉCOM PARISTECH. Mention Informatique et Réseaux. par.

NORME INTERNATIONALE INTERNATIONAL STANDARD. Dispositifs à semiconducteurs Dispositifs discrets. Semiconductor devices Discrete devices

Logiciel Libre Cours 3 Fondements: Génie Logiciel

Application Form/ Formulaire de demande

Quatre axes au service de la performance et des mutations Four lines serve the performance and changes

Université du Québec à Montréal CALCUL AVEC ISO DE LA TAILLE DE LOGICIELS DEVELOPPES SELON RATIONAL UNIFIED PROCESS

Ingénierie et gestion des connaissances

Instaurer un dialogue entre chercheurs et CÉR: pourquoi? Me Emmanuelle Lévesque Centre de génomique et politiques Université McGill

1.The pronouns me, te, nous, and vous are object pronouns.

English Q&A #1 Braille Services Requirement PPTC Q1. Would you like our proposal to be shipped or do you prefer an electronic submission?

IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels

Once the installation is complete, you can delete the temporary Zip files..

physicien diplômé EPFZ originaire de France présentée acceptée sur proposition Thèse no. 7178

REMOTE DATA ACQUISITION OF EMBEDDED SYSTEMS USING INTERNET TECHNOLOGIES: A ROLE-BASED GENERIC SYSTEM SPECIFICATION

Grandes tendances et leurs impacts sur l acquisition de produits et services TI.

Completed Projects / Projets terminés

Cette Leçon va remplir ces attentes spécifiques du curriculum :

AGROBASE : un système de gestion de données expérimentales

Marie Curie Individual Fellowships. Jean Provost Marie Curie Postdoctoral Fellow, Institut Langevin, ESCPI, INSERM, France

Qualité de la conception de tests logiciels : plate-forme de conception et processus de test

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

RAPID Prenez le contrôle sur vos données

FAQ Foire aux questions. Sur cette page, vous trouverez les réponses à toutes vos questions relatives aux études de la musique en Europe.

$SSOLFDWLRQGXNULJHDJHSRXUOD FDOLEUDWLRQPRWHXU

Vers une approche Adaptative pour la Découverte et la Composition Dynamique des Services

that the child(ren) was/were in need of protection under Part III of the Child and Family Services Act, and the court made an order on

Les contraintes de financement des PME en Afrique : le rôle des registres de crédit

Rapport de certification

CLIM/GTP/27/8 ANNEX III/ANNEXE III. Category 1 New indications/ 1 re catégorie Nouvelles indications

ICA Congress, Brisbane 2012 Thème général : Les temps qui changent. La confiance et les archives*

CALCUL DE LA CONTRIBUTION - FONDS VERT Budget 2008/2009

Ingénierie et qualité du logiciel et des systèmes

Modernisation et gestion de portefeuilles d applications bancaires

Improving the breakdown of the Central Credit Register data by category of enterprises

Analyse,, Conception des Systèmes Informatiques

VERS L EXCELLENCE DANS LA FORMATION PROGRAMME D APPUI A LA QUALITE AMELIORATION SUPERIEUR DE LA QUALITE DE L ENSEIGNEMENT TITRE DU PROJET

LE PROBLÈME DE RECHERCHE ET LA PROBLÉMATIQUE

Stéphane Lefebvre. CAE s Chief Financial Officer. CAE announces Government of Canada participation in Project Innovate.

MANAGEMENT SOFTWARE FOR STEEL CONSTRUCTION

Institut français des sciences et technologies des transports, de l aménagement

Architecture pragmatique pour la gestion du cycle de vie des applications (ALM)

UNE EXPERIENCE, EN COURS PREPARATOIRE, POUR FAIRE ORGANISER DE L INFORMATION EN TABLEAU

Discours du Ministre Tassarajen Pillay Chedumbrum. Ministre des Technologies de l'information et de la Communication (TIC) Worshop on Dot.

Génie logiciel. Systèmes et sous-systèmes. Modèliser des grands systèmes. Problématique. SS S-Syst1 SS S-Syst2 SS S-Syst3. Système.

Bourses d excellence pour les masters orientés vers la recherche

Forum AMOA ADN Ouest. Présentation du BABOK. 31 Mars 2013 Nadia Nadah

FUTURES COMPRENDRE VOTRE RELEVE DE COMPTE. WH SELFINVEST Est Luxemburg, France, Belgium, Poland, Germany, Netherlands

First Nations Assessment Inspection Regulations. Règlement sur l inspection aux fins d évaluation foncière des premières nations CONSOLIDATION

Analyse des logiciels d application spécialisée pour le courtage en épargne collective

Industrial Phd Progam

Small Businesses support Senator Ringuette s bill to limit credit card acceptance fees

THE SUBJUNCTIVE MOOD. Twenty-nineth lesson Vingt-neuvième leçon

Synergies entre Artisan Studio et outils PLM

Face Recognition Performance: Man vs. Machine

Nom de l application

Fiche produit ifinance v4

Notes de lecture : Dan SPERBER & Deirdre WILSON, La pertinence

Integrated Music Education: Challenges for Teaching and Teacher Training Presentation of a Book Project

Tex: The book of which I'm the author is an historical novel.

GEIDE MSS /IGSS. The electronic document management system shared by the Luxembourg

8. Cours virtuel Enjeux nordiques / Online Class Northern Issues Formulaire de demande de bourse / Fellowship Application Form

11 Février 2014 Paris nidays.fr. ni.com

Instructions pour mettre à jour un HFFv2 v1.x.yy v2.0.00

Scénarios économiques en assurance

Nouveautés printemps 2013

Les doutes et les questions des économistes face au système des brevets

Formulaire d inscription (form also available in English) Mission commerciale en Floride. Coordonnées

Plan. Department of Informatics

Instructions Mozilla Thunderbird Page 1

INSTITUT MARITIME DE PREVENTION. For improvement in health and security at work. Created in 1992 Under the aegis of State and the ENIM

This is a preview - click here to buy the full publication NORME INTERNATIONALE INTERNATIONAL STAN DARD. Telecontrol equipment and systems

Analyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML.

LES CARTES À POINTS : POUR UNE MEILLEURE PERCEPTION

L évaluation de la qualité d un dispositif d apprentissage en ligne. Quelles traces mobiliser? Comment les interpréter?

An Ontology-Based Approach for Closed-Loop Product Lifecycle Management

Évaluation de la mise en oeuvre des recommandations issues des audits effectués à l Université Nationale du Bénin par la Banque mondiale et l UNESCO

La Poste choisit l'erp Open Source Compiere

L ABC de l acquisition de petites entreprises

Estimation des charges. «Le travail se dilate jusqu à remplir le temps disponible»

INVESTMENT REGULATIONS R In force October 1, RÈGLEMENT SUR LES INVESTISSEMENTS R En vigueur le 1 er octobre 2001

Introduction au Génie Logiciel

iqtool - Outil e-learning innovateur pour enseigner la Gestion de Qualité au niveau BAC+2

Optimisez la gestion de vos projets IT avec PPM dans le cadre d une réorganisation. SAP Forum, May 29, 2013

Armand HATCHUEL Mines ParisTech Chaire de théorie et méthodes de la Conception innovante. Les défis contemporains

Évaluation et implémentation des langages

RULE 5 - SERVICE OF DOCUMENTS RÈGLE 5 SIGNIFICATION DE DOCUMENTS. Rule 5 / Règle 5

Design centré sur l utilisateur et développement Agile : perspectives de réconciliation

Relation entre deux variables : estimation de la corrélation linéaire

Guide No.2 de la Recommandation Rec (2009).. du Comité des Ministres aux États membres sur la démocratie électronique

Transcription:

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

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

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,