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

Institut Sup rieur de Gestion de Tunis RAPPORT DE STAGE DE FIN D TUDES En vue
1/127
100%
Rendu du PDF...
Page 1 sur 127Lecteur de document UniversityLib

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

Institut Sup rieur de Gestion de Tunis RAPPORT DE STAGE DE FIN D TUDES En vue · Computer Science (Mobile Application Development) · textbook

Universit de Tunis

Institut Sup rieur de Gestion de Tunis

RAPPORT DE STAGE DE FIN D TUDES

En vue de lobtention du dipl me de

La licence fondamentale en informatique de gestion

D veloppement de lapplication mobile du portail "MyU"

Organisme daccueil :

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.

1

D dicace

A mes chers parents,

Merci pour vos sacrices 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 taime plus que les mots ne peuvent le dire.

A mes petites soeurs et petits fr res,

Merci davoir t le Jerry pendant les 17 derni res ann es de ma vie.

A ma grande Soeur Jamila,

Mon amie denfance et partenaire dans le crime qui g re toujours s chapper je taime

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

2

Remerciement

Cest 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

laboutissement de ce travail.

Nos remerciements sadressent 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.

Enn, nous tenons exprimer notre gratitude envers tous les enseignants de lISG Tunis.

3

Table des mati res

1 Contexte g n ral du projet

1.1

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

1.2 Pr sentation de lorganisme daccueil

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

1.3 Contexte et cadre du projet

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

1.3.1 tude de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.2 Critique de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.3

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

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

1.4.1 Lapproche agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

2 Sprint 0 : Planication et architecture

2.1

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

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

2.2.1 Description du contexte

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

2.3

Identication des besoins fonctionnels et non fonctionnels . . . . . . . . . . .

2.3.1

Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.2 Les besoins fonctionnels

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

15

15

16

16

17

17

18

18

18

19

19

21

22

22

23

23

23

23

24

4

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 dutilisation global . . . . . . . . . . . . . . . . . . . . . .

2.7 Architecture de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 dutilisation global du Sprint 1 . . . . . . . . . . .

3.3.2 Ranement du cas dutilisation "SAuthentier" . . . . . . . . . . . .

3.3.3 Description textuelle du cas dutilisation "sauthentier" . . . . . . .

3.3.4 Ranement du cas dutilisation "G rer etudiants" . . . . . . . . . . .

3.3.5 Ranement du cas dutilisation "G rer comptes" . . . . . . . . . . .

3.3.6 Ranement cas dutilisation "G rer prol" . . . . . . . . . . . . . . .

3.3.7 Ranement du cas dutilisation "G rer groupes"

. . . . . . . . . . .

3.3.8 Ranement du cas dutilisation "G rer formations" . . . . . . . . . .

3.3.9 Prototype dinterfaces

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

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

5

26

28

30

31

32

32

33

33

34

34

35

37

37

38

39

40

Advertisement

40

41

43

43

44

45

3.4.1 Diagramme de classe de conception du cas dutilisation "SAuthentier" 45

3.4.2 Diagramme de s quence d taill du cas dutilisation "SAuthentier"

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

46

47

3.4.4 Diagramme de s quence d taill du cas dutilisation "Ajouter etudiant" 48

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

49

TABLE DES MATI RES

6

3.4.6 Diagramme de s quence d taill du cas dutilisation "Cr er compte" .

50

3.4.7 Diagramme de s quence d taill du cas dutilisation "Consulter compte" 51

3.4.8 Diagramme de classe de conception "G rer prol" . . . . . . . . . . .

3.4.9 Diagramme de s quence d taill du cas dutilisation "Consulter prol"

3.4.10 Diagramme de classe de conception "G rer groupes"

. . . . . . . . .

3.4.11 Diagramme de s quence d taill du cas dutilisation "Cr er groupe" .

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

52

52

54

55

56

3.4.13 Diagramme de s quence d taill du cas dutilisation "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 Authentication et s curit

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

3.5.3 Notications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 dutilisation du Sprint 2 . . . . . . . . . . . . . . .

4.3.2 Ranement du cas dutilisation "G rer plan d tude" . . . . . . . . .

4.3.3 Ranement du cas dutilisation "G rer enseignants" . . . . . . . . .

4.3.4 Description textuelle du cas dutilisation "Consulter enseignants" . .

4.3.5 Ranement du cas dutilisation "G rer emploi du temps"

. . . . . .

4.3.6 Description textuelle du cas dutilisation "Consulter emploi du temps"

4.3.7 Ranement du cas dutilisation "G rer cours en ligne" . . . . . . . .

4.3.8 Description textuelle du cas dutilisation "Consulter cours en ligne" .

58

59

59

60

61

62

63

64

64

65

66

66

67

68

69

70

71

72

73

TABLE DES MATI RES

4.3.9 Prototype dinterfaces

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

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

5.1

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

5.2 Sprint Backlog

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

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

5.3.1 Diagramme de cas dutilisation du sprint 3 . . . . . . . . . . . . . . .

5.3.2 Ranement du cas dutilisation "G rer tickets" . . . . . . . . . . . .

5.3.3 Description textuelle du cas dutilisation "Enregistrer ticket" . . . . .

5.3.4 Ranement du cas dutilisation "G rer examens" . . . . . . . . . . .

7

74

75

75

76

78

80

81

82

84

85

85

87

88

89

89

90

92

92

93

94

95

5.3.5 Description textuelle de cas dutilisation "Consulter planning examens" 96

5.3.6 Ranement du cas dutilisation "G rer absences" . . . . . . . . . . .

5.3.7 Ranement du cas dutilisation "G rer notes et r sultats" . . . . . .

5.3.8 Ranement du cas dutilisation "G rer actualites" . . . . . . . . . .

97

98

99

5.3.9 Prototype dinterfaces

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

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

TABLE DES MATI RES

8

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

Advertisement

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 dutilisation global . . . . . . . . . . . . . . . . . . . . . .

2.4 Architecture de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Diagramme de cas dutilisation Sprint 1 . . . . . . . . . . . . . . . . . . . . .

3.2 Diagramme de cas dutilisation du cas "sAuthentier" . . . . . . . . . . . .

3.3 Diagramme de cas dutilisation ran "G rer etudiants" . . . . . . . . . . .

3.4 Diagramme de cas dutilisation ran "G rer comptes" . . . . . . . . . . . .

3.5 Diagramme de cas dutilisation Ran "G rer prol" . . . . . . . . . . . . .

3.6 Diagramme de cas dutilisation ran "G rer groupes" . . . . . . . . . . . .

3.7 Diagramme de cas dutilisation ran "G rer formations" . . . . . . . . . .

3.8 Maquettes dinterfaces du Sprint 1

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

3.9 Diagramme de classe de conception "sAuthentier" . . . . . . . . . . . . . .

3.10 Diagramme de s quence d taill "sAuthentier" . . . . . . . . . . . . . . . .

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

16

19

27

30

31

32

37

38

40

40

41

43

43

44

45

46

47

48

49

9

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 prol" . . . . . . . . . . . . . . . . .

3.17 Diagramme de s quence d taill "Consulter prole . . . . . . . . . . . . . . .

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 lauthentication par le serveur

. . . . . . . . . .

3.25 R ception des notications . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

4.1 Diagramme de cas dutilisation du Sprint 2 . . . . . . . . . . . . . . . . . . .

4.2 Diagramme de cas dutilisation ran "G rer plan d tude" . . . . . . . . .

4.3 Diagramme de cas dutilisation ran "G rer enseignants" . . . . . . . . . .

4.4 Diagramme de cas dutilisation ran "G rer emploi du temps" . . . . . . .

4.5 Diagramme de cas dutilisation ran "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 dutilisation "Lister chiers" . . . . .

4.9 Diagramme de s quence d taill du cas dutilisation "Consulter cours" . . . .

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

4.11 Diagramme de s quence d taill du cas dutilisation "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 . . . . . . . . . . . . . . . . . . . . . .

10

50

51

52

53

54

55

56

57

58

59

60

61

62

66

67

68

70

72

74

75

77

79

80

81

83

84

86

TABLE DES FIGURES

11

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

87

5.1 Diagramme de cas dutilisation du Sprint 3 . . . . . . . . . . . . . . . . . . .

5.2 Diagramme de cas dutilisation "G rer tickets" . . . . . . . . . . . . . . . . .

5.3 Diagramme de cas dutilisation "G rer examens" . . . . . . . . . . . . . . . .

5.4 Diagramme de cas dutilisation "G rer absences"

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

5.5 Diagramme de cas dutilisation "G rer les notes et r sultats" . . . . . . . . .

5.6 Diagramme de cas dutilisation "G rer actualites" . . . . . . . . . . . . . . .

92

93

95

97

98

99

5.7 Maquettes dinterfaces 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 dutilisation "Lister tickets" . . . . . 102

5.10 Diagramme de s quence d taill du cas dutilisation "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

Advertisement

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

29

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

3.2 Description textuelle du cas "Sauthentier" . . . . . . . . . . . . . . . . . .

3.3 Description textuelle du cas "Consulter prol" . . . . . . . . . . . . . . . . .

3.4 Description textuelle du cas "Modier prol" . . . . . . . . . . . . . . . . . .

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

36

39

41

42

65

69

71

73

91

94

94

96

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

12

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 dinteragir avec les clients, partenaires et salari s ainsi qu la facilit dacc der

linformation depuis sa poche. Il est alors totalement logique destimer 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 dentreprises optent aujourdhui pour une

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

Lint gration du d veloppement dapplications mobiles une strat gie plus large bas e sur

des micros services cloud-native ore 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. Cest dans ce domaine que sint gre notre projet de n d tude qui est le

d veloppent dune application mobile qui consiste d velopper une application mobile

native qui aura pour but de permettre aux tudiants des tablissements dHonoris United

Universities dacc der leurs informations scolaires.

Ce rapport est reparti en 7 chapitres :

Le premier chapitre sera consacr une introduction g n rale de lorganisme dac-

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

ment.

13

LISTE DES TABLEAUX

14

Le second chapitre pr sentera lanalyse des besoins, Identication 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 oce de pr sentation de lenvironnement de d veloppement

de notre application.

Et enn, 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 dun aper u

du projet. Il englobera une pr sentation de lorga-

nisme daccueil ainsi que le cadre g n ral de notre

projet. Ensuite nous passerons l tude de lexistant

suivi de sa critique, puis nous nirons par proposer

notre solution.

15

CHAPITRE 1. CONTEXTE G N RAL DU PROJET

16

1.2 Pr sentation de lorganisme daccueil

Figure 1.1 Logo de Honoris

Honoris United Universities est le premier r seau panafricain denseignement sup rieur

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

davoir un impact sur leurs soci t s et leurs conomies dans un monde globalis .

Avec 32 000 tudiants, r partis sur 58 campus, centres dapprentissage 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 lIng nierie, de lIT, du Business, du Droit, de

lArchitecture, des Arts et du Design, des M dias, de lEducation 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 dop rer avec succ s

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

capables dinuencer les conomies et les communaut s de demain.[2]

1.3 Contexte et cadre du projet

Ce projet sinscrit dans le cadre dun projet de n d tudes pour lobtention du dipl me

de la licence fondamentale en informatique de gestion de linstitut sup rieur de gestion de

Tunis.

CHAPITRE 1. CONTEXTE G N RAL DU PROJET

17

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

phones, en eet ces petits appareils font d sormais partie de notre quotidien, tant sur le plan

personnel que dans le domaine professionnel ou ducatif. Cest pour cela quune entreprise

telle que "Honoris United Universities" leader panafricain de lenseignement sup rieur priv

se doit davoir une application mobile pour leurs instituts an de se renforcer au niveau du

secteur mobile, une volution qui est devenu n cessaire.

Cest dans ce cadre que seectue notre projet qui consiste d velopper une application

mobile native du portail tudiant "Myu".

1.3.1 tude de lexistant

Avec la croissance exponentielle de la digitalisation et lenseignement en ligne surtout

ces deux derni res ann es cause de la soudaine crise du covid-19, nous r alisons quil est

important quun 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 lUVT.

1.3.2 Critique de lexistant

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

avons constat quil 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 dune application mobile. Ceci implique un manque dint r t envers

ces platformes.

CHAPITRE 1. CONTEXTE G N RAL DU PROJET

18

1.3.3 Solution propos e

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

mobile native qui permettera aux tudiants des instituts denseignement 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 notications,

stockage.

1.4 M thodologie de d veloppement

Pour assurer la bonne gestion dun projet, il est indispensable de choisir une m thodologie

de gestion qui doit tre dune part, adapt e aux besoins volutifs des utilisateurs et dune

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

1.4.1 Lapproche 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 modier les plans

et la rapidit de livraison. Il sagit de rompre avec les pratiques plus traditionnelles bien

Advertisement

trop rigides et trop exigeantes en mati re de sp cications (contractuelles). Pour cela il

est important daccorder la priorit au relationnel et la communication tendue sur les

processus de d veloppement.[3]

CHAPITRE 1. CONTEXTE G N RAL DU PROJET

19

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 signie 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, lapproche SCRUM suit les principes de la m thodologie Agile, cest- -dire

limplication 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

20

R partition des r les

Scrum Master :

Il est responsable de la compr hension, de ladh sion et de la mise en Suvre de la

m thode SRUM quil 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. Cest 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 sagit dune 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.

Planication dun Sprint :

Les t ches accomplir pendant le Sprint sont d termin es par lensemble de l quipe

Scrum lors de la r union de planication de Sprint.

Revue du Sprint :

Il sagit du bilan du Sprint r alis . Une fois le Sprint termin .

CHAPITRE 1. CONTEXTE G N RAL DU PROJET

21

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 :

Cest le plan d taill de la r alisation de lobjectif du Sprint, d ni lors de la r union

de planication du Sprint.

Lincr ment :

Il sagit de lensemble des l ments termin s du product backlog pour le Sprint en cours,

ainsi que ceux des Sprints pr c dents. Lincr 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 lor-

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

Chapitre 2

Sprint 0 : Planication et architecture

2.1 Introduction

Ce chapitre sera bas sur les aspects techniques et

fonctionnels de notre projet. En eet cette partie aura

pour but de nous initier an de comprendre larchitec-

ture, cerner les besoins fonctionnels et non fonction-

nels, identier les acteurs principaux et secondaires et

enn alimenter notre Backlog produit pour d couper

notre projet en sprints.

22

CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE

23

2.2 Analyse des besoins

Durant cette section, nous allons comprendre et identier 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 oce dun portail tudiant, cette der-

ni re orira alors aux tudiants un acc s plus facile et plus rapide aux ressources de leur

universit .

2.3 Identication des besoins fonctionnels et non fonc-

tionnels

Durant ce segment, nous allons identier les acteurs de notre application et cerner les

besoins fonctionnels et non fonctionnels.

2.3.1

Identication des acteurs

Acteurs principaux :

Administrateur Ladministrateur a pour mission de g rer toutes les fonctionnalit s de

lapplication. Il est aussi charg dintervenir lors de lapparition de probl mes avec le compte

ou les informations dun tudiant.

L tudiant Cest lutilisateur principal de notre application, celui autour duquel gravitent

toutes les fonctionnalit s. En eet il peut consulter et t l charger les ressources quore

lapplication et proter des services "Help desk".

CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE

24

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

Gestion des tudiants

Ladministrateur peut consulter, cr er, modier ou supprimer le prol dun tudiant.

Gestion des comptes utilisateur de lapplication MyU

Ladministrateur peut consulter, cr er, modier ou supprimer le compte dun tudiant.

Gestion des services propos s par lapplication Myu

Ladministrateur peut consulter ou modier un ticket enregistr par un tudiant.

Gestion des formations des tudiants inscrits lapplication MyU

Ladministrateur peut consulter, ajouter, modier ou supprimer une formations.

Gestion des groupes des tudiants inscrits lapplication MyU

Ladministrateur peut consulter, ajouter, modier ou supprimer un groupe.

Gestion des enseignants de lapplication Myu

Ladministrateur peut consulter, ajouter, modier ou supprimer un enseignant.

Gestion de lemploi du temps des tudiant inscrits lapplication MyU

Ladministrateur peut consulter, ajouter, modier ou supprimer une s ance.

Gestion des preuves des tudiant inscrits lapplication MyU

Ladministrateur peut consulter, ajouter, modier ou supprimer un examen

Gestion des notes et r sultats des tudiants inscrits lapplication Myu

Ladministrateur peut consulter, ajouter, modier ou supprimer une note.

Ladministrateur peut consulter, ajouter, modier ou supprimer un r sultat.

CHAPITRE 2. SPRINT 0 : PLANIFICATION ET ARCHITECTURE

25

Gestion des absences des tudiants inscrits lapplication Myu

Ladministrateur peut consulter, ajouter, modier, supprimer labsence dun tudiant.

Gestion du plan d tude des tudiant inscrits lapplication Myu

Ladministrateur peut consulter, ajouter, modier ou supprimer une sp cialit .

Ladministrateur peut consulter, ajouter, modier ou supprimer un module.

Ladministrateur peut consulter, ajouter, modier ou supprimer une mati re.

Gestion des cours en ligne des tudiants inscrits lapplication Myu

Ladministrateur peut consulter, ajouter, modier ou supprimer un cours.

Gestion des actualit s de lapplication Myu

Ladministrateur peut consulter, ajouter, modier ou supprimer une actualit .

Les besoins fonctionnels de l tudiant :

Authentication lapplication Myu

Le syst me doit permettre l tudiant de sauthentier, tout en gardant ses donn es

s curis es.

Gestion des prols Myu

Le syst me doit permettre l tudiant de consulter son prol et modier ses para-

m tres.

Le syst me doit permettre l tudiant de modier son mot de passe en cas doubli.

Consultation de lemploi 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.

CHAPI...