View
1
Download
0
Category
Preview:
Citation preview
ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
UNIVERSITÉ DU QUÉBEC
PRÉSENTÉE À
L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
DANS LE CADRE DE COURS
COURS MGL804 - RÉALISATION ET MAINTENANCE DE LOGICIELS
PAR
SHABNAM MAHMOUDIMACHAKPOSHTI
MAHS08598103
ÉVALUATION DE LA MAINTENABILITÉ DES LOGICIELS AVEC SONARQUBE
MONTRÉAL, LE 17/05/2016
©Tous droits réservés, Shabnam MAHMOUDIMACHAKPOSHTI, 2016
1
ÉVALUATION DE LA MAINTENABILITÉ DES LOGICIELS AVEC
SONARQUBE
SHABNAM MAHMOUDIMACHAKPOSHTI
RÉSUMÉ
Ce rapport est l’analyse de la maintenabilité de deux projets open source à l’aide du logiciel
de l’évaluation de la qualité Sonar, en suivant les étapes d’une analyse reproductible, impartiale et
objective. Pour la mesure de la qualité de maintenabilité de logiciel, les deux projets différents
sont choisis. Les différences sont la taille, le genre de travail et le langage de programmation.
Sonar permet de visualiser les résultats de la mesure. L’analyse des résultats permet de bien
comprendre les points forts et les faibles de la qualité de la maintenabilité. Cette dernière est très
importante pour les mainteneurs qui effectuent la maintenance le logiciel.
L’approche utilisée pour réaliser ce travail est l’extraction des attributs qualité de
maintenabilité de la norme ISO 9126 qui sert de référence de la qualité et l’évaluation de qualité
des logiciels. Ensuite, l’exécution de logiciel Sonar pour obtenir des résultats de la mesure des
attributs qualité. Puis, l’analyse des résultats obtenus pour comprendre l’état de la qualité de
logiciel et décider de maintenir le logiciel. Enfin, l’émission des recommandations.
2
TABLE DES MATIÈRES
CHAPITRE 1: INTRODUCTION……….………………………………………………………..6
1.1 Objectif………………………………………………………………………………………...6
1.2 Approche………………………………………………………………………………………6
CHAPITRE 2: LA NORME UTILISÉE…………………………………………………………...7
2.1 La norme ISO 9126…………………………………………………………………………….7
CHAPITRE 3: DESCRIPTION DES PROJETS…………………………………………………..8
3.1 Pair FX………………………………………………………………………………………...9
3.2 Subirons………………………………………………………………………………………10
CHAPITRE 4: L’OUTIL CHOISI: SONAR……………………………………………………..11
4.1 Principe de Sonar……………………………………………………………………………..11
4.2 Mesure effectuée par Sonar…………………………………………………………………..11
4.3 Exécution de Sonar…………………………………………………………………………...12
CHAPITRE 5: ANALYSE DES RÉSULTATS………………………………………………….14
5.1 Taille du code source…………………………………………………………………………14
5.1.1 Résultat de la mesure……………………………………………………………………..14
5.1.2 Interprétation des résultats………………………………………………………………..14
5.2 Documentation……………………………………………………………………………….15
5.2.1 Résultat de la mesure……………………………………………………………………..15
5.2.2 Interprétation des résultats………………………………………………………………..15
5.2.3 Recommandations………………………………………………………………………..15
5.3 Duplication de code…………………………………………………………………………..16
5.3.1 Résultat de la mesure……………………………………………………………………..16
5.3.2 Interprétation des résultats………………………………………………………………..17
5.3.3 Recommandations………………………………………………………………………..18
5.4 Complexité…………………………………………………………………………………...18
5.4.1 Résultat de la mesure……………………………………………………………………..18
5.4.2 Interprétation des résultats………………………………………………………………..18
5.4.3 Recommandations..………………………..……………………………………………..19
5.5 Code Smell et Dette technique………………………………………………………………..20
5.5.1 Résultat de la mesure……………………………………………………………………..20
5.5.2 Interprétation des résultats………………………………………………………………..21
5.5.3 Recommandations………………………………………………………………………..22
CONCLUSION…………………………………………………………………………………..23
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES…………………………………………….24
3
LISTE DES TABLEAUX
Page
Tableau 5.1 Les classes qui contient les blocs dupliqués de PairFX………………………..…...17
Tableau 5.2 Les classes qui contient les blocs dupliqués de Subrion………………..…………..17
Tableau 5.3 La liste de blocs avec les mauvaises odeurs dans le code de PairFX………..……..21
Tableau 5.4 La liste de blocs avec les mauvaises odeurs dans le code de Subrion…………..….21
4
LISTE DES FIGURES
Page
Figure 2.1 Caractéristiques de la qualité ISO 9126………………………………………………...7
Figure 3.1 L’interface de PairFX…………………………………………………………...……...9
Figure 3.2 L’interface de Subrion…………………………………………………….…………..10
Figure 4.1 Les exemples de la configuration des projets en Java et PHP……………….…………12
Figure 4.2 Fenêtre de d’marrer le SonarQube…………………………………………………….13
Figure 5.1 Les résultats de taille des projets Subrion et PairFX…………………………………..14
Figure 5.2 La résultat de la mesure de documentation de deux projets Subrion et PairFX………..15
Figure 5.3 Le résultat de duplication pour l’application PairFX………………………………….16
Figure 5.4 Le résultat de duplication pour l’application Subrion…………………………………16
Figure 5.5 Le résultat de complexité pour les deux applications Subrion………………………...18
Figure 5.6 Le résultat de complexité pour les deux applications PairFX………………….………18
Figure 5.7 Le résultat de Code Smell pour l’application PairFX………………………….………20
Figure 5.8 Le résultat de Code Smell pour l’application Subrion………………………….……...20
5
LISTE DES ABRÉVIATIONS, SIGLES ET ACRONYMES
ISO : l'Organisation internationale de normalisation
API : Interface de programmation d'applications
6
CHAPITRE 1
INTRODUCTION
1.1 Objectif
Ce rapport est préparé dans le cadre de cour MGL804, la réalisation et la maintenance de
logiciels. Le but de ce projet est l’analyse de la maintenabilité de deux logiciels avec les différentes
caractéristiques. L’une est un petit projet en Java et l’autre est un grand projet en PHP. L’outil
utilisé pour l’évaluation de la qualité est Sonar. Enfin, les recommandations pour l’améliorer la
qualité de code source sera présentée.
1.2 Approche
L’approche utilisée pour ce projet est présentée dans les étapes suivantes :
Étudier la norme ISO 9126 qui est utilisée pour la qualité des logiciels;
Éliciter des attributs qualité pour la maintenabilité des logiciels;
Exécuter le Sonar pour mesurer des attributs qualité de deux logiciels;
Analyser les résultats de la mesure de qualité des codes sources;
Présenter les recommandations.
7
CHAPITRE 2
LA NORME UTILISÉE
2.1 La norme ISO 9126
La norme ISO 9126 est la norme qui définit les critères de mesure de la qualité d’un produit
logiciel. Le modèle de qualité de cette norme se base sur un ensemble de caractéristiques et de
sous-caractéristiques de la qualité. La figure 2.1 indiquant les caractéristiques et les sous-
caractéristiques de qualité interne et externe de la norme ISO 9126.
Figure 2.1 Caractéristiques de la qualité ISO 9126 [5]
La norme ISO/CEI 9126 définit six groupes d’indicateurs de la qualité d’un logiciel, qui sont
:
La capacité fonctionnelle
Ensemble d’attributs portant sur l’existence d’un ensemble de fonctions et leurs propriétés
données. Les fonctions sont celles qui satisfont aux besoins exprimés ou implicites.
La Fiabilité
Ensemble d’attributs portant sur l’aptitude d’un logiciel à maintenir son niveau de service
dans des conditions précises et pendant une période déterminée.
8
La facilité d’utilisation
Ensemble d’attributs portant sur l’effort nécessaire pour l’utilisation et sur l’évaluation
individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs.
L’efficacité
Ensemble d’attributs portant sur le rapport existant entre le niveau de service d’un logiciel
et la quantité de ressources utilisées, dans des conditions déterminées.
La maintenabilité
Ensemble d’attributs portant sur l’effort nécessaire pour faire des modifications données.
La portabilité
Ensemble d’attributs portant sur l’aptitude de logiciel à être transféré d’un environnement à
l’autre. Comme mentionné dans la figure 2.1, il y a des sous-caractéristiques pour chaque
caractéristique. Par exemple, pour la maintenabilité les sous-caractéristiques sont les suivantes :
Facilité d’analyse;
Facilité de modification;
Stabilité;
Facilité de test;
Maintenabilité;
Conformité réglementaire.
La mesure de la maintenabilité n’est pas une mesure directe. C’est-à-dire qu’il n’y a pas
qu’une seule mesure d’un logiciel et on se doit de mesurer plusieurs indicateurs afin d’en tirer
quelques conclusions sur la maintenabilité [9].
9
CHAPITRE 3
DESCRIPTION DES PROJETS
3.1 Pair FX
Pair FX est un logiciel open source de gestion d'appariement spécialisé dans les tournois de
jeunes administrés par les écoles et clubs d'échecs. Il est écrit en Java, Pair FX gère des tournois
qui ne sont pas organisés sous forme de ronde, c’est-à-dire qu’un joueur ayant terminé sa partie
plus tôt n’est pas obligé d’attendre tous les autres pour commencer une nouvelle partie [3]. La
figure 3.1 indique l’interface de ce logiciel.
Figure 3.1 L’interface de Pair FX [3].
Les fonctionnalités principales présentées dans le logiciel sont les suivantes :
Importer la liste des joueurs à partir d'Excel ;
Gérer des joueurs ;
Supprimer un appariement ;
Rechercher un joueur apparié ;
Exporter au format HTML ;
Activer ou désactiver l’atténuation de la couleur de l’écran ;
10
Enregistrer au format XML [3].
3.2 Subirons
Subirons est un logiciel open source pour la gestion de contenu qui permet de construire des
sites web. Il est écrit en PHP.
La figure 3.2 indique l’interface de ce logiciel.
Figure 3.2 L’interface de Subirons [4]
Les fonctionnalités principales présentées dans le logiciel sont les suivantes :
L’accès aux services pour les deux types d’utilisateurs : l’utilisateur final et l’administrateur;
La gestion de compte pour les deux types des utilisateurs;
La gestion de finance ;
11
CHAPITRE 4
L’OUTIL CHOISI : SONAR
4.1 Principe de Sonar :
SONAR est un outil open source pour la gestion de qualité du logiciel, dédié à l’analyse et
la mesure continues de la qualité du code source. [2]
L’outil permet d’effectuer une évaluation de la qualité d’un produit logiciel, en effectuant
un ensemble de mesures sur le code source, et sans exécuter le programme.
Les mesures effectuées par SONAR peuvent permettre de :
Détecter certaines erreurs potentielles, ou certaines mauvaises pratiques de programmation ;
Prendre des décisions quant à faire de factorisation de certaines composantes du Logiciel.
Il supporte plus de 20 langages de programmation et il fournit plusieurs métriques qui
permettent de mesurer la qualité des logiciels.
4.2 Mesure effectuée par Sonar
Les différents types de mesure que SONAR peut effectuer pour l’analyse de la maintenabilité
ont les suivants :
Taille du code source : nombre total de lignes de code, de packages, des classes et des méthodes.
Documentation : Nombre de lignes de commentaires pour les codes et les APIs.
Duplication de code : Cette métrique indiquant la duplication des blocs d’instructions dans le code
source.
Complexité : La complexité ou la complexité des fonctionnes et des classes. La complexité d'une
méthode est définie par le nombre de chemins linéairement indépendants qu'il est possible
d'emprunter dans cette méthode. Plus simplement, il s'agit du nombre de points de décision de la
méthode (if, case, white, ...).
Code Smell : En génie logiciel, les codes Smells ou mauvaises odeurs, sont des mauvaises
pratiques de conception logicielle qui conduisent à l'apparition de défauts. Ces défauts sont souvent
issus de mauvais choix d'implémentations ou de conceptions et conduisent à une complexification
du code source et de la maintenance et évolutivité de celui-ci. Afin de corriger, un code smell, il
https://fr.wikipedia.org/wiki/Conception_de_logicielhttps://fr.wikipedia.org/wiki/Maintenance
12
est nécessaire de procéder à une refactorisation du code source, c'est-à-dire modifier le code sans
en altérer son comportement. [8]
Dette technique : C’est une dette qui accompagne tous les projets logiciels. Ils ne sont pas des
bugs, mais plutôt des défauts de conception ne permettant pas au logiciel de se maintenir ou
d’évoluer simplement. [6]
En résumé, quand on code au plus vite et de manière non optimale, on contracte une dette
technique que l’on rembourse tout au long de la vie du projet sous forme de temps de
développement de plus en plus long et de bugs de plus en plus fréquents. [7]
4.3 Exécution de Sonar
Pour l’utilisation de SonarQube nous avons suivi les étapes suivantes :
1. Télécharger le SonarQube de l’adresse : http://www.sonarsource.org/downloads/ et unzip le fichier
(c:\sonarqube)
2. Lancer le serveur de SonarQube :
Sur Windows, exécuter:
C:\sonarqube\bin\windows-x86-xx\StartSonar.bat
Sur autre système d’opération:
/etc/sonarqube/bin/[OS]/sonar.sh console
3. Télécharger le SonarQube Scanner et unzip le fichier (C:\sonar-scanner)
4. Pour l’analyse du projet, il faut créer un fichier qui s’appelle « sonar-project-properties » dans le
dossier principal du projet. Les contenus de ce fichier sont indiqués dans la figure 4.1.
Figure 4.1 Les exemples de la configuration des projets en Java et PHP
1. L’exécution le lien suivant :
https://fr.wikipedia.org/wiki/R%C3%A9usinage_de_codehttp://www.sonarsource.org/downloads/http://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner
13
Cd C:\sonar-projects\PairFx
C:\sonar-scanner\bin\sonar-scanner.bat
2. Pour afficher les résultats d’analyse, il faut ouvrir l’adresse suivant sur le navigateur :
http://localhost:9000
Figure 4.2 Fenêtre de démarrer le SonarQube
À propos de l’analyse d’un projet en PHP, il faut installer le plug-in de PHP sur SonarQube
á suivre les étapes suivantes :
3. Choisir les sections :
Settings > Update Center > Available Plugins
4. Trouver le plug-in de PHP et cliquer le bouton « Install »
http://localhost:9000/
14
CHAPITRE 5
ANALYSE DES RÉSULTATS
Dans ce parti, il existe des résultats obtenus par Sonar. Après avoir exécuté le Sonar pour les
deux logiciels, ça nous a donné les résultats suivants :
5.1 Taille du code source
5.1.1 Résultat de la mesure
Sonar permet de visualiser la taille de projet par la ligne de code, les fonctions et les classes.
La figure 5.1 indiquant les résultats détaillés de taille de deux projets Subrion et PairFX.
Subrion PairFX
Figure 5.1 Les résultats de taille des projets Subrion et PairFX
5.1.2 Interprétation des résultats
Sonar calcule cette métrique en fonction du nombre de lignes du code. La figure 5.1
indiquant Subrion contient 91,163 lignes de code en PHP et PairFX contient 4,496 lignes de code
de Java.
15
5.2 Documentation
5.2.1 Résultats de la mesure
Subrion PairFX
Figure 5.2 La résultat de la mesure de documentation de deux projets Subrion et PairFX.
5.2.2 Interprétation des résultats
La documentation dans le code source est une pointe importante pour la maintenance. Il aide
les mainteneurs de comprendre le code source d'une application. La figure 5.2 indiquant dans
l’application Subrion il existe 28,451 lignes de commentaires. C’est-à-dire pour 23.8% de codes,
il y a des commentaires.
À propos de l’application PairFX, Sonar indique le total de lignes de commentaires. Il existe
142 lignes de commentaires pour 4459 lignes de code. C’est-à-dire pour 3.1% du code, il y a des
commentaires. Ce n’est pas suffisant pour maintenir. Pour le projet PaireFX en Java, Sonar a
donné les nombres de lignes de commentaire pour les APIs.
5.2.3 Recommandations
La recommandation pour les deux projets Subrion et PaireFX est bien documenter les codes
sources, afin de facilite la compréhension les deux types de projets par l’équipe de maintenance,
ceci s’effectue à travers les commentaires du code source et la documentation API pour les
fonctions publiques générée par l’outil Java doc.
16
5.3 Duplication de code
5.3.1 Résultats de la mesure
PairFX
Figure5.3 Le résultat de duplication pour l’application PairFX
Subrion
Figure 5.4 Le résultat de duplication pour l’application Subrion
17
5.3.2 Interprétation des résultats
Sonar permit aussi de visualiser les blocs de code dupliqués à l’intérieur du code des classes.
Comme indiqué dans la figure 5.3, la duplication pour l’application PairFX est 2.3% de lignes de
code. Pour cette application, il existe 6 blocs dupliqués dans deux fichiers.
Selon le diagramme de duplication de PairFX, les deux classes qui ont beaucoup de blocs
dupliqués sont les suivants :
Tableau 5.1 Les classes qui contient les blocs dupliqués de PairFX
Nom de Classe Ligne
de code
Linges
dupliqués
Blocs
dupliqués
ToernooiOverzichtRoundRobinControl 317 69 3
ToernooiOverzichtController 356 69 3
À propos de duplication dans l’application Subrion, comme indiqué dans la figure 5.4 le
ratio de duplication pour cette application est 10%. C’est-à-dire, il n’y a pas de problème de
duplication pour 90% du code source. Pour cela, il existe 576 blocs dupliqués dans 119 fichiers.
Selon le diagramme de duplication de Subrion, les fichiers qui ont plusieurs de blocs dupliqués
sont les suivants :
Tableau 5.2 Les classes qui contient les blocs dupliqués de Subrion
Nom de fichier Ligne de
code
Linges
dupliqués
Blocs
dupliqués
smarty_internal_templateparser 3007 1775 14
smarty_internal_cofigfileparser 818 682 12
ia.core.mysqli 670 593 12
ia.core.pdo 622 590 10
ia.core.mysql 649 551 9
Comme indiqué dans la figure 5.4, la plupart de problème de duplication des blocs sont
trouvés dans les fichiers qui ont moins de 1000 lignes de codes.
18
5.3.3 Recommandations
Les recommandations pour traiter la duplication sont les suivants :
Rassembler le code dupliqué dans des méthodes réutilisables.
Revoir la conception et le découpage des traitements pour bénéficier des similarités entre les
traitements d’ajout et de modification dans la base de données.
5.4 Complexité
5.4.1 Résultats de la mesure
Subrion
Figure 5.5 Le résultat de complexité pour les deux applications Subrion.
PairFX
Figure 5.6 Le résultat de complexité pour les deux applications PairFX
19
5.4.2 Interprétation des résultats
La complexité est une pointe importante pour la maintenance. Les méthodes complexes sont
difficiles à maintenir. Ils ont un impact sur l'effort requis pour faire sa maintenance. Une méthode
avec une faible complexité, nécessite en général moins d'effort pour la maintenir qu'une méthode
avec une forte complexité. Sonar permet de visualiser les résultats de la mesure de complexité. Les
résultats sont indiqués par méthode, par fichier et par classe. À propos de l’application Subrion,
la moyenne complexité par méthode est 5.3 et la complexité totale de cette application est 25,342.
Les 1687 méthodes dans l’application Subrion ont la complexité de 1 sur un total de 4424
méthodes, ce qui est bien pour la maintenance.
À propos de l’application PairFX, comme indique dans la figure 5.5, la moyenne de
complexité est 1.9 par méthode. La complexité totale est 939. Dans cette application, il y a 281
méthodes qui ont la complexité de 1 sur un total de 496 méthodes.
5.4.3 Recommandations
Pour diminuer la complexité, il faut découper les méthodes des classes s’il y a peu
d’interaction entre elle. Il faut aussi simplifier et optimiser les algorithmes.
20
5.5 Code Smell et Dette technique
5.5.1 Résultats de la mesure
PairFX
5.7 Le résultat de Code Smell pour l’application PairFX.
Subrion
5.8 Le résultat de Code Smell pour l’application Subrion.
21
5.5.2 Interprétation des résultats
Comme indiqué dans la figure 5.7 pour l’application PairFX, il a 270 codes smells. La
plupart des mauvaises odeurs sont dans les blocs qui ont moins de 100 lignes de codes. C’est-à-
dire les petits blocs ont des problèmes comme la duplication ou des longs commentaires. Les blocs
qui ont les plus parts des codes smell sont les suivants :
Tableau 5.3 La liste de blocs avec les mauvaises odeurs dans le code de PairFX
Nom de classe Lignes de code Dette technique Code Smells
Screens 20 3h 20min 18
Messages 36 1h 46min 35
ExportFlags 19 1h 10min 7
Également, le ratio de dette technique pour cette application est 1.2 %. Sonar calcul l’effort
pour traiter les défauts de dette technique. Pour PairFX, l’effort prévu pour dette technique est les
3 jours et 3heurs. C’est-à-dire un programmeur doit travailler 27 heures pour remédier les dettes
techniques de PairFX.
Comme indiqué dans la figure 5.8 pour l’application Subrion, il a 11,375 codes smells. La
plus part des mauvaise odeurs sont dans les blocs qui ont moins de 1000 lignes de codes. Les blocs
qui ont les plus parts des codes smell sont les suivants :
Tableau 5.4 La liste de blocs avec les mauvaises odeurs dans le code de Subrion
Nom de classe Lignes de code Dette
technique Code Smells
adminer.script.php 780 14j 1600
fields.php 985 2j 4h 84
ia.core.field.php 884 2j 115
Également, le ratio de dette technique pour cette application est 2.7 %. Sonar calcul l’effort
pour traiter les défauts de dette technique. Pour Subrion, l’effort prévu pour dette technique est les
22
154 jours. C’est-à-dire un programmeur doit travailler 1232 heures pour remédier les dettes
techniques de Subrion.
5.5.3 Recommandations
La plus part des problèmes de code smells et dette technique sont la duplication des
fonctions. La recommandation est de diminuer la duplication dans les méthodes et entre les blocs.
Également, les commentaires dans le code devraient être utilisés pour indiquer le "pourquoi" et
non pas le "quoi".
23
CONCLUSION
Nous a fait l’évaluation de la qualité de maintenabilité pour les deux l’application avec les
caractéristiques différents. Nous avons utilisé l’outil Sonar pour évaluer. Sonar nous a permis de
visualiser les mesures. L’équipe de maintenance peut prendre des décisions à propos de maintenir
de logiciels avec les résultats de la mesure.
Les résultats de la mesure indiquent le niveau de maintenabilité des logiciels analysés,
PairFX et Subrion sont A. Ce résultat est un bon niveau de maintenir en théorique. Selon les
résultats de l’estimation de dette technique de projet PairFX, ce projet a besoin de 3 jours d’effort
d’un programmeur. Ce n’est pas beaucoup pour réviser les codes source pour éliminer les
problèmes de dette technique d’un projet avec 4 KLOC. Également, le résultat de l’estimation des
efforts de dette technique de projet Subrion indiquent ce projet a besoin de 154 jours de l’effort
d’un programmeur pour résoudre les problèmes de dette technique. C’est beaucoup pour un projet
de 91 KLOC. En général, les outils de l’analyse de la qualité de logiciel ne peuvent pas dire
exactement, est ce que le niveau de maintenabilité d’un logiciel est bonne ou non. Mais ils peuvent
nous donner une estimation pour la décision de statut de la maintenance.
24
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES
[1] ISO/CEI 9126-1. « Modèle de qualité : 2001 », dans Technologie de l’information : Qualité
de produits logiciels, Partie 1, Genève, Norme Internationale, ISO, 2001.
[2] Documentation de SONAR : http://sonar.codehaus.org/ (consulté le 15 Mai 2016)
[3] Documentation de PairFX : http://sourceforge.net/projects/pairfx/?source=directory
[4] Documentation de Subrion : http://www.subrion.org/
[5] https://www.researchgate.net/figure/254916205_fig3_Figure-3-ISO-9126-Internal-and-
External-Quality-Characteristics-Level-5-Major-review
[6] http://blog.dollon.net/la-dette-technique/
[7] http://blog.octo.com/maitriser-sa-dette-technique/
[8] https://fr.wikipedia.org/wiki/Code_Smell
[9] Pressman, R. S. Software Engineering: A Practitioner’s Approach, 3th edition, McGraw-Hill,
1992.
http://sonar.codehaus.org/http://sourceforge.net/projects/pairfx/?source=directoryhttps://www.researchgate.net/figure/254916205_fig3_Figure-3-ISO-9126-Internal-and-%20%20%20%20%20External-Quality-Characteristics-Level-5-Major-reviewhttps://www.researchgate.net/figure/254916205_fig3_Figure-3-ISO-9126-Internal-and-%20%20%20%20%20External-Quality-Characteristics-Level-5-Major-reviewhttps://fr.wikipedia.org/wiki/Code_SmellRecommended