Wikipédia

Processus unifié

Le processus unifié est une famille de méthodes de développement de logiciels orientés objets. Elle se caractérise par une démarche itérative et incrémentale, pilotée par les cas d'utilisation, et centrée sur l'architecture et les modèles UML.
(Redirigé depuis Rational Unified Process)

Le processus unifié (PU), ou « unified process (UP) » en anglais, ou « Unified Software Development Process (USDP) » est une famille de méthodes de développement de logiciels orientés objets. Elle se caractérise par une démarche itérative et incrémentale, pilotée par les cas d'utilisation, et centrée sur l'architecture et les modèles UML. Elle définit un processus intégrant toutes les activités de conception et de réalisation au sein de cycles de développement composés d'une phase de création, d'une phase d'élaboration, d'une phase de construction et d'une phase de transition, comprenant chacune plusieurs itérations ².

Historique modifier

En 1987, Ivar Jacobson crée la société Objectory AB pour commercialiser une méthode de développement orientée objets appelée Objectory Process. Cette méthode est issue d'une approche centrée sur les composants qu'il avait mise au point depuis 1967 au sein de la société Ericson[1]. Objectory se base sur les cas d'utilisation, un concept dont Jacobson était l'auteur[2]. La méthode suit alors une démarche systématique visant par une succession de modèles OOSE à arriver à la réalisation du logiciel.

En 1992, Grady Booch, employé de la société Rational Software publie la méthode Booch de développement orientée objets. Celle-ci se compose d'un langage de modélisation graphique, d'un processus itératif de développement, et d'un ensemble de pratiques recommandées[3].

En 1995, la société Rational Software acquiert la société Objectory AB et fusionne les deux méthodes de développement sous l'appellation Rational Objectory Process[4]. La société a également recruté James Rumbaugh, créateur du langage de modélisation OMT.

En 1997, le « langage de modélisation unifié », UML, devient un standard de l'analyse et de la conception orientée objet, à la suite de l'unification des trois principales notations de l'époque, OOSE, Booch et OMT, tout d'abord au sein de Rational Software, puis d'un consortium plus large. La nouvelle notation est alors intégrée à Rational Objectory Process (version 4.1).

En 1998, à la suite de l'acquisition de plusieurs autres sociétés spécialisées dans les outils de génie logiciel, Rational Software améliore sa méthode et la renomme « Rational Unified Process (RUP)» (version 5.0). C'est une méthode propriétaire protégée par une marque déposée.

En 1999, Jacobson, Booch et Rumbaugh publient « Le processus unifié de développement logiciel » dans le but de diffuser plus largement au public les idées à la base de RUP. Ils soulignent qu'il s'agit à la fois d'une unification des approches de développement, et d'une unification des modèles utilisés, et que le processus intègre un grand nombre de contributions de spécialistes en méthodologie de Rational Software et de centaines d'autres sociétés[4].

Principes modifier

Caractéristiques modifier

Le processus unifié est une méthode de développement de logiciel caractérisée par :

Le processus unifié répond à la définition d'un processus métier[5]. 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[4].

Cycle de vie des projets modifier

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

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

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.

Enchainements d'activités modifier

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

 
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.

Planification itérative modifier

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

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

Fonctionnement modifier

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

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[réf. nécessaire].

L’architecture du système est conçue dès le départ de façon très pragmatique[réf. nécessaire] : 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[pas clair], 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[réf. nécessaire]. 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[réf. nécessaire]. 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.

Variantes du processus unifié modifier

Le processus unifié est configurable et peut donc être adapté aux particularités des projets et des organisations dans lequel il est employé[4]. Il existe ainsi de nombreuses spécialisations de la méthode générale. Plusieurs variantes plus fondamentales ont également vu le jour et connu une diffusion plus large[14].

Les dénominations et abréviations courantes sont:

Sigle Dénomination Première version Auteur(s) Particularités
PU Processus Unifié 1999 Ivar Jacobson, Grady Booch et James Rumbaugh préceptes généraux de la méthode[4]
UP Unified Process 1999 (voir PU) dénomination anglaise de PU
USDP Unified software development process 1999 (voir PU) autre dénomination anglaise de PU, d'après le titre du livre qui a publié la méthode
RUP Rational Unified Process 1998 Rational Software (IBM), équipe RUP sous la direction de Philippe Kruchten méthode propriétaire de Rational Software (IBM) sur laquelle PU a été basée[15]
EUP Enterprise Unified Process 2000 Scott Ambler et Larry Constantine intègre les phases et les activités de post-implantation pour couvrir le cycle de vie du logiciel en production jusqu’à son retrait de la production[16]; la dénomination est une marque commerciale[17].
XUP eXtreme Unified Process hybride intégrant UP avec extreme programming[18].
AUP Agile Unified Process 2005 Scott Ambler hybride combinant un sous-ensemble de UP avec des préceptes des méthodes agile - distribué sous forme d'un site web documentant la méthode, mais n'est plus maintenu depuis 2006[19]
2TUP two Tracks Unified Process Valtech susceptible de prendre en compte les aléas et contraintes liées aux changements perpétuels et rapides des SI des entreprises[réf. nécessaire]
EssUP Essential Unified Process 2006 Ivar Jacobson alternative allégée de UP intégrant des préceptes agiles et diffusée par sa société Ivar Jacobson Consulting[20]. EssUP est composée d'un ensemble de pratiques, dites "essentielles", qui peuvent être librement sélectionnées et combinées offrant ainsi une grande flexibilité dans son application[21]

RUP modifier

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

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

AUP modifier

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

EssUP modifier

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

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

Positionnement modifier

Comparaison avec d'autres méthodes modifier

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

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

Critiques modifier

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

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[réf. nécessaire]. 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é[réf. nécessaire]. 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[réf. nécessaire].

Évolutions modifier

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

Notes et références modifier

  1. ↑ (en) Jacobson, Ivar. et Jacobson, Agneta., The object advantage : business process reengineering with object technology, Wokingham/Reading (Mass.)/Paris etc., Addison-Wesley, ©1995, 347 p. (ISBN 0-201-42289-1 et 9780201422894, OCLC 32276135, lire en ligne)
  2. ↑ (en) Ivar Jacobson, « Object-oriented Development in an Industrial Environment », SIGPLAN Not., vol. 22, no 12,‎ , p. 183–191 (ISSN 0362-1340, DOI 10.1145/38807.38824, lire en ligne, consulté le )
  3. ↑ (en) Booch, Grady., Reese, Freddy. et Bonnetain, Pierre-Yves., Analyse et conception orientées objets, Addison-Wesley France, (ISBN 2-87908-069-X et 9782879080697, OCLC 31874228, lire en ligne)
  4. ↑ a b c d e f et g (en) Jacobson, Ivar., Booch, Grady. et Rumbaugh, Jim., The unified software development process, Addison-Wesley, (ISBN 0-201-57169-2, 9780201571691 et 9780321822000, OCLC 636807532, lire en ligne)
  5. ↑ (en) Kendall Scott, « Overview of the Unified Process », sur informit.com,
  6. ↑ (en) « Understand the Unified Process (UP) and Rational Unified Process (RUP) », sur www.methodsandtools.com (consulté le )
  7. ↑ « phase de création », sur www.granddictionnaire.com (consulté le )
  8. ↑ « phase d'élaboration », sur www.granddictionnaire.com (consulté le )
  9. ↑ « phase de construction », sur www.granddictionnaire.com (consulté le )
  10. ↑ « phase de transition », sur www.granddictionnaire.com (consulté le )
  11. ↑ a et b Serena Villata, Ameni Bouaziz et Eric Valade, « Processus unifiés - Principes, Description, Déclinaison », sur inria.fr,
  12. ↑ a et b (en) Jacobson, Ivar., Booch, Grady. et Rumbaugh, Jim., The unified software development process, Addison-Wesley, (ISBN 0-201-57169-2, 9780201571691 et 9780321822000, OCLC 636807532, lire en ligne), pages 324-330 et 342-344
  13. ↑ Jacobson, Ivar., Booch, Grady. et Rumbaugh, James. (trad. de l'anglais par Zaïm, Virginie.), Le processus unifié de développement logiciel [« The unified software development project »], Paris, Eyrolles, , 488 p. (ISBN 2-212-09142-7 et 9782212091427, OCLC 45152206, lire en ligne)
  14. ↑ (en) Shane Hastie, « The Various Flavors of Unified Process », sur InfoQ (consulté le )
  15. ↑ a et b (en) Kroll, Per. et Kruchten, Philippe, The rational unified process made easy : a practitioner's guide to the RUP, Addison-Wesley, (ISBN 0-321-16609-4 et 9780321166098, OCLC 51242053, lire en ligne)
  16. ↑ (en) Ambler, Scott W., 1966- et Vizdos, Michael J., The enterprise unified process : extending the rational unified process, Prentice Hall PTR, , 384 p. (ISBN 978-0-13-191451-3 et 0131914510, OCLC 59822996, lire en ligne)
  17. ↑ « Enterprise Unified Process (EUP): Strategies for Enterprise Agile », sur www.enterpriseunifiedprocess.com (consulté le )
  18. ↑ (en) « Extreme Unified Process », sur wiki.c2.com (consulté le )
  19. ↑ a b c et d (en) « The Agile Unified Process (AUP) Home Page », sur www.ambysoft.com (consulté le )
  20. ↑ a b et c (en) « Essential Unified Process », sur Ivar Jacobson International, (consulté le )
  21. ↑ (en) Y. Hui, Y. Yan, W. Quanyu et C. Zhiwen, « Compare Essential Unified Process (EssUP) with Rational Unified Process (RUP) », 2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA),‎ , p. 472–476 (DOI 10.1109/ICIEA.2015.7334159, lire en ligne, consulté le )
  22. ↑ a et b (en) « Standards, compliance, and Rational Unified Process », sur www.ibm.com, (consulté le )
  23. ↑ Reference Modeling for Business Systems Analysis :, IGI Global, , 389 p. (ISBN 978-1-59904-054-7 et 9781599040561, DOI 10.4018/978-1-59904-054-7.ch005, lire en ligne)
  24. ↑ (en) « Introduction to business modeling using the Unified Modeling Language (UML) », sur www.ibm.com, (consulté le )
  25. ↑ a et b (en) Ivar Jacobson et Pan Wei Ng, « The Essential Unified Process », sur Dr. Dobb's (consulté le )
  26. ↑ a et b (en) Martin Fowler, « The New Methodology », sur martinfowler.com (consulté le )
  27. ↑ (en) Haoyang Che, « Review of "Agile Modeling: Effective Practice for eXtreme Programming and the Unified Process by Scott W. Ambler", John Wiley & Sons, Inc, 2002, 0-471-20282-7 », SIGSOFT Softw. Eng. Notes, vol. 30, no 4,‎ , p. 83–83 (ISSN 0163-5948, DOI 10.1145/1082983.1083029, lire en ligne, consulté le )
  28. ↑ (en) Michael Hirsch, « Making RUP Agile », OOPSLA 2002 Practitioners Reports, ACM, oOPSLA '02,‎ , p. 1–ff (ISBN 9781581134711, DOI 10.1145/604251.604254, lire en ligne, consulté le )
  29. ↑ (en) Mihai Liviu DESPA, « Comparative study on software development methodologies », Database Systems Journal,‎ (ISSN 2069-3230, lire en ligne)

Voir aussi modifier

Bibliographie modifier

Articles connexes modifier

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Processus_unifié&oldid=214253991 ».