Optez pour une voie plus rapide et plus intelligente vers l'automatisation des tests C/C++ pilotée par l'IA. Découvrez comment >>
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.
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 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.
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 :
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:
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.
En matière de dette technique, il existe deux grandes catégories.
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.
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 :
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 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.
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.
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.
Un exemple de tableau de bord de portail Web. Dans ce cas, un résumé de la conformité 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.
L'explorateur de violations Parasoft
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.
Apprentissage automatique de la hiérarchisation des résultats d'analyse statique.
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.
Un exemple de rapport de déviation Parasoft MISRA C
C'est important pour les équipes qui sont adopter l'analyse statique Il est important de comprendre qu'il n'est pas nécessaire de corriger ou d'analyser tous les avertissements. Tous les avertissements ne sont pas identiques ; leur niveau de gravité est donc le meilleur indicateur des efforts à déployer pour les analyser et les corriger. En analysant l'arriéré d'avertissements, les équipes repoussent chaque fois un peu plus la limite.
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.
Paramètres de configuration de test personnalisés dans l'IDE
Cette configuration peut être utilisée pour filtrer les avertissements dans l'IDE.
Les configurations peuvent être sélectionnées dans la vue DTP Findings de l'EDI.
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.
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.
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.
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.
