Éléments de Méthodologie InformatiqueIllustration :
eXtreme Programming
Pourquoi ce cours ?
• Donner des éléments de méthodologie de projet (informatique)
• Introduire le vocabulaire et les concepts mis en jeux
• Guider le déroulement du projet d’informatique de L2
Plan
• Panaroma général– Définitions– Problématiques
• Méthodes & Standards– Typologie– Principales méthodes
• Exemple : eXtreme
Programming
Partie I : Panorama général
Dekoiçacôse ?
Méthode & Méthodologie
• Étymologie grecque :
• Méthodologie =science de la méthode
meta après, qui suit+ hodos chemin, voie, moyen= methodos la poursuite ou
la recherche d'une voie
Exemple de méthode (qualité)• Principe de Quintilien
– Quis, Quid, Ubi, Quibus auxiliis, Cur, Quomodo, Quando
• Méthode QQOQCP– Qui ? – Quoi ? – Où ? – Quand ? – Comment ? – Pourquoi ?
Méthodologie Informatique ?
• Plutôt que méthodologie– méthodes (standards)
destinées à améliorer– la conduite de projets
informatiques – pour le développement de
logiciels
Méthodologie Informatique
• Définition :– Utiliser des méthodes et des
outils dans le but de…– Produire des logiciels de
qualité…– En respectant les contraintes
de délai et de coût
• Exemples :– Méthodes : UP, XP, CMM, …– Outils : langage UML, AGL, …
QQOQCP
• Qui : Les étudiants de L2 + Prof• Quoi : Éléments de méthodo• Où : Ici !• Quand : Maintenant !• Comment : Cours (diaporama)• Pourquoi :
Bonne question !Commençons par une fable…
What for ? (metaphor)
A physician, a civil engineer, and a computer scientist were arguing about what was the oldest professionin the world.
What for ? (metaphor) – contd
The physician remarked,« Well, in the Bible, it says that God created Eve from a rib taken out of Adam. This clearly required surgery, and so I can rightly claim that mine is the oldest profession in the world. »
What for ? (metaphor) – contd
The civil engineer interrupted, and said, « But even earlier in the book of Genesis, it states that God created the order of the heavens and the earth from out of the chaos. This was the first and certainly the most spectacular application of civil engineering. Therefore, fair doctor, you are wrong: mine is the oldest profession in the world. »
What for ? (metaphor) - end
The computer scientist leaned back in her chair, smiled, and then said confidently,
« Ah, but who do you think created the chaos? »
Industrie Informatique
• Matériel– Fiable/Standardisé
• Logiciel– Complexe– Production souvent unitaire– Technique
Le développement logiciel est problématique :Taux de succès faible
décroissant avec la taille des projets et la taille des entreprises
Développement Logiciel
• Étude sur la réussite des projets informatiques :– Succès : 29% – Mitigés : 53% – Abandon : 18% (Source : Standish Group 2004)
• Discipline : Génie Logiciel
Méthodologie : Pour quoi faire ?
• Maîtriser les risques – Dépassement des délais– Abandon du projet– Logiciel défaillant– Logiciel inadapté– Développements inutiles– Logiciel impossible à
maintenir ou à faire évoluer– …
Problématique projet
Objectif
Moyens Délais
Gestion de la production
Gestion des
moyens
Gestion des
délais
Métiers
• Maîtrise d’ouvrage (utilisateur)– Chef de projet MOA– Expert métier– Utilisateur
• Maîtrise d’œuvre (concepteur)– Chef de projet MOE– Concepteur/Développeur– Intégrateur– …
Historique
• 1945 : – programmation en code
binaire/assembleur– 1 seul développeur– projets de petite taille
• 1955 :– Apparition des langages
évolués– projets + importants
Historique - suite
• 1965 : – Crise du logiciel :
l'intuition ne suffit pas pour développer correctement du logiciel
• 1968 :– Première conférence sur le
Génie Logiciel (Software engineering)
Historique - suite• 1970 :
– Notion de programmation structurée :
• suppression du GOTO,• structuration du code
• 1972 : – Développement des méthodes de
preuves de programmes
• 1975 : – Développer un projet coder
• cycle de vie• développement de méthodes
associées (modèles en V, W, …)
Historique - suite
• 1980 : – Approche fonctionnelle :
• importance des premières phases de conception
• Méthodes : Merise, …
• 1990 : – Développement de la POO
• Objectif : réutilisation• Méthodes : UP, XP, …
Partie II : Méthodes & Standards
Voilacékoi !
Modèle en cascade
Cycle en V
Modèle en spirale
4 - Validation
1 - Analyse2 - Conception
3 - Réalisation
Modèle en spirale - suite
Modèle itératif
Élaboration
Fabrication
Transition
Faisabilité
Nouveau Besoin
Exploitation ou Test
Merise
Étude préalable
Étude détaillée
Réalisation
Mise en oeuvre
Étapes OutilsModèle Organisationnel des TraitementsModèle Conceptuel des DonnéesModèle Conceptuel des Traitements
Modèle Logique des Données
Délivrables
MaquettesPrototypes
Merise - suite
• Maquette– Expression des besoins et
spécification des éléments– IHM– Développement jetable
destiné à valider une hypothèse
• Prototype– Version préliminaire ou
système incomplet destiné à un essai grandeur nature
Unified Process
Unified Process – suite
Unified Process – suite
• 4 phases :– INCEPTION (10%)
• Lancement
– ELABORATION (30%)• Analyse, spécification
– CONSTRUCTION (50%)• Développement du logiciel
– TRANSITION (10%)• Mise en œuvre
• Langage de modélisation : UML
Unified Process - suite
• Inception (mise en route)– Objectifs
• périmètre, use case critiques, architecture, risques, coûts, délai
– Activités• énoncer le contexte, les
exigences, les contraintes, planifier
– Artefacts • documents de vision, plan
projet, étude rentabilité
Unified Process - suite
• Elaboration– Objectifs
• valider l’architecture, vision de réf, plan de réf
– Activités• étude des cas d’utilisation,
définition de l’environnement de dév, élaborer l ’architecture
– Artefacts• un modèle de use case (80%),
description logicielle, prototype, manuel utilisateur
Unified Process - suite
• Construction– Objectifs
• Fournir une version beta, minimiser les coûts, qualité
– Activités• gérer les ressources,
développer et tester
– Les artefacts• le logiciel, manuel
d’utilisation, description de la version
Unified Process - fin
• Transition– Objectifs
• mise en œuvre, livrer une version finale, former les utilisateurs
– Activités• beta test, mettre en service,
former, améliorer les perf
– Artefacts• néant
Two Track Unified ProcessBranche
fonctionnelle
Capture des besoins
Spécifications fonctionnelles
Analyse
Capture des besoins techniques
Architecture logicielle et applicative
Frameworks techniques
Déploiement
Recette
Test
Codage
Conception
Branche technique
Phase deréalisation
Capability Maturity Model
• Outil d’évaluation de la capacité en terme de développement logiciel – Management– Développement– Maintenance
• Processus continu d’amélioration fondé sur une démarche par paliers
Capability Maturity Model
5 niveaux de maturité
eXtreme Programming
• L'eXtreme Programming est une méthode de développement logiciel mettant en oeuvre des processus agiles et dont l'objectif est la simplicité.
• La mise en oeuvre d'XP s'appuie sur une équipe unie permettant une communication rapide entre tous les acteurs du projet
eXtreme Programming - suite• Principales caractéristiques
– 1 représentant du client est intégré à plein temps dans l’équipe informatique
– Programmation en binôme
– Écriture des tests avant codage
– Intégration continue dès le début du projet
– Livraisons fréquentes
Typologie des méthodes
Cascade
Itératif
Formalisme
CMM
Cycle en V
Merise
UP
2TUP
XP
Partie III : eXtreme Programming
Pacifacile…
Prise en compte des risques
Risque Solution XP
Dép. délai Cycles courts (1)
Abandon Cycles courts
Détérioration Tests (2)
Défaillance Tests
Inadéquation Client intégré (3)
Évolution besoin (1) + (2)
Fonct. inutiles Priorités
Turnover Responsabilisation
Les 4 variables
• Coûts– Avoir le « bon » budget
• Délais– Augmentation des délais
• Amélioration qualité• Diminution du feedback
• Qualité– Délicate à piloter
• Périmètre– Définir et résoudre le
problème essentiel
Les 4 valeurs
• Communication– Essentielle au déroulement
du projet
• Simplicité– Éviter l’usine à gaz…
• Feedback– Tester le système
• Courage– Accepter le refactoring
Les principes fondamentaux
• Accélérer le feedback– Tests, cycles de livraison courts
• Supposer la simplicité– …quitte à complexifier ensuite
• Changer de façon incrémentale– Modifier par étapes
• Accueillir le changement– Rester disponible
• Chercher la qualité– Pour mieux travailler
Autres principes• Apprendre à apprendre• Réduire l’investissement initial• Jouer pour gagner• Expérimenter dans le concret• Communiquer ouvertement et
honnêtement• Exploiter l’instinct des gens• Accepter ses responsabilités• Adapter les principes si nécessaire• Voyager léger• Mesurer sans tricher
Le code
• Coder– Formuler, mettre en œuvre
• Tester– Fiabiliser, augmenter la
confiance
• Écouter– Problématique client,
équipe de développement
• Concevoir– Organiser le système
Mise en œuvre XP
• Jeu du planning– But : définir et mettre à jour
le périmètre, les livraisons et le planning
– Moyen : utiliser un jeu pour dépassionner le dialogue MOE/MOA
• Petites livraisons– But : définir les livraisons
les plus petites/pertinentes possibles
Mise en œuvre XP – suite
• Métaphore– But : identifier simplement
les composants du système
• Conception simple– Moyens : tests, refactoring,
programmation en binôme
• Tests– But : fiabiliser– Moyens : tests unitaires,
tests fonctionnels
Mise en œuvre XP - suite
• Refactoring– But : adapter le système– Moyens : tests, conception simple,
programmation en binômes
• Programmation en binômes– Mode : un membre au clavier, l’autre
avec plus de recul
• Responsabilité collective du code– Mode : tout le monde peut modifier
le code à tout moment
Mise en œuvre XP - suite
• Intégration continue– But : intégrer continûment les
développements
• Heures travaillées– Inutile d’accumuler des heures
supplémentaires
• Client sur site– But : s’assurer en permanence
de l’adéquation
• Règles de codage– But : améliorer la communication
Annexe
Compléments UML
Qu’est-ce que UML ?
• Unified Modeling Language– Langage graphique de
modélisation des données et des traitements
– Adapté aux langages Orientés Objet
– Utilisé dans certaines méthode (UP)
Modélisation• Aspect Fonctionnel
– Objectif : décrire les fonctionnalités du système du point de vue de l’utilisateur
– Diagrammes : cas d’utilisation, …
• Aspect Donné/Objet– Objectif : décrire la structuration du
système en objets, attributs, opérations et associations
– Diagrammes : de classe, d’objet, …
• Aspect Dynamique– Objectif : décrire le comportement
interne du système– Diagrammes : de séquence, …
Diagrammes structurels
• Diagramme de classe (L1)• Diagramme d’objet (L1)• Diagramme de composant
– Décrire la décomposition d’un logiciel en composants physiques (fichiers, librairies, packages) et la relation entre ces composants
Références