Les 2 grands types de processus d'Ingénierie Systèmes

Processus de mise en œuvre

Nous savons maintenant qu'un Ingénieur Système est fort utile sur un projet de création de nouveau produit ou de modification d'un existant. Comment va-t-il mettre en musique tous les métiers (le sien y compris) ?

Il existe pour ce faire plusieurs processus possibles, répartis en 2 grandes catégories :

• Processus séquentiels
• Processus Incrémentaux et Itératifs (Incremental and Iterative Development, IID)

Séquentiel : le Cycle en V

Aussi appelé Vee Cycle, voit le jour sous cette forme en 1991 à l'initiative de Forsberg et Mooz.

Le V représente le temps qui passe sur le projet (axe des abscisses) vs. la profondeur dans le détail du Système (axe des ordonnées).

Principe :

• Au début du projet on réfléchit au Besoin du Système (que voulons-nous faire avec/de ce système ?) et du Business derrière
• On le conçoit (comment réaliser telle Fonction utile à ma réponse au Besoin ?)
• On le développe (on implémente le code nécessaire au software, on réalise les plans mécaniques, électroniques etc. et on fait fabriquer le tout)
• Un fois que tout est fabriqué, codé et disponible, on assemble les éléments et on vérifie leur bon fonctionnement (seuls, puis intégrés les uns aux autres)
• On valide que le système complet répond bien au besoin
• Et le système peut partir vivre sa vie chez le(s) client(s)

Avantages :

• Fonctionne très bien pour des grandes équipes, qui travaillent dans des entreprises différentes
• Adapté aux projets complexes (Aéronautique, Systèmes embarqués, Smartphones, Voitures, ...)
• Les étapes sont prédictibles
• Progression stable et maîtrisée du travail des équipes
• Répétable d'un projet à l'autre
• Haut niveau de certitude sur le fonctionnement robuste du produit à la fin (sécurité fonctionnelle)
• Facilité de récupération des informations pour faire du retex en post mortem projet
• Certains standards modernes de sécurité et de sûreté demandent explicitement l'application du Cycle en V.

Inconvénients :

• Processus mastodonte, avec beaucoup de documentation associée
• Rigidité
• Le projet accouche du Système uniquement à la fin de toutes ces étapes (long time-to-market)

‍

IID : Agile, Evolutionary Development, ICSM

Principe :

• Ces processus IID se caractérisent par le fait de délivrer plutôt rapidement un Système répondant partiellement au Besoin
• Système qui sera ensuite complété par vagues successives d'ajouts de fonctionnalités.
• On arrête le processus quand les parties prenantes décident que le Système est enfin complet après avoir ajouté les X briques nécessaires

Avantages :

• Adapté aux produits peu complexes, ou au éléments constitutifs d'un produit complexe
• Adapté aux petites équipes
• Délivre un Système au plus vite (avec des fonctionnalités partielles seulement - time-to-market court)
• Permet de satisfaire un client qui ne sait pas vraiment ce qu'il désire initialement
• Permet de faire évoluer petit a petit son Système
• Présente régulièrement aux utilisateurs un nouveau Système, et permet de récolter leurs retours
• Évite d'investir beaucoup d'un coup dans un Système avant de se rendre compte qu'il ne satisfera personne in fine.

Inconvénients :

• Un Chef de Projet et/ou un client qui changent souvent d'avis peuvent rapidement amener à un projet chaotique
• N'invite pas à la réflexion sur une stratégie globale de réalisation d'un système; mais davantage sur des plans court termes
• Convient seulement aux petites équipes
• La prédictibilité dépend du niveau de connaissance sur les évolutions à venir

Les processus suivants sont des processus IID :

• Agile (Scrum)
  --> Certainement le plus connu.

• Evolutionary Development
  --> Utilisé dans les laboratoires de R&D
  --> Processus qui est "Plan-Driven". Toutes les exigences sont bien connues au départ, mais on choisit de construire son produit brique par brique et de les intégrer une par une. Phase de stratégie initiale.
  ‍
• Incremental Commitment Spiral Model (ICSM)
  --> "Plan-Driven"
  --> Combine certains concept du Cycle en V (spécifier avant de développer) et de l'Evolutionary Development (construction brique par brique)
  --> Chaque étape d'ajout d'une brique est vue comme une étude de faisabilité
  --> On avance d'étape en étape par l'évaluation du risque (acceptable, on avance ; sinon, on renonce).

Quel Processus choisir ? 

Ces processus ont chacun leurs avantages et leurs inconvénients. Cela dit ce sont toujours des processus, qui permettent tous de :

• Définir et ordonner les activités des équipes ("avant que le bureau d'études logicielles ne se penche sur le codage de cette fonction, j'ai besoin de savoir quel processeur le bureau d'électronique est capable de mettre sur ma carte" ou inversément selon les contraintes)
• Etablir les entrées/sorties de ces activités
• Définir les outils nécessaires à leur réalisation ("à ce moment-là on est censé valider 54 fonctions logicielles... Il serait intéressant d'automatiser cela avec un script qui ressemblerait à ceci...")
• Comprendre notre progression dans la réalisation du produit ("nous savons tout ce que doit faire le système, maintenant nous pouvons coder, dessiner les plans etc.")
• Communiquer à toutes les parties prenantes notre avancée
• Prévoir le travail restant ("nous avons terminé la vérification, il ne nous reste plus que la validation")

Un Chef de Projet et/ou Ingénieur Systèmes doit-il pour autant choisir au hasard l'un des processus d'Ingénierie Système existants ? Bien sûr que non : il faut choisir celui qui est le plus adapté.

Les facteurs qui influent sur le choix sont :

• La complexité du Système
• Les coûts envisageables pour le projet
• Les habitudes de travail des personnes qui vont être intégrées à l'équipe de réalisation du produit
• La maîtrise d'un processus plutôt qu'un autre par l'Ingénieur Systèmes
• Les objectifs du projet
• La stratégie de l'entreprise ("je préfère sortir au plus vite un produit, quitte à ce qu'il ne fasse pas tout ce que je désire")
• La qualité souhaitée sur le produit
• Sa Sécurité fonctionnelle
• Sa Sûreté
• Le nombre de personne dans les équipes
• Les ressources matérielles
• Le domaine d'application

Spoiler d'un prochain article... Des hybridations entre les processus sont possibles !

Aurélien NARDINI