Ingénierie Systeme

Ingénierie Système
Comment l’appliquer ?
Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 1

Sommaire
Les risques liés à un projet mal défini
Des systèmes qui nécessitent de l'Ingénierie Système
Processus 1 : Définition des exigences des parties prenantes
Processus 2 : Analyse des exigences
Processus 3 : Conception de l'architecture

Les risques liés à un projet
mal défini

Les frontières d’un besoin mal définies
Le vol inaugural d'Ariane 5 du 4 juin 1996 se solde par un échec.

40 secondes après le démarrage de la séquence de vol, le lanceur, qui
se trouve à une altitude de 3700 mètres, dévie de sa trajectoire, se
brise et explose.
Des ingénieurs des équipes du projet Ariane 5 du CNES et de l'industrie
commencent immédiatement à rechercher les causes de cet échec.

Les frontières d’un besoin mal définies
Rapport de la Commission d'enquête Ariane 501 Echec du vol
Ariane 501 Président de la Commission : Professeur J.-L. LIONS
Après enquête, les ingénieurs du CNES s’aperçoivent que, par mesure d'économie, le logiciel de navigation de la
fusée Ariane 5 est celui qui avait été conçu pour Ariane 4 générant une incompatibilité entre le logiciel et le
matériel.
Tout tient à une seule variable : celle allouée à l'accélération horizontale.
L'accélération maximum d'Ariane 4 a une valeur d'environ 64, la variable a été codée sur 8 bits.
Mais, Ariane 5 est plus véloce : son accélération peut atteindre la valeur 300 (soit 1 0010 1100 en binaire et
nécessitant 9 bits).
La variable codée sur 8 bits a connu un dépassement de capacité.
Ce dépassement a produit une valeur absurde dans la variable, ne pouvant correspondre à la réalité. Par effet
domino, le logiciel face à des valeurs considérées comme anormales décide l'autodestruction de la fusée.

Définir au mieux les besoins pour un projet réussi
Les principales causes de succès et d’échecs d’un projet sont liées aux exigences (Standish Group 2015)
Facteurs d’échecs Causes racines Facteurs de succès
37 % Besoins, exigences 40 %
9% Projet, ressources 23 %
Gestion des données

8% 14 %
techniques
11 % Technique, technologie 9%

Niveau de résolution des projets (étude 2015 Standish Group)
Conforme : le projet est réalisé en temps et en

heure, dans les budgets alloués, avec toutes les
fonctionnalités et caractéristiques spécifiées à
l'origine.
Défaut de conformité : le projet est terminé et

opérationnel, mais avec un dépassement du
budget et/ou des délais, et moins de
fonctionnalités que prévues initialement.
Rejeté : le projet est abandonné avant la fin

prévue ou n'est jamais mis en œuvre.

Des systèmes qui
nécessitent de
l'Ingénierie Système

Une complexité croissante des systèmes
La complexité croissante des systèmes

induit des facteurs de risques de plus en
plus nombreux et fréquents :

S’adapter à une complexité croissante
Dans l’industrie automobile, un projet "véhicule" représente en moyenne :
→ une charge de 1.500 hommes-années de travail,
→ répartie sur 4 ans,
→ fait intervenir 30 à 50 corps de métiers différents
→ met en jeu des budgets de l’ordre du milliard d’euros.
Source : Groupe PSA.com

Définition d’un système artificiel
Ensemble organisé : De matériels, logiciels, compétences humaines et processus
Structuré en fonction d'un objectif à atteindre,
Par le biais d'un jeu de relations (interactions mutuelles,

dynamiques...),
Remplissant une ou plusieurs fonctions.
Intégré à un environnement

Les notions clés d’un système artificiel
Flux matière, énergie,

❑ Le système est une boite noire utilisant des information
ressources pour transformer des éléments
d’entrée en éléments de sortie.
Ressources humaines,
logicielles, physiques
❑ Le système est dit fermé quand il ne reçoit
pas de flux de son extérieur.
❑ Le système est dit ouvert quand il reçoit Flux matière, énergie,

des flux de son extérieur. information

Limite et contexte
❑ L’analyse des flux permet d’identifier l’environnement du système en définissant l’intérieur et

l’extérieur

Mettre en œuvre l’ingénierie système durant le projet, c’est…
Processus 3 :
conception de
l’architecture
Domaine de la
solution
Processus 1 :
définitions des Processus 2:
parties prenantes analyse des
exigences
Passer du domaine du
problème au domaine de la
solution en déroulant les 3
Domaine du processus techniques de
problème l’ISO 15288.
L’ingénierie système en deux mots ou un peu plus….
Démarche dont l’objectif est de formaliser et de coordonner l’ensemble des processus à seule fin de
REPONDRE CORRECTEMENT à un besoin exprimé.
Recueillir le Arrêter la Définir les Concevoir Valider la

besoin, le finalité et les modes l’architecture réalisation
verbaliser, le missions du d’utilisations du système
valider système à et les
réaliser fonctions
associées
1
5
L’ensemble de ces actions s’inscrit dans une démarche de management de projets, qui sous tend les
notions suivantes : BIEN FAIRE (avec de bonnes pratiques) les BONNES activités au BON moment avec
les BONNES ressources. Source AFIS

L’ingénierie système, c’est donc…
Une démarche méthodologique coopérative et interdisciplinaire englobant l’ensemble des activités adéquates.
En apportant une solution

économique et performante aux
Pour concevoir, développer, faire évoluer et vérifier un ensemble de
besoins des parties prenantes
produits, processus et compétences humaines.
acceptable par tous (inspirée de
IEEE 1220).
Cet ensemble est intégré en un Dans un contexte de recherche

Sur l’ensemble de son cycle de vie.
système. d’équilibre et d’optimisation.

Relation entre système à faire et système pour faire
système mettant en œuvre l’IS
à dominante technologique
Système mis en œuvre pour réaliser l’IS

à dominante organisationnelle.

Les deux types de systèmes en IS
Technologique :
• Ensemble organisé de matériels, logiciels,
systèmes développés dans compétences humaines et processus pour répondre à
un contexte mettant en un besoin dans un ou des environnements
œuvre l’ingénierie
Organisationnel : • Ensemble organisé d’équipes (réunions de

compétences), de méthodes, de processus et de
systèmes mis en œuvre moyens pour répondre à un besoin (ici le besoin de
pour réaliser l’ingénierie développer un système), mobilisé dans un
des systèmes développés. environnement technico-industriel donné.

Système de systèmes (SoS)
Fait partie lui-même d’un système de plus haut
niveau : le sur-système du système d’intérêt :
trafic, route, etc.
Se définit comme : «
l’assemblage de
constituants réalisant
une tâche qu’aucun
autre système ne Constitué de
peut accomplir lui- systèmes de plus bas
même » niveau : les sous-
systèmes du
système d’intérêt.
Source : 2014/IBM/smart-si/assets/livresblancs/ingenierie-systeme-
pour-les-nuls.pdf

Visions et points de vue : une compréhension indispensable
Instance de points du vue (ex : brosse

Visions Répond à la question Exemples de points de vue
à dents électronique)
Mission, contexte
Dents propres et saines, gain de
Opérationnel Pourquoi ? opérationnel, contexte
temps , salle de bain « tendance ».
stratégique.
Brossage, régulation de vitesse,
Fonction, fonctionnement et
Fonctionnel Quoi ? programmation de la force de
mode de fonctionnement.
brossage.
Compostant, organe et Tête, base, corps, régulateur de

Organique Comment ?
configuration technique. vitesse.

Schémas des visions et points de vue

Cycle de vie d’un produit
Phase de projet
Standards et normes
Phase de projet

Définition du Processus
Processus : ensemble de tâches

coordonnées ajoutant une valeur dans les
transformations d'entrées en sorties.
Régis par la norme ISO 15288

Définit pour chaque processus :
✓ L’objet du processus
Cette démarche permet de construire un
✓ Les résultats
modèle du produit, formalisé en SysML.
✓ Les activités (tâches à accomplir)
On parle alors d’approche modèle.
MBSE : Model-Based System Engineering

Les différents processus pilotés dans le cadre de l’IS
Spécifique à la
phase de projet

Processus techniques en projet
Réalisation des
constituants
Définition
du système
Intégration du
système

Enchainement des processus en projet
Maître
d’ouvrage
MOA
Maître
d’œuvre
MOE
 Intersection de deux branches

Définition des acteurs du processus
Le maître d’ouvrage MOA Le maître d’oeuvre MOE Les parties prenantes
Type 1 :
Responsable du besoin Responsable de la solution Intéressées par l’utilisation
et/ou l’exploitation du
système ou susceptibles
d’être concernées par le
système
Doit obtenir un système
répondant au besoin et le Doit fournir un système Type 2 :
mettre à disposition des répondant au besoin.
exploitants et utilisateurs Impliquées dans le cycle de
vie du système :
concepteurs, producteurs,
« maintenanciers »,
logisticiens…

Les responsabilités du MOA
Différence entre maîtrise d’ouvrage et

maître d’ouvrage :
▪ La maîtrise d'ouvrage (MOA)

représente le client du projet, celui
qui sera normalement le
propriétaire de l'ouvrage. Il s’agit
d’une personne morale (une
entreprise, un service...).
• Le maître d'ouvrage est la personne
physique qui représente la MOA.
On parle parfois de pilote
stratégique du projet ou de sponsor.
Source http://www.gestion-projet-informatique.vivre-aujourdhui.fr/

Les responsabilités du MOE
La maîtrise d'oeuvre (MOE) est

garante de :
• la bonne réalisation technique des
solutions ;
• la fourniture du produit. Elle peut
réaliser elle-même cette solution,
ou missionner un ou plusieurs
fournisseurs pour cette réalisation ;
• la qualité technique de la solution
proposée ;
• du respect des coûts ;
• du respect des délais.
Source http://www.gestion-projet-informatique.vivre-aujourdhui.fr/

Temporalité des processus techniques et acteurs
3 processus techniques :
▪ 1 - DBPP : Définition des
Besoins des Parties
Prenantes
▪ 2 - AE : Analyse des
Exigences
▪ 3 - CA : Conception
Architecturale
1 MOA 2 MOE 3 MOE
Domaine du problème Domaine de la solution

L’intérêt du SysML dans l’IS
❑ Traduire
graphiquement les Définir les besoins Définir le contexte Définir les utilisations Définir les besoins
des parties
résultats obtenus en prenantes
BDD UC RD
suivant les processus

de l’IS
Analyser les Définir les états Décrire les missions Définir les exigences
exigences SMD SD, SMD RD
Concevoir Identifier les

Définir la vue logique
Vérifier l’architecture
l’architecture – Point opérations logique
AD
de vue logique SD & SMD RD & Matrices
Concevoir Analyse des

Définir la vue interne
Vérifier l’architecture
l’architecture – Point architectures physique
IBD
de vue physique BDD RD & Matrices

Processus 1 :
Définition des exigences
des parties prenantes

Les étapes à suivre pour définir correctement le problème
• Explicité par • Formalisa- • Rédigé sur la • Fait intervenir • Établi à partir

tion du
Mission
Utilisation
Besoin des parties prenantes

seule base du
Besoin initial
Contexte
l’utilisateur les acteurs de l’ensemble
par sondage, besoin besoin initial, issus du des
interview initial avec contexte. descriptions
• Explicité par d’éventuels • Peut entrainer précédentes.
le client lors retours pour • Peut nécessiter
des
de réunions mieux des
formaliser la réécritures ou
modification ajustements
mission (vis-à- dans la
vis de certaines de la mission
formalisation
parties • Peut entraîner
prenantes…) des
modifications
des parties
prenantes

Définir le besoin initial
❑ Formulé par le client.

❑ Apporte toujours une réponse à une problématique (sociétale, environnementale,
économique).
❑ Consiste en :
• l’amélioration d’un produit existant, suite à une révision du cahier des charges
initial ;
• la création d’un nouveau service répondant à des attentes fortes ;
• une initiative personnelle, prospective et visionnaire (prise de risque).

Représenter le besoin initial

Définir la mission du produit
❑ Elle est déduite

❑ Il s’agit de formuler le besoin initial (sans ajout) pour répondre clairement
aux questions suivantes :
Pourquoi ai-je besoin de ce produit ?

→ pour répondre à un problème posé
→ finalité du produit
Que doit faire ce produit pour cela ?

→ mission du produit

Représenter la mission du produit
❑ Elle est formalisée
graphiquement par un
diagramme des exigences
car derrière un besoin se
cache une exigence.

Définir le contexte
❑ Il correspond à l’environnement dans

lequel le système va évoluer.
❑ A l’intérieur des frontières de ce

contexte, le système est en interaction
avec les différentes parties prenantes
Cette étape est primordiale. En cas de frontière mal définie, le projet se soldera par un échec

Représenter le contexte
❑ Il est formalisé
graphiquement
par un diagramme
de contexte qui
mêle acteurs et
blocs.

Définir le cas d’utilisation du produit
Un produit :
• rend des services (services attendus/rendus) ;
• donne un résultat observable ;
• possède des cas d’utilisation différents décrient par un déroulement
temporel défini comme scénario
❑ La mission du produit constitue le cas d’utilisation principal.

❑ Il permet de clarifier et organiser les besoins du client.
❑ Les cas d’utilisation, via les scénario d’utilisation, décrivent le comportement attendu du produit.
Cas d’utilisation = comportement attendu du produit

qui servira au final à valider le produit d’un point de vue comportemental.

Représenter l’utilisation du produit
❑ Il est formalisé par un

diagramme de cas
d’utilisation qui inclut
la description textuelle
du scénario.

Représenter l’utilisation du produit

Définir les besoins des parties prenantes
Typés de la façon suivante :

• Service attendu ;
• Opérationnel : mode de fonctionnement, modes de marche, condition d’évolution, … ;
• Performance ;
• Interface : physique, ergonomie, interopérabilité, … ;
• Contrainte : liée à une phase de vie, environnement du produit, règlementation, coût,
délai, etc.
Obtenus sur la base des éléments initiaux (contraintes, performances attendues initiales),
complétés par l’analyse des activités précédentes :
• étude du contexte : besoins d’interface, contraintes ;
• utilisations : besoins de services attendus ;
• étude des scénarios : besoins d’interface, opérationnels, ...

Savoir rédiger les besoins des parties prenantes
❑ La MOA en charge de la spécification des besoins n’amène aucune expertise :

❑ Les besoins sont rédigés en des termes non spécialistes et doivent rester dans l’espace du problème. Ils
n’amènent aucune solution technique ni architecturale.
Espace du problème Solution technique/architecturale
« Transmettre une information à communiquer en Wi-Fi

distance » Mettre en œuvre la norme BlueTooth 5.2
« Animer, mettre en mouvement » guider en translation

transmettre un mouvement
« Être autonome en énergie » Produire

stocker

Représenter les besoins des parties prenantes

Focus sur un des besoins des parties prenantes



Les informations remises
❑ Au travers du cahier du charge et grâce à « la spécification des besoins », le MOE a les réponses à :
Question Via
Pourquoi le produit est-il utile/nécessaire ? finalité
Que doit-il faire ? mission
Qui est concerné / impacté par celui-ci ? parties prenantes
Quelles sont les frontières du produit ? contexte
Quels services sont attendus ? utilisations
Quels sont les comportements attendus ? scénarios
Quels sont les besoins pour répondre à tout cela ? besoins
Tout en restant toujours dans l’espace du problème !

Synthèse de la composition du CdC
Client/MOA Cdc Synthèse projet
Définition des
besoins Diagramme
de contenu
Diagramme
d’exigences
Diagramme
de contexte
Diagramme Référentiel IS = Cdc

de cas transmis
d’utilisations
Diagramme
d’exigences
Référentiel IS
des besoins

Processus 2 :
Analyse des exigences

Lecture du CdC et analyse des exigences
A partir de l’analyse des besoins des parties prenantes :
❑ La maîtrise d’œuvre (MOE) en charge du processus technique :

→ Apporte des concepts systèmes (opérationnels/architecturaux) ;
→ Décrit les états initiaux (SMD), raffinés par la suite ;
→ Décrit précisément les scénarios (SD) ;
→ Définit les exigences système (RD), basées sur les besoins et raffinées par les concepts système apportés.
❑ Les exigences système (ES) sont typées de la même manière que les besoins, sauf
pour :
→ Les besoins de service attendu, qui deviennent des exigences système
« Fonctionnelles » ;
→ les exigences de « Validation » : définissent les protocoles, test ou essais
permettant de valider une exigence .

Analyse des exigences
La première étape consiste à spécifier les exigences

de l'utilisateur pour ensuite, après une
itération, spécifier une configuration système
plus détaillée.
Analyse CdC
Exigences utilisateurs Exigences système

Version développée des spécifications
utilisateur.
Décrit les exigences fonctionnelles et Ajoutent des détails et expliquent comment
non fonctionnelles dans un langage le système doit répondre aux besoins des
simple et sans ambiguïté. utilisateurs.
Ne doit pas être assujetti à
l’implémentation ou à la conception.

Représenter les exigences utilisateurs en partant des besoins
des parties prenantes

Représenter les exigences du système

Représenter les exigences du système

Représenter les exigences du système satisfaites

Processus 3 :
Conception de
l’architecture

L’Architecture
❑ L’architecture est la clef de voûte.

❑ Si l’équilibre est atteint entre la proposition
d’architecture et le besoin utilisateur, alors le
succès est garanti.
Démarche
❑ L’architecture définit les choix stratégiques du

Architecture systèmes en termes :
▪ D’adaptabilité ;
▪ De performance ;
▪ De qualité.
Pilotée/
besoin utilisateur
❑ C’est la combinaison de ces choix qui
permettra la qualification.

Représenter l’architecture logique du système

Représenter l’architecture logique du système

Représenter l’architecture physique du système



Les itérations une étape indispensable
Chaque itération sur • Permet de clarifier, affiner, valider les

la phase d’analyse besoins de l’utilisateur
Chaque itération
sur la phase de • Permet la vigilance sur la prise en compte
conception et des besoins utilisateur
réalisation
Chaque itération • Permet la vérification de

durant la phase de la satisfaction des
test besoins utilisateur

Système
"ClipFlow_Evolution"
Une proposition de
réponse

Proposition d’activité sur l’évolution du clipflow
L’objectif est de formaliser un nouveau CdC à partir de la demande

du client.
Elle se découpe en 5 étapes :

1) Formuler l’expression du besoin initial ;
2) Définir la mission principale du système ;
3) Proposer le diagramme de contexte du nouveau système qui sera une évolution du
diagramme d’origine ;
4) Compléter le diagramme des cas d’utilisation du nouveau système ;
5) Etablir le diagramme d’exigences correspondant aux besoins des parties prenantes.

Proposition de correction du besoin initial

Proposition de correction de la mission principale

Proposition de correction du contexte

Proposition de correction du cas d’utilisation

Proposition de correction des besoins des parties prenantes

Proposition de correction de l’analyse des exigences

Proposition de correction de l’analyse des exigences

Proposition de correction - Diagramme de séquence analyse

Proposition de correction de l’architecture logique

Proposition de correction de l’architecture logique

Proposition de correction de l’architecture physique

Proposition de correction de l’architecture physique

Bibliographie
1. IS :
▪ Ouvrage collectif AFIS, « Découvrir et comprendre l’Ingénierie Système » Version 3 - 12 02 2009
▪ Livre Blanc AFIS « Ingénierie Système : la vision AFIS pour les années 2020-2025 »
▪ Boîte à outil du concepteur INSA Lyon
▪ Philippe Revellat, Lien ISO 15288,[dernière consultation le 20 mars 2019]. disponible sur http://phr-
configuration.com/gestion-de-configuration/lien-iso-15288/
▪ https://www.incose.org/about-systems-engineering
▪ D. LUZAUX, J-R RUAULT. L’ingénierie système. Afnor Editions, 2013.
2. SysML :
▪ Laurent Balmelli, An Overview of the Systems Modeling Language for Products and Systems
Development. IBM Technical Report 2006 TR-20060603, (?),[dernière consultation le 20 mars
2019]. disponible sur http://www.omgsysml.org/news-articles.htm
▪ Magic draw User Manual 18.1 No Magic, Inc.2015
▪ http://www.omgsysml.org/what-is-sysml.htm
▪ P. ROQUES. Modélisation de systèmes complexes avec SysML. Eyrolles, deuxième tirage 2015

Ingénierie Systeme

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ingénierie Systeme

Transféré par

Droits d'auteur :

Formats disponibles

Ingénierie Système

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 1

Les risques liés à un projet mal défini

Des systèmes qui nécessitent de l'Ingénierie Système

Processus 1 : Définition des exigences des parties prenantes

Processus 2 : Analyse des exigences

Processus 3 : Conception de l'architecture

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 2

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 3

Le vol inaugural d'Ariane 5 du 4 juin 1996 se solde par un échec.

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 4

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 5

Facteurs d’échecs Causes racines Facteurs de succès

Gestion des données

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 6

Conforme : le projet est réalisé en temps et en

Défaut de conformité : le projet est terminé et

Rejeté : le projet est abandonné avant la fin

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 7

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 8

La complexité croissante des systèmes

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 9

Source : Groupe PSA.com

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 10

Ensemble organisé : De matériels, logiciels, compétences humaines et processus

Structuré en fonction d'un objectif à atteindre,

Par le biais d'un jeu de relations (interactions mutuelles,

Remplissant une ou plusieurs fonctions.

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 11

Flux matière, énergie,

❑ Le système est dit ouvert quand il reçoit Flux matière, énergie,

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 12

❑ L’analyse des flux permet d’identifier l’environnement du système en définissant l’intérieur et

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 13

Recueillir le Arrêter la Définir les Concevoir Valider la

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 15

En apportant une solution

Cet ensemble est intégré en un Dans un contexte de recherche

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 16

Système mis en œuvre pour réaliser l’IS

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 17

Organisationnel : • Ensemble organisé d’équipes (réunions de

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 18

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 19

Instance de points du vue (ex : brosse

Compostant, organe et Tête, base, corps, régulateur de

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 20

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 21

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 23

Processus : ensemble de tâches

Régis par la norme ISO 15288

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 24

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 25

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 26

 Intersection de deux branches

Le maître d’ouvrage MOA Le maître d’oeuvre MOE Les parties prenantes

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 28

Différence entre maîtrise d’ouvrage et

▪ La maîtrise d'ouvrage (MOA)

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 29

La maîtrise d'oeuvre (MOE) est

Pr. Mohammed BOUAICHA - FST Settat_Université Hassan 1er 30

1 MOA 2 MOE 3 MOE

Domaine du problème Domaine de la solution