Éléments de Méthodologie Informatique Illustration : 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 Méthodes & Standards 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 profession in 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 …

Gestion de la production Problématique projet Gestion de la production Objectif Moyens Délais Gestion des moyens Gestion des délais

Métiers Maîtrise d’ouvrage (utilisateur) Maîtrise d’œuvre (concepteur) Chef de projet MOA Expert métier Utilisateur Maîtrise d’œuvre (concepteur) Chef de projet MOE Concepteur/Développeur Intégrateur …

Historique 1945 : 1955 : 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 : 1990 : 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 3 - Réalisation 2 - Conception 1 - Analyse

Modèle en spirale - suite

Modèle itératif Nouveau Besoin Élaboration Faisabilité Fabrication Transition Exploitation ou Test

Merise Étapes Outils Délivrables Modèle Organisationnel des Traitements Modèle Conceptuel des Données Modèle Conceptuel des Traitements Modèle Logique des Données Étude préalable Étude détaillée Réalisation Délivrables Maquettes Prototypes Mise en oeuvre

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 Activités Artefacts 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 Process Branche fonctionnelle Branche technique Capture des besoins techniques Capture des besoins Architecture logicielle et applicative Spécifications fonctionnelles Frameworks techniques Analyse Conception Codage Test Recette Phase de réalisation Déploiement

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 Cycle en V Merise CMM 2TUP Formalisme XP UP Itératif

Partie III : eXtreme Programming Pacifacile…

Prise en compte des risques 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 Délais Qualité Périmètre Avoir le « bon » budget 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 Simplicité Feedback Courage 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 Tester Écouter Concevoir Formuler, mettre en œuvre Fiabiliser, augmenter la confiance Écouter Problématique client, équipe de développement Concevoir Organiser le système

Mise en œuvre XP Jeu du planning Petites livraisons 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 Conception simple Tests 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 Programmation en binômes 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 Heures travaillées 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 Aspect Donné/Objet Aspect Dynamique 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