Présentation Unified Process

Salut à tous, voici un petit article vous présentant brièvement ce qu’est unified process.

On va dans cet article aborder les 3 axes fondateurs d’UP, les 5 core d’itération, ses phases et son implémentation RUP.

Kezako ?

Premièrement, unified process est un SDP (software developpement process) et un SEP (software engineering process), c’est-à-dire qu’il va fournir des process et méthodes permettant de répondre à qui, quoi, quand et comment dans le cadre du développement logiciel et donc aider à « transformer les specs en logiciel ».

Ensuite UP (unified process) est un très souvent utilisé en tant que framework, c’est-à-dire, un ensemble de bonnes pratiques et de concept qu’il faudra ensuite composer avec ses pratiques et méthodes.

UP  a été développé par un les auteurs d’UML ce qui explique sa forte utilisation dans les process.

Enfin UP apporte plus de questions que de réponse (mais au moins il permet d’avoir les bonnes questions)

Les 3 axes d’UP

UP repose sur 3 axes majeurs et les comprendre c’est déjà comprendre la moitié du process :

UP est axé sur les use-case et est risk driven

UP est centré sur l’architecture

UP et itératif et incrémental

Cores

Les projets mettant en place UP comportement tous les stades classique du développement logiciel :

Planification

Analyse & design

Construction

Intégration et teste

Livraison

Il implémente ces étapes dans ses 5 core suivant :

Requirement – Capturer les ce que le système doit faire

Analysis – Rafiner et structurer les requirements

Design – réaliser les requirements dans l’architecture du système

Implémentation – construire le logiciel

Test – Vérifier que l’implémentation fait ce que les requirements demandent

Ces 5 cores représentent une itération. Pour comprendre l’incrémental, un coup d’œil au schéma suivant sera utile :

On voit que les itérations sont exécutées dans 4 phases. Nous allons les détailler après, mais faisons d’abord un débroussaillement. La première, inception, qui consiste à lancer le projet et principalement dégager les spécification et débuter l’analyse. Ensuite la phase d’élaboration qui se concentre sur le raffinement des specs, l’analyse et le design avec un début d’implémentation. Suit la construction qui a lieu une fois les spécifications capturées. A ce stade l’analyse et le design ne concerne plus que de possible besoin supplémentaires et les itérations se focus sur l’implémentation. Afin de sortir de la phase de construction se conclut souvent par une beta testing publique. La phase de Transition représente le déploiement du système.

5 Phases : focus & objectifs

Inception

Établir la faisabilité

Créer les business case pour démontrer les bénéfices apportés

Tenter de capturer les besoins essentiels du système

Identifier les risques critiques

L’inception se concentre principalement sur les requirements et un début d’analyse. Un peu de design et d’implémentation peut être fait si il est nécessaire de réaliser un PoC ou un prototype d’application qui sera les seuls artefacts pouvant résulter de la phase.

Élaboration

Créer une architecture de base

Raffiner la gestion des risques

Définir les attributs qualité

Capturer 80% des use case des besoins fonctionnels

Créer un plan détaillé pour la phase de construction

Le but de cette phase est de créer un système partiel mais fonctionnel d’un point de vue architectural. Ce n’est pas un prototype mais plus une sorte de « coquille vide ». C’est d’ailleurs une des phases majeures d’UP. (UP étant basé sur l’architecture et l’architecture se définissant principalement ici, ça n’a rien de surprenant)

Construction

Découvrir tous les besoins n’ayant pas été pris en compte

Finaliser les modèles d’analyse

Finaliser le design

Construire les IOC et les tester

Maintenir l’intégrité de l’architecture du système

Le but de cette phase est de faire tout ce qui n’a pas encore été fait et surtout d’implémenter toutes les fonctionnalités restante vu que le design et l’architecture ont été finalisé ou presque dans la phase précédente.

Transition

Corriger les défauts

Préparer les migrations/déploiements

Adapter le système au lieu d’implémentation

Créer la documentation utilisateur

Fournir du support

Conduire une analyse de post projet

Les objectifs parlent d’eux même, on peaufine, on corrige les dernières petites erreurs (avec des patchs si le logiciel est déjà livré), on implémente et on documente. Étape très importante, le debrief de post projet. Ce debrief (qui peut durer une journée ou plus) permet d’identifier et de reporter les problèmes rencontré lors du développement du projet et de modifier les process si nécessaire afin de ne plus les rencontrer au projet développement.

RUP/UP

RUP est une implémentation réalisée par Rational Software de Unified Process (racheté par IBM en 2003, Rational ayant au moment du développement de RUP racheté Requisite, Verdix, Objectory, SQA & Pure-Atria). RUP a été créé également par les créateurs de UP et UML. En effet, en 1995 Rumbaugh rejoint Rational Software et ensuite Jacobson. Booch étant déjà chez Rational Software, toute l’équipe d’UML (Jacobson compris donc) était réunie pour collaborer autour d’une implémentation de UP, ce qui conduit a un ouvrage « The Unified Software Development Process » ne 1999. Cette implémentation fut longtemps une simple implémentation commerciale de UP avec quelques outils très peu différent. Ce qui a vraiment rendu RUP utile est le travail de documentation et d’écriture réalisé Kruchten, alors représentant pour Rational passé « Director of Process Development » qui développa un vrai framework basé sur Objective.

RUP est à la fois différent et similaire a UP, on notera principalement les cores supplémentaire, principalement résultant du travail de Kruchten une fois chez IBM. (Il garda son poste après le rachat de Rational). Mais le plus de RUP est l’intégration avec les outils de la gamme rational. Ceci dit, d’autres implémentations sont disponibles, comme OpenUP. De même UP est souvent implémenté en interne avec des outils comme Eclipse Process Framework.

 

Bibliographie

The Unified Software Development Process – Jacobson, Booch, Rumbaugh
UML & The Unified Process – Jim Arlow & Ila Naustadt
The Rational Unified Process-An Introduction – Kruchten
Rational Unified Process Made Easy-A Practitioner’s Guide to the RUP – Kruchten

http://en.wikipedia.org/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s