Bibliographie

BIBLIOGRAPHIE

[1] Dominique Dionisi, L’essentiel sur merise, Eyrolles, 1993

 [2] Hubert Tardieu, La  méthode merise, Éditions d'Organisation, 1983

 [3] M. KOPOIN KOPOIN Apollinaire,Cours Merise 2

 [4] Jean-Luc BAPTISTE, Merise Guide pratique (nouvelle édition), Eni éditions

                               WEBOGRAPHIE

[1] LES TEACHERS DU NET, www.teachersdunet.com

[2] PC SOFT, www.pcsoft.fr

[3] OPENCLASSROM, www.openclassrom.com

[4] DEVELOPPEZ.NET, www.developpez.net

Conclusion

CONCLUSION

La DECFINEX (Direction des Etablissements de Crédits et de FINances EXtérieurs) dans le souci d’améliorer ses services, la qualité de ses prestations et de fournir des rapports détaillés et plus fiables à son organe supérieur qui est la DGTCP (Direction Générale du Trésor et de la Comptabilité Publique) a  initié  le  projet d’automatisation du  processus de traitement des demandes d’autorisation de change de ses usagers.

Ce  logiciel  a  pour  but de  faciliter  la  tâche à la DECFINEX  en  lui permettant un suivi plus minutieux des traitements des demandes en vue de contrôler la fraudes et rendre les documents disponible le plus tôt et aussi de fournir des rapports plus détaillés à la Direction générale au moment opportun.

La réalisation de ce projet  a été très bénéfique dans la mesure où elle nous a permis d’avoir un aperçu  du  travail    en  entreprise  et  d’appliquer  les  connaissances acquises  durant  notre formation.

Ce  projet  nous  a  aussi  permis  d’améliorer  nos  connaissances  sur  les  bases  de données MYSQL, le langage Angular, Spring Boot et bien d’autres. Aussi,  le  fait  de côtoyer les  agents de la  Direction  des Systèmes  d’Informations de  la DGTCP nous a permis de nous familiariser avec le monde du travail et d’avoir une vue d’ensemble sur le fonctionnement d’une institution de l’Etat de COTE D’IVOIRE.

Réalisation du projet

Chapitre III : Réalisation

I.    CHOIX TECHNOLOGIQUE

En  tenant  compte  de  la  contrainte  technique,  le  SGBD  et  l’environnement  de développement étaient imposés. Dans ce chapitre, nous présenterons ces outils.

1.  Présentation du SGBD MYSQL

MySQL est un Système de Gestion de Bases de Données Relationnelles qui utilise le langage SQL. C'est un des SGBDR les plus utilisés. Sa popularité est due en grande partie au fait qu'il s'agit d'un logiciel open source, ce qui signifie que son code source est librement disponible et que quiconque en ressent l'envie et/ou le besoin peut modifier MySQL pour l'améliorer ou l'adapter à ses besoins. Une version gratuite de MySQL est par  conséquent  disponible.  À  noter  qu'une  version  commerciale payante  existe également.

a.   Avantage du SGBD MYSQL

La  version  de MYSQL  que  nous  utiliserons  ici,  présente  les avantages suivants :

• MySQL fonctionne sur de nombreuses plates-formes différentes;
• Dispose d’une vaste bibliothèque de fonctions et d’API ;
•  Multi Thread ;
•  Haute capacité de stockage;

2. Présentation du langage de programmation

Un langage de programmation est une notation conventionnelle destinée à formuler des algorithmes et produire des programmes informatiques qui les appliquent. C’est aussi un moyen de communication par lequel le programmeur  communique avec la machine mais également avec d’autres programmeurs.

Ainsi les langages de programmation que nous utiliserons dans notre environnement de développement est le langage Angular CLI et Spring boot.

a.  Angular CLI

Angular  est  un  Framework  JavaScript côté  client  qui permet  de  réaliser des applications  de type "Single  Page  Application".  Il est basé sur le concept de l'architecture MVC (Model View Controller) qui permet de séparer les données, les vues et les différentes actions que l'on peut effectuer.

Le code source d'Angular est écrit en TypeScript. Le TypeScript est une couche supérieure au JavaScript développé  par  Microsoft qui  se  compile  en  JavaScript simple. Etant un langage typé, il permet de créer des classes, des variables, des signatures de fonction et l'utilisation de modules.

b.  Spring boot

Spring Boot est un Framework qui facilite le développement d'applications fondées sur Spring  en offrant  des  outils  permettant  d'obtenir  une  application  packagée  en   jar, totalement autonome. Ce qui nous intéresse particulièrement, puisque nous essayons de développer des Micro services !

c.  Architecture 3 tiers

Une architecture 3 tiers encore appelée architecture à 3 niveaux est un système divisé en trois couches ou niveaux qui sont :

• Un serveur de d’application ou middleware ;
• Un serveur secondaire ;
• Le poste client ;

Dans cette approche,  les couches  communiquent  entre  elles  au  travers  d'un « modèle d'échange », et chacune d'entre elles propose un ensemble de services rendus. Les services d'une couche sont mis à disposition de la couche supérieure.

II.    PRESENTATION DE L’APPLICATION

Pour  exécuter  notre  application,  nous  avons  besoin  d’un  navigateur web.  Afin d’éviter  certains bugs,  il    est  conseiller  d’utiliser  "Google  chrome"  comme navigateur web et être connecté au réseau internet du Trésor.

• La page de connexion

Au lancement de l’application, une fenêtre d’authentification s’affiche. Cette fenêtre  va permettre aux   utilisateurs  de  s’identifier  avant  d’avoir  accès  aux  fonctionnalités  de l’application.

Une fois connectée nous sommes redirigés vers l’écran d’accueil qui est constitué de plusieurs services. Pour notre cas le service concerné est « Dossier »

• La page d’accueil du service « Dossier »

•  La page pour l’enregistrement d’un bordereau.

Cette page permet d’enregistrer les bordereaux déposés par les différentes banques.  Ces bordereaux sont composés de plusieurs dossiers de demandes d’agrément immanentes de leurs clients.

•  La page d’enregistrement des dossiers composants un bordereau

Cette date permet d’enregistrer chaque dossier d’un bordereau en les rattachant aux banques respectives.

• La page d’imputation des bordereaux

Cette page permet d’imputer un bordereau à un agent pour le traitement des dossiers.

•  La page d’analyse

Cette page permet à l’agent de faire son analyse et soumettre ses résultats à son supérieur.

• Générer l’état de l’autorisation.

Cette page permet de générer l’état de l’autorisation de change des dossiers jugé aptes.

• La page d’ajout de la date de signature

Cette page permet d’enregistrer la date à laquelle la demande a été signée par le directeur.

• La page d’enregistrement des bordereaux de sorti

Cette page permet d’enregistrer les autorisations de change signé dans des bordereaux de sorti. Ceux ci sont générer par banque.

III.  PRESENTATION DES DIFFICULTES ET LES ENSEIGNEMENTS TIRES

1. LES DIFFICULTES

Au cours de notre stage, nous avons eu les difficultés suivantes :

• Confrontation  à un nouveau langage de programmation : ANGULAR 7 ;
• Confrontation  à nouveau SGBD : ORACLE ;
• Un temps court d’apprentissage des outils parce qu’il fallait passer immédiatement  au développement de l’application.

2. LES ENSEIGNEMENTS TIRES

Au cours de notre immersion professionnelle nous avions appris plusieurs chose tels que :

• L’apprentissage des nouveaux langages de programmations ;
• Le perfectionnement en certains langages de programmations déjà connus ;
• La capacité à gérer le stress dans un délai court  pour le développement d’une application.

Conception du projet

CHAPITRE II : CONCEPTION

PRESENTATION DU PROBLEME

• Contexte du problème

La direction mis en place pour gérer les transferts de fonds à l’étranger met  plusieurs services à la disposition des usagers dont les autorisations de changes, Cependant nous constatons que cette direction ne parvient pas à traiter les demandes dans des brefs délais et aussi fournir des rapports a la direction générale en temps réel. Ensuite nous constatons  la destruction de l’information due à la détérioration des documents archivés.

• Problématique

Au vu de ce qui précède, nous souhaiterions améliorer la qualité de traitement des demandes d’autorisation  de  change ainsi  que  la  conservation  des informations alors  nous  nous posons l’interrogation suivante : Quelle  solution  applicative  mettre  en  place  pour  améliorer  le processus de  traitement  des demandes d’autorisation de change à la DECFINEX?

ANALYSE DU PROBLEME

L’objectif de ce chapitre est d'aboutir à la modélisation de notre plateforme. Après une analyse des besoins décrits dans le cahier des charges de notre projet, il est nécessaire de donner un fonctionnement du système à implémenter. Alors, l'utilisation d'une méthode d’analyse et de conception constitue un impératif pour conduire à bien un projet de développement informatique. Nous effectuons, ici, le choix d’une méthode avant d’aborder en profondeur l’étude des besoins des utilisateurs.

I.     PRESENTATION DES METHODES D’ANALYSE

Une méthode d'analyse et de conception informatique a pour objectif de permettre de formaliser les étapes préliminaires du développement d'un système afin de le rendre plus fidèle aux  besoins  du client.  Et  parmi  toutes  les  approches  existantes. Pour  ce  faire,  on  part  d'un énoncé informel (le besoin  tel  qu'il  est  exprimé  par  le  client,  complété  par  des  recherches d'informations auprès des experts du domaine fonctionnel, comme les futurs utilisateurs d'un logiciel), ainsi que de l'analyse de l'existant éventuel (c'est-à-dire la manière dont les processus à traiter par le système se déroulent actuellement chez le client).

Il y a plusieurs méthodes d’analyse et de conception en informatique telles que :

• MERISE ;
• SADT ;
• UP (unified process ou procédure unifié en français) ;
• Etc.

En ce qui nous concerne, notre choix s’est porté sur la méthode MERISE. Contrairement aux  autres méthodes d’analyse  telles que UP qui est une méthode utilisée dans le développement des logiciels orientés objets, MERISE est une méthode séquentielle basée sur le principe de la séparation des données et des traitements.

1.  La méthode MERISE

MERISE est une méthode de conception, de développement et de réalisation de projets informatiques. Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode  MERISE  est  basée sur la séparation des données et des traitements en modèles conceptuels et physiques.
Elle possède un certain nombre de modèles (ou schémas) qui sont répartis sur 3 niveaux:

•  Le niveau conceptuel ;
•  Le niveau logique ou organisationnel ;
•  Le niveau physique.

2.  Cycle de vie d’un projet MERISE

Comme pour toutes les fabrications, il est important d’avoir un procédé de fabrication du logiciel bien  défini  et  explicitement  décrit.  En  effet  le  développement  d’un  projet sous MERISE implique une démarche et des étapes à suivre afin d’arriver au résultat souhaité.

Le cycle de vie d’un logiciel désigne toutes les étapes du développement d'un logiciel, de sa conception à sa disparition. L'objectif d'un tel découpage est de permettre de définir des jalons intermédiaires  permettant  la  validation du  développement  logiciel,  c'est-à-dire  la conformité  du logiciel  avec  les  besoins  exprimés,  et  la  vérification  du  processus  de développement, c'est-à dire l'adéquation des méthodes mises en œuvre.

Afin d'être en mesure d'avoir une méthodologie commune entre le client et la société de service réalisant  le  développement,  des  modèles  de  cycle  de  vie  ont  été  mis  au  point définissant  les étapes  du  développement  ainsi  que  les  documents  à  produire  permettant  de valider chacune des étapes avant de passer à la suivante. Comme modèle de cycle de vie l’on peut répertorier les modèles suivants :

• Le modèle en cascade ;
• Le cycle en V ;
• Le cycle en spiral.

En  ce  qui  concerne  notre  projet,  nous  utiliserons  le  modèle  en  cascade,  qui  est  un  modèle linéaire c’est-à-dire une succession d’étapes où chaque étape doit être validée pour passer à la suivante.

En appliquant les étapes du modèle en cascade à notre méthode d’analyse nous obtenons les étapes suivantes :

3.  Etude technique

Pour la réalisation de notre analyse, nous appliquerons à notre projet les différents modèles de MERISE suivants :

• Le modèle conceptuel de données (MCD) ;
•  Le modèle conceptuel de traitement (MCT) ;
• Le modèle organisationnel de traitement (MOT) ;
• Le modèle logique des données (MLD) ;
•  Le modèle physique des données (MPD).

a)  Élaboration du Modèle Conceptuel de données (MCD)

Pour l’élaboration du MCD nous ferons :

•  Le dictionnaire des données

Le dictionnaire des données représente la liste de toutes les propriétés manipulées dans le domaine d’étude.

Propriété	Signification	Type	Taille	Nature	observation
idBordereau	Identifiant du bordereau	AN	100	E	identifiant
dateCreation	Date de création du bordereau	Date
statut	Statut du bordereau	AN	100	E
numBordereau	Numéro du bordereau	N	100	E
isIndiv	Bordereau individuel ou pas	AN	10	E
nombreDossier	Nombre de dossier constituant le bordereau	N	10	E
bordCreatedOn	Bordereau créer par	AN	100	E
bordIsDelete	Bordereau Supprimer ou pas	AN	10	E
adresseIp	IP de la machine d’enregistrement	AN	100	E
dateRetrait	Date de  retrait du bordereau	Date
dateSoumission	Date de soumission pour traitement	Date
idBanque	Identifiant de la banque	N	10	E	identifiant
libelleBanque	Libelle de la banque	AN	100	E
sigle	Sigle de la banque	AN	50	E
bankCreatedOn	Banque créer par			E
bankIsDeleted	Banque supprimé ou pas	AN	10	E
idTypeBordereau	Identifiant du type de bordereau	N	10	E	identifiant
libTypeBordereau	Libelle du type de bordereau	AN	100	E
TypeisDeleted	Type supprimé ou pas	AN	10	E
idDossier	Identifiant du dossier	N	10	E	identifiant
numOrdre	Numéro d’ordre bordereau	N	10	E
demandeur	Nom du demandeur	AN	100	E
beneficiaire	Nom du bénéficiaire	AN	100	E
destination	Pays de destination	AN	100	E
tauxDeChange	Taux de change	N	100	E
montantCFA	Montant en FCFA	N	500	E
codeTransfert	Code du transfert	AN	10	E
idDevise	Identifiant de la devise	N	10	E	identifiant
libDevise	Libelle de la devise	AN	100	E
idMotifAnalyse	Identifiant du motif d’analyse	N	10	E	identifiant
libMotifAnalyse	Libelle du motif d’analyse	AN	100	E
idPieceAnalyse	Identifiant de pièce d’analyse	AN	10	E	identifiant
libPieceAnalyse	Libelle pièce analyse	AN	100	E
idDetailAnalyse	Identifiant du détail analyse	AN	10	E	identifiant
matAgentAnalyse	Matricule de l’agent ayant fait l’analyse	AN	50	E
AgentAnalyseIp	IP de l’agent analyseur	AN	50	E
idImputation	Identifiant de l’imputation	N	10	E	identifiant
agentImputeur	Matricule de l’attributaire	AN	50	E
agentImputer	Matricule de l’imputer	AN	50	E
dateImputation	Date de l’imputation	Date
niveauImputation	Le niveau de l’imputation	N	10	E
observationImputation	Observation de l’imputation	AN	100	E
etatImputation	Etat de l’imputation	N	10	E
delaiTraitement	Délai de traitement du dossier imputé	Date

E : Elémentaire                                 N : Numérique                                AN : Alphanumérique

• Les règles de gestion

Les règles de gestion expriment les contraintes ou des choix particuliers à prendre en compte lors de l'élaboration du modèle conceptuel des données.

RG 1 : Une banque peut faire une ou plusieurs demandes via un bordereau de demande;

RG 2 : Un bordereau demande est liée à une et une seul entité ;

RG 3 : Un bordereau de demande peut contenir un ou plusieurs dossiers ;

RG 4 : Un dossier appartient à un et un seul bordereau de demande ;

RG 5 : Un bordereau a un type (Entré ou sorti) ;

RG 6 : Un bordereau de demande est imputé à un ou plusieurs agents pour analyse ;

RG 7 : Une imputation concerne un et un seul bordereau  de  demande;

RG 8 : Un dossier peut faire l’objet de zéro ou plusieurs analyse ;

RG 9 : Une analyse concerne un et un seul dossier ;

RG 10 : Une analyse porte sur un motif d’analyse ;

RG 11 : Un motif d’analyse est composé de plusieurs pièces d’analyse;

•  Le MCD à proprement dit

Le MCD est  une représentation schématique des différentes entités et les associations qui existent entre ces entités.

b)  Modèle conceptuel de traitement (MCT)

Le modèle conceptuel des traitements  permet de  traiter  a dynamique du système d'information, c'est-à-dire les opérations qui sont réalisées en fonction d'événements.

Ce  modèle  permet de  représenter  de  façon  schématique  l'activité  d'un  système d'information sans  faire  référence  à  des  choix  organisationnels  ou  des  moyens d'exécution, c'est-à-dire qu'il permet de définir simplement ce qui doit être fait, mais il ne  dit  pas  quand,  comment  ni  où.

 c) Modèle Organisationnel des traitements (MOT)

Le  modèle  organisationnel  des  traitements  s'attache  à  décrire  les  propriétés  des traitements non traitées par le modèle conceptuel des traitements, c'est-à-dire : le temps, les ressources,  le  lieu.  Le modèle organisationnel des traitements consiste donc à représenter le modèle conceptuel des traitements dans un tableau dont les colonnes sont la durée, le lieu, les responsables et ressources nécessaires à une action.

Légende :
T : moment quelconque de la journée des jours ouvrables
P : période fixe de l’année
NOK : non ok
M.A : manuelle Automatique.

d)  Modèle Logique des Données(MLD)

Le modèle logique des données consiste à décrire la structure de données utilisées sans faire référence  à  un  langage  de  programmation.  Il s'agit donc  de  préciser le type  de  données utilisées  lors  des traitements.  Le MLD est déductible du MCD validé en tenant compte  des règles de passage.

• Règle de passage du MCD au MLD

MCD	MLDR
Entité	relation ou table
Propriété	attribut (champ)
Identifiant	clé

• Elaboration du MLD

Dos_bordereau

(

IdBordereau,

#idTypeBordereau,

#idBanque,

DateCreation, StatutBordereau, NumBordereau, IsIndiv, NombreDossier, CreatedBy, CreatedOn, AdresseIp, IsDelete, DateRetrait, DateSoumission

)

Dos_banque

(

IdBanque,

LibBanque, Sigle, CreatedBy, CreatedOn, AdresseIp, IsDelete,

)

Dos_TypeBordereau

(

idTypeBordereau,

libTypeBordereau, CreatedBy, CreatedOn, AdresseIp, IsDelete,

)

Dos_dossier

(

IdDossier,

#idBordereau,

#idDevise,

numOrdre, numEnregistrement, demandeur, beneficiaire, destination, montantDevise, montantCfa, tauxChange, codeTransfert, dateArriveeDecfi, dateSoumission, dateRetrait, observation, dossierSorti, matriculeAgent, dateSignature, CreatedBy, CreatedOn, AdresseIp, IsDelete,

)

Dos_devise
(
IdDevise,
libDevise, codeDevise, CreatedBy, CreatedOn, AdresseIp, IsDelete,
)

Dos_imputation
(
IdImputation,
#idBordereau,
Attributaire, AgentImputer, DateImputation, NiveauImputation, Observation, EtatImputation, DelaiTraitement, CreatedBy, CreatedOn, AdresseIp IsDelete,
)

Dos_analyse
(
IdAnalyse,
#idDossier,
#idMotifAnalyse,
resultatAnalyse, dateAnalyse, Observation, MatriculeAgent, CreatedBy, CreatedOn, AdresseIp IsDelete,
)

Dos_motifAnalyse
(
IdMotifAnalyse,
libMotifAnalyse, codeMotifAnalyse, CreatedBy, CreatedOn, AdresseIp, IsDelete,
)

Dos_pieceAnalyse
(
idPieceAnalyse,
#IdMotifAnalyse,
libPieceAnalyse, CreatedBy, CreatedOn, AdresseIp, IsDelete,
)

e) Modèle Physique  des Données (MPD)

Nom : Code : Clé primaire : Source : Longueur :	Dos_Bordereau Dos_Bordereau IdBordereau disque dur 120
Liste des colonnes
Nom		Code	longueur	Type
Identifiant du bordereau		IdBordereau	10	AN
Date de création du bordereau		DateCreation	10	Date
Statut du bordereau		StatutBordereau	10	AN
Numéro du bordereau		NumBordereau	10	AN
Bordereau individuel ou collectif		IsIndiv	10	AN
Nombre de dossier du bordereau		NombreDossier	10	N
Date de retrait du bordereau		DateRetrait	10	Date
Date de soumission du bordereau		DateSoumission	10	Date
Bordereau créé par		CreatedBy	10	AN
Bordereau créé le		CreatedOn	10	Date
Adresse IP de la machine		AdresseIp	10	AN
Bordereau supprimé		IsDelete	10	AN

Nom : Code : Clé primaire : Source : Longueur :	Dos_banque Dos_banque IdBanque disque dur 70
Liste des colonnes
Nom		Code	longueur	Type
Identifiant de la banque		IdBanque	10	AN
Nom de la banque		LibBanque	10	Date
Sigle de la banque		Sigle	10	AN
Bordereau créé par		CreatedBy	10	AN
Bordereau créé le		CreatedOn	10	Date
Adresse IP de la machine		AdresseIp	10	AN
Bordereau supprimé		IsDelete	10	AN

Nom : Code : Clé primaire : Source : Longueur :	Dos_TypeBordereau Dos_TypeBordereau idTypeBordereau disque dur 30
Liste des colonnes
Nom		Code	longueur	Type
Identifiant du type de bordereau		idTypeBordereau	10	AN
Libelle du type de bordereau		libTypeBordereau	10	Date
Bordereau supprimé		IsDelete	10	AN
Nom : Code : Clé primaire : Source : Longueur :	Dos_dossier Dos_dossier IdDossier disque dur 230
Liste des colonnes
Nom		Code	longueur	Type
Identifiant du dossier		IdDossier	10	AN
Numéro d’ordre du dossier		numOrdre	10	N
Numéro d’enregistrement		numEnregistrement	10	N
Nom du demandeur		demandeur	10	AN
Nom du bénéficiaire		beneficiaire	10	AN
Pays de destination		destination	10	AN
Montant de devise		montantDevise	50	N
Montant en FCFA		montantCfa	50	N
Taux de change		tauxChange	10	N
Code du transfert		codeTransfert	10	AN
Date d’arrivée du dossier		dateArriveeDecfi	10	Date
Date soumission du dossier		dateSoumission	10	Date
Date de retrait		dateRetrait	10	Date
Observation		observation	10	AN
Matricule agent		matriculeAgent	10	AN

Nom : Code : Clé primaire : Source : Longueur :	Dos_imputation Dos_imputation IdImputation disque dur 70
Liste des colonnes
Nom		Code	longueur	Type
Identifiant de l’imputation		IdImputation	10	AN
Nom de l’attributaire		Attributaire	10	AN
Nom de l’agent impute		AgentImputer	10	AN
Date de l’imputation		DateImputation	10	Date
Niveau de l’imputation		NiveauImputation	10	AN
observation		Observation	10	AN
Délai de traitement		DelaiTraitement	10	Date
Etat de l’imputation		EtatImputation	10	AN
Bordereau supprimé		IsDelete	10	AN