3.9 Ingénierie des systèmes

Vue d’ensemble et motivation

L’ingénierie des systèmes est la discipline de concevoir un système complexe entier de bout en bout, pour que toutes ses parties fonctionnent ensemble pour satisfaire un vrai besoin. Les parties incluent bien plus que du logiciel. Un système moderne combine généralement du logiciel, du matériel, des personnes, des données, et des processus, et il doit fonctionner dans un monde réel désordonné. L’ingénierie des systèmes garde tout cela aligné à travers toute la vie du système.

C’est différent de l’architecture logicielle. L’architecture logicielle (chapitre 3.1) décide comment les composants logiciels sont structurés et comment ils se parlent. L’ingénierie des systèmes se trouve un niveau au-dessus. Elle demande ce que le système dans son ensemble doit faire, comment le logiciel, le matériel, et les opérateurs humains divisent le travail, et comment vous prouverez que la chose finie fonctionne. Son foyer professionnel est l’INCOSE, le International Council on Systems Engineering, et sa norme d’ancrage est l’ISO/CEI/IEEE 15288, qui définit les processus pour la vie d’un système.

Cela compte pour les grands programmes d’entreprise et gouvernementaux parce que leurs systèmes sont grands, de longue durée, et critiques pour la sécurité ou la mission. Une plateforme de défense, un système de contrôle aérien, ou une constellation de satellites mélange du matériel sur mesure, des pièces tierces, du logiciel embarqué et cloud, et des opérateurs humains, et aucune équipe seule ne peut tenir tout cela en tête. Vous construisez aussi souvent un système de systèmes : de nombreux systèmes indépendants, chacun utile en lui-même, qui doivent coopérer pour délivrer une capacité plus large.

Ce chapitre se rattache aux exigences logicielles (chapitre 2.8), aux fondamentaux d’architecture (chapitre 3.1), aux modèles et méthodes logiciels (chapitre 2.12), à l’interopérabilité et aux normes ouvertes (chapitre 3.8), et à la gestion de projet (chapitre 10.6).

Principes clés

Concevez le tout, pas les parties. Un système réussit ou échoue en tant que tout, donc optimiser un sous-système isolément peut aggraver le tout.
Suivez le cycle de vie. Un système a une vie du premier concept à la retraite finale. Planifiez pour tout cela, pas seulement la construction.
Tracez chaque exigence. Chaque besoin devrait correspondre à une exigence, un élément de conception, et un test. Si vous ne pouvez pas le tracer, vous ne pouvez pas le prouver.
Gérez les interfaces délibérément. La plupart des échecs se produisent aux frontières entre les parties, donc les interfaces méritent une propriété et un contrôle explicites.
Vérifiez et validez séparément. Construire la chose correctement (vérification) et construire la bonne chose (validation) sont des questions différentes, et vous avez besoin des deux réponses.
Attendez-vous à un comportement émergent. Combiner des parties crée un comportement qu’aucune partie seule ne montre. Une partie de cela est le but, et une partie est une méchante surprise.
Co-concevez le matériel et le logiciel. Quand les deux sont sur mesure, les décisions de l’un contraignent l’autre, donc planifiez-les ensemble.

Recommandations

Gérer le cycle de vie complet du système

Traitez le système comme ayant une vie entière, et planifiez chaque étape. Un cycle de vie courant suit : le concept (comprendre le besoin et explorer les options), les exigences (énoncer précisément ce que le système doit faire), la conception (décider l’architecture et les parties), l’intégration (rassembler les parties), la vérification et validation (prouver que cela fonctionne et que c’est le bon système), l’exploitation (l’exécuter et le maintenir), et la retraite (le mettre hors service en sécurité, incluant les données et l’élimination). L’ISO/CEI/IEEE 15288 vous donne un cadre de processus pour cela. Les étapes n’ont pas besoin d’être une cascade rigide à sens unique ; vous pouvez itérer, prototyper, et livrer par incréments. Le point est que vous adressez consciemment chaque étape, incluant les étapes ultérieures coûteuses que les plans précoces ignorent souvent.

Capturer les besoins des parties prenantes et allouer les exigences avec traçabilité

Commencez par les gens qui se soucient du système : utilisateurs, opérateurs, propriétaires, régulateurs, et le public. Rassemblez leurs besoins en langage simple, puis transformez ces besoins en exigences d’ingénierie qui sont spécifiques et testables (voir chapitre 2.8). Vient ensuite l’allocation d’exigences : assigner chaque exigence de niveau système à un sous-système spécifique, pour que vous sachiez quelle partie est responsable de la satisfaire. Gardez une matrice de traçabilité, un enregistrement vivant qui lie chaque besoin à son exigence, à l’élément de conception qui la satisfait, et au test qui la vérifie. Elle vous permet de prouver à tout moment que chaque besoin est couvert et que chaque partie existe pour une raison.

Gérer explicitement les interfaces

Les interfaces sont là où les parties se rencontrent, et où les systèmes se cassent le plus souvent. Une interface peut être un connecteur physique, un protocole réseau, un format de données, ou une procédure humaine. Pour chacune, écrivez un document de contrôle d’interface (ICD) : une spécification convenue de exactement comment deux parties se connectent et échangent de l’information. Donnez à chaque interface un propriétaire clair de chaque côté. S’appuyer sur des spécifications partagées et publiées plutôt que des connecteurs ponctuels rend l’intégration bien plus facile, ce qui est l’argument d’interopérabilité du chapitre 3.8. Gelez les interfaces tôt là où vous le pouvez, parce qu’un changement tardif se répercute dans chaque partie qui la touche.

Intégrer puis vérifier et valider

L’intégration système combine les sous-systèmes dans le tout fonctionnel, généralement par étapes plutôt que d’un coup, pour que vous trouviez les problèmes pendant qu’ils sont encore petits. Après l’intégration vient la vérification et validation (V&V), deux vérifications distinctes. La vérification demande : avons-nous construit le système correctement, c’est-à-dire satisfait-il ses exigences spécifiées ? Vous vérifiez par inspection, analyse, démonstration, et test. La validation demande : avons-nous construit le bon système, c’est-à-dire satisfait-il les vrais besoins des parties prenantes en usage réel ? Un système peut passer la vérification (il satisfait la spécification) mais échouer la validation (la spécification était fausse). Planifiez les deux tôt, et écrivez les exigences et les interfaces pour qu’elles puissent être vérifiées du tout.

Adopter l’ingénierie des systèmes fondée sur les modèles

L’ingénierie des systèmes traditionnelle produisait des montagnes de documents qui dérivaient hors synchronisation. L’ingénierie des systèmes fondée sur les modèles (MBSE) remplace ce tas par un unique modèle formel et partagé du système, à partir duquel des vues et rapports sont générés. Le langage de modélisation commun est SysML (Systems Modeling Language), un langage graphique pour décrire les exigences, la structure, le comportement, et les contraintes d’un système. Parce que tout vit dans un modèle connecté unique, un changement se met à jour partout, et la traçabilité devient une requête plutôt qu’une chasse manuelle. La MBSE se rattache aux idées de modélisation du chapitre 2.12. Adoptez-la graduellement, en commençant par les parties à plus haut risque où un modèle partagé rapporte le plus vite.

Appliquer la pensée systémique au comportement émergent

Pratiquez la pensée systémique : raisonnez sur le tout et les relations entre les parties, pas seulement les parties une à la fois. C’est comment vous anticipez le comportement émergent : des propriétés qui apparaissent seulement quand les parties se combinent et qu’aucune partie seule ne montre. La bonne émergence est souvent le but du système (une flotte de drones couvre une zone qu’aucun drone seul ne pourrait couvrir). La mauvaise émergence est l’échec surprise (deux sous-systèmes sûrs interagissent pour créer un état dangereux). Vous ne pouvez pas tester hors d’un système une émergence que vous n’avez jamais modélisée, donc utilisez la simulation et l’analyse de risque structurée pour la trouver avant l’exploitation.

Co-concevoir le matériel et le logiciel

Quand un système inclut du matériel sur mesure, concevez le matériel et le logiciel ensemble, une pratique appelée co-conception matériel/logiciel. Les décisions se lient mutuellement : le matériel fixe les limites de minutage, de mémoire, et de puissance dans lesquelles le logiciel doit vivre, et les besoins du logiciel façonnent ce que le matériel doit fournir. Les longs délais matériels pilotent aussi le calendrier. Décidez tôt quelles fonctions vivent dans le matériel et lesquelles dans le logiciel, et révisez cette division à mesure que les contraintes émergent.

Compromis : avantages et inconvénients

Approche	Avantages	Inconvénients / coût
Rigueur complète d’ingénierie des systèmes	Moins de surprises tardives, forte traçabilité, plus sûr et auditable	Coût élevé en amont, démarrage plus lent, processus lourd
Approche légère / logiciel seul	Rapide, bon marché, flexible pour une petite portée	S’effondre sur les grands systèmes multi-disciplinaires, manque les interfaces et l’émergence
Fondée sur les modèles (MBSE)	Source unique de vérité, traçabilité facile, vues cohérentes	Coût d’outillage et de formation, changement de culture, courbe d’apprentissage
Ingénierie des systèmes fondée sur les documents	Familière, faible coût d’outillage, facile à partager	Les documents dérivent hors synchronisation, la traçabilité est manuelle et sujette aux erreurs

Le compromis central est la rigueur contre la vitesse. L’ingénierie des systèmes complète charge l’effort en amont dans le concept, les exigences, et le travail d’interface. Cet effort se rembourse plusieurs fois sur les systèmes grands, de longue durée, et critiques pour la sécurité, où un défaut trouvé en exploitation peut coûter des milliers de fois plus qu’un même défaut trouvé dans les exigences. Sur un petit produit logiciel seul et de courte durée, cette rigueur est excessive. Assortissez le poids de votre processus à la taille, la durée de vie, et le risque du système. Le mode d’échec est d’appliquer des habitudes de projet jetable à un système qui fonctionnera pendant trente ans et portera un risque du monde réel.

Questions à discuter avec votre équipe

Où avez-vous construit exactement ce que la spécification exigeait et livré quand même le mauvais système, et qu’est-ce qui l’aurait attrapé ? La vérification (avons-nous bien construit) et la validation (avons-nous construit la bonne chose) répondent à des questions différentes, et un système peut passer chaque test de vérification tout en échouant la validation parce que la spécification elle-même était fausse. Sur les grands programmes, les deux sont fusionnés en « test », donc personne ne valide contre le vrai besoin de l’opérateur avant tard, quand une correction coûte des milliers de fois plus qu’un changement d’exigence. Apportez un exemple passé où le système livré satisfaisait ses exigences mais manquait le vrai besoin, et demandez quelle activité de validation (une simulation avec de vrais opérateurs, un prototype précoce sur le terrain) l’aurait révélé plus tôt. Planifiez les deux vérifications dès le départ, et écrivez les exigences et interfaces pour qu’elles puissent être vérifiées du tout. La distinction décide où vous dépensez l’effort de relecture rare.
Comment chassez-vous le mauvais comportement émergent avant que le système ne soit en exploitation, pas après ? Combiner des sous-systèmes sûrs peut créer des états dangereux qu’aucune partie seule n’exhibe, et vous ne pouvez pas tester hors d’un système une émergence que vous n’avez jamais modélisée. Pour un programme critique pour la sécurité ou la mission, l’interaction surprise est celle qui blesse quelqu’un ou fait échouer la mission, donc elle doit être trouvée avant l’exploitation en direct. Apportez votre approche de modélisation du tout (simulation, analyse de risque structurée, un modèle SysML qui capture les interactions) et demandez quels comportements inter-sous-systèmes vous avez réellement explorés contre supposés. La bonne émergence est souvent le but du système et mérite d’être conçue vers ; la mauvaise émergence est l’échec contre lequel vous devez concevoir. Si votre seule stratégie d’intégration est de câbler les parties ensemble et voir ce qui se passe, vous planifiez de découvrir l’émergence en production.
Quand les décisions matérielles à long délai doivent-elles être gelées, et comment cette échéance pilote-t-elle votre calendrier logiciel ? Quand un système inclut du matériel sur mesure, les deux doivent être co-conçus : la puce fixe le minutage, la mémoire, et les plafonds de puissance dans lesquels le logiciel vit, et les délais matériels dominent souvent le calendrier entier. Les équipes qui traitent le logiciel comme séparable optimisent localement puis entrent en collision avec les contraintes matérielles à l’intégration, perdant des mois. Apportez les délais matériels et la date à laquelle la division de fonction matériel/logiciel doit être décidée, et révisez cette division à mesure que les contraintes émergent plutôt que de la geler à l’aveugle. Plus tôt vous décidez quelles fonctions vivent dans le silicium et lesquelles dans le logiciel, moins vous affrontez de coûteux revirements. Les interfaces entre les deux méritent un document de contrôle d’interface et un propriétaire de chaque côté, parce qu’un changement tardif là se répercute à travers tout ce qui la touche.
Pouvez-vous tracer un seul besoin de partie prenante jusqu’à l’exigence, l’élément de conception, et le test qui le prouve, et qui garde ce lien vivant ? La traçabilité est ce qui vous permet de montrer à tout moment que chaque besoin est couvert et que chaque partie existe pour une raison, pourtant sur un grand programme la matrice pourrit à l’instant où personne ne la possède. La tension concurrente est réelle : les ingénieurs vivent la traçabilité comme une surcharge bureaucratique, et une matrice maintenue à la main dérive vers l’obsolescence plus vite que la conception ne change. Apportez un vrai fil d’un programme actuel et essayez de le parcourir de bout en bout dans la pièce, depuis un besoin de partie prenante nommé, jusqu’à l’exigence allouée, jusqu’au sous-système et élément de conception qui la satisfait, jusqu’au test de vérification, et notez où la chaîne se brise. Décidez qui possède la matrice et si elle devrait vivre dans un modèle où la traçabilité est une requête plutôt qu’une chasse manuelle. Pour les programmes d’entreprise et gouvernementaux, la matrice est aussi l’artefact d’audit que les régulateurs et autorités d’acquisition exigent, donc une chaîne brisée fait plus que ralentir l’ingénierie ; elle peut bloquer la certification ou le paiement.
Une approche fondée sur les modèles vaut-elle son coût d’outillage et de culture pour vous, ou deviendrait-elle une étagère coûteuse ? L’ingénierie des systèmes fondée sur les documents est familière et bon marché à outiller, mais ses documents dérivent hors synchronisation et sa traçabilité est manuelle et sujette aux erreurs ; la MBSE remplace le tas par un modèle connecté unique, au prix de l’outillage, de la formation, et d’un vrai changement de culture. Chaque extrême est coûteux : sautez la MBSE sur un grand programme multi-disciplinaire et vous payez en surprises d’intégration, adoptez-la sans la discipline de garder le modèle à jour et elle pourrit en étagère pire qu’aucun modèle du tout. Apportez une lecture honnête de la maturité de votre outillage, qui dans l’équipe peut réellement rédiger et maintenir un modèle SysML, et quel sous-système unique à haut risque pourrait piloter l’approche où un modèle partagé rapporte le plus vite. Décidez graduellement plutôt que de mandater toute l’organisation d’un coup. Pour une grande entreprise ou un programme gouvernemental avec de nombreux fournisseurs, pesez si un modèle partagé est le seul moyen réaliste de garder les exigences, interfaces, et tests cohérents à travers des contractants qui échangent autrement des documents obsolètes.
Votre plan de cycle de vie finance-t-il sérieusement l’exploitation et la retraite, ou s’arrête-t-il discrètement au lancement ? Les étapes qui dominent le coût total d’un système de longue durée, l’exploiter pendant des décennies et le mettre hors service en sécurité, sont celles que les plans précoces ignorent couramment, parce que la pression est toujours de livrer. La considération concurrente est que l’argent et l’attention sont les plus rares exactement quand ces étapes ultérieures semblent les plus lointaines, donc l’exploitation, la maintenance, la migration de données, et l’élimination sont différées jusqu’à devenir une ruée coûteuse et risquée. Apportez le plan de cycle de vie actuel et vérifiez s’il nomme des propriétaires, des budgets, et des critères de sortie pour l’exploitation et la retraite, ou s’il traite le lancement comme la ligne d’arrivée. Demandez ce qui arrive aux données et au matériel en fin de vie, et qui paie pour les années de maintenance entre les deux. Pour les systèmes d’entreprise et gouvernementaux qui doivent fonctionner pendant vingt ou trente ans puis se retirer sous examen public, une mise hors service non planifiée peut violer des obligations réglementaires, environnementales, ou de rétention d’enregistrements, donc la retraite appartient au plan et au budget dès la première revue de concept.

Regard sectoriel

Jeune pousse. Une toute petite équipe ne peut pas exécuter un programme formel d’ingénierie des systèmes et ne devrait pas essayer, mais elle peut quand même traiter le firmware, l’application, et le cloud comme un système au lieu de trois projets séparés. Écrivez un court document d’interface qui fixe comment les parties se parlent, gardez une table simple liant chaque besoin client à la partie qui le satisfait, et sautez le processus lourd. Votre ressource la plus rare est l’attention d’ingénierie, donc dépensez l’effort de traçabilité seulement là où une mauvaise supposition à une frontière casserait discrètement le produit sur le terrain.

Petite entreprise. Sans ingénieur système dédié et avec un budget serré, appuyez-vous sur des normes publiées et des sous-systèmes achetés plutôt qu’une intégration sur mesure que vous devez concevoir et vérifier vous-même. Favorisez les fournisseurs qui exposent des spécifications d’interface claires pour que les parties s’assemblent sans un connecteur personnalisé que vous devez posséder pour toujours. Cadrez le choix construire-contre-acheter autour de quelles interfaces vous pouvez réalistement contrôler et vérifier sur la vie du produit, et achetez le reste.

Grande entreprise. À l’échelle, le problème est la cohérence à travers de nombreuses équipes et fournisseurs : un processus de cycle de vie partagé aligné sur l’ISO/CEI/IEEE 15288, un document de contrôle d’interface et un propriétaire nommé pour chaque frontière de fournisseur, et une traçabilité de bout en bout pour qu’un changement de composant ne déclenche pas une ruée à l’échelle du programme. Investissez dans la MBSE là où un modèle partagé garde les exigences, interfaces, et tests alignés à travers les contractants. Gouvernez le processus pour que la vérification et la validation restent distinctes et que chaque exigence soit allouée à une partie responsable.

Gouvernement. Les règles d’approvisionnement, la transparence, et la redevabilité publique façonnent chaque choix. Spécifiez le processus d’ingénierie des systèmes, la traçabilité, et la preuve de V&V dans le contrat, exigez que les fournisseurs livrent des documents de contrôle d’interface et des artefacts de cycle de vie que vous pouvez auditer, et réservez la validation de sécurité et de mission à une revue indépendante avec de vrais opérateurs avant toute bascule en direct. Planifiez et financez explicitement l’exploitation et la retraite, parce qu’un programme public est redevable pour le cycle de vie complet, incluant la mise hors service sûre et la rétention d’enregistrements.

Exemples

Jeune pousse. Une start-up matérielle de quatre personnes construisant un capteur connecté ne peut pas se permettre un programme formel d’ingénierie des systèmes, mais elle traite quand même le produit comme un système unique de firmware, d’une application mobile, et d’un backend cloud plutôt que trois projets séparés. Elle écrit un court document d’interface qui fixe comment le dispositif, l’application, et le serveur se parlent (formats de message, unités, codes d’erreur) et garde une table simple liant chaque besoin client à la partie qui le satisfait. Quand une puce de capteur moins chère force un changement de firmware, cette interface partagée montre immédiatement ce que l’application et le backend doivent ajuster, si bien qu’un échange de composant ne casse pas discrètement le produit sur le terrain.

Grande entreprise. Un constructeur automobile mondial construit une nouvelle plateforme de véhicule électrique : un système de logiciel (gestion de batterie, aide à la conduite, infodivertissement), de matériel (moteurs, capteurs, puces), et de facteurs humains, plus de nombreux fournisseurs livrant chacun des sous-systèmes. L’entreprise exécute un programme d’ingénierie des systèmes. Les besoins des parties prenantes alimentent des exigences allouées, chaque interface fournisseur a un document de contrôle d’interface, et un modèle SysML lie les exigences à la conception aux tests. Quand un fournisseur de cellules de batterie change un composant, le modèle de traçabilité montre exactement quelles exigences, interfaces, et tests sont affectés, si bien que le changement est contenu au lieu de déclencher une ruée à l’échelle du programme.

Gouvernement. Une autorité nationale de navigation aérienne modernise son système de gestion du trafic aérien, un système de systèmes critique pour la sécurité couvrant des radars, des postes de travail de contrôleur, des communications, et du logiciel, exploité en continu. Le programme suit l’ISO/CEI/IEEE 15288 à travers le cycle de vie complet. La vérification prouve que chaque sous-système satisfait sa spécification, et la validation par simulation avec de vrais contrôleurs prouve que le système intégré soutient des opérations sûres avant que tout trafic réel n’en dépende. Une V&V rigoureuse permet à l’autorité de basculer par étapes, avec un recul à chaque étape, parce qu’ici un échec émergent non testé est un événement de sécurité publique.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

La motivation est que les défauts deviennent exponentiellement plus coûteux plus tard vous les trouvez. Une erreur d’exigence attrapée pendant l’étape des exigences coûte presque rien à corriger. La même erreur attrapée en exploitation peut coûter des milliers de fois plus, et sur un système critique pour la sécurité elle peut coûter des vies, des rappels, ou une mission échouée. L’ingénierie des systèmes déplace la découverte de défaut vers les étapes précoces bon marché.

Pour le retour sur investissement (ROI, valeur gagnée comparée au coût dépensé), le gain est du retravail évité, moins d’échecs d’intégration, et des programmes qui respectent le calendrier et le budget au lieu de les dépasser. Les études industrielles de grands programmes trouvent systématiquement qu’un fort effort d’ingénierie des systèmes corrèle avec de plus petits dépassements. Pour le coût total de possession (CTP, le coût complet sur le cycle de vie de construire, exploiter, et retirer un système), l’ingénierie des systèmes prend en compte les étapes d’exploitation et de retraite qui dominent le coût de long terme mais que les projets ad hoc ignorent. Concevoir pour la maintenabilité, les interfaces, et l’élimination dès le départ abaisse le coût des décennies que le système passe en service. Voir la gestion de projet (chapitre 10.6).

Anti-patterns et pièges

Grande conception préalable sans itération. Traiter le cycle de vie comme une cascade rigide à sens unique, si bien que vous apprenez que les exigences étaient fausses seulement après avoir tout construit.
Exigences sans traçabilité. Un tas d’exigences que personne ne lie à la conception ou aux tests, si bien que vous ne pouvez pas prouver la couverture ou justifier aucune partie.
Ignorer les interfaces. Supposer que les sous-systèmes s’assembleront simplement, puis perdre des mois à l’intégration à cause d’inadéquations de frontière que personne ne possédait.
Vérification sans validation. Prouver que le système satisfait sa spécification sans jamais vérifier que la spécification correspondait aux vrais besoins, puis livrer le mauvais système.
Traiter le logiciel comme séparé. Des équipes logicielles optimisant localement tout en ignorant les contraintes matérielles, le minutage, et les opérateurs humains.
La MBSE comme étagère. Construire un modèle une fois, puis le laisser pourrir hors synchronisation pour qu’il devienne pire qu’aucun modèle.
Sauter la planification de retraite. Aucun plan pour la mise hors service, la migration de données, ou l’élimination, si bien que la fin de vie devient une ruée coûteuse et risquée.

Modèle de maturité

Niveau 1 (Initier). L’ingénierie des systèmes est ad hoc et réactive. Les exigences vivent dans des documents dispersés, les interfaces sont découvertes à l’intégration, et la vérification est quel que soit le test qui arrive à être fait. Les grands programmes dépassent régulièrement et surprennent l’équipe tard.

Niveau 2 (Développer). Des pratiques de base existent sur les programmes majeurs. Les exigences sont capturées et fixées, les interfaces clés ont des documents de contrôle, et il y a un plan de vérification. La pratique est incohérente entre équipes et dépend des individus plutôt que d’une méthode partagée.

Niveau 3 (Standardiser). L’ingénierie des systèmes est une discipline documentée et à l’échelle de l’organisation alignée sur l’ISO/CEI/IEEE 15288 et imposée à travers les équipes. Le cycle de vie complet est planifié, la traçabilité est maintenue de bout en bout, les interfaces sont formellement contrôlées, et la vérification et la validation sont distinctes et planifiées. La MBSE est utilisée sur les programmes complexes.

Niveau 4 (Gérer). L’ingénierie des systèmes est mesurée et contrôlée avec des données. L’organisation suit des métriques par rapport à des références : la volatilité des exigences et la couverture de traçabilité, les défauts d’interface trouvés à l’intégration, les taux de réussite de vérification et de validation, et la fuite de défaut par étape de cycle de vie (combien de défauts échappent à chaque étape pour être attrapés plus tard à coût plus élevé). Les revues pilotent les programmes sur ces chiffres, et des seuils déclenchent une action corrective plutôt qu’une lutte contre l’incendie après coup.

Niveau 5 (Orchestrer). L’ingénierie des systèmes est continuellement améliorée et intégrée à travers l’organisation. Un modèle MBSE vivant est la source unique de vérité, la traçabilité est automatisée, la simulation prédit le comportement émergent avant la construction, et les métriques des programmes passés alimentent le suivant. Le matériel et le logiciel sont co-conçus comme une question de routine, et le processus s’adapte à mesure que les programmes, fournisseurs, et risques changent.

Pistes de réflexion

Où se trouve la ligne entre l’ingénierie des systèmes et l’architecture logicielle dans votre organisation, et qui possède l’espace entre les deux ?
Sur votre plus grand programme, pouvez-vous tracer un seul besoin de partie prenante jusqu’au test qui le vérifie ? Sinon, que faudrait-il ?
Lesquels de vos échecs récents se sont produits à une interface, et qui la possédait ?
La MBSE rapporterait-elle pour vous, ou deviendrait-elle une étagère coûteuse étant donné votre culture et votre outillage ?
Votre plan de cycle de vie adresse-t-il sérieusement l’exploitation et la retraite, ou s’arrête-t-il discrètement au lancement ?

Points clés à retenir

L’ingénierie des systèmes conçoit le système entier (logiciel, matériel, personnes, et processus) de bout en bout, et est distincte de l’architecture logicielle.
Planifiez le cycle de vie complet, du concept aux exigences, à la conception, à l’intégration, à la V&V, à l’exploitation, et à la retraite.
Tracez chaque besoin à une exigence, un élément de conception, et un test, et allouez chaque exigence à une partie responsable.
Gérez les interfaces explicitement avec une propriété claire et des documents de contrôle, parce que les frontières sont là où les systèmes se cassent.
La vérification (bien construit) et la validation (bonne chose construite) sont des vérifications différentes, et vous avez besoin des deux.
Utilisez la MBSE et SysML pour une source de vérité connectée unique, et utilisez la pensée systémique pour anticiper le comportement émergent.
Assortissez le poids de votre processus à la taille, la durée de vie, et le risque du système.

Références et lectures complémentaires

INCOSE, INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
ISO/CEI/IEEE 15288, Systems and Software Engineering: System Life Cycle Processes
ISO/CEI/IEEE 29148, Systems and Software Engineering: Requirements Engineering
Sanford Friedenthal, Alan Moore, et Rick Steiner, A Practical Guide to SysML: The Systems Modeling Language
NASA, NASA Systems Engineering Handbook (NASA/SP-2016-6105)
Andrew P. Sage et William B. Rouse, Handbook of Systems Engineering and Management
Dennis M. Buede et William D. Miller, The Engineering Design of Systems: Models and Methods
Donella H. Meadows, Thinking in Systems: A Primer
Eberhardt Rechtin et Mark W. Maier, The Art of Systems Architecting
U.S. Department of Defense, Defense Acquisition Guidebook (guidance d’ingénierie des systèmes)