CHAPITRE 3 : ANALYSE ET CONCEPTION DU SYSTEME
DE GESTION AUTOMATISE
3.1 Introduction à la méthodologie
d'analyse
3.1.1 Pourquoi une
méthode d'analyse ?
Toute résolution de problème quel qu'il soit,
nécessite une, voir plusieurs phases de réflexion plus ou moins
longues en fonction de l'ampleur et du type du problème.
Lors d'un projet informatique, cette réflexion doit
pouvoir être comprise et reprise par toute personne intervenant sur le
projet.
C'est pourquoi, ont été définies des
méthodes d'analyse. Certaines disparaissent laissant la place à
d'autres méthodes plus adaptées, d'autres évoluent dans le
temps en fonction des différentes technologies. Chaque méthode a
ses qualités et ses défauts. Il est donc parfois utile et
nécessaire en fonction de l'étape d'analyse du projet d'appliquer
des méthodes différentes.
Chaque méthode est adaptée au type de projet
(objet, industrielle, gestion) et aux outils (SGBD, L3G ...).
Quelques méthodes :
MERISE, MERISE/2
SADT
SART
OMT
UML (bien que UML n'est pas une méthode mais un langage
de modélisation unifiée)
3.1.2 Qu'est ce que
MERISE ?
MERISE est née en 1979 au Centre Technique Informatique
du ministère de l'industrie. Ces principaux créateurs sont
Hubert Tardieu, Georges Panet et Gérard Vahée . Elle a
réellement été introduite dans les entreprises entre 1983
et 1985. Depuis, elle a connu des évolutions en fonction des
avancées technologiques avec dernièrement MERISE/2 tournée
vers l'objet. Elle reste encore une méthode très utilisée
en France même si UML/OMT est en train d'inverser la tendance.
MERISE propose une double approches
données-traitements menée en parallèle tout au long du
projet ainsi qu'une démarche méthodologique de
développement d'un système d'information.
Nous nous intéresserons à l'approche MERISE,
c'est à dire aux outils de représentation que nous nommerons
modèles et qui sont des outils d'analyse (représentation du
système existant) et de conception (représentation du
système futur).
Chacun de ces modèles correspond à un niveau
d'abstraction et se représente selon un formalisme bien défini et
traduit un certain choix.
3.1.2.1 Les niveaux
d'abstraction :
Il y a trois niveaux d'abstraction :
Le niveau conceptuel
Le niveau organisationnel
Le niveau physique
a. Le niveau conceptuel :
Il consiste à répondre à la question
QUOI ?
C'est à dire quoi faire ?, avec quelles
données ?
A ce niveau, on ne se préoccupe pas de l'organisation
du travail ni du matériel utilisé.
Les deux modèles sont le Modèle conceptuel des
données et le Modèle conceptuel des traitements.
b. Le niveau organisationnel :
Il consiste à répondre à la question
QUI?, OU?, QUAND ?
C'est à ce niveau que sont intégrés les
critères d'organisation de travail.
On tient compte (ou on propose) des choix d'organisation de
travail comme la répartition des traitements entre l'homme et la
machine, le mode de fonctionnement (temps réel, temps
différé).
Le modèle de représentation est le modèle
organisationnel des traitements.
c. Le niveau physique :
Il consiste à répondre à la question
COMMENT ?
On étudie les solutions techniques ( mode de stockage
pour les données, découpage des programmes pour les traitements
).
Les modèles étudiés à ce niveau
sont les modèles logiques des données et physiques des
traitements.
Chacun de ces trois niveaux ne sont pas indépendants.
Il va de soi, que les choix techniques (niveau physique ) peuvent être
imposés dès le début du projet. Les modèles
conceptuels et organisationnels seront alors étudiés en tenant
compte de ces contraintes. Chacun des modèles seront affinés au
cours de la vie du projet.
Le tableau suivant résume les modèles que nous
allons aborder tout au long de ce projet :
Tableau 1: tableau des modèles
d'analyse
|
NIVEAU
|
DONNEES
|
TRAITEMENTS
|
CHOIX PRIX EN COMPTE
|
|
Conceptuel
|
Modèle Conceptuel des Données (MCD)
|
Modèle Conceptuel des Traitements (MCT)
|
Choix de gestion
Quoi ?
|
|
Organisationnel
|
|
Modèle Organisationnel des Traitements (MOT)
|
Choix 'organisation
Qui ?, Où ?,Quand ?
|
|
Physique
|
Modèle Logique des Données
(MLD) Modèle Physique des Données (MPD)
|
Modèle Physique des traitements (MPT)
|
Choix techniques
Comment ?
|
3.1.2.2 La démarche préconisée par
MERISE :
MERISE préconise un découpage du projet en
quatre étapes. Chacune des étapes correspond à des phases
d'avancement du projet et donc à une étude bien
précise.
Les études effectuées au cours de chacune de ces
étapes utilisent les différents niveaux d'abstraction.
Chaque étude doit déboucher sur un dossier qui
doit être validé par toutes les personnes concernées par le
projet (utilisateur et informaticiens).
Ces étapes sont au nombre de quatre :
Etude préalable
Etude détaillée
Réalisation
Mise en oeuvre
a. L'étude préalable :
Cette phase a pour but de bien cerner le système
à étudier : QUOI ? Dans quel but ?, Qu'est ce qui
existe ? ...et à proposer une première solution ainsi qu'une
évaluation tant qualitative que quantitative du projet.
Elle est primordiale et conditionne le bon déroulement
des phases suivantes.
La première des actions à effectuer est le
recueil des données c'est à dire toute information
nécessaire à cerner le projet, à le comprendre et à
en effectuer une première ébauche.
Tous ces renseignements sont généralement
obtenus au cours d'entretiens. Chaque entretien doit par la suite être
consolidé.
L'objectif de la consolidation est de préparer les
étapes suivantes en identifiant d'ores et déjà certains
concepts ( règles de gestion, de calcul et d'organisation, tâche,
domaines, acteurs, processus, flux d'information ... ) mais aussi de constater
les points restés obscurs. Il est généralement utile et
nécessaire de formaliser les échanges d'information par un
diagramme de flux de données.
Toutes les informations ainsi obtenues constituent le dossier
d'étude préalable.
b. L'étude
détaillée :
Basée sur le dossier d'étude préalable
elle a pour but de décrire complètement, au plan fonctionnel, la
solution à réaliser.
Elle débouche sur un dossier de spécifications
détaillées.
c. La réalisation :
Elle concerne la production du code informatique correspondant
aux spécifications définies dans l'étude
détaillée. Elle débouche sur un dossier de
réalisation.
d. La phase de mise en oeuvre :
Son but est d'exécuter
toutes les actions (formation, documentation, installation des
matériels, initialisation des données ...) qui permettront aux
utilisateurs d'utiliser le logiciel fourni.
3.2. Diagramme de flux de
données
Il paraît important de parler du diagramme de flux
données ( Data Flow Diagram ) car il est très souvent
utilisé, quelque soit la méthode d'analyse abordée.
En effet, lors de l'étude préalable, les
différents entretiens permettent de cerner le système
étudié tant par les documents échangés, les
données manipulées que par l'organisation.
L'intérêt de ce modèle est quadruple :
Il est simples, Il est fréquemment utilisés
même en dehors de toute méthodologie ( donc connu )
Il est un excellent point de départ au modèle
conceptuel des données
Il est un excellent point de départ au modèle
conceptuel des traitements
NOMENCLATURES :
Pour notre projet nous allons représenter:
L'organisation par un rectangle ;
Les acteurs externes par des ellipses en
pointillés ;
Les acteurs internes par des ellipses ;
Les flux d'information par des flèches dont
l'orientation désigne le sens du flux d'information.
Dépôt des données par un rectangle non
fermé
3.2.1.
Diagramme de flux des données lors de l'inscription
Figure 1: Diagramme de flux de
données inscription
1
INSCRIRE
Parent d'un enfant
Demande
Refus de demande
1
Listes des élèves Admis
2
Enregistrer
3
Listes des élèves en dette
2
Listes des élèves en ordre
élèves
Reste à payer
Bordereau de versement
Lors de l'inscription la demande de parent peut être
accepte ou refuser pour plusieurs raisons:
Soit quand il n'y a plus de places disponibles.
Soit quand l'enfant ne satisfait pas les conditions
d'inscription.
Quand l'inscription est accorde à l'enfant alors
l'enfant ou ses parents
procèdent à l'enregistrement et au paiement des frais de
scolarité.
| 
