Introduction Générale

Dans un monde de plus en plus moderne, disposer un crédit aujourd’hui c’est devenu
une chose bien nécessaire. En demandant un crédit, vous pouvez disposer bénéficiez
d’une multitude d’avantages pour faciliter la gestion de prêt.

Ce rapport est composé, hormis la précédente introduction, de Cinque chapitres dont

les lignes directrices sont esquissées ci-après.

Le premier chapitre intitulé « Entreprise d’accueil et problématique traitée » présente

la présentation de l’entreprise. Ainsi que la problématique traitée, le travail demandé et
une solution proposée avec le modèle cycle de vie d’un logiciel, en trouve aussi le choix
de méthodologie adopté pour la réalisation du projet avec le chronogramme de
réalisation.

Le second chapitre, intitulé « Analyse des besoins et conception », on va faire un

suivi par une étude de l’existant qui nous permet de fixer les de notre système et de faire
le découpage de projet selon la méthodologie Scrum.
Le troisième chapitre, intitulé « Etude et réalisation de sprint 1 », nous décrivons les
fonctionnalités détaillées de sprint 1 avec une conception détaillée, justifier par des
prototypes d’interface et la phase de réalisation.

Le quatrième chapitre, intitulé « Etude et réalisation de sprint 2 » dans ce chapitre

nous permet de faire les mêmes étapes que le chapitre précédent.

Le dernier chapitre de ce rapport présente une description de l’environnement du

travail et aussi des outils utilisés lors du développement.

Notre Application est réalisée dans le cadre du projet de fin d’étude ayant comme
objectif principal : Développement d’une application web la gestion de prêt avec une
système de chat.

1
 Chapitre 1 : Entreprise et problématique traitée

1.1.Introduction

Ce chapitre est représenté en deux parties, tout d’abord on va introduire la société qui
m’a pris en charge dans la période de stage, puis je présente l’entreprise et la
problématique traité.

1.2.Présentation de l’entreprise

1.3.Problématique traitée

Suite à la continuation des ravages à cause du nouveau coronavirus la procédure de

gestion de prêts est retardée, car elle devient nécessitée beaucoup plus de temps pour
que le comité accepte le dossier Ainsi que le client aussi

Préparer son dossier car il y a toujours les exceptions des situations des clients et
l'impatience pour savoir l'état de leurs dossiers. Dans ce contexte, on ne saurait
négliger le rôle d'outils et de solutions de gestion des risques abordables (notamment
numériques) qui favorisent l'inclusion financière et aident à faire face aux effets
immédiats et à long terme de la pandémie.

1.4.Travail demandé

Aujourd’hui avec la vulgarisation d’Internet, il est désormais facile de consulter son

compte, de commander et choisir le type de crédits que vous nécessitez, chat avec un
consultant pour vous aider en cas que vous avez des questions, consulter l’historique
de votre crédit sans se déplacer dans une agence. Cependant, tout cela sera fait par
une systémie contient des administrateurs pour gérer la saisie des données,
l'administrateur peut ajouter du personnel pour surveiller l'application, supprimer la

2
 mise à jour, chat avec le client, vérifier les intérêts des prêts et vérifier les types de
prêts.

En effet, avec un simple accès à distance, il est possible d’effectuer des opérations
courantes et avec une relative sécurité. C’est pourquoi dans le cadre dans le cadre du
projet de fin d’étude ayant comme objectif principal : Développement Web Gestion de
Prêts offrant les fonctionnalités suivantes :

• Gestion des prêts

• Gestion des emprunteurs

• Gestion des types de prêt

• Gestion des utilisateurs

• Chat instantanée

1.5.Méthodologie Utilisée

1.5.1. Méthode Agile

Une méthode Agile est une approche itérative et collaborative, capable de prendre en
compte les besoins initiaux du client et ceux liés aux évolutions.

Le principe de base consiste à proposer une version minimale du logiciel

puis à intégrer des fonctionnalités supplémentaires à cette base, par
processus itératif. Le processus itératif regroupe une séquence d’instructions
à répéter autant de fois que possible, selon le besoin. En ce qui concerne la
réalisation d’un logiciel, les instructions à répéter sont les suivantes :

• Les tests unitaires à la fin de chaque itération

• Le développement de l’application web
• L’intégration
• La relecture et amélioration des codes

3
1.5.2. Scrum

Scrum est la méthode agile la plus populaire. Ce terme signifie « mêlée » au

rugby. La méthode scrum s’appuie sur des « sprints » qui sont des espaces
temps assez courts pouvant aller de quelques heures jusqu’à un mois.
Généralement et de préférence un sprint s’étend sur deux semaines. À la fin
de chaque sprint, l’équipe présente ce qu’elle a ajouté au produit. Scrum
regroupe trois acteurs :

• Le Product Owner : qui porte la vision du produit à réaliser

(représente généralement le client). Il gère le Backlog du Produit,
défini des priorités et accepte ou rejette les livrables
• Le Scrum Master : membre de l’équipe, il a pour but d’optimiser
la capacité de production de l’équipe. Pour se faire, le scrum master
aide l’équipe à travailler de façon autonome tout en s’améliorant
d’avantage.
• L’équipe opérationnelle (qui regroupe idéalement moins de dix
personnes) : la particularité d’une équipe scrum est qu’elle est
dépourvue de toute hiérarchie interne. Une équipe scrum est
autoorganisé.

Figure 1:Schéma de processus Scrum (2)

4
D’autres termes sont à connaître pour comprendre la méthode scrum :

• Product Backlog (carnet du produit) : ce document contient les

exigences initiales dressées puis hiérarchisées avec le client en début de
projet. Néanmoins il va évoluer tout au long de la durée du projet, en
fonction des divers besoins du client.

• Sprint Backlog (carnet de sprint) : en chaque début de sprint, l’équipe

définit un but. Puis lors de la réunion de sprint, l’équipe de
développement choisit les éléments du carnet à réaliser.

L’ensemble de ces éléments constitue alors le sprint backlog :

• User story : ce terme désigne les fonctionnalités décrites par le client.

• Stand up meeting (scrum) : c’est une réunion d’avancement organisée

de manière quotidienne durant le sprint.

Figure 2:Répartition des rôles dans SCRUM

5
En clair, la méthodologie Agile est une méthode moderne, favorisant un gain de
productivité non négligeable, et la baisse des coûts de production

1.5.3. Modélisation avec UML

1.5.3.1.Définition UML

UML (Unified Modeling Langage) : Se définit comme un langage de modélisation

graphique et textuel destiné à comprendre et décrire des besoins, spécifier, concevoir des
solutions et communiquer des points de vue.

UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas d’une simple
notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont
porteurs de sens au même titre que les mots d’un langage, c’est pour ça qu’UML est présenté
parfois comme une méthode alors qu’il ne l’est absolument pas.

UML unifie également les notations nécessaires aux différentes activités d’un processus de
développement et offre, par ce biais, le moyen d’établir le suivi des décisions prises, depuis
la définition des besoins jusqu’au codage.

1.5.3.2.Les Diagrammes de UML

Ci-dessous une présentation rapide des différents diagrammes UML qui vont être utilisés
tout au long du projet :

Le diagramme des cas d’utilisation : Il représente la structure des fonctionnalités

nécessaires aux utilisateurs du système. Il est normalement utilisé lors des étapes de
capture des besoins fonctionnels et techniques ;

Le diagramme de classes : Sûrement l’un des diagrammes les plus importants dans un

6
développement orienté objet. Sur la branche fonctionnelle, ce diagramme est prévu pour
développer la structure des entités manipulées par les utilisateurs. En conception, le
diagramme de classes représente la structure d’un code orienté objet.

Le diagramme de séquences : Il représente les échanges de messages entre objets, dans

le cadre d’un fonctionnement particulier du système.

1.6.Chronogramme de réalisation

1.7.Conclusion

Dans ce premier chapitre, j’ai présenté l’entreprise, dégagé les différentes lacunes ainsi
que la solution envisagée. On a décrit le cycle de vie qui nous guidera dans la conception
de notre application. Finalement j’ai dégagé le chronogramme de réalisation. Maintenant
nous sommes en mesure d’entamer notre deuxième chapitre qui n’est d’autre que la
première phase de notre cycle.

7
 Chapitre 2 : Analyse des besoins et conception

2.1. Introduction

Dans ce deuxième chapitre, nous allons déterminer les principaux besoins, les ressources
à déployer ainsi que l’architecture générale de notre système.

La phase planification et spécification des besoins est primordiale pour réussir la

conception. En effet une description détaillée des besoins facilite la phase développement
du travail et la communication entre le client et le développeur.

Cette analyse se base sur les résultats de l’étude de l’existant, qui nous a permis d’une
part d’évaluer le système actuel en percevant ses besoins et d’autre part de décrire le bon
comportement que doit avoir le nouveau système.

2.2. Etude de l’existant

Amené à guider la banque dans son exercice et dans sa stratégie, le département « prêts » joue un
rôle primordial dans le déroulement de son activité, que ce soit dans la distribution des crédits (les
gestions de prêts), dans les opérations sur type des crédit (Plans de prêt / Type de prêt), processus
ou même des opérateurs (gestion des emprunteurs). Donc L'entreprise est un système complexe
dans lequel transitent de très nombreux flux d'information. Sans un dispositif de ce flux l'entreprise
peut très vite être dépassée et ne plus fonctionner avec une qualité et quantité de service
satisfaisante. La banque est donc une institution dont la principale mission consiste à mobiliser
l'épargne à la fructifier par des prêts ou crédits qu'elle accorde aux opérateurs qui en éprouve leurs
besoins. Les épargnants sont libres de retirer leurs économies, mais comme tous ne se présentent
pas au même moment lors du retrait, la banque peut donc utiliser une partie du capital constitué
pour satisfaire les demandeurs d'argent sous forme des prêts ou des crédits, de cela, il en découle
la mise en place d'un système de contrôle et de suivi du circuit des crédits accordés.

8
Départ la complexité des opérations effectuées par la banque dont notamment le contrôle et
les suivies d'octroi des crédits qui causent comme problème de gestion au sein des
institutions. Cependant, nonobstant les avantages incontestables de l'ordinateur, beaucoup
d'entreprises congolaises en général, et celles de Bukavu en particulier, n'exploitent pas
encore cet instrument de gestion, malgré tout, des grandes entreprises bancaires se trouvent
parmi celles qui ne l'utilisent pas. En revanche, il y a eu un changement significatif dans le
niveau de communication avec le client en raison du Coronavirus.

Dans cette rubrique, nous allons concevoir, développer et implémenter une application Web. Son
objectif principal est de gérer les prêts à l'aide du système de chat.

2.3. Analyse (ou spécification) des besoins

C’est une partie du cycle de vie du logiciel caractérisée par la détermination des besoins
fonctionnels et non fonctionnels exprimant les exigences de l’utilisateur. Cette tâche est
suivie d’une modélisation des fonctions du système par différents diagrammes.

2.3.1. Les besoins fonctionnels

Les besoins fonctionnels doivent répondre aux exigences mises en place du système en
matière de fonctionnalités. Ils constituent une sorte de promesse ou de contrat au
comportement du système généré. Voici les besoins fonctionnels que l’application doit
assurer et satisfaire.

➢ Chat instantanée

- Formulaire d’inscription des utilisateurs

- Module utilisateur
9
- Module de chat
- Chat instantanée avec web socket

➢ Gestion Des Prêts

- Ajouter un prêt
- Afficher la liste des prêts
- Modifier prêts
- Supprimer un prêt

➢ Gestion De Type

- Ajouter un type
- Afficher la liste des types
- Modifier un type
- Supprimer un type

➢ Gestion des users

❖ On tant que Admin

- Ajouter un user
- Modifier le profile
- Supprimer un user
- Afficher la liste des user
-Consulter le profile
-Recevoir des messages
-Envoyer des messages
- Gérer les types
- Gérer les prêts
❖ On tant que Client

10
 -Consulter le profile
- Modifier le profile
-Recevoir des messages
-Envoyer des messages

2.3.2. Les besoins non fonctionnels

• Sécurité : Assurer la sécurité des informations personnelles des clients et toutes

les opérations administratives ;
• Performance : Réduire le temps de réponse (le chargement de pages, affichage
des résultats et des délais de rafraîchissement) ;
• Fiabilité : Avoir un temps moyen de rétablissement acceptable en cas de panne.
• L’ergonomie : Les interfaces permettant la présentation de l'évolution des
données doivent être conviviales et assurer une navigation aisée .
• Design : le style des standards de l’interface : un design moderne, des pages
claires, des images significatives et des couleurs attirantes.

2.3.3. Description des Acteurs

Un acteur modélise le type de rôle joué par une entité qui interagit avec le système
modélisé. L'acteur est toujours externe au système modélisé. Un acteur peut représenter le
rôle joué par un humain, un appareil informatique .

Dans notre système, on a un deux acteurs principaux qu’on a défini Dans le tableau suivant :

11
Acteur Description Rôle

C’est une personne physique qui travaille
dans le poste Contrôle de gestion Et qui à
pour mission de pilotage budgétaire
Contribuer à l’amélioration de la
Admin performance économique d'entreprise.
Il doit gérer les prêts avec
engagement et réception de
chaque prêt en communication
avec le client.

Le client bancaire représente un facteur Il peut demander un prêt et

déterminant, primordial dans toute contacter le responsable de la
recherche effectuée en marketing bancaire. banque

Client

Tableau 1:Tableau des acteurs

2.3.4. Diagrammes de cas d’utilisation Général

12
Figure 4 : Diagramme de cas D’utilisation Général

13
 2.3.5. Pilotage du projet avec SCRUM

❖ Equipe et Rôle

Nous illustrons dans le tableau suivant les différents acteurs participant au déroulement de
ma projet et leurs rôles respectifs.

Acteur Rôle Mission

Avedia Product Owner C’est lui qui donner la direction,

Définir et prioriser la
liste des Fonctionnalité du
produit.

Ms. Faouzi Ben Hamida Scrum Master Optimiser la capacité de production de

l’équipe en l’aidant à travailler de
Ms. Saber Daagi façon autonome et à s’améliorer
constamment.

Wejdene Bedoui Equipe Scrum Développer une application web

gestion des prêts avec System chat,
Faire une Analyse détaillé sur
l’existant, Conception Générale et
détaillé, Codage, test et validation et
documentation pour le travail.

Tableau 2:Tableau d'équipe

14
 ❖ Les Sprints du Projets

Comme on a déjà mentionné, on choisira la méthodologie agile de Scrum, Dans le cadre de

l'approche Scrum, les produits logiciels sont développés sous forme de sprints, et les sprints
sont quelques semaines de développement, se concentrant généralement sur certaines
fonctions. La structuration du notre projet consiste à diviser le projet en deux sprints afin
d'avoir des sous-parties dont la complexité est plus facilement maitrisable.

Sprint 1 Sprint 2

Gestion des prêts

Gestion Des Users

Chat System
Gestion des types

Gestion Des Users

15
 ❖ Backlog Product

Le Backlog du produit est l’artefact le plus important de Scrum. En effet, il s’agit de

l’ensemble des caractéristiques fonctionnelles ou techniques qui constituent le produit
souhaité.

Id User Story Estimation/semaine Priorité Sprint

1 En tant que admin, je souhaite ajouter un client 2 1 2

ou un autre admin.

2 En tant que admin, je veux modifier le profil 2 2 2

d’un user.

3 En tant que admin, je voudrais supprimer un 2 3 2

admin ou client spécifique.

4 En que admin lorsque les données sont bien 2 4 2

insérées je souhaite afficher la liste des user.

5 En tant que admin, je souhaite consulter le 2 5 2

profil d’un client ou d’un admin.

6 En tant que admin, je souhaite recevoir des 2 6 2

messages et envoyer des messages.

7 En tant que admin, je souhaite gérer les types 2 7 2

8 En tant que admin, je souhaite gérer 2 8 2

les prêts.

16
9 En tant que client je veux faire une mise a 2 9 2
Jour de mon profil.
10 En tant que client je veux consulter le profil. 2 10 2

11 En tant que client, je souhaite recevoir des 2 11 2

messages et envoyer des messages.

3:Tableau Backlog Product

2.5. Conclusion

Tout au long de ce chapitre, j’ai mis le projet dans son cadre. J’ai présenté, Les besoins fonctionnels
et non fonctionnels. Par la suite on a généré le produit Backlog ainsi que le plan de découpage de
projet.

17
18
 Chapitre 3 : Réalisation
3.1. Introduction

Dans cette partie de notre rapport nous allons focaliser sur l’environnement matériels, logiciel et
le choix technologiques de cette application.

3.2. Environnement matériel

Pendant la phase de développement j’ai utilisé :

❖ Modèle : DELL

• Processor: Intel i7 10TH GEN.

• Mémoire installée (RAM) :24 Go.
• Système d’exploitation : Windows 10 / 64bits.

3.3. Environnement logiciel

3.3.1. Environnement de développement intégré

Visual studio code : C’est un éditeur de code qui admet plusieurs langages de
programmation et qui offre plusieurs fonctionnalités. Il est considéré comme une open
source à multiplateforme. J’ai utilisé Visual Studio code pour développer avec le
Framework Angular.

Spring Tool Suite : est une application basée sur Eclipse facilitant la
création de projet Spring.Etant basée sur Eclipse, il existe naturellement un plugin qu'il est
possible d'installer.

19
3.3.2. Les logiciels utilisés

Visual Paradigm : c’est un outil de conception qui prend en charge le langage

UML. Cet outil nous a aidé à modéliser les diagrammes de séquence objet et les
diagrammes de séquence systèmes.

Postman : C’est un API testing, c’est-à-dire grâce à poste man nous pouvons
tester nos services avec des requêtes http avons de les consommer. Durant notre projet j’ai
validé nos services à l’aide de ce logiciel.

WAMP : rassemble les principaux logiciels pour mettre en place un

serveur personnel ou professionnel sur un ordinateur. Il est souvent utilisé pour le
développement.

3.4. Choix technologiques

On a dans cette étape détaillé les différents langages, outils et les Framework utilisés.

Angluar : est un Framework basé essentiellement sur le langage de

programmation libre Type Script. Donc Angular nous aide à la création des classes, des
variables, des interfaces et à l’importation des modules pour les utilisée. J’ai utilisé la
version 10.

Spring Boot : est un micro Framework utilisé pour faciliter la configuration

des projets Spring. Spring Boot est considéré comme un facteur majeur de la croissance de

20
développement rapide.

Spring Security : est un Framework léger de sécurité des projets

fondés sur spring. Il accomplit une Authentification. L’avantage principal de
SpringSecurity est la personnalisation de sécurité informatique.

Bootstrap : est un ensemble des outils utilisé pour la création du graphisme

de site ou d’application web.

HTML : Ce langage est utilisé pour créer des pages web. L'acronyme signifie
HyperText Markup Language. Ce langage permet de réaliser de l'hypertexte à base d'une
structure de balisage.

CSS : Le terme CSS est l'acronyme anglais de Cascading Style Sheets qui
peut se traduire par "feuilles de style en cascade".

21
 ❖ Architecture logicielle de l’application

Pour décrire d’une manière symbolique et schématique les différents éléments de

notre système leurs interrelations et leurs interactions, On l’architecture trois tiers qui
est élaboré pour mon application.

Figure 3:Architecture Logicielle

• Le premier tiers est la couche présentation associée au client qui

dispose d'un navigateur web et accède à l’application.

• Le 2ème tiers est la couche métier correspond à la partie

fonctionnelle de l'outil qui est déployée dans le serveur
d'application et qui est chargé de fournir la ressource mais
faisant appel à un autre serveur.

• Le 3ème tiers est la couche accès aux données, elle permet

de fournir au serveur d'application les données dont il a
besoin.

22
 ❖ L’architecture MVC

Modèle-vue-contrôleur ou MVC est un motif d'architecture logicielle destiné aux interfaces

graphiques .Le motif est composé de trois types de modules :

• Un modèle (Model) contient les données à afficher.

• Une vue (View) contient la présentation de l'interface graphique.
• Un contrôleur (Controller) contient la logique concernant les actions effectuées par
l'utilisateur.

Figure 4:Architecture MVC

23
 ❖ Diagramme De Déploiement

En vue de représenter l’aspect statique qui sert à modéliser l'utilisation de l'infrastructure physique
par le système et la manière dont les composants du système sont répartis ainsi que les relations
échangées entre eux.

Figure 5:Diagramme de déploiement

3.5. Conclusion

Dans ce chapitre j’ai mis l’accent sur l’environnement et outils de développement, Architecture
logicielle de l’application. Finalement j’ai dégagé le Diagramme de déploiement

24
 Chapitre 4 : Etude et réalisation de Sprint 1

4.1. Introduction

Dans le chapitre précédent, j’ai choisi d’adopter la méthodologie Scrum pour la conception de
notre futur Projet. Dans cette Partie on a spécifié le sprint 1 pour avoir des fonctionnalités claires
et correspondent avec les besoins de notre client et toutes les informations des services doit
importer dans l’application convenablement.

4.2. Spécification et analyse détaillés du Sprint 1

4.2.1. Le Sprint Backlog

Le sprint Backlog est un outil qui facilite la répartition des tâches et qui fait la mise au point du
travail Notre Backlog sprint se présente comme suit :

Id sprint Item Critère d’acceptation Priorité Estimation /jours

1.1 Insérer les Insertion avec succès et 1 1

données d’prêt sans perte d’information

1.2 Afficher la liste des Résultat identique à 2 1

Prêts l’existant

1.3 Modifier les prêts modification sans erreurs 3 1

1.4 Supprimer un prêt Suppression sans erreurs 4 1

2.1 Insérer les Insertion avec succès 1 1

données de type et sans perte
d’information

25
 2.2 Afficher la liste des Résultat identique à 2 1
Types l’existant
2.3 Modifier les types modification sans erreurs 3 1

2.4 Supprimer un type Suppression sans erreurs 4 1

3.1 Ajouter un user Insertion avec succès et 1 1

sans perte d’information

3.2 Modifier le profile modification sans erreurs 3 1

3.3 Supprimer un user Suppression sans erreurs 4 1

3.4 Afficher la liste des Résultat identique à 2 1

users l’existant
3.5 Consulter le profile Consultation de profile 2 1

Tableau 4: Backlog Sprint 1

4.2.2. Diagramme de cas d’utilisation du Sprint1

Je présente ci-dessous un diagramme de cas d’utilisation de sprint 1

26
Figure 6:Diagramme De Cas D'Utilisation Sprint 1

27
Dans le but de mieux comprendre notre système et les interactions avec l’administrateurs, dans cette
partie nous allons détailler les scenarios de principaux cas d’utilisation.

Cas d’utilisations « Ajouter un prêts »

Acteur Administrateur

Pré-Condition Administrateur authentifié

Post-condition : Prêts ajouté.

Scénario nominal 1. L’administrateur s’authentifie

2. L’administrateur choisi le menu concerné : « Gestion des Prêts »

3. L’administrateur choisi l’action « Ajouter Prêt »

4. Le système affiche une nouvelle fenêtre contenant des champs pour la

description du prêt,

5. L’administrateur introduit les données du prêt à ajouter et confirme.

6. Le système vérifie les données saisies et ajoute le prêt.

Scénario alternative Les informations sont manquantes ou incorrectes : ce scénario commence au

point 6 du

Scénario nominal.

1 : Le système informe l’admin que les données saisies sont erronées, le

scénario reprend au point 4 du scénario nominal.

Tableau 5: description de cas d’utilisation « Ajouter un Prêt »

28
 Cas d’utilisations « Modifier Prêts »
Acteur Administrateur
Pré-Condition Administrateur authentifié

Post-condition Prêt modifié

1. L’administrateur s’authentifie
Scénario nominal
2. L’administrateur choisi le menu concerné : « Gestion des Prêts
»
3. L’administrateur choisi l’action « Modifier Prêt »
4. Le système affiche une nouvelle fenêtre contenant des champs
pour la description du cette cours
5. L’administrateur introduit les nouvelles données du prêt à
modifier et confirme.
6. Le système vérifie les données saisies et modifie le prêt.

Scénario alternative Les informations sont manquantes ou incorrectes : ce

scénario commence au point 6 du

Scénario nominal.
1 : Le système informe l’admin que les données saisies
sont erronées, garde les informations

Saisies avant et le scénario reprend au point 4 du scénario nominal.

Tableau 6:description de cas d’utilisation « Modifier un Prêt »

29
 Cas d’utilisation « Supprimer prêt»
Acteur Administrateur
Pré-Condition Administrateur authentifié

Post-condition : prêt supprimé.

1. L’administrateur s’authentifie
Scénario nominal
2. L’administrateur choisi le menu concerné : « Gestion des Prêts
»
3. L’administrateur cliquer sur le bouton supprimer d’un prêt
4. Le système supprimer le cour

Scénario alternative Le prêt n’a pas été supprimée

1 : Le système informe l’admin que prêt n’a pas supprimée et le
scénario reprend au point 2 du scénario nominal.

Tableau 7:Digramme de Cas D'Utilisation « Supprimer un Prêt »

4.2.3. Prototype des interfaces

Avant de commencer la phase d’analyse, on enchaine par quelque prototype d’interface pour bien
assimiler les fonctionnalités :

30
Figure 7: Prototype d’interface de Dashboard

Figure 8: Prototype d’interface d'Ajouter Prêt

31
Figure 9:Prototype d’interface d'Modifier Prêt

Figure 10:Prototype d'interface de Suppression

Figure 11:Prototype d'interface de Login

32
 4.3. Conception

4.3.1. Les diagrammes des séquences du Sprint (1)

Le diagramme de séquence système est une modélisation de la vue dynamique du système.

Ce diagramme reflète les interactions et les échanges entre un acteur et le système par des messages
dans leurs ordres chronologiques.

Figure 12: Diagramme de séquence objet « s’authentifier »

33
La figure 13 illustre le diagramme de séquence objet de cas d’utilisation « Ajouter Prêt »

Figure 13:Diagramme de séquence objet « ajouter un prêt »

34
 4.3.2. Diagramme d’activité

La figure 14 illustre le diagramme de séquence objet de cas d’utilisation « Gestion des Prêts »

Figure 14: Diagramme d’activité

❖ Explication du diagramme d’activité

- L’Administrateur doit être s’authentifié.

- L’Administrateur peut faire 4 fonctions pour gérer un prêt qui sont :
- Il peut insérer un prêt à l’aide d’un bouton « Ajouter »
- Ainsi, il est possible de faire une modification d’un prêt qui déjà inséré
dans la tâche précédente.
- Après l’insertion et la modification des données dans une base du
données l’administrateur peut afficher la liste des données des prêts qui
sont stocké.
- S’il nécessite de supprimer un prêt aussi il peut le faire la suppression
par un bouton « Supprimer ».

35
 4.3.3. Diagramme de classe de sprint (1) A voir pour les cardinalités

Le diagramme de classe est considéré comme le plus important de la modélisation orientée

objet, c'est le seul diagramme obligatoire lors d'une telle modélisation. Il permet de définir la
structure interne du système.

Figure 15:Diagramme de classe de sprint (1)

36
4.4. Schéma de la base de données

4.4.1. Table « User »

Attribut Type Description

id Long Identification de user

email String Email de user

fullname String Fullname de user

password String Password de user

phone String Phone de user

role String Role de user

type String Type de user

username String Username de user

Tableau 8:Table « User »

4.4.2. Table « Loan »

Attribut Type Description

id Long Identification de loan

deadline Date La date fine de Loan

Paid_amount Float Le montant payé de Loan

takenAt Date La date prise de Loan

status String Le status de loan

Tableau 9:Tabes « Loan »

37
 4.4.3. Tabes « Type »

Attribut Type Description

id Long Identification de type

nom String Nom de type

montant Double Le montant de type

tauxInterest Double Le taux d’intérêt de type

Tableau 10:Tabes « Type »

4.5. Test et Validation

Les tests, dans la méthode agile, sont essentiels au bon déroulement des développements. Afin
d'assurer la fiabilité des fonctionnalités développées, il est impensable de passer d’un sprint à un
autre sans pour autant l’avoir testé : les tests ont donc un rôle essentiel.

4.5.1. Portée

Dans cette partie, j’ai choisi de tester l’ajout d’un prêt par l’administrateur. L’ajout d’un
prêt ne se fait que si les champs obligatoires sont remplis. Je vais présenter les différents tests.

4.5.2. Inventaire des tests

ID Intitulé Descriptif

TS.1.0 S’authentifier Un admin déjà authentifié ne peut pas s’authentifié avec

un nouvel identifiant

TS.1.1 Contrôle d’ajout d’un Un prêt déjà existant ne permet pas d’ajouter un
prêt nouveau par le même identifiant.

Tableau 11:Inventaire de test

38
 4.5.3. Stratégie des tests

INTEGRITE DES Objectif L’unicité du prêt par identifiant de prêt

DONNEES
Technique Ajouter deux prêts au même identifiant

Critère de succès L’ajout est refusé et le prêt existant est

affiché

Considérations La module gestion des prêts est

particulières développé
Une insertion antérieure avec l’identifiant
utilisée est réussie.

FONCTIONNEL Objectif Ajout d’un Prêt

Technique Remplir un formulaire d’insertion

Critère de succès Ajout effectué avec succès – Création d’un

nouveau prêt

Considérations N.A
particulières

PERFORMANCE Objectif Non applicable pour cette portion de

l’application pour un projet de développement
Technique

Critère de succès

Considérations
particulières

39
 SECURITE Objectif Non applicable pour cette portion de
l’application pour un projet de développement
Technique

Critère de
succès

Considérations
particulières

INTERFACE Objectif Le formulaire d’insertion est simple avec bouton

UTILISATEUR d’ajout

Technique Remplir un formulaire d’inscription

Critère de Le passage d’un champ à une autre est contrôlé

succès Chaque champ manquant sont signalés par
une alerte sous forme de message Les
champs erronés sont signalés par une couleur
rouge

Considérations NA
particulières

Tableau 12:Stratégie de test

4.5.4. Cas De Test

Le texte en « Blue » donne un exemple d’un test réussi.

Le texte en « Rouge » donne un exemple d’un test erroné.

40
 ID Descriptif Valeur à saisir Valeur Valeur Résultat
observée attendue (OK/NOK)

TS.1.0.1 L’admin www.NowLoan/login La page La page OK

S’authentifier d’accueil est d’accueil est
affichée attendue

TS.1.0.2 L’admin clique Message « Redirection vers NOK

sur le bouton Echec le formulaire
ajouter prêt d’insertion
»

Tableau 13:Cas De Test

4.6. Burndown Chart

Figure 16:Burndown Chart Sprint 1

4.7. Conclusion

Dans ce chapitre j’ai mis l’accent sur la réalisation de sprint 1, j’ai présenté les cas d’utilisations,
détaillé la conception et en intégrant les interfaces de plateforme.

41