ETUDE DETAILLEE : spécifications externe et interne

La spécification externe (enchaînement des états et définition des informations de chaque état) est effectuée et validée par l'utilisateur avant la spécification interne ou la programmation, que ce soit dans le cas d'un site ou de plusieurs sites (de micro-informatique ou non).

4.1 Cas d'un seul site.

Le passage du modèle conceptuel de données au modèle physique est possible (MCD -> MPD). Construction MLD ou MPD Description des Etats (MLT) Modèles en Mise-à-jour

et consultation par outil + v alidation de la liste des outils = f in de

l'étude préalable

Programmation

4.2 Cas d'informatique multi-sites.

Les modèles logiques de données (livre des enregistrements et des chemins) sont construits pour chaque base de données.

Lancement Du Projet

Choix des éq uipes de spécification, de développement et de validation Construction MLD ou MPD Validation Modèles LD ou PD / outils Planning et Répartition des outils à spécifier

Lancement des études détaillées

Un Modèle Logique de Communication ou un schéma d'architecture de l'informatique existante et cible décrivant les messages échangés entre base de données et engendrés par tel outil est bienvenu. La liste des outils et un Modèle Logique de Données validé par les traitements (Modèles des outils) sont nécessaires pour la distribution des outils et attaquer la spécification.

Lancement des études

détaillées

Tests N f ois

Les tâches comprises entre le lancement des études détaillées et les tests sont à multiplier par le nombre d'équipes de spécification. Le Modèle Logique de Données n'est pas obligatoire pour la spécification externe. La difficulté des études détaillées tient à la charge de travail et à l'éclatement nécessaire du travail. La construction préalable du MLD évite toute dérive "personnalisée" par un analyste ou un programmeur audacieux.

Analy se des programmes par lot (dont

interf aces)

Déf inition des jeux d'essais

Actions de mise à jour par état sur le Modèle Logique de D onnées.

Obtention des inf ormations (Spécif ication interne) Enchaînement des

états et v alidation utilisateur (spécif ication externe) Lancement des études détaillées Programmation des outils traitement dif f éré Programmation des programmes transactionnels Tests Mise en production

5 REALISATION : le test de la méthode

Si la réalisation est bonne et l'utilisateur final enchanté du résultat, c'est sûrement grâce à la méthode. Sinon, c'est la faute de l'informatique. D'ailleurs, c'est souvent à ce moment qu'on se demande à quoi peut bien servir l'informatique.

6 LES POINTS FORTS DU PROJET.

Les équipes de conception, organisation et réalisation doivent être le plus "constantes" possible. Cela implique que les données et les traitements doivent être suivis par les mêmes personnes et que les responsables de l'organisation et de l'informatique soient les mêmes ou "chapeautés" par un même responsable des... systèmes d'information. Les gardiens de la méthode doivent participer aux études et ne pas se cantonner dans un service "méthodes".

Passer souvent sur les mêmes données et les mêmes opérations approfondit les problèmes et les solutions. Les individus tels que REGLE, SCENARIO, SIMULATION... apportent la valeur ajoutée et la durée de vie au résultat final. Ce point dépend fortement du premier.

Un utilisateur fortement sollicité par plusieurs personnes se réclamant d'une méthode n'apporte pas toute la concentration nécessaire. Il convient de choyer l'utilisateur final.

Il faut donc choisir des utilisateurs pouvant s'abstraire de l'existant en le simplifiant et en l'améliorant.

Attention à l'utilisateur seul et décidant pour ses "postes de travail" : les "postes de travail" se feront connaître un jour ou l'autre et auront sûrement un point de vue différent.

Et, bien sûr, ne jamais faire de projet sans avoir de contact suivi avec l'utilisateur : "Pas de conception en chambre".

CHAPITRE VII LA META-PHYSIQUE : maintenance, formation et documentation

Les oiseaux gazouillent, les fleurs

embaument.

(Expression chinoise)

Maintenance, documentation et formation permettent de faire face au départ classique du créateur du programme en temps différé datant des débuts de l'informatique et à remplacer par le nouvel embauché. Cette documentation doit porter au minimum sur les données. Certains logiciels de développement permettent une modification mémorisant automatiquement des renseignements sur les programmes et les bases de données.

1 UN DICTIONNAIRE DE DONNEES, SINON RIEN

La documentation est un domaine important et rarement traité. L'application d'une méthode telle que Merise facilite grandement cette tâche. Cette documentation obligatoire implique un certain travail.

Un dictionnaire de données d'entreprise, c'est-à-dire la liste des informations avec leur signification et dans quel enregistrement elles se trouvent est un atout considérable dans tout "système d'information" qui se respecte.

2 LA DOCUMENTATION AUTOMATIQUE EXISTE.

Certains logiciels comprennent une partie de documentation liée au physique ou au logique : quelles sont les données touchées par tel pro- gramme, pour connaître les programmes à modifier en cas de changement de données.

D'autres utilitaires de base de données facilitent la maintenance. Certains logiciels de SGBD proposent des dictionnaires d'enregistrements et des informations comprenant des explications : méta-dictionnaire de données incorporé (tables de tables en relationnel). L'adresse des programmes en bibliothèque peut être disponible automatiquement.

3 QUI DIRIGE QUI ? Le conceptuel ou le physique.

L'utilisation d'un progiciel de support de la méthode, d'aide à la conception et à la réalisation, fortement conseillée, peut entraîner un "pont" entre base de données de conception et base de données opérationnelle.

L'individu "client" est conçu dans une "base de conception". Dans cette base, l'enregistrement physique est "individu" et l'une de ses occurrences est "client". L'enregistrement physique "client" existe, ainsi que toutes ses occurrences dans une base de données "opérationnelle".

La structure et la nature des informations dans les enregistrements est la partie principale du dictionnaire de données et de ce "pont".

Trois démarches sont possibles.

Première démarche : le conceptuel de la base de données (MCD, MOD ou

MLD) définissant les concepts est bon et génère le physique. C'est le cas général lors du démarrage de l'application. Les fichiers opérationnels sont créés par une base conceptuelle. Toute information dans un enregistrement

est préalablement déclarée dans une base de données conceptuelle, définie dans un individu ou une relation. L'avantage "conceptuel" est de n'avoir que des informations qui se respectent, sans redondance non méritée.

Deuxième démarche : la base opérationnelle alimente la base de données

de conception. Les informations "opérationnelles" servent de base de documentation "automatique" facilitant la compréhension et la maintenance.

Le risque est l'absence de documentation des informations

d'enregistrements physiques créées lors de l'écriture de programmes. Les programmes seront plus vite réalisés mais avec le risque de ne pas avoir de documentation.

Troisième démarche : trois bases de données existent, une base

"méthode", une base "opérationnelle" et une base "tampon" où se trouvent les concepts désirés non opérationnels et les informations opérationnelles non "conceptualisées". Cette démarche permet une désynchronisation de la conception et de l'opérationnel.

La troisième démarche est celle recommandée. Elle permet d'organiser la fonction d'administration de données.