MINI PROJET GENIE LOGICIEL :

Mesure qualit logicielle.

Anne universitaire : 2011 / 2012.

1. Dfinitions [1] : ISO : (International Organization for Standardization) organisme international bas Genve charg dlaborer les normes au niveau mondial ; SEI : Software Engineering Institut ; EXT : Qualit externe ; INT : Qualit interne. 2. Qualit logicielle [2] : 2.1 Dfinition : La notion de qualit dun logiciel est trs large et assez vague. Cest pourquoi lISO en collaboration avec le SEI a dfini la norme ISO/9126 afin de structurer cette notion. Cette norme caractrise la qualit dun logiciel par un ensemble dattributs rsum sur le schma suivant (EXT signifie une qualit externe, c.--d.ISO visible de lutilisateur final et dduite du comportement lexcution du logiciel, INT une qualit interne, c.--d. non visible et dduite uniquement des caractristiques du logiciel) 2.2 Attributs et sous-attributs qualit : Ces attributs et sous-attributs sont dfinis ci-dessous :

Figure 01 : attributs et sous attributs de la qualit logicielle. a. Fonctionnalit : Dsigne la capacit dun produit logiciel fournir les fonctions qui rpondent aux besoins formuls et ncessaires quand le logiciel est utilis dans des conditions spcifies. Dsigne ce que fait le logiciel pour remplir les besoins utilisateurs, cet attribut chapote, en plus de la scurit, trois sous attributs qui sont : - Interoprabilit : Dsigne la capacit interagir avec un ou plusieurs systmes. Les lments favorisant une bonne interoprabilit sont classer suivant le niveau : Smantique : qui traite du sens des informations (c.--d. des mots) changes entre entits.

Il est directement li au modle du domaine. Les entits sentendent sur la signification des donnes quelles changent. Linteroprabilit smantique caractrise la capacit saccorder sur - Le contexte de lchange : dicte le sens des mots (par exemple une personne est vue comme un patient dans une application de sant et comme un citoyen dans une application dadministration publique) ; - Le processus de lchange : quels sont les acteurs, vnements et activits lis lchange ; - Le sens et la structuration de linformation change ; Syntaxique et technique: qui vhicule les informations dfinies au niveau smantique et mises en forme au niveau syntaxique. Il traite des normes et standards technique pour : - Les technologies de navigation et de restitution (prsentation). - Les technologies de communication entre humain (messagerie, tlphonie, multimdia) - Les technologies dchanges entre SI (services Web) - Les technologies lmentaires ncessaires aux changes (infrastructure dont protocoles rseaux). - Adquation (ou fonctionnalits conformes) : Dsigne lexistence de fonctions adquates pour les tches requises. Cela implique deux aspects : - Tout dabord, la prsence de la fonction : les tches sont spcifis travers des cas dutilisations. Pour chaque tche il doit exister une ou plusieurs fonctionnalits permettant de laccomplir. - Ensuite, le fait que limplmentation de la fonction soit approprie avec le besoin. - Exploitabilit : Cet attribut nexiste pas dans la norme ISO mais je le considre comme essentiel (voir cet article sur lACM Queue). Il dsigne la capacit exploiter correctement le systme logiciel, dtecter les erreurs, mesurer le niveau defficacit et dployer aisment de nouvelles versions. b. Fiabilit : Dsigne la capacit dun produit logiciel maintenir son niveau de service dans des conditions prcises pendant une certaine dure. Les fameux bugs sont le symptme dun manque de fiabilit mais on peut distinguer le bug technique, imprvu et qui plante le systme du bug qui dnote dune inadquation par rapport au besoin. Les bugs rentrent donc les aspects la fois dadquation et de fiabilit, cet attributs chapote quatre sous attributs qui sont : - Maturit : Dsigne la capacit dun produit logiciel viter les pannes rsultantes derreurs dans le logiciel. La maturit est calcule comme tant le Temps Moyen Avant Erreur (Mean Time To Failure ou MTTF) mesur par rapport au code source. - Tolrance aux pannes : Dsigne la capacit maintenir le niveau de performance en cas derreur logiciel et de nonrespect des interfaces dinteractions avec le logiciel. Facilit de recouvrement en cas dfaillance. Densit et couverture de test :

Dsigne le nombre et la proportion du code source couverte par des tests, il existe des outils spcifiques qui permettent de produire des rapports sur cette couverture. - Stabilit du logiciel : Dsigne le nombre derreur imprvues empchant la fourniture du service, ce sont les bugs bloquants, distinguer des anomalies lis une inadquation par rapport au besoin.

c. Utilisabilit : Dsigne la capacit dun produit logiciel tre compris, appris, utilis et attrayant pour lutilisateur quand celui-ci est utilis dans certaines conditions. Dsigne leffort ncessaire pour son utilisation, les sous attributs de lutilisabilit sont : (oprabilit, facilit dapprentissage, comprhensibilit, attractabilit, conformit aux standards conventions et guides dutilisabilit). Il faut noter que lutilisabilit est un domaine en plein essor, notamment avec les interfaces tactiles qui ont grandement augment lutilisabilit des applications. d. Efficacit : Dsigne la capacit dun produit logiciel fournir des performances appropries, relativement la quantit de ressources utilises, dans certaines conditions. Les sous attributs sont : - Comportement temporel : Dsigne la capacit dun produit logiciel fournir des temps de rponses, de traitement et un dbit appropris quand ses fonctions sont utilises sous certaines conditions. Cela implique, bien sr, de dfinir ces conditions, cest dire la charge (surtout les pics de charges, puisque le systme sera dimensionn sur ce pic) estime par fonctions mais galement les volumes impliqus, et toutes les exigences non-fonctionnelles (cohrence des donnes, scurit, etc). - Utilisation des ressources : Dsigne la quantit et le type de ressources utiliss (CPU, disque, rseau, mmoire, etc.) et la dure associe quand ses fonctions sont invoques.

e. Maintenabilit : Dsigne la capacit dun produit logiciel tre modifi. Les modifications peuvent inclure des corrections, des amliorations ou des adaptations du logiciel des changements dans lenvironnement, les besoins et les spcifications fonctionnelles. Dsigne leffort ncessaire pour la modification du logiciel. Cest lattribut essentiel de lassurance qualit du logiciel car cest le plus immdiat et celui dont leffet sur les cots est le plus avr. Ses sous attributs sont : - Modificabilit : Dsigne la capacit dun produit logiciel permettre une modification spcifie dtre implmente. - Testabilit : Dsigne la capacit dun produit logiciel tre valid par rapport une spcification, les lments favorisant la testabilit pour chacune des trois tapes dun test sont : Le contexte du test : la facilit de la mise en place du contexte est favorise par : a. Une conception stateless (sans tat) et la distinction entre objets mutables et immutables. Lapproche fonctionnelle des traitements est trs positive quant la testabilit. b. Une base de donnes de rfrence avec des donnes de test ne variant pas c. La substitution aise de classes dimplmentation grce des frameworks dinjection de dpendances permettant de raliser des objets mock.

- Les actions testes : Une sparation entre traitements mtiers et persistance, afin de ne tester quune responsabilit la fois et un rollback (retour en arrire) de tous les traitements invoqus. - Les constats lissue de lexcution des actions : Un accs ais ltat des objets et les diffrents attributs qui les composent de manire gnrale, la sparation des responsabilits, le faible couplage et la forte cohsion favorisent une bonne testabilit.

- Couplage : Le couplage est une proprit indiquant le niveau de dpendances entre composants dun systme. Cest une proprit globale obtenant partir du calcul de dpendances entrantes et sortantes pour chaque composant. - Modularit : La modularit exprime la topologie de larchitecture avec le nombre de composants dpendants dun composant en particulier. Un composant pouvant tre, suivant le niveau de granularit dsir, un package, une classe ou une mthode. - Stabilit : Dsigne la capacit dun produit logiciel viter des effets imprvus suite la modification du logiciel. f. Portabilit Dsigne la capacit dun produit logiciel tre transfr dun environnement un autre. Lenvironnement peut inclure lenvironnement organisationnel, matriel ou logiciel. Un sous-attribut est linstallabilit qui peut tre rang avec lexploitabilit, cest dire une fois mon produit termin comment son excution et son exploitation seront elles facilites ? . 3. Mesure qualit logicielle:

3.1 Dfinition de la mesure du logiciel [3] : Il n'existe pas de dfinition prcise de la mesure de la qualit logicielle. Cela peut-tre la mesure de la qualit de la conception du logiciel, de la qualit perue par le client (ergonomie, ...), de la qualit du code source, de la facilit de maintenance, ... La qualit logicielle est en quelques sortes un assemblage de tous ces critres, des mesures ont t tudies depuis longtemps et plusieurs recherches sur des mesures ont t effectues depuis les annes soixante. Mais le problme le plus important est de choisir et appliquer des mesures dans le dveloppement de logiciel. Actuellement, il existe plusieurs dfinitions sur la mesure de logiciel : [5] Selon Barry Boehm : Mesure de logiciel est un processus continu de dfinir, de collecter et d'analyser des donnes sur le processus de dveloppement de logiciel et ses produits pour comprendre et contrler le processus et ses produits, et pour fournir des informations significatives pour les amliorer . Dans larticle Software Measurement: a necessary scientific basis , Norman Fenton a dfini une mesure du logiciel comme un processus par lequel les nombres ou les symboles sont assigns aux attributs des entits du monde rel de mme faon que les caractrise daprs des rgles bien dfinies. 3.2 Entits : Les entits peuvent tre un objet, par exemple une personne ou une spcification de logiciel, ou un vnement comme un voyage ou la phase de test d'un projet logiciel 3.3 Les entits de mesure : Il y a trois entits d'une mesure : processus, produit et ressource.

Processus: l'ensemble des activits relatives au logiciel. Produit: ce sont les artefacts, les livrables, ou les documents qui sont rsultats des processus. Ressource: ce sont des entits requises par les processus.

Des mesures de logiciel sont utilises pour mesurer des attributs (cits dans la deuxime partie : qualit logicielle) spcifiques des logiciels ou des processus de dveloppement. Les attributs mesurables peuvent tre internes ou externes. L'attribut interne d'une entit est ses proprits inhrentes, par exemple, le nombre de ligne de code d'un module. Par contre, l'attribut externe dpend de son environnement, par exemple, le temps d'excution d'un programme, qui dpend du programme et la configuration de l'ordinateur.

Les mesures peuvent tre classes en deux catgories: mesures directes et mesures indirectes. Une mesure directe ne dpend pas d'autres mesures d'autres attributs ou d'autres entits, on peut citer comme exemple la mesure de la longueur du code source (mesur par le nombre de ligne de code), la dure du processus de test (mesur par le nombre d'heures pass), le nombre d'erreurs dcouvertes pendant le processus de test, le temps qu'un dveloppeur a consacr au projet. Par contre, les mesures indirectes se basent sur dautres mesures, par exemple : la productivit d'un dveloppeur, elle dpend de la taille du module et le temps qu'un dveloppeur a mis pour le terminer. 4. Objectifs de la mesure logicielle [5]: La mesure logicielle peut permettre de prendre des dcisions l'heure, de surveiller le progrs de l'organisation par rapport son but d'amlioration et d'valuer les impacts des changements du processus. En effet les mesures peuvent apporter des points positifs pour plusieurs acteurs de la mise en uvre des logiciels: Concernant les chefs de projets, les mesures permettent de : Analyser des erreurs et des dfauts du produit. valuer l'tat davancement du projet. Driver le principe d'estimation. Dterminer la complexit du produit. Valider exprimentalement les meilleures pratiques.

Concernant dautres acteurs comme : Les clients: qui ont peu de contrle sur la production du logiciel, les mesures leurs permettent de dterminer la qualit et la fonctionnalit du produit livr. Les mainteneurs: les mesures les aident prendre des dcisions sur la rutilisation, r-engineering et le remplacement des codes.

Les dveloppeurs: en particulier les ingnieurs dans le cas des grands projets avec un long calendrier, les mesures les aident comprendre l'avancement des activits compositrices de leurs projets.

5. Modles de la qualit logicielle [6] : 5.1 Dfinition : Un modle peut tre dfini par un ensemble de vues concernant le produit, chaque vue est dcompose en plusieurs facteurs, Un facteur est dcompos en plusieurs critres, les facteurs sont en gnral des attributs externes (mais aussi des attributs internes : testabilit, efficacit), chaque critre est dfini par un ensemble de mtriques. Par exemple, dans le modle de Mc Call le facteur de fiabilit est dcompos en cohrence, prcision, tolrance aux erreurs et simplicit. 5.2 Modle de McCall : attributs Le fonctionnement du produit : Fiabilit Efficacit Intgrit Facilit demploi Les changements Maintenabilit Testabilit Flexibilit La transition Portabilit Rutilisabilit Interoprabilit Mesure de la qualit :

Ce modle utilise 41 mtriques pour mesurer les critres de la qualit, mesurer un facteur revient considrer une liste de conditions vrifier, la liste de conditions peut s'appliquer aux besoins (R), la conception (D) et l'implmentation (I), une condition peut tre vraie ou fausse. Exemple : Liste des conditions pour le critre compltude Des rfrences non ambigus (entre, sortie, fonction) [R, D, I] ; Toutes les rfrences de donnes (variables ou rfrences directes des adresses au moyen de pointeurs) sont dfinies, calcules ou lues de l'extrieur [R, D, I] ; Toutes les fonctions dfinies sont utilises [R, D, I] ; La conception est conforme aux besoins [D].

5.3 Modle ISO 9126 : Standard driv du modle de McCall, lvaluation de produits logiciels se repose sur sept facteurs appels caractristiques qui sont : convenance, exactitude, interoprabilit, scurit, maturit, tolrance aux pannes, possibilit de rcupration. 5.4 Modles prdictifs de qualit :

Figure 02 : Le modle prdictif de qualit. Caractristiques : Modle fix davance, modle spcifique ; Bote blanche, Bote noire ; Classification, rgression ; Classique, techniques dI.A (intelligence artificielle) ; Donnes historiques, expertise (thorique).

Constat : Certains types de modles viennent palier aux problmes spcifiques des autres types (acceptation, incertitude, etc.), la tendance est de proposer des modles boites blanches bass sur des techniques dI.A 6. Problmes des modles de qualit : Constat : Causes : Absence des outils pour construire des modles ; Grand nombre de modles de qualit propos dans la littrature, mais faible utilisation relle ; Les plus propos sont des modles statistiques ; Faible acceptation.

Raret des donnes provenant de vrais logiciels pour construire ou valider les modles ; Modles existants ne tenant pas compte de laspect des entres (incertitude, manque, distribution) ; Chaque modle reflte un contexte particulier ; Difficult de gnraliser, valider, et rutiliser les modles.

7. Comment mesurer la qualit logicielle : Sans mesure quantifie de la qualit, celle-ci ne pourra pas tre gre et comme le dit le gourou du management Peter Drucker : Whats gets measured gets managed. Malheureusement, le revers de la mdaille est qu partir du moment o une mtrique est dfinie, les dveloppeurs optimiseront cette mtrique au dtriment des autres mtriques qui seront suivies avec moins dattention voire pas du tout. Il est donc important de dfinir clairement les mtriques qualits suivies, en dautres termes il faut dfinir les exigences qualit par des
mtriques simples, peu nombreuses et pertinentes.

a. Premire tape : dfinir les exigences de qualit

Les mtriques, qui doivent tre simples peu nombreuses et pertinentes, peuvent tre abordes pendant la rtrospective lissue de chaque sprint. Les cinq mtriques fondamentales pour la qualit et qui permettent de raliser le radiateur qualit dun projet sont : - Complexit : La mesure de la complexit agrge en une seule valeur par ajout des intrications (dpendances cycliques) entre modules et de la complexit cyclomatique est une excellente mesure. Le respect des rgles de dpendances entre modules (technique mais surtout mtier) est un must-have et le cur de la mthode de mesure. - Respect des rgles de codage : Les rgles de codages fournissent un bon indicateur de la qualit du code source. Ces rgles de vrification statiques sont dtailles pour chaque outil. - Test coverage : Le test coverage permet de sassurer quune majorit du code source est teste avec des outils performants comme Clover, Cobertura ou Emma. Tous les tests doivent sexcuter avec succs. La traabilit des tests vers le besoin (sous forme de Use Case ou de User Story) est importante. - Stabilit : Elle peut tre suivie par la mesure du nombre de bug ventuellement par catgorie (bloquant, majeur, mineur). Cela permet de dterminer les fonctionnalits les plus instables et de dcider des actions correctives entreprendre. Cette mesure peut tre faite par unit de temps (nombre de bug par mois) mais galement par quantit de ligne de code et par nombre de jour homme dpens. Sans prtendre tre une mesure absolue, cest une mesure relative qui permet dvaluer les

diffrences entre les projets dune mme entreprise. Cette mme mesure peut dailleurs tre faite entre diffrents modules dune mme application. - Rsultats des revues de conception et de code : Pour chaque module, la note de synthse de la dernire revue est donne.
Le schma ci-dessous illustre un tel radiateur qualit :

Figure 03 : Radiateur qualit. b. Seconde tape : effectuer les mesures et produire le rapport qualit : Les mesures se font de manire rgulire afin de pouvoir suivre les volutions dans le temps. Le point important est de dfinir le seuil au-del duquel la correction est juge obligatoire et ce afin de ne pas augmenter la dette technique. Diffrents seuils permettent davoir un synoptique de la qualit : vert, jaune, orange, rouge. La dfinition de chacun des seuils est lapprciation de chaque quipe. d. Troisime tape : dautres mesures effectuer plus ponctuellement : Lefficacit, plus couramment dnomme performance, est un attribut important mais qui est valu de plusieurs manires :

- par du profiling : Notamment lors des revues de code et sur du code dont on sait pertinemment quil aura une influence importante sur la perception de lefficacit du logiciel. - par lanalyse des logs dexcution : Notamment ceux lis la persistance (logs des requtes SQL), car linteraction base de donnes reste la source principale des problmes de performances dune application de gestion. - Par des tests de charge : Qui demandent cependant un investissement important. Ils sont typiquement mens en milieu et fin de projet afin de respectivement corriger et valider les performances de lapplication. Complexit smantique : Une mesure trs importante mais encore immature. Afin dvaluer la charge cognitive ncessaire la comprhension dun code, la complexit est une premire mesure trs utile. Nanmoins, une mesure complmentaire concerne la qualit du nommage (le signifiant) permettant de dduire si celui-ci est facilement comprhensible et surtout sil est fortement reli au vocabulaire du domaine (et donc au signifi). Un outil produit donc le nuage de mots utiliss au sein du code source (nom de classe, de mthodes, de variable) et permet de vrifier son adquation avec le modle du domaine. Un tel outil existe mme sil demande mrir (paramtrage, utilisation standalone ou en intgration continue, etc.).

8. Exemple doutils de mesure de la qualit logicielle (Sonar) [1] : a. Dfinition : Sonar est un logiciel libre permettant de mesurer la qualit du code source sur les projets de dveloppement java. Sonar est distribu selon les termes de la licence LGPL v3. Le code source est analys suivant sept axes : Identification des duplications de code ; mesure du niveau de documentation ; respect des rgles de programmation ; dtection des bugs potentiels ; valuation de la couverture de code par les tests unitaires ; analyse de la rpartition de la complexit ; analyse du Design et de l'Architecture d'une application et en faire ressortir des mtriques orientes objet.

L'ensemble de ces mtriques qualit permettent d'valuer rapidement la dette technique de chaque projet. Une interface Web permet la fois d'administrer l'outil (exclusion de code source, activation des profils qualit, dfinition des seuils d'alertes, ) et de consulter les rsultats en croisant les indicateurs et en offrant plusieurs modes de restitution ( clouds, treemap, hotspots, timemachine..).

b. Principe de fonctionnement : Sonar s'appuie sur 3 composants :

un plugin Maven ou une tche Ant en charge de l'analyse du code source ;

10

une base de donnes dans laquelle sont stocks l'ensemble des rsultats des analyses ; et un site web pour la partie reporting et pilotage.

Cette architecture permet d'utiliser Sonar pour des audits de code ponctuels, mais galement dans le cadre d'une dmarche d'amlioration continue. L'utilisation d'un plugin maven pour la partie collecte de donnes permet en effet d'utiliser tous les moteurs d'intgration continue pour automatiser le lancement des analyses. c. Open source : De nombreuses briques open source existent qui permettent d'analyser le code source Java mais chacune d'entre elles requiert un effort de configuration. Sonar intgre la plupart de ces briques tout en rduisant le cot de mise en uvre et en permettant de croiser les rsultats. Sonar s'appuie notamment sur : Duplication de code : CPD - PMD ; Test unitaires et couverture de code : Cobertura, Clover (en), Emma (en), JUnit, Surefire ; Rgles de programmation : Checkstyle, PMD ; Bugs potentiels : FindBugs.

Concernant le niveau de documentation et les mtriques standards comme la complexit et le nombre de lignes de code, Sonar utilise son propre moteur d'analyse. d. Extensibilit : Sonar a t dvelopp en s'appuyant sur un cur extensible. Cela signifie qu'il est possible pour qui le souhaite d'tendre ce cur afin d'augmenter les fonctionnalits (ajout d'un nouveau langage, calcul d'une nouvelle mtrique, ajout de rgles de programmation). Le portail des plugins Sonar permet d'accder la liste des extensions existantes. Aujourd'hui, plusieurs extensions Open Source et commerciales permettent de couvrir les langages PHP, Flex, PL/SQL, Cobol, Natural, Abap et Visual Basic 6.

Figure 04: Interface du logiciel Sonar.

11

Conclusion :

La qualit doit tre mesure afin dtre gre et il est important de concentrer lattention de lquipe et des managers sur des mtriques agrges et pertinentes.

12

Bibliographie :

[1] www.wikipedia.com [2] www.Redson.com

[3] www.10net.com

[4] CAPERS, Jones, 2004. Software Project Management Practices: Failure Versus Success.

[5] FUTRELL, Robert T., SHAFER, Donald F., SHAFER, Linda I., Quality Software Project Management. Software Quality Institute Series_Prentice Hall, chapitre 21 Software Metric. [6] FENTON Norman, 1994. Software Measurement: a necessary scientific basis

13

14