Urbanisme, modélisation, UML

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

2. I – Urbaniser un SI

3. 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

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

5. 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

6. Entreprise Domaine Processus Activité Composant Donnée Le schéma d’urbanisme • Une cartographie qui se détaille par zooms successifs :

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

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

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

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

11. Urbanisme fonctionnel et urbanisme technique

12. 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

13. 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

14. 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

15. « 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

16. Activité Plate-forme du SI Événement déclencheur Événement réponse Indicateurs et bouclage Communication interpersonnelle 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 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

20. 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

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

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 d’activité • Texte en langage naturel • Pour les utilisateurs : faciliter l’appropriation • Présentation sur l’Intranet • 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 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

26. 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

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

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

29. Modélisation du processus

30. Cas d’utilisation

31. Responsabilité de la MOE Responsabilité de la MOA Modèle métier Contraintes et ressources de la plate-forme Modèle complet Responsabilité conjointe « 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 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 %

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