Création de la base du SI Idée de départ : créer plusieurs couches de données avec chacune un intérêt propre et indépendante. Chaque couche doit pouvoir.

Présentation au sujet: "Création de la base du SI Idée de départ : créer plusieurs couches de données avec chacune un intérêt propre et indépendante. Chaque couche doit pouvoir."— Transcription de la présentation:

1 Création de la base du SI Idée de départ : créer plusieurs couches de données avec chacune un intérêt propre et indépendante. Chaque couche doit pouvoir fonctionner à partir de la couche précédente ou la couche minimale. But de cette réunion : déterminer les liens entre les différents services concernés et envisager les fonctionnalités utiles pour ces services. Également, déterminer les différentes données déjà existantes ainsi que leur type daccès.

2 Plan de la présentation 1. Blocs / Entités fonctionelles 2. Flux 3. Schéma dinteraction 4. « Problèmes » 5. Historique 6. Interfaces 7. Généricité

3 Intérêt : - Meilleur séparation des données - Capacité à fonctionner de manière autonome ou en relation avec dautres blocs. - Information minimum avec détails par source externe - Robustes aux modifications de leur environnement On distingue 4 grands blocs fonctionnels : 1.Le bloc des adresses 2.Les appels doffres et les projets 3.Le bloc contrats et finances 4.Les résultats de projets et les dépôts divers 1. Les blocs fonctionnels (données et traitements)

4 Les adresses Fonction primaire de la base Inclut la gestion des individus et des organismes Introduction de la notion de site Gestion des individus par leur fonction INDIVIDUS ORGANISMES SITES FONCTIONS Un individu a une fonction au sein dun organisme et lexerce sur un site précis

5 Appels doffres et projets Regroupe les appels doffres, soumissions et projets (entité) Ne contient pas forcément la partie contractuelle des projets (plutôt bloc des contrats) Liste les individus travaillant sur un même projet (lien avec le bloc précédent) Lien éventuel appels doffres - organisme émetteur APPELS DOFFRESSOUMISSIONSPROJETS PARTICIPANTS

6 Les contrats Entité principale pour le RIV En relation éventuelle avec tous les autres blocs Doit permettre laccès à toute linformation nécessaire Peut inclure une partie financière pour la gestion des recettes ou du marché public Peuvent avoir plusieurs formes : Financement, collaboration, licence, … CONTRATS SIGNATAIRESRECETTES

7 Résultats et dépôts Contient les productions écrites émanant des projets (publications, articles, compte-rendus, …) Regroupe également les logiciels ou brevets déposés (source indifférente) Peut contenir également les noms de domaines, etc … LOGICIELSBREVETSRESULTATS PROJETS AUTRE DEVELOPPEURS

8 Extension des blocs Facilité dajout de tables supplémentaires. Exemples : Gestion des événements (et leur organisation) Groupes dindividus et dorganismes Hiérarchie entre individus Suivi des négociations dun contrat Historique (spécial) Interfaces génériques (sur-couche)

9 Utilisation de linformation existante Lien vers les systèmes existants Accès à des informations plus précises Récupération de linformation existante Problème : déterminer les informations existantes et analyser leur caractéristiques daccès

10 ADRESSES CONTRATS APPELS DOFFRES DEPOTS BDU GIRHAF? ? Flux et récupération de linformation HISTORIQUE + HAL?

11 ADRESSES Représentation des différentes entités

12 ADRESSESCONTRATS Représentation des différentes entités

13 ADRESSESCONTRATS PROJETS APPELS DOFFRES SOUMISSIONS Représentation des différentes entités

14 ADRESSESCONTRATS RESULTATS PROJETS APPELS DOFFRES SOUMISSIONS DEPOTSDEPOTS Représentation des différentes entités

15 ADRESSESCONTRATS RESULTATS PROJETS APPELS DOFFRES SOUMISSIONS DEPOTSDEPOTS MARQUES NEGOCIATIONSNEGOCIATIONS Représentation des différentes entités

16 ADRESSESCONTRATS RESULTATS PROJETS APPELS DOFFRES SOUMISSIONS DEPOTSDEPOTS MARQUES NEGOCIATIONSNEGOCIATIONS Représentation des différentes entités EVENEMENTSEVENEMENTS

17 ADRESSESCONTRATS RESULTATS PROJETS APPELS DOFFRES SOUMISSIONS DEPOTSDEPOTS MARQUES NEGOCIATIONSNEGOCIATIONS Représentation des différentes entités HIERARCHIE GROUPES EVENEMENTSEVENEMENTS

18 ADRESSESCONTRATS Marché public RECETTES RESULTATS PROJETS APPELS DOFFRES HISTORIQUE SOUMISSIONS DEPOTSDEPOTS MARQUES NEGOCIATIONSNEGOCIATIONS Représentation des différentes entités HIERARCHIE GROUPES EVENEMENTSEVENEMENTS

19 ADRESSESCONTRATS Marché public RECETTES RESULTATS PROJETS APPELS DOFFRES HIERARCHIE HISTORIQUE SOUMISSIONS DEPOTSDEPOTS MARQUES GROUPES NEGOCIATIONSNEGOCIATIONS Représentation des différentes entités EVENEMENTSEVENEMENTS

20 SCHEMA

21 Chaque service est concerné par une partie différente de linformation. Dune manière simple, on peut déterminer les blocs concernant chaque service : SAF : Contrats, Recettes, … SRH : Adresses (Individus/Fonctions) COM : Événements, Résultats, Dépôts … DOC : Résultats (Publications, Articles, …) Il est également envisageable de créer une ou plusieurs tables pouvant sajouter aux précédentes dans le but de couvrir une fonctionnalité souhaitée en relation avec lexistant.

22 « Problèmes » à résoudre Conserver une bonne autonomie et un certain degré de robustesse en cas de coupure de lien avec les sources de données externes. Déterminer un système darchivage et de manipulation des données volatiles facile à gérer et proposant un système daccès à ces données pas trop lourd en terme de requêtes. Créer un système dinterfaces conviviales le plus générique possible avec une facilité de maintien.

23 Lhistorique Partie la plus lourde de la base ; doit posséder 2 avantages : - fiabilité darchivage des données - facilité daccès à ces données. Plusieurs solutions possibles : - création de tables darchivages relativement similaires aux tables dorigine (bonne dissociation des données mais accès alourdi) - conservation des informations dans les tables existantes (facilité daccès, augmentation de la taille des tables) Fonctionnalité envisagée : Être capable de se replacer dans un contexte complet à un moment donné.

24 Convivialité et ergonomie (indépendant de la fonctionnalité attendue) Facilité de maintien et dévolution Générique (le plus possible) : création dune série de tables contenant les informations de création de linterface. Les contrôles utilisés pour afficher ou éditer les champs seront stockés dans dautres tables associés aux champs de chaque tables de données. Les interfaces

25 Exemples dinterfaces Ce type dinterface demande généralement un temps de développement court mais propose une flexibilité réduite ainsi quune difficulté dévolution évidente. De plus, ce type dinterface ne peut que rarement être adapté à un autre type dinformations.

26 Exemples dinterfaces Edition dOrganisme Contrairement à la forme précédente, ce type dinterface permet lédition de nimporte quel type de structure de données.