Institut Supérieur des Langues Appliqués

et d’Informatique de Bèja

Projet de Fin d’Etude

conception et Implémentation d’une

application web de Gestion de magasin
catering

Élèves :
Encadrant :
Cherif Dorra
Prénom Nom
Slaimi Yassmine
Jury :
Prénom Nom
Prénom Nom

Année Universitaire 2024-2025

Remerciements

1
Résumé

2
Liste des Abréviations

3
Introduction générale
L’informatique joue un rôle vital dans le développement des entreprises. Elle offre une
opportunité pour améliorer la qualité des services. Dans le cadre de projet de fin d’étude,
nous avons eu l’opportunité de développer une application intitulé « Gestion de magasin
catering » au sein de l’agence de Express à la suite d’un stage de 4 mois. Ce travail nous
a permis de pratiquer et d’appliquer les acquis de notre formation à l’Institut Supérieur
des Langues Appliqués et d’Informatique de Béja. Notre projet consiste à développer un
logiciel destiné à optimiser la gestion du magasin catering. Il nous permet d’améliorer le
suivi des stocks et d’automatiser certaines taches afin d’augmenter la fiabilité et faciliter
les taches pénibles. Dans ce rapport nous présentons . . .. . .

4
Table des matières

Remerciements 1

Résumé 2

Liste des Abréviations 3

Introduction générale 4

1 Sprint0 :Phase de planification du projet 9

Sprint 0 9
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Présentation de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Méthodologies et Conception . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 Comparaison des méthodologies . . . . . . . . . . . . . . . . . . . . 11
1.4.2 Justification de choix de la méthodologie . . . . . . . . . . . . . . . 11
1.5 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.7 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 14
1.8 Plannification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Sprint1 :Gestion des utilisateurs et gestion des articles 16

Sprint 1 16
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Digramme de cas d’utilisation détaillé . . . . . . . . . . . . . . . . . . . . . 16
2.4 Digramme de séquence objet . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Implémentation et réalisation . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Environnement matériel et logiciel . . . . . . . . . . . . . . . . . . . 18
2.5.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.3 Choix architectural . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Présentation des interfaces du Sprint 1 . . . . . . . . . . . . . . . . . . . . 20

5
Table des matières

2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Sprint 2 : 21

Sprint 2 21
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Diagramme de cas d’utilisation détaillé . . . . . . . . . . . . . . . . . . . . 21
3.4 Diagramme de séquence objet . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Sprint 3 24

Sprint 3 24
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Diagramme de cas d’utilisation détaillé . . . . . . . . . . . . . . . . . . . . 24
4.4 Diagramme de séquence objet . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Sprint 4 26

Sprint 4 26
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Diagramme de cas d’utilisation détaillé . . . . . . . . . . . . . . . . . . . . 26
5.4 Diagramme de séquence objet . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Projet de .. 6 2024-2025
Table des figures

1.1 Logo de Tunisair Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Interface Gestion d’article . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Interface ajouter d’article . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Interface recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Cycle de vie de la méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . 12
1.6 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . . . . . 14

2.1 Diagramme de cas d’utilisation 1 . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Diagramme de séquence "Authentification" . . . . . . . . . . . . . . . . . 17
2.3 architecture MVC" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Diagramme de cas d’utilisation 1 . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Diagramme de séquence "ajouter et valider commande" . . . . . . . . . . . 22

4.1 Diagramme de cas d’utilisation 3 . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Diagramme de séquence ’retour article’ . . . . . . . . . . . . . . . . . . . . 25

5.1 Diagramme de cas d’utilisation 4 . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Diagramme de séquence "affectation des article à un vol" . . . . . . . . . . 27

7
Liste des tableaux

1.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Planification des sprints du projet . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

f

8
Chapitre 1

Sprint0 :Phase de planification du projet

1.1 Introduction
Dans ce chapitre, nous commençons par présenter l’organisme d’accueil Tunisair Ex-
press. Ensuite, nous présentons le projet en critiquant l’existant et en proposant une
solution. Nous parlons aussi de la méthodologie utilisée. Par la suite, nous spécifions les
besoins fonctionnels et non fonctionnels. Enfin, nous présentons un backlog et le dia-
gramme de cas d’utilisation.

1.2 Organisme d’accueil

Figure 1.1 – Logo de Tunisair Express

Tunisair Express [1] (code AITA : UG, code OACI : TUX), nom commercial de la
Société des lignes intérieures et internationales, est une compagnie aérienne tunisienne
fondée le 1er août 1991. Elle est une filiale de la compagnie nationale Tunisair mais acquiert
son autonomie dans tous les domaines d’activités en mars 1992. Elle se limite dans un
premier temps aux lignes intérieures tunisiennes (elle reste la seule compagnie à exploiter
le réseau domestique). Mais, ayant obtenu l’autorisation d’opérer sur le monde entier en
2000, elle élargit ses activités pour englober des liaisons internationales à destination de
dix aéroports situés notamment dans le Sud de l’Italie et à Malte.
Son activité domestique
— Tunisair Express exploite cinq lignes régulières : Djerba, Tozeur, Sfax, Gafsa.
Son activité régulière internationale :
— Tunis-Palerme-Tunis : 3 vols par semaine
— Tunis-malte-Tunis : 3 vols par semaine
— Tunis-Naples-Tunis : 2 vols par semaine

1.3 Présentation de projet

Dans cette section, nous présentons la problèmatiqque ensuite nous critiquons l’exis-
tant et proposons une solution .

9
Chapitre 1. Sprint0 :Phase de planification du projet

1.3.1 Problématique
Malgré la présence d’un logiciel de gestion, le magasin catering rencontre plusieurs pro-
blèmes comme l’absence du sécurité,pas d’authentification, suivi de stock ainsi la gestion
de commande et mannuelle alors nous allons développé une application web plus securisé
et efficace.

1.3.2 Etude de l’existant

Dans cette section , Nous allons critiquer l’existant et proposer une solution.

Analyse de l’application du magasin catering

Dans la partie gestion d’article dans l’application ne peut pas modifier ou supprimer
un article. Aussi les bouton ne sont pas claire . Meme chose pour les interfaces de gestion
des vols et fournisseurs.

Figure 1.2 – Interface Gestion d’article

Figure 1.3 – Interface ajouter d’article

L’interface est difficile à utiliser car le champ de saisie est petit et peu pratique.

Etude de l’existant
Dans cette partie nous avons identifié les lacunes afin de proposer une bonne solution.
L’application permet de gérer les stocks, mais elle présente plusieurs limites. D’abord,
l’application n’est pas sécurisée, Il n’existe pas un interface pour se connecter au site.

Projet de .. 10 2024-2025
Chapitre 1. Sprint0 :Phase de planification du projet

Figure 1.4 – Interface recherche

Ensuite, l’absence de mises à jour en temps réel des stocks donc risque de rupture et
surstock et enfin les commandes des articles destinés aux vols sont encore gérées sur
papier, ce qui génère des erreurs et des pertes d’informations.

Solution proposée
Afin de résoudre ce problème, nous allons développer une nouvelle application de
gestion du magasin catering. Cette application permettra de simplifier la gestion des
stocks, des vols et des check-lists tout en automatisant leur traitement. De plus, elle
offrira un niveau de sécurité renforcé pour garantir une meilleure protection des données
et une gestion plus efficace.

1.4 Méthodologies et Conception

1.4.1 Comparaison des méthodologies
Les méthodologies de gestion de projet diffèrent selon leurs caractéristiques. La mé-
thodologie en cascade est un modèle de développement séquentiel où chaque phase doit
être terminée avant de passer à l’autre. Si une phase validée , On ne peux pas modifier
en cours de projet. Par contre la méthodologie agile comme Scrum permet d’apporter des
modification tout au long des phases de développement du projet. elle est plannifiée en
sprints et plus flexible et mieux adaptée

1.4.2 Justification de choix de la méthodologie

Le choix de la méthode de réalisation d’un projet est l’une des étapes les plus essen-
tielles afin d’organiser le travail et d’accélérer le développement. Dans ce cadre, Nous avons
choisi la méthode de développement Agile, car elle est flexible, favorise la collaboration et
raccourcir le cycle de vie du logiciel. Alors, nous allons adopter la méthode agile « Scrum
» qui facilite la planification et l’exécution du projet, elle permet une adaptation rapide
aux changements grâce à ses itérations courtes. Scrum présente trois acteurs principaux :
Product Owner :Hammadi Nabil
Scrum Master :Hammadi Nabil
Equipe de dévelloepment : Cherif Dorra et Yasmine Slaimi

Projet de .. 11 2024-2025
Chapitre 1. Sprint0 :Phase de planification du projet

Figure 1.5 – Cycle de vie de la méthode Scrum

1.5 Spécification des besoins

Notre application doit répondre aux exigences et aux besoins que nous avons détermi-
nés afin d’assurer une gestion efficace du magasin catering. Les besoins fonctionnels sont
regroupés en différentes catégories, selon les rôles des utilisateurs.

1.5.1 Besoins fonctionnels

Administrateur
— Gestion des utilisateurs : L’administrateur peut gérer des utilisateurs, accepter
ou refuser une demande d’inscription
— Gestion des articles : L’administrateur peut gérer des articles.
— Gestion des fournisseurs : L’administrateur peut gérer des fournisseurs.
— Gestion des commandes : L’administrateur peut gérer des commandes.
— Gestion des demandes de service interne :L’administrateur peut gérer les
demandes de service internes.
— Gestion de stock : L’administrateur peut consulter les mouvements de stock et
les quantités disponibles.
— Retour article : l’administrateur peut enregistrer les retours d’articles.
— dotation et check-list : L’administrateur peut consulter les dotations affectés
aux vols et les check-list générer.

Magasinier
— Gestion des articles : Le magasinier peut ajouter, modifier et supprimer et
consulter des articles.
— Gestion des fournisseurs : Le magasinier peut ajouter, modifier et supprimer
et consulter des fournisseurs.
— Gestion des commandes : Le magasinier peut ajouter, modifier et supprimer et
consulter des commandes.
— Gestion des demandes de service interne : Le magasinier peut ajouter, mo-
difier et supprimer et consulter les demandes de service interne.
— Gestion de stock : Le magasinier peut consulter les quantités disponibles et
l’historique des mouvements de stock.
— Retour article : Le magasinier peut enregistrer les retours d’articles.

Projet de .. 12 2024-2025
Chapitre 1. Sprint0 :Phase de planification du projet

Planificateur des vols

— Dotation des avions : Le planificateur des vols peut affecter des articles à des
vols et valider une dotation.
— Gestion des check-list : Le planificateur des vols peut créer une check-list et
associer des articles à une check-list.

1.5.2 Besoins non fonctionnels

— Disponibilité : c’est à dire l’application doit etre acceccible 24h/24h.
— Performance : l’application doit etre un temps de réponse rapide au requete de
l’utilisateur.
— Sécurité : authentification des utilisateurs, gestion des roles et protection des
données sensibles.
— Maintenance : facilité de la mise à jour et correction des erreurs.

1.6 Backlog de produit

Dans cette section, nous allons présenter le backlog produit qui collecte les besoins du
client sous forme de User Stories.

Table 1.1 – Backlog de produit

Id Fonctionnalité User Stories priorité
1 Authentification En tant que magasinier, je veux m’authentifier. 1
En tant que planificateur des vols, je veux m’authentifier.
En tant qu’administrateur, je veux m’authentifier.
2 Gestion des utilisateurs En tant qu’administrateur, je veux gérer les utilisateurs. 2
En tant qu’administrateur, je veux accepter ou refuser la demande d’ins-
cription.
3 Gestion des articles En tant que magasinier, je veux gérer les articles. 3
En tant qu’administrateur, je veux gérer les articles.
4 Gestion des fournisseurs En tant que magasinier, je veux gérer les fournisseurs. 4
En tant qu’administrateur, je veux gérer les fournisseurs.
5 Gestion des commandes En tant que magasinier, je veux gérer les commandes. 5
En tant qu’administrateur, je veux gérer les commandes.
6 Gestion du stock En tant que magasinier, je veux consulter les quantités de stock disponibles. 7
En tant que magasinier, je veux être alerté sur le seuil minimal d’un article.
En tant que magasinier, je veux consulter l’historique des mouvements liés
à un article.
En tant que magasinier , je veux enregistrer les articles retournés.
En tant que magasinier , je veux gérer les demandes de service interne .
En tant qu’administrateur, je veux consulter le stock, enregister les articles
retournés et gérer les demandes de service interne.
7 Dotation et checklist En tant que planificateur des vols, je veux affecter des articles à un vol. 6
En tant que planificateur, je veux définir une quantité d’article pour chaque
vol.
En tant que planificateur des vols, je veux générer une checklist.
En tant que planificateur des vols, je veux valider une dotation.
En tant qu’administrateur, je veux consulter les dotations et les checklists.
8 Assistance technique à l’aide En tant qu’ utilisateur, je veux poser des questions à un chatbot. 8
d’ un chatbot.
9 Gestion du dashboard En tant qu’ utilisateur je veux accéder un dashboard personnalisé . 9

Projet de .. 13 2024-2025
Chapitre 1. Sprint0 :Phase de planification du projet

1.7 Diagramme de cas d’utilisation

Dans cette section, Nous présentons les besoins fonctionnels de notre application en
utilisant le diagramme de cas d’utilisation globale .

Figure 1.6 – Diagramme de cas d’utilisation globale

1.8 Plannification des sprints

Table 1.2 – Planification des sprints du projet

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Assistance
Gestion technique à
Gestion
fournisseurs et Dotation avions l’aide d’un
utilisateurs et Gestion stock
gestion des et check-list chatbot et
gestion articles
commandes gestion du
dashboard

Projet de .. 14 2024-2025
Chapitre 1. Sprint0 :Phase de planification du projet

1.9 Conclusion
Dans ce chapitre, nous avons présenté notre organisme d’accueil, Tunisair Express.
Ensuite, nous avons analysé les problèmes de l’existant et proposé une solution plus sécu-
risée, efficace et facile à utiliser. Nous avons également expliqué notre choix de la méthode
Scrum, établi le backlog produit ainsi que le diagramme de cas d’utilisation global.
À partir du chapitre suivant, nous passerons au développement des fonctionnalités,
sprint par sprint.

Projet de .. 15 2024-2025
Chapitre 2

Sprint1 :Gestion des utilisateurs et ges-

tion des articles
2.1 Introduction
Dans ce chapitre nous commençons à définir la conception de ce sprint et le backlog
produit . Nous présentons l’environnement de développement et les interface réalisé

2.2 Backlog du sprint

Dans cette section, nous commençons par présenter le backlog produit de sprint 1.

Table 2.1 – Backlog du sprint 1

User Story Tâches Estimation (j)
En tant qu’ utilisateur, je veux m’authentifier. - Créer l’interface de connexion. 3
- Implémenter la logique d’authentification.
- Tester et valider l’accès.
En tant qu’adminstrateur, je veux gérer les uti- - Créer l’interface de gestion d’utilisateur. 4
lisateurs. - Implémenter la logique backend (API et base de don-
nées).
- Tester.
En tant qu’adminstrateur, je veux accepter ou -Créer l’interface des demandes. 5
refuser une demande d’inscription. -Implémenter la logique backend.
-Tester.
En tant que magasinier, je veux gérer les ar- - Créer l’interface de gestion des articles. 3
ticles. - Implémenter la méthode de gestion des articles .
-Tester
En tant qu’Admin, je veux gérer des articles. -Réutiliser les interfaces du magasinier 1
-Tester l’accés pour l’admin

2.3 Digramme de cas d’utilisation détaillé

La figure suivante présente le diagramme de cas d’utilisation du sprint1.

16
Chapitre 2. Sprint1 :Gestion des utilisateurs et gestion des articles

Figure 2.1 – Diagramme de cas d’utilisation 1

2.4 Digramme de séquence objet

le diagramme de séquence présente les interactions entre les objets de quelques cas
d’utilisation.
La Figure 2.3 illustre le diagramme de séquence décrivant le processus de connexion
d’un utilisateur à l’application.

Figure 2.2 – Diagramme de séquence "Authentification"

Projet de .. 17 2024-2025
Chapitre 2. Sprint1 :Gestion des utilisateurs et gestion des articles

2.5 Implémentation et réalisation

Dans cette section, nous commençons par définir l’environnement matériel et logiciel
ainsi que les technologies choisies et l’architecture du projet. Enfin, nous présentons les
interfaces du sprint 1.

2.5.1 Environnement matériel et logiciel

Matériel utilisé
pour réaliser ce projet, nous avons utilisé un ordinateur personnel avec un système
d’exploitation Windows 11, et ayant les caractéristiques suivantes :
— Marque : Lenovo
— Processeur : Intel Core i5-1235U
— RAM : 16Go

Outil de base de données

Dans ce projet, nous avons choisi d’utiliser MongoDB.

MongoDB[2] est une base de données NoSQL orientée document utilisée pour le
stockage de données de gros volumes. Au lieu d’utiliser des tables et des lignes comme
dans les bases de données relationnelles traditionnelles, MongoDB utilise des collections
et des documents.

Outils de développement

Postman[8] est un logiciel permettant de créer et de tester des requêtes HTTP.

Il vous permet de les personnaliser dans les plus fins détails grâce à une interface ergono-
mique et intuitive.

Visual Studio Code [7] (VSCode) est un éditeur de code source et un environ-
nement de développement intégré (IDE) de Microsoft. Il est open-source et cross-platform,
c’est-à-dire qu’il fonctionne sur Windows, Linux et Mac. Il a été conçu pour les dévelop-
peurs web, mais il prend en charge de nombreux autres langages de programmation tels
que C++, C, Python, Java, etc.

2.5.2 Choix technologiques

[Link][3][Link] est un environnement d’exécution open-source et multipla-

teforme qui vous permet d’exécuter JavaScript côté serveur. L’architecture de ce logiciel
permet des transferts de données efficaces, ce qui en fait un choix populaire pour la
construction d’applications en temps réel et évolutives.

[Link][4](ou « Express ») est un framework Web NodeJS utilisé sur le back-end

Projet de .. 18 2024-2025
Chapitre 2. Sprint1 :Gestion des utilisateurs et gestion des articles

(ou côté serveur) des sites Web et des applications Web. Express est flexible et minimaliste,
ce qui signifie qu’il ne dispose pas d’une vaste collection de bibliothèques et de packages
inutiles, et qu’il ne dicte pas non plus la manière dont vous devez créer votre application.

[Link][5] est un framework React qui vous permet de créer des sites web sta-
tiques et des applications web surpuissantes, adaptés au référencement et extrêmement
conviviaux à l’aide du framework React.

Tailwind CSS[6] est un framework CSS open source. La fonctionnalité princi-

pale de cette bibliothèque est, contrairement à d’autres frameworks CSS comme Boots-
trap, qu’elle ne procure pas une série de classes prédéfinies pour des éléments tels que des
boutons ou des tables. À la place, Tailwind crée une liste de classes CSS « utilitaires »
pouvant être utilisés pour ajouter un style à chaque élément en les mélangeant et en les
agençant.

2.5.3 Choix architectural

Dans notre projet , nous avons adopté l’architecture MVC (Model View Controller).
Ce modèle se compose de trois composants.

— Modèle :cette couche représente les données et leur gestion dans la base de don-
nées. C’est une couche d’accès à la base de données et de manipulation des données.
— Vue : cette couche correspond à l’interface utilisateur et présente les informations
à l’utilisateur et reçoit ses interactions.
— controller :cette couche gère les requêtes entre le modèle (données) et la vue
(interface utilisateur), puis retourne une réponse.

Figure 2.3 – architecture MVC"

Projet de .. 19 2024-2025
Chapitre 2. Sprint1 :Gestion des utilisateurs et gestion des articles

2.6 Présentation des interfaces du Sprint 1

2.7 Conclusion
Dans ce chapitre, nous avons présenté notre premier sprint. Nous avons décrit le ba-
cklog produit de ce sprint, son diagramme de cas d’utilisation et de séquence. Nous avons
aussi présenté les technologies et l’architecture choisies, et enfin, les interfaces réalisées.
Dans le chapitre suivant, nous allons détailler le sprint 2 sur la gestion du stock et des
commandes.

Projet de .. 20 2024-2025
Chapitre 3

Sprint 2 :
Gestion des fournisseurs et gestion des
commandes
3.1 Introduction
A la suite du développement et de la conception du sprint1 , Nous allons commencer
à présenter le sprint 2 qui possède la gestion des fournisseurs ainsi que la gestion des
commandes.

3.2 Backlog du sprint

Table 3.1 – backlog du sprint 2

User Story Tâches Estimation (j)
En tant que magasinier, je veux gérer les four- - Créer l’interface de gestion fournisseur. 3
nisseurs. - Implémenter la méthode de gestion (backend).
- connecter frontend au backend.
-Tester
En tant qu’Admin, je veux gérer les fournnis- -Réutiliser les interfaces du magasinier -Tester l’accés 1
seurs. pour l’admin
En tant que magasinier, je veux gérer les com- - Créer l’interface de gestion commande. 3
mandes. - Implémenter la méthode de gestion (backend).
- connecter frontend au backend.
-Tester
En tant qu’Admin, je veux gérer les com- -Réutiliser les interfaces du magasinier -Tester l’accés 1
mandes. pour l’admin
En tant qu’magasinier, je veux valider une -Implémenter la méthode de mise à jour stock. 1
commande et mis à jour automatique de stock. -Tester.

3.3 Diagramme de cas d’utilisation détaillé

21
Chapitre 3. Sprint 2 :

Figure 3.1 – Diagramme de cas d’utilisation 1

3.4 Diagramme de séquence objet

Figure 3.2 – Diagramme de séquence "ajouter et valider commande"

3.5 Réalisation
3.6 Conclusion
Dans ce sprint, Nous avons présenté le backlog produit de ce sprint ainsi les dia-
grammmes de cas d’utilisation et de séquence. Enfin, Nous avons mis en place les interfaces

Projet de .. 22 2024-2025
Chapitre 3. Sprint 2 :

développé pour ce sprint.

Projet de .. 23 2024-2025
Chapitre 4

Sprint 3
Gestion de stock
4.1 Introduction
Poursuivant la développement et la conception du sprint2,Nous allons entamer à pré-
senter le sprint 3 qui

4.2 Backlog du sprint

Table 4.1 – backlog du sprint 2

User story Taches Estimation (j)
En tant que magasinier ou administrateur, je -Créer l’interface d’affichage de stock. 3
veux consulter les quantités de stock -Implémenter la méthode de récupération et d’affi-
chage.
-Tester.
En tant que magasinier ou administrateur, je -Créer l’interface de retour article. 3
veux enregistrer les articles retournés et mis à -Implémenter la méthode de mise à jour stock.
jour automatique de stock -Tester.
En tant que magasinier ou administrateur, je -Créer l’interface de gestion de commande. 3
veux gérer les demandes de service interne et -Implémenter la méthode de gestion et de mis à jour
mis à jour automatique de stock. stock.
-Tester.

4.3 Diagramme de cas d’utilisation détaillé

24
Chapitre 4. Sprint 3

Figure 4.1 – Diagramme de cas d’utilisation 3

4.4 Diagramme de séquence objet

Figure 4.2 – Diagramme de séquence ’retour article’

4.5 Réalisation
4.6 Conclusion

Projet de .. 25 2024-2025
Chapitre 5

Sprint 4
Dotation avion et check-list
5.1 Introduction
5.2 Backlog produit

Table 5.1 – backlog du sprint 2

User story Taches Estimation (j)
En tant que planificateur de vol ou adminis- -Créer l’interface d’affectation des articles. 3
trateur, je veux affecter des articles à un vol. -Implémenter la méthode de récupération des articles
et des vols
-Tester.
En tant que planificateur de vol ou adminis- -ajouter une champ pour la quantité 3
trateur, je veux définir une quantité d’article -Tester.
pour vol.
En tant que planificateur de vol ou adminis- -Créer une interface pour checklist . 3
trateur, je veux générer une checklist. -Implémenter la méthode d’affichage des checklist.
-Tester.
En tant que planificateur de vol ou adminis- -Créer une bouton pour valider une checklist . 3
trateur, je veux valider une dotation et mis à -Implémenter la méthode de validation des checklists.
jour automatique de stock. -Tester.

5.3 Diagramme de cas d’utilisation détaillé

Figure 5.1 – Diagramme de cas d’utilisation 4

26
Chapitre 5. Sprint 4
5.4 Diagramme de séquence objet

Figure 5.2 – Diagramme de séquence "affectation des article à un vol"

5.5 Réalisation
5.6 Conclusion

Projet de .. 27 2024-2025