DE STAGE DE FIN D’ETUDES

MEMOIRE

DE STAGE DE FIN D’ETUDES Pour l’obtention du

«Mastère professionnel en Nouvelles Technologies des

Télécommunications et Réseaux (N2TR)»

Présenté par :

Kaouther Elbedoui

Titre Conception et Réalisation d’une Application de suivi

de déroulement d’une formation à l’Université virtuelle de Tunis

Soutenu le : 07 Décembre 2018

Devant le jury :

Président : Mme. Rim CHERIF

Encadreur : Mr. Ezzeddine BEN BRAEIK

Rapporteur : Mme. Imen AMMARI

Membre : Mr. Oussama LIMAM

Année Universitaire : 2017 / 2018

Dédicaces

Je dédie ce travail À

L’âme de mon père Hédi,

Ma très chère mère Jamila,

Ma très chère sœur Moufida,

Mes frères Mohamed Ali, Saadedine, Adnen

Mes neveux et nièces,

Tou(te)s mes ami(e)s, et

Tous les gens qui m'aiment......

(Kaouther Elbedoui)

3

Remerciements En tout premier lieu, je remercie Dieu, le tout puissant de m’avoir

donné la force et l’audace pour dépasser les difficultés et réaliser ce

travail.

Je tiens à remercier tous ceux qui m’ont aidé à réaliser ce travail

notamment mon encadreur, Monsieur Ezzeddine BEN BRAEIK pour

son encouragement, ses directives, ses remarques constructives, et sa

disponibilité.

J’aimerais aussi montrer ma gratitude à mon encadreur au sein de

l’Université Virtuelle de Tunis Monsieur Oussama LIMAM, pour sa

coopération et collaboration en tant que chef du projet sur lequel ce

travail a été effectué.

Un grand merci à tous les personnels de L’Université Virtuelle de

Tunis, administration et professeurs pour les moyens qu’ils ont mis à

notre disposition, leurs encouragements continus et pour leurs aides

précieuses.

Enfin Je tiens également à remercier les membres du jury pour

avoir accepté d’évaluer ce travail et assister à cette soutenance.

4

TABLE DES MATIÈRES

Dédicaces ...............................................................................................................................2

Remerciements .......................................................................................................................3

Liste des figures .....................................................................................................................8

Liste des tableaux ................................................................................................................. 10

Liste des abréviations ........................................................................................................... 11

Introduction Générale ........................................................................................................... 12

Chapitre 1 : Cadre général du projet...................................................................................... 14

Introduction .......................................................................................................................... 15

1.1. Présentation de l’organisme d’accueil ........................................................................ 15

1.1.1 Les formations à distance de l’université virtuelle de Tunis ............................. 15

1.1.2 Organigramme ................................................................................................ 17

1.1.3 Infrastructure technique ................................................................................... 19

a. Les centres d’accès ............................................................................................. 19

b. Les centres de visioconférence ............................................................................ 19

c. Le laboratoire de production numérique .............................................................. 19

d. Le studio audio-visuel ......................................................................................... 19

e. L'hébergement .................................................................................................... 19

1.2. Contexte général ........................................................................................................ 20

1.2.1. Étude de l’existant ................................................................................................. 21

1.2.2. Critique de l’existant ............................................................................................. 21

1.2.3. Solutions proposées ............................................................................................... 21

1.3. L’état de l'art .............................................................................................................. 22

1.3.1. Définition du e-Learning : ................................................................................... 22

1.3.2. Les points forts du e-Learning ............................................................................. 22

1.3.3. Les points faibles du e-Learning : ....................................................................... 23

5

1.4. Méthodologie de gestion de projet adoptée .................................................................... 24

1.4.1. Présentation de la Méthodologie Scrum .................................................................. 24

1.4.2. Rôles de la Méthode Scrum .................................................................................... 25

1.5. Méthodologie d’analyse et de conception ................................................................... 26

1.5.1. Environnement du travail .................................................................................... 26

1.5.1.1. Environnement matériel ................................................................................... 26

1.5.1.2. Environnement logiciel .................................................................................... 26

Conclusion ........................................................................................................................... 29

Chapitre 2 : Planification et architecture ............................................................................... 30

Introduction .......................................................................................................................... 31

2.1. Capture et analyse des besoins ...................................................................................... 31

2.1.1. Identification des acteurs ..................................................................................... 31

2.1.2. Expression des besoins fonctionnels et non fonctionnels ..................................... 32

2.1.2.1. Spécification des besoins fonctionnels ......................................................... 32

2.1.2.2. Spécification des besoins non fonctionnels ................................................... 32

2.1.3. Diagramme de cas d’utilisation globale ............................................................... 33

2.1.4. Schémas de navigation ........................................................................................ 34

2.2. Découpage du projet .................................................................................................. 35

2.2.1. Diagramme de paquetage .................................................................................... 35

2.2.2. L’équipe Scrum du projet .................................................................................... 36

2.3. Conception architecturale ........................................................................................... 36

2.3.1. Conception de l’architecture Logique .................................................................. 36

2.3.2. Conception de l’architecture Physique ................................................................ 37

Conclusion ........................................................................................................................... 38

Chapitre 3 : Gestion des formations ...................................................................................... 39

Introduction .......................................................................................................................... 40

3.1. Backlog du sprint « gestion des formations » ............................................................ 40

6

3.2. Expression des besoins............................................................................................... 42

3.2.1. Diagramme des cas d’utilisations ........................................................................ 42

3.2.2. Les descriptions textuelles du premier Sprint ...................................................... 46

3.3. Analyse et Conception ............................................................................................... 51

3.3.1. Les diagrammes des séquence du premier sprint ................................................. 51

3.3.2. Les diagrammes de classe du premier sprint ........................................................ 52

3.4. Implémentations ........................................................................................................ 53

3.4.1 Génération des tables de la base de données ........................................................ 53

3.4.2 Les Interfaces finales .......................................................................................... 56

3.5. Test ............................................................................................................................ 61

Conclusion ........................................................................................................................... 61

Chapitre 4 : Gestion des invitations des enseignants.............................................................. 62

Introduction .......................................................................................................................... 63

4.1. Backlog du sprint « gestion des invitations des enseignants » .................................... 63


4.2.1. Diagramme des cas d’utilisations ........................................................................ 64

4.2.2. Les descriptions textuelles du troisième Sprint .................................................... 65


4.3.1. Les diagrammes de séquence du deuxième sprint ................................................ 67

4.3.2. Le diagramme de classe du troisième sprint ....................................................... 69


4.4.1. Génération des tables de la base de données ........................................................ 70

4.4.2. Les Interfaces finales .......................................................................................... 72

4.5. Test ............................................................................................................................ 75

Conclusion ........................................................................................................................... 76

Chapitre 5 : Gestion des enseignants ..................................................................................... 77

Introduction .......................................................................................................................... 78

7

5.1. Backlog du sprint « gestion des enseignants » ........................................................... 78


5.2.1 Diagrammes des cas d’utilisations ....................................................................... 79

5.2.2 Les descriptions textuelles du troisième Sprint .................................................... 81


5.3.1. Les diagrammes de séquence du troisième sprint ................................................ 86

5.3.2 Le diagramme de classe du troisième sprint ....................................................... 89


5.4.1. Génération des tables de la base de données ........................................................ 89

5.4.2. Les Interfaces finales .......................................................................................... 91

5.5. Test ............................................................................................................................ 95

Conclusion ........................................................................................................................... 96

Conclusion générale ............................................................................................................. 97

8

Liste des figures

Figure 1 Organigramme de l’UVT2 ...................................................................................... 18

Figure 2 Schématisation de processus de la méthodologie..................................................... 25

Figure 3 Diagramme de cas d’utilisation global .................................................................... 33

Figure 4 Schéma de navigation ............................................................................................ 34

Figure 5 Diagramme de package ........................................................................................... 35

Figure 6 L’équipe Scrum du projet ....................................................................................... 36

Figure 7 Modèle MVC ......................................................................................................... 37

Figure 8 Architecture 3-tiers ................................................................................................. 38

Figure 9 Diagramme de cas d’utilisation raffiné « Gérer une formation» ............................. 42

Figure 10 Diagramme de cas d’utilisation raffiné « Gérer calendrier» .................................. 43

Figure 11 Diagramme de cas d’utilisation raffiné « Gérer l’année universitaire» ................... 44

Figure 12 Diagramme de cas d’utilisation raffiné « Gérer calendrier pédagogique» ............. 45

Figure 13 Diagramme de cas d’utilisation raffiné « Gérer calendrier d’étude et réservation». 46

Figure 14 Diagramme de séquence détaillée de l’Item « lister les invitations » ................... 51

Figure 15 Diagramme de séquence détaillée de l’Item «envoyer invitation» ......................... 52

Figure 16 Diagramme de classe de conception de deuxième sprint ....................................... 53

Figure 17 Modèle relationnelle de la base de données « gestion formation » ......................... 54

Figure 18 Modèle relationnel de la base de données « gestion calendrier » ........................... 55

Figure 19 Interface d’authentification ................................................................................... 56

Figure 20 Interface liste des formations ................................................................................ 56

Figure 21 Interface « ajouter une formation » ..................................................................... 57

Figure 22 Interface qui affiche détailles d’une formation ...................................................... 57

Figure 23: Interface gestion des unités .................................................................................. 58

Figure 24 Interface définition des périodes d’un semestre ..................................................... 58

Figure 25 Interface définir période ........................................................................................ 59

Figure 26 Interface gestion calendrier ................................................................................... 59

Figure 27 Interface gestion calendrier d’étude...................................................................... 60

Figure 28 Interface gestion calendrier ................................................................................... 60

Figure 29 Interface test ajout d’une nouvelle formation ....................................................... 61

Figure 30 Test d’intégration de nouvelle formation dans la liste des formations ................... 61

Figure 31 Diagramme de cas d’utilisation raffiné « Gérer invitation » .................................. 64

9

Figure 32 Diagramme de séquence détaillée de l’Item «lister invitations» ............................ 68

Figure 33 Diagramme de séquence détaillée de l’Item «envoyer une invitation» ................... 69

Figure 34 Diagramme de classes de la conception de deuxième sprint .................................. 70

Figure 35 Modèle relationnel de la Base de Données Sprint 2 ............................................... 72

Figure 36 Interface invitation coordinateur ........................................................................... 73

Figure 37 Liste des invitations enseignants ........................................................................... 73

Figure 38 annulation invitation ............................................................................................. 74

Figure 39 invitation tutorat ................................................................................................... 74

Figure 40 Test d’envoi invitation coordinateur ..................................................................... 75

Figure 41 Test invitation reçue par le coordinateur .............................................................. 75

Figure 42 Test liste invitation coordinateur envoyée ........................................................... 76

Figure 43 Diagramme de cas d’utilisation raffiné « Gérer enseignant» .................................. 79

Figure 44 « Gérer CV en langue française ».......................................................................... 80

Figure 45« Gérer CV en langue arabe » ................................................................................ 80

Figure 46 Diagramme de séquence détaillée de l’Item «Ajouter grade» ................................ 87

Figure 47 Description de séquence détaillée de l’Item «Ajouter travaux» ............................. 88

Figure 48 Diagramme de classe de conception de dernier sprint............................................ 89

Figure 49 Modèle relationnel de la base de données « formation des enseignants » ............... 90

Figure 50 Modèle relationnel de la base de données « informations enseignants » ............... 91

Figure 51 Interface d’accueil gestion des enseignants. .......................................................... 91

Figure 52 Interface gestion « CV enseignant » ...................................................................... 92

Figure 53 Interface « gestion informations professionnelles enseignant » en langue arabe .... 92

Figure 54 Interface « déposer le dossier administratif »........................................................ 93

Figure 55 Interface mon compte pour l’enseignant............................................................... 93

Figure 56 Interface gestion CV enseignant en langue arabe................................................... 94

Figure 57 interface ajout grade enseignant ............................................................................ 94

Figure 58 test d’ajout enseignant......................................................................................... 95

Figure 59 test authentification de l’enseignant ajouté ........................................................... 95

Figure 60 test d’intégration d’un nouvel enseignant ajouté à la liste des personnes.............. 96

10

Liste des tableaux

Tableau 1 Backlog du sprint « gestion des formations » ....................................................... 41

Tableau 2 Description textuelle du diagramme « Gérer une formation » ............................... 47

Tableau 3 Description textuelle du diagramme« Gérer calendrier»........................................ 47

Tableau 4 Description textuelle du diagramme « gérer calendrier universitaire» .................. 48

Tableau 5 Description textuelle du diagramme « gérer calendrier pédagogique » ................. 49

Tableau 6 Description textuelle du diagramme« Gérer calendrier d’étude » ......................... 50

Tableau 7 Backlog du sprint « gestion des invitations enseignants » .................................... 63

Tableau 8 Description textuelle du diagramme « gérer invitation » ....................................... 65

Tableau 9 Description textuelle du diagramme « Gérer invitation coordinateur» ................... 66

Tableau 10 Description textuelle du diagramme « gérer invitation tuteur » ........................... 67

Tableau 11 Backlog du sprint « gestion des enseignants ».................................................... 78

Tableau 12 Description textuelle du diagramme « gérer enseignant » .................................. 81

Tableau 13 Description textuelle du diagramme « gérer CV »............................................... 82

Tableau 14 Description textuelle du diagramme « gérer information personnelle » ............... 83

Tableau 15 Description textuelle du diagramme « Gérer informations enseignants

en langue arabe » .................................................................................................................. 85

11

Liste des abréviations

UVT : Université Virtuelle de Tunis

ECU : Élément constitutif d’une unité d’enseignement

UE : Une unité d’enseignement

CV : Curriculum Vitae

MVC : Modèle, Vue, Contrôleur

HTML : Hyper Text Markup Langage

12

Introduction Générale

≠

Les systèmes d’informatiques ont pris de plus en plus d’importance dans notre société.

Pour satisfaire au mieux les besoins et les intérêts des clients, les administrateurs doivent

pouvoir offrir, au meilleur prix, des services d’excellente qualité.

Les ≠entreprises, ≠en ≠particulier, ≠nécessitent ≠des ≠logiciels ≠sophistiqués, ≠considérés

aussi l’un ≠des ≠piliers ≠de ≠leur ≠bon ≠fonctionnement. ≠C’est ≠pourquoi, ≠on ≠donne

aujourd’hui une très ≠grande ≠importance ≠aux ≠méthodes ≠de ≠développement ≠d’un ≠logiciel

qui allègent le travail ≠des ≠développeurs ≠et ≠garantissent ≠un ≠logiciel ≠satisfaisant ≠tous ≠les

besoins attendus par ≠l’entreprise.

Le ≠présent ≠projet s’inscrit dans le cadre d’un stage de fin d’études de mastère

professionnel en nouvelles technologies de télécommunications et des réseaux. Il se ≠doit

offrir, ≠dans ≠ce monde ≠où ≠la ≠science ≠de l’informatique évolue ≠très ≠rapidement, un

service ≠assez ≠raffiné et ≠adéquat ≠répondant particulièrement aux ≠exigences ≠de

l’université pour ≠améliorer et faire évoluer ≠leurs conditions ≠de ≠travail. ≠Dans le ≠cadre

de ≠cette ≠évolutivité, ≠il ≠nous a ≠été ≠proposé ≠de ≠développer une application

informatique qui gère ≠le suivi d’une formation en ligne au sein de l’UVT qui est la seule

université à l’échelle nationale qui assure des programmes de formation à distance.

Le présent rapport est organisé en cinq chapitres :

o Le premier chapitre intitulé «Cadre général du projet» présente l’organisme d’accueil,

décrit le contexte de notre projet, l’état de l’art ainsi que la méthodologie de gestion

du projet adoptée et comme dernier point l’environnement du travail.

o Le deuxième chapitre «Planification et architecture» explique notre démarche, soit,

l’identification des futurs acteurs de notre système et l’analyse des besoins. Et aussi la

description de l’architecture choisie pour réaliser notre solution.

13

o Le troisième chapitre « Gestion des formations » comporte la première partie de notre

projet défini en se basant sur la méthodologie Scrum. Nous présentons tout au long de

ce chapitre la spécification, la conception et la réalisation de ce premier sprint.

o Le quatrième chapitre « Gestion des invitations des enseignants » est dédié à la

réalisation de ce deuxième sprint tous en se basant sur la méthodologie Scrum.

o Le cinquième chapitre « Gestion des enseignants » est dédié à la réalisation du dernier

sprint tout en adoptant la même méthodologie du premier et deuxième sprint.

Le rapport sera clôturé par une conclusion générale.

14

Chapitre 1 : Cadre général

du projet

15

Introduction

Dans ce premier chapitre réservé à l’exposé du cadre général du projet, nous présentons, en

premier lieu, l’organisme d’accueil à savoir l’Université Virtuelle de Tunis, ensuite nous

allons passer à la problématique du projet et nous mettons en évidence la solution proposée.

En troisième lieu, nous définissons l’état de l’art, les concepts clés, les principales notions de

base associées au domaine du e-Learning, et qui spécifient la formation à l’UVT. Enfin nous

terminons par la méthodologie de gestion de projet adoptée et celle d’analyse et de

conception choisie.

1.1. Présentation de l’organisme d’accueil

L’Université Virtuelle de Tunis (UVT) est un établissement public, créé en janvier 2002.

L’UVT dispense à ses étudiants des programmes de formation en ligne et à distance. Ces

programmes de formation sont professionnalisant, innovants et adaptés aux besoins de

l'environnement économique, social, national et international.

L’UVT a une deuxième principale mission qui consiste à développer l’enseignement en ligne

dans les universités tunisiennes.

1.1.1 Les formations à distance de l’université virtuelle de Tunis

Des formations de mastères :

o Mastère Professionnel co-construit en Science des Données & Mobiquité

"MPSDM",

o Mastère Professionnel co-construit en Ingénierie Des Applications Web-

Nuagiques "MPWIN",

o Mastère Professionnel en Nouvelles Technologies des Télécommunications et

Réseaux "N2TR",

o Mastère Professionnel en Management Intégré : Qualité - Sécurité -

Environnement, "MPQSE",

o Mastère Professionnel en Optimisation et Modernisation de l’Entreprise

"MOME",

o Mastère Professionnel en Logiciels Libres "MP2L",

o Mastère Professionnel en Préparation Physique "MP3"

16

o Mastère Professionnel en Préparation Mentale "M2P2"

o Mastère Professionnel en Neuroradiologie et Neuro-imagerie Diagnostique

"MP2ND",

o Mastère de Recherche en Gestion durable et Valorisation des Ressources

Animales "VAGDRA"

Des formations en licences :

o Licence Appliquée en Management "LAM" (L1, L2, L3),

o Licence Appliquée en Sciences et Techniques de l'Information et de

Communications "LASTIC" (L3),

o Licence Appliquée en Marketing Electronique et Stratégies Numériques

"LAMESN" (L3),

o Licence Fondamentale en Gestion Comptable "LGC" (L3)

o Licence Fondamentale en Electronics and Optics e-Learning for Embedded

Systems "EOLES" (L3) (enseignée en anglais)

Des formations continues :

o En informatique et internet (formation de préparation à la certification C2i)

o En anglais (Ongoing Training in English "OTE")

o En technologies informatiques (Business Analytics, et Big Data, Informatique

mobile, Cyber sécurité, Cloud Computing, Web 2.0, etc.).

Des certifications :

o Certificat Informatique et Internet "C2i"

o Certification TOEFL

o Certification académique IBM 1

1 https://www.uvt.rnu.tn/l-universite/presentation

17

1.1.2 Organigramme

L'UVT est un établissement public, relevant du Ministère de l'Enseignement Supérieur et

de la Recherche Scientifique.

En plus du corps administratif, L'UVT dispose d'un réseau d'enseignants intervenant

comme coordinateurs, directeurs de département d'enseignement virtuel, correspondants et

tuteurs.

L'Institut Supérieur de l'Éducation et de la Formation Continue (ISEFC) est le seul

établissement universitaire relevant de l'UVT.

Figure 1 Organigramme de l’UVT22

2 https://www.uvt.rnu.tn/l-universite/organigramme

19

1.1.3 Infrastructure technique

a. Les centres d’accès

L’UVT met à la disposition des étudiants et des enseignants des centres d’accès installés

dans les établissements d’enseignement supérieur. Ces centres permettent aux étudiants

d’accéder aux contenus en ligne et d’assurer les regroupements présentiels. Chaque centre se

compose de 20 ordinateurs (Windows, Linux), 2 mini-serveurs (Linux), câblage réseau,

climatisations et éléments de bureau.

b. Les centres de visioconférence

La visioconférence est un service assurant en temps réel le transfert bidirectionnel, du son

et de l’image animée en couleur permettant ainsi à un groupe d’usagers de dialoguer tout en

occupant deux ou plusieurs lieux distincts. À cet effet, l’UVT vient d’acquérir des systèmes

de visioconférence

c. Le laboratoire de production numérique

L’UVT dispose d'un laboratoire de numérisation et de production des cours. Les

techniciens de ce laboratoire assistent les enseignants dans la numérisation de leurs cours.

d. Le studio audio-visuel

L’Université Virtuelle de Tunis vient d’installer dans ses locaux un studio professionnel de

tournage/montage pour l’enregistrement de séquences vidéo de cours animés par les

enseignants.

De même l’UVT envisage d’acquérir une solution complète de streaming incluant des

softwares adéquats, des serveurs...

e. L'hébergement

L’UVT possède un parc d’hébergement de serveurs, contenant les sites web de l’université,

les plates-formes d’enseignement à distance, les ressources pédagogiques, les applications

web. Le réseau de l’UVT est sécurisé contre les menaces de nature interne et externe.

L’UVT s’est dotée d’une solution complète de sécurité basée sur la technique des Coupe-Feu

(Firewalls redondants, sondes réseaux, antivirus, filtres) et étoffée par d’autres fonctionnalités

réparties sur l’ensemble des équipements du réseau.

20

La juxtaposition de l’ensemble de ces produits permet d’établir un ensemble de lois, de

règles et de mécanismes capables de gérer, de protéger et d’optimiser les ressources

disponibles au sein de l’université. 3

1.2. Contexte général

L’amélioration de la qualité de services est un défi qu’on cherche à atteindre. Afin d’y

parvenir, il est primordial de proposer de nouvelles technologies d’information set de

communications afin d’améliorer, d’une part le fonctionnement et la visibilité et d’autre part

garantir un bon service.

Sur le terrain de l'enseignement distanciel, tout est encore nouveau et il convient de

vérifier de manière permanente si le dispositif proposé est bien approprié au public

d'apprenants.

L’enseignement à distance n’est pas de même nature que l’enseignement en présence. Il

demande la mise en place de moyens spécifiques et suppose le développement de

compétences particulières de la part de tous les intervenants principalement les enseignants et

l’équipe administrative. Si par le passé la communication passait essentiellement par voie

postale, le développement et la généralisation des technologies de l’information et de la

communication ont profondément changé la situation. Pour mettre en place un service et une

gestion d’une formation à distance, les universités doivent mettre en place une infrastructure

technique et une organisation spécifiques.

C’est pour cette raison qu’il paraît cohérent de rendre compte à une numérisation de

l’aspect pédagogique d’une formation afin de suivre son bon déroulement et élaborer une

stratégie de gouvernance.

Dans ce contexte et dans le cadre de notre formation de master professionnel en nouvelles

technologies des télécommunications et réseaux à l’université virtuelle de Tunis et pour

mettre en application nos connaissances acquises et améliorer nos compétences, nous sommes

appelés à réaliser un projet de fin d’études au sein de L’UVT qui m’a offert l’opportunité de

concevoir et réaliser une application adéquate du suivi du déroulement de la formation

spécifique en ligne, distincte de celle de l’enseignement présentiel, afin de garantir son bon

déroulement.

3 https://www.uvt.rnu.tn/l-universite/infrastructure-technique

21

1.2.1. Étude de l’existant

Cette partie consiste à comprendre et analyser les solutions existantes pour déterminer

leurs points faibles pour pouvoir dégager les besoins du projet, et de les prendre en

considération lors de la conception et la réalisation de notre projet.

Dans ce cadre nous avons fait une analyse critique de quelques solutions. Afin de pouvoir

en améliorer la productivité, il est indispensable de déterminer des outils pertinents adaptés

aux besoins de l’université, de bien communiquer sur les modules du projet à venir et de gérer

efficacement les propositions du modèle de la gestion d’une formation. Cette démarche ne

peut être efficace que si chaque acteur intervenant à la gestion de la formation se sente

concerner et reste réactif.

1.2.2. Critique de l’existant

Avant d’entamer l’étude proprement dite de la solution, il est indispensable de prendre du

recul et de faire un résumé des problèmes concrets existants que rencontrent au jour le jour

nos différents acteurs.

Il convient de souligner que le système de gestion et de suivi de la formation à l’UVT

présente un certain nombre de difficultés. Notons néanmoins que ces difficultés ne peuvent

être réglées d’une manière définitive qu’à travers une refonte du système classique existant.

Les principales insuffisances et limites du système actuel de gouvernance de la formation

reviennent à l’inexistence d’une application spécifique et moderne qui assure le suivi du bon

déroulement de la formation en ligne. Ce ci implique la nécessite d’instaurer une solution

adéquate assurant le suivi dans le cadre du respect de la charte du tutorat et du calendrier

pédagogique.

1.2.3. Solutions proposées

22

La gestion administrative des formations à l’UVT est soumise à des réglementations

strictes et à une organisation basée sur les documents en papier et les dossiers qui s'entassent

et aboutissent à une défaillance d’organisation comme la perte des dossiers, le non respect de

délais, la non arrivée des infos aux destinataires …

Afin de remédier aux défaillances citées précédemment de cette démarche classique, nous

avons proposé de développer une application informatique de gestion de suivis de la

formation à l’UVT dont l'objectif premier est d’assurer un suivi du bon déroulement de la

formation, comme valeur ajoutée, nous citons le gain de temps et d énergie.

Le présent projet contient principalement un volet pédagogique relatif à l’habilitation de la

formation et comportant plusieurs parties, détaillées comme suit :

L’enseignement : (volume horaire, plans des cours, évaluation des activités …)

Le calendrier pédagogique

L’enseignant

La plateforme d’enseignement ou dossier e-learning : (pédagogie en ligne,

activités, calendrier d’enseignement en ligne, évaluation en ligne…)

1.3. L’état de l'art

1.3.1. Définition du e-Learning :

La formation en ligne, l'e-formation ou encore l'e-Learning, présente l'ensemble des

moyens permettant l'apprentissage par des moyens électroniques. La formation en ligne

introduit de cette manière des sites web éducatifs, la téléformation, l'enseignement

télématique, ou encore notamment des technologies de l'information et de la communication

pour l'éducation .

Plusieurs termes sont utilisés pour traduire le mot e-Learning. La traduction la plus proche

est l'apprentissage en ligne.

1.3.2. Les points forts du e-Learning

Le e-Learning présente plusieurs avantages dont la formation traditionnelle ne propose

pas. Le e-Learning :

https://fr.wikipedia.org/wiki/Apprentissage

https://fr.wikipedia.org/wiki/Technologies_de_l%27information_et_de_la_communication_pour_l%27%C3%A9ducation



23

Est un mode de suivi en asynchrone ou en synchrone : traditionnellement, le e-

Learning est plutôt asynchrone. Ce qui veut dire qu’il n’y a pas d’heure prédéfinie à

laquelle les apprenants doivent suivre le module. Chacun peut le suivre quand il le veut, à

son rythme. L’apprenant prend son temps pour assimiler les concepts.

À une portée mondiale. Si les modules e-Learning sont hébergés sur le web, les

personnes du monde entier peuvent y accéder. Il est Inutile de prévoir des coûts de

déplacement ou d’organiser des réunions à distance sur plusieurs fuseaux horaires.

S’étend à plusieurs types d’appareils : les modules en ligne peuvent être lus sur un

ordinateur aussi sur des appareils mobiles, tels que les Smartphones ou les tablettes. Ce

qui veut dire que les modules e-Learning peuvent également être aux portées des personnes

qui en ont besoin, à tout moment.

Est disponible au moment où on a besoin : de nos jours, les outils auteurs sont

tellement faciles à utiliser qu’il est possible de créer, et de partager un module en l’espace

de quelques heures. Vous pouvez donc fournir à vos apprenants les formations qu’il leur

faut au moment où ils en ont besoin.

Est plus efficace : vous pouvez créer un module e-Learning et le partager facilement

avec des milliers d’apprenants au lieu d’organiser des sessions de formations en présentiel

à chaque fois qu’on a besoin.

Réduit les coûts : les facteurs ci-dessus assurent des réelles économies lorsque l’on

remplace certaines formations en présentiel par des modules e-Learning.

Assure la qualité et la cohérence du contenu : avec un module e-learning, vous êtes

sûr que les apprenants auront accès au même contenu. Dans la formation traditionnelle, le

contenu et les conditions de la formation peuvent varier en fonction du formateur, du jour,

etc. Ces différences peuvent avoir une influence sur l’apprentissage.4

1.3.3. Les points faibles du e-Learning :

Bien que le E-Learning soit très intéressant, il présente quelques désavantages cités

comme suit :

4 http://blogs.articulate.com/les-essentiels-du-elearning/questce-le-e-learning/

24

La diffusion de cours e-Learning nécessite des équipements multimédias.

L’accès à l’outil informatique est nécessaire et une connexion Internet est aussi

indispensable.

L’e-Learning limite les interactions en face-to-face entre les individus.

Le suivi des enseignants-tuteurs et des apprenants est très limité.

1.4. Méthodologie de gestion de projet adoptée

Dans le cadre de notre projet et afin d’assurer le bon déroulement des différentes phases de

ce dernier, nous avons opté pour la méthode agile Scrum pour la conception et le

développement de notre système pour des raisons bien déterminées en effet ce processus

s’adapte parfaitement à la décomposition du notre projet et satisfait au mieux notre besoins.

1.4.1. Présentation de la Méthodologie Scrum

« Scrum est un cadre de développement dans lequel des équipes réalisent des produits de

manière itérative. Cette méthodologie structure le développement sous forme des cycles de

travail appelés Sprints. Ces itérations sont d’une durée de quatre semaines au maximum et se

trouvent l’une après l’autre sans interruption. Les Sprints sont d’une durée limitée, ils se

terminent à une date bien déterminée, que le travail soit terminés ou non, et ne sont jamais

prolongés.

Dans la plupart des cas, les équipes Scrum choisissent une durée de Sprint et la maintiennent

toutes au long du projet, jusqu’à ce qu’elles puissent augmenter leur productivité et utiliser

alors un cycle plus court. Au début de chaque Sprint, une équipe plurifonctionnelle

sélectionne des éléments qui exigent le client dans une liste priorisée. L’équipe s’accorde

collectivement sur une cible constituée de ce qu’elle pense pouvoir livrer à la fin du Sprint , de

manière concrète.

Tout au long du Sprint aucun nouvel élément n’est ajouté ; Scrum accepte le changement

pour le Sprint suivant, mais la durée fixe d’un Sprint en cours est faite pour se focaliser sur un

objectif relativement stable. Tous les jours, l’Équipe se réunit brièvement afin de contrôler la

progression du projet et organiser les prochaines étapes nécessaires à la finalisation du travail

restant. À la fin de chaque Sprint, une revue est planifiée avec les parties prenantes durant

laquelle l’équipe montre ce qu’elle a réalisé. Le feedback obtenu peut être pris en compte sur

le Sprint suivant. Scrum insiste sur la nécessité de concevoir un produit opérationnel à la fin

de chaque Sprint, et réellement «terminé». Dans le cas de développement des logiciels, cela

25

signifie un système intégré, testé, et documenté pour ses utilisateurs. Les rôles, les artefacts et

les événements clés sont présentés dans la figure 2» 5

Figure 2 Schématisation de processus de la méthodologie

Scrum 6

1.4.2. Rôles de la Méthode Scrum

Scrum assure trois rôles dans le but d’optimiser la souplesse et la productivité : le Product

Owner, l’Équipe, et le Scrum Master.

Le Product Owner qui porte la vision du produit à accomplir et travaille en répercussion

avec l’équipe de développement. Il interagit fréquemment avec l’équipe, collabore avec

l’ensemble des parties prenantes et passe en revue les résultats de chaque Sprint, au lieu de

mandater les décisions jointes au développement à un chef de projet.

L’Équipe (également appelée Équipe de Développement) assure le produit qui est défini

par le Product Owner. L’équipe décide des éléments à implémenter dans un Sprint, et des

moyens correspondants pour atteindre cet objectif.

5 http://scrumprimer.org/primers/fr_scrumprimer20.pdf

6 https://www.c-sharpcorner.com/article/scrum-framework-5-events-in-scrum-framework/

26

Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est bien appliqué. Il

a donc un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de

développement. Il doit donc faire preuve de pédagogie.

1.5. Méthodologie d’analyse et de conception

Durant la phase d’analyse, on cherche à bien comprendre et décrire convenablement les

besoins des clients. On l’appelle «phase d’analyse des besoins». Après la compréhension du

besoin de client, nous cherchons la solution. C’est l’analyse de la solution.

Après validation de la phase précédente nous nous entamons la phase de conception, on

apporte plus de détails à la solution et on clarifie les aspects techniques. Afin de réaliser ces

deux phases dans notre projet, nous avons utilisé des méthodes, des conventions et des

notations.

UML est une des notations les plus utilisées de nos jours. C’est un langage de modélisation

utilisé pour fournir une méthode normalisée pour exprimer les attentes du client en

pictogrammes qui visualise la conception du système.

1.5.1. Environnement du travail

1.5.1.1. Environnement matériel

Pour réaliser l’application on va utiliser un ordinateur portable Packard Bell caractérisé de :

Système d’exploitation : Windows 7

o Processeur : Dual Core

o Mémoire : 3G RAM

o Disque dur : 250 GO

1.5.1.2. Environnement logiciel

Tout au long de la phase de développement, nous allons utiliser l’environnement logiciel

suivant :

MySQL Workbench

27

MySQL server est un système de gestion de bases de données relationnelles. Ce dernier

intègre le serveur de base de données ainsi un logiciel de gestion et d’administration appelé

MySQL Workbench créé depuis 2004. Il permet via une interface graphique intuitive de créer,

modifier ou supprimer des tables, des comptes utilisateurs, et d'effectuer tout est les

opérations inhérentes à la gestion d'une base de données.

XAMPP Server

XAMPP Server est une plateforme de développement Web permettant de faire fonctionner

localement (sans se connecter à un serveur externe) des scripts PHP et Perl. XAMPP Server

n'est pas en soi un logiciel, mais un environnement comprenant plusieurs serveurs Apache,

MySQL, PERL, Filezilla, Mercury et Tomcat.

PhpMyAdmin (PMA)

Cette interface pratique permet d'exécuter, facilement et sans grandes connaissances en

bases de données, des requêtes comme les créations de table de données, insertions, mises à

jour, suppressions et modifications de structure de la base de données, ainsi que l'attribution et

la révocation de droits et l'import/export. Ce système permet de sauvegarder commodément

une base de données sous forme de fichier SQL et d'y transférer ses données, même sans

connaître SQL.7

PhpStorm

7 https://fr.wikipedia.org/wiki/PhpMyAdmin

28

Est un éditeur intelligent pour PHP, HTML et possède des caractéristiques distingués par

rapport au autres IDE : une coloration syntaxique, affichage des erreurs à la volée, auto-

complétion intelligente du code. Bootstrap qui est une collection d'outils utiles à la création du

design (de sites et d'applications web.

Bootstrap (Framework)

Bootstrap est une collection d'outils utile à la création du design (graphisme, animation et

interactions avec la page dans le navigateur ... etc. ...) de sites et d'applications web. C'est un

ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation

et autres éléments interactifs, ainsi que des extensions JavaScript en option.

AJAX

L'architecture informatique ajax (acronyme d'asynchronous JavaScript and XML : JavaScript

et XML asynchrones) permet de construire des applications Web et des sites web dynamiques

interactifs sur le poste client en se servant de différentes technologies ajoutées aux navigateurs

web entre 1995 et 2005.Ajax combine JavaScript, les requêtes de type XML http Request, les

manipulations du DOM, ainsi qu'un format de données (XML ou JSON), afin d'améliorer

d'utilisation des applications internet riches8

Zend Framework (ZF)

8 https://fr.wikipedia.org/wiki/Ajax_(informatique)

https://fr.wikipedia.org/wiki/Framework

https://fr.wikipedia.org/wiki/Site_web

https://fr.wikipedia.org/wiki/Application_web

https://fr.wikipedia.org/wiki/HTML

https://fr.wikipedia.org/wiki/Cascading_Style_Sheet

https://fr.wikipedia.org/wiki/JavaScript

29

ZF est un Framework d'applications Web open source, orienté objet, implémenté dans PHP 7

et concédé sous licence selon la nouvelle licence BSD. Le Framework est essentiellement une

collection de packages professionnels basés sur PHP. Zend Framework fournit aux utilisateurs

un support du Model View Controller (MVC) en combinaison avec la solution Front

Controller. La mise en œuvre de MVC dans Zend Framework comporte cinq domaines

principaux. Le routeur et le répartiteur ont pour fonction de choisir le contrôleur à exécuter en

fonction des données de l'URL, et les fonctions du contrôleur en combinaison avec le modèle

et la vue pour développer et créer la page Web finale.9

Conclusion

Dans ce chapitre, nous avons mis notre projet dans son cadre général. Nous avons ainsi décrit

l’organisme d’accueil, présenté l’état de l’art. L’état de l’existant nous a menés à faire

quelques critiques et proposer des solutions que nous allons développer dans les prochains

chapitres.

9 https://framework.zend.com/manual/1.11/fr/learning.quickstart.intro.html

30

Chapitre 2 : Planification et

architecture

31

Introduction

La réussite de tout projet dépend de la qualité de l’étape de spécification qui constitue la base

de départ de notre travail. Ce chapitre consiste à fournir une description détaillée du

fonctionnement du système afin d’analyser, comprendre et déterminer les différents besoins

de notre future application. Ce chapitre est organisé comme suit : la première section est

dédiée pour l’analyse des différents besoins fonctionnels et non fonctionnels. La deuxième

section est réservée à la planification architecturale des trois sprints de l’application.

2.1. Capture et analyse des besoins

2.1.1. Identification des acteurs

Un acteur est une personne ou un système qui interagit avec le système en échangeant des

informations en entrée comme en sortie. Le diagramme de cas d’utilisation d’UML distingue

deux acteurs à savoir :

• Les acteurs principaux (qui modifient l’état du système ou qui consultent cet état)

• Les acteurs secondaires (acteurs auxquels le système fait appel pour répondre aux

sollicitations d’un acteur principal)

Dans notre projet, nous avons dénoncé :

• Un acteur principal (Administrateur) : Il possède les droits administratifs qui lui

permettent de contrôler tout le système de suivis de formation et d’accéder à l’interface

d’administration de l’application et donner et contrôler les accès.

• Des acteurs secondaires :

- Le coordinateur

- Le tuteur

32

2.1.2. Expression des besoins fonctionnels et non fonctionnels

2.1.2.1. Spécification des besoins fonctionnels

Les besoins fonctionnels sont ceux qui doivent répondre aux exigences du futur système en

termes de fonctionnalités. Ils permettent de générer les cas d’utilisation. Pour notre

application les besoins recensés sont principalement comme suit :

Gestion des formations

Gestion du calendrier universitaire

Gestion du calendrier pédagogique

Gestion de la plateforme pédagogique (pédagogie en ligne, activité, calendrier d’enseignement

en ligne, évaluation en ligne…)

Gestion des invitations des enseignants

Gestion des enseignants (tuteurs et coordinateurs) qui comporte :

o La gestion du CV des enseignants

o La gestion des compétences des enseignants

o La gestion des diplômes des enseignants

o La gestion de formations assurées par les enseignants

o La gestion des travaux des enseignants

2.1.2.2. Spécification des besoins non fonctionnels

≠Les ≠besoins ≠non ≠fonctionnels ≠représentent ≠les ≠exigences ≠implicites ≠auquel ≠le

≠système ≠répondre. ≠Dans ≠notre cas, ≠l’application ≠doit ≠répondre ≠aux ≠exigences

≠suivantes

Facilité ≠d’utilisation ≠:≠ l’application doit avoir des interfaces simples à

utiliser et ergonomiques c’est à dire un ≠non ≠informaticien ≠doit ≠pouvoir ≠utiliser

l’application ≠sans difficulté.≠

Fiabilité ≠:≠l’application ≠doit ≠fonctionner ≠de ≠façon ≠cohérente ≠sans

≠erreurs.

La sécurité : l’accès à notre solution doit être en mode sécurisé.

Ergonomie≠:≠l’application ≠doit ≠être ≠adaptée ≠à ≠l’utilisateur ≠sans ≠qu’il

≠fournisse ≠trop d’effort. ≠

Efficacité ≠:≠l’application ≠doit ≠permettre ≠l’accomplissement ≠de ≠la ≠tâche

≠avec ≠le minimum ≠de ≠manipulations.

33

2.1.3. Diagramme de cas d’utilisation globale

La figure ci-dessous représente le diagramme de cas d’utilisation générale de l’application

Figure 3 Diagramme de cas d’utilisation global

2.1.4. Schémas de navigation

Figure 4 Schéma de navigation

35

2.2. Découpage du projet

La conduite du tout projet se base sur un découpage en précisant

Les fonctionnalités qu’on va réaliser (les packages du produit)

Par qui vont être réalisées (Ressources : l’équipe scrum)

2.2.1. Diagramme de paquetage

Les besoins fonctionnels de notre application, sont modélisés par un diagramme de

paquetages. Ce diagramme reflète les fonctionnalités. Son élaboration s’est basée sur une

décomposition des fonctionnalités en paquet.

Figure 5 Diagramme de package

36

2.2.2. L’équipe Scrum du projet

Après l’identification des besoins fonctionnels de l’application dans un diagramme de

package, nous présentons à ce niveau l’équipe scrum qui va travailler sur ce projet. Les rôles

seront répartis comme les montre la figure suivante.

Figure 6 L’équipe Scrum du projet

2.3. Conception architecturale

2.3.1. Conception de l’architecture Logique

Architecture MVC : dans notre projet nous avons utilisé le modèle MVC (Modèle, Vue,

Contrôleur) qui décrit une application informatique par une séparation en trois sous-parties.

Ce modèle permet de bien organiser le code en le regroupant sur trois parties :

La partie Modèle : C’est dans cette couche qu’on trouve tous les données. Elle définit

aussi l’interaction avec la base de données. Dans une programmation orientée objet,

les données vont être manipulées sous forme de classe.

La partie Vue : Les données sont envoyées, par le modèle, à la vue qui les présente à

l’utilisateur. Cette couche n’effectue aucun traitement juste un simple affichage des

données viennent du modèle.

La partie contrôleur : Le contrôleur s’occupe de la gestion des événements de

synchronisation. Il récupère les informations et il les traiter selon des paramètres

demandés par l’utilisateur

37

Figure 7 Modèle MVC10

Les avantages apportés par cette architecture logique sont :

o Les données de la vue et du contrôleur sont séparées (ce qui donne une

conception claire et efficace de l'application)

o Les données de l'affichage et des actions sont en indépendance (ce qui donne

plus de souplesse pour le maintien et la mise à jour du système).

o Un gain de temps de maintenance et d'évolution de l'application.

2.3.2. Conception de l’architecture Physique

Le développement d’une application présente plusieurs types d’architectures tels que l’architecture

client/serveur qui présente deux niveaux (2 tiers) et celle 3 tiers.

Alors vu les spécifications de notre application qui exige le passage d’une base de données, le

choix du passage par l’architecture (3 tiers) s’impose.

10 https://www.softwaretestingmaterial.com/software-architecture/

38

Figure 8 Architecture 3-tiers11

Conclusion

L’expression des besoins assure une vision claire du projet et une compréhension plus

profonde des tâches à réaliser. L’analyse nous a permis de représenter l’architecture de nos

sprints. Dans les chapitres qui suivent, nous abordons l’analyse, la conception et la réalisation

de chaque sprint.

11

https://www.softwaretestingmaterial.com/software-architecture/

39

Chapitre 3 : Gestion des

formations

40

Introduction

Il est primordial de définir le but de chaque sprint avant d’entamer son développement. Le

but de ce dernier est de développer un espace professionnel et administratif qui permet de

gérer les formations et qui englobe principalement, la gestion des unités éducatives des

formations ainsi que la gestion des calendriers globales du déroulement des formations.

Nous allons analyser les cas d’utilisations avec une description des scénarios de

déroulement de chaque histoire, une conception du module, et on achève par la

programmation et le test.

3.1. Backlog du sprint « gestion des formations »

Le Backlog Product est le point d’entrée du projet, est destiné à recueillir tous les besoins

du client que l’équipe projet 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. Tous les éléments inclus dans le backlog scrum sont classés

par priorité indiquant l’ordre de leur réalisation.12

Il présente une liste priorisée des besoins de développement de l’application. Il est définit

par des colonnes chacune possède une désignation.

En tant que : Acteur intervenant pour assurer la fonctionnalité décrite.

Je veux et afin que : décrivent un besoin à développer pour l’utilisateur afin

d’atteindre le but.

Thème : Nous regroupons les fonctionnalités qui convergent sou un même thème.

Priorité : La technique utilisée afin de prioriser nos scénarios est Moscow dont :

o M pour Must Have : L’exigence est très importante. le projet échoue en cas de non

réalisation de cette dernière. Donc elle possède une priorité haute.

o S pour Should Have : Il s’agit d’une exigence importante, qu’il faut faire dans la

mesure du possible. Mais elle n’a pas d’effet sur le fonctionnement de l’application.

o C pour Could Have : C’est une exigence souhaitable. Elle n’a pas d’impact sur

d’autres tâches.

o W pour Won’t Have C’est une exigence «Luxe». Elle ne va pas être faite cette fois

mais plus tard, à garder pour la prochaine version vue qu’elle est intéressante.

12 https://www.nutcache.com/fr/blog/quest-ce-quun-backlog-scrum/

41

Le backlog du sprint1 est illustré dans le tableau suivant:

Tableau 1 Backlog du sprint « gestion des formations »

ID

Thème

En Tant que

Je veux

Afin que

Priorité

1

Formation

Administrateur

Ajouter une

formation

Assurer un bon suivi de

cette formation

M

2

Habilitation

Administrateur

Ajouter les unités

d’enseignements de cette formation

Constituer le dossier

pédagogique de la formation

M

4

Habilitation

Administrateur

Ajouter les ECUE

de chaque unité

d’enseignement de cette formation

Saisir le contenu de la

formation selon

l’habilitation

M

5

Calendrier

Administrateur

Ajouter un semestre

Gérer année universitaire

M

6

Calendrier

Administrateur

Ajouter les périodes

d’un semestre

Gérer semestre

M

7

Calendrier

Administrateur

Ajouter une année

universitaire

Gérer le calendrier

universitaire

S

8

Calendrier

Coordinateur

Ajouter un

événement


universitaire

M

9

Calendrier

Tuteur

Réserver les dates


pédagogique

S

10

Calendrier

Tuteur

Réserver les dates


d’étude et réservation

S

42

3.2. Expression des besoins

3.2.1. Diagramme des cas d’utilisations

Figure 9 Diagramme de cas d’utilisation raffiné « Gérer une formation»

43

Figure 10 Diagramme de cas d’utilisation raffiné « Gérer calendrier»

44

Figure 11 Diagramme de cas d’utilisation raffiné « Gérer l’année universitaire»

45

Figure 12 Diagramme de cas d’utilisation raffiné « Gérer calendrier pédagogique»

46

Figure 13 Diagramme de cas d’utilisation raffiné « Gérer calendrier d’étude et

réservation»

3.2.2. Les descriptions textuelles du premier Sprint

Le premier sprint du projet rassemble principalement :

L’édition d’un modèle de formation : à ce niveau l’administrateur a la main de consulter

modifier d’ajouter ou aussi d’éditer la formation entière qu’il a besoin (licence, mastère,

formation continue)

L’édition des calendriers de déroulement de l’année universitaire, calendrier pédagogique et

calendrier des études et réservation.

Nous allons par la suite décrire globalement l’interaction entre les acteurs et le système aussi

nous allons analyser la chronologie des actions qui devront être accomplies.

47

Description textuelle du diagramme « Gérer formation »

Tableau 2 Description textuelle du diagramme « Gérer une formation »

Cas d'utilisation: Gérer une formation

Résumé: Ce diagramme décrit l’ensemble de fonctionnalités réalisées par l’administrateur

pour :

o Éditer les formations

o Éditer les UE/ECUE

o Gérer les calendriers (calendrier de l’année universitaire, calendrier

pédagogique et calendrier des études et réservation)

Acteur(s): Administrateur

Pré-condition: Accès à l’application (Authentification).

Scénario principal:

o Le système affiche la page d’accueil de l’application qui inclut la liste des formations,

o L’administrateur, sélectionne le type de formation (licence, mastère, formation

continue) à éditer ou il ajoute une nouvelle formation s’il a besoin.

o Le système affiche l’ensemble des données selon la formation sélectionné.

o L’administrateur remplit les informations nécessaires des différents champs (titre,

description, domaine…) et clique sur le bouton « Ajouter ». Si non sur le bouton

enregistrer s’il va modifier une formation existante.

o Le système enregistre la nouvelle formation éditée ou bien les modifications

apportées pour une des formations existantes.

o Le système affiche la nouvelle liste des formations.

Post-condition : la nouvelle formation est ajoutée ou modifiée.

Description textuelle du diagramme « Gérer calendrier»

Tableau 3 Description textuelle du diagramme« Gérer calendrier»

Cas d'utilisation: Gérer calendrier

Résumé: Ce diagramme raffiné décrit l’ensemble de fonctionnalités réalisées par

l’administrateur le tuteur, et le coordinateur pour éditer les trois calendriers cités comme suit

:

o calendrier de l’année universitaire

o calendrier pédagogique

48

o calendrier des études et réservation

Acteur(s): Administrateur, Coordinateur, Tuteur



1. Le système affiche la page d’accueil de l’application qui inclut la liste des formations,

2. L’administrateur s’accède à l’interface pour définir une nouvelle année universitaire.

3. L’administrateur ajoute ou modifie les périodes de chaque semestre constituant l’année

universitaire d’une formation.

4. Le système enregistre les périodes ajoutées

5. À ce niveau le coordinateur s’occupe de fixer et réserver toutes les dates des événements

(démarrage de formation, regroupement, Ds, examen.. délibération des résultats. ) pour

chaque période.

6. Par contre le tuteur s’intéresse au planning des modules à la réservation des dates des Ds ;

pour chaque période.

Post-condition : calendriers (universitaire, pédagogique, et d’étude et réservation) planifiés

Description textuelle du diagramme « Gérer l’année universitaire»

Tableau 4 Description textuelle du diagramme « gérer calendrier

universitaire»

Cas d'utilisation: Gérer l’année universitaire

Résumé: Ce diagramme raffiné décrit l’ensemble de fonctionnalités réalisées par

l’administrateur pour définir l’année universitaire et qui sont principalement :

o L’ajout de l’année universitaire

o L’ajout d’un semestre

o L’ajout d’une période

o La définition des calendriers

Acteur(s): Administrateur



1. Le système affiche la page d’accueil de l’application qui inclut la liste des formations à

49

travers la quelle on va éditer une nouvelle année universitaire

2. L’administrateur valide l’ajout d’une année universitaire.

3. Les semestres sont générés dans la base automatiquement.

4. Une fois l’année est ajoutée , aussi les semestres l’administrateur, va par la suite éditer les

périodes de cette année .

5. L’administrateur clique sur un bouton qui affiche un formulaire « définir période »

6. L’administrateur remplit les informations nécessaires des différents formulaires et clique

sur le bouton « Ajouter ». Si non sur le bouton enregistrer s’il va modifier une date

existante.

7. Le système enregistre la nouvelle période éditée ou bien des modifications apportées pour

une existante.

8. Le système affiche la formation avec les périodes ajoutées constituant chaque semestre.

Post-condition : calendrier universitaire ajouté ou modifié.

Diagramme de cas d’utilisation raffiné « Gérer calendrier pédagogique »

Tableau 5 Description textuelle du diagramme « gérer calendrier pédagogique »

Cas d'utilisation: Gérer calendrier pédagogique

Résumé: Ce diagramme raffiné décrit l’ensemble de fonctionnalités réalisées par le

coordinateur pour éditer le calendrier pédagogique et qui sont comme suit :

o Gestion des dates de regroupement

o Gestion des dates des DS

o Gestion des dates des événements pour chaque période

Acteur(s):Coordinateur



1. Le système affiche la page d’accueil de l’application qui inclut la liste des formations

2. Le coordinateur accède à l’interface dédié à l’édition du calendrier en cliquant sur un bouton «

calendrier » situé pour chaque formation.

3. Le système affiche une vue qui liste les semestres composant chaque formation.

50

4. Le coordinateur sélectionne un semestre.

5. Le système affiche une vue qui rassemble les calendriers à éditer.

6. Le coordinateur clique sur un bouton « ajouter un événement ».

7. Le système affiche un formulaire qui contient les informations nécessaires des différents

champs pour un événement (type, titre, date, description, heure…)

8. Le coordinateur clique sur le bouton « Ajouter ». Si non sur le bouton enregistre s’il va

modifier un événement existant.

9. Le système affiche la liste des événements ajoutés dans le calendrier pédagogique approprié.

Post-condition : calendrier pédagogique édité.

Diagramme de cas d’utilisation raffiné « Gérer calendrier d’étude et

réservation»

Tableau 6 Description textuelle du diagramme« Gérer calendrier d’étude »

Cas d'utilisation : Gérer calendrier d’étude et réservation

Résumé: Ce diagramme raffiné décrit l’ensemble de fonctionnalités réalisées par l’administrateur le

tuteur, et le coordinateur pour éditer le calendrier d’étude et réservation et qui sont comme suit :

o Gestion des dates des DS

o Réservation des dates

o Gestion des plannings du module

Acteur(s): Coordinateur, Tuteur



1. Le système affiche la page d’accueil de l’application qui inclut la liste des formations

2. Le tuteur s’accède à la formation sélectionné dont il fait partie du tutorat des modules qui la

constitue.

3. Le système affiche une vue qui liste les semestres composant chaque formation.

4. Le tuteur sélectionne le module qui lui concerne.

5. Le système affiche l’interface

6. Le tuteur s’accède à l’interface dédié à l’édition du calendrier d’étude qui correspond au

module à tutorer en cliquant sur un bouton « calendrier d’étude » situé dans chaque ECUE

d’une unité pour chaque formation.

7. Le système affiche une vue qui rassemble les trois calendriers à éditer.

51

8. À ce niveau le tuteur va s’intéresser seulement au calendrier d’étude et de réservation

9. Le tuteur clique sur un bouton « ajouter un événement ».

10. Le système affiche un formulaire qui contient les informations nécessaires des différents

champs pour un événement (type, titre, date, description, heure…)

11. Le tuteur clique sur le bouton « Ajouter ». Si non sur le bouton enregistrer s’il va modifier

un événement existant.

12. Le système affiche la liste des événements ajoutés dans le calendrier d’étude approprié pour

un module bien déterminé .

Post-condition : calendrier d’étude et de réservation d’un module planifié ou modifié

3.3.Analyse et Conception

3.3.1. Les diagrammes des séquence du premier sprint

Le diagramme de séquence détaillée analyse l’interaction des acteurs intervenant dans les

fonctionnalités pour ce sprint avec la partie système en détail. Alors nous allons voir

l’interaction entre l’administrateur, le coordinateur, le tuteur et l’interface machine.

La figure 14 décrit la séquence des actions ayant lieu lorsque l’administrateur va consulter la

liste des invitations de tutorat ou de cordination envoyées

Figure 14 Diagramme de séquence détaillée de l’Item « lister les invitations »

52

La figure 15 décrit la séquence des actions ayant lieu lorsque l’administrateur ou le

coordinateur envoi une invitation de tutorat.

Figure 15 Diagramme de séquence détaillée de l’Item «envoyer invitation»

3.3.2. Les diagrammes de classe du premier sprint

53

Le diagramme de classes est considéré comme le plus important de la modélisation orientée

objet. Il montre la structure interne et il permet de fournir une représentation abstraite des

objets du système qui vont interagir pour réaliser les cas d'utilisation.

Figure 16 Diagramme de classe de conception de deuxième sprint

3.4. Implémentations

3.4.1 Génération des tables de la base de données

54

Le diagramme de classes présenté dans l’activité de conception de cette itération constitue

un modèle de passage pour le schéma de la base de données. Nous avons conçu une base de

données relationnelle, qui se compose des tables, rassemblées en deux modèles :

La figure 17 rassemble les tables de la base des données de la gestion des formations.

Figure 17 Modèle relationnelle de la base de données « gestion formation »

55

La figure 18 rassemble les tables de la base de données qui représente la gestion du

calendrier.

Figure 18 Modèle relationnel de la base de données « gestion calendrier »

56

3.4.2 Les Interfaces finales

Un exemple d’interfaces est représenté sur les figures suivantes :

En tant qu’utilisateur (administrateur ou enseignant) de cette application ou a recours à

s’authentifier à travers ce formulaire tout en introduisant une adresse mail et un mot de passe.

Figure 19 Interface d’authentification

Une fois authentifié l’administrateur accède à cette interface pour ajouter une formation ou

modifier une autre existante

Figure 20 Interface liste des formations

57

À travers cette interface, l’administrateur a la possibilité d’ajouter une nouvelle formation

(licence, mastère, formation continue).

Figure 21 Interface « ajouter une formation »

Une fois la formation est ajoutée l’administrateur est appelé à remplir le contenu de cette

formation à travers l’ajout des unités d’enseignements qui la constituent.

Figure 22 Interface qui affiche les détails d’une formation

58

Cette interface liste des ECU éditées par l’administrateur à travers l’interface précédente et

qui constituent le contenu pédagogique d’une formation.

Figure 23: Interface gestion des unités

À travers cette interface l’administrateur définit les périodes composant un semestre dans une

année universitaire bien déterminée.

Figure 24 Interface définition des périodes d’un semestre

59

Cette interface permet à l’administrateur d’ajouter ou modifier les périodes d’un semestre d’une année

universitaire.

Figure 25 Interface « définir période »

À travers cette interface le coordinateur procède a édité les calendriers d’une formation.

Figure 26 Interface gestion calendrier

60

À travers cette interface le tuteur procède pour éditer et gérer le calendrier d’étude pour un

ECUE d’une formation.

Figure 27 Interface gestion calendrier d’étude

En tant qu’enseignant (tuteur ou coordinateur) cette interface lui permet d’ajouter un

événement (démarrage de formation, regroupement, démarrage de période, activité, séance

chat, forum …) à son calendrier.

Figure 28 Interface gestion calendrier

61

3.5. Test

Nous présentons dans cette partie les tests d’acceptation que nous avons effectués pour

valider ce sprint.

Test d’ajout d’une nouvelle formation

Pour tester ce scénario, nous allons faire des captures sur le processus.

Figure 29 Interface test ajout d’une nouvelle formation

Figure 30 Test d’intégration de nouvelle formation dans la liste des formations

Conclusion

Dans ce chapitre, nous avons réussi à réaliser le module gestion des formations avec

l’analyse, la conception, l’implémentation et le test. Dans le chapitre qui suit, nous allons

entamer un nouveau sprint couvrant les fonctionnalités suivantes : «Gestion des invitations des

enseignants ».

62


invitations des enseignants

63

Introduction

Après avoir dévoilé notre premier sprint et atteindre ses objectifs, nous passons au

deuxième sprint qui correspond à la gestion des invitations des enseignants. Nous allons faire

sortir les cas d’utilisation ensuite nous procéderons à une description des scénarios de chaque

histoire, une conception globale du module, et on achève par le développement et le test.

4.1. Backlog du sprint « gestion des invitations des enseignants »

Le Backlog Product est le point d’entrée du projet, il présente une liste priorisée des

besoins de développement de l’application. Il est définit par des colonnes chacune possède

une désignation. (Voir définition des colonnes du sprint1 page 40)

Le backlog du deuxième sprint est illustré dans le tableau suivant :

Tableau 7 Backlog du sprint « gestion des invitations enseignants »

ID Thème En Tant que Je veux Afin que Priorité

1

Tutorat

administrateur

Consulter liste

invitations tuteur

Affecter une

invitation tuteur

M

2

Tutorat

administrateur

Envoyer une

invitation

Affecter un

tuteur pour

chaque module

M

3

Tutorat

administrateur

Rappeler l’enseignant par un

autre envoi

Gérer la liste des

invitations

S

4

Tutorat

Enseignant

(tuteur)

Recevoir une

invitation

Confirmer ou

annuler

l’invitation

S

5

Tutorat

Enseignant

(tuteur)

Recevoir une

invitation

Confirmer

l’invitation de

tutorat

M

6

Tutorat

Enseignant

(tuteur)

Recevoir une

invitation

Annuler

l’invitation du

tutorat

M

7

Coordination

Enseignant (coordinateur)

Recevoir une

invitation

Confirmer pour

assurer sa mission de coordination

M

64

8

Coordination

Enseignant

(coordinateur)

Envoyer une

invitation tutorat

pour un tuteur

Affecter

un tuteur pour

chaque module

S


4.2.1. Diagramme des cas d’utilisations

Figure 31 Diagramme de cas d’utilisation raffiné « Gérer invitation »

65

4.2.2. Les descriptions textuelles du troisième Sprint

Diagramme de cas d’utilisation raffiné « Gérer invitation »

Tableau 8 Description textuelle du diagramme « gérer invitation »

Cas d'utilisation : Gérer invitation

Résumé : Ce diagramme décrit les taches réalisées par l’administrateur le tuteur ainsi que le

coordinateur pour assurer, s’simplifier et réussir la mission de tutorat et de coordination et qui sont

comme suit :

o Gérer les invitations des coordinateurs

o Gérer les invitations des tuteurs

Acteur(s): Administrateur, tuteur, coordinateur



1. Le système affiche la page d’accueil de l’application qui inclut la liste des

formations.

2. L’administrateur, sélectionne la formation dont il va éditer le tutorat de ses

ECU/UE.

3. Le système affiche l’interface de la formation sélectionné.

4. L’administration s’intéresse tout d’abord à envoyer une invitation de coordination de

la formation au coordinateur

5. Le coordinateur reçoit cette invitation qui sera par la suite validée ou annulée.

6. L’administrateur va associer pour chaque ECU un tuteur.

7. L’administrateur envoi une invitation de tutorat par mail.

8. Le tuteur reçoit cette invitation qui sera validée ou annulée

9. Dans le cas ou l’administrateur ne reçoit aucune réponse à cette invitation, il est

possible du rappelé par l’envoi d’une autre invitation.

Post condition : invitation gérée

66

Diagramme de cas d’utilisation raffiné « Gérer invitation coordinateur»

Tableau 9 Description textuelle du diagramme « Gérer invitation coordinateur»

Cas d'utilisation : Gérer invitation coordinateur

Résumé : Ce diagramme décrit les taches réalisées par l’administrateur et le coordinateur

pour assurer, et réussir la mission de tutorat et qui sont comme suit :

o Consulter invitation

o Gérer les invitations

Acteur(s) : Administrateur, coordinateur

Pré-condition : Accès à l’application (Authentification).


1. L’administrateur, sélectionne la formation dont il va gérer le tutorat de ses ECU.

2. Le système affiche l’interface de la formation sélectionnée.

3. L’administration s’intéresse tout d’abord à envoyer une invitation de coordination de

la formation au coordinateur de ce fait il s’accède à l’interface « inviter

coordinateur »

4. Le système affiche l’interface sélectionnée.

5. L’administrateur remplit les champs de ce formulaire (année universitaire, nom,

prénom,)

6. L’administrateur clique sur un bouton « inviter »

7. Le coordinateur reçoit cette invitation qui sera par la suite validée ou annulée.

8. Dans le cas où l’invitation est validée, l’enseignant sera assigné à cette formation

comme coordinateur.

9. Dans le cas où l’invitation est annulée, l’administrateur reçoit une annulation.

10. Le coordinateur signale l'annulation de tutorat par envoi d’un mail à l'administrateur

pédagogique.

11. Dans le cas ou l’administrateur ne reçoit aucune réponse a cette invitation, est

possible du rappelé par l’envoi d’une autre invitation

Post condition : un coordinateur est affecté à une formation

67

Diagramme de cas d’utilisation raffiné « Gestion invitations tuteurs»

Tableau 10 Description textuelle du diagramme « gérer invitation tuteur »

Cas d'utilisation : Gérer invitation tuteur

Résumé : Ce diagramme décrit les taches réalisées par l’enseignant ainsi que

l’administrateur pour assurer, et réussir la mission de tutorat et qui sont comme suit :

o Gestion invitations tuteurs

Acteur(s): Administrateur, tuteur, coordinateur



1. L’administrateur, sélectionne la formation qu’il doit gérer le tutorat de ses ECU.

2. Le système affiche l’interface de la formation sélectionnée.

3. L’administrateur remplit les champs de ce formulaire (année universitaire, nom,

prénom,)

4. L’administrateur clique sur un bouton « inviter »

5. Le tuteur reçoit cette invitation qui sera par la suite validée ou annulée.

6. Dans le cas où l’invitation est validée, l’enseignant sera assigné à cette formation

comme tuteur.

7. Dans le cas où l’invitation est annulée, l’administrateur reçoit une annulation.

8. Le tuteur signale l'annulation de tutorat par envoi d’un mail à l'administrateur

pédagogique ou au coordinateur.

9. Le coordinateur de la formation a le droit aussi d’envoyer des invitations de tutorat

pour les enseignants. Il procède de la même manière que l’administrateur.

10. Dans le cas ou l’administrateur ne reçoit aucune réponse a cette invitation, il est

possible du rappelé par l’envoi d’une autre invitation.

Post condition : invitation tuteur gérer

4.3. Analyse et Conception

4.3.1. Les diagrammes de séquence du deuxième sprint

68

Pour décrire quelques scénarios, nous nous sommes basées sur une vue dynamique d’UML

étant le diagramme de séquence.

Diagramme de séquence détaillée de l’Item «lister invitations»

La figure 32 décrit la séquence des actions ayant lieu lorsque l’administrateur consulte la liste

des invitations.

Figure 32 Diagramme de séquence détaillée de l’Item «lister invitations»

Diagramme de séquence détaillée de l’Item «envoyer une invitation»

La figure 33 décrit la séquence des actions ayant lieu lorsqu’à l’administrateur envoi une

invitation de tutorat.

.

69

Figure 33 Diagramme de séquence détaillée de l’Item «envoyer une

invitation»

4.3.2. Le diagramme de classe du troisième sprint

Le diagramme de classes est considéré comme le plus important de la modélisation orientée

objet. Il est le seul obligatoire lors d'une modélisation, due qu’il montre la structure interne et

il permet de fournir une représentation abstraite des objets du système qui vont interagir pour

réaliser les cas d'utilisation.

70

Figure 34 Diagramme de classes de la conception de deuxième sprint


4.4.1. Génération des tables de la base de données

À partir du diagramme de classe du sprint, nous avons conçu une base de données

relationnelle, et par la suite de définir toutes les tables qui la composent .Cette mise en

relation de tables permet de relier les données d’une table à celles d’une autre table et ainsi

d’établir une base de données de type relationnelle représentée dans la figure qui suit.

71

Règle de passage

Le diagramme de classes présenté dans l’activité de conception de cette itération constitue un

modèle de passage pour le schéma de la Base de Données.

Le passage du diagramme de classes vers la Base de Données relationnelle nous avons

appliqué les règles suivantes :

o Chaque classe entité donne une table,

o Chaque attribut primitif donne une colonne dans la table,

o La colonne de la clé primaire est l’identificateur unique de table,

o Chaque association « un à plusieurs » est représentée par une clé étrangère dans la table

fille,

o Chaque association « plusieurs à plusieurs » entre classes est représentée par une nouvelle

table qui prend pour clé primaire la concaténation des clés primaires des deux classes,

o Chaque association « un à un » est représentée par l’intégration d’une clé étrangère dans

la table là moins récente.

72

Figure 35 Modèle relationnel de la Base de Données Sprint 2

4.4.2. Les Interfaces finales

Nous présentons dans ce qui suit quelques interfaces représentant le travail élaboré dans ce

sprint.

73

À travers cette interface l’administrateur va envoyer une invitation à l’enseignant pour assurer

une mission de coordination.

Figure 36 Interface invitation coordinateur

Cette interface présente la liste des invitations consultées par l’administrateur ou enseignant

assigné pour chaque élément consécutif constituant une unité d’enseignement d’une

formation.

Figure 37 Liste des invitations enseignants

74

En tant qu’enseignant il a la possibilité d’annuler l’invitation de tutorat ou de coordination

reçue.

Figure 38 annulation invitation

Cette interface illustre l’invitation que l’enseignant reçoit de la part de l’administrateur

ou du coordinateur et à travers la quelle il va la valider pour assurer la mission du tutorat d’

un module bien déterminé.

Figure 39 invitation tutorat

75

4.5. Test

Nous présentons dans cette partie les tests d’acceptation que nous avons effectués pour

valider ce sprint.

Test d’envoi d’invitation tutorat coordinateur


Figure 40 Test d’envoi invitation coordinateur

Figure 41 Test invitation reçue par le coordinateur

76

Figure 42 Test liste invitation coordinateur envoyée

Conclusion

Dans ce chapitre, nous avons réussi à réaliser le deuxième module de l’application

« gestion des invitations » avec une analyse des cas d’utilisation, une conception du module et

une réalisation des interfaces. Dans le chapitre qui suit, nous allons entamer le dernier sprint

couvrant les fonctionnalités liées à la gestion du CV et des informations sur les des

enseignants.

77


enseignants

78

Introduction

Après avoir dévoilé notre premier et deuxième sprint et atteindre ses objectifs, nous

passons vers le dernier sprint qui correspond à la phase de la gestion des enseignants. Nous

allons faire sortir les cas d’utilisation ensuite nous procèderons à une description des

scénarios de chaque histoire, une conception globale du module, et on achève par le

développement et le test.

5.1. Backlog du sprint « gestion des enseignants »

Le Backlog Product est le point d’entrée du projet, il présente une liste priorisée des

besoins de développement de l’application. Il est définit par des colonnes chacune possède

une désignation. (Voir définition des colonnes du sprint1 page 40)

Le backlog du sprint 3 est illustré dans le tableau suivant:

Tableau 11 Backlog du sprint « gestion des enseignants »

ID

Thème

En tant que

Je veux

Afin que

Priorité

1

Tutorat

Enseignant

Accepter l’invitation

Assurer la

mission du tutorat

M

2

Tutorat

Enseignant

Afficher liste des invitations tutorat

Valider ou annuler

l’invitation

M

3

Document

administratif

Enseignant

Ajouter les informations

personnelles en langue arabe

Constituer le CV

en langue arabe

S

4

Document administratif

Enseignant


personnelles en langue française

Constituer le CV en langue

française

S

5

Dossier enseignant

Enseignant

Ajouter les informations professionnelles en langue

arabe

Constituer le CV

en langue arabe

S

6

Dossier enseignant

Enseignant


professionnelles en langue française

Constituer le CV en langue

française

S

79

7

Tutorat

Enseignant

Déposer document

administratif

Accomplir dossier

enseignant

administratif

S

8

Tutorat

Enseignant

Imprimer heures tutorats

Générer document

administratif

S


5.2.1 Diagrammes des cas d’utilisations

Figure 43 Diagramme de cas d’utilisation raffiné « Gérer enseignant»

80

Figure 44 « Gérer CV en langue française »

Figure 45« Gérer CV en langue arabe »

81

5.2.2 Les descriptions textuelles du troisième Sprint

Diagramme de cas d’utilisation raffiné « Gérer enseignant »

Tableau 12 Description textuelle du diagramme « gérer enseignant »

Cas d'utilisation : Gérer enseignant

Résumé : Ce diagramme décrit les taches réalisées par l’enseignant tuteur ou coordinateur

pour assurer et réussir la mission de tutorat et qui est comme suit :

o Gestion CV et les informations personnelles des enseignants.

Acteur(s): Tuteur, coordinateur



1. Le tuteur est invité par l’administrateur pour assurer une mission de tutorat pour un

ou plusieurs modules bien déterminés.

2. Acceptation de cette invitation par le tuteur.

3. Le système affiche l’interface « Ma liste des invitations »

4. Le tuteur clique sur le lien « mon CV ».

5. Le système affiche l’interface « CV enseignant », qui est constituée d’un menu à

gauche pour l’édition des informations en français et un autre à droite pour l’édition

des informations en arabe.

6. Le tuteur va remplir différents formulaires (« les informations personnelles », « mon

compte », « mon image de profil », « mes diplômes ») qui constituent son identité en

ouvrant l’onglet « Mon CV » et il valide par l’enregistrement s’il s’agit d’un

nouveau membre.

7. Le tuteur modifie les informations qui constituent son identité et il valide par

l’enregistrement dans le cas d’un enseignant existant et a besoin de modifier quelques

informations.

8. Par la suite le tuteur passe à l’édition ou la modification de ses informations

professionnelles en ouvrant l’onglet « informations professionnelles ». (expérience

d’enseignement, spécialité, grades, expérience professionnels).

9. Le système enregistre les informations ajoutées.

82

10. Et comme dernière étape le tuteur va ajouter les informations qui concernent ses

activités, en ouvrant l’onglet « mes activités avec l’UVT ».

Post-condition : dossier enseignant ajouté en langue française

Diagramme de cas d’utilisation raffiné « Gérer CV»

Tableau 13 Description textuelle du diagramme « gérer CV »

Cas d'utilisation : Gérer CV en langue française

Résumé : Ce diagramme décrit les taches réalisées par l’enseignant (tuteur ou coordinateur)

pour assurer, et réussir la mission de tutorat et qui sont comme suit :

o Gestion CV en langue française





2. Le système affiche l’interface « cv enseignant », qui est constituée d’un menu à

gauche pour l’édition des informations en français constituant le CV.

3. Le tuteur ouvre la rubrique mon CV et clique sur le premier lien

4. Le système affiche le formulaire d’identification.

5. Le tuteur va remplir tous les champs du formulaire d’identification et clique sur

le bouton « enregistre »

6. Le système enregistre les informations saisisses

7. Le tuteur clique sur le deuxième lien image de profil et télécharge son image.

8. Le système enregistre et affiche le fichier image ajouté.

9. Le tuteur clique sur le troisième lien de la rubrique « mon compte ».

10. Le système affiche le formulaire mon, compte.

11. Le tuteur remplit les champs et clique sur enregistrer

12. Le système enregistre les informations ajoutées

83

13. Le tuteur clique sur le quatrième lien de la rubrique « mes diplômes ».


15. Le tuteur doit cocher une case à cocher au dessous du formulaire diplôme s’il

s’agit du dernier diplôme obtenu

16. Le système enregistre les informations ajoutées et les liste dans la même

interface des diplômes dans un tableau.

17. Le tuteur a la possibilité de supprimer ou modifier chaque enregistrement à

travers deux boutons devant chaque ligne du tableau.

Post-condition : CV enseignant ajouté en langue française

Diagramme de cas d’utilisation raffiné « Gérer informations personnelles »

Tableau 14 Description textuelle du diagramme « gérer information personnelle »

Cas d'utilisation : Gérer informations personnelles

Résumé : Ce diagramme décrit les taches réalisées par l’enseignant pour géré ses

informations personnelles, afin de mener de bien la mission de tutorat et qui sont comme

suit :

o Ajout des grades

o Ajout des spécialités

o Ajout des expériences professionnelles

o Ajout des expériences d’enseignement

o Ajout des travaux

o Ajout des formations





2. Le système affiche l’interface « cv enseignant », qui est constituée d’un menu à gauche pour

l’édition des informations personnelles et professionnelles concernés.

3. Le tuteur ouvre la rubrique mes informations personnelles et clique sur le premier lien

84

4. Le système affiche le formulaire « mes grades ».

5. Le tuteur va sélectionner un grade de la liste du menu déroulant du formulaire, et ajouter sa

date d’obtention

6. Le tuteur clique sur le bouton « enregistre »

7. Le système enregistre les informations saisisses

8. Le tuteur clique sur le deuxième lien mes spécialités et remplit les champs du formulaire.

9. Le système enregistre et affiche une liste des spécialités dans la même interface à droite.

10. Le tuteur clique sur le troisième lien de la rubrique « mon expérience d’enseignement ».

11. Le système affiche le formulaire mon expérience d’enseignement


13. Le système enregistre les informations ajoutées et affiche une liste des spécialités dans la

même interface à droite.

14. Le tuteur clique sur lien de la rubrique « mon expérience d’enseignement ».

15. Le système affiche le formulaire mon expérience d’enseignement


17. Le système enregistre les informations ajoutées et affiche une liste des établissements dans

la même interface à droite

18. De même pour le lien d’après, à travers le quel l’enseignant va définir la liste de ses

formations qu’il a assurés ainsi qu’il a suivi.

19. Le système enregistre les informations ajoutées et affiche une liste des formations dans la

même interface à droite.

20. Enfin le tuteur clique sur le dernier lien contenant la rubrique « mes travaux »

Le système affiche le formulaire.


22. Le système enregistre les informations ajoutées et affiche une liste des travaux dans la même

interface à droite.

23. Le tuteur a la possibilité de supprimer ou modifier chaque enregistrement à travers deux

boutons devant chaque ligne du tableau pour toutes les interfaces comportant des listes.

Post-condition : dossier enseignant ajouté en langue française

85

Diagramme de cas d’utilisation raffiné « Gérer CV en langue Arabe»

Tableau 15 Description textuelle du diagramme « Gérer informations enseignants

en langue arabe »

Cas d'utilisation : Gérer CV en langue Arabe

Résumé : Ce diagramme décrit les taches réalisées par l’enseignant pour géré son CV en

langue arabe, afin de mener de bien la mission de tutorat et qui sont comme suit :

o Ajout des informations de l’identité en langue arabe

o Ajout des informations professionnelles en langue arabe

o Déposer le dosser de tutorat

o Imprimer le document officiel de l’UVT de l’autorisation de tutorat




1. Le tuteur passe à éditer ses informations en langue arabe

2. Le système affiche l’interface «معطياث عامت خاصت بالملف الإداري », qui est constituée

d’un menu à droite pour l’édition des informations en arabe.

3. Le tuteur ouvre la rubrique « المعطياث شخصيت» et remplit tous les champs du

formulaire


5. Le tuteur clique sur le deuxième lien «المعطياث المهنيت » et remplit les champs du

formulaire


7. Le tuteur clique sur le troisième lien de la rubrique « أعلى شهادة علميت» et remplit les

champs


9. Le tuteur clique sur le quatrième lien de la rubrique « داع الملف الإدار ي À ce .«إي

niveau le tuteur peut déposer son dossier officiel pour le tutorat comportant la CIN,

l’autorisation, l’attestation de travail, diplôme et la charte tuteur.

86

10. Enfin à travers le dernier lien « طباعت مطلب ساعاث التذريس » le tuteur a la possibilité

d’imprimer, le document officiel de l’ut de l’autorisation et le signer directement afin

de le porter à l’administration pour (par le publipostage).

Post-condition : CV enseignant ajouté en langue arabe et dossier officiel déposé

5.3. Analyse et Conception

5.3.1. Les diagrammes de séquence du troisième sprint

Le diagramme de séquence détaillé analyse l’interaction des acteurs intervenant dans les

fonctionnalités pour ce sprint avec la partie système en détail. Pour décrire quelques scénarios,

nous nous sommes basées sur scénarios, nous nous sommes basées sur une vue dynamique

d’UML étant le diagramme de séquence.

Diagramme de séquence détaillée de l’Item «Ajouter grade»

La figure 46 décrit la séquence des actions ayant lieu lorsque le tuteur ajoute ses grades.

87

Figure 46 Diagramme de séquence détaillée de l’Item «Ajouter grade»

88

Diagramme de séquence détaillée de l’Item «Ajouter travaux»

La figure 47 décrit la séquence des actions ayant lieu lorsque le tuteur ajoute ses travaux.

Figure 47 Description de séquence détaillée de l’Item «Ajouter travaux»

89

5.3.2 Le diagramme de classe du troisième sprint

Figure 48 Diagramme de classe de conception de dernier sprint


5.4.1. Génération des tables de la base de données

À partir du diagramme de classe du deuxième sprint, nous avons conçu une base de données

relationnelle, et par la suite nous avons défini les tables qui la composent. Les tables sont

rassemblées en deux figures :

La figure 49 rassemble les tables de la base de donnés représentant les formations des

enseignants.

90

Figure 49 Modèle relationnel de la base de données « formation des enseignants »

91

La figure 50 rassemble les tables de la base de donnés qui constitue l’identité des

enseignants.

Figure 50 Modèle relationnel de la base de données « informations enseignants »

5.4.2. Les Interfaces finales

Nous présentons dans ce qui suit quelques interfaces représentant le travail réalisé dans ce

sprint

Une fois l’invitation est validée, l’enseignant se trouve dans cette interface ou il va saisir ses

informations administratives, personnelles et professionnelles.

Figure 51 Interface d’accueil gestion des enseignants.

92

Cette interface permet à l’enseignant en tant que coordinateur ou tuteur de gérer son CV

et d’inclure toutes ses informations d’identifications en langue française.

Figure 52 Interface gestion « CV enseignant »

En tant qu’enseignant et à travers cette interface, il va ajouter ses expériences

professionnelles en langue arabe.

Figure 53 Interface « gestion informations professionnelles enseignant » en langue

arabe

93

Cette interface permet à l’enseignant de déposer son dossier administratif (CIN, diplôme,

autorisation, attestation de travail, charte tuteur).

Figure 54 Interface « déposer le dossier administratif »

Cette interface permet à l’enseignant en tant que coordinateur ou tuteur de créer un

compte d’authentification à travers l’adresse e-mail et un mot de passe.

Figure 55 Interface mon compte pour l’enseignant

94

Cette interface permet à l’enseignant en tant que coordinateur ou tuteur de gérer son CV

et d’inclure toutes ses informations d’identification en langue arabe.

Figure 56 Interface gestion CV enseignant en langue arabe

À travers cette interface l’enseignant a la possibilité d’ajouter et mettre à jour ses grades.

Figure 57 interface ajout grade enseignant

95

5.5. Test

Nous présentons dans cette partie les tests d’acceptations que nous avons effectués pour

valider ce sprint.

Test d’ajout d’un enseignant


Figure 58 test d’ajout enseignant

Figure 59 test authentification de l’enseignant ajouté

96

Figure 60 test d’intégration d’un nouvel enseignant ajouté à la liste des personnes

Conclusion

Nous arrivons à la fin du développement du dernier sprint de l’application qui inclut les

fonctionnalités liés à la « gestion des enseignants ». Nous avons ainsi réussi à réaliser le

module avec l’analyse, la conception, l’implémentation et le test. De ce fait, nous avons

terminé la réalisation de ce projet.

97

Conclusion générale

Le présent travail s’inscrit dans le cadre du projet de fin d’étude pour l’obtention du

diplôme de mastère professionnel en nouvelles technologies de télécommunications et des

réseaux (N2TR). Ce projet a constitué pour moi une occasion pour mettre en application

plusieurs notions et connaissances relevant de divers domaines (programmation, réseaux…)

acquises tout au long des deux années de formation.

Le projet porte sur la conception et la réalisation d’une solution à travers une application

informatique pour le suivi d’une formation pour le service pédagogique et de la vie

universitaire au sein de l’Université Virtuelle de Tunis, et qui rassemble les fonctionnalités

gérées principalement par l’enseignant et l’administrateur pour ce suivi. La réalisation de

cette application a été initiée par l’étude des solutions existantes et leur critique afin de fixer

les fonctionnalités de la future application. Ensuite, nous avons établi une analyse détaillée

modélisée en langage UML. Enfin, nous avons concrétisé notre travail par la réalisation de

notre solution.

Enfin, tout le long de l’élaboration du projet, nous avons rencontré plusieurs difficultés

tant au niveau de la réalisation qu’au niveau conceptuel. Mais tout de même, nous avons

réussi à les surpasser pour présenter en fin de compte une application opérationnelle

conforme aux exigences précisées dans le cahier des charges. Nous estimons avoir relevé le

défi auquel nous étions soumis pour explorer de manière descriptive une solution adéquate

susceptible de répondre aux besoins croissants des services de l’UVT en matière de suivi de

formation.

98

WEBOGRAPHIE

[1] https://www.uvt.rnu.tn/l-universite/presentation

[2] https://www.uvt.rnu.tn/l-universite/organigramme

[3] https://www.uvt.rnu.tn/l-universite/infrastructure-technique

[4] http://blogs.articulate.com/les-essentiels-du-elearning/questce-le-e-learning/

[5] https://www.c-sharpcorner.com/article/scrum-framework-5-events-in-scrum-framework/

[6] https://www.c-sharpcorner.com/article/scrum-framework-5-events-in-scrum-framework/

[7] https://fr.wikipedia.org/wiki/PhpMyAdmin

[8] https://fr.wikipedia.org/wiki/Ajax_(informatique)

[9] https://framework.zend.com/manual/1.11/fr/learning.quickstart.intro.html

[10] https://www.softwaretestingmaterial.com/software-architecture/

[11] https://www.softwaretestingmaterial.com/software-architecture

[12] https://www.nutcache.com/fr/blog/quest-ce-quun-backlog-scrum/

https://www.uvt.rnu.tn/l-universite/presentation

https://www.uvt.rnu.tn/l-universite/organigramme

https://www.uvt.rnu.tn/l-universite/infrastructure-technique

http://blogs.articulate.com/les-essentiels-du-elearning/questce-le-e-learning/

https://www.c-sharpcorner.com/article/scrum-framework-5-events-in-scrum-framework/

https://www.c-sharpcorner.com/article/scrum-framework-5-events-in-scrum-framework/

https://fr.wikipedia.org/wiki/PhpMyAdmin

https://fr.wikipedia.org/wiki/Ajax_(informatique)

https://framework.zend.com/manual/1.11/fr/learning.quickstart.intro.html

https://www.softwaretestingmaterial.com/software-architecture/

https://www.softwaretestingmaterial.com/software-architecture

https://www.nutcache.com/fr/blog/quest-ce-quun-backlog-scrum/

99

Conception et Réalisation d’une Application de suivi déroulement

d’une formation à l’Université virtuelle de Tunis

Rapport de Stage PFE, Mastère N2TR UVT 2017-2018

Résumé

Ce mémoire a été rédigé dans le cadre d’un stage clôturant la deuxième année d’études de

mastère professionnel en nouvelles technologies de télécommunications et des réseaux.

Ce stage avait pour but de concevoir et développer une solution pour une gestion adéquate du

suivi du déroulement de la formation spécifique en ligne, distincte de celle de l’enseignement

présentiel, afin de garantir son bon déroulement et pallier à ses problèmes.

À travers cette application l’administrateur a pour mission de:

o Saisir les différentes informations de l’habilitation de la formation ;

o Saisir les délais accordés pour l’élaboration du différents calendrier (calendrier

universitaire, pédagogique, étude et réservation) ;

o Inviter les tuteurs pour leur assigner un ou plusieurs modules selon l’année

universitaire ;

Aussi, l’enseignant a pour mission de saisir l’ensemble des informations qui le concernent

en deux langues (CV, documents officieux demandés par l’UVT pour le dossier de tutorat,

nombre de modules assurés par tuteur, nombre d’étudiants tutorés par tuteur…)

Dans le cas où l’enseignant est un coordinateur, il a pour mission de :

o d’inviter des tuteurs pour tutorer un module ;

o de saisir avec le tuteur le calendrier pédagogique de chaque module (date d’ouverture

de chaque chapitre, date des DS sur la plateforme, délais de réalisation des activités et

de dépôt des travaux.)

o de saisir son calendrier pédagogique selon les délais mentionnés par l’université (délai

accordé pour le démarrage de la formation, délai accordé pour élaborer les examens,

délai accordé pour la délibération …)

Mots clés : Formation à distance, Scrum, tutorat, MVC, suivi de formation, tutorat,

tuteur , coordinateur, sprint

DE STAGE DE FIN D’ETUDES

Documents

Transcript of DE STAGE DE FIN D’ETUDES