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

Si vous avez du mal à gérer votre arriéré d'avertissements d'analyse statique et de dette technique, consultez cet article pour savoir comment résoudre ce problème.

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 l'introduction de l'analyse statique dans un projet, mais cette fois-ci, l'accent est mis sur un ensemble d'avertissements plus faciles à analyser pour l'équipe. Parasoft C/C++test gère cela de plusieurs manières, comme nous le verrons plus loin.

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 en matière de dette technique consiste à adopter une approche proactive de la gestion de la qualité du code. Les développeurs peuvent ainsi réduire le risque d'accumulation excessive de dette technique et garantir la santé et la pérennité de leurs logiciels à long terme. Pour ce faire, ils privilégient un code et des pratiques de conception de haute qualité, et réduisent régulièrement leur dette technique. Cela implique d'investir dans la qualité du code, les tests et la documentation, et de veiller à ce 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

Les tableaux de bord centralisés de reporting et d'analyse de Parasoft permettent aux développeurs et aux responsables de visualiser l'état actuel d'un projet sous différents angles et d'accéder à des informations plus détaillées afin d'identifier les points d'alerte nécessitant une investigation plus approfondie. L'exemple ci-dessous illustre la conformité d'un projet à la norme 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.

En tirant parti de l'intelligence artificielle (IA) et de l'apprentissage automatique (AA), les rapports et analyses de Parasoft apprennent à la fois des interactions historiques avec la base de code et des résultats d'analyses statiques antérieures pour prédire la pertinence et prioriser les nouvelles découvertes.

Les responsables et les chefs de projet gagnent un temps précieux grâce à une interface intuitive permettant d'identifier les infractions et de générer automatiquement des rapports à des fins de certification, le cas échéant. 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é

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. Tous les avertissements ne se valent pas ; leur niveau de gravité est donc le meilleur indicateur de l'effort à consacrer à leur investigation et à leur correction. En examinant la liste des avertissements en attente, les équipes repoussent progressivement les limites de ce qu'il convient de traiter.

Les outils Jtest et C/C++test de Parasoft permettent aux utilisateurs de hiérarchiser et de filtrer les avertissements au sein de l'EDI grâce à des configurations. Par exemple, ils peuvent utiliser un niveau de gravité et une catégorie pour créer un ensemble d'avertissements pertinents pour l'analyse. Un exemple de configuration utilisateur est présenté ci-dessous.

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

La meilleure approche pour gérer un important arriéré d'alertes consiste à déplacer progressivement la ligne de démarcation vers la priorité et la catégorie suivantes. Les équipes logicielles finissent par atteindre un seuil critique en raison des contraintes de temps et de budget. Elles doivent néanmoins être convaincues d'avoir réalisé des améliorations significatives en termes de qualité et de sécurité malgré l'arriéré d'alertes.

Meilleures pratiques pour prévenir la dette technique

Prévenir la dette technique exige une approche proactive impliquant toute l'équipe de développement logiciel. Voici quelques bonnes pratiques pour y parvenir.

• 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 le tests automatisés pour détecter les problèmes au plus tôt et réduire le risque d'en introduire de nouveaux.
• 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 projet d'envergure, les avertissements sont nombreux au départ. Il est crucial de les gérer rapidement et efficacement. Il est important que les équipes adoptant l'analyse statique comprennent qu'il est inutile de corriger ou d'analyser tous les avertissements. Privilégiez plutôt un outil permettant de naviguer, d'évaluer, de prioriser et d'assigner les erreurs signalées à corriger. La meilleure approche pour gérer un important arriéré d'avertissements consiste à déplacer progressivement la ligne de démarcation vers la priorité et la catégorie suivantes.

« 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.