C’est quoi le Processus Unifié ?

Rappel : UML est un langage de modélisation et n’impose pas de démarche de développement

Présentation

Unified process ou processus unifié en français est un processus de conception et de réalisation de logiciels développés avec des langages de programmation orientés objet (Java par exemple). C’est un guide méthodologique pour réaliser des logiciels en conseillant et pilotant l’équipe dans ses différentes activités pour réduire la complexité du projet (on sait où on en est et ce qu’il nous reste à faire). Ce processus permet d’éclaircit qui fait quoi, et permet à chacun de savoir quelle est sa place dans le processus de production du logiciel. On notera que Merise a uniquement pour but de concevoir l’application.

Le processus unifié 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 phases de création, d’une phase d’élaboration, d’une phase de construction et d’une phase de transition, comprenant chacune plusieurs itérations.

Caractéristiques

Basé sur le langage UML

Guidé par des cas d’utilisation : Les besoins (exigences) des utilisateurs permettent de définir des cas d’utilisation. A partir des ces cas d’utilisation, une série de modèles UML peuvent être crées. L’objectif principal d’un système logiciel est de rendre service à ses utilisateurs ; il faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de développement sera donc centré sur l’utilisateur. Le terme utilisateur ne désigne pas seulement les utilisateurs humains mais également les autres systèmes. L’utilisateur représente donc une personne ou une chose dialoguant avec le système en cours de développement. Les cas d’utilisation permettent d’illustrer les besoins. Ils détectent puis décrivent les besoins fonctionnels (du point de vue de l’utilisateur), et leur ensemble constitue le modèle de cas d’utilisation qui dicte les fonctionnalités complètes du système. Les utilisateurs doivent être fortement impliqués dans le processus unifié pour garantir la qualité du futur logiciel.

Centré sur l’architecture : Cette architecture doit prévoir la réalisation de tous les cas d’utilisation. L’architecture et les cas d’utilisation évoluent donc de façon concomitante. Dès le démarrage du processus, on aura une vue sur l’architecture à mettre en place. L’architecture d’un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. L’architecture logicielle équivaut aux aspects statiques et dynamiques les plus significatifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation. Tout produit est à la fois forme et fonction. Les cas d’utilisation doivent une fois réalisés, trouver leur place dans l’architecture. L’architecture doit prévoir la réalisation de tous les cas d’utilisation. L’architecture et les cas d’utilisation doivent évoluer de façon concomitante.

Piloté par les risques

Itérative et incrémentale : Contrairement à la méthode MERISE qui est séquentielle. Itérative puisque chaque phase de la démarche UP comprend des itérations. Chaque phase est ponctuée par un jalon qui marquera la décision que les objectifs initiaux ont été remplis. Une itération a pour but de maîtriser une partie des risques et apporte une preuve tangible de faisabilité. Une itération est un cycle de développement logiciel (ou système) complet depuis le recueil des besoins jusqu’à l’implantation et aux tests. L’itération se termine par la sortie d’une version exécutable du projet, c’est à dire un prototype (exécutable, testé et intégré) avec une qualité égale à celle d’un produit fini et pouvant être évalué. Une itération reprend les livrables dans l’état où les a laissé l’itération précédente et les enrichit progressivement. Les premières itérations donnent des prototypes permettant l’expérimentation par les utilisateurs ainsi que la validation des technologies. Ces prototypes définissent alors le noyau de l’architecture. Incrémentale puisqu’il un incrément du projet par itération, c’est à dire que le logiciel et le modèle évoluent suivant des incréments. C’est le développement d’une série de prototypes qui vont en s’améliorant.

OpenUp

OpenUp est un guide qui décrit comment utiliser le Processus Unifié. Il donne l’ensemble des rôles nécessaires avec les activités que chacun doit réaliser et les livrables qu’il doit fournir. OpenUp est applicable aussi bien pour de tout petits projets comme des grands. OpenUp est disponible ici.

Fonctionnement

Le cycle de vie de la méthode UP se décompose en 4 phases principales au cours desquelles 6 activités d’ingénierie sont mises en oeuvre. Un certain nombre d’itérations est effectué à l’intérieur de chaque phase. Chaque itération met en oeuvre certaines activités.

Les phases

1) Phase de pré-étude (ou inception)

L’objectif de cette phase est de définir le cadre du projet, comprendre le problème et décider du go ou no go du projet. Elle dure environ 1 mois pour un projet d’un an.

Le Glossaire

Un glossaire est un lexique spécialisé. Il donne soit la définition, soit la traduction d’un terme. Il permet d’aider vos lecteurs et vos clients à mieux comprendre votre métier, ou votre domaine d’activité.

https://www.kabane.ca/glossaire-a-quoi-ca-sert
La Vision

La vision permet d’identifier les utilisateurs, les parties prenantes, les objectifs et le mode de suivi et de contrôle des budgets et dépenses du projet).

Descriptif du besoin :

  • Qui est le client ?
  • Quel est son besoin ?
  • Quelle solution apportée pour répondre au besoin ?

Descriptif de la solution :

  • Que propose la solution ?
  • Qui sont les futurs utilisateurs ?
  • Quels sont les impacts ?
  • Qui sont les concurrents ?

Descriptif des parties prenantes :

  • Qui sont les intervenants dans le cadre du projet ?
  • Quelles sont les responsabilités de chaque intervenant ?

Descriptif des cas d’utilisation :

  • Quels sont les différents cas d’utilisations de la solution ?
  • Quels sont les besoins fonctionnels et non fonctionnels ?
  • Quel est le cas d’utilisation qui découle du besoin fonctionnel ?
  • Quelle est la priorité de chaque cas d’utilisation ?
  • Pour chaque cas d’utilisation, quelles sont les fonctionnalités à développer ?
Le Plan projet

Le plan projet permet de déterminer pour chaque phase du Processus Unifié, le nombre d’itérations, les objectifs, la durée et les risques potentiels.

Descriptif des itérations :

  • Quelles sont les différentes itérations envisagées pour chacune des phases du processus unifiée ?
  • Quels sont les objectifs de chaque itération ?
  • Quelle est la durée estimée de chaque itération ?

Planification de la prochaine itération :

  • Quelles sont les tâches de la prochaine itération ?
  • Quelle est la priorité de chaque tâche ?
  • Qui est le responsable de la tâche ?
  • Pour chaque tâche, quels sont les documents de référence ?
  • Pour chaque tâche, quels sont les livrables attendus ?

Descriptif des risques de la prochaine itération :

  • Quels sont les différents risques potentiels de l’itération à venir ?

Le Plan d’itération, le diagramme des cas d’utilisation avec les principaux cas d’utilisation identifiés, le diagramme Acteur-Système pour un cas d’utilisation / Scénarios et enfin l’affectation du travail. Préparer jalon : Objectif; Périmètre; risques

Evaluer le projet : estimer les ressources nécessaires (financières, humaines, matérielles), définition d’un plan (petite planification) et estimation des risques

La diagramme des cas d’utilisation

Représenter les besoins fonctionnels de la solution dans un diagramme des cas d’utilisation UML basé sur l’ensemble des informations identifiées précédemment.

Livrables :

  • une première version du modèle du domaine ou de contexte de l’entreprise
  • la liste des besoins fonctionnels et non-fonctionnels
  • une ébauche des modèles de cas, d’analyse et de conception
  • une esquisse d’une architecture
  • une liste ordonnée de risques et une liste ordonnée de cas
  • les grandes lignes d’une planning pour un projet complet
  • une première évaluation du projet, estimation grossière des coûts
  • un glossaire

2) Phase d’élaboration : analyser le système et développer le plan du projet

Objectif : analyser le domaine du problème et comprendre la solution

Durée : 2 à 4 mois pour un projet d’un an

Tâches de l’activité de capture des besoins :

  • terminer la capture des besoins fonctionnels et en détailler de 40 à 80% en cas d’utilisation (~ quelques dizaines de CU)
  • réaliser les principaux scénarios (~ une centaine de scénarios principaux et quelques centaines de scénarios secondaires)
  • faire un prototype de l’interface utilisateur (éventuellement)
  • planifier le projet en élaborer une offre abordant les questions de calendrier, de personnel et de budget et éliminer ses plus hauts risques

Tâches de l’activité d’analyse :

  • analyse architecturale complète (packages…)
  • raffinement des cas d’utilisation (pour l’architecture, < 10%)

Tâches de l’activité de conception :

  • terminer la conception architecturale
  • réaliser modèle de classes (~ cinquante à cent classes)
  • définir l’architecture du produit
  • effectuer la conception correspondant aux cas sélectionnés

Tâches de l’activité de réalisation :

  • établir et se limiter à un squelette de l’architecture
  • faire en sorte de pouvoir valider les choix

Tâches de l’activité de test :

  • du squelette réalisé (attention, peut être coûteux)

Livrables :

  • Un modèle de l’entreprise ou du domaine complet
  • Une version des modèles : cas, analyse et conception (<10%), déploiement, implémentation (<10%)
  • Une architecture de base exécutable
  • La description de l’architecture (extrait des autres modèles) : document d’architecture logicielle
  • Une liste des risques mise à jour
  • Un projet de planning pour les phases suivantes
  • Un manuel utilisateur préliminaire (optionnel)
  • Évaluation du coût du projet

3) Phase de construction : développement du système

Objectif : réaliser la solution (version béta)

Durée : 6 à 9 mois pour un projet d’un an

Tâches de l’activité de capture des besoins :

  • spécifier l’interface utilisateur

Tâches de l’activité d’analyse :

  • terminer l’analyse de tous les cas d’utilisation, la construction du modèle structurel d’analyse

Tâches de l’activité de conception :

  • l’architecture est fixée et il faut concevoir les sous-systèmes
  • dans l’ordre de priorité (itérations de 1 à 3 mois, max. 9 mois)
  • concevoir les cas d’utilisation puis les classes

Tâches de l’activité de réalisation :

  • réaliser, passer des tests unitaires, intégrer les incréments

Tâches de l’activité de test :

  • toutes les activités de test : plan, conception, évaluation…

Livrables :

  • Un plan du projet pour la phase de transition
  • L’exécutable et son packaging minimal
  • Tous les documents et les modèles du système
  • Une description à jour de l’architecture
  • Un manuel utilisateur suffisamment détaillé pour les tests
  • Réaliser un plan de déploiement

4) Phase de transition : livraison du système aux utilisateurs finaux

Objectif : mise en service de la solution

Durée : 1 mois pour un projet d’un an

Tâches des activités de conception, réalisation et tests :

  • Préparer la version beta à tester : installer la version sur le site, convertir et faire migrer les données
  • Gérer le retour des sites (retour de déploiement) : Le système fait-il ce qui était attendu ? Erreurs découvertes ? Adapter le produit corrigé aux contextes utilisateurs (installation…)
  • Terminer les livrables du projet (modèles, documents…)
  • Déterminer la fin du projet
  • Reporter la correction des erreurs trop importantes (nouvelle version)
  • Organiser une revue de fin de projet (pour apprendre)
  • Planifier le prochain cycle de développement

Livrables :

  • L’exécutable et son programme d’installation
  • Les documents légaux : contrat, licences, garanties, etc.
  • Un jeu complet de documents de développement à jour
  • Les manuels utilisateur (manuel d’utilisation), administrateur (manuel d’installation) et opérateur et le matériel d’enseignement
  • Les références pour le support utilisateur (site Web…)

Sources

Leave a Comment