Rapport dernier tirage.pdf

Application web et mobile de

Mobile Banking

Attijari Bank

Elaboré par

Yasmine TORKHANI Cyrine TAHARI

Filière

Licence Fondamentale en Informatique de Gestion

Encadré par

Encadrant pédagogique Encadrants professionnels

M. Mohamed Hedi AMLOUK

M. Hosni Kricha

Année Universitaire

2014 – 2015

Ministère de l’Enseignement Supérieur Et de la Recherche Scientifique

Université de Tunis Institut Supérieur de Gestion

Mme. Nadia YACOUBI

Dédicaces

Je dédie ce modeste travail et ma profonde gratitude :

À mon père et ma mère

Pour l’amour, l’affection et la bienveillance dont ils m’entouraient ;

pour les efforts et les sacrifices qu’ils ont dû faire.

Pour leurs patiences et leurs encouragements...

"Je vous dois ce que je suis aujourd’hui et ce que je serai demain et je

ferai toujours de mon mieux pour rester votre fierté et ne jamais vous

décevoir.."

Qu’ils trouvent dans ce travail un humble témoignage de ma gratitude

et de ma reconnaissance.

À ma grande famille qui a cru en moi, à mes cousins et cousines…

À tous mes amis qui m’ont soutenu tout au long de mon parcours

À tous mes professeurs pendant mon parcours de l’école vers

l’université.

À toute personne qui a gravé ma vie par un mot qui m’a orienté vers

le bon chemin…

Cyrine TAHARI

Dédicaces

Je dédie ce modeste travail et ma profonde gratitude :

À mon père et ma mère

Autant de phrases aussi expressives soient-elles ne sauraient montrer

le degré d’amour et d’affection que j’éprouve pour eux.

Merci pour tout l'amour et la confiance et pour votre énorme support

pendant la rédaction de mon projet.

A mon frère Youssef

Pour sa patience, son amour et ses encouragements.

A ma sœur Haifa

Sans ses conseils et son amour je serai perdue

A Nilou

Pour ses encouragements continus et sa confiance énorme en moi.

A tous les membres de ma famille, petits et grands, veuillez trouver

dans ce modeste travail l'expression de mon affectation.

A tous mes amis et mes collègues qui m’ont soutenu.

Yasmine TORKHANI

Remerciements

Nous tenons, tout d’abord, à remercier Dieu le tout puissant et miséricordieux, qui nous a

donné la force et la patience d’accomplir ce modeste travail.

Au terme de notre projet de fin d’études, qu’il nous soit permis d’exprimer nos

sentiments de gratitude aux différentes personnes qui nous ont encadrés et soutenues tout au

long de notre travail rendant ainsi possible l’accomplissement du présent projet.

Nous tenons tout particulièrement à exprimer notre profonde gratitude et respect à

Monsieur Mohamed El Hedi AMLOUK, de nous avoir offert l’opportunité d’effectuer notre

stage au sein d'Attijari Bank.

Notre profonde gratitude s’adresse également à Monsieur Hosni KRICHA qui, en dépit

de ses multiples occupations et sollicitations, nous a été d'une aide judicieuse.

Notre profonde gratitude s’adresse tout particulièrement à Madame Nadia YACOUBI,

qui a accepté de diriger, de lire et d’apporter des correctifs à ce travail sans oublier ses conseils

et suggestions éclairées.

Nos remerciements s’adressent aussi à toutes l'équipe du département informatique

d'Attijari Bank qui nous a accompagné et aidé d’une manière et d’une autre à la réalisation

du présent travail.

Table des matières

Introduction générale ..................................................................................................................................... 1

Chapitre 1 Cadre du projet ............................................................................................................................. 3

1.1. Introduction ....................................................................................................................................... 3

1.2 Présentation de l’organisme d’accueil ............................................................................................. 3

1.3 Analyse de l’existant ......................................................................................................................... 3

1.4 Solutions envisagées .......................................................................................................................... 4

1.5 Travail à faire .................................................................................................................................... 4

1.6 Méthodologie et formalisme adoptés ............................................................................................... 6

1.6.1. Scrum ......................................................................................................................................... 6

1.7 Conclusion ....................................................................................................................................... 10

Chapitre 2 Sprint 0 ....................................................................................................................................... 11

2.1. Introduction ..................................................................................................................................... 11

2.2. Capture des besoins ........................................................................................................................ 11

2.2.1 Identification des acteurs ....................................................................................................... 11

2.2.2 Description des acteurs ........................................................................................................... 12

2.3. Les besoins fonctionnels.................................................................................................................. 12

2.4. Les besoins non fonctionnels .......................................................................................................... 13

2.5. Backlog du produit ......................................................................................................................... 14

2.6. Planification des Releases ............................................................................................................... 22

2.7. Identification de l’équipe Scrum.................................................................................................... 23

2.8. Diagramme de cas d’utilisation initial ........................................................................................... 23

2.9. Technologies et outils de développement ...................................................................................... 24

2.9.1 Présentation du système d’exploitation mobile Android..................................................... 24

2.9.2 Architecture de l’application Front Office ........................................................................... 25

2.9.3 Framework et développement de l’application Back Office ............................................... 26

2.10. Environnement technique du travail ............................................................................................. 28

2.10.1 Outil de conception ................................................................................................................. 29

2.10.2 Outils de développement ........................................................................................................ 29

2.10.3 Langages de programmation ................................................................................................. 30

2.10.4 Langage de modélisation : ...................................................................................................... 31

2.11. Conclusion ....................................................................................................................................... 31

Chapitre 3Développement de l'application Front Office ............................................................................ 32

3.1. Introduction ......................................................................................................................................... 32

3.2. Sprint 1 : Authentification .................................................................................................................. 32

3.2.1 Sprint planning ou planification du sprint .................................................................................. 32

3.2.2 Spécification fonctionnelle ............................................................................................................. 33

3.2.2.1 Diagramme de Cas d'utilisation ............................................................................................ 33

3.2.2.2 Description textuelle ............................................................................................................... 33

3.2.3 Conception ....................................................................................................................................... 34

3.2.4 Test ................................................................................................................................................... 38

3.2.5 Sprint planning ou planification du sprint ................................................................................... 40

3.2.6 Spécification fonctionnelle .............................................................................................................. 41



3.2.7 Conception ....................................................................................................................................... 44

3.2.8 Test ................................................................................................................................................... 52

3.3. Sprint 3: Accès aux services publics ................................................................................................... 54





3.3.3 Conception ....................................................................................................................................... 59

3.3.4 Test ................................................................................................................................................... 68

3.4. Conclusion ....................................................................................................................................... 71

Chapitre 4 Développement de l'application Backoffice .............................................................................. 72

4.1. Introduction ......................................................................................................................................... 72

4.2. Sprint 1 : Administration .................................................................................................................... 72





4.2.3 Conception ....................................................................................................................................... 75

4.3. Sprint 2: Gestion des demandes transactionnelles (Cartes, Chéquiers, Virements)...................... 80





4.3.3 Conception ....................................................................................................................................... 84

4.3.4 Test ................................................................................................................................................... 87

4.4. Sprint 3: Gestion des contacts ............................................................................................................ 88





4.4.3 Conception ....................................................................................................................................... 90

4.4.4 Test ................................................................................................................................................... 94

4.5. Conclusion ....................................................................................................................................... 95

Chapitre 5 Codage et déploiement ............................................................................................................... 96

5.1. Introduction ......................................................................................................................................... 96

5.2. Codage .................................................................................................................................................. 96

5.2.1 Diagramme de composants ............................................................................................................ 96

5.2.1.1 Diagrammes de composants de M1 ....................................................................................... 96

5.2.1.2 Diagrammes de composants de M2 ....................................................................................... 97

5.2.2 Diagramme de classes global de l’application .............................................................................. 98

5.2.3 Schéma de la base de données ........................................................................................................ 99

5.3. Déploiement ........................................................................................................................................ 110

5.3.1 Diagramme de déploiement de M1 .............................................................................................. 110

5.3.2 Diagramme de déploiement de M2 .............................................................................................. 111

5.4. Conclusion .......................................................................................................................................... 111

Conclusion et perspective ........................................................................................................................... 112

Annexe A ..................................................................................................................................................... 113

Neto graphie ................................................................................................................................................ 114

Liste des figures

FIGURE 1 : LE DEROULEMENT D’UNE ITERATION [1] ................................................................................ 8

FIGURE 2 : DEROULEMENT D’UN SPRINT [2] .............................................................................................. 10

FIGURE 3 : HERITAGE ENTRE LES ACTEURS .............................................................................................. 11

FIGURE 4 : SCHEMA DE RELEASES ............................................................................................................... 22

FIGURE 5: DIAGRAMME DE CAS D’UTILISATION GLOBAL DE L’APPLICATION ................................ 23

FIGURE 6 : ETUDE COMPARATIVE DES SYSTEMES D’EXPLOITATION MOBILE SUR LE MARCHE

[3] .................................................................................................................................................................. 24

FIGURE 7:ARCHITECTURE GENERALE DE L’APPLICATION MOBILE [4] .............................................. 25

FIGURE 8: ARCHITECTURE GENERALE D'APPLICATION WEB [5] .......................................................... 26

FIGURE 9: DIAGRAMME DE CAS D’UTILISATION GLOBAL SPRINT 1 ................................................... 33

FIGURE 10 : DIAGRAMME DE CLASSES DU CAS D’UTILISATION «S’AUTHENTIFIER» ..................... 35

FIGURE 11: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «S'AUTHENTIFIER» ................ 36

FIGURE 12 DIAGRAMME DE CLASSES DU CAS D’UTILISATION «MODIFIER MOT DE PASSE». ..... 37

FIGURE 13 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «MODIFIER MOT DE PASSE». 38

FIGURE 14 : INTERFACE PRINCIPALE DE L’APPLICATION MOBILE ...................................................... 39

FIGURE 15: INTERFACE D’AUTHENTIFICATION. ....................................................................................... 39

FIGURE 16: INTERFACE DE MODIFICATION DU MOT DE PASSE ............................................................ 39

FIGURE 17: DIAGRAMME DE CAS D’UTILISATION GLOBAL SPRINT 2 ................................................. 42

FIGURE 18: DIAGRAMME DE CLASSES DU CAS D’UTILISATION «CONSULTER L’EXTRAIT DE

COMPTE» ..................................................................................................................................................... 45

FIGURE 19: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «CONSULTER L’EXTRAIT DU

COMPTE» ..................................................................................................................................................... 46

FIGURE 20: DIAGRAMME DE CLASSE DU CAS D'UTILISATION «DEMANDER UNE CARTE

BANCAIRE»................................................................................................................................................. 47

FIGURE 21: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «DEMANDER UNE CARTE

BANCAIRE»................................................................................................................................................. 48

FIGURE 22: DIAGRAMME DE CLASSES DU CAS D'UTILISATION «OPPOSER UNE CARTE

BANCAIRE»................................................................................................................................................. 49

FIGURE 23: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «OPPOSER UNE CARTE

BANCAIRE»................................................................................................................................................. 50

FIGURE 24: DIAGRAMME DE CLASSES DU CAS D'UTILISATION «CONSULTER LA BOITE DE

RECEPTION» ............................................................................................................................................... 51

FIGURE 25: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «CONSULTER LA BOITE DE

RECEPTION» ............................................................................................................................................... 52

FIGURE 26 : INTERFACE DU MENU PRINCIPAL .......................................................................................... 53

FIGURE 27 : INTERFACE DE CONSULTATION DES COMPTES BANCAIRES .......................................... 53

FIGURE 28 : INTERFACE DE CONSULTATION DE L’EXTRAIT BANCAIRE ............................................ 53

FIGURE 29 INTERFACE DE DEMANDE D’UNE CARTE ............................................................................... 54

FIGURE 30: DIAGRAMME DE CAS D’UTILISATION GLOBAL SPRINT3 .................................................. 57

FIGURE 31: DIAGRAMME DE CLASSES DU CAS D’UTILISATION «SUIVRE LES COURS DE

DEVISE» ....................................................................................................................................................... 60

FIGURE 32: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «SUIVRE LES COURS DE

DEVISE» ....................................................................................................................................................... 60

FIGURE 33: DIAGRAMME DE CLASSES DU CAS D’UTILISATION «CONTACTER LA BANQUE» ..... 61

FIGURE 34: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «CONTACTER LA BANQUE»

PARTIE1 ....................................................................................................................................................... 63

FIGURE 35 : DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «CONTACTER LA BANQUE»

PARTIE2 ....................................................................................................................................................... 64

FIGURE 36: DIAGRAMME DE CLASSES DU CAS D’UTILISATION «CONSULTER LE SYSTEME DE

GEOLOCALISATION» ................................................................................................................................ 65

FIGURE 37: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «CONSULTER LE SYSTEME DE

GEOLOCALISATION » ............................................................................................................................... 66

FIGURE 38 : DIAGRAMME DE CLASSES DU CAS D'UTILISATION «CONSULTER LA LISTER DES

POINTS DE CONTACT». ............................................................................................................................ 67

FIGURE 39: DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «CONSULTER LA LISTER DES

POINTS DE CONTACT» ............................................................................................................................. 68

FIGURE 40 : INTERFACE DU MENU PUBLIC ................................................................................................ 69

FIGURE 41 : INTERFACE DE SUIVI DES COURS DE DEVISE ..................................................................... 69

FIGURE 42: INTERFACE DE CONSULTATION DE LA LISTE DES REGIONS. .......................................... 70

FIGURE 43: INTERFACE DE CONSULTATION DE LA LISTE DES AGENCES. ......................................... 70

FIGURE 44 : INTERFACE D’ENVOI D’UN POUR UN ABONNE ................................................................... 70

FIGURE 45: INTERFACE D’APPEL ................................................................................................................... 70

FIGURE 46 : DIAGRAMME DE CAS D’UTILISATION GLOBAL DU SPRINT 1 ......................................... 74

FIGURE 47 : DIAGRAMME DE CAS D’UTILISATION «GERER LES AGENCES» ..................................... 74

FIGURE 48 : DIAGRAMME DE CLASSES DU CAS D’UTILISATION «GERER LES AGENCES» ............. 76

FIGURE 49 : DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «GERER LES AGENCES» ...... 77

FIGURE 50 : INTERFACE PRINCIPALE DE LA GESTION DES AGENCES ................................................. 78

FIGURE 51 : INTERFACE DE L’OPERATION DE SUPPRESSION D’UNE AGENCE .................................. 78

FIGURE 52 : INTERFACE DE L’OPERATION D’AJOUT D’UNE AGENCE ................................................. 79

FIGURE 53 : INTERFACE DEL’OPERATION DE MODIFICATION DES COORDONNEES D’UNE

AGENCE ....................................................................................................................................................... 79

FIGURE 54 : DIAGRAMME DE CAS D’UTILISATION GLOBALE SPRINT2 ............................................... 82

FIGURE 55 : DIAGRAMME DE CAS D’UTILISATION «GERER LES DEMANDE DE CARTES» ............. 83

FIGURE 56 : DIAGRAMME DE CLASSES DU CAS D’UTILISATION «GERER LES DEMANDES DE

CARTE» ........................................................................................................................................................ 85

FIGURE 57: CAS D'UTILISATION GENERE «GERER LES DEMANDES D'OBTENTION » ...................... 86

FIGURE 58 : INTERFACE DE LA GESTION DES DEMANDES D’OBTENTION ......................................... 87

FIGURE 59 : CONSULTATION DES DEMANDES DE CARTES .................................................................... 87

FIGURE 60 : DIAGRAMME DE CAS D’UTILISATION GLOBAL SPRINT3 ................................................. 89

FIGURE 61 : DIAGRAMME DE CLASSE DU CAS D’UTILISATION «GESTION DES CONTACTS» ........ 91

FIGURE 62 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION «GERER LES MESSAGES» ...... 93

FIGURE 63 : INTERFACE DE LA GESTION DE LA LISTE DES RENDEZ-VOUS ....................................... 94

FIGURE 64 : INTERFACE DE LA GESTION DES RENDEZ-VOUS .............................................................. 94

FIGURE 65 : DIGRAMME DE COMPOSANTS DU MODULE M1 ................................................................. 97

FIGURE 66 : DIAGRAMME DE COMPOSANTS DU MODULE M2 ............................................................... 97

FIGURE 67 : DIAGRAMME DE CLASSE GLOBAL DE L’APPLICATION .................................................... 98

FIGURE 68 : DIAGRAMME DE DEPLOIEMENT DE M1 .............................................................................. 111

FIGURE 69 : DIAGRAMME DE DEPLOIEMENT DE M2 .............................................................................. 111

Liste des tableaux

TABLEAU 1 : DESCRIPTION DETAILLEE DES ACTEURS ........................................................................... 12

TABLEAU 2: PRODUCT BACKLOG ................................................................................................................. 16

TABLEAU 3: IDENTIFICATION DE L’EQUIPE SCRUM ................................................................................ 23

TABLEAU 4: DESCRIPTION DES MACHINES DE DEVELOPPEMENT ...................................................... 28

TABLEAU 5: SPRINT 1 BACKLOG ................................................................................................................... 33

TABLEAU 6: DESCRIPTION TEXTUELLE DE CAS D’UTILISATION «S’AUTHENTIFIER» .................... 34

TABLEAU 7 :SPRINT2 BACKLOG .................................................................................................................... 40

TABLEAU 8 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «CONSULTER L’EXTRAIT DU

COMPTE» ..................................................................................................................................................... 42

TABLEAU 9: DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «DEMANDER UNE CARTE

BANCAIRE»................................................................................................................................................. 43

TABLEAU 10: DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «CONSULTER LA BOITE

RECEPTION» ............................................................................................................................................... 44

TABLEAU 11 : SPRINT3 BACKLOG ................................................................................................................. 55

TABLEAU 12 : DESCRIPTION DU CAS D’UTILISATION «ACCEDER AUX SERVICES PUBLIC

D’ATTIJARI BANK» ................................................................................................................................... 57

TABLEAU 13: DESCRIPTION DU CAS D’UTILISATION «CONTACTER LA BANQUE» .......................... 58


TABLEAU 15 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «GERER LES AGENCES» ........ 75


TABLEAU 17 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «GERER LES DEMANDE

D'OBTENTION»........................................................................................................................................... 83


TABLEAU 19 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «GERER LES DEMANDES DE

RENDEZ-VOUS» ......................................................................................................................................... 90

TABLEAU 20 : DESCRIPTION TEXTUELLE DU CAS D'UTILISATION «GERER LES MESSAGES» ...... 90

TABLEAU 21 TABLE « ABONNE » .................................................................................................................. 99

TABLEAU 22 : TABLE « REGION » .................................................................................................................. 99

TABLEAU 23: TABLE « CLIENT » .................................................................................................................. 100

TABLEAU 24 : TABLE « COMPTE » ............................................................................................................... 100

TABLEAU 25 : TABLE « AGENT » ................................................................................................................. 101

TABLEAU 26 : TABLE «PARAMETRE» ......................................................................................................... 101

TABLEAU 27 : TABLE «AGENCE» ................................................................................................................. 102

TABLEAU 28 : TABLE «DAB»" ....................................................................................................................... 102

TABLEAU 29 : TABLE «DDE_CARTE» .......................................................................................................... 103

TABLEAU 30 : TABLE «MOUVEMENT» ....................................................................................................... 103

TABLEAU 31 : TABLE «DDE_CHEQ» ............................................................................................................ 104

TABLEAU 32 : TABLE « DE_OP_CARTE» .................................................................................................... 104

TABLEAU 33 : TABLE «DDE_OP_CHEQ» ..................................................................................................... 105

TABLEAU 34 : TABLE «CHEQUIER» ............................................................................................................. 105

TABLEAU 35 : TABLE «DDE_VIR» ................................................................................................................ 106

TABLEAU 36 TABLE «MESSAGE» ................................................................................................................ 107

TABLEAU 37 : TABLE «CHEQUE» ................................................................................................................. 108

TABLEAU 38 : TABLE «TYPCARTE» ............................................................................................................ 108

TABLEAU 39 : TABLE «RENDEZVOUS» ...................................................................................................... 109

TABLEAU 40 : TABLE «CARTE» .................................................................................................................... 110

1

Introduction générale

Le marché des téléphones intelligents ou « Smartphone » est un marché en plein essor avec plus

d’un milliard de téléphones vendu dans le monde en 2014.

Ces téléphones mobiles dotés d’une intelligence équivalente à celle d’un ordinateur ne sont plus

seulement un moyen de communication, mais aussi un outil pour faciliter la vie de tous les

jours. Les utilisateurs ne peuvent plus s’en passer, il y en a même qui les considèrent comme

leurs meilleurs amis, car ils représentent pour eux une source d’information de tout ce qui se

passe autour d’eux, un moyen de divertissement, mais aussi un outil de travail.

Afin d'élargir les canaux de communication avec les clients, les banques n'ont pas fait figure

d'exception à cette émergence et ont investi dans le domaine de Smartphone en inventant le

concept de Mobile Banking.

En effet, le mobile Banking signifie l'ensemble des services bancaires tels que la consultation

de soldes, des extraits bancaires, les demandes d'opposition ou d'obtention sur cartes ou sur

chéquiers ... qui sont accessibles par un terminal mobile.

Dans ce contexte, notre projet de fin d’études a pour but de concevoir et développer une

application de mobile banking comprenant deux parties:

Une application mobile pour les utilisateurs de M-banking qui constitue le front office.

Une application web pour l'administration, dédiés aux employés de la banque qui

constitue le Back office.

Notre travail s’intitulant « Conception et développement d’une application web et mobile de

Mobile Banking » est composé de cinq chapitres :

Dans le premier chapitre, nous présenterons le cadre de notre projet.

Le deuxième chapitre présentera notre sprint 0 ou encore la phase de préparation où nous

détaillerons les technologies que nous allons manipulé tout au long de notre projet.

Le troisième chapitre portera sur le les étapes de développement du front office et le quatrième

chapitre sur les étapes de développement du back office.

2

Et notre dernier chapitre, sera dédié à la partie déploiement et codage de notre application où

nous allons détaillé l'architecture des deux applications et le schéma de la base de données.

Nous finirons par une conclusion générale ainsi que la proposition de quelques perspectives.

3

Chapitre 1 Cadre du projet

1. Introduction

Pour la gestion des opérations financières, l’échange d'information avec la banque, le téléphone

mobile (ou la tablette utilisée en mobilité comme un Smartphone) est un média plus pratique,

plus immédiat et plus simple. Nous vivons à une époque où la technologie mobile est

omniprésente. Le téléphone mobile occupe une place centrale dans cette évolution

technologique rendant possible l’accès aux réseaux n’importe où et n’importe quand.

Ainsi, étant donnée le nombre croissant de téléphones portables en usage, il est intéressant d’en

faire un canal principal pour matérialiser ce qui constitue l’ossature d’une relation fidèle à sa

banque : gérer ses comptes, accéder aux services bancaires essentiels où, quand et comme l’on

veut.

2 Présentation de l’organisme d’accueil

Attijari Bank Tunisie est une banque tunisienne détenant le réseau d’agences le plus important

en Tunisie et classée troisième banque privée en terme de dépôt et d’engagement. Elle est

fortement présente sur l’ensemble des segments de marchés particuliers, professionnels et

entreprises. En vue de se positionner sur le marché tunisien en tant qu’acteur de référence,

Attijari Bank a conçu un plan de développement stratégique visant la réalisation d’objectifs

ambitieux à l'horizon 2015.

A travers la mise en place de son projet de développement, elle a contribué d’une façon active

à la performance du système bancaire tunisien et à la croissance du pays notamment grâce à

l’appui de ses partenaires. Outre son implication dans le développement économique du pays,

son projet s’inscrit dans une logique de coopération économique entre les pays du Maghreb.

3 Analyse de l’existant

L’analyse de l’existant consiste à présenter les services diversifiés d’Attijari Bank tel que, la

consultation de solde, la prise de rendez-vous, le suivi de la bourse .... En effet, ces services

offerts par Attijari Bank peuvent se faire de deux manières à savoir : Le mode classique et le

mode à distance.

Pour le premier mode, Attijari Bank met à la disposition de ses clients des agences pour servir

leurs besoins. Les guichets de l’agence émettrice proposent des services qui conviennent aux

besoins de ces clients.

4

Concernant le second mode, Attijari Bank met à la disposition de ses clients un service de

consultation et virement bancaire via internet. En effet, le client doit passer par le site web

d’Attijari Bank1 et choisir le service désiré ayant des paramètres d’authentification fournis

préalablement par son agence. Dans le but d’interagir d’avantage avec les clients et d’en attirer

des nouveaux, Attijari Bank décide de développer des services bancaires pour mobile.

4 Solutions envisagées

Depuis le milieu des années 2000, les plus grandes banques mondiales commencent à investir

dans le Mobile Banking appelé aussi M-Banking. Rappelons que le «M-Banking désigne une

spécificité du Mobile Business adaptée au métier de la Banque. Il s’agit du traitement des

services bancaires à travers le mobile» [1]

Attijari Bank nous 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 notre projet de fin d’études.Il s’agit en fait

d’une application Android M-Banking permettant à sa clientèle de bénéficier des services

bancaires qu’elle offre sur un terminal mobile (Smartphone, tablette..) d’où vient le concept de

l'informatique ubiquitaire.

«Les systèmes dits ubiquitaires supportent la mobilité de l'utilisateur. Le principal intérêt de ces

systèmes est de s’adapter à l'environnement de l'homme (géo localisation, disponibilité des

réseaux de communication, identification de l'utilisateur ...). En d'autre termes, c'est le système

qui s'adapte à l'Homme, et pour y arriver le système se doit d'être présent partout et en temps

réel.» [2] D'où le nom du guichet virtuel dans le secteur bancaire permettant d’assurer ces trois

principes :

Any Time : continuité de service, au besoin du client.

Any Where : à la maison, au travail, à l'extérieur, en Tunisie, à l'étranger.

Any Acces : multi canaux.

5 Travail à faire

Le travail à faire est de concevoir et développer une application de M-Banking que nous avons

nommée «Attijari Mobile Banking». Il s’agit d’une application divisée en deux modules : un

premier dédié au Front Office et un second pour le Back Office.

1 Site Officiel : http://www.attijaribank.com.tn/Fr/

http://www.attijaribank.com.tn/Fr/

5

M1 : Front Office

Une application Android qui sera installée sur un terminal mobile développé en langage de

programmation JAVA dédiée à la fois aux clients d’Attijari Bank et aux clients potentiels. En

effet, l’application mobile permet aux clients d'Attijari Bank de:

Accéder à des relevés bancaires électroniques

Demander et/ou opposer un chéquier.

Demander et/ou opposer une carte bancaire.

Effectuer des virements simples intra-bancaires.

Consulter la boite de notifications.

En plus, notre application s'adresse aux clients des autres banques qui seront traités comme des

clients potentiels. On leur offre un ensemble de fonctionnalités qui pourront servir dans leur vie

quotidienne mais aussi bien pour les tenir au courant des actualités de la banque et leur aider à

trouver des agences ou des DAB d'Attijari Bank en cas de besoin. Nos solutions permettent à

tous les utilisateurs de l'application de :

Trouver et lister les agences et les DAB.

Suivre les actualités de la banque.

Suivre le marché de la bourse.

Suivre les cours des devises.

Simuler des crédits et des placements.

Contacter la banque soit par message, par téléphone ou en demandant un rendez-vous

auprès de notre service clientèle.

M2 : Back Office

Pour cela, nous avons prévu une plateforme web J2EE pour l’administration de l’application

mobile. En effet, le Back Office désigne l'ensemble des parties du système

d’information auxquelles l'utilisateur final n'a pas accès. C'est la partie, que les employés

d'Attijari Bank doivent assurer le bon fonctionnement de l'application mobile.

La mise à jour de la base de données et de l'application mobile, l'approbation des demandes

clients, le contrôle d'identité et la communication avec les clients, sont les principales

fonctionnalités de cette application web.

6

6 Méthodologie et formalisme adoptés

Dans le cadre de ce projet, nous nous sommes intéressées à l’adoption d’une approche Agile.

«Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit

collaboratif, avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout

en prenant en compte l’évolution des besoins des clients.» [3]

Ce sont des méthodologies essentiellement dédiées à la gestion de projets informatiques. Elles

reposent sur des cycles de développement itératifs et adaptatifs en fonction des besoins évolutifs

du client. Elles permettent notamment d'impliquer l'ensemble des collaborateurs ainsi que le

client dans le développement du projet.

Ces méthodes permettent généralement de mieux répondre aux attentes du client en un temps

limité (en partie grâce à son implication) tout en faisant monter les collaborateurs en

compétences.

On citera comme méthodes de développement Agile :

• Scrum

• Extreme Programming

• Adaptive Software Development (ASD)

• Dynamic System Development Method (DSDM)

Nous nous sommes intéressées à la méthode Scrum.

6.1. Scrum

« La méthode SCRUM définit un cadre de travail permettant la réalisation de projets complexes.

Initialement prévu pour le développement de projets type « Software », cette méthode peut être

appliquée à tout type de projet, du plus simple au plus innovant, et ce de manière très

simple.»[4] Cette méthodologie permet de s’adapter rapidement aux changements d’un client à

fréquence régulière. Chaque fin d'itération, l'équipe et le client réévaluent les spécifications du

logiciel.

Pourquoi Scrum ?

Avant, le client ne voyait pas l’évolution du travail et n’était pratiquement pas impliqué pendant

l’exécution de son projet. En effet il ne pouvait pas commencer à faire des tests avant que tout

soit presque fini. Par contre en Scrum, le client est plus impliqué dans le processus car un projet

contient plusieurs livrables qu'il doit approuver. A chaque livrable les fonctionnalités sont en

7

amélioration continue et le client voit régulièrement l'évolution des travaux et si quelque chose

ne lui convient pas, il est plus facile de l'ajuster pour satisfaire ses besoins. Donc Scrum vise

essentiellement à optimiser la prévisibilité d'un projet et à mieux contrôler les risques.

Les intervenants dans Scrum

La méthode Scrum définit trois rôles pour un projet:

o Le Product Owner

Il s'agit du représentant officiel du client au sein d'un projet Scrum. Il définit les besoins

du produit et rédige les spécifications. Il est également chargé de définir et prioriser les

users stories pour chaque sprint.

o Le Scrum Master

Il s'agit d'une personne chargée de veiller à la mise en application de la méthode et au

respect de ses objectifs. Il ne s'agit pas d'un chef de projet, mais d'une personne chargée

de lever les obstacles éventuels qui empêcherait l'avancement de l'équipe et du projet

pendant les différents sprints.

o Team Members

Ce sont les personnes chargées de la réalisation du sprint et d'un produit utilisable en fin

de sprint. Il peut s'agir de développeurs, architectes, personnes chargées de faire des tests

fonctionnels…

Sprint

Scrum s'appuie sur le découpage des projets en itérations encore nommées «Sprints».Un Sprint

est une période durant laquelle une fonctionnalité (ou incrément du projet) est réalisée.

Il peut avoir une durée qui varie généralement entre deux semaines et un mois. Cette courte

durée permet de livrer rapidement au propriétaire du produit un incrément de logiciel

comportant le plus de valeur d’affaire. Le logiciel livré a de la valeur pour le propriétaire du

produit puisque les fonctionnalités développées sont celles qui ont la plus haute priorité, celles

se trouvant en tête du carnet de produit. Un autre avantage de la courte durée des itérations est

de permettre au propriétaire du produit de modifier les priorités des fonctionnalités demandées

au fur et à mesure de l’avancement du projet de développement. En effet, s'il désire ajouter des

fonctionnalités, celles-ci seront potentiellement prises en compte lors de la prochaine itération.

À la fin de chaque sprint, les membres de l’équipe obtiennent un produit partiel potentiellement

livrable et le feedback récolté permet d’ajuster le backlog pour le sprint suivant.En soi, Scrum

8

ne suggère que trois jalons2: la planification d'itération (sprint planning), la mêlée quotidienne

(daily Scrum) et la revue d'itération (sprint review). Durant ces derniers, il y a production de

trois artéfacts « de gestion » : le carnet de produit priorisé (product backlog), le carnet

d'itération.

La figure 1 schématise le cycle de vie d’un projet Scrum

Figure 1 : Le déroulement d’une itération [1]

Les artéfacts de Scrum

o Product Backlog (Carnet de produits)

Scrum débute avec un produit backlog, qui est une liste des requis priorisés partagé et

détenu par le Product Owner, «User Stories» ou «Uses Cases».Le propriétaire du produit

est responsable de prioriser les fonctionnalités. Ces derniers servent à articuler et à finaliser

ce que le client désire obtenir. Des nouvelles fonctionnalités peuvent être 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.

o Sprint Backlog (Carnet d'itération)

A chaque sprint, on choisit une partie des fonctionnalités du backlog de produit pour les

réaliser.

2Un jalon (ou, en anglais milestone), dans le cadre de la gestion de projet, est la fin d'une étape, la fin d'un

travail.

9

La réalisation de ces fonctionnalités doit permettre d'atteindre un objectif de sprint défini

au début de celui-ci. Chaque fonctionnalité est alors découpée en tâches qui pourront

être réalisées par différents membres de l'équipe.

o Burn Down Chart (Graphique d’avancement)

Le graphique d'avancement d'itération permet aux équipes de voir leur avancement par

rapport au travail engagé dans l'itération en cours. L’axe vertical présente la quantité de

travail à faire et l’axe horizontal les jours de travail.

Les activités d'un sprint

o Planification d'itération «Sprint Planning»

Lors de cette réunion, l’équipe discute des objectifs du sprint et décide de ce qui sera

accompli pendant cette période. À la fin de la réunion, l’équipe s’engage à livrer une ou

plusieurs fonctionnalités.

o Mêlée quotidienne «Daily Scrum Meeting»

La mêlée quotidienne est une rencontre de courte durée où l'équipe fait un compte rendu de

son avancement vers l’atteinte de l’objectif de l’itération. Chaque membre de l'équipe

répond à trois questions :

• Qu'as-tu accompli depuis la dernière mêlée?

• Que vas-tu accomplir jusqu'à la prochaine mêlée?

• Est-ce que des éléments te bloquent dans ton avancement?

Et si on doit obtenir des informations de la part du client, c’est le product owner qui doit

s’assurer de le contacter pour obtenir les réponses.

o Revue d'itération «Sprint Review»

La revue d'itération se fait à la fin du cycle de développement de l'itération et permet au

propriétaire du produit de prendre connaissance des fonctionnalités qui ont été développées

durant l'itération. À la revue d'itération, le propriétaire évalue si le produit qui lui est

présenté correspond bien à l’engagement de livraison pris par l’équipe lors de la séance de

planification de l’itération. Après la revue d'itération, une nouvelle itération débute et

relance ainsi le cycle de planification, développement et revue.

La figure 2 explique le déroulement d'un Sprint

10

Figure 2 : Déroulement d’un sprint [2]

7 Conclusion

Dans ce premier chapitre, nous avons commencé par présenter notre organisme d'accueil

Attijari Bank. Ensuite, nous avons décrit le contexte du projet et la solution proposée qui

constituera le sujet de notre projet. Enfin, après avoir choisi Scrum comme méthodologie de

gestion de projet, nous nous dirigerons naturellement vers le Sprint 0.

11

Chapitre 2 Sprint 0

1. Introduction

Le principe de base de Scrum est de se focaliser de façon itérative sur un ensemble de

fonctionnalités à réaliser dans chaque sprint. Dans ce chapitre, la première phase de Scrum qui

est le Sprint 0 sera présentée. Il s’agit en fait d’une phase de planification et architecture qui ne

se termine pas nécessairement par une livraison. Les travaux réalisés dans cette période

conduits à construire une bonne vision du produit, identifier les rôles des utilisateurs, dégager

les fonctionnalités principales, préparer l’environnement de développement et déterminer un

plan de Release afin de produire le Product Backlog initial ainsi qu'une première planification

des sprints.

2. Capture des besoins

Nous procéderons par l’identification des acteurs puis la description des histoires utilisateurs

de la future application.

2.1 Identification des acteurs

Les deux acteurs principaux de l'application Attijari Mobile Banking sont :

Client d'Attijari Bank

Client potentiel d'Attijari Bank

En tenant compte des fonctionnalités offertes en commun pour les deux acteurs, il existe un

autre plus général «Utilisateur M-Banking» avec lequel ils constituent une relation d’héritage.

La figure 3 illustre la relation d'héritage entre les acteurs:

Figure 3 : Héritage entre les acteurs

12

2.2 Description des acteurs

Le tableau 1 définit les acteurs de l'application Attijari Mobile Banking ainsi que leurs rôles.

3. Les besoins fonctionnels

«Les besoins fonctionnels expriment une action que doit effectuer le système en réponse à une

demande (sorties qui sont produites pour un ensemble donné d’entrées)». [7]

Dans ce qui suit, nous décrivons les besoins fonctionnels de notre application appelés dans

Scrum «User stories»:

Tableau 1 : Description détaillée des acteurs

Acteur Définition Rôle

Client d'Attijari Bank Tout client de la banque possédant le

pack « Mobile Banking » afin de

pouvoir utiliser l'application Attijari

Mobile Banking

-Il s’authentifie afin qu’il puisse

accéder à son espace client où il

bénéficiera d’un ensemble de

fonctionnalités (consultation compte,

demande carte ou chéquier,

virements ...).Il a également l’accès à

un espace public qui regroupe un

ensemble de services (trouver agence

ou distributeur, convertisseur de

devise, bourse..).

Client potentiel d'Attijari

Bank

Toute personne utilisant l'application

M-Banking d’Attijari Bank, qui n'est

pas encore client, et qui pourra le

devenir.

-Il a accès à un espace public de

l’application où il pourra bénéficier

d'un ensemble de fonctionnalités tel

que la recherche d'une agence ou d'un

DAB, le suivi des actualités de la

banque et de la bourse...

Administrateur M-

Banking d'Attijari Bank

Il s’agit de la personne qui possède

toute les permissions sur le

système.

Il est responsable de la gestion des

abonnés M-Banking, la gestion des

agences, des DAB, des régions et des

demandes clients (demandes

d’opposition ou d’obtention de carte

ou de chéquier, demandes de

virements…).

13

S’authentifier : Pour bénéficier des fonctionnalités offertes de l’application, le client

d'Attijari Bank doit s'authentifier en saisissant son code client et son mot de passe.

Accéder aux services public d’Attijari Bank : L’utilisateur M-Banking aura accès à

un espace public où un ensemble de fonctionnalités seront offertes tel que le suivi de la

bourse, des cours de devise, des actualités de la banque (Offre, Evénements, Ouverture

de nouvelles agences...), consultation des simulateurs et recherche des agences et des

DAB.

Accéder aux services clients d’Attijari Bank : C'est un espace dédié seulement aux

clients M-Banking qui leur permet d'effectuer des transactions bancaires tel que la

consultation de l'extrait bancaire, demande et/ou opposition sur un chéquier ou sur une carte

bancaire

Gérer le backoffice de l'application Mobile : L'administrateur de l'application doit

gérer la partie Backoffice. Il aura la possibilité de mettre à jour les données (ajouter une

nouvelle agence, supprimer une agence, actualiser les cours de devise ...), confirmer ou

décliner les demandes clients (demande d'obtention ou opposition sur carte, demande de

rendez-vous ...).

4. Les besoins non fonctionnels

«Il s’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de

performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les

contraintes d’implémentation (langage de programmation, type SGBD.) ». [7]

Les besoins non fonctionnels de notre système, appelés dans Scrum «Technical Stories», se

décrivent comme suit :

Contraintes ergonomiques

o La navigation entre les interfaces de notre future application mobile doit être légère et

fluide.

o Les interfaces de notre future application web doivent être simples et homogènes.

o L’utilisateur M-Banking doit être guidé lors de la saisie de certaines informations, afin

de respecter les formats des champs de notre base de données.

14

Contraintes techniques

o Vu que notre application mobile manipule des données confidentielles, tous les accès

des clients doivent être protégés par un login, un mot de passe et un IMEI3 récupéré

lors de l’ajout d’un nouvel abonné. Ce code permet d’assurer la sécurité en donnant

accès aux abonnées de manipuler l’application uniquement par leurs propres téléphones.

o Toutes les applications web au sein d'Attijari Bank nécessitent une authentification par

certificat qui sera établit en mettant en place le Framework Spring Security.Pour notre

cas, on a dû suivre le protocole interne et intégrer ce Framework d’authentification et

de contrôle d’accès.

o Les mots de passes des abonnés doivent êtres cryptés au niveau de la base de données

afin de garder sécurisé l’accès à l’application «Attijari Mobile Banking».

o Les requêtes doivent être optimisées afin d’assurer un temps de réponse minimal.

5. Backlog du produit

Le Backlog produit est utilisé pour planifier la release et aussi à chaque sprint, lors de la réunion

de planification du sprint pour décider du sous-ensemble qui sera réalisé. Ses éléments sont

classés par ordre de priorité ce qui permet de définir l’ordre de réalisation.

Pour chaque user story on identifie le rang, l’estimation, l'importance et la description.

Rang: Pour les user stories ayant la même priorité, un rang est assigné pour indiquer l'ordre

dans lequel l'équipe doit les implémenter.

Estimation: Sert à estimer l’effort nécessaire à une équipe pour implémenter une

fonctionnalité. Elle prend en compte l’effort pour le développement.

Importance :C'est un nombre qu'attribue le product owner à l'histoire : plus l'importance est

grande, plus l'histoire devra être traitée en priorité.

Priorité: Le product Owner classe les user story par ordre de priorité dans le Backlog produit

en travaillant avec le client pour savoir ce qui est important pour lui.

3International Mobile Equipment Identity, numéro qui permet d'identifier de manière unique chacun des

terminaux de téléphonie mobile.

http://fr.wikipedia.org/wiki/International_Mobile_Equipment_Identity

15

Description : Elle permet de décrire les user stories. Généralement, pour rendre ce nom

explicite, une bonne façon de procéder est d'utiliser le Template suivant : «En tant que X, je

veuxY,afinde...».

Le tableau 2 décrit le product backlog de notre apllication.

16

Tableau 2: Product Backlog

Id Nom Rang Estimation Priorité Description

1 S'authentifier 1 2 20 En tant que client d'Attijari Bank, je veux

m'authentifier afin de bénéficier des

fonctionnalités de l'application.

2 Modifier mot de passe 2 2 20 En tant que client d'Attijari Bank, je veux changer

mon mot de passe afin de mieux maitriser mes

paramètres de connexion.

3 Consulter la boite de réception. 3 2 20 En tant que client d'Attijari Bank, je veux

consulter ma boite de réception afin de voir si mes

demandes sont confirmées ou déclinées.

4 Demander une carte bancaire 4 3 20 En tant que client d'Attijari Bank, je veux

demander une nouvelle carte afin de faciliter mes

transactions quotidiennes.

6 Demander un chéquier 6 3 20 En tant que client d'Attijari Bank, je veux

demander un nouveau chéquier afin de faciliter

mes transactions quotidiennes.

7 Opposer un chéquier 7 3 20 En tant que client d'Attijari Bank, je veux opposer

mon chéquier en cas de perte ou de vol afin de

bloquer son utilisation.

8 Demander des virements simples

intra-bancaires

8 7 20 En tant que client d'Attijari Bank, je veux

transférer de l’argent entre mes comptes

domiciliés au sein d’Attijari Bank..

9 Consulter l’extrait du compte 9 5 20 En tant que client d'Attijari Bank, je veux

consulter mon extrait de compte afin de voir mes

dix dernières transactions effectuées sur ce

compte.

10 Suivre les actualités de la banque

10 2 20 En tant qu’utilisateur M-Banking, je veux suivre

les actualités d’Attijari Bank afin d'être au

courant de ses nouveautés.

11 Suivre les cours de devise 11 2 20 En tant qu’utilisateur M-Banking, je veux suivre

les cours de devise afin d’être au courant des

changements de devise.

17

12 Suivre le marché de la bourse 12 2 20 En tant qu’utilisateur M-Banking, je veux suivre

le marché de la bourse afin d'être au courant des

changements.

13 Prendre un rendez-vous 13 2 20 En tant qu’utilisateur M-Banking je veux prendre

un rendez-vous afin de planifier une rencontre

avec le chargé clientèle de mon agence

14 Envoyer un message 14 2 20 En tant qu’utilisateur M-Banking je veux envoyer

un message la banque afin de communiquer mes

réclamations et mes suggestions.

15 Appeler la banque 15 1 20 En tant qu’utilisateur M-Banking je veux appeler

la banque afin d’entrer en contact immédiat avec

le centre de relation client.

16 Consulter le système de géo

localisation des agences

16 9 20 En tant qu’utilisateur M-Banking, je veux

consulter le système de géo localisation afin de

visualiser sur la carte les agences d’Attijari Bank

sur le territoire tunisien.

17 Consulter le système de géo

localisation des D AB


consulter le système de géo localisation afin de

visualiser sur la carteles DAB d’Attijari Bank sur

le territoire tunisien.

18 Consulter la liste des points de

contacts des agences


consulter la liste des DAB afin d'avoir une idée

sur leurs adresses.

18

19 Consulter la liste des points de

contacts des DAB


consulter la liste des agences ou des DAB afin

d'avoir une idée sur leurs adresses.

20 Ajouter une agence 20 3 10 En tant qu'administrateur, je veux ajouter une

nouvelle agence afin que mon application soit

mise à jour.

21 Modifier les coordonnées d'une

agence.

21 3 10 En tant qu’administrateur, je veux modifier les

coordonnées d'une agence afin que mon

application soit mise à jour.

22 Supprimer une agence 22 3 10 En tant qu'administrateur, je veux désactiver une

agence afin que mon application soit mise à jour.

23 Ajouter un DAB 23 3 10 En tant qu'administrateur, je veux ajouter un DAB

afin que mon application soit mise à jour.

24 Modifier les coordonnées d'un

DAB

24 3 10 En tant qu'administrateur, je veux modifier les

coordonnées d'un DAB afin que mon application

soit mise à jour.

25 Supprimer un DAB 25 3 10 En tant qu'administrateur, je veux désactiver un

DAB afin que mon application soit mise à jour.

26 Ajouter un abonné 26 3 10 En tant qu'administrateur, je veux ajouter un

abonné afin que mon application soit mise à jour.

19

27 Mettre à jour les coordonnées

d'un abonné

27 3 10 En tant qu'administrateur, je veux mettre à jour les

coordonnées des abonnées (en cas d’annulation

de pack ou de changement de numéro de

téléphone ou de nom) afin de leur faciliter l'accès.

28 Supprimer un abonné 28 3 10 En tant qu'administrateur, je veux supprimer un


29 Accepter la demande d'obtention

d'une carte

29 3 10 En tant qu'administrateur, je veux accepter la

demande d’obtention d’une carte afin de répondre

aux demandes des clients.

30 Décliner la demande d'obtention

d'une carte

30 3 10 En tant qu'administrateur, je veux décliner les

demandes d’obtention d’une carte afin de

respecter les demandes d'obtention d'une carte.

31 Supprimerlademande

d’obtention d’une carte

31 3 10 En tant qu'administrateur, je veux supprimer les

demandes d’obtention d’une carte afin de mettre

à jour les données.

32 Accepter la demande

d'opposition sur une carte

32 3 10 En tant qu'administrateur, je veux accepter les

demandes d'opposition sur une carte afin de

répondre aux demandes des clients.

33 Décliner la demande



demandes d'opposition sur une carte afin de

respecter les conditions d'opposition sur une

carte.

34 Supprimer la demande



demande d'opposition sur une carte afin de mettre

à jour les données.

20

35 Accepter la demande d'obtention

d'un chéquier


demandes d'obtention d'un chéquier de répondre

aux demandes des clients.

36 Décliner la demande d'obtention

d'un chéquier


demandes d'obtention d'un chéquier afin de

respecter conditions d'obtention d'un chéquier.


d'obtention d'un chéquier


demandes d'obtention d'un chéquier afin de

mettre à jour les données.


d'opposition sur un chéquier


demandes d'opposition sur un chéquier afin de

répondre aux demandes des clients.





respecter les conditions d'opposition sur un

chéquier





mettre à jour les données.

41

Consulter les demandes

d'obtention ou d'opposition de

cartes ou de chéquiers

41 3 10 En tant qu'administrateur, je veux consulter les

demandes d'obtention ou d'opposition sur

chéquiers ou sur cartes afin de vérifier les

données.

42 Confirmer la réception des

messages

42 3 10 En tant qu'administrateur, je veux confirmer les

messages envoyés par les clients afin de prendre

en charges les suggestions et les réclamations des

clients.

21

43 Consulter la liste des messages

archivés

43 3 10 En tant qu'administrateur, je veux consulter la

liste des messages archivés afin de vérifier les

données.

44 Confirmer les demandes de

rendez-vous.

44 3 10 En tant qu'administrateur, je veux confirmer les

demandes de rendez-vous afin de gérer les

rencontres avec le chargé clientèle de l'agence

concernée.

45 Supprimer la demande de rendez

vous


demandes de rendez-vous afin de faciliter la visite

des clients à la banque.

46 Consulter la liste des anciens

rendez-vous

46 3

10 En tant qu'administrateur, je veux consulter la

liste des anciens rendez-vous afin de vérifier les

données.

47 Accepter la demande de

virements

47 3 1 En tant qu'administrateur, je veux accepter la

demande de virement afin de répondre aux

demandes des clients.

48 Décliner la demande de

virements

48 3 10 En tant qu'administrateur, je veux déclinerla

demande afin de respecter les conditions de

virement.

49 Supprimer la demande de

virement

49 3 10 En tant qu'administrateur, je veux supprimer la

demande afin de mettre à jour les données.

50 Consulter les anciennes

demandes de virements

50 3 10 En tant qu'administrateur, je veux consulter la

liste ancienne des rendez-vous afin de vérifier les

données.

22

6. Planification des Releases

La réunion de planification des sprints est une étape importante dans SCRUM. Le planning de

travail et l'identification du Backlog des sprints sont les buts de cette réunion. Durant ce meeting,

la durée de chaque sprint est décidée selon la complexité du contexte et la taille de l'équipe.

La planification de Sprint répond aux questions suivantes :

Qu’est-ce qui peut être terminé au cours de ce Sprint ?

Comment sera effectué le travail choisi ?

Et donc, une succession de Releases est le produit de cette réunion pour organiser le travail de

l'équipe. Un Release est une série de Sprints qui se termine quand les incréments successifs

constituent un produit présentant suffisamment de valeurs à ses utilisateurs. Dans notre cas, nous

avons décidé de découper notre projet en deux Releases.

La figure 4 schématise le découpage en Releases.

Figure 4 : Schéma de Releases

23

7. Identification de l’équipe Scrum

Dans le tableau 3, nous définissons, tout d’abord, notre équipe de travail ainsi que le rôle de chaque

équipier selon les rôles définis par Scrum

8. Diagramme de cas d’utilisation initial

Maintenant, nous allons présenter les différents besoins fonctionnels de notre application exprimés

précédemment d'une manière informelle en utilisant le digramme de cas d'utilisation d'UML.

La figure 5 illustre le diagramme de cas d'utilisation global de notre application

Rôles Scrum Personnes Affectées

Product Owner M. Mohamed Hedi AMLOUK

Scrum Master M. Hosni KRICHA, Mme. Nadia YACOUBI

Team TAHARI Cyrine, TORKHANI Yasmine

Tableau 3: Identification de l’équipe Scrum

Figure 5: Diagramme de cas d’utilisation global de l’application

24

9. Technologies et outils de développement

Dans cette partie, nous décrivons tous les outils matériels et logiciels de développement et de

conception, avec lesquels cette application a été réalisée. Nous allons commencer par une brève

description du système d'exploitation Android, de l’architecture de notre application mobile et web

J2EE, et nous allons finir par les outils de développement utilisé pour réaliser ce projet.

9.1 Présentation du système d’exploitation mobile Android

Android est développé par un consortium : l'Open Handset Alliance (OHA) , créée officiellement

en novembre 2007et qui regroupe beaucoup de sociétés liées aux nouvelles technologies,

intervenant, plus ou moins directement, dans le marché de la téléphonie mobile (Intel, HTC,

Motorola, Garmin…), mais le principal contributeur est Google .Son but est de mettre en place des

normes ouvertes dans le domaine de la téléphonie mobile. C'est à dire que les développeurs

d'application Android pourront accéder aux fonctionnalités du base d'un téléphone via une API4

spécifique.

Android connait la plus forte croissance sur le marché des OS mobiles avec son propre marché

d’applications nommé Google Play. Une étude faite en 2014 par ABI Researchpour évaluer la

vente mondiale de Smartphones par système d'exploitation mobile, montre une grande dominance

du système d'exploitation Android.

La figure 6 illustre l’étude montrant la dominance du système d’exploitation d’Android sur le

marché.

4Application Programming Interface

Figure 6 : Etude Comparative des systèmes d’exploitation mobile sur le marché [3]

25

9.2 Architecture de l’application Front Office

Nous décrivons dans cette partie le fonctionnement de notre application mobile «Attijari Mobile

Banking». Elle est connectée à un serveur de bases de données distant, via Internet, afin de

récupérer les données en utilisant des requêtes SQL, ce qui nécessite alors l’intégration d’un

serveur web entre l’application client et le serveur de bases de données. D’où l’architecture de notre

application mobile est une architecture 3-tiers partagée entre:

Le client Android :Il s’agit du demandeur de ressources et consommateurs des web services.

Le serveur Web : Il permet de gérer la communication entre le client Android et le serveur de base

de données.

Le serveur de base de données : Il permet de fournir les données au serveur web.

Afin de gérer la base de données, nous avons écrit et exécuter des scripts PHP(en utilisant le

protocole HTTP du système Android) et nous avons codé les données dans le format JSON.

La figure 7 schématise l’architecture générale de note application mobile.

Figure 7:Architecture générale de l’application mobile [4]

26

9.3 Framework et développement de l’application Back Office

Tout système d'information nécessite la réalisation de trois groupes de fonctions: le stockage des

données, la logique applicative et la présentation. Ces trois parties sont indépendantes les unes des

autres. D'où notre choix de l'architecture 3 tiers pour l'application Web (Figure 8).

L’architecture 3-tiers, est une architecture partagé entre :

Les pc clients (ou administrateurs)

Le serveur Web et le serveur d’application.

Le serveur de base de données.

En effet, cette architecture est un modèle logique d’architecture applicative qui vise à séparer, très

nettement trois couches logicielles au sein d’une même application ou système, à modéliser et à

présenter cette application comme un empilement de trois couches, étages, ou niveaux qui sont les

suivantes :

Couche Présentation (premier niveau)

Elle correspond à la partie de l’application visible et interactive avec les utilisateurs. On parle

d’interface homme machine. La couche présentation relaie les requêtes de l’utilisateur à destination

de la couche métier, et lui présente en retour les informations renvoyées par les traitements de cette

couche. Il s’agit donc d’un assemblage de services métiers et applicatifs offerts par la couche

inférieure.

Couche Métier / Business (second niveau)

Elle correspond à la partie fonctionnelle de l’application, celle qui implémente la «logique», et qui

décrit les opérations que l’application opère sur les données en fonction des requêtes des utilisateurs

effectuées au travers de la couche présentation.

Couche Accès aux données (troisième niveau)

C'est la partie qui gère l’accès aux données du système. Ces données peuvent être propres au

système, ou gérées par un autre système.

La figure 8 schématise l’architecture générale de note application web.

Figure 8: Architecture générale d'application web [5]

27

Parlons maintenant de la mise en place de la plate-forme J2EE : Cette opération se constitue de

deux étapes fondamentales : la mise en place des couches et celle du serveur web.

Mise en place des couches

Nous avons choisi de coder l’application en se basant sur les couches Hibernate, Spring et Spring

Security afin de faciliter l’effort de l’implémentation et de favoriser l’aspect sécurité ainsi que la

bibliothèque de composants PrimeFaces pour JSF2pour les interfaces.

o La couche Spring

Spring est un Framework libre pour construire et définir l’infrastructure d’une application

java2, dont il facilite le développement et les tests.

«SPRING est effectivement un conteneur dit «léger» .Il prend donc en charge la création

d'objets et la mise en relation d'objets par l'intermédiaire d'un fichier de configuration qui décrit

les objets à fabriquer et les relations de dépendances entre ces objets.» [6]

Pour l'authentification on a du intégrer le Framework Spring Security.En effet C’est est un

sous-projet de Spring, il a été lancé en 2003 sous le nom d’Acegi Secuirty. En 2007 il sera

renommé Spring Security. C’est l’un des projets les plus avancés de Spring.

«Spring Security est un cadre qui se concentre sur la fourniture de l'authentification et

l’autorisation aux applications Java. Comme tous les projets de Spring , la puissance réelle de

Spring Security se trouve dans la façon dont facilement il peut être étendu pour répondre aux

besoins personnalisés».[7]

o La couche Hibernate

C’est une couche qui sert à la persistance des objets dans les bases de données relationnelles.

Elle présente un avantage remarquable contre l’accès classique aux données manifestés par les

JDBCs «Java Data Base Connectivity», vue la rapidité de traitement via des appels à des

méthodes objet de haut niveau.

o La couche Prime faces

Le développement d’interface web avec JSF était limité à cause de peu de composants

graphiques disponibles.A cause de ce manque de composants, de nombreux lancés afin de créer

des bibliothèques de composants JSF plus ou moins spécifiques.

http://fr.wikipedia.org/wiki/Framework

http://fr.wikipedia.org/wiki/Libre

http://fr.wikipedia.org/wiki/Spring_framework#cite_note-1

28

D’où l’apparition de Prime Faces qui est maintenue par «Prime Teknoloji», une entreprise de

logiciels Turque de développement spécialisée dans Agile et Java EE conseil.

«Prime Faces est une bibliothèque open source de composants JSF.Il est basé, côté serveur, sur

l’API standard de JSF 2.Coté client, les scripts de Prime Faces sont basés sur la librairie la plus

populaire de JavaScript jQuery.Prime Faces vise à garder le traitement propre, rapide et

léger».[8]

Mise en place du serveur Web

o Apache Tomcat 7.0.59

«Apache Tomcat est un serveur d’application Java permettant d’exécuter des servlets et des

pages serveurs Java(JSP). Il peut être utilisé ou couplé avec un serveur Web, et porté sur

n’importe quel système sur lequel une machine virtuelle Java est installée».[9] Il est

paramétrable par des fichiers XML et de propriétés, et inclut des outils pour la configuration et

la gestion. Il comporte également un serveur HTTP.

10. Environnement technique du travail

Le tableau 4 détaille la configuration matérielle des machines de développement et de déploiement

utilisées ainsi que les différents logiciels qui y sont installés :

Tableau 4: Description des machines de développement

Machines Machine1 Machine2

Propriétaire TORKHANI Yasmine TAHARI Cyrine

Processeur Intel Core i5 Intel Core i5

RAM 8GB 8GB

Système d’exploitation Windows 8.1 Entreprise (x64) Windows 8.1 Entreprise (x64)

Logiciels installés Eclipse

MyEclipse for Spring

Rational Rose

WampServer

Apach Tomcat Server

plsqldevloper 7.0.3

Oracle 10g

ScreenPresso

Eclipse

MyEclipse for Spring

Rational Rose

WampServer

Apach Tomcat Server

plsqldevloper 7.0.3

Oracle 10g

ScreenPresso

http://fr.wikipedia.org/wiki/Extensible_Markup_Language

http://fr.wikipedia.org/wiki/Serveur_HTTP

29

10.1 Outil de conception

Rational Rose

Rational Rose est un logiciel édité par l'entreprise Rational Machines pour créer et éditer les

différents diagrammes du modèle UML (Unified Modeling Language) d'un logiciel. [10]

10.2 Outils de développement

Dans cette partie nous allons décrire les outils de développement utilisé pour réaliser ce projet.

Environnement de développement : Eclipse Luna 4.4 (La nouvelle version de l'IDE)

Eclipse est un environnement de développement open source, décliné et organisé en un ensemble

de sous-projets de développements logiciels, de la Fondation Eclipse visant à développer un

environnement de production de logiciels libre qui soit extensible et universel en s’appuyant

principalement sur le langage Java.[11]

Environnement de développement : MyEclipse for Spring 9.0

MyEclipse est un environnement de développement intégré basé sur le très connu Eclipse. Son

intérêt se situe dans la facilitation de la mise en place de différents Framework, tels que Hibernate

ou Spring. [12]

L'ensemble des bibliothèques logicielles : Java Développent Kit (JDK7 64bits)

Le JDK désigne un ensemble de bibliothèques logicielles de base du langage de

programmation Java, ainsi que les outils avec lesquels le code Java peut être compilé, transformé

en byte code destiné à la JVM (Java Virtual Machine).[13]

Android Software Development Kit (SDK)

Le SDK est' un ensemble d'outils que met à disposition Google afin de vous permettre de

développer des applications pour Android. [14] Il est disponible pour Windows, MacOs X et linux

et inclut des outils ainsi qu'un émulateur Android pour exécuter des applications.

AndroidDevelopment Tools (ADT)

Eclipse a été conçu de manière à pouvoir recevoir des plugins. Le plugin pour les développements

d'applications Android s'appelle ADT Outils de développement Android) et il peut être téléchargé

directement depuis Eclipse. [14]

Android Virtual Device (AVD)

L'Android Virtual Device est un émulateur de terminal sous Android, c'est-à-dire que c'est un

logiciel qui se fait passer pour un appareil sous Android à votre ordinateur. [14]

http://fr.wikipedia.org/wiki/Fondation_Eclipse

http://fr.wikipedia.org/wiki/Logiciel_libre

http://fr.wikipedia.org/wiki/Java_(technique)

http://fr.wikipedia.org/wiki/Biblioth%C3%A8que_logicielle

http://fr.wikipedia.org/wiki/Langage_de_programmation

http://fr.wikipedia.org/wiki/Langage_de_programmation

http://fr.wikipedia.org/wiki/Java_(langage)

http://fr.wikipedia.org/wiki/Bytecode

http://fr.wikipedia.org/wiki/Machine_virtuelle_Java

30

SGBDR Oracle 10g express

Oracle Database est un système de gestion de base de donnéesrelationnel (SGBDR) fourni

par Oracle Corporation. [15]

WampServer 32 bits

WampServer est une plate-forme de développement Web sous Windows pour des applications

Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et d’une base de données

MySQL. Il possède également PHPMyAdmin pour gérer plus facilement vos bases de données.[16]

10.3 Langages de programmation

Java

Java est un langage de programmation orienté objet, développé par Sun Microsystems permettant

de créer des logiciels compatibles avec des nombreux systèmes d’exploitation et donne aussi la

possibilité de développer des programmes pour téléphones portables. [17]

PHP

PHP (Hypertext Preprocessor) est un langage de programmation informatique essentiellement

utilisé pour produire des pages web dynamiques via un serveur HTTP. [18]

REST

REST (Representational State Transfer) est un style d'architecture réseau pour Web Services qui

met l'accent sur la définition de ressources identifiées par des URI, et utilise les messages du

protocole HTTP pour définir la sémantique de la communication client/serveur: [19]

GET pour le rapatriement d'une ressource,

POST pour une création

REST n'est pas vraiment un standard. Il n'existe donc pas de spécifications de REST. Il faut

comprendre le style REST et ensuite concevoir des applications ou des services Web selon ce style.

Bien que REST ne soit pas un standard, il utilise des standards. En particulier :

URI comme syntaxe universelle pour adresser les ressources

HTTP un protocole sans état (stateless) avec un nombre très limité d'opérations,

Des liens hypermedia dans des documents (X)HTML et XML pour représenter à la fois le

contenu des informations et la transition entre états de l'application,

Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg

pour la représentation des ressources. [20]

http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_base_de_donn%C3%A9es

http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_base_de_donn%C3%A9es

http://fr.wikipedia.org/wiki/Oracle_Corporation

31

JSON

JSON (JavaScript Object Notation) un format d'encodage de données structurées en JavaScript qui

date de 2002. Il permet de représenter de l’information structurée. Il n'est pas rare d'associer le

couple REST/JSON pour des raisons de simplicité. Son avantage est de fournir un support pour

une écriture simple et légère au format texte, relativement compréhensible par les développeurs

JavaScript, mais aussi - et surtout - d'être nativement interprété.

10.4 Langage de modélisation :

UML (en anglais Unified Modeling Language ou « langage de modélisation unifié ») est un langage

de modélisation graphique à base de représentations graphiques. Il est apparu dans le monde du

génie logiciel, dans le cadre de la «conception orientée objet». Couramment utilisé dans les projets

logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au domaine

informatique. [21]

11. Conclusion

Au long de ce chapitre, nous avons présenté le Sprint 0 qui, est en fait une phase de préparation

pendant laquelle on a construit notre backlog du produit en se basant sur les besoins fonctionnels

et non fonctionnels. En plus, nous avons découpé notre projet en des releases qui formeront les

chapitres suivants. Et finalement, nous avons défini les technologies et les environnements de

développement ainsi que l’architecture globale de l’application.

32

Chapitre 3Développement de l'application

Front Office

1. Introduction

Notre premier release sera composé de trois sprints. Tout au long de ce chapitre, nous allons traiter

les histoires utilisateurs de nos sprints pour produire un ensemble d'incréments potentiellement

livrable. Avant de se lancer dans le premier sprint, l'équipe doit définir le but de ce dernier qui doit

être défini en terme métier et non pas terme technique pour qu'il soit compréhensible par les

membres en dehors de l’équipe. Il s’agit de répondre à une question fondamentale «Pourquoi

faisons-nous ce sprint?».

2. Sprint 1 : Authentification

Au début de chaque sprint, on définit un objectif et on lui associe une liste de fonctionnalités qui

constitueront le backlog de sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne

peuvent être modifiés.

Ci-dessous la définition de l'objectif et des développeurs de ce sprint.

Objectif : Les clients de l'application «Attijari Mobile Banking» sont capables de

s’authentifier avec succès avec la possibilité de changer le mot de passe en cas de besoin.

Développeurs : Team.

2.1 Sprint planning ou planification du sprint

Une fois nous avons défini le but de notre sprint, il est temps de décider quelles histoires de notre

backlog du produit inclure dans le backlog du sprint.

Le tableau 5 résume donc le backlog du premier sprint.

33

Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un sprint

nous pouvons dégager trois étapes principales qui sont la spécification fonctionnelle, la conception,

et le test. Tout au long de ce sprint, nous respectons ces activités pour construire le plan de notre

travail.

2.2 Spécification fonctionnelle

Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du sprint puis une

description textuelle de ses histoires utilisateurs.

2.2.1 Diagramme de Cas d'utilisation

Il s'agit de la première étape du sprint 1. Afin d'accéder aux différentes fonctionnalités offertes par

l'application Mobile Banking d'Attijari Bank, le client doit s'authentifier en saisissant un code client

et un mot de passe généré par la banque lors de son inscription dans le pack Mobile Banking

d’Attijari Bank. Il a également la possibilité de modifier son mot de passe afin de personnaliser ses

paramètres d'authentification.

La figure 9 illustre le diagramme de cas d'utilisation global du premier Sprint.

2.2.2 Description textuelle

Le tableau 6 décrit textuellement le même cas d'utilisation

Id Nom Description Priorité

1

S’authentifier En tant que client d'Attijari Bank je veux



20

2 Modifier mot de passe

En tant que client d'Attijari Bank je veux

changer mon mot de passe afin de mieux

personnaliser mes paramètres de

connexion.

20

Tableau 5: Sprint 1 Backlog

Figure 9: Diagramme de cas d’utilisation global Sprint 1

34

Cas d’utilisation S’authentifier

Acteur Client d’Attijari Bank

Pré condition : L’utilisateur M-Banking télécharge l’application sur

son terminal mobile.

Post condition : L’utilisateur M-Banking est identifié comme étant

un client d’Attijari Bank.

Description du scénario principal : -Le client remplit les champs d’authentification et

clique sur le bouton «Connexion».

-Le système vérifie les informations saisies par le

client et affiche l’interface suivante.

Exception : Si un des champs est invalide, le système affiche un

message d’erreur.

Point d'extension:

Modifier mot de passe

-Le client clique sur «Changer mot de passe».

-Le système affiche l’interface appropriée.

- Le client saisit les champs nécessaires et clique sur

«Enregistrer».

-Le système vérifie les informations saisies par le

client et enregistre les modifications.

2.3 Conception

La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et

un diagramme de séquences.

Le diagramme de classes permet de représenter une vue statique du système

d’information.[23] Il identifie la structure des classes du système, y compris les propriétés

et les méthodes de chaque classe, et les diverses relations qui peuvent exister entre les

classes y sont également représentées.

Tableau 6: Description textuelle de cas d’utilisation «S’authentifier»

35

Le diagramme de séquences permet de représenter une vue dynamique du système

d’information.[23] Il permet de décrire les scénarios de chaque cas d'utilisation en mettant

l'accent sur la chronologie des opérations en interaction avec les objets.

Pour les cas d’utilisation «S’authentifier» et «Modifier mot de passe», nous allons présenter ces

deux diagrammes.

Cas d’utilisation «S’authentifier»

o Diagramme de classes

Le diagramme de classes du cas d’utilisation «S’authentifier» se traduit par les différentes classes

participantes à la réalisation de ce dernier.

La figure 10 illustre le diagramme de classes du cas d'utilisation «S'authentifier».

Figure 10 : Diagramme de classes du cas d’utilisation «S’authentifier»

o Diagramme de séquences

A travers ce diagramme, nous décrivons le scénario du même cas d’utilisation. Dans un premier

lieu, l’utilisateur M-Banking remplit le formulaire d’authentification et clique sur le bouton

«Connexion». Ensuite le système vérifie s’il s’agit bien d’un abonné ou non à travers le web service

«Login».

36

La figure 11 illustre le diagramme de séquences du cas d’utilisation «S'authentifier».

Figure 11: Diagramme de séquences du cas d’utilisation «S'authentifier»

Cas d’utilisation «Modifier Mot de passe»


Le diagramme de classes du cas d’utilisation «Modifier mot de passe» se traduit par les différentes

classes participantes à la réalisation de ce dernier.

La figure 12 illustre le diagramme de classes du cas d’utilisation «Modifier mot de passe».

37

Figure 12 Diagramme de classes du cas d’utilisation «Modifier mot de passe».


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Modifier mot de

passe». Dans un premier lieu, le client d’Attijari Bank remplit le formulaire de modification du mot

de passe.Ensuite le système vérifie la saisie et enregistre le nouveau mot de passe à travers le web

service «Update MDP».

La figure 13 illustre le diagramme de séquences du cas d’utilisation «Modifier mot de passe».

38

Figure 13 Diagramme de séquences du cas d’utilisation «Modifier mot de passe».

2.4 Test

L'approche Agile met le test au cœur des projets. Pour Scrum et les méthodes agiles en général, le

test ne se fait pas après la fin de développement. Au contraire, le test est une phase intégrée dès le

début du premier sprint jusqu'à la livraison du produit final.

Pour notre application mobile, les tests ont été effectués sur un smartphone Android (Version 4.2.2)

via un câble USB et sur des clients réels de la banque. Donc, pour des raisons de confidentialité on

a du flouter les informations personnelles des clients.

Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce sprint. Commençons par

l’interface principale au niveau de laquelle l’utilisateur M-Banking choisit l’espace auquel il veut

39

accéder. Dans le cas d’un abonné, il va choisir d’accéder à l’espace client afin de bénéficier des

services bancaires privés tel que la modification de mot de passe. Il doit donc s’authentifier en

saisissant son code client et son mot de passe.

La figure 14 illustre la première interface de l’application mobile.

La figure 15 illustre l’interface d’authentification.

La figure 16 illustre l’interface de modification du mot de passe

Figure 14 : Interface principale

de l’application mobile

Figure 15: Interface

d’authentification.

Figure 16: Interface de

modification du mot de passe

. Sprint 2: Accès aux services clients





Objectif : Les clients de l'application «Attijari Mobile Banking» sont capables d’effectuer

des demandes d'obtention et d’opposition sur carte et/ou chéquier et des demandes de

virement. Ils sont aussi capables de consulter leur extrait de compte ainsi que leur boite de

réception afin de voir si la banque a répondu à leurs demandes.

40





Le tableau 7 résume donc le backlog du deuxième sprint.

Tableau 7 :Sprint2 backlog

Id Nom Priorité Description

1 S'authentifier 20 En tant que client d'Attijari Bank, je veux



2 Modifier mot de passe 20 En tant que client d'Attijari Bank, je veux

changer mon mot de passe afin de mieux

maitriser mes paramètres de connexion.

3 Consulter la boite de

réception.

20 En tant que client d'Attijari Bank, je veux

consulter ma boite de réception afin de voir si

mes demandes sont confirmées ou déclinées

.

4 Demander une carte

bancaire


demander une nouvelle carte afin de faciliter

mes transactions quotidiennes.

5 Opposer une carte bancaire 20 En tant que client d'Attijari Bank, je veux

opposer ma carte bancaire en cas de perte ou

de vol afin de

bloquer son utilisation.

6 Demander un chéquier 20 En tant que client d'Attijari Bank, je veux

opposer mon chéquier en cas de perte ou de

vol afin de bloquer son utilisation.

41

7 Opposer un chéquier 20 En tant que client d'Attijari Bank, je veux

demander un nouveau chéquier afin de

faciliter mes transactions quotidiennes.

8 Demander des virements

simples intra-bancaires


opposer mon chéquier en cas de perte ou de

vol afin de bloquer son utilisation.

9 Consulter l’extrait du

compte


demander des virements afin de manipuler le

transfert d’argent entre mes comptes.

10 Consulter la boite de

réception


consulter mon extrait de compte afin de voir

mes dix dernières transactions effectuées sur

ce compte.




travail.


Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du Sprint puis une



Il s'agit de la première étape de ce sprint. Après authentification, le client d'Attijari Bank se trouve

capable de bénéficier des différents services bancaires offerts par Attijari Bank.

La figure 17 illustre le diagramme de cas d’utilisation global du deuxième Sprint.

42

Figure 17: Diagramme de cas d’utilisation global Sprint 2


Ci-dessous la description textuelle des différents cas d'utilisation généralisés du cas

d’utilisation«Accéder aux services clients d'Attijari Bank».

Le tableau 8 décrit textuellement le cas d'utilisation «Consulter l’extrait du compte»

Tableau 8 : Description textuelle du cas d’utilisation «Consulter l’extrait du compte»

Cas d’utilisation : Consulter l’extrait du compte

Acteur : Client d'Attijari Bank

Pré condition : L’utilisateur M-Banking est identifié comme étant un client

d’Attijari Bank.

Post condition : Le client consulte son extrait du compte avec succès.

Description du scénario

principal :

-A travers un sliding menu, le client choisit «Extrait

Bancaire».

-Le système affiche la liste des comptes du client.

-Le client choisit un des comptes.

-Le système affiche l’interface des mouvements du compte

approprié.

43

Point d'extension:

Effectuer des

virements simples

intra-bancaires

-A travers un sliding menu, le client choisit «Virements».


-Le client remplit les champs nécessaires et clique sur le bouton

«Valider». -Le système vérifie les informations saisies par le client et

affiche un message de succès.

A titre d'exemple, nous détaillons le cas d'utilisation «Demander une carte bancaire». Le scénario

pour la demande et l'opposition sur un chéquier et demande virement est identique à celui de la

demande et l'opposition sur une carte.

Tableau 9: Description textuelle du cas d’utilisation «Demander une carte bancaire»

Cas d’utilisation : Demander une carte bancaire



d’Attijari Bank.

Post condition : La demande de la carte bancaire est enregistrée.

Exception : Si un des champs est vide, le système affiche un message

d’erreur.


principal :

-A travers un sliding menu, le client choisit «Demande carte».

-Le système affiche l'interface appropriée.

-Le client remplit les champs nécessaires et clique sur le

bouton «Valider».

-Le système vérifie les informations saisies par le client,

enregistre la demande et affiche un message de succès.

Point d'extension

Opposer une carte

bancaire

-A travers un sliding menu, le client choisit «Opposition sur

Carte».


-Le client saisit les champs nécessaires et clique sur

«Valider».-Le système vérifie les informations saisies par le

client, enregistre la demande et affiche un message de succès.

Le tableau 10 décrit textuellement le cas d'utilisation«Consulter la boite de réception»

44

Tableau 10: Description textuelle du cas d’utilisation «Consulter la boite réception»

Cas d’utilisation : Consulter la boite de réception



d’Attijari Bank.

Post condition : Le client d'Attijari Bank consulte sa boite de réception avec

succès.


principal :

-A travers un sliding menu, le client choisit «Boite de

réception».


-Le client consulte sa boite de réception.

2.7 Conception



Le diagramme de classes permet de représenter une vue statique du système d’information.

[23] Il identifie la structure des classes du système, y compris les propriétés et les méthodes

de chaque classes, et les diverses relations qui peuvent exister entre les classes y sont

également représentées.

Le diagramme de séquence permet de représenter une vue dynamique du système

d’information. [23] Il permet de décrire les scénarios de chaque cas d'utilisation en mettant


Pour les cas d’utilisation de ce Sprint, nous allons présenter ces deux diagrammes.

Cas d’utilisation «Consulter l’extrait du compte»


Le diagramme de classes du cas d’utilisation «Consulter l’extrait de compte» se traduit par les

différentes classes participantes à la réalisation de ce dernier.

La figure 18 illustrant le diagramme de classes du cas d’utilisation «Consulter l’extrait de compte».

45

Figure 18: Diagramme de classes du cas d’utilisation «Consulter l’extrait de compte»


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Consulter l’extrait du

compte». Si le client d’Attijari Bank choisit de faire une consultation de l’extrait bancaire, il doit

choisir au début le compte auquel il veut faire cette consultation. Pour cela, deux web services sont

nécessaires : «GetInfosCompte» pour les consultations des comptes que possédé le client, et

«GetMouvement» pour la consultation des mouvements du compte.

La figure 19 illustre le diagramme de séquences du cas d’utilisation «Consulter l’extrait du

compte».

46

Figure 19: Diagramme de séquences du cas d’utilisation «Consulter l’extrait du compte»

Cas d’utilisation «Demander une carte bancaire»


Le diagramme de classes du cas d’utilisation «Demander une carte bancaire» se traduit par les


La figure 20 illustre le diagramme de classe du cas d'utilisation «Demander une carte bancaire»

47

Figure 20: Diagramme de classe du cas d'utilisation «Demander une carte bancaire»


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Demander une carte

bancaire». Dans un premier lieu, le client d’Attijari Bank remplit le formulaire. Ensuite le système

vérifie la saisie et enregistre la demande à travers le web service «DemandeCarte».

La figure 21 illustre le diagramme de séquences du cas d’utilisation «Demander une carte bancaire»

48

Figure 21: Diagramme de séquences du cas d’utilisation «Demander une carte bancaire»

«Opposer une carte bancaire»


Le diagramme de classes du cas d’utilisation «Opposer une carte bancaire» se traduit par les


La figure 22 illustre le diagramme de classes du cas d'utilisation «Opposer une carte bancaire».

49

Figure 22: Diagramme de classes du cas d'utilisation «Opposer une carte bancaire»


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Opposer une carte

bancaire». Dans un premier lieu, le client d’Attijari Bank consulte la liste des différentes cartes

qu’il possède. Ensuite, il choisit celle qu’il veut opposer, consulte les détails de la carte

concernée, puis enregistre la demande d’opposition sur carte.

La figure 23 illustre le diagramme de séquences du cas d’utilisation «Opposer une carte bancaire ».

50

Figure 23: Diagramme de séquences du cas d’utilisation «Opposer une carte bancaire»

«Consulter la boite de réception»


Le diagramme de classes du cas d’utilisation «Consulter la boite de réception» se traduit par les


La figure 24 illustre le diagramme de classes du cas d'utilisation «Consulter la boite de réception».

51

Figure 24: Diagramme de classes du cas d'utilisation «Consulter la boite de réception»


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Consulter la boite de

réception». Le client d’Attijari Bank consulte sa boite de réception afin de suivre l’avancement de

ses demandes (si elles sont en cours, acceptées ou déclinées).

52

La figure 25 illustre le diagramme de séquences du casd’utilisation «Consulter la boite de

réception».

Figure 25: Diagramme de séquences du cas d’utilisation «Consulter la boite de réception»

2.8 Test




53

Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce sprint. Après avoir

s’authentifier, le client d’Attijari Bank se trouve capable de bénéficier des différents services

bancaires offerts par Attijari Bank.

La figure 26 illustre l’interface du menu principal (qui inclut uniquement les services dédiés aux

clients).

L’interface de consultation de l’extrait bancaire se divise en deux:

-La figure 27 illustre l’interfacede consultation des comptes ainsi que le solde de chaque compte.

-La figure 28 illustre l’interface des mouvements du compte approprié.

Figure 26 : Interface du menu

principal

Figure 27 : Interface de

consultation des comptes

bancaires

Figure 28 : Interface de

consultation de l’extrait bancaire

La figure 29 illustre l’interface de demande carte.

54

Figure 29 Interface de demande d’une carte

3. Sprint 3: Accès aux services publics





Objectif : Les utilisateurs M-Banking de l'application «Attijari Mobile Banking» sont

capables d’accéder un espace public où ils bénéficieront d’un ensemble de fonctionnalités

(consulter le système de géo localisation, consulter les cours de devise…).


55




Le tableau 11 résume donc le backlog du troisième sprint

Tableau 11 : Sprint3 backlog

Id Nom Priorité Description

1 Suivre les actualités de la

banque

20 En tant qu’utilisateur M-Banking, je veux

suivre les actualités d’Attijari Bank afin

d'être au courant de ses nouveautés.

2 Suivre les cours de devise 20 En tant qu’utilisateur M-Banking, je veux

suivre les cours de devise afin d’être au

courant des changements de devise.

3 Suivre le marché de la

bourse


suivre le marché de la bourse afin d'être au

courant des changements.

4 Prendre un rendez-vous 20 En tant qu’utilisateur M-Banking je veux

prendre un rendez-vous afin de planifier une

rencontre avec le chargé clientèle de mon

agence.

5 Envoyer un message 20 En tant qu’utilisateur M-Banking je veux

envoyer un message la banque afin de

communiquer mes réclamations et mes

suggestions.

6 Appeler la banque 20 En tant qu’utilisateur M-Banking je veux

appeler la banque afin d’entrer en contact

immédiat avec le centre de relation client.

7 Consulter le système de

géo localisation des

agences


consulter le système de géo localisation afin

de visualiser sur la carte les agences

d’Attijari Bank sur le territoire tunisien.

56

8 Consulter le système de

géo localisation des D AB


consulter le système de géo localisation afin

de visualiser sur la carteles DAB d’Attijari

Bank sur le territoire tunisien.

9 Consulter la liste des

points de contacts des

agences


consulter la liste des DAB afin d'avoir une

idée sur leurs adresses.


points de contacts des

DAB


consulter la liste des agences ou des DAB

afin d'avoir une idée sur leurs adresses.




travail.





Il s'agit de la première étape de ce sprint. N’importe quelle personne possédant un terminal mobile

Android peut manipuler l’application pour différentes raisons. Ces utilisateurs, qui sont considérés

comme des clients potentiels de la banque, ont accès à un espace public dans lequel ils peuvent

bénéficier des différents services.

La figure 30 illustre le diagramme de cas d’utilisation global du Sprint 3.

57

Figure 30: Diagramme de cas d’utilisation global Sprint3


Ci-dessous la description textuelle des différents cas d'utilisation généralisés de «Accéder aux

services publics d'Attijari Bank».

Le tableau 12 décrit textuellement le cas d'utilisation «Accéder aux services public d'Attijari

Bank»

Tableau 12 : Description du cas d’utilisation «Accéder aux services public d’Attijari Bank»

Cas d’utilisation : Accéder aux services public d'Attijari Bank

Acteur : Utilisateur M-Banking

Pré condition : L’utilisateur M-Banking télécharge l’application sur son

terminal mobile.

Post condition : L’utilisateur accède à l’espace public avec succès.


principal :

-Le système affiche l’interface principale de l'application.

-Le client clique sur le bouton «Espace public».

-Le système affiche le menu principal.

58

Scénarii de base:

Suivre les actualités de

la banque

-A travers un sliding menu, le client choisit «Actualités».


Simuler les crédits et

les placements

-A travers un sliding menu, le client choisit «Simulateur de

crédit » ou «Simulateur de placement».


-L’utilisateur remplit les champs de simulation et clique sur le

bouton «Simuler».

-Le système affiche le résultat calculé.

Suivre le marché de la

bourse

-A travers un sliding menu, le client choisit «Bourse».


Suivre les cours de

devise

-A travers un sliding menu, le client choisit de «Cours de

devise».


A titre d'exemple, nous détaillons le cas d'utilisation «Suivre les cours de devise». Le scénario

pour le suivi de la bourse et des actualités estidentique à celui des cours de devise. Concernant les

simulateurs, il s’agit des simples calculs que l’utilisateur aura la possibilité de faire.

Le tableau 13 décrit textuellement le cas d'utilisation «Contacter la banque»

Tableau 13: Description du cas d’utilisation «Contacter la banque»

Cas d’utilisation : Contacter la banque

Acteur : Utilisateur M-Banking

Pré condition : L’utilisateur M-Banking télécharge l’application sur son

terminal mobile.

Post condition : L’utilisateur est capable d’accéder à l’espace public avec

succès.


principal :

-Le système affiche l’interface principale de l'application.

-Le client clique sur le bouton «Espace public».

-Le système affiche le menu principal.

Points d'extension:

Consulter le système de

géolocalisation

-A travers un sliding menu, le client choisit de «Recherche

DAB et Agence» puis choisit «Localiser une Agence» ou

«Localiser un DAB».

59

-Le système affiche l'interface appropriée qui contient une carte

où sont affichés les agences ou les DAB sur le territoire tunisien

avec leur coordonnés.

Consulter la liste les

points de contact

-A travers un sliding menu, le client choisit de «Liste des points

de contact» puis choisit «Liste des Agences» ou «Liste des

DAB». -Le système affiche l'interface qui contient les régions dans

lesquelles Attijari Bank a une ou plusieurs agence(s) ou DAB.

-Le client choisit une région.

-Le système affiche la liste appropriée.

3.3 Conception



Le diagramme de classes permet de représenter une vue statique du système d’information.

[23]Il identifie la structure des classes du système, y compris les propriétés et les méthodes

de chaque classes, et les diverses relations qui peuvent exister entre les classes y sont



d’information. [23] Il permet de décrire les scénarios de chaque cas d'utilisation en mettant



A titre d'exemple, nous détaillons le cas d'utilisation «Suivre les cours de devise».Le scénario

pour les actualités et le marché de la bourse est identique à celui de devise.

Cas d’utilisation «Suivre les cours de devise»


Le diagramme de classes du cas d’utilisation «Suivre les cours de devise» se traduit par les

différentes classes participantes à la réalisation de ce dernier

La figure 31 illustre le diagramme de classes du cas d’utilisation «Suivre les cours de devise».

60

Figure 31: Diagramme de classes du cas d’utilisation «Suivre les cours de devise»


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Suivre les cours de

devise». L’utilisateur M-Banking d’Attijari Bank accède au menu public et consulte la liste des

cours de devise à travers le web service «GetDevise».

La figure 32 illustre le diagramme de séquences du casd’utilisation «Suivre les cours de devise».

Figure 32: Diagramme de séquences du cas d’utilisation «Suivre les cours de devise»

Cas d’utilisation «Contacter la banque»


Le diagramme de classes du cas d’utilisation «Contacter la banque» se traduit par les différentes


61

La figure 33 illustre le diagramme de classes du cas d’utilisation «Contacter la banque».

Figure 33: Diagramme de classes du cas d’utilisation «Contacter la banque»


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Contacter la banque».

Si l’utilisateur M-Banking d’Attijari Bank choisit de contacter la banque, il peut prendre un rendez-

vous et/ou envoyer un message et/ou appeler la banque directement du téléphone.

Pour le cas de prise d’un rendez-vous et envoi d’un message deux scénarios sont possibles :

un pour les clients d’Attijari Bank, qui trouveront dans l’interface des informations

62

personnelles affichées tel que le nom, prénom, code client, numéro de compte...,et doivent

également saisir d’autres informations supplémentaires Et l’autre pour les clients potentiels

de la banque qui doivent saisir plusieurs informations d’identification.

Pour le cas d’appel, l’utilisateur M-Banking peut effectuer un appel direct vers le centre de

relation client.

La figure 34 illustre le diagramme de séquences du cas d’utilisation «Contacter la banque»

63

Figure 34: Diagramme de séquences du cas d’utilisation «Contacter la banque» Partie1

64

Figure 35 : Diagramme de séquences du cas d’utilisation «Contacter la banque» Partie2

65

Cas d’utilisation «Consulter le système de géolocalisation»


Le diagramme de classes du cas d’utilisation «Consulter le système de géolocalisation» se traduit

par les différentes classes participantes à la réalisation de ce dernier.

La figure 36 illustre le diagramme de classes du cas d’utilisation «Consulter le système de

géolocalisation».

Figure 36: Diagramme de classes du cas d’utilisation «Consulter le système de géolocalisation»


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Consulter le système

de géolocalisation».Si l’utilisateur M-Banking d’Attijari Bank choisit de consulter le système de

géolocalisation, il peut visualiser la carte de toutes les agences d’Attijari Bank et/ou visualiser la

carte de tous les DAB d’Attijari Bank

66

La figure 37 illustre le diagramme de séquences du casd’utilisation «Consulter le système de

géolocalisation »

Cas d’utilisation «Consulter la liste des points de contact»


Le diagramme de classes du cas d’utilisation «Consulter la lister des points de contact» se traduit

par les différentes classes participantes à la réalisation de ce dernier.

Figure 37: Diagramme de séquences du cas d’utilisation «Consulter le système de géolocalisation »

67

La figure 38 illustre le diagramme de classes du cas d'utilisation«Consulter la lister des points de

contact».

Figure 38 : Diagramme de classes du cas d'utilisation «Consulter la lister des points de contact».


A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Consulter la liste des

points de contact». Si l’utilisateur M-Banking d’Attijari Bank choisit de consulter la lister des

points de contact, il peut consulter la liste de toutes les agencesd’Attijari Bank par région et/ou

consulter la liste de tous les DAB d’Attijari Bank

68

La figure 39 illustre le diagramme de séquences du casd’utilisation «Consulter la lister des points

de contact»

3.4 Test





s’authentifier, le client d’Attijari Bank se trouve capable de bénéficier des différents services


La figure 40 illustre l’interface du menu public.

Figure 39: Diagramme de séquences du cas d’utilisation «Consulter la lister des points de contact»

69

La figure 41 illustre l’interface de suivi des cours de devise.

Figure 40 : Interface du menu public

Figure 41 : Interface de suivi des cours de devise

L’interface de consultation de la liste des agences divise en deux:

-La figure 42 illustre l’interfacede consultation des comptes ainsi que le solde de chaque compte.

-La figure 43 illustre l’interface des mouvements du compte approprié.

70

Figure 42: Interface de consultation de la liste des

régions.

Figure 43: Interface de consultation de la liste des

agences.

La figure 44 illustre l’interface d’envoi d’un message pour un abonné.

La figure 45 illustre l’interface permettant d’appeler la banque.

Figure 44 : Interface d’envoi d’un pour un abonné

Figure 45: Interface d’appel

71

4. Conclusion

Le résultat d’un release est un produit livrable au client contrairement au résultat d’un sprint qui

est un produit potentiellement livrable. A la fin de ce chapitre, nous avons réussi à produire un

incrément ayant suffisamment de valeur pour notre client. Dans le chapitre qui suit, notre effort

sera consacré pour produire un nouveau release couvrant les fonctionnalités de gestion de

l’application mobile.

72

Chapitre 4 Développement de l'application

Backoffice

1. Introduction

Notre deuxième release sera composé de quatre sprints. Tout au long de ce chapitre, nous allons

traiter les histoires utilisateurs (User story) de nos sprints pour produire un ensemble d'incréments

potentiellement livrable. Avant de se lancer dans le premier sprint, l'équipe doit définir le but de ce

dernier qui doit être défini en terme métier et non pas en terme technique pour qu'il soit

compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une question

fondamentale «Pourquoi faisons-nous ce sprint?».

2. Sprint 1 : Administration





Objectif : L’administration de l'application Web: gérer les agences, les DAB, les régions

et les abonnés.





Le tableau 14 résume donc le backlog du premier sprint.

73

Tableau 14 : Sprint1 backlog


1

Ajouter une agence En tant qu'administrateur, je veux ajouter une

nouvelle agence afin que mon application soit mise

à jour.

10

2 Modifier les coordonnées

d'une agence.

En tant qu’administrateur, je veux modifier les

coordonnées d'une agence afin que mon application

soit mise à jour.

10

3 Supprimer une agence En tant qu'administrateur, je veux désactiver une

agence afin que mon application soit mise à jour.

10

4 Ajouter un DAB En tant qu'administrateur, je veux ajouter un DAB


10

5 Modifier les coordonnées

d'un DAB.

En tant qu'administrateur, je veux modifier les

coordonnées d'un DAB afin que mon application

soit mise à jour.

10

6 Supprimer un DAB En tant qu'administrateur, je veux désactiver un

DAB afin que mon application soit mise à jour.

10

7 Ajouter un abonné En tant qu'administrateur, je veux ajouter un abonné


10

8 Mettre à jour les

coordonnées d'un abonné

En tant qu'administrateur, je veux mettre à jour les

coordonnées des clients M-Banking (en cas de

changement de mot de passe ou de numéro de tel ou

de nom) afin de faciliter l'accès pour nos clients.

10

9 Supprimer un abonné En tant qu'administrateur, je veux supprimer un


10




travail.




74


Après authentification, l'administrateur se trouve capable de gérer les abonnées, les agences, les

DAB et les régions.

La figure 46 illustre le diagramme de cas d’utilisation global du Sprint 1.

A titre d'exemple, nous détaillons le cas d'utilisation «Gérer les agences» et les autres cas

d'utilisation généralisés suivent le même principe.

Après avoir s'authentifier, l'administrateur de l'application Mobile Banking pourra gérer les

agences. La gestion inclut l'opération d'ajout, de modification des coordonnées et de suppression.

La figure 47 illustre le diagramme de cas d’utilisation «Gérer les agences».

Figure 46 : Diagramme de cas d’utilisation global du Sprint 1

Figure 47 : Diagramme de cas d’utilisation «Gérer les agences»

75


Le tableau 15 décrit textuellement le cas d'utilisation «Gérer les agences»

Tableau 15 : Description textuelle du cas d’utilisation «Gérer les agences»

Cas d’utilisation : Gérer les agences

Acteur : Administrateur M-Banking Attijari Bank

Pré condition : -L’administrateur M-Banking Attijari Bank est identifié comme

étant un administrateur.

Post condition : Une nouvelle agence est ajoutée, modifiée ou supprimée avec

succès.


principal :

-Le système affiche l'interface principale.

-L'administrateur clique sur l'onglet Agences.


-Le client clique sur l'onglet "Agences".

Point d'extension :

Ajouter une agence

-Le système affiche l'interface relative à «Ajouter une agence »

-L'administrateur remplit les champs demandés et clique sur

Enregistrer.

-Le système enregistre les données et affiche un message de

succès.

Point d'extension :

Modifier les

coordonnées d'une

agence

-Le système affiche l'interface relative à «Modifier les

coordonnées d'une agence»


Enregistrer.


succès.

Point d'extension :

Supprimer une

agence

-Le système affiche l'interface relative à «Supprimer une

agence»


Enregistrer.


succès.

2.3 Conception



76

Le diagramme de classes permet de représenter une vue statique du système d’information

[23].Il identifie la structure des classes du système, y compris les propriétés et les méthodes

de chaque classe, et les diverses relations qui peuvent exister entre les classes y sont


Le diagramme de séquences permet de représenter une vue dynamique du système

d’information. [23]. Il permet de décrire les scénarios de chaque cas d'utilisation en mettant


Pour le Sprint 1 «Administration» nous allons présenter les diagrammes de classes et de

séquences de l'opération «Gestion des agences» seulement puisque la gestion des abonnées, des

DAB et des régions suit le même principe.


Le diagramme de classes du cas d’utilisation «Gérer les agences» se traduit par les différentes


La figure 48 illustre le diagramme de classes du cas d'utilisation «Gérer les agences».


A travers ce diagramme, nous décrivons le scénario du même cas d’utilisation. L’administrateur

choisit l'opération à effectuer: Ajouter, supprimer ou modifier les coordonnées d'une agence. Aussi,

il peut effectuer une recherche avancée sur l'agence à modifier ou à supprimer.

La figure 49 illustre le diagramme de séquences du cas d’utilisation «Gérer les agences».

Figure 48 : Diagramme de classes du cas d’utilisation «Gérer les agences»

77

Figure 49 : Diagramme de séquences du cas d’utilisation «Gérer les agences»

78

2.4. Test




Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce Sprint. Commençons par

l’interface principale de la gestion des agences et par la suite nous illustrons les fonctionnalités

d'ajout, de modification et de suppression d'une agence.

La figure 50 illustre l'interface principale de la gestion des agences.

La figure 51 illustre l'opération de suppression d'une agence

Figure 51 : Interface de l’opération de suppression d’une agence

Figure 50 : Interface principale de la gestion des agences

79

La figure 52 illustre l'opération d'ajout d'une agence

La figure 53 illustre l'opération de modification des coordonnées d'une agence

Figure 52 : Interface de l’opération d’ajout d’une agence

Figure 53 : Interface del’opération de modification des coordonnées d’une agence

80

3. Sprint 2: Gestion des demandes transactionnelles (Cartes,

Chéquiers, Virements)





Objectif : Gestion des demandes d'obtention et demandes d'opposition sur les cartes et les

chéquiers. Egalement, la gestion des demandes de virements.





Le tableau 16 résume donc le backlog du deuxième sprint.

Tableau 16 : Sprint 2 backlog


1

Accepter la demande

d'obtention d'une carte

En tant qu'administrateur, je veux accepter la

demande afin de répondre aux demandes des

clients.

10



En tant qu'administrateur, je veux décliner la

demande afin de respecter les conditions

d'obtention d'une carte bancaire.

10



En tant qu'administrateur, je veux supprimer la


10





clients.

10





d'opposition d'une carte.

10





10

81





clients..

10





d'obtention d'un chéquier.

10





10





clients.

10





d'opposition sur chéquier.

10





10

13 Consulter les demandes

d'obtention et d'opposition

de cartes et de chéquiers

En tant qu'administrateur, je veux consulter les

demandes d'obtention ou d'opposition sur

chéquiers ou sur cartes afin de vérifier les

données.

10

14 Accepter la demande de

virement



clients.

10

15 Décliner la demande de

virement


demande afin de respecter les conditions de

virements

10

16 Supprimer la demande de

virement



10


anciens virements

En tant qu'administrateur, je veux consulter les

demandes de virements afin de vérifier les

données.

10

Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un

sprint nous pouvons dégager trois étapes principales qui sont la spécification fonctionnelle, la

conception, et le test. Tout au long de ce sprint, nous respectons ces activités pour construire le

plan de notre travail.

82





Après avoir s'authentifier, l'administrateur se trouve capable de gérer les demandes

transactionnelles des clients de la banque qui sont les demandes d'obtention ou de opposition sur

cartes ou chéquiers et les demandes de virements réalisés par le client.

La figure 54 illustre le diagramme de cas d’utilisation global du deuxième sprint.

Figure 54 : Diagramme de cas d’utilisation globale Sprint2

A titre d'exemple, nous traitons le cas de demandes d'obtention de carte puisque le même scénario

se produit pour les autres cas d'utilisations générés qui sont «Gérer les demandes de chéquiers» et

«Gérer les demandes de virements».

Après authentification, l'administrateur pourra gérer les demandes d'obtention ou d'opposition sur

cartes réalisées par les clients; Il peut soit approuver une demande, si toutes les conditions sont

vérifiées, soit décliner les demandes, si une des conditions n'est pas vérifiée, ou supprimer la

demande si c'était juste une demande de test effectuée par l'équipe de développement. Aussi,

l'administrateur pourra consulter la liste des anciennes demandes déjà traitées.

La figure 55 illustre le diagramme de cas d’utilisation «Gérer les demandes de cartes»

83

Figure 55 : Diagramme de cas d’utilisation «Gérer les demande de cartes»

.


Pour la gestion des cartes, le client a le choix entre effectuer une demande d'obtention ou

d'opposition. A titre d'exemple, notre raffinement se limite du cas d'utilisation généré : «Gérer les

demandes d'obtention».

Le tableau 17 décrit textuellement cas d’utilisation «Gérer les demandes d'obtention»

Tableau 17 : Description textuelle du cas d’utilisation «Gérer les demande d'obtention»

Cas d’utilisation : Gérer des demandes d'obtention


Pré condition : -L’employé d’Attijari Bank est identifié comme étant un

administrateur de l’application web du M-Banking.

Post condition : La table demande carte est mise à jour.


principal :


-L'administrateur choisit l'opération qu'il désire effectuer en

cliquant sur un bouton de commande.

-Le système enregistre les données et affiche l'interface

appropriée.

Points d'extension :

Accepter une demande

-Le système affiche le dialogue relatif à «Accepter une

demande» -L'administrateur traite la demande et enregistre son traitement

-Le système enregistre les données.

84

Décliner une demande -Le système affiche le dialogue relatif à «Décliner une

demande»

-L'administrateur traite la demande et enregistre son traitement


Supprimer une

demande

-Le système affiche le dialogue relatif à «Supprimer une

demande»

-L'administrateur traite la demande et enregistre son traitement


Consulter les

anciennes demandes

-Le système affiche l'interface relative à la consultation des

anciennes demandes.

-L'administrateur peut faire une recherche avancée.

3.3 Conception




d’information.[23]Il identifie la structure des classes du système, y compris les propriétés

et les méthodes de chaque classes, et les diverses relations qui peuvent exister entre les



d’information.[23] Il permet de décrire les scénarios de chaque cas d'utilisation en mettant


Comme déjà expliqué, nous illustrons seulement le cas d'utilisation généralisé «Gérer les

demandes de cartes».


Le diagramme de classes du cas d’utilisation «Gérer les demandes de cartes» se traduit par

les différentes classes participantes à la réalisation de ce dernier.

85

La figure 56 illustrant le diagramme de classes du cas d’utilisation «Gérer les demandes de cartes».

Figure 56 : Diagramme de classes du cas d’utilisation «Gérer les demandes de carte»

86


L'administrateur gère les demandes d'obtention et d'opposition sur cartes ; Dans les deux cas il peut soit accepter une demande, la décliner ou bien la supprimer s'il s'agit d'une demande de test effectuée par l'équipe de

développement. Egalement, l'administrateur peut consulter les demandes qui sont déjà traité auparavant. Et encore il peut effectuer une recherche avancée "La fonction (Saisir)" par code client, nom et d'autres critères.

A titre d'exemple nous illustrons le diagramme de séquence du cas d'utilisation généré «Gérer les demandes d'obtention des cartes ».

Figure 57: Cas d'utilisation généré «Gérer les demandes d'obtention »

87

3.4 Test





s’authentifier, le client d'Attijari Bank se trouve capable de bénéficier des différents services


La figure 58 illustre l’interface de gestion des demandes d'obtention de cartes.

La figure 59 illustre l'interface de la consultation des demandes cartes (demandes qui sont déjà

traitées).

Figure 58 : Interface de la gestion des demandes d’obtention

Figure 59 : Consultation des demandes de cartes

88

4. Sprint 3: Gestion des contacts





Objectif : La gestion de contacts qui inclut la gestion des messages envoyés par les clients

et des demandes de rendez-vous.





Le tableau 18 résume donc le backlog du troisième sprint

Tableau 18 : Sprint 3 backlog


1

Confirmer la demande de

rendez-vous


demande afin d'organiser les visites des clients

à l'agence.

10


anciens rendez-vous

En tant qu'administrateur, je veux consulter la

liste des anciens rendez-vous afin de vérifier

les données.

10

3 Confirmer la réception d'un

message

En tant qu'administrateur, je veux confirmer la

réception d'un message afin que la réclamation

ou la suggestion du client soit prise en compte.

10


messages archivés

En tant qu'administrateur, je veux consulter la

liste des messages archivés afin de vérifier les

données

10

Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un Sprint


et le test. Tout au long de ce Sprint, nous respectons ces activités pour construire le plan de notre

travail.

89





Après avoir s'authentifier, l'administrateur pourra gérer les demandes de contact effectuées par les

abonnés qui sont une demande de rendez-vous ou un envoi de message dans le but de réclamer ou

de suggérer. Ces deux moyens de contact doivent être gérer par l’administrateur.

La figure 60 illustre le diagramme de cas d’utilisation global du troisième Sprint..


Les tableaux suivants présentent la description textuelle des cas d'utilisation générés du cas

«Gestion des contacts»

Le tableau 19 décrit textuellement le cas d'utilisation «Gérer les demandes de rendez-vous»

Figure 60 : Diagramme de cas d’utilisation global Sprint3

90

Tableau 19 : Description textuelle du cas d’utilisation «Gérer les demandes de rendez-vous»

Cas d’utilisation : Gérer les demandes de rendez-vous


Pré condition : -Administrateur M-Banking Attijari Bank est identifié comme


Post condition : Les demandes de rendez-vous sont traitées.


principal :


-L'administrateur traite la demande et confirme son traitement.

Point d'extension :

Consulter la liste des

anciens rendez-vous

-Le système affiche l’interface relative à «Consulter la liste

des anciens rendez-vous»

Le tableau 20 décrit textuellement le cas d'utilisation «Gérer les messages»

Tableau 20 : Description textuelle du cas d'utilisation «Gérer les messages»

Cas d’utilisation : Gérer les messages


Pré condition : - Administrateur M-Banking Attijari Bank est identifié comme


Post condition : -Les messages sont bien reçus.


principal :


-L'administrateur choisit l'opération qu'il doit effectuée en

cliquant sur un bouton de commande

Point d'extension :

Confirmer les demandes

de rendez vous

-Le client traite la demande de rendez vous du client et

enregistre les modifications.


Consulter la liste des

anciens rendez-vous

-Le système affiche l’interface relative à «Consulter la liste

des messages archivés»

4.3 Conception




d’information.[23].Il identifie la structure des classes du système, y compris les propriétés

91

et les méthodes de chaque classes, et les diverses relations qui peuvent exister entre les



d’information.[23].Il permet de décrire les scénarios de chaque cas d'utilisation en mettant




Le diagramme de classes du cas d’utilisation «Gestion de contacts» se traduit par les différentes



Figure 61 : diagramme de classe du cas d’utilisation «Gestion des contacts»

92

A titre d'exemple nous illustrons le diagramme de séquence de«Gérer les rendez-vous » puisque

c'est le même principe que celui de la gestion des messages.

Après authentification, l'administrateur aura accès à l'interface de gestion des rendez-vous où il

pourra soit confirmer la demande de rendez-vous dans l'une des dates proposés par le client ou

proposer une autre date selon la disponibilité du chargé clientèle de son agence, soit supprimer la

demande et contacter le client par téléphone. D'autre part, l'administrateur peut consulter la liste

des anciens rendez-vous. Dans les deux cas, il peut faire une recherche avancée pour faciliter sa

tâche.

La figure 63 illustre le diagramme de séquences du cas d’utilisation «Gérer les messages».

93

Figure 62 Diagramme de séquences du cas d’utilisation «Gérer les messages»

94

4.4 Test





s’authentifier, l'administrateur de l'application «Attijari Mobile Banking» pourra gérer les

demandes de contact comme expliquer au début de notre sprint 3.

La figure 63 illustre l'interface de gestion de la liste des rendez-vous

La figure 64 illustre l'interface de gestion des rendez-vous

Figure 63 : Interface de la gestion de la liste des rendez-vous

Figure 64 : Interface de la gestion des rendez-vous

95

5. Conclusion

Le résultat d’un release est un produit livrable au client contrairement au résultat d’un sprint qui

est un produit potentiellement livrable. A la fin de ce chapitre, nous avons réussi à produire un

incrément ayant suffisamment de valeur pour notre client. Cet incrément est notre produit final et

donc la fin de ce release marque la fin de notre projet.

96

Chapitre 5 Codage et déploiement

1. Introduction

Dans ce chapitre, nous donnerons un aperçu sur le travail accompli au niveau de

l’implémentation des deux modules M1 (Front Office) et M2 (Back Office) définis dans les

chapitres précédents. Plus précisément, nous allons présenter les diagrammes de composant et

de déploiement de ces deux derniers, ainsi qu’un diagramme de classes global de toute

l’application suivi du schéma de la base de données.

2. Codage

Les travaux menés dans cette étape résument tout simplement dans l’implémentation et la

réalisation des histoires utilisateurs analysés lors des étapes précédentes. Pour notre cas, le

codage se traduit par un diagramme de composants pour chaque module, un diagramme de

classes global de toute l’application et un schéma de la base de données.

2.1 Diagramme de composants

«Le diagramme de composants représente les concepts connus de l’exploitant pour installer et

dépanner le système. Il s’agit dans ce cas de déterminer la structure des composants

d’exploitation que sont les librairies dynamiques, les instances de bases de données, les

applications, les objets distribués, les exécutables, etc…» [24].

Dans ce qui suit, nous allons commencer par présenter le diagramme de composants de chaque

module.

2.1.1 Diagrammes de composants de M1

Les classes d'interfaces et les classes contrôleurs au niveau conceptuel deviennent, au niveau

d'implémentation, les mêmes classes d'interface.Dans notre cas, le contrôleur est le couple

(class.java et webService.PHP).

La figure 88 illustre le diagramme de composants du module M1.

97

2.1.2 Diagrammes de composants de M2

Pour des raisons d'implémentation, le contrôleur dans notre cas est un fichier .XML, le modèle

est un fichier .java qui est le managedBean.

La figure 66 illustre le diagramme de composants du module M2

Figure 65 : Digramme de composants du module M1

Figure 66 : Diagramme de composants du module M2

98

2.2 Diagramme de classes global de l’application

Figure 67 : Diagramme de classe global de l’application

99

2.3 Schéma de la base de données

Pour construire le schéma de base de données de notre application, nous devons appliquer

certaines règles pour passer d’un schéma entité association (diagramme de classe) vers un

schéma relationnel {Voir Annexe A}.

Dans ce qui suit, nous présentons les tables de notre base de données.

Tableau 21 Table « abonne »

Nom de la table : abonne

Champs Types Contraintes

id_abonne VARCHAR(10) PRIMARY KEY

Nom VARCHAR(255) ---

Prenom VARCHAR(255) ---

password_abonne VARCHAR(255) ---

code_abonne VARCHAR(255) ---

Tel VARCHAR(255) ---

Mail VARCHAR(255) ---

id_mobile VARCHAR(255) ---

Typdoc VARCHAR(20) ---

Numdoc VARCHAR(15) ---

Tableau 22 : Table « region »

Nom de la table : region

Types Contraintes Contraintes

code_region VARCHAR2(3) PRIMARY KEY

Langue VARCHAR2(255) ---

titre_region VARCHAR2(255) ---

100

Tableau 23: Table « client »

Nom de la table : client


Codclt VARCHAR2(8) PRIMARY KEY

Nom VARCHAR(30) ---

Prenom VARCHAR(30) ---

Tel VARCHAR(20) ---

Mail VARCHAR(30) ---

typdoc VARCHAR(20) ---

numdoc VARCHAR(15) ---

Tableau 24 : Table « compte »

Nom de la table : compte


nucmpt VARCHAR2(13) PRIMARY KEY

clebct VARCHAR2(2) PRIMARY KEY

codugbct VARCHAR2(3) PRIMARY KEY

codbanq VARCHAR2(2) PRIMARY KEY

typdoc VARCHAR2(20) ---

numdoc VARCHAR2(15) ---

Nom VARCHAR2(255) ---

prenom VARCHAR2(255) ---

datclo DATE ---

adressecpt VARCHAR2(255) ---

Sin VARCHAR2(255) ---

101

Tableau 25 : Table « agent »

Nom de la table : agent


matricule VARCHAR(5) PRIMARY KEY

idnom NUMBER(10) ---

Pwd VARCHAR2(100) ---



Telph VARCHAR2(50) ---

telph_poste VARCHAR2(50) ---

Mail VARCHAR2(100) ---

adresse VARCHAR2(254) ---

date_embauche DATE ---

Cout NUMBER(3) ---

authority VARCHAR(50) ---

flg_suspendu NUMBER(1) ---

Tableau 26 : Table «parametre»

Nom de la table : parametre


codparam VARCHAR2(10) PRIMARY KEY

libparam VARCHAR2(255) ---

valparam VARCHAR2(255) ---

102

Tableau 27 : Table «agence»

Nom de la table : agence


Codug VARCHAR2(3) PRIMARY KEY

nom_ug VARCHAR2(255) ---

adresse_ug VARCHAR2(255) ---

altitude_ug NUMBER ---

longitude_ug NUMBER ---

zoom_ug NUMBER ---

tel_ug VARCHAR2(255) ---

fax_ug VARCHAR2(255) ---

type_oper VARCHAR2(1) ---

date_oper DATE ---

user_oper VARCHAR(5) ---

Tableau 28 : Table «DAB»"

Nom de la table : DAB


Code_dab VARCHAR2(3) PRIMARY KEY

nom_dab VARCHAR2(255) ---

adresse_dac VARCHAR2(255) ---

altitude_dab NUMBER ---

longitude_dab NUMBER ---

zoom_dab NUMBER ---


date_oper DATE ---

user_oper VARCHAR(5) ---

103

Tableau 29 : Table «dde_carte»

Nom de la table dde_carte


id_dde_carte VARCHAR2(10) PRIMARY KEY

type_carte VARCHAR2(5) ---

date_oper DATE ---

user_oper VARCHAR2(5) ---


date_valid DATE ---

user_valid VARCHAR2(1) ---

etat_demande VARCHAR2(1) ---

date_demande DATE ---





Tableau 30 : Table «mouvement»

Nom de la table : mouvement


Codop VARCHAR2(10) PRIMARY KEY

Libop DATE ---

sensop VARCHAR2(255) ---

Datop DATE ---

Dag DATE ---

mntop VARCHAR2(255) ---

104

Tableau 31 : Table «dde_cheq»

Nom de la table : dde_cheq


id_dde_cheq VARCHAR2(10) PRIMARY KEY

type_cheq VARCHAR2(255) ---

date_oper DATE ---



date_valid DATE ---

user_valid DATE ---



Tableau 32 : Table « de_op_carte»

Nom de la table : dde_op_carte


id_op_carte VARCHAR2(10) PRIMARY KEY

date_oper DATE ---



date_valid DATE ---

user_valid DATE ---



105

Tableau 33 : Table «dde_op_cheq»

Tableau 34 : Table «chequier»

Nom de la table : chequier


numchequier VARCHAR2(10) PRIMARY KEY

datelivraison DATE ---

numdebut VARCHAR2(255) ---

numfin VARCHAR2(255) ---

type_cheq VARCHAR2(255) ---

etat_chequier VARCHAR2(255) ---

Nom de la table : dde_op_cheq


id_op_cheq VARCHAR2(10) PRIMARY KEY

date_oper DATE ---



date_valid DATE ---

user_valid DATE ---



description VARCHAR2(255) ---

106

Tableau 35 : Table «dde_vir»

Nom de la table : dde_vir


id_dde_vir VARCHAR2(10) PRIMARY KEY

numcpt_ben VARCHAR2(13) ---

numcpt_don VARCHAR2(13) ---

codugbct_ben VARCHAR2(3) ---

codugbct_don VARCHAR2(3) ---

codug_ben VARCHAR2(3) ---

codug_don VARCHAR2(3) ---

codbanq VARCHAR2(2) ---

codbanq VARCHAR2(2) ---

clecbt_ben VARCHAR2(13) ---

clecbt_don VARCHAR2(13) ---

mnt_vir VARCHAR2(255) ---

lib_vir VARCHAR2(255) ---

date_vir DATE ---

date_oper DATE ---



date_valid DATE ---

user_valid DATE ---



107

Tableau 36 Table «message»

Nom de la table : message


id_envmsg VARCHAR2(10) PRIMARY KEY

nom VARCHAR2(255) ---


Tel VARCHAR2(255) ---

email VARCHAR2(255) ---

message VARCHAR2(255) ---



type_user VARCHAR2(1) ---

date_oper DATE ---



date_valid DATE ---

user_valid VARCHAR(15) ---



108

Tableau 37 : Table «cheque»

Nom de la table : cheque


numchq VARCHAR2(10) PRIMARY KEY

datecheq DATE ---

etatcheq VARCHAR2(255) ---

mntcheq VARCHAR2(255) ---

nombenef VARCHAR2(255) ---

dateopp DATE ---

Tableau 38 : Table «typcarte»

Nom de la table : typcarte


codtypcarte VARCHAR2(10) PRIMARY KEY


date_oper DATE ---



observation VARCHAR2(255) ---

nature VARCHAR2(255) ---

plancher VARCHAR2(255) ---

bin_carte VARCHAR2(255) ---

109

Tableau 39 : Table «rendezvous»

Nom de la table : rendezvous


id_dde_rendv VARCHAR2(10) PRIMARY KEY



Tel VARCHAR2(255) ---

email VARCHAR2(255) ---

plage_horaire VARCHAR2(255) ---

message VARCHAR2(255) ---



date_rendv1 DATE ---

date_rendv2 DATE ---

type_user VARCHAR2(1) ---

date_oper DATE ---



date_valid DATE ---

user_valid VARCHAR2(15) ---



110

Tableau 40 : Table «carte»

Nom de la table : carte


num_carte VARCHAR2(10) PRIMARY KEY






dateopp DATE ---

mntreatrait VARCHAR2(255) ---

mntpaie VARCHAR2(255) ---

mntdebit VARCHAR2(255) ---

etat_carte VARCHAR2(255) ---

3. Déploiement

Pour notre cas, le déploiement se traduit par un diagramme de déploiement qui permet de

représenter la répartition géographique des composants matériels de notre système sous forme de

nœuds.

3.1 Diagramme de déploiement de M1

L'utilisateur M-Banking demande une ressource auprès de son équipement Android. Ceci se traduit

par une requête HTTP GET ou POST qui sera envoyée à travers des web services PHP au serveur

de la base de données. La réponse finale est renvoyée au serveur de l'application mobile sous forme

d'un fichier JSON.

111

3.2 Diagramme de déploiement de M2

L'utilisateur demande une ressource auprès de son ordinateur. Ceci se traduit par une requête HTTP

qui sera envoyée au serveur de l'application. Ce dernier fournit la ressource, mais en faisant appel

à un autre serveur qui est le serveur de la base de données.

4. Conclusion

Au cours de ce chapitre, nous avons essayé de donner une meilleure visibilité du projet sur le plan

technique, mettre en place le schéma de la base de données et présenter diagramme de déploiement

des deux modules de l’application globale.

Figure 68 : Diagramme de déploiement de M1

Figure 69 : Diagramme de déploiement de M2

112

Conclusion et perspective

Les Smartphones sont devenus les accompagnantes indispensables de l’homme. Ceci est dû

principalement à la mise au point de multitude d’applications mobiles qui couvrent beaucoup de

secteurs, et parviennent même à satisfaire quelqu’un de nos besoins quotidiens.

C’est en considération de ce cadre qu’il nous a été confié de réaliser, au sein d'Attijari Bank, une

application de Mobile Banking sous Android qui constitue le Front office et une application Web

qui constitue, à son tour, le back office. Les études conceptuelles et techniques, ainsi que les

différentes étapes qui ont abouti à la réalisation de notre solution, ont fait l’objet des chapitres de

ce rapport.

Ce stage représente pour nous une opportunité irremplaçable, qui nous apermis de participer à un

projet d’envergure, de faire face aux contraintes réelles de l’entreprise, et de vivre les différentes

phases clés du développement et la production d’un logiciel.

Pour accomplir ce travail, nous avons adopté les méthodes agiles et plus précisément Scrum pour

la gestion de projet, UML est désormais notre langage de modélisation en utilisant le logiciel

Rational Rose. L'application mobile est développée en langage JAVA sous éclipse Luna et

l'application web enJ2eesous MyEclipse. D'autre part, nous avons développé des web services PHP

permettant de gérer la connexion avec le serveur de base de données. Afin de créer la base de

données, un système de gestion de base de données ORACLE a été exploité.

Ces choix nous ont permis de réaliser une application complète répondant aux attentes de

l’entreprise pour laquelle nous avons œuvré.

À l’issue de ce projet, nous pouvons envisager les perspectives suivantes :

Multilinguisme de l'application.

Gestion des habilitations pour les administrateurs de l'application web.

Augmenter le niveau de sécurité de l'application en utilisant le principe de Code QR .

Améliorer le design de l'application mobile.

113

Annexe A

Passage d’un schéma Entité/Association à un Schéma Relationnel

La déduction du schéma relationnel se base sur un ensemble de règles qui sont présentées comme

suit :

Règle 1 : Toute entité devient une table.

Règle 2 : Chaque propriété de l’entité devient un attribut de la table.

Règle 3 : L’identifiant de l’entité devient une clé primaire de la table

Règle 4 : Chaque association « un à plusieurs » est représentée par une clé étrangère dans la table

fille.

Règle 5 : Chaque association devient une relation, si les cardinalités maximales sont «n..n»

Règle 6 : Chaque association «1..1» est représentée par l’intégration d’une clé étrangère dans la

table la moins récente.

Règle 7 : Chaque classe association entre deux classes est représentée par une table qui prend pour

clé primaire la concaténation des clés primaires des deux classes.

114

Neto graphie

[1]Site internet «SeanRon», DeveloppemtEtDesign,

Available:http://seanron.free.fr/?article7/la-methode-agile-scrum-et-extreme-programming

[2] MazziveBlog, Available:http://mazzive.com/blog/?p=12

[3]ABI Research, Available: https://www.abiresearch.com/press/2q-2014-smartphone-results-

forked-android-aosp-gro/

[4]UNIVERSITE VIRTUELLE DE TUNIS (uvt), rapport de PFE «Conception et réalisation

d'une application mobile M-Banking», Available : http://pf-mh.uvt.rnu.tn/803/1/Conception-

realisation-application-mobile-M-BANKING.pdf

[5]Oracle's Developper Guide,

Available:http://otndnld.oracle.co.jp/document/products/as10g/101300/B25221_03/web.1013/b1

3593/undtldev010.html

[6]Site Personnel: Gradeux Vincent, de Gradeux Vincent, Available:http://gardeux-

vincent.eu/Documents/ProjetJEE/BACSWW_Hibernate_Jaxb_Spring/content/spring.html

[7] Site officiel du Spring, Cours de Spring Security Avalaible:http://projects.spring.io/spring-

security/

[8]Site: SlideShare.net, Available: http://fr.slideshare.net/cagataycivici/primetime-jsf-with-

primefaces-dec-2014

[9]Site Journal du net, Available:

http://www.journaldunet.com/encyclopedie/definition/972/34/20/tomcat.shtml

[10] Wikipedia, http://fr.wikipedia.org/wiki/Rational_Rose

[11]Wiki du Fablab Robert Houdin, Available:

http://fablab-robert-houdin.org/wiki/doku.php?id=tuto_installation_de_eclipse

[12]Site Personnel: Gradeux Vincent, de Gradeux Vincent, Available: http://gardeux-

vincent.eu/Documents/ProjetJEE/BACSWW_Hibernate_Jaxb_Spring/content/hibernate/hibernat

e_3.html

[13]Wikipedia, Available: http://fr.wikipedia.org/wiki/Java_Development_Kit

http://mazzive.com/blog/?p=12

https://www.abiresearch.com/press/2q-2014-smartphone-results-forked-android-aosp-gro/

https://www.abiresearch.com/press/2q-2014-smartphone-results-forked-android-aosp-gro/

http://pf-mh.uvt.rnu.tn/803/1/Conception-realisation-application-mobile-M-BANKING.pdf

http://pf-mh.uvt.rnu.tn/803/1/Conception-realisation-application-mobile-M-BANKING.pdf

http://otndnld.oracle.co.jp/document/products/as10g/101300/B25221_03/web.1013/b13593/undtldev010.html

http://otndnld.oracle.co.jp/document/products/as10g/101300/B25221_03/web.1013/b13593/undtldev010.html

http://gardeux-vincent.eu/Documents/ProjetJEE/BACSWW_Hibernate_Jaxb_Spring/content/spring.html

http://gardeux-vincent.eu/Documents/ProjetJEE/BACSWW_Hibernate_Jaxb_Spring/content/spring.html

http://fr.slideshare.net/cagataycivici/primetime-jsf-with-primefaces-dec-2014

http://fr.slideshare.net/cagataycivici/primetime-jsf-with-primefaces-dec-2014

http://www.journaldunet.com/encyclopedie/definition/972/34/20/tomcat.shtml

http://fr.wikipedia.org/wiki/Rational_Rose

http://fablab-robert-houdin.org/wiki/doku.php?id=tuto_installation_de_eclipse

http://fr.wikipedia.org/wiki/Java_Development_Kit

115

[14]Site «Zeste de savoir», Available: https://zestedesavoir.com/tutoriels/335/creez-des-

applications-pour-android/420/les-bases-indispensables-a-toute-application/2135/installation-et-

configuration-des-outils/#3-eclipse-ladt-et-le-sdk

[15]Wikipedia, Available: http://fr.wikipedia.org/wiki/Oracle_Database

[16]Site officiel WampServer, Available : http://www.wampserver.com/

[17]Site: Futur, Available: http://www.futura-sciences.com/magazines/high-

tech/infos/dico/d/internet-java-485/

[18]Site officiel du groupe «AddiTeam», Available: http://www.additeam.com/SSII/php/

[19]Pierre Gambarotto «Technologies pour Web Services faciles : REST, JSON», Available:

https://2009.jres.org/planning_files/article/pdf/92.pdf

[20]Site: Figer.com, REST, un style d'architecture universel, , Par: Jean-Paul Figer,

Available: http://www.figer.com/publications/REST.htm#.VWCsPU9_Okq

[21]Site officiel du groupe «AddiTeam», Available: http://www.additeam.com/SSII/uml/

[22]Site MemoireOnLine, Informatique et télécommunication, Par Alain CHIKURU

MUGISHO,Available:http://www.memoireonline.com/10/12/6148/m_Conception-dune-

application-web-de-suivi-des-passagers-sur-tous-les-vols-nationaux-et-internation14.html

[23]Tarak Chaari «Atelier UML», Available :

http://www.redcad.org/members/tarak.chaari/cours/coursUML.pdf

[24]Pascla Roques, Franck Vallée «UML2 De l’action à l’analyse des besoins à la conception»

https://zestedesavoir.com/tutoriels/335/creez-des-applications-pour-android/420/les-bases-indispensables-a-toute-application/2135/installation-et-configuration-des-outils/#3-eclipse-ladt-et-le-sdk



http://www.wampserver.com/

http://www.futura-sciences.com/magazines/high-tech/infos/dico/d/internet-java-485/

http://www.futura-sciences.com/magazines/high-tech/infos/dico/d/internet-java-485/

http://www.additeam.com/SSII/php/

https://2009.jres.org/planning_files/article/pdf/92.pdf

http://www.additeam.com/SSII/php/