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 :
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 :
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 règles métier que devront respecter le logiciel ne peuvent être déduites 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.