WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception d?un système d?information pour la gestion du personnel dans un établissement scolaire, cas du complexe scolaire Saint Bernard »

( Télécharger le fichier original )
par Didier KAKESA MIHALA
Institut supérieur de statistique de Kinshasa -  2011
  

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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.

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 :

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 :

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(*)

IV.2.4. Système opérant

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

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

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






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il faudrait pour le bonheur des états que les philosophes fussent roi ou que les rois fussent philosophes"   Platon