Une m thode de conception pour :

• Maitriser le co t, qualit et d lais dun projet de d veloppement logiciel.
• Diviser le projet en composants et par la suite planifier les quipes de d veloppement en fonction de ces composants.

(G rer le rapport effort/homme).

• Savoir les cl s de d veloppement logiciel : Qui fait Quoi Comment et quelle moment >jsynchronisation des quipes.
• Optimiser le processus de prise de d cision : la meilleure d cision dans le bon moment (Gestion de projet)

1. Pr sentation g n rale dUP

• La vie dun logiciel est compos e de cycles
• Chaque cycle est une version

Voici le sch ma dun cycle avec ses 4 phases :

Etude Pr liminaire

(INCEPTION)

Elaboration

Construction

Transition

Un Cycle

• Chaque phase du cycle est compos e dit rations (incr ments)
• Chaque it ration est une succession dactivit s ; une mini-cascade qui comporte toutes les activit s
• Une it ration conduit une version montrable impl mentant un certain nombre de CU

Capture des besoins

Analyse

Une it ration

Conception

R alisation

Test et int gration

• Chaque activit est r alis e avec une importance lors dune it ration
• Efforts par it ration dans une phase


1. Etude des phases dun cycle UP

| | |

| --- | --- |

| Phase1 : Etude Pr liminaire | Phase tr s courte (souvent 1 it ration) Etude de faisabilit , de risques et p rim tres de projet |

| Phase 2 : Elaboration | Quelques it rations courtes Identification des besoins Conception de larchitecture de base Programmation et test des composants logiciels les plus importants * Estimation des d lais et co ts |

| Phase3 : Construction | Phase la plus co teuse (+50% du cycle) D veloppement par incr ment * Produit suffisamment correcte pour tre install |

| Phase4 : Transition | produit d livr en version b ta correction, am lioration, formation des utilisateurs, pr paration des manuels |

1. Description d taill e des activit s dune it ration

Part des activit s dune it ration / Phases


6.1. Lactivit Capture et analyse des besoins

But :

• Identifier (d finir le p rim tre) le syst me construire
• D finir les besoins fonctionnels et non fonctionnels

Capture et analyse des besoins :

• Formulation des souhaits du client en besoin
• Passer dun langage informel redondant (langage client) un langage formel et non redondant (structuration par classes).
• Elaboration dun cahier de charge ; compromis entre le client et lanalyste

Remarque

\\Capture des besoins : Le mod le des CU repr sente le syst me vu de lext rieur, son insertion dans lorganisation, ses fronti res fonctionnelles.

\\Analyse : le mod le danalyse repr sente le syst me vu de lint rieur. Les objets sont des abstractions des concepts manipul es par les utilisateurs. Point de vue statique et dynamique sur les comportements.

Art facts/livrables :

• Mod les de domaine (business logic) du syst me construire
• Mod le de cas dutilisation syst me+les divers descriptions (textuelle/diagramme de s quence)
• Glossaire des mots cl s
• Cahier de charges

6.2. Lactivit Conception

But :

• Appr hender la logique comportementale (interactions entre objets)
• Identifier le design pattern adopt (d cision de premier ordre)
• R fl chir sur la logique structurelle (architecture logique et physique)

Conception de lapplication:

• Pendant cette phase, le syst me nest plus une boite noire
• D cortiquer le syst me en objets tout en pr cisant la relation entre eux et les responsabilit s de chaque objet.
• Qui cr e les objets ?
• Qui permet dacc der un objet ?
• Quel objet re oit un message provenant de lIHM ?
• Elaboration de mod les de conception (ajouter les visibilit s, les m thodes, les interfaces, les contr leurs, lier le mod le de s quence avec le mod le de classes, etc.)
• Concevoir les mod les architecturaux (diagrammes de package en couche, diagramme de d ploiement et de composants ou les deux coupl s) voir les exemples ci-dessous.


Exemple de diagramme de package pour une architecture en couche


Exemple de diagramme de d ploiement

Art facts/livrables :

• Diagrammes de s quence
• Diagrammes de classes participantes (de lapplication)
• Diagrammes de package
• Diagramme dinteraction
• Diagramme de d ploiement/de composants

6.3. Lactivit R alisation

But :

• Impl menter les cas dutilisations
• V rifier si le code et conforme aux besoins

Capture et analyse des besoins :

• Codage de classes avec g n ration automatique dun squelette de code (Reverse Engineering)
• Compl ter le squelette g n r
• Elaboration des fiches de test des fonctionnalit s d velopp es
• Retravailler le code selon le r sultat du test

Art facts/livrables :

• Code source
• Fiche de test

1. Description d taill e de chaque phase

7.1. Phase 1 : Etude Pr liminaire (Inception)


Objectif : lancer le projet

• D limiter le syst me
• D terminer que fait le syst me?
• A quoi pourrait ressembler larchitecture?
• Quels sont les risques?
• Quel est le co t estim du projet? Comment le planifier?

>jPhase tr s courte (1 it ration)

>jA la fin de cette phase on d cide de continuer ou non (la faisabilit )

Activit s principales de l tude pr liminaire

Capture et analyse des besoins

• Comprendre le contexte du syst me (50-70% du contexte)
• Identifier les cas dutilisation (80%)
• Identifier les besoins non fonctionnels (80%)
• D tailler et analyser les cas les plus importants (10%)

Analyse et Conception Orient es Objet

• Entamer la conception architecturale
• Architectures logique et de d ploiement

7.2. Phase 2 : Elaboration


Objectif : Cerner le projet

• Identifier et stabiliser les besoins
• Planifier les phases du projet et estimer les co ts
• Choisir larchitecture ad quate

Phase courte : quelques it rations de quelques semaines

Activit s principales de l laboration

Capture et analyse des besoins

• Compl ter la liste des cas dutilisation
• Description abr g e des cas dutilisation
• Description d taill e / Diag. de s quences de 40 80%
• Faire un prototype de linterface utilisateur

Analyse et Conception Orient es Objet

• Stabiliser la conception architecturale
• Architectures logique et de d ploiement
• Effectuer la conception des cas s lectionn s

R alisation et test

• Limit s au squelette de larchitecture
• Valider les choix

7.3. Phase 3 : Construction


Objectif : R aliser une version b ta

>jPhase la plus couteuse englobe conception, codage, tests, int gration.

Activit s principales de la construction

Capture et Analyse des besoins

• Sp cifier linterface utilisateur
• Terminer lanalyse de tous les cas dutilisation

Analyse et Conception Orient es Objet

• Larchitecture est fix e
• Concevoir les packages et classes pour r aliser les cas
• Selon lordre de priorit

R alisation et Tests

• R aliser et tester les cas, int grer les incr ments

7.4. Phase 4 : Transition


Objectif : Mise en service chez lutilisateur

• Test de la b ta-version, correction des erreurs
• Pr parer la formation, la commercialisation

Activit s principales de la transition

• Pr parer la version b ta tester
• Installer la version sur le site client, convertir et faire migrer les donn es n cessaires (Livraison)
• G rer le retour des sites (retour client) et Corriger le reliquat derreurs
• Adapter le produit corrig aux contextes utilisateurs (installation)
• Am liorer le produit
• Terminer les livrables du projet (mod les, documents...)
• D terminer la fin du projet
• former les utilisateurs
• Planifier le prochain cycle de d veloppement

\\\R capitulation\\\


1. Caract ristiques dUP

1. UP est guid par les cas dutilisation

• Objectif du processus : la construction dun syst me qui r ponde des besoins par construction complexe de mod les
• CU utilis s tout au long du cycle
• Validation des besoins / utilisateurs
• Point de d part pour lanalyse (d couverte des objets, de leurs

relations, de leur comportement) et la conception (sous

syst mes)

• Guide pour la construction des interfaces
• Guide pour la mise au point des plans de tests
• Les cas dutilisation lient les mod les


• 1. UP est centr sur larchitecture
• Larchitecture sert de lien pour lensemble des membres du projet
• Contrainte de larchitecture : plus le projet avance, plus larchitecture est difficile modifier >jles risques li s larchitecture sont tr s lev s, car tr s co teux
• Objectif pour le projet : tablir d s la phase d laboration des fondations solides et volutives pour le syst me d velopper, en favorisant la r utilisation
• Construire une architecture comme forme dans laquelle le syst me doit sincarner
• Les CU r alis s doivent y trouver leur place
• La r alisation des CU suivant doit sappuyer sur larchitecture
• Qui permette de promouvoir la r utilisation
• Qui ne change pas trop : converger vers une bonne architecture rapidement

1. UP est it ratif, incr mental

| |

| --- |

| Anti-cascade, spirale Construction progressive du syst me Chaque it ration permet de ma triser une partie des risques et apporte une preuve tangible de faisabilit . >j Produit un syst me partiel op rationnel (ex cutable, test et int gr ) avec une qualit gale celle dun produit fini (alpha) (qui peut tre valu : permet de savoir si on va dans la bonne direction ou non) S rie de prototypes qui vont en sam liorant de plus en plus de fonctionnalit s disponibles  |