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,

21 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

22 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

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

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

25 Complexité et mesure de la complexité du logiciel CONCEPTS UTILISÉS DANS LA THÈSE 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

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

27 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 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 3 rd 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

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

29 Complexité et mesure de la complexité du logiciel 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É Approche des systèmes complexes Software entities are more complex for their size than perhaps any other human construct because no two parts are alike. (Brooks, 1987) 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

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

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

32 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

33 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é intermodules ), 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 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, quasidé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é.

34 Complexité et mesure de la complexité du logiciel 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.

35 Complexité et mesure de la complexité du logiciel 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 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=X k )log(p(x=x k )), où X k 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 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

36 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 ( m i (x) ), où m i (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 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:

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

38 Complexité et mesure de la complexité du logiciel 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 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

39 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 : PRINT (i*i) 400: i=i+1 500: GOTO : 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? 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)

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

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

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

43 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 CODE CONCEPTION DU LOGICIEL Lignes de code (LOC) [49] Science du logiciel de Halstead [76] McCabe [118] Entropie [54] Fan-in et fan-out [79] Taille du code, puis l effort pour écrire le code Taille du code, puis l effort pour écrire le code Structure du code, puis la compréhensibilité du code Structure du code, puis la compréhensibilité du code Structure du module, puis la complexité du système. Compter le nombre de lignes de code (non vide et non commentaire) du programme. 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. 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. 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. 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).

44 Complexité et mesure de la complexité du logiciel 30 FONCTIONNALITÉ DU LOGICIEL Couplage et Cohésion [179] Points de fonction (FPA) [8,9] Structure du module et structure du système Taille, structure, puis effort de développement du logiciel. (pas de mesure quantitative) 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. 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.

45 Complexité et mesure de la complexité du logiciel 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.

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

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

48 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] 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!" N 1 : nombre total d occurrences des opérateurs

49 Mesures basées sur le code source et la conception du programme 35!" N 2 : 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=N 1 +N 2. 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: 2 µ L & x µ N 1 Et la longueur du programme (N) est estimée par: N & µ log(µ ) ' µ log(µ )

50 Mesures basées sur le code source et la conception du programme 36 Puis l effort requis pour composer le programme est: E & V L µ & 1 N 2 Nlogµ 2µ 2 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 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 = N 1 +N 2 = 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

51 Mesures basées sur le code source et la conception du programme 37 L peut être estimé par 2 µ 2 L & x = 2/14 * 13/42 = 0,044 µ N2 1 D = 1/L = 38,5 L effort est estimé par V µ 1N2 Nlogµ E & & = 442/0,044 = L 2µ 2 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].

52 Mesures basées sur le code source et la conception du programme 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.

53 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 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 = = 6.

54 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; ; ; ; ; 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 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.

55 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, fanout 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é intermodules comme suit: S = n ( f i i &1 n 2 Où: S est la complexité inter-modules du système f i est le nombre de fan-out du module i n est le nombre total de modules du système.

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

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

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

59 Mesures basées sur le code source et la conception du programme Mesures de la compréhensibilité du programme 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) 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é.

60 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: n H = - ( P(A i )log(p(ai )) i& 1 Où, n est le nombre de classes d équivalence et P(A i ) est la probabilité d appartenance d un chunk à la classe A i. 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

61 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

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

63 Mesures basées sur le code source et la conception du programme 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 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 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.

64 Mesures basées sur le code source et la conception du programme 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 = % 1 log(% 1 ) + % 2 log(% 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). % 1 log(% 1 ) est l espace de recherche pour % 1 opérateurs; % 2 log(% 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 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?».

65 Mesures basées sur le code source et la conception du programme 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.

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

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

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

69 Mesure de points de fonction 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 Item Poids Simple Moyen Complexe Entrées Sorties Requêtes Fichiers externes Fichiers internes 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 Données et manipulations distribuées processing 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,

70 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 = *( F i, où F i prend la valeur de 0 à 5 qui indique le degré d influence du facteur F i 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. 14 i& 1 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 the application can be estimated from the itemization of the major components data to be used or provided by it. Furthermore, this estimation of function should be correlated to both the amount of LOC to be developed and the development effort needed. (Albrecht and Gaffney, 1983)

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

72 Mesure de points de fonction 58 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) 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 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,

73 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 ( 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.

74 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 sousentendus 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: 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.

75 Mesure de points de fonction 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. It seems a reasonable hypothesis that a measure of processing complexity is to count the number of entity-types referenced by the transaction-type, referenced means created, updated, read or deleted. (Symons, 1988). 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:

76 Mesure de points de fonction 62 UFP = N I W I + N E W E + N O W O Où: UFP est la taille non-ajustée. N I est le nombre de types d éléments en entrée. N E est le nombre de références. N O est le nombre de types d éléments en sortie. W I, W E et W O 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

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

78 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 Piètre structure et plusieurs modules et Éléments de données et interactions très complexes. complexes chemins 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 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.

79 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: FP A = n * i& 1 wi y K i Où: FP A : points de fonction de Reifer. y i est le nombre d entrées/sorties, interrogations, etc., qui sont énumérées cidessus. w i 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 * (FP A * LANG + MVOL) + Où: SIZE: taille en lignes de code ARCH: constante d architecture EXPF: facteur d expansion

80 Mesure de points de fonction 66 FP A : points de fonction (de Reifer) LANG: constante de langage (un facteur de conversion FP A 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 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 COSMIC-FFP COSMIC-FFP est une méthode de points de fonction proposée par COSMIC 2. 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.

81 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

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

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

84 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. Méthode FPA Concepts Façon de mesurer MARK-II Concepts Complexité des composants Données Structure des entrées/sorties composants les intrants, extrants, et les requêtes, les fichiers internes, externes Subjective: utilise les guides et les tableaux de décision Entrées, sorties et les transactions une combinaison d entrées, sorties et manipulations «complex processing» (caractéristique 9 dans le tableau 3.2) Subjective en se basant sur les guides La structure de branchement et des boucles Complexité du système (de relations entre les composants) Data communication, distributed processing et complex processing (caractéristiques 1,2 et 9 dans le tableau 3.2) Subjective en se basant sur les guides Comme FPA Points de fonction totaux Combinaison des mesures des composants (UFP) et des mesures des caractéristiques du système (DI degré d influence) - la taille brute (UFP) est une mesure objective à partir du nombre des

85 Mesure de points de fonction 71 Façon de mesurer Feature Points Concepts Façon de mesurer ASSET-R Concepts Façon de mesurer Points de fonction 3D Concepts Façon de mesurer Subjective: utilise les guides nœuds, rendezvous COSMIC- FFP Concepts Façon de mesurer Le nombre des entités en entrées et en sorties La complexité des données Subjective: utilise les guides entrées, sorties, interrogations, fichiers, interfaces nombre d entrées, nombre de sorties, nombre d interrogations, nombre de fichiers, nombre d interfaces Données Nombre des entrées, sorties, requêtes, fichiers internes, fichiers externes Mouvement de données Le nombre total de mouvements de données: entrées, sorties, lectures et écritures Mesurée objectivement par le nombre d entités concernant la transaction (les entités lues, mises à jour, modifiées, supprimées) La complexité de l algorithme nombre de nœuds, nombre de rendez-vous Fonction: la manipulation de données Nombre de transformations Manipulation de donnée Pas mesurée Comme FPA Comme FPA Comme FPA relations stimulus/ réponse nombre de relations stimulus/ réponse Contrôle: relation de contrôle entre les fonctions Nombre de transitions Pas mentionnée Tableau 3.5: Analyse des mesures de points de fonction selon le cadre de la complexité dans la figure 3.4. 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) Comme FPA Une combinaison des mesures objectives dans les colonnes à gauche Une combinaison des mesures objectives dans les colonnes à gauche Nombre total de mouvements de données

86 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 Points de fonction/durée Points de fonction par mois de (Responsiveness) Qualité calendrier Nombre de défauts par point de fonction Nombre de défauts (defects)/ points 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].

87 Mesure de points de fonction 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. Productivity: the rate of output per unit input used especially in measuring capital growth, and in assessing the effective use of labour, materials and equipment. (Oxford English Dictionary, 2 nd edition) 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. taille Productivité = effort (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 Estimation d effort 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

88 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 (E r ) investi dans un projet et les points de fonction (PF) de celui-ci sont collectés. L analyse de régression linéaire entre E r 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 E r une valeur «proche d E r». Idéalement, E est égale à E r 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 E r 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 (R 2 ) 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 = E, E E r r (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):

89 Mesure de points de fonction 75 MMRE = n ( i&1 MRE n i (5) Où n est le nombre de projets dans la base de données, MRE i 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) = le nombre de projets ayant MRE - x n (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) 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.

90 Mesure de points de fonction 76 Modèle Effort Observations R 2 PRED(0,25) MMRE référence E = 54*FPA 13,39 Heures 24 0,85 0,52 0,35 [9] de travail E=0,355*FPA-88 Hommemois 15 0,87 N/A 1,03 [102] E=0,65*CFFP + 8,97 Heures 15 0,83 0,53 0,45 [2] Application Web de travail E=4,49*CFFP+ 83 Heures 18 0,84 0,555 0,40 [2] Application temps réel de travail E=0,72*CFFP 0,81 Hommemois 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.

91 Mesure de points de fonction 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 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.

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

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

94 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 soustâ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

95 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 (multicues) 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

96 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

97 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

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

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

100 Modèle de la complexité de la tâche 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: TC 1 = (( n m wij i& 1 j& 1 Où:!" n: nombre de sous-tâches.!" m: nombre d actions dans une sous-tâche.!" w ij : 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 TC 1 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-

101 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 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: TC 2 = ( p ri i& 1 Où: p est le nombre d actions dans la tâche; r i est le nombre d actions qui précède l action i; r i 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].

102 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 intercomposants 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: TC 3 = Où: ( k t& 1 TC,, 1(t ' 1) 1(t) 2(t' 1) TC ' TC TC 2(t)!" 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).!" TC 1t, TC 2t 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:

103 Modèle de la complexité de la tâche 89 k ( TC s s s s s 3 = TC TC,! ) ' TC, TC (1, ) Où: t& 1 1(t ' 1), 1(t) (1 TC1 2(t' 1) 2(t)! TC2!"!"!" s TC1 est la complexité des composants mesurée par une unité normalisée. s TC 2 est la complexité de coordination mesurée par une unité normalisée. s TC 3 est la complexité dynamique mesurée par une unité normalisée.!" / TC1 est le coefficient d autocorrélation de TC 1.!" / TC2 est le coefficient d autocorrélation de TC 2. 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 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. s s La complexité totale: TC = $ TC 1 ' # TC 2 ' " TC Où: s 3!"!"!" s TC1 est la complexité des composants mesurée par une unité normalisée. s TC 2 est la complexité de coordination mesurée par une unité normalisée. s TC 3 est la complexité dynamique mesurée par une unité normalisée.

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

105 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

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

107 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 N 2 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 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.

108 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

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

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

111 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 celleci. 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 MODÉLISATION DU LOGICIEL 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

112 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

113 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

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

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

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

117 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

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

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

120 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 soussystè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

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

122 Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel 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.

123 Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel 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 Logiciel Processus fonctionnel Entrées/sorties Relations entre entrées et sorties (règles d opération) Concepts du modèle Tâche globale Tâche élémentaire Éléments d information (information cues) 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.

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

125 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

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

127 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é de structure des composants Complexité du système Complexité des composants Coordination entre les entrées et les sorties Coordination entre les actions ou les tâches élémentaires Pour tenir compte de mouvements de données Pour tenir compte de la manipulation de données 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 Mesure de la complexité de données entrées/sorties 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 à

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

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

130 Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel Mesure de la complexité structurelle des composants 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.

131 Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel 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) = x 2, 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.

132 Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel 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é.

133 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), {P 1,P 2,,P n } est une partition de P en classes d équivalence. L entropie du système (EOS) est: EOS = - n ( i& 1 P i P log P i P 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

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

135 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. Complexité de la structure des composants. Complexité du système. NOD nombre de groupes de données. NOC nombre de conditions. EOS Entropie de l information en communication.!" La taille des composants.!" La complexité en entrée et en sortie.!" Le nombre d éléments d information de Wood.!" COSMIC FFPnombre de mouvements de données.!" La complexité de branchements des composants.!" Nombre de «points tournants»!" Nombre de cas à traiter. (turning points) de Wood.!" La complexité de la!" Nombre manipulation des données. cyclomatique de McCabe.!" 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

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

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

138 Nouvelle méthode de mesure de la complexité fonctionnelle du logiciel 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 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.

139 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 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!"!" E: mode choisi W: mode choisi 2 Établir la température cible 3 Contrôler le chauffage NOD = 1 É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 Événement 5s NOD=6 1. température cible 2. température actuelle 3. état du chauffage (marche/arrêt) Cfsu = 2!" 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!" R: température cible!" E: température actuelle!" X: état du chauffage (marche/arrêt) 4 Mesurer le temps écoulé Appuie sur le bouton Start NOD=3 1. signal de l horloge 2. temps écoulé 3. événement 30s 4. événement 5s Cfsu =3!" E: signal de l horloge!" W: temps écoulé!" X: temps écoulé!" X: événement 30s!" X: événement 5s NOD=4 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 à

140 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 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: (ON). Si (température effective < température cible) Alors état du chauffage = marche 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) 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 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.

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

142 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

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

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

145 Investigation empirique et validation des mesures de la complexité fonctionnelle Validation d une mesure 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) 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

146 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 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 (E r ) et la valeur estimée (E) sur la valeur réelle. MRE = E, E E r r (1)!" MMRE: la moyenne des amplitudes d erreur relative (ou simplement le taux d erreurs moyen). MMRE = n ( i&1 MRE i n (2)!" PRED(x): le taux des cas d estimation ayant MRE-x.

147 Investigation empirique et validation des mesures de la complexité fonctionnelle 133 PRED (x) = le nombre de projets ayant MRE - x n (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] 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.

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

149 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

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

151 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 Figure 6.2b: Trois types de validation d une méthode de mesure. Validation du système de prédiction 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).

152 Investigation empirique et validation des mesures de la complexité fonctionnelle 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 Validation de la conception de la méthode de mesure 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 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.

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

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

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

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

157 Investigation empirique et validation des mesures de la complexité fonctionnelle 143 La qualité de la documentation implicite 8% manque de documentation 2% documentation complète 34% incomplète 56% 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 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

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

159 Investigation empirique et validation des mesures de la complexité fonctionnelle 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 Figure 6.4a: 15 projets ayant un effort inférieur de 24 homme-mois. 10 projets ayant un effort suppérieur à 24 homme-mois 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 hommemois 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-

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

161 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 EOS 3 1 1, , , ** 4 2, , ,67 6 6, ** 7 7, ** 8 7, ** 9 7, , , ** 11 9, , , ** 13 14, ** 14 20, , , 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.

162 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 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 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 (R 2 ) 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 {X 1,,X n }. Y est appelé la variable

163 Investigation empirique et validation des mesures de la complexité fonctionnelle 149 dépendante et X 1,,X n sont les variables indépendantes. La relation entre Y et X 1,, X n prend la forme: Y=0 1 X n X n (1) Si n=1, on a une régression linéaire entre deux variables. Le coefficient de corrélation (R 2 ) est une valeur comprise de 0 à 1 qui représente le degré de la relation entre Y et X 1,,X n. Plus la valeur de R 2 est grande, plus la corrélation est élevée. Par exemple, la valeur R 2 =0,80 confirme que dans 80% des cas, il y a une relation entre la variable dépendante Y et les variables indépendantes X 1,, X n. 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 R 2 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 Résultats de l expérimentation Corrélation Taille d échantillon Coefficient de Corrélation (R 2 ) 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

164 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é (R 2 =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 (R 2 = 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.

165 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

166 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) R 2 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 20% 7% 0% 73% 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. MRE de l'estimation utilisant FFP, NOD and NOC 27% 7% 0% 66% 0<=MRE<=25% 25%<MRE<=35% 35%<MRE<=50% MRE>50% 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%.

167 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 (R 2 =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)

168 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) R 2 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 38% 0% 0% 62% 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 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.

169 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 X 1, X 2,, X n. La validation croisée de type leave-oneout est un processus itératif de n fois pour lequel chaque itération est un test croisé entre X i et les autres projets dans l échantillon. Au i ème test, on utilise X i 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: F i est le modèle établi au i ème test (en se basant sur les projets dans la base de données sauf X i ). F i (X i ) est l effort estimé pour le projet X i avec le modèle F i. E i est l effort réel pour réaliser le projet X i. Donc, l amplitude d erreur relative (MRE) d i ème test est: MRE i = F (X ), E i i E i i Puis le taux d erreurs relatives moyen (MMRE) de tous les tests croisés est:

170 Investigation empirique et validation des mesures de la complexité fonctionnelle 156 n 1 MMRE = ( MRE n i & 1 i Pour analyser la capacité d estimation d effort, la mesure de qualité de prédiction (PRED) est utilisée: 1 PRED(x)= (le nombre de tests ayant MRE - x) n 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.

171 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 7% 26% 0% 67% 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 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.

172 Investigation empirique et validation des mesures de la complexité fonctionnelle 158 Capacité de prédiction d'effort de NOD, NOC et EOS 25% 62% 13% 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 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 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.

173 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

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

175 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

176 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

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

178 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

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

180 Conclusion 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,

181 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

182 Conclusion 168 logarithmique [165] avec l analyse de régression pour chercher des modèles nonliné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.

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

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

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

186 BIBLIOGRAPHIE 1. Abran A., Desharnais J.-M., Oligny S., St-Pierre D., Symons C., COSMIC FFP Measurement Manual Field Trials Version, Montreal, May, 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 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, Abran A., Analyse du processus de mesure des points de fonction, thèse de doctorat, École Polytechnique de Montréal, 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 , Adamov R., Richter L., A Proposal for Measuring the Structural of Complexity Programs, Journal of Systems and Software, Vol. 12, pp , Aho, A.V., Hopcroft J.E., Ullman J.D., The Design and Analysis of Computer Algorithms, Addison-Wesley, Albrecht A., Measuring Application Development Productivity, presented at the IBM Applications Development Symposium, 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 , November Anderson J.R., Reder L.M., Lebriere C., Working Memory: Activation Limitations on Retrieval, Cognitive Psychology, Vol. 30, pp , Ashby W.R., Some Peculiarities of Complex Systems, Cybernetic Medicine, Vol. 9, pp.1-8, Atlan H., Les théories de la complexité, Seuil, 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 , Balzer R., What We Do and Don t Know About Software Process, Software Process Symposium, Washington, September, Banker R.D., Slaughter S.A, The Moderating Effects of Structure on Volatility and Complexity in Software Enhancement, Information Systems Research, Vol.11, pp , Banker R.D., Datar S.M., Kemerer C.F., Zweig D., Software Complexity and Maintenance Costs, Communications of ACM, Vol. 36(11), pp , 1993.

187 Bibliographie 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 , Basili V.R., Tutorial on Models and Metrics for Software Management and Engineering, IEEE Computer Society Press, New York, Basili V.R., Evaluating Software Development Characteristics: Assessment of Software Measures in The Software Engineering Laboratory, Proceedings of Sixth Annual Software Engineering Workshop, SEL , Basili V.R., Weiss D., A Methodology for Collecting Valid Software Engineering Data, IEEE Transactions on Software Engineering, SE-10(6), pp , Basili V.R., Rombach H.D., The Tame Project: Towards Improvement-Oriented Software Environments, IEEE Transaction on Software Engineering, 14(6), pp , Batty M., Torrens P.M., Modeling Complexity: The Limits to Prediction, Cybergeo, No. 201, Belady L.A., Evangelisti C.J., System Partitioning and its Measure, Journal of System and Software, No. 2, pp , Bennett C.H., Logical Depth and Physical Complexity, in The Universal Turing Machine- a half Century Survey, pp , Oxford University Press, Bennett P.A., Software Development for Channel Tunnel: A summary, High Integrity System, 1(2), pp , Bertalanffy L., Théorie Générale des Systèmes, traduction par Jean Benoît Chabrol, Dunod, Paris, 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, Bieman J.M, Ott L.M., Measuring Functional Cohesion, IEEE transaction on Software Engineering, 20(8), pp , 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 , June Boehm B.W., Software Engineering Economics, Prentice-Hall, 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 Briand L.C., Morasca S., Basili V.R., Property-Based Software Engineering Measurement, IEEE Transactions on Software Engineering, Vol. 22, No. 1, pp , January 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, Brooks F.P., The Mythical Man-Month, Addison-Wesley, New York, Brooks F.P., No Silver Bullet: Essence and Accidents of Software Engineering, Computer, Vol. 20, pp , 1987.

188 Bibliographie 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, Budgen D., Software Design, Addison-Wesley, Burman P., Chow E., Nolan D., A cross-validatory method for dependent data. Biometrika, 81(2), pp , 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 Campbell D.J., Task Complexity: A Review and Analysis, Academy of Management Review, Vol. 13, pp , 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 , Card S.K., Moran T.P., Newell A., The Psychology of Human Computer Interaction, Hillsdale, Card D.N., Glass R.L., Measuring Software Design Quality, Prentice Hall, Chaitin G.J., Algorithmic Information Theory, Cambridge University, Chaitin G.J., Information, Randomness, and Incompleteness, Singapore, World Scientific, Cherniavsky J.C, Smith C.H., On Weyuker s Axioms for Software Complexity Measures, IEEE Transactions on Software Engineering, No. 17, pp , Chidamber S.R., Kemerer C.F., A Metrics Suite for Object Oriented Design, IEEE transactions on software engineering, 20 (6), pp , Chulani S., Boehm B., Steece B., Bayesian Analysis of Empirical Software Engineering Cost Models, IEEE Transactions on Software Engineering, 25 (4), July, Conte S.D., Dunsmore H.E., Shen V.Y., Software Engineering Metrics and Models, Benjamin/Cummings, Menlo Park, CA, Cordero R., Costramagna M., Paschetta E., A Genetic Algorithm Approach for the Calibration of COCOMO like Models, 12 th COCOMO Forum, Curtis B., In Search of Software Complexity, Workshop on Quantitative Software Models, IEEE, New York, pp , Curtis B., Fifteen Years of Psychology In Software Engineering: Individual Differences and Cognitive Science, Proceedings of the 7th international conference on Software engineering, pp , 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 , Davis J.S., LeBlanc R.J, A Study of The Applicability of Complexity Measures, IEEE Transactions on Software Engineering, Vol. 14, No. 9, pp , 1988.

189 Bibliographie DeMarco T., Controlling Software Projects: Management, Measurement, and Estimation, New York, NY: Yourdon Press, 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 , Springer, Berlin, Germany, Dunn R.H., Software Quality Concepts and Plans, Prentice Hall, Ejiogu L.O., Beyond structured programming: an introduction to the principles of applied software metrics, Structured Programming, 11 (1), pp , Evangelisti W.M., Software Complexity Metric Sensitive to Program Structured Rules, The Journal of System and Software, No. 3, pp , Fenton N.E., Software Measurement: A Necessary Scientific Basis, IEEE Transaction on Software Engineering, Vol. 20, No. 3, pp , Mar Fenton N.E., Pfleeger S.L., Software Metrics: A Rigorous and Practical Approach, second edition, Fenton N.E., Neil M., Software Metrics: Successes, Failures and New Directions, The Journal of Systems and Software, Vol. 47, No. 2-3, pp , Fenton N.E., Neil M., A Critique of Software Defect Prediction Models, IEEE Transactions on Software Engineering, Vol. 25, pp , Finnie G.R., Wittig G.E., Desharnais J.M., Estimating software development effort with casebased reasoning, Proceedings of International Conference on Case-based Reasoning, p , Fortin R., Comprendre la Complexité, Les presses de l université Laval, Garmus D., Herron D., Measuring the Software Process, Upper Saddle River: Yourdon Press, Gilb T., Software Metrics, Winthrop Publishers, Inc., Cambridge, Massachusetts, Gill G.K., Kemerer C.,F., Cyclomatic Complexity Density and Software Maintenance Productivity, IEEE Transaction on Software Engineering, Vol.17 (9), pp , Grady R.B., and Caswell D.L., Software Metrics, Prentice Hall, Grady R.B., Practical Software Metrics for Project Management and Process Improvement, New Jersey: Prentice Hall, Grady R.B, Successfully Applying Software Metrics, IEEE computer, 27(9), pp September Gramantieri, F., Lamma, E., Riguzzi, F., Mello, P., A system measuring function points from specification, GUIDE International Corp., Estimating Using Function Point Handbook, GUIDE Publications GPP-134, Reprint Halstead M.H., Element of Software Science, New York, Elsevier North-Holland, Hansen W., Measurement of Program Complexity by Pair (Cyclomatic Number, Operator Count), ACM SIGPLAN notices, Vol. 13, No. 3, pp , Mars 1978.

190 Bibliographie Harrison W., An Entropy-Based Measure of Software Complexity, IEEE Transactions on Software Engineering, Vol. 18, No. 11, pp , Henry S.M., Kafura D.G., Software Structure Metric Based on Information Flow, IEEE Transactions on Software Engineering, Vol.7, No. 5, pp , September Henderson-Sellers B., Object-Oriented Metrics Measures of Complexity, Prentice Hall, New Jersey, Heylighen F., Joslyn C., What is Systems Theory?, in: F. Heylighen, C. Joslyn and V. Turchin (editors), Principia Cybernetica, Brussels, Hodgkinson A.C., Garratt P.W., A neurofuzzy Cost Estimator, Proceedings of the 3 rd International Conference on Software Engineering and Applications, pp , Holland J.H., Hidden Order: How Adaptation Builds Complexity, Addison-Wesley, Case Study: Rice Cooker, UQAM Software Engineering Management Research Laboratory, version 2.1, edited by Ho T.V., 14 Jan Humphrey W.S, A Discipline for Software Engineering, Addition-Wesley, MA, 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 IEEE, Standard Dictionary of Measures to Produce Reliable Software, The Institute of Electrical and Electronics Engineers, IEEE Standard Board, IFPUG (International Function Point Users Group), Function Point Counting Practices Manual, Release 1.1, Westerville, Ohio, April IFPUG (International Function Point Users Group), Function Point Counting Practices Manual, Release 2.0, Westerville, Ohio, April IFPUG (International Function Point Users Group), Function Point Counting Practices Manual, Release 4.1, Westerville, Ohio, April ISO 9001 Compliance TM Quality Manual + SOP's + Forms, ISO, Jackson M., Principles of Program Design, London: Academic, 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, Jacquet J.P., Abran A., Metrics Validation Proposals: A Structure Analysis, The 8 th International Workshop on Software Measurement, Magdeburg, Germany, September, 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 , Jones C., Estimating Software Cost, Second edition, New York, McGraw-Hill Inc, Jones C., Building a Better Metric, Computerworld Extra, 20 June Jones C., Applied Software Measurement Assuring Productivity and Quality, New York, McGraw-Hill Inc, 1991.

191 Bibliographie 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, Kelvin L., Popular Lectures and Addresses, Vol. 1, pp. 73, Kemerer C.F., Software complexity and Software Maintenance: A Survey of Empirical Research, Annals of Software Engineering, Vol. 1, No. 1, pp. 1-22, Kemerer C.F., An Empirical Validation of Software Cost Estimation Models, Communication of ACM, Vol. 30, No. 5, pp , Kintsch W., Memory and Cognition, John Wiley, New York, Kintsch W., Comprehension: a Paradigm for Cognition, Cambridge University Press, Kitchenham B., Känsälä K., Inter-item Correlations among Function Points, Proceedings of the 15th International Conference on Software Engineering, pp , 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 , Kitchenham B.A., John G.S., The Danger of Using Axioms in Software Metrics. IEEE Proceedings Software 144(5-6): , Kolmogorov A.N., Three Approaches to the Quantitative Definition of Information, Problem in Information Transmission, Vol. 1, pp. 1-7, Kolmogorov A.N., Logical Basis for Information Theory and Probability Theory, IEEE Transaction on Information Theory, IT 14, pp , Legasto A.A., Forrester J.W., Lyneis J.M., System Dynamics, North Holland, Le Moigne J-L., La Théorie du Système Général, Paris: PUF, Le Moigne J-L., La Modélisation des Systèmes Complexes, Paris (Dunod) 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, MacDonell S.G., Rigor in Software Complexity Measurement Experimentation, Journal of Systems Software, Vol. 16, No. 2, pp , October, Manson, S. M., Simplifying Complexity: A Review of Complexity Theory. Geoforum No. 32, pp , March J., Simon H., Organizations, New York: Wiley, Martin J., Rapid Application Development, McMillan Publishing, NY, McCabe T.J., A Complexity Measure, IEEE Transactions on Software Engineering, Volume SE-2, No. 4, pp , December McCabe T.J., Butler C.W., Design Complexity Measurement and Testing, Communications of the ACM, Vol. 32, No. 12, pp , December, 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 , Mendonca M.G., Basili V.R., Validation an approach for improving existing measurement frameworks, Transactions on Software Engineering, Vol. 26, pp , 2000.

192 Bibliographie Miller G.A., The Magical Number Seven Plus Or Minus Two: Some Limits on Our Capacity for Processing Information, Psychological Review, 63, 81-97, Morin E., Introduction à la Pensée Complexe, ESF éditeur, Morin E., La Méthode, Quatre volumes, Paris: Seuil, 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, 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, Myers G.J., An Extension to the Cyclomatic Measure of Program Complexity, ACM SIGPLAN notices, Vol.12, No.10, pp , October Naur P., Randell B., Software Engineering: A report on a Conference sponsored by the NATO Science Committee, NATO, Parrott L., Complexity and the Limits of Ecological Engineering, Transactions of the ASAE, No. 45, pp , Paulk M.C., Curtis B., Chrissis M.B., Weber C.V., The Capability Maturity Model for Software, IEEE Software, Vol. 10, No. 4, pp , July Peters J.F., Pedrycz W., Software Engineering: An Engineering Approach, John Wiley & Son, Inc., Pfleeger S.L., Jeffery R., Curtis B., Kitchenham B., Status Report on Software Measurement, IEEE Software, pp , Pressman, Roger S., Software Engineering: A Practitioner s Approach, McGraw-Hill, Prietula M.J., Vincinanza S.S., Mukhopadhyay T., Software Effort Estimation With Case- Based Reasoner, Journal Experimental & Theoretical Artificial Intelligence 8, pp , 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 , July Ramamoorthy C.V, Tsai W., Yamaura T., Bhide A., Metrics Guided Methodology, COMPSAC 85, pp , 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 , Schroder H., Driver M., Streufert S., Human Information Processing, New York: Holt, Rinehart and Winston, Schwab D., Cummings L., A Theoretical Analysis of The Impact of Task Scope on Employee Performance, Academy of Management Review, No. 1, pp , Shao J., Linear model selection by cross-validation, Journal of the American Statistical Association, No. 88, pp , 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 , April 2003.

193 Bibliographie Shannon C.E., Weaver W., The Mathematical Theory of Communication, University of Illinois Press, Urbana, Shepperd M.J., Ince D., The Use of Metrics in the Early Detection of Design Errors, Proceedings of the European Software Engineering Conference, pp , Shepperd M.J., Schofield C., Kitchenham B.A., Effort Estimation Using Analogy, 18 th International Conference on Software Engineering, Berlin, IEEE Computer Press, 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 , Simon H.A., From Substantive to Procedural Rationality, in S. Latsis (ed) Method and Appraisal in Economics Cambridge: Cambridge UP, pp , Simon H.A, Models of Thought: Volume I, New Haven, Connecticut: Yale University Press, Simon H.A, Models of Thought: Volume II, New Haven, Connecticut: Yale University Press, 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 , Simon H.A., Sciences des Systèmes, Sciences de l artificiel, Ch.7 l architecture de la complexité, Dumod, Paris, 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, Solomonoff R.J., A formal Theory of Inductive Inference, Information and Control, Vol. 7, pp. 1-22, , Srinivasan, K., Fisher D., Machine Learning Approaches to Estimating Software Development Effort, IEEE Transactions Software Engineering, Vol. 21, No. 2, pp , February 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 , Stroud J., The Fine Structure of Psychological Time, Annals of New York Academy of Science, Vol. 138, No. 2, pp , Sullivan J.E., Measuring the Complexity of Computer Software, Mitre Corporation, P.O Box 208, Bedfort, MA 01730, Sutcliffe A., Human-Computer Interface Design, Springer-Verlag, New York, Symons C., Function Point Analysis: Difficulties and Improvements, IEEE Transactions on Software Engineering, Vol. 14, No. 1, pp. 2-11, January, Terborg J., Miller H., Motivation, Behavior And Performance: A Closer Examination of Goal- Setting and Monetary Incentives, Journal of Applied Psychology, Vol. 63, pp , Turney P., A Theory of Cross-Validation Error, Journal of Experimental and Theoretical Artificial Intelligence, No. 6, pp , 1994.

194 Bibliographie Tian J., Zelkowitz M.V., A Formal Program Complexity Model and Its Application, Journal of Systems and Software, Vol. 17, pp , Torres I., Calatrava F., Automatic Function Point Counting on Conceptual Models, CARE technologies, Tran-Cao D., Abran A., Levesque G., Functional Complexity Measurement, Proceedings of the 11 th International Workshop on Software Measurement, Montreal, Canada, IWSM 2001, pp , 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 , October Tran-Cao D., Levesque G., Maintenance Effort and Cost Estimation Using Software Functional Sizes, International Workshop on Software Measurement, Montreal, Canada, September Tran-Cao D., Levesque G., Meunier J-G, Software Functional Complexity Measurement with the Task Complexity Approach, Proceedings of RIVF 04, Hanoi, Vietnam, February 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 , Berlin, Germany, Tracz, W.J., Computer Programming and the Human Thought Process, Software Practice and Experience, No. 9, pp , Turing A.M., Computing Machinery and Intelligence. Mind, Vol. 59, No. 263, pp , Troy D.A., Zweben S.H., Measuring the Quality of Structured Design, Journal of Systems and Software, Vol. 2, No. 2, pp , 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 , June Wang Y., On Cognitive Informatics: Keynote Lecture, Proceedings of the 1 st IEEE Conference Cognitive Informatics (ICCI 02), Calgary, Alberta, Canada, pp , August Walston C.E., Felix C.P., A Method of Programming Measurement and Estimation, IBM Systems Journal, Vol. 16, No. 1, pp , Weyuker E.J., Evaluating Software Complexity Measures, IEEE Transactions on Software Engineering, Vol. 14, No. 9,pp , Whitmire S.A., An Introduction to 3D Function Points, Software Development, pp , April, Wittig G., Finnie G., Estimating Software Development Effort with Connectionist Models, Information and Software Technology, Vol. 39, No. 7, pp , Wood R.E., Task Complexity: Define of the Construct, Organisational Behaviour and Human Decision Process, Vol. 36, pp , 1986.

195 Bibliographie Yatchinovsky A., L approche Systémique pour Gérer l Incertitude et la Complexité, ESF éditeur, Yourdon E., Constantine L.L., Structure design, Prentice Hall, NJ, Zuse H., Software Complexity Measures and Methods, Walter de Gruyter, Berlin - New York, 1991.

196 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, June 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, February 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 , IWSM/METRIKON 04, Berlin, Germany 3-5 November 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 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, September 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 , ICSM 02, Montreal, Canada, 3-6 October TRAN-CAO De, ABRAN Alain, LÉVESQUE Ghislain, Functional Complexity Measurement, Proceedings of the 11th International Workshop on Software Measurement, pp , IWSM 01, Montreal, Canada, August 2001.

197 ANNEXE 2 RAPPORT DE COMPTAGE DE 15 PROJETS 1. Case study 1: Project P6 Document source - System Design, version 1.1, December 20 th 2000 Document quality Not enough detail Complexity Counting Functional processes Information cues Conditions Hypothesis Create a new table entry Miscellaneous discount - entry: effective date and latest table entry - write & exit (copy): new table entry NOD=2 - Read & exit: old discount value. - Entry, Write & Exit: new discount value. Not count Write and Exit. Count 1 Read and 1 Entry. NOD=2 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 TOTAL NOD=18 NOC=3 System complexity: - Day - evening - night or weekend. NOC=3

198 Rapport de comptage de 15 projets 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

199 Rapport de comptage de 15 projets Case study 2: Project P17 Document source - System specification, System Architecture, version 1.1, September 13 th 2000 Document quality Detail Complexity Counting: Functional process NOD NOC Hypothesis Determine facility status of a TN -Read: data table. - Write & Exit: TN status. - Leased - Working - Vacant - Other Write and Exit is count as one because TN status is unchanged. NOD=2 NOC=4 Count number of NOD=2 release Count number of NOD=2 working TN Count number of NOD=2 Vacant TN Count number of NOD=2 TN by other Count number of NOD=2 TN by remark TOTAL NOD=12 NOC=4 Each counting process is counted as 2 pts. (one Read data and one Write of counting result). System complexity: EOS=0 These requests are independent (see the diagram on p. 5)

200 Rapport de comptage de 15 projets Case study 3: Project P21 The specification of this project is lost. Reuse the counting in [148]: NOD = CFFP. NOC = 0. EOS = **.

201 Rapport de comptage de 15 projets Case study 4: Project P20 Document source System Design, version 1.0, November 21 st 2000 Document quality Detail Complexity Counting Functional processes Information cues Conditions Hypothesis Toll free service SIF- A and is the same functional process with two different interfaces. - Used Language - customer - telco info. - Activity - Order - Features - Conversion - Add row - Remarks - Technical inf. - IF lang=en then interface in English. 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 Toll-free service SIF- H NOD=10 - Customer - Virtual transfer - Validation list - Speed dial list - remarks - Language - Add row NOD=7 - Used Language - customer - Feature options - DB validation list - Speed dial list - Remarks NOC=1 IF lang=en then interface in English. NOC=1 IF lang=en then interface in English. - Similar to the counting as above. - Counting is based on the design detailed in 800A_V02E.dot and 800A_V02F.dot Similar to the counting above.

202 Rapport de comptage de 15 projets Add row Toll-free H NOD=6 No descriptions: NOT COUNT NOC=1 TOTAL NOD=23 NOC=3 I suppose that this function is still not designed in the system. System complexity These forms are independent, EOS = 0.

203 Rapport de comptage de 15 projets Case study 5: Project P2 Document source System Requirement Specification, version 2.0, October 25 th 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) Rules to create circuit ID (p.6): 3 - SWITCH_C LLI - Bay position - NPANXXD NNN This function is not counted in CFFP [SOL02]. Reads: 2 - customer ID (query) - port ID (query) Write: 2 - Circuit ID - Access circuit record Connection creation (p.9-11) Total: 5 Bulk 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 Total: 3 This function is not counted in CFFP [SOL02].

204 Rapport de comptage de 15 projets 190 Create record (p.12-13) connection - NCO - ATM service category. Write: Bulk connection Total: 11 Entries: 4 - Bell path Id - Service Id - service description - Client ID - NCOid Reads: 2 - Order status - Order action - ALT Write: 1 - Connection record Create segment record (p.14-15) Total: 7 Entries: 1 - Circuit ID Writes: 3 - Segment type - Protocol - FAC_ID - Rules to assign segment type: 4 (4 segment types) Create termination point record (p.16-17) Total: 4 Entries: 1 - Service cat. Id Writes: 5 - Segment ID - TP_ordinal - Port ID - Node ID - Protocol ID Total: 6 Total: 4 - rules for termination point records: 5 Create parameter service records Entries: 3 - manufacturer Total: 5

205 Rapport de comptage de 15 projets 191 parameter (p.18-19) records - 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 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

206 Rapport de comptage de 15 projets 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 USOC-SAC update (P.8 -Billing) - Read & show old value - Entry & Write new value NOD=2 - 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. NOC=3 - Real plus code OK (USOC = realp, Rplus; account based ) - Discount 15% 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. Three conditions to show three types of legends + images Similar to two updates above. - Update images portrait and landscape - - French English - Both CBSS pricing Pricing Adjustments - Real Plus NOD=2 - Read customer info. - Write 3 top numbers selected - Read old discount Suppose that this is a new function of system to convert pricing tables.

207 Rapport de comptage de 15 projets 193 table. - Write new discount (adjusted) for top 3 numbers - Discount 10% off the rest when 15$ is reached Pricing Adjustments - Real Plus Extra NOD=4 - Read customer info. - Write 3 top numbers selected - Read old discount table. - Write new discount (adjusted) - PIC Bell - eligible calls - 5% additional NOC= % discount 15% discount PIC Bell Removal USOC Realp from CBSS tables (P.16) Removal USO XNB from CBSS (P.16) This counting part is based on MD & Q2 specification NOD=4 NOC=6 - Read pricing table - Write (delete) the data satisfied the condition NOD=2 NOC=1 - Read pricing table - Write (delete) the data satisfied the condition NOD=2 NOC= Check condition (USOC=RealP & Rplus, account based, ) Check condition (USOC=XNB, account based, ) USOC/Sac update NOD=2 Similar to Real & realp

208 Rapport de comptage de 15 projets 194 CBSS update Pricing adjustments - project Q2 and MD NOD=2 NOD=9 TOTAL NOD = 31 NOC = 17 Each updated rate is counted as one data group. This project is not relevant to analyze the system complexity. System complexity: EOS=**

209 Rapport de comptage de 15 projets Case study 7: Project P11 Document source System design release 2, version 1.0, October 11 th 2000 Document quality Not functional document, not detail enough. Complexity Counting Functional processes Number of data groups (Information cues) Conditions Hypothesis Screen windows -program list R: List of program W: List of program (if add more programs) NOD=2 Add new program Counted in Edit Counted in Find Counted in Program definition DELETE Program level product financial NOC= Program Entries Entries - Manager ID - Program ID Read: - program options Exit - program options (send to sever to update) NOC = 4 Already counted in Entry: - program ID Read & Show on screen - channel, volume Exit (save) - channel, volume NOC=0 NOC=0 NOC=0 Next and previous buttons do not add more function 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 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.

210 Rapport de comptage de 15 projets 196 product financial details 2 Load default attrition rate Reports & data files Report/ document - program financial summary product level financial summary - 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 Entries - report name exits: (submit) - report name, regions NOD=2 - individual - visual call - simple connection - total NOD =4 - individual - visual call - simple connection - total NOC=0 NOC=0 NOC=0 NOD = User list Read and show: user list. NOD= Add new user Entry and Exit list (save) New user NOD=1 NOC=0 NOC=0 Next and previous buttons don t add new function segment list NOD =1 NOC=0 Similar to segment detail Similar to Save NOD=1 NOC=0 DELETE Entry: - Segment ID

211 Rapport de comptage de 15 projets 197 Write: - segment details NOD=2 NOC= product details Read: - portfolio code - revenue type - calc. option Entry & save - product info. - Chanel, volume NOD=5 NOC= Revenues Read: - Program, Revenue Write / exit: - Revenues summary NOD=2 NOC= Core and non NOD=2 NOC=0 Similar to core revenues New RPC report , 18, 19, 20 NOD=2x5=10 NOC=0 Not clear, but suppose that it is similar to 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 = **.

212 Rapport de comptage de 15 projets Case study 8: Project P13 Document source - System specification, version 2.4, July 13 th 2000 Document quality Not detail enough Complexity Counting Functional processes Information cues Conditions Hypothesis Monthly LD results reports (p.7) Top Country with history Families - 1A-7A, 1B Master Entry: - specified input criteria (p.8) Read: history data - 3 tables (p.8) Write and Exit: - history summary NOD= 5 E: - Criteria - Country - Month R: history W & X: summary NOD=5 Read: - history data Writes: - summary file for PACT and PAVG - SASSUM file - Text and delimited file Exit: - telco view NOC=5 Read - history data Writes: - Master 01 Input criteria: summary for business or residence NOC=1 Criteria NOC=1 8 conditions to create 8 different reports NOC=8 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.

213 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 The counting is similar to Master. Master As above Master As above Master As above Master 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 APP- telco: copy and load APP. running) Not count (not running) NOD=60 NOC=10 System complexity: EOS=**

214 Rapport de comptage de 15 projets Case study 9: Project P8 Document source Conceptual system flow, version 1.0, May 22 th 2000 Document quality Detail Complexity Counting Functional processes Information cues Conditions Hypothesis Dataload component Update file cleanup WEB client Entry: - directory - file write: - validate file - archive file - update MS- SQL server - event log Exit: - confirm to Oracle Unix. NOD =7 Read: - x number of days - Archive directory Write: - delete old files NOD = 3 Entry: - user code Exit: - HSE request Entry: - HSE request result Exit: - Show HSE request result (not count) NOD = 3 Event OK Error NOC =2 - if older than x days NOC=2 NOC=0

215 Rapport de comptage de 15 projets 201 HSE Winning Connection Web Site Access - ASP page (web server) IVR APP Entry: - User code Exit: - HSE qualificatio n request Entry: - HSE qualificatio n result - HSE to Web client (count) NOD =4 Entry: - HSE service request - Telephone number Exit: - Send MSG to MQ Entry: - Response MSG on the receiver Channel Exit: - HSE qualificatio n playback - number valid - service type valid NOC = 2 NOD = 5 NOC =0 MQ series Entry: - request MSG exit: - Request MSG Entry: - TN qualificatio n result Exit: - response MSG NOD =4 NOC =0 MQ series NOD=5 NOC=0 Read Post Queue NOD=5 NOC=0

216 Rapport de comptage de 15 projets 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

217 Rapport de comptage de 15 projets Case study 10: Project P9 Document source Product Specification, version 2.8, March 10 th 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 SMCX 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 Entry: - order from CEI write: - Datafill generation NOD=10 NOC=74 (count

218 Rapport de comptage de 15 projets 204 in the spec.) Not detail enough to count the system complexity, EOS = **

219 Rapport de comptage de 15 projets Case study 11: Project P14 Document source - System Functional design, version 1.1 February 28 th 2000 Document quality Detail Complexity Counting Functional processes Information cues Conditions hypothesis 1. Batch processing file header processing (p.5) 1.2 parse data billing file 1.3 load data from temp to billing table Entry: - billing input file Write: - Trace number Read: - Billing CTRtbl Exit: - log error NOD = 4 Entries: - billing data Write (in temp. file) - file header - record details NOD=3 Read: - billing data (temp. file) Exits: - account - log error (not balance) - log error (not successful) Write: - billing data Check trace # NOC=1 NOC=0 - balance with file trailer - check if account exits - check successful 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. Parse billing file data box

220 Rapport de comptage de 15 projets 206 (updated, new entry) NOD= 5 2. Payment Entries: input file - balancing 2.1 file header batch. processing - Envelop inf., - account inf. Write: - Trace number Read: - Billing CTRtbl Exit: - log error NOD=6 2.2 parse file of BOM Entry: - payment input file Exits: - balance file - batch info. NOC=3 Check integrity (#trace) NOC=1 - Check if file is BOM - 15 Checks on p.12 First line in the diagram on p load data from temp to payment table Writes: (not count for NOD) - update balance, - batch info (clear) NOD=5 Read: - billing data exits: - account - log error (not balance) - log error (not successful) Writes: - Payment data - Table NOC=16 - Check document type = C - type =D - account exist? - Successful?

221 Rapport de comptage de 15 projets 207 cheques - Unmatched table NOD=7 2.4 Audit and control Entry: table - entry in temp table writes: - payment batchctl - audit feed - payment control table (trace number) exit: - log error NOD=5 3. extract file Entry: - payment history data exists: - two payment files (BIP, unmatched) NOD=3 3. report NOD=2 (in, put) 4.1 sorting (p.22) 4.2 exporting (p.22) NOD=2 (in, put) 4.3 Audit and control NOD=2 report (p.25) NOC=4 - successful? NOC=1 NOC=0 4.4 audit and control NOD=2 monthly report 4.5 daily report NOD=2 4.6 unmatched report NOD=2 Unmatched monthly NOD=2 report Unmatched daily NOD=2 report Total 54 26

222 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

223 Rapport de comptage de 15 projets 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 / SUBPROCESS Platform IMPACT NOD NOC HIGH LEVEL PROCESS 1. Reformat 1.1 Pre-reformat processing MF RJ, RP * 1.2 Monthly Reformat processing Create Trans PC files for next month feed Datapac monthly processing 2. Update 2.1 Monthly update processing Generate current month universal files Process monthly Concert data feed VNET and CVNS monthly update process Generate Call Plan and Generic Revenue reports Download universals (CL0x) files to DW Download Signature Trans38 to DW Monthly load of universals (CL0x) 3. Customer Grouping / CPC 3. 1 CPC Interface 3.1 Customer Grouping Weekly Process weekly input from CPC Apply Telus Filter on Account input from CPC MF RJ, MJ, RP Read and write data in a new format Count as one data group NOD=2 MF MP Read and write data NOD=2 MF MP NOD=2 MF RJ, MJ NOD=2 MF MP NOD=2 MF RJ, MJ NOD=2 MF RJ, MJ Read: data input Write - Call plan - Revenu e report NOD=3 MF/DW RJ, MJ Entry and write the same data NOD=1 MF/DW MJ NOD=1 DW MOP Entry and write the same data NOD=1 MF MP Read data and write a report NOD=2 MF MP - Entry: account input - Read data - Write NOC=0 NOC=0

224 Rapport de comptage de 15 projets Process Customer input from CPC Process monthly input from CPC 3.2 Customer Build Build Customer Grouping extract files for download to DW (account.txt, customer.txt) Download Customer Grouping extract files Load Customer table Update Customer table Customer Table Conversion - Re-assign Telco Prime 3.3 View Customer Data 4. PIC 4.1 PIC Daily Processing 4.2 Toll PIC Weekly Processing 4.3 Toll PIC Monthly Processing 3..3 Customer Customized Screens and Reports Customer Selection screen Customer Hierarchy screen Customer drill down screens & reports Customer PIC Loss Report NOD=3 MF T * MF MP NOD=2 data after filterin g MF MP Write account Write customer NOD=2 MF/DW MP NOD=1 DW T * DW T * DW NP Read old value Write new conversion NOD=2 NAV MP Read and write customized: - Screen - Report NOD=2 NAV NI 0 NAV MP Modify to create a hierarchy screen NOD=1 NAV NI 0 NAV MP Read and exit (report) the same data group NOD=1 4.1 PIC Daily Processing MF RJ * Process daily PIC/CARE input transaction files Split Toll PIC / Local PIC data Transmit daily WOR file to Telcos 4.2 Toll PIC Weekly Processing Build PIC Transaction Summary (PTS) Download PTS extract file Load PTS table extract file 4.3 Toll PIC Monthly Processing Toll WTN Master Month end update Create Toll WTN Master extracts (split into Bus / Res and Matched / MF RJ * MF NI 0 MF RJ * MF RJ, MJ Read and write a summary NOD=2 MF / DW RJ * DW MOP NOD=1 MF RJ * MF RJ * NOD=2

225 Rapport de comptage de 15 projets 211 Unmatched Download WTN MF/DW RJ * Master Extracts Load WTN Master DW MOP NOD=1 Matched tables DQ WTN Master DW RJ * Matched table loads Load WTN Master DW MOP NOD=1 Unmatched tables DQ WTN Master DW RJ * Unmatched table loads Toll Equal Access MF RJ * Month end Update Build EA extract for MF RJ * Pic d accounts Download EA MF/DW RJ * Extract Load Toll EA Table DW MOP NOD=1 4.4 View PIC Data 4.4 Toll PIC Navigator Reporting Toll PIC Transaction Summary Reporting Toll PIC Account Loss Summary Reporting 5. Sales 5. 1 Sales Territory Process Telco monthly input Build Sales extract for download to DW Download Sales extract file 5. 2 National Sales Directory NAV MP Read and write a summary NOD=2 NAV MP NOD=2 MF MJ MOD=2 MF MJ MOD=2 MF/DW RJ, MJ NOD= Load Sales table DW MOP NOD= Summarize Sales MF MJ NOD=1 input Download NSD MF/DW T * extract file Load NSD Customer DW MOP NSD customer Sales and Sales Profile slaes tables Selaes profile NOD= Update NSD tables - Remove Telus Records (one time conversion) 5.3 View National 5.3 NSD Customized Sales Data Screen & Reporting 6. CDMA 6.1 CDMA monthly processing 7. Calling Card 7.1 Process Calling Card monthly input data 7.2 Download Calling Card extract file 7.3 Load Calling Card Telco tables 7.4 Load Calling Card National table 7.5 Convert Calling Card history (remove Telus data) 7.6 Calling Card Customized Screen and Reporting DW NP Read: data Conersion and update: data NOD=2 NAV T * MF MJ NOD=2 MF MP NOD=2 MF/DW T * DW MOP NOD=1 DW MP NOD=1 DW NP NOD=2 NAV Calling Card Telco NAV T * Read data and write Screen and reporting NOD=2

226 Rapport de comptage de 15 projets 212 specific views Calling Card NAV MP NOD=2 National Views 8. SIC 8.1 SIC Monthly MF MJ??? Processing??? Bell only??? 9. Call Detail 9.1 Call Detail monthly MF MJ NOD=2 processing 9.2 Download Call Detail MF/DW NI * extract file 9.3 Load Call Detail tables DW MOP NOD= Service Service Monthly MF RJ, MJ NOD=2 Processing 10. Downstream Interfaces 10.1 Advantage Toll Free 10.1 Advantage Toll Free interface monthly processing 10.2 CDC 10.2 CDC interface monthly processing 10.3 CND National 10.2 CND National interface monthly processing 10.4 Resporg 10.3 Resporg weekly / monthly processing Process input from SMS Generate output for external interface Transmit output to external interface 10.5 SHOCS 10.4 SHOCS monthly processing Extract Toll Detail and PIC Status 10.6 Sales Management System 10.7 XWAVE Solutions Summarize data for all Telcos Transmit output to external interface 10.5 SMS monthly processing 10.6 XWAVE Solutions (MTT Interface) Extract PIC WTN Master data Transmit output to external interface (MTT) 10.8 Customer 10.7 Weekly Customer Grouping Grouping Extract for Telus Extract and transmit Customer and Account data to Telus 10.9 TIC 10.8 Monthly TIC Extract Extract and transmit TIC file to Telus 11. Data Warehouse 11.1 Monthly Startup load Monthly Loads script 11.2 Monthly Load MF O/S Scope NOD=2 MF MI NOD=2 MF MI NOD=2 MF MP NOD=2 MF MI Read and write in a new format for external interface NOD=2 MF NI * NOD=2 MF MI Read data Extract (write) - toll detail - PIC status NOD=3 MF MI Read and summary NOD=2 MF NI * MF MI NOD=2 MF MI Read and write (new) NOD=2 MF NI * MF RI * MF RI * DW MP NOD=1

227 Rapport de comptage de 15 projets 213 System complexity EOS = * * Sequence Load MSC, NSB DW MOP NOD=2 ref tables (Telco specific) Load account DW MOP NOD=1 profile table (Telco specific) Load account detail DW MOP NOD=1 tables (Telco specific) Load account DW MOP NOD=1 summary tables (Telco specific) Load account DW MP NOD=1 summary tables (national) Load Cust Acct DW MP NOD=1 Xref table Load Customer DW MOP NOD=1 level summary tables 11.3 DQ Table Loads DW MP NOD= Monthly Navigator Cutover load script DW MP NOD=1 NOD=106

228 Rapport de comptage de 15 projets Case study 13: Project P3 Document source System Design Specification, version 3.1, august 7 th 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 Align status between CENTRACS and all associated downstream systems: TLOG and FLOG 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 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.

229 Rapport de comptage de 15 projets 215 Search facility on TLOG Receive PVC data NOD = 3 NOC=0 Entry: - filter criteria read - text file write: - push/pull files on a scheduled and on demand basis. exit: - filtered events NOD = 4 NOC = 0 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

230 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 Code a data exchange interface in CENTRACS: read: - PVC data write: - Data coding Exit: - data coding to PVC 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. As above *Not counted by Solange. Identification of appointment time NOD =3 x 6 protocoles = 18 NOC =1 Read: - 48 hrs - time stamp time - read MLR stamp type - MLRT = exit: ADP - appointmen t time * Not counted by Solange. Input multiple deferral time value NOD =3 Entry - selected time value read: - data from CENTRAC database Write: - deferral time value - update MTTR exit: NOC =2

231 Rapport de comptage de 15 projets 217 Pass Bay, Slot and Shelf Populate access time - to update Deferral Maintennac e in FOCUS - to show on screen - Categorizat ion events - NAT - DMT - ACS - WFR - NA - DM NOD = 15 NOC = 0 Entry: - bay, slot and shelf from SODB - Cable pairs - OE change Read: 1 - bay, slot and shelf from CENTRAC S Write: 1 - bay, slot and shelf from SODB \ CENTRAC S Exit: - show data on screen (not count) NOD = 5 NOC = 0 Entry - customer access time write: - access time to text logs exit: - access time to CALRS

232 Rapport de comptage de 15 projets 218 Pass CENTRACS and DSSC resolution Support forecasted number of service records Pass deferred time details from CENTRACS to FOCUS Populate work force downstrea m NOD = 3 NOC =0 Entry - Resolution codes Write: - resolusion codes (modify) Exits: - code translated - 2 err. msg NOD = 5 NOC =0 Enhancement, not development of new functions This part needs 15 person - days. Read: - Deferred time Write - total deferred time (modify) Exit: - Pass Deferred time to FOCUS - Total deferred time NOD = 4 NOC = 0 Entry: - WFR (DSSC user or external update) Write: - WFR (record) Exit - WFR (to CALRS) NOT COUNTED

233 Rapport de comptage de 15 projets 219 Identify modem type Indentify and adresse premium USOC Simply customer records Expand TTI to encompass TTS Create a ADSL network trouble report NOD = 3 NOC =0 Entry: - data from USOC write & Exit: - modem type exit: - modem NOC =0 type (not count) NOD =2 Entry: - USOC data Read - scan USOC write: - MLR type Exit: - show USOC NOD =4 NOC =0 Enhancement part This part need 20 person days Enhancement part 95 person-days Entry: - If the - Network transmission is trouble successful request - If unsuccessful Read: - network trouble in CENTRAC S Write: - Network trouble report - modify of user Exit: - TTS server log update (Err. Msg or audit) - Show on screen fro user NOT COUNTED NOT COUNTED

234 Rapport de comptage de 15 projets 220 Pass ADSL network trouble report updates to CENTRACS Pass ADSL network trouble report to COPS-TM via CENTRACS Pass ADSL network trouble report updates to FOCUS via CENTRACS Total: 14.4 manmonth NOD =6 NOC = 2 Entry - trouble report Write: - troupe report - update log file NOD =3 NOC= 0 Entry - update or not - trouble report Write: - troupe report - update log file NOD =3 NOC=2 Entry - trouble report Write: - troupe report - update log file NOD =3 NOC=0 NOD=116 NOC =8 Cannot count the EOS EOS=**

235 Rapport de comptage de 15 projets Case study 14: Project P26 Document source - System Design, version 2.0, March 6 th 2001 Document quality Detail Complexity Counting Functional processes Information cues Conditions Hypothesis Forms: volunteer Grant Request & Census (client) Forms: volunteer Grant Request & Census (server) Entries: - User profile - action code Exit: - request to server NOD=3 x 2 forms = 6 Enties: - submitted parameters Read: - database Write: - user profile (update) Exit: - request results - NOC=0 Action code: A, C, P, S There 2 forms: - Grant Request - Census 2 forms have the same pts, including 2 entries and one exit. 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 / Entry: - user profile update Exit: - request to server - request results (audit or error msg) NOD=3 NOC=0 List of participant Entries: select an action:

236 Rapport de comptage de 15 projets 222 (server) - add / delete / update Authentification client side Authentification LDAP delivery - user profiles submitted - action Write: - user profile Exit: - feed back to client side. NOD=4 Entries: - PEIN - Audit/ error msg Exit: PEIN (not count) NOD=2 Entry: PEIN Read: LDAP Exit: audit yes/ no NOD=3 Entry: - empl. Info. Exit: - to client add, delete or update NOC=3 NOC=0 Check if PEIN is correct NOC=1 PART PART is not a functional description Opening a form NOD=2 THIS IS A SOLUTION. It is counted below Entry: - parameters describe object exit: - object NOD=2 Entry: - form record (user profile) Read - lockinfo NOC=0 NOC=0 Lockinfo= Lockinfo # user ID Not clear to count But suppose that to create an object the process will receive some parameters and stretch out the object.

237 Rapport de comptage de 15 projets 223 Saving form Closing form Generation of.doc and.xls Write: - Lockinfo Exit: - error NOD=4 Entry: - form record (user profile) Read - timestamp (in memory) Write: - lockinfo - form record Exit: - error NOD=4 Entry: - form record read: - lockinfo - user ID write: - lockinfo (update) NOD=4 Entry: type of document (DOC or XLS ) Read: reported data NOC=2 Check time stamp NOC=1 Lockinfo=user NOC=1 7 conditions respecting to 7 types of document user defined reports This part counts for the section Search charity Orgs Exit: a document NOD= 3 NOC = 7 CANNOT COUNT THIS PART IS A LOW LEVEL OF THE SOLUTION. - IT IS NOT THE SAME ABSTRACTION LEVEL WITH OTHER PARTS. Entry: - search parameters - check parameters input (non

238 Rapport de comptage de 15 projets 224 Search profile Search Grant Reqs Read: - Database Exit: - request result - msg error NOD=4 Entry: - search parameters Read: - Empl. Profile - Read LDAP Exit: - request result msg error NOD=5 Entry: - search parameters Read: - Database Exit: - request result - msg error blank) - check if operation is success NOC=2 - Check vntempnumber (contain PEIN) - Check if the operation is success NOC=2 - check parameters input (non blank) - check if operation is success NOD=4 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 NOC=2 - ten conditions respecting to 10 output values - check vntparticipant (at least one row) Create a empty record set & new record set NOD=4 Read: 3 tables - structure of table write: 3 - record set structure exit: - operation result (0,1) NOC=11 Check if the operation is success

239 Rapport de comptage de 15 projets 225 NOD=7 NOC= 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: . 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

240 Rapport de comptage de 15 projets Case study 15: Project P1 Document source - System Specification, version 1.20, May 16 th Product requirement document, version 2.3, May 12 th Document quality Not enough detail. Complexity Counting Functional processes Number of data groups (Information cues) Conditions Hypothesis Load_merlin: Import data from Merlin Load_location Load locations from some where Update_from_merlin Update data from Merlin - R: merlin_locatio n - R: telco NOD =2 NOC = 0 - R: locations - R: hist_locations NOD = 2 NOC = 0 - W:locations - W: merlin locations NOD = 2 NOC = 1 Frames (p.17-18) NOD = 49 NOC = 0 (Counted directly in the document) Import without modifying data. Read Locations without modifying this data group. It is similar to import data from Merlin, but there is at least one condition to decide that is an Update or a Delete. 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

241 Rapport de comptage de 15 projets 227 Screen 04 - add Region profile NOD=0 Screen 06 - Read: USER ID. - Read USER audit. - Read and show: list of host (from IPS-TDS table) - Write: switch CLLIs and remotes NOC=0 o If telbec user. o If the telebec has a groups permissio n add a third choice is a screen design so it is not count as a function. Screen 21 Screen 86, 91, 99 Screen 67 Screen 77 NOD=4 Screen design: not count E: user ID R: - list of Telebec host - list of common hosts NOD = 3 Entry: - user id Read: - list of host Telebec - list of common hosts. Exit: - error msg when accessing to screen error msg when accessing to screen 120. NOD = 5 Entry: - user ID Read: - list of NOC = 2 Verify: if a Telbec user NOC=1 If (user = telebec) If (user = telebec) and (hosts<>telebe c host) If (lang=french) then show msg in french. NOD =3. If Telbec user Modify to show only Telbec host and CLLI common host for Telbec user The same function one of these three screens is counted.

242 Rapport de comptage de 15 projets 228 components and qualifiers - list of CLLI NOD = 3 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 NOC=1 If (ID=telebec) then ownership = telebec If (ID=bell) then ownership=be ll. Screen 101 Screen 22 Screen 110 Screen 87 Screen 70 Screen 88 NOD = 4 Read & Exit - new qualifier NOC = 2 NOD = 2 NOC =0 Read & exit - ownership NOD=2 NOC=0 Entry: If Telbec user - user ID Reads: - components - qualifiers NOD = 3 NOC=1 Entry: If Telbec user - User ID - CLLI If (pick Reads: CLLI==1) - components - qualifiers - telebec hosts - common hosts NOD = 6 NOC=2 Entry: If telbec user - user ID Reads: - CLLI - Components - Qualifiers NOD = 4 Entry: - user ID NOC=1 If Telbec user Tag change when changing qualifier name: one entry and one exit Tag change when changing CLLI

243 Rapport de comptage de 15 projets 229 Screen 53 Screen 111 Report 84 Report 89 Same as report 84 Report 90 - component selected read: - qualifiers NOD = 3 The same as 88: not count Entry - user ID Read: - CLLI Write - Add new telbec CLLI NOD = 3 Entry - user ID Reads: - telbec host - common hosts - components - qualifiers NOD = 5 Not count Entries - user ID - CLLI selected Read: - telbec hosts NOC=1 If Telbec user NOC=1 If telbec user NOC=1 If telbec host Report 94, 96,97,98 Similar to 90 Report 118 Screen 36 Screen 122 The same as 118 Screen 123, 124 NOD = 3 NOC=1 NOD = 3 NOC=1 Count only one time for 4 reports because they are essentially the same. Entry If telbec user - user ID Read - telbec hosts NOD = 2 NOC=1 Screen design: not count Not count Entry - user ID Read - CLLIhosts If Telbec user If Bell user

244 Rapport de comptage de 15 projets 230 NOD = 2 NOC=2 Screen 07 Entry If (first - user ID access) Reads: - telbec hosts If (user - remote CLLI =telebec) and - error msg (lick on Write: report) - number of access NOD =5 NOC = 2 Screen 37 Not count TOTAL 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.