III. Le Processus Unifié
1. Présentation
Le Processus Unifié (PU ou UP en anglais pour Unified
Process) est un processus de développement défini pour prendre en
compte les meilleures pratiques. Il prend en charge le cycle de vie du
logiciel. C'est une méthode générique qui respecte les
spécifications d'UML (itérative et incrémentale,
guidée par les besoins des utilisateurs et centrée sur
l'architecture logicielle) et vient compléter la systémique de
ses modèles. Son caractère « générique »
constitue un de ses atouts essentiels car il donne la possibilité au
concepteur d'adapter la méthode à son domaine, son cas, ses
réalités, possibilité que nous ne manquerons pas
d'exploiter.
Les utilisateurs peuvent corriger, grâce aux
prototypes, la tournure du développement. Dès le début,
des résultats tangibles sont obtenus. Si les besoins des utilisateurs
changent en cours de développement, cette évolution peut
être, dans une certaine mesure, intégrée.
Le PU distingue cinq (5) activités que sont : les
spécifications, l'analyse, la conception, l'implémentation et les
tests. Il prévoit un cycle de vie où les itérations sont
regroupées en catégories d'activités. Ces
catégories sont soit initiales (création), soit
intermédiaires (élaboration, construction) soit finales
(transition vers l'utilisateur ou mise en production). Il est évident
qu'en phase de création, une plus grande partie du temps sera
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 42
consacrée à l'analyse des besoins qu'aux tests
; inversement, en phase de transition, les tests sont encore en cours alors que
l'analyse des besoins et son raffinage sont théoriquement bouclés
depuis la phase de construction.
Figure 3.2 : Cycle de vie du Processus
Unifié
Faisons une description des activités et phases (axes
vertical et horizontal) du PU.
2. Les activités
? L'expression des besoins
Il s'agit d'identifier les acteurs, de recenser les besoins
fonctionnels qui conduisent à l'élaboration des modèles de
cas d'utilisation et affiner ces modèles, de définir les besoins
non fonctionnels et livrer une liste des exigences. Le modèle de cette
activité présente le système du point de vue de
l'utilisateur et représente, sous forme de cas d'utilisation et
d'acteurs, les besoins exprimés. PU étant très axé
sur ces besoins, cette activité est essentielle pour la réussite
des autres.
? L'analyse
Elle permet d'identifier les classes et les attributs, de
réaliser les cas d'utilisation, de structurer le modèle par la
spécification d'interfaces. Son objectif est d'accéder à
une compréhension des besoins et des exigences. Son modèle livre
une spécification complète des besoins afin de les structurer
sous une forme qui facilite la compréhension, la préparation
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 43
(architecture), la modification et la maintenance du futur
système. Il s'écrit dans le langage des développeurs et
peut être considéré comme une ébauche du
modèle de conception.
? La conception
Il s'agit d'identifier les classes manquantes, de choisir les
algorithmes en cas de besoin, de décomposer les éléments
en vue du déploiement. Elle permet d'acquérir une
compréhension des contraintes liées au langage de programmation,
à l'utilisation des composants et au système d'exploitation. Elle
définit la structure statique du système sous forme de sous
systèmes et constitue un point de départ à l'implantation
en créant une abstraction transparente de celle-ci.
? L'implémentation
C'est le résultat de la conception pour
réaliser le système sous forme de composants : codes sources,
scripts, exécutables et d'autres éléments du même
type. On y choisit le langage. Ses objectifs principaux sont la planification
de l'intégration des composants pour chaque itération, la
production des classes sous forme de codes sources.
? Les tests
Ils permettent de vérifier des résultats de
l'implémentation en testant la construction. Pour mener à bien
ces tests, il faut les planifier pour chaque itération (les
hiérarchiser), les implémenter en créant des cas de tests,
les effectuer et prendre en compte le résultat de chacun d'eux. Des
règles de validation doivent être définies.
|