Académique Documents
Professionnel Documents
Culture Documents
Chapitre 4 - UP 1
Chapitre 4 - UP 1
1
Le processus unifié
• UML est un langage de modélisation et n’impose
pas de démarche de développement
• Le processus unifié : méthodologie de
développement
– basée sur un cycle de vie itératif et incrémental
– axe temporel : phases et itérations
– axe vertical : activités
2
PRÉSENTATION D’UP
3
Processus guidé par les cas
d’utilisation
• L’orientation forte donnée ici par UP est de montrer que le
système à construire se définit d’abord avec les utilisateurs.
4
Processus itératif et incrémental
• Ce type de démarche étant relativement connu dans
l’approche objet, il paraît naturel qu’UP préconise
l’utilisation du principe de développement par itérations
successives.
• Concrètement, la réalisation de maquette et prototype
constitue la réponse pratique à ce principe.
• Le développement progressif, par incrément, est aussi
recommandé en s’appuyant sur la décomposition du
système en cas d’utilisation.
5
Le cycle itératif incrémental
Planification
de l’itération
Risques initiaux,
portée du projet Développement de
l’itération
Itération N
Évaluation
Révision du
plan du projet
Risques éliminés
Révision des risques
6
Avantages (développement itératif )
8
Processus orienté par la réduction
des risques
• Processus orienté par la réduction des risques L’analyse des
risques doit être présente à tous les stades de développement
d’un système.
10
Rôle
• Un rôle définit le comportement et les responsabilités d’une
ressource ou d’un groupe de ressources travaillant en équipe.
11
Activité
• Les rôles ont des activités qui définissent le travail qu’ils effectuent.
• Une activité est une unité de travail qu’une ressource, dans un rôle
bien précis, peut effectuer et qui produit un résultat dans le cadre du
projet.
• L’activité a un but clairement établi, généralement exprimée en
termes de création ou de mise à jour d’artefacts, comme un modèle,
une classe ou un planning.
• Les ressources sont affectées aux activités selon leurs compétences et
leur disponibilité.
• Par exemple, les activités « planifier une itération » et « anticiper les
risques » sont attribuées au rôle de chef de projet.
12
13
Artefacts
• Un artefact est un ensemble d’informations qui est produit,
modifié ou utilisé par le processus.
• Les artefacts sont les produits effectifs du projet.
• Les artefacts sont utilisés comme input par les ressources
pour effectuer une activité et sont le résultat d’output
d’activités du processus.
• Un exemple d’artefacts rencontrés au cours du projet est un
planning d’une itération ou un diagramme produit dans une
activité
14
Workflows
• Une énumération de tous les rôles, activités et artefacts ne
constitue pas un processus.
• Il est nécessaire d’avoir une façon de décrire des séquences
d’activités mesurables qui produisent un résultat de qualité et
montre l’interaction entre les ressources.
• Le workflow est une séquence d’activités qui produit un
résultat mesurable.
• En UML, il peut être exprimé par un diagramme de séquence,
un diagramme de communication ou un diagramme d’activité.
15
Schéma d’ensemble
• UP peut être décrit suivant deux dimensions traduites en
deux axes :
– Un axe horizontal représentant le temps et montrant l’aspect
dynamique du processus. Sur cet axe, le processus est organisé
en phases et itérations.
– Un axe vertical représentant l’aspect statique du processus. Sur
cet axe, le processus est organisé en activités et workflows.
16
Schéma d’ensemble
17
Les activités
• Analyse
• Conception
• Réalisation
• Tests
• Maintenance
• Planification
• Gestion des changements
• ...
18
Les phases
• Étude d’opportunité
– plan marketing, prototype exécutable
• Élaboration
– modèle des cas d’utilisation, choix d’architecture
• Construction
– prototypes, plan de déploiement, version bêta
• Transition
– jusqu’à la version définitive
19
Étude d’opportunité
• Vision = Quoi + Pour qui + Combien
– les grandes lignes du produit
– la population cible
– combien l’acheteur serait prêt à payer
• Estimation des coûts
• Prototype
• petit projet : cahier de charges
• durée pour un projet moyen (un an) : un mois
20
Élaboration
• Analyse des besoins => architecture du
produit
• descriptions des cas d’utilisations, des scénarios
principaux, un modèle des classes (quelques dizaines de
CU, une centaine de scénarios principaux et quelques centaines de
scénarios secondaires, cinquante à cent classes)
• architecture du logiciel
• plan détaillé des itérations
• durée : 2-4 mois pour un projet d’un an
21
Construction
• Identification des scénarios à compléter au
cours de l’itération, en fonction des risques
• Affectation de tâches précise à l’équipe
• Définition des critères d’évaluation de
l’itération, des points de contrôle et des
délais
• Rédaction des documents pour l’utilisateur
• durée : 6-9 mois
22
Transition
• Pour l’utilisateur
– programmes (version bêta, puis définitive)
– documents (utilisation, installation)
• Pour le responsable du projet
– modèles révisés
– critères d ’évaluation des itérations
– description des livraisons
– résultats de l ’assurance qualité
• durée : un mois
23
Itération Phase Objectif Décision
Itération Etude d’opportunité Comprendre le
préliminaire problème
Ressources pour
l’élaboration
Itération Elaboration Comprendre la
d’architecture solution
…xN … …
Ressources pour la
construction
Itération de Construction Réaliser la solution
développement
…xN … …
Livrer le produit
(version bêta)
Itération de Transition Transmettre la
transition solution
…xN … …
Recette client
24
Petits projets
• Étude d’opportunité => cahier de charges
• Élaboration
– cas d’utilisations + scénarios (textuels, diagrammes de séquences)
=> validation
– diagrammes de collaborations, diagramme de classes, …
• Construction
– diagramme de classes => squelette de l’application, puis codage et
tests
• Transition
– livraison, tests, maintenance
25
Activités du processus
• Expression des besoins :
• UP propose d’appréhender l’expression des besoins en se
fondant sur une bonne compréhension du domaine
concerné pour le système à développer et une
modélisation des procédures du système existant.
• UP distingue deux types de besoins : •
– les besoins fonctionnels qui conduisent à l’élaboration des cas
d’utilisation,
– les besoins non fonctionnels (techniques) qui aboutissent à la
rédaction d’une matrice des exigences.
26
Activités du processus
• Analyse :
• L’analyse permet une formalisation du système à
développer en réponse à l’expression des besoins
formulée par les utilisateurs.
• L’analyse se concrétise par de tous les diagrammes
donnant une représentation du système tant statique
(diagramme de classe principalement), que dynamique
(diagramme des cas d’utilisation, de séquence,
d’activité, d’état-transition…).
27
Activités du processus
• Conception :
• La conception prend en compte les choix d’architecture
technique retenus pour le développement et l’exploitation
du système.
• La conception permet d’étendre la représentation des
diagrammes effectuée au niveau de l’analyse
28
Activités du processus
• Implémentation :
• Cette phase correspond à la production du logiciel sous
forme de composants, de bibliothèques ou de fichiers.
• Cette phase reste, comme dans toutes les autres méthodes, la
plus lourde en charge par rapport à l’ensemble des autres
phases.
29
Activités du processus
• Test :
• Les tests permettent de vérifier :
– la bonne implémentation de toutes les exigences
(fonctionnelles et techniques),
– le fonctionnement correct des interactions entre les
objets,
– la bonne intégration de tous les composants dans le
logiciel.
Classiquement, différents niveaux de tests sont réalisés dans cette activité :
test unitaire, test d’intégration, test de réception, test de performance et
test de non régression.
30