Remerciements

Nous remercions dans un premier lieu, tous ceux qui ont participé de différentes façons à
la réussite de notre projet.

Nous remercions notre encadrant monsieur Kamel ben Rhoma à SESAME pour l’aide et les
conseils concernant les missions évoquées dans ce rapport, pour son énorme soutien moral, et
qu’elle nous a apporté lors des différents suivis
Nous remercions aussi tous nos enseignants à Institut supérieur des études technologiques
Rades pour les connaissances qu’ils nous ont inculqué tout au long de notre cursus
universitaire.

Nous adressons nos remerciements aux membres du jury pour avoir accepté de juger ce
travail.
 Table des matières
Introduction générale ....................................................................................................................................1

Chapitre 1 : Etude préalable ..........................................................................................................................2

1. Introduction ........................................................................................................................................3

2. Présentation générale de l’organisme ................................................................................................3

3. Etude de l’existant ..............................................................................................................................3

3.1. Analyse de l’existant ................................................................................................................... 3

3.2. Critique de l’existant ................................................................................................................... 6
3.3. Proposition de différentes solutions ............................................................................................8
4. Choix méthodologique........................................................................................................................9

4.1. Définition .................................................................................................................................... 9

4.2. Scrum ........................................................................................................................................ 10
4.3. Les points forts de la méthode agile ......................................................................................... 11
4.4 Modélisation avec UML ............................................................................................................ 12
5. Conclusion........................................................................................................................................ 13

Chapitre 2 : Mise en œuvre ........................................................................................................................ 14

1. Introduction ..................................................................................................................................... 15

2. Planification ..................................................................................................................................... 15

2.1. Définition des rôles ................................................................................................................... 15

3. Sprint (0) 15

3.1. Définition .................................................................................................................................. 15

3.2. Spécification des besoins .......................................................................................................... 15
3.3. Backlog des produits ................................................................................................................. 20
4. Environnement et outils de développement ................................................................................... 21

4.1 Environnement matériel ........................................................................................................... 21

4.2 Environnement logiciel ............................................................................................................. 21
 5. Architecture logicielle de l’application ............................................................................................ 24

6. L’architecture MVC .......................................................................................................................... 25

7. Diagramme de déploiement ............................................................................................................ 26

8. Conclusion........................................................................................................................................ 26
Chapitre 3 : Sprint 1 .................................................................................................................................... 27

1. Introduction ..................................................................................................................................... 28

2. Diagramme de cas d’utilisation de sprint (1) ................................................................................... 28

3. Description des cas d’utilisations (user stories)............................................................................... 29

4. Conception ....................................................................................................................................... 31

4.1. Le diagramme de classe du Sprint (1) ....................................................................................... 31

4.2 Les diagrammes des séquences du Sprint (1) ........................................................................... 32
5. Réalisation et tests........................................................................................................................... 33

5.1 Interfaces liées à un utilisateur ................................................................................................. 33

5.2 Interfaces liées à un administrateur ......................................................................................... 37
6. Burndown Chart ............................................................................................................................... 39

7. Conclusion........................................................................................................................................ 39

Chapitre 4 : Sprint 2 .................................................................................................................................... 40

1. Introduction ..................................................................................................................................... 41

2. Diagramme de cas d’utilisation de sprint (2) ................................................................................... 41

3. Description des cas d’utilisations (user stories)............................................................................... 42

4 Conception ....................................................................................................................................... 44

4.1 Le diagramme de classe du Sprint (2) ....................................................................................... 44

4.2. Le diagramme de séquence du Sprint (2) ................................................................................. 45
5. Réalisation et tests........................................................................................................................... 45

5.1. Interfaces liées à un utilisateur ................................................................................................. 45

5.2. Interface liée à un administrateur ............................................................................................ 47
5.3. Interface liée à un coach ........................................................................................................... 49
5. Burndown Chart ............................................................................................................................... 50
 6. Conclusion........................................................................................................................................ 50

Chapitre 5 : Sprint 3 .................................................................................................................................... 51

1. Introduction ..................................................................................................................................... 52

2. Diagramme de cas d’utilisation de sprint (3) ................................................................................... 52

3. Description des cas d’utilisations (user stories)............................................................................... 53

4. Conception ....................................................................................................................................... 55
4.1. Diagramme de classe du Sprint (3) ........................................................................................... 55
4.2. Le diagramme de séquence du Sprint (3) ................................................................................. 56
5. Réalisation et tests........................................................................................................................... 57

5.1. Interface liée à un coach ........................................................................................................... 57

5.2. Interface liée à un utilisateur .................................................................................................... 58
5.3 Interface liée à un administrateur ............................................................................................ 59
6. Burndown Chart ............................................................................................................................... 59

7. Conclusion........................................................................................................................................ 59

Conclusion Générale ................................................................................................................................... 60

Bibliographie ............................................................................................................................................... 62
 Liste des Figures
Figure 1: Interface plateforme coursera .........................................................................................................4
Figure 2: Interface plateforme edX ................................................................................................................4
Figure 3:Interface plateforme Udemy ............................................................................................................5
Figure 4 : Interface OpenClassrooms .............................................................................................................5
Figure 5:Interface site W3Schools .................................................................................................................6
Figure 6: Schéma de processus Scrum ...........................................................................................................9
Figure 7: Schéma de processus Scrum (2) ...................................................................................................11
Figure 8: Diagramme de cas d’utilisation globale........................................................................................19
Figure 9: Architecture logicielle ..................................................................................................................24
Figure 10: Architecture MVC ......................................................................................................................25
Figure 11: Diagramme de déploiement ........................................................................................................26
Figure 12: Diagramme de cas d’utilisation de sprint (1)..............................................................................28
Figure 13: Diagramme de classe de sprint (1) .............................................................................................31
Figure 14: Diagramme de séquence objet « s’authentifier » ........................................................................32
Figure 15: Diagramme de séquence objet « ajouter un cours » ...................................................................33
Figure 16: Page d’accueil .............................................................................................................................34
Figure 17: Page « inscription » ....................................................................................................................35
Figure 18: Page « s’authentifier » ................................................................................................................36
Figure 19: Page « compte utilisateur » .........................................................................................................36
Figure 20: Page « modifier mot de passe » ..................................................................................................37
Figure 21 : Page « liste des cours » ..............................................................................................................37
Figure 22: Page « ajout d’un cours » ...........................................................................................................38
Figure 23: Page « modification d’un cours » ...............................................................................................38
Figure 24: Page liste des utilisateurs ............................................................................................................39
Figure 25: Burndown chart Sprint 1 ............................................................................................................39
Figure 26:Diagramme de cas d’utilisation de sprint (2)...............................................................................41
Figure 27 : Diagramme de classe de sprint (2) ............................................................................................44
Figure 28 : Diagramme de séquence objet « traiter demande du coach » ....................................................45
Figure 29 : Page s’inscrire à un cours ..........................................................................................................46
Figure 30: Page consulter liste des cours .....................................................................................................47
Figure 31: Page consulter liste des coachs 47
Figure 32: Page traiter demande coach ........................................................................................................48
Figure 33 : Page envoyer demande ..............................................................................................................49
Figure 34: Burndown chart Sprint 2 ............................................................................................................50
Figure 35: Diagramme de cas d’utilisation de sprint (3) .............................................................................52
Figure 36: Diagramme de classe de sprint (3) .............................................................................................55
Figure 37: Diagramme de séquence objet « répondre aux questions »........................................................56
Figure 38 : Page List de question envoyer par l’admin ...............................................................................57
Figure 39: Page envoyer question ................................................................................................................58
Figure 40: Page consulter réponse ...............................................................................................................58
Figure 41: Page List de question envoyer par user ......................................................................................59
Figure 42: Burndown chart Sprint 3 ............................................................................................................59
 Liste des Tableaux
Tableau 1: récapitule les avantages et les inconvénients de tous les outils traités .........................................8
Tableau 2: Rôle des membres de scrum .......................................................................................................15
Tableau 3: Planification des Sprints .............................................................................................................20
Tableau 4: backlog du sprint (1) ..................................................................................................................28
Tableau 5: description de cas d’utilisation « Ajouter cours » ......................................................................29
Tableau 6: description de cas d’utilisation « Modifier cours » ....................................................................30
Tableau 7: description de cas d’utilisation « supprimer cours » ..................................................................30
Tableau 8: description de cas d’utilisation « Bloquer utilisateur » ..............................................................31
Tableau 9: backlog du sprint (2) .................................................................................................................41
Tableau 10: description de cas d’utilisation « Bloquer coach » ...................................................................42
Tableau 11: description de cas d’utilisation « S’inscrire à une cour » .........................................................42
Tableau 12: description de cas d’utilisation « envoyer demande d’être un coach » ....................................43
Tableau 13: description de cas d’utilisation « traiter demande du coach » ..................................................43
Tableau 14: backlog du sprint (3) ...............................................................................................................52
Tableau 15: description de cas d’utilisation « demande une information du coach ou rendez-vous » ........53
Tableau 16: description de cas d’utilisation « répondre aux questions des utilisateurs et accepter ou
refuser un rendez-vous » ..............................................................................................................................54
 Introduction générale

De nos jours, la matière grise représente la plus grande richesse d’un pays. La formation devient
donc un enjeu essentiel.

Chaque jour, les technologies progressent, les métiers évoluent, l’organisation change, les méthodes
d’enseignement se transforment. Les besoins augmentent tant pour la formation initiale que
continue, les internautes sont de plus en plus curieux surtout en ce qui concerne les technologies
informatiques.

L’école n’est plus suffisante pour acquérir toutes les connaissances désirées tandis que le monde
est maintenant plus que jamais, concernés par les effets de la mondialisation dont les nouvelles
technologies de l’information et de la communication alors nous devons, dès à présent, penser «
apprentissage rapide et efficace », avec un minimum de problèmes d’organisation, de logistique
et surtout de perte de temps et avec virus « COVID-19 » qui menace le monde. De ce fait,
l’apprentissage en ligne est la solution. Ceci rend de plus en plus facile le fait d’apprendre et de
partager ces connaissances avec le monde entier.

Dans ce cadre intervient notre projet visant à mettre en œuvre les connaissances acquises lors de
notre formation au sein de SESAME dont l’objectif est de développer une plateforme tunisienne
d’éducation 100 % en ligne.
 Chapitre 1 : Etude préalable

1. Introduction
Ce chapitre a pour objectif de situer notre sujet dans son contexte général. Nous commençons par
une présentation d'une étude de l’existant et une analyse des applications similaires ainsi qu’une
critique de l’existant, et nous proposons des solutions qui pourront remédier aux problèmes
constatés, Enfin nous présentons le choix de la méthodologie de développement.

2. Etude de l’existant
Cette section a pour objectif d’étudier fait le tour sur les solutions de E-Learning les plus connues
sur le marché. Cette étude permet de dégager les points forts et les points faibles de chacune ces
solutions. Dans ce qui suit, nous présentons une analyse de l’existant, puis nous détaillons la
critique de l’existant.

3.1. Analyse de l’existant

La formation continue se fait actuellement de façon traditionnelle : cours, apprenants et formateurs
sur place. Ce type de formation présente beaucoup d’inconvénients tels que :Contrainte du nombre
de Places limitées

✓ Contrainte du nombre de salles réduites

✓ Charge élevée de la formation

Dans le but de résoudre ces inconvénients plusieurs outils ont étais créer à base des
nouvelles technologies. Parmi lesquels nous pouvons citer :

Coursera, edX, Udemy, OpenClassrooms, w3Schools

❖ Coursera
 Figure 1 : Interface plateforme coursera
Coursera est une plate-forme de cours en ligne qui propose des formations en ligne en
collaboration avec certaines des meilleures universités de la planète. Les cours proposés vont des
formations rapides (également appelés « Massive Open Online Courses », ou MOOCS) aux
spécialisations sur des sujets particuliers et diplômes en ligne. UNvaste éventail de possibilités
s’offre donc à vous.
❖ edX
EdX est une plateforme d'apprentissage en ligne (dite FLOT ou MOOC). Elle héberge et met
gratuitement à disposition des cours en ligne de niveau universitaire à travers le monde entier. Elle mène
également des recherches sur l'apprentissage en ligne et la façon dont les utilisateurs utilisent celle-ci. Elle
est à but non lucratif et la plateforme utilise un logiciel open source.

❖ Udemy

Figure 3: Interface plateforme Udemy

Udemy propose une pléiade de cours en ligne, à la fois pour le plaisir et destinés à développer des
compétences concrètes susceptibles de booster votre carrière.
Et bien qu’Udemy puisse être votre plate-forme idéale dans certaines situations, il existe plusieurs raisons
pour lesquelles une autre plate-forme de cours en ligne pourrait s’avérer plus adaptée.
❖ OpenClassrooms

Figure 4 : Interface OpenClassrooms

OpenClassrooms est une école en ligne offrant des parcours diplômants et professionnalisants à plus de
trois millions d'étudiants chaque mois à travers le monde. Quelle que soit votre ambition,
OpenClassrooms peut vous aider à bâtir votre avenir.

❖ W3Schools

Figure 5: Interface site W3Schools

W3Schools est un site de développeurs Web, avec des tutoriels et des références sur les langages de
développement Web tels que HTML, CSS, JavaScript, PHP, SQL, Python, jQuery, Java, C ++, C #,
React, XML, W3.CSS et Bootstrap, couvrant la plupart aspects de la programmation Web.

3.2. Critique de l’existant

Outils Avantage Inconvénients
Coursera ▪ La variété des thèmes ▪ L’absence d’attestation de
▪ La présence de cours ouverts réussite gratuite. Les cours
toute l’année que l’on peut que l’on a réussis sans payer
suivre à son rythme sont simplement listés dans
▪ La présence son profil.
d’établissements prestigieux ▪ Des cours en français peu
du monde entier et de cours nombreux même si certains
de très grande qualité cours en anglais peuvent
▪ Les cursus composés de avoir des sous-titres français
MOOC pour tout apprendre
sur un sujet en particulier et
devenir un expert (malgré le
prix élevé du dispositif).
edX ▪ La majorité des cours sont
full vidéo, mais on peut
également trouver des textes, ▪ Beaucoup de cours en

des graphiques et des anglais, ce qui peut limiter la

ressources téléchargeables compréhension ou même

(dans le domaine du l’accessibilité

développement personnel par ▪ Parfois, l’attestation n’est

exemple) disponible qu’en payant

▪ Des attestations de suivi, (notamment ceux de Harvard

qu’on peut ajouter à Viadeo ou du MIT). Il reste tout de

ou LinkedIn. L’ajout à même la possibilité

LinkedIn se fait en 2 clics d’imprimer le relevé de notes

▪ Les thèmes abordés sont très pour attester de la réussite

variés. ▪ Les forums pas pratiques,

▪ Des partenariats avec de qui peuvent être très long à

grandes écoles, ce qui, sur un charger s’il y a beaucoup de

CV, peut être valorisé. réponses.

▪ La possibilité de croiser des

apprenants du monde entier.
Udemy Udemy propose une pléiade de Le fait qu’Udemy soit si ouvert
cours en ligne, à la fois pour le n’est pas très attractif pour les
plaisir et destinés à développer formateurs. Par conséquent, les
des compétences concrètes instructeurs renommé et
susceptibles de booster votre professeurs d’université sont rares
carrière.
Certains cours sont tout
simplement de mauvaise
qualité. Je pourrais d’ailleurs
publier un cours médiocre dès
demain si je le souhaitais
 OpenClassrooms OpenClassrooms offre plus d’un Le petit hic avec Openclassrooms
millier de tutoriels visant surtout est la prédominance des tutoriels
les débutants. Il s’agit des métiers du web. Conçue
majoritairement de cours initialement pour traiter des sujets
concernant la programmation de développement informatique, la
informatique et autour des métiers plateforme n’affiche que peu de
du web. souplesse sur son programme
d’enseignement des années après
sa conception.
Aussi

W3Schools W3Schools met l'accent sur la

simplicité, pratique un
apprentissage simple et direct il
utilise des explications de code
simples avec des illustrations
simples de son utilisation.
Les tutoriels de W3Schools
partent du niveau de base et
remontent jusqu'aux références
professionnelles

Tableau 1: récapitule les avantages et les inconvénients de tous les outils traités.

Notre étude a montré que les solutions du marché n’offrent pas les fonctionnalités nécessaires à une
plateforme de E-Learning (coaching ……) Notre application tente à d’être parmi les premières
plateformes tunisienne qui intégrer ces différentes fonctionnalités et confronte les inconvénients des
solutions existants.

3.3. Proposition de différentes solutions

L’étude d’existant nous a permis de dégager plusieurs anomalies que nous avons détailles

Solution nous envisageons que :

✓ Notre plateforme de e-learning soit basée sur un environnement d'apprentissage plus confortable,
ce qui évitera les problèmes de compatibilité avec le système d'exploitation du formateur et celui
des apprenants.
✓ Notre plateforme doit être rapide (temps de connexion, temps de sharing) et fluide (Fluidité audio
et vidéo). Étant donné le nombre de fonctionnalités importantes, elle devra aussi offrir une
simplicité d’utilisation et surtout ergonomie d’interface.
 ✓ Notre plateforme offre Liberté et qualité d’enseignement.
✓ Assure Commodité et flexibilité.
✓ Faciliter Avancement de carrière pour les apprenants.

3. Choix méthodologique
4.1. Définition

Une méthode Agile est une approche itérative et collaborative, capable de prendre en compte les besoins
initiaux du client et ceux liés aux évolutions.

Figure 6: Schéma de processus Scrum

La méthode Agile se base sur un cycle de développement qui porte le client au centre. Le client est
impliqué dans la réalisation du début à la fin du projet. Grâce à la méthode agile le demandeur obtient une
meilleure visibilité de la gestion des travaux qu’avec une méthode classique.
L’implication du client dans le processus permet à l’équipe d’obtenir un feedback régulier afin
d’appliquer directement les changements nécessaires.
Cette méthode vise à accélérer le développement d’un logiciel. De plus, elle assure la réalisation d’un
logiciel fonctionnel tout au long de la durée de sa création.

Le principe de base consiste à proposer une version minimale du logiciel puis à intégrer des
fonctionnalités supplémentaires à cette base, par processus itératif. Le processus itératif regroupe une
séquence d’instructions à répéter autant de fois que possible, selon le besoin. En ce qui concerne la
réalisation d’un logiciel, les instructions à répéter sont les suivantes :

• Les tests unitaires À la fin de chaque itération

• Le développement de l’application web
• L’intégration
 • La relecture et amélioration des codes

La méthode agile nommée Manifeste Agile repose sur quatre grands principes :

• COLLABORATION : Communication et cohésion d’équipe passent avant les outils et les

processus.
• EQUIPE : Le privilège de la relation équipe/client est mis en avant plutôt que la négociation
contractuelle.
• APPLICATION : Préférer une application bien construite à une documentation détaillée.
• ACCEPTATION : Le choix de l’acceptation du changement et de la flexibilité au détriment d’un
plan rigide.

En effet le changement de contexte et les modifications interviennent dans le processus suite aux
demandes du client qui feront évoluer le projet plus rapidement.

Tous les jours à horaire régulier un « stand up meeting » est réalisé. Lors de ce bref point quotidien
d’environs chaque membre de l’équipe va :

• Relater les faits actuels

• Partager les actions à prévoir pour le lendemain
• Exprimer les obstacles rencontrés et les difficultés encourues

4.2. Scrum
« Scrum » est la méthode agile la plus populaire. Ce terme signifie « mêlée » au rugby. La méthode
scrum s’appuie sur des « sprints » qui sont des espaces temps assez courts pouvant aller de quelques
heures jusqu’à un mois. Généralement et de préférence un sprint s’étend sur deux semaines. À la fin de
chaque sprint, l’équipe présente ce qu’elle a ajouté au produit. Scrum regroupe trois acteurs :

• Le Product Owner : qui porte la vision du produit à réaliser (représente généralement le client).
Il gère le Backlog du Produit, défini des priorités et accepte ou rejette les livrables
• Le Scrum Master : membre de l’équipe, il a pour but d’optimiser la capacité de production de
l’équipe. Pour se faire, le scrum master aide l’équipe à travailler de façon autonome tout en
s’améliorant d’avantage.
• L’équipe opérationnelle (qui regroupe idéalement moins de dix personnes) : la particularité
d’une équipe scrum est qu’elle est dépourvue de toute hiérarchie interne. Une équipe scrum est
autoorganisée.
 D’autres termes sont à connaître pour comprendre la méthode scrum :
• Le product backlog (carnet du produit) : ce document contient les exigences initiales dressées
puis hiérarchisées avec le client en début de projet. Néanmoins il va évoluer tout au long de la
durée du projet, en fonction des divers besoins du client.
• Le sprint backlog (carnet de sprint) : en chaque début de sprint, l’équipe définit un but. Puis lors
de la réunion de sprint, l’équipe de développement choisit les éléments du carnet à réaliser.
L’ensemble de ces éléments constitue alors le sprint backlog.
• User story : ce terme désigne les fonctionnalités décrites par le client.
• Stand up meeting (scrum) : c’est une réunion d’avancement organisée de manière quotidienne
durant le sprint.

Figure 7: Schéma de processus Scrum (2)

4.3. Les points forts de la méthode agile

• L’équipe fait peu de hors sujet car cette méthode assure une bonne et constante
communication entre le client et l’entreprise
• La documentation est réduite, ainsi l’efficacité en termes de productivité est en augmentation
• La collaboration avec le client s’effectue de façon quotidienne
• Une version fonctionnelle du logiciel est livrée fréquemment
• La recherche constante de l’excellence technique : des tests sont réalisés en continu
• Le résultat est percevable petit à petit, ce qui permet d’éviter les mauvaises surprises

En clair, la méthodologie Agile est une méthode moderne, favorisant un gain de productivité non
négligeable, et la baisse des coûts de production
 4.4 Modélisation avec UML
Vu l’importance cruciale de la modélisation dans le cycle de vie de n’importe quelle application, il fallait
utiliser une méthode de modélisation qui s’adapte le mieux à nos besoins et à nos exigences qui sont entre
autres : L’ouverture, la réutilisabilité, la modularité et l’extensibilité.

Pour répondre à ces exigences, nous avons choisis de modéliser avec le langage de modélisation UML qui
s’adapte parfaitement à la modélisation des applications à base d’objets et qui offre grâce à ses différents
diagrammes une grande souplesse permettant la modélisation de différents aspects de l’application.

Notre choix de ce langage se justifie aussi par le fait qu’UML est devenu un standard de modélisation
adopté pour toutes les applications à aspect orienté objet.

4.4.1 Définition de UML

UML (Unified Modeling Langage) : Se définit comme un langage de modélisation graphique et textuel
destiné à comprendre et décrire des besoins, spécifier, concevoir des solutions et communiquer des points
de vue.

UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas d’une simple notation, mais
les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre
que les mots d’un langage, c’est pour ça qu’UML est présenté parfois comme une méthode alors qu’il ne
l’est absolument pas.

UML unifie également les notations nécessaires aux différentes activités d’un processus de développement
et offre, par ce biais, le moyen d’établir le suivi des décisions prises, depuis la définition des besoins
jusqu’au codage.

4.4.2 Les Diagrammes de UML

Ci-dessous une présentation rapide des différents diagrammes UML qui vont être utilisés tout au long du
projet :

Le diagramme des cas d’utilisation : Il représente la structure des fonctionnalités nécessaires aux
utilisateurs du système. Il est normalement utilisé lors des étapes de capture des besoins fonctionnels et
techniques ;

Le diagramme de classes : Sûrement l’un des diagrammes les plus importants dans un développement
orienté objet. Sur la branche fonctionnelle, ce diagramme est prévu pour développer la structure des entités
manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure d’un code
orienté objet.
Le diagramme de séquences : Il représente les échanges de messages entre objets, dans le cadre d’un
fonctionnement particulier du système.

4. Conclusion
Au cours de ce chapitre, nous avons réussi à mettre le point sur l’organisme qui nous a ouvert les bras tout
au long de cette période de stage. Puis nous avons étudié les exemples existants et les critiquer en proposant
une solution. Finalement nous avons dégagé le choix méthodologique
 Chapitre 2 : Mise en œuvre
1. Introduction
Dans ce chapitre, nous avons suivi la méthodologie agile SCRUM pour mettre en œuvre notre application
web en respectant le processus

2. Planification
Dans scrum la planification se fait par niveau, chaque niveau correspondant à un Sprint.

2.1. Définition des rôles

Le tableau suivant présente les membres de scrum et leurs rôles :

Rôle Membre
Le propriétaire du produit (Product owner) Naffati Ahmed
Le directeur du produit (SCRUM Master) Naffati Ahmed
Le membre de l'équipe (SCRUM Team) Waddani Mayem,Sarra dridi , Naffati
Ahmed
Tableau 2 : Rôle des membres de scrum

3. Sprint (0)
3.1. Définition
Le sprint 0, l’itération 0 ou l’exploration est un élément important pour mettre les bonnes bases d’un
nouveau projet IT et pour permettre à une nouvelle équipe de se former et d’apprendre à travailler
ensemble.

3.2. Spécification des besoins

Dans cette partie, nous abordons la phase spécification informelle des besoins. Ainsi, nous présentons les
besoins fonctionnels et non fonctionnels du site.

3.2.1. Besoins fonctionnels

Il s’agit de décrire des fonctionnalités du système. Ce sont les besoins spécifiant un comportement
d’entrée/sortie du système. Dans cette phase, nous identifions les fonctionnalités qui devront être respectées
pour obtenir l’objectif visé.

Les fonctionnalités que nous nous proposons de fournir dans notre système sont les suivantes :

❖ Espace user
• Espace public : nous allons présenter les fonctionnalités des internautes lors de leur
 navigationS’inscrire à une session : L’internaute doit s’inscrire à une session pour avoir les
droits dédiés seulement aux membres.

• dans la plateforme.
• Authentification : L’utilisateur doit s’identifier via un login et un mot de passe pour que le
système le redirige vers son espace approprié.
• Demander information coach : l’internaute demander information coach et peut demander rendez-
vous
• Consulter cours : l’internaute peut consulter les cours publics
❖ Espace administration
C’est un espace accessible uniquement par l’administrateur. L’administrateur est le super utilisateur pour
cela qu’il a tous les droits dans cette application. Ses fonctionnalités sont :
• Authentification : L’administrateur doit s’identifier via un login et un mot de passe pour que le
système le redirige vers son espace approprié.
• Gestion des cours : permet d’ajouter, consulter, modifier et supprimer les cours publiées.
• Gestion des coachs : L’administrateur peut accepter ou refuse demande du coach et consulter et
bloquer les comptes des coachs.
• Gestion des utilisateurs : permet consulter et bloquer les comptes des utilisateurs
❖ Espace coach

C’est un espace accessible uniquement par coach ses fonctionnalités sont :

• Authentification : Le coach doit s’identifier via un login et un mot de passe pour que le système le
redirige vers son espace approprié.
• Réponde aux questions des utilisateurs
• Accepter ou refuser les rendez-vous

3.2.2. Besoins non fonctionnels

Une fois les besoins fonctionnels sont spécifiés, il est très important de passer à la spécification non
fonctionnelle. Il s’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les contraintes
d’implémentation (langage de programmation, type SGBD, de système d’Exploitation, etc.). Dans le cadre
de ce travail, le site doit être extensible, c’est-à-dire qu’ils pourront y avoir une possibilité d’ajouter des
nouvelles fonctionnalités facilement.

❖ L’arborescence élaborée
Elle doit être la plus logique possible et on doit aussi veiller à ce que l’internaute /adhérent ne se
 sente jamais perdu.
❖ Ergonomie de l’interface
La composition des interfaces doit être claire, lisible et attirante pour satisfaire
l’internaute/adhérent.
❖ La gestion des erreurs

Notre plateforme doit gérer mieux ces exceptions par l’apparition d’une d’erreur qui permettra de filtrer les
données et de ne prendre en considération que les données qui correspondent aux types adéquats et qui
permettra de contrôler les champs de saisie.

Les erreurs possibles sont :

– L’identifiant ou mot de passe incorrect.

– Vérification si un utilisateur possède déjà un compte.

– Champ oublié pendant le remplissage des formulaires.

❖ Contraintes techniques

Nous avons fixé les contraintes techniques. Nous Obtenons l’ensemble des contraintes suivantes

• Portabilité du site : la plateforme doit être fiable et performante.

• Confidentialité : Les informations enregistrées dans les comptes privés sont strictement interdites
aux étrangers. Les utilisateurs de la plateforme sont identifiés en fonction de leur identifiant, de leur
mot de passe.
• Traitement optimisé des requêtes : Le traitement des requêtes doit être réalisé en un temps optimal.
Il faudra savoir gérer l’accès aux bases de données en fonction de la contrainte « temps ».
• Originalité de l’interface : En effet, la plateforme doit être facile à comprendre, facile à gérer et à
manipuler

3.2.3. Les Acteurs de notre application

Un acteur est une entité externe au système :

• Qui attend un ou plusieurs services du système

• A qui le système fournit une interface d'accès

• Qui interagit avec le système par l'envoi / réception des messages

• C'est une personne ou un autre système informatique.

 • Leurs relations avec les cas d'utilisation.

Dans notre application nous avons 3 acteurs principaux :

• User
• Coach
• Admin
 3.2.4. Diagramme de cas d’utilisation globale

Nous présentons ci-dessous un diagramme de cas d’utilisation global qui regroupe tous les cas
d'utilisation de notre application. Ce diagramme décrit les besoins fonctionnels de façon globale de
notre application et il définit aussi les rôles de chaque acteur.

Figure 8: Diagramme de cas d’utilisation globale

 3.3. Backlog des produits
3.3.1. Définition

Elément clé de tout projet utilisant la méthode Scrum, Le backlog produit ou backlog scrum doit être défini
et entretenu soigneusement. Que doit-il contenir, comment le construire ? Nous allons essayer d’apporter
des réponses à ces questions dans une définition backlog simple.

Le backlog scrum est destiné à recueillir tous les besoins du client que l’équipe projet doit réaliser. Il
contient donc la liste des fonctionnalités intervenant dans la constitution d’un produit, ainsi que tous les
éléments nécessitant l’intervention de l’équipe projet. Tous les éléments inclus dans le backlog scrum sont
classés par priorité indiquant l’ordre de leur réalisation.

3.3.2. Planification des sprints

La réunion de planification des Sprints est l’événement le plus important dans SCRUM. Le but de cette
réunion est de préparer le planning de travail et d’identifier le Backlog des Sprints. L’un des produits
de cette réunion est le choix de la durée des Sprints et qui diffère selon la complexité du projet et la taille
de l’équipe. Pour notre projet nous avons choisi de développer une seule version. Le tableau ci- dessous
résume notre planning de travail :

Sprint 1 Sprint 2 Sprint 3

De 01/04/2020 De 15/05/2020 De 01/07/2020
User : User : User :
• Consulter les cours (ces • S’inscrire à une • Demander une
sections et ces vidéos) session information du
coach ou rendez-
Admin : Admin : vous
• Gestion des cours (ajouter. • Gestion des profs (traiter Coach :
Modifier, consulter, et demande prof, consulter
• Répondre aux
supprimer cours) prof, bloquer prof)
questions des
• Gestion des utilisateurs Coach :
(consulter et bloquer utilisateurs et
• Envoyer demande
utilisateurs) accepter ou refuser
d’être un coach
rendez-vous

Tableau 3: Planification des Sprints

4. Environnement et outils de développement
Dans cette partie de notre rapport nous allons focaliser sur l’environnement matériels et logiciel de notre
plateforme.

4.1 Environnement matériel

Pendant la phase de développement nous avons utilisé :

• Environnement A :

• Modèle : DELL. • Processeur : Intel R

Core (TM) i3 6500M CPU @ 2.20 GHz 2.60 GHz. • Mémoire installée (RAM) :4,00 Go. • Système
d’exploitation : Windows 10 / 64bits.

• Environnement B :

• Modèle : Asus. • Processeur : Intel R

Core (TM) i7 2350M CPU 2.20 GHz • Mémoire installée (RAM) : 8,00 Go. • Système d’exploitation :
Windows 10 / 64bits.

• Environnement C :

• Modèle : MAC. • Processeur : Intel R

Core (TM) i5 2350M CPU 2.20 GHz • Mémoire installée (RAM) : 8,00 Go. • Système d’exploitation :
MAC OS / 64bits.

4.2 Environnement logiciel

Nous allons présenter les outils techniques et les langages de programmation que nous avons utilisée dans
ce projet. Les différents outils pour la réalisation de ce projet sont :

4.2.1. Environnement de développement intégré :

Visual studio code : C’est un éditeur de code qui admet plusieurs

langages de programmation et qui offre plusieurs fonctionnalités. Il est
considéré comme une open source à multiplateforme. Nous avons utilisé
Visual Studio code pour développer avec le Framework Angular
Eclipse IDE : C’est un environnement de développement écrit en java, il
intègre plusieurs fonctionnalités et supporte des différents langages de
programmation, nous avons utilisé éclipse pour développer avec le
Framework Spring boot. Pour faciliter le développement avec Spring boot
nous intégrons Spring Tools Suite dans Eclipse IDE, il ajoute des
Fonctionnalités spécifiques à ce Framework.
 4.2.2 Les logiciels utilisés :
Nous avons dans cette étape détaillé les différents langages et les logiciels utilisés.

Visual Paradigm : c’est un outil de conception qui prend en charge

le langage UML. Cet outil nous a aidé a modélisé les diagrammes de
séquence objet et les diagrammes de séquence systèmes.

Postman : C’est un API testing, c’est-à-dire grâce à poste man nous

pouvons tester nos services avec des requêtes http avons de les
consommer. Durant notre projet nous avons validé nos services à
l’aide de ce logiciel.

Star UML : est considéré comme l’outil de modélisation UML le

plus connue, il nous a permis de réaliser la conception de notre projet.
À l’aide de StarUML, nous avons modélisé nos différents
diagrammes : diagramme de séquence, diagramme de cas
d’utilisation et diagramme de classe.

XAMPP : est une distribution Apache entièrement gratuite et facile

à installer contenant MySQL, PHP et Perl. Le paquetage open source
XAMPP a été mis au point pour être incroyablement facile à installer
et à utiliser.
 4.2.3. Choix technologique :
Nous avons dans cette étape détaillé les différents langages, outils et les Frameworks utilisés.

Angular7 : est un framework basé essentiellement sur le langage de

programmation libre TypeScript. Donc Angular nous aide à la création
des classes, des variables, des interfaces et à l’importation des modules
pour les utilisée. Nous avons utilisé la version 7.

Spring Boot : est un micro framework utilisé pour faciliter la

configuration des projets Spring. Spring Boot est considéré comme un
facteur majeur de la croissance de développement rapide.

Spring Security : est un Framework léger de sécurité des projets fondés

sur spring. Il accomplit une Authentification et un appui d’autorisation
en intégrant des différents algorithmes des sécurité. L’avantage principal
de SpringSecurity est la personnalisation de sécurité informatique

Bootstrap : est un ensemble des outils utilisé pour la création du

graphisme de site ou d’application web

HTML Ce langage est utilisé pour créer des pages web. L'acronyme
signifie HyperText Markup Language, ce qui signifie en français
"langage de balisage d'hypertexte". Cette signification porte bien son
nom puisqu'effectivement ce langage permet de réaliser de l'hypertexte
à base d'une structure de balisage.

CSS 3 : Le CSS est un langage informatique utilisé sur l'internet pour

mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style,
aussi appelé les fichiers CSS, comprennent du code qui permet de gérer
le design d'une page en HTML.
5. Architecture logicielle de l’application
Pour décrire d’une manière symbolique et schématique les différents éléments de notre système leurs
interrelations et leurs interactions, On a recours à une architecture qui garantit la stabilité et l’efficacité de
notre application. C’est l’architecture trois tiers qui est élaboré pour notre plateforme qui présente trois
niveaux illustrés dans la Figure 8.

Figure 9: Architecture logicielle

• Le premier tiers est la couche présentation associée au client qui dispose d'un navigateur
web et accède à l’application. Il s‘agit d‘un ensemble de page web.
• Le 2ème tiers est la couche métier correspond à la partie fonctionnelle de l'outil qui est
déployée dans le serveur d'application et qui est chargé de fournir la ressource mais
faisant appel à un autre serveur.
• Le 3ème tiers est la couche accès aux données, elle permet de fournir au serveur
d'application les données dont il a besoin.
6. L’architecture MVC

Modèle-vue-contrôleur ou MVC est un motif d'architecture logicielle destiné aux interfaces graphiques
lancé en 1978 et très populaire pour les applications web. Le motif est composé de trois types de modules
ayant trois responsabilités différentes : les modèles, les vues et les contrôleurs.

• Un modèle (Model) contient les données à afficher.

• Une vue (View) contient la présentation de l'interface graphique.
• Un contrôleur (Controller) contient la logique concernant les actions effectuées par l'utilisateur.

Figure 10: Architecture MVC

7. Diagramme de déploiement

En vue de représenter l’aspect statique qui sert à modéliser l'utilisation de l'infrastructure physique par le
système et la manière dont les composants du système sont répartis ainsi que les relations échangées entre
eux. La Figure 9 est un aperçu de diagramme de déploiement.

Figure 11: Diagramme de déploiement

8. Conclusion :

Dans ce chapitre nous avons détaillé les besoins fonctionnels et non fonctionnels et nous avons mis l’accent
sur la décomposition des sprints Puis nous avons présente l’environnement et outils de développement,
Architecture logicielle de l’application Finalement nous avons dégagé le Diagramme de déploiement
 Chapitre 3 : Sprint 1

1. Introduction
L'objectif du Sprint (1) est de développer les cas d’utilisations représentés par le tableau suivant :

Cas d’utilisations Description

Consulter cours En tant qu’utilisateur je peux

consulter cours public
Gestion cours En tant que admin je peux consulter,
ajouter, modifier, supprimer cours
Gestion utilisateurs En tant que admin je peux consulter,
bloquer utilisateur
Tableau 4: backlog du sprint (1)

2. Diagramme de cas d’utilisation de sprint (1)

Nous présentons ci-dessous un diagramme de cas d’utilisation de sprint 1
Figure 12: Diagramme de cas d’utilisation de sprint (1)
3. Description des cas d’utilisations (user stories)
Dans le but de mieux comprendre notre système et les interactions avec les utilisateurs, dans cette partie
nous allons détailler les scenarios de principaux cas d’utilisation

Cas d’utilisations « Ajouter cours »

Acteur Administrateur

Pré-Condition Administrateur authentifié

Post-condition : Cours ajouté.

Scénario nominal 1. L’administrateur s’authentifie

2. L’administrateur choisi le menu concerné : « Gestion des Cours »
3. l’administrateur choisi l’action « Ajouter cours »
4. Le système affiche une nouvelle fenêtre contenant des champs pour la
description du cours,
5. L’administrateur introduit les données du cours à ajouter et confirme.
6. Le système vérifie les données saisies et ajoute le cours.
Scénario alternative Les informations sont manquantes ou incorrectes : ce scénario
commence au point 6 du
Scénario nominal.
1 : Le système informe l’admin que les données saisies sont
erronées, le scénario reprend au point 4 du scénario nominal.
Tableau 5: description de cas d’utilisation « Ajouter cours »
 Cas d’utilisations « Modifier cours »
Acteur Administrateur
Pré-Condition Administrateur authentifié

Post-condition Cours modifié

Scénario nominal 1. L’administrateur s’authentifie

2. L’administrateur choisi le menu concerné : « Gestion des Cours
»
3. l’administrateur choisi l’action « Modifier cours »
4. Le système affiche une nouvelle fenêtre contenant des champs
pour la description du cette cours
5. L’administrateur introduit les nouvelles données du cours à
modifier et confirme.
6. Le système vérifie les données saisies et modifie le cours.
Scénario alternative Les informations sont manquantes ou incorrectes : ce
scénario commence au point 6 du
Scénario nominal.
1 : Le système informe l’admin que les données saisies
sont erronées, garde les informations
Saisies avant et le scénario reprend au point 4 du scénario nominal.

Tableau 6: description de cas d’utilisation « Modifier cours »

Cas d’utilisation « Supprimer cours »
Acteur Administrateur
Pré-Condition Administrateur authentifié

Post-condition : Cours supprimé.

Scénario nominal 1. L’administrateur s’authentifie

2. L’administrateur choisi le menu concerné : « Gestion des Cours
»
3. l’administrateur cliquer sur le bouton supprimer d’une cour
4. Le système supprimer le cour
Scénario alternative La cour n’a pas été supprimée
1 : Le système informe l’admin que cour n’a pas supprimée et le
scénario reprend au point 2 du scénario nominal.
Tableau 7: description de cas d’utilisation « supprimer cours »
 Cas d’utilisation « Bloquer utilisateur »

Acteur : Administrateur
Pré-Condition : Administrateur authentifié

Post-condition : Utilisateur bloqué.

Scénario nominal : 1. L’administrateur s’authentifie

2. L’administrateur choisi le menu concerné : « Gestion des
Utilisateurs »
3. l’administrateur choisi l’action « Bloquer utilisateur »
4. Le système bloquer l’utilisateur

T ableau 8: description de cas d’utilisation « Bloquer utilisateur »

4. Conception
4.1. Le diagramme de classe du Sprint (1)
Le diagramme de classe est considéré comme le plus important de la modélisation orientée objet, c'est le
seul diagramme obligatoire lors d'une telle modélisation. Il permet de définir la structure interne du
système

Figure 13: Diagramme de classe de sprint (1)

 4.2 Les diagrammes des séquences du Sprint (1)
Le diagramme de séquence système est une modélisation de la vue dynamique du système. Ce diagramme
reflète les interactions et les échanges entre un acteur et le système par des messages dans leurs ordres
chronologiques

La figure 14 illustre le diagramme de séquence objet de cas d’utilisation « S’authentifier »

Figure 14 : Diagramme de séquence objet « s’authentifier »

La figure 15 illustre le diagramme de séquence objet de cas d’utilisation « Ajouter cours »

Figure 15: Diagramme de séquence objet « ajouter un cours »

5. Réalisation et tests

Dans cette partie nous allons présenter les différentes interfaces de sprint 1.

5.1 Interfaces liées à un utilisateur

5.1.1. Page d’accueil

Ce l’interface que n’importe quel visiteur peut consulter. La première interface vue au démarrage du
Plateforme A travers cette page l’utilisateur peut choisir se connecter ou bien s’inscrire et consulter les
cours
Figure 16: Page d’accueil
5.1.2. Page d’inscription

A travers la page d’inscription l’utilisateur peut créer un compte pour qu’il puisse profiter de nos services.

Figure 17: Page « inscription »

5.1.3. Page d’authentification

L’interface d’authentification qui permet de contrôler l’accès à la plateforme.

Figure 18: Page « s’authentifier »

5.1.4. Page compte d’utilisateur

A travers la page compte, l’utilisateur peut consulter ses différentes informations et peut modifier son image
et son mot de passe.

Figure 19: Page « compte utilisateur »

 Figure 20 : Page « modifier mot de passe »

5.2 Interfaces liées à un administrateur

5.2.1. Page liste des cours

Figure 21 : Page « liste des cours »

 5.2.2. Page ajouter cours

L’administrateur peut ajouter de nouveaux cours via cette interface.

Figure 22: Page « ajout d’un cours »

5.2.3. Page modifier cours

L’administrateur peut modifier de cours via cette interface.

Figure 23: Page « modification d’un cours »

 5.2.4. Page liste des utilisateurs

L’interface affiche une liste de tous les utilisateurs existants sur notre plateforme

Figure 24: Page liste des utilisateurs

6. Burndown Chart

Figure 25: Burndown chart Sprint 1

7. Conclusion

Dans ce chapitre nous avons mis l’accent sur la réalisation de sprint 1, nous avons présenté les cas
d’utilisations, détaillé la conception et en intégrant les interfaces de plateforme
 Chapitre 4 : Sprint 2

1. Introduction
L'objectif du Sprint (2) est de développer les cas d’utilisations représentés par le tableau suivant :

Cas d’utilisations Description

S’inscrire à une session En tant qu’utilisateur je peux

s’inscrire à une session
Envoyer demande d’être un coach En tant que coach je peux envoyer
demande d’être un coach
Gestion coachs En tant que admin je peux consulter,
bloquer et traiter demande d’un
coach
Tableau 9: backlog du sprint (2)

2. Diagramme de cas d’utilisation de sprint (2)

Nous présentons ci-dessous un diagramme de cas d’utilisation de sprint 2
Figure 26 : Diagramme de cas d’utilisation de sprint (2)
3. Description des cas d’utilisations (user stories)
Cas d’utilisation « Bloquer utilisateur »
Acteur : Administrateur
Pré-Condition : Administrateur authentifié

Post-condition : Coach bloqué.

Scénario nominal : 1. L’administrateur s’authentifie

2. L’administrateur choisi le menu concerné : « Gestion des Coachs »
3. l’administrateur choisi l’action « Bloquer coach »
4. Le système bloquer le coach
Tableau 10: description de cas d’utilisation « Bloquer coach »

Cas d’utilisations « s’inscrire à une cour »

Acteur : Utilisateur

Pré-Condition : Utilisateur authentifié

Post-condition : Utilisateur s’inscrire à une cour.

Scénario nominal : 1. L’utilsateur s’authentifie

2. L’utilisateur choisi une cour
3. L’utilisateur click « add to my course »
4. La cour ajoute à la liste de classes d’utilisateur
Scénario alternative : Utilisateur ne pas s’authentifier : ce scénario commence au point 3 du
scénario nominal.
1 : Le système informe l’utilisateur qu’il doit s’authentifier et
réorienter vers page login, le scénario reprend au point 1 du
scénario nominal.
Tableau 11: description de cas d’utilisation « S’inscrire à une cour »
 Cas d’utilisations « envoyé demande d’être un coach »

Acteur : Coach

Pré-Condition : Coach authentifié

Post-condition : Demande coach envoyé.

Scénario nominal : 1.Coach remplir demande avec ses données

2 Coach click sur envoyer demande
3. Le système vérifie les données saisies et enregistre.
Scénario alternative : Le coach n’a pas authentifié : ce scénario commence au point 2 du
Scénario nominal.
1 : Le système informe le coach qu’il doit s’authentifié et
réorienter vers page login, le scénario reprend au point 1 du
scénario nominal.

Tableau 12: description de cas d’utilisation « envoyer demande d’être un coach »

Cas d’utilisations « traiter demande du coach »

Acteur : Admin

Pré-Condition : Administrateur authentifié

Post-condition : Coach accepte où refuser.

Scénario nominal : 1. L’administrateur s’authentifie

2. L’administrateur choisi le menu concerné : « Gestion des Coachs »
3. l’administrateur consulter « liste des demandes envoyé par coach »
4. l’administrateur peut choisie entre accepter ou refuser
5. administrateur choisie accepter
6. un email d’acceptation va être envoyer au coach
7. admin change état d’user au coach
Scénario alternative : L’administrateur choisie refuser : ce scénario commence au point 4 du
Scénario nominal.
1 : Un email de refuse va être envoyer au coach, le scénario
reprend au point 3 du scénario nominal.
Tableau 13: description de cas d’utilisation « traiter demande du coach »
4 Conception
4.1 Le diagramme de classe du Sprint (2)

Figure 27 : Diagramme de classe de sprint (2)

 3.2.Le diagramme de séquence du Sprint (2)
La figure 28 illustre le diagramme de séquence objet de cas d’utilisation « traiter demande du coach ».

Figure 28 : Diagramme de séquence objet « traiter demande du coach »

5. Réalisation et tests

Dans cette partie nous allons présenter les différentes interfaces de sprint 2.

5.1. Interfaces liées à un utilisateur

5.1.1. Page s’inscrire à un cours
A travers cette page l’utilisateur peut s’inscrire à un cours

Figure 29 : Page s’inscrire à un cours

 5.1.2. Page consulter liste des cours

A travers cette page les utilisateurs peuvent consulter liste des cours ou se sont déjà inscrits

Figure 30: Page consulter liste des cours

5.2. Interface liée à un administrateur

5.2.1. Page gestion coachs

A travers cette page l’admin peut consulter liste des coachs

Figure 31: Page consulter liste des coachs

 5.2.2. Page traiter demande coach

A travers cette page l’administrateur peut traiter demande coach, bloquer coach

Figure 32: Page traiter demande coach

 5.3. Interface liée à un coach
5.3.1 Page envoyer demande

A travers cette page l’utilisateur peut envoyer une demande d’être coach

Figure 33 : Page envoyer demande

5. Burndown Chart

Figure 34: Burndown chart Sprint 2

6. Conclusion
Ce chapitre a été consacré à la conception détaillée de sprint 2 et nous avons également présenté un scénario
de test avec des imprimes écrans afin d’illustrer le fonctionnement de ce sprint
 Chapitre 5 : Sprint 3

1. Introduction
L'objectif du Sprint (3) est de développer les cas d’utilisations représentés par le tableau suivant :

Cas d’utilisations Description

Demander une information du coach En tant qu’utilisateur je peux

ou rendez-vous Demander une information du coach
ou rendez-vous

Répondre aux questions des En tant que coach je peux Répondre

utilisateurs et accepter ou refuser
Aux questions des utilisateurs et
rendez-vous
accepter ou refuser rendez-vous
Tableau 14 : backlog du sprint (3)

2. Diagramme de cas d’utilisation de sprint (3)

Nous présentons ci-dessous un diagramme de cas d’utilisation de sprint 3

Figure 35: Diagramme de cas d’utilisation de sprint (3)

3. Description des cas d’utilisations (user stories)
Cas d’utilisations « demande une information du coach ou rendez-vous »

Acteur : User

Pré-Condition : User authentifier

Post-condition : Demande information envoyé.

Scénario nominal : 1. user s’authentifie

2. user remplir formulaire
3. user envoyer demande au admin
4. admin recevoir une demande avec état attendre
5.admin choisi coach et réorienter vers lui
Scénario alternative : L’utilisateur n’a s’authentifié : ce scénario commence au point 2 du
Scénario nominal.
1 : Le système informe l’utilisateur qu’il doit s’authentifier et
réorienter vers page login, le scénario reprend au point 1 du
scénario nominal.
Tableau 15: description de cas d’utilisation « demande une information du coach ou rendez-vous »
 Cas d’utilisations « répondre aux questions des utilisateurs et accepter où
Refuser un rendez-vous »
Acteur : Coach

Pré-Condition : Coach authentifier

Post-condition : Répondre aux questions.

Scénario nominal : 1. coach s’authentifie

2. coach consulter « liste des questions envoyé par admin »
3. coach peut choisie entre accepter ou refuser
4. coach accepte et un champ s’affiche pour écrire réponse à l’user
5.Utilisateur consulter « liste des questions qui déjà envoyer avec ses
réponses »
6. Utilisateur lire réponse peut choisi entre satisfait ou n’a pas satisfait
7. utilisateur satisfait le question retour vers admin avec état terminé
Scénario alternative :  Utilisateur n’a pas satisfait : ce scénario commence au point 6
du
Scénario nominal.
1 : le question retour vers admin avec état attendre, il doit affecter à
un autre coach, le scénario reprend au point 1 du scénario nominal.
 Coach choisi refuser : ce scénario commence au point 3 du
Scénario nominal.
2 : cette question supprimer de la liste des questions de coach et
retour vers admin avec état attendre, il doit affecter à un autre coach,
le scénario reprend au point 1 du scénario nominal.
Tableau 16: description de cas d’utilisation « répondre aux questions des utilisateurs et accepter ou refuser un
rendez-vous »
4. Conception
4.1. Diagramme de classe du Sprint (3)

Figure 36: Diagramme de classe de sprint (3)

4.2. Le diagramme de séquence du Sprint (3)
La figure 37 illustre le diagramme de séquence objet de cas d’utilisation « répondre aux questions ».

Figure 37: Diagramme de séquence objet « répondre aux questions »

5. Réalisation et tests
Dans cette partie nous allons présenter les différentes interfaces de sprint 3.

5.1. Interface liée à un coach

5.1.1. Page List de question envoyer par l’admin

Le coach consulter List des questions que l’administrateur réoriente vers lui

Figure 38 : Page List de question envoyer par l’admin

5.2. Interface liée à un utilisateur
5.3.1. Page envoyer question

A travers cette page l’utilisateur peut envoyer question à l’administrateur

5.3.Page consulter réponse

A travers cette page l’utilisateur peut consulter ses questions avec ses réponses
5.3 Interface liée à un administrateur
5.3.1. Page List de question envoyer par user

L’administrateur consulter List des questions envoyé par utilisateur

6. Conclusion

Dans ce chapitre, nous avons mis en évidence les détails de la conception du sprint 3 en parlant dans un
premier temps De diagramme de cas d’utilisation, présente les descriptions textuelles et le diagramme de
séquence en intégrant les interfaces de plateforme
 Conclusion Générale

Le travail présenté dans ce rapport s’articule autour de la conception et la réalisation d’une plateforme
d’éducation en ligne.au sein de notre start up
Nous voulons mentionner que notre projet effectué tout au long de cette période, nous a été vraiment d’une
grande contribution sur le plan professionnel. Il nous a offert l’opportunité de nous intégrer dans
l’environnement de l'entreprenariat et d’améliorer nos capacités de communication, d’adaptation à la vie
professionnelle et au travail en équipe ce qui sera un atout dans un futur proche.
Il est très important de chercher comment se détacher du travail à la chaine surtout dans le secteur
entreprenariat. Dans notre cas, nous avons l’opportunité de se libérer de cette contrainte car notre travail
fait appel à la créativité et à l’imagination. Ces deux notions constituent des points d’orgue pour
accomplir notre tâche d’une manière efficace et utile. La réalisation du présent projet a été une occasion
favorable au cours de laquelle nous avons acquis des nouvelles connaissances théoriques et techniques.
Comme il nous a aussi offert l’occasion d’enrichir nos connaissances de gestion des ressources humaines
ainsi que de mettre en œuvre les connaissances obtenues durant notre formation à SESAME.
 Bibliographie

 https://www.w3schools.com/
 https://stackoverflow.com/
 https://medium.com/
 https://www.angularchef.com/
 https://spring.io/
 https://www.baeldung.com/