Système et ingénierie système
La littérature compose avec une multitude de définitions de la notion de système. L’INCOSE (International Council on Systems Engineering) définit un système comme « une construction ou une collection d’éléments qui, une fois assemblés, produisent des résultats dont l’obtention ne peut être obtenue par les éléments seuls » [53]. Meinadier [68] définit un système comme « un ensemble composite de personnels, de matériels et de logiciels organisé pour que leur interfonctionnement permette, dans un environnement donné, de remplir les missions pour lesquelles il a été conçu».
Ces définitions expriment plusieurs aspects caractérisant un système.
Le développement d’un système ou la modification d’un système existant est motivé par l’expression de besoins mal ou non satisfaits. L’objectif fondamental d’un système est de répondre à ces besoins, dans un contexte contraint par l’environnement, les ressources disponibles et les législations. Un système est complexe, il ne se réduit pas à la somme de ses constituants, mais il se définit également par leurs interactions. La nature de ces constituants est hétérogène : humains, physiques, logiciels, procédures de travail, etc. Il est par ailleurs qualifié de sociotechnique car il existe de fortes interactions entre les composants techniques, humains et environnementaux [18]. L’environnement dans lequel est inclus le système influence son comportement tout au long de sa vie. Il est caractérisé par ses propriétés, ses règles et ses contraintes opérationnelles et organisationnelles.
Il peut constituer une sous-partie d’un ensemble de systèmes. Il interopère alors avec d’autres systèmes extérieurs à l’aide d’interfaces. On parle alors de système de systèmes [16, 53].
L’ingénierie système est la discipline responsable de la production d’un système qui doit être apte à répondre aux besoins exprimés, en tenant compte des contraintes existantes (coût, délais etc.). L’INCOSE définit l’ingénierie système comme « la discipline de l’ingénierie responsable de la création et de la réalisation de processus interdisciplinaires garantissant la satisfaction des besoins du client et des parties prenantes d’une manière à assurer la qualité, la confiance, la gestion financière dans le respect des délais tout au long du cycle de vie du projet »[53]. Le Département américain de la Défense [39] définit quant à lui l’ingénierie système comme une discipline mettant en œuvre « les processus de gestion et de résolution de problèmes techniques appliquées durant l’ensemble des étapes de développement, afin de transformer les besoins et les exigences en un ensemble de descriptions de produits et de processus système (en ajoutant la valeur et le détail à chaque niveau de développement) ».
L’ingénierie système constitue ainsi une démarche méthodologique qui propose une approche holistique et pluridisciplinaire pour la conception et la mise en œuvre des systèmes complexes.
La production d’un système implique une multitude d’intervenants, autrement appelés parties prenantes. Une partie prenante désigne les personnes physiques et/ou les organisations morales concernées directement ou indirectement par le système [56]. La démarche d’ingénierie système intègre les contributions de toutes les disciplines impliquées dans l’ensemble du cycle de vie du système, en tenant compte des différents intérêts et exigences des parties prenantes impliquées [17]. On distingue deux catégories de parties prenantes [5]. Les parties prenantes intéressées représentent l’organisme qui émet le souhait d’acquérir et d’exploiter le système. Elles sont généralement les utilisatrices directes ou indirectes du système. Les parties prenantes conceptrices sont chargées de la réalisation du système, en réponse aux attentes des parties prenantes intéressées. Elles sont responsables de la bonne conduite du projet en vue de satisfaire la qualité, les délais et les coûts désirés par les parties prenantes intéressées. Plusieurs spécialités contribuent à la conception d’un système : les analystes, les experts des processus métiers, les experts du contrôle de la qualité, les architectes, les développeurs, les chefs de projet etc.
En définitive, l’ingénierie système est orientée vers deux perspectives complémentaires [5]. D’une part, elle se concentre sur la réalisation d’une solution technique qui répond à des besoins dans un cadre contraint ; on parle alors de «système à faire ». D’autre part, l’ingénierie système inclut l’ensemble des activités nécessaires pour produire le système à faire. Il s’agit par exemple de guider la réalisation par des procédés de gestion de projet. On parle alors de système pour faire.
Un système possède un cycle de vie
Un système rencontre une succession d’étapes qui rythme son cycle de vie. La norme ISO 15288 [3] définit un cycle de vie générique d’un système. D’autres cycles de vie davantage spécifiques à un domaine ou à une entreprise existent également, comme ceux de l’US Department of Defense (DoD) [39] ou celui de la NASA [47].
Conceptualisation Des besoins émergent dans un environnement. Des recherches exploratoires sont conduites afin d’évaluer l’opportunité de concevoir ou de modifier un système. La phase de conceptualisation construit l’espace du problème en définissant une première étude des besoins, d’exploration des idées et des technologies qui mènent à une étude de faisabilité et des propositions de solutions candidates.
Développement Une fois la décision actée de développer ou de modifier un système, la phase de développement œuvre à la spécification des exigences et la considération des contraintes du projet (technologique, structurelle, économique etc.). Les architectures système sont conçues, intégrées, vérifiées et validées. Cette phase garantit que le système conçu répond aux exigences des parties prenantes.
Production La phase de production définit l’ensemble des activités pour la construction et pour l’assemblage du système, en accord avec les spécifications établies. Des phases itératives de V&V (Vérification & Validation) sont conduites pour attester de la bonne qualité du système produit.
Utilisation Une fois produit, le système est mis en service opérationnel dans son environnement d’utilisation. Il est alors utilisé par les parties prenantes intéressées.
Support Le système peut être sujet à des dysfonctionnements entrainant des travaux de maintenance pour préserver une bonne condition opérationnelle. Il incombe aux concepteurs d’effectuer des mises à jour pour répondre à des nouvelles demandes ou corriger des aléas non détectés lors des phases précédentes. Le programme de support est généralement établi lors de la phase de développement [53]. D’autre part, un système de soutien logistique (Integrated Logistics Support – SLI) doit être apte à fournir les moyens matériels, humains et organisationnels pour permettre au système d’atteindre ses missions [114].
Retrait L’utilisation d’un système peut être suspendue après une certaine période d’utilisation pour diverses raisons. Il peut par exemple ne plus répondre aux demandes actuelles ou atteindre un point d’obsolescence technologique. Le système entre alors dans un période de retrait où le système doit être démantelé ou archivé.
La réalisation d’un système implique une multitude de parties prenantes. La division du cycle de vie d’un projet en étape facilite la répartition des parties prenantes. Par exemple, l’expression du besoin ou l’étude d’opportunité relève des parties prenantes intéressées, le développement ou le support relevant de la responsabilité des parties prenantes conceptrices. Par ailleurs, le cycle de vie d’un système structure l’organisation du projet en imposants des jalons à chaque fin d’étapes, offrant aux parties prenantes des points de visibilité sur l’état du projet [5]. La mise en œuvre pratique du cycle de vie d’un système a offert à la discipline plusieurs approches. On parle alors de modèles de cycle de vie. Les plus répandus sont le cycle en cascade [99], le cycle en V [36] et le cycle en spirale [15]. Ces modèles prescrivent l’ordonnancent et les jalons des activités des parties prenantes pour le développement de systèmes. Les modèles de cycle de vie déterminent l’enchaînement des étapes de cycle de vie d’un système.
Le cycle en cascade (Figure 1.3a) conduit à une réalisation séquentielle des activités d’analyse des besoins, de conception, de mise en œuvre, de vérification et de mise en service opérationnelle avec des retours possibles sur les activités précédentes pour chaque étape.
Le cycle en V propose une séparation du cycle de vie en deux branches (Figure 1.3b). La branche descendante inclut l’analyse des besoins, la spécification des exigences et la conception de l’architecture du système. La branche ascendante est constituée des phases d’intégration, et de vérification et de validation du système au regard des besoins initiaux. La phase de développement se positionne à l’arête des deux branches. Le modèle du cycle en V améliore le modèle en cascade car il permet de limiter les retours aux phases précédentes en cas de problèmes. Il met en évidence la nécessité d’anticiper et d’élaborer les plans de vérification et de validation qui détermineront les attendus des étapes de la branche descendante.
Le cycle en spirale reprend les étapes du cycle en V, mais les organise non plus en branches descendante/ascendante mais en cycle itératif (Figure 1.3c). Chaque itération est décomposée de la manière suivante : détermination des objectifs de l’itération, évaluation des solutions potentielles, développement et vérification du résultat. Le système gagne en maturité à chaque itération avec une maîtrise des risques accentuée car chaque itération est vérifiée. Ainsi, ce modèle de cycle de vie autorise plus facilement à réévaluer risques en cours de développement que le cycle en V .
Les normes de l’ingénierie système
L’ingénierie système s’est dotée de normes qui décrivent les activités à mener pour les étapes du cycle de vie d’un système. Leur existence repose sur l’idée qu’il existe de fortes analogies entre une grande partie des projets, quelle que soit la nature du système, de sa mise en œuvre ou du domaine d’application [10]. L’étude des retours d’expérience a permis d’identifier, de formaliser et d’harmoniser les bonnes pratiques éprouvées de la discipline. Elles déterminent les activités à mener pour les étapes du cycle de vie du système.
Les normes fournissent les références communes nécessaires pour structurer et institutionnaliser les pratiques de l’ingénierie système. Elles offrent de ce fait les moyens de communication et de collaboration entre les praticiens et les organisations du domaine. Par ailleurs, l’existence de normes constitue un indicateur de maturité, d’expansion et d’acception de la discipline considérée [86]. L’adoption des normes favorise [31] :
– la qualité des systèmes produits,
– l’anticipation des problèmes et de la maîtrise des risques,
– la maîtrise de la complexité des systèmes complexes,
– la tenue des délais et la maîtrise des coûts, avec notamment une anticipation en amont du coût global du cycle de vie,
– l’efficacité dans la maîtrise de la coopération de l’interdisciplinarité et de multiples acteurs,
– la satisfaction des parties prenantes .
Le normes formalisent les processus de l’ingénierie système (Figure 1.4). Un processus est un ensemble d’activités, sous le contrôle de régulations (Controls), qui transforment un ensemble d’éléments en entrée (Inputs) en un ensemble d’éléments de sortie (Outputs) dans un contexte déclencheur (Enablers). Les normes explicitent donc les résultats attendus pour une activité donnée. En revanche, elles ne spécifient pas la manière dont ces transformations se déroulent, en termes d’entités réalisatrices ou de temporalité. En ce sens, les normes se veulent généralistes afin de convenir à une grande diversité de projets et de domaines. Les processus sont mis en œuvre par des méthodes plus spécifiques au domaine d’application.
|
Table des matières
1 Introduction générale
I État de l’art
1 L’ingénierie système
1.1 Système et ingénierie système
1.2 Les normes de l’ingénierie système
1.3 L’ingénierie guidée par les modèles – MBSE
1.4 Formalisme SysML
1.5 Des lacunes dans la prise en considération des aspects humains
2 L’Intégration Homme-Système (HSI)
2.1 Les domaines du HSI
2.2 Une vision par processus de l’approche HSI
2.3 La conception centrée utilisateur
2.4 Le HSI dans les modèles MBSE
2.5 L’ingénierie cognitive pour l’analyse de l’activité humaine
2.6 Synthèse
3 Cognitive Work Analysis
3.1 Cognitive Work Analysis
3.2 L’analyse du domaine de travail
3.3 La Hiérarchie d’Abstraction
3.4 Le CWA et l’ingénierie système
3.5 Le CWA et le HSI
3.6 Synthèse
4 Synthèse et proposition
II Expérimentation
1 Expérimentation
1.1 Cadre de l’étude expérimentale
1.2 Résultats de l’expérimentation
1.3 Synthèse
III Proposition de la méthode IS+WDA
1 Intégration de l’analyse du domaine dans le MBSE
1.1 Processus de définition des exigences
1.2 Processus de conception
1.3 Proposition de la méthode IS+WDA
1.4 Synthèse
IV Cas d’application
1 Étude de cas NECTAR
1.1 Description du cas d’étude NECTAR
1.2 Application de la démarche pour NECTAR
1.3 Itérations suivantes
1.4 Synthèse
2 Étude de cas DURESS II
2.1 Description du système DURESS II
2.2 Application de la démarche pour DURESS II
2.3 Itérations suivantes
2.4 Synthèse
V Conclusion et perspectives
1 Résumé des contributions
2 Perspectives de travail
VI Bibliographie
VII Annexes
