Comment gérer votre arriéré d'avertissements d'analyse statique et de dette technique

Une fois que les outils d'analyse statique ont été intégrés dans le flux de travail quotidien de l'équipe de développement, la phase suivante consiste à réduire l'arriéré d'alertes et la dette technique d'un projet.

Dans le cas d'un produit en maintenance ou en développement, il y a probablement un arriéré important à traiter. Dans le cas d'un projet entièrement nouveau, il y a moins d'arriérés. Cependant, les recommandations restent les mêmes pour chaque stade de maturité.

Le meilleur point de départ pour traiter un arriéré d'avertissements est de hiérarchiser et de filtrer les résultats en fonction du résultat souhaité. En utilisant la sécurité comme exemple, il est logique de hiérarchiser le backlog en termes d'avertissements de sécurité, classés par criticité.

Il s'agit d'une continuation de l'approche utilisée lors de la première introduction à l'analyse statique dans un projet, mais maintenant l'accent est mis sur le prochain ensemble d'avertissements assimilables que l'équipe doit analyser. Ceci est géré de plusieurs manières par Parasoft C/C++test, comme nous le verrons ci-dessous.

Qu'est-ce que la dette technique et pourquoi c'est important

La dette technique est le coût encouru pour retarder des travaux essentiels ou prendre des raccourcis lors du développement de logiciels. Cette forme de dette, comme la dette financière, accumule des intérêts au fil du temps et peut devenir coûteuse à réparer si elle n'est pas résolue.

Voici des exemples de dette technique :

• Code difficile à maintenir ou à étendre
• Dépendances obsolètes
• Vulnérabilités de sécurité

Malheureusement, la dette technique est un problème courant car les équipes de développement de logiciels donnent souvent la priorité à la livraison rapide de fonctionnalités plutôt qu'à la création d'une base de code robuste.

S'attaquer à la dette technique est crucial pour plusieurs raisons. Ça peut:

• Entraver la capacité des équipes logicielles à fournir des produits de haute qualité.
• Diminuer la productivité.
• Augmenter le temps de développement.
• Baisse de la satisfaction client.
• Pose des risques de sécurité.

La résolution de la dette technique est essentielle pour créer des produits logiciels durables et maintenables qui peuvent s'adapter à l'évolution des besoins des entreprises et des clients.

Types de dette technique

En matière de dette technique, il existe deux grandes catégories.

1. Intentionnel
2. Involontaire

Une dette technique intentionnelle est contractée lorsqu'une équipe prend consciemment des raccourcis pour respecter un délai ou atteindre un objectif spécifique. Ce type de dette technique est souvent accumulé en raison de considérations commerciales, telles que les pressions du marché, et est considéré comme un mal nécessaire. L'inconvénient est que cela peut entraîner des travaux supplémentaires, tels que la refactorisation, qui peuvent être coûteux.

D'autre part, une dette technique non intentionnelle est contractée lorsqu'une équipe n'est pas consciente de l'impact des décisions qu'elle prend au cours du développement. Cela peut être dû à un manque de compréhension ou d'expertise dans un domaine spécifique, à un manque de ressources ou de temps, ou simplement à un manque de discipline ou de rigueur.

Ce type de dette technique est souvent plus insidieux, car il peut être difficile à détecter et à diagnostiquer, et peut entraîner des conséquences imprévues sur toute la ligne. Quel que soit le type de dette technique, il est important d'être conscient de son existence et de prendre des mesures pour la gérer efficacement afin d'assurer la santé et le succès à long terme d'un projet logiciel.

Exemples de dette technique

Une dette technique non intentionnelle peut s'accumuler au fil du temps si elle n'est pas résolue, ce qui finit par compliquer la maintenance et l'évolution du logiciel. Voici quelques exemples de dette technique non intentionnelle :

• Dette de conception survient lorsque des décisions de conception sont prises pour atteindre des objectifs à court terme ou des objectifs de livraison, sans tenir compte des implications à long terme de ces décisions.
• Dette de code découle de mauvaises pratiques de codage et de raccourcis pris pour respecter les délais, entraînant des problèmes tels qu'un code dupliqué ou trop complexe difficile à maintenir ou à tester.
• Tester la dette se produit lorsque des tests appropriés ne sont pas effectués ou sont insuffisants, ce qui entraîne des difficultés dans la détection et le traitement des défauts et le potentiel de publication de bogues en production.

La dette technique intentionnelle est contractée en sachant qu'elle devra être remboursée à un moment donné dans le futur. Voici quelques exemples de dette technique intentionnelle :

• La dette technique planifiée est délibérée. Cela implique de prendre des raccourcis en sachant qu'ils seront traités à l'avenir, comme l'utilisation d'une bibliothèque tierce qui sera remplacée par une solution personnalisée.
• La dette commerciale est intentionnellement contractée par l'équipe de développement pour répondre à un besoin commercial, comme le lancement d'un produit avec moins de fonctionnalités que prévu pour répondre à la demande du marché, étant entendu qu'il devra être amélioré ultérieurement.
• La dette stratégique survient lorsqu'une équipe reporte intentionnellement le travail sur de nouvelles fonctionnalités ou de nouveaux systèmes pour donner la priorité à d'autres domaines, tout en sachant que cela sera plus coûteux à l'avenir.

La meilleure pratique pour la dette technique consiste à adopter une approche proactive pour gérer la qualité du code afin que les développeurs de logiciels puissent réduire le risque d'accumuler trop de dette technique et de s'assurer que leurs logiciels restent sains et durables à long terme en donnant la priorité à des pratiques de code et de conception de haute qualité et en remboursant régulièrement la dette technique. Cela signifie investir dans la qualité du code, les tests et la documentation, et s'assurer que le logiciel reste maintenable, évolutif et sécurisé dans le temps.

Importance de l'analyse statique pour la gestion de la dette technique

L'analyse statique est une méthode automatisée d'examen du code source pour les problèmes de qualité et de conformité. Cela peut être utile pour identifier les problèmes de sécurité, les vulnérabilités de sécurité et les problèmes de fiabilité, ou les domaines où le code peut être plus difficile à maintenir ou à étendre à l'avenir.

En rattrapant tôt la dette technique, les équipes peuvent prendre des mesures pour y remédier avant qu'elle ne devienne un problème plus grave. Cela peut aider à améliorer la qualité du code, à réduire le temps de développement, à réduire les coûts de main-d'œuvre et à améliorer la valeur globale des produits logiciels.

Tableaux de bord pour l'analyse de haut niveau

Centralisé de Parasoft tableaux de bord de reporting et d'analyse offrent aux développeurs et aux gestionnaires la possibilité de voir l'état actuel d'un projet à partir de différents points de vue et de naviguer plus en détail si nécessaire pour établir un ensemble d'avertissements pour une enquête plus approfondie. Considérez le tableau de bord suivant montrant la conformité actuelle d'un projet avec la norme de codage de sécurité CERT C.

À l'aide de ce portail Web, les utilisateurs peuvent approfondir l'analyse, jusqu'au niveau du fichier et du code si nécessaire, et enquêter sur les avertissements entièrement dans le portail Web ou dans un IDE. Les avertissements peuvent être classés par ordre de priorité, attribués aux développeurs, supprimés ou marqués comme faux positifs à ce stade. Voir l'exemple suivant de l'explorateur Parasoft.

Gestion des violations des normes de codage

Dans la plupart des cas, lors de l'analyse du code source pour la conformité aux normes de codage, les violations sont signalées sous forme d'avertissements d'analyse statique. Dans un grand projet, il y aura initialement beaucoup d'avertissements. Les gérer rapidement et efficacement est essentiel. L'explorateur de violations de Parasoft est l'outil clé pour naviguer, évaluer, hiérarchiser et attribuer les erreurs signalées pour correction.

Si une violation de règle d'analyse statique s'avère valide mais justifiable, considérée comme inoffensive ou non applicable, un développeur peut supprimer l'erreur et un écart peut être documenté. Ces écarts sont signalés à chaque niveau du projet au tableau de bord et à la documentation de conformité.

Pour que la conformité aux normes de codage soit réalisable pour les projets existants, il est essentiel que les équipes se concentrent d'abord sur les règles considérées comme obligatoires. La conformité est souvent basée sur le respect des exigences obligatoires avec des violations des règles recommandées si elles sont documentées de manière appropriée. Les normes permettent de recatégoriser les règles, si elles ne sont pas obligatoires, en permettant les violations, si elles sont justifiables et documentées. Sans cela, essayer de corriger chaque violation devient impossible.

Tirant parti de l'intelligence artificielle (IA) et de l'apprentissage automatique (ML), Parasoft's rapports et analyses apprenez à la fois des interactions historiques avec la base de code et des résultats d'analyses statiques précédentes pour prédire la pertinence et hiérarchiser les nouveaux résultats.

Les responsables et responsables du développement économisent également des heures de travail supplémentaires grâce à une interface navigable pour explorer les violations et générer automatiquement des rapports pour les preuves de certification, si nécessaire. Un exemple de rapport d'écart MISRA C est présenté ci-dessous.

Gestion de l'arriéré des avertissements de bogues et de sécurité

C'est important pour les équipes qui sont adopter l'analyse statique comprendre qu'il n'est pas nécessaire de corriger ou d'analyser tous les avertissements. Tous les avertissements ne sont pas créés de la même manière. Le niveau de gravité est donc le meilleur indicateur de l'effort à consacrer à l'examen et à la correction d'un avertissement. Lorsqu'elles creusent dans l'arriéré d'avertissements, les équipes déplacent efficacement "la ligne dans le sable" un peu plus loin à chaque fois.

Parasoft's Jtest et Test C / C ++ permettent aux utilisateurs de hiérarchiser et de filtrer les avertissements dans l'IDE à l'aide de configurations. Par exemple, ils peuvent utiliser un niveau de gravité et une catégorie pour créer un ensemble d'avertissements adaptés à l'analyse. Un exemple de configuration d'un nouvel utilisateur est illustré ci-dessous.

Cette configuration peut être utilisée pour filtrer les avertissements dans l'IDE.

Déplacer progressivement la « ligne dans le sable » pour s'attaquer à la priorité et à la catégorie suivantes est la meilleure approche pour traiter un important arriéré d'avertissements. Finalement, les équipes logicielles atteignent un point limite en raison du temps et du budget. Mais ils doivent être convaincus qu'ils ont apporté des améliorations significatives à la qualité et à la sécurité malgré tout arriéré d'avertissements.

Meilleures pratiques pour prévenir la dette technique

La prévention de la dette technique nécessite une approche pro-active qui implique toute l'équipe de développement logiciel. Voici quelques bonnes pratiques qui peuvent aider à prévenir la dette technique.

• Prioriser et planifier. Élaborez un plan clair et hiérarchisez les tâches en fonction de la valeur commerciale et des risques. Cela peut aider à éviter de prendre des raccourcis pour respecter des délais irréalistes.
• Revues de codes. Effectuer des revues de code pour garantir la qualité du code et identifier les problèmes potentiels au début du processus de développement.
• Automatisez les tests. Utilisez des tests automatisés pour détecter rapidement les problèmes et réduire le risque d'introduction de nouveaux problèmes.
• Intégration et livraison continues. Mettez en œuvre une intégration et une livraison continues pour vous assurer que les modifications de code sont régulièrement intégrées et testées, réduisant ainsi le risque de problèmes d'intégration.
• Suivre la dette technique. Suivez la dette technique et priorisez son remboursement dans le cadre des cycles de développement réguliers.
• Partager le savoir. Favoriser une culture de partage des connaissances pour s'assurer que l'équipe est au courant des dernières mises à jour et des meilleures pratiques.

En suivant ces meilleures pratiques, les équipes de développement de logiciels peuvent aider à prévenir la dette technique et s'assurer qu'elles créent des produits logiciels sûrs, sécurisés, fiables et maintenables.

Résumé

Dans un grand projet, il y aura initialement beaucoup d'avertissements. Les gérer rapidement et efficacement est essentiel. Il est important pour les équipes qui adoptent l'analyse statique de comprendre qu'il n'est pas nécessaire de corriger ou d'analyser tous les avertissements. Au lieu de cela, assurez-vous de sélectionner un outil qui vous permet de naviguer, d'évaluer, de hiérarchiser et d'affecter les erreurs signalées à la correction. Déplacer progressivement la « ligne dans le sable » pour s'attaquer à la priorité et à la catégorie suivantes est la meilleure approche pour traiter un important arriéré d'avertissements.

« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Tous droits réservés.