Chapitre 3: Démarches de

développement et cycle de
vie d’un projet informatique
Pour essayer d’éviter ceci :

2
Les étapes du cycle de vie

3
 Deux grandes approches
◼ Méthodes prédictives (GL traditionnel)
❑ Le logiciel est figé : on planifie au début du projet
◼ Méthodes adaptatives (agiles)
❑ Intègrent le changement
❑ La planification est réévaluée au cours du développement

4
Cycle de vie : les étapes du logiciel
Analyse Compréhension du problème et des besoins
(spécification des besoins)
Description de ce que le système doit faire
: Le que faire
conception préliminaire
(spécifications)
Le comment faire : algorithmes...
conception détaillée
Développement des sources et tests des portions
Codage et tests unitaires
Assemblage planifié des portions,
conformité par rapport aux besoins
Intégration et validation
Vérification de réponse aux
Recette spécifications, performances…

Exploitation Utilisation du logiciel,

et maintenance maintenance corrective et évolutive
5
 Cycle de vie en cascade
Analyse

conception

Codage

Tests

Chaque étape validée n'est plus remise en cause

Ne prend pas en compte l'intégralité du cycle de vie

6
Modèle en V
Spécification du système Modèle utilisateur Livraison du système
et des besoins

Conception Test du système

du système Modèle architectural

Spécification Test des sous-systèmes

des sous-systèmes

Conception Test des modules

des modules

Construction
Modèle d'implantation
7
Modèle itératif
◼ Développement logiciel : processus graduel d’élimination des
risques
◼ Chaque nouvel incrément :
❑ a pour objectif la maîtrise d'une partie des risques
❑ apporte une preuve tangible de faisabilité ou d'adéquation

A chaque itération :
1. Spécification
2. Conception
3. Implémentation
4. Tests

8
Prototypage, RAD (Rapid Application Development)

◼ Discuter et interagir avec l’utilisateur

◼ Basé sur les maquettes / prototypes
❑ Vérifier l’efficacité réelle d’un algorithme
❑ Utiliser pour identifier les besoins (prototype jetable)
❑ Implémenté par des générateurs de code (prototype évolutif)

∞ Mais :
− Prototyper n’est pas spécifier
− Les décisions rapides sont rarement de bonnes décisions
− Le prototype évolutif donne-t-il le produit demandé ?
− Les générateurs de code produisent-ils du code assez efficace ?

→ Projets petits ou à courte durée de vie

9
 Modèle incrémental
Combine des éléments des modèles linéaires et du prototypage

utilisé quand il n’y a pas assez de ressources

disponibles pour une livraison à temps

Produit opérationnel :
incréments livrables
→Le premier incrément est
souvent le noyau
→ Les incréments aident à
gérer les risques techniques
(matériel non disponible)

10
Méthode du processus unifié (UP)

◼ Méthode générique de développement

❑ Cycle de vie itératif et incrémental
❑ Gère les demandes de changement (objectifs restreints à court terme)
❑ Gère les exigences du client (dialogues entre intervenants)
❑ Les risques majeurs sont traités en priorité

Le processus unifié est un ensemble structuré de « bonnes

pratiques » issues de l’expérience

∞ Cycle de vie décomposé suivant 2 axes :

− Horizontal : temps, aspect dynamique
− Vertical : aspect statique, disciplines / activités

11
Rational Unified Process (RUP)
définition planification des activités, développement recettage et
du problème affectation des ressources, analyse du logiciel déploiement

12
Méthode du processus unifié (UP et RUP)

◼ Piloté par les cas d’utilisation (s’appuie sur UML)

❑ Ils servent d’outils de spécification des besoins
❑ Chaque itération prend en compte un certain nombre de cas d'utilisation

∞ Avantages :
− Souci permanent de la qualité
− Gestion des risques permanente
− Gestion des demandes de changement

∞ Inconvénients :
− Coûteux à personnaliser
− Très axé processus au détriment du développement

13
Problèmes liés au développement de logiciels

◼ 3 facteurs liés à l’échec d’un logiciel :

❑ Le planning n’est pas maîtrisé
❑ Les besoins sont mal identifiés (mal compris)
❑ Des erreurs surviennent lors de la livraison du logiciel (bugs)

∞ Méthodes traditionnelles :

14
Exercice 1

15
Exercice 2

16
Réponse

◼ Un cycle de vie décomposé en plusieurs phases permet

d’avoir une meilleure visibilité du projet.
◼ Les différentes phases peuvent server de jalons dans sa
conduite. Plus les phases seront détaillées, plus
l’avancement du projet pourra etre mesuré précisément.
◼ Il faut qu’un Jalon soit lié au progrès du développement
du logiciel et il doit etre facile de determiner s’il a été
attaint ou non.

17
Réponse

18
 La philosophie AGILE

◼ Motivations principales :
❑ changements imprévisibles et rapides (besoins,
technologies, …)
❑ mal gérés par les méthodes « traditionnelles »
∞ Valeurs essentielles :
− Individus et interactions vs processus et outils
− Logiciel qui marche vs documentation exhaustive
− Collaboration avec le client vs négociation de contrat
− Réponse aux besoins vs respect des plans

19
Méthodes agiles : différentes méthodes
XP (eXtreme Programming)
ASD (Adaptative Software Development)
FDD (Feature Driven Development),
DSDM (Dynamic Systems Development Method)
AM (Agile Modeling),
→ Méthodes regroupées par l’Agile Alliance

20
 Méthodes agiles en pratique

◼ Concepts de base :
❑ Le code marche constamment (documentation
compréhensible)
❑ Travail de groupe avec forte communication
❑ Réponse au changement (nouvelles fonctionnalités
...)

∞ En pratique :
− Itérations très courtes (10 j à 1 mois) avec résultat
opérationnel
• Corriger au plus tôt les erreurs commises → retards limités

21
 Méthodes agiles en pratique (2)

❑ Planification des fonctions du logiciel (et non de tâches)

◼ Recentrer le travail sur la conception de l’application
◼ Se focaliser sur l’objectif à atteindre

❑ Evaluation dynamique de la priorité (à chaque itération)

❑ Retour d’information constant (revues en fin d’itération)
❑ Interactions intenses dans l’équipe (qui inclut le client)

22
◼ Les méthodes de développement dites
« méthodes agiles » visent à réduire le cycle
de vie du logiciel (donc accélérer son
développement) en développant une version
minimale, puis en intégrant les fonctionnalités
par un processus itératif basé sur une écoute
client et des tests tout au long du cycle de
développement.

23
Méthodes agiles
◼ L'origine des méthodes agiles est liée à
l'instabilité de l'environnement technologique et
au fait que le client est souvent dans l'incapacité
de définir ses besoins de manière exhaustive dès
le début du projet.
◼ Le terme « agile » fait ainsi référence à la capacité
d'adaptation aux changements de contexte et aux
modifications de spécifications intervenant
pendant le processus de développement.

24
Méthodes agiles
Grâce aux méthodes agiles, le client est
pilote à part entière de son projet et obtient
très vite une première mise en production de
son logiciel. Ainsi, il est possible d'associer
les utilisateurs dès le début du projet.

25
Définition de Scrum

•Scrum est un processus agile qui permet de produire

un logiciel dans la durée la plus courte.
•Le logiciel qui fonctionne est produit à chaque sprint
(toutes les 2 à 4 semaines).
•Le métier définit les priorités. L'équipe s'organise pour
déterminer la meilleure façon de produire les
exigences les plus prioritaires.
•A chaque fin de sprint, tout le monde peut voir
fonctionner le produit courant et décider soit de le
livrer, soit de continuer à l'améliorer pendant un sprint
supplémentaire.

26
Utilisateurs de Scrum
•Microsoft •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts •BMC Software
•High Moon Studios •Ipswitch
•Lockheed Martin •John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •Salesforce.com
•Capital One •Time Warner
•BBC •Turner Broadcasting
•Oce

27
Caractéristiques de Scrum

• Scrum est emprunté du Rugby (signifie mêlée). Ce

processus s'articule en effet autour d'une équipe soudée,
qui cherche à atteindre un but (comme c'est le cas en
rugby pour avancer avec le ballon pendant une mêlée).

• Equipe responsable, en auto-organisation

• Avancement du produit par une série de « sprints »

• Exigences définies comme des éléments d’une liste

appelée « backlog de produit »

28
Sprints
• Les projets Scrum progressent par une série
de sprints
• La durée d’un sprint est de 2 à 4 semaines
• Une durée constante apporte un meilleur
rythme
• Le produit (partiel) est conçu, codé et testé
pendant le sprint

29
Les étapes

Exigences Conception Code Test

Plutôt que de faire toute

une discipline d'un coup...
...Les équipes Scrum font un
peu de tout tout le temps

30
 Le cadre Scrum
Rôles
•Product Owner
•ScrumMaster
•Equipe
(développpeur, …)

Cérémonies
•Planification du sprint
•Revue du sprint
•Rétrospective
•Scrum quotidien

31
32
Le cadre Scrum

Rôles
•Product Owner
•ScrumMaster
•Equipe (développpeur, …)

33
Product Owner
Propriétaire du produit
• Est le représentant des clients et des
utilisateurs
• Définit les fonctionnalités du produit
• Choisit la date et le contenu du prototype
• Définit les priorités dans le backlog en
fonction de la valeur « métier »
• Ajuste les fonctionnalités et les priorités à
chaque sprint si nécessaire
• Accepte ou rejette les résultats

34
ScrumMaster
• Il est responsable de la méthode (le
management du projet)
• Responsable de faire appliquer par
l’équipe les valeurs et les pratiques de
Scrum
• Élimine les obstacles
• S'assure que l'équipe est complètement
fonctionnelle et productive
• Facilite une coopération poussée entre
tous les rôles et fonctions
• Protège l'équipe des perturbations
extérieures
35
Développeurs

• De 5 à 10 personnes
• Regroupant tous les rôles
• Architecte, concepteur, développeur, spécialiste IHM, testeur,
etc.
◼ Travaille à plein temps sur le projet, de
préférence
• L’équipe s’organise par elle-même
• La composition de l’équipe ne doit pas
changer pendant un Sprint

36
Le cadre Scrum

Cérémonial/Events
•Planification du sprint
•Revue du sprint
•Rétrospective
•Scrum quotidien

37
 Planification du sprint
Périmètre
• Analyser et évaluer le backlog de But du
produit sprint
• Définir le but du sprint

Plan
• Décider comment s'y prendre
(conception)
• Créer la liste des tâches à partir Liste des
des éléments du backlog de tâches
produit
• Estimer les tâches en heures

38
Backlog : Liste des fonctionnalités qui devront être mises en œuvre par le logiciel.
 Revue de sprint
• À la fin du sprint, tout le monde se réunit pour
effectuer la revue de sprint,
• Dure au maximum 4 heures.
• L'objectif est de valider le logiciel qui a été produit
pendant le sprint.
• L'équipe commence par énoncer les fonctionnalités
réalisées.
• Elle effectue ensuite une démonstration du logiciel
produit.
À la fin du sprint, tout le monde se réunit pour effectuer la revue de sprint, qui dure au

• Sur la base de cette démonstration, le directeur de

maximum 4 heures. L'objectif de la revue de sprint est de valider le logiciel qui a été produit
pendant le sprint. L'équipe commence par énoncer les items du carnet de produit qu'elle a
réalisés. Elle effectue ensuite une démonstration du logiciel produit. C'est sur la base de cette
produit valide chaque fonctionnalité planifiée pour
démonstration que le directeur de produit valide chaque fonctionnalité planifiée pour ce sprint.

ce sprint.

39
 Retrospective du sprint sprint

• La rétrospective du sprint est faite en interne à l'équipe

(incluant le Scrum Master), à la fin d’un sprint.

• Elle dure 3 heures pour un sprint d'un mois.

• L'objectif est de comprendre ce qui n'a pas bien marché

dans le sprint, les erreurs commises et de prendre des
décisions pour s'améliorer.
À la fin du sprint, tout le monde se réunit pour effectuer la revue de sprint, qui dure au
maximum 4 heures. L'objectif de la revue de sprint est de valider le logiciel qui a été produit
pendant le sprint. L'équipe commence par énoncer les items du carnet de produit qu'elle a
réalisés. Elle effectue ensuite une démonstration du logiciel produit. C'est sur la base de cette
démonstration que le directeur de produit valide chaque fonctionnalité planifiée pour ce sprint.

40
 Scrum quotidien
• Au quotidien, une réunion, (Daily Scrum), permet
aux développeurs de faire un point de coordination
sur les tâches en cours et sur les difficultés
rencontrées :
• Tous les jours
• 15 minutes
• Debout
• Pas fait pour résoudre les problèmes
• Tout le monde est invité
• Seuls les membres de l'équipe peuvent parler
41
Chacun répond à 3 questions
1
Qu’est ce que tu as fait hier ?

2
Que vas-tu faire aujourd'hui ?

3
Y a t-il un obstacle qui te freine ?

42
Scrum – Organisation 1/5

Source : www.scrumalliance.org

1. Backlog produit (ou catalogue des besoins)

◼ Besoins priorisés par le product owner
◼ Besoins évalués par l’équipe 43
Scrum – Organisation 2/5

Source : www.scrumalliance.org

2. Backlog de sprint
◼ Extrait du backlog produit

◼ Besoins éclatés en tâches

44
Scrum – Organisation 3/5

Source : www.scrumalliance.org

3. Sprint
◼ Développement des fonctionnalités du backlog de sprint

◼ Aucune modification du backlog de sprint possible

45
Scrum – Organisation 4/5

Source : www.scrumalliance.org

4. Mêlée quotidienne
◼ Point de contrôle quotidien de l’équipe

◼ Interventions régulées – 2 min. par personne

46
Scrum – Organisation 5/5

Source : www.scrumalliance.org

5. Incrément logiciel : livré au product owner à la

fin du sprint.
47
 Scrum – Indicateurs de projet 1/2

◼ Le tableau des tâches

Source : « Scrum and XP from the trenches » de H. Kniberg, 2007

48
 Scrum

Documentation : Uniquement celle qui est utile

• diagramme métier (diagramme d’activités, CU)
• diagramme de séquence : uniquement si la
fonctionnalité aura une utilisation complexe
• diagramme d'architecture du logiciel : (classes,
modules, composants, etc.), pour le projet :
indispensable pour avoir toujours sous les yeux une vue
de l'architecture et s'assurer ainsi qu'elle est de qualité ;
• les manuels utilisateur : les manuels sont produits à
chaque sprint et pas en fin du projet.

49