0.
INTRODUCTION GENERALE
0.1. Généralité
Une technologie a marqué chacun de trois derniers
siècles. Le dix-huitième siècle a été
l'ère des grands systèmes mécaniques propres à la
révolution industrielle. Le dix-neuvième siècle, la
technologie a été l'âge de la machine à vapeur.
Durant le vingtième siècle, la technologie clé a
concerné la collecte, le traitement et la diffusion de
l'information.1(*)
Nous avons vu, entre autres, la mise en place d'un
réseau téléphonique planétaire, l'invention de la
radio et de la télévision, la naissance et la croissance sans
précédent de l'industrie informatique et lancement des
satellites de communication.
Malgré sa jeunesse par rapport à d'autres
industries (automobile, transport aérien), l'industrie informatique a
fait en peu de temps des progrès spectaculaires. Pendant ses vingt
premières années, les systèmes informatiques
étaient très centralisés généralement dans
une grande salle. Il n'était pas rare de voir des ébahis admirer
le miracle électronique à travers des parois en verre. Une
société ou une université de taille moyenne avait toute au
plus un ou deux ordinateur, cela allait jusqu'à une petite douzaine pour
les grandes.2(*)
Imaginer que vingt ans plus tard on fabriquerait par million
des ordinateurs de la même puissance mais de la taille d'un timbre poste
relevé de la science fiction.
Les ordinateurs traitent des informations digitales
c'est-à-dire de l'information fondamentalement discontinue comme des
chiffres ou de caractères alphabétiques, par opposition aux
calculateurs analogiques et simulateur qui traitent de l'information analogique
qui a un caractère essentiellement continu.3(*)
La nécessité de l'informatique s'impose donc
dans tous les domaines de gestion (administration, planification
stratégique, prévision de vente, gestion des stocks...) et la
maitrise de l'outil informatique constitue la garantie d'une meilleure gestion,
un meilleur fonctionnement de l'entreprise et donc une meilleure
rentabilité de cette dernière.
0.2. Présentation du sujet
Notre sujet est intitulé « Conception
d'un système d'information pour la gestion du personnel dans un
établissement scolaire, cas du complexe scolaire Saint
Bernard »
Dans ce mémoire, notre préoccupation majeure est
de créer un système d'information informatisé qui
permettra de collecter des données, et de bien gérer ces
dernières qui permettront d'améliorer le système
existant.
0.3. Choix et intérêt du
sujet
a. Choix du sujet
Le choix thématique de ce sujet a été
motivé par trois raison, à savoir :
· La contrainte qu'ont les étudiants finalistes de
différents cycles de l'enseignement supérieur et
universitaire ;
· La disponibilité de la part de personnes
possédant les données au sein de cette institution
scolaire ;
· Le problème de stockage des informations qu'a
cette école.
b. Intérêt du sujet
L'intérêt du sujet que nous développons
est de chercher les voies et moyens d'illuger le temps pour
l'épanouissement du service de personnel dans le souci
d'améliorer ses conditions de travail avec l'aide des procédures
informatiques dans ce système de gestion.
0.4. Problématique et
Hypothèse
a. Problématique
La problématique désigne l'ensemble de questions
posées dans un domaine de la science, en vue d'une recherche des
solutions.4(*)
D'après les investigations que nous avons menées
dans le cadre de notre mémoire, nous nous sommes rendu compte que le
complexe scolaire saint Bernard utilise une gestion manuelle alors que le gain
de temps est l'une des caractéristiques d'une bonne gestion. Nous nous
sommes alors posé quelques questions de précision :
· La gestion actuelle est-elle efficace par rapport aux
objectifs du service du personnel ? ;
· Qu'est ce qui explique la lenteur et les pertes de
données au sein de cet établissement scolaire ;
· Le système informatique pourra-il
améliorer la gestion de cette école.
b. Hypothèse
Une hypothèse est une proposition relative à une
explication admise provisoirement avant d'être confirmée ou
infirmée5(*).
Dans le cadre de notre étude, nous émettons les
hypothèses que voici : Compte tenu des grandes
préoccupations telles que révélées dans la
problématique, nous envisageons l'amélioration du système
de gestion existant par l'informatisation, ceci permettra d'éradiquer
les erreurs de traitement et la mauvaise conservation des données.
0.5. Délimitation du sujet
La délimitation du sujet consiste à cadrer ou
à circonscrire les contours et les sphères de la recherche. A ce
stade, nous ne pouvons pas embrasser tous les services de cette école.
Ainsi, nous voulons circonscrire les champs de notre d'étude sur la
gestion du personnel plus précisément sur la gestion de
recrutement et la gestion de paie du personnel.
0.6. Méthodes et techniques
utilisées
a. Méthodes utilisées
En vue de doter ce travail d'un caractère scientifique,
il est importe d'opter une méthode parmi tant d'autres. Elle s'entend
comme un cheminement cohérent de la pensée humaine en vue de
donner une solution définitive à un problème de
fond6(*).
Nous avons jeté notre dévolue sur le langage UML
(Unified Modeling Language) qui est aujourd'hui le langage de
modélisation d'applications informatiques le plus important du
marché. Il est supporté par la quasi-totalité des outils
de développement, lesquels permettent l'édition de modèles
UML et offrent des capacités telles que la génération de
code, de test et de documentation, le suivi d'exigences ou encore le Reverse
Engineering.7(*)
· Le diagramme de GANTT : permet
d'associer les ressources aux tâches en fonction du temps.
· La Méthode Potentielle Métra
(MPM) : cette méthode fonctionne presque comme PERT
à la seule différence de ne pas faire appelle à une
tâche fictive.
· La méthode Delphi : elle
est basée sur le jugement d'expert ayant comme principe de rechercher
des analogies avec des projets de référence qui sont choisis dans
ou en dehors de l'entreprise.
· La méthode COCOMO : cette
méthode a été proposée par B.W. Boehm en 1981
(Constract Cost Model), basée sur la corrélation entre la taille
d'un projet et sa charge.
· La méthode des ratios : la
méthode d'évaluation par le ratio MERISE est basée sur une
pré-partition proportionnelle de la charge, il s'agit d'une approche
expérimentale. Cette méthode donne un résultat avec une
marge d'erreur de 40% lors que les équipes de développement ont
une efficacité homogène et une méthode de travail conforme
aux normes en vigueur.
b. Techniques utilisées
Nous avons utilisé deux techniques pour élaborer
ce travail de fin de cycle, à savoir : les techniques documentaires
et d'interview.
· Technique documentaires a été d'une
grande utilité pour collecter les données à partir des
différents documents mis a notre disposition.
· Technique d'interview ; grâce à cette
technique, nous avons obtenu des informations par le jeu des questions et
réponses auprès des interlocuteurs
0.7. Difficultés
rencontrées
Les difficultés nous ont accompagnées tout long
de la rédaction de ce mémoire, hormis les caprices et
indisponibilité du personne (agent de l'école) qui nous ont fait
défilé lors de la récolte de données, nous
étions encore en difficulté pour accéder dans le monde de
l'orienté objet.
0.8. Subdivision du travail
Hormis l'introduction générale et la conclusion
générale, notre travail est subdivisé en sept (7)
chapitres, à savoir :
· LE CADRAGE DU PROJET : qui nous a
permis d'avoir une idée sur la durée de chaque tache et la
durée de notre projet ;
· ETUDE D'OPPORTUNITE : ce chapitre nous a permis de
comprendre ou de maitriser le fonctionnement de cette institution
scolaire ;
· ANALYSE DE L'EXISTANT : dans ce chapitre nous
avons étudié ou analysé le fonctionnement du
système existant, nous l'avons critiqué et avons proposé
et placé notre choix sur une des solutions ;
· SPECIFICATION DES BESOINS : dans ce chapitre nous
avons parlé de ce que fera notre logiciel en s'appuyant au modèle
de contexte de UML ;
· ANALYSE DU DOMAINE : ici nous avons fait une
introduction sur UML et avons définit les termes utilisés pour
facilité la compréhension de diagramme UML utilisé;
· ANALYSE D'APPLICATION : Nous nous sommes
attelé à l'aspect comportemental du logiciel (application) en
s'appuyant toujours au diagramme UML ;
· CONCEPTION DU SYSTEME : dans ce chapitre, nous
avons déterminé comment cette implémentation sera
réalisée. Dans ce cas il faudra adapter le modèle par
rapport au langage cible.
CHAPITRE I : CADRAGE DU PROJET
1.1. Introduction
Comme tout autre projet, il nous est recommandé de
faire le cadrage de notre projet informatique. Dans ce chapitre nous allons
cadrer notre projet c'est-à-dire faire des estimations sur la
durée du projet, maitriser le dates au plut tôt et les dates au
plus tard.
1.2. Généralité sur
l'ordonnancement
Les problèmes d'ordonnancement sont apparus au
départ dans la planification de grands projets. Le but était de
gagner du temps sur leur réalisation. De tels projets sont
constitués de nombreuses étapes, également appelées
tâches. Des relations temporelles existent entre ces
dernières.8(*) Par
exemple :
· Une étape doit commencer à une date
précise ;
· Un certain nombre des tâches doivent êtres
terminées pour pouvoir démarrer une autre ;
· Chaque tâche nécessite une quantité
de mains oeuvres
· Deux taches ne peuvent être
réalisées en même temps (s'il elles utilisent la même
machine par exemple)
Toutes ces contraintes ne sont à prendre en compte dans
la résolution du problème.
On cherchera à déterminer une planification,
ordonnancement des étapes qui minimise le temps total de
réalisation du projet. A partir de cette planification, nous verrons que
le temps prévu pour certaines étapes peut éventuellement
être modifié sans entrainer un retard du projet, alors que
d'autres étapes dites critique retardent entièrement le projet au
moindre retard local.
1.3. Choix de la méthode de
planification
Dans le cadre de notre projet nous avons placé notre
choix sur la méthode PERT.
1.3.1. Présentation de la
Méthode PERT
La méthode PERT est une technique permettant de
gérer l'ordonnancement dans un projet. La méthode PERT consiste
à représenter sous forme de graphe, un réseau de
tâches dont l'enchaînement permet d'aboutir à l'atteinte des
objectifs d'un projet.
Elle a été conçue par la marine
américaine afin de permettre de coordonner les travaux de plusieurs
milliers de personnes pour aboutir à la réalisation de missiles
à ogives nucléaires POLARIS.
Ainsi, la méthode PERT implique au préalable :
· Un découpage précis du projet en
tâches ;
· L'estimation du la durée de chaque tâche ;
· La nomination d'un chef de projet chargé
d'assurer le suivi du projet, de rendre compte si nécessaire et de
prendre des décisions en cas d'écart par rapport aux
prévisions.
1.3.2.
Définition de concepts clés
Tâche ou opération: Elle fait
avancer une oeuvre vers son état final. Exemple de représentation
de la tâche A. Habituellement, on nomme les tâches et on indique
leur durée.
Etape: On appelle étape, le
début ou la fin d'une tâche. Exemple de représentation de
l'étape 1. Habituellement on numérote les étapes. On
indique aussi leur temps de réalisation au plus tôt et au plus
tard
Réseau: On appelle réseau ou
diagramme PERT, l'ensemble des tâches et des étapes qui forment le
projet. Un réseau possède toujours une étape de
début et une étape de fin. On lit un réseau de la gauche
vers la droite. Les flèches sont orientées dans ce sens. Il n'y a
jamais de retours. On ne peut représenter une tâche que par une
seule flèche.
Chemin subcritique : Chemin qui risque
de devenir critique
1.3.3. Identification de tâches
Dans le cadre de notre travail, nous avons recensé
quelques taches qui feront l'objet de notre cadrage, à savoir ;
· Etudes de l'existant ;
· Analyse de l'existant ;
· Critique de l'existant ;
· Proposition de solution ;
· Conception ;
· Test de conception ;
· Appel d'offre ;
· Dépouillement ;
· Cahier de charge ;
· Passation commande ;
· Installation matérielle ;
· Installation logiciel ;
· Formation ;
· Livraison.
1.3.4. Description des taches
Pour mieux décrire les taches de notre projet, nous
les présentons da ns un tableau
Taches
|
Désignation de la tâche
|
Durée de la tache
|
Taches Précédente
|
Taches suivantes
|
A
|
Etude de l'existant
|
18
|
-
|
B
|
B
|
Analyse de l'existant
|
5
|
B
|
C
|
C
|
Critique de l'existant
|
1
|
B
|
D
|
D
|
Proposition de solution
|
1
|
C
|
E
|
E
|
Conception
|
26
|
D
|
F, G
|
F
|
Test de conception
|
1
|
E
|
H
|
G
|
Appel d'offre
|
15
|
E
|
H
|
H
|
Dépouillement
|
2
|
F, G
|
I, J
|
I
|
Cahier de charge
|
5
|
H
|
K
|
J
|
Passation commande
|
6
|
H
|
K
|
K
|
Installation matérielle
|
2
|
I, J
|
L
|
L
|
Installation logiciel
|
3
|
K
|
M
|
M
|
Formation
|
12
|
L
|
N
|
N
|
Livraison
|
1
|
M
|
O
|
O
|
Fin
|
0
|
N
|
-
|
1.3.5. O 4
225 25 2525
O 15
994 94 9494
O 10
776 76
O 11
778 78
O 14
094 94
O 13
993 93
O 7
0 68 68
O 8
0 70 70
O 5
553 53 53
O 3
224 24 24
O 6
554 68
O 0
0 0 0
O 1
0 18 18
O 2
223 23 23
O 12
881 81
O 9
0 75 76
FA18
FH2
FD1
FB5
FC1
FO0
LL3
FG15
FF1
FE28
FN1
FM12
FI5
FJ6
FK2
Présentation du graphe
1.1.1. 1.3.6. Délai de
réalisation du projet
Calcul de date au plus tôt et plus tard
Nous avons pour chaque tache une date au plus tôt, c'est
la valeur située à gauche. Elle représente la date ou
durée de fin au plus tôt de la tâche
précédente et le début au plus tôt de la tâche
suivante du même sommet.
Tandis que la date au plus tard c'est la valeur située
à droite. Elle représente la date ou durée de fin au plus
tard de la tâche précédente et le début au plus tard
de la tâche suivante du même sommet. La date de début au
plus tard d'une tâche est la date à ne pas dépasser. Si non
le retard affecte l'ensemble du projet. Elle est calculée du dernier
sommet vers le premier sommet. Sa formule est présentée
ci-dessous.
1.3.7. Calcul marge libre
La marge libre sur une tâche est le retard que l'on peut
prendre dans sa réalisation (sous réserve qu'elle ait
commencé à sa date au plus tôt) sans retarder la date de
début au plus tôt de toute autre tâche suivante. Si l'on
dépasse la marge libre, certaines tâches suivantes sont
retardées. Mais cela reste sans incidence sur la durée du projet.
Sa formule de calcul est présentée ci-dessous.
Si on considère :
La tâche A situé entre les sommets a et b
T(b) : date au plus tôt du sommet b. (fin au plus
tôt de la tâche A)
T(a) : date au plus tôt du sommet a.(début
au plus tôt de la tâche A)
d (A) : durée de la tâche A.
Marge Libre de la tâche A = [T(b) - T(a) - d(A)]
pour toutes les tâches situées entre les deux sommets.
Apres l'application de la formule nous aurons les marges
libres ci-après
Début = 0, A= 0, B=0, C=0, D=0, E=0, F=14, G=0, H=0,
L=1, J=0, K=0, L=0, M=0, N=0, Fin =0
1.3.8. Calcul marge totale
La marge totale sur une tâche est le retard que l'on
peut prendre dans sa réalisation sans retarder l'ensemble du projet et
sous réserve que la tâche en question commence à sa date au
plus tôt. Si l'on dépasse la marge totale d'une tâche, le
projet prend du retard. Sa formule de calcul est présentée
ci-dessous. Si on considère :
La tâche A situé entre les sommets a et b
t(b) : date au plus tard du sommet b. (fin au plus tard
de la tâche A)
T(a) : date au plus tôt du sommet a. (début
au plus tôt de la tâche A)
d (A) : durée de la tâche A ;
Contrairement à la marge libre, la marge totale tien
compte de toutes les tâches situées entre les sommets (a) et (b)
Marge Totale de la tâche A = Min [t(b)
- T(a) - d (A)] pour toutes les tâches situées entre les deux
sommets.
Apres l'application de la formule nous aurons les marges
libres ci-après
Début = 0, A= 0, B=0, C=0, D=0, E=0, F=14, G=0, H=0,
L=1, J=0, K=0, L=0, M=0, N=0, Fin =0
Interprétation de résultats
Nous avons compris que la plus part de tache n'admettent pas
de retard dans leurs exécution à l'instar des taches F et L qui
admettent un retard respectif de 14 et 1 jours avant qu'elles soient
réalisées, sans remettre en cause les dates au plus tard des
aches suivantes.
1.3.9. Détermination de chemin critique
Le chemin critique est formé de la succession de
tâches sur le chemin le plus long en termes de durée. Tout retard
pris sur l'une des tâches de ce chemin entraîne un retard dans
l'achèvement du projet.
Sur un graphe Pert, chemin reliant les tâches la marge
totale est égale à zéro (0) partant du premier sommet
(Début) au dernier sommet (Fin). Sur un graphe de Gantt.
O 15
994 94 9494
O 10
776 76
O 11
778 78
O 14
094 94
O 13
993 93
O 7
0 68 68
O 8
0 70 70
O 5
553 53 53
O 3
224 24 24
O 0
0 0 0
O 1
0 18 18
O 2
223 23 23
O 12
881 81
FA18
FH2
FD1
FB5
FC1
FO0
LL3
FG15
FE28
FN12
FM12
FJ6
FK2
O 4
225 25 2525
1.3.10. Planning prévisionnel de
la réalisation du projet
a. Synthèse de données
Tache
|
Durée/jour
|
Tache précédente
|
Tache suivante
|
Date au plus tôt
|
Date au plus tard
|
Marge total
|
Marge libre
|
A
|
18
|
-
|
B
|
18
|
18
|
0
|
0
|
B
|
5
|
B
|
C
|
23
|
23
|
0
|
0
|
C
|
1
|
B
|
D
|
24
|
24
|
0
|
0
|
D
|
1
|
C
|
E
|
25
|
25
|
0
|
0
|
E
|
28
|
D
|
F, G
|
53
|
53
|
0
|
0
|
F
|
1
|
E
|
H
|
54
|
68
|
14
|
14
|
G
|
15
|
E
|
H
|
68
|
68
|
0
|
0
|
I
|
2
|
F, G
|
I, J
|
70
|
76
|
6
|
6
|
J
|
5
|
H
|
K
|
76
|
76
|
0
|
0
|
K
|
6
|
H
|
K
|
78
|
78
|
0
|
0
|
L
|
3
|
I, J
|
L
|
81
|
81
|
0
|
0
|
M
|
12
|
K
|
M
|
93
|
93
|
0
|
0
|
N
|
1
|
L
|
N
|
94
|
94
|
0
|
0
|
O
|
0
|
M
|
O
|
94
|
94
|
0
|
0
|
B. Calendrier d'exécution du projet
Nous avons démarré la réalisation de
notre projet le 10 juin 2011 et avons terminé le 19 septembre.
N°
|
DATE
|
TACHE
|
1
|
10 juin
|
Démarrage A
|
2
|
29 juin
|
Démarrage B
|
3
|
5 juillet
|
Démarrage C
|
4
|
6 juillet
|
Démarrage D
|
5
|
7 juillet
|
Démarrage E
|
6
|
6 aout
|
Démarrage F
|
7
|
7 aout
|
Démarrage G
|
8
|
21 aout
|
Démarrage H
|
9
|
23 aout
|
Démarrage I
|
10
|
29 aout
|
Démarrage I
|
11
|
30 aout
|
Démarrage I
|
12
|
2 septembre
|
Démarrage I
|
13
|
6 septembre
|
Démarrage I
|
14
|
18 septembre
|
Démarrage I
|
15
|
19 septembre
|
Fin projet
|
CHAPITRE II : ETUDE D'OPPORTUNITE
II.1. Historique de l'entreprise
Le Complexe Scolaire saint Bernard est né des cendres
du conflit de compétence entre le 1er Curé de la
paroisse Saint Bernard, le révérend Père cure GIOVANNI
MAGNAGUAGNO, affectueusement appelé Djani en 2004.
En effet, aussitôt nommé et investi curé
de la paroisse Saint Bernard par l'archevêque de Kinshasa, le Cardinal
Fréderic ETSOU. Il réunit le conseil paroissial pour savoir ce
que retenait pendant ma période d'observation 2002-2003, l'école
conventionnée catholique MATONDO, à obéir à
l'ordinaire du lieu. Le curé de la paroisse et le respect de la
convention signée avec l'état à cet effet.
Ayant recueilli les informations nécessaires, il a
entrepris les démarches en direction de la division des écoles
conventionnées catholiques du mont Amba à Lemba ; sous la
direction de Monsieur NGUBALA, qui avait clairement tripoté sur
l'ancienne école paroissiale.
II.2. Objectif
Le Complexe Scolaire saint Bernard a pour objectif :
· Créer une école viable dans un milieu
périphérique, remplissant toutes les conditions d'une bonne
école ;
· Permettre aux parents d'éviter de
déplacer leurs enfants dans les écoles lointaines qui exigent un
moyen de transport ;
· Former une personne intégrale, capable de se
défendre dans la vie en suivant le programme national de
l'éducation.
II.3. Situation géographique
Le complexe scolaire Saint Bernard est situé dans la
commune de LIMETE, dans le Quartier NDANU, commune de LIMETE
précisément sur l'avenue Mwepu N52
II.4. Organigramme de l'entreprise
Promoteur
Directrice adj. Maternelle
Maitres
Directrice
Secrétaire
Monitrices
Surnuméraire
Travailleurs
Sentinelles
Préfet
Directeur des études
Directeur de Discipline
Professeurs
Source : Secrétariat de l'école
CHAPITRE III : ANALYSE DE L'EXISTANT
III.1. Introduction
La plupart des méthodes d'analyse et de conception
utilisées dans la l'ingénierie des Systèmes reposent sur
la même démarche :
· Modéliser le système existant pour
émettre un diagnostic
· Modéliser le système cible pour
élaborer un plan d'actions.
Dans la démarche d'analyse, la phase de
modélisation est primordiale. La modélisation d'un système
et plus globalement de l'entreprise permet de représenter la structure
et le fonctionnement du système. Cette activité de mise à
plat des pratiques, permet d'atteindre plusieurs finalités, selon les
objectifs fixés au préalable lors de l'initialisation du projet
:
· Une meilleure compréhension du système
· Une meilleure communication entre les acteurs
· Une évaluation de la performance par
l'intermédiaire d'indicateurs de performance
· Une analyse des dysfonctionnements
· Une simulation du comportement du système Une
spécification d'applications informatiques
III.2. Présentation du service concerné
Dans le cadre de notre étude, nous allons nous occuper
seulement du personnel c'est-à-dire, le service qui gère le
personnel.
III.2.1. Organigramme du service concerné
Directrice adj. Maternelle
Promoteur
Directrice
Secrétaire
Surnuméraire
Préfet
Directeur des études
Source : Secrétariat de l'école
III.2.2. Présentation et description du service
concerné
a. Présentation
Dans ce service nous avons 7 postes qui interviennent,
à savoir :
· Le promoteur
· Le préfet
· La directrice
· Secrétaire
· Directrice adjoint
· Surnuméraire
· Le directeur des études
b. Description
Promoteur : Il est l'autorité
morale du complexe, à lui revient la dernière signature.
Le préfet : Il est le responsable
(Chef d'établissement) de la section secondaire
La directrice : elle est la responsable
(chef des établissements) de la section primaire et maternelle
Secrétaire : il s'occupe de la
finance du complexe et est le réceptionniste.
Directrice adjoint : Elle s'occupe de
l'administration de l'école maternelle, elle est la
représentante de cette section au comité de gestion.
Surnuméraire : il s'occupe de
l'administration de l'école primaire, il est le représentant de
cette section au comité de gestion.
Le directeur des études : il
s'occupe de la pédagogie de l'école celui qui décide sur
l'aspect pédagogique pendant le recrutement.
III.3. Etude des ressources utilisées
On appelle ressource l'ensemble de moyens matériels,
humains et financiers utilisés pour la réalisation des certaines
actions d'une opération au cours de l'analyse. Il est nécessaire
de recenser tous les moyens matériels, humains et financiers
utilisés dans cette organisation, ainsi nous aurons à faire
ressortir les moyens humains, matériels et financiers existant au sein
du Complexe scolaire saint Bernard.
3.3.1. Ressources humaines
Le service du personnel du Complexe Scolaire Saint Bernard
compte 8 agents tous qualifié, les explications dans le tableau
ci-dessus :
N°
|
Poste
|
Nombre agent
|
Qualification
|
Ancienneté
|
1
|
Promoteur
|
1
|
|
5 ans
|
2
|
Préfet
|
1
|
L2 Français
|
3
|
3
|
directrice
|
1
|
L2 gestion scol.
|
4
|
4
|
Secrétaire
|
1
|
G3 info
|
4
|
5
|
Directrice Adj
|
1
|
D6 Péda Gén
|
5
|
6
|
Surnuméraire
|
1
|
D6 Péda
|
5
|
7
|
Directeurs des études
|
1
|
L2 Ops
|
4
|
3.3.2. Ressources matérielles
Cette étude consistera à inventorier les
différents matériels utilisés au sein de cette
organisation pour le traitement des informations. Le service du personnel de
l'école Saint Bernard possède un certain nombre de
matériel à savoir :
N°
|
Matériels
|
Quantité
|
Poste
|
Etat
|
Année d'acquisition
|
1
|
Table
|
2
|
Promoteur
|
bon
|
2009
|
2
|
Chaise
|
6
|
Promoteur
|
Bon
|
2009
|
3
|
Armoire
|
1
|
Promoteur
|
Bon
|
2007
|
4
|
Lap top Tochiba
|
1
|
Promoteur
|
Bon
|
2006
|
5
|
Tables
|
2
|
Directrice
|
Bon
|
2008
|
6
|
chaises
|
4
|
Directrice
|
Bon
|
2008
|
7
|
Armoires
|
1
|
Chef de section
|
Bon
|
2008
|
8
|
Lap top acer
|
1
|
Chef de section
|
Bon
|
2008
|
III.3.3. Ressources financières
Les ressources financières des cette institution
financières proviennent de parents des élèves
c'est-à-dire de différent frais exigés à
l'école (Frais de fourniture, frais de minerval ...). Et ces frais sont
repartis en pourcentage, le frais de fonctionnement 30 % et l'enveloppe
salariale 70%.
III.4. Etude de documents utilisés
a. Présentation de documents
Nous avons recensé tous les documents utilisés
dans le service du personnel du complexe scolaire saint Bernard.
ü Fiche de paie
ü Contrat de service
ü Fiche d'évaluation
ü Fiche de présence
ü Fiche de signalement
b. Description des documents
N °
|
Document
|
Rôle
|
Emetteur
|
Destinataire
|
Fréquence
|
1
|
Fiche de paie
|
Donne accès à l'agent de toucher sont
salaire ;
Permet au père curé de maitriser les sorties
mensuelle
|
Secrétaire
|
· Caissier
· Père curé
· Agent
|
MENSUELLE
|
2
|
Contrat de service
|
Le document contractuel qui certifie l'engagement de l'agent
|
Père curé
|
Agent
|
ANNUELLE
|
3
|
Fiche d'évaluation
|
Le document qui permet aux autorités d'évaluer
la prestation des agents
|
Chef de section
|
· Directrice
· Préfet
|
TRIMESTRIELLE
|
4
|
Fiche de présence
|
Le document qui justifie la prestation des agents
|
Chef de section
|
· Directrice
· Préfet
· Agent
|
JOURNALIERE
|
5
|
Fiche de signalement
|
C'est un document qui ressemble les différentes
cotations (application, conduite, assiduité... durant une année
scolaire
|
Chef de section
|
· Directrice
· Préfet
· Agent
|
ANNUELLE
|
III.5. Etude de circuit des informations
Nous devons faire une narration pour expliciter comment les
documents et les informations circulent dans cette organisation. Nous nous
attachons beaucoup plus dans le recrutement et le paie des agents :
L'école lance un offre quand le besoin se fait sentir,
les concernés viennent déposer les dossiers au secrétariat
de l'école et ces dossiers seront envoyés au chef de section
(Cfr organigramme), après dépouillement de dossier par rapport
aux critériums, l'école organise un test qui sera corrigé
par le chef de section et ce dernier établit une liste de candidats
retenus après test ils seront appelé pour enfin être
notifié.
La première année scolaire est
considérée comme une année d'essaye et le recru aura le
grade de U.N. (nouvel unité).
Une année après, le service du personnel va-le
coté en tenant compte de fiche de présence, sa fiche
d'évaluation et établira pour lui une fiche de signalement.
Si cote de la fiche de signalement est supérieure ou
égale à 70% agent est accepté et signe un contrat de
rouage si non l'agent sera remercié.
Il a droit à un grade et le secrétaire
établit une fiche de paie pour lui à 2 exemplaires.
Le jour de la paie, il se présente au
secrétariat, reçoit le 2 exemplaires de sa fiche de paie, appose
sa signature, il les amène à la caisse ce dernier contré
signe sur le 2 exemplaire et il effectue le paie, l'agent rentre au
secrétariat pour remettre un exemplaire de la dite fiche et garde un
exemplaire.
A son tour le secrétaire vérifie et transmet un
exemplaire de la fiche de paie au père curé qui vérifie,
contré signe et enregistre le montant dans son fichier Excel avant de
retransmettre la fiche au secrétariat au elle est archivé
III.6. BILAN CRITIQUE DE L'EXISTANT
Il convient de relever tous les points qui peuvent être
positifs ou négatifs que connaît le complexe scolaire Saint
Bernard, ainsi ce dernier détient au moins un système
d'organisation bien défini du point de vue fonctionnel et
organisationnel.
· Des matériels informatiques bien
protégés par les onduleurs et stabilisateurs ;
· Une bonne circulation des informations et une bonne
collaboration et transmissions des informations entre eux.
Ces points ci-hauts cités, constituent les
mérites de cette entreprise
· Les documents étant conservés dans les
classeurs à papiers, l'accès est difficile et occasionne une
perte de temps. Etant donné, il faut toujours une recherche
sérieuse pour retrouver un document tel que la fiche les fiches
d'évaluation pour pouvoir établir la fiche de signalement, le
volume élevé des informations ;
· dans sa globalité, tous les services utilises
actuellement les Ordinateur pour la saisie de texte et la musique ;
· le complexe scolaire saint Bernard n'a pas de
logiciels approprié pour gérer toutes les données ;
· La mis à jours d'anti virus non
régulière.
III.7. Les orientations
a.
Solution manuelle
Cette solution présente un avantage car en cas de
coupure du courant, surtout dans notre pays avec le système de
délestage, nous risquons d'être bloqués pendant longtemps.
Ce système ne demande pas de grand moyen pour l'achat du matériel
à utiliser ainsi leurs entretiens.
Cependant, la conservation des documents à utiliser
n'est pas toujours parfaite. Il y a risque vengeurs détruisent. Le
système manuel présent de limite considérable. Il y a une
lenteur qui s'installe dans le traitement données.
· Le risque de commettre des erreurs dues à la
fatigue est considérablement élevé.
· Du coup la fiabilité des résultats n'est
toujours pas garantie.
b. Solution informatique
L'avantage de celle-ci est de traiter des informations avec
une certaine rapidité, précision et en temps réel afin de
rendre fiable la gestion de l'information. Elle présente aussi
l'inconvénient d'engager des grosses dépenses pour son
installation, le coût à la formation ou recrutement des agents et
autres.
L'informatisation, comme solution présente plusieurs
avantages à savoir : Il y a une bonne conservation des documents
à utiliser, une rapidité dans le traitement des informations, la
fiabilité de résultat est garantie car les risques des erreurs
sont moindres. Mais cette solution présente un désavantage, c'est
celui des coupures intempestives du courant qui pourrait tout bloquer, car
l'ordinateur ne fonctionne qu'avec de l'énergie électrique. De
toutes les façons, la difficulté peut être
surmontée.
III.8. Choix de solutions envisagées
Au regard des avantages et inconvénients des deux
systèmes (manuel et informatique), nous pensons que le système
informatique est mieux indiqué pour le recrutement et la promotion et la
paie des agents dans cette école.
Vu la complexité et le volume de l'information a
traitée nous leur proposons aussi une solution informatique qui peut les
aider à améliorer leurs travail, cette solution est fiable, car
elle tient compte de l'intérêt général,
présentant plus d'avantage par rapport aux autres. Le type de
système informatique adopté a cette situation est un
système informatique qui s'effectue au niveau de chaque poste de
travail, les ordinateurs sont indépendants les uns des autres donc ne
sont pas en réseau informatique.
Ainsi nous opterons pour la solution automatique ou
informatique et en temps réel pour des raisons suivantes :
· La prise en charge par la machine (ordinateur) tous les
traitements afin d'éviter les erreurs et fournir les résultats
fiables dans un bref délai;
Par la technique d'ingénierie des exigences ou
d'analyse et de spécification des besoins constituent une phase capitale
dans le cas où toute la suite du projet dépend d'elle, elle doit
être faite avec beaucoup de rigueur et plus d'attention pour que le
projet soit fiable pour tous.
CHAPITRE IV : SPECIFICATION DES BESOINS
IV.1. Introduction
Dans le cadre notre projet, notre logiciel sera utilisé
par le membre du service de personnel, du complexe scolaire. Tenant compte de
notre la localisation de différent bureau du complexe, nous avons
songé à mettre en place un réseau informatique local
pouvant permettre la communication et l'utilisation entre utilisateur et la
base sera logée dans un serveur.
IV.2. Définition des concepts
IV.2.1. Système
Un système est un ensemble d'élément en
interaction dynamique permanente organisé en fonction d'une fonction
d'un but à attendre9(*)
IV.2.2. Le système d'information
Selon la théorie systémique, l'entreprise ou
l'organisation est composée du système opérant,
système pilotage et du système d'information.
Le système d'information est l'ensemble de moyens
techniques, humains et des méthodes qui permettent le traitement des
informations au sein d'une organisation.10(*)
Le système d'information est le véhicule de la
communication dans l'organisation. Sa structure est constituée de
l'ensemble des ressources (les hommes, le matériel, les logiciels)
organisées pour : collecter, stocker, traiter et communiquer les
informations. Le système d'information coordonne grâce à
l'information les activités de l'organisation et lui permet ainsi
d'atteindre ses objectifs.
IV.2.3. Organisation
Une organisation c'est tout groupe social organisé
exerçant une activité déterminée11(*).
Une organisation est une unité qui structure et pilote
des ressources afin d'attendre un but12(*)
Un système opérant est un ensemble
d'élément matériels ou immatériels en interaction
transformant par un processus des éléments (les entrées)
en d'autre éléments (les sorties). Un
système opérant peut être contrôlé par un
autre système dit système de pilotage
On distingue d'abord le système opérant
où les produits finaux sont fabriqués à partir d'une
certaine matière première. On réduit l'organisation
à une sorte d'usine, qui travaille sur la matière première
pour fournir un produit final.
IV.2.5. Système de pilotage
Toute organisation est pilotée par une direction, une
équipe dirigeante. Ce système de pilotage a pour mission de
conduire l'organisation vers des objectifs qui lui sont fixés, et de
vérifier que ces objectifs ont bien été atteints. Ce qui
nécessite souvent un contrôle continu du fonctionnement du
système opérant et d'éventuelles modifications
(recrutement, investissement, nouveaux développements...) à
apporter au système opérant.
Dans le système de pilotage, l'information va permettre
à celui-ci de prendre les bonnes décisions en étant
constamment informé de ce qui se passe dans le système
opérationnel.
Un système de pilotage procède au pilotage
(régulation et contrôle) du système opérant en
décidant du comportement de celui-ci en fonction des objectifs
fixés.
Et c'est dans ce contexte qu'apparaît le système
d'information. Ce sous-système de l'organisation s'occupe de
récolter l'information, de la stocker, de la traiter et de la diffuser
dans le système opérant et dans le système de pilotage.
Dans le système opérant, cette information va permettre à
celui-ci de fonctionner. Car chaque individu et chaque tâche ont besoin
d'être informés sur le flux physique qui la traverse.
IV.2. Enoncé du problème
Le problème dont il est question a été
spécifié au niveau de la narration. Notre prochaine application
consistera à gérer un ensemble d'information permettant à
la direction du personnel, de nouveaux recrus et leur évaluation sans
trop de peine.
Au niveau de nouveau recru
Le processus commence lorsque les recrus sont acceptés,
et une évaluation a lieu pendant une année, lors de la citation
par le service du personnel, le recru dont la cote est supérieur ou
égal à75%, passe comme agent effectif de l'école si non
il est remercié.
Au niveau de l'agent effectif
D'abord, le service personnel par le biais du
secrétaire, enregistre les informations des agents dans la base des
données.
Le service du personnel, par le biais de son agent pointeur
enregistre les pointages pour chaque gent, à la fin du mois, il fait le
regroupement des touts les données qu'il enregistrera à la base
de données pendant le mois l'agent peut faire des emprunts.
Lors de la paie, le service personnel calcul le nombre de
présence envoyé par l'gent pointeur puis, il évalue ses
dettes ainsi que les avantages enregistrés pendant le mois et calcul le
net à payer. La liste de la paie est envoyée au curé pour
validation.
IV.3. Modèle de contexte
IV.3.1. Rôle
Ce diagramme permet de spécifier tous les
éléments externes au système en interaction avec
celui-ci.
IV.3.2.Formalisme13(*)
Acteur 1
Acteur 2
Acteur 4
Acteur 3
SYSTEME
IV.3.3. Présentation du diagramme de contexte
1er Diagramme de contexte
Secrétaire
Chef de section
SYSTEME
1 6
Père curé
2
3
4
5
Tableau descriptif de mouvement de message
N° message
|
MESSAGE
|
Expéditeur
|
Destinateur
|
1
|
Impression de fiche de paie
|
Système
|
Secrétaire
|
2
|
Enregistrement des informations des agents dans la base de
données
|
Secrétaire
|
Système
|
3
|
Enregistrement des emprunts
|
Secrétaire
|
Système
|
4
|
Enregistrement de présences journalières des
agents
|
Chef de section
|
Système
|
5
|
Impression de liste des agents par section
|
Système
|
Chef de section
|
6
|
Impression de toutes les listes
|
Système
|
Père curé
|
2ème Diagramme de contexte
SYSTEME
2
1 3
Tableau descriptif de mouvement de message
N° message
|
MESSAGE
|
Expéditeur
|
Destinateur
|
1
|
Enregistrement de recrus sur la base de données
|
Secrétaire
|
Système
|
2
|
Enregistrement des cotes de recrus dans la base de
données
|
Chef de section
|
Système
|
3
|
Impression des cotes des recrus
|
Système
|
Chef de section
|
CHAPITRE V : ANALYSE DU DOMAINE
V.1.
INTRODUCTION
Il est évident que les méthodes et les outils
choisis pour concevoir et développer une application doivent être
en fonction de l'environnement et du domaine d'application de celle-ci. Cela
est bien expliqué par le génie logiciel.
L'informatisation est le phénomène le plus
important de notre époque. Elle s'immisce maintenant dans la plus part
des objets de la vie courante et ce, que ce soit dans l'objet proprement dit
(Par exemple, aujourd'hui, 90% des nouvelles fonctionnalités des
automobiles sont apportées par l'électronique et l'informatique
embarquées. Il y a, ou aura à terme, du logiciel partout :
ampoules, four à micro ondes, tissus des vêtements, stylos et
livres, etc.), ou bien dans les processus de conception ou de fabrication de
cet objet.14(*)
UML (Unified Modeling Language, traduisez "langage de
modélisation objet unifié") est né de la fusion des trois
méthodes qui ont le plus influencé la modélisation objet
au milieu des années 90 : OMT (Object Modeling Technique), Booch et OOSE
(Object Oriented Software Engineering). Issu "du terrain" et fruit d'un
travail d'experts reconnus, UML est le résultat d'un large consensus. De
très nombreux acteurs industriels de renom ont adopté UML et
participent à son développement15(*)
En l'espace d'une poignée d'années seulement,
UML est devenu un standard incontournable. La presse spécialisée
foisonne d'articles exaltés et à en croire certains, utiliser les
technologies objet sans UML relève de l'hérésie. Lorsqu'on
possède un esprit un tant soit peu critique, on est en droit de
s'interroger sur les raisons qui expliquent un engouement si soudain et massif
! UML est-il révolutionnaire?
L'approche objet est pourtant loin d'être une
idée récente. Simula, premier langage de programmation à
implémenter le concept de type abstrait à l'aide de classes, date
de 1967 ! En 1976 déjà, Smalltalk implémente les concepts
fondateurs de l'approche objet : encapsulation, agrégation,
héritage. Les premiers compilateurs C++ date du début des
années 80 et de nombreux langages orientés objets
"académiques" ont étayés les concepts objets (Eiffel,
Objective C, Loops...).
Il y donc déjà longtemps que l'approche objet
est devenue une réalité. Les concepts de base de l'approche objet
sont stables et largement éprouvés. De nos jours, programmer
"objet", c'est bénéficier d'une panoplie d'outils et de langages
performants. L'approche objet est une solution technologique incontournable. Ce
n'est plus une mode, mais un réflexe quasi-automatique dès lors
qu'on cherche à concevoir des logiciels complexes qui doivent
"résister" à des évolutions incessantes.
Oui, mais... Tout n'est pas si rose. Beaucoup on
cédé aux sirènes de l'orienté objet et leur
aveuglement a fait couler bien des projets...16(*)
C'est ainsi que, l'unification
progressant par étapes. En 1995, Booch et Rumbaugh (et quelques autres)
se sont mis d'accord pour la construction d'une méthode unifiée,
Unified Method 0.822;
En 1996, Jacobson les rejoignant pour produire UML 0.9 (notez
le remplacement du mot méthode par le mot langage, plus modeste). Les
acteurs les plus important dans le monde du logiciel s'associent alors à
l'effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et UML 1.0
est soumis à l'OMG (Object Management Group) qui adoptant UML1.1 comme
langage de modélisation des systèmes d'information à
objets en Novembre 1997.
Signalons que la version en cours est UML 2.0 dès la
fin 2006 et les travaux d'amélioration se poursuivent17(*).
UML est donc non seulement un outil intéressant mais
une norme qui s'impose en technologie à objets et à laquelle se
sont rangés tous les grands acteurs du domaine, acteurs qui ont
d'ailleurs contribué à son élaboration.
V.1.1. OBJECTIFS ET AVANTAGES DE L'APPROCHE ORIENTEE
OBJET
ü Objectifs
· Représenter des systèmes
entiers ;
· Etablir un couplage explicite entre les concepts et les
artefacts exécutables ;
· Prendre en compte les facteurs
d'échelle ;
· Créer un langage de modélisation
utilisable à la fois par les humains et les machines.
ü Avantages
Parmi les avantages de cette approche, on peut citer : la
réutilisabilité des éléments (objets), l'avantage
d'utiliser un objet de base afin de produire un autre qui peut être une
amélioration de cet objet (phénomène d'héritage),
etc.
L'objet est le coeur de cette approche. Tout objet
donné possède deux caractéristiques :
§ Son état courant (attributs)
§ Son comportement (méthodes)
V.1.2. Illustration des axes
utilises par UML
UML utilise trois axes repartis comme suit :
SYSTEME D'INFORMATION FONCTIONNEL
· Diagrammes de cas d'utilisation ;
· Diagrammes de séquence ;
· Diagrammes d'activité.
SYSTEME D'INFORMATION STATIQUE
· Diagrammes de classe ;
· Diagrammes objet ;
· Diagrammes de déploiement ;
· Diagrammes de paquetages.
SYSTEME D'INFORMATION DYNAMIQUE
· Diagrammes d'état ;
· Diagrammes d'activité ;
· Diagrammes d'état-transition.
V.2. Le diagramme objet
Un objet est une entité
qui a un sens dans le contexte de l'application. C'est une
représentation informatique des éléments du monde
réel auxquels on s'intéresse, sans se préoccuper de
l'implémentation18(*)
V.2.1. Formalisme
: Nom objet
Les objets recensés
Dans le cadre de notre projet nous avons recensé
quelques objets, à savoir :
§ § Ecole
§ Primaire
§ Secondaire
§ maternelle
§ fonction
§ Agent
§ Personnel recrus
§ Personnel effectif
§ Apprécier
§ Cotation
§ Promotion
§ Enseignant
§ Administratif
§ Avantage
§ Prime
§ Payer
§ Obtenir
V.2.2. Présentation du diagramme objet
1
1....A
: Primaire
: Ecole
:Secondaire
: Agent
: Fonction
:Personnel_recrute
: Personnel_
effectif
: Promotion
Apprécier
: Cotation
: Enseignant
: Administratif
: Huissier
: Avantage
: Prime
: Paie
: Obtenir
: Maternelle
V.3. Dictionnaire de données
N°
|
Non de la classe
|
Description
|
Attribut
|
Type
|
1
|
Ecole
|
L'organisation qui englobe le different bureau
|
Code_ecole
Nom_ecole
Adresse_ecole
|
String
String
string
|
2
|
Primaire
|
Entité de l'école qui s'occupe de l'enseignement
primaire
|
Ref_primaire
Libelle
|
String
String
|
3
|
Secondaire
|
Entité de l'école qui s'occupe de l'enseignement
secondaire
|
Ref_secondaire
Libelle
|
String
String
|
4
|
maternelle
|
Entité de l'école qui s'occupe de l'enseignement
primaire
|
Ref_maternelle
Libelle
|
String
String
|
5
|
Paie
|
L'opération de qui consiste à payer un agent
|
Ref_paie
Date_paye
Libelle paie
Montant_payé
|
String
String
String
integer
|
6
|
Avantage
|
Avantage que peut obtenir un agent
|
Code_avantage
Libelle_avant
montant
|
String
String
Integer
|
7
|
Prime
|
L'effet d'accorder une prime à l'agent
|
Code_prime
Montant_prime
Libelle_prime
|
String
String
Integer
|
8
|
Agent
|
Toute personne exerçant dans cette école
|
Matricule
Nom
Adresse
Qualification
Num_phone
Sexe
Etat civil
|
String
String
String
String
String
String
String
|
9
|
fonction
|
La fonction que peut avoir un agent
|
Code_fonction
Libelle_fonction
|
String
String
|
10
|
Personnel recru
|
Tout agent nouvellement recru
|
Num_recru
Date recru
|
String
String
|
11
|
Personnel effectif
|
Tout agent ayant une année scolaire d'ancienneté
|
date_engag
|
String
|
12
|
Promotion
|
La promotion que peut bénéficier un agent
|
Code_prom
Date_promotion
|
String
String
|
13
|
Obtenir
|
Ce que l'agent peut obtenir
|
Code_obtention
Date_obtention
|
String
String
|
14
|
Apprécier
|
L'appreciation d'un agent
|
Code_appréciation
Libelle_appréciation
|
String
String
|
15
|
Cotation
|
La cote que peut avoir un agent recru
|
Code_cotation
Date_cotation
Libelle_cotation
|
String
String
String
|
16
|
Administratif
|
C'est un agent qui s'occupe de l'administration
|
Date_d'affectation
|
String
|
17
|
Enseignant
|
Tout agent qui enseigne dans cette école
|
Date d'affectation
|
String
|
V.4. Modèle de classe
Les diagrammes de classes ont pour
rôle de modéliser les classes ou entités composant
notre application. Le diagramme de classes nous mène à la
solution finale et on retrouve le corps des différentes classes de notre
application. Tandis que les diagrammes d'objets servent
à modéliser les instances.
En approche orientée objet on utilise le concept de
classe, celle-ci permet de regrouper des objets de même nature.
Une classe est un moule (prototype) qui permet de
définir les attributs (champs) et les méthodes (comportement)
à tous les objets de cette classe.
Le modèle des classes d'UML saisit la
structure statique d'un système en montrant les objets dans le
système, les relations entre les objets, les attributs et les
opérations qui caractérisent chaque classe d'objets. C'est le
plus important des modèles d'UML
V.4.1. Quelques notions d'objets
et de classes
a. Encapsulation
Une information (données) ainsi que les comportements
(méthodes) sont encapsulés lors qu'elles sont à
l'intérieur d'une entité. L'encapsulation a pour rôle de
protéger le contenu des classes d'une manipulation maladroite ou mal
intentionnée.
Quand les attributs sont visibles (à la portée)
de tous, on dit qu'ils sont publics et symbolisé par un (+). Si une fois
ils sont protégés, on dira que les attributs n'est visible
seulement qu'aux sous-classes de la classe doivent être symbolisés
par un (#). Enfin, les attributs privés sont visibles à la classe
seule et le symbole utilisé est (-).
b. Héritage
L'héritage est un mécanisme de transmission des
propriétés d'une classe (ses attributs et méthodes) vers
une sous-classe, on parle d'une généralisation.
Une classe peut être spécialisée en
d'autres classes, afin d'y ajouter des caractéristiques
spécifiques ou d'en adapter certaines.
Plusieurs classes peuvent être
généralisées en une classe qui les factorise, afin de
regrouper les caractéristiques communes d'un ensemble de classes.
La spécialisation et la généralisation
permettent de construire des hiérarchies de classes. L'héritage
peut être simple ou multiple.
b. Le
polymorphisme
Le
polymorphisme représente
la faculté d'une méthode à pouvoir s'appliquer à
des objets de classes différentes.
c. Associations entre classes
Le langage UML définit le concept d'association entre
deux classes. Ce concept très intéressant, qui ne fait pas partie
des concepts élémentaires du paradigme objet, permet de
préciser les relations qui peuvent exister entre plusieurs objets.
En UML, une association se fait entre deux classes. Elle a un
nom et deux extrémités, qui Permettent de la connecter à
chacune des classes associées. Lorsqu'une association est définie
entre deux classes, cela signifie que les objets instances de ces deux classes
peuvent être reliés entre eux.
d. Agrégation
Il s'agit d'une relation entre deux classes, spécifiant
que les objets d'une classe sont des composants de l'autre classe. Une relation
d'agrégation permet donc de définir des objets composés
d'autres objets. Signalons que l'agrégation permet d'assembler des
objets de base, afin d'en construire des objets plus complexes.
e. Les cardinalités
Les cardinalités traduisent les possibilités de
participation (mini, maxi) d'une occurrence quelconque d'une entité aux
occurrences d'une association (donc des n-1 entités de sa
collection).C'est pour cela que cette participation se note sur le lien entre
l'entité et l'association.
Voici en quelques lignes les règles de passage
Transformation des classes : chaque classe du diagramme UML
devient une relation, il faut choisir un attribut de la classe pouvant jouer le
rôle de clé. Transformation des associations :
Nous distinguons trois familles d'associations
Association 1.. : il faut ajouter un attribut de type
clé étrangère dans la relation fils de l'association.
L'attribut porte le nom de la clé primaire de la relation père de
l'association.
Association *..* et n-aire et classes-association : la
classe-association devient une relation. La clé primaire de cette
relation est la concaténation des identifiants des classes
connectées à l'association.
Association 1.. 1 : il faut ajouter un attribut de type
clé étrangère dans la relation dérivée de la
classe ayant la multiplicité minimale égale à un.
L'attribut porte le nom de la clé primaire de la relation
dérivée de la classe connectée à l'association. Si
les deux multiplicités minimales sont à un, il est
préférable de fusionner les deux classes en une seule.
V.3.2. Formalisme d'une classe
Nom de la classe
Attributs
Méthodes
V.3.3. Présentation du modèle de classe
Avantage
Code_avantage
Libelle_avantage
Montant
1...*
1...*
Ecole
Ecole
Code_ecole
Nom_ecole
Adresse_ecole
Primaire
Ref_primaire
Libelle
Secondaire
Ref_secondair
Libelle
Administration
Date_affect
Enseignant
Date_affect
Obtenir
Code_obtention
Date_obtention
Cotisation
Code_cotation
Datecotation
Libelle_cotation
Apprécier
Personnel recrus
Num_recru
date_recru
Personnel effectif
Date_engag
Promotion
Code_promo
Date_promo
Prime
Code_prime
Libelle_prime
Montant prime
Agent
Cfr dictionnaire de données
Grade
Code_fonction
Libelle_fonction
Grade
Fonction
1...*
1...*
1...*
1...
1...*
1...*
Ecole
Maternelle
Ref_maternell
Libelle
Paie
Ref_paie
Date paie
Libelle paie
Montant_ paie
1...*
1...*
1...*
1...*
Ecole
Ecole
Code_ecole
Nom_ecole
Adresse_ecole
Primaire
Ref_primaire
Libelle
Secondaire
Ref_secondair
Libelle
Administration
Date_affect
Enseignant
Date_affect
Obtenir
Code_obtention
Date_obtention
Cotisation
Code_cotation
Datecotation
Libelle_cotation
Apprécier
Personnel recrus
Num_recru
date_recru
Personnel effectif
Date_engag
Promotion
Code_promo
Date_promo
Prime
Code_prime
Libelle_prime
Montant prime
Agent
Cfr dictionnaire de données
Grade
Code_fonction
Libelle_fonction
Grade
Fonction
1...*
1...*
1...*
1...
1...*
1...*
Ecole
Maternelle
Ref_maternell
Libelle
Paie
Ref_paie
Date paie
Libelle paie
Montant_ paie
1...*
1...*
Avantage
Code_avantage
Libelle_avantage
Montant
codec
V.4. Diagramme d'état
V.4.1.Rôle
Ce diagramme sert à représenter des automates
d'états finis, sous forme de graphe d'états, reliés par
des arcs orientés qui décrivent les transitions. Les diagrammes
d'états-transitions permettent de décrire les changements
d'états d'un objet ou d'un composant, en réponse aux interactions
avec d'autres objets/composants ou avec des acteurs.
Un état se caractérise par sa durée et sa
stabilité, il représente une conjonction instantanée des
valeurs des attributs d'un objet. Une transition représente le passage
instantané d'un état vers un autre. Une transition est
déclenchée par un événement. En d'autres termes :
c'est l'arrivée d'un événement qui conditionne la
transition. Les transitions peuvent aussi être automatiques, lorsqu'on ne
spécifie pas l'événement qui la déclenche.
En plus de spécifier un événement
précis, il est aussi possible de conditionner une transition, à
l'aide de "gardes" : il s'agit d'expressions booléennes,
exprimées en langage naturel (et encadrées de crochets).
V.4.2. Formalisme19(*)
V.4.3. Présentation du diagramme d'état
Evaluer recru
Evaluer agent
Afficher les agents recrus
[Cot =75%]
Rejeter l'agent
Evaluer l'agent _recrus
[Cot =75%]
[Fin]
Agent recrus accepté
[Fin]
CHAPITRE VI : ANALYSE D'APPLICATION
VI.1.introduction
L'aspect comportemental d'une application orientée
objet est défini par la façon dont interagissent les objets qui
composent l'application. À l'exécution, l'objet est
l'entité de base d'une application. Les objets qui composent une
application pendant son exécution et leurs échanges de messages
permettent à l'application de réaliser les traitements pour
lesquelles elle a été développée.
UML propose plusieurs vues permettant de définir les
interactions entre objets. Une de ces vues permet de présenter des
exemples d'interaction entre plusieurs objets.
VI.2.CAS D'UTILISATION
VI.2.1. Introduction
Un cas d'utilisation spécifie une fonction offerte par
l'application à son environnement. Un cas d'utilisation est
spécifié uniquement par un intitulé.
Bien souvent, la maîtrise d'ouvrage et les utilisateurs
ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer
leurs besoins. C'est précisément le rôle des diagrammes de
cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les
besoins, et de recenser les grandes fonctionnalités d'un système.
20(*)
Un diagramme de cas d'utilisation capture le comportement d'un
système, d'un sous-système, d'une classe ou d'un composant tel
qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité
du système en unités cohérentes, les cas d'utilisation,
ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le
besoin des utilisateurs d'un système, ils sont donc une vision
orientée utilisateur de ce besoin au contraire d'une vision
informatique.21(*)
Lien
VI.2.2. Formalisme22(*)
Cas d'utilisations
Lien
Acteur
Cas d'utilisations
Acteur
a. Identification des acteurs
· Le secrétaire ;
· Le chef de section
· Le père curé
b. Identification de cas d'utilisation
Cas d'utilisation
|
Acteurs
|
Gérer les agents effectifs et le recrus
|
Secrétaire
|
Afficher
|
Secrétaire
|
Enregistrer
|
Secrétaire
|
Pointage
|
Chef de section
|
Authentification
|
Secrétaire
|
Mise à jour
|
Secrétaire
|
Evaluer le recrus
|
Chef de section
|
Calculer les avantages
|
Secrétaire
|
Calculer les dettes
|
Secrétaire
|
Calculer le salaire
|
Secrétaire
|
Valider la paie
|
Père curé
|
VI.2.3. Présentation du diagramme de cas
d'utilisation
Nous allons tracer 2 diagramme de cas d'utilisation pour
raison d'espace et de la compréhension du graphique.
1er Diagramme de cas d'utilisation
Gestion du personnel
Gérer les agents effectifs et les recrus
Evaluer les recrus
Enregistrer
Authentification
Afficher_les recru
Pointage
« include»
« include»
« include»
Mise à jour
Secrétaire
Chef de section
2ème Diagramme de cas d'utilisation
« extend »
SSecrétaire
Père curé
La paie
Calculer les avantages
Calculer salaire
Calculer les dettes
Consulter le nombre de présence
Afficher la liste de paie
Afficher la liste de paie
Authentification
Valider la paie
Afficher les dettes
VI.2.Diagramme de séquence
VI.2.1. Introduction
Dans une application orientée objet, les objets
communiquent par échanges de messages. Le message le plus important est
le message de demande de réalisation d'opération, par lequel un
objet demande à un autre objet (ou à lui-même) de
réaliser une des opérations dont il est responsable. En
théorie, avec ce message seul, il est possible de décrire
complètement le comportement d'une application.
L'aspect comportemental d'une application orientée
objet est défini par la façon dont interagissent les objets qui
composent l'application. À l'exécution, l'objet est
l'entité de base d'une application. Les objets qui composent une
application pendant son exécution et leurs échanges de messages
permettent à l'application de réaliser les traitements pour
lesquelles elle a été développée.
VI.2.2. Formalisme23(*)
Acteur
Message 3
Message 2
Message 1
Acteur
Système
VI.2.3. Présentation du diagramme de
séquence
1er Diagramme de
séquence
Impression de fiche de paire
Enregistrement des emprunts
Enregistrement des informations des agents
Impression de toutes les listes
Enregistrement de présences
Impression de liste des agents
Chef de section
Système
Calcul de salaire
Secrétaire
Père curé
2ème Diagramme de
séquence
Chef de Section
Secrétaire
Curé
Impression de cote de recrus
Enregistrement de cotes de recrus
Enregistrement de recrus
Calcul de cotes de recrus
Système
VI.3.Diagramme d'activité
Les diagrammes d'activités sont utilisés pour
illustrer les flux de travail dans un système, du niveau métier
jusqu'au niveau opérationnel, Ils sont créés dans les
activités, qui sont elles-mêmes créées dans les
packages, les classes, les interfaces, les acteurs, les cas d'utilisation, les
composants et les collaborations.
VI.3.1. Formalisme24(*)
Activité 1
Activité composée
Activité 1
VI.3.2. Présentation du diagramme d'activité
OOUI
Besoins ressentis et propositions d'offres
Candidature déposée
nNON
OUI
Enregistrement de candidats
NON
OK
Sélectionné
Suivi et observation de candidat (recru)
Prestation Médiocre
Enregistrement
Promotion
Prestation parfaite
Prestation non parfaite
Participation au test
CHAPITRE VII : CONCEPTION DU SYSTEME
Elle met en place les grands blocs applicatifs, la conception
reprend les modèles de l'analyse statique et dynamique l'organisation
des classes suivant le langage cible. Il met en relief les composants de
l'application et son déploiement dans différents postes
utilisateurs.
VII.1. Modèle statique du système
Une fois nous achevons la phase d'analyse en
déterminant ce que l'implémentation doit réaliser,
l'étape de la conception du système va déterminer comment
cette implémentation sera réalisée. Dans ce cas il faudra
adapter le modèle par rapport au langage cible. Comme modèle
débouche à une base des données et que le concept
orienté objet s'applique bien aux bases des données qu'à
la programmation, et aussi nous pouvons implémenter des modèles
UML non seulement avec les bases de données orienté objet mais
aussi avec des bases de données relationnelles.
Nous utilisons le langage standard SQL (Structured Query
Language) afin de traduire le modèle de classe en modèle
relationnel correspondant aux tables dans la base des données. Ainsi
notre base de données résultante est performante,
cohérentes et extensible.
VII.1.2. Diagramme de classe de conception
1...*
1...*
Ecole
Ecole
Code_ec :string
Nom_ec : string
Adresse_ec : string
Primaire
Ref_prim : string
Libelle : string
Secondaire
Ref_sec : string
Libelle : string
Administration
Date_affect : string
Enseignant
Date_affect :string
Obtenir
Code_obt :string
Date_obt :string
Cotisation
Code_cot : string
Datecot: string
Libelle_cot:string
Apprécier
Code_appr: string
Libelle appr: string
Personnel recrus
Num_recru : string
date_recru : string
Personnel effectif
Date_engag : string
Promotion
Code_prom : string
Date_prom : string
Prime
Code_prim : string
Libelle_prim : string
Montant prim : int
Agent
Cfr dictionnaire de données
Grade
Code_fonct : string
Libelle_fonct :string
Grade
Fonction
1...*
1...*
1...*
1...
1...*
1...*
Ecole
Maternelle
Ref_mat : string
Libelle : string
Paie
Ref_paie
Date paie
Libelle paie
Montant_ paie
1...*
1...*
Avantage
Code_avant : string
Libelle_avant :string
Montant : integer
VII.1.3.Choix de l'architecture de réseau
Le réseau informatique est une technique qui consiste
à relier un certain nombre de matériel informatique (ordinateur
et périphérique) dans l'objectif de partager les ressources des
ce derniers (ordinateur et périphérique).
Pour permettre à notre logiciel de bien fonctionner en
tenant compte de l'emplacement géographique de différent bureau
de notre école, nous avons opté pour un réseau local avec
une architecture client/serveur.
Cette architecture nous permettra de nous partagé les
ressources du serveur d'application pour être utilisé dans le
différent poste utilisateurs et d'imprimer en réseau
c'est-à-dire, avoir un serveur d'impression.
VII.1.4. Définition de concepts
Un serveur
d'application : Permet d'utiliser un programme sur un serveur
à partir de tous les postes clients simultanément, principalement
des applications qui utilisent des bases de données (gestion de
fabrication, commerciale, comptabilité, stock, ...). Ces applications
doivent être programmées pour gérer les partages.
Un serveur
d'impression : Partage des imprimantes. Actuellement,
différents modèles sont directement connectés à un
réseau Ethernet, des boîtiers spécifiques sont
également commercialisés.
Le réseau LAN : Il s'agit d'un
ensemble d'ordinateurs appartenant à une même organisation et
reliés entre eux dans une petite aire géographique par un
réseau, souvent à l'aide d'une même technologie.
VII.1.4. Diagramme de déploiement
En
UML, un
diagramme de déploiement est une vue statique qui sert à
représenter l'utilisation de l'infrastructure physique par le
système et la manière dont les composants du système sont
répartis ainsi que leurs relations entre eux. Les éléments
utilisés par un diagramme de déploiement sont principalement les
noeuds, les composants, les associations et les artefacts. Les
caractéristiques des ressources matérielles physiques et des
supports de communication peuvent être précisées par
stéréotype.
VII.1.4. Formalisme
LLAN
Poste de travail 1
Poste de travail 3
Composant 1
Composant N
VII.1.5. Identification des postes de travail, leurs
rôles et composants
a. Identification de poste de travail
Un poste de travail représente un type particulier
d'entité, il représente un ordinateur ou le poste auquel est
connecté un utilisateur d'application.
NN°
|
POSTE DE TRAVAIL
|
ROLE
|
11
|
SECRETAIRE
|
Pour enregistrer les différentes informations
|
22
|
CHEFS DE SECTION
|
Pour enregistrer le cote de recrus et les présences
journalières
|
23
|
PERE CURE
|
Pour suivre l'évolution et valider opérations de
paie
|
44
|
SERVEUR DE BASE DE DONNEES
|
Pour sauvegarder les informations
|
55
|
SERVEUR D'IMPRESSION
|
Pour imprimer dans le réseau
|
b. Identification des composants d'application
Un composant représente un composant logiciel
(paquetages, fichiers sources,
bibliothèques,
exécutables), des données (fichiers, bases de données) ou
encore d'éléments de configuration (paramètres, scripts,
fichiers de commandes). Les composants associés au diagramme de
déploiement décrit la dépendance entre composant du
système.
Composant 1 : gestion_agent,
Composant 2 : calcul_paie
Composant 3 : pointage
Composant 4 : Evaluer_recrus
Composant 5: validation_paie
Composant 6: etats_ paie
Composant 7: BDD_bernard
Composant 8 : module_impression
VII.1.6. Présentation du diagramme de
déploiement
Poste de travail 2
Poste de travail 1
Composant 3, 4
C omposant 1, 2
Chef de section
Père curé
LAN
LAN
Poste de travail 5
Composant 7
LAN
Serveur de base de données
LAN
Poste de travail 3
Poste de travail 4
C omposant 5,6
Composant 8
Serveur de l'impression
Secrétaire
VI.1.7. Cout du projet
Pour budgétiser notre projet, nous vous
présentons les tableaux de budgétisation avec comme unité
monétaire le dollar américain.
MATERIEL
|
N°
|
Désignation
|
Quantité
|
Prix unitaire
|
Prix total
|
1
|
Ordinateur Serveur
|
1
|
580
|
500
|
|
Ordinateur Client
|
3
|
400
|
1200
|
|
Une imprimante réseau
|
1
|
970
|
970
|
|
Switch (16 ports)
|
1
|
100
|
100
|
|
Câble UTP
|
110 m
|
65
|
65
|
|
Connecteur RJ45
|
30
|
0.2
|
6
|
|
Onduleur
|
5
|
80
|
400
|
LOGICIEL
|
|
My SQL
|
1
|
300
|
300
|
|
Windows server 2003
|
1
|
350
|
350
|
|
Kit JDK et Netbeans
|
1
|
200
|
200
|
|
Anti virus
|
1
|
100
|
100
|
FORMATION
|
|
Agent à former
|
5
|
50
|
250
|
TOTAL
4441$
|
CONCLUSION
L'information est devenue une valeur ; elle est source de
compétitivité pour les entreprises et organisations. Jacqueline
CALIXTE ne disait elle pas que : « l'entreprise ou l'administration ne
peut s'organiser et prospérer que si elle dispose des informations dont
elle a besoin, au moment où elle a besoin et sous une forme exploitable
par les moyens dont elle dispose »..
Rappelons que l'objectif de ce travail était de mettre
en place un système d'information pour la gestion du personnel.
Notre travail est débuté par le cadrage du
projet ensuite est venu l'étude d'opportunité et l'analyse du
système l'existant, ce qui nous a permis de fixer les anomalies à
éviter et les objectifs à réaliser pour avoir un
système satisfaisant. Puis, nous avons passé à la
spécification des besoins en s'appuyant au diagramme de contexte suivi
de l'analyse de l'application qui nous a donné l'accès à
l'étude conceptuelle de notre application selon une approche
orientée objet tout en se basant sur le langage UML.
Etant une oeuvre humaine, vos suggestions et remarques nous
seront les bienvenues et elles nous aideront à grandir...
BIBLIOGRAPHIE
a. OUVRAGES
1. J. Alain, R.Joli; réseaux
architectures protocoles, Applications Paris, interdiction, 1991, Page
21
2. J.P. MEINADIER ; Structure et fonctionnement des
ordinateurs, les éditions françaises, 1971, Page 5
3. MERLIN P, Tourisme et
aménagement touristique documentation, Paris 201, P 75
4. ISSABELLE MOUNIER ; UML2 Pour Les
Développeurs, EYROLLES, 2007, P7
5. G.Bressy et C. Konkuyt ;
Management et économie des entreprises, Editions SIREY, 2008, P
37
6. JUVENEL Romain ; Dossier d'analyse
UML, IRD, Montpelier 2006, P4
7. Fabio R, Leo L. UML 2 pratique de la
modélisation Palaiseau, France juin 2009, P25
b. WEBOGRAPHIE
1. Laurent AUDIBERT, cours d'UML 2.0, IUT.
Tiré du site
http://www-lipn.univ-paris13.fr/audibert/pages/enseignement/cours.htm
, consulté le 12 septembre 2011.
2. http://www.msn.fr consulté le
16/08/2011
c. NOTES DE COURS
1. OSOKONDA O ; Cours de Méthodes de
Recherche Scientifique, L1 Info ISS-Kin, 2009-2010
2. MANYA NDJADI L. Note de cours de Recherche
opérationnelle, G3 Informatique, UNIKIN, 2010-2011
3. MVIBUDULU KALUYIT , note de cours de conception
système d'information, L1 info, ISS/KIN, 2009-2010.
BASE DE DONNEES: `BASE`
Structure de la table `administratif`
CREATE TABLE `administratif` (
`code_adminis` int(11) NOT NULL auto_increment,
`date_admin` date NOT NULL,
PRIMARY KEY (`code_adminis`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
-- Structure de la table `agent`
CREATE TABLE `agent` (
`matricule` varchar(5) NOT NULL,
`nom` varchar(10) NOT NULL,
`adresse` varchar(20) NOT NULL,
`qualification` varchar(10) NOT NULL,
`phone` varchar(10) NOT NULL,
`sexe` varchar(5) NOT NULL,
`etat_civil` varchar(10) NOT NULL,
PRIMARY KEY (`matricule`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--
-- Contenu de la table `agent`
--
INSERT INTO `agent` (`matricule`, `nom`, `adresse`,
`qualification`, `phone`, `sexe`, `etat_civil`) VALUES
('AZE3', 'KASUSULA', 'LIMETE', 'ENSEIGNANT', '9837723',
'MASCU', 'MARIE');
-- Structure de la table `apprecier`
CREATE TABLE `apprecier` (
`code_appre` varchar(5) NOT NULL,
`libelle_appre` varchar(20) NOT NULL,
PRIMARY KEY (`code_appre`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `avantage`
CREATE TABLE `avantage` (
`code_av` varchar(5) NOT NULL,
`libelle_ava` varchar(20) NOT NULL,
`montant` int(11) NOT NULL,
PRIMARY KEY (`code_av`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `cotation`
CREATE TABLE `cotation` (
`code_cot` varchar(5) NOT NULL,
`libelle_cot` varchar(20) NOT NULL,
`date_cot` date NOT NULL,
PRIMARY KEY (`code_cot`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `ecole`
--
CREATE TABLE `ecole` (
`Code_ecole` varchar(10) NOT NULL,
`nom_ecole` varchar(10) NOT NULL,
`adress` varchar(20) NOT NULL,
PRIMARY KEY (`Code_ecole`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `enseignant`
CREATE TABLE `enseignant` (
`code_enseig` int(11) NOT NULL auto_increment,
`date_ense` date NOT NULL,
PRIMARY KEY (`code_enseig`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
-- Structure de la table `fonction`
CREATE TABLE `fonction` (
`code_fct` varchar(5) NOT NULL,
`libelle` varchar(10) NOT NULL,
PRIMARY KEY (`code_fct`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `maternelle`
--
CREATE TABLE `maternelle` (
`ref_maternelle` varchar(5) NOT NULL,
`libelle` varchar(20) NOT NULL,
PRIMARY KEY (`ref_maternelle`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `obtenir`
--
CREATE TABLE `obtenir` (
`code_obtention` varchar(5) NOT NULL,
`date_obtention` date NOT NULL,
PRIMARY KEY (`code_obtention`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `paie`
CREATE TABLE `paie` (
`ref_paie` int(11) NOT NULL auto_increment,
`libelle_paie` varchar(20) NOT NULL,
`date_paie` date NOT NULL,
`montant` int(11) NOT NULL,
PRIMARY KEY (`ref_paie`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
-- Structure de la table `personne_effectif`
CREATE TABLE `personne_effectif` (
`num_effect` int(11) NOT NULL auto_increment,
`personne_eff` varchar(20) NOT NULL,
PRIMARY KEY (`num_effect`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
-- Structure de la table `personne_recu`
CREATE TABLE `personne_recu` (
`num_recru` int(11) NOT NULL auto_increment,
`date_recu` date NOT NULL,
PRIMARY KEY (`num_recru`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
-- Structure de la table `primaire`
CREATE TABLE `primaire` (
`ref_primaire` varchar(5) NOT NULL,
`libelle` varchar(20) NOT NULL,
PRIMARY KEY (`ref_primaire`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `prime`
CREATE TABLE `prime` (
`code_prime` varchar(5) NOT NULL,
`libelle` varchar(20) NOT NULL,
`montant` int(11) NOT NULL,
PRIMARY KEY (`code_prime`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Structure de la table `promotion`
--
CREATE TABLE `promotion` (
`code_promo` varchar(5) NOT NULL,
`date_promo` date NOT NULL,
PRIMARY KEY (`code_promo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `secondaire` (
`ref_secondaire` varchar(5) NOT NULL,
`libelle` varchar(10) NOT NULL,
PRIMARY KEY (`ref_secondaire`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Table des matières
0. INTRODUCTION GENERALE
1
0.1
Généralité
1
0.2. Présentation du sujet
2
0.3. Choix et intérêt du
sujet
2
0.4. Problématique et
Hypothèse
3
0.5. Délimitation du sujet
4
0.6. Méthodes et techniques
utilisées
4
0.7. Difficultés
rencontrées
5
0.8. Subdivision du travail
6
1.1. Introduction
7
1.2. Généralité sur
l'ordonnancement
7
CHAPITRE I : CADRAGE DU PROJET
7
1.3. Choix de la méthode de
planification
8
1.3.1. Présentation de la
Méthode PERT
8
1.3.2. Définition de concepts
clés
8
1.3.3. Identification de tâches
9
1.3.4. Description des taches
10
1.3.5. Présentation du graphe
11
1.3.6. Délai de réalisation du
projet
12
1.3.7. Calcul marge libre
12
1.3.8. Calcul marge totale
13
1.3.9. Détermination de chemin
critique
14
1.3.10. Planning prévisionnel de la
réalisation du projet
16
II.1. Historique de l'entreprise
18
II.2. Objectif
18
II.3. Situation géographique
18
CHAPITRE II : ETUDE D'OPPORTUNITE
18
II.4. Organigramme de l'entreprise
19
III.1. Introduction
1
III.2. Présentation du service
concerné
1
CHAPITRE III : ANALYSE DE L'EXISTANT
1
III.2.1. Organigramme du service
concerné
2
III.2.2. Présentation et description du
service concerné
2
III.3. Etude des ressources utilisées
3
3.3.1. Ressources humaines
4
3.3.2. Ressources matérielles
4
III.3.3. Ressources financières
5
III.4. Etude de documents utilisés
5
III.5. Etude de circuit des informations
7
III.6. BILAN CRITIQUE DE L'EXISTANT
8
III.7. Les orientations
9
III.8. Choix de solutions envisagées
10
IV.1. Introduction
11
IV.2. Définition des concepts
11
IV.2.1. Système
11
IV.2.2. Le système d'information
11
CHAPITRE IV : SPECIFICATION DES BESOINS
11
IV.2.3. Organisation
12
IV.2.4. Système opérant
13
IV.2.5. Système de pilotage
13
IV.2. Enoncé du problème
14
IV.3. Modèle de contexte
15
IV.3.1. Rôle
15
IV.3.2.Formalisme
15
IV.3.3. Présentation du diagramme de
contexte
16
V.1. INTRODUCTION
19
CHAPITRE V : ANALYSE DU DOMAINE
19
V.1.1. OBJECTIFS ET AVANTAGES DE L'APPROCHE
ORIENTEE OBJET
21
V.1.2. Illustration des axes utilises par UML
22
V.2. Le diagramme objet
22
V.2.1. Formalisme
23
V.2.2. Présentation du diagramme objet
24
V.3. Dictionnaire de données
25
V.4. Modèle de classe
27
V.4.1. Quelques notions d'objets et de classes
27
V.3.2. Formalisme d'une classe
30
V.3.3. Présentation du modèle de
classe
31
V.4. Diagramme d'état
32
V.4.1.Rôle
32
V.4.2. Formalisme
32
V.4.3. Présentation du diagramme
d'état
33
VI.1.introduction
34
VI.2.CAS D'UTILISATION
34
VI.2.1. Introduction
34
CHAPITRE VI : ANALYSE D'APPLICATION
34
VI.2.2. Formalisme
35
VI.2.3. Présentation du diagramme de cas
d'utilisation
37
VI.2.Diagramme de séquence
39
VI.2.1. Introduction
39
VI.2.2. Formalisme
39
VI.2.3. Présentation du diagramme de
séquence
40
VI.3.Diagramme d'activité
42
VI.3.1. Formalisme
42
VI.3.2. Présentation du diagramme
d'activité
43
VII.1. Modèle statique du système
44
CHAPITRE VII : CONCEPTION DU SYSTEME
44
VII.1.2. Diagramme de classe de conception
45
VII.1.3.Choix de l'architecture de
réseau
46
VII.1.4. Définition de concepts
46
VII.1.4. Diagramme de déploiement
47
VII.1.4. Formalisme
47
VII.1.5. Identification des postes de travail,
leurs rôles et composants
48
VII.1.6. Présentation du diagramme de
déploiement
50
CONCLUSION
52
BIBLIOGRAPHIE
53
* 1 J.Alain,R. Joli;
Réseaux architectures protocoles, Applications;
Paris,Interédition,1991,Page 21
* 2 Idem
* 3 J.P. MEINADIER ;
Structure et fonctionnement des ordinateurs ;les éditions
françaises, 1971, Page 5
* 4 OSOKONDA O ; Cours
de méthodes de recherche scientifique, L1 Info ISS-Kin, 2009-2010
* 5 MERLIN P, Tourisme
et aménagement touristique documentation, Paris 2001,P 75
* 6 OSOKONDA O ; Op
cit
* 7 ISSABELLE MOUNIER ;
UML2 pour les développeurs, EYROLLES,2007,P7
* 8 MANYA NDJADI L.. Note de
cours de Recherche opérationnelle, G3 Informatique, UNIKIN,
2010-2011
* 9 MVIBUDULU KALUYIT ,
note de cours de conception système d'information, L1 info, ISS/KIN,
2009-2010
* 10 MVIBUDULU KALUYIT, Op
cit
* 11 Idem
* 12 G.Bressy et C.
Konkuyt,Management et économie des entreprises, , Editions SIREY, 2008,
P 37
* 13 Juvenel Romain ;
Dossier d'analyse UML, IRD, Montpelier 2006, P4
* 14Laurent
AUDIBERT, cours d'UML 2.0, IUT. Tiré du site
http://www-lipn.univ-paris13.fr/audibert/pages/enseignement/cours.htm
, consulté le 12 septembre 2011.
* 15 Idem
* 16
http://www.msn.fr consulté le 16/08/2011
* 17 Laurent AUDIBERT, Op.
Cit.
* 18MVIBUDULU K., note de
cours de conception du système d'information, L2 conception, ISS-KIn,
2010-2011
* 19 Fabio R, Leo L. UML
2 pratique de la modélisation Palaiseau, France juin 2009, P25
* 20 Laurent AUDIBERT :
op cit
* 21 Laurent AUDIBERT :
Op. cit
* 22 Idem
* 23 Laurent AUDIBERT :
Op. cit
* 24 Fabio R, Leo L. Op.
Cit
|