# Processus unifié

Le processus unifié (PU), ou « unified process (UP) » en anglais, ou « Unified Software Development Process (USDP) » est une famille de méthodes de développement de logiciels orientés objets. Elle se caractérise par une démarche itérative et incrémentale, pilotée par les cas d'utilisation, et centrée sur l'architecture et les modèles UML. Elle définit un processus intégrant toutes les activités de conception et de réalisation au sein de cycles de développement composés d'une phase de création, d'une phase d'élaboration, d'une phase de construction et d'une phase de transition, comprenant chacune plusieurs itérations ².

## Historique

En 1987, Ivar Jacobson crée la société Objectory AB pour commercialiser une méthode de développement orientée objets appelée Objectory Process. Cette méthode est issue d'une approche centrée sur les composants qu'il avait mise au point depuis 1967 au sein de la société Ericson. Objectory se base sur les cas d'utilisation, un concept dont Jacobson était l'auteur. La méthode suit alors une démarche systématique visant par une succession de modèles OOSE à arriver à la réalisation du logiciel.
En 1992, Grady Booch, employé de la société Rational Software publie la méthode Booch de développement orientée objets. Celle-ci se compose d'un langage de modélisation graphique, d'un processus itératif de développement, et d'un ensemble de pratiques recommandées.
En 1995, la société Rational Software acquiert la société Objectory AB et fusionne les deux méthodes de développement sous l'appellation Rational Objectory Process. La société a également recruté James Rumbaugh, créateur du langage de modélisation OMT.
En 1997, le « langage de modélisation unifié », UML, devient un standard de l'analyse et de la conception orientée objet, à la suite de l'unification des trois principales notations de l'époque, OOSE, Booch et OMT, tout d'abord au sein de Rational Software, puis d'un consortium plus large. La nouvelle notation est alors intégrée à Rational Objectory Process (version 4.1).
En 1998, à la suite de l'acquisition de plusieurs autres sociétés spécialisées dans les outils de génie logiciel, Rational Software améliore sa méthode et la renomme « Rational Unified Process (RUP)» (version 5.0). C'est une méthode propriétaire protégée par une marque déposée.
En 1999, Jacobson, Booch et Rumbaugh publient « Le processus unifié de développement logiciel » dans le but de diffuser plus largement au public les idées à la base de RUP. Ils soulignent qu'il s'agit à la fois d'une unification des approches de développement, et d'une unification des modèles utilisés, et que le processus intègre un grand nombre de contributions de spécialistes en méthodologie de Rational Software et de centaines d'autres sociétés.

## Principes
### Caractéristiques

Le processus unifié est une méthode de développement de logiciel caractérisée par :
* un pilotage par les cas d'utilisation,
* une démarche centrée sur l'architecture,
* une approche basée sur les modèles, et en particulier les modèles UML,
* une approche itérative et incrémentale visant en priorité à réduire les incertitudes.
Le processus unifié répond à la définition d'un processus métier. Il vise ainsi à assurer un cycle de développement avec des enchainements d'activités systématiques et répétables basés sur des artefacts bien définis, tout en facilitant l'intégration de nouvelles personnes dans les équipes. La méthode considère en outre que le produit est constitué non seulement du code, mais aussi de tous les éléments contribuant à la pérennité et aux évolutions ultérieures du logiciel.

### Cycle de vie des projets

Le processus unifié est cyclique : il vise par une succession de projets à fournir d'abord une version viable d'un produit puis des versions publiables successives (« release » en anglais).
Chaque projet a un cycle de vie en quatre phases, chacune subdivisée en plusieurs itérations:
* une phase création ou de cadrage ( « inception» en anglais) vise à définir le produit et les objectifs du projet;
* une phase d'elaboration vise à clarifier les exigences, à définir l'architecture du produit et à en valider la faisabilité. Cette phase prévoit ainsi la mise en œuvre d'une version exécutable constituée d'un squelette du système et démontrant les principaux éléments architecturaux;
* une phase de construction vise à construire et à mettre en œuvre le produit et les livrables associés;
* une phase de transition vise à livrer, diffuser ou déployer le produit de sorte qu'il soit prêt à être utilisé. Cette phase inclut la formation des utilisateurs si nécessaire.
Le processus unifié prône une approche pilotée par les risques, en cherchant au travers des différentes itérations, à lever en priorités les plus grandes incertitudes.

### Enchainements d'activités

Le processus unifié propose les enchainements d'activités suivants, qui peuvent être configurés selon les besoins du projet:
* Exigences : recherche des acteurs et des cas d'utilisation, priorisation, description des cas d'utilisation, prototypage de l'interface utilisateur, et structuration du modèle des cas d'utilisation ;
* Analyse : analyse de l'architecture, analyse d'un cas d'utilisation, analyse d'une classe, et analyse d'un package ;
* Conception : conception de l'architecture, conception d'un cas d'utilisation, conception d'une classe, et conception d'un sous-système ;
* Mise en œuvre (implémentation) : implémentation de l'architecture, intégration du système, implémentation d'un sous-système, implémentation d'une classe, et exécution de tests unitaires ;
* Test : planification des tests, conception des tests, mise en œuvre des tests, exécution des tests d'intégration, exécution de tests systèmes, et évaluation des tests.
Le terme « discipline » est également utilisé pour désigner les enchainements génériques.
Contrairement au modèle en cascade qui définit des phases distinctes pour chacun de ces enchainements d'activités, le processus unifié intègre ces activités au travers des différentes itérations et phases du projet. Le processus unifié est par ailleurs conçu pour gérer des systèmes complexes à base de composants. On y retrouve donc des idées du cycle en V comme une vision architecturale à base de composants, l'intégration du système, et les différents niveaux de validation, mais sans la contrainte de les organiser en étapes séquentielles.
Le processus unifié définit également des rôles pour les acteurs intervenant pour ces activités (par exemple architecte, ingénieur composant, designer d'interface utilisateur, etc.). Les auteurs soulignent néanmoins qu'il s'agit de rôles et non de personnes ; un même membre d'équipe peut donc cumuler plusieurs rôles. Le processus unifié définit enfin une série d'artefacts, c'est-à-dire de livrables du projet.

### Planification itérative

Le processus unifié préconise une planification itérative dans laquelle « le plan précède l'action ».
Le principe est qu'un plan d'ensemble détermine en fonction de la complexité du projet les itérations nécessaires pour chaque phase et positionne les phases dans le temps. Ce plan d'ensemble n'inclut pas de détail par itération. Les itérations sont planifiées de façon progressive au cours de l'avancement du projet. L'itération en cours est planifiée en détail lorsqu'elle démarre, avec un calendrier et un objectif de contenu (cas d'utilisation à traiter, changements à apporter aux livrables des itérations précédentes, composants à réaliser...). Le plan de l'itération suivante est préparé lorsque les éléments en sont connus. Il est ainsi tout d'abord estimé dans les grandes lignes, puis affiné en fonction des informations découvertes lors de l'itération en cours.
Dans le cas particulier de la phase de création, le contour du projet est en général trop incertain pour permettre une planification réaliste. Le plan de la première itération de cette phase doit donc être considéré comme une tentative de plan qui doit être ajustée si nécessaire. A l'issue de ce cette phase, la faisabilité du développement est établie et le plan d'ensemble correspondant à la vision du projet peut être produit.

### Fonctionnement

Le pilotage par les cas d'utilisation utilise les diagrammes de cas d'utilisation (DCU) complétés par des descriptions textuelles. À partir des DCU, on tire les modèles d’analyse, de conception, de déploiement, d'implémentation et de test. De ces modèles émergent l'architecture du système. Une approche systématique est par ailleurs proposée pour déduire des cas d'utilisation des classes d'analyses puis de conception selon le schéma entités-contrôle-frontières. Ce sont aussi les cas d’utilisation qui vont permettre l’élaboration des scénarios de tests puisque le nouveau logiciel devra permettre de réaliser les cas d’utilisation prévus. Les DCU sont ainsi les modèles qui garantissent la cohérence du processus du développement en servant de fil conducteur à l'ensemble des activités.
Les activités de modélisation reposent sur UML. Ce langage de modélisation couvre les aspects structurels et dynamiques de l'architecture et de la conception des logiciels. Il facilite une modélisation par composants en utilisant une approche orientée objets. Les créateurs d'UML sont d'ailleurs à l'origine du processus unifié, qui devait compléter UML par une démarche de développement complète et générique.
L’architecture du système 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 de 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 une succession d'enchainements d'activités. Un incrément est une avancée dans les stades de développement. À chaque itération on retrouve les activités de spécification des besoins, de conception, 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 finalement 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 organise le cycle de vie en regroupant les itérations (spécifications, analyse, conception, implémentation et tests) en phases. Ces phases sont soit initiales (création), soit intermédiaires (élaboration, construction) soit finales (transition vers l’utilisateur ou mise en production). Ces phases 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 besoins et son raffinage sont théoriquement bouclés depuis la phase de construction.

## Variantes du processus unifié

Le processus unifié est configurable et peut donc être adapté aux particularités des projets et des organisations dans lequel il est employé. Il existe ainsi de nombreuses spécialisations de la méthode générale. Plusieurs variantes plus fondamentales ont également vu le jour et connu une diffusion plus large.
Les dénominations et abréviations courantes sont:
| Sigle | Dénomination | Première version | Auteur(s) | Particularités |
| PU | Processus Unifié | 1999 | Ivar Jacobson, Grady Booch et James Rumbaugh | préceptes généraux de la méthode |
| UP | Unified Process | 1999 | (voir PU) | dénomination anglaise de PU |
| USDP | Unified software development process | 1999 | (voir PU) | autre dénomination anglaise de PU, d'après le titre du livre qui a publié la méthode |
| RUP | Rational Unified Process | 1998 | Rational Software (IBM), équipe RUP sous la direction de Philippe Kruchten | méthode propriétaire de Rational Software (IBM) sur laquelle PU a été basée |
| EUP | Enterprise Unified Process | 2000 | Scott Ambler et Larry Constantine | intègre les phases et les activités de post-implantation pour couvrir le cycle de vie du logiciel en production jusqu’à son retrait de la production; la dénomination est une marque commerciale. |
| XUP | eXtreme Unified Process | | | hybride intégrant UP avec extreme programming. |
| AUP | Agile Unified Process | 2005 | Scott Ambler | hybride combinant un sous-ensemble de UP avec des préceptes des méthodes agile - distribué sous forme d'un site web documentant la méthode, mais n'est plus maintenu depuis 2006 |
| 2TUP | two Tracks Unified Process | | Valtech | susceptible de prendre en compte les aléas et contraintes liées aux changements perpétuels et rapides des SI des entreprises |
| EssUP | Essential Unified Process | 2006 | Ivar Jacobson | alternative allégée de UP intégrant des préceptes agiles et diffusée par sa société Ivar Jacobson Consulting. EssUP est composée d'un ensemble de pratiques, dites "essentielles", qui peuvent être librement sélectionnées et combinées offrant ainsi une grande flexibilité dans son application |

### RUP

Rational Unified Process (RUP) est à l'origine du processus unifié et est à ce titre l'implémentation la plus connue. Il s'agit d'un produit et d'une marque de Rational Software, entre-temps acquise par IBM. La méthode est livrée clés en main et est accompagnée d'outils pour guider les équipes dans l'adaptation et exécution du processus.
Le cadre au développement logiciel proposé par RUP répond aux caractéristiques du processus unifié : il s'agit d'une méthode de développement guidée par les besoins des utilisateurs, centrée sur l’architecture logicielle, itérative et incrémentale, mettant en œuvre UML pour la modélisation.
RUP étend les enchainements d'activités pour couvrir également
* la modélisation métier ou modélisation d'affaires (« Business modelling » en anglais) afin de différencier au niveau des exigences les impératifs organisationnels propre à l'environnement métier des utilisateurs d'une part, et les exigences propre au système d'autre part. Cette modélisation des activités d'entreprise est également basée sur UML.
* la gestion de projets, pour prendre en compte les particularités du développement logiciel tout en assurant une conformité avec les normes existantes dans ce domaine.

### AUP

Agile Unified Process (AUP) est une variante simplifiée de UP qui intègre des pratiques agiles comme le développement piloté par les tests (TDD). Elle reprend ainsi les phases séquentielles, et les jalons de fin de phase du processus unifié, mais renforce l'approche agile en préconisant une mise à jour du plan notre en fin de chaque phase, la mise en œuvre d'une version potentiellement publiable à la fin de chaque itération, et l'application des principes du manifeste agile. De ce fait, l'utilisation des modèles comme artefact de documentation se limite au modèle des exigences et au modèle de conception. AUP enrichit la modélisation des exigences avec des modèles métier. La méthode recommande de plus de concentrer la modélisation sur les grandes lignes et d'éviter les détails qui pourraient aisément être déduits du code. AUP est disponible gratuitement en ligne sous forme d'archive compressée, mais n'est plus maintenue depuis 2006.

### EssUP

Essential Unified Process (EssUP) cherche à alléger le processus unifié qui bien qu'itératif et incrémental est souvent perçu comme trop lourd et trop formalisé. EssUP adopte pour cela le principe de la séparation des préoccupations. Plutôt qu'un processus monolithique, EssUP définit un ensemble de pratiques indépendantes qui peuvent être librement combinées pour former un processus adapté au contexte.
Les pratiques identifiées par EssUP sont regroupées en 8 familles de sujets : l'équipe, le produit, le cycle de vie, les itérations, les cas d'utilisation 2.0, l'architecture, les composants, et l'exécution de tests. EssUP est disponible en ligne.

## Positionnement
### Comparaison avec d'autres méthodes

Le processus unifié utilise des phases séquentielles comme les projets en cascade. Toutefois, les phases ne sont pas structurées artificiellement en fonction des disciplines techniques, mais répondent à une logique de réduction de risques par étapes, chaque phase intégrant l'ensemble des disciplines à des degrés plus ou moins développés. Par ailleurs le processus unifié prône une planification itérative et adaptative plutôt qu'une planification rigide et détaillée en amont.
Le processus unifié a des similarités avec le cycle en V dans la mesure où il est centré sur l'architecture de systèmes faits de composants et où il distingue les tests unitaires, les tests d'intégration et les tests systèmes. Toutefois, les phases du PU ne sont pas structurées par niveau architectural et par discipline, mais répondent à une logique de maturation itérative. Par ailleurs, le PU intègre les activités de vérification et de validation dans chaque phase.
Le processus unifié est proche des méthodes agiles dans la mesure où il prône une approche itérative et incrémentale, focalisée sur les besoins utilisateurs. Il se différencie toutefois des méthodes agiles par la collecte proactive d'une majorité d'exigences au cours des premières itérations d'un projet, et par la définition d'une architecture en amont avant la réalisation de versions publiables (« release » en anglais). Il centre également la démarche sur les modèles alors que les méthodes agiles privilégient la production de code à la production de documentation. Cette dernière différence doit toutefois être relativisée car certains agilistes prônent également une approche basée sur la modélisation. Ces méthodes agiles-là partagent avec UP la vision d'une modélisation incrémentale où les différents modèles (exigences, analyse, conception) sont affinés en parallèle au cours de chaque itération, plutôt que séquentiellement, phase par phase.
Le processus unifié fait un usage intensif des modèles UML. Il articule les différents types de diagrammes avec les différentes finalités de modélisation (analyse, conception, test). Il enrichit ainsi UML, qui est un langage de modélisation générique, avec approche systématique mais propre à une méthode de développement spécifique.

### Critiques

Le processus unifié combine les avantages de plusieurs approches, et en particulier une démarche structurée en phases avec une grande flexibilité au niveau des itérations.
La principale critique est que la description détaillée des enchainements d'activité et des artefacts confère au PU une certaine lourdeur$^,$$^,$ et nécessite de ce fait une qualification élevée des membres de l'équipe projet (en particulier : maitrise des approches itératives, connaissance approfondie d'UML, connaissance des enchainements d'activités et de leurs interdépendances).
Le processus unifié laisse aussi une grande latitude d'appréciation pour l'adaptation des activités aux spécificités d'une entreprise. Cette flexibilité, combinée à la complexité du processus et à une grande liberté d'interprétation, peut donner lieu à des mises en œuvre très rigides du PU, alors que celui-ci possède en principe les caractéristiques d'une méthode agile.
Souvent l’adoption de PU par une organisation découle de la volonté de discipliner les pratiques de développement à l’utilisation d’outils particuliers et au suivi de règles de conduites établies et homogènes. Le processus de développement de logiciels font alors eux-mêmes l'objet de réingénierie de processus (« BPR ») en vue d'une optimisation des activités des services informatiques. 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.
Selon Scott Ambler, certains fondements de PU ne peuvent coexister avec les préceptes d’agilité : la prééminence et le rôle moteur des diagrammes de cas d'utilisation doit être abandonné. En effet, s’ils permettent de documenter correctement les comportements du logiciel, ils ne pourront pas servir à piloter toutes les activités du projet : les contraintes, les interfaces utilisateurs et leur cinématique, les règles métier que devront respecter le logiciel ne peuvent être déduites des cas d'utilisation. 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.

### Évolutions

De nombreuses variantes allégées du processus unifié ont vu le jour pour pallier la lourdeur initiale de sa description. Plusieurs variantes agiles ont également vu le jour, en cherchant à renforcer le caractère itératif, alléger la documentation, ou faciliter l'intégration dans le processus de certaines pratiques agiles.
Les évolutions les plus récentes, et en particulier EssUP, visent à transformer le processus unifié en une « boite à outils ». Le principe est d'identifier et définir des composantes du processus, par exemple son découpage en phases, ses techniques de pilotage itératif, et certaines techniques de modélisation, pour les rendre indépendantes et réutilisables et permettre aux équipes projet de sélectionner et combiner celles qui sont pertinentes en fonction du contexte.