2544achouri Khaled PFE 2017-2018

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA
RECHERCHE SCIENTIFIQUE
Université Libre de Tunis
*******
Projet de Fin d’Etudes

En vue de l’obtention du Diplôme License en Informatique Spécialité : Informatique
appliquée à la gestion
Elaboré par :
ACHOURI KHALED
REALISATION D’UNE APPLICATION ANDROID ET WEB
«BTAPP»
Réalisé au sein de la
BANQUE DE TUNIS (BT)
Encadré par
Encadrant(s) universitaire(s) Encadrant(s)

professionnel(s)
Mr. Ghazouani Haythem Mr.Belgasmi Nabil
Mr.Med Cherif Bachamba
Année universitaire 2017 - 2018

Dédicaces
Achouri Khaled
i
Remerciement
ii
Table des matières
Introduction générale .............................................................................................................................. 1
Chapitre I. Etude Préalable................................................................................................................ 3
I.1 Introduction ............................................................................................................................. 3
I.2 Présentation de l’université ..................................................................................................... 3
I.3 Profil de l’entreprise ................................................................................................................ 3
I.3.1 Description .......................................................................................................................... 4
I.3.2 Organigramme de l’entreprise ............................................................................................. 5
I.4 Présentation du Projet.............................................................................................................. 6
I.4.1 Contexte du projet ............................................................................................................... 6
I.4.2 Objectifs du projet ............................................................................................................... 6
I.4.3 L’intérêt de l’application ..................................................................................................... 6
I.5 Etude de l’existant ................................................................................................................... 6
I.5.1 Critique de l’existant ........................................................................................................... 7
I.5.2 Solution proposée ................................................................................................................ 7
I.6 Travail à faire .......................................................................................................................... 8
I.7 Conclusion............................................................................................................................... 8
Chapitre II. Sprint 0 ............................................................................................................................ 9
II.1 Introduction ............................................................................................................................. 9
II.2 Méthode de travail ................................................................................................................... 9
II.2.1 La gestion de projet ......................................................................................................... 9
II.2.2 Méthodologies de développement ................................................................................. 10
II.2.3 Comparaison entre les méthodes ................................................................................... 10
II.2.4 Méthodologie adoptée ................................................................................................... 12
II.3 Etude des besoins .................................................................................................................. 15
II.3.1 Besoins Fonctionnels..................................................................................................... 15
II.3.2 Les besoins non fonctionnels ........................................................................................ 19
II.4 Définition des acteurs ............................................................................................................ 19
II.4.1 Identification des acteurs ............................................................................................... 19
II.4.2 Description des acteurs.................................................................................................. 20
II.5 Backlog du produit ................................................................................................................ 20
II.6 Planification des releases ...................................................................................................... 23
II.7 Diagramme de cas d’utilisation globale ................................................................................ 23
II.8 Technologies et outils de développement ............................................................................. 24
II.8.1 Présentation du système d’exploitation mobile Android............................................... 24
II.8.2 Architecture de l’application mobile (front office) ....................................................... 24
II.8.3 Architecture de la page web (Back office) .................................................................... 26
II.9 Environnement technique du travail...................................................................................... 27
II.9.1 Outils de développement ............................................................................................... 27
iii
....................................................................................................................................................... 27
II.9.2 Languages de modélisation ........................................................................................... 28
II.9.3 Langages de conception ................................................................................................ 28
II.9.4 Langages de développement ......................................................................................... 29
II.10 Diagramme de Classe Global ................................................................................................ 30
II.11 Conclusion............................................................................................................................. 31
Chapitre III. Release 1 Front office ................................................................................................... 32
III.1 Introduction ........................................................................................................................... 32
III.2 Organisation des sprints ........................................................................................................ 32
III.3 Sprint 1 : Authentification des agents ................................................................................... 33
III.3.1 Planification du Sprint ................................................................................................... 33
III.3.2 Diagramme de cas d’utilisation ..................................................................................... 33
III.3.3 Description textuelle ..................................................................................................... 33
III.3.4 Diagramme de séquence « Inscription » ....................................................................... 34
III.3.5 Test « Inscription »........................................................................................................ 35
III.3.6 Diagramme de séquence Authentification .................................................................... 35
III.3.7 Test Authentification ..................................................................................................... 36
III.4 Sprint 2 : Création et traitement des réclamations ................................................................ 36
III.4.1 Planification du sprint ................................................................................................... 36
III.4.2 Diagramme de cas d’utilisation ..................................................................................... 37
III.4.3 Description textuelle ..................................................................................................... 37
III.4.4 Diagramme de séquence de « saisie de la réclamation »............................................... 38
III.4.5 Test ................................................................................................................................ 39
III.4.6 Diagramme de séquence de « Consulter historique » ................................................... 39
III.5 Conclusion............................................................................................................................. 40
Chapitre IV. Release 2 Back Office ............................................................................................... 41
IV.1 Introduction ........................................................................................................................... 41
IV.2 Organisation des sprints ........................................................................................................ 41
IV.3 Sprint 3 : Gestion des réclamations et des comptes des agents par l’administrateur ............ 42
IV.3.1 Planification du sprint ................................................................................................... 42
IV.3.2 Diagramme de cas d’utilisation ..................................................................................... 43
IV.3.3 Description textuelle ..................................................................................................... 43
IV.3.4 Test « Authentification d’administrateur » ................................................................... 45
IV.3.5 Diagramme de séquence « Gestion des comptes des agents » ...................................... 46
IV.3.6 Test « Gestion des comptes des agents » ...................................................................... 47
IV.3.7 Diagramme de séquence « Gestion des réclamations »................................................. 47
IV.3.8 Test « Gestion des réclamations » ................................................................................. 48
IV.4 Sprint 4 : Traitement des réclamations par le responsable .................................................... 48
IV.4.1 Planification du sprint ................................................................................................... 48
iv
IV.4.2 Diagramme de cas d’utilisation ..................................................................................... 49
IV.4.3 Diagramme de séquence « Authentification du responsable » ...................................... 49
IV.4.4 Test « Authentification du responsable » ...................................................................... 50
IV.4.5 Diagramme de séquence « traitement des réclamations » ............................................. 50
IV.4.6 Test « Traitement des réclamations » ............................................................................ 51
IV.5 Conclusion............................................................................................................................. 51
Conclusions et perspectives .................................................................................................................. 52
Bibliographie ......................................................................................................................................... 54
v
Li
Liste des figures

Figure 1: Université Libre de Tunis (ULT) ..............................................................................................3
Figure 2: Banque de Tunisie (BT)............................................................................................................3
Figure 3: Les trois contraintes de projet ...................................................................................................9
Figure 4: La méthodologie agile Scrum .................................................................................................13
Figure 5: Mockup de la page de connexion ...........................................................................................17
Figure 6: Mockup de la page d'inscription .............................................................................................17
Figure 7: Mockup de la page de réclamation .........................................................................................17
Figure 8: Mockup de la page historique .................................................................................................18
Figure 9: Planification des releases ........................................................................................................23
Figure 10: Cas d'utilisation global de l'application ................................................................................23
Figure 11: Figure des différents systèmes d'exploitation mobile sur le marché.....................................24
Figure 12: Architecture générale de l’application mobile ......................................................................25
Figure 13:Diagramme de classe global ..................................................................................................30
Figure 14:Release 1 ................................................................................................................................32
Figure 15:Diagramme de cas d'utilisation globale du sprint 1 ...............................................................33
Figure 16: Diagramme de séquence "Inscription"..................................................................................34
Figure 17: Interface d'inscription ...........................................................................................................35
Figure 18: Diagramme de séquence "Authentification des agents" .......................................................35
Figure 19:Interface d'authentification ....................................................................................................36
Figure 20: Diagramme de cas d'utilisation du sprint 2 ...........................................................................37
Figure 21: Diagramme de séquence saisie de la réclamation .................................................................38
Figure 22: Interface de la page Saisie d'une réclamation .......................................................................39
Figure 23: Diagramme de séquence "Consulter historique" ..................................................................39
Figure 24: Release 2 ...............................................................................................................................41
Figure 25:Cas d'utilisation globale du sprint 3 .......................................................................................43
Figure 26: Diagramme de séquence "Authentification de l'administrateur" ..........................................45
Figure 27: Interface d'identification de l'administrateur ........................................................................45
Figure 28: Diagramme de séquence "Gestion des comptes des agents" ................................................46
Figure 29: Interface de gestion des comptes ..........................................................................................47
Figure 30: Diagramme de séquence "Gestion des réclamations" ...........................................................47
Figure 31: Interface de gestion des réclamations ...................................................................................48
Figure 32: Diagramme de cas d'utilisation globale du sprint 4 ..............................................................49
Figure 33: Diagramme de séquence "Authentification du responsable" ................................................49
Figure 34: Interface d'identification du responsable ..............................................................................50
Figure 35: Diagramme de séquence de "traitement des réclamations" ..................................................50
Figure 36: Interface de traitement de réclamation..................................................................................51
vi
Li
Liste des tableaux

Tableau 1: Backlog du Produit ...............................................................................................................21
Tableau 2: Description de la machine de développement ......................................................................27
Tableau 3:Backlog du sprint 1 ...............................................................................................................33
Tableau 4: Description textuelle des cas d'utilisation du sprint 1 ..........................................................34
Tableau 5: Backlog du sprint 2 ..............................................................................................................36
Tableau 6: Description textuelle des cas d'utilisation du sprint 2 ..........................................................37
Tableau 8: Description textuelles des cas d'utilisation du sprint 3 .........................................................43
vii
Introduction générale
Depuis une bonne lurette de temps, la Banque de Tunisie, a mis le poids en vue d’un
défit historique qui consiste de promouvoir le secteur vers un palier supérieur capable de gérer
les nouvelles tendances techniques dans le monde informatique.
De ce fait, un déploiement de matériel hautement sophistiqué a été installé par le biais de
ressources financières importantes consacrées pour la cause.
Le BLADE CENTER, une armada de serveurs rassemblant un support de stockage de grande

capacité, est un véritable témoin dans le domaine de l’informatique virtuelle de nos jours
fonctionnelle à outrance au sein de la Banque.
Des Serveurs de haute gamme placés dans les différents guichets du territoire résultent du fait
d’une envie de progression en matière de service et d’administration aux besoins de la clientèle.
D’autre part, la Banque de Tunisie, en tant qu’acteur important dans le secteur, tient de garder
au meilleur possible une image de marque susceptible d’ouvrir un chalenge sans égale dans le
marché économique aussi bien à l’échelle nationale qu’à l’échelle internationale…
Pour se faire, sur le plan réel, la banque propose de mettre en œuvre un outil technique capable
de gérer les éventuels incidents qui peuvent survenir soit aux agences soit au siège ou résident
les différents départements et services.
Notre projet objet de cet ouvrage est en faites une exploration dans le monde des réclamations
et suggestions qui ne cessent de surgir un peu partout, d’où l’obligation d’une intervention
prompte de la partie concernée afin de permettre une fonctionnalité continue et fluide du travail.
L’application ci- contre est développée à partir d’une base de données WEB pouvant être
supportée par les SMARTPHONES modernes (Android) donc ou vous soyez elle vous offre
des possibilités multiples à savoir :
1
 Accès aux réclamations envoyées par les différents interlocuteurs.
 Reconnaissance descriptive de l’incident (photo)
 Formuler une invitation à l’agent concerné (selon le type et la nature de l’incident).
 Recevoir en cours de traitement l’état actuel de l’incident (transmis-en cours de
réalisation-résolu-échu-…)
2
CHAPITRE I ETUDE PREALABLE
Chapitre I. Etude Préalable
I.1 Introduction
I.2 Présentation de l’université

L'Université Libre de Tunis « ULT », par sa large gamme de programmes d'études aux
trois cycles et ses activités diversifiées de recherche appliquée, a pour mission de former aussi
bien la relève que les personnes en situation d'emploi, de rendre accessible la connaissance de
pointe à tous les milieux sociaux et culturels et de servir la collectivité qui lui exprime ses
besoins. [1]
Figure 1: Université Libre de Tunis (ULT)
I.3 Profil de l’entreprise

Au cours du sixième semestre au sein de l’Université Libre de Tunis, On est demandé
de passer un stage de quatre mois qui devrait être couronné par un projet justifiant les fins
d’étude. Notre projet portera sur la conception et la réalisation d’une application Android
(mobile) et web pour le compte de la BANQUE DE TUNISIE (BT). [2]
Figure 2: Banque de Tunisie (BT)
3
I.3.1 Description
4
I.3.2 Organigramme de l’entreprise
5
I.4 Présentation du Projet

I.4.1 Contexte du projet
I.4.2 Objectifs du projet
I.4.3 L’intérêt de l’application
I.5 Etude de l’existant

L’étude de l’existant dans la réalisation de tout projet, consiste à bien étudier et analyser
des projets similaires. Elle nous permet de bien savoir les points faibles et les points forts du
projet afin de ne pas commettre les mêmes erreurs trouvées.
En effet, pour gérer au mieux possible le flux important des réclamations en provenance des
agences, la direction informatique au sein de la Banque de Tunisie, a mis en place un utilitaire
capable de créer des tickets d’incidents dans une base de données accessible aux opérateurs de
la cellule maintenance pour le traitement et l’examen des différents problèmes qui survient soit
au niveau « Software » ou au niveau « Hardware », un administrateur en ligne ayant le pouvoir
d’aiguiller les réclamations à la partie concernée de la direction informatique, il peut s’agir d’un
problème réseau ou d’un problème d’ordre matériel ou système etc...
Le responsable directe de l’équipe a qui est confié la résolution du problème reçu a le droit
d’accéder lui aussi à la base « HELP DESK » et ce en vue de faire un suivi minutieux et précis
à chaque étape du traitement.
Cela n’empêche que ce procédé reste toujours insuffisant quant à la nature du problème, la
diffusion de l’information avec tout ce qu’on peut rencontrer comme obstacle et contrariété.
6
I.5.1 Critique de l’existant

Il est à noter que le « HELP DESK » malgré le service qu’il présente aux cellules de la
direction informatique de la BT d’une part et aux agences d’autre part, il se trouve incapable
de :
 Envoyer un ticket d’incident directement au service de choix (un seul interlocuteur est
permis pour recevoir la réclamation).
 Manque d’usage associé au texte descriptif de l’incident
 Les réclamations d’ordre extra-informatique sont recenser au quotidien par la direction
des Moyens généraux de la BT et ce via la boite de réception baptisée pour la cause ou
via des notes écrites sous forme de lettres adressées par voie postale d’où le risque
d’erreur et de perte de l’information avant même le traitement de l’incident.
 Impossibilité de créer un ticket d’incident en dehors des locaux des agences de la banque
(le traitement se fait à partir des PC de travail de l’agence) puisque l’utilitaire n’est pas
sur le web donc on ne peut pas réclamer un incident à partir d’un smartphone ou support
extra-LAN
 Impossible au superviseur de faire un suivi en dehors de la banque (cas d’un chef
d’agence en congé, ou responsable des cellules informatique sous-indiquées en
séminaire ou en voyage etc…).
I.5.2 Solution proposée

La Banque de Tunisie m’a confié la tâche de concevoir et de développer une application
web et mobile. C’est dans ce contexte que vient s’inscrire mon projet de fin d’études. Il s’agit
en fait d’une application mobile qui permet aux agents de la banque de soumettre des
réclamations concernant des incidents bien déterminés d’une façon rapide et efficace ce
principe se base sur deux axes principaux :
 Any Time : continuité de service, au besoin de l’agent.
 Any Where : tout agent peut soumettre sa réclamation à partir de n’importe quel endroit
(domicile, bureau ou en déplacement).
7
I.6 Travail à faire

Le travail à faire est de développer une application de gestion des réclamations au sein de
la BT, cette application sera nommée « BTAPP », cette application est composée de deux
parties :
 Partie Front office :
o C’est une application Android qui est compatible par toutes les consoles
utilisant le système d’Android (Smartphone ou tablette), développée en
JAVA, elle a été mise en place pour les agents de la banque.
 Partie Back office :
o C’est une application web exploitable sur tous les navigateurs.
Développée en PHP, cette application a été mise en place pour les
administrateurs et responsables de département.
I.7 Conclusion
8
CHAPITRE II Sprint 0
Chapitre II. Sprint 0
II.1 Introduction
II.2 Méthode de travail

II.2.1 La gestion de projet
Figure 3: Les trois contraintes de projet
9
II.2.2 Méthodologies de développement
II.2.2.1 Le processus unifié
II.2.2.2 Les méthodes agiles
II.2.3 Comparaison entre les méthodes
10
Table 1: Comparaison entre les méthodes agiles
Description Points Forts Points Faibles

RUP - Le.RUP.est.à.la.fois - Itératif -
(Rational une méthodologie. - Coûteux.à
Unified et.un.outil Spécifie.le.dialogu personnali
Process) prêt.à.l'emploi e sé
(documents entre.les.différents -
types.partagés.dans.un intervenants.du. Très.axé.processus
référentiel Web) projet: les.livrables, , au.détriment.du
-.Adapté pour.des les plannings, développement :
projets qui les.prototypes… peu
comportent.plus.de. de.place.pour.le.co
10 personnes de
et.la.technologie
2TUP(Two - S'articule autour - Itératif Plutôt superficiel
Track de l'architecture - Laisse une large sur les phases
Unified - Propose un cycle place à la situées en amont
Process) de développement technologie et la et en aval du
en Y gestion du risque développement :
- Cible des projets - Définit les profils -capture des
de toutes tailles des intervenants, les besoins
livrables, les -support
plannings, les -maintenance
prototypes. -gestion du
changement
…
XP(eXtreme - Ensemble.de «Best - Itératif - Ne.couvre.pas.
Programmin Practices - les
g) ».de.développe- ment Simple.à.mettre.e phases.en.amont
(Idéal.pour.le.travail.en n œuvre .et en.aval.au
. groupe) -Fait.une.large.place .développement:
- Cible.des.projets.de aux.aspects.technique capture.des.besoi
moins.de.dix.person s: prototypes, ns support,
nes .règles.de maintenance,
développement, .tests
.tests… d'intégration…
- Assez.floue.dans
.sa mise.en.œuvre
11
II.2.4 Méthodologie adoptée
II.2.4.1 Présentation de Scrum
12
Figure 4: La méthodologie agile Scrum
Les artéfacts de Scrum

 Product Backlog (Backlog du produit):
13
ajoutées ou retirées à tout moment du carnet de produit. Cette flexibilité offerte au

propriétaire du produit est un grand avantage de Scrum.
 Sprint Backlog (Backlog du sprint) :
 Burn Down Chart (Graphic advancement) :
Les membres de l’équipe Scrum
Le Processus
14
Mêlée quotidienne (Daily Scrum)
II.3 Etude des besoins
II.3.1 Besoins Fonctionnels

Partie Front Office (Application mobile)
Les besoins fonctionnels se présentent comme suis :
- Inscription des agents.
- Soumettre la réclamation par l’agent.
o Remplissage d’un formulaire pour décrire la situation.
15
o Récupération des données GPS par l’agent.

o Insertion d’une photo afin d’enrichir la description de la situation
(camera/bibliothèque).
- Chaque agent peut consulter l’historique de ses réclamations.
Partie Back Office (Site Web)
Les Besoins fonctionnels se présentent comme suis :
- Authentification (Administrateur / Responsable).
- L’administrateur gère les comptes des agents (Activation, Suppression,
Récupération de mot de passe),
- L’administrateur peut consulter toutes les réclamations grâce à une liste générer
depuis une base de données.
- Dispatching des réclamations par l’administrateur.
- Traitement et clôture des réclamations par le responsable.
Partie front office
II.3.1.1 Inscription des agents
Pour pouvoir utiliser les services que présente l’application, les agents doivent s’inscrire
à cette application et attendre l’activation du compte auprès de l’administrateur. Dès que le
compte est activé l’agent peut alors s’authentifier afin de pouvoir utiliser l’application.
II.3.1.2 Soumettre une réclamation

Pour faire une réclamation qui décrit un incident quelconque l’utilisateur doit
commencer par remplir un petit formulaire contenant les informations nécessaires telles que :
 La provenance du problème (quelle agence ou quel département).
 Le choix du mot clé approprié pour décrire la situation.
 Ajout d’une image qui décrit la situation (depuis la camera en temps réel ou depuis
image déjà sauvegarder dans la bibliothèque du téléphone).
 Récupérer les données GPS d’une façon automatique en cliquant sur un bouton.
 Ajout d’un petit texte pour mieux décrire la situation.
Enfin l’agent peut soumettre la requête ou l’annuler selon des boutons spécifiques.
16
Figure 5: Mockup de la page de connexion Figure 6: Mockup de la page d'inscription
Figure 7: Mockup de la page de réclamation
17
II.3.1.3 Consulter l’historique

Chaque agent peut consulter son historique de réclamation grâce à la page d’historique
où il peut aussi voir l’état de chaque réclamation (en attente, en cours, annuler).
Figure 8: Mockup de la page historique
Partie back office

II.3.1.4 Authentification (Administrateur / agent)
On peut se connecter au site comme étant un administrateur pour gérer certaines tâches :
 Superviser les réclamations (consulter tout l’historique des réclamations et leurs
états).
 Dispatcher les réclamations aux différents départements.
On peut aussi se connecter au site en tant que responsable de département, ce dernier a

une tâche de traiter les réclamations reçues et les clôturer.
II.3.1.5 Gestion des comptes des agents

L’administrateur a la possibilité d’activer, désactiver ou même supprimer un compte
d’un agent au besoin (exemple: cas de départ à la retraite d’un agent).
II.3.1.6 Consulter l’historique des réclamations

L’administrateur a la possibilité de consulter toutes les réclamations qui ont été faites
18
par tous les agents et qui appartiennent à tous les départements.

Chaque responsable a la possibilité de consulter toutes les réclamations qui ont été
traitées par son propre département.
II.3.1.7 Dispatching des réclamations

L’administrateur doit dispatcher chaque réclamation au département concerné et de
faire en sorte de supprimer les réclamations redondantes.
II.3.1.8 Traitement des réclamations

Le responsable doit traiter la réclamation à l’aide de son équipe puis l’a clôturée en indiquant
son état :
 Valider, si la réclamation a été bien traité.
 Annuler, au cas échéant.
II.3.2 Les besoins non fonctionnels
II.3.2.1 Ergonomie et bonne interface (IHM) :
II.3.2.2 Compatibilité et portabilité :
II.3.2.3 Robustesse et sécurité :
II.4 Définition des acteurs

II.4.1 Identification des acteurs
Dans notre projet on a trois acteurs principaux qui sont :
o L’agent
19
o Le responsable de département
o L’administrateur
II.4.2 Description des acteurs
Ce tableau ci-dessous va nous définir les acteurs ainsi que leurs rôles.
Table 2: Description détaillé des acteurs
II.5 Backlog du produit
20
Tableau 1: Backlog du Produit

User Story Thèmes Sprint Priorité Estimation
(jours)
En tant qu’agent je Gestion
peux m’inscrire à d’inscription des 5
1 1
l’application agents
En tant qu’agent je Gestion des 7
peux m’authentifier authentifications 2
En tant qu’agent je Création d’une
peux saisir une réclamation 1 9
réclamation
peux ajouter les réclamation 1 6
coordonnées GPS
peux ajouter une réclamation
photo 2 1 10
(camera/bibliothèque)
peux soumettre ma réclamation 1 7
réclamation
En tant qu’agent je Consultation des
peux consulter mon réclamations
historique de concernant 2 12
réclamations l’agent
En tant Gestion
qu’administrateur je d’authentification 1 5
dois m’authentifier administrateur
En tant Gestion des
qu’administrateur je comptes d’agents 3
peux gérer les 14
comptes des agents 3
21
(ajouter,
supprimer…).
En tant Gestion des
qu’administrateur je réclamations
peux consulter
l’historique des 2 9
réclamations et
laisser des
commentaires.
En tant que Authentification
responsable je dois des responsables 1 5
m’identifier.
En tant que Consultation des
responsable je peux réclamations 2
consulter l’historique concernant les 4 7
de mon département. départements
En tant que Gestion des
responsable je traite réclamations
et clôture les 2 12
réclamations.
Totale 98 jours
22
II.6 Planification des releases

Release 1: Release 2:
Front Office Back Office
Sprint 3: Gestion des

Sprint1:Authentification réclamations et des
des Agents comptes par
l'administrateur
Sprint 2: Création et Sprint 4: Traitement des

traitement des réclamations par le
réclamations résponsable
Figure 9: Planification des releases
II.7 Diagramme de cas d’utilisation globale
Figure 10: Cas d'utilisation global de l'application
23
II.8 Technologies et outils de développement

II.8.1 Présentation du système d’exploitation mobile Android
Cette figure ci-dessous représente la dominance de l’Android sur le marché :
Figure 11: Figure des différents systèmes d'exploitation mobile sur le marché
II.8.2 Architecture de l’application mobile (front office)

Dans cette partie nous allons décrire le fonctionnement de notre application mobile
« BTAPP ». Via internet notre application est connecter à un serveur de base de
données distant afin de pouvoir enregistrer les données concernant les réclamations en
utilisant des requêtes SQL, d’où on intègre un service web entre l’application
utilisateur et le serveur de base de données. On intègre aussi une base de données
24
Figure 12: Architecture générale de l’application mobile
25
II.8.3 Architecture de la page web (Back office)
Page Web: Il s’agit d’un récepteur de données provenant de la base de données en

utilisant des requêtes SQL.
Serveur de la base de données : Permet la lecture des données depuis une page web.
26
II.9 Environnement technique du travail
Tableau 2: Description de la machine de développement
Machine
Propriétaire Achouri Khaled
Processeur Intel® Core™ i5-4200 CPU @ 1.60 GHz 2.30GHz
RAM 6.00 GO
Disque dur 750 GO
Système d’exploitation Windows 10 64bits x64
Logiciels installés Android Studio
WampServer
StarUML
Balsamiq Mockups 3
Visual Studio Code
Postman
CS PHOTOSHOP 6.0
II.9.1 Outils de développement
27
 Visual Studio Code
II.9.2 Languages de modélisation
II.9.3 Langages de conception
28
II.9.4 Langages de développement
 JAVA
 PHP
 JSON
 REST
29
II.10 Diagramme de Classe Global
Avant d’entamer dans nos deux derniers chapitres nous allons utiliser un diagramme de
classe pour essayer d’avoir une meilleure idée sur le scénario générale de notre projet.
Figure 13:Diagramme de classe global
30
II.11 Conclusion
31
CHAPITRE III Release 1
Chapitre III. Release 1 Front office
III.1 Introduction
III.2 Organisation des sprints
Sprint 1:
Authentification des
Agents
Sprint 2:
Création et traitement
des réclamations
Figure 14:Release 1
32
III.3 Sprint 1 : Authentification des agents
III.3.1 Planification du Sprint

Une fois le but de notre sprint est fixé nous allons commencer à traiter le Backlog du sprint.
Tableau 3:Backlog du sprint 1
III.3.2 Diagramme de cas d’utilisation
Figure 15:Diagramme de cas d'utilisation globale du sprint 1
III.3.3 Description textuelle
33
Tableau 4: Description textuelle des cas d'utilisation du sprint 1
III.3.4 Diagramme de séquence « Inscription »
Figure 16: Diagramme de séquence "Inscription"
34
III.3.5 Test « Inscription »
Figure 17: Interface d'inscription
III.3.6 Diagramme de séquence Authentification
Figure 18: Diagramme de séquence "Authentification des agents"
35
III.3.7 Test Authentification
Figure 19:Interface d'authentification
III.4 Sprint 2 : Création et traitement des réclamations

III.4.1 Planification du sprint
Tableau 5: Backlog du sprint
36
III.4.2 Diagramme de cas d’utilisation
Figure 20: Diagramme de cas d'utilisation du sprint 2
III.4.3 Description textuelle

Tableau 6: Description textuelle des cas d'utilisation du sprint 2
Cas d’utilisation Saisir une réclamation Consulter historique

Acteur Agent de la BT. Agent de la BT.
Pré condition L’agent doit avoir L’agent doit déjà avoir

l’application installé sur soumis une réclamation au
son appareil mobile, et moins.
doit avoir un compte.
Post condition L’agent attend le L’agent aura une liste qui
traitement de sa décrit son historique de
réclamation après l’avoir réclamations par détail.
soumise.
Description du scénario L’agent choisit la L’agent clic sur le bouton
principale provenance de la historique une liste de ses
réclamation, ensuite il réclamations sera affichée
choisit un mot clé qui peut montrant l’état de chacune
décrire sa situation, il de ses derniers (en attente,
choisit ensuite le en cours, valide…).
département concernant L’agent peut ensuite
son incident, ensuite il imprimer une réclamation
ajoute une photo (depuis pour en garder une copie
sa caméra ou depuis sa sur papier.
bibliothèque), il ajoute
37
ensuite ses coordonnées

GPS grâce à un bouton,
Enfin il soumet sa
réclamation.
Exception Si l’un des champs est Si l’agent n’a pas saisie
invalide on affiche un aucune réclamation au
message d’erreur. paravent il sera redirigé
Si la même réclamation est vers la page d’accueil et
soumise plusieurs fois par un message
la même personne, elle d’avertissement sera
risque d’être effacer. afficher.
III.4.4 Diagramme de séquence de « saisie de la réclamation »
Figure 21: Diagramme de séquence saisie de la réclamation
38
III.4.5 Test
Figure 22: Interface de la page Saisie d'une réclamation
III.4.6 Diagramme de séquence de « Consulter historique »
Figure 23: Diagramme de séquence "Consulter historique"
39
III.5 Conclusion
40
CHAPITRE IV Release 2
Chapitre IV. Release 2 Back Office
IV.1 Introduction
IV.2 Organisation des sprints
Sprint 3:
Gestion des réclamations et
des comptes des agents par
l'administrateur.
Sprint 4:
Gestion des réclamations
par le responsable.
Figure 24: Release 2
41
IV.3 Sprint 3 : Gestion des réclamations et des comptes des agents

par l’administrateur
IV.3.1 Planification du sprint

Tableau 7: Backlog du sprint 3
42
IV.3.2 Diagramme de cas d’utilisation
Figure 25:Cas d'utilisation globale du sprint 3
IV.3.3 Description textuelle
Tableau 8: Description textuelles des cas d'utilisation du sprint 3
Cas d’utilisation Authentification Gérer les comptes des Gérer les réclamations
agents
Acteur Administrateur Administrateur Administrateur
Précondition L’administrateur L’administrateur doit L’administrateur doit être
doit avoir un être connecté au site connecté au site
accès au site
Post condition L’administrateur L’administrateur peut L’administrateur peut
a un contrôle apporter des apporter des changements
total sur la base changements sur la sur la table client.
de données table client.
Description du L’administrateur L’administrateur clic L’administrateur clic sur le
scénario clic sur le sur le bouton « Gérer bouton « gérer
principale bouton les comptes des réclamations » une liste de
administrateur agents». réclamations sera affichée.
43
puis se connecte Une liste des agents Si l’état de la réclamation

en utilisant son sera affichée, est
identifiant et mot l’administrateur peut ‘Null’ alors il l’envoie au
de passe, ensuite ensuite choisir département concerné,
l’administrateur d’activer, de L’état de cette réclamation
clic sur le supprimer, de crée un change de ‘Null’ à ‘En
bouton « se compte attente’, d’une façon
connecter ». automatique le responsable
de département concerné
reçoit une notification
indiquant la réception d’une
nouvelle réclamation.
Si l’état de la réclamation
est ‘Valide’ alors
l’administrateur doit écrire
un commentaire sur cette
réclamation qui va être
envoyé à l’agent qui l’a
traité d’une façon
automatique pour le notifier
du changement d’état de sa
réclamation.
L’administrateur peut aussi
annuler une réclamation
(cas de fausse alerte ou
redondance de réclamation)
il changea l’état de la
réclamation à ‘Annuler’ cela
notifiera le responsable du
département concerné.
44
IV.3.3.1 Diagramme de séquence de « Authentification d’administrateur »
Figure 26: Diagramme de séquence "Authentification de l'administrateur"
IV.3.4 Test « Authentification d’administrateur »
Figure 27: Interface d'identification de l'administrateur
45
IV.3.5 Diagramme de séquence « Gestion des comptes des agents »
Figure 28: Diagramme de séquence "Gestion des comptes des agents"
46
IV.3.6 Test « Gestion des comptes des agents »
Figure 29: Interface de gestion des comptes
IV.3.7 Diagramme de séquence « Gestion des réclamations »
Figure 30: Diagramme de séquence "Gestion des réclamations"
47
IV.3.8 Test « Gestion des réclamations »
Figure 31: Interface de gestion des réclamations
IV.4 Sprint 4 : Traitement des réclamations par le responsable

IV.4.1 Planification du sprint
Tableau 9: Backlog du sprint 4
Nom Description Priorité

Authentification En tant que responsable je peux m’identifier afin de 1
traiter une réclamation.
Traitement des réclamations - En tant que responsable je suis capable de voir
tous les réclamations traiter par mon
département.
- En tant que responsable je suis capable de
changer l’état d’une réclamation selon la
situation actuelle du traitement de l’incident :
 En attente = en instance de prise en charge. 2
 En cours = en cours de traitement.
 Report = prise en charge reportée
(indisponibilité momentanée de ressources
matérielles ou humaines).
 Résolu = incident résolu.
48
IV.4.2 Diagramme de cas d’utilisation
Figure 32: Diagramme de cas d'utilisation globale du sprint 4
IV.4.3 Diagramme de séquence « Authentification du responsable »
Figure 33: Diagramme de séquence "Authentification du responsable"
49
IV.4.4 Test « Authentification du responsable »
Figure 34: Interface d'identification du responsable
IV.4.5 Diagramme de séquence « traitement des réclamations »
Figure 35: Diagramme de séquence de "traitement des réclamations"
50
IV.4.6 Test « Traitement des réclamations »
Figure 36: Interface de traitement de réclamation
IV.5 Conclusion
51
Conclusions et perspectives
L’expérience a montré qu’au sein des entreprises en général, et le secteur bancaire en particulier
les incidents qui surviennent au quotidien sont de plus en plus trainés, délaissés et voir même
cumulés en désarroi ; tout cela est faute de lucidité de l’information d’une part, de la lenteur
d’exécution et de traitement de l’incident d’autre part.
En effet la description d’un incident quelconque qu’il soit en genre « hard » ou « soft » n’était
pas une affaire aussi banale qu’on imagine puisque d’après les statistiques recensées, plus que
la moitié des incidents sont mal décelés et décrits et donc étrangement diffusés ce qui entraine
automatiquement un retard à la prise en charge de l’affaire par les parties concernées et
décidément un report quasiment chronique quant à la résolution des problèmes.
Ce phénomène dont souffre le secteur bancaire influe sur la rentabilité de la banque et donne
mauvaise impression de la part des clients.
L’étude qui a été mené sur ce facteur important dans l’administration nous a incités de mettre
en œuvre un objet capable de maitriser au mieux possible la gestion des traitements des
incidents en utilisant les techniques du jour :
 Pour la planification nous avons utilisé la méthode agile Scrum.
 Pour la modélisation nous avons adopté le langage UML.
 Pour le développement de l’application mobile nous avons utilisé le langage de
programmation JAVA sous la plateforme Android Studio.
 Pour la création de la base de données nous avons utilisé MySQL sous la plateforme
WampServer 64.
 Pour la création de la base de données locale SQLite nous avons implémenté un API
sous Android Studio
 Pour la connexion entre l’application mobile et la base de données nous avons utilisé un
web service crée avec le langage PHP.
 Pour les Interfaces de la page web on a fait leurs designs avec Adobe Photoshop.
 Pour le développement de la page web nous avons utilisé le langage PHP.
« BTAPP » est un projet qui s’inscrit dans cette noble vocation et offre les moyens les plus
sophistiqués du web et d’Android afin d’anéantir les retards et les blocages signalé lors d’un
incident quelconque et ce par l’envoi d’une étiquette regroupant texte et photo à la fois pour
exprimer une réclamation et observer une résolution imminente du problème soulevé
52
En Fin, l’utilité du programme en question ajoutée à la puissance inédite du projet en tant qu’un
outil d’accès rapide et efficace, exprime notre volonté de rapprocher le plus possible la banque
aux intentions du client et laisse séduire tous les acteurs quant à la technique créative du futur.
Ceci dit que ce projet peut servir d’autres secteurs et établissement en participant à la rénovation
des procédés administratifs et révolutionner les districts bureautiques archaïques.
53
Bibliographie
54

2544achouri Khaled PFE 2017-2018

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 :

2544achouri Khaled PFE 2017-2018

Titre original :

Transféré par

Droits d'auteur :

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA

Projet de Fin d’Etudes

REALISATION D’UNE APPLICATION ANDROID ET WEB

BANQUE DE TUNIS (BT)

Encadrant(s) universitaire(s) Encadrant(s)

Année universitaire 2017 - 2018

Liste des figures

Liste des tableaux

Le BLADE CENTER, une armada de serveurs rassemblant un support de stockage de grande

Chapitre I. Etude Préalable

I.2 Présentation de l’université

Figure 1: Université Libre de Tunis (ULT)

I.3 Profil de l’entreprise

Figure 2: Banque de Tunisie (BT)

I.3.2 Organigramme de l’entreprise

I.4 Présentation du Projet

I.4.2 Objectifs du projet

I.4.3 L’intérêt de l’application

I.5 Etude de l’existant

I.5.1 Critique de l’existant

I.5.2 Solution proposée

I.6 Travail à faire

Chapitre II. Sprint 0

II.2 Méthode de travail

Figure 3: Les trois contraintes de projet

II.2.2 Méthodologies de développement

II.2.2.1 Le processus unifié

II.2.2.2 Les méthodes agiles

II.2.3 Comparaison entre les méthodes

Table 1: Comparaison entre les méthodes agiles

Description Points Forts Points Faibles

II.2.4 Méthodologie adoptée

II.2.4.1 Présentation de Scrum

Figure 4: La méthodologie agile Scrum

Les artéfacts de Scrum

ajoutées ou retirées à tout moment du carnet de produit. Cette flexibilité offerte au

 Burn Down Chart (Graphic advancement) :

Les membres de l’équipe Scrum

Mêlée quotidienne (Daily Scrum)

II.3 Etude des besoins

II.3.1 Besoins Fonctionnels

o Récupération des données GPS par l’agent.

II.3.1.2 Soumettre une réclamation

Figure 5: Mockup de la page de connexion Figure 6: Mockup de la page d'inscription

Figure 7: Mockup de la page de réclamation

II.3.1.3 Consulter l’historique

Figure 8: Mockup de la page historique

Partie back office

On peut aussi se connecter au site en tant que responsable de département, ce dernier a

II.3.1.5 Gestion des comptes des agents

II.3.1.6 Consulter l’historique des réclamations

par tous les agents et qui appartiennent à tous les départements.

II.3.1.7 Dispatching des réclamations

II.3.1.8 Traitement des réclamations

II.3.2 Les besoins non fonctionnels

II.3.2.1 Ergonomie et bonne interface (IHM) :

II.3.2.2 Compatibilité et portabilité :

II.3.2.3 Robustesse et sécurité :

II.4 Définition des acteurs

II.4.2 Description des acteurs

II.5 Backlog du produit

Tableau 1: Backlog du Produit

II.6 Planification des releases

Sprint 3: Gestion des

Sprint 2: Création et Sprint 4: Traitement des