É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