Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques

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

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