1.2. Cycle de décision
Ce cycle représente le point de vue de tous les
décideurs de l'organisation étudiée quelques soient leur
niveau de décision et d'action (point de vue d'un décideur au
sens large).
Le cycle de décision définit la nature de
résultat à produire à l'issu de chaque étape pour
qu'une décision quant à la continuation ou à l'abandon
d'une politique d'informatisation puisse être prise.
Cycle de décision
Cycle d'abstraction
Hiérarchie de décisions croissantes
Cycle de vie
- Schéma directeur
- Etude préalable
- Etude détaillée
- Etude technique
- Réalisation
- Mise en oeuvre
- Maintenance
- Physique
- Logique
- Organisationnel
- Conceptuel
251641344
1.3. Les différentes versions de Merise
a) MERISE 1
- Approche systémique ayant ses origines dans la
théorie des systèmes de Boulding introduite en France par J.L
LEMOIGNE.
- Montre les relations existant entre le système
d'information et le système opérant d'une part, ensuite entre S.I
et S.P d'autre part.
- Le S.I fournit aux acteurs (SO) et aux décideurs
(S.P) les informations dont ils ont besoin pour agir et décider.
- Couvre tout le cycle de vie du logiciel : schéma
directeurs, étude préalable, étude
détaillée, étude technique, production de logiciels, mise
en oeuvre, maintenance.
- Cycle d'abstraction reposant sur 3 niveaux :
conceptuel, organisationnel ou logique et physique.
- Séparation entre les modèles de données
analyses avec une approche entité-association ; et les
modèles des traitements, présentes avec un formalisme proche de
celui des réseaux de Pétri.
- La phase de validation permet de vérifier que toute
les données sont présentes pour réaliser les traitements
et que tous les traitements utilisés sont utiles pour obtenir les
données sont prévus.
b) MERISE 2
1. Lancé par `'sema group'' pour prendre en compte des
extensions et des améliorations liées évolutions
organisationnelles et technique des années 1990.
2. Le modèle E/A retenu (utilisé) pour la
modélisation des données de la première version
(années 1970) présentait quelques carences et les concepts de ce
modèle peuvent s'avérait insuffisant pour modéliser
certaines situation ou contraintes et l'on est oblige dans ce cas d'ajouter des
commentaires pour mention.
3. Un groupe de l'AFCET à apporte en Novembre 1990.
Des extensions au modèle (extensions au modèle individuel
remédiant aux faiblesses du formalisme de base), telles que le notions
de généralisation et de spécialiste pour traduire des
notions de d'héritage, les contrainte ensembliste (d'inclusion, de
totalité, d'exclusion, d'égalité & exclusif), les
contraintes d'intégrité et la notion d'identifiant relatif
(opposé à absolu), qui d'identifier une entité par rapport
à une autre.
*AFCET = Association Français pour cybernétique
et Technique
4. Les traitements ont été enrichi au niveau
conceptuel par l'introduction =
- De diagrammes de flots de données
- D'une Modèle conceptuel des traitements
Analytique(MCTA), qui permet dès la phase de conception de
s'intéresser aux données qi s'y rattachant, préparant
ainsi la phase de validation ;
- De la notion de cycle de vie d'un objet (utilisé ici
dans les sens d'entité) -CVO, pour prendre en compte tous les
états par lequel passe un objet au cours de sa vie, en fonction
d'événement qui peut se produire.
5. Apres le niveau conceptuel, il faut préciser les
niveaux organisationnel, ou sont prise en compte les structure les moyens
matériel et humains à mettre en place.
6. Puis au niveau logique, sont définit les interfaces
avec les utilisateurs, les ressources logiques de traitement et de stockage
ainsi que la répartition des données.
En ce qui concerne les concepts étendus, mis à
part la notion d'identifiant relatif, pour imputation en relation n'est pas
directement réalisable, car il est impossible de représenter les
contraintes ensemblistes.
Il faudra donc mettre en place, au niveau des traitements des
dispositifs pour garantir toute les contraintes.
Trois possibilités de traduction du concept à
d'héritage rappelé par le schéma ci-dessous
E1
P1
P2
ES2
P2'
ES1
P1
251640320
| 
