Vérification et validation : la différence, et comment les organiser
Vérification et validation sont souvent prononcées d'un seul souffle, au point qu'on les confond. Elles répondent pourtant à deux questions différentes. La vérification demande : « avons-nous bien construit le produit ? ». La validation demande : « avons-nous construit le bon produit ? ». Un système peut passer toutes ses vérifications et échouer à sa validation, si les exigences elles-mêmes étaient mal posées.
Deux définitions
La norme ISO/IEC/IEEE 15288 consacre un processus technique à chacune. La vérification vise à fournir une preuve objective qu'un système ou un élément de système satisfait les exigences et caractéristiques spécifiées. La validation vise à fournir une preuve objective que le système, lorsqu'il est utilisé, répond aux besoins de ses parties prenantes et atteint l'usage prévu dans l'environnement d'exploitation prévu.
La différence tient donc au référentiel. La vérification se juge par rapport aux exigences écrites. La validation se juge par rapport au besoin et à l'usage réel. C'est pourquoi la validation fait intervenir les utilisateurs, les exploitants ou leurs représentants, dans des conditions aussi proches que possible de l'emploi réel.
Les quatre méthodes de vérification
La plupart des référentiels d'ingénierie retiennent quatre méthodes, souvent résumées par leurs initiales. Le choix de la méthode se fait pour chaque exigence, idéalement dès sa rédaction.
- L'inspection
- Un examen visuel ou dimensionnel, ou une revue de documents : présence d'un marquage, respect d'une cote, conformité d'un câblage à un plan. C'est la méthode la moins coûteuse, réservée aux caractéristiques directement observables.
- L'analyse
- Un calcul, une modélisation, une simulation, ou l'extrapolation de résultats d'essais existants. Elle s'impose quand l'essai est impossible ou disproportionné : tenue à un séisme rare, durée de vie de vingt ans, comportement dans une configuration de panne dangereuse.
- La démonstration
- Une utilisation du système pour montrer qu'une fonction est réalisée, sans instrumentation fine : on montre qu'une trappe s'ouvre, qu'un opérateur peut effectuer une opération de maintenance dans un espace donné.
- L'essai
- Une mise en œuvre instrumentée, dans des conditions contrôlées, avec des mesures confrontées à des critères d'acceptation. C'est la méthode la plus probante et souvent la plus coûteuse : essais d'environnement (vibrations, température, compatibilité électromagnétique), essais de performance, essais d'endurance.
Une même exigence peut combiner plusieurs méthodes : une analyse pour couvrir tout le domaine de fonctionnement, et un essai pour recaler l'analyse sur quelques points.
Le cycle en V, et au-delà
La représentation la plus connue de la vérification est le cycle en V. La branche descendante décompose le besoin en exigences, puis en architecture et en conception détaillée ; la branche montante intègre les éléments et les vérifie à chaque niveau, chaque niveau d'intégration faisant face au niveau de conception correspondant. La validation se situe au sommet de la branche montante, face à l'analyse du besoin.
Le V a ses limites : il suggère un déroulement séquentiel que la norme 15288 ne prescrit pas, et que la plupart des projets ne suivent pas. Dans les développements incrémentaux, la vérification et la validation se répètent à chaque incrément. Le principe de fond reste valable : chaque niveau de conception doit avoir son pendant en vérification, et la validation doit être préparée dès l'analyse du besoin, pas découverte en fin de projet. L'ensemble des processus est présenté dans notre article sur la norme 15288.
Organiser la vérification
Une vérification maîtrisée repose sur quelques documents ou vues du modèle :
- La matrice de vérification : pour chaque exigence, la méthode retenue, le niveau d'intégration où elle sera vérifiée et le cas de vérification correspondant.
- Le plan de vérification : la stratégie d'ensemble, les moyens d'essai, l'ordre des opérations, les critères d'entrée et de sortie de chaque campagne.
- Les procédures : le déroulé détaillé de chaque essai ou démonstration.
- Les comptes rendus : les résultats, les écarts, et la configuration exacte du produit vérifié.
La matrice de vérification n'est rien d'autre qu'une vue de la traçabilité des exigences : dans un modèle SysML, la relation de vérification relie directement l'exigence au cas de test. Les exigences invérifiables apparaissent alors immédiatement, à condition de les avoir écrites selon les règles présentées dans notre article écrire une bonne exigence.
Le rôle du modèle
Une démarche basée sur les modèles apporte à la vérification et à la validation au moins trois choses. D'abord, la vérification précoce : des règles de cohérence et des simulations sur le modèle permettent de détecter des erreurs d'interface ou de logique avant tout prototype. Ensuite, la préparation des essais : les scénarios modélisés (séquences, machines à états) servent de base aux procédures. Enfin, la gestion des écarts : quand un essai échoue, la traçabilité du modèle indique quelles exigences, quels composants et quels autres essais sont concernés.
Il faut cependant se garder d'une illusion : vérifier un modèle n'est pas vérifier le système. Un modèle est une abstraction, et sa propre validité doit être établie, en le confrontant à des résultats d'essais réels. C'est particulièrement vrai lorsque des analyses par simulation remplacent des essais dans un dossier de certification.
Les erreurs fréquentes
- Penser la vérification en fin de projet, quand les moyens d'essai ne peuvent plus être commandés à temps.
- Confondre les deux notions et se croire validé parce que tout est vérifié.
- Vérifier une configuration mal identifiée : un résultat d'essai sans référence précise à la version du produit et du logiciel n'a pas de valeur probante.
- Oublier les exigences non fonctionnelles : maintenabilité, sûreté, ergonomie, qui se vérifient souvent par analyse ou démonstration et qu'on laisse pour plus tard.
- Exclure les utilisateurs de la validation, ou ne les associer qu'à la recette finale.
Sources
- ISO/IEC/IEEE 15288:2023, processus de vérification et de validation, fiche ISO.
- ISO/IEC/IEEE 29148:2018, Ingénierie des exigences, sections sur la vérification des exigences.
- INCOSE, Systems Engineering Handbook, cinquième édition, 2023, chapitres sur la vérification et la validation.
- Object Management Group, SysML 1.7, relation de vérification et cas de test.
Exigences & architectureÉcrire une bonne exigence
Les qualités attendues, des gabarits de phrase, des exemples réécrits et les pièges à éviter.
Exigences & architectureLa traçabilité des exigences
Dérivation, satisfaction, vérification : les liens à établir et l'usage qu'on en fait pour l'analyse d'impact.
Exigences & architectureLes processus de la norme 15288
Quatre groupes, trente processus : la carte de référence de l'ingénierie système, et ce qu'elle n'impose pas.