Éléments de Méthodologie Informatique

Présentation au sujet: "Éléments de Méthodologie Informatique"— Transcription de la présentation:

1 Éléments de Méthodologie Informatique
Illustration : eXtreme Programming

2 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

3 Plan Panaroma général Méthodes & Standards
Définitions Problématiques Méthodes & Standards Typologie Principales méthodes Exemple : eXtreme Programming

4 Partie I : Panorama général
Dekoiçacôse ?

5 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

6 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 ?

7 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

8 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, …

9 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…

10 What for ? (metaphor) A physician, a civil engineer, and a
computer scientist were arguing about what was the oldest profession in the world.

11 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. »

12 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. »

13 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? »

14 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

15 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

16 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 …

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

18 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 …

19 Historique 1945 : 1955 : programmation en code binaire/assembleur
1 seul développeur projets de petite taille 1955 : Apparition des langages évolués projets + importants

20 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)

21 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, …)

22 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, …

23 Partie II : Méthodes & Standards
Voilacékoi !

24 Modèle en cascade

25 Cycle en V

26 Modèle en spirale 4 - Validation 3 - Réalisation 2 - Conception
1 - Analyse

27 Modèle en spirale - suite

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

29 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

30 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

31 Unified Process

32 Unified Process – suite

33 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

34 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é

35 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

36 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

37 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

38 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

39 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

40 Capability Maturity Model
5 niveaux de maturité

41 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

42 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

43 Typologie des méthodes
Cascade Cycle en V Merise CMM 2TUP Formalisme XP UP Itératif

44 Partie III : eXtreme Programming
Pacifacile…

45 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

46 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

47 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

48 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

49 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

50 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

51 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

52 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

53 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

54 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

55 Annexe Compléments UML

56 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)

57 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, …

58 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

59 Références