Guiochet SupportCoursProcessusUnifie

Le Processus Unifi
Une Dmarche Oriente Modle
1
IUP NTIE - Master 1 - Jrmie Guiochet - 4/11/09
Sommaire
Partie 1 : UML et processus unifi
Partie 2 : Artefacts
Partie 3 : Enchanement ditrations
Partie 4 : Rles
(Partie 5 : Gestion de la configuration et des
changements)
M1 ICE - UP - J. Guiochet 2009-2010
PARTIE
Rappels et complments
UML / Processus Unifi
3
1
Unified Modeling Language
4
Les diagrammes dUML (UML1.5)
Diagramme dobjets
reprsente les objets et leurs relations
(correspond un diagramme de
collaboration simplifi, sans
reprsentation des envois de
messages).
Diagramme de classes
Reprsente la structure statique en
terme de classes et de relations.
Diagramme de composants
Reprsente les composants physiques
dune application.
Diagramme de dploiement
Reprsente le dploiement des composants
sur les dispositifs matriels.
Diagramme de cas dutilisation

Reprsente les objectifs en terme de
fonctionnalits du systme du point de vue de
lutilisateur.
10
Diagramme de squence
Reprsentation temporelle des objets et de
leurs interactions.
11
Diagramme de collaboration
Reprsentation spatiale des objets, des liens et
des interactions.
12
Diagramme dtats-transitions
Reprsente le cycle de vie dun objet
13
Diagramme dactivit
Reprsente un
enchanement
dactivits au sein
dune opration, dun
cas dutilisation ou
dun processus
mtier.
[PAM-00 p94]
14
Diagrammes dUML2.0
15
2
Les meilleures pratiques du
dveloppement logiciel
16
Dvelopper le logiciel
de faon itrative (1/2)
Risque
Analyse
des besoins
Conception
Codage
Tests
Temps
Le cycle de vie en cascade
17
Dvelopper le logiciel
de faon itrative (2/2)
Analyse des
besoins
Planification
Analyse et conception
Implmentation
Planification
initiale
Dploiement
Evaluation
Tests
Chaque itration a
pour rsultat une
version excutable
Un processus itratif et incrmental
18
Grer les exigences

Problmatiques
Modifications des exigences au cours du dveloppement
Identification et intgration de lensemble des besoins au
cours du processus
Propositions
Organiser et dcrire les fonctionnalits et les contraintes du
systme (compltude et cohrence)
Evaluer les changements apporter au cahier des charges
et estimer leur impact (modifiabilit)
Dcrire les diffrentes dcisions prises et en faire le suivi
(traabilit)
19
Utiliser des architectures

base de composants
Larchitecture repose sur des dcisions
concernant :
Lorganisation du systme
Les choix des lments structurels et de leurs
interfaces
Leur comportement
Leur composition en sous systmes
(Exemples : Composants Com, Corba, EJB, classes .Net, etc.)
20
Modliser
graphiquement le logiciel
Utilisation des diagrammes UML, et plus globalement
de la notion de modle.
Tout nest pas modle
Tout modle nest pas UML
21
Vrifier la qualit du logiciel

Fonctionnalits, fiabilit et performances
Tests (de benchmark , de configuration, de
fonctionnement, dinstallation, dintgrit, de
charge, de performance, de stress, )
Rapports de conception (ou revues)
22
Exercice
Dcrivez en quelques lignes
lorganisation du processus de
dveloppement de votre entreprise
(prcisez la taille des quipes de
dveloppement).
Dterminez si ce processus intgre
votre connaissance les cinq pratiques
vues prcdemment.
23
3
Lessentiel du
Processus Unifi
24
Quest ce que le Processus Unifi ? (1/3)

Le Processus Unifi ou UP (Unified Process) est une mthode
gnrique de dveloppement de logiciel dveloppe par les
concepteurs dUML
Gnrique signifie qu'il est ncessaire d'adapter UP au contexte du
projet, de l'quipe, du domaine et/ou de l'organisation.
Il existe donc un certain nombre de mthodes issues de UP comme par
exemple RUP (Rational Unified Process), 2TUP (Two Track Unified
Process)
Il existe dautres approches (qui ne sont en gnral pas compltement
antinomique), comme par ex. les mthodes agile , beaucoup moins
orientes modle, comme XP (eXtreme Programming)
25

Le processus unifi permet daffecter des
tches et des responsabilits au sein
dune organisation de dveloppement
logiciel
Approche discipline pour des gros projets
(chef de projet, analystes, intgrateur,
intervenants, etc.)
Approche adapter pour des petits projets
Pas particulirement conu pour le
dveloppement de systmes embarqus
26
Le processus unifi utilise le langage UML

Le processus unifi est pilot par les cas
dutilisation
Centr sur larchitecture
Itratif et incrmental
27
La structure logique du Processus

[Rational UP]
Phases
Lancement
(inception)
Elaboration
Construction
Transition
Modlisation
mtier
Recueil
des
besoins
Principales
activits du
processus
Analyse et
Conception
Implmentation
Tests
Gestion de
projet
Itr.Init
lab.
1
lab.
2
Cstr.1
Cstr.2
Tran1
Tran2
28
Les quatre phases

Phases
Lancement
(inception)
Elaboration
Construction
Transition
Modlisation
mtier
Recueil
des
besoins
Principales
activits du
processus
Analyse et
Conception
Implmentation
Tests
Gestion de
projet
Itr.Init
lab.
1
lab.
2
Cstr.1
Cstr.2
Tran1
Tran2
29
ressources
V1
Lancement
Elaboration
Construction
Transition
temps
Jalon 1 :
Objectifs dfinis
(livraison
interne)
Jalon 2 :
Architecture
dfinie
Jalon 3 :
Premire
livraison
externe (bta)
Jalon 4 :
Livraison
finale
Les Jalons correspondent des tapes dvaluation de la phase

termine, et de lancement de la phase suivante
30
5
Les enchanements dactivits
31
Vue gnrale
Phases
Lancement
(inception)
Elaboration
Construction
Transition
Modlisation
mtier
Recueil
des
besoins
Principales
activits du
processus
Analyse et
Conception
Implmentation
Tests
Gestion de
projet
Itr.Init
lab.
1
lab.
2
Cstr.1
Cstr.2
Tran1
Tran2
32
Gestion de projet
La gestion de projet est la mise en uvre de connaissances,
de ressources, de comptences, doutils et de techniques qui
permettent le lancement, la planification, la ralisation, le
pilotage et la clture dun projet dans un cadre temporel et
budgtaire, pour atteindre des objectifs prcis.
De nombreux aspects ne sont pas couverts dans cette
prsentation (gestion personnel, budget, contrats, etc.)
[Voir cours gestion de projet (D. Hck) qui couvre galement les
aspects Phases dun projet , Artefacts , et Rles ]
Objectifs
Planifier/valuer un projet itratif
Grer les risques
Contrler les progrs (dlais, cots, qualit, efforts, satisfaction
client, productivit, etc.)
33
Modlisation mtier
Comprhension de la structure et la
dynamique de l organisation
Comprendre les problmes poss dans
le contexte de l organisation
Conception d un glossaire
34
Recueil et expression des besoins

Auprs des clients et parties prenantes du projet
Ce que le systme doit faire
Expression des besoins dans les cas d utilisation
(exigences fonctionnelles)
Spcification des cas dutilisation en scnarios
Limites fonctionnelles du projet et exigences non
fonctionnelles (utilisabilit, fiabilit, performances)
Planification et prvision de cot
Ebauche de l IHM (prototypage et validation par
lutilisateur)
35
Transformation des besoins utilisateurs en modles
UML
Unified Modeling Language (pas une mthode mais
un langage )
Modle danalyse et modle de conception,
(ventuellement modle de donnes)
tape importante :
de lanalyse la conception : assigner des
responsabilits aux classes Les patrons
GRASP (General Responsability Assignment
Software Patterns) [Prsentation ultrieure]
36
Implmentation
Dveloppement incrmental
Dcoupage en couches
Composants darchitecture
Retouche des modles et des besoins
Units indpendantes, quipes diffrentes
37
Tests
Etapes (unitaire, dintgration, systme,
acceptation)
Types :
De benchmark (comparaison)
De configuration (diffrentes config matrielles et logicielles)
De fonctionnement (vrification des CU)
Dinstallation
Dintgrit (fiabilit, robustesse, rsistance)
De charge (conditions oprationnelles plus lourdes = nb
utilisateurs, transactions,)
De performance (en modifiant les configurations)
De stress (conditions anormales oprationnelles)
38
Exercice
Dcrivez en quelques lignes les phases
que vous suivez lorsque vous tes seul
dvelopper un logiciel.
Est ce que vous retrouvez certains
lments du Processus Unifi ?
Quels tests effectuez vous lorsque vous
dveloppez seul ?
39
PARTIE
Les artefacts*
(ou livrables, ou dlivrables)
*artificiel actis
40
Les artefacts
Elments produits lors du dveloppement
(documents, modles, fichiers compils,
composants, etc.)
Nous nous intresserons ici aux artefacts
de documentation et leur gestion
(cration, modification, livraison)
41
Prambule
Les parties des documents sont prsentes ici titre
dexemple.
Suivant la taille du projet, il faut tendre ou rduire ces
documents (voire les supprimer)
Dans tous les cas, les documents doivent tre mis
rgulirement jour, avec une gestion des changements
(tableau de mise jour dans len-tte de chaque doc)
42
Artefact ou pas ? Rgles de base
Objectif des artefacts : produire un meilleur logiciel

Trop dartefacts produit perte de temps, dispersion de lquipe,
augmentation des cots
Restez concentr sur le logiciel excutable
En cas de doute sur lopportunit dun artefact, abstenez vous
43
Template des documents

<nom du projet>
Nom du document
Version <1.0>
Historique des rvisions
Date
Version
Description
Auteur
<jj/mm/aa>
<x.x>
<details>
<name>
..
Sommaire
1.
Introduction
1.
2.
3.
2.
Objectifs
Dfinitions, acronymes, et abrviations
Rfrences
<Sections spcifiques au document>
44
Ensemble dartefacts
Lensemble de gestion
Lensemble des exigences
Lensemble de conception
Lensemble dimplmentation
Lensemble de dploiement
45
Lensemble de gestion de projet

Document de vision
Plan de dveloppement logiciel (planning des phases,rles,
responsabilits, jalons, activits)
Liste des risques

Planning ditration
tude de rentabilit
Points en suspens
Glossaire
Donnes sur des anomalies
46
Document de vision
[En-tte]
Sommaire
1. Problme
[motivations pour la cration du logiciel]
2. nonc de la vision
[description du concept du systme et intrts]
3. Principaux acteurs concerns

[acteurs du dveloppement et utilisateurs]
4. Caractristiques du logiciel
[liste des principaux CU, performances, etc.]
47
Exemple de sommaire du document de vision tendu

1.
2.
Introduction
1.1
Purpose
Product Overview
4.1
Product Perspective
1.2
Scope
4.2
Summary of Capabilities
1.3
Definitions, Acronyms, and Abbreviations
4.3
Assumptions and Dependencies
1.4
References
4.4
Cost and Pricing
1.5
Overview
4.5
Licensing and Installation
Positioning
2.1
Business Opportunity
2.2
3.
4.
5.
Problem Statement
Product Features
5.1
<aFeature>
5.2
<anotherFeature>
2.3
Product Position Statement
Stakeholder and User Description
6.
7.
Constraints
Quality Ranges
3.1
Market Demographics
8.
Precedence and Priority
3.2
Stakeholder Summary
9.
Other Product Requirements
3.3
3.4
User Summary
User Environment
9.1
9.2
Applicable Standards
System Requirements
3.5
Stakeholder Profiles
3.5.1 <Stakeholder Name>
9.3
Performance Requirements
9.4
Environmental Requirements
3.6
User Profiles
3.6.1 <User Name>
10. Documentation Requirements

10.1 User Manual
3.7
Key Stakeholder or User Needs
10.2
Online Help
3.8
Alternatives and Competition
10.3
Installation Guides, Configuration
10.4
Labeling and Packaging
3.8.1 <aCompetitor>
3.8.2 <anotherCompetitor>
48
Plan de dveloppement
Distribution dans le temps des ressources
humaines (rles et responsabilits) et matrielles
1.
2.
3.
Structure organisationnelle
Rles et responsabilits
Planning du projet
1.
2.
3.
4.
Planning des phases

Objectifs des itrations
Dlivrables
Dcoupage en phases, identification des jalons et objectifs des
itrations
Nb : Utilisation de tableaux, diagrammes (Gantt par ex. pour des projets

importants)
49
Liste des risques
1 <Identificateur de risque> [nom descriptif ou numro]

1.1
1.2
1.3
1.4
1.5
Niveau de risque
Description
Consquences
Indicateurs
Stratgie de traitement du risque
2 <Risque suivant>
[]
50
Exemples de risques projet
(source Ian Sommerville 2004)
Risk
Affects
Description
Staff turnover
Project
Experienced staff will leave the project before it is finished.
Management change
Project
There will be a change of organisational management with

different priorities.
Hardware unavailability
Project
Hardware that is essential for the project will not be

delivered on schedule.
Requirements change
Project and
product
There will be a larger number of changes to the

requirements than anticipated.
Specification delays
Project and
product
Specifications of essential interfaces are not available on

schedule
Size underestimate
Project and
product
The size of the system has been underestimated.
CASE tool underperformance
Product
CASE tools which support the project do not perform as

anticipated
Technology change
Business
The underlying technology on which the system is built is

superseded by new technology.
Product competition
Business
A competitive product is marketed before the system is

completed.
51
Risk identification
Technology risks.
People risks.
Organisational risks.
Requirements risks.
Estimation risks.
52
Risks and risk types

Risk type
Possible risks
Technology
The database used in the system cannot process as many transactions per second
as expected.
Software components that should be reused contain defects that limit their
functionality.
People
It is impossible to recruit staff with the skills required.

Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational
The organisation is restructured so that different management are responsible for

the project.
Organisational financial problems force reductions in the project budget.
Tools
The code generated by CASE tools is inefficient.

CASE tools cannot be integrated.
Requirements
Changes to requirements that require major design rework are proposed.

Customers fail to understand the impact of requirements changes.
Estimation
The time required to develop the software is underestimated.

The rate of defect repair is underestimated.
The size of the software is underestimated.
53
Planning ditration
[en-tte]
Sommaire
1. Planning
[Description temporelles des jalons intermdiaires, versions beta,
demos, etc.]
2. Ressources
[Matrielles, humaines, et financires]
3. Cas dutilisation
[C.U. et scnarios qui seront dvelopps dans cette itration]
4. Critres dvaluation
[Fonctionalits, performances, mesures de qualit, etc.]
54
Lensemble des exigences

Demandes des intervenants
Modle des CU
Spcifications supplmentaires
Modle mtier
55
Demandes des intervenants

Document permettant de noter et
rfrencer les demandes des intervenants
(dveloppeurs, sous-traitants, clients,
etc.), concernant des modifications
dexigences (fonctionnelles ou non)
Date / Nom / Description / Prise en compte
ou non
56
Modle des cas dutilisation

(Ensemble des fiches de C.U. et du diagramme des C.U.)
1.
2.
3.
4.
Nom
Rsum
Acteurs
Description des scnarios
1.
2.
5.
6.
7.
8.
Scnario nominal
Scnarios alternatifs
Pr conditions
Post conditions
Enchanements alternatifs (description textuelle ou tableau)
Autres spcifications :
1.
2.
Besoins dIHM, ergonomie

Robustesse, confidentialit, performances (temps de rponse, charge),
disponibilit, etc.
Action de lacteur
principal
Action du systme
Action de lacteur secondaire
1. action1
2. Rponse du systme et
traitement
3. Rception dune information
57
Spcifications supplmentaires
1.
2.
3.
Introduction
Fonctionnalits
6.
2.1 <Exigence fonctionnelle 1>
7.
8.
Contraintes de conception
6.1 <Contrainte 1>
Aide en ligne et systme daide
Composants achets
9.
Interfaces
Utilisabilit (anglicisme de
usability)
3.1 <Exigence dutilisabilit1>
4.
9.1
9.2
9.3
9.4
Sret de fonctionnement
4.1 <Exigence SdF 1>
5.
Performance
5.1 <Exigence de performance 1>
Interfaces utilisateur
Interfaces matrielles
Interfaces logicielles
Interfaces de communication
11.
Exigences de licence
12.
13.
Copyright
Normes applicables
58
Modle mtier
Diagramme de classes mtier
Diagramme de C.U. mtier
Diagramme dactivits mtier
59
Lensemble de conception
Modle de conception (Diagrammes UML)
Description de larchitecture (privilgier un
reprsentation graphique UML ou non)
Plan de test
Cas de test
60
Plan de test
1. lments cibls par les tests
2. Vue densemble des tests
planifis
2.1 Descriptif des test inclus
dans le plan de dev.
2.2 Descriptif des autres tests
exclus du plan de dev.
2.3 Descriptif des tests
candidats une inclusion
dans le plan de dev.
3. Types et techniques de test

3.1 Test dintgrit
3.2 Test fonctionnel
3.3 Test de benchmark
3.4 Test de linterface graphique
3.5 Test de performance
3.6 Test de charge
3.7 Robustesse
3.8 Test de stress
3.9 Test de scurit et de contrle
daccs
3.11 Test de configuration
3.12 Test dinstallation
Il faut documenter les tests envisags pour lapplication

61
Plan de test
Objectifs de la
technique :
[Description des objectifs]
Technique:
[Description de la technique utilise, par ex.

Excuter chaque scnario et vrifier que ]
Oracles:
[Stratgies utilises par la technique pour

observer prcisment le succs ou la dfaillance
du test]
Outils requis :
[Besoins en terme de scripts, fichiers de log,

etc]
Critre de succs :
[Condition pour que lensemble du test soit

positif]
Considerations
particulires :
[Contraintes lies au type de test,

recommandations, remarques, etc]
62
Cas de test
Cas de test : <Nom du cas de test>
Numro didentification : <Identifiant>
Catgorie : <Catgorie de cas de test>
[Les valeurs possibles de catgorie sont Fonctionnel et Performance]

1.
Introduction
[Cette section dcrit brivement le rle et lobjectif du Cas de Test]

2.
Enchanement des vnements
[Dcrire les tapes que le testeur doit suivre. Les rponses (R) sont les rsultats attendus par le test.]
1.
tape 1
R.
2.
Rponse 1.
tape 2
R.
3.
tape 3
R.
3.
Rponse 2
Rponse 3
Besoins techniques
[Besoins techniques lis ce cas de test, par. Ex. un simulateur denvironnement, une machine sous
windowsNT, etc.]
3.1 < Premier besoin >
[]
63
Lensemble dimplmentation
Le code source et les excutables

Les fichiers de donnes associs (par ex.
Javadoc) ou les fichiers permettant de les
produire
64
Lensemble de dploiement
Scripts et guide dinstallation

Documentation utilisateur
Matriel de formation
65
Partie 3
Les enchanements
ditration
66
Phase de lancement
Phases
Lancement
(inception)
Elaboration
Construction
Transition
Modlisation
mtier
Recueil
des
besoins
Principaux
enchanements
du processus
Analyse et
Conception
Implmentation
Tests
It#1
67
Phase de lancement (inception) (1/4)

Comprendre le systme construire
(vision gnrale et limites du projet)
Recueillir les besoins utilisateurs
Spcifier les principaux cas d utilisation et scnarios
Dfinir une architecture candidate
Evaluer les cots et planning
Les principaux risques
68
Phase de lancement
Comprendre les objectifs et la porte du projet
Objectifs :
1.
2.
3.
4.
Comprendre le systme construire

Identifier la fonctionnalit principale du systme
Dterminer au moins une solution possible
Dcider du processus appliquer et des outils
utiliser
Nb : en gnral une seule itration, sauf pour projets

importants, innovants, ou trs risqus
69
Objectif 1 : Comprendre le systme

Produire une vision (artefact:document de vision), i.e.
opportunits apportes par lapplication, les utilisateurs
cibles, quelques cas dutilisation cls (un ou deux),
certains besoins non fonctionnels (artefact:spcifications
supplmentaires)
Gnrer une description large et superficielle

(brainstorming, identification des acteurs et des C.U.
principaux (artefact: modle des C.U.), dcrire les C.U.,
crer un artefact:glossaire et/ou un artefact:modle mtier,
dvelopper des proto dinterface jetables)
70
Objectif 2 : Identifier la fonctionnalit

essentielle du systme
Collaboration chef de projet, architecte, et
client (artefact: demandes des intervenants) pour
dterminer les C.U. les plus critiques
La fonctionnalit est le noyau de lapplication
Elle DOIT tre livre
71
Objectif 3 : Dterminer au moins une

solution possible
Architecture (client-serveur, centralise,
distribue, etc.)
Technologies utilises (ventuellement
faire des tests dimplmentation pour
estimer les risques lis une technologie)
72
Objectif 4 : Comprendre les cots, les

dlais et les risques
Examiner la faisabilit du projet (tude
de rentabilit, artefact: liste des risques)
tablir le plan du projet (artefact : plan de
dveloppement du logiciel)
73
Objectif 5 : Dcider du processus

appliquer et des outils utiliser
Faire des choix :
Processus de dveloppement
Outils de dveloppement
Complter le plan de dveloppement avec les
choix, mettre jour liste de risques, cots et
dlais
74
Revue de projet : Jalon fin de

lancement
Les diffrents intervenants valident:
le primtre du projet, cots et dlais
la liste des exigences
Les risques initiaux sont identifis et il existe une

stratgie de rduction pour chacun deux
Lensemble des artefacts produit est complet,
jour et cohrent
Lancement
Elaboration
Construction
Transition
75
Exercice : Lister ci dessous lensemble des artefacts

produits pendant la phase de lancement
76
Phase dlaboration
Phases
Lancement
(inception)
Elaboration
Construction
Transition
Modlisation
mtier
Recueil
des
besoins
Principaux
enchanements
du processus
Analyse et
Conception
Implmentation
Tests
ItElab1
ItElab2
77
Phase dlaboration
(2/4)
Modle des cas dutilisation complet

Exigences supplmentaires
(non fonctionnelles et celles qui ne sont pas
associes des c.u.)
Raffiner l architecture logicielle
Un prototype architectural excutable
Un manuel utilisateur prliminaire
78
La phase dlaboration
Construction dun squelette darchitecture en
intgrant les risques majeurs et affiner les
plans de projet
Objectifs :
1. Comprendre en dtail les exigences
2. Concevoir, implmenter, valider larchitecture
3. Rduire les risques essentiels et estimer plus
exactement le budget
4. Affiner le plan de dveloppement
NB: en gnral une trois itrations (artefact : plan ditration)
79
Objectif 1 : comprendre les

exigences en dtail
Mettre jour tout au long de cette phase :
Le modle des C.U. (certains C.U. trs simples
et ne prsentant aucun risque ne doivent pas
tre formaliss)
Le glossaire
Hirarchiser et faire des packages de C.U.
80
Objectif 2 : Concevoir, implmenter,

et valider larchitecture
Architecture: dfinir les sous-systmes, les composants, et leurs
interfaces (utiliser au maximum des frameworks darchitecture)(artefact :
description de l'architecture)
Dterminer les C.U. significatifs du point de vue architectural
Concevoir les C.U. critiques
Regrouper en packages les classes identifies (artefact : modle de
conception)
Rvaluer la couverture architecturale par les scnarios critiques
Concevoir la base de donnes
Dcrire la concurrence, les processus, les threads, et la distribution
physique
Identifier les patterns
Implmenter et tester les scnarios critiques (artefact : plan de test, cas
de test)
81
Objectifs 3 & 4
Rduire les risques essentiels et estimer au mieux les dlais et

cots et raffiner le plan de dveloppement
Utiliser toutes les informations provenant des activits de conception
pour mettre jour les risques, dlais et cots.
82
Revue de projet : jalon fin

dlaboration
valuer :
Stabilit vision et exigences
Stabilit architecture
Crdibilit du plan ditration
En cas de doute : refaire une itration
Lancement
Elaboration
Construction
Transition
83
Phase de construction
Phases
Lancement
(inception)
Elaboration
Construction
Transition
Modlisation
mtier
Recueil
des
besoins
Principaux
enchanements
du processus
Analyse et
Conception
Implmentation
Tests
Cstr1
Cstr2
84
Phase de construction
(3/4)
Gestion des ressources matrielles

(installation sur plateformes choisies)
Optimisation du processus pour rduire les cots de
dveloppement
Amliorer la qualit
Complter les modles suivant les besoins d implmentation
Produit : le logiciel install sur les plate-formes choisies, les
manuels dutilisation, description de la version mise en place
85
La phase de construction
Phase concentre sur la conception,
limplmentation et les tests
Objectifs :
1. Minimiser les cots de dveloppement et
obtenir un certain degr de paralllisme
2. Dvelopper de faon itrative un logiciel prt
la transition vers les utilisateurs
NB : mme pour de petits projets, il faut plusieurs

itrations (entre 2 et 4)
86
Objectif 1 : Minimiser les cots de

dveloppement et obtenir un certain
degr de paralllisme
Sorganiser autour de larchitecture
Gestion de la configuration
Gestion des demandes de changement
Appliquer larchitecture
Assurer une progression continue
87
Objectif 2 : Dvelopper de faon itrative

un logiciel prt la transition vers les
utilisateurs
Dcrire les C.U. restants et les spcifications
supplmentaires
Terminer la conception
Concevoir la base de donnes
Coder et excuter les tests unitaires
Effectuer les tests dintgration et systme
Premiers dploiements et boucle de rtroaction
88
Revue de projet : le jalon fin de

Construction
valuation :
Version du logiciel est elle stable ?
Tous les intervenants sont prts ?
Dpenses relles/prvisionnelles acceptables ?
Lancement
Elaboration
Construction
Transition
89
Phase de transition
Phases
Lancement
(inception)
Elaboration
Construction
Transition
Modlisation
mtier
Recueil
des
besoins
Principaux
enchanements
du processus
Analyse et
Conception
Implmentation
Tests
90
Phase de transition
(4/4)
Dployer
Tester
Valider (rponse aux attentes des utilisateurs)
Accompagner lutilisateur final (packaging,
documentation, formations, manuels )
91
Phase de transition
Objectifs :
Excuter les tests bta
Former les utilisateurs
Prparer le site de dploiement
Prparer le lancement
Obtenir laccord des intervenants
Amliorer les performances futures
92
Revue de projet : Jalon Fin de la

Transition
valuation :
Satisfaction des utilisateurs
Bilan sur les ressources rellement
consommes
Lancement
Elaboration
Construction
Transition
93
Bibliographie
P. Kroll et P. Kruchten, Guide pratique du RUP,
CampussPress, 2003
P. Kruchten, Introduction au Rational Unified Process,
Eyrolles, 2000
Craig Larman, Applying UML and patterns - An
introduction to object oriented analysis and design
and the Unified Process, Prentice Hall, 2004
Exemple de projet entirement RUP : http://
jdbv.sourceforge.net/
94
PARTIE
Les rles
95
Les rles
Chef de projet
Analyste
Architecte
Dveloppeur
Testeur
[]
96
Le chef de projet
Responsable de la gestion de projet
Individu ou quipe ?
Plan de dveloppement (plan de projet, plan ditration, risques)
Plan de gestion de la configuration
Choisir les artefacts UTILES
Adapter les artefacts au projet
Collaborer avec tous les autres acteurs
Constamment focalis sur les risques
97
Activits du chef de projet dans le

RUP
98
Lanalyste
Activits : Modlisation mtier, Exigences, Analyse et
conception
Dvelopper une Vision
Liste des fonctionnalits
Modle de C.U., Glossaire, Prototype interface
utilisateur, Spcifications Supplmentaires
Vrifier que les exigences sont respectes et testes
99
Activits de lanalyste dans le RUP
100
Larchitecte
Coordonne les artefacts techniques
Communication entre les quipes de
dveloppement
Choix dune architecture en fonction :
performance, robustesse, rutilisation, comprhensibilit,

modularit, contraintes techniques, sret de fonctionnement
Document darchitecture
Validation par le prototype architectural
101
Activits de larchitecte dans le RUP
102
Le dveloppeur
Activits :
Implmentation
Conception des ralisations des C.U.

Conception des tests
103
Activits du dveloppeur dans le

RUP
104
Le testeur
Activits en fonction des phases :
Lancement : test des ides des technologies
possibles
laboration : test architecture (notamment
performance, volutivit, etc.)
Construction : test fonctionnel
Transition : robustesse, ergonomie, etc.
105
PARTIE
La gestion de la configuration
et des changements pour un
travail collaboratif
106
Objectifs de la gestion de la
configuration et des changements
Garder la trace de tous les lments tangibles
qui participent aux dveloppement (artefacts)
Suivre leur volution
Participer de manire collaborative leur
cration/modification
107
Gestion de la configuration
Gestion des versions :
gestion des sources et des espaces de travail
(numroter les versions dartefacts, garder un
historique, possibilit de retour)
CVS, Subversion, etc.
Gestion de configuration
Gestion des dpendances : entre artefacts
(par exemple des fichiers java)
PVCS, Perforce, etc.
Liste de logiciels : http://fr.wikipedia.org/wiki/

Logiciel_de_gestion_de_versions
108
Gestion des changements

Traiter les modifications du systme
sollicites par les intervenants
Analyser les consquences
Suivre les demandes jusqu leur
accomplissement
109
Enchanement dactivits
1. Le chef de projet tablit les procdures de gestion
de la configuration
2. Le responsable de la configuration ( partir du plan
darchitecture logicielle) cre et alloue les espaces
de travail aux dveloppeurs
3. Les dveloppeurs modifient les artefacts de leur
espace de travail, ils soumettent des demandes de
changement
4. Lquipe tablit les impacts/cuts/etc. et approuve
ou non les demandes
5. Les modifications sont intgres et testes
110
Dfinition des espaces de travail des

dveloppeurs
Rpartition structurelle:
Par package / sous-systme
Rpartition dynamique:
Par C.U. / scnarios
Deux approches :
criture exclusive
criture partage
Le choix des approches de rpartition des espaces
de travail et dcriture dpendent des projets (et
notamment de la taille du logiciel et du nombre de
dveloppeurs)
111
Problmes inhrents la gestion de

configuration
Systmes centraliss (type cvs) :
Pas de gestion locale des versions
Attendre davoir une version compilable pour un
commit est parfois long
Technique du merge peu fiable
Pas de vrification de dpendance

Solutions en cours de dveloppement (git)
112

Guiochet SupportCoursProcessusUnifie

Uploaded by

Document Information

Original Title

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

Guiochet SupportCoursProcessusUnifie

Uploaded by

Copyright:

Available Formats

Le Processus Unifi

Une Dmarche Oriente Modle

M1 ICE - UP - J. Guiochet 2009-2010

Les diagrammes dUML (UML1.5)

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

Diagramme de cas dutilisation

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

Un processus itratif et incrmental

M1 ICE - UP - J. Guiochet 2009-2010

Grer les exigences

M1 ICE - UP - J. Guiochet 2009-2010

Utiliser des architectures

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

Vrifier la qualit du logiciel

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

Quest ce que le Processus Unifi ? (1/3)

M1 ICE - UP - J. Guiochet 2009-2010

Quest ce que le Processus Unifi ? (2/3)

M1 ICE - UP - J. Guiochet 2009-2010

Quest ce que le Processus Unifi ? (3/3)

Le processus unifi utilise le langage UML

M1 ICE - UP - J. Guiochet 2009-2010

La structure logique du Processus

M1 ICE - UP - J. Guiochet 2009-2010

Les quatre phases

M1 ICE - UP - J. Guiochet 2009-2010

Les Jalons correspondent des tapes dvaluation de la phase

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

Recueil et expression des besoins

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

Artefact ou pas ? Rgles de base

Objectif des artefacts : produire un meilleur logiciel

M1 ICE - UP - J. Guiochet 2009-2010

Template des documents

<Sections spcifiques au document>

M1 ICE - UP - J. Guiochet 2009-2010

M1 ICE - UP - J. Guiochet 2009-2010

Lensemble de gestion de projet

Liste des risques

M1 ICE - UP - J. Guiochet 2009-2010

3. Principaux acteurs concerns