Un guide pratique pour rendre votre base de code héritée conforme à la MISRA C 2012

La réutilisation du code hérité est une réalité, mais la réutilisation du code hérité dans un projet logiciel critique pour la sécurité et la réalisation complète MISRA La conformité au C 2012 est une tâche ardue.

Les principes MISRA originaux ont été créés pour être appliqués en tant que code en cours de développement. Même le document lui-même contient un avertissement :

"… Un projet qui vérifie la conformité MISRA C à la fin de son cycle passera probablement un temps considérable à recoder, revoir et tester de nouveau. On s'attend donc à ce que le processus de développement logiciel nécessite l'application précoce des principes MISRA C."

Étant donné que de nombreuses organisations doivent réutiliser leurs anciennes bases de code pour des raisons professionnelles, le document d'orientation Conformité MISRA : 2016 a été créé en réponse à ces défis. Dans celui-ci, il y a une distinction claire entre le nouveau code natif qui est développé dans le cadre d'un projet en cours et le code "adopté", qui a été développé en dehors du cadre du projet. Dans cet article, j'explique une approche pratique pour gérer le code hérité et MISRA Conformité C.

Les nuances de gris du respect des directives MISRA

Bien qu'il semble qu'il soit simple de comprendre le type de code auquel vous avez affaire, la situation n'est pas souvent en noir et blanc. Par exemple, un prototype initial qui a été développé sans suivre les directives MISRA est produit, puis la direction se rend compte que la conformité est une exigence pour le marché visé. En règle générale, la base de code héritée n'a jamais été développée avec des directives de codage à l'esprit. Par conséquent, une base de code ne peut pas être automatiquement classée comme «code adopté» si des mises à jour sont nécessaires dans le contexte d'un nouveau projet. Cela peut devenir complexe.

Trop souvent, les analyses initiales d'une grande base de code via un outil d'analyse statique avec toutes les règles MISRA C 2012 activées, y compris l'amendement 1, produisent des dizaines de milliers de violations. Après le choc initial, les équipes commencent à trouver des moyens «créatifs» de remédier aux violations. Il est important que les équipes de développement ne soient pas dissuadées - il y a de la lumière au bout du tunnel.

Au fil du temps, j'ai collecté et identifié les meilleures pratiques et approches utilisées par les équipes de développement pour rendre le code conforme sans interférer avec la vitesse de développement en cours. Dans cet article, je partage quelques approches pratiques et équilibrées pour rendre les bases de code existantes conformes à la MISRA.

Utilisez le cadre de conformité MISRA : 2016

MISRA C 2012 est un ensemble de directives de codage pour le langage de programmation C. L'objectif de la norme est d'augmenter la sécurité des logiciels en empêchant de manière préventive les programmeurs de commettre des erreurs de codage pouvant entraîner des échecs d'exécution (et d'éventuels problèmes de sécurité) en évitant les constructions de problème connues en langage C. Au fil des ans, de nombreux développeurs de systèmes embarqués se plaignaient (et se plaignent toujours) du fait que MISRA C était une norme trop stricte et que le coût d'écriture d'un code entièrement conforme était difficile à justifier. De manière réaliste, étant donné que MISRA C est appliqué dans un logiciel critique pour la sécurité, la valeur de l'application de la norme à un projet dépend de facteurs tels que:

• Risque de dysfonctionnement du système en raison d'une défaillance logicielle
• Coût d'une défaillance du système pour l'entreprise
• Outils de développement et plateforme cible
• Niveau d'expertise du développeur

Les programmeurs doivent donc trouver un terrain d'entente pratique qui réponde à l'esprit de la norme tout en revendiquant la conformité MISRA sans gaspiller d'efforts sur des activités sans valeur ajoutée.

Dans le document Conformité MISRA: 2016 le consortium MISRA fournit la réponse dont la communauté avait besoin, avec un cadre raisonnablement bien défini de ce que la déclaration «Conforme à MISRA» signifie vraiment. Le document aide l'organisation à utiliser un langage commun articulant les exigences de conformité en définissant les artefacts suivants:

• Plan d'application des lignes directrices - montre comment chaque directive MISRA est vérifiée.
• Plan de reclassification des lignes directrices - communique la sévérité convenue des règles individuelles dans les directives dans le cadre de la relation vendeur / client.
• Rapport des écarts - documente les violations des directives avec une justification appropriée.
• Résumé de la conformité aux lignes directrices - est le principal enregistrement de la conformité globale du projet.

Pour se concentrer sur ce qu'il faut faire avec une base de code héritée, le document clé est le Re-catégorisation des lignes directrices plan. Ce document capture toutes les directives et règles et identifie les catégories qui ont été reclassées. Par exemple, le diagramme suivant montre une partie d'un plan de reclassification:

Premièrement, pour l'ancien code «adopté», le MISRA 2016: Conformité Le document suggère de ne pas recatégoriser les classifications d'une classification moins stricte à une classification plus stricte. De plus, il est possible de désappliquer Règles consultatives toutes ensemble après avoir examiné les types de violations avec l'équipe.

L'obligation de documenter les écarts n'est nécessaire que pour toutes les règles obligatoires. Toute violation du code adopté doit être examinée et les écarts doivent indiquer clairement que les violations ne compromettent pas la sûreté et la sécurité. Indépendamment de la reclassification, s'il y a une constatation qui compromet la sûreté ou la sécurité du système, le problème doit être résolu. En outre, les modifications apportées au code hérité peuvent introduire d'autres problèmes qui ne sont pas clairement vus par le développeur.

Commencer en ayant la fin à l'esprit

Un problème clé que rencontrent les développeurs de logiciels critiques pour la sécurité est de savoir comment démontrer et prouver la conformité à la fin du projet. Cela peut être une question litigieuse entraînant une perte de temps et d'efforts si les critères d'évaluation sont fondés sur les opinions subjectives des différentes parties prenantes. C'est une situation que le Conformité MISRA: 2016 document a aidé à éclaircir.

Une approche recommandée pour améliorer l'évaluation de l'état de préparation à la conformité consiste à utiliser les modèles existants pour le rapport final de conformité et de qualification des outils. Il y a aussi une tendance à ajouter plus d'informations dans les rapports que nécessaire. Si les informations ne sont pas exigées par la norme, évitez les embellissements. L'ajout d'informations supplémentaires n'est pas seulement une perte de temps, mais présente également un risque de retarder un processus d'audit.

Les informations requises à inclure dans le rapport final sont fournies par Conformité MISRA 2016:

• Plan d'application des lignes directrices
• Résumé de la conformité aux lignes directrices
• Détails de tous les permis de dérogation approuvés
• Les enregistrements des écarts couvrant toutes les violations des directives reclassés comme obligatoires.

L'exemple ci-dessous de l'outil de Parasoft montre un format HTML, avec des liens vers les sections appropriées:

Établissez tôt l'objectif final

En plus des recommandations ci-dessus, il y a quelques autres points importants à considérer:

1. Le GRP (Guideline Re-categorization Plan) a-t-il été établi au début du projet? Selon la norme MISRA, la négociation avec le acquéreur est possible, tout comme la création de plusieurs GRP pour le adopté code qui est utilisé sans aucune modification et indigène code qui sont les fichiers activement modifiés au cours du projet.

2. Pour chaque changement progressif, y a-t-il une visibilité sur le nombre d'éléments de travail restants pour parvenir à une conformité totale? Cela permet de planifier le travail en conséquence et de définir les bonnes attentes avec la direction.

3. Les modèles de rapport GPS (Guidelines Compliance Summary) ont-ils été examinés avec le acquéreur au début du projet et ont-ils été jugés acceptables et complets?

Il existe des modèles pour ces documents que les fournisseurs d'outils commerciaux d'analyse statique, y compris Parasoft, fournissent pour aider les organisations à satisfaire le cadre de conformité MISRA 2016.

Une approche par étapes: diviser pour vaincre

Bien que l'analyse initiale du code existant par un outil d'analyse statique ait tendance à produire des milliers de violations (en particulier lors de l'utilisation d'un ensemble de règles par défaut), il n'est pas pratique d'arrêter de nouveaux efforts de développement pour se concentrer sur la correction de toutes ces violations. En fait, j'ai vu des cas où des régressions ont été introduites lorsque des modifications importantes de la base de code ont été apportées pour corriger les violations de l'analyse statique. Par conséquent, il est important d'établir un flux de travail pour corriger les violations au fil du temps, sans perturber le processus de développement et sans dégrader la qualité du logiciel.

Certaines recommandations clés lors de l'utilisation d'outils d'analyse statique pour la première fois dans un projet sont énoncées ci-dessous:

• Baselining. Après l'analyse initiale du code, marquez toutes les violations initiales comme «à traiter plus tard» et définissez-les comme un de base. À partir de ce moment, lors de la mise à jour du code existant et / ou du développement d'un nouveau code, maintenez une politique «Aucune nouvelle violation autorisée». Cette politique peut être appliquée par le processus de révision de code ou un outil d'intégration continue (CI) comme Jenkins or Bambou. Lorsque les développeurs ont quelques heures ou quelques jours à perdre, ils peuvent résoudre les violations restantes marquées à partir de la ligne de base. Les organisations peuvent prioriser cette approche en fonction du code actuel en cours de développement, des résultats de la révision du code ou en s'appuyant sur des mesures (par exemple, la complexité) pour suggérer la prochaine violation à résoudre.
• Ligne dans le sable. Le développement fixe une date, «la ligne dans le sable». Après cette date, toutes les violations doivent être résolues pour chaque unité de traduction (fichier source individuel) modifiée. Toutes les unités de traduction non modifiées relèvent automatiquement de la véritable définition de code «adoptée» du document de conformité MISRA.
• Hiérarchisation basée sur la gravité. Le développeur corrige tous les résultats obligatoires pour le module qui lui est attribué. Au fil du temps, ils traitent toutes les violations obligatoires lorsque le temps le permet en fonction d'une priorité choisie par le chef d'équipe.

Pour toutes les approches décrites ci-dessus, il est important que les responsables techniques et la direction surveillent en permanence l'avancement et l'état de conformité du projet via un tableau de bord centralisé. Par exemple, le hub de reporting de Parasoft fournit le tableau de bord de statut de conformité préconfiguré suivant:

Qualification des outils

Un élément moins évident de la conformité MISRA, souvent laissé jusqu'à la fin du projet, est la reconnaissance du fait que les outils de développement utilisés dans le produit doivent être qualifiés (adaptés à l'usage prévu) pour l'utilisation prévue. Si un outil nécessite une qualification, quel niveau de validation doit être effectué?

Alors que dans de nombreux cas la qualification de l'outil est requise, le méthode qui est utilisé pour effectuer la qualification des outils varie en fonction du risque associé au dysfonctionnement de l'outil et du niveau de criticité du logiciel. Parasoft fournit un kit de qualification et des certifications pour des normes de sécurité spécifiques et leurs exigences. En l'absence de ce kit efficace, les équipes logicielles doivent tenir compte des coûts de qualification des outils lors de l'évaluation des outils commerciaux, gratuits et open source.

Certaines normes comme ISO 26262 et DO-178B / C fournir des conseils raisonnables sur les exigences de qualification des outils. Indépendamment de la méthode, le but du processus de qualification de l'outil est de déclarer que «l'outil est valide pour l'usage prévu» et de fournir une preuve et une justification de la manière dont l'équipe est parvenue à cette conclusion.

Voici quelques étapes recommandées à suivre pour un processus de qualification d'outil:

• Spécifiez les besoins en outils pour votre utilisation prévue
• Identifiez un sous-ensemble de fonctionnalités du produit qui sont utilisées. Réduisez le processus de qualification aux seules fonctionnalités utilisées
• Esquisser un plan de qualification
• Décrire l'ensemble des étapes de qualification (qui peuvent inclure des tests effectués par l'équipe) qui vérifient que l'outil répond aux exigences
• Exécuter automatiquement des cas de test qui peuvent être automatisés
• Fournir un cadre pour saisir les résultats des étapes de test manuel
• Modèles de rapport pour réduire la quantité de texte à saisir par les développeurs.
• Passez en revue le rapport avec les parties prenantes et approuvez-le.

Le fait de négliger la qualification de l'outil dès le départ peut entraîner des retards de projet en fin de cycle.

Compétence et formation du personnel

L'expertise et la formation du personnel de développement est un autre facteur clé négligé par les organisations de logiciels et fréquemment identifié par les auditeurs comme le problème numéro un lors de l'évaluation de l'état de préparation d'un produit.

Selon les directives MISRA, compétence du personnel est un élément important de la conformité MISRA. Il est préférable de dispenser une formation au début du projet et d'enregistrer une date de formation avec tous les développeurs confirmés qu'ils ont reçu la formation. À la fin du projet, l'équipe de développement devrait être en mesure de prouver que:

• Le personnel qui a approuvé les écarts comprend et a été formé pour reconnaître les risques associés à la violation
• Le personnel a été formé pour configurer et utiliser correctement les outils d'analyse et de développement statiques avant leur utilisation.

En pratique, la formation d'une équipe expérimentée est relativement courte, mais quelques jours investis dans le début du projet permettent d'économiser des semaines de retouches après le dépassement d'une échéance de projet.

Résumé

Il n'y a pas de solution miracle qui permette d'atteindre MISRA conformité du code hérité facile dans les projets critiques pour la sécurité. Cependant, avec l'introduction de la Conformité MISRA 2016 cadre, en utilisant l'approche pratique par étapes avec un point final clairement défini à l'esprit, comme indiqué dans cet article, les équipes de développement de logiciels peuvent atteindre la conformité sans perturber de manière significative leur processus de développement. L'essentiel est qu'il reste encore beaucoup de travail à faire pour atteindre la conformité, mais avec une planification intelligente et la bonne approche, un ensemble minimal et équilibré de tâches peut être établi pour rendre le code hérité et nouvellement développé sûr et sécurisé.

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