Exp GL5Merise PDF

MERISE : une méthode systèmique de
conception de SI
- Présentation générale -
Bernard ESPINASSE
Professeur à l'Université d'Aix-Marseille
Plan
• Origine et évolution
• Principes généraux
• Cadre de modélisation et démarche préconisée
• Principales dernières évolutions
Présentation de MERISE 2 - Bernard ESPINASSE - © - 1

Introduction : les méthodes Systémiques
• méthodes s'appuyant sur une approche systémique
• définissent différents niveaux de préoccupation ou d'abstraction
• proposent de nombreux modèles complémentaires
• sont souvent spécialisées pour la conception d'un certain type de systèmes
• méthodes systémiques les plus connues :
• MERISE (méthode la plus utilisée en informatique de gestion en France et
grande partie de l'Europe)
• AXIAL (IBM - systèmes d'information), MEGA (Mega - systèmes

d'information),...
• OSSAD (systèmes bureautiques)
• SAGACE (CEA - systèmes complexes (centrales atomiques))
• GRAI (Productique)
• ...

Origine de Merise : Merise 1° génération
• 1978 - Ministère de l'industrie : Merise 1° génération
• concevoir et définir une méthode d'intérêt national
• principales SSII et le CETE d'Aix-en-Provence (H.Tardieu - A.Rochfeld)
1974-1978
recherche en recherche en
informatique de gestion systèmique appliquée aux
(bases de données, organisations
SGBD)
1976 1977
Ministère de l'Industrie SSCI
1979 MERISE
-> synthèse :
• réactualise acquis sur la spécification des traitements des méthodes
antérieures
• intègre l'approche par les données
• propose une démarche garantissant la rigueur de la méthode et sa facilité
d'application sur le terrain

Merise
• 1979 : Merise 1° génération
• 1992 : Merise 2° génération
• bibliographie complémentaire :
• Nanci D., Espinasse B. et al., Ingénierie des Systèmes d'Information:

Merise Deuxième Génération - 3° Édition entièrement revue et
augmentée, Éditions Sybex, 1996.
• Tardieu H., Rochfeld A., Coletti R., La méthode Merise, tome 1 : Principes
et outils, éditions d’Organisation, 1983.
• Tardieu H., Rochfeld A., Coletti R., Panet G., Vahee G., la Méthode
Merise, tome 2 : Démarche et pratiques, éditions d’Organisation, 1985.
• Rochfeld A., Morejon, J., la Méthode Merise, tome III : Gamme opératoire,
éditions d’Organisation, 1989.

Objectifs de Merise
Pour être efficace une méthode doit pouvoir :
• associer étroitement les aspects organisationnels et informatiques
• accroître la qualité des relations entre les utilisateurs et les
informaticiens dans la mesure ou l'informatisation peut modifier les modes
de gestion et les conditions de travail
• être acceptée par les uns et les autres comme moyen:
• d'étude
• de conception
• de dialogue
• de formalisation de décision de choix
• de contrôle d'avancement,...
• être précise pour être efficace,
• sans être abusivement rigide pour être tolérée...
• évaluer au préalable : les dépenses et les conséquences liées aux
solutions de conception

Principes fondamentaux de la méthode MERISE
• apport de la systémique (Bertalanffy, LeMoigne,..): tente depuis 30 ans d'apporter
un nouveau cadre de réflexion, de modélisation des structures complexes vivantes
(biologie, sciences sociale, gestion,...)
=> l'organisation en tant que système
• découpage de l'organisation en domaines
• analyse indépendante Données / Traitements
• une démarche à 3 dimensions :
• la démarche : cycle de vie
• le raisonnement : niveaux d'abstraction
• la maîtrise : niveaux de décision

La démarche ou cycle de vie
• modèle de la cascade :
"plan d'action"
SHEMA DIRECTEUR
"dossier de choix"
ETUDE PREALABLE
"cahier des charges
utilisateur"
ETUDE DETAILLEE
"cahier des charges
technique"
ETUDE TECHNIQUE
"dossier de
réalisation"
REALISATION
"manuel
utilisateur"
MISE EN SERVICE

La démarche ou cycle de vie
Définition des orientations générales du développement à
schéma directeur moyen terme des systèmes d'information
PROJET
étude préalable Proposition et évaluation de solutions d'organisation et

techniques pour le SI d'un domaine
étude détaillée Spécifications complètes du futur SIO. Point de vue

de l'utilisateur (externe).
étude technique Spécifications complètes du futur SII. Point de vue du

réalisateur (interne).
Ecriture des programmes, génération des fichiers ou bases

production logiciel de données, tests
Installation de l'application informatique, mise en
mise en service place de la nouvelle organisation
Rectification des anomalies, améliorations,

maintenance évolutions

Les raisonnements ou niveaux d'abstraction
Exemples de choix :
choix de gestion:
• faire de la pré-facturation ou de la post-facturation
• procéder à des contrôles systématiques des dossiers avant de les traiter ou les
traiter sans contrôles et procéder à des contrôles par échantillonnage
• affecter certains produits à tels dépôts
• admettre qu'une commande client pourra être livrée en plusieurs fois, chaque
livraison donnant lieu à une facture....
choix d'organisation:
• les quantités réceptionnées seront saisies en fin de journée sur un terminal
dans le magasin
• l'interrogation des commandes se fera en temps réel sur ce même terminal....
choix techniques:
• mettre à tel endroit un terminal de telle marque
• exécuter tel traitement dans tel programme
• implanter telle donnée sur tel disque....

Les 4 niveaux d'abstraction de MERISE
Système d'Information Organisationnel (SIO) :
• niveau conceptuel exprime les choix fondamentaux de gestion: recherche
des éléments stables indépendamment des moyens à mettre en oeuvre, de
leurs contraintes et de leur organisation.
• niveau organisationnel exprime les choix d'organisation de ressources
humaines et matérielles, au travers de la définition de sites, de postes de
travail,...
Système d'Information Informatisé (SII) :
• niveau logique exprime les choix de moyens et de ressources informatiques,
en faisant abstraction de leurs caractéristiques techniques précises.
• niveau physique traduit les choix techniques et la prise en compte de leurs
spécificités.
SYSTEME D'INFORMATION ORGANISATIONNEL
SIO
SYSTEME D'INFORMATION
INFORMATISE
SII

Les 4 niveaux d'abstraction de MERISE
Système
d'Information
"naturel"
choix de gestion
définition des informations
Système niveau conceptuel et des activités
d'Information
Organisationnel choix d'organisation
S.I.O.
types de ressources et
niveau affectation
organisationnel
choix logiciels
moyens et ressources
informatiques
Système niveau logique
d'Information
Informatisé choix techniques
S.I.I. ressources effectives
niveau physique
Applications informatiques supports du

système d'information

Les Modèles de Merise
Données Traitements
Modèle Conceptuel des Données Modèle Conceptuel desTraitements

MCD MCT
SIO Signification des informations
sans contrainte Activite du domaine sans préciser
CONCEPTUEL technique ou économique les ressources ou leur organisation
et
ORGANISATIONNEL Modèle Organisationnel
Modèles Organisationnels des
Traitements
des Données
MOD MOT
SYSTEME Signification des informations Fonctionnement du domaine avec
D'INFORMATION avec contrainte les ressources utilisées et leur
ORGANISATIONNEL organisationnelles et économique organisation
Modèle Logique des Données Modèles Logique des Traitements
SII LOGIQUE MLD MLT

Description des données tenant Fonctionnement du domaine avec
compte de leurs conditions les ressources et leur organisation
SYSTEME d'utilisation par les traitements informatiques
D'INFORMATION
INFORMATISE
Modèle Physique des Données Modèle Physique des Traitements
MPD MPT
PHYSIQUE
Description de la ou des bases
de données dans la syntaxe du Architecture technique
logiciel SGF ou SGBD des programmes
préoccupations du préoccupations de
gestionnaire- l'informaticien
utilisateur

Modèles et niveaux d'abstraction
se pose le problème de :
• comment élaborer et exprimer les différents modèles?

formalismes adaptés à chaque modèle
conseils de mise en oeuvres
• comment passer d'un niveau d'abstraction au suivant et transformer les

différents modèles?
procédures de transformation
prise en compte de nouveaux choix
• comment confronter données et traitements pour assurer une cohérence

interne?
vérification de cohérence

Cycle de décision dans MERISE
étapes de la démarche résultats décisions

plan de
développement approbation et mise en
schéma directeur
des SI application
étude préalable dossier de choix choix d'une solution

n solutions ou arrêt
stop stop
spécifications accord utilisateur
étude détaillée fonctionnelles /specifs fonctionnelles
spécifications accord réalisateurs

étude technique techniques /specifs techniques
pour réalisation
système réalisé recette provisoire

réalisation logiciel en ordre de marche conformité système
système installé
mise en service recette définitive
dans l'organisation système en service
système recette simplifiée

maintenance maintenu fin de maintenance

Cheminement du processus de conception "courbe du soleil"
8 3
niveau 2
conceptuel
niveau 7
SIO
organisationnel 9 4
niveau 1
logique 10 5
SII
niveau 11 6
physique
système d'information système d'information

état actuel état futur
champ de l'étude champ de l'étude

préalable détaillée
prise en compte d'objectifs, de contraintes, d'orientations nouvelles

Niveaux d'abstraction et du degré de détail
degré
global détaillé
niveau
conceptuel
organisationnel
logique zone d'utilisation classique
physique

Démarche et couverture des niveaux d'abstraction
0% étude préalable 100%
conceptuel
organisationnel
logique
physique
0% étude détaillée 100%

conceptuel
organisationnel
logique
physique
0% étude technique/réalisation 100%
conceptuel
organisationnel
logique
physique
Évolution de la méthode MERISE
• depuis 1992 : Merise 2° génération
• évolution du cadre de modélisation
• l'extension de 3 à 4 niveaux d'abstraction (conceptuel, organisationnel,
logique et physique)
• émergence de nouveaux modèles :
• modèle logique de traitements (MLT)
• modèle organisationnel de données (MOD),
• distinction de 2 missions distinctes de l'ingénierie des SI :
• conception du Système d'Information Organisationnel (SIO)
• conception du Système d'Information Informatisé (SII)
• évolution des outils et formalismes associés

• extension du formalisme Entité-Relation, avec par exemple
l'explicitation de types et sous-types, de contraintes d'intégrité, ...
• clarification de la modélisation des traitements à l'aide du formalisme
issu des réseaux de Pétri, à différents niveaux de préoccupation,

Évolution de la méthode MERISE (suite)
• Merise 2° génération :
• MCT : introduction du concept d'état et ses conséquences sur les aspects de
modélisation,
• MCD : amendements concernent les récentes extensions du formalisme
Entité-Relation, le traitement de l'historisation,....,
• MOT : avec l'introduction des cycles de vie des objets (CVO),

• MOD : répartition organisationnelle des données (MOD locaux) et toute
sa pertinence dans contexte d'architectures client-serveur,
• MLT : approche et modélisation opérationnelles, adaptées aux nouveaux

environnements (Client-Serveur, interfaces graphiques, ...),
• MLD : passage du modèle Entité-Relation au modèle relationnel enrichi :
• prise en compte des contraintes d'intégrité
• écriture des triggers associés, l'historisation, ...

Mise en oeuvre de la méthode MERISE (suite)
• couplage avec des méthodes de conduite de projet ,
• développement d'ateliers de génie logiciel (A.G.L.) de conception : AMC
Designer, MEGA, WinDesign, ...
• ouverture vers les autres méthodes :
• de génie logiciel (Merise et Yourdon [PHAN 85],...),
• de génie cognitif (Merise et KADS [BRUNET 90],...),
• ...
• adaptation à d'autres types d'activités :
• domaine de la productique (Merise et GRAI [Cecima 90]),
• l'EDI (Merise et l'EDI [BCEL 91])
• ...
• largement diffusée en France et dans l'Europe du Sud (parfois avec des
adaptations mineures)
• constitue un standard en conception de système d'information

MCT : introduction du concept d'état
• établi lien entre modélisation des données et modélisation des traitements
• peut s'exprimer :
• par une valeur prise par une information (dossier en cours),
• par le fait qu'une activité à été réalisée (calcul des pénalités effectué),
• par une règle de traitement (délai de règlement dépassé de 15 j.)
• mémorisation des états assurée par les données informations spécifiques (ex: état
de la commande).
• s'applique à des objets et associations modélisés dans les données
• description d'un état d'un objet :
• le nom de l'objet,
• le nom de l'information décrivant le type d'état,
• la valeur de l'état,
• éventuellement la règle permettant de déterminer l'état.
• représentation graphique :
DOSSIER CREDIT
situation contentieux
commandement

Exemple d'utilisation du concept d'état
ARTICLE
CLIENT demande disponibilité
OK
et
VENTE DIRECTE
AU COMPTANT
Enregistrer la commande
Facturer
Enregistrer le règlement
Remettre les articles
articles en stockdernier article vendu
CLIENT facture comptant

ARTICLE
disponibilité
COMMANDE
rupture
livrée
FACTURE
réglée

MCD : récentes extensions du formalisme Entité-
Relation
• Types et sous-types d’entités : spécialisation/généralisation
Spécialisation simple Spécialisations multiples Spécialisations à surtypes
multiples
TIERS ADHERENT TIERS
n° adhérent n° tiers
n° tiers date adhésion raison sociale
raison sociale adresse administrative
adresse
adresse type
statut
type statut
XT T
CLIENT FOURNISSEUR
n° client n° fournisseur
PERSONNE MORALE PERSONNE PHYSIQUE COTISANT BENEFICIAIRE adresse de livraison délai de livraison
n° SIREN n° INSEE taux date ouverture droits conditions de vente
CLIENT FOURNISSEUR raison sociale nom

date création prénom
condition de règlement taux de remise forme juridique date naissance
• Restrictions et sous-types de relations

EMPLOYE 0,n travailler 1,n PROJET
0,1
SECRETAIRE 0,n gérer

MCD : récentes extensions du formalisme Entité-
Relation
• Contraintes intrarelation
• Contraintes interrelations
0,n
Rel_1 EXCLUSION 0,n
Rel_1 EXCLUSION et TOTALITÉ
Ent_1
Si une occurrence de l’entité Ent_1
Toute occurrence de l’entité
X Ent_1 participe à la relation XT Ent_1 participe au moins soit à
Rel_2
Rel_1, elle ne peut pas participer Rel_2
la relation Rel_1, soit à la
0,n à la relation Rel_2 et 0,n relation Rel_2, mais pas aux
réciproquement (possibilité deux à la fois.
d’orientation de cette exclusion)
0,n
Rel_1 SIMULTANÉITÉ 0,n
Rel_1 INCLUSION
Ent_1
Toute occurrence de l’entité Ent_1 Ent_1
Si une occurrence de l’entité
S participant à la relation Rel_1 I Ent_1 participe à la relation
Rel_2
participe simultanément à la Rel_2
Rel_1, elle participe à la
0,n relation Rel_2. 0,n relation Rel_2 (mais pas
réciproquement).
0,n
Rel_1 TOTALITÉ
Ent_1 Toute occurrence de l’entité Ent_1
S
participe au moins à l’une des
0,n
Rel_2 deux relations Rel_1 ou Rel_2.

Historisation
• Historisation des valeurs d’une propriété PERSONNE
nom antérieurement DATE
prénom 0,n 1,n
adresse jj_mm_aa
date naissance
adresse
• Propriété historisée PERSONNE

ident
nom
adresse (H)
• Entité historisée PERSONNE (H)

ident
nom
adresse
nombre d'enfants
• Relation historisée PERSONNE 1,n louer (H) 1,n LOGEMENT

montant loyer
• Patte de relation historisée ASSURE 0,n présent dans 1,n (H) DOSSIER

MOT : introduction des cycles de vie des objets (CVO)
• Concepts généraux de la modélisation de la dynamique
• Etat : abstraction des valeurs des attributs et des associations d'un objet,
• Evénement : stimulus accompagné éventuellement d'information,
• Transition : modification d'état provoquée par un événement,
• Diagramme d'états : graphe dont les noeuds sont des états et les arcs
orientés des transitions désignées par des noms d'événements.
déclaration accepté
controlé
ouvert en instruction en attente
renvoi trop hors facture
grave non délai reçue
pièces
manquantes couvert
incomplet transmis clos réglé
Diagramme d'états du dossier de sinistre
• les méthodes objet ajoutent d'autres concepts :

• Condition : associée à une transition,
• Opération : associée à l'état, décrit ce que fait l'objet en réponse à
l'événement

MOT : introduction des cycles de vie des objets (CVO)
• Concepts retenus pour le cycle de vie des objets dans Merise
• Etat,
• Evénement,
• Activité : (opération, tâche) appelée Transition avec si nécessaire
synchronisation et conditions
• Particularités du CVO Merise :
• le passage d'un état à un autre nécessite obligatoirement une transition
indiquant à minima les activités permettant ce changement d'état,
• une transition pas obligatoirement déclenchée par un événement
explicite : déclenchement implicitement liée à un événement décisionnel
Dossier Sinistre
en attente facture
• passage de l'état "attente" de l'objet "Dossier sinistre" à l'état

Règlement
"réglé" de celui-ci,
contrôler facture
calculer montant indemnisé • passage déclenché par l'événement "facture" et nécessitant la
réalisation de l'activité "Réglement"
Dossier Sinistre
réglé

MOD : répartition organisationnelle des données (MOD
locaux) pour les architectures client-serveur
• Répartition organisationnelle des données = répartition d'utilisation de ces
données suivant les différentes unités organisationnelles.
• permet d'orienter ultérieurement la répartition informatique des données, en
particulier dans des environnements clients / serveurs
• MOD local à une unité organisationnelle
• exprime, du point de vue de l’utilisateur, les données accessibles par un
ensemble de postes de l'unité organisationnelle
• pour chaque unité organisationnelle MOD local :
• sous-ensemble du MOD global : sous ensemble d'entités-types,
de relations-types et de propriétés
• tableau précisant les éventuelles restrictions sur les occurrences
disponibles d'entités ou de relations : une agence (unité
organisationnelle) ne gère que les contrats de son secteur.
• permet de mettre en évidence :
• les données communes à l'ensemble du domaine,
• les données partagées entre certaines unités,
• les données privées à une unité.
0,n
(R)
1,n
0,n
Unités organisationnelles et MOD locaux

• accessibilité des données d'un MOD local : actions élémentaires possible pour
tous les traitements réalisés dans le site organisationnel => préciser différents types
d’accès, lecture (L), modification (M), création (C) et suppression (S)
• si partage entre plusieurs UOs et si répartition informatique : préciser quelle
UO fait référence en cas de divergence dans le contenu des informations partagées.

• Sécurité des données :
• s'exprime, selon les cas, au niveau du MOD global ou des MOD locaux
• passe par la définition de catégories ou profils d'utilisateurs
• definir les restrictions d'accès aux données mémorisées pour certaines profils
d'utilisateurs concernant un type d'action limité (L, M, C, S) :
• soit aux entités, relations ou propriétés du MOD global ou local,
• soit à une sous-population des occurrences d’entités/relations
Profil utilisateur : Employé

Entité - Relation restriction ou autorisation
Propriété
CLIENT
niveau découvert Lecture seule autorisée
Profil utilisateur : Chef de service

Propriété
CLIENT
niveau découvert Modification autorisée montant <= 10 000 F.
Profil utilisateur : Directeur

Propriété
CLIENT
niveau découvert Modification autorisée tout montant

MLT : modélisation adaptée aux environnements Client-
Serveur, interfaces graphiques, ...
Machine logique
• machine physique = ensemble de matériels permettant d'assurer les fonctions de
base de l'informatique (exécution de logiciel, mémorisation, entrées/sorties).
• machine logique = ensemble de ressources informatiques (matériel et logiciel)
capables d'exécuter des traitements informatiques de façon autonome
• une machine logique peut être :

• équivalente à une machine physique : micro autonome ou en réseau,
serveur, mainframe ou mini avec terminaux passifs.
• composée de plusieurs machines physiques : mini et micro en émulation
terminal passif, mainframe et machine base de données.
• une partie de machine physique : machine virtuelle sur un mainframe.

Répartition des traitements entre des machines logiques :
SYSTEME DEPARTEMENTAL AGENCE SYSTEME INTER-COMPAGNIES
infos adversaire début
et
CONTROLE PARTIE ADVERSE
Saisie des informations de la partie adverse :
compagnie, n° contrat, n° véhicule
compagnie hors convention
compagnie conventionnée éléments d'identification
CONTROLE EXISTENCE NATIONALE

Vérifier au fichier central des assurances
la validité des informations saisies
connu inconnu
infos administratives
ENREG INFOS PARTIE ADVERSE

mise à jour dossier sinistre
ou
SAISIE COMPLEMENT DOSSIER
Saisir les informations connues
pour traitement hors procédure
standard d'indemisation directe
fin

• l'Unité Logique de Traitement = ensemble des traitements informatiques
homogènes à réaliser qui peuvent être décomposés selon leur nature :
• Interface,
• Traitements,
• Données.
Composants fonctionnels d'une ULT : Sous schéma de données logique
associé à l'ULT :
Enregistrer sinistre
PRESENTATION
Nouveau dossier sinistre
LOGIQUE DE
DIALOGUE ASSURE VEHICULE
ACCES AUX CODE N° IMMATRICULATION
NOM TYPE
DONNEES ADRESSE MARQUE
PUISSANCE FISCALE
LOGIQUE
FONCTIONNELLE concerner couvrir
SINISTRE
N° SINISTRE
REGLES CONTRAT
N° POLICE
N° POLICE
DE CALCUL N° IMMATRICULATION
NOM
rattaché à DATE OUVERTURE
CODE
DATE SURVENANCE
NATURE
ENCHAINEMENTS

MLD : passage du modèle Entité-Relation au modèle
relationnel enrichi
• prise en compte des types et sous-types :
-> écriture des assertions SQL ou des triggers associés
• prise en compte des contraintes d'intégrité :
• prise en compte de l'historisation :

relationnel enrichi
exemple de contrainte inter relations d'inclusion : toute personne qui effectue un
prêt doit avoir souscrit un abonnement :
Entité-Relation Relationnel dérivé
SOUSCRIRE ABONNEMENT souscrire ABONNEMENT
1,n n°abonnement PERSONNE n°abonnement

0,1 n°personne SOUSCRIRE
n°abonnement
PERSONNE occurrences de PRET
I EFFECTUER
n°personne
PERSONNE
n°pret
n°personne
0,n
EFFECTUER PRET
1,1 n°pret
effectuer
Assertion SQL 2 : Trigger oracle :

CREATE ASSERTION I CREATE TRIGGER Inclusion_Effectuer_Souscrire
CHECK (NOT EXISTS BEFORE INSERT ON Pret
(SELECT DISTINCT n°personne FROM Personne A ON EACH ROW
WHERE NOT EXISTS WHEN new.n°personne IS NOT NULL
(SELECT DISTINCT n°personne FROM Prêt B DECLARE
WHERE (A.n°personne= B.n°personne)) nb_abonnement number;
AND n°abonnement IS NOT NULL)); BEGIN
SELECT COUNT(*) INTO nb_abonnement FROM Personne
WHERE n°personne = :new.n°personne;
IF nb_abonnement = 0 THEN
raise_application_error (-20006, 'Un abonnement n'a pas été souscrit' ));
END IF;
END;

relationnel enrichi
• prise en compte de l'historisation : règles de transformation logique
exemple : historisation de relation
PERSONNE LOGEMENT
n°personne adresse
LOUER (H)
nom surface
adresse 0,n loyer_mensuel 0,n nb_pièces
Pour toute modification de valeur de l'une des propriétés d'une relation, on historise
l'ensemble des valeurs des propriétés de la relation ainsi que son identification :
PERSONNE LOUER LOGEMENT
n°personne adresse adresse
nom n°personne surface
adresse loyer_mensuel nb_pièces
H_LOUER
adresse
n°personne
DATE_HISTO
loyer_mensuel

Exp GL5Merise PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Exp GL5Merise PDF

Transféré par

Droits d'auteur :

Formats disponibles

MERISE : une méthode systèmique de

Présentation de MERISE 2 - Bernard ESPINASSE - © - 1

• AXIAL (IBM - systèmes d'information), MEGA (Mega - systèmes

• OSSAD (systèmes bureautiques)

• SAGACE (CEA - systèmes complexes (centrales atomiques))

Présentation de MERISE 2 - Bernard ESPINASSE - © - 2

Présentation de MERISE 2 - Bernard ESPINASSE - © - 3

• Nanci D., Espinasse B. et al., Ingénierie des Systèmes d'Information:

Présentation de MERISE 2 - Bernard ESPINASSE - © - 4

Présentation de MERISE 2 - Bernard ESPINASSE - © - 5

=> l'organisation en tant que système

• découpage de l'organisation en domaines

• analyse indépendante Données / Traitements

• une démarche à 3 dimensions :

• la démarche : cycle de vie

• le raisonnement : niveaux d'abstraction

• la maîtrise : niveaux de décision

Présentation de MERISE 2 - Bernard ESPINASSE - © - 6

Présentation de MERISE 2 - Bernard ESPINASSE - © - 7

étude préalable Proposition et évaluation de solutions d'organisation et

étude détaillée Spécifications complètes du futur SIO. Point de vue

étude technique Spécifications complètes du futur SII. Point de vue du

Ecriture des programmes, génération des fichiers ou bases

Rectification des anomalies, améliorations,

Présentation de MERISE 2 - Bernard ESPINASSE - © - 8

Présentation de MERISE 2 - Bernard ESPINASSE - © - 9

Présentation de MERISE 2 - Bernard ESPINASSE - © - 10

Applications informatiques supports du

Présentation de MERISE 2 - Bernard ESPINASSE - © - 11

Modèle Conceptuel des Données Modèle Conceptuel desTraitements

Modèle Logique des Données Modèles Logique des Traitements

SII LOGIQUE MLD MLT

Présentation de MERISE 2 - Bernard ESPINASSE - © - 12

• comment élaborer et exprimer les différents modèles?

• comment passer d'un niveau d'abstraction au suivant et transformer les

• comment confronter données et traitements pour assurer une cohérence

Présentation de MERISE 2 - Bernard ESPINASSE - © - 13

étapes de la démarche résultats décisions

étude préalable dossier de choix choix d'une solution

spécifications accord réalisateurs

système réalisé recette provisoire

système recette simplifiée

Présentation de MERISE 2 - Bernard ESPINASSE - © - 14

système d'information système d'information

champ de l'étude champ de l'étude

prise en compte d'objectifs, de contraintes, d'orientations nouvelles

Présentation de MERISE 2 - Bernard ESPINASSE - © - 15

logique zone d'utilisation classique

Présentation de MERISE 2 - Bernard ESPINASSE - © - 16

0% étude détaillée 100%

• évolution des outils et formalismes associés

Présentation de MERISE 2 - Bernard ESPINASSE - © - 18

• MOT : avec l'introduction des cycles de vie des objets (CVO),

• MLT : approche et modélisation opérationnelles, adaptées aux nouveaux

Présentation de MERISE 2 - Bernard ESPINASSE - © - 19

Présentation de MERISE 2 - Bernard ESPINASSE - © - 20

Présentation de MERISE 2 - Bernard ESPINASSE - © - 21

CLIENT facture comptant

Présentation de MERISE 2 - Bernard ESPINASSE - © - 22

CLIENT FOURNISSEUR raison sociale nom

• Restrictions et sous-types de relations

SECRETAIRE 0,n gérer

Présentation de MERISE 2 - Bernard ESPINASSE - © - 23