Vous êtes sur la page 1sur 27

INSTITUT DE HAUTE ETUDE COMMERCIAL DE

CARTHAGE

Rapport de projet de fin d’études pour


l’obtention de licence appliquée en informatique
de l’administration des affaires

Sujet : Conception et développement d’une application


web «Workflows » au Qatar national Bank (QNB)

Réalisé par :
Redissi Fatma & Sboui Marwa

Encadré par :
Mme.Lâabidi Maroua (IHEC)
Mme.Fenina Miriem (QNB)

Année Universitaire 2014/2015


ANNEE : 2014/2015

THEME : Informatique de l’Administration des Affaires

Titre : Conception et développement d’une application web « Workflow » de QNB

Auteurs: Redissi Fatma ; Sboui Marwa

Etablissement Universitaire: IHEC Carthage

Encadrant :Lâabidi Maroua

Encadrant : Fenina Miriem

Organisme PFE: QNB
Dédicaces
Remerciements
Table des matières
Introduction Générale :
De nos jours, l'utilisation croissante des systèmes de gestion de workflow dans les
entreprises exprime leur importance indéniable comme outil d'automatisation de leurs
procédés. Les systèmes de gestion de workflow sont parmi les systèmes les plus élaborés
pour définir et exécuter des opérations . Ils permettent, en particulier, de décrire
explicitement les méthodes de travail réalisant un tache , de les expérimenter, de mesurer
leurs qualités et de les optimiser a fin de pouvoir assurer l'amélioration et la réutilisation des
informations.

En plus , les entreprises entrent dans l'ère du e-business et pour rester compétitives, elles
doivent améliorer constamment leur efficacité opérationnelle. 
Un workflow performant et facile d’utilisation permettant à la fois l’automatisation et la
dématérialisation des différents processus métiers de la banque avec notamment la
possibilité d’attacher et de visualiser les documents numérisés, la circulation des
informations et des documents entre les différents acteurs et les différentes départements
se faisant de façon électronique. Donc ,le workflow permet de formaliser, de structurer,
d'automatiser et d'exécuter ces méthodes de travail

le Workflow apporte la solution efficace pour: 


- Modéliser les procédures de travail
- Contrôler et suivre l'avancement des projets 
- Automatiser la circulation des documents
Chapitre 1 : Présentation générale
1. Introduction:
En premier lieu, nous présentons l’organisme d’accueil, dans lequel le projet a été effectué ainsi que
la problématique et les objectifs de ce dernier. Et enfin On termine avec la solution proposée.

2. Présentation de la Qatar National Bank « QNB » :


2.1 Historique
La « TQB » à été créé en 1982 au terme d’une convention signée le 3 mars 1982 entre l’Etat du Qatar
et la République Tunisienne. Son capital est partagé à égalité entre le gouvernement de l’Etat du
Qatar et le gouvernement Tunisien. A la création da la « TQB » son rôle était principalement
l’élaboration, la réalisation et le financement des projets (industrie, tourisme, agricole, immobilier…)
considérés comme étant économiquement viables et financièrement rentable…

De 2004 à 2008, cinq agence virent le jour , la banque n’en comptait pas plus au regard de
ses origines. De 2004 à 2010, le rythme de création n’excédait pas une agence par an. Au
cours des trois dernières années, de 2011 à fin 2013, il se créait une agence tous les deux
mois. En 2014, il est prévu l’ouverture de 12 nouvelles agences, soit une moyenne d’une
agence par mois. Selon le plan stratégique nouvellement mis en oeuvre, la banque comptera
45 agences à l’horizon 2017.

Ces chiffres ne sont pas le fruit du hasard , ils traduisent et expriment en surface les
mutations et les changements de la physionomie et de la sociologie du capital de la banque.
Celles-ci connurent plusieurs inflexions : en 2008, l’Etat qatari cède ses parts 50% du
capital à la QNB. Il y a alors comme un air de gouvernance au parfum plus délié, qui
stimula les ardeurs de la banque cinq ans plus tard, la banque fit un nouveau pas vers une
plus grande cohérence managériale. Au printemps 2013, la QNB rachète, à la suite d’un
appel d’offres internationale. Au printemps 2013, la QNB rachète, à la suite d’un appel
d’offres international, les 50% restants formant la part de l’Etat tunisien. La banque prit
alors un nouvel envol en passant le giron de la prestigieuse Qatar National Bank (QNB).
2.2 Vision
Pour devenir un MENA « Middle East and North Africa » Icône.

2.3 Mission
QNB a pour missions :

 Constituer l’institution de choix pour les clients, employés, investisseurs et fournisseurs.


 Constituer l’intervenant dominant sur le marché.
 Maintenir une notation de crédit la plus élevée.
 Avoir une notoriété de la marque et une valeur de la marque.
 Réaliser une croissance rentable soutenue.
 Renforcer la valeur pour l’actionnaire.

2.4 L'organigramme de la Banque


................
3. Problématique:
L’entreprise pense qu’il y a une perte de temps et d’argent dans les déplacements entre les
différentes structures puisque la gestion des opérations bancaires implique de nombreux documents
papier circulant entre beaucoup d'utilisateur , l'échange des documents entre agence et siège fais
perdre beaucoup du temps et on se trouve face à plusieurs problèmes on cite :

- L'entassement des documents.


- le risque de perte des documents.
- Gaspillage du temps.

Donc , avec cette application il n’y aura plus de distance .

4. Objectifs
L’objectif de ce projet de fin d’étude est de mettre en place une application web "Workflows" interne
pour Qatar Notionnel Bank afin de bénéficié du :

-Gain de temps.
-Limitations des voyages/déplacements.
-Amélioration de la collaboration entre les employés .
-Coordination entre les différentes filières .

Grace à cette application web il aura une amélioration de l’environnement de travail. Les employées
peuvent désormais envoyer des documents aux autres partenaires sans se déplacer. L'accès au
l'historique est possible pour le CSO.

5. Solution proposé
Afin de palier aux défaillances observé, nous proposons d’informatiser les documents des différentes
opérations bancaires par une application afin d’éviter l'échange des documents, et assure une
certaine cohérence des données, pour rester compétitives, elles doivent améliorer constamment leur
efficacité opérationnelle.  Le Workflow apporte la solution efficace pour: 
- Modéliser les procédures de travail.
- Contrôler et suivre l'avancement des opérations .
- Automatiser la circulation des documents.
-Archiver les documents .

6. Conclusion
Au niveau de ce chapitre nous avons présenté brièvement le cadre général de notre projet à
savoir QNB qui nous a accueilli et qui nous a demander de réaliser cette application.

Dans ce qui suit, nous allons présenter les besoins fonctionnels et non fonctionnels ainsi que les cas
d’utilisation de notre projet.
Chapitre2 :Analyse des besoins et spécifications
1. Introduction 
La phase de spécification est une étape importante dans le déroulement d’un projet. Elle permet de
se fixer les idées sur les besoins du projet et les contraintes qui l’entourent. Au cours de cette phase,
nous commençons par une description de spécification des exigences fonctionnelles sous de cas
d’utilisation, suivi par une deuxième section pour l’illustration des exigences non fonctionnelles.

2. Spécifications des exigences et des acteurs


Dans cette partie nous allons définir les acteurs qui vont interagir avec l’application, et identifier les
exigences fonctionnelles de cette dernière.

2.1 Identification des acteurs


Département Branch

CSO , Branch Manager .

 CSO :

Il est responsable de Choisir l'opération bancaire , saisir Num compte et Nom, ajouter les documents,
envoyer aux acteurs concernés (selon l'opération bancaires ) et archivage des documents
(maintenance et suivi des opération ) .

 Users:

Ensembles des employées qui vont gérés les documents envoyer par le CSO . Les droits d'accès sont
réparti selon les opérations bancaires et selon le département :

 Département Operation : Bco_Officer , Bco_Manager , COD _Officer , CLD_Authonizer .


 Département Risk : Credit_Analyst , Head_Of_Retail, CLD_Officer.

2.2 Expression des besoins fonctionnels


Dans cette section du chapitre, nous nous intéressons aux besoins des utilisateurs à travers les
spécifications fonctionnelles et non fonctionnelles pour aboutir à une application de qualité selon les
besoins interne de la banque.

Besoin non fonctionnel :

 Interface Homme-Machine: Il faut prévoir une accessibilité rapide aux différentes


fonctions 2 clics de souris au maximum pour chaque fonctionnalité. Facilité de
navigation entre les rubriques.
 Contraintes d'exploitation: L'application devra être accessible que pour le CSO et le
Branch Manager dans l'agence .Le Branche Manager doit pouvoir avoir un accès à
l'historique.
 Ergonomie des interfaces : Le système doit offrir une interface conviviale et
ergonomique exploitable par l'utilisateur.
 Sécurité : Le système doit être sécurisé, avec un droit d’accès selon l'utilisateur.
 Fiabilité : Le système doit assurer de manière continue les services attendus.
 Robustesse: Le système doit fonctionner même dans des conditions anormales.
Besoins fonctionnels :

Notre application doit permettre certaines fonctionnalités de base qui seront utiles par la suite dans
des extensions de la solution proposée pour une application web de Workflow . Nous citons dans ce
qui suit les différentes fonctionnalités qui seront assurées par l’application.

Afin de simplifier la compréhension de notre système, ont va présenté quelques diagrammes de cas
d’utilisation.

3. Diagramme de cas d'utilisation


3.1 Diagramme de cas d’utilisation général relatif au CSO
Après s’être connecté le CSO peut Choisir l'opération bancaire , saisir Num compte et Nom, ajouter
les documents, envoyer aux acteurs concernés (selon l'opération bancaires ) et archivage des
documents (maintenance et suivie du système) .

Figure 3: Diagramme de cas d'utilisation général relatif au CSO


Dans le diagramme de cas d’utilisation représenté par la Figure 3, nous mettons le point sur
les besoins fonctionnels les plus importants .
 vérification l'existence du client :

Le CSO doit vérifier l'existence du client à travers le saisie des informations relative aux clients (Num
compte& Nom), si le client existe alors le système renvoi un formulaire remplie par les cordonnées
relative du client, sinon retour au page d’accueil.

 Ajouter les documents :

La déposition des documents se traduit par l'ajout des documents, ainsi que la modification et la
suppression des documents par CSO.

 Archivage :

Le CSO archive les documents pour l’utiliser plus tard en cas de nécessiter .

3.2 Raffinement du CU « Choisir l’opération bancaire » :


Cette tâche regroupe ensemble des opérations bancaires : Etablissement des comptes , transfert ,
établissement des crédits , dépôt à terme .

Figure 4 : Raffinement du CU « Choisir l’opération bancaire»


3.3 Raffinement du CU "Vérification l'existence du client ":

Figure 5 : Raffinement du CU «Vérification l'existence du clients»

3.4 Raffinement du CU "Déposer les documents ":


Consiste à :

 Ajouter les documents : Le CSO ajoute les documents nécessaire pour envoyer au acteurs
concernés
 Supprimer les documents: Le CSO supprime des documents indésirables (irrespectueuse,
insolite, etc…)
 Modifier les documents: Le CSO modifie les documents en cas de manque des documents
dans le dossier

Figure 6 : Raffinement du CU «Déposer les documents»

Tableau1 : Description du CU "Déposer les documents":


Cas d’utilisation :  Déposer les documents

Acteur :  CSO

Pré condition :  Client existe

Post condition :  Documents déposer

Description du scenario  Ajouter documents


 CSO clique sur le bouton ‘Ajouter’.
principal :
 CSO ajout les documents.
 le système verifie le type de document .
 le système télécharge les documents sur
le serveur .
 CSO archive les documents .
 Le système vérifie l'ajout et met la base
de données à jour.
 Envoyer les documents aux acteurs
concernés.

 En cas de Suppression
 CSO choisit le document à supprimer.
 CSO clique sur le bouton ‘Supprimer’.
 Le système affiche un message
d’avertissement pour valider la
suppression.
 Le système vérifier la saisie et enregistre
la modification des informations dans la
base.
 En cas de Modification
 CSO choisit le rapport à modifier.
 CSO saisie les nouvelles informations.
 CSO clique sur le bouton ‘Modifier’.
 Le système vérifie la saisie et enregistre
la modification des informations dans la
base.

Exception :  Cas d’Ajout :


 Si le rapport existe déjà, le système
affiche un message d’erreur.
 En cas de Suppression ou de
Modification :
 Si un problème de suppression ou de
modification apparaitra, le système
affiche un message d’erreur.

Tableau 2 : Description du CU « Envoyer les documents »:

Cas d’utilisation :  Envoyer les documents

Acteur :  CSO

Pré condition :  Documents scanner

Post condition :  Documents scanner

Description du scenario  CSO clique sur le bouton ‘Submit’.


 CSO valide l'action d’envoi.
principal :
 le système envoi les documents au
acteur selon l’opération bancaire.
 le système envoi un message de
confirmation.

Exception :  Sécurité : les accès doivent être


extrêmement sécurisés.

3.5 Diagramme du cas d'utilisation User « Gérer les documents »:

 Gérer les documents :


Notre application permettre aux acteurs l’échange des documents et la consultation des documents
selon l'opération bancaire par Users .

Prise de décision (Aprove, Reject, Return User).

- En cas « Aprove  » l’opération va être validée (par l'acteur concerné selon l'opération) .

- En cas « Reject » l’opération va être refusée.

- En cas «Return User » manque d’information donc il va être transmis au CSO pour le
modifier.

 Outlook :

L'application doit intégrer un forum de discussions(Outlook) afin de permettre aux acteurs


d’échanger les documents entre eux.

Figure 7 : Diagramme du cas d’utilisation «Gérer les documents»


3.6 Raffinement du cas d'utilisation «  Gérer les documents »:

Figure 8 : Raffinement du CU «Gérer les documents»

Cas d’utilisation :  Gérer les documents scannés

Acteur :  Users

Pré condition :  Documents scanné

Post condition :  Gérer les documents

Description du scenario
 En cas d'Approve:
principal :
 User vérifie les documents.
 User clique sur le bouton "Approved".
 Le système vérifier la saisie et enregistre
la modification des informations dans la
base.
 En cas de Reject:
 User vérifie les documents.
 User clique sur le bouton "Rejected".
 Le système vérifier la saisie et enregistre
la modification des informations dans la
base.
 En cas de return user :
 User vérifie les documents.
 User clique sur le bouton "Declined".
 Le système vérifier la saisie et enregistre
la modification des informations dans la
base.

Exception :  En cas de return user :


 User doit commenter les documents
pour ajouter des informations par le
 CSO.

Conclusion

Au cours de cette phase, nous avons pu dégager les différentes exigences fonctionnelles et non
fonctionnelles. Dans ce qui suit, nous allons présenter la méthodologie de conception qui a été mise
en œuvre tout au long de la réalisation de ce projet.
Chapitre 3 : Conception

1. Introduction
La conception est une étape primordiale dans le cycle de vie d’une application, elle a pour objectif
d’élaborer à partir du modèle du système obtenu lors de l’étape d’analyse de besoin, des modèles
détaillés de l’architecture du système. Elle vise également la réduction de la complexité du système.
Nous allons commencer par expliquer la conception générale de notre application par la présentation
des diagrammes de classes, et diagrammes de séquences.

I. Conception général :
2. Le model du cycle de vie :
Afin de concevoir et réaliser notre application, nous avons opté pour le model de cycle de vie en V.

2.1 Présentation du modèle :


Le modèle du cycle en V est un modèle conceptuel de gestion de projet imaginé suite au problème
de réactivité du modèle en cascade. Il permet, en cas d'anomalie, de limiter un retour aux étapes
précédentes .

Figure 9: Le model en V

2.1.1 Description du modèle en V :


La représentation en V tient d'avantage compte de la réalité, le processus de développement n'est
pas réduit à un enchaînement de tâches séquentielles. Elle montre que:
 c'est en phase de spécification que l'on se préoccupe des procédures de validation ;
 c'est en phase de conception générale que l'on se préoccupe des procédures d'intégration
 c'est en phase de conception détaillée que l'on prépare les tests unitaires.
Le modèle de cycle de vie en V permet d'anticiper sur les phases ultérieures de développement du
produit. En particulier le modèle en V permet de commencer plus tôt:
 Plan de tests de qualification ;
 Plan d'évaluation des performances.

1. Présentation du Vb.net

...........

2. Choix de UML
Afin d’aboutir au développement d’un système fiable, il est indispensable de suivre une démarche
qui définit et modélise le fonctionnement du système d’une manière simple et efficace. Notre
conception sera modélisée par, UML (UnifiedModeling Language), ou Langage de modélisation
unifié, est un langage de modélisation graphique à base de pictogrammes. Il est utilisé en
développement logiciel, et en conception orientée objet. Cette méthodologie est basée sur le
langage de modélisation UML que nous avons adopté pour toute la suite de notre travail. L'UML est
constitué d'une notation très spécifique ainsi que les règles grammaticales s'y attachant pour
élaborer des modèles de logiciel.

L'UML supporte un riche ensemble d'éléments de notation graphique. Il décrit la notation pour les
classes, les composants, les nœuds, les activités, le workflow, les cas d'utilisations, les objets, les
états ainsi que la façon de modéliser les relations entre ces éléments. L'UML permet également les
extensions personnelles à travers les éléments stéréotypés. . Nous avons opté pour UML car nous le
maitrisons bien mieux que les autres langages.

3.1 Méthodologie adoptée


Power AMC .........

3. Architecture d'une application web du Workflow:


Notre projet consiste à concevoir une application avec une architecture 3-tiers.

Dans l'architecture à 3 niveaux (appelée architecture 3-tiers), il existe un niveau intermédiaire, c'est-
à-dire que l'on a généralement une architecture partagée entre :

 Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une interface


utilisateur (généralement un navigateur web) chargée de la présentation ;
 Le serveur d'application (appelé également middleware), chargé de fournir la ressource mais
faisant appel à un autre serveur ;
 Le serveur de données, fournissant au serveur d'application les données dont il a besoin.
Figure 10 : la structure générique d'une architecture 3-tiers

4. Conception
La conception représente une phase primordiale dans le cycle de développement d’une application.
Elle permet de trouver des solutions informatiques techniques et graphiques pour mettre en œuvre
et construire le portail demandé.

Ceci nous a conduit à adopter les approches orientée objet pour modéliser notre système en se
basant sur les diagrammes UML.

L’UML est un support de communication performant, qui facilite la représentation et la


compréhension de solution objet :

 Sa notation graphique permet d’exprimer visuellement une solution objet, ce qui facilite la
comparaison et l’évaluation de solutions.
 L’aspect formel de sa notation, limite les ambiguïtés et incompréhensions.

5.1Conception Statique
Dans cette partie, nous nous intéresserons à la conception des données afin d’aboutir à la base de
données de l’application. Pour se faire, nous allons concevoir le diagramme de classe.

5.1.1. Diagramme de classe


Le diagramme de classe est considéré comme le plus important de la modélisation orienté objet, il
est obligatoire los d’une telle modélisation. Il exprime d’une manière générale la structure statique
d’un système, en termes de classes et de relations. Outre les classes, il présente un ensemble
d’interface et paquetage, ainsi que leurs relations. Dans ce qui suit, nous allons dégager les classes
indispensables pour l’application et les relations entre elles.
PersonnelDepartment (Id PerDep,Type ) 

PersonnelBranch (Id PerBran, Name , FirstName) ;

PersonnelOperation (Id PerOpName , FirstName) ;

PersonnelRisk(Id PerRk, Name , FirstName) ;

CSO (Id Cso,Name, FirstName) ;

Custmer (Id Cust, Name , FirstName, CIN,Tel, Adresse,RIB,MaritalStatus) ;

BranchManager (Id BM, Name , FirstName) ;

BCO_Officer (Id BCOof, Name , FirstName) ;

BCO_Manager (Id BCOMan, Name , FirstName) ;

COD_Officer (Id CODOf, Name , FirstName) ;

CLD_Authonizer (Id CLDA, Name , FirstName) ;

Credit_Analyst (Id CA, Name , FirstName) ;

Head_Of_Retail (Id HOR, Name , FirstName) ;

CLD_Officer (Id CLDO, Name , FirstName) ;

Banking_Transaction(Id Bank, Type) ;

Establishment_Of_Account(Id EstAcc, Name , Date, Time,Type) ;

Transfert (Id Trens, Name , Date, Time,Type) ;

Deposit_Booking(Id DeBo, Name , Date, Time,Type) ;

Loans (Id Loans, Name , Date, Time,Type) ;

Document (Id Doc, Name , Type) ;


Figure 11 : Diagramme de classe
5.2 Conception dynamique
Pour mieux comprendre le fonctionnement de notre système et son évolution chronologique,
l’utilisation d’un diagramme dynamique sera plus démonstrative et plus concrète. Nous avons
présenté notre système à l’aide du diagramme de séquences.
Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et
le système selon un ordre chronologique dans la formulation UML. On montre ces interactions dans
le cadre d’un scénario d’un diagramme des cas d’utilisation. Dans un souci de simplification, on
représente l’acteur principal à gauche du diagramme et les acteurs secondaires éventuels à droite du
système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou les objets. Les
périodes d’activité des classes sont symbolisées par des rectangles.

5.2.1 Diagramme de séquence d'authentification


Acteur : CSO.

Description :

Le CSO doit se connecter avant de pouvoir profité de l’application, et pour ceci il accède à la page
d’authentification et saisie son identifiant et son mot de passe, le système vérifie les données saisies
par le CSO , si les données sont erronée il lui renvoi un message d’erreur sinon il le redirige vers la
page de son profil.
Figure 12 : diagramme de séquence d'authentification

5.2.2 Diagramme de séquence de vérification client


Acteur : CSO

Description :

Après s’être authentifié, le CSO doit vérifier l'existence du client à travers le saisie du nom et le
numéro du client , si les données sont erronée il lui renvoi à la page d'accueil sinon il le affiche un
formulaire remplie par les données du client.

Figure 13 : Diagramme de séquence relatif à la «Vérification du clients»


5.2.3 Diagramme de séquence Déposer les documents
Acteur : CSO.

Description :

Après la vérification de l'existence du client, le CSO peut déposer les documents , il peut ajouter des
documents, il peut aussi supprimer des documents seulement si ils ne sont pas valide et il peut aussi
modifier les documents en cas de manque des documents .

Figure 14 : Diagramme de séquence «Déposer les documents»


5.2.3 Diagramme de séquence « Gérer les documents » 
Acteur : Users.

Description :

Après l'envoi des documents aux acteurs concernés (selon l'opération bancaire ) par le CSO , chaque
user valide une partie du document .

Les documents peuvent être approuver ou rejeter ou refuser par les users .

chaque user doit vérifier une partie du document puis envoyer aux users suivant .

Figure 15 : Diagramme de séquence «Gérer les documents »