La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus (fin) Hiver 2002 Petko Valtchev.

Présentations similaires


Présentation au sujet: "© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus (fin) Hiver 2002 Petko Valtchev."— Transcription de la présentation:

1 © Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Le Processus (fin) Hiver 2002 Petko Valtchev

2 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Logiciel, tentative de définition l Génie logiciel, aspects historiques l La qualité des logiciels l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus

3 © Petko ValtchevUniversité de Montréal Janvier Bases Les Questions Questions fondamentales: l Quel est le problème à résoudre? l Quelles sont les fonctionnalités désirées du logiciel? l Comment sera conçu et construit le logiciel? l Quelle technique sera utilisée dans la détection des erreurs (bogues) dans le logiciel l Comment le logiciel sera-t-il maintenu (corrigé et/ou amélioré)?

4 © Petko ValtchevUniversité de Montréal Janvier Bases Les Activités Les Activités constituant le Processus: 1. Acquisition des besoins 2. Analyse 3. Conception 4. Implémentation 5. Vérification et validation 6. Maintenance 7. Retrait l + Gestion des ressources humaines et matérielles

5 © Petko ValtchevUniversité de Montréal Janvier Bases Définitions « Processus: fournit un cadre pour le développement en apportant des réponses aux principales questions dordre organisationnel. » Pressman, 2001 Comment gérer les activités du projet? Comment utiliser les ressources techniques? Comment produire les différents documents (pour décrire modèles, données, avancement du projet, etc.)? Comment fixer les objectifs du projet à long, moyen et court terme? Comment gérer les éventuels changements? Ex. Rational Unified Process, Extreme Programming, etc.

6 © Petko ValtchevUniversité de Montréal Janvier Bases Définitions ( suite ) « Méthode : Décrit une manière daborder les différentes activités (souvent un sous-ensemble) du développement du logiciel en proposant des principes, des théories, des formalismes, des techniques de modélisation et de spécification pour réaliser ces activités. » Pressman, 2001 Ex. OMT, OOA/OOD, Objectory, etc.

7 © Petko ValtchevUniversité de Montréal Janvier Bases Définitions ( fin ) « Outil : Support automatisé ou semi-automatisé pour lapplication dune méthode ou dun processus. » Pressman, 2001 Atelier de Génie Logiciel: Ensemble cohérent d'outils informatiques formant un environnement d'aide à la conception, au développement et à la mise au point de logiciels d'application spécialisés. Computer-Aided Software Engineering (CASE) Tool

8 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Logiciel, tentative de définition l Génie logiciel, aspects historiques l La qualité des logiciels l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus

9 © Petko ValtchevUniversité de Montréal Janvier Bases status quo définition du problème technique développement solution intégration de la Résolution itérative de problèmes Le Processus Logiciel Ré-évaluation de la situation: Phase 2 Phase 1 Phase 3

10 © Petko ValtchevUniversité de Montréal Janvier Bases Les Phases, 1 l Objectifs l Besoins : Comprendre le problème l Spécification : Identifier les caractéristiques requis du système l Pourquoi : répondre à l'évolution des matériels, des systèmes, des langages de programmation, et surtout la complexité toujours croissantes des logiciels. 1. Définition Quel public (usagers)? Quelles fonctionnalités? Quelles propriétés? Quelles performances? Quelles comportements? Quel type dinterfaces? QUOI

11 © Petko ValtchevUniversité de Montréal Janvier Bases Les Phases, 2 2. Developpement l Comment structurer linformation? l Comment implémenter la conception logicielle? l Comment tester le logiciel? COMMENT l Objectif l Traduction progressive des spécifications (Le Problème) vers une description du système (La Solution) sans pour autant produire ce système. l Pourquoi : réduire la complexité du passage entre la description du problème et sa solution.

12 © Petko ValtchevUniversité de Montréal Janvier Bases Les Phases, 3 3. Maintenance l Corrections l Adaptations l Améliorations l Modifications préventives CHANGEMENT Pourquoi : l Erreurs l Évolution de lenvironnement l Nouveaux besoins l Anticipation sur les conditions de fonctionnement et de maintenance Réingénierie

13 © Petko ValtchevUniversité de Montréal Janvier Bases Activités de support I C D 1. Suivi du projet 2. Révision formelle 3. Contrôle de la qualité 4. Documentation 5. Gestion de la réutilisation 6. Évaluation 7. Gestion du risque etc. 1. Suivi du projet 2. Révision formelle 3. Contrôle de la qualité 4. Documentation 5. Gestion de la réutilisation 6. Évaluation 7. Gestion du risque etc.

14 © Petko ValtchevUniversité de Montréal Janvier Bases Maturité du Processus Primitif (Initial) Reproductible (Repeatable) Défini Bien géré (Managed) Optimisant Le modèle proposé par SEI (Software Engineering Institute)

15 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Logiciel, tentative de définition l Génie logiciel, aspects historiques l La qualité des logiciels l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus

16 © Petko ValtchevUniversité de Montréal Janvier Bases Le Modèle en Cascade analyse conceptioncodetest Ingénierie du système Le modèle classique de développement

17 © Petko ValtchevUniversité de Montréal Janvier Bases La Cascade Ingénierie du système - phase préliminaire Système (au sens large) = configuration de composantes l matérielles, l logicielles (BD, réseaux, passerelles Web, etc.), l humaines (usagers du système). dans laquelle devra sintégrer le logiciel à développer. Besoins - clarification des besoins relatifs à tous les éléments du système Vue densemble sur les besoins.

18 © Petko ValtchevUniversité de Montréal Janvier Bases Les Activités Analyse des besoins l Objectif : éviter de produire un logiciel inadéquat. l Démarche : l Étudier les besoins et les spécifier de la manière la plus claire possible. l Les éléments pertinents incluent: l le domaine dapplication, l l'environnement du futur système, l le rôle escompté du système, l les ressources disponibles et requises, l les contraintes d'utilisation, l les performances attendues.

19 © Petko ValtchevUniversité de Montréal Janvier Bases Les Activités Conception l Objectif : transformer la description du problème obtenu par lanalyse en une description (de plus en plus détaillée) de la solution, sans pour autant produire la solution elle-même. l Démarche : l La conception architecturale: l décomposition du système logiciel en sous-systèmes (composants) de taille et complexité inférieures; chaque sous- système est décrit par ces fonctions et les interfaces avec le reste du système. l La conception détaillée: l définition des détails concernant la réalisation de chaque composant: algorithmes, structures de données, etc.

20 © Petko ValtchevUniversité de Montréal Janvier Bases Les Activités Implémentation l Objectif : Production du code des composants à partir de leurs conceptions détaillées. l Démarche : l Si la conception est de bonne qualité, la génération se fait de manière directe et peut être automatisée pour une grande partie.

21 © Petko ValtchevUniversité de Montréal Janvier Bases Les Activités Vérification (tests) l Objectif : Sassurer que le logiciel produit respecte les spécifications initiales. l Démarche : l Vérification de lensemble des descriptions produites tout au long du développement. l Examens des artefacts du développement: l preuves de correction l tests dynamiques = choix dune sous-ensemble représentatif des données possibles et exécution du logiciel avec ces données.

22 © Petko ValtchevUniversité de Montréal Janvier Bases Les Activités Maintenance l Objectif : Sassurer que le logiciel livré continue de répondre aux besoins du client qui peuvent évoluer dans la période post-livraison. l Démarche : l Correction derreurs, l Adaptations l Ex. nouvelle plate-forme, l Améliorations l Ex. service accessible via le Web. l Changements au logiciel = nécessité de traverser une ou plusieurs (voire toutes) les phases du développement en cascade.

23 © Petko ValtchevUniversité de Montréal Janvier Bases Le Modèle en Cascade Bilan Les projets réels suivent rarement un déroulement purement séquentiel, souvent il y a des retours en arrière. Le client est rarement capable dexprimer la totalité de ses besoin en une seule fois, dhabitude il prend conscience de certains besoins au cours du projet. Le client doit être patient car il ne verra une version exécutable de son système que vers la fin du processus de développement. Problème de validation important!!!

24 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus l Modèle en cascade l Modèle par prototypage l « Rapid Application Development » l Modèles évolutifs l Modèles avancés

25 © Petko ValtchevUniversité de Montréal Janvier Bases Développement de Prototypes CLIENT INGENIEUR DU LOGICIEL Connaissances du domaine Jargon technique Connaissances en logiciel Langages, notations Indécis, opinion variable Besoins ambigus, incomplets Spécifications ésotériques Document des besoins Incomplet Imprécis

26 © Petko ValtchevUniversité de Montréal Janvier Bases Modèle par Prototypage Consulter/ réviser la maquette Écouter le client Faire tester la maquette par le client Une ou plusieurs itérations… Démarche : Pour corriger les spécifications du logiciel au fur et à mesure, construction dun prototype (maquette).

27 © Petko ValtchevUniversité de Montréal Janvier Bases Les Prototypes Deux manières de construire des prototypes: l Approche classique «prototypage jetable » : l Réalisation rapide dun prototype dès le début du cycle de vie. Le prototype sert alors de référence pour la définition et la validation des spécifications, puis il est « jeté ». l Le système logiciel final ne contient pas déléments du prototype. l Approche évolutive «prototypage incrémental» : l Réalisation dès le début du cycle de vie dun premier prototype (p 1 ). Ajouts progressif de fonctionnalités supplémentaires (raffinements: p 2,p 3,…) jusquà lobtention du prototype final p n (p n = système visé).

28 © Petko ValtchevUniversité de Montréal Janvier Bases Le Modèle par Prototypage Bilan l Le client a tendance à vouloir faire du simple prototype son produit final. Il ignore que souvent la façade cache une conception très approximative, voire inexistante. l Les choix des développeurs pris lors du prototypage, et donc sous fortes contraintes temporelles, ont des fortes chances de devenir de choix définitifs. On oublie que ces choix nétaient peut-être pas les meilleurs du point de vue de la qualité.

29 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus l Modèle en cascade l Modèle par prototypage l « Rapid Application Development » l Modèles évolutifs l Modèles avancés

30 © Petko ValtchevUniversité de Montréal Janvier Bases Rapid Application Development l Cycle de développement très court = 60 à 90 jours. l Adaptation « haute vitesse » du modèle en cascade. l Conception à base de composants. l Pré-conditions essentielles: 1. besoins logiciels bien saisis, 2. portée du projet bien définie, 3. projet facilement « modularisable ».

31 © Petko ValtchevUniversité de Montréal Janvier Bases Le Modèle RAD Cinq grandes phases : 1. Modélisation des fonctions daffaires (business functions): Définition des fonctions du système (en termes dentrées - sorties) et du flot des informations à être manipulées et transformées. 2. Modélisation des données: Définition des structures de données qui vont accueillir les informations manipulées. 3. Modélisation des processus: Définition des processus qui traitent les informations. 4. Génération de lapplication: Construction de lapplication à partir des modèles produits auparavant. Utilisation doutils de 4e génération (ex. CASE) pour la généation. 5. Test et livraison de lapplication.

32 © Petko ValtchevUniversité de Montréal Janvier Bases Schéma RAD modéliser les fonctions daffaires business modeling data modeling process modeling application generation test & turnover business modeling data modeling process modeling application generation testing & turnover équipe #1 équipe #2 équipe # jours Rapid Application Development modéliser les données modéliser les processus générer lapplication tester et livrer

33 © Petko ValtchevUniversité de Montréal Janvier Bases Le Modèle RAD Bilan l Nécessite des ressources humaines importantes: l Afin de pouvoir composer le nombre suffisant déquipes. l Exige lengagement constant du client sous péril de faire échouer le projet. l Supporte mal des niveaux de risque élevés: l Le modèle RAD nest pas approprié lorsque des facteurs de risque importants sont présents car ceux-ci peuvent provoquer de retards non-négligeables dans le travail dune des équipes. l Ex. utilisation de nouvelles technologies l Portée limitée: l Le modèle RAD ne se prête pas au développement de certains types de logiciel

34 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus l Modèle en cascade l Modèle par prototypage l « Rapid Application Development » l Modèles évolutifs –Modèle incrémental –Modèle en spirale l Modèles avancés

35 © Petko ValtchevUniversité de Montréal Janvier Bases Les Modèles Évolutifs l Afin de permettre un retour de la part du client (usager) plus tôt dans le processus global: l De versions successives du système sont livrées, avec chaque prochaine version possédant des fonctionnalités de plus en plus complètes vis à vis des besoins du client. l Un processus global itératif est utilisé permettant de passer plusieurs fois par les différentes phases du développement. l Ex. l Modèle par «prototypage incrémental» - une approche évolutive l Modèle incrémental l Modèle en spirale Au sein des modèles vus précédemment: Le système est divisé en composants séparés qui sont développés pour être intégrés à la fin (juste avant les tests et la livraison). CONSTAT

36 © Petko ValtchevUniversité de Montréal Janvier Bases Modèles par incrément : le système est séparé en incréments qui sont constitués dun ensemble de composants, chaque incrément développé selon un modèle de processus complet: souvent un modèle en cascade, à la fin de leur cycle de vie (indépendante) des incréments viennent s'intégrer, dans lordre, à un noyau développé au préalable (le plus souvent, lincrément 1) i1 i3i2 i1 i2 … i4 version 1 (noyau) version 2version finale Le Modèle Incrémental

37 © Petko ValtchevUniversité de Montréal Janvier Bases analysis designcodetest analysis designcodetest analysis designcodetest incrément 2 incrément 1 (noyau) livraison du 1er incrément temps analyseconcept. codetest incrément 3 incrément 4 livraison du 2nd incrément livraison du 3eme incrément livraison du 4eme incrément Schéma Incrémental

38 © Petko ValtchevUniversité de Montréal Janvier Bases Avantages chaque développement est en soi moins complexe, lintégration des incréments se fait de manière progressive, possibilité (et non obligation!) dune livraison et de mise en service après le développement de chaque incrément, permet une meilleure gestion de lensemble des ressources allouées au projet: du temps réduit par rapport au modèle en cascade du coût en effort humain réduit par rapport au RAD: recouvrement entre processus pour les incréments, mis pas de recouvrement entre phases. Risques devoir remettre en cause le noyau ou les incréments précédents, une tâche ardue, ne pas pouvoir intégrer de nouveaux incréments. Le Modèle Incrémental, Bilan

39 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus l Modèle en cascade l Modèle par prototypage l « Rapid Application Development » l Modèles évolutifs –Modèle incrémental –Modèle en spirale l Modèles avancés

40 © Petko ValtchevUniversité de Montréal Janvier Bases Le Modèle en Spirale Linévitable remise en cause des résultats dun processus partiel est explicitée sous forme dune spirale dans le modèle du même nom. l Projet global, divisé en un ensemble de sous-projets réalisés en séquence. l Sous-projet = un circuit de la spirale de développement (1 ou + tours). l Chaque tour de la spirale traverse six régions dactivités. l Région dactivité = ensemble de tâches spécifiques à réaliser. Chaque tour de la spirale doit produire ses propres résultats: l un document de spécification, l un prototype initial, l une version améliorée du prototype, etc. De facteurs comme lévolution des besoins ou leur remise en cause après la livraison, lesquels entraînent un passage supplémentaire par toutes les phases du cycle de vie, ne sont pas reflétés par les modèles vus précédemment. CONSTAT

41 © Petko ValtchevUniversité de Montréal Janvier Bases Planification Discussion avec le Client Évaluation par le Client Construction & Livraison Ingénierie Analyse des risques Les itérations sont rendues explicites! Le Modèle en Spirale, Schéma

42 © Petko ValtchevUniversité de Montréal Janvier Bases Avantages Combine les avantages des modèle en cascade, par prototypage et incrémental. De façon générale, le modèle est réaliste et bien adapté pour le développement de systèmes de taille large. Risques Lanalyse des risques étant, elle aussi, « évolutive », cela risque dinquiéter le client. Modèle moins connu que les modèles en cascade et par prototypage. Moins de recul, donc difficile den évaluer lefficacité. Le Modèle Incrémental, Bilan

43 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus l Modèle en cascade l Modèle par prototypage l « Rapid Application Development » l Modèles évolutifs l Modèles avancés –Modèle de développement par composants –Modèles centrés sur des méthodes formelles

44 © Petko ValtchevUniversité de Montréal Janvier Bases Le Modèle par Composants l Processus de développement similaire à celui en spirale mais dans lequel lactivité dingénierie a une forme particulière. l Ingénierie = conception de lapplication à partir de composants logiciels prêts à lemploi (disponibles sous forme de librairies commerciales) 1. Identification des composants candidats. 2. Chercher composants dans les librairies. 3. Si disponible, extraire les composants. Sinon, les construire 4. soi-même et les ajouter à la librairie. 5. Intégrer les composants à la nième version du système. l Certains Ateliers de génie logiciel offrent lenvironnement nécessaire pour ce type de processus.

45 © Petko ValtchevUniversité de Montréal Janvier Bases Sommaire l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus l Modèle en cascade l Modèle par prototypage l « Rapid Application Development » l Modèles évolutifs l Modèles avancés –Modèle de développement par composants –Modèles centrés sur des méthodes formelles

46 © Petko ValtchevUniversité de Montréal Janvier Bases Le Modèle « Méthodes Formelles » Plusieurs outils CASE disponibles pour les principales méthodes. l Ex. l VDM, B, Z, l CTL, Lotos, etc. l Avantages = Détection précise l dambiguïtés et derreurs, l de problèmes de complétude et de cohérence. l Inconvénients: Coûteux en temps, expertise requise, moyen inadéquat pour communiquer avec le client. Notations mathématiques et techniques danalyse rigoureuses pour la spécification, la conception et la vérification de systèmes informatiques.


Télécharger ppt "© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus (fin) Hiver 2002 Petko Valtchev."

Présentations similaires


Annonces Google