Les équipes de conception de puces et de systèmes électroniques sont confrontées à un problème qui dépasse l’augmentation du nombre de tests ou l’automatisation des processus de régression. À mesure que les produits s’appuient davantage sur des architectures dépendantes des logiciels et qu’ils intègrent des composants matériels, logiciels et sous-systèmes, les preuves de vérification se répartissent entre différents outils, équipes et étapes, tandis que les exigences et les configurations évoluent et que la propriété intellectuelle est réutilisée dans de nouveaux contextes.
Dans ce contexte, Jake Wiltgen et Mike Andrews estiment que le principal défi consiste à préserver le sens et la cohérence tout au long du cycle de vie, et non pas simplement à produire davantage d’enregistrements. L’article publié sous la forme d’un blog sponsorisé présente le concept de « fil de vérification » comme un lien numérique structuré entre les exigences, les critères, les activités de vérification, les configurations et les résultats.
Le problème n’est pas le manque de données
Les environnements de vérification produisent déjà des journaux, des chronogrammes, des signaux, des confirmations, des mesures de couverture et des résultats de réussite ou d’échec. Mais un résultat de test positif n’explique pas à lui seul quelle exigence il a traitée, ni quelle version de la conception, quel environnement de test et quelles configurations ont été utilisés, ou quelles hypothèses ont déterminé le scénario.
Il en va de même pour les chiffres de couverture. Ils indiquent une activité ou une progression, mais ne prouvent pas à eux seuls que la vérification est suffisante. Et lorsque des exigences ou des configurations changent, les équipes doivent reconstruire manuellement le contexte afin de déterminer quels tests sont concernés et si les résultats précédents restent valides.
Qu’ajoute le fil de vérification ?
Les auteurs proposent de considérer chaque événement de vérification comme une preuve d’ingénierie réutilisable, et non comme une simple ligne dans un rapport de régression. Cela consiste notamment à relier l’activité à l’exigence ou à l’intention d’ingénierie, et à enregistrer les critères, la version de la conception, l’environnement d’exécution, les stimuli, les contraintes et les preuves associées.
Cette interconnexion permet aux équipes de passer de l’affirmation « nous avons effectué le test » à une réponse plus précise : comment l’exigence a-t-elle été vérifiée, dans quelles conditions, avec quelles preuves et quelles lacunes subsistent ? Elle aide également à évaluer la validité des résultats antérieurs lors de la réutilisation de modules ou du développement de conceptions dérivées, plutôt que de répéter le travail de manière aléatoire ou de l’écarter sans analyse.
De l’intégration des outils à l’unification du sens
L’article souligne que la mise en relation des applications ou l’échange de fichiers ne suffisent pas à construire un véritable fil de vérification. La vérification du matériel, la vérification des logiciels, les tests système, les analyses de sécurité et la gestion des exigences utilisent des abstractions et des critères de réussite différents.
Le modèle proposé a donc besoin de significations communes reliant les exigences, les critères, les configurations et les objets de preuve, même lorsqu’ils sont créés dans des environnements différents. Le résultat ressemble à un réseau de connaissances d’ingénierie permettant d’identifier les preuves manquantes, dupliquées ou obsolètes, et de suivre l’impact d’une modification d’exigence sur les tests et les résultats associés.
Pourquoi cette information est-elle importante ?
L’importance de cette proposition réside dans le fait qu’elle redéfinit la vérification comme une question d’architecture d’ingénierie continue, et non comme une étape de documentation ultérieure. Le développement réparti entre des équipes, des fournisseurs et des sites géographiques différents réduit la dépendance aux connaissances implicites. En outre, l’augmentation du coût des retards et de l’ambiguïté lors des phases d’homologation rend l’exhaustivité des preuves et leur capacité à être défendues encore plus importantes.
L’article pose toutefois une limite claire : aucun outil ni aucun fil numérique ne peut remédier à des exigences ambiguës, à des critères indéfinis ou à des preuves enregistrées de manière incohérente. La réussite de l’approche exige donc de décomposer les exigences en attentes vérifiables, de rendre les critères explicites et d’enregistrer les événements de vérification dans une structure organisée.
Sur la base des faits présentés, la principale valeur pratique ne réside pas dans l’ajout d’un nouveau tableau de bord, mais dans le fait de rendre les résultats de vérification compréhensibles, réutilisables et propices à l’analyse d’impact. La référence à la solution Questa One VeriThreader et au livre blanc « Rethinking Traceability for Modern Systems » apparaît à la fin d’un contenu promotionnel et ne fournit pas suffisamment de détails indépendants pour évaluer le produit ou le comparer à d’autres solutions.