Your SlideShare is downloading. ×
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Analyse de code source: accélérer la validation des logiciels Java

1,101

Published on

Accélérez la mise en production de vos logiciels Java en réalisant des tests plus efficaces, basés sur les risques, et une validation plus rapide.

Accélérez la mise en production de vos logiciels Java en réalisant des tests plus efficaces, basés sur les risques, et une validation plus rapide.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,101
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ICESCRUM Application ICESCRUM2 Rapport d’audit 10/02/2011 Ce document est un exemple de rapport d’audit produit automatiquement à partir des résultats de l’analyse de l’application sur la plateforme Kalistick. Il n’intègre pas de commentaires spécifiques sur les résultats obtenus. Son objectif est de servir de modèle pour constituer des rapports personnalisés,il illustre la capacité de la plateforme à restituer une vision claire et compréhensible de la qualité d’une application. Ce document est confidentiel, il est la propriété de Kalistick, Il ne doit pas être diffusé ni modifié sans autorisation. Kalistick 13 av Albert Einstein F-69100 Villeurbanne +33(0) 486 68 89 42 contact@kalistick.com www.kalistick.com
  • 2. Audit de code de l’application IceScrum2 10/02/2011 1 Executive Summary Le Cockpit Qualité utilise des techniques d’analyse statique : il n’exécute pas l’application mais analyse les éléments qui la constituent (code, résultats des tests, architecture, …). Les résultats sont corrélés, agrégés et comparés avec les enjeux du projet pour identifier les risques liés à la qualité. Ce rapport présente les résultats obtenus. Synthèse - Ecart par rapport à l’objectif Ce graphique compare la situation actuelle du projet par rapport aux objectifs fixés sur chacun des axes de qualité. L’objectif, configuré à l’initialisation de l’audit, représente l’importance de chaque axe de qualité. Il est destiné à déterminer les règles à respecter dans les développements et la tolérance acceptée. Taux de non-conformité global Cette jauge indique le niveau de qualité global de l’application par rapport à son objectif qualité. Elle présente le pourcentage de l’application (code) considéré comme non-conforme. Selon la configuration réalisée, un taux supérieur à 15% indique la nécessité d’approfondir l’analyse des résultats. Origine des violations Ce graphique identifie l’origine technique des non-conformités détectées, et les principaux domaines d’amélioration. Selon les éléments soumis lors de l’analyse, certains domaines peuvent ne pas avoir été évalués.Confidentiel - Ce document est la propriété de Kalistick 2/58
  • 3. Audit de code de l’application IceScrum2 10/02/2011 Organisation du rapport Ce rapport présente les concepts du Cockpit Qualité, l’objectif fixé et les exigences techniques associées, avant de poursuivre par les résultats synthétiques puis détaillés par domaine technique. 1 Executive Summary ...................................................................................................................................... 2 2 Introduction .................................................................................................................................................. 4 2.1 Le Cockpit Qualité ................................................................................................................................. 4 2.2 La grille d’analyse ................................................................................................................................. 4 3 Objectif qualité ............................................................................................................................................. 7 3.1 Le profil qualité..................................................................................................................................... 7 3.2 Les exigences techniques ..................................................................................................................... 7 4 Synthèse des résultats ................................................................................................................................ 10 4.1 Situation du projet.............................................................................................................................. 10 4.2 Benchmarking ..................................................................................................................................... 13 5 Résultats détaillés....................................................................................................................................... 17 5.1 Détail par axes de qualité ................................................................................................................... 17 5.2 Implémentation .................................................................................................................................. 18 5.3 Structure ............................................................................................................................................. 22 5.4 Test ..................................................................................................................................................... 30 5.5 Architecture ........................................................................................................................................ 37 5.6 Duplication ......................................................................................................................................... 38 5.7 Documentation................................................................................................................................... 40 6 Plan d’action ............................................................................................................................................... 42 7 Glossaire ..................................................................................................................................................... 44 8 Annexes ...................................................................................................................................................... 46 8.1 La complexité cyclomatique ............................................................................................................... 46 8.2 Le couplage ......................................................................................................................................... 49 8.3 Le TRI et TEI ........................................................................................................................................ 50 8.4 Exigences techniques ......................................................................................................................... 52Confidentiel - Ce document est la propriété de Kalistick 3/58
  • 4. Audit de code de l’application IceScrum2 10/02/2011 2 Introduction 2.1 Le Cockpit Qualité Cet audit est basé sur un processus d’analyse de code industrialisé. Cette industrialisation permet de garantir des résultats fiables et facilement comparables avec les résultats d’autres audits. Le processus d’analyse repose sur la plateforme « Cockpit Qualité », disponible en mode SaaS1 (https://cockpit.kalistick.com). Cette plateforme présente l’avantage d’offrir une base de connaissances unique du fait qu’elle centralise les résultats statistiques issus de l’analyse de millions de lignes de code, base enrichie en continu avec les nouvelles analyses. Elle permet notamment de réaliser des analyses comparatives avec d’autres projets similaires. 2.2 La grille d’analyse L’analyse porte sur le code Java (JEE) ou C# (.Net) de l’application (code source et code binaire). C’est une analyse statique (sans exécution), complétée par la corrélation avec des informations extraites des outils de développement déjà mis en œuvre pour le projet : gestionnaires de versions, frameworks de tests unitaires, outils de couverture de code. Les résultats sont proposés dans une grille d’analyse qui s’articule autour de 3 dimensions principales :  Les axes de qualité, qui déterminent la nature de l’impact des non-conformités détectées, donc la conséquence sur le niveau de qualité de l’application  Les domaines de qualité, qui précisent l’origine technique des non-conformités  Les niveaux de sévérité, qui positionnent les non-conformités sur une échelle de gravité afin de caractériser leur priorité 1 Software as a Service : application accessible à distance via Internet (à l’aide d’un navigateur standard)Confidentiel - Ce document est la propriété de Kalistick 4/58
  • 5. Audit de code de l’application IceScrum2 10/02/2011 2.2.1 Les axes de qualité Les axes de qualité standardisent un ensemble de qualités auxquelles doit prétendre l’application selon la norme ISO 912623 :  Maintenabilité. Capacité d’un logiciel à pouvoir être dépanné facilement, en fonction de l’effort exigé pour localiser, identifier et corriger les erreurs.  Fiabilité. Aptitude d’un logiciel à fonctionner correctement en rendant le service attendu dans les conditions normales de fonctionnement.  Evolutivité. Aptitude d’un logiciel à pouvoir évoluer, en fonction de l’effort requis pour ajouter, supprimer, modifier des fonctions d’un logiciel déjà opérationnel.  Sécurité. Aptitude du logiciel à fonctionner en respectant les contraintes d’intégrité, de confidentialité et de traçabilité requises.  Transférabilité. Capacité à faire réaliser la maintenance et les évolutions d’un logiciel par une nouvelle équipe distincte de celle ayant développé le logiciel initial.  Efficacité. Relation entre le niveau de performance du logiciel et la quantité de ressources nécessaires pour le faire fonctionner dans des conditions nominales. 2.2.2 Les domaines de qualité Les domaines de qualité déterminent la nature des problèmes selon leur origine technique. Ils sont au nombre de six :  Implémentation. Les problèmes inhérents au codage : mauvaise utilisation du langage, bugs potentiels, code difficilement compréhensible, … Ces problèmes peuvent nuire à un ou plusieurs des six axes de qualités.  Structure. Les problèmes liés à l’organisation du code : méthodes trop longues, trop complexes, avec trop de dépendances, … Ces problèmes impactent généralement la maintenabilité et l’évolutivité de l’application. 2 ISO/IEC 9126-1:2001 Software engineering — Product quality — Part 1: Quality model : http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749 3 L’analyse porte sur un sous-ensemble de la norme ISO 9126 afin de se focaliser sur les dimensions contrôlables de manière automatisée.Confidentiel - Ce document est la propriété de Kalistick 5/58
  • 6. Audit de code de l’application IceScrum2 10/02/2011  Test. Qualifie la manière dont est testée l’application, à partir des résultats des tests unitaires (taux d’échec, durée d’exécution, …), mais également en fonction de la nature du code couvert par l’exécution des tests. L’objectif consiste à s’assurer que les tests couvrent les parties critiques de l’application.  Architecture. Problèmes liés à l’architecture logicielle de l’application. Il est possible de définir un modèle d’architecture pour modulariser l’application en couches ou composants puis de définir des contraintes d’appel entre ces éléments. L’analyse identifie au sein du code tous les appels ne respectant pas ces contraintes, pour détecter les risques au niveau de la maintenabilité, de l’évolutivité et de la sécurité.  Documentation. Problèmes liés au manque de documentation dans le code. Ce domaine impacte essentiellement la transférabilité du code.  Duplication. Identification de tous les copier-collers importants au sein de l’application. Ceux-ci présentent des risques sur les axes fiabilité, maintenabilité, transférabilité et évolutivité. 2.2.3 Les niveaux de sévérité Les niveaux de sévérité sont destinés à caractériser la priorité de correction d’une non-conformité. Cette priorité dépend de la gravité de l’impact d’une non-conformité, mais également de l’effort à fournir pour la correction : certains problèmes moyennement critiques seront marqués avec un niveau de sévérité important en raison de la trivialité de leur résolution. Pour simplifier leur interprétation, les niveaux de sévérité sont exprimés à l’aide d’une échelle à quatre niveaux. Le premier correspond à une erreur, les trois suivants à des avertissements, du plus grave au moins grave :  Interdit  Fortement déconseillé  Déconseillé  A éviter Par rapport au niveau Interdit, les autres niveaux de sévérité sont gérés à l’aide d’un seuil de tolérance, qui augmente inversement avec la gravité.Confidentiel - Ce document est la propriété de Kalistick 6/58
  • 7. Audit de code de l’application IceScrum2 10/02/2011 3 Objectif qualité Une des particularités du « Cockpit Qualité » consiste à réaliser une analyse en fonction des besoins réels du projet en terme de qualité, afin d’éviter des efforts inutiles de « sur-qualité » et de garantir une meilleure pertinence sur les risques qualité. Ces besoins sont formalisés via la définition d’un « profil qualité » de l’application, qui caractérise les niveaux de qualité attendus sur chacun des six axes de qualités. Ce profil qualité est ensuite traduit en « exigences techniques », qui sont des règles techniques que devront respecter les développeurs. 3.1 Le profil qualité Pour cet audit, le profil qualité établi est le suivant : Voir sur le Cockpit Qualité 3.2 Les exigences techniques En se basant sur le profil qualité précédent, les exigences techniques ont été sélectionnées à partir de la base de connaissances du « Cockpit Qualité ». Ces exigences techniques couvrent les six domaines de qualités (implémentation, structure, test, architecture, documentation, duplication) et sont configurées en fonction du profil qualité (seuils, niveaux de sévérité, …). L’objectif est d’assurer un calibrage des exigences qui assure le meilleur retour sur investissement.Confidentiel - Ce document est la propriété de Kalistick 7/58
  • 8. Audit de code de l’application IceScrum2 10/02/2011 Voici le détail de ces exigences techniques : Domaine Règle Explication, objectif et seuils éventuels - Selon votre profil, entre 150 et 200 règles ont été sélectionnées. Elles sont Implémentation présentées exhaustivement en annexe du rapport (8.4.1 Règles d’implémentation). Objectif : éviter les mauvaises pratiques et appliquer les bonnes pratiques liées aux technologies utilisées. Taille des méthodes Nombre de ligne dinstructions. Cette mesure est différente du nombre de ligne de code : elle ninclut pas les lignes de commentaire ni les lignes blanches mais seulement les lignes comportant au moins une instruction. Objectif : éviter les blocs de traitements difficilement compréhensibles. Le seuil retenu pour le projet est :  nombre de lignes : 100 Complexité des Complexité cyclomatique dune méthode. Elle mesure la complexité méthodes algorithmique dune méthode en comptant le nombre de chemins indépendants couvrant tous les cas possibles. Plus ce nombre est élevé, plus le code est difficile à maintenir et à tester. Structure Objectif : éviter les blocs de traitements difficilement compréhensibles, non testables et qui tendent à avoir un taux de dysfonctionnement important. Le seuil retenu pour le projet est :  complexité cyclomatique : 20 Complexité et couplage Identifie les méthodes difficiles à comprendre, à tester et à maintenir en des méthodes raison dune complexité moyenne (complexité cyclomatique) et à de nombreuses références à des types tiers (couplage efférent) Objectif : éviter les blocs de traitements difficilement compréhensibles et non testables. Les seuils retenus pour le projet sont :  complexité cyclomatique : 15  couplage efférent : 20Confidentiel - Ce document est la propriété de Kalistick 8/58
  • 9. Audit de code de l’application IceScrum2 10/02/2011 Domaine Règle Explication, objectif et seuils éventuels Couverture de test des Taux de couverture de code dune méthode. Cette métrique est méthodes standardisée par notre plateforme à partir des mesures brutes de couverture de code quand elles sont fournies au sein de larchive du projet. Cette exigence associe un seuil minimal de test (couverture de code) à chaque méthode de lapplication selon le TRI (TestRelevancyIndex) ; le TRI évalue pour chaque méthode le risque quelle contienne des bugs. Son calcul tient compte des risques métiers définis pour lapplication. Test Objectif : orienter sa stratégie et les efforts de test sur les points sensibles de l’application et la vérifier. Ces points sensibles sont évalués selon leur propension à contenir des bugs et les risques métiers/fonctionnels de l’application. Le détail des seuils est fourni en annexe du rapport (8.4.2 Seuils de couverture de code). Règles définies Voir le modèle d’architecture éventuellement défini pour découvrir les spécifiquement pour le contraintes d’architecture en cours. Architecture modèle d’architecture de l’application. Objectif : s’assurer que les développements respectent le modèle d’architecture prévu et n’introduisent pas des incohérences synonymes de failles de sécurité, de difficultés de maintenance ou d’évolution. NB : les violations d’architecture ne sont pas prises en compte dans le calcul de la non-conformité. Entête de Identifie les méthodes de complexité moyenne qui ne disposent pas documentation des dentête de documentation. Les méthodes prises en compte sont celles Documentation méthodes dont la complexité cyclomatique et le nombre dinstructions excèdent des seuils définis spécifiquement pour le projet. Objectif : s’assurer que la documentation est présente sur les blocs de traitements clés en vue de faciliter les éventuels changements d’équipe (transférabilité). Les seuils retenus pour le projet sont :  complexité cyclomatique : 10  nombre de lignes : 50 Détection des Les duplications sont invalidées au-delà de 20 instructions Duplication duplications Objectif : détecter l’implémentation de traitements identiques à plusieurs endroits différents dans l’application, très souvent source d’incohérences lorsque l’on effectue des modifications, et facteur d’augmentation des coûts de tests et d’évolution.Confidentiel - Ce document est la propriété de Kalistick 9/58
  • 10. Audit de code de l’application IceScrum2 10/02/2011 4 Synthèse des résultats Ce chapitre synthétise la situation du projet à l’aide d’indicateurs globaux. Ceux-ci mesurent la qualité intrinsèque du projet, mais comparent également sa situation à celle des autres projets de la base de référence du « Cockpit Qualité ». 4.1 Situation du projet Les indicateurs suivants concernent la situation intrinsèque du projet. 4.1.1 Taux de non-conformité global Le taux de non-conformité mesure la proportion du code de l’application considéré comme non-conforme. Voir sur le Cockpit Qualité Plus précisément, ce chiffre résulte du rapport entre le nombre total d’instructions, et le nombre d’instructions des classes non-conformes. Une classe est considérée comme non conforme si au moins un des cas suivants est rencontré : - Une non-conformité de sévérité interdite est détectée dans la classe - Un ensemble de non-conformités fortement déconseillées, déconseillées, ou à éviter sont détectées dans la classe et dépassent un certain seuil. Ce calcul dépend de la sévérité de chaque non-conformité ainsi que du profil qualité qui ajuste le seuil de tolérance.Confidentiel - Ce document est la propriété de Kalistick 10/58
  • 11. Audit de code de l’application IceScrum2 10/02/2011 4.1.2 Ecart par rapport à l’objectif Ce graphique résume l’écart entre l’objectif visé tel que représenté par le profil qualité et la situation actuelle du projet. Cet écart est présenté pour chacun des axes de qualité : Voir sur le Cockpit Qualité Le niveau de non-conformité est calculé pour chaque axe de qualité, puis pondéré en fonction du niveau d’exigence fixé pour l’axe concerné. Axe de qualité Classes Violations impactantes % application Efficacité 7 8 5% Evolutivité 27 107 29% Fiabilité 40 136 37% Maintenabilité 40 216 41% Sécurité 0 0 0% Transférabilité 32 131 38% [Total] 53 264 50% Les résultats détaillés précisent pour chaque axe de qualité : le nombre de classes non- conformes, le nombre de violations des règles sélectionnées, et le pourcentage de l’application présent dans les classes concernées.Confidentiel - Ce document est la propriété de Kalistick 11/58
  • 12. Audit de code de l’application IceScrum2 10/02/2011 4.1.3 Origine des non-conformités Le graphique suivant montre la répartition des non-conformités selon leur origine technique : Voir sur le Cockpit Qualité Ce graphique compare chaque domaine selon l’impact des règles qui lui sont associées sur la qualité de l’application. L’impact est mesuré à partir du nombre d’instructions des classes non- conformes. 4.1.4 Volumétrie Le tableau suivant précise la volumétrie de l’application analysée : Métrique Valeur Tendance Nombre de lignes 47671 +14,93% Nombre dinstructions 24034 +18,36% Nombre de méthodes 4384 +13,75% Nombre de classes 230 +10,58% Nombre de packages 43 +4,88% Voir sur le Cockpit Qualité Une « ligne » correspond à une ligne physique dun fichier de code. Elle peut concerner une ligne blanche, ou une ligne de commentaire. Une « instruction » représente une unité de code primaire, elle peut s’écrire sur plusieurs lignes, mais une ligne peut également contenir plusieurs instructions. Pour simplifier, une instruction est délimitée par un point-virgule (;) ou par une accolade gauche ({).Confidentiel - Ce document est la propriété de Kalistick 12/58
  • 13. Audit de code de l’application IceScrum2 10/02/2011 4.2 Benchmarking La base de connaissance du « Cockpit Qualité » permet de réaliser une analyse comparative du projet avec les autres projets analysés sur la plateforme. L’objectif est de mesurer son niveau de qualité par rapport à une moyenne générale. Cette comparaison « benchmarking » est proposée par rapport à deux catégories de projets :  Les projets « intra-Cockpit » : les projets analysés en continu sur la plateforme, donc, à priori, avec un niveau de qualité supérieur à la moyenne  Les projets « extra-Cockpit » : les projets analysés ponctuellement sur la plateforme, en mode audit, donc avec un niveau de qualité très hétérogène. NB : chaque projet disposant d’un profil qualité qui lui est spécifique, on ne compare pas l’écart en fonction de l’objectif, mais à l’aide de caractéristiques brutes, afin de donner des points de repère. 4.2.1 Comparaison sur les problèmes d’implémentation Le graphique suivant présente la situation du projet dans le domaine implémentation par rapport aux projets « extra-Cockpit », donc analysés ponctuellement sur la plateforme. Pour chaque niveau de sévérité, le niveau de qualité du projet est positionné par rapport aux autres : Voir sur le Cockpit QualitéConfidentiel - Ce document est la propriété de Kalistick 13/58
  • 14. Audit de code de l’application IceScrum2 10/02/2011 Le projet est positionné par rapport aux autres projets selon son taux de violations pour chaque règle. La répartition est basée sur la méthode des quartiles, trois groupes sont distingués, « Meilleur » : les 25% de projets les meilleurs, « Dans la moyenne » : les 50% de projets médians, « Moins bon » : les 25% de projets les moins bons. Cette information est synthétisée ensuite par niveau de sévérité. Plus le rouge domine plus le problème est important. Les règles d’implémentation comparées ne sont pas forcément les mêmes selon les profils de qualité, mais on compare ici les règles selon leur niveau de sévérité défini pour chaque projet. Le graphique suivant propose la même analyse, mais cette fois avec les projets « intra-Cockpit », analysés en continu sur la plateforme, donc avec un niveau de qualité normalement supérieur à la moyenne car dans un processus d’amélioration où les violations détectées sont corrigées : Voir sur le Cockpit Qualité Une couleur rouge dominante indique que les autres projets tendent à corriger les violations détectées sur ce projet.Confidentiel - Ce document est la propriété de Kalistick 14/58
  • 15. Audit de code de l’application IceScrum2 10/02/2011 4.2.2 Cartographie de la structure Le graphique suivant compare la cartographie de la taille des méthodes du projet avec celle des autres projets, « intra-Cockpit » et « extra-Cockpit », en comparant la proportion de l’application (en pourcentage d’instructions) qui est située dans des blocs de traitement (méthodes) avec un nombre d’instructions élevé : Voir sur le Cockpit Qualité Une proportion importante de l’application dans la zone droite est un indicateur de coûts de maintenance et d’évolution plus importants. NB : l’application analysée est indiquée sous le terme « Release ».Confidentiel - Ce document est la propriété de Kalistick 15/58
  • 16. Audit de code de l’application IceScrum2 10/02/2011 Une cartographie similaire est proposée à partir de la complexité cyclomatique4 des méthodes, en comparant la proportion de l’application (en pourcentage d’instructions) qui est située dans des blocs de traitement (méthodes) complexes : Voir sur le Cockpit Qualité Une proportion importante de l’application dans la zone droite indique non-seulement des coûts de maintenance et d’évolution plus importants, mais également des problèmes de fiabilité car ce code est difficile à tester. 4.2.3 Comparaison des principales métriques Le tableau suivant compare le projet avec les autres projets, « intra-Cockpit » et « extra-Cockpit », sur les principales métriques liées à la structure du code. Les intervalles de valeurs recommandées sont fournis à titre d’information. Métrique Project Extra-Cockpit Intra-Cockpit Intervalle recommandé Classes par package 5,35 7,57 50,68 6 - 26 Méthodes par classe 19,06 10,71 8,74 4 - 10 Lignes de code par méthode 5,48 8,05 7,26 7 - 13 Complexité par ligne de code 0,34 0,3 0,29 0.16 - 0.24 Voir sur le Cockpit Qualité 4 La complexité cyclomatique mesure la complexité algorithmique du code, et donc sa facilité à le tester, cf. http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20(Complexity%20Measure).pdfConfidentiel - Ce document est la propriété de Kalistick 16/58
  • 17. Audit de code de l’application IceScrum2 10/02/2011 5 Résultats détaillés Ce chapitre détaille les résultats en ciblant plus précisément les règles et les éléments de code non- conformes. Une analyse domaine par domaine est proposée. 5.1 Détail par axes de qualité L’histogramme suivant complète l’analyse synthétique en détaillant le taux de non-conformité ainsi que le nombre de classes non-conformes pour chaque axe de qualité. Pour rappel, le taux de non-conformité est basé sur le volume d’instructions des classes non-conformes par rapport au volume d’instructions global du projet. Ces taux de non-conformité dépendent directement du profil qualité du et du niveau des exigences qui ont été sélectionnées : Voir sur le Cockpit Qualité Une même classe pouvant être non-conforme sur plusieurs axes, le total ne correspond pas nécessairement à la somme des axes.Confidentiel - Ce document est la propriété de Kalistick 17/58
  • 18. Audit de code de l’application IceScrum2 10/02/2011 5.2 Implémentation Le domaine Implémentation couvre les règles se rapportant aux techniques de codage. Contrairement aux autres domaines, ces règles sont souvent spécifiques aux caractéristiques du langage (Java / C#). Elles identifient par exemple :  des bugs potentiels : variables non initialisées, problèmes d’accès concurrents, appels récursifs, …  des optimisations en terme mémoire ou CPU  des failles de sécurité  des utilisations de code obsolètes  des écritures s’écartant des standards recommandés  … Les règles d’implémentations sont les plus nombreuses au sein des exigences techniques. Elles sont ici nommées « pratiques ». 5.2.1 Répartition par sévérité L’objectif de cet indicateur est d’identifier la sévérité des pratiques qui ont provoqué l’invalidation des classes. On restreint ici les niveaux de sévérité à deux niveaux : les pratiques interdites (niveau de sévérité Interdit) et les pratiques déconseillées (niveaux de sévérité Fortement déconseillé, Déconseillé et A éviter). Le graphique suivant compare le nombre de classes invalidées en implémentation, selon les pratiques qui ont participé à cette invalidation :  Si une classe ne viole que des pratiques interdites, elle est dans le groupe « Pratiques interdites »  Si une classe ne viole que des pratiques déconseillées, elle est dans le groupe « Pratiques déconseillées »  Sinon, elle viole des pratiques des deux catégories et se trouve dans le groupe « Pratiques déconseillées et interdites » Voir sur le Cockpit QualitéConfidentiel - Ce document est la propriété de Kalistick 18/58
  • 19. Audit de code de l’application IceScrum2 10/02/2011 L’effort de correction lié aux pratiques interdites est généralement moins important par rapport aux sévérités inférieures : une seule violation interdite suffit à générer une non- conformité alors qu’il en faut plusieurs non interdites pour générer une non-conformité, en fonction des seuils de tolérance. Le tableau suivant détaille le graphique en introduisant la notion de « violation impactante ». Une violation impactante est une violation dont la correction permet de corriger totalement ou partiellement la non- conformité d’une classe. En effet, en raison des seuils de tolérance associés aux niveaux de sévérité, la correction de certaines violations n’a aucune influence sur la non-conformité globale de la classe. Sévérité Violations Nouvelles Violations Autres impactantes violations corrigées violations Interdit 14 3 2 0 Fortement déconseillé 71 29 7 70 Déconseillé 44 48 4 29 A éviter 35 26 10 107 Les colonnes « Nouvelles violations » et « Violations corrigées » ne sont pertinentes que dans le cas où l’audit fait suite à un audit précédent. 5.2.2 Pratiques à corriger en priorité Les deux tableaux suivants fournissent la liste des pratiques interdites et fortement déconseillées détectées dans l’application. Ce sont généralement les règles à corriger en priorité. Ces tableaux proposent pour chaque pratique le nombre de nouvelles violations (si un audit précédent a été réalisé), le nombre de violations au total pour cette pratique, le nombre de classes non-conformes où cette pratique a été détectée et le pourcentage d’instructions de ces classes par rapport au volume d’instruction global du projet. Ces chiffres permettent d’établir un plan d’action en fonction de l’impact associé à chaque pratique.Confidentiel - Ce document est la propriété de Kalistick 19/58
  • 20. Audit de code de l’application IceScrum2 10/02/2011 5.2.2.1 Pratiques interdites Pratique Nouvelles Violations Classes % NC application DontUseNewToInstantiateIntegers 0 6 5 2% AlwaysDeclareCloneableInterfaceWhenImplementingClo 3 3 3 2% neMethod AlwaysSynchronizeDateFormatter 0 1 1 1% DontUseNewToInstantiateStrings 0 1 1 3% MisplacedNullCheck 0 1 1 1% NPEAlwaysThrown 0 1 1 1% UseAppendMethodForStringBuffer 0 1 1 1% Voir sur le Cockpit Qualité 5.2.2.2 Pratiques fortement déconseillées Pratique Nouvelles Violations Classes % NC application TraceErrorsWithLogger 20 80 28 34% NeverMakeCtorCallInnerMethod 3 27 18 26% UseLoggerRatherThanPrintMethods 4 27 7 9% DontAssignVariablesInOperands 2 5 2 3% DontIgnoreMethodsReturnValue 0 1 1 2% OverrideEqualsWhenImplementingCompareTo 0 1 0 1% Voir sur le Cockpit Qualité 5.2.3 Classes à corriger en priorité sur les problèmes d’implémentation Les deux tableaux suivants fournissent une vision complémentaire concernant l’impact des problèmes d’implémentation en détaillant la liste des principales classes concernées par des pratiques interdites ou fortement déconseillées. Pour chaque classe sont associés le nombre de violations existantes (pratiques interdites ou fortement déconseillées), le nombre de nouvelles violations (si un audit précédent a été réalisé), et l’état de conformité de la classe.Confidentiel - Ce document est la propriété de Kalistick 20/58
  • 21. Audit de code de l’application IceScrum2 10/02/2011 5.2.3.1 Classes avec des pratiques interdites Classe NC Nouvelles Violations Instructions icescrum2.dao.model.impl.Sprint Oui 1 2 218 icescrum2.service.chart.PointBurnupChartProduct Oui 0 2 121 icescrum2.dao.model.impl.RemainingEstimationArray Oui 0 2 74 icescrum2.presentation.app.chat.PrivateChat Oui 0 1 184 icescrum2.service.impl.HibernateManagerImpl Oui 0 1 76 icescrum2.dao.impl.ProductDao Oui 0 1 69 icescrum2.dao.impl.UserDao Oui 0 1 76 icescrum2.service.impl.UserServiceImpl Oui 0 1 75 icescrum2.service.impl.ExportXMLServiceImpl Oui 0 1 628 icescrum2.dao.model.ISprint Oui 1 1 56 icescrum2.presentation.model.SprintImpl Oui 1 1 208 Voir sur le Cockpit QualitéConfidentiel - Ce document est la propriété de Kalistick 21/58
  • 22. Audit de code de l’application IceScrum2 10/02/2011 5.2.3.2 Classes avec des pratiques fortement déconseillées Classe NC Nouvelles Violations Instructions icescrum2.service.impl.RepositoryServiceImpl Oui 0 13 51 icescrum2.service.impl.ExportPDFServiceImpl Oui 1 9 455 icescrum2.service.impl.HibernateManagerImpl Oui 0 5 76 icescrum2.service.chart.BurndownChartProduct Oui 0 4 172 icescrum2.service.chart.GlobalChartTest Oui 0 4 122 icescrum2.listeners.IS2ServletListener Oui 0 4 20 icescrum2.service.impl.ImportXMLServiceImpl Oui 0 4 482 icescrum2.presentation.broadcast.RenderableSession Oui 0 4 110 icescrum2.service.impl.ConfigurationServiceImpl Oui 1 4 103 icescrum2.service.impl.ExportXMLServiceImpl Oui 0 4 628 icescrum2.service.impl.UserServiceImpl Oui 0 4 75 icescrum2.presentation.app.productbacklog.ProductBacklogUI Oui 2 3 817 icescrum2.service.chart.BurnupChartProduct Oui 0 3 184 icescrum2.service.chart.PointBurnupChartProduct Oui 0 3 121 icescrum2.service.impl.ExportPDFSprint Oui 3 3 97 icescrum2.presentation.app.login.LoginUI Oui 1 2 152 icescrum2.presentation.app.product.ProductUI Oui 0 2 375 icescrum2.presentation.app.roadmap.RoadmapUI Oui 2 2 687 icescrum2.presentation.app.task.TasksUI Oui 1 2 776 Voir sur le Cockpit Qualité 5.3 Structure Le domaine Structure cible les règles se rapportant à la structuration du code, par exemple :  La taille des méthodes  La complexité cyclomatique des méthodes  Le couplage, ou la dépendance des méthodes par rapport aux classes extérieures L’objectif est de s’assurer que le code est structuré de telle manière qui puisse être facilement maintenu, testable, et qu’il puisse évoluer. Ces règles sont des « métriques ». Elles mesurent des valeurs (p. ex. : un nombre d’instructions) et sont conditionnées par des seuils (p. ex. : 100 instructions / méthode). Seules les métriques qui offrent un levier d’action facile à comprendre et à mettre en œuvre sont proposées ici. Elles s’appliquent toutes à des méthodes.Confidentiel - Ce document est la propriété de Kalistick 22/58
  • 23. Audit de code de l’application IceScrum2 10/02/2011 5.3.1 Typologie des problèmes de structure Cet histogramme montre pour chaque règle de structure le nombre de non-conformités (donc de méthodes) ainsi que le pourcentage du volume d’instructions concernées par rapport au volume global de l’application : Voir sur le Cockpit Qualité Le pourcentage d’instructions représenté est intéressant dans la mesure où on constate souvent qu’un petit nombre de méthodes concentrent une grosse partie du code de l’application. Si des règles ont été configurées pour ne pas être prises en compte dans l’audit, elles sont affichées dans ce graphe mais sans aucun résultat. Une méthode peut-être concernée par plusieurs règles, en conséquence le total ne correspond pas à la somme des chiffres. Le tableau suivant complète cette vision en introduisant le nombre de nouvelles violations et le nombre de violations corrigées dans le cas où un audit précédent aurait été réalisé :Confidentiel - Ce document est la propriété de Kalistick 23/58
  • 24. Audit de code de l’application IceScrum2 10/02/2011 Anomalie Violation Nouvelles Violations NC s violations corrigées impactant es Nombre dinstructions supérieur à 100 2 1 0 1% Complexité cyclomatique supérieure à 20 14 4 0 3% Voir sur le Cockpit Qualité 5.3.2 Cartographie des méthodes par taille L’histogramme suivant présente une cartographie des méthodes de l’application selon leur taille. La taille est exprimée en nombre d’instructions pour faire abstraction du format d’écriture (conventions de styles appliquées sur le projet). Le dernier intervalle identifie les méthodes dont le nombre d’instructions dépasse le seuil fixé. Ces méthodes sont considérées comme non-conformes car elles sont généralement difficiles à maintenir et à faire évoluer, et montrent également une forte propension à faire apparaître des bugs, car elles sont difficilement testables. Le pourcentage d’instructions est fourni car les méthodes les plus grosses concentrent généralement une part importante de l’application : Voir sur le Cockpit Qualité Le tableau suivant détaille les principales méthodes non-conformes, identifiées dans le dernier intervalle du graphique précédent :Confidentiel - Ce document est la propriété de Kalistick 24/58
  • 25. Audit de code de l’application IceScrum2 10/02/2011 Méthode Instructions Lignes Complexité Nouvelle violation icescrum2.service.impl.ExportPDFServiceImpl.addReleasePlan ( 131 227 38 Nouvelle icescrum2.dao.model.IUser, int[], int[], icescrum2.dao.model.IProduct) icescrum2.service.impl.ClicheServiceImpl.createCliche ( 208 343 42 icescrum2.dao.model.IProduct, java.util.Date) 5.3.3 Cartographie des méthodes par complexité L’histogramme suivant présente une cartographie des méthodes de l’application selon leur complexité cyclomatique (cf 8.1 La complexité cyclomatique). La complexité cyclomatique est une mesure qui permet de caractériser la complexité d’un bloc de code, en s’intéressant aux différents chemins d’exécution possibles. Ce concept a été standardisé par Mc Cabe5 mais plusieurs modes de calcul existent. Celui retenu ici est l’un des plus répandus et l’un des plus simples : il consiste à compter le nombre d’opérateur d’embranchements (if, for, while, ?, …) et de conditions ( ??, &&, …). Le dernier intervalle identifie les méthodes dont la complexité dépasse le seuil fixé. Ces méthodes sont considérées comme non-conformes pour les mêmes raisons que pour les méthodes trop longues : elles sont généralement difficiles à maintenir et à faire évoluer, et montrent également une forte propension à faire apparaître des bugs. 5 1976, IEEE Transactions on Software Engineering: 308–320. http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20(Complexity%20Measure).pdf.Confidentiel - Ce document est la propriété de Kalistick 25/58
  • 26. Audit de code de l’application IceScrum2 10/02/2011 Le pourcentage d’instructions ainsi que le pourcentage de complexité sont fournis car les méthodes les plus complexes concentrent généralement une part importante de l’application. Voir sur le Cockpit Qualité Le tableau suivant détaille les principales méthodes non-conformes, identifiées dans le dernier intervalle du graphique précédent :Confidentiel - Ce document est la propriété de Kalistick 26/58
  • 27. Audit de code de l’application IceScrum2 10/02/2011 Méthode Instructions Lignes Complexité Nouvelle violation icescrum2.service.impl.ExportPDFServiceImpl.addReleasePl 131 227 38 Nouvelle an ( icescrum2.dao.model.IUser, int[], int[], icescrum2.dao.model.IProduct) icescrum2.service.impl.ReleaseServiceImpl.saveRelease ( 59 84 30 Nouvelle icescrum2.dao.model.IRelease, icescrum2.dao.model.IProduct, boolean, icescrum2.dao.model.IUser) icescrum2.service.impl.SprintServiceImpl.closeSprint ( 70 120 21 Nouvelle icescrum2.dao.model.IRelease, icescrum2.dao.model.ISprint, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct) icescrum2.service.impl.SprintServiceImpl.saveSprint ( 43 69 20 Nouvelle icescrum2.dao.model.ISprint, icescrum2.dao.model.IRelease, java.lang.Integer, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct) icescrum2.dao.model.impl.Sprint.equals ( java.lang.Object) 47 70 84 icescrum2.service.impl.ClicheServiceImpl.createCliche ( 208 343 42 icescrum2.dao.model.IProduct, java.util.Date) icescrum2.service.impl.ImportXMLServiceImpl.parseProduct ( 73 169 41 org.w3c.dom.Element) icescrum2.dao.model.impl.ProductBacklogItem.equals ( 45 40 37 java.lang.Object) icescrum2.dao.model.impl.Build.equals ( java.lang.Object) 29 27 24 icescrum2.dao.model.impl.CustomRole.equals ( 27 27 24 java.lang.Object) icescrum2.service.impl.UserServiceImpl.saveUser ( 24 36 23 icescrum2.dao.model.IUser) icescrum2.dao.model.impl.ExecTest.equals ( 27 25 22 java.lang.Object) icescrum2.dao.model.impl.Task.equals ( java.lang.Object) 27 26 22 icescrum2.dao.model.impl.Test.equals ( java.lang.Object) 27 25 22 5.3.4 Cartographie des méthodes selon leur complexité et leur couplage efférent Cette règle vise à identifier les méthodes dont le code présente de nombreuses dépendances vers d’autres classes que la classe courante. La notion de « couplage efférent » correspond à ces dépendances « sortantes ». Le principe est qu’une méthode accusant un fort couplage efférent est difficile à comprendre, à maintenir et à tester d’une part parce qu’elle nécessite la connaissance des différents types tiers dépendants, d’autre par parce que son risque de déstabilisation est plus élevé en raison de ses dépendances. Cette règle est croisée avec la complexité cyclomatique afin d’ignorer certaines méthodes triviales, par exemple des méthodes d’initialisation d’interfaces graphiques qui font appels à de nombreuses classes de composants graphiques sans présenter de réelle complexité. Cette règle considère donc qu’une méthode est non-conforme si elle excède un seuil de couplage efférent et un seuil de complexité cyclomatique.Confidentiel - Ce document est la propriété de Kalistick 27/58
  • 28. Audit de code de l’application IceScrum2 10/02/2011 Le graphique suivant présente une cartographie des méthodes selon leur complexité et leur couplage efférent. Chaque point représente une ou des méthodes avec les mêmes valeurs de complexité et de couplage. Ils sont répartis dans quatre zones selon leur état par rapport aux deux seuils :  La zone en bas à gauche (points verts) contient des méthodes conformes qui n’ont atteint aucun des deux seuils  La zone en bas à droite (points gris) contient des méthodes conformes ; elles ont atteint le seuil de complexité, mais restent en-dessous du seuil de couplage  La zone en haut à gauche (points gris) contient des méthodes conformes ; elles ont atteint le seuil de couplage, mais restent en-dessous du seuil de complexité  La zone en haut à droite (points rouges) contient les méthodes non-conformes car les deux seuils sont atteints Voir sur le Cockpit Qualité L’intensité de la couleur des points dépend du nombre de méthodes partageant les mêmes valeurs en complexité et en couplage : plus la couleur du point est marquée, plus il y a de méthodes concernées.Confidentiel - Ce document est la propriété de Kalistick 28/58
  • 29. Audit de code de l’application IceScrum2 10/02/2011 L’histogramme suivant fournit une vision complémentaire de cette cartographie et précise les chiffres pour les quatre zones, en termes de pourcentage des méthodes de l’application et en termes de pourcentage du nombre d’instructions total de l’application. Les dernières barres correspondent à la zone de non- conformité : Voir sur le Cockpit Qualité Le tableau suivant détaille les principales méthodes non-conformes : Méthode Couplage Complexité Nouvelle efférent violation icescrum2.service.impl.ExportPDFServiceImpl.addReleasePlan ( 35 38 Nouvelle icescrum2.dao.model.IUser, int[], int[], icescrum2.dao.model.IProduct) icescrum2.service.impl.SprintServiceImpl.closeSprint ( 29 21 icescrum2.dao.model.IRelease, icescrum2.dao.model.ISprint, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct) icescrum2.service.impl.ImportXMLServiceImpl.parseProduct ( 23 41 org.w3c.dom.Element) icescrum2.service.impl.SprintServiceImpl.autoSaveSprint ( 21 16 icescrum2.dao.model.IRelease, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct) icescrum2.service.impl.SprintServiceImpl.saveSprint ( 20 20 icescrum2.dao.model.ISprint, icescrum2.dao.model.IRelease, java.lang.Integer, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct) icescrum2.service.impl.ImportXMLServiceImpl.importProduct ( 20 18 Nouvelle java.io.InputStream, icescrum2.dao.model.IUser, icescrum2.service.beans.ProgressObject) Voir sur le Cockpit QualitéConfidentiel - Ce document est la propriété de Kalistick 29/58
  • 30. Audit de code de l’application IceScrum2 10/02/2011 5.4 Test Le domaine Test propose des règles pour s’assurer que l’application est suffisamment testée, quantitativement mais surtout qualitativement, c.-à-d. que les tests ciblent les zones à risques. 5.4.1 Problématiques Il est important de situer les problématiques inhérentes à la gestion des tests afin de comprendre les résultats d’analyse pour ce domaine. 5.4.1.1 Tests unitaires et couverture de code Les résultats de ce domaine dépendent du processus de test appliqué sur le projet : si processus de tests unitaires automatisés et/ou de la couverture de code sont mis en œuvre sur le projet, alors l’analyse exploite les résultats de ces processus. Pour rappel, il faut bien distinguer test unitaire et couverture de code :  Un test unitaire est un test automatisé, qui teste généralement une méthode. Mais cette méthode ayant généralement des dépendances vers d’autres méthodes ou classes, un test unitaire peut tester un ensemble plus ou moins important de l’application (et plus cet ensemble est large, moins le test est pertinent)  La couverture de code mesure le volume de code réellement exécuté suite à des tests, en identifiant précisément chaque élément de code exécuté (instruction, branche conditionnelle, fonction, …). Ces tests peuvent être des tests unitaires (automatisés), ou des tests d’intégration / fonctionnels (manuels ou automatisés). La couverture de code est intéressante à combiner aux tests unitaires car c’est le seul moyen de mesurer le code réellement testé. Cependant, beaucoup de projets ne vérifient toujours pas la couverture du code, ce qui ne permet pas de vérifier la qualité des tests dans ce type d’analyse. Les indicateurs présentés par la suite permettent d’adresser les différents cas, que le projet mette en œuvre ou non des tests unitaires ou de la couverture de code. 5.4.1.2 Pertinence de la couverture de code La couverture de code fournit des chiffres précisant la proportion du code exécuté suite à des tests, par exemple 68% des instructions d’une méthode sont couvertes, 57% des instructions du projet. Le problème est que ces chiffres ne tiennent pas compte de la pertinence à tester le code. Par exemple une couverture de 70% de l’application est un bon chiffre, mais le code couvert peut être trivial et sans réel intérêt pour les tests (par exemple les accesseurs ou du code généré), alors que le code sensible pourra se trouver dans les 30% non couverts. L’analyse réalisée ici tient compte de la pertinence à tester chaque méthode, ce qui permet de calibrer les exigences de couverture de code et de fixer des exigences en termes de seuil de couverture qui utilisent au mieux l’effort de test en l’orientant sur les zones à risques.Confidentiel - Ce document est la propriété de Kalistick 30/58
  • 31. Audit de code de l’application IceScrum2 10/02/2011 5.4.2 Les métriques TestRelevancyIndex (TRI) et TestEffortIndex (TEI) Pour affiner l’analyse des tests, deux nouvelles métriques ont été conçues par le Centre d’Excellence en Technologies de l’Information et de la Communication (CETIC) en s’appuyant sur les recherches effectuées durant les 20 dernières années et à partir de la base de connaissances du « Cockpit Qualité »6. Le TestRelevancyIndex (TRI) mesure la pertinence à tester une méthode selon ses risques techniques et ses risques fonctionnels. Le risque technique évalue la probabilité de trouver un défaut, il est basé sur différentes métriques qui les favorisent telles que la complexité cyclomatique, le nombre de variables, de paramètres, le couplage efférent, le nombre de non-conformités cumulé, … Le risque fonctionnel associe un facteur de risque aux différents groupes de traitements fonctionnels que l’on souhaite tester en priorité (risque majoré) ou à l’inverse ne pas tester (risque minoré). Il doit être déterminé au début de l’audit pour être pris en compte dans les calculs de TRI. L’objectif est d’orienter l’effort de test sur les fonctionnalités importantes. Pour cela, le TRI permet de classer les méthodes selon une échelle de priorité de tests, et donc de bien distinguer les méthodes réellement pertinentes à tester des méthodes triviales et sans intérêt sur ce domaine. Pour chaque niveau de l’échelle, un seuil de couverture de code à atteindre peut être fixé indépendamment. Ceci permet de définir un seuil exigeant pour des méthodes critiques, et un seuil bas pour des méthodes à priorité basse. Le TestEffortIndex (TEI) complète le TRI en mesurant le niveau d’effort pour tester une méthode. Comme le TRI, il est basé sur un ensemble de métriques unitaires caractérisant la méthode. Il permet d’affiner les décisions pour sélectionner le code à tester en mettant dans la balance l’effort à fournir par rapport à la pertinence de test. Le détail du calcul de ces deux index est fourni en annexe (8.2 Le couplage). 5.4.3 Cartographie des méthodes par priorité de test L’histogramme suivant présente une cartographie des méthodes selon leur priorité de tests, à l’aide d’une échelle de quatre niveaux basée sur le TRI des méthodes (chaque niveau correspondant à un intervalle de TRI). Cette cartographie exploite les informations de couverture de code seulement si elles ont été fournies pour l’analyse. Pour chaque niveau de priorité est indiqué :  Le taux de couverture moyen (0 si les informations de couverture n’ont pas été fournies)  Le nombre de méthodes non couvertes (aucune couverture)  Le nombre de méthodes insuffisamment couvertes (taux de couverture inférieur au taux fixé en objectif pour ce niveau de priorité)  Le nombre de méthodes suffisamment couvertes (taux de couverture supérieur ou égal au taux fixé en objectif pour ce niveau de priorité) 6 CETIC, Kalistick. Statistically Calibrated Indexes for Unit Test Relevancy and Unit Test Writing Effort, 2010Confidentiel - Ce document est la propriété de Kalistick 31/58
  • 32. Audit de code de l’application IceScrum2 10/02/2011 Le tableau suivant détaille ces chiffres pour chaque niveau de priorité, en ajoutant également un cinquième niveau correspondant aux méthodes sans priorité de test : Priorité de test Couvertes Non couvertes Insuffisamment couvertes Critique 0 3 2 Haute 4 13 5 Moyenne 6 46 2 Basse 18 96 3 Aucune 115 3093 0 [Total] 143 3251 12 Voir sur le Cockpit Qualité 5.4.4 Couverture de l’application par les tests Ce graphique, appelé « TreeMap », restitue une vision de la couverture de l’application par les tests par rapport aux objectifs. Il permet d’identifier facilement les parties de l’application qui ne sont pas assez testées par rapport aux risques identifiés. Il regroupe les classes du projet par sous-ensembles techniques, et les caractérise selon deux dimensions :  la taille, qui dépend de leur nombre dinstructions  la couleur, qui représente lécart par rapport à lobjectif de test fixé pour la classe : la couleur rouge indique que le taux de couverture actuel est loin de l’objectif, la couleur verte indique que l’objectif est atteintConfidentiel - Ce document est la propriété de Kalistick 32/58
  • 33. Audit de code de l’application IceScrum2 10/02/2011 Voir sur le Cockpit Qualité Une classe peut être de couleur verte même si elle n’est pas ou peu testée, par exemple pour des classes avec une faible probabilité de défauts ou un risque fonctionnel réduit. Inversement, une classe déjà bien testée peut être indiquée comme insuffisante (rouge/brun) si son objectif est très exigeant. Une stratégie efficace pour améliorer sa couverture consiste à se concentrer sur les classes de taille importantes et proches de l’objectif. 5.4.5 Classes les plus importantes à tester (Top Risks) Le graphique suivant permet d’identifier rapidement les classes les plus pertinentes à tester, les « Top Risks ». C’est une représentation dite en « nuage », qui affiche les classes à l’aide de deux dimensions :  La taille du nom de classe dépend de son intérêt à être testée (valeur de TRI cumulée pour toutes ses méthodes)  La couleur représente lécart par rapport à lobjectif de couverture fixé pour la classe, tout comme pour le TreeMap précédentConfidentiel - Ce document est la propriété de Kalistick 33/58
  • 34. Audit de code de l’application IceScrum2 10/02/2011 Voir sur le Cockpit Qualité Cette représentation permet d’identifier les éléments critiques, mais si l’on souhaite tenir compte de l’effort d’écriture des tests il faut privilégier la représentation suivante pour sélectionner les éléments à corriger. 5.4.6 Classes les plus importantes à tester et demandant le moins d’effort (Quick Wins) Les « Quick Wins » complémente les « Top Risks » en tenant compte de l’effort de test à fournir pour tester la classe (TEI) :  La taille du nom de classe dépend de son intérêt à être testée (TRI), mais pondéré par l’effort nécessaire (TEI cumulé pour toutes ses méthodes) : une classe avec un fort TRI et un fort TEI (donc difficile à tester) apparaît plus petite qu’une classe avec un TRI moyen mais un faible TEI  La couleur représente lécart par rapport à lobjectif de couverture fixé pour la classe, tout comme pour le TreeMap ou les QuickWins Voir sur le Cockpit Qualité 5.4.7 Méthodes à tester en prioritéConfidentiel - Ce document est la propriété de Kalistick 34/58
  • 35. Audit de code de l’application IceScrum2 10/02/2011 Le tableau suivant détaille les principales méthodes à tester en priorité. A chaque méthode sont associés son taux de couverture actuel, sa valeur brute de TRI, et son niveau de TEI échelonnée de 0 à 4 :Confidentiel - Ce document est la propriété de Kalistick 35/58
  • 36. Audit de code de l’application IceScrum2 10/02/2011 Méthode Couverture Pertinence Priorité Effort Nouvelle (TRI) violation icescrum2.service.impl.ExportPDFServiceImpl.addRele 0% 39.0 Critique Très élevé Nouvelle asePlan ( icescrum2.dao.model.IUser, int[], int[], icescrum2.dao.model.IProduct) icescrum2.service.impl.ImportXMLServiceImpl.parseP 0% 39.0 Critique Très élevé roduct ( org.w3c.dom.Element) icescrum2.service.impl.ClicheServiceImpl.createCliche 0% 37.0 Critique Très élevé ( icescrum2.dao.model.IProduct, java.util.Date) icescrum2.service.impl.ProductBacklogServiceImpl.sa 76% 36.0 Critique Elevé veProductBacklogitem ( icescrum2.dao.model.IStory, icescrum2.dao.model.IProduct, icescrum2.dao.model.ISprint, icescrum2.dao.model.IUser, icescrum2.dao.model.ICustomRole) icescrum2.service.impl.TaskServiceImpl.updateTask ( 51% 35.0 Critique Elevé icescrum2.dao.model.ITask, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct, java.lang.String) icescrum2.service.impl.ProductBacklogServiceImpl.as 60% 34.0 Haute Elevé sociateItem ( icescrum2.dao.model.ISprint, icescrum2.dao.model.IStory, icescrum2.dao.model.IProduct, icescrum2.dao.model.ISprint, icescrum2.dao.model.IUser) icescrum2.dao.model.impl.Sprint.equals ( 0% 33.0 Haute Très élevé java.lang.Object) icescrum2.service.impl.ExportPDFServiceImpl.addProj 0% 33.0 Haute Elevé Nouvelle ect ( java.util.HashMap, icescrum2.dao.model.IProduct, icescrum2.dao.model.IUser) icescrum2.service.chart.VelocityChartSprint.init ( ) 0% 33.0 Haute Elevé icescrum2.service.chart.BurndownChartRelease.init ( 0% 33.0 Haute Elevé ) icescrum2.service.impl.ReleaseServiceImpl.updateRel 45% 32.0 Haute Elevé ease ( icescrum2.dao.model.IRelease, icescrum2.dao.model.IProduct) icescrum2.service.impl.TestServiceImpl.saveTest ( 79% 32.0 Haute Elevé icescrum2.dao.model.ITest, icescrum2.dao.model.IStory, icescrum2.dao.model.IUser) icescrum2.service.impl.SprintServiceImpl.autoSaveSpr 0% 32.0 Haute Très élevé int ( icescrum2.dao.model.IRelease, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct) icescrum2.service.impl.SprintServiceImpl.calculateDai 47% 32.0 Haute Elevé lyHours ( icescrum2.dao.model.ISprint, int)Confidentiel - Ce document est la propriété de Kalistick 36/58
  • 37. Audit de code de l’application IceScrum2 10/02/2011 icescrum2.service.impl.SprintServiceImpl.closeSprint ( 61% 32.0 Haute Très élevé icescrum2.dao.model.IRelease, icescrum2.dao.model.ISprint, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct) icescrum2.dao.model.impl.ProductBacklogItem.equal 0% 31.0 Haute Elevé s ( java.lang.Object) icescrum2.service.impl.ProductBacklogServiceImpl.ch 0% 31.0 Haute Elevé angeRank ( icescrum2.dao.model.IProduct, icescrum2.dao.model.IStory, icescrum2.dao.model.IStory, icescrum2.dao.model.IUser) icescrum2.service.impl.ProductBacklogServiceImpl.ge 0% 30.0 Haute Elevé tStory ( org.w3c.dom.Element, java.util.Map) icescrum2.service.impl.ProductBacklogServiceImpl.up 0% 30.0 Haute Elevé dateProductBacklogItem ( icescrum2.dao.model.IStory, icescrum2.dao.model.IUser, icescrum2.dao.model.IProduct, icescrum2.dao.model.ISprint, icescrum2.dao.model.ICustomRole) Voir sur le Cockpit Qualité 5.5 Architecture Le domaine Architecture vise à contrôler le respect d’un modèle d’architecture logicielle. Le principe consiste à définir un modèle d’architecture cible, qui identifie des couches et/ou des composants au sein de l’application, puis établit des contraintes pour autoriser ou interdire les communications entre chacun de ces éléments. L’objectif est triple :  Homogénéiser le comportement dune application. Par exemple sassurer que les écritures de logs utilisent telle API spécifique, que les accès aux données passent par telle couche, que telle librairie ne soit utilisée que par tel composant, ...  Assurer létanchéité de certains composants pour faciliter leur évolution et limiter les effets imprévus, mais aussi les rendre mutualisables avec dautres applications. Les cycles de dépendances sont par exemple proscrits.  Eviter les failles de sécurité en sassurant par exemple que des appels directs vers une couche daccès aux données ne sont jamais réalisés sans passer par une couche métier qui serait responsable de contrôles de validationConfidentiel - Ce document est la propriété de Kalistick 37/58
  • 38. Audit de code de l’application IceScrum2 10/02/2011 Actuellement, les violations des contraintes d’architecture ne sont pas prises en compte dans le calcul de la non-conformité de l’application. Voir sur le Cockpit Qualité Les violations de contraintes de communication entre deux éléments sont représentées à l’aide de flèches. Le point de départ est l’élément appelant, le point de destination est l’appelé. Les flèches orange concernent une communication directe entre une couche haute et une couche basse non adjacente (parfois acceptables). Les flèches noires concernent des communications totalement prohibées. 5.6 Duplication Le domaine Duplication concerne les « copier-coller » identifiés au sein de l’application. Pour éviter les nombreux faux-positifs dans ce domaine, seuls sont remontés les blocs dupliqués impliquant un seuil minimal d’instructions. Les duplications sont à proscrire pour de multiples raisons : problèmes de maintenance et d’évolutivité, coûts de tests, défaut de fiabilité, … 5.6.1 Cartographie des duplications Le graphique suivant présente une cartographie des duplications au sein de l’application. Il ne tient pas compte des duplications impliquant un nombre d’instructions inférieur au seuil, car celles-ci sont généralement nombreuses et peu pertinentes (par exemple les duplications d’accesseurs entre différentes classes partageant des propriétés semblables).Confidentiel - Ce document est la propriété de Kalistick 38/58
  • 39. Audit de code de l’application IceScrum2 10/02/2011 Les duplications sont catégorisées par intervalles d’instructions dupliquées. Pour chaque intervalle est présenté :  Le nombre de blocs dupliqués différents (chacun étant dupliqué au moins une fois)  Le nombre maximal de duplications d’un même bloc Voir sur le Cockpit Qualité 5.6.2 Duplications à corriger en priorité Le tableau suivant détaille la liste des principales duplications à corriger en priorité. Chaque bloc est identifié par un numéro unique, et chaque duplication est localisée dans le code. Si un audit précédent a été réalisé, un indicateur indique si la duplication est nouvelle ou non.Confidentiel - Ce document est la propriété de Kalistick 39/58
  • 40. Audit de code de l’application IceScrum2 10/02/2011 N° Nb lignes Classe impliquée Lignes Nouvelle duplication dupliquées violation 239 111 icescrum2.presentation.app.roadmap.RoadmapUI 858:1003 Nouvelle 239 111 icescrum2.presentation.app.releasebrowser.ReleaseBrowse 1045:119 Nouvelle rUI 0 238 69 icescrum2.presentation.app.roadmap.RoadmapUI 590:688 Nouvelle 238 69 icescrum2.presentation.app.releasebrowser.ReleaseBrowse 731:830 Nouvelle rUI 237 56 icescrum2.service.impl.ClicheServiceImpl 309:373 237 56 icescrum2.service.impl.ClicheServiceImpl 201:263 236 52 icescrum2.service.chart.GlobalChartTest 243:316 236 52 icescrum2.service.chart.VelocityChartSprint 219:292 236 52 icescrum2.service.chart.ExecChartTest 156:229 235 50 icescrum2.service.chart.VelocityChartSprint 221:290 235 50 icescrum2.service.chart.ExecChartTest 158:227 235 50 icescrum2.service.chart.BurndownChartProduct 322:391 235 50 icescrum2.service.chart.GlobalChartTest 245:314 234 49 icescrum2.presentation.app.releasebrowser.ReleaseBrows 877:944 Nouvelle erUI 234 49 icescrum2.presentation.app.roadmap.RoadmapUI 698:765 Nouvelle 233 48 icescrum2.service.chart.GlobalChartTest 249:316 233 48 icescrum2.service.chart.ExecChartTest 162:229 233 48 icescrum2.service.chart.BurndownChartRelease 202:268 233 48 icescrum2.service.chart.VelocityChartSprint 225:292 Voir sur le Cockpit Qualité 5.7 Documentation Le domaine Documentation vise à contrôler le niveau de documentation technique du code. Seule la présence des commentaires d’entêtes standards des méthodes est vérifiée : Javadoc pour Java, XmlDoc pour C#. Les commentaires « inline » (dans le corps des méthodes) ne sont pas évalués en raison de la difficulté à vérifier leur pertinence (souvent du code commenté). De plus, l’entête de documentation n’est vérifié que sur les méthodes considérées comme assez longues et complexes. Car l’effort pour documenter des méthodes triviales est rarement justifié. Pour cela, un seuil sur la complexité cyclomatique et un seuil sur le nombre d’instructions sont définis pour filtrer les méthodes à vérifier. 5.7.1 Cartographie des problèmes de documentation Le graphique suivant présente une cartographie de la documentation des méthodes du projet avec une complexité supérieure au seuil fixé. Les méthodes sont regroupées par intervalles de taille (nombre d’instructions). Pour chaque intervalle sont indiqués le nombre de méthodes avec entête de documentation et le nombre de méthodes sans entête de documentation. La zone rouge du dernier intervalle correspond aux méthodes non documentées donc non-conformes.Confidentiel - Ce document est la propriété de Kalistick 40/58
  • 41. Audit de code de l’application IceScrum2 10/02/2011 5.7.2 Méthodes à documenter en priorité Le tableau suivant détaille la liste des principales méthodes à documenter en priorité : Méthode Instructions Complexité Nouvelle violation icescrum2.service.impl.ExportXMLServiceImpl.exportSprint 81 10 Nouvelle icescrum2.service.impl.ReleaseServiceImpl.saveRelease 59 30 Nouvelle icescrum2.service.impl.ClicheServiceImpl.createCliche 208 42 icescrum2.service.impl.SprintServiceImpl.autoSaveSprint 89 16 icescrum2.service.chart.VelocityChartSprint.init 78 13 icescrum2.service.impl.SprintServiceImpl.closeSprint 70 21 icescrum2.service.impl.ExportXMLServiceImpl.exportItem 66 10 icescrum2.service.chart.BurndownChartRelease.init 66 14 icescrum2.service.chart.BurnupChartProduct.init 50 10 Voir sur le Cockpit QualitéConfidentiel - Ce document est la propriété de Kalistick 41/58
  • 42. Audit de code de l’application IceScrum2 10/02/2011 6 Plan d’action Pour chaque domaine, une préconisation des corrections a été établie sur la base de tableaux détaillant les règles et les éléments de code à corriger. Le graphique suivant propose une approche globale pour établir un plan de corrections en définissant une liste d’actions. Cette liste est priorisée selon le retour sur investissement escompté : les actions préconisées en premier lieu sont celles qui présentent le meilleur rapport entre l’effort à produire et le gain sur le taux de non-conformité global. Voir sur le Cockpit Qualité Voici l’explication de chaque étape : 1. Correction des pratiques interdites Ces pratiques sont souvent simples à corriger, et du fait qu’elles invalident directement les classes, leur correction conduit généralement à améliorer significativement le taux de non-conformité global (si les classes ne sont pas invalidées par d’autres règles). 2. Eclatement des méthodes trop longues A l’aide de certains IDE, il est souvent facile d’éclater une méthode trop longue en plusieurs méthodes unitaires. Ceci est réalisé à l’aide d’opérations automatisées réalisant des refactorings7, évitant tout risque de régression lié à une intervention manuelle. 3. Documentation des méthodes complexes Cette étape consiste à documenter les méthodes identifiées comme non-conformes dans le domaine Duplication, opération simple mais potentiellement fastidieuse.Confidentiel - Ce document est la propriété de Kalistick 42/58
  • 43. Audit de code de l’application IceScrum2 10/02/2011 4. Correction des pratiques déconseillées Correspondent à toutes les pratiques restantes après correction des pratiques interdites : pratiques fortement déconseillées, déconseillées et à éviter. 5. Suppression des duplications Cette opération est plus ou moins compliquée suivant les cas : il faut au préalable déterminer si la duplication doit réellement être factorisée (deux composants peuvent partager une même base de code mais être indépendants). Ensuite l’opération peut être automatisée selon les IDE et selon le type de duplication (difficile si la duplication est à cheval sur plusieurs méthodes). 6. Modularisation des traitements complexes Cette opération est proche de l’éclatement des méthodes trop longues, mais est souvent plus délicate à réaliser en raison de la complexité du code. Le plan d’action peut être affiné sur le Cockpit Qualité en utilisant le mécanisme des « tags ». Les tags permettent d’étiqueter les résultats d’analyse pour faciliter des opérations telles que la priorisation des corrections, leur affectation à des développeurs ou leur lotissement selon les versions.Confidentiel - Ce document est la propriété de Kalistick 43/58
  • 44. Audit de code de l’application IceScrum2 10/02/2011 7 Glossaire Axe de qualité Les résultats danalyses sont ventilés sur 6 axes de qualités selon les besoins de lapplication en termes de qualité :  Efficacité : lapplication assure-t-elle les performances dexécution attendues ?  Evolutivité : les évolutions du code nécessitent-t-elles un coût de développement croissant ?  Fiabilité : lapplication présente-t-elle des bugs qui nuisent à son comportement attendu ?  Maintenabilité : les mises à jour de maintenance nécessitent-t-elles un coût de développement constant ?  Sécurité : lapplication présente-t-elle des failles de sécurité ?  Transférabilité : la reprise de lapplication par de nouveaux intervenants est-elle problématique ? Couverture par blocs La couverture par blocs mesure le taux de blocs exécutés lors des tests par rapport au nombre total de blocs. Un bloc de code est un chemin de code avec un point dentrée unique, un point de sortie unique et un jeu dinstructions exécutées en séquence. Il se termine lorsquil atteint une instruction conditionnelle, un appel de fonction, une levée dexception, ou un try/catch. Couverture par branches La couverture par branches mesure le taux de branches exécutées lors des tests par rapport au nombre total de branches. if (value) { // } Ce code sera couvert par branches à 100% si la condition du if a été testée dans le cas vrai et faux. Couverture par lignes La couverture par lignes (ou instructions) mesure le taux de lignes exécutées lors des tests par rapport au nombre total de lignes. Cette mesure est insensible aux instructions conditionnelles, la couverture par lignes peut être de 100% sans que lensemble des conditions soit exécuté.Confidentiel - Ce document est la propriété de Kalistick 44/58
  • 45. Audit de code de l’application IceScrum2 10/02/2011 Domaine de qualité Les résultats danalyses sont ventilés sur 4 domaines selon la nature des violations :  Implémentation : concerne des problèmes liés à lutilisation du langage ou à lalgorithmie  Structure : concerne des problèmes liés au découpage de lapplication : taille des méthodes, complexité cyclomatique, ...  Test : concerne les problèmes liés aux tests unitaires du code et à sa couverture  Architecture: concerne les problèmes liés l’architecture logicielle  Documentation : concerne les problèmes liés à la documentation du code : commentaires dentête, commentaires de code, ...  Duplication : correspond aux copier-coller découverts dans le code  Instruction de code Une instruction de code représente une unité de code primaire, proche de la ligne de code. Pour simplifier, une instruction est délimitée par un point-virgule (;) ou pour par une accolade gauche ({). Exemples dinstructions en Java :  int i = 0;  if (i == 0) {  } else {  public final class SomeClass  {  import com.project.SomeClass;  package com.project; A la différence des lignes de code, les instructions ne comprennent pas les lignes blanches et les commentaires. De plus, une ligne peut contenir plusieurs instructions. Ligne de code Une ligne physique dun fichier de code. Peut concerner une ligne blanche, ou une ligne de commentaire. Non-conformité Un résultat danalyse qui ne satisfait pas les exigences techniques fixées par le projet. Une non-conformité concerne un axe de qualité et un domaine de qualité. Synonyme(s) : violationConfidentiel - Ce document est la propriété de Kalistick 45/58
  • 46. Audit de code de l’application IceScrum2 10/02/2011 8 Annexes 8.1 La complexité cyclomatique La complexité cyclomatique est un indicateur du nombre de chemins possibles d’exécution. Sa valeur élevée est signe qu’il sera difficile à comprendre, à tester, à valider, à maintenir et à faire évoluer. 8.1.1 Définition On produit un graphe de contrôle qui représente le code dont on veut mesurer la complexité. Une fois ce graphe de contrôle dessiné, on compte le nombre CC de faces de ce graphe. La complexité structurelle du code (appelée aussi complexité cyclomatique) est mesurée par CC.Confidentiel - Ce document est la propriété de Kalistick 46/58
  • 47. Audit de code de l’application IceScrum2 10/02/2011 8.1.2 Exemple On souhaite mesurer la complexité du code suivant : Code analysé Graphe de contrôle équivalent int x = 3; if (x > 0) { x++; } else { Le graphe contient 4 arcs, 4 nœuds et 2 faces (1 intérieure, 1 extérieure). Le nombre CC vaut donc 2. x--; } 8.1.3 Corollaire de la définition CC = nb de décisions du code + 1  Une instruction if compte pour 1 décision  Une instruction for ou while compte pour 1 décision  Une instruction case compte n décisions.Confidentiel - Ce document est la propriété de Kalistick 47/58
  • 48. Audit de code de l’application IceScrum2 10/02/2011 8.1.4 Diagnostic à effectuer 8 Valeur de la Complexité Evaluation des risques selon le S.E.I. Cyclomatique 1-10 Programme simple, sans trop de risque 11-20 Complexité et risque modéré 21-50 Complexe, risque élevé Supérieure à 50 Non testable, risque très élevé Dans le cas où la valeur de la complexité est trop élevée (>20) :  Il peut y avoir une présence de nombreux tests “instance of” du même objet ce qui est symptomatique d’un sous-emploi du polymorphisme.  Le niveau d’imbrication des instructions if, for, while dans le code est élevé. Il faut extraire le code signifiant et le mettre dans une ou plusieurs méthodes. 8 : Le S.E.I. (Software Engineering Institute, http://www.sei.cmu.edu/) est l’institut à l’origine de la norme CMMI. Ses recherches réputées sur la qualité de code en font un acteur majeur et fiable dans le domaine. CMMi : sigle de Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises dingénierie (source : Wikipedia).Confidentiel - Ce document est la propriété de Kalistick 48/58
  • 49. Audit de code de l’application IceScrum2 10/02/2011 8.2 Le couplage Le couplage permet de mesurer le déficit en indépendance des classes ou des méthodes. Si le couplage entre les classes est élevé, alors l’application est peu modulaire et sera difficile à faire évoluer. 8.2.1 Définition Deux classes sont couplées si les méthodes déclarées dans l’une utilisent des méthodes ou instancient des variables définies dans l’autre. La relation est symétrique : si la classe A est couplée à B, alors B est couplée à A. La métrique CBO (Coupling Between Classes) mesure pour une classe A donnée, le nombre de classes qui sont couplées à cette classe A. Le couplage efférent mesure pour une méthode donnée, le nombre de références faites à des types tiers et à leurs méthodes dans son code. Lorsque le couplage efférent est élevé, la méthode atteint un haut niveau de dépendance vis-à-vis des autres classes de l’application. 8.2.2 Exemple de calcul de couplage Le calcul du couplage entre des classes peut par exemple s’effectuer en comptant :  Les déclarations d’attributs avec des références sur les classes  Les paramètres formels (dans les signatures des méthodes par exemple)  Les déclarations throws  Les variables locales  Les types Le calcul du couplage efférent pour une méthode peut par exemple s’effectuer en comptant :  Les paramètres formels (dans la signature de la méthode) ayant un type tiers non primitif  Les déclarations throws  Les variables locales de la méthode utilisant un type non primitif défini hors de la classeConfidentiel - Ce document est la propriété de Kalistick 49/58
  • 50. Audit de code de l’application IceScrum2 10/02/2011 8.3 Le TRI et TEI Le TRI (TestRelevancyIndex) et le TEI (TestEffortIndex) sont deux index permettant de mesurer respectivement la pertinence à tester du code et l’effort à produire pour implémenter ces tests. Ils ont été conçus en partenariat avec le Centre dExcellence en Technologies de lInformation et de la Communication (CETIC) à partir des millions de lignes de code analysées par la plateforme Cockpit Qualité9. 8.3.1 Le TRI (TestRelevancyIndex) 8.3.1.1 Objectif Lobjectif du TRI est d’affiner l’analyse de la couverture de code effectuée par les tests en corrélant la notion brute de couverture de code à celle de pertinence à tester dune méthode. On ne s’intéresse plus seulement au pourcentage de code couvert, mais aussi à la pertinence dans le choix des méthodes testées. Lintérêt est de sassurer que lobjectif de couverture de code à atteindre ciblera les bonnes méthodes. 8.3.1.2 Principe et groupes de priorités de test Le TRI est un index spécifique aux méthodes, dont la valeur est obtenue en scorant les valeurs dun ensemble de métriques unitaires (complexité cyclomatique, couplage afférent, ...) et en appliquant un facteur de criticité. Ce facteur de criticité est associé à des sous-ensembles fonctionnels auxquels contribue lélément de code. Il est déterminé de manière spécifique à l’application. En fonction de cette valeur de TRI, les méthodes sont classifiées en cinq groupes de priorité de test :  Critique : méthodes complexes et/ou sensibles à tester obligatoirement  Haute  Moyenne  Basse  Aucune : méthodes triviales inutiles à tester Chaque groupe de priorité de test fixe pour les méthodes concernées :  un seuil de couverture à atteindre.  une sévérité en cas de violation Il est ainsi possible de spécifier pour les éléments critiques un objectif de test exigeant, avec le traitement des différents cas de fonctionnement, et pour les éléments moins prioritaires, des tests qui ciblent uniquement les traitements nominaux. 8.3.1.3 Détail des métriques unitaires Le TRI est calculé à partir des métriques unitaires suivantes :  Complexité cyclomatique de la méthode  Nombre de paramètres de la méthode  Nombre de variables locales de la méthode  Couplage afférent 9 CETIC, Kalistick. Statistically Calibrated Indexes for Unit Test Relevancy and Unit Test Writing Effort, 2010Confidentiel - Ce document est la propriété de Kalistick 50/58
  • 51. Audit de code de l’application IceScrum2 10/02/2011  Couplage efférent  Nombre de violations cumulées de la méthode 8.3.2 Le TEI (TestEffortIndex) 8.3.2.1 Objectif Le TEI introduit une nouvelle dimension dans la priorisation des méthodes à tester, en fournissant une estimation de leffort nécessaire pour tester une méthode. Cet index nintervient pas dans la non-conformité des méthodes, il est simplement fourni à titre indicatif. 8.3.2.2 Principe Le TEI est un index spécifique aux méthodes, dont la valeur est obtenue en scorant les valeurs dun ensemble de métriques unitaires (complexité cyclomatique, nombre de paramètres, ...). En fonction de cette valeur de TEI, les méthodes sont classifiées en cinq groupes deffort de test :  Très faible: méthodes triviales à tester  Faible  Normal  Élevé  Très élevé: méthodes complexes très difficilement testables exhaustivement 8.3.2.3 Détail des métriques unitaires Le TEI est calculé à partir des métriques unitaires suivantes :  Complexité cyclomatique de la méthode  Nombre de paramètres de la méthode  Nombre de variables locales de la méthodeConfidentiel - Ce document est la propriété de Kalistick 51/58
  • 52. Audit de code de l’application IceScrum2 10/02/2011 8.4 Exigences techniques 8.4.1 Règles d’implémentation Référence Description courte Sévérité AlwaysCallSuperCloneIn Lappel à <code>clone</code> doit toujours remonter dans larbre Interdit CloneMethod dhéritage AlwaysDeclareClassPack Toujours organiser les classes dans des packages. Interdit age AlwaysDeclareCloneable Toujours déclarer linterface <code>Cloneable</code> lorsque la méthode Interdit InterfaceWhenImplement clone est implémentée. ingCloneMethod AlwaysSynchronizeDate Les classes de formattage <code>java.text.XXXFormat</code> nétant pas Interdit Formatter thread-safe, il est indispensable de synchroniser les traitements en environnement multitâches. AvoidBadPatternDouble La pratique du "Double-checked locking", qui vise à améliorer les Interdit CheckLocking performances de certaines synchronisations de ressources, na pas un fonctionnement garanti. CallWaitInsideWhile Un appel à linstruction <code>wait()</code> devrait être réalisé au sein Interdit dun <code>while</code> plutôt que dun <code>if</code>. ChooseDifferentNamesF Une méthode ne doit pas avoir le même nom que la classe à laquelle elle Interdit orMethodAndClass appartient DontAssignBooleansInC Assigner un booléen dans une condition est peu clair et est en fait souvent Interdit onditions le résultat dune faute de frappe. DontAssignVariablesInC Réaliser des affectations dans des conditions rend le code très difficilement Interdit onditions lisible. DontCallFinalizeExplicitel La méthode <code>finalize()</code> ne doit jamais être invoquée Interdit y explicitement. DontCallNotifyWithoutMo Appeler la méthode <code>notify()</code> sur un objet sans posséder un Interdit nitor verrou dessus conduit, lors de lexécution, à une exception de type <code>IllegalMonitorStateException</code>. DontCallRunExplicitely La méthode <code>run()</code> dun <code>Runnable</code> ne devrait Interdit pas être invoquée directement. DontCallWaitWithoutMon Appeler la méthode <code>wait()</code> sur un objet sans posséder un Interdit itor verrou dessus conduit, lors de lexécution, à une exception de type <code>IllegalMonitorStateException</code>. DontCatchIllegalMonitorS La gestion explicite de lexception Interdit tateException <code>IllegalMonitorStateException</code> dénote généralement dune mauvaise conception du code. DontCatchNPE Lexception <code>NullPointerException</code> ne doit jamais être Interdit attrapée. DontChangeLockInSynch Dans un bloc de synchronisation, il ne faut pas modifier la référence de Interdit ronizedBlock lobjet avec lequel on synchronise le bloc en cours. Dans le cas contraire, on peut engendrer des interblocages de Thread. DontCompareFloatToNa Il ne faut jamais comparer une variable à la valeur spéciale Interdit N <code>NaN</code> (Not A Number) DontCompareObjectWith Le test dégalité renverra toujours faux car les deux objets comparés sont Interdit DistinctType de type différent. DontCreateExceptionNot Une exception est crée mais nest pas envoyée. Interdit Thrown DontDefineHardwiredDB Le mot de passe pour se connecter à la base de données ne doit pas se Interdit Password retrouver codé en dur dans le code Java. DontDefineHardwiredPat Définir un chemin en dur pour référencer un fichier est proscrit. Interdit hNamesConfidentiel - Ce document est la propriété de Kalistick 52/58
  • 53. Audit de code de l’application IceScrum2 10/02/2011 DontDefineTooManyLeve Il est très difficile de comprendre une conception&nbsp;&nbsp;lorsquil y a Interdit lsOfNestedInnerClasses de nombreuses classes internes imbriquées DontHideInheritedInstanc Lorsquune classe hérite dune autre, il faut faire attention à ne pas Interdit eFields masquer des champs de la classe mère, car ceci peut avoir des effets de bords désastreux. DontInstantiateStringBuff Il ne faut pas instancier un StringBuffer avec un argument de type Char car Interdit erWithChar ce constructeur est utilisé pour initialiser la taille du StringBuffer. DontOverloadFinalize Il est déconseillé de redéfinir la méthode finalize() avec des paramètres. Interdit Cette méthode ne sera pas appelée par la JVM et pourra être source de confusion et derreur. DontOverwriteNonReadP Il ne faut pas écrire sur un paramètre qui na jamais été lu. Interdit arameter DontPutRandomResultInI Il ne faut pas stocker le résultat de lopération random dans un integer Interdit nteger DontSynchronizeOnBool Il ne faut pas synchroniser sur un objet de type Booléen. Dans le cas Interdit ean contraire, on peut engendrer des interblocages de Thread. DontSynchronizeOnBoxe Il ne faut pas synchroniser sur un objet Wraper de type primitif comme par Interdit dPrimative exemple Integer. Dans le cas contraire, on peut engendrer des interblocages de Thread. DontSynchronizeOnCons Il ne faut pas synchroniser sur une constante de type String. Dans le cas Interdit tantString contraire, on peut engendrer des interblocages de Thread. DontUseAssertAsIdentifi Le terme assert ne doit plus être utilisé comme identifiant du fait quil est Interdit er un mot réservé depuis Java 5. DontUseConstructorsInCl Clone ne doit pas utiliser de constructeur Interdit oneMethod DontUseDirectlyParamet Il ne faut pas écrire directement des paramètres HTTP dans un Cookie qui Interdit erInCookieResponse va être renvoyé au navigateur client. DontUseDirectlyParamet Il ne faut pas écrire directement des paramètres HTTP dans lentête du Interdit erInHeaderResponse flux HTTP de sortie. DontUseDirectlyParamet Il ne faut pas écrire directement des paramètres HTTP dans le flux de sortie Interdit erInServletWriter de la Servlet (cross site scripting vulnerability). DontUseEnumAsIdentifie Enum ne doit pas être utilisé comme identifiant pour des raisons de Interdit r portabilité vers java 5 et supérieur DontUseEqualsOnFloats Les comparaisons de nombres à virgule flottante peuvent être inexactes. Interdit DontUseMultipleUnaryOp Lécriture de plusieurs opérateurs unaires à la suite engendre une Interdit erators complexité de compréhension du code. DontUseNewToInstantiat La création dun objet Integer à partir dun entier primitif doit être réalisée Interdit eIntegers à laide de la méthode valueOf() plutôt que par le constructeur. DontUseNewToInstantiat Linstanciation de nouveaux objets String est géneralement inutile, un Interdit eStrings objet String est initialisé directement à partir dune chaîne de caractères. DontUseNonCaseLabelIn Lutilisation de label en développement est connue pour être une très Interdit Switch mauvaise façon de coder. DontUseOctalNotation Il ne faut pas affecter de valeur Octal (entier commençant par un 0) à une Interdit valeur entière. DontUseReturnInFinallyB Lutilisation de linstruction return dans un bloc finally est proscrite. Interdit lock DontUseSameVariableLo Il ne faut pas incrémenter&nbsp;&nbsp;la même variable de boucle Interdit opAsEnclosingLoop pour deux boucles for imbriquées. ImpossibleCast Cast qui renverra toujours <code>ClassCastException</code> Interdit InfiniteLoop Une boucle infinie est une pratique déconseillée en environnement Java. Interdit InfiniteRecursiveCall Une méthode récursive doit absolument avoir une condition darrêt Interdit MakeSingletonsThreadS Un singleton doit être thread-safe afin déviter des incohérences dans un Interdit afe environnement multitâches.Confidentiel - Ce document est la propriété de Kalistick 53/58
  • 54. Audit de code de l’application IceScrum2 10/02/2011 MisplacedNullCheck La vérification quun objet nest pas <code>null</code>&nbsp;&nbsp;ne Interdit doit pas être réalisée après quil ait été utilisé, mais avant. Cela rend le test inutile et indique quil aurait sans-doute dû avoir lieu avant. MisplacedSemicolon Un point-virgule est défini immédiatement après un if est généralement Interdit une erreur de frappe. MisusedNullCheck La vérification quun objet nest pas <code>null</code>&nbsp;&nbsp;est Interdit erronée. Ce cas&nbsp;&nbsp;générera trés vraisemblablement une exception <code>Null Pointer Exception</code>. NPEAlwaysThrown Une exception <code>NullPointerException</code> sera Interdit systématiquement levée au regard du code écrit. NeverCallGarbageCollect Lappel au Garbage Collector ne doit jamais être réalisé de manière Interdit orExplicitely explicite, sauf cas très particulier du type benchmark. NeverCallUglyJavaMetho Les méthodes System.RunFinalizersOnExit et Runtime.runFinalizersOnExit Interdit d sont connues pour poser des problèmes et avoir de graves effets de bord. NeverDefineClassFieldsI Il ne devrait pas y avoir de variables dinstances dans des Servlet J2EE Interdit nJ2EEServlet NeverDefineClassFieldsI Il ne devrait pas y avoir de variables dinstances dans des Struts J2EE Interdit nJ2EEStruts NeverMakeCtorCallInner Un contructeur ne devrait jamais utiliser une classe interne, car elle nest Interdit Class pas encore initialisée lors de la construction. NeverMakeCtorCallInner Un constructeur ne devrait pas appeler une méthode interne dans une Interdit MethodInAbstractClass classe abstraite. Ceci peut avoir des effets de bords lors de la construction des classes filles héritées SQLStatementsAndResu Un SQL statement et un resultset ont un index qui commence à 1 et non Interdit ltsetsParametersStartAtO pas à 0. ne SameCodeForTwoPaths Lorsque deux branches dune condition définissent exactement les mêmes Interdit traitements, le code souffre généralement dun copier/coller et sen trouve erroné. UseAppendMethodForStr La pratique consistant à alimenter un <code>StringBuffer</code> à partir Interdit ingBuffer de concaténation de <code>String</code> sans utiliser la méthode <code>append()</code> est incohérente. UseBetterObjectArrayList Il est désormais recommandé dutiliser les nouvelles classes des Interdit collections, en remplacement de la classe <code>Vector</code>. UseBetterObjectMap Il est désormais recommandé dutiliser des classes du framework des Interdit collections en remplacement de la classe <code>Hashtable</code>. UseSameArgCountInStri Le nombre de jokers dans la chaîne de formatage doit être égal au Interdit ngFormat_ nombre de valeurs passées en paramètre de la méthode. UseStringBufferForString Il est préférable dutiliser un <code>StringBuffer</code> pour concaténer Interdit Concatenation des objets String dans une boucle. UselessCheckEqualsNull Selon le contrat Java standard, une methode <code>equals()</code> Interdit appelée avec <code>null</code> en paramètre (ex: <code>obj1.equals(null)</code>) doit toujours retourner <code>false</code>. Un tel appel&nbsp;&nbsp;est donc erroné (il fallait faire <code>obj1==null</code>) ou inutile. UselessIfStatement Linstruction <code>if</code> est inutile du fait que la condition testée à Interdit toujours la même valeur. AlwaysMakeInitializersSt Il est déconseillé de définir des initialisations dans des blocs non statiques Fortement atic et hors méthodes déconseillé AlwaysProvideThrowClo Une classe non clonable devrait toujours renvoyer Fortement neNotSupportedExceptio <code>CloneNotSupportedException</code> nForCloneMethod déconseillé DontAssignVariablesInO Réaliser des affectations dans des conditions ou dans des opération Fortement perands complexifie la lecture du code. déconseilléConfidentiel - Ce document est la propriété de Kalistick 54/58
  • 55. Audit de code de l’application IceScrum2 10/02/2011 DontCallNextInHasNext Il ne faut jamais appeler <code>Next</code> dans une méthode Fortement Method <code>hasNext</code>. déconseillé DontCallSystemExit Lappel à la méthode <code>System.exit()</code> est rarement Fortement justifiable. déconseillé DontIgnoreInputstreamR Il est indispensable de vérifier le retour des méthodes Fortement eadReturnValue <code>read(byte[])</code> et <code>read(byte[] b int, int)</code> déconseillé pour exploiter le tableau résultat. DontIgnoreMethodsRetur La valeur de retour dune méthode devrait être exploitée. Fortement nValue déconseillé DontMakeAssignmentInR Laffectation dune variable au niveau du retour dune fonction nest pas Fortement eturnStatement conseillé. déconseillé DontMakeClassesFields Un attribut de classe ne doit pas être déclaré avec une visibilité publique, Fortement PublicExceptFinalFields sauf sil est final ou statique. déconseillé DontStartThreadInsideCt Le démarrage dun thread au sein dun constructeur de classe est une Fortement or pratique à risque. déconseillé DontThrowNPE Lancer explicitement une exception de type NullPointerException porte à Fortement confusion. déconseillé DontTouchForLoopVaria Attention à ne pas modifier la variable ditération dune boucle for à Fortement ble lintérieur de celle-ci. déconseillé DontUseExceptionAsGot Il nest pas recommandé de se servir des exceptions pour contrôler le flot Fortement o dune méthode, en lançant une exception pour lattraper quelques déconseillé lignes après. DontUseInstanceofInCat La récupération de différents types dexception doit être réalisée à laide Fortement chBlocks de plusieurs bloc catchs et non en testant manuellement le type déconseillé dexception. NeverMakeCtorCallInner Un constructeur ne devrait jamais appeler une méthode interne Fortement Method déconseillé OverrideEqualsAndHash Si une des deux méthodes <code>equals()</code> ou Fortement codeTogether <code>hashCode()</code> doit être suchargée, il est nécessaire de déconseillé surcharger lautre. OverrideEqualsWhenImp Limplémentation de <code>compareTo()</code> suppose également Fortement lementingCompareTo limplementation de <code>equals()</code> déconseillé ThreadsMustHaveRunM Une classe dérivant de <code>Thread</code> ou implémentant Fortement ethod <code>Runnable</code> doit implémenter la méthode déconseillé <code>run()</code>. TraceErrorsWithLogger Il est recommandé de tracer les erreurs à laide dune API de logging plutôt Fortement que de recourir à des appels du type printStackTrace(). déconseillé UseBetterInterfaceIterato Il est désormais recommandé dutiliser des interfaces du framework des Fortement r collections (<code>Iterator</code>) en remplacement de déconseillé <code>Enum</code>. UseConstantStringsForS Pour des raisons de sécurité, les requêtes SQL doivent avoir une structure Fortement qlRequests constantes déconseillé UseLoggerRatherThanPr Il est préférable dutiliser un framework de log plutôt que décrire Fortement intMethods directement sur la sortie standard ou la sortie derreur. déconseillé UseStaticFinalLoggerFor Un attribut de type loguer doit généralement être déclaré comme Fortement ClassesThatNeedOne statique. déconseillé UselessOperationOnCon Invoquer des méthodes sur des objets immuables sans récupérer leur Fortement stantObjects retour ne sert à rien. déconseillé AlwaysPutDefaultCaseLa Dans un soucis de logique, on place toujours le <code>case Déconseillé stInSwitch default</code> en dernier.Confidentiel - Ce document est la propriété de Kalistick 55/58
  • 56. Audit de code de l’application IceScrum2 10/02/2011 AlwaysSynchronizeAtBlo Il est conseillé de définir une synchronisation au niveau dun bloc Déconseillé ckLevel dinstructions plutôt que dune méthode ChangeForLoopIntoWhil Utiliser la structure ditération la plus claire Déconseillé eLoop ChooseDifferentNamesF Il faut éviter de donner à un attribut le nom de sa classe. Déconseillé orFieldsAndClasses ChooseDifferentNamesF Il faut éviter de donner à une variable locale&nbsp;&nbsp;le nom dun Déconseillé orFieldsAndLocalVariabl attribut de la même classe. es ChooseDifferentNamesF Il faut éviter de donner à une méthode le nom dun attribut de la Déconseillé orFieldsAndMethods même classe. CompareToMustBeUnive La méthode <code>compareTo()</code> doit suivre la signature de Déconseillé rsal <code>Comparable</code>. DontCastCollectionToDer Déconseillé ivedCollection DontCatchTooGeneralEx Il nest pas recommandé dattraper des exceptions avec un type trop Déconseillé ceptions général. DontDeclareThrowingTo Une méthode ne devrait pas être déclarée avec des exceptions trop Déconseillé oGeneralException générales DontDefineHardwiredCh Il est déconseillé dutiliser des éléments de type caractère en dur. Déconseillé aracterLiterals DontInstantiateClassProv Il est inutile dinstancier une classe qui nest constituée que de méthodes Déconseillé idingOnlyStaticMethods statiques. DontLeaveEmptyCatchBl Un bloc catch ne doit jamais être vide. Déconseillé ocks DontThrowTooGeneralEx Il est recommandé déviter de lancer des exceptions trop générales Déconseillé ception EqualsMustBeUniversal La méthode equals() doit renvoyer false si le paramètre nest pas du même Déconseillé type que lobjet courant. MakeEverySerializableCl Une classe serialisable doit être entièrement composée de classe Déconseillé assComponentsSerializa sérialisable ble PreferNotifyAlltoNotifyMe Il est recommandé dutiliser la méthode <code>notifyAll()</code> plutôt Déconseillé thod que la méthode <code>notify()</code>. PreserveStackTraceWhe Une exception lancée à partir dune autre exception devrait toujours Déconseillé nThrowingNewException stocker la pile derreur originale. ProvideStaticMethodFor Une classe qui ne peut pas être instanciée doit disposer de méthodes Déconseillé NonInstantiableClasses statiques. UseInterfaceRatherThan Il est préférable de raisonner sur des interfaces génériques plutôt que sur Déconseillé LowClasses leurs implémentations UseStringSplitRatherTha <code>StringTokenizer</code> est en passe de devenir deprecated. Il faut Déconseillé nStringTokenizer donc maintenant utiliser <code>String.split</code> UselessDeclarationOfRu Il est inutile de définir <code>RuntimeException</code> parmi les Déconseillé nTimeException exceptions que peut lancer une méthode. AlwaysDeclareFinalField Un attribut immuable déclaré final et dont la valeur est affectée à la A éviter sStatic déclaration devrait être déclaré statique. DeclareBiggerStringBuffe Un <code>StringBuffer</code> devrait être instancié avec un capacité A éviter rThanNeeded suffisante pour le contenu qui lui sera ajouté. DontDeclareMoreThanO Il est déconseillé de définir plusieurs instructions sur une même ligne. A éviter neStatementPerLine DontDirectlyReturnArray Lorsquune méthode retourne un attribut de lobjet qui est de type A éviter tableau, il est préférable de retourner une copie du tableau plutôt que la référence directe. DontDirectlyStoreArray Stocker directement un tableau reçu en paramètre dans un attribut ne A éviter permet pas de garder le contrôle exclusif de lattribut du fait quil reste toujours modifiable par les autres classes.Confidentiel - Ce document est la propriété de Kalistick 56/58
  • 57. Audit de code de l’application IceScrum2 10/02/2011 DontLeaveEmptyFinallyB Un bloc finally ne doit pas être laissé vide. A éviter locks DontLeaveEmptyInitialize Un bloc dinitialisation statique vide devrait être supprimé. A éviter r DontLeaveEmptyLoops Il ne faut jamais laisser une boucle vide. A éviter DontLeaveEmptyMethod Une méthode vide devrait être commentée. A éviter s DontLeaveEmptySynchro Un bloc synchronized ne doit jamais être vide A éviter nizedBlocks DontLeaveEmptyTryBloc Un bloc try ne devrait jamais être vide A éviter ks DontLeaveUnusedLocalV Il ne faut pas laisser des variables locales inutilisées A éviter ariables DontLeaveUnusedPrivat Un attribut privé qui nest pas utilisé dans la classe doit être A éviter eFields supprimée. DontLeaveUnusedPrivat Une méthode privée qui nest pas utilisée dans la classe doit être A éviter eMethods supprimée. DontNestTooManyCondit Il faut éviter dutiliser de trop nombreuses structures if imbriquées A éviter ionnalStatements DontUseForWithoutUpda Classiquement dans une boucle for, il y a une condition dupdate A éviter teClause DontUseInstanceToAcce Les méthodes et les champs statiques doivent être accédés à travers la A éviter ssStaticFieldsOrMethods classeet non une instance. DontUsePollingLoops Lutilisation de linstruction wait est beaucoup plus efficace quune boucle A éviter de test DontUseProtectedFieldsI Une classe final nétant pas dérivable, il est inutile dutiliser le mot clé A éviter nFinalClasses protected DontUseTooLongDotCha Ne pas utiliser des chaines de méthodes dans une seule instruction. A éviter inCallsInOneStatement ReturnEmptyArrayRather Il est préférable de retourner un tableau vide plutôt que la valeur A éviter ThanNull <code>null</code> SwitchCaseMustHaveDef Une instruction <code>switch<code> devrait toujours contenir le block A éviter aultStatement <code>default</code>. UselessConsecutiveLiter Il est préférable de regrouper plusieurs appels de A éviter alAppends <code>StringBuffer.append()</code> en un seul lorsque des chaînes constantes sont ajoutées. DontLeaveEmptyCtor Lorsquun constructeur est vide, il est préférable dinsérer un [Aucune] commentaire pour justifier sa définition. DontLeaveUnusedImp Les lignes dimport inutiles doivent être supprimées. [Aucune] orts UseBetterObjectCollec Il est préférable dutiliser des objets <code>Collection</code> [Aucune] tion optimisés plutôt que des tableaux dobjetsConfidentiel - Ce document est la propriété de Kalistick 57/58
  • 58. Audit de code de l’application IceScrum2 10/02/2011 8.4.2 Seuils de couverture de code Le tableau suivant présente les seuils de couverture de code attendus selon la priorité de test des méthodes (TRI). Cette priorité de test est échelonnée selon cinq niveaux, en fonction d’intervalles de TRI : Priorité de test [ TRI Min. TRI Max.[ Seuil Sévérité Aucune 0 20 0 Pour information Basse 20 25 60% Pour information Moyenne 25 30 70% Pour information Haute 30 35 80% Pour information Critique 35 [Infini] 90% Pour informationConfidentiel - Ce document est la propriété de Kalistick 58/58

×