CM processus-unifie

Processus de conception de SI2/3 – Processus unifiéYannick PriéDépartement Informatique – Faculté des Sciences et TechnologiesUniversité Claude Bernard Lyon 12011-2012

Plan du cours global1/3 – Méthodes et processus2/3 – Processus unifié3/3 – Méthodes Agile2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Plan de ce coursTrame du processus unifiéCaractéristiques essentiellesDescription du processus unifiéIllustration : deux déclinaisonsBeaucoup de transparents, une icône pour ce qui est à retenir 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Plan Trame du processus unifiéCaractéristiques essentiellesDescription du processus unifiéIllustration : deux déclinaisons2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Unified Software DevelopmentProcess / UnifiedProcess (UP) Années 1990 : 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 USDPproposée par Rumbaugh, Booch, Jacobson les concepteurs originaux d’UMLpurement objetprend de la hauteur par rapport à RUP (Rational) méthode / processusregroupement des meilleures pratiques de développement Dans ce cours : beaucoup de généralités liées à USDP, qui s’appliquent à peu près à toute méthode objet 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Unified Software DevelopmentProcessUn processus capable dedicter l’organisation des activités de l’équipediriger les tâches de chaque individu et de l’équipe dans son ensemblespécifier les artefacts à produireproposer des critères pour le contrôle de produits et des activités de l’équipeBrefgérer un projet logiciel de bout en boutRegroupement de bonnes pratiques, maisnon figé générique (hautement adaptable : individus, cultures, …)choisir un UP (« cas de développement » dans RUP) qui correspond au projet du moment, appliquerseul un expert peut en décider2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Un cycle de vie contient 4 phases2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Cycle 1Cycle 2Cycle 3Étude préliminaireÉlaborationConstructionTransitionPhasesConsidérer un produit logiciel quelconque par rapport à ses versions

Gérer chaque cycle de développement comme un projet ayant quatre phases

chaque phase se termine par un point de contrôle (ou jalon) permettant aux chefs de projet de prendre des décisionsPhase 1 Etude préliminaire2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Étude préliminaireÉlaborationConstructionTransitionVisionDéterminerque fait le système ?à quoi pourrait ressembler l’architecture ?quels sont les risques ?quel est le coût estimé du projet ? Comment le planifier ?Jalon« vision du projet » = documentAccepter le projet ?Coût faible

Phase 2 ElaborationÉtude préliminaireÉlaborationConstructionTransitionArchitecture de baseVisionSpécifier la plupart des cas d’utilisationConcevoir l’architecture de base (squelette du système)Mettre en œuvre cette architecture CU critiques, <10 % des besoinsFaire une planification complèteJalon « architecture du cycle de vie » = premier prototype qui démontre la validité des choix architecturauxPeut-on passer à la construction ?besoins, architecture, planning stables ? Risques contrôlés ?2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Phase 3Construction2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Étude préliminaireÉlaborationConstructionTransitionVersion bétaArchitecture de baseVisionDévelopper par incrémentsl'architecture reste stable malgré des changements mineursle produit contient au final tout ce qui avait été planifié, il reste quelques erreursJalon « capacité opérationnelle initiale » = version bétaLe produit est-il suffisamment correct pour être installé chez le / un client ?Phase la plus coûteuse > 50% du cycle englobe conception, codage, tests, intégration, etc.

Phase 4Transition2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Étude préliminaireÉlaborationConstructionTransitionProduit livréVersion bétaArchitecture de baseVisionTransition livrer / déployer le produitcorriger le reliquat d’erreursaméliorer le produitformer les utilisateurslettre en place l’assistance en ligneJalon « livraison du produit » = produit déployé chez le clienttests suffisants ? Produit satisfaisant ? Manuels prêts ?

Phases et activitésUn cycle met en jeu des activitésvue du développement sous l’angle technique (développeur)les activités sont réalisées au cours des phasesles activitésÉtude préliminaireÉlaborationConstructionTransitionCapture des besoinsAnalyseConception RéalisationTestArchitecture de baseVersion bétaProduit livréVision2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Plan Trame du processus unifiéProcessus unifié : caractéristiques essentiellesitératif et incrémentalpiloté par les besoinspiloté par les risquescentré sur l’architectureDescription du processus unifiéIllustration : deux déclinaisons du processus unifié2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Itérations et incrémentsAnti-cascade, spiraleConstruction progressive du systèmeprocessus incrémentalChaque itération permet demaîtriser une partie des risques et apporte une preuve tangible de faisabilitéproduit un système partiel opérationnel (exécutable, testé et intégré) avec une qualité égale à celle d’un produit fini (alpha)qui peut être évalué : permet de savoir si on va dans la bonne direction ou nonSérie de prototypes qui vont en s’améliorant de plus en plus de fonctionnalités disponiblesretours utilisateurs2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Cycle 1…Itération 1Itération 2Itération 3Itération n

ItérationUne itération est un mini-projetplan pré-établi et objectifs pour le prototype, critères d’évaluation, comporte toutes les activités (mini-cascade)est terminée par un point de contrôleensemble de modèles agréés, décisions pour les itérations suivantesconduit à une version montrable implémentant un certain nombre de CUdure entre quelques semaines et 9 mois (au delà : danger) butée temporelle qui oblige à prendre des décisions2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Itérations et phases2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1tempsÉlabo-rationactivitésÉtude préliminaireTransitionConstructionCapture des besoinAnalyseConception RéalisationTestItération 1Itér 2Itér 3Itér…Itér…Itér…Itér nProduit livréitérationsVersion bétaArchitecture de base

Avantages d’un processus itératif et incrémentalGestion de la complexitépas tout en même temps, étalement des décisions importantesMaîtrise des risques élevés précocediminution de l’échecarchitecture mise à l’épreuve rapidement (prototype réel)Intégration continueprogrès immédiatement visiblesmaintien de l’intérêt des équipes (court terme, prototypes vs documents) Prise en compte des modifications de besoinsfeedback, implication des utilisateurs et adaptation précoceApprentissage rapide de la méthodeamélioration de la productivité et de la qualité du logicielAdaptation de la méthode possibilité d'explorer méthodiquement les leçons tirées d'une itération (élément à conserver, problèmes, éléments à essayer…)Mais gestion de projet plus complexe : planification adaptative2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

RésuméDémarche traditionnelleMéthodes itérativesValidation effective2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Plan Trame du processus unifiéProcessus unifié : caractéristiques essentiellesitératif et incrémentalpiloté par les besoinspiloté par les risquescentré sur l’architectureDescription du processus unifiéIllustration : deux déclinaisons2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Un processus piloté par les besoins Objectif du processus construction d’un système qui réponde à des besoinspar construction complexe de modèlesCas d’utilisation = expression / spécification des besoinsCU portée système / objectifs utilisateurs CU utilisés tout au long du cyclevalidation des besoins / utilisateurspoint de départ pour l’analyse (découverte des objets, de leurs relations, de leur comportement) et la conception (sous-systèmes)guide pour la construction des interfacesguide pour la mise au point des plans de tests2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Les CU lient les modèles2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Besoinsspécifié parModèle des cas d’utilisationréalisé pardistribué parAnalyseModèle d’analyseimplémenté parConceptionModèle de conceptionModèle de déploiementvérifié parImplémentationModèle d’implémentationTestsModèle de test

Avantages des cas d’utilisationCentrés utilisateurssupport de communication en langue naturelle entre utilisateurs et concepteurs basé sur les scénarios (et non liste de fonctions)dimension satisfaction d’un objectif utilisateur également pour les utilisateurs informaticiens (administration)besoins fonctionnels, pour acteurs humains et non humains à identifier précisémentAssurent la traçabilité par rapports aux besoins de toute décision de conception sur l’ensemble du projet tout modèle peut se référer in fine à un CUFournissent une vision commune aux participants du projet management, conception, qualité, marketing, etc.Attention créer de bons CU est un art (cf. « cours rédaction de CU »)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Risque ?Risque que le projet de construction du système soit un échecDifférentes natures de risques pour un projetbesoins / technique / autresExemplesle système construit n’est pas le bon architecture inadaptée, utilisation de technologies mal maîtrisées, performances insuffisantespersonnel insuffisant, problèmes commerciaux ou financiers (risques non techniques, mais bien réels)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Processus piloté par les risquesGestion des risquesidentifier et classer les risques par importanceagir pour diminuer les risquesex. changer les besoins, confiner la portée à une petite partie du projet, faire des test pour vérifier leur présence et les éliminers’ils sont inévitables, les évaluer rapidementtout risque fatal pour le projet est à découvrir au plus tôt 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Pilotage par les risques et itérationsIdentifier, lister et évaluer la dangerosité des risquesConstruire les itérations en fonction des risques : s’attaquer en priorité aux risques les plus importants qui menacent le plus la réussite du projet« provoquer des changements précoces »ex. stabiliser l’architecture et les besoins liés le plus tôt possibleRisqueEtude préliminairePériode d’intégration et de testsCascadeÉlaboration ItératifConstruction Transition Temps/itérations2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Itération pilotées par la réduction des risques2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Définir les scénarios permettant de prendre en compte les risques les plus importantsPlanifier l’itération N coût

planningRisques initiaux du projetObjectif initial du projetDévelopper l’itération N Collecter les dépenses et les métriques de qualitéIteration NValider l’itération NRéviser l’ensemble deL’objectif du projet coût

Itérations et risqueOn ordonne les itérations à partir des priorités établies pour les cas d’utilisation et de l’étude du risqueplan des itérationschaque prototype réduit une part du risque et est évalué comme tel les priorités et l’ordonnancement de construction des prototypes peuvent changer avec le déroulement du plan2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Planification des itérationsPlanification des itérations dès l’élaborationprécise pour l’itération suivante, imprécise pour la finla planification générale est adaptée en fonction des risques identifiés/traités et des résultats obtenus dans les itérationsPlanification adaptative (vs. prédictive)fixer des butées temporellesgérer l’adaptation avec le clientItérationtoutes les activités des besoins aux tests, résultats différents en fonction de la phase dans laquelle on se trouve mini-projet : planning, ressources, revuepremières itérations : suivre une méthodeà la fin d’une itération : retrospectiveéléments à conserver, problèmes, éléments à essayer2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Processus centré sur l’architectureL’architecture sert de lien pour l’ensemble des membres du projetréalisation concrète de prototypes incrémentaux qui « démontrent » les décisions prisesvient compléter les cas d’utilisation comme « socle commun »Contrainte de l’architectureplus le projet avance, plus l’architecture est difficile à modifierles risques liés à l’architecture sont très élevés, car très coûteuxObjectif 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éutilisationl’architecture s’impose à tous, contrôle les développements ultérieurs, permet de comprendre le système et d’en gérer la complexité L’architecture est contrôlée et réalisée par l’architecte du projet2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Objectif / architectureConstruire une architecture comme forme dans laquelle le système doit s’incarnerles CU réalisés doivent y trouver leur place la réalisation des CU suivant doit s’appuyer sur l’architecture.qui permette de promouvoir la réutilisationqui ne change pas trop converger vers une bonne architecture rapidement2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Analyse architecturale2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Identifier et traiter les besoins non fonctionnels dans le contexte des besoins fonctionnelsIdentifier les points de variation et d'évolution les plus probablespoints de variation : variations dans le système existant ou dans les besoinspoints d’évolution : points de variation spéculatifs, actuellement absents des besoins

Construction de l’architecture : principe (1)Pour commencerchoix d’une architecture de haut-niveau et construction des parties générales de l’application ébauche à partir de solutions existantes de la compréhension du domainede parties générales aux applications du domaine (quasi-indépendant des CU)des choix de déploiement2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Construction de l’architecture : principe (2)Ensuite : Construction de l’architecture de référence confrontation à l’ébauche des cas d’utilisation les plus significatifs (un à un) construction de parties de l’application réelle (sous-systèmes spécifiques)stabilisation de l’architecture autour des fonctions essentielles (sous-ensemble des CU). traitement des besoins non fonctionnel dans le contexte des besoins fonctionnelsidentification des points de variation et les points d'évolution les plus probables.2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Construction de l’architecture : principe (3)Ensuite : réalisation incrémentale des cas d’utilisation itérations successivesl’architecture continue à se stabiliser sans changement majeur Remarque : maturation des cas d’utilisationplus faciles à exprimer et plus précis quand un début d’application est disponible2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

L’architecture est conçue et réalisée pendant la phase d’élaboration Phase d’élaborationaller directement vers une architecture robuste, à coût limité, appelée « architecture de référence »10% des classes suffisentL’architecture de référence permettra d’intégrer les CU incrémentalementpendant la constructionguidera le raffinement et l’expression des CU pas encore détaillés2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Besoin de développement des modèles pour une architecture de référence : « petite et maigre »Modèle des cas d’utilisationModèle d’analyseModèle de conceptionModèle de testsModèle de déploiementModèle de réalisation

Remarque Processus orienté composantsOn cherche à développer et à réutiliser des composantssouplesse, préparation de l’avenirAu niveau modélisationregroupement en packages d’analyse, de conception réutilisablesutilisation de design patternsarchitecturauxobjets (création, comportement, structure)Au niveau productionutilisation de frameworksachats de composants 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Les 4 grandes caractéristiques du processus unifié sont liées2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Processus itératif et incrémentalPiloté par les risquesPiloté par les cas d’utilisationCentré sur l’architecture

Plan Trame du processus unifiéProcessus unifié : caractéristiques essentiellesDescription du processus unifiéActivités, travailleurs, artefacts et modèlesDifférentes activités pour passer des besoins au codeDifférentes phases pour piloter les activitésFocus sur quelques points importantsIllustration : deux déclinaisons2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Rappel : principes de conception objetPasser des besoins aux classes implémentées en réalisant des scénarios comme des collaborations entre objetsdéduire les responsabilités des collaborationsS’appuyer sur un modèle du domaine pour créer des objets métiers susceptibles d’évoluer avec les besoinsassumer l’évolutivité des besoinsFavoriser systématiquement la réutilisationen conception : patternsen construction : composants, frameworks2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Principe généralDécrire le modèle du domainefournira l’ossature du diagramme de classesDécrire les cas d’utilisationbesoins fonctionnelsRéaliser les cas d’utilisation un par un avec des interactions entre objets diagrammes de séquences / communicationCompléter le diagramme de classeCoder les classescompléter le prototypeTester / déployer2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Processus unifié : activités et phasesActivités : description technique de la méthodeque faire ? comment ?quel forme de produit (modèles, documents textuels, code…) ?Phases : description du déroulement du projetplanifier les phases et les itérationspour chaque itération / phase quels sont les buts à atteindre ?quels sont les livrables ?quels aspects décrire, avec quel niveau d’abstraction ?2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Les activités selon les phases 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1tempsactivitésÉlabo-rationÉtude préliminaireConstructionTransitionitérationCapture des besoinAnalyseConception RéalisationTestitérations

USDPUP définit un enchaînement d’activitésréalisées par un ensemble de travailleurs (rôles, métiers)ayant pour objectif de passer des besoins à un ensemble cohérent d’artefacts constituant un système informatiqueet de favoriser le passage à un autre système quand les besoins évolueront (nouvelle version, nouveau cycle) UP n’est qu’un cadre général de processusun projet particulier est une instance de ce cadre adaptée au contexte du projet (taille, personnels, entreprise, compréhension du processus, etc.)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activités, travailleurs, artefactsArtefacts (quoi)documentent le système et le projet (traces et produits)ex. : modèle architectural, code source, exécutable, modèle des CU, etc.Travailleurs ou discipline (qui)rôle par rapport au projetex. : architecte, analyste de CUActivités (comment) 5 grandes activités, multiples sous-activitéstâches réalisée par un travailleur, impliquant une manipulation d’information exemplesconcevoiruneclasse, corrigerundocument, détaillerun CU, etc.2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Travailleurs et activités2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

WorkflowsEnchaînement d’activités qui produisent des artefactsDiagramme d’activité2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Exemple RUP : requirement workflow2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Les modèles du processusObjectif de la modélisationcréer un modèle global composé de diagrammesliés aux différentes activitéset pas une montagne de documentsLes modèles sont liés par les cas d’utilisationpar les enchaînements d’activités qui ont permis de les mettre en placeRappel la description de l’architecture utilise une sous-partie des modèles2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Modèles d’un projet USDP2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Les activités consistent (entre autres) à créer des modèlesModèle des cas d’utilisationModèle d’analyseModèle de conceptionModèle d’implémentationModèle de testModèle de déploiement

Modèles et activités (1/2)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Capture des besoinsle modèle des CU représente le système vu de l’extérieur, son insertion dans l’organisation, ses frontières fonctionnelles. Analysele modèle d’analyse représente le système vu de l’intérieur. Les objets sont des abstractions des concepts manipulées par les utilisateurs. Point de vue statique et dynamique sur les comportements.Modèle des cas d’utilisationModèle d’analyse

Modèles et activités (2/2)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Conceptionle modèle de conception correspond aux concepts utilisés par les outils, les langages et les plateformes de développement. le modèle de déploiement spécifie les nœuds physiques et la distribution des composants. Permet d’étudier, documenter, communiquer et d’anticiper une conceptionImplémentation le modèle d’implémentation lie le code et les classes de conceptionTestsle modèle de tests décrits les cas de testsModèle de conceptionModèle de déploiementModèle d’implémentationModèle de test

Avertissement sur la suiteCe n’est pas forcément du UP générique complet insistance sur certains points plutôt que d’autres, utilisation de plusieurs sources à peu près cohérentesS’appuie largement sur le cours de JL Sourrouille (INSA-Lyon)trame description / exemple2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité acquisition des besoins :objectifsDéterminer les valeurs attendues du nouveau système et de la nouvelle organisation arriver à un accord client / développeursRecenser les besoins potentielscaractéristiques potentielles, priorité, risques…Comprendre le contexte du systèmeassociation d’analystes et d’experts métier pour construire un vocabulaire communmodèle du domaine (ou modèle de l’entreprise)diagramme de classes modèle du métier (éventuellement) modélisation des processus (CU métier, diagrammes de séquences, activité)glossaire2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité acquisition des besoins :Liste initiale des besoins2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Une petite chaîne d'hôtels a décidé de mettre sur le web un système de réservation de chambres ouvert à tout client, 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é, 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.

Activité acquisition des besoins :Modèle du domaineReprésentation des classes conceptuelles d’une situation réelleobjets métier (ex. Réservation), du monde réel (ex. Chambre), événementsquelques attributs, peu d’opérationsassociations (s’il y a nécessité de conserver la mémoire de la relation)les classes non retenues sont placées dans un glossaire« Dictionnaire visuel » du domaine construit surtout pendant la phase d’élaboration, itérativement en fonction des CU considérésServira à réduire le décalage des représentation entre domaine et objets logiciels inspiration pour la construction de la couche domaine de l'architecture logicielle (parfois aussi appelée modèle de domaine : ne pas mélanger)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité acquisition des besoins :modèle du domaine2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1OccupationdateDébut dateFin NuméroRéservationMénageNotedateDébut dateFin Hôtel0..*0..*ChambreHôte0..*0..*Sdb : douchenettoie

Activité acquisition des besoins :Pour construire un modèle du domaine 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(Larman) Réutiliser/modifier des modèles existantsLister les catégories classes : objets physiques, transactions, autre systèmes informatiques, organisations, documents de travail, etc.associations : A est membre de B, A est une transaction liée à une transaction B, A est une description de B, etc.Utiliser des groupes nominaux extraits par exemple des CU détaillés

Activité acquisition des besoins :Modèle du métier (facultatif)Modèle des CU métierreprésenter les processusacteurs métierCU organisation boîte blanche,objectif stratégiqueModèle objet métiermontre comment les CU métier sont réalisés par acteurs métiertravailleurs métierentités métier2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1ClientRéservationGérantPlanningMénage

Activité acquisition des besoins Modélisation de processus métiers2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1nettoyagedemandé ?Nettoyer chambreMarquer chambre Nettoyer chambreFaire litChambreChambreNettoyer salle de bain

Activité acquisition des besoins :Produits de l’acquisition des besoins2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Concepts del’applicationUtilisateursExpériencedu domaineDocumentsmanuel AQ

…Acquisition des besoinsCompréhension du systèmeModèle du domaine(modèle du métier)Liste des besoinspotentielsSpécification des besoins

Activité expression des besoinsObjectifs (1/4)Définir les besoins fonctionnelsécrire les récits d’utilisationdéfinir les acteurs et leurs objectifslimites du système à construire interactions avec le systèmedéfinir les cas d’utilisation portée système / objectif utilisateurdescription brève, puis plus détailléeconstruire le modèle des cas d’utilisationorganiser les cas d’utilisationutiliser des CU portée organisation2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité expression des besoinsExemple : description des CU2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Le 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 mais non détaillé (sous-système classique).Localement, la base de données est considérée comme interne au système et ignorée pour l'instant.Systèmeréservation à distanceRéserver une chambreClient« actor »Système bancaireConfirmerune réservation

Activité expression des besoinsDescription des CU2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Système gestion hôtelAdministrer hôtelLe gérant gère les chambres, leur catégorie, leur prix... Il peut déclarer qu'une chambre est momentanément non utilisable (travaux...). Il fait le bilan mensuel des employés de nettoyage. Il tient à jour une liste des services et les prix (petit déjeuner en salle, dans la chambre...)...Ajouter chambreLe gérant crée une chambre dans le système, avec toutes ses caractéristiques.Facturer client ...Facturer client« actor »Système bancaireFaire bilanménageAdministrerhôtelGérant« actor »Système réservationAjouter chambreRéserver chambreNettoyageMettre à jour lenettoyage

Activité expression des besoinsObjectifs (2/4)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Classer 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 testsLes 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é. Le système de gestion des chambres pour le ménage peut entraîner des questions techniques difficiles (équipement mobile).Réserver une chambre sur le webRéserver une chambre (locale)Trouver la prochaine chambre à nettoyerAdministrer...

Activité expression des besoinsObjectifs (3/4)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Détailler et formaliser les cas d’utilisationscénariosséquence d’étape nominaleextensionscompléter la description des scénarios éventuellement diagrammes de séquence système, diagrammes d’activité, de machines d’états maquette IHM uniquement si l’interface est complexe ou nécessite une évaluation par le clientStructurer le modèleréorganiser si besoinUtilisateurs non spécialistes, interface simple et logique. Problème classique, sans risque majeur, donc pas de maquette.

Activité expression des besoinsDétails des cas d’utilisation2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Description détailléescénario nominal, extensions (voir cours sur la rédaction des CU)CU : Réserver une chambrePortée : système de réservationNiveau : objectif utilisateurActeur principal : GérantIntervenants et intérêts : Client, Chaîne hôtelièrePréconditions : une chambre est libre pour la période désiréeGaranties minimales : rien ne se passeGaranties en cas de succès : la chambre est réservéeScénario nominal1. 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.…

Activité expression des besoinsObjectifs (4/4)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Appréhender les besoins non fonctionnels (contraintes sur le système : environnement, plate-forme, fiabilité, vitesse…)rattacher si possible les besoins aux cas d’utilisationdescription dans les descriptions des CU (section « exigences particulières » pour UP)sinon, dresser une liste des exigences supplémentairesLa 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 sont reliés en permanence au système de réservation aux coupures près (ADSL) et les postes devront être fiables (reprise sur erreur après 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.

Activité expression des besoinsArtefactsConcepts del’applicationUtilisateursExpériencedu domaineDocumentsmanuel AQ

…Acquisition des besoinsCompréhension du systèmeModèle du domaine(modèle du métier)Liste des besoinspotentielsSpécification des besoinsBesoins / spécifications(non fonctionnels)supplémentairesClassement des cas( vue architecture)Maquette(s) interface(s) utilisateurModèle des cas d’utilisation (texte)AnalyseGlossaireVision2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité expression des besoinsExpression des besoins : travailleurs2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Analyste système, du domainemodèle du domaine / du métiermodèle des CU / acteursglossaireSpécificateur de cas d’utilisationCU détaillésConcepteur d’interface utilisateurmaquette/prototypeArchitectevue architecturale du modèle des CU

Activité analyseObjectif généralConstruire le modèle d’analyse pour préparer la conceptionforme générale stable du systèmehaut-niveau d’abstraction réalisation des cas d’utilisation par des objets/classes d’analysepassage du langage du client à celui du développeur2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité analyseObjectifs (1/4)Mener l’analyse architecturaleidentifier les paquetages d’analyseregroupement logique indépendant de la réalisationrelations de dépendances, navigabilité entre classes de paquetage différentsà partir des CU et du domaineservira de point de départ pour le découpage en sous-systèmes2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité analyseDécoupage en paquetages2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Gestion réservationsRéservationsClients/gérantsRéservationsGestion hôtelRequêtesgérantsComptabilitéConnexionsystèmebancaire

Activité analyseObjectifs (2/4)Mener l’analyse architecturale (suite)Identifier les classes entités manifestes (premier modèle structurel)modèle des 10-20 classes constituant l’essence du domaine (à partir du modèle du domaine/métier)3 stéréotypes de classe : frontière, contrôle, entitéresponsabilités évidentesIdentifier les exigences particulières communesdistribution, sécurité, persistance, tolérance aux fautes…les rattacher aux classes et cas d’utilisation2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité analysePremier modèle structurel 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(paquetage : Gestion hôtel)<< InterfaceUtilisateur >>AgentNettoyageGestionHotelHôtelEmploie+lesAgentsnuméronuméroHistorique<<InterfaceLogicielle >>CComptabilitéNettoieNettoyage<< InterfaceLogicielle >>+lesChambresSystèmeRéservationOccupeHôteChambredateDébut : DateResponsabilités : - connaître sa taille- connaître son équipement- savoir si elle est occupéedateFin : Date<< InterfacePhysique >>CommunicationRéseau

Activité analyseObjectifs (3/4)Analyser les cas d'utilisationréaliser les scénarios des cas d'utilisationidentifier les classes, attributs et relationsexaminer l'information nécessaire pour réaliser chaque scénarioajouter 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.décrire les interactions entre objetsdiagrammes de séquencediagrammes de communicationsi scénario trop complexe, modéliser par parties (enchaînements), et indiquer les branchements Le modèle structurel sera construit pour supporter l'union des collaborations et interactions exprimées2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité analyseDiagramme de communication2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1(Réalisation du CU« Mettre à jour le nettoyage »)2.3: ajouter(nouvNettoyage)2:chambreNettoyée(noCh,noEmpl)2.4: afficher(resteANettoyer): Hôtel:IUGestionHôtel2.1: marquer(nettoyée)1:Chambre nettoyée2.2: nouvNettoyage :=New(date,lesAgents[noEmpl]…)lesChambres[noCh] : Chambre: Nettoyage{new}

Activité analyseObjectifs (4/4)Préciser les classes d’analysefaire le bilan des responsabilités à partir des collaborations responsabilité d’une classe = union des rôles dans tous les cas (négliger en analyse les opérations implicites)identifier les attributs rester simple, pas choix de conception à ce niveauidentifier les associationsidentifier les relations d’héritageidentifier les besoins spéciaux des classesVérifier les paquetages d’analysedépendances, couplagesils seront à la base des composants / sous-systèmesPrendre un nouveau cas d’utilisation et recommencer 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité analyseDiagramme de classes complété2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1<< InterfaceUtilisateur >>AgentNettoyageGestionHotelHôtelEmploie+lesChambres+lesAgentsajouter()chambreNettoyee()Historique<<InterfaceLogicielle >>CComptabilitéNettoieNettoyage<< InterfaceLogicielle >>+lesChambresSystèmeRéservation0..nOccupeHôteChambrenuméromarquer()dateDébut : DatedateFin : Date<< InterfacePhysique >>CommunicationRéseau

Activité analyseProduits de l’analyse2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Produits des activités précédentesAnalyseModèle de paquetagesRéalisation des cas(collaboration, séquences)Description del’architecture(analyse)Modèle d’analyse(structurel)Conception

Activité analyseTravailleurs 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Architecteresponsable de l’intégrité du modèle d’analysedescription de l’architectureextrait du modèle d’analyseIngénieur des CUréalisation/analyse des CUIngénieur des composantsclasses d’analysepaquetages d’analyse

Activité analyseComparaison des modèles CU et analyse2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Remarque :Différentes sortes de classesClasse conceptuelleobjets du monde réelClasse d’analyse3 stéréotypes de Jacobson : frontière, contrôle, entitéClasse logiciellecomposant logiciel du point de vue des spécifications ou de l’implémentationClasse d'implémentationclasse telle que implémentée dans un langage OO2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité conceptionObjectifsProposer une réalisation de l'analyse et des cas d’utilisation en prenant en compte toutes les exigencesMener la conception architecturaleidentifier les nœuds et la configuration du réseau (déploiement), les composants/sous-systèmes et leurs interfaces (modèle en couche), les classes significatives de l'architectureConcevoir les cas d'utilisationidentifier 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éciauxConcevoir les sous-systèmesmettre à jour les dépendances, les interfaces...composants de service liés à l’appli, de middleware…permettra de distribuer le travail aux développeurs2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité conceptionDiagramme de déploiement2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Client iClient 1Client ninternetinternetinternetServeurclientsSystèmebancaireBDréservationsLANWANLANServeurGérantsADSLADSLADSLGérant 1ServeurhôtelPostegérant Gérant i Les deux serveurs et la BD des réservations peuvent être sur un même nœud tant que les liaisons clients ne pénalisent pas les liaisons gérants

Les liaisons gérant-serveur sont en ADSL

Possibilité que les hôtel aient un unique poste, ou bien un serveur local

...Activité conceptionDécoupage en composants2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1<<component>>Accès système bancaire<<component>>Requêtes gérant<<component>>Stockageréservations<<component>>RéservationsPaiementAccès BDServices gérantRéservation<<component>>Gestion hôtel<<component>>BD gestion<<component>>ComptabilitéODBCCompta

Activité conceptionProduits de la conception2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Produits des activités précédentesConceptionModèle des composantsDiagrammes d’interactions détaillés (cas)Description del’architecture(conception)Modèle de classede conceptionRéalisationModèle de déploiement

Activité conceptionTravailleurs2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Architecteintégrité des modèles de conception et de déploiementdescription de l’architectureIngénieur de CUréalisation/conception des CUIngénieur de composantsclasses de conceptioncomposants/sous-systèmes de conceptioninterfaces

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Activité réalisationComparaison des modèles analyse et conception

Activité réalisationObjectifsFaire la mise en œuvre architecturaleidentifier les artefacts logiciels et les associer à des nœudsIntégrer le systèmeplanifier l'intégration, intégrer les incréments réalisésRéaliser les composants/sous-systèmesRéaliser les classesMener les tests unitairestests de spécification en boîte noire, de structure en boîte blanche2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité réalisationProduits de la réalisation2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Produits des activités précédentesRéalisationComposants et sous-systèmesInterfaces(composants et sous-systèmes)Pland’intégrationArtefacts :exécutables, bibliothèques, fichiers,données…Test

Activité réalisationTravailleurs2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Architectemodèles d'implémentation et de déploiementdescription de l’architectureIngénieur de composantsartefacts logiciels, sous-systèmes et composants d’implémentation, interfacesIntégrateur systèmeplan de construction de l’intégration

Activité testObjectifsRédiger le plan de testdécrire la stratégie de test, estimer les besoins pour l'effort de test, planifier l'effort dans le tempsConcevoir les testsAutomatiser les testsRéaliser les tests d'intégrationRéaliser les tests du systèmeÉvaluer les tests2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Activité testProduits de l’activité de test2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Produits des activités précédentesTestModèle de testCas de tests, procédures de test,composants de testDéfautsPlan de testCouverture destests

Activité testTravailleurs2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Concepteur de testsmodèle de tests, cas de test, procédures de test, évaluation des tests, plan de testsIngénieur de composantstest unitairesTesteur d’intégration tests d’intégrationTesteur systèmevérification du système dans son ensemble

Un exemple de projet à 7 itérationsEtude Prélimi-naireTran-sitionÉlaborationConstructionitération1it2it3it4it5it6it7Capture des besoinAnalyseConception RéalisationTestSqueletteexécutableVersion bétaVersion finale2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Gestion des phasesPlanifier les phasesallouer le temps, fixer les points de contrôle de fin de phase, les itérations par phase et le planning général du projetDans chaque phaseplanifier les itérations et leurs objectifs de manière à réduireles risques spécifiques du produitles risques de ne pas découvrir l'architecture adaptéeles risques de ne pas satisfaire les besoinsdéfinir les critères d'évaluation de fin d'itérationDans chaque itérationfaire les ajustements indispensables (planning, modèles, processus, outils...)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Phase d’étude préliminaire 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Objectif : lancer le projetétablir les contours du système et spécifier sa portéedéfinir les critères de succès, estimer les risques, les ressources nécessaires et définir un planà la fin de cette phase, on décide de continuer ou nonattention à ne pas définir tous les besoins, à vouloir des estimation fiables (coûts, durée), etc. on serait dans le cadre d’une cascadeRessourcesTestsRéalisationBesoinsAnalyseConception

Activités principales de l’étude préliminaireCapture des besoinscomprendre le contexte du système (50-70% du contexte)établir les besoins fonctionnels et non fonctionnels (80%)traduire les besoins fonctionnels en cas d'utilisation (50%)détailler les premiers cas par ordre de priorité (10% max)Analyseanalyse des cas d'utilisation (10% considérés, 5% raffinés)pour mieux comprendre le système à réaliser, guider le choix de l'architectureConceptionpremière ébauche de la conception architecturale : sous-systèmes, nœuds, réseau, couches logiciellesexamen des aspects importants et à plus haut risque2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Livrables de l’étude préliminairePremière version du modèle du domaine ou de contexte de l’entreprise parties prenantes, utilisateurs Liste des besoinsfonctionnels et non fonctionnelsÉbauche des modèles de cas, d’analyse et de conceptionEsquisse d’une architectureListe ordonnée de risques et liste ordonnée de casGrandes lignes d’un planning pour un projet completPremière évaluation du projet, estimation grossière des coûtsGlossaire2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Phase d’élaboration2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Objectif : analyser le domaine du problèmecapturer la plupart des besoins fonctionnelsplanifier le projet et éliminer ses plus hauts risquesétablir un squelette de l’architectureréaliser un squelette du systèmeRessourcesTestsBesoinsRéalisationAnalyseConception

Activités principales de l’élaborationCapture des besoinsterminer la capture des besoins et en détailler de 40 à 80%faire un prototype de l'interface utilisateur (éventuellement)Analyseanalyse architecturale complète (paquetages...)raffinement des cas d'utilisation (pour l'architecture, < 10%)Conceptionterminer la conception architecturaleeffectuer la conception correspondant aux cas sélectionnésRéalisationlimitée au squelette de l'architecturefaire en sorte de pouvoir éprouver les choixTestdu squelette réalisé2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Livrables de l’élaborationUn modèle de l'entreprise ou du domaine completUne version des modèles : cas, analyse et conception, (<10%), déploiement, implémentation (<10%) Une architecture de base exécutable La description de l'architecture (extrait des autres modèles)document d’architecture logicielleUne liste des risques mise à jourUn projet de planning pour les phases suivantesUn manuel utilisateur préliminaire (optionnel)Évaluation du coût du projet 2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Phase de constructionObjectif : Réaliser une version beta2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1RessourcesTestsRéalisationBesoinsAnalyseConception

Activités principales de la constructionCapture des besoinsspécifier l'interface utilisateur Analyseterminer l'analyse de tous les cas d'utilisation, la construction du modèle structurel d'analyse, le découpage en paquetages...Conceptionl'architecture est fixée et il faut concevoir les sous-systèmes dans l'ordre de priorité (itérations de 30 à 90j, max. 9 mois)concevoir les cas puis les classesRéalisationréaliser, faire des tests unitaires, intégrer les incrémentsTesttoutes les activités de test : plan, conception, évaluation...2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Livrables de la constructionUn plan du projet pour la phase de transitionL'exécutableTous les documents et les modèles du systèmeUne description à jour de l'architectureUn manuel utilisateur suffisamment détaillé pour les tests2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Phase de transitionObjectif : mise en service chez l’utilisateurtest de la beta-version, correction des erreurspréparation de la formation, la commercialisation2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1RessourcesTestsBesoinsAnalyseConceptionRéalisation

Préparer la version beta à testerInstaller la version sur le site, convertir et faire migrer les données nécessaires...Gérer le retour des sitesLe système fait- il ce qui était attendu ? Erreurs découvertes ? Adapter le produit corrigé aux contextes utilisateurs (installation...)Terminer les livrables du projet (modèles, documents...)Déterminer la fin du projetReporter la correction des erreurs trop importantes (nouvelle version)Organiser une revue de fin de projet (pour apprendre)...Planifier le prochain cycle de développement2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Activités principales de la phase de transition (déploiement)

Livrables de la transitionL'exécutable et son programme d'installationLes documents légaux : contrat, licences, garanties, etc.Un jeu complet de documents de développement à jourLes manuels utilisateur, administrateur et opérateur et le matériel d'enseignementLes références pour le support utilisateur (site Web...)2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Taux de complétion des modèles par rapport aux phases2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1CréationÉlaboration UACDITUACDITU : modèle des cas d'utilisationA : modèle d’analyseC : modèle de conceptionD : modèle de déploiementI : modèle d’implémentationT : modèle de testsConstruction Transition UACDITUACDIT

Les tentations de la cascadeLes « principes cascade » ne doivent pas envahir le processuson ne peut pas tout modéliser avant de réaliserExemples de situations problématiques« nous avons une itération d’analyse suivie de deux itérations de conception »« le code de l’itération est très bogué, mais nous corrigerons tout à la fin »« la phase d’élaboration sera bientôt finie : il ne reste que quelques cas d’utilisation à détailler »2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Attention aux personnesLe processus a un impact sur les personneschangements de rôleson passe des « ressources » aux « travailleurs »Mérites UP par rapport aux personnesfavorise le travail d’équipechaque membre comprend son rôleles développeurs appréhendent mieux l’activité des autres développeursles dirigeants comprennent mieux diagrammes d’architecturesi tout le monde le connaît meilleure productivité de l’entreprise (passage d’un projet à l’autre, formation)Nécessités de la communicationles artefacts soutiennent la communication dans le projetil faut également des moyens de communications2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Personnes, environnement et outilsUn mixte de facteurs à prendre en compte dans la gestion du projetéquilibre entre outils et processus (gérer leur influence réciproque)nécessaire gestion de tous les artefacts et de la communicationsite web du projet, wiki, gestion de versions, etc.organisation physiques des personnes et artefacts physiquestableaux, outils de projection et de capture, pièces et circulation, etc.2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Plan Trame du processus unifiéProcessus unifié : caractéristiques essentiellesDescription du processus unifiéIllustration : deux déclinaisons2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Two Tracks Unified ProcessProcessus proposé par Valtech (consulting), présenté dans Pascal Roques, Franck Vallée (2004) UML2 en action (3ème édition), Eyrolles, 386 pp.Objectifprendre en compte les contraintes de changement continuel imposées aux systèmes d’information des organisationsCréation d’un nouveau SIdeux grandes sortes de risquesimprécision fonctionnelle : inadéquation aux besoinsincapacité à intégrer les technologies : inadaptation techniqueEvolution du SI deux grandes sortes d’évolutionsévolution fonctionnelle évolution technique2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Two Tracks Unified ProcessPrincipe généraltoute évolution imposée au système d’information peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un axe techniqueTTUPprocessus unifié (itératif, centré sur l’architecture et piloté par les CU)deux branchesbesoins techniques : réalisation d’une architecture techniquebesoins fonctionnels : modèle fonctionnelréalisation du systèmefusionner les résultats des deux branches du processus2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Branche techniqueBranche fonctionnelleContraintesfonctionnellesContraintestechniquesCapture de besoins fonctionnelsCapture des besoins techniquesAnalyseConception génériqueArchitecture techniqueModèle d’analysePrototypeConception préliminaireConception détailléeCodage et testsRecetteBranche conception et développement logiciel

TTUP : commentairesCôté fonctionnelrelativement classique, indépendant des technologiesmodèle d’analyse réutilisableCôté technique insistance sur l’architecture technique indépendamment des besoins fonctionnels c’est un problème de conception en soinotion de CU techniquesdépend de l’existantarchitecture à base de composantarchitecture technique réutilisableBranche communeconception préliminaire : le plus délicat2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1

Itérations et TTUP2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1Etude préliminaireElaborationConstructionIncr.4…Incrément 1Incr.2Incr.3Incr.5

CM processus-unifie

Contenu connexe

Tendances

En vedette

Similaire à CM processus-unifie

Plus de Yannick Prié (Enseignement)

Dernier

CM processus-unifie