Unified Process - Définition

Introduction

Processus unifié (PU ou UP en anglais pour Unified Process) est une méthode de prise en charge du cycle de vie d’un logiciel et donc du développement, pour les logiciels orientés objets. C’est une méthode générique, itérative et incrémentale, contrairement à la méthode séquentielle Merise (ou SADT).

PU vient compléter la systémique des modèles UML. Elle est le résultat final d’une évolution de l’approche d’Ericsson qui est au fondement d’une des premières méthodes de développement pour applications orientées objets, la méthode Objectory Process (1987). Objectory Process (version 1 à 3.8 en 1995) a elle-même servi de base à la société Rational pour la création de Rational Objectory Process (1997) (version 4.1), parente direct de RUP en 1998.

Abréviations utilisées

• PU : Processus unifié, désigne les préceptes généraux de la méthode.
• UP : Unified Process, la dénomination anglaise.
• RUP : Rational Unified Process, Instanciation par Rational Software (IBM) des préceptes UP.
• EUP : Enterprise Unified Process, Instanciation intégrant les phases de post-implantation et décrivant le cycle de vie du logiciel.
• XUP : Extreme Unified Process, Instanciation hybride intégrant UP avec Extreme Programming.
• AUP : Agile Unified Process, partie des préceptes UP permettant l’agilité du développement, instanciation partielle de la méthode mettant l’accent sur l’optimisation et l’efficience sur le terrain plus que sur le modèle théorique.
• 2TUP : Two Tracks Unified Process, Instanciation de UP proposé par Valtech prenant en compte les aléas et contraintes liées aux changements perpétuels et rapides des SI des entreprises.
• EssUP : Essential unified process, par Ivar Jacobson, initiateur d'UML et RUP, entre autres. À travers sa société Ivar Jacobson Consulting, Ivar propose une mouture du processus unifié qui intègre certains concepts de la méthode Agile et des idées des partisans de Process Improvement. Ivar travaille aujourd'hui pour Microsoft afin d'intégrer EssUP aux outils de travail collaboratifs de la firme (Visual Studio Team System).
• DCU : Diagramme de cas d’utilisation, modèle UML considéré comme fondamental dans PU.
• Méthode agile : Agile Modeling, tentative de formalisation et d’inventaires des préceptes décrivant l’agilité en matière de développement applicatif.

Note : On utilisera les abréviations par commodité. On utilisera de préférence les sigles sous la forme de leur traduction française lorsqu’on parle des concepts génériques ou de méthodes non instanciées. À l’inverse, on gardera la terminologie anglo-saxonne pour parler des instances.

Fonctionnement

Le pilotage par les diagrammes de cas d'utilisation (DCU) revêt une signification concrète : des DCU, on doit tirer les modèles d’analyse, de conception, de déploiement. Ce sont eux qui sont implantés et ce sont les cas d’utilisation prévus qui vont présider à l’élaboration des lignes de tests : les cas d’utilisation doivent au final être permis par le nouveau logiciel. Les DCU sont les modèles garantissant la cohérence du processus du développement. Ce sont eux qui unifient. Enfin les DCU sont, de par leur nature, intrinsèquement liés à l’architecture du système.

Celle-ci est conçue dès le départ de façon très pragmatique : elle est adaptée au contexte de travail, aux besoins de l’utilisateur, aux possibilités de réutilisation (re-use) de bibliothèques ou de « briques » préexistantes.

L’élaboration de l’architecture est d’abord grossière et indépendante des cas d’utilisation (on veillera cependant à ce qu’elle n’empêche pas leur réalisation) puis, un sous-ensemble des fonctions essentielles est identifié et l’architecture est reprise et détaillée suivant cet ensemble. De la spécification à la précision des cas, l’architecture évolue, incluant finalement de nouveaux cas, ainsi de suite, jusqu’à ce que l’architecture ait atteint un niveau de développement suffisamment élevé et stable pour donner lieu au développement d’un prototype qui sera présenté au client achevant ainsi une itération.

Une itération est la succession des étapes d’une activité. Un incrément est une avancée dans les stades de développement. A chaque itération on retrouve les phases de spécification des besoins (inception), d’élaboration, jusqu’au prototypage exécutable. Une nouvelle itération, par exemple après démonstration du prototype aux utilisateurs, reprendra la spécification en la précisant ou la corrigeant, puis reprenant l’élaboration, etc.

Les incréments sont définis par le projet, et chaque incrément va ajouter de nouvelles fonctionnalités. Les incréments peuvent suivre les différents cas d’utilisation par exemple. La difficulté résidera dans le fait de combiner au final les sous projets ou incréments ensemble et de respecter leurs interdépendances et la cohérence générale du produit envisagé. C’est donc également un développement sous forme de composants qui est proposé. Il utilisera au mieux les apports des technologies objets.

PU intègre les deux visées dans le but de minimiser les risques de contre-sens par rapport aux besoins ainsi que le risque de développements infinis, indéfinis, mal définis ou inachevés : Ici l’utilisateur peut corriger lui-même, sur les prototypes, la tournure que prend le développement. Dès le début, des résultats tangibles sont obtenus même s’ils ne sont que prototypiques. Certaines implémentations de PU considèrent d’ailleurs les prototypes comme des versions à part entière du système final. Les fonctions subalternes peuvent très bien, dans une telle optique, être abandonnées en cours de route pour des questions de coûts ou de délais par exemple. Enfin, si les besoins utilisateurs changent en cours de développement, cette évolution peut être, dans une certaine mesure, intégrée. Ce n’est pas le cas dans le cadre d’un développement séquentiel.

PU prévoit au global un cycle de vie où les itérations (spécifications + analyse + conception + implémentation + tests) sont regroupées en catégories d’activités. Ces activités sont soit initiales (création), soit intermédiaires (élaboration, construction) soit finales (transition vers l’utilisateur ou mise en production). Ces catégories d’activité découpent la réalisation du produit comme une succession temporelle (séquences) mais comprennent toutes les tâches structurantes du projet (raffinage successifs, itérations) et proposent une organisation matricielle du volume d’activité total fourni : il est évident qu’en phase de création, une plus grande partie du temps sera 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 besoin et son raffinage sont théoriquement bouclés depuis la phase de construction :

Fichier:Rup-fr.png

EUP (Entreprise PU) ajoute des catégories d’activités décrivant la vie du logiciel en production jusqu’à son retrait de la production.