1GL - 22.2 Processus de dveloppement

Cycles de vie

Lydie du BousquetLydie.du-bousquet@imag.fr

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

2Plan

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

3Rappel 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

4Cycle 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

5Plan

Introduction Modles en cascade Modles itratifs Autres modles Modles agiles Synthse

6Modles 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

7Modles 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) Inadapt aux

dveloppements en quipe ou de grande taille

Relative Costs of Phases

Maintenance (67%)Requirements (2%)Specification (5%)

Design (6%)

Module coding (5%)

Module testing (7%)Integration (8%)

Construction dune v0

Modifications

8Modles 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 retoursarrire

Inspir des processus dingnierie

9Modles en cascade

Waterfall model avec itration

Introduction des retours en arrire (limit la phase prcdente)

Plus flexible mais lourd grer

Nombre ditration limit

10

Modles en cascade

Le cycle de vie en V

Structuration de la phase de validation Les tests sont dfinis lissue de chaque

phase

11

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)

12

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

Est-ce un vraiment problme ?

Fait lhypothse de la faisabilit 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

13

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

14

Plan

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

15

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

16

Dfinition desexigences minet des incrments

Conception delarchitecture ou dun noyau

Dveloppementdun incrment

Intgration et validation

Produit final

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 testcomme un produit final

Les incrments sont dfinisa priori (classification des exigences par le client sipossible)

17

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

18

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)

19

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)

20

Modles incrmentaux

Limites Les incrments

Difficile dfinir : mapper des exigences sur des incrments est complexe

Trop peu dincrments on se rapproche du modle en cascade

Trop dincrments ingrable Larchitecture

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

21

Implementation, integration Deliver to clientDesignSpecifications

Build 1:

Implementation, integration Deliver to clientDesignSpecificationsBuild 2:

Implementation, integration Deliver to clientDesignSpecificationsBuild 3:

specification team

design team

implementation/integration team

Implementation, integration Deliver to clientDesignSpecificationsBuild n:

Plus flexiblePas de conception globale Pb de rutilisation des incrments

Autre modle incrmental

22

Prototypage

Construire un prototype jetable pour mieux comprendre les points durs (exigences, technologies)

Dfinition des objectifs

Plan deprototypage

Plan deprototypage

Dfinition desfonctionnalits

Dveloppementdu prototype

valuation du prototype

Spcification(lgre)

Spcification(lgre) PrototypePrototype

Rapportdvaluation

Rapportdvaluation

23

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)

24

Plan

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

25

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

26

Modle en spirale : schma

27

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

28

Attention

Le modle en spirale est en fait un mta-modle

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 !

29

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)

30

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

31

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

32

Premier incrment

Objectifs tude de faisabilit Focalisation sur la technologie ce nest pas un prototype Trouver les alternatives technologiques si problme

Identification des risques Connaissances techno. insuffisantes formations

immdiates Planification et ralisation

1 mois de travail + 1 semaine de formation 2 personnes (rpartition des points travailler)

33

Second incrment

Objectifs Construction dun prototype Proposer des IHMs innovantes

Identification des risques Connaissances mtier insuffisantes planification

de runions

Planification et ralisation 2 mois de travail 4 personnes

34

Troisime incrment Objectifs

Dfinition dune architecture stable dintgration

Raliser la fonction de visualisation Identification des risques

Accs la base de donnes des documents duplication dune partie de la base

Planification et ralisation 6 mois de travail 6 personnes

Browser Serveurdapplications1..100 1

1..*

Serveurde donnes

1

35

Quatrime incrment

Objectifs Reprendre (et mettre jour) larchitecture existante Raliser les fonctions demprunt et de tlchargement

Identification des risques Problme de scurit contacter des experts et affiner les

besoins Planification et ralisation

9 mois de travail 6 personnes Client Riche Serveurdapplications1..100 1

1..*

Serveurde donnes

1

36

Cinquime incrment

Objectifs Reprendre (et mettre jour) larchitecture existante Raliser la fonction de rservation

Identification des risques 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

Serveurdapplications1..30 1

1..*

Serveurde donnes

1

37

Plan

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

38

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)

39(Maj YL 2007)

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.

40

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)

41(Maj YL 2007)

Principes des mthodes agiles Utilisateur implication dans le dveloppement

fourniture des exigences et prioritisationvaluation des itrations

Incrments fourniture incrmentale du logiciel People reconnaissance du talent des

dveloppeurspas de processus impos

Changements conception oriente volution Simplicit Chasser toute forme de complexit Tests jouent le rle de spcification Binmes les dveloppeurs travaillent par

binmes

42

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

valuation dusystme

Fourniture delincrment

Dveloppement intgration/test

Slection desscnarios

Cration de tches

Planification de lincrment

43

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

44

Salle de lquipe ( war room )

45

Scnarios cods

Scnarios nonplanifis

Scnarios planifis

Gestion des cartes (scnarios)

46Scnarios dtaills

Liste des bugs

Scnarios courants (1 ou 2 semaines)

47

Runion de fin ditration

48

War rooms : autres exemple

49

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

efficace et moins coteuse que les inspections formelles Favorise la re-factorisation du code

vers la simplicit Aussi productif que deux programmeurs

indpendants

50

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

51

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

52

Plan

Introduction Modles en cascade Modles volutifs Autres modles Modles agiles Synthse

53

Synthse

Un cycle de vie apporte stabilit, contrle et organisation une activit qui peut vite devenir chaotique meilleure estimation des cots et besoins meilleure coordination meilleure productivit meilleure visibilit et comprhension

Adopter et appliquer un cycle de vie est un signe de maturit pour une entreprise

(Maj YL 2007)

54

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

55

Lequel choisir ?

Pas de modle idal Cascade : risqu pour les projets innovants volutif : coteux pour les projets clairs ds le dbut

Pour les projets de taille petite ou moyenne (< 500 000 l) 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)

56

Gestion des exigences Conception Implantation

En gnral : imbriqu et itratif

57

Suggestions de lecture A Spiral Model of Software Development and Enhancement

Barry W. Boehm Computer 21(5), 1988

Software Development Process: A Necessary EvilMohamed E. Fayad, Communications of the ACM 40(9), 1997

The agile methods frayTom De Marco and Barry W. BoehmIEEE computer 35(6), 2002

http://www.extremeprogramming.org