Missaoui 3 EB

iii
Dédicace
L’offre ce modeste travail :

A mes chers parents, Mais aucune dédicace ne serait témoin de mon profond amour,
Mon immense gratitude et mon plus grand respect, car je ne pourrais jamais oublier
la tendresse et l’amour dévoué par lesquels ils m’ont toujours entouré depuis mon
enfance..
Je dédie aussi ce modeste travail : , A mes frères Yassin et Islem: , qui n’ont
pas cessée de me conseiller, encourager et soutenir tout au long de mes études.
A tous les cousins, les voisins et les amis tout particulièrement Abir. , Merci pour
leurs amours et leurs encouragements..
Sans oublier mon binôme Tassnim : pour son soutien moral, sa patience et sa
compréhension tout au long de ce projet.
A mes chers formateurs et formatrice. ,sans aucune exception..

v
Remerciements
Je tiens tout d’abord à remercier Mon Dieu de m’avoir donné le courage, la force et
la volonté pour achever ce modeste travail.
Aussi, nous exprimons notre parfaite reconnaissance et nos remerciements à notre

encadrant Monsieur AYADI MOUHAMED GHAITH pour son assistance, sa disponi-
bilité, ces conseils judicieux lors de la réalisation de ce projet et son aide à l’aboutissement
de la bonne organisation de ce rapport.
Nous tenons à remercier Monsieur GASSOUMI FAOUZI , notre encadrant profes-

sionnel, pour sa disponibilité tout au long de ce stage, ses judicieux conseils et ses
encouragement, qu’il trouve ici notre respectueuse reconnaissance.
Enfin, Nous tenons à remercier de Jury de nous avoir offert l’occasion de présenter
notre projet devant leur honorable assistance et d’avoir accepté d’évaluer ce travail. .
vii
Contents
Dedications ii
Introduction générale 1
1 Cadre général du projet 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . 3
1.3.1 Société AL-IDHAFA . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Equipe et Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . 4
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Méthodes classiques . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.2 Méthodes Agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.3 Comparaison entre les méthodes classiques et les méthodes
agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.4 La méthode adoptée . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.1 Définition d’UML (Unified Modeling language) . . . . . . . . . 9
1.6.2 Objectifs de l’UML : . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.3 Diagrammes UML : . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Analyse et spécification des besoins 11

2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 11
Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Le Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . 14
2.5 Organigramme des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Equipe de réalisation de projet . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . 16
2.8.2 Environnement technique . . . . . . . . . . . . . . . . . . . . . . 16
2.9 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
viii
3 Mise en oeuvre de Sprint 1 23

3.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Tableau des taches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Phase d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Raffinement du cas d’utilisation «S’inscrire» . . . . . . . . . . . 24
3.3.3 Raffinement du cas d’utilisation «S’authentifier» . . . . . . . . . 25
3.3.4 Raffinement du cas d’utilisation «Gestion des chambres» . . . . 26
3.3.5 Raffinement du cas d’utilisation «Vérifier étudiant» . . . . . . . 28
3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.1 Conception statique . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2 Diagramme de classe de sprint 1 . . . . . . . . . . . . . . . . . . 29
3.4.3 Conception dynamique . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Réalisation du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.1 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2 Les interfaces : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.3 Interfaces d’inscription : . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.4 Interface d’authentification: . . . . . . . . . . . . . . . . . . . . . 39
3.6 Test et validation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7 Conclusion: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Phase d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1 Raffinement des cas d’utilisation de sprint 2 : . . . . . . . . . . . 43
4.2.2 Raffinement du cas d’utilisation «Demande de logement» . . . 43
4.2.3 Raffinement du cas d’utilisation «Gestion de logement» . . . . 44
4.2.4 Raffinement du cas d’utilisation «Envoyer une réclamation» . . 46
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Conception statique : . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.2 Diagramme de classe de sprint 2 . . . . . . . . . . . . . . . . . . 48
4.3.3 Conception dynamique : . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1 Base de données : . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.2 Les interfaces : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3 Interfaces demande de logement : . . . . . . . . . . . . . . . . . 54
4.6 Conclusion: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2 Phase d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.1 Raffinement de cas d’utilisation de sprint 3: . . . . . . . . . . . . 57
5.2.2 Raffinement du cas d’utilisation «Gestion de réclamation» . . . 58
5.2.3 Raffinement du cas d’utilisation «Gestion du club» . . . . . . . 60
5.2.4 Raffinement du cas d’utilisation «Déclaration de sortie» . . . . 62
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.1 Conception statique . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.2 Conception dynamique . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.1 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
ix
5.4.2 Les interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4.3 Gestion de reclamation . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.4 Interface clubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.5 Interface sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Conclusion 73
Bibliography 75
xi
List of Figures
1.1 Logo « AL-IDHAFA » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 « Equipe et Staff » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Démarche méthode « cycle en V » . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Missile command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 les artéfacts d’un projet Scrum . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . 14

2.2 Organigramme des taches . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Logo LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Logo Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Logo react . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Logo MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 Logo Vite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 Logo NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.10 Logo JSX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.11 Logo CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.12 Logo Visual Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.13 Logo Materialize CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.14 Logo Express.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.15 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 Diagramme de cas d’utilisation «S’inscrire» . . . . . . . . . . . . . . . . 24

3.2 Diagramme de cas d’utilisation «S’authentifier» . . . . . . . . . . . . . 25
3.3 Diagramme de cas d’utilisation «Gestion des chambres» . . . . . . . . 26
3.4 Diagramme de cas d’utilisation «Vérifier étudiant» . . . . . . . . . . . . 29
3.5 Diagramme de classe de sprint 1 . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Diagramme de séquence «S’inscrire partie frontend» . . . . . . . . . . 30
3.7 Diagramme de séquence «S’inscrire partie backend» . . . . . . . . . . 31
3.8 Diagramme de séquence «S’authentifier partie frontend» . . . . . . . . 31
3.9 Diagramme de séquence «S’authentifier partie backend» . . . . . . . . 32
3.10 Diagramme de séquence «Consulter chambre partie frontend» . . . . 32
3.11 Diagramme de séquence «Consulter chambre partie backend» . . . . . 33
3.12 Diagramme de séquence «Ajouter chambres partie frontend» . . . . . 33
3.13 Diagramme de séquence «Ajouter chambres partie backend» . . . . . 34
3.14 Diagramme de séquence «Supprimer chambre partie frontend» . . . . 34
3.15 Diagramme de séquence «Supprimer partie backend» . . . . . . . . . 35
3.16 Diagramme de séquence «Modifier chambre partie frontend» . . . . . 35
3.17 Diagramme de séquence «Modifier partie backend» . . . . . . . . . . . 36
3.18 Diagramme de séquence «Vérifier etudiant partie frontend» . . . . . . 36
3.19 Diagramme de séquence «Vérifier etudiant partie backend» . . . . . . 37
3.20 Collection "employes" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.21 Collection "Students" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
xii
3.22 Collection "Rooms" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.23 – Inscription ’erreur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.24 – Inscription ’erreur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.25 – Inscription ’correct’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.26 – S’authentifier ’erreur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.27 – S’authentifier ’erreur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.28 – interface d’authentification correcte . . . . . . . . . . . . . . . . . . . . 40
3.29 – Interface étudiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.30 – Test du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Diagramme de cas d’utilisation «Demande logement» . . . . . . . . . . 44

4.2 Diagramme de cas d’utilisation «Gestion de logement» . . . . . . . . . 45
4.3 Diagramme de cas d’utilisation «Envoyer une réclamation» . . . . . . 46
4.5 Diagramme de séquence «Demande de logement partie frontend» . . 49
4.6 Diagramme de séquence «Demande de logement partie backend» . . 49
4.7 Diagramme de séquence «Consulter demande partie frontend» . . . . 50
4.8 Diagramme de séquence «Consulter demande partie backend» . . . . 50
4.9 Diagramme de séquence «Accepter demande partie frontend» . . . . . 51
4.10 Diagramme de séquence «Accepter demande partie backend» . . . . . 51
4.11 Diagramme de séquence «Enlever demande partie frontend» . . . . . 52
4.12 Diagramme de séquence «Enlever demande partie backend» . . . . . 52
4.13 Diagramme de séquence «Envoyer reclamation partie frontend» . . . 53
4.14 Diagramme de séquence «Envoyer reclamation partie backend» . . . . 53
4.16 Interface "Demande de logement" . . . . . . . . . . . . . . . . . . . . . . 54
4.17 Interface "Gestion de logement" . . . . . . . . . . . . . . . . . . . . . . . 55
4.18 – Gestion de réclamation ’erreur’ . . . . . . . . . . . . . . . . . . . . . . 55
4.19 – Gestion de réclamation avec ’succés’ . . . . . . . . . . . . . . . . . . . 55
4.20 – Test du sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1 – Diagramme de cas d’utilisation«Gestion de réclamation» . . . . . . . 58

5.2 – Diagramme de cas d’utilisation«Gestion du club» . . . . . . . . . . . 60
5.3 – Diagramme de cas d’utilisation «Déclaration de sortie» . . . . . . . . 62
5.4 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.5 Diagramme de séquence «Consulter liste de réclamation partie fron-
tend» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.6 Diagramme de séquence «Consulter liste de réclamation partie back-
end» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.7 Diagramme de séquence «Modifier reclamation partie frontend» . . . 65
5.8 Diagramme de séquence «Modifier reclamation partie backend» . . . 65
5.9 Diagramme de séquence «Ajouter club partie frontend» . . . . . . . . 66
5.10 Diagramme de séquence «Ajouter club partie backend» . . . . . . . . 66
5.11 Diagramme de séquence «Rejoindre club partie frontend» . . . . . . . 67
5.12 Diagramme de séquence «Rejoindre club partie backend» . . . . . . . . 67
5.13 Diagramme de séquence «Déclaration de sortie partie frontend» . . . . 68
5.14 Diagramme de séquence «Déclaration de sortie partie backend» . . . . 68
5.15 Collection "sorties" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.16 Collection "clubs" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.17 – ’Gestion de reclamation’ . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.18 – Gestion du club ’erreur’ . . . . . . . . . . . . . . . . . . . . . . . . . . 70
xiii

5.21 – Gestion du club ’succés’ . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.22 – Sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.23 – déconnexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.24 – test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
xv
List of Tables
1.1 Méthodes classique vs Méthodes agiles . . . . . . . . . . . . . . . . . . 8
2.1 Tableau des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Tableau du Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Membre d’équipe de projet et leurs roles . . . . . . . . . . . . . . . . . 15
2.4 Tableau d’environnement matéreil . . . . . . . . . . . . . . . . . . . . . 16
3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Les scénarios d’exécution du cas d’utilisation “S’inscrire” . . . . . . . . 25
3.3 Les scénarios d’exécution du cas d’utilisation “S’authentifier” . . . . . 26
3.4 Les scénarios d’exécution du cas d’utilisation “Consulter chambre” . . 27
3.5 Les scénarios d’exécution du cas d’utilisation “Ajouter chambre” . . . 27
3.6 Les scénarios d’exécution du cas d’utilisation “Supprimer chambre” . 28
3.7 Les scénarios d’exécution du cas d’utilisation “Modifier chambre” . . . 28
3.8 Le scénario d’exécution du cas d’utilisation “Vérifier étudiant” . . . . . 29

4.2 Les scénario d’exécution du cas d’utilisation “Demande logement” . . 44
4.3 Les scénarios d’exécution du cas d’utilisation “Consulter demande” . . 45
4.4 Les scénario d’exécution du cas d’utilisation “Accepter demande” . . . 45
4.5 Les scénario d’exécution du cas d’utilisation “Enlever demande” . . . 46
4.6 Les scénarios d’exécution du cas d’utilisation “Envoyer une réclama-
tion” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 Les scénarios d’exécution du cas d’utilisation “Consulter la liste de
réclamation” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Les scénarios d’exécution du cas d’utilisation “Modifier reclamation” . 59
5.4 Les scénarios d’exécution du cas d’utilisation “Enlever réclamation” . 59
5.5 Les scénarios d’exécution du cas d’utilisation “Consulter la liste du
clubs” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.6 Les scénarios d’exécution du cas d’utilisation “Ajouter club” . . . . . . 61
5.7 Les scénarios d’exécution du cas d’utilisation “Rejoindre un club” . . . 61
5.8 Les scénarios d’exécution du cas d’utilisation “declaration de sortie” . 62
1
Introduction générale
Le monde connait une avance technologique considérable dans des différents secteurs
grâce à l’informatique qui est un domaine d’activité scientifique basé sur le traite-
ment automatique de l’information numérique, et ce dernier joue un rôle fonda-
mental dans le développement économique et social d’un pays.
Malgré la progression du monde mais on remarque que les foyers universitaires

à ce jour sont encore utilisés des supports papier, les étudiant sont ordonnés dans
les foyers en les rejoignant sur place et en apportant un certain nombre de docu-
ments requis par l’administration. De même, ils ne choisissent leurs chambres qu’en
présence.
A cet effet, notre projet de fin d’études consiste a développer une plateforme
décisionnelle de gestion des ressources informatique.
Le rapport sera composé de cinq chapitres.
- Le premier chapitre est une présentation générale de projet, la solution pro-

posée, la méthodologie utilisée.
- La deuxième chapitre analyse et spécification des besoins présente les besoins

du client, L‘ identification des acteurs, besoins fonctionnels et non fonctionnels ainsi
que le Backlog du produit, l‘organigramme des taches, l‘architecture du projet,
- La troisième chapitre s‘intitule mise en œuvre du sprint 1 le rôle de ce chapitre

est de présenter la 1ere sprint d’où nous allons élaborer l‘analyse, la conception, la
réalisation et les tests du sprint 1.
- La quatrième chapitre s’intitule mise en œuvre du sprint 2 rôle de ce chapitre

est de présenter le 2ème sprint d’où nous allons élaborer l‘analyse, la conception, la
- Le cinquième chapitre s’intitule mise en œuvre du sprint 3 rôle de ce chapitre

est de présenter le 3ème sprint d’où nous allons élaborer l‘analyse, la conception, la
- Le rapport se termine par une conclusion générale qui va récapituler tout ce qui
a été énoncé dans le rapport.
3
Chapter 1
Cadre général du projet

1.1 Introduction
Dans ce chapitre, nous commençons, en premier lieu par déterminer le cadre général
de ce projet, ensuite présenter l’organisme d’accueil, puis l’étude de l’existant, et
finir par les besoins fonctionnels et non fonctionnels.
1.2 Cadre du projet

Ce travail est effectué dans le cadre de projet de fin d’étude en vue de l’obtention de
diplôme nationale de licence en informatique applique à la gestion (IAG) , spécialité
E-Business (EB) au sein de la Faculté des Sciences Juridiques, Économiques et de
Gestion de Jendouba.
Ce projet est réalisé au sein de la société AL-IDHAFA .
Ce projet est à l’occasion de développer mon connaissances théoriques et pratiques
dans le domaine de développement web.
1.3 Présentation de l’organisme d’accueil

1.3.1 Société AL-IDHAFA
L’accompagnement d’entreprise est un service proposé par un conseiller ou une so-
ciété d’accompagnement afin d’aider les entreprises, notamment celles qui sont nou-
vellement créées, à développer leur activité et à sécuriser son démarrage au niveau
de la mise en place de certaines démarches...
C’est ainsi qu’AL-IDHAFA vous propose les bonnes techniques et astuces pour
bien démarrer, le choix de votre statut, apprendre à établir un business plan, toutes
les informations pratiques sur les formations collectives et les RDV . . . À travers des
ateliers collectifs gratuits regroupant une dizaine de participants sur 6 à 8 semaines,
vous pourrez préparer votre projet de création d’entreprise :
• Statuts, formes juridique, procédures et étapes de création d’entreprise
• Business-plan,
• Développement commercial
• Les incitations et les avantages proposées par l’ APII ; le BMN, le CEPEX , le
FAMEX , le Chèque-Service . . .
4 Chapter 1. Cadre général du projet
F IGURE 1.1: Logo « AL-IDHAFA »
1.3.2 Equipe et Staff

Le groupe de personnes assurant des fonctions de direction ou d’encadrement dans
un service, un organisme; ensemble des collaborateurs directs du directeur d’une
entreprise(voir Tab.1.1).
F IGURE 1.2: « Equipe et Staff »
1.4 Etude de l’existant

1.4.1 Description de l’existant
L’étude de l’existant est une phase très importante pour bien comprendre le système
actuel. Il permet de définir le contexte de fonctionnement et dégager les différent
insuffisances et imperfection dans le système actuel afin de le corriger. Dans cette
section je fais une étude basée sur l’observation de comment la gestion de foyer uni-
versitaire se réaliser. La gestion de foyer est réalisée par une application desktop.
Ils ont découvert plusieurs tache besoin d’améliorer, par exemple gestion des étudi-
ant. . . . Aussi des taches sont réalisées manuellement en utilisant des support papier.
1.4.2 Critique de l’existant

La critique de l’existant est une étape très nécessaire. Son objectif est d’exprimer une
opinion pour développer tout défaut existant dans le système existant dans le sys-
tème actuel afin de proposer un système plus fiable que l’ancien. Après l’observation
j’ai distingué les problèmes suivants :
• Absence d’accès directe à l’informations
• Risque de perte des informations
• Manque de sécurité des informations et des donner
1.5. Méthodologie de travail 5
• Perte de temps
• Manque de sécurité de l’information et des données.
1.4.3 Solution proposée

L’étude de l’existant montre beaucoup des problèmes voire des anomalies donc j’ai
proposé une solution qui pourra se traduire par le développement d’une application
web pour la gestion d’un foyer universitaire.
Cette plateforme a pour objectif de:
• Simplification de travail.
• Gestion et suivi des ressources logicielles.
• Minimisation des support papier utiliser.
• Facilite la recherche et l’accès aux données avec l’outil informatique.
• Réduire le temps d’accès au données.
• Amélioration de la fiabilité et de la sécurité des donnes.
• Faciliter la gestion de foyer universitaire
1.5 Méthodologie de travail

Avant la réalisation d’un projet informatique, il est nécessaire de choisir une méthodolo-
gie d’un travail afin d’aboutir à la fin a un logiciel fiable, au niveau de cette section,
nous présentons le formalisme adopté pour la conception d’un system.[4]
1.5.1 Méthodes classiques

Les méthodes classiques de gestion de projet telles que le cycle en V (Fig1.3) et le
modèle en cascade sont caractérisées par leurs aspects prédictifs, comme son nom
l’indique, il faut que tout soit planifié et défini dès le début.
Le principe de la méthode prédictive consiste à collecter dans un premier temps,
les besoins puis déterminer le produit. En d’autres termes, la particularité de cette
méthode consiste à prévoir toutes les étapes de manière séquentielle et de valider
l’étape en amont pour pouvoir passer à l’étape qui suit.
De ce fait, le chef de projet s’engage sur un planning de réalisation du projet bien
précis mais il lui est impossible d’anticiper les problèmes que l’équipe peut rencon-
trer, dans un environnement où les nouvelles technologies font leurs apparitions
constamment.
Néanmoins, parmi les méthodes classiques, la démarche cycle en V est la plus util-
isée lorsqu’il s’agit d’un projet décisionnel.
F IGURE 1.3: Démarche méthode « cycle en V »
1.5.2 Méthodes Agiles

les méthodes agiles sont des méthodologies essentiellement Dédié au projet infor-
matique.
Il optimise la façon dont les équipes travaillent ensemble et créent conjointement une
valeur ajoutée pour client. L’objectif de la méthode agile est de développer des pro-
duits plus rapidement, a moindre cout, et avec un taux de réussite et de satisfaction
plus important. En d’autres termes, la méthode agile favorise plus l’autonomie des
individus, implique au maximum le client et aussi, elle permet une grande réactivité
à ses demandes et une prise de décision plus rapide. Cette approche repose sur un
cycle de développement itératif, incrémental et adaptatif. Parmi les méthodologies
agiles nous citons, l’extrême Programming (XP), Scrum et Crystal.
Méthode SCRUM
Scrum signifie mêlée en français, son nom provient du rugby. Cette méthode est
un cadre méthodologique agile qui révolutionne la manière de l’administration du
projet.
La figure ci-dessous décrit le déroulement d’un projet Scrum.
F IGURE 1.4: Missile command
Les acteurs d’un projet SCRUM • Product owner : Il porte la vision du produit
à réaliser, il travail en interaction avec l’équipe de développement qui doit suivre ces
interactions.
• Scrum master : Il est responsable de la compréhension, de l’adhésion et de la
mise en œuvre de la méthode scrum. Il est considéré comme le coach de l’équipe de
1.5. Méthodologie de travail 7
développement.
• Equipe de d’développement : Il est charger de transformer les besoins définit par
le Product owner en fonctionnalité utilisables. Cette équipe a pour rôle de dévelop-
per le meilleur produit possible.
Présentation des événements se scrum :
un évènement scrum est une réunion assurer à fréquence régulière qui rythme le
sprint agile. Il a comme objectif de synchroniser en équipe, et adapter le plan d’action
afin d’atteindre l’objectif fixé et de développer le meilleur produit possible.
a- Le sprint
un cycle de développent court d’un produit, d’une durée maximale de 4 semaines. Il
permet de maximiser la valeur de produit livré au client. Chaque sprint a un objectif
et une liste de fonctionnalité à réaliser.
b- Planification d’un sprint :
il a pour objectif de déterminer les éléments du Product backlog à intégrer au sprint
backlog qui seront réaliser en cours de sprint. Un sprint planning est timeboxé a 8h
maximum pour un sprint de 4 semaines, 6h pour un sprint de 3 semaines, 4h pour
un sprint de 2 semaines, et 2h pour un sprint de 1 semaines.
c- Revue de sprint :
il s’agit du bilan de sprint réaliser une fois le sprint terminer, l’équipe scrum et
les parties prenantes se réunissent pour valider ce qui a été accompli pendant le
sprint.[8]
Cette réunion dure 4h maximum.
e- Rétrospective de sprint :
cette réunion est interne à l’équipe scrum et dure 3h pour un sprint d’un mois. Le
but est l’adaptation aux changements qui peuvent survenir et l’amélioration con-
tinue du processus de réalisation.
Les artéfacts d’un projet SCRUM

Les artefacts SCRUM sont basés sur un ensemble de valeurs, principes et pratiques
qui fournissent la base de la philosophie Agile.
Les artefacts SCRUM sont au nombre de 3 :
F IGURE 1.5: les artéfacts d’un projet Scrum
1.5.3 Comparaison entre les méthodes classiques et les méthodes agiles

Le tableau "Tab 1.1" présente une comparaison entre les méthodes classiques et les
méthodes agiles.
Approche classique Approche agile

Cycle de vie Phase séquentielles Itératif et incrémentale
Gestion de risque Processus district et Satisfaction du client par la
rigoureux de gestion de livraison de valeur souhaitée
risque
Mesure de succés Respect des engagements ini- satisfaction du client par la
tiaux en termes de couts, de livraison de valeur souhaité.
budget et de niveau de qual-
ité.
Equipe Equipe avec ressources spé- Equipe responsable,
cialisé dirigéés par un chef de soutenue par le chef de
projet. projet.
Qualité Controle qualité a la fin de cy- Controle de qualité per-
cle de développement. manant au niveau du produit
et du processus.
Planification Prédictictive. Adaptative
Changement Résistance au changement, Accueil favorable au change-
processus lourds de gestion ment intégré dans le proces-
des changements acceptés sus.
TABLE 1.1: Méthodes classique vs Méthodes agiles

1.6. Langage de modélisation 9
1.5.4 La méthode adoptée

Après la recherche comparative, nous avons décidé d’adopter une méthode agile
pour notre projet. Cette méthode est cohérente avec le concept de création d’une
application web.
Avec la méthode agile, nous pouvons modifier et adopter les besoins au fur et à
mesure pendant les sprints qui se suivent. Pour cela, nous avons à choisir la méthode
de développement agile Scrum qui est la mieux adaptée pour notre projet.
1.6 Langage de modélisation

Le langage UML (Unified Modeling Language) est constitué de diagrammes inté-
grés utilisés par les développeurs informatiques pour la représentation visuelle des
objets, des états et des processus dans un logiciel ou un système.[1]
1.6.1 Définition d’UML (Unified Modeling language)

Le langage UML (Unified Modeling Language, ou langage de modélisation unifié)
a été pensé pour être un langage de modélisation visuelle commun, et riche séman-
tiquement et syntaxiquement. Il :
• est destiné à l’architecture, la conception et la mise en œuvre de systèmes logi-

ciels complexes par leur structure aussi bien que leur comportement,
• a des applications qui vont au-delà du développement logiciel, notamment

pour les flux de processus dans l’industrie,
• ressemble aux plans utilisés dans d’autres domaines et se compose de dif-

férents types de diagrammes,
• n’est pas un langage de programmation, mais il existe des outils qui peu-
vent être utilisés pour générer du code en plusieurs langages à partir de di-
agrammes UML. L’UML a une relation directe avec l’analyse et la conception
orientées objet, Dans l’ensemble, les diagrammes UML décrivent la limite, la
structure et le comportement du système et des objets qui s’y trouvent.
1.6.2 Objectifs de l’UML :

• Raisonner sur le comportement du système.
• Détecter les erreurs et les omissions au début du cycle de vie.
• Présenter les conceptions proposées et communiquer avec les parties prenantes.
• Comprendre les exigences.

• Piloter la mise en œuvre.
1.6.3 Diagrammes UML :

• Diagramme des cas d’utilisation,
• Diagramme de séquence,
• Diagramme des composants,
• Diagramme de classe,
• Diagramme d’activité,
• Diagramme de collaboration,
• Diagramme de déploiement,
• Diagramme d’état.
1.7 Conclusion
Dans le premier chapitre introductif, nous avons présenté le cadre de notre projet,
puis nous avons proposé une solution qui peut répondre à nos besoins. Dans le
prochain chapitre, nous allons commencer la planification de notre projet.
11
Chapter 2
Analyse et spécification des

besoins
Introduction
L’analyse est une étape très importante au cours du cycle de vie d’un projet infor-
matique. Dans ce chapitre nous allons définir les acteurs, préciser les besoins fonc-
tionnels et non fonctionnels de notre futur application.
2.1 Identification des acteurs

Un acteur est une entité extérieur au système modélisé qui interagie directement
avec lui.
Les acteurs qui vont interagir avec ce projet sont classifiés en trois catégories :
• Employé: Employer un fonctionnaire est une personne employée par un or-

ganisme public dans un emploi permanent. Il est titularisé à son poste dans
un grade de la hiérarchie administrative.
• Etudiants: De manière générale, peut prétendre au statut d’étudiant toute

personne inscrite régulièrement dans un cursus d’enseignement secondaire,
supérieur ou universitaire. Dans certains cas, une carte d’étudiant te sera
même délivrée.
2.2 Identification des besoins

2.2.1 Besoins fonctionnels
12 Chapter 2. Analyse et spécification des besoins
Les besoins fonctionnels (selon Tab 2.1) sont l’exigence de projet donc l’application
doit être répondre aux besoins fonctionnels suivants
Fonctionnalités Description
Authentification l’application permet aux utilisateurs de
s’authentifier afin de profiter certaines fonc-
tionnalités de l’application.
Gestion de logement l’employé peut accepter ou refuser les deman-
des de logement
Gestion des étudiants l’employé peut ajouter, supprimer, modifier,
consulter les étudiant
Gestion des chambres l’employé peut ajouter, supprimer, modifier,
consulter les chambres
Gestion du club l’employé accepter ou refuser les demandes de
création de club
Gestion de reclamation l’employé peut accepter les demandes de recla-
mation
Demande de logement les étudiants peut accepter, refuser, envoyer les
demandes de binome
Declaration de sortie de les étudiant fait une declaration de sortie de
foyer foyer
TABLE 2.1: Tableau des besoins fonctionnels
Besoins non fonctionnels

A part les besoins fondamentaux, Les besoins non fonctionnels décrivent toutes les
contraintes auxquelles est soumis le système pour sa réalisation et son bon fonction-
nement.
• L’ergonomie des interfaces et la facilité d’utilisation : la plateforme doit être

simple et présente des interfaces conviviales et ergonomiques et pas trop com-
pliquées.
• La performance : doit assurer la rapidité des activités et leurs fiabilités et être

capable de manipuler un grand nombre d’enregistrements.
• La maintenabilité: Le code doit être suffisamment clair pour permettre des

éventuelles évolutions, améliorations ou corrections.
• La sécurité: L plateforme doit garantir à l’utilisateur l’intégrité et la confiden-

tialité de ses données.
2.3 Le Backlog du produit

Le backlog produit est une liste d’éléments ou de fonctionnalités nécessaires pour
atteindre les objectifs ou définir les attentes au sein d’une équipe, le tout classé par
ordre de priorité. Elle permet à ses membres de suivre leurs tâches.
2.3. Le Backlog du produit 13
Un Product Backlog inclut les champs suivants :
• Identifiant : c’est un nombre unique et auto-incrémenté pour chaque user

story.
• Thème : c’est le sujet auquel une user story est reliée.
• User story : c’est une description courte de la tâche à réaliser.
• Priorité : c’est l’importance attribué par le product owner à cette tâche.
Le tableau suivant (Tab 2.2) présente le Backlog du produit.
ID Thème User Story Priorité

1 Gestion de lo- En tant que employé accepter les étudiants trés elevé
gement
2 Authentification En tant que employé: je souhaite étre authentifier trés elevé
En tant que étudiant: je souhaite étre authentifier
3 vérifier des étu- trés élevé
diant En tant que employé: consulter la listes des étudiants et
rendre valide ou non valide .
4 Gestion de elevé
chambres En tant que employé: consulter, ajouter, supprimer, modi-
fier chambres
5 Gestion de elevé
reclamation En tant que employé: accepter les demandes de reclama-
tion
6 Envoyer une trés elevé
demande de En tant que étudiant: consulter la listes de cham-
logement bres disponibles, envoyer un demande a une chambre
disponible
7 Declaration de moyen
sortie de foyer En tant que étudiant: declaration de sortie
8 Gestion de club moyen

En tant que étudiant: participer a un club, création d’un
club
9 envoyer une moyen

reclamation En tant que étudiant: envoyer une demande de reclama-
tion(dommage)
TABLE 2.2: Tableau du Backlog du produit

2.4 Diagramme de cas d’utilisation global

Les diagrammes de cas d’utilisation sont des diagrammes UML utilisées pour une
présentation auprès de la direction ou des acteurs d’un projet. Un cas d’utilisation
représente une unité discrète d’interaction entre un utilisateur et un système
F IGURE 2.1: Diagramme de cas d’utilisation global
N.B:
Dans notre projet l’administrateur et un personne qui interagit avec mongoDB
2.5. Organigramme des tâches 15
2.5 Organigramme des tâches
F IGURE 2.2: Organigramme des taches
2.6 Diagramme de Gantt

Le diagramme de Gantt (Fig 2.3) est un outil utilisé en ordonnancement et en gestion
de projet et permettant de visualiser dans le temps les diverses tâches composant un
projet . Il s’agit d’une représentation d’un graphe connexe, permet de représenter
graphiquement l’avancement du projet.
Le diagramme permet :
— De déterminer les dates de réalisation d’un projet
— D’identifier les marges existantes sur certaines tâches
— Visualiser d’un coup d’œil le retard ou l’avancement des travaux
F IGURE 2.3: Diagramme de Gantt
2.7 Equipe de réalisation de projet
Nom projet application web pour un foyer universitaire

présentation de Jihen MISSAOUI
cadre de proje
(product owner)
Directeur du pro- Mr Mouhamed Ghaith AYADI
duit
Membre de Jihen MISSAOUI
l’équipe
TABLE 2.3: Membre d’équipe de projet et leurs roles

2.8 Environnement de travail

2.8.1 Environnement matériel
Le projet a été développé sur une machine possédant les caractéristiques décrites
dans le tableau suivants :
composant Cractéristiques
Marque Acer
Processus intel(R) Core(TM)i7-10510U CPU 1.80GHZ
2.30GHZ
Ram 16.0 GO
Type de system system d’exploitation 64 bits processeur X64
TABLE 2.4: Tableau d’environnement matéreil
2.8.2 Environnement technique

Dans cette partie, nous allons aborder les outils et les technologies qui ont servi à la
réalisation de notre application
a- LATEX
LATEX(Fig 2.4)est un langage et un système de composition de documents. Il
s’agit d’une collection de macrocommandes destinées à faciliter l’utilisation du «
processeur de texte » TeX de Donald Knuth.
LaTeX permet de rédiger des documents dont la mise en page est réalisée au-
tomatiquement en se conformant du mieux possible à des normes typographiques.
Une fonctionnalité distinctive de LaTeX est son mode mathématique, qui permet de
composer des formules complexes.
F IGURE 2.4: Logo LATEX
b- Visual Studio Code

Visual Studio Code (Fig 2.5)est un éditeur de code open-source, gratuit et mul-
tiplateforme (Windows, Mac et Linux), développé par Microsoft. Il fournit aux
développeurs à la fois un environnement de développement intégré avec des out-
ils permettant de faire avancer les projets techniques, de l’édition, à la construction,
jusqu’au débogage.
2.8. Environnement de travail 17
F IGURE 2.5: Logo Visual Studio Code
c- React
react(Fig 2.6)est une bibliothèque JavaScript libre développée par Facebook (main-
tenant Meta) depuis 2013. Le but principal de cette bibliothèque est de faciliter
la création d’application web monopage, via la création de composants dépendant
d’un état et générant une page (ou portion) HTML à chaque changement d’état..
F IGURE 2.6: Logo react
d- MongoDB
MongoDB (Fig 2.7)Apparue au milieu des années 2000, MongoDB est une base
de données NoSQL orientée document. Elle est utilisée pour le stockage de volumes
massifs de données.[12]
Démarrer avec MongoDB est très simple. Il suffit de lancer son serveur Mongo sur
son poste avec la commande mongod ou via une image Docker. Ensuite il suffit de
saisir la commande mongo pour accéder au Mongo Shell et effectuer ses premières
requêtes MongoDB.
F IGURE 2.7: Logo MongoDB
e- Vite
Vite (Fig 2.8) est un serveur de développement, créé pour faire tourner localement
des applis web. Cet outil a pour fondateur Evan You, déjà connu pour avoir développé
le framework Vue. js.
F IGURE 2.8: Logo Vite
f- NodeJS
NodeJS (Fig 2.9) est la Framework que nous avons choisi pour développer notre
partie backend en version 16.13.2 LTS. Node.js est un environnement bas niveau per-
mettant l’exécution de JavaScript côté serveur. L’un des points forts de NodeJS c’est
qu’il élimine l’attente et continue simplement avec la requête suivante. Node.js exé-
cute une programmation asynchrone à un seul thread, non bloquante, qui est très
économe en mémoire.
F IGURE 2.9: Logo NodeJS
JSX ( Fig 2.10 ) JSX (JavaScript Syntax Extension et parfois appelé JavaScript
XML) est une extension React de la syntaxe du langage JavaScript 1 qui permet de
structurer le rendu des composants à l’aide d’une syntaxe familière à de nombreux
développeurs. Il est similaire en apparence au HTML.
Les composants React sont généralement écrits à l’aide de JSX, bien qu’ils ne soient
pas obligés de l’être, car les composants peuvent également être écrits en JavaScript
pur. JSX est similaire à une autre syntaxe d’extension créée par Facebook pour PHP
appelée XHP [3]
F IGURE 2.10: Logo JSX
i- CSS
L’acronyme de CSS (Fig 2.11) est Cascading Style Sheets. Il s’agit d’un langage
permettant de gérer la présentation générale d’une page web en insérant des styles
2.8. Environnement de travail 19
sur le code HTML. Ces derniers permettent de préciser et de définir les comporte-
ments des éléments de la page.
F IGURE 2.11: Logo CSS
h-Visual Paradigm
Visual Paradigm(Fig 2.12)Visual Paradigm est un outil de modélisation perme-

ttant de mettre en place des diagrammes UML et ERD. L’application permet de
réaliser des rapports personnalisés au formats PDF, Word ou HTML afin de les
partager et de les publier sur internet par exemple .
F IGURE 2.12: Logo Visual Paradigm
i-Materialize CSS
Materialize CSS (Fig 2.13)Materialize CSS est un framework CSS open source
baser sur le design de Google Material Design, qui fournit des composants prêts à
l’emploi pour la création d’interfaces utilisateur web modernes et responsives.
F IGURE 2.13: Logo Materialize CSS
i-Express.js
Express.js(Fig 2.14)Express.js est le framework backend le plus populaire pour

Node.js, et il fait partie intégrante de l’écosystème JavaScript. Il est conçu pour con-
struire des applications web monopages, multipages et hybrides.
F IGURE 2.14: Logo Express.js
2.9 Architecture de la solution

2.9.1 Architecture logicielle
L’architecture MVC (selon Fig 2.28) est l’une des architectures logicielles les plus
utilisées pour les application Web, elle se compose de 3 modules :[2]
Modèle : noyau de l’application qui gère les données, permet de récupérer les
informations de la base de données, de les organiser pour qu’elles puissent ensuite
être traitées par le contrôleur.
Vue : composant graphique de l’interface qui permet de présenter les données

du modèle à l’utilisateur.
Contrôleur : composant responsable des prises de décision, gère la logique du

code qui prend des décisions, il est l’intermédiaire entre le modèle et la vue.
F IGURE 2.15: Architecture logicielle
2.9.2 Architecture logique

Les fonctionnalités relatives aux besoins spécifiques de notre solution exigent une
mise en place d’une architecture bien étudiée afin d’assurer une meilleure perfor-
mance.
C’est pour cette raison que dans notre projet, nous avons opté pour une archi-
tecture trois tiers qui sert principalement à concevoir l’application en trois couches
2.10. Conclusion 21
logicielles :
• La couche de présentation des données correspond à l’affichage et assure le

dialogue avec l’utilisateur.
• La couche de traitement qui assure à son tour la mise en œuvre des différentes
règles et la gestion de la logique applicative.
• La couche d’accès aux données correspond aux données qui sont destinées à
être conservées.
2.10 Conclusion
Dans ce chapitre nous avons identifié les besoins fonctionnels et non fonctionnels de
notre système ainsi que les acteurs. Ensuite, nous avons détaillé le backlog du pro-
duit Puis nous avons présenté l’environnement matériel et logiciel que nous utilis-
erons pour développer notre plateforme.
Dans le chapitre suivant nous entamons le développement du premier sprint.
23
Chapter 3
Mise en oeuvre de Sprint 1
Introduction
Ce chapitre fait l’objet d’une présentation du premier sprint du projet.
L’étude de ce sprint couvre l’analyse, la conception, l’implémentation et les tests
fonctionnels.
3.1 Backlog du sprint

Le sprint est une période qui dure entre une et quatre semaines, au bout de cette
période l’équipe doit réaliser un incrément de produit livrable. Un nouveau sprint
démarre lorsque le précédent est terminé.
Le tableau ci-dessous présente le backlog de notre premier sprint
ID Thème User Story

1 S’inscrire
• en tant que utilisateur je peux m’inscrire afin que
j’accéde aux fonctionnalités offertes par l’application
2 S’authentifier
• En tant qu’employé, je veux s’authentifier
• En tant qu’étudiant , je veux s’authentifier
2 Gestion des
chambres
• En tant qu’employé, je dois consulter, ajouter, sup-
primer,modifier chambres
4 Vérifier des
étudiants
• En tant qu’employé: je veux consulter la listes des
étudiants et rendre valide ou non valide
TABLE 3.1: Backlog du sprint 1

24 Chapter 3. Mise en oeuvre de Sprint 1
3.2 Tableau des taches

Pour Scrum, le tableau de tâche est un affichage visuel de la progression de l’équipe
Scrum au cours d’un sprint. Il est divisé en trois colonnes :
• To do : Les tâches à réaliser
• In Progress : Les tâches en cours
• Done : Les tâches réalisées
3.3 Phase d’analyse

Dans cette partie nous présentons la phase d’analyse qui répond à la question « que
fait le système ». La réponse de cette question se traduit par la présentation du dia-
gramme des cas d’utilisation puis la description textuelle de chacun d’entre eux.
3.3.1 Identification des acteurs

Les acteurs qui interagissent dans le sprint 1 sont :
— Administrateur : c’est l’acteur de back office qui capable de contrôler et config-
urer l’accés du les utilisateurs
— Utilisateur : c’est un acteur principale de notre application, qui permet de
s’inscrire et s’authentifier (peut être un étudiant ou un employé )
N.B : L’Ajout de nouvel employé s’effectue de la part de l’administrateur.
3.3.2 Raffinement du cas d’utilisation «S’inscrire»

La figure 3.1 illustre la raffinement du cas d’utilisation «s’inscrire»
Pour accéder aux fonctions, l’utilisateur doit s’inscrire en remplissant un formu-

laire donné.
F IGURE 3.1: Diagramme de cas d’utilisation «S’inscrire»
Les scénarios d’exécutions du cas d‘utilisation «s‘inscrire» sont décrits par le

tableau suivant représentant la fiche descriptive du cas :
3.3. Phase d’analyse 25
TABLE 3.2: Les scénarios d’exécution du cas d’utilisation “S’inscrire”
Cas S’inscrire
d’utilisation
Acteur Utilisateur
Pré condition
• L’utilisateur doit accéder a la page d’accueil
Post condition L’utilisateur peut accède à son espace personnel

Scénario nom-
inale
• 1.L’utilisateur demande la page d’inscription.
• 2. le systéme lui affiche la page demandée.
• 3.L’utilisateur remplit le formulaire d’inscription.
• 4.Le système vérifie les données saisies.
• 5. Le système ajoute utilisateur dans la base de données

et affiche le message:"compte crée avec succés"
Scénario alter-
natif
• L’utilisateur saisit des données manquantes
• Le système affiche un message d’erreur
• identifiants déja existant dans la base de données: Le

système afiche un message d’erreur
3.3.3 Raffinement du cas d’utilisation «S’authentifier»

La figure 3.2 illustre la raffinement du cas d’utilisation «-S’authentifier»
F IGURE 3.2: Diagramme de cas d’utilisation «S’authentifier»
Les scénarios d’exécutions du cas d‘utilisation «s‘authentifier» sont décrits par le

tableau suivant représentant la fiche descriptive du cas :
TABLE 3.3: Les scénarios d’exécution du cas d’utilisation

“S’authentifier”
Cas S’authentifier
d’utilisation
Acteur Utilisateur
Pré condition
• L’utilisateur doit avoir un compte valide
• L’utilisateur doit étre a la page d’authentification
Post condition L’utilisateur accède à son espace personnel

Scénario nom-
inale
• 1.L’utilisateur saisit son login et son mot de passe.
• 2. L’utilisateur valide l’authentification.
• 3. Le système vérifie les données saisies
• 4. Le système affiche l’espace personnel.
Scénario alter-
natif
• L’utilisateur n’a pas saisit les bons identifiants :
• Le système affiche un message d’erreur: Identifiants in-

correct (mail ou matricule)
• Le système affiche un message d’erreur: Mot de passe

incorrect
• Le système affiche un message d’erreur: compte invalide
3.3.4 Raffinement du cas d’utilisation «Gestion des chambres»

La figure 3.4 illustre la raffinement du cas d’utilisation «-Gestion des chambres»
F IGURE 3.3: Diagramme de cas d’utilisation «Gestion des chambres»
Les scénarios d’exécutions du cas d‘utilisation «Gestion des chambres» sont décrits
par les tableaux suivants représentant la fiche descriptive du cas :
TABLE 3.4: Les scénarios d’exécution du cas d’utilisation “Consulter

chambre”
Cas Consulter chambre

d’utilisation
Acteur Employé
Pré condition
• L’employé doit être authentifié
• L’employé doit être a l’interface chambre.
Post condition Afficher liste de chambres

Scénario nom-
inale
• 1. L’employé accéde a la page chambre
• 2. Le systéme affiche l’interface de formulaire et la liste

de chambres
TABLE 3.5: Les scénarios d’exécution du cas d’utilisation “Ajouter

chambre”
Cas Ajouter chambre

d’utilisation
Acteur Employé
Pré condition
• L’employé doit être a l’interface Chambres
Post condition Chambre ajoutée

Scénario nom-
inale
• 1. L’employé demande le formulaire d’ajout
• 2. Le systéme affiche le formulaire
• 3. L’employé remplit le champs et ajouter
• 4. Le système verfie les données saisies.
• 5. Le système enregistre la nouvelle chambre.
• 6. Le système envoie un message ajouté avec succés
Scénario alter-
natif
• L’employé saisit des données manquantes ou des don-
nées de chambre indisponible : Le systéme affiche un
message d’erreur
TABLE 3.6: Les scénarios d’exécution du cas d’utilisation “Supprimer

chambre”
Cas Supprimer chambre

d’utilisation
Acteur Employé
Pré condition
• L’employé doit etre authentifié
• L’employé doit consulter la liste de chambres
Post condition Chambre supprimée

Scénario
Nominale
• L’employé choisit la chambre a supprimer.
• L’employé clique sur le boutton pour supprimer le

chambre.
• Le systéme effectue la suppression .
TABLE 3.7: Les scénarios d’exécution du cas d’utilisation “Modifier

chambre”
Cas Modifier chambre

d’utilisation
Acteur Employé
Pré condition
• L’employé doit être a l’interface Chambres
Post condition Changer la disponibilité de chambre

Scénario nom-
inale
• 1. L’employé accéder a l’interface chambre
• 2. L’employé consulter la liste de toutes les chambres et

cliquer pour changer la disponibilité de chambre
• 1. le systéme envoie une requéte de modification.
Scénario alter-
natif
• Chambre contient deux étudiant: systéme affiche mes-
sage d’erreur.
3.3.5 Raffinement du cas d’utilisation «Vérifier étudiant»

La figure 3.4 illustre la raffinement du cas d’utilisation «-Vérifier étudiant»
3.4. Conception 29
F IGURE 3.4: Diagramme de cas d’utilisation «Vérifier étudiant»
Le scénario d’exécution du cas d‘utilisation «Vérifier étudiant» sont décrits par

le tableau suivant représentant la fiche descriptive du cas :
TABLE 3.8: Le scénario d’exécution du cas d’utilisation “Vérifier étu-

diant”
Cas Vérifier étudiant

d’utilisation
Acteur Employé
Pré condition
• L’employé doit accéder a l’interface étudiants
Post condition Changé la validité d’étudiant

Scénario nom-
inale
• 1. L’employé clique sur le bouton de validité
• 2. la validité de l’etudiant change.
3.4 Conception
3.4.1 Conception statique
3.4.2 Diagramme de classe de sprint 1
Un diagramme de classe de conception statique est une représentation visuelle des
classes, des attributs, des méthodes et des relations statiques entre les objets dans un
système logiciel. Il est utilisé pour décrire la structure et les interactions des classes
lors de la conception d’un système.
Une classe est représentée par un rectangle séparé en trois parties :

— première partie contient le nom de la classe
— la seconde contient les attributs de la classe
— la dernière contient les méthodes de la classe
F IGURE 3.5: Diagramme de classe de sprint 1
NB :
- demandingStudent:( array)
La listes des étudiants qui ont fait une demande a une chambre.
- affectedStudents:( array)
la liste des étudiants qui ont été affecté par l’employé a une chambre.
3.4.3 Conception dynamique

Dans les figures suivantes nous présentons le diagramme de séquence de "S’inscrire"
F IGURE 3.6: Diagramme de séquence «S’inscrire partie frontend»

3.4. Conception 31
F IGURE 3.7: Diagramme de séquence «S’inscrire partie backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "S’authentifier"
F IGURE 3.8: Diagramme de séquence «S’authentifier partie frontend»

F IGURE 3.9: Diagramme de séquence «S’authentifier partie backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Con-

sulter chambre"
F IGURE 3.10: Diagramme de séquence «Consulter chambre partie

frontend»
3.4. Conception 33
F IGURE 3.11: Diagramme de séquence «Consulter chambre partie

backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Ajouter

chambre"
F IGURE 3.12: Diagramme de séquence «Ajouter chambres partie

frontend»
F IGURE 3.13: Diagramme de séquence «Ajouter chambres partie

backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Sup-

primer chambre"
F IGURE 3.14: Diagramme de séquence «Supprimer chambre partie

frontend»
3.4. Conception 35
F IGURE 3.15: Diagramme de séquence «Supprimer partie backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Mod-

ifier étudiant"
F IGURE 3.16: Diagramme de séquence «Modifier chambre partie

frontend»
F IGURE 3.17: Diagramme de séquence «Modifier partie backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Véri-

fier étudiant"
F IGURE 3.18: Diagramme de séquence «Vérifier etudiant partie fron-

tend»
3.5. Réalisation du sprint 37
F IGURE 3.19: Diagramme de séquence «Vérifier etudiant partie back-

end»
3.5 Réalisation du sprint

3.5.1 Base de données
F IGURE 3.20: Collection "employes"
F IGURE 3.21: Collection "Students"

F IGURE 3.22: Collection "Rooms"
3.5.2 Les interfaces :

Dans cette partie, nous allons présenter quelques interfaces de l’application afin de
montrer le résultat de ce sprint.
3.5.3 Interfaces d’inscription :

La figure ci-dessous présente les erreurs
F IGURE 3.23: – Inscription ’erreur’
F IGURE 3.24: – Inscription ’erreur’
La figure ci-dessous présente une inscription correcte :

F IGURE 3.25: – Inscription ’correct’
3.5.4 Interface d’authentification:

pour accéder à son espace personnel l’utilisateur doit étre taper son login et mot de
passe correctement , ainsi que le compte doit etre valider par l’administrateur.
La figure ci-dessous présente les erreurs:
F IGURE 3.26: – S’authentifier ’erreur’
F IGURE 3.27: – S’authentifier ’erreur’

F IGURE 3.28: – interface d’authentification correcte
F IGURE 3.29: – Interface étudiant
3.6 Test et validation :

Un test de validation permet de vérifier si toutes les exigences client, décrites dans
le document de spécification du logiciel, sont respectées.
3.7. Conclusion: 41
F IGURE 3.30: – Test du sprint1
3.7 Conclusion:
Dans de ce chapitre, nous avons décrit le backlog de sprint et nous avons fait son
analyse, sa conception suivie des étapes de la réalisation et de test.
43
Chapter 4
Introduction
Ce chapitre fait l’objet d’une présentation du deuxième sprint du projet.
fonctionnels.

1 Demande de
logement
• En tant qu’étudiant je peux consulter la liste de cham-
bres disponible et envoyer une demande de logement
2 Gestion de
logement
• En tant qu’employé, je peux consulter la liste de de-
mandes et j’accepte les demande des étudiants
3 Envoyer un
réclamation
• En tant qu’étudiant: je peux envoyer un reclamation

Dans cette partie, nous présentons les diagrammes de cas d’utilisation et la descrip-
tion textuelle
4.2.1 Raffinement des cas d’utilisation de sprint 2 :

Nous allons présenter les raffinements des cas d’utilisatuion relatif au sprint 2 :
Demande de logement, Gestion de logement, Envoyer une reclamation
4.2.2 Raffinement du cas d’utilisation «Demande de logement»

La figure 4.1 illustre la raffinement du cas d’utilisation «Demande de logement»
F IGURE 4.1: Diagramme de cas d’utilisation «Demande logement»
Le scénario d’exécution du cas d‘utilisation «Demande logement» sont décrit par

le tableau suivant représentant la fiche descriptive du cas :
TABLE 4.2: Les scénario d’exécution du cas d’utilisation “Demande

logement”
Cas Demande de logement

d’utilisation
Acteur Etudiant
Pré condition
• L’etudiant doit etre authentifié
• L’etudiant doit accéder a l’interface chambre
Post condition CIN d’etudiant ajouté a liste demandingStudents

Scénario nom-
inale
• 1.L’étudiant demande une chambre
• 2.Le système envoie un message de confirmation
Scénario alter-
native
• 1. CIN d’étudiant existe déja dans la liste demand-
ingStudent ou affectedStudents dans un chambre: sys-
téme affiche un message erreur.
4.2.3 Raffinement du cas d’utilisation «Gestion de logement»

La figure 3.1 illustre la raffinement du cas d’utilisation «Gestion de logement»
F IGURE 4.2: Diagramme de cas d’utilisation «Gestion de logement»
Les scénarios d’exécutions du cas d‘utilisation «Gestion de logement» sont décrits


demande”
Cas Consulter demande

d’utilisation
Acteur Employé
Pré condition
• L’employé doit être a l’interface demande.
Post condition Afficher la liste de demande

Scénario nom-
inale
• 1. L’employé accéde a la page demande

de chambres
TABLE 4.4: Les scénario d’exécution du cas d’utilisation “Accepter

demande”
Cas Accepter demande

d’utilisation
Acteur Employé
Pré condition
• L’émployer doit etre authentifié
• L’émployer doit accéder a l’interface demande
Post condition L’ajout d’un étudiant de la liste affectdStudent .
Scénario nom-
inale
• 1.L’émployer clique sur le bouton pour affecter.
• 2. Le systéme envoie une requête d’affectation.

TABLE 4.5: Les scénario d’exécution du cas d’utilisation “Enlever de-

mande”
Cas Enlever demande

d’utilisation
Acteur Employé
Pré condition
• L’émployer doit etre authentifié
• L’employer doit accéder a l’interface demande
Post condition demande enlever
Scénario nom-
inale
• 1.L’employé clique sur le bouton pour supprimer étudi-
ant de la liste affectedStudents.
• 2.Systéme envoie une requéte de suppression
4.2.4 Raffinement du cas d’utilisation «Envoyer une réclamation»

La figure 3.1 illustre la raffinement du cas d’utilisation «Envoyer une réclamation»
F IGURE 4.3: Diagramme de cas d’utilisation «Envoyer une réclama-

tion»
Le scénario d’exécution du cas d‘utilisation «Envoyer réclamation» sont décrit

par le tableau suivant représentant la fiche descriptive du cas :
TABLE 4.6: Les scénarios d’exécution du cas d’utilisation “Envoyer

une réclamation”
Cas Envoyer une réclamation

d’utilisation
Acteur Etudiant
Pré condition
• Etudiant doit etre authentifié
• Etudiant doit accéder a l’interface reclamation
Post condition reclamation envoyée avec succés.

Scénario nom-
inale
• 1. L’étudiant demande la page de reclamation .
• 2. Le systéme affiche la page demandée.
• 3. L’étudiant remplit le formulaire de reclamation
• 4.L’étudiant clique sur le boutton envoyer
• 5. Le systéme affiche un message "reclamation envoyé

avec succés.
Scénario alter-
natif
• L’employé saisit des données manquantes:
• L’employer saisit un némuro de chambre n’existe pas:
• Même étudiant avec même numéro de chambre avec

même type de probléme :
• systéme affiche un message d’erreur.

4.3 Conception
4.3.1 Conception statique :
4.3.2 Diagramme de classe de sprint 2
4.3.3 Conception dynamique :

Diagrammes de séquence de Sprint 2 Les figure 4.5 représentes le Diagramme de
séquence «Demande de logement»
Dans les figures suivantes nous présentons le diagramme de séquence de "De-
mande de logement"
4.3. Conception 49
F IGURE 4.5: Diagramme de séquence «Demande de logement partie

frontend»
F IGURE 4.6: Diagramme de séquence «Demande de logement partie

backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Con-

sulter demande"
F IGURE 4.7: Diagramme de séquence «Consulter demande partie

frontend»
F IGURE 4.8: Diagramme de séquence «Consulter demande partie

backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Ac-

cepter demande"
4.3. Conception 51
F IGURE 4.9: Diagramme de séquence «Accepter demande partie

frontend»
F IGURE 4.10: Diagramme de séquence «Accepter demande partie

backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "En-

lever demande"
F IGURE 4.11: Diagramme de séquence «Enlever demande partie

frontend»
F IGURE 4.12: Diagramme de séquence «Enlever demande partie

backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "En-

voyer réclamation"
4.3. Conception 53
F IGURE 4.13: Diagramme de séquence «Envoyer reclamation partie

frontend»
F IGURE 4.14: Diagramme de séquence «Envoyer reclamation partie

backend»

4.4.1 Base de données :
4.4.2 Les interfaces :

4.4.3 Interfaces demande de logement :
F IGURE 4.16: Interface "Demande de logement"

F IGURE 4.17: Interface "Gestion de logement"
F IGURE 4.18: – Gestion de réclamation ’erreur’
F IGURE 4.19: – Gestion de réclamation avec ’succés’

F IGURE 4.20: – Test du sprint2
4.6 Conclusion:
57
Chapter 5
Introduction
Ce chapitre fait l’objet d’une présentation du troisième sprint du projet.
fonctionnels.

1 Gestion de
réclamation
• En tant qu’émployer je peux consulter la liste de ré-
clamations et modifié leur états .
2 Gestion du
club
• En tant qu’étudiant, je peux consulter la liste du clubs
et je peux ajouter un nouveau club ou rejoindre des
clubs.
3 déclaration
de sortie
• En tant qu’éttudiant: je peux accéder a l’interface sor-
tie et envoyer une déclaration de sortie.

Dans cette partie, nous présentons les diagrammes de cas d’utilisation et la descrip-
tion textuelle.
5.2.1 Raffinement de cas d’utilisation de sprint 3:

Nous allons présenter les raffinement des cas d’utilisation relatif au sprint 3: Gestion
de réclamation, Gestion du club, déclarationa de sortie
5.2.2 Raffinement du cas d’utilisation «Gestion de réclamation»
F IGURE 5.1: – Diagramme de cas d’utilisation«Gestion de réclama-

tion»
Les scénarios d’exécution du cas d‘utilisation «Gestion de reclamation» sont décrits


la liste de réclamation”
Cas Consulter liste de réclamation

d’utilisation
Acteur Employé
Pré condition
• L’employé doit être a l’interface reclamation.
Post condition Afficher la liste de reclamations

Scénario nom-
inale
• 1. L’employé accéder a l’interface reclamation
• 2. Le systéme affiche l’interface de la listes reclamations

TABLE 5.3: Les scénarios d’exécution du cas d’utilisation “Modifier

reclamation”
Cas Modifier reclamation

d’utilisation
Acteur Employé
Pré condition
• L’employé doit être a l’interface reclamation.
Post condition Changement de l’état ( en traitement ou bien résolu)

Scénario nom-
inale
• 1. L’employé clique sur le bouton.
• 2. Le systéme envoie une requête de modification.
• 3. Changement d’etat de reclamtion.
TABLE 5.4: Les scénarios d’exécution du cas d’utilisation “Enlever

réclamation”
Cas Enlever reclamation

d’utilisation
Acteur Employé
Pré condition
• L’employé doit consulter la liste de reclamation
Post condition reclamation supprimée

Scénario
Nominale
• L’employé choisit la reclamation a enlever.
• L’employé clique sur le boutton pour enlevé la reclama-

tion.
• Le systéme effectue envoyer une requête de suppression

.
5.2.3 Raffinement du cas d’utilisation «Gestion du club»
F IGURE 5.2: – Diagramme de cas d’utilisation«Gestion du club»
Les scénarios d’exécutions du cas d‘utilisation «Gestion du club» sont décrits par les
tableaux suivants représentant la fiche descriptive du cas :

la liste du clubs”
Cas Consulter liste du clubs

d’utilisation
Acteur Etudiant
Pré condition
• L’étudiant doit être authentifié
• L’étudiant doit être a l’interface clubs
Post condition Afficher l’interface clubs

Scénario nom-
inale
• 1. L’étudiant accéde a la page clubs

de tout les clubs.
TABLE 5.6: Les scénarios d’exécution du cas d’utilisation “Ajouter

club”
Cas Ajouter du club

d’utilisation
Acteur Etudiant
Pré condition
• L’étudiant doit être authentifié
• L’étudiant doit être a l’interface club.
Post condition Ajouter un club avec succés

Scénario nom-
inale
• 1. L’étudiant accéde a l’interface clubs
• 2. L’étudiant remplit les champs de formulaire
• 3. clique sur le bouton pour ajouter le club.
• 4. Le système envoie une requête d’ajout
Scénario alter-
natif
• L’étudiant saisit des données manquantes ou un nom du
club déja exist: le systéme affiche un message d’erreur.
TABLE 5.7: Les scénarios d’exécution du cas d’utilisation “Rejoindre

un club”
Cas Rejoindre un club

d’utilisation
Acteur Etudiant
Pré condition
• l’étudiant doit etre authentifié
• l’étudiant doit être a l’interface club.
Post condition Club rejoint avec succés

Scénario nom-
inale
• 1. L’étudiant accéde a l’interface clubs
• 2. clique sur le bouton pour joindre.
• 3. Le système affiche un message de confirmation.
Scénario alter-
natif
• l’etudiant déja un membre: Le systéme affiche un mes-
sage d’erreur.
5.2.4 Raffinement du cas d’utilisation «Déclaration de sortie»
F IGURE 5.3: – Diagramme de cas d’utilisation «Déclaration de sortie»
TABLE 5.8: Les scénarios d’exécution du cas d’utilisation “declaration

de sortie”
Cas Declaration de sortie

d’utilisation
Acteur Etudiant
Pré condition
• l’étudiant doit être authentifié
Post condition
• Instance ajouté dans la table sortie.
• Etudiant supprimer de la liste affectedStudents.
• Etudiant supprimé de la table de BD.
• Deconnexion de l’étudiant.
Scénario nom-
inale
• 1. L’étudiant accéde a l’interface sortie.
• 2. l’étudiant remplit le formulaire.
• 3. l’étudiant cliquer sue le button quitter le foyer.
• 4. Le systéme envoie une requête de sortie.

5.3. Conception 63
5.3 Conception
5.3.1 Conception statique
La figure ci-dessous présente le diagramme de classe du sprint 3
F IGURE 5.4: Diagramme de classe global
5.3.2 Conception dynamique

Nous présentons dans cette section les diagrammes de séquence des cas d’utilisation
relatifs au sprint 3.
Dans les figures suivantes nous présentons le diagramme de séquence de "Consulter
liste de réclamation "
F IGURE 5.5: Diagramme de séquence «Consulter liste de réclamation

partie frontend»
F IGURE 5.6: Diagramme de séquence «Consulter liste de réclamation

partie backend»
Dans les figures suivantes nous présentons le diagramme de séquence de " Mod-
ifier reclamation"
5.3. Conception 65
F IGURE 5.7: Diagramme de séquence «Modifier reclamation partie

frontend»
F IGURE 5.8: Diagramme de séquence «Modifier reclamation partie

backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Ajouter

club"
F IGURE 5.9: Diagramme de séquence «Ajouter club partie frontend»
F IGURE 5.10: Diagramme de séquence «Ajouter club partie backend»
Dans les figures suivantes nous présentons le diagramme de séquence de "Re-

joindre club"
5.3. Conception 67
F IGURE 5.11: Diagramme de séquence «Rejoindre club partie fron-

tend»
F IGURE 5.12: Diagramme de séquence «Rejoindre club partie back-

end»
Dans les figures suivantes nous présentons le diagramme de séquence de "Dec-

laration de sortie"
F IGURE 5.13: Diagramme de séquence «Déclaration de sortie partie

frontend»
F IGURE 5.14: Diagramme de séquence «Déclaration de sortie partie

backend»

5.4.1 Base de données
F IGURE 5.15: Collection "sorties"
F IGURE 5.16: Collection "clubs"
5.4.2 Les interfaces

5.4.3 Gestion de reclamation
F IGURE 5.17: – ’Gestion de reclamation’
5.4.4 Interface clubs

La figure ci-dessous présente un erreurs dans la formulaire de création de club (
Club déja existe )
F IGURE 5.18: – Gestion du club ’erreur’
La figure ci-dessous présente un erreurs dans la formulaire de création de club

( Club déja existe )
La figure ci-dessous présente un erreurs dans le formulaire de création de club

( champs manquants )

La figure ci-dessous présente la création du club se termine avec succés.
F IGURE 5.21: – Gestion du club ’succés’
5.4.5 Interface sortie

La figure ci-dessous présente la declaration de sortie.
F IGURE 5.22: – Sortie
La figure ci-dessous présente la déconnexion d’étudiant.
F IGURE 5.23: – déconnexion


La figure ci-dessous présente le test et la validation.
F IGURE 5.24: – test et validation
5.6 Conclusion
73
Conclusion
Ce stage s’inscrit dans le cadre du projet de fin d’études effectué au sein de la boite
de développement "Al-IDHAFA" en vue de l’obtention du diplôme de licence fon-
damentale en informatique de gestion.
Dans ce cotexte, j’ai eu l’occasion de concevoir et développer une application web
intitulée "FOYER UNIVERSITAIRE"
Pour accomplir ce travail, nous avons adopté la méthode Scrum comme méth-
ode développement, l’UML comme langage de modélisation. Notre application est
développée en React en utilisant l’environnement de développement Visual studio
code. Ainsi, afin de créer la base de données, nous avons exploité le MongoDB
qui utilise des base de données NoSQL. Nous avons commencé par la présentation
du cadre du projet. Par la suite nous avons passé à la spécification des besoins et
l’identification des acteurs afin de garantir une conception fiable. Ceci a fait l’objet
de l’étape suivante afin de pouvoir enchainer avec l’implémentation et la réalisation
de chaque Sprint mentionné dans le Backlog du Produit. Pour ce faire, nous étions
amenés à étudier, développer et mettre en place cette application en respectant une
architecture claire et standardisée qui la MVC.
Malgré les contraintes de temps et les difficultés que nous avons rencontré nous
avons réussi à réaliser presque la totalité de notre application.
Pour conclure notre travail ne s’arrête pas à ce niveau, en effet ce projet peut améliorer
• Améliorer notre application on ajout d’autre fonctionnalités.
• Améliorer la qualité de désigne des interfaces de notre application.
75
Bibliography
[1] Johannes Schönböck Dietmar Winkler Manuel Wimmer. "UML Modeling and
Code Generation in Practice: Results from a Survey". URL: https://ieeexplore.
ieee.org/document/6336424.
[2] Nikita Jha. "An Evaluation of Software Development Life Cycle Models: A Systematic
Review". URL: https://www.ijecs.in/index.php/ijecs/article/view/3637.
[3] Schwaber et Sutherland. "Scrum: A Breathtakingly Brief and Agile Introduction".
[4] Dr. N. Mohan Kumar T.M. Rajkumar. "A Comparison between Five Models of
Software Engineering". URL: https : / / www . researchgate . net / publication /
264570269_A_Comparison_between_Five_Models_of_Software_Engineering.

Missaoui 3 EB

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Missaoui 3 EB

Transféré par

Droits d'auteur :

Formats disponibles

iii

L’offre ce modeste travail :

pas cessée de me conseiller, encourager et soutenir tout au long de mes études.

A mes chers formateurs et formatrice. ,sans aucune exception..

Aussi, nous exprimons notre parfaite reconnaissance et nos remerciements à notre

Nous tenons à remercier Monsieur GASSOUMI FAOUZI , notre encadrant profes-

1 Cadre général du projet 3

2 Analyse et spécification des besoins 11

3 Mise en oeuvre de Sprint 1 23

4 Mise en oeuvre de Sprint 2 43

5 Mise en oeuvre de Sprint 3 57

5.4.2 Les interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

1.1 Logo « AL-IDHAFA » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

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

3.1 Diagramme de cas d’utilisation «S’inscrire» . . . . . . . . . . . . . . . . 24

3.22 Collection "Rooms" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1 Diagramme de cas d’utilisation «Demande logement» . . . . . . . . . . 44

5.1 – Diagramme de cas d’utilisation«Gestion de réclamation» . . . . . . . 58

5.19 – Gestion du club ’erreur’ . . . . . . . . . . . . . . . . . . . . . . . . . . 70

1.1 Méthodes classique vs Méthodes agiles . . . . . . . . . . . . . . . . . . 8

2.1 Tableau des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Malgré la progression du monde mais on remarque que les foyers universitaires

- Le premier chapitre est une présentation générale de projet, la solution pro-

- La deuxième chapitre analyse et spécification des besoins présente les besoins

- La troisième chapitre s‘intitule mise en œuvre du sprint 1 le rôle de ce chapitre

- La quatrième chapitre s’intitule mise en œuvre du sprint 2 rôle de ce chapitre

- Le cinquième chapitre s’intitule mise en œuvre du sprint 3 rôle de ce chapitre

Cadre général du projet

1.2 Cadre du projet

1.3 Présentation de l’organisme d’accueil

F IGURE 1.1: Logo « AL-IDHAFA »

1.3.2 Equipe et Staff

F IGURE 1.2: « Equipe et Staff »

1.4 Etude de l’existant

1.4.2 Critique de l’existant

1.4.3 Solution proposée

Cette plateforme a pour objectif de:

• Gestion et suivi des ressources logicielles.

• Minimisation des support papier utiliser.

• Facilite la recherche et l’accès aux données avec l’outil informatique.

• Réduire le temps d’accès au données.

• Amélioration de la fiabilité et de la sécurité des donnes.

• Faciliter la gestion de foyer universitaire

1.5 Méthodologie de travail

1.5.1 Méthodes classiques

F IGURE 1.3: Démarche méthode « cycle en V »

1.5.2 Méthodes Agiles

F IGURE 1.4: Missile command

Les artéfacts d’un projet SCRUM

F IGURE 1.5: les artéfacts d’un projet Scrum

1.5.3 Comparaison entre les méthodes classiques et les méthodes agiles

Approche classique Approche agile

TABLE 1.1: Méthodes classique vs Méthodes agiles

1.5.4 La méthode adoptée

1.6 Langage de modélisation

1.6.1 Définition d’UML (Unified Modeling language)

• est destiné à l’architecture, la conception et la mise en œuvre de systèmes logi-

• a des applications qui vont au-delà du développement logiciel, notamment

• ressemble aux plans utilisés dans d’autres domaines et se compose de dif-

1.6.2 Objectifs de l’UML :

• Détecter les erreurs et les omissions au début du cycle de vie.