J’ai reçu des documents de Capers Jones, auteur bien connu et conférencier international, qu’il n’ai pas nécessaire de présenter, mais au cas où : http://www.namcook.com/aboutus.html). Capers Jones est vice president et CTO de Namcook Analytics LLC.
Ce matériel constitue une bonne synthèse de l’état actuel de la qualité du logiciel, dont je vais résumer les principaux points, ce qui me permettra également de poser quelques questions à Capers.
Introduction
En 2012, plus de la moitié des projets logiciels de plus de 10 000 points de fonction (environ 1 000 000 lignes de code) sont soit annulés, soit en retard de plus d’un an. Le tableau suivant présente les résultats d’environ 13 000 projets classés en six tailles différentes, et les pourcentages de ceux qui sont à l’heure, en avance, en retard ou supprimés.
Table 1: Software Project Outcomes By Size of Project
| Early | On-Time | Delayed | Canceled | |
| 1 FP | 14.68% | 83.16% | 1.92% | 0.25% |
| 10 FP | 11.08% | 81.25% | 5.67% | 2.00% |
| 100 FP | 6.06% | 74.77% | 11.83% | 7.33% |
| 1 000 FP | 1.24% | 60.76% | 17.67% | 20.33% |
| 10 000 FP | 0.14% | 28.03% | 23.83% | 48.00% |
| 100 000 FP | 0.00% | 13.67% | 21.33% | 65.00% |
| Average | 5.53% | 56.94% | 13.71% | 23.82% |
Q: Capers, comment avez-vous réussi à obtenir toutes ces données sur tous ces projets? S’agit-il de données provenant de projets aux EU ?
J’ai travaillé chez IBM et ITT et eu accès à toutes leurs données internes. J’ai également eu une équipe d’une dizaine de consultants apportant des données de 25 à 75 projets par mois pour des centaines d’entreprises. J’ai travaillé dans 24 pays, mais environ 90% des données de la table précédente proviennent des États-Unis.
Les meilleurs pays pour la qualité sont le Japon et l’Inde. La productivité est une question plus complexe en raison des grandes variations dans les heures de travail. Aux États-Unis, nous avons une semaine nominale de 40 heures, elle est de 44 heures au Japon, seulement 36 heures au Canada. Il ya aussi de grandes différences dans les vacances et les jours fériés. C’est trop compliqué pour une réponse rapide.
Q: Vous dites que 10 000 FP représente environ 1 000 000 lignes de code. Est-ce une mesure que quelqu’un peut utiliser pour comparer ses projets avec ces données, quand il n’a pas d’estimation en FP ? Ou existe-t-il une autre mesure, comme par exemple, la taille de l’équipe de développement, ou les années-hommes ?
Le ratio d’instructions de code source pour les points de fonction est appelé « backfired » et a d’abord été développé dans les années 1970 par IBM. Ce ratio varie selon les langages ou les combinaisons de langages. Pour le Cobol, il est d’environ 105,7 instructions par point de fonction; pour le C, environ 128 déclarations par point de fonction; JAVA est autour de 53 instructions par point de fonction. Il existe plusieurs compagnies qui vendent des listes de ces ratios pour environ 1 000 langages de programmation.
Volume de défauts
Lors de l’examen des projets en difficulté, on vérifie toujours que la raison principale du retard ou de l’abandon est due à des volumes excessifs de défauts graves. Le tableau 2 montre les volumes moyens des défauts constatés sur des projets logiciels, ainsi que le pourcentage de défauts enlevés avant la livraison aux clients, pour différentes origines de défauts.
Table 2: Defect Removal Efficiency By Origin of Defects Circa 2012
| Defect Origins | Defect potentials | Removal Efficiency | Delivered Defects |
| Requirements | 1.00 | 77% | 0.23 |
| Design | 1.25 | 85% | 0.19 |
| Coding | 1.75 | 95% | 0.09 |
| Document | 0.60 | 80% | 0.12 |
| Bad Fixes | 0.40 | 70% | 0.12 |
| Total | 5.00 | 85% | 0.75 |
(Data Expressed in Terms of Defects per Function Point)
Q: Nous pouvons voir dans le tableau précédent que les défauts potentiels de programmation sont supérieurs à tous les autres. Avez-vous vu une évolution selon les différentes technologies utilisées sur les projets? Beaucoup de gens pensent que les nouvelles technologies, parce que plus complexe, sont susceptibles d’introduire plus de défauts.
Les erreurs de code sont principalement liées au niveau des langages utilisés. Chaque source de défauts est affectée par la complexité et les applications multi-tiers comme le client-serveur ont tendance à avoir plus de defauts de spécifications (Requirements) et de conception (Design).
Q: On peut voir également que les défauts de Requirements et de Design sont plus nombreux que les défauts de code. Même question: avez-vous vu une évolution dans ce domaine ? Avec l’accent mis sur l’externalisation et l’outsourcing, certains pourraient penser que ces défauts se produisent de plus en plus fréquemment.
Il existe des outils efficaces tels que FOG et FLESCH, des outils d’analyse statique de texte ou d’analyse UML qui peuvent réduire les défauts de spécifications. Ainsi que les outils de modélisation des requirements et de conception. Les utilisateurs intégrés dans les processus Agile peuvent aider également, mais avec certaines limites. Aucun utilisateur ne peut comprendre à lui toutes les fonctionnalités d’une application de 10 000 points de fonction ou 10 000 utilisateurs.
L’industrie du logiciel devrait utiliser des outils modernes de spécification et de conception en 3D, et pas seulement du texte et des diagrammes statiques. Si vous utilisez les méthodes appropriées, vous aurez un haut niveau de qualité et des planning plus courts également.
De par mon travail d’expert dans des procès pour cause de projets en difficulté, j’ai pu constater que la plupart échouent en raison de contrôles de qualité médiocres. Trop de bugs présents avant que ne commence la phase de test aboutissent à étendre les cycles de projet de manière presque infinie.
Deux stratégies générales sont nécessaires pour atteindre la qualité:
- Réduire les volumes de défauts existants ou potentiels.
- Accroître l’efficacité de suppression des défauts (Defect Removal Efficiency ou DRE) – á noter que celle-ci n’est pas très efficace pour les défauts autres que de code.
Réduire le volume des défauts
Certaines des méthodes qui permettent de réduire les défauts :
- Modélisation des spécifications.
- Outils d’analyse statique des spécifications, qui permettent de trouver des erreurs et des ambiguïtés.
- Formalisation des spécifications et inspection des requirements et de la modélisation fonctionnelle.
- Incorporation des utilisateurs au projet, comme on le trouve dans les processus Agile.
- Développement à base de tests, quand la phase de conception est précédée par la définition des cas de tests.
- Prototypage, afin de minimiser les évolutions de spécifications.
- Examen formalisé de toutes les demandes de changement (Change Requests).
- Outils de contrôles automatisés des changements, avec des références croisées.
Lorsque les inspections formelles sont ajoutés au cycle, les défauts potentiels diminuent progressivement, passant de 5 par point de fonction à 3, alors que les niveaux d’efficacité d’élimination de défauts (DRE) sont systématiquement supérieurs à 95% voire atteignent 99%.
L’analyse de code est une forme relativement nouvelle d’éliminer des défauts, qui présente également des avantages en termes de prévention de ceux-ci.
Un aspect intéressant des contrôles des spécifications est la réduction des modifications imprévues de requirements. Les projets où les spécifications sont soigneusement précisées et analysées connaissent en moyenne seulement une fraction de 1% de changements imprévus par mois.
Relever l’efficacité de l’élimination des défauts
De nombreuses formes de tests réalisés par les développeurs présentent moins de 35% d’efficacité à détecter des bugs ou des défauts, même si parfois ils peuvent atteindre les 50%. Les tests á base de scénarios de test mis en oeuvre par des testeurs certifiés perment de dépasser souvent les 50%.
Une phase de conception formelle et des inspections de code permettent d’atteindre 65% d’efficacité dans la détection des bugs ou des défauts, et parfois les 85%. Les inspections également peuvent augmenter cette efficacité en fournissant des spécifications plus complètes pour le personnel de QA.
L’analyse de code permet également un niveau d’efficacité élevé de suppression de nombreux défauts de programmation. Par conséquent, les projets de premier plan dans les entreprises leaders utilisent des combinaisons synergiques á base d’inspections formelles, d’analyse de code et de tests.
Cette combinaison est le seul moyen connu d’atteindre des niveaux d’élimination des défauts supérieurs à 98%, conduit à des délais de développement plus courts et diminue les risques d’échec des projets.
Q: Parmi ces méthodes, certaines sont automatisées et donc devraient être moins coûteuses alors que d’autres – telles que la conception formelle et les inspections de code – ne peuvent l’être, et sont donc probablement plus coûteuse. Avez-vous déjà essayé de définir un rapport entre le coût et l’efficacité de ces méthodes ?
Vous vous trompez. Avant qu’IBM n’introduise les inspections pour une application de base de données, les tests duraient 3 mois. Après la mise en oeuvre d’inspections, la phase de QA est descendue à 1 mois. Les inspections prenaient environ 6 semaines. Il ya eu une réduction nette des coûts et des délais et une augmentation de l’efficacité de l’élimination des défauts de moins 85% à plus de 95% dans le même temps.
Votre question reflète un problème courant: la plupart des entreprises ne mesurent pas suffisamment bien pour disposer de données qui permettent de comprendre l’économie de la qualité. J’ai des données sur les coûts comparatifs de chaque combinaison d’inspections pré-test, d’analyse de code et de tests. Les meilleurs résultats proviennent d’une combinaison synergique de prévention des défauts, d’élimination ce ceux-ci avant la phase de test, et de tests réalisés par un personnel de QA certifié.
Les pires résultats proviennent de tests réalisés uniquement par les développeurs ou par du personnel de QA amateur, sans aucune inspection pré-test ou d’analyse de code. Tout le monde devrait savoir cela, mais les données et les mesures sont si pauvres que la plupart des managers n’en ont pas la moindre idée.
Q: Diriez-vous que l’efficacité de ces méthodes varie en fonction de la taille d’un projet ? On peut penser instinctivement que plus le projet est important, plus le risque de trouver des défauts de spécifications et de conception est élevé, tandis que le niveau d’erreurs de code devrait rester (plus ou moins) stable ?
Lorsque les applications croissent en taille, les défauts potentiels deviennent plus importants et l’efficacité d’élimination de ces défauts devient plus faible. C’est pourquoi les inspections pré-test et l’analyse de code sont de plus en plus précieux lorsque la taille des applications devient plus importante.
Q: Je dirais que pour les grands projets, il est recommandé d’industrialiser l’ensemble de ces méthodes. Mais pour les projets de petite taille ou de taille moyenne, ou pour une équipe qui n’est pas habituée à utiliser ces méthodes, en recommanderiez-vous certaines que vous jugez plus faciles à mettre en œuvre en premier ou plus importantes ? Pour le dire autrement, existe-t-il un chemin optimal vers la maturité ?
Il s’agit lá d’une question trop compliquée pour pouvoir répondre de manière courte. L’analyse de code ne coûte pas cher, eset efficace et facile à utiliser sur les projets de toutes tailles. En dessous de 1 000 points de fonction, Agile est Ok; au-dessus de 10 000 points de fonction, TSP est meilleur. Ce dont les entreprises ont besoin ne sont pas de réponses générales mais de prédictions précises qui montrent l’ensemble des méthodes optimales pour des projets spécifiques. Mon travail principal est de construire des outils qui permettent de prédire des résultats spécifiques pour des projets spécifiques.
Q: Dernière question, pour conclure, et sans doute celle que la plupart des gens sont curieux de savoir : qu’est-ce qu’une journée typique pour vous? Faire du consulting pour un client? Travailler sur un document ou un nouveau livre? Aller à la pêche ou jouer au golf?
Il ya des années, quand je travaillais sur mon premier livre, je devais être au travail vers 8h30 alors j’ai commencé à me lever tôt pour écrire à 5 heures. Après 15 livres, je ne peux plus dormir tard. J’ai l’habitude d’écrire des livres ou des articles entre 4 heures et 10 heures du matin; je passe à une activité à base de logiciels ou centrée sur le business de 10 heures à 16 heures, et ensuite je me repose ou joue au golf tard dans la journée. Je vais aussi à un gymnase trois fois par semaine.
La plupart de mon activité de conseil ou de mes présentations s’effectuent à l’étranger. Le 8 novembre, je participe à une conférence à Stockholm, en Suède. Le sujet est “Achieving Software Excellence”. Le 13 novembre, j’effectue un webinar sur “Software Risk and Value Analysis”. Le 4 décembre, un webcast pour IBM intitulé “Measuring Software Quality and Customer Satisfaction”.
Je voyage pour les conférences les plus importantes telles que le Japanese Symposium on Software Testing, le Malaysian Testing Conference, et différentes conférences du International Function Point Users Group.
Capers, merci pour le matériel que vous m’avez envoyé et pour avoir pris le temps de répondre à mes questions.
Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.