Analyse et conception d un modèle de qualité logiciel

Transcription

1 Université Vincennes Saint-Denis Paris 8 LIASD EA 4383 Analyse et conception d un modèle de qualité logiciel THÈSE présentée et soutenue publiquement le 3 décembre 2012 pour l obtention du Doctorat en Informatique Université Vincennes Saint-Denis Paris 8 par Karine Mordal Composition du jury Rapporteurs : Fabrice Bouquet Professeur des universités, Université de Franche-Comté Salah Sadou Maître de conférences, HDR, Université de Bretagne Sud Directeur : Françoise Balmas Maître de conférences, HDR, Université Saint-Denis Paris 8 Examinateurs : Stéphane Ducasse Directeur de recherches, INRIA Lille Laboratoire RMod Nicolas Anquetil Maître de conférences, INRIA Lille Laboratoire RMod Harald Wertz Professeur des universités, Université Saint-Denis Paris 8 Patrick Greussay Professeur des universités, Université Saint-Denis Paris 8 Philippe Vaillergues PDG des entreprises Henix et Qualixo

2

3 Résumé Nous présentons un modèle d évaluation de la qualité pour des logiciels de taille industrielle, le modèle Squash, fondé sur le modèle empirique conçu par les entreprises Qualixo et Air-France KLM. A partir de l étude des normes ISO 9126 et SQuaRE notamment, tout en nous appuyant sur les savoir-faire métier issus des domaines du développement informatique et de la validation fonctionnelle, nous avons déterminé une méthodologie précise d évaluation de principes de qualité, tant au niveau technique que fonctionnel. A partir de notre méthodologie nous avons formalisé un modèle de qualité prenant en compte les particularités et exigences du domaine industriel. L implémentation de ce modèle est en cours de validation chez Generali. Ce modèle est composé de deux niveaux : le niveau conceptuel de la qualité qui définit les grands principes de qualité à évaluer et le niveau technique de la qualité qui décrit des règles techniques de base et les mesures associées permettant l évaluation du niveau supérieur. La principale difficulté dans l élaboration de ce type de modèle consiste à déterminer comment passer des principes de qualité aux mesures et vice versa, tout en respectant deux principes fondamentaux : ne pas masquer les progrès et mettre en évidence les problèmes. Pour y parvenir nous utilisons d une part, des formules de combinaison et d agrégation de métriques et d autre part, des formules à base de logique floue permettant d évaluer la qualité à partir de mesures non issues de métriques. Nous avons principalement travaillé à la formalisation des différentes couches du modèle et à la validation des formules utilisées dans celui-ci. De plus, nous avons également formalisé les règles d évaluation de la qualité d un point de vue fonctionnel et entièrement redéfini les règles d évaluation qui reposent sur des données non numériques telle que les audit d experts ou les documents annexes au programme (documentation, ou cahier des charges par exemple). Abstract We present a model for analysing and evaluating the quality of industrial software, named Squash model, based on the empirical model developed by Qualixo and Air France-KLM enterprises. We determine an evaluation methodology for both technical and functional quality principles based on studying ISO 9126 and SQuaRE standards, industrial skill in software development and functional validation. From our methodology we formalized a quality model taking into account the particularities and requirements oh industrial applications. The implementation of this model is being validated at Generali. This model is divided into two levels : the conceptual quality level that defines the main quality principles and the technical quality that defines basic technical rules and measures used to assess the top level. i

4 The main issue of quality model conception is how to fill the gap between metrics and quality principles : metrics often defined for individual components cannot be easily transposed to higher abstraction levels. Furthermore, we need to highlight problems without hiding progress. To achieve this, we use combination and aggregation formulas to assess quality principles from metrics measurements and fuzzy logic (to assess quality principles) from non-metric measurements. We mainly work on the architecture model formalization and we validate the formulas used in the model. Furthermore, we also formalize the rules for evaluating the quality of a functional point of view and we completely redefined the assessment rules based on non-numeric data such as audit expert or program related documents (documentation or specifications for example). ii

5 Remerciements Ce travail n aurait jamais abouti sans l aide de personnes que je tiens tout particulièrement à remercier ici. D une part, je tiens à remercier ma directrice de thèse, Françoise Balmas, qui m a aidée et qui m a fait confiance, que ce soit pour la thèse mais également pour les deux projets de recherche auxquels j ai participé. Elle a toujours été présente, tout au long de mes études et m a sans cesse encouragée à persévérer année après année. Toute ma gratitude va également à Monsieur Philippe Vaillergues, PDG des sociétés Qualixo et Henix qui a appris à me connaître sur le projet Squale et qui m a renouvelé toute sa confiance en me permettant de participer au projet qui a suivi, le projet Squash. Je tiens également à remercier tous les membres des projets Squale et Squash qui m ont permis d apprendre tant de choses et sans qui ma thèse n aurait pu aboutir de cette manière. De même, je remercie les membres du club qualimétrie, club qui m a permis de mieux comprendre ce qu évaluer la qualité signifie en entreprise. Les membres du laboratoire RMod de L Inria Lille qui m ont accueillie au sein de leur laboratoire à maintes reprises et qui m ont appris à écrire des articles de recherche scientifique avec tant de patience et de persévérance. En particulier Stéphane Ducasse et Nicolas Anquetil, sans qui cette thèse n aurait sans doute jamais vu le jour et qui m ont soutenue tout au long de ces années. J ai collaboré avec Alexander Serebrenik et je tiens à le remercier pour ses compétences mathématiques qui m ont aidée à formaliser les propriétés mathématiques de la formule de Squale. Je tiens également à remercier Fabrice Bouquet, pour son professionnalisme doublé d une bonne humeur toujours égale. Travailler avec lui est un réel plaisir. Je tiens aussi à remercier Salah Sadou qui a accepté d être rapporteur de ma thèse. Je remercie Thomas Sermier, ingénieur à l Inria, sur le projet Squash, qui a patiemment développé le plugin Squash à partir de mon modèle. J ai une pensée émue pour Thomas McCabe, rencontré lors d une réunion du club qualimétrie et qui a manifesté un intérêt au modèle de qualité qui a été pour moi un véritable encouragement. J ai une pensée particulière pour Harald Wertz et Patrick Greussay, figures emblématiques de Paris 8 et pour les membres du laboratoire LIASD qui m ont supportée depuis tout ce temps. Je tiens tout particulièrement à remercier Isis Truck qui a su être présente au moment crucial de l écriture de ma thèse et me tirer d affaire, qui a toujours eu de très bons conseils et des encouragements qui m ont permis de ne jamais me décourager. Je remercie Sion Elbaz pour ses critiques et remarques pertinentes qui m ont obligée à me dépasser et qui me donne tant d idées pour continuer mes recherches, pour son soutien de tous les jours, pour son exigence et pour tout ce qu il sait. iii

6 iv

7 Table des matières Table des figures xi Introduction générale 1 Chapitre 1 Etat de l art et contexte Modèles d évaluation de la qualité Le modèle de McCall : Facteurs Critères Métriques FCM La Norme ISO 9126, qualité des produits logiciels SQuaRE, Software product QUAlity Requirement and Evaluation Le modèle GQM (Goal Question Metrics) Quelques autres modèles de qualité Sonar : un outil d évaluation de la qualité Conclusion Les métriques de code Vocabulaire Les métriques de code conventionnelles Les métriques de code orienté objet Les conventions de codage Conclusion Les techniques de tests Les tests en boîte blanche v

8 Table des matières Les métriques de tests structurels Tests fonctionnels Conclusion Conclusion Chapitre 2 Le modèle Squale Présentation générale de Squale Squale : un modèle hiérarchique en quatre couches Les mesures Les pratiques Les critères Les facteurs Le calcul des notes de Squale Les pratiques de code Les pratiques de normes et standard Les pratiques documentaires Les pratiques de modèle Les pratiques de tests L implémentation de Squale Conclusion Chapitre 3 Evaluer la qualité : définitions et propriétés Présentation générale Que signifie évaluer la qualité Propriétés et architecture d un modèle de qualité L architecture d un modèle de qualité Déterminer le périmètre d évaluation de la qualité Les propriétés d un modèle de qualité vi

9 3.4 Evaluer la qualité à partir des mesures Evaluer la qualité à partir de métriques L agrégation de métriques L agrégation des métriques dans la littérature scientifique L agrégation de mesures non issues de métriques Exigences pour l évaluation de la qualité logicielle Conclusion Chapitre 4 Présentation du modèle Squash L architecture de Squash Le niveau conceptuel de Squash Les facteurs de Squash Les critères de Squash Validation du périmètre d évaluation Définition du niveau technique de Squash Les pratiques de Squash Les mesures de Squash Conclusion Chapitre 5 Evaluation de la qualité dans Squash L évaluation des facteurs et des critères Les pratiques de code : la validation des formules de Squale Formalisation des notes des pratiques de code Validation théorique de la formule I Squale L évaluation de la qualité à travers les pratiques documentaires Les valeurs des caractéristiques des pratiques documentaires L agrégation des caractéristiques L exemple d une pratique documentaire vii

10 Table des matières 5.4 Conclusion Chapitre 6 Validation du modèle Squash Validation des exigences d évaluation La validation des exigences d évaluation des indices d inégalité économiques La validation des exigences d évaluation de la formule I Squale Validation des exigences pour les pratiques documentaires Evaluation expérimentale des pratiques de code Conditions expérimentales Résultats Limites de l expérience Conclusion Validation des propriétés de Squash L implémentation du modèle Squash Les différentes vues du modèle Squash Conclusion Chapitre 7 Vers un plan de remédiation du code Les tâches abordées par Squash La transgression : de l utilisation des pratiques La tâche de remédiation : la portée d une action Coût de remédiation : de la mesure de l effort L aspect organisationnel du plan de remédiation Choisir une stratégie Stratégie utilisée par Squash : Stratégie mixte du coût et des priorités Les limitations du plan Conclusion Conclusion générale 177 viii

11 1 Le travail effectué Perspectives Annexe 181 Annexe A Les pratiques du modèle Squash 181 A.1 Les pratiques de code A.2 Les pratiques de normes et standard A.3 Les pratiques de modèle A.4 Les pratiques de tests A.4.1 Les pratiques de tests de développement A.4.2 Les pratiques de tests fonctionnels A.4.3 Les pratiques de tests automatisés A.4.4 les pratiques de tests applicatifs A.4.5 Les pratiques de tests système A.4.6 Les pratiques de tests de sécurité A.4.7 Les pratiques d organisation des tests A.5 Les pratiques documentaires Bibliographie 259 ix

12 Table des matières x

13 Table des figures 1.1 Les facteurs et les critères du modèle FCM Un exemple de graphe de flot de contrôle avec les trois différents chemins linéairement indépendants Un exemple de graphe de flot de contrôle simplifié Un exemple simple de graphe pour illustrer les métriques LCOM avec m i les méthodes appelées par d autres méthodes ou accédant aux attributs a j Chaque module est représenté par une boîte contenant des carrés. Il s agit soit d une classe contenant des méthodes et des attributs, soit d un package contenant des classes. Le couplage efférent est représenté par les modules rouges (Ce = 2) ; le couplage afférent est représenté par les modules bleus (Ca = 2) Graphe de flot de contrôle de l algorithme Hiérarchie des critères de couverture Chemins vérifiés avec un taux de couverture de lignes de code à 100% Chemins vérifiés avec un taux de couverture de branches à 100% Chemins vérifiés avec un taux de couvertures de chemins à 100% La pyramide du modèle Squale Une vue du modèle Squale Les mesures du modèle Squale, classées en quatre groupes Les pratiques du modèle Squale Les critères du modèle Squale Principe de pondération : les notes individuelles sont diminuées lorsqu elles sont transposées dans l espace pondéré Les notes globales obtenues pour les deux séries des tables 2.4 et Une vue du tableau de bord de Squale Une vue détaillée d une pratique dans Squale xi

14 Table des figures 3.1 La courbe des poids pour la métrique SLOC Une vue du modèle Squash Comparaison entre les facteurs de ISO 9126, de SQuaRE et du modèle Squash Les critères du modèle Squash Les pratiques du modèle Squash Un extrait des mesures du modèle Squash, classées en cinq groupes Courbe de la fonction de combinaison de la pratique taille de la méthode Déplacement latéral d une étiquette linguistique le 2-tuple (s 2, 0.3) Notes non uniformément distribuées sur l axe Exemple de partition floue utilisant une hiérarchie linguistique à 3 niveaux Echelle de conversion numérique de la note Les résultats des expériences de toutes les formules d agrégation (voir le texte pour explication). La figure la plus élevée à gauche affiche la légende commune Une vue globale de Squash Un exemple de vue de Squash s adressant aux développeurs Les différents acteurs identifiés La vue développement La vue production La vue modèle La vue tests Les étapes du plan de remédiation xii

15 Introduction générale De nos jours les entreprises se préoccupent de plus en plus de la qualité des logiciels qu elles utilisent. Les nombreuses pannes et erreurs logiciels les sensibilisent de fait à se préoccuper de la qualité. En effet, les exemples de pertes de chiffre d affaire dues directement à des pannes logiciels se multiplient. Pour exemple, le crash de la navette Ariane 5 en 1996 qui s est brisée 40 secondes après le décollage à cause d un bogue informatique dans le système de pilotage automatique. Un bogue qui a provoqué une perte de 370 millions de dollars. Ou encore le site de vente en ligne Ebay indisponible pendant 22 heures en 1999, qui entraina une perte pour le groupe estimé entre 3 et 5 millions de dollars. De plus, le coût des logiciels n a cessé d augmenter ces dernières années. Notamment le coût lié à la maintenance logiciel, à savoir principalement la corrections des erreurs, qui peut représenter jusqu à plus de la moitié du coût total de conception. C est pourquoi il est de plus en plus important pour les entreprises de disposer d un système le plus fiable possible et de pouvoir mesurer la qualité des systèmes qu ils utilisent. Evaluer un logiciel permet à la fois d obtenir une image précise de la qualité de ce dernier mais peut également fournir une indication quant à son comportement dans le temps : quels sont les risques de bogues, les éventuelles failles sécuritaires, les difficultés de maintenance, les freins à l évolution, la viabilité à long terme, etc. De plus, évaluer la qualité d un logiciel peut également servir d outil pour déterminer si le logiciel correspond aux attentes du client : un outil leur permettant d évaluer la qualité du produit délivré par un prestataire extérieur. Un des objectifs de la mesure de la qualité logicielle consiste également à sensibiliser les équipes de développement sur leur méthodes de programmation. En effet, mesurer la qualité a de surcroît pour objectif de formaliser de bonnes pratiques de travail et des indicateurs permettant d augmenter la qualité des développements. De même, vouloir mettre en place une mesure de la qualité oblige à formaliser les processus de conception au sein d une entreprise, en commençant par l expression la plus précise possible des besoins, jusqu aux processus de tests mis en place pour vérifier l adéquation entre les fonctionnalités du logiciel et ses objectifs. S il est souhaitable pour une entreprise de mettre en place des processus permettant à la fois d évaluer la qualité de ses applications et d augmenter la qualité de ses développements ultérieurs, cette démarche peut s avérer compliquée. Il faut en effet dépenser du temps à la mise en place des processus, bousculer parfois les habitudes de travail et consacrer un budget dédié à la qualité. De plus, effectuer un audit qualité par exemple n est pas obligatoirement synonyme de réussite. Pour être efficace, une démarche qualitative doit s inscrire dans la durée et s étendre au savoir-faire de l entreprise, à la mise en place de méthodes de travail, et ne pas se contenter d évaluer les applications au cas par cas. Une démarche qualitative globale doit donc s effectuer en plusieurs étapes : analyser les objectifs qualitatifs de l entreprise, évaluer les résultats qualitatifs des applications, tirer de cette 1

16 Introduction générale évaluation des objectifs d amélioration de la qualité. De plus, un logiciel de qualité ne signifie pas obligatoirement exempt de toute erreur. Il faut donc garder à l esprit que mesurer la qualité n est pas un gage de perfection mais une démarche de perfectibilité. Nos travaux portent donc sur l élaboration d un outil permettant à la fois de fournir une image de la qualité du logiciel mais également de donner aux entreprises des moyens d améliorer la qualité, à la fois du logiciel mais aussi de leur processus de conception et d organisation : fournir une image de la qualité à un instant donné tout en pointant concrètement les actions à mener pour augmenter le niveau de qualité. Mesurer la qualité d un logiciel nécessite tout d abord de définir précisément ce que l on entend par qualité. Partant de la définition générale de la qualité Ce qui fait qu une chose est plus ou moins recommandable, par rapport à l usage ou au goût humain, qu une autre de même espèce ; degré plus ou moins élevé d une échelle de valeurs pratiques [Rob, 2012] nous devons également prendre en compte la notion de qualité appliquée à un logiciel. En effet, dans ce domaine précis, il existe un certain nombre de définitions de la qualité, que ce soit des définitions au sein de normes de type Iso ou bien des définitions propres à une entreprise ou encore à un outil de mesure de la qualité. Ces définitions ont toutes des points communs mais également des différences de point de vue. Il nous faut donc dans un premier temps définir ce que nous entendons par le terme qualité. De plus, la notion de qualité est souvent subjective : elle varie en fonction des exigences, du métier, de la relation que l on a avec le logiciel, du type même de logiciel. La qualité est-elle définie de la même manière selon que l on soit le client (celui pour qui le logiciel a été conçu), l utilisateur (celui qui se sert du logiciel au quotidien), le développeur (celui qui écrit les lignes de code), le testeur (celui qui valide le logiciel), ou encore le manager. Nous devons donc également définir précisément cette notion : le périmètre de l évaluation. Plus précisément, que voulons-nous évaluer? Une fois le champ d évaluation précisé, il faut alors formaliser des règles correspondant à chaque périmètre évalué. Il s agit de répondre à la question suivante : comment traduire la notion de qualité en fonction des acteurs ciblés? Au sein d un même périmètre, par exemple la validation du logiciel, le technicien de tests a-t-il les mêmes exigences que le responsable de la validation? La conception d un modèle de qualité doit donc prendre en compte les différents acteurs auxquels il s adresse. Que ce soit le manager, le développeur ou le technicien des tests, le modèle doit être utile à chacun d entre eux et facilement compréhensible par tous. Il doit lui fournir de manière claire et précise uniquement les informations qui l intéresse dans un formalisme traduisant le savoir-faire métier du domaine. Une fois les règles définies, il faut alors décider des indicateurs de qualité qui permettront l évaluation de celles-ci. Quels indicateurs sont utiles pour un développeur ou pour un manager? De quels indicateurs disposons-nous pour donner une vue adéquate de la qualité? Chaque groupe de règles doit être décrit précisément et mesuré le plus précisément possible. Un modèle de qualité repose donc sur des mesures qui doivent être fiables et interprétables en terme de qualité. Par exemple, déterminer la qualité des tests effectués sur le logiciel doit se baser sur des mesures objectives, comparables et calculables facilement. Tout comme déterminer la qualité du code source en collectant les résultats de métriques de code doit préalablement comporter une étape de définition précise des métriques utilisées. En effet, calculer le nombre de lignes de code par exemple parait au premier abord trivial. Cependant, cette métrique de code possède une multitude de définitions : les lignes de codes et les lignes de commentaire, les lignes de code et les lignes blanches uniquement, les lignes d instructions, par exemple. Il faut donc définir précisément les métriques utilisées. Il faut également déterminer parmi toutes les métriques disponibles quelles seront les métriques pertinentes, celles qui 2

17 permettront de fournir une information utile à la qualité. Un modèle de qualité fiable doit reposer sur des métriques précises, objectives, calculables et définies sans ambiguïté [Grubb et Takang, 2003] pour fournir une évaluation incontestable de la qualité. Les indicateurs étant choisis, il faut ensuite définir le sens à donner aux différentes mesures : définir comment évaluer la qualité de manière pertinente, construire un système capable de fournir des mesures et de les interpréter correctement. Plante souligne que mesurer c est attribuer une quantité quelconque à un phénomène ou à un objet, à partir d une règle d attribution déterminée a priori (...) Il convient donc de distinguer la mesure de l évaluation qui, elle, porte un jugement de valeur en comparant les données obtenues à la suite de la mesure avec des critères, des normes ou des standards [Plante, 1994]. Un modèle de qualité doit donc non seulement mesurer mais également évaluer : faire un lien entre les métriques de bas-niveau et les règles de plus haut niveau pour évaluer ces dernières. Il s agit du plus difficile à réaliser dans un modèle de qualité. Par exemple, pour évaluer la qualité d un code, il faut pouvoir formaliser ce que l on entend par code de qualité, mesurer le code à l aide de métriques et faire un lien entre les mesures et les règles. Comment passer par exemple d une mesure du nombre de lignes de code effectuée sur les différents composants du logiciel à l évaluation d une règle qui détermine si le code source dans sa totalité est équilibré en terme de lignes de code? Comment passer d un ou plusieurs résultats de métriques (pour l ensemble du code ou par composant) à une évaluation globale d une règle de qualité? Un modèle de qualité doit donc faire un lien entre des métriques pertinentes et significatives et des règles à évaluer. Il faut arriver à passer d un niveau détaillé à un niveau plus général en conservant le niveau d information délivré par les métriques. De plus, mesurer une règle nécessite souvent d utiliser plus d une seule métrique. Ce qui engendre une nouvelle difficulté. En effet, chaque métrique donne une mesure dans un intervalle qui lui est propre. Comment alors composer deux métriques ensemble et garantir que le résultat obtenu donnera une évaluation correcte de la règle mesurée? Pour construire un modèle de qualité il faut donc respecter un certain nombre de contraintes : défnir le périmètre évalué, le formaliser, prendre en compte les acteurs auxquels il s adresse, définir les bons indicateurs, faire le lien entre mesures et qualité et enfin, délivrer l information de manière simple à comprendre. Toutes ces étapes doivent être accomplies en gardant à l esprit l objectif du modèle de qualité : obtenir une vue de la qualité du logiciel mais également permettre d améliorer la qualité du logiciel lui-même tout comme des processus de conception. Les modèles de qualité existant sont en général des modèles hiérarchiques qui définissent des facteurs des groupes regroupant des principes de qualité des règles ces principes reposant eux-même sur des métriques qui permettent l évaluation de ces règles. Evaluer la qualité signifie mesurer. Cette étape constitue le niveau inférieur d un modèle de qualité. Celui-ci évalue le logiciel analysé à partir de mesures obtenues grâce au code source, à la documentation, aux annexes techniques, aux règles de conception ou tout autre information disponible pour le projet. Les informations collectées doivent être précises et objectives et les mesures établies doivent suivre des règles précises pour que le modèle donne une vue la plus précise possible de la qualité. Nos recherches ont été effectuées dans le cadre de deux projets recherche, à partir d un modèle de qualité pré-existant, le modèle Squale. Celui-ci a été construit de manière empirique par les développeurs de Air France-KLM et l entreprise Qualixo, deux des partenaires du premier projet de recherche. Nous avons tout d abord défini les étapes à suivre pour formaliser ce modèle : valider une architecture pour le modèle, recenser les propriétés pour lesquelles nous souhaitons valider le modèle, définir les domaines d évaluation, définir les règles de qualité à évaluer pour ces domaines, préciser les 3

18 Introduction générale métriques et les mesures à utiliser pour évaluer ces principes et enfin, déterminer comment évaluer les principes de qualité à partir des mesures effectuées. Une étude de l existant nous a permis de définir précisément ce que signifie pour nous le terme de qualité, ainsi que de valider l architecture du modèle selon deux niveaux différents : le niveau conceptuel et le niveau technique. Nous avons alors posé les propriétés que nous attendons d un modèle de qualité en fonction d une part des points forts des normes de qualité et d autre part des exigences et attentes de nos partenaires industriels. Nous nous sommes ensuite intéressés aux règles de qualité et aux mesures qui permettent de les évaluer. Nous avons d une part repris les règles existant dans le modèle Squale et d autre part formalisé de nouvelles règles, celles permettant notamment de préciser comment évaluer la qualité de validation fonctionnelle d une application. Une fois ces règles posées, nous avons évalué les mesures disponibles et retenu celles qui nous sont apparues comme de bons indicateurs de qualité. Nous nous ensuite sommes attachés à déterminer comment transcrire les résultats de métriques et les documents se rapportant au logiciel en terme d évaluation de la qualité. Nous avons repris les formules qui composaient le modèle Squale et nous les avons validées et formalisées. Nous avons également construit un autre mode d évaluation à partir de la logique floue, pour nous permettre de transposer de manière fine et précise les évaluations de qualité résultant d audit. Le résultat de nos recherches nous a permis de formaliser une nouvelle version du modèle : le modèle Squash. Notre thèse s organise de la manière suivante. Nous analysons tout d abord les modèles de qualité et les normes existants sur lesquels reposent le modèle de qualité que nous proposons (Chapitre 1.1). Nous analysons en quoi ces modèles hiérarchiques permettent de définir le niveau conceptuel de la qualité mais également leurs limites dans l évaluation précise de ces concepts. Nous détaillons ensuite les métriques de code (Chapitre 1.2) ainsi que les techniques de tests (Chapitre 1.3) que nous avons utilisées dans l élaboration du modèle de qualité présenté ici. Les métriques de code ont fait l objet d une analyse détaillée permettant de les définir précisément et de préciser ce que chacune d entre elles mesure et en quoi ces mesures peuvent donner des indications quant à la qualité du code analysé. L analyse des techniques de tests nous a permis de définir précisément comment les transcrire sous forme de règles de qualité à évaluer. Le chapitre 2 présente le modèle Squale et son fonctionnement. Tout d abord nous décrivons son architecture hiérarchique en couches, fondé sur le modèle de McCall et la norme ISO Nous détaillons la particularité de ce modèle de qualité constitué d une couche intermédiaire entre les mesures et les concepts de qualité évalués : les pratiques. Cette couche permet de définir précisément des règles techniques de base à évaluer, elle traduit le savoir-faire métier en règle à suivre ou à éviter pour concevoir un logiciel de qualité. Puis, nous expliquons comment le modèle évalue la qualité, c est-à-dire comment il transforme les mesures effectuées en une évaluation des concepts de qualité. Nous discutons ensuite de la notion de qualité et nous présentons les propriétés que nous attendons d un modèle de qualité (Chapitre 3). Nous précisons pourquoi nous avons retenu une architecture hiérarchique en quatre couches pour notre modèle et nous définissons ces quatre couches, réparties dans les deux niveaux, conceptuel et technique. Puis nous expliquons en quoi les principales techniques classiques d évaluation de la qualité ne donnent pas de résultats satisfaisants et nous étudions les techniques émergentes d agrégation reposant sur les indices d inégalité économiques (Chapitre 3.4). A partir de cette étude, nous listons les exigences qu un modèle de qualité doit satisfaire pour évaluer la qualité. 4

19 Nous présentons ensuite le modèle Squash, issu du second projet de recherche (Chapitre 4). Ce modèle est fondé sur le modèle Squale, l étude des modèles de qualité existants et les exigences des partenaires du projet de recherche. Nous expliquons comment, à partir de nos réflexions présentées dans le chapitre précédent, nous avons redéfini le niveau conceptuel du modèle, divisé en deux couches : les facteurs et les critères. Nous détaillons ensuite le niveau technique du modèle constitué des pratiques et des mesures. Nous expliquons comment nous avons formalisé les pratiques autour du métier de la validation fonctionnelle du logiciel. Dans le chapitre suivant (Chapitre 5), nous expliquons comment le modèle Squash évalue la qualité à partir des mesures. Nous présentons nos travaux de formalisation des formules issues du modèle Squale permettant l évaluation de la qualité à partir de métriques de code et nous présentons nos travaux sur l évaluation de la qualité à partir de mesures non-issues de métriques : nous expliquons en quoi les techniques issues de la logique floue nous permettent d affiner cette évaluation. Puis, nous présentons nos travaux de validation de ces modes d évaluation dans le chapitre 6. Nous expliquons également en quoi le modèle Squash répond aux attentes que nous avons définies dans le chapitre 3. Enfin nous proposons un plan de remédiation du code (Chapitre 7). Ce plan est défini à partir des pratiques du modèle Squale. Nous présentons la version du plan telle que défini actuellement et nous proposons des pistes pour améliorer cette première version afin de la rendre efficiente. Nous concluons en présentant les différents travaux sur lesquels nos futures recherches porteront. L annexe A présente les définitions des pratiques du modèle Squash actuellement en cours de validation chez Generali. Elle donne les définitions de chaque pratique ainsi que les formules d évaluation associées. 5

20 Introduction générale 6

21 Chapitre 1 Etat de l art et contexte Sommaire 1.1 Modèles d évaluation de la qualité Le modèle de McCall : Facteurs Critères Métriques FCM La Norme ISO 9126, qualité des produits logiciels SQuaRE, Software product QUAlity Requirement and Evaluation Le modèle GQM (Goal Question Metrics) Quelques autres modèles de qualité Sonar : un outil d évaluation de la qualité Conclusion Les métriques de code Vocabulaire Les métriques de code conventionnelles Les métriques de code orienté objet Les conventions de codage Conclusion Les techniques de tests Les tests en boîte blanche Les métriques de tests structurels Tests fonctionnels Conclusion Conclusion Mesurer la qualité d un logiciel consiste à formaliser un certain nombre de principes de qualité et à déterminer si le logiciel évalué y répond. Il faut par exemple s assurer de la qualité fonctionnelle de l application ou de sa qualité technique. Pour y parvenir, un modèle de qualité est donc constitué d un certain nombre de règles qui définissent la qualité mesurée le plus précisément possible. Les modèles de qualité définissent, classent, hiérarchisent ces règles et évaluent le projet en fonction de celles-ci. L évaluation est obtenue à partir de résultats de différentes métriques : les métriques de code, les métriques de test, ou toute autre information susceptible de fournir un renseignement quant à la qualité de l application mesurée (par exemple les résultats d audit). Ces métriques doivent être définies précisément et les propriétés qu elles mesurent doivent être en adéquation avec les règles qu elles évaluent. 7

22 Chapitre 1. Etat de l art et contexte Dans ce chapitre, nous décrivons les différents types d outils généralement utilisés dans le cadre de l évaluation de la qualité modèles de qualité et normes de qualité et nous expliquons en quoi ces modèles nous ont permis de construire notre propre modèle et pourquoi les entreprises ne sont pas toujours entièrement satisfaites des résultats obtenus grâce à ceux-ci (Section 1.1). Ensuite, nous détaillons les métriques de code et les techniques de tests existantes actuellement. En effet, pour évaluer la qualité, les modèles reposent sur des mesures. En fonction du périmètre qualité évalué, nous disposons d un certain nombre de données : des mesures issues de métriques ou des données brutes. Notre étude portant principalement sur l analyse de la qualité du code et de la validation fonctionnelle d un application, nous détaillons donc les données dont nous disposons pour évaluer le code source (Section 1.2) mais également les techniques de tests utilisées pour valider un logiciel que nous avons formalisées sous forme de règles de qualité (Section 1.3). 1.1 Modèles d évaluation de la qualité Evaluer la qualité consiste à définir des règles, interpréter des indicateurs de qualité en fonction de ces règles, leur donner du sens et les utiliser pour qualifier des concepts qualitatifs. Pour y parvenir, les entreprises utilisent des modèles de qualité. Ces modèles définissent des concepts, des domaines et des règles qualitatifs qu ils évaluent via les mesures et métriques effectuées sur le système. La pertinence d un modèle de qualité est fondée sur sa capacité à modéliser, qualifier, évaluer un certain nombre de règles complexes à partir de mesures (comme par exemple évaluer la structure générale du code source à partir de métriques de code). Nous présentons les principaux modèles de qualité existants actuellement. Ce sont des modèles hiérarchiques qui recensent les principes de qualité en partant des exigences globales et des principes les plus généraux pour descendre vers les métriques qui permettent de les mesurer. Ceci implique que la mesure de la qualité ne peut débuter qu une fois le modèle totalement spécifié et que les premiers résultats ne peuvent être obtenus qu une fois la collecte des données suffisante Le modèle de McCall : Facteurs Critères Métriques FCM McCall crée en 1977 un modèle pour mesurer le niveau de qualité d un logiciel pour l US Air Force [McCall et al., 1976]. Son modèle est composé de trois couches : les métriques, les critères et les facteurs. Les facteurs représentent la vision externe de la qualité, celle de l utilisateur. McCall identifie cinquante facteurs mais n en retient que onze comme étant les plus significatifs, distribués dans trois catégories : caractéristiques opérationnelles (exploitation de l application) : conformité aux besoins. L application répond-elle aux besoins? fiabilité. L application fonctionne-t-elle correctement? efficacité. L application utilise-t-elle un minimum de ressources? intégrité. L application est-elle bien protégée? facilité d emploi. L application est-elle facile à prendre en main? capacité d évolution de l application (maintenance de l application ou aptitude à subir des changements) : maintenabilité. Facilité à la localisation et la correction des erreurs ; 8

23 1.1. Modèles d évaluation de la qualité tracabilité maintenabilité simplicité conformité aux besoin complétude concision cohérence testabilité auto-description précision modularité fiabilité tolérance aux erreurs flexibilité instrumentation efficacité d'exécution extensibilité efficacité efficacité de sotckage portabilité généralisation contrôle d'acces indépendance système-logiciel intégrité audit d'accès réutilisabilité indépendance machine opérabilité facilité d'emploi communication interopérabilité communication commune formation données communes Figure 1.1 Les facteurs et les critères du modèle FCM flexibilité. Facilité de modification et d évolution du logiciel ; testabilité. Qualification des efforts de tests du logiciel ; adaptabilité de l application (portage de l application ou adaptabilité aux nouveaux environnements) : portabilité. Facilité d utilisation de l application sur une autre machine ; réutilisabilité. Facilité d utilisation de tout ou partie du code du logiciel pour l intégrer au sein d une autre application ; interopérabilité. Facilité d interfaçage de l application avec un autre système. Les facteurs sont assimilés aux caractéristiques du logiciel. Chaque facteur est divisé en critères qui représentent la vision interne de la qualité, celle du développeur. McCall définit vingt-trois critères répartis comme représentés dans la figure 1.1. Les critères sont évalués à partir de métriques. McCall définit, pour chaque critère, une liste de propriétés à mesurer. Par exemple, le critère complétude est évalué avec les propriétés suivantes : références non ambiguës (entrées, sorties, fonction) ; toutes les références de données sont obtenues, définies, calculées à partir d une source externe ; toutes les fonctions définies sont utilisées ; toutes les fonctions référencées sont définies ; toutes les conditions et exécutions sont définies pour chaque condition ; toutes les définitions et références des paramètres d appel sont exacts ; tous les problèmes rapportés sont résolus ; le design est en accord avec les exigences ; 9

24 Chapitre 1. Etat de l art et contexte le code est en accord avec le design. Chaque propriété obtient une valeur et la valeur du critère correspond à la moyenne des valeurs de chaque propriété. Ce modèle est extrêmement complet mais également très difficile à appliquer du fait des 300 métriques qui le composent. Bien qu implémenté dans plusieurs outils commerciaux, la correspondance entre les métriques et les critères n est pas clairement définie comme le remarquent Marinescu et Ratiu [Marinescu et Rațiu, 2004]. Ce modèle présente également une faiblesse importante : le manque de lisibilité. En effet, lorsqu un critère obtient une faible note, il est difficile, voire impossible, de relier cette note directement au problème qu elle pointe, surtout lorsque le critère est composé de plusieurs métriques. Dans ce cas il devient difficile de trouver comment remédier au problème existant. En revanche, l idée de McCall de définir un modèle regroupant des facteurs en fonction du domaine évalué (l exploitation, la maintenance et le portage), nous apparaît être pertinente. De plus, les critères qu il définit possèdent des contours clairs, chaque critère définit un domaine précis à évaluer, par exemple, l évaluation des efforts de tests ou encore le fonctionnement de l application. Ce modèle est d ailleurs la base de nombreux autres modèles de qualité telles que les normes Iso par exemple La Norme ISO 9126, qualité des produits logiciels ISO 9126 est une norme standard internationale visant à évaluer la qualité logicielle [ISO/IEC, 2001, ISO/IEC, 2003]. Elle normalise et classifie un certain nombre de principes qualité. Réalisée par le comité technique JTC 1 de l ISO/CEI, cette norme évolue pour être enrichie et intégrée dans la norme SquaRE (Software product Quality Requirement and Evaluation, exigences et évaluation de la qualité du logiciel). La qualité logicielle repose sur la définition de la norme ISO 8402, à savoir la capacité à satisfaire les besoins exprimés et implicites. ISO 9126 définit la qualité comme l objectif à atteindre pour obtenir la qualité nécessaire et suffisante pour répondre aux besoins réels des utilisateurs. Elle définit un modèle de qualité comme étant un ensemble d attributs de qualité liés à un ensemble de métriques. La relation entre les attributs de qualité et les métriques précise le processus d évaluation de qualité Les différentes qualités 10 La norme ISO 9126 distingue 3 catégories de qualité : la qualité interne qui qualifie la qualité du logiciel à partir de mesures statiques du code ; la qualité externe qui repose sur les mesures externes. Il s agit des mesures effectuées lors de simulation d exécution du logiciel, lors des phases de tests par exemple ; la qualité à l utilisation qui est mesurée lors de l utilisation du logiciel. Il s agit de la qualité ressentie par l utilisateur dans des conditions spécifiques et dans un environnement spécifique.

25 1.1. Modèles d évaluation de la qualité Le modèle hiérarchique La norme a défini un modèle hiérarchique inspiré du modèle de McCall. Ce modèle répartit les attributs de qualité en six caractéristiques générales qui définissent la qualité globale d une application. Une caractéristique spécifie une exigence qualité, fonctionnelle ou non, des clients et des utilisateurs. Chaque caractéristique est décomposée en sous-caractéristiques. Pour chacune de ces souscaractéristiques la norme propose une série de mesures visant à l évaluation de la conformité du produit par rapport aux exigences formulées. La norme ISO 9126 définit ses caractéristiques et sous-caractéristiques ainsi : capacité fonctionnelle : la capacité d une application à délivrer les fonctions répondant aux besoins explicites et implicites dans un contexte donné ; pertinence : la capacité d une application à fournir les fonctions appropriées pour répondre aux tâches spécifiques et aux besoins de l utilisateur ; exactitude : la capacité d une application à fournir les résultats attendus avec le degré d exactitude attendu ; interopérabilité : la capacité d une application à interagir avec un ou plusieurs systèmes spécifiés ; sécurité : la capacité d une application à protéger les informations et les données de manière à ce que les personnes non autorisées ne puissent lire ou modifier celles-ci tandis que les personnes autorisées puissent y avoir accès ; conformité : la conformité d une application par rapport aux standards, conventions et règles définis dans le cahier des charges fonctionnel ; fiabilité : la capacité d une application à maintenir le niveau de service spécifié dans des conditions spécifiées ; maturité : la capacité d une application à éviter les défaillances résultant de défauts dans le logiciel ; tolérance aux pannes : la capacité d une application à maintenir un niveau spécifié de performances en cas de panne ou de violation de son interface ; facilité de récupération : la capacité d une application à rétablir son niveau de performances et à récupérer les données affectées en cas de panne ; conformité : la capacité d une application à se conformer aux standards, conventions et fonctionnalités relatifs à la conformité ; facilité d utilisation : la capacité d un logiciel à être compris, appris et attractif pour les utilisateurs, selon des circonstances spécifiques d utilisation ; facilité de compréhension : la capacité d une application à être comprise et la facilité pour un utilisateur de comprendre comment l application doit être utilisée pour une tâche particulière et dans des conditions d utilisation données ; facilité d apprentissage : la facilité pour un utilisateur à apprendre à utiliser l application ; facilité d exploitation : la facilité pour un utilisateur à contrôler l application ; facilité d attractivité : la capacité d une application à être attractive pour un utilisateur ; conformité : la capacité d une application à se conformer aux standards, conventions et règles définies en relation avec la facilité d utilisation ; rendement : la capacité d une application à fournir le niveau attendu de performances, en fonction des ressources utilisées selon des conditions fixées ; 11