Template Pfe Isi 2 [PDF]

Zitiervorschau

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

Architecture Utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.6.1

L’architecture réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.6.2

Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.6

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.4

2.3.1

Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.2

Besoins non Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

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 3.1

29

Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 iv

3.2

3.3

3.4

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

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

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

4.2

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

4.3

4.4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1

Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.2.2

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

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

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

2.7

logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.8

logo Modelio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.9

Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

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"

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

. . . . . . . . . . . . . . . . . . . . . 40

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 problè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éveloppement 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 : · ! [email protected] · ~ 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’université. — 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 affronté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 consacré 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 (contractuelles). 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’organisation 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 applicative 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èleVueContrô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’application 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 traitements 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 indispensable 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 globalement 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 beaucoup 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 fonctionnels 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 toutmobile. 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)

1

4

1

5

-En tant que Etudiant Consulter et Télécharger/Importer 1

Cours

je peux consulter et télécharger mes cours de n’importe quel navigateur. 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 2

Emploi

n’importe que navigateur. 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)

1

5

2

7

-En tant que Ressource Humaine je peux Ajouter ou bien Consulter 2

Emploi

Supprimer un emploi du temps -En tant que Etudiant je peux m’authentifier pour accéder a mon

3

Authentification

compte. -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)

2

10

1

4

-En tant que Etudiant je peux m’inscrit a n’importe 4

Inscription

quel moment. -En tant que Ressource humaine je peux faire l’inscription de mes étudiants. -En tant que Etudiant

Consulter les 5

absences

je peux consulter ma liste des absences. -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)

1

3

2

7

-En tant que Administrateur je peux affecter les étudiants à 6

Affecter Classe

leurs classes. -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

7

Gestion des

changement

notifications

d’emploi,. . . -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 considé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)

1

4

1

5

-En tant que Etudiant je peux consulter et télécharger Consulter et Télécharger/Importer 1

Cours

mes cours de n’importe quel navigateur. 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. -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)

1

5

1

4

-En tant que Ressource Humaine je peux Ajouter ou bien Supprimer un emploi du 2

Consulter Emploi

temps. -En tant que Etudiant je peux consulter ma liste des

5

Consulter les absences

absences. -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)

1

3

-En tant que Administrateur je peux affecter les étudiants à 6

Affecter Classe

leurs classes. -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.

Scénario nominal

5.l’acteur clique sur la bouton Ajouter Enseignant qui se trouve a coté du 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

Scénario nominal

3.l’acteur choisi l’option "Gestion des enseignants" et une liste sera affichée. 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

Scénario nominal

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 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

Scénario nominal

3.l’acteur choisi l’option "Gestion des cours" 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.

Scénario nominal

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, 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.

Scénario nominal

2.Une fois les champs sont validées , le compte sera ouvert 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 diagramme 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)

2

7

2

5

-En tant que Etudiant je peux consulter et télécharger mes cours de n’importe quel 3

Authentification

navigateur. -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. 53

Chapitre 4. Les fonctionnalités avancées ID

Fonctionnalité

Taches

Priorité

Durée(Jours)

2

5

2

7

-En tant que Etudiant je peux consulter mon emploi du temps de n’importe que 6

Inscription

navigateur. -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

7

Gestion des

changement

notifications

d’emploi,. . . -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)

2

7

-En tant que Administrateur je peux ajouter et supprimer 6

4.2

Inscription

une notification.

Spécification des besoins

4.2.1

Identification des acteurs

Ce sprint comporte deux acteurs. Le tableau ci-dessous représente la classification des acteurs 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.

Scénario nominal

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, 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.

Scénario nominal

2.Une fois les champs sont validées , le compte sera ouvert 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

Scénario nominal

3.l’acteur choisi l’option "Gérer les Notifications" 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 manipulation 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 proffesionnel. 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/ [Visité 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/ 15/06/2021].

71

[Visité

le

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 : yAf› 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

[email protected] : ¨ž¤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: [email protected]

Bibliographie Entreprise : Digi Smart Solutions Adresse : Technoparks, innovation center Elgazella, 2088 , Tunisia Tel : +216 93 170 183 Email : [email protected]

73