II.

Processus de
développement de logiciel
 Objectifs

 Comprendre les principes du génie logiciel :

 Expliquer les activités du cycle de vie de logiciel
et leurs livrables
 Distinguer les différents processus de
développement de logiciel
 S’initier aux méthodes Agile

2
 Plan

1. Rappel : Cycle de vie de logiciel

2. Activités de production de logiciel
3. Livrables
4. Processus de développement
1. Modèle en cascade
2. Modèle en V

3. Modèle en spirale

4. Modèles par incréments

5. Processus unifié (Unified Process - UP)

6. Méthodes Agile
3
Cycle de vie de logiciel

La production de logiciel suppose les activités :

 Étude de faisabilité
 Spécification  Intégration et Tests
 Conception  Exploitation
 Codage  Maintenance

4
Activités de production de logiciel

Étude de faisabilité
But : Déterminer si le logiciel est à la fois faisable
(techniquement) et rentable (économiquement)
Cette activité consiste à déterminer les avantages et
les inconvénients que procureraient la réalisation et
l’utilisation d’un nouveau logiciel. Elle est destinée
aux décideurs qui :
 valident les orientations
 chiffrent l’effort, coût de réalisation, gestion des délais,
temps de formation des utilisateurs, coût d’achat de
nouveaux matériels, récupération des anciennes données
5
Activités de production de logiciel

Analyse des besoins

But : Éviter de produire un logiciel non adéquat. Pour
établir les besoins (le cahier des charges) il faut
étudier :
 Le domaine d'application
 L'état actuel de l'environnement du futur système
 Le rôle du système
 Les ressources disponibles et requises
 Les contraintes d'utilisation
 Les performances attendues

Il faut établir un dialogue avec les experts du domaine, qui

ne sont pas forcément des informaticiens, à l’aide des
entretiens, des questionnaires…. 6
Activités de production de logiciel

Spécification

But : Établir une première description du futur

système et ses fonctionnalités

Cette activité utilise les résultats de l'analyse des

besoins, les considérations techniques et la
faisabilité informatique pour produire une
description de ce que doit faire le système mais
sans préciser comment il le fait (on précise
le quoi mais pas le comment).
7
Activités de production de logiciel

Spécification

But : Établir une première description du futur

système et ses fonctionnalités

 Description détaillée et explicite de tous les

modules / classes (point de vue fonctionnel).
 Entrées / sorties, qui « voit » qui, qui inclut qui,
qui dépend de qui ?...

8
Activités de production de logiciel

Conception
But : Enrichir la première description du logiciel
de détails d'implémentation

 Conception architecturale : détermine la structure

du système.
 Conception des interfaces : décrit la
communication entre les composants du système
 Conception détaillée : fournit pour chaque
composant une description de la manière dont les
fonctions ou les services sont réalisés :
algorithmes, représentation des données.
9
Activités de production de logiciel

Codage

But : Réalisation, à partir de la conception

détaillée, d'un ensemble de programmes ou de
composants de programmes.

10
Activités de production de logiciel

Intégration et tests

 But : réaliser un ou plusieurs systèmes

exécutables à partir des composants. Les choix
possibles correspondent à des variantes du
système.
 Différents niveaux de test :
 Tests unitaires pour les composants isolés ;
 Tests d'intégration pour un assemblage de
composants ;
 Test système qui consiste à tester le logiciel dans
des conditions opérationnelles et au delà.
11
Livrables
Étape Résultat
Phase exploratoire :
-Dossier d’entretien
-Décision (ne pas faire, acheter, faire faire, faire)
-Budget approximatif
Étude préalable -Cahier des charges
-Plan général du projet
-Budget précis
-Définition des contraintes

Document de spécification (fonctions et performances)

Première version du manuel d’utilisation
Spécification Plan détaillé du reste du projet
Plan de validation (test)
Définition des principales structures de données
Conception générale Décomposition du système en modules
Description du rôle de chaque module

Conception détaillée Description détaillée des structures de données et des modules

Test des programmes, chaque module vérifié séparément

Codage/Tests unitaires

Validation globale Compte-rendu de recette

Rapport d’inspection et de validation
Recette
Diffusion Versions des programmes et leur documentation adaptée aux
différentes catégories d’utilisateurs
Mise en production
Exploitation Programmes en fonctionnement
Rapport d’incidents et de correction
Maintenance 12
Cycle de vie de logiciel

 Dans un projet « bien conduit », l'effort se répartit

comme suit :
 40% spécification et conception,

 20% programmation,

 40% validation et vérification.

 Comparé aux autres produits, le logiciel présente des

particularités :
 Le problème de production en série ne se pose pas

 Il est produit selon un processus de

développement.

13
Processus de développement

 Caractéristiques du processus de développement :

 L’analyse des besoins, la conception et la validation occupent
une large place
 Le processus s’opère par raffinements successifs
 Certaines étapes peuvent déclencher la révision des étapes
précédentes
 Le processus se poursuit même après la livraison : la
maintenance

 Pour maîtriser le processus de développement, on se

réfère à des modèles permettant de prendre en
compte, en plus des aspects techniques,
l’organisation et les aspects humains : Modèles en
cascade, en V, en spirale, par incrément

14
Processus de développement

 Une étape peut faire intervenir plusieurs activités.

 Une activité peut se dérouler pendant plusieurs
étapes.
 Les relations entre les différentes activités, entre les
différentes étapes et entre les étapes et les activités
dépendent du modèle.
 Le processus du développement consiste à décomposer le
problème en veillant à :
 Bien décrire le problème et sa décomposition en sous-
problèmes
 Préciser le procédé de recomposition (Intégration)
 Concevoir et utiliser les solutions réutilisables
15
Modèles de cycle de vie

 Parmi les modèles de cycle de vie du logiciel, on

cite :

 Modèle en cascade

 Modèle en V

 Modèle en spirale

 Modèles par incréments

16
Modèle en cascade

Faisabilité
Analyse des besoins
Planification

Conception du
produit

Conception
détaillée
Codage

Intégration

Installation
Exploitation et
17
maintenance
Modèle en cascade

 Années 1970
 Linéaire, flot descendant
 Principe très simple : chaque phase se termine
à une date précise par la production de certains
documents ou programmes.
 Résultats définis sur la base des interactions
entre étapes et activités.
 On ne passe à la phase suivante que si les
résultats sont jugés satisfaisants.
 Retour limité à une phase en amont  Dans la
pratique, c’est absurde !!!!
18
Modèle en cascade

Faisabilité
Analyse des besoins
Planification

Conception du
produit

Conception
détaillée
Codage

Intégration

Installation
Exploitation et
19
maintenance
Modèle en cascade

 Phases gérables au niveau temps et ressources

 Bonne compréhension du système puisque le code est
créé assez tardivement
 Bien adapté lorsque les besoins sont clairement
identifiés et stables
 Echecs majeurs sur de gros systèmes
 Délais longs pour voir quelque chose
 Test de l’application globale
 Difficulté de définir tous les besoins au début du
projet
 Ne permet pas de mener, en parallèle, le
développement de plusieurs modules 20
Modèle en cascade

 Les développements de ce modèle font paraître

la validation & vérification à l’issue de chaque
étape :
 Faisabilité et analyse des besoins  validation
 Conception  vérification
 Codage  Test unitaire
 Intégration  test d'intégration et test
d'acceptation
 Installation  test du système
21
 Validation & vérification (V&V)

 Lavalidation consiste essentiellement en des

revues et inspections de spécifications ou de
manuels et du prototypage rapide.

 Question posée : A-t-on décrit le « bon »

système qui répond aux attentes des
utilisateurs et aux contraintes de leur
environnement ?

22
 Validation & vérification (V&V)

 Lavérification consiste à s'assurer que les

descriptions successives et le logiciel lui-même
satisfont la spécification globale. Elle inclut des
inspection de spécifications et de programmes
ainsi que de la preuve et du test.
 Question posée : Le développement est-il
correct par rapport à la spécification de départ?
Le produit respecte-t-il son cahier des charges?

23
 Modèle en V

Analyse des besoins Installation et

et faisabilité test système

Spécification Test d’acceptation

Conception Intégration et test

architecturale d’intégration

Conception Test
détaillée unitaire

Programmation
24
Modèle en V

 Principe de ce modèle :
 Avec toute décomposition doit être décrite la
recomposition
 Toute description d'un composant est
accompagnée de tests pour s'assurer qu'il
correspond à sa description.
 Préparation des dernières phases (V&V) par les
premières (construction du logiciel)
 On distingue deux sortes de dépendances :
 Enchaînement et itération
 Préparation des phases ultérieures

25
Modèle en V

 Conséquences :

 Obligation de concevoir les jeux de test et leurs

résultats

 Réflexion et retour sur la description en cours

 Meilleure préparation de la branche droite du V

26
Modèle en V

 Conception et développement modulaire

 Convient aux systèmes complexes
 Produit de bonne qualité
 Permet d’identifier et d’anticiper les éventuelles
évolutions des besoins

 Couteux en terme de temps

27
Modèle en spirale

28
Modèle en spirale

 Proposé par B. Boehm en 1988

 Modèle beaucoup plus général que celui en V

 Il met l'accent sur l'activité d'analyse des risques

 Chaque cycle de la spirale se déroule en quatre
phases :
1. Détermination des objectifs du cycle, des alternatives et
des contraintes
2. Analyse des risques, évaluation des alternatives et
maquettage
3. Développement et vérification de la solution retenue
4. Revue des résultats et vérification du cycle suivant
29
Modèle en spirale

 L'analyse préliminaire est affinée au cours des

premiers cycles
 Le modèle utilise des maquettes exploratoires pour
guider la phase de conception du cycle suivant
 Le dernier cycle se termine par un processus de
développement classique
 Ce modèle a été moins expérimenté que les
précédents, sa mise en ouvre demande de grandes
compétences et devrait être limitée aux projets
innovants à cause de l'importance qu'il accorde à
l'analyse des risques
30
Modèle en spirale - Risques majeurs

 Défaillance de personnel
 Calendrier et budget irréalistes
 Volatilité des besoins
 Développement de fonctions inappropriées
 Développement d’interfaces utilisateurs
inappropriées
 Changement de technologie en cours de route
 Problèmes de performances
 Exigences démesurées par rapport à la technologie
 Incompréhension des fondements de la technologie
 … etc.
31
Modèle en spirale

 Intégration au niveau de la phase 4 «

Planification »  peut être un modèle de gestion
 Elimination de l’ambiguïté le long du cycle de vie
 C’est un méta modèle puisqu’il permet
d’intégrer d’autres modèles
 Evaluation et maitrise des risques

 Le nombre de cycle de la spirale peut

augmenter et par conséquent le coût du projet

32
Modèles par incréments

33
Modèles par incréments

 Dans les modèles précédents, un logiciel est

décomposé en composants développés
séparément et intégrés à la fin du processus

 Dans les modèles par incréments, un seul

ensemble de composants est développé à la fois,
des incréments viennent s'intégrer à un noyau
de logiciel développé au préalable

 Chaque incrément est développé selon l'un des

modèles précédents
34
Modèles par incréments

 Chaque développement est moins complexe

 Les intégrations sont progressives
 Possibilité de livraisons après chaque incrément

Risques :
 Cas de remise en cause du noyau ou des
incréments précédents
 Ne pas pouvoir intégrer de nouveaux
incréments

35
Processus unifié – UP

Caractéristiques

Itératif et Piloté par

incrémental les risques

Conduit par les Centré sur

besoins (CU) l’architecture
36
Processus unifié – UP

Itérations et risque
 Une itération est un mini-projet, comporte toutes
les activités, terminée par un point de contrôle,
conduit à une version montrable implémentant un
certain nombre de CU, dure entre quelques
semaines et 9 mois
 On ordonne les itérations à partir des priorités
établies pour les CU et de l’étude du risque
 plan des itérations
 chaque prototype réduit une part du risque et est évalué
comme tel
 les priorités et l’ordonnancement de construction des
prototypes peuvent changer avec le déroulement du plan
37
Processus unifié – UP

38
Processus unifié – UP

Avantages d’un processus itératif et

incrémental
 Gestion de la complexité
 Maîtrise précoce des risques élevés
 Intégration continue
 Prise en compte des modifications de besoins
 Apprentissage rapide de la méthode
 Adaptation de la méthode
 Mais gestion de projet plus complexe :
planification adaptative
39
Processus unifié – UP

Conduit par les besoins

 Objectif du processus : construction d’un système qui
réponde à des besoins
 Cas d’utilisation
 expression / spécification des besoins : que fait le
système, pour qui, dans quel environnement ?
 utilisation tout au long du cycle

 validation des besoins / utilisateurs

 point de départ pour l’analyse (découverte des
objets, de leurs relations, de leur comportement) et
la conception (sous-systèmes)
 guide pour la construction des interfaces

 guide pour la mise au point des plans de tests 40

Processus unifié – UP

Piloté par les risques

 Nature des risques : besoins / technique / autres
 Exemples
 le système construit n’est pas le bon
 architecture inadaptée, utilisation de technologies mal
maîtrisées, performances insuffisantes
 personnel insuffisant, problèmes commerciaux ou
financiers (risques non techniques, mais bien réels)
 Gestion des risques
 identifier et classer les risques par importance
 agir pour diminuer les risques (Ex. changer les besoins,
faire des test pour vérifier leur présence et les éliminer)
 s’ils sont inévitables, les évaluer rapidement 41
Processus unifié – UP

Centré sur l’architecture

Définitions :
 « Software architecture is not only concerned with
structure and behaviour, but also with usage,
functionality, performance, resilience, reuse,
comprehensibility, economic and technologic
constraints and tradeoffs, and esthetics.» (RUP, 98)
 « A Technical Architecture is the minimal set of rules
governing the arrangement, interaction, and
interdependence of the parts or elements that
together may be used to form an information
system.» (US Army, 96) 42
Processus unifié – UP

Centré sur l’architecture

 Art d’assembler des composants en respectant des
contraintes, ensemble des décisions significatives sur
 l’organisation du système
 les éléments qui structurent le système
 la composition des sous-systèmes en systèmes
 le
style architectural guidant l’organisation
(couches…)
 Ensemble des éléments de modélisation les plus
signifiants qui constituent les fondations du système
à développer
43
Processus unifié – UP

Centré sur l’architecture

 Architectures client/serveurs en niveaux (appelés
tiers)
 Architectures en couches : Présentation, Application,
Domaine/métier, Infrastructure métier, Services
techniques, Fondation
 Architectures en zones de déploiement : déploiement
des fonctions sur les postes de travail des utilisateurs
 Architectures à base de composants

 Architecture logicielle (ou architecture logique) :

organisation à grande échelle des classes logicielles en
packages, sous-systèmes et couches
 Notion de patterns architecturaux (Couches, MVC,…) 44
Processus unifié – UP

45
Processus unifié – UP

4 Phases
1. Initialisation (Inception)
 Définir la vision du projet, sa portée, sa faisabilité 
Poursuite ou arrêt.
2. Elaboration : 3 objectifs
 Identifier et décrire la majeure partie des besoins utilisateurs
 Construire l’architecture de base du système
 Lever les risques majeurs du projet
3. Construction
 Concevoir et implémenter l’ensemble des éléments
opérationnels  Ressources et effort
4. Transition
 Faire passer l’application des développeurs aux users finaux
(formation, déploiement, béta-tests) 46
Processus unifié – UP

Phases

 Chaque phase est décomposée séquentiellement en

itérations limitées dans le temps (entre 2 et 4
semaines)

 Le résultat de chacune d’elles est un système testé,

intégré et exécutable.

 Activités de développement : Capture des

exigences, analyse, conception, implémentation, test,
déploiement.
47
Processus unifié – 2TUP

Déclinaison du Processus Unifié

 Proposé par Valtech (consulting), présenté dans
Pascal Roques, Franck Vallée (2004) UML2 en action
(3ème édition), Eyrolles
 Objectif : prendre en compte les contraintes de
changement continuel imposées aux systèmes
d’information des organisations
 Création d’un nouveau SI : deux sortes de risques
 imprécision fonctionnelle : inadéquation aux besoins
 incapacité à intégrer les technologies : inadaptation
technique
 Evolution du SI : deux sortes (fonctionnelle,
technique) 48
Processus unifié – 2TUP

49
Méthodes Agile – Evolution

 « Code and fix » : marche bien sur les petits projets,

suicidaire ensuite
 Méthodes, processus, contrats : rationalisation à tous
les étages  Problèmes et échecs (trop de choses
sont faites qui ne sont pas directement liées au
produit logiciel à construire, planification trop rigide)
 Agile : trouver un compromis : le minimum de
méthode permettant de mener à bien les projets en
restant agile (capacité de réponse rapide et souple au
changement, orientation vers le code plutôt que la
documentation) 50
Méthodes Agile

 Augmenter le niveau de satisfaction du client

 Inclure le client dans le cycle de vie du produit
 Rendre le travail du développement plus simple
 Simplifier les phases afin d’en raccourcir la durée
 Communauté de projet : développeurs et
utilisateurs, présents en permanence
 Grande réactivité face aux problèmes et aux
modifications qui arrivent au cours du développement
51
Méthodes Agile

Développement adaptatif

Caractéristiques

Itératif Incrémental

Centré sur l’autonomie des ressources humaines

52
Méthodes Agile – Historique

 Années 90
 réaction contre les grosses méthodes
 priseen compte de facteurs liés au développement
logiciel
 Fin années 90 : méthodes, d’abord des pratiques
liées à des consultants, puis des livres (XP,
Scrum, FDD, Crystal, …)
 2001 : les principaux méthodologues s’accordent
sur le «Agile manifesto»
 Années 2000 : projets Agile mixent des éléments
des principales méthodes 53
Méthodes Agile – Principes

 Méthodes adaptatives (vs. prédictives)

 itérations courtes
 lien fort avec le client
 fixer les délais et les coûts, mais pas la portée
 Insistance sur les hommes
 lesprogrammeurs sont des spécialistes, et pas des
unités interchangeables
 attention à la communication humaine
 équipes auto-organisées
 Processus auto-adaptatif
 révision du processus à chaque itération 54
Méthodes Agile – Caractéristiques

 5-12 personnes
 Regroupés sur un seul site
 A temps plein (semaine de 40h)
 Systèmes interactifs
 Architecture définie
 Criticité faible ou modérée
 Management accommodant
 Nouveau développement
55
Méthodes Agile – Caractéristiques

 Simplicité
 Légèreté
 Orientées participants plutôt que plan
 Nombreuses (XP est la plus connue)
 Pas de définition unique
 Mais un manifeste

56
Méthodes Agile – Comparaison

57
Méthodes Agile – Manifeste

 Février 2001, rencontre et accord sur un manifeste

 Mise en place de la « Agile alliance » pour promouvoir
les principes et méthodes Agile (www.agilealliance.com)
 Les signataires privilégient (les 4 valeurs)
 les individus et les interactions davantage que les
processus et les outils
 les logiciels fonctionnels davantage que l’exhaustivité et
la documentation
 la collaboration avec le client davantage que la
négociation de contrat
 la réponse au changement davantage que l’application
d’un plan 58
Méthodes Agile – Manifeste
(les 12 principes)

1. Notre plus haute priorité est de satisfaire le client en

livrant rapidement et régulièrement des fonctionnalités à
grande valeur ajoutée.
2. Accueillez positivement les changements de besoins,
même tard dans le projet. Les processus Agiles exploitent
le changement pour donner un avantage
compétitif au client.
3. Livrez fréquemment un logiciel opérationnel avec des
cycles de quelques semaines à quelques mois et une
préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs
doivent travailler ensemble quotidiennement tout au long
du projet.
59
Méthodes Agile – Manifeste
(les 12 principes)
5. Réalisez les projets avec des personnes motivées.
Fournissez-leur l’environnement et le soutien dont ils ont
besoin et faites-leur confiance pour atteindre les objectifs
fixés.
6. La méthode la plus simple et la plus efficace
pour transmettre de l’information à l'équipe de
développement et à l’intérieur de celle-ci est le dialogue
en face à face.
7. Un logiciel opérationnel est la principale mesure
d’avancement.
8. Les processus Agiles encouragent un rythme de
développement soutenable. Ensemble, les
commanditaires, les développeurs et les utilisateurs
devraient être capables de maintenir indéfiniment un
rythme constant. 60
Méthodes Agile – Manifeste
(les 12 principes)

9. Une attention continue à l'excellence technique et à une

bonne conception renforce l’Agilité.

10. La simplicité – c’est-à-dire l’art de minimiser la quantité

de travail inutile – est essentielle.

11. Les meilleures architectures, spécifications et conceptions

émergent d'équipes auto-organisées.

12. À intervalles réguliers, l'équipe réfléchit aux moyens de

devenir plus efficace, puis règle et modifie son
comportement en conséquence.
61
Méthodes Agile – Exemples

 RAD (Rapid Application Development), 1991

 DSDM (Dynamic System Development Method),
1995
 Scrum de Ken Schwaber, 1996
 FDD (Feature Driven Development), 1999
 XP (Extreme programming) de Ward Cunningham
et Kent Beck, 1999
 ASD (Adaptive Software Development) de Jim
Highsmith, 2000
 Crystal d’Alistair Cockburn, 2002
 … 62
Méthodes Agile – Exemples

Taille de l’équipe selon la taille du projet

63
Méthodes Agile – Points forts

 Réduction au maximum des écarts entre le

produit développé et les besoins métiers
 Réduction des coûts d’étude qui est réalisée
conjointement avec les développements
 Ecartent la possibilité d’effet tunnel pour les
utilisateurs et la direction qui sont impliqués
dans le projet
 Font naître une grande souplesse et une
réactivité pour les projets courts à forte valeur
ajoutée
64
Méthodes Agile – Limites

 Problème de disponibilité, celle-ci s’avère plus

difficile à obtenir dans les équipes réduites,
notamment pour la rédaction de la
documentation du projet, car tout est fait au fur
et à mesure
 Manque de planification prévisionnelle car le
projet avance à vue
 Besoin de concertation avec les autres projets,
car le fait de mettre des collaborateurs ensemble
ne crée pas toujours une équipe réceptive au
changement
65
Méthodes Agile – XP

Caractéristiques principales
 Le client pilote lui-même le projet, de très près grâce à des
cycles itératifs extrêmement courts (1 ou 2 semaines).
 L’équipe du projet livre très tôt une première version du
logiciel, et les livraisons de nouvelles versions s’enchaînent à
un rythme soutenu pour obtenir un feedback maximal sur
l’avancement des développements.
 L’équipe s’organise elle-même pour atteindre ses objectifs,
en favorisant une collaboration maximale entre ses
membres.
 L’équipe met en place des tests automatiques pour toutes
les fonctionnalités qu’elle développe, ce qui garantit au
produit un niveau de robustesse très élevé.
 Les développeurs améliorent sans cesse la structure interne
du logiciel pour que les évolutions y restent faciles et
66
rapides.
Méthodes Agile – XP

Vue d’ensemble

67
Méthodes Agile – XP

 Le client décide :
 Objectif
 Priorité
 Composition de la version
 Date de livraison de la version
 L’équipe de développement décide :
 Estimations
 Conséquences
 Processus
 Planning détaillé
Méthodes Agile – XP

Recaftoring

 Réécriture, restructuration et simplification

permanente du code – le code doit toujours être
propre.
 Y a-t-il moyen de changer le code pour rendre plus
facile l’ajout de nouvelles fonctionnalités ?

69
Méthodes Agile – XP

Pair Programming (Programmation en binôme)

 Tout le code est écrit par deux programmeurs devant
un ordinateur
 l’un pense à l’implémentation de la méthode
courante,
 l’autre pense stratégiquement à tout le système,
 Les paires échangent les rôles, les participants des
paires changent

70
Méthodes Agile – XP

Rythme durable (alias 40h / semaine)

 Be fresh every morning, tired every night
 Une semaine qui a occasionné des heures
supplémentaires ne doit pas être suivie d’une autre
qui lui ressemble

71
Méthodes Agile – XP

Client sur site

 Répond à toutes les questions maintenant (… et peut
réviser ses réponses après)
 Répondre maintenant est plus important que
répondre correctement

72
Méthodes Agile – XP

Boucles Planning / Feedback

73
Méthodes Agile – XP

Avantages

 Concept intégré et simples

 Pas trop de management
 pas de procédures complexes
 pas de documentation à maintenir
 communication directe
 programmation en binômes (par paires)
 Gestion continuelle du risque
 Estimation permanente des efforts à fournir
 Insistance sur les tests : facilite l’évolution et la
maintenance 74
Méthodes Agile – XP

Inconvénients

 Approprié pour de petites équipes, pas plus de 10

développeurs, ne passe pas à l’échelle (pour des
groupes plus gros, il faut plus de structure et de
documentation)
 Risque d’avoir un code pas assez documenté (des
programmeur qui n’auraient pas fait partie de
l’équipe de développement auront du mal à
reprendre le code)
 Pas de design générique (pas d'anticipation des
développements futurs) 75
Méthodes Agile – Scrum

Caractéristiques principales

 Scrum, emprunté au rugby = mêlée

 Adaptée au développement de systèmes complexes
 Suit un processus itératif, incrémental
 Les livraisons sont cadencées, par itération
 Offre l’agilité nécessaire pour répondre aux
changements rapides des besoins
 Défit ses utilisateurs à se focaliser sur les
améliorations à apporter au système
 Les sprints assurent la réponse aux besoins
76
Méthodes Agile – Scrum

Caractéristiques principales

 Une équipe soudée qui cherche à atteindre un but.

 Objectif : améliorer la productivité des équipes
auparavant ralentie par des méthodes plus lourdes.
 3 rôles principaux : Directeur du produit (Product
owner), Facilitateur (Scrum master) et Equipe
(Team).

77
Scrum – Product Owner (PO)

 Représentant du client et des utilisateurs

 Définit l’ordre de développement des fonctionnalités
 Prend les décisions importantes concernant
l’orientation du projet

78
Scrum – Scrum Master (SM)

 Empêche les éléments perturbateurs extérieurs de

s’installer dans l’équipe
 Assure l’application des valeurs Scrum
 Résout les problèmes non techniques
 Renforce la collaboration entre client et fournisseur

79
Scrum – Team (T)

 Assure le développement et les tests du produit

 Ne comporte pas la notion d’hiérarchie interne,
toutes les décisions sont prises ensemble
 S’adresse directement au PO, il est conseillé qu’elle
lui montre le plus souvent possible le logiciel
développé pour qu’il puisse ajuster les détails
d’ergonomie et d’interface (par exemple)
 L’équipe étendue intègre le PO et le SM  Client et
fournisseur travaillent d’un commun effort vers le
succès du projet
80
Scrum – Stakeholders

 Intervenants ou personnes qui souhaitent avoir une

vue sur le projet sans réellement s’investir dedans.
 Expert technique, agent de direction, …
 Vue éloignée de l’avancement du projet.

81
Scrum – Processus

 Focaliser l’équipe, de façon itérative, sur un

ensemble de fonctionnalités à réaliser, dans des
itérations de durée fixe (1 à 4 semaines)  Sprints
 Sprint Backlog : exigences traitées pendant le sprint
 Product Backlog : toutes les fonctionnalités du
logiciel selon leurs priorités
 Le PO définit le but à atteindre du sprint, duquel on
choisit les fonctionnalités à traiter
 Un sprint aboutit à la livraison d’un produit partiel
fonctionnel
 Le 1er Sprint Planning, le dernier Sprint Review 82
Scrum – Processus

83
Scrum – Processus
Scrum – Processus

85
Daily Standup

• Réunion quotidienne de courte durée 1. Meilleur Focus

• Même lieu 2. Meilleur Alignement
• Même heure 3. Meilleure Collaboration

86
Sprint Review

 S’organise à la fin du Sprint

 Demontre les réalisations du Sprint et les
événements intéressants

Sprint backlog
87
Sprint Retrospective

 Suit le Sprint Review

 L’équipe révise le Sprint pour identifier
 Ce que l’on a appris ?
 Ce qui a bien marché ?
 Ce qui est à améliorer ?

88
Anatomie d’un Sprint

 Sprint Planning (sélectionner les user stories)

 Conception
 Codage / Test
 Intégration

 Sprint Review

 Sprint Retrospective

89