création de la base du si idée de départ : créer plusieurs couches de données avec chacune un...

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 d’accès.

Plan de la présentation

• 1. Blocs / Entités fonctionelles

• 2. Flux

• 3. Schéma d’interaction

• 4. « Problèmes »

• 5. Historique

• 6. Interfaces

• 7. Généricité

Intérêt : - Meilleur séparation des données

- Capacité à fonctionner de manière autonome ou en relation avec d’autres 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 d’offres 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)

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 d’un organisme et l’exerce

sur un site précis

Appels d’offres et projets• Regroupe les appels d’offres, 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 d’offres - organisme émetteur

APPELS D’OFFRES

SOUMISSIONS

PROJETS

PARTICIPANTS

Les contrats

• Entité principale pour le RIV

• En relation éventuelle avec tous les autres blocs

• Doit permettre l’accès à toute l’information 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

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 …

LOGICIELS

BREVETS RESULTATS PROJETS AUTRE

DEVELOPPEURS

Extension des blocs

Facilité d’ajout de tables supplémentaires. Exemples :

• Gestion des événements (et leur organisation)

• Groupes d’individus et d’organismes

• Hiérarchie entre individus

• Suivi des négociations d’un contrat

• Historique (spécial)

• Interfaces génériques (sur-couche)

• Utilisation de l’information existante

• Lien vers les systèmes existants

• Accès à des informations plus précises

Récupération de l’information existante

Problème : déterminer les informations existantes et analyser leur caractéristiques d’accès

ADRESSES

CONTRATS

APPELS D’OFFRES

DEPOTSBDU

GIRHAF?

?

Flux et récupération de l’information

HISTORIQUE+

HAL?

ADRESSES

Représentation des différentes entités

ADRESSESCONTRATS

Représentation des différentes entités

ADRESSESCONTRATS

PROJETS APPELS D’OFFRES

SOUMISSIONS

Représentation des différentes entités

ADRESSESCONTRATS

RESULTATSPROJETS APPELS

D’OFFRES

SOUMISSIONSDEPOTS

Représentation des différentes entités

ADRESSESCONTRATS

RESULTATSPROJETS APPELS

D’OFFRES

SOUMISSIONSDEPOTS

MARQUES

NEGOCIATIONS

Représentation des différentes entités

ADRESSESCONTRATS

RESULTATSPROJETS APPELS

D’OFFRES

SOUMISSIONSDEPOTS

MARQUES

NEGOCIATIONS

Représentation des différentes entités

EVENEMENTS

ADRESSESCONTRATS

RESULTATSPROJETS APPELS

D’OFFRES

SOUMISSIONSDEPOTS

MARQUES

NEGOCIATIONS

Représentation des différentes entités

HIERARCHIE GROUPES

EVENEMENTS

ADRESSESCONTRATS

Marché publicRECETTES

RESULTATSPROJETS APPELS

D’OFFRES

HISTORIQUE

SOUMISSIONSDEPOTS

MARQUES

NEGOCIATIONS

Représentation des différentes entités

HIERARCHIE GROUPES

EVENEMENTS

ADRESSESCONTRATS

Marché publicRECETTES

RESULTATSPROJETS APPELS

D’OFFRES

HIERARCHIE

HISTORIQUE

SOUMISSIONSDEPOTS

MARQUES

GROUPES

NEGOCIATIONS

Représentation des différentes entités

EVENEMENTS

SCHEMA

Chaque service est concerné par une partie différente de l’information. D’une 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 s’ajouter aux précédentes dans le but de couvrir une fonctionnalité souhaitée en relation avec l’existant.

« 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 d’archivage et de manipulation des données volatiles facile à gérer et proposant un système d’accès à ces données pas trop lourd en terme de requêtes.

• Créer un système d’interfaces conviviales le plus générique possible avec une facilité de maintien.

L’historique

Partie la plus lourde de la base ; doit posséder 2 avantages :

- fiabilité d’archivage des données

- facilité d’accès à ces données.

Plusieurs solutions possibles :

- création de tables d’archivages relativement similaires aux tables d’origine (bonne dissociation des données mais accès alourdi)

- conservation des informations dans les tables existantes (facilité d’accès, augmentation de la taille des tables)

Fonctionnalité envisagée : Être capable de se replacer dans un contexte complet à un moment donné.

• Convivialité et ergonomie (indépendant de la fonctionnalité attendue)

• Facilité de maintien et d’évolution

• Générique (le plus possible) : création d’une série de tables contenant les informations de création de l’interface. Les contrôles utilisés pour afficher ou éditer les champs seront stockés dans d’autres tables associés aux champs de chaque tables de données.

Les interfaces

Individu

Nom

Prenom

Date de naissance / /

Adresse

Rechercher

FonctionsEtablissement Fonction Bureau Adresse Telephone Responsable Date arrivee

Exemples d’interfaces

Ce type d’interface demande généralement un temps de développement court mais propose une flexibilité réduite ainsi qu’une difficulté d’évolution évidente. De plus, ce type d’interface ne peut que rarement être adapté à un autre type d’informations.

Organisme

Exemples d’interfaces

Nom Type Domaine Nombre employés Nombre sites Nom

Type

Domaine

Nombre employés

Nombre sites

Adresse principaleEmployés

Sites

Edition d’Organisme

Modifier SupprimerNouveau

Contrairement à la forme précédente, ce type d’interface permet l’édition de n’importe quel type de structure de données.