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.

Des leviers existent pour évaluer la qualité logicielle, notamment :

  • Nombre de tests qui réussissent (tests unitaires, tests d’intégration, tests UI…) : plus les tests sont automatisés, moins il y a de bogues. Moins de bogues signifie un logiciel plus fiable et une capacité des équipes à le faire évoluer optimisée
  • Taux de couverture des fonctionnalités : respect des spécifications et capacité à répondre au problème de l’utilisateur
  • Feedback des utilisateurs et tests d’acceptation : facilité d’utilisation
  • Temps de démarrage et d’exécution des principales fonctions : optimisation des temps de réponse et capacité à monter en charge
  • Complexité du code et respect des bonnes pratiques : en particulier le code inutile influe directement sur les coûts de maintenance de même que la capacité à diagnostiquer un problème et à le corriger

 

 

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.

Comment anticiper sa qualité logicielle?

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

 

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, …

schéma exemple architecture de code

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.
A lire sur le même sujet : Automatiser ses développements

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.