Urbanisme, mod

1
Urbanisme, modélisation, UML

• ENSG
• 18 septembre 2006

2
I Urbaniser un SI
3
Un cas lANPE

• Volumétrie
• 20 000 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
• S_at_D 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

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
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
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
Processus
17
Activité
Organisation
Écouter Comprendre Expliquer Concevoir Décider
Communication interpersonnelle
EHO
IHM
Classer Trier Calculer Traiter
APU
Plate-forme
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

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