methodes de gestion de projets - introduction au processus unifié
Post on 20-Jun-2015
3.412 Views
Preview:
DESCRIPTION
TRANSCRIPT
Méthodes de conduite de projet
1
Mireille Blay-FornarinoIUT Nice-Sophia Antipolis
blay@polytech.unice.frhttp://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
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de vie du logiciel
1) Activités2) Différents types de cycles
4
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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)
Activités du cycle de vie du logiciel
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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…
Activités du cycle de vie du logiciel
mercredi 29 septembre 2010
Cycle de vie du logiciel
1) Activités2) Différents types de cycles
9
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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»
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
16
Problèmes avec le processus classique...
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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.
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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 »
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Méthode
21
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
É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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
É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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
Outils et MéthodeUne méthode spécifie
des activités
des artefacts à réaliser
25
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Processus UnifiéUnified Software Development Process /
Unified Process (UP)
28
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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)
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
30
Unified Software Development Process /Unified Process (UP)
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
31
Unified Software Development Process /Unified Process (UP)
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
32
Processus Unifié Piloté par les cas d’utilisation
Le processus de développement est centré sur l’utilisateur
Modèles UML
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
33
Unified Software Development Process /Unified Process (UP)
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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é.
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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é.
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
36
Unified Software Development Process /Unified Process (UP)
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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)
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
41
Unified Software Development Process /Unified Process (UP)
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
43
Approche Itérativetime
content
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
43
Approche Itérativetime
content
Disciplines
Une itération, traverse
toutes les «disciplines.
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
44
Unified Software Development Process /Unified Process (UP)
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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é)
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
50
Description d’Architecture (2)
Design Model Deployment Model
Implementation Model
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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?
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
54
Transition Phase: Evaluation
Les utilisateurs sont-ils satisfaits ? Les dépenses engagées par rapport aux prévisions sont-elles
acceptables?
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
55
Principaux jalonsProduit suffisamment
mature pour les clients
Premières fonctionnalités
Inception Elaboration Construction Transition
time
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
Itérations dans chaque Phase
TransitionConstructionElaborationPré-étude
Transition Iteration
Transition Iteration
Development Iteration
Development Iteration
Development IterationArchitecture
IterationPreliminary Iteration
Versions Exécutables
56
Architecture Iteration
Development Iteration
Transition Iteration
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
Tous les critères caractérisant lesprocessus UP sont liés
58
mercredi 29 septembre 2010
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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.
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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...
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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.
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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.
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
Ex : diagramme de séquence système pour un scénario
67
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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.
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
Ex : découpage en paquetages
71
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
Analyse architecturale (suite)
73
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
Exemple : diagramme de collaboration
75
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
•
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
Exemple : découpage en sous-systèmes
78
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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
mercredi 29 septembre 2010
Cycle de Vie. Méthodes Processus Unifié Exemple
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, 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
mercredi 29 septembre 2010
top related