UP : Unified Process

UP : Unified Process

Table des matires

1DFINITION.......................................................................................................................................................... 2 1.1UP est itratif ................................................................................................................................................ 2 1.2UP est centr sur l'architecture...................................................................................................................... 2 1.3UP est pilot par les cas d'utilisation d'UML.................................................................................................. 2 2VIE DU PROCESSUS UNIFI.............................................................................................................................. 3 2.1L'architecture bidirectionnelle........................................................................................................................ 3 3LES ACTIVITS.................................................................................................................................................... 4 3.1Expression des besoins................................................................................................................................. 4 3.2Analyse.......................................................................................................................................................... 4 3.3Conception..................................................................................................................................................... 5 3.4Implmentation.............................................................................................................................................. 5 3.5Test................................................................................................................................................................ 5 4LES PHASES........................................................................................................................................................ 5 4.1Analyse des besoins...................................................................................................................................... 5 4.2Elaboration..................................................................................................................................................... 5 4.3Construction................................................................................................................................................... 6 4.4Transition....................................................................................................................................................... 6 5ANNEXE 1............................................................................................................................................................ 7

UP : Unified Process

1 Dfinition
Le processus unifi est un processus de dveloppement logiciel itratif, centr sur l'architecture, pilot par des cas d'utilisation et orient vers la diminution des risques. C'est un patron de processus pouvant tre adapte une large classe de systmes logiciels, diffrents domaines d'application, diffrents types d'entreprises, diffrents niveaux de comptences et diffrentes tailles de l'entreprise.

1.1

UP est itratif

L'itration est une rptition d'une squence d'instructions ou d'une partie de programme un nombre de fois fix l'avance ou tant qu'une condition dfinie n'est pas remplie, dans le but de reprendre un traitement sur des donnes diffrentes. Elle qualifie un traitement ou une procdure qui excute un groupe d'oprations de faon rptitive jusqu' ce qu'une condition bien dfinie soit remplie.

Une itration prend en compte un certain nombre de cas d'utilisation et traite en priorit les risques majeurs.

1.2

UP est centr sur l'architecture

Ph. Kruchten propose diffrentes perspectives, indpendantes et complmentaires, qui permettent de dfinir un modle d'architecture (publication IEEE, 1995). http://uml.free.fr/cours/i-p7.html
Vue logique Vue des composants

Besoin des utilisateurs Vue des processus Vue des composants

1.3

UP est pilot par les cas d'utilisation d'UML

Le but principal d'un systme informatique est de satisfaire les besoins du client. Le processus de dveloppement sera donc accs sur l'utilisateur. Les cas d'utilisation permettent d'illustrer ces besoins. Ils dtectent puis dcrivent les besoins fonctionnels (du point de vue de l'utilisateur), et leur ensemble constitue le modle de cas d'utilisation qui dicte les fonctionnalits compltes du systme.

UP : Unified Process

<<use case>> Gerer athlete

<<interne>> Operateur CIO

<<extend>>

<<use case>> Gerer inscription

<<include>>

<<use case>> <<interne>> Comite de validation Gerer validation inscription

Exemple : gestion de l'inscription d'un athlte aux Jeux Olympique

2 Vie du processus unifi

L'objectif d'un processus unifi est de matriser la complexit des projets informatiques en diminuant les risques. UP est un ensemble de principes gnriques adapt en fonctions des spcificits des projets. UP rpond aux proccupations suivantes : - QUI participe au projet ? - QUOI, qu'est-ce qui est produit durant le projet ? - COMMENT doit-il tre ralis ? - QUAND est ralis chaque livrable ?

2.1

L'architecture bidirectionnelle

UP gre le processus de dveloppement par deux axes. L'axe vertical reprsente les principaux enchanements d'activits, qui regroupent les activits selon leur nature. Cette dimension rend compte l'aspect statique du processus qui s'exprime en terme de composants, de processus, d'activits, d'enchanements, d'artefacts et de travailleurs. L'axe horizontal reprsente le temps et montre le droulement du cycle de vie du processus; cette dimension rend compte de l'aspect dynamique du processus qui s'exprime en terme de cycles, de phases, d'itrations et de jalons.

UP : Unified Process

UP rpte un certain nombre de fois une srie de cycle qui s'articule autours de 4 phases - analyse des besoins - laboration - construction - transition Pour mener efficacement un tel cycle, les dveloppeurs ont besoins de toutes les reprsentations du produit logiciel - un modle de cas d'utilisation - un modle d'analyse : dtailler les cas d'utilisation et procder une premire rpartition du comportement - un modle de conception : finissant la structure statique du systme sous forme de soussystmes, de classes et interfaces. - un modle d'implmentation : intgrant les composants - un modle de dploiement : dfinissant les nuds physiques des ordinateurs - un modle de test : dcrivant les cas de test vrifiant les cas d'utilisation - une reprsentation de l'architecture

3 Les activits
3.1 Expression des besoins

L'expression des besoins comme son nom l'indique, permet de dfinir les diffrents besoins : - inventorier les besoins principaux et fournir une liste de leurs fonctions - recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent l'laboration des modles de cas d'utilisation - apprhender les besoins non fonctionnels (technique) et livrer une liste des exigences. Le modle de cas d'utilisation prsente le systme du point de vue de l'utilisateur et reprsente sous forme de cas d'utilisation et d'acteur, les besoins du client.

3.2

Analyse

L'objectif de l'analyse est d'accder une comprhension des besoins et des exigences du client. Il s'agit de livrer des spcifications pour permettre de choisir la conception de la solution. Un modle d'analyse livre une spcification complte des besoins issus des cas d'utilisation et les structure sous une forme qui facilite la comprhension (scnarios), la prparation (dfinition de l'architecture), la modification et la maintenance du futur systme.

UP : Unified Process

Il s'crit dans le langage des dveloppeurs et peut tre considr comme une premire bauche du modle de conception.

3.3

Conception

La conception permet d'acqurir une comprhension approfondie des contraintes lies au langage de programmation, l'utilisation des composants et au systme d'exploitation. Elle dtermine les principales interfaces et les transcrit l'aide d'une notation commune. Elle constitue un point de dpart l'implmentation : - elle dcompose le travail d'implmentation en sous-systme - elle cre une abstraction transparente de l'implmentation

3.4

Implmentation

L'implmentation est le rsultat de la conception pour implmenter le systme sous formes de composants, c'est--dire, de code source, de scripts, de binaires, d'excutables et d'autres lments du mme type. Les objectifs principaux de l'implmentation sont de planifier les intgrations des composants pour chaque itration, et de produire les classes et les sous-systmes sous formes de codes sources.

3.5

Test

Les tests permettent de vrifier des rsultats de l'implmentation en testant la construction. Pour mener bien ces tests, il faut les planifier pour chaque itration, les implmenter en crant des cas de tests, effectuer ces tests et prendre en compte le rsultat de chacun.

4 Les phases
4.1 Analyse des besoins

L'analyse des besoins donne une vue du projet sous forme de produit fini. Cette phase porte essentiellement sur les besoins principaux (du point de vue de l'utilisateur), l'architecture gnrale du systme, les risques majeurs, les dlais et les cots On met en place le projet. Elle rpond aux questions suivantes : - que va faire le systme ? par rapport aux utilisateurs principaux, quels services va-t-il rendre? - quelle va tre l'architecture gnrale (cible) de ce systme - quels vont tre : les dlais, les cots, les ressources, les moyens dployer?

4.2

Elaboration

L'laboration reprend les lments de la phase d'analyse des besoins et les prcise pour arriver une spcification dtaille de la solution mettre en uvre. L'laboration permet de prciser la plupart des cas dutilisation, de concevoir larchitecture du systme et surtout de dterminer l'architecture de rfrence. Au terme de cette phase, les chefs de projet doivent tre en mesure de prvoir les activits et destimer les ressources ncessaires lachvement du projet. Les taches effectuer dans la phase laboration sont les suivantes : - crer une architecture de rfrence - identifier les risques, ceux qui sont de nature bouleverser le plan, le cot et le calendrier - dfinir les niveaux de qualit atteindre

UP : Unified Process

formuler les cas d'utilisation pour couvrir les besoins fonctionnels et planifier la phase de construction laborer une offre abordant les questions de calendrier, de personnel et de budget

4.3

Construction

La construction est le moment o lon construit le produit. Larchitecture de rfrence se mtamorphose en produit complet. Le produit contient tous les cas dutilisation que les chefs de projet, en accord avec les utilisateurs ont dcid de mettre au point pour cette version.

4.4

Transition

Le produit est en version bta. Un groupe dutilisateurs essaye le produit et dtecte les anomalies et dfauts. Cette phase suppose des activits comme la formation des utilisateurs clients, la mise en uvre dun service dassistance et la correction des anomalies constates.

UP : Unified Process

5 Annexe 1
- Recenser les besoins potentiels et fournir une liste des fonctions - Comprendre le contexte du systme en produisant un modle du mtier ou du domaine - Apprhender les besoins fonctionnels qui conduisent l'laboration des modles de cas d'utilisation - Apprhender les besoins non fonctionnels et livrer une liste des exigences supplmentaires. - Livre une spcification plus prcise des besoins - S'crit dans le langage des dveloppeur et doit servir de base une rflexion sur les mcanismes internes du systme - Structure les besoins et les exigences sous une forme qui facilite la comprhension, la prparation, la modification et la maintenance - Peut envisag comme une premire bauche du modle de conception - Dlimiter la porte du systme proposer : dfinir les frontires et identifier les interfaces - Dcrire et esquisser l'architecture candidate - Identifier les risques les plus srieux - Dmontrer que le systme propose est en mesure de rsoudre les problmes ou de prendre en charge les objectifs fixs - Crer une architecture de rfrence - Identifier les risques, ceux qui sont de nature bouleverser le plan, le cot et le calendrier - Dfinir les niveaux de qualit atteindre - Formuler les cas d'utilisation pour couvrir environ 80% des besoins fonctionnels et de planifier la phase de construction - Elaborer une offre abordant les questions de calendrier, de personnel et de budget - Extension de l'identification, de la description et de la ralisation des cas d'utilisation - Finalisation de l'analyse, de la conception de l'implmentation et des tests - Prservation de l'intgrit de l'architecture - Surveillance des risques critiques et significatifs identifis dans les deux premires phases et rduction des risques

- Prparation des activits - Recommandations au client sur la mise jour de l'environnement logiciel - Elaboration des manuels et de la documentation concernant la version du produit - Adaptation du logiciel - Correction des anomalies lies au bta test - Dernires corrections

- Acqurir une comprhension approfondie des questions - constituer une base et un point de dpart - Dcomposer le travail d'implmentation en portions plus agrables - Dterminer trs tt dans le cycle de vie du logiciel, les principales interfaces - Visualiser et penser la conception l'aide d'une notation commune - Crer une abstraction transparente de l'implmentation

- Planifier les intgrations - Distribuer le systme - Implmenter les classes et les sous systmes - Tester les composants unit par unit

- Planifier les tests ncessaires pour chaque itration - Concevoir et implmenter les tests en crant des cas de test - Effectuer divers test et prendre en compte le rsultat de chacun