Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques

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

description

 

Transcript of Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques

Page 2: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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 5: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 5

Protéger l’équipeProtéger l’équipe

Page 6: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 7

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

Page 8: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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 9: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 9

Pratique de l’XPPratique de l’XP

Page 10: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 10

Le cycle itératifLe cycle itératif

1ère Itération 2ème Itération 3ème Itération

Page 11: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 13

Intégration ContinueIntégration Continue

Développeur

HudsonIntégration Continue

Métriques

Anomalies

Page 14: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 31

Coût des bugsCoût des bugs

http://www.agitar.com/solutions/why_unit_testing.html

Page 32: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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 39: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 39

Scrum – backlogScrum – backlog

Page 40: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 40

Scrum – Sprint backlogScrum – Sprint backlog

Page 41: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 41

Scrum - Mêlée quotidienneScrum - Mêlée quotidienne

Page 42: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 42

Scrum – burndown chartScrum – burndown chart

Page 43: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 43

Scrum – Sprint review and retrospectiveScrum – Sprint review and retrospective

Page 44: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 44

Lean - WasteLean - Waste

Page 45: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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.

Emmanuel Hugonnet
Mura: unevenness of flow. Thus, the first thing to do is establish a reasonable pull, an even flow.Muri: overburdening the system. (System being the overall thing you are talking about; generally not a computer system.) Thus, once you establish a production "pipe", don't try to force more through that pipe that it can handle. As an fluid dynamics person will tell you, that means even less liquid will travel through the pipe in a given time period.Muda: waste. This is further defined by Type I and Type II muda. And by the classic 7 wastes. "Muda" is an ugly work in Japanese. Kind of like an earthy but dirty Anglo-Saxon word, I think.
Page 46: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

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

Page 50: Industrialisation Du Logiciel  - Introduction Et Bonnes Pratiques

Page 50

Questions?Questions?