Pourquoi devriez-vous utiliser des pratiques de développement basées sur des normes (même si vous n'y êtes pas obligé)

Toute une industrie s'est développée autour de pratiques de vérification et de validation qui sont défendues par des normes de sécurité fonctionnelle, de sécurité et de codage telles que IEC 61508, ISO 26262, IEC 62304, MISRA C et CWE. Bien sûr, tout le monde n'est pas obligé de suivre les processus formels et les méthodologies promus par ces normes, surtout si leur logiciel n'a pas besoin de répondre aux rigueurs de ces normes. Mais les normes défendent les meilleures pratiques, car l'expérience montre qu'elles représentent le moyen le plus efficace d'obtenir des logiciels de haute qualité, fiables et robustes.

Les meilleures techniques de développement qui suivent ces normes permettent de garantir que les erreurs ne sont pas introduites dans le code en premier lieu, ce qui réduit le besoin d'activités de débogage étendues qui peuvent ralentir le délai de commercialisation et augmenter les coûts. Bien sûr, tous les développeurs n'ont pas le luxe du temps et du budget accordés aux applications vues dans les secteurs de l'aérospatiale, de l'automobile ou des dispositifs médicaux. Les techniques qu'ils déploient, cependant, représentent une boîte à outils avec d'énormes avantages potentiels pour toute équipe de développement, que la criticité impose leur utilisation ou non.

Types d'erreurs et outils pour les corriger

Deux principaux types d'erreurs peuvent être détectés dans le logiciel et résolus à l'aide d'outils pour empêcher l'introduction d'erreurs :

• Erreurs de codage. Un exemple est le code qui essaie d'accéder en dehors des limites d'un tableau. Ces types de problèmes peuvent être détectés en effectuant une analyse statique.
• Erreurs d'application. Ceux-ci ne peuvent être détectés qu'en sachant exactement ce que l'application est censée faire, ce qui signifie tester par rapport aux exigences.

Erreurs de codage et révision de code

L'analyse statique est une technique efficace pour détecter les bugs de codage, surtout lorsqu'elle est déployée dès le début d'un projet. Une fois le code analysé, différents types de résultats peuvent être visualisés. La revue de code est l'endroit où le code est vérifié par rapport à une norme de codage telle que MISRA C:2012, c'est ce sur quoi nous nous concentrerons dans cet article.

Idéalement, un langage sûr tel qu'Ada serait utilisé pour tous les projets embarqués. Ada comprend de nombreuses caractéristiques pour imposer une réflexion qui réduit naturellement les erreurs (comme la saisie stricte, par exemple). Malheureusement, il est difficile de trouver des programmeurs ayant des connaissances et de l'expérience en Ada, c'est pourquoi la majorité des entreprises utilisent plutôt C et/ou C++. Ces langages, cependant, présentent des pièges même pour les développeurs expérimentés. Heureusement, en effectuant une revue de code, la plupart de ces pièges potentiels peuvent être évités.

La meilleure façon d'éviter les défauts dans le code est d'éviter de les y mettre. Cela semble évident, mais c'est exactement ce que fait une norme de codage. Dans le monde C et C++, environ 80% des défauts logiciels sont causés par une utilisation incorrecte d'environ 20% du langage. Si l'utilisation de la langue est limitée pour éviter les parties de la langue qui sont connues pour être problématiques, alors les défauts sont évités et la qualité du logiciel augmente considérablement.

Les causes fondamentales d'échec liées au langage avec les langages de programmation C/C++ sont un comportement indéfini, un comportement défini par l'implémentation et un comportement non spécifié. Ces comportements entraînent des bogues logiciels et des problèmes de sécurité.

Comme exemple de comportement défini par l'implémentation, considérons la propagation du bit de poids fort lorsqu'un entier signé est décalé vers la droite. Le résultat est-il 0x4000000 ou 0xC0000000 ?

Figure 1 :Le comportement de certaines constructions C et C++ dépend du compilateur utilisé. (Source :LDRA)

La réponse dépend du compilateur que vous utilisez (Figure 1). Cela pourrait être l'un ou l'autre. L'ordre dans lequel les arguments d'une fonction sont évalués n'est pas spécifié dans le langage C. Dans le code illustré à la figure 2, où le rollDice() La fonction lit simplement la valeur suivante à partir d'un tampon circulaire contenant les valeurs "1, 2, 3 et 4" - la valeur renvoyée attendue serait 1234. Il n'y a, cependant, aucune garantie de cela et au moins un compilateur générera du code qui renvoie la valeur 3412.

Figure 2 :Le comportement de certaines constructions C et C++ n'est pas spécifié par les langages. (Source :LDRA)

Les langages C/C++ présentent de nombreux pièges comme celui-ci, mais avec l'utilisation d'une norme de codage, ces comportements non définis, non spécifiés et définis par l'implémentation peuvent être évités. De même, l'utilisation de constructions telles que goto ou malloc peut conduire à des défauts, de sorte qu'une norme de codage peut être utilisée pour empêcher l'utilisation de ces constructions. De nombreux problèmes surviennent lors du mélange de valeurs signées et non signées, ce qui ne génère aucun problème la plupart du temps, mais il peut parfois y avoir un cas particulier où la valeur signée déborde et devient négative.

Les normes de codage peuvent également vérifier que le code est écrit dans un style particulier; par exemple vérifier que le caractère de tabulation n'est pas utilisé, que l'indentation est d'une taille spécifique, ou que les parenthèses sont positionnées dans une position spécifique. Ceci est important car une révision manuelle du code sera nécessaire et lorsque le code est affiché dans un éditeur différent où le caractère de tabulation a une taille différente, la disposition étrange empêche le réviseur de se concentrer sur la révision du code.

Certains développeurs sont coupables d'avoir écrit du code « intelligent » qui peut être très efficace et compact, mais peut aussi être cryptique et complexe, ce qui le rend difficile à comprendre pour les autres. Il est préférable de rester simple et de laisser le compilateur s'occuper de créer un binaire efficace. Encore une fois, l'utilisation d'une norme de codage peut aider à empêcher les développeurs de créer du code non documenté et trop complexe.

Les normes de programmation les plus connues sont peut-être les normes MISRA, qui ont été publiées pour la première fois en 1998 pour l'industrie automobile. La popularité de ces normes se reflète dans le nombre de compilateurs embarqués offrant un certain niveau de vérification MISRA. La dernière version de MISRA est MISRA C:2012, qui a presque le double du nombre de pages de son prédécesseur. La plupart de cette documentation supplémentaire consiste en des explications utiles sur la raison de l'existence de chaque règle, ainsi que des détails sur les différentes exceptions à cette règle. MISRA a plusieurs directives et, le cas échéant, elles contiennent des références à des normes ou au comportement non défini, non spécifié et défini par la mise en œuvre. Un exemple de ceci peut être vu dans la Figure 3.

Figure 3 : références MISRA C à un comportement non défini, non spécifié et défini par l'implémentation. (Source :LDRA)

La majorité des directives MISRA sont « décidables », ce qui signifie qu'un outil doit être capable d'identifier s'il y a une violation ou non. Cependant, quelques lignes directrices sont « indécidables », ce qui signifie qu'il n'est pas toujours possible pour un outil de déduire s'il y a une violation ou non. Un exemple de ceci est lorsqu'une variable non initialisée est transmise en tant que paramètre de sortie à une fonction système qui doit l'initialiser. Cependant, à moins que l'analyse statique n'ait accès au code source de la fonction système, elle ne peut pas savoir si cette fonction utilise la variable avant de l'initialiser. Si un simple vérificateur MISRA est utilisé, il se peut qu'il ne signale pas cette violation, ce qui peut conduire à un faux négatif. Alternativement, si un vérificateur MISRA n'est pas sûr, il peut signaler la violation, ce qui peut conduire à un faux positif. Quel est le meilleur ? Ne sachant pas qu'il pourrait y avoir un problème? Ou savoir exactement où passer du temps pour s'assurer qu'il n'y a définitivement pas de problème ? Il est certainement préférable d'avoir des faux positifs plutôt que des faux négatifs.

En avril 2016, le comité MISRA a publié un amendement à MISRA C:2012 qui a ajouté 14 directives supplémentaires pour aider à garantir que MISRA était applicable non seulement pour les logiciels critiques pour la sécurité mais aussi pour les logiciels critiques pour la sécurité. L'une de ces directives était la directive 4.14, qui, comme le montre la figure 4, permet d'éviter les pièges dus à un comportement indéfini.

Figure 4 :MISRA et considérations de sécurité. (Source :LDRA)

Erreurs d'application et test des exigences

Les bogues d'application ne peuvent être trouvés qu'en testant que le produit fait ce qu'il est censé faire, ce qui signifie avoir des exigences. Éviter les bogues d'application nécessite à la fois de concevoir le bon produit et de bien concevoir le produit.

Concevoir le bon produit signifie établir des exigences dès le départ et assurer une traçabilité bidirectionnelle entre les exigences et le code source afin que chaque exigence ait été implémentée et que chaque fonction logicielle remonte à une exigence. Toute fonctionnalité manquante ou inutile (qui ne répond pas à une exigence) est également un bogue d'application. Concevoir correctement le produit consiste à confirmer que le code système développé répond aux exigences du projet, ce qui peut être réalisé en effectuant des tests basés sur les exigences.

La figure 5 montre un exemple de traçabilité bidirectionnelle. Dans cet exemple simple, une seule fonction a été sélectionnée et la traçabilité en amont est mise en évidence de la fonction à une exigence de bas niveau, puis à une exigence de haut niveau et enfin à une exigence de niveau système.

Figure 5 :Traçabilité bidirectionnelle, avec fonction sélectionnée. (Source :LDRA)

Dans la figure 6, une exigence de haut niveau a été sélectionnée, et la mise en évidence montre à la fois la traçabilité en amont vers une exigence de niveau système et la traçabilité en aval vers les exigences de bas niveau et vers les fonctions du code source.

cliquez pour agrandir l'image

Figure 6 :Traçabilité bidirectionnelle, avec exigence sélectionnée. (Source :LDRA)

Cette capacité à visualiser la traçabilité peut conduire à la détection de problèmes de traçabilité (bugs d'application) au début du cycle de vie.

Tester la fonctionnalité du code exige une connaissance de ce qu'il est censé faire, ce qui signifie avoir des exigences de bas niveau pour indiquer ce que fait chaque fonction. La figure 7 montre un exemple d'exigence de bas niveau, qui, dans ce cas, décrit entièrement une fonction unique.

Figure 7 :Exemple d'exigence de bas niveau. (Source :LDRA)

Les cas de test sont dérivés d'exigences de bas niveau, comme illustré dans le tableau 1.

Tableau 1 : cas de test dérivés d'exigences de bas niveau. (Source :LDRA)

À l'aide d'un outil de test unitaire, ces cas de test peuvent ensuite être exécutés sur l'hôte ou la cible pour s'assurer que le code se comporte conformément aux exigences. La figure 8 montre que tous les cas de test ont été régressés et réussis.

Figure 8 :Réalisation de tests unitaires. (Source :LDRA)

Une fois les cas de test exécutés, la couverture structurelle doit être mesurée pour s'assurer que tout le code a été exercé. Si la couverture n'est pas à 100 %, il est possible que d'autres cas de test soient nécessaires ou qu'il y ait du code superflu qui doit être supprimé.

Conclusion

Avec une complexité logicielle croissante, les erreurs logicielles potentielles augmentent également. Les meilleures techniques de développement permettent d'éviter que ces erreurs ne se produisent. Le développement des meilleures pratiques consiste à utiliser une norme de codage de pointe telle que MISRA C:2012, à mesurer des métriques sur le code, à suivre les exigences et à mettre en œuvre des tests basés sur les exigences. La mesure dans laquelle ces techniques sont appliquées lorsqu'il n'y a aucune obligation de respecter les normes est clairement à la discrétion de l'équipe de développement. Cependant, les normes défendent ces pratiques car l'expérience montre qu'elles représentent le moyen le plus efficace d'obtenir des logiciels de qualité, fiables et robustes. Et qu'un produit soit critique pour la sécurité ou non, c'est certainement un résultat qui ne peut être que bénéfique pour son équipe de développement.