Services proposés
En voici quelques uns qui nous paraissent déterminants suite à notre expérience auprès de différents industriels:
- But et périmètre de la modélisation: s’agit-il de définir des concepts (modèles conceptuels)? d’illustrer des exigences (modèles descriptifs)? de spécifier des exigences (modèles prescriptifs)?
- Sans stratégie claire, le risque est grand de mélanger ces différents buts et consacrer au final beaucoup d’efforts pour des résultats mitigés.
- Conseil: Définissez les retours que vous attendez du modèle (aide à la validation des exigences, aide à l’écriture des exigences, aide à la définition d’architecture…) et la pérennité du modèle (moyen intermédiaire jetable ou artefact de référence de l’ingénierie)
- Analyse et partage des pratiques d’ingénierie de systèmes: est-ce que les termes, concepts et activités des processus d’ingénierie des systèmes sont claires et connues de tous?
- Dans MBSE il y a d’abord SE. Tenter de construire une approche de modélisation unifiée sur des pratiques hétérogènes est vouée à l’échec.
- Conseil: Prenez d’abord le temps de vérifier que les notions fondamentales de l’IS sont bien partagées: exigence, fonction, mode, scénario, architecture logique/physique…, et que les activités sont bien décrites pour les différents processus, notamment techniques (ISO15288:2015), puis identifiez le langage existant (standard si possible) le plus adapté pour formaliser ces éléments: SysML, Capella, Simulink, Core,… et enfin spécialisez ce langage pour les besoins de votre domaine/entreprise/projet.
- Approche pragmatique liée aux caractéristiques du projet: utiliserez-vous la même approche pour la définition d’un tout nouveau système et l’ajout d’une fonction dans une ligne de produit? pour un système critique embarqué ou un système d’information?
- Si l’approche proposée est trop rigide, elle risque de « crisper » l’équipe qui ne verra pas les bénéfices et considérera ce changement comme une contrainte forte.
- Conseil: laissez des degrés de liberté, notamment entre une approche descendante qui part de l’analyse des besoins et une approche montante qui fonctionne par assemblage de composants. La vérité est toujours un mélange entre ces 2 approches, mais avec des poids qui diffèrent selon le contexte, la phase du projet et les attentes de l’équipe.
- Identification des gains et quantification: savez-vous dire ce que l’approche de modélisation va faire économiser au projet et à quelle échéance?
- Cet aspect est très important car il y aura des responsables pour demander des comptes. Ignorer cette demande, c’est ignorer le sponsor de l’approche et hypothéquer l’avenir de la modélisation.
- Conseil: définissez une stratégie de modélisation avec des objectifs de gains clairs par rapport à une approche sans modélisation sur chaque phase et processus du projet. Une fois les gains bien ciblés, il s’agira de voir comment les atteindre et cela peut demander des adaptations de la méthode (et donc des formations, coaching) et de l’outillage. Il faut donc anticiper ces efforts au plus vite. En parallèle, il s’agira de raffiner les gains, d’abord de façon qualitative, puis quantitative via des métriques sur le temps de validation, d’analyse d’erreurs, le nombre d’itérations sur la maturation d’exigences… ces chiffres, combinés à ceux des efforts, permettront de conclure sur l’intérêt de la modélisation et vous donneront de la crédibilité.
Vous pouvez consulter la présentation ICSSEA 2016 conference – MBSE tutorial: gradual modeling approach to support development of complex systems pour vous faire une idée concrète des bénéfices retirés par des industriels à partir d’une approche basée modèle (approche qui repose sur le standard d’ingénierie des systèmes ISO 15288:2015).
<< accès au catalogue de formations >>
Nous sommes certifiés QUALIOPI depuis le 5 mai 2021. Notre certificat est disponible ici: Certificat QUALIOPI
Coaching
La formation est un bon moyen pour partager la connaissance et la pratique d’un outil mais il s’avère que ce n’est pas toujours la meilleure solution à cause des raisons suivantes: mauvaise période (les sessions de formation, planifiées à l’avance, arrivent parfois trop tôt ou trop tard par rapport aux démarrages des projets), disponibilité limitée des participants, manque d’expérience en cadre opérationnel (les questions clef arrivent trop tard souvent bien après la formation, quand l’expert n’est plus présent…)
Pour toutes ces raisons, il est utile et parfois plus efficace d’envisager un support par de l’accompagnement projet (coaching) et des réunions régulières. Nous avons cette expérience et pouvons fournir un expert en modélisation directement impliqué dans les équipes opérationnelles. Au début c’est l’expert qui prendra en charge le modèle pour avoir des résultats rapidement sur la complétude et la cohérence du système.
Ensuite, l’étape suivante consiste à travailler à deux (pair modelling) avec quelques membres de l’équipe destinées à devenir des référents sur la modélisation. Quand les référents sont autonomes, l’expert en modélisation limite son intervention à du support « deuxième niveau » et revient voir l’équipe projet une fois par semaine (ou moins) pour répondre aux questions avancées et proposer des règles et canevas de modélisation.
Nous vous accompagnons dans le choix du langage de modélisation le mieux adapté à votre contexte.
Concernant l’ingénierie des systèmes, OMG SysML est un bon candidat mais ce langage reste très généraliste et nécessite une adaptation de façon à correspondre au vocabulaire et aux standards spécifiques des domaines. Par exemple SysML ne comporte pas nativement le concept de « Fonction » qui est un concept fondamental lorsqu’on traite des systèmes sûrs de fonctionnement (ARP4754A/ARP4761, DO178C). Nous vous aidons à détailler tous les concepts nécessaires pour vos processus d’ingénierie de systèmes et quels sont ceux qui peuvent être modélisés par SysML ou qui nécessitent une extension du langage (via un profil).
Méthode SAMAREQ: si vous souhaitez démarrer rapidement et ne savez pas trop par où commencer, nous pouvons vous donner accès à la méthode SAMAREQ (
Samares Approach for Modelling of Architecture and REQuirements) définie par Samares Engineering.
Voici une illustration de cette méthode:
Ci-dessous 2 présentations à propos de la méthode SAMAREQ.
La première montre l’identification des exigences système en cours de modélisation grâce au mode « live »: Catia NMEC 2019 (Hambourg) – Specification development during modelling
Les 2 vidéos qui suivent correpondent aux démonstrations faites à la conférence Catia NMEC 2019 et illustrent la méthodologie SAMAREQ dans le contexte d’un drone d’inspection avion.
La deuxième présentation présente la motivation et les détails de la méthode SAMAREQ: No Magic European Conference 2018 – Building Good Quality Functional Specification Model
Lorsque les concepts dont vous avez besoin sont trop éloignés du langage SysML, nous vous aidons à définir votre propre langage de modélisation (méta modèle) et nous pouvons construire rapidement un prototype montrant l’utilisation de ce langage.
N’hésitez pas à nous contacter si vous êtes intéressé(e).
Lorsqu’une entreprise n’a pas défini d’outillage « corporate » pour la modélisation ou souhaite étudier des alternatives, nous pouvons vous aider à choisir l’outil le mieux approprié à votre contexte car nous avons une bonne expérience avec beaucoup d’outils de modélisation. Notamment les outils SysML (commerciaux ou open source)…
- MagicDraw/Cameo System Modeler (NoMagics) ,
- Enterprise Architect(Sparx Systems ),
- Rhapsody (IBM),
- Rational Software Architect (IBM),
- Papyrus (Eclipse foundation),
- Modelio (ModelioSoft),
- PTC Integrity Modeler (PTC/Atego).
… mais aussi d’autres outils basés sur un autre modèle de données:
- Capella (PolarSys) ,
- arKItect SEA (Knowledge Inside),
- Core (Vitech),
D’un point de vue pratique, nous définissons avec vous les critères clef d’évaluation correspondant à vos besoins prioritaires en terme de modélisation et nous effectuons l’évaluation des outils avec des scores de 0 à 2 pour chaque critère. C’est votre entreprise qui fixe le poids de chaque critère et cela permet d’avoir une note globale donnant un caractère formel à l’évaluation.
Nous vous aidons à définir et construire votre propre plateforme de modélisation à partir d’un langage de modélisation que vous avez défini ou d’un langage existant (OMG SysML, Capella, arKItect…): personnalisation de la plateforme avec création de scripts ou plugins, prototypage, évaluation de technologies complémentaires, tests d’intégration…
Vous pouvez consulter ci après la publication ERTS 2014 Efficient modelling of avionics systems: combining standard language and custom editor pour vous faire une idée du travail réalisé avec Airbus sur la mise en place d’un outil de définition d’architecture fonctionnelle basé sur une personnalisation de l’outil SysML Eclipse Papyrus.
Voici aussi ci-dessous la définition d’une plateforme basée « modèle » faite sur la base d’un langage dédié et avec des technologies Eclipse (EMF, Sirius):
Recommandations
Raphael Faudou (Samares Engineering) was a key contributor in the architecture definition of several MBSE projects for Airbus Engineering.
He has a deep knowledge of SysML language, Model Driven Development, and works with a good methodology – Mars 2015 –
Raphael Faudou has been working in my Systems Engineering teams in the frame of a large avionics development. He’s been coaching efficiently Systems Engineers to apply a Model-Based Systems Engineering methodology he has contributed largely to edit.
He is not only a bright engineer but also someone able to listen and adapt.
I fully recommends his skills as coach – Mars 2015 –
Raphael Faudou (Samares Engineering) did a real good job in training and supporting our system engineers on modelling practices. He has a true experience in system engineering with efficient analysis capabilities : his modelling domain deep knowledge (methods and tools) allows him to propose adapted solutions for industrial projects.
I fully recommends his skills as coach – Mars 2015 –