2003 (revisé 2008)SEG2501 - Chapitre 11 Chapitre 1 “The Systems Engineering Context” Le contexte du génie de systèmes.

Slides:



Advertisements
Présentations similaires
Analyse et définition des besoins
Advertisements

LA QUALITE LOGICIELLE Plan du cours La modélisation d’activité 1 h ½
Les Systèmes d’Information Financière Atelier conjoint ACBF / Banque Mondiale / AFRITAC de l’Ouest Gérer l’application dans le temps, sur les plans fonctionnel,
Module N° 7 – Introduction au SMS
Eléments de Génie Logiciel
Contrôle des processus : Introduction au Contrôle Qualité
Processus d'expression du besoin
L'installation et la diffusion 1 LInstallation et la Diffusion.
La Recette La recette.
La Gestion de la Configuration
Le processus unifié UML est un langage de modélisation et n ’impose pas de démarche de développement Le processus unifié : méthodologie de développement.
UML - Présentation.
1 B Système Enjeux et principes Cours DESS Nantes 04 Décembre 2002 Didier ESSAME.
Phase de préparation des itérations Produit Story 11 Release1 Story 1mStory 21 Release2 Story 2m… …
UML (Unified Modeling Langage)
Rational Unified Process (RUP)
Les Ateliers de Génie Logiciel
La revue de projet.
Conférence sur les perspectives dapprovisionnement Mark Seely Directeur principal Maritime.
MIAGE MASTER 1 Cours de gestion de projet
Introduction au Génie Logiciel
Algorithmique et Programmation
Parcours de formation SIN-7
Tests unitaires et fonctionnels
Algorithmique et Programmation
Etude globale de système.
Techniques de test Boulanger Jean-Louis.
IGL301 - Spécification et vérification des exgiences 1 Chapitre 1 Introduction (ref : Bray chapitre 1)
IGL301 - Spécification et vérification des exgiences 1 Chapitre 2 Le processus dingénierie des exigences (ref : Bray chapitre 2)
TESTING BUSINESS PROCESSES
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Notions de Base Hiver 2002 Petko Valtchev.
La plateforme Multicom
Hiver 2011SEG Chapître 11 Chapître 1 (partie 1) Revision de cours précédants Sujet 1: Le processus de développement de logiciel.
Les étapes du cycle de développement du génie logiciel
Sensibilisation a la modelisation
Ingénierie Système en SysML appliquée à la rédaction du cahier des charges Y. Le Gallou Séminaire académique STI2D - Calais – 1er avril 2014.
Cycle de vie: « Waterfall » GEF492A Automne 2014 [HvV § 3.1]
Les principes de la modélisation de systèmes
Supports de formation au SQ Unifié
Institut Supérieur des Sciences Appliquées et de Technologie Sousse
GENIE LOGICIEL
Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville«Software Engineering» de Ian Sommerville B.Shishedjiev.
© Petko ValtchevUniversité de Montréal Février IFT 2251 Génie Logiciel Conception Hiver 2002 Petko Valtchev.
Le système informatique et le système d’information
Les épreuves du BTS Systèmes photoniques
Introduction au Génie Logiciel
Réalisé par: BOUMSISS Hassnae OUED Zahra TABIT Youssef EZZIANI Hamza
Extrait du Referentiel BTS Systèmes numériques Options : Informatique et réseaux et Électronique et communication S1 à S9 Définition des savoirs et savoir-faire.
Initiation à la conception des systèmes d'informations
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
ISO 9001:2000 DOCUMENTATION DU SYSTEME QUALITE
MOCK.
Année 2006 – 2007 ENSEA © Emeric Rollin
Hiver 2004SEG2501 Chapître 41 Chapître 4 SDL – structure d’un système et son comportement.
Principes et définitions
Chapitre 2 Rappels objet et Présentation des diagrammes UML
Chapitre 2 Rappels objet et Présentation des diagrammes UML
Principe de mise en position, isostatisme et côtes fabriquées
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Le Processus Hiver 2002 Petko Valtchev.
Conférence 2TUP Stéphane Barthon 03/12/
développeur informatique
Document de spécification d’exigences Normes IEEE et 29148:2011
ISO 9001:2000 Interprétation Article 7 Réalisation du produit
Conception des IHM.
Modèles de cycle de vie et processus de génie
LES OUTILS DE GESTION DE PROJET
PRÉSENTATION AGL LES TESTS LOGICIELS LES TEST LOGICIELS 1 Mickael BETTINELLI Brandon OZIOL Gaétan PHILIPPE Simon LUAIRE.
Les bases de données Séance 2 Méthodologies d’analyse.
Planning Process « t’as un plan pour ce soir ? » Tony Carnal Altran.
4 1 : A quoi sert la gestion de projet
Transcription de la présentation:

2003 (revisé 2008)SEG Chapitre 11 Chapitre 1 “The Systems Engineering Context” Le contexte du génie de systèmes

2003 (revisé 2008)SEG Chapitre 12 Le génie de systèmes, c’est quoi? C’est un approche interdisciplinaire qui permet la réalisation réussie de systèmes. On se concentre, tôt dans le développement, à déterminer les besoins des clients et la fonctionnalité requise, les besoins de documentation, et ensuite on procède à la conception, la synthèse du système et la validation, tout en considérant le problème au complet, soit: –Les opérations –La performance –Les tests –L’installation –Les coûts et la cédule –La formation et le support –L’élimination (fin de vie)

2003 (revisé 2008)SEG Chapitre 13 Le contexte du génie de systèmes Aspect historique: Génie logiciel (terme défini en 1968) Les sous-sections du chapître : Le problème Les principes La gestion de l’évolution du système

2003 (revisé 2008)SEG Chapitre : Le problème Sous-sous sections: Symptômes Raisons Qualité L’approche traditionelle

2003 (revisé 2008)SEG Chapitre 15 Symptômes La qualité et le coût du logiciel laisse à désirer –Livraison en retard –Coût plus grand que prévu –Sans donner la satisfaction anticipée aux usagers Types d’erreurs: –Planifier une fonctionnalité en désaccord avec le but du système –Définir une fonctionnalité inconsistante à l’interne –Implanter la fonctionnalité différente que planifié

2003 (revisé 2008)SEG Chapitre 16 Raisons Il est difficile de comprendre le but du système assez bien pour planifier sa fonctionnalité au début et donner complète satisfaction aux usagers. La complexité du système et de son comportement dynamique est trop grande. La nature de visibilité du produit rend l’effort de développement et de maintenance difficile à comprendre et à contrôler. Il y a un manque de composantes éprouvées qui peuvent servir comme modules réutilisables. Il y a trop de re-développement.

2003 (revisé 2008)SEG Chapitre 17 Concepts Usagers: ceux qui interagissent directement avec le système et utilisent son service pour quelque but. Propriétaires: des personnes qui seront les propriétaires du système ou qui seront responsables pour son opération pendant une partie de son cycle de vie. Sujets: connus au système, mais n’interagissent pas directement avec lui. Développeurs: les gens qui développent le système.

2003 (revisé 2008)SEG Chapitre 18 Qualité du système La qualité du système est son habilité de satisfaire les besoins et attentes des usagers et propriétaires. La qualité dépend d’une bonne communication (précise et sans ambiguïté) pendant le développement du système (voir diagramme).

2003 (revisé 2008)SEG Chapitre 19 Qualité du système

2003 (revisé 2008)SEG Chapitre 110 Le problème de communication

2003 (revisé 2008)SEG Chapitre 111 Points essentiels du contrôle de qualité Pour assurer que tous les liens de communication et toutes les étapes de transformation fonctionnent comme prévus: –Le processus: Organisation du processus de développement en plusieurs étapes pendant lesquelles des documents spécifiques sont créés et certaines procédures de validation sont faites. –Contenu technique: Le contenu des document variés, e.g. spécification des exigences, du système, plans de tests, etc.

2003 (revisé 2008)SEG Chapitre 112 L’approche traditionnelle (un niveau de description: le code source)

2003 (revisé 2008)SEG Chapitre : Les principes du génie de systèmes Sous-sous sections: Methodologie Descriptions Les descriptions principales

2003 (revisé 2008)SEG Chapitre 114 Objectif d’une méthodologie L’activité de génie de systèmes est réalisée par un système qui consiste de personnes et d’outils, et qui est appelé “project system” ou organisation de réalisation. Le résultat final de cette activité est le système cible et sa documentation, sous forme de descriptions. Le rôle d’une méthodologie est d’aider l’organisation de réalisation à faire un système cible de qualité la première fois, chaque fois, en temps, et à l’intérieur du budget.

2003 (revisé 2008)SEG Chapitre 115 Le rôle d’une méthodologie

2003 (revisé 2008)SEG Chapitre 116 Une méthodologie est... Une méthodologie définit un ensemble de descriptions et une des méthodes associés, chaque méthode étant une façon systématique d’obtenir un certain résultat. Chaque méthode fournit des règles pour la structuration et l’utilisation de descriptions dans des notations données.

2003 (revisé 2008)SEG Chapitre 117 Descriptions (représentations symboliques d’un sujet d’intérêt) Propriétés désirées: facile à créer facile à interpréter, comprendre se prête au raisonnement, à la vérification

2003 (revisé 2008)SEG Chapitre 118 Les Descriptions principales (I)

2003 (revisé 2008)SEG Chapitre 119 Les Descriptions principales (II) Pourquoi on a besoin du système ? –Spécification des exigences Quelles devraient être ses fonctionnalités ? –Conception fonctionelle Comment devrait-il être implanté ? –Conception d’implantation Dans le cas de logiciel: l’implantation –code source et documentation

2003 (revisé 2008)SEG Chapitre 120 Spécification des exigences Clarifier le besoin des usagers et des propriétaires Documenter les besoins sous forme d’exigences Les exigences devraient être clairement comprises par les usagers, propriétaires et développeurs Mettre l’emphase sur le but et le rôle du système Deux catégories: exigences fonctionnelles et non fonctionnelles

2003 (revisé 2008)SEG Chapitre 121 Conception fonctionnelle Définir la fonctionnalité du système aussi clairement et complètement que possible

2003 (revisé 2008)SEG Chapitre 122 Conception de l’implémentation Emphase sur la solution technique, basée sur la conception fonctionnelle et les exigences non fonctionnelles Définir l’architecture du système La conception de l’implantation fournit la base pour l’implantation du système concret consistant de matériel et de logiciel Explique comment le système sera réalisé

2003 (revisé 2008)SEG Chapitre 123 Qualité du processus C’est la conformité du système avec la spécification des exigences Différence: qualité de système <> qualité du processus “V&V” = “validation and verification” = assurance de qualité –Définition de termes: Valider (to validate: do we build the right system?) Vérifier (to verify: do we build the system right?) –Qualité du processus, c’est seulement de la vérification

2003 (revisé 2008)SEG Chapitre 124 Assurance de qualité

2003 (revisé 2008)SEG Chapitre 125 Les bénéfices du génie de systèmes (I) L’assurance de qualité peut être faite en étapes pendant tout le développement Les besoins des usagers et propriétaires sont mis au point La fonctionalité du système peut être validée tôt dans le cycle de développement Le nombre d’aspects à considérer dans chaque étape est réduit Le coût de la correction d’erreurs est réduit parce que les erreurs sont détectées plus tôt

2003 (revisé 2008)SEG Chapitre 126 Les bénéfices du génie de systèmes (II) Les différentes descriptions correspondent à des savoir d’experts différents La notation (langage) peut être sélectionnée en fonction du but de chaque description Une description peut être modifié sans affecter les autres descriptions (cela n’est pas complètement vrai, puisque on veut les garder consistantes entre elles – “traceability” ) La conception fonctionnelle documente le système comme un tout, indépendemment de la technologie d’implantation pour les différentes parties du système Chaque étape fournit la fondation pour l’étape suivante

2003 (revisé 2008)SEG Chapitre : La gestion de l’évolution du système Le modèle de référence (processus de développement en cascades) Documents

2003 (revisé 2008)SEG Chapitre 128 Processus de développement en cascades

2003 (revisé 2008)SEG Chapitre 129 Quelques concepts Activité: la production de résultats Phase: période de temps pendant que des activités spécifiques sont faites et des résultats sont obtenus “Baseline“ : résultat d’une phase, qui sert comme base pour le travail subséquent “ Milestone“ : transition de phase

2003 (revisé 2008)SEG Chapitre 130 Milestones and Baselines

2003 (revisé 2008)SEG Chapitre 131 Maintenance

2003 (revisé 2008)SEG Chapitre 132 Modèle d’activités

2003 (revisé 2008)SEG Chapitre 133 Documents