Urbanisme, modélisation, UML

ENSG18 septembre 2006

I – Urbaniser un SI

Un cas : l’ANPE• 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 : l’intermédiation du marché de l’emploi– Stocker des offres et des demandes, trouver des rapprochements– Deux clients : l’entreprise, l’actif (demandeur d’emploi le plus

souvent)

• Plusieurs grands projets– GEODE : intermédiation du marché de l’emploi (cœur de métier)– OASIS : gestion des ressources humaines– SIAD : système d’aide à la décision– S@D : services à distance (Internet et/ou téléphonie)– Informatique de communication

• Messagerie, agenda partagé, Intranet, workflows

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 d’information »• Appel d’offres, 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 d’action

Déroulement

• Organisation des travaux– Une responsabilité bi-céphale

• Direction de l’architecture de la DSI• Coordination des maîtrises d’ouvrage

– Dans chaque métier, un maître d’ouvrage délégué– Un comité de pilotage mensuel

• Difficultés– Une logistique compliquée

• Recueil d’expertise• Rédaction, circulation et recueil des remarques• Validation des documents• Communication, appropriation…

– D’épais dossiers à la lecture laborieuse• Besoin d’une présentation figurée, imagée

Le schéma d’urbanisme

• Une cartographie qui se détaille par zooms successifs :

Entreprise

Domaine Processus Activité Composant Donnée

Le schéma d’urbanisme

• Les commentaires précisent le contenu et expliquent les choix de priorités

• La vue d’ensemble montre la solidarité des divers domaines• Mise en évidence des questions d’architecture

– 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 l’informatique de communication

• Un langage de modélisation– Utiliser UML sous une forme propre à la communication

(diagramme d’activité)

Présenter un modèle à la validation

Validations techniques

Validation intermédiaire

Validation stratégique

Modèleformalisé

Modèle« en français »

L’appropriation du schéma d’urbanisme

• Une très grande difficulté !– Il est difficile de faire s’approprier le schéma d’urbanisme par l’entreprise

• Les documents consignent le résultat d’un travail technique– Ils sont longs– Ils ne se prêtent pas à la lecture– Il est difficile d’obtenir 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 l’informatique (quelques centaines), soit au total 2 % de l’entreprise

• Buts – Percevoir les implications pratiques du système d’information par delà

son apparente abstraction– En tirer les conséquences en termes d’organisation (travail coopératif,

application de nouvelles normes)

Couches de la plate-forme informatique

Applications métiers

Infrastructure applicative

Infrastructure de communication

Génie logiciel

Infrastructure de base

Équipement physique et OS Infr

astr

uctu

re d

’adm

inis

trat

ion

Urbanisme fonctionnel et urbanisme technique

Axe du temps

Urbanisme fonctionnel

Urbanisme technique

Axe du temps

Urbanisme fonctionnel

Urbanisme technique

Mise en discussion de questions stratégiques

• L’Agence doit-elle ou non offrir des services marchands ?– Exemple : « recrutement par habileté ». Évaluer les prestations,

facturer, encaisser, comptabiliser

• Faut-il enrichir l’intermédiation du marché de l’emploi en prenant en compte l’offre de formation ?

– L’intermédiation passe de deux à trois pôles : complexité multipliée par trois

• Faut-il articuler le système d’information avec les services rendus sur l’Intranet?

– 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 d’une CRM, intégration de services multicanaux

• Comment doit évoluer la relation avec les partenaires ?– Interopérabilité des systèmes d’information

Principaux obstacles à l’urbanisation

• Sociologiques– Refus de l’explicitation – Refus de la logique– Compromis managérial

• Intellectuels– Refus de la pratique de l’abstraction– Méconnaissance des techniques et apports de la modélisation– Défaut d’expertise en statistique

• Difficulté à définir les indicateurs– Difficulté à penser l’articulation entre l’être humain et

l’automate• Philosophiques

– Difficulté à penser en termes de processus• La pensée grecque porte sur des concepts pérennes…• Refus de l’articulation entre la pensée et l’action

Que signifie « modéliser » ?

• Qu’est-ce qu’un modèle ?– représentation explicite d’un être réel permettant de

simuler mentalement son fonctionnement – théorie orientée vers l’action– 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 l’entreprise exigent des modèles explicites– Un modèle explicite est pratique, mais difficile à

comprendre

« Modéliser » l’entreprise

• Principe de la modélisation– Documenter les tâches réalisées dans l’entreprise, tant par l’être

humain que par l’informatique. • 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 d’intégrité, cycle de vie des objets

Plate-formedu SI

Événement déclencheur

Événement réponse

Activité

Indicateurset bouclage

Communicationinterpersonnelle

Processus

Activité

IHM

CommunicationinterpersonnelleEHO

APU

Organisation

Plate-forme

ÉcouterComprendreExpliquerConcevoirDécider

ClasserTrierCalculerTraiter

II – Modéliser un processus

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

l’entreprise– Compenser l’autisme 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 l’entreprise

Pourquoi modélise-t-on ?

• Certaines entreprises ne veulent pas modéliser…– Elles croient inutile de comprendre comment elles font

ce qu’elles savent faire– Un modèle explicite dérouterait des salariés formés aux

habitudes maison

• … d’autres, de plus en plus nombreuses, sont contraintes modéliser– Évolutivité : l’entreprise 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

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 d’information géographique• Deux écueils

– Exagérer le formalisme d’un langage de modélisation interdirait toute compréhension à certains acteurs

– L’absence d’une méthode de représentation empêcherait la collecte et la synthèse de l’information

Des vues autour du modèle formel

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 d’activité– Texte en langage naturel

• Pour les utilisateurs : faciliter l’appropriation– Présentation sur l’Intranet– Outil de contrôle personnel des connaissances

Une démarche méthodique

Les phases amont du développement

• Les acteurs (décisionnaires, utilisateurs, MOA) bâtissent l’objectif 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

Comment modéliser ?

• Langage UML et outils de cohérence– La méthode qui convient pour mettre en œuvre UML n’est 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 d’une

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 d’attaquer la suivante

– S’assurer de l’authenticité des validations– S’il faut corriger, modifier en amont et boucler vers l’aval

• Le modèle métier peut être remis partiellement en question par la prise en compte des contraintes et ressources de la plate-forme

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 d’information » d’UML 2.0

• Phase 2 :– Modélisation des processus

• Diagramme d’activité– 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 d’utilisation

• 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

Approche systémique : le « flot d’information »

Modélisation du processus

Cas d’utilisation

« 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 ressourcesde la plate-forme

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 l’EHO et de l’APU• L’informatique 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 n’excèdera pas 10 à 20 %

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