CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel

Présentation au sujet: "CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel"— Transcription de la présentation:

1 CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel
eXtreme Programming CNAM – GLG102 – Techniques et Normes pour la Qualité du Logiciel 26/01/2007 François Potentier

2 Sommaire Qu’est-ce que XP ? Le changement comme valeur du projet
Éléments fondamentaux de XP Modèle de développement Cycle de vie Management Outils Adopter XP XP et Qualité

3 I. Qu’est-ce que XP ? Méthode de développement
Rassemblement de bonnes pratiques déjà connues et utilisées Une des méthodes agiles Récente : 1999 Bilan des premiers retours : fin 2004 Prend son essor début com Méthode encore récente donc en évolution .com => mise sur le marché rapide nécessaire. Les méthodes traditionnelles ne sont pas adaptées.

4 Caractéristiques des méthodes agiles – Agile Manifesto
I. Qu’est-ce que XP ? Caractéristiques des méthodes agiles – Agile Manifesto Travail d’équipe VS Process et outils Logiciel qui fonctionne VS Documentation Collaboration client VS Contrat blindé Ouverture au changement VS Suivre un plan

5 II. Changement – valeur du projet
Le changement est la seule constante dans un projet => l’inclure dans le projet => abaisser les coûts du changement Outils adéquats Bonnes pratiques au quotidien – Développement Bonnes pratiques au quotidien – Management

6 III. Éléments fondamentaux d’XP
5 valeurs  les racines Communication Simplicité Feedback Courage Respect 5 principes essentiels  les guidelines Accélérer le feedback Supposer la simplicité Changer de façon incrémentale Accueillir le changement Chercher la qualité Mise en œuvre dans les pratiques au quotidien

7 IV. Modèle de développement
Modèle de développement INCREMENTAL Cycle de vie en SPIRALE Petites livraisons : entre 1 et 2 mois Itérations : entre 2 à 3 semaines

8 V. Cycle de vie - Spécifications
Client sur site Documentation minimale Il écrit les scénarios client – fiches scénarios Il choisit les scénarios de la prochaine livraison Il les classe par importance d’un point de vue utilisateur

9 V. Cycle de vie - Planification
Planning de livraison – CLIENT A partir des scénarios écrits par le client L’équipe estime les scénarios Le client classe les scénarios par importance L’équipe donne au client le nombre de points à dépenser Il choisit les scénarios de la prochaine livraison Planning d’itération – EQUIPE Le client peut changer d’avis au début d’une itération Les fiches de scénario donnent des fiches de tâches Choix des tâches puis estimation personnelle Nivellement des charges de travail

10 V. Cycle de vie - Planification
Distinction temps technique idéal – vélocité Temps technique idéal  Temps que l’on mettrait sans être dérangé, sans réunion… Correspond à une charge de travail Vélocité  Temps calendaire pour réaliser la charge de travail estimée Vélocité itération courante = vélocité constatée pour itération précédente Total scénarios choisis ne dépasse pas la vélocité

11 V. Cycle de vie - Planification
Choix : Le client choisit le contenu => date déduite Le client fixe la date => contenu adapté On privilégie : Fréquence fixe Variation du périmètre

12 V. Cycle de vie - Conception
Une conception simple Le système répond aux scénarios du client. Aucune anticipation des problèmes futurs Architecture obtenue lors de la première itération Graphes de conception maintenus à jour

13 V. Cycle de vie – Développement
Responsabilité collective du code  Chacun intervient sur tout le projet Programmation en binômes Code de meilleure qualité Partage des connaissances Évite les retours à « l’état sauvage » Refactoring permanent Éliminer toute flexibilité inutile Ajouter de la souplesse en cas de besoin Améliorer le code en le rendant plus clair

14 V. Cycle de vie – Développement
Conventions de nommage Utilisation de métaphores Parler un langage commun dans l’équipe Meilleur dialogue entre fonctionnel et technique Rythme soutenable  Pas d’heures supplémentaires plus de 2 semaines consécutives

15 V. Cycle de vie - Intégration
Intégration continue Plusieurs fois par jour pour chaque binôme Tâches d’une granularité de quelques heures Évite le rush de l’intégration avant la livraison : tous les jours une version stable du logiciel est disponible.

16 V. Cycle de vie – Tests unitaires
Écriture systématiques de tests unitaires  Clé de voûte de la méthode  Priorité numéro 1 du programmeur Écrits avant le code  le code est terminé quand tous les tests unitaires imaginés passent Conservés sans limite de temps Exécutés en totalité à chaque build Exécution automatique

17 V. Cycle de vie – Tests fonctionnels
Écriture de tests fonctionnels Écrits par le client avec l’aide de l’équipe Au moins un testeur technique pour assister le client Itération terminée quand tous les tests fonctionnels passent.

18 VI. Management Responsabilité forte de l’équipe - dilution du rôle de chef de projet Coach Mise en œuvre de la démarche Amélioration du fonctionnement de l’équipe Tracker Responsable des indicateurs S’occupe du jeu du planning Mesure l’avancement Manager Interface avec le reste de l’organisation S’occupe des problèmes matériels de l’équipe Vérifie que les résultats sont là

19 VII. Outils – Gestion de projet
Outils papier – le tableau ostentatoire A étoffer avec des screenshots

20 VII. Outils – Gestion de projet
Outils classiques MS Project : non adapté Outils agiles : gestion d’une liste de tâche, pas de synchro entre les tâches. Important : charge de travail cohérente et date atteignable. Hansoft XPlanner Bugs trackers étendus JIRA Mantis…

21 VII. Outils – Dvt-Intégration-Tests
Souplesse et ciblage des modifications  Langage objets : Java sous Eclipse (C# en .NET) Graphes de conception  UML : eUML2 pour Eclipse, cohérence graphes-code Tests unitaires  Framework de tests : JUnit pour Eclipse (NUnit en .NET) Contrôle de version  Subversion, Subversive/Subclipse pour Eclipse Intégration continue et tests unitaires automatiques  CruiseControl VIII. V

22 VIII. Adopter XP - … ou pas
Utiliser XP quand… Besoins flous Périmètre mal défini Petite équipe – 12 personnes maximum Site unique Pas de sous-traitance Ne pas utiliser XP si… Besoins changeront peu Périmètre bien défini Équipe de plus de 12 personnes Dvt multi-sites Dvt off-shore Projets critiques

23 VIII. Adopter XP – Comment ?
Appliquer les recommandations de la méthode : par petites touches Le jeu du planning Tests unitaires et intégration continue avec mise en place de serveurs de builds Testeur technique pour les tests fonctionnels

24 VIII. Adopter XP - Difficultés
Implication forte du client nécessaire Entente parfaite entre les membres de l’équipe Synergie des pratiques entre elles => tout ou rien Abandon temporaire des tests unitaires => effondrement de l’édifice Contrats peu adaptés à XP

25 IX. XP et Qualité Définition AFNOR NF5019 : Aptitude d’un produit ou d’un service à satisfaire les besoins utilisateur Un produit est de qualité s’il répond aux exigences des utilisateurs, livré en temps voulu et au plus juste prix.

26 IX. XP et Qualité Norme ISO 9126 pour l’évaluation d’un logiciel
Capacité fonctionnelle OUI Fiabilité OUI Facilité d’utilisation OUI Rendement OUI Maintenabilité OUI Adaptabilité ?

27 IX. XP et Qualité - les Normes
Esprit d’amélioration permanente existe mais à l’intérieur du projet seulement Côté industriel n’existe pas : absence de documentation : réussite du projet dépend de l’équipe plus que de processus définis XP adapté n’est pas contradictoire avec les normes

28 CONCLUSION Plus une discipline au quotidien et un état d’esprit qu’une méthode Première approche d’organisation Limites assez vite atteintes XP est en pleine évolution – 6 ans Fait avancer la réflexion sur les méthodes Devient un argument commercial Bien adapté au jeu vidéo

29 Questions ?