Explorer les Livres électroniques
Catégories
Explorer les Livres audio
Catégories
Explorer les Magazines
Catégories
Explorer les Documents
Catégories
Par
Sahar Mannai
Par
Sahar Mannai
Le
J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation.
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 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.
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
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
Conclusion générale 69
Bibliographie 70
v
Table des figures
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
vii
Liste des tableaux
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 ...),...
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.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.
Source: [3]
— Applications Mobiles.
3
Chapitre 1. Contexte général
— Consulting.
— TI Outsourcing.
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é.
— Contact :
· ! info@horizon-data.tn
· ~ http://www.horizon-data.tn/
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]
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.
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.
6
Chapitre 1. Contexte général
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 :
— SCRUM
— Crystal
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 :
7
Chapitre 1. Contexte général
— 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.
— 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.
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 :
8
Chapitre 1. Contexte général
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 de données :Ce dernier possède le moteur de stockage de données pour répondre
aux requêtes du client. [12]
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 :
— 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.
10
Chapitre 1. Contexte général
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
Plan
1 Les roles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Environnement de développement . . . . . . . . . . . . . . . . . . . 16
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.
— 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.
— 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...
14
Chapitre 2. Analyse et Spécification des besoins
15
Chapitre 2. Analyse et Spécification des besoins
— 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.
— 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.
16
Chapitre 2. Analyse et Spécification des besoins
-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]
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 :
-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]
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]
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
19
Chapitre 2. Analyse et Spécification des besoins
20
Chapitre 2. Analyse et Spécification des besoins
21
Chapitre 2. Analyse et Spécification des besoins
22
Chapitre 2. Analyse et Spécification des besoins
23
Chapitre 2. Analyse et Spécification des besoins
24
Chapitre 2. Analyse et Spécification des besoins
25
Chapitre 2. Analyse et Spécification des besoins
26
Chapitre 2. Analyse et Spécification des besoins
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
Plan
1 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
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.
30
Chapitre 3. Sprint 1 : Les fonctionnalités de base
31
Chapitre 3. Sprint 1 : Les fonctionnalités de base
32
Chapitre 3. Sprint 1 : Les fonctionnalités de base
33
Chapitre 3. Sprint 1 : Les fonctionnalités de base
34
Chapitre 3. Sprint 1 : Les fonctionnalités de base
35
Chapitre 3. Sprint 1 : Les fonctionnalités de base
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
36
Chapitre 3. Sprint 1 : Les fonctionnalités de base
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
37
Chapitre 3. Sprint 1 : Les fonctionnalités de base
Acteur Enseignant
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
38
Chapitre 3. Sprint 1 : Les fonctionnalités de base
Acteur Enseignant
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
Acteur Enseignant
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
39
Chapitre 3. Sprint 1 : Les fonctionnalités de base
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
Acteur Etudiant
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
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
41
Chapitre 3. Sprint 1 : Les fonctionnalités de base
42
Chapitre 3. Sprint 1 : Les fonctionnalités de base
43
Chapitre 3. Sprint 1 : Les fonctionnalités de base
44
Chapitre 3. Sprint 1 : Les fonctionnalités de base
45
Chapitre 3. Sprint 1 : Les fonctionnalités de base
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,...
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
Ajouter Enseignant :
Pour ajouter un enseignant il faut remplir le formulaire suivant :
47
Chapitre 3. Sprint 1 : Les fonctionnalités de base
Modifier Enseignant :
Pour modifier un enseignant il faut changer le formulaire suivant :
Ajouter Etudiant :
Pour ajouter un etudiant il faut remplir le formulaire suivant :
48
Chapitre 3. Sprint 1 : Les fonctionnalités de base
Ajouter Absence Pour l’ajout des absences , on doit remplir le formulaire suivant :
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
Plan
1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
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.
52
Chapitre 4. Les fonctionnalités avancées
53
Chapitre 4. Les fonctionnalités avancées
54
Chapitre 4. Les fonctionnalités avancées
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
56
Chapitre 4. Les fonctionnalités avancées
C.U S’authentifier
Acteur Enseignant
Objectif L’authentification
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
57
Chapitre 4. Les fonctionnalités avancées
C.U S’inscrire
Acteur Etudiant
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
58
Chapitre 4. Les fonctionnalités avancées
Acteur Enseignant
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
59
Chapitre 4. Les fonctionnalités avancées
Scénario alternatif Si les champs ne sont pas valides, le systéme affiche un message d’erreur.
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.
61
Chapitre 4. Les fonctionnalités avancées
62
Chapitre 4. Les fonctionnalités avancées
63
Chapitre 4. Les fonctionnalités avancées
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
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
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
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
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.
69
Bibliographie
70
Bibliographie
71
PÌl
Ahn§z¤ §¤ ybW ® AAyb £@¡Horizn Dat a TrJ ¤rKm @¡ r§wWt Anm dq
Th ¤ ® ..., yml`m , Ah®V r§d ¨t yml`m §Cd TFCdm PO AAy dA ¨
db db ¨t dyJr Tyhnm ¤db , ¤rKm @¡ r§wW ¨ Anl¤ .Tylm¤ TWys TykbJ
Tq§rV P± Yl¤ , AnAys Tº® r £r§wW b tnm Ak ¨lyOft XyWt ¤ Af} wm
..LMUT@m T UML, SCRUM
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.
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.
isi@isim.rnu.tn : ¨¤rtk¯ d§rb 71 706 698 :HAf 71 706 164 :Ah TA§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
73