SlideShare une entreprise Scribd logo
1  sur  57
Télécharger pour lire hors ligne
GL - 2
2.2 Processus de développement
Cycles de vie
Lydie du Bousquet
Lydie.du-bousquet@imag.fr

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

1
Plan
Introduction
Modèles en cascade
Modèles évolutifs
Modèle en spirale
Modèles agiles
Synthèse
2
Rappel sur les activités
Le développement comprend un ensemble d’activités
La gestion des exigences
La spécification
La conception
L’implantation
La validation
L’intégration
Le déploiement
La maintenance

L’enchaînement de ces activités se fait plus ou moins
bien
3
Cycle de vie du logiciel /
Processus de développement
Un processus de développement définit un ensemble d’activités
et leur enchaînement
Une activité comprend
des tâches,
des contraintes,
des ressources,
une façon d’être réalisée

La plupart des modèles des processus reprennent les activités
fondamentales mais les organisent différemment
De nombreux modèles ont été définis
Un modèle peut être spécifique à une organisation et à un type de
logiciels (ex: embarqué)
Il existe malheureusement peu d’outils supportant les processus
4
Plan
Introduction
Modèles en cascade
Modèles itératifs
Autres modèles
Modèles agiles
Synthèse
5
Modèles en cascade

Principes

Considérer le développement logiciel comme
une succession d’étapes réalisées de façon
strictement séquentielle
Chaque étape correspond à
une activité de base
Chaque étape est validée
Il n’y a pas (ou peu) de retours
en arrière

6
Modèles en cascade

« code and fix »
« on code d’abord et on
modifie ensuite »
Développement sauvage
Analyse courte et priorité au
codage
Votre dernier TD ?

Modèle primitif (< 1970)

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

Modifications

Design (6%)

Specification (5%)
Requirements (2%)

Maintenance (67%)

Inadapté aux
développements en équipe ou
de grande taille

7
Modèles en cascade

« Waterfall model » (1970)
Définition d’un
ensemble plus large et
plus complet d’activités
Chaque activité est
validée par un
document
Pas (ou peu) de retours
arrière
Inspiré des processus
d’ingénierie
8
Modèles en cascade

« Waterfall model » avec itération
Introduction des retours
en arrière (limité à la
phase précédente)
Plus flexible mais lourd
à gérer
Nombre d’itération
limité

9
Modèles en cascade

Le cycle de vie en V
Structuration de la phase de validation
Les tests sont définis à l’issue de chaque
phase

10
Modèles en cascade

Avantages
Simple et facile à comprendre
Force la documentation : une phase ne
peut se terminer avant q’un document
soit validé
Le test est inhérent à chaque phase
Les progrès sont tangibles (pour
l’équipe de développement)
11
Modèles en cascade

Limites

Modèle dirigé par les documents
Non compréhensibles par les clients
Le produit final est la première chose que voit le client
Est-ce un vraiment problème ?

Fait l’hypothèse de la faisabilité
Ne marche que si les exigences sont stables et le problème
connu

Manque de flexibilité (ne traite pas les évolutions,
notamment des exigences)
Problèmes découverts en phase de validation
Irréaliste dans de nombreux cas
12
Modèles en cascade

Conclusions
Conditions d’utilisation
Seulement quand les exigences sont bien
connues et non sujettes à modification
Fonctionnalités / Attentes utilisateurs
Technologies utilisées

Encore assez populaires
Simples et similaires au modèles utilisés
dans d’autres disciplines
Souvent utilisés par les non spécialistes
13
Plan
Introduction
Modèles en cascade
Modèles incrémentaux
Modèle en spirale
Modèles agiles
Synthèse
14
La nature changeante d’un projet
1 : Le changement est inévitable

L’environnement technique et économique évolue
Les besoins et les souhaits des clients changent
Les priorités du management aussi

les méthodes en cascade ne marchent pas
2 : On ne peut pas attendre de tout savoir pour
commencer
Réduction impérative du time-to-market
Illusion de la perfection

15
Modèles incrémentaux

Principes

Diviser le projet en incréments
Un incrément = une sous partie
fonctionnelle cohérente du
produit final
Chaque incrément ajoute de
nouvelles fonctions
Chaque incrément est testé
comme un produit final
Les incréments sont définis
a priori (classification des
exigences – par le client si
possible)

Définition des
exigences min
et des incréments
Conception de
l’architecture ou
d’un noyau

Développement
d’un incrément

Intégration et
validation

Produit final

16
Modèle incrémental - 1
Architecture évolutive
La première version constitue le noyau
Les versions suivantes s’appuient sur l’existant et
étendent l’architecture
Chaque version donne lieu à un cycle de vie
complet

17
Modèle incrémental - 2
Architecture stable

La première version fournit une enveloppe
complète
Chaque nouvelle version fournit un ou plusieurs
sous système en respectant l’architecture
Le développement en parallèle est possible
(surtout pour les incréments)

(Maj YL 2007)

18
Modèles incrémentaux

Avantages
Une première version du système est fournie
rapidement
ROI rapide (Retour sur investissement)
Réduit le stress du management !
En général, cette version n’est pas mise en production

Les risques d’échec sont diminués
Découverte des problèmes assez tôt
Les parties importantes sont fournies en premier et seront
donc testées plus longuement
Les clients peuvent ajouter des exigences à tous moments

(Maj YL 2007)

19
Modèles incrémentaux

Limites
Les incréments
Difficile à définir : mapper des exigences sur des incréments
est complexe
Trop peu d’incréments
on se rapproche du modèle en
cascade
Trop d’incréments
ingérable

L’architecture
Difficile de concevoir une architecture stable dès le début ou
facilement évolutive
Difficile d’identifier des services techniques communs

Ne traite pas toutes les évolutions, notamment celles
qui remettent en cause l’architecture
20
Autre modèle incrémental
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:

Plus flexible
Pas de conception globale

Specifications

Design

…

implementation/integration team

…

…

design team

Implementation,
integration

Deliver to client

Pb de réutilisation des incréments
21
Prototypage
Construire un prototype jetable pour mieux
comprendre les points durs (exigences, technologies)
Définition
des objectifs

Plan de
Plan de
prototypage
prototypage

Définition des
fonctionnalités

Spécification
Spécification
(légère)
(légère)

Développement
du prototype

Prototype
Prototype

Évaluation
du prototype

Rapport
Rapport
d’évaluation
d’évaluation
22
Propriétés du prototypage
Avantages
Permet d’impliquer l’utilisateur et d’éclaircir 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
Coût mal compris par les managers et les clients
Tentation de construire à partir du prototype et donc
d’utiliser des solutions non optimales
N’aborde qu’une phase du développement
(Maj YL 2007)

23
Plan
Introduction
Modèles en cascade
Modèles évolutifs
Modèle en spirale
Modèles agiles
Synthèse
24
Modèle en spirale (Boehm, 1988)
Le cycle de vie est représenté à l’aide d’une spirale
Chaque boucle représente une phase du développement
La boucle la plus interne traite des premières phases
(faisabilité). La plus externe traite de la livraison
Chaque boucle traverse quatre sections :
Définition des objectifs de la phase (la boucle)
Evaluation des risques et plan de gestion
Développement et validation
Planification de la phase suivante

Nombre de cycles variable

25
Modèle en spirale : schéma

26
Principe du modèle en spirale
Reconnaissance explicite de la notion de risque
Exemples
défaillance de personnel
calendrier et budgets irréalistes
développement de fonctionnalités inappropriées
développement d’interfaces utilisateurs inappropriées
produit « plaqué or » (non rentable)
volatilité des besoins
problème de performances
exigences démesurées par rapport à la technologie
tâches ou composants externes défaillants
27
Attention
Le modèle en spirale est en fait un métamodèle
Il offre un cadre où chaque boucle doit être
instanciée
On peut par exemple créer
Une boucle de faisabilité
Une boucle de prototypage
Des boucles de développement itératif, etc.

Il faut alors trouver le bon modèle de
processus pour chaque boucle !
28
Exemple
Rapide cahier des charges
Un logiciel pour gérer les emprunts de documents dans une
nouvelle bibliothèque très moderne qui possèdera des
ouvrages de toutes natures (dont multimédia)
Le logiciel devra permettre la visualisation, l’emprunt, le
téléchargement et la réservation des ouvrages.
Le logiciel devra utiliser les dernières avances des NTICs
(Nouvelles Technologies de l’Information et de la
Communication)
Les futurs utilisateurs sont très motivés mais ne savent pas
exactement à quoi s’attendre (ils ne connaissent pas les
NTICs)

29
Problèmes
Difficultés liées à ce projet
C’est un produit nouveau
On ne peut pas se baser sur un produit existant
Nouveaux types de documents
Nouveaux types de consultation
(téléchargement)

Utilisation de technologies nouvelles est
immatures
Besoins client à affiner
30
Approche retenue
Approche itérative avec 5 incréments
(ou boucles)
Incrément 1 : étude de faisabilité
Incrément 2 : prototypage
Incrément 3 : fonctions de visualisation
Incrément 4 : fonctions d’emprunt et de
téléchargement
Incrément 5 : fonctions de réservation
31
Premier incrément
Objectifs
Étude de faisabilité
Focalisation sur la technologie
ce n’est pas un prototype
Trouver les alternatives technologiques si problème

Identification des risques
Connaissances techno. insuffisantes
immédiates

formations

Planification et réalisation
1 mois de travail + 1 semaine de formation
2 personnes (répartition des points à travailler)

32
Second incrément
Objectifs
Construction d’un prototype
Proposer des IHMs « innovantes »

Identification des risques
Connaissances métier insuffisantes
de réunions

planification

Planification et réalisation
2 mois de travail
4 personnes
33
Troisième incrément
Objectifs
Définition d’une architecture stable
d’intégration
Réaliser la fonction de visualisation

Identification des risques
Accès à la base de données des documents
duplication d’une partie de la base

Planification et réalisation
6 mois de travail
6 personnes

Browser
1..100

1

Serveur
d’applications
1
1..*

Serveur
de données
34
Quatrième incrément
Objectifs
Reprendre (et mettre à jour) l’architecture existante
Réaliser les fonctions d’emprunt et de téléchargement

Identification des risques
Problème de sécurité
besoins

contacter des experts et affiner les

Planification et réalisation
9 mois de travail
6 personnes

Client Riche
1..100

1

Serveur
d’applications
1
1..*

Serveur
de données35
Cinquième incrément
Objectifs
Reprendre (et mettre à jour) l’architecture existante
Réaliser la fonction de réservation

Identification des risques
Crainte de retard
négociation avec les clients pour
identifier le meilleur palliatif
Performance
adaptation de l’architecture

Planification et réalisation
6 mois de travail
6 personnes

Client Riche
1..30

1

Serveur
d’applications
1
1..*

Serveur 36
de données
Plan
Introduction
Modèles en cascade
Modèles évolutifs
Modèle en spirale
Modèles agiles
Synthèse
37
Les cycles de vie présentés
jusqu’ici
Une approche très contrôlée du développement
Planification précise
Assurance qualité
Méthodes d’analyse et de conception
Utilisation d’outils (CASE)

Conditions optimales d’utilisation
Projets critiques de grande taille
Longue durée de développement et d’utilisation
Équipes de développement dispersées
Apport de plusieurs sociétés

(Maj YL 2007)

38
Remarque
En suivant ces cycles de vie, on peut
passer plus de temps sur la façon de
développer un système que sur le
développement lui même.

(Maj YL 2007)

39
Les méthodes agiles
Ces méthodes

Se focalisent sur le développement
(les ingénieurs aiment programmer)
Sont basées sur une approche itérative
Visent à fournir rapidement un logiciel exécutable que les
clients peuvent amender

Ces méthodes ont été conçues pour le
développement d’applications dont les exigences
changent
«
«
«
«

Extreme programming » (Beck)
Crystal » (Cockburn)
Adaptive software development » (Highsmith)
Feature driven development » (Palmer)
(Maj YL 2007)

40
Principes des méthodes agiles
Utilisateur
Incréments
People
Changements
Simplicité
Tests
Binômes

implication dans le développement
fourniture des exigences et prioritisation
évaluation des itérations
fourniture incrémentale du logiciel
reconnaissance du talent des
développeurs
pas de processus imposé
conception orientée évolution
Chasser toute forme de complexité
jouent le rôle de spécification
les développeurs travaillent par
binômes

(Maj YL 2007)

41
Extreme programming (XP)
Une approche basée sur des itérations fréquentes
Sélection des scénarios à réaliser (sous forme de cartes)
Définition et répartition des tâches
Planification du développement et des tests
Fourniture d’un logiciel exécutable et évaluation
Sélection des
scénarios

Évaluation du
système

Création de
tâches

Fourniture de
l’incrément

Planification
de l’incrément

Développement
intégration/test
42
XP : principes
Réalisation d’un incrément
Réunion debout tous les matins (tous)
Programmation à deux dans une « war room »
La « war room » se trouve de préférence chez le client
Les programmeurs définissent et exécutent les tests
Conception minimale
Constante adaptation du code pour simplifier
Intégration continuelle
Cadence intense

43
Salle de l’équipe (« war room »)

44
Gestion des cartes (scénarios)
Scénarios codés

Scénarios
planifiés

Scénarios non
planifiés

45
Scénarios courants (1 ou 2 semaines)
Liste des bugs

Scénarios détaillés

46
Réunion de fin d’itération

47
« War rooms » : autres exemple

48
Programmation à deux
De nombreux avantages

« egoless programming » : le code est à tout le
monde
Rotation des binômes et diffusion de la
connaissance dans le projet
Revue constante du code

efficace et moins coûteuse que les inspections formelles

Favorise la re-factorisation du code
vers la simplicité

Aussi productif que deux programmeurs
indépendants
49
La vérification dans XP
Beaucoup de tests mais les approches itératives
traitent souvent mal le test
(pas de spécifications sur lesquelles se baser)
Gestion des tests dans XP :
Définition des tests en premier
Chaque tâche donne lieu à des tests
Définis avant l’implantation avec le client

Ecriture de tests qui seront exécutés automatiquement
Codés avant l’applicatif
50
Difficultés des méthodes agiles
Aucune documentation n’est disponible pour la
maintenance
Ces méthodes sont parfois difficiles à mettre en place
Le client n’est pas toujours d’accord pour participer au
développement
Elles demandent une implication intense des développeurs
L’affectation de priorités est souvent complexes (surtout
quand il y plusieurs clients)
Maintenir la simplicité demande du travail additionnel

51
Plan
Introduction
Modèles en cascade
Modèles évolutifs
Autres modèles
Modèles agiles
Synthèse
52
Synthèse
Un cycle de vie apporte stabilité, contrôle et
organisation à une activité qui peut vite
devenir chaotique
meilleure
meilleure
meilleure
meilleure

estimation des coûts et besoins
coordination
productivité
visibilité et compréhension

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 modèles de cycles de vie
Les modèles définissent les activités et les livrables
Quelle satisfaction de pouvoir dire à la direction que « la
phase x est terminée »
rendus obligatoires par de nombreux clients

Les ingénieurs ne les aiment pas trop
Ne représentent pas ce qui se passe dans « les tranchées »
Ne règlent jamais complètement le problème des évolutions
(« les clients ne peuvent jamais donner leurs besoins dès le
début »)
Les phases sont toujours mêlées

54
Lequel choisir ?
Pas de modèle idéal
Cascade : risqué pour les projets innovants
évolutif : coûteux pour les projets clairs dès le début

Pour les projets de taille petite ou moyenne
(< 500 000 l)
Une approche incrémentale est souvent plus appropriée

Pour les grands projets (multi-sites, multi-équipes)
Approche mixte intégrant des aspects des modèles évolutifs
et des modèles en cascade
Exemple : utilisation d’un prototype pour stabiliser les
exigences et développement en V

(Maj YL 2007)

55
En général : imbriqué et itératif

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

Contenu connexe

Tendances

Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieMohammed Amine Mostefai
 
Présentation PFE: Système de gestion des réclamations et interventions clients
Présentation PFE: Système de gestion des réclamations et interventions clientsPrésentation PFE: Système de gestion des réclamations et interventions clients
Présentation PFE: Système de gestion des réclamations et interventions clientsMohamed Ayoub OUERTATANI
 
UML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouriUML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouriMansouri Khalifa
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-CorrectionLilia Sfaxi
 
Chp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceChp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceLilia Sfaxi
 
diagramme des cas d'utilisation
diagramme des cas d'utilisationdiagramme des cas d'utilisation
diagramme des cas d'utilisationAmir Souissi
 
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriMansouri Khalifa
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Ayoub Mkharbach
 
Support du cours : Programmation Web 2
Support du cours : Programmation Web 2Support du cours : Programmation Web 2
Support du cours : Programmation Web 2Faycel Chaoua
 
Telecharger Exercices corrigés PL/SQL
Telecharger Exercices corrigés PL/SQLTelecharger Exercices corrigés PL/SQL
Telecharger Exercices corrigés PL/SQLwebreaker
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Ahmed Makni
 
TD2 - UML - Correction
TD2 - UML - CorrectionTD2 - UML - Correction
TD2 - UML - CorrectionLilia Sfaxi
 
Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisationNassim Amine
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logicielMohamed Diallo
 
présentation ppt du stage technicien
présentation ppt du stage technicienprésentation ppt du stage technicien
présentation ppt du stage technicienIheb Ben Salem
 
TD1-UML-correction
TD1-UML-correctionTD1-UML-correction
TD1-UML-correctionLilia Sfaxi
 
Présentation soutenance du PFE
Présentation soutenance du PFEPrésentation soutenance du PFE
Présentation soutenance du PFEmarouan barssa
 
TD3-UML-Correction
TD3-UML-CorrectionTD3-UML-Correction
TD3-UML-CorrectionLilia Sfaxi
 

Tendances (20)

Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
 
Présentation PFE: Système de gestion des réclamations et interventions clients
Présentation PFE: Système de gestion des réclamations et interventions clientsPrésentation PFE: Système de gestion des réclamations et interventions clients
Présentation PFE: Système de gestion des réclamations et interventions clients
 
UML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouriUML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouri
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-Correction
 
Chp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceChp4 - Diagramme de Séquence
Chp4 - Diagramme de Séquence
 
diagramme des cas d'utilisation
diagramme des cas d'utilisationdiagramme des cas d'utilisation
diagramme des cas d'utilisation
 
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouri
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
 
Support du cours : Programmation Web 2
Support du cours : Programmation Web 2Support du cours : Programmation Web 2
Support du cours : Programmation Web 2
 
Telecharger Exercices corrigés PL/SQL
Telecharger Exercices corrigés PL/SQLTelecharger Exercices corrigés PL/SQL
Telecharger Exercices corrigés PL/SQL
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...
 
Diagramme d'activité en UML
Diagramme d'activité en UMLDiagramme d'activité en UML
Diagramme d'activité en UML
 
TD2 - UML - Correction
TD2 - UML - CorrectionTD2 - UML - Correction
TD2 - UML - Correction
 
Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisation
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logiciel
 
Cours Génie Logiciel - Introduction
Cours Génie Logiciel - IntroductionCours Génie Logiciel - Introduction
Cours Génie Logiciel - Introduction
 
présentation ppt du stage technicien
présentation ppt du stage technicienprésentation ppt du stage technicien
présentation ppt du stage technicien
 
TD1-UML-correction
TD1-UML-correctionTD1-UML-correction
TD1-UML-correction
 
Présentation soutenance du PFE
Présentation soutenance du PFEPrésentation soutenance du PFE
Présentation soutenance du PFE
 
TD3-UML-Correction
TD3-UML-CorrectionTD3-UML-Correction
TD3-UML-Correction
 

En vedette

Java - Introdução a banco de dados
Java - Introdução a banco de dadosJava - Introdução a banco de dados
Java - Introdução a banco de dadosSérgio Souza Costa
 
Manual de Usuário - TCC André Luiz Jamarino Abekawa
Manual de Usuário - TCC André Luiz Jamarino AbekawaManual de Usuário - TCC André Luiz Jamarino Abekawa
Manual de Usuário - TCC André Luiz Jamarino AbekawaAndré Luiz Jamarino Abekawa
 
Replicacao Object Sistemas
Replicacao Object SistemasReplicacao Object Sistemas
Replicacao Object Sistemastaniamaciel
 
Minicurso de Cakephp
Minicurso de CakephpMinicurso de Cakephp
Minicurso de CakephpCauan Cabral
 
Junções e subconsultas
Junções e subconsultasJunções e subconsultas
Junções e subconsultasjulianaveregue
 
Apostila PhP com Wamp, 2a. parte
Apostila PhP com Wamp, 2a. parteApostila PhP com Wamp, 2a. parte
Apostila PhP com Wamp, 2a. parteIlton Barbosa
 
6. Caracteres; Tipos char e int; Tipos de valor e de referência – Fundamentos...
6. Caracteres; Tipos char e int; Tipos de valor e de referência – Fundamentos...6. Caracteres; Tipos char e int; Tipos de valor e de referência – Fundamentos...
6. Caracteres; Tipos char e int; Tipos de valor e de referência – Fundamentos...Manuel Menezes de Sequeira
 
Scrum em 15 minutos
Scrum em 15 minutosScrum em 15 minutos
Scrum em 15 minutosSerge Rehem
 
Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Pyxis Technologies
 
area econòmica i patrimonial
area econòmica i patrimonialarea econòmica i patrimonial
area econòmica i patrimonialSandro
 
Canvi climàtic: Efectes i percepció social
Canvi climàtic: Efectes i percepció socialCanvi climàtic: Efectes i percepció social
Canvi climàtic: Efectes i percepció socialJosep Lluís Ruiz
 
Arquitectura de Computadores (II Bimestre)
Arquitectura de Computadores (II Bimestre)Arquitectura de Computadores (II Bimestre)
Arquitectura de Computadores (II Bimestre)Videoconferencias UTPL
 
Tema 3 Dissolucions 1er batxillerat
Tema 3 Dissolucions 1er batxilleratTema 3 Dissolucions 1er batxillerat
Tema 3 Dissolucions 1er batxilleratmmarti61
 
Les propietats dels materials i els assaigs d'estudi
Les propietats dels materials i els assaigs d'estudiLes propietats dels materials i els assaigs d'estudi
Les propietats dels materials i els assaigs d'estudiGlòria García García
 
1c-EL SEXENNI DEMOCRÀTIC
1c-EL SEXENNI DEMOCRÀTIC1c-EL SEXENNI DEMOCRÀTIC
1c-EL SEXENNI DEMOCRÀTICjcorbala
 

En vedette (20)

ADO.NET
ADO.NETADO.NET
ADO.NET
 
Java - Introdução a banco de dados
Java - Introdução a banco de dadosJava - Introdução a banco de dados
Java - Introdução a banco de dados
 
Manual de Usuário - TCC André Luiz Jamarino Abekawa
Manual de Usuário - TCC André Luiz Jamarino AbekawaManual de Usuário - TCC André Luiz Jamarino Abekawa
Manual de Usuário - TCC André Luiz Jamarino Abekawa
 
Replicacao Object Sistemas
Replicacao Object SistemasReplicacao Object Sistemas
Replicacao Object Sistemas
 
Minicurso de Cakephp
Minicurso de CakephpMinicurso de Cakephp
Minicurso de Cakephp
 
Junções e subconsultas
Junções e subconsultasJunções e subconsultas
Junções e subconsultas
 
Apostila PhP com Wamp, 2a. parte
Apostila PhP com Wamp, 2a. parteApostila PhP com Wamp, 2a. parte
Apostila PhP com Wamp, 2a. parte
 
6. Caracteres; Tipos char e int; Tipos de valor e de referência – Fundamentos...
6. Caracteres; Tipos char e int; Tipos de valor e de referência – Fundamentos...6. Caracteres; Tipos char e int; Tipos de valor e de referência – Fundamentos...
6. Caracteres; Tipos char e int; Tipos de valor e de referência – Fundamentos...
 
Agile Management
Agile ManagementAgile Management
Agile Management
 
Scrum em 15 minutos
Scrum em 15 minutosScrum em 15 minutos
Scrum em 15 minutos
 
Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?
 
Scrum Guide
Scrum GuideScrum Guide
Scrum Guide
 
Lliço5 Cinèticaquímica
Lliço5 CinèticaquímicaLliço5 Cinèticaquímica
Lliço5 Cinèticaquímica
 
area econòmica i patrimonial
area econòmica i patrimonialarea econòmica i patrimonial
area econòmica i patrimonial
 
Canvi climàtic: Efectes i percepció social
Canvi climàtic: Efectes i percepció socialCanvi climàtic: Efectes i percepció social
Canvi climàtic: Efectes i percepció social
 
Arquitectura de Computadores (II Bimestre)
Arquitectura de Computadores (II Bimestre)Arquitectura de Computadores (II Bimestre)
Arquitectura de Computadores (II Bimestre)
 
Tema 3 Dissolucions 1er batxillerat
Tema 3 Dissolucions 1er batxilleratTema 3 Dissolucions 1er batxillerat
Tema 3 Dissolucions 1er batxillerat
 
Les propietats dels materials i els assaigs d'estudi
Les propietats dels materials i els assaigs d'estudiLes propietats dels materials i els assaigs d'estudi
Les propietats dels materials i els assaigs d'estudi
 
Tema15
Tema15Tema15
Tema15
 
1c-EL SEXENNI DEMOCRÀTIC
1c-EL SEXENNI DEMOCRÀTIC1c-EL SEXENNI DEMOCRÀTIC
1c-EL SEXENNI DEMOCRÀTIC
 

Similaire à 2.2 cycles de vie

Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptxLatifaBen6
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Erradi Mohamed
 
3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciellauraty3204
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxssuserec8501
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_finalagnes_crepet
 
1bis_ProcessusUnifie.pdf
1bis_ProcessusUnifie.pdf1bis_ProcessusUnifie.pdf
1bis_ProcessusUnifie.pdfWafaNeji1
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxinformatiquehageryah
 
NightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryNightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryZenika
 
Ddj Architecture & Design Beyond Functional Requirements On Agile Projects
Ddj   Architecture & Design   Beyond Functional Requirements On Agile ProjectsDdj   Architecture & Design   Beyond Functional Requirements On Agile Projects
Ddj Architecture & Design Beyond Functional Requirements On Agile ProjectsEmmanuel Hugonnet
 
Utc apm human talks compiegne
Utc apm human talks compiegneUtc apm human talks compiegne
Utc apm human talks compiegneArthur Van Ceulen
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxtestuser715939
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1DIALLO Boubacar
 
Retour d expérience_sur_l_agilité
Retour d expérience_sur_l_agilitéRetour d expérience_sur_l_agilité
Retour d expérience_sur_l_agilitéAgile Partner S.A.
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logicielguest0032c8
 
Presentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationPresentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationStéphane Traumat
 
Une application sans framework en 2019
Une application sans framework en 2019Une application sans framework en 2019
Une application sans framework en 2019Rodrigue Villetard
 

Similaire à 2.2 cycles de vie (20)

Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
Up1
Up1Up1
Up1
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
1bis_ProcessusUnifie.pdf
1bis_ProcessusUnifie.pdf1bis_ProcessusUnifie.pdf
1bis_ProcessusUnifie.pdf
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
 
NightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryNightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous Delivery
 
Ddj Architecture & Design Beyond Functional Requirements On Agile Projects
Ddj   Architecture & Design   Beyond Functional Requirements On Agile ProjectsDdj   Architecture & Design   Beyond Functional Requirements On Agile Projects
Ddj Architecture & Design Beyond Functional Requirements On Agile Projects
 
Utc apm human talks compiegne
Utc apm human talks compiegneUtc apm human talks compiegne
Utc apm human talks compiegne
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
Initiation à UML: Partie 1
Initiation à UML: Partie 1Initiation à UML: Partie 1
Initiation à UML: Partie 1
 
Retour d expérience_sur_l_agilité
Retour d expérience_sur_l_agilitéRetour d expérience_sur_l_agilité
Retour d expérience_sur_l_agilité
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
 
Presentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationPresentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub Foundation
 
Une application sans framework en 2019
Une application sans framework en 2019Une application sans framework en 2019
Une application sans framework en 2019
 
Lecon 1.1
Lecon 1.1Lecon 1.1
Lecon 1.1
 
Methodologie projet
Methodologie projet Methodologie projet
Methodologie projet
 

Dernier

Calendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilCalendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilfrizzole
 
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfbdp12
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Gabriel Gay-Para
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfSylvianeBachy
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursStagiaireLearningmat
 
Aux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAmar LAKEL, PhD
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfRiDaHAziz
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 37
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film françaisTxaruka
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfRiDaHAziz
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 37
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24BenotGeorges3
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxJCAC
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneTxaruka
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxMartin M Flynn
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film françaisTxaruka
 
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 37
 

Dernier (18)

Calendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilCalendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avril
 
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceurs
 
Aux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècle
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdf
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film français
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdf
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
 
Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienne
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film français
 
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
 

2.2 cycles de vie

  • 1. GL - 2 2.2 Processus de développement Cycles de vie Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, Ph. Lalanda, I. Parissis, Y. Ledru 1
  • 2. Plan Introduction Modèles en cascade Modèles évolutifs Modèle en spirale Modèles agiles Synthèse 2
  • 3. Rappel sur les activités Le développement comprend un ensemble d’activités La gestion des exigences La spécification La conception L’implantation La validation L’intégration Le déploiement La maintenance L’enchaînement de ces activités se fait plus ou moins bien 3
  • 4. Cycle de vie du logiciel / Processus de développement Un processus de développement définit un ensemble d’activités et leur enchaînement Une activité comprend des tâches, des contraintes, des ressources, une façon d’être réalisée La plupart des modèles des processus reprennent les activités fondamentales mais les organisent différemment De nombreux modèles ont été définis Un modèle peut être spécifique à une organisation et à un type de logiciels (ex: embarqué) Il existe malheureusement peu d’outils supportant les processus 4
  • 5. Plan Introduction Modèles en cascade Modèles itératifs Autres modèles Modèles agiles Synthèse 5
  • 6. Modèles en cascade Principes Considérer le développement logiciel comme une succession d’étapes réalisées de façon strictement séquentielle Chaque étape correspond à une activité de base Chaque étape est validée Il n’y a pas (ou peu) de retours en arrière 6
  • 7. Modèles en cascade « code and fix » « on code d’abord et on modifie ensuite » Développement sauvage Analyse courte et priorité au codage Votre dernier TD ? Modèle primitif (< 1970) Construction d’une v0 Relative Costs of Phases Integration (8%) Module testing (7%) Module coding (5%) Modifications Design (6%) Specification (5%) Requirements (2%) Maintenance (67%) Inadapté aux développements en équipe ou de grande taille 7
  • 8. Modèles en cascade « Waterfall model » (1970) Définition d’un ensemble plus large et plus complet d’activités Chaque activité est validée par un document Pas (ou peu) de retours arrière Inspiré des processus d’ingénierie 8
  • 9. Modèles en cascade « Waterfall model » avec itération Introduction des retours en arrière (limité à la phase précédente) Plus flexible mais lourd à gérer Nombre d’itération limité 9
  • 10. Modèles en cascade Le cycle de vie en V Structuration de la phase de validation Les tests sont définis à l’issue de chaque phase 10
  • 11. Modèles en cascade Avantages Simple et facile à comprendre Force la documentation : une phase ne peut se terminer avant q’un document soit validé Le test est inhérent à chaque phase Les progrès sont tangibles (pour l’équipe de développement) 11
  • 12. Modèles en cascade Limites Modèle dirigé par les documents Non compréhensibles par les clients Le produit final est la première chose que voit le client Est-ce un vraiment problème ? Fait l’hypothèse de la faisabilité Ne marche que si les exigences sont stables et le problème connu Manque de flexibilité (ne traite pas les évolutions, notamment des exigences) Problèmes découverts en phase de validation Irréaliste dans de nombreux cas 12
  • 13. Modèles en cascade Conclusions Conditions d’utilisation Seulement quand les exigences sont bien connues et non sujettes à modification Fonctionnalités / Attentes utilisateurs Technologies utilisées Encore assez populaires Simples et similaires au modèles utilisés dans d’autres disciplines Souvent utilisés par les non spécialistes 13
  • 14. Plan Introduction Modèles en cascade Modèles incrémentaux Modèle en spirale Modèles agiles Synthèse 14
  • 15. La nature changeante d’un projet 1 : Le changement est inévitable L’environnement technique et économique évolue Les besoins et les souhaits des clients changent Les priorités du management aussi les méthodes en cascade ne marchent pas 2 : On ne peut pas attendre de tout savoir pour commencer Réduction impérative du time-to-market Illusion de la perfection 15
  • 16. Modèles incrémentaux Principes Diviser le projet en incréments Un incrément = une sous partie fonctionnelle cohérente du produit final Chaque incrément ajoute de nouvelles fonctions Chaque incrément est testé comme un produit final Les incréments sont définis a priori (classification des exigences – par le client si possible) Définition des exigences min et des incréments Conception de l’architecture ou d’un noyau Développement d’un incrément Intégration et validation Produit final 16
  • 17. Modèle incrémental - 1 Architecture évolutive La première version constitue le noyau Les versions suivantes s’appuient sur l’existant et étendent l’architecture Chaque version donne lieu à un cycle de vie complet 17
  • 18. Modèle incrémental - 2 Architecture stable La première version fournit une enveloppe complète Chaque nouvelle version fournit un ou plusieurs sous système en respectant l’architecture Le développement en parallèle est possible (surtout pour les incréments) (Maj YL 2007) 18
  • 19. Modèles incrémentaux Avantages Une première version du système est fournie rapidement ROI rapide (Retour sur investissement) Réduit le stress du management ! En général, cette version n’est pas mise en production Les risques d’échec sont diminués Découverte des problèmes assez tôt Les parties importantes sont fournies en premier et seront donc testées plus longuement Les clients peuvent ajouter des exigences à tous moments (Maj YL 2007) 19
  • 20. Modèles incrémentaux Limites Les incréments Difficile à définir : mapper des exigences sur des incréments est complexe Trop peu d’incréments on se rapproche du modèle en cascade Trop d’incréments ingérable L’architecture Difficile de concevoir une architecture stable dès le début ou facilement évolutive Difficile d’identifier des services techniques communs Ne traite pas toutes les évolutions, notamment celles qui remettent en cause l’architecture 20
  • 21. Autre modèle incrémental 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: Plus flexible Pas de conception globale Specifications Design … implementation/integration team … … design team Implementation, integration Deliver to client Pb de réutilisation des incréments 21
  • 22. Prototypage Construire un prototype jetable pour mieux comprendre les points durs (exigences, technologies) Définition des objectifs Plan de Plan de prototypage prototypage Définition des fonctionnalités Spécification Spécification (légère) (légère) Développement du prototype Prototype Prototype Évaluation du prototype Rapport Rapport d’évaluation d’évaluation 22
  • 23. Propriétés du prototypage Avantages Permet d’impliquer l’utilisateur et d’éclaircir 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 Coût mal compris par les managers et les clients Tentation de construire à partir du prototype et donc d’utiliser des solutions non optimales N’aborde qu’une phase du développement (Maj YL 2007) 23
  • 24. Plan Introduction Modèles en cascade Modèles évolutifs Modèle en spirale Modèles agiles Synthèse 24
  • 25. Modèle en spirale (Boehm, 1988) Le cycle de vie est représenté à l’aide d’une spirale Chaque boucle représente une phase du développement La boucle la plus interne traite des premières phases (faisabilité). La plus externe traite de la livraison Chaque boucle traverse quatre sections : Définition des objectifs de la phase (la boucle) Evaluation des risques et plan de gestion Développement et validation Planification de la phase suivante Nombre de cycles variable 25
  • 26. Modèle en spirale : schéma 26
  • 27. Principe du modèle en spirale Reconnaissance explicite de la notion de risque Exemples défaillance de personnel calendrier et budgets irréalistes développement de fonctionnalités inappropriées développement d’interfaces utilisateurs inappropriées produit « plaqué or » (non rentable) volatilité des besoins problème de performances exigences démesurées par rapport à la technologie tâches ou composants externes défaillants 27
  • 28. Attention Le modèle en spirale est en fait un métamodèle Il offre un cadre où chaque boucle doit être instanciée On peut par exemple créer Une boucle de faisabilité Une boucle de prototypage Des boucles de développement itératif, etc. Il faut alors trouver le bon modèle de processus pour chaque boucle ! 28
  • 29. Exemple Rapide cahier des charges Un logiciel pour gérer les emprunts de documents dans une nouvelle bibliothèque très moderne qui possèdera des ouvrages de toutes natures (dont multimédia) Le logiciel devra permettre la visualisation, l’emprunt, le téléchargement et la réservation des ouvrages. Le logiciel devra utiliser les dernières avances des NTICs (Nouvelles Technologies de l’Information et de la Communication) Les futurs utilisateurs sont très motivés mais ne savent pas exactement à quoi s’attendre (ils ne connaissent pas les NTICs) 29
  • 30. Problèmes Difficultés liées à ce projet C’est un produit nouveau On ne peut pas se baser sur un produit existant Nouveaux types de documents Nouveaux types de consultation (téléchargement) Utilisation de technologies nouvelles est immatures Besoins client à affiner 30
  • 31. Approche retenue Approche itérative avec 5 incréments (ou boucles) Incrément 1 : étude de faisabilité Incrément 2 : prototypage Incrément 3 : fonctions de visualisation Incrément 4 : fonctions d’emprunt et de téléchargement Incrément 5 : fonctions de réservation 31
  • 32. Premier incrément Objectifs Étude de faisabilité Focalisation sur la technologie ce n’est pas un prototype Trouver les alternatives technologiques si problème Identification des risques Connaissances techno. insuffisantes immédiates formations Planification et réalisation 1 mois de travail + 1 semaine de formation 2 personnes (répartition des points à travailler) 32
  • 33. Second incrément Objectifs Construction d’un prototype Proposer des IHMs « innovantes » Identification des risques Connaissances métier insuffisantes de réunions planification Planification et réalisation 2 mois de travail 4 personnes 33
  • 34. Troisième incrément Objectifs Définition d’une architecture stable d’intégration Réaliser la fonction de visualisation Identification des risques Accès à la base de données des documents duplication d’une partie de la base Planification et réalisation 6 mois de travail 6 personnes Browser 1..100 1 Serveur d’applications 1 1..* Serveur de données 34
  • 35. Quatrième incrément Objectifs Reprendre (et mettre à jour) l’architecture existante Réaliser les fonctions d’emprunt et de téléchargement Identification des risques Problème de sécurité besoins contacter des experts et affiner les Planification et réalisation 9 mois de travail 6 personnes Client Riche 1..100 1 Serveur d’applications 1 1..* Serveur de données35
  • 36. Cinquième incrément Objectifs Reprendre (et mettre à jour) l’architecture existante Réaliser la fonction de réservation Identification des risques Crainte de retard négociation avec les clients pour identifier le meilleur palliatif Performance adaptation de l’architecture Planification et réalisation 6 mois de travail 6 personnes Client Riche 1..30 1 Serveur d’applications 1 1..* Serveur 36 de données
  • 37. Plan Introduction Modèles en cascade Modèles évolutifs Modèle en spirale Modèles agiles Synthèse 37
  • 38. Les cycles de vie présentés jusqu’ici Une approche très contrôlée du développement Planification précise Assurance qualité Méthodes d’analyse et de conception Utilisation d’outils (CASE) Conditions optimales d’utilisation Projets critiques de grande taille Longue durée de développement et d’utilisation Équipes de développement dispersées Apport de plusieurs sociétés (Maj YL 2007) 38
  • 39. Remarque En suivant ces cycles de vie, on peut passer plus de temps sur la façon de développer un système que sur le développement lui même. (Maj YL 2007) 39
  • 40. Les méthodes agiles Ces méthodes Se focalisent sur le développement (les ingénieurs aiment programmer) Sont basées sur une approche itérative Visent à fournir rapidement un logiciel exécutable que les clients peuvent amender Ces méthodes ont été conçues pour le développement d’applications dont les exigences changent « « « « Extreme programming » (Beck) Crystal » (Cockburn) Adaptive software development » (Highsmith) Feature driven development » (Palmer) (Maj YL 2007) 40
  • 41. Principes des méthodes agiles Utilisateur Incréments People Changements Simplicité Tests Binômes implication dans le développement fourniture des exigences et prioritisation évaluation des itérations fourniture incrémentale du logiciel reconnaissance du talent des développeurs pas de processus imposé conception orientée évolution Chasser toute forme de complexité jouent le rôle de spécification les développeurs travaillent par binômes (Maj YL 2007) 41
  • 42. Extreme programming (XP) Une approche basée sur des itérations fréquentes Sélection des scénarios à réaliser (sous forme de cartes) Définition et répartition des tâches Planification du développement et des tests Fourniture d’un logiciel exécutable et évaluation Sélection des scénarios Évaluation du système Création de tâches Fourniture de l’incrément Planification de l’incrément Développement intégration/test 42
  • 43. XP : principes Réalisation d’un incrément Réunion debout tous les matins (tous) Programmation à deux dans une « war room » La « war room » se trouve de préférence chez le client Les programmeurs définissent et exécutent les tests Conception minimale Constante adaptation du code pour simplifier Intégration continuelle Cadence intense 43
  • 44. Salle de l’équipe (« war room ») 44
  • 45. Gestion des cartes (scénarios) Scénarios codés Scénarios planifiés Scénarios non planifiés 45
  • 46. Scénarios courants (1 ou 2 semaines) Liste des bugs Scénarios détaillés 46
  • 47. Réunion de fin d’itération 47
  • 48. « War rooms » : autres exemple 48
  • 49. Programmation à deux De nombreux avantages « egoless programming » : le code est à tout le monde Rotation des binômes et diffusion de la connaissance dans le projet Revue constante du code efficace et moins coûteuse que les inspections formelles Favorise la re-factorisation du code vers la simplicité Aussi productif que deux programmeurs indépendants 49
  • 50. La vérification dans XP Beaucoup de tests mais les approches itératives traitent souvent mal le test (pas de spécifications sur lesquelles se baser) Gestion des tests dans XP : Définition des tests en premier Chaque tâche donne lieu à des tests Définis avant l’implantation avec le client Ecriture de tests qui seront exécutés automatiquement Codés avant l’applicatif 50
  • 51. Difficultés des méthodes agiles Aucune documentation n’est disponible pour la maintenance Ces méthodes sont parfois difficiles à mettre en place Le client n’est pas toujours d’accord pour participer au développement Elles demandent une implication intense des développeurs L’affectation de priorités est souvent complexes (surtout quand il y plusieurs clients) Maintenir la simplicité demande du travail additionnel 51
  • 52. Plan Introduction Modèles en cascade Modèles évolutifs Autres modèles Modèles agiles Synthèse 52
  • 53. Synthèse Un cycle de vie apporte stabilité, contrôle et organisation à une activité qui peut vite devenir chaotique meilleure meilleure meilleure meilleure estimation des coûts et besoins coordination productivité visibilité et compréhension Adopter et appliquer un cycle de vie est un signe de maturité pour une entreprise (Maj YL 2007) 53
  • 54. A retenir Les managers adorent les modèles de cycles de vie Les modèles définissent les activités et les livrables Quelle satisfaction de pouvoir dire à la direction que « la phase x est terminée » rendus obligatoires par de nombreux clients Les ingénieurs ne les aiment pas trop Ne représentent pas ce qui se passe dans « les tranchées » Ne règlent jamais complètement le problème des évolutions (« les clients ne peuvent jamais donner leurs besoins dès le début ») Les phases sont toujours mêlées 54
  • 55. Lequel choisir ? Pas de modèle idéal Cascade : risqué pour les projets innovants évolutif : coûteux pour les projets clairs dès le début Pour les projets de taille petite ou moyenne (< 500 000 l) Une approche incrémentale est souvent plus appropriée Pour les grands projets (multi-sites, multi-équipes) Approche mixte intégrant des aspects des modèles évolutifs et des modèles en cascade Exemple : utilisation d’un prototype pour stabiliser les exigences et développement en V (Maj YL 2007) 55
  • 56. En général : imbriqué et itératif Gestion des exigences Conception Implantation 56
  • 57. 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