Methodes de gestion de projets - introduction au processus unifié

Méthodes de conduite
de projet
Où les enseignements prennent leur place

Mireille Blay-Fornarino
IUT Nice-Sophia Antipolis
blay@polytech.unice.fr
http://www.polytech.unice.fr/~blay

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

Cycle de Vie. Méthodes Processus Unifié Exemple

Projet en général : qq définitions
Projet : 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 sufﬁsant 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 logiciel
Période entre l’idée du logiciel et sa mise en service

3

Cycle de vie du
logiciel
1) Activités
2) Différents types de cycles

4


Activités du cycle de vie du logiciel
1) Définition des besoins (Requirements)
Expression des besoins dans le langage du client

2) Spécifications
Traduction 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 2005 5


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… 6


3) Conception
Traduction des spéciﬁcations 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)

7


7) Validation
Test du système final par rapport aux spécifications
8) Recette/Mise en exploitation
Acceptation 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 projet
Orthogonale à toutes ces activités
Gestion du temps, des coûts, des équipes
Gestion des relations avec les clients…

8

Cycle de vie du
logiciel
1) Activités
2) Différents types de cycles

9


Modèles de cycle de vie d’un logiciel
Modèles de cycle de vie
organiser les différentes activités du cycle de vie pour l'obtention
d'un logiciel ﬁable, adaptable et efﬁcace
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éaires
en cascade et variantes
Modèles non linéaires
en spirale, incrémentaux, itératifs

10


Cycle exploratoire
Prototypage
RAD*
Discuter et interagir avec l’utilisateur
Vérifier l ’efficacité réelle d ’un
algorithme
Vérifier des choix spécifiques d ’IHM
Souvent utilisé pour identifier les
besoins
Prototype jetable (moins de risque ?)
Souvent implémenté par des
générateurs de code
Prototype évolutif

*Rapid Application Development 11


Cycle exploratoire,
Prototypage, RAD*
MAIS
‣ Les objectifs sont uniquement généraux
‣ Prototyper n’est pas spéciﬁer
‣ 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 efﬁcace ?

Admissible tel quel pour
- du prototypage Cependant, retour en force
- de très petits projets dans les processus « agiles »
développés mais sous une forme
- par de très petites équipes beaucoup plus élaborée
- avec de très petits enjeux 12


Modèle en cascade (70)
Analyse
• Expression du besoin
• Analyse détaillée - Les vrais projets suivent rarement
un développement séquentiel
Conception
• Etude technique préalable
- Établir tous les besoins au début
• Conception préliminaire d’un projet est difﬁcile
• Conception détaillée - Le produit apparaît tard, les tests
Réalisation
sont tardifs.
• Codage
• Mise au point
• Tests unitaires
Seulement applicable
Intégration pour les projets qui sont
• Intégration
bien compris et maîtrisés
• Tests d'Intégration

Validation
• Validation
• Mise en œuvre 13



Modèle en «V»
Variante du cycle en
➡ Cycle de vie normalisé AFNOR « cascade »
Définition des tests
Analyse Validation
• Expression du besoin • Validation
• Analyse détaillée • Mise en œuvre
Définition du plan d’intégration
Conception
Intégration
• Etude technique préalable
• Conception préliminaire • Intégration
• Conception détaillée • Tests d'Intégration

Réalisation
• Codage
• Mise au point
• Tests unitaires
14


Modèle en «V»
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 ﬁnale tardive très
coûteuse s’il y a des erreurs)

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

15


Problèmes avec le processus
classique...

16


Modèle en « spirale » (Boehm 88)
Couplage de la nature itérative du prototypage avec les aspects
systématiques et contrôlés du modèle en cascade.

Analyse détaillée

Analyse
préliminaire « (de risque) »
Conception

V1 V2
Réalisation
Validation

Intégration
17


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 ﬁnancier

➡ Moins simple à manager
difﬁcile à 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 ﬁnancier

➡ Moins simple à manager
difﬁcile à gérer en situation contractuelle
mal contrôlé => on retombe dans le hacking

À la base de tous les processus « agiles »
18


Stratégies d'itération PROBLEM

Large et peu profonde
Analyse de l’ensemble du domaine

SOLUTION
 Tous les cas d’utilisation sont étoffés
Déﬁnition d’une architecture générale

PROBLEM

Etroite et profonde

SOLUTION
Analyse en profondeur d’une partie du
problème
Développement de cette parie
PROBLEM
Hybride
Un mélange des stratégies Elaboration

SOLUTION
Construction

Transition

19


Méthodologie, Méthode
Méthodologie de développement
Identification et enchaînement des activités et phases du
processus de développement
Identification des pré- et post-conditions de chaque phase
Définition des procédures de gestion et de mesure
Gestion des équipes, des moyens, du budget…

Méthode
Approche technique pour aborder une ou plusieurs phases ou
activités

Pas de méthode «en or»
20

Méthode

21


Méthode/Processus
Méthode :
guide +/- formalisé, démarche reproductible pour obtenir des
solutions ﬁables
capitalise l’expérience de projets antérieurs
Une méthode déﬁnit
des 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
22


Évolution des méthodes
Origine : ﬁn 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
Ensuite
conception 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
Maintenant
conception pour et par réutilisation
‣ Frameworks, Design Patterns, bibliothèques de classes
méthodes
‣ exploitant un capital d'expériences
‣ uniﬁées par une notation commune (par ex. UML)
‣ procédant de manière incrémentale
‣ validant par simulation effective

24


Outils et Méthode
Une méthode spéciﬁe
des activités
des artefacts à réaliser

25


Notion d’artefact
Un artefact est un élément produit ou modiﬁé dans le cadre
d’un processus de développement
Il 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éthode
Une méthode spécifie
des activités
- Outils de planification
des artefacts à réaliser - Outils de gestion des versions
Il est souvent vital de disposer - Outils de gestion de
d’outil(s) soutenant le processus documentation
- Outils de maquettage
en pilotant / permettant les - Outils de gestion des tests
activités - Outils de modélisation
en gérant les artefacts du projet * pro, rétro, roundtrip
- Ateliers de développement
Les outils peuvent être plus ou
logiciel
moins - Outils de vérification
intégrés à la méthode
interopérables
achetés / fabriqués / transformés…
27

Processus Unifié
Unified Software Development Process /
Unified Process (UP)

28


Beaucoup de méthodes
liées à des outils, à l’adaptation à UML (comme langage de
notation) de méthodes pré-existantes , aux entreprises, etc.
…ﬁnalement, 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)

29



30


Un Processus uniﬁé 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éﬁni par 6 disciplines fondamentales :
Modélisation métier, Analyse et Conception, Implémentation, Test et
Déploiement
31


Processus Uniﬁé
Piloté par les cas d’utilisation
Le processus de développement est centré sur l’utilisateur

Modèles
UML

32


- construit sur UML


Déploiement
33


(3) Pilotage par les risques
➡ Un risque est un
événement redouté dont
l’occurrence est plus ou
moins prévisible et
provoquant, lorsqu’il se
produit, des dommages
Vous avez la grippe, je vais vous
sur le projet. prescrire des antibiotiques

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


(3) Pilotage par les risques
L’hiver,
➡ Un risque est un il faut se faire vacciner
événement redouté dont contre la grippe

l’occurrence est plus ou
moins prévisible et
provoquant, lorsqu’il se
produit, des dommages
Vous avez la grippe, je vais vous
sur le projet. prescrire des antibiotiques

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


Types de Risques
Quelques types de Risques :

• Technique/ Architectural
 Technologie incertaine, visibilité partielle
Doivent être
• Ressources
identifiés et
 Les gens, les compétences, le financement
«priorisés»
• «Business» dans des
 La concurrence, le retour sur investissement,
les interfaces avec les fournisseurs artefacts
dédiés
• Planning
 Dépendances
 «Only 24 hours in a day»
An ongoing or upcoming
• Changements d’exigences concern that has a significant
probability of adversely
• Insatisfaction des utilisateurs affecting the success of major
35 milestones. (RUP Glossary)


- construit sur UML


Déploiement
36


Processus centré sur l’architecture
Les 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


Processus Uniﬁé
Centré sur l’architecture
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


Notion d’architecture
Au sens de RUP, une architecture :
Sert à comprendre le système lorsqu’il est complexe
Pilote le projet en découpant les tâches
Favorise la réutilisation

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)
39


Quelques axes pour considérer
l’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


- construit sur UML


Déploiement
41


Processus Unifié
Itératif et Incrémental
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


Approche Itérative
time

content

43


Approche Itérative
time

Une
itération,
content
traverse
toutes les
«disciplines.

Disciplines

43


- construit sur UML


Déploiement
44


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
Identiﬁer 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 ﬁxés
Vision : Glossaire, Détermination des parties prenantes et
des utilisateurs, Détermination de leurs besoins, Besoins
fonctionnels et non fonctionnels, Contraintes de conception
45


Pré-étude (Inception Phase): Evaluation

Acceptation des parties prenantes sur la déﬁnition 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é identiﬁés et une stratégie de gestion du
risque a été prévue.

46


Pré-étude (Inception Phase): Evaluation

Acceptation des parties prenantes sur la déﬁnition 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é identiﬁés et une stratégie de gestion du
risque a été prévue.

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


Elaboration Phase: Objectifs

Déﬁnir et valider l'architecture de base
Formuler les cas d’utilisation pour couvrir environ 80% des
besoins fonctionnels
Déﬁnir les niveaux de qualité à atteindre,
Etablir un plan détaillé pour la phase de construction
Démontrer que l'architecture de base prend en charge «la
vision» à un coût raisonnable dans un délai raisonnable
Architecture : Document d’architecture Logicielle,
Différentes vues selon la partie prenante,
Comportement et conception des composants du système
47


Elaboration Phase: Evaluation
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
sufﬁsamment 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.

48


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

Donne une vue d'ensemble complète de l'architecture
du système logiciel
Inclus
‣ 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é)

49


Description d’Architecture (2)

Implementation Model

Design Model Deployment Model

50


Construction Phase: Objectifs

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’identiﬁcation, de la description et de la
réalisation des cas d’utilisation
Finalisation de l’analyse, de la conception, de l’implémentation
et des tests
Produit : Première version sufﬁsamment stable et mature
pour être déployée (testée, documentée, accompagnée…),
Les procédures d’installation sont prêtes
51


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?

52


Transition Phase: Objectifs

Préparation des activités
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 liées au béta test
Dernières corrections
Livraison du produit
aux utilisateurs
53


Transition Phase: Evaluation

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

54


Principaux jalons
Produit suffisamment
mature pour les clients

Inception Elaboration Construction Transition

time

Premières
fonctionnalités

55


Principaux jalons
Acceptation par les Clients
Produit suffisamment ou fin de vie
Architecture mature pour les clients
de référence
Accord sur le contexte
et les cas d’utilisation

Inception Elaboration Construction Transition

time

Produit
Architecture
Vision Livraison
Premières
fonctionnalités

55


Itérations dans chaque Phase
Pré-étude Elaboration Construction Transition
Preliminary Architecture Architecture Development Development
Development Development Transition Transition
Transition
Iteration Iteration Iteration
Iteration Iteration Iteration Iteration
Iteration
Iteration Iteration

Versions Exécutables

56


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 les
processus 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

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


Exemple : liste initiale des besoins
Une 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 besoins
Une 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 afﬁché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é61un mois.


Etude préliminaire
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

62


Ex : Etude préliminaire
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.

63


Etude préliminaire
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 jeu
une architecture plus complexe et sont à examiner en priorité :
Réservation (distante)
Réservation locale
Administration
...

64


Etude préliminaire
Détailler et formaliser les cas d’utilisation
Structurer 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.

65


Ex : Etude préliminaire
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ée
Scénario nominal
‣ 1. Le gérant demande le planning d'occupation pour la
période qui vient. Le système afﬁche 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.
66


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

67


Etude préliminaire
Appréhender les besoins non fonctionnels (contraintes sur le
système : environnement, plate-forme, ﬁabilité, 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 ﬁables (coupures
de courant...).
Le temps d’apprentissage du logiciel par les acteurs professionnels ne doit pas
dépasser une demi-journée.
Une société tierce s'occupera de la maintenance du système et abritera les serveurs.
68


Activité : analyse
Objectif :
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 architecturale
identiﬁer 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
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 Synch. des
de l’application, y compris différents systèmes
de réservations
les règles d’échanges entre
applications

Représente les objets du
métier et implémente leur Restitue les
règles de gestion. représentations
métier à partir des
données de stockages

Assure la persistance des
données

70


Ex : découpage en paquetages

71


Analyse architecturale (suite)
Identiﬁer 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
Identiﬁer les exigences particulières communes
distribution, 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
rafﬁnement de tous les scénarios des cas d'utilisation →
‣ découverte des classes, attributs, relations, interactions
entre objets, et des besoins spéciaux
identiﬁer 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é : conception
Propose une réalisation de l'analyse et des cas d’utilisation en
prenant en compte toutes les exigences
Conception architecturale
identifier 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 Juste pour infos
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èmes
mettre à jour les dépendances, les interfaces...
sous-systèmes de service, liés à l’appli, de middleware…
permettra de distribuer le travail aux développeurs
76


Exemple : diagramme de déploiement

• 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
•
77


Exemple : découpage en sous-systèmes

78


4- Activité : réalisation
Mise 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


Bibliographie
UNIVERSITE 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, jd@olek.fr - 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
gauthier.picard@emse.fr, Octobre 2009
Processus Unifié : www2.lifl.fr/~clerbout/.../Cours4-ProcessusUnifie.pdf

80

Methodes de gestion de projets - introduction au processus unifié

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Methodes de gestion de projets - introduction au processus unifié

Semelhante a Methodes de gestion de projets - introduction au processus unifié (20)

Último

Último (20)

Methodes de gestion de projets - introduction au processus unifié