GL - 2

2.2 Processus de dveloppement

Cycles de vie
Lydie du Bousquet
Lydie.du-bousquet@imag.fr

En collaboration avec J.-M. Favre, Ph. Lalanda, I. Parissis,

Y. Ledru

Plan

Introduction
Modles en cascade
Modles volutifs
Modle en spirale
Modles agiles
Synthse
2

Rappel sur les activits

Le dveloppement comprend un ensemble dactivits

La gestion des exigences

La spcification
La conception
Limplantation
La validation
Lintgration
Le dploiement
La maintenance

Lenchanement de ces activits se fait plus ou moins

bien
3

Cycle de vie du logiciel /

Processus de dveloppement

Un processus de dveloppement dfinit un ensemble dactivits

et leur enchanement
Une activit comprend

des tches,
des contraintes,
des ressources,
une faon dtre ralise

La plupart des modles des processus reprennent les activits

fondamentales mais les organisent diffremment

De nombreux modles ont t dfinis

Un modle peut tre spcifique une organisation et un type de
logiciels (ex: embarqu)
Il existe malheureusement peu doutils supportant les processus
4

Plan

Introduction
Modles en cascade
Modles itratifs
Autres modles
Modles agiles
Synthse
5

Modles en cascade

Principes

Considrer le dveloppement logiciel comme

une succession dtapes ralises de faon
strictement squentielle

Chaque tape correspond

une activit de base
Chaque tape est valide
Il ny a pas (ou peu) de retours
en arrire

Modles en cascade

code and fix

on code dabord et on
modifie ensuite

Dveloppement sauvage
Analyse courte et priorit au
codage
Votre dernier TD ?

Modle primitif (< 1970)

Construction
dune v0
Relative Costs of Phases
Integration (8%)
Module testing (7%)
Module coding (5%)

Modifications

Design (6%)

Specification (5%)
Requirements (2%)

Maintenance (67%)

Inadapt aux
dveloppements en quipe ou
de grande taille

Modles en cascade

Waterfall model (1970)

Dfinition dun
ensemble plus large et
plus complet dactivits
Chaque activit est
valide par un
document
Pas (ou peu) de retours
arrire
Inspir des processus
dingnierie
8

Modles en cascade

Waterfall model avec itration

Introduction des retours

en arrire (limit la
phase prcdente)
Plus flexible mais lourd
grer
Nombre ditration
limit

Modles en cascade

Le cycle de vie en V

Structuration de la phase de validation

Les tests sont dfinis lissue de chaque
phase

10

Modles en cascade

Avantages

Simple et facile comprendre

Force la documentation : une phase ne
peut se terminer avant qun document
soit valid
Le test est inhrent chaque phase
Les progrs sont tangibles (pour
lquipe de dveloppement)
11

Modles en cascade

Limites

Modle dirig par les documents

Non comprhensibles par les clients

Le produit final est la premire chose que voit le client

Fait lhypothse de la faisabilit

Est-ce un vraiment problme ?

Ne marche que si les exigences sont stables et le problme

connu

Manque de flexibilit (ne traite pas les volutions,

notamment des exigences)
Problmes dcouverts en phase de validation
Irraliste dans de nombreux cas
12

Modles en cascade

Conclusions

Conditions dutilisation

Seulement quand les exigences sont bien

connues et non sujettes modification

Fonctionnalits / Attentes utilisateurs

Technologies utilises

Encore assez populaires

Simples et similaires au modles utiliss

dans dautres disciplines
Souvent utiliss par les non spcialistes
13

Plan

Introduction
Modles en cascade
Modles incrmentaux
Modle en spirale
Modles agiles
Synthse
14

La nature changeante dun projet

1 : Le changement est invitable

Lenvironnement technique et conomique volue

Les besoins et les souhaits des clients changent
Les priorits du management aussi

les mthodes en cascade ne marchent pas

2 : On ne peut pas attendre de tout savoir pour
commencer

Rduction imprative du time-to-market

Illusion de la perfection

15

Modles incrmentaux

Principes

Diviser le projet en incrments

Un incrment = une sous partie
fonctionnelle cohrente du
produit final
Chaque incrment ajoute de
nouvelles fonctions
Chaque incrment est test
comme un produit final
Les incrments sont dfinis
a priori (classification des
exigences par le client si
possible)

Dfinition des
exigences min
et des incrments
Conception de
larchitecture ou
dun noyau

Dveloppement
dun incrment

Intgration et
validation

Produit final

16

Modle incrmental - 1

Architecture volutive

La premire version constitue le noyau

Les versions suivantes sappuient sur lexistant et
tendent larchitecture
Chaque version donne lieu un cycle de vie
complet

17

Modle incrmental - 2

Architecture stable

La premire version fournit une enveloppe

complte
Chaque nouvelle version fournit un ou plusieurs
sous systme en respectant larchitecture
Le dveloppement en parallle est possible
(surtout pour les incrments)

(Maj YL 2007)

18

Modles incrmentaux

Avantages

Une premire version du systme est fournie

rapidement

ROI rapide (Retour sur investissement)

Rduit le stress du management !
En gnral, cette version nest pas mise en production

Les risques dchec sont diminus

Dcouverte des problmes assez tt

Les parties importantes sont fournies en premier et seront
donc testes plus longuement
Les clients peuvent ajouter des exigences tous moments

(Maj YL 2007)

19

Modles incrmentaux

Limites

Les incrments

Larchitecture

Difficile dfinir : mapper des exigences sur des incrments

est complexe
Trop peu dincrments on se rapproche du modle en
cascade
Trop dincrments ingrable
Difficile de concevoir une architecture stable ds le dbut ou
facilement volutive
Difficile didentifier des services techniques communs

Ne traite pas toutes les volutions, notamment celles

qui remettent en cause larchitecture
20

Autre modle incrmental

Build 1:

Design

Implementation,
integration

Deliver to client

Specifications

Design

Implementation,
integration

Specifications

Design

Specifications

Build 2:

Build 3:

Deliver to client

Implementation,
integration

Deliver to client

specification team

Build n:

Specifications

Design

implementation/integration team

design team

Implementation,
integration

Deliver to client

Plus flexible
Pas de conception globale Pb de rutilisation des incrments
21

Prototypage
Construire un prototype jetable pour mieux
comprendre les points durs (exigences, technologies)
Dfinition
des objectifs

Plan
Plande
de
prototypage
prototypage

Dfinition des
fonctionnalits

Spcification
Spcification
(lgre)
(lgre)

Dveloppement
du prototype

Prototype
Prototype

valuation
du prototype

Rapport
Rapport
dvaluation
dvaluation
22

Proprits du prototypage

Avantages

Permet dimpliquer lutilisateur et dclaircir les zones

troubles
Permet d valuer des risques et de tester une solution
Utile dans tous les cycles de vie
Il existe des outils de maquettage/prototypage

Limites

Le client doit comprendre ce qui est propre au prototype

Cot mal compris par les managers et les clients
Tentation de construire partir du prototype et donc
dutiliser des solutions non optimales
Naborde quune phase du dveloppement
(Maj YL 2007)

23

Plan

Introduction
Modles en cascade
Modles volutifs
Modle en spirale
Modles agiles
Synthse
24

Modle en spirale (Boehm, 1988)

Le cycle de vie est reprsent laide dune spirale

Chaque boucle reprsente une phase du dveloppement

La boucle la plus interne traite des premires phases
(faisabilit). La plus externe traite de la livraison
Chaque boucle traverse quatre sections :

Dfinition des objectifs de la phase (la boucle)

Evaluation des risques et plan de gestion
Dveloppement et validation
Planification de la phase suivante

Nombre de cycles variable

25

Modle en spirale : schma

26

Principe du modle en spirale

Reconnaissance explicite de la notion de risque

Exemples

dfaillance de personnel
calendrier et budgets irralistes
dveloppement de fonctionnalits inappropries
dveloppement dinterfaces utilisateurs inappropries
produit plaqu or (non rentable)
volatilit des besoins
problme de performances
exigences dmesures par rapport la technologie
tches ou composants externes dfaillants
27

Attention

Le modle en spirale est en fait un mtamodle

Il offre un cadre o chaque boucle doit tre
instancie
On peut par exemple crer

Une boucle de faisabilit

Une boucle de prototypage
Des boucles de dveloppement itratif, etc.

Il faut alors trouver le bon modle de

processus pour chaque boucle !
28

Exemple

Rapide cahier des charges

Un logiciel pour grer les emprunts de documents dans une

nouvelle bibliothque trs moderne qui possdera des
ouvrages de toutes natures (dont multimdia)
Le logiciel devra permettre la visualisation, lemprunt, le
tlchargement et la rservation des ouvrages.
Le logiciel devra utiliser les dernires avances des NTICs
(Nouvelles Technologies de lInformation et de la
Communication)
Les futurs utilisateurs sont trs motivs mais ne savent pas
exactement quoi sattendre (ils ne connaissent pas les
NTICs)

29

Problmes

Difficults lies ce projet

Cest un produit nouveau

On ne peut pas se baser sur un produit existant

Nouveaux types de documents
Nouveaux types de consultation
(tlchargement)

Utilisation de technologies nouvelles est

immatures
Besoins client affiner
30

Approche retenue

Approche itrative avec 5 incrments

(ou boucles)

Incrment 1 : tude de faisabilit

Incrment 2 : prototypage
Incrment 3 : fonctions de visualisation
Incrment 4 : fonctions demprunt et de
tlchargement
Incrment 5 : fonctions de rservation
31

Premier incrment

Objectifs

Identification des risques

tude de faisabilit
Focalisation sur la technologie ce nest pas un prototype
Trouver les alternatives technologiques si problme
Connaissances techno. insuffisantes formations
immdiates

Planification et ralisation

1 mois de travail + 1 semaine de formation

2 personnes (rpartition des points travailler)

32

Second incrment

Objectifs

Identification des risques

Construction dun prototype

Proposer des IHMs innovantes
Connaissances mtier insuffisantes planification
de runions

Planification et ralisation

2 mois de travail
4 personnes
33

Troisime incrment

Objectifs

Identification des risques

Dfinition dune architecture stable

dintgration
Raliser la fonction de visualisation
Accs la base de donnes des documents
duplication dune partie de la base

Planification et ralisation

6 mois de travail
6 personnes

Browser
1..100

Serveur
dapplications
1
1..*

Serveur
de donnes
34

Quatrime incrment

Objectifs

Identification des risques

Reprendre (et mettre jour) larchitecture existante

Raliser les fonctions demprunt et de tlchargement
Problme de scurit contacter des experts et affiner les
besoins

Planification et ralisation

9 mois de travail
6 personnes

Client Riche
1..100

Serveur
dapplications
1
1..*

Serveur
de donnes35

Cinquime incrment

Objectifs

Identification des risques

Reprendre (et mettre jour) larchitecture existante

Raliser la fonction de rservation
Crainte de retard ngociation avec les clients pour
identifier le meilleur palliatif
Performance adaptation de larchitecture

Planification et ralisation

6 mois de travail
6 personnes

Client Riche
1..30

Serveur
dapplications
1
1..*

Serveur 36
de donnes

Plan

Introduction
Modles en cascade
Modles volutifs
Modle en spirale
Modles agiles
Synthse
37

Les cycles de vie prsents

jusquici

Une approche trs contrle du dveloppement

Planification prcise
Assurance qualit
Mthodes danalyse et de conception
Utilisation doutils (CASE)

Conditions optimales dutilisation

Projets critiques de grande taille

Longue dure de dveloppement et dutilisation
quipes de dveloppement disperses
Apport de plusieurs socits

(Maj YL 2007)

38

Remarque
En suivant ces cycles de vie, on peut
passer plus de temps sur la faon de
dvelopper un systme que sur le
dveloppement lui mme.

(Maj YL 2007)

39

Les mthodes agiles

Ces mthodes

Se focalisent sur le dveloppement

(les ingnieurs aiment programmer)
Sont bases sur une approche itrative
Visent fournir rapidement un logiciel excutable que les
clients peuvent amender

Ces mthodes ont t conues pour le

dveloppement dapplications dont les exigences
changent

Extreme programming (Beck)

Crystal (Cockburn)
Adaptive software development (Highsmith)
Feature driven development (Palmer)
(Maj YL 2007)

40

Principes des mthodes agiles

Utilisateur
Incrments
People
Changements
Simplicit
Tests
Binmes

implication dans le dveloppement

fourniture des exigences et prioritisation
valuation des itrations
fourniture incrmentale du logiciel
reconnaissance du talent des
dveloppeurs
pas de processus impos
conception oriente volution
Chasser toute forme de complexit
jouent le rle de spcification
les dveloppeurs travaillent par
binmes

(Maj YL 2007)

41

Extreme programming (XP)

Une approche base sur des itrations frquentes

Slection des scnarios raliser (sous forme de cartes)

Dfinition et rpartition des tches
Planification du dveloppement et des tests
Fourniture dun logiciel excutable et valuation

Slection des
scnarios

valuation du
systme

Cration de
tches

Fourniture de
lincrment

Planification
de lincrment

Dveloppement
intgration/test
42

XP : principes

Ralisation dun incrment

Runion debout tous les matins (tous)

Programmation deux dans une war room
La war room se trouve de prfrence chez le client
Les programmeurs dfinissent et excutent les tests
Conception minimale
Constante adaptation du code pour simplifier
Intgration continuelle
Cadence intense

43

Salle de lquipe ( war room )

44

Gestion des cartes (scnarios)

Scnarios cods

Scnarios
planifis

Scnarios non
planifis

45

Scnarios courants (1 ou 2 semaines)

Liste des bugs

Scnarios dtaills

46

Runion de fin ditration

47

 War rooms : autres exemple

48

Programmation deux

De nombreux avantages

egoless programming : le code est tout le

monde
Rotation des binmes et diffusion de la
connaissance dans le projet
Revue constante du code

Favorise la re-factorisation du code

efficace et moins coteuse que les inspections formelles

vers la simplicit

Aussi productif que deux programmeurs

indpendants
49

La vrification dans XP

Beaucoup de tests mais les approches itratives

traitent souvent mal le test
(pas de spcifications sur lesquelles se baser)
Gestion des tests dans XP :

Dfinition des tests en premier

Chaque tche donne lieu des tests

Dfinis avant limplantation avec le client

Ecriture de tests qui seront excuts automatiquement

Cods avant lapplicatif

50

Difficults des mthodes agiles

Aucune documentation nest disponible pour la

maintenance
Ces mthodes sont parfois difficiles mettre en place

Le client nest pas toujours daccord pour participer au

dveloppement
Elles demandent une implication intense des dveloppeurs
Laffectation de priorits est souvent complexes (surtout
quand il y plusieurs clients)
Maintenir la simplicit demande du travail additionnel

51

Plan

Introduction
Modles en cascade
Modles volutifs
Autres modles
Modles agiles
Synthse
52

Synthse

Un cycle de vie apporte stabilit, contrle et

organisation une activit qui peut vite
devenir chaotique

meilleure
meilleure
meilleure
meilleure

estimation des cots et besoins

coordination
productivit
visibilit et comprhension

Adopter et appliquer un cycle de vie est un

signe de maturit pour une entreprise
(Maj YL 2007)

53

A retenir

Les managers adorent les modles de cycles de vie

Les modles dfinissent les activits et les livrables

Quelle satisfaction de pouvoir dire la direction que la
phase x est termine
rendus obligatoires par de nombreux clients

Les ingnieurs ne les aiment pas trop

Ne reprsentent pas ce qui se passe dans les tranches

Ne rglent jamais compltement le problme des volutions
( les clients ne peuvent jamais donner leurs besoins ds le
dbut )
Les phases sont toujours mles

54

Lequel choisir ?

Pas de modle idal

Pour les projets de taille petite ou moyenne

(< 500 000 l)

Cascade : risqu pour les projets innovants

volutif : coteux pour les projets clairs ds le dbut

Une approche incrmentale est souvent plus approprie

Pour les grands projets (multi-sites, multi-quipes)

Approche mixte intgrant des aspects des modles volutifs

et des modles en cascade

Exemple : utilisation dun prototype pour stabiliser les

exigences et dveloppement en V

(Maj YL 2007)

55

En gnral : imbriqu et itratif

Gestion des exigences

Conception

Implantation

56

Suggestions de lecture

A Spiral Model of Software Development and Enhancement

Barry W. Boehm Computer 21(5), 1988
Software Development Process: A Necessary Evil
Mohamed E. Fayad,
Communications of the ACM 40(9), 1997
The agile methods fray
Tom De Marco and Barry W. Boehm
IEEE computer 35(6), 2002
http://www.extremeprogramming.org

57