USDP

USDP

Unified Process

Processus unifié (PU ou UP en anglais pour Unified Process) est une méthode de prise en charge du cycle de vie dun logiciel et donc du développement, pour les logiciels orientés objets. Cest une méthode générique, itérative et incrémentale, contrairement à la méthode séquentielle Merise (ou SADT).

PU vient compléter la systémique des modèles UML. Elle est le résultat final dune évolution de lapproche dEricsson qui est au fondement dune des premières méthodes de développement pour applications orientées objets, la méthode Objectory Process (1987). Objectory Process (version 1 à 3.8 en 1995) a elle-même servi de base à la société Rational pour la création de Rational Objectory Process (1997) (version 4.1), parente direct de RUP en 1998.

Sommaire

Abréviations utilisées

  • PU : Processus unifié, désigne les préceptes généraux de la méthode.
  • UP : Unified Process, la dénomination anglaise.
  • RUP : Rational Unified Process, Instanciation par Rational Software (IBM) des préceptes UP.
  • EUP : Enterprise Unified Process, Instanciation intégrant les phases de post-implantation et décrivant le cycle de vie du logiciel.
  • XUP : Extreme Unified Process, Instanciation hybride intégrant UP avec Extreme Programming.
  • AUP : Agile Unified Process, partie des préceptes UP permettant lagilité du développement, instanciation partielle de la méthode mettant laccent sur loptimisation et lefficience sur le terrain plus que sur le modèle théorique.
  • 2TUP : Two Tracks Unified Process, Instanciation de UP proposé par Valtech prenant en compte les aléas et contraintes liées aux changements perpétuels et rapides des SI des entreprises.
  • EssUP : Essential unified process, par Ivar Jacobson, initiateur d'UML et RUP, entre autres. À travers sa société Ivar Jacobson Consulting, Ivar propose une mouture du processus unifié qui intégre certains concepts de la méthodes Agile et des idées des partisans de Process Improvement. Ivar travail aujourd'hui pour Microsoft afin d'intégrer EssUP aux outils de travail collaboratifs de la firme (Visual Studio Team System).
  • DCU : Diagramme de cas dutilisation, modèle UML considéré comme fondamental dans PU.
  • Méthode agile : Agile Modeling, tentative de formalisation et dinventaires des préceptes décrivant lagilité en matière de développement applicatif.

Note : On utilisera les abréviations par commodité. On utilisera de préférence les sigles sous la forme de leur traduction française lorsquon parle des concepts génériques ou de méthodes non instanciées. À linverse, on gardera la terminologie anglo-saxonne pour parler des instances.

RUP

RUP est lune 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 dUML :

  • une méthode de développement doit être guidée par les besoins des utilisateurs
  • elle doit être centrée sur larchitecture logicielle
  • elle doit être itérative et incrémentale

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 lOMG, 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 nest 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 dentreprise dans une seule et unique méthode ? Cest à cette question laissée délibérément en suspens par lOMG que répond PU et ses divers avatars (RUP, XUP, AUP, EUP, 2TUP, EssUP). Cest pour préserver une nécessaire adaptabilité au contexte dentreprise 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 :

  • PU est à base de composants
  • PU utilise UML
  • PU est piloté par les cas dutilisation
  • PU est centré sur larchitecture
  • PU est itératif et incrémental

Fonctionnement

Le pilotage par les DCU revêt une signification concrète : des DCU, on doit tirer les modèles danalyse, de conception, de déploiement. Ce sont eux qui sont implantés et ce sont les cas dutilisation prévus qui vont présider à lélaboration des lignes de tests : les cas dutilisation doivent au final être permis par le nouveau logiciel. Les DCU sont les modèles garantissant la cohérence du processus du développement. Ce sont eux qui unifient. Enfin les DCU sont, de par leur nature, intrinsèquement liés à larchitecture du système.

Celle-ci 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 lutilisateur, aux possibilités de réutilisation (re-use) de bibliothèques ou de « briques » préexistantes.

Lélaboration de larchitecture est dabord grossière et indépendante des cas dutilisation (on veillera cependant à ce quelle nempêche pas leur réalisation) puis, un sous-ensemble des fonctions essentielles est identifié et larchitecture est reprise et détaillée suivant cet ensemble. De la spécification à la précision des cas, larchitecture évolue, incluant finalement de nouveaux cas, ainsi de suite, jusquà ce que larchitecture ait atteint un niveau de développement suffisamment élevé et stable pour donner lieu au développement dun prototype qui sera présenté au client achevant ainsi une itération.

Une itération est la succession des étapes dune activité. Un incrément est une avancée dans les stades de développement. A chaque itération on retrouve les phases de spécification des besoins (inception), délaboration, jusquau 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 dutilisation par exemple. La difficulté résidera dans le fait de combiner au final les sous projets ou incréments ensemble et de respecter leurs interdépendances et la cohérence générale du produit envisagé. Cest 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 contresens par rapport aux besoins ainsi que le risque de développements infinis, indéfinis, mal définis ou inachevés : Ici lutilisateur 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 sils ne sont que prototypiques. Certaines implémentations de PU considèrent dailleurs 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 nest pas le cas dans le cadre dun développement séquentiel.

PU prévoit au global un cycle de vie les itérations (spécifications + analyse + conception + implémentation + tests) sont regroupées en catégories dactivités. Ces activités sont soit initiales (création), soit intermédiaires (élaboration, construction) soit finales (transition vers lutilisateur ou mise en production). Ces catégories dactivité 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 dactivité total fourni : il est évident quen phase de création, une plus grande partie du temps sera consacrée à lanalyse des besoins quaux tests ; inversement, en phase de transition, les tests sont encore en cours alors que lanalyse des besoin et son raffinage sont théoriquement bouclés depuis la phase de construction :

Fichier:Rup-fr.png

EUP (Entreprise PU) ajoute des catégories dactivités décrivant la vie du logiciel en production jusquà son retrait de la production.

PU, méthode agile

Les méthodes dites agiles (AM) décrivent des processus de développement dapplication 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 lemboîtement des pratiques agiles avec les concepts UP nest pas évident :

Souvent ladoption de PU par une organisation découle en fait de la volonté de discipliner les pratiques de développement à lutilisation doutils 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 lobjet dingénierie (BPR : Business Process Reengineering). Le développement agile, au contraire, préconise le choix des outils les plus simples et lutilisation 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. Lutilisateur peut théoriquement intervenir au bon moment et annihiler toute erreur dinterprétation.

La modélisation en parallèle est préconisée par PU comme par AM : en effet, si la « sérialisation » telle quelle peut être induite par le découpage en activité organise la matrice des tâches, il nen 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 lexistant ou système en place. RUP prévoie létude de « classes frontières » servant dinterface avec le SI existant tel quil demeurera après limplantation 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 dagilité : La prééminence et le rôle moteur des DCU doit être abandonné car sils 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 « business rules » que devront respecter le logiciel ne peuvent être déduite des DCU. PU ajoute dailleurs un ensemble de « spécifications supplémentaires » pour pallier ce manque. Ainsi, toujours selon Ambler, si lanalyse des besoins peut conduire le projet, les cas dutilisations ne le peuvent pas et ne constituent quune 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 lest 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 à lencontre de loptimisation agile.

Voir aussi

Références externes

Pour une information actualisée, consulter la dernière version du métamodèle [SPEM 2.0, Software Process Engineering Metamodel] de l'OMG.

  • Portail de l’informatique Portail de linformatique
Ce document provient de « Unified Process ».

Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article USDP de Wikipédia en français (auteurs)

Игры ⚽ Поможем сделать НИР

Regardez d'autres dictionnaires:

  • USDP — may be an abbreviation for * United States Democratic Party * Unified Software Development Process …   Wikipedia

  • USDP — Die Abkürzung USDP steht für: Ukrajinska Sozial Demokratytschna Partija – Ukrainische Sozial Demokratische Partei Unabhängige Sozialdemokratische Partei Deutschlands Eine später in der KPD aufgegange Splittergruppe der SPD, meist mit USPD… …   Deutsch Wikipedia

  • Repêchage d'entrée dans la LNH 2009 — John Tavares, premier choix du repêchage …   Wikipédia en Français

  • Burmese general election, 2010 — Burmese (Myanma) general election, 2010 1990 ← 7 November 2010 → 2015 …   Wikipedia

  • Ukrajinska Sozial-Demokratytschna Partija — Kyrillisch (Ukrainisch) Українська соціал демократична партія Die Ukrajinska Sozial Demokratytschna Partija (deutsch Ukrainische Sozial Demokratische Partei, kurz: USDP) ist eine sozialdemokratische politische Partei in der Ukraine. Sie ist im… …   Deutsch Wikipedia

  • Repechage d'entree dans la LNH 2007 — Repêchage d entrée dans la LNH 2007 Le logo du repêchage d entrée dans la LNH 2007. Le Repêchage d entrée dans la LNH 2007 fut le 45e repêchage d entrée de l histoire de la Ligue nationale de hockey. Il a été présenté au Nationwide Arena, situé… …   Wikipédia en Français

  • Repêchage d'entrée dans la LNH 2007 — Patrick Kane, premier choix du repêchage …   Wikipédia en Français

  • Repêchage d'entrée dans la LNH 2008 — Steven Stamkos, premier choix du repêchage Généralités …   Wikipédia en Français

  • Repêchage d'entrée dans la lnh 2007 — Le logo du repêchage d entrée dans la LNH 2007. Le Repêchage d entrée dans la LNH 2007 fut le 45e repêchage d entrée de l histoire de la Ligue nationale de hockey. Il a été présenté au Nationwide Arena, situé dans la ville de Columbus en Ohio …   Wikipédia en Français

  • NHL Entry Draft 2007 — Überblick Datum 22. bis 23. Juni 2007 Ort Columbus, Ohio, USA …   Deutsch Wikipedia

Share the article and excerpts

Direct link
https://fr-academic.com/dic.nsf/frwiki/1673599 Do a right-click on the link above
and select “Copy Link”