Dans notre dernier article à propos de la performance d’une équipe de développement, nous avons abordé l’alignement.

Aujourd’hui, nous traitons de la qualité.

La qualité est un aspect critique des logiciels et mesurer la performance de votre équipe de développement au travers de ce critère est fondamental.

Selon nous cela passe par 5 dimensions comme indiqué dans le schéma suivant :

La qualité est évidemment un sujet “en soi” avec ses propres défis d’organisation et de meilleures pratiques. Précédemment, nous avions développé dans un article les “Les meilleures pratiques du test logiciel« . Ce billet est d’ailleurs l’un des plus visités de notre blog, ce qui confirme l’importance du sujet.

L’idée ici n’est pas de traiter de l’ensemble du vaste sujet de gestion de la qualité mais plutôt de se concentrer sur la façon de mesurer la performance de votre équipe de développement sur cet aspect particulier de la qualité développement logiciel.

Fiabilité

Mesurer la fiabilité d’une application peut s’avérer relativement simple même si les comparaisons ne sont pas toujours faciles ; cette information étant la plupart du temps confidentielle au sein des entreprises.

Fondamentalement, le meilleur indicateur est le nombre de bogues ouverts et l’évolution au fil du temps. Evidemment moins il y a de bogues mieux c’est. Mais attention, le “zéro bogue” est souvent le signe d’une insuffisance des tests ou d’une non utilisation de l’application, à moins que vous n’atteignez ce résultat sur le long terme. Et, en général, cela signifie qu’il y a peu d’évolutions.

Ce qu’il est important de surveiller au fil du temps lorsque vous livrez un logiciel c’est

• La tendance du nombre de bogues : elle peut être élevée au moment où de nouvelles fonctionnalités sont livrées et doivent se réduire régulièrement ensuite,
• La répartition de l’importance des bogues : critique, majeur or mineur,
• La cohérence du ratio bogue/ligne de code quand vous délivrez un nouveau logiciel

Un indicateur important que nous allons aborder à propos du support est le temps nécessaire pour corriger un bogue. Si ce temps est élevé par rapport au nombre de bogues, c’est le signe d’une mauvaise conception et cela aura probablement de l’impact sur la fiabilité.

La conséquence d’un manque de fiabilité peut être désastreuse, surtout pour les éditeurs de logiciels. Le coût du support d’une application peut en être impacté dramatiquement, il y a quelques précédents d’éditeurs qui ont disparu ou ont été sévèrement impactés par manque de fiabilité sur une version spécifique de leur logiciel.

Performance

Nous sommes tous des utilisateurs de logiciels. Qui n’a jamais pesté contre une application lente ou un site web qui ne répond pas ?

C’est évident lorsque nous sommes du côté utilisateur, mais certains développeurs ont tendance à minimiser l’importance d’une interface utilisateur réactive. Au final et quelle que soit la raison technique sous-jacente ou la qualité du logiciel, les utilisateurs n’utiliseront pas une application trop lente.

Par conséquent, lorsque vous codez, vous devez opter pour les options techniques qui procurent une bonne performance pour les utilisateurs. Cela ne signifie pas de ne prendre en compte que ce critère ou de tout écrire en langage assembleur, mais d’optimiser les composants qui ont un fort impact sur la performance : les connexions à distance, l’accès aux données, la réduction appropriée des jeux de données manipulés, la parcimonie dans l’utilisation des boucles (notamment imbriquées).

Si certains traitements de données sont longs il est judicieux de réfléchir à des mécanismes asynchrones, au fractionnement des données ou à d’autres options de conception pour éviter une expérience pénible pour vos utilisateurs.

La conséquence d’un manque de performance sera la non-acceptation de l’application par l’utilisateur, quelle que soit la bonne mise en œuvre des fonctionnalités. Dans le cas d’une application interne, cela causera un conflit dans l’entreprise. Dans le cas d’un produit destiné à être vendu… vous ne le vendrez simplement pas !

Scalabilité

On a tendance parfois à confondre performance et montée en charge (scalabilité). Ce sont 2 sujets différents qui requièrent des options de conception contradictoires.

La scalabilité est la capacité de votre application à croître sans limite, à la fois en nombre d’utilisateurs pris en charge qu’en volume de données à gérer. Par exemple Access est une SGBD très performante mais pas scalable notamment en nombre d’utilisateurs.

En haut, est représenté un système non scalable, en bas, un système scalable.

Avec l’émergence d’internet, et donc des applications Saas et Cloud, la scalabilité revêt souvent une importance supérieure à la pure performance. C’est la plupart du temps un défi technique que d’avoir à gérer un nombre énorme d’utilisateurs partageant les mêmes données.

Avec la diminution du coût du matériel, multiplier le nombre de machines est nettement moins coûteux que la sur-optimisation de la performance avec du temps de développeurs. Mais l’ajout de machines ‘en soi’ ne fonctionne pas, il vous faut concevoir votre application de sorte que vous puissiez partager le travail entre ces machines tout en maintenant la cohérence.

Mesurer la scalabilité de votre application est un processus relativement coûteux. Cela requiert la mise en place de plateformes complètes dédiées au processus d’évaluation de votre application en fonction de la charge d’utilisateurs et de données.

Cela requiert également les outils et compétences appropriés pour interpréter correctement les mesures et être capable d’évaluer les éléments dont vous avez besoin en fonction de la croissance de votre base d’utilisateurs. Ce processus est connu sous le nom de planification de la capacité (capacity planning en anglais).

Le manque de scalabilité peut être la cause de problèmes commerciaux majeurs. Si l’application ne peut pas accueillir de nouveaux utilisateurs et que l’application n’a pas été conçue pour, il n’y a en général pas de solution à court terme.

Exploitabilité

L’exploitabilité est la capacité d’une application à être rapidement corrigée en production.

La bonne gestion des erreurs et exceptions est un élément clé comme mentionné dans notre article “Les bonnes pratiques de l’instrumentation du code« .

Une application conçue pour l’exploitation doit être capable de faire face à certains évènements impromptus comme les pannes de réseaux, la bande passante ou les problèmes matériels.

Pour mesurer les résultats sur cette dimension, nous recommandons de mesurer le temps moyen de correction d’un bogue :

• Trouver ce qui s’est produit,
• Trouver la ligne de code concernée,
• Être capable d’isoler les données utilisées dans le scénario qui cause l’erreur,
• Identifier le scénario non prévu initialement,
• Proposer une correction compatible avec le code existant.

La rapidité avec laquelle vous pouvez reproduire le problème est également un indicateur clé pour le support de votre application.

Penser à l’après-sinistre et à la manière de restaurer une application dans le cas d’évènements majeurs fait partie de cette dimension également.

La conséquence d’une application peu exploitable se traduit par un risque d’indisponibilité. Au-delà des coûts induits et des problèmes d’image une interruption de service peut être très impactant dans certaines entreprises où le chiffre d’affaires est directement corrélé au bon fonctionnement du système.

Ergonomie et facilité d’utilisation

L’ergonomie et la facilité d’utilisation constituent également un pilier majeur de la qualité.

Les mesurer et effectuer des comparaisons n’est pourtant pas si simple. Les gens ont tendance soit à sous-estimer l’importance de l’ergonomie soit, au contraire, à attendre de toutes les applications la même facilité d’utilisation que les sites web grand public majeurs, alors que ceux-ci sont développés avec des dizaines de millions de dollars dont on ne dispose pas forcément.

Certaines applications comportent de plus des complexités intrinsèques à leur problématique susceptibles de requérir une connaissance très spécifique, et pour lesquels il n’est pas toujours aisé de définir une ergonomie simple et intuitive.

Lire la suite : Mesurer la performance d’une équipe de développement – Partie 3