Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4

Industrialisation du logiciel Introduction et bonnes pratiques Emmanuel HUGONNET Architecte Technique / Expert Java EE http://www.ehsavoie.com e [email_address] +334 76 24 86 58 17 novembre 2008
Support en version 1.4

Critères d’appréciation selon les profils Utile Evolutif Maintenable Exploitable Ergonomique Performant Ouvert Fiable Utilisateur Développeur Marketing Exploitation Perception des critères de qualité

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

Organiser l’équipe
Sé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

Protéger l’équipe

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

Pourquoi un changement de mentalité est il nécessaire ?

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

Pratique de l’XP

Le cycle itératif 1 ère Itération 2 ème Itération 3 ème Itération

Le 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

S’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

Intégration Continue Développeur Hudson Intégration Continue Métriques Anomalies

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

Bonnes 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

Gérer les exigences
Parler aux utilisateurs
Document de spécifications fonctionnelles
Maquette
Story board
Prototype technique
Prototype fonctionnel
Portail projet

Tracer 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

Concevoir et développer
Architecture 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é

Découpage
Utiliser 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

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

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

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

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

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

Documentation
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

Qualité 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 classes Classes décrivant une structure Classes complexes avec toute l’intelligence Loc/classe Nb classes

Couplage 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

Mesurer la qualité du code
Des 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)

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

Tests automatisés
Tests 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

Coût des bugs http://www.agitar.com/solutions/why_unit_testing.html

Test 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 …..

Gestion 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

Refactoring
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

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)

Méthodologies
Scrum : 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

Scrum – backlog

Scrum – Sprint backlog

Scrum - Mêlée quotidienne

Scrum – burndown chart

Scrum – Sprint review and retrospective

Lean - Waste

Lean – 10 Points
Eliminer 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.

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* :

Lean 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 La perfection est l’ennemi du bien Confiance, Capital Humain Culture Hautement Collaborative Agile

Agile 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%."

Conclusion
Dans 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

Questions?

Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4

by Emmanuel Hugonnet

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4 Presentation Transcript