UP-XP

Process unifiéAgilité

1

Demander le programme (1)LE PROCESSUS UNIFIE• Un processus itératif et incrémental.• Un processus piloté par les exigences utilisateurs.• L'architecture à base de composants.• La modélisation graphique UML.• La qualité du logiciel.• Le contrôle des changements.LES PHASES DU PROCESSUS UNIFIE• La phase d'inception.• La phase d'élaboration.• La phase de construction.• La phase de transition.LES CONCEPTS DU PROCESSUS UNIFIE• Les rôles.• Les activités et leurs enchaînements.• Les produits tangibles.

2

Demander le programme (2)LES ACTIVITES DU PROCESSUS UNIFIE• La modélisation métier.• La gestion des exigences.• L'analyse et la conception.• L'implémentation • Les tests.• Le déploiement.• La gestion de projet et l’environnement de développement• La gestion de la configuration et des changements. IMPLEMENTER LE PROCESSUS UNIFIE• La configuration.• La planification des itérations.• Les guides méthodologiques.• Les modèles de documents.VERS LES METHODES AGILES• Les concepts.• EXtreme programming : un exemple de méthode agile.

3

Plan du coursIndustrialisation des processus

• La gestion de projet classique• Les nouveaux concepts • Unified process• Vers l’agilité• Les tests (UP-XP)• Autres outils indispensables (UP-XP)

4

UP-XP

IntroductionGestion de projet

Les concepts de base (OO & UML)

5

Industrialisation

6

Les 4 axes d’un processus

7

Exemple de processus

8

Processus : définition

Le processus est une déclaration plus ou moins organisée, plus ou moins formelle, dont un groupe ou un individu va s’y prendre pour livrer la solution à une demande ou à un problème.

C’est en général une approche que l’on peut réutiliser lorsque le problème ou la demande est répétitif.

9

Mise en place d’un processus (SEI)

10

Gestion de projet classique (1)• Phase Préliminaire : la réflexion sur l’intérêt du projet en lui-même, en terme d’opportunité stratégique, suivant la manière

dont se présente l’avenir …• Jalon de Lancement du projet : on décide (au niveau “politique”) qu’il y a lieu de lancer un projet spécifique, et on y

consacre un chef de projet, une équipe, des moyens, un responsable et un budget.• Phase d’Expression du besoin : la définition de ce que l’on attend (les fonctions attendues), le périmètre, ce sur quoi on va

évaluer le projet, ce qui est important et ce qui l’est moins.• Jalon de Validation du besoin : le client valide l’expression de ses besoins (ainsi les évolutions dans l’approche des besoins

pourront être tracées et justifieront d’éventuels ajustements du plan projet), ce sont les bases sur lesquelles le projet va être bâti.

• Phase de Faisabilité : l’étude de ce qui est techniquement et économiquement faisable. Consultation des maîtres d’œuvres possibles, comparaison des propositions techniques et financières des réalisateurs possibles.

• Jalon du Choix de la solution : signature du contrat qui précise ce qui sera fait et la manière de le faire.• Phase de Développement : le maître d’œuvre coordonne les travaux sur le “produit papier”, pour préciser ce qui doit être

fait jusqu’au dernier boulon.• Jalon de Lancement du chantier (éventuel) : quand le “produit papier” est suffisamment défini, on peut faire le point avant

de lancer les travaux de réalisation.• Phase de Réalisation : le chantier est lancé, les travaux avancent pour transférer le “produit papier” dans le réel.• Phase de Vérification (qui peut commencer très tôt, sur le “produit papier”) : sur le produit réel ou sur le produit papier, on

vérifie (ou on calcule) que les caractéristiques attendues sont bien au rendez-vous (avec les écarts éventuels, qu’il faut alors gérer).

• Jalon de Qualification : après vérification, la définition de référence du produit est la bonne et ne sera plus modifiée (du moins, pas aussi facilement).

• Jalon de Livraison (et recette) encore appelée Acceptation : on remet le produit entre les mains du client, qui en devient propriétaire (et peut émettre des réserves sur les écarts constatés). C’est la fin du projet proprement dit.

• Phase d’Exploitation, qui commence le plus souvent par la levée des réserves, et voit la fin de la relation contractuelle.

11

Gestion de projet classique (2)

12

Le cycle en V (Cascade)

Winston Royce (1970) Walker Royce (1990)13

Les normes de gestion de projet

L'ISO 10006:2003 donne des conseils sur l'application du management de la qualité aux projets.

Elle est applicable à des projets de complexité variable, qu'ils soient petits ou grands, de courte ou longue durée, qui se situent dans des environnements différents, quel que soit le type de produit ou de processus de projet. Il peut être nécessaire d'adapter ces conseils à un projet précis.

L'ISO 10006:2003 ne constitue pas un guide pour le «management de projet» en lui-même, mais se contente de donner des conseils sur la qualité dans le cadre des processus de management de projet alors que l'ISO 9004 donne des conseils sur la qualité dans le cadre des processus relatifs au produit du projet et sur l'«approche processus».

Il convient de noter que la présente Norme internationale est un recueil de conseils et qu'elle n'est pas destinée à être utilisée pour des besoins de certification/enregistrement.

14

• Gérer les risques

• Gérer le projet– Estimer les charges– Planifier– Suivre l’avancement

• Gérer les modifications

• Gérer la communication

Des activités de gestion pour…piloter !

Les activités de management de projet

15

• Définir le rythme• Lancer la production• Tout au long du projet :

– Déclenchement des autres activités du projet• Suivre l’avancement selon le cadencement défini• Réaliser le suivi financier selon le cadencement défini • Préparer la tenue de chaque réunion• Tenir la réunion• Mettre en œuvre les décisions de pilotage • Rapporter aux instances de contrôle

Les activités

16

• Objectifs– De réduire la criticité des risques potentiels– Réduire l’impact des risques avérés

• Risques couverts– Mauvaises surprises quant à l’atteinte des

objectifs projet• Points essentiels

– Identifier les facteurs d’insuccès– Préparer et faire aboutir les actions préventives

et palliatives

Gérer les risques

17

• Principe :– Une attitude permanente de mesure et de pilotage

• L’aboutissement– Budgétiser chaque type d’activité de chaque phase– Budgétiser

• Les coûts directs• Pour tous les produits de la phase en cours

• La règle d’or

• « ON PRODUIT DES JOURS * HOMMES BUDGETES »• « ON DEPENSE DES JOURS * HOMMES CONSTATES »

Estimer

18

Estimer pour Planifier

La méthode des trois wagons (BCG)Hiérarchisation des fonctionsCoCoMoPERT…….

19

No. 20

• Comparer 2 à 2 chaque fonction

• A chaque comparaison est associé un poids variant entre 1 et 3 (1 signifiant peu de différence)

• Exemples :– F2 est plus importante que F1 avec un poids relatif de 1– F4 est plus importante que F1 avec un poids relatif de 2

• Poids de la fonction 5 : – Somme de toutes les cases orangées (1+1+1+1)

• Poids de toutes les fonctions :– Somme de tous les poids de fonction

• Poids relatif de la fonction 5 : – 4 / 27 = 14,80 %

• Hiérarchie des fonctions

F2 F3 F4 F5 F6F1 F2 1 F1 3 F4 2 F5 1 F1 3 6

F2 F2 3 F4 2 F2 2 F6 1 6F3 F4 1 F5 1 F3 2 2

F4 F5 1 F4 3 8F5 F5 1 4

F6 1

27

29,66%

22,22%

22,22%

14,80%

7,40%

3,70%

F4

F1

F2

F5

F3

F6

Hiérarchiser les fonctions

29,66%

22,22%

22,22%

14,80%

7,40%

3,70%

5%

20%

20%

15%

10%

30%

F4

F1

F2

F5

F3

F6

CoûtPoids

La fonction F4 représente 5 % du budget pour un poids de 29,66 %

Intégrer cette fonction dans le périmètre minimal

• La fonction F6 représente 30 % du budget du projet pour un poids de 3,7 %

– Améliorer le coût de la solution, ou– Supprimer la fonction du périmètre

Déterminer la valeur des fonctions

21

Planifier avec Fibonacci

22

Plus c’est compliqué et plus ça …..Et si c’est encore plus compliqué

alors ça ….. Encore plus

Cocomo : un outil

23

Cocomo : Les résultats

ACT

DET

24

Planifierméthode prédictive

Gant, Temps, €, ….

25

Suivre l’avancementet on réagit …

26

• Objectifs– Maîtriser le produit, ses coûts et ses délais– Offrir au client la flexibilité appropriée

• Risques couverts– Dérives– Insatisfaction client

• Points essentiels– Étudier l’impact de toute demande de modification sur

le produit, ses coûts et ses délais de développement– N’engager la modification qu’après décision du

responsable du projet

Gérer les modifications

27

No. 28

• Recevoir une demande de modification• Évaluer la demande• Décider• Réaliser la demande• Clore la demande• Modifier

– Les produits– Les pratiques– Les ressources

Gérer les modifications

PERTTâches Durée

RV Mairie 15 Choix de la date

Réserver une salle 60

DJ 15 Dépend de la salle

Traiteur 30 Dépend de la salle

Faire part 30

Envoyer FP 1

Réponses FP 30

Robe 60

On est le 16/12/2008 (total des taches = 8 mois) • Quelle sera la date du mariage, dans 8 mois => 16/08?• Quelles sont les tâches critiques ?• Trouver la date de début au plus tard de chacune des tâches

29

Correction

30

Trouver les dates de débutAu plus tard

Les Méthodes classiques : Conclusion(1)

31

« La logique est l’art de s’enfoncer dans l’erreur avec confiance ».Joseph Wood Krutch

Les Méthodes classiques : Conclusion(2)

On est également en droit de se poser les questions suivantes :

· L’approche prédictive du BTP est-elle adaptée au monde du logiciel ?

· Si certains aspects de ce processus échouent de façon récurrente, n’est-ce pas parce que ceux-ci ne sont pas abordés correctement ?

· Définir le rôle du chef de projet et le cantonner dans une attitude réactive est-elle la bonne approche?

. Qu’en est-il des membres de l’équipe de développement ?

32

UP-XP

Les concepts de base

33

Programmation fonctionnelle

34

Programmation objetProgramme

principal

o1

o2o3

o4 o5

new

fqq

35

Les concepts Objet

• Abstraction : Classe• Encapsulation• Héritage• Polymorphisme

36

Pourquoi l’objet ?

1711

81714

11

7

6

2

2

5

IncreasedProductivity

Cost savings

Improvedinterfaces

Software reuse

ImprovedapplicationmaintenanceEncapsulateexistingapplicationsDevelop strategicapplicationsquicklyDevelopapplications asrevenue sourceAccess new OSand tools

37

Fonctionnel versus Objet

C++ C++ C++ C C CV0 V1 V2 V0 V1 V2

Average Function LOC 6,66 6,2 6,11 29,62 32,5 37,11Min Function LOC 2 1 1 3 3 3Avg Cyclomatic Complex 1,66 1,59 1,59 5,88 6,25 6,56Avg Comparison Complex 0,25 0,24 0,3 1,38 1,62 2,22Avg Logic Flow Complex 1,91 1,83 1,89 7,25 7,88 8,78Avg Function Complexity 3,69 3,59 3,7 9 9,62 10,56eLoc/100 2,07 2,5 2,68 2,68 2,91 3,53eLOC 207 250 268 268 291 353

3838

Un modèle : Définition

Ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose (petit robert)

Top Model 39

UML : La genèse

Booch-93 Rumbaugh( OMT2)

Oct-950.8

Jacobson (use case - sdl)

Juillet-960.9

Janv-971.0

Nov-971.0

Sept-971.1 (OMG)

20001.4

DOC-PDF UML1.3 = 4,7MBDOC-PDF UML2.0 = 5.8 MB

20032.0

40

Taille des projets

1-2 ans & 6-12 personnes Couper les projets

41

UP-XP

UP - RUP

42

UP : La base

PU est à base de composantsPU utilise UMLPU est piloté par les cas d’utilisationPU est centré sur l’architecturePU est itératif et incrémental

43

UP & RUPUnify Process (Énorme process pour tous)

RUP Rational Unify Process Process customisé à partir du UPC'est un outil (site web, customisable)

Custom

AirFranceUP

44

RUP : La genèse

45

UP

46

RUP : Principes

47

Les artefacts

• Activité de gestion de projet– Comptes rendus, planning d’activité, ….

• Résultats– Modèles– Code source– Spécifications– …..

48

Les rôles

• Les analystes (exigences)• Les développeurs• Les testeurs• Les managers (gèrent le processus)• Le chef de projet• Les autres (Client, MOA, stakeholder, ….)

49

Les activités• Modélisation métier• Les Besoins• Analyse et conception• Implémentation• Tests• Déploiement• Gestion de configuration• Gestion du projet• Environnement

Etudié plus tard

50

BPM

51

Modélisation métierStéréotypes UP

Fournisseur

Les processLes objets de L’entreprise

Client

Les employés

business use case

5252

Modélisation métierArtefacts et rôles

53

• Rôle : Business Process Analyst• Artefacts :

• Business Glossary• Business Use case Model

Les besoins

• Les exigences• Les cas d’utilisation + • Le document supplémentaire (architecture)

54

Gestion des exigences

http://www.alm.tv/permalink/1734/sameliorer-sur-la-gestion-des-exigences-un-premier-pas-vers-lindustrialisation.aspx 55

Gestion des exigencesArtefacts et rôles

56

• Rôle : System Analyst (qui connait le métier)• Artefacts :

• Supplementary Specifications : Document recensant toutes les exigences qui ne peuvent pas être capturées par les UC. Exigences non fonctionnelles ou transversales (performance, sécurité, contraintes légales, standards d’entreprise, ….

• Use case Model : ce modèle central du RUP concerne les exigences fonctionnelles des utilisateurs

• Glossaire• Business case et vision : ROI du projet• Risk list• Proto d’IHM

Les grands types d’exigences

• exigences fonctionnelles• exigences opérationnelles• exigences de performance• exigences d’architecture• exigences d’interface• exigences de construction• exigences de données• exigences de qualité

57

Gestion des exigences : Processus

58

Gestion des exigences : Outils

59

Gestion des exigences : CaliberRM

60

Use Case : ExerciceUne société de vente par correspondance vous demande de développer sonsystème informatique. Ce système doit pouvoir prendre en compte descommandes passées par la poste et des commandes passées par internet. Ildoit suivre les expéditions qui ne sont effectuées que si le paiement est OK.Les paiements se font par carte bancaire dans le cas d'internet et par chèquedans le cas de la poste. Les paiements sont validés par un système bancaire appartenant à la société et existant. Il faut récupérer ce système. Lenouveau système est chargé aussi de la gestion de stocks, lorsqu'un articleatteint un seuil minimal, alors il faut passer une nouvelle commande aufournisseur adéquat. A la réception de la commande, la mise à jour de la base est faite par un employé. Dans le cas d'un paiement accepté et de stockdisponible, l'expédition est faite par un robot existant au quel il suffit depasser les coordonnées du client, et la liste des produits achetés. En cas d'indisponibilité, une lettre doit être envoyé au client.

6161

Analyse (1)Manger

Descriptions

A

A1()A2()A3()

B

B1()B2()

C

C1()C2()C3()C4()

Distribuer le comportement des fonctionnalitésaux méthodes des objets

6262

Analyse (2)Boundary-Controleur-Entité (1)

Environnement

Métier

Fonctionnel

B

C

E

Control

Fonctionnel

Entite

Métier

Boundary

Environnement

6363

Analyse (2) Boundary-Contrôleur-Entité (2)

Aiguilleur

Pilote

Decoller

Atterrir

Aeroport

Voler

6464

Analyse (2) Boundary-Contrôleur-Entité (3)

Aiguilleur

Pilote

Decoller

Atterrir

Aeroport

VolerCtrlVoler

CtrlDecoller

CtrlAtterrir

DecollerForm

VolerForm

AtterrirForm

AeroportForm

AiguilleurForm

TrainAtterrissage

Reacteur

Frein

6565

Conception (1)

pour chaque ligneloop

: Secretaire : EnregistrerCommandeForm

<<boundary>>

: EnregistrerCommandeCtrl<<control>>

: Client

: Commande

: Stock

: LigneCommande

EnregistrerCommande(nomClient): voidEnregistrerCommande(nomClient): void

Rechercher(nom): void

Dupondnew()

setNumeroDateEtat(): void

setClient(c): void

EnregistrerLigne(vin, cond, qte): voidEnregistrerLigne(vin, cond, qte): void

EnregistrerLigne(vin, cond, qte): voidVerifierStock(vin, cond, qte): int

OKNew()

prix += GetPrixLigne()

66

Conception (2)

Conditionnement

-type: TypeConditionnement-volumeEnLitres: int-coefficient: int

Stock

-nbLitres: float+Soustraire(qte: float)+VerifierStock(vin, cond, qte): int

Vin

+reference: int+millesime: Date.Year+qtePressee: float+GetPrixLitre(Periode): float

0..*

0..*

LigneCommande

-qte: int-qteLivree: int-qteDiso: int+GetPrixLigne(): float

1

0..*qte= nb de conditionnements

TypeConditionnement<<enumeration>>

+cuve+bouteille+cubit+tonneau

Commande

-numero: int-saisie: Date-etat: EtatCommande-prix+AjouterLigne(Vin, Conditinnement, qte)+setNumeroDateEtat()+setClient(c: Client)+EnregistrerLigne(vin, cond, qte)

EtatCommande<<enumeration>>

+enregistree+attente+annulee+confirmee+realisable+expediee+facturee

1..*

Client

-nom: String-adresse: String+Rechercher(nom): Client

+leClient

0..*1

BonLivraison

-date: Date

0..1

1

Facture

-numero: int-edition: Date-reglement: Date+CalculerMontant()

0..1

1

GetPrix = Conditionnement.coefficient*qteLivree*(Vin.GetPrixLitre(this.date)

67

Architecture• Exemple : persistance JAVA

– Mapping Objet-Relationnel– JDBC– Serialization

• Découpe des modules (Composants)• Travail de l’architecte

– Input : Document spécifications supplémentaires– Trouver une solution technique– Maquette, validation de la solution– Formation, explication, exemples– Validation des résultats

68

Example: Incorporating JDBC Steps• Provide access to the class libraries needed to implement

JDBC – Provide java.sql package

• Create the necessary DBPersistentClasses– Guideline: One DBPersistentClass per persistent class

• Incorporate DBPersistentClasses into the design– Allocate to package/layer– Add relationships from persistence clients

• Create/Update interaction diagrams that describe:– Database initialization– Persistent class access: Create, Read, Update, Delete

JDBC: Static View

ResultSet

getString() : string

(from java.sql)

Connection

createStatement() : Statement

(from java.sql)

Statement

executeQuery(sql : String) : ResultSetexecuteUpdate(sql : String) : int

(from java.sql)

DriverManager

getConnection(url, user, pass) : Connection

(from java.sql)

DBPersistentClass

create() : PersistentClassread(searchCriteria : string) : PersistentClassListupdate(c : PersistentClass)delete(c : PersistentClass)

1

1

PersistenceClient(from SamplePersistence Client)

PersistentClass

getData()setData()command()new()

(from SamplePersistentClass)

PersistentClassList

new()add(c: PersistentClass)

(from SamplePersistentClass)

0..*1

0..*1

Roles to be filled by the designer applying the

mechanism

JDBC : Read : Connection : Statement : ResultSet :

PersistenceClient : DBPersistentClass

:

PersistentClass

: PersistentClassList

1. read(string)

1.1. createStatement( )

1.2. executeQuery(string)

1.4. new()

1.5. getString( )

1.6. setData( )

called for each attribute in the class

returns a Statement

1.3. new( )Create a list to hold all retrieved data

1.7. add(PersistentClass)

Add the retrieved course offering to the list to be returned

Repeat these operations for each element returned from the executeQuery() command.

The PersistentClassList is loaded with the data retrieved from the database.

The SQL statement built by the DBPersistentClass using the given criteria is passed to executeQuery()The criteria used to

access data for the persistent class

JDBC Read : Example de codepublic void Read (String critere){

//SELECT FROM `A` WHERE nom = 'Sylvie';Statement statement;String SQL = "SELECT * FROM `A`" + critere + ";";System.out.println(SQL);try {

statement = conn.createStatement();ResultSet resultset = statement.executeQuery(SQL);while (resultset.next()){

String id, nom, sexeString;int age;boolean sexe = true;id= resultset.getString(1);nom = resultset.getString(2);age = resultset.getInt(3);sexeString = resultset.getString(4);if (sexeString == "F") sexe = false;A a =new A (nom,age, sexe);a.Afficher(); // Il ne reste plus qu'a mettre ces objets ds la liste

// et rendre le liste}

} catch (SQLException ex) {// handle any errorsSystem.out.println("SQLException: " + ex.getMessage());System.out.println("SQLState: " + ex.getSQLState());System.out.println("VendorError: " + ex.getErrorCode());

}}

BD

Architecture : Composants

74

SiteWeb

VPC

Classesresidents

Robot

SBVerifiable

Expediable

GererCommande

IHMSecretaire

IHMresidents

Menagere

Secretaire

Administrateur

GererStock et le reste

IHM-DOS

in out-refout

Architecture : Déploiement

75

IHM

IHMSecretairecomponents

ServeurA

VPCIHM-DOS

components

WWW

SiteWebcomponents

lan

tcpip

ServeurB

Robot SB

lan

Analyse et conceptionArtefacts et rôles

76

• Rôles : • Software Architect : Architecte• Designer : Programmeur, Analyste• Data Designer

• Artefacts :• Software Architecture• Design Model • Deployment model• Data model

Implémentation

77

ImplémentationArtefacts et rôles

78

• Rôles : • Software Architect : Architecte• Implementer : Programmeur, Analyste• Integrateur

• Artefacts :• Implementation model• Build (les sources et autres ressources)

Autres activités (1)Artefacts et rôles

79

• Déploiement : • Rôle : Deployment manager• Artefacts : Deployment plan, Product

• Tests• Rôle : Test Designer• Artefact : Test plan , Test suite (source des tests)

• Environnement :• Role : process engineer• Artefact : Development case (process customisé),

guidelines, Development infrastructure (machines et outils)

Autres activités (2)Artefacts et rôles

80

• Gestion de configuration : • Rôle : Change control manager• Artefacts : Project repository (bd de tous les artefacts du

projet), Change Requests (gestion des DM et des RT)• Gestion de projet

• Rôle : Project manager• Artefact :

• Software development plan (planning global mis à jour après chaque itération), il contient les tâches à réaliser et les ressources associées.

• Iteration plan

Les meilleurs pratiques

• Développer itérativement;• Gérer les exigences;• Utiliser une architecture à base de

composants;• Modéliser visuellement;• Vérifier continuellement la qualité;• Gérer les changements.

81

82

83

Phase d’inception

• Objectifs– Comprendre le périmètre du projet– Étudier la rentabilité du projet– Adhésion des intervenants– Décision de continuer

• Jalon LCO (LifeCycle Objective)– Objectifs définis

84

La phase d’élaboration

• Objectifs– Réduire les risques techniques majeurs– Créer une architecture de référence– Comprendre les éléments nécessaires à la

construction du système• Jalon LCA (LifeCycle Architecture)

– Architecture définie

85

La phase de construction

• Objectifs– Construire la 1ère version opérationnelle du

produit, puis les suivantes ….– Chaque itération révise et étend (en les

stabilisant) les produits de la phase d’élaboration• Jalon IOC (Initial Operational Capability)

– Première version exploitable– De nouveaux produits sont créés

86

La phase de transition

• Objectifs– Construire la version finale du produit et la livrer

au client– Former les utilisateurs– Exécuter des tests– Préparer le lancement du produit

• Jalon PR (Product Release)– Livraison finale

87

88

89

Organisation des modèles (UP)

90

Les sources

Les UC realization (Documentation)

Les composants (physiques et logiques)Les machines

Définition des besoins

PC

Composant1components

Composant1

C1C2

residents

C1 C2

VOPC

uc1

Phases et Activités

91

92

93

94

95

96

97

98

99

100

RUP : Ses forces

• Cadre générique• Référentiel de bonnes pratiques;• Gestion des risques dans les projets;• Cadre propice à la réutilisation;• Approche basée sur l’architecture;• Traçabilité à partir des Uses Cases jusqu’au

déploiement.

101

RUP : Ses faiblesses

• Coût de personnalisation souvent élevé;– Autres logiciels propriétaires (Rational)

indispensables;• Très axé processus :

– peu de place pour le code et la technologie ;• Vision non évidente ni immédiate:

DEVELAY IsabelleEDORH-A. SemehoGUIBOUT Nicolas

102

RUP : Conclusion

• RUP considéré comme:– un framework de processus génériques;– un métaprocessus;

• Démarche itérative– Réduction des risques;

• Facile à expliquer et à valider (les livrables);• Finalement pas très populaire…

DEVELAY IsabelleEDORH-A. SemehoGUIBOUT Nicolas

103

UP-XP

Vers les méthodes agilesXP

Scrum

104

Qu’est ce qu’une méthode agile

Deux caractéristiques fondamentales– Adaptatives plutôt que prédictive

• Favorables au changement• Planification plus souple

– Orientée vers les personnes plutôt que vers les processus

• Travailler avec les spécifités de chacun• responsabilité

105

Le manifeste agile

106

Les méthodes agiles

107

Les 4 valeurs de XP (1)

• Communication• FeedBack• Simplicité• Courage

108

Les 4 valeurs de XP (2)Communication XP intègre réellement le client au projet pour qu'il définisse mieux ses besoins, arbitre les priorités et apporte ses

connaissances métier à l'équipe. XP fait travailler tous les développeurs ensemble et les fait participer à toutes les activités du développement, créant

ainsi une réelle dynamique d'équipe. XP rend accessible à tous les intervenants l'ensemble des indicateurs d'avancement du projet.• Feedback XP fournit des livraisons régulières au client pour lui permettre d'affiner et de compléter la définition de ses besoins

à partir de données concrètes. XP met en place des batteries de tests d'acceptation qui mesurent concrètement l'avancement des développements. XP met en place des batteries de tests unitaires qui indiquent rapidement si le code fonctionne et qui détectent

instantanément toute régression.• Simplicité XP s'assure que seules les fonctionnalités demandées par le client sont implémentées. XP maintient un design et un code toujours aussi simples que possible pour rester ouvert au changement et

conserver une grande vitesse de développement tout au long du projet.• Courage XP donne au jour le jour une transparence maximale sur l'état d'avancement réel du projet. XP s'attaque aux problèmes dès qu'ils se présentent, en autorisant des retours en arrière s'ils sont nécessaires.

109

B.Vinot

Les principes de base

• Seul le code source fait foi, il possède une odeur• L’important c’est le programmeur• Faire le plus simple possible• Restructurer dès que nécessaire• Pratiquer la programmation par paire• Les spécifications sont des « histoires d’utilisateurs »• La planification est un jeu• Livrer fréquemment• Tester encore, toujours et tout le temps• Être courageux

Le chef de projet Agile

111la qualité essentielle du leader sera le charisme plus que l’autorité.

Le cycle de l’agilité

112

Les 3 rythmes :• Le rythme du projet• Le rythme de l’itération, qui définit les étapes de réalisation majeures du projet.• Le rythme journalier, qui montre la progression au sein de l’itération.

Ces rythmes suivent la même progression : • préparation,

• Une idée claire (sinon précise) de l’objectif à atteindre.• Une façon de vérifier que la réalisation atteint l’objectif.

• réalisation (laisser faire l’équipe)• retour d’expérience ,• adaptation.

User story

113

• Taille : carte postale• Ecrite par le client• N’est qu’un résumé• Le reste est verbal• Affectation d’une priorité• Affectation sur une itération• Ecriture des tests finaux

le client L’équipe de dvp

• Affectation d’un coût• Découpage en tâches• Affectation sur une itération (voir partielle)• Prise de responsabilité d’un développeur pour

une tâche• Discussion avec le client• Réalisation en binôme• Ecritures des TU• Passage des tests finaux

Exemple Scrum : Une release

114

UCUser story

Planninggame

DVPTests

Le client est dans la salle

Les tâches à faire (le radiateur)

115

Stand up meeting

116

• Tous les jours 15 mn• Toute l’équipe• Chacun doit dire (15/6 = 2mn30s)

• Les problèmes qu’il a eu la veille si ils ne sont pas résolus• Ce qu’il pense pouvoir faire aujourd’hui

• On est pas là pour résoudre les pb, mais • pour les faire connaitre, • prendre un RV ds la journée avec le sauveur• si il n’y a pas de sauveur, il faudra réestimer la tâche.

• Mise à jour du planning journalier (Sprint) et de la liste des PB• Si plusieurs équipes scrum de scrum (entre scrum masters)

Stand up meeting : Objectifs

• Evaluer l'avancement du travail• Identifier les obstacles(problèmes) nuisant à la

progression• Garder l'équipe concentrée sur l'objectif du sprint• Améliorer l'esprit d'équipe• Permettre une communication objective sur

l'avancement

117

Stand up meeting : Les erreurs

• La réunion n'a pas lieu tous les jours• la réunion commence en retard • Tout le monde ne s'exprime pas • Des personnes bavardent en aparté • Une personne interrompt les autres • On s'adresse uniquement au ScrumMaster • On parle de choses sans rapport avec les

tâches du sprint

118

Exemple Scrum : Une release

119

Planification classiquePlanifier par tâches, c’est adopter une approche tayloriste du développement

logiciel. La première conséquence de cette approche est la déresponsabilisation : les membres de l’équipe acquièrent le sentiment de n’être qu’un engrenage de la machine. Dans un tel état d’esprit, il leur importe plus d’échapper aux reproches en accomplissant les tâches qui leur sont désignées que de contribuer à la réussite globale du projet. On ne peut mobiliser les énergies sans engagement, on ne peut obtenir cet engagement sans participation.

120

Planifier (Planning game)Planning de version :• Une version = 2 à 6 mois• Chaque user story a un poids et une priorité• Le client en choisit et définit l’ordre de réalisation• Les programmeurs répartissent ces US dans des itérationsPlanning des itérations : planning game)• Une itération = 1-3 semaines (durée fixe)• Prendre les US par ordre de priorité• Décomposer chaque US en tâches• Estimer chaque tâche• Chacun prend la responsabilité des tâches qu’il pense pouvoir

mener pendant l’itération (en binôme) et en réajuste le cout sur lequel il s’engage

121

Product backlog (au début)

122

Product backlog (après estimation)

123

Suivi de projet (Release)

124

Suivi de projet (Itération)

125

Vélocité (1)La vélocité est la mesure du nombre de points finis pendant une itération. Elle donne une indication de la

capacité de l'équipe. Quand elle est utilisée à bon escient, la mesure de la vélocité permet à l'équipe :1. de s'engager sur le court terme (contenu d'une itération)2. de prévoir sur le moyen terme (planning de release)3. Pour le point 1, l'idée est de se baser sur la mesure concrète de la vélocité pour en déduire la capacité

pour la prochaine itération. Ce n'est qu'une indication, car lors de la réunion de planification de l'itération, le périmètre est plus défini par l'engagement de l'équipe sur ce qu'elle estime pouvoir faire que par un total de points égal à la vélocité passée[1]

4. Pour le point 2, le calcul de la vélocité concourt à la production du beurdone de release. Cependant le reste à faire utilisé dans le burn down dépend aussi des variations de périmètre. Ce n'est pas parce que l'équipe a une vélocité qui augmente que le reste à faire diminue, en particulier si de nombreux bugs viennent s'ajouter dans le backlog.Encore quelques remarques pour différencier vélocité de productivité :

5. La vélocité est basée sur les estimations en points. Et malheureusement, si la vélocité augmente, il n'y a pas moyen de savoir si c'est dû à une amélioration de la productivité ou à des mauvaises estimations. Il est aussi possible augmenter artificiellement la vélocité

6. La vélocité est une mesure de l'équipe, pas de personnes individuelle

V = nb de points / (nb de jours * nb de personne)

126

Vélocité (2)

127

Développement (1)

• Faire le plus simple possible• 1 jour de modélisation sur 10• Binômes• Personne n’est propriétaire du code Equipe• CR journalier

128

Binômes (1)• Il y en a un qui fait le code pendant que l ’autre fait les

tests • Il y en a un qui code pendant que l’autre le surveille • Il y en a un qui code pendant que l’autre se repose • Il y en a un qui tient la souris, l ’autre a le clavier... • Cela coûte forcément deux fois plus cher • J ’ai mes habitudes de codage...• J ’aime travailler tout seul • Binômer, c’est multiplier les couts

par 2

129

Binômes (2)• Deux personnes travaillant ensemble pour concevoir,

tester, coder...• Une seule machine

– un conducteur: manipule la machine, réalise le travail– un observateur: propose, conseille, vérifie, et réfléchi à la

stratégie globale• Changements de conducteur fréquents• Changements de binôme fréquents• Travail dense, exigeant, productif et efficace• L’un regarde le clavier, l’autre l’écran, et on discute

130

Cycle de vie du binôme

131

« 1 + 1 = 1[...]1 + 1 = 11 »Jean-Claude Van Damme.

Qualités d’ ½ binôme

Ouverture d'esprit et remise en questionCourage (de se mettre à nu)Communication active (pas de rétention d'information)Respect de l'autre et de son travailCapacité à tourner (tâches, fonctionnalités, personnes...)A se rendre non indispensableTravailler à deuxA partager la gloire... Et les erreursil est « plus facile de former un débutant (à l'agilité) que de

déformer un gourou ».

132

La modélisation agile

• Il faut modéliser (1 jour sur 10)• Les modèles sont faux• Modéliser à plusieurs• Moins de diagrammes de classe et plus de

diagrammes d’interaction (et en //)• Ne pas passer trop de temps avec les outils,

faire de reverse• Modéliser pour soi même

133

Les bureaux agiles

134

Développement (2)• Faire le plus simplement possible

– Faire simple mais pas simpliste– Commencer simple– Ne pas faire de sur spécification– Pas de savants– Problème des design patterns– Homogénéité de l’équipe avant tout– Les cimetières sont remplis de gens indispensables– Faire de la réorganisation de code

• Revue (binômes)• Une seule fois • Refactoring

135

Faire le plus simple possible (1)

• Faire le plus simple possible• Ne pas faire de sur spécification, mais penser à

demain• Réorganiser le code• Compliquer le code (ex DP)

– Former, convaincre sinon ne pas faire– Nivèlement par le bas, mais tout le monde comprend

• Ne pas prendre d’expert• Se méfier des architectes

136

Faire le plus simple possible (2)if (n==3) System.out.print ("III");if (n==2) System.out.print ("II"); if (n==1) System.out.print ("I");----------------------------------------------while (n > 0) { System.out.print("I"); n = n - 1; }-----------------------------------------------if (n == 9) { System.out.print("IX"); n = n - 9; } if (n >= 5) { System.out.print("V"); n = n - 5; } if (n == 4) { System.out.print("IV"); n = n - 4; } while (n > 0) { System.out.print("I"); n = n - 1; }

137

Faire le plus simple possible (3)while (n >= 100)

{ System.out.print("C " );n = n - 100;}if (n >= 90) { System.out.print("XC");n = n - 90; }if (n >= 50) { System.out.print("D "); n = n - 50; }if (n == 40) { System.out.print("XD"); n = n - 40; }while (n >= 10) { System.out.print("X "); n = n - 10; }if (n == 9) { System.out.print("IX "); n = n - 9; }if (n >= 5) { System.out.print("V "); n = n - 5; } if (n == 4) { System.out.print("IV "); n = n - 4; } while (n >= 1) { System.out.print ("I "); n = n - 1; }

138

Faire le plus simple possible (4)if (n == 9) { System.out.print("IX "); n = n - 9; }if (n >= 5) { System.out.print("V "); n = n - 5; } if (n == 4) { System.out.print("IV "); n = n - 4; } while (n >= 1 0) { System.out.print ("I "); n = n - 1; }

n = Tester(n,1,0);---------------------------------------------------------------------Int Teter(int n , int p , int ind){if (n >= 9 * p) { System.out.print(tab[ind]+tab[ind + 2]); n = n - (9 * p); } if (n >= 5 * p) { System.out.print(tab[ind + 1]); n = n - (5 * p); } if (n == 4 * p) { System.out.print(tab[ind]+ tab[ind+1]); n = n - (4 * p); } while (n >= p) {System.out.print(tab[ind]); n = n - p;} return n;}// 0 1 2 3 4 5 6 private static String tab[]= { "I","V", "X","L","C","D","M"};

139

Faire le plus simple possible (5)package nommbrearabe;public class Main {// 0 1 2 3 4 5 6 private static String tab[]= { "I","V", "X","L","C","D","M"}; public static void main(String[] args) { for (int i = 1; i<250 ;i++)Calculer(i); }

private static void Calculer(int n) { System.out.print (n + "="); while (n>=1000)System.out.print("M"); n = Tester(n,100,4); n = Tester(n , 10, 2); n = Tester(n,1,0); System.out.println(""); }private static int Tester (int n , int p,int ind){ if (n >= 9 * p) { System.out.print(tab[ind]+tab[ind + 2]); n = n - (9 * p); } if (n >= 5 * p) { System.out.print(tab[ind + 1]); n = n - (5 * p); } if (n == 4 * p) { System.out.print(tab[ind]+ tab[ind+1]); n = n - (4 * p); } while (n >= p) {System.out.print(tab[ind]); n = n - p;} return n;}}

140

UP-XP

TestDTD

141

Les tests (1)

142

Les tests (2)• Tests unitaires (X-UNIT)

– Déclarer les classes que l‘on veut tester (via les digrammes UML si possible)

– Ecrire le programme de test– Lancer le programme de test Echec– Ecrire le programme– Lancer le test jusqu’au Succès– Archiver le test ( TestSuite )– Ecrits par le programmeur

• Tests de recette– Des outils– IHM Textuelles (automatique)– Outils de test– Ecrits par le client

143RMQ : Si possible, écrire et tester le programme avant de l’écrire (TTD)

Junit : Echec avant écriture du programme

144

Ecriture du programme

public class Personne {private String nom;private int age;private String adresse ;public Personne(String nom, String adresse) {

super();this.nom = nom;this.adresse = adresse;age = 0;

}public int getAge() {return age;}public void setAge(int age) {this.age = age;}public String getNom() {return nom;}public String getAdresse() {return adresse;}public void Afficher(){

System.out.println("Personne :"+nom+","+age+","+adresse);}

public void Travailler(){ age--;}}

145

Junit : Syntaxe

146

Junit : Ecriture du test et run

147

Junit : testSuite

148

IHM DOS

149

CTRL

BlalalGfgdgghdghds

E1<<entity>>

E2<<entity>>

IHM

Test IHM Web : Selenium

150

Outil de test automatiqueTester les IHM

http://www.alm.tv/Accueil/tabid/381/Default.aspx151

UP-XP

Les outils indispensables

152

Les outils

• Le client• Des outils de DVP

– avec du refactoring et du TU• UML (avec ou sans outil)• Gestion de la configuration• Des outils de test fonctionnel• Un outil de gestion de projet

153

Refactoring

100 fois sur le métier remettez votre ouvrage

154

Solution trop lourde

Architecture complexe

Réparer avant de continuerFaire le ménage tous les jours, puis faire un nettoyage de printemps.

Refactoring (NetBeans)

155

Refactoring (Eclipse)

156

Gestion de Configuration

DVP

Test

Intégration

Check inCheck out

157

Mode :• lock• merge

Gestion conf : arborescence

158

S1 S2

S1.VF S1.VO

S1.VF.1

S1.VF.2

S1.VF.3

S2.1

S1

S2

R1.1

R1.2

R2

R1

Gestion conf : Méthode de travail

159

: binomeA : binomeB

: System gest Conf

1 : CheckOut de la BD V1.0()

2 : Travail en local() 3 [mode != lock] : CheckOut de la BD V1.0()

4 : Travail en local()5 : Consolidation()

6 : CheckIn de la BD V1.1()

7 : Consolidation()

8 : Integration du travail de A()

9 : CheckIn V1.2()V1.2 = V1.0 + WA + WBV1.2 = V1.1 + WB

Gestion des changements (1)

160

Utilisateur

Admin

Developpeur

Testeur

Login

Configurer

Liste des utilisateurs

Gerer un PB

Corriger un PB S'approprier un PB

Enregistrer un PB

Rechercher un PB

Gestion des changements (2)

161

MySQL

Serveur Web

Client

Developpeur

Admin

Bug

Produit

DM

Gestion des changementsBugzilla : Etats des DM

162

Gestion de projet

163http://www.extremeplanner.com/tour/

UP-XP

Conclusions

164

Retours d’expérience

165

Chrysler (la paye)Métro de NewcastlePostes de supervision TGV Madrid-Barcelone

Bibliographie (livres)

166

UMLLaurent Audibert

(www)

Bibliographie (www)

167

IBM-Rational

UP-XP

Etude de casVPC

168

Use Case : Correction

169

UC : Secrétaire

170

UC: Détails

171

UC:Suppléments

172

IHM : Secrétaire

173

Idem (Visio)

174

UCWeb

175

176

177

178

179

UC : Requirements

180

IHM WEB

181

Acceuil

LoginEnregistrer nouveau client

nouveau clientClient connu

Regarder les produits

Pull

String

ChaussettesCommander

ret

ret

ret

encore

Payer

Suivre commandes