Vous êtes sur la page 1sur 84

République Tunisienne

Ministère de l’Enseignement Supérieur


et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Années

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques


Spécialité : Ingénierie en Développement des logiciels

Par

Sahar Mannai

Développement d’un systéme


d’information pour une école de formation
professionnel

Encadrant professionnel : Mr Med Amine Harabi


Encadrant académique : Madame Sonia Zaouali

Réalisé au sein de Horizon Data

Année Universitaire 2020 - 2021


République Tunisienne

Ministère de l’Enseignement Supérieur


et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques


Spécialité : Ingénierie en Développement des logiciels

Par

Sahar Mannai

Développement d’un systéme


d’information pour une école de formation
professionnel

Encadrant professionnel : Mr Med Amine Harabi


Encadrant académique : Madame Sonia Zaouali

Réalisé au sein de Horizon Data


J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation.

Encadrant professionnel, Mr Med Amine Harabi

Le

J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation.

Encadrant académique, Madame Sonia Zaouali

Le

i
Dédicaces

Je dédie ce travail à
À mes parents, ma raison de vivre, ceux qui ont toujours parsemé mon chemin
de bonheur et d’encouragement, aucun mot ne peut décrire leurs dévouements et
leurs sacrifices.

À mes frères, pour leurs encouragements, leurs patiences et leurs


compréhensions tout au long de ce projet.

À ma soeur pour son soutien moral.

À ma famille qui m’encourage et me pousse toujours en avant.

À mes amis, en témoignage de l’amitié sincère qui nous a lié et des bons
moments que nous avons passé ensemble.

Sahar Mannai

ii
Remerciements

C’est avec un grand plaisir que je réserve cette page en signe de gratitude à tous
ceux qui m’avaient aidé à réussir ce travail.

J’adresse mes vifs remerciements et mon profond respect à Mr.Mohamed


Amine Harabi pour l’expérience enrichissante qu’il m’a fait vivre durant ces
quatre mois au sein de Data Horizon. Je tiens à lui exprimer mon entière
reconnaissance pour son aide, ses conseils et son encouragement au sein de la
société afin de bien réussir ce projet.

Mes plus grands remerciements s’adressent aussi à Mme.Sonia Zaouali, mon


encadrante académique pour m’avoir soutenu durant la période de ce projet,
pour tout son dynamisme et ses compétences scientifiques qui m’ont permis de
mener à bien ce travail. Je suis reconnaissant pour son soutien aussi bien moral
que technique. Qu’elle trouve ici le témoignage de ma profonde gratitude.

Mes remerciements s’adressent également à monsieur le président et les


membres du jury pour avoir accepté d’évaluer ce rapport avec l’espoir d’être à la
hauteur de leurs attentes.

iii
Table des matières

Introduction générale 1

1 Contexte général 2
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Domaine d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Méthodologies du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.1 Méthodologies du développement . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Architecture Utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.1 L’architecture réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.2 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Analyse et Spécification des besoins 12


2.1 Les roles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Besoins non Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Elaboration du backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Diagramme de cas d’utilisation Initiale . . . . . . . . . . . . . . . . . . . . . . . 25
2.8 Diagramme de class initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Sprint 1 : Les fonctionnalités de base 29


3.1 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

iv
3.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1 Identification des acteurs de Sprint 1 . . . . . . . . . . . . . . . . . . . . 34
3.2.2 Diagramme de cas d’utilisation détaillé du premier sprint . . . . . . . . . 34
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1 Diagramme de classe détaillé du premier sprint . . . . . . . . . . . . . . 41
3.3.2 Diagramme de séquence détaillé du premier sprint . . . . . . . . . . . . . 42
3.4 Réalisation du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.1 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.2 Gestion des enseignants . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.3 Gestion Etudiant : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.4 Gestion Emploi du temps . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.5 Gestion Absences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Les fonctionnalités avancées 51


4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.2 Diagramme de cas d’utilisation détaillé du deuxiéme sprint . . . . . . . . 56
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.1 Digramme de classe détaillé du deuxiéme sprint . . . . . . . . . . . . . . 61
4.3.2 Diagramme de séquence détaillé du deuxiéme sprint . . . . . . . . . . . . 61
4.3.3 Diagramme d’activité détaillé du deuxiéme sprint . . . . . . . . . . . . . 63
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.2 Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.3 Gestion des notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Conclusion générale 69

Bibliographie 70

v
Table des figures

1.1 Logo de la société Data Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . 3


1.2 Cartographie de Data Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Fichier contient la liste des enseignants . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Fichier contient la liste des enseignants . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Architecture SCRUM[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Architecture réseau de l’application [2] . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Equipe SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13


2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 logo springboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 logo Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 logo HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 logo Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8 logo Modelio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.9 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.10 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.11 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.12 Diagramme de class initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


3.2 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Diagramme de cas d’utilisation détaillé du premier sprint . . . . . . . . . . . . . 35
3.4 Diagramme de classe détaillé du premier sprint . . . . . . . . . . . . . . . . . . . 41
3.5 Diagramme de Séquence "Ajouter Enseignant" . . . . . . . . . . . . . . . . . . . 42
3.6 Diagramme de Séquence "Ajouter Cours" . . . . . . . . . . . . . . . . . . . . . . 43
3.7 Diagramme de Séquence "Affecter Classe" . . . . . . . . . . . . . . . . . . . . . 43
3.8 Diagramme de Séquence "Modifier Enseignant" . . . . . . . . . . . . . . . . . . 44
3.9 Diagramme de Séquence "Modifier Cours" . . . . . . . . . . . . . . . . . . . . . 44
3.10 Diagramme de Séquence "Visualiser Absences" . . . . . . . . . . . . . . . . . . . 45

vi
3.11 Diagramme de Séquence "Supprimer Cours" . . . . . . . . . . . . . . . . . . . . 45
3.12 Diagramme de Séquence "Supprimer Cours" . . . . . . . . . . . . . . . . . . . . 46
3.13 Réalisation "Liste Enseignant" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.14 Réalisation "Ajouter Enseignant" . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.15 Réalisation "Modifier Enseignant" . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.16 Réalisation "Ajouter Etudiant" . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.17 Réalisation "Emploi du temps" . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.18 Réalisation "Ajouter Absence" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1 Backlog Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52


4.2 Backlog Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3 Backlog Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4 Diagramme de classe du deuxiéme sprint . . . . . . . . . . . . . . . . . . . . . . 61
4.5 Diagramme de Séquence "S’authentifier" . . . . . . . . . . . . . . . . . . . . . . 62
4.6 Diagramme de Séquence "S’inscrire" . . . . . . . . . . . . . . . . . . . . . . . . 63
4.7 Diagramme d’activité "S’authentifier" . . . . . . . . . . . . . . . . . . . . . . . . 63
4.8 Diagramme d’activité "S’inscrire" . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.9 Réalisation "Page d’authentification" . . . . . . . . . . . . . . . . . . . . . . . . 65
4.10 Réalisation "S’authentifier" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.11 Réalisation "Création d’un compte" . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.12 Réalisation "Inscription" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.13 Réalisation "Notification" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vii
Liste des tableaux

2.1 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Cas d’utilisation "Ajouter Enseignant" . . . . . . . . . . . . . . . . . . . . . . . 36


3.2 Cas d’utilisation "Modifier Enseignant" . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Cas d’utilisation "Supprimer Enseignant" . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Cas d’utilisation "Ajouter Cours" . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Cas d’utilisation "Modifier Cours" . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Cas d’utilisation "Supprimer Cours" . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Cas d’utilisation "Affecter Classe" . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Cas d’utilisation "Visualiser les absences" . . . . . . . . . . . . . . . . . . . . . 40

4.1 Cas d’utilisation "S’authentifier" . . . . . . . . . . . . . . . . . . . . . . . . . . 57


4.2 Cas d’utilisation "S’inscrire" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Cas d’utilisation "Visualiser les notifications" . . . . . . . . . . . . . . . . . . . 59
4.4 Cas d’utilisation "Gérer les notifications" . . . . . . . . . . . . . . . . . . . . . . 60

viii
Introduction générale

Depuis quelques années, les innovations dans le domaine des technologies de l’information
en génerale et plus particuliérement dans le domaine du développement web se multiplient et
évoluent sans cesse, c’est pour ca que les entreprises dans tous les domaines ont amené a avoir
des sites web qui les présente et de suivre les changements de ces technologies pour pouvoir
profiter de ces avantages.

C’est dans ce cadre que plusieurs entreprises essayent toujours de profiter au maximum
possible de ces technologies afin d’améliorer leurs productivités et de faire face à quelques pro-
blèmes pénibles qui peuvent constituer un obstacle de progression.
Dans ce contexte, la société Horizon Data m’a confié et m’a donnée la responsabilité de dé-
velopper un systéme d’information permettant de gérer une école professionnel.

La naissance de cette idée est due pour répondre à un ensemble des besoins que l’école à
vécu notamment : la gestion des etudiants(inscription,Cours ,création des emplois du temps ...),
gestion des enseignants (gestion des informations , gestion des cours ...) et gestion des ressources
humaines (créations des niveaux avec leurs classes, affecter à chaque niveau ses disciplines ...),...

Pour mener à bien le développement de ce projet,La progression de ce rapport est ponctuée


par quatre chapitres détaillés comme suit : Le premier chapitre est dédié à la présentation de
l’organisme d’accueil ainsi qu’une étude de l’existant et une description de la solution proposée.
Quant au deuxième chapitre, il s’intéresse à l’analyse et la spécification des besoins du système
d’information. Le troisième a comme objectif de définir les fonctionnalités de base du Sprint 1.
Le Sprint 2 et ces différents réalisations sont présentés dans le quatrième chapitre.

1
Chapitre 1

Contexte général

Plan
1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . 3

2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5 Méthodologies du travail . . . . . . . . . . . . . . . . . . . . . . . . . 6

6 Architecture Utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapitre 1. Contexte général

Introduction
Dans le premier volet de ce chapitre, nous nous intéressons à la présentation de l’organisme
d’accueil "Data Horizon". Le deuxième volet est dédié à une étude de l’existant pour cerner la
problématique et énoncer par la suite la solution proposée.

1.1 Présentation de l’organisme d’accueil


Dans cette partie, nous présentons la société Data Horizon au sein de laquelle nous avons
réalisé notre projet de stage d’été.

1.1.1 Présentation

Horizon Data est une jeune SARL tunisienne spécialiser dans le domaine de la technologie
d’informations et de la communications. Cette dérniére, se caractérise par ces services de haut
gamme axé sur la qualité , l’innovation et la rapidité.
Elle opére dans différents secteurs d’activités tels que : le développement web , développe-
ment mobile , maintenance informatique , Backup et sauvgardes,...etc.[3]
La figure1.1 présente le logo de l’organisme d’accueil.

Figure 1.1: Logo de la société Data Horizon

Source: [3]

1.1.2 Domaine d’activité

Horizon Data propose les services suivants :

— Webmastering et création de contenu.

— Médias sociaux et Référencement.

— Applications Mobiles.

3
Chapitre 1. Contexte général

— Consulting.

— TI Outsourcing.

— Solutions extranet et intranet full web.

— Accompagnement et formation. [4]

1.1.3 Généralités

— ) Adresse : Horizon Data, 184 jaafer, km6 App n°9 2088 , Tunisie.[5]
La figure 1.2 présente la cartographie de la société.

Figure 1.2: Cartographie de Data Horizon

— Contact :

· ! info@horizon-data.tn

· ~ http://www.horizon-data.tn/

1.2 Étude de l’existant


Au début chaque année universitaire, la tache la plus importante pour chaque directeur de
départements de notre école universitaire est l’affectation des charges horaires d’enseignement
aux différents enseignants. le but de cette tache est de dispatcher les modules a enseigner aux
différents enseignants chacun avec une charge horaire bien précise dans son emploi du temps .
Lors de cette étape, le responsable devra tenir en compte plusieurs contraintes notamment le
grade de l’enseignant qui influence directement son du, et le volume horaire d’enseignement pour
chaque matiére, ainsi que la cofficient de chaque matiére. Lors de cette affectation, les membres

4
Chapitre 1. Contexte général

de l’administration utilisent des fichiers excel séparées contenant les informations conncernée
comme le montrent la figure1.4. [6]

Figure 1.3: Fichier contient la liste des enseignants

Source: [7]

De meme, pour les étudiants il ont obligée d’attendre l’administration de lui afficher leurs
emplois du temps , liste d’absence et d’autre informations importante. La responsable des
ressources humaines est aussi mal a l’aise avec la manipulation des fichiers Excel, et pour toute
inscription des étudiants ainsi que la programmation des réunions entre les responsables, et
d’autres encore,... [8] La figure 1.4 montre une feuille qui contient les différents spécialités et
noms des différents enseignants de l’école.

Figure 1.4: Fichier contient la liste des enseignants

Source: [9]

5
Chapitre 1. Contexte général

1.3 Problématique
Lors de l’étude que nous avons effectué dans la section précédente, nous avons dégagé les
problémes suivants :

— Les données sont stockées dans des fichiers Excel, ce qui augmente le risque de perte
d’informations(virus , absence des mécanismes de sauvgarde /restauration,etc).

— L’information est dispersée et décentralisée sur plusieurs fichiers et qui cause le probléme
de réplication et de redondance.

— Perte du temps liés a la ré-saisie des données a chaque fois. une fois un de ces fichiers est
mise a jour, impérativement les autres fichiers devront etre modifiés pour garder l’intégrité
des données.

— La complexité de la tache du responsable qui doit vérifier tout au long de son travail si
l’enseignant a atteint son du ou non.

— Communication informelle.

— Le responsable devra obligatoirement maitriser l’outil Excel, sinon il aura beaucoup des
problémes et il risque de ne pas etre efficace dans son travail.

— L’encombrement des étudiants le jour de l’affichage de l’emploi sur le panneau de l’uni-


versité.

— Des problémes liées a l’inscription des étudiants a chaque début d’année.[10]

1.4 Solution proposée


Pour remédier aux limites de la méthodes traditionnelles. L’application que nous envisageons
de développer produira les fonctionnalités nécessaires a mettre en place dans notre application
et répond aux besoins des étudiants , enseignants et ressource humaine. Ainsi qu’elle permet
de gérer la partie administrative d’une facon ergonomique , fiable et volatile.

1.5 Méthodologies du travail


La finalisation d’une application dans les délais de livraison fixée est le souci majeur de
chaque équipe du développement d’un logiciel. L’un des problèmes les plus fréquemment af-
frontés lors de la construction d’un projet est la mauvaise spécification et le changement brusque
des besoins lors de la phase de développement. Cela peut influencer géneralement l’équipe de

6
Chapitre 1. Contexte général

développement en créant un environnement de stress, et aussi ca va limité le temps consa-


cré pour la réalisation du logiciel et donc des délais de livraison dépassées. Afin d’éviter ces
situations critiques, nous adoptons la méthodologie agile comme solution pour notre projet.

1.5.1 Méthodologies du développement

Méthodologies Agiles
Les méthodes agiles caractérisent un mode de gestion des projets informatiques privilégiant la
communication entre toutes les parties prenantes, clients, utilisateurs, développeurs et autres
professionnels du projet, la souplesse en cours de réalisation, la capacité à modifier les plans et
la rapidité de livraison du projet selon uen date fixés. Il s’agit de broullier avec les pratiques
plus traditionnelles bien trop rigides et trop exigeantes en matière de spécifications (contrac-
tuelles). Pour cela il est important de mettre en rapport la priorité au relationnel et à l’échange
étendue sur les processus de développement. Une fois qu’une organisation décide d’adopter une
méthoodologie de développement Agile, il reste encore à choisir la gestion la plus adaptée à
son projet. En effet, les méthodes Agiles existantes sont nombreuses et peuvent être source de
confusion. Les méthodes Agiles les plus populaires et utilisable aujourd’hui sont :

— L’extrême Programming (XP)

— SCRUM

— Feature Driven Development (FDD)

— Lean Software Development

— Agile Unified Process (Agile UP ou AUP)

— Crystal

— Dynamic Systems Development Method (DSDM)

Pour la méthodologie de notre projet, nous avons adopté la méthode SCRUM, faisant parties
des méthodes agiles pour le cycle de développement d’un logiciel, mais également, pour la
gestion et le suivi de nos activités journalières tout au long de la période de notre stage d’été.
La méthode SCRUM C’est une méthode itérative est basée sur des itérations de courtes
durées appelées Sprints. Elle définit un cadre de travail permettant le développement des projets
complexes. Lorsqu’on dit Scrum, on dit ces jargons principale suivants :

— Responsable Produit : le représentant des clients et des utilisateurs. Il détermine ce


qui doivent être réalisé.

— SCRUM Master : le responsable du déroulement du processus. Il garantit la motivation


de l’équipe et l’efficacité de la collaboration entre les membres.

7
Chapitre 1. Contexte général

— Equipes du projet : Les développeurs chargés de la construction du logiciel et d’en faire


une démonstration.

— Backlog du produit : tout le travail est encadré par le Backlog. En effet, tout le projet
est découpé en un ensemble de "User Stories" classés par priorité et listés dans le Backlog.

— Backlog du Sprint :une sélection de tâches retenues du "Backlog du produit" pour


construire l’objectif du sprint.

— Daily meeting : c’est un point quotidien qui permet de mettre le point sur ce qui a été
réalisé, les problèmes rencontrés et les objectifs de la journée.

— Démonstration du sprint : on la nomme aussi "Sprint Review". C’est une réunion


programmée à la fin de chaque sprint durant laquelle l’équipe projet peut présenter son
travail. Sur la base de cette démonstration, le responsable produit valide ce qui a été
réalisé et détermine le nouvel objectif en se basant sur le Backlog du produit et si jamais
il y’a un ajout ou bien une modification dans ce dernier. [11]

La figure 1.5 illustre à la fois les différents rôles de Scrum que nous venons d’exhiber et le
déroulement du processus :

Figure 1.5: Architecture SCRUM[1]

8
Chapitre 1. Contexte général

1.6 Architecture Utilisées


La définition de l’architecture technique consiste à faire les choix des technologies et d’or-
ganisation des composants logiciels les plus adaptés aux besoins de l’organisme d’accueil.

1.6.1 L’architecture réseau

Il s’agit d’une application web dont l’architecture réseau la mieux adaptée est celle du
client-serveur ou elle est connue par l’architecture 3tiers qui se compose de :

— Client :Un ordinateur qui envoie des requêtes au serveur à l’aide d’un navigateur web.

— Serveur d’application : Ce dernier est appellé un middleware, il fournit la partie ap-


plicative au client et fait appel à un serveur de données.

— Serveur de données :Ce dernier possède le moteur de stockage de données pour répondre
aux requêtes du client. [12]

La figure 1.6 illustre l’architecture réseau de notre application.

Figure 1.6: Architecture réseau de l’application [2]

1.6.2 Architecture MVC

L’application de la gestion de l’école se caractérise par : le patron d’architecture ModèleVue-


Contrôleur (MVC) et avoir la couche d’abstraction d’accès aux données de type DAO (Data
Access Object). Le modèle MVC est une méthodologie de conception qui a été mise au point
en 1979 pour le développement d’application web et plus géneralement logicielles, qui sépare le

9
Chapitre 1. Contexte général

modèle de données, l’interface utilisateur et la logique de contrôle, ce qui offre les trois parties
fondamentales de l ’application.
Le modèle : cette partie représente le comportement de l’application c’est a dire le traitement
des données, l’interactions avec la base de donnée, etc. Il décrit les données utilisées par l’ap-
plication et définit les méthodes d’accès.
La vue : La vue, c’est la partie de la présentation. en fait ,c’est comment on veut que la donnée
soit présentée à l’utilisateur. Ça peut être le code qui pond du HTML ou produit un CSV, ou
par le fait de configurer de jolis boutons dans une UI.
Le contrôleur : cette partie gère les interactions avec l’utilisateur et elle détermine quels trai-
tements doivent être effectués pour une action donnée. D’une manière générale, il va utiliser
les données du modèle, les traiter en fonction de l’action de l’utilisateur, et les envoyer à la vue
pour pouvoir les affichées. Scénario de traitement :

— 1) L’utilisateur envoie une requête à l’application à l’aide de son navigateur(chrome,


Intenet Explorer,...).

— 2) Le contrôleur détermine dans quelle partie du modèle est concernée et les vues associées
aux différents parties.

— 3) Le modèle traite les interactions avec les données, il applique des règles métier et
renvoie les données a la couche du contrôleur.

— 4) Le contrôleur renseigne les données à la vue.

— 5) La vue présente les données à l’utilisateur.[13]

10
Chapitre 1. Contexte général

La figure1.6représentative de cette architecture est la suivante

Figure 1.7: Architecture MVC

Conclusion
Tout au long de ce chapitre nous avons présenté le cadre général du projet : la société
Horizon Data. Par ailleurs, nous avons pu dégager le contexte général du projet et présenter le
choix de la méthodologie et l’architecture de développement. Le chapitre suivant sera consacré
à l’analyse et Spécification des Besoins.

11
Chapitre 2

Analyse et Spécification des besoins

Plan
1 Les roles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Environnement de développement . . . . . . . . . . . . . . . . . . . 16

5 Elaboration du backlog produit . . . . . . . . . . . . . . . . . . . . . 19

6 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . 24

7 Diagramme de cas d’utilisation Initiale . . . . . . . . . . . . . . . . 25

8 Diagramme de class initial . . . . . . . . . . . . . . . . . . . . . . . . 27


Chapitre 2. Analyse et Spécification des besoins

Introduction
Notre travail est ainsi défini, nous entamons maintenant une phase importante et indispen-
sable dans le cycle de vie d’un projet, c’est l’analyse fonctionnelle et la rédaction du cahier de
charge. Nous présentons après le Backlog de produit et la planification des sprints. Ensuite,
nous allons identifier les besoins fonctionnels et non fonctionnels de l’application. Enfin, nous
allons clôturer le chapitre par la modélisation du diagramme de cas d’utilisation global du
projet ainsi que sa description textuelle.

2.1 Les roles Scrum


L’équipe Scrum est composée d’un propriétaire de produit, de l’équipe de développement
et d’un Scrum Master. Le modèle d’équipe de Scrum est conçu pour optimiser la productivité,
la créativité et la flexibilité . [14]
Nous allons tout d’abord tenter de présenter notre équipe Scrum selon la figure 2.1 ci-dessous :

Figure 2.1: Equipe SCRUM

— Product Owner (PO) : Monsieur Mohamed Amine Harabi et Son rôle est d’assurer
la présentation des caractéristiques et des fonctionnalités du produit à développer et de
l’approbation du produit à livrer.

— Scrum Master : Monsieur Tarek Brira, Le role de ce Scrum Master est d’assure glo-
balement la Supervision de l’avancement du projet et des activités de l’équipe. Il assure
également l’organisation des réunions et la bonne application de la méthode AGILE de

13
Chapitre 2. Analyse et Spécification des besoins

par ce biais.

— Team member : Mannai sahar et Riahi Wajdi . ils se charge de la réalisation des histoires
utilisateurs et élaboration des sprints.

2.2 Identification des acteurs


Un acteur est une personne ou un système informatique qui attend un ou plusieurs services
offerts par l’application. Il interagit avec le système par envoi ou la réception des requetes. Par
conséquent, nous identifions dans notre application quatre acteurs :

— Administrateur : C’est la personne qui se trouve du côté de BackOffice du site, et qui a


pour rôle la gestion des comptes.

— Etudiant : C’est un individu de l’université qui appartient a une classe particuliére , il


peut consulter des informations bien défini dans l’application.

— Enseignant : C’est la personne qui va enseigner un cours aux différents étudiants , il peut
consulter certains options comme il peut aussi ajouter , modifier et supprimer certains
données.

— Resource Humaine : C’est une partie de l’administration qui est concerné par l’inscription
des etudiants , la gestion gestion des absences et d’autres encore...

La figure 2.8 présente les acteurs et leurs roles.

14
Chapitre 2. Analyse et Spécification des besoins

Figure 2.2: Identification des acteurs

2.3 Identification des besoins


2.3.1 Besoins Fonctionnels

L’identification des besoins consiste à traduire les objectifs de l’application en un ensemble


de fonctionnalités ciblées et bien définis par l’outil à réaliser. Ceci procurera une compréhension

15
Chapitre 2. Analyse et Spécification des besoins

plus claire des tâches à mettre en œuvres.

2.3.2 Besoins non Fonctionnels

— L’ergonomie : L’application doit être adaptée à l’utilisateur sans qu’il ne fournisse beau-
coup d’effort a comprendre (utilisation claire et facile) de point de vue navigation entre
les différentes pages, couleurs et mise en textes utilisés, symboles et boutons. et ceci en
utilisant un texte lisible pour la lecture , des termes simples et classique.

— La performance : il s’agit d’optimiser le maximum du temps de chargements des donnés


depuis deux environnements différents c’est a dire la rapidité de chargement des pages
web de l’application.

— L’évolutivité : l’application peut avoir des extensions et des amélioration dans le temps,
toute en intégrant des nouveaux modules pour répondre aux nouveaux besoins fonction-
nels et ceci sans modifier les modules déjà existantes. Cette fonction elle sera assuré en
en adoptant des patrons du développement MVC et DAO.

— La Portabilité : C’est a dire la facilité de la consultation de la site sur n’importe quelle


plateforme par pc,tablette ou smart phone. cette fonction sera garantie par l’utilisation
du web responsive et l’utilisation de la technologie CSS.

— La sécurité : L’accès à l’application et les données en géneral doit être sécurisé vu la


sensibilité des données tels que : la liste des enseignants et leurs informations personnelles,
la liste des etudiants et surtout des paiements qui doivent être bien protégés. [14]

2.4 Environnement de développement


Pour la réalisation des taches, il est indispensable d’adopter plusieurs environnements

2.4.1 Environnement matériel

— Premier PC : Lenovo/Intel Core i5/CPU @ 2.60GHZ(8CPUs) /12Go RAM

— Deuxième PC : HP/Intel Core i5/CPU @ 2.60GHZ(8CPUs) /16Go RAM

— Troisième PC : HP/Intel Core i5/CPU @ 2.60GHZ(8CPUs) /4Go RAM

2.4.2 Environnement logiciel

Pour le développement du module en question, il nous a été nécessaire de maitriser les


environnements logiciels suivantes :

16
Chapitre 2. Analyse et Spécification des besoins

Environnement de développement intégré :


-Spring Boot c’est un framework java qui gére et simplifie le développement d’applications
fondées sur Spring , toute en offrant des outils permettant d’obtenir une application packagée
en "jar". cet outil est créer par l’équipe de chez Pivotal.[14]
La figure 2.8 ci-dessous présente le logo :

Figure 2.3: logo springboot

-Angular c’est un framework open source,c’est coté client, il est basé sur le langage TypeScript.
Il permet de créer des applications web dynamiques, immersives et en SPA.
La figure 2.8 ci-dessous présente le logo : [14]

Figure 2.4: logo Angular

Langage de Description :
-Le HTML est un langage de base pour la création des application web. Il se base principalement
sur le principe de balises imbriquées. [14]
La figure 2.8 ci-dessous présente le logo :

Figure 2.5: logo HTML

-Bootstrap est une infrastructure de développement frontale, gratuite et open source pour la

17
Chapitre 2. Analyse et Spécification des besoins

création de sites et d’applications Web. L’infrastructure Bootstrap repose sur HTML, CSS et
JavaScript (JS) pour faciliter le développement de sites et d’applications réactives et tout-
mobile.
La figure 2.8 ci-dessous présente le logo : [14]

Figure 2.6: logo Bootstrap

Environnement de test :
-Postman est une application permettant de tester des API créer dans la partie backend de
l’application,cet outil est créer dont le but est de répondre à une problématique des developpeurs
dont le test d’API partageable.
La figure 2.8 ci-dessous présente le logo : [14]

Figure 2.7: logo Postman

Environnement Conceptuel :
Modelio est un outil de modélisation UML disponible sur les plates-formes Windows, Linux et
Mac. Il intègre également la modélisation BPMN, et le support de la modélisation des exigences,
du dictionnaire, des règles métier et des objectifs.
La figure 2.8 ci-dessous présente le logo : [14]

18
Chapitre 2. Analyse et Spécification des besoins

Figure 2.8: logo Modelio

2.5 Elaboration du backlog produit


Le Backlog Produit est destiné à recueillir tous les besoins du client que l’équipe projet
de développement doit réaliser. Il contient donc la liste des fonctionnalités intervenant dans
la constitution d’un produit, ainsi que tous les éléments nécessitant l’intervention de l’équipe
projet et l’ordonancement des taches a effectuer.
Le tableau 2.10 suivant représente le Backlog produit de notre application en énumérant les
champs suivants :

19
Chapitre 2. Analyse et Spécification des besoins

ID Fonctionnalité User stories Priorité Durée(Jours)


-En tant que Etudiant
Consulter et je peux consulter et
Téléchar- télécharger mes cours
ger/Importer de n’importe quel
1 Cours navigateur. 1 4
En tant que
Enseignant je peux
consulter et importer
et supprimer mes
cours.
-En tant que Etudiant
je peux consulter mon
emploi du temps de
Consulter n’importe que
2 Emploi navigateur. 1 5
En tant que
Enseignant je peux
consulter l’emploi de
mes étudiants.
En tant que
Administrateur je
peux Ajouter,
Supprimer, Modifier
un emploi du temps.

20
Chapitre 2. Analyse et Spécification des besoins

ID Fonctionnalité User stories Priorité Durée(Jours)


-En tant que
Ressource Humaine je
peux Ajouter ou bien
Consulter Supprimer un emploi
2 Emploi du temps 1 5
-En tant que Etudiant
je peux m’authentifier
pour accéder a mon
3 Authentification compte. 2 7
-En tant que
Enseignant je peux
m’authentifier pour
accéder a mon
compte.
-En tant que
Ressource humaine je
peux m’authentifier
pour accéder a mon
compte.
-En tant que
Administrateur je
peux m’authentifier
pour accéder a mon
compte.

21
Chapitre 2. Analyse et Spécification des besoins

Tableau 2.1: Backlog Produit

ID Fonctionnalité User stories Priorité Durée(Jours)


-En tant que
Etudiant je peux
m’inscrit a n’importe
4 Inscription quel moment. 2 10
-En tant que
Ressource humaine je
peux faire
l’inscription de mes
étudiants.
-En tant que Etudiant
Consulter les je peux consulter ma
5 absences liste des absences. 1 4
-En tant que
Administrateur je
peux consulter,
modifier, supprimer et
ajouter des absences a
la liste des absences.
-En tant que
Enseignant je peux
consulter, ajouter des
absences a la liste des
absences.

22
Chapitre 2. Analyse et Spécification des besoins

ID Fonctionnalité User stories Priorité Durée(Jours)


-En tant que
Administrateur
je peux affecter
les étudiants à
6 Affecter Classe leurs classes. 1 3
-En tant que
Ressource
humaine je peux
affecter les
étudiants à leurs
classes.
-En tant que
Enseignant je
peux voir la liste
des étudiants de
chaque classe.
-En tant que
Ressource
humaine je peux
notifier les
enseignants
d’une réunion,
d’un
Gestion des changement
7 notifications d’emploi,. . . 2 7
-En tant que
Enseignant je
peux consulter
la notification
envoyé par la
ressource
humaine.

23
Chapitre 2. Analyse et Spécification des besoins

2.6 Planification des sprints


Nous allons présenter en premier lieu notre découpage du projet en ensemble des sprints.
comme elle indique la figure 2.10.

Figure 2.9: Sprint 1

Et pour la figure 2.10 elle indique le sprint 2 comme suit :

Figure 2.10: Sprint 2

24
Chapitre 2. Analyse et Spécification des besoins

2.7 Diagramme de cas d’utilisation Initiale


Les diagrammes de cas d’utilisation ce sont des diagrammes UML exploitées pour accorder
le comportement fonctionnel d’un système logiciel. Ils sont indispensable pour les présentations
auprès des acteurs ,de la direction ou bien des jurys. Mais pour le développement, Ils sont consi-
dérer les plus appropriés. Un cas d’utilisation représente une unité discrète d’interaction entre
un utilisateur(humainoumachine) et un système.Ilest une unité significative de travail. Dans un
diagramme de cas d’utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent
avec les cas d’utilisation (use cases).Comme elle indique la figure 2.12.

25
Chapitre 2. Analyse et Spécification des besoins

Figure 2.11: Diagramme de cas d’utilisation

26
Chapitre 2. Analyse et Spécification des besoins

2.8 Diagramme de class initial


Notre diagramme de class initial est :

Figure 2.12: Diagramme de class initial

27
Chapitre 2. Analyse et Spécification des besoins

Conclusion
Tout au long de ce chapitre, nous avons identifié l’équipe de projet. Par ailleurs, nous avons
construit le Backlog produit de notre application en se basant sur les besoins fonctionnels.
Finalement,Nous avons mentionné le découpage de notre release en des sprints ainsi que les
diagramme de cas d’utilisatin et de classe initiale. Donc, Le chapitre suivant sera consacré à
présenter et détailler le premier sprint.

28
Chapitre 3

Sprint 1 : Les fonctionnalités de base

Plan
1 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Réalisation du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Introduction
Le chapitre en cours, va traiter les user stories de notre sprint en les classant dans des feautres
qui pourront s’intégrer à la release de notre projet. Au sein de ce sprint, les user stories vont
passer par les quatre étapes du SCRUM, qui sont l’analyse, la conception, le développement et
les tests.

3.1 Backlog Sprint 1

Figure 3.1: Backlog Sprint 1

Le tableau ci-dessous représente la planification détaillée du sprint 1.

30
Chapitre 3. Sprint 1 : Les fonctionnalités de base

ID Fonctionnalité Taches Priorité Durée(Jours)


-En tant que
Etudiant je
peux consulter
et télécharger
Consulter et mes cours de
Télécharger/Importer n’importe quel
1 Cours navigateur. 1 4
En tant que
Enseignant je
peux consulter
et importer et
supprimer mes
cours.
-En tant que
Etudiant je
peux consulter
mon emploi du
temps de
n’importe que
2 Consulter Emploi navigateur. 1 5
-En tant que
Enseignant je
peux consulter
l’emploi de mes
étudiants.
-En tant que
Administrateur
je peux Ajouter,
Supprimer,
Modifier un
emploi du
temps.

31
Chapitre 3. Sprint 1 : Les fonctionnalités de base

ID Fonctionnalité Taches Priorité Durée(Jours)


-En tant que
Ressource
Humaine je
peux Ajouter ou
bien Supprimer
un emploi du
2 Consulter Emploi temps. 1 5
-En tant que
Etudiant je
peux consulter
ma liste des
5 Consulter les absences absences. 1 4
-En tant que
Administrateur
je peux
consulter,
modifier,
supprimer et
ajouter des
absences a la
liste des
absences.
-En tant que
Enseignant je
peux consulter,
ajouter des
absences a la
liste des
absences.

32
Chapitre 3. Sprint 1 : Les fonctionnalités de base

ID Fonctionnalité Taches Priorité Durée(Jours)


-En tant que
Administrateur
je peux affecter
les étudiants à
6 Affecter Classe leurs classes. 1 3
-En tant que
Ressource
humaine je peux
affecter les
étudiants à leurs
classes.
-En tant que
Enseignant je
peux voir la liste
des étudiants de
chaque classe.

3.2 Spécification des besoins


Nous devons établir les fonctionnalités que le Sprint 1 doit l’assurer. Pour cela nous avons
utilisé le diagramme de cas d’utilisation, nous commençons donc par identifier les acteurs et
énumérer les cas d’utilisation .Ensuite, les diagrammes seront présentés

33
Chapitre 3. Sprint 1 : Les fonctionnalités de base

3.2.1 Identification des acteurs de Sprint 1

Ce sprint comporte 4 acteurs. Le tableau ci-dessous représente la classification des acteurs


selon le cas d’utilisation du sprint1.

Figure 3.2: Backlog Sprint 1

3.2.2 Diagramme de cas d’utilisation détaillé du premier sprint

34
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Figure 3.3: Diagramme de cas d’utilisation détaillé du premier sprint

35
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Description du cas d’utilisation "Ajouter Enseignant"

Tableau 3.1: Cas d’utilisation "Ajouter Enseignant"

C.U Ajouter Enseignant

Acteur Ressource Humaine

Objectif Ajouter un Enseignant

1.L’acteur saisit son adresse et mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
3.l’acteur choisi l’option "Gestion des enseignants"
4.la liste des enseignants disponible sera affichée.
5.l’acteur clique sur la bouton Ajouter Enseignant qui se trouve a coté du
Scénario nominal
tableau affiché.
6.Un formulaire dans ce sens sera ouvert pour écrire les coordonnées de
la nouvelle enseignant.
7. l’acteur remplit les champs de la formulaire et valide.
8. le systéme va retournée avec un succées.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

Description du cas d’utilisation "Modifier Enseignant"

36
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Tableau 3.2: Cas d’utilisation "Modifier Enseignant"

C.U Modifier Enseignant

Acteur Ressource Humaine

Objectif Modifier les coordonnées d’un Enseignant

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
3.l’acteur choisi l’option "Gestion des enseignants" et une liste sera affichée.
Scénario nominal
5.l’acteur choisit l’option modifier devant le nom de l’enseignant.
6.Un formulaire sera ouvert contenant les coordonnées de l’enseignant.
7. l’acteur modifie les champs et valide

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

Description du cas d’utilisation "Supprimer Enseignant"

Tableau 3.3: Cas d’utilisation "Supprimer Enseignant"

C.U Supprimer Enseignant

Acteur Ressource Humaine

Objectif Supprimer un Enseignant

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
3.l’acteur choisi l’option "Gestion des enseignants
Scénario nominal
4.la liste des enseignants disponible sera affichée.
5.l’acteur clique sur la bouton supprimer devant l’enseignant qu’il veux
le supprimer.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

37
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Description du cas d’utilisation "Ajouter Cours"

Tableau 3.4: Cas d’utilisation "Ajouter Cours"

C.U Ajouter Cours

Acteur Enseignant

Objectif Ajouter un Cours

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
3.l’acteur choisi l’option "Gestion des Cours"
4.la liste des cours disponible sera affichée.
Scénario nominal 5.l’acteur clique sur la bouton Ajouter cours.
6. un formulaire sera affiché pour l’ajout du cours
7.l’acteur remplir les champs du formulaire et valide.
8.le systéme retourne une réponse de sucées.
9.le cours est bien ajoutées.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

38
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Description du cas d’utilisation "Modifier Cours"

Tableau 3.5: Cas d’utilisation "Modifier Cours"

C.U Modifier Cours

Acteur Enseignant

Objectif Modifier un cours

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
3.l’acteur choisi l’option "Gestion des cours"
Scénario nominal
4.la liste des cours disponible sera affichée , l’acteur clique sur modifier.
5.Un formulaire sera ouvert contenant les coordonnées du cours séléctionnée.
6. l’acteur modifie les champs et valide

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

Description du cas d’utilisation "Supprimer Cours"

Tableau 3.6: Cas d’utilisation "Supprimer Cours"

C.U Supprimer Cours

Acteur Enseignant

Objectif Supprimer un Cours

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
Scénario nominal
3.l’acteur choisi l’option "Gestion des cours"
4.la liste des cours disponible sera affichée, une bouton de suppression est dispo.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

39
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Description du cas d’utilisation "Affecter Classe"

Tableau 3.7: Cas d’utilisation "Affecter Classe"

C.U Affecter Classe

Acteur Administrateur de scolarité

Objectif Affecter Classe

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
Scénario nominal 3.l’acteur choisi l’option "Affecter Classe"
4.un formulaire a remplir sera affichée.
5.l’acteur remplit le formulaire et valide.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

Description du cas d’utilisation "Visualiser les absences"

Tableau 3.8: Cas d’utilisation "Visualiser les absences"

C.U Visualiser les absences

Acteur Etudiant

Objectif Visualiser les absences

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
Scénario nominal
3.l’acteur choisi l’option "Absences"
4.Une page qui contient les absences de cette acteur sera ouvert.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

40
Chapitre 3. Sprint 1 : Les fonctionnalités de base

3.3 Conception
Pour la conception du sprint 1 nous avons utilisées deux diagrammes d’UML à savoir dia-
gramme de class et le diagramme de séquences afin d’exprimer la solution proposée

3.3.1 Diagramme de classe détaillé du premier sprint

Figure 3.4: Diagramme de classe détaillé du premier sprint

41
Chapitre 3. Sprint 1 : Les fonctionnalités de base

3.3.2 Diagramme de séquence détaillé du premier sprint

Description de séquence "Ajouter Enseignant"

Figure 3.5: Diagramme de Séquence "Ajouter Enseignant"

42
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Description de séquence "Ajouter Cours"

Figure 3.6: Diagramme de Séquence "Ajouter Cours"

Description de séquence "Affecter Classe"

Figure 3.7: Diagramme de Séquence "Affecter Classe"

43
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Description de séquence "Modifier Enseignant"

Figure 3.8: Diagramme de Séquence "Modifier Enseignant"

Description de séquence "Modifier Cours"

Figure 3.9: Diagramme de Séquence "Modifier Cours"

44
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Description de séquence "Visualiser Absences"

Figure 3.10: Diagramme de Séquence "Visualiser Absences"

Description de séquence "Supprimer Cours"

Figure 3.11: Diagramme de Séquence "Supprimer Cours"

45
Chapitre 3. Sprint 1 : Les fonctionnalités de base

3.4 Réalisation du Sprint 1


3.4.1 Dashboard

Une fois l’utilisateur s’authentifie avec succès ,la page de dashboard sera affiché comme cette
figure l’indique .Il lui donne l’accès a des différents fonctionnalités a titre d’exemple : Etudiants
, Enseignants, Cours,...

Figure 3.12: Diagramme de Séquence "Supprimer Cours"

3.4.2 Gestion des enseignants

Liste Enseignant :
Pour pouvoir afficher la liste des enseignants disponible, on doit accéder a l’option Enseignant
. Par la suite une liste sera affiché dans laquelle elle se trouve toute les enseignants ainsi que
les différents traitement qu’un utilisateur peut faire comme l’ajout d’un nouvel enseignant, la
modification des informations personnelles existante ou bien la suppression d’un enseignant.

46
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Figure 3.13: Réalisation "Liste Enseignant"

Ajouter Enseignant :
Pour ajouter un enseignant il faut remplir le formulaire suivant :

Figure 3.14: Réalisation "Ajouter Enseignant"

47
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Modifier Enseignant :
Pour modifier un enseignant il faut changer le formulaire suivant :

Figure 3.15: Réalisation "Modifier Enseignant"

3.4.3 Gestion Etudiant :

Ajouter Etudiant :
Pour ajouter un etudiant il faut remplir le formulaire suivant :

Figure 3.16: Réalisation "Ajouter Etudiant"

48
Chapitre 3. Sprint 1 : Les fonctionnalités de base

3.4.4 Gestion Emploi du temps

L’emploi du temps est apparu comme la figure ci-dessous.

Figure 3.17: Réalisation "Emploi du temps"

3.4.5 Gestion Absences

Ajouter Absence Pour l’ajout des absences , on doit remplir le formulaire suivant :

Figure 3.18: Réalisation "Ajouter Absence"

49
Chapitre 3. Sprint 1 : Les fonctionnalités de base

Conclusion
Au terme de ce chapitre, nous avons présenté les fonctionnalités de base pour la réalisation
de notre systéme d’information, ainsi que la conception et la partie de réalisation de chacun de
ces tache. l’accumulation de notre projet fera l’objet du dernier chapitre.

50
Chapitre 4

Les fonctionnalités avancées

Plan
1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 55

3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Chapitre 4. Les fonctionnalités avancées

Introduction
Dans ce chapitre, nous allons présenter notre deuxiéme sprint. A l’issue de ce dernier nous
allons obtenu une deuxiéme version de notre application. Nous étudions en premier temps la
spécification fonctionnelle puis la conception détaillée et on va clóturer par le test.

4.1 Backlog du sprint 2


Le deuxiéme backlog sprint comporte ces modules :

Figure 4.1: Backlog Sprint 2

De meme , Le tableau ci-dessous représente la planification détaillée du sprint 2.

52
Chapitre 4. Les fonctionnalités avancées

ID Fonctionnalité Taches Priorité Durée(Jours)


-En tant que
Etudiant je
peux consulter
et télécharger
mes cours de
n’importe quel
3 Authentification navigateur. 2 7
-En tant que
Enseignant je
peux
m’authentifier
pour accéder a
mon compte.
-En tant que
Ressource
humaine je peux
m’authentifier
pour accéder a
mon compte.
-En tant que
Administrateur
je peux
m’authentifier
pour accéder a
mon compte.
-En tant que
Etudiant je
peux consulter
mon emploi du
temps de
n’importe que
6 Inscription navigateur. 2 5

53
Chapitre 4. Les fonctionnalités avancées

ID Fonctionnalité Taches Priorité Durée(Jours)


-En tant que
Etudiant je
peux consulter
mon emploi du
temps de
n’importe que
6 Inscription navigateur. 2 5
-En tant que
Ressource
humaine je peux
faire
l’inscription de
mes étudiants.
-En tant que
Ressource
humaine je peux
notifier les
enseignants
d’une réunion,
d’un
Gestion des changement
7 notifications d’emploi,. . . 2 7
-En tant que
Enseignant je
peux consulter
la notification
envoyé par la
ressource
humaine.

54
Chapitre 4. Les fonctionnalités avancées

ID Fonctionnalité Taches Priorité Durée(Jours)


-En tant que
Administrateur
je peux ajouter
et supprimer
6 Inscription une notification. 2 7

4.2 Spécification des besoins


4.2.1 Identification des acteurs

Ce sprint comporte deux acteurs. Le tableau ci-dessous représente la classification des ac-
teurs selon le cas d’utilisation du sprint 2.

55
Chapitre 4. Les fonctionnalités avancées

Figure 4.2: Backlog Sprint 2

4.2.2 Diagramme de cas d’utilisation détaillé du deuxiéme sprint

56
Chapitre 4. Les fonctionnalités avancées

Figure 4.3: Backlog Sprint 2

Description du cas d’utilisation "S’authentifier"

Tableau 4.1: Cas d’utilisation "S’authentifier"

C.U S’authentifier

Acteur Enseignant

Objectif L’authentification

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
Scénario nominal
3.l’acteur choisi l’option "Gestion des cours"
4.la liste des cours disponible sera affichée, une bouton de suppression est dispo.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

57
Chapitre 4. Les fonctionnalités avancées

Description du cas d’utilisation "S’inscrire"

Tableau 4.2: Cas d’utilisation "S’inscrire"

C.U S’inscrire

Acteur Etudiant

Objectif L’inscription l’école

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
Scénario nominal 3.l’acteur choisi l’option "Inscription"
4.Un formulaire dans ce sens sera affichée.
5.L’acteur rempli le formulaire et valide.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

58
Chapitre 4. Les fonctionnalités avancées

Description du cas d’utilisation "Visualiser les notifications"

Tableau 4.3: Cas d’utilisation "Visualiser les notifications"

C.U Visulaiser les notifications

Acteur Enseignant

Objectif La visualisation des différents notifications(changement d’emploi , réunion,..)

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
Scénario nominal
3.l’acteur choisi l’option "Notifications"
4.l’acteur trouve tous les alerts envoyées par la ressource humaine.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

59
Chapitre 4. Les fonctionnalités avancées

Description du cas d’utilisation "Gérer les notifications"

Tableau 4.4: Cas d’utilisation "Gérer les notifications"

C.U Gérer les notifications

Acteur Ressource humaine

Objectif Envoyé des notifications

1.L’acteur saisit son adresse et son mot de passe.


2.Une fois les champs sont validées , le compte sera ouvert
3.l’acteur choisi l’option "Gérer les Notifications"
Scénario nominal
4.Un formulaire dans ce sens sera ouvert pour que l’acteur écrit l’objet du
notification et son corps et a qui sera envoyé et valide.
5.La notification sera envoyé.

Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.

Pré Condition Authentification validées.

Post Condition Déconnexion

60
Chapitre 4. Les fonctionnalités avancées

4.3 Conception
Pour la conception du sprint 2 nous avons utilisées deux diagrammes d’UML, a savoir
diagramme de classe et le diagramme de séquence afin d’exprimer la solution proposée.

4.3.1 Digramme de classe détaillé du deuxiéme sprint

Figure 4.4: Diagramme de classe du deuxiéme sprint

4.3.2 Diagramme de séquence détaillé du deuxiéme sprint

Description de séquence "S’authentifier"

61
Chapitre 4. Les fonctionnalités avancées

Figure 4.5: Diagramme de Séquence "S’authentifier"

Description de séquence "S’inscrire"

62
Chapitre 4. Les fonctionnalités avancées

Figure 4.6: Diagramme de Séquence "S’inscrire"

4.3.3 Diagramme d’activité détaillé du deuxiéme sprint

Description d’activité "S’authentifier"

Figure 4.7: Diagramme d’activité "S’authentifier"

63
Chapitre 4. Les fonctionnalités avancées

Description d’activité "S’inscrire"

Figure 4.8: Diagramme d’activité "S’inscrire"

4.4 Réalisation
4.4.1 Authentification

Pour la réalisation du projet , nous avons créer dans un premier lieu , une interface de login
avec un bouton pour le sign-up , permettant à un utilisateur de créer un compte . Par defaut , un
utilisateur qui cree un compte va prendre le role (Etudiant , Enseignant , Admin ou ressources
humaines) Pour s’authentifier l’utilisateur doit tout d’abord s’authentifier à travers un login et
un mot de passe qui doivent etre conforme à ceux au niveau de la base de donnée générés aprés
la création du compte et selon le token générée l’utilisateur sera affecté à son propre compte
et en cas du saisie incorrecte un message d’erreur est affiché comme il est indiqué au figure au
dessous.

64
Chapitre 4. Les fonctionnalités avancées

Figure 4.9: Réalisation "Page d’authentification"

Figure 4.10: Réalisation "S’authentifier"

suite à un saisie d’un login et un mot de passe incorrect un message d’erreur est affiché
Dans le cas où l’utilisateur n’a pas de compte , il doit créer un compte afin de s’authentifié
.Il est obligé d’entrer les champs obligatoire dont l’username et l’email n’ont pas été utilisés
précédemment .De plus , il doit respecter certains conditions de contrôle de saisie tel que la
format de mail , la longueur de mot de passe , ect.

65
Chapitre 4. Les fonctionnalités avancées

Figure 4.11: Réalisation "Création d’un compte"

4.4.2 Inscription

Cette figure est visualisées lorsque le choix de l’utilisateur, a porté sur le sous menu«Inscription»du
menu «Etudiants». Cet écran permet à l’administration de scolarité d’ajouter les informations
d’un nouvel étudiant.

66
Chapitre 4. Les fonctionnalités avancées

Figure 4.12: Réalisation "Inscription"

4.4.3 Gestion des notifications

Cette interface permet au ressource humaine d’envoyer une notification, ont sélectionnant
le destinataire et d’écrire le message à envoyer.

67
Chapitre 4. Les fonctionnalités avancées

Figure 4.13: Réalisation "Notification"

Conclusion
Durant ce dernier chapitre, nous avons présenté les différents focntionnalités avancées que
nous avons réalisée , leur conception et leur description textuelle ainsi que les tests du système
pour vérifier le bon fonctionnement de notre travail.

68
Conclusion générale

Ce rapport résume le travail réalisé lors d’un projet de stage d’été effectué au sein de
l’entreprise Horizon Data.
L’objectif principal de notre projet était la conception et le développement d’un systéme
d’information pour une école proffessionnel qui se souffre des divers problémes tel que la mani-
pulation de ces données avec Excel, mauvaise traitement , manque de rapidité , mal organisation
,... et d’autres encore.

Le point de départ de la réalisation de notre projet était une récolte d’informations né-
cessaires propre a l’entreprise pour dresser un état de l’existant, présenter un aperçu sur la
problématique ainsi que les besoins quand va traité dans l’établissement. Par la suite, nous
sommes intéressés à l’analyse des besoins qui nous a permis de distinguer les différents acteurs
interagissant avec l’application web visée. L’objectif de la partie suivante , c’est de organisé
le projet en des sprints et de ce développer les fonctionnalités sur chacun de ces sprints crée.
Enfin, pour la dernière phase de ce projet s’est focalisé sur la réalisation de l’application. Dans
ce sens, nous avons présenté les logiciels utilisés (Angular, SpringBoot, SQl, Postman ...).

Ce travail nous a été très enrichissant de point de vue des thèmes abordés et technologies
utilisées. Il a été l’occasion pour approfondir les connaissances et le savoir-faire acquis durant
les 2 années de ma formation à l’ISI. C’était une vraie opportunité pour apprendre à travailler,
s’adapter et s’intégrer dans un environnement professionnel au sein d’une grande société, ainsi
que se familiariser avec l’esprit du travail d’équipe et du partage.
Le système que nous avons conçu peut être utiliser pour d’autres école de formation proffe-
sionnel.

Le développement n’aura jamais de fin et le projet ne cessera de s’améliorer. Comme futures


perspectives, nous envisageons d’utiliser une application mobile similaire a l’application web
crée dont le but de faciliter son interaction avec l’utilisateur.Ainsi que au niveau de l’application
web créer , nous pouvons ajouter d’autres fonctionnalités comme la gestion des staff et des
formations et des évenements réalisé dans l’école

69
Bibliographie

[1] [En ligne]


Disponible sur : https://fr.hach.com/1200-s-sc-sonde-ph-numerique-pour-controleur-sc/
product?id=26371008313#note={[Visitéle02/06/2021]}

[2] [En ligne]


Disponible sur : http://techingenium.com.uy/ [Visité le 10/05/2021].

[3] [En ligne]


Disponible sur : http://dig2s.com/ [visité le 22/03/2021].

[4] [En ligne]


Disponible sur : https://fr.hach.com/module-d-affichage-sc1000-avec-ecran-tactile/
product?id=26370930081 [Visité le 04/05/2021].

[5] [En ligne]


Disponible sur : http://meteosat.pessac.free.fr/Cd_elect/Doc_pdf/liaison/loop420.pdf
[visité le 22/03/2021].

[6] [En ligne]


Disponible sur : https://www.lucidchart.com/pages/fr/langage-uml. [visité le 25/04/2021].

[7] [En ligne]


Disponible sur : https://www.xplenty.com/blog/the-sql-vs-nosql-difference/
#sqldbsystems

[8] [En ligne]


Disponible sur : https://nodejs.dev/learn [Visité le 20/05/2021].

[9] [En ligne]


Disponible sur : http://algo.tn/esp32/introduction/ [Visité le 3/06/2021].

[10] [En ligne]


Disponible sur : https://deepbluembedded.com/
esp32-adc-tutorial-read-analog-voltage-arduino/ [Visité le 05/05/2021].

[11] [En ligne]


Disponible sur : https://microcontrollerslab.com/ads1115-external-adc-with-esp32/ [Vi-
sité le 17/04/2021].

70
Bibliographie

[12] [En ligne]


Disponible sur : https://fr.rs-online.com/web/p/thermocouples/1747512/ [Visité le
15/05/2021].

[13] [En ligne]


Disponible sur : https://blog.webnet.fr/visual-studio-code/#:~:text=Visual [Visité le
15/06/2021].

[14] [En ligne]


Disponible sur : https://lacavernedelucan.com/
decouvrez-kicad-et-realisez-vos-pcb-comme-un-pro-de-lelectronique/ [Visité le
15/06/2021].

71
PÌl›
Ahn§z ¤ §¤ “ybW š® Ÿ› AžAyb˜ £@¡Horizn Dat a T•rJ ™ Š¤rKm˜ @¡ r§wWt Anm’ dq˜
Th ¤ š® Ÿ› ..., Ÿyml`m˜ , Ah®V ™• r§dž ¨t˜ Ÿyml`m˜ §Cd TFCdm˜ PO› AžAy ­dˆA’ ¨
db› Ÿ› db ¨t˜ ­dyJr˜ Tyhnm˜ ¤db , Š¤rKm˜ @¡ r§wW ¨ Anl˜¤ .Tylmˆ¤ TWys TykbJ
Tq§rV P± Ylˆ¤ , An’Ays˜ T›º®› r• £r§wW ™b’ tnm˜ ™›Ak˜ ¨lyOft˜ XyWt˜ ¤ Af} wm˜
..LMUT@mž TŒ˜ ‰› UML, SCRUM

T§¤ z˜ Atˆ , AA , LQR , w n§rbF : y Af› Aml•

Résumé
Ce projet consiste à développer un systéme d’information dans Horizon Data, destiné
a une école de formation proffesionnel dont laquelle nous avons gérer l’ensemble de ses
etudiants, enseignants, ... à travers une interface web simple et pratique. Pour bien mener
le développement de ce projet,la méthodologie agile qui part du principe de la spécification
et la planification dans les détails l’intégralité d’un produit avant de le développer, semble
plus adéquate à notre contexte, et plus particuliérement la méthode SCRUM, avec Le
langage de modélisation UML.

Mots clés : Spring Boot , SQL, Java, Angular Matériel

Abstract
This project consists in developing an information system in Horizon Data, intended for
a teacher training school of which we manage all of its students, teachers, ... through
a simple and practical web interface. In order to successfully develop this project, the
agile methodology that starts from the principle of specification and planning in detail
the entire product before developing it, seems more appropriate to our context, and more
particularly the SCRUM method, with the UML modeling language.

Keywords : Spring Boot , SQL, Java, Angular Hardware

isi@isim.rnu.tn : ¨ž¤rtk˜¯ d§rb˜ 71 706 698 :H•Af˜ 71 706 164 : Ah˜ TžA§C 2080 ¨ž¤CAb˜  A§r˜ w hž 2
2 Abou Raihane Bayrouni 2080 l’Ariana Tél: 71 706 164 Fax: 71 706 698 Email: isi@isim.rnu.tn
Bibliographie

Entreprise : Digi Smart Solutions


Adresse : Technoparks, innovation center Elgazella, 2088 , Tunisia
Tel : +216 93 170 183
Email : contact@dig2s.com

73

Vous aimerez peut-être aussi