Une technique universelle pour améliorer la qualité des logiciels
Tout le monde souhaite améliorer la qualité des logiciels autant que possible, à condition que cela ne ralentisse pas la fourniture de nouvelles fonctionnalités.
Il se trouve qu’il existe une seule technique capable d’améliorer considérablement la qualité du développement logiciel. Dans cet article, vous apprendrez deux principes fondamentaux :
- La connaissance de la taille des logiciels contribue à améliorer la qualité des logiciels
- Le processus de dimensionnement des logiciels contribue à améliorer la qualité des logiciels
- Cette technique peut trouver et vous aider à éliminer 7-10% de tous les défauts avant le codage.
Commençons par quelques principes fondamentaux du développement de logiciels. Tous les logiciels présentent des défauts (bugs). Les bogues peuvent être causés par un mauvais codage ou par autre chose. Peut-être avons-nous mal défini les exigences, peut-être avons-nous mal compris les exigences, peut-être avons-nous manqué certaines exigences importantes.
Très souvent, les exigences sont à l’origine des bugs logiciels. Mais nous passons rarement du temps à examiner la qualité des exigences. Pourquoi? C'est important mais rarement urgent. L’examen et l’affinement des exigences ne sont presque jamais considérés comme une activité critique dans un plan de projet. J'ai vu des exigences très médiocres utilisées « juste pour que les développeurs puissent démarrer ». Mais il s’agit d’un processus inefficace qui entraînera d’importantes retouches et retards inutiles.
Améliorez la qualité des logiciels en connaissant la taille
Si vous avez déjà travaillé avec le dimensionnement de logiciels, vous saurez également que le potentiel de défauts (le nombre probable de défauts/erreurs) dans les exigences est prévisible. Cette seule connaissance peut vous guider pour être plus efficace. Il peut vous informer d'introduire la quantité optimale d'efforts dans la qualité des exigences avant le codage, en supprimant les bogues des exigences, avant le début du codage.
Exemple
De nos jours, une voiture typique comporte environ 5 millions de lignes de code. D'après les données historiques, nous savons que cela équivaut probablement à environ 100 000 points de fonction (mesure ISO de la taille du logiciel). De plus, à partir des données historiques, nous savons qu'il existe (en moyenne) un potentiel de défauts de 0,7 à 1,0 défauts d'exigence par point de fonction. Il y aura donc (aura) 100 000 défauts d’exigences. Si vous suivez le nombre de défauts trouvés et supprimés, vous pouvez déterminer approximativement combien il en reste. De plus, si vous effectuez des revues et des examens des exigences pour détecter et corriger rapidement les défauts des exigences, vous réduirez les défauts des exigences qui sont reportés au début du codage.
Savoir combien de défauts sont potentiellement présents vous informe de la quantité de travail que vous devez effectuer pour les supprimer. Si vous optimisez votre (exigences) travail d'assurance qualité en ciblant (pas 100% mais) la suppression des défauts 95%, vous serez alors sur la bonne voie pour une livraison simple et efficace.
Par exemple, si vous utilisez ScopeMaster pour examiner et tester vos exigences avant de coder, vous pourriez probablement trouver environ 50 000 de ces défauts (50%) et éviter qu'ils n'atteignent les développeurs. Imaginez à quel point vos développeurs seraient plus efficaces s'ils commençaient avec des exigences comportant moins de défauts 50% ?
Mesures de qualité valides grâce à la connaissance de la taille du logiciel
Remarque CFP = Points de fonction COSMIC
Améliorer la qualité avec le processus de dimensionnement
Le processus de dimensionnement fonctionnel formel est idéal pour clarifier l'intention fonctionnelle, c'est-à-dire ambiguïtés. Parfois, des termes différents sont utilisés mais signifient en réalité la même chose. En examinant les utilisateurs fonctionnels et les types d'objets gérés par les utilisateurs selon un ensemble d'exigences, vous pouvez facilement repérer incohérences. Si deux fonctions effectuent la même action sur un objet, vous pourriez avoir un dupliquer exigence. Si vous disposez d'un objet qui doit être entièrement géré par votre logiciel, mais qu'il manque à vos besoins une fonction de maintenance des données critiques, vous disposez peut-être d'un exigence manquante. Si une exigence implique de nombreuses étapes fonctionnelles, elle pourrait être trop compliquée à coder, elle pourrait nécessiter une simplification, nous pourrions considérer cela comme une défaut de complexité. Collectivement, ces cinq catégories de défauts d'exigences représentent environ 40% de tous les défauts potentiels.. Ces défauts sont susceptibles d'être exposés par processus de dimensionnement fonctionnel. Le dimensionnement manuel des exigences constitue donc une activité d’assurance qualité efficace et intéressante. Le dimensionnement automatisé à partir des exigences avec ScopeMaster est encore plus efficace et approfondi. Il détectera et signalera ces défauts plus rapidement et de manière plus approfondie que les humains ne pourraient le faire manuellement.
Conclusion
Nous avons montré dans cet article que la connaissance de la taille fonctionnelle ET du processus de dimensionnement améliorera considérablement la qualité des logiciels. Plus précisément, 7 à 10% de tous les bogues logiciels peuvent être supprimés grâce au processus (automatisé) de dimensionnement du logiciel. Ensuite, la connaissance du dimensionnement peut aider à optimiser les activités d’assurance qualité pour aider à supprimer les bogues restants.
