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

26 Chapitre 1. Etat de l art et contexte comportement temporel : la capacité d une application à fournir la réponse appropriée dans un délai de traitement défini ou avec des débits adéquats dans des conditions déterminées ; utilisation des ressources : la capacité d une application à utiliser les ressources adéquates dans un environnement fixé ; conformité : la capacité d une application à se conformer aux standards et règles relatives au rendement ; maintenabilité : la capacité d une application à être modifiée. Les modifications incluent les corrections, les améliorations et l adaptation lors d un changement d environnement, d exigences ou de spécifications fonctionnelles ; facilité d analyse : la capacité d une application à être diagnostiquée en cas de panne et de défaillance, ou lors de besoin de modification du logiciel ; facilité de modification : la capacité d une application à faciliter l implémentation des modifications ; stabilité : la capacité d une application à éviter les effets non souhaités lors de sa modification ; testabilité : la capacité d une application à être testée lors des modifications ; conformité : la capacité d une application à se conformer aux standards et règles définis en relation avec la maintenabilité ; portabilité : la capacité d une application à basculer d un environnement à un autre ; facilité d adaptation : la capacité d une application à être adaptée à différents environnements sans appliquer d actions autres que celles prévues pour cela ; facilité d installation : la capacité d une application à être installée dans un environnement spécifique ; coexistence : la capacité d une application à co-exister avec d autres applications indépendantes dans un environnement commun avec des ressources partagées ; interchangeabilité : la capacité d une application à être utilisée à la place d une autre pour le même but dans le même environnement ; conformité : la capacité d une application à se conformer aux standards et règles définis en relation avec la portabilité. La norme ISO 9126 donne également des indications pour mesurer ces caractéristiques et souscaractéristiques. Ainsi l échelle de mesures associée aux métriques utilisées pour évaluer les exigences qualité peut être divisée en différentes catégories à discrétion des acteurs. Par exemple, l échelle peut être divisée en deux catégories : satisfaisant ou non. Ou encore en quatre catégories : dépasse les exigences, atteint sa cible, acceptable a minima, non acceptable, comme indiqué dans la norme ISO Les catégories doivent être précisées de telle sorte que l utilisateur et le développeur puissent éviter les coûts inutiles et les dépassements de calendrier Les limites du modèle Le modèle ISO 9126 ne repose pas uniquement sur les métriques et de nombreuses mesures doivent être manuelles. La norme lie les qualités internes et externes d un logiciel, indique un lien de causalité entre ces deux types de caractéristiques mais ne donne aucune indication quant aux bonnes ou mauvaises valeurs. 12

27 1.1. Modèles d évaluation de la qualité Cette norme semble être une bonne approche pour déterminer la qualité d un logiciel dans son ensemble et fournir une vue globale satisfaisante. Cependant, la norme ne précise pas de manière explicite comment mesurer les caractéristiques qualité définies et comment les relier aux métriques de bas niveau. Il n y a aucun continuum entre ces deux niveaux. Ainsi, le modèle reste trop abstrait : bien que constituant une base théorique solide, le fait de devoir l adapter à chaque cas de figure sans avoir de guide précis pour le faire augmente d autant sa difficulté de mise en œuvre. Le modèle ISO 9126 est désormais remplacé par la norme SQuaRE SQuaRE, Software product QUAlity Requirement and Evaluation La norme SQuaRE définie depuis 2005 est la norme qui succède au standard ISO Elle a été définie à partir de ISO 9126 et de la partie évaluation de la norme ISO [ISO/IEC, 2005]. Elle a pour objectif d intégrer ces deux normes pour n en former qu une. Elle veut également répondre aux différents besoins de la qualité selon les acteurs (développeurs, testeurs, utilisateurs, clients). De plus, elle unifie les différents documents normatifs autour de la qualité. SQuaRE définit quatre étapes pour permettre une meilleur évaluation de la qualité : définir les exigences, établir un modèle de qualité, définir les métriques de la qualité et évaluer la qualité Différences par rapport à ISO 9126 La norme SQuaRE reprend le modèle défini dans ISO 9126 et y apporte les changements suivants : la portée du modèle de qualité a été étendue pour y inclure la qualité à l utilisation en tant que modèle à part entière (il reste cependant le facteur facilité d utilisation dans le modèle) ; la norme définit deux modèles de qualité : le modèle se référant à la qualité en production et celui mesurant la qualité à l utilisation ; la sécurité est devenue une caractéristique au lieu d être une sous caractéristique de la fonctionnalité ; la portabilité a été scindée en deux : d un côté la portabilité qui fait référence uniquement à la facilité d installation et l interchangeabilité, et de l autre la compatibilité qui inclut l interopérabilité ; les sous-caractéristiques suivantes ont été ajoutées : robustesse, utilité, accessibilité technique, modularité, réutilisabilité et portabilité ; plusieurs caractéristiques et sous-caractéristiques ont été précisées et renommées Le modèle SQuaRE Le système SQuaRE décrit deux modèles distincts. Un modèle de qualité à l utilisation et un modèle de qualité propre à la production logicielle. Nous nous intéressons uniquement à ce dernier dans le cadre de nos travaux. En effet, le modèle de qualité à l utilisation qualifie la qualité d un point de vue utilisateur, après la conception du logiciel tandis que notre étude porte sur la qualité de la conception d un logiciel. Le modèle est constitué de huit caractéristiques, décomposées en sous caractéristiques : 13

28 Chapitre 1. Etat de l art et contexte adéquation fonctionnelle : degré à partir duquel un produit offre les fonctions répondant aux besoins exprimés et implicites dans des conditions d utilisation spécifiées ; complétude fonctionnelle : degré à partir duquel l ensemble des fonctions couvre toutes les tâches et les objectifs spécifiés par l utilisateur ; exactitude fonctionnelle : degré à partir duquel un produit fournit des résultats corrects avec le degré de précision attendu ; adéquation fonctionnelle : degré à partir duquel les fonctions facilitent l accomplissement des tâches et objectifs spécifiés par l utilisateur ; performances : performances par rapport aux ressources utilisées dans des conditions déterminées ; comportement dans le temps : degré à partir duquel les temps de réponse et de traitement ainsi que les taux de débit d un produit, lors de l exécution de ses fonctions, correspondent aux exigences ; utilisation des ressources : degré à partir duquel les ressources et les types de ressources y compris les ressources humaines utilisées par le produit correspondent aux exigences ; capacité : degré à partir duquel les limites maximales d un produit répondent aux exigences ; compatibilité : degré à partir duquel un produit peut échanger des informations avec d autres produits et/ou remplir ses fonctions, tout en partageant les mêmes environnements matériel et logiciel ; co-existence : degré à partir duquel un produit peut remplir ses fonctions efficacement tout en partageant un environnement et des ressources avec d autres produits sans impact négatif sur les autres produits ; interopérabilité : degré à partir duquel deux ou plusieurs produits peuvent échanger des informations et utiliser les informations qui ont été échangées ; facilité d utilisation : degré à partir duquel un produit peut être utilisé, appris, compris et attractif par des utilisateurs pour atteindre des buts identifiés, dans un contexte spécifié ; pertinence : degré à partir duquel un utilisateur peut savoir si le produit est approprié à ses besoins ; facilité d apprentissage : degré à partir duquel l apprentissage de l utilisation d un produit, dans un but précis, peut être effectué avec efficacité, absence de risque et satisfaction, dans un contexte spécifié ; opérabilité : degré à partir duquel les attributs d un produit le rendent facile à utiliser et à contrôler ; protection contre les erreurs utilisateur : degré à partir duquel le produit empêche les erreurs des utilisateurs ; esthétique de l interface utilisateur : degré à partir duquel l interface utilisateur permet une interaction agréable et satisfaisante pour l utilisateur ; accessibilité : degré à partir duquel un produit peut être utilisé avec le plus large éventail de caractéristiques et de capacités pour atteindre un objectif spécifié dans un contexte spécifié ; fiabilité : degré à partir duquel un produit exécute les fonctions spécifiées dans des conditions spécifiées pour une période de temps spécifiée ; maturité : degré à partir duquel un produit répond aux besoins de fiabilité dans des conditions normales d utilisation ; disponibilité : degré à partir duquel un produit est opérationnel et accessible quand on en a besoin ; tolérance aux pannes : degré à partir duquel un produit fonctionne comme prévu, malgré la présence de défauts de matériel ou logiciel ; 14

29 1.1. Modèles d évaluation de la qualité recouvrabilité : degré à partir duquel, en cas de panne ou d interruption, un produit peut récupérer les données directement affectées et rétablir son niveau de service ; sécurité : degré à partir duquel un produit protège les informations et données de manière à ce que les personnes ou autres produits aient un accès à ces derniers qui correspond à leur niveau d autorisation ; confidentialité : degré à partir duquel un produit garantit que les données sont accessibles uniquement aux personnes autorisées ; intégrité : degré à partir duquel un produit prévient les accès non autorisés ou les modifications indues, aux données comme aux programmes ; non-répudiation : degré à partir duquel les actions ou événements peuvent être actés de manière à ne pas pouvoir les contester ensuite ; responsabilisation : degré à partir duquel les actions d une entité donnée peuvent être tracées de manière individuelle ; identification : degré à partir duquel l identité d un produit ou d une ressource peut être prouvée sans contestation possible ; maintenabilité : degré d efficacité à partir duquel un produit peut être modifié par les personnes appropriées ; modularité : degré à partir duquel un produit est composé de composants discrets tels que le changement d un composant a un impact minimal sur les autres composants ; facilité de réutilisation : degré à partir duquel un élément actif peut être utilisé dans plusieurs systèmes ou dans la construction d autres éléments actifs ; facilité d analyse : degré d efficacité à partir de laquelle il est possible d évaluer l impact sur un produit d un changement d une ou plusieurs parties, ou de diagnostiquer les causes de déficience et de panne d un produit, ou de déterminer les composants à modifier ; facilité de modification : degré à partir duquel un produit peut être modifié efficacement, sans introduire de défauts ou de dégradation de la qualité ; facilité de tests : degré d efficacité avec laquelle les critères de tests peuvent être établis pour un produit et avec laquelle les tests peuvent être effectués pour déterminer si ces critères ont été respectés ; portabilité : degré d efficacité avec laquelle un produit peut être transféré depuis un environnement matériel ou logiciel vers un autre ou d un usage à un autre. adaptabilité : degré auquel un produit peut être adapté efficacement dans un autre environnement matériel ou logiciel ; facilité d installation : degré d efficacité avec laquelle un produit peut être installé ou désinstallé avec succès dans un environnement donné ; interchangeabilité : degré auquel un produit peut être remplacé par un autre pour le même but dans le même environnement Les limites du modèle Issue de la norme ISO 9126, SquaRE redéfinit de manière beaucoup plus judicieuse les caractéristiques qualité d un logiciel. Le fait, par exemple, d avoir distingué la partie sécurité comme étant désormais une caractéristique à part entière, ou encore d avoir fait une distinction entre la portabilité et la compatibilité rendent le modèle plus pertinent. Cependant, là encore, ce modèle généraliste est difficile à mettre en œuvre ; il n existe aucun lien explicite entre les caractéristiques et les métriques. De plus, la norme définit un modèle de qualité général qui vise à qualifier un logiciel dans 15

30 Chapitre 1. Etat de l art et contexte son ensemble. Pour ce faire, il qualifie à la fois des notions externes adéquation fonctionnelle ou encore facilité d utilisation avec des notions internes de qualification du code source à proprement parlé maintenabilité ou compatibilité, ce qui rend l application du modèle dans son intégralité souvent beaucoup trop complexe à mettre en œuvre Le modèle GQM (Goal Question Metrics) Il s agit d une approche de la qualité logicielle qui a été promue par Basili et son équipe [Basili et al., 1994]. Il définit la mesure de la qualité sur trois niveaux : le niveau conceptuel (the goal level), le niveau opérationnel (the question level), et le niveau quantitatif (the metric level). Cette approche a pour but de déterminer quelles sont les métriques utiles pour évaluer si le but souhaité par l entreprise a été atteint. Il s agit, à partir d un processus défini en trois points (Goal Question Metrics), de définir un plan de qualité correspondant exactement au logiciel évalué. Le niveau conceptuel fixe les objectifs de mesure à savoir, ce qui doit être mesuré, le niveau à atteindre en terme de qualité, les objectifs visés par l entreprise. Ce niveau détermine les attentes de l entreprise, il s agit du but à atteindre : the Goal. Le niveau opérationnel définit pour sa part les questions à se poser pour déterminer si les objectifs définis au niveau précédent sont atteints. Cette seconde étape consiste à déterminer quelles sont les bonnes questions répondant aux buts définis précédemment : the Questions. Le niveau quantitatif détermine quelles métriques doivent être utilisées pour mesurer le niveau précédent. Cette dernière étape passe par le calcul des métriques qui répondent aux questions de l étape précédente : the Metrics. L idée de Basili et Rombach était d emprunter des idées simples et générales correspondant aux exigences des démarches qualité dans le but de définir un schéma permettant de déterminer les métriques utiles et adéquates [Fenton et Neil, 1999]. En effet, d après Hall et al., un programme de mesures établi sans objectifs ni buts clairs et précis est presque forcément voué à l échec [Hall et Fenton, 1997]. Même si cette démarche d évaluation de la qualité est largement diffusée dans l industrie comme moyen de déterminer le niveau de qualité d un système, elle n est cependant pas sans faille, comme le soulignent par exemple Bache et al. : partir du niveau le plus haut a souvent pour contrepartie d ignorer totalement ce qui est réellement mesurable au niveau le plus bas [Bache et Neil, 1995]. Le compromis idéal serait de coupler les programmes de métriques existants avec ce modèle, de sorte que seules les métriques adéquates soient conservées. De plus, cette démarche n explicite pas clairement comment intégrer les stratégies et les buts spécifiques aux entreprises dans le modèle. Enfin, elle ne sépare pas clairement les différents points de vue entre les managers et les développeurs et ne permet donc pas une lecture claire systématique et aisée des résultats obtenus. 16

31 1.1. Modèles d évaluation de la qualité Quelques autres modèles de qualité QMOOD QMOOD pour Quality Model for Object-Oriented Design est également un modèle hiérarchique fondé sur la norme ISO Il est composé de quatre niveaux : les attributs de la qualité du design, les propriétés du design orienté objet, les métriques du design orienté objet et les composants du design orienté objet. Ces attributs de haut niveau sont évalués en utilisant un ensemble de propriétés empiriquement identifié et pondéré [Bansiya et Davis, 2002]. Ce modèle est conçu pour des applications orientées objet et ne peut s appliquer pour d autres paradigmes. Plus encore, il ne qualifie que la conception des programmes : il ne prend pas en compte la qualité de l implémentation ou le respect des règles de programmation par exemple Le modèle Factor-Strategy Marinescu et Rațiu sont partis de la question suivante : Comment pouvons-nous travailler en partant des résultats? Leur idée est de relier clairement les facteurs de qualité au code source en utilisant une stratégie de détection [Marinescu et Rațiu, 2004]. Ils définissent cette stratégie de détection comme un mécanisme générique permettant d analyser le code source en utilisant des métriques [Marinescu, 2004]. Les métriques sont soumises à des mécanismes de filtrage et de composition. Une opération de filtrage est caractérisée par des seuils et des extrémités. Les opérateurs de composation utilisés sont : et, or, butnotin. Ils présentent ainsi un nouveau modèle de qualité appelé Factor-Strategy (pour Facteur-Stratégie) à partir de cette stratégie de détection. Ce modèle utilise une approche de type décomposition : la qualité est décomposée en facteurs. Ces derniers ne sont plus reliés directement aux métriques mais exprimés en terme de stratégie de détection, qui sont les expressions quantifiées (évaluées) de règles de design en terme de conception orienté-objet. Chaque facteur ou stratégie se voit attribuer un score calculé à l aide d une matrice de rang : étant donné une donnée brute ou une note, la matrice renvoie une note de qualité normalisée qui pourra être utilisée dans une autre formule. Ce modèle est pertinent pour mesurer les concepts orientés objets mais, tout comme le modèle précédent, il ne peut s appliquer pour d autres concepts et ne couvre pas l intégralité des propriétés d une application SourceInventory Bakota et Guymóthy ont présenté un modèle appelé SourceInventory (inventaire du source) [Bakota et al., 2008] qui collecte des mesures telles que des métriques et des informations de couverture de tests. SourceInventory fournit une aide pour interpréter les données collectées mais demeure toutefois un modèle de bas niveau qui ne fournit pas une vue globale et de haut niveau de la qualité Le modèle de qualité SQALE Le modèle de qualité SQALE (Software Quality Assessment based on Lifecycle Expectations) est un modèle hiérarchique : trois niveaux allant du plus général les caractéristiques au plus détaillé les mesures des points de contrôle du code (dépendant du langage et des situations) 1. Les 1. http :// 17

32 Chapitre 1. Etat de l art et contexte caractéristiques de SQALE ont été déterminées à partir d un modèle générique du cycle de vie d un logiciel. Elles sont représentées selon un modèle en couche qui implique que chaque caractéristique doit être validée pour passer à la suivante, tout comme chaque étape de développement d un logiciel doit être validée pour continuer. Les exigences, ou points de contrôle peuvent être des métriques avec un seuil de validation ou des règles de codage n acceptant pas d exception. Les évaluations des caractéristiques sont fondées sur des index de remédiation calculant la distance entre le code analysé et l objectif qualité à atteindre. Calculé pour chaque composant du code, cet index représente l effort de remédiation nécessaire pour corriger le composant mesuré. L index d un composant se calcule par addition des index de ses constituants. De même, l index d une caractéristique se calcule à partir de la somme de ses sous-caractéristiques. Ce modèle a été créé pour mesurer la qualité du code produit et l évalue en terme d effort de remédiation uniquement. Il est particulièrement adapté aux développeurs pour lesquels il a été conçu. En revanche, il ne tient pas compte de la qualité fonctionnelle du logiciel. De plus, les modes de calcul des index de remédiation n ont pas fait l objet d une réelle validation théorique et formelle. De même, l index d un composant calculé par addition des index de ses constituants n est peut-être pas la meilleure démarche : dans certains cas, les efforts de remédiatipn peuvent se mutualiser plutôt que s additionner Sonar : un outil d évaluation de la qualité Sonar n est pas à proprement parlé un modèle de qualité logiciel. Il constitue plus exactement un outil open source qui mesure la qualité du code source d une application répartie en sept groupes 2 : l architecture et le design du code ; les commentaires du code ; les conventions de nommage ; les bugs potentiels ; la complexité ; les tests unitaires ; les duplications de lignes de code. Il analyse les codes sources de la majorité des langages de programmation, tant orientés objet tels que Java ou C++, mais également procéduraux tels que le langage C par exemple. Il utilise des métriques de code dont il restitue les valeurs sous forme de tableaux et met en évidence les composants du code qui ne sont pas en adéquation avec les mesures attendues (les violations de règles). Cet outil est utilisé de manière concrète par de nombreux développeurs car il leur permet d évaluer de manière concrète et directe le code de l application. Cependant, même s il pointe les composants défectueux ou les savoir-faire métier qui ne sont pas respectés, il ne constitue pas à proprement parlé un modèle de qualité : il n offre pas une vue globale de la qualité logicielle. Il est destiné aux développeurs pour les aider à détecter les points faibles de leur code en leur fournissant une vue technique de bas niveau de la qualité du code. Il est à noter que le modèle SQALE a été implémenté comme un plugin de Sonar pour fournir cette vue de la qualité de plus haut niveau. 2. http :// 18

33 1.2. Les métriques de code Conclusion Les modèles utilisés pour déterminer la qualité d une application reposent sur des métriques et des mesures. Ces modèles décrivent des règles de qualité, des principes formels et donnent des indications pour déterminer le niveau de qualité en se fondant sur des métriques. Les modèles sont généralement hiérarchiques : ils définissent des domaines de qualité qu ils précisent par des principes de qualité. Ils évaluent ces principes en utilisant des mesures. Cependant, il est difficile de concevoir un modèle de qualité qui puisse être adaptable à tout type de logiciel. Pour y parvenir, certains modèles donnent des définitions générales qu il faut ensuite adapter au logiciel : les normes et les modèles issus du modèle FCM de McCall. D autres modèles en revanche Factor-Strategy par exemple prennent le parti de n évaluer qu un seul type de logiciels : les logiciels orientés objet. Certains modèles ne prennent pas en compte l intégralité des propriétés d une application : ils évaluent uniquement le code, par exemple. Or, pour déterminer la qualité globale d une application il faut prendre en considération la qualité de son code source mais également son adéquation avec les objectifs les exigences client ou encore la qualité de la validation du logiciel les tests sur le code source et les tests fonctionnels. A cet égard, le modèle GQM est le plus complet. Nous constatons donc qu il existe principalement deux types de modèles : les modèles qui ont pour objectif d évaluer la qualité globale d une application et ceux qui restreignent leur champ d investigation. Les premiers définissent de manière formelle et complète les concepts de qualité à mesurer mais ne fournissent pas assez d indications quant à la façon de les décomposer en unités plus fines pour permettre de les mesurer. Les seconds, de par leur spécification, sont précis quant à l évaluation mais ne fournissent qu une vue partielle de la qualité ou qu un point de vue. De plus, tous ces modèles reposent sur des mesures qu ils agrègent souvent de manière simpliste. On constate alors que certaines informations fournies par les mesures sont perdues ou bien qu une fois l agrégation faite, il n est plus possible de déterminer avec précision d où vient le problème constaté (nous aborderons plus précisément ces notions dans la section 3.4). C est pour cette raison que les développeurs de Air France-KLM, par exemple, préfèrent utiliser uniquement les métriques de code et les interpréter directement en fonction de leur propre savoir-faire, tout comme de nombreux développeurs préfèrent se référer à des outils tel que Sonar [Bouhier, 2008]. La principale difficulté est donc de déterminer comment passer des principes de qualité aux mesures et vice versa. Evaluer signifie mesurer, et donc utiliser des métriques. Nous avons concentré nos recherches sur l évaluation de la qualité logicielle aux périmètres suivants : la qualité du code source et la qualité de la validation logicielle. C est pourquoi, dans la partie suivante de ce chapitre, nous recensons les métriques qui vont nous permettre d évaluer la qualité dans ces deux domaines. 1.2 Les métriques de code Après avoir défini précisément les termes relatifs à notre étude en matière de mesures, nous présentons les principales métriques de code disponibles, nous précisons leur définition et nous les analysons pour déterminer lesquelles pourrons être utiles à notre modèle. 19

34 Chapitre 1. Etat de l art et contexte Vocabulaire Un modèle de qualité se compose d un certain nombre de règles et de principes, répartis en différentes catégories. Appliquer un modèle de qualité consiste à évaluer ces règles. Pour y parvenir, le modèle collecte un certain nombre d informations issues du projet : les mesures. Il convient tout d abord de définir précisément les termes de mesures et de métriques. En effet, ces deux termes sont souvent utilisés de manière indistincte pour désigner la même entité. La norme ISO 9126 définit une mesure comme étant un nombre ou une catégorie assigné à un attribut d une entité suite à l utilisation d une métrique [ISO/IEC, 2001]. Une mesure est donc le résultat d une évaluation. Une métrique d un ensemble donné est définie comme une distance sur cet ensemble. La métrique est une théorie de la mesure dans un espace, fondée sur la formule de la distance entre deux points de cet espace [Rob, 2012]. Appliquée à l informatique, une métrique représente un indicateur de valeur d une propriété donnée. La norme ISO 9126 définit une métrique comme étant la définition de méthode associée à une échelle quantitative utilisées pour déterminer la valeur d une propriété donnée pour une entité logiciel donnée. Une métrique quantifie donc une propriété. Pour être valide elle doit posséder au moins les deux caractéristiques suivantes : la fidélité et la validité [Plante, 1994]. La fidélité signifie qu un résultat de métrique doit être identique lorsque la propriété est mesurée plusieurs fois dans les mêmes conditions. La validité signifie que la mesure doit être pertinente et refléter ce que cette dernière quantifie. Nous employons donc les termes suivants : les métriques sont définies par les propriétés qu elles mesurent et les intervalles qui leur correspondent. Une métrique est calculée de manière automatique et reproductible, par exemple la métrique du nombre de lignes d un code ; les intervalles sont les ensembles de nombres dans lequel la mesure prend sa valeur, par exemple, la métrique du nombre de lignes de code qui peut prendre ses valeurs dans l intervalle [0; + [ ; les mesures sont le résultat des métriques, par exemple, une méthode qui possède 15 lignes de code, 15 étant le résultat de la métrique nombre de lignes de code ; les données brutes sont les informations recueillies lors de l évaluation de la qualité du logiciel mais qui ne peuvent être obtenues de manière automatique. Ces informations ne sont d ailleurs pas toujours exprimées en valeur numérique mais en langage naturel. Par exemple, le cahier des charges du projet est rédigé correctement, ou encore, les tests fonctionnels sont rédigés de manière suffisamment détaillée. Selon Fenton et Pfleeger, mesurer est un processus par lequel des nombres et des symboles sont assignés aux attributs des entités mesurées de telle sorte à caractériser les attributs avec des règles clairement définies [Fenton et Pfleeger, 1996]. Ainsi, selon Park, la définition d une métrique doit comporter [Park, 1992] : le type d entité mesurée (logiciel, fonction, méthode, etc.) ; les attributs mesurés (l héritage, les lignes de code, etc.) ; les règles et intervalles qui affectent une valeur à un attribut. 20

35 1.2. Les métriques de code Une métrique doit donc être définie précisément pour être utilisée de manière correcte et significative. Dans les parties suivantes, nous étudions les différentes métriques de code utilisées par les modèles de qualité pour évaluer la qualité du code source d un logiciel. Nous avons exprimé chacune des métriques décrites par la suite avec les propriétés suivantes : Nom : le nom exact de la métrique ; Acronyme : l abréviation utilisée pour cette métrique ; Références : les références qui définissent et/ou analysent cette métrique ; Définition : la définition précise de la métrique ; Portée : le type d entité du programme que mesure la métrique ; Analyse : une analyse précise des atouts et des points faibles de la métrique. Il existe un nombre considérable de métriques et certaines d entre elles ne sont pas calculées de la même manière selon l outil utilisé. C est pourquoi il convient de déterminer quelles métriques seront utiles et comment elles doivent précisément être calculées [Fenton et Pfleeger, 1996, Lanza et Marinescu, 2006a, Jones, 2008]. Nous regroupons les métriques de code en différents groupes selon les mesures fournies par celles-ci : les métriques de code conventionnelles qui sont calculées quel que soit le type de langage utilisé ; les métriques orientées objet qui sont calculées sur des langages orientés objet ; les conventions de nommage et d écriture qui définissent les règles appliquées dans l entreprise ; Les métriques de code conventionnelles Cette catégorie regroupe les métriques basiques couramment utilisées pour évaluer certaines propriétés du code source. Ces métriques s appliquent à tout type de langage procédural ou objet par exemple La complexité du code Nom Complexité cyclomatique Acronyme V(G) Références [McCabe, 1976] Définition La complexité cyclomatique est une mesure, notée V(G), définie par Thomas McCabe en 1976, aussi appelée complexité de McCabe. Elle mesure le nombre maximum de chemins linéairement indépendants qu il est possible d emprunter dans un module de programme. Le module est représenté sous forme d un graphe de flot de contrôle. Dans celui-ci, un nœud du graphe correspond à une série d instructions séquentielles et un arc correspond à une branche du programme. De plus, il est posé dans la définition que le graphe possède un unique nœud 21

36 Chapitre 1. Etat de l art et contexte d entrée et un unique nœud de sortie, que chaque nœud est atteignable depuis l entrée et que chaque nœud peut atteindre la sortie. La définition de la complexité cyclomatique est la suivante : V (G) = e n + 2p où e correspond au nombre d arcs, n au nombre de nœuds et p au nombre de composants connectés. Dans cette formule, les arcs sont les branches d un programme, les nœuds sont les blocs d instructions séquentielles. De plus, tel qu est défini le graphe de flot de contrôle, p a pour valeur 1 : il n existe qu un seul composant connecté. La figure 1.2 représente l exemple suivant : le schéma supérieur représente le graphe du programme et les trois graphes inférieurs représentent chacun un chemin possible dans ce graphe. Dans cet exemple, e vaut 8, n vaut 7 et p vaut 1. Donc la valeur de V (G) est de 3. Il y a effectivement 3 chemins linéairement indépendants dans cet exemple (ils sont représentés en couleur sur l exemple). On nomme parfois cette mesure la complexité conditionnelle car elle revient également à mesurer le nombre de points de décision du programme, à savoir les conditions et branchements if, while, for, etc. auquel on ajoute 1 pour comptabiliser le chemin principal. La complexité cyclomatique d un programme a pour valeur minimum 1 puisqu il y a toujours au moins un chemin possible. Portée Fonction, Méthode, Classe Analyse Cette métrique donne une indication de la complexité du programme : plus le nombre est élevé et plus il est difficile pour un développeur de comprendre sa structure et les résultats attendus. Un programme ayant une trop grande complexité cyclomatique comporte plus de risques d introduction de bogues. De plus, cette mesure est directement reliée à l effort de tests nécessaire au programme : plus la mesure est élevée et plus le nombre de tests à effectuer pour obtenir un taux de couverture de tests satisfaisant est également élevé. On peut relier la complexité cyclomatique aux tests de la manière suivante : V(G) correspond au maximum de cas de tests à effectuer pour obtenir une couverture complète des tests par branche ; V(G) correspond au minimum de cas de tests unitaires à effectuer pour obtenir une couverture complète du code (taux de couverture à 100%). Calculée au niveau des classes, la complexité cyclomatique correspond à la somme des complexités cyclomatiques de chacune des méthodes de la classe. Bien que cette métrique ait été définie indépendamment du langage de programmation utilisé, Lorenz et Kidd jugent que cette mesure doit être adaptée au modèle orienté objet pour être correcte [Lorenz et Kidd, 1994]. De plus, cette mesure ne tient pas compte de la complexité des structures de données ni du flux de ces données. Nom Complexité cyclomatique essentielle Acronyme ev(g) 22

37 1.2. Les métriques de code Instructions Vrai Instructions Instruction conditionnelle Faux Vrai Instructions Instruction conditionnelle Faux Instructions Instructions Instructions Instructions Instructions Vrai Instruction conditionnelle Vrai Instruction conditionnelle Vrai Instruction conditionnelle Instructions Faux Instructions Faux Instructions Faux Vrai Instruction conditionnelle Faux Vrai Instruction conditionnelle Faux Vrai Instruction conditionnelle Faux Instructions Instructions Instructions Instructions Instructions Instructions Instructions Instructions Instructions Figure 1.2 Un exemple de graphe de flot de contrôle avec les trois différents chemins linéairement indépendants. Instructions Instructions Instructions Vrai Instruction conditionnelle Instructions Faux Vrai Instruction conditionnelle Faux Vrai Instruction conditionnelle Faux Instructions Instructions Instructions Instructions Instructions Instructions Instructions Figure 1.3 Un exemple de graphe de flot de contrôle simplifié. 23

38 Chapitre 1. Etat de l art et contexte Références [McCabe, 1976] Définition La complexité cyclomatique essentielle correspond à la complexité cyclomatique calculée sur un graphe simplifié : les parties du graphe qui correspondent à des structures de contrôle très bien structurées sont remplacées par de simples branches. Par exemple, un if-then-else est considéré comme correctement structuré lorsqu il possède une seule sortie et une seule entrée. Dans ce cas, il est remplacé par une simple branche. En revanche, un break dans une boucle ne peut être simplifié puisqu il crée un nouveau point de sortie dans le flot d exécution. a définition de la métrique est : ev(g) = V(G) m où m est le nombre de sous-graphes avec une unique entrée et une unique sortie. La figure 1.3 représente le graphe simplifié de l exemple précédent. Le premier sous-graphe, entouré en rouge peut être simplifié puisqu il possède une seule entrée et un seul point de sortie. L étape suivante s intéresse au second sous-graphe qui, pour les mêmes raisons, peut également être simplifié. On obtient alors ev(g) = 3 2 = 1. Portée Fonction, Méthode, Classe Analyse Cette métrique est un indicateur de degré de structuration du code qui a des conséquences sur la maintenance et les efforts de modularisation. Plus un code possède des clauses continue, break, goto, etc., plus ev(g) est grand et plus il est complexe à comprendre et à simplifier. Tout comme pour la métrique V(G), les entités de code ayant une grande complexité cyclomatique essentielle doivent être analysées avec davantage d attention. Dans l idéal, un code totalement structuré a une complexité cyclomatique essentielle de valeur 1 : il peut être entièrement simplifié Les lignes de code Les mesures les plus largement utilisées concernent les lignes de code. Très simples à comprendre, ces métriques doivent pourtant être définies précisément. En effet, la composition d une ligne de code varie et le moyen de compter les lignes de code n est pas toujours compris de la même manière. Prenons l exemple suivant, sans difficulté apparente : for (i = 0; i < 10; i+ = 1) printf("hello World") ; /* une ligne de code avec une boucle */ Cet exemple contient une ligne de code mais plusieurs instructions et également un commentaire. On peut donc considérer que cette ligne contient : une ligne physique ; deux lignes logiques ; une ligne de commentaires. Cet exemple illustre donc les différentes métriques que nous pouvons appliquer aux lignes de code. Nom Nombre de lignes de code source Acronyme SLOC 24

39 1.2. Les métriques de code Références [Kan, 2002] Définition La métrique SLOC pour Source Line Of Code mesure la taille d un logiciel en déterminant le nombre de lignes de son code source. Cette métrique ne tient en principe pas compte des commentaires. Cependant, même si le plus courant est de compter le nombre de lignes physiques d un programme sans tenir compte des lignes vides, certains utilitaires vont compter le nombre de lignes logiques ou encore vont avoir leur propre définition de dénombrement, comme l illustre Park à travers la check-list qui définit les règles de calcul de SLOC [Park, 1992]. Portée Fonction, Méthode Analyse Cette métrique est très souvent employée pour déterminer la valeur d un logiciel et estimer l effort qu il est nécessaire de fournir pour la conception ou la maintenance du logiciel. Cependant, cet indicateur ne doit pas être le seul à prendre en compte puisqu il ne fournit pas de réelle indication quant à la complexité des lignes de code par exemple. Il convient, par exemple, de le coupler au calcul de la complexité cyclomatique pour distinguer un code avec de nombreuses lignes de code mais très simple, d un code avec peu de lignes de code mais plus complexe. Nom Lignes de commentaires Acronyme CLOC Références [Kan, 2002] Définition La métrique CLOC pour Comments Lines Of Code détermine le nombre de lignes de commentaires dans un programme. Portée Fonction, Méthode Analyse Il est souvent intéressant de connaître le nombre de lignes de commentaires contenues dans un logiciel afin de déterminer la facilité de compréhension des lignes de code. En effet, plus un code est commenté et plus il sera facilement compréhensible. Cependant, là encore, connaître le nombre de lignes de commentaires n est pas suffisant. Il faut également savoir si la répartition des commentaires est judicieuse et mettre en rapport cette mesure avec la complexité du code commenté. Il semble raisonnable de penser que plus un code est compliqué et plus il doit être commenté. De plus, connaitre le nombre de lignes de commentaires ne permet pas de définir la qualité de ceux-ci : certains commentaires peuvent être obsolètes, incompréhensibles ou erronés Les métriques de code orienté objet Les métriques conventionnelles sont de bons indicateurs mais ne correspondent pas toujours aux exigences et particularités du code orienté objet. En particulier Moreau et Dominick ont montré que les métriques traditionnelles ne s appliquent pas au design orienté objet [Moreau et Dominick, 1989]. Par exemple, mesurer le nombre de lignes de code (SLOC ) ne leur apparaît pas suffisant dans le cadre 25

40 Chapitre 1. Etat de l art et contexte orienté objet. C est pourquoi ils suggèrent d associer cette mesure avec par exemple, la profondeur d héritage pour prendre en compte la réelle complexité du code. Par ailleurs, Tegarden présente le résultat d une série de mesures sur quatre systèmes et prouve que les métriques traditionnelles telles que SLOC, la complexité cyclomatique ou encore les métriques de Halstead sont utiles pour interpréter la complexité du design orienté objet mais que ces seules métriques ne suffisent pas [Tegarden et al., 1992] Les métriques primitives Les métriques de Chidamber et Kemerer Les métriques suivantes, parfois appelées les métriques CK, ont été regroupées par Chidamber et Kemerer comme constituant un ensemble de métriques de base d analyse du code source orienté objet [Chidamber et Kemerer, 1994] : WMC pour Weighted Methods per Class ; DIT pour Depth of Inheritance Tree ; NOC pour Number Of Children ; RFC pour Response For a Class ; LCOM pour Lack of Cohesion in Methods (définie en page 34) ; CBO pour Coupling Between Objects(définie en page 33). Nom Nombre pondéré de méthodes par classe (Weighted Methods per Class) Acronyme WMC Références [Chidamber et Kemerer, 1994] Définition WMC comptabilise le nombre de méthodes définies pour une classe donnée, pondérées par leur complexité, sachant que la complexité s entend ici en terme de complexité cyclomatique. Portée Classe Analyse Cette métrique permet d obtenir une vue globale de la complexité d une classe. Certains outils calculant cette métrique offre la possibilité de définir la pondération comme étant la complexité cyclomatique ou encore, par exemple, le nombre de lignes de code d une méthode. Cependant, la plupart du temps, la pondération est négligée (tous les poids ont pour valeur 1), ce qui revient à calculer la métrique NOM (voir sa définition plus loin). Nom Profondeur de l arbre d héritage (Depth of Inheritance Tree) Acronyme DIT Références [Lorenz et Kidd, 1994],[Chidamber et Kemerer, 1994],[Briand et al., 1996], [Gyimóthy et al., 2005],[Li et Henry, 1993],[Hitz et Montazeri, 1995],[Tempero et al., 2008] 26

41 1.2. Les métriques de code Définition La profondeur d héritage d une classe correspond à la profondeur maximum de la classe dans l arbre d héritage, i.e., depuis la racine jusqu au nœud de la classe, mesurée en nombre d ancêtres de la classe. Plus une classe est profonde dans l arbre d héritage, plus le nombre de méthodes héritées est élevé, ce qui rend la prédiction et la compréhension de son comportement plus complexe. Un arbre d héritage profond résulte d un design complexe avec des classes et des méthodes très imbriquées. En revanche, cela diminue le potentiel de réutilisation des méthodes héritées. Portée Classe Analyse Calculer une profondeur d héritage n est pas toujours suffisant. En effet, il faut tenir compte du contexte de la classe. Est-elle une sous-classe d un framework par exemple? Si cela est le cas, cela peut parfois impliquer une très grande profondeur d héritage mais qui, ramenée au contexte seul de l application, peut tout à fait être une valeur beaucoup plus petite. Puisque le principal problème lié à cette métrique est le manque de distinction entre les différents types d héritage, Tempero et al. ont proposé une alternative à la métrique DIT pour le langage Java [Tempero et al., 2008]. Ils font une distinction entre les deux types d héritage suivants : extend et implement. Ils distinguent également trois domaines différents : les classes définies par le développeur, les classes appartenant aux librairies standards et les autres. Ils introduisent de nouvelles métriques pour calculer alors les profondeurs d héritage mais ne fournissent aucune métrique ou indicateur pour définir un bon design ou une aide à la prédiction d erreurs. En cas de multiples héritages, DIT mesure le chemin le plus long, ce qui n indique pas le nombre de classes impliquées dans l héritage. L héritage multiple étant généralement déconseillé, il est dommage de ne pas prendre en compte ce paramètre dans les mesures. Briand et al. ont effectué une validation empirique de cette métrique, déduisant que plus la valeur de la métrique est élevée, plus la probabilité de détecter des fautes est également élevée [Briand et al., 1996]. Gyimóthy et al. pour leur part concluent que cette métrique n est pas le meilleur indicateur parmi l ensemble des métriques CK [Gyimóthy et al., 2005]. Ils estiment cependant qu elle doit faire l objet d une plus grande étude pour confirmer l hypothèse suivante : une classe située plus profondément dans l arbre d héritage est plus sujette aux erreurs que ses pairs. Li et Henry, quant à eux, ont proposé d utiliser cette métrique comme mesure de la complexité plus la profondeur est élevée et plus le programme est complexe [Li et Henry, 1993]. Mais comme le remarquent Hitz et Montazeri, ceci signifie que l héritage augmente la complexité d un système alors qu il est considéré comme un avantage majeur du paradigme orienté objet [Hitz et Montazeri, 1995]. On le comprend, DIT a très souvent été étudiée, mais la plupart des études ont paradoxalement été effectuées avec des programmes comportant finalement très peu d héritage. Il serait souhaitable de faire des études plus approfondies avec des programmes plus complexes. De plus, comme la plupart des autres métriques CK, celle-ci doit être mise en perspective : une mesure n est pas forcément significative à elle seule. Suivre l évolution de la profondeur d héritage au cours du temps peut être plus révélateur. En outre, il convient d interpréter les valeurs de cette métrique en perspective avec le contexte utilisation d un framework, etc. 27

42 Chapitre 1. Etat de l art et contexte Nom Nombre de fils dans l arbre d héritage (Number Of Children) Acronyme NOC Références [Chidamber et Kemerer, 1994, Gyimóthy et al., 2005] Définition Comptabilise le nombre de sous-classes immédiatement subordonnées à la classe dans la hiérarchie. Portée Classe Analyse Cette métrique montre l impact des modifications d une classe sur ses descendants. Plus une classe possède d enfants et plus les changements effectués doivent être testés. C est pourquoi cette métrique peut être un bon indicateur du niveau de tests mais également de l impact d une classe dans sa hiérarchie. En revanche, le fait de ne comptabiliser que les successeurs immédiats rend cette métrique insuffisante pour évaluer la qualité de la hiérarchie. Gyimóthy et al. ont étudié cette métrique et ne l ont pas validée d un point de vue prédiction d erreurs par rapport aux logiciels sur lesquels ils ont travaillé, constatant que les mesures obtenues avec NOC ne pouvaient être reliées aux nombres de bogues contenus dans la classe étudiée. En outre, ils affirment que cette métrique est peu fiable car selon les études menées et les manières de calculer celle-ci, les résultats peuvent varier significativement. Briand et al. pour leur part considèrent l hypothèse suivante : une classe avec de nombreuses sous-classes est difficile à modifier et demande plus de tests qu une autre. Ils prouvent que cette métrique est significative et considèrent que plus la valeur est élevée et plus le risque d erreur est élevé, comme l atteste les résultats de leur étude et des logiciels évalués [Briand et al., 1996]. Marinescu et Rațiu caractérisent l héritage sur l ensemble d une application à partir de deux métriques : la moyenne des classes dérivées la moyenne de la métrique NOC et la hauteur moyenne de la hiérarchie la moyenne de la métrique DIT [Marinescu et Rațiu, 2004]. Ils n utilisent pas cette métrique de manière isolée mais couplée à une autre pour pouvoir interpréter les résultats obtenus. Cette métrique n est donc pas significative à part entière mais doit être prise en compte parmi les autres métriques d héritage. Nom Réponse pour une classe (Response For a Class) Acronyme RFC Références [Chidamber et Kemerer, 1994] Définition RFC compte le nombre de méthodes accessibles par la classe, qu elles soient implémentées directement, surchargées ou disponibles par héritage (méthodes publiques, protégées et du package, pour Java). Elle correspond à la somme du nombre de méthodes héritées (NIM voir plus loin), du nombre de méthodes surchargées (NRM voir plus loin) et du nombre de méthodes implémentées (WMC ). Portée Classe Analyse Cette métrique reflète la complexité d une classe par rapport au nombre de communications avec les autres classes. Plus le nombre de méthodes accessibles par une classe est grand et plus la classe est complexe. Il subsiste trois points dans la définition de la métrique qui restent imprécis et demandent plus d explications : 28

43 1.2. Les métriques de code Bien que ce ne soit pas explicite dans la définition, le nombre de méthodes appelées devraient inclure les méthodes polymorphiques. C est pourquoi l ensemble des méthodes devrait inclure les signatures de celles-ci. Les méthodes héritées, aussi bien que les méthodes appelées à travers elles, devraient être incluses également puisqu elles peuvent être appelées par n importe quel objet de la classe. Il n est pas clairement expliqué si les méthodes indirectes appelées à travers les méthodes locales doivent être comptabilisées. Si c est le cas, le calcul de cette métrique devient potentiellement complexe. En pratique, la métrique se limite au premier niveau en cas d appels imbriqués i.e., uniquement les méthodes directement appelées dans les méthodes locales. Les trop nombreuses implémentations et façons d interpréter cette métrique la rendent peu fiable. Elle doit être définie plus précisément. Ces métriques sont calculables facilement, reflètent les expériences des développeurs et permettent de donner une vision d ensemble de la qualité et de l intégrité du design orienté objet. Il faut noter que cet ensemble de métriques constitue l un des plus référencé dans le domaine de l orienté objet et a pour but de mesurer la taille des classes, leur complexité, l héritage, le couplage, la cohésion et la collaboration entre les classes. On considère souvent ces métriques comme étant les plus critiquées dans de très nombreux articles mais elles restent sans conteste les plus utilisées dans le domaine orienté objet et les plus populaires. Basili et al. présentent les résultats de leur étude empirique de ces métriques dans le but de les utiliser en tant qu indicateurs de la qualité du logiciel [Basili et al., 1996]. Ils démontrent d une part que ces métriques sont de meilleures candidates à la prédiction des bogues que les métriques traditionnelles puisqu elles peuvent être calculées plus en amont du cycle de vie du logiciel. D autre part, ils démontrent également que certaines de ces métriques, notamment DIT, RFC et NOC sont utiles pour la détection d erreurs potentielles : il y a corrélation entre les chiffres obtenus par ces métriques et les erreurs effectives détectées dans le code. En effet, plus la métrique DIT est élevée et plus le risque de bogues est significatif, de même pour les métriques RFC et NOC. Subramanyam et al. appliquent, quant à eux, ces métriques sur des programmes écrits d une part en C++ et d autre part en Java [Subramanyam et Krishnan, 2003]. Ils interprètent les valeurs trouvées au niveau des classes par rapport au design orienté objet et aux défauts de conception du logiciel. Ils démontrent que l interprétation des résultats des métriques diffère selon le langage utilisé en rapport avec les différences structurelles de ces deux langages. De plus, ils constatent qu une valeur élevée de ces métriques signifient également une valeur élevée des défauts de conception. Ils mettent en évidence la corrélation entre les métriques DIT et CBO (en effet la métrique CBO compte également l héritage évalué par la métrique DIT ), et confirment l utilité des métriques définies par Chidamber et Kemerer dans le cadre de la détection des erreurs de conception. Gyimóthy et al. présentent une étude appliquant les métriques CK aux logiciels Open Source [Gyimóthy et al., 2005]. Ces derniers suivent des modes de développement particuliers : les équipes sont dirigées différemment et à distance, il n existe pas obligatoirement d uniformisation dans la manière de développer, chacun peut contribuer au code, etc. Il convenait donc de s intéresser à la validation de ces métriques dans ce cas particulier. Ils concluent que CBO semble être la 29

44 Chapitre 1. Etat de l art et contexte métrique la mieux adaptée dans la prédiction d erreurs comme nous le détaillons ensuite. En revanche, ils concluent que la métrique DIT n est pas un bon indicateur. Ainsi, les différentes études montrent que les métriques de Chidamber et Kemerer sont très utiles, même si elles ne suffisent pas à elles seules à définir entièrement la qualité du code mesuré. Les métriques primitives restent en effet indispensables. De plus, les résultats parfois contradictoires entre les différentes études de ces métriques s expliquent également par la différence de date entre elles. En effet, un code orienté objet datant de 1996 n est pas architecturé de la même façon qu un code datant de Toutefois, on notera une réserve quant à la métrique LCOM, fortement décriée et remplacée par d autres versions plus adaptées comme nous l expliquons par la suite. Les métriques de Lorenz et Kidd Lorenz et Kidd ont déterminé également un certain nombre d autres métriques de base dont nous retiendrons les principales [Lorenz et Kidd, 1994] : NOM pour Number Of Methods ; NIM pour Number of Inherited Methods ; NRM pour Number of overriden Methods ; SIX pour Specialization IndeX. Nous donnons maintenant une définition précise de chacune de ces métriques. Nom Nombre de méthodes (Number of Methods) Acronyme NOM Références [Lorenz et Kidd, 1994] Définition NOM comptabilise le nombre de méthodes définies localement à une classe, comptant les méthodes privées aussi bien que publiques. Les méthodes surchargées sont également comptabilisées. Portée Classe Analyse NOM est une métrique très simple qui donne une indication sur la complexité d une classe en terme de responsabilité. Cependant, elle ne prend pas en compte la complexité des méthodes elles-mêmes. WMC est donc plus représentatif pour cela. NOM peut être utilisé pour effectuer des ratios fondés sur les méthodes. Nom Nombre de méthodes héritées (Number of Inherited Methods) Acronyme NIM Références [Lorenz et Kidd, 1994, Briand et al., 1998a] Définition NIM est une métrique simple qui permet de mesurer le nombre de comportements/ propriétés qu une classe peut réutiliser. Elle compte le nombre de méthodes héritées par une classe : les méthodes auxquelles une classe peut accéder par l intermédiaire de ses super-classes. 30

45 1.2. Les métriques de code Portée Classe Analyse Plus le nombre de méthodes héritées est élevé, plus la classe peut faire appel à des éléments hérités. Il peut être intéressant de mettre cette métrique en perspective avec le nombre réel d appels à ces méthodes, à savoir les méthodes super et les appels à des méthodes non définies à l intérieur de la classe. Cela permet de vérifier à quel point les propriétés de réutilisation des langages orientés objet sont utilisées. Cependant, cette comparaison n a de sens que lors d héritage de classes simples. En effet, en cas d héritage d une très grande classe, la sous-classe n utilisera pas et n aura pas besoin de toutes les propriétés de celle-ci. Nom Nombre de méthodes surchargées (Number of overriden Methods) Acronyme NRM Références [Lorenz et Kidd, 1994] Définition NRM comptabilise le nombre de méthodes surchargées i.e., définies dans la super-classe et redéfinies dans la classe. Cette métrique inclut les méthodes super. Portée Classe Analyse Cette métrique montre le degré de personnalisation d une sous-classe par rapport aux comportements dont elle hérite. Quand une méthode surchargée est appelée par les méthodes héritées, elle représente souvent une hook method. Un grand nombre de méthodes surchargées indique également une grande spécialisation de la classe par rapport aux comportements hérités de sa super-classe. Cependant, les classes avec beaucoup de super invocations sont rares (par exemple pour VisualWorks.Core il y a 1937 méthodes surchargées pour 229 classes : une moyenne de 8,4 méthodes surchargées par classe). En comparant avec le nombre de méthodes ajoutées, on peut déterminer le type de relation d héritage : soit il s agit de personnaliser les comportements d une classe, soit il s agit d ajouter de nouveaux comportements à une classe. Cependant, Briand et al. concluent que le recours à des méthodes surchargées augmentent le risque d erreurs dans un programme [Briand et al., 1998a]. Nom Index de spécialisation (Specialization IndeX) Acronyme SIX Références [Lorenz et Kidd, 1994, Mayer, 1999] Définition SIX = NRM DIT NOM + NIM Cette métrique détermine le niveau de spécialisation d une classe en tenant compte de sa profondeur d héritage. Cette métrique fait le ratio entre le nombre de méthodes surchargées et le total des méthodes définies dans la classe, pondéré par la profondeur d héritage. Lorenz et Kidd précisent que les méthodes qui invoquent les méthodes super ou qui surchargent des 31

46 Chapitre 1. Etat de l art et contexte templates ne sont pas inclues. La redéfinition et la surcharge de méthodes sont de moins en moins souhaitables au fur et à mesure où l on descend dans la hiérarchie d une classe. Cela augmente la complexité du développement. Portée Classe Analyse Cette métrique a été conçue pour rendre compte à quel point les classes sont structurées dans la hiérarchie en spécialisant le code de leur super-classe. Bien qu elle soit définie avec précision et facile à calculer, cette métrique n a jamais fait l objet d une réelle validation théorique et empirique. Même s il est communément accepté que plus une classe est spécialisée et plus elle est difficile à maintenir, ce fait n a jamais été prouvé. De plus, cette métrique ne prend pas en compte la portée de la classe. Et, étant donné qu elle utilise la métrique DIT pour ses calculs, elle possède les mêmes limites. Plutôt que de comprendre cette métrique comme une évaluation qualitative, elle devrait être comprise comme un indicateur pour les classes qui doivent être analysées avec plus d attention. Lorenz et Kidd affirment que le seuil maximum à ne pas dépasser est de 15% ce qui correspond pour eux à un maximum de 3 méthodes surchargées au premier niveau d héritage et moins de trois méthodes surchargées pour les niveaux suivants. Cela peut être obtenu par exemple avec NRM = 3, DIT = 2, NOM = 20, NIM = 20, soit : SIX = = 15% Selon Mayer, cette métrique semble raisonnable et logique, mais en pratique, elle est trop incohérente et trop grossière dans son calcul pour être utile [Mayer, 1999]. Il montre avec deux exemples théoriques que cette métrique ne reflète pas la compréhension spontanée de la spécialisation et qu il serait suffisant de simplement multiplier le nombre de méthodes surchargées (NRM ) avec la profondeur d héritage (DIT ). Il affirme que diviser par le nombre de méthodes n ajoute rien ; en fait cela réduit considérablement sa précision Les métriques de design Ces métriques évaluent les entités d un code source par rapport au respect des principes de design. Ces métriques, en faisant ressortir les entités qui ne respectent pas ces principes, mettent en évidence les lacunes générales du design dont la correction peut amener une amélioration globale de la qualité. Nous distinguons les métriques qui traitent du couplage, les métriques qui mesurent la cohésion de classes et les métriques qui évaluent la cohésion des packages. Le couplage Le couplage est un des principes de design les plus importants à considérer. Stevens et al. qui introduisent en premier la notion de couplage dans le contexte des techniques de développement structuré ont défini le couplage comme la mesure de la force de l association créée par la connexion d un module à un autre [Stevens et al., 1974]. Par conséquent, plus le couplage entre modules est élevé, i.e., plus ils sont fortement liés, plus il est difficile de les comprendre, de les modifier ou de les corriger, et donc plus le système est complexe. 32

47 1.2. Les métriques de code En langage orienté objet, un couplage excessif indique la faiblesse de l encapsulation, ce qui peut induire une absence de possibilité de réutilisation du code. Un couplage élevé indique également un risque d erreurs plus élevé dû à la grande interaction entre les classes. Nom Couplage entre les objets (Coupling Between Object classes) Acronyme CBO Références [Chidamber et Kemerer, 1994],[Fenton et Pfleeger, 1996],[Martin, 2005] Définition Deux classes sont couplées ensemble si l une d elles utilise l autre, i.e., une classe appelle une méthode ou accède à un attribut d une autre classe. Le couplage à travers l héritage et le polymorphisme sont également pris en compte. Pour une classe, la métrique CBO compte le nombre de classes auxquelles elle est reliée, couplée. Portée Classe Analyse Un couplage excessif est préjudiciable à la conception modulaire et empêche les principes de réutilisation. Plus la classe est indépendante et plus il est facile de la réutiliser dans une autre application. Un fort couplage complique l application : il rend les classes trop difficiles à comprendre, maintenir et corriger. La métrique évalue donc les notions d efficacité et de réutilisabilité. CBO ne mesure que le couplage direct. Prenons par exemple trois classes, A, B et C avec A couplée à B et B couplée à C. Selon les cas, il peut arriver que A dépende de C à travers B. Cependant, CBO ne prend pas cette dépendance en compte. CBO est à distinguer de la métrique de couplage efférent (qui ne compte que les dépendances entrantes) et de la métrique de couplage afférent (qui ne compte que les dépendances sortantes). Cohésion de classe La cohésion de classe est également une notion très importante en langage orienté objet. Elle vérifie le degré de responsabilité de la classe. Une classe correctement définie doit avoir des responsabilités spécifiques et délimitées, ses responsabilités forment un tout cohérent. En effet, un programme orienté objet avec des classes cohésives sera plus facile à : comprendre. Elle possède un rôle bien défini et il est plus aisé de comprendre ses méthodes ; maintenir. Il est plus facile de déterminer les classes à modifier ou à vérifier puisqu elles sont clairement identifiées dans leur rôle ; modifier. L ajout de nouvelles fonctionnalités sera plus aisé. On évite d alourdir le code des classes déjà définies, on crée plus facilement de nouvelles classes dédiées ; tester. L écriture des tests unitaires est plus aisée. Les classes peuvent être plus facilement testées, puisqu elles ont des responsabilés clairement définies ; réutiliser. Les classes ayant un rôle clair et limité, il est plus facile de les utiliser pour un autre programme. Elles sont moins dépendantes du contexte, ce qui évite également de dupliquer le code inutilement. Si une classe possède trop de responsabilités, il convient de la subdiviser. La métrique LCOM manque de cohésion des méthodes est l une des premières métriques utilisées pour évaluer le manque de cohésion d un code orienté objet. Elle s inspire de l évaluation de la cohésion d un programme en langage procédural qui mesure l inter-contiguité entre les portions d un programme. Chidamber et Kemerer qui ont défini cette métrique s appuient sur les variables 33

48 Chapitre 1. Etat de l art et contexte d instance utilisées par les méthodes. Ils partent du principe suivant : les variables d instance représentent les propriétés, l état d un objet. Plus les méthodes définies dans la classe partagent les mêmes variables d instance, plus la cohésion est grande. Dans le cas où les méthodes ne partagent aucune variable d instance, elles pourraient tout aussi bien être définies dans des classes différentes. De plus, Chidamber et Kemerer affirment que moins une classe est cohésive, plus elle est complexe et donc le risque d erreur de programmation augmente. Une classe qui possède un trop grand nombre de fonctionnalités est moins facile à maintenir et à prédire. La cohésion des méthodes au sein d une classe est souhaitable, car elle favorise l encapsulation, tandis que le manque de cohésion implique que les classes devraient probablement être divisées en deux ou plusieurs sous-classes. Bien qu il existe plusieurs façons de définir les métriques comptabilisant le manque de cohésion d une classe, toutes ces définitions évaluent la cohésion d une classe à travers les relations entre les différentes méthodes de la classe. Il existe différentes versions de cette métrique : certaines tentent de corriger des lacunes tandis que d autres essaient d adopter un point de vue différent quant à la façon d envisager le manque de cohésion en langage orienté objet. D où la nécessité de vérifier de quelle manière cette métrique est calculée. La plupart de ces métriques restent très naïves dans l intention qu elles souhaitent capturer. En effet, définir la cohésion d une classe uniquement sur le partage des variables d instances n est pas suffisant. Une classe peut avoir une responsabilité centrale par rapport au domaine qu elle représente mais également posséder des responsabilités périphériques constituées par des méthodes qui échangent des informations de calcul. Cela ne signifie pas que la classe doit être divisée. Une classe ne doit être divisée que lorsqu il existe deux groupes d attributs et de méthodes qui ne sont pas accédés simultanément. Les différents métriques LCOM calculent leur résultat de manière inversée : une forte cohésion est traduite par une valeur basse, tandis qu une faible cohésion est signifiée par une valeur élevée de la métrique. Nous détaillons les différentes métriques telles que définies par Briand, puisque ces définitions semblent aujourd hui être les plus généralement partagées [Briand et al., 1998b]. m5 m1 m2 m3 m4 a1 a2 a3 Figure 1.4 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. Nom Manque de cohésion des méthodes (Lack of COhesion in Methods) 34

49 1.2. Les métriques de code Acronyme LCOM1 Références [Chidamber et Kemerer, 1994][Briand et al., 1998b] Définition LCOM1 est le nombre de paires de méthodes dans une classe qui ne référencent pas d attribut commun. Portée Classe Analyse Dans la figure 1.4 où les m i représentent les méthodes appelées par d autres méthodes ou accédant aux attributs a j, LCOM1 = 7. Les paires qui n ont pas d attribut commun sont (m 1, m 3 ), (m 1, m 4 ), (m 2, m 4 ), (m 5, m 1 ), (m 5, m 2 ), (m 5, m 3 ), (m 5, m 4 ). La définition de cette métrique est basique et a fait l objet de nombreux débats contre elle. En général, cette façon de calculer doit être évitée autant que possible. En particulier, il n a pas de sens de considérer que toutes les méthodes d une classe doivent accéder directement à tous les attributs de la classe. Cette métrique donne des résultats similaires sur des classes qui ont pourtant un design totalement différent. La plus grosse lacune de cette métrique se rencontre dans le cas d utilisation de méthodes accesseurs et mutateurs (par exemple getter et setter en Java). En effet, ces méthodes sont utilisées comme seules méthodes d accès aux variables et le calcul de LCOM devient alors caduque. Cette métrique ne considère que les méthodes et les attributs implémentés dans la classe. Les méthodes et attributs hérités sont exclus du calcul. Basili et al. estiment pour leur part que les résultats obtenus avec la métrique LCOM sont décevants et non appropriés : ils attribuent ce défaut à la définition même de la métrique qui renvoie la valeur 0 dans de trop nombreux cas. Nom Manque de cohésion des méthodes 2 (Lack of COhesion in Methods 2) Acronyme LCOM2 Références [Briand et al., 1998b] Définition Soient deux variables entières P et Q. Pour chaque paire de méthodes de la classe, si elles accèdent à un ensemble disjoint de variables d instance, alors P est incrémenté de un, sinon Q est incrémenté de un. On définit LCOM2 comme étant : LCOM2 = { P Q si P > Q 0 sinon. On distingue deux valeurs remarquables : LCOM2 = 0 qui indique une classe cohésive et LCOM2 > 0 qui indique que la classe peut être divisée en plusieurs classes puisque ses variables d instances appartiennent à des ensembles disjoints. Portée Classe Analyse Dans la figure 1.4, LCOM2 = 4. P est la somme de toutes les paires qui n ont aucun attribut en commun, et donc, P = 7. Il s agit des paires suivantes : (m 1, m 3 ), (m 1, m 4 ), (m 2, m 4 ), (m 5, m 1 ), (m 5, m 2 ), (m 5, m 3 ), (m 5, m 4 ). Q est calculé avec les autres paires ((m 1, m 2 ), (m 2, m 3 ), (m 3, m 4 )), d où Q = 3. Le résultat est P Q = 4. 35

50 Chapitre 1. Etat de l art et contexte Cette métrique ne considère que les méthodes et les attributs implémentées dans la classe. Les méthodes et attributs hérités sont exclus du calcul. De plus, elle donne également le même résultat alors que les classes mesurées peuvent avoir un design totalement différent. Elle donne également un résultat incorrect en cas de méthodes accesseurs (getter et setter en Java). De plus, cette métrique n est pas monotone : si Q > P, alors LCOM2 = 0. Nom Manque de cohésion des méthodes 3 (Lack of COhesion in Methods 3) Acronyme LCOM3 Références [Briand et al., 1998b] Définition LCOM3 correspond au nombre de composants connectés dans le graphe des méthodes. Les méthodes sont connectées avec celles qui accèdent aux mêmes attributs. Portée Classe Analyse Dans la figure 1.4, LCOM3 = 2. Le premier composant est (m 1, m 2, m 3, m 4 ) : les méthodes sont connectées directement ou indirectement à travers le même attribut. Le second composant est (m 5 ) car cette méthode n accède à aucun argument, elle n est pas connectée. Cette métrique ne considère que les méthodes et les attributs implémentées dans la classe. Les méthodes et attributs hérités sont exclus du calcul. De plus elle donne des résultats incorrects quand il y a des méthodes accesseurs puisque seules les méthodes directement connectées sont prises en compte. De plus, les méthodes constructeurs posent problème parce qu elles créent des connexions indirectes entre les méthodes qui utilisent différents attributs, ce qui augmente la cohésion, alors que ce n est pas réellement le cas. Nom Manque de cohésion des méthodes 4 (Lack of COhesion in Methods 4) Acronyme LCOM4 Références [Briand et al., 1998b] Définition LCOM4 est le nombre de composants connectés dans un graphe de méthodes. Les méthodes sont connectées dans un graphe lorsqu elles accèdent au même attribut ou lorsqu elles s appellent. LCOM4 améliore LCOM3 en prenant en compte ces appels. Il faut noter ces trois valeurs remarquables : LCOM4 = 1 indique une classe cohésive ; LCOM4 2 indique un problème. La classe doit être scindée en classes plus petites ; LCOM4 = 0 est obtenu quand la classe ne possède aucune méthode. Portée Classe Analyse Dans la figure 1.4, LCOM4 = 1. Le seul composant est (m 1, m 2, m 3, m 4, m 5 ) car ces méthodes sont directement ou indirectement connectées à une même collection d attributs. S il existe plus de deux composants, la classe devrait être scindée en classes plus petites, chacune encapsulant un composant connecté. 36

51 1.2. Les métriques de code Nom Manque de cohésion des méthodes 5 (Lack of COhesion in Methods 5) Acronyme LCOM5, encore notée LCOM* Références [Briand et al., 1998b] Définition LCOM5 = NOM m M NOAcc(m) NOA NOM 1 où M est l ensemble des méthodes de la classe, NOM le nombre de méthodes, NOA le nombre d attributs et N OAcc(m) le nombre d attributs de la classe accédés par la méthode m. Portée Classe Analyse Dans la figure 1.4, LCOM5 = 3 4, car NOM = 5, NOA = 3, NOAcc = 6. LCOM5 varie dans l intervalle [0; 1]. Bien que normalisée, elle peut tout de même renvoyer une valeur supérieure à deux quand par exemple il n y a que deux méthodes et pas d attributs accédés. Cette métrique considère que chaque méthode devrait accéder à tous les attributs dans une classe complètement cohésive, ce qui n est pas forcément gage d un bon design. Cohésion des packages Nous analysons ici les métriques de design définies par Martin. Celui-ci décrit des règles d architecture et de design de packages dans [Martin, 1997, Martin, 2005, Martin, 2000]. Il y propose plusieurs principes répartis comme suit : principes de cohésion : ces principes décrivent les règles à suivre pour construire un package cohérent ; Reuse-Release Equivalence Principle (REP) : le principe de réutilisation et d équivalence. Un bon package doit contenir des classes réutilisables entre elles. Il s agit d inclure dans un package des classes qui sont équivalentes sur le plan des versions ; Common Closure Principle (CCP) : les classes qui changent ensemble vont ensemble. Afin de minimiser le nombre de packages impactés lors d une modification, il faut regrouper les classes qui changent ensemble ; Common Reuse Principle (CRP) : les classes qui ne sont pas utilisées entre elles ne doivent pas être mises ensemble. principes de couplage : ces principes décrivent les relations entre packages. Acyclic Dependencies Principle (ADP) : les dépendances entre packages ne doivent pas former de cycles ; Stable Dependencies Principle (SDP) : le principe de stabilité est intrinsèquement lié, dans ce cas, à la définition de cette notion. La stabilité est vue sous l angle de la quantité de travail requise pour effectuer une modification des dépendances. Par conséquent, elle est liée à la taille du package et à sa complexité, mais aussi aux dépendances du package. Un package qui possède de nombreuses dépendances est considéré ici comme étant stable car l effort requis pour le modifier est conséquent le travail à fournir pour s assurer que les dépendances sont toujours satisfaites est considérable. Ainsi, un paquet avec de nombreuses dépendances entrantes est stable (il est responsable des packages entrants), et un package 37

52 Chapitre 1. Etat de l art et contexte sans dépendance est considéré comme indépendant et instable. Le principe énoncé ici est le suivant : plus un package a de dépendances entrantes et plus il possède de bonnes raisons pour ne pas le modifier car la quantité de travail à fournir est élevée. Les métriques qui mesurent ce principe sont les métriques de couplage afférent (Ca), couplage efférent (Ce) et d instabilité (I ) détaillées ci-après ; Stable Abstractions Principle (SAP) : des packages stables doivent être des packages abstraits. Pour améliorer la flexibilité des applications, les packages instables étant facilement modifiables, ils doivent contenir les classes qui seront souvent modifiées, tandis que les packages stables étant difficilement modifiables, ils doivent être facilement étendus, donc avoir un degré élevé d abstraction. La métrique utilisée pour mesurer cette propriété est appelée A pour abstractness metric et détaillée ci-après. A partir de ces principes, Martin a donc défini un certain nombre de métriques permettant de mesurer ces propriétés [Martin, 1997]. Cependant les résultats fournis par ces métriques sont difficiles à interpréter comme nous l expliquons ci-dessous. Nom Couplage efférent (Efferent Coupling) (module) Acronyme Ce Références [Martin, 2005] Définition Cette métrique mesure le couplage efférent d un module. Il s agit du nombre de modules dont dépend celui qui est mesuré les dépendances sortantes : voir figure 1.5). Portée Classe, package Analyse Martin définit tout d abord cette métrique comme étant le nombre de classes du package qui dépendent de classes extérieures [Martin, 1997]. Puis, plus récemment il précise sa définition du couplage efférent pour un package comme étant le nombre de classes extérieures au package dont dépendent les classes contenues dans ce package [Martin, 2000]. La définition courante est généralisée par rapport au concept de module : un module est soit toujours une classe ou toujours un package. Cette métrique est un indicateur d indépendance du code. Nom Couplage afférent (Afferent Coupling) (module) Acronyme Ca Références [Martin, 2005] Définition Cette métrique mesure le couplage afférent d un module, à savoir le nombre de modules qui dépendent du module mesuré les dépendances entrantes : voir figure 1.5). Portée Classe, package Analyse Pour un package, la définition de cette métrique est le nombre de classes externes qui dépendent d une des classes du package. Il s agit d un indicateur de responsabilité d un package. 38

53 1.2. Les métriques de code Figure 1.5 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). Nom Abstraction (Abstractness) Acronyme A Références [Martin, 1997] Définition L abstraction est calculée par le ratio entre le nombre de classes abstraites et le nombre total de classes d un package, dans l intervalle [0, 1]. A(P)= 0 signifie que le package est totalement concret tandis que A(P)= 1 signifie qu il est totalement abstrait. Portée Package Analyse Cette métrique ne peut être analysée seule. En effet, dans un programme certains packages doivent être abstraits et d autres concrets. Nom Instabilité (Instability) Acronyme I Références [Martin, 1997] Ce(P ) Définition La formule de la métrique est I = Ce(P )+Ca(P ), définie dans l intervalle [0, 1], avec P un package. I(P)= 0 signifie que le package est stable à son maximum (Ce(P ) = 0) i.e., il ne contient aucune dépendance sortante et ne peut être modifié sans grande conséquence. A contrario, I(P)= 1 signifie que le package ne contient aucune dépendance entrante (Ca(P ) = 0) et qu il est donc instable. 39

54 Chapitre 1. Etat de l art et contexte Cette métrique est utilisée pour évaluer le principe de dépendance stable (SDP) : selon Martin, un package ne devrait dépendre que de packages plus stables que lui, i.e., il devrait avoir une valeur I plus grande que n importe laquelle de ses dépendances. Portée Package Analyse Cette métrique ne mesure pas la possibilité de modification interne du package mais plus exactement l impact potentiel d une modification d un package sur les autres packages. Un package totalement stable pourra être modifié mais cela aura un impact sur les packages dépendants. En revanche, une modification d un package instable n aura pas de conséquances sur ses dépendances. Toutefois, une valeur intermédiaire de cette mesure, dans l intervalle [0, 1] est difficilement interprétable. Une bonne façon d interpréter l instabilité est de la considérer comme une mesure du couple responsabilité/indépendance. Un package stable (I = 0) est indépendant des autres mais également responsable des autres du fait de ses dépendances. Un package instable est dépendant des autres et non responsable pour les autres packages. Le principe de stabilité d un package peut être défini transitivement : un package est stable seulement si ses dépendances le sont également. Nom Distance (Distance) Acronyme D Références [Martin, 1997] Définition D = A+I 1 2 ou (normalisée) D = A + I 1. Un package doit être équilibré entre abstraction et instabilité, i.e., entre abstrait et stable d un côté, concret et instable de l autre. Cette règle est sous-jacente à l équation A + I 1 = 0. D est la distance à cette séquence principale et doit être égale à 0. Cette métrique est utilisée pour calculer le principe SAP : les packages stables devraient être abstraits (A = 1 et I = 0) tandis que les instables devraient être concrets (A = 0 et I = 1). Portée Package Analyse Cette métrique part du principe qu il y a une corrélation entre abstraction et instabilité et réciproquement pour qualifier le design d un package. Toutefois, une telle corrélation semble difficile à établir étant donné la différence dans la nature des données sur laquelle chaque métrique est calculée. De plus, aucune étude empirique à grande échelle n a été menée pour le confirmer. Cette métrique est sensible aux cas extrêmes. Par exemple, un package avec uniquement des classes concrètes (A = 0) mais sans dépendances sortantes (I = 0) a une distance D = 1. Et pourtant, ce package n est pas nécessairement d un mauvais design. 40

55 Table 1.1 Table récapitulative des métriques Les métriques de code Nom Acronyme Portée Définition en page Complexité cyclomatique V(G) fonction, méthode, classe 21 Complexité cyclomatique essentielle ev(g) fonction, méthode, classe 22 Nombre de lignes de code source SLOC fonction, méthode 24 Nombre de lignes de commentaires CLOC fonction, méthode 25 Nombre pondéré de méthodes par classe WMC classe 26 Profondeur de l arbre d héritage DIT classe 26 Nombre de fils dans l arbre d héritage NOC classe 28 Réponse pour une classe RFC classe 28 Nombre de méthodes NOM classe 30 Nombre de méthodes héritées NIM classe 30 Nombre de méthodes surchargées NRM classe 31 Index de spécialisation SIX classe 31 Couplage entre les objets CBO classe 33 Manque de cohésion des méthodes LCOM( ) classe 34 Couplage efférent Ce classe, package 38 Couplage afférent Ca classe, package 38 Instabilité I package 39 Abstraction A package 39 Distance D package 40 Le tableau 1.1 récapitule ces métriques qui sont les plus largement utilisées pour mesurer les différentes propriétés que doit posséder un logiciel de qualité. Il existe également d autres métriques, non citées ici, mais qui sont, soit hors de notre périmètre de mesure de la qualité, soit trop marginales, soit redondantes Les conventions de codage En plus des métriques précédentes qui évaluent l architecture du code, il existe des règles et conventions d écriture de code. Ces conventions ont pour but d harmoniser l écriture du code afin de diminuer le nombre de bogues et d en faciliter la compréhension et la maintenance. En effet, plus un logiciel vieillit et plus il est sujet à modifications successives ou à des réécritures de portions de code, par exemple. Il est important de garder dans la mesure du possible un style identique, quel que soit le développeur qui écrit le code, afin de faciliter la lecture et la compréhension de code par le plus grand nombre. Organiser la nomenclature des noms de packages, de variables, par exemple, fixe des repères pour identifier plus rapidement un objet dans un code. Les conventions peuvent également se rapporter à des pratiques connues génératrices potentiellement de bogues. Ainsi, fixer la manière dont un test un if doit être écrit (par exemple toujours mettre le bloc qui suit le if entre accolades y compris si celui-ci n a qu une ligne) facilite à la fois la lecture mais également évite un certain nombre d erreurs. 41

56 Chapitre 1. Etat de l art et contexte Ces conventions se répartissent en général de la sorte : règles de syntaxe et mise en forme du code source : par exemple, de quelle manière les if sont écrits (placement des accolades, retour à la ligne ou encore arguments sur une ou plusieurs lignes) ; règles de nommage qui regroupent les conventions d appellation des données, au sens large, dont les attributs, méthodes, classes, packages, paramètres. On peut, par exemple, rendre les préfixes obligatoires, imposer l utilisation de majuscules ou minuscules ; règles de programmation qui recensent généralement les mauvaises pratiques de programmation connues pour être des sources de bogues potentiels. Par exemple, les boucles ou des tests imbriquées qui doivent suivre un formalisme précis d écriture ; règles de documentation qui s assurent du respect de formatage de la documentation. En général, il s agit de respecter un format permettant la génération automatique de documentation à partir du code source, par exemple, la Javadoc ; règles d architecture qui vérifient le respect de l architecture préalablement définie pour le programme et l utilisation à bon escient des Design Pattern. Ces règles sont soumises à l application stricte des règles de nommage et de mise en forme ; règles d utilisation de certains composants tels que les frameworks de traçage ou les socles d ergonomie. Il faut donc d une part fixer ces conventions scrupuleusement mais également vérifier leur respect. Des outils de Rule Checking tels que PMD 3 et Checkstyle 4 vérifient que les conventions de programmation définies par l entreprise sont respectées. Cependant, il faut également être attentif en utilisant ces logiciels : vouloir à tout prix respecter toutes les règles peut mener au paradoxe d introduire des bogues au lieu d en éviter Conclusion Toutes les métriques citées dans cette section sont largement utilisées dans le cadre du développement d un logiciel. Les développeurs y ont recours comme une aide pour évaluer la qualité du programme. Il faut cependant être prudent lorsque l on utilise ces métriques dans le cadre de la qualité. Tout d abord, il n est pas rare de constater qu une même métrique ne donne pas le même résultat selon l outil utilisé pour les mesurer. En effet, les définitions de ces métriques sont parfois vagues ou sujets à interprétation (par exemple les lignes de code qui peuvent être définies de différentes manières avec ou sans les commentaires, ligne de code physique ou instruction, etc.), parfois simplifiées (exclusion de la complexité cyclomatique dans le calcul de la métrique WMC ), parfois adaptées (la mesure de la complexité cyclomatique varie d importance selon l outil utilisé). Certaines métriques semblent encore trop mal définies pour être réellement utiles (la métrique RFC par exemple), ou encore ne pas apporter de renseignements réellement pertinents (la métrique SIX par exemple comme l affirme Mayer). De plus, le résultat de ces métriques peut également être sujet à différentes lectures : la profondeur d héritage par exemple doit être mise en perspective avec ce dont la classe hérite vraiment (un framework ou des classes définies dans l application). 3. http ://pmd.sourceforge.net 4. http ://checkstyle.sourceforge.net 42

57 1.3. Les techniques de tests Il est donc important de décider, d une part des métriques qui seront utilisées pour l évaluation de la qualité du code, d autre part de définir en détail la formule de calcul de la métrique. Ensuite, il est nécessaire de donner du sens aux mesures effectuées et de définir, notamment grâce au savoir-faire des développeurs, les intervalles de mesures qui caractérisent la qualité pour une métrique donnée comme nous le détaillons dans les sections 2.3 et Les techniques de tests Mesurer la qualité d une application ne consiste pas uniquement à mesurer la qualité de son code source. Il faut également s intéresser à la qualité des tests effectués autour de l application. Il existe différents types de tests que nous présentons dans cette section. A partir de ces techniques nous avons formalisé des règles de qualité évaluant les techniques de tests Les tests en boîte blanche Les tests en boîte blanche également appelés tests white-box ou encore tests structurels, se fondent sur l analyse de la structure interne du composant testé. Ils vérifient sa structure, comme par exemple la validité des branches résultant des instructions conditionnelles dans un code. Les tests unitaires des développeurs, par exemple, sont classés dans cette catégorie de tests. Ces tests reposent sur l analyse du code modélisé selon les deux modèles suivants : le graphe de flot de contrôle ; le flot de données associé Graphe de flot de contrôle Les techniques de tests structurels reposent sur l analyse de la structure du programme modélisé sous la forme d un graphe de flot de contrôle [Myers, 1979]. Un graphe de flot de contrôle fait ressortir les chemins d exécution résultant des différentes structures de contrôle du code : les conditions et les itérations. Un graphe de flot de contrôle ou Control Flow Graph, noté CFG, est un graphe dirigé, dans lequel : N est l ensemble des nœuds qui représentent des blocs d instructions séquentielles ; E est l ensemble des arcs, ou branches, qui représentent les possibilités de transitions d un nœud à un autre ; n e et n s, respectivement, sont les nœuds uniques d entrée et de sortie du graphe ; chaque nœud n N est un bloc d instructions ; chaque chemin du graphe voir définition ci-après partant du nœud d entrée jusqu au nœud de sortie représente une exécution possible de l application. La figure 1.6 représente le graphe de flot de contrôle associé au code de l exemple 1. Chaque nœud représente des blocs d instructions et chaque arc, ou branche, représente une condition. Chemin Un chemin c de longueur p dans un graphe de flot de contrôle est une suite finie de nœuds : où (n i, n i+1 ) E, n 0 = n s et n p = n e. c = (n 0, n 1,..., n i,..., n p ) 43

58 Chapitre 1. Etat de l art et contexte Algorithm 1 Calcul du min de trois nombres if a < b then if a < c then min = a else min = c end if else if b < c then min = b else min = c end if return min A a < b a >= b B C a < c a >= c a < b a >= b D min = a E min = c F min = b G min = c H return min Figure 1.6 Graphe de flot de contrôle de l algorithme Un chemin est dit faisable si les conditions nécessaires à son parcours peuvent être satisfaites pour le parcourir, sinon il est dit infaisable. Dans l exemple précédent, les chemins faisables sont : c 0 = abdh, c 1 = abeh, c 2 = acfh, c 3 = acgh. En revanche, le chemin beh est infaisable puisqu il ne part pas du nœud d entrée, tout comme le chemin abfh puisqu aucune branche ne relie b à f. Couverture du graphe de flot de contrôle L idée sous-jacente aux tests structurels consiste à couvrir tous les chemins possibles d exécution du système. Or, le nombre de chemins possibles à parcourir peut très vite devenir exponentiel, voir quasiment infini. Il faut donc envisager une stratégie pour couvrir un maximum de chemins possibles, de la manière la plus optimale possible. Pour y parvenir, les tests structurels définissent des objectifs à atteindre par rapport à la couverture de la structure du programme, la couverture du graphe de flot de contrôle. On distingue différents types de couverture d un graphe de flot de contrôle. Les plus utilisés sont généralement : 44

59 1.3. Les techniques de tests toutes-les-instructions (tous-les-noeuds) : chaque instruction est exécutée au moins une fois. Chaque nœud est atteint par au moins un chemin parmi les chemins parcourus ; tous-les-arcs : chaque décision est exécutée au moins une fois dans ces deux assertions (vrai et faux). Chaque arc est couvert par au moins un des chemins parmi les chemins parcourus ; tous-les-i-chemins : tous les chemins possibles en passant de 0 à i fois dans les boucles ; tous-les-chemins-linéairement-indépendants : tous les arcs sont couverts dans chaque configuration possible ; chemins limites : tous les chemins qui traversent une boucle mais ne l itèrent pas ; chemins intérieurs : tous les chemins qui itèrent une boucle une seule fois ; tous-les-chemins : il s agit d exécuter tous-les-i-chemins en donnant à i la valeur maximum qu elle peut atteindre dans le programme Flot de données Un flot de données s intéresse aux données d un programme : les variables et leur utilisation. On distingue les assignations de variables qui correspondent aux modifications effectuées sur celles-ci (affectation d une valeur à une variable ou modification de la valeur d une variable) et les utilisations de variables (accès au contenu de la variable). Un flot de données est représenté par une annotation du graphe de flot de contrôle par les assignations et utilisations des variables. Couverture du flot de données Les critères de couverture du flot de données sont les suivants : toutes-les-assignations : pour chaque assignation, il y a au moins un chemin reliant l instruction de l assignation de cette variable à une instruction d utilisation ; toutes-les-utilisations : chaque assignation est exécutée au moins une fois et atteint toutes les utilisations qui s y réfèrent, les tests produits couvrent toutes les utilisations ; tous-les-du-chemins : ajoute au critère précédent le fait de devoir couvrir tous les chemins possibles entre la définition D et l utilisation U, en se limitant aux chemins passant 0 ou 1 fois dans chaque boucle. Le terme DU-chemins correspond donc à un chemin reliant une Définition à une Utilisation. La figure 1.7 décrit la hiérarchie des différents critères de couverture de graphe de flot de contrôle et de flux de données. Les tests structurels permettent, moyennant un effort de tests plus ou moins important, de parcourir le code d un programme. Ils permettent de vérifier l exactitude du code dans son exécution et détectent des erreurs d implémentation. En revanche, ces tests ne permettent pas d établir que le code fourni est conforme aux besoins exprimés. Ils valident que le code s exécute mais ne vérifient pas que le logiciel répond aux attentes. Cependant, dans la pratique, il est souvent très difficile d exécuter l ensemble des tests requis pour valider la totalité du code, d autant plus si le logiciel testé est de taille importante. 45

60 Chapitre 1. Etat de l art et contexte tous-les-chemins tous-les-du-chemins toutes-les-utilisations tous-les-i-chemins toutes-les-définitions tous-les-arcs plus fort tous-les-noeuds plus faible Figure 1.7 Hiérarchie des critères de couverture Les métriques de tests structurels Nous détaillons ici les métriques implémentées dans les outils de tests les plus généralement utilisés pour évaluer la couverture des tests (couverture du graphe de flot de contrôle). Ces outils, tels que Sonar ou Cobertura, valident essentiellement trois types de couverture, à savoir, les instructions, les branches et les chemins : Couverture des instructions. Cette métrique calcule le nombre d instructions couvertes par les tests. Elle valide le cas de couverture toutes-les-instructions. Une instruction peut, par exemple, être un test if. Dans ce cas, l instruction sera dite couverte si le test passe par une de ses deux branches. Couvrir toutes les instructions est utile pour rechercher du code cassé ou du code inutile, mais ne permet pas de déterminer si les résultats obtenus sont conformes aux attentes dans tous les cas possibles. Cette mesure est facile à calculer, mais ne prend pas en compte tous les chemins d exécution déterminés par les structures de contrôle. Dans la figure 1.8, la couverture des instructions est de 100 % parce que toutes les déclarations sont couvertes, mais 46

61 1.3. Les techniques de tests Instructions Instructions Vrai instruction de décision Vrai instruction de décision Instructions Faux Instructions Faux Vrai instruction de décision Vrai instruction de décision Instructions Faux Instructions Faux Vrai instruction de décision Vrai instruction de décision Instructions Faux Instructions Faux Instructions Instructions Figure 1.8 Chemins vérifiés avec un taux de couverture de lignes de code à 100%. il reste encore trois chemins qui ne sont pas couverts : les chemins correspondant aux cas faux. Il n y a donc aucune garantie de qualité, même si la couverture est de 100 %. Couverture de branches ou couverture de décision. Cette métrique détermine si les tests couvrent les branches issues des conditions. Elle valide le cas de couverture tous-les-arcs. Par exemple, un if introduit deux branches et les tests doivent donc couvrir ces deux cas : vrai et faux. Dans la figure 1.9, les trois structures de contrôle introduisent six branches et les tests doivent donc valider six cas : vrai et faux pour chaque structure de contrôle. Donc, si les tests couvrent d abord les trois branches vrai, puis les trois branches faux, la couverture de branches est de 100 %, mais ne prend pourtant pas en compte tous les chemins possibles dans le système : qu en est-il du cas vrai, vrai et faux par exemple? Couverture de chemins. Cette métrique détermine si les tests couvrent tous les chemins possibles dans un système. Elle valide le cas de couverture tous-les-chemins-linéairement-indépendants. En raison du nombre de chemins possibles qui peut être très élevé (pour N conditions il existe 2 N chemins possibles) ou illimité (si le programme contient une boucle infinie), cette mesure va de pair avec la complexité cyclomatique. Le nombre de chemins à couvrir augmente linéairement avec la complexité cyclomatique, et non pas de façon exponentielle. Dans la figure 1.10, il y a trois conditions donc 2 3 = 8 chemins possibles, mais seulement quatre chemins pour couvrir la complexité cyclomatique : Un ensemble de chemins pourrait être : vrai-vrai-vrai, faux-vrai-vrai, vrai-faux-vrai, vrai-vrai-faux. Les autres voies ne sont pas des chemins indépendants de sorte qu ils sont ignorés. 47

62 Chapitre 1. Etat de l art et contexte Instructions Instructions Instructions Vrai instruction de Vrai instruction de décision Vrai instruction de décision décision Instructions Faux Instructions Faux Instructions Faux Vrai instruction de Vrai instruction de décision Vrai instruction de décision décision Instructions Faux Instructions Faux Instructions Faux Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision Instructions Faux Instructions Faux Instructions Faux Instructions Instructions Instructions Test 1 Test 2 Figure 1.9 Chemins vérifiés avec un taux de couverture de branches à 100%. Instructions Instructions Instructions Instructions Instructions Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision Instructions Faux Instructions Faux Instructions Faux Instructions Faux Instructions Faux Vrai instruction de Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision décision Faux Instructions Faux Instructions Faux Instructions Faux Instructions Faux Instructions Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision Vrai instruction de décision Instructions Faux Instructions Faux Instructions Faux Instructions Faux Instructions Faux Instructions Instructions Instructions Instructions Instructions Test 1 Test 2 Test 3 Test 4 Figure 1.10 Chemins vérifiés avec un taux de couvertures de chemins à 100%. 48

63 1.3. Les techniques de tests Ces métriques déterminent le niveau de tests par rapport à un type de couverture du code mais pas la qualité des tests par eux-mêmes. Ils ne permettent pas de savoir si les tests sont correctement définis. De plus, même une couverture de code proche de 100 % ne permet pas d exclure la possibilité de bogues résiduels. Ces métriques à elles seules ne permettent donc pas de d évaluer en totalité la qualité des tests structurels. Il faut également évaluer d autres paramètres tels que le taux de réussite des tests, ou encore la qualité de la formalisation des tests. Il est donc nécessaire de disposer d indicateurs supplémentaires tels que : le pourcentage de tests en échec, la fréquence de tests, les modifications des tests en fonction du cycle de vie de l application. Certains de ces indicateurs sont des métriques (pourcentage d échec) tandis que d autres reposent sur des données brutes qu il faudra alors évaluer d un point de vue qualité : donner un sens à l information en fonction d une règle de qualité. De plus, les tests structurels ne suffisent pas à déterminer la qualité d un logiciel. Ils permettent de se faire une opinion par rapport à la fiabilité d exécution du code source mais ne permettent pas de vérifier que le logiciel est en adéquation avec les exigences définies au départ (les besoins exprimés). Pour le valider, on fait appel à un autre type de tests : les tests fonctionnels Tests fonctionnels Les techniques de tests en boîte noire ou black-box analysent le comportement du logiciel d un point de vue fonctionnel. Il s agit de déterminer si le logiciel fait ce pour quoi il est prévu, s il répond aux attentes du client. Le test fonctionnel repose sur une sélection de cas de tests déterminés à partir des spécifications fonctionnelles du logiciel. Les cas de tests sont écrits par un technicien, à partir de son analyse des spécifications qui sont écrites en langage naturel. Les tests résultant de ces cas de tests peuvent être soit manuels, i.e., exécutés par un technicien, soit automatiques, i.e., exécutés à partir de scripts. La qualité de ces tests est donc directement liée à la qualité de la description des besoins fonctionnels et à l analyse minutieuse de ceux-ci. Les spécifications doivent donc tout d abord être correctement établies, i.e., définies et identifiées avec précision. Il est souhaitable de déterminer pour chacune : le domaine d application de la fonctionnalité, les cas minimaux ; les tests dans le domaine, les tests portant sur des valeurs comprises dans le domaine. On détermine si l application exécute correctement la fonctionnalité ; les tests aux limites du domaine, les tests portant sur les valeurs des extrémités du domaine. On détermine si l application répond correctement pour les valeurs seuil ; les tests hors limites, les tests portant sur des valeurs choisies hors des limites du domaine. On détermine si l application récupère et traite correctement les erreurs. Pour déterminer si le test est une réussite ou un échec, le testeur utilise un oracle. Il permet de déterminer le comportement attendu du logiciel. Il contient les résultats attendus en fonction des entrées insérées dans le module testé. Un oracle doit donc être le plus précis possible. Métriques de tests fonctionnels. Evaluer la qualité des tests fonctionnels repose à la fois sur des métriques et sur des données brutes. En effet, si on peut déterminer facilement le taux de réussite des tests fonctionnels grâce à une métrique (un pourcentage), par exemple, il n est pas possible d utiliser de métriques pour 49

64 Chapitre 1. Etat de l art et contexte déterminer la qualité de rédaction des tests, ou encore la qualité de la définition des exigences (les besoins que doit satisfaire le logiciel). Pour parvenir à évaluer totalement la qualité de la validation fonctionnelle d un logiciel il faudra donc prendre en compte : les métriques de taux de réussite des tests, de couverture (des tests, des exigences, des données de tests) ; les données brutes concernant les méthodes de formalisation des tests, le cycle de vie des tests, le suivi des tests, l organisation des campagnes de tests, la rédaction des cas de tests, l expression des besoins de tests Conclusion Les tests sont déterminants pour s assurer de la qualité d un système. Les tests en boîte blanche permettent de déterminer si le code s exécute correctement tandis que les tests en boîte noire permettent de vérifier que le logiciel répond aux attentes. Bien qu il existe des métriques permettant de vérifier le taux de couverture des tests ou encore leur taux de réussite, il faut également analyser de nombreuses données brutes qui ne relèvent pas de métriques pour obtenir une vue d ensemble de la qualité de la validation fonctionnelle. Il faut non seulement interpréter d un point de vue qualité ce que signifie la couverture des tests mais aussi analyser les descriptions des spécifications, le suivi de tests, le suivi des corrections d erreurs, l organisation et la gestion des tests, entre autre. Evaluer la qualité des tests passe donc par une analyse fine de l intégralité du processus mis en place dans les phases de tests de l application. 1.4 Conclusion La norme SQuaRE donne un schéma général en quatre étapes de l évaluation de la qualité logicielle : définir les exigences, établir un modèle de qualité, définir les métriques de la qualité et évaluer la qualité. Il faut donc d abord définir clairement les exigences en matière de qualité avant de construire un modèle qui les évaluera. Il faut ensuite inventorier les métriques les plus à même d être des indicateurs de qualité pertinents. Une fois ces métriques identifiées, il faut pouvoir interpréter les valeurs obtenues d un point de vue qualité : évaluer les résultats des métriques sous l angle de la qualité comme le précise Plante. La plupart des modèles de qualité existants définissent les principes de qualité sous forme de facteurs ou de caractéristiques qu elles évaluent ensuite par des métriques. Cependant, nous avons constaté que le passage entre les métriques et les règles de qualité constitue le point le plus délicat à mettre en œuvre dans un modèle de qualité. De plus, un des buts de l évaluation de la qualité consiste aussi à permettre d améliorer celle-ci. Or, il n est pas toujours aisé de concevoir un modèle qui mette clairement en avant les composants logiciels à améliorer. Les modèles sont soit de haut niveau ils offrent une vue globale de la qualité mais ne permettent pas de faire le lien direct avec les composants défectueux, tels que les normes ou le modèle de McCall, ou alors ils mettent en évidence les composants qui posent problème mais ne fournissent pas une vue générale et synthétique de la qualité tels que les outils comme Sonar. 50

65 1.4. Conclusion De plus, il existe de nombreuses métriques logicielles qui fournissent des mesures abordant différents domaines conceptuels (le design du code par exemple, ou encore la complexité, ou la couverture des tests). Toutes ces métriques ont leur importance dans leur domaine respectif et il faut souvent utiliser plusieurs métriques différentes pour évaluer une règle de qualité, comme le font les modèles de qualité existants. De plus, ces métriques ne possèdent pas toutes les mêmes échelles de valeur, d ou la difficulté de les utiliser ensemble. Il faut également parvenir à passer du niveau détaillé dans lequel se situe généralement une métrique donnée (un nombre de lignes de code pour une méthode par exemple) au niveau général de qualité dans lequel s exprime une règle (la qualité générale d un programme en terme de longueur de ses composants) en essayant de transposer les indications collectées au niveau le plus bas en indication pertinente au niveau le plus haut, tout en conservant le maximum d informations. Ceci n est pas toujours effectué avec succès, comme par exemple lors de l utilisation de normes de qualité qui permettent d obtenir une image de la qualité globale d une application mais ne parviennent pas à relier cette information avec les composants qui doivent être améliorés. Mesurer la qualité repose également sur la collecte de données brutes qui ne sont pas fournies par des métriques. Par exemple, mesurer le nombre de lignes de commentaires d un programme ne permet pas de déterminer si les commentaires sont pertinents par exemple. Il faut donc s appuyer à la fois sur des métriques mais également sur des données non numériques pour parvenir à évaluer précisément la qualité d une application, ce qui par exemple dans le cas d un outil comme Sonar n est pas inclus dans le champ des évaluations. A partir de ces constatations, nous avons donc cherché à concevoir un modèle de qualité qui soit global, qui indique de manière précise comment utiliser les métriques pour évaluer la qualité et qui soit adaptable à tous types de logiciel. Nous avons donc défini d une part ce que doit être un modèle de qualité : quelles propriétés voulons-nous qu il satisfasse? Et d autre part, nous avons déterminé une nouvelle façon d agréger les mesures dans l idée de conserver les informations fournies par celles-ci. De plus, nous avons cherché à concevoir un modèle qui puisse fournir une vue qualitative intéressant tout à la fois le responsable (manager ou chef de projet par exemple) et le technicien (développeur ou testeur par exemple). 51

66 Chapitre 1. Etat de l art et contexte 52

67 Chapitre 2 Le modèle Squale Sommaire 2.1 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 Dans ce chapitre nous présentons le modèle Squale. Celui-ci est issu d un travail entre l entreprise Qualixo et Air France-KLM. Suite à un besoin d évaluer la qualité de leur code source, ces derniers n avaient pas trouvé d outils satisfaisant pleinement leurs exigences, à savoir, un modèle capable de fournir à la fois une vue détaillée de la qualité du code source mais aussi une vue globale utilisable par les décideurs de l entreprise pour déterminer la qualité générale d une application. Ils ont donc élaboré le modèle Squale de manière empirique en se fondant sur leur savoir-faire métier. Le modèle Squale a fait ensuite l objet d un premier projet de recherche, d une durée de deux ans, soutenu et labélisé par le pôle de compétitivité Systematic - PARIS Région, groupe thématique logiciels libres. Il s agissait d un projet FUI (Projet R&D du fond Unique Interministériel) également financé en partie par la région Île-de-France et la Direction Générale des Entreprises. Ce projet, porté par l entreprise Qualixo, avait pour partenaires les entreprises Paqtigo, Air France-KLM et PSA Peugeot-Citroën et les équipes de recherche de l Inria RMod de Lille et de laboratoire LIASD de l université Paris 8. Il a eu pour objectif de formaliser et de valider le modèle Squale, puis de développer les outils open-source associés, de fournir des tableaux de bord synthétiques de la qualité logiciel, de déterminer l évolution de la qualité dans le temps et de fournir des indicateurs économiques de rentabilité de la mesure de la qualité. Le projet a permis de définir en partenariat avec 53

68 Chapitre 2. Le modèle Squale l équipe Inria RMod et le laboratoire LIASD de l université Paris 8 une première version formelle du modèle : le modèle Squale. Ce modèle repose sur les exigences et les compétences techniques des partenaires industriels du projet : Air France-KLM et PSA Peugeot-Citroën. A l issu du projet, le modèle a été décliné en deux instances utilisées au sein des entreprises Air France-KLM et PSA Peugeot-Citroën. Les laboratoires RMod et le LIASD ont formalisé le modèle issu des travaux empiriques de Qualixo et Air France-KLM, ils ont recensé les métriques de code utiles au projet et travaillé à l élaboration d un premier plan de remédiation fondé sur le modèle Squale. Nous avons été personnellement chargé chargé plus spécifiquement de valider une partie des métriques de code, de formaliser le modèle et de valider les formules d agrégation de métriques. Ce projet de recherche a été présenté dans [Bergel et al., 2009]. A partir des travaux et brainstorming du projet Squale, nous avons élaboré les travaux présentés dans les chapitres 3, 4, 5 et Présentation générale de Squale Le modèle Squale est hiérarchique, il s inspire des mêmes principes que le modèle facteurs-critèresmétriques de McCall détaillé dans la section et la norme ISO 9126 décrite dans la section La norme ISO 9126 se définit tout d abord par six caractéristiques principales détaillées ensuite par des sous-caractéristiques tout comme le modèle de McCall se définit tout d abord par ses facteurs puis les critères qui les composent. Ils s appuient sur des métriques qui servent à évaluer la qualité des critères (ou sous-caractéristiques). La principale lacune des modèles hiérarchiques classiques se situe dans la manière d évaluer les principes de qualité. En effet, bien que décrits précisément, aucune indication n est donnée quant à la manière de mesurer ces principes. Les métriques définies dans ces modèles sont trop peu précises ou trop nombreuses pour être utilisées de manière efficace. Le modèle Squale se propose donc de palier à ce problème. Il introduit un niveau supplémentaire entre les métriques et les critères : les pratiques. Ce niveau situé au dessus des métriques permet d agréger les données brutes sous forme de règles à respecter ou à éviter pour développer une application de qualité. Ce niveau a été défini pour préciser comment doivent être évalués les grands principes qualitatifs et pour permettre de retrouver facilement les points forts et les points faibles du logiciel évalué. De même, les modèles de qualité classiques ne précisent pas comment faire pour évaluer la qualité en partant de métriques brutes. Comment agréger des métriques pour leur donner un sens général, comment ne pas perdre les indications contenues dans chacune des métriques. Squale se propose donc d utiliser des formules d agrégation qui lui sont propres, pour parvenir à résoudre ce problème. Les pratiques qui sont le coeur des calculs effectués dans Squale ont été définies de manière à conserver les informations fournies par les métriques, dans le but de mettre en avant les faiblesses éventuelles du logiciel, de manière précise. 2.2 Squale : un modèle hiérarchique en quatre couches Le modèle Squale est composé de quatre couches : mesures, pratiques, critères et facteurs répartis en deux niveaux différents : 54

69 2.2. Squale : un modèle hiérarchique en quatre couches une partie de haut-niveau composée des facteurs et critères : un facteur représente le plus haut niveau du modèle. Il représente un élément constitutif de la qualité dans son ensemble et spécifie un domaine d exigences. L ensemble des facteurs fournit une vue globale de la qualité ; un critère représente un principe conceptuel de qualité. Il précise le facteur dans lequel il est défini et fournit le détail des principes généraux de qualité que sont les facteurs ; une partie de bas niveau composée des pratiques et mesures : une pratique représente un principe technique de qualité. Les pratiques s expriment en termes de bonnes ou mauvaises méthodes (de programmation, de tests, etc.) et fournissent un guide à suivre pour développer une application qui respecte les critères de qualité définis pour ce projet. Les pratiques permettent donc de déterminer clairement les règles de qualité importantes pour l entreprise et de définir sans ambiguité les critères et facteurs qui composent les couches supérieures du modèle ; une mesure est une donnée brute collectée à partir de métriques ou de documents attachés au projet. Ces mesures sont utilisées pour déterminer la qualité du projet et mesurer les règles définies par les pratiques. Ces deux niveaux marquent la différence entre les couches supérieures qui définissent des règles qualitatives générales et formelles et les couches inférieures qui définissent les règles qualitatives propres au système étudié. Ainsi, le modèle Squale se propose d offrir plusieurs grilles de lecture différentes de la qualité dans l optique de s adresser à la fois aux techniciens et aux managers. Le haut niveau, théorique et abstrait, classe des principes qualitatifs applicables et définis quel que soit le système étudié. Il repose d ailleurs sur les définitions des modèles de McCall et de la norme ISO Il s agit de principes de qualité formels s adressant principalement aux managers. Le bas niveau en revanche définit non plus des principes formels mais des manières de mesurer ces principes de haut niveau. Il s agit d un niveau concret, qui repose sur les exigences et les attentes propres au logiciel étudié (son langage, son domaine d application, les exigences clients). Ce niveau utilise à la fois les exigences attendues par le client mais également le savoir-faire lié au domaine du logiciel mesuré. Il s adresse aux techniciens : développeurs ou testeurs par exemple. S appuyant sur les sources du logiciel aussi bien que sur les documents qui lui sont rattachés, Squale collecte des informations des mesures pour les transformer en notes facilement interprétables. Le processus de transformation est schématisé par la Figure 2.1. La couche inférieure du modèle contient des mesures brutes qui peuvent prendre n importe quelle valeur : un nombre de lignes de code ou encore un taux de couverture de tests ou la qualité du cahier des charges, par exemple. Les couches supérieures pratiques, critères et facteurs utilisent un intervalle de notation commun, comme le préconise la norme ISO 9126 [ISO/IEC, 2001]. Cette dernière précise que l échelle de mesures associée aux métriques utilisées pour évaluer les exigences qualité peut être divisée en différentes catégories, par exemple, deux catégories satisfaisant ou non ou encore quatre catégories dépasse les exigences, atteint sa cible, acceptable a minima, non acceptable. Ainsi, pour faciliter l interprétation d une note donnée et permettre une comparaison plus aisée, Squale est composé de notes comprises dans l intervalle continu [0; 3], qui se comprend selon l échelle de valeurs suivante : entre 0 et 1, le but n est pas atteint ; 55

70 Chapitre 2. Le modèle Squale Vue Manager Facteurs Note dans [0;3] Critères Notes dans [0;3] H a u t - n i v e a u Vue technicien Notes globales dans [0;3] Pratiques Notes individuelles dans [0;3] Mesures mesures B a s - n i v e a u Métriques Analyse d'experts Résultats techniques Figure 2.1 La pyramide du modèle Squale. entre 1 et 2, le minimum est atteint mais avec des réserves ; entre 2 et 3, le but est atteint. Le modèle Squale est donc composé au bas de la pyramide de mesures brutes qui livrent une valeur dans leur propre échelle de mesures tandis que les critères et les facteurs sont toujours notés dans l intervalle [0; 3]. L étape de transformation des données brutes de bas niveau en notes de haut niveau s effectue au niveau des pratiques. Elles constituent donc le point central du modèle Squale. La transformation des mesures est effectuée selon des règles de calcul qui dépendent du type de mesures effectuées. Nous expliquons en détail le principe de fonctionnement de cette transformation dans la section 2.3. La figure 2.2 montre comment sont répartis les facteurs, critères et pratiques du modèle Squale. Les sections suivantes décrivent précisément cette architecture et les quatre couches du modèle, depuis le niveau inférieur des mesures jusqu au niveau le plus élevé des facteurs ainsi que le principe de notation du modèle Les mesures Une mesure est une information brute collectée au cours de l analyse du projet évalué. Ce niveau représente le plus bas niveau du modèle. Il est composé de mesures brutes qui reposent sur l ensemble des documents qui constituent une application : code source, documentation, cahier des charges, rapport de tests, rapports d audit, par exemple. On distingue deux types principaux de mesures pour évaluer la qualité d un logiciel : les métriques automatiques calculées facilement et aussi souvent que nécessaire et les données brutes qui proviennent d experts. On attribue une longévité aux notes reposant sur les données brutes qui ne 56

71 2.2. Squale : un modèle hiérarchique en quatre couches Simplicité Taille de méthodes Nombre de méthodes Code spaghetti Capacité de réutilisation Sécurité Conformité implémentation/ définition sécurité Dossier technique : sécurité Dossier fonctionnel : sécurité Normes et standard : sécurité Capacité d'intégration Couplage efferent Couplage afferent Maintenabilité Tests techniques Tests fonctionnels de non régression Couverture des tests d'intégration Couvertures tes tests unitaires Tests unitaires Compréhension Exploitabilité Homogénéité Modélisation Aptitude à la tâche Profondeur d'héritage Dossier de production Normes et standard : règles de nommage Raisonnement pas les modèles Spécifications fonctionnelles Normes et standard : documentation Normes et standard : traçage Normes et standard : programmation Conformité entre modélisation et implémentation Normes d'ergonomie Qualité de la documentation Normes et standard : portabilité Normes et standard : mise en forme Prédétection d'antipattern Plan d'assurance qualité Spécialisation de la classe Diagramme de modélisation Taux de commentaires Fiabilité Capacité d'évolution Capacité fonctionnelle Architecture Pertinence de l'architecture Stabilité Gestion des exceptions Modularité Dossier design technique : sécurité Choix des technologies Tests de charge Normes et standard : traçage Couplage afferent Cohésion de classe Couteau suisse Respect de l'architecture Respect de l'architecture en couches Choix des mécanismes Organisation générale du code Tests de robustesse Copier coller Correspondance entre couches et nommage Dossier d'architecture technique Figure 2.2 Une vue du modèle Squale. Tests d'acceptation Tests de non régression fonctionnels Tests aux limites Couverture des tests d'acceptation Analyse des risques Tests automatiques d'acceptation Scénarios des tests d'acceptation Modularité de l'architecture Dépendance cyclique Découpage en couches Niveau d'abstraction et de stabilité 57

72 Chapitre 2. Le modèle Squale sont re-évaluées que lors de changements majeurs. Ceci permet de déterminer un indice de confiance dans la note. Les mesures se décomposent en quatre grands groupes : les métriques de code telles que le nombre de lignes de code, la profondeur d héritage ou la complexité cyclomatique, regroupent les métriques qui évaluent le code source d un logiciel. Ces métriques ont été sélectionnées pour ne garder que les plus pertinentes correspondant aux besoins de l entreprise. Elles dépendent étroitement du langage de programmation utilisé : la profondeur d héritage par exemple ne sera calculée que pour un langage objet. Ces métriques ont été décrites dans la section 1.2 et ont fait l objet d une étude détaillée au cours du projet de recherche [Balmas et al., 2009] ; les conventions de codage (rules checking) telles que les règles de programmation, les règles syntaxiques, regroupent les vérifications effectuées sur les noms et les conventions de programmation liés au code source. Il s agit des règles mises en place par l entreprise pour définir les standards d écriture et de programmation ayant cours chez elle. Là encore ces métriques sont directement issues des exigences et du savoir-faire mis en place dans l entreprise ; les métriques de tests telles que les taux de couverture, qui regroupent les métriques évaluant les tests effectués sur l application. Elles permettent de savoir si l application est testée correctement et si les couvertures de tests sont correctes ; les données brutes qui correspondent aux audits effectués par des experts ou aux appréciations fournies directement par une personne. Ces mesures qualifient la documentation, le cahier des charges ou tout autre document nécessaire à la conception de l application. Ces mesures englobent également la vérification du respect des contraintes définies au préalable : respect du cahier des charges par exemple. Chaque mesure métrique, conventions de nommage ou donnée brute est affectée à l entité qu elle mesure, i.e., la classe pour la profondeur d héritage ou le projet pour la qualité du cahier des charges par exemple. Cette affectation déterminera ensuite le niveau auquel se calculent les notes des pratiques. La figure 2.3 liste les mesures définies pour l instance du modèle Squale telle que mise en œuvre chez Air France-KLM, réparties selon les quatre groupes cités précédemment. Actuellement, l instance du modèle Squale mise en place chez Air France-KLM dispose de 37 mesures. Les métriques possèdent des valeurs brutes qui varient selon leur propre échelle de notation. La mesure SLOC qui détermine le nombre de lignes de code possède en général une valeur n excédant par 1000 tandis que la mesure NOM qui détermine le nombre de méthodes a une valeur inférieure à 100 en pratique, alors que la valeur de la métrique instabilité est toujours comprise entre 0 et 1. En revanche, les données brutes n ont pas de valeur numérique : il s agit de documents (par exemple le cahier des charges ou le dossier de conception technique) qui devront être analysés par un expert. Celui-ci n attribue pas de note à proprement parlé au document analysé mais utilise un ensemble de documents pour évaluer une pratique donnée. Dans le cas de rapport d audit, les documents ont été préalablement évalués par un expert qui a utilisé son propre système d évaluation des documents au sein de son rapport. Il faudra alors, à partir du rapport d audit attribuer une note à la pratique. 58

73 2.2. Squale : un modèle hiérarchique en quatre couches métriques de code conventions de codage métriques de tests Données brutes métriques orientées objet métriques primitives RCF NOM DIT métriques conventionnelles CLOC V(G) ev(g) SLOC Normes et standard : erreurs Normes et standard : warning Normes et standard : info Taux de couverture de branches Taux de couvertures TU Taux de couverture de code cahier des charges PAQ scénarios de recette fonctionnelle SIX CLOC dossier d'architecture technique NRM WMC documentation métriques de design dossier de production LCOM cycles normes d'ergonomie métriques de packages scénarios des risques fonctionnels Ce Ca dossier de conception technique Instabilité technologies Distance design pattern dossier de spécifications technqiues gestion des exceptions organisation générale du code dossier d'architecture générale Tests fonctionnels Figure 2.3 Les mesures du modèle Squale, classées en quatre groupes Les pratiques Une pratique s assure du respect d un principe technique issu du savoir-faire métier des développeurs, comme par exemple, les classes complexes doivent être plus commentées que les triviales ou encore issu d exigences fonctionnelles, comme par exemple l évaluation de la qualité du cahier des charges. Elle s adresse directement au technicien en terme de bonne ou de mauvaise règle de programmation en respect avec la définition de la qualité attendue sur le projet. Les bonnes techniques de conception doivent être suivies et renforcées tandis que les mauvaises doivent être repérées et évitées. L ensemble des pratiques définies sur un projet donné représente l ensemble des principes de qualité à respecter pour obtenir la qualité optimale visée sur le projet analysé. Ces règles et principes de qualité sont définies selon un point de vue technique en mode boîte blanche. 59

74 Chapitre 2. Le modèle Squale Pratiques de code taille de méthodes nombre de méthodes code Spaghetti Profondeur d'héritage couplage efferent couplage afferent couteau suisse copier coller cohésion de classe taux de commentaires dépendance cyclique niveau d'abstraction et de stabilité spécialisation de la classe Pratiques de modèles diagramme de modélisation conformité entre modélisation et implémentation prédétection d'antipatterns Raisonnement par les modèles Pratiques de normes et standards normes et standards : documentation normes et standards : programmation normes et standards : règles de nommage Normes et standard : traçage normes et standards : mise en forme normes et standards : gestion de configuration Normes et standard : portabilité Normes et standard : sécurité respect de l'architecture en couches Pratiques documentaires qualité de la documentation choix des technologies design-pattern organisation générale du code dossier d'architecture technique correspondance entre couches et nommage découpage en couches dossier de production Gestion des exceptions analyse des risques Scénario de tests d'acceptation conformité implémentation/définition sécurité Dossier technique : sécurité Pratiques de tests Tests de non régression fonctionnels Tests aux limites taux de couverture des scénarios de tests fonctionnels Tests automatiques fonctionnels taux de couverture des tests d'intégration Taux de couvertures des tests unitaires Tests unitaires Tests de robustesse tests de charge Dossier fonctionnel : sécurité Dossier design technique : sécurité Tests de performance Plan d'assurance qualité Normes d'ergonomie Spécifications fonctionnelles Figure 2.4 Les pratiques du modèle Squale. Tout comme les mesures, les pratiques sont regroupées en différentes catégories selon les principes techniques qu elles décrivent. La figure 2.4 représente les pratiques répertoriées dans ces différentes catégories. Chaque pratique décrit une règle unitaire du domaine dans lequel elle se situe : les pratiques de code décrivent les règles et les principes de programmation à suivre ou à éviter pour obtenir un code de qualité. Ces règles dépendent du langage de programmation utilisé et du type de logiciel développé. Ces pratiques utilisent les métriques de code issues du code source du projet. Ces métriques sont combinées entre elles et/ou comparées à des seuils afin d obtenir les notes de la pratique. Ces pratiques s adressent directement aux développeurs ; les pratiques de tests décrivent les règles et les principes à suivre pour obtenir des tests de qualité sur l application. Ils comprennent les tests structurels mais également les tests fonctionnels. Ces pratiques utilisent les métriques et données issues des tests. Elles s adressent aux développeurs ainsi qu aux techniciens de tests ; les pratiques de modèles décrivent les règles et les principes techniques à respecter pour obtenir une modélisation du projet de qualité. Ces pratiques dépendent du type de modélisation utilisé modèles UML par exemple et du type de l application. Les pratiques sont mesurées à partir des métriques de modélisation mais également à partir de métriques identiques à celles des métriques de code mais calculées sur le modèle et non plus sur le code source : le nombre de méthodes ou le nombre de classes par exemple. Ces pratiques s adressent aux concepteurs du modèle ; 60

75 2.2. Squale : un modèle hiérarchique en quatre couches les pratiques documentaires décrivent l existence et la qualité des documents annexes au logiciel. Par exemple, la qualité de la documentation, ou encore la qualité du cahier des charges. Ces pratiques sont notées directement par une personne habilitée tel qu un expert lors d un audit. Plus généralement, toute pratique dont la note n est pas automatisable est dite pratique documentaire. Ces pratiques s adressent plus généralement aux chefs d équipes (équipes de tests, de développement, etc.) ; les pratiques de normes et standards décrivent les règles et les principes de codage mis en place dans l entreprise : règles de nommage, syntaxe du code, architecture, commentaires du code, etc. Ces pratiques décrivent toutes les règles mises en place par l entreprise. Elles sont donc directement reliées aux exigences de celle-ci. Les notes des pratiques sont calculées à partir des métriques de convention de développement. Ces pratiques s adressent directement aux développeurs. Environ 55 pratiques sont actuellement définies dans le modèle Squale et ont fait l objet d une étude détaillée dans le cadre du projet de recherche [Balmas et al., 2010]. Cependant, la liste doit être établie en fonction des attentes des entreprises et des projets, au début de l étude. Elle n est donc pas fermée et peut être étendue selon les cas étudiés Les critères Un critère qualifie un principe de qualité d une application (sécurité, simplicité, ou modularité par exemple). Il s adresse aux managers et propose une vue détaillée de la qualité du logiciel, sans toutefois être technique. Les critères représentent un point de vue technique en mode boîte noire. Un critère agrège un certain nombre de pratiques. La note d un critère correspond à une moyenne simple des pratiques qui la composent. Les critères actuellement définis dans le modèle Squale se fondent sur les sous-caractéristiques définies dans la norme ISO Ils ont toutefois été adaptés aux exigences des entreprises travaillant sur le projet de recherche, les entreprises Air France-KLM et PSA Peugeot-Citroën. Actuellement, le modèle Squale est composé de quinze critères, répartis comme le montre la figure 2.5 et définis comme suit : simplicité qualifie la lisibilité et la facilité de diagnostic du code source, hors documentation technique ; capacité d intégration qualifie le niveau de dépendance des éléments les uns envers les autres ; compréhension qualifie la facilité pour un développeur à comprendre rapidement la logique générale du code source du projet ; exploitabilité qualifie le niveau d exploitabilité de l application en termes de documentation et de respect des procédures de mise en production et de suivi de production ; homogénéité qualifie le niveau d homogénéité du codage au sein du projet à savoir, le respect des normes de programmation, les conventions de nommage, la mise en forme ; modélisation qualifie la qualité de modélisation du projet et la conformité entre les modèles et le code implémenté ; aptitude à la tâche qualifie la capacité d un système à réaliser un produit satisfaisant les exigences ; 61

76 Chapitre 2. Le modèle Squale tests d acceptation ou recette fonctionnelle. Qualifie les scénarios de recette et les résultats des tests fonctionnels ; sécurité qualifie le niveau de sécurité de l application ; tests techniques qualifie le processus de tests structurels ; stabilité qualifie l aptitude d une application à faire face aux défaillances potentielles ; modularité qualifie la composition d une application en éléments de taille limitée ; respect de l architecture vérifie le niveau de conformité de l architecture par rapport à ce qui a été défini au préalable ; pertinence de l architecture qualifie les choix architecturaux et leur pertinence par rapport à l état de l art dans le domaine et les technologies choisies ; modularité de l architecture qualifie la pertinence de l architecture pour obtenir un découpage adéquat des composants dans des perspectives d évolution et de réutilisation ; Maintenabilité Simplicité Capacité d'intégration Compréhension Homogénéité Capacité de réutilisation Compréhension Capacité d'intégration Exploitabilité Tests techniques Capacité d'évolution Compréhension Homogénéité Modularité Modélisation Fiabilité Stabilité Tests techniques Sécurité Simplicité Capacité fonctionnelles Modélisation Aptitude à la tâche Tests fonctionnels Architecture Modularité de l'architecture Pertinence de l'architecture Respect de l'architecture Figure 2.5 Les critères du modèle Squale. Ces critères sont définis de manière générique. Ils sont toutefois adaptables en fonction du type de logiciel analysé mais également en fonction des exigences de l entreprise, par l intermédiaire de la personnalisation des pratiques qui les composent et les définissent. Par exemple, une instance du modèle Squale appliquée chez Air France-KLM définit le critère Simplicité avec les pratiques suivantes : Nombres de méthodes ; Code spaghetti ; Taille des méthodes ; qui signifie que la Simplicité d un code source d un logiciel écrit en langage objet est évalué en fonction du nombre de méthodes et de la taille des méthodes des classes qui le composent, ainsi que de la structure de ses méthodes (code spaghetti) : un code simple doit avoir un nombre de méthodes par classes raisonnable, des méthodes de taille pas trop élevée pour faciliter la compréhension mais également des méthodes écrites de manière structurée Les facteurs Un facteur représente le niveau le plus élevé du modèle de qualité. Chaque facteur donne une vue globale de la qualité du projet pour un secteur précis (architecture ou fiabilité par exemple). Les facteurs agrègent les critères. La note d un facteur correspond à la moyenne simple des notes des critères qu il agrège. Les six facteurs du modèle Squale reposent sur les définitions des facteurs de la norme ISO 9126 et ont été adaptés aux exigences de Air France-KLM et PSA Peugeot-Citroën. Ils sont définis ainsi : 62

77 2.3. Le calcul des notes de Squale capacité fonctionnelle représente l adéquation des fonctionnalités offertes par l application avec les besoins implicites ou explicites exprimés par la maîtrise d ouvrage ; architecture représente le niveau de qualité de l architecture technique du projet ; fiabilité mesure l aptitude du logiciel à maintenir son niveau de service et de stabilité dans des conditions précises et pendant une période déterminée ; maintenabilité mesure l aptitude d un logiciel à faciliter la localisation et la correction d erreurs résiduelles. Il s agit bien là de correction de défauts de non-conformité par rapport aux spécifications et non de défauts provenant d une mauvaise expression des besoins ; capacité d évolution mesure l aptitude d un logiciel à faciliter l adjonction de nouvelles fonctionnalités. Il est complémentaire au facteur maintenabilité, car ici, on ne situe plus à périmètre fonctionnel constant ; capacité de réutilisation mesure la facilité de réutilisation de tout ou partie du logiciel sur un autre projet, quel que soit l environnement technique et fonctionnel cible. 2.3 Le calcul des notes de Squale Dans cette partie, nous présentons comment le modèle Squale évalue les différents principes de qualité qu il définit à partir des mesures qu il collecte et comment le modèle calcule les notes de haut niveau. Les calculs sont effectués au niveau des pratiques, de différentes manière selon le type de mesures collectées. Dans cette section nous détaillons ces différents calculs en fonction de la répartition des pratiques : les pratiques de code ; les pratiques de normes et standard ; les pratiques documentaires ; les pratiques de modèles ; les pratiques de tests Les pratiques de code Ces pratiques reposent sur des mesures issues de métriques de code. L ensemble des pratiques de code définies pour une instance du modèle Squale, actuellement utilisée par Air France-KLM, est résumé dans le tableau 2.1 et détaillé en Annexe A.1. Squale collecte différentes mesures qu il utilise pour fournir une note globale de haut-niveau comprise dans l intervalle [0; 3]. Pour transformer ces mesures hétérogènes en notes comprises dans l intervalle [0; 3], Squale calcule les notes en deux étapes : le calcul d une note individuelle qui fournit un résultat par composant (par classe ou par méthode par exemple), puis le calcul d une note globale à partir des notes individuelles qui détermine une note au niveau du projet. Les notes des pratiques de code sont composées par : 63

78 Chapitre 2. Le modèle Squale Table 2.1 Les pratiques de code d une instance du modèle Squale Nom de la pratique Taille d une méthode Nombre de méthodes Code Spaghetti Profondeur d héritage Couplage efférent Couplage afférent Couteau suisse Copier-Coller Cohésion de classe Taux de commentaires Niveau d abstraction et de stabilité Dépendance cyclique Spécialisation de la classe Définition calcule la taille des méthodes pour alerter sur les méthodes trop longues qualifie le nombre de méthodes pour chaque classe qualifie le niveau de déstructuration et de complexité du code pointe les classes qui ont une profondeur d héritage trop élevée analyse la dépendance entre une classe et les autres classes de l application analyse la dépendance des classes de l application vis à vis d une classe recherche les classes dites utilitaires traque les parties du code source qui ont été dupliquées par simple copier-coller qualifie les relations entre les méthodes dans une classe qualifie le taux de commentaires dans le code source qualifie la cohérence d un package en terme d abstraction (ou non) et de stabilité met en avant tous les cas de dépendance cyclique des packages mesure le niveau de spécialisation de la classe Les notes individuelles. Chaque composant (méthode, classe, package) concerné par une pratique donnée possède une note pour cette pratique. Cette note est calculée à partir des mesures effectuées sur cet élément. Elle est notée IM (pour Individual mark ) dans les formules. Par exemple, les deux métriques qui définissent la note de la pratique taux de commentaires, à savoir complexité cyclomatique et nombre de lignes de code, sont calculées pour chaque méthode du projet. La pratique taux de commentaires possède donc une note individuelle, calculée pour chaque méthode du projet à partir des métriques. Cette note prend en compte le poids d une métrique par rapport à une autre et associe les métriques selon une formule définie. Cette note individuelle est donnée dans l intervalle [0 ;3] pour permettre des comparaisons entre composants. La note globale. Une note globale est ensuite attribuée pour une pratique donnée en se basant sur les notes individuelles obtenues pour chaque composant. Elle est notée GM (pour Global mark ) dans les formules. La pratique taux de commentaires possède donc une note globale calculée à partir de ses notes individuelles. Les pratiques qui reposent sur des mesures au niveau projet ont une note globale et pas de note individuelle. La pratique dépendance cyclique, par exemple, possède une seule note globale pour le projet entier, les cycles étant calculés pour le projet dans son ensemble Les notes individuelles Une note individuelle est calculée à partir des mesures obtenues pour un composant donné. Les mesures sont données dans des intervalles hétérogènes tandis que la note individuelle est toujours comprise dans l intervalle [0; 3]. Pour transposer les mesures brutes en note individuelle, le modèle Squale utilise une formule continue afin d éviter les effets de seuil et de traduire les variations de mesure au plus juste. Chaque pratique tient compte des spécificités des métriques utilisées et la fonction de calcul de la note individuelle est déterminée pratique par pratique (ces formules sont données dans l annexe A.1). 64

79 2.3. Le calcul des notes de Squale Ces fonctions continues sont également ajustées aux besoins des entreprises qui utilisent le modèle. C est pourquoi les fonctions utilisées se fondent sur des valeurs seuils établies par des experts au sein des entreprises. A partir de ces valeurs, on définit une équation, linéaire ou non, qui interpole au mieux les valeurs intermédiaires. La pratique Nombres de méthodes, par exemple, détermine si le nombre de méthodes de la classe est satisfaisant. Les seuils expliqués dans l exemple suivant sont tirés de l instance du modèle mis en place chez Air France-KLM. Les seuils correspondent donc aux exigences de cette entreprise. Ils sont cependant adaptables facilement. Un seuil a été défini dans un premier temps qui correspond à un nombre de 15 méthodes par classe maximum pour une qualité optimale, soit une note de 3. La note décroit ensuite non seulement en fonction du nombre de méthodes mais également en fonction de la complexité des méthodes. Ceci permet de traduire le fait qu une classe qui possède des méthodes complexes doit avoir un nombre de méthodes moins important qu une classe ayant des méthodes moins complexes. Le tableau 2.2 fournit les valeurs seuils retenues pour calculer les notes de la pratique. La métrique V(G) est utilisée comme seuil pour calculer la note de la pratique de différentes manières. La métrique NOM est utilisée dans l équation pour déterminer la note obtenue. La pratique utilise donc 3 équations qui permettent de fournir des résultats continus et évitent les effets de seuils. Soient v(g) la complexité cyclomatique de la classe et NOM la métrique nombre de méthodes, pour chaque valeur seuil de v(g) on définit la valeur de IM, note individuelle : SI v(g) 80 ALORS IM = 2 (30 NOM)/10 SI v(g) 50 ET NOM 15 ALORS IM = 2 + (20 NOM)/30 SI v(g) 30 ALORS IM = 3 + (15 NOM)/15 SINON IM = 3 Table 2.2 Mesures/notes de références servant de base aux équations déterminant la note de la pratique Nombre de méthodes Note de la pratique valeur de V(G) valeur de NOM Les notes globales Pour une pratique donnée, chaque composant du projet visé par celle-ci obtient une note individuelle située dans l intervalle [0; 3]. Ces notes sont ensuite agrégées ensemble pour obtenir la note 65

80 Chapitre 2. Le modèle Squale globale de la pratique (i.e., pour le projet) : la note obtenue au niveau projet pour une pratique donnée. Les poids de la note globale La fonction utilisée pour calculer cette note globale permet de faire ressortir les mauvaises notes pour mettre en avant les points faibles. Pour cela, un système de pondération a été introduit qui permet de définir un seuil de tolérance aux mauvaises notes individuelles. Ce seuil est fixé en fonction des exigences des entreprises et permet de renforcer les pratiques importantes et critiques : les pondérations utilisées pour ces dernières sont plus sévères que pour les autres, faisant baisser la note globale plus rapidement. Avoir un seuil de tolérance aux mauvaises notes signifie que le modèle prend en compte les exceptions à certaines règles. En effet, reprenons l exemple précédent de la taille d une méthode. S il est souhaitable d avoir des méthodes qui ont un nombre fixé de lignes de code, le développeur peut parfois être amené à déroger à cette règle pour coder une fonction particulière du logiciel. Dans ce cas, la méthode qui déroge à la règle obtiendra une mauvaise note individuelle, ce qui permettra de la mettre en avant et de lui porter une attention particulière dans le reste des étapes de développement (tests plus poussés sur cette méthode ou encore commentaires plus nombreux et plus explicites). Toutefois, la mauvaise note individuelle n entrainera pas une mauvaise note globale. En revanche, la note globale sera mauvaise si le programme contient trop de méthodes ayant une mauvaise note individuelle. Le modèle intègre quelques mauvaises notes à condition qu elle soient des exceptions et non la règle. Les poids traduisent donc le seuil de tolérance du modèle de la sorte : un poids fort est appliqué quand la tolérance aux exceptions est extrêmement faible. Dans ce cas, il suffit de peu de mauvaises notes individuelles pour obtenir une mauvaise note globale comprise dans l intervalle [0; 1] ; un poids moyen est utilisé quand la tolérance aux exceptions se situe dans la norme. La note globale chute dans l intervalle [0; 1] uniquement s il existe un nombre moyen de mauvaises notes individuelles ; un poids faible est appliqué en cas de tolérance très grande aux exceptions. La note globale ne chute alors que s il existe un grand nombre de notes individuelles mauvaises. La fonction de calcul de la note globale de Squale La fonction de calcul de la note globale de Squale a pour définition : ( ISquale λ = log n ) 1 λ λ IMn n, où λ varie selon le poids appliqué et IM n correspond à la note individuelle pour le composant n. Cette fonction peut être comprise comme le résultat de plusieurs étapes dans le processus de calcul de la note globale : Dans un premier temps une fonction de pondération est appliquée à chaque note individuelle : g(im) = λ IM

81 2.3. Le calcul des notes de Squale où IM Individual Mark correspond à la note individuelle d un composant pour une pratique donnée et λ correspond à une constante qui définit le poids appliqué lourd, moyen ou léger. λ est plus élevé pour un poids fort tandis qu il diminue pour un poids faible. Cette transformation transpose également les notes individuelles dans un nouvel espace où les notes les plus basses ont plus de poids que les plus élevées. 2. Dans un second temps, la moyenne de ces notes pondérées à l étape précédente est calculée. 3. Enfin, sur cette moyenne est appliquée la fonction opposée : g 1 (W avg(ims)) = log λ (W avg(ims)) qui permet de retransposer la note obtenue dans l espace de notation initial de [0; 3]. g(im) weighted average weighted mark mark average Figure 2.6 Principe de pondération : les notes individuelles sont diminuées lorsqu elles sont transposées dans l espace pondéré. La figure 2.6 représente ces différentes étapes pour trois notes individuelles de départ (représentées en bleu sur l axe des x) qui ont pour valeur 0.5, 1.5, et Les notes individuelles sont pondérées et notées en bleu sur l axe des y avec un poids moyen appliqué soit λ = 9. Elles ont pour valeur respectives 0, 33, 0, 037 et 0, Cette transformation donne effectivement plus de poids à la note la plus basse : la note de 0, 5 devient nettement plus importante (0, 33) tandis que la note la plus haute (3) perd quasiment toute valeur (0, 0013). 2. La moyenne de ces trois notes est représentée en rouge sur l axe des y. Elle a pour valeur 0, 123. Le point jaune sur la figure représente la moyenne simple des notes initiales, soit 1, La fonction opposée appliquée ensuite permet d obtenir la note dans l espace [0; 3], soit 0, 93. Elle est représentée par le point rouge sur l axe des x. Pour illustrer ces différents calculs, nous expliquons à présent l exemple d une pratique dans le détail L exemple détaillé d une pratique Prenons la pratique taux de commentaires. Elle a pour propriétés : définition : qualifie le taux de commentaires des lignes de code d une méthode. Cette pratique ne prend pas en compte les javadoc par exemple. Elle vérifie l assertion suivante : plus une méthode est complexe et plus elle doit être commentée. La complexité d une méthode est calculée en 67

82 Chapitre 2. Le modèle Squale fonction du nombre de lignes de code mais également de sa complexité cyclomatique. La fonction de calcul des notes individuelles a été définie avec des seuils qui tiennent compte de l encapsulation accesseurs et mutateurs ne sont pas pris en compte dans le calcul et qui visent à obtenir des taux de commentaires allant de 10 % à 30 % en fonction de la complexité de la méthode. composant : méthodes. métriques : V(G) pour complexité cyclomatique, CLOC pour nombre de lignes de commentaires et SLOC pour nombre de lignes de code source. note individuelle (IM). IM calculée à partir des métriques a pour formule : Si V (G) 5 ou SLOC > 30 : Alors : IM = (CLOC) 9/(CLOC + SLOC)/(1 10 ( V (G)/15) ) note globale (GM) : I Squale poids : faible Le tableau 2.3 donne les valeurs seuils de cette pratique, à partir desquelles a été déterminée la formule de calcul des notes individuelles. Table 2.3 Mesures/notes de références servant de base à la formule déterminant la note de la pratique Taux de commentaires Note de la pratique Métrique V(G) Taux de commentaires < % [0; 1[ 5 5% [0; 1[ > 15 10% [1; 2] 15 [2, 5; 3[ 25 30% % Pour un projet donné, chaque méthode du projet obtient ainsi une note individuelle dans l intervalle [0; 3] (sauf pour les méthodes d encapsulation qui ne sont pas prises en compte : la pratique n est calculée que pour les méthodes d une complexité V (G) 5 et d une taille SLOC > 30). L ensemble de ces notes est ensuite agrégé selon la formule ISquale λ définie précédemment pour obtenir une note globale de la pratique Taux de commentaires pour l ensemble du projet. La table 2.4 donne un exemple de notes attribuées à dix méthodes en fonction des résultats des métriques SLOC, V(G), CLOC. La note individuelle varie en fonction du nombre de lignes de commentaires par rapport au nombre de lignes de code mais également en fonction de la complexité de la méthode. Les méthodes G et H, bien qu ayant les mêmes nombres de lignes de commentaires et de code n obtiennent pas la même note : la méthode H ayant une complexité moindre, elle obtient de fait une note individuelle plus élevée, qui la classe dans les méthodes ayant une note acceptable pour cette pratique, tandis que la méthode G obtient une note insuffisante pour cette pratique. Ceci est dû aux formules de calcul des notes individuelles dans le modèle Squale qui tiennent comptent de plusieurs paramètres pour évaluer le fait que les commentaires d une méthode doivent dépendre du nombre de lignes de code mais également de sa complexité. 68

83 2.3. Le calcul des notes de Squale La table 2.4 donne également les résultats pour la note globale selon les principes expliqués précédemment. La note globale varie en fonction du poids attribué : plus le poids est fort et plus l exigence est élevée, ce qui se traduit par une note globale qui diminue fortement en fonction du poids. La moyenne simple quant à elle ne traduit pas le fait que certaines méthodes sont en dessous des exigences requises (les méthodes A et E par exemple) et donne un résultat globalement satisfaisant : elle lisse et homogénéise les résultats plutôt que de mettre en avant les points faibles. Table 2.4 Série 1 de notes pour la pratique Taux de commentaires Méthode A B C D E F G H I J Métrique V(G) Métrique CLOC Métrique SLOC Note individuelle IM 1,246 2, , ,976 2,869 1,840 2, 670 Notes globales ISquale λ poids faible ISquale λ poids moyen ISquale λ poids fort Moyenne simple Table 2.5 Série 2 de notes pour la pratique Taux de commentaires Méthode A B C D E F G H I J Métrique V(G) Métrique CLOC Métrique SLOC Note individuelle IM 1,246 2, ,976 2,869 1,840 2, 670 Notes globales ISquale λ poids faible ISquale λ poids moyen ISquale λ poids fort Moyenne simple La table 2.5 reprend les mêmes valeurs que la table précédente à une valeur près : le nombre de lignes de commentaires de la méthode E. La note individuelle de cette méthode s en trouve alors fortement augmentée : elle passe d une note insuffisante à une note acceptable selon le barème d interprétation des notes du modèle Squale (voir Section 2.2). Les notes globales s interprétant de la même façon, le graphe 2.7 permet de constater que dans la série 1 toutes les notes globales sont inacceptables (i.e., < 2) alors que pour la série 2, les notes globales de poids faible et moyen sont devenues acceptables. L utilisation de poids renforce l écart entre les résultats des deux séries. Les poids servent donc à ajuster le niveau d exigence des entreprises pour chaque pratique. Lors de la mise en place d une instance du modèle en entreprise, les pratiques ont des poids attribués par défaut. Les entreprises peuvent décider de changer le poids pour une pratique en fonction de ses propres exigences. 69

84 Chapitre 2. Le modèle Squale 3 2,5 2 1,5 Série 1 Série 2 1 0,5 0 poids faible poids moyen poids fort moyenne Figure 2.7 Les notes globales obtenues pour les deux séries des tables 2.4 et 2.5. Cette pratique offre une aide au développeur pour déterminer quelles sont les méthodes à commenter davantage. Par exemple, la note de la méthode E a été améliorée par l ajout de nouveaux commentaires. Les notes individuelles fournissent donc une aide très précise pour le technicien en pointant de manière directe et précise les composants du projet qui ne donnent pas satisfaction. De plus chaque modification, chaque effort est pris en compte dans les calculs et traduit au plus juste les efforts en terme de qualité : l ajout de lignes de commentaires, qui entraîne la modification de la mesure de CLOC va être transposé dans la note individuelle de la pratique (la note augmente) et celle-ci va également influencer la note globale. Ainsi les efforts, tout comme les dégradations de code sont pris en compte dans le calcul des notes des pratiques de code. Les notes globales de la pratique permettent en un seul coup d œil de déterminer si l ensemble du projet satisfait à la règle évaluée par celle-ci, contrairement à une moyenne simple qui ne donne finalement qu une indication générale pas réellement exploitable. Au contraire, les notes globales des pratiques de Squale permettent d une part de fixer le niveau de tolérance aux erreurs sur le projet (un poids faible pour cette pratique entraîne une note globale acceptable pour la seconde série alors qu un poids fort entraîne une note insuffisante pour cette même série de notes), et d autre part traduisent efficacement les efforts d amélioration de la qualité tout comme les dégradations (les variations des notes individuelles sont répercutées dans le calcul de la note globale de la pratique). Le manager peut ainsi d une part fixer avec précision le niveau de qualité attendu sur le projet et d autre part suivre l évolution de celui-ci dans le temps Les pratiques de normes et standard Ces pratiques déterminent le degré de respect des règles de codage. Elles reposent sur les conventions de codage telles que définies dans la section Ces règles sont définies au début du projet et doivent être respectées par les développeurs. Elles dépendent également des règles définies par l entreprise. 70

85 2.3. Le calcul des notes de Squale L ensemble des pratiques de normes et standard définies pour une instance du modèle Squale est résumé dans le tableau 2.6 et détaillé en Annexe A.2. Table 2.6 Les pratiques de normes et standard d une instance du modèle Squale Nom de la pratique Respect de l architecture en couche Documentation Mise en forme Règles de nommage Traçage Sécurité Portabilité Programmation Gestion de configuration Définition détermine le niveau de respect de l architecture définie initialement détermine si la documentation extractible existe dans le projet détermine si les règles de mise en forme du code sont respectées détermine le niveau de respect des règles de nommage qualifie les éléments de traçage pour la génération automatique des logs qualifie le respect des règles de sécurité pour les lignes de code détermine la portabilité de l application détermine le niveau de respect des règles de programmation et de codage vérifie l utilisation de la gestion de configuration Les notes des pratiques de normes et standard Les pratiques sont liées à l outil utilisé pour les mesurer. Si l outil ne fournit qu un rapport pour l ensemble du projet la pratique correspondant ne peut pas être calculée sur les méthodes par exemple et reste calculée sur tout le projet. Checkstyle ou PMD actuellement utilisés pour calculer ces pratiques fournissent un rapport sans spécifier l entité concernée, c est pour cela que les pratiques sont calculées sur le projet dans son ensemble (elle n ont pas de note individuelle). Pour ces pratiques, la note globale GM est fonction du nombre de transgressions de ces règles. On recense trois types de transgression : les erreurs qui sont les plus fortement pondérées, leur poids est noté W 1 ; les warning qui sont modérément pondérées, leur poids est noté W 2 ; les informations qui sont légèrement pondérées, leur poids est noté W 3. Le poids appliqué aux transgressions reflète l importance de la transgression. Il correspond à la tolérance aux transgressions par nombre d items (ligne de code, classes, etc.). La formule utilisée pour calculer la note globale est de la forme : GM = W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber metrique avec W 1 le poids appliqué à ErrorNumber le nombre d erreurs, W 2 le poids appliqué à W arningnumber le nombre de warning, W 3 le poids appliqué à InfoNumber le nombre d informations et metrique la métrique utilisée dans la pratique en fonction de la convention mesurée. Cette formule résume les différentes étapes de calcul de la note globale : 1. application des poids en fonction de la gravité des transgressions. Les erreurs, warning et informations sont comptabilisées et le poids correspondant leur est appliqué ; 2. moyenne des résultats en fonction du composant mesuré. Par exemple, si la règle mesurée concerne les lignes de code, la métrique SLOC est alors utilisée ; 3. transposition du résultat dans l espace de notation [0; 3]. 71

86 Chapitre 2. Le modèle Squale L exemple d une pratique de normes et standard Prenons l exemple de la pratique Normes et standard documentation. Cette pratique est définie par : définition : détermine si la documentation extractible (par exemple, la Javadoc) existe dans le projet. Elle ne qualifie pas les commentaires des lignes de code. composant : projet. métriques : SLOC pour le nombre de lignes de code source. note globale (GM) : GM = poids : faible. W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC Cette pratique détermine si les conventions associées aux commentaires extractibles sont respectées. Ces conventions sont déterminées au début du projet et doivent être respectées pour uniformiser la documentation. Les poids associés aux différents types d avertissements sont les suivants : W 1 vaut 500 ; W 2 vaut 30 ; W 3 vaut 5. Le tableau 2.7 donne des exemples de notes attribuées à différents projets. Le très fort poids attribué aux erreurs entraîne une chute de la note de la pratique dès que le seuil des erreurs franchit la barre des 0,5 %. De même, dès que le taux des warning franchit le seuil des 10 % la note de la pratique devient insuffisante. Le seuil de tolérance pour les infos est, quant à lui, très élévé, avec 70 %. Le tableau montre également que pour une somme de 2 % d avertissements, selon leur répartition en erreurs, warning ou infos, la note de la pratique diffère de manière significative, ce qui montre que les degrés d importance des avertissements sont pris en compte grâce aux poids appliqués : les erreurs sont considérées comme rapidement bloquantes tandis que les warning sont davantage tolérés et que les infos sont légèrement pris en compte dans la note. Ce type de pratiques oblige les développeurs à respecter les conventions d écriture et de mise en forme du code de manière générale. Pour une pratique donnée, le développeur peut tout de suite savoir si la convention mesurée est respectée et sait en fonction du type de transgressions (erreur, warning ou info) ce qui doit être rectifié dans le code pour augmenter la note de la pratique mais également ce qui doit être modifié dans sa façon de travailler pour s améliorer par rapport au respect des normes et conventions de l entreprise. Le manager pour sa part, peut savoir, grâce aux notes des pratiques de normes et standard, si les normes et conventions en vigueur dans l entreprise sont respectées. De même, il peut déterminer quelles sont les pratiques pour lesquelles il souhaite une plus grande vigilance en appliquant un poids différent selon les cas. Il peut, par exemple, renforcer les poids d une pratique donnée pour obliger les développeurs à une plus grande rigueur dans le respect d une règle donnée Les pratiques documentaires Ces pratiques reposent sur des analyses faites par des experts. Il s agit de pratiques qui ne peuvent être évaluées de manière automatique, à partir de métriques. Certaines pratiques de type documentaires (c est-à-dire évaluées par un expert) sont classées dans les pratiques de modèle ou de tests car 72

87 2.3. Le calcul des notes de Squale Table 2.7 Exemple de notes pour la pratique Normes et standard documentation SLOC % de SLOC % de SLOC % de SLOC Nombre d erreurs 47 0, 1% 236 0, 5% 473 1% Nombre de warning 0 0% 0 0% 0 0% Nombre d infos 0 0% 0 0% 0 0% Note GM 2,45 1,09 0,39 SLOC % de SLOC % de SLOC % de SLOC Nombre d erreurs 0 0% 0 0% 0 0% Nombre de warning % % % Nombre d infos 0 0% 0 0% 0 0% Note GM 1,84 0,88 0,26 SLOC % de SLOC % de SLOC % de SLOC Nombre d erreurs 0 0% 0 0% 0 0% Nombre de warning 0 0% 0 0% 0 0% Nombre d infos % % % Note GM 2,45 1,088 0,73 SLOC % de SLOC % de SLOC % de SLOC Nombre d erreurs 946 2% 0 0% 0 0% Nombre de warning 0 0% 946 2% 0 0% Nombre d infos 0 0% 0 0% 946 2% Note GM 0,05 2,35 2,88 SLOC % de SLOC % de SLOC % de SLOC Nombre d erreurs 315 0, 665% 157 0, 33% 78 0, 16% Nombre de warning 315 0, 665% 630 1, 33% 78 0, 16% Nombre d infos 316 0, 67% 158 0, 34% 790 1, 68% Note GM 0,7 1,3 2,03 elles sont directement liées au modèle ou aux tests. Cependant, leur mode d évaluation est identique à celui décrit ci-après. L ensemble des pratiques documentaires définies pour une instance du modèle Squale est résumé dans le tableau 2.8 et détaillé en Annexe A Les notes des pratiques documentaires Prenons l exemple de la pratique qualité de la documentation. Celle-ci est définie comme étant : la qualité de l ensemble de la documentation technique du projet telle que définie par la méthodologie interne et permettant à un développeur de comprendre rapidement le projet. L évaluation de la qualité de la documentation est alors effectuée en suivant ce barème : 0 pour aucune documentation ; 1 ou 2 pour une documentation de mauvaise qualité ; 3 pour une documentation de qualité satisfaisante. 73

88 Chapitre 2. Le modèle Squale Table 2.8 Les pratiques documentaires d une instance du modèle Squale Nom de la pratique Définition Qualité de la documentation qualifie la documentation technique par rapport à la méthodologie Découpage en couches vérifie la présence d un dossier de spécifications techniques validé Organisation générale du code qualifie l organisation du code de manière macroscopique Design-pattern évalue les mécanismes articulant la cinématique de l application Dossier d architecture technique qualification de la présence d un DAT validé Choix des technologies vérifie le choix des technologies et leur adéquation avec les besoins Correspondance entre couche et nommage vérifie la conformité des noms des packages avec le découpage Respect des règles de sécurité de l entreprise : dossier de conception technique vérifie les règles de sécurité du DCT Partie sécurité du cahier des charges vérifie les règles de sécurité du cahier des charges Dossier design technique : sécurité vérifie que le design prend en compte les règles de sécurité Conformité implémentation/définition sécurité vérifie que les règles de sécurité sont respectées Dossier de production vérifie l existence et la pertinence du dossier de production Gestion des exceptions vérifie la manière dont sont gérés les exceptions dans un code Analyse des risques tests pilotés par l évaluation des risque fonctionnels et techniques Scénario de tests d acceptation vérification de la qualité des scénarios de tests fonctionnels Plan d assurance qualité vérifie la qualité du plan d assurance qualité Normes d ergonomie vérifie la qualité des normes d ergonomie implémentées Spécifications fonctionnelles vérifie la cahier du cahier des charges L expert chargé de l évaluation doit attribuer lui-même une note, juger la qualité de la documentation en fonction de son point de vue, prendre en compte les informations contenues dans la définition de la pratique et évaluer celle-ci de manière globale. Les pratiques issues de données brutes qui ne sont pas des métriques procèdent toutes de la même manière : elles sont définies le plus précisément possible et l expert attribue une note globale. A cette note est adjointe une durée de longévité pour tenir compte de la date à laquelle cette pratique a été évaluée. En effet, contrairement aux pratiques reposant sur des métriques et pouvant être recalculées autant de fois que nécessaire, ces dernières ne sont pas mise à jour systématiquement. Certaines notes sont valables pour tout le projet tandis que d autres doivent être ré-évaluées lors de changement majeurs par exemple. On obtient ainsi un niveau de fiabilité de la note L exemple d une pratique documentaire Soit l exemple de la pratique design-pattern. Elle a pour propriétes : définition : il s agit d évaluer les mécanismes articulant la cinématique de l application, à savoir la mise en œuvre des design-patterns, leur pertinence, la qualité de leur implémentation. composant : le projet note globale : notation discrète 0 pour mauvais choix des design-patterns, mécanismes mis en œuvre inadaptés aux besoins ou mauvaise implémentation des mécanismes ; 1 et 2 représentent les situations intermédiaires des extrêmes 0 et 3 ; 3 pour mise en œuvre des design-patterns reconnus, mécanismes pertinents et adaptés aux besoins, implémentation correcte des mécanismes choisis. 74

89 2.3. Le calcul des notes de Squale Cette pratique sert à évaluer les différents mécanismes mis en place pour la conception du logiciel, notamment s il n existe pas de framework imposé. Il faut vérifier que les solutions choisies ne complexifient pas inutilement le produit et répondent aux besoins. Prenons les différents cas de figures possibles de la note de la pratique. 0 : dans ce cas la pratique est insuffisante, mais on ne peut pas savoir exactement pourquoi (les design-patterns ont été mal choisis, ou alors les mécanismes sont inadaptés ou encore l implémentation est mauvaise) ; 1 : la pratique obtient donc une note traduisant le fait que le but n est pas encore atteint. La encore on ne peut déterminer exactement pourquoi ; 2 : la pratique obtient un score suffisant mais ne donne aucune indication quant à ce qui pourrait augmenter la qualité de celle-ci ; 3 : la pratique obtient un score maximum. L évaluation de la pratique se fait à partir de la revue de la documentation de conception mais aussi de la revue du code. Elle nécessite une forte compétence technique de la part de l expert qui évalue la pratique. Il faut également souligner que la marge de manœuvre est faible pour intervenir sur cette pratique, les modifications coûtant très chers ensuite. Il faut donc envisager les corrections et donc l évaluation de cette pratique le plus en amont possible dans la conception Les pratiques de modèle L objectif du modèle Squale est de qualifier le projet dès que possible pour aider les développeurs à améliorer la qualité du projet. C est pourquoi quand il existe un modèle U.M.L., le modèle Squale aide à analyser la pertinence du modèle. L analyse de métriques de modèle vise à étudier la qualité de la modélisation du projet, au travers de métriques objets et volumétriques directement issues du modèle UML. Le contrôle de ces métriques permet souvent d anticiper au maximum les erreurs de d analyse et de conception qui pourraient nuire gravement à la phase d implémentation. Cette analyse vise aussi à étudier la conformité entre la modélisation et l implémentation du projet. On compte parmi les métriques de modèle les familles suivantes : les métriques de modélisation telles le nombre d associations ou le nombre d agrégats d une classe ; les métriques volumétriques, tel le nombre de méthodes ou le nombre de classes ; les métriques orientées objet, par exemple le nombre d attributs par visibilité (public, protégé, privé), nombre de méthodes par visibilité (public, protégé, privé), la profondeur moyenne et maximale de l arbre d héritage. L ensemble des pratiques de modèle définies pour une instance du modèle Squale est résumé dans le tableau 2.9 et détaillé en Annexe A Les notes des pratiques de modèle Les pratiques de modèle sont évaluées selon deux principes différents : les pratiques qui utilisent des métriques sont notées selon les mêmes principes que les pratiques de code (voir Section et ) ; les pratiques de modèle qui reposent sur une expertise humaine sont notées selon les mêmes principes que les pratiques documentaires (voir Section ). 75

90 Chapitre 2. Le modèle Squale Table 2.9 Les pratiques de modèle d une instance du modèle Squale Nom de la pratique Diagramme de modélisation Pré-dectection d antipatterns Encapsulation Classes sans méthode Classes sans attribut Classes isolées Raisonnement par les modèles Conformité modélisation/implémentation Définition vérifie la pertinence des diagrammes du cycle de modélisation détermine les antipatterns connus et identifiables. qualifie le nombre de champs publics de la classe qualifie le nombre de méthode pour une classe qualifie le nombre d attribut de la classe qualifie la relation entre la classe et le reste du projet évalue le niveau de raisonnement par modèle qualifie la cohérence entre le modèle et l implémentation Certaines pratiques utilisent une combinaison de métriques basique pour calculer leurs notes individuelles. Il s agit pour ces pratiques de vérifier que certaines règles telles que les règles d accession aux attributs sont respectées. Pour chaque composant, la métrique vérifie le respect de la règle et la note individuelle attribuée est : 0 si la métrique renvoie un résultat, c est-à-dire qu il existe au moins un élément qui ne respecte pas la règle ; 3 si la métrique renvoie 0, c est-à-dire que tous les éléments mesurés suivent la règle L exemple d une pratique de modèle Prenons l exemple de la pratique encapsulation. Elle vérifie qu il n existe aucun champ public dans le programme, c est-à-dire que les attributs sont accédés à l aide de méthodes dédiées. Cette pratique est définie par : définition : qualifie le nombre de champs publics de la classe. Les champs publics doivent être évités. Il est recommandé d utiliser des accesseurs à la place, permettant un respect des règles de la programmation objet et notamment l encapsulation. composant : classe. métriques : nombre de champs publics. note individuelles (IM) : 0 s il existe au moins un champ public dans la classe ; 3 si la classe ne possède aucun champ public. note globale (GM) : I λ Squale poids : moyen Le tableau 2.10 contient différentes mesures pour un projet de 410 classes. Les notes individuelles sont réparties selon les deux valeurs possibles 0 et 3 correspondant au fait qu une classe ne doit pas posséder de champ public. Le seuil de tolérance varie avec le poids appliqué lors de l agrégation des notes individuelles. Par exemple, pour 5% de classes ayant au moins un champ public, la note globale varie, passant de 2, 25 pour un poids faible à 0, 92 pour un poids fort. En principe, ce type de champ devant être absolument évité, il est donc préférable d appliquer un poids fort pour cette pratique qui chutera drastiquement dès la première note individuelle à 0 comme le montre la dernière colonne du tableau : pour une seule classe la note globale est déjà en dessous de 2 pour un poids fort. 76

91 Table 2.10 Exemple de notes pour la pratique encapsulation 2.3. Le calcul des notes de Squale Nombre de classes 410 % 410 % 410 % 410 % de classes de classes de classes de classes IM de valeur % % % , 75% IM de valeur % 41 10% 20 5% 1 0, 25% Note GM poids faible 0,31 1,83 2,25 2,94 Note GM poids moyen 0,16 1,04 1,36 2,54 Note GM poids fort 0,11 0,7 0,92 1,82 moyenne simple 0,9 2,7 2,85 2,99 Cette pratique permet d identifier, avant même le début de la phase de développement les erreurs de conception du logiciel. En effet, les champs publics doivent absolument être évités. Dans ce cas, s il existe un champ public au sein d une classe, le modèle devra être revu pour corriger le défaut. Toutes les pratiques de modèle permettent de vérifier, avant même l implémentation, la pertinence de l architecture. Elles permettent d effectuer au plus tôt les corrections nécessaires et met en avant les erreurs de conception. En terme de maintenance informatique, de telles erreurs doivent être absolument détectées au plus tôt afin d éviter le bogues et les difficultés de maintenance qui en découlent Les pratiques de tests Ces pratiques évaluent la qualité des tests effectués sur l application : les tests structurels ou les tests fonctionnels. Ces pratiques servent à déterminer si l application est correctement testée mais également si celle-ci est en adéquation avec les besoins du client. L ensemble des pratiques de tests définies pour une instance du modèle Squale est résumé dans le tableau Table 2.11 Les pratiques de tests d une instance du modèle Squale Nom de la pratique Tests de non régression fonctionnels Tests aux limites Couverture des scénarios de tests fonctionnels Tests automatiques fonctionnels Taux de couverture des tests d intégration Taux de couverture des tests unitaires Tests unitaires Tests de robustesse Tests de charge Tests de performance Définition vérifie la présence de tests de non-régression et évalue leurs résultats vérifie la présence de tests aux limites et leur évaluation qualifie le niveau de couverture des scénarios vérifie la présence et l avancement des scénarios de tests automatiques vérification et évaluation des tests d intégration qualifie le taux de couverture des TU vérification et évaluation des tests unitaires vérification et évaluation des tests de robustesse vérification et évaluation des tests de charge vérification et évaluation des tests de performance 77

92 Chapitre 2. Le modèle Squale Les notes des pratiques de tests Les pratiques de tests sont évaluées selon deux méthodes : les pratiques qui reposent sur les couvertures de tests sont évaluées à partir de métriques de couverture de tests calculées sur l ensemble du projet. Elles ont donc une note globale, calculée à partir d une fonction permettant de ramener la valeur de la métrique dans l intervalle [0; 3]. les autres pratiques sont évaluées par un expert qui attribue directement une note dans l intervalle [0; 3] de la même manière qu une pratique documentaire L exemple d une pratique de tests Soit la pratique Test unitaires. Elle est définie de la sorte : définition : vérification de la présence de tests unitaires et évaluation des résultats de ces tests. composant : projet note : notation discrète 0 aucun tests unitaire ; 1 et 2 : note intermédiaire entre les deux extrêmes ; 3 présence de tests unitaires avec un taux de réussite de 100 %. Cette pratique vérifie qu il existe des tests unitaires effectués sur le projet. Elle obtient une note de 3 si ces derniers ont un taux de réussite de 100 %. En revanche, les notes intermédiaires de 1 et 2 ne sont pas définies précisément. Il faut noter que la pratique qui lui est associée (taux de couverture des tests unitaires) valide le fait que les tests couvrent tout le code. Cependant, ces deux pratiques ne suffisent pas à déterminer si les tests couvrent tous les cas : en plus du code il faut vérifier que les tests couvrent les données. De plus, il n est pas vérifié que les tests sont effectués systématiquement, à chaque modification de code, ou encore que les erreurs révélées par les tests sont corrigées et suivies. 2.4 L implémentation de Squale Le modèle Squale a été défini de manière empirique par les entreprises Qualixo et Air France- KLM depuis Au cours du projet de recherche, le modèle a été implémenté pour devenir une plate-forme Open-Source, disponible via un site internet, ainsi que les comptes rendus des recherches effectuées durant les deux ans 5. Depuis 2008, Air France-KLM et PSA Peugeot-Citroën ont mis en place dans leur entreprise une instance du modèle, personnalisée en fonction de leurs exigences. L outil Squale évalue les projets en appliquant le modèle de qualité tel que décrit précédemment à partir des mesures recueillies. Il permet de naviguer entre les différents écrans en partant du niveau de plus élevé les notes des facteurs pour arriver jusqu au composants déficients recensés pratique par pratique. La figure 2.8 illustre l exemple d une vue du tableau de bord de Squale s adressant aux managers. Chaque facteur est représenté avec sa note actuelle mais également la note précédente ainsi qu un 5. http :// 78

93 2.5. Conclusion Figure 2.8 Une vue du tableau de bord de Squale. symbole indiquant le niveau de qualité (le symbole météorologique) et une flèche qualifiant l évolution de la note dans le temps. La figure 2.9 représente une vue détaillée pour une pratique donnée. Au cours du projet de recherche, Air France-KLM gérait une centaine d applications : applications de gestion de fret ou de marketing, gestion de personnel ou encore framework techniques. Parmi ces applications, une vingtaine utilisait activement les résultas de Squale pour améliorer la qualité de leur code source. L ensemble du parc analysé par Squale représentait un total de 7 millions de lignes de code pour une moyenne de 130 audit par mois. Le logiciel Squale est également utilisé par PSA Peugeot-Citroën depuis Il monitore environ lignes de code réparties en dix applications Java : deux framework, sept applications métier (commerce et fabrication) ainsi qu un composant technique. L application la plus importante analysée par Squale est utilisée pour coordonner le flux des véhicules au sein des usines. Sa taille est de lignes de code. L application a été bien accueillie par les développeurs et les managers qui ont montré un intérêt pour les résultats de Squale. Ils ont constaté une amélioration de la qualité sur certains projets même s ils ne peuvent quantifier exactement cette amélioration. 2.5 Conclusion Le modèle Squale est composé de quatre couches qui permettent à la fois une vue détaillée de la qualité mais également une vue globale. Son originalité repose sur la définition d un niveau supplémentaire par rapport aux modèles dont il s inspire : les pratiques. Ce modèle a été conçu de manière empirique notamment par les développeurs de Air France- KLM qui se sont principalement attachés à définir les pratiques de code et de normes et standard du modèle. En revanche, les pratiques de tests n évaluent pas complètement toutes les règles techniques associées aux tests (surtout les tests fonctionnels). De même, l évaluation des pratiques documentaires reste très minime et demande à être améliorée. 79

94 Chapitre 2. Le modèle Squale Figure 2.9 Une vue détaillée d une pratique dans Squale. Après avoir étudié le fonctionnement de ce modèle que nous avons présenté dans [Mordal-Manet et al., 2009], nous avons réfléchi à l élaboration d un nouveau modèle, en nous fondant sur les points forts de celui-ci, en y intégrant les exigences de nos partenaires sur le projet de recherche et nos travaux de recherche. 80

95 Chapitre 3 Evaluer la qualité : définitions et propriétés Sommaire 3.1 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é 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 Les modèles de qualité déterminent des principes de qualité qu ils évaluent ensuite. Dans ce chapitre, nous présentons les réflexions personnelles qui nous ont conduits à l élaboration d un nouveau modèle de qualité. Après avoir défini la qualité d un logiciel, nous détaillons les propriétés que nous avons retenues comme étant celles que nous estimons les plus importantes pour un modèle de qualité, puis nous expliquons en quoi les agrégations classiques des mesures ne peuvent satisfaire une évaluation qualitative. A partir de ces constatations, nous complétons les propriétés que doit satisfaire un modèle de qualité pour y intégrer celle qui définissent une évaluation pertinente des mesures. Ces travaux sont issus de nos réflexions personnelles à partir des brainstorming des projets de recherche auxquels nous avons collaboré. 3.1 Présentation générale Pour évaluer la qualité d un logiciel il convient de se poser en priorité les questions suivantes : qu est-ce que la qualité? Comment définir précisément la notion de qualité logicielle? Résoudre ces 81

96 Chapitre 3. Evaluer la qualité : définitions et propriétés questions revient très vite à admettre qu il n y a pas une seule réponse possible tout comme il n y a pas un seul champ d évaluation, un seul point de vue. Il convient donc de préciser le plus finement possible les domaines que l on souhaite mesurer : la maintenabilité de l application, par exemple, ou encore sa fonctionnalité. Ces espaces étant posés, il reste à définir pour chacun d entre eux ce que le terme qualité représente. Quelles sont les règles qui définissent un logiciel fonctionnel? Quels principes régissent la facilité de maintenance d une application par exemple? Une fois ces domaines délimités, il faut alors se doter d outils capables de les évaluer. Dans la pratique on constate qu une démarche qualitative est souvent initiée de deux manières différentes. Soit les différents acteurs de la conception logicielle se retrouvent confrontés à des problèmes qui leur sont propres et tentent de les résoudre de manière indépendante, soit la démarche est initiée au niveau hiérarchique supérieur. Dans le premier cas, les outils utilisés diffèrent souvent selon les métiers. En effet, un développeur optera le plus souvent pour des solutions lui donnant des mesures brutes sur son code source (par exemple l outil Sonar) ; un testeur de son côté fera appel à des outils lui permettant de gérer les bases de tests et d obtenir des métriques associées à ces tests (par exemple Salomé 6 ou TestLink 7 ). S il existe des outils différents, c est, le plus souvent, parce que chacun d entre eux répond aux attentes particulières de celui qui l utilise. En effet, le développeur envisage la qualité d un point de vue du code source et utilise donc des métriques de code pour l aider dans l analyse de son code. En revanche, le testeur aura besoin d outils pour évaluer plus spécifiquement les tests menés sur l application. Chacun d entre eux analysera alors les mesures obtenues avec la vision et le savoirfaire qui lui sont propres. Dans le second cas, lorsque la démarche qualitative est envisagée dans une démarche liée à l entreprise elle-même et non plus seulement au cas particulier d une application, les managers souhaitent avoir une vue globale de cette qualité et non pas une série de résultats de métriques. Il font habituellement appel à des modèles de qualité pour obtenir une évaluation d ensemble et complète de cette qualité tels que la norme ISO 9126 par exemple. Ces modèles tentent d évaluer la qualité de manière plus générale. Ils reposent sur les mesures et les analyses des différents corps de métier pour leur donner sens à un niveau plus global. Il s agit alors d appliquer une démarche homogène et d utiliser un référentiel commun pour évaluer non plus une application ou encore une partie de l application, ni même un ensemble d applications, mais d évaluer la qualité pour la faire évoluer dans le temps, pour mettre en place un référentiel, une méthodologie, des normes. Dans le cadre de nos travaux, nous avions pour objectif à la fois de formaliser et de valider le modèle Squale. Nous avons tout d abord donné une définition précise de la qualité (section 3.2), nous avons ensuite validé l architecture du modèle Squale à partir des différents modèles existants (section 3.3.1), puis nous avons défini un certain nombre de principes que nous présentons dans la section Ces principes reposent à la fois sur les différentes recherches que nous avons effectuées mais également sur les exigences et contraintes qui nous ont été données par les entreprises du projet Squale. Pour répondre aux attentes des entreprises avec lesquelles nous avons travaillé, nous avons envisagé l évaluation de la qualité en réunissant deux approches : construire un modèle qui réponde à la 6. https ://wiki.ow2.org/salome-tmf/ 7. http :// 82

97 3.2. Que signifie évaluer la qualité fois aux attentes des managers mais également utilisable par les différents techniciens. Pour faire la jonction entre ces deux visions de la qualité, les mesures utilisées doivent être agrégées de manière à faire passer le message délivré au plus bas niveau vers le plus haut niveau : il s agit de transcrire les informations brutes en informations globales sans pour autant perdre les détails. Nous avons donc envisagé la façon d agréger les mesures et les différentes techniques qu il est possible d utiliser. Nous présentons ces travaux dans la section 3.4. A partir de ces études nous avons ensuite défini les propriétés que doit posséder un modèle pour évaluer la qualité, détaillées dans la section Que signifie évaluer la qualité Définir la qualité logicielle n est pas aussi évident qu il y parait. Prenons tout d abord les différentes définitions de la qualité : 1. la norme ISO 9001 définit la qualité comme le degré auquel un ensemble de caractéristiques remplit les exigences (du client) [ISO/IEC, 2008] ; 2. le livre swebok donne la définition suivante : un ensemble de règles et de principes à suivre au cours du développement d une application afin de concevoir un logiciel répondant aux attentes (du client), le tout sans défaut d exécution [Abran et al., 2004] ; 3. la norme ISO 8402 définit la qualité logicielle comme étant la capacité à satisfaire les besoins exprimés et implicites [ISO/IEC, 1994] ; 4. la norme 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 [ISO/IEC, 2001]. Ces différentes définitions mettent en avant les notions suivantes : exprimer des besoins implicites et explicites ; remplir des exigences, répondre aux attentes, être capable de satisfaire des besoins ; formaliser des ensembles de règles et principes à suivre ; garantir qu il n y a pas de défaut d exécution. A partir de ces différentes considérations, nous posons pour notre part les définitions et principes suivants, sur lesquels nous appuyons ensuite nos travaux : La qualité d un logiciel est le degré auquel un logiciel remplit les besoins et exigences des clients sans défaut d exécution. La qualité logicielle s exprime sous forme de règles et de principes à suivre pour développer un logiciel capable de répondre aux attentes du client, c est-à-dire développer un logiciel de qualité. Les besoins d un client doivent être exprimés avec soin, de manière précise et détaillée et doivent faire l objet d une étude minutieuse. La qualité d un logiciel repose donc sur deux notions essentielles : les attentes du client et l absence de défaut. 83

98 Chapitre 3. Evaluer la qualité : définitions et propriétés La première notion fait référence à l objectif fixé en début de conception d une application : déterminer précisément ce que doit faire le logiciel, déterminer les exigences du client ou encore les particularités éventuelles de fonctionnement. La seconde notion fait référence au savoir-faire des concepteurs du logiciel : comment concevoir un outil fiable et efficace. Déterminer la qualité d un logiciel consiste donc à mesurer deux éléments complémentaires : d une part l adéquation du logiciel avec les objectifs de départ et d autre part le respect de procédures éprouvées, de standards et de règles de programmation permettant de fournir un logiciel le plus exempt possible de défaut. Il faut donc définir précisément ce que l application doit faire et comment elle doit le faire, tant d un point de vue fonctionnel que d un point de vue technique. La qualité d un logiciel est donc une donnée relative aux attentes et aux objectifs et non une mesure absolue. Elle dépend des besoins exprimés par le client et des contraintes techniques qui lui sont propres. Chaque application possède ses particularités, chaque client possède son propre niveau d exigences. Un logiciel embarqué, un jeu vidéo ou un logiciel de gestion par exemple ne répondent pas aux mêmes exigences ou attentes des clients. Evaluer la qualité d un logiciel est donc directement lié à la fonction de celui-ci. De plus, la qualité d un logiciel se reflète non seulement dans les processus de développement mais aussi dans les éléments qui le constituent : la documentation, les tests, la définition des exigences fonctionnelles ou les dossiers de conception. Les règles et objectifs qui vont permettre de mesurer la qualité du logiciel doivent donc couvrir l ensemble de ces éléments. De surcroît, les éléments qualitatifs doivent être établis précisément et dès le début du projet dans le but de les communiquer à l ensemble des acteurs participant au processus de développement du projet. La NASA par exemple, a déterminé un ensemble de procédures, d instructions de travail et de règles pour s assurer que chaque étape du développement s effectue de manière adéquate 8 [Esmond B. Marvray, 2006]. Evaluer la qualité signifie appliquer un ensemble de règles et de mesures afin de calculer la différence entre objectifs attendus et réalisation obtenue. Il faut déterminer : le pourquoi : ce que doit faire une application, le point de vue fonctionnel ; le comment : comment atteindre l objectif, le point de vue technique. Pour parvenir à évaluer la qualité d une application, un modèle doit considérer ces deux points de vue. De plus, nous avons choisi de nous inspirer des recommandations de la norme SQuaRE (voir Section 1.1.3) pour valider le modèle Squale (définir les exigences, établir un modèle de qualité, définir les métriques de la qualité et évaluer la qualité). Nous avons pour notre part déterminé les étapes suivantes : définir une architecture générale de notre modèle, définir le périmètre d évaluation de celui-ci, définir les règles à évaluer, définir les métriques et les données nous permettant de les évaluer, définir comment évaluer les règles. 8. http ://sw-assurance.gsfc.nasa.gov/disciplines/quality/index.php 84

99 3.3. Propriétés et architecture d un modèle de qualité 3.3 Propriétés et architecture d un modèle de qualité Un modèle de qualité doit répondre à l objectif principal d évaluer la différence entre objectifs attendus et objectifs réalisés. Un modèle formalise donc des règles décrivant ce que doit être la qualité et y associe des métriques permettant l évaluation du logiciel en fonction de ces règles L architecture d un modèle de qualité Cette définition posée, nous nous sommes intéressés aux modèles de qualité existants. Ceux-ci sont en général des modèles hiérarchiques qui définissent des facteurs regroupant des principes de qualité des règles. Ces principes reposent eux-mêmes sur des métriques qui permettent l évaluation de ces règles. Les modèles comportent donc souvent plusieurs niveaux de lecture : les caractéristiques autrement appelés facteurs ont été définis pour couvrir l ensemble des aspects de la qualité ISO. Chaque facteur décrit une caractéristique qualité d un domaine, l ensemble des facteurs représente la qualité dans son intégralité. Il s agit par exemple, dans la norme ISO 9126, des caractéristiques de fiabilité ou d utilisabilité. Ce niveau donne un résumé, une synthèse très généraliste de l évaluation de la qualité. Utiles pour cibler les éventuels domaines qui posent problème, les facteurs ne permettent pourtant pas à eux seuls d appréhender la qualité ; les sous-caractéristiques autrement appelées critères qui définissent des règles et des principes qui précisent les facteurs auxquels ils sont rattachés. La norme ISO 9126 par exemple définit la sous-caractéristique conformité comme étant la conformité d une application par rapport aux standards, conventions et règles définis dans le cahier des charges fonctionnel. Ce niveau détaille le précédent mais surtout va plus loin dans l interprétation du modèle. Il s agit ici de décrire des principes qualitatifs. Les critères permettent aux managers d affiner l évaluation qualitative du modèle, ils fournissent une vue plus détaillée, compréhensible et interprétable facilement ; les métriques qui définissent le support dans lequel les niveaux supérieurs puisent pour donner une évaluation qualitative des règles et principes de qualité. Ce niveau se fonde sur les métriques qui correspondent à ce qu utilisent les développeurs ou les testeurs pour déterminer la qualité de leur travail. Il s agit souvent de résultats qui sont difficilement interprétables par des nonspécialistes du domaine. De plus, la manière de les interpréter dépend également du niveau d exigences que requièrt l entreprise et des techniques de conception logicielle. Cette architecture permet de classifier les règles en différents domaines (les facteurs) pour obtenir une vue globale et claire de la qualité. De plus, définir des domaines permet de délimiter précisément le champ d investigation du modèle. Détailler les domaines en principes permet de déterminer quelles sont les notions à prendre en considération pour son évaluation. Cependant, entre ces définitions et les métriques utilisées pour les évaluer, il existe un manque : que traduisent précisément les métriques utilisées? Prenons par exemple le critère complétude fonctionnelle de la norme ISO Celui-ci qualifie la manière dont 85

100 Chapitre 3. Evaluer la qualité : définitions et propriétés un logiciel répond aux besoins. Pour parvenir à évaluer un tel critère, on utilise des mesures telles que le taux de couverture des tests, le taux de réussite des tests ou encore la validation des données de tests. Toutes ces mesures ne fournissent pas directement une évaluation de la qualité. C est la traduction de leur valeur par rapport à un principe technique de base qui détermine le niveau de qualité. Que veut dire un nombre de lignes de code égal à 70 par exemple? Il faut traduire cette donnée brute en terme de qualité pour lui donner du sens (par exemple une méthode de 70 lignes de code est beaucoup trop longue ou acceptable selon les exigences). Les métriques et mesures utilisées pour noter un critère de qualité servent à évaluer les règles techniques de base qui sont sous-entendues dans la définition du critère. Ainsi le critère complétude fonctionnelle repose sur des règles qui déterminent si les tests fonctionnels sont en adéquation avec les besoins (les tests couvrent-ils toutes les exigences?), décrivent la manière dont les tests sont effectués (les tests sont-ils suivis, répertoriés, identifiés?), évaluent la réussite des tests passés (si la fonctionnalité testée est remplie par le logiciel), déterminent si les données utilisées pour les tests remplissent tous les cas de figures (pour une exigence donnée il peut y avoir plusieurs valeurs possibles à tester) ou encore précisent si les éventuelles erreurs détectées sont corrigées. A un critère donné, correspond donc plusieurs règles techniques à considérer. De plus, pour évaluer une règle technique il faut parfois s appuyer sur plusieurs mesures. Par exemple, pour évaluer le fait que les données couvrent toutes les exigences, il faut à la fois mesurer la qualité des données utilisées mais également savoir si les données aux limites sont validées par exemple, si les données sont manipulées correctement ou encore si elles font l objet d une procédure de validation. Ainsi à une règle technique de base correspond plusieurs mesures (taux de couverture des données, validation des données, référencement des données, traçabilité des erreurs, par exemple). C est pour ces raisons que les modèles hiérarchiques en trois couches font difficilement le lien entre les mesures et les critères. Les informations contenues dans les mesures ne sont plus accessibles au niveau des critères. Le modèle Squale a donc introduit un niveau entre les critères et les mesures : les pratiques. Ce niveau permet de décrire précisément les règles techniques qui composent un critère, de préciser les mesures utilisées pour son évaluation mais également de préciser comment les mesures doivent être interprétées en terme de qualité par rapport à la règle technique décrite. Ce niveau constitue le pivot du modèle dans lequel les mesures brutes sont transformées en note de la qualité d une règle technique de base. Nous avons donc retenu l utilité et l importance de ce niveau et nous avons défini de manière formelle les quatre niveaux du modèle Squale : 86

101 3.3. Propriétés et architecture d un modèle de qualité Mesures. Donnée brute qui permet d évaluer un principe de qualité. Ces mesures peuvent être issues de métriques, de règles, ou de documents attachés au projet mesuré. Comme expliqué dans la section 1.2, à un nom de métrique correspond souvent plusieurs façons de mesurer. Il convient donc de reposer l évaluation de la qualité sur des métriques et mesures préalablement définies afin de ne pas fausser les résultats ; Pratiques. Une pratique exprime une règle technique de base. Les bonnes pratiques sont des règles techniques à suivre tandis que les mauvaises pratiques sont des principes à éviter. L ensemble des pratiques d un domaine représente toutes les règles à appliquer pour obtenir une qualité optimum dans ce domaine ; Critères. Un critère est un principe conceptuel de qualité. Il regroupe les pratiques qui lui sont associées et qui décrivent en règles techniques le principe énoncé par le critère ; Facteurs. Un facteur définit un domaine d évaluation de la qualité, un périmètre précis de ce que le modèle analyse. Un facteur regroupe les critères qui constituent les principes conceptuels qui définissent le domaine évalué par le facteur. L ensemble des facteurs donne une vue globale de la qualité du logiciel. La définition des facteurs d un modèle de qualité permet donc de préciser les contours d évaluation de la qualité. Ces quatre couches décrivent deux parties différentes du modèle : le niveau conceptuel composé de facteurs qui délimitent les domaines d évaluation du modèle et de critères qui décrivent les principes conceptuels attachés aux facteurs. Un domaine tel que l évaluation de la qualité du code source, par exemple, sera donc déterminé par plusieurs facteurs qui eux-mêmes seront décrits par des principes généraux répartis en critères. Ce niveau décrit des principes généraux, il est indépendant des exigences de l entreprise ou des particularités du logiciel ; le niveau technique composé de pratiques qui décrivent des règles techniques et qui sont évaluées par des mesures. Ce niveau est étroitement lié aux particularités du logiciel par exemple le langage de programmation et aux exigences de l entreprise par exemple le type de tests que l entreprise effectue sur le logiciel Déterminer le périmètre d évaluation de la qualité Définir la qualité selon deux axes principaux (le pourquoi et le commment) oriente notre modèle de qualité dans deux domaines : la qualité technique et la qualité fonctionnelle. Le premier évalue la qualité selon le point de vue du développement d une application, tandis que le second évalue la qualité selon l angle de la validation fonctionnelle d un logiciel, autrement appelée la qualification fonctionnelle. Nous avons, dans un premier temps, écarté les domaines de la sécurité applicative ou encore celui de l utilisation du logiciel (le point de vue utilisateur), ou bien encore celui de l exploitation logicielle (le comportement d un logiciel dans son environnement d exploitation). Une fois les domaines d évaluation posés, nous devons définir précisément les objectifs de notre modèle de qualité, selon ces domaines. La validation technique implique de formaliser les principes suivants : savoir évaluer la qualité d un code source ; prendre en compte le savoir-faire métier des développeurs ; 87

102 Chapitre 3. Evaluer la qualité : définitions et propriétés vérifier si le code est testé de manière à repérer les erreurs d exécution au plus vite ; vérifier que le code est écrit de manière à pouvoir être facilement modifié en cas d erreurs ; vérifier que le code est écrit de manière à pouvoir évoluer facilement. La validation fonctionnelle implique de formaliser les principes suivants : vérifier que les exigences du client sont correctement définies ; vérifier que le logiciel répond aux exigences de manière adéquate ; vérifier les stratégies mises en place pour valider le logiciel Les propriétés d un modèle de qualité Une fois l architecture du modèle validé et les contours de l évaluation de la qualité posés, nous avons recensé les exigences auxquelles notre modèle doit répondre. Ces exigences reposent à la fois sur nos recherches mais également sur les exigences des partenaires industriels de notre projet de recherche Le modèle doit être exhaustif. Il doit aborder la qualité selon les deux angles de vue identifiés (fonctionnel et technique) à partir des préconisations du swebok [Abran et al., 2004] ; 2. Il possède une partie fonctionnelle. La qualité repose sur la satisfaction des besoins. Les attentes du client doivent donc être considérées de deux manières différentes. Il faut, d une part, qualifier l expression des besoins : déterminer si les besoins sont exprimés en détail et clairement. Il faut, d autre part, déterminer si le logiciel répond aux besoins, comme le préconise la norme Iso 8402 [ISO/IEC, 1994] ; 3. Il possède une partie technique. Notre définition de qualité précise que le logiciel doit être sans défaut d exécution. Il est rare de pouvoir atteindre un tel but. Cependant, pour s en approcher, il faut que l application soit développée en respectant un savoir-faire et des processus de conception logicielle reconnus et validés. Evaluer la partie technique d une application consiste donc à formaliser précisément ce savoir-faire et ces processus et à vérifier que le développement logiciel a suivi ces principes. De plus la notion de qualité implique également que le logiciel puisse évoluer dans le temps, que ce soit pour intégrer des corrections (la maintenance logicielle) ou pour intégrer de nouvelles fonctionnalités (l évolution logicielle). Les règles définies en terme de qualité technique devront donc également tenir compte de ces deux exigences tout comme la NASA le préconise [Esmond B. Marvray, 2006] ; 4. Il possède des règles d évaluation précises. Il doit préciser comment les mesures doivent être prises en compte pour évaluer la qualité. Il s agit ici de déterminer quelles mesures pour quel critère mais également quel résultat pour quelle note, tout comme l indique Plante [Plante, 1994] ; 5. Il est adaptable. Les règles définies ainsi que l évaluation de ces règles doivent prendre en compte les particularités de l application évaluée. Il s agit de définir le savoir-faire technique et les exigences de l entreprise qui accompagnent le type de logiciel évalué dans le but d apporter une aide pertinente à l amélioration de la qualité comme voulu par nos partenaires ; 6. Il reflète objectivement un niveau de qualité. Bien que prenant en compte les particularités du logiciel analysé, les règles définies doivent également être indépendantes du logiciel évalué. En effet, un modèle doit être tout à la fois paramétrable mais également témoin du niveau de qualité. Il faut donc constituer un modèle possédant des niveaux de qualité par défaut qui puissent être adaptables de manière raisonnée, définir des règles générales, adapter

103 3.4. Evaluer la qualité à partir des mesures le niveau d exigences mais également fixer des seuils et limites qui reflètent le plus objectivement possible la qualité. il s agit donc de fixer les exigences comme le préconise la norme SQuaRE [ISO/IEC, 2005] ; 7. Il n est pas un but en soit mais une aide. Ceci rejoint le commentaire de Wiegers qui nous alerte sur le fait que l utilisation de mesures pour motiver plutôt que comprendre, est un piège commun : une mesure n est intrinsèquement ni vertueuse ni mauvaise, tout simplement informative. Utiliser les mesures pour motiver plutôt que pour apprendre peut potentiellement conduire à un comportement dysfonctionnel, dans lequel les résultats obtenus ne sont pas compatibles avec les objectifs visés par la motivation [Wiegers, 1996]. Toutefois, en pratique, et dans toute activité humaine, il est difficile de concevoir un modèle de qualité qui n aura pas tendance à devenir un objectif lui-même. Pour être accepté dans la pratique, un modèle de qualité ne doit pas être uniquement un modèle d évaluation, mais aussi un guide pour améliorer la qualité. Un manager doit savoir si le projet a des problèmes de qualité, tandis que le développeur doit savoir quel composant doit être corrigé. Cela implique que l évaluation permette également une analyse fine des résultats ; 8. Il reflète finement les efforts de qualité. Une évaluation qualitative ne doit pas être vue comme une sanction mais comme un outil d aide à l amélioration. Il faut donc encourager les efforts et les transcrire finement pour encourager les techniciens à utiliser cet outil. Cette propriété permet comme nous avons pu le constater, à travers l usage de Squale dans les entreprises, de faire accepter plus facilement le modèle au sein d une équipe. Ceci permet de définir l outil comme une aide et non comme une sanction ; 9. Il doit diriger les efforts. Le modèle doit fournir une aide à l amélioration de la qualité en mettant en avant les points faibles. Il doit pointer les échecs dans le but de déterminer l orientation des efforts à mener pour augmenter la qualité, que ce soit au niveau du logiciel lui-même ou au niveau des processus de conception. Il s agit là encore d une demande très forte de la part des entreprises, utilisatrices de notre modèle ; 10. Il possède différents niveaux de lecture. Il doit s adresser à tous, techniciens comme décideurs, être une source d information exploitable utilement dans leur métier. Le décideur doit pouvoir en tirer une vue de la qualité du logiciel mais également une vue des performances de ses équipes. Il doit pouvoir l utiliser comme support d amélioration, d harmonisation des processus mis en place. Un technicien quant à lui doit pouvoir naviguer dans le modèle pour déterminer facilement les problèmes à résoudre ou les points à examiner attentivement, par exemple déterminer le module du code source qui doit être testé plus particulièrement ; 11. Il possède des résultats facilement interprétables. Les résultats fournis devront être homogènes et offrir une grille d interprétation simple comme le conseille la norme ISO 9126 [ISO/IEC, 2001]. 3.4 Evaluer la qualité à partir des mesures Nous avons tout d abord recensé les différentes techniques d évaluation les plus utilisées par les modèles de qualité afin de déterminer ensuite si les techniques utilisées par Squale sont plus pertinentes que les autres. Comment donner un sens aux mesures sous l angle de la qualité? Les modèles hiérarchiques attribuent des notes déterminant le niveau de qualité d un logiciel à partir de deux types différents de mesures : les métriques et les données brutes. 89

104 Chapitre 3. Evaluer la qualité : définitions et propriétés Evaluer la qualité à partir de métriques Envisageons tout d abord les métriques. Il se pose deux principaux problèmes. Tout d abord, les métriques sont définies et mesurées pour certains composants du logiciel : la métrique SLOC (nombre de lignes de code source) par exemple est calculée pour une méthode donnée ou encore la métrique DIT (profondeur d héritage) calculée pour une classe donnée. Il n est donc pas aisé de transposer les résultats obtenus pour des composants vers une évaluation qualitative de plus haut niveau. D autre part, les principes qualitatifs tels qu ils sont définis font le plus souvent appel à l utilisation de plusieurs métriques. Par exemple, la norme ISO 9126 définit la sous-caractéristique facilité de modification comme la capacité d un logiciel à intégrer de nouvelles implémentations. Pour mesurer cette propriété, les métriques telles que le nombre de lignes de code (SLOC ), la complexité cyclomatique, le nombre de méthodes par classe, la profondeur d héritage (DIT ) sont combinées de manière à déterminer à partir de toutes ces mesures une seule et unique note pour cette sous-caractéristique. Pour parvenir à évaluer un critère de qualité à partir de métriques il faut donc procéder en deux étapes : la combinaison. La première consiste à combiner les métriques retenues entre-elles. Cette étape qui pourra être exécutée de différentes manières permet d obtenir une note qualitative pour un composant donné : par exemple, en combinant la métrique CLOC avec la métrique V(G) pour chaque méthode d un projet. Nous nommons cette étape la combinaison. On cherche en effet à donner du sens, un sens qualitatif en combinant des mesures différentes ; l agrégation. La seconde étape consiste à agréger ces notes obtenues au niveau de chacun des composants en une note globale pour la totalité du projet. Nous nommons cette étape l agrégation. Celle-ci relève plus d un aspect statistique. On détermine à partir d un ensemble de mesures la valeur générale qui s en dégage. Ces deux étapes peuvent, en théorie, être faites indépendamment l une de l autre et dans n importe quel ordre. En effet, la combinaison de métriques peut s effectuer à différents niveaux : pour chaque composant à partir de chacune des métriques obtenues ou au niveau du projet à partir de métriques déjà agrégées. Prenons l exemple illustré dans le tableau 3.1 : quatre méthodes notées A, B, C et D sur lesquelles les métriques CLOC (nombre de lignes de commentaires) et V(G) (complexité cyclomatique) ont été mesurées. Pour cet exemple, nous utilisons une formule de combinaison de métriques basique, à savoir la multiplication de SLOC par V(G), et une formule d agrégation tout aussi simple, à savoir une simple moyenne. Les résultats rappellent que le résultat final est différent selon que l on procède d abord à la combinaison puis à l agrégation, ou le contraire. Or, nous ne pouvons pas affirmer, d emblée, que le premier résultat est plus pertinent que le second. Nous pouvons tout au plus constater que les deux étapes peuvent être effectuées dans n importe quel ordre. Pour déterminer la pertinence de l ordre, il faut réfléchir au sens de ces deux étapes. La combinaison constitue une étape sémantique : donner un sens pertinent au fait de mélanger plusieurs métriques. Il s agit de qualifier une règle qualitative à partir de métriques ayant un rapport avec cette règle tout en conservant les informations individuelles apportées par chacune des métriques. Prenons l exemple d un critère qui évaluerait la qualité du taux de commentaires d un code. On peut 90

105 Table 3.1 Résultats de deux étapes 3.4. Evaluer la qualité à partir des mesures Méthode Métrique CLOC Métrique V(G) combinaison A B C D agrégation utiliser les métriques CLOC et V(G) : CLOC nous donne l information sur le nombre de lignes de commentaires le taux tandis que V(G) renseigne sur la complexité du code analysé. Combiner ces deux métriques permet alors de donner un sens qualitatif plus fin qu une simple évaluation d un taux de commentaires. On combine ces deux métriques pour évaluer un principe de qualité simple : plus un code est complexe et plus il doit être commenté. L utilisation de ces deux métriques est sémantique. L opération d agrégation constitue, pour sa part, une étape statistique : donner une valeur globale, pour l ensemble d un projet, à un ensemble de mesures. Continuons avec l exemple précédent. Il est tout à fait possible, pour évaluer la règle retenue, d agréger les métriques CLOC et V(G) puis de les combiner ensuite. Dans ce cas de figure, nous obtiendrons une valeur globale, i.e. pour l ensemble du projet, qui évaluera la règle qualitative. Il faut alors considérer un autre élément indispensable : la finesse d évaluation de la règle. Reprenons l exemple précédent. La règle de qualité du taux de commentaires d un code, telle que définie précédemment, peut s envisager sur l ensemble du projet. Cependant, il est plus pertinent de considérer cette règle comme devant s appliquer sur chaque méthode définie dans le code. En effet, les méthodes n ont pas toutes le même niveau de complexité. La règle devient alors, de manière plus fine : plus une méthode est complexe et plus elle doit être commentée. De même, l évaluation de la qualité du taux de commentaires est nettement moins pertinente au niveau d une classe qu au niveau des méthodes qui la composent. Par exemple, une classe peut avoir une méthode très complexe, mal commentée et une méthode très simple et sur-documentée. Dans ce cas l agrégation des métriques donnera une résultat moyen pour les deux (une complexité élevée additionnée à une complexité simple d un côté et un nombre de lignes de commentaires élevé additionné à un nombre de lignes de commentaires faible). Dans ce cas la combinaison ne donnera pas d indication pertinente puisqu elle combinera deux valeurs moyennes (elle ne permettra pas de montrer qu une des deux méthodes n est pas assez commentée). Une méthode déficiente peut se retrouver masquée par d autres méthodes sur-commentées lorsque l on exprime le résultat uniquement au niveau du projet. En revanche, la combinaison en première étape permet de déterminer directement la méthode qui ne correspond pas aux exigences. Calculer les notes au niveau du projet mais également au niveau des composants permet donc de déterminer précisément les composants déficients et les améliorations à apporter au code pour en augmenter la qualité. Ainsi, en partant du principe que la combinaison constitue une étape sémantique et que l agrégation a une valeur statistique, nous retenons l ordre suivant : combinaison puis agrégation des métriques. Effectuer les opérations dans l ordre inverse aboutit en effet à une perte de précision dans l évaluation de la qualité. Il est plus judicieux d évaluer une règle qualitative donnée pour 91

106 Chapitre 3. Evaluer la qualité : définitions et propriétés Table 3.2 Un exemple de transposition discrète de la métrique SLOC dans l intervalle [0; 3]. Valeurs normalisées Interprétation Excellent Acceptable Problématique Mauvais SLOC 35 ]35; 70] ]70; 160] > 160 chaque composant d un logiciel puis d en donner une évaluation globale et statistique plutôt que de déterminer directement une valeur globale qui ne pourrait être individualisée. Notons également que de ces deux opérations peut résulter une perte d information : les valeurs individuelles de chaque métrique sont perdues dans l étape de combinaison, et l évaluation individuelle des composants ne se retrouve pas nécessairement transcrite dans l opération d agrégation. Il faut donc effectuer ces deux étapes avec des opérations ad hoc. Dans le reste de cette section nous détaillons en quoi les méthodes de combinaison et d agrégation utilisées le plus couramment ne permettent pas de répondre de manière satisfaisante aux exigences. Puis nous regardons comment l agrégation de métriques est abordée aujourd hui dans la littérature scientifique. La combinaison de métriques L étape de combinaison des métriques implique de tenir compte des intervalles de mesure de celle-ci, ce qui entraîne deux points importants. Tout d abord, les intervalles des métriques peuvent être totalement différents, par exemple, le critère facilité de modification qui utilise les métriques SLOC, V(G), et DIT. Ces trois métriques ne possèdent pas les mêmes échelles de valeurs. Il faut alors s assurer que la combinaison ne dilue pas les mesures de l une par rapport à l autre. Ensuite, les métriques possèdent toutes leur propre sens : SLOC renseigne sur le nombre de lignes d une méthode, tandis que V(G) nous fournit une information sur la complexité, et DIT qualifie la profondeur d héritage. Ceci impose de les utiliser de manière différente et de faire en sorte de garder le sens des unes par rapport aux autres. Pour y parvenir, la combinaison des métriques doit être élaborée spécifiquement pour chaque critère évalué. Dans la table 3.1 à propos du taux de commentaires d un code, par exemple, l opération de multiplication de CLOC avec V(G) n est pas satisfaisante. Il serait préférable de combiner ces deux métriques plus finement pour traduire le fait que le commentaire doit être mis en perspective avec la complexité, comparer la complexité avec les commentaires sous forme d un seuil, par exemple. La normalisation des résultats Etre capable de combiner plusieurs métriques en un résultat unifié passe par une normalisation des valeurs dans un intervalle donné. Normaliser des valeurs quelconques dans un intervalle donné consiste le plus souvent à appliquer des transformations discrètes sur ce jeu de valeurs. La Table 3.2 nous montre un exemple dans lequel les valeurs cibles normalisées associées à SLOC sont toujours 0, 1, 2 ou 3. Un tel système présente l avantage d être très simple à implémenter et facile à lire mais il n est pas obligatoirement adapté à toutes les mesures. Il constitue le moyen le plus simple de traduire une expertise humaine telles que celles qui constituent les mesures manuelles du modèle Squale mais pose les problème suivants lorsqu il traduit des métriques en valeur de qualité : 92

107 3.4. Evaluer la qualité à partir des mesures les modifications sont masquées. Utiliser des formules discrètes introduit des paliers et des effets de seuil, ce qui masque certains détails et peut fausser l interprétation des résultats. De plus, lorsque l on souhaite surveiller l évolution de la qualité dans le temps, ces valeurs discrètes masquent les fluctuations plus faibles, dans un sens comme dans un autre. Par exemple, si l on prend les valeurs de la Table 3.2, pour un projet donné contenant des méthodes d une moyenne de 150 lignes de code, chaque méthode a une valeur normalisée de 1. Si les développeurs réécrivent certaines méthodes pour les porter à un nombre de 80 lignes de code, la qualité du projet aura alors globalement augmenté ce qui ne sera pas traduit dans la note globale qui reste inchangée du fait des transpositions discrètes appliquées ; une mauvaise influence sur les décisions de ré-ingénierie. Travailler sur les composants dont la note est proche d une valeur seuil nécessite moins de charge de travail et permet d augmenter plus facilement la note globale de la qualité. En revanche, les composants dont la note est plus éloignée d une valeur seuil nécessitent beaucoup plus d effort pour que le bénéfice soit visible d un point de vue note. Pourtant, d un point de vue purement qualitatif et indépendamment de la note, il est plus judicieux de se consacrer aux plus mauvais composants pour augmenter réellement la qualité et corriger les problèmes réels. L intervalle de normalisation des valeurs doit donc être continu par opposition à des valeurs discrètes comme une échelle de Likert [Likert, 1932]. Il est également préférable que cet intervalle soit composé de bornes finies aux deux extrémités pour faciliter les comparaisons. Nous détaillons dans la section les solutions que nous avons apportées pour obtenir des valeurs dans un intervalle continu L agrégation de métriques L étape d agrégation des mesures doit elle aussi être effectuée de manière à ne pas perdre les informations fournies au niveau de chaque composant. Comment faire ressortir le fait qu un élément ne réponde pas aux exigences de qualité lorsqu on se situe au niveau le plus haut? Utiliser des notes globales pour définir la qualité pose également un problème crucial pour les développeurs : comment retrouver les informations livrées par les données brutes à travers une seule note globale? Comment traduire cette note en un problème concret de conception/développement? Cet écueil empêche nombre de développeurs de s intéresser à un modèle de qualité dans son ensemble et ils lui préfèrent encore souvent les métriques de code brutes. Pour fournir une représentation de la qualité à un niveau élevé, le modèle ISO 9126 s appuie sur des métriques, comme décrit dans sa partie 3 [ISO/IEC, 2003]. Cependant, cette description ne donne aucune indication précise quant à la manière d agréger les différentes métriques citées. Une moyenne simple ou pondérée reste souvent le moyen le plus utilisé pour y parvenir. Et pourtant, nous allons voir que les moyennes ne donnent pas entière satisfaction puisqu elles perdent de l information comme cela est souligné par Bieman et d autres chercheurs [Bieman, 1996, Serebrenik et van den Brand, 2010a, Vasilescu et al., 2010a] Moyenne simple La méthode employée pour calculer une note globale sans perdre les informations fournies par les notes individuelles des composants du projet cristallise souvent les points faibles des modèles de 93

108 Chapitre 3. Evaluer la qualité : définitions et propriétés Table 3.3 Les moyennes simples de la métrique SLOC pour quatre méthodes dans deux classes différentes Méthodes SLOC Classe 1 SLOC Classe 2 A B 25 9 C D 24 8 Moyenne qualité. Calculer une simple moyenne n est pas assez précis puisque cela ne permet pas de déterminer l écart type d une population comme illustré ensuite. Elle dilue les valeurs extrêmes au milieu des valeurs moyennes. La Table 3.3 présente le nombre de lignes de code, soit la métrique SLOC, pour quatre méthodes dans deux classes différentes. Dans cet exemple, la moyenne du nombre de lignes de code est de 25.0 pour la classe 1 et de 24.5 pour la classe 2. En partant du fait qu il est préférable pour une classe de posséder des méthodes n ayant pas un nombre trop élevé de lignes de code, ces résultats pourraient amener à croire que la seconde classe est de meilleure qualité que la première (puisque la moyenne est moins élevée) ou du moins que ces deux classes sont sensiblement identiques. Mais cette moyenne masque le fait que la seconde classe possède une méthode A qui est très clairement en dehors des normes. C est pourquoi, bien que la note moyenne soit meilleure, le détail des notes montre que cette seconde classe est pourtant la moins bonne, du moins par rapport aux mesures de la métrique SLOC. La moyenne, parce qu elle lisse les résultats ne représente pas toujours la réalité [Vasilescu et al., 2010a]. Pour être utile, un modèle de qualité doit être un modèle d évaluation mais également un guide pour augmenter la qualité. Un développeur doit pouvoir connaître les composants à améliorer et un manager les points faibles du projet : donner une note globale qui ait du sens, mettre en avant les mauvais composants et les faiblesses d une application. Dans l exemple précédent, un indicateur de qualité approprié devrait pointer du doigt le mauvais résultat de la méthode A en fournissant une note globale plus basse. Une simple moyenne ne pointe pas les mauvais composants et même pire : elle les masque. En effet, si l on prend pour exemple la règle qualitative suivante : les méthodes de plus de 300 lignes de code sont inacceptables, une moyenne simple peut facilement échouer à traduire cette règle pour les raisons susdites. Pour remédier à cet inconvénient, il est souvent décidé d utiliser une moyenne pondérée. Cependant, cette méthode a aussi ses défauts comme nous en discutons dans la suite Moyenne pondérée L idée principale derrière l utilisation d une moyenne pondérée est de mettre en avant les mauvais composants et de détecter s il existe des composants critiques. Intuitivement, il s agit d utiliser l agrégation de métriques comme une alarme : donner une mauvaise note globale lorsqu un composant est mauvais. Le poids est appliqué aux notes individuelles et représente l influence de la note 94

109 Table 3.4 Exemple de poids appliqués sur SLOC. Note 35 ]35; 70] ]70; 160] > 160 Poids Evaluer la qualité à partir des mesures Table 3.5 Les moyennes de deux versions différentes d un même projet Version 1 Version 2 Méthodes SLOC Poids SLOC pondérée A B C D Moyenne Simple/Pondérée Méthodes SLOC Poids SLOC pondérée A B C D Moyenne Simple/Pondérée comparée aux autres. Une première version du modèle Squale mettait ce principe en application : plus une note était mauvaise, plus elle avait un poids fort. Considérons l exemple suivant : la Table 3.4 décrit les poids donnés pour la métrique SLOC dans la première version de Squale. Ces poids ont été choisis pour traduire l intention sous-jacente de pondérer de plus en plus sévèrement les mauvais résultats, selon la courbe représentée par la figure 3.1. Les poids sont multipliés par 3 pour chaque seuil et les valeurs des seuils de la métrique SLOC sont déterminées par les développeurs en fonction de leur savoir-faire : une méthode de moins de 35 lignes est idéale ; une méthode entre 35 et 70 lignes est acceptable ; une méthode entre 70 et 160 lignes est passable ; une méthode de plus de 160 lignes est inacceptable. Les mesures obtenues pour cette métrique sont donc pondérées de plus en plus fortement, avec une valeur extrême de 27, pour augmenter leur influence lors du calcul de la moyenne. La Table 3.5 représente un exemple de résultats obtenus pour la métrique SLOC selon ce principe pour deux versions d un même projet. Par exemple, les poids appliqués pour la méthode C sont différents du fait de la note différente obtenue. Les méthodes B et C illustrent le paradoxe créé par l emploi de cette technique. En effet, alors que la valeur de la métrique SLOC diminue et donc que la qualité augmente, les poids appliqués aux valeurs produisent un effet totalement inverse sur le calcul de la note globale : celle-ci diminue! Dans cet exemple, la moyenne pondérée passe de ( )/40 = à ( )/32 = pour la seconde version car la somme des poids passe de 40 à 32. Le résultat augmente (donc l évaluation de la qualité diminue) alors même que la qualité du code est globalement améliorée. Cet exemple montre que l utilisation d une moyenne pondérée n est pas la méthode adéquate et peut même s avérer totalement inappropriée. Un modèle de qualité doit refléter tous les changements le plus finement possible et avec fiabilité. 95

110 Chapitre 3. Evaluer la qualité : définitions et propriétés Figure 3.1 La courbe des poids pour la métrique SLOC L agrégation des métriques dans la littérature scientifique En dehors de l utilisation des moyennes simples ou pondérées, la littérature scientifique décrit de nouvelles méthodes d agrégation telles que des fonctions d écart médian ou de déviation [Perepletchikov et al., 2007], [Lanza et Marinescu, 2006b], et [Barkmann et al., 2009]. Cependant, ces fonctions, de par leur similarité avec les moyennes, tombent dans les mêmes travers dès lors qu il existe dans les mesures des résultats trop dispersés, ce qui est souvent le cas dans les logiciels d ingénierie [Turnu et al., 2011]. Une alternative est proposée en utilisant la distribution ajustée [Concas et al., 2007], [Serebrenik et al., 2009], [Turnu et al., 2011]. Cette méthode consiste à sélectionner manuellement une famille de distribution bien connue (par exemple le logarithme normal ou l exponentielle) et à ajuster ses paramètres pour approcher les valeurs des métriques analysées. Les paramètres ajustés peuvent être considérés comme des agrégations de ces métriques. Cependant, le processus d ajustement doit être répété à chaque nouvelle mesure et, en outre, il reste encore une controverse majeure, à savoir, par exemple, si la mesure de la taille d un logiciel est distribuée par logarithme normal [Concas et al., 2007] ou double Pareto [Herraiz, 2009] Les indices d inégalité économiques Récemment, un courant a émergé qui vise à utiliser des techniques d agrégation différentes des moyennes, empruntées à l économie : les indices d inégalité. Ces indices sont utilisés en économie pour étudier les inégalités de revenus ou de bien-être d une population [Cowell et Jenkins, 1995, Cowell et Kuga, 1981, Cowell, 2000]. Ces indices économiques analysent des données dont la répartition est similaire à celles des mesures issues de métriques logicielles (répartition très asymétrique) et prennent en compte une grande 96

111 3.4. Evaluer la qualité à partir des mesures quantité de données. Pour ces raisons, Vasilescu, Vasa et Serebrenik ont étudié des fonctions telles que le coefficient de Gini ou l index Theil dans l analyse de métriques pour l évaluation de la qualité logicielle [Vasilescu et al., 2010a], [Vasa et al., 2009a] et [Serebrenik et van den Brand, 2010a]. Serebrenik et Vasilescu ont étudié les indices économiques suivants : l indice de Gini [Gini, 1921], l indice de Theil et la mean logarithmic deviation (MLD) [Theil, 1967], l indice de Atkinson [Atkinson, 1970], l indice de Hoover [Hoover, 1936] (aussi connu sous les noms de coefficient de Ricci-Schutz, ou d index de Robin des Bois) et l indice de Kolm [Kolm, 1976]. Ils ont notamment étudié l indice de Theil sur les résultats de la métrique SLOC appliquée à une version stable de Debian (une distribution Linux). Leur étude a montré que la disparité de résultats de la métrique SLOC est directement corrélée aux packages (i.e., la répartition des packages) et non pas, par exemple, aux différents langages de programmation utilisés [Serebrenik et van den Brand, 2010b]. Leurs travaux nous ont particulièrement intéressés de part leur similitude avec la formule proposée dans le modèle Squale pour agréger des données. Nous avons donc étudié et comparé leur méthode avec celle de Squale, ce qui a fait l objet d un article commun [Mordal et al., 2012]. Les résultats de cette comparaison sont détaillés dans la section Cette étude nous a permis, notamment à partir des propriétés mathématiques des indices économiques, de définir les exigences à retenir pour évaluer la qualité logicielle à partir de métriques (voir section 3.5). La table 3.6 liste les définitions de ces indices appliqués aux valeurs x 1,..., x n. Nous utilisons x pour noter la moyenne de x 1,..., x n et x pour noter la valeur absolue de x. Table 3.6 Définitions des indices d inégalité économiques Indices Définition I Gini 1 2n 2 x n i=1 n j=1 x i x j I α Atkinson 1 1 x ( 1 n ) 1 n i=1 x1 α 1 α i, avec α =? 1 I n ( xi Theil n i=1 x log x ) i x I Hoover 1 2n x n i=1 x i x 1 ) I n MLD n i=1 (log x xi I β Kolm 1 β log [ 1 n n i=1 eβ( x x i) ], avec β =? Propriétés mathématiques des indices d inégalité économiques 97

112 Chapitre 3. Evaluer la qualité : définitions et propriétés Vasilescu a démontré que certaines propriétés mathématiques des indices d inégalité économiques sont pertinentes pour l agrégation de métriques logicielles [Vasilescu et al., 2011a], dont les suivantes : Domaine et intervalle. Les indices ont différents domaines de définition (valeurs d entrée) et différents intervalles de valeur (valeurs de sortie), pas nécessairement compatibles avec les intervalles des métriques agrégées. Rappelons que le domaine d une relation binaire R X Y est un ensemble défini pour tout x X il existe un couple (x, y) R avec y Y. De manière similaire, l intervalle de R est un ensemble pour tout y Y il existe un couple (x, y) R avec x X [Johnsonbaugh, 2001]. Pour simplifier la notation des domaines et intervalles dans la table 3.6, nous écrivons ϕ(x 1,..., x n ) pour indiquer que x i 0 pour tout i, 1 i n, et qu il existe j, 1 j n, tel que x j > 0. De même, nous écrivons R n ϕ pour noter {(x 1,..., x n ) (x 1,..., x n ) R n ϕ(x 1,..., x n )}. Par exemple, le domaine de I Theil, I MLD, et I α Atkinson est Rn ϕ, i.e., ces indices d inégalités ne peuvent être appliqués à des métriques ayant des valeurs négatives telles que l index de maintenabilité [Oman et Hagemeister, 1994]. En outre, l intervalle de I Theil est [0, log n], i.e., la valeur maximum possible dépend du nombre de mesures agrégées. D où, si I Theil est utilisé pour comparer deux applications de taille très différente, il faut tout d abord envisager de normaliser les valeurs, par exemple, en les divisant par log n [Serebrenik et van den Brand, 2010b]. Invariance. L invariance par rapport à l addition signifie que si l on additionne une constante à toutes les valeurs individuelles à agréger, alors, le résultat de la valeur agrégée reste inchangé. De même, l invariance par rapport à la multiplication signifie que si l on multiplie toutes les valeurs individuelles par un facteur constant, le résultat de l agrégation est inchangé [Cowell, 2000]. Ces deux types d invariance sont mutuellement exclusives. Transposabilité (translatability en anglais). A l opposé de l invariance par rapport à l addition, la transposabilité signifie qu additionner une constante à toutes les valeurs individuelles augmente le résultat de la valeur agrégée de la même manière. La transposabilité et l invariance par rapport à l addition sont mutuellement exclusives. Symétrie [Foster, 1983] ou impartialité [Kolm, 1976]. Cette propriété assure que le résultat global ne dépend pas de l ordre dans lequel les éléments sont regroupés. Décomposition [Shorrocks, 1980]. Cette propriété permet d évaluer dans quelle mesure le résultat agrégé peut être attribué à la différence de répartition des sous-systèmes, ce qui est souvent nécessaire pour interpréter correctement les résultats produits au niveau de l application dans son ensemble [Vasa et al., 2009b]. La table 3.7 résume les informations sur les domaines, les intervalles et les propriétés discutées ci-dessus. Décomposition des indices d inégalité économiques. Ces indices ont une propriété de décomposition qui leur confère la possibilité d analyser et d expliquer la diversité de répartition des résultats [Cowell et Jenkins, 1995]. Une telle propriété est utile par exemple, lorsque l on mesure la répartition des inégalités de taille (SLOC ) entre les classes d une application organisée en packages. On peut ainsi essayer d évaluer si les classes disproportionnées sont concentrées seulement dans quelques packages ou réparties sur l ensemble du système. Serebrenik a pu ainsi démontrer que les inégalités mesurées dans les tailles de fichiers de la version Linux Debian Lenny sont davantage dues aux répartitions par packages qu aux différents langages de programmation utilisés [Serebrenik et van den Brand, 2010a]. 98

113 3.4. Evaluer la qualité à partir des mesures Table 3.7 Propriétés mathématiques des indices d inégalité économiques Incide Domaine Intervalle Invariance Symétrie Décomposition I Gini R n x 0 R Oui Non [0, 1 1 n ], si ϕ(x 1,..., x n ) I Theil R n ϕ [0, log n] Oui Oui I MLD R n ϕ R 0 Oui Oui IAtkinson α R n ϕ [0, 1 1 n ] Oui Non I Hoover R n x 0 R Oui Non [0, 1], si ϕ(x 1,..., x n ) I β Kolm R n R 0 + Oui Oui Néanmoins, les indices d inégalité économiques sont fondés sur un certain nombre d hypothèses valables pour les valeurs économiques comme le revenu ou le bien-être, mais pas nécessairement pour les métriques logicielles. Notamment de par le fait qu ils sont avant tout des indicateurs d inégalités, ils ne font aucune différence entre des valeurs toutes faibles ou toutes fortes [Cowell, 2000] : un logiciel dont les valeurs de complexité des composants sont toutes élevées aura la même note qu un autre ayant toutes ses valeurs très faibles, ce qui ne signifie pourtant pas la même chose en terme de maintenance logicielle. Un modèle de qualité efficace doit permettre d alarmer les développeurs et mettre en valeur les problèmes potentiels L agrégation de mesures non issues de métriques La plupart des caractéristiques nécessitent donc la combinaison de plusieurs mesures pour être évaluées. De plus, certaines mesures ne peuvent pas être issues de métriques. En effet, prenons par exemple une caractéristique qui a pour but d évaluer la qualité de la documentation. On va alors s attacher à déterminer s il existe de la documentation, une méthodologie associée à sa rédaction et à sa mise à jour, on regardera également si la documentation est complète et actualisée, etc. Pour tous ces points, il n existe aucune métrique capable d en rendre compte. On fait alors appel à une expertise humaine. Comment dans ce cas, traduire les appréciations humaines pour chiffrer, évaluer la qualité de la documentation? Le modèle Squale Le modèle Squale définit la qualité de la documentation comme étant : la qualité de l ensemble de la documentation technique du projet telle que définie par la méthodologie interne et permettant à un développeur de comprendre rapidement le projet.. L évaluation de la qualité de la documentation est effectuée en suivant ce barème : 0 pour aucune documentation ; 1 ou 2 pour une documentation de mauvaise qualité ; 3 pour une documentation de qualité satisfaisante. L expert chargé de l évaluation doit alors attribuer lui-même une note, juger la qualité de la documentation en fonction de son point de vue. Cette note, n est cependant pas toujours facile à attribuer : juger de la qualité de la documentation nécessite de prendre en compte plusieurs paramètres qu il faut évaluer de manière globale dans ce cas. La personne qui attribue la note doit donc à la fois avoir une vue d ensemble de la documentation, savoir sans indication précise quels 99

114 Chapitre 3. Evaluer la qualité : définitions et propriétés Table 3.8 Liste des propriétés de l exemple qualité de la documentation. Nom Caractéristiques oui non C1 Il existe de la documentation technique 1 0 C2 La documentation est complète 1 0 C3 La documentation est à jour 1 0 C4 Il existe des normes et des règles de mise à jour 1 0 C5 Les règles sont suivies 1 0 C6 La documentation est pertinente 1 0 C7 Les templates sont remplis 1 0 sont les paramètres à prendre en compte pour juger de la qualité mais également décider de ce qui est de bonne ou de mauvaise qualité, le tout ramené à l ensemble du projet. Ceci entraîne les lacunes suivantes : d un expert à l autre, comment savoir s ils incluront les mêmes paramètres dans leur évaluation? comment l expert décide-t-il de la note? Une documentation moyenne a-t-elle le même sens d une personne à l autre? quelle différence entre une note de 1 ou une note de 2? en cas de mauvaise note, comment savoir ce qui a motivé cette note? Est-ce le manque de commentaires ou encore le fait qu ils ne soient pas mis à jour correctement, que la méthodologie n est pas correctement définie ou alors qu elle n est pas respectée? quelle est l importance relative d une caractéristique par rapport à une autre? Finalement, évaluer la qualité de la documentation de manière aussi globale n apporte pas réellement une indication exploitable directement et devant le manque de précision quant à la manière d attribuer la note, on peut alors se demander si celle-ci peut vraiment être prise en considération. Le modèle de McCall Nous avons alors étudié la façon dont McCall évalue de tels critères dans son modèle. Il établit une liste de propriétés qui sont évaluées indépendamment. En appliquant cette même démarche à l évaluation de la qualité de la documentation, nous pouvons définir une liste telle que représentée dans la table 3.8 à prendre en compte pour évaluer la qualité de la documentation. A chaque propriété est associée une des deux valeurs possibles : 1 pour oui et 0 pour non. La note finale de la caractéristique est alors déterminée par rapport à la moyenne des réponses : 3 note de la ième propriété et n le nombre de propriétés. n 1 C i n avec C i la Cependant, imaginons le cas de figure suivant : la documentation est partiellement mise à jour. Dans ce cas l expert devra répondre à la question par non, puisqu elle n est pas totalement mise à jour. Il pourra aussi répondre oui s il estime que la documentation est presque totalement mise à jour. La première réponse entraîne alors une perte d information quant à la progression de la qualité. En effet, la réponse ne pourra passer à oui que si toute la documentation est mise à jour. Les progrès intermédiaires ne seront pas visibles. La seconde réponse entraîne une évaluation faussée. Dire que la documentation est presque totalement mise à jour n est pas la même affirmation que la documentation est totalement mise à jour. Ce type de notation entraîne également des seuils dont nous avons décrits les effets dans la section

115 3.5. Exigences pour l évaluation de la qualité logicielle Table 3.9 Listes des propriétés affinées pour la qualité de la documentation. Nom Caractéristiques oui partiel non C1 Il existe de la documentation technique 1 X 0 C2 La documentation est complète 1 0,5 0 C3 La documentation est à jour 1 0,5 0 C4 Il existe des normes et des règles de mise à jour 1 X 0 C5 Les règles sont suivies 1 0,5 0 C6 La documentation est pertinente 1 0,5 0 C7 Les templates sont remplis 1 0,5 0 Affiner les seuils Pour palier à la difficulté des valeurs intermédiaires, nous pouvons également décider de définir un nouveau tableau 3.9 qui prend en compte les étapes intermédiaires. Même si ce nouveau cas de figure apporte des précisions par rapport au précédent, il ne résout pas tous les problèmes. La progression est toujours dans un intervalle discret avec 3 valeurs au lieu de 2 et a donc les mêmes inconvénients que ceux cités précédemment. De plus, les différentes propriétés, bien que devant sans doute être toutes prises en compte, n ont pas toutes la même valeur. On aurait envie de dire, par exemple, que le fait qu il existe de la documentation est plus important que le fait qu il existe des règles de mise à jour. Plus on veut arriver à évaluer la qualité de manière fine et plus il faut prendre en compte les nuances de ce qui doit être évalué. Pour évaluer une caractéristique qui ne peut être mesurée à partir d une métrique mais qui doit l être à partir d un avis d expert, il faut donc tout d abord établir une liste de propriétés qui la définisse. Il faut ensuite trouver un moyen de traduire l appréciation de l expert en chiffres. Une simple transposition combinée à une moyenne simple bien que donnant une première indication doit cependant être affinée si le modèle de qualité doit être le plus précis possible et traduire le plus objectivement possible la qualité du logiciel. Nous détaillons dans la section 5.3 la solution que nous proposons d apporter dans le modèle Squash. 3.5 Exigences pour l évaluation de la qualité logicielle Comme le souligne Rosenberg, quand les métriques sont utilisées pour évaluer un projet, il n y a aucun guide permettant d interpréter leurs résultats. Le plus souvent l interprétation des résultats repose sur le sens commun et l expérience [Rosenberg, 1998]. Déterminer ce qui est acceptable dépend donc de l expérience des techniciens et des exigences de l entreprise. Par exemple, certaines entreprises exigent que la profondeur d héritage n excède pas un certain seuil tandis que d autres préfèrent se préoccuper davantage de l architecture générale du code ou encore de l application des normes de codage. Par conséquent, nous soulignons que pour évaluer la qualité de manière adéquate il convient de prendre en compte l organisation, les spécificités et les exigences des entreprises. 101

116 Chapitre 3. Evaluer la qualité : définitions et propriétés Nous identifions à présent les exigences qui doivent être satisfaites pour parvenir à agréger des mesures avec succès. Ces besoins sont issus à la fois de nos recherches mais également de l expérience industrielle de nos partenaires lors de la construction de notre modèle. Ces exigences sont classées selon trois critères doit, devrait et pourrait afin de les classer selon leur niveau d importance (cf. [Stapleton, 1997]). Les exigences doit sont imposées par notre perception de la façon dont les mesures doivent être utilisées, selon deux étapes, la combinaison et l agrégation ; les exigences devrait et pourrait reposent sur les propriétés de techniques d agrégation dans la littérature et notre expérience avec l aide du modèle Squale dans l industrie. doit : Pour évaluer la qualité de manière pertinente, un modèle devrait : combinaison : doit combiner différentes métriques qui ont toutes des échelles de valeurs différentes pour les transposer dans un intervalle unique, comme cela est expliqué dans la section ; agrégation : doit agréger les résultats des bas niveaux (par rapport au niveau des composants logiciels individuels comme les classes ou les méthodes) à un niveau supérieur (par exemple, un sous-système ou l ensemble d un projet) pour évaluer la qualité d un projet dans son ensemble, tel que discuté dans la section ; domaine et intervalle de combinaison/agrégation de mesures : doit prendre en compte le fait que l échelle de valeurs de la première étape (la sortie) doit être compatible avec le domaine (l entrée) de la seconde étape, que la combinaison soit faite avant l agrégation (comme recommandé dans la section 3.4), ou l inverse. Par exemple, si la formule d agrégation contient un logarithme, la méthode de composition doit avoir une portée strictement positive ; mettre en évidence des problèmes : devrait être plus sensible aux valeurs problématiques dans le but de les repérer, et aussi de fournir une forte rétroaction positive quand les problèmes sont corrigés, comme nous l avons vu dans la section ; ne pas masquer les progrès : devrait ne jamais aboutir à une aggravation de l évaluation (par exemple comme expliqué dans les sections , et ). décomposition : devrait être décomposable (tel que discuté dans la section ) afin de déterminer dans quelle mesure la valeur agrégée au niveau du système peut être expliquée par un partitionnement particulier du système en sous-systèmes [Cowell, 2000, Serebrenik et van den Brand, 2010b] ; combiner avant d agréger : devrait effectuer les deux étapes dans cet ordre. La combinaison devrait être effectuée au niveau des composants individuels pour conserver la sémantique comme cela a été discuté dans la section 3.4) ; intervalle de l agrégation : devrait avoir un intervalle d agrégation des mesures dans une échelle continue, de préférence délimitée (bornée à gauche et à droite) (voir la section 3.4.1) ; Symétrie : devrait parvenir à un résultat final indépendant de l ordre des éléments regroupés (voir la section ). Cette exigence n est généralement pas applicable pour la combinaison. Prenons par exemple, la combinaison des deux métriques suivantes : SLOC la taille et V(G) la complexité cyclomatique. On ne peut guère s attendre à une combinaison de fonctions f telle que f(sloc, V (G)) = f(v (G), SLOC ) ; pourrait : 102

117 3.6. Conclusion normalisation de l évaluation : pourrait normaliser tous les résultats (métriques, combinaison, agrégation) pour permettre une interprétation unifiée à tous les niveaux (voir la section 3.4.1) ; invariance et transposabilité : pourrait à la fois posséder ces deux propriétés d invariance et de transposabilité. Elles sont intéressantes, par exemple pour SLOC, si le même header (contenant les informations de licence) est ajouté à toutes les classes (invariance par rapport à l addition et transposabilité), ou si le pourcentage de la somme des SLOC est pris en compte dans les calculs plutôt que le nombre lui-même (invariance par rapport à la multiplication). 3.6 Conclusion Pour évaluer la qualité nous avons tout d abord cherché à définir précisément ce que sous-entend le terme de qualité en matière de logiciel. Puis, en nous inspirant des étapes préconisées par la norme SQuaRE, nous nous sommes tout d abord attachés à définir les étapes que nous jugeons indispensables pour construire un modèle de qualité. La première étape consiste à définir une architecture générale de notre modèle. Les modèles de qualité de type hiérarchiques correspondent le mieux à ce que nous souhaitons pouvoir obtenir d un modèle de qualité : une vue à la fois globale de la qualité mais également détaillée. La seconde étape consiste à définir le périmètre d évaluation du modèle. Nous avons retenus deux domaines principaux, l évaluation de la qualité de développement et celui de la validation fonctionnelle, du fait également des projets de recherche sur lesquels nous avons été amenés à travailler. Nous avons également déterminé un certain nombre de propriétés que nous souhaitons voir satisfaites par notre modèle pour répondre aux différentes exigences d évaluation de la qualité. La troisième étape définit les règles à évaluer dans ces deux domaines ainsi que les mesures qui correspondent à ces règles. Cette démarche est totalement liée au type de logiciel évalué et aux processus mis en place dans l entreprise. Elle permet de définir les pratiques et les mesures du modèle. La quatrième étape consiste à déterminer comment évaluer les règles à partir des mesures de manière pertinente. Après avoir étudié les points faibles des techniques d agrégation les plus utilisées, nous avons défini une liste d exigences que devront valider les techniques d évaluation du modèle ainsi que les deux étapes à suivre : la combinaison et l agrégation des mesures. Nous avons donc construit un modèle de qualité à partir de ces différentes étapes que nous présentons dans le chapitre suivant. 103

118 Chapitre 3. Evaluer la qualité : définitions et propriétés 104

119 Chapitre 4 Présentation du modèle Squash Sommaire 4.1 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 Ce chapitre présente le modèle de qualité que nous avons formalisé à partir du modèle Squale : le modèle Squash. Le modèle Squash est issu de nos travaux sur le modèle Squale et du second projet de recherche auquel lequel nous avons collaboré, nommé Squash pour Software QUality ASsurance enhancement. Ce projet a eu pour objet de structurer et d industrialiser les tests fonctionnels et logiciels. Les objectifs répartis en quatre axes ont été définis de la manière suivante : intégrer les tests au sein du modèle de qualité Squale dans le but d améliorer la mesure de la qualité, constituer un référentiel pédagogique autour des métiers du test, développer un outillage permettant d optimiser la réalisation des tests et fournir une méthodologie outillée de mise en œuvre des activités de test dans le cadre d un centre de service de qualification logicielle. Ce projet a permis de formaliser l évaluation de la qualité de la validation fonctionnelle et de définir une nouvelle version du modèle le modèle Squash. L entreprise Henix a été le porteur du projet, en collaboration avec les partenaires Generali, Kalis, l équipe Inria Nancy et le laboratoire LIASD de l université Paris 8. Il s agissait également d un projet de recherche FUI financé en partie par la région Île-de-France. Nous été personnellement en charge de la définition du modèle Squash ainsi que de l intégration des données de validation fonctionnelle dans le modèle et de la mise à niveau du modèle par rapport à la norme SQuaRE (voir Section 1.1.3). Pour construire le modèle Squash nous avons suivi les étapes définies dans la section 3.2 : définir une architecture générale du modèle (Section 4.1), définir le périmètre d évaluation de celui-ci le niveau conceptuel (Section 4.2), définir les règles à évaluer ainsi que les métriques et les données nous permettant de les évaluer le niveau technique (Section 4.3). 105

120 Chapitre 4. Présentation du modèle Squash 4.1 L architecture de Squash Le modèle Squash est construit selon la même hiérarchie que Squale : il possède quatre couches réparties en deux niveaux. Chaque couche est définie telle que décrit dans la Section 3.3. Les deux niveaux ont également été définis en détail dans cette même section : Le niveau conceptuel composé par les facteurs qui représentent le niveau le plus haut du modèle. Un facteur définit un domaine d évaluation de la qualité. L ensemble des facteurs fournit une vue globale de la qualité du logiciel ; les critères qui représentent des principes conceptuels de qualité qui détaillent les domaines identifiés par les facteurs. le niveau technique composé par les pratiques qui représentent les règles techniques qui détaillent les principes définis dans les critères. Pour un critère donné, les pratiques qui le composent détaillent l ensemble de règles techniques à appliquer pour obtenir une qualité optimum pour ce principe conceptuel ; les mesures qui permettent d évaluer les règles définies dans les pratiques. Nous avons toutefois ajouté un niveau supplémentaire, pour plus de lisibilité : les sous-facteurs. Ce niveau supplémentaire a été ajouté pour permettre de mieux appréhender en un seul coup d oeil les propriétés liées à un sous-domaine. Ce niveau constitue simplement une aide à la lecture du modèle, il regroupe quelques principes de qualité définissant un sous-domaine, rattaché au domaine défini par le facteur. Par exemple, le sous-facteur tests fonctionnels regroupe tous les critères se rattachant au sous-domaine des tests fonctionnels, lui même rattaché au facteur Adéquation fonctionnelle. Ce niveau permet à nos partenaires du projet Squash, spécialisés en qualification logicielle de retrouver facilement et rapidement les informations auxquelles il souhaitent avoir accès en priorité. La figure 4.1 montre une vue du modèle Squash tel qu il est défini actuellement. Nous avons défini les facteurs et les critères de Squash à partir de la définition du modèle Squale mais également des normes ISO 9126 et SQuaRE. Les pratiques ont fait l objet d une première étude détaillée qui a permis de définir précisément les pratiques de code, de modèles et de normes et standard [Balmas et al., 2010]. Cette étude a également mis en avant les lacunes de certaines pratiques. Elle a ensuite été complétée par la formalisation des pratiques de tests et documentaires [Mordal et Bouquet, 2012]. 4.2 Le niveau conceptuel de Squash Nous avons défini le périmètre d évaluation de la qualité dans la Section A partir de cette analyse, nous avons orienté nos recherches dans ces deux domaines : la validation technique du code et la validation fonctionnelle. Cependant, le modèle Squale se proposait d être un modèle exhaustif qui couvre tous les domaines de conception d une application, depuis la définition des besoins jusqu à l utilisation de celui-ci. Il a donc été défini pour couvrir les domaines suivants : le domaine fonctionnel qui regroupe la définition des besoins mais également la validation du logiciel par rapport à ces besoins ; le domaine technique qui regroupe tout ce qui concerne l implémentation du logiciel, depuis sa modélisation jusqu à l écriture des lignes de code ; 106

121 4.2. Le niveau conceptuel de Squash Simplicité taille d'une méthode nombre de méthodes code Spaghetti Profondeur d'héritage Maintenabilité Portabilité Normes et standard : traçage Normes et standard : portabilité Dépendance cyclique Interdépendance couplage afférent couplage efférent Capacité de réutilisation Stabilité Gestion des exceptions Normes et standard : traçage Gestion des anomalies Gestion des anomalies après tests Maturité des tests Gestions des versions Documentation technique normes et standard : documentation qualité de la documentation taux de commentaires Capacité de d'évolution Tests développement Couverture tests unitaires Couverture des tests d'intégration Cycle de vie des tests développement Taux de réussite des tests unitaires Taux de réussite des tests d'integration Exigences des tests unitaires Stratégie des tests d'intégration Homogénéité normes et standard : programmation normes et standard : convention de nommage normes et standard : gestion de configuration normes et standard : mise en forme Fiabilité Exploitabilité dossier de production Exigences système Données système Couverture des données système Couverture de tests d'intégration système Tests d'intégration système Tests de configuration/ installation Couverture des tests configuration Modularité couplage efferent cohésion de classe couteau suisse copier coller Normes de performances Normes et standard : traçage normes et standard : portabilité Modélisation diagramme de modélisation conformité entre modélisation et implémentation prédétection d'antipatterns Raisonnement par les modèles Modularité de l'architecture dépendance cyclique découpage en couches niveau d'abstraction et de stabilité Pertinence de l'architecture choix des technologies design-pattern organisation générale du code dossier d'architecture technique Profondeur d'héritage Respect de l'architecture respect de l'architecture en couches correspondance entre couches et nommage Architecture conduite de projet Performances Adéquation fonctionnelle tests fonctionnels Tests applicatif Exigences applicatif Données applicatif Couverture des données applicatif Tests de performance Couverture de tests performance Tests de montée en charge Couverture des tests de montée en charge Tests de robustesse Couverture des tests de robustesse Tests fonctionnels Exigences fonctionnelles Rédaction des cas de tests fonctionnels Couverture des cas de tests fonctionnels Données de tests fonctionnels Données aux limites Taux de réussite des tests fonctionnels Taux de couverture des tests fonctionnels Couverture des données fonctionnelles Cycle de vie des tests fonctionnels tests d'acceptation Automatisation des tests Données de tests automatisés Couverture des données tests automatisés Testabilité de l'application Cycle de vie des tests auto Maturité des test auto Tests automatisés Formalisation de la stratégie de tests Définition de la campagne de tests conformité entre la stratégie et les tests Validation de la campagne de tests Données de tests Couverture des données de tests Définition des besoins des données Qualité de l'échantillonnage Facteurs Données anonymisées Sous-Facteurs Critères Pratiques normes et standard Exigences Extraction des exigences criticité des exigences catégorisation des exigences cycle de vie des exigences Taux de couverture tests d'acceptation Stratégie des tests de non régression Taux de couverture des tests de non régression Pratiques de code Pratiques modèles Pratiques documentaires Pratiques tests Figure 4.1 Une vue du modèle Squash. Organisation ALM(application life cycle management) Plan d'assurance qualité Validation du cahier des charges Stratégie de validation et d'homologation du logiciel Sécurité Tests sécurité Exigences sécurité Données sécurité Couverture des données sécurité Tests d'intrusion Couverture de tests d'intrusion Normes de sécurité Respect des règles de l'entreprise : dossier de conception technique Respect partie sécurité du cahier des charges conformité implémentation/ définition sécurité Normes et standard : sécurité 107

122 Chapitre 4. Présentation du modèle Squash le domaine de la production qui regroupe la mise en service du logiciel ainsi que les aspects ayant trait à la sécurité. Nous avons donc conservé ces trois domaines : le domaine fonctionnel a fait l objet d une étude lors du projet de recherche Squash, tandis que le domaine technique a été couvert par le projet de recherche Squale. Le domaine de la production, quoique pris en compte, n a pas encore fait l objet d une étude approfondie. Nous avons exclu de notre modèle l aspect utilisation, à savoir la satisfaction de l utilisateur du logiciel. En effet, nous avons estimé que ce domaine doit faire l objet d une étude de la qualité séparée pour deux raisons essentielles : d une part l importance de celui-ci et d autre part le fait que pour déterminer la qualité sous l angle utilisateur les outils employés ne sont pas les mêmes que pour les autres domaines cités. De plus, notre but était de concevoir un modèle qui pourrait déterminer la qualité du logiciel au plus tôt dans la conception de celui-ci. Or, l utilisation arrive après la conception et ne recouvre pas les mêmes considérations. Après avoir défini les facteurs et les critères de Squash, nous expliquons en quoi ceux-ci couvrent les domaines définis précédemment Les facteurs de Squash Les sept facteurs définis dans le modèle Squash sont fondés sur les facteurs des normes ISO 9126 et SQuaRE et modifiés en fonction du savoir-faire et des validations empiriques effectuées lors des projets de recherche Squale et Squash, avec les entreprises Air France-KLM, PSA Peugeot-Citroën et Generali Définition des facteurs de Squash Nous donnons la définition de chaque facteur ainsi que la liste des critères (détaillés dans la section suivante) qui les composent : adéquation fonctionnelle couvre le domaine de la validation fonctionnelle d une application. Ce domaine peut être scindé en deux parties : d une part, l adéquation des fonctionnalités offertes par l application avec les besoins implicites ou explicites exprimés par la maîtrise d ouvrage, d autre part, les processus mis en place pour effectuer les opérations de validation fonctionnelle. Pour cette raison, il contient deux sous-facteurs complémentaires, à savoir, la Conduite de projets qui définit la qualité des stratégies mises en place pour la validation du logiciel et la description des fonctionnalités générales et les Tests fonctionnels qui définissent la qualité des tests eux-mêmes. L évaluation de ce facteur est donc réparti comme suit : conduite de projets : organisation ALM (pour Application Lifecycle Management ou gestion du cycle de vie des applications) exigences données de tests Ce sous-facteur regroupe les notions d organisation générale des processus de validation fonctionnelle autour du projet : l organisation de la validation d une part mais également la validation des exigences fonctionnelles et la gestion générale des données de tests qui serviront à vérifier l adéquation du projet par rapport aux exigences fonctionnelles ; 108

123 4.2. Le niveau conceptuel de Squash tests fonctionnels : formalisation de la stratégie de tests automatisation des tests tests fonctionnels Ce sous-facteur regroupe les règles de gestion des tests fonctionnels : la formalisation des tests, leur automatisation et le résultat des tests fonctionnels eux-mêmes. Ce facteur regroupe donc tous les processus et étapes qui valident la qualité de l application d un point de vue fonctionnel : gestion des processus de validation fonctionnelle, des exigences, des données de tests et des tests fonctionnels ; fiabilité mesure l aptitude du logiciel à maintenir son niveau de service et de stabilité dans des conditions précises et pendant une période déterminée mais également le taux de confiance dans le code source via les tests structurels. Il est détaillé par les critères suivants : stabilité exploitabilité test développement Ce facteur détermine la qualité d un point de vue stabilité de l application. Pour être fiable, une application doit résister correctement aux défaillances potentielles et respecter les procédures définies par l équipe d exploitation. Son code source doit également faire l objet de procédures de tests formalisées et complètes ; performances mesure les performances de l application par rapport aux ressources utilisées dans des conditions préalablement déterminées. Il est détaillé par les critères suivants : exploitabilité tests applicatifs normes de performance Ce facteur qualifie la performance en termes de respect des règles d exploitation et des règles de performances liées à l entreprise et au logiciel ainsi que des tests effectués en condition réelle d utilisation par rapport au système sur lequel il est installé ; maintenabilité mesure l aptitude d un logiciel à faciliter la localisation et la correction d erreurs résiduelles. Il s agit ici de correction de défauts de non-conformité par rapport aux spécifications et non de défauts provenant d une mauvaise expression des besoins. Il est détaillé par les critères suivants : simplicité interdépendance homogénéité documentation technique Ce facteur est qualifié en fonction de règles qui déterminent si le code source du logiciel est simple, facile à comprendre grâce à sa documentation, si les modules qui le composent sont suffisamment indépendants pour évoluer facilement et si le code source dans son ensemble est homogène ; capacité d évolution mesure l aptitude d un logiciel à faciliter l adjonction de nouvelles fonctionnalités. Il est complémentaire au facteur maintenabilité (qui mesure la facilité de corrections) en mesurant la facilité de modification d un logiciel dans le cadre de son évolution : la définition des besoins fonctionnels du logiciel change dans ce cas, contrairement au cas de la maintenabilité. On distingue notamment dans ce facteur un sous-facteur qui caractérise les particularités liées à l architecture du logiciel. Cette sous-partie est nommée Architecture et se définit de la sorte : représente le niveau de qualité de l architecture technique du projet, non seulement au 109

124 Chapitre 4. Présentation du modèle Squash niveau des choix que de son respect effectif au sein des livrables. Il est détaillé par les critères suivants : architecture : modélisation modularité de l architecture pertinence de l architecture respect de l architecture Ce sous-facteur qualifie l architecture technique de l application ; documentation technique homogénéité modularité tests développement Ce facteur détermine la capacité d un logiciel à intégrer de nouvelles fonctionnalités par rapport à la qualité de la modélisation du logiciel, d une part et par rapport à la qualité de la documentation, l homogénéité, les tests sur le code source et la modularité de ses composants, d autre part ; capacité de réutilisation mesure la facilité de réutilisation de tout ou partie du logiciel sur un autre projet, quel que soit l environnement technique et fonctionnel cible. Il est détaillé par les critères suivants : portabilité documentation technique interdépendance stabilité Ce facteur détermine la capacité d un logiciel à être réutilisé en fonction de la qualité de sa documentation, la capacité à se déployer sur différents systèmes, sa capacité à faire face aux défaillances et l interdépendance des modules de l application les uns par rapport aux autres ; sécurité mesure les aspects sécuritaires de l application et l adéquation des protections par rapport aux exigences spécifiées préalablement. Il est détaillé par les critères suivants : tests sécurité normes de sécurité Ce facteur défini la qualité selon deux grands axes : le respect des normes mises en place dans l entreprise et les tests effectués sur l application pour valider son respect des règles de sécurité. La répartition des critères en fonction des facteurs dans Squash est présentée dans la figure 4.3 en page 114. Celle-ci est le résumé de la figure 4.1, à savoir, elle ne contient que les facteurs et les critères Comparaison de Squash avec les normes ISO 9126 et SQuaRE La figure 4.2 montre les évolutions des facteurs entre la norme ISO 9126 et la norme SQuaRE mais également les différences entre les facteurs définis dans ces normes et les facteurs définis dans Squash : Les facteurs capacité fonctionnelle et adéquation fonctionnelle sont similaires. Ce facteur qui qualifie la partie fonctionnelle de l application est identique dans Squash ; les facteurs fiabilité et maintenabilité se retrouvent dans les trois modèles ; le facteur portabilité de ISO 9126 a été scindé en deux dans SQuaRE : portabilité et compatibilité. Ils ont été exclus du modèle Squash dans un premier temps. Toutefois le facteur capacité de 110

125 4.2. Le niveau conceptuel de Squash Iso 9126 SQuARE Squash Capacité fonctionnelle Adéquation fonctionnelle Adéquation fonctionnelle Fiabilité Fiabilité Fiabilité Maintenabilité Maintenabilité Maintenabilité Portabilité Portabilité Capacité de réutilisation Capacité d'évolution Performances Performances Compatibilité Sécurité Sécurité Facilité d'utilisation Facilité d'utilisation Rendement Figure 4.2 Comparaison entre les facteurs de ISO 9126, de SQuaRE et du modèle Squash réutilisation intègre dans ses critères des notions similaires au facteur compatibilité mais sans être totalement semblable. Ces deux facteurs doivent faire l objet d une étude plus approfondie afin d intégrer le modèle Squash dans ses prochaines versions ; le facteur capacité de réutilisation, défini uniquement dans Squale et repris dans Squash, a pour objet de faire ressortir qu un code de qualité doit pouvoir être utilisé, du moins pour partie, dans d autres logiciels. Nous avons choisis d évaluer cette propriété comme un facteur du fait des différentes mesures à prendre en compte pour évaluer cette propriété mais également du fait de son importance dans la conception d un logiciel ; le facteur capacité d évolution, défini également uniquement dans Squale a été repris dans Squash. Il détermine la capacité d un logiciel à intégrer de nouvelles fonctionnalités. Là encore, cette propriété se retrouve dans les normes ISO 9126 et SQuaRE sous forme de souscaractéristiques. Cependant, cette propriété nous apparaît comme un domaine à part entière 111

126 Chapitre 4. Présentation du modèle Squash de la qualité et non pas une sous-caractéristique d un domaine. Nous avons donc choisi de la définir comme facteur dans notre modèle ; le facteur rendement a été renommé performances dans la norme SQuaRE et se retrouve dans Squash ; le facteur sécurité défini dans la norme SQuaRE a été également conservé dans le modèle Squash ; le facteur facilité d utilisation n a pas été repris dans Squash. En effet, nous estimons que ce facteur qui qualifie la facilité d utilisation du logiciel doit faire l objet d une évaluation à part entière, en dehors du modèle. D autre part, le modèle Squash a pour objectif d évaluer la qualité d un produit le plus tôt possible dans son cycle de développement. Or ce facteur ne peut être évalué qu une fois le logiciel totalement fini et dors et déjà en production. Nous avons donc privilégié l évaluation des descriptions fonctionnelles et de l adéquation de l application par rapport aux besoins exprimés en amont plutôt que l adéquation du logiciel en aval Les critères de Squash Les critères actuellement définis dans le modèle Squash se fondent à la fois sur les souscaractéristiques définies dans les normes ISO 9126 et SQuaRE mais également sur le travail précédent mené par les entreprises Air France-KLM et PSA Peugeot-Citroën qui ont participé au projet de recherche Squale. Ces critères proviennent donc à la fois d une étude théorique mais également d une validation empirique à partir des savoir-faire et des méthodes de travail en entreprise Définition des critères de Squash Actuellement, le modèle Squash est composé de vingt-trois critères définis comme suit : organisation ALM, ALM pour Application Lifecycle Management" ou gestion du cycle de vie des applications, qualifie la gestion globale du projet, depuis la validation des fonctionnalités jusqu à la validation des différentes étapes de développement du logiciel et la gestion des ressources et planning ; exigences correspond aux besoins exprimés par le client. Qualifie la qualité de la définition et de la gestion des exigences, à la fois les exigences exprimées mais également les exigences sous-jacentes à un projet ; données de tests qualifie la qualité et la gestion des données de tests (données utilisées pour effecteur les tests) ; formalisation de la stratégie de tests qualifie la manière dont est formalisée et définie la stratégie de tests ; automatisation des tests qualifie la qualité des tests automatiques ; tests fonctionnels obtenus ; vise à qualifier les scénarios de tests fonctionnels et à observer les résultats stabilité qualifie l aptitude d une application à faire face aux défaillances potentielles ; exploitabilité qualifie le niveau d exploitabilité de l application en termes de documentation et de respect des procédures de mise en production et de suivi de production ; 112

127 4.2. Le niveau conceptuel de Squash tests développement qualifie l ensemble des tests effectuées par l équipe de développement. Qualifie le processus de production de tests (unitaires, d intégration) et les résultas obtenus dans les phases de réalisation, recette technique et intégration ; tests applicatifs qualifie la qualité et les résultats des tests liés à la mise en service de l application, à son exploitation : la charge et la robustesse par exemple ; normes de performance qualifie le respect des normes de performance et de traçage que doit respecter une application ; simplicité qualifie la lisibilité et la facilité de diagnostic du code source, hors documentation ; interdépendance qualifie le niveau de dépendance des éléments d une application les uns envers les autres. Un niveau trop élevé d interdépendance affecte l impact des modifications du code ; homogénéité qualifie le niveau d homogénéité du codage au sein du projet, à savoir le respect des normes de programmation, les conventions de nommage, la mise en forme ; documentation technique qualifie la facilité pour un développeur à comprendre rapidement la logique globale du code grâce à la documentation technique du code ; modélisation évalue la qualité de modélisation du projet et la conformité entre les modèles produits et le code implémenté. Permet de s assurer de la maîtrise et de l utilisation des techniques de modélisation ; modularité de l architecture qualifie la pertinence de l architecture pour obtenir un découpage adéquat des composants dans des perspectives d évolution et de réutilisation ; pertinence de l architecture qualifie les choix architecturaux et leur pertinence par rapport à l état de l art dans le domaine et les technologies choisies ; respect de l architecture vérifie le niveau de conformité de l architecture par rapport à ce qui a été défini au préalable ; modularité qualifie la composition d une application en éléments de taille limitée ; portabilité qualifie la portabilité, la packaging et la facilité de déploiement de tout ou partie d une application ; tests sécurité qualifie les tests et leurs résultats qui ont trait à la sécurité ; normes de sécurité qualifie de respect des normes de sécurité de l entreprise. La figure 4.3 illustre la manière dont les critères de Squash décrivent les facteurs du modèle Comparaison des critères de Squash et de Squale Les critères définis dans le modèle Squale ont été validés, renommés ou redéfinis comme suit : les critères simplicité, exploitabilité, homogénéité, modélisation, stabilité, modularité, respect de l architecture, pertinence de l architecture, modularité de l architecture gardent la même définition dans les deux modèles. Ils ont été validés empiriquement par Air France-KLM et PSA Peugeot-Citroën. De plus pour certains d entre eux, ils correspondent également à des critères définis dans les normes ISO 9126 ou SQuaRE ; le critère capacité d intégration devient interdépendance. Il garde cependant la même définition ; le critère compréhension devient documentation technique. La définition de ce critère se modifie également : ce critère vise à qualifier désormais uniquement la documentation et non plus la 113

128 Chapitre 4. Présentation du modèle Squash Maintenabilité Simplicité Interdépendance Documentation technique Homogénéité Capacité de réutilisation Documentation technique Interdépendance Portabilité Stabilité Capacité d'évolution Documentation technique Homogénéité Modularité Tests développement Architecture Fiabilité Stabilité Tests développement Exploitabilité Performances Normes de performances Exploitabilité Tests applicatif Adéquation fonctionnelle Conduite de projets Organisation ALM Exigences Données de tests Sécurité Normes de sécurité Tests de sécurité Modélisation Tests fonctionnels Modularité de l'architecture Pertinence de l'architecture Respect de l'architecture Tests fonctionnels Automatisation des tests Formalisation de la stratégie de tests Figure 4.3 Les critères du modèle Squash. compréhension générale d un module qui pour sa part se trouve évaluée grâce à la documentation technique et à la simplicité. Nous avons préféré de système de découpage pour permettre de mettre en valeur la qualité générale de la documentation ; le critère sécurité est devenu un facteur comme le préconise la norme SQuaRE ; le critère tests techniques devient tests de développement. Il prend en compte désormais uniquement les tests structurels. Nous avons ajoutés les critères suivants :organisation ALM, exigences, données de tests, formalisation de la stratégie de tests, automatisation des tests, tests fonctionnels, tests applicatifs et tests sécurité qui qualifient et formalisent le domaine fonctionnel de manière plus précise. Les critères normes de sécurité, portabilité et normes de performance viennent renforcer pour leur part le domaine de la sécurité Validation du périmètre d évaluation Les facteurs et critères de Squash se répartissent selon les trois domaines cités précédemment dans la Section 4.2. Le domaine technique Nous rappelons que le domaine technique englobe tout ce qui a trait au code lui même : l écriture du code, son architecture, son évolution. Les facteurs suivants s emploient à définir la qualité dans ce domaine : la maintenabilité, la capacité d évolution et la capacité de réutilisation. La maintenabilité fait référence directement à la partie technique de l application : son code source. Un logiciel doit pouvoir être maintenable, c est-à-dire facilement corrigé en cas d erreurs (que ce soient les corrections de bogues, comme les corrections d erreurs d implémentation par rapport aux exigences fonctionnelles) pour pouvoir prétendre être un logiciel de qualité qui continuera à être utilisé dans le temps. Nous avons considéré la maintenabilité uniquement sous l angle de la compréhension du code source : simplicité, interdépendance, documentation technique et homogénéité. 114

129 4.2. Le niveau conceptuel de Squash Les tests (inclus dans ce facteur dans le modèle Squale) sont désormais rattachés à la fiabilité de l application. La capacité d évolution cible la capacité d un logiciel à intégrer de nouvelles fonctionnalités. Cette exigence est importante pour permettre là encore une utilisation durable de ce dernier. En effet, au fil du temps les exigences évoluent et il est primordial de pouvoir les satisfaire facilement. Ce facteur, spécifique à Squale en tant que facteur a été conservé dans Squash. En effet, cette notion, bien que prise en compte dans la norme ISO 9126 n est pas pour autant un facteur de la norme à part entière. En revanche, elle fait partie du facteur maintenabilité en tant que sous-caractéristique de celui-ci (la Facilité de modification). Cette notion se retrouve pourtant en tant que facteur dans le modèle de McCall (la flexibilité). Nous avons estimé que les notions de maintenabilité et de capacité d évolution diffèrent dans ce qu elles impliquent. En effet, la capacité d évolution fait plus référence à des notions d architecture générale du code tandis que la maintenabilité fait plus référence à des notions de lisibilité du code source. Bien sûr, la frontière entre les deux notions est mince et les caractéristiques de l une peuvent se retrouver dans l autre. Cependant, il nous a semblé essentiel de distinguer ces deux notions pour mettre l accent sur l importance de leurs exigences respectives. Le facteur architecture de Squale est devenu un sous-facteur de la capacité d évolution. En effet, la qualité de l architecture du logiciel a des conséquences directes quant à la capacité d évolution de celui-ci. C est même un des points essentiels. La modélisation n est plus un critère de la capacité fonctionnelle mais un critère de l architecture puisqu il s agit de définir au préalable cette dernière. Squash définit désormais la capacité d évolution selon les critères suivants : architecture, documentation technique, homogénéité, modularité et tests développement. La capacité de réutilisation vérifie la possibilité d utiliser une partie du code de l application pour en implémenter une autre. Cette notion, absente de la norme ISO 9126 mais présente dans le modèle de McCall est importante. En effet, pour être portable à d autres applications un code doit suivre des normes strictes de programmation qui impliquent un formalisme précis, permettant l écriture d un code de haut niveau d abstraction. C est donc un gage essentiel de qualité du code. Ce facteur est défini à partir des critères suivants : portabilité, documentation technique, stabilité et interdépendance. Le domaine fonctionnel Nous rappelons que le domaine fonctionnel correspond à tout ce qui a trait à l expression des besoins et à la validation de l adéquation du logiciel par rapport à ces besoins. Le facteur adéquation fonctionnelle couvre l intégralité du domaine. Le modèle Squale définissait déjà ce facteur mais de manière incomplète. Le second projet de recherche a été consacré à redéfinir précisément le domaine dans le modèle Squash. Nous avons distingué deux sous-facteurs : d une part la conduite de projet qui évalue les méthodes de travail autour de la validation fonctionnelle et d autre part les tests fonctionnels qui évalue les tests eux-mêmes. La conduite de projet est définie par les critères suivants : organisation ALM, exigences et données de tests ce qui signifie que ce sous-facteur évalue la façon dont s organisent l expression des besoins et leur validation, ainsi que la manière dont sont gérées et déterminées de manière générale les exigences et les données de tests. Le second sous-facteur, les tests fonctionnels, est caractérisé par les critères suivants : tests fonctionnels, automatisation des tests et formalisation de la stratégie de tests. Ces critères évaluent les tests fonctionnels mais également la manière dont sont menés et validés les campagnes de tests 115

130 Chapitre 4. Présentation du modèle Squash ainsi que l automatisation des tests (il s agit des tests fonctionnels qui sont exécutés de manière automatique et non par un technicien). Le domaine fonctionnel est donc entièrement couvert : Squash évalue à la fois l expression des besoins mais aussi la validation fonctionnelle, il évalue à la fois la manière dont le domaine fonctionnel est organisé mais également les tests ainsi que leurs résultats, à travers les pratiques de couverture de tests et de taux de réussite de ceux-ci. Le domaine de la production Le domaine de la production regroupe à la fois l exploitation du logiciel mais également les aspects de sécurité. Les facteurs fiablité, performances et sécurité évaluent ce domaine. La fiabilité regroupe les critères suivants : stabilité, exploitabilité et tests de développement. Ce critère évalue la fiabilité d un logiciel en vérifiant les tests de développements mais également les tests qui vérifient que le logiciel fonctionne dans les conditions d exploitation définies. Il évalue également la manière dont sont gérées les différentes versions d un logiciel ainsi que la manière dont les erreurs et anomalies sont suivies. La sécurité regroupe les critères suivants : tests sécurité et normes de sécurité. Ils évaluent à la fois les tests éffectués autour de la sécurité mais également le respect des normes de sécurité définies par l entreprise. Les performances sont évaluées avec les critères suivants : exploitabilité, tests applicatifs et normes de performances. Les performances sont donc directement reliées à la fois aux tests de vérification de celle-ci, mais également aux tests exécutés pour vérifier que le logiciel fonctionne dans les conditions d exploitation pour lequel il est prévu. Ces trois facteurs ont été modifiés lors du second projet de recherche pour intégrer les pratiques de tests de développement, applicatifs, système et sécurité. En revanche, pour être vraiment complet, Squash doit encore intégrer des pratiques définissant les savoir-faire et exigences aussi bien en matière de sécurité qu en matière de production/exploitation. En effet, il n est pas défini par exemple comment doivent être suivis les plantages d un logiciel par exemple, ou encore les procédures à suivre pour déployer un logiciel sur plusieurs sites. L intégralité de ce domaine doit faire l objet d une étude pour intégrer toutes les procédures et les savoir-faire métier dans ce domaine. 4.3 Définition du niveau technique de Squash Pour évaluer la qualité il faut définir des règles de qualité et les mesures qui y correspondent. Le modèle Squash définit ces règles à travers les pratiques qui le composent. Celle-ci sont évaluées à partir des métriques et données brutes qui composent le niveau le plus bas du modèle Les pratiques de Squash 116 Chaque pratique possède les propriétés suivantes :

131 4.3. Définition du niveau technique de Squash la définition ou le principe technique qu elle décrit. Il s agit de préciser la règle ou le savoir-faire visé par la pratique, comme par exemple le taux de couverture des tests unitaires ; les différentes mesures qu elle utilise pour le qualifier. Il s agit des mesures associées à la pratique pour calculer sa note comme par exemple : SLOC ou V(G) ; le composant qu elle cible. Les mesures utilisées pour mesurer la pratique sont rattachées à un type de composant donné (une classe ou une méthode par exemple) et la pratique est rattachée également au même type de composant ; une note individuelle calculée à partir d une formule de combinaison de mesures. On distingue deux types de combinaison selon le type de pratique (d une part les pratiques qui reposent sur des métriques, d autre part celles qui reposent sur des données brutes). Pour les pratiques reposant sur des métriques, il s agit de déterminer comment à partir de plusieurs métriques ayant des valeurs brutes quelconques on obtient une note individuelle de la pratique comprise dans l intervalle [0 ;3]. Pour y parvenir on détermine une formule de combinaison qui calcule les notes individuelles de la pratique. Celle-ci correspond à une note par composant auquel la pratique est attachée. Le second type de pratique, reposant sur des données brutes, n ont pas de notes individuelles ; une note globale calculée à partir d une formule d agrégation qui dépend également de la formule de combinaison. Les pratiques obtenant des notes individuelles fondées sur des métriques utilisent la formule I Squale pour calculer la note globale de la pratique. Cette formule permet de déterminer la note globale de la pratique, comprise dans l intervalle [0 ;3], à partir de l ensemble des notes individuelles de la pratique. Les pratiques reposant sur des données brutes utilisent un algorithme d agrégation comme détaillé dans la section 5.3 ; le poids associé à la formule I Squale, le cas échéant, permettant de calibrer les notes en fonction des exigences propres à l entreprise et au logiciel analysé. 117

132 Chapitre 4. Présentation du modèle Squash Pratiques de code taille de méthodes nombre de méthodes code Spaghetti Profondeur d'héritage couplage efferent couplage afferent Pratiques de modèles diagramme de modélisation conformité entre modélisation et implémentation prédétection d'antipatterns Raisonnement par les modèles Pratiques de normes et standards normes et standards : documentation normes et standards : programmation normes et standards : convention de nommage Normes et standard : traçage Pratiques documentaires qualité de la documentation choix des technologies design-pattern organisation générale du code couteau suisse copier coller cohésion de classe normes et standards : mise en forme normes et standards : gestion de configuration dossier d'architecture technique correspondance entre couches et nommage taux de commentaires dépendance cyclique niveau d'abstraction et de stabilité Normes et standard : portabilité Normes et standard : packaging de livraison découpage en couches dossier de production Gestion des exceptions Normes et standard : sécurité respect de l'architecture en couches Respect des règles de l'entreprise : dossier de conception technique Respect partie sécurité du cahier des charges conformité implémentation/ définition sécurité Pratiques de tests Plan d'assurance qualité Couverture des données de tests Définition de la campagne de tests Tests de performance Validation du cahier des charges Définition des besoins des données conformité entre la stratégie et les tests Couverture de tests performance Extraction des exigences Qualité de l'échantillonnage Validation de la campagne de tests Tests de montée en charge catégorisation des exigences Données anonymisées Taux de couverture tests unitaires Couverture des tests de montée en charge cycle de vie des exigences Stratégie de validation et d'homologation du logiciel Taux de couverture des tests d'intégration Tests de robustesse criticité des exigences Données de tests automatisés Cycle de vie des tests développement Couverture des tests de robustesse Gestion des anomalies Couverture des données tests automatisés Tests unitaires Exigences charge Maturité des tests Cycle de vie des tests auto Tests d'integration rédaction des cas de tests fonctionels Gestions des versions Maturité des test auto Testabilité de l'application Cycle de vie des tests fonctionnels Gestion des anomalies après tests Tests automatisés Couverture des données système Couverture de tests fonctionnels Couverture des données applicatif Couverture des cas de tests Données système Tests fonctionnels Données applicatif Tests de configuration/ installation Exigences système Taux de couverture des données fonctionnel Stratégie des tests de non régression Couverture des tests configuration Couverture de tests d'intégration système Données de tests fonctionnels Taux de couverture des tests de non régression Taux de couverture tests d'acceptation Tests d'intégration système Exigences fonctionnelles tests d'acceptation Données aux limites 118 Figure 4.4 Les pratiques du modèle Squash.

133 4.3. Définition du niveau technique de Squash La répartition des pratiques de Squash Nous avons conservé la répartition des pratiques telle que définie dans le modèle Squale (voir Section 2.2.2) : pratiques de code détaillées dans l annexe A.1 ; pratiques de normes et standard détaillées dans l annexe A.2 ; pratiques de modèle détaillées dans l annexe A.3 ; pratiques de tests détaillées dans l annexe A.4 ; pratiques documentaires détaillées dans l annexe A.5. La figure 4.4 dresse la liste des pratiques selon cette répartition. Les pratiques de code et de normes et standard du modèle Squale ont été validés par Air France-KLM et PSA Peugeot-Citroën. Nous les avons donc intégrées au modèle Squash. Les pratiques de modèle sont également restés telles que décrites précédemment mais doivent encore faire l objet d une validation plus approfondie. Les pratiques documentaires ont été entièrement retravaillées dans leur système de notation (voir Section 5.3). Les pratiques de tests ont entièrement été redéfinies en accord avec les exigences de Generali lors du second projet de recherche. Nous les détaillons ci-après Les pratiques de tests Ces pratiques déterminent la qualité des tests effectués sur l application, que ce soient les tests en boîte noire ou les tests en boîte blanche, tels que définis dans la section 1.3. Le modèle Squash distingue plusieurs types de tests définis et classés ainsi : les tests de développement qui regroupent les tests effectués par les développeurs. Il s agit de tests en boîte blanche, à partir de l analyse du code source ; les tests système qui regroupent les tests autour du système d exploitation. Il s agit de tests qui déterminent si l application se comporte correctement dans son environnement d exploitation ; les tests applicatifs qui regroupent les tests autour de la performance de l application. Ces tests déterminent si l application se comporte comme attendu lors de son utilisation en conditions réelles d exploitation ; les tests fonctionnels qui regroupent les tests effectués sur l application pour déterminer si celle-ci correspond aux exigences définies préalablement. Il s agit de tests en boîte noire, à partir des exigences et du cahier des charges ; les tests automatisés qui regroupent les tests fonctionnels effectués de manière automatique ; les tests de sécurité qui regroupent les tests effectués pour déterminer si l application répond aux normes de sécurité. Pour chaque type de tests, définis précédemment, les pratiques couvrent l ensemble du processus de tests à mettre en œuvre pour parvenir à une campagne de tests réussis. Pour y parvenir nous avons identifié les domaines techniques suivants : les besoins associées à ces tests. Ce terme désigne l expression des besoins de tests de manière large. Les pratiques déterminent si les besoins les exigences sont exprimés avec précision. la couverture des exigences. Il s agit d évaluer si les tests effectués couvrent effectivement l ensemble des exigences, l ensemble des besoins de tests définis préalablement. La couverture des tests de développement est associée au code source ; 119

134 Chapitre 4. Présentation du modèle Squash Table 4.1 Les pratiques de tests de développement du modèle Squash Nom de la pratique Taux de réussite des Tests unitaires Exigences des tests unitaires Couverture des tests unitaires Taux de réussite des tests d intégration Stratégie des tests d intégration Couverture des tests d intégration Cycle de vie des tests de développement Définition qualifie le taux de réussite des tests unitaires appliqués au programme qualifie la qualité des tests unitaires qualifie le taux de couverture des tests unitaires qualifie le taux de réussite des tests d intégration qualifie la stratégie mise en œuvre pour gérer les tests d intégration qualifie le taux de couverture des tests d intégration vérifie que les tests sont rejoués en fonction du cycle de développement Table 4.2 Les pratiques de tests fonctionnels du modèle Squash Nom de la pratique Exigences fonctionnelles Rédaction des cas de tests fonctionnels Couverture des cas de tests fonctionnels Données fonctionnelles Données aux limites Taux de réussite des tests fonctionnels Taux de couverture des tests fonctionnels Couverture des données fonctionnelles Cycle de vie des tests fonctionnels Tests d acceptation Taux de couverture des tests d acceptation Stratégie des tests de non régression Taux de couverture des tests de non régression Définition vérifie la qualité des exigences fonctionnelles vérifie la qualité de la rédaction des cas de tests vérifie que les cas de tests couvrent les exigences détermine si les données fonctionnelles couvrent les besoins. vérifie que les données aux limites sont correctes qualifie le taux de réussite des tests fonctionnels vérifie le pourcentage de tests effectués par rapport aux cas de tests vérifie la couverture des données pour les tests fonctionnels détermine si les tests sont intégrés dans le cycle de vie du logiciel taux de réussite des tests d acceptation les tests passés sont en corrélation avec les exigences détermine si les tests de non régression suivent une stratégie vérifie le pourcentage de tests effectués par rapport aux tests retenus le taux de réussite des tests. Vérifier que les tests sont effectivement effectués ne suffit pas à déterminer la qualité des tests. Il faut également vérifier que les tests sont effectués avec succès ; les données de tests. Les données utilisées avec les tests doivent couvrir l ensemble des besoins des tests. Elles doivent permettre d effecteur tous les tests et doivent répondre à tous les cas à envisager ; le cycle de vie des tests. Une application évolue, que ce soit de par ses corrections ou de par ses modifications ou autres ajouts de fonctionnalités. Les tests doivent évoluer de la même manière et être rejoués en fonction des modifications apportées à l application. Pour y parvenir, il faut que le processus de tests, depuis l expression des besoins jusqu à la phase de tests, suive le même cycle de vie que l application elle-même. 120 Selon le type de tests la notion de besoins désigne : les tests de développement. Se rapporte à la méthodologie attachée aux tests unitaires. Détermine si les tests sont écrits de manière formelle avec une méthodologie rigoureuse ou au cas par cas ; les tests système. Se rapporte à l expression des besoins de tests système, tels que les login, les connections, les procédures d installation et de déploiement de l application.

135 4.3. Définition du niveau technique de Squash Table 4.3 Les pratiques de tests automatisés du modèle Squash Nom de la pratique Testabilité de l application Tests automatisés Cycle de vie des tests automatisés Maturité des tests automatiques Données de tests automatisés Couverture des données de tests automatisés Définition qualifie la stratégie des cas automatisables définie dans le plan de tests qualifie les tests automatisés qui doivent être maintenables facilement qualifie le cycle de vie des tests automatisés qualifie le nombre de tests automatisés effectifs détermine la qualité des données de tests automatiques détermine la couverture des données pour les tests automatisés Table 4.4 Les pratiques de tests applicatifs du modèle Squash Nom de la pratique Exigences applicatif Données applicatif Couverture des données applicatif Tests de montée en charge Couverture des tests de montée en charge Tests de robustesse Couverture des tests de robustesse Tests de performance Couverture des tests de performance Définition détermine la qualité des exigences qui se rapportent aux tests applicatifs détermine la qualité des données en adéquation avec ces tests qualifie l adéquation données/besoins pour les tests applicatifs détermine le taux de réussite des tests par rapport aux exigences qualifie le taux de couverture ces tests détermine le taux de réussite de ces tests par rapport aux exigences. détermine le taux de couverture des tests de robustesse détermine la qualité du taux de réussite de ces tests détermine le taux de couverture des tests de performance les tests applicatif. Se rapporte à l expression de besoins de tests tels que la bande passante, les connections simultanées, la montée en charge,etc. les tests fonctionnels. Se rapporte aux exigences définies dans le cahier des charges mais également à la définition des cas de tests associés à ces exigences. les tests automatisés. Se rapporte à définir la testabilité du logiciel, notamment en fonction de son degré de maturité. Analyse le fait que les tests automatisés suivent une évolution et un processus défini avec soin ; les tests de sécurité. Se rapporte à l expression des besoins autour de la sécurité tels que la résistance aux intrusions, les connections non permises, les droits associés à chaque utilisateur, etc. A chaque type de tests correspond donc les pratiques qui évaluent ces règles techniques. Par exemple, les tests de développement sont évalués grâce à l ensemble des pratiques : exigences des tests unitaires et stratégie des tests d intégration pour qualifier les besoins, taux de couverture des tests unitaires et des tests d intégration pour qualifier la couverture des exigences, taux de réussite des tests unitaires et des tests d intégration pour qualifier le taux de réussite, cycle de vie des tests de développement pour qualifier le cycle de vie. Il faut noter que les données de tests ne sont pas analysées pour ce type de pratiques car elles sont liées directement aux taux de couverture des tests. Les pratiques répartis en fonction des autres types de tests sont déclinés de la même manière. L ensemble des pratiques de tests définies pour le modèle Squash est résumé dans les tableaux 4.1 à 4.6 et détaillé en Annexe A.4. En plus des pratiques qui évaluent la qualité des tests, le modèle Squash définit également des pratiques qui évaluent la qualité de la stratégie de tests mise en place par l entreprise de manière 121

136 Chapitre 4. Présentation du modèle Squash Table 4.5 Les pratiques de tests système du modèle Squash Nom de la pratique Exigences système Données système Couverture des données système Tests de configuration/installation Couverture des tests de configuration Tests d intégration système Couverture des tests d intégration système Définition détermine la qualité des exigences qui se rapportent aux tests système détermine la qualité des données en adéquation avec ces tests qualifie l adéquation données/besoins pour les tests système vérifie le taux de réussite des tests de configuration détermine le taux de couverture des tests de configuration vérifie le taux de réussite des tests d intégration système détermine le taux de couverture des tests d intégration système Table 4.6 Les pratiques de tests sécurité du modèle Squash Nom de la pratique Exigences sécurité Données sécurité Couverture des données sécurité Tests d intrusion Couverture des tests d intrusion Définition détermine la qualité des exigences qui se rapportent aux tests sécurité détermine la qualité des données en adéquation avec ces tests qualifie l adéquation données/besoins pour les tests sécurité qualifie le taux de réussite des tests de sécurité par rapport aux exigences détermine le taux de couverture des tests d intrusion globale. Ces pratiques évaluent les documents annexes à l application tel que le cahier des charges, la qualité de la définition des campagnes de tests, la formalisation de la stratégie de tests ou encore la gestion des bogues. Ces pratiques sont regroupées dans le tableau 4.7 et détaillés en Annexe A.4. Les notes des pratiques de tests Les pratiques de tests sont notées de manière différente selon la pratique : les pratiques qui reposent sur une expertise humaine sont notées selon le même principe que les pratiques documentaires (voir Section 5.3) ; les pratiques de tests qui reposent sur des métriques sont évaluées selon les mêmes principes que les pratiques de code (voir Section 2.3.1) ; les pratiques de tests qui reposent sur des métriques et qui ne sont évaluées qu au niveau projet utilisent les formules de combinaison de métriques telles que définies dans la section pour calculer directement leur note globale. L exemple d une pratique de tests Soit la pratique Couverture des cas de tests fonctionnels qui possède les propriétés suivantes : définition : détermine si les cas de tests fonctionnels définis couvrent effectivement tous les besoins exprimés (les besoins ou exigences font l objet d une pratique différente qui détermine leur qualité). Il faut au moins un cas de test par exigence pour arriver à un niveau satisfaisant de couverture des exigences. Cette pratique ne s occupe pas de déterminer si les cas de tests sont effectivement correctement reliés aux exigences ou encore aux tests eux-mêmes. Il s agit ici de n estimer que le fait que le nombre de cas de tests est suffisant par rapport aux exigences. Pour un résultat de 85 % de cas de tests par rapport aux exigences, la pratique obtient la note de 2. En revanche, la pratique prend également en compte la criticité d une exigence : une exigence majeure doit être plus couverte qu une exigence mineure. composant : Projet. 122

137 4.3. Définition du niveau technique de Squash Table 4.7 Les pratiques d organisation des tests du modèle Squash Nom de la pratique Maturité des tests Plan assurance qualité Validation du cahier des charges Stratégie de validation et d homologation Gestion des anomalies Gestion des anomalies après tests Gestion des versions Couverture des données de tests Définition des besoins des données Qualité de l échantillonnage Données anonymisées Définition de la campagne de tests Conformité entre la stratégie et les tests Validation de la campagne de tests Extraction des exigences Criticité des exigences Catégorisation des exigences Cycle de vie des exigences Définition qualifie la maturité par rapport aux bogues détectés pendant les tests vérifie qu il existe un PAQ en accord avec la méthodologie de l entreprise vérifie la procédure de validation du cahier des charges vérifie la stratégie de validation et d homologation détermine la qualité de la gestion des anomalies détectées lors des tests vérifie la gestion des anomalies détectées après la campagne de tests qualifie la gestion des différentes versions du logiciel vérification des règles de construction des données pour les tests qualifie l établissemnt et la gestion des besoins de données pour les tests vérifie que les échantillons correspondent aux besoins des différents tests vérifie que les contrôles des données anonymisées sont exercés vérifie la qualité de la campagne de tests vérifie si la stratégie de tests est suivie vérifie la qualité de la validation de la campagne de tests vérifie que les exigences sont extraites correctement du cahier des charges vérifie que les exigences sont répertoriées en fonction des leur criticité vérifie que les exigences sont réparties en fonction de différents domaines qualifie les exigences qui doivent s inscrire dans le cycle de vie du projet note individuelle : pas d objet. note globale (GM) : GM = 2 ((3 Ratio Critique+Ratio Autre ) 225)/90 avec Ratio Critique qui représente le pourcentage de couverture des exigences majeures et Ratio Autre qui représente le taux de couverture des exigences mineures. Un poids de 3 est appliqué pour renforcer les exigences majeures. poids : pas d objet. Table 4.8 Exemple de notes pour la pratique Couverture des cas de tests fonctionnels Exigences critiques Exigences mineures Cas de tests critiques Cas de tests mineures Somme des cas de tests Ratio critiques 100 % 100 % 63 % 73 % 80 % 100 % 45 % 63 % Ratio mineures 0 % 56 % 100 % 88 % 80 % 34 % 100 % 78 % Ratio total 54 % 80 % 80 % 80 % 80 % 70 % 70 % 70 % note de la pratique 1,77 3 1,63 1,87 2,07 2,31 1,07 1,37 Le tableau 4.8 fournit un exemple d évaluation pour un projet composé de 60 exigences critiques et 50 exigences mineures. Les cas de tests appliqués varient selon les différents ratios reportés dans le tableau. La note de la pratique varie pour mettre en avant le fait que les cas de tests doivent couvrir pratiquement entièrement les exigences, mais plus particulièrement celles critiques. Le premier cas montre qu il ne suffit pas de couvrir 100 % des exigences critiques pour obtenir une bonne note. 123

138 Chapitre 4. Présentation du modèle Squash Les cas suivants montrent que pour 80 % d exigences couvertes, il faut en plus avoir un seuil de 80 % des exigences critiques pour obtenir une note satisfaisante. Les trois derniers cas, avec 70 % de couverture globale montrent qu il faut avoir une couverture minimum de 100 % des exigences critiques pour obtenir une note satisfaisante. Cette pratique calcule la note en fonction du taux de couverture mais également en classant les exigences selon leur niveau d importance. Les chiffres utilisés dans la formule GM = 2 ((3 Ratio Critique+Ratio Autre ) 225)/90 se comprennent de la manière suivante : 225 correspond à la note de , soit trois fois le ratio des exigences critiques additionné au ratio des exigences autres pour obtenir la note de correspond à la pente de la courbe. Les exigences critiques sont donc prises en compte trois fois plus sévèrement que les autres exigences. Dans le cas où les exigences ne sont pas répertoriées en fonction de leur criticité, cette pratique peut être adaptée pour ne prendre en compte que la couverture de tests, en utilisant une formule semblable à celle utilisée par exemple pour la pratique couverture des tests unitaires, telle que décrite en Annexe A.4.1 en page 200. Chaque pratique de tests évalue une règle unique en matière de tests (celle-ci évalue uniquement la couverture de tests) et doit être mise en relation avec les pratiques associées pour obtenir une image complète de la qualité des tests. Par exemple, pour cette pratique permet de mesurer la qualité de la couverture des cas de tests fonctionnels et pour obtenir une image de la qualité générale des tests fonctionnels, il faut prendre en compte la qualité de toutes les pratiques afférentes aux tests fonctionnels. Cette image est traduite par la note du critère tests fonctionnels. Ce découpage permet de pointer très exactement les lacunes et de diriger l effort précisément pour parvenir à augmenter la qualité et comprendre les origines probables des erreurs dans la qualification logicielle Les mesures de Squash Tout comme pour le modèle Squale, on distingue deux types de mesures : les mesures issues de métriques et les mesures issues de l analyse de données brutes. La figure 4.5 donne la liste des métriques associées au modèle Squash ainsi qu un extrait des données brutes nécessaires à l évaluation des pratiques du modèle Squash. Nous avons conservé la répartition des mesures telle que définie dans Squale (voir Section 2.2.1). Les mesures associées aux différentes pratiques ont fait, en partie, l objet d une étude détaillée. Les métriques de code et les conventions de codage ont été définies dans le document [Balmas et al., 2009]. Elles sont détaillées dans la section 1.2. Les mesures associées aux pratiques de modèle doivent encore faire l objet d une étude conjointe à celle des pratiques de modèle. Les données brutes associées aux pratiques documentaires ont été redéfinies entièrement dans le cadre du projet de recherche Squash et sont détaillées dans l annexe A.5 au sein des pratiques qu elles évaluent. Les métriques associées aux pratiques de tests ont été définies en fonction de l étude présentée dans la section 1.3. Ces métriques, ainsi que les données brutes associées aux pratiques de tests sont détaillées dans l annexe A.4. Les données brutes correspondent désormais non plus uniquement à une liste de documents à analyser (tels que décrits dans la figure 2.3 en page 59 pour le modèle Squale) mais plus précisément à une liste de caractéristiques, définie pour chaque pratique. Cette liste doit être évaluée par un expert selon l échelle de valeur linguistique suivante : Excellent, bien, assez bien, moyen et insuffisant comme expliqué dans le section Chaque pratique possède donc sa liste propre qui permet de détailler toutes les données à prendre en compte pour évaluer la pratique. Nous expliquons en détail 124

139 4.4. Conclusion métriques orientées objet métriques primitives RCF NOM DIT métriques de design LCOM4 cycles métriques de packages Ce métriques de code métriques conventionnelles CLOC V(G) ev(g) SLOC métriques de modèle RCF NOM DIT SIX V(G) LCOM4 Ca Nombre d'attributs Nombre de champs publics DepClients DepSuppliers conventions de nommage Nombre de classes SLOC Normes et standard : erreurs Normes et standard : warning Normes et standard : info Données brutes qualité des données de tests existence d'un PAQ Stratégie de tests respect du cahier des charges stratégie de suivi de bogues rédaction des cas de tests données anonymes métriques de tests Taux de couverture des test Taux de couvertures TU Taux de couvertures de données de tests Taux de couverture des tests fonctionnels... Ca Distance existence de documentation technique mise à jour de la documentation campagne de tests... Figure 4.5 Un extrait des mesures du modèle Squash, classées en cinq groupes. le processus d évaluation et de notation de la pratique à partir de sa liste de caractéristiques dans la section Conclusion A partir du modèle Squale et les réflexions que nous avons présentées dans le chapitre 3 nous avons conçu une nouvelle version du modèle appelé Squash. Ce modèle hiérarchique est composé de quatre couches définies précisément, séparées en deux niveaux : le niveau conceptuel et le niveau technique. Le premier niveau permet d avoir une vue générale de la qualité du logiciel tandis que le second niveau permet d adapter le modèle aux exigences de l entreprise ainsi qu aux exigences techniques du logiciel évalué. Le modèle possède désormais sept facteurs et la répartition des critères en fonction des facteurs a été revue en fonction également de la définition de la norme SQuaRE. Les pratiques ont fait également l objet d une nouvelle répartition ainsi que d une étude approfondie qui a permis de valider les pratiques de code et de définir entièrement les pratiques de tests. Les mesures qui sont de deux types différents, à savoir les métriques et les données brutes, ont été analysées. Les métriques ont été validées et les données brutes ont été entièrement précisées. Le modèle Squash définit désormais une liste de caractéristiques par pratique documentaire qui permet de qualifier plus finement les documents utilisés pour évaluer ce type de pratiques. 125

140 Chapitre 4. Présentation du modèle Squash Dans le chapitre suivant nous présentons comment le modèle Squash évalue les règles techniques qu il définit les pratiques à partir des mesures qu il utilise. 126

141 Chapitre 5 Evaluation de la qualité dans Squash Sommaire 5.1 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 Conclusion Dans ce chapitre, nous présentons comment sont évaluées les différentes couches du modèle Squash et nous expliquons la dernière étape de notre processus de conception d un modèle de qualité : l évaluation des règles de qualité (les pratiques) à partir des mesures. L évaluation de la qualité se découpe en deux parties correspondant aux deux niveaux du modèle (conceptuel et technique). L évaluation du niveau conceptuel est expliquée dans la section 5.1. Le niveau technique est associé aux pratiques définies dans le modèle. Les pratiques de modèle ont été définies dans la section et leur mode de calcul restent inchangées, de même pour les pratiques de normes et standard définies dans la section Les formules utilisées dans les pratiques de code, bien qu inchangées ont fait l objet d une validation détaillée que nous présentons dans la section 5.2. Les pratiques de tests sont évaluées selon les mêmes modes que les pratiques de code ou les pratiques documentaires selon qu elles reposent sur des métriques ou sur des données brutes. Les pratiques documentaires ont fait l objet d une nouvelle évaluation selon les principes que nous détaillons dans la section 5.3. Le système de notation imposé par Squale a été conservé. Les notes sont calculées dans l intervalle [0; 3] suivant les mêmes significations : entre 0 et 1, le but n est pas atteint ; entre 1 et 2, le minimum est atteint mais avec des réserves ; entre 2 et 3, le but est atteint. 127

142 Chapitre 5. Evaluation de la qualité dans Squash 5.1 L évaluation des facteurs et des critères Les critères et les facteurs sont évalués à partir d une moyenne simple des pratiques ou critères qui les composent. La notation du niveau conceptuel reste donc inchangée par rapport à Squale. Cependant, il s offre plusieurs possibilités pour affiner la notation du niveau conceptuel. La première piste consiste à traduire l importance d un élément par rapport à un autre. Pour y parvenir, il suffit alors de pondérer les éléments d un niveau en fonction de leur importance relative. Par exemple, pondérer les pratiques en fonction de leur importance dans l évaluation du critère qu ils décrivent. Une moyenne pondérée peut en effet s envisager et être mise en place facilement. Par exemple, le critère organisation ALM composé des pratiques plan assurance qualité, validation du cahier des charges et stratégie de validation et d homologation du logiciel pourrait être soumis à ce type de notation pour renforcer l importance de la validation du cahier des charges par rapport à la stratégie de validation du logiciel. En revanche, pour le critère simplicité composé des pratiques taille d une méthode, nombre de méthodes, code spaghetti et profondeur d héritage pondérer les pratiques paraît inopportun. En effet, les pratiques sont toutes de même importance pour déterminer la valeur du critère. Ainsi, le choix de pondérer les notes ne semble pas suffisamment pertinent. En effet, l importance relative des éléments les uns par rapport aux autres peut varier en fonction des entreprises. De plus les éléments sont en nombre restreint, ce qui limite d autant la nécessité d utiliser un autre système de calcul qu une simple moyenne. Cela pourrait facilement revenir à complexifier l information délivrée au lieu d ajouter une information supplémentaire. Nous avons également envisagé d utiliser la formule I Squale ou une formule équivalente pour noter les critères et les facteurs, dans le but de renforcer l impact des mauvaises notes d un élément. Là encore, le nombre restreint d éléments qui composent les critères et les facteurs ne rendent pas indispensable l utilisation d une telle formule, à priori. Cependant, cette piste n est pas totalement écartée et mériterait d être plus approfondie pour déterminer avec précision si ce système de notation peut apporter une information utile supplémentaire. Nous avons donc choisi de conserver une moyenne simple comme mode de calcul, dans un premier temps. 5.2 Les pratiques de code : la validation des formules de Squale L ensemble des pratiques de code définies pour le modèle Squash est identique à celui du modèle Squale. Ces pratiques reposent sur des mesures issues de métriques de code. Squash calcule les notes en deux étapes. Tout d abord il attribue une note individuelle à chaque composant visé par la pratique puis il calcule la note globale de la pratique à partir des notes individuelles (voir Sections et 3.4). 128

143 5.2. Les pratiques de code : la validation des formules de Squale Les notes individuelles : la combinaison de métriques et la normalisation des notes. Chaque composant concerné par une pratique donnée possède une note pour celle-ci. Cette note, calculée à partir des mesures effectuées sur cet élément est notée IM dans les formules. La note globale : l agrégation des notes individuelles. Une note globale est ensuite attribuée pour une pratique donnée en se basant sur les notes individuelles obtenues pour chaque composant. Elle est notée GM dans les formules et est calculée avec une fonction continue pondérée notée I Squale Formalisation des notes des pratiques de code Les fonctions définies pour chaque pratique et qui calculent les notes individuelles regroupent deux principes : d une part la combinaison éventuelle de plusieurs métriques mais également la normalisation de la note obtenue dans l intervalle [0; 3]. La combinaison des métriques Une pratique définit une règle technique précise. Pour parvenir à qualifier le plus finement et précisément possible cette règle, il est souvent nécessaire d utiliser plusieurs métriques comme nous l avons expliqué dans la section Nous avons identifié les combinaisons possibles suivantes à partir du savoir-faire des développeurs qui ont travaillé sur le projet de recherche de Squale : calculer une moyenne simple ou pondérée des différentes valeurs des métriques. Ceci est possible uniquement quand les métriques ont le même intervalle de valeurs et la même sémantique. C est le cas par exemple pour les métriques SLOC et CLOC qui mesurent le nombre de lignes de code et le nombre de lignes de commentaires ; utiliser une métrique comme valeur seuil pour une autre métrique. Par exemple, considérer la métrique V(G) de la complexité comme seuil à partir duquel une autre métrique fait sens : ne considérer pour une règle de qualité donnée que les méthodes ayant une complexité cyclomatique supérieure à un seuil, dans le but de faire disparaître du calcul des méthodes d encapsulation ; utiliser une métrique comme paliers successifs pour renforcer une propriété. Par exemple, utiliser différentes valeurs de la métrique V(G) pour accentuer le fait qu un code doit être commenté en fonction de sa complexité. Dans ce cas, selon les paliers, la métrique CLOC sera insérée dans des formules différentes pour renforcer l exigence de commentaires ; interpoler une métrique pour traduire un savoir-faire pratique. Quelques valeurs repères sont demandées aux développeurs pour traduire des niveaux de qualité de référence. Une courbe d interpolation des valeurs intermédiaires est créée à partir de ces valeurs, par exemple pour traduire des valeurs qualitatives par rapport aux nombres de lignes de code d une méthode ; une combinaison de toutes ces méthodes. On associe un seuil à une interpolation, par exemple. Les équations sont déterminées au cas par cas en fonction des pratiques et sont données dans l annexe A.1. Elle sont issues du savoir-faire métier des entreprises partenaires des projets de recherche. La combinaison est effectuée en même temps que la normalisation des notes. 129

144 Chapitre 5. Evaluation de la qualité dans Squash La normalisation des notes Lorsqu une pratique est calculée à partir de plusieurs métriques, ces dernières sont souvent hétérogènes, i.e., elles ne fournissent pas leurs résultats dans la même échelle de valeurs. D où le besoin dans ce cas de transposer les valeurs dans le même intervalle,i.e., les mettre sous dénominateur commun pour les rendre homogènes. De plus, le calcul des notes des pratiques traduit une perception de la qualité par rapport à un principe technique précis. D où l utilisation de valeurs seuils qui traduisent les perceptions et les exigences des entreprises. Pour obtenir un système de notation homogène et interprétable facilement, les notes du modèle Squash sont donc calculées dans un intervalle identique pour toutes les pratiques : l intervalle de notation de Squash [0; 3]. Un exemple L exemple de la pratique Taille de la méthode illustre ce mode de calcul. Cette pratique est calculée au niveau des méthodes : les notes individuelles sont calculées pour chaque méthode et la note globale de la pratique est calculée avec une fonction pondérée et un poids moyen. Cette pratique se fonde sur le nombre de lignes de code pour être calculée. Elle est définie comme une pratique qui pointe les méthodes qui sont trop longues, et donc sans doute trop difficiles à maintenir et à comprendre. Pour calculer la note individuelle pour cette pratique, des valeurs de référence (des valeurs seuils) ont été définies par Air France-KLM à partir de leur prérequis et sont données dans la première ligne de la Table 5.1. A partir de ces valeurs, la fonction de calcul de la note individuelle IM est définie par interpolation de la manière suivante, avec SLOC métrique du nombre de lignes de code : IM = 2 (70 sloc)/21. L équation a été validée par les développeurs de Air France-KLM, et les seuils définis ont pour signification : le premier seuil qui correspond à la note de 3 exprime qu une méthode de taille optimale doit avoir moins de 40 lignes ; le second seuil qui correspond à la valeur 2 exprime le fait qu une méthode dont la taille est comprise entre 40 et 50 lignes est de taille acceptable ; le troisième seuil qui correspond à la note de 1 exprime le fait qu une méthode dont la taille est comprise entre 50 et 70 lignes est beaucoup plus difficile à comprendre et à maintenir. Il est souhaitable d analyser cette méthode pour éventuellement diminuer le nombre de lignes qui la composent ; le dernier seuil qui correspond à la note de 0 exprime le fait qu une méthode de plus de 160 lignes de code est, à terme, trop difficile à comprendre et à maintenir. Il faut alors étudier cette méthode pour la scinder en plusieurs méthodes de taille correcte. On note que chaque instanciation du modèle peut avoir ses propres valeurs. Table 5.1 Mesures/notes de références servant de base à la formule déterminant la note de la pratique taille des méthodes Seuil développeurs SLOC Pratique

145 5.2. Les pratiques de code : la validation des formules de Squale La Figure 5.1 montre la courbe correspondant à cette fonction. Le seuil de 40 correspond à la note maximum, c est-à-dire le seuil au delà duquel la note est égale à 3. C est la note maximum qui correspond au fait d avoir atteint l objectif souhaité. Ce seuil a été ajusté à la valeur 37 pour le faire correspondre à l équation d interpolation tout comme les autres seuils. En dessous de ce seuil, les notes individuelles diminuent en suivant une courbe de forme exponentielle : les notes tendent très rapidement vers zéro. Figure 5.1 Courbe de la fonction de combinaison de la pratique taille de la méthode L agrégation des notes : la formule I Squale Le calcul de la note globale est effectué à partir de la formule d agrégation I Squale. Nous rappelons sa définition : ( n 1 λ IMn ) ISquale λ = log λ n, où λ varie selon le poids appliqué et IM n correspond à la note individuelle pour le composant n. Son principe de fonctionnement est décrit dans la section Cette formule a été définie de manière empirique en collaboration avec Air France-KLM. Elle repose sur des poids qui définissent des seuils au delà desquels la pratique obtient une mauvaise note. Elle sert à la fois à agréger les notes individuelles mais également à mettre en avant les pratiques pour lesquelles la qualité pour l ensemble du projet n est pas suffisante. Cette formule a pour but de palier aux défauts des méthodes classiques telles que détaillés dans la section Pour prouver que la formule y parvient, nous construisons notre évaluation selon deux axes : théorique et empirique. Tout d abord, nous comparons I Squale de manière théorique à la technique d agrégation la plus utilisée la moyenne arithmétique (Section ) ainsi qu aux indices inégalités économiques (Section ), nouvelle technique d agrégation utilisée dans le domaine des métriques logicielles [Vasa et al., 2009b, Serebrenik et van den Brand, 2010b, Vasilescu et al., 2010b, Vasilescu et al., 2011a, Goeminne et Mens, 2011, Vasilescu et al., 2011b]. Nous exploitons une étroite relation théorique entre I Squale et I Kolm dans la section , et en déduisons une propriété mathématique supplémentaire de I Squale. Puis, nous comparons de manière empirique les sensibilités de I Squale, de la moyenne arithmétique et des indices d inégalité aux valeurs 131

146 Chapitre 5. Evaluation de la qualité dans Squash les plus faibles (les mauvaises notes). Cette validation empirique est détaillée dans le chapitre suivant (Section 6.2). Cette validation en deux parties a fait l objet d une étude conjointe avec l équipe RMod de l Inria et les auteurs de l étude sur les indices d inégalité économiques appliqués aux métriques de code [Mordal et al., 2012] Validation théorique de la formule I Squale Nous avons tout d abord comparé cette formule à une moyenne arithmétique Comparaison avec la moyenne arithmétique Table 5.2 Notes globales obtenues à partir de trois notes individuelles : 0.5, 1.5, 3 Moyenne simple 1.67 Squale poids faible 1.19 Squale poids moyen 0.93 Squale poids fort 0.81 Considérons trois notes individuelles : 0.5, 1.5 et 3. Les différentes notes globales obtenues par moyenne arithmétique simple, ou par application de la formule I Squale avec un poids faible, moyen ou fort sont référencées dans le tableau 5.2. Ces résultats, ainsi que la courbe g(im) sur la figure 2.6 en page 67 suggèrent que les notes agrégées ne peuvent jamais être inférieures à la plus basse des notes individuelles (0.5) et ne peuvent jamais excéder la moyenne arithmétique (1.67). La proposition suivante prouve que c est effectivement le cas : la note globale calculée par I Squale n est jamais moins sensible à la plus petite valeur que la moyenne arithmétique. Proposition 1. Soient x 1,..., x n des nombres réels et soit x = 1 n n i=1 x i. Alors pour λ > 1 min(x 1,..., x n ) I λ Squale (x 1,..., x n ) x. Démonstration. Puisque min(x 1,..., x n ) x i pour tout 1 i n, alors on en déduit également que x i min(x 1,..., x n ). Puisque λ > 1 on en déduit que λ x i λ min(x 1,...,x n) pour tout i. Donc, n i=1 λ x i nλ min(x 1,...,x n) 1 n n i=1 λ x i λ min(x ( 1,...,x n) log 1 λ n min(x 1,..., x n ) min(x 1,..., x n ) ISquale λ (x 1,..., x n ) n ) i=1 λ x i n De plus, la moyenne géométrique n excède jamais la moyenne arithmétique, i.e., n i=1 λ x i 1 n n i=1 λ x i. Cependant, n n i=1 λ x i = λ 1 n n i=1 x i = λ x. D où, λ x 1 n n i=1 λ x i Puisque λ > 1, x log λ ( 1 n n i=1 λ x i) logλ ( 1 n n i=1 λ x i) x I λ Squale (x 1,..., x n ) x Ainsi, la formule utilisée pour agréger les notes individuelles prend donc en compte les mauvaises notes de manière plus efficace qu une simple moyenne pondérée. 132

147 5.2. Les pratiques de code : la validation des formules de Squale Comparaison théorique avec les indices économiques La relation entre ISquale λ et la moyenne arithmétique a été établie dans la proposition 1. Nous montrons ensuite que I Squale est étroitement liée à I Kolm [Kolm, 1976] dans le Lemme 1. Lemme 1. I log λ Kolm (x 1,..., x n ) + I λ Squale (x 1,..., x n ) = x Démonstration. On observe que : I log λ Kolm (x 1,..., x n ) + ISquale λ (x 1,..., x n ) = 1 log λ log ( 1 n n i=1 elog λ( x x i) ) ( log 1 λ n 1 log λ log ( 1 n n i=1 λ x x i) 1 log λ log ( 1 n ( ( i) n i=1 λ x = 1 log λ log 1 n λ x n ( i) i=1 λ x log 1 n (log 1 n λ x n ) 1 log λ = 1 1 n i=1 λ x i n i=1 λ x i log λ (log λ x ) = x Qui prouve que le Lemme est vrai. n ) i=1 λ x i = n )) i=1 λ x i = En plus d établir une relation entre I Kolm et I Squale, le Lemme 1 nous permet de prouver une importante propriété de I Squale : le principe d anti-transfert. Fondé sur le lemme 1, la proposition 2 prouve que I Squale garantit que les améliorations ultérieures de la qualité se reflètent dans le résultat de l évaluation agrégée de la qualité. Par exemple, considérant que la valeur de SLOC (nombre de lignes de code source) doit être inférieure à 36 lignes (voir section en page 130), si une méthode a pour valeur initiale 60 lignes par exemple et que sa valeur est diminuée ensuite de 20 tandis qu une autre méthode est pour sa part augmentée de 20 (les lignes de code sont transférées dans une autre méthode de manière similaire, i.e., le nombre de lignes ôtées de la première méthode est égale au nombre de lignes ajoutées à l autre méthode), alors ceci a pour effet d augmenter la note globale calculée avec la formule I Squale. Nous appelons cette propriété de I Squale le principe d anti-transfert, par analogie avec le principe des transferts [Kolm, 1976] satisfait par divers indices d inégalité [Cowell, 2000] y compris les indices I Kolm. Proposition 2. Soit x i < x j et soit δ > 0 tels que x i + δ x j δ. Alors, ISquale λ satisfait le principe d anti-transfert, i.e., ISquale λ (x 1,..., x i,..., x j,..., x n ) < ISquale λ (x 1,..., x i + δ,..., x j δ,..., x n ). Démonstration. I Kolm est connu pour satisfaire le principe de transferts [Kolm, 1976], i.e., pour tout β il s avère que I β Kolm (x 1,..., x i,..., x j, x n ) > I β Kolm (x 1,..., x i + δ,..., x j δ,..., x n ), pour x i, x j, δ comme ci-dessus. Du lemme 1 nous avons I log λ Kolm (x 1,..., x n ) = mean(x 1,..., x n ) I λ Squale (x 1,..., x n ), et I log λ Kolm (x 1,..., x i +δ,..., x j δ,..., x n ) = mean(x 1,..., x i +δ,..., x j δ,..., x n ) I λ Squale (x 1,..., x i + δ,..., x j δ,..., x n ) = mean(x 1,..., x i,..., x j,..., x n ) I λ Squale (x 1,..., x i + δ,..., x j δ,..., x n ). Ces observations préliminaires indiquant que la formule I Squale et les indices d inégalités économiques possèdent une base de propriétés communes, associées aux propriétés mathématiques des indices d inégalité économiques (voir Section ) nous ont orientés vers une étude plus poussée de ces deux types d agrégation. Nous avons donc complété notre étude par une comparaison empirique de ces formules ainsi que par une évaluation des indices économiques et de I Squale par rapport 133

148 Chapitre 5. Evaluation de la qualité dans Squash aux exigences définies dans la section 3.5. Ces points sont abordés dans le chapitre suivant (voir les sections et 6.2). 5.3 L évaluation de la qualité à travers les pratiques documentaires Ces pratiques reposent sur des analyses faites par des experts car elles ne peuvent être évaluées de manière automatique, à partir de métriques. Certaines pratiques de type documentaires, donc évaluées par un expert, sont classées dans les pratiques de modèle ou de tests car elles sont directement liées au modèle ou aux tests. Cependant, leur mode d évaluation est identique à celui décrit ci-après. L ensemble des pratiques documentaires définies pour le modèle Squash est résumé dans le tableau 5.3 et détaillé en Annexe A.5. Table 5.3 Les pratiques documentaires du modèle Squash Nom de la pratique Définition Qualité de la documentation qualifie la documentation technique par rapport à la méthodologie Découpage en couches vérifie la présence d un dossier de spécifications techniques validé Organisation générale du code qualifie l organisation du code de manière macroscopique Design-pattern évalue les mécanismes articulant la cinématique de l application Dossier d architecture technique qualifie la présence d un DAT validé Choix des technologies vérifie le choix des technologies et leur adéquation avec les besoins Correspondance entre couche et nommage vérifie la conformité des noms des packages avec le découpage Respect des règles de sécurité de l entreprise : dossier de conception technique vérifie les règles de sécurité du DCT Partie sécurité du cahier des charges vérifie les règles de sécurité du cahier des charges Conformité implémentation/définition sécurité vérifie que les règles de sécurité sont respectées Dossier de production vérifie l existence et la pertinence du dossier de production Les valeurs des caractéristiques des pratiques documentaires Comme expliqué dans la section 3.4.4, certaines pratiques reposent sur des avis humains qu il est difficile d interpréter directement sous forme d une évaluation numérique précise. Le calcul des notes de ces pratiques dans Squale nous est apparu trop superficiel pour être réellement pertinent. Nous avons donc adopté dans Squash une autre méthode de calcul de ces pratiques. En nous inspirant de la méthode d évaluation du modèle McCall telle que nous l avons présentée dans la section 3.4.4, nous avons tout d abord établi une liste de caractéristiques à évaluer pour chacune des pratiques documentaires. Puis, nous avons cherché comment évaluer cette liste, en utilisant une échelle de termes linguistiques ad hoc pour recueillir les avis des experts sur ces listes. Nous nous sommes donc intéressés à la logique floue pour déterminer dans quelle mesure cette dernière pouvait nous aider à chiffrer au plus juste les caractéristiques évaluées par un expert. 134

149 5.3. L évaluation de la qualité à travers les pratiques documentaires Le modèle de Herrera & Martínez Les approches linguistiques fondées sur les sous-ensembles flous ont prouvé leur efficacité pour la modélisation de l information qualitative. Cette approche consiste à estimer des valeurs linguistiques à l aide de variables linguistiques dont les valeurs ne sont pas des nombres mais des mots issus d un langage artificiel ou naturel [Zadeh, 1975]. Les valeurs linguistiques sont modélisables grâce à des sous-ensembles flous [Zadeh, 1965] qui permettent de capturer les imprécisions du langage. Les paliers obtenus en notation discrète (discutés dans la section 3.4.4) sont ainsi lissés et amènent à une expression plus fine des notes. Parmi les modèles existants pour représenter l information imprécise, nous nous sommes intéressés aux 2-tuple linguistiques de Herrera & Martínez : ils utilisent des sous-ensembles flous très simples combinés à une valeur de décalage. Dans ce modèle, les fonctions d appartenance (les sous-ensembles flous) triangulaires sont suffisantes pour capturer l imprécision des propositions. Tout d abord, nous devons choisir des descripteurs linguistiques appropriés pour former l ensemble de termes attaché à chaque univers de discours. Comme c est souvent l usage, on prendra des ensembles de termes à cardinalité impaire (5, 7 ou 9) pour être en mesure de représenter un terme milieu. Considérons par exemple l ensemble T ordonné constitué des cinq termes suivants : T = {s 0 : complètement faux, s 1 : plutôt faux, s 2 : ni vrai ni faux, s 3 : plutôt vrai, s 4 : complètement vrai}. Il est aussi habituellement requis qu il y ait les trois opérateurs usuels Neg, max et min définis sur T [Herrera et Martínez, 2001] : 1. Neg(s i ) = s j tel que j = g i (avec g + 1 la cardinalité), 2. max(s i, s j ) = s i si s i s j, 3. min(s i, s j ) = s i si s i s j. Etant donné un terme linguistique, le formalisme 2-tuple fournit un couple (sous-ensemble flou, translation symbolique) = (s i, α) avec α [ 0.5, 0.5[ comme on peut le voir sur la figure 5.2 où le 2-tuple obtenu est (s 2, 0.3). α permet de supporter les calculs sans perte d information, lorsque le résultat ne coïncide pas exactement avec l un des sous-ensembles de départ. α = 0.3 s 0 s 1 s 2 s 3 s 4 Figure 5.2 Déplacement latéral d une étiquette linguistique le 2-tuple (s 2, 0.3). En utilisant ce modèle pour faire des calculs et exprimer leur résultat, on affiche une valeur solution égale à l un des éléments de l ensemble de départ affecté d une certaine modification α. Ainsi, si α est positif, s i est renforcé, sinon, s i est affaibli. 135

150 Chapitre 5. Evaluation de la qualité dans Squash Si l information est parfaitement répartie (i.e. si la distance séparant les termes est toujours exactement la même), tous les s i sont uniformément distribués sur l axe. Mais si ce n est pas le cas ce qui peut arriver lorsqu on modélise une opinion (un avis d expert) d excellent à insuffisant, par exemple, cf. Figure 5.3 les s i ne doivent pas être équidistants sur leur axe. insuffisant moyen assez bien bien excellent Figure 5.3 Notes non uniformément distribuées sur l axe. On parle alors d information linguistique multigranulaire et on utilise des hiérarchies linguistiques composées d un nombre impair de sous-ensembles flous, également répartis sur l axe (ces derniers forment une partition floue) [Herrera et al., 2008]. Une hiérarchie s écrit l(t, n(t)) avec t le numéro de la hiérarchie et n(t) le nombre de sous-ensembles flous de la hiérarchie. Un terme linguistique peut ainsi avoir une ou deux hiérarchies linguistiques et une opinion peut être représentée à l aide de plusieurs hiérarchies. De ce fait, les sous-ensembles obtenus ont toujours une forme triangulaire mais pas nécessairement isocèle. En guise d exemple, la figure 5.4 montre ce que l on obtient pour les cinq notes insuffisant à excellent (le dernier graphique est la partition floue finale). La notation s j i permet en outre de conserver la hiérarchie attachée au terme, j correspondant à n(t). Ainsi, s 3 0 est exprimé dans une hiérarchie à 3 étiquettes et représente la note insuffisant, s 5 2 dans une hiérarchie à 5 étiquettes et représente la note moyen, etc. (s 9 7,.15) correspond donc à une note que l on pourrait qualifier de presque bien. Ce modèle de logique floue permet donc de représenter de manière pas obligatoirement uniformément distribuée des informations linguistiques. De plus il permet d effectuer des calculs tels que des agrégations de valeurs tout en conservant précisément les décalages obtenus (grâce à α, le second terme du 2-tuple). Nous avons donc utilisé leur approche pour l évaluation de nos pratiques documentaires L évaluation des caractéristiques de Squash Dans le cadre de Squash, nous avons choisi les termes linguistiques [excellent, bien, assez bien, moyen, insuffisant] répartis selon l échelle de la figure 5.3. Ces termes permettront à l expert d évaluer les caractéristiques d une pratique documentaire donnée. Cette représentation traduit les exigences attendues en terme de qualité dans le modèle Squash : les caractéristiques qui n atteignent pas la moyenne sont recalées tandis que celles au dessus de la moyenne sont classées plus finement pour déterminer de manière plus précise leur niveau de qualité. L idée est d utiliser une échelle qui soit symboliquement similaire aux formules utilisées pour calculer les notes individuelles des pratiques de code. En effet, ces formules ont été choisies pour faire chuter les notes en dessous de un rapidement, passé un certain seuil, et pour affiner la note obtenue dans l intervalle [1; 3]. Ce même principe sous-tend le choix de notre échelle. Chaque caractéristique est donc représentée selon le modèle détaillé dans le tableau 5.4. La première ligne du second tableau tableau donne les sous-ensembles flous associés aux termes linguistique selon l échelle choisie, le seconde ligne donne les sous-ensembles flous ramenés dans une échelle 136

151 5.3. L évaluation de la qualité à travers les pratiques documentaires s 3 0 l(1, 3) s 5 2 l(2, 5) s 9 6 s 9 7 s 9 8 l(3, 9) s 3 0 s 5 2 s 9 6 s 9 7 s 9 8 Hiérarchie linguistique à 3 niveaux (s 9 7,.15) insuffisant moyen assez bien bien excellent Figure 5.4 Exemple de partition floue utilisant une hiérarchie linguistique à 3 niveaux. commune. Cette façon de représenter les informations des pratiques documentaires nous permet également une évaluation individuelle précise de chacune des caractéristiques : en cas de mauvaise note attribuée à une pratique, le détail des caractéristiques nous renseigne directement sur ce qu il faut améliorer pour parvenir à augmenter le niveau de qualité. Cette évaluation individuelle joue ici le même rôle que les notes individuelles des pratiques de code. Prenons l exemple de la pratique qualité de la documentation déjà utilisée dans la section Le tableau 3.9 de la page 101 définit ses caractéristiques et y associe les valeurs suivantes : oui, partiel et non. A partir de ces premiers travaux, nous avons défini un nouveau tableau 5.5, qui différencie les caractéristiques de type binaire oui, non aux caractéristiques plus complexes auxquelles sont associées cette fois les termes linguistiques [excellent, bien, assez bien, moyen, insuffisant]. Ainsi, les caractéristiques de type binaire telles que C 1 et C 4 sont modélisées pour les calculs comme des 2-tuple dans une hiérarchie à 2 étiquettes seulement : s 2 0 et s2 1, sachant que s2 0 correspond à non et s 2 1 correspond à oui. Les autres caractéristiques sont modélisées dans une hiérarchie à trois niveaux telle que décrite précédemment (voir les figures 5.4 et 5.3). 137

152 Chapitre 5. Evaluation de la qualité dans Squash Table 5.4 Modèle de représentation d une caractéristique et les 2-tuple associés. Terme linguistique oui non Caractéristique de type binaire s 2 1 s 2 0 Terme linguistique excellent bien assez bien moyen insuffisant Caractéristique non binaire s 9 8 s 9 7 s 9 6 s 2 5 s 3 0 Caractéristique non binaire s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 Table 5.5 Liste des caractéristiques et de leur 2-tuple associé pour la pratique qualité de la documentation. Nom Caractéristique oui non C1 Existence de la documentation technique s 2 1 s 2 0 C4 Existence des normes et des règles de mise à jour s 2 1 s 2 0 Nom Caractéristique excellent bien assez bien moyen insuffisant C2 La documentation est complète s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 C3 Mise à jour de la documentation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 C5 Suivi des règles s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 C6 Pertinence de la documentation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 C7 Remplissage des templates s 9 8 s 9 7 s 9 6 s 9 4 s

153 5.3.2 L agrégation des caractéristiques 5.3. L évaluation de la qualité à travers les pratiques documentaires Les caractéristiques une fois définies avec leurs différentes valeurs, nous nous sommes alors attelés à agréger celles-ci pour parvenir à évaluer la pratique. Il s agit ici de savoir comment exprimer le résultat d un processus cognitif ou encore exprimer le résumé d un ensemble de données quelconques par une réponse agrégée, représentative ou encore émergente [Truck, 2002]. Les opérateurs OWA Supposons que l on souhaite agréger les évaluations suivantes : moyen, assez bien, bien, assez bien, assez bien, assez bien que l on note : (s 5 2, 0), (s9 6, 0), (s9 7, 0), (s9 6, 0), (s9 6, 0), (s9 6, 0). Tout d abord, il faut les exprimer dans une hiérarchie commune. On prend la hiérarchie la plus fine (s 5 2 devient donc s 9 4 ) et on obtient les nouvelles valeurs à agréger : (s9 4, 0), (s9 6, 0), (s9 7, 0), (s9 6, 0), (s9 6, 0), (s9 6, 0) Ensuite, on choisit l opérateur, par exemple une moyenne arithmétique, qui utilise uniquement les i. L agrégation est donc égale à : ( )/ = (s 9 6,.16). Le résultat se trouve donc avant s 9 6. Dans cette zone, la hiérarchie utilisée est à 5 étiquettes (cf. Figure 5.4). Ainsi, il faut renommer (s 9 6,.16) en (s5 3,.08) (α doit être divisé par deux puisque la hiérarchie est deux fois plus grossière). La réponse est donc (assez bien,.08) que l on peut garder telle quelle si d autres calculs sont à venir ou bien nommer linguistiquement : quasiment assez bien. Il faut remarquer que notre système utilise 3 hiérarchies différentes réparties comme telles : les valeurs comprises entre s 3 0 et s5 2 sont dans une hiérarchie à 3 étiquettes, les valeurs comprises entre s 5 2 et s9 6 sont dans une hiérarchie à 5 étiquettes et les valeurs supérieures sont dans une hiérarchie à 9 étiquettes, comme le montre la figure 5.4. Ainsi, pour agréger les valeurs des évaluations, nous devons tout d abord passer dans une hiérarchie commune à 9 étiquettes et exprimer le résultat dans cette hiérarchie. Il faut ensuite repasser dans la hiérarchie multiple en fonction de la valeur obtenue : pour les résultats compris entre s 3 0 et s5 2 nous divisons α par 4, pour les résultats compris entre s5 2 et s 9 6 nous divisons par 2. Enfin,le tableau 5.6 donne le détail de la conversion à effectuer pour obtenir la valeur finale de α. Cet agrégateur très simple peut facilement être remplacé par d autres opérateurs. Par exemple, nous avons retenu les OWA pour Ordered Weighted Averaging operators. Cette famille d opérateurs a été introduite par Yager pour fournir un moyen d agréger des objets en satisfaisant plusieurs critères. Les OWA sont à la fois conjonctifs et disjonctifs : on peut agréger des objets en établissant que tous les critères ou certains critères ou au moins un critère, ou etc. doivent être satisfaits, tout en ayant des pondérations sur chaque critère [Yager, 1988]. Les OWA se définissent de la sorte : Un opérateur d agrégation A, A : [0, 1] n [0, 1], est appelé un OWA de dimension n s il est associé à un vecteur de pondération W : w 1... w n tel que w j [0, 1], n i=1 w i = 1 et A(x 1, x 2,..., x n ) = n j=1 w jy j et où y j est le j-ième plus grand élément des {x 1, x 2,... x n }. On remarque que, lorsque W = (1, 0, 0,..., 0) (i.e. tous les poids sont nuls sauf le premier), l opérateur est un max. De même, lorsque W = (0, 0,..., 0, 1) (i.e. tous les poids sont nuls sauf le 139

154 Chapitre 5. Evaluation de la qualité dans Squash Sous-ensemble Valeur de α Opération s 9 0 positive α/4 s 9 1 négative 0, 125 α/4 s 9 1 positive 0, 5 + α/4 s 9 2 négative 0, 5 + α/4 s 9 2 positive 0, 5 + α/4 s 9 3 négative 0, α/4 s 9 3 positive 0, 125 α/4 s 9 4 négative α/4 s 9 4 positive α/2 s 9 5 négative 0, 5 + α/2 s 9 5 positive 0, 5 + α/2 s 9 6 négative α/2 Table 5.6 Calcul de la valeur finale de α. dernier), l opérateur est un min. Enfin, lorsque W = (1/n, 1/n,..., 1/n) (i.e. tous les poids sont égaux), l opérateur est une moyenne arithmétique. L agrégation des caractéristiques de Squash Les OWA permettent de pondérer une caractéristique en fonction de son importance pour le calcul de la note finale. Nous utilisons donc ce type d agrégation pour nos pratiques. Par exemple, le tableau 5.7 regroupe les caractéristiques qui définissent la pratique qualité de la documentation avec les valeurs linguistiques et les poids associés à chacune. La somme des poids atteint le total de 1. Pour être au plus près des exigences de notre modèle, à chaque pratique est associé un algorithme de calcul des notes afin de prendre en compte certaines caractéristiques bloquantes dans le calcul de la note. Par exemple, dans ce cas précis, la caractéristique Existence de la documentation technique est dite bloquante. En effet, s il n existe pas de documentation technique, il s agit alors d un défaut majeur et la note de la pratique est immédiatement de 0. L algorithme associé à la pratique qualité de la documentation est le suivant : On note GM la note de la pratique, s C1 le terme linguistique s j i associé à la caractéristique C 1 et choisi par l expert la personne qui juge la qualité des caractéristiques, s C2 le terme linguistique associé à C 2, etc. On note w 1 le poids associé à C 1, w 2 le poids associé à C 2, etc. if s C1 == s 1 0 then GM = 0 else if s C2 == s 9 0 then GM = 1 else 7 GM = w k.s Ck 140 k=1 GM est converti en 2-tuple ou conservé sous forme complètement numérique, selon les besoins end if

155 5.3. L évaluation de la qualité à travers les pratiques documentaires Table 5.7 Liste des caractéristiques avec les valeurs et les poids associés qui qualifient la pratique qualité de la documentation. Nom Caractéristique oui non Poids C1 Existence de la documentation s 2 1 s 2 0 0, 2 technique C4 Existence des normes et des s 2 1 s 2 0 0, 1 règles de mise à jour Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C2 La documentation est complète s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C3 Mise à jour de la documentation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C5 Suivi des règles s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 C6 Pertinence de la documentation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 C7 Remplissage des templates s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 04 Une fois la note agrégée obtenue, nous devons alors la convertir en valeur numérique comprise dans l intervalle [0; 3] pour être en harmonie avec les notes du modèle. Rappelons tout d abord les significations des notes de Squash : entre 0 et 1, le but n est pas atteint ; entre 1 et 2, le minimum est atteint mais avec des réserves ; entre 2 et 3, le but est atteint. insuffisant moyen assez bien bien excellent ,5 3 Figure 5.5 Echelle de conversion numérique de la note Squash évalue la qualité. Selon ce principe, une appréciation moyenne ne peut pas être considérée suffisante d un point de vue qualité. Il faut être au dessus de la moyenne pour obtenir une note qualitative correcte : avoir atteint le but mais avec des réserves. Le terme moyen prend donc le sens suivant dans le cadre du modèle : une appréciation moyenne correspond à un but atteint mais avec réserves et non pas à un but suffisant. En rapportant les significations des notes du modèle aux termes linguistiques choisis, les notes deviennent donc : les notes autour de insuffisant se traduisent par : presque nul ; les notes autour de moyen se traduisent par : minimum absolument pas atteint pour les notes inférieures à moyen et minimum atteint avec réserves pour les notes supérieures à moyen ; les notes autour de assez bien se traduisent par : minimum atteint avec réserves pour les notes inférieures à assez bien et but atteint pour les notes supérieures à assez bien ; 141

156 Chapitre 5. Evaluation de la qualité dans Squash les notes autour de bien se traduisent par : but atteint pour les notes inférieures à bien et but atteint presque parfaitement pour les notes supérieures à bien ; les notes autour de excellent se traduisent par but parfaitement atteint. La conversion numérique se fait alors selon l échelle de la figure 5.5, avec α la translation symbolique (le second terme du 2-tuple) : les notes supérieures à s 3 0 (supérieures à insuffisant) sont converties en 0 + α ; les notes inférieures à s 5 2 (inférieures à moyen) sont converties en 1 α ; les notes supérieures à s 5 2 (supérieures à moyen) sont converties en 1 + α ; les notes inférieures à s 9 6 (inférieures à assez bien) sont converties en 2 α ; les notes supérieures à s 9 6 (supérieures à assez bien) sont converties en 2 α/2 ; les notes inférieures à s 9 7 (inférieures à bien) sont converties en 2, 5 α/2 ; les notes supérieures à s 9 7 (supérieures à bien) sont converties en 2, 5 α/2 ; les notes inférieures à s 9 8 (inférieures à excellent) sont converties en 3 α/2. Les notes comprises dans l intervalle [insuffisant; assez bien] sont sur une échelle deux fois plus grande que les notes comprises dans l intervalle [assez bien; excellent], d où la division de α par 2. La conversion des notes s 2 1 et s2 0 qui traduisent une caractéristique vrai ou fausse se fait de manière particulière : la valeur s 2 1 signifie que la caractéristique existe, ce qui, d un point de vue qualité ne signifie pas obligatoirement une valeur excellente mais plutôt une valeur à minima, d où notre choix de traduire cette valeur par moyen. La valeur s 2 0 peut être pour sa part, soit bloquante et donc la note de la pratique est égale à 0, soit non-bloquante et dans ce cas elle correspond à la valeur insuffisant. Ceci permet donc d obtenir une note dans l intervalle [0; 3] de manière continue et pondérée : d une part les différentes caractéristiques sont pondérées pour refléter leur importance par rapport à la pratique mais également les unes par rapport aux autres, d autre part la transposition des termes linguistiques en note se fait de manière continue. D autre part, ce système de notation des pratiques reposant sur des données brutes peut être étendue à tout autre type de notation. En effet, les 2-tuple peuvent peuvent traduits dans n importe quelle autre échelle de valeur, la conversion numérique n étant pas rattachée à ce type de notation préliminaire. Ainsi, il peut donc être envisagée de convertir le 2-tuple final dans un autre système de notation L exemple d une pratique documentaire Soit la pratique Validation du cahier des charges ayant les propriétés suivantes : définition : Vérifie l existence et la procédure de validation du cahier des charges qui décrit les spécificités fonctionnelles liées au projet. composant : projet. tableau des caractéristiques : 142 Nom Caractéristique oui non Poids C1 Existence d un cahier des s 2 1 s 2 0 0, 25 charges

157 5.3. L évaluation de la qualité à travers les pratiques documentaires Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Clarté du cahier des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 charges (est-il explicite?) C3 Classement des exigences (métier, tech- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 nique, etc.) C4 Précision et détail du s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 cahier des charges C5 Validation du cahier des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 14 charges par une procédure formelle, détaillée note globale : if s C1 == s 2 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 Cette pratique détermine la qualité générale du cahier des charges. Les caractéristiques choisies pour y parvenir contrôlent les points suivants : le cahier des charges doit être explicite, les exigences doivent être classées pour distinguer à quel ensemble elles appartiennent (exigence métier, exigence technique, exigence fonctionnelle, etc.), le cahier des charges doit être suffisamment détaillé et le cahier des charges doit être validé selon une procédure formelle et détaillée. Le tableau 5.8 montre trois exemples d évaluation de ces caractéristiques. La traduction des exemples en valeurs linguistiques est donné dans le tableau 5.9. L expert n a pas à se soucier de cette traduction qui est faite de manière automatique, après son évaluation. Il donne simplement un avis en termes linguistiques clairs. La première colonne du tableau 5.8 signifie que le projet 1 a les caractéristiques suivantes : le cahier des charge existe, sa validation est excellente, il est bien détaillé, il est assez bien explicite mais le classement des exigences est moyen. La note finale de la pratique est calculée selon l algorithme 5 cité précédemment : GM = w k.s Ck, soit 0, 25 s , 25 s , 16 s , 2 s , 14 s9 8, en k=1 appliquant pour chacune des valeurs linguistiques les poids correspondant attribués pour la pratique (détaillés précédemment dans la description de ses propriétés). En exprimant l agrégation dans une hiérarchie commune, on obtient alors 0, 25 s , 25 s , 16 s , 2 s , 14 s9 8. Selon le mode de calcul de la note expliqué dans la section 5.3.2, cette formule équivaut à 0, , , , , 14 8 = 5, 66 en additionnant les i des sous-ensembles flous. Nous traduisons ensuite ce résultat sous forme de 2-Tuple. Le résultat obtenu se situe avant s 9 6, soit (s9 6,.34). Dans cette zone nous sommes en hiérarchie à 5 étiquettes, ce qui se traduit donc par (s 5 3,.17) (selon le tableau 5.6) et la pratique obtient comme résultat : minimum atteint avec réserves. La note peut être ensuite convertie selon l échelle de correspondance décrite précédemment, ce qui revient à : 2 0, 17 = 1, 83. Il paraît effectivement raisonnable d estimer que cette pratique est au dessus de 143

158 Chapitre 5. Evaluation de la qualité dans Squash Table 5.8 Exemple de valeurs attribuées aux caractéristiques de la pratique Validation du cahier des charges. Nom Caractéristique Projet 1 Projet 2 Projet 3 C1 Existence d un cahier des charges oui oui oui C2 Clarté du cahier des charges (est-il explicite?) C3 Classement de exigences (métier, technique, etc.) C4 Précision et détail du cahier des charges C5 Validation du cahier des charges par un procédure formelle, détaillée assez bien moyen insuffisant moyen assez bien assez bien bien moyen insuffisant excellent excellent excellent 1, seuil qui correspond à un minimum atteint avec réserves, puisque les principales caractéristiques sont satisfaites mais que le cahier des charges n est pas totalement explicite et que la caractéristique de classement des exigences est moyenne. Le projet 2 a pour sa part les caractéristiques suivantes : le cahier des charge existe, sa validation est excellente, le classement des exigences est assez bien mais il est moyennement détaillé et moyennement explicite. Ce qui donne donc : 0, 25 s , 25 s , 16 s , 2 s , 14 s9 8, soit, 0, , , , , 14 8 = 4, 88. Sa note est donc (s 9 5,.12). Or dans cette zone, la hiérarchie utilisée est à 5 étiquettes. Il obtient donc la note de (s 5 2, +.44) (puisqu on passe dans une hiérarchie 2 fois plus grossière donc il faut diviser α par 2), soit minimum atteint avec réserves, et une note globale de 1 + 0, 44 = 1, 44. Ce qui est raisonnable étant donnée que le cahier ces charges n est que moyennement détaillé et explicite. Il obtient donc une note moins élevée que le projet précédent. Le projet 3 a pour sa part les caractéristiques suivantes : le cahier des charge existe, sa validation est excellente, le classement des exigences est assez bien mais il est insuffisamment détaillé et insuffisamment explicite. Ce qui donne donc : 0, 25 s , 25 s , 16 s , 2 s , 14 s9 8, soit, 0, , , , , 14 8 = 3, 08. Sa note est donc (s 9 3, +.08). Or dans cette zone, la hiérarchie utilisée est à 3 étiquettes et il faut donc diviser α par 4. Il obtient donc la note de (s 5 2,.145), soit minimum absolument pas atteint, et une note globale de 1 0, 145 = 0, 855. En effet ; les caractéristiques du cahier des charges sont insuffisantes pour obtenir une note supérieure à 1 (le cahier des charges est insuffisamment détaillé et explicite). 5.4 Conclusion Dans ce chapitre nous avons validé les formules de combinaison et d agrégation définies dans le modèle Squale et utilisées dans le modèle Squash. Nous avons notamment établi que la formule I Squale permet d obtenir une valeur plus fine qu une simple moyenne ou une moyenne pondérée. 144

159 5.4. Conclusion Table 5.9 Traduction en valeurs linguistiques de l évaluation des experts pour les exemples du tableau 5.8. Nom Caractéristique Projet 1 Projet 2 Projet 3 C1 Existence d un cahier des charges s 2 1 s 2 1 s 2 1 C2 Clarté du cahier des charges (est-il explicite?) s 9 6 s 9 4 s 9 0 C3 Classement de exigences (métier, technique, etc.) s 9 4 s 9 6 s 9 6 C4 Précision et détail du cahier des charges s 9 7 s 9 4 s 9 0 C5 Validation du cahier des charges par un procédure formelle, détaillée s 9 8 s 9 8 s 9 8 Note de la pratique (s 9 7,.16) (s5 3, +.12) (s5 2, +.4) 1, 66 1, 6 0, 54 Nous avons également présenté le nouvelle évaluation des pratiques documentaires de Squash, à savoir les pratiques reposant sur des données brutes et donc non issues de métriques. Chaque pratique documentaire possède sa propre liste de caractéristiques évaluées à partir de formules de logique floue issues des travaux de Herrera et Martínez. Dans le chapitre suivant, nous présentons nos travaux de validation du modèle Squash. 145

160 Chapitre 5. Evaluation de la qualité dans Squash 146

161 Chapitre 6 Validation du modèle Squash Sommaire 6.1 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 Dans ce chapitre nous validons différents points de nos recherches. Tout d abord, nous vérifions en quoi les exigences définies dans la section 3.5 sont vérifiées par les indices d inégalité économiques (Section 6.1.1) puis par la formule I Squale (voir Section 6.1.2) et enfin par les pratiques documentaires (Section 6.1.3). Ensuite nous détaillons (dans la section 6.2) l expérience de validation empirique de I Squale que nous avons menée et nous expliquons en quoi la formule I Squale et les indices d inégalité économiques sont satisfaisants pour agréger les notes individuelles des pratiques de code (Section 6.2.4). Enfin, nous validons le modèle Squash (Section 6.3) par rapport aux propriétés définies préalablement dans la section et nous présentons l implémentation de Squash et son utilisation actuelle selon les différents acteurs qui utilisent Squash (Section 6.4). 6.1 Validation des exigences d évaluation La section 3.5 définit un certain nombre d exigences pour l évaluation de la qualité logicielle. Dans cette section nous présentons en quoi les indices d inégalité économiques ainsi que les formules d évaluation utilisées dans le modèle Squash satisfont ces exigences. 147

162 Chapitre 6. Validation du modèle Squash La validation des exigences d évaluation des indices d inégalité économiques Les indices d inégalité économique nous apparaissent comme étant des outils d agrégation pertinents. Nous expliquons ici en quoi ils satisfont les exigences d évaluation de la qualité logicielle. La section rappelle un certain nombre de propriétés mathématiques des indices d inégalité économique et explique en quoi certains indices satisfont l exigence de décomposition. De plus, les exigences telles que la symétrie, l invariance ou la transposabilité ont déjà été discutées (voir le tableau 3.7 en page 99). Il faut également rappeler que les indices d inégalité ne constituent pas des modèles de qualité complets, par opposition à Squash, et en tant que tels n ont pas été conçus pour satisfaire ces exigences spécifiques au départ. Ainsi, ils ne sont pas destinés à être des outils de combinaison mais plutôt des outils d agrégation, tout comme la formule I Squale seule. De plus, de part leur conception initiale (à savoir des formules de mesure d inégalité), les indices d inégalité économiques peuvent parfois masquer les progrès, mais uniquement dans des situations extrêmes. En effet, elles peuvent diminuer (alors qu elles devraient augmenter) si on passe d une situation telle que toutes les valeurs de qualité sont mauvaises à une situation telle que toutes les valeurs de qualité sont bonnes. 148 Les indices d inégalité économiques vérifient donc les exigences suivantes : combinaison : cette exigence n est pas vérifiée par les indices utilisés seuls mais il suffit de les coupler à des formules de combinaison pour obtenir un système d évaluation complet ; agrégation : cette exigence est vérifiée comme le prouve les travaux de Serebrenik et Vasilescu et notre expérience décrite dans la section suivante ; domaine et intervalle de combinaison/agrégation de mesures : comme expliqué dans la section , certains indices ont des domaines de définition qu il faut prendre en compte et ne peuvent être utilisés directement avec certaines métriques ; mettre en évidence des problèmes : nous expliquons dans l expérience qui suit en quoi les indices satisfont cette exigence de manière adéquate dans la plupart des cas ; ne pas masquer les progrès : Comme rappelé précédemment, les indices peuvent parfois masquer les progrès mais uniquement dans des cas spécifiques (comme passer d un système où tous les composants sont mauvais à un système ou tous les composants sont bons) ; décomposition : certains indices satisfont cette exigence comme cela a été discuté dans la section ; combiner avant d agréger : les indices n étant pas utilisés pour effectuer des opérations de combinaison, cette exigence n est pas satisfaite ; intervalle de l agrégation : les indices satisfont à cette exigence comme le montre leurs propriétés mathématiques (voir Section ) ; symétrie : certains indices satisfont cette exigence comme cela a été discuté dans la section ; normalisation de l évaluation : les indices d inégalité économiques ne normalisent pas les résultats mais ont leur propre échelle de valeurs ; invariance et transposabilité : certains indices satisfont ces exigences comme cela a été discuté dans la section

163 6.1. Validation des exigences d évaluation La validation des exigences d évaluation de la formule I Squale Nous expliquons ici en quoi la notation des pratiques de code valide ou non les exigences d évaluation de la qualité logicielle. Nous prenons en compte à la fois la combinaison effectuée lors du calcul des notes individuelles et l agrégation effectuée avec la formule I Squale. combinaison : cette exigence est remplie par le calcul des notes individuelles. En effet, les notes individuelles sont par définition des combinaison de métriques ; agrégation : cette exigence est remplie par le calcul des notes globales. En effet, la formule I Squale est une formule d agrégation ; domaine et intervalle de combinaison/agrégation de mesures : l intervalle utilisé comme résultat des notes individuelles est [0, 3], ce qui est compatible avec la définition de la fonction d agrégation ISquale λ ; mettre en évidence des problèmes : le calcul des notes individuelles utilise des formules différentes selon les pratiques. Ces formules ont été établies pour mettre en évidence les composants ne respectant pas les définitions des pratiques. Elles répondent donc à cette exigence. Le calcul des notes globales s effectue pour sa part à partir de la formule d agrégation de Squale. Cette dernière, comme le montre la proposition 1, donne plus de poids aux mauvaises notes individuelles qu une simple moyenne arithmétique, quel que soit le coéfficient de pondération utilisé ; ne pas masquer les progrès : nous prouvons dans la section (Proposition 2) que la formule Squale satisfait à cette exigence ; décomposition : la proposition 3 discutée ci-après montre que ISquale λ n est pas décomposable ; combiner avant d agréger : Squash applique l agrégation aux résultats de combinaison de métriques ; intervalle de l agrégation : l intervalle d agrégation de I Squale est toujours [0, 3]. Cette formule est continue et bornée ; symétrie : cette exigence n est généralement pas applicable pour la combinaison. En revanche ISquale λ satisfait cette exigence ; normalisation de l évaluation : l ensemble des notes individuelles et globale suit toujours le même intervalle de résultat [0, 3] ; invariance et transposabilité : la proposition 4 (ci-après) montre que ISquale λ est transposable quel que soit λ R, λ 0, λ 1. Donc ISquale λ n est invariant ni par rapport à l addition, ni par rapport à la multiplication. Nous discutons ici des propriétés de décomposition et d invariance de I Squale : Proposition 3. ISquale λ n est pas décomposable selon le principe établi dans la section Démonstration. Rappelons qu une agrégation de technique I est décomposable (telle que présenté dans la section ) pour toute collection de nombres réels x 1, x 2,..., X n et tout partitionnement mutuellement exclusif et collectivement exhaustif (le principe MECE) = {G 1, G 2,..., G m } s il satisfait : 1. I = I between,g + I within,g 3. I within,g = m i=1 w ii(g i ) 2. I between,g 0 4. m i=1 w i = 1 Supposons pour la contradiction que I Squale est décomposable. Alors, I Squale est décomposable pour une collection X constituée de n nombres égaux x, avec x > 0, pour un partitionnement de type MECE G qui place chaque nombre dans son propre groupe. Rappelons de que R = 1 149

164 Chapitre 6. Validation du modèle Squash pour les partitions qui considèrent tous les éléments de la population comme un groupe à part entière. Par conséquent, R X,G = 1. Par définition de R, R = Ibetween Squale (G) I Squale (X ) et R = 1 Iwithin Squale (G) I Squale (X ) car I = I between + I within. Ainsi, Iwithin Squale (G) I Squale (X ) = 0 et, puisque I Squale(X ) x > 0 (d après le théoreme 1), ISquale within (G) = 0. Cependant, ISquale within = n i=1 w ii Squale ({x}) = n i=1 w ix (by (3)). Puisque x > 0 il en découle que w i = 0 pour tout 1 i n, et donc, m i=1 w i = 0, contredit (4). Par conséquent, notre hypothèse était erronée et I Squale n est pas décomposable. Proposition 4. Soit x 1,..., x n des nombres réelles. Alors pour tout λ R, λ 0, λ 1 nous avons I λ Squale (x 1 + c,..., x n + c) = I λ Squale (x 1,..., x n ) + c. Démonstration. Pour constater que la proposition est vraie, on observe que ISquale λ (x ( 1+c,..., x n +c) = log 1 n λ n i=1 λ (x i+c) ) ( = log 1 n λ n i=1 (λ x i λ c ) ) ( = log λ c n λ i) n i=1 λ x = ( ( log 1 n λ i) n i=1 λ x + logλ λ c) = ( ( log 1 n ) ( λ i) n i=1 λ x + ( c) = 1 n logλ i) n i=1 λ x + c = ISquale λ (x 1,..., x n ) + c Validation des exigences pour les pratiques documentaires Nous expliquons ici en quoi les pratiques documentaires valident les exigences pour l évaluation de la qualité définies dans la section combinaison : cette exigence est partiellement remplie par les notes des caractéristiques, qui bien qu exprimées sous forme de 2-Tuple peuvent également être traduites sous forme numérique dans l intervalle [0; 3] selon la même échelle que la conversion de la note globale de la pratique ; agrégation : cette exigence est remplie par le calcul des notes globales avec les opérateurs OWA ; domaine et intervalle de combinaison/agrégation de mesures : cette exigence est remplie par les 2-Tuple qui s expriment dans un intervalle compatible avec la méthode d agrégation ; mettre en évidence des problèmes : les caractéristiques sont différenciées et précises, ce qui permet également de pointer directement les problèmes de manière fine, en fonction d une caractéristique et non d une règle générale (telle que dans le modèle Squale) définissant une pratique. Par exemple, la pratique qualité de la documentation définie avec une liste de caractéristique précise permet désormais de mettre en évidence la caractéristique déficiente. En revanche, nous avons choisi de ne pas renforcer le poids des mauvaises notes mais celui des caractéristiques en fonction de leur importance dans la pratique. Cela ne permet donc pas de mettre directement en évidence les caractéristiques ayant une mauvaise note mais plutôt d accentuer l importance des unes par rapport aux autres. Ceci nous a semblé plus judicieux puisque, contrairement aux notes individuelles des pratiques de code qui ont toutes la même valeur relative, les caractéristiques n ont effectivement pas la même importance les unes par rapport aux autres ;

165 6.2. Evaluation expérimentale des pratiques de code ne pas masquer les progrès : nous avons employé le formalisme à 2-tuple pour éviter tout effet de seuil et permettre également la transcription de toute modification, les progrès comme les régressions, contrairement au système de notation discrète utilisé précédemment dans Squale. De plus, contrairement aux pratiques de code, il n y a pas ici de principe de transfert, chaque caractéristique est indépendante l une de l autre (i.e., l amélioration de l une ne se fait pas aux dépends de l autre) ; décomposition : les caractéristiques s expriment au niveau du projet et ne peuvent être exprimées au niveau d une sous-partie du projet, cette propriété n est pas respectée ; combiner avant d agréger : les caractéristiques des pratiques documentaires sont notées individuellement avant d être agrégées ; intervalle de l agrégation : l intervalle d agrégation des pratiques documentaires est toujours [0, 3] ; Symétrie : la formule d agrégation des pratiques documentaires respecte cette propriété, le résultat de l agrégation est indépendant de l ordre des éléments regroupés ; normalisation de l évaluation : l ensemble des notes des pratiques documentaires suit toujours le même intervalle de résultat [0, 3] ; Bien que définies pour valider les formules de notation des pratiques de code, ces exigences sont donc en partie satisfaites par le système de notation des pratiques documentaires, notamment la notation dans un intervalle continu et borné qui permet de ne pas masquer les progrès mais également de mettre en évidence, pour une pratique donnée un défaut de qualité. 6.2 Evaluation expérimentale des pratiques de code Comme mentionné dans la section 3.5, un modèle de qualité doit agréger des métriques dans un intervalle normalisé et mettre en évidence les composants défectueux (d un point de vue qualité) pour avertir les développeurs de problèmes potentiels. Nous avons déjà expliqué dans la section que la formule I Squale satisfait cette exigence. Nous allons ici mettre en avant sa sensibilité aux problèmes et la comparer à d autres techniques d agrégation Conditions expérimentales. Afin de mieux évaluer le degré de sensibilité des techniques d agrégation classiques (les moyennes), des indices d inégalité économique et de I Squale, nous comparons leurs réactions en présence d une quantité toujours plus élevée de problèmes. Nous utilisons une expérience contrôlée dans laquelle la somme de problèmes peut être quantitative ou qualitative, et nous considérons deux variables indépendantes : la quantité de problèmes parmi une quantité connue de bons résultats : le pourcentage de notes imparfaites (en dessous de 3) ; la qualité des problèmes (le degré de mauvais résultats) dans une quantité connue de résultats parfaits : la répartition des mauvaises notes selon une échelle de valeurs correspondant à l échelle d interprétation des résultats de Squash ([2, 3[, [1, 2[, [0.5, 1[, [0.1, 0.5[ et [0, 0.1[). L évaluation porte sur le résultat final en fonction des techniques d agrégation. Nous utilisons les techniques d agrégation de I λ Squale avec λ = 3, λ = 9 et λ = 30 (les poids de la formule I Squale) et 151

166 Chapitre 6. Validation du modèle Squash les indices d inégalité économique I Theil, I MLD, I Gini, IAtkinson α, Iβ Kolm, I Hoover. Nous supposons des instanciations standards [Zeileis, 2009] pour IAtkinson α et Iβ Kolm avec α = 0.5 et β = 1, respectivement. Notre premier problème a été de trouver une étude de cas appropriée pour notre expérience. Un autre problème est de trouver un système qui peut fournir la variation dont nous avons besoin en quantité et qualité de mauvais résultats. Pour plus de commodité, nous avons choisi d utiliser Eclipse 2.0 comme banc d essai pour l expérience. Nous agrégeons les notes individuelles de la pratique taille de la méthode qui utilise la métrique SLOC (nombre de lignes de code source). Nous avons choisi une pratique utilisant une seule métrique pour permettre la comparaison avec les techniques d agrégation des indices d inégalité économiques qui n offrent pas de mécanismes de combinaison par défaut. Enfin, nous normalisons les résultats bruts de la métrique dans l intervalle [0, 3] comme défini dans Squash, même si les indices d inégalité économiques ne nécessitent pas cette étape. La fonction de normalisation sera celle définie par Air France-KLM (donnée dans la section 5.2.1). Le déroulement exact de l expérience procède comme suit : le système dispose d un total de 8612 méthodes, dont 8093 ont une note de 3. la base, les cas parfaits, est constituée de ces 8093 méthodes. En fait, le nombre de composants de cette base de cas parfaits est sans importance car ils ont tous la même note de 3 ; pour la variable indépendante quantité de problèmes, nous travaillons avec 8612 méthodes contenant une proportion donnée de méthodes imparfaites. Cette proportion varie de 10 % à 100 % par palier de 10 %. Par exemple, pour le test avec 10 % de méthodes imparfaites, nous avons une sélection aléatoire de 7751 méthodes parfaites et 861 methodes imparfaites, ce qui donne un total de 8612 méthodes ; lorsque nous avons besoin de méthodes plus imparfaites que le système n en contient en réalité, nous sélectionnons les mêmes plusieurs fois ; pour la variable indépendante qualité de problèmes, nous avons choisi des composants avec des notes comprises dans les intervalles suivants : [2, 3[, [1, 2[, [0.5, 1[, [0.1, 0.5[ et [0, 0.1[. Ces intervalles ont été choisis pour avoir une compréhension fine de ce qui se passe avec de mauvais résultats. Pour chaque traitement des notes, l expérience consistera dans le produit cartésien de toutes les valeurs pour les deux variables indépendantes. En outre, parce que chaque expérience consiste à sélectionner au hasard les éléments imparfaits, nous répétons l expérience 10 fois et gardons la moyenne de ces 10 résultats Résultats La figure 6.1 présente les résultats pour toutes les techniques d agrégation. Le premier graphique (en haut à gauche), donne les résultats pour la moyenne arithmétique. Il montre que même avec 30% de très mauvaises notes (méthodes imparfaites en [0, 0.1[), le résultat agrégé est encore 2 ce qui indique toujours une bonne qualité. Les résultats de ce premier graphique sont répétées dans tous les autres graphiques sous la forme d un triangle gris en arrière-plan, afin de faciliter la comparaison de toutes les techniques d agrégation avec les limites inférieures et supérieures de la moyenne arithmétique. Les résultats obtenus avec la méthode I Squale montrent qu elle se comporte comme prévu, avec la gradation des différents poids (de faible λ = 3 à fort λ = 30). En particulier, la pondération forte donne un résultat agrégé bas, même pour une petite quantité (10 %) de mauvaises notes. 152

167 6.2. Evaluation expérimentale des pratiques de code Average Arithmetic mean range [2,3] range [1,2[ range [0.5,1[ range [0.1,0.5[ range [0,0.1[ Arithmetic mean Percentage of imperfect marks Average Squale (weight = 3) mark Squale (weight = 3) Percentage of imperfect marks Average mean range Average Squale (weight = 9) mark Squale (weight = 9) Average mean range Average Squale (weight = 30) mark Squale (weight = 30) Average mean range Percentage of imperfect marks Percentage of imperfect marks Average Theil aggregate Theil Average mean range Average MLD aggregate MLD Average mean range Percentage of imperfect marks Percentage of imperfect marks 0.0 Gini Kolm 3.0 Average Gini aggregate Average mean range Average Kolm aggregate Average mean range Percentage of imperfect marks Percentage of imperfect marks Average Atkinson aggregate Atkinson Average mean range Average Hoover aggregate Hoover Average mean range Percentage of imperfect marks Percentage of imperfect marks Figure 6.1 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. 153

168 Chapitre 6. Validation du modèle Squash Pour la pondération moyenne et dure, après une chute brutale (10 % des notes mauvaises), les courbes montrent une pente plus douce, ce qui suggère que I Squale est moins sensible à partir de 20 % ou plus de mauvaises notes que pour le premier 10 %. Cela peut poser problème, car la note globale ne permet pas directement de savoir s il existe seulement quelques problèmes, ou de nombreux problèmes. Il faudra se référer aux notes individuelles pour le savoir. En outre, même si elle ne rompt pas l exigence de ne pas masquer les progrès, la note finale entre 90 % et 30 % de mauvaises notes n est pas beaucoup plus élevée : l amélioration n est pas significative. Il faut donc trouver un juste équilibre entre l exigence de mise en évidence des problèmes et l exigence de ne pas masquer les progrès. Pour les indices d inégalité économiques, il faut se rappeler que ce sont des mesures d inégalité, elle donnent donc normalement des résultats faibles pour les valeurs agrégées toutes égales (e.g., le cas de base). Cette caractéristique est à l opposé de ce que nous recherchons. Par conséquent, pour faciliter la comparaison avec I Squale, nous avons inversé l axe Y de leurs résultats (sur la gauche des graphiques, l axe Y de droite se rapporte au triangle gris se référant aux moyennes arithmétiques). I Theil a été décrit comme étant appropriée aux gens riches donc aux valeurs supérieures [Cowell, 2000]. I Theil est plus sensible pour, par exemple les mesures faites pour 90 % à 80 % de mesures parfaites que dans les cas de 30 % à 20 % de notes parfaites. Cependant, nos expériences suggèrent que I Theil est la technique d agrégation qui met en avant les résultats les moins mauvais (pauvres), y compris par rapport à la moyenne arithmétique. En revanche, I Kolm est l indice d inégalité qui convient le mieux par rapport à l exigence de mettre en avant les mauvais résultats, tant que ceux-ci ne sont pas trop nombreux (jusqu à 30% ou 40%). On peut observer que lorsque la proportion de mauvais résultats augmente, il y a moins d inégalités et donc I Kolm diminue (la courbe monte sur notre axe inversé). Toutefois, ceci ne constitue pas une caractéristique désavantageuse, sachant qu un logiciel évalué dans un contexte industriel n a en général presque jamais de composants dépassant les 40% de notes imparfaites pour la même mesure. Cependant, le plus gênant pour I Kolm réside dans le fait que l amélioration de la qualité (par exemple de 60 % à 50 % de notes imparfaites) se traduira également par une augmentation de l inégalité (depuis une majorité de méthodes imparfaites jusqu à une minorité) et, par conséquent, une aggravation de la valeur totale. Certains travaux seraient nécessaires pour améliorer cet aspect, mais il ne faut pas oublier que nous considérons ici des données artificielles avec seulement un nombre limité de notes imparfaites ( [0.5, 1[), alors que sur des projets réels, ils seraient plus étalés. Il faut aussi se rappeler que l agrégation est effectuée ici sur les résultats normalisés de SLOC dans [0, 3], ce qui défavorise les résultats apportés par les inégalités limitant les valeurs possibles pour les indices d inégalité Limites de l expérience 154 Nous avons identifié les limites suivantes à l expérience menée : l expérience a été menée sur un seul système logiciel avec une seule mesure. Toutefois, étant donné que l agrégation porte uniquement sur les résultats des combinaisons des métriques (les notes individuelles normalisées) donc sur des valeurs numériques normalisées, ce fait n a que peu d influence et peut être ignoré. Notre expérimentation valide la méthode d agrégation, et non les équations de combinaison ;

169 6.3. Validation des propriétés de Squash les données sont artificielles et ne représentent pas un cas réel dans lequel on trouverait des quantités différentes pour une plus grande variété de qualité. Cependant, cette configuration était nécessaire pour analyser finement la réponse de chaque technique d agrégation à une quantité variable de problèmes. Ce problème est inhérent à des expériences contrôlées ; nous avons utilisé une seule métrique (SLOC ), et ses résultats ont été normalisés à l intervalle [0, 3]. Ces deux restrictions ont été nécessaires pour être en mesure de comparer dans les mêmes conditions d utilisation la formule I Squale et les différents indices d inégalité économiques. Avec des valeurs réelles, ayant une plus grande portée, les indices d inégalité économiques aurait pu faire mieux, car ils auraient réagi plus fortement à de plus grandes différences. Cependant, nous avons déjà fait valoir que, dans un contexte d évaluation réelle, il est normalement plus judicieux de combiner les métriques avant de les agréger et la combinaison se traduit souvent par une certaine normalisation des valeurs des métriques pour harmoniser les intervalles de valeur. Ce n est donc pas un cadre irréaliste Conclusion Notre expérience montre donc que la formule I Squale met en valeur les problèmes même lorsqu ils sont peu nombreux mais est peut-être parfois trop sévère pour répondre correctement à l exigence de ne pas masquer les progrès. De plus, cette formule, bien que précisant que les résultats ne sont pas ceux attendus, ne donne aucune indication quant au nombre de mauvaise notes donc au nombre de composants défectueux. Il faudra se référer aux notes individuelles pour y parvenir. Cependant, la formule I Squale répond à presque toutes les exigences, sauf celle de décomposition. Les indices d inégalité pour leur part répondent également à la plupart des exigences. I Kolm donnes les résultats les plus satisfaisants lors de l expérience, même si nous avons identifié des problèmes inhérents au fait qu elle soit une formule d inégalité économique (lorsque tous les résultats sont soit bons soit mauvais, la formule ne peut faire la différence). Cependant, dans les faits, cela ne représente pas réellement un obstacle à l utilisation de cette méthode pour l agrégation de métriques puisqu il est rare, voir même impossible de rencontrer de tels cas de figure. De plus, au vu de l importante littérature existant à propos de ces indices, il peut être intéressant de continuer à les étudier pour les adapter totalement aux besoins de l évaluation de la qualité. 6.3 Validation des propriétés de Squash Reprenant les propriétés définies dans la section en page 88, nous expliquons en quoi notre modèle valide ou non ces propriétés : 1. Un modèle doit être exhaustif. Squash s attache à couvrir tous les aspects de conception d un logiciel. Ainsi, il évalue la qualité d un point de vue technique avec les pratiques de code et les pratiques de normes et standard, mais également d un point de vue fonctionnel avec les pratiques de tests. En revanche, Squash n évalue que partiellement la qualité d un point de vue production. Le modèle doit encore être amélioré pour prendre en compte tous les aspects de mise en production d un logiciel ; 2. Il possède une partie fonctionnelle. Squash évalue l expression des besoins des clients à travers le facteur Adéquation fonctionnelle qui a été entièrement redéfini tant au niveau des 155

170 Chapitre 6. Validation du modèle Squash critères qui le composent qu au niveau des pratiques. Il qualifie à la fois l expression des besoins à travers le critère exigences, la validation du logiciel à travers le sous-facteur tests fonctionnels et les processus de qualification logiciel mis en place à travers le sous-facteur conduite de projet ; 3. Il possède une partie technique. Les pratiques de code et les pratiques de normes et standard évaluent l aspect technique du logiciel ; 4. Il possède des règles d évaluation précises. Squash définit les pratiques de manière précise, donnant à la fois la mesure qui doit être utilisée mais également comment les utiliser dans des règles de calculs établies. En revanche, les métriques utilisées dépendent encore fortement des outils qui les calculent, ce qui a pour conséquence de parfois fausser les résultats. L instance actuellement implémentée du modèle Squash (voir Section 6.4) repose sur l outil de calcul Sonar et certaines métriques de cet outil font parfois défaut tandis que d autres ne calculent pas de manière satisfaisante les mesures. Il faudra par la suite développer des métriques propres à Squash. Par ailleurs, concernant les pratiques de tests, notre outil se fonde sur les résultats de l outil Squash, développé au sein du même projet, en accord avec les besoins de Squash, ce qui rend ces pratiques beaucoup plus précises ; 5. Il est adaptable. Les pratiques peuvent être personnalisées pour prendre en compte les particularités de l entreprise et du logiciel. De plus, Squash prévoit de pouvoir supprimer ou ajouter autant de pratiques que nécessaire ; 6. Il reflète objectivement un niveau de qualité. Les pratiques du modèle ont été conçues de manière à être paramétrables mais propose néanmoins une valeur par défaut traduisant des exigences généralement admises. Notre modèle reflète donc la qualité de manière personnalisée mais également objective, si tant est que l utilisateur ne pervertisse pas l outil en le paramétrant à outrance ; 7. Il n est pas un but en soit mais une aide. La définition même des pratiques implique que le résultat pointe les lacunes de manière explicite. En cela, notre modèle est une aide. En revanche, il n échappe pas forcément au phénomène qui incite les utilisateurs du modèle à viser absolument une note, à évaluer leur travail sous l angle des résultats obtenus dans le modèle. Pour prévenir ce dysfonctionnement, la prévention reste le meilleur outil : avertir avec insistance que les notes ne sont pas un but en elle-mêmes ; 8. Il reflète finement les efforts de qualité. Le système de notation des pratiques a été établi dans ce but : elles sont évaluées par un système de notation en continu et non de manière discrète, dans le but de traduire chaque variation, en positif comme en négatif ; 9. Il doit diriger les efforts. Les pratiques de Squash mettent en valeur les points faibles du logiciel, soit par l intermédiaire des notes individuelles des composants, soit par l intermédiaire des listes de caractéristiques détaillées des pratiques documentaires. Ceci permet donc de pointer effectivement les points faibles tant au niveau technique qu au niveau fonctionnel ; 10. Il possède différents niveaux de lecture. Le modèle hiérarchique retenu pour Squash permet d avoir tout à la fois une vue détaillée de la qualité à travers les pratiques mais également une vue générale à travers les critères et les facteurs ; 11. Il possède des résultats facilement interprétables. Les résultats fournis utilisent toujours la même échelle de valeur ([0; 3]) qui est très facilement interprétable à tous les niveaux. Squash a été conçu pour remplir ces objectifs. Il y répond pour la plupart, à l exception cependant du domaine de la mise en production du logiciel qui n est pas encore couvert de manière satisfaisante. 156

171 6.4 L implémentation du modèle Squash 6.4. L implémentation du modèle Squash Squash est actuellement développé par l équipe de l Inria Nancy comme plugin Sonar. Les figures 6.2 et 6.3 donnent deux exemples de tableaux de bord. Les icônes météorologiques symbolisent la qualité de la note obtenue (un soleil pour une bonne note par exemple). La première figure présente une vue globale du modèle de qualité, avec le détail du facteur maintenabilité et la seconde présente la vue s adressant aux développeurs. En effet, pour permettre une meilleure adéquation entre les utilisateurs et le modèle Squash, nous avons découpé ce dernier en vues différentes selon les acteurs utilisant le modèle. Figure 6.2 Une vue globale de Squash Les différentes vues du modèle Squash Le modèle Squash a été découpé de façon à donner une vue personnalisée en fonction des acteurs identifiés dans la construction d une application. Nous avons choisi de classer les acteurs tels que représentés dans la figure 6.4. Ce découpage correspond essentiellement à un regroupement des acteurs en fonction des principaux processus de création d une application : la phase de modélisation de l application (par exemple la rédaction d un modèle UML) ; la phase de développement de l application ; 157

172 Chapitre 6. Validation du modèle Squash Figure 6.3 Un exemple de vue de Squash s adressant aux développeurs 158

173 6.4. L implémentation du modèle Squash Chef de projet Infrastructure Projet Développement Validation Production Responsable développement Responsable validation Chef de production Développeurs Analyste de tests Métiers de la production Architecte Testeur Automaticien Figure 6.4 Les différents acteurs identifiés la phase de tests de validation de l application ; la phase de mise en production de l application. Cette répartition, ainsi que les acteurs identifiés peuvent être discutés et également varier d une entreprise à une autre ou d un logiciel à un autre. C est pourquoi, tout comme le modèle Squash lui-même est totalement personnalisable, nous laissons également la possibilité aux entreprises de faire évoluer ces vues en fonction de leurs besoins et de leur organisation propre. 159

174 Chapitre 6. Validation du modèle Squash taille de méthodes nombre de méthodes normes et standard : documentation Couverture tests unitaires code Spaghetti copier coller taux de commentaires Profondeur d'héritage couplage afferent couplage efferent cohésion de classe couteau suisse couplage classe efferent normes et standard : programmation normes et standard : nommage normes et standard : gestion de configuration normes et standard : mise en forme Normes et standard : traçage normes et standard : portabilité Couverture des tests d'intégration Cycle de vie des tests développement Taux de réussite des tests unitaires Taux de réussite des tests d'integration Exigences des tests unitaires Stratégie des tests d'intégration Pratiques normes et standard Pratiques de code Pratiques documentaires Pratiques tests qualité de la documentation Normes et standard : traçage Gestion des exceptions normes et standard : supervision de l'application Figure 6.5 La vue développement Stabilité Gestion des exceptions Normes et standard : traçage Gestion des anomalies Gestion des anomalies après tests Maturité des tests Gestions des versions Exploitabilité dossier de production Exigences système Données système Couverture des données système Couverture de tests d'intégration système Tests d'intégration système Tests de configuration/ installation Couverture des tests configuration Tests applicatif Exigences applicatif Données applicatif Couverture des données applicatif Tests de performance Couverture de tests performance Tests de montée en charge Couverture des tests de montée en charge Tests de robustesse Normes de performances Normes et standard : traçage normes et standard : portabilité Normes de sécurité Respect des règles de l'entreprise : dossier de conception technique Respect partie sécurité du cahier des charges conformité implémentation/ définition sécurité Normes et standard : sécurité Tests sécurité Exigences sécurité Données sécurité Couverture des données sécurité Tests d'intrusion Couverture de tests d'intrusion Couverture des tests de robustesse Facteurs Critères Pratiques normes et standard Capacité de réutilisation Fiabilité Performances Sécurité Pratiques manuelles Pratiques tests Figure 6.8 La vue production 160

175 6.4. L implémentation du modèle Squash Modélisation diagramme de modélisation conformité entre modélisation et implémentation prédétection d'antipatterns Raisonnement par les modèles Modularité de l'architecture dépendance cyclique découpage en couches niveau d'abstraction et de stabilité Pertinence de l'architecture choix des technologies design-pattern organisation générale du code dossier d'architecture technique Profondeur d'héritage Respect de l'architecture respect de l'architecture en couches correspondance entre couches et nommage Organisation ALM(application life cycle management) Plan d'assurance qualité Cahier des charges Stratégie de validation et d'homologation du logiciel Sous-Facteurs Architecture Critères Pratiques normes et standard Pratiques métriques Pratiques modèles Pratiques manuelles Figure 6.6 La vue modèle Capacité de réutilisation Fiabilité Performances Adéquation fonctionnelle Sécurité tests fonctionnels conduite de projet Stabilité Gestion des exceptions Normes et standard : traçage Gestion des anomalies Gestion des anomalies après tests Maturité des tests Gestions des versions Exploitabilité dossier de production Exigences système Données système Couverture des données système Couverture de tests d'intégration système Tests d'intégration système Tests de configuration/ installation Couverture des tests configuration Tests applicatif Exigences applicatif Données applicatif Couverture des données applicatif Tests de performance Couverture de tests performance Tests de montée en charge Couverture des tests de montée en charge Tests de robustesse Couverture des tests de robustesse Tests fonctionnels Exigences fonctionnelles Rédaction des cas de tests fonctionnels Couverture des cas de tests fonctionnels Données de tests fonctionnels Données aux limites Taux de réussite des tests fonctionnels Taux de couverture des tests fonctionnels Couverture des données fonctionnelles Cycle de vie des tests fonctionnels Automatisation des tests Données de tests automatisés Couverture des données tests automatisés Testabilité de l'application Cycle de vie des tests auto Maturité des test auto Tests automatisés Formalisation de la stratégie de tests Définition de la campagne de tests conformité entre la stratégie et les tests Validation de la campagne de tests Facteurs Sous-Facteurs Critères Données de tests Couverture des données de tests Définition des besoins des données Qualité de l'échantillonnage Données anonymisées Pratiques normes et standard Exigences Extraction des exigences criticité des exigences catégorisation des exigences cycle de vie des exigences Organisation ALM(application life cycle management) Plan d'assurance qualité Validation du cahier des charges Stratégie de validation et d'homologation du logiciel Tests sécurité Exigences sécurité Données sécurité Couverture des données sécurité Tests d'intrusion Couverture de tests d'intrusion tests d'acceptation Taux de couverture tests d'acceptation Stratégie des tests de non régression Taux de couverture des tests de non régression Pratiques manuelles Pratiques tests Figure 6.7 La vue tests 161

176 Chapitre 6. Validation du modèle Squash Par défaut, le modèle propose les découpages suivants, en fonction des quatre grands pôles identifiés ci-dessus : la figure 6.5 représente la vue développement. Elle regroupe les pratiques de code qui analysent le code statiquement. Un développeur n a pas forcément besoin d avoir une vue des critères et facteurs du modèle mais il lui est plus utile d avoir directement une vue des pratiques qu il doit respecter. Améliorer la qualité signifie dans ce cas modifier le code source de l application. La figure 6.3 montre le tableau de bord qui correspond à cette vue ; la figure 6.6 représente la vue modèle. On y retrouve les pratiques de modèle qui évaluent la qualité de modèle de type UML par exemple. Améliorer la qualité dans ce domaine, signifie essentiellement améliorer la qualité du modèle et de l architecture de l application ; la figure 6.7 représente la vue tests. Elle regroupe toutes les analyses autour des tests : les tests eux-mêmes mais également la stratégie de tests. Améliorer la qualité passe par la distinction de ces deux différents axes : d une part la stratégie, l organisation générale des tests et d autre part les tests eux-mêmes. Nous distinguerons donc l amélioration de la stratégie de tests de celle des tests eux-mêmes, la première signifiant appliquer les recommandations des experts et la seconde signifiant augmenter la qualité des tests eux-mêmes ; la figure 6.8 représente la vue production. Elle regroupe les pratiques autour de la production. Améliorer la qualité signifie alors mettre l application en adéquation avec son environnement. Les vues représentent la répartition des pratiques du modèle point central de celui-ci en fonction des acteurs. Chaque acteur au sein de chaque pôle peut ainsi prendre connaissance de l évaluation de la qualité de son travail mais également avoir accès à l évaluation qualitative globale de son secteur. Le développeur, par exemple, aura connaissance de la qualité des lignes de code sur lesquelles il travaille mais également de la qualité de tout le code de l application. Détailler les vues de manière plus fine reviendrait à nier le travail d équipe qui doit s harmoniser autour du logiciel pour obtenir une amélioration de la qualité. 6.5 Conclusion Dans ce chapitre nous avons montré en quoi le modèle Squash répond aux exigences que nous avons définies préalablement dans le chapitre 3. D une part, nous avons montré que les formules utilisées pour calculer les notes des pratiques de code répondent effectivement aux attentes d évaluation de la qualité. Nous avons également montré que les indices d inégalité économiques sont une piste intéressante. En effet, nous pensons par exemple au fait d utiliser ces formules conjointement avec la formule I Squale pour, par exemple, permettre de corréler la qualité avec les parties d un système évalué (comme nous le montre les recherches de Serebrenik et Vasilescu [Serebrenik et van den Brand, 2010b]), ce que ne permet pas I Squale (elle n est pas décomposable). D autre part, nous avons montré que le mode de calcul mis en place dans Squash pour les pratiques documentaires (non issues de métriques) satisfont en partie les exigences d évaluation de la qualité. Notamment, le fait de pouvoir évaluer la qualité de manière continue et pondérée semble être une amélioration importante par rapport au modèle Squale. Nous rappelons également que Squash a fait l objet de deux projets de recherches. Il est à la fois issu de recherches et appliqué en industrie, ce qui en fait un modèle à la fois théorique mais 162

177 6.5. Conclusion également appliqué de manière concrète. Squale a été développé durant deux ans au sein du projet de recherche Squale. Ceci a permis de valider, avec Air France-KLM et PSA Peugeot-Citroën, les pratiques de code et les pratiques de normes et standard que nous avons reprises dans Squash. De plus, les formules utilisées dans le modèle Squash ont fait l objet d un article [Mordal-Manet et al., 2011] et d un article de journal [Mordal et al., 2012]. L architecture générale du modèle repose sur une architecture similaire de type hiérarchique. Ce type de modèle permet à la fois une vue globale et une vue détaillée de la qualité. De plus, l organisation générale du modèle a été validée de manière empirique par Air France-KLM et PSA Peugeot- Citroën, satisfaits du l outil qu ils utilisent tant au niveau des développeurs qu au niveau des managers. Cependant, le modèle Squash doit encore faire l objet d une validation plus aboutie et doit également être comparé aux autres modèles de qualité existant. Actuellement, une instance est en cours de validation chez Generali, notamment pour valider les pratiques du domaine fonctionnel et les techniques de notation des pratiques de type documentaires (à base de logique floue). 163

178 Chapitre 6. Validation du modèle Squash 164

179 Chapitre 7 Vers un plan de remédiation du code Sommaire 7.1 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 Appliquer des modèles de qualité à des logiciels ne constitue qu une première étape. En effet, les entreprises qui mesurent la qualité de leurs logiciels ont majoritairement pour but soit d augmenter celle-ci, soit d en éviter la détérioration au fil du temps. L élaboration d un plan de remédiation constitue donc l étape suivante dans le modèle Squash : construire un outil d aide à la décision à partir d une vue qualitative. Les modifications, que ce soient des corrections de bogues ou des améliorations de fonctionnalités peuvent entrainer une détérioration de la qualité au fil du temps. En revanche, ces opérations de maintenance peuvent être également l occasion d augmenter la qualité du logiciel. Pour ce faire, les chefs de projet vont devoir prendre des décisions et orienter les développements judicieusement. Le plan de remédiation a pour but d aider à cette prise de décision. Il ne s agit pas de se substituer aux décisions humaines mais d aider dans les choix à prendre. Un plan de remédiation doit donc être vu comme une aide dans les développements futurs et non comme une injonction de modification. Il doit être mis en concurrence avec les besoins de développement sur le projet et doit tenir compte également de l état de fonctionnement de l application. En effet, il arrive régulièrement que certains composants obtiennent une note qualitative médiocre alors qu ils fonctionnent pourtant correctement. Dans ce cas, il semble inutile de se consacrer à des tâches d amélioration de ces composants si ceux-ci ne sont pas amenés à évoluer. Le modèle Squash qualifie la qualité dans plusieurs domaines : le développement, les tests, les modèles, etc. Il s adresse à différents acteurs. Il nous a donc semblé donc essentiel que le plan de remédiation du modèle soit construit de la même façon. En effet, l amélioration de la qualité se 165

180 Chapitre 7. Vers un plan de remédiation du code répartie en fonction des rôles de chacun : un développeur travaille à améliorer la qualité du code tandis qu un technicien du test travaille à améliorer celle des tests. Le plan doit donc être personnalisé en fonction des rôles de chacun et tenir compte de la répartition des tâches pour augmenter sa lisibilité et son utilité directe. Les pratiques du modèle Squash constituent sa particularité, le point central du modèle qui décrit des règles qualitatives. C est pourquoi le plan de remédiation proposé pour le modèle repose sur les pratiques. A partir des réunions de travail du projet Squale, nous avons donc élaboré avec l équipe RMod de l Inria, un premier plan de remédiation à partir des pratiques de code du modèle : un plan de remédiation du code destiné aux développeurs. Différents types de modèles connus. Identifier les modifications et calculer leur coût par composant reste un défi. Plusieurs travaux ont déjà tenté de couvrir l un des deux aspects de cette problématique. Nous citerons les plus connus et les plus intéressants : les modèles d estimation des coûts comme Cocomo (bien qu ils s attachent uniquement à l estimation de coûts et non pas à l identification des modifications). De plus, ces modèles ne prennent pas en compte les éventuelles conséquences des modifications d un composant [Kemerer, 1987] ; les modèles de refactorisation et les actions de maintenance [Mens et Tourwé, 2004, Buckley et al., 2005] qui s attachent à déterminer les modifications à apporter à un logiciel mais qui ne prennent pas en compte les coûts de maintenance comme critère de décision ; les modèles de prédiction des efforts de maintenance [Munson et Elbaum, 1998], [Bengtsson et Bosch, 1999], [J.E. et J.P., 1997] ; les modèles d impact de changements [Bohner et Arnold, 1996]. Les plans de remédiation présentent de multiples caractéristiques qui régissent leur portée et leur application au sein d une entreprise : il faut savoir prendre en compte à la fois le code impacté mais également les équipes qui devront travailler dessus ou encore prendre en compte l opportunité de certaines modifications. La démarche visant à augmenter la qualité n échappe pas à ces principes et doit toujours les prendre en compte pour les utiliser à bon escient. Il est important de connaître les caractéristiques des tâches abordées par le plan (Section 7.1) ainsi que son aspect organisationnel par rapport aux équipes de développement et durant le processus de développement du projet (Section 7.2). 7.1 Les tâches abordées par Squash Le but du plan de remédiation du modèle Squash est de définir une stratégie globale d augmentation de la qualité à partir de calculs de coûts unitaires effectués sur les composants du projet. L effort de remédiation unitaire est défini comme étant la quantité de travail à fournir pour obtenir une meilleure qualité de l entité analysée. Le terme effort de remédiation est quant à lui, employé dans le contexte du modèle de qualité : il s agit de mesurer la quantité de travail à fournir pour obtenir une augmentation de la qualité par rapport à la mesure fournie par le modèle de qualité. Le plan se base autant sur les composants défectueux que sur les violations des pratiques du modèle. Le but du plan est de fournir un guide pour améliorer la qualité au plus faible coût possible. 166

181 7.1. Les tâches abordées par Squash Les tâches abordées par le plan de remédiation de Squash sont caractérisées comme suit : la transgression : une instance qui n a pas atteint l objectif visé par la pratique i.e., que ce soit un composant ou une règle de transgression. Décrite dans la partie ; la tâche de remédiation : la description des actions à mener pour résoudre la transgression d une pratique. Décrite dans la partie ; le coût de remédiation : le coût est caractérisé par le travail à accomplir pour appliquer une tâche de remédiation. Décrite dans la partie La transgression : de l utilisation des pratiques Le plan de remédiation de Squash utilise les caractéristiques du modèle de qualité sur lequel il s appuie. Il repose donc essentiellement sur les pratiques du modèle et sur leur notes individuelles ou globales. Les pratiques sélectionnées sont celles qui s adressent aux développeurs telles que représentées dans la figure 6.5. Ces pratiques sont de différents types : code, normes et standards, tests et documentaires : les pratiques de code sont automatiques et peuvent être calculées facilement aussi souvent que souhaité. De plus, elles décrivent des principes de développement reconnus que nous pouvons analyser et utiliser pour améliorer la qualité du code ; les pratiques de normes et standard sont également automatiques et pour les mêmes raisons, seront prise en compte également dans le plan de remédiation ; les pratiques de tests automatiques telles que les couvertures de tests sont également automatiques et seront prises en compte ; les pratiques documentaires feront l objet d un traitement séparé. En effet, ces pratiques reposent sur l analyse d un expert et ont vocation à évaluer la qualité à un niveau plus général. Il est plus utile de prendre en compte les notes de ces pratiques pour améliorer la qualité des développements d applications futures que dans le plan de remédiation lui-même. Une transgression est donc définie comme étant un objectif non atteint défini par une pratique donnée. Ainsi, une transgression se détermine en fonction d une pratique et des composants ciblés par celle-ci. Par exemple, si on prend la pratique nombre de méthodes, celle-ci définit un nombre de méthodes par classe à respecter. Une classe qui transgresse cette pratique possède un nombre de méthodes inadéquat et donc une mauvaise note individuelle. Une transgression est donc directement liée aux notes individuelles des pratiques. Dans le cas des pratiques de normes et standard, celles-ci étant définies pour le projet en entier, une transgression correspond alors à une règle non respectée pour l ensemble du projet La tâche de remédiation : la portée d une action Une tâche de remédiation est une unité conceptuelle décrivant les actions à mener pour résoudre une transgression. Dans le contexte du modèle Squash, deux questions sous-tendent l évaluation des efforts de remédiation : 1. Dans quel contexte et caractéristiques du système l effort de remédiation se situe-t-il? 167

182 Chapitre 7. Vers un plan de remédiation du code 2. Quel objectif doit atteindre l action de remédiation? Le contexte évalue le composant visé par la pratique aussi bien que les composants reliés qui seront sans doute également impactés par cette action. Deux paramètres définissent le contexte : la complexité i.e., est-il facile de modifier le composant selon l action voulue (par exemple, une méthode complexe est plus difficile de diviser qu une méthode simple) ; l impact i.e., combien de composants vont être touchés par cette action (par exemple, changer une méthode peut entrainer la mise à jour des appels à cette méthode). L objectif représente le niveau de qualité recherché. Dans le contexte du modèle Squash, la qualité est notée dans l intervalle [0 ;3] pour permettre une interprétation précise du niveau de qualité. Nous avons donc défini l objectif comme étant le score à atteindre pour la pratique : une note au dessus de 2 est satisfaisante ; une note comprise entre 1 et 2 doit être améliorée si possible ; une note inférieure à 1 doit être une priorité pour le modèle de remédiation. Finalement, la remédiation est un compromis entre les buts à atteindre (en terme de notes) et le contexte qui permet de déterminer les ressources à mettre en œuvre pour fournir l effort souhaité. L évaluation des actions à mener Nous identifions trois principes fondamentaux pour évaluer le travail nécessaire à une tâche de remédiation : la portée de la pratique et de la remédiation : évalue la cible de la remédiation au sein du projet. La Table 7.1 décrit les différentes portées de la remédiation en fonction des pratiques visées ; le degré d automatisation du travail de remédiation : certaines tâches de remédiation peuvent être automatisées en effectuant quelques corrections préalables. C est le cas par exemple des pratiques visant la conformité avec certains standards de programmation. Dans ces cas, il est plus judicieux de cibler les transgressions plutôt que les composants. En effet, la transgression ne sera corrigée qu une fois tous les composants mis en conformité et homogènes ; l expertise nécessaire à la rémédiation : Tandis que certaines règles décrites par les pratiques sont faciles à suivre, d autres nécessitent un niveau d expertise plus élevé. Par exemple, les tâches liées à l architecture et au design, ou à la sécurité ont besoin d un expert dans leur domaine respectif. A cela s ajoute quatre caractéristiques supplémentaires qui dépendent du contexte (du type de projet et des exigences et standards appliqués par l entreprise) : les propriétés et l organisation du code : un plan de remédiation nécessite de prendre en compte l organisation du code aussi bien que ses propriétés. Certains composants peuvent se situer en dehors du champ d action du plan. Il est parfois indispensable de bien connaître les composants et leur historique de développement pour déterminer si certaines transgressions sont nécessaires et doivent être conservées ; la criticité d une pratique : toutes les pratiques ne sont pas de même importance tout au long du cycle de vie d une application. Par exemple, les pratiques de test deviennent primordiales lorsque l application est en phase de tests. De plus, en fonction de certaines contraintes, un chef de projet peut décider que certaines pratiques deviennent prioritaires par rapport à d autres, ce qui entraîne alors une modification des priorités dans le plan de remédiation ; 168

183 Table 7.1 Portée des pratiques et de la remédiation 7.1. Les tâches abordées par Squash Pratique Portée Portée de la remédiation Documentaire Projet Selection des composants prioritaires identifiés lors de l audit Code Composant le composant et ses dépendances Test (package, classe, méthode... ) Normes et standard Règles Composant responsable de la transgression transgression la criticité du composant : une connaissance en interne du projet peut conduire à décider de rendre prioritaires certains composants lorsqu ils sont les éléments centraux correspondant au stade courant de développement du projet. D un autre côté, certains autres composants peuvent être déclarés hors du champ d action s ils fonctionnent malgré leur défauts et qu il n est pas prévu de les modifier ; les caractéristiques du composant : selon la pratique, les caractéristiques telles que la taille, la complexité, le couplage peuvent avoir un impact important sur les corrections à effectuer. Certaines pratiques prennent explicitement ces corrélations en considération : par exemple, le fait qu il faille fournir plus de tests pour les méthodes plus complexes Coût de remédiation : de la mesure de l effort Une fois les transgressions identifiées, les tâches de remédiation définies, il reste à mesurer le coût de cette remédiation. Pour y parvenir, il faut tout d abord définir la mesure de l effort : à partir de quoi mesurer l effort à fournir Mesure de l effort. La formule qui permet de calculer l effort de remédiation doit prendre en compte les propriétés des pratiques. Les pratiques reposant sur des mesures, il est indispensable de les prendre en compte dans le calcul de l effort de remédiation. Ceci permet de relier directement les efforts de remédiation aux notes de la qualité : propriété importante qui permet de mesurer le niveau de travail à fournir pour parvenir au but souhaité. Prenons la pratique taux de commentaires. Les transgressions pour cette pratique correspondent aux méthodes qui ne sont pas assez commentées. Calculer l effort de remédiation pour ces méthodes consiste alors à calculer le coût que représente l ajout de commentaires dans le code. La métrique CLOC est donc directement reliée à la mesure de l effort de remédiation. Toutefois, les formules de pratiques ne prennent pas nécessairement en compte la complexité d une situation, elles servent avant tout à détecter les problèmes. Prenons par exemple la pratique nombre de méthodes dont la note est calculée à partir des métriques NOM et v(g). Si la formule de calcul de la pratique est effectivement judicieuse pour détecter les classes qui transgressent cette pratique, en revanche, les métriques utilisées ne peuvent à elles seules évaluer l effort de remédiation. En effet, 169

184 Chapitre 7. Vers un plan de remédiation du code la remédiation consiste à fractionner la classe de manière à ce que les méthodes soient distribuées entre plusieurs classes plus petites. Cependant, évaluer la difficulté de diviser une classe se fait plus facilement grâce à des métriques de cohésion (plus la méthode est cohésive et plus il est difficile de la fractionner) qu avec les métriques N OM ou v(g). En outre, lors de la mesure de l effort, d autres paramètres peuvent également influencer cette mesure. Reprenons l exemple de la pratique nombre de méthodes. Diviser une classe est souvent liée à des décisions de conception : séparer une classe oblige à penser au nombre de nouvelles classes à créer et à leur interaction par exemple. Ainsi, la mesure de l effort de remédiation dépend de la transgression et de l impact de la remédiation. A chaque pratique correspond une mesure qui lui est propre Coût de remédiation. Le coût est caractérisé par le travail à accomplir pour appliquer une tâche de remédiation. Le coût de remédiation (noté W ) pour une pratique et pour un composant donné repose sur la formule empirique des pratiques : l objectif est de donner une évaluation du coût, basée sur la complexité du cas et l impact les modifications. Ceci implique une estimation du nombre de corrections nécessaires et du poids des actions de refactorisation. Quatre types de paramètres sont utilisés pour calculer ce coût : complexité : évaluation des caractéristiques du composant visé qui doit être soumis à la remédiation ; impact : le nombre de composants touchés par la remédiation (qui doivent également être modifiés pour parvenir au but) ; but à atteindre : la note attendue après la remédiation ; l unité du coût de remédiation (URC) : l unité de l effort qui dépend des changements à appliquer. Notons que ces quatre paramètres ne sont pas nécessairement indépendants les uns des autres. Par exemple, évaluer la complexité du cas dépend du but à atteindre. Plus la note attendue est élevée, plus le cas est complexe à résoudre. De plus, les pratiques identifient souvent des situations complexes pour lesquelles il n existe pas un seul mais de multiples problèmes. Pour cette raison, fixer un coût de remédiation devient alors beaucoup plus difficile. Il faut alors parvenir à déterminer le niveau d expertise requis pour effectuer ces corrections. C est pourquoi les coûts exprimés ne peuvent être que des estimations qui doivent être affinées par des experts en fonction de la situation. A chaque pratique correspond une formule d estimation de coût. Le détail est donné dans le document [Balmas et al., 2011]. Nous fournissons ici un exemple pour la pratique taux de commentaires L exemple da la pratique Taux de commentaires La complexité de remédiation de cette pratique est etroitement liée à la formule de calcul de sa note. Elle dépend de la complexité cyclomatique V(G) et de la note à atteindre. Le taux de commentaires est directement lié à la complexité. Le coût de remédiation est calculé à partir de la 170

185 7.2. L aspect organisationnel du plan de remédiation différence entre le nombre de lignes de commentaires actuels et le nombre de lignes attendues par rapport à la complexité. Il n y a aucun impact par rapport aux autres composants lorsque cette pratique est corrigé. Concerne : Cependant, la complexité de la remédiation dépend de facteurs extérieurs au code source, comme la connaissance du code par le développeur. Ceci peut être pris en compte par l intermédiaire d un factuer empirique à ajouter : recallf actor, en particulier pour les projets existants déjà. complexité : complexite = goal score (1 10 v(g)/15 ) impact : expectedcommentrate = complexity 9 complexity but à atteindre : E goal = URC SLOC expectedcommentrate, l effort absolu par rapport au nombre attendu de lignes de commentaires E current = URC SLOC currentcommentrate, le score initial de la pratique l unité du coût de remédiation (URC) : URC = edit avec edit, pour le coût du changement manuel d une expression L URC peut être multiplié par un facteur empirique, recallf actor, dépendant des connaissances des développeurs par rapport au code courant W = E goal E current, le coût de remédiation pour améliorer la pratique donnée pour le composant défectueux est fonction de son état actuel (son score initial) par rapport à l objectif souhaité. Ces formules ont été définies avec les développeurs de Air France-KLM et de Qualixo. Pour cette pratique, la formule de calcul de la note individuelle intervient dans le calcul de la complexité selon leurs estimations. L unité du coût de remédiation correspond à l estimation du coût pour changer une ligne donnée, ce coût pouvant varier selon le niveau de connaissances des développeurs du code à corriger. 7.2 L aspect organisationnel du plan de remédiation Chaque entreprise a sa propre politique d application de la qualité et utilise la remédiation à différents niveaux, depuis le technicien de base jusqu au chef de projet. Un plan de remédiation doit donc s adresser à tous et prendre en compte toutes les équipes du projet. Il doit pouvoir doit être adaptable et répartir les tâches recensées entre les différentes équipes : le développeur peut orienter son travail quotidien sans ressentir comme un fardeau les processus liées à la qualité ; le chef de projet peut utiliser cet outil pour évaluer la situation et orienter les efforts à fournir. Il peut s appuyer sur le plan de remédiation pour augmenter la qualité globale du projet ; l équipe qui s occupe de la qualité doit pouvoir adapter le modèle en fonction des besoins et des standards de l entreprise. L aspect organisationnel du plan de remédiation détermine également l ordre dans lequel les tâches à effectuer seront présentées, depuis les tâches prioritaires jusqu aux tâches les moins importantes. 171

186 Chapitre 7. Vers un plan de remédiation du code Choisir une stratégie Le modèle actuellement utilisé par Squash vise à réduire les risques en ciblant les mauvaises notes des pratiques et en priorisant les remédiations qui vont augmenter ces notes au moindre coût. Le modèle est donc orienté pratique en leur donnant la priorité par rapport aux composants du projet. Stratégies de base. Indépendamment des critères de haut niveau comme le coût, la rentabilité, ou la criticité, il existe deux stratégies de base pour augmenter la qualité d une pratique : améliorer légèrement les notes de nombreux composants ; améliorer les notes des pires éléments. Les poids appliqués aux notes individuelles des pratiques (voir Section ) déterminent la stratégie qui devra être adoptée : utiliser des poids forts obligent à s intéresser aux plus mauvais composants et donc à améliorer les pires éléments, tandis que l utilisation des poids faibles entraine la stratégie inverse. La stratégie dépend également de la complexité et de l automatisation de la tâche de remédiation, comme cela est décrit dans la section Les corrections visant les pratiques de convention de nommage peuvent se faire par l intermédiaire d un script qui automatisera les corrections et qui s effectuera pour l ensemble du projet tandis que les corrections nécessitant une plus grande expertise sont d avantage susceptibles d être abordés en se concentrant uniquement sur quelques composants défectueux. Objectifs. A partir de ces constatations, les chef de projet vont alors avoir le choix entre deux stratégies pour remédier aux problèmes liés à la qualité : parvenir à une réduction importante des risques en ciblant les éléments et les pratiques critiques. Nous appelons ce choix le modèle de risque. obtenir la meilleure rentabilité dans les processus de qualité i.e., le meilleur compromis entre l augmentation de la qualité et les coûts de remédiation liés. Nous appelons ce choix le modèle de rentabilité Stratégie utilisée par Squash : Stratégie mixte du coût et des priorités 172 La stratégie mise en place dans le modèle actuel de Squash suit cinq étapes : 1. les pratiques avec les plus basses notes sont prioritaires ; 2. les composants qui échouent pour une pratique doivent être corrigés avant les autres (on améliore d abord les plus mauvais composants) ; 3. certaines pratiques sont plus faciles à corriger que d autres ; 4. la charge de travail nécessaire pour corriger une pratique est fonction de la pratique elle-même et du nombre de transgressions de la pratique ; 5. la stratégie de remédiation détermine l ordre des composants et/où transgressions dans lequel le travail à faire est proposé.

187 7.2. L aspect organisationnel du plan de remédiation Etape 1 Priorisation des pratiques en fonction de leur note Projet Pratique_3: 1 -> refusée Pratique_1: 1.6 -> acceptée avec réserve Pratique_2: 2.5 -> accpetée Etape 2 Sélection des composants en fonction des pratiques Etape 3 Coefficient de correction par pratique P1Coeff: 3.8 Workld (Pi) = Pi.Coeff * #C où C = composants de la pratique ou transgressions Etape 4 Charge de travail par pratique Etape 5 Stratégie de remédiation refusé Pratique_3 Pratique_4 C23 C3... C7 C4 C3... C7 Refusé: (Workld(Pi)< Workld(Pj) tri Accepté/réserve: (Workld(Pi)< Workld(Pj) tri Accepté: (Workld(Pi)< Workld(Pj) tri Accepté avec réserve Pratique_1 C9: 1 C12: 1.8 C16: 1.3 Practice_5 Figure 7.1 Les étapes du plan de remédiation 173

188 Chapitre 7. Vers un plan de remédiation du code Table 7.2 Pondération actuelle des efforts pour différentes pratiques Nom de la pratique Coefficient d effort Niveau d abstraction et de stabilité 200 Couplage afférent 150 Couplage efférent 100 Couteau suisse 35 Copier-coller 30 Code spaghetti 30 Prfondeur d héritage 20 Cohésion de classe 20 Taille d une méthode 20 Nombre de méthodes 20 Dépendance cyclique 10 Normes et standard : respect de l architecture en couche 40 Normes et standard : programmation 15 Normes et standard : documentation 6 Normes et standard : convention de nommage 4 Normes et standard : mise en forme 1 Documentation 10 Priorisation des pratiques en fonction de leur note. Le modèle Squash classe ses pratiques en trois catégories "refusée", "acceptée avec des reserves" et "accepté" en fonction des notes attribuées. Le plan de remédiation utilise ces notes pour déterminer l ordre de priorité des pratiques : les pratiques "refusées" obtiennent la plus grande priorité, suivies des pratiques "acceptées avec réserves". Les pratiques "acceptées" sont en dehors du cadre de la remédiation mais peuvent toutefois faire l objet d amélioration futures. Sélection des composants en fonction des pratiques. Une fois les pratiques sélectionnées en fonction de leur note, seuls les composants qui ont obtenu une mauvaise note individuelle une note inférieure ou égale à la note globale apparaissent dans le plan de remédiation. Les composants ayant obtenu une note correcte peuvent éventuellement faire l objet d amélioration mais pas de correction. Coefficient de correction par pratique. Un coefficient de correction est déterminé pour chaque pratique, en collaboration avec l entreprise. Celui-ci évalue les efforts relatifs nécessaires pour corriger une transgression pour une pratique donnée, par rapport aux autres pratiques. Il sert à traduire des faits tels que, par exemple, la transgression de normes de formatage du code est plus facile à corriger qu un problème de conception dû au couplage. Ce coefficient agit un peu comme un poids qui traduit la quantité d effort en fonction de la pratique. Ce coefficient est déterminé de manière empirique en fonction des spécificités de l entreprise. Le tableau 7.2 donne quelques valeurs actuellement utilisées dans une instance du modèle. Charge de travail par pratique. Etant donné que le coefficient de correction pour une pratique est une constante, la charge de travail pour corriger toutes les transgressions de celle-ci est définie comme 174

189 7.2. L aspect organisationnel du plan de remédiation étant le produit du coefficient par le nombre de transgressions. Pour les pratiques basées sur des métriques, le nombre de transgressions est le nombre de composants sélectionnés. Pour les pratiques basées sur des convention de nommage (normes et standard), il s agit directement du nombre de transgressions détecté par la règle. Cependant, ce calcul implique que le coefficient de correction ait été déterminé avec le plus grand soin. C est pour cette raison que ce dernier nécessite des ajustements dans les premières phases d utilisation du plan de remédiation. En effet, le coefficient possède une marge d erreur qui multipliée aux composants traités entraîne une augmentation significative de la marge d erreur globale. Stratégie de remédiation. L idée est de parcourir chaque niveau défini par Squash (depuis "refusé" à "accepté") puis pour chacun de sélectionner les pratiques en commençant par celles qui ont la plus petite charge de travail Les limitations du plan Il y a plusieurs limites à cette stratégie : 1. le coefficient est une constante indépendante du composant qui transgresse la pratique, ce qui signifie que le coût de remédiation ne prend en compte les caractéristiques du composant visé. Pour la pratique couverture de tests, l effort pour écrire des tests pour des méthodes complexes (ce qui est requis par la pratique) est lié á leur complexité et croit avec celle-ci ce qui n est pas pris en compte par une simple constante ; 2. certaines pratiques sont contradictoires, corriger une pratique peut en dégrader d autres ; 3. bien que cette stratégie trie les pratiques par notes et effort, elle ne peut déterminer de manière optimum où et quand les notes doivent-être améliorées. Pour cette raison, la charge de travail peut ne pas être optimale ; 4. bien que la tâche de remédiation soit fixée en fonction d un but à atteindre, les tâches proposées ne garantissent pas d atteindre ce but. Les corrections proposées amélioreront la note de manière incontestable mais ne parviendront pas forcément à obtenir la note maximale ; 5. les composants impliqués dans plusieurs transgressions ne sont pas détectés. Il est donc possible qu ils soient une cible de travail répétée Conclusion Le modèle Squash se propose de donner des pistes pour augmenter le niveau de la qualité grâce à son plan de remédiation, découpé selon les différents acteurs qui conçoivent le logiciel, et utilisant les pratiques comme point de référence. Bien que nécessitant encore des améliorations notamment en ce qui concerne ses formules d agrégation de coût de l effort, le plan de remédiation proposé dans Squash permet de dégager des pistes d amélioration de la qualité en mettant en avant les plus mauvais composants des plus mauvaises pratiques. Il s agit de fournir une aide à la décision quant aux choix à effectuer pour combiner maintenance applicative et augmentation de la qualité : mettre en corrélation les composants qui devraient être améliorés d un point de vue qualitatif avec ceux qui doivent être modifiés dans le cadre d une opération de maintenance. 175

190 Chapitre 7. Vers un plan de remédiation du code De plus, bien que le plan de remédiation serve d outil pour cibler les tâches à effectuer, celuici reste une indication théorique et demeure encore trop imprécis pour se substituer totalement à l avis d un expert. De plus, le plan doit également être amélioré pour définir comment fournir une estimation beaucoup plus précise de la charge de travail. De même, les conditions et le contexte de travail au sein d une entreprise sont pris en compte dans une certaine mesure, lors de la mise en place des pratiques. Il serait pourtant judicieux de les prendre en compte plus finement lors du paramétrage du plan de remédiation. Il faudrait par exemple inclure dans les calculs à quel moment intervenir dans le cycle de vie du logiciel, ou encore prendre en compte le fait que les équipes de développement travaillent par exemple à la correction d un bogue sur une partie du logiciel, ou encore à l implémentation d une nouvelle propriété. Il s agit de mutualiser les efforts : inclure la remédiation dans les développements en cours pour diminuer les coûts. 176

191 Conclusion générale Nos travaux de recherche ont pour but d évaluer la qualité d un logiciel. Nous avons cherché comment concevoir un modèle de qualité adapté aux exigences de nos partenaires industriels mais qui pourrait également être utilisable de manière beaucoup plus étendue. Il nous a donc fallu à la fois prendre en compte ce que signifie la qualité en matière de conception de système d information mais également envisager comment la notion de qualité pouvait être étendue à d autres types de logiciels (par exemple les logiciels embarqués ou encore les logiciels temps réels). Nous devions donc réaliser un modèle qui soit à la fois adapté à un type particulier de logiciel mais également adaptable à d autres. Nos travaux de recherche se sont déroulés dans le cadre de deux projets de recherche portant sur la qualité logicielle. Le premier projet Squale avait pour but de valider et de formaliser un modèle de qualité conçu de manière empirique par les entreprises Qualixo et Air France-KLM. Dans le second projet Squash nous avions pour tâche de formaliser la qualification logicielle et de l intégrer au modèle existant. Pour parvenir à notre but, nous avons tout d abord mis en place une démarche formelle de conception de notre modèle de qualité, reprenant les étapes définies par la norme SQuaRE. Ces étapes (définir une architecture générale du modèle, définir le périmètre d évaluation de celui-ci, définir les règles à évaluer, définir les métriques et les données nous permettant de les évaluer, définir comment évaluer les règles) nous ont permis de construire le modèle de qualité que nous avons présenté : le modèle Squash. 1 Le travail effectué La première question à laquelle nous nous sommes efforcés de répondre était la définition même de la notion de qualité en matière de conception logicielle. A partir des différentes définitions apportées par les normes et modèles existants, nous avons posé la définition suivante pour commencer à envisager la formalisation de notre modèle de qualité : la qualité d un logiciel est le degré auquel un logiciel remplit les besoins et exigences des clients sans défaut d exécution. Ceci nous a fait dégager deux axes principaux dans l évaluation de la qualité : le pourquoi ou point de vue fonctionnel et le comment ou point de vue technique. Nous avons ensuite cherché à valider l architecture du modèle Squale sur lequel reposait nos premiers travaux. Squale a été conçu en s inspirant du modèle hiérarchique de McCall et de la norme ISO Ces deux modèles sont construits à partir de trois couches hiérarchiques, chacune agrégeant les couches inférieures. Ils donnent une vue de la qualité partant du niveau le plus général 177

192 Conclusion générale les facteurs pour arriver au niveau technique des métriques utilisées pour évaluer les niveaux supérieurs. L architecture de Squale est composée de quatre couches hiérarchiques. Elle a été définie par Qualixo et Air France-KLM et nous a permis de séparer distinctement deux niveaux : le niveau conceptuel de la qualité et le niveau technique. Cette séparation autorise notre modèle à être tout à la fois général et applicable à tout type de logiciel mais également adaptable de façon à prendre en compte les concepts propres à chaque type de logiciel. En effet, le niveau conceptuel, composé des couches supérieures du modèle à savoir les facteurs et les critères s emploie à déterminer précisément les domaines qui seront évalués par le modèle de qualité (les facteurs) et à qualifier ces domaines selon des concepts généraux de conception d un logiciel (les critères). D autre part, le niveau technique, composé des couches inférieures du modèle à savoir les pratiques et les mesures détermine pour sa part comment évaluer les concepts à partir de règles techniques (les pratiques) qui sont évaluées à partir de données (les mesures). Ce niveau est entièrement dépendant du logiciel et des exigences de l entreprise. Pour définir le périmètre d évaluation de la qualité du modèle, nous avons été guidé par les projets de recherche. En effet, le projet Squale a été mené en collaboration avec des spécialistes en matière de développement logiciel, tandis que le projet Squash avait pour partenaires des spécialistes de la qualification logicielle. Nous nous sommes donc attaché à évaluer ces deux domaines plus particulièrement : le développement et le domaine fonctionnel. Le périmètre étant déterminé, il nous a permis de poser les exigences auxquelles nous souhaitions que notre modèle de qualité réponde. Ces exigences ont été motivées par les besoins de nos partenaires industriels. A partir de ces premiers travaux nous avons comparé Squale avec les normes ISO 9126 et SQuaRE et nous avons redéfini le niveau conceptuel du modèle. Le modèle Squash est désormais composé de facteurs prenant en compte à la fois le développement logiciel mais également la validation fonctionnelle. Nous avons aussi souhaité intégrer des facteurs et critères faisant référence à des notions telles que la sécurité et la mise en production d un logiciel afin de pouvoir prendre en compte dès à présent ces domaines, même si nous ne les avons pas encore formalisés. Le niveau technique a fait l objet de plusieurs recherches. Tout d abord nous avons validé les pratiques de code du modèle Squale et les mesures qui y sont associées. Puis nous avons formalisé les pratiques fonctionnelles. Ces pratiques ont entièrement été définies à partir des connaissances et du savoir-faire des partenaires du projet Squash. Les mesures associées aux pratiques fonctionnelles ont été choisies en fonction des besoins de ces pratiques mais également en fonction du référentiel de tests construit par nos partenaires dans le cadre du projet Squash. Un autre défi à relever consiste à évaluer les règles de qualité à partir de métriques. Il faut pouvoir associer les métriques de manière à traduire les informations qu elles délivrent pour fournir une lecture aisée de la qualité. Pour y parvenir nous avons déterminé deux étapes essentielles : la combinaison de métriques et leur agrégation. Puis nous avons déterminé les exigences à satisfaire pour que cette évaluation soit satisfaisante. Après avoir constaté que les techniques utilisées le plus couramment dans les modèles existants, à savoir de simples transpositions ou de simples moyennes, ne permettent pas d y parvenir de manière totalement satisfaisante, nous avons cherché à valider les formules utilisées dans Squale et nous les avons comparées aux techniques utilisant les indices d inégalité économiques. Ces techniques fournissent en effet des résultats intéressants et font l objet de nombreuses études actuellement tels que celle menées par Serebrenik avec qui nous avons travaillé. Nous avons mis en évidence le fait que les techniques de combinaison et la formule d agrégation de 178

193 2. Perspectives Squale correspond effectivement à nos attentes et d autre part, nous avons également prouvé que les techniques utilisant les indices d inégalité économiques donnent de bons résultats. L évaluation des règles de qualité ne repose pas toujours sur des métriques. Il faut parfois utiliser des données brutes non numériques, telles que le cahier des charges par exemple. Le modèle Squale utilisait une méthode qui ne permettait pas d évaluer au plus juste la qualité de ces données. Nous nous sommes intéressé à la logique floue comme moyen d évaluation de ces données. En effet, les approches linguistiques fondées sur les sous-ensemble flous ont prouvé leur efficacité pour la modélisation de l information qualitative. Nous avons utilisé les 2-tuple linguistiques de Herrera & Martínez pour obtenir une évaluation fine des caractéristiques que nous avions définies pour ces pratiques. Puis nous avons employé les OWA comme opérateurs d agrégation, nous permettant ainsi d associer des poids aux caractéristiques pour transcrire l importance relative des unes et des autres dans l évaluation d une pratique donnée. 2 Perspectives Court terme Le projet de recherche Squash n est pas encore fini. Dans ce cadre, nous souhaitons tout d abord valider les formules des pratiques documentaires, les pratiques de tests et le modèle Squash tel que défini aujourd hui. Nous allons tout d abord valider le modèle de manière empirique avec notamment l instance mise en place chez Generali. Parallèlement à cette validation empirique, nous souhaitons établir ce que le modèle pourra apporter au sein des équipes de validation fonctionnelle pour renforcer l utilisation d un modèle de qualité comme outil d aide à l amélioration des processus de validation. Conjointement à ces travaux de validation, nous étudierons comment proposer un plan de remédiation à partir des pratiques de tests en nous inspirant du modèle de remédiation de code. Nos travaux auront pour but, d une part de déterminer comment à partir d une évaluation de la qualité nous pouvons proposer des améliorations des processus de qualification logiciel, et d autre part, de déterminer comment orienter les efforts de tests. Il s agit de valoriser à long terme le patrimoine de tests d une application et son évolution dans le temps. En effet, un logiciel est souvent amené à être modifié, que ce soit pour intégrer de nouvelles fonctionnalités ou pour corriger des bogues. Il doit donc être validé testé à chaque nouvelle version. Notre plan vise à proposer comment améliorer les tests lors de ces nouvelles phases de recette, aider à la mise en place d un patrimoine de tests valorisé, mais également aider dans la démarche d automatisation des tests. Un autre objectif pour les mois à venir consiste à améliorer le plan de remédiation de code proposé dans Squash. En effet, le plan proposé nécessite d une part une amélioration en matière d agrégation du coût de l effort, mais également en matière d estimation de la charge de travail nécessaire à la remédiation proposée. Il devra également prendre en compte le contexte et les conditions de travail au sein de l entreprise : par exemple, proposer une remédiation en corrélation avec le travail actuel de l équipe de développement, ou encore prendre en compte la maturité de l application. Il s agit de mutualiser les efforts : inclure la remédiation dans les développements en cours pour diminuer les coûts. Long terme 179

194 Conclusion générale Bien que les pratiques de code aient été validées par les entreprises Air France-KLM et PSA Peugeot-Citroën, notre étude sur les différentes métriques existantes nous oblige à constater que les notions de cohésion et de couplage de packages, par exemple, ne sont pas prise en compte de manière adéquate. En effet, Martin a décrit une certain nombre de principes assortis de métriques. Celle-ci ne sont pas assez exploitées dans les pratiques de code actuelles. A partir de ces métriques et de ces principes, nous souhaitons formaliser des pratiques qui pourraient d une part mesurer les packages mais surtout fournir des pistes d aide à l amélioration de leur architecture : évaluer le respect des principes de Martin et donner une indication en cas de défaillance pour corriger le design. Une autre motivation dans nos recherches futures, consiste à établir un modèle de prédiction de bogues à partir de l évaluation de la qualité. En particulier il s agit de porter l attention sur des points particuliers du code à surveiller, susceptibles de contenir des bogues. Pour y parvenir, nous nous proposons d établir un lien entre les bogues détectés et les parties de code source concerné. Nous utiliserons le référentiel mis en place dans le cadre du projet Squash afin de déduire de situations particulières des schémas à plus grande échelle et de corréler ces schémas avec l évaluation de la qualité. Ceci aura pour conséquence de modifier également le modèle de qualité pour amener à pointer ces schémas, les intégrer au modèle sous forme de pratiques qui permettront de mettre en avant les parties de code sensibles. Nous pourrions également être amenés à constater que, contrairement à notre idée de départ, nous ne pouvons établir de relation aussi directe entre la qualité d un logiciel et les bogues potentiels. Cette démarche s inscrit totalement dans la démarche de recherche initiée par l entreprise Qualixo au cours du projet de recherche Squash. Comme nous l avons précisé, le modèle Squash intègre de manière détaillée les domaines du développement et de la validation logiciel. En revanche, pour être vraiment complet, le modèle devrait également intégrer le savoir-faire des métiers de la production. Ceci permettrait de prendre en compte des notions telles que le déploiement logiciel, les exigences de partage de données dans les systèmes d information et les procédures de redémarrage après un échec, entre autres. Au delà de compléter notre modèle, cela permettrait de créer un lien entre les différents métiers de conception et de maintenance logicielle, de mettre en évidence que la qualité logicielle se décline en différentes notions selon les domaines abordés mais que ces notions sont reliées entre elles. Les exigences doivent être mutualisées, tout comme les efforts de conception, pour obtenir un logiciel efficient et stable. Ainsi, nos travaux de recherche nous montrent que le domaine de la qualité logicielle nécessite encore de nombreux travaux de recherche pour parvenir à concevoir un modèle qui puisse prendre en compte tous les aspects liés à la qualité d une application. 180

195 Annexe A Les pratiques du modèle Squash A.1 Les pratiques de code Ces pratiques sont calculées avec les métriques préalablement déterminées et choisies dans le projet Squale qui ont fait l objet d une étude [Balmas et al., 2009]. Ces pratiques permettent de déterminer la qualité du code et du design. Nom Chaque pratique est définie de la sorte : Nom de la pratique Critère Nom du critère qu il détaille Portée Portée de la pratique, type de composant sur lequel la note individuelle de la pratique est calculée. Métrique Liste des métriques utilisées Définition Définition de la pratique Note Formule de calcul de la note individuelle IM et de la note globale GM Poids Poids retenu pour le calcul de la note globale Dans cette instance du modèle, les poids appliqués avec la formule ISquale λ ont pour valeur : poids fort : 30 ; poids moyen : 9 ; poids faible : 3. Ces valeurs, qui permettent de renforcer le poids des mauvaises notes et de diminuer la tolérance au mauvaises notes individuelles, ont été déterminées avec les ingénieurs de Air France-KLM lors de la conception de la première instance du modèle. Ces poids ont été validés par Air France-KLM et PSA Peugeot-Citroën. Les pratiques définies pour l instance du modèle actuellement utilisée chez Generali sont les suivantes : 181

196 Annexe A. Les pratiques du modèle Squash Nom Profondeur d héritage Critère Simplicité Portée classe Métrique DIT (depth inheritance tree) Définition Pointe les classes qui ont une profondeur d héritage trop élevée. En effet, une telle classe est plus difficile à maintenir et à comprendre. Le seuil est fixé pour tenir compte des capacités humaines à comprendre facilement le code source et les différents appels faits dans le code. Il ne prend pas en compte l utilisation de frameworks et l héritage qui en découle : une classe peut être une sous-classe d un framework, ce qui augmente d autant sa profondeur d héritage alors que dans le contexte unique de l application sa profondeur d héritage n est pas forcément élevée. Note Note individuelle : 0 si dit > 7 1 si 7 dit > 6 2 si 6 dit > 5 3 si dit 5 Note globale de la pratique : I λ Squale Poids faible Nom Taux de commentaires Critère Documentation technique Portée méthode Métrique CLOC (number of lines of comments), SLOC (sources lines of code), V(G) (cyclomatic complexity) Définition Qualifie le taux de commentaires dans le code source. La Javadoc n est pas incluse pour calculer cette pratique. Cette pratique vérifie que plus le code d une méthode est complexe et plus il est commenté. Le nombre de lignes souhaité ne dépend donc pas seulement du nombre de lignes de code de la méthode mais également de sa complexité, calculée par la complexité cyclomatique. Le seuil dépend donc de cette complexité. De plus cette pratique n est pas calculée pour des méthodes ayant un nombre de lignes de code inférieur à un seuil fixé de façon à exclure de la pratique les méthodes accesseurs (getter et setter en Java). Le principe général est de vérifer qu il y a au moins 30 % de commentaires inclus dans chaque méthode. Note Note individuelle : Si V (G) >= 5 or SLOC > 30 : alors : IM = (CLOC) 9/(CLOC + SLOC)/(1 10 ( V (G)/15) ) 182 Principales valeurs des notes individuelles :

197 A.1. Les pratiques de code Note de la Pratique Métrique V(G) Taux de commentaires < % [0; 1[ 5 5% [0; 1[ > 15 10% [1; 2] 15 [2, 5; 3[ 25 30% % Note globale de la pratique : I λ Squale Poids faible Nom Nombre de méthodes Critère Simplicité Portée classe Métrique V(G) (cyclomatic complexity), NOM (number of local methods) Définition Qualifie le nombre de méthodes pour chaque classe. Cette pratique détecte les classes qui ont un trop grand nombre de méthodes. Elles centralisent trop de fonctionnalités et peuvent être difficiles à maintenir ou modifier. Note Note individuelle : si V (G) 80 alors IM = 2 (30 NOM)/10 si V (G) 50 et NOM 15 alors IM = 2 + (20 NOM)/30 si V (G) 30 alors IM = 3 + (15 NOM)/15 sinon IM = 3 Principales valeurs des notes individuelles : Note de la pratique valeur de V(G) valeur de NOM Note globale de la pratique : I λ Squale Poids moyen 183

198 Annexe A. Les pratiques du modèle Squash Nom Taille d une méthode Critère Simplicité Portée méthode Métrique SLOC (number of source lines of code) Définition Calcule la taille des méthodes pour alerter sur les méthodes trop longues car trop difficiles à maintenir et à comprendre. Le seuil par défaut est fixé à 70 lignes de code. Note Note individuelle : IM = 2 (70 SLOC)/21 Principales valeurs des notes individuelles : Valeur de la pratique Valeur de la métrique SLOC Note globale de la pratique : I λ Squale Poids moyen Nom Couteau suisse Critère Modularité 184

199 A.1. Les pratiques de code Portée classe Métrique LCOM4 (lack of cohesion in methods), Ca (afferent coupling), RFC (number of local methods) Définition Cette méthode recherche les classes dites utilitaires qui sont souvent trop difficiles à maintenir. Les classes couteau suisse ne respectent pas les principes objet d héritage et d encapsulation et augmentent fortement le couplage entre les objets. Il s agit généralement de classes sans parents ni enfants, avec peu, voire pas d attribut et un nombre relativement important de méthodes, parfois complexes. Elles sont appelées dans beaucoup trop de cas différents dans le programme. Note Note individuelle : 0 si Ca > 20 et LCOM4 > 2 et RF C > 30 3 si Ca 20 ou LCOM4 = 1 ou RF C 30 Note globale de la pratique : I λ Squale Poids faible Nom Cohésion de classe Critère modularité Portée classe Métrique LCOM4 (lack of cohesion in methods) Définition Qualifie les relations entre les méthodes dans une classe. La métrique utilisée dans cette pratique n est souvent pas celle réellement souhaitée du fait du manque d outils disponibles pour calculer la métrique. Une solution d amélioration serait d utiliser la métrique LCOM5 et d ajuster le calcul des seuils à cette nouvelle métrique. Le couplage ne doit pas être élevé au sein de la classe, tout en gardant une certaine cohérence. Ainsi, on ne doit pas pouvoir casser facilement des objets. Note Note individuelle : 0 si lcom4 2 definir note intermediaire si lcom4 a des valeurs intermédiaires 3 si lcom4 = 1 Note globale de la pratique : I λ Squale Poids faible Nom Couplage efférent Critère Modularité, interdépendance Portée classe Métrique Ce (efferent coupling) Définition Analyse la dépendance entre une classe et les autres classes de l application. Pour cela, elle étudie le niveau de dépendance réelle d une classe par rapport à l interface publique des autres classes. Cette pratique observe aussi les données publiques de l application. Les données déclarées en publique conduisent fréquemment à du couplage entre classes. Une classe qui fait appel à de nombreuses autres classes est potentiellement plus affectée en cas de modification des autres classes. 185

200 Annexe A. Les pratiques du modèle Squash Note Note individuelle : IM = 2 (10 Ce)/2 Principales valeurs des notes individuelles : Valeur de la pratique Valeur de la métrique Ce 3 <= >= 19 Note globale de la pratique : I λ Squale Poids faible Nom Couplage afférent Critère interdépendance Portée classe Métrique Ca (afferent coupling) Définition Cette pratique est le complément de la pratique couplage efférent. Elle analyse la dépendance des classes de l application vis à vis d une classe. C est donc le nombre de classes qui dépendent de la classe étudiée. Cette pratique pointe les classes qui ont trop de responsabilités dans le projet. Une modification de ce type de classe peut avoir d importantes répercutions 186

201 A.1. Les pratiques de code sur l ensemble du projet. Cette pratique est cependant délicate à interpréter. En effet, en principe une classe doit être appelée mais plus elle est appelée et plus ses modifications ont des conséquences. Note Note individuelle : IM = 2 (30 Ca)/7 Principales valeurs des notes individuelles : Valeur de la pratique Valeur de la métrique Ca Note globale de la pratique : I λ Squale Poids moyen Nom Code Spaghetti Critère Simplicité Portée méthode Métrique ev(g) (cyclomatic complexity), SLOC (number of source lines of code) Définition Qualifie le niveau de déstructuration et de complexité du code, mettant en évidence les parties de code source à risque, car difficilement compréhénsibles et donc difficilement maintenables. Dès que le niveau de complexité essentiel et non essentiel est dépassé, il faut commencer à investiguer les méthodes remontées pour un éventuel remaniement. Un filtre est appliqué au niveau de nombre de lignes de code source afin de ne pas remonter des méthodes 187

202 Annexe A. Les pratiques du modèle Squash déstructurées mais courtes et maintenables car correspondant à une pratique de codage connue (exemple : l implémentation des méthodes equals(object) en Java). Note Note individuelle : Si SLOC > 30 : Alors : IM = 2 (6 ev (G))/3 Principales valeurs des notes individuelles : Valeur de la pratique Valeur de la métrique ev(g) Note globale de la pratique : I λ Squale Poids moyen Nom Copier-Coller Critère Modularité Portée projet Métrique SLOC (number of source lines of code) 188

203 A.1. Les pratiques de code Définition Traque les parties du code source qui ont été dupliquées par simple copier-coller, avec parfois un simple renommage des données. Cette façon très productive de procéder a le défaut de dupliquer les efforts de test et de dupliquer les éventuels bugs. Cette pratique est très dépendante des outils utilisés pour détecter ces lignes de code dupliqués, donc la formule doit être adaptée à l outil utilisé. Dans tous les cas, elles doit être sévère et notamment pour le code orienté objet : ceci ne devrait pas avoir lieu dans un développement Orienté Objet (utilisation de la factorisation par les mécanismes de l héritage par exemple). Note Note globale de la pratique : mark = Number_of_copiedlines sloc Karine nombre ligne dupliquée calcule par sonar Copy paste 3,5 3,0 2,5 2,0 1,5 1,0 0,5 0, taux de lignes copiées Principales Valeurs : Valeur de la pratique taux de lignes copiées Poids faible Nom Niveau d abstraction et de stabilité Critère Modularité de l architecture Portée package 189

204 Annexe A. Les pratiques du modèle Squash Métrique D (Distance) Définition Qualifie la gestion et la cohérence d un package en terme d abstraction (ou non) et de stabilité. Cela permet de bien différencier notamment les interfaces des implémentations. Un package abstrait doit avoir un couplage efférent faible tandis qu un package d implémentation doit avoir un couplage afférent faible. Note Note individuelle : IM = Distance 25 Principales valeurs des notes individuelles : Valeur de la pratique Valeur de la métrique D Note globale de la pratique : I λ Squale Poids faible Nom Dépendance cyclique Critère Modularité de l architecture, Portabilité Portée package Métrique jdepend.cycle Définition Cette pratique met en avant tous les cas de dépendance cyclique des packages, mettant en avant soit une mauvaise conception, soit une mauvaise implémentation et répartition des classes au sein du projet. La formule de cette pratique est dépendante de l outil utilisé pour détecter les cycles. Note La note individuelle est calculée par rapport à un ratio de transgressions Note individuelle : 0 s il existe un cycle 3 s il n y a pas de cycle Note globale de la pratique : simple moyenne des notes des packages. Poids faible A.2 Les pratiques de normes et standard Chaque pratique est définie de la sorte : 190

205 A.2. Les pratiques de normes et standard Nom Nom de la pratique Critère Nom du critère qu elle détaille Portée Portée de la pratique Métrique Métrique utilisée Définition Définition de la pratique Note Note de la pratique Poids Poids appliqué Les pratiques définies pour l instance du modèle actuellement utilisée chez Generali sont les suivantes : Nom Normes et standard : respect de l architecture en couche Critère Respect de l architecture Portée projet Métrique Nombre de classes Définition Détermine le niveau de respect de l architecture définie initialement. Cette pratique calcule le niveau de transgression. Note Note globale de la pratique : mark = Poids fort. Par défaut les pondérations sont les suivantes : W1 : 500 W2 : 30 W3 : 5 W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber Number_of_Classes Nom Normes et standard : Documentation Critère Documentation technique Portée projet Métrique SLOC (number of source lines of code) Définition Détermine si la documentation extractible (exemple, Javadoc) existe dans le projet. Ne qualifie pas les commentaires des lignes de code. Note Note globale : mark = Poids fort. Par défaut les pondérations sont les suivantes : W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC 191

206 Annexe A. Les pratiques du modèle Squash W1 : 500 W2 : 30 W3 : 5 Nom Normes et standard : mise en forme Critère Homogeneité Portée project Métrique SLOC (number of source lines of code) Définition Détermine si les règles de mise en forme du code sont respectées. Vérifie l homogénéité du code source. Note Note globale : mark = Poids faible. Par défaut les pondérations sont les suivantes : W1 : 100 W2 : 20 W3 : 5 W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC Nom Normes et standard : convention de nommage Critère Homogeneité Portée projet Métrique SLOC (number of source lines of code) Définition Détermine le niveau de respect des règles de nommage des types de données et méthodes du code. Note Note globale : mark = Poids faible. Par défaut les pondérations sont les suivantes : W1 : 200 W2 : 25 W3 : 5 W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC Nom Normes et standard : traçage Critère Normes de performance, stabilité, portabilité 192

207 A.2. Les pratiques de normes et standard Portée projet Métrique SLOC (number of source lines of code) Définition Qualifie les éléments de traçage pour la génération automatique de fichiers de logs. Note Note globale : mark = Poids fort. Par défaut les pondérations sont les suivantes : W1 : 500 W2 : 30 W3 : 5 W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC Nom Normes et standard : sécurité Critère Normes de sécurité Portée project Métrique SLOC (number of source lines of code) Définition Qualifie le respect des règles de sécurité pour les lignes de code. Note Note globale : mark = Poids fort. Par défaut les pondérations sont les suivantes : W1 : 500 W2 : 30 W3 : 5 W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC Nom Normes et standard : portabilité Critère Normes de performances, portabilité Portée projet Métrique SLOC (number of source lines of code) Définition Détermine la portabilité de l application. Vérifie qu il n y a d instruction comportant une dépendance matérielle ou logicielle. Note Note globale : mark = W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC 193

208 Annexe A. Les pratiques du modèle Squash Poids fort. Par défaut les pondérations sont les suivantes : W1 : 500 W2 : 30 W3 : 5 Nom Normes et standard : programmation Critère homogeneité Portée projet Métrique SLOC (number of lines of code) Définition Détermine le niveau de respect des règles de programmation et de codage du projet. Note Note globale : mark = W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC Poids faible. Par défaut les pondérations sont les suivantes : W1 : 200 W2 : 25 W3 : 5 Nom Normes et standard : gestion de configuration Critère homogeneité Portée projet Métrique SLOC (number of lines of code) Définition Vérification de l utilisation de la gestion de configuration : utilisation et gestion des branches et des labels. Note Note globale : mark = W 1 ErrorNumber+W 2 W arningnumber+w 3 InfoNumber SLOC Poids faible. Par défaut les pondérations sont les suivantes : W1 : 200 W2 : 25 W3 : 5 194

209 A.3. Les pratiques de modèle A.3 Les pratiques de modèle Chaque pratique est définie de la sorte : Nom Nom de la pratique Critère Nom du critère qu elle détaille Portée Portée de la pratique Métrique Métrique utilisée selon les cas Définition Définition de la pratique Note Note de la pratique Les pratiques définies pour l instance du modèle actuellement utilisée chez Generali sont les suivantes : Nom Diagramme de modélisation Critère Modélisation Portée projet Définition Vérifie la pertinence et la validation des diagrammes du cycle de modélisation (diagramme de classes et modèle de données) Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Le diagramme de classes s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 est cohérent C2 Le modèle de données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 est cohérent C3 Le diagramme de classes s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 est validé C4 Le modèle de données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 est validé C5 Le diagramme de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 classes correspond aux exigences C6 Le modèle de données correspond aux s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 exigences Nom pré-dectection d antipatterns Critère Modélisation 195

210 Annexe A. Les pratiques du modèle Squash Portée projet Définition Si dans le projet est utilisé de la génération automatique de code, cette pratique vise à déterminer dès la phase de modélisation des antipatterns connus et identifiables. Cette pratique est divisée en 8 sous-pratiques qui détectent les antipatterns suivants : Profondeur d héritage Classe couteau suisse Présence d attributs publics Nombre de méthodes Spécialisation de la classe Encapsulation Classes sans méthode Classes sans attribut Classes isolées Les Sous pratiques Profondeur d héritage, Classe couteau suisse, Nombre de méthodes, Spécialisation de la classe sont définies dans la section A.1. Les autres sont définies ci-dessous. Chaque cas remonté doit être considéré comme un cas suspect qu il convient d examiner afin de confirmer ou d infirmer la suspicion d antipattern en fonction du contexte et des justifications fournies. Note Note globale de la pratique : moyenne simple des notes des sous-pratiques(chacune représentant 1/8 de la note). Nom Encapsulation Critère pratique pré-dectection d antipatterns Portée classe Métrique Nombre de champs publics Définition Qualifie le nombre de champs publics de la classe. Les champs publics doivent être évités. Il est recommandé d utiliser des accesseurs à la place, permettant un respect des règles de la programmation objet et notamment l encapsulation. Note Note individuelle : 0 s il y a un champ public 3 s il n y a pas de champ public. Note globale de la pratique : I λ Squale Nom Classe sans méthode Critère pratique pré-dectection d antipatterns Portée classe Métrique NOM (number of methods) Définition Qualifie le nombre de méthode pour une classe. Une classe doit avoir au moins des accesseurs pour accéder à ses attributs et des méthodes pour exécuter ses traitements. Une classe sans méthode signifie qu elle n est qu une structure de données. 196

211 A.3. Les pratiques de modèle Note Note individuelle : 0 s il n y a pas de méthode 3 s il y a des méthodes Note globale de la pratique : I λ Squale Nom Classes sans attribut Critère pratique pré-dectection d antipatterns Portée classe Métrique number of fields Définition Qualifie le nombre d attribut de la classe. Une classe doit avoir au moins un champ pour décrire son instance. Si une classe possède des méthodes et pas d attribut cela signifie qu elle traite des données extérieures. Note Note individuelle : 0 s il n y a pas d attribut 3 s il y a au moins un attribut. Note globale de la pratique : I λ Squale Nom Classes isolées Critère pratique pré-dectection d antipatterns Portée classe Métrique DepClients, DepSuppliers Définition Qualifie la relation entre la classe et le reste du projet (que ce soit une composition, une agrégation, un héritage ou tout autre forme de dépendance). Une classe doit être en relation avec les autres pour assurer sa raison d être dans le modèle. Note Note individuelle : 0 si Depclient et DepSupplier = 0 3 si Depclient ou DepSupplier!= 0 Note globale de la pratique : I λ Squale Nom Raisonnement par les modèles Critère Modélisation Portée projet Définition Evalue le niveau de raisonnement par modèle en cas de correction, modification ou addition de fonctionnalités dans le projet. Ceci signifie qu un changement doit d abord être intégré dans le modèle avant d être codé, pour conserver une cohérence. 197

212 Annexe A. Les pratiques du modèle Squash Note Note globale : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Les changements sont s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 30 intégrés d abord dans le modèle C2 Le modèle intègre les s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 corrections C3 Le modèle intègre les s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 modifications C4 Le modèle intègre les s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 ajouts de fonctionnalités C5 Le modèle est validé à s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 chaque changement Nom Conformité entre modélisation et implémentation Critère Modélisation Portée projet Définition Qualifie la cohérence entre le modèle et l implémentation. Vérifie que le contrôle de la cohérence existe et qu il est automatisé. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Cohérence entre implémentation et modèle s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 5 C2 Vérification de la cohérence s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 C3 Automatisation de la s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 vérification de la cohérence A.4 Les pratiques de tests A.4.1 Les pratiques de tests de développement Il s agit des tests pratiqués par les développeurs sur le code source. Ce sont des tests en boîte blanche. Les différentes pratiques de tests unitaires s attachent à déterminer sir les tests unitaires couvrent bien tout le code source, s il sont réussis et s ils sont définis de manière rigoureuse. Nom Taux de réussite des Tests unitaires 198

213 A.4. Les pratiques de tests Critère Tests développement Portée méthode Métrique nombre de tests unitaires, nombre d échec Définition Test Pendant le développement, par les développeurs. Teste les différents modules en isolation. Un module peut être une classe, une méthode, un package,etc. Définition Pratique Qualifie les tests unitaires appliqués au programme. Pour un module donné, il faut que les tests unitaires soient passés et avec un taux minimum d échec. Note Note individuelle : GM = 2 (15 Ratio)/9 Avec Ratio qui représente le pourcentage de tests unitaires en échec. Principales valeurs des notes individuelles : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 6 % 1.5 % 1 15 % 0.5 % 0 % Note globale : I λ Squale Poids moyen Nom Exigences des tests unitaires Critère Tests développement Portée méthode 199

214 Annexe A. Les pratiques du modèle Squash Métrique complexité cyclomatique, nombre de tests Définition Qualifie la qualité des tests unitaires. Cette pratique s intéresse à qualifier la méthodologie attachée aux tests unitaires. Les tests unitaires doivent être définis en fonction de la complexité du module testé : comme principe de base, chaque module devrait avoir un nombre de cas de tests au moins égal au nombre cyclomatique. Note Note individuelle : GM = 2 ((NbreT ests 100/V (G)) 70)/19 Avec NbreT ests qui représente le nombre de tests unitaires appliqués au module et V (G) la complexité cyclomatique du module. Principales valeurs des notes individuelles avec ratio qui représente le rapport entre le nombre de tests unitaires et la complexité cyclomatique : Valeur de la pratique Valeur du ratio % 2.5 % 2 89 % 1.5 % 1 70 % 0.5 % 0 % Note globale : I λ Squale Poids moyen Nom Couverture des tests unitaires Critère Tests développement Portée méthode 200

215 A.4. Les pratiques de tests Métrique code coverage, branch code coverage ; cobertura plugin sonar Définition Qualifie le taux de couverture des tests unitaires. En fonction d un seuil donné. L idéal à atteindre n étant pas forcément 100%. Il faut distinguer deux types de couverture : couverture des branches et couverture du nombre de ligne de code. Note Note Individuelle : 3 (branch_code_coverage + code_coverage)/200 Note globale : I λ Squale Poids moyen Nom Taux de réussite des tests d intégration Critère Tests développement Portée package Métrique nombre de tests d intégration, nombre d échecs Définition Test Pendant le développement. Tester le bon comportement lors de la composition des modules. Définition Pratique Qualifie les tests d intégration appliqués au programme en fonction du nombre de tests qui restent en échec. La pratique prend en compte également le nombre de tests réalisés en fonction du nombre de tests attendus. Note Note individuelle : GM = 2 (15 Ratio)/9 Avec Ratio qui représente le pourcentage de tests en échec. Principales valeurs des notes individuelles : 201

216 Annexe A. Les pratiques du modèle Squash Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 6 % 1.5 % 1 15 % 0.5 % 0 % Note globale : I λ Squale Poids moyen Nom Stratégie des tests d intégration Critère Test développement Portée projet Définition Qualifie la stratégie mise en oeuvre pour gérer les tests d intégration. Cette stratégie doit déterminer quels sont les tests à mettre en place, quels sont les stratégies de rejeu de tests, les tests doivent faire l objet d un suivi intégré, les tests en échecs doivent être rejoués, les modifications du programme doivent être répercutés sur les tests. Dans certain cas ces tests peuvent être également fonctionnels, se basant sur des exigences métier mais d un point de vue développeur. Note Note globale de la pratique : Nom Caractéristique oui non Poids C1 Existence des tests d intégration s 2 1 s 2 0 0, Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Définition de la stratégie des test d intégra- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 tion C3 Rejeu des tests d intégration s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C4 Suivi des tests d intégration lors de modifica- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 tion C5 Suivi des tests en échec s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 C6 Taux d échec des tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 C7 Validation de la stratégie des test d intégra- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 05 tion if s C1 == s 2 0 then GM = 0 else

217 A.4. Les pratiques de tests GM = end if 7 w k.s Ck k=1 Nom Couverture des tests d intégration Critère Test développement Portée projet Métrique code coverage, branch code coverage Définition qualifie le taux de couverture des tests d intégration. En fonction d un seuil donné. L idéal à atteindre n étant pas forcément 100% Note Note individuelle : Note globale : I λ Squale Poids moyen 3 (branch_code_coverage + code_coverage)/200 Nom Cycle de vie des tests de développement Critère Tests développement Portée projet Définition On vérifie que les TU et le TI sont rejoués et font partie intégrante du cycle de développement du produit. On vérifie que les tests font partie du build et sont rejoués à chaque commit. Note Note globale de la pratique : Nom Caractéristique oui non Poids C1 Intégration des tests dans les s 2 1 s 2 0 0, 25 versions Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Rejeu des TU à chaque s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 modification C3 Rejeu des TI à chaque s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 build C4 Automatisation du rejeu des TI s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 125 C5 Automatisation du rejeu des TU s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 125 C6 Build fait en continu s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 if s C1 == s 2 0 then GM = 0 203

218 Annexe A. Les pratiques du modèle Squash else GM = end if 6 w k.s Ck k=1 A.4.2 Les pratiques de tests fonctionnels Nom Il s agit des pratiques qui se rapportent aux tests fonctionnels. Exigences fonctionnelles Critère Tests fonctionnels Portée projet Définition Vérifie que les exigences fonctionnelles sont précisées et leur niveau de qualité. Cette pratique évalue la qualité des exigences fonctionnelles : la rédaction, le détail, la gestion dans un référentiel, leur association à au moins un cas de tests, leur suivie dans le cycle de vie. Note Note globale de la pratique : Nom Caractéristique oui non Poids C1 Existence des exigences fonctionnelles s 2 1 s 2 0 0, Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Précision de la description des exigences fonc- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 tionnelles C3 Association des exigences aux cas de tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 (au moins un cas de test) C4 Gestion des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C5 Lien entre exigences et s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 cas de tests dans le référentiel C6 Classement des exigences en fonction de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 leur criticité C7 Gestion du cycle de vie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 09 des exigences if s C1 == s 2 0 then GM = 0 else 7 GM = w k.s Ck k=1

219 A.4. Les pratiques de tests end if Nom Rédaction des cas de tests fonctionnels Critère Tests fonctionnels Portée projet Définition Vérifie que les cas de tests sont rédigés en détail, ils sont rattachés aux exigences, ils sont gérés dans un référentiel, avec des pas de tests décrits en détail, les pas de tests suivent une formalisation précise dans leur rédaction (nombre de pas, niveau de détail,etc). Note Note globale de la pratique : Nom Caractéristique oui non Poids C1 Les cas de tests sont rédigés s 2 1 s 2 0 0, 25 Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Qualité de la rédaction s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 20 des cas de tests C3 Rédaction des pas de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 tests C4 Qualité de la rédaction s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 des pas de tests C5 Gestion des pas de tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 dans un référentiel C6 Formalisation normée s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 de la rédaction des pas de tests if s C1 == s 2 0 then GM = 0 else 6 GM = w k.s Ck end if k=1 Nom Couverture des cas de tests fonctionnels Critère Tests fonctionnels Portée projet Définition Il s agit de vérifier que les cas de tests couvrent les exigences définies préalablement. Il faut au moins un cas de test par exigence. Pour 85 % de tests par rapport aux exigences, la note de la pratique est de 2, elle monte à 3 pour 100 %. On prend en compte également la criticité des exigences. Une exigence majeure doit être plus couverte qu une exigence mineure. Note Note globale : 205

220 Annexe A. Les pratiques du modèle Squash GM = 2 ((3 Ratio Critique+Ratio Autre ) 225)/90 Avec Ratio Critique qui représente le pourcentage de couverture des exigences majeures et Ratio Autre qui représente le taux de couverture des exigences mineures. Un poids de 3 est appliqué pour renforcer les exigences majeures. Principales valeurs des notes globales : Valeur de la pratique Ratio exigences critiques Ratio exigences autres % 70 % 2.5 % 2 85 % 60 % 1.5 % 1 60% 45 % 0.5 % 0 % Nom Données fonctionnelles Critère Tests fonctionnels Portée projet Définition Il s agit de déterminer si les données utilisées pour les tests fonctionnels sont en adéquation avec ces tests. Sont vérifiés : la pertinence des données, les besoins, la validation des données par rapport aux besoins, la gestion des données. Note Note globale de la pratique : 206

221 A.4. Les pratiques de tests Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Vérification de la pertinence des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 C2 Précision de la description des besoins de don- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 nées C3 Validation des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 par rapport aux besoins C4 Gestion des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C5 Facilité de manipulation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 et d injection des données if s C1 == s 9 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 Nom Données aux limites Critère Tests fonctionnels Portée projet Définition Les tests aux limites nécessitent des données particulières. Cette pratique vérifie que ces données sont correctes. Note Note globale de la pratique : Nom Caractéristique oui non Poids C1 Existence de tests aux limites s 2 1 s 2 0 0,

222 Annexe A. Les pratiques du modèle Squash Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Vérification de la pertinence des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C3 Précision de la description des besoins de don- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 nées aux limites C4 Validation des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 par rapport aux besoins C5 Couverture des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 par rapport aux cas nécéssaires C6 Gestion des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C7 Facilité de manipulation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 5 et d injection des données if s C1 == s 2 0 then GM = 0 else 7 GM = w k.s Ck end if k=1 Nom Taux de réussite des tests fonctionnels Critère Tests fonctionnels Portée projet Métrique nombre de tests effectués, nombre de tests réussis Définition Test Ces tests servent à vérifier que les exigences définies dans le cahier des charges sont réalisées. Définition Pratique Plus une application est de qualité et plus les tests fonctionnels effectués sont corrects. Note Note globale : GM = 2 (30 Ratio)/ Avec Ratio qui représente le pourcentage de tests fonctionnels en échec.

223 A.4. Les pratiques de tests Principales valeurs des notes globales : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 20 % 1.5 % 1 30 % 0.5 % 0 % Poids aucun Nom Taux de couverture des tests fonctionnels Critère Tests fonctionnels Portée projet Définition Les tests passés sont en corrélation avec les exigences et la rédaction des cas de test. On vérifie le pourcentage de tests effectués par rapport aux cas de tests rédigés. Note Note globale : O aucune mise en relation entre les tests et la rédaction des cas de tests 1 les tests sont basés sur des cas de tests mais il n y a pas de vérification du taux de couverture à partir de 1 : pourcentage entre les cas de tests et les tests effectués réellement. GM = 2 (Ratio 60)/25 209

224 Annexe A. Les pratiques du modèle Squash Principales valeurs des notes globales : Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % 0.5 % 0 % Nom Couverture des données fonctionnelles Critère Tests fonctionnels Portée projet Définition Il s agit de déterminer si les données utilisées pour les tests fonctionnels couvrent tous les besoins. La note prend en compte la criticité des exigences lorsque celles-ci sont classées, avec une note maximum pour 100% des exigences critiques, etc, tels que défini dans le tableau ci-dessous. Note Note globale : Lorsque les exigences n ont pas de classement : GM = 2 (Ratio 60)/ Avec Ratio qui représente le taux de couverture des exigences par les données.

225 A.4. Les pratiques de tests Valeur de la pratique Ratio exigences % 2.5 % 2 85 % 1.5 % 1 60% 0.5 % 0 % Lorsque les exigences sont classées : GM = 2 ((3 Ratio Critique+Ratio A utre) 230)/90 Principales valeurs des notes globales : 211

226 Annexe A. Les pratiques du modèle Squash Valeur de la pratique Ratio exigences critiques Ratio exigences autres % 70 % 2.5 % 2 85 % 60 % 1.5 % 1 60% 45 % 0.5 % 0 % Nom Cycle de vie des tests fonctionnels Critère Tests fonctionnels Portée projet Définition Détermine si les tests sont intégrés dans le cycle de vie du logiciel, s ils suivent la même évolution. Les tests ont différents statut en fonction du cycle de vie du logiciel : nouveau, exécutable, obsolète, supprimé, etc. Note Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Intégration des tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 dans un cycle C2 Corrélation entre exigences et cycle de vie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 des tests C3 Rejeu des tests en fonction de leur cycle de vie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C4 Qualité de la stratégie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 de rejeu des tests C5 Prise en compte du classement des tests dans la s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 stratégie if s C1 == s 9 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 Nom Tests d acceptation Critère Tests fonctionnels Portée projet Métrique 212

227 A.4. Les pratiques de tests Définition Test Ces tests servent à vérifier que le système fonctionne entièrement dans les conditions réelles d utilisation. Il doivent s effectuer avec des jeux de données réelles. Définition Pratique Egalement appelés tests d acceptation. Le système est testé entièrement dans les conditions réelles d utilisation. Note Note globale : GM = 2 (30 Ratio)/10 Avec Ratio qui représente le pourcentage de tests fonctionnels en échec. Principales valeurs des notes globales : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 20 % 1.5 % 1 30 % 0.5 % 0 % Poids aucun Nom Taux de couverture des tests d acceptation Critère Tests fonctionnels Portée projet Définition Les tests passés sont en corrélation avec les exigences et la rédaction des cas de test. On vérifie le pourcentage de tests effectués par rapport aux cas de tests rédigés. Note Note globale : O aucune mise en relation entre les tests et la rédaction des cas de tests 213

228 Annexe A. Les pratiques du modèle Squash 1 les tests sont basés sur des cas de tests mais il n y a pas de vérification du taux de couverture à partir de 1 : pourcentage entre les cas de tests et les tests effectués réellement. GM = 2 (Ratio 60)/25 Principales valeurs des notes globales : Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % 0.5 % 0 % Nom Stratégie des tests de non régression Critère Tests fonctionnels Portée projet Définition Il s agit de déterminer si les tests de non régression suivent une stratégie définie et couvrent les exigences impactées par la nouvelle livraison. Les exigences doivent être sélectionnées. Les tests sont rejoués en fonction de leur statut : obsolètes, modifiés, stagnation, évolution, etc. Note Note globale de la pratique : 214 Nom Caractéristique oui non Poids C1 Existence de tests de non regression s 2 1 s 2 0 0, 3

229 A.4. Les pratiques de tests Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Vérification de la pertinence des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 C3 Précision de la description des besoins de don- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 nées aux limites C4 Validation des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 par rapport aux besoins if s C1 == s 2 0 then GM = 0 else 4 GM = w k.s Ck end if k=1 Nom Taux de couverture des tests de non régression Critère Tests fonctionnels Portée projet Définition Les tests passés sont en corrélation avec la stratégie de non régression définie. On vérifie le pourcentage de tests effectués par rapport aux tests retenus. Note Note globale de la pratique : O aucune mise en relation entre les tests passé et la stratégie de non régression. 1 Les tests sont sélectionnés auparavant. à partir de 1 : pourcentage entre les tests sélectionnés et les tests effectués réellement. pour 80 % de tests par rapport aux exigences on obtient la note de 2, qui monte à 3 pour 100 %. GM = 2 (Ratio 60)/25 Principales valeurs des notes globales : 215

230 Annexe A. Les pratiques du modèle Squash Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % 0.5 % 0 % A.4.3 Les pratiques de tests automatisés Nom Testabilité de l application Critère Automatisation des tests Portée Projet Définition La stratégie des cas automatisables est définie dans le plan de tests. On définit les tests auto, les champs de tests auto ou les tests qui doivent être manuels. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Qualité de la définition s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 des cas de tests automatisés C2 Suivie de la stratégie des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 26 cas de tests C3 Qualité de définition de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 26 la stratégie C4 Prise en compte de la s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 maturité dans la stratégie if s C1 == s 9 0 then GM = 0 else 4 GM = w k.s Ck end if k=1 Liste des caractéristiques : Nom Tests automatisés Critère Automatisation des tests Portée Projet 216

231 A.4. Les pratiques de tests Définition Les tests automatisés doivent être maintenables facilement, exploitables et indépendants. les modifications des cas de tests doivent être impactés et les reporting autour des tests doivent être précis. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Facilité de maintenance s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 des tests automatisés C2 Impact automatique sur s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 les tests des modifications des cas de tests C3 Gestion des scripts automatiques s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 14 C4 Mise à jour des scripts s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 C5 Facilité d analyse des erreurs grâce au s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 reporting if s C1 == s 9 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 Nom Cycle de vie des tests automatisés Critère Automatisation des tests Portée projet Définition Il existe deux choix possibles : des tests construits de manière logique ou physique. Dans le cas de tests définis de manière logique, le cycle de vie doit prendre en compte la reconstruction des tests à chaque version. Note Note globale manuelle : Nom Caractéristique oui non Poids C1 Existence d un cycle de vie s 2 1 s 2 0 0,

232 Annexe A. Les pratiques du modèle Squash Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Réinitialisation automatique des tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C3 Vérification de la reconstruction des tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 C4 Mise à jour automatique s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 des tests C5 Exécution automatique s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 14 des tests C6 Reconstruction des tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 à chaque phase de tests if s C1 == s 2 0 then GM = 0 else 6 GM = w k.s Ck end if k=1 Nom Maturité des tests automatiques Critère Automatisation des tests Portée Projet Définition On qualifie le nombre de tests automatisés mis en place par rapport à ce qu il est possible d automatiser, la testabilité de l application. Il s agit de déterminer si les tests qui peuvent être automatisés le sont réellement. Note Note globale : GM = 2 (Ratio 10)/ Principales valeurs des notes :

233 A.4. Les pratiques de tests Valeur de la pratique Valeur du ratio % 2.5 % 2 60 % 1.5 % 1 10 % 0.5 % 0 % Nom Données de tests automatisés Critère Automatisation des tests Portée projet Définition On détermine la qualité des données de tests automatiques Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Définition d une stratégie suivie par les don- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 nées C2 Choix des données en s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 17 fonction de leur pertinence C3 Représentativité des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 données C4 Validation des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 C5 Gestion des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C6 Manipulation et injection facile des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 données if s C1 == s 9 0 then GM = 0 else 6 GM = w k.s Ck end if k=1 Nom Couverture des données de tests automatisés Critère Tests automatisés Portée projet Définition Il s agit de déterminer si les données utilisées pour les tests automatisés couvrent tous les besoins. 219

234 Annexe A. Les pratiques du modèle Squash Note Note globale : GM = 2 (Ratio 60)/25 Principales valeurs des notes : Valeur de la pratique Valeur du ratio % 2.5 % 2 85 % 1.5 % 1 60 % 0.5 % 0 % A.4.4 les pratiques de tests applicatifs Nom Exigences applicatif Critère Tests applicatif Portée projet Définition Il s agit de déterminer si les exigences qui se rapportent aux tests applicatifs (montée en charge, performance, robustesse) sont précises et utilisées dans la rédaction des cas de tests. Note Note globale de la pratique : 220 Nom Caractéristique oui non Poids C1 Existence d exigences de type s 2 1 s 2 0 0, 25 aplicatif

235 A.4. Les pratiques de tests Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Précision de la description des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 C3 Association exigences et s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 cas de tests C4 Gestion des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C5 Gestion des liens entre s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 les exigences et les cas de tests C6 Classement des exigences en fonction de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 leur criticité C7 Gestion du cycle de vie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 des exigences if s C1 == s 2 0 then GM = 0 else 7 GM = w k.s Ck end if k=1 Nom Données applicatif Critère Tests de charge Portée projet Définition Détermine si les données utilisées pour les tests de charge (montée en charge, performance, robustesse) sont en adéquation avec ces tests. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Vérification de la pertinence des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 C2 Précision de la description des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 C3 Validation des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 par rapport aux besoins C4 Gestion des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C5 Facilité de manipulation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 08 et injection des données if s C1 == s 9 0 then GM = 0 221

236 Annexe A. Les pratiques du modèle Squash else GM = end if 5 w k.s Ck k=1 Nom Couverture des données applicatif Critère Tests applicatif Portée projet Définition Il s agit de déterminer si les données utilisées pour les tests applicatifs couvrent tous les besoins Note Note globale de la pratique : GM = 2 (Ratio 60)/25 Principales valeurs des notes : Valeur de la pratique Valeur du ratio % 2.5 % 2 85 % 1.5 % 1 60 % 0.5 % 0 % Nom Tests de montée en charge Critère Tests applicatif 222

237 A.4. Les pratiques de tests Portée projet Métrique utilisateurs, pages/s, erreurs, bande passante, durée page min, durée page moy, durée page maw, utilisateurs attente, temps moyen d attente Définition Test Tests durant lequel on monte le nombre d utilisateurs, d accès, etc, afin de valider si l application répond à la charge attendue. Il permet de mesurer la bande passante requise, les serveurs nécessaires et vérifie l architecture technique. Définition Pratique Qualifie le fait de faire des tests de charge mais également le résultat obtenu par ces tests par rapport aux exigences attendues. Cette pratique détermine le taux de réussite des tests par rapport aux exigences. Note Note globale : GM = 2 (30 Ratio)/10 Avec Ratio qui représente le pourcentage de tests de montée en charge en échec. Principales valeurs des notes globales : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 20 % 1.5 % 1 30 % 0.5 % 0 % Poids aucun Nom Couverture des tests de montée en charge Critère Tests applicatif 223

238 Annexe A. Les pratiques du modèle Squash Portée projet Définition Détermine le taux de couverture des tests de montée en charge, par rapport aux exigences définies. Note Note globale : O aucune mise en relation entre les tests et les exigences 1 les tests sont basés sur les exigences mais il n y a pas de vérification du taux de couverture à partir de 1 : pourcentage ces exigences couvertes par les tests. GM = 2 (Ratio 60)/25 Principales valeurs des notes globales : Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % Nom Tests de robustesse Critère Tests applicatif Portée projet Métrique Définition Test Le test de robustesse (appelé également test du singe) vise à vérifier la capacité d un système ou d un composant à fonctionner de façon acceptable en dépit d aléas. Comment réagit le système face à des événements imprévus. La capacité d un système à adopter un comportement acceptable en présence d entrées invalides ou d environnement stressant. une propriété importante : le choix des aléas. Définition Pratique Détermine le taux de réussite de ces tests par rapport aux exigences. 224

239 A.4. Les pratiques de tests Note Note globale : GM = 2 (30 Ratio)/10 Avec Ratio qui représente le pourcentage de tests de robustesse en échec par rapport aux exigences attendues. Principales valeurs des notes globales : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 20 % 1.5 % 1 30 % 0.5 % 0 % Poids aucun Nom Couverture des tests de robustesse Critère Tests applicatif Portée projet Définition Détermine le taux de couverture des tests de robustesse, par rapport aux exigences définies. Note Note globale : O aucune mise en relation entre les tests et les exigences 1 les tests sont basés sur les exigences mais il n y a pas de vérification du taux de couverture à partir de 1 : pourcentage ces exigences couvertes par les tests. GM = 2 (Ratio 60)/25 225

240 Annexe A. Les pratiques du modèle Squash Principales valeurs des notes globales : Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % Nom Tests de performance Critère Tests applicatif Portée projet Métrique Définition Test Ces tests vérifient que les performances attendues pour l exploitation du logiciel sont correctes. Par exemple, les temps de réponse du système, la gestion de la mémoire, etc. Définition Pratique Détermine la qualité du taux de réussite de ces tests. Note Note globale : GM = 2 (30 Ratio)/ Avec Ratio qui représente le pourcentage de tests de performance en échec par rapport aux exigences attendues.

241 A.4. Les pratiques de tests Principales valeurs des notes globales : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 20 % 1.5 % 1 30 % 0.5 % 0 % Poids aucun Nom Couverture des tests de performance Critère Tests applicatif Portée projet Définition Détermine le taux de couverture des tests de performance, par rapport aux exigences définies Note Note globale : O aucune mise en relation entre les tests et les exigences 1 les tests sont basés sur les exigences mais il n y a pas de vérification du taux de couverture à partir de 1 : pourcentage ces exigences couvertes par les tests. GM = 2 (Ratio 60)/25 227

242 Annexe A. Les pratiques du modèle Squash Principales valeurs des notes globales : Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % A.4.5 Les pratiques de tests système Nom Exigences système Critère Exploitabilité Portée projet Définition Il s agit de déterminer si les exigences qui se rapportent aux tests système (intégration système, configuration) sont précises et utilisées pour la réalisation des tests. Note Note globale de la pratique : 228 Nom Caractéristique oui non Poids C1 Existence d exigences de type s 2 1 s 2 0 0, 25 système

243 A.4. Les pratiques de tests Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Précision de la description des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 C3 Association exigences et s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 cas de tests C4 Gestion des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C5 Gestion des liens entre s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 les exigences et les cas de tests C6 Classement des exigences en fonction de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 leur criticité C7 Gestion du cycle de vie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 des exigences if s C1 == s 2 0 then GM = 0 else 7 GM = w k.s Ck end if k=1 Nom Données système Critère Exploitabilité Portée projet Définition Il s agit de déterminer si les données utilisées pour les tests système (intégration système, configuration) sont en adéquation avec ces tests Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Vérification de la pertinence des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 C2 Précision de la description des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 C3 Validation des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 par rapport aux besoins C4 Gestion des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C5 Facilité de manipulation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 08 et injection des données if s C1 == s 9 0 then GM = 0 229

244 Annexe A. Les pratiques du modèle Squash else GM = end if 5 w k.s Ck k=1 Nom Couverture des données système Critère Exploitabilité Portée projet Définition Il s agit de déterminer si les données utilisées pour les tests système couvrent tous les besoins Note Note globale de la pratique : GM = 2 (Ratio 60)/25 Principales valeurs des notes : Valeur de la pratique Valeur du ratio % 2.5 % 2 85 % 1.5 % 1 60 % 0.5 % 0 % Nom Tests de configuration/installation Critère Exploitabilité Portée projet 230

245 A.4. Les pratiques de tests Métrique Définition Test Ces tests vérifient que l application peut s installer correctement et répond aux exigences de déploiement et d installation sur le matériel utilisé dans les conditions réelles. Définition Pratique Vérifie qu il existe des tests de configuration et détermine la qualité des tests en fonction de leur taux de réussite Note Note globale : GM = 2 (30 Ratio)/10 Avec Ratio qui représente le pourcentage de tests de configuration en échec par rapport aux exigences attendues. Principales valeurs des notes globales : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 20 % 1.5 % 1 30 % 0.5 % 0 % Poids aucun Nom Couverture des tests de configuration Critère Exploitabilité Portée projet Définition Détermine le taux de couverture des tests de configuration, par rapport aux exigences définies. Vérifie que les tests recouvrent toutes les exigences spécifiées. (matériel utilisé, fichiers accédés, connexions correctes) 231

246 Annexe A. Les pratiques du modèle Squash Note Note globale : O aucune mise en relation entre les tests et les exigences 1 les tests sont basés sur les exigences mais il n y a pas de vérification du taux de couverture à partir de 1 : pourcentage ces exigences couvertes par les tests. GM = 2 (Ratio 60)/25 Principales valeurs des notes globales : Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % Nom Tests d intégration système Critère Exploitabilité Portée projet Métrique Définition Test Les tests d intégration système visent à garantir le fonctionnement du logiciel dans l environnement d exploitation et l absence de répercussion sur les autres systèmes. Définition Pratique Vérifie qu il existe des tests d intégration système et détermine la qualité des tests en fonction de leur taux de réussite Note Note globale : 232 GM = 2 (30 Ratio)/10 Avec Ratio qui représente le pourcentage de tests d intégration système en échec par rapport aux exigences attendues.

247 A.4. Les pratiques de tests Principales valeurs des notes globales : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 20 % 1.5 % 1 30 % 0.5 % 0 % Poids aucun Nom Couverture des tests d intégration système Critère Exploitabilité Portée projet Définition Détermine le taux de couverture des tests d intégration système, par rapport aux exigences définies. Vérifie que les tests sont en rapport avec les exigences exprimées précisément. Note Note globale : O aucune mise en relation entre les tests et les exigences 1 les tests sont basés sur les exigences mais il n y a pas de vérification du taux de couverture à partir de 1 : pourcentage ces exigences couvertes par les tests. GM = 2 (Ratio 60)/25 233

248 Annexe A. Les pratiques du modèle Squash Principales valeurs des notes globales : Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % A.4.6 Les pratiques de tests de sécurité Nom Exigences sécurité Critère Tests sécurité Portée projet Définition Il s agit de déterminer si les exigences qui se rapportent aux tests sécurité sont précises et utilisées dans la rédaction des cas de tests Note Note globale de la pratique : 234 Nom Caractéristique oui non Poids C1 Existence d exigences de type s 2 1 s 2 0 0, 25 sécurité

249 A.4. Les pratiques de tests Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Précision de la description des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 C3 Association exigences et s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 cas de tests C4 Gestion des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C5 Gestion des liens entre s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 les exigences et les cas de tests C6 Classement des exigences en fonction de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 leur criticité C7 Gestion du cycle de vie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 des exigences if s C1 == s 2 0 then GM = 0 else 7 GM = w k.s Ck end if k=1 Nom Données sécurité Critère Tests sécurité Portée projet Définition Il s agit de déterminer si les données utilisées pour les tests sécurité sont en adéquation avec ces tests Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Vérification de la pertinence des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 C2 Précision de la description des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 C3 Validation des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 par rapport aux besoins C4 Gestion des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C5 Facilité de manipulation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 08 et injection des données if s C1 == s 9 0 then GM = 0 235

250 Annexe A. Les pratiques du modèle Squash else GM = end if 5 w k.s Ck k=1 Nom Couverture des données sécurité Critère Tests de sécurité Portée projet Définition Il s agit de déterminer si les données utilisées pour les tests sécurité couvrent tous les besoins Note Note globale de la pratique : GM = 2 (Ratio 60)/25 Principales valeurs des notes : Valeur de la pratique Valeur du ratio % 2.5 % 2 85 % 1.5 % 1 60 % 0.5 % 0 % Nom Tests d intrusion Critère Tests de sécurité Portée projet 236

251 A.4. Les pratiques de tests Métrique Définition Test Ces tests servent à vérifier que le système respecte les normes de sécurité telles que : respect de la confidentialité des données, définition claire des données confidentielles, notion de lecture seule, statut des utilisateurs, des droits d accès, politique de contrôle d accès. Définition Pratique Qualifie le taux de réussite des tests de sécurité par rapport aux exigences définies. Note Note globale : GM = 2 (30 Ratio)/10 Avec Ratio qui représente le pourcentage de tests de sécurité en échec par rapport aux exigences attendues. Principales valeurs des notes globales : Valeur de la pratique Valeur du ratio 3 0 % 2.5 % 2 20 % 1.5 % 1 30 % 0.5 % 0 % Poids aucun Nom Couverture des tests d intrusion Critère Tests de sécurité Portée projet Définition Détermine le taux de couverture des tests d intrusion, par rapport aux exigences définies 237

252 Annexe A. Les pratiques du modèle Squash Note Note globale : O aucune mise en relation entre les tests et les exigences 1 les tests sont basés sur les exigences mais il n y a pas de vérification du taux de couverture à partir de 1 : pourcentage ces exigences couvertes par les tests. GM = 2 (Ratio 60)/25 Principales valeurs des notes globales : Valeur de la pratique Ratio % 2.5 % 2 85 % 1.5 % 1 60 % A.4.7 Les pratiques d organisation des tests Nom Il s agit des pratiques qui évaluent les stratégies de tests mises en place dans l entreprise. Maturité des tests Critère Stabilité Portée projet Définition On qualifie la maturité des tests effectués en déterminant le nombre de bogues détectés après la campagne de validation qui ne l ont pas été lors de la phase de tests. C est un ratio entre les bogues révélés en post-tests et les bogues révélés lors des tests. On tiendra compte de la criticité des bogues dans le calcul lorsque ceux-ci sont classés. Cette pratique peut s adapter à toutes les phases de tests de l entreprise : elle peut par exemple, calculer la différence entre les bogues détectés avant et après les tests de développements. Pour cela, il suffit d ajuster les seuils et la formule selon le même principe. 238

253 A.4. Les pratiques de tests Note Note globale : Si la criticité des bogues n est pas prise en compte : GM = 2 (20 Ratio)/10 Avec Ratio qui représente le pourcentage de bogues détectés en phase de post-tests par rapport aux bogues détectés en phase de tests. Par exemple, un ratio de 5 % signifie que 5 % des tests ont été découverts en phase de post tests (et donc 95 % des bogues l ont été au cours des tests). Si la criticité des bogues est prise en compte : GM = 2 (90 (3 Ratio Critique+Ratio Autre ))/45 Avec Ratio Critique pour le taux de bogues critiques et Ratio Autre pour les autres bogues. Les bogues critiques ont un poids de 3 par rapport aux autres et la formule est adaptée en fonction. Principales valeurs des notes : 239

254 Annexe A. Les pratiques du modèle Squash Valeur de la pratique Ratio des bogues critiques Ratio des bogues autres 3 5 % 10 % 2.5 % 2 10 % 15 % 1.5 % 1 20 % 30 % 0.5 % 0 % Nom Plan assurance qualité Critère Organisation ALM Portée projet Définition On vérifie qu il existe un plan d assurance qualité en accord avec la méthodologie de l entreprise. Selon la norme Iso 8402 :1994, un PAQ est un document qui décrit les pratiques, les moyens et la séquence des activités liées à la qualité spécifique à un projet. Note Note globale de la pratique : Nom Caractéristique oui non Poids C1 Existence d un PAQ s 2 1 s 2 0 0, 25 Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Accord entre la méthodologie de l entreprise et s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 le PAQ C3 Qualité du PAQ (est-il s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 complet?) C4 Description des différentes phases du projet s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 C5 Description des différents acteurs s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 C6 Description des différents documents à four- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 nir C7 Validation du PAQ s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 05 if s C1 == s 2 0 then GM = 0 else 7 GM = w k.s Ck end if k=1 Nom Validation du cahier des charges 240

255 A.4. Les pratiques de tests Critère organisation ALM Portée projet Définition Vérifie l existence et la procédure de validation du cahier des charges qui décrit les spécificités fonctionnelles liées au projet. Note Note globale de la pratique : Nom Caractéristique oui non Poids C1 Existence d un cahier des s 2 1 s 2 0 0, 25 charges Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Clarté du cahier des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 charges (est-il explicite?) C3 Classement de exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 (métier, technique, etc.) C4 Précision et détail du s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 cahier des charges C5 Validation du cahier des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 charges par un procédure formelle, détaillée if s C1 == s 2 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 Nom Stratégie de validation et d homologation du logiciel Critère organisation ALM Portée projet Définition Vérifie que le projet est soumis à une stratégie de validation et d homologation clairement établie. Note Note globale de la pratique : Nom Caractéristique oui non Poids C1 Existence d une stratégie de s 2 1 s 2 0 0, 25 validation 241

256 Annexe A. Les pratiques du modèle Squash Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C2 Définition de la stratégie de validation pour s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 tout le projet C3 Qualité de la politique s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 globale de validation des tests C4 Définition des rôles des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 différents acteurs C5 Définition de la priorité s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 des tests C6 Identification de l interaction entre les tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 C7 Prise en compte dans la s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 stratégie de la particularité du projet C8 Définition de la fréquence des versions s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 04 C9 Définition des différentes phases du projet s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 04 C10 Définition de la communication entre les s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 04 acteurs au cours des phases C11 Définition des normes s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 04 de formalisation des tests if s C1 == s 2 0 then GM = 0 else 1 GM = 1w k.s Ck end if k=1 Nom Gestion des anomalies Critère Stabilité Portée projet Définition On détermine la qualité de la gestion des anomalies détectées lors des tests. Comment sont-elles gérées (ouverte et fermée)? Prend-on en compte la criticité des anomalies détectées par rapport à la criticité des exigences qu elles impactent (anomalies résiduelles donc non bloquantes ou anomalies à corriger impérativement). Note Note globale manuelle : 242

257 A.4. Les pratiques de tests Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Suivi des anomalies s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 C2 Référencement des anomalies dans un outil de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 23 bugtracker C3 Suivi des anomalies s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 dans les tests C4 Rejeu des tests permettant la fermeture des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 14 bogues C5 Classement des anomalies en fonction de leur s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 14 criticité if s C1 == s 9 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 Nom Gestion des anomalies après tests Critère Stabilité Portée projet Définition Vérifie la manière dont sont gérées les anomalies détectées après la fin de la campagne de tests. Les bugs peuvent être découverts en phase de recette, en production, etc. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Qualité des statistiques s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 sur le bogues révélés en post-tests C2 Traçabilité des bogues s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 révélés en post-tests C3 Répartition des bogues s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 en fonction des acteurs C4 Répartition des bogues s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 en fonction des phases C5 Intégration des bogues s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 dans les cas de tests C6 Rejeu des tests pour les s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 livraisons suivantes if s C1 == s 9 0 then 243

258 Annexe A. Les pratiques du modèle Squash GM = 0 else 6 GM = w k.s Ck end if k=1 Nom Gestion des versions Critère Stabilité Portée projet Définition On qualifie la gestion des différentes versions du logiciel. On doit pouvoir obtenir une traçabilité et une concordance entre les numéros de versions livrées par l équipe de développement, ceux utilisés dans le référentiel de tests et ceux utilisés dans le bugtracker. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Précision de la concordance entre les versions s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 de développement et les tests C2 Association entre les s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 bogues et les versions du logiciel C3 Association entre les s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 tests en les versions du logiciel C4 Précision de la vue des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 tests effectués à partir du num. de version C5 Précision de la vue des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 15 bogues à partir du num. de version if s C1 == s 9 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 Nom Couverture des données de tests Critère Données de tests Portée projet 244

259 A.4. Les pratiques de tests Définition Vérification des règles de construction des données pour les tests. Les données sont-elles en adéquation avec les besoins exprimés? Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Vérification des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 34 C2 Précision des règles de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 vérification C3 Couverture des besoins s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 par les données if s C1 == s 9 0 then GM = 0 else 3 GM = w k.s Ck end if k=1 Nom Définition des besoins des données Critère Données de tests Portée Projet Définition Qualifie comment sont établies et gérées les besoins de données pour les tests Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Précision de la politique s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 de gestion des données C2 Précision de l expression s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 23 des besoins C3 Détail des besoins s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C4 Qualité de l expression s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 des différents types de données (anonymes, limites, etc) C5 Validation des besoins s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 08 if s C1 == s 9 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 245

260 Annexe A. Les pratiques du modèle Squash Nom Qualité de l échantillonnage Critère Données de tests Portée projet Définition Les échantillons utilisés pour les tests correspondent aux besoins des différents tests. Elles sont représentatives des données réelles. Elles peuvent être rejouées. Elles ont un cycle de vie défini. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Choix des données en s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 fonction des besoins C2 Gestion de la totalité s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 des données C3 Qualité du contrôle effectué sur les données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 C4 Rejeu possible des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 C5 Facilité de manipulation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 des données C6 Facilité de remise à zéro s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 des données C7 Répartition des données s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 07 C8 Suivi du cycle de vie des s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 04 données if s C1 == s 9 0 then GM = 0 else 8 GM = w k.s Ck end if k=1 Nom Données anonymisées Critère Données de tests Portée projet Définition Les données doivent parfois être anonymes. Cette pratique vérifie que les contrôles sont exercés. Note Note globale manuelle : 246

261 A.4. Les pratiques de tests Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Vérification que les données doivent être ano- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 nymes C2 Identification des besoins de données ano- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 23 nymes C3 Couverture des besoins s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 23 de données anonymes C4 Echantillon représentatif des données ano- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 21 nymes if s C1 == s 9 0 then GM = 0 else 4 GM = w k.s Ck end if k=1 Nom Définition de la campagne de tests Critère Formalisation de la stratégie de tests Portée projet Définition Vérifie la qualité de la campagne de tests. On s assure qu il existe une stratégie de tests définie, la nature des tests est définie à l avance et les tests sont rédigés en fonction, la couverture de tests est précisée et respectée. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Qualité de la définition s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 de la campagne de tests C2 Précision de la stratégie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 de la campagne C3 Qualité du plan de tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 C4 Répartition des tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 entre les acteurs C5 Précision des objectifs à s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 atteindre C6 Outillage de suivi de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 tests C7 Mesure de la couverture s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 05 des tests dans l outillage if s C1 == s 9 0 then 247

262 Annexe A. Les pratiques du modèle Squash GM = 0 else 7 GM = w k.s Ck end if k=1 Nom Conformité entre la stratégie et les tests Critère Formalisation de la stratégie de tests Portée projet Définition On vérifie si la stratégie de tests est suivie. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Qualité de la procédure s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 de vérification de suivi C2 Normalisation des règles s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 27 de vérification C3 Respect de la stratégie s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 27 C4 Outillage de la vérification de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 suivi if s C1 == s 9 0 then GM = 0 else 4 GM = w k.s Ck end if k=1 Nom Validation de la campagne de tests Critère Formalisation de la stratégie de tests Portée projet Définition On vérifie que la campagne de tests est validée et on mesure la qualité de cette validation. On s assure notamment que l arrêt des tests qui doit être décidé en amont est respecté. Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Qualité de la validation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 4 de la campagne de tests C2 Automatisation de la s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 validation de la campagne C3 Outillage de la validation mis en s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 place 248

263 A.4. Les pratiques de tests if s C1 == s 9 0 then GM = 0 else 3 GM = w k.s Ck end if k=1 Nom Extraction des exigences Critère Exigences Portée projet Définition on vérifie que les exigences sont exprimées et extraites correctement du cahier des charges Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Description des exigences dans le cahier s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 36 des charges C2 Extraction des exigences à partir du s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 cahier des charges C3 Lien entre les exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 et les cas de tests C4 Prise en compte du s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 vieillissement des exigences C5 Validation des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 par un expert if s C1 == s 9 0 then GM = 0 else 5 GM = w k.s Ck end if k=1 Nom Criticité des exigences Critère Exigences Portée projet Définition on vérifie que les exigences extraites du cahier des charges sont répertoriées en fonction des leur criticité. Quelles sont les exigences qui sont incontournables, celles qui sont préconisées, souhaitées, etc. On pourra également croiser le niveau de gravité de l exigence avec le risque technique (obtenu par le croisement de la complexité du code concerné par le scénario). 249

264 Annexe A. Les pratiques du modèle Squash Note Note globale manuelle : Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Répartition des exigences en fonction de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 leur criticité C2 Validation de la répartition par un expert s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 27 C3 Prise en compte de la s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 criticité dans la campagne de tests C4 Prise en compte de la s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 criticité dans la définition de la couverture de tests if s C1 == s 9 0 then GM = 0 else 4 GM = w k.s Ck end if k=1 Nom Catégorisation des exigences Critère Exigences Portée projet Définition Les exigences doivent être réparties en fonction de différents domaines : fonctionnelle (y compris métier), sécurité, charge, ergonomie, etc. Note Note globale manuelle : 250

265 A.4. Les pratiques de tests Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Qualité du classement s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 des exigences C2 Précision des règles de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 classement C3 Suivi des règles de classement s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 C4 Validation du classement par un expert s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 C5 Répartition des tests en s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 fonction des rôles C6 Gestion des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 dans un référentiel C7 Tag des exigences en s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 08 fonction de leur catégorie if s C1 == s 9 0 then GM = 0 else 7 GM = w k.s Ck end if k=1 Nom Cycle de vie des exigences Critère Exigences Portée projet Définition Les exigences doivent s inscrire dans le cycle de vie du projet Note Note globale manuelle : 251

266 Annexe A. Les pratiques du modèle Squash Nom Caractéristique excellent bien assez moyen insuffisant Poids bien C1 Inscription des exigences dans un cycle de s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 33 vie C2 Evolution des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 avec le projet C3 Suivi des exigences s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 C4 Répartition des exigences au cours du s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 cycle de vie C5 Répercussion des modifications dans le référen- s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 13 tiel C6 Modification automatique des tests s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 09 si modification des exigences if s C1 == s 9 0 then GM = 0 else 6 GM = w k.s Ck end if k=1 A.5 Les pratiques documentaires Un Projet doit inclure des documents tels que le cahier des charges et la documentation. La qualité du projet dépend de la qualité de ces documents. Le but de ces analyses est de vérifier que les documents requis pour le projet existent et de déterminer leur qualité. Cette analyse ne peut être automatisée et requiert une expertise humaine. Etant donné que ces pratiques sont basées sur l analyse humaine les notes ne sont pas calculées aussi souvent que celles basées sur les métriques. Elles ont également une limite de durée de vie et doivent être redéterminées après un temps donné. Nom Qualité de la documentation Critère Documentation Portée projet Définition Qualifie la documentation technique du code en accord avec la méthodologie de l entreprise. Cette documentation permet aux développeurs de comprendre rapidement le code. Cette pratique qualifie aussi les commentaires insérés au sein du code source. La pertinence 252

267 A.5. Les pratiques documentaires des commentaires est évaluée par sondage, guidés par d autres pratiques comme le code spaghetti ou le niveau de commentaires. Sont généralement détectés des problèmes de code mis en commentaire, de templates automatiques non remplis, etc. Note liste des caractéristiques : Nom Caractéristique oui non Poids C1 Existence de la documentation s 2 1 s 2 0 0, 2 technique C4 Existence des normes et des s 2 1 s 2 0 0, 1 règles de mise à jour Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C2 La documentation est complète s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C3 Mise à jour de la documentation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C5 Suivi des règles s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 C6 Pertinence de la documentation s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 16 C7 Remplissage des templates s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 04 Nom Découpage en couches Critère Modularité de l architecture Portée projet Définition Vérifie la présence effective d un dossier de spécifications techniques validé et contenant une description détaillée de l architecture interne de l application ainsi qu une description détaillée des différentes couches de l application. Note liste des caractéristiques : Nom Caractéristique oui non Poids C1 Existence d un dossier de spécifications s 2 1 s 2 0 0, 25 techniques Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C2 Validation du dossier de spécifications techniques par un expert s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 C3 Description détaillée des couches s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C4 Description détaillée de l architecture interne s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 253

268 Annexe A. Les pratiques du modèle Squash Nom Organisation générale du code Critère Pertinence de l architecture Portée projet Définition Qualifie l organisation du code de manière macroscopique : cohérence entre les packages, partage des éléments communs, gestion des bibliothèques, existence de code mort. Cette pratique permet notamment de vérifier que l organisation du code ne se dégrade pas au fur et mesure du temps et des ajouts de fonctionnalités. Note liste des caractéristiques : Nom Caractéristique oui non Poids C1 Existence de code mort s 2 1 s 2 0 0, 2 Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C2 Description d une organisation type pour le code s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 C3 Respect de l organisation type par le code s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 C4 Cohérence entre les packages s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C5 Gestion des bibliothèques externes au niveau des templates s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 05 C6 Mise en commun des Template d application s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 05 Nom design-pattern Critère Pertinence de l architecture Portée projet Définition Il s agit d évaluer les mécanismes articulant la cinématique de l application : mise en œuvre des design-pattern, pertinence, qualité de leur implémentation. Note liste des caractéristiques : 254

269 A.5. Les pratiques documentaires Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C1 Pertinence des design-pattern s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 C2 Consistance des design-pattern avec le projet s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 C3 C4 Contrôle de la mise en oeuvre des design-pattern Qualité de l implémentation des design-pattern s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 Nom Dossier d architecture technique Critère Pertinence de l architecture Portée projet Définition Qualification de la présence effective d un dossier d architecture technique validé pour le projet et de sa cohérence vis à vis des contraintes fonctionnelles et techniques. Note liste des caractéristiques : Nom Caractéristique oui non Poids C1 Existence du DAT s 2 1 s 2 0 0, 2 Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C2 Cohérence entre le DAT et les contraintes fonctionnelles et techniques s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 C3 Niveau de détail du DAT s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 25 C4 Pertinence du DAT s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 C5 Validation du DAT s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 1 Nom Choix des technologies Critère Pertinence de l architecture Portée projet 255

270 Annexe A. Les pratiques du modèle Squash Définition Vérifie le choix des technologies et s assure de leur adéquation avec les besoins du projet. Cette pratique est complémentaire de la pratique de choix des mécanismes, mais sous l angle des solutions standards du marché mises en œuvre dans l application. Note liste des caractéristiques : Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C1 C2 C3 Pertinence des choix technologiques Mise en oeuvre des choix technologiques Validation des choix technologiques s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 4 s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 4 s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 Nom Correspondance entre couche et nommage Critère Respect de l architecture Portée projet Définition Vérifie que les noms des packages sont en conformité avec le découpage en couches défini dans le dossier technique. Il doit y avoir une association claire entre le découpage en packages et le découpage en couche, avec en plus des noms significatifs. Note liste des caractéristiques : Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C1 Conformité entre découpage et définition du découpage s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 4 C2 Nom des packages conformes s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 4 C3 Nom des packages significatifs s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 Nom Respect des règles de sécurité de l entreprise : dossier de conception technique Critère normes de sécurité Portée projet Définition Vérifie que le dossier de conception technique contient les règles de sécurité propres à l entreprise. Ces règles doivent être clairement définies et énoncées. 256

271 A.5. Les pratiques documentaires Note liste des caractéristiques : Nom Caractéristique oui non Poids C1 Existence de règles de sécurité s 2 1 s 2 0 0, 35 dans le dossier de conception technique Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C2 C3 Définition claire des règles de sécurité Niveau de détail des règles de sécurité s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 35 s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 Nom Respect de la partie sécurité du cahier des charges Critère normes de sécurité Portée projet Définition Vérifie que le cahier des charges fonctionnel contient des règles de sécurité précises quant au projet. Ces règles doivent être énoncées et clairement définies. Note liste des caractéristiques : Nom Caractéristique oui non Poids C1 Existence de règles de sécurité s 2 1 s 2 0 0, 35 dans le cahier des charges Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C2 C3 Définition claire des règles de sécurité Niveau de détail des règles de sécurité s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 35 s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 Nom Conformité entre implémentation et définition sécurité Critère Normes de sécurité Portée projet Définition Vérifie que les principes de sécurité énoncés dans le cahier de conception technique et le cahier des charge sont respectées dans l implémentation du projet. Note liste des caractéristiques : 257

272 Annexe A. Les pratiques du modèle Squash Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C1 C2 Respect des règles de sécurité du dossier de conception technique Respect des règles de sécurité du cahier des charges s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 5 s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 5 Nom Dossier de production Critère Exploitabilité Portée projet Définition Vérifie l existence et la pertinence du dossier de production. Note liste des caractéristiques : Nom Caractéristique oui non Poids C1 Existence du dossier de production s 2 1 s 2 0 0, 2 Nom Caractéristique excellent bien assez bien moyen insuffisant Poids C2 C3 C4 Pertinence du dossier de production Mise à jour de la procédure de déploiement Validation du dossier de production s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 3 s 9 8 s 9 7 s 9 6 s 9 4 s 9 0 0, 2 258

273 Bibliographie [Rob, 2012] (2012). Dictionnaire Le grand Robert. Robert. [Abran et al., 2004] Abran, A., Bourque, P., Dupuis, R., et Tripp, L. (2004). Guide to the software engineering body of knowledge (ironman version). Rapport technique, IEEE Computer Society. [Atkinson, 1970] Atkinson, A. B. (1970). On the measurement of inequality. Journal of Economic Theory, 2(3) : [Bache et Neil, 1995] Bache et Neil (1995). Introducing metrics into industry : a perspective on gqm. Software Quality Assurance and metrics : A Worldwide prespective, pages [Bakota et al., 2008] Bakota, T., Beszédes, A., Ferenć, R., et Gyimóthy, T. (2008). Continuous software quality supervision using sourceinventory and columbus. In Companion of the 30th international conference on Software engineering, ICSE Companion 08, pages , New York, NY, USA. ACM. [Balmas et al., 2011] Balmas, F., Bellingard, F., Denier, S., Ducasse, S., Laval, J., et Mordal-Manet, K. (2011). Technical and economical model, http :// Rapport technique, INRIA Lille Nord Europe. [Balmas et al., 2009] Balmas, F., Bergel, A., Denier, S., Ducasse, S., Laval, J., Mordal-Manet, K., Abdeen, H., et Bellinguard, F. (2009). Software metrics for java and c++ practices, http :// Rapport technique, INRIA Lille Nord Europe. [Balmas et al., 2010] Balmas, F., Bergel, A., Denier, S., Ducasse, S., Laval, J., Mordal-Manet, K., Abdeen, H., Bellinguard, F., et Franchet, B. (2010). The squale quality model, v2, http :// [Bansiya et Davis, 2002] Bansiya, J. et Davis, C. (2002). A hierarchical model for object-oriented design quality assessment. IEEE Transactions on Software Engineering, 28(1) : [Barkmann et al., 2009] Barkmann, H., Lincke, R., et Löwe, W. (2009). Quantitative evaluation of software quality metrics in open-source projects. In Advanced Information Networking and Applications (WAINA 09). International Conference on, pages IEEE. [Basili et al., 1996] Basili, V. R., Briand, L. C., et Melo, W. L. (1996). A validation of object-oriented design metrics as quality indicators. IEEE Trans. Softw. Eng., 22(10) : [Basili et al., 1994] Basili, V. R., Caldiera, G., et Rombach, H. D. (1994). The goal question metric approach. In Encyclopedia of Software Engineering. Wiley. [Bengtsson et Bosch, 1999] Bengtsson, P. et Bosch, J. (1999). Architecture level prediction of software maintenance. In European Conference on Software Maintenance and Reengineering (CSMR 99), pages

274 Bibliographie [Bergel et al., 2009] Bergel, A., Denier, S., Ducasse, S., Laval, J., Bellingard, F., Vaillergues, P., Balmas, F., et Mordal-Manet, K. (2009). Squale software quality enhancement. Presentation. [Bieman, 1996] Bieman, J. M. (1996). Metric development for object-oriented software. [Bohner et Arnold, 1996] Bohner, S. A. et Arnold, R. (1996). IEEE Computer Society Press. [Bouhier, 2008] Bouhier, L. (2008). Réunion de travail squale. Software Change Impact Analysis. [Briand et al., 1998a] Briand, L., Daly, J., Porter, V., et Wust, J. (1998a). A comprehensive empirical validation of design measures for object-oriented systems. Software Metrics Symposium, Metrics Proceedings. Fifth International, pages [Briand et al., 1998b] Briand, L. C., Daly, J. W., et Wüst, J. (1998b). A Unified Framework for Cohesion Measurement in Object-Oriented Systems. Empirical Software Engineering : An International Journal, 3(1) : [Briand et al., 1996] Briand, L. C., Morasca, S., et Basili, V. (1996). Property-based software engineering measurement. Transactions on Software Engineering, 22(1) : [Buckley et al., 2005] Buckley, J., Mens, T., Zenger, M., Rashid, A., et Kniesel, G. (2005). Towards a taxonomy of software change. Journal on Software Maintenance and Evolution : Research and Practice, pages [Chidamber et Kemerer, 1994] Chidamber, S. R. et Kemerer, C. F. (1994). A metrics suite for object oriented design. IEEE Transactions on Software Engineering, 20(6) : [Concas et al., 2007] Concas, G., Marchesi, M., Pinna, S., et Serra, N. (2007). Power-laws in a large object-oriented software system. IEEE Trans. Software Eng., 33(10) : [Cowell, 2000] Cowell, F. A. (2000). Measurement of inequality. In Atkinson, A. B. et Bourguignon, F., éditeurs, Handbook of Income Distribution, volume 1, pages Elsevier. [Cowell et Jenkins, 1995] Cowell, F. A. et Jenkins, S. P. (1995). How much inequality can we explain? a methodology and an application to the United States. Economic Journal, 105(429) : [Cowell et Kuga, 1981] Cowell, F. A. et Kuga, K. (1981). Inequality measurement : An axiomatic approach. Eur. Econ. Review, 15(3) : [Esmond B. Marvray, 2006] Esmond B. Marvray, NASA Goddard Space Flight Center, S. Q. (last update 2006). Procedure for developing and implementing software quality programs. [Fenton et Pfleeger, 1996] Fenton, N. et Pfleeger, S. L. (1996). Software Metrics : A Rigorous and Practical Approach. International Thomson Computer Press, London, UK, second edition I*, envoye a l inria lille le 19 aout. [Fenton et Neil, 1999] Fenton, N. E. et Neil, M. (1999). Software metrics : successes, failures, and new directions. Journal of Systems and Software. [Foster, 1983] Foster, J. E. (1983). An axiomatic characterization of the theil measure of income inequality. Journal of Economic Theory, 31(1) : [Gini, 1921] Gini, C. (1921). Measurement of inequality of incomes. The Economic Journal, 31 : [Goeminne et Mens, 2011] Goeminne, M. et Mens, T. (2011). Evidence for the Pareto principle in Open Source Software Activity. In Proc. Int l Workshop SQM CEUR-WS workshop proceedings. 260

275 [Grubb et Takang, 2003] Grubb, P. et Takang, A. A. (2003). Software Maintenance : Concepts and Practice. World Scientific, 2nd edition. [Gyimóthy et al., 2005] Gyimóthy, T., Ferenc, R., et Siket, I. (2005). Empirical validation of objectoriented metrics on open source software for fault prediction. IEEE Transactions on Software Engineering, 31(10) : [Hall et Fenton, 1997] Hall, T. et Fenton, N. (1997). Implementing effective software metrics programs. IEEE Software, 14 : [Herraiz, 2009] Herraiz, I. (2009). A statistical examination of the evolution and properties of libre software. In Proceedings of the 25th IEEE International Conference on Software Maintenance (ICSM), pages IEEE Computer Society. [Herrera et al., 2008] Herrera, F., Herrera-viedma, E., et Martínez, L. (2008). A fuzzy linguistic methodology to deal with unbalanced linguistic term sets. IEEE Transactions on Fuzzy Systems, pages [Herrera et Martínez, 2001] Herrera, F. et Martínez, L. (2001). A model based on linguistic 2-tuples for dealing with multigranularity hierarchical linguistic contexts in multiexpert decisionmaking. IEEE Transactions on Systems, Man and Cybernetics. Part B : Cybernetics. [Hitz et Montazeri, 1995] Hitz, M. et Montazeri, B. (1995). Measuring product attributes of objectoriented systems. In Proc. ESEC 95 (5th European Software Engineering Conference, pages Springer Verlag. [Hoover, 1936] Hoover, E. M. (1936). The measurement of industrial localization. The Review of Economic Statistics, 18(4) : [ISO/IEC, 1994] ISO/IEC (1994). Iso/iec 8402 management de la qualité et assurance de la qualité. [ISO/IEC, 2001] ISO/IEC (2001). Iso/iec software engineering -product quality- part 1 : Quality model. [ISO/IEC, 2003] ISO/IEC (2003). Iso/iec software engineering -product quality- part 3 : Internal metrics. [ISO/IEC, 2005] ISO/IEC (2005). Iso/iec :2005 software engineering -software product quality requirement and evaluation. [ISO/IEC, 2008] ISO/IEC (2008). Iso/iec 9001 management de la qualité. [J.E. et J.P., 1997] J.E., H. et J.P., C. (1997). A quantitative comparison of perfective and corrective software maintenance. Journal of Software Maintenance : Research and Practice, pages [Johnsonbaugh, 2001] Johnsonbaugh, R. (2001). Discrete mathematics. Prentice Hall. [Jones, 2008] Jones, C. (2008). Applied Software Measurement : Global Analysis of Productivity and Quality. McGraw-Hill, Inc., Hightstown, NJ, USA. [Kan, 2002] Kan, S. H. (2002). Metrics and Models in Software Quality Engineering. Addison Wesley. [Kemerer, 1987] Kemerer, C. F. (1987). An empirical validation of software cost estimation models. Communications of the ACM. [Kolm, 1976] Kolm, S.-C. (1976). Unequal inequalities I. Journal of Economic Theory, 12(3) : [Lanza et Marinescu, 2006a] Lanza, M. et Marinescu, R. (2006a). Object-Oriented Metrics in Practice. Springer-Verlag. 261

276 Bibliographie [Lanza et Marinescu, 2006b] Lanza, M. et Marinescu, R. (2006b). Object-oriented metrics in practice : using software metrics to characterize, evaluate, and improve the design of object-oriented systems. Springer. [Li et Henry, 1993] Li, W. et Henry, S. (1993). Object oriented metrics that predict maintainability. Journal of System Software, 23(2) : [Likert, 1932] Likert, R. (1932). A technique for measurement of attitudes. Archives of Psychology, 140 : [Lorenz et Kidd, 1994] Lorenz, M. et Kidd, J. (1994). Object-Oriented Software Metrics : A Practical Guide. Prentice-Hall. [Marinescu, 2004] Marinescu, R. (2004). Detection strategies : Metrics-based rules for detecting design flaws. In 20th IEEE International Conference on Software Maintenance (ICSM 04), pages , Los Alamitos CA. IEEE Computer Society Press. [Marinescu et Rațiu, 2004] Marinescu, R. et Rațiu, D. (2004). Quantifying the quality of objectoriented design : the factor-strategy model. In Proceedings 11th Working Conference on Reverse Engineering (WCRE 04), pages , Los Alamitos CA. IEEE Computer Society Press. [Martin, 1997] Martin, R. C. (1997). Stability. [Martin, 2000] Martin, R. C. (2000). Design principles and design patterns. [Martin, 2005] Martin, R. C. (2005). The tipping point : Stability and instability in oo design. http :// [Mayer, 1999] Mayer, T. (1999). Only connect. an investigation into the relationship between objectoriented design metrics and the hacking culture. [McCabe, 1976] McCabe, T. (1976). A measure of complexity. IEEE Transactions on Software Engineering, 2(4) : [McCall et al., 1976] McCall, J., Richards, P., et Walters, G. (1976). Factors in Software Quality. NTIS Springfield. [Mens et Tourwé, 2004] Mens, T. et Tourwé, T. (2004). A survey of software refactoring. IEEE Transaction on Software Engineering, 30(2) : [Mordal et al., 2012] Mordal, K., Anquetil, N., Laval, J., Serebrenik, A., Vasilescu, B., et Ducasse, S. (2012). Software quality metrics aggregation in industry. Journal of Software : Evolution and Process. [Mordal et Bouquet, 2012] Mordal, K. et Bouquet, F. (2012). Modèle iso9126 de conformité fiabilité (squash deliverable 1.1). Rapport technique, LIASD and INRIA. [Mordal-Manet et al., 2009] Mordal-Manet, K., Balmas, F., Denier, S., Ducasse, S., Wertz, H., Laval, J., Bellingard, F., et Vaillergues, P. (2009). The squale model a practice-based industrial quality model. In ICSM 09 : Proceedings of the IEEE International Conference on Software Maintenance, pages [Mordal-Manet et al., 2011] Mordal-Manet, K., Laval, J., Ducasse, S., Anquetil, N., coise Balmas, F., Bellingard, F., Bouhier, L., Vaillergues, P., et McCabe, T. (2011). An empirical model for continuous and weighted metric aggregation. In 15th Eur. Conf. Soft. Maintenance and Reeng., pages IEEE. [Moreau et Dominick, 1989] Moreau, D. R. et Dominick, W. D. (1989). Object-oriented graphical information systems : Research plan and evaluation metrics. Journal of Systems and Software, 10(1) :

277 [Munson et Elbaum, 1998] Munson, J. et Elbaum, S. (1998). Code churn : A measure for estimating the impact of code change. In ICSM 98, pages [Myers, 1979] Myers, G. J. (1979). The art of software testing. Business data processing - A Wiley- Interscience publication. Wiley, New York. [Oman et Hagemeister, 1994] Oman, P. et Hagemeister, J. (1994). Construction and testing of polynomials predicting software maintainability. Journal of Systems and Software, 24(3) : [Park, 1992] Park, R. E. (1992). Goal-driven software measurement : A guidebook (Handbook / Carnegie Mellon University. Software Engineering Institute). Carnegie Mellon University, Software Engineering Institute. [Perepletchikov et al., 2007] Perepletchikov, M., Ryan, C., Frampton, K., et Tari, Z. (2007). Coupling metrics for predicting maintainability in service-oriented designs. In Software Engineering Conference, ASWEC th Australian, pages IEEE. [Plante, 1994] Plante, J. (1994). Evaluation de programmes. Presse de l universit/ e Laval, Qu/ ebec. [Rosenberg, 1998] Rosenberg, L. H. (Software Technology Conference (Utah - April 1998)). Applying and interpreting object oriented metrics. [Serebrenik et al., 2009] Serebrenik, A., Roubtsov, S., et van den Brand, M. G. J. (2009). D n -based architecture assessment of Java open source software systems. In ICPC 09 : Proc. 17th Int. Conf. on Program Comprehension, 2009, pages IEEE. [Serebrenik et van den Brand, 2010a] Serebrenik, A. et van den Brand, M. G. J. (2010a). index for aggregation of software metrics values. In Proceedings of ICSM Theil [Serebrenik et van den Brand, 2010b] Serebrenik, A. et van den Brand, M. G. J. (2010b). Theil index for aggregation of software metrics values. In Int. Conf. on Software Maintenance, pages 1 9. IEEE. [Shorrocks, 1980] Shorrocks, A. F. (1980). The class of additively decomposable inequality measures. Econometrica, 48(3) : [Stapleton, 1997] Stapleton, J. (1997). DSDM Dynamic Systems Development Method : The Method in Practice. Addison-Wesley. [Stevens et al., 1974] Stevens, W. P., Myers, G. J., et Constantine, L. L. (1974). Structured design. IBM Systems Journal, 13(2) : [Subramanyam et Krishnan, 2003] Subramanyam, R. et Krishnan, M. (2003). Empirical analysis of ck metrics for object-oriented design complexity : implications for software defects. Software Engineering, IEEE Transactions on, 29(4) : [Tegarden et al., 1992] Tegarden, D. P., Sheetz, S. D., et Monarchi, D. E. (1992). Effectiveness of traditional software metrics for object-oriented systems. In Proc. Hawaii Int l Conf. on System Sciences. [Tempero et al., 2008] Tempero, E., Noble, J., et Melton, H. (2008). How do java programs use inheritance? an empirical study of inheritance in java software. In ECOOP 08 : Proceedings of the 22nd European conference on Object-Oriented Programming, pages , Berlin, Heidelberg. Springer-Verlag. [Theil, 1967] Theil, H. (1967). Economics and Information Theory. North-Holland. [Truck, 2002] Truck, I. (2002). Approches symbolique et floue des modificateurs linguistiques et leur lien avec l agrégation. Thèse d université. 263

278 Bibliographie [Turnu et al., 2011] Turnu, I., Concas, G., Marchesi, M., Pinna, S., et Tonelli, R. (2011). A modified Yule process to model the evolution of some object-oriented system properties. Inf. Sci., 181 : [Vasa et al., 2009a] Vasa, R., Lumpe, M., Branch, P., et Nierstrasz, O. (2009a). Comparative analysis of evolving software systems using the Gini coefficient. In Proceedings of the 25th International Conference on Software Maintenance (ICSM 2009), pages , Los Alamitos, CA, USA. IEEE Computer Society. [Vasa et al., 2009b] Vasa, R., Lumpe, M., Branch, P., et Nierstrasz, O. M. (2009b). Comparative analysis of evolving software systems using the Gini coefficient. In Int. Conf. on Software Maintenance, pages IEEE. [Vasilescu et al., 2010a] Vasilescu, B., Serebrenik, A., et van den Brand, M. G. J. (2010a). Comparative study of software metrics aggregation techniques. In Proceedings of the International Worskhop Benevol [Vasilescu et al., 2010b] Vasilescu, B., Serebrenik, A., et van den Brand, M. G. J. (2010b). Comparative study of software metrics aggregation techniques. In Ducasse, S., Duchien, L., et Seinturier, L., éditeurs, 9th Belgian-Netherlands Softw. Evolution Seminar, pages 1 5, Lille. [Vasilescu et al., 2011a] Vasilescu, B., Serebrenik, A., et van den Brand, M. G. J. (2011a). By no means : A study on aggregating software metrics. In Concas, G., Di Penta, M., Tempero, E., et Zhang, H., éditeurs, 2nd International Workshop on Emerging Trends in Software Metrics, Honolulu, Hawaii, USA. [Vasilescu et al., 2011b] Vasilescu, B., Serebrenik, A., et van den Brand, M. G. J. (2011b). You can t control the unfamiliar : A study on the relations between aggregation techniques for software metrics. In Int. Conf. on Software Maintenance. IEEE. [Wiegers, 1996] Wiegers, K. E. (1996). Software process improvement : Ten traps to avoid. Software Development, 4 : [Yager, 1988] Yager, R. R. (1988). On ordered weighted averaging aggregation operators in multicriteria decisionmaking. IEEE Trans. Syst. Man Cybern., 18(1) : [Zadeh, 1965] Zadeh, L. A. (1965). Fuzzy sets. Information Control, 8 : [Zadeh, 1975] Zadeh, L. A. (1975). The concept of a linguistic variable and its application to approximate reasoning - i. Inf. Sci., 8(3) : [Zeileis, 2009] Zeileis, A. (2009). Package ineq for R. Rapport technique, CRAN. 264

279

280