Rapport PFE [PDF]

Zitiervorschau

Ecole sup´erieure priv´e´e des sciences appliqu´ees et managment

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

Gestion de budget d’une banque Encadrant SESAME : R´ealis´e par M Tarek HAMROUNI Taoufik Tababi Encadrant Entreprise : M Ali Turki

Ann´ee Universitaire :2020-2021

Table des mati`eres Introduction g´en´erale

4

1 Pr´esentation du cadre g´en´eral de projet

6

1.1

Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.2

Pr´esentation de l’organisme d’accueil . . . . . . . . . . . . . . . . .

7

1.2.1

Pr´esentation de Kripton tunisie . . . . . . . . . . . . . . . .

7

1.2.2

Histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.2.3

Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

Pr´esentation Du Projet . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.3.1

Contexte du projet . . . . . . . . . . . . . . . . . . . . . . .

9

1.3.2

Probl´ematique . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.3

Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.4

Etude De L’existant . . . . . . . . . . . . . . . . . . . . . . 10

1.3.5

Solution Propos´e . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3

1.4

1.5

Choix technologique . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4.1

Framework et langages . . . . . . . . . . . . . . . . . . . . . 11

1.4.2

Environnement logiciel . . . . . . . . . . . . . . . . . . . . . 12

M´ethodologie de d´eveloppement adopt´ee . . . . . . . . . . . . . . . 14 1.5.1

1.6

Pr´esentation de la m´ethodologie choisie . . . . . . . . . . . . 15

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1

` TABLE DES MATIERES 2 Analyse et Sp´ecification des Besoins 2.1

2.2

Sp´ecification des besoins . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1

Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 18

2.1.2

Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 19

2.1.3

Identification des acteurs . . . . . . . . . . . . . . . . . . . . 20

Analyse globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.1

2.3

2.5

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

Pilotage du projet par Scrum . . . . . . . . . . . . . . . . . . . . . 22 2.3.1

2.4

17

Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . 22

Architecture des microservices . . . . . . . . . . . . . . . . . . . . . 25 2.4.1

Concept de base . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.2

Les avantages de l’architecture microservices . . . . . . . . . 26

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

Diff´erence entre l’approche monolithique et l’approche microservices [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3

Introduction g´en´erale Chaque banque est consciente de l’impact d’une gestion efficace sur ses performances et sa comp´etitivit´e sur le march´e. Mais la croissance des activit´es engendre un ´enorme effort dans la gestion des budgets qui rend la gestion de plus en plus complexe et difficile. A ce titre, la gestion budg´etaire qui repr´esente l’aboutissement de la d´emarche strat´egique, s’est impos´ee comme ´etant un des outils imp´eratifs de la gestion moderne, dans la mesure o` u elle constitue un des moments privil´egi´es d’anticipation, d’analyse et de remise en cause pouune allocation coh´erente et pertinente des ressources mobilisables en vue d’atteindre les objectifs vis´es. Elle est aujourd’hui pleinement mise en œuvre dans les banques et les ´etablissements financiers internationaux, participant activement au processus de cr´eation de valeur et constituant ainsi un v´eritable atout concurrentiel. Ce rapport est une synth`ese de tout le travail que nous avons r´ealis´e dans cette perspective. Il est initialis´e par le premier chapitre intitul´e «pr´esentation du cadre g´en´eral de projet» concerne la pr´esentation de l’organisme d’accueil, contexte du projet,cadre du projet ,la probl´ematique ainsi la solution propos´ee, on finit avec la d´efinition de la m´ethode de d´eveloppement adopt´e dans notre projet. Par la suite, le deuxi`eme chapitre intitul´e «Analyse et Sp´ecification des Besoins» prendra place. Dans ce chapitre nous pr´esenterons l’analyse et la sp´ecification des besoins.Nous exposerons, en premier lieu,nous pr´esenterons une analyse d´etaill´ee des besoins fonc4

TABLE DES FIGURES

tionnels et non fonctionnels ainsi que le diagramme de cas d’utilisation g´en´eral.En second lieu,nous d´ecrirons le Backlog Produit et la planification des sprints.Et enfin,nous pr´esenterons des concepts th´eoriques li´es a` l’architecture micro-services.

5

Chapitre 1 Pr´esentation du cadre g´en´eral de projet Introduction Dans ce chapitre, nous souhaitons mettre notre projet en contexte, a` savoir l’organisme d’accueil « Kripton Tunisie » en indiquant ses activit´es ainsi que les valeurs de cette soci´et´e dans un premier temps, ensuite nous d´eveloppons la probl´ematique de notre sujet et la solution propos´ee. Enfin, nous exposons une description des technologies et m´ethodologie adopt´ee.

1.1

Cadre du projet

` l’occasion de notre formation a` l’Ecole ´ A Sup´erieure des Sciences Appliqu´ees et de Management SESAME, j’ai eu l’occasion de compl´eter mon projet de fin d’´etudes pour l’obtention du diplˆome national d’ing´enieur en informatique au sein de la soci´et´e « Kripton Tunisie » .Ce projet intitul´e Gestion de budget d’une banque vient dans le but de compl´eter ma formation acad´emique acquise au cours 6

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

des trois derni`eres ann´ees, o` u je devrai mettre en pratique mes connaissances acquises en d´eveloppement informatique, d´efiant mon esprit d’ing´enieur pour trouver des solutions aux probl`emes rencontr´es dans un cadre professionnel.

1.2

Pr´esentation de l’organisme d’accueil

Dans cette section nous allons pr´esenter l’entreprise o` u nous ´etions accueillis : « Kripton Tunisie ».

1.2.1

Pr´esentation de Kripton tunisie

Kripton est une entreprise filiale du groupe allemand Sapres GmbH bas´ee `a Francfort sur la main qui op´ere dans le domaine des technologies de l’information.Elle est sp´ecialis´ee dans les m´etiers du conseil et des services en ing´enierie informatique. Kripton fournit des services de d d´eveloppement de logiciels, de conseil et de formation pour les soci´et´es dans plusieurs secteurs d’activit´e touten collaborant avec ses clients, pour les aider a` faire des am´eliorations sub-stantielles et durables de leurs performances en leur donnant des comp´etenceshautement qualifi´ees pour d´evelopper des syst´emes innovants. Elle offre plusieurs services :

Figure 1.1 – kripton tunisie [2] — D´eveloppement,sp´ecifique et Consulting — Gestion de patrimoine applicatif — Architecture Software 7

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

— Test et validation — Int´egration progicielle-SAP

1.2.2

Histoire

Apr`es un parcours d’une quinzaine d’ann´ee et une croissance continue le groupe Cynapsys (dont Kripton faisait partie) se rapproche de la soci´et´e GFI (G´en´erale Fran¸caise de l’informatique) bas´ee `a Paris -Saint Ouen dont un partenariat existait d´ej`a sur certaines op´erations en Afrique du Nord. En effet le groupe Gfi Informatique a acquis les soci´et´es du Groupe Cynapsys op´erant sur la march´e fran¸cais et africain, multi sp´ecialiste pour des clients soit fran¸cais (en centre de services) soit sur le march´e local tunisien ou plus largement africain. Les soci´et´es reprises r´ealisent ensemble un chiffre d’affaires de l’ordre de 5 M= C. L’effectif est de 150 personnes en France et en Tunisie a ´et´e d`es lors transf´er´e et la soci´et´e et a ´et´e consolid´e dans les comptes de Gfi Informatique a` compter du 1er mars 2018. Pour Selim Ben Yedder, Co-fondateur de Cynapsys : la c´ession est « le couronnement de 15 ans de travail continu et acharn´e qui a fait de Cynapsys un fleuron de l’IT et de l’innovation tunisienne. ils ont pu cr´eer de la valeur avec des comp´etences tunisiennes, des ing´enieurs de haute qualit´e qui ont pu s’imposer par leur performance sur des projets IT de grande envergure.» Les op´erations de Cynapsys `a travers sa filiale Kripton n’ont pas ´et´e sujet de cette transaction et se sont d´ecoupl´es de l’activit´e de Cynapsys / GFI par un management by-out. Kripton donc se red´efini a` travers cette nouvelle orientation en se focalisant ses activit´es en cr´eant de ` propos de Gfi Informanouveaux partenariats et en red´efinissant ses priorit´es. A tique : Acteur europ´een de r´ef´erence des services informatiques a` valeur ajout´ee et des logiciels, Gfi Informatique occupe un positionnement strat´egique diff´erenciant entre les op´erateurs 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

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

de proximit´e, d’organisation sectorielle et de solutions de qualit´e industrielle. Le Groupe qui compte pr`es de 18 000 collaborateurs a r´ealis´e en 2017 un chiffre d’affaires de 1 132 M= C[2].

1.2.3

Vision

la vision de kripton tunisie est d’ˆetre un acteur principal dans la r´egion EMEA dans le domaine des technologies d’information et de la transformation digitale. il veut ˆetre toujours a` l’´ecoute de vos clients en leur offrant un service a` haute valeur ajout´ee tout en ´etant une force de proposions avec des id´ees innovantes pr´esentant un fort potentiel pour leurs clients et partenaires. il souhaite ´egalement faire de Kripton un groupe de soci´et´e ax´e sur l’avenir et reconnu comme un acteur innovant et visionnaire. Ainsi, Kripton souhaite d´evelopper ses comp´etences et son savoir-faire afin de r´epondre aux enjeux technologiques futurs. Les syst`emes qu’il d´eveloppe devront avoir une conception claire et pr´ecise et pr´esenter des interfaces utilisateur ergonomique et intuitive [2].

1.3 1.3.1

Pr´esentation Du Projet Contexte du projet

La proc´edure de la gestion budg´etaire est apparue dans les organisations ´economiques complexes `a partir des ann´ees 1930, du fait de leur grande taille, dans le but de r´esoudre des probl`emes de gestion apr`es avoir ´et´e pratiqu´ee et d´evelopp´ee au niveau de l’Etat. La gestion budg´etaire en g´en´erale s’appuie sur des pr´evisions, fonction des conditions int´erieures et ext´erieures. A partir de ces pr´evisions, les responsables de la banque re¸coivent apr`es accord des attributions programmes et moyens pour une dur´ee limit´ee.

9

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

1.3.2

Probl´ematique

La gestion budg´etaire est un processus qui comprend deux phases, Une phase consacr´ee a` la pr´eparation du budget et la seconde phase `a la confrontation entre ce budget et le budget r´ealis´e. De la cr´eation a` l’approbation du budget, plusieurs acteurs interviennent pour mener a` bien ce processus.D’autre part ce processus de d´efinition d’un budget est couteux en terme du temps et compliqu´e car il exige le passage par plusieurs ´etapes qu’on peut les ´eviter. C’est dans ce contexte que l’id´ee est de d´evelopper une application de gestion budg´etaire dans une banque.

1.3.3

Objectifs du projet

Dans ce stage, nous sommes ramen´es `a d´evelopper une application de gestion budg´etaire dans une banque. Le but est d’abord, de simplifier la cr´eation d’un budget avec la r´ealisation d’un interface qui donne la main au responsable de cr´eer un budget d´etaill´e, aussi pour faciliter le contrˆole, la n´egociation, la validation et l’approbation de ce dernier. Tous les acteurs impliqu´es dans ce processus devront admettre leurs propres comptes et interfaces.

1.3.4

Etude De L’existant

Le processus de la gestion budg´etaire dans une banque est enti´erement manuel.Les principaux probl`emes identifi´es sont : — Le processus de creation des budgets n’est pas automatis´e. — Il n’y a pas de contrˆole centralis´e. — Il n’y a pas une outil de supervision des budgets. Pour accomplir ces points et satisfaire les nouvelles fonctionnalit´es, nous avons

10

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

r´ealis´e un syst`eme enti`erement automatis´e qui doit ˆetre mis en place pour optimiser et automatiser le processus.

1.3.5

Solution Propos´e

La soci´et´e a propos´ee comme solution de d´evelopper une application pour g´erer le budget annuel d’une banque. Cette application recouvrera plusieurs aspects afin de r´epondre aux normes impos´ees par la gestion budg´etaire.

1.4

Choix technologique

Pour la r´ealisation de la solution propos´ee, nous avons choisi de travailler avec : — UML comme langage de conception et StarUML comme un logiciel de mod´elisation — Mysql comme SGBD — Spring boot comme technologie BackEnd — angular 10 comme technologie frontend — Eclipse et Visual Studio Code comme des outils de d´eveloppement — Git comme outil de versioning de code et GitLab comme plate-forme d’h´ebergement de r´ef´erentiels de contrˆole de version.

1.4.1

Framework et langages

Angular Angular est un Framework open source ´ecrit en JavaScript qui permet la cr´eation d’applications Web et plus particuli`erement de ce qu’on appelle des « Single Page Applications » des applications web accessibles via une page web unique qui permet de fluidifier l’exp´erience utilisateur et d’´eviter les chargements de pages `a 11

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

chaque nouvelle action.Le Framework est bas´e sur une architecture du type MVVM et permet donc de s´eparer les donn´ees, le visuel et les actions pour une meilleure gestion des responsabilit´es. Un type d’architecture qui a largement fait ses preuves et qui permet une forte maintenabilit´e et une am´elioration du travail collaboratif [3].

Spring boot Spring Boot est un framework qui facilite le d´eveloppement d’applications fond´ees sur Spring en offrant des outils permettant d’obtenir une application packag´ee en jar , totalement autonome. il int`egre directement Tomcat, Jetty ou Undertow et fournit des d´ependances de ”d´emarreur” avis´ees pour simplifier la configuration de construction. Il configure automatiquement les biblioth`eques Spring et tierces autant que possible, et il fournit des fonctionnalit´es prˆetes `a la production telles que les mesures [4].

1.4.2

Environnement logiciel

Mysql MySQL est un serveur de bases de donn´ees relationnelles Open Source. c’est un serveur de bases de donn´ees stocke les donn´ees dans des tables s´epar´ees plutˆot que de tout rassembler dans une seule table. Cela am´eliore la rapidit´e et la souplesse de l’ensemble. Les tables sont reli´ees par des relations d´efinies, qui rendent possible la combinaison de donn´ees entre plusieurs tables durant une requˆete. Le SQL dans ”MySQL” signifie ”Structured Query Language” : le langage standard pour les traitements de bases de donn´ees [7].

12

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

Visual Studio Code C’est un ´editeur de code open-source, gratuit et multi-plateforme (Windows, Mac et Linux), d´evelopp´e par Microsoft. Il est principalement con¸cu pour le d´eveloppement d’application avec JavaScript, TypeScript et Node.js. L’´editeur peut s’adapter a` d’autres types de langages grˆace a` un syst`eme d’extension bien fourni.

Eclipse Eclipse est un IDE, Integrated Development Environment (EDI environnement de d´eveloppement int´egr´e en fran¸cais), c’est un logiciel qui simplifie la programmation en proposant un certain nombre de raccourcis et d’aide `a la programmation. Il est d´evelopp´e par IBM, est gratuit et disponible pour la plupart des syst`emes d’exploitation. Au fur et `a mesure que vous programmez, eclipse compile automatiquement le code que vous ´ecrivez, en soulignant en rouge ou jaune les probl`eme qu’il d´ec`ele. Il souligne en rouge les parties du programme qui ne compilent pas, et en jaune les parties qui compilent mais peuvent ´eventuellement poser probl`eme (on dit qu’eclipse l`eve un avertissement, ou warning en anglais). Pendant l’´ecriture du code, cela peut sembler un peu d´eroutant au d´ebut, puisque tant que la ligne de code n’est pas termin´ee (en gros jusqu’au point-virgule), eclipse indique une erreur dans le code [5].

Git Git est un syst`eme de contrˆole de versions pour le d´eveloppement de logiciels qui a ´et´e initialement con¸cu et d´evelopp´e par Linus Torvalds. Il permet et encourage a` avoir plusieurs d´epˆots locaux pouvant ˆetre enti`erement ind´ependantes les unes des autres. La cr´eation, la fusion et la suppression de ces lignes de d´eveloppement se fait en quelques secondes. Le Git facilite le travail en groupe grˆace aux pull

13

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

requests qui simplifient les revues de code, ce qui garantit un code de meilleure qualit´e et permet de partager des connaissances dans l’´equipe [6].

GitLab Gitlab, c’est une plateforme permettant d’h´eberger et de g´erer des projets web de A a` Z. Pr´esent´ee comme la plateforme des d´eveloppeurs modernes, elle offre la possibilit´e de g´erer ses d´epˆots Git et ainsi de mieux appr´ehender la gestion des versions de vos codes sources.

1.5

M´ethodologie de d´eveloppement adopt´ee

La finalisation du projet dans les d´elais de livraison est la pr´eoccupation majeure de chaque d´eveloppement logiciel. L’un des probl`emes les plus courants rencontr´es lors de la cr´eation des logiciels est la mauvaise sp´ecification et changement soudain des exigences. Cela peut influencer non seulement sur l’´equipe de d´eveloppement en cr´eant une situation stressante pour l’environnement, mais aussi le temps pass´e sur le projet et donc d´epass´e les d´elais de livraison. ´ Etant une approche incr´ementale et it´erative, la m´ethode agile est mise en œuvre dans l’esprit collaboratif. Il contribue a` la r´ealisation d’un produit de haute qualit´e sans oublier les besoins des clients. D´eriv´e du Manifeste Agile, le d´eveloppement Agile a ´et´e ´ecrit au d´ebut des ann´ees 2000 par une ´equipe de Scrum cr´eateurs, Dynamic Systems Development Method (DSDM), Extreme Programming (XP), et bien d’autres leaders de l’industrie du logiciel.

14

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

1.5.1

Pr´esentation de la m´ethodologie choisie

Suite au tableau comparatif entre les m´ethodes agiles que nous avons ´elabor´e ci-dessus,nous avons choisi le Scrum qui est it´eratif et incr´emental pour s’adapter aux ´evolutions des fonctionnalit´es. Le principe de la m´ethode agile SCRUM est de concentrer l’´equipe de d´eveloppement sur un ensemble de fonctionnalit´es de mani`ere it´erative, chaque it´eration est d’une dur´ee de deux a` quatre semaines, appel´ees 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 m´ethode SCRUM, il faut : — Tout d’abord, identifier le maximum de fonctionnalit´es a` r´ealiser pour constituer le carnet du produit. — Deuxi`emement, d´efinir les priorit´es des fonctionnalit´es et choisir celles qui seront ex´ecut´ees `a chaque it´eration

15

´ ´ ERAL ´ CHAPITRE 1. PRESENTATION DU CADRE GEN DE PROJET

— Par la suite, se concentrer it´erativement sur toutes les fonctionnalit´es `a r´ealiser dans des it´erations appel´ees Sprints. Unsprint se traduit toujours par livraison d’un produit partiel fonctionnel appel´e incr´ement. Ainsi, vers la fin de chaque Sprint, une rencontre aura lieu pour revoir l’it´eration. Le but de cette r´eunion est de valider l’incr´ement qui ´etait produit lors de l’it´eration.

1.6

Conclusion

Tout au long de ce chapitre, nous avons pr´esent´e l’organisme d’accueil et une br`eve description du projet `a traiter, identifier le probl`eme et proposer la solution envisag´ee pour se faire face a` la situation actuelle. Par la suite, nous avons pr´esent´e une comparaison entre les m´ethodologies de d´eveloppement existantes pour rendre le choix de la m´ethodologie adopt´e au d´eveloppement de notre syst`eme plus facile. Le prochain chapitre sera consacr´e a` l’´etude des besoins fonctionnels et non fonctionnelset la sp´ecification du Product Backlog

16

Chapitre 2 Analyse et Sp´ecification des Besoins Introduction Apr`es avoir op´er´e une ´etude pr´eliminaire, nous abordons la section de sp´ecification des besoins. En effet, c’est au cours de celle-ci que les axes lies a` la r´ealisation du projet sont pr´esent´es. Tout d’abord, nous d´evelopperons une ´etude contextuelle dans laquelle nous identifions les besoins fonctionnels et non fonctionnels, les acteurs de notre application. Par la suite,Nous planifierons le projet en se basant sur le Product Backlog. Enfin, nous clˆoturons le chapitre en pr´esentant l’architecture g´en´erale de notre application.

2.1

Sp´ecification des besoins

Dans cette partie, nous d´efinissons les besoins auxquels l’application doit r´epondre. Pour ce faire, nous d´egagerons d’une part les besoins fonctionnels et d’autre part les besoins non fonctionnels,ainsi que l’identification des acteurs pour la r´ealisation de notre application

17

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

2.1.1

Besoins fonctionnels

Apr`es avoir des r´eunions successives avec le Product Owner, nous avons pu extraire les fonctionnalit´es que notre solution doit avoir. L’application alors doit n´ecessairement r´epondre aux besoins fonctionnels suivants : 1. S´ecurit´e : l’une des fonctionnalit´es les plus importantes de cette application est d’augmenter la s´ecurit´e afin de prot´eger les fonctionnalit´es requises par la plateforme, tout utilisateur de l’application doit avoir un compte activ´e.

2. Administration :Ce module permettra a` l’administrateur de visualiser, modifier,supprimer et activer ou d´esactiver les comptes utilisateurs de l’application,aussi de g´erer l’organigramme de la banque et de consulter l’historique de navigation.

3. Responsable : Ce module permettra au responsable de cr´eer son budget d´etaill´e, aussi de choisir le type de budget soit d´epense ou recette , il lui permettra ´egalement de r´eviser le budget avec le directeur du contrˆole de gestion.

4. Directeur g´en´erale :Ce module permettra au directeur g´en´eral de n´egocier le budget avec le responsable et le directeur du contrˆole de gestion afin de le valider et de le passer au vote pour l’approuver.

5. Pr´esident du conseil :Ce module permettra au pr´esident du conseil d’approuver le budget apr`es le vote qui est effectu´e par les membres du conseil avec le directeur g´en´eral

18

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

2.1.2

Besoins non fonctionnels

En plus des besoins fonctionnels que notre futur application doit fournir, il existe ´egalement un ensemble de contraintes qui doivent ˆetre respect´ees, et qui pr´esentent une propri´et´e qualifiante du projet. Parmi ces exigences nous distinguons : 1. La disponibilit´e : Notre application doit ˆetre fonctionnel et garantit un acc`es aux services et aux ressources avec un temps de r´eponse ad´equat.

2. Maintenabilit´e et ´evolutivit´e :L’application doit permettre une maintenance simple et facile et il doit ˆetre susceptible `a s’´evaluer d’une mani`ere plus ais´ee. Ainsi, nous avons essay´e de simplifier notre code le plus possible, le commenter et le structurer dans des diff´erents fichiers et dossiers.

3. Int´egrit´e :les informations contenues dans lapplication ne doivent pas ˆetre modifi´ees en raison d’erreurs.

4. Performance :l’application doit fournir un temps de r´eponse minimum. Cela n´ecessite un d´eveloppement orient´e optimisations ainsi que la mise `a disposition des ressources mat´erielles n´ecessaires.

5. Gestion des erreurs : l’application doit mieux g´erer ces exceptions par l’apparition des messages d’alerte.

6. S´ecurit´e : l’acc`es aux diff´erentes fonctionnalit´es de la solution n’est favorable qu’apr`es une ´etape d’authentification s´ecuris´ee. Le syst`eme doit ˆetre prot´eg´e contre les fraudes de modification, suppression, etc. 19

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

2.1.3

Identification des acteurs

Un acteur est un ´el´ement externe qui interagit avec le syst`eme pour obtenir un r´esultat. Il prend des d´ecisions et initiatives. Dans le cas de notre projet, les acteurs varient en fonction de leurs besoins et des services qu’ils sont all´es consommer de l’application. Les acteurs qui interagissent ont en commun des fonctionnalit´es qui nous avons identifi´e ce qui sera d´etaill´e 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 charg´e de cr´eer les comptes et ,d´efinir les droits d’acc`es des utilisateurs et cr´eer l’organigramme de la banque. Il a une visibilit´e totale sur les comptes des responsables ainsi que leurs budgets qu’ils ont d´efinis.il participe aussi `a la phase de r´evison et n´egociation des budgets. — Responsable :C’est le responsable de la gestion d’un budget .Il participe aussi a` la phase de r´evison et n´egociation des budgets. — Directeur g´en´erale : Il participe `a la phase de n´egociation d’un budget enfin il le valide.Il participe ´egalement a` la phase d’approbation avec les membres du conseil. — Pr´esident du conseil : il est responsable de l’approbation d’un budget apr`es le vote qui est effectu´e par les membres du conseil avec le directeur g´en´eral

2.2

Analyse globale

L’´etape d’analyse repr´esente la premi`ere phase du cycle de d´eveloppement logiciel. Dans cette partie, nous utilisons le langage de mod´elisation unifi´e comme moyen simple et compr´ehensible de formuler les principaux cas d’utilisation offerts 20

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

par notre syst`eme ainsi que le diagramme de classes d’analyse qui repr´esente les entit´es manipul´ees par les utilisateurs.

2.2.1

Diagramme de cas d’utilisation global

Nous pr´esentons dans la figure 2.1 une vue globale concernant le comportement fonctionnel de l’application. Ce diagramme permet ´egalement de repr´esenter les interactions entre les acteurs et les cas d’utilisation du syst`eme.

Figure 2.1 – Diagramme de cas d’utilisation global

21

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

2.3

Pilotage du projet par Scrum

Une bonne planification du travail est tr`es importante pour aboutir `a un bon projet. Dans cette partie, nous allons identifier les membres de l’´equipe, ´elaborer le Backlog du produit et pr´esenter le d´ecoupage de notre projet en des sprints.

2.3.1

Backlog du produit

Le Product Backlog est une liste hi´erarchis´ee des besoins et des exigences du client. Les ´el´ements du Product Backlog, ´egalement appel´es user stories, sont formul´es en une ou deux phrases d´ecrivant d’une mani`ere claire et pr´ecise les fonctionnalit´es souhait´ees par le client. C’est a` travers le Product Backlog que s’´etablit une vue g´en´erale sur tous les besoins du client que l’´equipe projet doit r´ealiser. Habituellement, ´ecrit sous la forme suivante « En tant que X,je veux Y, donc Z». ` chaque sprint, l’´equipe de d´eveloppement part d’une partie de fonctionnalit´es A extraites du Product Backlog afin de les r´ealiser et livrer a` sa fin un produit contenant ces fonctionnalit´es. Par la suite une description des termes utilis´es dans le Product Backlog : — Fonctionnalit´e :Cette colonne contient les besoins fonctionnels initiaux fix´es auparavant. — ID :C’est un identifiant unique pour chaque fonctionnalit´e. — User story : Il s’agit d’une phrase d´ecrivant la fonctionnalit´e souhait´ee par le client. — Priority : C’est une approximation de l’effort essentiel `a la r´ealisation d’une story selon les attentes et les besoins du client.

22

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

23

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

24

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

Figure 2.2 – Le backlog du produit

2.4 2.4.1

Architecture des microservices Concept de base

L’architecture des microservices est un mod`ele de conception qui d´ecompose une application complexe en plusieurs processus ind´ependants et faiblement coupl´es, tous sp´ecialis´es dans une seule tˆache. Ceux-ci sont appel´es microservices. Ils sont souvent li´es par des API REST via le protocole HTTP. Cette architecture diff`ere de l’architecture monolithique qui centralise tous les besoins en un seul processus. La figure 2.3 illustre la diff´erence entre une application monolithique et une application bas´ee sur microservices. 25

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

Figure 2.3 – Diff´erence entre l’approche monolithique et l’approche microservices [8]

L’approche monolithique a un processus unique qui g`ere toutes les fonctionnalit´es. D’autre part, une application bas´ee sur l’architecture microservices est compos´ee 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 ´et´e invent´ee pour r´esoudre certains probl`emes rencontr´es notamment au niveau de grands projets parmi eux : — Extensibilit´e :plus un projet est gros, plus il devient coˆ uteux et risqu´e. Le risque est d’ˆetre dans un projet qui ne peut pas ˆetre modifi´e pour un nouveau cas d’utilisation. En utilisant l’architecture des microservices, il est plus facile d’augmenter l’extensibilit´e en changeant le code ou en le r´e´ecrivant compl`etement selon le nouveau besoin puisque l’application est 26

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

d´ecompos´ee en un processus de taille limit´ee. ´ — Evolutivit´ e : :dans une application, certaines fonctionnalit´es sont utilis´ees plus que d’autres. Diviser l’application en microservices permet de dupliquer un service requis plutˆot que d’impl´ementer une redondance de l’ensemble de l’application.

— Maintenabilit´e : A mesure que la taille du code augmente, le code devient plus complexe. Cela rend plus difficile d’ajouter de nouvelles fonctionnalit´es 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.

— Productivit´e et rapidit´e am´elior´ees : l’architecture microservices s’attaque au probl`eme de la productivit´e et la vitesse de d´eveloppement en d´ecomposant les applications en services g´erables qui sont plus rapides `a d´evelopper. Les ´equipes peuvent travailler simultan´ement sur diff´erents composants sans attendre aucune autre ´equipe termine un morceau de travail. Les microservices s´epar´es sont plus faciles a` localiser et a` modifier. Ce type d’architecture est ´egalement tr`es pratique pour acc´el´erer l’assurance qualit´e puisque chaque microservice peuvent ˆetre test´es individuellement et vous pouvez tester les composants qui ont d´ej`a ´et´e d´evelopp´es lorsque les programmeurs travaillent sur les autres.

27

´ CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS

2.5

Conclusion

Ce chapitre r´esume la phase d’analyse des besoins que nous avons ´etablie avant de commencer la phase de d´eveloppement de notre application.Nous avons d’abord identifi´e les besoins fonctionnels et non fonctionnels, puis nous avons identifi´e les acteurs qui interagissent avec l’application. Ensuite nous avons pr´esent´e l’architecture mod`ele 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