Université Paris Nord 3 avril 2002

Présentation au sujet: "Université Paris Nord 3 avril 2002"— Transcription de la présentation:

1 Université Paris Nord 3 avril 2002
Maîtrise d’ouvrage et maîtrise d’œuvre dans la conduite des projets informatiques Université Paris Nord 3 avril 2002

2 Points de repère Maîtrise d’ouvrage, maîtrise d’œuvre
« ouvrage » et « œuvre » Client et fournisseur Organisation de la maîtrise d’ouvrage MOAS, MOAD, MOAO, AMO, utilisateur Organisation de la maîtrise d’œuvre DIT, direction des études, responsable de domaine, CP MOE, entreprises. Une organisation ancienne et universelle Elle remonte à l’ancienne Egypte Elle n’est pas « franco-française » (« Business Technologists » aux Etats-Unis)

3 Maîtrise d ’ouvrage : une histoire millénaire !
MOE MOA MOAS CP - MOE MOAD MOAO Utilisateurs Entreprises

4 Missions de la maîtrise d’ouvrage
Assurer la pertinence du SI en regard des priorités du métier, de la « stratégie » Suivi et contrôle de la mise en œuvre du SI Spécification fonctionnelle des évolutions et suivi des projets Déploiement et formation des utilisateurs

5 Missions de la maîtrise d’œuvre
Assurer l’exploitation de la plate-forme informatique Performance, disponibilité, support aux utilisateurs Assurer l’évolution du SI Qualité des développements, recette, mise en exploitation

6 Etapes d’un projet Expression de besoin Etude OFR (ou étude préalable)
Fiche de synthèse de mission Contrat client-fournisseur, répartition des rôles à la DIT Spécification Générale, détaillée, technique Conduite de projet Reporting : avancement des travaux, consommation du budget Recettes Technique, fonctionnelle

7 Spécifications Spécifications générales (modèle métier)
Responsable : MOA Spécifications détaillées (modèle d’analyse) Responsable : MOE, validée par MOA Spécifications techniques (modèle technique) Responsable : MOE

8 Maîtrise d’ouvrage Maîtrise d’oeuvre Modèle métier Modèle d’analyse Modèle technique Production Validation

9 Nouvelles relations entre maîtrise d’ouvrage et maîtrise d’œuvre
1

10 Débuts de l ’informatique
Utilisateurs Traitements Bases de données paie etc. client compta Années 60 : gros ordinateurs coûteux Automatisation des tâches administratives : paie, comptabilité, gestion des comptes clients (commandes, factures) « Applications » au coup par coup Des « bases de données » séparées Des « fusions de fichiers » difficiles

11 De l ’informatique au système d ’information
Nomenclatures différentes pour chaque applications synonymes, homonymes catalogues de produits différents selon l ’établissement exemple de Schlumberger croissance par acquisition : chaque nouvelle filiale arrive avec ses nomenclatures exemple de Pont-à-Mousson Qualité des identifiants identifiants mal conçus exemple : banques, France Télécom difficulté de l ’identification exemple du transport aérien Référentiel

12 RLPC et nouvelles technologies
Mainframe et terminaux Client-serveur Réseau de PC Workflow TCP/IP Documentation partagée Intranet Rédaction coopérative Hypertexte Forum Groupware Messagerie Bureautique communicante Une évolution parallèle : le RLPC Développement de la bureautique locale : traitement de texte, tableur, grapheur communicante : messagerie, agenda partagé évoluée : documentation électronique, workflow Un nouveau type d ’informatique ubiquité apportée par le réseau (RLPC, WAN) croisement des données et du commentaire Problèmes d ’organisation et d ’usage La messagerie : un nouveau savoir vivre pièges et bonnes pratiques le risque de l ’agressivité : exemple de Cisco La documentation électronique : Intranet, ou instaurer la transparence réticences à la transparence partage de la documentation technique et de l ’expertise gain d ’efficacité : exemple d ’Arthur Andersen suppression de l ’écart d ’information DG-DR un changement des relations dans l ’entreprise Agenda partagé Langages systèmes d’exploitation L4G Orienté-objet Datawarehouse Datamining SGBDR

13 Nouvelle approche du SI
Domaines de création de valeur ajoutée Processus de production Acteurs du processus (« use cases ») Composants Référentiels (identifiants, attributs) UML

14 Les données au centre du processus
Traitements Structuration des processus par le WF Des applications multiples traitement des réclamations des clients demandes de congé, de mutation animation et contrôle des procédures Clarté et confort des procédures routage pré-programmé, traçabilité, maîtrise des délais Des risques néo-taylorismes réorganisations brutales (suppression des niveaux hiérarchiques intermédiaires) difficulté à adopter le workflow Événement Activité Transfert Bouclage

15 Processus et sous-processus
Livrable

16 Evolution du SI Organisation Ancienne Nouvelle
Définition du SI Informatique Métiers Économie Centre Centre de l'informatique de coûts d'investissement Priorités Développement Service aux de l'informatique Exploitation utilisateurs Éléments du SI Applications Processus Objets

17 Evolution de l ’organisation
Contrôle A priori A posteriori Visibilité Opacité Transparence Circulation de Rétention Diffusion l'information Contrôle d'accès Equipement des Terminal passif PC en réseau utilisateurs Communication Téléphone les mêmes, plus : Télécopie Messagerie Réunion GED Workflow Forum

18 Nouveaux rôles L ’entreprise s ’organise autour des processus et des composants Les métiers modélisent leur système d ’information Le système d ’information s ’ajuste pour équiper les processus des métiers Émergence de la « maîtrise d ’ouvrage » Organisation et sémantique : des règles simples aux applications diversifiées Professionnalisation de la maîtrise d ’ouvrage et de l ’informatique

19 Nouveaux rôles Généralisation de l ’assisté par ordinateur
Articulation de l ’homme organisé et de l ’automate programmable Un nouveau professionnalisme de la MOA... Équiper la stratégie d ’entreprise Élucider les processus des métiers Veille SI … en relation avec celui de l ’informatique Solide plate-forme technique Maîtrise des coûts Veille techno : langages, middleware, solutions, Maîtrise des fournisseurs

20 Principes de la MOA Axes fondamentaux Méthodes Sobriété
Fermeté et disponibilité Esprit de coopération Méthodes Spécifications, validations, qualité de la validation EB, OFR, FSM, MCP, recettes, déploiement Composition du portefeuille SI 6

21 Problèmes essentiels Priorité : « domaines » ou « projets » ?
Frontière de l ’externalisation Maîtrise de la diversification des compétences techniques Vers un nouveau type d ’entreprise

22 Relation entre la maîtrise d’ouvrage et ses utilisateurs

23 Relation MOA - utilisateurs
2 utilisateurs : « terrain » et « concepteur » étapes de la relation : expression des besoins, recette fonctionnelle, formation, déploiement, conduite du changement, aide aux utilisateurs, exploitation technique de proximité Lorsque l ’on parle des « utilisateurs » du système d ’information, il faut distinguer deux catégories de personnes : les utilisateurs « de terrain », ceux qui en pratique feront fonctionner l ’application et s ’en serviront pour leur travail quotidien ; et les « concepteurs », généralement affectés à la direction générale, et qui sont chargés de concevoir les nouvelles applications en fonction des orientations stratégiques de métiers de l ’entreprise. Les concepteurs ne sont pas des utilisateurs finals, mais ce sont eux qui sont chargés de transcrire les besoins de l ’entreprise en termes de fonctionnalités qui seront fournies par l ’application. Les relations entre la maîtrise d ’ouvrage et les utilisateurs comportent plusieurs étapes, que nous pouvons parcourir dans l ’ordre chronologique : d ’abord l ’expression des besoins, puis la recette fonctionnelle qui permet aux utilisateurs de vérifier que l ’application correspond bien à leur demande, puis la formation des utilisateurs « de terrain », le déploiement, la conduite du changement, l ’aide aux utilisateurs, l ’exploitation technique de proximité. Nous considérerons dans cet exposé uniquement la première de ces étapes, l ’expression de besoins.

24 Étapes de l’expression des besoins
Expression informelle Validation par les responsables Formalisation du besoin Convergence MOA Convergence MOA-MOE L ’expression de besoins se fait selon plusieurs étapes : - une première expression, dite « informelle » pour la distinguer des expressions formalisées, est d ’abord nécessaire pour que l ’on puisse bien comprendre de quoi il s ’agit : bien qu ’informelle, elle doit être rigoureuse. Elle est exprimée en langage courant, et elle est compréhensible à la lecture par tout le monde, y compris par les dirigeants. - l ’expression informelle doit être validée par les dirigeants responsables, de sorte que l ’on soit certain qu ’elle correspond bien aux priorités et à la stratégie de l ’entreprise. Cette validation est indispensable, car sinon on court le risque d ’un désaveu après plusieurs mois de travail dans une direction erronée. - on établit ensuite une expression formalisée, selon un langage que nous allons décrire ci-dessous. La formalisation fait parfois apparaître des lacunes de l ’expression informelle, et il faut donc que l ’on parcoure des itérations jusqu ’à ce que l ’on dispose d ’une expression informelle et d ’une expression formelle cohérentes. - jusqu ’à présent, on en est resté à la maîtrise d ’ouvrage, responsable de l ’expression des besoins. Lorsque celle-ci est terminée, elle est communiquée à la maîtrise d ’œuvre et il faut s ’assurer que celle-ci la comprend bien. Un jeu de questions et réponses conduit à l ’expression des besoins finale, dûment comprise et validée par la maîtrise d ’œuvre.

25 Expression des besoins
Apports des experts terrain et concepteurs Logistique de la consultation talon d'Achille de la maîtrise d'ouvrage Clubs d'utilisateurs un piège : poussée inflationniste, manipulation par l'informatique, règle d'or : prioriser Pour rédiger l ’expression de besoins, il est utile de consulter les personnes du terrain et les concepteurs. Les informations qu ’apportent ces deux catégories d ’utilisateurs ne sont pas les mêmes : les personnes du terrain indiquent dans le détail comment les choses se passent, et permettent d ’éviter des erreurs de conception pratique. Les concepteurs indiquent comment les choses devraient se passer, ou comment elles doivent évoluer, et permettent d ’éviter les erreurs stratégiques. La consultation des experts, les entretiens, les séances de validation, la rédaction et la vérification des comptes rendus, représentent une tâche matérielle considérable. La logistique des recueils d ’expertise, consultations et validations est le talon d ’Achille de la maîtrise d ’ouvrage : une expression des besoins peut échouer, en qualité ou en délai, parce que cette logistique n ’a pas été bien organisée. On pense trop souvent que cela va marcher tout seul, et ce n ’est pas le cas. On utilise parfois des « clubs d ’utilisateurs » pour faire l ’expression des besoins. L ’expérience conduit à se méfier de ces formations, même si elles ont une allure sympathique et démocratique. En rassemblant les utilisateurs, on les pousse à exprimer une demande fonctionnelle inflationniste, chacun cherchant à demander quelque chose que les autres n ’ont pas pensé à demander. Il arrive souvent que les informaticiens manipulent les clubs d ’utilisateurs pour faire passer leurs propres préférences : comme les utilisateurs demandent tout et le reste, l ’informaticien peut choisir ce qui lui plaît. La règle d ’or pour amener un club d ’utilisateur à travailler raisonnablement, c ’est de lui demander d ’exprimer ses priorités, de dire ce qui lui paraît indispensable. On ne retiendra, pour faire la « version 1 », que l ’indispensable… et parfois il ne sera pas utile d ’aller plus loin par la suite.

26 Validation du besoin par les responsables
communication et pédagogie faire ressortir les implications politiques présenter les choix alternatifs obtenir une validation authentique se méfier des signatures trop rapides Il n ’est pas facile d ’obtenir de la part des dirigeants responsable une vraie validation, décidée en connaissance de cause. Si on leur communique un épais classeur rempli de documents techniques, ils ne pourront que le parcourir sans aller au fond des choses ; il valideront de confiance, quitte à s ’apercevoir quelques mois après que les décisions prises ne correspondaient pas à leurs priorités stratégiques. Il importe de présenter aux décideurs des documents sur lesquels il puissent faire porter leur jugement, et opérer une validation authentique qui ne sera pas remise en cause par la suite. Ceci demande de la part des techniciens un effort de clarté, de simplicité et de pédagogie. Les implications politiques éventuelles des choix techniques proposés doivent être mises en évidence, des choix alternatifs doivent être proposés, de façon que le dirigeant puisse faire son travail et contribuer vraiment aux spécifications. Les textes à leur présenter doivent être rédigés en français, illustrés par des graphiques clairs ; les compléments techniques éventuels sont à mettre dans des annexes qu ’ils ne consulteront que s ’ils veulent aller au détail.

27 Formalisation du besoin
vers la modélisation métier professionnalisation du maître d'ouvrage transcription de la stratégie de l'entreprise dans le système d'information Une fois l ’expression de besoin en français rédigée et validée, il est utile de la modéliser. On dispose maintenant, avec le langage UML (Unified modeling language) d  ’un langage de modélisation bien adapté. Il permet de préciser les besoins de façon à supprimer toute ambiguïté pour l ’entreprise qui sera par la suite chargée de la réalisation. Il utilise les concepts propres à l ’orienté objet (classes, composants, attributs, liens etc.) : proche de l ’utilisateur, dont il formalise la demande, il fournit à la réalisation une base conceptuelle qui sera réutilisée et précisée lors des étapes ultérieures, ce qui permet un gain de temps précieux. La maîtrise du langage de modélisation UML (ou de tout autre langage analogue dans le futur ; pour le moment, c ’est UML qui s ’impose) est une étape importante de la professionnalisation des maîtrises d ’ouvrage. Alors que les expression de besoins étaient auparavant souvent imprécises et versatiles, les maîtrises d ’œuvre vont désormais disposer de descriptions complètes, établies selon une procédure qui garantit leur pérennité. Le modèle devient le langage dans lequel le métier structure ses fondations conceptuelles. Il sert aussi (ou plutôt il servira, car nous sommes ici en avance par rapport à la pratique de la plupart des entreprises) à mettre en forme les choix stratégiques et à les expliciter. Dès lors le modèle est la transcription de la stratégie de l ’entreprise, dont il donne une description complète et précise, propre à la réalisation technique qui lui fait suite.

28 Modèle UML Présentation stratégique Présentation des processus
Explication de la modélisation Modèle formel Un modèle UML se compose de plusieurs documents en langage courant et d ’un document formalisé : il ne se limite en aucun cas au seul document formalisé, car celui-ci est pratiquement incompréhensible si on le présente seul, sauf peut-être pour des experts en UML, mais ces personnes sont rares. Le premier document est la présentation stratégique, expliquant pourquoi l ’entreprise a voulu se doter de l ’outil considéré, les buts qu ’elle cherche à atteindre, le calendrier de réalisation qu ’elle a prévu, etc. Le second document est une présentation des processus de travail par lesquels la stratégie doit se réaliser. Il doit être illustré par une présentation des écrans qui seront affichés devant les utilisateurs, de sorte que le lecteur puisse voir comment l ’application va fonctionner en pratique. Le troisième document est une explication des choix et des méthodes utilisés pour la modélisation formelle : il s ’agit de reproduire, pour le lecteur, les discussions qui ont présidé à ces choix. Le quatrième document est le modèle formel lui-même. Il comporte des diagrammes, des liens hypertextes permettant l ’ouverture de fenêtres de contenu textuel. Parmi les diagrammes, on doit présenter en premier le diagramme d ’activité, qui montre l ’enchaînement des « use cases » au sein du processus et qui est le plus immédiatement compréhensible ; puis le diagramme de séquence, qui montre l ’enchaînement des opérations à l ’intérieur d ’un « use case ». Enfin, le diagramme de classes, qui est le plus précis conceptuellement mais aussi le plus difficile à lire.

29 Convergence MOA En fait l ’élaboration du modèle, avec ses parties formelles et ses parties en langage naturel, se fait de façon itérative. On rédige d ’abord une première expression de besoins en langage naturel ; la modélisation formelle fait apparaître les ambiguïtés et incohérences inévitables dans une première rédaction : on les corrige, ce qui conduit à construire une deuxième version du modèle formel, etc. A la fin du processus, la maîtrise d ’ouvrage dispose d ’un modèle livrable à la maîtrise d ’œuvre, composé de ses deux parties (formelle et en langage naturel) dûment cohérentes. Avant d ’être livré, ce modèle doit être validé par les dirigeants responsables, qui liront surtout les documents en langage naturel. Cette élaboration demande une gestion documentaire attentive : il importe que les diverses versions des textes soient numérotées et leur cohérence vérifiée, de sorte que le destinataire n ’ait pas le souci de devoir vérifier la cohérence de ce qui lui est livré. Le livrable fourni par la maîtrise d ’ouvrage à la maîtrise d ’œuvre s ’appelle « modèle métier », « modèle fonctionnel » ou encore « spécifications générales », ces deux termes étant synonymes.

30 Convergence MOA-MOE Maîtrise d’ouvrage Maîtrise d’œuvre
Lorsque le modèle métier est fourni au maître d ’œuvre, celui-ci doit se l ’approprier et s ’assurer qu ’il l ’a bien compris. Il peut ainsi relever des points obscurs. On entre donc dans un cycle de remarques du maître d ’œuvre, auxquelles le maître d ’ouvrage répond en précisant ou modifiant le modèle. A la fin de ce cycle, on dispose d ’un modèle métier stabilisé, parfaitement compris par les deux parties, et qui va servir de fondation à la réalisation.

31 Suite de l ’histoire modèle métier -> modèle d ’analyse
(spécifications générales -> spécifications détaillées) modèle d ’analyse -> modèle technique (specs détaillées -> specs techniques) specs techniques -> développement etc. Il est important de bien voir la chaîne des démarches qui conduisent à la réalisation. Le vocabulaire comporte des synonymes, mais la démarche est claire : - le « modèle métier » (ou « spécifications générales ») est celui qui est livré par la maîtrise d ’ouvrage à la maîtrise d ’œuvre. - le « modèle d ’analyse » (ou « spécifications détaillées ») est rédigé par le maître d ’œuvre, et validé par le maître d ’ouvrage. Il a pour but d ’apporter au modèle métier des précisions de nature technique (cardinalité des liens, définition des classes etc.) afin de préparer une réalisation efficace. Il doit être validé par la maîtrise d ’ouvrage et devient ensuite le modèle sur lequel fournisseur et client se sont mis d ’accord, et qui servira de charte à la réalisation. - le « modèle technique » (ou « spécifications techniques ») est le document qui sera fourni aux développeurs pour la réalisation. Il fixe les choix techniques nécessaires. Il est interne à la réalisation, et n ’a pas à être validé par le maître d ’ouvrage. Pour comprendre cette succession, il est utile d ’utiliser une métaphore inspirée de la vie courante. Supposons que vous fassiez construire une maison. Vous avez le plan sous les yeux, et vous dites : « dans cette chambre, il faudra quatre prises de courant, un interrupteur commandant une prise, et une applique commandée par un interrupteur ». Ce sont vos spécifications générales. L ’électricien vous demandera de préciser l ’endroit où il faut installer les prises, les interrupteurs et l ’applique. Noter ces emplacements précis, c ’est les spécifications détaillées. Puis l ’électricien fera le plan de câblage, et déterminera le parcours des goulottes et saignées. Ce sont les spécifications techniques, qui ne vous intéressent pas (il vous demandera peut-être de donner votre accord avec l ’emplacement de l ’armoire de raccordement, où se trouveront les disjoncteurs). Toute réalisation doit parcourir ces trois étapes, et être conduite de telle sorte que l ’on ait pas lors d ’une étape à remettre en cause les choix opérés lors des étapes précédentes.

32 Site du club des maîtres d’ouvrage des systèmes d’information :
Pour en savoir plus Questions et réponses ! Sites web à utiliser : Site du club des maîtres d’ouvrage des systèmes d’information : Site personnel :