USDP

Unified Process

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éthodes Agile et des idées des partisans de Process Improvement. Ivar travail 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.

RUP

RUP est l’une des plus célèbres implémentations de la méthode PU, livrée clés en main, permettant de donner un cadre au développement logiciel, répondant aux exigences fondamentales préconisées par les créateurs d’UML :

• une méthode de développement doit être guidée par les besoins des utilisateurs
• elle doit être centrée sur l’architecture logicielle
• elle doit être itérative et incrémentale

UML est souvent qualifié de langage de modélisation et permet en fait de « penser objet » au moment de la conception, de la modélisation, pour permettre un développement objet plus aisé. Mais, et ses créateurs, membres de l’OMG, en étaient tout à fait conscients, le cycle de vie du logiciel, le processus de création et même de la conception des dits modèles n’est pas du tout prise en charge par UML. La raison en est simple : Comment prendre en compte la diversité des projets, des problématiques, des équipes et des cultures d’entreprise dans une seule et unique méthode ? C’est à cette question laissée délibérément en suspens par l’OMG que répond PU et ses divers avatars (RUP, XUP, AUP, EUP, 2TUP, EssUP). C’est pour préserver une nécessaire adaptabilité au contexte d’entreprise que PU est avant tout générique.

Ainsi, une réalisation conforme à PU, pour transformer les besoins des utilisateurs en logiciel, doit nécessairement présenter les caractéristiques suivantes :

• PU est à base de composants
• PU utilise UML
• PU est piloté par les cas d’utilisation
• PU est centré sur l’architecture
• PU est itératif et incrémental

Fonctionnement

Le pilotage par les 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 contresens 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.

PU, méthode agile

Les méthodes dites agiles (AM) décrivent des processus de développement d’application basés sur la modélisation, la conception et la documentation réalisés de façon efficiente. Les pratiques de modélisation agiles sont en fait des améliorations (Best practices) censées pouvoir être appliquées à des méthodes déjà existantes, déjà instanciées. Ainsi AUP (agile modeling unified process) doit être considéré comme un sous-ensemble de Rational UP. Or l’emboîtement des pratiques agiles avec les concepts UP n’est pas évident :

Souvent l’adoption de PU par une organisation découle en fait de la volonté de discipliner les pratiques de développement à l’utilisation d’outils particuliers et au suivi de règles de conduites établies, homogènes. Ils constituent eux-mêmes des traitements dans les directions informatiques des entreprises et font l’objet d’ingénierie (BPR : Business Process Reengineering). Le développement agile, au contraire, préconise le choix des outils les plus simples et l’utilisation en douceur ou « sur le mode de la boîte à outils » des modèles du langage ou des phases de la méthode. Il y a donc paradoxe à vouloir rigidifier en les codifiant des pratiques par nature destinées à la souplesse.

Pour autant, la plupart des concepts agiles sont implantés, décrits, dans PU sous la forme de mécanismes de développement :

La participation active telle que promue par AM est facilitée par le développement itératif et incrémental. L’utilisateur peut théoriquement intervenir au bon moment et annihiler toute erreur d’interprétation.

La modélisation en parallèle est préconisée par PU comme par AM : en effet, si la « sérialisation » telle qu’elle peut être induite par le découpage en activité organise la matrice des tâches, il n’en reste pas moins qu’à chaque itération les différents types de modèles peuvent être effectués en même temps.

AM préconise une formalisation des zones de contacts entre le projet et l’existant ou système en place. RUP prévoie l’étude de « classes frontières » servant d’interface avec le SI existant tel qu’il demeurera après l’implantation du projet.

La modélisation dans chaque incrément est conçue par PU comme étant le résultat de raffinages successifs.

Favoriser la réutilisation de codes, de classes : Plus encore que PU ce sont les langages objets et la conception en classe qui permettent cela. Par contre, selon Scott Ambler (http://www.agilemodeling.com/ ), certains fondements de PU ne peuvent coexister avec les préceptes d’agilité : La prééminence et le rôle moteur des DCU doit être abandonné car s’ils permettent de documenter correctement les comportements du logiciel ils ne pourront pas servir à piloter quelque autre activité du projet que ce soit : les contraintes, les interfaces utilisateurs et leur cinématique, les « business rules » que devront respecter le logiciel ne peuvent être déduite des DCU. PU ajoute d’ailleurs un ensemble de « spécifications supplémentaires » pour pallier ce manque. Ainsi, toujours selon Ambler, si l’analyse des besoins peut conduire le projet, les cas d’utilisations ne le peuvent pas et ne constituent qu’une rhétorique marketing propre aux instanciations telles que RUP ou EUP.

En second lieu, la méthode de développement en incrément et itération, si elle est assimilée par le chef de projet, ne l’est pas forcément des développeurs et encore moins des utilisateurs qui peuvent y être associés. Ces concepts ne sont pas simples à appréhender et à implanter dans une gestion de projet. Cela nécessite une démarche active de la part de celui qui décide de mener le projet selon ces préceptes de façon à ce que la démarche soit effectivement itérative et incrémentale. Autant de temps consacré à la « métaphysique » du projet et de sa gestion qui vont à l’encontre de l’optimisation agile.

Voir aussi

• Urbanisme (système d'information)
• Gestion de programme

Références externes

Pour une information actualisée, consulter la dernière version du métamodèle [SPEM 2.0, Software Process Engineering Metamodel] de l'OMG.

Ce document provient de « Unified Process ».