Télécharger 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
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.