Cycle en V hybride : Développement, Tests, Préséries (partie 3)

Avant d'aller plus loin, je vous recommande la lecture de la partie 1 puis 2.

‍

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

Partie 3 : Fin de descente du V

En fin d'étape 6, nous avons terminé la Conception du Système. Nous avons :

• Un jeu d'exigences détaillées au niveau sous-systèmes
• Une architecture (= décomposition du système en sous-systèmes et leurs interfaces entre eux) qui est capable de porter ces exigences
• Les allocations matérielles, logicielles, procédurales etc. de ces exigences vers l'architecture détaillée
• Le plan de vérification détaillée associé

Deuxième dérisquage

Encore une fois, avant d'aller plus loin, il est toujours mieux de tester d'une manière ou d'une autre que notre Système est viable. C'est l'étape 7. Il ne s'agit pas de voir s'il répond favorablement au Besoin, Exigences Systèmes et Exigences Détaillées car cela sera fait exhaustivement lors de la remontée du V. Il s'agit de voir plutôt brièvement (le côté bref n'est pas toujours possible) si les sous-systèmes présentent des difficultés (points bloquants majeurs) et s'ils peuvent bien être assemblés et intégrés pour constituer le Système.

Cela peut se faire selon plusieurs méthodes en fonction du Système (idem qu'à l'étape 5):

• Maquettage et quelques tests
• Modélisation et Simulation

Exemple Trottinette (décidément) :

Vous partez sur une solution où l'utilisateur démarre sa trottinette avec une petite télécommande (admettons - on admet aussi qu'il y a le super moteur thermique discuté en partie 1...). Il s'agit ici de prendre un proto de télécommande (ou un échantillon approvisionné chez un fournisseur si cela existe), le boîtier en regard qui va recevoir son signal et faire démarrer le moteur, le moteur, et voir si tout cela fait bien ce qu'on attend. Ou en tout cas, à ce stade du projet, a une chance de faire ce qu'on veut en conditions réelles.

Si chaque élément participe bien à la réalisation de ce qu'on veut dérisquer, alors c'est OK. Sinon, il faut reboucler sur les exigences des sous-systèmes et l'architecture en regard afin de corriger ce qui ne va pas. N'oubliez pas, on peut faire de l'Agile et du Design Thinking même si on fait du Cycle en V !

‍

Quelle différence avec la faisabilité de l'étape 2 ? Sur le principe l'étape 2 est aussi un dérisquage. Mais à l'étape 6 vous êtes arrivé à un niveau de compréhension du Système que vous voulez à la fin (et de ses contraintes) nettement supérieur. Il y a donc beaucoup de choses auxquelles vous n'avez pas pensé à l'étape 2 et qui méritent des petits tests. De plus, en Etape 6 vous devez vous intéresser particulièrement aux interfaces internes de votre Système, et comment celles-ci vous aident ou vous empêchent d'avoir la perfo attendue au niveau Système complet. Chose que vous n'avez pas forcément abordé en étape 2.

Développement et premiers Tests

Passons à l'étape 8. On est au niveau "élément" de mon cube de l'Ingénierie Système. On est encore descendu d'un étage, on est encore plus profond dans le système. Si l'un de vos sous-systèmes est une carte électronique, c'est le moment de parler de composants (microcontrôleur, mémoire, gestion batterie, rails d'alimentation, ...). Si un sous-système est un mécanisme, il va falloir lui aussi le détailler (pignons, arbres, lubrifiant, ...). Si on parle de logiciel, il faut en définir les fonctions et les libs à considérer. En bref, si on fait l'analogie avec des Lego, vous en êtes arrivés à vous demander quelle petite brique de quelle couleur vous allez empiler sur quelle autre pour faire le château fort de vos rêves.

Rebelote, c'est le moment de... Décliner les Spécifications Détaillées du niveau Sous-Systèmes pour obtenir une Spécification élémentaire au niveaux des Elements du Système ! Et de construire en regard l'Architecture élémentaire qui est bien capable de porter ce nouveau jeu de spécifications. On est sur de la récursivité de processus pure et dure.

L'Ingénieur Systèmes qui jusqu'à présent a beaucoup mené la danse en s'appuyant sur les compétences métiers de ses collègues de la mécanique, logiciel, électronique, etc. s'efface peu à peu et leur donne le crayon. Ces experts peuvent même décliner les spécifications eux-mêmes s'ils sont familiers de l'exercice. Attention, l'Ingénieur Systèmes doit tout de même rester dans les parages afin d'apporter sa vision holistique du Système qui est utile à tout moment. Il ne s'agirait pas de prendre à ce niveau de spécification une décision fâcheuse pour la réponse au Besoin tout en haut du V.

Trotti-exemple :

• Système : Trottinette
• Un des Sous-Systèmes (par exemple) : Ordinateur de bord avec son logiciel intégré (pour le contrôle moteur, l'affichage de la vitesse etc.)
• Elements : composants logiciels et électroniques de cet ordinateur

Et, vous l'attendez : cette spécification élémentaire doit être accompagnée d'un Plan de vérification ! Avec tous les tests qui vont bien pour s'assurer que chaque exigence est bien répondue comme attendue par le Système.

NOTA : Jusqu'à présent, l'organisation de l'Entreprise n'a peut-être pas forcément joué sur vos spécifications. Vous avez pu les laisser dans un même document à chaque étape de descente du Cycle en V. Maintenant, vous allez certainement avoir à scinder cette spécification selon les métiers qui vont la porter car cela va être confié à des équipes différentes (la spécification mécanique, la spécification logicielle, la spécification électronique etc.)

On est toujours dans l'étape 8. J'aurais pu la scinder en plusieurs morceaux, je préfère ne pas le faire car on reboucle souvent beaucoup au sein de cette étape. Les équipes métiers ont terminé leur spécification et leur architecture métier. Le tout à l'air cohérent pour l'Ingénieur Systèmes. Tout le monde sait comment tester le résultat des travaux de chaque métier. Maintenant, place au Développement ! Les électroniciens vont faire des schémas, définir des cartes, les faire câbler. Les codeurs vont coder, packager. Les mécaniciens vont acheter, usiner, mouler des pièces. On peut dire qu'on est à la pointe du V, tout en bas.

Normalement, si tout le travail amont de spécification, d'architecture etc. a été fait convenablement, toutes les questions compliquées ont déjà été adressées, tout a été clarifié et dérisqué. Les développements de chaque élément du Système n'ont plus qu'à dérouler car il n'y a plus de difficultés ni de points d'ombre (aux aléas près...). Libre aux équipes de faire également à ce moment-là du Agile.

Tous les éléments doivent bien sûr répondre à leurs exigences convenablement. C'est pourquoi la partie montante de cette étape 8 (le tout début de la remontée du V) consiste en des tests exhaustifs des éléments constitués, par les équipes, et selon les plans de vérification définis. Cela donnera lieu à un Rapport de Tests Elémentaires.

Première présérie

Avant de parler de cette remontée dans un prochain article, attardons-nous d'abord sur l'étape 9. Cette étape est intéressante car elle doit permettre, dans cette dynamique trépidante qu'est le développement, de regarder si notre Système sera fabricable à la fin et de voir si tout ce qu'on a envisagé jusqu'ici fonctionnera. On prototype... Et en plusieurs exemplaires !

Il s'agit de voir si les fournisseurs peuvent bien nous faire les pièces qu'on demande, est-ce qu'on peut bien assembler nos composants sur la carte électronique comme souhaité, est-ce que le logiciel va bien fonctionner sur la plateforme matérielle choisie,... Oui, certes. Mais ceci doit avoir été dérisqué avant. Ici, il faut surtout voir si le Système dont on construit ici les briques les plus élémentaires pourra bien être fait en plusieurs exemplaires (si c'est le but)! Une présérie de dérisquage en quelques sortes. Le logiciel est-il assez maîtrisé pour être installé à l'identique sur 10 Systèmes ? 100 ? 1000 ? La répétabilité de la fabrication mécanique est-elle satisfaisante ? L'électronique est-elle "câblable" avec le même niveau de qualité à chaque carte ? Pour s'en convaincre, dès qu'on a un minimum finalisé quelques briques et qu'elles sont assemblables, il ne faut pas se priver de faire une petite présérie.

Vous voyez que le chemin blanc suit le chemin bleu au niveau de l'étape 9... C'est le chemin d'Industrialisation justement. J'y reviendrai lors d'un prochain article. Nous ne considérons que le chemin bleu pour le moment (même si j'ai déjà un peu divulgâché).

Quelques commentaires pour terminer

Il faut user et abuser des dérisquages (maquettages, modélisations, préséries...). Ils permettent de confirmer qu'on s'engage bien dans la bonne voie pour la réalisation de notre produit. Cela évite d'arriver à la fin devant le client (client externe ou bien son chef en interne) avec un produit qui ne marche pas et passer de nombreuses heures à mettre au point à grands coûts un système bancal.

Aurélien NARDINI

‍

‍