Processus unifié

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[6]. 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[1].

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[7]:

• une phase création[8] ou de cadrage ( « inception» en anglais) vise à définir le produit et les objectifs du projet;
• une phase d'elaboration[9] 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[10] vise à construire et à mettre en œuvre le produit et les livrables associés;
• une phase de transition[11] 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[1].

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.

Le processus unifié propose les enchainements d'activités suivants, qui peuvent être configurés selon les besoins du projet[12]:

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.

Le processus unifié préconise une planification itérative dans laquelle « le plan précède l'action »[13].

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[13]. 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.

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[12]. 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[2].

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.

Aspects RUP : les aspects dynamiques sont à l'horizontale, les statiques affichés verticalement.

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[21].

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[15].

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[22]. Cette modélisation des activités d'entreprise est également basée sur UML[23].
• 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[21].

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)[18]. 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 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.

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[24].

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[19]. EssUP est disponible en ligne.

Le processus unifié utilise des phases séquentielles comme les projets en cascade[18]. 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[1].

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[25]. 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[26]. 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.

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[27] - [18] - [19] et nécessite de ce fait une qualification élevée des membres de l'équipe projet[28] (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[25].

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.

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[24].

• (en) Ivar Jacobson, Grady Booch et James Rumbaugh, The unified software development process : The complete guide to the Unified Process from the original designers, Addison-Wesley, 1999 (ISBN 978-0-201-57169-1)
• (en) Per Kroll et Philippe Kruchken, The rational unified process made easy : A practitionner's guide to RUP, Addison-Wesley, 2003, 416 p. (ISBN 0-321-16609-4, lire en ligne)

• Développement de logiciels
• Modèle en cascade
• Cycle en V
• Méthodes agiles
• OpenUP
• Urbanisation des systèmes d'information
• Gestion de projet
• Programme (gestion de projet)