SlideShare une entreprise Scribd logo
1  sur  26
Télécharger pour lire hors ligne
Génie Logiciel
CYCLE DE VIE DU LOGICIEL( SUITE)
EXTREME PROGRAMMING(XP)
Extreme Programming (XP)
 Emphase sur la satisfaction du client
 le produit dont il a besoin
 des livraisons aux moments où il en a besoin
 un processus robuste si les exigences sont modifiées
 Emphase sur le travail d'équipe
 managers, clients, développeurs : ensemble
Caractéristiques du Extreme
Programming
 Communication
 programmeurs avec clients et autres programmeurs
 Simplicité
 design propre et simple
 Feedback
 test du code dès le premier jour
 Livraison
 aussi tôt que possible
 adaptabilité à des changements d'exigences ultérieurs
Succès de Extreme Programming
(« pur » ou adapté)
 Applications :
 comptabilité de Chrysler (gestion de 10.000 employés)
 banque, assurance vie, automobile...
 Plusieurs conférences, livres, sites, forums, outils, ...
 Sociétés spécialisées dans la formation à XP
 Associations dans le monde (XP-France, ...)
 Utilisateurs de XP (entre autres modèles) :
 IBM, Xerox, Nortel, Cisco, Symantec, Sun, ...
Extreme Programming
Quatre types d'activité :
 Planification
 Design
 Codage
 Test
Extreme Programming :
Planification
Scénarios d'utilisation (« user's stories »)
 écrits par les utilisateurs : ce que ça doit faire pour eux
 utilisés à la place d'un cahier des charges (!)
 base pour estimer les dates de livraison (priorités)
 base pour les tests de recette
Extreme Programming :
Planification
 Division du projet en « itérations » successives
 itération ~ tâche unitaire
 durée : 1 à 3 semaines
 Planning de l'itération
 en tout début de l'itération
suit mieux des besoins évolutifs
 Principe :
 ne pas implémenter ce qui n'est pas dans l'itération
 si semble déborder, créer une nouvelle itération
Extreme Programming :
Planification
 Nombreuses livraisons intermédiaires (!)
 retour (feedback) des clients au plus tôt
 planifier les fonctionnalités importantes en premier
 Planning des livraisons
 selon le nombre de scénarios à implémenter avant une date donnée
pour l'itérations à venir
Extreme Programming :
Planification
 Mesure de la vitesse de réalisation du projet
 temps effectivement passé / temps prévu
 Réunion « debout » quotidienne (!)
 forme : tous les matins, courte (pas de longs meetings)
 contenu : problèmes, solutions, focalisation
 Changer les règles quand ça ne marche pas (!)
Extreme Programming : Design
 Faire simple (!)
 c'est plus rapide
 c'est moins cher
 Pas de nouvelle fonctionnalité si pas utile
 a priori, n'encourage pas la généricité et la réutilisabilité
Extreme Programming : Design
 Restructurer sans pitié (!)
 partout et dès que possible
 opérations : « refactoring »
 nettoyage
 simplification
 élimination des redondances et du code inutilisé
 rajeunissement des designs obsolètes
 gagne du temps et améliore la qualité
Extreme Programming : Codage
 Avoir le client toujours disponible (!)
 ajout de détails au scénario pour définir le codage
 feedback sur les développements
 participation aux tests fonctionnels
En théorie :
 acceptable pour le client car il fait des économies (pas de cahier des charges...)
En pratique :
 disponibilité fréquente difficile à organiser
 pas facile de faire tenir ses promesses au client
Extreme Programming : Codage
Coder les tests (unitaires) en premier (!)
 programmation ultérieure plus facile et plus rapide
 fixe la spécification (ambiguïtés) avant le codage
 feedback immédiat lors du développement
 processus :
 créer un test pour un petit aspect du problème
 créer le bout de code le plus simple qui passe le test
 itérer jusqu'à ce qu'il n'y ait plus rien à tester
(☛ temps d'écriture des tests ~ temps de programmation)
Extreme Programming : Codage
 Programmation en binôme (!)
 deux personnes, un seul PC
 quand l'un crée le code d'une fonction
 l'autre se demande comment elle s'insère dans le reste
 contre-intuitif, pourtant :
 Même délai
 Mais meilleure qualité
 Suivre des standards de codage
 cohérence globale
 code lisible / modifiable par toute l'équipe
Extreme Programming : Codage
 Intégration séquentielle (!)
 un binôme à la fois
 préparée en local et avant diffusion
 réduit les problèmes d'intégration
 combinatoire des problèmes unitaires
 chasse aux bugs inexistants (vieilles versions)
Extreme Programming : Codage
 Intégration fréquente (!)
 > 1 fois / jour
 évite : divergences, efforts fragmentés
 permet : diffusion rapide pour la réutilisation
 N.B. il faut que les tests unitaires courants soient OK
Extreme Programming : Codage
 Possession du code collective
 tout le monde peut contribuer à tout (!)
nouvelles fonctionnalités, correction de bogues (bug fix),
restructurations (refactoring)
pas de personnes dépositaires de droits exclusifs
 OK parce que :
chacun teste ce qu'il développe
les tests unitaires sont accessibles à tous
intégrations fréquentes
→ extensions et réparations passent inaperçues
Extreme Programming : Codage
 N'optimiser qu'à la fin (!)
 ne pas chercher à deviner les goulots d'étranglement
 mais les mesurer
« make it work, make it right, then make it fast »
 Pas d'heures supplémentaires (!)
 affaiblit la motivation
 en cas de problème, changer l'objectif
 ne pas ajouter de nouvelles personnes pour combler le retard
Extreme Programming : Test
 Tout bout de code doit avoir ses tests unitaires
 besoin d'un environnement (framework) de test :
 automatisation, gestion
 créer les tests avant de coder
 tests archivés avec le source correspondant
 semble coûteux mais très rentable au final
 rend possible : restructuration, intégration fréquente
Extreme Programming : Test
 Tests de recette (acceptance tests)
 créés à partir des scénarios des utilisateurs
 pour tout scénario qui apparaît dans l'itération
 un scénario → un ou plusieurs tests de recette
 tests « boîte noire » (sans connaître le contenu)
 teste ce que ça fait sans savoir comment ça le fait
 aussi utilisés pour non-régression avant distribution
 exécutés aussi souvent que possible
 client = responsable de la validité et priorité de ces tests
Extreme Programming : Test
 Pas de distribution sans 100% des tests OK
 Quand un bug est trouvé, ajouter un test
→ éviter qu'il ne revienne
Rôles dans le XP
Une équipe, plusieurs rôles
 Client
 Spécifie les demandes et les tests client
 Planifie en tenant compte de la VA des demandes
 Développeur
 Estime les demandes et réalise le codage
 Manager
 Fait confiance et aplanie le terrain,
 Facilite le travail de l’équipe
 Testeur/Analyste
 Consultant
 Coach
 …
Critique de l’Extreme Programming
Contraintes de délai (client ou time-to-market)
 documents de spécification et de conception
 peu précis, ambigus, absents, parfois faits plus tard
 codage
 bâclé, peu documenté, code refait (peu réutilisé), ...
 tests
 temps de préparation des tests avant le codage du logiciel
 unitaires : rares ou absents (faits « au vol » et perdus)
 intégration : peu de tests de non-régression
 qualification
 seule vraie épreuve (mais bien trop tard !)
Avantages du XP
 Rassembler toutes les pratiques connues
 Les pousser à l’extrême
 Revue de code effectué en binôme
 Préparation des tests automatiques avant le codage
 Conception en permanence
 Simplicité
 Intégration de modules par binôme
 Chaque binôme a accès aux codes des autres
 Evolution cycle très rapide et intégration continue
À retenir
 La création logicielle suit un cycle de vie
 Ne pas rester figé dans un modèle : l'/s'adapter
 Importance de la planification
 découpage en tâches (parallèles, indépendantes)
 ne pas oublier : tâche d'intégration
 surtout ne pas oublier : contrôle (revues, tests, ...)
 mais uniquement en fonction des besoins identifiés
FIN
MERCI

Contenu connexe

Tendances

La revue de code : facile !
La revue de code : facile !La revue de code : facile !
La revue de code : facile !Lucian Precup
 
BBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - PuppetBBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - PuppetOlivier BAZOUD
 
Human Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDDHuman Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDDXavier NOPRE
 
Intégration continue
Intégration continueIntégration continue
Intégration continueKlee Group
 
Pourquoi vous ne pouvez pas tester votre code
Pourquoi vous ne pouvez pas tester votre codePourquoi vous ne pouvez pas tester votre code
Pourquoi vous ne pouvez pas tester votre codeRémi Lesieur
 
Sonar 2.0 au JUG Genève
Sonar 2.0 au JUG GenèveSonar 2.0 au JUG Genève
Sonar 2.0 au JUG GenèveFreddy Mallet
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileDenis Voituron
 
Soirée Qualité Logicielle avec Sonar
Soirée Qualité Logicielle avec SonarSoirée Qualité Logicielle avec Sonar
Soirée Qualité Logicielle avec SonarElsassJUG
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingGeeks Anonymes
 
Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Elapse Technologies
 
Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Sylvain Leroy
 
Concept de l’Intégration Continue
Concept de l’Intégration ContinueConcept de l’Intégration Continue
Concept de l’Intégration ContinueFrédéric Sagez
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsAgile Tour 2009 Québec
 
Intégration continue transco
Intégration continue transcoIntégration continue transco
Intégration continue transcolaurent_opnworks
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2Christophe Rochefolle
 
Integration continue et déploiement automatisé
Integration continue et déploiement automatiséIntegration continue et déploiement automatisé
Integration continue et déploiement automatiséJérémie Campari
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyonClement Bouillier
 

Tendances (20)

Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
La revue de code : facile !
La revue de code : facile !La revue de code : facile !
La revue de code : facile !
 
BBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - PuppetBBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - Puppet
 
Human Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDDHuman Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDD
 
Intégration continue
Intégration continueIntégration continue
Intégration continue
 
Pourquoi vous ne pouvez pas tester votre code
Pourquoi vous ne pouvez pas tester votre codePourquoi vous ne pouvez pas tester votre code
Pourquoi vous ne pouvez pas tester votre code
 
Sonar 2.0 au JUG Genève
Sonar 2.0 au JUG GenèveSonar 2.0 au JUG Genève
Sonar 2.0 au JUG Genève
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
 
Soirée Qualité Logicielle avec Sonar
Soirée Qualité Logicielle avec SonarSoirée Qualité Logicielle avec Sonar
Soirée Qualité Logicielle avec Sonar
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
 
Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29
 
Rappels Modularisation application C/C++
Rappels Modularisation application C/C++Rappels Modularisation application C/C++
Rappels Modularisation application C/C++
 
Concept de l’Intégration Continue
Concept de l’Intégration ContinueConcept de l’Intégration Continue
Concept de l’Intégration Continue
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
 
Normandy JUG integration Continue
Normandy JUG integration ContinueNormandy JUG integration Continue
Normandy JUG integration Continue
 
Intégration continue transco
Intégration continue transcoIntégration continue transco
Intégration continue transco
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Integration continue et déploiement automatisé
Integration continue et déploiement automatiséIntegration continue et déploiement automatisé
Integration continue et déploiement automatisé
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
 
Valider par des tests - Blend
Valider par des tests - BlendValider par des tests - Blend
Valider par des tests - Blend
 

Similaire à 4-Cours de Géniel Logiciel

[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement MicrosoftChristophe HERAL
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agilelaurent bristiel
 
2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciellauraty3204
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange LabsEmmanuel Hugonnet
 
Optimisation des applications Windows 8/HTML5/WinJS
Optimisation des applications Windows 8/HTML5/WinJSOptimisation des applications Windows 8/HTML5/WinJS
Optimisation des applications Windows 8/HTML5/WinJSMicrosoft
 
Test driven development v0.2 20121221
Test driven development v0.2 20121221Test driven development v0.2 20121221
Test driven development v0.2 20121221Frédéric Delorme
 
Industrialisez vos projets Php
Industrialisez vos projets Php Industrialisez vos projets Php
Industrialisez vos projets Php ALTER WAY
 
AgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFSAgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFSAgile Toulouse
 
Une application sans framework en 2019
Une application sans framework en 2019Une application sans framework en 2019
Une application sans framework en 2019Rodrigue Villetard
 
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ? TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ? Christophe HERAL
 
Test unitaires - refactoring - clean code
Test unitaires - refactoring - clean codeTest unitaires - refactoring - clean code
Test unitaires - refactoring - clean codeHadrien Blanc
 
20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache MavenArnaud Héritier
 
Les nouveautés de Visual Studio 11
Les nouveautés de Visual Studio 11Les nouveautés de Visual Studio 11
Les nouveautés de Visual Studio 11Microsoft
 
Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilNormandy JUG
 
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4Emmanuel Hugonnet
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_finalagnes_crepet
 

Similaire à 4-Cours de Géniel Logiciel (20)

Xtreme Programming
Xtreme ProgrammingXtreme Programming
Xtreme Programming
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agile
 
2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange Labs
 
Optimisation des applications Windows 8/HTML5/WinJS
Optimisation des applications Windows 8/HTML5/WinJSOptimisation des applications Windows 8/HTML5/WinJS
Optimisation des applications Windows 8/HTML5/WinJS
 
Test driven development v0.2 20121221
Test driven development v0.2 20121221Test driven development v0.2 20121221
Test driven development v0.2 20121221
 
Industrialisez vos projets Php
Industrialisez vos projets Php Industrialisez vos projets Php
Industrialisez vos projets Php
 
AgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFSAgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFS
 
Une application sans framework en 2019
Une application sans framework en 2019Une application sans framework en 2019
Une application sans framework en 2019
 
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ? TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
 
Test unitaires - refactoring - clean code
Test unitaires - refactoring - clean codeTest unitaires - refactoring - clean code
Test unitaires - refactoring - clean code
 
20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven
 
Usine Logicielle 2013
Usine Logicielle 2013Usine Logicielle 2013
Usine Logicielle 2013
 
Les nouveautés de Visual Studio 11
Les nouveautés de Visual Studio 11Les nouveautés de Visual Studio 11
Les nouveautés de Visual Studio 11
 
Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
 
Tests Logiciel
Tests LogicielTests Logiciel
Tests Logiciel
 
Conformiq
ConformiqConformiq
Conformiq
 
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 

Plus de lauraty3204

1.1-Cours de Géniel Logiciel
1.1-Cours de Géniel Logiciel 1.1-Cours de Géniel Logiciel
1.1-Cours de Géniel Logiciel lauraty3204
 
13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciellauraty3204
 
12-Cours de Géniel Logiciel
12-Cours de Géniel Logiciel12-Cours de Géniel Logiciel
12-Cours de Géniel Logiciellauraty3204
 
11-Cours de Géniel Logiciel
11-Cours de Géniel Logiciel11-Cours de Géniel Logiciel
11-Cours de Géniel Logiciellauraty3204
 
10-Cours de Géniel Logiciel
10-Cours de Géniel Logiciel10-Cours de Géniel Logiciel
10-Cours de Géniel Logiciellauraty3204
 
9-Cours de Géniel Logiciel
9-Cours de Géniel Logiciel9-Cours de Géniel Logiciel
9-Cours de Géniel Logiciellauraty3204
 
7-Cours de Géniel Logiciel
7-Cours de Géniel Logiciel7-Cours de Géniel Logiciel
7-Cours de Géniel Logiciellauraty3204
 
6-Cours de Géniel Logiciel
6-Cours de Géniel Logiciel6-Cours de Géniel Logiciel
6-Cours de Géniel Logiciellauraty3204
 
5-Cours de Géniel Logiciel
5-Cours de Géniel Logiciel5-Cours de Géniel Logiciel
5-Cours de Géniel Logiciellauraty3204
 
3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciellauraty3204
 
1-Cours de Géniel Logiciel
1-Cours de Géniel Logiciel1-Cours de Géniel Logiciel
1-Cours de Géniel Logiciellauraty3204
 

Plus de lauraty3204 (12)

1.1-Cours de Géniel Logiciel
1.1-Cours de Géniel Logiciel 1.1-Cours de Géniel Logiciel
1.1-Cours de Géniel Logiciel
 
Documentation
DocumentationDocumentation
Documentation
 
13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel
 
12-Cours de Géniel Logiciel
12-Cours de Géniel Logiciel12-Cours de Géniel Logiciel
12-Cours de Géniel Logiciel
 
11-Cours de Géniel Logiciel
11-Cours de Géniel Logiciel11-Cours de Géniel Logiciel
11-Cours de Géniel Logiciel
 
10-Cours de Géniel Logiciel
10-Cours de Géniel Logiciel10-Cours de Géniel Logiciel
10-Cours de Géniel Logiciel
 
9-Cours de Géniel Logiciel
9-Cours de Géniel Logiciel9-Cours de Géniel Logiciel
9-Cours de Géniel Logiciel
 
7-Cours de Géniel Logiciel
7-Cours de Géniel Logiciel7-Cours de Géniel Logiciel
7-Cours de Géniel Logiciel
 
6-Cours de Géniel Logiciel
6-Cours de Géniel Logiciel6-Cours de Géniel Logiciel
6-Cours de Géniel Logiciel
 
5-Cours de Géniel Logiciel
5-Cours de Géniel Logiciel5-Cours de Géniel Logiciel
5-Cours de Géniel Logiciel
 
3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel
 
1-Cours de Géniel Logiciel
1-Cours de Géniel Logiciel1-Cours de Géniel Logiciel
1-Cours de Géniel Logiciel
 

4-Cours de Géniel Logiciel

  • 1. Génie Logiciel CYCLE DE VIE DU LOGICIEL( SUITE) EXTREME PROGRAMMING(XP)
  • 2. Extreme Programming (XP)  Emphase sur la satisfaction du client  le produit dont il a besoin  des livraisons aux moments où il en a besoin  un processus robuste si les exigences sont modifiées  Emphase sur le travail d'équipe  managers, clients, développeurs : ensemble
  • 3. Caractéristiques du Extreme Programming  Communication  programmeurs avec clients et autres programmeurs  Simplicité  design propre et simple  Feedback  test du code dès le premier jour  Livraison  aussi tôt que possible  adaptabilité à des changements d'exigences ultérieurs
  • 4. Succès de Extreme Programming (« pur » ou adapté)  Applications :  comptabilité de Chrysler (gestion de 10.000 employés)  banque, assurance vie, automobile...  Plusieurs conférences, livres, sites, forums, outils, ...  Sociétés spécialisées dans la formation à XP  Associations dans le monde (XP-France, ...)  Utilisateurs de XP (entre autres modèles) :  IBM, Xerox, Nortel, Cisco, Symantec, Sun, ...
  • 5. Extreme Programming Quatre types d'activité :  Planification  Design  Codage  Test
  • 6. Extreme Programming : Planification Scénarios d'utilisation (« user's stories »)  écrits par les utilisateurs : ce que ça doit faire pour eux  utilisés à la place d'un cahier des charges (!)  base pour estimer les dates de livraison (priorités)  base pour les tests de recette
  • 7. Extreme Programming : Planification  Division du projet en « itérations » successives  itération ~ tâche unitaire  durée : 1 à 3 semaines  Planning de l'itération  en tout début de l'itération suit mieux des besoins évolutifs  Principe :  ne pas implémenter ce qui n'est pas dans l'itération  si semble déborder, créer une nouvelle itération
  • 8. Extreme Programming : Planification  Nombreuses livraisons intermédiaires (!)  retour (feedback) des clients au plus tôt  planifier les fonctionnalités importantes en premier  Planning des livraisons  selon le nombre de scénarios à implémenter avant une date donnée pour l'itérations à venir
  • 9. Extreme Programming : Planification  Mesure de la vitesse de réalisation du projet  temps effectivement passé / temps prévu  Réunion « debout » quotidienne (!)  forme : tous les matins, courte (pas de longs meetings)  contenu : problèmes, solutions, focalisation  Changer les règles quand ça ne marche pas (!)
  • 10. Extreme Programming : Design  Faire simple (!)  c'est plus rapide  c'est moins cher  Pas de nouvelle fonctionnalité si pas utile  a priori, n'encourage pas la généricité et la réutilisabilité
  • 11. Extreme Programming : Design  Restructurer sans pitié (!)  partout et dès que possible  opérations : « refactoring »  nettoyage  simplification  élimination des redondances et du code inutilisé  rajeunissement des designs obsolètes  gagne du temps et améliore la qualité
  • 12. Extreme Programming : Codage  Avoir le client toujours disponible (!)  ajout de détails au scénario pour définir le codage  feedback sur les développements  participation aux tests fonctionnels En théorie :  acceptable pour le client car il fait des économies (pas de cahier des charges...) En pratique :  disponibilité fréquente difficile à organiser  pas facile de faire tenir ses promesses au client
  • 13. Extreme Programming : Codage Coder les tests (unitaires) en premier (!)  programmation ultérieure plus facile et plus rapide  fixe la spécification (ambiguïtés) avant le codage  feedback immédiat lors du développement  processus :  créer un test pour un petit aspect du problème  créer le bout de code le plus simple qui passe le test  itérer jusqu'à ce qu'il n'y ait plus rien à tester (☛ temps d'écriture des tests ~ temps de programmation)
  • 14. Extreme Programming : Codage  Programmation en binôme (!)  deux personnes, un seul PC  quand l'un crée le code d'une fonction  l'autre se demande comment elle s'insère dans le reste  contre-intuitif, pourtant :  Même délai  Mais meilleure qualité  Suivre des standards de codage  cohérence globale  code lisible / modifiable par toute l'équipe
  • 15. Extreme Programming : Codage  Intégration séquentielle (!)  un binôme à la fois  préparée en local et avant diffusion  réduit les problèmes d'intégration  combinatoire des problèmes unitaires  chasse aux bugs inexistants (vieilles versions)
  • 16. Extreme Programming : Codage  Intégration fréquente (!)  > 1 fois / jour  évite : divergences, efforts fragmentés  permet : diffusion rapide pour la réutilisation  N.B. il faut que les tests unitaires courants soient OK
  • 17. Extreme Programming : Codage  Possession du code collective  tout le monde peut contribuer à tout (!) nouvelles fonctionnalités, correction de bogues (bug fix), restructurations (refactoring) pas de personnes dépositaires de droits exclusifs  OK parce que : chacun teste ce qu'il développe les tests unitaires sont accessibles à tous intégrations fréquentes → extensions et réparations passent inaperçues
  • 18. Extreme Programming : Codage  N'optimiser qu'à la fin (!)  ne pas chercher à deviner les goulots d'étranglement  mais les mesurer « make it work, make it right, then make it fast »  Pas d'heures supplémentaires (!)  affaiblit la motivation  en cas de problème, changer l'objectif  ne pas ajouter de nouvelles personnes pour combler le retard
  • 19. Extreme Programming : Test  Tout bout de code doit avoir ses tests unitaires  besoin d'un environnement (framework) de test :  automatisation, gestion  créer les tests avant de coder  tests archivés avec le source correspondant  semble coûteux mais très rentable au final  rend possible : restructuration, intégration fréquente
  • 20. Extreme Programming : Test  Tests de recette (acceptance tests)  créés à partir des scénarios des utilisateurs  pour tout scénario qui apparaît dans l'itération  un scénario → un ou plusieurs tests de recette  tests « boîte noire » (sans connaître le contenu)  teste ce que ça fait sans savoir comment ça le fait  aussi utilisés pour non-régression avant distribution  exécutés aussi souvent que possible  client = responsable de la validité et priorité de ces tests
  • 21. Extreme Programming : Test  Pas de distribution sans 100% des tests OK  Quand un bug est trouvé, ajouter un test → éviter qu'il ne revienne
  • 22. Rôles dans le XP Une équipe, plusieurs rôles  Client  Spécifie les demandes et les tests client  Planifie en tenant compte de la VA des demandes  Développeur  Estime les demandes et réalise le codage  Manager  Fait confiance et aplanie le terrain,  Facilite le travail de l’équipe  Testeur/Analyste  Consultant  Coach  …
  • 23. Critique de l’Extreme Programming Contraintes de délai (client ou time-to-market)  documents de spécification et de conception  peu précis, ambigus, absents, parfois faits plus tard  codage  bâclé, peu documenté, code refait (peu réutilisé), ...  tests  temps de préparation des tests avant le codage du logiciel  unitaires : rares ou absents (faits « au vol » et perdus)  intégration : peu de tests de non-régression  qualification  seule vraie épreuve (mais bien trop tard !)
  • 24. Avantages du XP  Rassembler toutes les pratiques connues  Les pousser à l’extrême  Revue de code effectué en binôme  Préparation des tests automatiques avant le codage  Conception en permanence  Simplicité  Intégration de modules par binôme  Chaque binôme a accès aux codes des autres  Evolution cycle très rapide et intégration continue
  • 25. À retenir  La création logicielle suit un cycle de vie  Ne pas rester figé dans un modèle : l'/s'adapter  Importance de la planification  découpage en tâches (parallèles, indépendantes)  ne pas oublier : tâche d'intégration  surtout ne pas oublier : contrôle (revues, tests, ...)  mais uniquement en fonction des besoins identifiés

Notes de l'éditeur

  1. Les valeurs de l’extrême Programming: Communication, Simplicité, Feedback Courage et Respect
  2. L’itération consiste à répéter un processus ou une procédure=! L’Incrémentation consiste à ajouter 1
  3. L’objectif consiste à réaliser les tests avant le codage du logiciel, après il revient à adapter le code du logiciel aux différents tests; d’où TDD: Test Driven Devloppement
  4. Conception continue, à chaque collecte de besoins