United software process

Histoire

Le “Unified Software Process” fut originellement créé par Ivar Jacobson. En 1988, il définit Objectory V1.0, qui constitue la base sur laquelle se développeront ensuite l’RUP et l’EUP. Plusieurs versions améliorées d’Objectory V1.0 seront alors développées jusqu’à la publication par Jacobson en 1999 de The Unified software development process. Ce livre fournit un cadre détaillé de ce qu’est un Unified process. Il y définit également les jalons essentiels à la conduite d’un projet, à savoir l’identification du besoin client, l’analyse, le design, le codage et la phase de test. Plusieurs variantes de l’Unified process seront développées par la suite par diverses acteurs. La plus populaire à ce jour est le Rational Unified Process (RUP), que nous définirons plus en détails dans cet article.

Définition

Contrairement à ce que son nom pourrait laisser suggérer, l’Unified process n’est pas un simple “process”, mais plutôt un cadre de travail modulable en fonction de différents projets ou organisations. En d’autres termes c’est une architecture permettant de cadrer le développement d’un logiciel qui conserve néanmoins une certaine souplesse afin de s’adapter à des contextes diverses.

Cette manière de faire à été développée en réponse à la complexité grandissante des développements de logiciel, qui ne pouvaient plus être mis en oeuvre sans une structure claire et cohérente. Elle fournit ainsi une ligne de conduite aux différents individus et équipes d’un projet.

3 composantes font l’essence d’un Unified Process:

• Il doit être use-case driven, c’est à dire qu’il base son raisonnement sur l’interaction entre le système et l’utilisateur. C’est le besoin de l’utilisateur qui détermine les exigences auxquelles devra répondre le système.
• L’architecture du logiciel est centrale dans son développement. Si les use case déterminent in fine l’architecture du projet, celle-ci permet également de centraliser les besoins et d’offrir par la même une base sur lesquelles les use case s’appuient également. Les notions de use case et d’architecture sont donc intimement liées, les premiers composants la seconde, et celle-ci fournissant un cadre aux premiers.
• Enfin, le projet doit-être itératif , c’est à dire en progression constante. C’est ce qui donne une certaine souplesse à l’architecture définit, et permet au projet de ne pas s’enfermer dans un cadre rigide qui pourrait perdre en pertinence en fonction des nouveaux éléments faisant emergence.

Le développement du RUP

Le RUP, Rational Unified process, a été développé en 2003 par Rational, une branche d’IBM. Ce processus est vite devenu une référence dans le domaine et est encore aujourd’hui fréquemment utilisé.

Le RUP compte quatre phases principales, qui restent constante en dépit de la flexibilité contextuelle a laquelle l’architecture peut être confrontée.

La première phase est la phase d’ “inception”, c’est à dire de démarrage. Elle consiste à cadrer le projet et ses objectifs, afin de pouvoir déterminer les coûts qu’il engendrera, ainsi que les ressources à déployer.

Vient ensuite la phase d’élaboration, au cours de laquelle sera définie l’architecture globale du logiciel. Il s’agit là d’une phase de conception et d’analyse technique qui reste néanmoins assez générale.

La phase de conception qui suit consiste en la mise en oeuvre de l’architecture définie au cours de l’élaboration. C’est une phase de développement du logiciel.

Enfin, la phase de “transition” permet de faire la bascule entre le développement et la mise en production du logiciel. C’est au cours de cette phase que le passage de témoin aux utilisateurs finaux est effectué.