Méthodologies de

conception des SI

Objectif du cours

Beaucoup de raisons pour étudier et

s’intéresser aux Systèmes d’Information (SI)

 Utiliser intensivement les SI existants

 Analyser des SI existants et identifier leurs forces
et faiblesses
 Emettre des recommandations d’amélioration
et/ou de modifications
 Proposer, participer à la conception et réalisation
de nouveaux SI
Information

Le bon fonctionnement d'une organisation, voire sa
survie, est conditionné par la mise en place d'une
communication cohérente et fluide :
 entre ses différentes composantes

 avec son environnement externe

L'essence de cette communication est l'information

Cette information n'est utile que si elle est exploitée et
mise à disposition de façon optimale

Or,
 augmentation du volume d'informations à traiter

 complexité croissante de la communication dans les

organisations

Système d’Information

Nécessaire pour gérer cette ressource

stratégique qu'est devenue l'information

Composante indissociable des organisations
« le système d'information suppose
l'organisation et celle-ci ne fonctionne pas
sans lui » ( J.L. Peaucelle )

Le SI d’une entreprise est l’ensemble des
données et des traitements qui sont
nécessaires et suffisants à son
fonctionnement
Information et donnée

Donnée: Signe+ code

Elle peut être numérique, alphanumérique, ….
Exemple : 71540325

Information: donnée +interprétation

Exemple : C’est un numéro de téléphone

L’information peut-être interprétée par un être
humain et elle apporte alors de la connaissance
Exemple : ce numéro correspond à un abonné de
Tunis

Évolution des applications de gestion

60-80
 stockage et restitution d'informations
 structures plates (fichier, ligne de table)
 traitement simple (mise à jour et édition de données)

80- ..
 objets complexes (texte, graphiques, images)
 traitements plus élaborés (tableau de bord, système expert,
statistiques)
 intégration (bureautique, multimédia, web)

Les méthodes de conception doivent évoluer
Cycle de vie du logiciel

Cycle de développement du logiciel

Plusieurs catégories de modèles ou de méthodes

ont été proposés pour décrire le cycle de
développement du logiciel

Les modèles définissent des étapes clairement
identifiables et censées correspondre à
l’achèvement d’une partie du travail

Catégories de modèles
 Code and fix
 Linéaire
 Itératif
Code and Fix

Approche chaotique (coder,
tester et réparer)

Code devient rapidement
déstructuré, très difficile à
comprendre, modifier, gérer, etc

Correspond en réalité à
l’absence de modèle

Ne peut plus s’appliquer aux
projets post années 70
 Taille, complexité, spécifications
changeantes

Crise du logiciel

Catégorie linéaire

Processus logiciel bien défini et inclut

souvent des procédures détaillées suivies
plus ou moins de façon périodique

L’analyse des besoins et la conception sont
identifiées, passées en revue, et acceptées

Modèle en cascade, V
Modèle en cascade (Années 65-75)
Waterfall Model…

Modèle qui permet de
définir les principales étapes
du processus logiciel

Les activités sont
représentées dans des
processus séparés
 Après chaque étape un
délivrable est produit et on
passe à la prochaine étape

Originalement ce modèle fut
proposé de façon linéaire
sans «backtracking»
 Ceci est un objectif difficile à
atteindre

Modèle en cascade (Années 65-75)

Waterfall Model…

Étude de faisabilité
 Définir le problème, définir et étudier les alternatives, définir les
coûts et les délais

Analyse des besoins et spécifications
 Définir les attendus du système, aboutir à un document de
spécification lisible, précis, complet, consistant et non ambigu
 Aboutir aux besoins fonctionnels et non fonctionnels

Conception architecturale
 Définir les modules qui constituent le système et leurs relations
 Selon le contexte, la conception détaillée correspond à:

Définir les interfaces utilisateurs

Définir les types, les algorithmes
 Modèle en cascade (Années 65-75)
Waterfall Model…

Codage et test unitaire
 Écriture du code source, test des modules séparément par rapport à la
conception architecturale

Intégration et Test système
 Assembler les modules (gérer les versions)
 Tester le système

Test de régression

Alpha testing: Mettre l’application entre les mains d’utilisateurs
compréhensifs

Beta testing: Élargir la base des utilisateurs

Mise en exploitation et maintenance
 Le système est installé sur site à large diffusion. On distingue 3 sortes de
maintenance

Maintenance corrective

Maintenance adaptative

Maintenance perfective

Modèle en cascade
avantages et inconvénients

Bien adapté pour des petits systèmes

Mal adapté à des systèmes complexes
(processus de développement rarement
séquentiel)

Les tests s'appliquent à l'application globale
(pas de validation des besoins)

Difficulté de définir tous les besoins dés le
début du projet

Délai assez long pour voir quelque chose
Modèle en V
V Model

Variante du modèle en cascade

Modèle en V
avantages et inconvénients

Tests bien structurés

Hiérarchisation du système à développer
permettant une conception et un
développement modulaire

Validation par rapport aux besoins

Validation ou le test de réception trop tardifs
– très coûteux si des erreurs sont constatées
Catégorie Itérative

Processus logiciel bien défini et inclut souvent les

procédures détaillées qu'on s'attend à ce que des
réalisateurs appliquent d'une façon itérative

Les exigences peuvent être définies avec un niveau

d’abstraction élevé et affiné tout au long du processus

Les modèles de cette catégorie sont:
 Prototypage
 Spirale
 Entreprise Unified Process (EUP)
 Rational Unified Process (RUP)
 2 TUP

Modèle prototypage
Je saurai ce que je veux lorsque je le verrai!

Un prototype initiale peut évoluer jusqu’à avoir le système
définitif

Utilisé pour comprendre les besoins de l’utilisateur

Son but est de s’assurer de la faisabilité et vérifier les exigences

Le produit est reconstruit en tenant compte du feed-back de
l’utilisateur

Une nouvelle version est développée en utilisant le modèle en
cascade
 Évolutif

Plusieurs prototypes sont développés (avec minimum de
fonctionnalités)

Seul le prototype retenu par l’usager est évolué en un produit final
Modèle prototypage
avantages et inconvénients

Validation des besoins très tôt dans le processus

Validation concrète et sûre par les utilisateurs

Forte implication des utilisateurs

Bonne compréhension du système par les
développeurs

Ne convient que pour
 les projets qui peuvent être découpés en sous systèmes
 les applications dans lesquelles l’interface utilisateur est
prépondérante

Coût pourrait être élevé

RUP

S’applique sur des moyens et grands projets (>10 employés)

Basé sur le langage UML

RUP est piloté par les cas d’utilisation
 RUP saisit les besoins fonctionnels à travers les cas d’utilisations
qui ne sont pas un simple outil de spécification des besoins mais
guident tout le processus de développement et en garantissent la
cohérence

RUP est centré sur l’architecture
 L’architecture permet de réaliser les besoins exprimés par les
utilisateurs à travers les cas d’utilisation qui guident tout le
processus de développement

RUP est itératif et incrémental
 Les itérations se succèdent dans un ordre logique pour prendre
en compte les cas d’utilisation et traiter en priorité les risques
majeurs et les problèmes imprévus
 Classes de méthodes de
conception

Les différentes classes de méthodes de

conception

Approches cartésiennes (première
génération)

Approches systémiques (deuxième
génération)

Approches objet (troisième génération)
Les approches cartésiennes

Approche cartésienne classique:

décomposition d'un problème en sous-
problèmes

Méthodes d'analyse fonctionnelles
 décomposition d'une fonction en sous-fonctions
jusqu'à atteindre un niveau facile à coder

Méthodes: méthodes de programmation
structurée, SADT, Jackson, Yourdon

Les approches cartésiennes

suite

Points forts:
 simplicité et bon sens
 adéquation à capturer les besoins des utilisateurs
 capacité à produire des solutions à plusieurs
niveaux d'abstraction

Points faibles:
 effort sur les fonctions au détriment des données
 règles de décomposition non explicites
 difficile de faire de la réutilisation
Les approches systémiques

Approche inspirée d'une vision systémique

SI = structure + comportement

Modélisation des données et des traitements

Méthodes: Merise, Information Engineering

Les approches systémiques

suite

Points forts:
 grande cohérence des données
 niveaux d'abstraction bien définis

niveau conceptuel, niveau logique ,niveau physique

Points faibles:
 manque de cohérence entre données et
traitements
 faiblesse de la modélisation des traitements,
mélange des contraintes et des contrôles
Les approches objet

Évolution de l'approche systémique vers une

plus grande cohérence entre les objets et
leurs comportements

Vision du SI comme un ensemble d'objets
avec leurs opérations

Méthodes: OMT, OOD, OOSE, Unified
Software

Development Process (UML)

Les approches objet

suite

Points forts:
 capacité à modéliser des objets complexes
 réduire les distorsions entre système informatique
et monde réel
 intégration des traitements aux données
 encapsulation

Points faibles
 "tout objet" difficile à appréhender
 aspect fonctionnel mal représenté
 aspect procédural des opérations
Approche cartésienne
vs approche objet

Approche cartésienne: approche
descendante par décomposition de fonctions

Approche objet: approche ascendante par
composition d'objets

Approche systémique
vs approche objet

Basées sur les mêmes concepts

Approche systémique
 Les langages de modélisation pour les données
et les traitements sont incompatibles
 Faut-il commencer par les données ou les
traitements?

Approche objet
 nouveau paradigme
 Réunir les traitements et les données dans la
même unité, objet