Application de Gestion Des Bourses Scolaires (BONZI Philipe Soumboza)

ETUDE ET CONCEPTION D'UNE APPLICATION DE GESTION DES BOURSES SCOLAIRES OCTROYEES AUX AYANTS
DROIT DES PENSIONNES DECEDES
Remerciements
Nous tenons ici à témoigner notre reconnaissance et notre gratitude aux structures et
aux personnes sans lesquelles ce projet n’aurait jamais vu le jour
➢ Nous remercions l’Université Aube Nouvelle (U-AUBEN) pour le confort
pédagogique et pour la qualité de la formation que nous avons reçue.
➢ Nous exprimons nos vifs remerciements à l’endroit de toute l’équipe
pédagogique.
➢ Nous remercions également la direction de la CARFO, ainsi que toute son équipe,
pour l’expérience enrichissante et pleine d’intérêts qu’elles nous ont fait vivre
durant cette période de stage.
Nous tenons à remercier tout particulièrement et à témoigner toute notre
reconnaissance aux personnes suivantes :
➢ M. Youssouf LOYA, Directeur de high-tech à U-AUBEN pour sa générosité et
son accompagnement ;
➢ Mme Edwige Marie Eveline, Directrice Général de la CARFO, qui nous a
ouvert les portes de sa structure ;
➢ M. Noël BADO, Directeur des systèmes d’informations de la CARFO ;
➢ M. Karim KOMONDI, notre Directeur de Mémoire, Enseignant à U-AUBEN
qui nous a suivi et orienté durant la réalisation de notre projet ;
➢ M. Serge KONSIEGA, le superviseur de ce travail, notre maître de stage ;
➢ Tout le personnel administratif, pour l’effort et la patience accordée afin de
réussir notre projet ;
➢ Ma famille, qui m’a toujours soutenue, et en particulier, mes parents, pour leur
discernement, et leurs conseils ;
➢ Mes amis, pour leur soutien ;
➢ Tous ceux ayant participer de près ou de loin a l’élaboration du document
Université Aube Nouvelle Mémoire de fin de cycle : Option Technologie du Génie Informatique.
I
Table des matières

Remerciements ...................................................................................................................................
Table des matières ........................................................................................................................... II
Liste des tableaux ............................................................................................................................ V
Liste des figures ............................................................................................................................ VI
Sigles et abréviations .................................................................................................................... VII
INTRODUCTION GENERALE ...................................................................................................... 1
PARTIE I : GENERALITES ........................................................................................................... 3
CHAPITRE I PRESENTATION DU CONTEXTE DE STAGE ............................................... 4
I.1 Introduction : ....................................................................................................................... 4
I.2 Présentation de l’U-AUBEN............................................................................................... 4
I.3 Présentation de la structure d’accueil : ............................................................................... 6
I.4 Présentation du projet : ....................................................................................................... 9
I.5 Conclusion : ...................................................................................................................... 13
CHAPITRE II DEMARCHES ET MOYENS DE RESOLUTION .......................................... 14
II.1 Introduction ..................................................................................................................... 14
II.2 Exigences fonctionnelles et techniques ........................................................................... 14
II.3 Méthode de résolution du problème ................................................................................ 14
II.4) Conclusion :.................................................................................................................... 26
PARTIE II : MODELISATION ..................................................................................................... 27
CHAPITRE I : EXPRESSION DES BESOINS ............................................................................. 28
I.1) Introduction ..................................................................................................................... 28
I.2) Recueil des besoins fonctionnels ..................................................................................... 28
I.3) Recueil des besoins techniques ........................................................................................ 29
I.4) Conclusion ....................................................................................................................... 30
CHAPITRE II : MODELISATION DETAILLEE ....................................................................... 31
II.1) Introduction .................................................................................................................... 31
II.2) Diagramme de cas d’utilisation ...................................................................................... 31
II.3) Description textuelle des quelques cas d’utilisation....................................................... 37
II.4) Diagramme de Séquence ................................................................................................ 40
II.5) Diagramme de classe ...................................................................................................... 45
II
II.6) Diagramme d’activité ..................................................................................................... 49

II.7) Diagramme de déploiement ........................................................................................... 53
II.8) Conclusion ...................................................................................................................... 53
PARTIE III : DEVELOPPE-MENT DE L’APPLICATION ......................................................... 54
CHAPITRE I : SPECIFICATIONS TECHNIQUES .................................................................... 55
I.1) Introduction ..................................................................................................................... 55
I.2) L’architecture technique .................................................................................................. 55
I.3) Le SGBD ......................................................................................................................... 56
I.4) Environnement Développement ...................................................................................... 57
I.5) Matérielles ....................................................................................................................... 59
I.6) Conclusion ....................................................................................................................... 60
CHAPITRE II : SECURITE ............................................................................................................... 61
II.1) Introduction .................................................................................................................... 61
II.2) Sécurité logique .............................................................................................................. 61
II.3) Sécurité physique ........................................................................................................... 62
II.4) Conclusion ...................................................................................................................... 63
CHAPITRE III : PRESENTATION DES PRINCIPALES IHM ............................................... 64
III.1) Introduction ................................................................................................................... 64
❖ IHM Authentification ..................................................................................................... 64
❖ IHM d’accueil ................................................................................................................ 65
❖ IHM statistique ............................................................................................................... 66
❖ IHM de gestion des boursiers ......................................................................................... 67
❖ IHM de création de droit ................................................................................................ 68
❖ IHM de génération d’état : liste des utilisateurs ............................................................. 69
III.2) Conclusion .................................................................................................................... 70
CHAPITRE IV : Etude sociale et économique ................................................................................ 71
IV.1) Introduction................................................................................................................... 71
IV.2) Etude sociale ................................................................................................................. 71
IV.3) Etude économique ........................................................................................................ 71
IV.4) Présentation de la méthode COCOMO......................................................................... 72
IV.5) Formules du modèle COCOMO ................................................................................... 72
IV.6) Estimation des coûts ..................................................................................................... 73
IV.7) Rentabilité ..................................................................................................................... 74
IV.8) Conclusion .................................................................................................................... 74
III
Conclusion générale ....................................................................................................................... 75

REFERENCES Bibliographie et webographie .............................................................................. 76
Bibliographie........................................................................................................................................... 76
Webographie........................................................................................................................................... 76
Annexes ........................................................................................................................................... A
IV
Liste des tableaux

Tableau 1 Liste de tâches............................................................................................................... 12
Tableau 2 : Liste des cas d'utilisation ............................................................................................ 31
Tableau 1: Description textuelle du CU « S’authentifier » ........................................................... 38
Tableau 4 : Description textuelle du CU « Ajouter boursiers » .................................................... 38
Tableau 5 : Description textuelle du CU « Produire des statistiques » ......................................... 39
Tableau 6 : Description textuelle du CU « Créer des droits s » .................................................... 39
Tableau 7 : Règles de gestion ........................................................................................................ 45
Tableau 8 : Le dictionnaire de données ......................................................................................... 46
Tableau 9 : Liste des SGBD les plus demandés ............................................................................ 56
Tableau 10 : Formule du modèle COCOMO ................................................................................. 72
Tableau 11 : Estimation des coûts ................................................................................................. 73
V
Liste des figures

Figure 01 : Organigramme de la CARFO ........................................................................................ 8
Figure 02 : Diagramme prévisionnel .............................................................................................. 13
Figure 03 : Formalisme éléments de cas d’utilisation .................................................................... 16
Figure 04 : Formalisme d’un cas d’utilisation ............................................................................... 17
Figure 05 : Formalisme d’une classe .............................................................................................. 18
Figure 06 : Formalisme d’un diagramme de classe ........................................................................ 19
Figure 07 : Formalisme d’un objet et d’un acteur .......................................................................... 20
Figure 08 : Formalisme d’une Ligne de vie ................................................................................... 20
Figure 09 : Formalisme d’une période activation .......................................................................... 20
Figure 10 : Formalisme d’un diagramme de séquence .................................................................. 22
Figure 11 : Formalisme d’un Nœud ............................................................................................... 23
Figure 12 : Formalisme d’un Artefact ............................................................................................ 24
Figure 13 : Formalisme d’un diagramme de déploiement ............................................................. 24
Figure 15 : Diagramme de cas d’utilisation ................................................................................... 32
Figure 16 : raffinement de cas utilisation Gérer boursier ............................................................... 33
Figure 17 : raffinement de cas utilisation Gérer bulletin ............................................................... 34
Figure 18 : raffinement de cas utilisation Gérer système ............................................................... 35
Figure 19 : raffinement de cas utilisation Gérer tuteur .................................................................. 36
Figure 20 : raffinement de cas utilisation Gérer lien ...................................................................... 37
Figure 21 : Diagramme de séquence « S’authentifié » .................................................................. 41
Figure 22 : Diagramme de séquence « Ajouter boursiers » ........................................................... 42
Figure 23 : Diagramme de séquence « Produire des statistiques » ................................................ 43
Figure 24 : Diagramme de séquence « Créer des droits » .............................................................. 44
Figure 25 : Diagramme de classe ................................................................................................... 48
Figure 26 : Diagramme d’activité « S’authentifié » ....................................................................... 49
Figure 27 : Diagramme d’activité « Ajouter boursiers » ............................................................... 50
Figure 28 : Diagramme d’activité « Produire des statistiques » .................................................... 51
Figure 29 : Diagramme d’activité « Créer des droits » .................................................................. 52
Figure 30 : Diagramme de déploiement ......................................................................................... 53
Figure 31 : Page d’authentification ................................................................................................ 64
Figure 32 : Page d’accueil .............................................................................................................. 65
Figure 33 : Page statistique ............................................................................................................ 66
Figure 34 : Formulaire gestion des boursiers ................................................................................. 67
Figure 35 : Formulaire de création de droit .................................................................................... 68
Figure 36 : Génération d’état : liste des utilisateurs ....................................................................... 69
VI
Sigles et abréviations
2TUP Two Tracks Unified Process
AG Assemblée Générale
BD Base de Données
CU Cas d’Utilisation
CAMES Conseil Africain et Malgache pour l’Enseignement Supérieur
CARFO Caisse Autonome de Retraite des Fonctionnaires
COCOMO Constructive Cost Model
DIS Direction de l’Informatique et des Statistiques
DP Direction des Prestations
HM Homme Mois
IC Ingénieur de Conception
IDE Integrated Development Environment
IRS Ingénierie des Réseaux et Systèmes

IHM Interface Homme Machine
ISIG Institue supérieure d’Informatique et de Gestion
Java SE Java, Standard Edition
KLS Kilo Lignes Sources
LMD Licence Master Doctorat
SEDE Service Développement et exploitation
SN Scenario Nominal
SGBD Système de Gestion de Base de Données

SQL Structured Query Langage
U-AUBEN Université Aube Nouvelle
UML Unified Modeling Language
VII
INTRODUCTION GENERALE
L’Homme ayant travaillé pendant une longue période de sa vie pour son pays, devenu
moins vigoureux avec l’âge ou ne disposant plus de moyens physiques nécessaires pour
continuer à servir son pays mérite un repos. Afin de subvenir à ses besoins pendant cette
période dite de retraite, un mécanisme est nécessaire pour la mise en place d’un fonds.
Ainsi est – il important d’assister le travailleur tout au long de sa carrière pour qu’il puisse
s’auto suffire au moment où il se retire de la vie active.
C’est en cela que la CAISSE AUTONOME DE RETRAITE DES FONCTIONAIRES
(CARFO) qui a bien voulu nous recevoir pour notre stage, s’occupe de la gestion de la
retenue pour pension des employés du secteur public et des collectivités locales. Cette
retenue est obtenue en associant les contributions de l’employé et de l’employeur tout
le long de sa carrière.
Malheureusement on enregistre des cas de décès de retraités. Dans de pareilles situations

et sous certaines conditions, une pension temporaire d'orphelin ou une pension aux
ayants droits du regretté est octroyée.
La CARFO exerçant dans un domaine social, a le souci d’assister les pensionnés pour
lesquels elle travail. Pour ce faire, elle a mis en place durant l’année scolaire 2007-2008
un système de bourse d’une valeur de cent mille Francs CFA (100000 FCFA) destiné
exclusivement aux filles dont quatre-vingt une (81) en étaient bénéficiaires. Le nombre
de ces bourses n’a cessé d’augmenter. Ainsi on en dénombrait cinq cent (500) pour le
compte de l’année scolaire 2013-2014. Pour celle en cours il a été décidé d’étendre ces
bourses aux deux sexes d’où l’atteinte du nombre de quatre mille trois cents dix-sept
(4317) boursiers à nos jours. Chaque année donc cinq cent (500) nouveaux orphelins
sont alors choisis selon un certain nombre de critères pour bénéficier de cette bourse.
Afin de permettre un suivi approprié de la gestion de ces bourses, il serait nécessaire

d’abandonner la gestion manuelle dont fait l’objet ce système de bourse vers une gestion
automatisée. C’est cette raison qui a guidé la CARFO à me proposer le thème suivant :
« ETUDE ET CONCEPTION D'UNE APPLICATION DE GESTION DES
BOURSES SCOLAIRES OCTROYEES AUX AYANTS DROIT DES
PENSIONNES DECEDES PAR LA CARFO. » Il vise à proposer un outil permettant
le suivi des bourses en s’appuyant sur les technologies JSE (Java, Standard Edition).
Ce stage permettra de mettre en pratique les compétences acquises durant la formation
à U-AUBEN afin de nous préparer à une vie professionnelle qualifiante et compétitive
dans un monde sans cesse en perpétuel recherche d’innovation.
Université Aube Nouvelle Mémoire de fin de cycle : Option Technologie du Génie Informatique
1
L’application que nous avons développé nommée SG-BOURSES a été réalisée en

s’appuyant sur des outils, des méthodes de modélisation et de programmation orientée
objets. Il s’agît d’une application permettant d’avoir des informations à temps réels sur
les boursiers et les tuteurs, de les localiser et de générer des statistiques fiables. Une base
de données sur les tuteurs et les ayants droit est associée à SG-BOURSES.
Ce rapport s’articule autour de huit (8) chapitres divisés en trois (3) partis. Le premier
chapitre présente les structures de formation et d’accueil avant d’exposer le projet. La
seconde traite de la démarche et des moyens de résolution. Le troisième chapitre a pour
objet : l’analyse du domaine d’étude. Le quatrième chapitre fait cas des spécifications du
futur système. Quant au cinquième chapitre, il permet de détailler l’architecture du futur
système. Ensuite, le sixième chapitre résume la conception de la solution. Le septième
chapitre présente quelques résultats attendus. Enfin le huitième chapitre porte sur
l’étude budgétaire du projet.
2
PARTIE I :
GENERALITES
3
CHAPITRE I PRESENTATION DU
CONTEXTE DE STAGE
I.1 Introduction :
L’Université Aube Nouvelle exige un stage de trois (03) mois minimum à ses étudiants
en fin de cycle afin de valider leur cursus. Ce stage leur permet de mettre en pratique les
compétences acquises durant la formation afin de se préparer à une vie professionnelle
épanouie.
Ainsi, dans ce chapitre il sera question de présenter le contexte du stage, les objectifs,
les résultats attendus, les moyens adoptés pour la mise en œuvre et la planification de
l’exécution du projet. Cependant, il convient tout d’abord de présenter la structure de
formation, ainsi que l’entreprise d’accueil.
I.2 Présentation de l’U-AUBEN
I.2.1 Présentation générale

L’Institut Supérieur d'Informatique et de Gestion (ISIG) a ouvert ses portes en octobre
1992, par l’arrêté N°092-125/ESSRS3/DCHEP3DEST du 21-10-1992 sous le statut
d’entreprise personnelle. Et ses modifications arrêté N°2003-
089/MESSRS/SG/DGESRS/CNESSP/SP du 16 mai 2003 et arrêté
N°2005244/MESSRS/CAB du 2 décembre 2005 confère à l’ISIG le statut de personne
morale au capital de 50 000 000 francs CFA. Elle débute avec L’informatique de gestion
comme première filière. En 2004 un second détachement a été ouvert à Bobo Dioulasso
pour promouvoir la décentralisation et permettre à plus de personnes d’avoir accès à
une formation supérieure de qualité. Une annexe fut Ouverte à Ouagadougou depuis la
rentrée académique 2009-2010 pour améliorer encore les conditions d’étude et de
travail.
L’ISIG-INTRENATIONAL devenue UNIVERSITE AUBE NOUVELLE (U-
AUBEN) par autorisation n° 20120000344/MESS/SG/DGESR/DIEPR du 17 février
2012, est un établissement d’enseignement supérieur privé membre de CAMES.
4
Les diplômes qui y sont délivrés ont les grades de : DUT, Licence, Master et Doctorat.
Avec plus de 26 diplômes homologués par le Conseil Africain et Malgache pour
l’Enseignement Supérieur (CAMES).
Le siège de l'U-AUBEN est situé au cœur du quartier 1200 logements, de la ville de

Ouagadougou au Burkina Faso avec Une infrastructure moderne et des bâtiments à la
pointe de la technologie équipée de Wifi, d’une salle multimédia…U- AUBEN est une
université reconnue sur le plan international. Il existe en son sein près de 30 nationalités.
Pour assurer une meilleure qualité de formation, l’Université Aube Nouvelle a signé de
nombreux partenariats avec des universités et institutions d'enseignement supérieur,
scientifiques et de recherche, aussi bien en Amérique, en Europe, en Asie qu'en Afrique.
I.2.2 Formation :
Elle est composée d’instituts, d’écoles et des Unités de Formation et de Recherche
(UFR). L'université aube nouvelle comprend :
➢ Six (06) UNITÉS DE FORMATION ET DE RECHERCHE (UFR) :

• Langues, lettres, sciences humaines et sociales ;
• Sciences économiques et de gestion ;
• Sciences juridiques et politiques ;
• Sciences de l’ingéniorat ;
• Sciences de l’éducation et professorat ;
• Sciences de la santé.
➢ Une (01) ÉCOLE DOCTORALE ;
➢ Six (04) CENTRES :

• American Language Center (ALC) ;
• Laboratoire de langues (TOEIC) ;
• Une Académie CISCO ;
• Un centre C2i.
5
I.3 Présentation de la structure d’accueil :

I.3.1 Organisation interne de la CARFO :
I.3.1.1 Historique
L’histoire de la CARFO remonte très loin, avant les indépendances. A cette époque, il
n’existait pas en Haute Volta de régime de retraite encore moins de Caisse de retraite.
La gestion des pensions de retraite était confiée à une section de la direction du budget,
qui avait pour tâche d’assurer le traitement des dossiers des pensions constitués par les
fonctionnaires.
A cette époque, les fonctionnaires étaient affiliés à deux organismes de retraite
différents. Le premier appelé Caisse Locale de Retraite (CLR) avait son siège à Dakar et
gérait le régime de retraite des fonctionnaires des anciens cadres locaux de l’ex Afrique
occidentale française (A.O.F). Le second, dénommé Caisse de retraite de la France
d’outre-mer (CRFOM) qui avait son siège à Paris était chargé de la gestion du régime de
retraite des fonctionnaires des anciens cadres généraux et supérieurs des ex Territoires
d’outre-mer (TOM). En 1959, ces caisses furent dissoutes pour laisser la liberté à chacun
des nouveaux Etats indépendants l’initiative de la mise en place de son propre système
de retraites et d’en assurer la gestion. C’est ainsi que le Burkina Faso, à l’instar des autres
ex- colonies a procédé à la mise en place progressive d’un dispositif juridique et
organisationnel permettant la prise en charge de la retraite des agents de l’Etat.
Cependant, en lieu et place d’une caisse des pensions proprement dite, c’est un service
des pensions dont l’organisation et le fonctionnement ont été définis par l’arrêté n°
271/MF/B/DIR/F8 du 13/10/61. Mais au fil des ans, des problèmes de gestion sont
apparus compte tenu du nombre grandissant de pensionnés.
On peut citer entre :
➢ la non maîtrise du volume des dépenses ;
➢ le manque d’infrastructures adéquates ;
➢ l’inexistence de statistiques ;
➢ l’absence de données sur les cotisations pour pension ;
➢ etc.
De ce constat, il est apparu nécessaire de créer une structure autonome avec pour
mission de gérer les pensions. D’où la naissance de la CARFO. Créée en 1986 sous la
forme juridique d’un Etablissement public à caractère industriel et commercial doté de
la personnalité juridique et de l’autonomie financière, la Caisse autonome de retraite des
fonctionnaires, en abrégé CARFO, a été transformée en un Établissement public de
prévoyance sociale (EPPS) par décret n° 2008-155/PRES/PM/MFPRE/MEF du 3
avril 2008. Elle est régie par la loi N° 016-2006/AN du 16 mai 2006 portant création de
la catégorie d’Établissements publics de prévoyance sociale et le décret n° 2008-
6
156/PRES/PM/MFPRE/MEF du 3 avril 2008 approuvant ses statuts particuliers. Bien

que créée en 1986, la CARFO n’a démarré ses activités de façon autonome qu’en 1989.
I.3.1.1 Missions et Objectif
La CARFO a pour objet la gestion :

- du régime de retraite des fonctionnaires, militaires et magistrats, institué par la loi n°
47/94/ADP du 29 novembre 1994 portant régime général de retraite des
fonctionnaires, militaires et magistrats, étendu aux agents contractuels de la fonction
publique recrutés à partir du 1er janvier 1999 à travers la loi n° 006-2001/AN du 17 mai
2001 ;
-du régime de prévention et de réparation des risques professionnels institué par la loi
n° 022/2006/AN du 16 novembre 2006 portant régime de prévention et de réparation
des risques professionnels applicables aux agents de la Fonction publique, aux militaires
et aux magistrats ;
-de tout autre régime qui viendrait à être créé par la loi.
Se fondant sur la mission qui lui est assignée, la CARFO sert actuellement les prestations
suivantes :
➢ la pension de retraite ;
➢ la pension d’invalidité ;
➢ la pension de survivants (veuves/veufs et orphelins) ;
➢ les remboursements des retenues pour pension
Il est prévu très prochainement que la CARFO fournisse les prestations suivantes au
titre des accidents du travail et des maladies professionnelles :
➢ l’assistance médicale, chirurgicale, pharmaceutique hospitalière et accessoires ;
➢ la fourniture, l’entretien, le renouvellement et la réparation des appareils de
prothèse ;
➢ le paiement des rentes d’incapacité ;
➢ le paiement des rentes de survivants ;
➢ la rééducation professionnelle, la réadaptation fonctionnelle ;
➢ la prise en charge du transport et des frais de séjour pour soins.
Outre les activités liées à son objet social, la CARFO assure par ailleurs la liquidation et
le payement des capitaux décès pour le compte de l’État. Cette prestation n’est donc pas
à la charge de la CARFO mais de l’État qui en assure le financement.
La pension est payée actuellement trimestriellement aux guichets de la CARFO à
Ouagadougou ou auprès des services déconcentrés du Trésor public (trésoreries et
perceptions) dans les autres localités, aux échéances suivantes : mars, juin, septembre et
décembre.
7
I.3.2 Organigramme
Figure 01 : Organigramme de la CARFO
I.3.3 La Direction du Système d’Information

La Direction du Système d’Information de la CARFO est composée de deux services, à
savoir :
➢ Le Service développement et exploitation (SEDE) ;
➢ Le Service réseau, sécurité et maintenance (SRSM) ;
Nous avons effectué notre stage dans cette direction plus précisément au niveau de
service de Développement Informatique (SDI).
La Direction des systèmes d’information est chargée :

➢ du suivi du bon fonctionnement du système de gestion informatisé et de
télécommunication de la CARFO ;
➢ de la gestion du site WEB de la CARFO ;
➢ de la mise en œuvre de la politique informatique de la CARFO ;
➢ de l’étude et le suivi des projets informatiques ;
➢ du suivi de l’administration du réseau informatique ;
8
➢ du suivi de l’exploitation et de la maintenance du réseau ;

➢ de la réalisation du schéma directeur informatique de la CARFO ;
➢ de l’élaboration d’une politique de choix des matériels informatiques ;
➢ de la mise en place d’un système de sécurité informatique ;
➢ de la coordination des actions de formation du personnel en informatique ;
➢ de la diffusion des technologies de l’information et de la communication au sein
de la CARFO et la formation des utilisateurs de ces technologies ;
➢ de la gestion du parc informatique de la CARFO en relation avec la Direction du
Patrimoine et des marchés Publics ;
➢ de l’édition des documents techniques ,
➢ de l’appui technique aux autres directions en matière informatique.
I.4 Présentation du projet :

Le stage effectué dans l’entreprise a pour objectif d’introduire l’étudiant à la vie
professionnelle.
Ce stage, la rédaction d’un mémoire et la conception d’une application sont
indispensables à l’obtention de la licence d’ingénieur informatique.
Notre travaillent porte sur la gestion des bourses scolaires octroyées à des orphelins,
étant des ayants droit des pensionnés décédés de la CARFO.
I.4.1 Problématique :
Chaque année La CAISSE AUTONAME DE RETRAITE DES FONCTIONAIRES
(CARFO) octroie cinq cent bourses scolaires aux ayants droit des pensionnés décédés
dont le montant de la pension trimestrielle est inférieur à 75 000 FCFA.
Les orphelins concernés par l’attribution de bourses sont ceux étant dans des classes de
collège ou de lycée, n’étant pas âgé de plus de 22 (vingt-deux) ans et dont la joignabilité
est juger acceptable. Aussi le critère social prime dans le choix de ses boursiers.
Le renouvèlement de bourse pour les orphelins retenus, est soumis à certaines
conditions :
➢ obligation d’apporter leur résultat en fin d’année scolaire ;
➢ l’orphelin doit valider son année et ne doit pas être en fin de cycle du lycée ;
➢ l’orphelin ne doit pas avoir atteint l’âge des personnes exclus ;
➢ l’orphelin ne doit pas être à son troisième redoublement, dans le même cycle.
L’organisation et la gestion de ces bourses sont effectuées à l’aide de logiciels
bureautique en enregistrant les différentes informations concernant les boursiers dans
des registres et aussi électroniquement à l’aide des logiciels, en particulier Microsoft
Excel. Les opérations effectuées sont pour la plupart des opérations d’ajout, de
modification, et de suppression sur les boursiers ainsi que leur tuteur.
9
Cette situation n’est pas optimale et pose plusieurs soucis tels que :
➢ un grand risque d’erreurs sur plusieurs plans du fait de la non automatisation des
processus ;
➢ un travail difficile et fastidieux vue le nombre de personnes concernées et la
méthode ne permettant pas le suivi des boursiers qui réside dans les différentes
régions du pays et aussi quelque foi à l’étranger ;
➢ divers problèmes de fiabilité de contrôle et de sécurité sur le registre et les
fichiers ;
➢ un manque de fonctionnalité dédie tels que la recherche, l’édition de statistiques
et La génération de l’état global des boursiers à une date donnée et avec des
informations prévisionnelles et bien autre ,
➢ la possibilité de connaitre à un instant donné et pour tout boursier l’année
d’expiration des bourses.
Ainsi les logiciels de bureautiques utilisés, bien que puissants se révèlent inefficaces dans
la gestion appropriée de ces boursiers car ils ne permettent pas de satisfaire certains
besoins capitaux.
Afin de permettre une gestion et un suivi de qualité des bourses, l’implémentation d’une
application simple, robuste et conviviale s’impose comme une solution idoine pour
pallier aux difficultés et faciliter le suivi de ces boursiers de la CARFO.
I.4.2 Objectifs de l’étude :

I.4.2.1 Objectifs global :
Il s’agira de développer une application de gestion des bourses qui devra permettre :
➢ la gestion des bourses ;
➢ d’avoir des informations précises ;
I.4.2.2 Objectifs spécifiques :

Plus spécifiquement l’application devra permettre de :
➢ automatiser les traitements ;
➢ sécuriser les différents processus et les données ;
➢ modifier et de mettre à jour les résultats et les différentes informations sur les
bourses ;
➢ réaliser des statistiques (annuaires statistiques), leur permettant ainsi de suivre
l’évolution des boursiers ;
➢ répondre aux exigences techniques définis.
10
I.4.3 Résultats attendus :

Au regard des objectifs du projet, il est attendu :
➢ une application de suivi des bourses simple et robuste ;
➢ une base de données des boursiers et des différentes informations qui leur sont
rattachés ;
➢ un system sécurisé ; sûr et fiable qui respecte l’intégrité des données ;
➢ des fonctionnalités utiles qui simplifient et facilitent le travail ;
➢ pouvoir avoir des traces des différentes actions et modifications exécutées ;
➢ un rapport d’analyse et de conception détaillé.
I.4.4 Gestion du projet :

I.4.4.1 Acteurs du projet :
Les acteurs du projet représentent l’ensemble des personnes qui participeront à sa

réalisation. Ils sont organisés en trois groupes.
a) Le groupe de pilotage
Le groupe de pilotage est chargé de veiller au bon fonctionnement du projet. Il valide
les grands choix techniques, les délais à respecter et les résultats attendus.
Il est constitué de :
➢ Monsieur Noel BADO, Directeur des Systèmes Informations de la CARFO ;
➢ Monsieur Aboudou TRAORE, Chef de Service développement et exploitation à
la CARFO ;
➢ Monsieur W. Serge Franck Amel KONSIEGA, le superviseur de ce travail, notre
maître de stage ;
➢ Monsieur Nazaire OUATTARA, Directeur des Prestation de CARFO ;
➢ Monsieur François D’assise OUATTARA, Chef de Service des Risques
Professionnels à la CARFO ;
b) Le groupe de projet
Le groupe de projet est chargé de l’exécution du projet, c’est à dire de procéder à
l’analyse, la conception, la réalisation et le déploiement de l’application. La validation
des différents rapports sur l’avancement du projet est effectuée par le groupe de pilotage.
11
Le groupe de projet est constitué de :

➢ BONZI Philippe Soumboza, étudiant en 3eme année à U-AUBEN.
c) Le groupe des utilisateurs

Le groupe des utilisateurs est formé de l’ensemble des personnes susceptibles d’interagir
avec le système. Il joue un rôle important et permet :
➢ la capture des besoins
➢ la validation des fonctionnalités développées.
Il est constitué par :

➢ les agents de la Direction des Prestations de la CARFO ;
I.4.4.2 Planning prévisionnel :

La réalisation d’un projet passe par l’établissement et le respect d’un planning
prévisionnel bien défini en accord avec le groupe de pilotage. A cet effet, il est
impérativement nécessaire de faire l’inventaire de toutes les tâches à réaliser, les
contraintes auxquelles elles sont soumises afin de respecter les délais accordés et de
suivre l’avancement du projet.
Pour cela, les différentes tâches qui constituent notre projet sont représentées dans le
Tableau 1.
Tableau 1 Liste de tâches

TÂCHES
Accueil installation
Etude préliminaire
Interviews et capture des besoins
Validation des besoins
Capture des besoins techniques
Rédaction du rapport
Conception générique
Conception préliminaire
Conception détaillée
Test unitaire
Test d’intégration
12
Test général
Rédaction du manuelle utilisation
Le planning prévisionnel est représenté par la Figure 2.
Figure 02 : Diagramme prévisionnel
I.5 Conclusion :
Le présent chapitre nous a permis de faire un tour d’horizon sur la structure d’accueil,
de présenter le projet et notamment ses attentes, ses objectifs ainsi que le rôle de chaque
acteur du projet.
Ce qui nous permettra dans le chapitre suivant de présenter le processus de
développement utilisé, la démarche et les moyens mis en place.
13
CHAPITRE II DEMARCHES ET MOYENS

DE RESOLUTION
II.1 Introduction
Dans ce chapitre, nous ferons part de la démarche et des moyens utilisés afin de résoudre
le problème qui nous a été posé.
Pour cela, nous ferons cas, des exigences fonctionnelles et techniques, de la méthode de
résolution, du langage de modélisation, des outils et des modèles issus de cette
démarche.
II.2 Exigences fonctionnelles et techniques

Les fonctionnalités attendues du futur système d’après les besoins exprimés par les
utilisateurs :
➢ importer ficher ;
➢ ajout, modification et suppression des boursiers ;
➢ ajout, modification et suppression des bulletins ;
➢ ajout, modification et suppression des liens ;
➢ ajout, modification et suppression des tuteurs ;
➢ produire des statistiques ;
➢ gestion de comptes ;
➢ gérer Système :
o ajout, modification et suppression des utilisateurs ;
o ajout, modification et suppression des droits ;
o ajout, modification et suppression des motifs de retraits ;
➢ mettre à jour l’année académique.
II.3 Méthode de résolution du problème

L’analyse et la conception d’un système informatique nécessitent l’utilisation d’un
langage de modélisation et d’une méthode de conception. Ces outils permettant la
description du système logiciel, offrent une meilleure compréhension de celui-ci par les
14
principaux utilisateurs du système. Ils permettent par conséquent une participation

active des utilisateurs dans la collecte d’informations.
Dans le cadre de notre projet, nous avons décidé d’utiliser l'approche objet (technique
performante et fiable) qui permet l’évolution du logiciel et une réutilisation des objets.
Pour ce faire, nous avons choisi le langage UML comme langage de modélisation, et le
processus 2TUP comme méthode de développement
II.3.1 Langage de modélisation
Comme Langage de Modélisation, nous avons utilisé le langage de modélisation unifié
appelé en anglais Unified Modeling Langage (UML). UML est un langage de
modélisation orienté objet. Il est né de la fusion de trois méthodes de modélisation Objet
à savoir :
➢ la méthode BOOCH'93 de Booch ;
➢ la méthode OMT de Rumbaugh ;
➢ la méthode OOSE de Jacobson (Object Oriented Software Engineering).
UML a été Adopté comme standard par l’Object Management Group (OMG). UML
permet de représenter graphiquement les besoins des utilisateurs sous forme de
diagrammes. Grâce à ces diagrammes, UML fournit un cadre de représentation et de
compréhension commun d’un système informatique.
Les diagrammes UML 2.3 sont des éléments graphiques qui représentent le problème et
sa solution selon différents points de vue, ils sont au nombre de treize (13) et se
répartissent en trois grands groupes :
➢ diagrammes structurels ou diagrammes statiques :
• constitués par les diagrammes de classes, d’objets, de composants, de
déploiements, de paquetages et de structures composites.
➢ diagrammes comportementaux ou diagrammes dynamiques :
• constitués par les diagrammes d’activités, d’états-transitions, et des cas
d’utilisation
➢ diagrammes d’interaction :
• constitué par les diagrammes de communication, de séquence, global
d’interaction et de temps.
Pour notre projet nous serons amenés à utiliser certains de ces diagrammes comme :
❖ Le diagramme de cas d’utilisation (DCU)
Le diagramme de cas d’utilisation décrit les fonctionnalités du système et la manière

dont l’utilisateur doit utiliser ce système. Le diagramme de cas d’utilisation se base sur
le cahier de charge pour être écris.
La construction du DCU utilise les éléments suivants :
15
Un acteur : un acteur est une entité autonome et extérieure au système, et qui interagit
directement avec lui. Il peut être un humain, un logiciel, un matériel.
Un cas d’utilisation : Un cas d’utilisation est représenté par une ellipse contenant son
nom, ce nom correspondant à l’utilisation représentée, il est lié à un acteur par une
association.
Une Relation : Elle est représentée par une ligne qui permet de relier les acteurs aux cas
d’utilisation et de montrer quel acteur participe à quel cas d’utilisation.
Formalisme et exemple :
Figure 03 : Formalisme éléments de cas d’utilisation
UML possède trois (3) types de relations entre les cas utilisation, Une relation d’inclusion
(include), une relation d’extension (extend) et une relation de généralisation. Ces
relations sont toutes représentées graphiquement de manière unique.
➢ L’inclusion :
Un cas A inclut un cas B, si le comportement de A inclut forcement au préalable et en
intégralité le comportement attribué au cas B. Elle est matérialisée graphiquement par
le stéréotype <<include >>
➢ L’extension :
Un cas A étend un cas B, Si le comportement de A peut être étendu par le comportement
de B c’est-à-dire que A ajoute un comportement à B. Une extension est souvent soumise
à condition. Elle est matérialisée par le stéréotype <<extend>>
16
➢ La généralisation :
Un cas A est une généralisation d’un cas B si B est un cas spécial de A.
Figure 04 : Formalisme d’un cas d’utilisation
❖ Le diagramme de classe
Le diagramme de classe a pour but de décrire les concepts du monde réel et aussi les
relations qu’ils entretiennent entre eux, il est considéré comme l’un des plus important
de la modélisation orientée objet. Il montre la structure interne des objets, il permet en
plus de fournir une représentation abstraite des objets du système qui vont interagir
pour réaliser les cas d'utilisation. Il se compose de plusieurs éléments en voici certains :
➢ Objet :
En informatique, un objet est considéré comme une simulation d’un élément du monde
réel, il est autonome et contient des informations et a un comportement bien défini en
rapport avec l’élément émulé. Un objet est défini par une identité un état et un
comportement.
➢ Les classes :
Ce sont les descriptions d’un ensemble d’objets ayant une sémantique, des attributs, des
méthodes et des relations en commun. Un objet est une instance d’une classe.
➢ Les attributs :
17
Ce sont des données déclarées au niveau d’une classe, éventuellement typées, à laquelle
chacun des objets de cette classe donne une valeur. Un attribut peut posséder une
multiplicité de valeur et une valeur initiale.
➢ Les opérations :
Elles sont les éléments de comportement des objets, défini de manière globale dans leur
classe. Une opération peut déclarer des paramètres (eux-mêmes typés) ainsi qu’un type
de retour.
Figure 05 : Formalisme d’une classe
Relation entre classe :
• Association
Une association représente la relation entre des classes (au moins deux (2)). Elle a un
nom et un sens de lecture.
• Cardinalité
La Cardinalité est le nombre d’instance d’un objet (min, max), qui peut intervenir dans
une relation avec un autre objet dans le cadre d’une association. Elle est utilisée dans la
lecture des associations
• Agrégation
L’agrégation est une sorte d’association entre plusieurs classes. Elle exprime le fait
qu’une classe soit composée d’une ou plusieurs autres classes.
• Composition
La composition est une relation d’agrégation dans laquelle il existe une contrainte de
durée de vie entre la classe « composant » et la ou les classes « composé ».
• Héritage
18
Une relation héritage est une relation indiquant héritage entre une ou plusieurs classes.
Cet héritage donne à la sous classe les propriétés (attributs et opérations) de la super
classe. L’héritage utilise deux (2) principes de généralisation et spécialisation.
Figure 06 : Formalisme d’un diagramme de classe
❖ Diagramme de séquence
Le diagramme de séquence est un élément du diagramme interactions, qui sert à décrire

les interactions entre les acteurs et le système, c’est à dire à décrire les scénarios des cas
d'utilisation. Les acteurs interagissent avec le système au moyen d’IHM (Interface
Homme-Machine).
Le diagramme de séquence met l’accent sur la représentation temporelle d’une
interaction en montrant la séquence dans le temps des messages entre les participants à
une interaction.
Il permet de déterminer à la foi les diverses entités, appelées participants ou acteurs, les
échanges (messages) entre les entités dans le cadre de cette fonctionnalité, le
déroulement dans le temps de ces échanges.
Un diagramme de séquence a deux dimensions
-dimension verticale : Qui représente le temps et l’ordre d’agencement des messages. Le
temps s'écoule de haut en bas
-dimension horizontale : les participants (objets, acteurs)
L’ordre de disposition peut être aléatoire.
19
• Participant (objets, acteurs) :

Le participant dans le diagramme de séquence est considéré comme un émetteur ou un
receveur d’un message. Un participant peut-être un objet du système, un acteur ou le
système lui-même. La représentation graphique pour un objet est similaire à une classe
(un rectangle) avec le nom de l’objet (facultatif) précédé de deux points (:).
Figure 07 : Formalisme d’un objet et d’un acteur
• Ligne de vie des participants

Dans le diagramme de séquence la ligne de vie représente la durée pendant laquelle un
objet existe. La notation utilisée pour les modéliser est une ligne pointillée verticale
partant du participant.
Figure 08 : Formalisme d’une Ligne de vie
• Activation
Les activations sont modélisées par des boîtes rectangulaires sur la ligne de vie. Elles
indiquent quand l’objet effectue une action.
Figure 09 : Formalisme d’une période activation
20
• Message
Dans le diagramme de séquence on communique en échangeant des messages.
Plusieurs types de messages peuvent être distingués :
• message synchrone : après l’envoi d’un message l’émetteur reste en
attente de la réponse à son message, avant de poursuivre ses actions.
Elle est symbolisée par une flèche avec une extrémité pleine. Le
message retour peut ne pas être représenté car il est souvent inclus dans
la fin d’exécution de l’opération de l’objet destinataire du message.
• message asynchrone : dans ce cas, l’émetteur n’attend pas la réponse à
son message, il poursuit l’exécution de ses opérations. C’est une flèche
avec une extrémité non pleine qui symbolise ce type de message.
• message de retour : Si le traitement d’un message doit retourner des
valeurs à la fin, cela se fait par un message de retour. Non impératif
pour un message synchrone,
• message réflexif ou interne : Un objet s’envoie un message à lui-même,
• message de création : Message entraînant la création d'objets ;
• message de destruction ; Message entraînant la destruction d'objets.
• Fragment d’interaction combiné

Dans le diagramme de séquence on a des opérateurs d’interaction qui permettent le
traitement en bloc, Les principales modalités sont les boucles, les branchements
conditionnels, les alternatives, les envois simultanés, etc.
On peut citer parmi eux :
• OPT l’opérateur option, on utilise cet opérateur pour marquer une condition,
cette condition est notée entre crochets Le fragment s’exécute si la condition
est vraie et ne s’exécute pas dans le cas échéant.
• ALT l’opérateur alternative, on utilise cet operateur pour marquer au moins
deux conditions, ces conditions sont notées entre crochets et sont séparées
entre elles par des pointilles. Le fragment s’exécute si la condition [1 à N] est
respectée et exécute la partie [ELSE]si toutes les précédentes conditions
données ne sont pas respectées.
• LOOP l’opérateur boucle, on utilise cet opérateur pour répéter un bloc
interaction tant que la condition est vrai, cette condition est notée entre
crochets loop [min, max, condition], Le contenu du fragment est exécuté
min fois, puis continue à s’exécuter tant que la condition est vraie et que le
nombre d’exécution de la boucle ne dépasse pas max fois.
21
• REF l’opérateur référence, on utilise cet opérateur pour permettre d’appeler

une séquence d’interactions nommée décrite ailleurs.
Figure 10 : Formalisme d’un diagramme de séquence
22
❖ Diagramme de déploiement
Le diagramme de déploiement est utilisé pour représenter l’architecture qui doit être
mise en place pour recevoir le système en développement. Cette architecture comprend
des nœuds correspondants aux supports physiques (serveurs, routeurs…) ainsi que la
répartition des artefacts (Composant) logiciels (bibliothèques, exécutables…) sur ces
nœuds. C’est un véritable réseau constitué de nœuds et de connexions entre ces nœuds
qui modélisent cette architecture.
Composante du diagramme de déploiement :
• Nœud
Un nœud représente une ressource matérielle de traitement sur laquelle des artefacts
seront mis en œuvre pour l’exploitation du système. Les nœuds peuvent être
interconnectés pour former un réseau d’éléments physiques.
Formalisme et exemple
Représenté par un cube ou parallélépipède
Figure 11 : Formalisme d’un Nœud
• Artefact (Composant)
Un artefact est la spécification d’un élément physique qui est utilisé ou produit par le
processus de développement du logiciel ou par le déploiement du système. C’est donc
un élément concret comme par exemple : un fichier, un exécutable ou une table d’une
base de données. Un artefact peut être relié à d’autres artefacts par notamment des liens
de dépendance.
Un artefact se représente par un rectangle caractérisé par le mot-clé « artefact » et/ou
une icône particulière dans le coin droit du rectangle.
23
Figure 12 : Formalisme d’un Artefact
• Liens entre un artefact et les autres éléments du diagramme

• représentation inclusive – Dans cette représentation, un artefact est représenté
à l’intérieur du nœud auquel il se situe physiquement.
• représentation avec un lien de dépendance typé « deploy ».
Dans ce cas l’artefact est représenté à l’extérieur du nœud auquel il appartient avec un
lien de dépendance entre l’artefact et le nœud typé avec le mot-clé « deploy ».
Figure 13 : Formalisme d’un diagramme de déploiement

24
II.3.2 Langage de modélisation Le processus Two Track Unified

Process (2TUP)
Le Two Track Unified Process (2TUP), est un processus de développement logiciel qui
met en œuvre la méthode du processus Unifié. Un processus Unifié est un processus de
développement logiciel construit sur UML. On dit que PU vient compléter la systémique
des modèles UML. Il est itératif et incrémental, conduit par les cas d'utilisation donc par
les exigences des utilisateurs.
L'objectif de notre projet est de développer une application de gestion. Nous nous
sommes orientés vers l’utilisation de la méthodologie 2TUP, le processus 2TUP
rassemble le travail effectué sur la branche fonctionnelle d’une part et technique d’autre
part, ainsi que sa bonne gestion des risques.
Le 2TUP propose un cycle de développement en Y,

• 1er branche aspects fonctionnels ;
• 2eme branche aspects techniques ;
• 3eme branche conception et développement.
Il faut noter que le processus 2TUP commence d’abord par une étude préliminaire qui
consiste essentiellement à identifier les acteurs qui vont interagir avec le système à
construire, les messages d’échangent entre les acteurs et le système, à produire le cahier
des charges et à modéliser le contexte. Le processus s'articule ensuite autour de 3 phases
essentielles :
➢ Une branche fonctionnelle : Cette phase a pour objectif de définir la frontière

fonctionnelle entre le système et son environnement, les activités attendues des
différents utilisateurs par rapport au système et obtenir une idée de ce que va
réaliser le système en termes de métier.
➢ Une branche technique : Pendent cette étape on répertorie toutes les contraintes
sur les choix technologiques pour la conception du système, il est aussi défini
dans cette branche les composants nécessaires à la construction de l’architecture
technique.
➢ Une phase de conception : Cette étape permet de produire le modèle de

conception du système, de réaliser chaque composant, de tester les unités de code
au fur et à mesure de leur réalisation et de valider les fonctionnalités du système
développé.
25
Figure 14 : Schéma de processus de développement en Y
II.4) Conclusion :
Dans ce chapitre, nous avons pu définir une démarche d'analyse et le langage de

modélisation qui va nous permettre de réaliser notre projet. Ainsi le chapitre suivant
portera sur les expressions de besoins.
26
PARTIE II :
MODELISATION
27
CHAPITRE I : EXPRESSION DES BESOINS

I.1) Introduction
La solution qui sera mise en place nécessite une connaissance préalable de l’organisation
du système actuellement en place au sein de la CARFO. Pour cela, il sera question
d’étudier sont fonctionnement, la gestion des rapports entre les différents acteurs,
ensuite de délimiter le domaine et procéder à son analyse grâce à l’identification de ses
concepts clés, le développement du diagramme de classes et enfin la construction du
diagramme de déploiement. L’expression des besoins doit permettre aux utilisateurs qui
ne sont pas toujours des informaticiens, de bien exprimer leurs besoins et de bien
comprendre les fonctionnalités que le système va fournir. Les besoins sont divisés en
deux parties : la partie fonctionnelle et la partie technique.
I.2) Recueil des besoins fonctionnels
Les fonctionnalités du système à mettre en place sont organisées en modules comme

suit :
➢ La gestion des utilisateurs :

La gestion des utilisateurs est un module dédie à l’administrateur du système, il
servira à créer des comptes pour chaque utilisateur, ces utilisateurs posséderont
des droits qui fixerons les limites de chaque catégorie d’utilisateurs.
L’administrateur pourra naturellement gérer tous les comptes c’est-à-dire changer
les mots de passe, modifier un profil, fermer un compte, etc.
➢ La gestion des boursiers :

Ce module permettra à un utilisateur de créer, modifier, supprimer, afficher les
détails sur un boursier
➢ La gestion des tuteurs :

Ce module servira à enregistrer créer, modifier, supprimer, afficher les détails sur
un tuteur, il permettra surtout d’avoir tous les détails sur un tuteur déjà enregistré.
28
➢ La gestion des liens

L’utilisateur pourra avec ce module créer, modifier, supprimer, afficher les détails
sur les liens qui existe ou à exister entre les différents tuteurs et boursiers.
➢ La gestion des bulletins

Ce module permettra à un utilisateur de créer, modifier, supprimer, afficher les
détails sur les bulletins des boursiers.
➢ La gestion des statistiques

Ce module sera utilisé pour qu’un utilisateur puise afficher les détails sur les
statistiques diverses. Il permettra surtout de faire ressortir les différentes
statistiques en se basant sur les moyennes des bulletins fourni chaque fin d’année.
➢ La gestion des alertes

Grâce à une alerte, l’utilisateur sera informé après le passage à la nouvelle année
académique des boursiers actifs qui non pas apporter les bulletins.
I.3) Recueil des besoins techniques

Les besoins techniques regroupent les besoins indispensables au bon fonctionnement
de l’application.
Exigence de performance :
L’application devra permettre la connexion simultanée de plusieurs utilisateurs et la
rapidité des différentes transactions sera assurée sur le réseau.
Exigence de sécurité :
Le respect de la confidentialité des données de l’application.
Exigence évolutive :
Le code doit être clair pour permettre des évolutions ou améliorations ultérieures
Exigence ergonomique :
L’application présentera une interface sobre et efficace qui facilitera au maximum son
utilisation à l’aide d’une présentation claire et intuitive.
29
I.4) Conclusion
Dans ce chapitre, nous avons présenté les exigences fonctionnelles du point de vue de
l’utilisateur et les besoins techniques.
.
30
CHAPITRE II : MODELISATION
DETAILLEE
II.1) Introduction
Pour développer une application, il ne faut pas se précipiter dans l'écriture du code : il
faut d'abord organiser ses idées, les documenter, puis organiser la réalisation en
définissant les modules et étapes de la réalisation. C'est cette démarche antérieure à
l'écriture que l'on appelle "modélisation" ; son produit est un "modèle".
II.2) Diagramme de cas d’utilisation
CU01 : Importer ficher

CU02 : Gérer boursiers
CU03 : Gérer bulletins
CU04 : Gérer liens
CU05 : Gérer tuteurs
CU06 : Produire des statistiques
CU07 : Gérer Système
CU08 : S'authentifier
CU09 : Se déconnecter
CU10 : Mettre à jour l’année académique
Tableau 2 : Liste des cas d'utilisation

Acteurs Cas d’utilisation
Importer ficher
Gérer boursiers
Agent Gérer bulletins
Gérer liens
Gérer tuteurs
Produire des statistiques
S'authentifier
Se déconnecter
31
Administrateur Gérer Système

Mettre à jour l’année académique
II.1.1) Représentation du diagramme de cas d’utilisation
Figure 15 : Diagramme de cas d’utilisation
Pour une meilleure compréhension nous allons décomposer les cas d’utilisation : Gérer
boursier, Gérer bulletin, Gérer lien, Gérer tuteur et Gérer Système qui renferme d’autres
cas d’utilisation.
32
Figure 16 : raffinement de cas utilisation Gérer boursier
33
Figure 17 : raffinement de cas utilisation Gérer bulletin
34
Figure 18 : raffinement de cas utilisation Gérer système
35
Figure 19 : raffinement de cas utilisation Gérer tuteur
36
Figure 20 : raffinement de cas utilisation Gérer lien
II.3) Description textuelle des quelques cas d’utilisation
Le diagramme de cas d’utilisation décrit les grandes fonctions du système du point de

vue des acteurs. Mais il n’expose pas de façon détaillée le dialogue entre les acteurs et
les cas d’utilisation, d’où la nécessité de décrire ce dialogue. Dans cette section, nous
décrirons les cas d’utilisation « S’authentifier », « Ajouter boursiers », « Produire des
statistiques », « créer des droits ».
37
Tableau 1: Description textuelle du CU « S’authentifier »

CU : « S’authentifier »
Objectif : Ce cas d’utilisation permet Acteurs : Tout utilisateur du système
à chaque utilisateur de se connecter Version : 1.0
au système en utilisant son Date :02/08/2018
identifiant et son mot de passe
Acteur
Préconditions : Le système est accessible et l’utilisateur n’est pas encore
connecté.
Scénario nominal :
Début
L’utilisateur lance l’application
Le système affiche la page d’authentification
L’utilisateur saisi ses identifiants puis valide
Le système vérifie les données fournies
Le système créé une session de connexion
L’utilisateur a accès à l’espace de travail.
Fin du cas d’utilisation
Scénario alternatif : SA1 données saisies incorrectes
Les informations sont incomplètes ou erronées.
Le système envoie un message d’erreur.
L’utilisation n’arrive pas à se connecter au bout de trois essais,
L’application se ferme.
Tableau 4 : Description textuelle du CU « Ajouter boursiers »

CU : « Ajouter boursiers »
Objectif : Ce cas d’utilisation permet Acteurs : agent qualifier et
à un utilisateur de procéder à un administrateur
ajout de boursier Version : 1.0
Date : 02/08/2018
Préconditions : L’utilisateur est connecté.

Scénario nominal :
Début
38
L’utilisateur accède au menu des bourses.

L’utilisateur demande le formulaire d’ajout de boursier
L’utilisateur remplis le formulaire puis valide
Le système notifie la réussite d’ajout
Le système notifie que les données fournies sont incorrectes,
l’enchainement continue à partir du point 4 du scénario nominal en
indiquant les données incorrectes
Scénario d’Exception : SE le boursier existe déjà
Le système notifie que le boursier existe déjà dans la base.
Post condition : Le boursier est ajouté
Tableau 5 : Description textuelle du CU « Produire des statistiques »

CU : Produire des statistiques
Objectif : Ce cas d’utilisation permet de Acteurs : tous les utilisateurs.
Produire des statistiques. Version : 1.1
Date de création : 02/08/2018
Précondition : L’utilisateur est connecté.
Scénario nominal :
Début
L’utilisateur accède à la fenêtre des statistiques.
Il choisit option désirée.
Le système calcul et fournies les résultats.
Tableau 6 : Description textuelle du CU « Créer des droits s »

CU : « Créer des droits »
Objectif : Ce cas d’utilisation permet Acteurs : administrateur
à un administrateur de procéder à Version : 1.0
une création de catégorie de droit Date : 02/08/2018
d’accès
39
Préconditions : un administrateur est connecté.

Scénario nominal :
Début
L’utilisateur accède à la fenêtre d’administrateur.
L’utilisateur demande le formulaire d’ajout de catégorie
L’utilisateur remplis le formulaire puis valide
Le système notifie la réussite d’ajout
Le système notifie que les données fournies sont incorrectes,
l’enchainement continue à partir du point 4 du scénario nominal en
indiquant les données incorrectes
Scénario d’Exception : SE le droit d’accès existe déjà
Le système notifie que le droit d’accès existe déjà dans la base.
Post condition : un droit accès est ajouté
II.4) Diagramme de Séquence
Le diagramme des séquences d’un cas d’utilisation est la représentation des interactions
entre les acteurs et le système dans le respect de l’ordre chronologique de ces
interactions.
❖ Diagramme de séquence « S’authentifié »
40
Figure 21 : Diagramme de séquence « S’authentifié »
❖ Diagramme de séquence « Ajouter boursiers »
41
Figure 22 : Diagramme de séquence « Ajouter boursiers »
42
❖ *Diagramme de séquence « Produire des statistiques »
Figure 23 : Diagramme de séquence « Produire des statistiques »
43
❖ *Diagramme de séquence « Créer des droits »
Figure 24 : Diagramme de séquence « Créer des droits »
44
II.5) Diagramme de classe
❖ Règles de gestion
Dans le souci d’éviter la redondance des données, et de mieux assurer la relation entre
les classes nous avons établi des règles de gestion parmi lesquelles on a :
:
Tableau 7 : Règles de gestion

Numéro Règle de gestion
1 Un utilisateur à un (1) ou plusieurs droits
2 Un boursier à un (1) tuteur
3 Un boursier à zéro (0) ou plusieurs bulletins
4 Un boursier à zéro (0) ou un (1) motif de retrait
5 Un boursier est relié à zéro (0) ou un (1) lien
6 Un utilisateur peut gérer zéro (0) ou plusieurs boursier
7 Un droit est attribué à zéro (0) ou plusieurs agents
8 Un tuteur est relié à zéro (0) ou plusieurs liens
9 Un boursier est relié à un (1) ou plusieurs titulaires
❖ Le dictionnaire de données
Le dictionnaire de données recense l′ensemble des données élémentaires se rapportant
strictement au domaine étudié. Il constitue la liste des classes du système, et nous permet
également de bien le comprendre et d’avoir une idée sur ses classes.
Dans cette partie, nous décrirons le dictionnaire de donnée.
45
Tableau 8 : Le dictionnaire de données

Classe Nom Type Description
Boursier Alphanumérique Identifiant d’un
IdBoursier
Boursier
AnneIntegration Date Date
d’intégration du
boursier
AnneSortie Date Date de fin de la
bourse
Etat Numérique Etat actuel de la
bourse activé ou
désactivé
NbRedoublementC Numérique Nombre de foi
qu’un élevé
redouble par
cycle
bulletin IdBuletin Numérique Identifiant d’un
bulletin
AnneScolaire Date Année scolaire
du bulletin
Moyenne Double Moyenne de
l’élève
Appréciation Alphanumérique Mention obtenu
Etablisement Alphanumérique Nom de
l’établissement
Classe Alphanumérique Classe faite par le
boursier
Cycle Alphanumérique Cycle du boursier
Droit IdDroit Numérique Identifiant d’un
Droit
Alphanumérique Désignation d’un
NomDroit droit
GestionBoursier Numérique Gestion des
boursiers
GestionTuteur Numérique Gestion des
tuteurs
GestionLien Numérique Gestion des lien
Admin Numérique Fonction
d’administrateur
46
Esttuteur IdEsttuteur Numérique Identifiant d’un

Droit
NPension Alphanumérique Numéro de
pension
DateDebut Date Date début du
lien
DateFin Date Date de fin du
lien
Motif-retrait IdMotif Numérique Identifiant d’un
motif de retrait
NomMotif Alphanumérique Nom d’un motif
de retrait
idPersonne Numérique Identifiant d’une
personne
Nom Alphanumérique Nom d’une
personne
Personne Prenom Alphanumérique Prénom d’une
personne
DateNaisance Date Date de
naissance d’une
personne
Sexe Caractère Sexe d’une
personne
Adresse Alphanumérique Adresse d’une
personne
Telephone Alphanumérique Numéro de
téléphone d’une
personne
Titulaire IdTitulaire Numérique Identifiant d’un
assuré
MatriculeTitulaire Alphanumérique Matricule d’un
assuré
Tuteur IdTuteur Numérique Identifiant d’un
tuteur
Utilisateur IdUtilisateur Alphanumérique Identifiant d’un
utilisateur
Identifiant Alphanumérique pseudonyme
d’un utilisateur
MatriculeUtilisateur Numérique Matricule d’un
utilisateur
47
MotDePasse Alphanumérique Mot de passe de

connexion d’un
utilisateur
Position Numérique Etat actuel de
l’utilisateur
connecté ou
déconnecté
Figure 25 : Diagramme de classe
48
II.6) Diagramme d’activité
❖ Diagramme d’activité « S’authentifier »
Figure 26 : Diagramme d’activité « S’authentifié »
Ouverture
49
❖ Diagramme d’activité « Ajouter boursiers »
Figure 27 : Diagramme d’activité « Ajouter boursiers »
50
❖ Diagramme d’activité « Produire des statistiques »
Figure 28 : Diagramme d’activité « Produire des statistiques »
51
❖ *Diagramme d’activité « Créer des droits »
Figure 29 : Diagramme d’activité « Créer des droits »
52
II.7) Diagramme de déploiement
Figure 30 : Diagramme de déploiement
II.8) Conclusion
Dans ce chapitre nous avons représenté et décrit le fonctionnement des différentes
fonctionnalités du futur système à travers des diagrammes de modélisation. Pour mettre
ces fonctionnalités en place des spécifications techniques sont nécessaires.
53
PARTIE III :
DEVELOPPE-
MENT DE
L’APPLICATION
54
CHAPITRE I : SPECIFICATIONS
TECHNIQUES
I.1) Introduction
La phase de réalisation est la partie de l’implémentation du futur système. Le système

contient tous les cas d’utilisation que le groupe de projet et le groupe de pilotage ont
décidé de mettre en place. Dans ce chapitre, nous allons décrire les différents outils
utilisés pendant la durée du projet ainsi que quelques captures d’écrans.
I.2) L’architecture technique
L’architecture d’un logiciel est la basse de toute application, elle décrit sa structure
globale. Elle est ce sur quoi les développeurs s’appui pour réaliser l’application.
L’architecture de notre futur système est une architecture à trois (03) couches :
➢ La couche présentation : Appelé couche de IHM, elle va permettre les

interactions entre le système et les utilisateurs à travers les interfaces (fenêtres)
simples et faciles, mais aussi de gérer le clavier et d’autres périphériques.
➢ La couche traitements : Aussi appelé couche de métier, au niveau de cette couche

on fait de sorte que l’application respecte et suit les différentes règles de gestion
et de logique applicative qui on était retenues.
➢ La couche donnée : Cette couche s’assure de la pérennité des données et de la

manière dont elles sont conservées.
Pour notre projet, nous avons adopté l’architecture à 3 niveaux ou encore 3-tiers qui est
basée sur l’environnement client-serveur.
Un environnement client/serveur, cela signifie que des machines clientes (des

machines faisant partie du réseau) contactent un serveur, une machine généralement très
55
puissante en termes de capacités d'entrée-sortie, qui leur fournit des services. Ces
services sont des programmes fournissant des données.
Le modèle client/serveur est particulièrement recommandé pour des réseaux nécessitant
un grand niveau de fiabilité, ses principaux atouts sont :
➢ Des ressources centralisées : étant donné que le serveur est au centre du réseau,
il peut gérer des ressources communes à tous les utilisateurs, comme par exemple
une base de données centralisée, afin d'éviter les problèmes de redondance et de
contradiction
➢ Une meilleure sécurité : car le nombre de points d'entrée permettant l'accès aux
données est moins important
➢ Une administration au niveau serveur : les clients ayant peu d'importance dans ce
modèle, ils ont moins besoin d'être administrés
➢ Un réseau évolutif : grâce à cette architecture il est possible de supprimer ou
rajouter des clients sans perturber le fonctionnement du réseau et sans
modification majeure
L'architecture client/serveur a tout de même quelques lacunes parmi lesquelles :
➢ Un coût élevé dû à la technicité du serveur. (Étant donné que la CARFO possède

déjà des serveurs se problème n’en est plus un)
➢ Un maillon faible : le serveur est le seul maillon faible du réseau client/serveur,
étant donné que tout le réseau est architecturé autour de lui ! Heureusement, le
serveur a une grande tolérance aux pannes.
I.3) Le SGBD
Un Système de Gestion de Base de Données (SGBD) est un logiciel conçu dans le but
de stocker, partager des informations dans une base de données tout en garantissant la
pérennité, la qualité et la confidentialité de ces informations. Il comporte des
mécanismes pour assurer la cohérence des informations, éviter des pertes
d’informations due à des pannes, assurer la confidentialité et permettre son utilisation
par d’autres logiciels.
Tableau 9 : Liste des SGBD les plus demandés

NUMERO NOM
1 MySQL
2 MongoDB
56
3 PostgreSQL
4 Oracle
5 Microsoft SQL Server
6 Microsoft Access
7 MariaBD
8 DB2
9 Sybase
10 Firebrid
MySQL, Microsoft SQL Server, PostgreSQL et Oracle sont des systèmes presque
équivalents bien que certain (MySQL et PostgreSQL) soit gratuit et les autres très
onéreux. Rien ne justifie l’emploi d’Oracle et Microsoft SQL Server plutôt que
PostgreSQL, MySQL sauf pour certaines catégories de très grandes bases de données
ou ils seront plus utiles.
Notre choix se portera sur MySQL pour ses Service Web qui ne sont pas disponible sur
PostgreSQL, la disponibilité de service web donnera à notre application encore plus de
possibilités évolutives.
I.4) Environnement Développement

I.4.1) Environnement Développement Intégré
Un environnement de développement est un ensemble d'outils qui permet d'augmenter

la productivité des programmeurs qui développent des logiciels il est composé d’un
éditeur de texte, un compilateur, des outils automatiques de fabrication, et souvent un
débogueur. Pour le développement de notre application nous avons les IDE comme
Eclipse, NetBeans etc.
❖ NetBeans
NetBeans permet le développement d'applications Java, PHP, C, C++ et Ruby.
NetBeans, créé à l'initiative de Sun Microsystems (Noyau de Forte4J/SunOne), il
présente toutes les caractéristiques indispensables à un EDI de qualité :
➢ permet de développer en Java, Ruby, C/C++ ou même PHP.
➢ licence Open Source, il est gratuit.
57
➢ permet de développer et déployer rapidement et gratuitement des applications

graphiques Swing, des Applets, des JSP/Servlets, des architectures J2EE, dans
un environnement fortement personnalisable.
➢ repose sur un noyau robuste.
➢ possède un système de plugins performant, qui permet vraiment d'avoir un
IDE sur mesure.
➢ il vous permet également de déployer vos applications Web.
❖ Eclipse
Eclipse permet le développement d'applications Java principalement, mais également
d'autres langages grâce à l'utilisation de plugins. Eclipse est une plateforme de
développement écrite en Java, fruit du travail d'un consortium de grandes entreprises
(IBM, Borland, Rational Rose, HP...).
-performant.
-open Source
-intègre pour cela la prise en charge des outils comme Ant, SVN, JUnit...
-fonctionnalités principales : création de projet, de Template, refactoring, debuggage ...
-faciles à prendre en main.
-permet l'ajout de très nombreux plugins.
-supporte aussi d'autres langages comme PHP (via PDT) et C/C++ (via CDT), etc.
Nous avons opté pour NetBeans (version 8.0.2) car il intègre les composants
interfaces graphique (Swing) dès l’installation contrairement à Eclipse dont on a besoin
d’un plug-in.
I.4.2) Présentation des outils de modélisation
❖ PowerAMC 15
PowerDesigner est un logiciel de conception créé par la société SAP, qui permet de
modéliser les traitements informatiques et leurs bases de données associées. Il a été créé
par SDP sous le nom AMC*Designor, racheté par Powersoft qui lui-même a été racheté
par Sybase en 1995, il permet :
➢ La modélisation intégrée via l’utilisation de technologies et de notations
standards :
• données (E/R, Merise)
• métiers (BPMN, BPEL, ebXML)
58
• application (UML)
• génération automatique de code via des Template personnalisables :
• SQL (avec plus de 50 SGBD)
• Java
• ( . NET )
➢ Les fonctionnalités de reverse-engineering pour documenter et mettre à
jour des systèmes existants ;
➢ Une solution de référentiel d’entreprise avec des fonctionnalités de sécurité
et de gestion des versions très complètes pour permettre un
développement multi-utilisateur ;
➢ Des fonctionnalités de génération et de gestion des rapports automatisés
et personnalisables ;
➢ Un environnement extensible permettant d’ajouter des règles, des
commandes, des concepts et des attributs aux méthodologies de
modélisation et de codage.
❖ *GanttProject
GanttProject permet la planification d'un projet à travers la réalisation d'un diagramme
de Gantt. C'est une décomposition hiérarchique axée sur les tâches du travail que
l'équipe de projet doit exécuter pour atteindre les objectifs du projet et produire les
livrables voulus.
I.5) Matérielles
Pour la mise en place de notre application nous utilisons :
➢ un ordinateur de marque SAGER np8278s pc
➢ un disque dure de 128 Go ssd
➢ un disque dure de 2 to
➢ une mémoire physique (RAM) de 16 Go
➢ une carte graphique intègre Intel graphique 4600 2 Go
➢ une carte graphique dédier Nvidia gt970m 6 Go
➢ un écran de 17.3 pouces
59
I.6) Conclusion
Dans ce chapitre il a été question de présenter les outils de développement, de faire un
choix sur l’architecture et également sur le SGBD grâce à un tableau comparatif. Pour
le bon fonctionnement d’un système, la mise en place d’un système de sécurité est
obligatoire.
60
CHAPITRE II : SECURITE
II.1) Introduction
De nos jour une bonne politique de sécurité est une obligation tant pour protéger les
humains et les biens, sinon que serait une maison sans porte n’y fenêtre ; Une politique
de sécurité dans le domaine informatique consiste à empêcher les risques de
disfonctionnement, l’incohérence de données, les violations d’accès dans le système. Ce
qui implique ainsi de prendre les dispositions nécessaires afin de réduire au maximum
les effets néfastes liés aux pannes logicielles ou matérielles.
II.2) Sécurité logique
Pour ce qui est de la sécurité de notre application, nous avons travaillé sur un certain
nombre d’aspects. On peut énumérer entre autres :
-Gestion des mots de passe et la connexion à l’application :

Les mots de passe sont souvent la seule protection d’une station de travail. Il est donc
indispensable de mettre en œuvre une politique de gestion des mots de passe afin de
protéger aussi bien l’utilisateur final que le système d’information. Ainsi les postes de
travail de la CARFO sont tous dotées de mot de passe qui limite l’accès aux
administrateurs et aux différents agents de la CARFO. Accès à l’application protégée
par un mot de passe utilisé pour la connexion au système. L’utilisateur devrait saisir son
login, puis son mot de passe.
➢ Application d’une politique de droit d’accès aux différents niveaux de

l’application :
Il sera attribué à chaque utilisateur un certain nombre de droit qui préciseront ce
qu’il peut ou ne peut pas faire.
➢ La traçabilité :
Toutes les actions des utilisateurs seront archivées.
61
➢ L’intégrité :
Elle assure que les données demeurent telles qu’enregistrées.
➢ Protection contre les attaques :

Une attaque informatique est l’exploitation d’une faille d’un système informatique
à des fins non connues par l’exploitant du système.
➢ La disponibilité :
La disponibilité garantit l’accessibilité des données aux utilisateurs.
➢ La sauvegarde :
La sauvegarde consiste en la copie des données d’un système en vue de leur
restauration en cas de sinistre. Les enregistrements des logs du SGBD ainsi que
les sauvegardes hebdomadaires nous permettrons de restaurer les données du
système en cas de sinistre.
II.3) Sécurité physique
La sécurité physique est primordiale et doit être correctement assurée afin que toute
mesure de protection logique ne soit pas vaine. Afin de protéger les serveurs contre les
catastrophes dont ils peuvent être victimes (incendies, foudre, inondation, …), les
locaux les abritant devront être équipés de paratonnerres, d’extincteur ainsi que de
groupes électrogènes qui assurent la continuité de l’alimentation des serveurs en
électricité. Aussi l’accès aux locaux doit être soumis à certaines normes de sécurité.
En ce qui concerne la CARFO un certain nombre de paramètres sécuritaires sont déjà
en place :
➢ Un accès au bâtiment contrôlé par la gendarmerie ;
➢ Un bâtiment construit en respectant les normes de sécurités en vigueur

concernant les lieux publics ;
➢ Des caméras de surveillance sont installées ;
➢ Des extincteurs placés à tous les niveaux du bâtiment ;

62
➢ Des onduleurs et un groupe électrogène pour assurer la bonne continuité du

travail en cas de coupure du courant ;
➢ Une salle serveur au portail blindé (accès par empreinte digitale et clé) ;
➢ Détecteur de fumée en salle serveur ;
➢ Des pare-feu (Firewall) ;
➢ Un contrôleur de domaine ;
➢ Des sessions de connexion à chaque utilisateur ;
➢ Des antivirus sur les postes clients qui assurent la protection contre des virus
informatiques.
II.4) Conclusion
Dans ce chapitre, nous avons exposé les différents modules développés pour avoir une
bonne politique de sécurité, afin de garantir l’intégrité du système d’information
63
CHAPITRE III : PRESENTATION DES

PRINCIPALES IHM
III.1) Introduction
Dans ce chapitre nous présentons l’enchaînement des écrans de notre application, c’est-
à-dire les interfaces permettant à un utilisateur de communiquer avec le système.
❖IHM Authentification
Cette interface permet à un l’utilisateur disposant d’un compte valide de se connecte
afin de pouvoir utiliser les différentes fonctionnalités de l’application.
Figure 31 : Page d’authentification
64
❖IHM d’accueil
Cette interface est l’interface d’accueil qui présente le pseudonyme de l’utilisateur

connecté et les différentes fonctionnalités de l’application, qui lui sont autoriser sellons
les droits dont il dispose.
Figure 32 : Page d’accueil
65
❖IHM statistique
Cette interface est l’interface des statistiques, ici il est présenté selon l’option choisit les
statistiques générales de l’année précédente et pour l’année au choix de l’utilisateur
connecté et les différentes fonctionnalités de l’application, qui lui sont autorisées selon
les droits dont il dispose.
Figure 33 : Page statistique
66
❖IHM de gestion des boursiers
Cette interface est l’interface qui permet à un utilisateur d’ajouter, de supprimer, ou

modifier des boursiers du système.
Figure 34 : Formulaire gestion des boursiers
67
❖IHM de création de droit
Cette interface est l’interface qui permet à un administrateur d’ajouter, de supprimer, et

de modifier des droits systèmes.
Figure 35 : Formulaire de création de droit
68
❖IHM de génération d’état : liste des utilisateurs
Cette interface est l’interface qui permet à un utilisateur d’imprimer la liste des
utilisateurs du système.
Figure 36 : Génération d’état : liste des utilisateurs
69
III.2) Conclusion
Dans cette partie il a été question de présenter et expliqué quelques écrans de notre
application pour montrer comment elle doit fonctionner.
70
CHAPITRE IV : Etude sociale et économique

IV.1) Introduction
Dans ce chapitre nous expliquerons en quoi la réalisation de cette application est

bénéfique pour la CARFO et nous donnerons une estimation sur les coûts de la
réalisation.
IV.2) Etude sociale

Un logiciel de gestion a pour but d’aider en simplifiant et en sécurisant le travail des
employés qui vont l’utilise en leurs offrants des interfaces sur lesquelles ils exécuteront
plus facilement les taches qui leurs sont confiés. Notre logiciel de gestion des bourses
devra permettre de :
➢ minimiser le temps de traitement des données.
➢ sécuriser les données traitées.
➢ limiter certaines erreurs.
➢ suivre les différents boursiers et les bourses.
Ce logiciel de gestion va donc apporter un plus au déroulement des taches effectuées au
sein de la CARFO.
IV.3) Etude économique
L’estimation des coûts d’un projet informatique est une chose compliquée et mène le
plus souvent à des litiges puisqu’ils sont souvent sous ou surévaluer. On observe
différentes méthodes dont
COCOMO (Constructive Cost Mode) qui est une méthode développée en 1981 par Dr.
Barry Boehm pour estimer les coûts. Cette méthode se basse sur le nombre de personne
impliquer dans le projet le temps en mois et aussi sur le temps de développement du
logiciel tout cela afin d’éviter les erreurs budgétaires.
71
IV.4) Présentation de la méthode COCOMO

COCOMO est une méthode qui prend en compte beaucoup de paramètres en se basant
sur la complexité du logiciel à développer. En fonction de la complexité du projet on
distingue trois types :
- les projets de mode organique : ces projets sont réalisés par une équipe de taille
relativement petite, travaillant dans un environnement familier et dans un domaine
d'application connu de l'équipe.
-les projets de mode semi-détaché : ce sont des types de projets qui ne sont pas trop
complexes. Les membres de l’équipe de développement se connaissent peu, les
technologies peuvent être mal connues, mais pas d’une grande difficulté d’appréhension.
- les projets de mode embarqué : le système à développer est une partie d'un système
complexe et les modifications de spécifications destinées à contourner des problèmes
logiciels sont en général impossibles.
IV.5) Formules du modèle COCOMO
Les formules qui permettent de calculer le coût de développement du logiciel en

fonction du type de projet sont les suivantes :
Tableau 10 : Formule du modèle COCOMO

type Complexité en effort (en mois Temps de développement (en
homme) mois)
* Organique Effort= 2,4 × (KLS)1.05 TDev= 2,5 × (Effort) 0, 38
* Semi-détaché Effort= 3 × (KLS)1, 12 TDev= 2,5 × (Effort) 0, 35
* Intégré Effort= 3,6 × (KLS) 1, 2 TDev= 2,5 × (Effort) 0, 32
➢ KLS (pour Kilo Ligne Source) représente le nombre de milliers d'instructions que
contiendra l'application.
➢ Le nombre de personnes requises pour réaliser le projet dans cet intervalle de
temps est donc : N= Effort/TDev.
➢ Coût de développement : Effort * Salaire
72
IV.6) Estimation des coûts

Nous estimons à 12000 lignes le nombre moyen de code de notre programme. Le coût
du projet sera donc estimé comme suit :
Effort = 2,4(KLS)1.05 = 3*(12000/1000)1.12
Effort = 2,4(12)1.05 = 32,610056409807453734263446524475
Effort = 32,611
TDev = 2.5(Effort) 0.38
TDev = 2.5(32,611)0.38 = 9,40mois
N = 32,611/9,40= 3,5 hommes soit environ 4 hommes
Le Coût de développement de l’application :
Nous allons estimer le salaire moyen d’un informaticien à 250 000 FCFA
Coût de développement =Effort * Salaire
Coût de développement =32,611*250 000
Coût de développement =8.152.750
Le cout de formation des utilisateurs de l’application :

Nombre d’utilisateur = 5, Nombre de jour = 7, Montant/jour = 25000F CFA
Montant total = (25000*7)
Montant total = 175000 FCFA
Tableau 11 : Estimation des coûts

Désignation Quantité Coût
Ordinateur portable 01 450000
Antivirus 01 20 000
Licence MYSQL 01 Licence libre
Licence NetBeans 01 Licence libre
Coût de développement 8.152.750
Coût de formation des 05 175000
utilisateurs
Coût total 8392750
73
IV.7) Rentabilité
La rentabilité est un enjeu majeur recherché par toute entreprise. Notre application serait
plus productive pour la CARFO, que pour les boursiers. Au niveau de la Caisse
Autonome de Retraite des Fonctionnaires, le traitement des dossiers serait plus efficace
et rapide. Une fois déployé l’application va permettre de réduire les dépenses liées à
l’achat des fournitures de bureau tel que les rames de papiers, les encres pour
imprimante. Et cette somme pourrait être réinvestie dans d’autres secteurs d’activités.
Elle permettra aussi d’obtenir une meilleure sécurité et une plus grande fiabilité des
données
IV.8) Conclusion
.
Dans ce chapitre il a été question de faire une étude sociale et économique de notre
application. Nous avons pu évaluer le coût du projet ainsi que sa rentabilité.
74
Conclusion générale
Le présent rapport fait le bilan de notre stage de fin de cycle en licence informatique
dont le thème est le suivant : « ETUDE ET CONCEPTION D'UNE APPLICATION
DE GESTION DES BOURSES SCOLAIRES OCTROYEES AUX AYANTS
DROIT DES PENSIONNES DECEDES PAR LA CARFO ».
En effet, la CARFO, qui autrefois connaissait des difficultés dans la gestion des bourses,
pourra grâce à cette application améliorer considérablement le suivi, également la gestion
des bourses et des bousiers.
Nous pensons que le but de ce projet est atteint car nous avons au cours de ce stage
appris à travailler en entreprise grâce à un savoir-faire qui nous été appris, de plus nous
avons approfondi nos connaissances sur le langage de modélisation qu’est UML, les
outils de modélisation et le langage de programmation java SE.
Dans le souci de faciliter et de rendre encore plus fiable le travail sur les bourses nous
souhaiteront aussi avoir la possibilité d’automatiser tout le processus de sélection des
boursiers, en concevant une application nouvel application ou en fessant évoluer SG-
BOURSE.
75
REFERENCES Bibliographie et
webographie
Bibliographie
[1] Cours d’UML M. LOYA Youssouf, Université Aube-Nouvelle, 383pages 2016
[2] Joseph Gabay. David Gabay UML 2 ANALYSE ET CONCEPTION 2008,
242pages
[2] Cours de JAVA, M. OUOBA Hadi, Université Aube-Nouvelle, 55pages 2017
[3] Programmer en java 5e édition 2008, Editions Eyrolles, 816pages
[4] Pascal Roques. 2008. UML 2 par la pratique (6e édition). Paris : Editions Eyrolles,
368 pages
[5] Mémoires OUEDRAOGO N. Jean-Jacques 1er J & OUEDRAOGO J. Jean Luc 2e
J, « Analyse, Conception et Réalisation d’une plateforme de cartographie et d’édition de
statistiques des établissements d’enseignement du Burkina-Faso ». 2017, ESI
[6] Mémoires Nafissatou Carine KABORE, « Etude et réalisation d’une application de
gestion des dépôts à terme (DAT) et des chèques bancaires de la CARFO ». 2018,
Université Aube Nouvelle
Webographie
[1] https://fr.wikipedia.org/wiki/GanttProject 18/05/18
[2] https://openclassrooms.com/courses/apprenez-a-programmer-en-java/les-
methodes-declasse 02/05/18
[3] https://fr.wikipedia.org/wiki/Constructive_Cost_Model 18/05/18
[4] https://www.developpez.net/forums/d1118446/java/general-java/apis/java-
util/calculertemps-ecoule-entre-dates/ 10/03/18
[5] https://fr.wikipedia.org/wiki/Client-serveur 18/05/18
[6]https://emploi.developpez.com/actu/199867/Emploi-developpeur-2017-les-
SGBD-les-plus-demandes-et-les-mieux-payes-MySQL-MongoDB-et-PostgreSQL-
plus-demandes-mais-MongoDB-et-DB2-mieux-payes/ 02/05/18
76
Annexes
La plate-forme Java (the Java Platform en anglais, plateforme Java 2 anciennement) est
un standard de facto de plate-forme logicielle, produit par Sun Microsystems, puis
Oracle Corporation, permettant de développer et d'exécuter des programmes écrits en
A
langage Java indépendants de tout processeur et de tout système d'exploitation,

conformément à la technologie Java.
Toute plate-forme Java se compose principalement d'un moteur d'exécution (appelé une
machine virtuelle Java, ou 'JVM') et d'un compilateur fourni avec un ensemble de
bibliothèques standards dont il existe plusieurs implémentations pour divers matériels
et systèmes d'exploitation, de façon que les programmes Java puissent s'exécuter de
façon identique sur chacun d'entre eux.
Chaque version de plate-forme Java répond à des spécifications normalisées dans les
Java Specification Requests ou (JSR). Plusieurs versions de cette plateforme3 cohabitent
mi-2015, avec des JVM propres, Oracle implémentant et proposant notamment ses
propres implémentations : HotSpot pour Java SE, serveur Glassfish pour Java EE.
À l'instar de la plateforme Microsoft .NET ou de l'environnement Eclipse qui ciblent

plusieurs langages, la plateforme Java vise à supporter d'autres langages de
programmation que son langage natif Java.
Quelle est la différence entre les plates-formes JRE et SE ?

Java SE
JRE
(plate-forme Java,
(Java Runtime Environment)
Standard Edition)
Aux développeurs de
À qui est- Aux utilisateurs exécutant des
logiciels créant des applets
elle applets et des applications créés à
et des applications à l'aide de
destinée ? l'aide de la technologie Java.
la technologie Java.
C'est un kit de
C'est un environnement nécessaire développement logiciel
De quoi à l'exécution d'applets et utilisé pour créer des applets
s'agit-il ? d'applications créés à l'aide du et des applications à l'aide du
langage de programmation Java. langage de programmation
Java.
La plate-forme Java 2 est La plate-forme Java 2 est
Comment distribuée gratuitement et distribuée gratuitement et
l'obtenir ? disponible sur : disponible sur :
java.com oracle.com/javase
B
Quelle est la différence entre JRE et JDK ?

JRE
JDK
(Java Runtime
(Java Development Kit)
environment)
Il s'agit d'une
implémentation de la
Il s'agit d'un bundle de logiciels que vous pouvez utiliser
machine virtuelle
pour développer des applications Java.
Java* qui exécute des
programmes Java.
Java Runtime
Environment est un
Le kit de développement Java (JDK) est requis pour le
plug-in requis pour
développement d'applications Java.
l'exécution de
programmes Java.
Le JRE est moins
Le JDK requiert davantage d'espace disque car il
volumineux que le
contient le JRE ainsi que divers outils de
JDK et requiert donc
développement.
moins d'espace disque.
Le JRE peut être
téléchargé/pris en Le JDK peut être téléchargé/pris en charge
charge gratuitement gratuitement sur
sur oracle.com/technetwork/java/javase/downloads/
java.com
Il contient le JVM, les
bibliothèques de base
et d'autres composants
Il contient le JRE, un jeu de classes API, un compilateur
supplémentaires pour
Java, Web Start et d'autres fichiers requis pour l'écriture
l'exécution
d'applets et d'applications Java.
d'applications et
d'applets écrits dans
Java.
C

Langue

Application de Gestion Des Bourses Scolaires (BONZI Philipe Soumboza)

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Application de Gestion Des Bourses Scolaires (BONZI Philipe Soumboza)

Transféré par

Droits d'auteur :

ETUDE ET CONCEPTION D'UNE APPLICATION DE GESTION DES BOURSES SCOLAIRES OCTROYEES AUX AYANTS

DROIT DES PENSIONNES DECEDES

Table des matières

II.6) Diagramme d’activité ..................................................................................................... 49

Conclusion générale ....................................................................................................................... 75

Liste des tableaux

Liste des figures

IDE Integrated Development Environment

IRS Ingénierie des Réseaux et Systèmes

SGBD Système de Gestion de Base de Données

Malheureusement on enregistre des cas de décès de retraités. Dans de pareilles situations

Afin de permettre un suivi approprié de la gestion de ces bourses, il serait nécessaire

L’application que nous avons développé nommée SG-BOURSES a été réalisée en

I.2 Présentation de l’U-AUBEN

I.2.1 Présentation générale

Le siège de l'U-AUBEN est situé au cœur du quartier 1200 logements, de la ville de

➢ Six (06) UNITÉS DE FORMATION ET DE RECHERCHE (UFR) :

➢ Six (04) CENTRES :

I.3 Présentation de la structure d’accueil :

156/PRES/PM/MFPRE/MEF du 3 avril 2008 approuvant ses statuts particuliers. Bien

I.3.1.1 Missions et Objectif

La CARFO a pour objet la gestion :

Figure 01 : Organigramme de la CARFO

I.3.3 La Direction du Système d’Information

La Direction des systèmes d’information est chargée :

➢ du suivi de l’exploitation et de la maintenance du réseau ;

I.4 Présentation du projet :

I.4.2 Objectifs de l’étude :

I.4.2.2 Objectifs spécifiques :

I.4.3 Résultats attendus :

I.4.4 Gestion du projet :

Les acteurs du projet représentent l’ensemble des personnes qui participeront à sa

Le groupe de projet est constitué de :

c) Le groupe des utilisateurs

Il est constitué par :

I.4.4.2 Planning prévisionnel :

Tableau 1 Liste de tâches

Le planning prévisionnel est représenté par la Figure 2.

Figure 02 : Diagramme prévisionnel

CHAPITRE II DEMARCHES ET MOYENS

II.2 Exigences fonctionnelles et techniques

II.3 Méthode de résolution du problème

principaux utilisateurs du système. Ils permettent par conséquent une participation

❖ Le diagramme de cas d’utilisation (DCU)

Le diagramme de cas d’utilisation décrit les fonctionnalités du système et la manière

Figure 03 : Formalisme éléments de cas d’utilisation

Figure 04 : Formalisme d’un cas d’utilisation

Figure 05 : Formalisme d’une classe

Relation entre classe :

Figure 06 : Formalisme d’un diagramme de classe

Le diagramme de séquence est un élément du diagramme interactions, qui sert à décrire

• Participant (objets, acteurs) :

Figure 07 : Formalisme d’un objet et d’un acteur

• Ligne de vie des participants

Figure 08 : Formalisme d’une Ligne de vie

Figure 09 : Formalisme d’une période activation

• Fragment d’interaction combiné

• REF l’opérateur référence, on utilise cet opérateur pour permettre d’appeler

Figure 10 : Formalisme d’un diagramme de séquence

Figure 11 : Formalisme d’un Nœud

Figure 12 : Formalisme d’un Artefact

• Liens entre un artefact et les autres éléments du diagramme

Figure 13 : Formalisme d’un diagramme de déploiement

II.3.2 Langage de modélisation Le processus Two Track Unified

Le 2TUP propose un cycle de développement en Y,