Upload
emmanuel-hugonnet
View
7.177
Download
3
Embed Size (px)
DESCRIPTION
Citation preview
Industrialisation du logiciel Industrialisation du logiciel Introduction et bonnes pratiques
Emmanuel HUGONNETArchitecte Technique / Expert Java EEhttp://www.ehsavoie.com
+334 76 24 86 58
17 novembre 2008
Support en version 1.4
Page 2
Critères d’appréciation selon les profilsCritères d’appréciation selon les profils
Utile Evolutif
Maintenable
Exploitable
Ergonomique
Performant
OuvertFiable
Utilisateur
DéveloppeurMarketing
ExploitationPerception des critères de qualité
Page 3
Lancer un projetLancer un projet
Une équipe de taille raisonnable:
Entre et
Munie des compétences adaptées
Spectre nécessaire couvert
Formations prévues en amont
Stable et disponible
Peu de mouvement
Pas à 50% sur autre chose
Suffisamment expérimentée
50% avec une expérience >= 3 ans (et encore mieux si 1 personne avec 6 – 7 ans d’expérience)
mh*2
*mh
Page 4
Organiser l’équipeOrganiser l’équipeSéparer les rôles (dans la mesure du possible)
D’organisation (Chef de projet)
Technique(Architecte, Expert)
Fonctionnel (Utilisateur, Expert)
Privilégier les tâches de support
L’encadrement doit être disponible
Il est d’abord là pour répondre aux questions
Favoriser le travail d’équipe:
Implication
Communication
Appropriation
Page 6
Dynamiser l’équipeDynamiser l’équipe
Privilégier la proximité :
un seul lieu de travail spacieux et agréable
Impliquer les utilisateurs :
Travailler près d’eux.
Formaliser la mise en commun :
Réunion ‘debout’ d’un quart d’heure quotidienne
Réunion d’avancement hebdomadaire
Réunion d’itération (mensuelle)
Page 7
Pourquoi un changement de mentalité est il Pourquoi un changement de mentalité est il nécessaire ?nécessaire ?
Page 8
AgilitéAgilitéLes principes
Parier sur les hommes et la communication plutôt que sur les processus et l’outillage.
Ecrire du logiciel qui fonctionne
Collaborer avec l’utilisateur plutôt que d’avoir une relation contractuelle
Réagir et d’adapter plutôt que de suivre un plan prédéfini
Un code professionnel
Les bonnes pratiques
Cycle itératif et incrémental
Proximité avec l’utilisateur
Intégration continue
Tests exhaustifs et systématiques
Gestion continue des évolutions
Page 10
Le cycle itératifLe cycle itératif
1ère Itération 2ème Itération 3ème Itération
Page 11
Le cycle itératifLe cycle itératif
Réduction des risques
Lancer les items les plus risqués le plus tôt possible
Mettre en œuvre le plus rapidement possible
S’adapter aux changements
Être réactif par rapport aux demandes des utilisateurs
Eviter l’effet tunnel
Valider qu’utilisateurs et développeurs ont la même vision
Démo de fin d’itération qui force à avoir un logiciel qui fonctionne et qui permet de prendre du recul pour l’itération suivante
Page 12
S’outillerS’outiller
Pour faire vivre le projet
Communication (forum, mailing list, Jabber …)
Documentation (wiki, Maven site, ….)
Gestion des anomalies (Trac, Bugzilla, …)
Gestion des tâches
Pour développer
Environnement de développement (IDE et plugins)
Outil de build (Maven, Ant, …)
Plate-forme d’intégration Continue (Hudson, Continuum, …)
Plate-forme de validation
Page 13
Intégration ContinueIntégration Continue
Développeur
HudsonIntégration Continue
Métriques
Anomalies
Page 14
Définir des actions QualitéDéfinir des actions Qualité
Relecture du code (au premier commit par exemple) par un pair.
Revue de code régulière au cours des itérations par le responsable qualité.
Audit(au hasard) par une personne extérieure au projet
Page 15
Bonnes pratiquesBonnes pratiques
Reconnaître la qualité de ce qui est fait
Ne pas oublier l’objectif qui est d’améliorer, de trouver une solution et non de critiquer.
Ne pas s’acharner à trouver la faute et à critiquer les individus
Ne pas alourdir les méthodes de travail
Page 16
Gérer les exigencesGérer les exigences
Parler aux utilisateurs
Document de spécifications fonctionnelles
Maquette
Story board
Prototype technique
Prototype fonctionnel
Portail projet
Page 17
Tracer les évolutionsTracer les évolutions
Pourquoi ?
Pour cibler les campagnes de tests
Pour rechercher les éventuelles régressions
Pour ne pas ré implémenter les anciennes anomalies
Quand ?
Au cours des itérations
Pendant la maintenance
Comment ?
Outil de gestion des exigences
Outils de gestion des sources
Outils de gestion des anomalies
Release notes
Page 18
Concevoir et développerConcevoir et développerArchitecture fonctionnelle
Processus métier
Découpage en modules fonctionnels
Architecture technique
Découpage en couches
Typologie des composants
Choix des technologies
L’architecture permet
De structurer et d’organiser
D’affronter rapidement le risque
De fournir un exemple à suivre
De prouver la faisabilité
Page 19
DécoupageDécoupageUtiliser une architecture simple
Le 2-tiers suffit souvent
Bien penser l’usage de frameworks ‘maison’
Découper l’application en modules
Par couche
Par sous système fonctionnel
Gérer les dépendances entre modules (JDepend)
Pas de dépendances circulaires
Réduire au maximum les dépendances
Utiliser l’IoC
Utiliser des interfaces
Page 20
Qu’est ce qu’une bonne conception ? Qu’est ce qu’une bonne conception ?
Distribuer les données et les traitements
De manière homogène (éviter les objets sans mémoire et sans intelligence: modèle anémique)
Cohérente : données et leurs traitements doivent être regroupés
Cela permet
Une bonne encapsulation
De remplacer un élément
De réduire l’impact d’une modification
Page 21
Comment faire une bonne conception ?Comment faire une bonne conception ?
Plusieurs façons
Par essai / erreur
Au contact d’experts
En formalisant l’expertise (design pattern)
Qu’est ce qu’un design pattern?
Une paire problème / solution
Réunis en catalogue (Gof, …)
Un vocabulaire
Page 22
Les bonnes pratiques de développement (1/3)Les bonnes pratiques de développement (1/3)Développement par l’exemple
L’expert construit un exemple complet que les développeurs reprennent
Pair programming
Deux développeurs : l’un qui guide et l’autre qui exécute ce qui permet une revue de code automatique (très pratique en cas de nouvelle technologie)
Support de proximité
L’expert travaille au sein du groupe
Page 23
Les bonnes pratiques de développement (2/3)Les bonnes pratiques de développement (2/3)
Solliciter si nécessaire les compétences spécialisées
Un ergonome pour l’ihm
Un designer pour la chartre graphique
Un pédagogue pour la documentation
Echanger les sujets entre développeurs ainsi le code devient la propriété de tous
Utiliser une convention de codage
Page 24
Les bonnes pratiques de développement (3/3)Les bonnes pratiques de développement (3/3)
Yagni (You Ain ’t Gonna Need It)
Ne faire que le besoin
Eviter de prévoir des fonctionnalités à l’avance
Kiss (Keep It Simple Stupid)
Faire au plus simple
Optimiser après et seulement si c’est nécessaire
DRY (Don’t Repeat Yourself)
Automatiser au maximum les taches
Ne pas copier/ coller de code
Page 25
DocumentationDocumentation
Commenter au plus près du code
Documentation pérenne (outils de génération automatique)
Commenter les en-têtes de classe et de méthode (éviter les commentaires au sein des méthodes)
Eviter les commentaires inutiles (getter / setter)
Rédiger des tutoriels cours (3-8 pages) regroupés dans un wiki
Page 26
Qualité du code objetQualité du code objet
Un ensemble riche de classes homogènes
La (non) qualité est généralement constatée quelque soit le critère : taille, couplage, complexité
Loc/classe
Nb c
lass
es
Classes décrivant
une structure
Classes complexes avec toute
l’intelligence
Loc/classe
Nb c
lass
es
Page 27
Couplage et cohésionCouplage et cohésion
Dans un code de qualité le couplage est faible
Couplage: densité des dépendances entre les classes
Et la cohésion est importante
Peu de responsabilité par classe
Peu de classes impliquées dans une responsabilité
Généralement les deux indices sont couplés :
Moins un logiciel est couplé et plus il et cohérent
Page 28
Mesurer la qualité du codeMesurer la qualité du codeDes classes de taille raisonnable
Entre 100 et 1000 lignes hors commentaires
250 en moyenne
Un nombre limité de méthodes par classe
Entre 3 et 20 (hors getter / setter)
Des méthodes de taille réduite
Entre 1 et 100 lignes (10 lignes en moyenne)
Moins de 10 paramètres (2 en moyenne)
Complexité faible (indice cyclomatique <= 10 dans 90% des cas)
Arbre d’héritage de faible hauteur (4 niveaux au maximum, 1 en moyenne)
Page 29
Protéger par le test automatiséProtéger par le test automatisé
Avantages du test automatisé
Maitrise des régressions
Documentation
Vérifie l’intégration
Conséquences
Exécuter un test ne coute rien
Le développeur se sent protégé
La couverture du code
Plus de 95% des lignes de code doivent être traversées par les tests
Mesure la qualité des tests
Page 30
Tests automatisésTests automatisésTests unitaires
Test en mode boite blanche
Utilisation d’un framework type XUnit
D’abord obtenir la couverture de code ( > 95%)
Reproduire chaque anomalie avec un test
Tests fonctionnels
Test en mode boite noire
Pré-enregistrement d’un ensemble d’opérations utilisateur
Réaliser un ensemble de scénarii des spécifications fonctionnelles
Tests de performance
Test en mode boite noire
Sur quelques scénarii représentatifs
Déclenché dans une simulation de l’environnement réel
Page 31
Coût des bugsCoût des bugs
http://www.agitar.com/solutions/why_unit_testing.html
Page 32
Test Driven DevelopmentTest Driven Development
Ecrire le test : il ne compile pas car il manque le code métier
Ecrire le code métier nécessaire à la compilation du test: le test est en échec
Écrire le code métier suffisant pour que le test s’exécute correctement
On transforme (refactoring) le code pour le rendre plus lisible et de meilleure qualité
Le test doit toujours s’exécuter correctement
On recommence …..
Page 33
Gestion des patchesGestion des patches
Un patch est une correction rapide
Pour répondre à une anomalie urgente
Pour tenir compte de la spécificité d’une plate-forme
Pour s’adapter à un composant extérieur
Les patches sont inévitables
Ils mettent en danger la qualité car ils sont mal testés et peu cohérents
Il faut gérer les patches
Les tracer (wiki, tracker, …)
Les documenter
Prévoir le refactoring
Page 34
RefactoringRefactoring
Modifier un code en profondeur
Iso fonctionnalités
Procéder par petites étapes et vérifier le bon fonctionnement à chaque étape
Pourquoi ?
Optimiser le code existant
Préparer de nouvelles fonctionnalités
Eviter les redondances
Rendre le code plus cohérent et plus lisible
Page 35
Comment faire ?Comment faire ?
S’outiller correctement (IDE récent)
Vérifier grâce aux tests automatisés
Plus la couverture de tests est importante et plus c’est efficace
Connaître les patterns de refactoring (Martin Fowler)
Page 36
MéthodologiesMéthodologiesScrum : Gestion de projet itérative et incrémentale (Microsoft, Nokia, Orange, …) .
Lean : Adaptation du système Toyota (http://www.poppendieck.com/)
Crystal Clear : Méthodologie agile adaptée à une équipe de moins de 10 personnes. (Alistair Cockburn )
Dynamic Systems Development Method
eXtrem Programming
Page 40
Scrum – Sprint backlogScrum – Sprint backlog
Page 41
Scrum - Mêlée quotidienneScrum - Mêlée quotidienne
Page 42
Scrum – burndown chartScrum – burndown chart
Page 43
Scrum – Sprint review and retrospectiveScrum – Sprint review and retrospective
Page 45
Lean – 10 PointsLean – 10 PointsEliminer les gaspillages. (muda)
Réduire les stocks.
Maximiser le flux (itérations brèves).
Faire selon la demande (décider le plus tard possible).
Donner du pouvoir à l’équipe (décider au plus près possible).
Répondre aux exigences des clients.
Faites le bien la première fois (intégrer les retours).
Abolir l’optimisation locale.
S’associer avec ses fournisseurs.
Créer une Culture de l’Amélioration Continue.
Page 46
Lean – Supprimer les gaspillages (muda)Lean – Supprimer les gaspillages (muda)
Travail partiellement fait (partially done work)
Processus inutiles (extra processes)
Développements ou fonctionnalités inutiles (extra features)
Passer d'un projet à l'autre (task switching)
Attentes (waiting) : supprimer les queues
Déplacements (motion)
Défauts, retouches (defects) : Do It Right the First Time
Gaspillages dans les projets SI selon Poppendieck* :
Page 47
La perfection est l’ennemi du bien
Confiance, Capital HumainCulture Hautement Collaborative
Agile
Lean et AgileLean et Agile
Equilibrer la demande en fonction du flux
Supprimer les Gaspillages
Amélioration Continue
Savoir que le travail est périssable
LEAN
http://www.agilemanagement.net/Articles/Weblog/FutureDirectionsforAgile.html
Page 48
Agile et CMMIAgile et CMMI
Mark Paulk, l’homme derrière CMM, est positif en ce qui concerne la méthodologie Agile and dit : "Agile Methods address many CMM level 2 and 3 practices".
XP, for example, addresses most level 2 and 3 practices, but not level 4 and 5.
Scrum correctement implémenté permet d’atteindre seul CMMI niveau 3.
Jeff Sutherland : "I think the cost of going to CMMI Level 5 starting with Scrum could be reduced by 50-80%. ... The process overhead of CMMI Level 5 with Scrum is 4%."
Page 49
ConclusionConclusionDans un projet la qualité n’est pas une étape c’est un principe
La (non) qualité entraine la (non) qualité
Un mauvais code est de moins en moins respecté
Les corrections sont plus difficiles
Faire simple
Faire ce qui est nécessaire et suffisant
Utiliser les technologies adaptées
Bâtir autour d’une architecture simple et raisonnable
Etre concret
Etablir une stratégie de développement
Procéder par l’exemple