Exigences et ingénierie système : Mise en œuvre avec SysML
Introduction
Pour mener à bien des projets de développement de systèmes complexes, c'est-à-dire de systèmes composés récursivement de sous-systèmes en interaction, l’ingénierie système propose des méthodes basées sur la gestion des exigences.
La gestion des exigences et l’architecture système sont parfois vues comme deux disciplines distinctes. Néanmoins, le fil conducteur assurant la traçabilité entre les exigences, depuis les expressions de besoin des clients (ou des équipes marketing) jusqu’aux exigences transmises aux fournisseurs, passe par l’architecture, ses choix et ses justifications.
L’objet de cet article est de résumer l’état de l’art des pratiques d’ingénierie système permettant d’articuler la gestion des exigences avec les travaux d’architecture lorsque ceux-ci mettent en œuvre des modèles, en particulier des modèles SysML [3].
L’article vise d’abord, pour chacun des processus technique de développement [1],[2], à rappeler les activités se rapportant aux exigences. Il illustre leur mise en œuvre dans le cadre d’une démarche que nous proposons pour accompagner les développements effectués avec SysML. Ensuite, il aborde les problématiques d’outillage des ateliers système.
Références
[1] ANSI/EIA 632, janvier 1999
[2] ISO 15288, novembre 2003
[3] SyML: Standard OMG (Object Management Group) V1.0, 19 septembre 2007 (www.omg.org)
[4] ISO 10303 / AP233, novembre 2007
Concepts et problématiques
Cet article se réfère à des concepts d’ingénierie système dont nous présentons ici notre interprétation. La définition de ces concepts donnant souvent lieu à des débats d’experts qui ne manquent pas d’animation, nous n’avons pas la prétention de fournir ici des définitions standardisées mais seulement notre compréhension.
Systèmes complexes
Ensembles d’éléments structurés interagissant avec leur environnement et développés par sous-systèmes :
■ interagissant et coopérant entre eux pour rendre les services attendus du système global ;
■ réalisables industriellement ;
■ développés récursivement, souvent sur plusieurs niveaux, jusqu’aux constituants dont l’ingénierie relève de spécialités « métier ».
Ingénierie Système
Démarche d’ingénierie propre au développement des systèmes complexes dont l’objet est de fédérer des compétences diverses dans une approche pluridisciplinaire :
■ pour concevoir des solutions résolvant des problèmes industriels et, autant que possible, vérifiées sur des exemplaires de préséries avant la mise en production ;
■ impliquant un grand nombre de partie prenantes (montages financiers, impacts sur l’environnement, expertises technologiques…) ;
■ basée sur un cycle de vie impliquant des chaînes récursives de relations de type « client-fournisseur » (voir Figure 1).
Exigence
Enoncé prescriptif.
Exigence technique
Enoncé auquel le système doit être conforme et dont la conformité est vérifiable (par Inspection, Analyse, Test, Démonstration : méthodes de vérification dites « IADT »).
Une exigence possède :
■ un cycle de vie caractérisé par des états (exemples : identifiée, validée, enregistrée, vérifiée…) ;
■ des attributs (exemples: priorité, criticité, probabilité d’évolution…).
■ Les exigences permettent :
■ de savoir ce qui est à faire ;
■ de s’assurer que la base des développements est possible, cohérente et non-contradictoire ;
■ de négocier avec son client et ses partenaires ;
■ de vérifier que l’on a fait ce qui est attendu ;
■ de réutiliser : réutiliser des spécifications ou ces constituants déjà développés n’est possible que si on est en mesure de connaître les exigences qu’ils satisfont.
Exigence initiale
Exigence technique exprimée selon un point vue d’utilisateur, en rapport avec le système vu comme une boîte noire ou avec ses interfaces externes. La conformité est vérifiée (validation) dans un contexte opérationnel effectif. Les exigences initiales sont aussi appelées exigences clients et autres parties prenantes [1],[2]. Elles sont aussi appelées parfois aussi exigences de besoin.
Exigence système
Exigence technique exprimée selon un point vue de concepteur, mais toujours en rapport avec le système vu comme une boîte noire ou avec ses interfaces externes. La conformité est vérifiée (vérification) en interne (tests sur bancs, analyses …).
Exigence spécifiée
Exigence technique exprimée à l’issue de travaux d’architecture se rapportant aux constituants du système ou à ses interfaces internes. Les exigences spécifiées d’un niveau d’ingénierie n tiennent le rôle d’exigences initiales pour le niveau n+1. La conformité est vérifiée lors de l’acceptation des composants et par les tests d’intégration.
Remarque additionnelle : Exigences et cycle de vie des systèmes
C’est au cours du développement que sont définies, non seulement les exigences opérationnelles, mais les exigences portant sur l’ensemble des phases cycle de vie. D’où la nécessité de faire intervenir le plus en amont possible des experts métier des autres phases : production, logistique, support, exploitation, maintenance, retrait…).
Figure 1 : relations client/fournisseurs en ingénierie système
Figure 2 : exigences et processus techniques d’ingénierie système
Les exigences dans les processus techniques de développement
Chacun des processus de développement donne lieu à la production d’exigences et de liens de traçabilité : liens entre des exigences (dérivation*) ou liens entre des exigences et d’autres données d’ingénierie (allocation*). L’objet de ce chapitre est de présenter très synthétiquement comment les exigences sont mises en jeu dans ces processus.
Pour chacun des processus, nous rappelons sa finalité, les principales activités relatives aux exigences et l’apport de SysML à ces activités.
* Les termes de dérivation (entre exigences) et d’allocation (entre données d’ingénierie de types différents) font aujourd’hui l’objet d’un consensus entériné par SysML.
Définition des exigences
Finalité du processus : comprendre les besoins initiaux et les exprimer sous forme d’exigences « initiales » vérifiables dans des conditions opérationnelles (validation). Ces exigences ont vocation à être partagées avec le client et, pour certaines d’entre elles, avec d’autres parties prenantes.
Activités « exigences » : identifier, rédiger et enregistrer les exigences initiales.
Pour faciliter l’expression des exigences fonctionnelles, nombre de méthodes recommandent de décrire et d’analyser, d’un point du vue utilisateur, des scénarios opérationnels mettant en jeu le système dans son contexte de fonctionnement.
Démarche avec SysML : les scénarios opérationnels partageant les même pre-conditions sont organisés en cas d’utilisation. Les exigences communes à tous les scénarios d’un même cas d’utilisation sont allouées explicitement au cas d’utilisation. Par transitivité, elles sont implicitement allouées aux scénarios.
Analyse des exigences
Finalité du processus : disposer d’une base d’exigences système détaillées, quantifiées et vérifiables en interne, sur laquelle baser les travaux de conception et par rapport à laquelle vérifier la (les) solution(s) d’architecture retenue(s).
Activités « exigences » : identifier, rédiger et enregistrer les exigences « système ».
L’expression des exigences fonctionnelles est facilitée par une étude approfondie des scénarios opérationnels, effectuée ici d’un point de vue de concepteur. Le but de l’étude est d’identifier les fonctions système de haut niveau mises en jeu par les scénarios et les exigences détaillées associées aux fonctions, dérivées des exigences initiales.
Démarche avec SysML : les scénarios opérationnels sont illustrés par des diagrammes de séquence explicitant les échanges (matière, énergie, information) entre le système et son contexte. Ceux-ci facilitent :
■ d’une part, la recherche des exigences d’interfaces externes ;
■ d’autre part, l’identification des fonctions système utilisant les entrées et/ou élaborant les sorties.
Figure 3 : définition et analyse des exigences (modélisation SysML)
Architecture logique
Finalité du processus : définir vue de l’organisation du système en constituants logiques, indépendante des technologies de réalisation et valide quelles que puissent être ces technologies.
Activités « exigences » : identifier, rédiger et enregistrer les exigences « spécifiées » allouées aux constituants logiques et donc indépendantes des technologies. Elles comprennent les exigences se rapportant aux fonctions (quels résultats obtenus, avec quelles performances, dans quelles conditions opérationnelles).
Deux types de pratiques sont souvent mises en œuvre conjointement ; il s’agit de pratiques :
■ d’architecture fonctionnelle : visant à décomposer les fonctions de plus haut niveau en fonctions de complexité décroissante et, en parallèle, à formaliser les exigences allouées aux fonctions en les dérivant des exigences système ;
■ des pratiques d’architecture modulaire : visant à regrouper les fonctions en constituants « logiques » minimisant les dépendances inter-constituants et optimisant les circuits des échanges internes.
Démarche avec SysML : les fonctions sont regroupées par blocs (constituants) logiques. Ceux-ci présentent l’avantage de permettre la définition les paramètres numériques manipulés par les fonctions et des types des échanges transitant par les interfaces. Un modèle décrivant une architecture logique et les exigences allouées à ses éléments peuvent ainsi être employés :
■ comme référence de spécification lorsque plusieurs solutions technologiques sont envisagées, ou qu’elles évoluent au cours du temps ;
■ à des fins de réutilisation, au moins partielle, par des projets partageant des problématiques fonctionnelles semblables ;
■ comme référence de spéciation partagée par l’ensemble des produits d’une même gamme.
Figure 4 : architecture logique (modélisation SysML)
Architecture physique
Finalité du processus : définir, selon les solutions technologiques retenues, une vue de l’organisation du système en constituants physiques. Cette vue a pour objet de préparer l’intégration du système et aussi de préparer la communication d’éléments techniques complémentaire aux exigences spécifiées.
Activités « exigences » : identifier, rédiger et enregistrer les exigences « spécifiées » dépendantes des technologies de réalisation retenues.
Démarche avec SysML : les blocs logiques et les exigences qui leur sont allouées sont projetés sur des bocs physiques (composants physiques) et les exigences induites par les solutions technologiques sont exprimées. Les blocs physiques et l’ensemble des exigences « spécifiées » spécifient ainsi les attendus des constituants concrets qui pourront être développés à leur tour, réutilisés, ou acquis « sur étagère ».
En outre, les modèles SysML peuvent être utilisés conjointement avec des modèles non SysML (modèles de simulation, modèles CAD/CAM). Dans ce cas, le modèle SysML est la référence de la définition des contraintes et des paramètres partagés avec les autres modèles. Les exigences à prendre en compte sont celles allouées aux éléments du modèle SysML.
Figure 5 : architecture physique (modélisation SysML)
Intégration, Vérification, Validation
Finalité des processus :
■ Intégration : recetter les exemplaires des composants physiques, procéder à l’intégration et vérifier la conformité des interfaces internes avec leurs exigences ;
■ Vérification : vérifier la conformité du système par rapport aux exigences système ;
■ Validation : vérifier la conformité du système par rapport aux exigences initiales.
Démarche avec SysML : SysML entérine une démarche désormais communément adoptée visant à tracer chaque procédure de test avec les exigences qu’elle vérifie.
Considérations « ateliers »
Référentiel d’exigences
Les outils de modélisation SysML permettent la saisie et la gestion des exigences et des liens de traçabilité dans les modèles. Ceci est très pratique pour les ingénieurs disposant d’un modeleur UML comme outil de travail. Néanmoins, des profils n’ayant lieu de modéliser avec SysML peuvent aussi avoir à traiter des exigences (experts métier, sûreté de fonctionnement, équipes de test, ….) C’est pourquoi des modèles peuvent difficilement tenir lieu de référentiels d’exigences et de traçabilité
En revanche, ils peuvent être tout à fait être utilisés comme outil de saisie des analystes et concepteurs SysML, ces derniers ayant à exporter leurs exigences et à synchroniser leurs modèles par rapport à référentiel projet dédié à la gestion des exigences.
Les gestionnaires d’exigences disponibles sur le marché proviennent de deux domaines différents : les premiers viennent du monde du logiciel (par exemple Requisite Pro d’IBM/Rational ou DOORS de Telelogic) et les seconds, arrivés plus tard sur le marché, du monde des PDM/PML (par exemple SMARTEAM CSE de Dassault Systèmes ou Teamcenter d’UGS.
Gestion de configuration
Il est nécessaire de gérer les exigences et les liens de traçabilité en configuration avec l’ensemble des autres données d’ingénierie, y compris celles gérées par les modèles. C’est au prix d’une gestion de configuration instaurée dès le début d’un projet d’ingénierie système que sera garantie le versionnement cohérents des données des différents référentiels.
Ceci implique d’enregistrer des baselines progressives au fur et à mesure de l’avancement du projet. En contrepartie, la gestion du projet et les différentes évaluations de jalon sont significativement facilitées. Elle rend possible par exemple, au cours d’une analyse de compromis, l’accès à la fois à la vue partagée avec le client, à celles partagées avec les fournisseurs et à la vue courante interne.
Ingénierie système et bureaux d’études
On peut regretter que, jusqu’à présent, l’ingénierie système ne proposait ni méthodes, ni d’outils de collaboration entre équipes de spécialités différentes pour la mise en œuvre concrète de ses processus. Par exemple, l’ingénierie système nous montrera difficilement l’avant et l’arrière d’un système. Les concepts seront sans doute évoqués dans des fonctions ”avancer” et ”reculer”, mais ce n’est pas l’ingénierie système qui en fournira une représentation. Elle ne fournira pas davantage les plans de montage pourtant nécessaires à l’intégration.
SysML [3], nous l’avons vu, permet désormais le partage de données avec d’autres modèles et, entre autres, avec les modèles CAD/CAM. Par ailleurs, les protocoles d’application STEP XXX) définissant les protocoles d’échange entre données industrielles traitent désormais les données spécifiques de l’ingénierie système (AP233). La combinaison des 2 standards permet maintenant d’envisager dans les prochaines années une collaboration outillée effective entre ingénieurs « système » et ceux des bureaux d’étude. Des travaux de conception de tels ateliers sont actuellement en cours aux Etats-Unis, à l’instigation et avec le support de la NASA.
En conclusion
Les processus d’ingénierie système ont été développés initialement pour rationnaliser les processus d’acquisition de grands donneurs d’ordre (DOD, NASA).
Ils sont maintenant adoptés par toutes sortes d’entreprises, même par des fournisseurs de rang supérieur à 2, pour faciliter le traitement de la complexité croissante des projets. En même temps, celles-ci se munissent d’outils qui rendent obsolète une gestion intégralement documentaire des produits de processus.
D’où la nécessité de standards permettant une gestion non plus documentaire, mais orientée sur des données structurées et des modèles.
Si le sujet vous intéresse, merci de contacter Alexandre Loire (loire@galia.com) afin d’envisager les suites à donner à cet article.
Françoise Caron - EIRIS Conseil
Les dossiers
GALIA - Groupement pour l'Amélioration des Liaisons dans l'Industrie Automobile