Qualité logicielle et logiciel libre

D’après la définition de Wikipédia, « la qualité logicielle est une appréciation globale d’un logiciel, basée sur de nombreux indicateurs: la complétude des fonctionnalités, la précision des résultats, la fiabilité, la tolérance de pannes, la facilité et la flexibilité de son utilisation, la simplicité, l’extensibilité, la compatibilité et la portabilité, la facilité de correction et de transformation, la performance, la cohérence et l’intégrité des informations ».

quality survey

Indicateurs de qualité logicielle

La norme ISO 9126 définit six groupes d’indicateurs de qualité des logiciels :

  • la capacité fonctionnelle:  capacité qu’ont les fonctionnalités d’un logiciel à répondre aux exigences et besoins explicites ou implicites des utilisateurs. ;
  • la facilité d’utilisation, qui porte sur l’effort nécessaire pour apprendre à manipuler le logiciel: facilité de compréhension, d’apprentissage et d’exploitation ;
  • la fiabilité: capacité d’un logiciel de rendre des résultats corrects quelles que soient les conditions d’exploitation (dont la tolérance aux pannes) ;
  • la performance: rapport entre la quantité de ressources utilisées (moyens matériels, temps, personnel), et la quantité de résultats délivrés: temps de réponse, débit et extensibilité ;
  • la portabilité: aptitude d’un logiciel de fonctionner dans un environnement matériel ou logiciel différent de son environnement initial (facilité d’installation et de configuration).

La recherche en informatique

Le problème n’est pas nouveau: depuis les années 1970 la recherche en informatique s’est intéressée à l’idée décrire du code à partir de spécifications et d’en prouver sa validité à partir de logique mathématique. Cela a donné lieu à un foisonnement de recherche qui visent à employer les méthodes formelles pour s’approcher de cet objectif: il a fallu plusieurs décennie pour arriver aux exploits d’aujourd’hui qui sont la production d’une chaine de compilation certifié, la vérification de code ou la certification d’un noyau de système exploitation.

Mais la complexité du code développée aujourd’hui et la vitesse avec lequel il change, oblige à la mise en place de tests systématiques, et une lisibilité, maintenabilité et évolutivité du code qui ont fait également l’objet de nombreux recherches dans l’architecture, et le processus de développement et de maintenance des logiciels avec le besoin de fournir des mesures exploitables. Le logiciel libre est un moyen qui s’est généralisé parmi les chercheurs pour partager leurs résultats et faciliter les contributions.

On peut se référencer pour cela au livret bleu du logiciel libre sur la qualité logiciel de Systemics (voir référence en bas) dont cet article est largement inspiré et qui liste les grands projets de recherche dans le domaine.

L’informatique embarqué critique

Malgré ces exploits, l’utilisation de ces méthodes restent anecdotiques dans le monde industriel, qui y ont recours que dans des environnements hautement critiques. Dans ces domaines des normes obligent les industrielles à un effort de qualification (et donc couteux) pour des exigences de fiabilité (transport, avionique) ou de sécurité (carte à puce, télécommunication): l’activité de programmation y est soumise à des règles très contraignantes (et donc très couteuses): voir l’article sur la norme DO 178 .

Dans ces environnements, les industriels ont besoins de s’appuyer sur des standards pour la certification et aux  preuves formelles pour poser les bases de la qualité logiciel.

L’informatique en milieu industriel non critique

Dans le contexte non critique, on trouve des niveaux d’exigence divers: SI d’entreprise et d’administration, transaction bancaire sensible, informatique embarquée non critique.

Ces cas sont caractérisés par une grande quantité de codes, une inter connectivité entre les systèmes croissante et un large recours aux tests, avec une combinatoire impossible à couvrir de manière exhaustive que ce soit pour des méthodes manuelles ou automatisées.

L’enjeu devient donc d’optimiser les moyens de tests pour minimiser les risques; on a alors recours à des méthodes qui visent à ce que le code ait un niveau jugé suffisant pour répondre aux besoins, plutôt que de le valider par les méthodes formelles. Pour cela on cherche à garantir le processus de développement par l’utilisation de bonnes pratiques, en corrigeant et en traçant par exemple les erreurs pour éviter toute régression. La qualité du logiciel est améliorée en industrialisant le processus de développement avec des métriques et différents types de tests. On parle alors de forge logicielle. Ces forges ont été largement répandues par le développement de logiciel libre. On parle alors d’ingénierie collaborative qui caractérise le monde du logiciel libre avec les technologies associes: forges logicielles, démarches agiles, cloud, intégration continue …

Les méthodes agiles et les logiciels libres

L’apparition des processus agiles ont été popularisé dans les année 1990 par les grands acteurs du Web. Contrairement aux méthodes traditionnelles qui visent à anticiper et découper au maximum les différentes étapes de développement, les méthodes agiles visent sur la communication tout au long du projet entre les différents intervenants. Avec le DevOps, le processus est même traité en un seul flux depuis les besoins utilisateurs  jusqu’aux opérations (exploitation).

La qualité logicielle est alors traitée différemment: les processus traditionnels tentent de mesurer et valider en aval alors que les méthodes agiles en font un pré requis permanent tout au long du projet: l’imprévu est alors partie intégrale de la qualité logicielle.

Parmi les pratiques popularisées par les méthodes agiles, la principale est le développement piloté par les tests (TDD) : les tests, généralement automatiques, sont écrits avant même la réalisation de la fonctionnalité, ce qui force le développeur à réfléchir en permanence sur la qualité de son code, en plus d’éviter les régressions. Les plateforme d’intégration continue permettent de rejouer les tests unitaires et de non régression pour constituer de véritable chaines de qualification en continue.

Une autre pratique est celle du pair programming: l’idée étant que deux développeurs travaillent sur la même machine qui garantir de façon plus efficace le code produit; bien que cette pratique reste assez rare (car couteuse),  le « peer-reviewing » est plus répandue : cela consiste à inspecter le code produit par les pairs ce qui est plus efficace que les tests car cela permet d’éliminer de 80 à 95% des anomalies contre 30% par les tests.

Ces pratiques se sont largement répandues grâce à la disponibilité des logiciels libres (Git, jenkis, xUnit…) mises à disposition par les communautés des développeurs.

Utilisation des logiciels libres

Un autre facteur de qualité est le démocratisation de l’utilisation de logiciels libres et ouverts: plutôt que de grand projets centralisé avec du code source gardé secret, de plus en plus de projets en logiciel libre sont intégrés comme briques logiciels ; l’intérêt est que ces briques sont alimentées par des contritions venant de toute part et accessible à quiconque ce qui est gage de qualité car potentiellement ils sont revus par des milliers de personnes. Le défi étant alors de les intégrer ensemble sur des systèmes différents.

Les métriques

Autres éléments importants, les métriques qui permet de mesurer la qualité logicielle d’un code source. Le document en référence, « métriques et critères dévaluation de la qualité du code sources d’un logiciel« , vise à introduire les métriques et les critères fréquemment utilisés pour caractériser et évaluer la qualité d’un code source. Une attention toute particulière  a été portée sur l’importance et les limites de ces paramètres. Voici la liste des métriques qui ont un intérêt élevé:

Métriques standards:

  • Complexité cyclomatique:  mesurer la complexité d’une fonction (max 10);
  • Couverture de code: proportion  du  code  source couverte par des tests,   généralement  automatisés (80%)
  • Afferent and efferent coupling: mesure respectivement le nombre de références vers une classe et le nombre de types que la classe « connait » (max 20)
  • Instability: niveau de résistance au changement
  • Abstractness: niveau d’abstraction par rapport aux autres classes
  • Distance  from  main  sequence: équilibre du module entre l’abstractness et l’instability (max 0.7)
  • Lack of Cohesion Of Methods (LCOM): niveau de cohésion d’une classe
  • Relational Cohesion:  nombre moyen de relations internes à un module (entre 1.5 et 4)
  • Specialization index: degré de spécialisation d’une classe (max 1.5)
  • Number of coding rules violations : violation des règles de codage dépendantes du    langage ou des technologies utilisés

Critères supplémentaires:

  • Maintenabilité: directement liée à l’architecture logicielle, elle doit être simple et efficace
  • Évolutivité: l’architecture logicielle doit permettre une bonne évolutivité
  • Fiabilité:  nombre de défaillances rencontrées dans un intervalle de temps donné. inclut également la tolérance aux pannes.

Les outils open source

Voici une sélection d’outils non exhaustive pour une bonne qualité logicielle selon les bonnes pratiques décrits précédemment: agilité et travail collaboratif

 

Références:

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s