IFT 2251 Génie Logiciel Le Processus (fin)

Présentation au sujet: "IFT 2251 Génie Logiciel Le Processus (fin)"— Transcription de la présentation:

1 IFT 2251 Génie Logiciel Le Processus (fin)
Hiver Petko Valtchev

2 Sommaire Logiciel, tentative de définition
Génie logiciel, aspects historiques La qualité des logiciels Le processus de production Concepts de base Nature du processus et phases Modèles de processus

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

4 Les Activités Les Activités constituant le Processus:
Acquisition des besoins Analyse Conception Implémentation Vérification et validation Maintenance Retrait + Gestion des ressources humaines et matérielles

5 Définitions « Processus: fournit un cadre pour le développement en apportant des réponses aux principales questions d’ordre 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 Définitions (suite) « Méthode: Décrit une manière d’aborder 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 Définitions (fin) « Outil: Support automatisé ou semi-automatisé pour
l’application d’une méthode ou d’un processus. » Pressman, 2001 Computer-Aided Software Engineering (CASE) Tool 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.

8 Sommaire Logiciel, tentative de définition
Génie logiciel, aspects historiques La qualité des logiciels Le processus de production Concepts de base Nature du processus et phases Modèles de processus

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

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

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

12 Les Phases, 3 3. Maintenance CHANGEMENT Réingénierie Pourquoi :
Corrections Adaptations Améliorations Modifications préventives Erreurs Évolution de l’environnement Nouveaux besoins Anticipation sur les conditions de fonctionnement et de maintenance Réingénierie

13 Activités de support Activités de support Suivi du projet
Révision formelle Contrôle de la qualité Documentation Gestion de la réutilisation Évaluation Gestion du risque etc. D C I

14 Le modèle proposé par SEI (Software Engineering Institute)
Maturité du Processus Le modèle proposé par SEI (Software Engineering Institute)                Primitif (Initial) Reproductible (Repeatable) Défini Bien géré (Managed) Optimisant

15 Sommaire Logiciel, tentative de définition
Génie logiciel, aspects historiques La qualité des logiciels Le processus de production Concepts de base Nature du processus et phases Modèles de processus

16 Le modèle classique de développement
Le Modèle en Cascade Le modèle classique de développement Ingénierie du système analyse conception code test

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

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

19 Les Activités Conception
Objectif : transformer la description du problème obtenu par l’analyse en une description (de plus en plus détaillée) de la solution, sans pour autant produire la solution elle-même. Démarche : La conception architecturale: 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. La conception détaillée: définition des détails concernant la réalisation de chaque composant: algorithmes, structures de données, etc.

20 Les Activités Implémentation
Objectif : Production du code des composants à partir de leurs conceptions détaillées. Démarche : 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 Les Activités Vérification (tests)
Objectif : S’assurer que le logiciel produit respecte les spécifications initiales. Démarche : Vérification de l’ensemble des descriptions produites tout au long du développement. Examens des artefacts du développement: preuves de correction tests dynamiques = choix d’une sous-ensemble représentatif des données possibles et exécution du logiciel avec ces données.

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

23 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 d’exprimer la totalité de ses besoin en une seule fois, d’habitude 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 Sommaire Le processus de production Concepts de base
Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés

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

26 Modèle par Prototypage
Démarche : Pour corriger les spécifications du logiciel au fur et à mesure, construction d’un prototype (maquette). Écouter le client Consulter/ réviser la maquette Faire tester la maquette par le client Une ou plusieurs itérations…

27 Les Prototypes Deux manières de construire des prototypes:
Approche classique «prototypage jetable » : Réalisation rapide d’un 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é ». Le système logiciel final ne contient pas d’éléments du prototype. Approche évolutive «prototypage incrémental» : Réalisation dès le début du cycle de vie d’un premier prototype (p1). Ajouts progressif de fonctionnalités supplémentaires (raffinements: p2,p3,…) jusqu’à l’obtention du prototype final pn(pn = système visé).

28 Le Modèle par Prototypage
Bilan  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. 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 Sommaire Le processus de production Concepts de base
Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés

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

31 Le Modèle RAD Cinq grandes phases :
Modélisation des fonctions d’affaires (business functions): Définition des fonctions du système (en termes d’entrées - sorties) et du flot des informations à être manipulées et transformées. Modélisation des données: Définition des structures de données qui vont accueillir les informations manipulées. Modélisation des processus: Définition des processus qui traitent les informations. Génération de l’application: Construction de l’application à partir des modèles produits auparavant. Utilisation d’outils de 4e génération (ex. CASE) pour la généation. Test et livraison de l’application.

32 Schéma RAD 60 - 90 jours équipe #1 équipe #3 équipe #2 modéliser
b u s i n e m o d l g a t p r c & v business modeling data process application generation test & turnover modéliser les fonctions d’affaires modéliser les données modéliser les processus générer l’application Rapid Application Development tester et livrer jours

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

34 Sommaire Le processus de production Concepts de base
Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèle incrémental Modèle en spirale Modèles avancés

35 Les Modèles Évolutifs CONSTAT
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 Afin de permettre un retour de la part du client (usager) plus tôt dans le processus global: 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. Un processus global itératif est utilisé permettant de passer plusieurs fois par les différentes phases du développement. Ex. Modèle par «prototypage incrémental» - une approche évolutive Modèle incrémental Modèle en spirale

36 … Le Modèle Incrémental Modèles par incrément:
le système est séparé en incréments qui sont constitués d’un 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 l’ordre, à un noyau développé au préalable (le plus souvent, l’incrément 1) version 1 (noyau) version 2 version finale Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus. Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents. Les noyau, les incréments ainsi que leurs interactions doivent donc être faites globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement. i2 i1 i3 i1 i2 i1 … i4

37 Schéma Incrémental livraison du 1er incrément livraison du
incrément 1 (noyau) analyse concept. livraison du 1er incrément code test a n l y s i d e g c o t livraison du 2nd incrément incrément 2 a n l y s i d e g c o t livraison du 3eme incrément incrément 3 a n l y s i d e g c o t incrément 4 livraison du 4eme incrément temps

38 Le Modèle Incrémental, Bilan
Avantages chaque développement est en soi moins complexe, l’intégration des incréments se fait de manière progressive, possibilité (et non obligation!) d’une livraison et de mise en service après le développement de chaque incrément, permet une meilleure gestion de l’ensemble 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. Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus. Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents. Les noyau, les incréments ainsi que leurs interactions doivent donc être faites globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.

39 Sommaire Le processus de production Concepts de base
Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèle incrémental Modèle en spirale Modèles avancés

40 Le Modèle en Spirale CONSTAT
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 L’inévitable remise en cause des résultats d’un processus partiel est explicitée sous forme d’une spirale dans le modèle du même nom. Projet global, divisé en un ensemble de sous-projets réalisés en séquence. Sous-projet = un circuit de la spirale de développement (1 ou + tours). Chaque tour de la spirale traverse six régions d’activités. Région d’activité = ensemble de tâches spécifiques à réaliser. Chaque tour de la spirale doit produire ses propres résultats: un document de spécification, un prototype initial, une version améliorée du prototype, etc.

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

42 Le Modèle Incrémental, Bilan
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 L’analyse des risques étant, elle aussi, « évolutive », cela risque d’inquiéter le client. Modèle moins connu que les modèles en cascade et par prototypage. Moins de recul, donc difficile d’en évaluer l’efficacité. Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus. Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents. Les noyau, les incréments ainsi que leurs interactions doivent donc être faites globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.

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

44 Le Modèle par Composants
Processus de développement similaire à celui en spirale mais dans lequel l’activité d’ingénierie a une forme particulière. Ingénierie = conception de l’application à partir de composants logiciels prêts à l’emploi (disponibles sous forme de librairies commerciales) Identification des composants candidats. Chercher composants dans les librairies. Si disponible, extraire les composants. Sinon, les construire soi-même et les ajouter à la librairie. Intégrer les composants à la nième version du système. Certains Ateliers de génie logiciel offrent l’environnement nécessaire pour ce type de processus.

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

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