Travaux Dirig

1
Travaux Dirigésd'Urbanisation de Système
d'information

• Exemple de démarche

2
Introduction

• Master 1 Miage, Année 2009-2010
• Référentiel de Travaux Dirigés
• d'Urbanisation de système d'informations
• Projet d'un système urbanisé d'informations
• Contexte
• L'entreprise pour laquelle nous décrivons
  ci-après les principes de son système
  d'information se destine à la création de
  matériels de diagnostic médical qu'elle projette
  de mettre à disposition comme un service suivi
  auprès de personnels médicaux qualifiés.
• De par la nature même de leur objet, les enjeux
  de l'entreprise exigent une excellente
  traçabilité des informations qu'elle traite.
  Cette exigence conduit à apporter le plus grand
  soin à la formalisation de son système
  d'information, dès la conception de l'entreprise.
• Nous sommes en effet convaincus que de la
  confiance que l'on peut prêter aux activités de
  l'entreprise dépend celle de ses investisseurs.
• Ce système d'information nécessite donc d'être
  décrit comme une représentation de l'entreprise
  elle-même, de son organisation et de ses
  activités il en est le système nerveux.
• La suite du document décrit les principes de ce
  système d'information au travers d'un méta-modèle
  sémantique dont la construction est justifiée au
  fur et à mesure de sa description via une
  expression informatique formelle, et des exemples
  d'application pratique de ce méta-modèle sur des
  entités de l'entreprise.

3
Conscience d'une utopie

• La démarche qui suit décrit une sorte d'idéal, où
  tout ce qui régit le fonctionnement de
  l'entreprise est décrit et associé. À l'évidence
  il n'existe pas d'entreprise où tout soit
  auto-formalisé de cette façon. Entre les deux
  extrêmes de la vision de la ville, elle tend vers
  celle d'un peintre italien

4
Conscience de réalités

• Bâtir le modèle formel d'information est un
  chantier de longue haleine. S'il est plus facile
  de commencer ce chantier à la création d'une
  entreprise, il est rare que cela soit une
  priorité de ses fondateurs. Quoiqu'il en soit, ce
  modèle ne se réussit pas d'un coup. Il se
  complète et s'aménage constamment selon les
  nécessités d'évolutions, et selon la
  compréhension de ses utilités.
• Pour cela, si l'on se réfèrera aux meilleures
  pratiques en cours que l'on peut observer, on
  évitera toute adoption d'un métamodèle figé sur
  ces pratiques. La description des modèles de
  l'entreprise intègre donc la description
  évolutive de son propre métamodèle.

5
Bootstrap

• Tout système d'information d'entreprise fait
  appel à des systèmes informatiques, associant
  entre elles des applications de logiciels.
• À l'expérience, les étapes du cycle de vie de la
  plupart des matériels et des logiciels est court
  il est en particulier plus court que celles que
  l'on destine à notre entreprise elle-même. À
  l'évidence pour leur survivre, l'entreprise doit
  s'en défier, et éliminer toute dépendance vitale
  par rapport à elles.
• Il est heureusement des entités de ce domaine des
  technologies de l'information dont la pérennité
  justifie d'être considérée. Ce sont des standards
  de langages, ce sont quelques logiciels dont le
  succès d'usage a assuré la longévité. Ce sont des
  entreprises qui ont réussi à développer des
  services utiles avec ces technologies logicielles
  et les matériels qui les supportent.
• Hélas rien ne peut garantir la compatibilité
  entre les intérêts de ces entreprises avec la
  notre. L'alignement des champs d'intérêt ne peut
  s'obtenir qu'en s'acquittant de coûts qui peuvent
  devenir prohibitifs. Dans ce domaine, les
  fusions-acquisitions d'entreprises du domaine des
  technologies de l'information créent des risques
  de coûts infinis.
• La première règle stratégique de l'entreprise en
  matière de Système d'Information est donc de
  protéger l'expression de ses informations contre
  tout fournisseur de logiciel en s'imposant des
  modalités d'expression indépendantes dans des
  langages normalisés pérennes.
• Sa propre description est à la racine d'un
  système d'information, ce qui implique de lui
  appliquer cette première règle
• L'expression de la description d'un système
  d'informations ne doit pas dépendre d'un modèle
  spécifique à un progiciel commercial.

6
La question du choix d'un langage de description

• L'expression de la description du système
  d'information que nous entreprenons ici, doit
  être formelle pour être à la fois exploitable par
  une machine et compréhensible par un être humain.
• Elle doit donc utiliser un langage informatique
  d'expression de données, et d'expression
  nécessaire et suffisante de leur signification,
  de sorte que ces données soient à la fois
  compréhensible sans hiatus ni ambiguïté par un
  humain et puisse faire l'objet de raisonnements
  logiques effectués aussi bien par un humain que
  par un programme informatique.
• Pour exprimer ainsi une essence des choses, la
  philosophie définit à sa racine la notion
  d'ontologie, comme un "bootstrap" de la
  compréhension des choses. Étant elle-même une
  "chose" l'ontologie se comprend elle-même. Les
  technologies de l'information ont donné des
  expressions formelles exploitables par des
  machines
• La description d'un Système d'Information est à
  la racine de celui-ci elle en est le
  "bootstrap" de sa propre compréhension, tout en
  étant un élément de ce système d'information.
  Notre objet étant ici d'exprimer et de pouvoir
  faire évoluer à la fois le contenu de la
  description du système d'information et les
  moyens sémantiques explicites de sa
  compréhension, cette expression nécessite l'usage
  d'un tel langage d'ontologie formelle, normalisé
  pour être indépendant des outils commerciaux ou
  non de traitement, et largement partagé pour être
  pérennisé.
• En l'occurrence le choix se porte donc sur le
  langage d'ontologie standardisé le plus pratiqué
  qu'est la modalité OWL du méta-langage XML.

7
Démarche de Description

• Pour chaque sujet ou objet de l'entreprise, la
  démarche consiste à en formaliser la notion via
  une terminologie non ambiguë pour ses usages dans
  l'entreprise, afin de pouvoir en insérer la
  description dans leurs catégories et leurs liens
  potentiels.
• La démarche commence donc par la définition du
  champ lexical des termes métier qui sont utilisés
  au sein du système d'information de l'entreprise.
• Les Termes sont donc eux-mêmes une catégorie
  d'objet métier de l'entreprise, avec autant de
  sous-catégories que de langues pratiquées. Leurs
  liens rhétoriques usuels entre termes sont
  formalisés, tels que synonymie, antonymie,
  homonymie etc.

8
Effet stratégique

• La formalisation du système d'information de
  l'entreprise commence par l'enregistrement de sa
  raison sociale, autour de laquelle s'articule la
  stratégie de l'entreprise.
• La raison sociale établit le principal objectif
  recherché, "effet" attendu de l'entreprise.
• En l'occurrence il s'agit ici de mettre sur le
  marché ses propres appareils de diagnostic
  médical.
• De cet effet attendu résulte un jeu d'exigences,
  fonctionnelles ou non, logiques ou analogiques,
  portant sur les produits de l'entreprise au
  travers de ses caractéristiques..

9
Formalisation de stratégie

• En anticipant l'analyse rationnelle des démarches
  stratégiques de l'entreprise, on formalise ses
  éléments selon la méthode et les diagrammes
  d'analyse des causes et des effets définis par
  Kaoru Ishikawa
• la formalisation de la stratégie viendra peupler
  les différentes catégories de causes nécessaires
  et suffisantes à l'effet recherché.
• Chacune de ces différentes causes peuvent être
  récursivement des effets d'autres causes.
• Chaque cause entraine un jeu d'exigences.
• Comme tout objet métier les jeux de causes et
  d'effets évoluent dans le temps selon les
  circonstances et le développement de
  l'entreprise, avec leur propre cycle de vie.

10
Formalisation de raisonnement décisionnel

• Les objectifs stratégiques relèvent de processus
  décisionnels dont les arguments se doivent d'être
  pesés, pour qu'une décision soit justifiés. Entre
  nombreux travaux sur la notion de "Rationale" le
  MIT a défini un langage de description DRL qui
  peut être transcrit en ontologie.

11
Exigences

• La définition des produits et/ou des services que
  se propose d'offrir une entreprise commence par
  la description -ici formelle - des exigences
  auxquelles doivent répondre ces produits et
  services, issues des objectifs stratégiques que
  l'on s'est donné. Ces exigences contraignent des
  caractéristiques des produits et services. Elles
  peuvent être de type analogique, imposant des
  domaines de valeurs, ou qualitatives imposant un
  fait.

12
Analyse fonctionnelle des produits de l'entreprise

• L'analyse fonctionnelle décompose les produits et
  services de l'entreprise en éléments étudiés et
  réalisés via des processus séparés avant d'être
  assemblés.

13
Description des Processus

• Une des formes de description des processus se
  dessinent comme des "chaînes de valeur" de
  Michael Porter ,
• Ainsi les éléments formellement représentés au
  bas du diagramme précédent prennent la forme
  suivante, pour un état provisoire (à compléter)
  de formalisation processus principal de création
  d'un appareil

14
Chaîne de Valeur (1)?

• Chaque processus étant composite, la
  formalisation est fractale, ainsi se formalise le
  processus de création de la coque de carrosserie
  de l'appareil de diagnostic

15
Chaîne de Valeur (2)?

• Exemple d'expression en chaîne de valeur le
  processus de production de la carte mère de notre
  appareil de diagnostic

16
Processus et Procédures

• Les Processus se décomposent en procédures,
  décrivant le détail des conditions d'exercice
  synchronisé de chaque activité humaine, assistée
  ou non de moyens d'outils matériels et logiciels.
• Le diagramme ci dessous en montre le méta-modèle
  d'une expression formelle, et une de ses
  instanciations

17
Transposition d'un l'exemple de procédure,
exprimée en notation BPMN

• Notre Méta-modèle est une expression formelle des
  notions du langage d'expression graphique
  Business Process Model Notation, comme
  l'illustre l'expression graphique issue de
  l'exemple précédent.

18
Transposition d'un l'exemple de procédure,
exprimée en notation BPMN (suite)?

• Suite et fin de l'exemple d'expression graphique
  de la procédure précédente

19
Rationalisation de produits Catalogues et
Spécifications

• La rationalisation de la production implique la
  constitution de catalogues et de spécifications
  de choix, portant sur les caractéristiques des
  composants à choisir par exemple ici
  l'illustration du choix de la batterie de
  l'appareil de diagnostic

20
Diversité des métiers

• Chaque phase des processus qui accompagnent un
  produit ou un service traite différents sujets de
  préoccupations. Chacun d'eux prend en charge un
  jeu d'exigences, à chacun correspondant une
  qualification métier. La traitement de chaque
  sujet de préoccupation fait aussi appel à des
  outils, moyens matériels ou applications
  logicielles. Ces outils sont éligibles des mêmes
  conditions de formalisation de leurs
  caractéristiques et des exigences qui s'y
  attachent.

21
Concrétisation des produits

• Aux étapes de cycle de vie d'étude, au cours
  desquelles un produit n'existe qu'en instance,
  suivent les étapes au cours desquelles le produit
  est concrétisé. Le méta-modèle d'entreprise
  sépare les notions de produits en instance et
  concrets. Si ceux-ci ont aussi des étapes de
  cycle de vie, ils ont des caractéristiques
  contextuelles essentielles pour être tracés
  leur propriétaire et leur emplacement.

22
Exemple de lien de traçabilité

• L'exemple ci-après montre les principes de liens
  de traçabilité des produits réalisés

23
À chaque sujet de préoccupation, ses
représentations

• Tout sujet de préoccupation privilégie une vue
  d'un produit ou un service, ne comprenant que les
  caractéristiques concernées par les exigences que
  ce sujet traite, ce qui se formalise ainsi

24
Applications logicielles principe de délégation

• De la décomposition en processus métier découle
  la nécessité de délégation de responsabilités aux
  métiers qui en ont la charge, dotés de leur
  propres outils. Chacun de ces outils reprend à
  son compte une partie du modèle de gestion des
  objets métiers défini par l'ontologie, auquel il
  ajoute ses extensions spécifiques, qui n'ont pas
  lieu d'avoir une gestion détaillée partagée, et
  qui ne se manifesteront que dans les contenus des
  documents que chaque métier produit.
• À défaut de pouvoir être tenu de respecter le
  modèle général, ce que produit chaque application
  nécessite de pouvoir être traduit selon ce modèle
  commun.
• Pour synchroniser les travaux réalisés sur des
  applications métiers, il est nécessaire de doter
  le système d'information d'applications partagées
  de gestion des activités et des données qu'elles
  produisent.
• Sans préjuger des logiciels qui les implémentent,
  quatre grandes fonctions doivent être ainsi
  traitées
• Le monitorat des activités et des évolutions de
  données,
• La base des données partagées, entrepôt de
  données décisionnelle,
• Le gestionnaire des catalogues de composants
  réutilisables et de leur règles de choix,
• Et enfin la gestion de la description du système
  d'information lui-même.

25
Application Moniteur des données et activités

• Le moniteur enregistre et synchronise les données
  et les activités il contrôle l'exécution des
  procédures, et leur fait appliquer une procédure
  éditoriale générique pour tracer la qualité des
  données.

26
Application de Gestion des catalogues

• L'application de gestion des catralogues a la
  délégation de l'enregistrement des données des
  composants réutilisables et de leurs
  spécifications de choix

27
Application d'entrepôts de données

• Les données partagées entre applications sont
  stockées dans des entrepôts de données, à partir
  desquels fonctionnent les applications
  décisionelles.

28
Application d'auto gestion du Système
d'Information

• L'application de gestion de la description du
  système d'information gère les évolutions de
  chacun des éléments du SI, selon les étapes de
  son propre cycle de vie.
• Elle formalise les mutations de l'ADN de
  l'entreprise.

29
Formalisation du domaine des applications
logicielles
30
Organisation des flux dans l'entreprise

• Dans l'entreprise, l'organisation reflète les
  principaux processus, que chaque subdivision
  prend en charge en recrutant et regroupant les
  compétences nécessaires aux traitements des
  sujets de préoccupation correspondants.
  L'optimisation de l'organisation implique
  d'appréhender les flux d'objets métiers entre les
  subdivisions de l'organisation, au moyen de
  "diagrammes d'entreprise".

31
Organigramme motivé

• La façon ordinaire de représenter l'organisation
  de l'entreprise est un organigramme de délégation
  de responsabilités à des subdivisions.
  L'existence même de ces subdivisions se justifie
  par les objectifs stratégiques et les processus
  qu'elles prennent en charge.
• Le diagramme ci dessous est un organigramme
  "motivé", par sa "décoration" avec des liens
  vers la description des objectifs et processus
  assignés à chacun.

32
Les sujets de préoccupation du DSI les
applications logicielles

• Au sein de l'organisation, le responsable du
  système d'information a la charge de la cohérence
  et du bon fonctionnement des systèmes
  d'applications informatiques au service du
  système d'information.
• Cette démarche commence par l'établissement des
  cartes de correspondance entre les activités
  définies par les procédures de l'entreprise, et
  les applications qui les traitent.

33
Les sujets de préoccupation du DSI les
solutions progicielles

• Chaque application logicielle est tributaire ou
  non d'une solution progicielle, que l'entreprise
  choisit selon un cadre de cohérence, destiné à
  mutualiser les ressources et à favoriser
  l'intéropérabilité entre les applications. Pour
  maîtriser ce sujet de préoccupation il est
  nécessaire d'établir des cartographies des
  dépendances entre produits logiciels utilisés,
  depuis chaque application jusqu'au système
  d'exploitation mis en oeuvre.

34
Les sujets de préoccupation du DSI les réseaux
de solutions matérielles

• La cartographie des infrastructures informatiques
  illustre les moyens de communication mis en place
  entre les matériels informatiques qui supportent
  les applications. Les informations associées sur
  les flux d'informations échangés y sont
  nécessaires pour spécifier le dimensionnement des
  infrastructures de communications et de stockage.
• L'analyse des cartes d'infrastructure est aussi
  nécessaire pour évaluer les risques de pannes et
  ainsi les réorganiser pour maintenir le service
  rendu en cas de simple, double, voire triple
  défaillance....

35
À suivre...
36
À suivre...
37
À suivre...
38
À suivre...
39
À suivre...