Rapport PFE

Ecole supérieure privéé des sciences
appliquées et managment
RAPPORT DE STAGE DE PROJET DE FIN D’ETUDES INGENIEURS EN

INFORMATIQUE
Gestion de budget d’une banque
Encadrant SESAME :
Réalisé par
M Tarek HAMROUNI
Taoufik Tababi
Encadrant Entreprise :
M Ali Turki
Année Universitaire :2020-2021

Table des matières
Introduction générale 4
1 Présentation du cadre général de projet 6

1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . 7
1.2.1 Présentation de Kripton tunisie . . . . . . . . . . . . . . . . 7
1.2.2 Histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Présentation Du Projet . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.4 Etude De L’existant . . . . . . . . . . . . . . . . . . . . . . 10
1.3.5 Solution Proposé . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Choix technologique . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 Framework et langages . . . . . . . . . . . . . . . . . . . . . 11
1.4.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . 12
1.5 Méthodologie de développement adoptée . . . . . . . . . . . . . . . 14
1.5.1 Présentation de la méthodologie choisie . . . . . . . . . . . . 15
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1
TABLE DES MATIÈRES
2 Analyse et Spécification des Besoins 17

2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 18
2.1.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 19
2.1.3 Identification des acteurs . . . . . . . . . . . . . . . . . . . . 20
2.2 Analyse globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . 21
2.3 Pilotage du projet par Scrum . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Architecture des microservices . . . . . . . . . . . . . . . . . . . . . 25
2.4.1 Concept de base . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.2 Les avantages de l’architecture microservices . . . . . . . . . 26
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2
Table des figures
1.1 kripton tunisie [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Cycle de vie SCRUM [1] . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . 21

2.2 Le backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Différence entre l’approche monolithique et l’approche microservices
[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3
Introduction générale
Chaque banque est consciente de l’impact d’une gestion efficace sur ses perfor-
mances et sa compétitivité sur le marché. Mais la croissance des activités engendre
un énorme effort dans la gestion des budgets qui rend la gestion de plus en plus
complexe et difficile.
A ce titre, la gestion budgétaire qui représente l’aboutissement de la démarche stra-
tégique, s’est imposée comme étant un des outils impératifs de la gestion moderne,
dans la mesure où elle constitue un des moments privilégiés d’anticipation, d’ana-
lyse et de remise en cause pouune allocation cohérente et pertinente des ressources
mobilisables en vue d’atteindre les objectifs visés. Elle est aujourd’hui pleinement
mise en œuvre dans les banques et les établissements financiers internationaux,
participant activement au processus de création de valeur et constituant ainsi un
véritable atout concurrentiel.
Ce rapport est une synthèse de tout le travail que nous avons réalisé dans cette
perspective. Il est initialisé par le premier chapitre intitulé «présentation du cadre
général de projet» concerne la présentation de l’organisme d’accueil, contexte du
projet,cadre du projet ,la problématique ainsi la solution proposée, on finit avec la
définition de la méthode de développement adopté dans notre projet. Par la suite,
le deuxième chapitre intitulé «Analyse et Spécification des Besoins» prendra place.
Dans ce chapitre nous présenterons l’analyse et la spécification des besoins.Nous ex-
poserons, en premier lieu,nous présenterons une analyse détaillée des besoins fonc-
4
TABLE DES FIGURES
tionnels et non fonctionnels ainsi que le diagramme de cas d’utilisation général.En

second lieu,nous décrirons le Backlog Produit et la planification des sprints.Et en-
fin,nous présenterons des concepts théoriques liés à l’architecture micro-services.
5
Chapitre 1
Présentation du cadre général de

projet
Introduction
Dans ce chapitre, nous souhaitons mettre notre projet en contexte, à savoir
l’organisme d’accueil « Kripton Tunisie » en indiquant ses activités ainsi que
les valeurs de cette société dans un premier temps, ensuite nous développons la
problématique de notre sujet et la solution proposée. Enfin, nous exposons une
description des technologies et méthodologie adoptée.
1.1 Cadre du projet

À l’occasion de notre formation à l’École Supérieure des Sciences Appliquées
et de Management SESAME, j’ai eu l’occasion de compléter mon projet de fin
d’études pour l’obtention du diplôme national d’ingénieur en informatique au sein
de la société « Kripton Tunisie » .Ce projet intitulé Gestion de budget d’une
banque vient dans le but de compléter ma formation académique acquise au cours
6
CHAPITRE 1. PRÉSENTATION DU CADRE GÉNÉRAL DE PROJET
des trois dernières années, où je devrai mettre en pratique mes connaissances ac-
quises en développement informatique, défiant mon esprit d’ingénieur pour trouver
des solutions aux problèmes rencontrés dans un cadre professionnel.
1.2 Présentation de l’organisme d’accueil

Dans cette section nous allons présenter l’entreprise où nous étions accueillis :
« Kripton Tunisie ».
1.2.1 Présentation de Kripton tunisie
Kripton est une entreprise filiale du groupe allemand Sapres GmbH basée à
Francfort sur la main qui opére dans le domaine des technologies de l’informa-
tion.Elle est spécialisée dans les métiers du conseil et des services en ingénierie
informatique. Kripton fournit des services de d développement de logiciels, de
conseil et de formation pour les sociétés dans plusieurs secteurs d’activité touten
collaborant avec ses clients, pour les aider à faire des améliorations sub-stantielles
et durables de leurs performances en leur donnant des compétenceshautement qua-
lifiées pour développer des systémes innovants. Elle offre plusieurs services :
Figure 1.1 – kripton tunisie [2]
— Développement,spécifique et Consulting
— Gestion de patrimoine applicatif
— Architecture Software
7
— Test et validation
— Intégration progicielle-SAP
1.2.2 Histoire
Après un parcours d’une quinzaine d’année et une croissance continue le groupe

Cynapsys (dont Kripton faisait partie) se rapproche de la société GFI (Générale
Française de l’informatique) basée à Paris -Saint Ouen dont un partenariat existait
déjà sur certaines opérations en Afrique du Nord. En effet le groupe Gfi Informa-
tique a acquis les sociétés du Groupe Cynapsys opérant sur la marché français
et africain, multi spécialiste pour des clients soit français (en centre de services)
soit sur le marché local tunisien ou plus largement africain. Les sociétés reprises
réalisent ensemble un chiffre d’affaires de l’ordre de 5 M=
C. L’effectif est de 150
personnes en France et en Tunisie a été dès lors transféré et la société et a été
consolidé dans les comptes de Gfi Informatique à compter du 1er mars 2018. Pour
Selim Ben Yedder, Co-fondateur de Cynapsys : la céssion est « le couronnement
de 15 ans de travail continu et acharné qui a fait de Cynapsys un fleuron de l’IT et
de l’innovation tunisienne. ils ont pu créer de la valeur avec des compétences tuni-
siennes, des ingénieurs de haute qualité qui ont pu s’imposer par leur performance
sur des projets IT de grande envergure.» Les opérations de Cynapsys à travers
sa filiale Kripton n’ont pas été sujet de cette transaction et se sont découplés de
l’activité de Cynapsys / GFI par un management by-out. Kripton donc se redé-
fini à travers cette nouvelle orientation en se focalisant ses activités en créant de
nouveaux partenariats et en redéfinissant ses priorités. À propos de Gfi Informa-
tique : Acteur européen de référence des services informatiques à valeur ajoutée et
des logiciels, Gfi Informatique occupe un positionnement stratégique différenciant
entre les opérateurs de taille mondiale et les acteurs de niche. Avec son profil de
multi-specialiste, le Groupe met au service de ses clients une combinaison unique
8
de proximité, d’organisation sectorielle et de solutions de qualité industrielle. Le

Groupe qui compte près de 18 000 collaborateurs a réalisé en 2017 un chiffre d’af-
faires de 1 132 M=
C[2].
1.2.3 Vision
la vision de kripton tunisie est d’être un acteur principal dans la région EMEA
dans le domaine des technologies d’information et de la transformation digitale.
il veut être toujours à l’écoute de vos clients en leur offrant un service à haute
valeur ajoutée tout en étant une force de proposions avec des idées innovantes
présentant un fort potentiel pour leurs clients et partenaires. il souhaite également
faire de Kripton un groupe de société axé sur l’avenir et reconnu comme un acteur
innovant et visionnaire. Ainsi, Kripton souhaite développer ses compétences et son
savoir-faire afin de répondre aux enjeux technologiques futurs. Les systèmes qu’il
développe devront avoir une conception claire et précise et présenter des interfaces
utilisateur ergonomique et intuitive [2].
1.3 Présentation Du Projet
1.3.1 Contexte du projet
La procédure de la gestion budgétaire est apparue dans les organisations éco-

nomiques complexes à partir des années 1930, du fait de leur grande taille, dans le
but de résoudre des problèmes de gestion après avoir été pratiquée et développée
au niveau de l’Etat. La gestion budgétaire en générale s’appuie sur des prévisions,
fonction des conditions intérieures et extérieures. A partir de ces prévisions, les
responsables de la banque reçoivent après accord des attributions programmes et
moyens pour une durée limitée.
9
1.3.2 Problématique
La gestion budgétaire est un processus qui comprend deux phases, Une phase
consacrée à la préparation du budget et la seconde phase à la confrontation entre
ce budget et le budget réalisé.
De la création à l’approbation du budget, plusieurs acteurs interviennent pour
mener à bien ce processus.D’autre part ce processus de définition d’un budget est
couteux en terme du temps et compliqué car il exige le passage par plusieurs étapes
qu’on peut les éviter.
C’est dans ce contexte que l’idée est de développer une application de gestion
budgétaire dans une banque.
1.3.3 Objectifs du projet
Dans ce stage, nous sommes ramenés à développer une application de gestion

budgétaire dans une banque. Le but est d’abord, de simplifier la création d’un
budget avec la réalisation d’un interface qui donne la main au responsable de créer
un budget détaillé, aussi pour faciliter le contrôle, la négociation, la validation et
l’approbation de ce dernier. Tous les acteurs impliqués dans ce processus devront
admettre leurs propres comptes et interfaces.
1.3.4 Etude De L’existant
Le processus de la gestion budgétaire dans une banque est entiérement ma-

nuel.Les principaux problèmes identifiés sont :
— Le processus de creation des budgets n’est pas automatisé.
— Il n’y a pas de contrôle centralisé.
— Il n’y a pas une outil de supervision des budgets.
Pour accomplir ces points et satisfaire les nouvelles fonctionnalités, nous avons
10
réalisé un système entièrement automatisé qui doit être mis en place pour optimiser
et automatiser le processus.
1.3.5 Solution Proposé
La société a proposée comme solution de développer une application pour gérer

le budget annuel d’une banque. Cette application recouvrera plusieurs aspects afin
de répondre aux normes imposées par la gestion budgétaire.
1.4 Choix technologique

Pour la réalisation de la solution proposée, nous avons choisi de travailler avec :
— UML comme langage de conception et StarUML comme un logiciel de mo-
délisation
— Mysql comme SGBD
— Spring boot comme technologie BackEnd
— angular 10 comme technologie frontend
— Eclipse et Visual Studio Code comme des outils de développement
— Git comme outil de versioning de code et GitLab comme plate-forme d’hé-
bergement de référentiels de contrôle de version.
1.4.1 Framework et langages
Angular
Angular est un Framework open source écrit en JavaScript qui permet la créa-
tion d’applications Web et plus particulièrement de ce qu’on appelle des « Single
Page Applications » des applications web accessibles via une page web unique qui
permet de fluidifier l’expérience utilisateur et d’éviter les chargements de pages à
11
chaque nouvelle action.Le Framework est basé sur une architecture du type MVVM
et permet donc de séparer les données, le visuel et les actions pour une meilleure
gestion des responsabilités. Un type d’architecture qui a largement fait ses preuves
et qui permet une forte maintenabilité et une amélioration du travail collaboratif
[3].
Spring boot
Spring Boot est un framework qui facilite le développement d’applications fon-

dées sur Spring en offrant des outils permettant d’obtenir une application packagée
en jar , totalement autonome. il intègre directement Tomcat, Jetty ou Undertow
et fournit des dépendances de ”démarreur” avisées pour simplifier la configuration
de construction. Il configure automatiquement les bibliothèques Spring et tierces
autant que possible, et il fournit des fonctionnalités prêtes à la production telles
que les mesures [4].
1.4.2 Environnement logiciel
Mysql
MySQL est un serveur de bases de données relationnelles Open Source. c’est un

serveur de bases de données stocke les données dans des tables séparées plutôt que
de tout rassembler dans une seule table. Cela améliore la rapidité et la souplesse
de l’ensemble. Les tables sont reliées par des relations définies, qui rendent possible
la combinaison de données entre plusieurs tables durant une requête. Le SQL dans
”MySQL” signifie ”Structured Query Language” : le langage standard pour les
traitements de bases de données [7].
12
Visual Studio Code
C’est un éditeur de code open-source, gratuit et multi-plateforme (Windows,

Mac et Linux), développé par Microsoft. Il est principalement conçu pour le dé-
veloppement d’application avec JavaScript, TypeScript et Node.js. L’éditeur peut
s’adapter à d’autres types de langages grâce à un système d’extension bien fourni.
Eclipse
Eclipse est un IDE, Integrated Development Environment (EDI environnement

de développement intégré en français), c’est un logiciel qui simplifie la programma-
tion en proposant un certain nombre de raccourcis et d’aide à la programmation.
Il est développé par IBM, est gratuit et disponible pour la plupart des systèmes
d’exploitation. Au fur et à mesure que vous programmez, eclipse compile automa-
tiquement le code que vous écrivez, en soulignant en rouge ou jaune les problème
qu’il décèle. Il souligne en rouge les parties du programme qui ne compilent pas,
et en jaune les parties qui compilent mais peuvent éventuellement poser problème
(on dit qu’eclipse lève un avertissement, ou warning en anglais). Pendant l’écriture
du code, cela peut sembler un peu déroutant au début, puisque tant que la ligne
de code n’est pas terminée (en gros jusqu’au point-virgule), eclipse indique une
erreur dans le code [5].
Git
Git est un système de contrôle de versions pour le développement de logiciels qui

a été initialement conçu et développé par Linus Torvalds. Il permet et encourage
à avoir plusieurs dépôts locaux pouvant être entièrement indépendantes les unes
des autres. La création, la fusion et la suppression de ces lignes de développement
se fait en quelques secondes. Le Git facilite le travail en groupe grâce aux pull
13
requests qui simplifient les revues de code, ce qui garantit un code de meilleure
qualité et permet de partager des connaissances dans l’équipe [6].
GitLab
Gitlab, c’est une plateforme permettant d’héberger et de gérer des projets web
de A à Z. Présentée comme la plateforme des développeurs modernes, elle offre
la possibilité de gérer ses dépôts Git et ainsi de mieux appréhender la gestion des
versions de vos codes sources.
1.5 Méthodologie de développement adoptée

La finalisation du projet dans les délais de livraison est la préoccupation ma-
jeure de chaque développement logiciel. L’un des problèmes les plus courants ren-
contrés lors de la création des logiciels est la mauvaise spécification et changement
soudain des exigences. Cela peut influencer non seulement sur l’équipe de déve-
loppement en créant une situation stressante pour l’environnement, mais aussi le
temps passé sur le projet et donc dépassé les délais de livraison.
Étant une approche incrémentale et itérative, la méthode agile est mise en œuvre
dans l’esprit collaboratif. Il contribue à la réalisation d’un produit de haute qualité
sans oublier les besoins des clients.
Dérivé du Manifeste Agile, le développement Agile a été écrit au début des années
2000 par une équipe de Scrum créateurs, Dynamic Systems Development Method
(DSDM), Extreme Programming (XP), et bien d’autres leaders de l’industrie du
logiciel.
14
1.5.1 Présentation de la méthodologie choisie
Suite au tableau comparatif entre les méthodes agiles que nous avons élaboré
ci-dessus,nous avons choisi le Scrum qui est itératif et incrémental pour s’adapter
aux évolutions des fonctionnalités.
Le principe de la méthode agile SCRUM est de concentrer l’équipe de dévelop-
pement sur un ensemble de fonctionnalités de manière itérative, chaque itération
est d’une durée de deux à quatre semaines, appelées Sprints. Chaque Sprint doit
s’installer dans la livraison d’un produit partiel. La figure 1.5 illustre le cycle de
vie SCRUM.
Figure 1.2 – Cycle de vie SCRUM [1]
Comme le montre la figure ci-dessus, et dans le but de mettre en place la

méthode SCRUM, il faut :
— Tout d’abord, identifier le maximum de fonctionnalités à réaliser pour consti-
tuer le carnet du produit.
— Deuxièmement, définir les priorités des fonctionnalités et choisir celles qui
seront exécutées à chaque itération
15
— Par la suite, se concentrer itérativement sur toutes les fonctionnalités à

réaliser dans des itérations appelées Sprints. Unsprint se traduit toujours
par livraison d’un produit partiel fonctionnel appelé incrément. Ainsi, vers
la fin de chaque Sprint, une rencontre aura lieu pour revoir l’itération. Le
but de cette réunion est de valider l’incrément qui était produit lors de
l’itération.
1.6 Conclusion
Tout au long de ce chapitre, nous avons présenté l’organisme d’accueil et une
brève description du projet à traiter, identifier le problème et proposer la solution
envisagée pour se faire face à la situation actuelle. Par la suite, nous avons pré-
senté une comparaison entre les méthodologies de développement existantes pour
rendre le choix de la méthodologie adopté au développement de notre système plus
facile. Le prochain chapitre sera consacré à l’étude des besoins fonctionnels et non
fonctionnelset la spécification du Product Backlog
16
Chapitre 2
Analyse et Spécification des Besoins
Introduction
Après avoir opéré une étude préliminaire, nous abordons la section de spécifica-
tion des besoins. En effet, c’est au cours de celle-ci que les axes lies à la réalisation
du projet sont présentés. Tout d’abord, nous développerons une étude contextuelle
dans laquelle nous identifions les besoins fonctionnels et non fonctionnels, les ac-
teurs de notre application. Par la suite,Nous planifierons le projet en se basant sur
le Product Backlog. Enfin, nous clôturons le chapitre en présentant l’architecture
générale de notre application.
2.1 Spécification des besoins

Dans cette partie, nous définissons les besoins auxquels l’application doit ré-
pondre. Pour ce faire, nous dégagerons d’une part les besoins fonctionnels et d’autre
part les besoins non fonctionnels,ainsi que l’identification des acteurs pour la réa-
lisation de notre application
17
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
2.1.1 Besoins fonctionnels
Après avoir des réunions successives avec le Product Owner, nous avons pu
extraire les fonctionnalités que notre solution doit avoir. L’application alors doit
nécessairement répondre aux besoins fonctionnels suivants :
1. Sécurité : l’une des fonctionnalités les plus importantes de cette application

est d’augmenter la sécurité afin de protéger les fonctionnalités requises par
la plateforme, tout utilisateur de l’application doit avoir un compte activé.
2. Administration :Ce module permettra à l’administrateur de visualiser, mo-

difier,supprimer et activer ou désactiver les comptes utilisateurs de l’applica-
tion,aussi de gérer l’organigramme de la banque et de consulter l’historique
de navigation.
3. Responsable : Ce module permettra au responsable de créer son budget

détaillé, aussi de choisir le type de budget soit dépense ou recette , il lui
permettra également de réviser le budget avec le directeur du contrôle de
gestion.
4. Directeur générale :Ce module permettra au directeur général de négocier

le budget avec le responsable et le directeur du contrôle de gestion afin de
le valider et de le passer au vote pour l’approuver.
5. Président du conseil :Ce module permettra au président du conseil d’ap-

prouver le budget après le vote qui est effectué par les membres du conseil
avec le directeur général
18
2.1.2 Besoins non fonctionnels
En plus des besoins fonctionnels que notre futur application doit fournir, il
existe également un ensemble de contraintes qui doivent être respectées, et qui
présentent une propriété qualifiante du projet. Parmi ces exigences nous distin-
guons :
1. La disponibilité : Notre application doit être fonctionnel et garantit un

accès aux services et aux ressources avec un temps de réponse adéquat.
2. Maintenabilité et évolutivité :L’application doit permettre une mainte-

nance simple et facile et il doit être susceptible à s’évaluer d’une manière
plus aisée. Ainsi, nous avons essayé de simplifier notre code le plus possible,
le commenter et le structurer dans des différents fichiers et dossiers.
3. Intégrité :les informations contenues dans lapplication ne doivent pas être

modifiées en raison d’erreurs.
4. Performance :l’application doit fournir un temps de réponse minimum.

Cela nécessite un développement orienté optimisations ainsi que la mise à
disposition des ressources matérielles nécessaires.
5. Gestion des erreurs : l’application doit mieux gérer ces exceptions par
l’apparition des messages d’alerte.
6. Sécurité : l’accès aux différentes fonctionnalités de la solution n’est favo-

rable qu’après une étape d’authentification sécurisée. Le système doit être
protégé contre les fraudes de modification, suppression, etc.
19
2.1.3 Identification des acteurs
Un acteur est un élément externe qui interagit avec le système pour obtenir un
résultat. Il prend des décisions et initiatives. Dans le cas de notre projet, les acteurs
varient en fonction de leurs besoins et des services qu’ils sont allés consommer de
l’application. Les acteurs qui interagissent ont en commun des fonctionnalités qui
nous avons identifié ce qui sera détaillé dans les sous-sections suivantes.
Classification des acteurs :
— Directeur gestion control :Il est l’acteur en charge de l’administration

de l’application,Il est le seul acteur chargé de créer les comptes et ,définir
les droits d’accès des utilisateurs et créer l’organigramme de la banque. Il a
une visibilité totale sur les comptes des responsables ainsi que leurs budgets
qu’ils ont définis.il participe aussi à la phase de révison et négociation des
budgets.
— Responsable :C’est le responsable de la gestion d’un budget .Il participe
aussi à la phase de révison et négociation des budgets.
— Directeur générale : Il participe à la phase de négociation d’un budget
enfin il le valide.Il participe également à la phase d’approbation avec les
membres du conseil.
— Président du conseil : il est responsable de l’approbation d’un budget après
le vote qui est effectué par les membres du conseil avec le directeur général
2.2 Analyse globale

L’étape d’analyse représente la première phase du cycle de développement lo-
giciel. Dans cette partie, nous utilisons le langage de modélisation unifié comme
moyen simple et compréhensible de formuler les principaux cas d’utilisation offerts
20
par notre système ainsi que le diagramme de classes d’analyse qui représente les
entités manipulées par les utilisateurs.
2.2.1 Diagramme de cas d’utilisation global
Nous présentons dans la figure 2.1 une vue globale concernant le comportement
fonctionnel de l’application. Ce diagramme permet également de représenter les
interactions entre les acteurs et les cas d’utilisation du système.
Figure 2.1 – Diagramme de cas d’utilisation global
21
2.3 Pilotage du projet par Scrum

Une bonne planification du travail est très importante pour aboutir à un bon
projet. Dans cette partie, nous allons identifier les membres de l’équipe, élaborer
le Backlog du produit et présenter le découpage de notre projet en des sprints.
2.3.1 Backlog du produit
Le Product Backlog est une liste hiérarchisée des besoins et des exigences du
client. Les éléments du Product Backlog, également appelés user stories, sont for-
mulés en une ou deux phrases décrivant d’une manière claire et précise les fonc-
tionnalités souhaitées par le client.
C’est à travers le Product Backlog que s’établit une vue générale sur tous les be-
soins du client que l’équipe projet doit réaliser.
Habituellement, écrit sous la forme suivante « En tant que X,je veux Y, donc Z».
À chaque sprint, l’équipe de développement part d’une partie de fonctionnalités
extraites du Product Backlog afin de les réaliser et livrer à sa fin un produit conte-
nant ces fonctionnalités. Par la suite une description des termes utilisés dans le
Product Backlog :
— Fonctionnalité :Cette colonne contient les besoins fonctionnels initiaux fixés
auparavant.
— ID :C’est un identifiant unique pour chaque fonctionnalité.
— User story : Il s’agit d’une phrase décrivant la fonctionnalité souhaitée par
le client.
— Priority : C’est une approximation de l’effort essentiel à la réalisation d’une
story selon les attentes et les besoins du client.
22
23
24
Figure 2.2 – Le backlog du produit
2.4 Architecture des microservices
2.4.1 Concept de base
L’architecture des microservices est un modèle de conception qui décompose

une application complexe en plusieurs processus indépendants et faiblement cou-
plés, tous spécialisés dans une seule tâche. Ceux-ci sont appelés microservices. Ils
sont souvent liés par des API REST via le protocole HTTP. Cette architecture
diffère de l’architecture monolithique qui centralise tous les besoins en un seul pro-
cessus.
La figure 2.3 illustre la différence entre une application monolithique et une appli-
cation basée sur microservices.
25
Figure 2.3 – Différence entre l’approche monolithique et l’approche microservices

[8]
L’approche monolithique a un processus unique qui gère toutes les fonctionna-

lités. D’autre part, une application basée sur l’architecture microservices est com-
posée de plusieurs processus qui interagissent les uns avec les autres et à distance
via les API.
2.4.2 Les avantages de l’architecture microservices
L’architecture des microservices a été inventée pour résoudre certains problèmes

rencontrés notamment au niveau de grands projets parmi eux :
— Extensibilité :plus un projet est gros, plus il devient coûteux et risqué.
Le risque est d’être dans un projet qui ne peut pas être modifié pour un
nouveau cas d’utilisation. En utilisant l’architecture des microservices, il
est plus facile d’augmenter l’extensibilité en changeant le code ou en le
réécrivant complètement selon le nouveau besoin puisque l’application est
26
décomposée en un processus de taille limitée.
— Évolutivité : :dans une application, certaines fonctionnalités sont utilisées

plus que d’autres. Diviser l’application en microservices permet de dupliquer
un service requis plutôt que d’implémenter une redondance de l’ensemble
de l’application.
— Maintenabilité : A mesure que la taille du code augmente, le code devient

plus complexe. Cela rend plus difficile d’ajouter de nouvelles fonctionnali-
tés et d’apporter des modifications. En utilisant l’architecture microservices,
leschangements deviennent plus simples, puisqu’ils ne provoquent la mise à
jour que d’un seul service.
— Productivité et rapidité améliorées : l’architecture microservices s’attaque

au problème de la productivité et la vitesse de développement en décompo-
sant les applications en services gérables qui sont plus rapides à développer.
Les équipes peuvent travailler simultanément sur différents composants sans
attendre aucune autre équipe termine un morceau de travail. Les microser-
vices séparés sont plus faciles à localiser et à modifier. Ce type d’architec-
ture est également très pratique pour accélérer l’assurance qualité puisque
chaque microservice peuvent être testés individuellement et vous pouvez
tester les composants qui ont déjà été développés lorsque les programmeurs
travaillent sur les autres.
27
2.5 Conclusion
Ce chapitre résume la phase d’analyse des besoins que nous avons établie avant
de commencer la phase de développement de notre application.Nous avons d’abord
identifié les besoins fonctionnels et non fonctionnels, puis nous avons identifié les
acteurs qui interagissent avec l’application. Ensuite nous avons présenté l’architec-
ture modèle de notre solution.
28
Bibliographie
[1] https ://www.scrum.org/resources/what-is-scrumd
[2] https ://www.kripton.fr/a-propos/
[3] https ://fr.wikipedia.org/wiki/Angular
[4] https ://spring.io/projects/spring-boot
[5] https ://fr.wikipedia.org/wiki/
[6] https ://gitscm.com/
[7] https ://fr.wikipedia.org/wiki/MySQL
[8] https ://rancher.com/blog/2019/microservices-vs-monolithic-architectures
29

Rapport PFE

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Rapport PFE

Titre original :

Transféré par

Droits d'auteur :

Ecole supérieure privéé des sciences

RAPPORT DE STAGE DE PROJET DE FIN D’ETUDES INGENIEURS EN

Gestion de budget d’une banque

Année Universitaire :2020-2021

1 Présentation du cadre général de projet 6

2 Analyse et Spécification des Besoins 17

1.1 kripton tunisie [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . 21

tionnels et non fonctionnels ainsi que le diagramme de cas d’utilisation général.En

Présentation du cadre général de

1.1 Cadre du projet

1.2 Présentation de l’organisme d’accueil

1.2.1 Présentation de Kripton tunisie

Figure 1.1 – kripton tunisie [2]

Après un parcours d’une quinzaine d’année et une croissance continue le groupe

de proximité, d’organisation sectorielle et de solutions de qualité industrielle. Le

1.3 Présentation Du Projet

1.3.1 Contexte du projet

La procédure de la gestion budgétaire est apparue dans les organisations éco-

1.3.3 Objectifs du projet

Dans ce stage, nous sommes ramenés à développer une application de gestion

1.3.4 Etude De L’existant

Le processus de la gestion budgétaire dans une banque est entiérement ma-

1.3.5 Solution Proposé

La société a proposée comme solution de développer une application pour gérer

1.4 Choix technologique

1.4.1 Framework et langages

Spring Boot est un framework qui facilite le développement d’applications fon-

1.4.2 Environnement logiciel

MySQL est un serveur de bases de données relationnelles Open Source. c’est un

Visual Studio Code

C’est un éditeur de code open-source, gratuit et multi-plateforme (Windows,

Eclipse est un IDE, Integrated Development Environment (EDI environnement

Git est un système de contrôle de versions pour le développement de logiciels qui

1.5 Méthodologie de développement adoptée

1.5.1 Présentation de la méthodologie choisie

Figure 1.2 – Cycle de vie SCRUM [1]

Comme le montre la figure ci-dessus, et dans le but de mettre en place la

— Par la suite, se concentrer itérativement sur toutes les fonctionnalités à

Analyse et Spécification des Besoins

2.1 Spécification des besoins

2.1.1 Besoins fonctionnels

1. Sécurité : l’une des fonctionnalités les plus importantes de cette application

2. Administration :Ce module permettra à l’administrateur de visualiser, mo-

3. Responsable : Ce module permettra au responsable de créer son budget

4. Directeur générale :Ce module permettra au directeur général de négocier

5. Président du conseil :Ce module permettra au président du conseil d’ap-

2.1.2 Besoins non fonctionnels

1. La disponibilité : Notre application doit être fonctionnel et garantit un

2. Maintenabilité et évolutivité :L’application doit permettre une mainte-

3. Intégrité :les informations contenues dans lapplication ne doivent pas être

4. Performance :l’application doit fournir un temps de réponse minimum.

6. Sécurité : l’accès aux différentes fonctionnalités de la solution n’est favo-

2.1.3 Identification des acteurs

— Directeur gestion control :Il est l’acteur en charge de l’administration

2.2 Analyse globale

2.2.1 Diagramme de cas d’utilisation global

Figure 2.1 – Diagramme de cas d’utilisation global

2.3 Pilotage du projet par Scrum

2.3.1 Backlog du produit

Figure 2.2 – Le backlog du produit

2.4 Architecture des microservices

2.4.1 Concept de base

L’architecture des microservices est un modèle de conception qui décompose

Figure 2.3 – Différence entre l’approche monolithique et l’approche microservices