Rup

Processus Unifi
Unified Software Development Process /

Unified Process (UP)
Merci tous ceux qui ont rendu leurs cours et

exposs disponibles sur le web & dans les livres,
voir Biblio. & refs dans les slides
M. Blay-Fornarino
1
jeudi 13 octobre 2011
Cycle de Vie. Mthodes Processus Unifi Exemple

Beaucoup de mthodes
lies des outils, ladaptation UML (comme langage de
notation) de mthodes pr-existantes , aux entreprises, etc.
finalement, autant de mthodes que de concepteurs / projets
(1997) UP : Rumbaugh, Booch, Jacobson (les concepteurs dUML)

une trame commune des meilleures pratiques de developpement
(pas une mthode)
Issu des travaux de lObject Management Group et de Rational
Plusieurs variantes (RUP,UPEDU,) toutes intgrant lUML
2

3

Un Processus unifi est
un processus de dveloppement logiciel
- construit sur UML
- conduit par les cas dutilisation
- pilot par les risques
- centr sur larchitecture,
- itratif et incrmental
- organis autour de 4 phases :

prtude(inception), laboration, construction et transition
- dfini par 6 disciplines fondamentales :

Modlisation mtier, Analyse et Conception, Implmentation, Test et
Dploiement
4
Processus Unifi
Pilot par les cas dutilisation
Le processus de dveloppement est centr sur lutilisateur
Modles
UML
5

- construit sur UML


Dploiement
6
(3) Pilotage par les risques

Un risque est un
vnement redout dont
loccurrence est plus ou
moins prvisible et
provoquant, lorsquil se
produit, des dommages
Vous avez la grippe, je vais vous
sur le projet. prescrire des antibiotiques
Il ne faut pas confondre risque et problme.

l Un problme est un risque qui sest rvl.
7
(3) Pilotage par les risques

Lhiver,
Un risque est un il faut se faire vacciner
vnement redout dont contre la grippe
loccurrence est plus ou

moins prvisible et
provoquant, lorsquil se
produit, des dommages
Vous avez la grippe, je vais vous
sur le projet. prescrire des antibiotiques
Il ne faut pas confondre risque et problme.

l Un problme est un risque qui sest rvl.
7
Facteurs de Risque
Quelques facteurs de Risques :
Technique/ Architectural
Technologie incertaine, visibilit partielle
Doivent tre
Ressources
identifis et
Les gens, les comptences, le financement
prioriss
Business dans des
La concurrence, les interfaces avec les
fournisseurs artefacts
ddis
Planning
Dpendances
Only 24 hours in a day
An ongoing or upcoming
Changements dexigences concern that has a significant
probability of adversely
affecting the success of major
8 milestones. (RUP Glossary)
Identifier les facteurs de risques

Un facteur de risque peut entraner lapparition de plusieurs risques
Dveloppement sans spcifications approuves
-> insatisfaction du client
-> surcot du projet
Plusieurs facteurs de risque peuvent contribuer lapparition dun

mme risque
Connaissance insuffisante du mtier client,
Plan de validation incomplet,
Conduite au changement non-prvue
-> rejet par les utilisateurs
daprs Michel Winter 2008 / 2009 9

Analyser les risques

Lanalyse des risques consiste valuer :
La probabilit dapparition dun risque
La gravit dune consquence
Exemple :
Probabilit de rencontrer un chat en libert Paris : forte
Probabilit de rencontrer un lion en libert Paris : faible
Probabilit de rencontrer un lion en libert dans la savane : forte
Probabilit de rencontrer un chat en libert dans la savane : faible
Gravit dune morsure de chat : faible

Gravit dune morsure de lion : forte
10
daprs Michel Winter 2008 / 2009
Actions
La gestion des risques consiste prvoir ou anticiper les situations risques et
mettre en uvre un plan dactions compos :
Actions de rduction : rduire linfluence des facteurs de risques (rduire la
probabilit)
Les technologies utilises sont bien connues des dveloppeurs, ce qui devrait rduire
les risques de non-aboutissement.
Actions prventives : ne pas se mettre dans une situation (actions sur le
dclenchement des facteurs de risques)
Lintervention dun ergonome rduira les risques de non acceptance.
Actions de couverture : limiter les consquences des risques (rduire la gravit)
Un dveloppement itratif, incrmental permettra de limiter la prise de risque
technologique
Attitude de NO GO
Le projet est abandonn.
11
daprs Michel Winter 2008 / 2009

- construit sur UML


Dploiement
12
Notion darchitecture
Au sens de RUP, une architecture :
Sert comprendre le systme lorsquil est complexe
Pilote le projet en dcoupant les tches
Favorise la rutilisation
Software architecture is not only concerned with structure and behavior,

but also with usage, functionality, performance, resilience, reuse,
comprehensibility, economic and technological constraints and tradeoffs,
and esthetics. (RUP, 98)-
A Technical Architecture is the minimal set of rules governing the

arrangement, interaction, and interdependance of the parts or elements that
together may be used to form an information system. (U.S. Army 1996)
13
Quelques axes pour considrer

larchitecture
Architectures client/serveurs en niveaux
aussi appels tiers
Architectures en couches
Prsentation, Application, Domaine/mtier, Infrastructure mtier
(services mtiers de bas-niveau), Services techniques (ex. scurit),
Fondation (ex. accs et stockage des donnes)
Architectures en zones de dploiement
dploiement des fonctions sur les postes de travail des utilisateurs
(entreprise : central/dpartemental/local)
Architectures base de composants
rutilisation de composants
14

- construit sur UML


Dploiement
15
Processus Unifi
Itratif et Incrmental
http://www.entreprise-agile.com/HistoAgile.pdf
16
Processus Unifi
http://www.entreprise-agile.com/HistoAgile.pdf 17
Processus Unifi
Ordonnancement des itrations bas sur les priorits entre cas
d'utilisation et sur l'tude du risque
Une itration est une squence dactivits
Une itration se dcompose en:
Une planification de litration
Analyse des besoins (raffinement)
Analyse et conception
Implmentation et tests
valuation
Livraison
18
Approche Itrative
time
content
19
Une
Approche Itrative itration,
traverse
time
toutes les
disciplines.
content
Disciplines
19

- construit sur UML


Dploiement
20
Les 4 phases
Incep Transi
tion tion
Elaboration Construction
MBA/IID-SIA-20072001 P. Colin 21
Les 4 phases
Ce qui
sera
valid
Incep Transi
tion tion
Les 4 phases
Ce qui
sera
valid
Incep Transi
tion tion
Les 4 phases
Primtre
Ce qui Organisation du projet
sera Estimations
valid Besoins majeurs
Incep Transi
tion tion
Les 4 phases
Primtre
sera Estimations
Incep Transi
tion tion
Les 4 phases
Primtre
sera Estimations
Incep Transi
tion tion
Ce
qui
est
fait
Les 4 phases
Primtre
sera Estimations
Incep Transi
tion tion
- Validation des
objectifs
- Identification des
besoins majeurs
- Macro-planification Ce
- Analyse des risques qui
majeurs
est
- Macro-estimation
- Macro-analyse
fait
architecture
Les 4 phases
Primtre Architecture
Ce qui Organisation du projet Estimations
sera Estimations fines
valid Besoins majeurs Exigences
Incep Transi
tion tion
- Validation des
objectifs
besoins majeurs
- Macro-planification Ce
- Analyse des risques qui
majeurs
est
- Macro-estimation
- Macro-analyse
fait
architecture
Les 4 phases
Primtre Architecture
Ce qui Organisation du projet Estimations
sera Estimations fines
Incep Transi
tion tion
- Validation des
objectifs -Formalisation des
exigences
besoins majeurs -Analyse fine,
conception et
- Macro-planification construction de Ce
- Analyse des risques larchitecture de base qui
majeurs - Mise en place de est
- Macro-estimation lenvironnement
- Macro-analyse
fait
- Revue des plans
architecture - Micro-estimation
Les 4 phases
Primtre Architecture Solution
Ce qui Organisation du projet Estimations oprationnelle
sera Estimations fines Documentation
Incep Transi
tion tion
- Validation des
exigences
besoins majeurs -Analyse fine,
conception et
- Analyse des risques larchitecture de base qui
majeurs - Mise en place de est
- Macro-estimation lenvironnement
- Macro-analyse
fait
- Revue des plans
Les 4 phases
Primtre Architecture Solution
Ce qui Organisation du projet Estimations oprationnelle
Incep Transi
tion tion
- Validation des
exigences - Suite conception
-Analyse fine, et implmentation
besoins majeurs
conception et - Gestion des
demandes de
- Analyse des risques larchitecture de base changement qui
majeurs - Mise en place de - Prparation est
- Macro-estimation lenvironnement dploiement
- Macro-analyse
fait
- Revue des plans - Tests
Les 4 phases
Primtre Architecture Solution Solution
Ce qui Organisation du projet Estimations oprationnelle dploye
Incep Transi
tion tion
- Validation des
exigences - Suite conception
-Analyse fine, et implmentation
besoins majeurs
conception et - Gestion des
demandes de
majeurs - Mise en place de - Prparation est
- Macro-analyse
fait
Les 4 phases
Primtre Architecture Solution Solution
Ce qui Organisation du projet Estimations oprationnelle dploye
Incep Transi
tion tion
- Validation des
exigences - Suite conception - Test et
-Analyse fine, et implmentation valuation de
besoins majeurs
conception et - Gestion des la version bta
demandes de - Formation
majeurs - Transfert de
- Mise en place de - Prparation comptence est
- Macro-analyse
- capitalisation fait
Pr-tude (Inception Phase): Objectifs
tablir la porte du projet et les conditions aux limites

Dterminer les cas d'utilisation et les scnarios principaux
Proposer une architecture
Estimer le cot global et le calendrier
Identifier les risques potentiels et leurs sources
Dmontrer que le systme propos est en mesure de rsoudre
les problmes ou de prendre en charge les objectifs fixs
Vision : Glossaire, Dtermination des parties prenantes et
des utilisateurs, Dtermination de leurs besoins, Besoins
fonctionnels et non fonctionnels,
22
Contraintes de conception
Pr-tude (Inception Phase): Evaluation
Acceptation des parties prenantes sur la dfinition du champ

d'application
Accord sur les exigences (ensemble et comprhension
commune)
Accord sur les estimations de cot, le planning, les priorits,
les risques et le processus de dveloppement
Les risques ont t identifis et une stratgie de gestion du
risque a t prvue.
23
Pr-tude (Inception Phase): Evaluation
Acceptation des parties prenantes sur la dfinition du champ

d'application
Accord sur les exigences (ensemble et comprhension
commune)
Accord sur les estimations de cot, le planning, les priorits,
les risques et le processus de dveloppement
Les risques ont t identifis et une stratgie de gestion du
risque a t prvue.
Abandon du projet si pas de

23 passage de ce jalon
Elaboration Phase: Objectifs
Dfinir et valider l'architecture de base

Formuler les cas dutilisation pour couvrir environ 80% des
besoins fonctionnels
Dfinir les niveaux de qualit atteindre,
Etablir un plan dtaill pour la phase de construction
Dmontrer que l'architecture de base prend en charge la
vision un cot raisonnable dans un dlai raisonnable
Architecture : Document darchitecture Logicielle,
Diffrentes vues selon la partie prenante,
Comportement et conception des composants du systme
24
Description dArchitecture (1)

Software Architecture Document
Donne une vue d'ensemble complte de l'architecture

du systme logiciel
Inclus
Vues dArchitecture
Buts et contraintes
Exigences que larchitecture doit supporter
Contraintes Techniques
Caractristiques de taille et performance
Qualit, extensibilit, and cibles potentielles (portabilit)
25
Description dArchitecture (2)
Implementation Model
Design Model Deployment Model
26
Elaboration Phase: Evaluation

Vision du produit et les exigences sont stables.
L'architecture est stable.
Les lments de risque majeurs ont t abords et rsolus.
Les plans ditration pour la phase de construction sont
suffisamment dtaills
Tous les intervenants s'entendent pour dire que la vision
actuelle peut tre atteinte si le plan actuel est excut dans le
contexte de l'architecture actuelle.
27
Construction Phase: Objectifs
Objectifs principaux
Produire un logiciel utilisable conforme aux besoins
Confronter ce logiciel aux critres dacceptation
Extension de lidentification, de la description et de la
ralisation des cas dutilisation
Finalisation de lanalyse, de la conception, de limplmentation
et des tests
Produit : Premire version suffisamment stable et mature

pour tre dploye (teste, documente, accompagne),
Les procdures dinstallation sont
28
prtes
Construction Phase: Evaluation
La version du produit est-elle assez stable et mre pour tre

dploye dans la communaut des utilisateurs?
Les utilisateurs sont-ils informs ? Sensibiliss ? Forms?
Les dpenses engages par rapport aux prvisions sont-elles
acceptables?
29
Transition Phase: Objectifs
Prparation des activits

Recommandations au client sur la mise jour de
lenvironnement logiciel
Elaboration des manuels et de la documentation concernant la
version du produit
Adaptation du logiciel
Correction des anomalies lies au bta test
Dernires corrections
Livraison du produit
aux utilisateurs
30
Transition Phase: Evaluation
Les utilisateurs sont-ils satisfaits ?

Les dpenses engages par rapport aux prvisions sont-elles
acceptables?
31
Itrations dans chaque Phase

Pr-tude Elaboration Construction Transition
Preliminary Architecture Architecture Development Development
Development Development Transition Transition
Transition
Iteration Iteration Iteration
Iteration Iteration Iteration Iteration
Iteration
Iteration Iteration
Versions Excutables
32
Tous les critres caractrisant les

processus UP sont lis
33
Le processus unifi
Variantes UP
Il existe plusieurs variantes:
RUP: Rational Unified Process (IBM)
Version industrielle avec une panoplie doutils
UPEDU:
Version allge pour des environnements acadmiques
Toutes ces variantes:
laborent des modles qui seront interelis
ont des mcanismes dvaluation et dadaptation du
processus
Exigences et spcifications du logiciel -- RR - LOG3410 UPproc 07/30/11 Page /15

Un exemple de
bout en bout
Bas sur le cours de
M1 MIAGE - SIMA 2005-2006 / Yannick Pri -
Universit Claude Bernard Lyon 1
Pour mieux comprendre le procd

mais pas savoir faire
35
Exemple : liste initiale des besoins

Une chane d'htels a dcid de mettre sur le rseau un systme de rservation de
chambres ouvert tout client via un navigateur, et d'autre part elle veut automatiser la
gestion de ses htels. Un htel est gr par un directeur assist d'employs.
Pour rserver distance, aprs avoir choisi htels et dates, le client fournit un numro
de carte bleue. Lorsque le retrait a t accept (1h aprs environ), la rservation devient
effective et une confirmation est envoye par mail. Les clients sous contrat (agences de
voyage...) bnficient d'une rservation immdiate.
Le directeur de l'htel enregistre les rservations par tlphone. Si un acompte est reu
avant 72h, la rservation devient effective, sinon elle est transforme en option (toute
personne ayant pay a la priorit). Si la rservation intervient moins de 72h avant la
date d'occupation souhaite, le client doit se prsenter avant 18h.
Le directeur fait les notes des clients, peroit l'argent et met jour le planning
d'occupation effectif des chambres.
Une chambre est nettoye soit avec l'accord du client lorsqu'il reste plusieurs jours, soit
aprs le dpart du client s'il s'en va, et dans ce cas avant occupation par un nouveau
client. Les employs s'informent des chambres nettoyer et indiquent les chambres
nettoyes au fur et mesure. Pour cela les chambres vides nettoyer doivent tre
affiches, et les employs doivent pouvoir indiquer les chambres nettoyes de faon trs
simple. Un historique des chambres nettoyes par chaque employ est conserv un
mois. 36
Exemple : liste initiale des besoins

Une chane d'htels a dcid de mettre sur le rseau un
systme de rservation de chambres ouvert tout client via
un navigateur, et d'autre part elle veut automatiser la gestion
de ses htels. Un htel est gr par un directeur assist
d'employs.
....
Une chambre est nettoye soit avec l'accord du client lorsqu'il
reste plusieurs jours, soit aprs le dpart du client s'il s'en va,
et dans ce cas avant occupation par un nouveau client. Les
employs s'informent des chambres nettoyer et indiquent les
chambres nettoyes au fur et mesure. Pour cela les
chambres vides nettoyer doivent tre affiches, et les
employs doivent pouvoir indiquer les chambres nettoyes de
faon trs simple. Un historique des chambres nettoyes par
chaque employ est conserv37un mois.
Etude prliminaire
Apprhender les besoins fonctionnels
trouver les acteurs
partir des besoins
dlimiter le systme par rapport son environnement (systme = bote noire)
chercher qui interagit avec le systme (rles)
trouver les cas dutilisation
examiner comment chaque acteur interagit avec le systme pour que celui-ci
lui rende un service
regrouper les interactions similaires en cas dutilisation
dcrire brivement les cas dutilisation
construire le modle des cas dutilisation
les considrer dans leur ensemble
38
Ex : Etude prliminaire
Le systme dvelopper est divis en deux sous systmes indpendants :
- le systme de rservation distance et le systme de gestion local l'htel.
La base de donnes des rservations est considre comme un systme externe.
39
Etude prliminaire
Classer les cas dutilisation par priorit
la priorit dpend des risques associs au cas dutilisation et de
leur importance pour larchitecture, des ncessits de ralisation et
de tests
Exemple : classement des CU par importance
Les traitements trs classiques de la gestion locale

sont examiner en dernier (risque faible).
Les rservations (client ou grant) mettent en jeu
une architecture plus complexe et sont examiner en priorit :
Rservation (distante)
Rservation locale
Administration
...
40
Etude prliminaire
Dtailler et formaliser les cas dutilisation
Structurer le modle (rvision des cas si besoin)
Faire une maquette de linterface utilisateur
uniquement si linterface est complexe ou ncessite une valuation
par le client
Utilisateurs non spcialistes, interface simple et logique.
Problme classique, sans risque majeur, donc pas de

maquette.
41
Ex : Etude prliminaire
CU : Grer rservation par le grant
Acteur principal : Grant
Intervenants et intrts : Client, Chane htelire
Prconditions : une chambre est libre pour la priode
dsire
Scnario nominal
1. Le grant demande le planning d'occupation pour la
priode qui vient. Le systme affiche le planning sur plusieurs
semaines.
2. Le grant slectionne une chambre libre pour une date qui
lintresse. Le systme lui prsente le rcapitulatif de cette
chambre, et sa disponibilit quelques jours avant et aprs la
date choisie.
42
Ex : diagramme de squence systme

pour un scnario
43
Etude prliminaire
Apprhender les besoins non fonctionnels (contraintes sur le
systme : environnement, plate-forme, fiabilit, vitesse)
rattacher si possible les besoins aux cas dutilisation
description dans les descriptions des CU (section exigences
particulires pour UP)
sinon, dresser une liste des exigences supplmentaires
La chane possde 117 htels de 30 chambres en moyenne. Les appels sur le rseau
sont valus 300 par jour (au dbut, prvoir des volutions).
Pour des raisons d'extensibilit, de performances et de scurit, la chane de
traitement des rservations des clients doit tre indpendante des liaisons des
htels avec le systme de rservation. Les htels ne sont pas relis en permanence
au systme de rservation (conomie) et les postes devront tre fiables (coupures
de courant...).
Le temps dapprentissage du logiciel par les acteurs professionnels ne doit pas
dpasser une demi-journe.
Une socit tierce s'occupera de la maintenance
44
du systme et abritera les serveurs.
Elaboration
Objectif :
construction du modle danalyse pour prparer la conception
forme gnrale stable du systme, haut-niveau dabstraction
vision plus prcise et formelle des CU, ralisation par des objets
danalyse
passage du langage du client celui du dveloppeur
Analyse architecturale
identifier les paquetages danalyse (dcoupage en catgorie)
regroupement logique indpendant de la ralisation
relations de dpendances, navigabilit entre classes de paquetage
diffrents partir des CU et du domaine
point de dpart du dcoupage en sous-systmes
45
Ex : Organisation logicielle
Restitue les donnes lutilisateur et
transforme ses actions en vnements
de lapplication.
Reprsente les objets de
contrle et pilote les rgles Synch. des
de lapplication, y compris diffrents systmes
de rservations
les rgles dchanges entre
applications
Reprsente les objets du

mtier et implmente leur Restitue les
rgles de gestion. reprsentations
mtier partir des
donnes de stockages
Assure la persistance des

donnes
46
Ex : dcoupage en paquetages
47
Analyse architecturale (suite)

Identifier les classes entits manifestes (premier modle
structurel)
modle des 10-20 classes constituant lessence du domaine
3 strotypes de classe : frontire, contrle, entit
responsabilits videntes
Identifier les exigences particulires communes
distribution, scurit, persistance, tolrance aux fautes
les rattacher aux classes et cas dutilisation
48
Analyse architecturale (suite)
49
Activit : analyse (suite)

Analyse des cas d'utilisation
raffinement de tous les scnarios des cas d'utilisation
dcouverte des classes, attributs, relations, interactions
entre objets, et des besoins spciaux
identifier les classes, attributs et relations
examiner l'information ncessaire pour raliser chaque
scnario
ajouter les classes isolant le systme de l'extrieur
(interfaces physiques, vues externes des objets)
liminer les classes qui nen sont pas : redondantes,
vagues, de conception, etc.
50
3- Activit : conception
Propose une ralisation de l'analyse et des cas dutilisation en
prenant en compte toutes les exigences
Conception architecturale
identifier les noeuds et la configuration du rseau (dploiement), les sous-
systmes et leurs interfaces (modle en couche en gnral), les classes
significatives de l'architecture
Concevoir les cas d'utilisation
identifier les classes ncessaires la ralisation des cas ...
Concevoir les classes et les interfaces
... dcrire les mthodes, les tats, prendre en compte les besoins spciaux
Concevoir les sous-systmes
mettre jour les dpendances, les interfaces...
sous-systmes de service, lis lappli, de middleware
permettra de distribuer le travail
51
aux dveloppeurs
Exemple : diagramme de dploiement
Les deux serveurs et la BD des rservations peuvent tre sur un mme

noeud tant que les liaisons clients ne pnalisent pas les liaisons grants

52
Exemple : dcoupage en sous-systmes
53
4- Activit : ralisation
Mise en oeuvre architecturale
identifier les artefacts logiciels et les associer des noeuds
Intgrer le systme
planifier l'intgration, intgrer les incrments raliss
Raliser les sous-systmes
Raliser les classes
Faire les tests unitaires
tests de spcification en bote noire, de structure en bote
blanche
54
Bibliographie
UNIVERSITE PARIS XII -ISIAG , MASTER 2, METHODOLOGIE
ET CONDUITE DE PROJETS, CHAPITRE 3
Gnie Logiciel Orient Objets, Philippe Collet, Master 1 Informatique,
2007-2008
Processus de conception de SI M1 MIAGE - SIMA - 2005-2006 Yannick
Pri UFR Informatique - Universit Claude Bernard Lyon 1
Mthodes de conduite de projet, Tester, optimiser, structurer ses
applications Jean David Olekhnovitch, jd@olek.fr - www.olek.fr
Les cours IBM sur le RUP
Conduite de projet, Mthode danalyse et de conception, Processus
unifi, G. Picard, SMA/G2I/ENS Mines Saint-Etienne
gauthier.picard@emse.fr, Octobre 2009
Processus Unifi : www2.lifl.fr/~clerbout/.../Cours4-ProcessusUnifie.pdf
P. Colin,
55

Rup

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rup

Uploaded by

Copyright:

Available Formats

Processus Unifi

Unified Software Development Process /

Merci tous ceux qui ont rendu leurs cours et

Unified Process (UP)

(1997) UP : Rumbaugh, Booch, Jacobson (les concepteurs dUML)

Unified Software Development Process /

Unified Software Development Process /

- organis autour de 4 phases :

- dfini par 6 disciplines fondamentales :

Unified Software Development Process /

- organis autour de 4 phases :

- dfini par 6 disciplines fondamentales :

(3) Pilotage par les risques

Il ne faut pas confondre risque et problme.

(3) Pilotage par les risques

loccurrence est plus ou

Il ne faut pas confondre risque et problme.

Identifier les facteurs de risques

Plusieurs facteurs de risque peuvent contribuer lapparition dun

daprs Michel Winter 2008 / 2009 9

Analyser les risques

Gravit dune morsure de chat : faible

Unified Software Development Process /

- organis autour de 4 phases :

- dfini par 6 disciplines fondamentales :

Software architecture is not only concerned with structure and behavior,

A Technical Architecture is the minimal set of rules governing the

Quelques axes pour considrer

Unified Software Development Process /

- organis autour de 4 phases :

- dfini par 6 disciplines fondamentales :

Unified Software Development Process /

- organis autour de 4 phases :

- dfini par 6 disciplines fondamentales :

Pr-tude (Inception Phase): Objectifs

tablir la porte du projet et les conditions aux limites

Pr-tude (Inception Phase): Evaluation

Acceptation des parties prenantes sur la dfinition du champ

Pr-tude (Inception Phase): Evaluation

Acceptation des parties prenantes sur la dfinition du champ

Abandon du projet si pas de

Elaboration Phase: Objectifs

Dfinir et valider l'architecture de base

Description dArchitecture (1)

Donne une vue d'ensemble complte de l'architecture

Description dArchitecture (2)

Design Model Deployment Model

Elaboration Phase: Evaluation

Construction Phase: Objectifs

Produit : Premire version suffisamment stable et mature

Construction Phase: Evaluation

La version du produit est-elle assez stable et mre pour tre

Transition Phase: Objectifs

Prparation des activits

Transition Phase: Evaluation

Les utilisateurs sont-ils satisfaits ?

Itrations dans chaque Phase

Tous les critres caractrisant les

Exigences et spcifications du logiciel -- RR - LOG3410 UPproc 07/30/11 Page /15

jeudi 13 octobre 2011

Pour mieux comprendre le procd

Exemple : liste initiale des besoins

Exemple : liste initiale des besoins

Les traitements trs classiques de la gestion locale