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 alt=Cycle de développement du processus unifié: un cycle de vie de produit comprend plusieurs projets livrant chacun une version publiable du logiciel. Chaque projet est découpé en 4 phases, et chaque phase est décomposée en une ou plusieurs itérations produisant un incrément (et le cas échéant une version interne non publiée du logiciel). |vignette|566x566px|Cycle de développement: projets, phases et itérations 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: alt=Processus unifié : enchainements d'activités au cours du cycle de vie - les activités se déroulent de façon intégrée tout au long du projet à travers les phases|vignette|568x568px|Processus unifié : enchainements d'activités au cours du cycle de vie
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 alt=Phases et itérations d'un projet de développement avec description des principaux jalons de fin de phase|vignette|579x579px|Phases et itérations d'un projet de développement 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. , 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.