Analyse et conception avancé des systèmes

d'information
(d’Outils et Modèles pour le Génie Logiciel)

Enseignant:
Dr. Wahabou K. TABA CHABI

Année 2025/2026
 Programme Pédagogique National
Algorithmique Programmation

Architecture Systèmes Réseaux

ACSI Bases de Données

Mathématiques
OMGL
Économie et Gestion des Organisations

Langues (Anglais) Expression-Communication

… et Projet Personnel et Professionnel, Projets Tutorés, Stage

 Plan
• Définitions
• Cycles de vie du logiciel
• Taxinomie des méthodes d’informatisation
• Démarche
• Modèles
• Méthodes et langages de modélisation

+ Gestion de Projet, Qualité, Interface Homme-

Machine, etc.
Définitions
 Définitions : OMGL
• OMGL = Outils et Modèles pour le Génie Logiciel

• Outil : logiciel supportant une méthode

• Modèle : représentation schématique de la réalité

• Logiciel selon l'arrêté du 22 décembre 1981 : ensemble

des programmes, procédés et règles, et éventuellement
de la documentation, relatifs au fonctionnement d'un
ensemble de traitements de l'information

• Génie Logiciel (ou l'ingénierie des systèmes

d'information) selon l'arrêté du 30 décembre 1983 :
ensemble des activités de conception et de mise en
œuvre des produits et des procédures tendant à
rationaliser la production du logiciel et de son suivi
 Définitions : ACSI
• ACSI = Analyse et Conception des Systèmes
d'Information

• Analyse : processus d'examen de l'existant

• Conception : processus de définition de la

future application informatique

• Systèmes d'Information : ensemble des

moyens (humains et matériels) et des méthodes
se rapportant au traitement de l'information
d'une organisation
 Définitions : BD
• BD = Bases de Données

• Bases de Données [définition des

informaticiens] : ensemble des données
(de l'organisation) structurées et liées
entre elles :
– stocké sur support à accès direct
(disque magnétique)

– géré par un SGBD (Système de Gestion de

Bases de Données)
– accessible par un ensemble d'applications
 Définitions (compléments)
• Informatique : science du traitement
automatique et rationnel de l'information
[académie française, 1966]

• Informatique de Gestion : informatisation des

systèmes d'information

• AGL = Atelier de Génie Logiciel (CASE =

Computer Aided Software Engineering) :
ingénierie du logiciel assisté par ordinateur
 L’information, indispensable dans
le processus de décision d'une
organisation

• Diminution de l'incertitude
• Liberté de choix
• Cohésion de l'organisation
• Évolutivité par rapport à l'environnement
 Qualités requises pour une
information
• Pertinence (mesure la qualité d’une information) :
relation directe entre l’action à accomplir ou la décision à
prendre
– précision : ni trop importante, ni trop faible
– sécurité (pour reconstituer l’information en cas d’accident)
– intégrité (contraintes statiques ou dynamiques)
– confidentialité (protection contre tentatives d’accès)
– non redondance (un seul exemplaire de chaque information)

– Convivialité (qualité de représentation sur support externe et

facilité d’accès par les utilisateurs)
– âge (temps entre enregistrement et sortie des résultats)
– fréquence (nombre de transmissions par unité de temps)

• Cohérence (d’unité, de temps, etc.)

• Rentabilité : coût d’obtention ≤ gain, meilleur service
 Types d'information
• Niveau d'agrégation
– brutes
– élaborées

• Flux
– logistique
– monétaire
– de personnel
– de l'actif

• Utilisation
– planification stratégique
– gestion administrative
– régulation opérationnelle

• Nature du support
– oral
– documentaire
– informatique
•
Définitions : systémique
Analyse systémique : analyse qui envisage les éléments
d'une conformation complexe, les faits (notamment les
faits économiques), non pas isolément mais
globalement, en tant que parties intégrante d'un
ensemble dont les différents composants sont dans une
relation de dépendance réciproque [P.L.I. 2003]

• Neuf niveaux imbriqués de complexité selon cette

théorie : l'objet passif, l'objet actif, l'objet actif régulé,
l'objet s'informe, l'objet décide son activité, l'objet actif a
une mémoire, l'objet actif se coordonne, l'objet actif
imagine (et donc s'auto-organise), l'objet actif
s'auto-finalise
L'organisation correspond au dernier niveau
 Définitions : système
• Système : ensemble d'éléments en
interaction dynamique, dont les éléments
sont organisés et coordonnés en vue
d'atteindre un objectif, qui évolue dans un
environnement
Un système vu comme une « boîte
noire »
Système : de la « boîte noire » à la
« boîte blanche »
Le système se décompose en sous-systèmes dont on
définit les entrées (issues de l'extérieur ou sorties
d'autres sous-systèmes) et les sorties (à destination de
l'extérieur ou devenant les entrées d'autres
sous-systèmes)
Système : de la « boîte noire » à la
« boîte blanche »
Système : de la « boîte noire » à la
« boîte blanche »
Chaque sous-système est lui-même un
système : affinages successifs jusqu'à
l'obtention d'une « boîte blanche »
 Principales difficultés de l’approche
d’un système par décomposition
récursive

• identification du système
• identification des limites du système
• identification des sous-systèmes

• risque de perte engendrée par la

décomposition
• etc.
Définitions : système organisationnel
Définitions : système organisationnel
• Système de Décision (ou pilotage, management, etc.)
– Guide l'organisation vers ses objectifs (activités de planification et de
contrôle) : coordonne, imagine, finalise, élabore objectifs
– Gérer
• Système d'Information
– Intermédiaire entre les systèmes de décision et opérationnel, par qui
transite toute information :
• mémorise l’information (conservation de l'information pour des
besoins ultérieurs),
• traite l’information (rapprochements, calculs, comparaisons),

• fait circuler l’information (accès à la mémoire, échange entre

acteurs)

• Système Opérant (ou logistique, technologique,

physique, de production, etc.)
– Effectue la transformation : reçoit, traite, envoie
– Acheter ; Produire ; Stocker ; Vendre

Remarque : un même employé peut être un acteur de chacun

des trois sous-systèmes
 Rôles du système
d’information
• Produire les informations légales réclamées par
l'environnement

• Déclencher les décisions programmées

• Fournir des informations aux décideurs pour aider à la

prise de décisions non programmées

• Coordonner les tâches en assurant les communications

au sein du système organisationnel
 Connaissances nécessaires
en Informatique de
Gestion
• Science de gestion : mise en place du réseau
d'information et de communication (conception du
système d'information)

• Technique informatique : conception et réalisation du

système informatique pour gérer le système
d'information (conception du logiciel)
 Définitions : système d’information
vs système informatique

• Le système informatique est la partie informatisée du

système d’information automatisable

système d’information

système d’information automatisable

système informatique
 Définitions : système informatique

• Communication
– Système informatique communique directement avec son
environnement (utilisateurs, fichiers d’autres systèmes via
un réseau ou non, etc.)

– Communication entre composants d’une application (ex.

: fichier de mouvement)

• Traitement
– Demandes de traitements issues de l’échange entre le
système informatique et son environnement

– Pilotage des traitements proposés par le système

informatique en gérant les appels aux processus
permettant de les réaliser

• Mémorisation
– Gestion des données par différents modes d’accès (et
stockage aux niveaux logique et physique)
 Enjeux de l’informatisation pour
l'organisation

• Augmenter la productivité en améliorant

l’efficacité des utilisateurs
• Améliorer les conditions de travail :
enrichissement des tâches
• Rendre un meilleur service (de qualité,
rapide, etc.) aux partenaires de
l'organisation
 Facteurs de la complexité de
l'informatisation
• Difficultés techniques de l'informatique : complexité de la mise en
œuvre des matériels, complexité de la construction logicielle,
réflexion abstraite, contraintes techniques
• Constantes novations (matérielle et logicielle)
• Symbiose requise entre l'application informatique et toute
l'organisation (et ses partenaires)
• Multiplicité des décisions et nombreux domaines (humain,
financier, technique, etc.) de l'organisation concernés
 Critères d'un bon système
informatique
• Productivité (en rationalisant le processus
d'informatisation)
– Établissement d'une ligne directrice des informatisations
– Planification et suivi des performances
– Efficacité des études informatiques
– Utilisation judicieuse des technologies

• Qualité
– Conformité de la réalisation par rapport aux besoins
– Documentation correcte
– Adaptabilité
– Fiabilité
– Facilité d'utilisation

• Rentabilité (i.e. gain pour l'organisation relativement au

coût de l'informatisation)
 L'informatique remplit maintenant
un rôle stratégique dans
l'organisation
On est passé de l’automatisation des tâches
administratives aux systèmes d'information d'aide à
la décision (SIAD)

Informatique de production  Informatique de management

• Système opérant • Système décisionnel

• Début années 1960 • Plus récent

• Faible complexité des • Forte complexité des

traitements traitements

• Mise à jour transactionnelles, • Consultation en temps partagé

chaînes séquentielles • Information significative,

• Information précise rapidement disponible
• L3G • SQL
Cycles de vie du logiciel
 Cycle de développement et cycle
de vie du logiciel : les phases

• Analyse
Cycle
• Conception
de Cycle
• Réalisation
développement de
• Tests
vie
• Exploitation
• Maintenance
 Cycles de vie du logiciel
• Analyse de l'existant et définition des
besoins, du système d'information et du
logiciel

• Conception du système d'information et du

logiciel

• Réalisation (ou codage, programmation) :

traduction des algorithmes dans un
langage compréhensible par un ordinateur
 Cycles de vie du logiciel
• Tests :
– vérification du logiciel (i.e. système
informatique)
– validation du logiciel
– vérification du système d'information
– validation du système d'information

Vérification : le produit en cours d’élaboration répond-il à la

définition des besoins ? (est-ce bien le produit ?)

Validation : le produit en cours d’élaboration remplit-il les

fonctionnalités désirées par l'utilisateur ? (est-ce le bon
produit ?)
 Cycles de vie du logiciel
• Exploitation : utilisation du logiciel une fois
installé (et dont on fait la recette)
• Maintenance
– Correction des erreurs
– Amélioration des fonctions existantes
– Ajout de nouvelles fonctionnalités
 Cycles de vie en cascade (ou en
chute d’eau)

Critiques :
– Recouvrement de phases

– Avancées et retours d’une seule phase du cycle de

développement à la fois

– Impact de la maintenance sur toutes les phases du

développement

– Contacts avec l’utilisateur restreints à la phase

d’analyse
 Cycles de développement en V

• Système signifie ici système d'information (manuel et

informatisé)
• Modèle de l'AFCIQ (Association Française pour le
Contrôle Industriel de Qualité) avec le vocabulaire
suivant : Spécification fonctionnelle \ Conception
préliminaire \ Conception détaillée \ Codage / Tests
unitaires / Tests d'intégration / Recette
 Cycles de développement en
M

3 activités interviennent durant toute la durée du

développement en V
– Gestion de projet : pilotage du projet
– Gestion des configurations : gestion des différentes versions du
produit
– Assurance qualité : contrôle systématiquement que le produit en
cours est cohérent et complet, en le confrontant à des normes
préétablies si elles existent
Cycles de développement en W

• Maquette : défilement d'écrans donnant une idée de ce

que sera la future application (sans accès aux données)

• Les maquettes sont élaborées par les informaticiens et

validées par les utilisateurs
• Avantages du maquettage
– Gain de temps sur les phases en aval (2nd V)
– Limitation des erreurs lors de la recette
Cycles de développement en spirale

• Prototype : application en
réduction (avec accès aux
données)

• Expérimentation : tests de la
part des utilisateurs du produit
dans sa version actuelle
(éventuellement définitive)

• Bilan : critique de
l’expérimentation

• Généralisation de l’approche
par itération

• Ex. : conception d’outils de

pilotage (car une forte réactivité
aux besoins non stables des
utilisateurs est nécessaire)
Cycles de développement composite : un
exemple

Démonstration : présentation du produit aux utilisateurs

Cycles de vie de l’ISO
Cycles de vie d’EuroMethode
 Chiffres : coût moyen relatif
de chaque phase (du cycle
de développement du
logiciel) pour une application
de gestion
• Analyse et Conception : 44 %
• Réalisation : 28 %
• Tests : 28 %
Chiffres : coût relatif de correction d'une
erreur selon la phase (du cycle de vie du
logiciel) au cours de laquelle elle a été
détectée

Analyse : 1
Conception : 2
Réalisation : 5
Tests : 10

Exploitation et Maintenance : plus de 100

• Remarque : plus de 80 % des erreurs sont introduites
durant les phases d'analyse et de conception
• Les coûts de la maintenance corrective (ni adaptative,
ni évolutive) peuvent aller jusqu'à deux fois ceux du
développement
Exemple pathologique (système avionique) : coût de
développement de 30$ par instruction mais coût de
maintenance de 4000$ par instruction
Démarche
 Démarche d’une méthode
d'informatisation traditionnelle

• Étude préalable
• Analyse fonctionnelle
• Analyse organique
• Programmation
• Mise en service
 Démarche : 3 premières
étapes
• Étude préalable
– Étude de l’existant → dossier de l’existant validé
– Étude d'opportunité → rapport d'opportunité
→ cahier des charges (et plan directeur de réalisation)

• Analyse fonctionnelle
– Conception (modèles de communication, des
traitements et des données)
– Validation
→ schéma conceptuel

• Analyse organique
– Progiciel ou Développement spécifique
→ solution informatique
 Démarche : étude préalable
(objectif)
• Analyse du fonctionnement de l'organisation et
diagnostic général de l’existant

• Recensement des critiques (positives ou

négatives, d’organisation et informatiques) et
des besoins des utilisateurs

• Opportunité (financement, moyens humains,

etc.) et faisabilité (technique) des
automatisations

• Rédaction d'un cahier des charges

 Démarche : étude de l’existant
(importance)
Toute l'application en dépend 
– exhaustivité
– exactitude
Gravité croissante d'une étude préalable se révélant
incomplète ou inexacte lors de l'analyse fonctionnelle et/ou
organique (peu grave), de la programmation (dommage), de
l’exploitation (catastrophique)
 Démarche : étude de l’existant
(objectif)

■ Description de l'existant (par différentes

représentations littéraires/schématiques et modèles
de communication/traitement/données) en
collectant toutes les informations (informatisées ou
non) utiles et nécessaires
 Démarche : étude de l’existant
(phases)
• Collecte
– Aller sur le terrain
– Observer
– Questionner
– Prendre des notes
– etc.

• Représentation
– Rédiger
– Formaliser les renseignements collectés
– Modéliser
– etc.

• Validation
 Démarche : collecte
• Objectif : recueillir et sélectionner les
informations intéressantes (i.e.
pertinentes) parmi toutes les informations
vues (i.e. observées) ou entendues (via
entretiens)

• Informations à recueillir
– Nature, volume, fréquence, précision
observée ou requise, durée de vie,
ancienneté, etc.

– Exemplaires vierges et renseignés

 Démarche : collecte (critères)
• Informations sur le système actuel et futur
• Informations sur le système ou du système
– Ne recueillir que les informations directement utiles liées à l'étude
• Informations de type
– Dynamique : circulation des documents dans l’espace (ex. : diagramme de
circulation des documents ou de l’information, diagramme de flots de données)
et dans le temps (calendrier, temps des traitements, délai de circulation, etc.)

– De transformation : procédure de traitement, règle de gestion,

enchaînement des tâches, formule de calcul, condition de
déclenchement des traitements

– Statique : données élémentaires (ex. : dictionnaire des données) et documents

(fiches de rubriques/fichiers/documents), services et postes de travail (ex. :
organigramme, fiche de fonction)
• Degré de conscience ou d’expression de l'information
– Collecter les informations exprimées (par écrit ou oralement)
– Détecter les informations conscientes non exprimées
– Deviner les informations inconscientes

– N. B. : selon le cas, faire exprimer/reconnaître les informations non

exprimées ou les laisser dans l'ombre
 Démarche : collecte (moyens)
• À partir de documents (écrits et collectés)
– Documents existants : d’exécution (ex. : facture, bulletin de paye,
bordeaux, fichiers produits, etc.), de gestion (ex. : organigrammes,
statistiques, etc.) ou à établir entièrement
– Documents à compléter (questionnaire)
• Entretien (ou enquête orale)
– Accompagnant des documents écrits (pour les
expliquer/compléter/contrôler/mettre à jour) ou sans document écrit
préalable (avec ou sans la participation de l’interlocuteur)
– Contraignant ou peu directif (selon expérience/aisance de l’analyste)

– Quelques conseils : fixer un rendez-vous, préparer l’entretien, être

ponctuel, préciser l'objectif, questionner, écouter, noter, demander tous
les documents nécessaires, conclure, faire un compte-rendu
• Observation (ou enquête visuelle)
– Après un entretien par exemple

– Qualitative (sur le déroulement d’une procédure d’un poste de travail,

sur la circulation empruntée par un document marqué, etc.) ou
quantitative (ex. : mesurer le nombre de tâches pour une période
donnée, la durée d’exécution d’un travail, etc.)
 Démarche : collecte
(ordonnancement des tâches)
Tâches d'introduction (définition de l’étude)
Tâches d'analyse du présent (recueil de l’existant)
Tâches montrant les contraintes et désirs de l'organisation future (critique)
Tâches de conclusion
4
9
1 2 3 5 6 8 ● 11 12 13 14
10
7

Remarques
– Il existe des tâches séparées dont la collecte est commune, et
inversement une tâche peut nécessiter des collectes séparées

– Avancées ou retour en arrière possibles

– Il ne s'agit que d'un ordonnancement possible

 Démarche : collecte
(ordonnancement des tâches
d'introduction)
1. Prise de connaissance du contexte i.e. de la structure
hiérarchique de l'organisation et de son environnement
social, technique et économique

2. Reformulation des limites de l'étude et du découpage

en projets à partir de ce qui a été décrit ou demandé
 Démarche : collecte
(ordonnancement des tâches
d'analyse du présent)
3. Au niveau du projet retenu, étude de la structure
hiérarchique et liste des postes de travail et des centres de
décision
4. Étude détaillée des postes de travail
5. Établissement d'une liste des fichiers et des documents

6. Représentation de la circulation des documents

mentionnant les traitements

7. Recensement et description des règles de gestion (:=

condition facultative, affectation et règle de calcul), i.e.
les procédures et règles de traitement
8. Confection d'un dictionnaire des rubriques
 Démarche : collecte
(ordonnancement des tâches
montrant les contraintes et désirs de
l'organisation future)

9. Récapitulation des moyens et ressources utilisés et

des contraintes (durée, délai, fréquence, volume, coût,
réglementation, ergonomie)

10. Récapitulation des demandes d'information et des

critiques formulées par le personnel consulté

11. Contrôle du travail effectué i.e. des éléments du

système d'information existant répertoriés au cours de
l'analyse
 Démarche : collecte
(ordonnancement des tâches de
conclusion)
12. Constitution du dossier de l’existant i.e. première
version du cahier des charges détaillé

13. Validation de l'étude auprès des personnes

compétentes et concernées par l'étude

14. Premier examen critique des personnes ayant réalisé

cette analyse mentionnant leurs avis sur l’existant
 Démarche : étude d’opportunité
(objectif)
Faciliter la prise de décision par la direction générale
en commission informatique sur la suite à donner à
l'étude (par un rapport synthétique présentant les
principales critiques formulées et les diverses
solutions envisageables) i.e. la mise en œuvre d'un
certain nombre de projets d'automatisation parmi ceux
proposés
Démarche : étude d’opportunité (critique
du système d'information existant)
• Niveaux : général, des domaines d'étude, des services et
postes de travail
• Causes possibles de dysfonctionnement
– Insuffisance des moyens de traitement de l'information (ex. : en
personnel, matériel, locaux)

– Mauvaise organisation (ex. : centralisation excessive ou

insuffisante, personnel inadapté ou incompétent, mauvaise
structure hiérarchique)

– Circuits informationnels mal étudiés (ex. : trop longs, non

compris)

– Méthodes de traitements mal formalisées ou archaïques (ex. :

inexistence d’algorithme)
– Documents inexistants ou inutiles ou incomplets
– Fichiers inexistants, mal structurés, incomplets, redondants, etc.

• Exposé des besoins nouveaux exprimés par les

utilisateurs
 Démarche : étude d’opportunité
(propositions de solutions)
• Pallier les dysfonctionnements et améliorer le
système
– Solutions non informatisées
• Personnel (ex. : embauche, promotion, déplacement,
formation)

• Matériels (ex. : achat, remplacement, entretien,

déplacement)

• Documents (ex. : création, modification, suppression,

amélioration du circuit)

• Méthodes (ex. : réorganisation des tâches, définition des

algorithmes)
• Fichiers (ex. : création, restructuration)

– Solutions informatisées
• Définition des tâches devant être automatisées

• Découpage en projets d'automatisation homogènes et relativement

indépendants, en faisant apparaître les priorités de réalisation
Démarche : étude d’opportunité (synthèse
des propositions de solutions)
• Évaluation financière (coût estimé et gain escompté) de
chaque proposition

• Présentation de l'ordre des priorités entre les différentes

solutions

• Mesure de la faisabilité et établissement de la mise en œuvre

(en prenant en compte des mesures d’accompagnement :
personnel, matériel, logiciel, etc.) de chaque proposition
 Plan directeur de réalisation
Présentation de toutes les modalités de réalisation
(des programmes d'application spécifiques) :
– responsabilités
– personnel d’exécution
– calendrier de réalisation de chaque projet

– liaisons entre les différents projets (ou logiciels

acquis)

– interventions éventuelles d'informaticiens extérieurs

à l'organisation
 Cahier des charges
• Destinataires
Service informatique, constructeur ou
société de services en informatique
• Objectif
Définir les besoins en matériel et en
logiciel du futur système informatique
(pour permettre de choisir l'une des
solutions) afin d'établir un contrat entre
utilisateurs et informaticiens
 Cahier des
charges
(renseignements informatiques)
• Description détaillée des fonctionnalités
attendues

• Évaluation chiffrée des volumes à mettre en œuvre

– Données à stocker, sauvegarder, saisir, imprimer

– Modes de travaux envisagés : immédiat ou en temps

différé, unitaire ou par lot
Ex. : saisie d’un questionnaire, édition des commandes
du jour, sauvegarde incrémentale, édition
préprogrammée des bulletins de paye

– Nombre maximum d'utilisateurs connectés

simultanément
 Cahier des charges
(renseignements informatiques)
• Définition des besoins en matériel
– Types de postes de travail (bureau, ordinateur, taille écran, type
d’imprimante, etc.)

– Réseau de communication utilisé (privé ou public, en étoile ou en bus ou en

anneau ou … , local ou global, etc.)

– Périphériques particuliers (ex. : lecteur de code à barres)

• Définition des besoins en logiciel

– Progiciels systèmes (système d’exploitation, compilateurs et interpréteurs
des langages de programmation, utilitaires, gestionnaire des données,
gestionnaire réseau, etc.)
– Progiciels d'application
 Cahier des charges (renseignements
technico-commerciaux, avant la livraison)

• Conditions financières des matériels et logiciels : achat, location,

maintenance, etc.

• Conditions d’extension de la configuration matérielle (mémoire

principale, mémoire auxiliaire, périphériques, etc.) et des logiciels
(amélioration des performances, volumes de données, nouvelles
fonctionnalités, etc.), en assurant portabilité et compatibilité

• Conditions d'implantation des matériels (plan, onduleur, climatisation,

puissance électrique, etc.) et logiciels (ex. : système d’exploitation,
mémoire minimale, etc.)

• Conditions d’essais (des performances, sur du matériel équivalent,

etc.)

• Conditions de livraison (délai, pénalités de retard, responsable

du transport du matériel, installation et adaptation, support
logiciel, livraison partielle, etc.)
 Cahier des charges
(renseignements technico-commerciaux,
après la livraison)

• Conditions de maintenance (durée, jour et délai

d’intervention, coût des nouvelles versions, etc.)
• Durée d'utilisation en cas de location

• Formation du personnel (nature, durée, date, coût, lieu, etc.

des stages et cours)

• Aide à la mise en œuvre (durée et périodicité, nombre de

techniciens à disposition, etc.)

• Documentation (nature, coût, nombre d’exemplaires,

nouvelles versions, etc.)
• Conditions de reconversion des applications existantes
 Démarche : analyse fonctionnelle
• Objectif
Obtenir un schéma général de structuration des traitements et des
données, à un niveau conceptuel (c'est-à-dire indépendant de tout
matériel ou logiciel de base)
Quoi faire ?

• Critères d'un schéma conceptuel

– Communicable (avec utilisateurs et autres informaticiens)
– Conforme
– Valide : complet et cohérent
– Réalisable (automatisable en partie)

• Principe d'indépendance des traitements et des données

Pour cela, un logiciel (le SGBD) doit être capable, au moment de
l’exécution des programmes, de retrouver les données nécessaires
aux traitements à effectuer
Indépendance logique (respectivement physique) lorsque le schéma
conceptuel (respectivement logique) des données peut être modifié sans
changer les programmes
 Démarche : conception
• Représentation de la communication au sein de l'organisation
• Représentation de l'ensemble des traitements
– Modélisation des traitements avec leurs conditions d'activation, leurs règles
d'utilisation et de transformation, leur enchaînement, etc.
• Statique : description d'un traitement

• Dynamique : spécification des conditions d’exécution (événement déclencheur) et

d’enchaînement (en séquence, en parallèle, convergent, etc.) de traitements pour
caractériser le comportement du système

• Représentation de l’ensemble des données

– Modélisation de toutes les informations (et de leurs structures) devant être
manipulées (et donc stockées)

– Contraintes d'intégrité : conditions à satisfaire pour les données mémorisées par

le système d'information
• Statique : vérifiées à tout moment

• Dynamique : caractérise la validité des changements d'états du système

d'information
Remarque : certaines contraintes sont déjà inclues dans les modèles
 Démarche : validation
• Validation formelle des traitements et des
données
– Complétude des traitements
• L’ensemble des traitements décrits correspondent à la
définition
– Cohérence des traitements
• Statique : pas de contradiction
• Dynamique : pas d'inter-blocage, terminaison
– Complétude des données
• Pas d'oubli (respect de la norme décrivant le modèle)
– Cohérence des données
• Conformité à la norme : pas d'ambiguïté, pas de
contradiction, pas de redondance,
désagrégation/décomposition
 Démarche : validation
• Synthèse des différents schémas (de
communication, des traitements, des données)
garantissant la cohérence du schéma conceptuel

1. Toute communication s'appuie (si Communication

besoin) sur un traitement
1
2. Tous les traitements assurent les 2
communications de l'organisation
avec son environnement et en son Traitements
sein
3. Aucun traitement ne fait référence à 3
4
une donnée n’existant pas
4. Toutes les données sont manipulées Données
par au moins un traitement
 Démarche : validation
• Confrontation avec les utilisateurs
 Démarche : analyse organique
(objectif)

Adapter la solution fonctionnelle à un choix

technique particulier
– Définition des structures de données et de leur
enregistrement
– Détermination des unités de traitement
– Choix des matériels
– Établissement du calendrier et des budgets de
réalisation
Démarche : progiciel vs développement
spécifique
• Achat d'un progiciel standard (i.e. un PGI)
– Plus économique (à long terme)
– Présent sur de nombreux segments de
marché
– Produit déjà testé
– S'assurer de la réelle adaptation aux besoins
– Complexité du paramétrage
– Peut nécessiter de recourir à un spécialiste
– Existe-t-il un service après-vente, de plus
viable à long terme ?
• Développement spécifique
– Solution parfaitement adaptée aux besoins
– Deux approches : traditionnelle ou génie
logiciel
– Deux étapes
• Étape logique : choix d'organisation (Qui fera quoi ?
Où ? Quand ?)
• Étape physique : choix techniques (Comment :
avec quels moyens matériels et logiciels ?)
 Démarche : approche traditionnelle
• Représentation des traitements
– Étape logique : prise en compte des contraintes des
utilisateurs faisant intervenir le temps (date de début au
plus tôt, date de fin au plus tard, durée, date de début
effective, etc.) et le lieu (communication entre les
acteurs, poste de travail effectuant le traitement,
traitement manuel ou interactif ou différé) des
traitements

■Cas particulier : procédures de fonctionnement en mode

dégradé (données détruites, lieu ou ressource indisponible)

– Étape physique : fait intervenir les contraintes de

ressources nécessaires et utilisées (regroupement de
traitements successifs, éclatement d'un traitement) et
affecter les responsabilités des traitements
 Démarche : approche traditionnelle

• Représentation des données

– Étape logique : prise en compte des
besoins d'utilisation des
informations (ex. : définition des
modes d'accès aux données)
– Étape physique : prise en compte des
contraintes physiques liées en
particulier aux matériels et
logiciels utilisés (ex. : description des
données par rapport à leur
implantation, calculs d'activité afin de
déterminer les
schémas/vues/index/clusters/redonda
nces/etc. les plus efficaces, etc.)
 Démarche : approche traditionnelle
• Structure d'accueil : mémoire,
processeur, réseau, langage, progiciel,
etc.
• Interface homme-machine : ergonomie,
langage de communication
• Méthode de conception : analyse
descendante
• Programmation : programmation objet
(encapsulation, héritage, polymorphisme,
etc.)
• Calendrier
• Budget de programmation
 Démarche : approche génie logiciel
(objectif)

■ Passer à l'ère industrielle de la

production du logiciel, en développant
des méthodes et des techniques
permettant de réaliser à moindre coût
des logiciels performants et fiables
Démarche : approche génie logiciel
• Concevoir (le produit)
– Résultat d'une analyse ou d'une
étude de marché
– Fournir un ensemble de
spécifications détaillées
– Choisir une interface utilisateur :
graphique (on évitera dorénavant
une interface en mode texte)
 Démarche : approche génie logiciel
• Fabriquer
– Principe : décomposer en composants plus simples, et mettre
au point un processus d'assemblage

– Pour chaque composant identifié, trois choix possibles

:
• Utiliser un composant standard : SGF ou SGBD, bibliothèque mathématique,
bibliothèque de classes, applets JAVA, contrôles VBX ou ActiveX, etc.
• Le fabriquer soi-même

• En sous-traiter la fabrication, lorsque les coûts sont trop importants, par

une entreprise spécialisée

– Implémenter les traitements : décomposition modulaire

– Implémenter les données : données transitoires et

permanentes
– Méthode : programmation descendante, objet
 Démarche : approche génie logiciel

– Langage de programmation
• Choix d'un paradigme (ex. : procédural, déclaratif,
fonctionnel, L4G, objet, etc.)

• Identification des besoins : objets, systèmes répartis, bases de

données, systèmes concurrents, etc.

• Identification des moyens : disponibilité du produit sur les

plateformes cibles, personnel formé

– Choix des outils

• Outils de développement rapide : pour du prototypage car les
performances sont souvent insuffisantes

• Générateurs de code : description de haut niveau des

traitements à réaliser, code généré en L3G

• Outils spécialisés : SGBD, gestionnaire réseau, architecture

client/serveur, etc.
 Démarche : approche génie logiciel

• Tester
– Jeux d'essais : jeux de données
couvrant tous les cas possibles,
générateurs de tests
– Simulation du fonctionnement :
injection de données,
brenchmark de systèmes
– Tests en grandeur nature (par les
utilisateurs finals)
 Démarche : approche génie logiciel
• Prouver/Valider
– Méthodes mathématiques de preuve de
programmes (cf. FLOYD, HOARE,
etc.)
– Preuve des spécifications formelles du
logiciel
– Utilisation d'outils de validation
– Vérifier l'adéquation aux besoins
 Démarche : approche génie logiciel
• Évaluer les performances
– Calculs des complexités a priori (et s'assurer que
les charges des machines suffiront)

– Tests en grandeur nature (dans l’environnement

final, dans les conditions réelles d’exploitation)
Démarche : approche génie logiciel
• Assurer la fiabilité
– Plus aucune erreur majeure

– Risque d’erreurs (mineures) résiduelles

(ex. : conditions limites non testées)

– Révisions successives du logiciel (versions

alpha, béta, release, mises à jour mineures et
majeures)
 Démarche : approche génie logiciel

• Fournir une documentation

– Technique
• Durant tout le développement (dossier de programmation) :
communication entre sous-équipes, rédigé quotidiennement par
les développeurs
• Pour la maintenance (guide de maintenance) : recherche
ultérieure des causes d’erreurs
• Pour l’installation (guide d’installation)
– Utilisateur
• Mode d’emploi pour un produit sur mesure (manuel
utilisateur) : précis, technique, sans fioritures
• Communication pour un produit grand public : rédigé par des
professionnels
N. B. : précise, claire, fiable, à jour, etc.
Démarche : approche génie logiciel
• Proposer un service après-vente
– Maintenance sur site, ligne directe,
service payant
– Formation
Modèles
 Modèles : modélisation

• Problème de la réalité : flou, difficile à appréhender, etc.

• Deux types d’erreurs : réalité omise et schéma prenant

en compte davantage que la réalité
• Rarement un seul modèle (union de modèles)
 Modèles : objectifs de la modélisation

• Rendre compte de la réalité

– Conforme
– Complet
– Réalisable
– Plausible

• Simplifier la réalité
• Ne présenter qu’un aspect du problème

• Permettre de mieux comprendre un problème

complexe
• Permettre de communiquer les connaissances
– Standard
– Précis
– Simple
– Cohérent
 Modèles : outils et types

• Outils
– Langage naturel
– Représentation graphique
– Mathématiques
• Types de modèles
– De communication, des traitements ou de données
– Statique ou dynamique
 Modèles : l’exemple « jouet »
• Les traitements
– Le jour de la rentrée, le secrétariat de
l’établissement avise les étudiants qu'ils ont
jusqu’à la fin de la semaine pour amener les
originaux des diplômes qu'ils ont obtenus, ceci
permettant de compléter les fiches des étudiants

– Un mois après la rentrée, le secrétariat

transmet une photocopie des fiches au
directeur de l’établissement

• Un fichier ( … de cinq étudiants)

Modèles : l’exemple « jouet »
Modèles : l’exemple « jouet »
 Modèles : l’exemple « jouet »

• Problème des zones variables (zéro, une ou

plusieurs valeurs) engendrant des difficultés de
stockage efficace
– Ex. : les voitures des étudiants

• Problème de redondance
– Ex. : intitulé complet des diplômes
 Quelques modèles
• Actigramme
• Algèbre relationnelle
• Arbre de décomposition fonctionnel
• Calcul relationnel
• Cycle de vie d'un objet
• Datagramme
• Diagramme d’activités
• Diagramme d’états-transitions
• Diagramme d’objets
• Diagramme de cas d’utilisation
• Diagramme de circulation de l'information
• Diagramme de circulation des documents
• Diagramme de classes
• Diagramme de collaboration
• Diagramme de communication
• Diagramme de composants
• Diagramme de déploiement
• Diagramme de flots de données
 Quelques modèles
• Diagramme de flots d'événements entre classes
• Diagramme de flots d'événements entre objets
• Diagramme de séquence
• Diagramme de structure
• Diagramme de structures composites
• Diagramme de suivi d'événements
• Diagramme de temps
• Diagramme des paquetages
• Diagramme d'états (structuré)
• Diagramme global d'interaction
• Fiche de description de fonction
• Fiches de description de document
• Fiches de description de fichier
• Fiches de description de rubrique
• Graphe acteurs-flux
• Grille d'analyse des rubriques
• Logique des propositions et des prédicats
• Machine abstraite
 Quelques modèles
• Modèle conceptuel des traitements
• Modèle conceptuel des traitements analytique
• Modèle de flux (modèle de contexte, modèle de
flux conceptuel, modèle de flux organisationnel)
• Modèle dynamique
• Modèle entités-associations (ou modèle
conceptuel des données)
• Modèle fonctionnel
• Modèle logique des données
• Modèle logique des données réparties
• Modèle logique des traitements (guidage
fonctionnel, interface utilisateur (présentation,
dialogue), noyau applicatif non interactif)
• Modèle logique des traitements répartis
• Modèle navigationnel
• Modèle objet
• Modèle organisationnel des données
• Modèle organisationnel des traitements
• Modèle organisationnel des traitements analytique
• Modèle relationnel
 Quelques modèles

• Organigramme
• Réseaux de Pétri
• Schéma d'architecture logique des moyens
informatiques
• SQL
• Substitution généralisée
• Table de décision
• Théorie des ensembles et relations
Méthodes et langages de
modélisation

MERISE/2
SADT
OMT
UML
B