Chapitre 4 : Le processus unifié (UP)

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

• Le processus de développement UP, associé à UML, met

en œuvre les principes suivants :
– processus guidé par les cas d’utilisation,
– processus itératif et incrémental,
– processus centré sur l’architecture,
– processus orienté par la réduction des risques.
• Ces principes sont à la base du processus unifié décrit par
les auteurs d’UML.

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.

• Les cas d’utilisation permettent d’exprimer les interactions

du système avec les utilisateurs, donc de capturer les
besoins.

• Le développement peut se décomposer par cas d’utilisation.

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 )

• Les risques sont évalués et traités au fur et à

mesure des itérations,
• Les premières itérations permettent d’avoir un
feed-back des utilisateurs,
• Les tests et l’intégration se font de manière
continue,
• Les avancées sont évaluées au fur et à mesure de
l’implémentation.
7
 Processus centré sur l’architecture
• Les auteurs d’UP mettent en avant la préoccupation de
l’architecture du système dès le début des travaux
d’analyse et de conception,

• Il est important de définir le plus tôt possible, même à

grandes mailles, l’architecture type qui sera retenue pour
le développement, l’implémentation et ensuite le
déploiement du système.

• Le vecteur des cas d’utilisation peut aussi être utilisé

pour la description de l’architecture.
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.

• Il est important de bien évaluer les risques des

développements afin d’aider à la bonne prise de décision.

• Du fait de l’application du processus itératif, UP contribue

à la diminution des risques au fur et à mesure du
déroulement des itérations successives.
9
 Concepts et schéma d’ensemble
• Le processus unifié décrit qui fait quoi, comment et quand
les travaux sont réalisés tout au long du cycle de vie du
projet. Quatre concepts d’UP répondent à ces questions :
– Rôle (qui ?)
– Activité (comment ?)
– Artefact (quoi ?)
– Workflow (quand ?)

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.

• Le rôle doit être considéré en termes de « casquette » qu’une

ressource peut revêtir sur le projet.

• Une ressource peut jouer plusieurs rôles sur le projet

• Par exemple sur un projet, Paul peut être à la fois chef de
projet et architecte.

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