1 / 33

1. Pourquoi une méthode ? 2. Les constituants d ’une méthode 3. Le concept de système

1. Pourquoi une méthode ? 2. Les constituants d ’une méthode 3. Le concept de système 4. Cycles de vie et cycles de développement 5. Panorama des méthodologies objet 6. Mise en œuvre des méthodologies objet : le RUP 7. Approches « RAD » et « Concurrent Engineering »

nika
Download Presentation

1. Pourquoi une méthode ? 2. Les constituants d ’une méthode 3. Le concept de système

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 1. Pourquoi une méthode ? 2. Les constituants d ’une méthode 3. Le concept de système 4. Cycles de vie et cycles de développement 5. Panorama des méthodologies objet 6. Mise en œuvre des méthodologies objet : le RUP 7. Approches « RAD » et « Concurrent Engineering » 8. Méthodes OO et « Business Process Reengineering » Méthodologie objetCycle de développement objetC. Soulé-DupuyProfesseur d ’informatique Université Toulouse 1 &Institut de Recherche en Informatique de Toulouse

  2. Utilisateurs Maître d ’ouvrage Maître d ’oeuvre Développeurs Cheminement de la communication dans un processus de développement 1. POURQUOI UNE MÉTHODE ? • Volonté d ’HOMOGÉNÉISATION de la prise en compte et de la résolution de problèmes • Nécessité d ’une CONCERTATION entre : • utilisateurs • décideurs • informaticiens • Fixer des règles opératoires • Capitaliser des expériences • Nécessité de spécifier et de concevoir en abordant conjointement cadre décisionnel et informatique • Nécessité d ’une approche globale • cohérence • priorités

  3. 1. POURQUOI UNE MÉTHODE ? • Elle guide et indique comment aborder les problèmes au travers de • formalismes • démarche de modélisation • Elle propose des normes ou standards de présentation des résultats de la spécification et de la conception • langage standardisé • démarche vérifiable • validation aisée Une méthode a un double rôle :

  4. 2. LES CONSTITUANTS D ’UNE MÉTHODE • Philosophie générale • support continu métier • guide sur la façon d ’aborder les problèmes dans leur environnement • Démarche • mode d ’emploi de la méthode • découpage du processus de développement en étapes cohérentes • Vocabulaire • identifier les concepts • décrire les concepts • Formalisme et normes • spécifier la représentation des composantes du système • Outils • aides à l ’analyse et à la conception • aides à la réalisation

  5. 3. LE CONCEPT DE SYSTÈME • Définition Autrement dit : • ensemble d ’éléments matériels ou immatériels en interaction • transforment, grâce à un processus, des éléments (entrées) en d ’autres éléments (sorties) « UN SYSTÈME EST UN ENSEMBLE D ’ÉLÉMENTS EN INTERACTION DYNAMIQUE ORGANISÉS EN FONCTION D ’UN BUT DONNÉ »

  6. 3. LE CONCEPT DE SYSTÈME • Schéma général d ’un système :

  7. 3. LE CONCEPT DE SYSTÈME Approche systémique

  8. Spécifications fonctionnelles Tests de vérification Conception Expression des besoins Analyse Implémentation Validation 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT • Cycles de vie linéaires • applications traditionnelles • processus séquentiels

  9. Expression des besoins Validation des besoins Spécifications fonctionnelles Validation fonctionnelle Conception du système Test du système Conception des composants Test des composants Implémentation 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT • Cycles de vie en « V » • enchaînement de phases autonomes • facilite vérification et validation

  10. 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT • Le cycle de vie objet • traçabilité entre les étapes • caractère itératif • caractère incrémental Analyse Conception Spécifications V 1.0 V 1.1 V 1.2 Implémentation Validation Tests

  11. 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT • Cycle de développement Orienté Objet Exigences Analyse et conception Modélisation métier Planification Gestion des changements et de la configuration Réalisation Planification initiale Environnement Tests Déploiement Évaluation

  12. Cascade Faible formalisme Formalisme élevé Itératif 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT • Quel cycle de vie ? Quel Cycle de développement ? Peu de risques Séquentiel Intégration et tests tardifs Peu de documentation Processus légers Bien documenté Traçabilité Comité de contrôle des changements Piloté par les risques, Intégration et tests continus

  13. 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT • Les paradigmes de modélisation • axe structurel et statique • axe temporel et dynamique • axe fonctionnel STRUCTUREL MÉTHODE DE CONCEPTION FONCTIONNEL DYNAMIQUE

  14. 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT • Niveaux d ’abstraction : 3+1 niveaux de préocccupation • couche de modélisation conceptuelle • couche de modélisation logique et organisationnelle • couche de modélisation physique et opérationnelle Niveau Préoccupations Données Traitements Flux ConceptuelQUOI ? Conceptuel Conceptuel Conceptuel QUE VEUT-ON FAIRE ? Organisationnel QUI ? OU ? QUAND ? Organisationnel Organisationnel Organisationnel Logique COMMENT ? Logique Logique Physique AVEC QUELS MOYENS Physique Opérationnel

  15. 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT • Niveaux d ’abstraction (suite) :

  16. 4. CYCLES DE VIE ET CYCLES DE DÉVELOPPEMENT Processus de Conception Les résultats types Globalement Expression des besoins Articulation des domaines PLAN DE DÉVELOPPEMENT Description choix scénario de développement Par système Etude préalable DOSSIER DE CHOIX Description 2ème sous-système Description 1er sous-système Par sous-système Etude détaillée CAHIER CHARGES CAHIER CHARGES UTIL. REAL. UTIL. REAL. Réalisation et mise en œuvre 1er module Réalisation et mise en œuvre 2ème module Réalisation et mise en oeuvre Par module ou paquetage DOC. 1er MODULE DOC. 2ème MOD.

  17. 5. PANORAMA DES MÉTHODES OBJET • Précurseurs de  RUP-UML • OOD (Object Oriented Design) - G. Booch • Ada, C++, Smalltalk, Eiffel • HOOD (Hierarchical Object Oriented Design) • Ada • OOA (Object Oriented Analysis) - Shlaer & Mellors • OOA / OOD - Coad & Yourdon • OMT (Object Modeling Technique) - Rumbaugh • OOSE (Object Oriented Software Ingineering) - Jacobson • OOM (Orientation Objet dans Merise) 1985 1993

  18. 5. PANORAMA DES MÉTHODES OBJET • Aujourd ’hui, les AGL (Atelier de Génie Logiciel ) permettant une modélisation objet : • intègrent UML • Rational ROSE (Rational Inc.) OMT, Booch, UML • ISOA (MEGA International) UML, Chen ER • ObjectPartner (Verilog) OMT, UML • Paradigm Plus (Platinum Technology) OMT, Booch, UML, Jacobson, Chen ER, OOA (Slaer & Al.), ... • StP ou Software through Pictures (Aonix) OMT, Booch, UML • ... • Intègrent un processus UP • permettent la génération de code C++ et Java et éventuellement VisualBasic

  19. 5. PANORAMA DES MÉTHODES OBJET • Evolution des méthodes Objet UML 2.0 Septembre 2003 Spécifications sur le site Web de l ’OMG : http://www.omg.com UML 1.3 Juin 1999 Rational SW, Microsoft, HP, ICON, ORACLE, Unisys, MCI Systemhouse, TI SW : soumission commune à l ’OMG, 17 Janvier 1997 UML 1.1 UML 1.0 Spécifications sur le site Web Rational : http://www.rational.com WWW, Juin 96 UML 0.9 Partenaires IBM ObjecTime/ROOM Unified Method 0.8 OOPSLA ’95 Booch ’93 OMT-2 Jeu de documentation Autres méthodes Booch ’91 OMT-1 J. Rumbaugh, 91 OOSE (Objectory) I. Jacobson, 92

  20. 6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP • L ’ingénierie de systèmes avec le RUP: Rational Unified Process) « Production de logiciel d ’un haut niveau de qualité correspondant aux besoins de l ’utilisateur final dans le cadre de programmes et de budgets prévibles » • Approche disciplinée sur la manière d ’attribuer les tâches et les responsabilités • maîtrise des moyens • maîtrise des coûts • maîtrise des délais • S ’adapte à tous types de projets et d ’organisations • processus itératif • décomposé en phases et itérations modulables et configurales

  21. 6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP • 4 phases dans le RUP 1. Inception Cadre du système et portée du projet 2. Elaboration Analyser le système et développer le plan du projet 3. Construction Développement du système 4. Transition Livraison du système aux utilisateurs • Itération • Cycle de développement logiciel (ou système) complet depuis le recueil des besoins jusqu ’à l ’implantation et aux tests. • Se termine par la sortie d ’une version exécutable du projet 1..* itérations par phase Cf. plan détaillé fourni séparément.

  22. 6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP PHASES Inception Elaboration Construction Transition Workflows du processus Modélisation métier Exigences Analyse et conception Implantation Tests Déploiement Workflows de soutien Gestion de configuration et des changements Gestion de projet Environnement Itér. #1 Itér. #2 Itér. #n Itér. #n+1 Itér. #n+2 Itér. #k Itér. #k+1 Itération(s) préliminaire(s) ITÉRATIONS

  23. 6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP Modélisation métier Gestion de projet Déploiement et maintenance Urbanisation du système Construction, Intégration et Test Développement du sous-système logiciel Développement et acquisition du matériel

  24. 6. MISE EN ŒUVRE DES MÉTHODOLOGIES OBJET : le RUP Utilisateurs Fonctionnalités Programmeurs Gestion du logiciel Vue Logique Vue des Composants Vue des Cas d’ Utilisation Maîtrise d ’ouvrage / Analystes Comportements Vue des Processus Vue de Déploiement Intégrateurs de systèmes Performance Robustesse, Adaptabilité Débit Ingénierie du système Topologie du système Distribution, Installation Communication

  25. 7. APPROCHES «RAD» et «CONCURRENT ENGINEERING» Réduction du cycle de vie • Rapid Application Development • approche par prototypage itératif • meilleure appréhension des objectifs d ’un projet et des besoins • Concurrent Engineering • Ingénierie simultanée • « prendre les bonnes personnes au bon moment pour identifier et résoudre les problèmes de conception »

  26. 8. MÉTHODES OO ET « BPR » • Objets métiers et objets logiciels • Objet métier • générique / contexte idéal • terme utilisé tant en génie logiciel qu’en management • objets perçus au pour l ’implantation des modèles conceptuel et logique • Objet logiciel • objets perçus au niveau de l ’architecture logicielle

  27. 8. MÉTHODES OO ET « BPR » • Objets métiers et objets logiciels • Architecture en couches Processus métier Organisation métier Interfaces H-M Ecrans / dialogues / maquettes Contrôle Liens écrans / modèles Applications Modèles Conceptuel & logique Objets métiers Services Services techniques / objets de classes prédéfinies Communication Echanges entre applications distantes, accès BD, ... Objets techniques Stockage Données persistantes / matériel / base de données / système d ’exploitation Objets d ’infrastructures

  28. 8. MÉTHODES OO ET « BPR » • Objets métiers et objets logiciels • Structuration des objets métiers • Diagramme de classes global • partitionnement du modèle de classes en paquetages==> identifier le domaine métier • classes liées par agrégation • même attente utilisateur • même responsabilité géographique et fonctionnelle Entités de pilotage Entités opérantes Entités externes

  29. 8. MÉTHODES OO ET « BPR » • Objets métiers et objets logiciels • Fractionner la migration par phase==> limiter les risques Axe applicatif (paquetage logique) Axe technique (infrastructure) Axe géographique (structure entreprise)

  30. 8. MÉTHODES OO ET « BPR » • Business ProcessReengineering • Nouveaux modes de restructuration dynamique et continuelle • réaction rapide face aux changements de l ’environnement • forte aptitude au changement • La complexité des systèmes et de leur management nécessite des méthodes et outils nouveaux permettant aux acteurs de mieux comprendre l ’organisme et le système

  31. 8. MÉTHODES OO ET « BPR » • Business Process Reengineering • Objectifs du « BPR » • correction • prévention • anticipation • satisfaction client / utilisateur • privilégier processus et non fonction ==> Reconfiguration de processus Compréhension du fond Hommes Succès Organisation du projet BPR Développement incrémental

  32. 8. MÉTHODES OO ET « BPR » • Business Process Reengineering • Le processus est : • transversal • dynamique • rarement indépendant du produit fini • Le processus correspond à une action

  33. 8. MÉTHODES OO ET « BPR » • Déroulement du « BPR » ÉTAPES PHASES - Volonté de l ’action - Étude d ’opportunité - Préparation de la logistique Lancement de l ’action BPR Existant et bilan Conception Mise en œuvre - Compréhension de l ’existant - Élaboration des stratégies - Conception des processus métier - Planification des actions - Implantation - Suivi des processus Processus incrémental

More Related