L'ingénierie système en STI2D et SI - Comment l'appliquer en cycle terminal ? - Formation IS 2019
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
L’ingénierie système en STI2D et SI Comment l’appliquer en cycle terminal ? Formation IS – 2019 1
Objectifs de la journée
1. Découvrir les acteurs et processus liés à l’Ingénierie Système ;
2. Comprendre le déroulé de l’Ingénierie Système en STI2D et SI ;
3. S’exercer sur le Plugin MagicDraw : « Ingénierie Système dans l'Éducation Nationale » ;
4. Appréhender la rédaction de la validation de projet format session 2019-2020 ;
Formation IS – 2019 2
Ensemble des documents utilisés pour cette formation
❑ Les différents documents, supports, fil rouge vous seront partagés via votre clef
USB.
❑ Courant octobre, vous recevrez des informations complémentaires pour la dépose
des fichiers.
Formation IS – 2019 3
Déroulé de la journée
9h-11h : Présentation de l’IS avec le fil rouge « Clipflow »
11h-12h : Proposition d’activité sur l’évolution du « Clipflow »
12h-13h : Repas
13h-15h : Poursuite de l’activité sur l’évolution du Clipflow et proposition de réponse
15h-15h30 : Présentation du document de validation de terminale STI2D 2020 avec la trottinette
15h30-15h50 : Présentation d’une démarche IS prenant en compte le domaine des produits issus du bâtiment
15h50-16h : Commande pour J2 et conclusions
Formation IS – 2019 4
Sommaire
Les risques liés à un projet mal défini
Des systèmes qui nécessitent d’être abordés différemment
Les trois processus
A vous de jouer
Une proposition de réponse
La validation des projets pour la terminale STI2D 2020
L’IS en AC, une aberration ?
Formation IS – 2019 5
Les risques liés à un projet
mal défini
Formation IS – 2019 6
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.
Formation IS – 2019 7
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. Formation IS – 2019 8
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%
Formation IS – 2019 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.
1
Formation IS – 2019
0Des systèmes qui
nécessitent d’être abordés
différemment
1
Formation IS – 2019
1Une complexité croissante des systèmes
La complexité croissante des systèmes
induit des facteurs de risques de plus en
plus nombreux et fréquents :
Formation IS – 2019 12S’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
Formation IS – 2019 13Dé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
Formation IS – 2019 14Les 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
Formation IS – 2019 15Limite et contexte
❑ L’analyse des flux permet d’identifier l’environnement du système en définissant l’intérieur et
l’extérieur
Formation IS – 2019 16Mettre 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.
Formation IS – 2019 17Mais c’est aussi et surtout…..
Pour arriver à la satisfaction client
client
Partir du besoin initial
« Le commencement est beaucoup
plus que la moitié de l'objectif. »
Aristote
Formation IS – 2019 18L’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
2
3
4
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
Formation IS – 2019 19L’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.
Formation IS – 2019 20Relation 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.
Formation IS – 2019 21Les 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é.
Formation IS – 2019 22Systè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
Formation IS – 2019 23SoS du fil rouge Formation IS – 2019 24
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.
Formation IS – 2019 25Schémas des visions et points de vue Formation IS – 2019 26
Cycle de vie d’un produit
Phase de projet
Formation IS – 2019 27Standards et normes
Phase de projet
Formation IS – 2019 28Dé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
Formation IS – 2019 30Les différents processus pilotés dans le cadre de l’IS
Spécifique à la
phase de projet
Formation IS – 2019 31Processus techniques en projet
Réalisation des
constituants
Définition
du système
Intégration du
système
Formation IS – 2019 32Enchainement des processus en projet
Maître
d’ouvrage
MOA
Maître
d’œuvre
MOE
Intersection de deux branches
Formation IS – 2019 34Dé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…
Formation IS – 2019 35Les 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/
Formation IS – 2019 36Les 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/
Formation IS – 2019 37Temporalité 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
Formation IS – 2019 38L’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
Formation IS – 2019 39Processus 1 du projet :
Définition des exigences
des parties prenantes
4
Formation IS – 2019
0Les é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
Formation IS – 2019 41Dé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).
Formation IS – 2019 42Représenter le besoin initial Formation IS – 2019 43
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
Formation IS – 2019 44Représenter la mission du produit
❑ Elle est formalisée
graphiquement par un
diagramme des exigences
car derrière un besoin se
cache une exigence.
Formation IS – 2019 45Dé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
Formation IS – 2019 46Représenter le contexte
❑ Il est formalisé
graphiquement
par un diagramme
de contexte qui
mêle acteurs et
blocs.
Formation IS – 2019 47Dé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.
Formation IS – 2019 48Représenter l’utilisation du produit ❑ Il est formalisé par un diagramme de cas d’utilisation qui inclut la description textuelle du scénario. Formation IS – 2019 49
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, ...
Formation IS – 2019 50Savoir 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
Formation IS – 2019 51Représenter les besoins des parties prenantes Formation IS – 2019 52
Focus sur un des besoins des parties prenantes Formation IS – 2019 53
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 !
Formation IS – 2019 54Synthè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
Formation IS – 2019 56Processus 2 du projet :
Analyse des exigences
5
Formation IS – 2019
7Lecture 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 .
Formation IS – 2019 58L’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.
Formation IS – 2019 59Représenter les exigences utilisateurs en partant des besoins des parties prenantes Formation IS – 2019 60
Représenter les exigences du système Formation IS – 2019 61
Représenter les exigences du système Formation IS – 2019 62
Représenter les exigences du système satisfaites Formation IS – 2019 63
Processus 3 du projet :
Conception de
l’architecture
6
Formation IS – 2019
4L’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.
Formation IS – 2019 65Représenter l’architecture logique du système Formation IS – 2019 66
Représenter l’architecture logique du système Formation IS – 2019 67
Représenter l’architecture physique du système Formation IS – 2019 68
Représenter l’architecture physique du système Formation IS – 2019 69
Représenter l’architecture physique du système Formation IS – 2019 70
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
Formation IS – 2019 71A vous de jouer Formation IS – 2019 73
Proposition d’activité sur l’évolution du clipflow
L’objectif est de formaliser un nouveau CdC à partir de la demande
du client (enregistrement audio de l’entretien).
Cette activité est à réaliser en suivant le cadre ISEN du logiciel MagicDraw.
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.
Formation IS – 2019 74Une proposition de
réponse
Formation IS – 2019 75Proposition de correction du besoin initial Formation IS – 2019 76
Proposition de correction de la mission principale Formation IS – 2019 77
Proposition de correction du contexte Formation IS – 2019 78
Proposition de correction du cas d’utilisation Formation IS – 2019 79
Proposition de correction des besoins des parties prenantes Formation IS – 2019 80
Proposition de correction de l’analyse des exigences Formation IS – 2019 81
Proposition de correction de l’analyse des exigences Formation IS – 2019 82
Proposition de correction - Diagramme de séquence analyse Formation IS – 2019 83
Proposition de correction de l’architecture logique Formation IS – 2019 84
Proposition de correction de l’architecture logique Formation IS – 2019 85
Proposition de correction de l’architecture physique Formation IS – 2019 86
Proposition de correction de l’architecture physique Formation IS – 2019 87
La validation des projets
en terminale pour la
rentrée 2019
Formation IS – 2019 88Document de validation de terminale STI2D 2020 Formation IS – 2019 89
Document de validation de terminale STI2D 2020 Formation IS – 2019 90
Document de validation de terminale STI2D 2020 Formation IS – 2019 91
Document de validation de terminale STI2D 2020
Convertir ou pas, libre choix !!
Diagramme des besoins
des parties prenantes Diagramme des exigences
pour terminer l’ancien
programme STI2D 2011
Intitulés des tâches des élèves
Formation IS – 2019 92Document de validation de terminale STI2D 2020
❑ Fiche officielle de validation du projet
de terminale 2020
❑ Certains champs se remplissent
automatiquement.
Formation IS – 2019 93L’IS en AC, une
aberration ?
Lien diaporama
Formation IS – 2019 94Commande pour la J2 Formation IS – 2019 95
Production activité élève de 1ère STI2D (IT et/ou I2D) ou SI.
Commande pour la J2 :
Produire une activité pour des élèves de 1ère STI2D (IT et/ou I2D) ou SI qui abordera :
▪ Soit le SysML et son appropriation via une lecture et modification de diagrammes d’un produit
disponible dans le laboratoire.
▪ Soit une analyse de besoin via la démarche IS pour améliorer un produit existant sans oublier de
définir les périmètres de chaque intervenant dans le dossier
▪ Soit une action complète d’amélioration du besoin via la démarche IS
Il s’agira d’une activité ou l’élève sera acteur. Sa finalité sera à intégrer dans un déroulé de séquence.
Organisation pour la J2 :
Production collaborative par groupe de 2 ou 4
A déposer avant la J2. Site de dépose donné courant octobre.
Formation IS – 2019 96Bibliographie
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
Formation IS – 2019 97Vous pouvez aussi lire
