1 Gestion de projet 2- Introduction au Génie Logiciel Préparé par : Gérard Battarel Pour : lUniversité René Descartes Octobre 2006 © Copyright 2004 Gérard.

Présentation au sujet: "1 Gestion de projet 2- Introduction au Génie Logiciel Préparé par : Gérard Battarel Pour : lUniversité René Descartes Octobre 2006 © Copyright 2004 Gérard."— Transcription de la présentation:

1 1 Gestion de projet 2- Introduction au Génie Logiciel Préparé par : Gérard Battarel Pour : lUniversité René Descartes Octobre 2006 © Copyright 2004 Gérard Battarel - Reproduction interdite sans autorisation de lauteur

2 2 Objectifs Comprendre le rôle du génie logiciel Comprendre le rôle du génie logiciel Comprendre le cycle de base dun projet informatique Comprendre le cycle de base dun projet informatique Comprendre les limites de lapproche classique et aborder les méthodes « modernes » Comprendre les limites de lapproche classique et aborder les méthodes « modernes » Aborder quelques outils et méthodes Aborder quelques outils et méthodes

3 3 Les projets informatiques Projet informatique = Projet informatique = –Projet dont une partie au moins du produit résultant se compose de logiciels et/ou de matériels informatiques –Projet dont les services résultants consistent à faire fonctionner des logiciels et/ou des matériels informatiques Exemples : Exemples : –Centre dappels ? Maintenance dun système ?

4 4 Les projets informatiques Rappel de la complexité Rappel de la complexité –Nombre dacteurs et de compétences différents mis en œuvre –Complexité des besoins Logiciel « professionnel » Logiciel « professionnel » –Production efficace –Maintenance facile –Évolutivité (?) –Réutilisation du savoir-faire dans le cadre de lorganisation productrice –Caractéristiques non fonctionnelles

5 5 Variété des problèmes Prédominance des données (« gestion ») –Application bancaire (édition de relevés) –Data mining Prédominance des traitements (« scientifique ») –Calculs de primes dassurances –Calculs de structures (résistance des matériaux) Prédominance des événements (« temps réel ») –Contrôleur dun réacteur nucléaire –Application graphique

6 6 Pathologies des projets informatiques Mauvais contrôle du périmètre Mauvais contrôle du périmètre Erreurs détectées trop tard Erreurs détectées trop tard Planning trop optimistes Planning trop optimistes Tâches oubliées Tâches oubliées Incompréhension entre acteurs Incompréhension entre acteurs

7 7 A quoi sert le génie logiciel Produire des logiciels de qualité, qui répondent aux besoins des utilisateurs Produire des logiciels de qualité, qui répondent aux besoins des utilisateurs Fournir des outils et méthodes pour anticiper les pathologies, … mais pas de remède miracle Fournir des outils et méthodes pour anticiper les pathologies, … mais pas de remède miracle

8 8 A quoi sert le génie logiciel Processus formalisés = réutilisation du savoir-faire Processus formalisés = réutilisation du savoir-faire Communication entre acteurs du projet Communication entre acteurs du projet Maîtrise de la qualité (cohérence, complétude et conformité) Maîtrise de la qualité (cohérence, complétude et conformité) Automatisation = efficacité Automatisation = efficacité

9 9 Le génie logiciel a mauvaise presse Souvent perçu comme cher et peu productif Pourquoi : –Outils lourds et peu flexibles : carcan –Coûts de mise en œuvre élevés (formation) –Retour sur investissement sur le long terme On a tendance à loublier quand les choses deviennent plus difficiles

10 10 Outils de génie logiciel Périmètre : Périmètre : –Mise en œuvre de méthodologies –Gestion du risque –Gestion de projet –Gestion de configuration –Gestion de documentation

11 11 Gestion de configuration Objectifs : Objectifs : –Définir les relations de composition entre parties dun produit –Définir de nouvelles versions dun produit ou sous- ensemble (variantes, évolutions) –Définir des relations entre un produit final et ses livrables intermédiaires (spec fonctionnelle - spec technique - modules logiciels – jeux de tests) –Déterminer limpact dun changement : traçabilité –Partager et communiquer ces définitions

12 12 Méthodologie Définition Ensemble de règles permettant de structurer le déroulement dun projet et daméliorer la prévisibilité du résultat Ensemble de règles permettant de structurer le déroulement dun projet et daméliorer la prévisibilité du résultat Structurer : les tâches, leurs résultats (livrables), les rôles et responsabilités des acteurs Structurer : les tâches, leurs résultats (livrables), les rôles et responsabilités des acteurs

13 13 Terminologie Phase Phase Correspond à un ou plusieurs livrables majeurs Activité Activité Liée à une fonction du projet (ex : tests) pouvant déborder les limites dune phase Tâche Tâche Élément dune phase (ou dune activité) produisant un livrable Livrable : Livrable : Produit intermédiaire ou final du projet : matériel, logiciel ou service (formation, doc) géré par la gestion de configuration

14 14 Rôles et responsabilités Objectif des rôles : –Indépendance des individus –Définition des compétences requises –Clarification des interfaces

15 15 Rôles et responsabilités Responsabilités : –Associées à une tâche –Responsable, participe, valide, est informé (R, P, V, I) –Contraintes sur la responsabilité et la validation : Un seul responsable Un seul responsable On ne peut pas être juge et partie On ne peut pas être juge et partie La responsabilité peut être déléguée mais le devoir de contrôle subsiste La responsabilité peut être déléguée mais le devoir de contrôle subsiste

16 16 Exercice : trouver les erreurs VP Obtenir laccord client PR Réaliser des corrections VPPR Présenter le prototype PPI Construire des exercices PRV Développer un proto du support RIIR Définir le contenu du support CltBACP

17 17 Le cycle en V (waterfall) Méthodologie de base pour le développement de solutions informatiques –Base pour dautres méthodes –Séquence ordonnée dactivités sans recouvrement –Contrôle en fin de chaque phase –Conduite par les documents

18 18 Schéma du cycle en V Cycle en V (waterfall) –Correspond à une exécution séquentielle des activités, donc en principe à un risque minimal –Correspond en principe à un coût minimal –Suppose des besoins bien définis Visibilité maîtrise douvrage _ + Temps Analyse Conception technique Codage Intégration Recette

19 19 Phases et livrables du cycle en V Définition du besoin Définition du besoin Analyse fonctionnelle Analyse fonctionnelle Conception technique Conception technique Codage et intégration Codage et intégration Recette Recette [Déploiement] [Déploiement] [Maintenance] [Maintenance] Cahier des charges Cahier des charges Spec. fonctionnelle, Cahier de recette Spec. fonctionnelle, Cahier de recette Architecture et specs. techniques Architecture et specs. techniques Code, résultats de test Code, résultats de test Résultats de recette Résultats de recette Plan, formation, doc dexploitation Plan, formation, doc dexploitation Spec. de service de maintenance Spec. de service de maintenance

20 20 Terminologie Analyse Analyse –Initialement, étude du fonctionnement de lentreprise –Ensuite, distinction analyse fonctionnelle (description des fonctions) et organique (description de la solution logicielle) –Usage actuel : spécification de ce qui est attendu du système (maîtrise douvrage, cahier des charges)

21 21 Terminologie Conception : Conception : –Apparue dans les années 80, liée au système dinformation dont elle décrit les éléments (acteurs, règles, flux dinformation) –Usage actuel : développement de larchitecture et des composants de la solution informatique

22 22 Cahier des charges Définit : Définit : –La raison dêtre du projet –Les attentes des futurs utilisateurs –Les contraintes de diverses natures de la maîtrise douvrage (temps, budget, …) Il est écrit par la maîtrise douvrage Il est écrit par la maîtrise douvrage –Pour approbation interne –Pour communication à une maîtrise dœuvre

23 23 Cahier des charges Contexte : pourquoi un projet Contexte : pourquoi un projet Environnement Environnement Objectifs : résultats attendus (du système) Objectifs : résultats attendus (du système) Périmètre : fonctionnalités attendues Périmètre : fonctionnalités attendues Facteurs critiques (définition des conditions de succès du projet) Facteurs critiques (définition des conditions de succès du projet) Contraintes Contraintes Échéances Échéances Budget (?) Budget (?)

24 24 Exercice Cahier des charges

25 25 Spécifications fonctionnelles Définissent : Définissent : –Lensemble des règles et caractéristiques (fonctionnelles ou non) auxquelles satisferont la solution à construire et son contexte dutilisation –Les contraintes initiales, retraduites en termes de solution –Éventuellement, des indicateurs et objectifs de résultat –Une méthodologie et un plan de projet

26 26 Spécifications fonctionnelles Le contexte dutilisation de la solution inclut : –Les utilisateurs finals du système et leur organisation –Les processus métier au cours desquels la solution est utilisée –Les personnes chargées du fonctionnement opérationnel de la solution –Les systèmes avec lesquels la solution sinterface

27 27 Exemple de contexte dutilisation Pour un système informatisé de contrôle radar, le contexte inclut : Pour un système informatisé de contrôle radar, le contexte inclut : –Les protagonistes : police, fabricants de radar, constructeurs auto, organisme chargé de lémission et du recouvrement des PV, juristes, gestionnaires du système informatique –Les processus : verbalisation, recouvrement, recours, reporting aux administrations –Les interfaces avec des systèmes : radar, embarqué, fichier des cartes grises, …

28 28 Spécifications fonctionnelles Les spécifications fonctionnelles présentent les grandes lignes de la solution. On doit à ce niveau : Les spécifications fonctionnelles présentent les grandes lignes de la solution. On doit à ce niveau : –Sassurer de la faisabilité technique –Sassurer que la maîtrise dœuvre en sait assez pour concevoir la solution détaillée –Ne pas créer trop de contraintes de réalisation Les spécifications fonctionnelles sont développées conjointement et validées par la maîtrise douvrage Les spécifications fonctionnelles sont développées conjointement et validées par la maîtrise douvrage

29 29 Spécifications techniques Définissent la solution dans le détail Définissent la solution dans le détail –Le contenu dépend de la technologie utilisée (ex : UML en environnement objet) –Il doit décrire tout ce qui est nécessaire à lopération et à la maintenance du système: Structure interne de lapplication, comportement statique et dynamique Structure interne de lapplication, comportement statique et dynamique Caractéristiques techniques et packaging des composants Caractéristiques techniques et packaging des composants Interfaces avec lextérieur (acteurs, systèmes) Interfaces avec lextérieur (acteurs, systèmes) Lancement, sauvegarde, reprise Lancement, sauvegarde, reprise

30 30 Plan de recette Définit les conditions selon lesquelles on détermine quune solution répond aux besoins Définit les conditions selon lesquelles on détermine quune solution répond aux besoins –Processus de recette –Rôles et responsabilités –Conditions dacceptation –Configuration et données de test –Jeux de tests –Planning

31 31 Les inconvénients du cycle en V La concurrence a le temps de créer de nouveaux besoins La concurrence a le temps de créer de nouveaux besoins Les utilisateurs ont le temps de changer davis Les utilisateurs ont le temps de changer davis On ne découvre le produit quà la fin On ne découvre le produit quà la fin Les erreurs découvertes tardivement coûtent cher Les erreurs découvertes tardivement coûtent cher Visibilité utilisateurs _ + Temps Analyse Conception technique Codage Intégration Recette

32 32 Étude de cas : application du cycle en V Discuter les choix du chef de projet. Discuter des scénarios alternatifs et leurs conditions de mise en œuvre

33 33 Premières alternatives au cycle en V Développer des méthodes qui assurent plus de réactivité : Développer des méthodes qui assurent plus de réactivité : Mais attention : Mais attention : –Ceci ne veut pas dire, sans méthode, au contraire –Ceci ne veut pas dire sans documentation Car il existe une chose économiquement plus importante que la conception et la programmation : la maintenance Car il existe une chose économiquement plus importante que la conception et la programmation : la maintenance

34 34 Les méthodologies oublient la maintenance… Maintenance curative Les application sont de plus en plus stratégiques, donc tolèrent de moins en moins les interruptions de service. Les erreurs bloquantes doivent donc être résolues « immédiatement » Si un défaut dun système est détecté en analyse avec un coût de résolution de 1 unité, sa détection pendant la phase de programmation coûtera 10 unités, sa détection pendant les tests dintégration coûtera 100 unités, sa détection en production coûtera 1000 unités Analyse Dévelop- pement Tests Produc -tion Coût de résolution 1000 100 10 1 Échelle logarithmique

35 35 Coder et débuguer « Code and fix », la méthode des gens peu enclins à la formalisation « Code and fix », la méthode des gens peu enclins à la formalisation Combinaison informelle de (spec) design, code et test Combinaison informelle de (spec) design, code et test Management minimal Management minimal Peut fonctionner pour : Peut fonctionner pour : –des projets « simples », de courte durée, ne nécessitant pas une grosse équipe (<3) –des équipes peu sophistiquées Ne peut pas fonctionner pour : Ne peut pas fonctionner pour : –des projets mal définis, stratégiques ou sous de fortes contraintes de temps

36 36 Les variantes du waterfall Waterfall avec recouvrement –Principe : admettre du recouvrement entre phases –Introduit de nouveaux risques (suivi plus complexe, problèmes de communication) Waterfall avec sous-projets –Principe : une fois larchitecture technique définie, lancer des sous-projets en parallèle –Danger : dépendances inattendues entre sous- projets

37 37 Les variantes du waterfall Waterfall avec maquettage ou prototype Objectif : limiter les risques en augmentant la visibilité de certains aspects en début de cycle Maquette et prototype –Un prototype crée un sous-ensemble du système projeté développé sans tenir compte de laspect industrialisation –Une maquette est une présentation en trompe lœil de lapparence externe du système (ex : navigation dun site Web)

38 38 Maquettage Le maquettage : Le maquettage : –Remplace des descriptions complexes –Ne couvre pas toutes les spécifications (cas de fonctionnement normaux) –Sert à figer la définition dune interface –Est « jetable »

39 39 Prototypage A la différence dune maquette, un prototype réalise une fonction A la différence dune maquette, un prototype réalise une fonction Deux cas : Deux cas : –Prototype jetable : on utilise un langage ou des modes de développement rapides. Lobjectif est de montrer la faisabilité (technique, de performance, etc.) –Prototype non jetable : sert de base au développement du reste du produit, et correspond donc à un premier incrément dun système

40 40 Prototype jetable Objectif : accélérer un projet et en réduire les risques en explorant certains aspects critiques en début de cycle Exemples : –Validation dune interface avec un système existant –Étude du comportement dune base de données sous forte charge –Présentation de résultats –Partie critique dun système temps réel

41 41 Risques associés au prototype jetable 1. Le prototype devient la base du système 2. Le prototypage devient un projet ouvert et consommateur de ressources 3. Les utilisateurs ont limpression que le produit final nest pas loin Parade : considérer le prototype comme un projet séparé

42 42 Étude de cas n° 1 : choix de méthodologie Scénario Prototypage

43 43 Itération et incrémentation Itération : le système (ou sous-ensemble) est fabriqué par itérations successives correspondant au raffinement de fonctionnalités (introduction de variantes, optimisations, etc.) Itération : le système (ou sous-ensemble) est fabriqué par itérations successives correspondant au raffinement de fonctionnalités (introduction de variantes, optimisations, etc.) Incrémentation : le système est dabord livré avec des fonctionnalités limitées, mais totalement développées ; dautres fonctionnalités sont ensuite ajoutées. Incrémentation : le système est dabord livré avec des fonctionnalités limitées, mais totalement développées ; dautres fonctionnalités sont ensuite ajoutées. Itération et incrémentation peuvent être combinées

44 44 Cycle en spirale (incrémental) Principe : raccourcir la longueur du cycle en V en ayant plusieurs incréments, dont le contenu est défini par une gestion du risque privilégiant : Principe : raccourcir la longueur du cycle en V en ayant plusieurs incréments, dont le contenu est défini par une gestion du risque privilégiant : –Les fonctions à plus grande valeur ajoutée –Les fonctions dont la mise en œuvre est la plus risquée Le premier cycle est plus long car il définit larchitecture technique sur laquelle reposent les suivants.

45 45 Cycle en spirale : avantages Réduction de la longueur de cycle = meilleure visibilité des utilisateurs Réduction de la longueur de cycle = meilleure visibilité des utilisateurs Résultats intermédiaires = meilleure motivation de léquipe Résultats intermédiaires = meilleure motivation de léquipe Planification plus aisée à partir de la seconde incrémentation Planification plus aisée à partir de la seconde incrémentation

46 46 Cycle en spirale : risques Suppose les fonctionnalités relativement stables et bien définies Suppose les fonctionnalités relativement stables et bien définies Suppose que larchitecture élaborée en première incrémentation supportera les futures fonctionnalités Suppose que larchitecture élaborée en première incrémentation supportera les futures fonctionnalités Nécessite un travail de gestion (planification, gestion de configuration) plus complexe et plus conséquent Nécessite un travail de gestion (planification, gestion de configuration) plus complexe et plus conséquent

47 47 RAD (timebox) Principe : Repose également sur des itérations, dont le contenu est fixé par ce quil est possible de faire à lintérieur dun volume de temps donné Principe : Repose également sur des itérations, dont le contenu est fixé par ce quil est possible de faire à lintérieur dun volume de temps donné Durée : 2 à 4 mois pour un produit, 1 à 2 semaines pour un prototype Durée : 2 à 4 mois pour un produit, 1 à 2 semaines pour un prototype Petite équipe, forte implication des utilisateurs Petite équipe, forte implication des utilisateurs Peut sutiliser pour des sous-ensembles dun projet plus gros Peut sutiliser pour des sous-ensembles dun projet plus gros

48 48 Schéma du RAD Cahier des charges Définition du système Prototype Revue des utilisateurs et demandes de changements Construire et faire évoluer le prototype Demandes de changement Évaluer le système Développement Acceptation Évolution majeure Refus Développement en temps contraint Source : Rapid Development (McConnell 1996)

49 49 RAD : avantages Focus sur lefficacité Focus sur lefficacité Très bonne visibilité des utilisateurs Très bonne visibilité des utilisateurs Cycle court, donc bonne réaction au changement Cycle court, donc bonne réaction au changement Tire le meilleur parti des outils de production de logiciel Tire le meilleur parti des outils de production de logiciel

50 50 RAD : risques Sapplique mal au développement externe Sapplique mal au développement externe Suppose une équipe fortement mobilisée Suppose une équipe fortement mobilisée Suppose des utilisateurs très disponibles Suppose des utilisateurs très disponibles Suppose que lon sache estimer les charges correctement Suppose que lon sache estimer les charges correctement Risque de sacrifier la qualité au timing Risque de sacrifier la qualité au timing

51 51 Exemples dévolution dun SI Évolution fonctionnelle : Évolution fonctionnelle : Un fabricant de pièces détachées de moto signe un accord commercial avec Honda : le SI doit refléter cet accord Évolution technologique : Évolution technologique : Il décide de mettre son catalogue sur le Web Il décide de migrer vers une architecture Java Évolution combinée : Évolution combinée : Il décide de vendre à travers une place de marché

52 52 Choix dune méthodologie Choisir une méthodologie que lon sera en mesure dappliquer Choisir une méthodologie que lon sera en mesure dappliquer Volatilité des besoins Volatilité des besoins Complexité et taille du projet Complexité et taille du projet Risques métier : importance du facteur « temps » et des facteurs « métier » Risques métier : importance du facteur « temps » et des facteurs « métier » Risques technologiques Risques technologiques Outils disponibles Outils disponibles

53 53 Comparaison des méthodologies

54 54 Outils de génie logiciel Il ny a pas doutil qui procure un gain de productivité de 25% ou plus sur un projet Il ny a pas doutil qui procure un gain de productivité de 25% ou plus sur un projet Ladoption dun outil est une entreprise risquée, dont le coût dacquisition nest quun élément du coût total Ladoption dun outil est une entreprise risquée, dont le coût dacquisition nest quun élément du coût total Lacquisition doutils relève dun choix stratégique de lorganisation, et dun processus défini sur le long terme, pas de celui dun projet isolé Lacquisition doutils relève dun choix stratégique de lorganisation, et dun processus défini sur le long terme, pas de celui dun projet isolé

55 55 Outils de génie logiciel Il existe des statistiques décourageantes Il existe des statistiques décourageantes –30% ne satisfont pas aux besoins de manière efficace –10% ne servent pas après lachat –25% sont sous-utilisés par manque de formation –15% sont incompatibles avec les outils existants Cependant, Cependant, –Lacquisition doutils garde tout son sens si elle est intégrée à un processus damélioration de la qualité et de la productivité incluant les équipes et les processus –Le passage de linformatique au stade post-artisanal passe par des outils impactant la totalité du cycle du projet

56 56 Outils de génie logiciel Les véritables gains peuvent se trouver dans une bonne combinaison doutils ; des outils simples et adaptés peuvent apporter un gain marginal Les véritables gains peuvent se trouver dans une bonne combinaison doutils ; des outils simples et adaptés peuvent apporter un gain marginal Leffet dun outil sur la productivité ne se fait sentir quau terme dune durée dapprentissage : les (bons) outils ne sont effectifs que sils sont utilisés de manière répétitive Leffet dun outil sur la productivité ne se fait sentir quau terme dune durée dapprentissage : les (bons) outils ne sont effectifs que sils sont utilisés de manière répétitive

57 57 Outils de génie logiciel Critères de sélection –Gain estimé (attention aux promesses) –Crédibilité du fabricant –Qualité (essayer) –Maturité du produit (attention à la version 1) –Effort dapprentissage –Compatibilité avec lexistant –Perspectives dévolution

58 58 Étude de cas n° 2 : choix de méthodologie Prise en compte des exigences de la MOA

59 59 Ce quil faut retenir Le génie logiciel nest pas un luxe, ni une garantie, mais il augmente sensiblement les chances de succès Le génie logiciel nest pas un luxe, ni une garantie, mais il augmente sensiblement les chances de succès Sa mise en œuvre nécessite du doigté : il y a toujours des (mauvaises) raisons pour sen passer Sa mise en œuvre nécessite du doigté : il y a toujours des (mauvaises) raisons pour sen passer Il existe de nombreuses méthodologies : aucune nest adaptée à tous les cas Il existe de nombreuses méthodologies : aucune nest adaptée à tous les cas Lavènement des technologies objet conduit à des processus de développement standardisés supportés par des outils Lavènement des technologies objet conduit à des processus de développement standardisés supportés par des outils Les outils ne déterminent pas la qualité dun projet, mais un processus dacquisition sur le long terme peut amener des gains sil sintègre dans une démarche damélioration Les outils ne déterminent pas la qualité dun projet, mais un processus dacquisition sur le long terme peut amener des gains sil sintègre dans une démarche damélioration