Dédicaces

J'aimerais dédier ce modeste travail, le fruit de mes efforts et ma réussite :

À mes chers parents Kamel et Mounira, vous m’avez donné la vie, la tendresse, le courage
de réussir, la confiance et le soutien pour tous les choix de ma vie, aucune dédicace ne peut
exprimer mes sentiments, mon respect, mon amour éternel. J’espère avoir répondu aux
espoirs que vous avez fondés en moi. En achevant le dernier maillon de mon long parcours
académique, j’espère être à la hauteur de votre support qui a toujours illuminé mon chemin
même dans les situations les plus sombres. Que Dieu vous préserve et vous donne la santé et
la longue vie.

A mon cher Ahmed, qui a toujours été présents pour m'encourager, j'ai une entière confiance
en vous et en vos capacités, votre sérieux et toutes vos qualités qui vous rendent digne de
réussite.

A mes frères, qui ont toujours été présents pour m'encourager.

À ma grande famille, votre amour est un honneur et une fierté pour moi. Je vous remercie
d’avoir embelli ma vie par des moments précieux de bonheur.

À mes amies, l'amitié vraie ne s'écrit pas, elle ne se dit pas, elle ne s'explique pas, tout
simplement elle se vit.
 Remerciement

Au titre de ce travail, Dieu soit loué qui m'a permis de mener à bien ce travail et pour m'avoir
donné le pouvoir d'être ce que je suis aujourd'hui (El-Hamdoullah)

Puis, je réserve ces quelques lignes pour exprimer mes sincères remerciements et ma
gratitude aux personnes qui m’ont apporté leur support et leur aide durant mon stage de PFE
et qui ont contribué au succès de ce travail.

Au terme de ce travail, je suis très redevable à l’équipe de ICstartup, en particulier à mon

superviseur Mr Jebali Makrem pour son encadrement, ses précieux conseils, sa disponibilité
et son soutien.

C’est un grand plaisir pour je à exprimer mes remerciements les plus sincères à Madame
Chaabani Marwa, pour la confiance qu’elle nous a accordée en acceptant de nous encadrer
pour réaliser ce projet de fin d’études ainsi que pour sa rigueur scientifique, son assistance
perpétuelle, ses précieux conseils et judicieuses critiques, tout au long de la réalisation de ce
travail.

Mes vifs remerciements vont également aux membres du jury pour avoir accepté d’examiner
mon travail et de l’enrichir par leurs propositions.

Enfin, je tenue également à remercier toutes les personnes qui ont participé de près ou de loin
à la réalisation de ce travail, je n’oublie pas mes parents pour leurs contributions, leurs
soutiens et leur patience.
Sommaire
Introduction generale ----------------------------------------------------------------------------------- 1
Chapitre 1 : Cadre general du projet et choix methodologique -------------------------------- 2
Introduction ----------------------------------------------------------------------------------------------- 2
I. Presentation de l’organisme de l’accueil ------------------------------------------------------- 2
1. Description de l’organisme d’accueil (ICSTARTUP) --------------------------------------- 2
2. Activités de la société ------------------------------------------------------------------------------- 2
3. Description du service informatique ------------------------------------------------------------ 4
II. Etude de l’existant ------------------------------------------------------------------------------- 4
1. Description de l’existant --------------------------------------------------------------------------- 4
2. Critique de l’existant ------------------------------------------------------------------------------- 5
3. Solution proposée ----------------------------------------------------------------------------------- 6
III. Methodologie de travail et langage de modelisation -------------------------------------- 7
1. Les méthodologies de travail traditionnelles VS Agiles ------------------------------------- 7
2. Méthodologie choisie : SCRUM ----------------------------------------------------------------- 8
3. Langage de modélisation : UML----------------------------------------------------------------- 9
Conclusion ------------------------------------------------------------------------------------------------ 10
Chapitre 2 : Sprint 0 : preparation des bases de projet ----------------------------------------- 11
I. Capture des besoins ------------------------------------------------------------------------------- 11
1. Identification des acteurs ---------------------------------------------------------------------- 11
2. Descriptions des besoins fonctionnels ------------------------------------------------------- 11
3. Description des besoins non-fonctionnels : ------------------------------------------------ 12
II. Diagramme de cas d’utilisation global ------------------------------------------------------ 13
III. Backlog Product ------------------------------------------------------------------------------ 15
IV. Planification des Sprints -------------------------------------------------------------------- 16
VI. Environnement de travail --------------------------------------------------------------------- 18
1. Environnement matériel ----------------------------------------------------------------------- 18
2. Environnements logiciels ---------------------------------------------------------------------- 18
2.1 Langages et Technologies ------------------------------------------------------------------- 18
2.2 Logiciels----------------------------------------------------------------------------------------- 19
2.3 Serveur d’application et serveur SGBD ------------------------------------------------- 20
VII. Architecture du système ----------------------------------------------------------------------- 21
VIII. Pilotage du projet avec SCRUM ---------------------------------------------------------- 22
Conclusion ------------------------------------------------------------------------------------------------ 23
Chapitre 3 : Sprint 1 « gestion des comptes des utilisateurs, authentification » ----------- 24
Introduction ---------------------------------------------------------------------------------------------- 24
I. Backlog Sprint -------------------------------------------------------------------------------------- 24
II. Diagrammes de cas d’utilisation détaillés du Sprint n°1 ------------------------------- 25
1. Raffinement des cas d’utilisation :----------------------------------------------------------- 26
2. Description textuelle du cas d'utilisation « Sprint 1 » : --------------------------------- 26
III. Diagrammes de séquence du Sprint n°1 ---------------------------------------------------- 28
1. Diagramme de séquence du cas « s’authentifier » --------------------------------------- 28
2. Diagramme de séquence du cas « Inscrire » d’un donateur --------------------------- 29
 3. Diagramme de séquence du cas « Modifier rôle » ---------------------------------------- 30
IV. Réalisation-------------------------------------------------------------------------------------- 31
Conclusion ------------------------------------------------------------------------------------------------ 34
Chapitre 4 : Sprint 2 « gestion des profils et d’utilisateurs » ---------------------------------- 35
Introduction ---------------------------------------------------------------------------------------------- 35
I. Backlog Sprint -------------------------------------------------------------------------------------- 35
II. Diagrammes de cas d’utilisation détaillés du Sprint n°2 ------------------------------- 36
1. Raffinement des cas d’utilisation :----------------------------------------------------------- 36
2. Description textuelle du cas d'utilisation « Sprint 2 » : --------------------------------- 37
III. Diagrammes de séquence du Sprint n°2 ---------------------------------------------------- 38
1. Diagramme de séquence du cas « Modifier Profil » ------------------------------------- 38
2. Diagramme de séquence du cas « Ajouter Association » ------------------------------- 38
3. Réalisation ---------------------------------------------------------------------------------------- 39
Conclusion ------------------------------------------------------------------------------------------------ 42
Chapitre 5 : Sprint 3 « gestion des dons » --------------------------------------------------------- 43
Introduction ---------------------------------------------------------------------------------------------- 43
I. Backlog Sprint -------------------------------------------------------------------------------------- 43
II. Diagrammes de cas d’utilisation détaillés du Sprint n°3 ------------------------------- 46
1. Raffinement des cas d’utilisation :----------------------------------------------------------- 47
2. Description textuelle du cas d'utilisation « Sprint 3 » : --------------------------------- 47
III. Diagrammes de séquence du Sprint n°3 ---------------------------------------------------- 49
1. Diagramme de séquence du cas « Ajouter Don » ----------------------------------------- 50
2. Diagramme de séquence du cas « Ajouter catégorie » ---------------------------------- 50
IV. Réalisation-------------------------------------------------------------------------------------- 51
Conclusion ------------------------------------------------------------------------------------------------ 56
Chapitre 6 : Sprint 4 « gestion des associations et des evenements » ------------------------ 57
Introduction ---------------------------------------------------------------------------------------------- 57
I. Backlog Sprint -------------------------------------------------------------------------------------- 57
II. Diagrammes de cas d’utilisation détaillés du Sprint n°4 ------------------------------- 59
1. Raffinement des cas d’utilisation :----------------------------------------------------------- 59
2. Description textuelle du cas d'utilisation « Sprint 4 » : --------------------------------- 59
V. Diagrammes de séquence du Sprint n°4 ------------------------------------------------------ 61
1. Diagramme de séquence du cas « Ajouter Evènements » ------------------------------ 61
2. Diagramme de séquence du cas « Afficher Evènements » ------------------------------ 62
3. Réalisation ---------------------------------------------------------------------------------------- 63
Conclusion ------------------------------------------------------------------------------------------------ 65
Conclusion generale ET Perspectives --------------------------------------------------------------- 66
Bibliographie --------------------------------------------------------------------------------------------- 67
 Les figures

Figure 1 : Site web de la jeune artiste, Sirine Mohamed ...................................................... 3

Figure 2 : Avicenne de la société suisse .................................................................................. 3
Figure 3 : Ecopack de la société italienne .............................................................................. 3
Figure 4 : Imprime d'écran d'un fichier Excel d'association ............................................... 5
Figure 5 : Méthodologie de conception en cascade ............................................................... 7
Figure 6 : Les différents rôles de Scrum et le déroulement du processus .......................... 9
Figure 7 : Diagramme de cas d'utilisation global ................................................................ 14
Figure 8: Diagramme de classe ............................................................................................. 17
Figure 9 : Architecture 3 tiers ............................................................................................... 21
Figure 10 : Architecture 3 tiers plus détaillée...................................................................... 22
Figure 11 : Equipe SCRUM .................................................................................................. 23
Figure 12 : Diagramme du cas d’utilisation détaillé « Sprint1 » ....................................... 26
Figure 13 : Diagramme de séquence de cas « s’authentifier ». .......................................... 29
Figure 14 : Diagramme de séquence du cas d’utilisation de s’inscrire ............................. 30
Figure 15 : Diagramme de séquence du cas d’utilisation de modifier rôle ....................... 31
Figure 16 : Interface d'inscription pour le donateur .......................................................... 32
Figure 17 : Interface d'authentification donateur ............................................................... 32
Figure 18 : Interface d'authentification admin ................................................................... 33
Figure 19 : Interface d'authentification association............................................................ 33
Figure 20 : Interface de gestion rôle ..................................................................................... 34
Figure 21 : Diagramme du cas d’utilisation détaillé « Sprint 2 » ...................................... 36
Figure 22 : Le diagramme de séquence du cas de modifier profil ..................................... 38
Figure 23 : Le diagramme de séquence du cas d’ajouter association ............................... 39
Figure 24: Interface ajouter association............................................................................... 39
Figure 25 : Interface de modifier profil pour l'association ................................................ 40
Figure 26 : Interface modifier profil pour l'admin ............................................................. 40
Figure 27 : Interface modifier profil pour le donateur ...................................................... 41
Figure 28 : Interface de gestion association ......................................................................... 41
Figure 29 : Interface gestion donateur ................................................................................. 42
Figure 30 : Diagramme du cas d’utilisation détaillé « Sprint 3 » ...................................... 47
Figure 31: Diagramme de séquence du cas d’utilisation d’ajouter don ........................... 50
Figure 32: Diagramme de séquence du cas d’ajouter catégorie ....................................... 51
Figure 33 : Interface de gestion catégorie ............................................................................ 52
Figure 34 : Interface de gestion type fourniture.................................................................. 52
Figure 35 : Interface de gestion don pour l'admin .............................................................. 53
Figure 36 : Interface de gestion fourniture .......................................................................... 53
Figure 37 : Interface de gestion don pour l'association ...................................................... 54
Figure 38 : Interface d'effectuer don .................................................................................... 54
Figure 39 : Interface d'ajouter les fournitures .................................................................... 55
Figure 40 : Interface de gestion don pour le donateur........................................................ 55
Figure 41 : Le diagramme du cas d’utilisation détaillé « Sprint 4 » ................................. 59
Figure 42 : Le diagramme de séquence du cas d’utilisation d’ajouter événement .......... 62
Figure 43 : Le diagramme de séquence du cas d’afficher événements ............................. 62
Figure 44: Interface de consulter les évènements pour le donateur et le visiteur ............ 63
Figure 45: Interface de consulter les évènements pour l'admin ........................................ 63
Figure 46: Interface de consulter les événements pour l'association................................. 64
Figure 47: Interface de consulter les associations pour le donateur et le visiteur ............ 64
Figure 48: Interface de tableau de bord pour l'association ................................................ 65
Figure 49: Interface de tableau de bord pour l'admin ....................................................... 65
 Liste des tableaux

Tableau 1 : Backlog Product ................................................................................................. 15

Tableau 2 : Planification des sprints .................................................................................... 17
Tableau 3 : Tableau des langages utilisés............................................................................. 18
Tableau 4 : Tableau des logiciels utilisés .............................................................................. 19
Tableau 5 : Tableau des serveurs utilisés ............................................................................. 20
Tableau 6 : Backlog sprint 1.................................................................................................. 24
Tableau 7 : Description textuelle du cas de « s’authentifier » ........................................... 26
Tableau 8 : Description textuelle du cas de « Ajouter rôle ».............................................. 27
Tableau 9 : Description textuelle du cas de « s’inscrire »................................................... 28
Tableau 10 : Backlog sprint 2................................................................................................ 35
Tableau 11 : Description textuelle du cas de « Ajouter d’Association » ........................... 37
Tableau 12 : Description textuelle du cas de « Modifier Profil » ....................................... 37
Tableau 13 : Backlog sprint 3................................................................................................ 43
Tableau 14 : La description textuelle du cas de « Ajouter Don » ...................................... 47
Tableau 15 : Description textuelle du cas de « Afficher listes des dons » ......................... 48
Tableau 16 : La description textuelle du cas de « Ajouter Type fourniture » .................. 48
Tableau 17 : La description textuelle du cas de « Valider don » ....................................... 49
Tableau 18 : Backlog sprint 4................................................................................................ 57
Tableau 19 : La description textuelle du cas de « Ajouter événements » ......................... 59
Tableau 20 : La description textuelle du cas de « Afficher listes des événements »......... 60
Tableau 21 : La description textuelle du cas de « Contacter Donateur » ......................... 60
Tableau 22 : La description textuelle du cas de « Afficher listes des associations » ........ 61
 Introduction générale

Ces dernières années, les innovations dans le domaine du développement web se sont
multipliées et ne cessent de se développer, la révolution informatique a balayé tous les pays
du monde, et cela concerne aussi notre pays la Tunisie qui a connu un indéniable fort
développement dans ce domaine. Pour cela, les ordinateurs sont devenus indispensables à la
communication.

Actuellement, le concept de don des fournitures scolaires existe déjà. Il y a beaucoup

d’associations qui se donnent pour mission de collecter des fournitures scolaires non usagées
et usagées à travers des moyens. Les difficultés auxquelles ils sont confrontés sont le manque
d'une plateforme spécifique pour les dons des fournitures scolaire. Dans ce cadre nous
sommes appelés durant notre projet de fin d’études à concevoir et à développer une solution
informatique permettant de mettre en place une plateforme de don des fournitures scolaire.
Cette application permettra à ces derniers de collecter les dons en ligne du public et de mettre
en relation les organismes de bienfaisance avec les donateurs les fournitures scolaires et aider
les associations à mieux gérer et collecter les dons.

Ce rapport détaillera les différentes phases afin d’aboutir à une application fiable et
satisfaisante, pour cela notre rapport sera composé de six chapitres organisés comme suit :

Le premier chapitre intitulé « Cadre général du projet et choix méthodologiques » est

consacré à la présentation du contexte du projet et le choix de la méthodologie Scrum pour la
phase de développement.

Le deuxième chapitre, « Sprint 0 : Préparation des bases du projet » s’articule autour de

l’identification des acteurs et la description des besoins fonctionnels et non fonctionnels. Puis,
nous élaborons le Backlog du produit et nous terminons par la présentation des architectures
et l’environnement de développement de notre application.

Le troisième, le quatrième, le cinquième et le sixième chapitre « Réalisation du Sprint »

mettent en œuvre les sprints Backlog associés à chaque sprint, les diagrammes de cas
d’utilisations et par les diagrammes de séquences ainsi que la réalisation. Enfin, nous
clôturons ce rapport par une conclusion générale ainsi que la proposition de quelques
perspectives sur lesquels peut s’ouvrir le présent travail.

1
 Chapitre 1 : Cadre général du projet et choix méthodologique

Introduction
L’objectif de ce chapitre est de mettre le projet dans son cadre général. Nous commençons par
une présentation de l’organisme d’accueil et le cadre général du travail. Ensuite, nous
critiquons l’existant et puis, nous présenterons la solution proposée et le choix de la méthode
de conception. Enfin, nous clôturons ce chapitre par une conclusion.

I. Présentation de l’organisme de l’accueil

1. Description de l’organisme d’accueil (ICSTARTUP)
International coach start-up est une agence de marketing digital cité à Béja, qui utilise les
derniers outils et technologies digitales pour collecter des informations sur le comportement
des internautes. Intervenant sur les différents leviers du marketing online, ISCSTARTUP se
distingue par son expertise pointue : un atout conséquent pour faire décoller le business. [1]

Vision : développer un écosystème basé sur le Co-leadership, composé d'experts créatifs et

socialement responsables.
Valeurs : construction des liens individuels et forts avec nos clients, fondés sur l’écoute et le
conseil.
Mission : créer, développer et optimiser le business des entreprises dans le monde en utilisant
la technologie et la créativité.

2. Activités de la société
Nous présentons dans cette partie quelque projets réalisés dans e notre société :

Ecopack de la société italienne https://ecopacktunisie.com/

Avicenne de la société suisse https://avicenne.ch/

Site web de la jeune artiste, Sirine Mohamed https://sirinemohamed.art/

2
Figure 1: Site web de la jeune artiste, Sirine Mohamed

Figure 2: Avicenne de la société suisse

Figure 3: Ecopack de la société italienne

3
 3. Description du service informatique

Maintenance site web :

Ergonomie & design
maintenir les sites Web afin que CREATION SITE
La création des logos puissent concentrer sur la INTERNET
gestion de votre entreprise.
Met des différentes
formules pour vous
faciliter la création
DIGITAL de votre site internet.
MARKETING
Services
Aider à développer une
stratégie, à gérer et à ISCSTARTUP
exécuter les outils onlines RÉFÉRENCEMENT
pour générer des clients WEB
potentiels. Une boîte à outils
SOUS TRAITANCE impressionnante quand
WEB il s’agit de
L’impartition des services référencement web
de développement site Tunisie ou
web à un prix abordable et référencement Naturel.
une qualité remarquable.

II. Etude de l’existant

L’étude de l’existant est une étape très importante pour la bonne réalisation du projet, C'est la
phase du projet pendant laquelle le Business Analyst va auditer les processus et les solutions
informatiques existants. Elle est réalisée avant l'initialisation du changement. Elle permet de
préparer l'analyse des besoins de la solution cible et de réaliser l'analyse des écarts.

1. Description de l’existant
Actuellement, le concept de don des fournitures scolaires d'art existe déjà. Il y a beaucoup
d’associations qui se donnent pour mission de collecter des fournitures scolaires non usagées
et usagées à travers de ces moyens :
- La création d'événements ;
- Les médias sociaux (Instagram, Facebook, YouTube, WhatsApp, Messenger)
-Les médias de masse (presse écrite, radio, télévision, cinéma, affichage) ;
-L’édition (affiche, brochures, plaquettes, rapport annuel, livre blanc, etc.) ;
-Les supports internes (journal, newsletter, séminaires, conventions, etc.).

4
Mais d’autre part il y a plusieurs plateformes leurs missions de collecter des dons.
Les meilleurs sites de collecte de fonds pour les organismes de bienfaisance afin de faciliter
les dons sont :
GoFundMe : Avec plus de 9 milliards de dollars collectés à ce jour pour des causes grandes
et petites, GoFundMe est l’un des sites de collecte de fonds personnels les plus connus et les
plus fiables dans l’arène du crowdfunding. Grâce à leur plateforme, les gens peuvent collecter
des fonds pour des causes personnelles, commerciales et caritatives. Mais Il existe plusieurs
inconvénients et problèmes :
- Problème de sécurité : Manque de sécurité car possibilité de voler l’argent des
donateurs, escroquerie à la carte bancaire sur ce site.
- Problème de financement : Système de paiement très lent 8 jours que les dons
sont toujours en attente et pourcentage de prélèvement de commission très élevée.
Cha9a9a : Le site cha9a9a.tn est une plateforme de dons en ligne qui permet aux individus
et associations de s'entraider financièrement pour réaliser des actions sociales et solidaires,
soutenir des causes ou organiser des évènements à but non lucratif. Mais Il existe plusieurs
inconvénients et problèmes :
- Problème d’organisation et de communication : retard de répondre aux
demandes et aux problèmes des donneurs c’est un système lent de l’organisation.

2. Critique de l’existant
Les actions de ces associations ne sont pas suffisantes pour la collecte de plusieurs dons et
pour permettre ainsi de faire reculer l'analphabétisme dans les pays où le taux est très élevé en
permettant à la population d'accéder à l'éducation grâce aux fournitures scolaires récupérées.

Il y a plusieurs problèmes rencontrés tels que :

Manque d'un système d'information : Le montant des dons accordés est important, le
service chargé du développement de la collecte et de la saisie administrative des dons est
souvent en archive. D’autant plus si les données des contacts sont dispersées et pas à jour. La
gestion des dons se fait manuellement par des papiers ou parfois par des fichiers Excel.

Figure 4: Imprime d'écran d'un fichier Excel d'association

5
Difficulté de diversifier leur stratégie de collecte : Pour l'association, la difficulté de
diversifier leur stratégie de collecte et de recrutement de nouveaux donateurs est bien réelle.
Trouver de nouvelles idées et de nouveaux moyens de collecte implique le changement des
habitudes des équipes, la prise en main de nouvelles solutions pour, par exemple, collecter en
ligne ou en strelet marketing, la recherche de nouvelles compétences en communication
digitale pour compléter son équipe.

Avec 55 % des personnes qui accèdent à internet depuis leur mobile, et 40 % qui déclarent
être en confiance pour faire un jour un don sur les réseaux sociaux.

L'attrition des donateurs (surtout les plus jeunes) : Les 65 ans et plus représentent un tiers
des dons et sont souvent qualifiés de donateurs fidèles. Leur attrition inquiète particulièrement
les fundraisers car il est difficile de les remplacer. Les générations passent, il est pourtant
indispensable de pouvoir aussi compter sur des donateurs plus jeunes et plus connectés de
façon pérenne. À une époque d’instantanéité permanente, le processus de fidélisation et
d’engagement sur le long terme est plus compliqué pour les fundraisers. Les très jeunes
générations passent de mode en mode et s’émeuvent temporairement avant de passer à
l’émotion suivante. Pour garder leur attention, il faut les stimuler en permanence, les rappeler
à leur affect de ce moment où ils ont fait leur premier don pour votre association.

Devenu très concurrentiel (le marché des associations sature de campagnes d’appels aux
dons) : Aussi généreux soient-ils, les donateurs n’ont pas un budget extensible et doivent, par
conséquent, faire des choix. Au-delà de campagnes marketing aussi créatives qu’engageantes
pour se démarquer, qu’elles soient par voie d’affichage, par voie postale ou par des moyens
dématérialisés (emails, réseaux sociaux), informer le donateur est ce qui fait la différence.

3. Solution proposée
Actuellement, en raison d'une augmentation de ceux qui en ont besoin et ceux qui n'ont pas
les moyens d'acheter des fournitures scolaires. Nous avons eu recours à développer une
application appelée « School-out box » qui facilite la gestion et la collecte des dons pour les
différents organismes de bienfaisance.

La plateforme sera dédiée à l'intérêt public :

Particuliers, associations ou entreprises peuvent déposer des projets solidaires et innovants

développement social, durable, promotion de la culture ou des biens communs et collecte les
dons en ligne du public et de mettre en relation les organismes de bienfaisance avec les

6
donateurs des fournitures scolaires et donc aider les associations à mieux gérer et collecter les
dons.

III. Méthodologie de travail et langage de modélisation

1. Les méthodologies de travail traditionnelles VS Agiles

Figure 5 : Méthodologie de conception en cascade

Cette figure résume le cycle d’une méthodologie de travail en cascade. Selon cette figure,
chaque participant dans la réalisation du projet doit terminer toute sa tâche avant de la
transférer au suivant.

La méthode classique lorsqu'on a une idée précise du projet, avec un planning bien détaillé et
où on a anticipé tous les risques possibles. Quant à la méthode Agile, on la choisira plutôt
pour les gros projets, celle-ci permettant une meilleure adaptabilité, visibilité et gestion des
risques.
Cependant, la majorité des clients concernent la maintenance et l’évolution [2].
La solution pour remédier aux inconvénients des méthodes traditionnelles de gestion de projet
est la méthode Agile.
Scrum est une méthode de développement agile orientée projet informatique dont les
ressources sont régulièrement actualisées.
La méthode Scrum tire son nom du monde du rugby, scrum = mêlée. Le principe de base
étant d’être toujours prêt à réorienter le projet au fil de son avancement.
C’est une approche dynamique et participative de la conduite du projet. La mêlée est une
phase de jeu essentielle au rugby. Elle permet au jeu de répartir sur d’autres bases. La réunion
dans la méthode Scrum relaie la métaphore.

7
La méthode Agile répond aux problèmes liés aux méthodes traditionnelles de gestion de
projet en mettant l’accent sur deux aspects :
- Impliquer le client au maximum dans le projet
- Les développements itératifs et incrémentaux

 Un développement itératif est une approche utilisée pour développer du

logiciel au cours de laquelle l’ensemble du cycle se compose de
plusieurs itérations successives. Chaque itération est composée, par
exemple, de ; Analyse des exigences, Design, Programmation, Tests,
Développement

 Incrémental : logiciel construit progressivement

2. Méthodologie choisie : SCRUM

Notre choix s’est porté sur la méthode Scrum de gestion de projet car elle répond aux
caractéristiques des méthodes agile définies dans la section précédente. Elle est basée sur les
principes des méthodes agiles précédemment définis, elle privilégie la livraison rapide d’un
prototype, opérationnel par définition, afin d’avoir un retour rapide des clients et des donneurs
d’ordre par minimiser les pertes de temps .

• Rôles SCRUM
Scrum est basé sur 3 rôles.
Les principaux acteurs dans la méthode SCRUM sont :
- Directeur du produit (Product Owner) : c’est le responsable de l’orientation du projet, la
production et la mise à jour du carnet du produit.
- Chef de mêlée (Scrum Master) : c’est une personne chargée de résoudre les problèmes
éventuels qui empêcherait l’avancement du projet pendant les différents sprints.
- Equipe : Elle peut être composée d’architecte, concepteur, analyste, développeur dont le
rôle est de transformer les besoins exprimés par le propriétaire du produit en
fonctionnalités utilisables.

• Concepts SCRUM
Les concepts de la méthode Scrum sont les suivants :

- Sprint : Le Sprint est une période qui varie entre deux et quatre semaines au maximum.
Durant cette période, l’équipe délivre un livrable du produit. La durée fixée reste
constante pendant toute la durée du développement.

8
- Product Backlog (ou carnet de produit) : est défini par le guide scrum comme étant “une
liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit”.
- Scrum Meeting : Le Scrum Meeting n’est qu’une réunion pendant laquelle nous
cherchons à résoudre les problèmes, mais uniquement à les identifier et les exprimer.
- Revue de Sprint : À la fin du Sprint, l’Equipe, le Scrum Master et le Product Owner se
réunit pour effectuer la revue du sprint dont le but est de valider le livrable qui a été
produit durant le Sprint. L’équipe commence par énoncer les user story du Backlog de
produit qu’elle a réalisé.
- Rétrospective de Sprint : La rétrospective du sprint est faite en interne à l’équipe.
L’objectif est de détecter les erreurs commises et de prendre des décisions pour les
améliorer.

Figure 6 : Les différents rôles de Scrum et le déroulement du processus

Scrum est :

 Léger.
 Simple à comprendre.
 Difficile à maîtriser.
Durant un développement d’un projet avec la méthode Scrum il y a plusieurs étapes à suivre
avec une démarche spécifique et une interaction avec plusieurs intervenants. [3]

3. Langage de modélisation : UML

La conception de notre projet est basée sur le concept objet et articulée autour d’UML
(Unified Modeling Langage) qui est par définition un langage de modélisation unifié et
standardisé pour la conception des systèmes informatiques. Nous avons choisi UML car il
n’impose pas de méthode de travail particulière. [4]

Il peut être utilisé par n’importe quel processus de développement logiciel puisqu’il présente
une sorte d’outils qui permet d’améliorer peu à peu les méthodes de travail tout en gardant les
modes de fonctionnement.
9
Dans notre projet, nous avons utilisé l’outil StarUML pour schématiser nos diagrammes
(diagramme du cas d’utilisation, diagramme de classe, diagramme de séquence).

Conclusion
Ce chapitre est une partie introductive de notre projet, au cours duquel nous avons présenté le
cadre général de notre travail. Nous avons introduit, en premier lieu, l’organisme d’accueil,
ensuite, nous avons cité les solutions existantes et critiqué l’existant, puis, nous avons proposé
une solution et enfin nous avons mis l’accent sur la méthode du travail adoptée.

10
 Chapitre 2 : Sprint 0 : Préparation des bases de projet
Introduction
Avant de commencer à développer notre application, nous commençons par la phase de
spécification pour bien organiser, identifier les tâches de notre projet et appliquer la
méthodologie Scrum.
Ce chapitre consiste donc à déterminer les besoins fonctionnels et non fonctionnels, les
différents acteurs de notre projet, le product backlog et l'architecture technique de notre
application.
De plus, dans ce chapitre, nous élaborerons le diagramme de cas d'utilisation général et le
diagramme de classes. Enfin, nous présenterons l'environnement de développement et les
technologies utilisées.
I. Capture des besoins
1. Identification des acteurs
Un acteur représente une personne ou un autre système informatique qui bénéficient d’un ou
plusieurs services offerts par une interface d’accès et interagissent avec le système par envoi
ou réception des messages.
✓ Admin : C’est la personne possédant le privilège de plus haut niveau.
✓ Donateur : possède un accès partiel au système, il ne manipule que certaines
fonctionnalités.
✓ Association : possède un accès partiel au système, il ne manipule que certaines
fonctionnalités.
2. Descriptions des besoins fonctionnels
Dans cette partie, nous allons présenter les différentes fonctionnalités et services assurés par
notre système pour les différents acteurs. Nous avons deux parties :
❖ Une partie Admin : par laquelle, nous pouvons gérer les utilisateurs (les associations
ou bien les donateurs) et les dons et les évènements de charité. Ces taches sont
accomplies par un administrateur qui doit s’authentifier avec un email et un mot de
passe à partir de la page d’accueil.
❖ Une partie destinée à l’Association : dans laquelle, elle peut gérer son profil, déposer
ses événements et gérer les dons déposés …
❖ Une partie destinée au donateur : dans laquelle, il peut gérer son profil, consulter les
événements et effectuer des dons …
Dans ce qui suit, nous allons détailler les besoins fonctionnels offerts par notre application en
fonction de chaque acteur.

11
Le système doit permettre :
Au Visiteur de :
 Consulter la liste des événements
 Consulter la liste des associations
 Consulter site vitrine
A l’admin de :
 S’authentifier
 Gérer association
 Gérer donateur
 Gérer les dons
 Gérer les évènements
 Gérer son compte
À l’association de :
 S’authentifier
 Gérer les dons
 Gérer les évènements
 Gérer son compte
Au Donateur de :
 S’inscrire
 S’authentifier
 Gérer son compte
 Effectuer un don
 Gérer la liste de ses dons
 Consulter la liste des événements
 Consulter la liste des associations

3. Description des besoins non-fonctionnels :

Ces besoins sont les caractéristiques du système, comme les besoins en matière de
performance, en type de matériels ou type de conception.
Ils peuvent aussi concerner les contraintes d’implémentation (langage de programmation, type
SGBD, de système d’Exploitation...).
Les besoins non-fonctionnels de notre système se décrivent comme suit :

12
  Besoins de sécurité : tous les accès aux différentes espaces doivent être protégées par
un mot de passe et un privilège d’accès. Ainsi, il faut s’assurer des cryptages des
données au niveau de la base de données.
 Besoins d’utilisation : tous les standards d’ergonomies doivent être présents :
interface utilisateur bien claire et simple dans l’utilisation.
 L’ergonomie : l’application doit être conforme aux principes de l’interface Homme-
Machine.
 La fiabilité : l’application doit toujours donner des résultats corrects aux clients.
 Efficacité : L'application doit être fonctionnelle indépendamment de toutes
circonstances pouvant entourer l'utilisateur.
 Rapidité : L'application doit optimiser les traitements pour avoir un temps de
génération de schéma raisonnable.
II. Diagramme de cas d’utilisation global
La conception des cas d’utilisation clarifie le déroulement futur du système. En fait, les
diagrammes de cas d’utilisation permettent d’abord de modéliser le système, de déterminer
ses fonctions à travers la représentation et enfin de forcer l’utilisateur à définir ce qu’il attend
du système.

13
Figure 7: Diagramme de cas d'utilisation global

14
 III. Backlog Product
Tableau 1: Backlog Product

Sprint Module Id User Stories Priorit Estimati Risque

é on
1 En tant qu’administrateur, je 3 Elevée 0
dois pouvoir gérer les rôles.
2 En tant qu’administrateur, je 2 Elevée 1
dois pouvoir m’authentifier.

Sprint Authentification 3 En tant que donateur, je dois 2 Elevée 1

1
pouvoir m’authentifier.

4 En tant qu’association, je dois 2 Elevée 1

pouvoir m’authentifier.

Inscription 5 En tant que donateur, je dois 3 Elevée 1

pouvoir m’inscrire à la
plateforme.
Sprint 6 En tant qu’administrateur, je 2 Elevée 2
2
dois pouvoir gérer association.
Profil
7 En tant qu’administrateur, je 3 Elevée 2
dois pouvoir gérer donateur.
8 En tant qu’association, je dois 1 Elevée 0
pouvoir gérer mon profil.
9 En tant que donateur, je dois 1 Elevée 0
pouvoir gérer mon profil.
10 En tant qu’administrateur, je 1 Elevée 0
dois pouvoir gérer mon profil.
Sprint 3 10 En tant qu’administrateur, je 2 Moyenne 1
dois pouvoir gérer les catégories
Dons d'approvisionnement.

15
 11 En tant qu'administrateur, je dois 2 Moyenne 1
pouvoir gérer les types de
fournitures de chaque catégorie.
12 En tant que donateur, je dois 3 Moyenne 1
pouvoir effectuer un don.
13 En tant qu’association je dois 3 Moyenne 1
pouvoir consulter les
informations des donateurs.
14 En tant qu’administrateur ou 3 Moyenne 1
association, je dois pouvoir gérer
les dons.
15 En tant que donateur, je dois 2 Moyenne 2
pouvoir gérer mes dons.
Sprint 4 Evènements 15 En tant que donateur, je dois 2 Faible 1
pouvoir consulter la liste des
événements.
16 En tant qu’administrateur ou 3 Faible 1
association, je dois pouvoir gérer
les évènements.
Association 17 En tant que visiteur ou donateur, 2 Faible 1
je dois pouvoir consulter la liste
des associations.
18 En tant qu’association, je dois 3 Faible 1
pouvoir contacter le donateur par
email.
19 En tant qu’association ou 2 Faible 1
administrateur, je dois pouvoir
consulter les statistiques.

IV. Planification des Sprints

La planification du sprint est une cérémonie Scrum qui lance le sprint. Elle a pour objectif de
définir ce qui peut être livré dans le sprint et comment y parvenir. La planification du sprint
est effectuée en collaboration avec toute l’équipe Scrum.

16
Nom Sprint Date de début Date de fin

Sprint 1 : Gestion des comptes 01 /3/2022 20/3/2022

des utilisateurs, authentification.
Sprint 2 : Gestion des profils et 21/3/2022 10/4/2022
d’utilisateurs
Sprint 3 : Gestion des dons. 11/4/2022 01 /5/2022

Sprint 4 : Gestion des 02 /5/2022 20 5/2022

associations et des évènements.
Tableau 2: Planification des sprints

V. Diagramme de classe

Les diagrammes de classes sont l'un des types de diagrammes UML les plus utiles, car ils
décrivent clairement la structure d'un système particulier en modélisant ses classes, ses
attributs, ses opérations et les relations entre ses objets.

Figure 8: Diagramme de classe

17
 VI. Environnement de travail
Pour mettre en place notre système, nous avons utilisé un environnement de développement
qui a assuré le bon déroulement de la phase implémentation. Cet environnement comporte des
outils matériels ainsi que logiciels.

1. Environnement matériel

Pour réaliser notre travail, nous avons utilisé comme environnement matériel un ordinateur
portable de marque « ASUS » avec un système d’exploitation Windows 10 de 64 bits, ayant
un processeur Intel(R) Pentium(R) CPU N3700 @ 1.60GHz 1.60 GHz, doté d’une Ram de 4
GO.

2. Environnements logiciels

Dans cette partie, nous présentons l’environnement logiciel de notre application de point de
vue langages, Framework, Logiciels et technologies.

2.1 Langages et Technologies

Dans le tableau suivant, Il y’a une description des langages et technologies utilisés lors du
développement tels que AngularJS, HTML et CSS3 dans l’aspect graphique de l’application.

Tableau 3: Tableau des langages utilisés

Langages Description
Langage de balisage utilisé pour la création de pages web,
permettant notamment de définir des liens hypertextes.

Le langage CSS est employé pour déterminer le style de

l’application.
Le CSS (ou feuille de style), est un document au travers duquel nous
avons défini le choix de couleurs, type de police, positions.

Type Script est un langage de programmation libre et open source

développée par Microsoft qui a pour but d’améliorer et de sécuriser
la production de code JavaScript. C’est un sur-ensemble de
JavaScript (c’est-à-dire que tout code JavaScript correcte peut être
utilisé comme Type Script). [5]

18
 Angular 13 est un Framework basé sur Type Script coté client qui
est utilisé pour créer des applications Web dynamiques. Il est très
similaire à ses versions précédentes, à l’exception de quelques
fonctions étendues. [6]

Bootstrap 3 est une compilation de plusieurs éléments et fonctions

web design personnalisables, le tout emballé dans un seul et même
outil. Ces éléments sont une combinaison de HTML, CSS et
JavaScript. C’est l'un des projets les plus populaires sur la plate-
forme de gestion de développement GitHub (GitHub est un service
web d'hébergement et de gestion de développement de logiciels). [7]

2.2 Logiciels

Dans le tableau qui suit, Il y’a une description des logiciels utilisés lors du développement de
l’application, tel que Visual Studio Code.

Tableau 4: Tableau des logiciels utilisés

Logiciels Description
Google chrome : C’est un navigateur internet
développé par Google. Ce navigateur est sur le marché
depuis 2008 et fonctionne sur différentes plateformes
(PC, tablettes, smartphone ...) et sous différents OS
(Windows, mac, Linux, Android). [8]

Visual Studio Code est un éditeur de code extensible

développé par Microsoft par Windows, Linux et
MacOs.
Wamp est une plateforme de développement Web de
type WAMP, permettent de faire fonctionner
localement des scripts PHP. Wamp n’est pas en soi un
logiciel, mais un environnement comprenant trois
serveurs, un interpréteur de script, ainsi que
phpMyAdmin pour l’administration web des bases
MySQL. [9]

19
 StarUML est un logiciel de modélisation UML
(Unified Modeling Langage) open source qui peut
remplacer dans bien des situations des logiciels
commerciaux et coûteux comme Rational Rose ou
Together. [10]
Canva est une plate-forme de conception graphique
australienne, utilisée pour créer des graphiques de
médias sociaux, des présentations, des affiches, des
documents et d'autres contenus visuels. L'application
comprend des modèles que les utilisateurs peuvent
utiliser.

Postman est un outil de développement logiciel, il

permet aux utilisateurs de tester les appels aux API,
les utilisateurs du facteur saisissent des données, les
données sont envoyées à une adresse de serveur Web
spéciale. [11]
Git : est un logiciel de gestion de versions
décentralisé. C'est un logiciel libre créé par Linus
Torvald, auteur du noyau Linux, et distribué selon les
termes de la licence publique générale GNU version 2.
[12]

2.3 Serveur d’application et serveur SGBD

Dans le tableau suivant, Il y’a une description des serveurs d’application et SGBD utilisés lors
du développement de l’application.

Tableau 5:Tableau des serveurs utilisés

Serveurs Description
MySQL est un serveur de bases de données
relationnelles SQL développées avec un souci de
performances élevées en lecture, ce qui signifie qu’il
est davantage orienté vers le service de données déjà

20
 en place que vers celui de mise à jour fréquentes et
fortement sécurisées Il est multi-threadé et multi-
utilisateur. [13]
Node.js est une plate-forme côté serveur construite
sur le moteur d’exécution JavaScript de Chrome pour
créer facilement des applications réseau rapides et
évolutives. Node.js utilise un modèle d’Entrée/Sortie
non bloquant piloté par les événements qui le rendent
léger et efficace, parfait pour les applications en
temps réel gourmandes en données qui s’exécutent
sur des appareils distribués. Il fournit également une
riche bibliothèque de divers modules JavaScript qui
simplifie dans une large mesure le développement
d’applications Web utilisant Node.js. Également
cette bibliothèque Node.js est très rapide dans
l’exécution de code. [14]

VII. Architecture du système

Afin de réaliser notre projet, nous avons opté pour une architecture 3-tiers. Il s’agit d’un
modèle logique d’architecture applicative qui vise à modéliser une application comme un
empilement de trois couches logicielles dont le rôle est clairement défini :
o La présentation des données : correspondant à l’affichage, la restitution sur le poste de
travail, le dialogue avec l’utilisateur.
o Le traitement métier des données : correspondant à la mise en œuvre de l’ensemble
des règles de gestion et de la logique applicative.
o L’accès aux données persistantes : correspondant aux données qui sont destinées à être
conservées sur la durée, voire de manière définitive. [15]

Figure 9 : Architecture 3 tiers

21
 Front_end Back_end Database

Figure 10 : Architecture 3 tiers plus détaillée

VIII. Pilotage du projet avec SCRUM

Dans cette section nous avons met en valeur l’équipe Scrum et son rôle bien défini, le
Backlog de produit ainsi la planification des releases.

• Equipe et rôles

Pour administrer un projet Scrum, de préférence commencer par mettre en valeur l’équipe et
son rôle bien défini. L’équipe a un rôle principal dans scrum puisque ce dernier sert à
améliorer la flexibilité et la productivité.

Les rôles sont composés comme ci-dessous :

o Scrum Master : Madame Marwa Chaabani

o Product Owner :
o Equipe de développement : Ines Ouechteti

22
 Ines Ouechteti

Mme Marwa

Chaabani

Figure 11 : Equipe SCRUM

Conclusion
Durant ce chapitre, nous avons planifié notre travail, identifier les besoins fonctionnels et non
fonctionnels de notre application, les rôles des utilisateurs par la suite nous avons présenté le
Backlog de notre système, ainsi nous avons détaillé la phase de planification des sprints. Nous
allons enchainer à présent avec notre premier release dans le chapitre qui suit.

23
 Chapitre 3 : Sprint 1 « Gestion des comptes des utilisateurs,
authentification »
Introduction
Ce chapitre est consacré pour décrire l’analyse, la conception et la réalisation du premier
sprint. Ce sprint a pour objectif de permettre à l’administrateur, à le donateur et l’association
de s’authentifier afin de pouvoir accéder à leurs différentes fonctionnalités de l’application.

I. Backlog Sprint

Les différentes tâches liées à la réalisation du premier Sprint sont décrites dans le tableau
suivant :

Tableau 6 : Backlog sprint 1

Id User stories Les sous-tâches

1 En tant qu’administrateur, je 1.Création d'un web service d'ajouter rôle. (Back-end)

dois pouvoir gérer les rôles.
2.Création d'un web service de modifier rôle. (Back-end)

3.Création d'un web service d'afficher la liste des rôles. (Back-

end)

4.Création de l’interface d'ajouter rôle (Front-end)

5.Création de l’interface d’afficher la liste des rôles (Front-

end)

6.Création de l’interface de modifier rôle (Front-end)

7. Intégration les web services.

8.Test du cas « Ajouter rôle »

9.Test du cas « Modifier rôle »

10.Test du cas « Afficher les rôles »

2 En tant qu’administrateur, je 1.Création d'un web service d'authentification. (Back-end)

dois pouvoir m’authentifier.
2. Sécuriser l'authentification avec JWT.

24
 3.Création de l’interface « Login Admin » (Front-end)

4. Intégration du web service.

5.Test du cas « Authentification »

3 En tant que donateur, je dois 1.Création d'un web service d'authentification. (Back-end)
pouvoir m’authentifier.
2. Sécuriser l'authentification avec JWT.

3.Création de l’interface « Login Donateur » (Front-end)

4. Intégration du web service.

5.Test du cas « Authentification »

4 En tant qu’association, je dois 1.Création d'un web service d'authentification. (Back-end)

pouvoir m’authentifier.
2. Sécuriser l'authentification avec JWT.

3.Création de l’interface « Login Association » (Front-end)

4. Intégration du web service.

5.Test du cas « Authentification »

5 En tant que donateur, je dois 1.Création d'un web service d’inscrire. (Back-end)
pouvoir m’inscrire à la
2. Sécuriser l'authentification avec JWT.
plateforme.
3.Création de l’interface « Registre » (Front-end)

4. Intégration du web service.

5.Test du cas « Registre »

II. Diagrammes de cas d’utilisation détaillés du Sprint n°1

Les cas d'utilisation détaillés sont bien plus précis et offrent plus de détails que le diagramme
global de cas d'utilisation. Ils représentent la structure des grandes fonctionnalités nécessaires
aux utilisateurs du système.

25
La description d’un cas d’utilisation permet de :

❖ Clarifier le déroulement de la fonctionnalité.

❖ Décrire la chronologie des actions qui devront être réalisées.
❖ Identifier les parties redondantes pour en déduire des cas d’utilisation plus précises qui
seront utilisées par inclusion, extension ou généralisation/spécialisation.
1. Raffinement des cas d’utilisation :
La figure illustre le diagramme du cas d’utilisation détaillé « Sprint1 ».

Figure 12 : Diagramme du cas d’utilisation détaillé « Sprint1 »

2. Description textuelle du cas d'utilisation « Sprint 1 » :

Le tableau présente la description textuelle du cas de « s’authentifier »
Tableau 7 : Description textuelle du cas de « s’authentifier »

Titre S’authentifier

Acteur Admin / Association / Donateur

Pré-condition - L’utilisateur doit être inscrit et possède son propre identifiant et mot
de passe.
- Une connexion au serveur doit être établie.

Scénario 1- Le système affiche l’interface d’authentification.

nominal 2- L’utilisateur saisit son identifiant et son mot de passe.
3- Il clique sur le bouton « Login »

26
 4- Le système vérifie la validité des champs et s'ils ne sont pas vides.
5- Il vérifie ensuite la combinaison identifiant et mot de passe.
6- Si l’identifiant et le mot de passe sont valides alors le système
redirige l’acteur vers sa page d’accueil spécifique selon son rôle.

Scénario 7- Si les champs sont vides alors un message d’erreur contenant « Le

alternatif champ est obligatoire » est affiché.

Retour à l’étape numéro 2 du scénario nominal.

8- Si erreur de combinaison alors un message « Mauvaises

qualifications » est affiché.

Retour à l’étape numéro 2 du scénario nominal.

Le tableau présente la description textuelle du cas de « Ajouter rôle »

Tableau 8 : Description textuelle du cas de « Ajouter rôle »

Titre Ajouter rôle

Acteur Admin

Pré-condition - L’admin doit être authentifié.

- Une connexion au serveur doit être établie.

Scénario nominal 1- Le système affiche l’interface de la liste des rôles.

2- L’admin appuie le bouton « ajouter rôle »
3- L’admin renseigne les données nécessaires
4- Le système vérifie la saisie des données
5- Le système traite la requête d’ajout.

Scénario alternatifs A2 : L’admin ne saisit pas tous les champs obligatoires.

L’enchaînement A2 démarre au point 4 du scénario nominal.
Le système alerte l’admin par un message d’erreur « Veuillez
renseigner ce champ »
Le scénario nominal reprend au point 3.

Post-condition Le rôle ajouté avec succès.

27
Le tableau présente la description textuelle du cas de « s’inscrire »
Tableau 9 : Description textuelle du cas de « s’inscrire »

Titre S’inscrire

Acteur Donateur

Pré-condition - Le donateur accédé au site pour crée compte

Scénario nominal 1- Le donateur clique sur le bouton " Inscription ".

2- Le donateur remplit le formulaire.
3- Le donateur clique sur le bouton "registre".
4- Le système vérifie la validité des informations.

Scénario alternatifs Si erreur de validation des champs un message d'erreur est affiché.

Post-condition S’inscris avec succès.

III. Diagrammes de séquence du Sprint n°1

Dans cette partie nous allons modéliser les diagrammes de séquences pour certains cas
d’utilisation, ce qui permettra de mieux détailler les scénarios de notre application en mettant
l’accent sur l’aspect chronologique de la séquence.

1. Diagramme de séquence du cas « s’authentifier »

Le diagramme de séquence du cas d’utilisation s’authentifier est présenté par la figure

suivante :

28
 Figure 13 : Diagramme de séquence de cas « S’authentifier ».

2. Diagramme de séquence du cas « Inscrire » d’un donateur

Le diagramme de séquence du cas d’utilisation de crée compte est présenté par la figure
suivante :

29
 Figure 14 : Diagramme de séquence du cas d’utilisation de s’inscrire

3. Diagramme de séquence du cas « Modifier rôle »

Le diagramme de séquence du cas d’utilisation de modifie rôle est présenté par la figure
suivante :

30
 Figure 15 : Diagramme de séquence du cas d’utilisation de modifier rôle

IV. Réalisation

Pour réaliser les objectifs de ce sprint, nous entamons la partie la plus importante qui est la
réalisation.
Nous passons à la présentation d’une partie de l’application de l’admin, l’association et l’autre
pour le donateur à travers des captures d’écrans produites après la finalisation de la phase de
réalisation.

31
La figure suivante présente l’interface d’inscription pour le donateur :

Figure 16 : Interface d'inscription pour le donateur

La figure suivante présente l’interface d’authentification pour le donateur :

Figure 17 : Interface d'authentification donateur

32
La figure suivante présente l’interface d’authentification pour l’admin :

Figure 18 : Interface d'authentification admin

La figure suivante présente l’interface d’authentification pour l’association :

Figure 19 : Interface d'authentification association

33
La figure suivante présente l’interface de gestion rôle pour l’admin :

Figure 20 : Interface de gestion rôle

Conclusion
Durant ce chapitre du Sprint n°1, nous avons, en premier lieu, organisé notre Backlog Sprint
pour définir les user story à réaliser dans ce sprint, en deuxième lieu, nous avons réalisé les
diagrammes de case d’utilisation, de classes et de séquences correspondants à ce sprint, par la
suite, nous avons illustré les imprimes écrans des interfaces créées durant ce sprint, au niveau
de la partie réalisation. Dans le chapitre qui suit, nous allons entamer le Sprint n°2 qui est
dédié à la gestion des profils et d’utilisateurs.

34
 Chapitre 4 : Sprint 2 « Gestion des profils et d’utilisateurs »
Introduction
Ce chapitre est consacré pour décrire l’analyse, la conception et la réalisation du deuxième
sprint. Ce sprint a pour objectif de permettre à l’administrateur, à le donateur et l’association
de gérer leur profil et pour l’admin de gérer les utilisateurs.

I. Backlog Sprint

Les différentes tâches liées à la réalisation du premier Sprint sont décrites dans le tableau
suivant :

Tableau 10 : Backlog sprint 2

Id User stories Les sous-tâches

6 En tant qu’administrateur, je 1.Création d'un web service d'ajouter association. (Back-

dois pouvoir gérer association. end)

2.Création d'un web service d'ajouter email à l’association

contient les coordonnés. (Back-end)

3.Création d'un web service de supprimer association.

(Back-end)

4.Création d'un web service d'afficher la liste des

associations. (Back-end)

5.Création d'un web service d'ajouter association. (Back-

end)

6. Intégration les web services.

7.Test du cas « Ajouter Association »

8.Test du cas « Supprimer Association »

9.Test du cas « Afficher les Associations »

7 En tant qu’administrateur, je 1.Création d'un web service de supprimer donateur. (Back-

dois pouvoir gérer donateur. end)

2.Création d'un web service d'afficher la liste des donateurs.

35
 (Back-end)

3. Intégration les web services.

4.Test du cas « Supprimer donateur »

5.Test du cas « Afficher les donateurs »

8 En tant qu’association, je dois 1- Créer et tester l’API de la modification du profile.

pouvoir gérer mon profil. 2- Créer l’interface de la modification du profile.
3- Intégrer l’API.

9 En tant que donateur, je dois 1- Créer et tester l’API de la modification du profile.

pouvoir gérer mon profil. 2- Créer l’interface de la modification du profile.
3- Intégrer l’API.

10 En tant qu’administrateur, je 1- Créer et tester l’API de la modification du profile.

dois pouvoir gérer mon profil. 2- Créer l’interface de la modification du profile.
3- Intégrer l’API.

II. Diagrammes de cas d’utilisation détaillés du Sprint n°2

Dans ce qui suit, nous détaillons la conception de ce deuxième sprint en présentant le
diagramme de cas d’utilisation, les descriptions textuelles des fonctionnalités ainsi que les
diagrammes de séquence relatives à ce sprint.
1. Raffinement des cas d’utilisation :
La figure illustre le diagramme du cas d’utilisation détaillé « Sprint 2 ».

Figure 21 : Diagramme du cas d’utilisation détaillé « Sprint 2 »

36
 2. Description textuelle du cas d'utilisation « Sprint 2 » :
Le tableau présente la description textuelle du cas de « Ajouter d’Association »
Tableau 11: Description textuelle du cas de « Ajouter d’Association »

Titre Ajouter d’Association

Acteur Admin
Pré-condition - L'admin doit être authentifié.
Scénario nominal 5- L’admin accède à l'interface d'ajout d’association.
6- L'admin clique sur le bouton " Ajouter d’Association ".
7- L'admin remplit le formulaire.
8- L'admin clique sur le bouton "Ajouter ".
9- Le système vérifie la validité des informations.
10- Le système ajoute l’association.
11- Le système envoi email à l’association qui contient ses
coordonnées.
Scénario alternatif 12- Si erreur de validation des champs un message d'erreur est
affiché.
Post-condition Ajouter d’association avec succès.

Le tableau présente la description textuelle du cas de « Modifier Profil »

Tableau 12: Description textuelle du cas de « Modifier Profil »

Titre Modifier Profil

Acteur Admin/Association/Donateur

Pré-condition - L’admin doit être authentifiée.

- Une connexion au serveur doit être établie.

Scénario nominal 1- L'admin clique sur l'icône de modification.

2- L'admin clique sur le bouton "Modifier".
3- Le système vérifie la validité des informations.
4- Le système modifie le profil.

Scénario alternatifs 5- Si erreur de validation des champs un message d'erreur est

affiché.

Post-condition Le profil est modifié avec succès.

37
 III. Diagrammes de séquence du Sprint n°2

Dans cette partie nous allons modéliser les diagrammes de séquences pour certains cas
d’utilisation, ce qui permettra de mieux détailler les scénarios de notre application en mettant
l’accent sur l’aspect chronologique de la séquence.

1. Diagramme de séquence du cas « Modifier Profil »

Le diagramme de séquence du cas d’utilisation de modifier profil est présenté par la figure
suivante :

Figure 22 : Le diagramme de séquence du cas de modifier profil

2. Diagramme de séquence du cas « Ajouter Association »

Le diagramme de séquence du cas d’ajouter association est présenté par la figure suivante :

38
 Figure 23 : Le diagramme de séquence du cas d’ajouter association

3. Réalisation

Pour réaliser les objectifs de ce sprint, nous entamons la partie la plus importante qui est la réalisation.
Nous passons à la présentation d’une partie de l’application de l’admin et l’association et l’autre pour
le donateur à travers des captures d’écrans produites après la finalisation de la phase de réalisation.
La figure suivante présente l’interface d’ajouter association :

Figure 24: Interface ajouter association

39
La figure suivante présente l’interface de modifier profil pour l'association :

Figure 25 : Interface de modifier profil pour l'association

La figure suivante présente l’interface de modifier profil pour l’administrateur :

Figure 26 : Interface modifier profil pour l'admin

40
La figure suivante présente l’interface de modifier profil pour le donateur :

Figure 27 : Interface modifier profil pour le donateur

La figure suivante présente l’interface de gestion association pour l’admin :

Figure 28 : Interface de gestion association

41
La figure suivante présente l’interface de gestion donateur pour l’admin :

Figure 29 : Interface gestion donateur

Conclusion
Durant ce chapitre du Sprint n°2, nous avons, en premier lieu, organisé notre Backlog Sprint
pour définir les user story à réaliser dans ce sprint, en deuxième lieu, nous avons réalisé les
diagrammes de cas d’utilisation, de classes et de séquences correspondants à ce sprint, par la
suite, nous avons illustré les imprimes écrans des interfaces créées durant ce sprint, au niveau
de la partie réalisation. Dans le chapitre qui suit, nous allons entamer le Sprint n°3 qui est
dédié à la gestion des dons.

42
 Chapitre 5 : Sprint 3 « Gestion des Dons »
Introduction
Ce chapitre est consacré pour décrire l’analyse, la conception et la réalisation du troisième
sprint. Ce sprint a pour objectif de gestion des dons.

I. Backlog Sprint

Les différentes tâches liées à la réalisation du troisième Sprint sont décrites dans le tableau
suivant :

Tableau 13 : Backlog sprint 3

Id User stories Les sous-tâches

10 En tant qu’administrateur, je dois 1.Création d'un web service d'ajouter catégorie. (Back-
pouvoir gérer les catégories end)
d'approvisionnement.
2.Création d'un web service de modifier catégorie. (Back-
end)

3.Création d'un web service d'afficher la liste des

catégories. (Back-end)

4.Création d'un web service de supprimer catégorie.

(Back-end)

4.Création de l’interface d'ajouter catégorie (Front-end)

5.Création de l’interface d’afficher la liste des catégories

(Front-end)

6.Création de l’interface de modifier catégorie (Front-

end)

7. Intégration des web services.

8.Test du cas « Ajouter catégorie »

9.Test du cas « Modifier catégorie »

9.Test du cas « Supprimer catégorie »

43
 10.Test du cas « Afficher les catégories »

11 En tant qu'administrateur, je dois 1.Création d'un web service d'ajouter type de fourniture.
pouvoir gérer les types de (Back-end)
fournitures de catégorie.
2.Création d'un web service de modifier type de
fourniture. (Back-end)

3.Création d'un web service d'afficher la liste des types de

fournitures. (Back-end)

4.Création d'un web service de supprimer type de

fourniture. (Back-end)

4.Création de l’interface d'ajouter type de fourniture

(Front-end)

5.Création de l’interface d’afficher la liste des types de

fournitures (Front-end)

6.Création de l’interface de modifier type de fourniture

(Front-end)

7. Intégration des web services.

8.Test du cas « Ajouter type de fourniture »

9.Test du cas « Modifier type de fourniture »

9.Test du cas « Supprimer type de fourniture »

10.Test du cas « Afficher les types de fournitures »

12 En tant que donateur, je dois 1.Création d'un web service d'ajouter don. (Back-end)
pouvoir effectuer un don.
2. Création d'un web service d'ajouter fourniture. (Back-
end)

3.Création de l’interface d'ajouter don (Front-end)

4. Création de l’interface d'ajouter fourniture (Front-end)

5. Intégration des web services.

44
 6.Test du cas « Ajouter un don »

7.Test du cas « Ajouter les fourniture »

13 En tant qu’association je dois 1.Créer et tester l’API de la récupération les donateurs de

pouvoir consulter la liste des leur région.
donateurs.
2.Créer l’interface de la liste des donateurs.

3. Intégrer l’API.

4.Test du cas « afficher liste donateurs »

14 En tant qu’administrateur ou 1.Création d'un web service d'afficher la liste des dons.
association, je dois pouvoir gérer (Back-end)
les dons.
2.Création d'un web service d'afficher la liste des
fournitures de don. (Back-end)

3.Création d'un web service de supprimer fourniture.

(Back-end)

4.Création d'un web service de supprimer don avec leur

fourniture. (Back-end)

5.Création de l’interface d’afficher la liste des dons

(Front-end)

6. Création de l’interface d’afficher la liste des fourniture

(Front-end)

7. Intégration les web services.

8.Test du cas « Afficher les dons »

9.Test du cas « Afficher les fournitures »

9.Test du cas « Supprimer don »

10.Test du cas « Supprimer fourniture »

45
15 En tant que donateur, je dois 1.Création d'un web service d'afficher la liste des dons.
pouvoir gérer mes dons. (Back-end)

2.Création d'un web service d'afficher la liste des

fournitures de don. (Back-end)

3.Création d'un web service de supprimer fourniture.

(Back-end)

4.Création d'un web service de supprimer don avec leur

fourniture. (Back-end)

5. Création d'un web service de modifier don. (Back-end)

6.Création de l’interface d’afficher la liste des dons

(Front-end)

7. Création de l’interface d’afficher la liste des fourniture

(Front-end)

8. Création de l’interface de modifier don (Front-end)

9. Intégration des web services.

10.Test du cas « Afficher les dons »

11.Test du cas « Afficher les fournitures »

12.Test du cas « Supprimer don »

13.Test du cas « Supprimer fourniture »

14.Test du cas « Modifier don »

II. Diagrammes de cas d’utilisation détaillés du Sprint n°3

Dans ce qui suit, nous détaillons la conception de ce troisième sprint en présentant le

diagramme de cas d’utilisation, les descriptions textuelles des fonctionnalités ainsi que les
diagrammes de séquence relatives à ce sprint.

46
 1. Raffinement des cas d’utilisation :
La figure illustre le diagramme du cas d’utilisation détaillé « Sprint 3 ».

Figure 30 : Diagramme du cas d’utilisation détaillé « Sprint 3 »

2. Description textuelle du cas d'utilisation « Sprint 3 » :

Le tableau présente la description textuelle du cas de « Ajouter Don »
Tableau 14 : La description textuelle du cas de « Ajouter Don »

Titre Ajouter Don

Acteur Donateur

Pré-condition - Le donateur doit être authentifiée.

- Une connexion au serveur doit être établie.

Scénario nominal 1- Le donateur accède à l'interface d'ajout don.

2- Le donateur clique sur le bouton " Ajouter don ".
3- Le donateur remplit le formulaire.
4- Le donateur clique sur le bouton " Next ".
5- Le système vérifie la validité des informations.
6- Le système ajoute le don
7- Le donateur remplit le formulaire des fournitures.
8- Le donateur clique sur le bouton " finish".

47
 9- Le système vérifie la validité des informations.
10- Le système ajoute les fournitures

Scénario alternatifs 11- Si erreur de validation des champs un message d'erreur est
affiché.

Post-condition Ajouter don avec succès.

Le tableau présente la description textuelle du cas de « Afficher listes des dons »

Tableau 15 : Description textuelle du cas de « Afficher listes des dons »

Titre Modifier Profil

Acteur Admin/Association/Donateur

Pré-condition - L’admin doit être authentifiée.

- Une connexion au serveur doit être établie.

Scénario nominal 1- L’admin accède à l'interface des listes des don.

2- Le système affiche la liste des dons.
3- L’admin accède à l'interface des listes des fournitures.
4- Le système affiche la liste des fournitures.

Scénario alternatifs 5- Si la liste des dons est vide. Afficher liste vide

Post-condition La liste est affichée avec succès.

Le tableau présente la description textuelle du cas de « Ajouter Type fourniture »

Tableau 16: La description textuelle du cas de « Ajouter Type fourniture »

Titre Ajouter Type fourniture

Acteur Admin

Pré-condition - L’admin doit être authentifiée.

- Une connexion au serveur doit être établie.

Scénario nominal 1- L’admin accède à l'interface d'ajout type fourniture.

2- L’admin clique sur l’icône "Ajouter".

48
 3- L’admin remplit le formulaire. (Choisir le catégorie)
4- L’admin clique sur le bouton "Ajouter".
5- Le système vérifie la validité des informations.
6- Le système ajoute type fourniture.

Scénario alternatifs 7- Si erreur de validation des champs un message d'erreur est

affiché.

Post-condition Ajout type fourniture avec succès.

Le tableau présente la description textuelle du cas de « Valider don »

Tableau 17 : La description textuelle du cas de « Valider don »

Titre Valider don

Acteur Association

Pré-condition - L’association doit être authentifier.

- Une connexion au serveur doit être établie.

Scénario nominal 1- L’admin accède à l'interface des listes des don.

2- Le système affiche la liste des dons.
3- L’admin clique sur l’icône "Valider".
4- Le système valide le don.

Scénario alternatifs 8- Si erreur de validation des champs un message d'erreur est

affiché.

Post-condition Valide don avec succès.

III. Diagrammes de séquence du Sprint n°3

Dans cette partie nous allons modéliser les diagrammes de séquences pour certains cas
d’utilisation, ce qui permettra de mieux détailler les scénarios de notre application en mettant
l’accent sur l’aspect chronologique de la séquence.

49
 1. Diagramme de séquence du cas « Ajouter Don »

Le diagramme de séquence du cas d’utilisation d’ajouter don est présenté par la figure
suivante :

Figure 31: Diagramme de séquence du cas d’utilisation d’ajouter don

2. Diagramme de séquence du cas « Ajouter catégorie »

Le diagramme de séquence du cas d’ajouter catégorie est présenté par la figure suivante :

50
 Figure 32: Diagramme de séquence du cas d’ajouter catégorie

IV. Réalisation

Pour réaliser les objectifs de ce sprint, nous entamons la partie la plus importante qui est la
réalisation.
Nous passons à la présentation d’une partie de l’application de l’admin et l’association et
l’autre pour le donateur à travers des captures d’écrans produites après la finalisation de la
phase de réalisation.

51
La figure suivante présente l’interface de gestion catégorie :

Figure 33 : Interface de gestion catégorie

La figure suivante présente l’interface de gestion type fourniture :

Figure 34 : Interface de gestion type fourniture

52
La figure suivante présente l’interface de gestion don pour l'admin :

Figure 35 : Interface de gestion don pour l'admin

La figure suivante présente l’interface de gestion fourniture :

Figure 36 : Interface de gestion fourniture

53
La figure suivante présente l’interface de gestion don pour l'association :

Figure 37 : Interface de gestion don pour l'association

La figure suivante présente l’interface d'effectuer don :

Figure 38 : Interface d'effectuer don

54
La figure suivante présente l’interface d'ajouter les fournitures :

Figure 39 : Interface d'ajouter les fournitures

La figure suivante présente l’interface de gestion don pour le donateur :

Figure 40 : Interface de gestion don pour le donateur

55
Conclusion
Durant ce chapitre du Sprint n°3, nous avons, en premier lieu, organisé notre Backlog Sprint
pour définir les user story à réaliser dans ce sprint, en deuxième lieu, nous avons réalisé les
diagrammes de case d’utilisation, de classes et de séquences correspondants à ce sprint, par la
suite, nous avons illustré les imprimes écrans des interfaces créées durant ce sprint, au niveau
de la partie réalisation. Dans le chapitre qui suit, nous allons entamer le Sprint n°4 qui est
dédié à la gestion des associations et des évènements.

56
 Chapitre 6 : Sprint 4 « Gestion des associations et des
évènements »
Introduction
Ce chapitre est consacré pour décrire l’analyse, la conception et la réalisation du quatrième
sprint. Ce sprint a pour objectif de permettre la gestion des associations et des évènements.

I. Backlog Sprint

Les différentes tâches liées à la réalisation du quatrième Sprint sont décrites dans le tableau
suivant :

Tableau 18 : Backlog sprint 4

Id User stories Les sous-tâches

15 En tant que donateur, je dois pouvoir 1.Création d'un web service d'afficher la liste des
consulter la liste des événements. événements. (Back-end)

2.Création de l’interface d’afficher la liste des

événements (Front-end)

3. Intégration le web service.

4.Test du cas « Afficher les événements »

16 En tant qu’administrateur ou 1.Création d'un web service événements. (Back-end)

association, je dois pouvoir gérer les
2.Création d'un web service de modifier événements.
évènements.
(Back-end)

3.Création d'un web service d'afficher la liste des

événements (Back-end)

4.Création d'un web service de supprimer événements.

(Back-end)

4.Création de l’interface d'ajouter événements (Front-

end)

5.Création de l’interface d’afficher la liste des

57
 événements. (Front-end)

6.Création de l’interface de modifier événement

(Front-end)

7. Intégration les web services.

8.Test du cas « Ajouter événement »

9.Test du cas « Modifier événement »

10.Test du cas « Supprimer événements »

11.Test du cas « Afficher les événements »

17 En tant que donateur, je dois pouvoir 1.Création d'un web service d'afficher la liste des
consulter la liste des associations. associations. (Back-end)

2.Création de l’interface d’afficher la liste des

associations (Front-end)

3. Intégration le web service.

4.Test du cas « Afficher les associations »

18 En tant qu’association, je dois 1.Création d'un web service d’envoyer email. (Back-
pouvoir contacter le donateur par end)
email.
2.Création de l’interface d’envoyer email (Front-end)

3. Intégration le web service.

4.Test du cas « Envoyer email »

19 En tant qu’association ou admin, je 1.Création de l’interface de tableau de bord (Front-

dois pouvoir consulter les end)
statistiques.
2.Test du cas « Afficher nombre des associations »

3.Test du cas « Afficher nombre des donateurs »

4.Test du cas « Afficher nombre des événements »

5.Test du cas « Afficher nombre des dons »

58
 II. Diagrammes de cas d’utilisation détaillés du Sprint n°4

Dans ce qui suit, nous détaillons la conception de ce quatrième sprint en présentant le

diagramme de cas d’utilisation, les descriptions textuelles des fonctionnalités ainsi que les
diagrammes de séquence relatives à ce sprint.
1. Raffinement des cas d’utilisation :
La figure illustre le diagramme du cas d’utilisation détaillé « Sprint 4 ».

Figure 41 : Le diagramme du cas d’utilisation détaillé « Sprint 4 »

2. Description textuelle du cas d'utilisation « Sprint 4 » :

Le tableau présente la description textuelle du cas de « Ajouter événements »
Tableau 19 : La description textuelle du cas de « Ajouter événements »

Titre Ajouter événements

Acteur Association

Pré-condition - L’association doit être authentifié.

- Une connexion au serveur doit être établie.

Scénario nominal 1- L’association accède à l'interface d'ajout événement.

2- L’association clique sur le bouton " Ajouter événement ".

59
 3- L’association remplit le formulaire.
4- L’association clique sur le bouton " Ajouter".
5- Le système vérifie la validité des informations.

Scénario alternatifs 6- Si erreur de validation des champs un message d'erreur est

affiché.

Post-condition Ajouter don avec succès.

Le tableau présente la description textuelle du cas de « Afficher listes des événements »

Tableau 20 : La description textuelle du cas de « Afficher listes des événements »

Titre Afficher listes des événements

Acteur Admin/Association/Donateur

Pré-condition - L’admin doit être authentifié.

- Une connexion au serveur doit être établie.

Scénario nominal 1- L’admin accède à l'interface des listes des événements.

2- Le système affiche la liste des événements.

Scénario alternatifs 3- Si la liste des dons est vide. Afficher liste vide

Post-condition La liste est affichée avec succès.

Le tableau présente la description textuelle du cas de « Contacter Donateur »

Tableau 21: La description textuelle du cas de « Contacter Donateur »

Titre Contacter Donateur

Acteur Association

Pré-condition - L’association doit être authentifié.

- Une connexion au serveur doit être établie.

Scénario nominal 1- L’association accède à l'interface de liste des dons.

2- L’association clique sur l’icône "détails donateur".
3- Le système affiche les informations du donateur

60
 4- L’association clique sur « contacter »
5- L’association remplit le formulaire.
6- L’association clique sur le bouton "envoyer".
7- Le système vérifie l’envoyer d’email.

Scénario alternatifs 1- Si erreur de validation des champs un message d'erreur est

affiché.

Post-condition Envoyer email avec succès.

Le tableau présente la description textuelle du cas de « Afficher listes des associations »

Tableau 22 : La description textuelle du cas de « Afficher listes des associations »

Titre Afficher listes des associations

Acteur Donateur

Pré-condition - Le donateur doit être authentifié.

- Une connexion au serveur doit être établie.

Scénario nominal 1- Le donateur accède à l'interface des listes des associations.

2- Le système affiche la liste des associations.

Scénario alternatifs 3- Si la liste des associations est vide. Afficher liste vide

Post-condition La liste est affichée avec succès.

V. Diagrammes de séquence du Sprint n°4

Dans cette partie nous allons modéliser les diagrammes de séquences pour certains cas
d’utilisation, ce qui permettra de mieux détailler les scénarios de notre application en mettant
l’accent sur l’aspect chronologique de la séquence.

1. Diagramme de séquence du cas « Ajouter Evènements »

Le diagramme de séquence du cas d’utilisation d’ajouter événement est présenté par la figure
suivante :

61
 Figure 42: Le diagramme de séquence du cas d’utilisation d’ajouter événement

2. Diagramme de séquence du cas « Afficher Evènements »

Le diagramme de séquence du cas d’afficher événements est présenté par la figure suivante :

Figure 43 : Le diagramme de séquence du cas d’afficher événements

62
 3. Réalisation

Pour réaliser les objectifs de ce sprint, nous entamons la partie la plus importante qui est la
réalisation.
Nous passons à la présentation d’une partie de l’application de l’admin et l’association et
l’autre pour le donateur à travers des captures d’écrans produites après la finalisation de la
phase de réalisation.
La figure suivante présente l’interface de consulter les évènements pour le donateur et le
visiteur :

Figure 44: Interface de consulter les évènements pour le donateur et le visiteur

La figure suivante présente l’interface de consulter les évènements pour l'admin :

Figure 45: Interface de consulter les évènements pour l'admin

63
La figure suivante présente l’interface de consulter les évènements pour l'association :

Figure 46: Interface de consulter les événements pour l'association

La figure suivante présente l’interface de consulter les associations pour le donateur et le

visiteur :

Figure 47: Interface de consulter les associations pour le donateur et le visiteur

64
La figure suivante présente l’interface de tableau de bord pour l'association :

Figure 48: Interface de tableau de bord pour l'association

La figure suivante présente l’interface de tableau de bord pour l'admin :

Figure 49: Interface de tableau de bord pour l'admin

Conclusion
Durant ce chapitre du Sprint n°4, nous avons, en premier lieu, organisé notre Backlog Sprint
pour définir les user story à réaliser dans ce sprint, en deuxième lieu, nous avons réalisé les
diagrammes de case d’utilisation, de classes et de séquences correspondants à ce sprint, par la
suite, nous avons illustré les imprimes écrans des interfaces créées durant ce sprint, au niveau
de la partie réalisation.

65
 Conclusion générale et perspectives

Ce projet est le fruit des travaux menés au sein d'IC startup dans le cadre de Projet de fin
d'études pour une licence nationale en Technologies informatiques à l'Institut supérieur
d'études technologiques de Beja.

L'objectif de notre projet de fin d'études a été la réalisation d'une application web spécialisée
dans le secteur du don des fournitures scolaire en utilisant des technologies en plein essor.
Nous avons essayé tout au long de notre travail de construire notre module incrément par
incrément en utilisant la méthodologie Scrum. Nous avons commencé par présenter le cadre
général de notre projet afin de fixer nos objectifs à atteindre, ensuite nous avons fait une étude
préalable afin de découvrir les techniques et les outils à utiliser, et choisir la méthodologie à
suivre. Nous avons passé par la suite à analyser les besoins en déduisant le Backlog Product.
La mise en place de notre projet a nécessité la subdivision de ce dernier en quatre sprints,
pour ce faire, nous avons été amenés dans chaque sprint à étudier la conception de ces
fonctionnalités qui met l’accent sur l’aspect statique et dynamique du système décrivant
minutieusement l’aspect métier de la solution, les développer et les mettre en place en
respectant une architecture claire et standardisée.

Ce projet a été une occasion pour améliorer mes connaissances dans le domaine du
développement web. Ce projet m'a permis également de développer mes capacités
autodidactes et ma réflexion à la résolution des problèmes. Nous pensons que l'avenir du
secteur de dons aura un changement radical avec l'évolution des méthodes d'apprentissage.
C'est un domaine d'étude très prometteur et chaque jour nous découvrons de nouvelles
techniques permettant un meilleur traitement.

Dans nos perspectives, nous pensons à améliorer notre projet sur tous les plans. En effet, nous
allons essayer ajouter d'autres fonctionnalités à notre projet par exemple de créer des blogs et
aussi développer une application mobile pour le donateur pour répondre le plus possible aux
besoins des utilisateurs.

66
 Bibliographie

[1], «https://icstartup.digital/».

[2],«https://www2.stardust-testing.com/blog-fr/cascade-scrum-testing-qa/.».

[3],«https://www.journaldunet.fr/web-tech/guide-de-l-entreprise-digitale/1443834-scrum-
guide-de-la-methode-agile-star/».

[4], «https://fr.wikipedia.org/wiki/UML_(informatique)».

[5], «https://www.kicklox.com/lexique/typescript/».

[6], «https://www.50a.fr/0/angular».

[7], «https://www.journaldunet.com/web-tech/developpeur/1159810-bootstrap-definition-
tutoriels-astuces-pratiques.».

[8], «https://cours-informatique-gratuit.fr/dictionnaire/google-chrome/.».

[9], «https://techlib.fr/definition/wamp.html».

[10],«https://inf1410.teluq.ca/teluqDownload.php?file=2014/01/INF1410-
PresentationStarUML.pdf».

[11], «https://practicalprogramming.fr/postman/».

[12], «https://fr.wikipedia.org/wiki/Git».

[13],«https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203595-
mysql-my-structured-query-language-definition».

[14], «https://fr.wikipedia.org/wiki/Node.js».

[15], «https://fr.wikipedia.org/wiki/Architecture_trois_tiers.».

67