Un logiciel de bonne qualité est un logiciel qui fonctionne, bien sûr, mais pas seulement, il doit aussi répondre aux attentes, être facile d’utilisation, performant, être capable d’évoluer en fonction des besoins, et aussi bien évidemment, être maintenable.
Au-delà des actions de vérification, un environnement propice à la gestion de la qualité se construit dès la conception du logiciel. Un code bien conçu sera plus facilement compréhensible, réutilisable, maintenable et évolutif. En conséquence les anomalies dues aux incompréhensions ou à la complexité seront réduites.
Évaluation de la Qualité Logicielle
L’étape préalable à l’assurance de la qualité d’un logiciel est de respecter les règles de l’art du développement : un code uniforme respectant des standards de codage, une gestion décentralisée du code source, en passant par l’automatisation de toute la chaîne de construction d’un logiciel. Ces bonnes pratiques constituent la base pour gérer efficacement de la qualité logicielle de votre projet.
Mais comment savoir si ces bonnes pratiques ont été appliquées, comment évaluer la qualité d’un logiciel ?
Capacité fonctionnelle
Evaluer le taux de couverture des fonctionnalités : le logiciel doit respecter les spécifications et surtout répondre aux attentes de l’utilisateur. Vous pouvez créer une matrice de respect des exigences, lister les fonctionnalités et vérifier si elles sont implémentées et respectées avec des critères de type : aptitude, exactitude, interopérabilité, sécurité…
Fiabilité
Vérifier l’aptitude du logiciel à maintenir son niveau de service dans des conditions précises et pendant une période déterminée et notamment
- La fréquence des défaillances dues à des bugs
- L’aptitude à maintenir un niveau de service satisfaisant en cas de problèmes quel qu’il soit
- La capacité à rétablir son niveau de service et de restaurer les données directement affectées en cas de défaillance, en combien de temps ? avec quel effort ?
Le logiciel doit résister aux erreurs de l’utilisateur et les tests suivants doivent être concluants :
- Tests Unitaires : menés par le développeur lui-même, ils consistent à vérifier la bonne exécution des fonctions dont il a la charge.
- Tests d’Intégration : menés par un testeur dédié, ils visent à tester la mise en commun de plusieurs composants et l’enchaînement de processus complets au-delà des simples fonctions unitaires.
- Tests du système complet, qui consistent à dérouler des scénarios complets, représentant les cas d’utilisation du logiciel, sans se préoccuper de l’implémentation ou des composants sous-jacents. Lors de l’évolution du système, on rejouera ces scénarios afin de valider la non-régression.
Facilité d’utilisation
Prendre en compte les feedbacks des utilisateurs (formulaire de contact, téléphone, forum…) pour améliorer en continu l’expérience utilisateur
Effectuer des tests sur des groupes de personnes
- Les tests d’acceptation, menés avec des utilisateurs pilotes, afin de valider l’adéquation aux besoins et la facilité d’adoption par ceux qui devront utiliser le logiciel régulièrement.
- Les tests d’ergonomie. Ces tests incluent tout autant la facilité d’utilisation que l’apparence visuelle
Performance
Vérifier le temps de démarrage : c’est une des clés voire la clé de succès de votre logiciel notamment pour les nouvelles générations habituées à obtenir tout de manière rapide et zappant sans état d’âme si l’efficacité n’est pas là.
S’assurer d’un temps d’exécution satisfaisant pour les tests suivants
- Les tests de performance consommation CPU, évolution de l’utilisation mémoire, nombre de requêtes par seconde, flux d’entrée/sortie… Le test de performance détermine la bonne exécution en mesurant les temps de réponse sans contexte particulier. Dans le cas d’un test de performance continu, il démarre dès le début des phases de développement, et est adapté à chaque étape du cycle de vie de l’application, jusqu’aux tests de charge complets.
- Les tests de montée en charge doivent être distingués des tests de performance et réalisés avec des outils permettant de simuler de nombreux clients simultanés. En augmentant le nombre d’utilisateurs par paliers, il détecte les éventuelles limites en capacité du système, pour valider la qualité de service avant déploiement
Maintenabilité
Les points à vérifier sont notamment
- Faculté d’analyse : facilité à diagnostiquer les déficiences, leurs causes ou à identifier les parties à faire évoluer
- Faculté de modification : facilité à modifier, remédier aux défauts ou à prendre en compte l’environnement
- Stabilité : facilité à anticiper les risques éventuels lors de modifications
Vous devriez être en mesure d’évaluer un projet et sa complexité sur la base des éléments suivants :
- Nombre d’entités métier,
- Nombre de règles métier simples (au sein d’une entité),
- Nombre de règles métier avancées (combinant plusieurs entités par exemple),
- Nombre d’éléments pour l’interface utilisateur (écrans, pages web),
- Nombre de rapports (ou états),
- Nombre d’interfaces externes,
- Nombre de calculs ou processus de traitements par lots,
- Nombre de variations technologiques de chaque composant (client -riche, page web, version mobile, technologies de base de données, utilisation d’un stockage « cloud »).
Le nombre de lignes de code écrites à la main voire inutiles influent directement sur les coûts de maintenance.
L’automatisation permet non seulement de limiter ce risque mais aussi de respecter les règles de codage et de conception.
Qualité Logicielle : comment l’anticiper et la gérer ?
Voici quelques actions à mener pour vous aider dans cette démarche.
Définir un référentiel de bonnes pratiques de code
Un code uniforme, simple, court respectant les règles de l’art est non seulement plus facile à maintenir mais il est aussi plus facile à appréhender pour les équipes de développement. Il est donc primordial de définir un référentiel commun sur l’utilisation des langages de programmation dans vos équipes : Mise en forme, constructions, appels d’API, sécurité, persistance des données, localisation, cache de données, règles métier, convention de nommage … tout doit y passer.
Au-delà de ces bonnes pratiques de code, la mise en place d’indicateurs pour le suivi des anomalies, et de traces pour leur analyse permet de les traiter plus efficacement : lorsqu’une erreur se produit dans le logiciel, il est important de fournir une indication la plus claire possible sur l’événement et le contexte associé, de façon cohérente et compréhensible. La maintenance en sera grandement simplifiée
Lire aussi | Sensibiliser les équipes à la Qualité Logicielle
Adopter une gestion décentralisée du Code Source
Des systèmes tels que Git permettent aux équipes de collaborer facilement de façon décentralisée.
Chaque personne contribue sur sa propre copie du dépôt de code, et peut dès qu’elle le souhaite/doit pousser ses modifications sur le système centralisé. L’utilisation des branches permet d’isoler facilement les changements apportés par chaque personne et d’utiliser les fusions pour les intégrer dans la branche de développement principale. La productivité des équipes est optimisée, elles peuvent ainsi avancer sur leurs tâches respectives, travailler simultanément sur un même fichier ou valider une partie du travail sans impacter celui des autres.
De plus, cette méthode permet d’observer finement et facilement les modifications apportées par une personne sur le code afin de les fusionner sur une branche de développement et de mettre en place des revues de code entre les différentes personnes de l’équipe. La revue de code est un excellent moyen de :
- Échanger sur les bonnes pratiques
- Former les développeurs débutants
- Détecter et corriger les anomalies
- Favoriser la collaboration
- Maintenir un haut niveau de qualité du code
Chaque développeur dispose d’une version locale du code source, il peut suivre l’historique des modifications et surtout revenir à une version antérieure en cas d’erreur ou de perte d’une partie du code source. En outre, dès lors que plusieurs personnes travaillent sur le même code source, la gestion de projet est optimisée.
Mettre en place des tests automatisés
Le test automatisé a pour objectif de minimiser autant que possible les efforts de tests grâce aux scripts. … Automatisés, ils peuvent être rejoués à tout moment. Le caractère répétitif permet non seulement de tester en continu mais aussi de tester plus et mieux notamment de tester manuellement des scénarios plus avancés, ainsi que de pouvoir tester à nouveau l’ensemble du système en cas d’évolutions techniques ou fonctionnelles structurantes impactant l’ensemble du système. C’est notamment le cas pour les tests unitaires, les tests d’intégration ou les tests de non-régression.
Ecrire des tests permet de vérifier le comportement attendu par votre code.
A chaque fois qu’une modification est introduite dans le système de gestion de sources, des tests automatiques s’exécutent rapidement dans un environnement le plus proche possible de celui utilisé en production pour valider le bon fonctionnement du système.
Documenter l’architecture du code
Documenter l’architecture du code c’est fournir le mode d’emploi pour comprendre le découpage de l’architecture, les principaux composants, leurs sous-composants, et leur orchestration, qui appelle qui, … cette documentation doit expliquer les concepts-clés du code, schématiser les composants et leurs dépendances, décrire les commandes pour jouer les tests, …
Ecrire de la documentation, tout comme écrire des tests, doit faire partie intégrante du quotidien d’un développeur.
Un code avec une documentation à jour sera plus facile à maintenir. Il constitue un outil de communication efficace pour les équipes et un gain de temps considérable pour comprendre le code.
Le point de départ peut s’avérer être le rassemblement des éléments suivants
- Les documents liés aux méthodes agiles : compte-rendu de rétrospectives, axes d’amélioration, correspondance sprint/version/fonctionnalités …
- La définition des termes métiers et les règles associées: le domaine métier est parfois plus complexe à appréhender que le code lui-même, surtout pour un débutant.
- Un plan d’architecture matérielle et système : serveurs ou composants Cloud, configurations logicielles, plateformes (dev/test/pré-production).
- L’architecture et la structure du code : surtout si le framework est maison et basé sur une architecture particulière, il est intéressant de définir le chemin d’exécution : point d’entrée, exemple de cheminement des informations, couches chargées de la validation des données, de la persistance, de la sécurité etc
- Modèle de données de la base de données : avec par exemple les valeurs possibles pour les colonnes. On peut aussi lister les règles qui existent entre deux colonnes (valeur d’une colonne qui dépend de la valeur d’une autre colonne). Certains outils facilitent la création de cette documentation (tables, colonnes, contraintes, description des objets) en se basant sur des annotations des objets.
- Procédures et check-lists : étapes à suivre lors du déploiement, de la création de branches, de la modification de code spécifique, des code-review et check-list des bonnes pratiques concernant la sécurité par exemple.
- Change-log des versions : utile pour repérer rapidement les changements majeurs et fonctionnalités de chaque version.
- Roadmap : pour donner la vision avec les dates importantes (mises à jour, déploiements, réunions …). Il peut s’agir d’un planning partagé avec les équipes.
Mais aussi
- Jeux de tests : quel utilisateur possède quel droit et quelle configuration sur quelle plateforme ?
- Documentations externes des outils : lien vers les tutoriels d’initiation aux outils (Git, Frameworks…)
- Boite à idées : ou application web de mind-mapping pour envisager toutes les solutions aux problèmes rencontrés et pouvoir en débattre en sprint.
Plus la documentation est structurée et tenue à jour, plus elle sera un véritable atout pour mener à bien un projet sans dérapage majeur.
Déployer une intégration continue
Mener un projet sans intégration continue, c’est un peu comme creuser un trou sans pelle. L‘intégration continue, c’est surtout l’automatisation de toute la chaîne de construction d’un logiciel
L’objectif de cette approche moderne est de progresser par étapes afin de concevoir le processus de développement plus efficacement et de pouvoir réagir aux modifications avec flexibilité.
Les développeurs intègrent leur code terminé une ou plusieurs fois par jour dans le sytème de gestion des sources, et en quelques minutes, le code source est accessible à tous. Si l’on découvre une erreur de « compilation » , de construction d’un composant du logiciel ou de certains tests automatisés, elle peut alors être immédiatement localisée et corrigée rapidement.
Finalement, l’intégration continue permet surtout de :
- Avoir un processus automatique bien défini pour diminuer le risque d’erreurs « humaines » liées à une construction manuelle du logiciel.
- Diminuer le risque de régressions et de recevoir une notification, si vos tests ne passent plus suite au dernier incrément de code.
- Générer des mesures sur la qualité de votre code pour piloter la qualité de vos projets.
Vous l’avez certainement compris, bâtir une stratégie efficace de gestion de la qualité logicielle nécessite un terreau fertile. L’aspect humain est primordial tout comme la collaboration et la mise en place des bonnes pratiques et des méthodologies de conception et de développement.
Qualité Logicielle : l’impact de l’Agilité et du DevOps
Créer de la valeur pour l’entreprise
La méthodologie agile peut peut-être se résumer à 2 mots ‘interaction’ et ‘itération’ : avoir une interaction avec le métier et prendre les bonnes décisions, avoir toutes les compétences dans l’équipe, réaliser un produit conforme aux attentes et le tester régulièrement, le montrer aux parties prenantes et réajuster au fur et à mesure.
La qualité est une des composantes centrales de la méthodologie agile dont les bénéfices sont indéniables et incontestés.
Sans changer les règles de développement et donc sans pénaliser la qualité, l’agilité permet à l’équipe de livrer en priorité les fonctionnalités attendues, en fonction du marché et des besoins et, ainsi, de créer de la valeur pour l’entreprise.
En adaptant l’effort au besoin, en évitant la sur-qualité et en maximisant le retour sur investissement tout en étant réactif, la méthodologie agile privilégie une mise en œuvre pragmatique de la qualité avec, en ligne de mire, la satisfaction des utilisateurs.
Qualité, productivité et réactivité sont donc intimement liées de même que gestion des priorités, échange, communication et collaboration.
Evidemment, les bonnes pratiques et toutes les techniques de développement consistant à créer un code utile, robuste, durable, pérenne et documenté vont également contribuer à améliorer encore la qualité.
Et si cette recette qui fonctionne sur les développeurs était appliquée aux équipes d’exploitation ?
En embarquant davantage le métier en amont et en prolongeant ces principes d’agilité en aval avec les équipes de déploiement et les Ops, la démarche DevOps est née.
Apprentissage et amélioration continue
Tout comme l’Agilité, DevOps n’est pas une finalité en tant que telle. Il est plutôt question d’apprentissage et d’amélioration continue. Au-delà de la problématique de livrer plus de logiciels, il faut livrer des logiciels de meilleure qualité plus rapidement, sans sacrifier la fiabilité et la stabilité.
Pour s’assurer du maintien de cette qualité en permanence, la pratique de tests doit également être menée en continu. L’entreprise gagne en flexibilité et améliore la qualité de service pour ses clients en temps réel et de manière automatique.
L’automatisation est également une des clés de la réussite. Les bénéfices de l’industrialisation des développements et des processus associés sont multiples et notamment :
- La réduction des temps de déploiement : avec une incidence directe sur les coûts des projets de développement.
- La réduction de l’intervention humaine : limite les risques d’erreurs et, surtout, donne l’opportunité aux développeurs de se focaliser sur des tâches à plus haute valeur ajoutée.
Des synergies intéressantes peuvent être obtenues lorsque la démarche s’intègre dans un processus de livraison continue. La livraison et le déploiement continus permettent non seulement, de produire des solutions logicielles sur des cycles courts mais aussi de s’assurer en permanence que chaque modification apportée n’a pas ou n’aura pas d’incidence sur le bon fonctionnement
C’est également un changement culturel qui doit s’opérer pour permettre aux équipes d’être soudées, d’avoir les mêmes objectifs fondamentaux et de collaborer efficacement en instaurant, par exemple, les revues de code et le pair programming. Un des secrets de la réussite est de donner confiance aux équipes pour qu’elles trouvent elles-mêmes leurs solutions et se les approprient. En rapprochant les équipes, on crée une dynamique vertueuse et de l’engagement !
Enfin, l’amélioration continue implique de mettre en place les KPI y compris lorsque le logiciel est opérationnel :
- Pour mesurer : en incluant dans la boucle les équipes de support qui sont en première ligne des remontées client
- Mais aussi partager les succès : notamment l’optimisation du temps passé sur des opérations automatisées, l’investissement de ce temps sur des tâches à plus forte valeur ajoutée ou encore toutes les données liées à l’amélioration de l’expérience client.
Avec quinze ans d’expérience dans le développement de logiciel sur-mesure, notre valeur réside dans notre expertise pointue en conseil alimentée, au fil des années, par notre expérience des projets d’envergure : logiciels sur mesure, migration vers le Cloud Azure, audit applicatif, méthodologie agile, processus DevOps, mais aussi transformation digitale et édition d’outils de productivité.
Passionnés et experts du développement, chez SoftFluent nous pensons que le logiciel est un formidable levier du succès des sociétés. Nous partageons nos réflexions et publions régulièrement des livres blancs. Si la qualité logicielle vous interpelle, le livre blanc ‘La performance d’une équipe de développement’ devrait vous intéresser.
