You are on page 1of 15

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