2tup Archi Dev1 4

le : 12/12/2000 Projet : Plan Assurance Qualit
Projet : Document : VERSION Objet
Plan Assurance Qualit 2UP_ARCHI_DEV1 1.00 Ce document a pour objectif de dfinir la dmarche TOW TRACK UNIFIED PROCESS.
Auteur Eric PAPET
Vrifi par: Dominique MASSON
Valid par: Socit: Fonction: Date: Signature
Guillaume FOURQUET IEP Grant, ingnieur informaticien
Liste de diffusion
Rfrence :C:\projets\dev1-0\paq\2TUP_ARCHI_DEV1.doc Page 1 sur 8 DEV1.0 - Technopole Izarbel - 64210 BIDART SARL au Capital de 8000 - SIRET 432 897 056 00011 - APE 722Z e.papet@dev1-0.com
Gestion des modifications apportes au document

Auteur Date Modification Eric PAPET 12/12/2000 Descriptions Cration du document Version document 1.00
SOMMAIRE
GESTION DES MODIFICATIONS APPORTES AU DOCUMENT ........................................................... 2 SOMMAIRE.......................................................................................................................................................... 3 INTRODUCTION AUX PROCESSUS UNIFIS.............................................................................................. 4 PROCESSUS DE DVELOPPEMENT LOGICIEL ......................................................................................................... 4 PROCESSUS UNIFI (UNIFIED PROCESS) .............................................................................................................. 5 LE PROCESSUS 2TUP........................................................................................................................................ 6 BRANCHE FONCTIONNELS (GAUCHE): ................................................................................................................. 7 BRANCHE ARCHITECTURE TECHNIQUE (DROITE) :............................................................................................... 7 BRANCHE CONCEPTION (MILIEU) : ...................................................................................................................... 7 ANALYSE : .......................................................................................................................................................... 8 CAPTURE DES BESOINS TECHNIQUES : ................................................................................................................. 8 CONCEPTION GNRIQUE : .................................................................................................................................. 8 CONCEPTION PRLIMINAIRE :.............................................................................................................................. 8 CONCEPTION DES CLASSES :................................................................................................................................ 8
Introduction aux processus unifis

La complexit croissante des systmes informatiques a conduit les concepteurs sintresser aux mthodes. On comptabilis en 1994 jusqu 50 mthodes. Chaque mthode se dfinit par une notation et un processus spcifique. UML a ouvert le terrain en fusionnant la notation. Il reste cependant dfinir le processus pour rellement capitaliser des rgles dans le domaine du dveloppement logiciel. Les groupe de travail UML(les 3 amigos) ont donc travaill unifier non pas les processus, mais plus exactement les meilleures pratiques de dveloppement objet. Ces processus ce distingueront par le gnrique < UNIFIED PROCESS >. Nous dvelopperons ici le < Two Track Unified Process >. Processus de dveloppement logiciel Un processus dfinit une squence dtapes, en partie ordonn, qui concoure lobtention dun systme logiciel ou lvolution dun systme existant. Pour produire des logiciels de qualit, qui rpondent aux besoins des utilisateurs dans des temps et des cots prvisibles. On dcoupe le processus en deux axes : Laxe de dveloppement technique, qui de concentre principalement sur la qualit de production. Laxe de gestion du dveloppement, qui permet la mesure et la prvision des cots et des dlais.
le : 12/12/2000 Projet : Plan Assurance Qualit Processus Unifi (Unified Process) Un processus unifi est un processus de dveloppement logiciel construit sur UML. Il est : Itratif ; Centr sur larchitecture ; Conduit par les cas dutilisation et pilot par les risques. La gestion dun tel processus est organise suivant 4 phases : Pr tude ; Elaboration ; Construction ; Transition. Les activits de dveloppement sont dfinies par 5 workflows fondamentaux qui dcrivent : La capture des besoins ; Lanalyse ; La conception ; Limplmentation ; Le test. Tout processus UP rpond aux caractristiques ci prs : Il est incrmental. La dfinition dincrments de ralisation est en effet la meilleure pratique de gestion des risques techniques et fonctionnels. Il est pilot par les risques. Les causes majeures dchec dun projet logiciel doivent tre cartes en priorits ; les deux principales causes sont lincapacit de larchitecture technique rpondre aux contraintes oprationnelles et linquation du dveloppement aux besoins utilisateurs. Il est construit autour de la cration et de la maintenance dun modle, plutt que de la production de montage de documents. Il est itratif. Chaque itration porte sur un niveau dabstraction de plus en plus prcis. Il est orient composant. Il est orient utilisateur.
Le processus 2TUP
Le processus 2TUP apporte une rponse aux contraintes de changement continuel imposes aux systmes dinformation de lentreprise. Ce processus suit deux chemins. Architecture fonctionnel Architecture technique
Contexte Cas dutilisation Analyse du domaine Analyse de lapplication
Spcification fonctionnelle Structurel
Spcification logicielle
Matriel
ti
Logique
Exploitation
Dploiement
Conception systme
Configuration logicielle
Conception des composants
le : 12/12/2000 Projet : Plan Assurance Qualit Branche fonctionnels (gauche): Capture des besoins fonctionnels, qui produit le modle des besoins focalis sur le mtier des utilisateurs. Elle qualifie, au plus tt le risque de produire un systme inadapt aux utilisateurs Lanalyse, qui consiste tudier prcisment la spcification fonctionnelle de manire obtenir une ide de ce que va raliser le systme en terme de mtier. Branche architecture technique (droite) : La capture des besoins techniques, qui recense toutes les contraintes sur les choix de dimensionnant et la conception du systme. Les outils et le matriels slectionns ainsi que la prise en compte des contraintes dintgration avec lexistant (pr requis darchitecture technique). La conception gnrique, qui dfinit ensuite les composants ncessaires la construction de larchitecture technique. Cette conception est compltement indpendante des aspect fonctionnel. Elle a pour objectif de duniformiser et de rutiliser les mmes mcanismes pour tout un systmes. Larchitecture technique construit le squelette du systme, son importance est telle quil est conseill de raliser un prototype. Branche conception (milieu) : La conception prliminaire, qui reprsente une tape dlicate, car elle intgre le modle danalyse fonctionnelle dans larchitecture technique de manire tracer la cartographie des composants du systme dvelopper. La conception dtaille, qui tudie ensuite comment raliser chaque composant. Ltape de codage, qui produit ses composants et teste au fur et mesure les units de code ralises. Ltape de recette, qui consiste enfin valider les fonctionnalits du systme dvelopper.
Capture des besoins fonctionnels : Le niveau contexte a pour objet de dfinir la frontire fonctionnelle entre le systme considr comme une bote noire et son environnement. Le niveau cas dutilisation dfinit ensuite les activits attendues des diffrents utilisateurs par rapport au systme toujours envisag comme une bote noire. Analyse : Ouvre le systme pour tablir la structure des objets utiliss. Le modle danalyse du domaine dfinit la structure et le comportement des objets connus dans le mtier des utilisateurs du systme. Le modle danalyse de lapplication y rajoute, suivant le mme processus les objets qui sont connus des utilisateurs, dans le cadre de la mise en application de leurs besoins. Capture des besoins techniques : Le modle danalyse technique tablit des couches logicielles et y spcifie les activits techniques attendues. Conception gnrique : Le modle de conception technique dfinit les composants qui, dlivrant des services techniques, assurent la rponse aux exigences oprationnelles du systme. Conception prliminaire : Le modle de conception systme organise le systme en composants, dlivrant les services techniques et fonctionnels. Ce modle regroupe les informations de la branche de droite et de la branche de gauche. Elle peut tre considr comme la transformation du modle danalyse par projection des classes danalyse sur les couches logicielles. Conception des classes : Le modle de conception des composants fournit limage prte fabriquer du systme complet.

2tup Archi Dev1 4

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2tup Archi Dev1 4

Transféré par

Droits d'auteur :

Formats disponibles

le : 12/12/2000 Projet : Plan Assurance Qualit

Projet : Document : VERSION Objet

Auteur Eric PAPET

Vrifi par: Dominique MASSON

Valid par: Socit: Fonction: Date: Signature

Guillaume FOURQUET IEP Grant, ingnieur informaticien

le : 12/12/2000 Projet : Plan Assurance Qualit

Gestion des modifications apportes au document

le : 12/12/2000 Projet : Plan Assurance Qualit

le : 12/12/2000 Projet : Plan Assurance Qualit

Introduction aux processus unifis

le : 12/12/2000 Projet : Plan Assurance Qualit

Contexte Cas dutilisation Analyse du domaine Analyse de lapplication

Spcification fonctionnelle Structurel

Conception des composants

le : 12/12/2000 Projet : Plan Assurance Qualit

Vous aimerez peut-être aussi