SlideShare une entreprise Scribd logo
DEMO
                  Application SHARPDEVELOP

                             Rapport d’audit
                                     01/01/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
Audit de code de l’application SharpDevelop                                                          01/01/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/61
Audit de code de l’application SharpDevelop                                                                                                         01/01/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
             4.3      Modélisation de l’application ............................................................................................................. 17
         5     Résultats détaillés....................................................................................................................................... 20
             5.1      Détail par axes de qualité ................................................................................................................... 20
             5.2      Implémentation .................................................................................................................................. 21
             5.3      Structure ............................................................................................................................................. 26
             5.4      Test ..................................................................................................................................................... 35
             5.5      Architecture ........................................................................................................................................ 42
             5.6      Duplication ......................................................................................................................................... 43
             5.7      Documentation................................................................................................................................... 44
         6     Plan d’action ............................................................................................................................................... 47
         7     Glossaire ..................................................................................................................................................... 49
         8     Annexes ...................................................................................................................................................... 51
             8.1      La complexité cyclomatique ............................................................................................................... 51
             8.2      Le couplage ......................................................................................................................................... 53
             8.3      Le TRI et TEI ........................................................................................................................................ 54
             8.4      Exigences techniques ......................................................................................................................... 56




Confidentiel - Ce document est la propriété de Kalistick                                                                                                                3/61
Audit de code de l’application SharpDevelop                                                                  01/01/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/61
Audit de code de l’application SharpDevelop                                                          01/01/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/61
Audit de code de l’application SharpDevelop                                                        01/01/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/61
Audit de code de l’application SharpDevelop                                                         01/01/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/61
Audit de code de l’application SharpDevelop                                                                  01/01/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 d'instructions. Cette mesure est différente du nombre de
                                                       ligne de code : elle n'inclut 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 d'une méthode. Elle mesure la complexité
                              méthodes                 algorithmique d'une 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 d'une 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 : 20




Confidentiel - Ce document est la propriété de Kalistick                                                                      8/61
Audit de code de l’application SharpDevelop                                                                  01/01/2011




         Domaine Règle                                Explication, objectif et seuils éventuels
                             Couverture de test des   Taux de couverture de code d'une 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 l'archive du projet.

                                                      Cette exigence associe un seuil minimal de test (couverture de code) à
                                                      chaque méthode de l'application selon le TRI (TestRelevancyIndex) ; le TRI
                                                      évalue pour chaque méthode le risque qu'elle contienne des bugs. Son
                                                      calcul tient compte des risques métiers définis pour l'application.
             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        d'entête de documentation. Les méthodes prises en compte sont celles
             Documentation




                             méthodes                 dont la complexité cyclomatique et le nombre d'instructions 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/61
Audit de code de l’application SharpDevelop                                                     01/01/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/61
Audit de code de l’application SharpDevelop                                                         01/01/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é                159             283              42%
                               Evolutivité               429            1794              84%
                               Fiabilité                 425            1925              84%
                               Maintenabilité            54              339              18%
                               Sécurité                   0               0               0%
                               Transférabilité           51              180              25%
                               [Total]                   480            2286              87%




                      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/61
Audit de code de l’application SharpDevelop                                                       01/01/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                        70895     +0,14%
                                         Nombre d'instructions                   48877     +0,15%
                                         Nombre de méthodes                       7568     +0,36%
                                         Nombre de classes                        975      +0,21%
                                         Nombre de packages                        48         =



                                                           Voir sur le Cockpit Qualité




                      Une « ligne » correspond à une ligne physique d'un 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/61
Audit de code de l’application SharpDevelop                                                      01/01/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/61
Audit de code de l’application SharpDevelop                                                       01/01/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/61
Audit de code de l’application SharpDevelop                                                    01/01/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/61
Audit de code de l’application SharpDevelop                                                           01/01/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                   20,31      10,48           10,9               6 - 26
               Méthodes par classe                    7,76       7,78           7,58               4 - 10
               Lignes de code par méthode             6,46      12,76          10,85               7 - 13
               Complexité par ligne de code           0,31       0,22           0,15            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).pdf

Confidentiel - Ce document est la propriété de Kalistick                                                                16/61
Audit de code de l’application SharpDevelop                                                         01/01/2011


         4.3 Modélisation de l’application
         Pour faciliter la restitution des résultats d’analyse, l’application est modélisée sous deux angles: un angle
         fonctionnel pour mieux identifier les fonctionnalités métier de l’application et les rattacher au code, et un
         angle technique pour vérifier l’architecture technique de l’application.

         Ces modèles sont construits à l’aide de l’assistant de modélisation disponible au sein du Cockpit. Vous
         pouvez modifier ces modèles sur les pages Modélisation fonctionelle             et Architecture technique     (selon
         vos droits utilisateurs).


         4.3.1 Modèle fonctionnel
         Le modèle fonctionnelle représente la vue métier de l’application, compréhensible par l’ensemble des
         acteurs du projet.




                                                           Voir sur le Cockpit Qualité




                        Le modèle fonctionnel est constitué de « modules » qui représente chacun une
                fonctionnalité métier, ou un groupe de fonctionnalité. Ces modules ont été identifiés à partir d’un
                corpus lexical généré à partir du code de l’application et qui permet d’isoler le vocabulaire métier
                de l’application.




Confidentiel - Ce document est la propriété de Kalistick                                                             17/61
Audit de code de l’application SharpDevelop                                                       01/01/2011


         4.3.2 Modèle technique
         Le modèle technique représente l’architecture du code de l’application. Le principe consiste à définir un
         modèle d’architecture cible, qui identifie des couches et/ou des composants techniques 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 d'une application. Par exemple s'assurer 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 d'autres applications. Les cycles de dépendances
                  sont par exemple proscrits.

                 Eviter les failles de sécurité en s'assurant par exemple que des appels directs vers une couche
                  d'accès aux données ne sont jamais réalisés sans passer par une couche métier qui serait
                  responsable de contrôles de validation

         Le résultat de l’analyse des contraintes d’architecture est présenté dans le chapitre 5.5 Architecture.




Confidentiel - Ce document est la propriété de Kalistick                                                           18/61
Audit de code de l’application SharpDevelop                                                  01/01/2011


                                                           Voir sur le Cockpit Qualité




                        Les flèches vertes formalisent des communications autorisées entre modules, tandis que
                les flèches rouges formalisent des communications proscrites.




Confidentiel - Ce document est la propriété de Kalistick                                                     19/61
Audit de code de l’application SharpDevelop                                                 01/01/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                                                    20/61
Audit de code de l’application SharpDevelop                                                       01/01/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                                                           21/61
Audit de code de l’application SharpDevelop                                                    01/01/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                             382          5         0          0
                          Fortement déconseillé                176          1         0         55
                          Déconseillé                           81          5         2        336
                          A éviter                             202          1         1        340




                      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.




Confidentiel - Ce document est la propriété de Kalistick                                                       22/61
Audit de code de l’application SharpDevelop                                                             01/01/2011


         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.

         5.2.2.1 Pratiques interdites


          Pratique                                                               Nouvelles   Violations Classes        %
                                                                                                          NC      application
          AvoidRedundantCasts                                                            1      124       83         29%
          ImplementIDisposableForTypesWithDisposableFields                               0      103       64         13%
          DontHardcodeLocaleSpecificStrings                                              2       81       56         14%
          UseConstInsteadOfReadOnlyWhenPossible_                                         0       33       10          4%
          UseIsNullOrEmptyToCheckEmptyStrings                                            0       12        9          4%
          OverrideEqualsWithOperatorOnValueTypes                                         0       11       11          4%
          PropertyNamesMustNotMatchGetMethods                                            0       6         5          1%
          InstantiateExceptionsWithArguments                                             0       5         4          2%
          DontImplementWriteOnlyProperty                                                 0       3         3          1%
          DefineMessageForObsoleteAttribute                                              2       2         2          1%
          DontUseInadvisableTypes                                                        0       1         1          1%
          DontRaiseExceptionInUnexpectedMethod_                                          0       1         1          1%



                                                           Voir sur le Cockpit Qualité




Confidentiel - Ce document est la propriété de Kalistick                                                                 23/61
Audit de code de l’application SharpDevelop                                                            01/01/2011


         5.2.2.2 Pratiques fortement déconseillées


             Pratique                                                          Nouvelles Violations   Classes        %
                                                                                                        NC      application
             NeverMakeCtorCallOverridableMethod                                      0      185         48         10%
             DontUseNonConstantStaticVisibleFields                                   1      26          11          3%
             OverrideMethodsInIComparableImplementations                             0       9           6          2%
             DefineAttributeForISerializableTypes                                    0       7           5          3%
             DontNestGenericInMemberSignatures_                                      0       3           2          2%
             DontIgnoreMethodsReturnValue                                            0       1           1          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                                                                24/61
Audit de code de l’application SharpDevelop                                                             01/01/2011


         5.2.3.1 Classes avec des pratiques interdites


          Classe                                                                     NC    Nouvelles Violations Instructions
          ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefa                      Oui      0          10         647
          ctoryResolver
          ICSharpCode.SharpDevelop.Dom.VBNet.VBExpressionFinder                      Oui      0          10         319
          ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpressionFi                     Oui      0          10         600
          nder
          ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.SharpD                   Oui      0           9         255
          evelopTextAreaControl
          ICSharpCode.SharpDevelop.Gui.DefaultWorkbench                              Oui      0           8         387
          ICSharpCode.SharpDevelop.Project.ConfigurationGuiHelper                    Oui      1           8          0
          ICSharpCode.SharpDevelop.Widgets.TreeGrid.DynamicListIt                    Oui      0           8         211
          em
          ICSharpCode.SharpDevelop.ParserService                                     Oui      0           7         489
          ICSharpCode.SharpDevelop.Gui.SdiWorkbenchLayout                            Oui      0           7         360
          ICSharpCode.SharpDevelop.Dom.DomPersistence                                Oui      0           6         567
          ICSharpCode.Core.MenuService                                               Oui      0           6         78
          ICSharpCode.SharpDevelop.Dom.DefaultProjectContent                         Oui      0           5         554
          ICSharpCode.SharpDevelop.Gui.XmlForms.XmlLoader                            Oui      0           5         200
          ICSharpCode.SharpDevelop.Refactoring.RefactoringService                    Oui      0           5         312
          ICSharpCode.SharpDevelop.Project.ProjectService                            Oui      0           5         355
          ICSharpCode.SharpDevelop.Project.MSBuildEngine                             Oui      0           5         337
          ICSharpCode.SharpDevelop.Gui.FontSelectionPanelHelper                      Oui      0           5         101
          ICSharpCode.SharpDevelop.Project.Commands.AddExistingIt                    Oui      0           4         168
          emsToProject
          ICSharpCode.SharpDevelop.Debugging.DebuggerService                         Oui      0           4         288



                                                           Voir sur le Cockpit Qualité




Confidentiel - Ce document est la propriété de Kalistick                                                               25/61
Audit de code de l’application SharpDevelop                                                               01/01/2011


         5.2.3.2 Classes avec des pratiques fortement déconseillées


      Classe                                                                             NC    Nouvelles   Violations Instructions
      ICSharpCode.SharpDevelop.Gui.ExtTreeNode                                           Oui      0            69         248
      ICSharpCode.SharpDevelop.Gui.ClassBrowser.MemberNode                               Oui      0            12          72
      ICSharpCode.SharpDevelop.Gui.XmlForms.XmlForm                                      Oui      0            12          22
      ICSharpCode.SharpDevelop.Dom.HostCallback                                          Oui      1            9           19
      ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionClass                       Oui      0            8          102
      ICSharpCode.SharpDevelop.Dom.ExpressionContext                                     Oui      0            6          142
      ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionMethod                      Oui      0            5           41
      ICSharpCode.SharpDevelop.Project.Dialogs.NewProjectDialog                          Oui      0            4          274
      ICSharpCode.SharpDevelop.Project.FileNode                                          Oui      0            4          155
      ICSharpCode.SharpDevelop.Gui.NewFileDialog                                         Oui      0            3          378
      ICSharpCode.SharpDevelop.Project.ProjectNode                                       Oui      0            3          114
      ICSharpCode.SharpDevelop.Dom.DefaultEvent                                          Oui      0            3           43
      ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionParame                      Oui      0            3           14
      ter
      ICSharpCode.SharpDevelop.Dom.DefaultProperty                                       Oui      0            3          62
      ICSharpCode.SharpDevelop.Dom.DefaultMethod                                         Oui      0            3          84
      ICSharpCode.SharpDevelop.Dom.DefaultProjectContent                                 Oui      0            2          554
      ICSharpCode.SharpDevelop.Internal.Templates.FileTemplate                           Oui      0            2          124
      ICSharpCode.SharpDevelop.Dom.DefaultParameter                                      Oui      0            2          76
      ICSharpCode.Core.MenuCommand                                                       Oui      0            2          85



                                                           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,
         testé, 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                                                                  26/61
Audit de code de l’application SharpDevelop                                                      01/01/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                                                         27/61
Audit de code de l’application SharpDevelop                                                                    01/01/2011


                                        Anomalie                                          Violation Nouvelles    Violations   NC
                                                                                              s     violations   corrigées
                                                                                         impactant
                                                                                             es
          Complexité cyclomatique supérieure à 20                                            41          1           0        5%
                                                           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                                                                      28/61
Audit de code de l’application SharpDevelop                                                               01/01/2011


      Méthode                                                                            Instructions   Lignes   Complexité Nouvelle
                                                                                                                            violation



         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.

         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 :


         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                                                                     29/61
Audit de code de l’application SharpDevelop                                               01/01/2011


      Méthode                                                       Instructions   Lignes   Complexité Nouvelle
                                                                                                       violation
      ICSharpCode.SharpDevelop.Dom.ReflectionLayer.Reflection           21          36         21       Nouvelle
      Class.InitMembers ( System.Type)
      ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.Con               53          77         83
      versionExists (
      ICSharpCode.SharpDevelop.Dom.IReturnType,
      ICSharpCode.SharpDevelop.Dom.IReturnType)
      ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression              57          78         47
      Finder.SearchBracketForward ( System.String, System.Int32,
      System.Char, System.Char)
      ICSharpCode.SharpDevelop.Dom.VBNet.VBNetAmbience.C                81          128        44
      onvert ( ICSharpCode.SharpDevelop.Dom.IClass)
      ICSharpCode.SharpDevelop.Dom.CSharp.CSharpAmbience.               77          118        41
      Convert ( ICSharpCode.SharpDevelop.Dom.IClass)
      ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRef              71          100        34
      actoryResolver.ResolveInternal (
      ICSharpCode.NRefactory.Ast.Expression,
      ICSharpCode.SharpDevelop.Dom.ExpressionContext)
      ICSharpCode.SharpDevelop.Widgets.SideBar.SideBarContro            81          97         32
      l.ProcessCmdKey ( ref System.Windows.Forms.Message,
      System.Windows.Forms.Keys)
      ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.Get               20          22         31
      BetterPrimitiveConversion (
      ICSharpCode.SharpDevelop.Dom.IReturnType,
      ICSharpCode.SharpDevelop.Dom.IReturnType)
      ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.Type              53          73         31
      Visitor.CreateReturnType (
      ICSharpCode.NRefactory.Ast.TypeReference,
      ICSharpCode.SharpDevelop.Dom.IClass,
      ICSharpCode.SharpDevelop.Dom .IMember, System.Int32,
      System.Int32,
      ICSharpCode.SharpDevelop.Dom.IProjectContent,
      System.Boolean)
      ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass.Ini           57          83         30
      tMembers ( Mono.Cecil.TypeDefinition)
      ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.MethodI         42          59         29
      nsightDataProvider.SetupDataProvider ( System.String,
      ICSharpCode.TextEditor.Document.IDocument,
      ICSharpCode.SharpDevelop.Dom.ExpressionResult,
      System.Int32, System.Int32)
      ICSharpCode.SharpDevelop.Refactoring.RefactoringService.          55          89         29
      AddReferences (
      System.Collections.Generic.List<ICSharpCode.SharpDevelop
      .Refactoring.Reference>,
      ICSharpCode.SharpDevelop.Dom.IClass,
      ICSharpCode.SharpDevelop.Dom.IMember, System.Boolean,
      System.String, System.String)
      ICSharpCode.SharpDevelop.Project.DirectoryNode.Initialize (       81          121        29
      )
      ICSharpCode.SharpDevelop.Project.MSBuildBasedProject.S            92          140        28
      etPropertyInternal ( System.String, System.String,
      System.String, System.String,
      ICSharpCode.SharpDevelop.Project.PropertyStorageLocation
      s, System.Boolean)


Confidentiel - Ce document est la propriété de Kalistick                                                 30/61
Audit de code de l’application SharpDevelop                                                     01/01/2011


      ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRef                53            81           28
      actoryResolver.ResolveIdentifierInternal ( System.String)
      ICSharpCode.SharpDevelop.Commands.ToolMenuBuilder.To                54            74           26
      olEvt ( System.Object, System.EventArgs)
      ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.Get                 32            51           26
      BetterFunctionMember (
      ICSharpCode.SharpDevelop.Dom.IReturnType[],
      ICSharpCode.SharpDevelop.Dom.IMethodOrProperty,
      ICSharpCode.SharpDevelop.Dom.IReturnType[],
      System.Boolean,
      ICSharpCode.SharpDevelop.Dom.IMethodOrProperty,
      ICSharpCode.SharpDevelop.Dom.IReturnType[],
      System.Boolean)
      ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression                51            68           26
      Finder.FindFullExpression ( System.String, System.Int32)
      ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression                58            76           25
      Finder.ReadNextToken ( )




         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                                                        31/61
Audit de code de l’application SharpDevelop                                                     01/01/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                                                         32/61
Audit de code de l’application SharpDevelop                                                 01/01/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 :




Confidentiel - Ce document est la propriété de Kalistick                                                    33/61
Audit de code de l’application SharpDevelop                                          01/01/2011


         Méthode                                                           Couplage   Complexité   Nouvelle
                                                                           efférent                violation
         ICSharpCode.SharpDevelop.Refactoring.RefactoringMenuBuilder.Build    45         22
         Submenu ( ICSharpCode.Core.Codon, System.Object)
         ICSharpCode.SharpDevelop.Project.Commands.AddExistingItemsToP        39         22
         roject.Run ( )
         ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass.InitMember       36         30
         s ( Mono.Cecil.TypeDefinition)
         ICSharpCode.SharpDevelop.Gui.NewFileDialog.OpenEvent (               35         17
         System.Object, System.EventArgs)
         ICSharpCode.SharpDevelop.Commands.ToolMenuBuilder.ToolEvt (          32         26
         System.Object, System.EventArgs)
         ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryRes        31         34
         olver.ResolveInternal ( ICSharpCode.NRefactory.Ast.Expression,
         ICSharpCode.SharpDevelop.Dom.ExpressionContext)
         ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.MethodInsightDat   30         29
         aProvider.SetupDataProvider ( System.String,
         ICSharpCode.TextEditor.Document.IDocument,
         ICSharpCode.SharpDevelop.Dom.ExpressionResult, System.Int32,
         System.Int32)
         ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryRes        30         18        Nouvelle
         olver.CtrlSpace ( System.Int32, System.Int32, System.String,
         System.String, ICSharpCode.SharpDevelop.Dom.ExpressionContext)
         ICSharpCode.SharpDevelop.DefaultEditor.Commands.ClassBookmark        29         19
         MenuBuilder.BuildSubmenu ( ICSharpCode.Core.Codon,
         System.Object)
         ICSharpCode.SharpDevelop.Project.MSBuildEngine.BuildRun.ParseS       29         19
         olution ( Microsoft.Build.BuildEngine.Project)
         ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryRes        28         28
         olver.ResolveIdentifierInternal ( System.String)
         ICSharpCode.SharpDevelop.Dom.CecilReader.CreateType (                28         21
         ICSharpCode.SharpDevelop.Dom.IProjectContent,
         ICSharpCode.SharpDevelop.Dom.IDecoration,
         Mono.Cecil.TypeReference)
         ICSharpCode.SharpDevelop.Project.ProjectService.LoadProject (        27         15
         System.String)
         ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.TypeVisitor.Cre      26         31
         ateReturnType ( ICSharpCode.NRefactory.Ast.TypeReference,
         ICSharpCode.SharpDevelop.Dom.IClass,
         ICSharpCode.SharpDevelop.Dom.IMember, System.Int32,
         System.Int32, ICSharpCode.SharpDevelop.Dom.IProjectContent,
         System.Boolean)
         ICSharpCode.SharpDevelop.Project.DirectoryNode.Initialize ( )        26         29
         ICSharpCode.SharpDevelop.Widgets.TreeGrid.DynamicList.OnPaint (      26         21
         System.Windows.Forms.PaintEventArgs)
         ICSharpCode.SharpDevelop.Project.Dialogs.NewProjectDialog.OpenE      26         20
         vent ( System.Object, System.EventArgs)
         ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass (                26         15
         ICSharpCode.SharpDevelop.Dom.ICompilationUnit,
         ICSharpCode.SharpDevelop.Dom.IClass, Mono.Cecil.TypeDefinition,
         System.String).CecilClass (
         ICSharpCode.SharpDevelop.Dom.ICompilationUnit,
         ICSharpCode.SharpDevelop.Dom.IClass, Mono.Cecil.TypeDefinition,
         System.String)
         ICSharpCode.SharpDevelop.Gui.GotoDialog.TextBoxTextChanged (         25         18
         System.Object, System.EventArgs)


Confidentiel - Ce document est la propriété de Kalistick                                              34/61
Audit de code de l’application SharpDevelop                                                       01/01/2011


                                                           Voir sur le Cockpit Qualité




         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.




Confidentiel - Ce document est la propriété de Kalistick                                                           35/61
Audit de code de l’application SharpDevelop                                                                     01/01/2011


         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.


         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)



         6
             CETIC, Kalistick. Statistically Calibrated Indexes for Unit Test Relevancy and Unit Test Writing Effort, 2010

Confidentiel - Ce document est la propriété de Kalistick                                                                          36/61
Audit de code de l’application SharpDevelop                                                         01/01/2011


                 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é)




         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         1373              0
                                  Haute                    0          515              0
                                  Moyenne                  0          10               0
                                  Basse                    0          14               0
                                  Aucune                   0         5656              0
                                  [Total]                  0         7568              0
                                                           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 d'instructions
                 la couleur, qui représente l'écart par rapport à l'objectif 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 atteint



Confidentiel - Ce document est la propriété de Kalistick                                                             37/61
Audit de code de l’application SharpDevelop                                                       01/01/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 à l'objectif de couverture fixé pour la classe, tout comme
                  pour le TreeMap précédent




Confidentiel - Ce document est la propriété de Kalistick                                                          38/61
Audit de code de l’application SharpDevelop                                                        01/01/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 à l'objectif de couverture fixé pour la classe, tout comme
                  pour le TreeMap ou les QuickWins




Confidentiel - Ce document est la propriété de Kalistick                                                           39/61
Audit de code de l’application SharpDevelop                                                   01/01/2011




                                                           Voir sur le Cockpit Qualité




         5.4.7 Méthodes à tester en priorité
         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                                                       40/61
Audit de code de l’application SharpDevelop                                         01/01/2011


     Méthode                                            Couverture Pertinence Priorité     Effort     Nouvelle
                                                                      (TRI)                           violation
     ICSharpCode.SharpDevelop.Refactoring.RefactoringM     0%        37.00    Critique     Elevé
     enuBuilder.BuildSubmenu ( ICSharpCode.Core.Codon,
     System.Object)
     ICSharpCode.SharpDevelop.Project.Solution.SetupSol    0%        37.00    Critique   Très élevé
     ution ( ICSharpCode.SharpDevelop.Project.Solution,
     System.String)
     ICSharpCode.SharpDevelop.Project.MSBuildBasedProj     0%        37.00    Critique   Très élevé
     ect.SetPropertyInternal ( System.String,
     System.String, System.String, System.String,
     ICSharpCode.SharpDevelop.Project.PropertyStorageL
     ocations, System.Boolean)
     ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.      0%        37.00    Critique   Très élevé
     NRefactoryResolver.ResolveIdentifierInternal (
     System.String)
     ICSharpCode.SharpDevelop.Commands.SharpDevelop        0%        36.00    Critique     Elevé
     StringTagProvider.Convert ( System.String)
     ICSharpCode.Core.AddInTree.Load (                     0%        36.00    Critique     Elevé
     System.Collections.Generic.List<System.String>,
     System.Collections.Generic.List<System.String>)
     ICSharpCode.SharpDevelop.Project.Commands.AddEx       0%        36.00    Critique     Elevé
     istingItemsToProject.Run ( )
     ICSharpCode.SharpDevelop.Dom.CecilReader.CreateT      0%        35.00    Critique     Elevé
     ype (
     ICSharpCode.SharpDevelop.Dom.IProjectContent,
     ICSharpCode.SharpDevelop.Dom.IDecoration,
     Mono.Cecil.TypeReference)
     ICSharpCode.SharpDevelop.Commands.ToolMenuBuil        0%        35.00    Critique     Elevé
     der.ToolEvt ( System.Object, System.EventArgs)
     ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.    0%        35.00    Critique   Très élevé
     MethodInsightDataProvider.SetupDataProvider (
     System.String,
     ICSharpCode.TextEditor.Document.IDocument,
     ICSharpCode.SharpDevelop.Dom.ExpressionResult,
     System.Int32, System.Int32)
     ICSharpCode.SharpDevelop.Refactoring.RefactoringSe    0%        35.00    Critique     Elevé
     rvice.AddReferences (
     System.Collections.Generic.List<ICSharpCode.SharpD
     evelop.Refactoring.Reference>,
     ICSharpCode.SharpDevelop.Dom.IClass,
     ICSharpCode.SharpDevelop.Dom.IMember,
     System.Boolean, System.String, System.String)
     ICSharpCode.SharpDevelop.Dom.ReflectionLayer.Refl     0%        35.00    Critique     Elevé
     ectionReturnType.Create (
     ICSharpCode.SharpDevelop.Dom.IProjectContent,
     ICSharpCode.SharpDevelop.Dom.IDecoration,
     System.Type, System.Boolean)




Confidentiel - Ce document est la propriété de Kalistick                                              41/61
Audit de code de l’application SharpDevelop                                                            01/01/2011


     ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.                        0%          35.00   Critique   Très élevé
     NRefactoryResolver.ResolveInternal (
     ICSharpCode.NRefactory.Ast.Expression,
     ICSharpCode.SharpDevelop.Dom.ExpressionContext)
     ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.                        0%          35.00   Critique   Très élevé
     TypeVisitor.CreateReturnType (
     ICSharpCode.NRefactory.Ast.TypeReference,
     ICSharpCode.SharpDevelop.Dom.IClass,
     ICSharpCode.SharpDevelop.Dom.IMember,
     System.Int32, System.Int32,
     ICSharpCode.SharpDevelop.Dom.IProjectContent,
     System.Boolean)
     ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpre                         0%          35.00   Critique     Elevé
     ssionFinder.SearchBracketForward ( System.String,
     System.Int32, System.Char, System.Char)
     ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.A                     0%          35.00   Critique     Elevé
     bstractCodeCompletionDataProvider.CreateItem (
     System.Object,
     ICSharpCode.SharpDevelop.Dom.ExpressionContext)
     ICSharpCode.SharpDevelop.Project.MSBuildEngine.Bu                       0%          34.00   Critique    Normal
     ildRun.ParseSolution (
     Microsoft.Build.BuildEngine.Project)
     ICSharpCode.SharpDevelop.Project.ProjectService.Loa                     0%          34.00   Critique     Elevé
     dProject ( System.String)
     ICSharpCode.SharpDevelop.Project.ProjectBrowserCo                       0%          34.00   Critique     Elevé
     ntrol.FindDeepestOpenNodeForPath ( System.String)
                                                           Voir sur le Cockpit Qualité




         5.5 Architecture
         Le domaine Architecture vise à contrôler le respect d’un modèle d’architecture logicielle. Le modèle
         d’architecture cible a été présenté dans le chapitre 4.3.2 Modèle technique. Le schéma suivant montre les
         résultats de l’analyse des contraintes d’architecture en comparant ce modèle cible avec le code de
         l’application.


                      Actuellement, les violations des contraintes d’architecture ne sont pas prises en compte
                dans le calcul de la non-conformité de l’application.




Confidentiel - Ce document est la propriété de Kalistick                                                                 42/61
Audit de code de l’application SharpDevelop                                                       01/01/2011




                                                           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 oranges 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                                                          43/61
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#

Contenu connexe

Tendances

Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnels
cvcby
 
Test logiciel
Test logicielTest logiciel
Test logiciel
Youness Boukouchi
 
Présentation Agile Testing
Présentation Agile TestingPrésentation Agile Testing
Présentation Agile Testing
jubehr
 
White paper" La DO-254 pour les nuls"
White paper" La DO-254 pour les nuls"White paper" La DO-254 pour les nuls"
White paper" La DO-254 pour les nuls"
SILKAN
 
Test de logiciels
Test de logiciels Test de logiciels
Test de logiciels
Bilel Abed
 
Qualité logiciel - Generalités
Qualité logiciel - GeneralitésQualité logiciel - Generalités
Qualité logiciel - Generalités
Christophe Rochefolle
 
Dmap Ip Do254 White Paper
Dmap Ip Do254 White PaperDmap Ip Do254 White Paper
Dmap Ip Do254 White Paper
DMAP
 
Rpc12263 r7 final thème 5 dee ete conf aimcc 12 09 12
Rpc12263 r7 final thème 5 dee ete conf aimcc 12 09 12Rpc12263 r7 final thème 5 dee ete conf aimcc 12 09 12
Rpc12263 r7 final thème 5 dee ete conf aimcc 12 09 12
satanbaal
 
Présentation Tests Fonctionnels
Présentation Tests FonctionnelsPrésentation Tests Fonctionnels
Présentation Tests Fonctionnels
DATANYWARE.com
 
20120124 05 - Le Model-based Testing aujourd'hui (Inria)
20120124 05 - Le Model-based Testing aujourd'hui (Inria)20120124 05 - Le Model-based Testing aujourd'hui (Inria)
20120124 05 - Le Model-based Testing aujourd'hui (Inria)
LeClubQualiteLogicielle
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
Maintenance logicielle
Maintenance logicielleMaintenance logicielle
Maintenance logicielle
Nicolas Anquetil
 
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
LeClubQualiteLogicielle
 
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logicielsAccélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
kalistick
 
20111004 02 - Présentation Sqale
20111004 02 - Présentation Sqale20111004 02 - Présentation Sqale
20111004 02 - Présentation Sqale
LeClubQualiteLogicielle
 
Keynote Retmo2018 : le test QA et UAT en méthode agile
Keynote Retmo2018 : le test QA et UAT en méthode agileKeynote Retmo2018 : le test QA et UAT en méthode agile
Keynote Retmo2018 : le test QA et UAT en méthode agile
StardustTesting
 
QSOS 2.0 Solutions Linux 2009
QSOS 2.0 Solutions Linux 2009QSOS 2.0 Solutions Linux 2009
QSOS 2.0 Solutions Linux 2009
Raphaël Semeteys
 
Exigences de qualité des systèmes / logiciels
Exigences de qualité des systèmes / logicielsExigences de qualité des systèmes / logiciels
Exigences de qualité des systèmes / logiciels
Pierre
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
Mohammed Amine Mostefai
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
Nicolas Fédou
 

Tendances (20)

Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnels
 
Test logiciel
Test logicielTest logiciel
Test logiciel
 
Présentation Agile Testing
Présentation Agile TestingPrésentation Agile Testing
Présentation Agile Testing
 
White paper" La DO-254 pour les nuls"
White paper" La DO-254 pour les nuls"White paper" La DO-254 pour les nuls"
White paper" La DO-254 pour les nuls"
 
Test de logiciels
Test de logiciels Test de logiciels
Test de logiciels
 
Qualité logiciel - Generalités
Qualité logiciel - GeneralitésQualité logiciel - Generalités
Qualité logiciel - Generalités
 
Dmap Ip Do254 White Paper
Dmap Ip Do254 White PaperDmap Ip Do254 White Paper
Dmap Ip Do254 White Paper
 
Rpc12263 r7 final thème 5 dee ete conf aimcc 12 09 12
Rpc12263 r7 final thème 5 dee ete conf aimcc 12 09 12Rpc12263 r7 final thème 5 dee ete conf aimcc 12 09 12
Rpc12263 r7 final thème 5 dee ete conf aimcc 12 09 12
 
Présentation Tests Fonctionnels
Présentation Tests FonctionnelsPrésentation Tests Fonctionnels
Présentation Tests Fonctionnels
 
20120124 05 - Le Model-based Testing aujourd'hui (Inria)
20120124 05 - Le Model-based Testing aujourd'hui (Inria)20120124 05 - Le Model-based Testing aujourd'hui (Inria)
20120124 05 - Le Model-based Testing aujourd'hui (Inria)
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Maintenance logicielle
Maintenance logicielleMaintenance logicielle
Maintenance logicielle
 
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
 
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logicielsAccélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
 
20111004 02 - Présentation Sqale
20111004 02 - Présentation Sqale20111004 02 - Présentation Sqale
20111004 02 - Présentation Sqale
 
Keynote Retmo2018 : le test QA et UAT en méthode agile
Keynote Retmo2018 : le test QA et UAT en méthode agileKeynote Retmo2018 : le test QA et UAT en méthode agile
Keynote Retmo2018 : le test QA et UAT en méthode agile
 
QSOS 2.0 Solutions Linux 2009
QSOS 2.0 Solutions Linux 2009QSOS 2.0 Solutions Linux 2009
QSOS 2.0 Solutions Linux 2009
 
Exigences de qualité des systèmes / logiciels
Exigences de qualité des systèmes / logicielsExigences de qualité des systèmes / logiciels
Exigences de qualité des systèmes / logiciels
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
 

En vedette

Développement sécurisé d'applications avec Zend Framework
Développement sécurisé d'applications avec Zend FrameworkDéveloppement sécurisé d'applications avec Zend Framework
Développement sécurisé d'applications avec Zend Framework
Mickael Perraud
 
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014 Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Patrick Leclerc
 
Introduction à Zend Framework 2
Introduction à Zend Framework 2Introduction à Zend Framework 2
Introduction à Zend Framework 2
Mickael Perraud
 
Techdays 2012 : Mise en place d'une démarche ALM avec Visual Studio pour Wind...
Techdays 2012 : Mise en place d'une démarche ALM avec Visual Studio pour Wind...Techdays 2012 : Mise en place d'une démarche ALM avec Visual Studio pour Wind...
Techdays 2012 : Mise en place d'une démarche ALM avec Visual Studio pour Wind...
vlabatut
 
Présentation de DBAL en PHP (Nantes)
Présentation de DBAL en PHP (Nantes)Présentation de DBAL en PHP (Nantes)
Présentation de DBAL en PHP (Nantes)
Mickael Perraud
 
SonarQube et la Sécurité
SonarQube et la SécuritéSonarQube et la Sécurité
SonarQube et la Sécurité
Sébastien GIORIA
 
Modernisez le cycle fournisseurs: comment gagner en efficience et sérénité ?
Modernisez le cycle fournisseurs: comment gagner en efficience et sérénité ?Modernisez le cycle fournisseurs: comment gagner en efficience et sérénité ?
Modernisez le cycle fournisseurs: comment gagner en efficience et sérénité ?
Mazars
 
OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP Top10 2013 - Présentation aux RSSIA 2013OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP Top10 2013 - Présentation aux RSSIA 2013
Sébastien GIORIA
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
Rabia AZIZA
 

En vedette (9)

Développement sécurisé d'applications avec Zend Framework
Développement sécurisé d'applications avec Zend FrameworkDéveloppement sécurisé d'applications avec Zend Framework
Développement sécurisé d'applications avec Zend Framework
 
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014 Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
 
Introduction à Zend Framework 2
Introduction à Zend Framework 2Introduction à Zend Framework 2
Introduction à Zend Framework 2
 
Techdays 2012 : Mise en place d'une démarche ALM avec Visual Studio pour Wind...
Techdays 2012 : Mise en place d'une démarche ALM avec Visual Studio pour Wind...Techdays 2012 : Mise en place d'une démarche ALM avec Visual Studio pour Wind...
Techdays 2012 : Mise en place d'une démarche ALM avec Visual Studio pour Wind...
 
Présentation de DBAL en PHP (Nantes)
Présentation de DBAL en PHP (Nantes)Présentation de DBAL en PHP (Nantes)
Présentation de DBAL en PHP (Nantes)
 
SonarQube et la Sécurité
SonarQube et la SécuritéSonarQube et la Sécurité
SonarQube et la Sécurité
 
Modernisez le cycle fournisseurs: comment gagner en efficience et sérénité ?
Modernisez le cycle fournisseurs: comment gagner en efficience et sérénité ?Modernisez le cycle fournisseurs: comment gagner en efficience et sérénité ?
Modernisez le cycle fournisseurs: comment gagner en efficience et sérénité ?
 
OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP Top10 2013 - Présentation aux RSSIA 2013OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP Top10 2013 - Présentation aux RSSIA 2013
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 

Similaire à Analyse de code: accélérez la validation de vos applications C#

Tra optimiser preparation_tests_v1
Tra optimiser preparation_tests_v1Tra optimiser preparation_tests_v1
Tra optimiser preparation_tests_v1
SQLI
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
NoamHaythem
 
[FR] Récit Utilisateur ArianeGroup
[FR] Récit Utilisateur ArianeGroup[FR] Récit Utilisateur ArianeGroup
[FR] Récit Utilisateur ArianeGroup
Itris Automation Square
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
Sany_M
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
jkebbab
 
Présentation événement dette technologique micropole
Présentation événement dette technologique micropolePrésentation événement dette technologique micropole
Présentation événement dette technologique micropole
Micropole Group
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualité
soregh
 
20100121 01 - Présentation Renault
20100121 01 - Présentation Renault20100121 01 - Présentation Renault
20100121 01 - Présentation Renault
LeClubQualiteLogicielle
 
Conduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Conduite d'un projet informatique - Assurance Qualité et Aspects JuridiquesConduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Conduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Mohamed Sabra
 
[FR] Récit Utilisateur Industrie Pharmaceutique
[FR] Récit Utilisateur Industrie Pharmaceutique[FR] Récit Utilisateur Industrie Pharmaceutique
[FR] Récit Utilisateur Industrie Pharmaceutique
Itris Automation Square
 
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile? Et saura-t-elle f...
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile?  Et saura-t-elle f...ATMTL23 - La QA a-t-elle reussi à prendre le virage agile?  Et saura-t-elle f...
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile? Et saura-t-elle f...
Agile Montréal
 
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
qualimétrie logiciel -  Entreprise Software Analytic - nov 2015qualimétrie logiciel -  Entreprise Software Analytic - nov 2015
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
Julien Vq
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdf
mido04
 
20090609 04 - Calcul du ROI
20090609 04 - Calcul du ROI20090609 04 - Calcul du ROI
20090609 04 - Calcul du ROI
LeClubQualiteLogicielle
 
Diaporama AMDEC.pdf
Diaporama  AMDEC.pdfDiaporama  AMDEC.pdf
Diaporama AMDEC.pdf
foundiassana
 
Utc apm human talks compiegne
Utc apm human talks compiegneUtc apm human talks compiegne
Utc apm human talks compiegne
Arthur Van Ceulen
 
Tester les applications plus efficacement
Tester les applications plus efficacementTester les applications plus efficacement
Tester les applications plus efficacement
kalistick
 
chap6_GL.pptx
chap6_GL.pptxchap6_GL.pptx
chap6_GL.pptx
MOHAMEDAMINEKADRI4
 
[FR] Récit utilisateur inudstrie pharmaceutique
[FR] Récit utilisateur inudstrie pharmaceutique[FR] Récit utilisateur inudstrie pharmaceutique
[FR] Récit utilisateur inudstrie pharmaceutique
Itris Automation Square
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigences
Caroline de Villèle
 

Similaire à Analyse de code: accélérez la validation de vos applications C# (20)

Tra optimiser preparation_tests_v1
Tra optimiser preparation_tests_v1Tra optimiser preparation_tests_v1
Tra optimiser preparation_tests_v1
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
 
[FR] Récit Utilisateur ArianeGroup
[FR] Récit Utilisateur ArianeGroup[FR] Récit Utilisateur ArianeGroup
[FR] Récit Utilisateur ArianeGroup
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
 
Présentation événement dette technologique micropole
Présentation événement dette technologique micropolePrésentation événement dette technologique micropole
Présentation événement dette technologique micropole
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualité
 
20100121 01 - Présentation Renault
20100121 01 - Présentation Renault20100121 01 - Présentation Renault
20100121 01 - Présentation Renault
 
Conduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Conduite d'un projet informatique - Assurance Qualité et Aspects JuridiquesConduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Conduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
 
[FR] Récit Utilisateur Industrie Pharmaceutique
[FR] Récit Utilisateur Industrie Pharmaceutique[FR] Récit Utilisateur Industrie Pharmaceutique
[FR] Récit Utilisateur Industrie Pharmaceutique
 
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile? Et saura-t-elle f...
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile?  Et saura-t-elle f...ATMTL23 - La QA a-t-elle reussi à prendre le virage agile?  Et saura-t-elle f...
ATMTL23 - La QA a-t-elle reussi à prendre le virage agile? Et saura-t-elle f...
 
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
qualimétrie logiciel -  Entreprise Software Analytic - nov 2015qualimétrie logiciel -  Entreprise Software Analytic - nov 2015
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdf
 
20090609 04 - Calcul du ROI
20090609 04 - Calcul du ROI20090609 04 - Calcul du ROI
20090609 04 - Calcul du ROI
 
Diaporama AMDEC.pdf
Diaporama  AMDEC.pdfDiaporama  AMDEC.pdf
Diaporama AMDEC.pdf
 
Utc apm human talks compiegne
Utc apm human talks compiegneUtc apm human talks compiegne
Utc apm human talks compiegne
 
Tester les applications plus efficacement
Tester les applications plus efficacementTester les applications plus efficacement
Tester les applications plus efficacement
 
chap6_GL.pptx
chap6_GL.pptxchap6_GL.pptx
chap6_GL.pptx
 
[FR] Récit utilisateur inudstrie pharmaceutique
[FR] Récit utilisateur inudstrie pharmaceutique[FR] Récit utilisateur inudstrie pharmaceutique
[FR] Récit utilisateur inudstrie pharmaceutique
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigences
 

Analyse de code: accélérez la validation de vos applications C#

  • 1. DEMO Application SHARPDEVELOP Rapport d’audit 01/01/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 SharpDevelop 01/01/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/61
  • 3. Audit de code de l’application SharpDevelop 01/01/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 4.3 Modélisation de l’application ............................................................................................................. 17 5 Résultats détaillés....................................................................................................................................... 20 5.1 Détail par axes de qualité ................................................................................................................... 20 5.2 Implémentation .................................................................................................................................. 21 5.3 Structure ............................................................................................................................................. 26 5.4 Test ..................................................................................................................................................... 35 5.5 Architecture ........................................................................................................................................ 42 5.6 Duplication ......................................................................................................................................... 43 5.7 Documentation................................................................................................................................... 44 6 Plan d’action ............................................................................................................................................... 47 7 Glossaire ..................................................................................................................................................... 49 8 Annexes ...................................................................................................................................................... 51 8.1 La complexité cyclomatique ............................................................................................................... 51 8.2 Le couplage ......................................................................................................................................... 53 8.3 Le TRI et TEI ........................................................................................................................................ 54 8.4 Exigences techniques ......................................................................................................................... 56 Confidentiel - Ce document est la propriété de Kalistick 3/61
  • 4. Audit de code de l’application SharpDevelop 01/01/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/61
  • 5. Audit de code de l’application SharpDevelop 01/01/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/61
  • 6. Audit de code de l’application SharpDevelop 01/01/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/61
  • 7. Audit de code de l’application SharpDevelop 01/01/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/61
  • 8. Audit de code de l’application SharpDevelop 01/01/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 d'instructions. Cette mesure est différente du nombre de ligne de code : elle n'inclut 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 d'une méthode. Elle mesure la complexité méthodes algorithmique d'une 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 d'une 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 : 20 Confidentiel - Ce document est la propriété de Kalistick 8/61
  • 9. Audit de code de l’application SharpDevelop 01/01/2011 Domaine Règle Explication, objectif et seuils éventuels Couverture de test des Taux de couverture de code d'une 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 l'archive du projet. Cette exigence associe un seuil minimal de test (couverture de code) à chaque méthode de l'application selon le TRI (TestRelevancyIndex) ; le TRI évalue pour chaque méthode le risque qu'elle contienne des bugs. Son calcul tient compte des risques métiers définis pour l'application. 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 d'entête de documentation. Les méthodes prises en compte sont celles Documentation méthodes dont la complexité cyclomatique et le nombre d'instructions 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/61
  • 10. Audit de code de l’application SharpDevelop 01/01/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/61
  • 11. Audit de code de l’application SharpDevelop 01/01/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é 159 283 42% Evolutivité 429 1794 84% Fiabilité 425 1925 84% Maintenabilité 54 339 18% Sécurité 0 0 0% Transférabilité 51 180 25% [Total] 480 2286 87% 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/61
  • 12. Audit de code de l’application SharpDevelop 01/01/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 70895 +0,14% Nombre d'instructions 48877 +0,15% Nombre de méthodes 7568 +0,36% Nombre de classes 975 +0,21% Nombre de packages 48 = Voir sur le Cockpit Qualité Une « ligne » correspond à une ligne physique d'un 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/61
  • 13. Audit de code de l’application SharpDevelop 01/01/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/61
  • 14. Audit de code de l’application SharpDevelop 01/01/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/61
  • 15. Audit de code de l’application SharpDevelop 01/01/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/61
  • 16. Audit de code de l’application SharpDevelop 01/01/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 20,31 10,48 10,9 6 - 26 Méthodes par classe 7,76 7,78 7,58 4 - 10 Lignes de code par méthode 6,46 12,76 10,85 7 - 13 Complexité par ligne de code 0,31 0,22 0,15 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).pdf Confidentiel - Ce document est la propriété de Kalistick 16/61
  • 17. Audit de code de l’application SharpDevelop 01/01/2011 4.3 Modélisation de l’application Pour faciliter la restitution des résultats d’analyse, l’application est modélisée sous deux angles: un angle fonctionnel pour mieux identifier les fonctionnalités métier de l’application et les rattacher au code, et un angle technique pour vérifier l’architecture technique de l’application. Ces modèles sont construits à l’aide de l’assistant de modélisation disponible au sein du Cockpit. Vous pouvez modifier ces modèles sur les pages Modélisation fonctionelle et Architecture technique (selon vos droits utilisateurs). 4.3.1 Modèle fonctionnel Le modèle fonctionnelle représente la vue métier de l’application, compréhensible par l’ensemble des acteurs du projet. Voir sur le Cockpit Qualité Le modèle fonctionnel est constitué de « modules » qui représente chacun une fonctionnalité métier, ou un groupe de fonctionnalité. Ces modules ont été identifiés à partir d’un corpus lexical généré à partir du code de l’application et qui permet d’isoler le vocabulaire métier de l’application. Confidentiel - Ce document est la propriété de Kalistick 17/61
  • 18. Audit de code de l’application SharpDevelop 01/01/2011 4.3.2 Modèle technique Le modèle technique représente l’architecture du code de l’application. Le principe consiste à définir un modèle d’architecture cible, qui identifie des couches et/ou des composants techniques 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 d'une application. Par exemple s'assurer 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 d'autres applications. Les cycles de dépendances sont par exemple proscrits.  Eviter les failles de sécurité en s'assurant par exemple que des appels directs vers une couche d'accès aux données ne sont jamais réalisés sans passer par une couche métier qui serait responsable de contrôles de validation Le résultat de l’analyse des contraintes d’architecture est présenté dans le chapitre 5.5 Architecture. Confidentiel - Ce document est la propriété de Kalistick 18/61
  • 19. Audit de code de l’application SharpDevelop 01/01/2011 Voir sur le Cockpit Qualité Les flèches vertes formalisent des communications autorisées entre modules, tandis que les flèches rouges formalisent des communications proscrites. Confidentiel - Ce document est la propriété de Kalistick 19/61
  • 20. Audit de code de l’application SharpDevelop 01/01/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 20/61
  • 21. Audit de code de l’application SharpDevelop 01/01/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 21/61
  • 22. Audit de code de l’application SharpDevelop 01/01/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 382 5 0 0 Fortement déconseillé 176 1 0 55 Déconseillé 81 5 2 336 A éviter 202 1 1 340 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. Confidentiel - Ce document est la propriété de Kalistick 22/61
  • 23. Audit de code de l’application SharpDevelop 01/01/2011 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. 5.2.2.1 Pratiques interdites Pratique Nouvelles Violations Classes % NC application AvoidRedundantCasts 1 124 83 29% ImplementIDisposableForTypesWithDisposableFields 0 103 64 13% DontHardcodeLocaleSpecificStrings 2 81 56 14% UseConstInsteadOfReadOnlyWhenPossible_ 0 33 10 4% UseIsNullOrEmptyToCheckEmptyStrings 0 12 9 4% OverrideEqualsWithOperatorOnValueTypes 0 11 11 4% PropertyNamesMustNotMatchGetMethods 0 6 5 1% InstantiateExceptionsWithArguments 0 5 4 2% DontImplementWriteOnlyProperty 0 3 3 1% DefineMessageForObsoleteAttribute 2 2 2 1% DontUseInadvisableTypes 0 1 1 1% DontRaiseExceptionInUnexpectedMethod_ 0 1 1 1% Voir sur le Cockpit Qualité Confidentiel - Ce document est la propriété de Kalistick 23/61
  • 24. Audit de code de l’application SharpDevelop 01/01/2011 5.2.2.2 Pratiques fortement déconseillées Pratique Nouvelles Violations Classes % NC application NeverMakeCtorCallOverridableMethod 0 185 48 10% DontUseNonConstantStaticVisibleFields 1 26 11 3% OverrideMethodsInIComparableImplementations 0 9 6 2% DefineAttributeForISerializableTypes 0 7 5 3% DontNestGenericInMemberSignatures_ 0 3 2 2% DontIgnoreMethodsReturnValue 0 1 1 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 24/61
  • 25. Audit de code de l’application SharpDevelop 01/01/2011 5.2.3.1 Classes avec des pratiques interdites Classe NC Nouvelles Violations Instructions ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefa Oui 0 10 647 ctoryResolver ICSharpCode.SharpDevelop.Dom.VBNet.VBExpressionFinder Oui 0 10 319 ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpressionFi Oui 0 10 600 nder ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.SharpD Oui 0 9 255 evelopTextAreaControl ICSharpCode.SharpDevelop.Gui.DefaultWorkbench Oui 0 8 387 ICSharpCode.SharpDevelop.Project.ConfigurationGuiHelper Oui 1 8 0 ICSharpCode.SharpDevelop.Widgets.TreeGrid.DynamicListIt Oui 0 8 211 em ICSharpCode.SharpDevelop.ParserService Oui 0 7 489 ICSharpCode.SharpDevelop.Gui.SdiWorkbenchLayout Oui 0 7 360 ICSharpCode.SharpDevelop.Dom.DomPersistence Oui 0 6 567 ICSharpCode.Core.MenuService Oui 0 6 78 ICSharpCode.SharpDevelop.Dom.DefaultProjectContent Oui 0 5 554 ICSharpCode.SharpDevelop.Gui.XmlForms.XmlLoader Oui 0 5 200 ICSharpCode.SharpDevelop.Refactoring.RefactoringService Oui 0 5 312 ICSharpCode.SharpDevelop.Project.ProjectService Oui 0 5 355 ICSharpCode.SharpDevelop.Project.MSBuildEngine Oui 0 5 337 ICSharpCode.SharpDevelop.Gui.FontSelectionPanelHelper Oui 0 5 101 ICSharpCode.SharpDevelop.Project.Commands.AddExistingIt Oui 0 4 168 emsToProject ICSharpCode.SharpDevelop.Debugging.DebuggerService Oui 0 4 288 Voir sur le Cockpit Qualité Confidentiel - Ce document est la propriété de Kalistick 25/61
  • 26. Audit de code de l’application SharpDevelop 01/01/2011 5.2.3.2 Classes avec des pratiques fortement déconseillées Classe NC Nouvelles Violations Instructions ICSharpCode.SharpDevelop.Gui.ExtTreeNode Oui 0 69 248 ICSharpCode.SharpDevelop.Gui.ClassBrowser.MemberNode Oui 0 12 72 ICSharpCode.SharpDevelop.Gui.XmlForms.XmlForm Oui 0 12 22 ICSharpCode.SharpDevelop.Dom.HostCallback Oui 1 9 19 ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionClass Oui 0 8 102 ICSharpCode.SharpDevelop.Dom.ExpressionContext Oui 0 6 142 ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionMethod Oui 0 5 41 ICSharpCode.SharpDevelop.Project.Dialogs.NewProjectDialog Oui 0 4 274 ICSharpCode.SharpDevelop.Project.FileNode Oui 0 4 155 ICSharpCode.SharpDevelop.Gui.NewFileDialog Oui 0 3 378 ICSharpCode.SharpDevelop.Project.ProjectNode Oui 0 3 114 ICSharpCode.SharpDevelop.Dom.DefaultEvent Oui 0 3 43 ICSharpCode.SharpDevelop.Dom.ReflectionLayer.ReflectionParame Oui 0 3 14 ter ICSharpCode.SharpDevelop.Dom.DefaultProperty Oui 0 3 62 ICSharpCode.SharpDevelop.Dom.DefaultMethod Oui 0 3 84 ICSharpCode.SharpDevelop.Dom.DefaultProjectContent Oui 0 2 554 ICSharpCode.SharpDevelop.Internal.Templates.FileTemplate Oui 0 2 124 ICSharpCode.SharpDevelop.Dom.DefaultParameter Oui 0 2 76 ICSharpCode.Core.MenuCommand Oui 0 2 85 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, testé, 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 26/61
  • 27. Audit de code de l’application SharpDevelop 01/01/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 27/61
  • 28. Audit de code de l’application SharpDevelop 01/01/2011 Anomalie Violation Nouvelles Violations NC s violations corrigées impactant es Complexité cyclomatique supérieure à 20 41 1 0 5% 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 28/61
  • 29. Audit de code de l’application SharpDevelop 01/01/2011 Méthode Instructions Lignes Complexité Nouvelle violation 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. 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 : 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 29/61
  • 30. Audit de code de l’application SharpDevelop 01/01/2011 Méthode Instructions Lignes Complexité Nouvelle violation ICSharpCode.SharpDevelop.Dom.ReflectionLayer.Reflection 21 36 21 Nouvelle Class.InitMembers ( System.Type) ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.Con 53 77 83 versionExists ( ICSharpCode.SharpDevelop.Dom.IReturnType, ICSharpCode.SharpDevelop.Dom.IReturnType) ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression 57 78 47 Finder.SearchBracketForward ( System.String, System.Int32, System.Char, System.Char) ICSharpCode.SharpDevelop.Dom.VBNet.VBNetAmbience.C 81 128 44 onvert ( ICSharpCode.SharpDevelop.Dom.IClass) ICSharpCode.SharpDevelop.Dom.CSharp.CSharpAmbience. 77 118 41 Convert ( ICSharpCode.SharpDevelop.Dom.IClass) ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRef 71 100 34 actoryResolver.ResolveInternal ( ICSharpCode.NRefactory.Ast.Expression, ICSharpCode.SharpDevelop.Dom.ExpressionContext) ICSharpCode.SharpDevelop.Widgets.SideBar.SideBarContro 81 97 32 l.ProcessCmdKey ( ref System.Windows.Forms.Message, System.Windows.Forms.Keys) ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.Get 20 22 31 BetterPrimitiveConversion ( ICSharpCode.SharpDevelop.Dom.IReturnType, ICSharpCode.SharpDevelop.Dom.IReturnType) ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.Type 53 73 31 Visitor.CreateReturnType ( ICSharpCode.NRefactory.Ast.TypeReference, ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom .IMember, System.Int32, System.Int32, ICSharpCode.SharpDevelop.Dom.IProjectContent, System.Boolean) ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass.Ini 57 83 30 tMembers ( Mono.Cecil.TypeDefinition) ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.MethodI 42 59 29 nsightDataProvider.SetupDataProvider ( System.String, ICSharpCode.TextEditor.Document.IDocument, ICSharpCode.SharpDevelop.Dom.ExpressionResult, System.Int32, System.Int32) ICSharpCode.SharpDevelop.Refactoring.RefactoringService. 55 89 29 AddReferences ( System.Collections.Generic.List<ICSharpCode.SharpDevelop .Refactoring.Reference>, ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom.IMember, System.Boolean, System.String, System.String) ICSharpCode.SharpDevelop.Project.DirectoryNode.Initialize ( 81 121 29 ) ICSharpCode.SharpDevelop.Project.MSBuildBasedProject.S 92 140 28 etPropertyInternal ( System.String, System.String, System.String, System.String, ICSharpCode.SharpDevelop.Project.PropertyStorageLocation s, System.Boolean) Confidentiel - Ce document est la propriété de Kalistick 30/61
  • 31. Audit de code de l’application SharpDevelop 01/01/2011 ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRef 53 81 28 actoryResolver.ResolveIdentifierInternal ( System.String) ICSharpCode.SharpDevelop.Commands.ToolMenuBuilder.To 54 74 26 olEvt ( System.Object, System.EventArgs) ICSharpCode.SharpDevelop.Dom.MemberLookupHelper.Get 32 51 26 BetterFunctionMember ( ICSharpCode.SharpDevelop.Dom.IReturnType[], ICSharpCode.SharpDevelop.Dom.IMethodOrProperty, ICSharpCode.SharpDevelop.Dom.IReturnType[], System.Boolean, ICSharpCode.SharpDevelop.Dom.IMethodOrProperty, ICSharpCode.SharpDevelop.Dom.IReturnType[], System.Boolean) ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression 51 68 26 Finder.FindFullExpression ( System.String, System.Int32) ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpression 58 76 25 Finder.ReadNextToken ( ) 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 31/61
  • 32. Audit de code de l’application SharpDevelop 01/01/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 32/61
  • 33. Audit de code de l’application SharpDevelop 01/01/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 : Confidentiel - Ce document est la propriété de Kalistick 33/61
  • 34. Audit de code de l’application SharpDevelop 01/01/2011 Méthode Couplage Complexité Nouvelle efférent violation ICSharpCode.SharpDevelop.Refactoring.RefactoringMenuBuilder.Build 45 22 Submenu ( ICSharpCode.Core.Codon, System.Object) ICSharpCode.SharpDevelop.Project.Commands.AddExistingItemsToP 39 22 roject.Run ( ) ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass.InitMember 36 30 s ( Mono.Cecil.TypeDefinition) ICSharpCode.SharpDevelop.Gui.NewFileDialog.OpenEvent ( 35 17 System.Object, System.EventArgs) ICSharpCode.SharpDevelop.Commands.ToolMenuBuilder.ToolEvt ( 32 26 System.Object, System.EventArgs) ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryRes 31 34 olver.ResolveInternal ( ICSharpCode.NRefactory.Ast.Expression, ICSharpCode.SharpDevelop.Dom.ExpressionContext) ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.MethodInsightDat 30 29 aProvider.SetupDataProvider ( System.String, ICSharpCode.TextEditor.Document.IDocument, ICSharpCode.SharpDevelop.Dom.ExpressionResult, System.Int32, System.Int32) ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryRes 30 18 Nouvelle olver.CtrlSpace ( System.Int32, System.Int32, System.String, System.String, ICSharpCode.SharpDevelop.Dom.ExpressionContext) ICSharpCode.SharpDevelop.DefaultEditor.Commands.ClassBookmark 29 19 MenuBuilder.BuildSubmenu ( ICSharpCode.Core.Codon, System.Object) ICSharpCode.SharpDevelop.Project.MSBuildEngine.BuildRun.ParseS 29 19 olution ( Microsoft.Build.BuildEngine.Project) ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.NRefactoryRes 28 28 olver.ResolveIdentifierInternal ( System.String) ICSharpCode.SharpDevelop.Dom.CecilReader.CreateType ( 28 21 ICSharpCode.SharpDevelop.Dom.IProjectContent, ICSharpCode.SharpDevelop.Dom.IDecoration, Mono.Cecil.TypeReference) ICSharpCode.SharpDevelop.Project.ProjectService.LoadProject ( 27 15 System.String) ICSharpCode.SharpDevelop.Dom.NRefactoryResolver.TypeVisitor.Cre 26 31 ateReturnType ( ICSharpCode.NRefactory.Ast.TypeReference, ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom.IMember, System.Int32, System.Int32, ICSharpCode.SharpDevelop.Dom.IProjectContent, System.Boolean) ICSharpCode.SharpDevelop.Project.DirectoryNode.Initialize ( ) 26 29 ICSharpCode.SharpDevelop.Widgets.TreeGrid.DynamicList.OnPaint ( 26 21 System.Windows.Forms.PaintEventArgs) ICSharpCode.SharpDevelop.Project.Dialogs.NewProjectDialog.OpenE 26 20 vent ( System.Object, System.EventArgs) ICSharpCode.SharpDevelop.Dom.CecilReader.CecilClass ( 26 15 ICSharpCode.SharpDevelop.Dom.ICompilationUnit, ICSharpCode.SharpDevelop.Dom.IClass, Mono.Cecil.TypeDefinition, System.String).CecilClass ( ICSharpCode.SharpDevelop.Dom.ICompilationUnit, ICSharpCode.SharpDevelop.Dom.IClass, Mono.Cecil.TypeDefinition, System.String) ICSharpCode.SharpDevelop.Gui.GotoDialog.TextBoxTextChanged ( 25 18 System.Object, System.EventArgs) Confidentiel - Ce document est la propriété de Kalistick 34/61
  • 35. Audit de code de l’application SharpDevelop 01/01/2011 Voir sur le Cockpit Qualité 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. Confidentiel - Ce document est la propriété de Kalistick 35/61
  • 36. Audit de code de l’application SharpDevelop 01/01/2011 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. 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) 6 CETIC, Kalistick. Statistically Calibrated Indexes for Unit Test Relevancy and Unit Test Writing Effort, 2010 Confidentiel - Ce document est la propriété de Kalistick 36/61
  • 37. Audit de code de l’application SharpDevelop 01/01/2011  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é) 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 1373 0 Haute 0 515 0 Moyenne 0 10 0 Basse 0 14 0 Aucune 0 5656 0 [Total] 0 7568 0 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 d'instructions  la couleur, qui représente l'écart par rapport à l'objectif 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 atteint Confidentiel - Ce document est la propriété de Kalistick 37/61
  • 38. Audit de code de l’application SharpDevelop 01/01/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 à l'objectif de couverture fixé pour la classe, tout comme pour le TreeMap précédent Confidentiel - Ce document est la propriété de Kalistick 38/61
  • 39. Audit de code de l’application SharpDevelop 01/01/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 à l'objectif de couverture fixé pour la classe, tout comme pour le TreeMap ou les QuickWins Confidentiel - Ce document est la propriété de Kalistick 39/61
  • 40. Audit de code de l’application SharpDevelop 01/01/2011 Voir sur le Cockpit Qualité 5.4.7 Méthodes à tester en priorité 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 40/61
  • 41. Audit de code de l’application SharpDevelop 01/01/2011 Méthode Couverture Pertinence Priorité Effort Nouvelle (TRI) violation ICSharpCode.SharpDevelop.Refactoring.RefactoringM 0% 37.00 Critique Elevé enuBuilder.BuildSubmenu ( ICSharpCode.Core.Codon, System.Object) ICSharpCode.SharpDevelop.Project.Solution.SetupSol 0% 37.00 Critique Très élevé ution ( ICSharpCode.SharpDevelop.Project.Solution, System.String) ICSharpCode.SharpDevelop.Project.MSBuildBasedProj 0% 37.00 Critique Très élevé ect.SetPropertyInternal ( System.String, System.String, System.String, System.String, ICSharpCode.SharpDevelop.Project.PropertyStorageL ocations, System.Boolean) ICSharpCode.SharpDevelop.Dom.NRefactoryResolver. 0% 37.00 Critique Très élevé NRefactoryResolver.ResolveIdentifierInternal ( System.String) ICSharpCode.SharpDevelop.Commands.SharpDevelop 0% 36.00 Critique Elevé StringTagProvider.Convert ( System.String) ICSharpCode.Core.AddInTree.Load ( 0% 36.00 Critique Elevé System.Collections.Generic.List<System.String>, System.Collections.Generic.List<System.String>) ICSharpCode.SharpDevelop.Project.Commands.AddEx 0% 36.00 Critique Elevé istingItemsToProject.Run ( ) ICSharpCode.SharpDevelop.Dom.CecilReader.CreateT 0% 35.00 Critique Elevé ype ( ICSharpCode.SharpDevelop.Dom.IProjectContent, ICSharpCode.SharpDevelop.Dom.IDecoration, Mono.Cecil.TypeReference) ICSharpCode.SharpDevelop.Commands.ToolMenuBuil 0% 35.00 Critique Elevé der.ToolEvt ( System.Object, System.EventArgs) ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor. 0% 35.00 Critique Très élevé MethodInsightDataProvider.SetupDataProvider ( System.String, ICSharpCode.TextEditor.Document.IDocument, ICSharpCode.SharpDevelop.Dom.ExpressionResult, System.Int32, System.Int32) ICSharpCode.SharpDevelop.Refactoring.RefactoringSe 0% 35.00 Critique Elevé rvice.AddReferences ( System.Collections.Generic.List<ICSharpCode.SharpD evelop.Refactoring.Reference>, ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom.IMember, System.Boolean, System.String, System.String) ICSharpCode.SharpDevelop.Dom.ReflectionLayer.Refl 0% 35.00 Critique Elevé ectionReturnType.Create ( ICSharpCode.SharpDevelop.Dom.IProjectContent, ICSharpCode.SharpDevelop.Dom.IDecoration, System.Type, System.Boolean) Confidentiel - Ce document est la propriété de Kalistick 41/61
  • 42. Audit de code de l’application SharpDevelop 01/01/2011 ICSharpCode.SharpDevelop.Dom.NRefactoryResolver. 0% 35.00 Critique Très élevé NRefactoryResolver.ResolveInternal ( ICSharpCode.NRefactory.Ast.Expression, ICSharpCode.SharpDevelop.Dom.ExpressionContext) ICSharpCode.SharpDevelop.Dom.NRefactoryResolver. 0% 35.00 Critique Très élevé TypeVisitor.CreateReturnType ( ICSharpCode.NRefactory.Ast.TypeReference, ICSharpCode.SharpDevelop.Dom.IClass, ICSharpCode.SharpDevelop.Dom.IMember, System.Int32, System.Int32, ICSharpCode.SharpDevelop.Dom.IProjectContent, System.Boolean) ICSharpCode.SharpDevelop.Dom.CSharp.CSharpExpre 0% 35.00 Critique Elevé ssionFinder.SearchBracketForward ( System.String, System.Int32, System.Char, System.Char) ICSharpCode.SharpDevelop.DefaultEditor.Gui.Editor.A 0% 35.00 Critique Elevé bstractCodeCompletionDataProvider.CreateItem ( System.Object, ICSharpCode.SharpDevelop.Dom.ExpressionContext) ICSharpCode.SharpDevelop.Project.MSBuildEngine.Bu 0% 34.00 Critique Normal ildRun.ParseSolution ( Microsoft.Build.BuildEngine.Project) ICSharpCode.SharpDevelop.Project.ProjectService.Loa 0% 34.00 Critique Elevé dProject ( System.String) ICSharpCode.SharpDevelop.Project.ProjectBrowserCo 0% 34.00 Critique Elevé ntrol.FindDeepestOpenNodeForPath ( System.String) Voir sur le Cockpit Qualité 5.5 Architecture Le domaine Architecture vise à contrôler le respect d’un modèle d’architecture logicielle. Le modèle d’architecture cible a été présenté dans le chapitre 4.3.2 Modèle technique. Le schéma suivant montre les résultats de l’analyse des contraintes d’architecture en comparant ce modèle cible avec le code de l’application. Actuellement, les violations des contraintes d’architecture ne sont pas prises en compte dans le calcul de la non-conformité de l’application. Confidentiel - Ce document est la propriété de Kalistick 42/61
  • 43. Audit de code de l’application SharpDevelop 01/01/2011 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 oranges 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 43/61