Maîtrisez le cycle de développement logiciel des systèmes connectés – ou il vous maîtrisera

Temps de lecture : 8 minutes

Si vous développez un logiciel critique pour la sécurité, vous comprenez l'importance de la traçabilité bidirectionnelle des exigences pour garantir que la conception reflète les besoins, que la mise en œuvre logicielle correspond à la conception et que les processus de test confirment la bonne implémentation de ce logiciel. Vous savez également combien les changements d'exigences peuvent être pénibles en raison de la nécessité d'identifier le code modifié et de répéter les tests nécessaires.

Jusqu'à présent, ce cycle se terminait avec la sortie du produit. Bien sûr, il peut y avoir des ajustements en réponse aux conditions sur le terrain, mais le développement était essentiellement terminé. Puis sont arrivés la voiture connectée, l'Internet industriel des objets (IIoT) et la surveillance à distance des dispositifs médicaux. Pour ces systèmes connectés et d'autres, les exigences ne changent pas de manière ordonnée uniquement pendant le développement. Elles changent sans avertir, chaque fois qu'un acteur malveillant trouve une nouvelle vulnérabilité ou élabore un nouveau hack. Et les exigences continuent de changer non seulement pendant toute la durée de vie du produit, mais aussi tant qu'il est sur le terrain.

À chaque fois qu'un changement est nécessaire, le code révisé doit être réanalysé statiquement et tous les tests unitaires et d'intégration concernés doivent être réexécutés (tests de régression). Dans une application isolée, la durée de support de ces situations dure à peine plus longtemps que la période de développement du produit. Mais la connectivité exige la capacité de répondre aux vulnérabilités identifiées sur le terrain. Chaque nouvelle vulnérabilité découverte implique une exigence modifiée ou nouvelle, nécessitant une réponse immédiate – même si le système n’a pas été manipulé par les ingénieurs de développement depuis un certain temps. Dans de telles circonstances, la capacité d'isoler et de tester automatiquement uniquement les fonctions concernées devient beaucoup plus significative.

Cela modifie l'importance de la maintenance produit et met en avant l'importance des outils et techniques de traçabilité automatisée des exigences. En reliant les exigences, le code, les résultats d'analyse statique et dynamique, et les tests, le cycle de développement logiciel devient traçable, ce qui permet aux équipes d'identifier les problèmes et de mettre en œuvre des solutions plus rapidement et de manière plus économique – même après la sortie du produit. Cela offre aux développeurs un avantage concurrentiel crucial lorsque le message redouté « nous avons été piratés » arrive.

Nous prendrons la norme ISO 26262 de sécurité fonctionnelle automobile comme exemple, mais les mêmes principes s'appliquent à d'autres industries et normes critiques pour la sécurité, telles que la DO-178C, l'IEC 61508 ou l'IEC 62304. Bien que la terminologie varie, un élément constant est la pratique consistant à attribuer des exigences techniques de sécurité dans la spécification de conception système et à développer cette conception pour en dériver un plan d'intégration et de test des éléments. Cela s'applique à tous les aspects du système, avec la subdivision explicite des pratiques de développement matériel et logiciel au fur et à mesure de l'avancement du cycle de vie. La relation entre la norme et les sous-phases spécifiques au logiciel peut être représentée dans un modèle en V (voir Figure 1).

Les produits de la phase de conception système globale peuvent inclure des dessins CAO, des feuilles de calcul, des documents textuels et de nombreux autres artefacts, développés avec divers outils. Cette phase permet également de raffiner et d'attribuer les exigences techniques de sécurité au matériel et au logiciel. Maintenir la traçabilité entre ces exigences et les produits des phases ultérieures pose généralement des défis en gestion de projet.

Les outils idéaux pour la gestion des exigences peuvent aller d'une simple feuille de calcul ou d'un document Word à des outils de gestion des exigences spécialement conçus, tels que Siemens Polarion. Le choix des outils appropriés aide à maintenir une traçabilité bidirectionnelle entre les phases de développement.

Cette sous-phase se concentre sur la spécification des exigences de sécurité logicielle pour soutenir les phases de conception suivantes, en tenant compte des contraintes imposées par le matériel. Elle fournit l'interface entre la norme de conception système et les exigences logicielles spécifiques, et détaille le processus d'évolution des exigences de niveau inférieur relatives au logiciel. Elle continuera probablement à utiliser les outils de gestion des exigences utilisés lors de la phase de conception système.

De nombreux outils permettent de générer la conception architecturale logicielle. Les outils d'analyse statique aident à vérifier la conception par l'analyse des flux de contrôle et de données du code qui en est dérivé, fournissant des représentations graphiques des relations entre les composants de code pour comparaison avec la conception prévue (voir Figure 2).

L'illustration de la Figure 3 est un exemple typique d'un tableau tiré de l'ISO 26262-6:2011. Elle montre les directives de codage et de modélisation à appliquer lors de la mise en œuvre, avec une indication des endroits où la conformité peut être confirmée à l'aide d'outils automatisés.

Ces directives combinées rendent le code résultant plus fiable, moins sujet aux erreurs, plus facile à tester et à entretenir. Les revues par les pairs représentent une approche traditionnelle pour faire respecter les directives, et bien qu'elles aient encore un rôle important à jouer, automatiser ces vérifications fastidieuses est bien plus efficace, reproductible et démontrable, et moins sujet aux erreurs. Il existe de nombreux ensembles de directives de codage disponibles, telles que MISRA, des ensembles internes ou des adaptations d'un ensemble standard pour le rendre plus approprié à une application particulière.

Établir des directives de projet appropriées pour le codage, la conception architecturale et la mise en œuvre des unités sont trois tâches distinctes, mais les développeurs logiciels responsables de la mise en œuvre de la conception doivent être conscients de toutes en même temps. Les directives concernant la conception architecturale et l'implémentation des unités sont fondées sur l'idée de rendre le code résultant plus fiable, moins sujet aux erreurs, plus facile à tester et à maintenir.

Les outils d'analyse statique peuvent fournir des métriques pour garantir la conformité à la norme, telles que les métriques de complexité, les métriques de cohésion évaluées via l'analyse des objets de données et les métriques de couplage via l'analyse des liaisons de données et de contrôle. L'analyse statique peut également garantir que les pratiques requises par les normes sont respectées, qu'il s'agisse de règles de codage, de principes de conception ou de principes de conception architecturale logicielle. En pratique, le rôle d'un tel outil évolue souvent d'un moyen de mettre en évidence les violations à un moyen de confirmer qu'il n'y en a pas.

Tout comme les techniques d'analyse statique (impliquant une « inspection » automatisée du code source) sont applicables aux sous-phases de codage, de conception architecturale et de mise en œuvre des unités, les techniques d'analyse dynamique (impliquant l'exécution de tout ou partie du code) sont applicables aux tests unitaires, d'intégration et de système. Les tests unitaires se concentrent sur des procédures ou fonctions logicielles spécifiques de manière isolée, tandis que les tests d'intégration garantissent que les exigences de sécurité et fonctionnelles sont satisfaites lorsque les unités fonctionnent ensemble conformément à la conception architecturale logicielle.

Les tableaux de l'ISO 26262-6:2011 répertorient des techniques et des métriques pour effectuer des tests unitaires et d'intégration sur le matériel cible afin de s'assurer que les exigences de sécurité et fonctionnelles sont satisfaites et que les interfaces logicielles sont vérifiées aux niveaux des unités et de l'intégration.

Les artefacts associés à ces techniques fournissent à la fois des références pour leur gestion et des preuves de leur réalisation. Ils incluent les spécifications de conception d'unités logicielles, les procédures de test, le plan de vérification et la spécification de vérification. À la fin de chaque procédure de test, les résultats de réussite/échec sont rapportés et la conformité aux exigences est vérifiée de manière appropriée.

L'exemple de la figure 6 montre comment l'interface logicielle est exposée au niveau de la fonction, permettant à l'utilisateur d'entrer des entrées et des sorties attendues pour former la base d'un harnais de test. Le harnais est ensuite compilé et exécuté sur le matériel cible, et les sorties réelles et attendues sont comparées.

Les tests unitaires deviennent des tests d'intégration lorsque les unités sont introduites dans un arbre d'appels au lieu d'être simulées. Les mêmes données de test peuvent être utilisées pour valider le code dans les deux cas. Les valeurs limites peuvent être analysées en générant automatiquement une série de cas de test unitaire, accompagnés des données d'entrée associées. Une extension de cette fonction permet de définir des valeurs limites d'équivalence telles que la valeur minimale, la valeur en dessous de la limite inférieure, la valeur limite inférieure, la valeur limite supérieure et la valeur au-dessus de la limite supérieure.

Si des changements s'avèrent nécessaires — en raison d'un test échoué ou d'un changement d'exigence de la part d'un client — tous les tests unitaires et d'intégration impactés devront être relancés (tests de régression). L'application automatique de ces tests via l'outil garantit que les modifications n'altèrent aucune fonctionnalité déjà établie.

En plus de démontrer le bon fonctionnement du logiciel, l'analyse dynamique génère également des métriques de couverture structurelle. Ces métriques fournissent les données nécessaires pour évaluer la complétude des cas de test et pour démontrer qu'il n'y a pas de fonctionnalités non souhaitées (Figure 7).

Les métriques de couverture peuvent inclure la couverture fonctionnelle, d'appel, d'instructions, de branchement et MC/DC. Les installations de test unitaire et système peuvent fonctionner en tandem, de sorte que les données de couverture peuvent être générées pour la majorité du code source via un test système dynamique, puis être complétées par des tests unitaires. Cela permet de tester, par exemple, les constructions défensives qui sont inaccessibles pendant le fonctionnement normal du système.

La traçabilité bidirectionnelle exige que chaque phase de développement reflète avec précision celle qui la précède. En théorie, si la séquence exacte du modèle en V est suivie, alors les exigences ne changeront jamais et les tests ne révéleront jamais de problème. Mais en réalité, les choses peuvent être plus complexes.

Que se passe-t-il si un changement de code est nécessaire suite à un test d'intégration échoué, peut-être parce que les exigences sont incohérentes ou qu'il y a une erreur de codage ? Quelles autres unités logicielles étaient dépendantes du code modifié ? De tels scénarios peuvent rapidement entraîner des ruptures dans la traçabilité entre les produits du développement logiciel.

La conception d''un logiciel peut prendre diverses formes, allant d'un document de conception détaillée en langage naturel à un modèle basé. Dans tous les cas, ces éléments de conception doivent être traçables dans les deux sens, à la fois vers les exigences de sécurité logicielle et vers l'architecture logicielle. Les unités logicielles doivent ensuite être mises en œuvre conformément aux spécifications et être traçables jusqu'à leur spécification de conception.

Les outils de traçabilité automatisés des exigences établissent des associations entre les exigences et les cas de test à différents niveaux, ce qui permet d'évaluer la couverture des tests (Figure 8). L'impact des cas de test échoués peut être évalué et traité, de même que les changements d'exigences et les lacunes de couverture des exigences. Des artefacts tels que des matrices de traçabilité peuvent être générés automatiquement pour fournir des preuves de conformité aux normes.

La couverture structurelle initiale est généralement obtenue dans le cadre de l'exécution de tests fonctionnels sur du code instrumenté, laissant parfois des parties de code non exécutées. Ces parties non couvertes nécessitent une analyse plus approfondie. Cela peut entraîner l'ajout ou la modification de cas de test, des changements dans les exigences, ainsi que la suppression de code mort. En général, une séquence itérative de révision, de correction et d'analyse garantit que les spécifications de conception sont respectées, assurant ainsi que le code est complet et conforme aux attentes.

Bien que les normes de sécurité fonctionnelle apportent des contributions significatives à la fois à la sécurité et à la sûreté, il est également évident qu'elles impliquent une charge de travail considérable. L'application d'outils automatisés tout au long du cycle de développement peut jouer un rôle clé pour minimiser cette charge, tout en réduisant les risques d'erreurs humaines.

Cela est d'autant plus crucial aujourd'hui, avec l'impact de la connectivité qui modifie la notion même de fin du processus de développement. Traditionnellement, un produit était considéré comme terminé lorsqu'il était lancé. Cependant, avec la connectivité moderne, chaque fois qu'une nouvelle vulnérabilité est découverte sur le terrain, elle entraîne une évolution des exigences pour y remédier. Ce phénomène met en lumière la nécessité d'une solution automatisée, qui ne soit pas seulement utilisée pendant le cycle de développement, mais aussi dans la phase post-développement pour maintenir la sécurité et la conformité continue des produits.