mémoire de stage fin d'étude présenté en vue de l'obtention du diplôme de mastère professionnel spécialité service web et multimédia
Réalisé par: Ibtihel El Bache
Supervisé par: Mme Maha Harzallah
Année universitaire 2018 - 2019
Email: bacheibtihel@gmail.com
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
1. i
Remerciements
Je tiens, avant de présenter mon travail, à exprimer notre grande reconnaissance envers les
personnes qui m’ont, de près ou de loin, apporté leurs soutiens. Qu’ils trouvent ici
collectivement et individuellement l’expression de toute ma gratitude.
Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance à
Monsieur Mr. Taki Eddine BEN MESSAOUD pour l’expérience enrichissante et pleine
d’intérêt qu’il m’a fait
vivre durant la période du stage et pour tous les conseils et les informations qu’il m’a
prodigués.
À Mme Maha HARZALLAH
Je tiens à remercier vivement mon encadrante académique, pour son aide précieuse, ses conseils
judicieux, pour le temps qu’elle m’a consacré tout au long de la période du travail, répondant
avec bienveillance à toutes nos interrogations.
Aux membres du jury
Je tiens finalement à remercier vivement les membres du jury qui m’ont fait l’honneur de juger
ce travail, et j’espère qu’il sera à la hauteur de la confiance qu’ils m’ont accordée.
Je serai attentive à toutes leurs critiques et leurs conseils.
2. ii
Dédicaces
À ma chère mère
Aucune dédicace ne saurait être assez éloquente pour exprimer ce que tu mérites pour tous
les sacrifices que tu n’as cessé de me donner depuis ma naissance, je te dédie ce travail en
témoignage de mon profond amour. Puisse Dieu, le tout puissant, te préserver et t’accorder
santé, longue vie et bonheur.
À mon cher père
Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et le respect que j’ai
toujours eu pour vous. Rien au monde ne vaut les efforts fournis jour et nuit pour mon
éducation. Ce travail est le fruit de tes sacrifices que tu as consentis pour mon éducation.
À mon très cher frère Mohamed Ali et ma sœur Arij
Je témoigne mes sincères reconnaissances pour les efforts qu’ils m’ont consentis chaque fois que
j’en avais besoin, je leur dédie ce modeste travail.
À mes enseignants
Depuis le primaire jusqu’aujourd’hui, en reconnaissance de leur encouragement infini pour
avancer dans mes études, à eux je dédie tout ce travail comme preuve de ma reconnaissance.
À ma grande famille
Pour leur aide et leur soutien moral durant l’élaboration de ce travail.
À mes chers amis
À tous ceux que j’aime et à tous ceux que m’aiment
À tous ceux dont l’oubli du nom n’est pas celui du cœur.
3. Table des matières
iii
Table des matières
Introduction générale...................................................................................................................1
Chapitre 1 : APERÇU GÉNÉRAL ET CADRE DU PROJET ............................................3
Introduction .............................................................................................................................3
1.1 Organisme d’accueil.................................................................................................4
1.1.1 Présentation générale de la société Taki Academy..........................................4
1.1.2 Les services de la société TakiAcademy .........................................................4
1.2 Problématique...........................................................................................................5
1.3 Étude de l’existant ....................................................................................................5
1.3.1 Les applications existantes...............................................................................6
1.3.2 Critique de l’existant........................................................................................7
1.4 Solutions proposées ..................................................................................................7
1.5 Méthodologie agile...................................................................................................7
1.5.1 Présentation de SCRUM..................................................................................8
1.6 Langage de modélisation UML ..............................................................................10
Conclusion.............................................................................................................................10
Chapitre 2 : PLANIFICATION ET ARCHITECTURE....................................................11
Introduction ...........................................................................................................................11
2.1 Capture des besoins ................................................................................................12
2.1.1 Identification des acteurs ...............................................................................12
2.1.2 Identification des besoins...............................................................................12
2.2 Pilotage du projet avec scrum.................................................................................13
2.2.1 Identification de l’équipe scrum ....................................................................13
2.2.2 Le backlog du produit ....................................................................................14
4. Table des matières
iv
2.2.3 Planification des Sprints ................................................................................16
2.2.4 Sprint 0 : Mise en place du projet ..................................................................16
2.2.5 Diagramme des cas d’utilisation globale .......................................................17
2.3 Conception graphique..............................................................................................17
2.3.1 Synopsis .........................................................................................................17
2.3.2 Charte graphique............................................................................................18
2.3.3 Prototypage des interfaces .............................................................................18
2.3.4 Choix des couleurs.........................................................................................18
2.4 Environnement de travail........................................................................................19
2.4.1 Environnement matériel.................................................................................19
2.4.2 Environnement logiciel..................................................................................20
2.4.3 Choix technologiques.....................................................................................21
2.4.4 Le système de gestion de versions GIT .........................................................22
2.5 Architecture générale de l’application....................................................................24
2.5.1 Choix de l’architecture de l’application.........................................................24
2.5.2 Spécification de l’architecture .......................................................................25
2.6 Diagramme de déploiement....................................................................................26
Conclusion.............................................................................................................................27
Chapitre 3 : GESTION DES PROFILS ET GESTION DES MATIÈRES...................28
Introduction ...........................................................................................................................28
3.1 Sprint 1 : Gestion des profils ..................................................................................29
3.1.1 Backlog de sprint 1 ........................................................................................29
3.1.2 Spécification fonctionnelle ............................................................................29
3.1.3 Conception.....................................................................................................31
3.1.4 Réalisation et interprétation ...........................................................................34
3.1.5 Test.................................................................................................................38
3.2 Sprint 2 : Gestion des matières...............................................................................39
3.2.1 Backlog de sprint 2 ........................................................................................39
3.2.2 Spécification fonctionnelle ............................................................................40
3.2.3 Conception.....................................................................................................41
3.2.4 Réalisation et interprétation ...........................................................................43
3.2.5 Test.................................................................................................................46
Conclusion.............................................................................................................................46
5. Table des matières
v
Chapitre 4 : GESTION DES QUIZS ET GESTION DES EXAMENS .............................47
Introduction ...........................................................................................................................47
4.1 Sprint 3 : Gestion des quizs ....................................................................................48
4.1.1 Backlog de sprint 3 ........................................................................................48
4.1.2 Spécification fonctionnelle ............................................................................49
4.1.3 Conception.....................................................................................................50
4.1.4 Réalisation et interprétation ...........................................................................52
4.1.5 Test.................................................................................................................53
4.2 Sprint 4 : Gestion des examens................................................................................53
4.2.1 Backlog de sprint 4 ........................................................................................53
4.2.2 Spécification fonctionnelle ............................................................................54
4.2.3 Conception.....................................................................................................56
4.2.4 Réalisation et interprétation ...........................................................................58
4.2.5 Test.................................................................................................................59
Conclusion.............................................................................................................................59
Conclusion générale et perspectives......................................................................................60
Webographies..........................................................................................................................61
Bibliographies..........................................................................................................................62
Annexe......................................................................................................................................63
6. Liste des figures
vi
Liste des figures
Figure 01: Logo Taki Academy......................................................................................................4
Figure 02: Cycle de vie de la méthodologie Scrum........................................................................9
Figure 03: Tableau Trello.............................................................................................................10
Figure 04: Diagramme cas d'utilisation globale ...........................................................................17
Figure 05: Color tools...................................................................................................................19
Figure 06: Architecture de React Native ......................................................................................23
Figure 07: Architecture générale de l’application ........................................................................25
Figure 08: Le modèle MVC..........................................................................................................26
Figure 09: Diagramme de déploiement ........................................................................................27
Figure 10: Diagramme de cas d'utilisation globale sprint 1 .........................................................30
Figure 11: Diagramme de séquence « S’authentifier » ................................................................32
Figure 12: Diagramme de l’activité « Authentification ».............................................................33
Figure 13: Écran de démarrage.....................................................................................................34
Figure 14: Écran de connexion.....................................................................................................34
Figure 15: Alerte de connexion ....................................................................................................35
Figure 16: Interface de connexion................................................................................................35
Figure 17: Interface mot de passe oublié......................................................................................36
Figure 18: Interface profile...........................................................................................................37
Figure 19: Diagramme de cas d'utilisation globale de Sprint 2....................................................40
Figure 20: Diagramme de séquence « Rechercher une leçon »....................................................41
Figure 21: Consulter la liste des matières.....................................................................................42
Figure 22: Diagramme d'activité « Rechercher leçon » ...............................................................42
Figure 23: Interface matière..........................................................................................................43
Figure 24: Interface chapitres.......................................................................................................44
Figure 25: Interface résumé..........................................................................................................44
Figure 26: Interface Recherche.....................................................................................................45
Figure 27: Diagramme de cas d'utilisation globale Sprint 3.........................................................49
Figure 28: Diagramme de séquence remplir le quiz.....................................................................51
Figure 29: Diagramme de séquence refaire le quiz ......................................................................52
7. Liste des figures
vii
Figure 30: Interface quiz...............................................................................................................52
Figure 31: Diagramme de cas d'utilisation globale Sprint 4.........................................................54
Figure 32: Diagramme de séquence « Consulter la note »...........................................................56
Figure 33: Diagramme de séquence système « Scanner la copie »..............................................57
Figure 34: Interface examen.........................................................................................................58
8. Liste des tableaux
viii
Liste des tableaux
Tableau 01: Les acteurs de notre système ....................................................................................12
Tableau 02: Backlog produit ........................................................................................................15
Tableau 03: Planification des sprints............................................................................................16
Tableau 04: Backlog de Sprint 0 ..................................................................................................16
Tableau 05: React native vs mobile native...................................................................................22
Tableau 06: Points positifs et négatifs de react native..................................................................24
Tableau 07: Backlog de Sprint 1 ..................................................................................................29
Tableau 08 : Tableau descriptif de cas d'utilisation « S'authentifier » .........................................31
Tableau 09: Tableau descriptif de cas d'utilisation « Consulter les informations de profil ».......31
Tableau 10: Liste des APIs utilisées.............................................................................................38
Tableau 11: Tests..........................................................................................................................38
Tableau 12: Backlog de Sprint 2 ..................................................................................................39
Tableau 13: Tableau descriptif de cas d'utilisation « Rechercher une matière ».........................41
Tableau 14: APIs utilisées ............................................................................................................45
Tableau 15: Tests..........................................................................................................................46
Tableau 16: Backlog de Sprint 3 ..................................................................................................48
Tableau 17: Tableau descriptif de cas d'utilisation « Remplir quiz »...........................................50
Tableau 18: Tableau descriptif de cas d'utilisation « Refaire quiz »............................................50
Tableau 19: Tests..........................................................................................................................53
Tableau 20: Backlog de sprint 4...................................................................................................54
Tableau 21: Tableau descriptif de cas d'utilisation « Scanner copie ».........................................55
Tableau 22: Tableau descriptif de cas d'utilisation « Consulter la note » ....................................56
Tableau 23: APIs utilisées ............................................................................................................58
Tableau 24: Tests..........................................................................................................................59
9. Liste des acronymes
ix
Liste des acronymes
API : Application Programming Interface
UML : Unified Modeling Language
StarUML : Star Unified Modeling Language
HTTP : Hypertext Transfer Protocol
MVC: Model View Controller
IHM: Interface Homme Machine
DB: Data Base
UI: User Interface
UX: User Experience
10. Introduction générale
1
Introduction générale
De nos jours, nous vivons dans la révolution de l’e-learning qui se définit par l’utilisation
des nouvelles techniques et méthodes numériques pour permettre l’apprentissage à distance.
Plus concrètement, l’e-learning est un mode d’éducation via Internet mettant à disposition des
apprenants des contenus pédagogiques. Ainsi il n’est pas nécessaire de se déplacer au sein d’un
centre de formation, donc l’étudiant peut suivre le cours depuis n’importe quel lieu et à n’importe
quelle heure.
L’e-learning est aujourd’hui le résultat de la transformation digitale qui a touché
l’ensemble des secteurs d’activités ces dernières années, avec notamment la digitalisation des
secteurs de l’éducation et la formation dans notre pays..
Le marché du mobile connaît une extension folle ces dernières années. Certes que le mobile
a changé la donne sur le marché du web. Depuis 2015, le « Smart phone » est au cœur de toutes
les utilisations, car il nous accompagne du matin jusqu’au soir. Nous n’utilisons plus nos
téléphones intelligents pour téléphoner ou pour une affaire privée seulement, ça peut avoir une
vision professionnelle.
Alors qui dit smartphone dit application mobile. Et les applications sont bel et bien au cœur
de cette révolution, car elles nous offrent des fonctionnalités innovantes et pratiques. Ainsi nous
n’avons plus besoin de chercher sur le web, car les applications mobiles sont adaptées,
personnalisées et répondent à n’importe quel besoin dans un temps record. D’ailleurs les
applications représentent aujourd’hui 89% du temps passé sur mobile, comparé à 11% restant pour
la navigation sur le web.
Dans ce cadre Taki Academy se stabilise comme première plateforme d’éducation en ligne
en Tunisie offrant aux élèves du primaire jusqu’au Baccalauréat un support éducatif très consistant
contenant généralement des documents de formation sur des supports en ligne qui peuvent se
présenter sous différentes formes : Vidéo, PDF, quizs, etc.
11. Introduction générale
2
Le présent rapport vient de couronner un projet réalisé durant cinq mois et demi, il est organisé
comme suit :
La première partie, intitulée « Aperçu général et cadre du projet » sera destinée à la mise
de notre projet dans son contexte général. En premier lieu, nous présenterons la société
d’accueil Taki Academy. Ensuite, la seconde partie est consacrée à l’analyse de l’existant
en étudiant les procédures actuelles et relevant les manques et les insuffisances ainsi qu’à
la solution convenable offerte par notre projet, et pour finir nous le clôturerons par la
méthode de travail à utiliser pour élaborer notre application.
Le deuxième chapitre « Planification et architecture » qui présente le cadre
méthodologique SCRUM. Il expose les besoins fonctionnels et non fonctionnels ainsi que
outils de conception, de développement et les technologies adoptées lors de
l’implémentation...
Le troisième et le quatrième présentent les « releases » de notre projet « Gestion des profils
et gestion des matières » et derniers chapitre « Gestion des quizs et gestion des examens »
en respectant les principes fondamentaux de SCRUM..
Finalement, ce rapport est clôturé par une conclusion générale dans laquelle nous
évaluerons le travail réalisé..
12. Chapitre 1 : Aperçu général et cadre du projet
3
Chapitre 1
APERÇU GÉNÉRAL ET CADRE
DU PROJET
Introduction
ans ce chapitre, on tient à exposer, en premier lieu, le cadre général du projet par la
présentation de l’organisme d’accueil, ses secteurs d’activité et de son historique.
Ensuite, nous allons présenter, le contexte du projet ainsi que les différents facteurs qui ont
suscité le besoin de notre projet et qui ont lui mené à dégager la solution proposée.
.
D
13. Chapitre 1 : Aperçu général et cadre du projet
4
1.1 Organisme d’accueil
Dans cette section nous allons présenter l’entreprise Taki Academy et ses différents
secteurs d’activité.
1.1.1 Présentation générale de la société Taki Academy
TakiAcademy est une société fondée en 2013 spécialisée dans l’éducation en ligne. Son
objectif est le développement web et mobile de son propre plateforme d’enseignement en ligne
en adoptant plusieurs technologies. En effet, l’entreprise est formée d’une équipe compétente
et créative d’experts dans la conception et la réalisation d’un concept éducatif en offrant à ses
clients les meilleurs accès d’apprentissage en ligne.
En effet, la plateforme Taki Academy est considérée comme la première plateforme
d'enseignement en ligne en Tunisie, elle contient plus que 180 enseignants et 45000 élèves. Elle
enseigne les élèves de la 5ème année primaire jusqu'aux cycle préparatoire à l’ingénierie.
La figure suivante présente le logo de TakiAcademy :
1.1.2 Les services de la société TakiAcademy
TakiAcademy à l'expérience, les ressources et les bases pour fournir des services qui
répondent aux besoins des clients de la plateforme. La société est basée sur quatre secteurs de
services :
Pôle web : Une équipe des experts de multiples compétences est concentrée sur le
développement de site web TakiAcademy et ses différentes fonctionnalités et maintient
sa sécurité. .
Figure 01: Logo Taki Academy
14. Chapitre 1 : Aperçu général et cadre du projet
5
Pôle mobile : Ce pôle est caractérisé par sa créativité, son expérience et son innovation.
Son objectif est de développer des applications visées pour l’utilisation du mobile
(Android, iOS).
Pôle marketing : Consiste à concevoir l'offre des produits de TakiAcademy en fonction
de l'analyse des clients. Également, il étudie le marché et l’analyse afin d’en extraire un
plan stratégique.
Pôle Editing : Il est composé par les professeurs et les inspecteurs qui créent le contenu
et contrôlent sa compatibilité avec le système éducatif tunisien. Ce contenu est sous
forme des vidéos de cours, des vidéos, d’exercices, des examens d’évaluation, des
quizes et des magazines.
Pôle Contrôle Qualité : Ce service veille à contrôler la qualité de contenu réalisé par
le service "Editing" et sa compatibilité avec la charte production et design imposé par
TakiAcademy. Également, ce service veille à collecter le feedback des élèves abonnés
afin de développer la qualité des services produits par TakiAcademy.
1.2 Problématique
TakiAcademy offre des vidéos de cours et des séances d’enseignement directes pour les
élèves. Mais ce qui manque c’est l’évaluation. En effet, l’évaluation doit être faite dans les
mêmes conditions des devoirs passés dans les établissements d’enseignement.
Dans cette perspective, TakiAcademy souhaite exploiter cette opportunité afin de créer
une solution. Réservée pour les matières principales, chaque matière est composée de chapitres,
de résumés, de quizs, d’exercices et de devoirs de durées précises et limitées dans le temps.
Une fois réalisés, les devoirs doivent être envoyés à l’aide d’une l’application mobile
au professeur correcteur qui est inconnu par l’élève.
La correction est immédiatement envoyée avec barème, mais une correction personnalisée à
chaque élève sera envoyée dans un délai de 24 heures accompagnée de la note obtenue.
1.3 Étude de l’existant
L’étude de l’existant est une phase importante pour bien comprendre le système actuel,
définir ses objectifs et dégager les problématiques et les vrais besoins de l’entreprise.
15. Chapitre 1 : Aperçu général et cadre du projet
6
1.3.1 Les applications existantes
OpenClassrom
OpenClassrom est une école en ligne qui propose à ses
membres des cours certifiants et des parcours
débouchants sur un métier d'avenir, réalisé en interne,
par des écoles, des universités, ou encore par des
entreprises partenaires comme Microsoft ou IBM.
Linkedin Learning
Linkedin Learning est une plateforme pédagogique en
ligne qui vous permet de découvrir et de développer des
compétences commerciales, créatives et en rapport avec
les technologies par le biais de vidéos de cours
dispensés par des experts. .
CamScanner
CamScanner est une application mobile qui permet de
transformer un téléphone en un scanner portable. Le
principe est simple, vous capturez vos documents tels
que notes, livres, factures, etc.., avec votre appareil
photo, et CamScanner s'occupe du reste. Il est en
mesure de rogner automatiquement l'image et améliorer
sa qualité. Et ce n'est pas tout, vous pouvez ensuite
exporter vos captures de documents en format PDF….
16. Chapitre 1 : Aperçu général et cadre du projet
7
1.3.2 Critique de l’existant
La plateforme prépare des vidéos de cours de haute qualité et d’excellent contenu selon
les avis des experts du domaine d’enseignement, cependant, cette dernière ne peut pas garantir
l’évaluation des élèves, car elle doit être faite dans les mêmes conditions des devoirs passés
dans les établissements d’enseignement.
De plus, si on prend OpenClassrom cette application fonctionne seulement sur IOS, elle
n’existe pas sur les autres plateformes.
Et enfin, chaque application présentée ci-dessus offre un service, ces services ne sont
pas centralisés sur une même application.
1.4 Solutions proposées
Cependant, nous proposons dans notre application la possibilité d’évaluer les élèves, ainsi
que la consultation des différents cours et résumés par matières et par chapitres en consultant
les niveaux de difficultés associées, le passage des quiz comme un simple test qui va permettre
à l’élève de passer les examens comme à l’école si les conditions des tests sont respectées.
Notre application exige que l’examen soit scanné dans un délai bien déterminé, suite à ça une
correction va être ajouté au compte de l’élève.
En fait, après une analyse approfondie de l’existant sur le marché et en se basant sur
ses limites, nous nous sommes orientés vers la conception et le développement d’une
application mobile sous différentes plateformes qui regroupent un ensemble de services dédié
à l’e-learning.
1.5 Méthodologie agile
Toute démarche pour le développement a besoin d’un modèle de développement
définissant une méthode qui doit fournir des résultats fiables. Une telle méthode doit décrire la
modélisation du système logiciel (éventuellement matériel) efficace et complète. Plusieurs
méthodologies de gestion de projet existent, mais le choix d’une entre elles dépendra de la
nature du projet. Si le domaine du projet est maîtrisé, un cycle de vie en cascade. Au cas où,
nous ne pouvons pas tout prévoir dès le début ou si les besoins sont incomplets comme dans
notre cas, il faut utiliser les méthodes itératives et incrémentales telles que les méthodes agiles.
17. Chapitre 1 : Aperçu général et cadre du projet
8
Une méthode agile garantit une meilleure qualité de communication avec l’utilisateur,
une meilleure visibilité du client sur l’avancement des travaux, un meilleur contrôle de qualité
par le fait que les tests sont effectués en continuité, ce qui permet de détecter rapidement les
problèmes. Elle intègre aussi la notion de travail en équipe. Parmi les méthodes agiles, nous
pouvons citer « SCRUM » [1] qui sera utilisé dans la réalisation de notre projet. Après le choix
de la méthodologie, nous avons besoin d’un langage de modélisation unifié pour la modélisation
de notre projet. Pour concevoir notre système, nous avons choisi UML (Unied Modeling
Language) comme un langage de modélisation. Notre choix s’est basé sur les points forts de ce
langage notamment sa standardisation et les divers diagrammes qu’il propose.
De plus, UML présente le meilleur outil pour schématiser des systèmes complexes sous un
format graphique et textuel simplifié et normalisé.
1.5.1 Présentation de SCRUM
Le principe de la méthode agile SCRUM est de concentrer l’équipe de développement
sur un ensemble de fonctionnalités à réaliser de façon itérative, dans des itérations d’une durée
de deux à quatre semaines, appelées des sprints. Chaque sprint doit aboutir à la livraison d’un
produit partiel.
Cycle de vie de SCRUM
Comme c’est indiqué dans la figure 02, pour appliquer la méthode SCRUM, il faut
dégager dans un premier temps le maximum de fonctionnalités à réaliser pour former le Backlog
du produit. Dans un deuxième temps, il faut définir les priorités des fonctionnalités et choisir
celles qui seront réalisées dans chaque itération. Par la suite, l’équipe doit se focaliser sur
l’ensemble des fonctionnalités à réaliser dans des itérations appelées sprints. Un sprint aboutit
toujours à la livraison d’un produit partiel fonctionnel appelé incrément. Ainsi, vers la fin de
chaque sprint, une réunion aura lieu pour effectuer la revue de l’itération. L’objectif de cette
réunion consiste à valider l’incrément qui a été produit pendant l’itération.
18. Chapitre 1 : Aperçu général et cadre du projet
9
Figure 02: Cycle de vie de la méthodologie Scrum
Le choix de Scrum comme méthodologie de pilotage pour ce projet repose sur les avantages
de ce dernier. Il se résume comme suit :
Plus d’agilité et de réactivité.
La possibilité énorme d’adaptation aux modifications grâce à des itérations courtes.
Et la chose la plus importante, c’est que Scrum joint les deux aspects théorique et
pratique et s’assimile beaucoup de la réalité.
Les outils Scrum (Trello)
En utilisant « Trello » (Application de gestion de projet en ligne gratuite) qui permet de
découper les grands projets en plusieurs sous-projets plus petits et plus faciles à gérer et les
distribuer par sprint d´équipe. Cela permettrait à l’équipe de développement d’être plus agile et
de constamment progresser dans sa gestion de projets.
19. Chapitre 1 : Aperçu général et cadre du projet
10
1.6 Langage de modélisation UML
Une dizaine d'années après le début de son utilisation dans le cadre de projets de
développement orienté objet, UML s'est imposé comme standard. Ce langage est né de la fusion
de plusieurs méthodes existantes auparavant est devenu désormais la référence en matière de
modélisation objet. La modélisation objet consiste à créer une représentation informatique des
éléments du monde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui
signifie indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets
présents et d'isoler leurs données et les fonctions qui les utilisent [2].
Donc, après le choix de la méthodologie, on a opté UML comme un langage de
modélisation qui est utilisé dans tous les projets logiciels comportant un ensemble de
diagrammes, il permet de fournir une représentation informatique d’un ensemble d’objets et de
problèmes standards du monde réel.
Conclusion
Dans ce chapitre, nous avons commencé par une présentation de l’entreprise et une brève
description du sujet. Par ailleurs, nous avons pu déterminer les problématiques, en faisant une
critique de l’existant et en désignant la méthode du développement choisie. Le chapitre suivant
sera consacré à la phase de planification mettant l’accent sur l’étude préliminaire des besoins
ainsi que la présentation du Backlog produit et la planification des sprints.
Figure 03: Tableau Trello
20. Chapitre 2 : Planification et architecture
11
Chapitre 2
PLANIFICATION ET
ARCHITECTURE
Introduction
omme nous l’avons déjà mentionné, dans le chapitre précédent, nous avons choisi à
adopter la méthodologie pour la conception de notre futur système, l’analyse des besoins
est une étape primordiale dans la réalisation de tout projet informatique.
Ce chapitre présente le sprint zéro qui représente le premier pas de la réalisation de notre projet.
Tout d’abord, nous entamons la spécification fonctionnelle et non fonctionnelle afin de produire
le backlog du produit ainsi qu’une première planification des sprints. Puis, nous donnons un
bref aperçu sur le matériel de base, les technologies et les langages de programmation utilisés
pour la mise en place de l’environnement de travail.
C
21. Chapitre 2 : Planification et architecture
12
2.1 Capture des besoins
Dans cette partie, nous identifions les acteurs, leurs rôles et leurs privilèges dans notre
application.
2.1.1 Identification des acteurs
« Un acteur représente une entité externe du système qui interagit avec lui.
Il ne s’agit pas nécessairement d’un acteur humain, mais peut être un acteur machine » [3].
Dans notre application, nous avons identifié un seul acteur qui est l’élève inscrit à l’académie
et qui va interagir avec l’application.
Acteur
L’élève de Taki Academy
Tableau 01: Les acteurs de notre système
2.1.2 Identification des besoins
Notre application doit satisfaire les exigences des utilisateurs. Nous exposons dans ce
qui suit leurs besoins fonctionnels ainsi que les besoins non fonctionnels.
Les besoins fonctionnels
Les besoins fonctionnels doivent expliciter ceux du client. Dans notre cas, des besoins
exprimés par l’entreprise ont permis d’établir le cahier des charges suivant :
Les besoins utilisateurs :
Authentification : Permet à l’utilisateur de se connecter à travers un login et un mot de
passe de son compte « Taki Academy » afin de bénéficier des fonctionnalités de
l'application.
Gestion des profils : Permet à l’utilisateur de consulter son profil.
Gestion des résumés de cours concernant chaque matière : Permet à l’utilisateur de
consulter les résumés de chaque matière, chercher des cours…
Gestion des Quiz pour chaque chapitre : Permet à l’utilisateur de consulter et remplir
les quiz …
22. Chapitre 2 : Planification et architecture
13
Gestion des examens pour chaque chapitre : Permet à l’utilisateur de consulter
l’examen, le scanner et recevoir les corrections.
Les besoins non fonctionnels
Après avoir défini les besoins fonctionnels de notre projet, nous passons à dégager les
exigences non fonctionnelles de l'utilisateur qui seront prises en compte tout au long du travail.
Les principaux besoins non fonctionnels de notre application se résument dans les points
suivants :
Fiabilité : L’application doit être robuste et assure des résultats efficaces et fiables.
Ergonomie de l’interface : Les interfaces homme machine doivent être ergonomiques
et conviviales.
Clarté : Le code doit être clair pour permettre des futures évolutions ou améliorations.
Sécurité : Le système doit respecter la confidentialité des données.
2.2 Pilotage du projet avec scrum
2.2.1 Identification de l’équipe scrum
« Le principe de la méthode agile « SCRUM » est de concentrer l’équipe de
développement, pour cela, elle s’organise elle-même et doit avoir toutes les compétences
nécessaires au développement du produit. » [B1].
Très brièvement, cette méthodologie définit les trois rôles suivants :
Le Product Owner (le propriétaire du produit) : représente les utilisateurs (les
clients), c’est une personne qui porte la vision du produit à réaliser, clarifie leurs
besoins, détermine leurs priorités et prend les décisions importantes concernant
l’orientation du projet.
Le Scrum Master (le directeur de produit) : c’est un facilitateur et un coach plus
qu’un superviseur qui doit assurer le bon déroulement des différents sprints du release,
et qui doit impérativement maitriser Scrum, il protège l’équipe de tous les éléments
perturbateurs, ainsi que des problèmes non techniques.
23. Chapitre 2 : Planification et architecture
14
Le Scrum Team (l’équipe de Scrum) : constitué des personnes qui seront chargées
d’implémenter les différents besoins du client. Les membres prennent les décisions
ensemble et personne ne donne d’ordre à l’équipe sur sa façon de procéder. L’équipe
s’adresse directement au client.
Dans le contexte de notre projet, notre encadreur sera à la fois le propriétaire et le directeur
de produit puisqu’il satisfait les différents prés requis des deux rôles cités précédemment et je
formerais le membre de l’équipe Scrum.
2.2.2 Le backlog du produit
L’approche de «SCRUM» propose de commencer par énumérer les exigences du client
pour produire le backlog du produit en tant qu’une liste de « user-stories », cette liste contient
tout ce qui pourrait être exigé dans le produit et elle est la seule source de besoins pour toutes
les modifications à apporter au produit. Les éléments du backlog (« backlog items ») sont
classés par priorité qui peut être élevée ou moyenne. Le tableau 02 introduit le backlog du
produit à réaliser dans notre projet avec la priorité qui a été fixée par le « Product Owner ».
24. Chapitre 2 : Planification et architecture
15
Tableau 02: Backlog produit
Numéro User Story Priorité
01 En tant que développeur, je veux créer une maquette graphique de
l’application sur adobe XD.
Élevée
02 En tant que développeur, je veux assister à une formation React
native et material design.
Élevée
03 En tant que développeur, je veux mettre en place le projet et les
éléments nécessaires pour le développement
Moyenne
04 En tant qu’utilisateur, je veux m’authentifier pour accéder à
l’application.
Élevée
05 En tant qu’utilisateur, je veux consulter les informations générales
de mon profil.
Moyenne
06 En tant qu’utilisateur, je veux me déconnecter de l’application. Moyenne
07 En tant qu’utilisateur, je veux consulter la liste des matières. Élevée
08 En tant qu’utilisateur, je veux consulter les chapitres de chaque
matière.
Moyenne
09 En tant qu’utilisateur, je veux rechercher un chapitre. Moyenne
10 En tant qu’utilisateur, je veux accéder au résumé. Moyenne
11 En tant qu’utilisateur, je veux consulter la durée et la difficulté de
chaque matière
Moyenne
12 En tant qu’utilisateur, je veux rechercher une matière. Élevée
13 En tant qu’utilisateur, je veux accéder au quiz. Élevée
14 En tant qu’utilisateur, je veux accéder aux corrections de quiz. Élevée
15 En tant qu’utilisateur, je veux accéder à mon score. Moyenne
16 En tant qu’utilisateur, je veux accéder à l’examen. Élevée
17 En tant qu’utilisateur, je veux scanner ma copie d’examen. Élevée
18 En tant qu’utilisateur, je veux envoyer mon travail. Élevée
19 En tant qu’utilisateur, je veux télécharger la correction en fichier
PDF.
Moyenne
20 En tant qu’utilisateur, je veux consulter ma note. Moyenne
25. Chapitre 2 : Planification et architecture
16
2.2.3 Planification des Sprints
Après avoir organisé le backlog produit, et au cours de la réunion de planification des
sprints, nous avons réalisé, les durées prévisionnelles du travail à effectuer durant chaque sprint.
Le tableau 03 présente la planification que nous avons établie pour les sprints relatifs à notre
projet.
Tableau 03: Planification des sprints
2.2.4 Sprint 0 : Mise en place du projet
Ce sprint est le premier pas pour le développement de notre application, durant ce sprint
nous avons réalisé les tâches présentées dans le backlog de sprint.
Backlog de sprint 0
Date du début du sprint : 04/02/2019.
Date du fin du sprint : 15/03/2019.
Estimation en heure : 240 heures.
Échelle de mesure : une journée est égale à 8h de travail de 8h30 à 12h30 et de 13h00 à
17h00.
Le tableau 04 présent le backlog de sprint 0.
Élément du backlog Tâche Estimation
Conception maquette graphique
de l’application.
Assister à la formation Adobe XD. 10h
Conception de l’application. 70h
Assister à des formations en
ligne.
Assister à la formation React Native. 120h
Assister à la formation en matériel design. 30h
Installer l’environnement
matériel et logiciel.
Mettre en place les logiciels nécessaires. 10h
Tableau 04: Backlog de Sprint 0
Sprint Libellé Users Story ID Début prévu Fin prévue
0 Mise en place du projet 01,02,03 04/02/2019 15/03/2019
1 Gestion des profils 04,05,06 18/03/2019 15/04/2019
2 Gestion des matières 07,08,09,10,11,12 16/04/2019 14/05/2019
3 Gestion des quiz 13,14,15 15/05/2019 17/06/2019
4 Gestion des examens 16,17,18,19,20 18/06/2019 15/07/2019
26. Chapitre 2 : Planification et architecture
17
2.2.5 Diagramme des cas d’utilisation globale
La figure 04 donne une vue globale concernant le comportement fonctionnel du
système.
Ce diagramme permet de décrire les interactions entre l’acteur et les cas d’utilisation du
système.
Figure 04: Diagramme cas d'utilisation globale
2.3 Conception graphique
En sens graphique du terme, le design se rapporte aux qualités formelles des objets
produits en vue d’un résultat esthétique. Dans cette partie, nous allons nous intéresser à la
conception graphique de l’application, et nous allons établir le synopsis et la charte graphique.
2.3.1 Synopsis
Sujet : Réalisation d’une application mobile pour évaluer le niveau des élèves de Taki
Academy.
Public cible : Les élèves de Taki Academy (les classes de 5ème année de base jusqu’au
cycle préparatoire à l’ingénierie).
Type : Application mobile.
Catégorie : e-learning.
But : Évaluation niveau d’élèves.
Marché : Tunisie.
27. Chapitre 2 : Planification et architecture
18
2.3.2 Charte graphique
On appelle charte graphique l’ensemble des codes graphiques, colorés et formels créés
pour la communication visuelle d’une entreprise. C’est la mission du concepteur d’élaborer un
certain nombre de règles donnant une unité et une cohérence aux activités du site web. Ces
règles sont appliquées aux logos et à tous les supports de communication (plaquettes, affiches,
sites web, cartes visites, etc.).
Pour notre travail, et dans le but de garantir la cohérence du site avec les autres supports de
communication, nous allons appliquer un certain nombre de règles pour assurer une identité
cohérente et stable.
Type de ligne : Des lignes droites et claires pour désigner la clarté et le dynamisme.
Gamme des formes : Les carrés arrondis et les lignes sont les plus utilisés dans les
pages de l’application.
Gamme de couleurs : Il est recommandé d’utiliser le minimum des nuances de couleurs
pour créer une sobriété sur les pages.
Choix typographiques :
- Pour les titres : Roboto Medium 20px.
- Pour le corps de texte : Roboto Medium ou Roboto Regular 14px.
- Pour les boutons de texte : Roboto Medium 14px, EN MAJUSCULES.
2.3.3 Prototypage des interfaces
Une fois que nous avons terminé la conception de nos écrans, nous pouvons les connecter
les uns aux autres pour visualiser comment les utilisateurs peuvent découvrir notre application.
Adobe XD nous permet de créer des prototypes interactifs pour visualiser la navigation
entre les écrans ou les structures filaires . Nous pouvons prévisualiser l'interaction pour valider
l'expérience utilisateur et effectuer une itération sur notre conception pour gagner du temps sur
le développement. Nous pouvons également enregistrer les interactions et les partager avec les
parties prenantes pour obtenir leurs réactions. (Voir annexe).
2.3.4 Choix des couleurs
Aussi bien que le design plat, il y a une tendance de couleurs utilisées récemment par
Google. Nous avons utilisé « COLOR TOOL » du Matériel design qui offre des choix multiples
de couleurs simples.
Le choix de couleur bleu (#2ba7df) est inspiré du logo de l’entreprise.
28. Chapitre 2 : Planification et architecture
19
Figure 05: Color tools
2.4 Environnement de travail
L’analyse des besoins techniques couvre la spécification des technologies à utiliser ainsi
que la structure applicative pour donner une vision globale sur l’architecture de notre projet.
Avant de traduire la conception et ses règles en un langage de programmation, et afin d’aboutir
à une automatisation de ses besoins tel qu’ils ont été définis dans la phase de spécification des
besoins, nous présentons ici l’environnement et les outils de travail.
2.4.1 Environnement matériel
Concernant la partie matérielle, il faut utiliser un matériel performant au niveau
processeur et mémoire pour gagner au niveau du temps de réponse de l’exécution de
l’application.
Nous avons utilisé un ordinateur dont les caractéristiques techniques sont les suivantes :
- Laptop DELL
Processeur : Intel® Core ™ i5-6200U CPU @ 2.30Hz 2.40 GHz
RAM : 8.00 GB.
Disque dur : 500 GO
Système d’exploitation : Windows 10 Pro
- Écran LCD DELL
- Smartphone : SUMSUNG
29. Chapitre 2 : Planification et architecture
20
2.4.2 Environnement logiciel
Dans cette section, nous spécifions les logiciels utilisés, l’environnement de conception
et l’environnement de développement mobile.
Adobe XD
Adobe XD est un vectoriel outil de conception de l' expérience
utilisateur pour les applications Web et des applications
mobiles , développé et édité par Adobe Inc . Il est disponible
pour macOS et Windows , bien qu'il existe des versions
pour iOS et Android permettant de prévisualiser le résultat du
travail directement sur les appareils mobiles. XD prend en charge
les structures filaires de site Web et la création de prototypes de
clics interactifs simples [4].
Environnement de conception UML
StarUML est un outil de modélisation logicielle open source
prenant en charge le langage UML (Unified Modeling Language)
[5].
Environnement de développement mobile
Node.js est une plateforme logicielle libre et évènementielle en
JavaScript orientée vers les applications réseau qui doivent
pouvoir monter en charge. Elle utilise la machine virtuelle V8 et
implémente sous licence MIT les spécifications CommonJS [6].
Visual Studio Code est un éditeur de code extensible développé
par Microsoft pour Windows, Linux et macOS [7].
30. Chapitre 2 : Planification et architecture
21
Expo le moyen le plus rapide pour créer une application avec les
outils, les services et React Native, Ainsi nous pouvons créer,
déployer et parcourir rapidement des applications natives iOS et
Android à partir de la même base de code JavaScript.
2.4.3 Choix technologiques
React native
React Native est un framework JavaScript créé par Facebook en
2015.Il s’appuie sur la librairie JavaScript, react très populaire
ces dernières années. React native utilise les composants mobiles
natifs, utiliser les composants mobiles native signifie que lorsque
vous afficher un élément graphique dans une application react
native le converti en son équivalent native. Par exemple une vue
sera convertie en UIView sur ios et en Android.view sur Android.
Grâce à cette conversion react native permet de créer des
applications cross plateforme aussi fluide et performante que des
applications natives.
Swagger
Swagger est une infrastructure logicielle open source reposant
sur un vaste écosystème d'outils qui aide les développeurs à
concevoir, créer, documenter et utiliser des services
Web RESTful . Alors que la plupart des utilisateurs identifient
Swagger à l'aide de l'outil d'interface utilisateur Swagger, le jeu
d'outils Swagger comprend la prise en charge de la
documentation automatisée, de la génération de code et de la
génération de cas de test.
31. Chapitre 2 : Planification et architecture
22
2.4.4 Le système de gestion de versions GIT
GitHub permet de stocker le code source d'un projet et de suivre
l'historique complet de toutes les modifications apportées à ce
code. Grâce aux outils qu'elle fournit pour gérer les conflits
éventuels résultant des changements apportés par plusieurs
développeurs, il est possible de collaborer efficacement sur un
même projet. GitHub facilite la programmation collaborative en
mettant une interface Web à disposition du référentiel de code de
Git, ainsi que des outils d'administration favorisant
la collaboration.
React native vs mobile native
Tableau 05: React native vs mobile native
Une application native est une application développée spécifiquement pour un système
d'exploitation cela signifie que si nous souhaitons créer une application native sur iOS et
Android nous allons devoir créer deux applications mobiles une première pour iOS avec les
langages de programmation Swift ou objectif, et une seconde pour Android avec les langages
de programmation Java ou kotlin.
Les applications natives sont fluides et très performantes, mais elles sont longues et difficiles à
développer.
C'est dans ce contexte où il était difficile de développer une application rapidement pour
iOS et Android que les applications cross platform ont vu le jour. React Native s’inscrit parmi
32. Chapitre 2 : Planification et architecture
23
les applications de type cross-plateforme il permet de développer une seule application en un
seul langage de programmation le JavaScript et qui fonctionnera aussi bien sur iOS
qu’Android.
Architecture de React Native
React Native a un fonctionnement très spécifique propre à lui-même. En effet chaque
composant est directement branché au composant natif dont il fait référence. Aucune couche
supplémentaire n’est nécessaire pour communiquer entre les composants natifs et ceux offerts
par React Native [8].
Il est néanmoins important de comprendre que l’on n’interagit pas immédiatement avec les
composants natifs du téléphone. React Native reste un Framework utilisant le langage
JavaScript et ne peut donc pas directement être lancé sur un téléphone Android ou IOS.
C’est pour cela que React Native utilise un environnement de runtime lié à JavaScript.
Figure 06: Architecture de React Native
L’application est alors lancée dans cet environnement, ce qui permet d’accéder au
langage JavaScript et de faire fonctionner l’application. Des ponts sont ensuite créés entre les
composants offerts par React Native et les composants natifs du téléphone. Le reste de
33. Chapitre 2 : Planification et architecture
24
l’application communique ensuite uniquement via les composants React Native qui sont eux-
mêmes connectés aux composants natifs du téléphone.
Points positifs et négatifs de react native
Points positifs Points négatifs
React Native est gratuit.
React Native est Open Source.
React Native reste porté par Facebook.
React Native permet de tester son
application instantanément.
Framework jeune.
Compatibilité IOS et Android (partielle pour
l'instant), mais pas de Windows Phone prévu.
Nécessité d'utiliser des conditions pour
différencier le code spécifique aux
composants natifs des différentes
plateformes.
Tableau 06: Points positifs et négatifs de react native
2.5 Architecture générale de l’application
2.5.1 Choix de l’architecture de l’application
Nous décrivons dans cette partie le fonctionnement de notre application mobile. Elle s'est
communiquée avec les API de Taki Academy à travers des requêtes HTTP afin de poster et
récupérer des données réelles sous format json en interrogeant la base de données de Taki
Academy. D’où l’architecture de notre application mobile est une architecture 3-tiers partagé
entre :
Une base de données : l’application ne possède pas une base de données, mais elle a
l’accès à la base de données de Taki Academy.
Un client mobile : est une personne qui a un smartphone ayant l’application.
Un serveur d’api : qui répond aux requêtes de l’application.
34. Chapitre 2 : Planification et architecture
25
La figure suivante schématise l’architecture générale de notre application mobile.
Figure 07: Architecture générale de l’application
2.5.2 Spécification de l’architecture
L’architecture Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais Model-View-
Controller) est une méthode de conception qui organise l'interface homme-machine (IHM)
d'une application logicielle :
Le modèle représente le comportement de l'application. Il décrit ou contient les
données manipulées par l'application. Il assure la gestion de ces données et garantit
leur intégrité.
La vue se contente d'afficher les résultats des traitements effectués par le modèle
et d'interagir avec l'utilisateur.
Le contrôleur reçoit tous les évènements de l'utilisateur et enclenche les actions à
effectuer pour mettre à jour la vue ou le modèle.
Le client envoie une requête à l’application, elle est analysée par le contrôleur qui
demande au modèle approprié d’effectuer les traitements puis renvoie la vue adaptée au
navigateur.
35. Chapitre 2 : Planification et architecture
26
Figure 08: Le modèle MVC
2.6 Diagramme de déploiement
Un diagramme de déploiement décrit la disposition physique des ressources matérielles
qui composent le système et montrent la répartition des composants sur ces ressources.
Chaque ressource étant matérialisée par un nœud, le diagramme de déploiement précise
comment les composants sont répartis sur les nœuds et quelles sont les connexions entre les
composants ou les nœuds. Les diagrammes de déploiement existent sous deux formes :
spécification et instance [9].
Ce diagramme décrit l’architecture globale nécessaire pour la mise en place de notre
application.
36. Chapitre 2 : Planification et architecture
27
Figure 09: Diagramme de déploiement
Conclusion
Dans ce chapitre nous avons présenté d’une manière globale les principales technologies que
nous allons utiliser tout au long du développement de notre application. Dans les chapitres
suivants, nous allons détailler la manière avec laquelle ils fonctionnent, appuyée par des
exemples extraits de notre application.
37. Chapitre 3 : Gestion des profils et gestion des matières
28
Chapitre 3
GESTION DES PROFILS ET
GESTION DES MATIÈRES
Introduction
ans ce chapitre, nous allons détailler la réalisation du sprint 1 et 2. En premier lieu, nous
allons présenter le backlog de chaque sprint, ensuite nous allons déterminer une analyse
des besoins suivie d’une conception détaillée.
Nous allons décrire par la suite la phase de réalisation et nous allons finir par des imprimes écrans.
D
38. Chapitre 3 : Gestion des profils et gestion des matières
29
3.1 Sprint 1 : Gestion des profils
3.1.1 Backlog de sprint 1
Date du début du sprint : 18/03/2019.
Date du fin du sprint : 15/04/2019.
Estimation en heure : 160 heures.
Échelle de mesure : une journée est égale à 8h de travail de 8h30 à 12h30 et de 13h00 à
17h00.
Le tableau 07 présente le backlog de sprint 1 en précisant la liste des tâches qui seront réalisées
et la charge de travail pour chacune en nombre d’heures.
Élément du backlog Tâche Estimation
En tant qu’utilisateur, je veux m’authentifier
pour accéder à l’application.
Développement de l’interface 20h
Intégration des APIs. 29h
En tant qu’utilisateur, je veux récupérer mon
mot de passe par email.
Développement de l’interface 16h
Intégration des APIs. 16h
En tant qu’utilisateur, je veux consulter les
informations générales de mon profil.
Développement de l’interface 26h
Intégration des APIs. 16h
En tant qu’utilisateur, je veux me déconnecter
de l’application.
Développement de l’interface 26h
Intégration des APIs. 11h
Tableau 07: Backlog de Sprint 1
3.1.2 Spécification fonctionnelle
Dans ce suit, nous allons modéliser les User Story mentionnées auparavant. Nous
commençons par la présentation du diagramme de cas d’utilisation globale du sprint 1, puis nous
allons passer au raffinement de chaque cas d’utilisation et la description textuelle de quelques uns
ainsi que les diagrammes de séquences.
39. Chapitre 3 : Gestion des profils et gestion des matières
30
Diagramme de cas d’utilisation globale du Sprint 1
La figure 10 représente le diagramme de cas d’utilisation globale du premier sprint.
Figure 10: Diagramme de cas d'utilisation globale sprint 1
Description textuelle du cas d’utilisation « S’authentifier »
Le tableau suivant décrit la description textuelle du cas d’utilisation « S’authentifier ».
Titre S’authentifier
Acteurs Élève de Taki Academy
Description Lorsqu’un utilisateur du système veut accéder à l’application, il doit saisir
son login et son mot de passe : ensuite le système vérifie s’ils sont
corrects ou pas afin d’autoriser ou bien refuser l’accès.
Pré condition(s) L’utilisateur doit avoir un compte TA.
Description des
scénarios
Scénario nominal :
1. L’utilisateur demande l’accès au système, en cliquant sur le
bouton « Se connecter ».
2. Le système redirige l’utilisateur vers la page takiacademy.com.
3. L’utilisateur introduit son email et son mot de passe de son
compte TA.
4. Si l’utilisateur est identifié, le système affiche l’interface de
« Accueil ».
Scénario alternatif :
A1 : Email ou mot de passe non valide :
40. Chapitre 3 : Gestion des profils et gestion des matières
31
1. Le système affiche un message d’erreur « Votre identifiant ou
votre mot de passe est incorrect ».
Tableau 08 : Tableau descriptif de cas d'utilisation « S'authentifier »
Description textuelle du cas d’utilisation « Gérer profils »
Le tableau 09 décrit la description textuelle du cas d’utilisation « Consulter les
informations générales de profil ».
Titre Gérer profil
Acteurs Élève de Taki Academy
Description Consulter les informations générales de profil.
Pré condition(s) Authentification et accès autorisé.
Description des
scénarios
Scénario nominal :
1. Après l’authentification, l’utilisateur accède à l’application.
2. L’utilisateur clique sur l’élément « Profil » du menu pour accéder
à son profil.
3. Le système affiche les informations générales de profil de
l’utilisateur.
Scénario alternatif :
A1 : Réseau non disponible ou pas d’accès à internet :
1. Le système affiche un message d’erreur « Erreur réseau ».
Tableau 09: Tableau descriptif de cas d'utilisation « Consulter les informations de profil »
3.1.3 Conception
Diagramme de séquences détaillées
Dans cette partie, nous allons simplifier la vue dynamique de notre système informatique,
nous exposons les principaux scénarios d’exécutions à travers des diagrammes de séquences.
Ce diagramme permet d’afficher les différentes interactions entre l’acteur et notre système via des
messages présentés dans un ordre chronologique.
41. Chapitre 3 : Gestion des profils et gestion des matières
32
Diagramme de séquence de l’opération « S’authentifier »
Figure 11: Diagramme de séquence « S’authentifier »
42. Chapitre 3 : Gestion des profils et gestion des matières
33
Diagramme d’activité
Les diagrammes d’activités permettent de mettre l’accent sur le traitement. Ils sont donc.
Particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de flots de
données. Ils permettent ainsi de représenter graphiquement le comportement d’une méthode ou le
déroulement d’un cas d’utilisation.
En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme
d’activités, mais seuls les mécanismes complexes ou intéressants méritent d’être représentés.
Diagramme d’activité de l’opération « S’authentifier »
L’authentification est la procédure qui consiste, pour un système informatique, à vérifier
l’identité d’une entité (personne, ordinateur...), afin d’autoriser son accès aux systèmes, réseaux,
applications. Elle permet donc de valider l’authenticité de l’entité en question.
La figure 14 représente le diagramme de l’activité « Authentification ».
Figure 12: Diagramme de l’activité « Authentification »
43. Chapitre 3 : Gestion des profils et gestion des matières
34
3.1.4 Réalisation et interprétation
Dans cette partie, nous présentons quelques captures d’écran sur notre application afin
de mieux comprendre la réalisation des différentes tâches de sprint1.
Interface « Authentification »
L’application n'aura pas le flux d'écran d'inscription et supposera que l’utilisateur possède
un compte TA.
Tout commence avec Splashscreen (figure 13) puis un écran de connexion (figure 14) si
l'utilisateur est déconnecté.
L’utilisateur doit se connecter avec leur email et leur mot de passe de son compte TA puis il doit
autoriser l’application à utiliser leur compte TA pour avoir authentifié.
Figure 13: Écran de démarrage Figure 14: Écran de connexion
44. Chapitre 3 : Gestion des profils et gestion des matières
35
Interface « Se connecter »
L’utilisateur doit se connecter avec leur email et leur mot de passe ou bien avec leur
compte Google ou Facebook.
Figure 16: Alerte de connexionFigure 15: Interface de connexion
45. Chapitre 3 : Gestion des profils et gestion des matières
36
Interface « Mot de passe oublié »
Si l’utilisateur oublie son mot de passe il peut le réinitialiser lorsqu’il clique sur le lien
« Mot de passe oublié ? »
Figure 17: Interface mot de passe oublié
46. Chapitre 3 : Gestion des profils et gestion des matières
37
Interface « Profil »
Le profil est le lieu où chaque utilisateur renseigne ses informations et personnalise son
espace, lorsqu’en cliquant sur l’élément « profil » du menu l’utilisateur accède à l’interface de
profil ou il peut consulter ses informations et déconnecter de l'application.
Figure 18: Interface profile
47. Chapitre 3 : Gestion des profils et gestion des matières
38
APIs utilisées
Verbe URL Paramètres Description
POST /auth/login credential, password. Se connecter par numéro de
téléphone ou par e-mail.
POST /auth/register email, phone, birth_date,
password, last_name,
first_name, division_id,
country
Créer un utilisateur et envoyer le
code pour vérifier le compte.
POST /password/reset email Réinitialiser le mot de passe.
GET /auth/me Accept, contetnt-type ,
Authorization
Récupérer les information de
profil.
Tableau 10: Liste des APIs utilisées
3.1.5 Test
Les tests logiciels sont définis comme une activité permettant de vérifier si les résultats
réels correspondent aux résultats attendus et de s’assurer que le système logiciel est sans défaut.
Avant la fin de chaque Sprint, nous avons testé les fonctionnalités du module. Ensuite nous avons
validé toutes les fonctionnalités avec le Product Owner.
Pour ce fait, nous avons élaboré dans le tableau suivant un ensemble de cas de scénarios de tests
relatifs au sprint 1.
Cas de test Démarche Comportement attendu Résultats
Test d’authentification. Saisie mail et un mot de
passe puis cliquer sur le
boutton se connecter.
Accès à un espace privé. Conforme
Test d’affichage de
données générales du
compte de l’utilisateur
dans le profil.
Cliquer sur l’élément du
menu « profil »
Accès au profil de
l’utilisateur et affichage
des données générales du
compte de l’utilisateur.
Conforme
Test de mot de passe
oublié
Saisie mail et cliquer sur
le boutton envoyer.
Le nouveau mot de passé
est envoyé au boite mail.
Conforme
Test de déconnexion Cliquer sur le bouton
déconnexion
Retour au page login. Conforme
Tableau 11: Tests
48. Chapitre 3 : Gestion des profils et gestion des matières
39
3.2 Sprint 2 : Gestion des matières
3.2.1 Backlog de sprint 2
Date du début du sprint : 16/04/2019.
Date de la fin du sprint : 14/05/2019.
Estimation en heure : 160 heures
Échelle de mesure : une journée est égale à 8h de travail de 8h30 à 12h30 et de 13h00 à
17h00.
Le tableau 12 présente le backlog de sprint 3 en précisant la liste des tâches qui seront réalisées
et la charge de travail pour chacune en nombre d’heures.
Élément du backlog Tâche Estimation
En tant qu’utilisateur, je veux consulter les
matières.
Développement de l’interface 18h
Intégration des APIs. 08h
En tant qu’utilisateur, je veux consulter les
chapitres.
Développement de l’interface 18h
Intégration des APIs. 08h
En tant qu’utilisateur, je veux chercher une
leçon.
Développement de l’interface 20h
Intégration des APIs. 08h
En tant qu’utilisateur je veux consulter le
niveau de difficulté de chaque leçon.
Développement de l’interface 19h
Intégration des APIs. 08h
En tant qu’utilisateur je veux consulter la durée
de chaque leçon.
Développement de l’interface 18h
Intégration des APIs. 08h
En tant qu’utilisateur je veux consulter la
progression de chaque chapitre.
Développement de l’interface 19h
Intégration des APIs. 08h
Tableau 12: Backlog de Sprint 2
49. Chapitre 3 : Gestion des profils et gestion des matières
40
3.2.2 Spécification fonctionnelle
Dans ce qui suit, nous allons modéliser les User Story mentionnés auparavant. Nous
commençons par la présentation du diagramme de cas d’utilisation globale du deuxième sprint,
puis nous allons passer au raffinement de chaque cas d’utilisation et la description textuelle de
quelques uns ainsi que leurs diagrammes de séquences.
Diagramme de cas d’utilisation
Diagramme de cas d’utilisation globale sprint 2
La figure 18 représente le diagramme de cas d’utilisation globale du deuxième sprint.
Figure 19: Diagramme de cas d'utilisation globale de Sprint 2
Description textuelle des cas d’utilisation « Rechercher une matière »
Le tableau 13 suivant décrit la description textuelle du cas d’utilisation « Chercher une
matière ».
Titre Rechercher une matière
Acteurs Élève de Taki Academy
Description Rechercher une leçon.
Pré condition(s) Authentification et accès autorisé.
Scénario nominal :
50. Chapitre 3 : Gestion des profils et gestion des matières
41
Description des
scénarios
1. L’utilisateur accède à la fenêtre de recherche.
2. L’utilisateur saisit le nom de la leçon à rechercher dans la barre
de recherche.
3. Le système affiche une liste des leçons contenant les mots saisis
par l’utilisateur.
Scénario alternatif :
A1 : Réseau non disponible ou pas d’accès à internet :
1. Le système affiche un message d’erreur « Erreur réseau ».
Tableau 13: Tableau descriptif de cas d'utilisation « Rechercher une matière »
3.2.3 Conception
Diagramme de séquences détaillées
Diagramme de séquence « Rechercher une leçon »
Figure 20: Diagramme de séquence « Rechercher une leçon »
51. Chapitre 3 : Gestion des profils et gestion des matières
42
Diagramme consulter la liste des matières
Figure 21: Consulter la liste des matières
Diagramme d’activité
Diagramme d’activité «Rechercher leçon »
La figure 22 représente le diagramme d’activité de la recherche d’une leçon.
Figure 22: Diagramme d'activité « Rechercher leçon »
52. Chapitre 3 : Gestion des profils et gestion des matières
43
3.2.4 Réalisation et interprétation
Dans cette partie, nous présentons quelques interfaces de notre système réalisées dans le
deuxième sprint.
Interface « Matières »
Figure 23: Interface matière
53. Chapitre 3 : Gestion des profils et gestion des matières
44
Interface « Chapitres »
Figure 24: Interface chapitres
Interface « Résumé »
Figure 25: Interface résumé
54. Chapitre 3 : Gestion des profils et gestion des matières
45
Interface « Recherche »
Figure 26: Interface Recherche
APIs utilisées
Verbe URL Paramètres Description
GET
/progress/subjects/{subject_id}
/chapters
Subject_id Afficher les chapitres.
POST
/search Accept, Contecnt-
Type, Authorization,
keyword
Chercher une leçon.
Tableau 14: APIs utilisées
55. Chapitre 3 : Gestion des profils et gestion des matières
46
3.2.5 Test
Les estimations initiales proposées pour chaque user story Sprint sont mesurées par jour
de travail. Au bout du Sprint, une présentation sera faite pour démontrer le produit livrable
développé pendant le Sprint.
Cas de test Démarche Comportement attendu Résultats
Test de recherche d’une
leçon.
Cliquer sur le
bouton rechercher
Les leçons sont afficher Conforme
Test d’affichage des
matières.
Cliquer sur le
bouton accueil.
Les matières sont afficher. Conforme
Tableau 15: Tests
Conclusion
Durant ce chapitre, nous avons commencé par définir notre ligne de travail grâce au Sprint
Backlog. Ensuite, nous avons fait l’analyse détaillée de ce dernier pour aboutir enfin a l’étude
conceptuelle et la réalisation de cette itération. Après avoir terminé le premier release en
implémentant toutes les exigences demandées et donné un aperçu sur les principales interfaces
graphiques de notre application, nous pouvons poursuivre notre travail et passer au release 2 qui
fait l’objet du chapitre suivant.
56. Chapitre 4 : Gestion des quizs et gestion des examens
47
Chapitre 4
GESTION DES QUIZS ET
GESTION DES EXAMENS
Introduction
ous allons entamer dans ce chapitre le troisième et le quatrième sprint de notre projet. En
gardant la même démarche du chapitre précédent, nous commençons par présenter le
Backlog du troisième sprint, ensuite nous passons à l’analyse et la conception. Enfin nous
clôturons par la partie réalisation.
N
57. Chapitre 4 : Gestion des quizs et gestion des examens
48
4.1 Sprint 3 : Gestion des quizs
4.1.1 Backlog de sprint 3
Date du début du sprint : 15/05/2019.
Date de la fin du sprint : 17/06/2019.
Estimation en heure : 160 heures.
Échelle de mesure : une journée est égale à 8h de travail de 8h30 à 12h30 et de 13h00 à
17h00.
Le tableau 16 présente le backlog de sprint 3 en précisant la liste des tâches qui seront réalisées
et la charge de travail pour chacune en nombre d’heures.
Élément du backlog Tâche Estimation
En tant qu’utilisateur, je veux remplir quiz.
Développement de l’interface 30h
Développement de l’interface 10h
En tant qu’utilisateur, je veux accéder au score.
Développement de l’interface 20h
Intégration des APIs. 20h
En tant qu’utilisateur, je veux consulter les
réponses.
Développement de l’interface
30h
Intégration des APIs. 10h
En tant qu’utilisateur, je veux refaire le quiz.
Développement de l’interface 30h
Intégration des APIs. 10h
Tableau 16: Backlog de Sprint 3
58. Chapitre 4 : Gestion des quizs et gestion des examens
49
4.1.2 Spécification fonctionnelle
Diagramme de cas d’utilisation
Diagramme de cas d’utilisation globale de sprint 3
La figure 27 représente le diagramme de cas d’utilisation globale du troisième sprint.
Figure 27: Diagramme de cas d'utilisation globale Sprint 3
Description textuelle Diagramme de cas d’utilisation « Remplir quiz »
Le tableau suivant décrit la description textuelle des cas d’utilisation « Remplir quiz».
Titre Remplir quiz
Acteurs Élève de Taki Academy
Description Remplir quiz
Pré condition(s) Authentification et accès autorisé.
Description des
scénarios
Scénario nominal :
1. L’utilisateur clique sur l’élément « quiz » du menu
2. Le système affiche le quiz
3. L’utilisateur clique sur un choix.
4. L’utilisateur passe aux questions suivantes.
5. L’utilisateur valide leurs réponses.
6. Le système affiche leur score.
Scénario alternatif :
59. Chapitre 4 : Gestion des quizs et gestion des examens
50
A1 : Réseau non disponible ou pas d’accès à internet :
1. Le système affiche un message d’erreur « Erreur réseau ».
Tableau 17: Tableau descriptif de cas d'utilisation « Remplir quiz »
Description textuelle Diagramme de cas d’utilisation « Refaire quiz »
Le tableau suivant décrit la description textuelle du cas d’utilisation « Refaire quiz ».
Titre Refaire quiz
Acteurs Élève de Taki Academy
Description Refaire quiz
Pré condition(s) Authentification et accès autorisé.
Description des
scénarios
Scénario nominal :
1. L’utilisateur clique sur le bouton « Refaire le quiz » du menu
2. Le système affiche un nouveau quiz
3. L’utilisateur clique sur un choix.
4. L’utilisateur passe aux questions suivantes.
5. L’utilisateur valide leur réponse.
6. Le système affiche leur score.
Scénario alternatif :
A1 : Réseau non disponible ou pas d’accès à internet :
1. Le système affiche un message d’erreur « Erreur réseau ».
Tableau 18: Tableau descriptif de cas d'utilisation « Refaire quiz »
4.1.3 Conception
Cette partie comporte la conception du sprint, elle contient les diagrammes de séquence
système. Nous poursuivons avec l’exemple « Remplir quiz » et « Refaire le quiz ». Les figures 28
et 29 représentent leurs deux diagrammes de séquences respectivement.
60. Chapitre 4 : Gestion des quizs et gestion des examens
51
Diagramme de séquence « Remplir le quiz »
Figure 28: Diagramme de séquence remplir le quiz
61. Chapitre 4 : Gestion des quizs et gestion des examens
52
Diagramme de séquence « Refaire le quiz »
Figure 29: Diagramme de séquence refaire le quiz
4.1.4 Réalisation et interprétation
Dans cette partie, nous détaillons l’interface afin de montrer les résultats de ce sprint.
Figure 30: Interface quiz
62. Chapitre 4 : Gestion des quizs et gestion des examens
53
4.1.5 Test
Cas de test Démarche Comportement attendu Résultats
Test d’affichage Quiz. Cliquer sur l’élément
Quiz du menu
Accès au quiz. Conforme
Test d’affichage des
réponses après la
validation de quiz.
Cliquer sur le
bouton valider
Accès au Score. Conforme
Tableau 19: Tests
4.2 Sprint 4 : Gestion des examens
4.2.1 Backlog de sprint 4
Date du début du sprint : 18/06/2019.
Date de la fin du sprint : 15/07/2019.
Estimation en heure : 160 heures.
Échelle de mesure : une journée est égale à 8h de travail de 8h30 à 12h30 et de 13h00
à 17h00.
Le tableau 20 présente le backlog de sprint 4 en précisant la liste des tâches qui seront
réalisées et la charge de travail pour chacune en nombre d’heures.
Élément du backlog Tâche Estimation
En tant qu’utilisateur, je veux consulter les
examens.
Développement de l’interface 10h
Intégration des APIs. 08h
En tant qu’utilisateur, je veux consulter la
date limite de chaque examens.
Développement de l’interface 10h
Intégration des APIs. 10h
En tant qu’utilisateur, je veux consulter la
durée de chaque examen et exercice.
Développement de l’interface 10h
Intégration des APIs. 10h
En tant qu’utilisateur, je veux scanner ma
copie.
Développement de l’interface 10h
Intégration des APIs. 10h
63. Chapitre 4 : Gestion des quizs et gestion des examens
54
En tant qu’un utilisateur, je veux consulter la
chronomètre
Développement de l’interface
10h
Intégration des APIs. 05h
En tant qu’utilisateur, je veux déposer mon
travail.
Développement de l’interface 10h
Intégration des APIs. 08h
En tant qu’utilisateur, je veux télécharger la
correction.
Développement de l’interface 10h
Intégration des APIs. 05h
En tant qu’utilisateur, après la correction je
veux consulter ma copie corrigée.
Développement de l’interface 10h
Intégration des APIs. 06h
En tant qu’utilisateur, après la correction je
veux consulter ma note.
Développement de l’interface 10h
Intégration des APIs. 08h
Tableau 20: Backlog de sprint 4
4.2.2 Spécification fonctionnelle
La figure 31 représente le diagramme de cas d’utilisation globale du quatrième sprint.
Figure 31: Diagramme de cas d'utilisation globale Sprint 4
64. Chapitre 4 : Gestion des quizs et gestion des examens
55
Description textuelle Diagramme de cas d’utilisation « Scanner la copie »
Le tableau suivant décrit la description textuelle du cas d’utilisation « Scanner la copie ».
Titre Scanner la copie
Acteurs Élève de Taki Academy
Description Scanner la copie
Pré condition(s) Authentification et accès autorisé.
Description des
scénarios
Scénario nominal :
1. L’utilisateur clique sur le bouton « Scanner »
2. Le système démarrer l’appareil photo
3. L’utilisateur capture la copie.
4. L’utilisateur clique sur suivant.
5. L’utilisateur upload la copie.
6. Le système affiche une interface de confirmation.
7. Le système affiche une interface pour télécharger la
correction.
Scénario alternatif :
A1 : Réseau non disponible ou pas d’accès à internet :
1. Le système affiche un message d’erreur « Erreur réseau ».
Tableau 21: Tableau descriptif de cas d'utilisation « Scanner copie »
Description textuelle Diagramme de cas d’utilisation « Consulter la note »
Le tableau suivant décrit la description textuelle du cas d’utilisation « Consulter la note ».
Titre Consulter la note
Acteurs Élève de Taki Academy
Description Consulter la note
Pré condition(s) Authentification et accès autorisé.
Description des
scénarios
Scénario nominal :
1. L’utilisateur clique sur le menu « Examen »
2. Le système affiche une interface qui contient la note obtenue
et la copie corrigée.
3. Le système affiche interface pour télécharger la copie
corrigée.
65. Chapitre 4 : Gestion des quizs et gestion des examens
56
4. L’utilisateur télécharge la copie
Scénario alternatif :
A1 : Réseau non disponible ou pas d’accès à internet :
Le système affiche un message d’erreur « Erreur réseau ».
Tableau 22: Tableau descriptif de cas d'utilisation « Consulter la note »
4.2.3 Conception
Diagramme de séquence « Consulter la note »
Figure 32: Diagramme de séquence « Consulter la note »
66. Chapitre 4 : Gestion des quizs et gestion des examens
57
Diagramme de séquence système « Scanner la copie »
Figure 33: Diagramme de séquence système « Scanner la copie »
67. Chapitre 4 : Gestion des quizs et gestion des examens
58
4.2.4 Réalisation et interprétation
Dans cette section, nous allons exposer à travers un enchaînement de captures d’écran un
aperçu général sur quelques fonctionnalités réalisées au cours de sprint 4.
Figure 34: Interface examen
APIs utilisées
Verbe URL Paramètres Description
POST /instructor/exams-
upload/{content_id}
Name, is_draft,
appearance_date,
due_date, scope_id
L’utilisateur télécharge
son essai.
POST /student/exams/{content_id}
Content_id,
student-id
L’utilisateur télécharge la
correction.
Tableau 23: APIs utilisées
68. Chapitre 4 : Gestion des quizs et gestion des examens
59
4.2.5 Test
Cas de test Démarche Comportement attendu Résultats
Test upload le travail Cliquer sur
l’élément déposer
du menu.
Le document est envoyé au
professeur.
Conforme
Test scanner la copie. Cliquer sur le
bouton scanner.
Accès à l’appareil photo. Conforme
Tableau 24: Tests
Conclusion
Tout au long de ce chapitre, nous avons décrit le déroulement de troisième et quatrième
sprint. Nous avons commencé par définir le backlog de chaque sprint, ensuite nous avons effectué
une étude fonctionnelle. Nous avons détaillé par la suite la partie conception et la partie réalisation
dans laquelle nous avons présenté quelques interfaces. Nous présentons, dans la conclusion
générale, un résumé du travail effectué ainsi que nos acquis sur le plan personnel et professionnel.
69. Conclusion générale et perspectives
60
Conclusion générale et perspectives
Ce stage était une contribution à notre formation pratique (recherche, analyse,
développement, validation et test) et une initiation à la vie professionnelle. En effet, durant cette
période nous avons découvert l’importance des rapports socioprofessionnels, le plan des relations
(verticales et horizontales) et de la communication. En plus c’était l’occasion pour
l’approfondissement de l’esprit d’analyse, de synthèse et de logique. C’était une acquisition du
savoir faire et du savoir être (adaptation à une dynamique de groupe).
Nous sommes vraiment très satisfaits des résultats de notre projet de fin d’études, où tout s’est
très bien déroulé. Les principaux objectifs ont été atteints.
Ce projet nous a permis de découvrir le fonctionnement de Framework « React Native ». Il nous
a permis également d’acquérir des connaissances techniques et méthodologiques sur la manière
avec laquelle nous pouvons développer une application mobile cross plateforme.
Cette expérience nous a permis d’acquérir une vision plus claire sur le développement
d’application mobile et de mieux appréhender les problèmes que peut rencontrer un développeur.
Tout au long de notre cycle de développement nous avons utilisé SCRUM qui est une méthode
agile dédiée à la « gestion de projets ». Nous souhaitons que notre travail ait accompli ses objectifs,
mais, comme tout travail humain, il ne peut prétendre à la perfection.
Enfin, nous tenons à signaler que l’application mobile est évolutive, extensible et toujours ouverte
à l’enrichissement et au développement, dans un souci de perfectionnement.
70. Webographies
Webographies
[1] Scrum (dernier accès le 18 septembre 2019). Scrum, Méthodologie.
http ://scrummethodology.com/
[2] Méthodologie agile, (dernier accès le 17 septembre 2019). Scrum, Agile.
https://agiliste.fr/introduction-methodes-agiles/
[3] UML (dernier accès le 18 septembre 2019). UML, Présentation UML.
https://www.uml.org/what-is-uml.htm
[4] Adobe XD (dernier accès le 18 septembre 2019). Adobe XD, Prototype.
https://www.adobe.com/support/golive
[5] Star UML (dernier accès le 18 septembre 2019). StarUml, Définition de logiciel.
http://www.methodsandtools.com/tools/staruml.php
[6] NodeJS (dernier accès le 18 septembre 2019). JavaScript, Définition de logiciel.
http://baudet.me/2015/06/introduction-a-node-js/
[7] Visual Studio Code (dernier accès le 18 septembre 2019). VSC, Définition de logiciel.
https://code.visualstudio.com/docs/editor/editingevolved
[8] Architecture (dernier accès le 18 septembre 2019). React Native, Architecture.
https://oneshoe.com/blog/the-benefits-of-building-your-business-apps-with-react-native/
[9] Diagramme de déploiement (dernier accès le 18 septembre 2019). UML, Déploiement.
http ://laurent-audibert.developpez.com/Cours-UML