Le Processus Unifié en bref

« Le processus unifié est un processus de développement logiciel, c’est-à-dire qu’il regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel » (Jacobson, Booch, Rumbaugh 1999)

Il est le fruit des meilleures pratiques de l’ingénierie logicielle: des approches éprouvées pour développer et maintenir des logiciels de qualité.

Pourquoi passer au Processus Unifié ?
Le processus Unifié est en mesure de répondre directement ou indirectement à à ces problématiques, n’hésitez donc pas à en lire un peu plus !

• Vous explosez vos budgets
• Vous dérapez sur les délais ce qui retarde la mise en marché de vos produits
• Vos clients ne sont pas satisfaits de la qualité de vos produits
• Vos produits ne font pas, au final, ce qu’il sont censés faire, sans compter les bugs !
• Vous ne parvenez pas à gèrer le moindre changement demandé en cours de projet
• Vous manquez de visibilité sur vos projets, d’ailleurs vous avez commencé du développement Offshore et c’est encore pire!
• Vos équipes de développement ne savent pas ce qu’elles ont à faire ou ne semblent guère motivées
• Vous perdez du temps à refaire sans cesse les mêmes choses
• Vous n’avez rien à communiquer à vos clients, dailleurs vos clients vous ne les revoyez qu’à la fin !
• Vous avez besoin d’un « cadre » que les autres méthodes Agiles (XP ou SCRUM) ne peuvent vous proposer …

Son origine
Le terme « Unifié » est trés approprié puisqu’il s’agit de la fusion des travaux d’Ivar Jacobson, Grady Booch (au départ chez Objectory) et de James Rumbaugh, enrichie de nombreux apports issus d’UML (développé en parallèle) et du produit commercial RUP, sorti en 1998 et toujours mis à jour par IBM (aprés le rachat de Rational qui avait lui même acheté Objectory en 1995).
D’autres ont permis de peaufiner le processus, notamment Walker Royce et Philippe Kruchten pour la planification et la gestion de projet.

Ses principes
Le Processus Unifié (UP) est piloté par les cas d’utilisation (eux même guidés par les risques) centré sur l’architecture, itératif et incrémental.
Le projet sera donc mené selon les besoins et les exigences (fonctionnelles et non fonctionnelles) : points d’entrée sur lesquels l’analyse des risques va principalement s’exercer pour organiser les plans d’itération, et pour moi en tant qu’ergonome c’est important.
Les risques majeurs (souvent liés à l’architecture) seront traités en premier lieu dans le but de les lever au plus tôt: gestion et pilotage par les risques, de vrais points forts pour la méthode.
Le Processus Unifié est opposé au cycle de vie en cascade (ou séquentiel) trop figé et rigide, et se lit selon deux axes: vertical (enchainement de disciplines et d’activités au sein d’une itération) et horizontal (enchainement dynamique sur l’axe temporel de phases et d’itérations). On va donc par exemple, tester à chaque itération sans attendre la fin du projet…

Il définit donc 4 phases :

• Inception (courte pour estimer, planifier, partager une même vison du problème, et engager les hostilités),
• Elaboration (architecture définie, risques majeurs levés, exigences trés avancées, programmation largement engagée)
• Construction (plus d’itérations mais plus courtes; développement de toutes les fonctionnalités, doc incluse)
• Transition (préparation du lancement, tests beta, formation des utilisateurs, optimisation …).

Mais le Processus Unifié permet aussi et surtout de définir des disciplines, des activités, des rôles et des livrables: en cela il est beaucoup plus complet que la plupart des autres méthodes agiles (XP ou SCRUM) qui n’abordent pas ou trés peu ces questions.
Autre avantage, le Processus Unifié est customisable que ce soit à partir de sa forme la plus répandue et la mieux documentée, le RUP, ou à partir des autres instanciations qui ont été faites ces dernières années :

• EnterpriseUP (Scott Ambler, 2004),
• AgileUP (Scott Ambler, 2006 pour sa dernière version),
• EssentialUP (Ivar Jacobson, 2005),
• OpenUP (Eclipse Process Framework, 2006).

Les évolutions récentes cherchant à être plus légères, plus agiles.
Bref, à vous de l’adapter à votre contexte (organisation, types de projet…) pour qu’il réponde efficacement à vos besoins.

Ses six bonnes pratiques
L’application de ces principes ne peut vous assurer à 100 % de la réussite de votre projet; disons simplement qu’elle y contribuera fortement.

• Iterations courtes de 3 à 6 semaines avec les principes du Timeboxing (on ne bouge pas les dates, on ajuste le contenu des itérations) et du pilotage par les risques
• Développements centrés sur l’architecture (et orientés sur les risques majeurs) avec le principe de la réutilisation des composants
• Focus sur la qualité (tester tôt et souvent, niveau unitaire, intégration, système) avec les principes de la validation et de l’intégration continues
• Modélisation graphique (UML, digrammes, grilles …) avec le principe de l’utilisation du visuel pour communiquer
• Gestion des exigences (organisation, traçabilité, évolution des exigences)
• Contrôle du changement (anticipation, gestion des demandes) avec le principe du réajustement (feedback, adaptation)

Son adaptation, sa customisation
Avant tout être « Agile » (c’est un état d’esprit), faire simple en ne retenant que le strict nécessaire; voici ma démarche:

• S’attaquer aux processus
• Mettre en avant les bonnes pratiques
• Identifier de manière pragmatique ce qui se passe sur les projets en termes de rôles, activités et disciplines. Ce fut notamment pour moi l’occasion d’officialiser certains rôles (dont l’ergonome…)
• Etablir une première mouture et l’appliquer sur 2 ou 3 projets pilotes
• Conduire le changement et généraliser
• Capitaliser et faire évoluer de nouveau

Les pre-requis pour mener à bien ce type de mission :

• bonne connaissance de l’organisation,
• vue globale sur les projets de l’entreprise et sur les activités des différents acteurs,
• bonne connaissance du RUP (bien documenté c’est une bonne référence),
• ouverture sur les différentes instanciations et les autres méthodes agiles (XP, SCRUM)

Les erreurs malheureusement souvent commises
Elles sont le signe d’une mauvaise interprétation du Processus Unifié:

• Decrire les phases d’UP comme les phases du mode séquentiel. L’inception n’est pas que l’analyse des besoins, la transition n’est pas une phase de test. La construction, ce n’est pas que du code ! Toutes ces disciplines peuvent avoir lieu en même temps dans une itération (comme l’indique le schéma).
• Commencer d’entrée par un planning ultra détaillé pour les 12 mois à venir
• Planifier des itérations trop longues (une itération dure entre 2 et 6 semaines : le but est d’être réactif)
• Décaler les dates d’itération à sa guise sans respecter le Timeboxing
• Ne pas tester dans une itération ce qu’on a produit
• Oublier que le but de la phase d’Elaboration n’est pas de produire un prototype jetable mais une architecture viable
• Analyser toutes les exigences avant de commencer à programmer
• Se dire qu’il faut absolument utiliser tous les livrables potentiellement utilisables

Pour aller plus loin…

• The Unified Software development process, Jacobson, Booch, Rumbaugh, 1999
• The Rational Unified Process, An Introduction, Philippe Kruchten, 2000
• Agile and iterative development : A Manager’s guide, Craig Larman, 2003
• Rational Unified Process Version 2003.06.01.06