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

Présentation au sujet: "2003 (revisé 2008)SEG2501 - Chapitre 11 Chapitre 1 “The Systems Engineering Context” Le contexte du génie de systèmes."— Transcription de la présentation:

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

2 2003 (revisé 2008)SEG2501 - 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)

3 2003 (revisé 2008)SEG2501 - 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

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

5 2003 (revisé 2008)SEG2501 - 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é

6 2003 (revisé 2008)SEG2501 - 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.

7 2003 (revisé 2008)SEG2501 - 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.

8 2003 (revisé 2008)SEG2501 - 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).

9 2003 (revisé 2008)SEG2501 - Chapitre 19 Qualité du système

10 2003 (revisé 2008)SEG2501 - Chapitre 110 Le problème de communication

11 2003 (revisé 2008)SEG2501 - 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.

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

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

14 2003 (revisé 2008)SEG2501 - 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.

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

16 2003 (revisé 2008)SEG2501 - 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.

17 2003 (revisé 2008)SEG2501 - 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

18 2003 (revisé 2008)SEG2501 - Chapitre 118 Les Descriptions principales (I)

19 2003 (revisé 2008)SEG2501 - 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

20 2003 (revisé 2008)SEG2501 - 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

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

22 2003 (revisé 2008)SEG2501 - 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é

23 2003 (revisé 2008)SEG2501 - 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

24 2003 (revisé 2008)SEG2501 - Chapitre 124 Assurance de qualité

25 2003 (revisé 2008)SEG2501 - 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

26 2003 (revisé 2008)SEG2501 - 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

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

28 2003 (revisé 2008)SEG2501 - Chapitre 128 Processus de développement en cascades

29 2003 (revisé 2008)SEG2501 - 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

30 2003 (revisé 2008)SEG2501 - Chapitre 130 Milestones and Baselines

31 2003 (revisé 2008)SEG2501 - Chapitre 131 Maintenance

32 2003 (revisé 2008)SEG2501 - Chapitre 132 Modèle d’activités

33 2003 (revisé 2008)SEG2501 - Chapitre 133 Documents