Transcript Génie logiciel et Gestion de projet BTS IRIS 2

Génie logiciel
et
Gestion de projet
BTS IRIS 2
GL
1
Introduction
génie logiciel (software engineering)
existe depuis plus de 30 ans
► Né des constatations que les logiciels :
► Le
 Pas fiables
 Incroyablement difficiles à réaliser dans les
délais
 Ne satisfaisaient pas le cahier des charges
BTS IRIS 2
GL
2
La préhistoire du logiciel
► Années
50 et 60 : programmation empirique
 production "artisanale" de logiciels scientifiques
 royaume des "codeurs" et les "grands gourous"
► Fin
des années 60 : la "crise du logiciel"
 difficulté d'écrire de grands programmes
 difficulté de les utiliser, difficulté de les faire
évoluer
 de nombreux projets échouent
BTS IRIS 2
GL
3
Quelques erreurs célèbres
►
►
►
►
►
►
perte de la 1ère sonde Mariner vers Venus suite à une erreur de
programmation dans un programme Fortran
perte, en 1971, de 72 ballons d’expérimentation météorologique
à cause d’un bug logiciel
panne, en 1990, du réseau téléphonique de la cote Est des USA
suite à un changement de version d’un des modules du système
de gestion du réseau
abandon d'un projet d'informatisation de la City après 4 ans de
travail et 100 M£ de perte
échec d’ARIANE 501 suite à un bug logiciel
Invalidation de version de Windows suite au changement de
version du Windows Genuine Advantage
BTS IRIS 2
GL
4
La crise du logiciel
► Etude





du gouvernement américain en 1979
Payés mais jamais livrés
Livrés mais jamais utilisés
Abandonnés ou refaits
Utilisés après modification
Utilisés tel quel
BTS IRIS 2
GL
$3.2M
$2.0M
$1.3M
$0.2M
$0.1M
47%
29%
19%
3%
2%
5
Pourquoi le GL?
Si l'on veut maîtriser le développement de systèmes
complexes, il faut :
► rédiger
attend)
de façon claire les spécifications du système (ce que l'on
=> comment être sûrs que ces spécifications sont complètes ?
=> comment être sûrs que ces spécification sont cohérentes ?
► valider/vérifier
toutes les étapes du développements
=> a-t-on des moyens de validation/vérification (mathématiques) ?
► de
réutiliser des sous-systèmes déjà réalisés (mais pas
n'importe comment)
=> a-t-on des règles, des outils pour aider à la réutilisation ?
 nécessité d’une base théorique et d’une approche
ingénierie (science de l’ingénieur) du logiciel
6
Définition
► Le
génie logiciel comporte des aspects de gestion
de projet et des notions de qualité (satisfaire
le client)
► Ceci en utilisant des méthodes, des modèles, et
des outils.
BTS IRIS 2
GL
7
Récréation...
A propos de la réutilisation et du poids du passé…
 Question : la distance standard entre 2 rails de chemin de fer aux US
est de 4 pieds et 8,5 pouces. C'est un chiffre particulièrement bizarre.
Pourquoi cet écartement a-t-il été retenu ?
 Parce que les chemins de fer US ont été construit de la même façon
qu'en Angleterre, par des ingénieurs anglais expatriés, qui ont pensé
que c'était une bonne idée car ça permettait également d'utiliser des
locomotives anglaises.
Pourquoi les anglais ont construits les leurs comme cela ?
 Parce que les premières lignes de chemin de fer furent construites
par les mêmes ingénieurs qui construisirent les tramways, et que cet
écartement était alors utilisé.
Pourquoi ont-ils utilisé cet écartement ?
Récréation...
 Parce que les personnes qui construisaient les tramways étaient les mêmes
qui construisaient les chariots et qu'ils ont utilisé les mêmes méthodes et les
mêmes outils.
Pourquoi les chariots utilisent un tel écartement ?
 Parce que partout en Europe et en Angleterre les routes avaient déjà des
ornières et un espacement différent aurait causé la rupture de l'essieu du
chariot.
Pourquoi ces routes présentaient elles des ornières ainsi espacées ?
 Parce que les premières grandes routes en Europe ont été construites par
l'empire romain pour accélérer le déploiement des légions romaines.
Pourquoi les romains ont ils retenu cette dimension ?
 Parce que les premiers chariots étaient des chariots de guerre romains. Ces
chariots étaient tirés par deux chevaux. Ces chevaux galopaient cote à cote et
devaient être espacés suffisamment pour ne pas se gêner. Afin d'assurer une
meilleure stabilité du chariot, les roues ne devaient pas se trouver dans la
continuité des empreintes de sabots laissées par les chevaux, et ne pas se
trouver trop espacées pour ne pas causer d'accident lors du croisement de
deux chariots.
 Réponse à la question :
l'espacement des rails US (4 pieds et 8 pouces et demi) s'explique parce
que 2000 ans auparavant, sur un autre continent, les chariots romains
étaient construits en fonction de la dimension de l'arrière train des chevaux
de guerre.
 Conséquence : la navette spatiale américaine est flanquée de deux
réservoirs additionnels attachés au réservoir principal. La société THIOKOL
fabrique ces réservoirs additionnels dans leur usine de l'UTAH. Les
ingénieurs qui les ont conçus auraient bien aimé les faire un peu plus
larges, mais ces réservoirs devaient être expédiés par train jusqu'au site de
lancement. La ligne de chemin de fer entre l'usine et Cap Canaveral
emprunte un tunnel sous les montagnes rocheuses. Les réservoirs
additionnels devaient pouvoir passer sous ce tunnel. Le tunnel est
légèrement plus large que la voie de chemin de fer, et la voie de chemin de
fer est à peu près aussi large que les arrières train de deux chevaux.
 Conclusion : une contrainte de conception du moyen de transport le plus
avancé au monde est la largeur d'un cul de cheval.
Les modèles de développement
BTS IRIS 2
GL
11
Le modèle en cascade
BTS IRIS 2
GL
12
Étude préliminaire
► définition
globale du problème,
► différentes stratégies possibles avec
avantages/inconvénients, ressources, coûts,
délais
► rapport d’analyse préliminaire ou schéma
directeur
► Principalement guidé par l’expérience
BTS IRIS 2
GL
13
Analyse des besoins
►
►
►
qualités fonctionnelles attendues en termes des services
offerts
qualités non fonctionnelles attendues : efficacité, sûreté,
sécurité, facilité d’utilisation, portabilité, etc.
qualités attendues du procédé de développement (ex :
procédures de contrôle qualité)
►
cahier des charges + plan qualité
►
Le cahier des charges peut inclure une partie destinée aux
clients (définition de ce que peuvent attendre les clients) et
une partie destinée aux concepteurs (spécification des
besoins)
BTS IRIS 2
GL
14
Cahier des charges
► document
contractuel
► décrit ce qui est attendu du maître d'œuvre
par le maître d'ouvrage
► décrit de façon précise (avec un vocabulaire
simple) les besoins auxquels le maître
d'œuvre doit répondre
► fait apparaître le besoin de manière
fonctionnelle (indépendamment de toute
solution technique)
BTS IRIS 2
GL
15
Cahier des charges
► But
:
 garantir au maître d'ouvrage que les livrables
seront conformes à ce qui est écrit
 éviter que le souhait soit modifié au fur et à
mesure du projet
BTS IRIS 2
GL
16
Cahier des charges
► permet
au maître d'œuvre de juger de la taille du
projet et de sa complexité afin de proposer une
offre la plus adaptée possible (coût, délai, de
ressources humaines, qualité)
► document
de référence, permettant de lever toute
ambiguïté sur ce qui était attendu
► un outil de dialogue permettant au maître d'œuvre
d'interroger le maître d'ouvrage afin d'affiner sa
compréhension de la demande
BTS IRIS 2
GL
17
Éléments principaux du CdC
►
Contexte : Un cahier des charges commence généralement par une
section décrivant le contexte, c'est-à-dire notamment le
positionnement politique et stratégique du projet.
►
Objectifs : Très rapidement, le cahier des charges doit permettre de
comprendre le but recherché, afin de permettre au maître d'œuvre
d'en saisir le sens.
►
Dictionnaire : Nombre de projets échouent à cause d'une mauvaise
communication et en particulier à cause d'un manque de culture et de
vocabulaires communs entre maîtrise d'œuvre et maîtrise d'ouvrage.
En effet, là où le maître d'ouvrage croît employer un vocabulaire
générique, le maître d'œuvre entend parfois un terme technique avec
une signification particulière.
BTS IRIS 2
GL
18
Éléments principaux du CdC
►
Périmètre : Le périmètre du projet permet de définir le nombre de personnes
ou les ressources qui seront impactées par sa mise en place.
►
Calendrier : Le calendrier souhaité par le maître d'ouvrage doit être très
clairement explicité et faire apparaître la date à laquelle le projet devra
impérativement être terminé. Idéalement des jalons seront précisés afin
d'éviter un « effet tunnel ».
►
Clauses juridiques : Un cahier des charges étant un document contractuel,
cosigné par la maîtrise d'œuvre et la maîtrise d'ouvrage, possède
généralement un certain nombre de clauses juridiques permettant par exemple
de définir à qui revient la propriété intellectuelle de l'ouvrage, les pénalités en
cas de non-respect des délais ou encore les tribunaux compétents en cas de
litige
BTS IRIS 2
GL
19
Analyse du système
► modélisation
 du domaine
 de l’existant (éventuellement)
► définition
d’un modèle conceptuel (ou
spécification conceptuelle),
► plan de validation.
► dossier
BTS IRIS 2
d’analyse + plan de validation
GL
20
Conception
► proposition
de solution au problème spécifié dans
l’analyse
► organisation de l’application en modules et
interface des modules (architecture du logiciel),
► description détaillée des modules avec les
algorithmes essentiels (modèle logique)
► structuration des données.
► dossier
module
BTS IRIS 2
de conception + plan de test global et par
GL
21
Programmation et tests
unitaires
► traduction
dans un langage de
programmation,
► tests avec les jeux d’essais par module
selon le plan de test.
► dossiers
BTS IRIS 2
de programmation et codes sources
GL
22
Intégration et test
d’intégration
► composition
progressive des modules,
► tests des regroupements de modules,
► test en vraie grandeur du système complet
selon le plan de test global (‘alpha testing’)
 Parfois très long (Half Life 2)
BTS IRIS 2
GL
23
Installation
► Mise
en fonctionnement opérationnel chez
les utilisateurs.
► Parfois restreint dans un premier temps à
des utilisateurs sélectionnés (« beta
testing »).
BTS IRIS 2
GL
24
Maintenance
► maintenance
corrective (ou curative)
 Dans le contrat
► maintenance
adaptative
 Mises à jour
► maintenance
perfective
 Nouvelles versions
BTS IRIS 2
GL
25
Activités transversales
► Spécification
► Documentation
► validation
et vérification
► Management
BTS IRIS 2
GL
26
Le modèle en V
BTS IRIS 2
GL
27
Principe du modèle en V
►
►
démarche reste linéaire
mais fait mieux apparaître :
 les produits intermédiaires à des niveaux d’abstraction et de
formalité différents
 et les procédures d’acceptation (validation et vérification) de ces
produits intermédiaires.
►
►
les activités de construction précèdent les activités de
validation et vérification
Mais l’acceptation est préparée dès la construction (flèches
de gauche à droite). Cela permet de mieux approfondir la
construction et de mieux planifier la ‘remontée’.
BTS IRIS 2
GL
28
Modèle incrémental
BTS IRIS 2
GL
29
Principe du modèle incrémental
►
Ces méthodes ne sont pas parfaites
 Dérives bureaucratiques (on passe plus de temps à faire des documents qu’à
coder…)
 Méthode bien sur le papier, mais dans la réalité, il est difficile de procéder de
manière linéaire
►
Modèle incrémental
 Le produit est délivré en plusieurs fois, de manière incrémentale, c’est à dire en le
complétant au fur et à mesure et en profitant de l’expérimentation opérationnelle
des incréments précédents.
►
Chaque incrément peut donner lieu à un cycle de vie classique plus ou
moins complet.
►
Les premiers incréments peuvent être
►
Le risque de cette approche est celui de la remise en cause du noyau.
 des maquettes (jetables s’il s’agit juste de comprendre les besoins des
utilisateurs)
 ou des prototypes (réutilisables pour passer au prochain incrément en les
complétant et/ou en optimisant leur implantation).
30
En réalité
Il n’y a pas de modèle idéal car tout dépend des
circonstances
► Le modèle en cascade ou en V est risqué pour les
développements innovants car les spécifications et la
conception risquent d’être inadéquats et souvent remis en
cause
► Le modèle incrémental est risqué car il ne donne pas
beaucoup de visibilité sur le processus complet
► Souvent, un même projet peut mêler différentes
approches, exemple :
►
 prototypage pour les sous-systèmes à haut risque
 cascade pour les sous systèmes bien connus et à faible risque
BTS IRIS 2
GL
31
La normalisation des processus
►
De nombreuses normes sont apparues dans les années 90 pour
évaluer les processus en fonction de normes de qualité
►
USA : le standard CMM du SEI (Software Engineering Institute du DoD
- Department Of Defense des USA)
►
UE : les normes ISO 9000 (9003) et ISO SPICE attestent qu’une
entreprise suit un processus orienté qualité
►
Qualité :
 Définition donnée par la Norme ISO 9000:2000 : Aptitude d'un ensemble
de caractéristiques intrinsèques à satisfaire des exigences
 capacité à atteindre les objectifs opérationnels visés
►
►
Les sociétés sont certifiées en fonction de leur respect de ces normes
Cela ne donne pas de garantie sur la qualité du produit lui même
BTS IRIS 2
GL
32
La spécification
BTS IRIS 2
GL
33
Définition
► Tout
produit complexe à construire doit d’abord
être spécifié
► Exemple : un pont de 30 mètres de long,
supportant au moins 1000 tonnes, construit en
béton, etc.
► Ces spécifications peuvent être considérées
comme un contrat entre un client et un producteur
► De
manière générale une spécification décrit les
caractéristiques attendues (le quoi)
BTS IRIS 2
GL
34
Spécification et cycle de vie
►
La spécification des besoins (contrat entre les futurs utilisateurs et les
concepteurs) concerne les caractéristiques attendues (exigences
fonctionnelles et non fonctionnelles)
►
La spécification d’un système (contrat entre les futurs utilisateurs et les
concepteurs) concerne la nature des fonctions offertes, les
comportements souhaités, les données nécessaires…
►
La spécification d’une architecture de système (contrat entre les
concepteurs et les réalisateurs) définit l’architecture en modules de
l’application à réaliser
►
La spécification technique d’un module, d’un programme, d’une
structure de données ou d’un type de données (contrat entre le
programmeur qui l’implante et les programmeurs qui l’utilisent) défini
la technologie à utiliser.
BTS IRIS 2
GL
35
conclusion
► Différentes
techniques et styles existent
► Souvent les techniques de spécifications se
complètent, en décrivant des vues
complémentaires d’un système
► Parler des techniques de spécification est comme
parler des langages de programmation : Il n’y a ni
langage ni technique idéale, ni langage ni
technique permettant de tout faire.
► L’informaticien
doit avoir une culture assez
étendue des diverses techniques comme des
divers langages
BTS IRIS 2
GL
36
La conception
BTS IRIS 2
GL
37
Définition
►
La conception propose une solution (le comment) au problème
spécifié lors de l’analyse :
 architecture de l’application (architecture logicielle et architecture
physique)
 description détaillée des modules, des interfaces utilisateurs, des données
►
Elle donne lieu à un dossier de conception avec souvent une partie
destinée au client (présentation de la solution) et une partie pour les
réalisateurs (conception technique)
►
La conception de l’architecture logicielle, concerne la décomposition du
système en modules, avec la description abstraite de ce que chaque
module doit faire et la description des relations entre les modules
►
La description précise du contenu des modules relève de la phase de
conception détaillée
BTS IRIS 2
GL
38
Modules et relation
► Un
module est un composant d’une application,
contenant des définitions de données et/ou de
types de données et/ou de fonctions et constituant
un tout cohérent
► On
peut définir un module comme un fournisseur
de ressources ou de services
► Quand
on décompose un système en modules il
faut décrire précisément les relations entre ces
modules
BTS IRIS 2
GL
39
Démarches de conception
► Deux
(principales) démarches de conception :
 l'approche fonctionnelle
 l'approche à objets
► Dans
l'approche à objets, les modules principaux
correspondent aux objets concrets ou abstraits du
domaine de l'application
► Ce sont des entités autonomes qui collaborent
pour réaliser le système global
BTS IRIS 2
GL
40
Interface et encapsulation
►
Objectif : diviser un système en composants qui peuvent
être conçus indépendamment
►
la nature de la relation d'utilisation doit être explicitement
et précisément spécifiée : c’est son interface
La manière dont ces services sont réalisés ne doit pas
apparaitre : c’est son implémentation
►
►
On sépare ainsi :
 la vue abstraite d’un module : nécessaire par ses clients (le
‘contrat’ passé entre le module et ses clients)
 la vue de son implémentation.
BTS IRIS 2
GL
41
Interface et encapsulation
►
On peut programmer un module en ne connaissant que les
interfaces des autres modules
►
En pratique, en conception objet, l’interface décrit
principalement les objets du module, leurs attributs publics
et leurs méthodes publics
Le reste de l’information doit être caché (encapsulé) dans
l’implémentation.
► La partie encapsulée peut être modifiée, sans aucun
impact sur les modules clients à partir du moment où
l’interface ne change pas
►
BTS IRIS 2
GL
42
Autres aspects de la conception
►
D'autres aspects doivent être considérés par les
concepteurs:




►
►
conception des interfaces utilisateurs
conception des algorithmes
conception des bases de données
etc.
Les systèmes étant de plus en plus souvent distribués sur
un réseau, une phase de conception de la l'architecture
physique de l'application peut-être nécessaire
Les différents modules (présentation, logique applicative,
gestion des données…) sont répartis sur ces architectures
physiques
BTS IRIS 2
GL
43
La vérification
BTS IRIS 2
GL
44
Définition
►
Tous les produits du cycle de vie doivent être vérifiés (pas
seulement le code)
►
Le résultat de ces vérifications n’est pas nécessairement
binaire (acceptation ou rejet du produit), des défauts
peuvent être tolérés (correctifs, pack)
►
Il existe deux approches complémentaires de la
vérification:
 expérimenter le comportement de l’application (la tester) avec un
ensemble bien choisi de données (vérification dynamique)
 analyser les propriétés du système, sans exécution (vérification
statique)
BTS IRIS 2
GL
45
Vérification dynamique : les Tests
► Les
tests ont pour but de mettre en évidence les
erreurs
► se font à partir de jeux de tests (jeux d’essais)
► Le
programme est exécuté avec un jeu de tests
 Les résultats obtenus sont comparés aux résultats
attendus
► Les
tests peuvent prouver la présence d’erreurs
mais ne peuvent pas prouver leur absence
BTS IRIS 2
GL
46
Construction des jeux de tests
► Approche
aléatoire :
 Le jeu de tests est sélectionné au hasard sur le
domaine de définition des entrées
 Le domaine de définition déterminé à l’aide des
interfaces de la spécification ou du programme
► Pas
une bonne couverture de l’ensemble
des entrées
 Ne traite pas des cas limites ou exceptionnels
► efficacité
BTS IRIS 2
très variable
GL
47
Construction des jeux de tests
► Approche
fonctionnelle (boîte noire) :
 considère uniquement la spécification de ce que
doit faire le programme (sans considérer sa
structure interne)
 vérifier chaque fonctionnalité décrite dans la
spécification
► Avantage
: on peut écrire ces tests très tôt,
dès qu'on connaît la spécification
BTS IRIS 2
GL
48
Construction des jeux de tests
► Approche
structurelle (boîte blanche) :
 on tient compte de la structure interne du
module
 On peut s’appuyer sur différents critères pour
conduire le test (couverture des instructions,
graphe de contrôle, couverture des
conditions…)
BTS IRIS 2
GL
49
Types de tests
►
Test unitaires de programmes ou de modules :


►
Tests d’intégration



►
Après Tests unitaires
tester leur intégration progressive jusqu’au système complet
Test alpha : l’application est mise dans des conditions réelles d’utilisation, au sein de l’équipe de
développement (simulation de l’utilisateur final)
Test de réception


►
test d’un programme isolé ou d’un module
Pour tester un module, il faut simuler le comportement des modules appelés et simuler les
appels du module
effectué par l'acquéreur (avec la participation du fournisseur ) après installation d'un système
dans ses locaux
Test bêta : distribution du produit sur un groupe de clients avant la version définitive
Tests de non régression


suite à la modification d'un logiciel (ou d'un de ses constituants)
a pour but de montrer que les autres parties du logiciel n'ont pas été affectées par cette
modification
BTS IRIS 2
GL
50
Vérifications statiques
►
Techniques informelles
 activités réalisées par un groupe d’inspecteurs qui examinent un document
à la recherche d’erreurs
 Dans le cas de code, les participants peuvent ‘jouer à la machine’ (« code
walk-through »)
 Dans le cas de code ou de documents de conception, les participants
peuvent faire des « revues » ou « inspections » en s’aidant d’une liste des
défauts les plus courants
►
Techniques formelles
 prouver formellement la correction d’un programme
 Le programme est caractérisé par sa précondition (condition éventuelle à
respecter par les données du programme) et sa postcondition (condition
vraie à la fin du programme qui définit donc son objectif)
 Méthode de Hoare définit des assertions logiques intermédiaires
permettant de prouver la correction en remontant de la post-condition à la
pré-condition du programme
BTS IRIS 2
GL
51
Méthodes d’analyse
et de conception
BTS IRIS 2
GL
52
Définition
► propose
une démarche, distinguant les
étapes du développement dans le cycle de
vie du logiciel et exploitant au mieux les
principes fondamentaux : modularité,
réduction de la complexité, réutilisation,
abstraction, etc.,
► propose des formalismes (langages) et des
types de documents (modèles), qui facilitent
la communication, l’organisation et la
vérification
BTS IRIS 2
GL
53
Différentes méthodes
► méthodes
fonctionnelles de décomposition
hiérarchique (1ère génération) :
 application du principe diviser pour régner (problème ->
sous problèmes)
 SADT, SA-SD, ...
► méthodes
systémiques (2ème génération) :
 séparation données/traitements, niveaux conceptuels,
organisationnels, physiques
 MERISE, SSADM, ...
► méthodes
objets (3ème génération) :
 OMT, OOSE, OOM, UML, ...
BTS IRIS 2
GL
54
Principaux objectifs des méthodes
objets
► regrouper
l’analyse des données et des
traitements
► établir un couplage explicite entre les concepts du
monde réel et les composants exécutables
► faciliter la réutilisation
► simplifier les transformations entre le niveau
conceptuel et l’implantation
BTS IRIS 2
GL
55
Et UML dans tout ça ?
BTS IRIS 2
GL
56
Les vues d’UML
BTS IRIS 2
GL
57
Démarche naturelle
BTS IRIS 2
GL
58
Diagrammes et phases
► Analyse
des besoins : cas d’utilisation
► Analyse du système : diagrammes de
classes, de collaboration, d’activités
(enchaînement des cas)
► Conception : diagrammes de classes, de
séquences, d’activités (conception des
méthodes), d’états, de composants, de
déploiement.
BTS IRIS 2
GL
59
Outils, aspects organisationnels
et humains
BTS IRIS 2
GL
60
Grandes catégories
► les
outils dédiés à des tâches spécifiques
► les
ateliers de génie logiciel (AGL) :
► les
environnements intégrés, qui visent à
intègrent plusieurs outils supportant une
partie des activités du développement
supporter tout le développement (cycle de
vie et activités transversales)
BTS IRIS 2
GL
61
Les principaux outils
outils d’édition
► outils de programmation
► outils de vérification
► outils de gestion de version et de gestion de
► Les
configurations
► outils de gestion de projet et de productivité
individuelle ou collective
BTS IRIS 2
GL
62
Aspects organisationnels et humains
►
La gestion de projet inclut de nombreuses activités telles
que :






►
écriture des propositions de projets
estimation des coûts des projets
planification et l’ordonnancement des projets
suivi et l’évaluation des projets
Sélection et évaluation des personnels et l’organisation des équipes
rédaction des rapports de gestion
3 grands tâches :
 Organisation des équipes
 Planification
 Estimation des coûts
BTS IRIS 2
GL
63
Diagramme de GANTT
►
outil permettant de modéliser la planification de tâches nécessaires à la
réalisation d'un projet
facilité de lecture => utilisé par la quasi-totalité des chefs de projet dans tous
les secteurs
► permet de représenter graphiquement l'avancement du projet (mais également
un moyen de communication entre les différents acteurs d'un projet)
► facile à mettre en œuvre avec un simple tableur ou des outils spécialisés
►
►
Fait apparaître :
 Tâches
 Dates
►
Éléments supplémentaires :
 Tâches jalons
 Ressources
BTS IRIS 2
GL
64
Diagramme de GANTT
BTS IRIS 2
GL
65