Cycle en V hybride : Intégration, Vérification, Validation (partie 4)

Cycle en V vs Agile sur un Projet: combinez! Voici la fusion du V model, de l’Agile et du Design Thinking. Définition, explication, exemple. Partie 4 !

Avant d'aller plus loin, je vous recommande la lecture des parties 1, 2, 3.

Mon implémentation personnelle du Cycle en V

Dans cet article sur mon processus personnel d'Ingénierie Systèmes, nous allons traiter des étapes 10 à 12 sur le chemin bleu. D'autres articles suivront pour les étapes suivantes et celles en parallèles repérées par des lettres.

Partie 4 : Fin de remontée du V

Nous avons terminé l'étape 8 et 9. Nous en sommes donc ici :

  • Le Besoin Technique du Système est connu et agréé avec le client
  • Le Système est complètement spécifié depuis le niveau Système jusqu'au niveau Elémentaire.
  • Une Architecture est disponible a tous les niveaux et elle porte convenablement ces exigences
  • Les plans d'Intégration et de Vérification à tous les étages du Système sont disponibles
  • Le plan de Validation est disponible
  • Et nous avons un Rapport de Tests Elementaires (correspondant aux tests du Plan de Vérifications Elementaires) dûment rempli qui atteste que chacun des éléments du Système fonctionne comme attendu.

Les Logiciels chacun dans leur coin sont bien fonctionnels (toutes les fonctions sont OK, leur intégration également). Les cartes électroniques également. Les parties mécaniques aussi, etc.

Intégrations et Vérifications des sous-Systèmes

On peut donc passer à l'étape 10 : l'Intégration et la Vérification Détaillée. Ici il 'agit de dérouler le Plan d'Intégration et Vérification Détaillée qu'on a préparé en étape 6.

Ce plan doit avoir prévu :

  • Les tests de chaque sous-système pour s'assurer que toutes leurs exigences sont bien remplies au niveau de performance attendu.
  • Les tests d'interface entre chacun des sous-systèmes à intégrer
  • Mais également les étapes amonts d'intégration, nécessairement préalables auxdits tests (flasher/installer les logiciels sur les plateformes hardware par exemple).
Tests de ce sous-système

NOTA : Si on veut être tout à fait malin lors de l'étape 6, il faut aussi anticiper les besoins en outils qui faciliteront nos tests de l'étape 10. Il est toujours bon de considérer qu'on refera plusieurs fois la remontée du V. Peut-être qu'on va y rencontrer un problème qui nécessite modification de l'architecture système*. Et donc de refaire une remontée de V une fois le problème corrigé. Ainsi, s'armer pour automatiser le maximum de tests est une bonne pratique. Cela reste un risque Programme à gérer : est-il pertinent de dépenser N*10k€ pour créer des outils dont on ne se servira qu'une fois ? Ou bien on considère qu'on s'en servira au moins 2 fois ? 

* cela arrive 90% du temps.

NOTA BENE : Ne pas oublier également la vie du Système, en opération chez le client. Peut-être qu'après 1 an d'utilisation, le client voudra qu'on y apporte des modifications. A ce moment-là, il faudra changer la spécification du Système, changer ses plans de vérifications, faire la modification, la vérifier, et la déployer. Si on a des outils qui automatisent les tests qu'on aura conservés, alors c'est encore du temps gagné.

On sort de l'étape 10 avec un Rapport d'Intégration et de Vérification Détaillée qui statue sur chacun des tests passés par nos sous-systèmes.

Deuxième présérie

Si tout est OK (ou en tout cas non bloquant) dans ce Rapport, il semble judicieux de passer par l'étape 11. C'est à nouveau une présérie de tests pour notre Système. Tous les sous-systèmes de notre Système sont matures, est-ce qu'on peut bien les intégrer de manière répétable dans le Système complet ? Ce qui voudra dire qu'on pourra se lancer sereinement dans la production série ? 

Vous voyez qu'il y a 3 chemins sur cette étape 11 : le chemin du Produit, le chemin de l'Industrialisation, et le chemin du Support. Je reviendrai dans des articles dédiés sur ces 2 autres chemins. Pour l'heure, restons sur le bleu.

Présérie de sous-systèmes (cartes) qui vont constituer la présérie Système (complet)

Intégration, Vérifications Système et Validation

L'étape 12 est l'Intégration et la Vérification Système, puis sa Validation. La philosophie est la même que pour l'étape 10 : on déroule le plan judicieusement construit en étape 4. Il permet de s'assurer qu'on peut bien intégrer tous les sous-systèmes entre eux pour en faire un Système complet, et que le Système complet répond favorablement à ses Exigences Systèmes, en s'interfaçant à tous les autres Systèmes autour de lui.

La toute fin de l'étape 12 correspond à la Validation. La philosophie est encore la même : on déroule le plan judicieusement construit en étape 3. Il permet de s'assurer que le Système complet répond favorablement au Besoin.

NOTA : Au sujet de la différence entre Vérification et Validation :

  • Lors de la Vérification, on s'assure que le Système (et ses sous-systèmes et éléments) répond aux exigences
  • Lors de la Validation, on s'assure que le Système (complet) répond au Besoin

Les anglophones ont une belle formule pour retenir la différence entre Vérification et Validation :

  • Vérification : "you built the system right"
  • Validation : "you built the right system"

La Validation comprend plusieurs aspects qui pourraient tout à fait faire l'objet d'un découpage en phases distinctes du Cycle en V :

  • Les tests d'intégration externe --> Le Système s'intègre-t-il bien avec tous les autres Systèmes qui vont l'entourer dans sa vie (communications USB ? Radio ? Fixation mécanique d'un système dans l'autre ? etc.)
  • Les tests de vie réelle --> période d'essais du Système chez le client afin qu'il puisse effectivement dire que le Système lui convient
  • Les tests de Qualification en environnements --> tests de tenue du Système aux environnements mécaniques (chocs, vibrations), thermiques (cycles de chaleur humide par exemple), chimique (étanchéité à l'eau, corrosion, ...), électromagnétiques (susceptibilité, émissions). Certains de ces tests vous autoriseront même à prétendre à une certification (marquage CE par exemple).
  • Les tests d'Usability Study (Summative Study) qui sont obligatoires si vous développez un Dispositif Médical par exemple.
Tests en vibration d'un élément du rover Curiosity (NASA)

Quelques commentaires pour terminer

Il ne faut pas négliger l'outillage nécessaire pour la remontée du Cycle en V. Notamment pour la Qualification : par quels moyens allez-vous vous assurer que le Système actuellement immergé dans l'eau va bien (si étanchéité vous souhaitez) ? Idem lorsque le Système sera en salle de tests électromagnétiques (entièrement blindée et sans fenêtres) ?

Prévoyez dans votre planning 2 campagnes de remontée de V. Vous allez certainement trouver un problème qui nécessitera modifications du Système et donc repassage de tout ou partie des tests.

Aurélien NARDINI

Un Système Sans Problème est une ressource de connaissances et de savoir-faire pratiques, avec exemples concrets.

Que vous soyez Chef de Programme, Chef de Projet, Architecte Système, Ingénieur, Manager dans l'Industrie, Etudiant ou Curieux de l'Ingénierie, vous êtes au bon endroit.

Au travers d'articles publiés régulièrement, découvrez ou révisez les Processus, Méthodes, Outils et Astuces utiles pour concevoir et piloter dans les domaines du Software, Firmware, de l’Électronique, et de la Mécanique.
 
Parce-qu'un produit fiable et industrialisable ne s'improvise pas !