Methodes de gestion de projets - introduction au processus unifié

Méthodes de conduite de projet

1

Mireille Blay-FornarinoIUT Nice-Sophia Antipolis

[email protected]://www.polytech.unice.fr/~blay

Site web du module : http://anubis.polytech.unice.fr/iut/2010_2011/s1/omgl

Où les enseignements prennent leur place

mercredi 29 septembre 2010

mailto:[email protected]


http://www.polytech.unice.fr/~blay

http://www.polytech.unice.fr/~blay

http://anubis.polytech.unice.fr/iut/2010_2011/s1/omgl

http://anubis.polytech.unice.fr/iut/2010_2011/s1/omgl

Cycle de Vie. Méthodes Processus Unifié Exemple

Projet en général : qq définitionsProjet : ensemble d’actions à entreprendre afin de répondre à un besoin défini (avec une qualité suffisante), dans un délai fixé, mobilisant des ressources humaines et matérielles, possédant un coût.

Maître d’ouvrage : personne physique ou morale propriétaire de l’ouvrage. Il détermine les objectifs, le budget et les délais de réalisation.

Maître d’oeuvre : personne physique ou morale qui reçoit mission du maître d’ouvrage pour assurer la conception et la réalisation de l’ouvrage.

Conduite de projet : organisation méthodologique mise en oeuvre pour faire en sorte que l’ouvrage réalisé par le maître d’oeuvre réponde aux attentes du maître d’ouvrage dans les contraintes de délai, coût et qualité.

2



UML : «No silver bullet» Connaître UML n’est pas suffisant pour réaliser de bonnes conceptions

Il faut en plus savoir maîtriser/contrôler le processus de développement d’un projet

Cycle de vie du logicielPériode entre l’idée du logiciel et sa mise en service

3


Cycle de vie du logiciel

1) Activités2) Différents types de cycles

4



5

Activités du cycle de vie du logiciel1) Définition des besoins (Requirements)

Expression des besoins dans le langage du client

2) SpécificationsTraduction des besoins dans un langage plus informatique

Description du système d’un point de vue extérieur

‣ Ce qu’il doit faire

‣ Pas comment il le fait

Spécifications fonctionnelles et non-fonctionnelles

Doit rester accessible au client (contrat)

Jean-Paul Rigault 2005mercredi 29 septembre 2010


6

2) Spécifications (suite)Spécifications fonctionnelles

‣ Les fonctions/services rendus par le système

Spécifications non-fonctionnelles

‣ Utilisabilité

‣ Fiabilité (reliability)

‣ Performance

‣ Supportabilité (maintenabilité)

‣ Conditions d’implémentation, de déploiement…

‣ Interface

‣ Conditions d’exploitation

‣ Conditionnement

‣ Aspects juridiques

‣ Aspects financiers…

Activités du cycle de vie du logiciel



7

3) Conception Traduction des spécifications en termes d’artefacts logiciels

Peut être plus ou moins détaillée

4) Codage Traduction de la conception en code

5) Test unitaires Test de chaque module individuellement

Généralement de la responsabilité du développeur du module

6) Tests d’intégration Test de la composition de plusieurs modules (sous-systèmes)




8

7) ValidationTest du système final par rapport aux spécifications

8) Recette/Mise en exploitationAcceptation du système final

Peut être l’objet d’une procédure formelle et parfois officielle

9) Gestion des changements, gestion de configuration

Gestion de projetOrthogonale à toutes ces activités

Gestion du temps, des coûts, des équipes

Gestion des relations avec les clients…



Cycle de vie du logiciel

1) Activités2) Différents types de cycles

9



Modèles de cycle de vie d’un logicielModèles de cycle de vie

organiser les différentes activités du cycle de vie pour l'obtention d'un logiciel fiable, adaptable et efficace

guider le développeur dans ses activités techniques

fournir des moyens pour gérer le développement et la maintenance

‣ ressources, délais, avancement, etc.

Modèles linéairesen cascade et variantes

Modèles non linéairesen spirale, incrémentaux, itératifs

10



11

Cycle exploratoirePrototypage

RAD*Discuter et interagir avec l’utilisateur

Vérifier l ’efficacité réelle d ’un algorithme

Vérifier des choix spécifiques d ’IHMSouvent utilisé pour identifier les besoins

Prototype jetable (moins de risque ?)

Souvent implémenté par des générateurs de code

Prototype évolutif

*Rapid Application Developmentmercredi 29 septembre 2010


12

Cycle exploratoire, Prototypage, RAD*

MAIS

‣ Les objectifs sont uniquement généraux

‣ Prototyper n’est pas spécifier

‣ Les décisions rapides sont rarement de bonnes décisions

‣ Le prototype évolutif donne-t-il le produit demandé ?

‣ Les générateurs de code produisent-ils du code assez efficace ?

Admissible tel quel pour- du prototypage- de très petits projets développés- par de très petites équipes- avec de très petits enjeux

Cependant, retour en force dans les processus « agiles » mais sous une forme beaucoup plus élaborée



Modèle en cascade (70)• Expression du besoin

Analyse

• Analyse détaillée

• Codage

• Mise au point

Réalisation

• Tests unitaires

• Validation

Validation

• Mise en œuvre

• Etude technique préalable

• Conception préliminaire

Conception

• Conception détaillée

• Intégration

Intégration

• Tests d'Intégration

13

- Les vrais projets suivent rarement un développement séquentiel- Établir tous les besoins au début d’un projet est difficile- Le produit apparaît tard, les tests sont tardifs.

Seulement applicable pour les projets qui sont bien compris et maîtrisés



Modèle en «V»

• Expression du besoin Analyse

• Analyse détaillée

• Codage • Mise au point

Réalisation

• Tests unitaires

• Validation Validation

• Mise en œuvre

• Etude technique préalable • Conception préliminaire

Conception

• Conception détaillée

• Intégration Intégration

• Tests d'Intégration

➡ Cycle de vie normalisé AFNOR Variante du cycle en « cascade »

Définition des tests

Définition du plan d’intégration

14



15

Le cycle en V- permet une meilleure anticipation- présente des tests bien structurés

Mais - le cadre de développement est rigide - la durée est souvent trop longue - le produit apparaît très tard (validation finale tardive très coûteuse s’il y a des erreurs)

Variante : W (validation d’un maquette avant conception)

Modèle en «V»



16

Problèmes avec le processus classique...



17

Modèle en « spirale » (Boehm 88)

Intégration

Réalisation

Conception

Analyse détaillée

Analyse préliminaire « (de risque) »

V1 V2

Validation

Couplage de la nature itérative du prototypage avec les aspects systématiques et contrôlés du modèle en cascade.



18

Modèle en « spirale »➡ Bien adapté aux développements innovants

les progrès sont tangibles : c’est du logiciel qui « tourne » et pas seulement des kilos de documents

réduit les risques si bien appliqué : possibilité de s ’arrêter « à temps », i.e. avant que l ’irréalisabilité du projet ait créé un gouffre financier

➡ Moins simple à managerdifficile à gérer en situation contractuelle

mal contrôlé => on retombe dans le hacking



18

Modèle en « spirale »➡ Bien adapté aux développements innovants

les progrès sont tangibles : c’est du logiciel qui « tourne » et pas seulement des kilos de documents

réduit les risques si bien appliqué : possibilité de s ’arrêter « à temps », i.e. avant que l ’irréalisabilité du projet ait créé un gouffre financier

➡ Moins simple à managerdifficile à gérer en situation contractuelle

mal contrôlé => on retombe dans le hacking

À la base de tous les processus « agiles »



Stratégies d'itération Large et peu profonde

Analyse de l’ensemble du domaine Tous les cas d’utilisation sont étoffés

Définition d’une architecture générale

Etroite et profondeAnalyse en profondeur d’une partie du

problèmeDéveloppement de cette parie

HybrideUn mélange des stratégies

PROBLEM

PROBLEM

SO

LUTIO

N

PROBLEM

Elaboration

Construction

Transition

SO

LUTIO

NS

OLU

TION

19



Méthodologie, Méthode Méthodologie de développement

Identification et enchaînement des activités et phases du processus de développementIdentification des pré- et post-conditions de chaque phase

Définition des procédures de gestion et de mesureGestion des équipes, des moyens, du budget…

MéthodeApproche technique pour aborder une ou plusieurs phases ou activités

Pas de méthode «en or»20


Méthode

21



22

Méthode/ProcessusMéthode :

guide +/- formalisé, démarche reproductible pour obtenir des solutions fiables

capitalise l’expérience de projets antérieurs

Une méthode définitdes concepts de modélisation

une chronologie des activités (→ construction de modèles)

un ensemble de règles et de conseils pour tous les participants

– notation + démarche (+ outils)– façon de modéliser et façon de travailler



Évolution des méthodesOrigine : fin des années 60

problèmes de qualité et de productivité dans les grandes entreprises, mauvaise communication utilisateurs / informaticiens

méthodes = guides pour l’analyse et aide à la représentation du futur SI

conception par découpage en sous-problèmes, analytico-fonctionnelle

méthodes d’analyse structurée

Ensuiteconception par modélisation : « construire le SI, c'est construire sa base de données »

méthodes globales qui séparent données et traitements

23



Évolution des méthodes

Maintenantconception pour et par réutilisation

‣ Frameworks, Design Patterns, bibliothèques de classes

méthodes

‣ exploitant un capital d'expériences

‣ unifiées par une notation commune (par ex. UML)

‣ procédant de manière incrémentale

‣ validant par simulation effective

24



Outils et MéthodeUne méthode spécifie

des activités

des artefacts à réaliser

25



Notion d’artefact

Un artefact est un élément produit ou modifié dans le cadre d’un processus de développementIl peut s’agir d’un document, un diagramme, un compte rendu de réunion......mais aussi un code source, un écran, une base de données...

26



Outils et MéthodeUne méthode spécifie

des activités

des artefacts à réaliser

Il est souvent vital de disposer d’outil(s) soutenant le processus

en pilotant / permettant les activités

en gérant les artefacts du projet

Les outils peuvent être plus ou moins

intégrés à la méthode

interopérables

achetés / fabriqués / transformés…27

- Outils de planification- Outils de gestion des versions- Outils de gestion de documentation- Outils de maquettage- Outils de gestion des tests- Outils de modélisation

* pro, rétro, roundtrip- Ateliers de développement logiciel- Outils de vérification


Processus UnifiéUnified Software Development Process /

Unified Process (UP)

28



29

Unified Process (UP)

Beaucoup de méthodesliées à des outils, à l’adaptation à UML (comme langage de notation) de méthodes pré-existantes , aux entreprises, etc.

…finalement, autant de méthodes que de concepteurs / projets

➡ UP : Rumbaugh, Booch, Jacobson (les concepteurs d’UML) une trame commune des meilleures pratiques de developpement (pas une méthode)



30

Unified Software Development Process /Unified Process (UP)



31


Un Processus unifié est un processus de développement logiciel

- construit sur UML- conduit par les cas d’utilisation

- piloté par les risques- centré sur l’architecture,

- itératif et incrémental

- organisé autour de 4 phases : préétude(inception), élaboration, construction et transition

- défini par 6 disciplines fondamentales : Modélisation métier, Analyse et Conception, Implémentation, Test et

Déploiement



32

Processus Unifié Piloté par les cas d’utilisation

Le processus de développement est centré sur l’utilisateur

Modèles UML



33








Déploiement



34

(3) Pilotage par les risques

Vous avez la grippe, je vais vousprescrire des antibiotiques

➡ Un risque est un événement redouté dont l’occurrence est plus ou

moins prévisible et provoquant, lorsqu’il se produit, des dommages

sur le projet.

➡ Il ne faut pas confondre risque et problème.lUn problème est un risque qui s’est révélé.



34

(3) Pilotage par les risquesL’hiver,

il faut se faire vacciner contre la grippe

Vous avez la grippe, je vais vousprescrire des antibiotiques

➡ Un risque est un événement redouté dont l’occurrence est plus ou

moins prévisible et provoquant, lorsqu’il se produit, des dommages

sur le projet.

➡ Il ne faut pas confondre risque et problème.lUn problème est un risque qui s’est révélé.



35

Types de Risques

An ongoing or upcoming concern that has a significant

probability of adversely affecting the success of major milestones. (RUP Glossary)

Quelques types de Risques :

• Technique/ Architectural Technologie incertaine, visibilité partielle

• RessourcesLes gens, les compétences, le financement

• «Business»La concurrence, le retour sur investissement,

les interfaces avec les fournisseurs

• PlanningDépendances«Only 24 hours in a day»

• Changements d’exigences• Insatisfaction des utilisateurs

Doivent être identifiés et «priorisés» dans des artefacts dédiés



36








Déploiement



Processus centré sur l’architectureLes cas d’utilisation ne sont pas suffisants comme lien pour l’ensemble des membres du projet

L’architecture joue également ce rôle, en insistant sur la réalisation concrète de prototypes incrémentaux qui «démontrent» les décisions prises

D’autre part

plus le projet avance, plus l’architecture est difficile à modifier

les risques liés à l’architecture sont très élevés, car très coûteux

Objectifs 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

l’architecture s’impose à tous, contrôle les développements ultérieurs, permet de comprendre le système et d’en gérer la complexité

37



L’architecture regroupe les différentes vues du système qui doit être construit.

Elle doit prévoir la réalisation de tous les cas d’utilisation.

Marche à suivre:Créer une ébauche grossière de l’architecture.

‣ Travailler sur les cas d’utilisation représentant les fonctions essentielles.

‣ Adapter l’architecture pour qu’elle prenne en compte ces cas d’utilisation.

Sélectionner d’autres cas d’utilisation et refaire de même.

L’architecture et les cas d’utilisation évoluent de façon concomitante.

38

Processus Unifié Centré sur l’architecture



Notion d’architectureAu sens de RUP, une architecture :

Sert à comprendre le système lorsqu’il est complexePilote le projet en découpant les tâchesFavorise la réutilisation

39

Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse,

comprehensibility, economic and technological constraints and tradeoffs, and esthetics. (RUP, 98)-

A Technical Architecture is the minimal set of rules governing the arrangement, interaction, and interdependance of the parts or elements that

together may be used to form an information system. (U.S. Army 1996)



Quelques axes pour considérerl’architecture

Architectures client/serveurs en niveaux

‣ aussi appelés tiers

Architectures en couches

‣ Présentation, Application, Domaine/métier, Infrastructure métier (services métiers de bas-niveau), Services techniques (ex. sécurité), Fondation (ex. accès et stockage des données)

Architectures en zones de déploiement

‣ déploiement des fonctions sur les postes de travail des utilisateurs (entreprise : central/départemental/local)

Architectures à base de composants

‣ réutilisation de composants

40



41








Déploiement



Ordonnancement des itérations basé sur les priorités entre cas d'utilisation et sur l'étude du risque

Une itération est une séquence d’activités Une itération se décompose en:

•Une planification de l’itération •Analyse des besoins (raffinement) •Analyse et conception •Implémentation et tests •Évaluation •Livraison

42

Processus Unifié Itératif et Incrémental



43

Approche Itérativetime

content



43

Approche Itérativetime

content

Disciplines

Une itération, traverse

toutes les «disciplines.



44








Déploiement



45

Pré-étude (Inception Phase): Objectifs

Établir la portée du projet et les conditions aux limites

Déterminer les cas d'utilisation et les scénarios principaux

Proposer une architecture

Estimer le coût global et le calendrier

Identifier les risques potentiels et leurs sources

Démontrer que le système proposé est en mesure de résoudre les problèmes ou de prendre en charge les objectifs fixés

Vision : Glossaire, Détermination des parties prenantes et des utilisateurs, Détermination de leurs besoins, Besoins fonctionnels et non fonctionnels, Contraintes de conception



46

Acceptation des parties prenantes sur la définition du champ d'application

Accord sur les exigences (ensemble et compréhension commune)

Accord sur les estimations de coût, le planning, les priorités, les risques et le processus de développement

Les risques ont été identifiés et une stratégie de gestion du risque a été prévue.

Pré-étude (Inception Phase): Evaluation



46

Acceptation des parties prenantes sur la définition du champ d'application

Accord sur les exigences (ensemble et compréhension commune)

Accord sur les estimations de coût, le planning, les priorités, les risques et le processus de développement

Les risques ont été identifiés et une stratégie de gestion du risque a été prévue.

Abandon du projet si pas de passage de ce «jalon»

Pré-étude (Inception Phase): Evaluation



47

Définir et valider l'architecture de base Formuler les cas d’utilisation pour couvrir environ 80% des besoins fonctionnelsDéfinir les niveaux de qualité à atteindre,Etablir un plan détaillé pour la phase de constructionDémontrer que l'architecture de base prend en charge «la vision» à un coût raisonnable dans un délai raisonnable

Elaboration Phase: Objectifs

Architecture : Document d’architecture Logicielle, Différentes vues selon la partie prenante,Comportement et conception des composants du système



48

Vision du produit et les exigences sont stables. L'architecture est stable. Les éléments de risque majeurs ont été abordés et résolus. Les plans d’itération pour la phase de construction sont

suffisamment détaillées Tous les intervenants s'entendent pour dire que la vision

actuelle peut être atteinte si le plan actuel est exécuté dans le contexte de l'architecture actuelle.

Elaboration Phase: Evaluation



49

Description d’Architecture (1)«Software Architecture Document»

Donne une vue d'ensemble complète de l'architecture du système logicielInclus‣ Vues d’Architecture

‣ Buts et contraintes Exigences que l’architecture doit supporter Contraintes Techniques

‣ Caractéristiques de taille et performance

‣ Qualité, extensibilité, and cibles potentielles (portabilité)



50

Description d’Architecture (2)

Design Model Deployment Model

Implementation Model



51

Objectifs principaux Produire un logiciel utilisable conforme aux besoins

Confronter ce logiciel aux critères d’acceptation (élaborés pendant la phase d'opportunité)

Extension de l’identification, de la description et de la réalisation des cas d’utilisationFinalisation de l’analyse, de la conception, de l’implémentation et des tests

Construction Phase: Objectifs

Produit : Première version suffisamment stable et mature pour être déployée (testée, documentée, accompagnée…), Les procédures d’installation sont prêtes



52

Construction Phase: Evaluation

La version du produit est-elle assez stable et mûre pour être déployée dans la communauté des utilisateurs?

Les utilisateurs sont-ils informés ? Sensibilisés ? Formés?Les dépenses engagées par rapport aux prévisions sont-elles

acceptables?



53

Préparation des activitésRecommandations au client sur la mise à jour de l’environnement logicielElaboration des manuels et de la documentation concernant la version du produitAdaptation du logicielCorrection des anomalies liées au béta testDernières corrections

Transition Phase: Objectifs

Livraison du produit aux utilisateurs



54

Transition Phase: Evaluation

Les utilisateurs sont-ils satisfaits ? Les dépenses engagées par rapport aux prévisions sont-elles

acceptables?



55

Principaux jalonsProduit suffisamment

mature pour les clients

Premières fonctionnalités

Inception Elaboration Construction Transition

time



55

Principaux jalons

Architecture de référence

Architecture

Accord sur le contexte et les cas d’utilisation

Vision

Produit suffisamment mature pour les clients

Premières fonctionnalités

Acceptation par les Clients ou fin de vie

Produit Livraison

Inception Elaboration Construction Transition

time



Itérations dans chaque Phase

TransitionConstructionElaborationPré-étude

Transition Iteration


Development Iteration


Development IterationArchitecture

IterationPreliminary Iteration

Versions Exécutables

56

Architecture Iteration





Artefacts Analysis & Design

• Software architecture : description formelle de l’architecture du système

• Design & deployment model : répartition physique des composants

• Data model : structure logique et physique de la base de données

57



Tous les critères caractérisant lesprocessus UP sont liés

58


Un exemple de bout en bout

Basé sur le cours de M1 MIAGE - SIMA 2005-2006 / Yannick Prié -

Université Claude Bernard Lyon 1

59

Pour mieux comprendre le procédé mais pas à savoir faire



Exemple : liste initiale des besoinsUne chaîne d'hôtels a décidé de mettre sur le réseau un système de réservation de chambres ouvert à tout client via un navigateur, et d'autre part elle veut automatiser la gestion de ses hôtels. Un hôtel est géré par un directeur assisté d'employés.

Pour réserver à distance, après avoir choisi hôtels et dates, le client fournit un numéro de carte bleue. Lorsque le retrait a été accepté (1h après environ), la réservation devient effective et une confirmation est envoyée par mail. Les clients sous contrat (agences de voyage...) bénéficient d'une réservation immédiate.

Le directeur de l'hôtel enregistre les réservations par téléphone. Si un acompte est reçu avant 72h, la réservation devient effective, sinon elle est transformée en option (toute personne ayant payé a la priorité). Si la réservation intervient moins de 72h avant la date d'occupation souhaitée, le client doit se présenter avant 18h.

Le directeur fait les notes des clients, perçoit l'argent et met à jour le planning d'occupation effectif des chambres.

Une chambre est nettoyée soit avec l'accord du client lorsqu'il reste plusieurs jours, soit après le départ du client s'il s'en va, et dans ce cas avant occupation par un nouveau client. Les employés s'informent des chambres à nettoyer et indiquent les chambres nettoyées au fur et à mesure. Pour cela les chambres vides à nettoyer doivent être affichées, et les employés doivent pouvoir indiquer les chambres nettoyées de façon très simple. Un historique des chambres nettoyées par chaque employé est conservé un mois. 60



Exemple : liste initiale des besoinsUne chaîne d'hôtels a décidé de mettre sur le réseau un système de réservation de chambres ouvert à tout client via un navigateur, et d'autre part elle veut automatiser la gestion de ses hôtels. Un hôtel est géré par un directeur assisté d'employés.....Une chambre est nettoyée soit avec l'accord du client lorsqu'il reste plusieurs jours, soit après le départ du client s'il s'en va, et dans ce cas avant occupation par un nouveau client. Les employés s'informent des chambres à nettoyer et indiquent les chambres nettoyées au fur et à mesure. Pour cela les chambres vides à nettoyer doivent être affichées, et les employés doivent pouvoir indiquer les chambres nettoyées de façon très simple. Un historique des chambres nettoyées par chaque employé est conservé un mois.61



Etude préliminaire

62

Appréhender les besoins fonctionnels trouver les acteurs

‣ à partir des besoins

‣ délimiter le système par rapport à son environnement (système = boîte noire)

‣ chercher qui interagit avec le système (rôles)

trouver les cas d’utilisation

‣ examiner comment chaque acteur interagit avec le système pour que celui-ci lui rende un service

‣ regrouper les interactions similaires en cas d’utilisation

décrire brièvement les cas d’utilisation

construire le modèle des cas d’utilisation

‣ les considérer dans leur ensemble



Ex : Etude préliminaire

63

Le système à développer est divisé en deux sous systèmes indépendants :

- le système de réservation à distance et le système de gestion local à l'hôtel.

La base de données des réservations est considérée comme un système externe.



Etude préliminaire

64

Classer les cas d’utilisation par priorité

la priorité dépend des risques associés au cas d’utilisation et de leur importance pour l’architecture, des nécessités de réalisation et de tests

Exemple : classement des CU par importance

Les traitements très classiques de la gestion locale sont à examiner en dernier (risque faible).

Les réservations (client ou gérant) mettent en jeuune architecture plus complexe et sont à examiner en priorité :

Réservation (distante)Réservation locale

Administration...



Etude préliminaire

65

Détailler et formaliser les cas d’utilisationStructurer le modèle (révision des cas si besoin)Faire une maquette de l’interface utilisateur

uniquement si l’interface est complexe ou nécessite une évaluation par le client

Utilisateurs non spécialistes, interface simple et logique.

Problème classique, sans risque majeur, donc pas de maquette.



Ex : Etude préliminaire

66

CU : Gérer réservation par le gérant Acteur principal : Gérant

Intervenants et intérêts : Client, Chaîne hôtelière

Préconditions : une chambre est libre pour la période désiréeScénario nominal

‣ 1. Le gérant demande le planning d'occupation pour la période qui vient. Le système affiche le planning sur plusieurs semaines.

‣ 2. Le gérant sélectionne une chambre libre pour une date qui l’intéresse. Le système lui présente le récapitulatif de cette chambre, et sa disponibilité quelques jours avant et après la date choisie.



Ex : diagramme de séquence système pour un scénario

67



Etude préliminaire

68

Appréhender les besoins non fonctionnels (contraintes sur le système : environnement, plate-forme, fiabilité, vitesse…)

rattacher si possible les besoins aux cas d’utilisation

‣ description dans les descriptions des CU (section « exigences particulières » pour UP)

‣ sinon, dresser une liste des exigences supplémentaires

La chaîne possède 117 hôtels de 30 chambres en moyenne. Les appels sur le réseau sont évalués à 300 par jour (au début, prévoir des évolutions).Pour des raisons d'extensibilité, de performances et de sécurité, la chaîne de traitement des réservations des clients doit être indépendante des liaisons des hôtels avec le système de réservation. Les hôtels ne sont pas reliés en permanence au système de réservation (économie) et les postes devront être fiables (coupures de courant...).Le temps d’apprentissage du logiciel par les acteurs professionnels ne doit pasdépasser une demi-journée.Une société tierce s'occupera de la maintenance du système et abritera les serveurs.



Activité : analyseObjectif :

construction du modèle d’analyse pour préparer la conception

‣ forme générale stable du système, haut-niveau d’abstraction

‣ vision plus précise et formelle des CU, réalisation par des objets d’analyse

passage du langage du client à celui du développeur

Analyse architecturaleidentifier les paquetages d’analyse (découpage en catégorie)

‣ regroupement logique indépendant de la réalisation

‣ relations de dépendances, navigabilité entre classes de paquetage différents à partir des CU et du domaine

‣ point de départ du découpage en sous-systèmes

69



Ex : Organisation logicielle

70

Restitue les données à l’utilisateur et transforme ses actions en événements

de l’application.Représente les objets de

contrôle et pilote les règles de l’application, y compris les règles d’échanges entre

applications

Représente les objets du métier et implémente leur

règles de gestion. Restitue les

représentations métier à partir des

données de stockages

Assure la persistance des données

Synch. des différents systèmes

de réservations



Ex : découpage en paquetages

71



Analyse architecturale (suite)

Identifier les classes entités manifestes (premier modèle structurel)

modèle des 10-20 classes constituant l’essence du domaine

3 stéréotypes de classe : frontière, contrôle, entité

responsabilités évidentes

Identifier les exigences particulières communesdistribution, sécurité, persistance, tolérance aux fautes…

les rattacher aux classes et cas d’utilisation

72



Analyse architecturale (suite)

73



Activité : analyse (suite)Analyse des cas d'utilisation

raffinement de tous les scénarios des cas d'utilisation →

‣ découverte des classes, attributs, relations, interactions entre objets, et des besoins spéciaux

identifier les classes, attributs et relations

‣ examiner l'information nécessaire pour réaliser chaque scénario

‣ ajouter les classes isolant le système de l'extérieur (interfaces physiques, vues externes des objets…)

éliminer les classes qui n’en sont pas : redondantes, vagues, de conception, etc.

74



Exemple : diagramme de collaboration

75



3- Activité : conceptionPropose une réalisation de l'analyse et des cas d’utilisation en prenant en compte toutes les exigences

Conception architecturaleidentifier les noeuds et la configuration du réseau (déploiement), les sous-systèmes et leurs interfaces (modèle en couche en général), les classes significatives de l'architecture

Concevoir les cas d'utilisation identifier les classes nécessaires à la réalisation des cas ...

Concevoir les classes et les interfaces... décrire les méthodes, les états, prendre en compte les besoins spéciaux

Concevoir les sous-systèmesmettre à jour les dépendances, les interfaces...

sous-systèmes de service, liés à l’appli, de middleware…

permettra de distribuer le travail aux développeurs76

Juste pour infos



Exemple : diagramme de déploiement

77

• Les deux serveurs et la BD des réservations peuvent être sur un même noeud tant que les liaisons clients ne pénalisent pas les liaisons gérants

•



Exemple : découpage en sous-systèmes

78



4- Activité : réalisationMise en oeuvre architecturale

identifier les artefacts logiciels et les associer à des noeuds

Intégrer le système

planifier l'intégration, intégrer les incréments réalisés

Réaliser les sous-systèmes

Réaliser les classes

Faire les tests unitaires

tests de spécification en boîte noire, de structure en boîte blanche

79



BibliographieUNIVERSITE PARIS XII -ISIAG , MASTER 2, METHODOLOGIE ET CONDUITE DE PROJETS, CHAPITRE 3

Génie Logiciel Orienté Objets, Philippe Collet, Master 1 Informatique, 2007-2008

Processus de conception de SI M1 MIAGE - SIMA - 2005-2006 Yannick Prié UFR Informatique - Université Claude Bernard Lyon 1

Méthodes de conduite de projet, Tester, optimiser, structurer ses applications Jean David Olekhnovitch, [email protected] - www.olek.fr

Les cours IBM sur le RUP

Conduite de projet, Méthode d’analyse et de conception, Processus unifié, G. Picard, SMA/G2I/ENS Mines Saint-Etienne [email protected], Octobre 2009

Processus Unifié : www2.lifl.fr/~clerbout/.../Cours4-ProcessusUnifie.pdf

80




http://www.olek.fr

http://www.olek.fr



Education

Methodes de gestion de projets - introduction au processus unifié