Université de Tunis

Institut Supérieur de Gestion de Tunis

RAPPORT DE STAGE DE FIN D’ÉTUDES

En vue de l’obtention du diplôme de

La licence fondamentale en informatique de gestion

Développement de l’application mobile du portail "MyU"

Organisme d’accueil :

Honoris United Universities

Réalisé par :

Kamoun Hédi

Sallem Marwen

Encadrant pédagogique

Encadrante professionnelle

Mr. Katar Chaker

Mme. Bsila Wafa

Année universitaire

2018/2019

Dédicace

Je dédie ce travail,

A ma très chère grand-mère Hayet Badri Attia, à mes parents, à mon grand frère, ainsi qu’à

tous les membres de ma famille.

Au très cher comité du Rotaract club ISG Tunis.

Ainsi qu’à toute ma famille Rotarienne.

-Hedi.

Dédicace

A mes chers parents,

Merci pour vos sacriﬁces innombrables et votre soutien tout au long ma vie,je dois tout mon

succès a vous .

A la plus belle femme au monde, ma grand-mère chrifa nefzi,

Je t’aime plus que les mots ne peuvent le dire.

A mes petites soeurs et petits frères,

Merci d’avoir été le Jerry pendant les 17 dernières années de ma vie.

A ma grande Soeur Jamila,

Mon amie d’enfance et partenaire dans le crime qui gère toujours à s’échapper je t’aime

beaucoup, Je te souhaite tout le succès.

A ma famille du Croissant Rouge Hammam Lif,

Votre soutien vaut le monde pour moi, que Dieu vous protège.

A mes amis proches

Que votre vie soit remplie de bonheur et de réussite.

-Marwen

Remerciement

C’est avec un grand plaisir et beaucoup de gratitude que nous présentons nos remercie-

ments et notre profonde reconnaissance à tous ceux qui, de prés ou de loin, ont contribué à

l’aboutissement de ce travail.

Nos remerciements s’adressent à notre encadrant pédagogique Mr Katar Chaker et notre

encadrante professionnelle Mme Bsila Wafa pour leur disponibilité et leurs précieuses recom-

mandations.

Nous remercions également les membres du jury pour avoir bien voulu donner de leur temps

pour lire et évaluer ce travail.

Nos remerciements vont également à Mme la directrice IT Somai Meriem.

Enﬁn, nous tenons à exprimer notre gratitude envers tous les enseignants de l’ISG Tunis.

Table des matières

1 Contexte général du projet

1.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Présentation de l’organisme d’accueil

. . . . . . . . . . . . . . . . . . . . . .

1.3 Contexte et cadre du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.3

Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1 L’approche agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.2 La méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.3 Principe de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Sprint 0 : Planiﬁcation et architecture

2.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1 Description du contexte

. . . . . . . . . . . . . . . . . . . . . . . . .

2.3

Identiﬁcation des besoins fonctionnels et non fonctionnels . . . . . . . . . . .

2.3.1

Identiﬁcation des acteurs . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.2 Les besoins fonctionnels

. . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIÈRES

2.3.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . .

2.4 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5 Découpage du projet en sprints

. . . . . . . . . . . . . . . . . . . . . . . . .

2.6 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . .

2.7 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7.2 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Sprint 1 : Gestion des comptes

3.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Sprint Backlog

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Analyse du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.1 Diagramme de cas d’utilisation global du Sprint 1 . . . . . . . . . . .

3.3.2 Raﬃnement du cas d’utilisation "S’Authentiﬁer" . . . . . . . . . . . .

3.3.3 Description textuelle du cas d’utilisation "s’authentiﬁer" . . . . . . .

3.3.4 Raﬃnement du cas d’utilisation "Gérer etudiants" . . . . . . . . . . .

3.3.5 Raﬃnement du cas d’utilisation "Gérer comptes" . . . . . . . . . . .

3.3.6 Raﬃnement cas d’utilisation "Gérer proﬁl" . . . . . . . . . . . . . . .

3.3.7 Raﬃnement du cas d’utilisation "Gérer groupes"

. . . . . . . . . . .

3.3.8 Raﬃnement du cas d’utilisation "Gérer formations" . . . . . . . . . .

3.3.9 Prototype d’interfaces

. . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 Conception du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.1 Diagramme de classe de conception du cas d’utilisation "S’Authentiﬁer" 45

3.4.2 Diagramme de séquence détaillé du cas d’utilisation "S’Authentiﬁer"

3.4.3 Diagramme de classe de conception "Gérer etudiants" . . . . . . . . .

3.4.4 Diagramme de séquence détaillé du cas d’utilisation "Ajouter etudiant" 48

3.4.5 Diagramme de classe de conception "Gérer comptes" . . . . . . . . .

TABLE DES MATIÈRES

3.4.6 Diagramme de séquence détaillé du cas d’utilisation "Créer compte" .

3.4.7 Diagramme de séquence détaillé du cas d’utilisation "Consulter compte" 51

3.4.8 Diagramme de classe de conception "Gérer proﬁl" . . . . . . . . . . .

3.4.9 Diagramme de séquence détaillé du cas d’utilisation "Consulter proﬁl"

3.4.10 Diagramme de classe de conception "Gérer groupes"

. . . . . . . . .

3.4.11 Diagramme de séquence détaillé du cas d’utilisation "Créer groupe" .

3.4.12 Diagramme de classe de conception "Gérer formations" . . . . . . . .

3.4.13 Diagramme de séquence détaillé du cas d’utilisation "Créer formation" 57

3.4.14 Diagramme de classe sprint 1 . . . . . . . . . . . . . . . . . . . . . .

3.5

Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5.1

Schéma de la base de donnée du sprint 1 . . . . . . . . . . . . . . . .

3.5.2 Authentiﬁcation et sécurité

. . . . . . . . . . . . . . . . . . . . . . .

3.5.3 Notiﬁcations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5.4 Présentation des interfaces utilisateur . . . . . . . . . . . . . . . . . .

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Sprint 2 : Gestion du E-Learning

4.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Sprint Backlog

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Analyse du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.1 Diagramme de cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . .

4.3.2 Raﬃnement du cas d’utilisation "Gérer plan d’étude" . . . . . . . . .

4.3.3 Raﬃnement du cas d’utilisation "Gérer enseignants" . . . . . . . . .

4.3.4 Description textuelle du cas d’utilisation "Consulter enseignants" . .

4.3.5 Raﬃnement du cas d’utilisation "Gérer emploi du temps"

. . . . . .

4.3.6 Description textuelle du cas d’utilisation "Consulter emploi du temps"

4.3.7 Raﬃnement du cas d’utilisation "Gérer cours en ligne" . . . . . . . .

4.3.8 Description textuelle du cas d’utilisation "Consulter cours en ligne" .

TABLE DES MATIÈRES

4.3.9 Prototype d’interfaces

. . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Conception du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.1 Diagramme de classe de conception "Gérer cours en ligne" . . . . . .

4.4.2 Diagramme de séquence détaillé du cas "Lister ﬁchiers" . . . . . . . .

4.4.3 Diagramme de séquence détaille du cas "consulter cours en ligne" . .

4.4.4 Diagramme de classe de conception "Gérer emploi du temps" . . . . .

4.4.5 Diagramme de séquence détaillé du cas "Créer seance" . . . . . . . .

4.4.6 Diagramme de séquence détaille du cas "Consulter emploi du temps"

4.4.7 Diagramme de classe du Sprint 2 . . . . . . . . . . . . . . . . . . . .

4.5

Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5.1

Schéma de la base de donnée du sprint 2 . . . . . . . . . . . . . . . .

4.5.2 Présentation des interfaces utilisateurs

. . . . . . . . . . . . . . . . .

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Sprint 3 : Gestion des aﬀaires éstudiantine

5.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Sprint Backlog

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3 Analyse du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.1 Diagramme de cas d’utilisation du sprint 3 . . . . . . . . . . . . . . .

5.3.2 Raﬃnement du cas d’utilisation "Gérer tickets" . . . . . . . . . . . .

5.3.3 Description textuelle du cas d’utilisation "Enregistrer ticket" . . . . .

5.3.4 Raﬃnement du cas d’utilisation "Gérer examens" . . . . . . . . . . .

5.3.5 Description textuelle de cas d’utilisation "Consulter planning examens" 96

5.3.6 Raﬃnement du cas d’utilisation "Gérer absences" . . . . . . . . . . .

5.3.7 Raﬃnement du cas d’utilisation "Gérer notes et résultats" . . . . . .

5.3.8 Raﬃnement du cas d’utilisation "Gérer actualites" . . . . . . . . . .

5.3.9 Prototype d’interfaces

. . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.4 Conception du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

TABLE DES MATIÈRES

5.4.1 Diagramme de classe de conception "Gérer tickets" . . . . . . . . . . 101

5.4.2 Diagramme de séquence détaille du cas "Lister tickets" . . . . . . . . 102

5.4.3 Diagramme de séquence détaille du cas "Enregistrer ticket" . . . . . . 103

5.4.4 Diagramme de classe de conception "Gerer examens" . . . . . . . . . 104

5.4.5 Diagramme de séquence détaille du cas "Consulter planning examens" 105

5.4.6 Diagramme de classe sprint 3 . . . . . . . . . . . . . . . . . . . . . . 106

5.5

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.5.1

Schéma de la base de donnée du sprint 3 . . . . . . . . . . . . . . . . 108

5.5.2 Présentations des interfaces utilisateurs . . . . . . . . . . . . . . . . . 110

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6 Sprint 4 : Dockerisation

112

6.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2 Technologie Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.3 Comparaison VM et Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.4 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.4.1 Architecture docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.4.2 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7 Environnement de développement

118

7.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

7.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7.2.1 Environnement matériel

. . . . . . . . . . . . . . . . . . . . . . . . . 119

7.2.2 Environnement logiciel

. . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.2.3 Technologie utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Table des ﬁgures

1.1 Logo de Honoris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

cycle de vie de la méthode SCRUM[5] . . . . . . . . . . . . . . . . . . . . . .

2.1 UI et UX[6]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Découpage des Sprints

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . .

2.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Diagramme de cas d’utilisation Sprint 1 . . . . . . . . . . . . . . . . . . . . .

3.2 Diagramme de cas d’utilisation du cas "s’Authentiﬁer" . . . . . . . . . . . .

3.3 Diagramme de cas d’utilisation raﬃné "Gérer etudiants" . . . . . . . . . . .

3.4 Diagramme de cas d’utilisation raﬃné "Gérer comptes" . . . . . . . . . . . .

3.5 Diagramme de cas d’utilisation Raﬃné "Gérer proﬁl" . . . . . . . . . . . . .

3.6 Diagramme de cas d’utilisation raﬃné "Gérer groupes" . . . . . . . . . . . .

3.7 Diagramme de cas d’utilisation raﬃné "Gérer formations" . . . . . . . . . .

3.8 Maquettes d’interfaces du Sprint 1

. . . . . . . . . . . . . . . . . . . . . . .

3.9 Diagramme de classe de conception "s’Authentiﬁer" . . . . . . . . . . . . . .

3.10 Diagramme de séquence détaillé "s’Authentiﬁer" . . . . . . . . . . . . . . . .

3.11 Diagramme de classe de conception "Gérer etudiants" . . . . . . . . . . . . .

3.12 Diagramme de séquence détaillé "Créer etudiant" . . . . . . . . . . . . . . .

3.13 Diagramme de classe de conception "Gérer comptes" . . . . . . . . . . . . .

TABLE DES FIGURES

3.14 Diagramme de séquence détaillé "Créer compte" . . . . . . . . . . . . . . . .

3.15 Diagramme de séquence détaillé "Consulter compte" . . . . . . . . . . . . .

3.16 Diagramme de séquence détaillé "Gérer proﬁl" . . . . . . . . . . . . . . . . .

3.17 Diagramme de séquence détaillé "Consulter proﬁle . . . . . . . . . . . . . . .

3.18 Diagramme de classe de conception "Gérer groupes" . . . . . . . . . . . . . .

3.19 Diagramme de séquence détaillé "Créer groupe . . . . . . . . . . . . . . . . .

3.20 Diagramme de classe de conception "Gérer formations" . . . . . . . . . . . .

3.21 Diagramme de séquence détaillé "Créer formation . . . . . . . . . . . . . . .

3.22 Diagramme de classe Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . .

3.23 Schéma de la base de donnée sprint 1 . . . . . . . . . . . . . . . . . . . . . .

3.24 Création du Token lors de l’authentiﬁcation par le serveur

. . . . . . . . . .

3.25 Réception des notiﬁcations . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.26 Interface utilisateur du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Diagramme de cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . . . . . .

4.2 Diagramme de cas d’utilisation raﬃné "Gérer plan d’étude" . . . . . . . . .

4.3 Diagramme de cas d’utilisation raﬃné "Gérer enseignants" . . . . . . . . . .

4.4 Diagramme de cas d’utilisation raﬃné "Gérer emploi du temps" . . . . . . .

4.5 Diagramme de cas d’utilisation raﬃné "Gérer cours" . . . . . . . . . . . . .

4.6 Maquettes interfaces du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . .

4.7 Diagramme de classe de conception "Gérer cours en ligne" . . . . . . . . . .

4.8 Diagramme de séquence détaillé du cas d’utilisation "Lister ﬁchiers" . . . . .

4.9 Diagramme de séquence détaillé du cas d’utilisation "Consulter cours" . . . .

4.10 Diagramme de classe de conception "Gérer emploi du temps" . . . . . . . . .

4.11 Diagramme de séquence détaillé du cas d’utilisation "Créer séance" . . . . .

4.12 Diagramme de séquence détaillé du CU "Consulter emploi du temps" . . . .

4.13 Diagramme de classe du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . .

4.14 Schéma de la base de donnée sprint 2 . . . . . . . . . . . . . . . . . . . . . .

TABLE DES FIGURES

4.15 Présentation des interfaces du Sprint 2 . . . . . . . . . . . . . . . . . . . . .

5.1 Diagramme de cas d’utilisation du Sprint 3 . . . . . . . . . . . . . . . . . . .

5.2 Diagramme de cas d’utilisation "Gérer tickets" . . . . . . . . . . . . . . . . .

5.3 Diagramme de cas d’utilisation "Gérer examens" . . . . . . . . . . . . . . . .

5.4 Diagramme de cas d’utilisation "Gérer absences"

. . . . . . . . . . . . . . .

5.5 Diagramme de cas d’utilisation "Gérer les notes et résultats" . . . . . . . . .

5.6 Diagramme de cas d’utilisation "Gérer actualites" . . . . . . . . . . . . . . .

5.7 Maquettes d’interfaces du Sprint 3

. . . . . . . . . . . . . . . . . . . . . . . 100

5.8 Diagramme de classe de conception "Gérer tickets" . . . . . . . . . . . . . . 101

5.9 Diagramme de séquence détaillé du cas d’utilisation "Lister tickets" . . . . . 102

5.10 Diagramme de séquence détaillé du cas d’utilisation "Enregistrer ticket" . . . 103

5.11 Diagramme de classe de conception "Gerer examens" . . . . . . . . . . . . . 104

5.12 Diagramme de séquence détaillé du CU "Consulter planning examens" . . . 105

5.13 Diagramme de classe du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.14 Schéma de la base de donnée sprint 3 . . . . . . . . . . . . . . . . . . . . . . 109

5.15 Présentation des interfaces du Sprint 3 . . . . . . . . . . . . . . . . . . . . . 110

6.1 Virutalisation et conteneurisation[9] . . . . . . . . . . . . . . . . . . . . . . . 114

6.2 Architecture docker[9]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.3 Conteneur Back-End et base de données

. . . . . . . . . . . . . . . . . . . . 116

6.4 DockerFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Liste des tableaux

2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

3.2 Description textuelle du cas "S’authentiﬁer" . . . . . . . . . . . . . . . . . .

3.3 Description textuelle du cas "Consulter proﬁl" . . . . . . . . . . . . . . . . .

3.4 Description textuelle du cas "Modiﬁer proﬁl" . . . . . . . . . . . . . . . . . .

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

4.2 Description textuelle du cas "Consulter emploi du temps" . . . . . . . . . . .

4.3 Description textuelle du cas "Consulter emploi du temps" . . . . . . . . . . .

4.4 Description textuelle du cas "Consulter mes cours" . . . . . . . . . . . . . .

5.1 Sprint Backlog 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Description textuelle du cas "Enregistrer ticket" . . . . . . . . . . . . . . . .

5.3 Description textuelle du cas "Consulter ticket" . . . . . . . . . . . . . . . . .

5.4 Description textuelle du cas "Consulter planning examens" . . . . . . . . . .

6.1 Tableau comparatif entre Les VMs et Conteneurs[10]

. . . . . . . . . . . . . 114

7.1 Caractéristiques du 1er ordinateur . . . . . . . . . . . . . . . . . . . . . . . . 119

7.2 Caractéristiques du 2ème ordinateur

. . . . . . . . . . . . . . . . . . . . . . 119

Introduction

Il est vrai que le développement mobile augmente de plus en plus en notoriété surtout

ces dernières années avec la popularisation des smartphones et de la micro technologie.

Cette augmentation est due à la ﬁabilité, l’évolution et la portabilité qui permet aux grandes

entreprises d’interagir avec les clients, partenaires et salariés ainsi qu’à la facilité d’accéder à

l’information depuis sa poche. Il est alors totalement logique d’estimer que les applications

mobiles sont un enjeu vital. Leur importance ne fait que grandir avec le temps, et pour

rester pertinent, il est de plus en plus important que votre organisation dispose de sa propre

application dédiée. De ce fait de plus en plus d’entreprises optent aujourd’hui pour une

stratégie de développement basée sur des services avec des fonctionnalités mobiles intégrées.

L’intégration du développement d’applications mobiles à une stratégie plus large basée sur

des micros services cloud-native oﬀre de nombreux avantages : augmentation de la produc-

tivité, réduction des coûts, renforcement de la sécurité, amélioration du niveau de visibilité

et de contrôle. C’est dans ce domaine que s’intègre notre projet de ﬁn d’étude qui est le

«développent d’une application mobile» qui consiste à développer une application mobile

native qui aura pour but de permettre aux étudiants des établissements d’Honoris United

Universities d’accèder à leurs informations scolaires.

Ce rapport est reparti en 7 chapitres :

— Le premier chapitre sera consacré à une introduction générale de l’organisme d’ac-

cueil ainsi que du cadre et contexte du projet ainsi que la méthodologie de développe-

ment.

LISTE DES TABLEAUX

— Le second chapitre présentera l’analyse des besoins, Identiﬁcation des besoins fonc-

tionnels et non fonctionnels, la mise en place du Backlog produit et le découpage des

Sprints.

— Les trois chapitres qui suivent seront consacrés aux 3 premiers Sprint, nous trai-

terons leurs analyse,conception et implementation.

— Le sixième chapitre montrera le déploiement de notre projet dans des conteneurs

Docker.

— Le dernier chapitre fera oﬃce de présentation de l’environnement de développement

de notre application.

Et enﬁn, nous terminerons par clôturer notre rapport avec une conclusion générale et une

perspective.

Chapitre 1

Contexte général du projet

1.1 Introduction

Ce chapitre sera représenté sous la forme d’un aperçu

du projet. Il englobera une présentation de l’orga-

nisme d’accueil ainsi que le cadre général de notre

projet. Ensuite nous passerons à l’étude de l’existant

suivi de sa critique, puis nous ﬁnirons par proposer

notre solution.

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET

1.2 Présentation de l’organisme d’accueil

Figure 1.1 – Logo de Honoris

Honoris United Universities est le premier réseau panafricain d’enseignement supérieur

privé engagé à former la nouvelle génération de leaders et de professionnels africains capables

d’avoir un impact sur leurs sociétés et leurs économies dans un monde globalisé.

Avec 32 000 étudiants, répartis sur 58 campus, centres d’apprentissage ou en ligne, dans

9 pays et 30 villes en Afrique, Honoris United Universities délivre plus de 150 diplômes

dans les domaines des Sciences de la Santé, de l’Ingénierie, de l’IT, du Business, du Droit, de

l’Architecture, des Arts et du Design, des Médias, de l’Education et des Sciences Politiques.[1]

Mission et valeurs

Les fondateurs de "Honoris united universities" partages la vision de pouvoir préparer et

former des leaders et des professionnels axés sur les solutions capables d’opérer avec succès

sur le continent le plus jeune et à la croissance la plus rapide du monde, des individus

capables d’inﬂuencer les économies et les communautés de demain.[2]

1.3 Contexte et cadre du projet

Ce projet s’inscrit dans le cadre d’un projet de ﬁn d’études pour l’obtention du diplôme

de la licence fondamentale en informatique de gestion de l’institut supérieur de gestion de

Tunis.

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET

Nous vivons désormais dans une ère ou règne la portabilitée notamment à travers les smart-

phones, en eﬀet ces petits appareils font désormais partie de notre quotidien, tant sur le plan

personnel que dans le domaine professionnel ou éducatif. C’est pour cela qu’une entreprise

telle que "Honoris United Universities" leader panafricain de l’enseignement supérieur privé

se doit d’avoir une application mobile pour leurs instituts aﬁn de se renforcer au niveau du

secteur mobile, une évolution qui est devenu nécessaire.

C’est dans ce cadre que s’eﬀectue notre projet qui consiste à développer une application

mobile native du portail étudiant "Myu".

1.3.1 Étude de l’existant

Avec la croissance exponentielle de la digitalisation et l’enseignement en ligne surtout

ces deux dernières années à cause de la soudaine crise du covid-19, nous réalisons qu’il est

important qu’un institut possède les bons outils pour bien mener une année universitaire

quelques soient les conditions.

il existe plusieurs outils qui répondent à ce besoin avec chaque institut disposant de son

propre portail étudiant comme par exemple le site "MYU" du groupe "Honoris United Uni-

versities" ou encore "Environnement numérique de travail" de l’UVT.

1.3.2 Critique de l’existant

Lors de notre étude menée sur les deux platformes mentionnées précédemment, nous

avons constaté qu’il y a un manque de ﬂexibilité notamment des interfaces qui se répètent

avec les mêmes couleurs et mêmes structures, une prise en charge seulement par navigateur

web et un manque total d’une application mobile. Ceci implique un manque d’intérêt envers

ces platformes.

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET

1.3.3 Solution proposée

Le but de ce projet est de proposer une solution consistante sous forme d’une application

mobile native qui permettera aux étudiants des instituts d’enseignement supérieur du groupe

"Honoris United Universities" de bénéﬁcier des avantages tels que :

— Une performance appropriée (optimisation du contenu et du temps de chargement)

— Un design moderne avec un "look and feel" adapté

— Un accès rapide et instantané aux fonctionnalités du portail.

— Utilisation des fonctionnalités du smartphone : photo, vidéo, GPS, push notiﬁcations,

stockage.

1.4 Méthodologie de développement

Pour assurer la bonne gestion d’un projet, il est indispensable de choisir une méthodologie

de gestion qui doit être d’une part, adaptée aux besoins évolutifs des utilisateurs et d’une

autre part, adaptée à la vitesse d’évolution des priorité ainsi que des besoins.

1.4.1 L’approche agile

La méthode agile caractérise un mode de gestion des projets informatiques privilégiant

le dialogue entre toutes les parties prenantes, clients, utilisateurs, développeurs et autres

professionnels du projet, la souplesse en cours de réalisation, la capacité à modiﬁer les plans

et la rapidité de livraison. Il s’agit de rompre avec les pratiques plus traditionnelles bien

trop rigides et trop exigeantes en matière de spéciﬁcations (contractuelles). Pour cela il

est important d’accorder la priorité au relationnel et à la communication étendue sur les

processus de développement.[3]

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET

1.4.2 La méthode SCRUM

Scrum est la méthodologie la plus utilisée parmi les méthodes Agiles existantes. Le terme

Scrum (qui signiﬁe mêlée) décrit une nouvelle approche plus rapide et ﬂexible pour le dé-

veloppement de nouveaux produits. Cette méthode est comparée au rugby, du fait que

l’équipe avance ensemble et soit toujours prête à réorienter le projet au fur-et-à mesure

de sa progression.[4]

Figure 1.2 – cycle de vie de la méthode SCRUM[5]

1.4.3 Principe de SCRUM

Évidemment, l’approche SCRUM suit les principes de la méthodologie Agile, c’est-à-dire

l’implication et la participation active du client tout au long du projet. SCRUM se compose

de plusieurs éléments fondamentaux :[4]

— Rôles

— évènements

— artefacts

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET

Répartition des rôles

— Scrum Master :

Il est responsable de la compréhension, de l’adhésion et de la mise en œuvre de la

méthode SRUM qu’il maîtrise parfaitement. Il veille à ce que les principes et les valeurs

de la méthodologie soient respectés.

— Product owner :

Il porte la vision du produit à réaliser. Il travaille en interaction avec l’équipe de

développement qui doit suivre ses instructions. C’est lui qui établit la priorité des

fonctionnalités à développer ou à corriger, et qui valide les fonctionnalités terminées.

Il est responsable de la gestion du Backlog produit.

— L’équipe de développement :

est chargée de transformer les besoins déﬁnis par le Product Owner en fonctionnalités

utilisables.

Les diﬀérents événements

— Le Sprint :

Un Sprint est une itération. Il s’agit d’une période de 2 à 4 semaines maximum pen-

dant laquelle une version terminée et utilisable du produit est réalisée. Un nouveau

sprint commence dès la ﬁn du précédent. Chaque sprint a un objectif et une liste de

fonctionnalités à réaliser.

— Planiﬁcation d’un Sprint :

Les tâches à accomplir pendant le Sprint sont déterminées par l’ensemble de l’équipe

Scrum lors de la réunion de planiﬁcation de Sprint.

— Revue du Sprint :

Il s’agit du bilan du Sprint réalisé. Une fois le Sprint terminé.

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET

Les artefacts

— Le Backlog produit :

liste hiérarchisée des exigences initiales du client concernant le produit à réaliser. Ce

document évolue sans cesse durant le projet, en fonction des besoins du client.

— Le Sprint backlog :

C’est le plan détaillé de la réalisation de l’objectif du Sprint, déﬁni lors de la réunion

de planiﬁcation du Sprint.

— L’incrément :

Il s’agit de l’ensemble des éléments terminés du product backlog pour le Sprint en cours,

ainsi que ceux des Sprints précédents. L’incrément doit fonctionner et être utilisable.

1.5 Conclusion

Ce chapitre était une introduction générale de notre projet avec la présentation de l’or-

ganisme d’accueil, le cadre général et la méthodologie de développement adaptée.

Chapitre 2

Sprint 0 : Planiﬁcation et architecture

2.1 Introduction

Ce chapitre sera basé sur les aspects techniques et

fonctionnels de notre projet. En eﬀet cette partie aura

pour but de nous initier aﬁn de comprendre l’architec-

ture, cerner les besoins fonctionnels et non fonction-

nels, identiﬁer les acteurs principaux et secondaires et

enﬁn alimenter notre Backlog produit pour découper

notre projet en sprints.

CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE

2.2 Analyse des besoins

Durant cette section, nous allons comprendre et identiﬁer les besoins à satisfaire du client

tout en représentant les fonctionnalité à intégrer dans notre application.

2.2.1 Description du contexte

Dans le cadre de ses activités estudiantine Honoris United Universities souhaite produire

une application mobile native intitulée MyU qui fera oﬃce d’un portail étudiant, cette der-

nière oﬀrira alors aux étudiants un accès plus facile et plus rapide aux ressources de leur

université.

2.3 Identiﬁcation des besoins fonctionnels et non fonc-

tionnels

Durant ce segment, nous allons identiﬁer les acteurs de notre application et cerner les

besoins fonctionnels et non fonctionnels.

2.3.1

Identiﬁcation des acteurs

Acteurs principaux :

Administrateur L’administrateur a pour mission de gérer toutes les fonctionnalités de

l’application. Il est aussi chargé d’intervenir lors de l’apparition de problèmes avec le compte

ou les informations d’un étudiant.

L’étudiant C’est l’utilisateur principal de notre application, celui autour duquel gravitent

toutes les fonctionnalités. En eﬀet il peut consulter et télécharger les ressources qu’oﬀre

l’application et proﬁter des services "Help desk".

CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE

2.3.2 Les besoins fonctionnels

Maintenant que nous avons identiﬁé les acteurs, il est temps de passer à l’étape suivante

qui consiste à cerner les besoins fonctionnels.

Les fonctionnalités de l’administrateur :

Gestion des étudiants

— L’administrateur peut consulter, créer, modiﬁer ou supprimer le proﬁl d’un étudiant.

Gestion des comptes utilisateur de l’application MyU

— L’administrateur peut consulter, créer, modiﬁer ou supprimer le compte d’un étudiant.

Gestion des services proposés par l’application Myu

— L’administrateur peut consulter ou modiﬁer un ticket enregistré par un étudiant.

Gestion des formations des étudiants inscrits à l’application MyU

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer une formations.

Gestion des groupes des étudiants inscrits à l’application MyU

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer un groupe.

Gestion des enseignants de l’application Myu

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer un enseignant.

Gestion de l’emploi du temps des étudiant inscrits à l’application MyU

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer une séance.

Gestion des épreuves des étudiant inscrits à l’application MyU

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer un examen

Gestion des notes et résultats des étudiants inscrits à l’application Myu

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer une note.

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer un résultat.

CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE

Gestion des absences des étudiants inscrits à l’application Myu

— L’administrateur peut consulter, ajouter, modiﬁer, supprimer l’absence d’un étudiant.

Gestion du plan d’étude des étudiant inscrits à l’application Myu

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer une spécialité.

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer un module.

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer une matière.

Gestion des cours en ligne des étudiants inscrits à l’application Myu

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer un cours.

Gestion des actualités de l’application Myu

— L’administrateur peut consulter, ajouter, modiﬁer ou supprimer une actualité.

Les besoins fonctionnels de l’étudiant :

Authentiﬁcation à l’application Myu

— Le système doit permettre à l’étudiant de s’authentiﬁer, tout en gardant ses données

sécurisées.

Gestion des proﬁls Myu

— Le système doit permettre à l’étudiant de consulter son proﬁl et modiﬁer ses para-

mètres.

— Le système doit permettre à l’étudiant de modiﬁer son mot de passe en cas d’oubli.

Consultation de l’emploi du temps

— Le système doit permettre à l’étudiant de consulter et télécharger son emploi du temps

en format PDF.

Consultation des enseignants

— Le système doit permettre à l’étudiant de consulter la liste de ses enseignants.

CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE

Consultation des épreuves

— Le système doit permettre à l’étudiant de consulter et télécharger son planning d’exa-

mens.

— Le système doit permettre à l’étudiant de consulter et télécharger ses convocations

d’examen.

Consultation des absences

— Le système doit permettre à l’étudiant de consulter et télécharger la liste des absences.

Consultation des cours en ligne

— Le système doit permettre à l’étudiant de consulter et télécharger ses cours.

Gestion des services Myu

— Le système doit permettre à l’étudiant de gérer ses tickets.

Consultation des actualités de l’application Myu

— Le système doit permettre à l’étudiant de consulter les actualités.

Réception de notiﬁcations lors d’un événement

— Le système doit permettre à l’étudiant de recevoir des notiﬁcations.

2.3.3 Les besoins non fonctionnels

Ce sont des besoins optionnels qui caractérisent le système en terme d’interopérabilité et

d’implementations, on note parmi eux :

Performance

— Il est primordial que l’application propose des temps de chargements rapides ne conte-

nant pas des crashes.

Sécurité

— L’application doit être sécurisée donc il faut veiller à respecter la conﬁdentialité de

Développement de l’application mobile du portail 'MyU'