Notion de qualité dans le logiciel

En mars 2020, Google publie Building Secure and Reliable Systems.

En préface, le livre démarre par cette question : "un système peut-il être considéré comme vraiment fiable [reliable] s’il n’est pas fondamentalement sûr [secure] ? Ou peut-il être considéré comme sûr s’il n’est pas fiable ?".

Cette question nous ramène à la notion de qualité dans le logiciel et ce document présente ici, dans les grandes lignes, les principaux critèques de qualité et nous invitons le lecteur à approfondir ce thème par l’ouvrage de référence, sur lequel cette étude est principalement basée, Conception et Programmation orientées objet (Bertrand Meyer).

Un bon logiciel métier est un logiciel qui a atteint ses objectifs, à savoir la satisfaction de ses utilisateurs quant à la qualité des services rendus et pour sa facilité d’utilisation, rapidité, robustesse etc.

Selon la catégorie de l’utilisateur, les critères d’appréciation peuvent varier. Par exemple le responsable des achats sera très satisfait si le logiciel de gestion de la chaîne logistique est livré à date prévue, et sans surcoût. Un chef d’atelier sera plus attentif à l’ergonomie du logiciel qu’à son coût, un DPO (pour Data Protection Officer) sera particulièrement vigilent à la protection des données personnelles, etc.

La satisfaction est fonction des intérêts de chacun, même si certains, comme la sécurité peuvent être transverses.

La qualité est une affaire de point de vue. Un informaticien chargé de maintenir le code d’une application, sera sensible à son architecture, à la lisibilité du code source.

Les points de vue peuvent se classer en deux catégories, ou facteurs, nommées externes et internes.

Les facteurs externes sont ceux perçus par les utilisateurs au sens large, c’est à dire ceux qui ne sont pas en contact direct avec le code source du logiciel. Les facteurs externes sont les seuls qui comptent en réalité car ils concernent la finalité du produit, sa raison d’être, cependant, le seul moyen d’atteindre des niveaux de qualités visibles satisfaisants pour l’utilisateur (facteurs externes), est de rechercher à atteindre les qualités cachées du logiciel : facteurs internes.

Voici quelques unes des qualités attendues : correction, facilité d’utilisation, rapidité d’exécution, extensibilité, couverture fonctionnelle, ponctualité, robustesse, réutilisabilité, compatibilité, portabilité, documentation.

C’est la première qualité attendue, si elle n’est pas remplie alors le reste ne compte pas.

Que ferais-je d’une voiture si elle ne peut pas me transporter d’un endroit à un autre ? Sa couleur, l’ergonomie de son tableau de bord sont autant de qualités que je ne saurais que faire.

Les méthodes garantissant la correction sont, en général, conditionnées.

On ne réinvente pas la roue à chaque projet. On réutilise des composants techniques et métiers maisons que l’on garantie mais aussi de tierces parties, parfois imposés par le client.

Les bibliothèques de base sont parfois écrites dans un autre langage que celui utilisé, le compilateur traduit-il correctement le code ? Nous trouvons ici deux classes de correction : une sémantique : le sens que le développeur prête au code source est-il conforme à la sémantique du langage ? - par exemple if ("PARFAIT" == etat) (etat une variable de type String) peut ne pas donner le résultat escompté - et une autre technique, concernant la correction de la traduction automatique du code source en un code exécutable.

La chaîne de responsabilités est organisée en tiers (collaboration horizontale) et en couches verticales :

La robustesse complète la correction.

Un cas est étiqueté d'anormal s’il n’est pas couvert pas la spécification.

Éviter les catastrophes, tendre à la mise en place d’un système garantissant une "dégradation harmonieuse".

Le mécanisme de traitement des exceptions favorise la réalisation de logiciel robuste.

Ce facteur de qualité est une application de la robustesse, dans le cadre de la cybersécurité.

Exemples de bonnes pratiques

Un problème d’autant plus pointu que le nombre de lignes de code du logiciel est grand.

Le contexte de forte concurrence, les fusions d’entreprise, l’évolution technologique entraîne souvent des changements majeurs des systèmes d’informations. Plus le logiciel est flexible, plus sa capacité de s’adapter aux changements de spécifications est forte.

Deux principes essentiels à l’amélioration de l’extensibilité :

On pourra s’interesser aux principes d’eXtrême Programming suivants :

Réutilisation de "bout de code", module, composants logiciels spécialisés appelés objets techniques ou objet métiers.

On pourra s’intéresser au principe suivant :

Exemple : Les formats de fichier d’un logiciel ouverts ou propriétaires.

i

Les ressources à préserver sont :

Par exemple la capacité d’un logiciel sous Windows à être porté sous Gnu/Linux.

La facilité d’utilisation est l’aisance avec laquelle des personnes, de formations et de compétences différentes, peuvent apprendre à utiliser les produits logiciels et à s’en servir pour résoudre des problèmes.

Sont concernés également la facilité d’installation, d’opération et de contrôles.

Conseil : Chercher la simplicité

Il est conseiller, en début de projet, de définir les limites de l’application, d’éviter la "course aux options".

Quelques Conséquences liées à la course aux options :

On pourra s’interesser à la méthode MoSCoW dans le but d’affecter des niveaux de priorités aux exigences.

Un super produit qui arrive trop tard peut complètement rater sa cible.

On distingue :

Durant la vie d’un projet, il est souvent question de compromis, et les facteurs de qualité n’échappent ps à cette règle.

Les qualités généralement attendues d’un logiciel est sa fiabilité et sa modularité.

Les facteurs de qualité présents dans ce document ne pourrait se passer de quelques recommandations de l’eXtreme Programming.