Chapitre 5

(R)UP, XP et Scrum

Ce chapitre détaille trois « méthodes » de développement objet qui jouent un rôle majeur
aujourd’hui : (Rational) Unified Process – (R)UP –, eXtreme Programming – XP – et Scrum.
Le mot méthode est placé entre guillemets car ces approches n’ont pas tous les attributs d’une
méthode complète. XP est plutôt un « cadre technique » et Scrum un « cadre organisationnel »
pour le développement agile des applications.

5.1 (RATIONAL) UNIFIED PROCESS – (R)UP

James Rumbaugh, Ivar Jacobson et Grady Booch, ont proposé un cadre général de processus
itératif pour le développement orienté objet, Unified Process (UP) [JBR99], étroitement
associé au langage UML dont ils sont également les principaux auteurs. La version de
la société Rational, Rational Unified Process (RUP) en est la déclinaison la plus connue
[Kru04]. Il en existe plusieurs autres, comme eXtreme UP (XUP), qui intègre XP et UP,
Agile UP qui simplifie UP dans une optique d’agilité ou 2TUP (Two Tracks UP) et son
modèle en Y déjà discuté au paragraphe 4.1.3., qui peuvent satisfaire différents types de
projet.
(R)UP met en avant sept « bonnes pratiques » qui sont explicitées dans les paragraphes
suivants :
(1) le développement itératif et incrémental,
(2) le développement guidé par les cas d’utilisation et centré sur l’architecture,
(3) le pilotage par les risques,
(4) la gestion des exigences,
74 Partie 1. Le développement logiciel

(5) la maîtrise des modifications,

(6) l’évaluation continue de la qualité,
(7) la modélisation visuelle avec UML.

5.1.1. Le développement itératif et incrémental

(R)UP définit un processus de développement relativement « générique », qui peut être adapté
à des contextes particuliers. Dans l’approche (R)UP, le développement d’un logiciel passe par
quatre phases, chacune pouvant donner lieu à une série d’itérations : lancement (inception),
élaboration, construction et transition. Chaque phase se termine par un jalon d’évaluation et
de prise de décision quant au passage à la phase suivante.
Toute phase est concernée en proportions diverses par différentes « disciplines » du
développement (activités) : modélisation métier, recueil et expression des besoins, analyse
et conception de l’application, implantation, tests, déploiement et les activités transversales
de gestion de configuration et du changement, gestion de projet (personnes, budgets,
contrats, planning), gestion de l’environnement de développement (outils, administration
système/réseau/bases de données). Par exemple, lors de la phase de lancement, ce sont les
disciplines de modélisation métier et de recueil et expression des besoins qui dominent en
proportion. Lors de la phase de construction, ce sont les disciplines d’implantation, de test et
de déploiement qui dominent (cf. figure 5.1).

F IGURE 5.1 Phases, itérations et disciplines

Les phases sont composées d’itérations. Une itération est une séquence d’activités qui
répond à un plan et possède des critères d’évaluation. Une itération se termine par un jalon
d’évaluation et de prise de décision. Toute itération peut être considérée comme un mini
projet (qui parcourt une ou plusieurs fois le cycle recueil et expression des besoins, analyse,
conception, implantation, tests) et qui produit un livrable (cf. figure 5.2).
Le développement se concrétise donc par une série de livrables, par exemple des maquettes
ou des prototypes dans les premières itérations et des versions exécutables du logiciel final
(releases) ultérieurement, comme dans l’exemple de la figure 5.3.
5 • (R)UP, XP et Scrum 75

F IGURE 5.2 Structure d’une itération

F IGURE 5.3 Un exemple de suite de livrables

➤ Le lancement
Objectifs : C’est une phase très courte, avec souvent une seule itération. Elle explicite la
« vision » associée au projet en termes de faisabilité, de risques et de périmètre du projet.
Livrables : (tout ou partie de la liste suivante)
– Un document de vision présentant les besoins de base, les contraintes et fonctionnalités
principales.
– Une description courte des principaux cas d’utilisation et une analyse plus poussée des
10 % de cas les plus critiques.
– Un glossaire de projet.
– Un document de justification économique incluant le contexte général de réalisation, les
facteurs de succès et la prévision financière.
– Une évaluation des risques.
– Une première planification du projet (phases et itérations).
– Une maquette.
76 Partie 1. Le développement logiciel

➤ L’élaboration
Objectifs : Cette phase comporte quelques itérations courtes et de durée fixe, pilotées par
les risques et centrée sur l’architecture. Elle comprend l’identification et la stabilisation de
la plupart des besoins, la spécification de la plupart des cas d’utilisation, la conception de
l’architecture de référence, du squelette du système à réaliser, la programmation et le test
des éléments d’architecture les plus importants, la réalisation et le test des cas d’utilisation
critiques (< 10 % des besoins) et une estimation fiable du calendrier et des coûts de
construction de l’application.
Livrables :
– Au moins 80 % des cas d’utilisation sont élaborés à la fin des itérations.
– Les exigences et contraintes non fonctionnelles sont identifiées.
– L’architecture est définie.
– Une version du produit permettant de valider l’architecture du logiciel à travers les
fonctionnalités les plus importantes.
– Un planning de réalisation réaliste (phases, itérations, critères d’évaluation).

➤ La construction
Objectifs : C’est la phase la plus longue (plus de 50 % du cycle de développement). La
construction se fait par incréments, avec une architecture stable malgré des changements
mineurs. À chaque incrément, le produit doit contenir tout ce qui avait été planifié. Par contre,
il peut éventuellement rester quelques erreurs non encore traitées.
Livrables :
– Les versions exécutables du logiciel correspondant à l’enrichissement itération par
itération des fonctionnalités.
– Les manuels d’utilisation réalisés simultanément à la livraison incrémentale des
exécutables.
– Une description des versions produites.

➤ La transition
Objectifs : Le produit est livré (en version béta). Il y a correction du reliquat d’erreurs. Le
produit est essayé et amélioré, les utilisateurs sont formés, l’assistance en ligne est élaborée.
Livrables :
– La version finale du logiciel.
– Les manuels d’utilisation.
– L’assistance en ligne.

Une telle approche est très flexible. Lors des premières itérations la gestion des risques est
fondamentale. Il faut également construire et stabiliser le noyau architectural rapidement.
Le feedback régulier des utilisateurs doit permettre une adaptation permanente du système
aux besoins réels. Le feedback des développeurs et des testeurs doit permettre d’affiner la
5 • (R)UP, XP et Scrum 77

conception et les modèles et de mieux gérer la complexité. Des étapes courtes et pas trop
complexes permettent d’éviter la « paralysie par l’analyse ».

5.1.2. Le guidage par les cas et le centrage sur l’architecture

Les cas d’utilisation (use cases) décrivent les interactions entre les acteurs et le système.
Ils permettent de réfléchir en termes d’acteurs et de buts plutôt que directement en termes
de fonctionnalités. Il s’agit d’un bon véhicule, compréhensible par tous, pour recueillir et
communiquer les besoins métier. C’est également un bon outil pour guider et garantir la
cohérence de tout le processus de développement.

F IGURE 5.4 Guidage par les cas

Dans le cadre d’un développement itératif, chaque itération est centrée sur un sous-ensemble
de cas. Il faut traiter en premier les cas d’utilisation « pertinents », c’est-à-dire les plus risqués
(critiques), les plus importants pour le client ou les plus représentatifs du système.
L’architecture décrit les aspects les plus significatifs du système en termes de modèles,
selon les 4+1 vues définies par UML [Kru95] : modèle fonctionnel (cas d’utilisation),
modèles statiques (classes, objets, paquets), modèles dynamiques (processus, concurrence,
performance), modèle d’implantation (composants logiciels), modèle de déploiement
(composants logiciels et matériels). Elle est conçue et stabilisée lors des premières itérations
en parallèle avec l’approfondissement des cas d’utilisation.

5.1.3. Les autres bonnes pratiques

a) Le pilotage par les risques
Un risque est un événement prévisible redouté, car il peut produire des dommages au projet.
Ces risques peuvent être techniques, mais aussi liés au client, au domaine applicatif ou à
l’organisation du projet.
Le pilotage par les risques implique une analyse des risques potentiels le plus tôt possible,
dès les premières itérations, et leur hiérarchisation. Cela conduit à travailler prioritairement
78 Partie 1. Le développement logiciel

sur les éléments les plus exposés, comme l’architecture de l’application ou la gestion des
ressources humaines.

b) La gestion des exigences

(R)UP recommande de se servir des cas d’utilisation UML pour exprimer les exigences
fonctionnelles. (R)UP indique que les exigences doivent être organisées, enregistrées et
tracées, si possible avec un outil. On retrouve ce qui est demandé au niveau de maturité 2
du CMMI en matière de gestion des exigences (cf. paragraphe 1.5). Par contre, on ne voit
pas d’apport conséquent de (R)UP pour ce qui est demandé au niveau de maturité 3 dans le
domaine du développement des exigences.

c) La maîtrise des modifications

La multiplication du nombre de versions, liée au nombre d’itérations et à l’évolution des
besoins dans le temps, ainsi que la parallélisation des développements impliquent de gérer
les modifications.
Les demandes doivent être formalisées sous la forme d’une demande de changement (change
request), d’une demande d’extension (feature request) ou d’un rapport d’anomalie (bug
report), enregistrées, négociées, validées et tracées.
Il faut en parallèle gérer les configurations du logiciel et les versions de ses composants, mais
aussi les artefacts associés (documentations, scripts de configuration, etc.).

d) L’évaluation continue de la qualité

Tester en fin de développement n’est pas suffisant. Il faut des tests systématiques tout au long
du développement, susceptibles de déclencher des actions qualité.
L’évaluation continue de la qualité doit permettre une identification précoce des problèmes,
une bonne réactivité aux déviations et la maîtrise des risques de dérapage.

e) La modélisation visuelle avec UML

La bonne quantité de modélisation visuelle se situe entre le trop et le pas assez. Des schémas
dessinés sur un tableau blanc, sont plus efficaces pour exprimer des idées et les communiquer,
que d’écrire ou changer du code directement.

5.1.4. Conclusion
En tant que cadre général (R)UP doit être instancié et adapté en fonction des spécificités du
projet, de sa complexité et d’éventuelles règles propres à l’organisation qui l’héberge.
Cette adaptation concerne non seulement la forme des documents utilisés ou la nature des
outils déployés, mais aussi de manière plus fondamentale la manière de mettre en œuvre
le cycle de vie, incluant par exemple l’existence d’itérations parallèles au sein des grandes
équipes de développement ou la manière de coder. Certaines préconisations de XP, présentées
au paragraphe suivant, peuvent parfaitement trouver leur place dans le cadre de (R)UP.
5 • (R)UP, XP et Scrum 79

5.2 EXTREME PROGRAMMING (XP)

Ce cadre technique pour le développement agile des applications a été conçu à l’origine par
Kent Beck [Bec99].
Son nom ne doit pas être mal interprété. Il ne s’agit pas d’une « méthode pour extrémistes de
la programmation » qui méconnaîtraient l’importance de la conception ou des tests !
L’idée directrice consiste au contraire à pousser « à l’extrême » les meilleures pratiques du
développement logiciel.
– Puisque la revue de code est une bonne pratique, elle doit être pratiquée par un binôme de
développeurs où chacun contrôle en permanence la production de l’autre.
– Puisque les tests sont utiles, ils doivent être systématiquement créés avant chaque écriture
de code et tous vérifiés après chaque modification de l’application.
– Puisque la conception est importante, elle doit être pratiquée tout au long du projet, en
remaniant à chaque fois que nécessaire les codes (refactoring).
– Puisque l’intégration des modifications est cruciale, elle doit être effectuée plusieurs fois
par jour.
– Puisque les besoins évoluent vite, les cycles de développement doivent être extrêmement
courts.

5.2.1. Les valeurs

XP met en avant quatre valeurs, qui sont des normes de conduite individuelle ou sociale.
La communication : Le développement logiciel est un effort collectif de création qui
exige une vision commune et une bonne synchronisation des acteurs. Dans ce cadre, la
communication est fondamentale.
Au sein de l’équipe de développement, XP privilégie la communication orale directe
par rapport à l’échange de documents, car cette forme de communication permet une
meilleure réactivité. Sa faible structuration et traçabilité est compensée par l’existence de
contreparties écrites, principalement au sein du code (commenté) et des jeux de tests.
Par ailleurs, les développeurs communiquent en direct avec le client.
Le retour d’information (feedback) : Les boucles de feedback sont essentielles pour
réduire les risques. Elles permettent de connaître l’état réel du projet et de rectifier
sa trajectoire si nécessaire. Les boucles de feedback facilitent aussi l’acquisition
d’expérience et l’amélioration continue des pratiques.
Le courage : Il consiste d’une part à accepter de se lancer dans un projet non entièrement
spécifié et de changer fréquemment de rôle et de vision.
Il consiste d’autre part, à travers le feedback et une communication franche et ouverte, à
accepter de montrer ses propres limites et insuffisances.
La simplicité : Il faut viser « la chose la plus simple qui puisse marcher », sans confondre
toutefois simple et simpliste. Cela peut concerner autant le processus que le code. Par
exemple, éviter toute complexité inutile ou duplication à l’intérieur des codes.
80 Partie 1. Le développement logiciel

5.2.2. Les pratiques

De ces quatre valeurs dérivent douze pratiques. Les quatre premières sont liées à la gestion
de projet, les quatre suivantes à la communication et les quatre dernières à la programmation.
(1) Client sur site : Le client doit être intégré physiquement à l’équipe de développement
pour répondre aux questions des développeurs et définir les tests fonctionnels.
Une telle implication continue du client n’est évidemment pas toujours facile à mettre en
pratique.
(2) Rythme soutenable : Il faut savoir travailler mais aussi savoir se reposer. L’équipe doit
adopter un rythme de travail raisonnable qui lui permette de fournir un travail de qualité
tout au long du projet.
Par exemple, éviter de dépasser les horaires hebdomadaires prévus. Si les heures
supplémentaires sont nécessaires deux semaines de suite, c’est le symptôme d’un
problème qu’il faut résoudre plutôt que de le masquer par un surplus de travail.
(3) Livraisons fréquentes : La première livraison, minimale, doit arriver le plus tôt possible,
afin de dissiper d’éventuels malentendus et de donner une matérialité au projet.
Les livraisons suivantes doivent être aussi proches que possible (1 à 6 mois), pour
permettre un pilotage précis du projet et montrer son avancement. Chaque livraison
permet un feedback vers le client et vers les développeurs.
(4) Planification itérative : La planification s’effectue à deux niveaux de granularité : les
livraisons, associées à des fonctionnalités, et les itérations, associées à des tâches à
réaliser par les développeurs.
On compte de 4 à 6 itérations en moyenne par livraison, d’une durée de 1 à 4 semaines
chacune.
La réunion de planification des livraisons (release planning meeting) définit un plan des
livraisons (release plan) pour l’ensemble du projet. Ce plan est utilisé pour définir des
plans d’itération (iteration plan) au début de chaque itération.
Ces plans peuvent être revus et remaniés à tout moment pour tenir compte de l’expérience
acquise par le client et l’équipe de développement.
(5) Programmation en binôme : Cette organisation correspond à une forme de revue de code
permanente. Le pilote écrit le code et le co-pilote le relit et fait des propositions.
Les binômes changent fréquemment (plusieurs fois par jour). Les affectations sont libres.
Chaque développeur est responsable de ses tâches. À tout instant, soit il travaille sur une
de ses tâches, soit il aide quelqu’un d’autre à réaliser les siennes.
Cette organisation fonctionne mieux dans un espace de travail ouvert (salle de projet ou
war room).
(6) Appropriation collective du code : Chaque binôme peut intervenir sur n’importe quelle
partie du code et chacun est responsable de l’ensemble. Les spécialistes doivent devenir
polyvalents et agissent comme des consultants internes.
(7) Intégration continue : On peut avoir plusieurs intégrations par jour. Cette pratique permet
de profiter immédiatement des efforts de chacun, sans avoir à attendre une période
d’intégration lointaine.
Les modalités techniques de l’intégration continue sont présentées au paragraphe 5.5.2.
5 • (R)UP, XP et Scrum 81

(8) Développement dirigé par les tests : Les tests unitaires sont automatisés pour être rejoués
à chaque évolution du code (non-régression). Ils sont écrits en premier, avant le code
qu’ils testent. Ils servent à documenter le code (notion de contrat).
Les modalités techniques du développement dirigé par les tests sont présentées au
paragraphe 5.4.
(9) Règles de codage et de nommage : Une homogénéisation est nécessaire pour permettre
l’appropriation collective. Elle permet une prise en main plus rapide du code écrit par
d’autres.
Les règles doivent être définies avant le démarrage du projet. Elles peuvent concerner
la présentation du code (indentation, espaces, etc.), l’organisation des commentaires, les
règles de nommage (classes, méthodes, constantes, etc.), le vocabulaire commun, des
pratiques de codage ou idiomes (parcours de liste, singletons, etc.).
(10) Conception simple : On peut résumer cette philosophie de la façon suivante « il vaut
mieux faire simple aujourd’hui, quitte à changer demain, plutôt que de faire tout de suite
compliqué sans être absolument certain de l’utilité de ce que l’on développe ».
Plutôt que de tenter de trouver dès le début une architecture idéale assez générique pour
accueillir toutes les fonctionnalités et survivre aux évolutions, l’idée est de considérer
chaque fonctionnalité tour à tour et de rechercher une solution simple et fonctionnelle
sans essayer d’aller au-delà, quitte à devoir remanier régulièrement le code déjà
développé.
Cette philosophie correspond aux préceptes « Do the simplest thing that could possibly
work » (« Faire la chose la plus simple qui puisse fonctionner ») et « You Aren’t Gonna
Need It » ou YAGNI (« Tu n’en auras pas besoin »).
La simplicité recherchée n’est pas la facilité. Elle se caractérise entre autres choses par :
– des idées exprimées clairement et ponctuellement,
– un nombre minimal de classes, de méthodes et de lignes de code,
– pas de duplications de code,
– des tests, tous exécutés avec succès à tout moment.
(11) Utilisation de métaphores : La documentation est limitée au maximum. En effet, les tests
fonctionnels documentent les spécifications, les tests unitaires et le code documentent la
conception détaillée.
Il reste essentiellement à définir la vision d’ensemble de l’application. Elle doit éviter
le jargon technique et utiliser plutôt des analogies avec la vie réelle (métaphores) et des
expressions imagées qui parlent à tout le monde.
(12) Remaniement (refactoring) du code : Remanier signifie modifier un logiciel de façon à
améliorer sa structure interne sans changer son comportement externe.
Martin Fowler a répertorié des dizaines de symptômes de problèmes (code smells), décrits
avec précision un peu à la manière des patrons de conception : code dupliqué, code mort,
trop de paramètres, trop grosse méthode, trop grosse classe (God object), etc.
À noter que certaines corrections peuvent être appliquées automatiquement par des
environnements de développement comme Eclipse.
82 Partie 1. Le développement logiciel

5.2.3. Les rôles

Le programmeur (développeur) est au cœur de tout. Il est à la fois codeur, concepteur et
analyste. Il doit viser l’excellence. Il reçoit des responsabilisés qui vont bien au-delà de la
seule technique, comme l’estimation des charges et des délais, qui doivent l’inciter à donner
le meilleur de lui-même.
Le client est intégré à l’équipe et il explique ce qu’il souhaite via les user stories et les tests
d’acceptation qui doivent être passés avec succès par les livraisons.
Le testeur travaille avec le client pour définir et automatiser les tests d’acceptation. Il doit
communiquer sur la progression de nombre de tests passés (graphiques de progression) pour
motiver l’équipe.
Le tracker suit l’avancement des tâches en cours d’itération. Ce n’est pas un supérieur
hiérarchique mais quelqu’un qui cherche à détecter les problèmes au plus tôt en discutant
avec les programmeurs. Il « fait en sorte que la tâche de 3 jours en prenne 4 et non 6 » !
Le manager est le supérieur hiérarchique des programmeurs, qui s’occupe matériellement de
l’équipe, demande des comptes sur les engagements pris, et réalise l’interface avec l’extérieur.
Le coach est le garant du processus. C’est un expert de la méthode XP, un expert technique,
programmeur chevronné, architecte, pédagogue et doté de sang-froid pour faire face aux
difficultés.

5.2.4. Le processus
Un projet XP présente la structure que décrit la figure 5.5.

F IGURE 5.5 Processus XP au niveau macroscopique

(1) Une phase d’exploration pendant laquelle les user stories initiales et les éléments
architecturaux initiaux du projet (concepts et composants) sont déterminés avec les
clients.
(2) Une phase de planification pendant laquelle sont sélectionnées avec les clients les stories
à implanter dans la première livraison et les livraisons suivantes (release plan). Les
5 • (R)UP, XP et Scrum 83

stories choisies pour la première livraison sont décomposées en tâches à réaliser dont
les durées sont estimées par les développeurs.
(3) Une phase de construction incrémentale de la livraison. Les itérations d’une durée d’une
à quatre semaines sont planifiées de manière souple (cf. figure 5.6).
Chaque itération permet de recalculer la vélocité. Elle peut éventuellement créer de
nouvelles stories. Quand l’ensemble des tests fonctionnels (d’acceptation) passent, on
entame la mise en production de la livraison.
(4) Une phase de mise en production de la livraison impliquant l’accord du client.
(5) Une phase de maintenance qui répète les phases de planification, construction et mise
en production pour les livraisons suivantes (2 à n). Ce cycle se répète tant que le client
peut sélectionner des stories à livrer.

Généralement, la première livraison est celle qui inclut le volume le plus important de
fonctionnalités et ébauche le squelette du système (the whole system in a skeletal form).
Au niveau microscopique, chaque itération de la phase de construction s’organise autour du
développement dirigé par les tests.

F IGURE 5.6 Processus XP au niveau microscopique

5.2.5. Conclusion
a) Forces et faiblesses

La production de logiciels de bonne qualité bien adaptés aux besoins des clients et l’efficacité
pour les petits projets sont les points le plus souvent portés à l’actif de XP.
A contrario, la limitation des équipes à 20 personnes au maximum, l’investissement très
important demandé au client, et la programmation en binôme pas toujours bien ressentie,
sont fréquemment mis au passif de XP.
84 Partie 1. Le développement logiciel

Enfin XP est plus facile à appliquer en interne qu’avec un prestataire externe. Les contrats
au « forfait » classiques, où le fournisseur s’engage à un résultat donné, dans un délai donné,
pour un prix fixé, sont délicats à mettre en place. Il faut forfaitiser chaque itération ou chaque
livraison avec la possibilité pour le client d’interrompre le contrat. Il faut accepter aussi
le « troc d’exigence », c’est-à-dire l’ajout d’une nouvelle exigence en échange du retrait
d’une autre moins importante et de même coût. Même les « régies », où le fournisseur met à
disposition du personnel, ne sont envisageables qu’avec des personnes très expérimentées et
motivées.

b) XP et (R)UP
Certaines pratiques de XP peuvent être utilisées dans tout projet (R)UP, alors que c’est
beaucoup moins évident pour d’autres.
Parmi les pratiques compatibles on peut citer par exemple le développement dirigé par les
tests et l’intégration continue.
Par contre l’appropriation collective du code est peu crédible dès que la taille du projet devient
importante. Le remaniement permanent du code, acceptable pour les petits projets, s’oppose
à l’idée d’une architecture clairement définie, souvent considérée comme essentielle dans les
gros projets et les projets critiques. De même, des livraisons très rapides peuvent ne pas être
souhaitables pour des gros systèmes où la logistique du déploiement est lourde et coûteuse.

5.3 SCRUM
Scrum est un cadre de gestion d’un projet agile [SB01]. Scrum signifie « mêlée de rugby ».
L’image est qu’on fait progresser le ballon en travaillant ensemble, comme on fait progresser
un projet en travaillant ensemble. Scrum reprend les principes de base des méthodes agiles :
– itérations courtes (appelées sprints), produisant une version potentiellement livrable,
– travail en collaboration étroite entre tous les intervenants, sans « spécialistes » et sans
primes individuelles selon les performances,
– avec un rythme de développement soutenable,
– avec une équipe qui s’auto-organise.

5.3.1. Les rôles

Scrum sépare les « cochons » (pigs), c’est-à-dire les membres de l’équipe de développement,
et les « poulets » (chickens), c’est-à-dire les personnes extérieures à l’équipe, intéressées par
le développement (stakeholders) incluant :
– le Client, extérieur ou interne, qui commande et paye le développement et peut donner du
feedback,
– l’Utilisateur final, qui connaît les besoins, contribue à définir le produit et donne du
feedback,
– le Manager, qui met en place un environnement optimal pour le déroulement du projet.
5 • (R)UP, XP et Scrum 85

Parmi les « cochons » on distingue :

– Le Product Owner, qui représente les « poulets » au sein de l’équipe, est chargé de :
• communiquer une vision claire du produit et définir ses caractéristiques,
• piloter le projet d’un point de vue métier,
• s’assurer que l’équipe de développement se concentre sur les aspects à plus forte valeur
ajoutée.
– Le Scrum Master est chargé principalement de :
• vérifier la mise en œuvre de Scrum,
• assurer la bonne collaboration au sein de l’équipe de développement et avec le Product
Owner,
• protéger l’équipe de développement des turbulences et lever les obstacles qui pourraient
apparaître.
– L’équipe de développement (Team), pluridisciplinaire et autogérée, comporte de cinq à
neuf personnes qui sont chargées de :
• travailler avec les utilisateurs finaux, les clients, le Product Owner pour comprendre les
exigences métier,
• collaborer pour spécifier, coder, valider et documenter le produit,
• délivrer un produit de qualité.
On parle parfois de Scrum team pour l’équipe de développement complétée par le Scrum
Master et le Product Owner.

5.3.2. Les artefacts

a) Le product backlog

Le travail de l’équipe de développement s’organise autour d’un artefact particulier, le product

backlog (« carnet de produit »). Backlog signifie quelque chose comme le « restant dû ».
Il s’agit d’une liste d’items (user stories ou epics) qui restent à développer par priorités
décroissantes. Chaque item inclut une définition, un effort estimé et une priorité. Les plus
prioritaires sont aussi les plus détaillés (cf. figure 5.7).
Le Product Owner génère la liste initiale des items. L’équipe associe à chaque item un effort
estimé. Il s’agit d’une estimation relative entre items exprimée en points (story points) plutôt
que d’une estimation absolue en durée. La technique du Planning Poker est préconisée pour
obtenir cette estimation en points :
(1) Les membres de l’équipe disposent chacun d’un jeu de cartes dont les valeurs suivent la
suite de Fibonacci, 1, 2, 3, 5, 8, 13, 21, 34, 55. . . plus éventuellement une carte « infini »
qui signifie que l’item est trop gros et doit être scindé en au moins deux parties.
(2) Chacun joue une carte face cachée représentant son estimation en points de l’effort.
(3) Si tout le monde est d’accord, ou presque, l’estimation est adoptée.
86 Partie 1. Le développement logiciel

F IGURE 5.7 Le product backlog

(4) Sinon, le plus pessimiste et le plus optimiste expliquent leur vote, des discussions rapides
ont lieu, puis on recommence en (2).
La figure 5.8 résume toutes les opérations courantes sur le backlog.

F IGURE 5.8 Les opérations courantes sur le product backlog

Le Product Owner, éventuellement avec le Scrum Master, donne une priorité à chaque item,
en fonction d’un objectif, comme par exemple la maximisation du retour sur investissement.
Une user story est supprimée du backlog quand elle est « finie » (done). Cette notion de
« fini » doit être définie avec précision et être partagée par tous au sein du projet, car elle
5 • (R)UP, XP et Scrum 87

garantit la qualité du logiciel. Elle dépasse la seule notion de test réussi et peut concerner
bien d’autres aspects comme l’ergonomie, la documentation, les performances, etc. Elle doit
être appliquée rigoureusement : « À moitié fini n’est pas fini » (half done is not done) !
Le backlog peut être complété par de nouvelles stories à chaque itération si des besoins
nouveaux apparaissent.

b) Le sprint backlog
Un sprint est une itération courte de deux à quatre semaines, débouchant sur une version
potentiellement livrable, c’est-à-dire testée et documentée.
Elle s’appuie sur un sprint backlog (ou « carnet de sprint ») qui est l’extrait du product
backlog concerné par le sprint. Une fois qu’un sprint est initialisé, il doit se dérouler comme
prévu jusqu’au bout.

F IGURE 5.9 Structure d’un sprint

Le sprint backlog prend la forme d’un tableau avec un ensemble de Post-it, un par tâche
assignée au sprint, répartis en trois colonnes : « à faire », « en cours », « fait ». Le passage de
« à faire » à « en cours » est fait individuellement par chaque intervenant le matin. Le passage
de « en cours » à « fait » se fait en fin de journée, si tout ce qui a été spécifié comme indiquant
qu’une tâche peut être considérée comme faite, a été réalisé. Si une tâche n’est pas finie, il y
a mise à jour de l’effort restant.
Pendant un sprint :
– le but ne peut être modifié,
– la composition de l’équipe reste a priori inchangée,
– la qualité n’est pas négociable,
– la liste d’items est négociée entre le Product Owner et l’équipe de développement.

c) Le sprint burndown chart

Ce graphique représente en abscisses, l’écoulement du temps en jours ouvrables du début à
la fin du sprint, et en ordonnées, le montant de travail restant à faire estimé en points.
88 Partie 1. Le développement logiciel

F IGURE 5.10 Le sprint backlog

L’avancement idéal est représenté par une droite. L’avancement réel est souvent moins
linéaire en fonction des avances ou des retards pris par l’équipe.

F IGURE 5.11 Le sprint burndown chart

d) Le product burndown chart

Ce graphique représente en abscisses, les sprints successifs, et en ordonnées, le montant de
travail restant à faire estimé en points.
Connaissant la vélocité de l’équipe, il permet d’estimer le nombre de sprints qui restent à
réaliser pour terminer le produit.

5.3.3. Les réunions

Plusieurs réunions rythment le développement de l’application (cf. figure 5.12).

a) Le sprint planning meeting

La planification d’un sprint se réalise au cours d’une réunion de planification (sprint planning
meeting), d’une journée au maximum. Dans un premier temps le Product Owner choisit les
items qu’il aimerait voir implantés dans le sprint (le QUOI).
5 • (R)UP, XP et Scrum 89

F IGURE 5.12 Les réunions

Le nombre d’items possibles dépend de la vélocité de l’équipe. Elle se calcule par la somme
des points des stories qui ont été terminées lors du précédent sprint. Elle ne doit pas être
gonflée artificiellement en rognant sur les exigences de qualité.
Dans un deuxième temps, l’équipe et le Product Owner discutent pour mieux appréhender
ce qui est attendu pour chaque item (le COMMENT), c’est-à-dire la conception en termes
d’architecture, de composants, d’interfaces, de données, etc. Les items sont découpés en
tâches, qui sont ajoutées au sprint backlog. Un effort estimé (en heures) est associé à chaque
tâche. Il n’y a pas d’attribution des tâches à un participant, sauf si une compétence unique est
requise.
Remarque : Il est possible également de planifier les livraisons qui seront fournies aux
utilisateurs. Entre deux livraisons effectives, plusieurs sprints sont en général nécessaires.
Pour éviter une dérive vers une approche trop prédictive et rigide, ce type de planification
doit rester souple et modifiable après chaque sprint.

b) Le daily scrum
Chaque jour, le daily scrum ou « mêlée quotidienne » est une réunion de type stand-up
(debout) et de durée très réduite (environ un quart d’heure) où chacun expose :
– ce qu’il a fait la veille,
– ce qu’il compte faire ce jour,
– les embûches éventuelles.

Il n’y a pas de discussion pendant le daily scrum. Si cela semble nécessaire, les discussions
se tiennent après, lors d’un follow-up meeting.
Après ces réunions, le travail de développement est effectué. En fin de journée, le sprint
backlog est mis à jour de même que le sprint burndown chart.
90 Partie 1. Le développement logiciel

Le sprint se termine à la date prévue, que la totalité du sprint soit réalisée ou non, sans
multiplier les heures supplémentaires. Cette terminaison comprend une revue et une
rétrospective de sprint.

c) La revue de sprint
La revue de sprint (quatre heures maximum) consiste à inspecter le produit. Il est présenté par
l’équipe au Product Owner. Les « poulets » participent en général à cette réunion. « Poulets »
et « cochons » sont libres de poser des questions et d’y répondre. Il s’agit de vérifier si les
items sont « bien faits ». Cela passe par une démonstration du produit, mais ne doit pas se
limiter à cela. Le backlog et les plannings sont revus en fonction des tâches ou items non
réalisés.

d) La rétrospective de sprint
La rétrospective de sprint (trois heures maximum) consiste à inspecter le processus. L’équipe
et le Scrum Master y participent. Le Scrum Master doit limiter ses interventions pour garder
au maximum une position neutre. La présence du Product Owner n’est pas indispensable.
Un tableau à trois colonnes sur ce qui « marche bien», ce qui « marche mal » et ce qui pourrait
être fait pour améliorer la situation est élaboré. Chaque intervenant dispose un ou plusieurs
items dans chaque colonne. Les items répétés sont marqués par des barres pour chaque
occurrence supplémentaire. L’équipe discute des modifications à essayer dans le prochain
sprint pour corriger les défauts.

F IGURE 5.13 La rétrospective de sprint

5.3.4. Réflexions sur Scrum

a) La gestion et le développement des besoins
La gestion des exigences au sens du niveau 2 du CMMI (cf. paragraphe 1.5) est assurée par le
Product Owner. Les besoins sont exprimés sous forme de user stories qui sont stockées dans
le product backlog et le sprint backlog sous son contrôle.
5 • (R)UP, XP et Scrum 91

Scrum apporte aussi des réponses pour le développement des exigences au sens du niveau 3
du CMMI, incluant par exemple l’intégration continue du client à l’équipe de développement
ou la systématisation des démonstrations du produit pour valider les exigences.

b) La possibilité de changer d’échelle

La limitation des équipes à moins d’une dizaine de personnes est un facteur limitant
important. Selon Jeff Sutherland, co-fondateur de la méthode, il est possible d’utiliser Scrum
dans des projets de plus de 500 personnes. L’idée, appelée « Scrum de Scrums » ou « Méta-
Scrum », consiste à diviser le projet entre n équipes. Un Scrum of Scrums meeting réunit
une personne de chaque équipe pour coordonner le travail. Ces réunions sont similaires à la
mêlée quotidienne mais avec une fréquence moindre (deux par semaine suffisent souvent).
Pour les très gros projets, on peut avoir des Scrum of Scrums meetings à plusieurs niveaux.

c) La complémentarité de Scrum et XP

La complémentarité de Scrum et XP est communément admise. Scrum se positionne au

niveau de la gestion et de l’organisation de projet alors que XP se positionne au niveau des
activités de développement. C’est la raison pour laquelle ces deux approches se marient
si bien ensemble : elles s’attachent à des problématiques différentes et se complètent
mutuellement. La figure 5.14 montre un mélange habituel des concepts des deux approches.

F IGURE 5.14 Les pratiques combinées de Scrum/XP

Si on raisonne en termes de feedback, la complémentarité et la puissance de l’approche

combinée sont aussi évidentes. Le feedback est partout, avec toutes les fréquences de
rétroaction possibles, comme l’illustre la figure 5.15.
92 Partie 1. Le développement logiciel

F IGURE 5.15 Les rétroactions multiples de Scrum/XP

5.4 LE DÉVELOPPEMENT DIRIGÉ PAR LES TESTS

5.4.1. Présentation
Le développement dirigé par les tests (Test-driven development ou TDD) est une technique
popularisée par XP qui a rencontré un écho dépassant largement le cadre de cette seule
méthode. La technique est fondée sur deux idées principales.
La première est l’importance de la conception des tests pour améliorer la qualité du logiciel :
« More than the act of testing, the act of designing tests is one of the best bug preventers
known. The thinking that must be done to create a useful test can discover and eliminate
bugs before they are coded » [Bei90] (« Plus que l’acte de tester, l’acte de concevoir des tests
est une des meilleures manière de prévenir les bugs. La réflexion qui doit être conduite pour
créer un test utile aide à découvrir et éliminer les bugs avant même qu’ils soient codés »).
C’est une idée déjà présente dans le modèle en V qui prône la conception des tests dans la
phase descendante et leur exécution dans la phase ascendante. Cela peut concerner les tests
d’acceptation comme les tests unitaires.
La seconde idée est de concevoir les tests unitaires utiles juste avant de coder chaque morceau
de code : « Test a little, code a little » (« Tester un peu, coder un peu »). Dans cette optique, les
tests unitaires deviennent la spécification du code (non ambigüe a priori). Le pseudocode et
le schéma qui suivent résument cette manière de travailler qui combine les tests d’acceptation
au niveau du système et les tests unitaires au niveau de chaque morceau de code.
répéter
choisir une fonctionnalité à implanter
créer et/ou modifier les tests d’acceptation
répéter
le développeur choisit une unité à écrire et/ou modifier
le développeur crée et/ou modifie les tests unitaires
5 • (R)UP, XP et Scrum 93

répéter
le développeur écrit et/ou modifie le code de l’unité
jusqu’à ce que tous les tests unitaires passent
jusqu’à ce que tous les tests d’acceptation passent
jusqu’à qu’il ne reste plus de fonctionnalité à implanter

F IGURE 5.16 Le processus du TDD

À noter qu’initialement un test doit toujours échouer car le code correspondant n’est pas
encore écrit ! À noter également que chaque itération de test et codage s’accompagne d’une
activité de remaniement (refactoring) du code :
1. Écrire un petit nombre des tests unitaires automatisés.
2. Vérifier qu’ils échouent (car le code testé n’existe pas encore)
ce qui montre qu’ils sont valides.
3. Écrire le code suffisant pour passer les tests.
4. Lancer les tests jusqu’à ce qu’ils passent tous,
sinon corriger le code.
5. Remanier le code, pour améliorer sa conception ou ses performances
tout en gardant les mêmes fonctionnalités.

Le développement dirigé par les tests présente de nombreux avantages :

– Une suite complète de tests est construite progressivement.
– Cette suite peut être exécutée à chaque évolution du code (chaque compilation).
– Tous les tests qui passaient auparavant doivent continuer à passer (non-régression).
– Le code peut être remanié avec confiance car il ne régressera jamais.

L’essentiel des tests peut être exécuté automatiquement. Il existe de nombreux frameworks
pour automatiser le test unitaire, comme JUnit pour Java, où les tests sont écrits dans le même
langage que le code.

5.4.2. Un exemple en Java avec le framework JUnit

On veut coder une méthode qui compte le nombre de chiffres dans un entier non négatif et
qui ne commence pas par des zéros inutiles :
public static int compterChiffres(long n)
94 Partie 1. Le développement logiciel

Un premier test porte sur la plus petite valeur, 0L. Pour éviter d’avoir à dupliquer plusieurs
fois le code de test, on l’écrit pour qu’il puisse tester n’importe quelle valeur passée en
paramètre.
private void testValeur(long n, int resultatOK) {
System.out.println("compte les chiffres de "+n);
int resultat = compterChiffres(n);
assertEquals("resultat", resultatOK, resultat);
}
@Test
public void test0() {
testValeur(0L, 1);
}

Ce code ne compile pas car le code de la méthode compterChiffres n’est pas écrit. Pour
le faire compiler on peut se contenter dans un premier temps d’écrire :
public static int compterChiffres(long n) {
return 1;
}

Le test passe. On ajoute un deuxième test pour le plus grand nombre qui donne 1, soit 9L.
@Test
public void test9() {
testValeur(9L, 1);
}

Les deux tests passent. On ajoute un troisième test pour le plus petit nombre qui donne 2, soit
10L.
@Test
public void test10() {
testValeur(10L, 2);
}

Bien entendu le test ne passe plus. Il faut coder la méthode compterChiffres de manière
plus réaliste. On la réécrit avec une itération qui compare n aux puissances successives de
10 :
public static int compterChiffres(long n) {
int res = 1;
long p10 = 10L;
while (!(n < p10)) {
p10 *= 10;
res++;
}
return res;
}

Les trois tests passent maintenant. On généralise à une longueur quelconque (par exemple 5),
avec un quatrième test pour la plus grande valeur qui donne 5, soit 99999L.
5 • (R)UP, XP et Scrum 95

@Test
public void test99999() {
testValeur(99999L, 5);
}

Les quatre tests passent. On ajoute un cinquième test pour la plus petite valeur qui donne 6,
soit 100000L.
@Test
public void test100000() {
testValeur(100000L, 6);
}

Les cinq tests passent. On teste maintenant la plus grande valeur possible sur 64 bits,
Long.MAX_VALUE soit 263 − 1 ou 9223372036854775807, de longueur 19.
@Test
public void testmax() {
testValeur(Long.MAX_VALUE, 19);
}

Le test ne passe pas, il boucle indéfiniment.

Remarque : On peut borner le temps avec l’annotation @Test(timeout=1000) qui ar-
rête l’exécution après une seconde.
L’explication est que p10 *= 10; déborde et passe donc dans les valeurs négatives, ce
qui permet au programme de continuer. Il faut écrire la méthode compterChiffres de
manière plus robuste.
L’idée et de faire décroître n au lieu de faire croître p. Soit :
public static int compterChiffres(long n) {
int res = 1;
while (10 <= n) {
n /= 10;
res++;
}
return res;
}

Cette fois-ci tous les tests passent. On est en droit d’avoir une certaine confiance en cette
dernière implantation.
La classe à tester :
public class ClasseATester{
public static int compterChiffres(long n) {
int res = 1;
while (10 <= n) {
n /= 10;
res++;
}
return res;
}
}
96 Partie 1. Le développement logiciel

La classe de test :
import static org.junit.Assert.*;
import org.junit.*;
public class ClasseTest {
private void testValeur(long n, int resultatOK) {
System.out.println("compte les chiffres de "+n);
int resultat = ClasseATester.compterChiffres(n);
assertEquals("resultat", resultatOK, resultat);
}
@Test
public void test0(){
testValeur(0L, 1);
}
@Test
public void test9(){
testValeur(9L, 1);
}
@Test
public void test10(){
testValeur(10L, 2);
}
@Test
public void test99999(){
testValeur(99999L, 5);
}
@Test
public void test100000(){
testValeur(100000L, 6);
}
@Test
public void essaiMax(){
testValeur(Long.MAX_VALUE, 19);
}
}

Le compilation en ligne de commandes sous Windows dans un répertoire qui contient tous
les fichiers et les librairies s’écrit :
javac -cp .;junit-4.11.jar ClasseTest.java

L’exécution en ligne de commande s’écrit :

java -cp .;junit-4.11.jar;hamcrest-all-1.3.jar org.junit.runner.JUnitCore
ClasseTest

Le résultat obtenu est le suivant :

5 • (R)UP, XP et Scrum 97

Il existe des cas de figure beaucoup plus complexes, en particulier quand on doit recourir
à des objets factices (mock objects ou mocks) car l’objet réel n’existe pas encore ou car il
est trop coûteux à utiliser dans un test, comme une base de données complexe. Ce mock a la
même interface que l’objet qu’il simule. Il existe des frameworks spécialisés dans la définition
et la manipulation des différentes catégories d’objets factices (mock, stub, spy, etc.), comme
Mockito pour Java. Ces frameworks permettent au minimum de spécifier quelles méthodes
vont être appelées, dans quel ordre, ainsi que les valeurs retournées.

5.5 LES OUTILS DU DÉVELOPPEMENT AGILE

Le développement agile s’appuie souvent sur une combinaison d’outils low tech pour la
communication et la collaboration et d’outils high tech pour la gestion des artefacts.

5.5.1. Les outils low tech

Les outils de communication et de collaboration usuels font partie de cette catégorie. Ils
jouent un rôle essentiel pour l’analyse, la conception et la gestion de projet. On y retrouve
les Post-it, les posters affichés aux murs, les tableaux blancs, les grilles Excel, etc. La
communication active passe par la programmation en binôme et les multiples réunions en
face-à-face. La communication passive passe par les « radiateurs d’informations » ou autres
« kanban des tâches » affichés aux murs de la salle de projet.

5.5.2. Les outils high tech pour l’intégration continue

La gestion des artefacts du développement (codes sources, binaires, tests unitaires, scripts de
construction, de déploiement, etc.) et l’assurance qualité font au contraire appel à des outils
logiciels parfois sophistiqués.
L’intégration continue est prônée par les méthodes agiles. Elle consiste à reconstruire
l’application, on dit « produire un build », très fréquemment et en tout cas plusieurs fois
par jour. Il existe différents types de builds, plus ou moins complets. Builds privés par le
développeur sur sa machine, build d’intégration pendant la journée pour tester toutes les
modifications ensemble, build de nuit plus poussé avec la production de rapports détaillés à
consulter le matin. Tout ou partie des opérations suivantes sont exécutées lors d’un build :
– chargement de la dernière version depuis le gestionnaire de sources,
– compilation des sources,
– exécution des tests unitaires,
– contrôle de la qualité du code,
– construction de l’artefact de déploiement (packaging),
– déploiement de l’application sur l’environnement de test,
– exécution des tests d’intégration, de performance, etc.,
– génération de la documentation,
– génération de rapports.
98 Partie 1. Le développement logiciel

L’intégration continue peut être mise en œuvre à l’aide d’un gestionnaire de versions (comme
CVS, Subversion, Git, etc.), d’un logiciel d’intégration continue (comme Jenkins/Hudson,
Apache Continuum, etc.) et éventuellement d’outils de mesure de la qualité (comme Sonar,
PMD, etc.). La figure 5.17 montre un scénario possible.

F IGURE 5.17 Un scénario d’intégration continue

(1) Le développeur code une fonctionnalité.

(2) Il la teste en local en faisant des builds privés sur sa machine avec des outils tels que Ant
ou Maven et en corrigeant les éventuelles erreurs.
(3) Il récupère la dernière version du code sur le gestionnaire de sources pour mettre à jour
son propre code (update).
(4) Il fusionne son code avec le code qu’il a récupéré, résout les conflits et refait des builds
privés pour corriger les éventuelles erreurs.
(5) Il publie sa nouvelle version (commit).
(6) Soit parce qu’il détecte un changement, soit à heure fixe, le logiciel d’intégration exécute
un build d’intégration en utilisant les différents scripts à sa disposition.
(7) L’application est déployée sur le serveur de test et testée.
(8) Le logiciel d’intégration génère les différents types de feedback qui ont été configurés,
comme RSS, mail, blog, etc. Les développeurs peuvent prendre connaissance de ces
feedbacks et réagir en conséquence, par exemple si le build a échoué.
5 • (R)UP, XP et Scrum 99

EXERCICES

Exercice 5.1. Caractéristiques des méthodes

Remplir le tableau suivant avec un + ou un ++ par case selon que la méthode satisfait (+) ou
satisfait préférentiellement (++) la caractéristique de la ligne.

Caractéristique (R)UP XP Scrum

Itérative et incrémentale
Centrée sur l’architecture
Centrée sur les tests
Centrée sur l’interaction client-développeur
Centrée sur la qualité du code
Convient aux grosses équipes
Convient aux petites équipes
Centrée sur les cas d’utilisation
Convient aux gros projets
Considère la gestion du risque

Exercice 5.2. QCM Scrum (une seule réponse possible par question)
Q1. Quel rôle est responsable de la définition des priorités au sein du product backlog ?
a) Product Owner b) Project Manager c) Lead Developer d) Scrum Master
Q2. Quel rôle n’est pas défini dans Scrum ?
a) Product Owner b) Scrum Master c) Product Manager d) Team
Q3. Quel document n’est pas un artefact Scrum ?
a) Product backlog b) User story c) Sprint backlog d) Burndown Chart
Q4. Quel type de réunion ne fait pas partie de Scrum ?
a) Product review meeting b) Sprint review meeting c) Sprint planning meeting
d) Sprint retrospective meeting
Q5. Quel est le nom de la réunion dans laquelle l’équipe démontre au Product owner et aux
autres personnes intéressées ce qui a été accompli durant le sprint ?
a) Sprint retrospective meeting b) Product review meeting c) Sprint review meeting
d) Stakeholder review meeting
Q6. Quand l’exécution d’un sprint est-elle finie ?
a) Cela dépend des événements b) Quand tous les items du product backlog sont « faits »
(done) c) Quand toutes les tâches planifiées sont finies d) À la fin de la durée prévue
(timebox)
Q7. Quelle est la durée normale du Daily Scrum meeting ?
a) 15 minutes b) Aussi longtemps que nécessaire c) 60 minutes d) 5 minutes
Q8. Quelle est la taille recommandée pour une équipe Scrum ?
a) 9 ± 3 b) 10 ± 3 c) 7 ± 2 d) Peu importe
100 Exercices

Q9. Comment le product backlog est organisé ?

a) Items par importance décroissante b) Items par taille décroissante c) Au hasard
d) Par catégories
Q10. Qui estime l’effort nécessaire pour réaliser un item du product backlog ?
a) Product owner b) Scrum master c) Team d) Le développeur le plus expérimenté

Exercice 5.3. Tests de validation

Soit le cas d’utilisation suivant. Comment construire un ensemble de tests d’acceptation
(positifs, c’est-à-dire conformes au cas, et négatifs, c’est-à-dire qui violent le cas) permettant
de valider ce cas ?

Nom : Réserver un vol

Description : Ce cas d’utilisation décrit la réservation d’un vol constitué d’une ou
plusieurs étapes par un voyageur.
Acteur principal : Voyageur
Acteurs secondaires : Agent de voyage, Commercial de la compagnie
aérienne
Préconditions :
– Chaque étape du vol existe.
– Il y a une place disponible dans la classe souhaitée pour chaque étape du vol.
– Toutes les exigences de réservation et de séjour sont satisfaites.
Postconditions :
– Les réservations pour chaque étape du vol sont faites.
– Le voyageur a reçu la confirmation.
– Les places disponibles ont été mises à jour.
Déroulement normal :
1. La demande de réservation est faite.
2. La demande de réservation est traitée.
Variantes :
1. Le voyageur règle sa réservation immédiatement.
2. Le voyageur demande une prestation optionnelle.
3. Le voyageur est sur la liste noire des passagers.
Autres cas liés : Annuler une réservation, Payer une réservation
Autres remarques :
– La transaction ne doit pas nécessiter plus de deux minutes.
– Le cas concerne uniquement une réservation pour un seul voyageur.