La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Urbanisme, modélisation, UML ENSG 18 septembre 2006.

Présentations similaires


Présentation au sujet: "Urbanisme, modélisation, UML ENSG 18 septembre 2006."— Transcription de la présentation:

1 Urbanisme, modélisation, UML ENSG 18 septembre 2006

2 I – Urbaniser un SI

3 Un cas : lANPE Volumétrie – salariés équipés de PC en réseau –1 000 agences disséminées sur le territoire –Budget informatique annuel de plus de 100 M Un cœur de métier : lintermédiation du marché de lemploi –Stocker des offres et des demandes, trouver des rapprochements –Deux clients : lentreprise, lactif (demandeur demploi le plus souvent) Plusieurs grands projets –GEODE : intermédiation du marché de lemploi (cœur de métier) –OASIS : gestion des ressources humaines –SIAD : système daide à la décision : services à distance (Internet et/ou téléphonie) –Informatique de communication Messagerie, agenda partagé, Intranet, workflows

4 Principes Fournir une « portée de phares » de trois ans –Mettre en perspective le budget annuel –Anticiper à grosses mailles les évolutions futures –Un exercice à renouveler chaque année « Schéma dévolution du système dinformation » Appel doffres, puis contrat avec DMR (devenue ensuite Mitsubishi) Calendrier des travaux –Début en novembre 2000 –Livrable final prévu pour fin 2001, rendu en juin 2002 Phases des travaux –1 – État des lieux –2 – Objectifs prioritaires –3 – Architecture cible –4 – Plan daction

5 Déroulement Organisation des travaux –Une responsabilité bi-céphale Direction de larchitecture de la DSI Coordination des maîtrises douvrage –Dans chaque métier, un maître douvrage délégué –Un comité de pilotage mensuel Difficultés –Une logistique compliquée Recueil dexpertise Rédaction, circulation et recueil des remarques Validation des documents Communication, appropriation… –Dépais dossiers à la lecture laborieuse Besoin dune présentation figurée, imagée

6 Le schéma durbanisme Une cartographie qui se détaille par zooms successifs : Entreprise DomaineProcessusActivitéComposantDonnée

7 Le schéma durbanisme Les commentaires précisent le contenu et expliquent les choix de priorités La vue densemble montre la solidarité des divers domaines Mise en évidence des questions darchitecture –Importance des référentiels –Gestion des données de référence –Règles de mise à jour des bases de données –Exigences de synchronisation –Apports de linformatique de communication Un langage de modélisation –Utiliser UML sous une forme propre à la communication (diagramme dactivité)

8 Présenter un modèle à la validation Validations techniques Validation intermédiaire Validation stratégique Modèle formalisé Modèle « en français »

9 Lappropriation du schéma durbanisme Une très grande difficulté ! –Il est difficile de faire sapproprier le schéma durbanisme par lentreprise Les documents consignent le résultat dun travail technique –Ils sont longs –Ils ne se prêtent pas à la lecture –Il est difficile dobtenir des dirigeants une validation authentique La valeur ajoutée du dirigeant risque dêtre perdue Il faut compléter le SESI par une médiatisation –Elle doit toucher le cercle des dirigeants (~ 100 personnes environ), plus les experts métier et les experts de linformatique (quelques centaines), soit au total 2 % de lentreprise Buts –Percevoir les implications pratiques du système dinformation par delà son apparente abstraction –En tirer les conséquences en termes dorganisation (travail coopératif, application de nouvelles normes)

10 Couches de la plate-forme informatique Applications métiers Infrastructure applicative Infrastructure de communication Génie logiciel Infrastructure de base Équipement physique et OS Infrastructure dadministration

11 Urbanisme fonctionnel et urbanisme technique

12 Mise en discussion de questions stratégiques LAgence doit-elle ou non offrir des services marchands ? –Exemple : « recrutement par habileté ». Évaluer les prestations, facturer, encaisser, comptabiliser Faut-il enrichir lintermédiation du marché de lemploi en prenant en compte loffre de formation ? –Lintermédiation passe de deux à trois pôles : complexité multipliée par trois Faut-il articuler le système dinformation avec les services rendus sur lIntranet? –Modification des procédures, nouvelle répartition des responsabilités Faut-il articuler les services rendus sur le Web et les plateaux téléphoniques avec les services « présentiels » en agence ? –Mise en place dune CRM, intégration de services multicanaux Comment doit évoluer la relation avec les partenaires ? –Interopérabilité des systèmes dinformation

13 Principaux obstacles à lurbanisation Sociologiques –Refus de lexplicitation –Refus de la logique –Compromis managérial Intellectuels –Refus de la pratique de labstraction –Méconnaissance des techniques et apports de la modélisation –Défaut dexpertise en statistique Difficulté à définir les indicateurs –Difficulté à penser larticulation entre lêtre humain et lautomate Philosophiques –Difficulté à penser en termes de processus La pensée grecque porte sur des concepts pérennes… Refus de larticulation entre la pensée et laction

14 Que signifie « modéliser » ? Quest-ce quun modèle ? –représentation explicite dun être réel permettant de simuler mentalement son fonctionnement –théorie orientée vers laction –concepts (descriptifs) & relations fonctionnelles entre concepts Modèle implicite et modèle explicite –Chacun modélise tout le temps, mais de façon implicite –La science et lentreprise exigent des modèles explicites –Un modèle explicite est pratique, mais difficile à comprendre

15 « Modéliser » lentreprise Principe de la modélisation –Documenter les tâches réalisées dans lentreprise, tant par lêtre humain que par linformatique. Seule une partie des tâches est réalisée par le logiciel –Clarifier le vocabulaire, expliciter procédures et contraintes, rôles et responsabilités –Prévoir notamment les démarches en mode dégradé (Jacques Printz) Contenu du modèle –Référentiel Dictionnaire, identifiants, nomenclatures, règles de gestion –Urbanisme Modélisation globale : « plan de masse » des processus et de leurs relations –Modélisation du processus Enchaînement des activités humaines et opérations informatiques, dossiers (« objets ») que le processus manipule Règles de gestion : contraintes dintégrité, cycle de vie des objets

16 Plate-forme du SI Événement déclencheur Événement réponse Activité Indicateurs et bouclage Communication interpersonnelle Processus

17 Activité IHM Communication interpersonnelle EHO APU Organisation Plate-forme Écouter Comprendre Expliquer Concevoir Décider Classer Trier Calculer Traiter

18 II – Modéliser un processus

19 Finalités de la modélisation Finalité technique –Préciser la conception du SI, guider sa construction –Qualité du SI : ISO 9126 FURPSE : « Functionality, Usability, Reliability, Performance, System Maintainability, Evolutivity » Finalité intellectuelle –Élucider les objets, concepts, processus, référentiels de lentreprise –Compenser lautisme centrifuge des spécialistes –Que chacun puisse se représenter clairement Le cours du processus pour lequel il travaille Son propre rôle dans le processus, les rôles des autres acteurs Les relations entre les divers processus de lentreprise

20 Pourquoi modélise-t-on ? Certaines entreprises ne veulent pas modéliser… –Elles croient inutile de comprendre comment elles font ce quelles savent faire –Un modèle explicite dérouterait des salariés formés aux habitudes maison … dautres, de plus en plus nombreuses, sont contraintes modéliser –Évolutivité : lentreprise ne sera souple que si les salariés se sont appropriés le modèle –Interopérabilité : deux entreprises ne peuvent interopérer que dans la mesure où leurs modèles sont explicites

21 Comment présenter un modèle ? Modèle = être idéal (donc invisible) représenté par un document (texte et graphique) –Il faut fournir à chaque acteur (utilisateur, analyste, responsable hiérarchique, expert du domaine) la « vue » qui lui convient –Exemple : système dinformation géographique Deux écueils –Exagérer le formalisme dun langage de modélisation interdirait toute compréhension à certains acteurs –Labsence dune méthode de représentation empêcherait la collecte et la synthèse de linformation

22 Des vues autour du modèle formel

23 Quelles sont les « vues » que le modèle doit présenter ? Pour les informaticiens qui produisent le logiciel : faciliter le travail –Diagrammes de classe, détat etc. –Automatisation (partielle) de la production du code Pour les responsables hiérarchiques : faciliter la validation –Diagramme dactivité –Texte en langage naturel Pour les utilisateurs : faciliter lappropriation –Présentation sur lIntranet –Outil de contrôle personnel des connaissances

24 Une démarche méthodique

25 Les phases amont du développement Les acteurs (décisionnaires, utilisateurs, MOA) bâtissent lobjectif stratégique –Le contour du domaine, les engagements fonctionnels, budgétaires, de planning et architecturaux apparaissent –Enjeu : définir des objectifs compris par tous, réalistes, recouvrant entièrement la vision initiatrice du projet Maîtriser les risques –Sélection des ressources de développement –Compétence technique –Budget et planning réalistes –Conduite de projet organisée et suivie –Méthode de développement et assurance qualité adaptées au projet

26 Comment modéliser ? Langage UML et outils de cohérence –La méthode qui convient pour mettre en œuvre UML nest pas écrite –Il faut choisir dans la panoplie des outils Principes utiles –Critères de qualité du SI : Pertinence, Sobriété, Cohérence –Piloter par les livrables Définir les produits plutôt que la façon de les produire –Ne pas se lancer dans la modélisation sans disposer dune expression de besoins validée et stabilisée –Progresser « top down » Ne jamais anticiper une étape ultérieure Réaliser entièrement chaque étape avant dattaquer la suivante –Sassurer de lauthenticité des validations –Sil faut corriger, modifier en amont et boucler vers laval Le modèle métier peut être remis partiellement en question par la prise en compte des contraintes et ressources de la plate-forme

27 Méthode proposée pour la modélisation Phase 1 : –Expression de besoin validée –Dictionnaire Description du domaine –Approche systémique Structures impliquées, mode de coopération Notion de « flot dinformation » dUML 2.0 Phase 2 : –Modélisation des processus Diagramme dactivité –Modèle conceptuel Diagramme de classes –Règles métier Contraintes, invariants, pré- et post-conditions Démarche à suivre en fonctionnement dégradé Phase 3 : –Modèle de cas dutilisation Phase 4 : –Prise en compte des contraintes et ressources de la plate-forme –Modèle complet Validation et appropriation –Présentation du modèle aux responsables et aux utilisateurs

28 Approche systémique : le « flot dinformation »

29 Modélisation du processus

30 Cas dutilisation

31 « Modèle métier » et « modèle complet » (Pascal Roques et Franck Vallée, UML en action, Eyrolles 2003) Modèle métier Modèle complet Responsabilité de la MOA Responsabilité de la MOE Responsabilité conjointe Contraintes et ressources de la plate-forme

32 Pourquoi faut-il un modèle métier ? Les processus métier sont très divers –Automate pur (pilote automatique etc.) –Back-office –Front-office –Interopérabilité avec des partenaires –Exigences spécifiques Temps réel, synchronisme, qualité des données, homogénéité des codages –Bien séparer les rôles de lEHO et de lAPU Linformatique ne peut pas tout savoir La modélisation procure au métier une révision de ses processus, voire une relance de sa réflexion stratégique Lévaluation du coût et des gains (rentabilité) du projet progresse pendant la modélisation La révision du modèle métier lors de la prise en compte des contraintes et ressources de la plate-forme nexcèdera pas 10 à 20 %

33 Désordres à éviter Référentiel –Identifiants et nomenclatures défectueux, homonymes, dialectes locaux, défaut de mise à jour des BD Spécification –Démarrage précipité, inflation et versatilité des besoins Modélisation –Anticiper le travail des phases suivantes Validation –Manque de lisibilité du modèle Responsabilité –Confusion MOA/MOE, manque de légitimité de la MOA Conduite de projet –Mauvaise définition des comités, mauvaise qualité du suivi Appropriation –Carence de la communication avec les utilisateurs


Télécharger ppt "Urbanisme, modélisation, UML ENSG 18 septembre 2006."

Présentations similaires


Annonces Google