Méthodologies de conception des SI

Auteur: S. SI- SAID CHERFI Maître de conférences- CNAM - PARIS

Bibliographie
La méthode MERISE, Principes et outils : H. TARDIEU, A. ROCHFELD, R. COLLETTI.
Les éditions d ’organisation, 1979. (à savoir)

Ingénierie des systèmes d'information MERISE deuxième génération (4eme édition), D.

NANCI, B. ESPINASSE, éditions Vuibert. 2001 (vue complète sur la méthode)

Conception des bases de données relationnelles en pratique: Concepts, méthodes et cas

corrigés J. AKOKA, I. Comyn-Wattiau. Éditions Vuibert, 2001 (exercices corrigés)

Object-Oriented Systems Analysis and Design using UML, S. BENETT, S. McROBB, R.

FARMER, éditionsMcGrawwHill, 2001

UML par la pratique P. Roques, (exercices avec corrigés)

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 1

Copie des transparents de cours

1. Accéder au site du département informatique

http://deptinfo.cnam.fr/
2. Rubriques supports puis chaire Informatique
d’entreprise
3. NFE108

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 2

1
 Méthodologies de conception des SI

Partie I
Introduction

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 3

Qu’est ce qu’un système d’information?

Tout système d’information possède:

– une activité humaine nécessitant de l’information
– des données stockées
– des données en entrée avec un moyen pour les acquérir
– un ensemble de processus qui transforment les données
– des données en sortie avec un moyen pour les représenter

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 4

2
 Caractéristiques des systèmes

• Un système
–est un ensemble d’éléments en interaction dynamique, organisés en
fonction d’un but.
• Un système:
–a des frontières
–est doté d’une structure
–fait une ensemble d’activités afin d’atteindre un but
–évolue dans un environnement
• Un système d’information est un système organisé de ressources, de
personnes et de structures qui évolue dans une organisation et dont dont le
comportement coordonné vise à atteindre un but commun.
• Exemple de systèmes d’information
Gestion des réparations dans un garage automobile, Gestion de la scolarité,
Gestion des vols dans une compagnie aérienne etc..
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 5

Types de SI

• Les systèmes d’information sont sensés aider les

utilisateurs dans leurs activités
– Stocker et restaurer l’information
– Faire des calculs
– Aider à communiquer
– Ordonnancer et contrôler des tâches
– Etc.

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 6

3
 Types de SI

• Systèmes opérationnels assistent et ou contrôlent

l’exécution des opérations de gestion
– Un système comptable corrige les erreurs commises par le
facturier ou le comptable
• Système de pilotage aide les décideurs dans leurs
prises de décision
– Un système décisionnel de gestion de places de marché aide
les décideurs dans le choix de l’ouverture d’une nouvelle
place de marché.

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 7

Types de SI

• Systèmes temps-réel gèrent essentiellement des

dispositifs matériels, souvent dans des domaine de
sécurité de fonctionnement
– Les centrales nucléaires sont dotés d’un système de
control de la température.

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 8

4
 Où est la difficulté?

• Le développement de systèmes, en général et celui des

systèmes d'information en particulier est complexe.
• Pourquoi? (selon Booch, 1994)
1. Complexité liée au domaine
– complexité des domaines (connaissance et évolution des besoins)
– coût de la maintenance des systèmes (problèmes
d’interopérabilité générés par l’hétérogénéité des solutions)

2. Complexité du processus de développement

– besoin de gérer des groupes (communication, éloignement
géographique et de langue etc.)

– besoins de simplifier le processus

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 9

Où est la difficulté ? (suite)

3. Dangers de la flexibilité
le logiciel est flexible et expressif. Il encourage par conséquent l'expression de
besoins de plus en plus exigeants, qui conduisent à leur tour à des
implémentations complexes et difficiles à évaluer.

4. Difficulté dans la caractérisation des aspect

comportementaux
Il est plus facile de décrire les aspects statiques d’un systèmes que ses
aspects comportementaux. Il faut décrire les états, la séquence de valeurs
possibles et les règles qui régissent ces états.

"La tâche de l'équipe de développement est d'organiser

l'illusion de la simplicité" [Booch, 94]
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 10

5
 Conséquences

Échec dans la gestion de la complexité

Non respect des contraintes liées au projet de

développement :
Retard, dépassement des budgets, déficience
par rapport aux besoins
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 11

Conséquences

Why Big Software Projects Fail: The 12 Key Questions

Watts S. Humphrey,
The Software Engineering Institute

In spite of the improvements in software project management over the last several years, software
projects still fail distressingly often, and the largest projects fail most often. …. The principal
questions concern why large software projects are hard to manage, the kinds of management systems
needed, and the actions required to implement such systems.

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 12

6
 Conséquences

USS
London
Taurus
Denver
Ariane
E-mail
MarsYorktown
buffer
5(1993)
baggage
Ambulance
(1996)
Climate overflow
(1998)
handling
System
Orbiter (1998)
system
(1992)(1992)
(September 23rd, 1999)

AThe Ariane
Taurus,
The
Several
crew
succession
Denver 5 rocket
member
the
E-mail exploded
planned
airport
of systems
of
software
the onsuffer
baggage its
automated maiden
guided-missile
engineering flight
handling
from a in
transaction June [4],
cruiser
"buffer
failures,
system 1996
settlement
overflow
USS
was because
especially
Yorktown
so complex theproject
error",
system
in navigation
mistakenly
when for
(involving package was
The 125 million dollar Mars Climate Orbiter is assumed lost by officials at theextremely
management,
NASA. London
entered
300
The
inherited from the Ariane 4 without proper testing. The new rocket flew faster, resulting in larger values of
a
caused
Stock
computers)
long
zero
failure
some e-mail
Exchange
for2 failures
a data
responsible
variables addresses
that
in the the
value,
was
of loss
for development
London's
canceled
navigation are
which received.
ofsoftware.
the resulted
(England)
after
orbiteroverrun
is5The
Shortly years
in Ambulance
ainternal
prevented
division
attributed
after of to
launch, failed
abuffers
an by the
development.
zero.
failure
attempt airport
receiving
of
to Thefrom
NASA’s
convert error
the
Losses
opening
system
a 64-bit cascadedare
floating-on
engineer
and
dispatch
estimated
time.eventually
addresses
point number process.
Fixingsystem.
at
dothe
into£75m
anot
shutThe
16-bit process
incredibly
The
check
for
downrepair
thefor
integer the did
project
buggy
length
cost
generated not
ship's and
an specify
system
was
and
propulsion
£450m the
estimated
allow
overflow.requiredsystem
their
to
The system. ofadditional
customers.
atbuffers
erroran£9m,
was measurement
The
but
to (Pooley
caught, overflow
ship
itbutisthe
50% to
believed
was be
&causing
code ofdeadused
Stevens,
the
that in on
that
caught
the
it
the
people
1999)project.
elected
original
the water to
applications
died As
shut
budget
for whoa -result,
down
severaltothe
nearly
would one
crash.
hours
notof
subsystem.
$200m. theThe
Hostile
because
have development
rocket
died
hackersveered
a ifprogram teams
off course
ambulances
use this used
didn't and
fault
hadImperial
check for measurement
exploded.
toreached
trick It was
valid
the them as while
unfortunate
computer
that other
the the code that the
used failed genereated
metric system inertial
of reference information
measurement. When useful only before from
parameters lift-off;one
had it been
module
input.
promptly
into
turnedrunning
off(reported
at as
the they
a malicious
moment inwould
Scientific
have
program
of launch, American,
done
there wouldinwithout
its
have place.
November
beenthe nofailures.
1998)
trouble. (Kernighan, 1999)
were passed to another during orbit navigation correct, no conversion was performed,
resulting in the loss of the craft.
http://mars.jpl.nasa.gov/msp98/orbiter/

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 13

Conséquences

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 14

7
 Caractéristiques de la complexité

• D ’après Grady Booch

1. La complexité est souvent hiérarchique
2. Le choix des primitives du système est souvent arbitraire (choix
de l’architecte système)

3. Les liens intra-composants devraient être plus forts que les

liens inter-composants (concept de module)
4. Les systèmes sont souvent issues de combinaisons différentes
des mêmes briques de base (patterns récurrents)
5. Tout système devrait être conçu par étape en évoluant du
simple vers le complexe (développent incrémental)

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 15

Développement de systèmes d'information

• Le développement de systèmes d'information est:

– Un processus de changement dirigé par un groupe de

développeurs qui opère en prenant en compte un système, dans
un environnement et ce pour atteindre ou pour maintenir des
objectifs fixés par des acteurs

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 16

8
 Développement et Système

• Le système : l'objet
– a des frontières arbitraires fixées par les objectifs et les
perspectives
– est doté d’une structure composée d'objets et de relations entre
ces objets
– a des propriétés émergentes et inattendues
– peut renfermer des contradictions / des ambiguïtés / des
recouvrements
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 17

Développement et processus de changement

• Le processus de changement
– agit sur la structure
– est dirigé par les objectifs
– renferme une dimension sociale
– souvent incertain
– nécessite des moyens
– est spécifique au problème

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 18

9
 Développement et environnement

• L'environnement :
• tout ce qui est en dehors de l'objet (le système) et du
groupe de développement
– est composé de conditions et de facteurs qui ont un impact sur
le groupe de développeurs et sur le processus de changement
– est constitué d'une multitude de sous environnements:
• économique
• technique (outils, méthodes et les techniques)
• légal (législation)
• humain (acteurs)

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 19

Développement et développeurs

• Les développeurs:

– Organisation formelle
• rôles
• Assignation des tâches
• Autorité / responsabilité
– Organisation informelle
• rapports de force
• relations personnelles
• Engagements personnels

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 20

10
 Développement et objectifs

• Les objectifs
– implicites / explicites
– imposés ou négociés
– contradictoires ou complémentaires
– conformes à la législation
– réalistes / trop ambitieux

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 21

Développement et acteurs

• Les acteurs
– internes (utilisateurs, dirigeants, unités organisationnelles) ou
externes (clients, instances gouvernementales, associations,
éditeurs de logiciels, détenteurs de technologies, etc.)
– sont guidés par des intérêts et des objectifs
– peuvent être impliqués dans le développements en tant que
membres
– Peuvent avoir des droits sur le système et ses propriétés.

Le développement est la combinaison de facteurs

technologiques, sociaux, psychologiques et culturels
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 22

11
 Comment concevoir un SI

• Concevoir un SI revient à:
– Résoudre un problème
– décomposer le problème
– le modéliser
• la modélisation est une activité orientée par le bon sens
• Modéliser
– abstraire Besoin de modèles
– organiser Besoin de méthodes
– « formaliser »

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 23

Modélisation du processus de développement

Les modèles de cycle de vie

• Les modèles de cycle de vie servent à

– décrire les activités à effectuer lors du développement
d ’un systèmes d’information
– prédéfinir l’enchaînements de ces activités
• Ils sont sensés fournir un cadre général pour
– comprendre
– contrôler et
– gérer
le processus de développement
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 24

12
 Exemples de modèles de cycle de vie
Le modèle en cascade

• Introduit par [Royce, 1970]. Le développement est vu

comme un processus séquentiel comprenant les activités
suivantes:
– définition des besoins
– conception
– implémentation & tests unitaires
– vérification
– exploitation et Maintenance
• Inconvénients :
– vision linéaire
– pas d ’itération, donc pas de prise en compte du changement
– Délai de livraison trop longs
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 25

Exemples de modèles de cycle de vie

Le modèle en spirale et approche incrémentale
• Introduit par [Bohem, 1987]. Le développement est
vu comme un processus itératif et incrémental.

•identifier un problème
•définir les besoins associés (req.)
•une solution et le risque associé
(analyse)
•développement et vérification
(design & build)
•planifier l'étape suivante (plan)

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 26

13
 Apports de l’approche incrémentale

• Les plus par rapport au modèle en cascade

– minimise les risques (en livrant des incrément)
– permet la prise en compte de l'évolution des besoins (la
livraison des incréments permet de mesurer la satisfaction des
utilisateurs et l’adéquation aux besoins)
– plus facile à contrôler (cycles de durée limitée)
– peut mieux répondre aux besoins des utilisateurs
(architecture modulaire permettant un développement évolutif)

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 27

Conclusion sur les modèles de cycle de vie

– décrivent les phases du développement à un niveau de détail

insuffisant pour guider les développeurs. Ils se focalisent sur
l'organisation des activités (contraintes régissant leur
exécution) et se soucient peu du produit.
• Les modèles de cycle de vie ne sont que des
stratégies d’organisation et de gestion des phases du
processus de développement.

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 28

14
 Méthodes pour le développement
de systèmes

• Définition [Booch, 1994]

– "…un processus rigoureux permettant de générer un
ensemble de modèles et qui décrit divers aspects d'un
logiciel en cours de construction en utilisant une certaine
notation"

• Objectifs
– atteindre les objectifs fixés par les acteurs
– aider à la conduite du processus de développement

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 29

Apport des méthodes au processus de

développement

• Lorsqu'une méthode est "bien" utilisée, elle:

– est un support pour les efforts de standardisation et
d'harmonisation du travail de développement et des
produits délivrés,
– joue le rôle de garant de la qualité du système,
– est un support de communication entre les individus,
– Améliore le processus de développement des SI
• réutilisation, répétition, prédiction et contrôle
• adaptation
• Diminution de la dépendance envers des personnes clés
• facilite le test des systèmes produits
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 30

15
 Exemple de méthodes

• Méthodes structurées : SSADM

– "Structured System Analysis and Design Method''

• Méthodes systémiques : MERISE

• Méthodes orientées objet : OMT, Processus unifié

MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 31

SSADM : historique

• 1980 Central Computer and Telecommunications Agency (CCTA)

évalue des méthodes d'analyse et de conception
• 1981 LBMS méthode choisie parmi une liste de cinq proposées
• 1983 SSADM imposée pour tous les nouveaux développements de
SI
• 1984 Version 2 de SSADM délivrée
• 1989 évolue vers Euromethod, lancement d'outils CASE
• 1990 Version 4 lancée
• 1995 SSADM V4+ annoncée, V4.2 lancée
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 32

16
 La méthode SSADM : caractéristiques

• Adopte le modèle en cascade

Analyse:
Analyse des besoins
Conception
Spécification des besoins
Implémentation & tests unitaires
Spécification du système logique
Vérification
Spécification du système physique
Exploitation et Maintenance

• Notations
• Data flow diagrams
• ER diagrams
• Data dictionaries
• Function specifications
33
• Etc. MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS

La méthode MERISE : historique

• 1976 premières réflexions sur une méthode d'analyse

destinée à la conduite des projets du ministère de
l'industrie
• 1979 naissance de MERISE version 0
• 1982 création de MERISE version 1 en tirant partie des
premières années d'expérience
• 1985 début des réflexions sur MERISE version 2
• 1991 création de MERISE version 2
• 1991 début des réflexions sur MERISE version 3 – OOM
• Mi 1991 début d'utilisation d'OOM
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 34

17
 UML et Processus Unifié : historique

Standardisation par l’OMG UML 1.3 Livres:

Guide de l’utilisateur,Manuel de référence
1997, Soumission à l’OMG Guide du processus
UML 1.0 Spécification disponible sur Internet

OOPSLA’96
UML 0.9 Spécification disponible sur Internet

OOPSLA’95 Méthode unifiée 0.8

Booch’93 OMT-2

Autres méthodes Booch’91 OMT-1 OOSE Partenaires

Rumbaugh’91 Jacobson’92 Rational
MSI-B8: 19768 S. SI-SAID CHERFI CNAM-PARIS 35

18