UNIVERSITE CATHOLIQUE DE BUKAVU

(UCB)
B.P. 285 BUKAVU
Faculté des Sciences et Technlogies
Département des Sciences de l’informatique

Méthodes d’analyse informatique 1 (MAI1)

Notes de cours
Abbé Jean-Dominique Uyergiu Kwolonyo, Ass2
Exclusif pour les étudiants B2

2021-2022
EC : Analyse informatique Sommaire - Introduction

Sommaire

I. Code de l’unité d’enseignement (UE)

INF201.

II. Intitulés

- Unité d’enseignement : Analyse, bases et systèmes.

- Elément constitutif : Analyse informatique.

III. Public-cible

Etudiants inscrits en B2 Sciences et technologies.

IV. Nom de l’enseignant

Abbé Jean-Dominique Uyergiu Kwolonyo

V. Objectifs

a. Objectif principal

Amener l’étudiant à acquérir des connaissances de base sur les méthodes utilisées en informatique
pour l’analyse et la conception des systèmes d’information informatisés.

b. Objectifs spécifiques
i. Amener l’étudiant à comprendre les fondamentaux du système organisationnel, celui-ci étant le
cadre par excellence du développement des applications informatiques ;
ii. amener l’étudiant à connaître certaines méthodes de développement des projets informatiques ;
iii. présenter à l’étudiant les principes de la modélisation des données selon la méthode Merise ;
iv. initier l’étudiant aux fondamentaux de la modélisation objet par le langage UML.

VI. Contenu

a. Résumé

L’ère du numérique est caractérisée par l’utilisation à grande échelle des applications logicielles de
tous bords. Comment ces applications sont-elles produites ? Voilà une question à laquelle ce cours
tâchera de répondre, en prescrivant les démarches à suivre pour la production d’une application
logicielle. Et puisque celle-ci est produite dans et pour le système organisationnel, il a fallu, tout
d’abord, se concentrer sur la compréhension dudit système, en en faisant une étude systémique.
Ensuite, il fallait présenter quelques modèles et méthodes de développement logiciel pour, enfin,
mettre en relief deux approches de modélisation informatique, à savoir la méthode Merise et le
B2INF.2021-2022.DSI.FS.UCB ©Abbé Jean-Dominique Uyergiu Kwolonyo, Ass2 Page 1
EC : Analyse informatique Sommaire - Introduction

langage UML (Unified Modeling Language), la première étant une méthode systémique et la
seconde un langage de modélisation orientée objet.

b. Plan

Introduction
Chapitre 1 : Système organisationnel
1.1 La notion de système
1.2 La systémique
1.3 La modélisation systémique de l’organisation.

Chapitre 2 : Des méthodes d’analyse et de conception des systèmes d’information informatisés

2.1 Quelques définitions
2.2 Classification des méthodes
2.3 Différentes méthodes de développement logiciel.

Chapitre 3 : Méthode Merise

3.1 Appellation de la méthode
3.2 Historique de la méthode
3.3 Dimensions de la méthode
3.4 Fondamentaux de la méthode Merise
3.5 Modélisation Merise

Chapitre 4 : Introduction à la modélisation par UML

4.1 Approche orientée objet
4.2 Historique du langage UML
4.3 Fondamentaux du langage UML
4.4 Modélisation par UML.

c. Contexte

i. Cet EC dans le cursus universitaire :

L’EC Analyse informatique est dispensé au niveau baccalauréat (bachelor) ou licence, en
deuxième année (B2/L2), au département des sciences informatiques de la Faculté des Sciences
et technologies.
ii. Il s'agit d'un EC fondamental, à dominance théorique.
iii. Profil et prérequis :
- profil : avoir validé les crédits en B1/B2 et être régulièrement inscrit à l’Université
Catholique de Bukavu.

B2INF.2021-2022.DSI.FS.UCB ©Abbé Jean-Dominique Uyergiu Kwolonyo, Ass2 Page 2

EC : Analyse informatique Sommaire - Introduction

- prérequis : aucun.

VII. Modes et critères d’évaluation

i. Les évaluations se feront systématiquement par écrit (avec ou sans notes) ;

ii. les interrogations, les travaux dirigés (TD) et les travaux pratiques (TP) seront systématiquement
pris en compte dans la note finale ;
iii. les présences feront l’objet d’une sanction positive ; d’où favoriser le plus possible la
participation des étudiants aux cours magistral interactif (CMI), travaux dirigés (TD) et travaux
pratiques (TP) ;
iv. Répartition des notes :
- Contrôle continu (CC : interrogations, TD, TP, etc.) : 50%.
- Examen : 50%.
- Rattrapage : 100%.

VIII. Nombre de credits

4 CECT

IX. Organisation pratique

i. L’enseignement magistral et pratique se fera en présentiel, au campus de Kalambo.

ii. Les travaux pratiques sur machine se feront dans le laboratoire informatique, au campus de
Kalambo.
iii. L’enseignant mettra à la disposition des étudiants un syllabus.
iv. Chaque étudiant sera muni des outils nécessaires pour prendre note (papier, stylo, latte, …).
v. Pour le bon déroulement de l’enseignement, la présence au cours sera obligatoire ; pour ce faire,
une liste de présence sera régulièrement tenue ; la ponctualité et la discipline seront de mise ; la
latitude sera donnée à l’étudiant qui le demande de poser des questions.

X. Bibliographie

- [Bap2009] BAPTISTE J.-L., Merise : Guide pratique. Modélisation des données et des
traitements, langage SQL, ENI Editions, 2009.
- [Boo1998] BOOCH G., RUMBAUGH J. et JACOBSON I., The Unified Modeling Language
User Guide, Addison Wesley, 1998.
- [Cou1997] COURBON, J.-C., Systèmes d’information : structuration, modélisation et
communication, InterEditions, 1997.
- [Dio1994] DIONISI D., L’essentiel sur Merise, Eyrolles, 1994.
- [Div1992] DIVINE M., Parlez-vous Merise ?, Eyrolles, 1992.

B2INF.2021-2022.DSI.FS.UCB ©Abbé Jean-Dominique Uyergiu Kwolonyo, Ass2 Page 3

EC : Analyse informatique Sommaire - Introduction

- [Nan2001] NANCI D. et ESPINASSE B., Ingénierie des systèmes d’information : Merise

deuxième génération, Vuibert Editions, 2001.
- [Roq2009] ROQUES P., UML 2 par la pratique. Etudes de cas et exercices corrigés, Eyrolles,
2009.
- [Roq2007] ROQUES P. et VALLEE F., UML 2 en action. De l’analyse des besoins à la
conception, Eyrolles, 2007.
- [Sou2015] SOUTOU C., Modélisation des bases de données, 3e édition, Eyrolles, 2015
- [Tar1995] TARDIEU H., ROCHFELD A., COLLETI R., PANET G. et VAHEE G., La méthode
Merise. Démarches et pratiques, Tome 2, Editions d’Organisation, 1995.
- [Tar1994] TARDIEU H., ROCHFELD A. et COLLETI R., Méthode Merise. Principes et outils,
Tome 1, Editions d’Organisation, 1994.

B2INF.2021-2022.DSI.FS.UCB ©Abbé Jean-Dominique Uyergiu Kwolonyo, Ass2 Page 4

EC : Analyse informatique Sommaire - Introduction

Introduction

A peine inscrit à l’université, dans la filière des sciences informatiques, les cours ayant commencé, le
jeune étudiant nourrit déjà un certain nombre d’ambitions, parfois démesurées. Est-ce à tort ou à
raison ? Difficile à imaginer.

Ce jeune étudiant s’arroge aussitôt le titre d’ingénieur informaticien, de la même manière que l’étudiant
inscrit en médecine qui souhaiterait qu’il soit honorablement appelé docteur, celui en agronomie
ingénieur agronome, celui en économie économiste et celui en droit maître ou magistrat. Et pourtant il
n’a aucun bagage en ce qui est de la programmation orientée objet, de l’endoscopie, de la pédologie, de
la mathématique financière et du droit des obligations.

En plus, le fait d’avoir emmagasiné un tas de connaissances en programmation ou en base de données

ne justifierait pas l’ambition de développer des applications informatiques ou des logiciels. Quand bien
même l’étudiant en sciences informatiques aurait des connaissances suffisantes pour penser logiciel, le
vrai problème qui se poserait à lui concernerait, à coup sûr, la procédure à suivre pour produire un
logiciel ou une application informatique digne de ce nom. D’où la perpétuelle question de méthode.

En effet, la conception d'un système d'information n'est pas aussi évidente qu’on le pense du moment
qu’elle exige, en amont, qu’il faille réfléchir à l'ensemble de l'organisation que l'on doit mettre en place.
La phase de conception nécessite ainsi des méthodes permettant de mettre en place un modèle sur lequel
on va s'appuyer.

Par ailleurs, face aux problèmes de croissance de la taille et de la complexité des systèmes (car les
besoins et fonctionnalités augmentent ou évoluent, les technologies sont en perpétuelle évolution et les
architectures logicielles sont diversifiées), avec des délais de plus en plus courts et des équipes de plus
en plus grosses, avec des compétences multiples, le recours à une méthode d’analyse et de conception
des systèmes d’information s’avère nécessaire.

Aussi est-il que vers les années 60, un constat a été fait au sujet du développement logiciel. Il y eut une
certaine crise du logiciel. Celle-ci était due non seulement au fait que les délais de livraison des logiciels
n’étaient pas du tout respectés et que le budget ne l’était pas non plus, mais aussi au fait que les logiciels
ne répondaient pas aux besoins des utilisateurs ou des clients et qu’ils devenaient difficiles à utiliser, à
maintenir et à faire évoluer.

B2INF.2021-2022.DSI.FS.UCB ©Abbé Jean-Dominique Uyergiu Kwolonyo, Ass2 Page 5

EC : Analyse informatique Sommaire - Introduction

L’histoire relève également qu’il y a eu des bugs tels que les bugs1 de sonde Mariner 12 en 1962, de
Therac-253 en 1985-1987, du Processeur Pentium4 en 1994, d’Ariane V vol 5015 en 1996 dont les
raisons principales auraient été :
- les erreurs humaines ;
- la taille et la complexité des logiciels ;
- la taille des équipes de conception / développement ;
- le manque de méthodes de conception ;
- la négligence de la phase d’analyse des besoins du client ;
- la négligence et le manque de méthodes et d’outils des phases de validation ou de vérification.

Comment penser que l’on peut commencer à programmer un logiciel alors qu’on en a une idée encore
imprécise ? Comment penser que le travail du logiciel est terminé quand on a un programme écrit et
fonctionnel alors que la maintenance du logiciel à elle seule vaut plus de 50% de son coût total ?
Comment penser qu’il soit facile de gérer les spécifications changeantes alors que les changements de
spécifications sont souvent coûteux ? Comment penser qu’en cas de retard, la solution facile soit
d’ajouter6 des programmeurs alors que la période de familiarisation et la communication plus difficile
entre lesdits programmeurs impliquent la perte de productivité ? Ainsi, pour en finir avec les mythes du
logiciel, l’idée-force demeure sans conteste l’application des méthodes classiques d’ingénierie au
domaine du logiciel.

1
En informatique, un bug (« insecte » en anglais) ou bogue (au Québec et en France) est un défaut de conception d’un
programme informatique à l’origine d’un dysfonctionnement. Ce nom est communément attribué au tout premier incident
informatique qui a été causé par un insecte lors du développement du système Havard Mark II (un ordinateur
éléctromécanique construit à l’Université Havard sous la direction de Howard Aiken.
2
Le programme Mariner est une série de missions spatiales américaines de la NASA ayant pour objectif d’envoyer des
sondes spatiales afin d’étudier les trois planètes intérieures du système solaire, les plus proches de la terre (Mars, Venus et
Mercure). La sonde Mariner 1 a été détruite 5 minutes après son lancement. Son coût était de 18,5 millions de dollars. Sa
destruction était causée par la défaillance des commandes de guidage due à une erreur de spécification et à une erreur de
transcription manuelle d’un symbole mathématique dans la spécification.
3
Therac-25 était le nom d’une machine de radiothérapie développée conjointement par l’Energie atomique du Canada
Limitée et CGR MeV. Entre 1985 et 1987, le Therac-25 fut impliqué dans au moins six accidents durant lesquels des patients
reçurent des doses massives de radiation, parfois de l’ordre de plusieurs centaines de grays. Au moins cinq patients décèdent
des suites de l’irradiation. La cause directe du dysfonctionnement était d’ordre informatique, notamment un problème
d’accès concurrents dans le contrôleur.
4
Il s’agit du bug de la division du Pentium. Ce problème s’est produit seulement sur quelques modèles du processeur
Pentium, notamment dans la table de valeurs utilisée par l’algorithme de division.
5
Le vol 501 est le vol inaugural du lanceur européen Ariane 5, qui a eu lieu le 4 juin 1996. Il s’est soldé par un échec causé
par le dysfonctionnement informatique (bug) qui vit la fusée se briser et exploser en vol seulement 36,7 secondes après le
décollage.
6
« Ajouter des programmeurs à un projet en retard ne fait que le retarder davantage ».

B2INF.2021-2022.DSI.FS.UCB ©Abbé Jean-Dominique Uyergiu Kwolonyo, Ass2 Page 6