11

Gestion de projet Gestion de projet 2- 2- IntroductionIntroduction au au Génie Génie Logiciel Logiciel

Préparé par : Gérard BattarelPréparé par : Gérard Battarel

Pour : l’Université René Pour : l’Université René DescartesDescartes

Octobre 2006Octobre 2006© Copyright 2004 Gérard Battarel - Reproduction interdite sans autorisation de l’auteur

22

ObjectifsObjectifs

Comprendre le rôle du génie Comprendre le rôle du génie logiciellogiciel

Comprendre le cycle de base d’un Comprendre le cycle de base d’un projet informatiqueprojet informatique

Comprendre les limites de Comprendre les limites de l’approche classique et aborder l’approche classique et aborder les méthodes « modernes »les méthodes « modernes »

Aborder quelques outils et Aborder quelques outils et méthodesméthodes

33

Les projets informatiquesLes projets informatiques

Projet informatique =Projet informatique =– Projet dont une partie au moins du produit Projet dont une partie au moins du produit

résultant se compose de logiciels et/ou de résultant se compose de logiciels et/ou de matériels informatiques matériels informatiques

– Projet dont les services résultants Projet dont les services résultants consistent à faire fonctionner des logiciels consistent à faire fonctionner des logiciels et/ou des matériels informatiqueset/ou des matériels informatiques

Exemples :Exemples :– Centre d’appels ? Maintenance d’un Centre d’appels ? Maintenance d’un

système ?système ?

44

Les projets informatiquesLes projets informatiques

Rappel de la complexitéRappel de la complexité– Nombre d’acteurs et de compétences différents Nombre d’acteurs et de compétences différents

mis en œuvre mis en œuvre – Complexité des besoinsComplexité des besoins

Logiciel « professionnel »Logiciel « professionnel »– Production efficaceProduction efficace– Maintenance facileMaintenance facile– Évolutivité (?)Évolutivité (?)– Réutilisation du savoir-faire dans le cadre de Réutilisation du savoir-faire dans le cadre de

l’organisation productricel’organisation productrice– Caractéristiques non fonctionnellesCaractéristiques non fonctionnelles

55

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 d’assurances– Calculs de structures (résistance des matériaux)

Prédominance des événements (« temps réel »)– Contrôleur d’un réacteur nucléaire– Application graphique

66

Pathologies des projets Pathologies des projets informatiquesinformatiques

Mauvais contrôle du périmètreMauvais contrôle du périmètre

Erreurs détectées trop tardErreurs détectées trop tard

Planning trop optimistesPlanning trop optimistes

Tâches oubliéesTâches oubliées

Incompréhension entre acteursIncompréhension entre acteurs

77

A quoi sert le génie logicielA quoi sert le génie logiciel

Produire des logiciels de qualité, Produire des logiciels de qualité, qui répondent aux besoins des qui répondent aux besoins des utilisateursutilisateurs

Fournir des Fournir des outilsoutils et et méthodesméthodes pour anticiper les pathologies, … pour anticiper les pathologies, … mais pas de remède miraclemais pas de remède miracle

88

A quoi sert le génie logicielA quoi sert le génie logiciel

Processus formalisés = Processus formalisés = réutilisation du savoir-faireréutilisation du savoir-faire

Communication entre acteurs du Communication entre acteurs du projetprojet

Maîtrise de la qualité (cohérence, Maîtrise de la qualité (cohérence, complétude et conformité)complétude et conformité)

Automatisation = efficacitéAutomatisation = efficacité

99

Le génie logiciel a mauvaise Le génie logiciel a mauvaise pressepresse

Souvent perçu comme cher et peu Souvent perçu comme cher et peu productifproductif

Pourquoi :Pourquoi :– Outils lourds et peu flexibles : carcanOutils lourds et peu flexibles : carcan– Coûts de mise en œuvre élevés Coûts de mise en œuvre élevés

(formation)(formation)– Retour sur investissement sur le long Retour sur investissement sur le long

terme terme

On a tendance à l’oublier quand On a tendance à l’oublier quand les choses deviennent plus les choses deviennent plus difficilesdifficiles

1010

Outils de génie logicielOutils de génie logiciel

Périmètre : Périmètre : – Mise en œuvre de méthodologiesMise en œuvre de méthodologies– Gestion du risqueGestion du risque– Gestion de projetGestion de projet– Gestion de configurationGestion de configuration– Gestion de documentationGestion de documentation

1111

Gestion de configurationGestion de configuration

Objectifs :Objectifs :– Définir les relations de composition entre parties Définir les relations de composition entre parties

d’un produitd’un produit– Définir de nouvelles versions d’un produit ou sous-Définir de nouvelles versions d’un produit ou sous-

ensemble (variantes, évolutions)ensemble (variantes, évolutions)– Définir des relations entre un produit final et ses Définir des relations entre un produit final et ses

livrables intermédiaires (spec fonctionnelle - spec livrables intermédiaires (spec fonctionnelle - spec technique - modules logiciels – jeux de tests)technique - modules logiciels – jeux de tests)

– Déterminer l’impact d’un changement : traçabilitéDéterminer l’impact d’un changement : traçabilité– Partager et communiquer ces définitionsPartager et communiquer ces définitions

1212

MéthodologieMéthodologie

DéfinitionDéfinition Ensemble de règles permettant de structurer Ensemble de règles permettant de structurer

le déroulement d’un projet et d’améliorer la le déroulement d’un projet et d’améliorer la prévisibilité du résultat prévisibilité du résultat

Structurer : les tâches, leurs résultats Structurer : les tâches, leurs résultats (livrables), les rôles et responsabilités des (livrables), les rôles et responsabilités des acteursacteurs

1313

TerminologieTerminologie

PhasePhaseCorrespond à un ou plusieurs livrables majeursCorrespond à un ou plusieurs livrables majeurs

ActivitéActivitéLiée à une fonction du projet (ex : tests) pouvant Liée à une fonction du projet (ex : tests) pouvant déborder les limites d’une phasedéborder les limites d’une phase

TâcheTâcheÉlément d’une phase (ou d’une activité) produisant Élément d’une phase (ou d’une activité) produisant un livrableun livrable

Livrable : Livrable : Produit intermédiaire ou final du projet : matériel, Produit intermédiaire ou final du projet : matériel, logiciel ou service (formation, doc) géré par la logiciel ou service (formation, doc) géré par la gestion de configurationgestion de configuration

1414

Rôles et responsabilitésRôles et responsabilités

Objectif des rôles :Objectif des rôles :– Indépendance des individusIndépendance des individus– Définition des compétences requisesDéfinition des compétences requises– Clarification des interfacesClarification des interfaces

1515

Rôles et responsabilitésRôles et responsabilités

Responsabilités :Responsabilités :– Associées à une tâcheAssociées à une tâche– Responsable, participe, valide, est Responsable, participe, valide, est

informé (R, P, V, I)informé (R, P, V, I)– Contraintes sur la responsabilité et Contraintes sur la responsabilité et

la validation :la validation : Un seul responsableUn seul responsable On ne peut pas être juge et partieOn ne peut pas être juge et partie La responsabilité peut être déléguée La responsabilité peut être déléguée

mais le devoir de contrôle subsistemais le devoir de contrôle subsiste

1616

Exercice : trouver les erreursExercice : trouver les erreurs

VPObtenir l’accord client

PRRéaliser des corrections

VPPRPrésenter le prototype

PPIConstruire des exercices

PRVDévelopper un proto du support

RIIRDéfinir le contenu du support

CltBACP

1717

Le cycle en V (waterfall)Le cycle en V (waterfall)

Méthodologie de base pour le Méthodologie de base pour le développement de solutions développement de solutions informatiquesinformatiques– Base pour d’autres méthodesBase pour d’autres méthodes– Séquence ordonnée d’activités sans Séquence ordonnée d’activités sans

recouvrementrecouvrement– Contrôle en fin de chaque phaseContrôle en fin de chaque phase– Conduite par les documentsConduite par les documents

1818

Schéma du cycle en VSché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 d’ouvrage

_

+

Temps

AnalyseConceptiontechnique

Codage

Intégration

Recette

1919

Phases et livrables du cycle en VPhases et livrables du cycle en V

Définition du besoinDéfinition du besoin Analyse Analyse

fonctionnellefonctionnelle

Conception Conception techniquetechnique

Codage et Codage et intégrationintégration

RecetteRecette [Déploiement] [Déploiement]

[Maintenance][Maintenance]

Cahier des chargesCahier des charges Spec. fonctionnelle, Spec. fonctionnelle,

Cahier de recetteCahier de recette Architecture et Architecture et

specs. techniquesspecs. techniques Code, résultats de Code, résultats de

testtest Résultats de recetteRésultats de recette Plan, formation, doc Plan, formation, doc

d’exploitationd’exploitation

Spec. de service de Spec. de service de maintenancemaintenance

2020

TerminologieTerminologie

AnalyseAnalyse– Initialement, étude du fonctionnement de Initialement, étude du fonctionnement de

l’entreprisel’entreprise– Ensuite, distinction analyse fonctionnelle Ensuite, distinction analyse fonctionnelle

(description des fonctions) et organique (description des fonctions) et organique (description de la solution logicielle)(description de la solution logicielle)

– Usage actuel : spécification de ce qui est Usage actuel : spécification de ce qui est attendu du système (maîtrise d’ouvrage, attendu du système (maîtrise d’ouvrage, cahier des charges)cahier des charges)

2121

TerminologieTerminologie

Conception :Conception :– Apparue dans les années 80, liée au Apparue dans les années 80, liée au

système d’information dont elle décrit les système d’information dont elle décrit les éléments (acteurs, règles, flux éléments (acteurs, règles, flux d’information)d’information)

– Usage actuel : développement de Usage actuel : développement de l’architecture et des composants de la l’architecture et des composants de la solution informatiquesolution informatique

2222

Cahier des chargesCahier des charges

DéfinitDéfinit : :– La raison d’être du projetLa raison d’être du projet– Les attentes des futurs utilisateursLes attentes des futurs utilisateurs– Les contraintes de diverses natures de la Les contraintes de diverses natures de la

maîtrise d’ouvrage (temps, budget, …)maîtrise d’ouvrage (temps, budget, …) Il est écrit par la maîtrise d’ouvrageIl est écrit par la maîtrise d’ouvrage

– Pour approbation internePour approbation interne– Pour communication à une maîtrise Pour communication à une maîtrise

d’œuvre d’œuvre

2323

Cahier des chargesCahier des charges

Contexte : pourquoi un projetContexte : pourquoi un projet EnvironnementEnvironnement Objectifs : résultats attendus (du système)Objectifs : résultats attendus (du système) Périmètre : fonctionnalités attenduesPérimètre : fonctionnalités attendues Facteurs critiques (définition des Facteurs critiques (définition des

conditions de succès du projet)conditions de succès du projet) ContraintesContraintes ÉchéancesÉchéances Budget (?)Budget (?)

2424

ExerciceExercice

Cahier des chargesCahier des charges

2525

Spécifications fonctionnellesSpécifications fonctionnelles

Définissent :Définissent :

– L’ensemble des règles et caractéristiques L’ensemble des règles et caractéristiques (fonctionnelles ou non) auxquelles (fonctionnelles ou non) auxquelles satisferont la solution à construire et son satisferont la solution à construire et son contexte d’utilisationcontexte d’utilisation

– Les contraintes initiales, retraduites en Les contraintes initiales, retraduites en termes de solutiontermes de solution

– Éventuellement, des indicateurs et Éventuellement, des indicateurs et objectifs de résultatobjectifs de résultat

– Une méthodologie et un plan de projetUne méthodologie et un plan de projet

2626

Spécifications fonctionnellesSpécifications fonctionnelles

Le contexte d’utilisation de la solution Le contexte d’utilisation de la solution inclut :inclut :

– Les utilisateurs finals du système et leur Les utilisateurs finals du système et leur organisationorganisation

– Les processus métier au cours desquels la Les processus métier au cours desquels la solution est utiliséesolution est utilisée

– Les personnes chargées du Les personnes chargées du fonctionnement opérationnel de la solutionfonctionnement opérationnel de la solution

– Les systèmes avec lesquels la solution Les systèmes avec lesquels la solution s’interfaces’interface

2727

Exemple de contexte Exemple de contexte d’utilisationd’utilisation

Pour un système informatisé de Pour un système informatisé de contrôle radar, le contexte inclut :contrôle radar, le contexte inclut :– Les protagonistes : police, fabricants de radar, Les protagonistes : police, fabricants de radar,

constructeurs auto, organisme chargé de constructeurs auto, organisme chargé de l’émission et du recouvrement des PV, juristes, l’émission et du recouvrement des PV, juristes, gestionnaires du système informatique gestionnaires du système informatique

– Les processus : verbalisation, recouvrement, Les processus : verbalisation, recouvrement, recours, reporting aux administrationsrecours, reporting aux administrations

– Les interfaces avec des systèmes : radar, Les interfaces avec des systèmes : radar, embarqué, fichier des cartes grises, …embarqué, fichier des cartes grises, …

2828

Spécifications fonctionnellesSpécifications fonctionnelles

Les spécifications fonctionnelles Les spécifications fonctionnelles présentent les grandes lignes de la présentent les grandes lignes de la solution. On doit à ce niveau :solution. On doit à ce niveau :– S’assurer de la faisabilité techniqueS’assurer de la faisabilité technique– S’assurer que la maîtrise d’œuvre en sait assez S’assurer que la maîtrise d’œuvre en sait assez

pour concevoir la solution détailléepour concevoir la solution détaillée– Ne pas créer trop de contraintes de réalisationNe pas créer trop de contraintes de réalisation

Les spécifications fonctionnelles sont Les spécifications fonctionnelles sont développées conjointement et validées développées conjointement et validées par la maîtrise d’ouvragepar la maîtrise d’ouvrage

2929

Spécifications techniquesSpécifications techniques

Définissent la solution dans le détailDéfinissent la solution dans le détail– Le contenu dépend de la technologie Le contenu dépend de la technologie

utilisée (ex : UML en environnement utilisée (ex : UML en environnement objet)objet)

– Il doit décrire tout ce qui est nécessaire Il doit décrire tout ce qui est nécessaire à l’opération et à la maintenance du à l’opération et à la maintenance du système:système:

Structure interne de l’application, Structure interne de l’application, comportement statique et dynamiquecomportement statique et dynamique

Caractéristiques techniques et packaging des Caractéristiques techniques et packaging des composantscomposants

Interfaces avec l’extérieur (acteurs, Interfaces avec l’extérieur (acteurs, systèmes)systèmes)

Lancement, sauvegarde, repriseLancement, sauvegarde, reprise

3030

Plan de recettePlan de recette

Définit les conditions selon Définit les conditions selon lesquelles on détermine qu’une lesquelles on détermine qu’une solution répond aux besoinssolution répond aux besoins– Processus de recetteProcessus de recette– Rôles et responsabilitésRôles et responsabilités– Conditions d’acceptationConditions d’acceptation– Configuration et données de testConfiguration et données de test– Jeux de testsJeux de tests– PlanningPlanning

3131

Les inconvénients du cycle en VLes inconvénients du cycle en V

La concurrence a le temps de créer de La concurrence a le temps de créer de nouveaux besoinsnouveaux besoins

Les utilisateurs ont le temps de Les utilisateurs ont le temps de changer d’avischanger d’avis

On ne découvre le produit qu’à la finOn ne découvre le produit qu’à la fin Les erreurs découvertes tardivement Les erreurs découvertes tardivement

coûtent chercoûtent cherVisibilité utilisateurs

_

+

Temps

AnalyseConceptiontechnique

Codage

Intégration

Recette

3232

Étude de cas : application du Étude de cas : application du cycle en Vcycle en V

Discuter les choix du chef de Discuter les choix du chef de projet. Discuter des scénarios projet. Discuter des scénarios alternatifs et leurs conditions de alternatifs et leurs conditions de mise en œuvremise en œuvre

3333

Premières alternatives au Premières alternatives au cycle en V cycle en V

Développer des méthodes qui assurent Développer des méthodes qui assurent plus de réactivité : plus de réactivité :

Mais attention :Mais attention :– Ceci ne veut pas dire, sans méthode, au contraireCeci ne veut pas dire, sans méthode, au contraire– Ceci ne veut pas dire sans documentationCeci ne veut pas dire sans documentation

Car il existe une chose Car il existe une chose économiquement plus importante que économiquement plus importante que la conception et la programmation : la la conception et la programmation : la maintenancemaintenance

3434

Les méthodologies oublient la Les méthodologies oublient la maintenance…maintenance…Maintenance curativeMaintenance curative

Les application sont de plus en Les application sont de plus en

plus stratégiques, donc tolèrent de plus stratégiques, donc tolèrent de

moins en moins les interruptions moins en moins les interruptions

de service. Les erreurs bloquantes de service. Les erreurs bloquantes

doivent donc être résolues doivent donc être résolues

« immédiatement »« immédiatement »

Si un défaut d’un système est Si un défaut d’un système est

détecté en analyse avec un coût détecté en analyse avec un coût

de résolution de 1 unité, sa de résolution de 1 unité, sa

détection pendant la phase de détection pendant la phase de

programmation coûtera 10 unités, programmation coûtera 10 unités,

sa détection pendant les tests sa détection pendant les tests

d’intégration coûtera 100 unités, d’intégration coûtera 100 unités,

sa détection en production sa détection en production

coûtera 1000 unitéscoûtera 1000 unités

Analyse Dévelop-pement

Tests Produc-tion

Coût derésolution

1000

100

10

1

Échell

e log

arith

miq

ue

3535

Coder et débuguerCoder et débuguer

« Code and fix », la méthode des gens « Code and fix », la méthode des gens peu enclins à la formalisationpeu enclins à la formalisation

Combinaison informelle de (spec) Combinaison informelle de (spec) design, code et testdesign, code et test

Management minimalManagement minimal Peut fonctionner pour :Peut fonctionner pour :

– des projets « simples », de courte durée, ne des projets « simples », de courte durée, ne nécessitant pas une grosse équipe (<3)nécessitant pas une grosse équipe (<3)

– des équipes peu sophistiquéesdes équipes peu sophistiquées Ne peut pas fonctionner pour :Ne peut pas fonctionner pour :

– des projets mal définis, stratégiques ou sous de des projets mal définis, stratégiques ou sous de fortes contraintes de tempsfortes contraintes de temps

3636

Les variantes du waterfallLes variantes du waterfall

Waterfall avec recouvrementWaterfall avec recouvrement– Principe : admettre du recouvrement entre Principe : admettre du recouvrement entre

phasesphases– Introduit de nouveaux risques (suivi plus Introduit de nouveaux risques (suivi plus

complexe, problèmes de communication)complexe, problèmes de communication)

Waterfall avec sous-projetsWaterfall avec sous-projets– Principe : une fois l’architecture technique Principe : une fois l’architecture technique

définie, lancer des sous-projets en définie, lancer des sous-projets en parallèleparallèle

– Danger : dépendances inattendues entre Danger : dépendances inattendues entre sous-projetssous-projets

3737

Les variantes du waterfallLes variantes du waterfall

Waterfall avec maquettage ou prototypeWaterfall avec maquettage ou prototype

Objectif : limiter les risques en Objectif : limiter les risques en augmentant la visibilité de certains augmentant la visibilité de certains aspects en début de cycleaspects en début de cycle

Maquette et prototypeMaquette et prototype– Un Un prototypeprototype crée un sous-ensemble du système crée un sous-ensemble du système

projeté développé sans tenir compte de l’aspect projeté développé sans tenir compte de l’aspect industrialisationindustrialisation

– Une Une maquettemaquette est une présentation en trompe l’œil est une présentation en trompe l’œil de l’apparence externe du système (ex : navigation de l’apparence externe du système (ex : navigation d’un site Web)d’un site Web)

3838

MaquettageMaquettage

Le maquettage :Le maquettage :– Remplace des descriptions complexesRemplace des descriptions complexes– Ne couvre pas toutes les spécifications Ne couvre pas toutes les spécifications

(cas de fonctionnement normaux)(cas de fonctionnement normaux)– Sert à figer la définition d’une interfaceSert à figer la définition d’une interface– Est « jetable »Est « jetable »

3939

PrototypagePrototypage

A la différence d’une maquette, un A la différence d’une maquette, un prototype réalise une fonctionprototype réalise une fonction

Deux cas :Deux cas :– Prototype jetable : on utilise un langage ou des Prototype jetable : on utilise un langage ou des

modes de développement rapides. L’objectif est de modes de développement rapides. L’objectif est de montrer la faisabilité (technique, de performance, montrer la faisabilité (technique, de performance, etc.)etc.)

– Prototype non jetable : sert de base au Prototype non jetable : sert de base au développement du reste du produit, et correspond développement du reste du produit, et correspond donc à un premier incrément d’un systèmedonc à un premier incrément d’un système

4040

Prototype jetablePrototype jetable

Objectif : accélérer un projet et en Objectif : accélérer un projet et en réduire les risques en explorant réduire les risques en explorant certains aspects critiques en début de certains aspects critiques en début de cyclecycle

Exemples :Exemples :– Validation d’une interface avec un système Validation d’une interface avec un système

existantexistant– Étude du comportement d’une base de données Étude du comportement d’une base de données

sous forte chargesous forte charge– Présentation de résultatsPrésentation de résultats– Partie critique d’un système temps réelPartie critique d’un système temps réel

4141

Risques associés au prototype Risques associés au prototype jetablejetable

1.1. Le prototype devient la base du Le prototype devient la base du systèmesystème

2.2. Le prototypage devient un projet Le prototypage devient un projet ouvert et consommateur de ouvert et consommateur de ressourcesressources

3.3. Les utilisateurs ont l’impression que Les utilisateurs ont l’impression que le produit final n’est pas loinle produit final n’est pas loin

Parade : considérer le prototype Parade : considérer le prototype comme un projet séparécomme un projet séparé

4242

Étude de cas n° 1 : choix de Étude de cas n° 1 : choix de méthodologie méthodologie

Scénario PrototypageScénario Prototypage

4343

Itération et incrémentationItération et incrémentation

Itération : le système (ou sous-ensemble) Itération : le système (ou sous-ensemble) est fabriqué par itérations successives est fabriqué par itérations successives correspondant au raffinement de correspondant au raffinement de fonctionnalités (introduction de variantes, fonctionnalités (introduction de variantes, optimisations, etc.)optimisations, etc.)

Incrémentation : le système est d’abord Incrémentation : le système est d’abord livré avec des fonctionnalités limitées, mais livré avec des fonctionnalités limitées, mais totalement développées ; d’autres totalement développées ; d’autres fonctionnalités sont ensuite ajoutées.fonctionnalités sont ensuite ajoutées.

Itération et incrémentation peuvent être Itération et incrémentation peuvent être combinéescombinées

4444

Cycle en spirale (incrémental)Cycle en spirale (incrémental)

Principe : raccourcir la longueur du Principe : raccourcir la longueur du cycle en V en ayant plusieurs cycle en V en ayant plusieurs incréments, dont le contenu est défini incréments, dont le contenu est défini par une gestion du risque privilégiant :par une gestion du risque privilégiant :– Les fonctions à plus grande valeur ajoutéeLes fonctions à plus grande valeur ajoutée– Les fonctions dont la mise en œuvre est la plus Les fonctions dont la mise en œuvre est la plus

risquéerisquée

Le premier cycle est plus long car il Le premier cycle est plus long car il définit l’architecture technique sur définit l’architecture technique sur laquelle reposent les suivants.laquelle reposent les suivants.

4545

Cycle en spirale : avantagesCycle en spirale : avantages

Réduction de la longueur de cycle = Réduction de la longueur de cycle = meilleure visibilité des utilisateursmeilleure visibilité des utilisateurs

Résultats intermédiaires = meilleure Résultats intermédiaires = meilleure motivation de l’équipemotivation de l’équipe

Planification plus aisée à partir de la Planification plus aisée à partir de la seconde incrémentationseconde incrémentation

4646

Cycle en spirale : risquesCycle en spirale : risques

Suppose les fonctionnalités Suppose les fonctionnalités relativement stables et bien définiesrelativement stables et bien définies

Suppose que l’architecture élaborée en Suppose que l’architecture élaborée en première incrémentation supportera première incrémentation supportera les futures fonctionnalitésles futures fonctionnalités

Nécessite un travail de gestion Nécessite un travail de gestion (planification, gestion de (planification, gestion de configuration) plus complexe et plus configuration) plus complexe et plus conséquent conséquent

4747

RAD (timebox)RAD (timebox)

Principe : Repose également sur des Principe : Repose également sur des itérations, dont le contenu est fixé par ce itérations, dont le contenu est fixé par ce qu’il est possible de faire à l’intérieur d’un qu’il est possible de faire à l’intérieur d’un volume de temps donnévolume de temps donné

Durée : 2 à 4 mois pour un produit, 1 à 2 Durée : 2 à 4 mois pour un produit, 1 à 2 semaines pour un prototype semaines pour un prototype

Petite équipe, forte implication des Petite équipe, forte implication des utilisateursutilisateurs

Peut s’utiliser pour des sous-ensembles d’un Peut s’utiliser pour des sous-ensembles d’un projet plus grosprojet plus gros

4848

Schéma du RADSchéma du RADCahier 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éveloppementAcceptation

Évolution majeure

Refus

Développement en temps contraint

Source : Rapid Development (McConnell 1996)

4949

RAD : avantagesRAD : avantages

Focus sur l’efficacitéFocus sur l’efficacité Très bonne visibilité des utilisateursTrès bonne visibilité des utilisateurs Cycle court, donc bonne réaction au Cycle court, donc bonne réaction au

changementchangement Tire le meilleur parti des outils de Tire le meilleur parti des outils de

production de logicielproduction de logiciel

5050

RAD : risquesRAD : risques

S’applique mal au développement S’applique mal au développement externeexterne

Suppose une équipe fortement Suppose une équipe fortement mobiliséemobilisée

Suppose des utilisateurs très Suppose des utilisateurs très disponiblesdisponibles

Suppose que l’on sache estimer les Suppose que l’on sache estimer les charges correctementcharges correctement

Risque de sacrifier la qualité au timingRisque de sacrifier la qualité au timing

5151

Exemples d’évolution d’un SIExemples d’évolution d’un SI

Évolution fonctionnelle :Évolution fonctionnelle : Un fabricant de pièces détachées de moto signe un Un fabricant de pièces détachées de moto signe un accord commercial avec Honda : le SI doit refléter accord commercial avec Honda : le SI doit refléter cet accordcet accord

Évolution technologique :Évolution technologique :Il décide de mettre son catalogue sur le WebIl décide de mettre son catalogue sur le Web

Il décide de migrer vers une architecture JavaIl décide de migrer vers une architecture Java

Évolution combinée : Évolution combinée : Il décide de vendre à travers une place de marchéIl décide de vendre à travers une place de marché

5252

Choix d’une méthodologieChoix d’une méthodologie

Choisir une méthodologie que l’on sera Choisir une méthodologie que l’on sera en mesure d’appliqueren mesure d’appliquer

Volatilité des besoinsVolatilité des besoins Complexité et taille du projetComplexité et taille du projet Risques métier : importance du facteur Risques métier : importance du facteur

« temps » et des facteurs « métier »« temps » et des facteurs « métier » Risques technologiquesRisques technologiques Outils disponiblesOutils disponibles

5353

Comparaison des Comparaison des méthodologiesméthodologies

B e s o in ma l dé fini

B e s o in trè s

é v o lutif

G ra nde ta ille

Te mps c ritique

Te c hno lo gie no uv e lle

C ulture G L é lé me nta ire

P a s d'o utils

G L a da pté s

W a te rfa ll -- -- + -- -- + +C o de & F ix -- - -- - - + ++W a te rfa ll a v e c re c o uv re me nt

- -- + - -- - -

W a te rfa ll a v e c pro to ty pe ++

-- + - ++ - +

S pira le + + ++ + + - -R AD - ++ - ++ + -- --

5454

Outils de génie logicielOutils de génie logiciel

Il n’y a pas d’outil qui procure un gain Il n’y a pas d’outil qui procure un gain de productivité de 25% ou plus sur un de productivité de 25% ou plus sur un projetprojet

L’adoption d’un outil est une L’adoption d’un outil est une entreprise risquée, dont le coût entreprise risquée, dont le coût d’acquisition n’est qu’un élément du d’acquisition n’est qu’un élément du coût totalcoût total

L’acquisition d’outils relève d’un choix L’acquisition d’outils relève d’un choix stratégique de l’organisation, et d’un stratégique de l’organisation, et d’un processus défini sur le long terme, pas processus défini sur le long terme, pas de celui d’un projet isoléde celui d’un projet isolé

5555

Outils de génie logicielOutils de génie logiciel

Il existe des statistiques décourageantesIl existe des statistiques décourageantes– 30% ne satisfont pas aux besoins de manière efficace30% ne satisfont pas aux besoins de manière efficace– 10% ne servent pas après l’achat10% ne servent pas après l’achat– 25% sont sous-utilisés par manque de formation25% sont sous-utilisés par manque de formation– 15% sont incompatibles avec les outils existants15% sont incompatibles avec les outils existants

Cependant, Cependant, – L’acquisition d’outils garde tout son sens si elle est L’acquisition d’outils garde tout son sens si elle est

intégrée à un processus d’amélioration de la qualité et intégrée à un processus d’amélioration de la qualité et de la productivité incluant les équipes et les processusde la productivité incluant les équipes et les processus

– Le passage de l’informatique au stade post-artisanal Le passage de l’informatique au stade post-artisanal passe par des outils impactant la totalité du cycle du passe par des outils impactant la totalité du cycle du projetprojet

5656

Outils de génie logicielOutils de génie logiciel

Les véritables gains peuvent se Les véritables gains peuvent se trouver dans une bonne combinaison trouver dans une bonne combinaison d’outils ; des outils simples et adaptés d’outils ; des outils simples et adaptés peuvent apporter un gain marginalpeuvent apporter un gain marginal

L’effet d’un outil sur la productivité ne L’effet d’un outil sur la productivité ne se fait sentir qu’au terme d’une durée se fait sentir qu’au terme d’une durée d’apprentissage : les (bons) outils ne d’apprentissage : les (bons) outils ne sont effectifs que s’ils sont utilisés de sont effectifs que s’ils sont utilisés de manière répétitivemanière répétitive

5757

Outils de génie logicielOutils de génie logiciel

Critères de sélectionCritères de sélection– Gain estimé (attention aux promesses)Gain estimé (attention aux promesses)– Crédibilité du fabricantCrédibilité du fabricant– Qualité (essayer)Qualité (essayer)– Maturité du produit (attention à la version Maturité du produit (attention à la version

1)1)– Effort d’apprentissageEffort d’apprentissage– Compatibilité avec l’existantCompatibilité avec l’existant– Perspectives d’évolutionPerspectives d’évolution

5858

Étude de cas n° 2 : choix de Étude de cas n° 2 : choix de méthodologieméthodologie

Prise en compte des Prise en compte des exigences de la MOAexigences de la MOA

5959

Ce qu’il faut retenirCe qu’il faut retenir Le génie logiciel n’est pas un luxe, ni une Le génie logiciel n’est pas un luxe, ni une

garantie, mais il augmente sensiblement les garantie, mais il augmente sensiblement les chances de succèschances de succès

Sa mise en œuvre nécessite du doigté : il y a Sa mise en œuvre nécessite du doigté : il y a toujours des (mauvaises) raisons pour s’en toujours des (mauvaises) raisons pour s’en passerpasser

Il existe de nombreuses méthodologies : Il existe de nombreuses méthodologies : aucune n’est adaptée à tous les casaucune n’est adaptée à tous les cas

L’avènement des technologies objet conduit L’avènement des technologies objet conduit à des processus de développement à des processus de développement standardisés supportés par des outilsstandardisés supportés par des outils

Les outils ne déterminent pas la qualité d’un Les outils ne déterminent pas la qualité d’un projet, mais un processus d’acquisition sur le projet, mais un processus d’acquisition sur le long terme peut amener des gains s’il long terme peut amener des gains s’il s’intègre dans une démarche d’améliorations’intègre dans une démarche d’amélioration