View
104
Download
0
Category
Preview:
Citation preview
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.
Recommended