INTRODUCTION GENERALE
0.1. CHOIX ET INTERET DU
SUJET
0.1.1. CHOIX DU SUJET
L'irruption massive de la micro-informatique dans les
entreprises et organismes à partir du début des années 80
a radicalement et irrévocablement changé la nature du travail de
production et de soutien à celle-ci.
Dès lors, apparait son caractère universel, la
micro-informatique implique l'existence des méthodes, techniques et
procédures de la gestion rationnelle et efficace des ressources
humaines, financières temporelles et matérielles. Ceci s'inscrit
dans la partie de « l'informatique de gestion »1(*).
Ainsi les progrès technologiques apportés par
cette dernière, n'épargnent pas la gestion d'affectation des
sujets de TFC et MEMOIRE aux étudiants, c'est alors que nous avons
porté notre choix sur la mise en place d'un logiciel applicatif pour la
gestion d'affectation de sujets de TFC et MEMOIRE aux étudiants du
département d'informatique de gestion cas de l'ISP/MBUJIMAYI.
0.1.2. INTERET DU SUJET
Ce travail a un triple intérêt à
savoir : l'intérêt personnel, social et scientifique.
a) Intérêt
personnel : ce travail nous a permis de mettre en pratique
la théorie apprise pendant les quatre années d'études en
informatique de gestion,
b) Intérêt
social : ce travail pourra tant soit peu aider le
comité de gestion de l'ISP/MBUJIMAYI (Système de pilotage)
d'informatiser la gestion des travaux de fin de cycle TFC en sigle et
mémoires aux étudiants au niveau de leurs départements
respectifs (système opérant).
c) Intérêt
scientifique : ce travail sera un miroir pour tout
chercheur qui voudra pousser dans la mesure du possible ses connaissances dans
le même sens que nous.
0.2. PROBLEMATIQUE
La gestion des affectations de sujets de TFC et MEMOIRE aux
étudiants est un processus qui nécessite le stockage des
informations de ces derniers d'une manière permanente, actuellement
cette opération d'affectation et d'archivage des sujets est manuelle.
Cette manière de gérer est source des multiples erreurs et
difficultés entre autres :
v Le retard dans la transmission des rapports administratifs
ou autres documents à la hiérarchie vu le nombre exorbitant des
étudiants concernés,
v Perte du temps mis dans la recherche des archives relatives
à une affectation considérée;
v Risque de perte des données lié à une
mauvaise conservation du support;
v Risques d'affecter le même sujet à deux ou
plusieurs étudiants sans s'en rendre compte ou sans que les cinq ans
soient écoulés;
Nous qualifions ces problèmes de non adaptation aux
nouvelles technologies de l'information et communication
« NTIC » en sigle. Et cherchant d'en savoir plus, nous
rattachons notre problématique autour des questions suivantes :
Ø Quelle technique faut-il mettre en place au
département d'informatique de gestion dans la gestion des sujets de
TFC et MEMOIRE adaptée à la nouvelle
technologie de l'information et communication?
Ø Est-il possible d'implémenter le
système d'information de l'ISP/MBUJIMAYI dans la gestion des TFC et
mémoire au niveau du département d'informatique de gestion? si
oui, comment ?
0.3. HYPOTHESE
D'une manière générale,
l'hypothèse est une réponse provisoire ou anticipée aux
questions soulevées dans la problématique, réponses qui
seront soit confirmées soit infirmées, soit nuancées
à l'issue de l'analyse des données récoltées sur
terrain.2(*)En guise de
réponses provisoires aux questions ci-haut posées, il semble
que :
- Pour adapter la gestion des sujets de TFC et MEMOIRE des
étudiants aux nouvelles technologies de l'information et de
communication, il faudra implémenter un système d'information
informatisé;
- Oui, en concevant une application informatique capable de
répondre à cette question sur base d'un SGBD.
0.4. DELIMITATION DU
SUJET
Pour la délimitation de notre travail dans le temps,
nous avons opté pour la période allant de 2017 à 2019 donc
deux années académiques (2017-2018) et (2018-2019). Et dans
l'espace nous avons choisi le département d'informatique de gestion de
l'ISP/MBUJIMAYI.
0.5. METHODES UTILISEES
Dans l'élaboration de ce travail, nous avons recouru
à ces méthodes :
u Structuro-Fonctionnelle : Qui
nous a permis d'étudier la structure fonctionnelle de l'ISP/MBM,
de ses sections et surtout de son département d'informatique de
gestion;
u La méthode OMT (Object
Modeling Technique ou Technique de modélisation objet en
français) : Qui est une méthode d'analyse informatique qui
nous a permis de modéliser les données de notre recherche pour
concevoir une application informatique.
0.6. TECHNIQUES UTILISEES
Dans la collecte de données nécessaires à
l'élaboration de notre travail, nous avons recouru aux techniques de
recherche ci-après :
· Technique documentaire et
· Technique d'interview libre
0.7. DIFFICULTES
RENCONTREES
Au cours de notre recherche, plusieurs difficultés ont
été rencontrées dont les plus pertinentes sont :
ü L'insuffisance de la documentation dans nos
bibliothèques en rapport avec notre sujet d'étude ;
ü L'indisponibilité des responsables pouvant nous
fournir des informations.
Pour contourner ces difficultés, nous avons fait
recours à l'internet.
0.8. CANEVAS DU TRAVAIL
Dans sa structure, ce travail comprend quatre chapitres, outre
l'introduction et la conclusion générale
· Le premier chapitre est consacré à la
définition des concepts de base ;
· Le deuxième parle sur l'étude du
système d'information cas de l'ISP/MBUJIMAYI ;
· Le troisième est sur la
modélisation et
· Le dernier présente la réalisation de
l'application.
CHAPITRE I :
CONSIDERATIONS THEORIQUES
1.1. NOTIONS DE BASE DE
DONNEES
INTRODUCTION
Les données constituent des ressources
organisationnelles cruciales qu'il faut gérer comme des actifs
importants d'une entreprise4(*). Ainsi les organisations et leurs gestionnaires
doivent gérer ces données avec toute prudence.
1.1.1. DEFINITION DE LA BASE DES
DONNEES
La base des données en abrégé BD ou DB
pour Data Base en Anglais, est un ensemble structuré de données
apparentées qui modélisent un univers réel5(*). C'est aussi un ensemble de
données structurées non répétitives
enregistrées sur un support accessible par les utilisateurs pour
répondre à leurs besoins.
1.1.2. MISE A JOUR D'UNE BASE DE
DONNEES
Il faut constamment mettre à jour les bases des
données d'une organisation afin de refléter les opérations
récentes et les autres activités. On doit encore apporter divers
changements en vue d'assurer l'exactitude des données. La mise à
jour d'une base de données s'effectue avec des programmes de traitement
transactionnel et d'autres progiciels d'application individuels, avec l'aide du
SGBD.
1.1.3. LES DIFFERENTS TYPES DE
BASES DE DONNEES5(*)
La croissance de l'informatique distribuée, de
l'informatique de l'utilisateur finale, des systèmes d'information pour
dirigeants et les systèmes d'aide à la décision a
entrainé la création de plusieurs grands types de base de
données du point de vu utilisateur tels que :
a) Bases de données
opérationnelles
Elles stockent les données détaillées
afin de soutenir les opérations de toute l'organisation.
Exemples : Base de données sur la
clientèle, Base de données sur le personnel, Base de
données sur les stocks, et d'autres bases de données qui
contiennent des données relatives aux différentes
activités d'une entreprise.
b) Bases de données de la
direction
Elles stockent des données et de l'information
extraites de certaines bases de données opérationnelles et
externes choisies. Elles contiennent des données et des informations
résumées, absolument nécessaires pour les dirigeants de
l'organisation et pour d'autres utilisateurs. On les appelle aussi
« bases de données de
renseignement ». Elles aident à faciliter le
processus décisionnel de la direction.
c) Les bases entrepôts de
données
Un entrepôt de données stocke les données
de l'année en cours ou des années précédentes
provenant de diverses bases de données opérationnelles et de la
direction. Il s'agit d'une source centrale de données qui a
été normalisée et intégrée de façon
à ce que les cadres et les autres utilisateurs de l'organisation
puissent s'en servir.
d) Les bases de données
distribuées
Ce sont des bases de données qui comprennent des
segments de bases de données opérationnelles et individuelles
communes ainsi que des données créées et utilisées
seulement sur le lieu de travail de l'utilisateur final. Donc ce sont des bases
de données de succursales.
e) Bases de données
individuelles
Elles constituent en une variété de fichiers mis
au point par les utilisateurs à leur poste de travail.
f) Les banques de données
Ensemble de données relatives à un domaine
défini de connaissances et organisé pour être offert aux
consultations d'utilisateurs6(*)
1.2. APPLICATION
INFORMATIQUE
a) Définition
Une application informatique est un programme permettant
d'exécuter une tâche précise.
b) Mise en place d'une application
informatique
La mise en place d'une application informatique est
l'installation d'une application sur un environnement (système
d'exploitation), quelconque pour s'adapter à son utilisation.
1.3. FORMULAIRE7(*)
Un formulaire est un objet de base de données que l'on
peut utiliser pour créer l'interface utilisateur d'une application de
base de données. On peut parler de :
v D'un formulaire
« lié » : Qui est un
formulaire connecté directement à une source de données
telle qu'une table ou une requête. Ce formulaire peut servir à
entrer, modifier et afficher des données à partir de cette source
de données.
v D'un formulaire
« indépendant » : qui ne se
connecte pas directement à une source de données, mais qui
contient néanmoins des boutons de connecter des étiquettes et
autres contrôles dont on a besoin pour faire fonctionner une
application.
Un formulaire efficace permet d'accélérer
l'utilisation d'une base de données dans la mesure où les
utilisateurs n'ont pas besoin de rechercher les éléments dont ils
ont besoin et il permet également d'éviter la saisie de
données incorrectes.
1.4. REQUETES
Une requête vise à obtenir des résultats
de données, à effectuer une action sur des données, ou les
deux à la fois. On peut utiliser une requêtes dans le but
d'obtenir une réponse à une question simple, d'effectuer des
calculs ; de combiner les données de différentes tables, ou
encore d'ajouter, modifier ou supprimer des données de la table.
Par le biais d'une requête, on peut assembler les
données à utiliser avant de concevoir un formulaire ou un
Etat.
1.5. ETATS
1.5.1. Définition
Un état est un objet de base de données qui sert
à afficher et synthétiser des données.
1.5.2. Importance
L'état permet de distribuer ou archiver une capture
instantanée des données en étant imprimé, converti
ou format de fichier PDF ou XPS ou exporté dans d'autres formats de
fichier.
CHAPITRE II : ETUDE DU
SYSTEME D'INFORMATION
2.1. ANALYSE DE
L'EXISTANT
Dans cette partie du travail, nous allons présenter
notre cadre de recherche, elle nous donnera la possibilité de
présenter l'institut Supérieur pédagogique de Mbujimayi
comme notre cadre choisi, et de décrire les différents documents
pour arriver à une image globale de système d'information de
l'organisation. En effet, l'objet poursuivi par cette étude n'est pas
seulement de présenter l'ISP/MBUJIMAYI, mais aussi critiquer le
système existant, et faire le choix de la meilleure solution pouvant
ainsi améliorer les conditions de travail au département
d'informatique de gestion.
2.1.1. PRESENTATION DE
L'ISP/MBUJIMAYI
a) HISTORIQUE
Sous l'appellation de l'école Normale moyenne, ENM en
sigle, et à l'initiative de Monseigneur NKONGOLO, évêque
du diocèse de Mbujimayi, l'ISP/MBUJIMAYI fut créé en 1986.
Cette création se situe dans le cadre du plan gouvernemental
d'expression des instituts supérieurs pédagogiques. Les
différentes dates qui ont marqué les moments remarquables de la
création de l'institut supérieur pédagogique de Mbujimayi
sont :
Ø Le 05 Novembre 1968, pour sa lettre END/SR/02-1532,
le gouvernement central notifia son accord au pouvoir organisateur ;
Ø Le 05 Novembre 1970, soit après deux ans de
fonctionnement, l'ISP/MBUJIMAYI fut créé
définitivement ;
Ø Le 06 Aout 1971, par l'ordonnance loi
présidentielle n°17/075, l'institut supérieur
pédagogique de Mbujimayi fut avec l'ensemble des instituts
supérieurs pédagogiques, intégré au sein de
l'université nationale du Zaïre.
b) SITUATION GEOGRAPHIQUE
L'ISP/MBUJIMAYI sis avenue Cathédrale n°86 au
Quartier KASHALA BONZOLA dans la commune de la KANSHI, ville de Mbujimayi dans
la province du Kasaï-Oriental. Il est limité à l'Est par
l'institut Saint Jean Baptiste, au sud par le collège Episcopal Saint
Pierre DIBUE DIA BUAKANA), à l'Ouest par le camp de Prof, au nord par
l'institut national de préparation professionnelle.
c) OBJECTIFS SOCIAUX
Les objectifs de l'ISP/MBUJIMAYI sont précisés
dans l'article 2 de l'ordonnance loi n°71/252 du 11 septembre 1971
relative à l'organisation des instituts supérieurs
pédagogiques :
- La formation de maitres destinés à enseigner
dans les classes inférieures de l'enseignement secondaire (jusqu'en
4ème année y compris) ;
- Le perfectionnement des maitres, des inspecteurs de
l'enseignement primaire et secondaire ;
- La promotion d'études et de la recherche dans le
domaine de la pédagogie appliquée ;
De nos jours tous les instituts supérieurs
pédagogiques ont pour mission :
u La formation des enseignants gradués et
licenciés (si le cycle de licence est organisé au sein de
l'institut) aux qualités morales et pédagogiques
éprouvées ;
u La formation de tous les enseignants du secondaire pour les
disciplines que l'institut organise ;
u La recherche dans les domaines de la
pédagogie ;
u La vulgarisation des résultats de ces recherches par
la rédaction et la diffusion de manuels scolaires.
a) ORGANIGRAMME FONCTIONNEL DE L'ISP
MBUJIMAYI
SECRETARIAT GENERAL ACADEMIQUE
COMITE DE GESTION
DIRECTION GENERALE
SECRETARIAT GENERAL ADMINISTRATIF
ADMINISTRATION DU BUDGET
CONSEIL D'INSTITUT
Schémas 1 : l'organigramme
fonctionnel de l'ISP/MBUJIMAYI
b) ORGANIGRAMME FONCTIONNEL DE L'ISP
MBUJIMAYI
SECRETAIRE DE DEPARTEMENT
CHEF DE DEPARTEMENT
DEPARTEMENT D'ORIENTATION SCOLAIRE
PROFESSIONNELLE
DEPARTEMENT DE GESTION ET INFORMATIQUE
CHEF DE SECTION ADJOINT CHARGE DE LA
PEDAGOGIQUE
APPARITEUR SECTION
CHEF DE SECTIONCONSEIL DE L'INSTITUT
SECRRETAIRE SECTION
DEPARTEMENT DE SCIENCES COMMERCIALES ET
ADMINISTRATIVES
DEPARTEMENT DE GESTION DES ENTREPRISES
CHEF DE DEPARTEMENT
SECRETAIRE DE DEPARTEMENT
CHEF DE SECTION ADJOINT CHARGE DE LA
RECHERCHE
Schéma 2 : L'organigramme fonctionnel de la section
commerciale-informatique et celui du département d'informatique de
gestion
c) ETUDES DES POSTES
0. Conseil de l'institut
Il exécute la politique académique et
scientifique de l'institut supérieur pédagogique de Mbujimayi. Il
fait des propositions sur le développement des activités
scientifiques de l'ISP/MBUJIMAYI.
1. Comité de gestion
Il assure la gestion courante de l'institut sous la direction
du chef d'établissement et à ce titre, il exécute les
décisions du département, de la recherche scientifiqueet du
conseil de sections de l'ISP/MBM et prend toutes les mesures qui ne
relèvent pas de la compétence d'un autre organe.
2. Directeur
général
Il préside le conseil de l'institut pédagogique
et le comité de gestion, au respect du statut et règlement de
l'ISP/MBM. Il supervise et coordonne l'ensemble des activités de
l'institut à ce titre.
3. Secrétariat
Académique
Le secrétariat général académique
est membre du comité de gestion. Il supervise et coordonne les
activités des services relevant de son ressort.
4. Du secrétaire général
Administratif
Le secrétaire général administratif est
membre du comité de gestion d'un établissement.
5. Administration du budget
L'administration du budget est membre du conseil de gestion.
En tant que tel, il se charge de la gestion budgétaire quotidienne,
financière et des activités d'autofinancement.
2.1.2. EXPLOITATION DES SOURCES
D'INFORMATION
Les documents tenus au département d'informatique de
gestion pour l'affectation des sujets de TFC et mémoires aux
étudiants sont :
· La fiche de proposition des sujets et
· La fiche de sujets retenus et les preuves de paiement
de la fiche de proposition
2.1.2.1. DESCRIPTION DES
DOCUMENTS
Cette description consiste à préciser les
documents essentiels utilisés dans le traitement des sujets au
département d'informatique de gestion. Pour de raison de synthèse
les documents retenus dans cette études sont : Fiche de proposition
des sujets, fiche des sujets retenus et la pièce justificative.
|
N°
|
CODE
|
DESIGNATION
|
SERVICES TRAVERSES
|
UTILITE
|
|
PROVENANCE
|
RECEPTION
|
DESTINATION
|
|
01
|
FIPRO
|
Fiche de proposition des sujets
|
Caisse
|
Etudiant
|
Chef de département
|
Une fiche sur laquelle on inscrit deux ou trois sujets au
choix
|
|
02
|
FSR
|
Fiche des sujets retenus
|
Secrétaire du département
|
Etudiant
|
Secrétaire du département
|
Une fiche sur laquelle on reprend tous les sujets des
étudiants retenus selon leur promotion et vacation
|
|
03
|
REC
|
Reçu
|
Caisse
|
Etudiant
|
Chef de département
|
Document prouvant le paiement de la fiche de proposition des
sujets
|
Tableau 1 : Données du
Secrétariat du département d'informatique de gestion.
2.1.2.2. DESCRIPTION DES
RUBRIQUES
|
N°
|
CODE
|
DESIGNATION
|
NATURE
|
TAILLE
|
DOCUMENTS
|
OBSRVATION
|
OPERATION
|
|
FIPRO
|
FSR
|
REC
|
|
1
|
NomEtudiant
|
Nom Etudiant
|
Alph.
|
20
|
X
|
X
|
X
|
Le nom de l'étudiant
|
|
|
2
|
Promo
|
Promotion
|
alphNum.
|
2
|
X
|
X
|
X
|
La promotion de l'étudiant
|
|
|
3
|
Vac
|
Vacation
|
Alph.
|
5
|
X
|
X
|
X
|
La vacation de l'étudiant soir ou jour.
|
|
|
4
|
Date
|
Date
|
Date/heure
|
10
|
X
|
X
|
X
|
La date à laquelle l'étudiant a payé le
reçu
|
|
|
5
|
Mont
|
Montant
|
Num.
|
10
|
X
|
-
|
X
|
Le montant payé pour la fiche de proposition
|
|
|
6
|
Mot
|
Motif
|
Alph.
|
30
|
-
|
-
|
X
|
Le motif pour lequel on a payé le reçu
|
|
|
7
|
SUPRO
|
Sujets proposés
|
Alph.
|
400
|
X
|
-
|
-
|
Sujet proposé
|
|
|
8
|
Suret
|
Sujet retenu
|
Alph.
|
400
|
-
|
X
|
-
|
Sujet retenu
|
|
|
9
|
DIR
|
Directeur
|
Alph.
|
25
|
X
|
X
|
-
|
Le nom du directeur de l'étudiant
|
|
Tableau 2 : différentes rubriques
des documents du secrétariat du département d'informatique de
gestion
2.1.2.3. ANALYSE DE FLUX
D'INFORMATIONS
L'analyse de flux d'informations consiste à mettre en
évidence la circulation des informations au sein du système.
Pour ce faire, dans cette partie nous allons présenter le diagramme de
flux d'informations et le schéma de circulation des informations.
A. Le Diagramme de flux
d'information
Etudiant
Caisse
Secrétaire du département
Chef du département
Section
Secrétariat Académique
1
2 4
12
5 3
6 11
7
10
8
9
Schéma 3 : La circulation des
informations au département d'informatique de gestion
LEGENDE :
1. L'étudiant paie la fiche de proposition des sujets
à la caisse ;
2. La caisse lui remet le reçu ;
3. L'étudiant présente le reçu au
secrétaire du département ;
4. Le secrétaire lui donne la fiche de
proposition ;
5. L'étudiant propose deux ou trois sujets et remet la
fiche au secrétaire ;
6. Le secrétaire présente la fiche des sujets
proposés au chef du département ;
7. Le chef du département propose le sujet retenu
à la section ;
8. La section propose le sujet à
l'académique ;
9. Le secrétariat académique étudie et
restitue le sujet à la section ;
10. La section remet au département ;
11. Après le chef du département donne le sujet
retenu au secrétaire ;
12. Le secrétaire informe le sujet retenu à
l'étudiant avec le nom de son Directeur.
B. Le schéma de circulation des
informations
Parler du schéma de circulation, sous-entend le
détail des processus ci-haut énumérés en utilisant
des symboles pour formaliser la circulation des informations dans l'affectation
des sujets de TFC et MEMOIRE aux étudiants. Nous présentons ainsi
quelques symboles que nous utiliserons dans ce schéma.
LIBELLE POSTE
N°
:
Représente un poste, son numéro ainsi que son libellé.
LI LIBELLE
OPERATIONS
N°
:
Représente une tâche avec son numéro, ainsi que les
opérations les opérations
effectuées à cette tâche d'un poste.
CODE DOCUMENT
: Un document
circulant en un seul exemplaire
CODE
: Un document
non circulant ou en position
N°
: La provenance
d'une tâche, opération ou document
N°
: La destination
d'une information
: La base des
données
: Information verbale ou
orale adressée à un poste quelconque
: L'archivage d'un
document.
2.1.2.4. SCHEMA DE
CIRCULATION D'INFORMATIONS
|
ETUDIANTS 100
|
CAISSE 200
|
SECRETAIRE 300
|
CHEF DE DEPARTEMENT 400
|
201
101
102
201
102
301
302
401
|
- Réception de la fiche de proposition
- Etude des sujets proposés
- Communication du sujet retenu au secrétaire
|
|
|
|
Reçu
301
Reçu
101
102
Reçu
Fiche
501
402
502
403
302
Fiche
403
Réception de la fiche et remise au
secrétaire
302
- Fiche
401
102
Communication du sujet retenu à l'étudiant
|
|
|
|
|
SECTION COMMERCIALE-INFORMATIQUE 500
|
SECRETARIAT ACADEMIQUE 600
|
601
Fiche
402
501
601
502
Réception de la fiche et remise au
département
501
601
502
Fiche
601
Réception de la fiche et remise à la section
Fiche
403
Schéma 4 : le flux d'informations
au département d'informatique de gestion avant
2.1.2.5. MOYENS DE
TRAITEMENT DES INFORMATIONS
Ici nous essayerons de présenter les moyens
matériels et humains utilisés au département
d'informatique de gestion.
A. Moyens humains
|
N°
|
SERVICE
|
PERSONNE
|
SEXE
|
NIVEAU D'ETUDE
|
|
01
|
Département
|
Chef de département
|
M
|
L2
|
|
02
|
Secrétariat du département
|
Secrétaire
|
M
|
L2
|
Tableau 3 : les moyens humains qui
dirigent le département d'informatique de gestion
B. Moyens matériels
|
N°
|
POSTE
|
FOURNITURE
|
MATERIELS
|
|
Electronique
|
Marque
|
Date acquisition
|
Etat
|
|
01
|
Chef de département
|
Table, papier, stylo, registre, latte, etc...
|
Ordinateur
|
HP
|
-
|
Bon
|
|
02
|
Secrétaire
|
Table, papier, stylo, tous les horaires de cours, programmes
nationaux, etc...
|
Ordinateur
|
DEL
|
-
|
Bon
|
Tableau4 : les matériels servant au
département de bien travailler
2.2. CRITIQUE DE
L'EXISTANT
Ici, nous essayerons de critiquer le système de
gestion des sujets de recherche au département d'informatique de
gestion, pas dans le mauvais sens, mais dans un esprit de suggérer des
solutions techniques et adéquates dans la gestion :
u Sur le plan matériel : le département
d'informatique de gestion dispose d'un outil informatique de bonne
qualité, mais non utilisé selon les règles de la
gestion ;
u Sur le plan organisationnel : l'information ne circule
pas selon les règles établies ;
u Sur le plan de gestion : Malgré que ce
département soit géré par des qualifiés en
informatique, mais on n'y trouve pas l'application de gestion d'affectation des
sujets de TFC et mémoires, il n'y a même pas de petites
applications de gestion qui puissent gérer la petite
bibliothèque composée des TFC et Mémoires
déjà publiés.
Ces trois points énumérés nous poussent
à proposer l'informatisation sans réorganisation.
Ainsi, voici le nouveau schéma de circulation :
|
ETUDIANTS 100
|
CAISSE 200
|
SECRETAIRE 300
|
CHEF DE DEPARTEMENT 400
|
201
101
102
201
102
301
302
401
|
- Réception de la fiche de proposition
- Etude des sujets proposés
- Communication du sujet retenu au secrétaire
|
|
|
|
Reçu
301
Reçu
101
Reçu
102
Fiche
501
402
502
403
302
Fiche
Réception de la fiche et remise au
secrétaire
|
|
|
|
|
102
- Proposition des sujets sur la fiche
- Transmission de la fiche au secrétaire.
|
302- Récupération des sujets
proposés
- Vérification dans l'ordinateur pour voir s'il y a
coïncidence des sujets
- Transmission de la fiche au chef de département
- Enregistrement de l'étudiant et du sujet retenu dans
l'ordinateur
- Communication du sujet retenu à l'étudiant et
prise de sa photo.
|
302
Fiche
401
|
|
|
SECTION COMMERCIALE-INFORMATIQUE 500
|
SECRETARIAT ACADEMIQUE 600
|
601
Fiche
402
501
601
502
Réception de la fiche et remise au
département
501
601
Réception de la fiche et remise à la section
502
Fiche
Fiche
403
Schéma 5 : le flux d'information
au département d'informatique après
CHAPITRE 3 :
MODELISATION SOUS OMT
3.1. INTRODUCTION
La programmation classique ou procédurale telle que
connu par débutant à travers des langages
de programmation comme pascal, C, etc...., traite les programmes comme un
ensemble des données sur lesquelles agissent des
procédures.8(*)
Cette manière de concevoir les programmes reste proche
des machines de Von Neumann et consiste en dernier ressort à traiter
indépendamment les données et les algorithmes sans tenir compte
des relations qui les lient.
En introduisant la notion de modularité dans la
programmation structurée descendante, l'approche diffère
légèrement de l'approche habituelle de la programmation
algorithmique classique.
La programmation orientée objet relève d'une
conception ascendante définie comme des « messages »
échangés par des entités de base appelées
objets.
3.2. LA MODELISATION
La modélisation consiste à établir un
modèle qui décrit un objet naturel9(*).
Dans ce travail, cette modélisation sera
focalisée sur la méthode OMT à partir de ses trois
modèles qui sont :
a) Modèle statique
b) Modèle dynamique et
c) Modèle fonctionnel.
3.2.1. MODELE STATIQUE
Etant une extension du modèle
Entité-Association, ce modèle introduit la notion de :
l'agrégation, la généralisation, la spécification
d'opérations et les contraintes au niveau des entités ici
nommées « classes objets »
La construction de ce modèle, consiste à
identifier les classes d'objets, préparer le dictionnaire des
données pour déterminer les associations entre classes et les
propriétés de celle-ci.
3.2.1.1. IDENTIFICATION DES
CLASSES D'OBJETS
Une classe est une sorte de moule ou de matrice à
partir duquel sont engendrés les objets réels. Elle contient des
attributs et des méthodes.
Voici les classes que nous avons retenues dans notre
travail :
v ETUDIANTS_JOUR
v ETUDIANTS_SOIR
v DIRECTEUR
3.2.1.2. ELABORATION DU
DICTIONNAIRE DES DONNEES
Le dictionnaire des données selon OMT consiste à
définir les classes d'objets retenues, à donner le rôle de
chacune d'elles et à préciser toutes les informations
liées à celles-ci dans une gestion d'affectation des sujets de
TFC et MEMOIRE aux étudiants.
Voici notre dictionnaire des données
|
ETUDIANTS_JOUR
|
C'est une table représentant les sujets retenus pour
les étudiants de la vacation jour. L'étudiant peut consulter un
et un seul directeur.
|
|
ETUDIANTS_SOIR
|
: C'est une table représentant les sujets retenus pour
les étudiants de la vacation soir. L'étudiant peut consulter un
et un seul directeur.
|
|
DIRECTEUR
|
Une personne qui doit diriger le travail ou mémoire de
l'étudiant du jour ou soir, le directeur peut diriger un ou plusieurs
étudiants.
|
Tableau 5 : le dictionnaire reprenant
les classes principales de notre base de données
3.2.1.3. IDENTIFICATION DES
ASSOCIATIONS ENTRE CLASSES
Une association est une relation entre deux instances de deux
ou plusieurs classes décrivant un groupe de liens avec une structure et
une sémantique. De ce fait, à partir de notre dictionnaire des
données, nous aurons les associations suivantes :
1) ETUDIANTS_JOUR CONSULTER
DIRECTEUR
2) ETUDIANTS_SOIR CONSULTER
DIRECTEUR
3) DIRECTEUR DIRIGER
ETUDIANTS_JOUR
4) DIRECTEUR DIRIGER
ETUDIANTS_SOIR
Schéma 6 : identification des
associations entre les classes
3.2.1.4. DETERMINATION DE LA
MULTIPLICITE
La multiplicité est le nombre d'objet (Min, Max) qui
participer à une relation avec un autre objet dans le cadre d'une
association.
Les multiplicités fréquentes sont :
· 0...1 = optionnel (mais pas multiple)
· 1 = exactement 1
· 0...* = quelconque
· 1...* = au moins 1
Pour déterminer les multiplicités dans notre
projet ; nous avons fait recours aux règles de gestion
présentées dans ce tableau :
|
N°
|
CLASSES
|
RELATION
|
REGLE DE GESTION
|
Multiplicité
|
|
SOURCE
|
BUT
|
|
01
|
DIRECTEUR
|
ETUDIANTS_SOIR ; ETUDIANTS_JOUR
|
DIRIGER
|
Un directeur peut diriger un ou plusieurs étudiants
à la fois.
|
1..*
|
|
02
|
ETUDIANTS_SOIR
|
DIRECTEUR
|
Consulter
|
Un étudiant du soir peut consulter un et un seul
directeur.
|
1...1
|
|
03
|
ETUDIANTS_SOIR
|
DIRECTEUR
|
Consulter
|
Un étudiant du jour peut consulter un et un seul
directeur.
|
1...1
|
Tableau 6 : les multiplicités
déterminées sur base de nos classes
3.2.1.5. IDENTIFICATION DES
ATTRIBUTS D'OBJETS
ETUDIANTS_JOUR
*NumEtudiant
NomEtudiant
PostnomEtudiant
Promotion
AnneeAcad
SujetRetenu
Domaine
Directeur
Ajouter
Modifier
Supprimer
3.2.1.5.1. MODELE D'OBJET
INITIAL AVEC ATTRIBUTS, METHODES ET MULTIPLICITES
ETUDIANTS_SOIR
*NumEtudiant
NomEtudiant
PostnomEtudiant
Promotion
AnneeAcad
SujetRetenu
Domaine
Directeur
Ajouter
Modifier
Supprimer
Diriger1
Diriger2
DIRECTEUR
*NumDirecteur
NomDirecteur
PostnomDirecteur
PrenomDirecteur
Niveau
Grade
Domaine
Etudiantdirige
Ajouter
Modifier
Supprimer
Consulter1
Consulter2
Schéma 7 : le premier modèle
reprenant les classes et leurs attributs
3.2.1.5.2. RAFFINAGE EN
UTILISANT L'HERITAGE ET L'AGREGATION
Dans un langage orienté objet, il existe une
particularité dans la façon d'organiser ses classes :
l'héritage de propriétés. L'objectif est de construire de
nouvelles classes en réutilisant des attributs et des méthodes de
classes déjà existantes. L'héritage est un
mécanisme très puissant qui permet de décrire des
structures génériques en transmettant depuis l'intérieur
d'une même classe toutes les propriétés communes à
toutes les « sous-classes » de cette classe.
Par construction, toutes les sous-classes possèdent tous
les attributs de leur classe parent.
Voici alors le nouveau modèle dynamique :
ETUDIANTS_JOUR
ETUDIANTS_SOIR
DIRECTEUR
*NumDirecteur
NomDirecteur
PostnomDir
PrenomDir
Niveau
Grade
Domaine
Etudiantdirige
Ajouter
Modifier
Supprimer
ETUDIANTS
*NumEtudiant
NomEtudiant
PostnomEtudiant
Vacation
Promotion
AnneeAcad
SujetRetenu
Domaine
Directeur
Ajouter
Modifier
Supprimer
Diriger
CONSULTER
Schéma 8 : le modèle
raffiné reprenant les classes retenues et leurs attributs
3.2.1.6. QUANTIFICATION DU
DIAGRAMME D'OBJET
La quantification consiste à exprimer en termes de
volume mémoire la capacité de la base de données qui sera
implantée sur ase des informations de la recherche et de la description
de rubriques. C'est ainsi que nous avons estimé la capacité et le
coût total de l'application de la manière suivante :
a) Table ETUDIANTS
|
N°
|
PROPRIETES
|
TYPE
|
TAILLE
|
NOMBRE D'OCCURRENCES
|
VOLUME
|
|
1
|
NumEtudiant
|
N
|
4
|
2000
|
8000
|
|
2
|
NomEtudiant
|
C
|
7
|
2000
|
14000
|
|
3
|
PostnomEtudiant
|
C
|
7
|
2000
|
14000
|
|
4
|
PrenomEtudiant
|
C
|
7
|
2000
|
14000
|
|
5
|
Vacation
|
C
|
4
|
2000
|
8000
|
|
6
|
Promotion
|
AlphNum
|
2
|
2000
|
4000
|
|
7
|
AnnéeAcad
|
N
|
4
|
1500
|
6000
|
|
8
|
SujetRetenu
|
C
|
400
|
2000
|
800000
|
|
9
|
Directeur
|
C
|
20
|
2000
|
40000
|
|
10
|
Domaine
|
C
|
20
|
2000
|
40000
|
|
TOTAL DES CLASSES
|
948000
|
Tableau 7 : Diagramme d'objet
quantifiant les données de classe ETUDIANTS
b) Table DIRECTEUR
|
N°
|
PROPRIETES
|
TYPE
|
TAILLE
|
NOMBRE D'OCCURRENCES
|
VOLUME
|
|
1
|
NumDirecteur
|
N
|
4
|
2000
|
8000
|
|
2
|
NomDirecteur
|
C
|
7
|
2000
|
14000
|
|
3
|
PostnomDir
|
C
|
7
|
2000
|
14000
|
|
4
|
PrenomDir
|
C
|
7
|
2000
|
14000
|
|
5
|
Niveau
|
alphNum.
|
2
|
2000
|
4000
|
|
6
|
Grade
|
C
|
7
|
1500
|
10500
|
|
7
|
Domaine
|
C
|
20
|
2000
|
40000
|
|
8
|
Etudiantdirige
|
C
|
20
|
2000
|
40000
|
|
TOTAL DES CLASSES
|
144500
|
Tableau 8 : diagramme d'objet
quantifiant les données de la troisième classe
Après l'analyse, voici notre proposition des outils de
développement de cette application :
1. Un Ordinateur : ayant comme disque dur de 500 Go, OS
(Windows 7, 8, 10)
2. Office : 2010
3. SGBD : Access 2010
4. Une Imprimante : Laser 1132
5. Ondulaires
Soit un montant de 850 $ reparti comme suit :
v Ordinateur : 350 $
v Imprimante : 250$
v Ondulaires : 200 $
v Récolte des données : saisies, impression du
rapport de recherche : 50 $
3.2.2. MODELE DYNAMIQUE
Le modèle dynamique montre le comportement du
système en réponse aux externes. Il indique le contexte et
l'enchainement des opérations responsables de l'évolution. Il ne
prend pas en compte la façon dont les opérations sont
réalisées, ni sur quoi elles agissent.
L'importance de ce modèle dépend du type de
l'application étudiée.
Un ensemble de diagrammes, des scénarios représente
ce modèle. Il est à noter que dans ce travail, les principaux
événements sont issus des clics de souris réalisés
par l'utilisateur.
Le scénario permet d'identifier les
événements et à réaliser les diagrammes
d'états. Il est défini comme une séquence
d'événements qui se produit lors d'une exécution du
système.
3.2.2.1. IDENTIFICATION DES
EVENEMENTS
Pour représenter l'identification des
événements, nous avons fait recours à la méthode de
REMORA qui décrit le trois grandes parties constituant structurellement
un objet à savoir10(*) :
v Un événement
v Un attribut (objet) et
v Une opération
Un événement est une action qui se produit à
un moment donné dans le temps.
Voici le schéma illustrant ce formalisme :
Objet
Opération
Evénement
Schéma 9 : le modèle type
d'identification des événements
1) Classe d'objet : ETUDIANTS
NumEtudiant
Validation
Enter
NomEtudiant
Validation
Enter
PostnomEtudiant
Validation
Enter
PrenomEtudiant
Validation
Enter
Vacation
Validation
Enter
Promotion
Validation
Enter
AnneeAcad
Validation
Enter
SujetRetenu
Validation
Enter
Domaine
Validation
Enter
Directeur
ON
Import : NumEtudiant
Import : NomEtudiant
Import : PostnomEtudiant
Import : PrenomEtudiant
Import : Vacation
Import : Promotion
Import : AnneeAcad
Import : SujetRetenu
Import : Domaine
Import : Directeur
Afficher : NumEtudiant
Afficher : NomEtudiant
Afficher : PostnomEtudiant
Afficher : PrenomEtudiant
Afficher : Vacation
Afficher : Promotion
Afficher : AnneeAcad
Afficher : SujetRetenu
Afficher : Domaine
Afficher : Directeur
Schémas 10 : identification des
événements de la première classe
SujetRetenu
Validation
Enter
2) Classe d'objet : DIRECTEUR
NumDirecteur
Validation
Enter
NomDirecteur
Validation
Enter
PostnomDir
Validation
Enter
PrenomDirecteur
Validation
Enter
Niveau
Validation
Enter
Grade
Validation
Enter
Domaine
Validation
Enter
Etudiantdirige
ON
Import : NumDirecteur
Import : NomDirecteur
Import : PostnomDir
Import : PrenomDir
Import : Niveau
Import : Grade
Import : Domaine
Import : Etudiantdirige
Afficher : NumDirecteur
Afficher : NomDirecteur
Afficher : PostnomDir
Afficher : PrenomDir
Afficher : Niveau
Afficher : Grade
Afficher : Domaine
Afficher : Etudiantdirige
Schéma 11 : identification
des événements de la troisième classe
3.2.2.2. LES DIAGRAMMES
D'ETAT ET LES SCENARIOS
A. MENU PRINCIPAL
SOUS/SYSTEME
SOUS/SYSTEME
MENU PRINCIPAL
OBJET EVENEMENT OPERATION
|
Saisie de données
|
ON CLICK
|
Ouverture du Menu Principal
|
|
Consultation de données
|
ON CLICK
|
Ouverture du Menu consultation
|
|
Impression de données
|
ON CLICK
|
Ouverture du Menu impression
|
|
Quitter l'application
|
ON CLICK
|
Quitter l'application
|
|
|
|
Schéma 13 : le diagramme
d'état et les scénarios du menu principal
B. SAISIE DE DONNEES DES
ETUDIANTS
SOUS/SYSTEME
SOUS/SYSTEME
MENU PRINCIPAL
OBJET EVENEMENT OPERATION
|
NumEtudiant
|
ON Enter
|
Validation
|
|
NomEtudiant
|
ON Enter
|
Validation
|
|
PostnomEtudiant
|
ON Enter
|
Validation
|
|
PrenomEtudiant
|
ON Enter
|
Validation
|
|
Vacation
|
ON Enter
|
Validation
|
|
Promotion
|
ON Enter
|
Validation
|
|
AnneeAcad
|
ON Enter
|
Validation
|
|
SujetRetenu
|
ON Enter
|
Validation
|
|
Directeur
|
ON Enter
|
Validation
|
|
Domaine
|
ON Enter
|
Validation
|
|
|
|
|
ON CLICK
|
Importation /Affichage
|
|
Ajouter
|
ON CLICK
|
Ajouter un enregistrement
|
|
Premier
|
ON CLICK
|
Passer au premier enregistrement
|
|
Suivant
|
|
|
|
ON CLICK
|
Passer à l'enregistrement suivant
|
|
Précédent
|
ON CLICK
|
Passer à l'enregistrement
précédent
|
|
Supprimer
|
ON CLICK
|
supprimer unenregistrement
|
|
Fermer
|
ON CLICK
|
Retour au menu principal
|
|
|
|
Schéma 14 : le diagramme
d'état et les scénarios de la première classe
C. SAISIE DES DONNEES DE
DIRECTEUR
MENU PRINCIPAL
SOUS/SYSTEME
SOUS/SYSTEME
OBJET EVENEMENT OPERATION
|
NumDirecteur
|
ON Enter
|
Validation
|
|
NomDirecteur
|
ON Enter
|
Validation
|
|
PostnomDir
|
ON Enter
|
Validation
|
|
PrenomDir
|
ON Enter
|
Validation
|
|
Niveau
|
ON Enter
|
Validation
|
|
Grade
|
ON Enter
|
Validation
|
|
Domaine
|
ON Enter
|
Validation
|
|
|
|
|
Etudiantdirige
|
ON Enter
|
Validation
|
|
Ajouter
|
ON CLICK
|
Ajouter un enregistrement
|
|
Premier
|
ON CLICK
|
Passer au premier enregistrement
|
|
Suivant
|
ON CLICK
|
Passer à l'enregistrement suivant
|
|
Précédent
|
ON CLICK
|
Passer à l'enregistrement
précédent
|
|
|
|
|
Supprimer
|
ON CLICK
|
supprimer unenregistrement
|
|
Fermer
|
ON CLICK
|
Retour au menu principal
|
|
|
|
Schéma 15: le diagramme
d'état et les scénarios de la troisième classe
3.2.2.3. MODULE DE
TRAITEMENT
Ce module consiste à transformer les valeurs des
données et représenter la mutation du traitement d'un
système informatique d'entreprise. Ici, notre module est l'affectation
du sujet à l'étudiant :
Module SujetRetenu - NumEtudiant + NomEtudiant +
PrenomEtudiant + Promotion + Sujet + Directeur
Concaténation
SujetRetenu?
NumEtudiant+NomEtudiant+PrenomEtudiant+Promotion+Sujet+Directeur
Schémas 16 : le module de
traitement
3.2.2.4. DIAGRAMME A FLOT
DE DONNEES
C'est une décomposition du système en processus
qui s'opèrent sans les données et donne chaque détail aux
processus élémentaires du système.
Ici nous allons représenter graphiquement le
modèle fonctionnel montrant les dépendances entre les valeurs
entrées et les valeurs de modèles sorties sans
considération du moment de l'exécution même de la
fonction.
Saisie
Traitement
Impression
Identification complète de l'étudiant
Liste de déclaration.
Identification du directeur
Liste des Directeurs
Et des
étudiants
Schéma 17 : le
diagramme à flot de données
CHAPITRE 4 :
REALISATION DE L'APPLICATION
4.0. INTRODUCTION
Toute oeuvre humaine qui ne produit pas de fruit n'est que
perte du temps. Comme nous vous avions déjà
présenté dans tous les chapitres précédents qui
n'étaient que l'ombre de ce que nous allons réaliser maintenant,
nous connaissons déjà le nouveau système d'information,
nous avons encore pris connaissance des matériels à utiliser pour
la mise au point de notre application. Dans ce chapitre, nous allons passer
à la visualisation de différentes interfaces qui font parties de
l'application et qui seront à chaque fois devant l'utilisateur final.
4.1. CHOIX DU LOGICIEL
Dans le cadre de notre travail nous avons fait recours
à l'ACCESS pour la réalisation de notre application.
4.2. CRÉATION DE LA
BASE DE DONNÉES VIDE
La procédure pour créer la base de
données vide en Access est la suivante :
v Lancer le MS Office ACCESS
v Clic sur l'icône « BASE DES DONNEES
VIDE » ;
v Nommer la BD ;
v Cliquer sur le bouton
« CRÉER » ;
Ainsi notre base de données nous l'avons
renommée : « GESTION DES TFC ET
MÉMOIRES »
Figure 1 : création de la
base des données vierge
4.3. STRUCTURATION D'UNE
BASE DE DONNÉES
4.3.1. CRÉATION DES
TABLES
La table est le premier objet de la base de données
qui nous permet de stocker les données. L'une des procédures de
la création d'une table est la suivante :11(*)
u Clic sur l'onglet « CRÉER » de la
barre de menu ;
u Clic sur l'outil « CREATION DE
TABLE » ;
u Une fenêtre permettant de définir les champs en
précisant le nom du champ et le type de données qu'il contient
ainsi leur taille ;
u Clic sur le bouton office puis
« ENREGISTRER » ;
u Dans la fenêtre « ENREGISTRER
SOUS », donner le nom de la table et cliquer OK.
Figure 2 : présentation de la
table en mode création
NB. Toutes les tables ont été créées
de la même manière.
4.3.2. CRÉATION DES
RELATIONS ENTRE LES TABLES
Après un clic sur « OUTILS DE BASE DES
DONNEES » puis sur « RELATIONS », et
après, l'application de l'intégrité
référentielle.
4.2.4. CRÉATION DES
FORMULAIRES12(*)
Voici la procédure de création :
ü Clic sur « CRÉER »,
ü Clic sur « ASSISTANT
FORMULAIRE »
ü Choisir la table concernée ;
ü Sélectionner et ajouter les champs disponibles,
ü Clic sur « SUIVANT »
ü Définir le nom du formulaire
ü Clic sur « TERMINER » et le
formulaire s'affiche en mode formulaire. S'il faut modifier, il faut l'ouvrir
en mode création comme suit :
Figure 3 : un formulaire en mode
création
4.3.5. LE FORMULAIRE LOGIN
Figure 4 : un formulaire en mode
formulaire
4.3.6. LES REQUÊTES13(*)
L'une des procédures de créations des
requêtes est la suivante :
· Ouvrir la base de données ;
· Cliquer sur
« CRÉER » ;
· Clic sur « CREATION DE
REQUETES » ;
· Dans la boite de dialogue « AFFICHER LA
TABLE » cliquez y puis fermer ;
· Placer ses différents champs dans la grille de
requête puis exécuter.
CONCLUSION GENERALE
Nous voici à la fin de notre travail scientifique, le
fruit de nos recherches dans l'apprentissage au premier cycle de notre passage
dans cette institution notre Alma mateur ISP.MBUJIMAYI.
Ici nous avons passé en revue tout ce que nous avons
dû apprendre jusqu'ici par rapport à notre recherche, en essayant
d'étaler, les différents moyens humains et matériels
envisagés.
Ainsi dans nos analyses, grâce à la
méthode organisationnelle de traitement (OMT), nous nous sommes vus
arrivés à concevoir (solution proposée) une application
permettant de traiter d'une façon automatique les informations au niveau
du département d'informatique de gestion ; ceci dans la gestion des
TFC et Mémoires en passant par différentes étapes telles
que :
- L'étude du système existant ;
- La modélisation selon OMT et
- La réalisation de l'application en question.
Pour tout dire, nous disons que l'informatique reste encore
une science de grandes recherches mondiales et nous encourageons tout chercheur
sincère de pouvoir dans la mesure du possible poursuivre ses recherches
dans le souci d'améliorer ce qui existe déjà car nous
venons au monde pas pour le laisser comme nous l'avons trouvé mais le
laisser au moins amélioré.
BIBLIOGRAPHIES
I. OUVRAGES
- James A. O'Brien, Guy Marion & Gilles S. A.,
Système d'information de gestion, édition 2015
- Georges G., Base de données objet relationnel,
Eyrolles, 2ème édition 2000
- Philippe Rigaux, Cours de la BD, 1966/2000,
- Bernard Espinasse, Présentation de la
méthode Objet : OMT, Université d'Aix Marseille, 2011,
P. 560-570
- IUT de Nice, inédit
- Robert Michel Discal, Base de
l'informatique-Programmation, édition 2005
II. NOTES DE
COURS
- Robert TSHIABUILA, K., Technique de gestion de base des
données, G3 IG/ISP/MBM/SOIR/2018
- Ben KABOKALA, Informatique générale, G1
IG/ISP/SOIR/2015
- Laurent MAMBA, Progiciel, G4 IG/ISP/SOIR/2019
- Sylvain MUTOMBO, Méthode d'analyse informatique
II, G4 IG/ISP/SOIR/2018
- Prof Dominique TSHIENKE K., Initiation à la
recherche scientifique, G2 IG/ISP/SOIR/2017
III. TRAVAUX DE FIN DE
CYCLE
- Roger MIKUWA, I., Mise en place d'une application pour
l'enregistrement des clients au RCCM, ISP/MBM, 2018
- Jeanny DIKASA, M., Conception et réalisation d'une
application de gestion des chambres dans un Hôtel (cas de
Métropole du Kasaï), ISP/MBUJIMAYI, 2018
- Jacques NGOY KIBAMBE, gestion de la trésorerie (cas
de la REGIDESO), ISTIA, 2008
- Mbangie NKOLE Benith, inédit
IV. WEBOGRAPHIE
-
www.Commentçamarche.net
-
http//fr.wikibooks.org/w/index.php ?title=programmation-Visual
Table des matières
INTRODUCTION GENERALE
Erreur ! Signet non
défini.
0.1. CHOIX ET
INTERET DU SUJET
1
0.1.1. CHOIX DU
SUJET
1
0.1.2. INTERET DU
SUJET
1
0.2.
PROBLEMATIQUE
2
0.3.
HYPOTHESE
2
0.4. DELIMITATION DU
SUJET
3
0.5. METHODES
UTILISEES
3
0.6. TECHNIQUES
UTILISEES
3
0.7. DIFFICULTES
RENCONTREES
3
0.8. CANEVAS DU
TRAVAIL
4
CHAPITRE I : CONSIDERATIONS THEORIQUES
5
1.1. NOTIONS DE BASE
DE DONNEES
5
1.1.1.
INTRODUCTION
5
1.1.2.
DEFINITION DE LA BASE DES DONNEES
5
1.1.3.
MISE A JOUR D'UNE BASE DE DONNEES
5
1.1.4.
LES DIFFERENTS TYPES DE BASES DE DONNEES
5
1.2.
APPLICATION INFORMATIQUE
7
1.3.
FORMULAIRE
7
1.4.
REQUETES
7
1.5.
ETATS
8
CHAPITRE II : ETUDE DU SYSTEME
D'INFORMATION
9
2.1. ANALYSE DE L'EXISTANT
9
2.1.1. PRESENTATION DE L'ISP/MBUJIMAYI
9
2.1.2. EXPLOITATION DES SOURCES D'INFORMATION
13
2.1.2.1. DESCRIPTION DES DOCUMENTS
13
2.1.2.2. DESCRIPTION DES RUBRIQUES
14
2.1.2.3. ANALYSE DE FLUX D'INFORMATIONS
15
2.1.2.4. SCHEMA DE CIRCULATION D'INFORMATIONS
17
2.1.2.5. MOYENS DE TRAITEMENT DES INFORMATIONS
19
2.2. CRITIQUE DE L'EXISTANT
20
CHAPITRE 3 : MODELISATION SOUS OMT
23
3.1. INTRODUCTION
23
3.2. LA MODELISATION
23
3.2.1. MODELE STATIQUE
24
3.2.1.1. IDENTIFICATION DES CLASSES D'OBJETS
24
3.2.1.2. ELABORATION DU DICTIONNAIRE DES DONNEES
24
3.2.1.3. IDENTIFICATION DES ASSOCIATIONS ENTRE
CLASSES
25
3.2.1.4. DETERMINATION DE LA MULTIPLICITE
25
3.2.1.5. IDENTIFICATION DES ATTRIBUTS D'OBJETS
26
3.2.1.5.1. MODELE D'OBJET INITIAL AVEC ATTRIBUTS,
METHODES ET MULTIPLICITES
26
3.2.1.5.2. RAFFINAGE EN UTILISANT L'HERITAGE ET
L'AGREGATION
26
3.2.1.6. QUANTIFICATION DU DIAGRAMME D'OBJET
27
3.2.2. MODELE DYNAMIQUE
29
3.2.2.1. IDENTIFICATION DES EVENEMENTS
29
3.2.2.2. LES DIAGRAMMES D'ETAT ET LES SCENARIOS
34
A. MENU PRINCIPAL
34
B. SAISIE DE DONNEES DES
ETUDIANTS
34
C. SAISIE DES DONNEES DE
DIRECTEUR
35
3.2.2.3. MODULE DE TRAITEMENT
36
3.2.2.4. DIAGRAMME A FLOT DE DONNEES
36
CHAPITRE 4 : REALISATION DE L'APPLICATION
38
4.0. INTRODUCTION
38
4.1. Choix du logiciel
38
4.2. Création de la base de
données vide
38
4.3. Structuration d'une base de
données
39
4.3.1. Création des tables
39
4.3.2. Création des relations entre les
tables
39
4.2.4. Création des formulaires
39
4.3.5. LE FORMULAIRE LOGIN
40
4.3.6. Les requêtes
41
CONCLUSION GENERALE
42
BIBLIOGRAPHIES
43
I.
OUVRAGES
43
II. NOTES DE
COURS
43
III. TRAVAUX DE FIN
DE CYCLE
43
IV.
WEBOGRAPHIE
43
 
* 1André Vigneau,
les documents informatiques pour une classification efficace,
ARCHIVES, VOLUME 27, NUMÉRO 3, 1996 P.29
* 23 Prof Dominique
TSHIENKE KANYONGA, initiation à la recherche scientifique G2
IG/SOIR/ISP/MBM, 2017
* 4 James A. O'Brien, Guy Marion
et Gilles Saint Amant Système d'information de gestion,
P.242
* 4 IUT de Nice cité par MIKUWA
ILUNGA Roger, TFC sur la conception d'une application pour
l'enregistrement des activités au RCCM de Mbujimayi,
Année académique 2017-2018, P.5, travail dirigé par C.T.
J.J. KABENGELE
* 5 James A. O'Brien, Guy Marion
et Gilles Saint Amant, Op.cit. P.251
* 6http://
Wikidictionnairy.org
* 7 INPP, Cours d'Access 2010
p.19
* 8Discal, Base de
l'informatique-Programmation, édition 2005, P. 448-449
* 9 MIKUWA ILUNGA Roger, TFC sur
la conception d'une application pour l'enregistrement des activités au
RCCM de Mbujimayi, Année académique 2017-2018, P.19, travail
dirigé par C.T. J.J. KABENGELE
* 10Boni KIBAMBE, Cours de
conception Orientée Objet, G3 Info, ISTIA, 2002-2003, P.24
* 11Jeanny DIKASA MBUYI
Etudiant de G3 IG/Jour, TFC sur « la conception et
réalisation d'une application pour la gestion des chambres dans un
hôtel », années académique 2017-2018 P.35
* 12 MIKUWA Roger, OP.CIT,
P.39
* 13Assistant Robert
TSHIABUILA, cours de technique de gestion de Bases de Données G3
IG/SOIR, année académique 2017-2018.
| 
