Technologies de l'information
Article
Nouvelle
Étude de cas
Portrait de formateur

Comment trouver l’équilibre entre livraison rapide de valeur et qualité logicielle (1/2)

Michel Benoit
Comment trouver l’équilibre entre livraison rapide de valeur et qualité logicielle (1/2)

« Les développements rapides et peu soucieux de la qualité produisent généralement des années de maintenance et d’évolutions coûteuses » (Ward Cunningham)

Avec Michel Benoit, spécialiste TI et en particulier de l’assurance qualité, voyons comment l’AQL peut atteindre son objectif, à savoir fournir de la valeur à grande vitesse sans sacrifier la qualité ou la sécurité.

L’Assurance qualité – le parent pauvre du développement logiciel

Aujourd’hui 75% du budget consacré aux technologies de l’information sert à la maintenance et aux coûts opérationnels. Il ne reste donc que 25% du budget disponible pour créer de la valeur et répondre aux besoins des clients. En 2016, le Government Accountability Office qui est l'organisme d'audit, d'évaluation et d'investigation du Congrès des États-Unis, constatait que les trois quarts des systèmes informatiques dépensaient la totalité de leur budget pour l’exploitation et l’entretien. Il est plus que nécessaire d’identifier ce qui cloche dans le développement des produits logiciels.

De nombreux dirigeants ne font pas de la qualité des logiciels un objectif prioritaire… une erreur coûteuse. Pensez à SaaqClic, Equifax, Boeing et son Max 7, le système de paye Phoenix du gouvernement fédéral… pour n’en nommer que quelques uns. Outre les coûts liés aux correctifs, c’est la réputation de l’entreprise qui est compromise lorsque des problèmes de qualité surviennent.

Plus généralement, le manque d’attention porté à la qualité contribue à des systèmes qui fonctionnent mal ou à des projets logiciels en retard, qui dépassent le budget ou sont annulés.

Or, les interactions clients et entreprises sont à 65% en numériques (travail, magasinage, formation…). De plus, la numérisation rapide accélère la demande mondiale en solutions logicielles. Bien des initiatives de transformation numérique échouent à cause d’une mauvaise ingénierie logicielle et d’un manque d’attention aux problèmes de qualité.

Comment redresser la barre ?

Quelles sont les cause d'une mauvaise qualité logicielle

Selon Bill Curtis, les principales causes d’une mauvaise qualité logicielle sont :

  1. Le manque de connaissance du domaine ce qui entraine des exigences mal définies.
  2. Le manque de connaissance sur les technologies
  3. Des échéanciers irréalistes dû à de mauvaises pratiques d’estimation.
  4. Du logiciel mal conçu par manque de discipline, pratiques immatures et du personnel moins qualifié.
  5. De mauvaises pratiques d’acquisition
  6. Un manque de communication et de coordination dans les équipes
  7. L’absence de métriques utiles sur l’état de la qualité des logiciels.

Création de l’amalgame qualité-valeur

La création de valeur est un concept ambigu car il n’y a pas de définition universelle de la valeur. Dans le domaine de la transformation numérique ou des technologies de l’information, je dirais que c’est de transformer un besoin par des produits et des services qui vont apporter de la valeur à l’ensemble des parties-prenantes. Ce que rappelle ITIL dans ses principes :

« Un service est un moyen de permettre la co-création de valeur en facilitant l’obtention des résultats demandés par les clients, sans que les clients n’aient à gérer les coûts et les risques spécifiques. »

Il est clair que sans l’implication du client, le fournisseur ne pourra pas satisfaire les attentes de celui-ci. La définition et la mise en œuvre des produits et services résultent donc d’une co-création entre le client et le fournisseur.

Les clients considèrent désormais la qualité comme une mesure fondamentale de leur perception/expérience d’un produit ou service fournit. Ce qui résulte en cet amalgame qualité-valeur. Une sorte de mesure.

Convaincre la Direction

Contrairement à une idée répandue, les entreprises n’ont pas à choisir entre qualité ou productivité. La qualité n’interfère pas avec la productivité, mais au contraire l’augmente. La qualité n’est pas une dépense, mais un investissement. Faire bien du premier coup est beaucoup moins dispendieux que de refaire (le « rework »).
En améliorant la qualité sur tout le cycle de développement d’un produit logiciel, vous obtiendrez une baisse du temps de correction et par le fait même une augmentation de la productivité. Ce temps gagné pourra être consacré à faire plus de prévention.

En premier lieu, il est donc important de sensibiliser la Direction à ce qu’est l’assurance qualité logicielle. Il faut donner à la Direction l’envie de changer et non de suivre les tendances. Comment convaincre la direction qu’investir dans la qualité est une bonne décision d’affaire ? Avec des éléments concrets : 

  • Évaluer le niveau d’insatisfaction du client, ses impacts et les coûts (en jour/homme ou en $) pour y remédier
  • Présenter une revue des problèmes perpétuels ou récurrents et évaluer les ressources mobilisées (donc leur coût) pour les résoudre
  • Faire suivre aux dirigeants une formation sur l'AQL ou les meilleures pratiques en test logiciel (ça ouvre les yeux en général)
  • Impliquer la direction dans l'implantation d'un programme qualité

Présenter les pertes directes dues à la non-qualité demeure l’argument le plus convaincant.

Combien coûte la non-qualité

Coûts de la non qualité | Technologia

De nombreux coûts liés à la mauvaise qualité des logiciels informatiques sont difficiles à identifier; un peu comme la partie immergée d’un iceberg. Être capable de les identifier va permettre à une entreprise ou organisation de réduire considérablement ses coûts d’exploitation.

Généralement, la partie visible de ces coûts sont :

  • Les problèmes rapportés par nos clients
  • Les appels de service
  • Les poursuites et les demandes d’honorer une garantie
  • Les coûts du groupe ou du coach qualité
  • Les coûts de l’équipe de test ou du testeur
  • Les interruptions de service

 

 

 

 

 

 

 

 

 

 

La portion des coûts qui est plus difficile à identifier/calculer :

- Le temps de recherche et de résolution des problèmes.
- Les projets qui sont en difficultés, annulés ou abandonnés
- Les heures supplémentaires non comptabilisées parce que on est en mode crise.
- Le travail mis de côté (fait pour rien) et celui qui est retravaillé (« rework »).
- Les cyberattaques qui perturbent nos opérations ou les rançongiciels.
- Les problèmes de recrutement ou de roulement du personnel.
- La mauvaise collaboration ou le travail en silo
- La mauvaise planification ou estimation
- Le retour sur investissement (ROI) qui n’est pas au rendez-vous
- Les coûts astronomiques des systèmes à maintenir ou à faire évoluer
- Le manque de bonnes pratiques et de normes de qualité
- Les opportunités de marché perdues
- Le temps dépensé à comprendre du code qui est complexe
- La dette technique
- Les données de mauvaise qualité

-> Les coûts de la non-qualité sont tous les coûts évitables si le produit était adéquat du premier coup.

Le modèle classique reconnu pour le calcul des coûts de la non-qualité est le suivant :

 

Modelé de calcul des coûts de le non qualité | Technologia

Coût des contrôles :

 

Ce sont les coûts engendrés pour détecter les anomalies.
Ex. revues, audit, TU, TI, TS, les approbations, réunion d’équipe etc.

Coût des corrections internes :

Ce sont les coûts engendrés pour corriger des anomalies avant que le système ou logiciel ne soit déployé dans l’environnement opérationnel.
Ex. travail refait, le gaspillage, heures supplémentaires etc.

Coût des corrections externes :

Ce sont les coûts engendrés pour corriger des anomalies lorsque le système ou logiciel est en production et utilisé par les clients.

Ex. poursuites judiciaires, désinstallation/installation, appels de service etc.

Flower S. propose dans son livre « Software Failure : Management Failure » d’étendre le modèle en ajoutant tout l’aspect des frais de gestion associés aux trois catégories du modèle classique. Cette proposition permet de refléter plus spécifiquement les particularités du développement de logiciels, que celles du domaine manufacturier. Le but avoué est d’essayer d’arriver avec un coût le plus près de la réalité possible.

Coût des frais de gestion des contrôles de la qualité

Les coûts typiques de gestion pour la préparation et les contrôles de la qualité.

Ex. coût de la mise à jour périodique du plan de projet et du plan qualité.

Coût des frais de gestion des anomalies internes

Tous les coûts des imprévus au niveau des risques du projet, du calendrier et du budget.

Ex. sous-estimation des besoins en ressources ou les coûts additionnels pour la sous-traitance etc.

Coût des frais de gestion des anomalies externes

Tous les coûts des imprévus après que le logiciel est publié.

Ex. Les pénalités versées pour les retards ou dommages pour mauvaise gestion.

Une autre proposition d’extension du modèle inclus les coûts de la dette technique et les coûts de la cybersécurité. Deux catégories importantes dans le monde de la transformation numérique.

Coût dû à la dette technique :

Représente l'effort requis pour résoudre les problèmes qui subsistent dans le code lorsqu'une application/système/logiciel est publié.

Intentionnelle – le remaniement de code (refactoring)

Non-intentionnelle – le carnet/backlog des bogues ou les bogues latents.

Coût dû à la cybersécurité :

Représente tous les coûts liés au vol des données, cyber attaques (intrusion), à la cyber criminalité qui peuvent dans les cas extrêmes mener à la faillite de l’entreprise.

Quelques erreurs communes à éviter !

  1. Chercher la perfection dans les chiffres.
    Sachez qu’en peu de temps il est possible de produire un estimé de 85%. Pour augmenter la précision à 95%, ceci peut prendre beaucoup de temps et être très dispendieux.
  2. Éviter les discussions sans fin pour positionner les coûts (bonne catégorie).
    Il s’agit seulement d’être constant afin de permettre des comparaisons dans le temps.
  3. Essayer de réduire les coûts qualité à zéro.
    Il est normal que le coût total d’un projet augmente en essayant de réduire les coûts dûs à la non-qualité.

Conclusion

Selon le référentiel d’analyse CAST le coût de la dette technique moyenne est de 3,61 $ par ligne de code. Ce coût peut s’élever jusqu’à 5,45 $ par ligne de code selon le langage utilisé.
En moyenne un développeur de logiciels génère 100 à 150 erreurs pour chaque mille (1000) lignes de code.
Selon Grady Booch, en 2005 il estime à environ 35 milliards de nouvelles lignes de code écrites par année dans le monde. Aujourd’hui en 2023 nous sommes beaucoup plus près du 100 milliards de nouvelles lignes de code par an dans le monde.
Une application de taille moyenne (moins d’un million de lignes de code) comporte 200 à 300 composants en moyenne.
Selon le groupe Meta, jusqu’à 80% des problèmes sont attribués à une mauvaise compréhension des exigences.
Les tests logiciels coûtent en moyenne de 40 à 75 % du coût total d’un projet.
On estime que la non-qualité atteint 30% à 70% du coût total d’un projet.

Vous l’aurez compris, la qualité c’est mieux d’y penser avant,

Dans notre prochain article sur le même sujet nous verrons comment définir des objectifs de qualité, mettre l’accent sur la prévention, améliorer les processus et instaurer l’amélioration continue.

Pour aller plus loin :

 

Assurance qualité : améliorer la qualité des livrables, processus et produits logiciels

 

Assurance qualité : savoir intégrer la qualité selon le contexte des projets

 

Assurance qualité : implanter un bureau qualité

Voir toutes les formations en Langages et environnements de réalisation d'applications

Voir aussi le webinaire Qualité des logiciels : au-delà des tests

Photo de Aaron Burden sur Unsplash
Photo de SIMON LEE sur Unsplash

Contactez-nous

Pour en savoir plus sur nos nouveaux services ou nous parler de vos besoins en développement de compétences, contactez nos spécialistes en formation au 514 380-0380 ou par courriel : formation@technologia.ca.

Articles similaires

Voir tous les articles de blogue