Rubrique Tunisienne

Ministère de l’Enseignement Supérieure et de la Recherche Scientifique Université

de Jendouba

Faculté des Sciences Juridique Economique et de Gestion de Jendouba

Rapport de Projet de Fin d’Etudes

Présenté en vue de l’obtention du

Diplôme de License Fondamentale en Informatique de Gestion

Par

Mahjoubi Ranya

Conception et développement d’un site web responsive pour

La Startup DATA2AI

Encadrant académique : Mr.

Sellami Mokhtar

Année universitaire : 2021/2022

 Dédicace

J’offre ce modeste travail :

A mes chers parents,
Aucune dédicace ne pourra faire témoin de mon profond amour, mon immense
gratitude et plus grand respect à votre égard. On n’oubliera jamais la tendresse
et l’amour dont vous m’avez entourée depuis mon enfance et l’encouragement
dans les moments les plus difficiles de ma scolarité.

A mes adorables frères, qui par les soutiens moraux et les encouragements,
multipliait mes efforts, pour pouvoir réaliser parfois l’impossible.

A tous mes amis, et à tous ceux qu’on aime et à toutes les personnes qui m’ont
encouragée et se donner la peine de me soutenir durant cette formation.

A mes chers enseignants sans exception.

A ceux qui me sont chers.

Mahjoubi Ranya
 Remerciement

Nous tenions tout d’abord à remercier DIEU de nous avoir donné le courage, la
force et la volonté pour achever ce travail

La réalisation de ce projet a été possible grâce aux soutiens de plusieurs

personnes à qui je voudrais témoigner toute ma gratitude

J’adresse mes vifs remerciements à toute personne contribuant de près ou de

loin à la réalisation de ce travail.

Nous tenions à remercie vivement la faculté de sciences juridiques économiques

et de gestion de Jendouba (FSJEGJ).

Mes remerciements le plus sincères à Mr. Sellami Mokhtar, mon encadrant à la

faculté de sciences juridiques économiques et de gestion de Jendouba, pour son
encadrement tout au long de notre travail.

Enfin, mes remerciements à tous mes professeurs. Ensuite, je remercie les

membres de jury pour avoir accepté d’évaluer le résultat auquel j’arrivés.
 Table des matières

Introduction Générale ............................................................................................................................. 1

Chapitre 1| Cadre de projet .................................................................................................................... 2
1 Introduction ..................................................................................................................................... 2
2 Data2AI............................................................................................................................................. 2
Problématique ................................................................................................................................. 3
3 Cahier des charges technique .......................................................................................................... 3
4 Solution proposée ............................................................................................................................ 9
5 Approche méthodologique .............................................................................................................. 9
5.1 Etude comparative de quelques méthodologies .......................................................................... 9
5.2 Choix de la méthodologie Scrum ................................................................................................ 10
5.3 Processus Scrum.......................................................................................................................... 11
5.4 Le langage UML ........................................................................................................................... 12
6 Conclusion ...................................................................................................................................... 12
Chapitre 2 | Analyse et spécification des besoins ................................................................................ 13
1 Introduction ................................................................................................................................... 13
2 Identification des acteurs............................................................................................................... 13
2.3 Analyse des besoins .................................................................................................................... 14
2.3.1 Besoins fonctionnels ................................................................................................................ 14
2.3.2 Besoins non fonctionnels ......................................................................................................... 15
2.4 Diagramme de cas d’utilisation globale ...................................................................................... 16
2.5 Le Backlog du produit.................................................................................................................. 17
3.1 Livrables du projet....................................................................................................................... 19
3.2 Risques du projet ........................................................................................................................ 19
4. Environnement de travail.............................................................................................................. 20
4.1 environnement matériel ............................................................................................................. 20
4.2 environnement logiciel ............................................................................................................... 20
4.3 Système de gestion de base de données .................................................................................... 23
4.4 Choix technologiques .................................................................................................................. 23
4.5 Organigramme des taches .......................................................................................................... 24
4.6 Planifications de projet : ............................................................................................................. 24
4.7 Diagramme de Gantt : ................................................................................................................. 24
 4.8 Architecture de l’application....................................................................................................... 25
4.8.1 Architecture 3-tiers .................................................................................................................. 25
4.8.2 Architecture logicielle : MVC.................................................................................................... 26
5. Conclusion ..................................................................................................................................... 28
Chapitre 3 |Mise en œuvre de sprint 1 ................................................................................................ 31
1 Introduction ................................................................................................................................... 31
2 Backlog de sprint ............................................................................................................................ 31
3 Tableau des taches ......................................................................................................................... 32
4.1 Identification des acteurs............................................................................................................ 32
4.1.1 Raffinement des cas d’utilisation de sprint 1 : ......................................................................... 33
4 Conception ..................................................................................................................................... 39
4.1 Conception statique .................................................................................................................... 39
4.1.1 Diagramme de classe de sprint 1 ............................................................................................. 39
4.1.2 Dictionnaire des données du sprint 1 ...................................................................................... 40
5 Conception dynamique .................................................................................................................. 41
5.1 Diagramme de séquence du sprint 1 .......................................................................................... 41
5.2 Diagramme d’activité .................................................................................................................. 47
6 Réalisation du sprint ...................................................................................................................... 50
6.1 Les interfaces ..................................................................................................................... 50
6.2 Interface inscription .................................................................................................................... 50
6.3 Interface d’authentification ........................................................................................................ 51
7 Test et validation ............................................................................................................................ 53
8 Conclusion ...................................................................................................................................... 56
Chapitre 4 | Mise en œuvre du sprint 2 ............................................................................................... 59
1 Introduction ................................................................................................................................... 59
2 Backlog du sprint 2 ......................................................................................................................... 59
3 Tableau des taches ......................................................................................................................... 60
4 Phase Analyse................................................................................................................................. 61
4.1 Indentification des acteurs ................................................................................................ 61
4.1.1 Raffinement des cas d’utilisation de sprint 2 : ........................................................................ 61
5 Conception ..................................................................................................................................... 67
5.1 Conception statique : .................................................................................................................. 67
5.1.1 Diagramme de classe de sprint 2 ............................................................................................. 67
5.1.2 Dictionnaire des données du sprint 2 ...................................................................................... 68
5.2 Conception dynamique ............................................................................................................... 70
 5.2.1 Diagramme de séquence ......................................................................................................... 70
5.2.2 Le diagramme d’activité ........................................................................................................... 74
6 Réalisation de sprint....................................................................................................................... 76
6.1 Les interfaces .............................................................................................................................. 76
6.2 Interface <<consulter projet>> ................................................................................................... 77
7 - Test et validation.......................................................................................................................... 78
8 Conclusion ...................................................................................................................................... 79
Chapitre 5 | Mise en œuvre de sprint 3................................................................................................ 85
1 Introduction : ................................................................................................................................. 85
2 Backlog du sprint 3 : ....................................................................................................................... 85
3 Tableau des taches : ....................................................................................................................... 86
4 Phase d’analyse : ............................................................................................................................ 86
4.1 Identification des acteurs............................................................................................................ 86
5 Conception ..................................................................................................................................... 91
5.1 Conception statique .................................................................................................................... 91
5.1.1 Diagramme de classe globale :................................................................................................. 91
5.1.2 Dictionnaire de données de sprint 3 ........................................................................................ 92
6 Conception dynamique .................................................................................................................. 94
6.1 Diagramme de séquence ............................................................................................................ 94
6.2 Diagramme d’activité ........................................................................................................ 97
7 Réalisation du sprint ...................................................................................................................... 99
7.2 les interfaces : ............................................................................................................................. 99
7.2.1 Interface Gérer service : ........................................................................................................... 99
7.2.2 Interface consulter statistiques ............................................................................................. 100
8 Test et validation .......................................................................................................................... 101
9 Conclusion .................................................................................................................................... 102
Conclusion générale ............................................................................................................................ 103
Bibliographie ....................................................................................................................................... 104
 Liste des figures

Figure 1 - Maquette de la page d'accueil ................................................................................................. 4

Figure 2 - Maquette de la page service ................................................................................................... 5
Figure 3 - Maquette de la page contact ................................................................................................... 6
Figure 4 - Maquette de la page register ................................................................................................... 7
Figure 5 - Maquette de la page login ....................................................................................................... 8
Figure 6 - Processus Scrum ................................................................................................................... 11
Figure 7 - Diagramme de cas d'utilisation globale ................................................................................ 16
Figure 8 - Caractéristique du PC ........................................................................................................... 20
Figure 9 - Logo wampserver ................................................................................................................. 21
Figure 10 - Logo StarUML ................................................................................................................... 21
Figure 11 - Logo Visual Studio Code.................................................................................................... 21
Figure 12 - Logo Lucidchart ................................................................................................................. 22
Figure 13 - Logo Trello ......................................................................................................................... 22
Figure 14 - Logo Gantt Project.............................................................................................................. 23
Figure 15 - Organigramme des taches ................................................................................................... 24
Figure 16 - Diagramme de Gantt ........................................................................................................... 25
Figure 17 - Architecture 3-tiers ............................................................................................................. 26
Figure 18 - Schéma du modèle MVC .................................................................................................... 27
Figure 19 - Tableau des taches .............................................................................................................. 32
Figure 20 - Diagramme de cas d'utilisation de sprint 1 ......................................................................... 33
Figure 21 - Diagramme de cas d'utilisation <<s'inscrire>> ................................................................... 34
Figure 22 - Diagramme de cas d'utilisation <<Authentification>> ....................................................... 35
Figure 23 - Diagramme de cas d'utilisation <<Gérer utilisateur>> ....................................................... 36
Figure 24 - Diagramme de classe de sprint 1 ........................................................................................ 39
Figure 25 - Principe de diagramme de séquence ................................................................................... 41
Figure 26 - Exemple message asynchrone ............................................................................................ 42
Figure 27 - Diagramme de séquence <<S'inscrire>> ............................................................................ 43
Figure 28 - Diagramme de séquence <<S'authentifier>> ...................................................................... 44
Figure 29 - Diagramme de séquence <<Bloquer utilisateur>> ............................................................. 45
Figure 30 - Diagramme de séquence <<Débloquer utilisateur>> ......................................................... 46
Figure 31 - Diagramme d'activité <<S'inscrire>> ................................................................................. 47
Figure 32 - Diagramme d'activité <<Authentification>> ...................................................................... 48
Figure 33 - Diagramme d'activité <<Bloquer utilisateur>> .................................................................. 49
Figure 34 - interface signup................................................................................................................... 50
Figure 35 - Interface Authentification ................................................................................................... 51
Figure 36 – Interface user...................................................................................................................... 52
Figure 37 - Tableau des taches .............................................................................................................. 60
Figure 38 - Diagramme de cas d'utilisation de sprint 2 ......................................................................... 61
Figure 39 - Diagramme de cas d'utilisation ........................................................................................... 62
Figure 40 - Diagramme de cas d'utilisation <<Gérer projet >> ............................................................ 63
Figure 41 - Diagramme de cas d'utilisation <<Consulter projet>> ....................................................... 66
Figure 42 - Diagramme de classe du sprint 2 ........................................................................................ 67
Figure 43 - Diagramme de séquence <<créer projet>> ......................................................................... 70
Figure 44 - Diagramme de séquence <<Consulter projet>> ................................................................. 71
Figure 45 - Diagramme de séquence <<Accepter projet>> .................................................................. 72
Figure 46 - Diagramme de séquence <<Refuser projet>> .................................................................... 73
Figure 47 - Diagramme d'activité <<Créer projet>> ............................................................................. 74
Figure 48 - Diagramme d'activité <<Accepter projet>> ....................................................................... 75
Figure 50 - Interface gérer projet .......................................................................................................... 76
Figure 51 - Interface consulter projet .................................................................................................... 77
Figure 52 - Tableau des taches du sprint 3 ............................................................................................ 86
Figure 53 - Diagramme de cas d'utilisation <<Gérer service>> ........................................................... 87
Figure 54 - Diagramme de cas d'utilisation <<Passer réclamation>> ................................................... 89
Figure 55 - Diagramme de cas d'utilisation <<Consulter statistique>> ................................................ 90
Figure 56 - Diagramme de classe globale ............................................................................................. 91
Figure 57 - diagramme de séquence <<ajouter service>> .................................................................... 94
Figure 58 - diagramme de cas d’utilisation <<passer réclamation>> ................................................... 95
Figure 59 - diagramme de séquence <<consulter statistique>> ............................................................ 96
Figure 60 - Diagramme d'activité <<Modifier service>> ..................................................................... 97
Figure 61 - Diagramme d'activité <<Passer réclamation>> .................................................................. 98
Figure 62 - Interface gérer service ........................................................................................................ 99
Figure 63 - Interface consulter statistiques .......................................................................................... 100
 Liste des tableaux

Tableau 1 - Etude comparatif de quelque méthodologie......................................................................... 9

Tableau 2 - Identification des besoins ................................................................................................... 13
Tableau 3 - Backlog du produit ............................................................................................................. 17
Tableau 4 - Livrables du projet ............................................................................................................. 19
Tableau 5 - Risques du projet ................................................................................................................ 19
Tableau 6 - Backlog du sprint 1 ............................................................................................................ 31
Tableau 7 - Description textuelle du cas d'utilisation <<S'inscrire>> ................................................... 34
Tableau 8 - Description textuelle de cas d'utilisation <<s'authentifier>> ............................................. 35
Tableau 9 - Description textuelle du cas d'utilisation <<Bloquer utilisateur>> .................................... 37
Tableau 10 - Description textuelle du cas d'utilisation <<Débloquer utilisateur>> .............................. 38
Tableau 11 - Dictionnaire de données <<utilisateur>> ......................................................................... 40
Tableau 12 - Dictionnaire de données <<administrateur>> .................................................................. 40
Tableau 13 - Fiche test fonctionnel de l'interface <<Inscrire>> ........................................................... 53
Tableau 14 - Fiche test fonctionnel de l'interface <<Blocage>>........................................................... 54
Tableau 15 - Fiche test fonctionnel de l'interface <<Déblocage>> ....................................................... 55
Tableau 16 - Backlog du sprint 2 .......................................................................................................... 59
Tableau 17 -Description textuelle de cas d'utilisation <<créer projet>> ............................................... 62
Tableau 18 - Description textuelle de cas d'utilisation <<Accepter projet>> ....................................... 64
Tableau 19 - Description textuelle de cas d'utilisation <<Refuser projet>> ......................................... 65
Tableau 20 - Description textuelle de cas d'utilisation <<Consulter projet>> ...................................... 66
Tableau 21 - Dictionnaire de données <<utilisateur>> ......................................................................... 68
Tableau 22 - Dictionnaire de données <<administrateur>> .................................................................. 68
Tableau 23 - Dictionnaire des données <<projet>> .............................................................................. 69
Tableau 24 - Dictionnaire de données <<service>> .............................................................................. 69
Tableau 25 - Test fonctionnel de l'interface <<Acceptation>> ............................................................. 78
Tableau 26 - Backlog du sprint 3 .......................................................................................................... 85
Tableau 27 - Description textuelle de cas d'utilisation <<Gérer service>>........................................... 88
Tableau 28 - Description textuelle de cas d'utilisation <<Passer réclamation>> .................................. 89
Tableau 29 - Description textuelle de cas d'utilisation <<Consulter statistique>> ............................... 90
Tableau 30 - Dictionnaire de données <<utilisateur>> ......................................................................... 92
Tableau 31 - Dictionnaire de données <<administrateur>> .................................................................. 92
Tableau 32 - Dictionnaire des données <<projet>> .............................................................................. 93
Tableau 33 - Dictionnaire de données <<service> ................................................................................ 93
Tableau 34 - Dictionnaire des données <<réclamation>> .................................................................. 93
Tableau 35 - Test fonctionnel de l'interface <<réclamation>> ........................................................... 101
Introduction Générale

De nos jours, l’informatique peut se trouver partout et fait partie du quotidien de

bien de personnes. Il a effectivement été vu que rien ne fonctionne plus
réellement sans elle, les écoles, les postes, les magasins, toutes les sociétés en font
usage. Il a fallu que chaque personne s’adapte à la notion d’informatique en tous
genres.
Ce travail a été réalisé dans le cadre de notre projet pour l’obtention de Diplôme
de Licence Fondamentale en Informatique de gestion. Ce dernier consiste à
concevoir et à développer un site web responsive pour la startup
<<DATA2AI>>.
Cinq parties nous permettront de présenter notre travail : Dans le premier chapitre
intitulé <<Cadre de projet>>, on va commencer par la présentation de notre cadre
de projet ainsi le choix méthodologique à suivre.
Dans le deuxième chapitre nommé <<Spécification des besoins >>, il a comme
objectif la détermination des besoins fonctionnels ainsi que les besoins non
fonctionnels de notre application.
Dans les chapitres 3, 4 et 5 <<Mise en œuvre de sprint 1, 2 et 3>>, on va
distinguer les différents cas d’utilisation et détailler les diagrammes de classe
global et les diagrammes de sé[Link] les réalisations des sprints, on va définir
l’environnement, les multiples outils de développement et les différentes
interfaces graphiques de notre application suivie par les tests de l’application.

1
FSJEGJ Chapitre 1 : Cadre de projet

Chapitre 1| Cadre de projet

1 Introduction

Dans ce premier chapitre, nous commençons par une présentation de l’étude de l’existant et
nous introduisons la solution proposée tout en évoquant l’intérêt de notre projet. A la fin de ce
chapitre, nous terminons par une présentation de la méthodologie adoptée pour la réalisation de
notre application.

2 Data2AI

DATA2AI est une startup du conseil en nouvelles technologies et en nouveaux systèmes IT

intelligents (Big Data, Cloud, Intelligence Artificielle), en stratégie numérique et digitale, et la
cybersécurité.

Expertises : Data2ai accompagne les entreprises sur l’implémentation d’infrastructures

sécurisées et réalisation des projets IT/ grâce à leur experts Clouds et DevOps et les plateformes
Big Data permettant à mieux répondre aux problématiques et aux enjeux d’aujourd’hui :
Transformation digitale, développement, technologies et innovation. Nos experts BI et Big Data
Analytics vous accompagnent à la mise en place les outils de pilotage adaptés à vos enjeux
business, depuis le choix de la solution jusqu’à l’élaboration des Dashbording et reporting.
Nos Experts et nos formateurs en nouvelles technologies, vous accompagnent afin de mettre en
œuvre des plateformes forte valeur ajoutée et innovants dans vos projets de formation ou SI.
Technologies | Data2AI vous accompagne afin accéder à et maitriser de nombreuses
technologies de pointes comme le cloud/Big Data /ML/Devops pour la réalisation de vos projets
IT/BI en prémisse, Multicloud ou Cloud Hybride.
Plateformes Cloud | Des experts certifiés maitrisant les environnements cloud, vous
accompagne à déployer vos projets sur les 3 Big de plateformes cloud pour mieux répondre à
vos exigences en agilité : Cloud Public AWS, Cloud Public Azure.
Big Data/ Machine Learning| Data2AI vous propose des solutions technologiques
pragmatiques D’analyse avancée, conçues pour fournir aux entreprises différents types
d’analyse (Big Data Analytics et Data Science), permettant la transition vers un modèle
économique fondé sur la valeur ajoutée des données.

2
FSJEGJ Chapitre 1 : Cadre de projet

Problématique

La startup data2ai n'a pas de site web, alors que nous sommes à une époque où toutes
les startups ont un site web moderne.

3 Cahier des charges technique

Ce cahier des charges a pour objectif de définir un site Internet qui permettra aux clients de
trouver les informations nécessaires de notre startup DATA2AI.
La maquette basique composées des grilles de positionnement se trouve directement dans le
présent cahier des charges.

• Front office

Liste des pages :

- Page d’accueil
- Page about
- Page service
- Page contact
- Page registre
- Page login

Menu principal
Le menu principal, horizontal, se trouve sur toutes les pages du site et permet de naviguer dans
chacune des rubriques.
Les noms des rubriques doivent être en texte.
Rubrique :

- Accueil
- About
- Service
- Contact

3
FSJEGJ Chapitre 1 : Cadre de projet

Figure 1 - Maquette de la page d'accueil

4
FSJEGJ Chapitre 1 : Cadre de projet

Page de service :
Cette page permet de lister tous les services offerts par notre startup, et de trouver le service
qu’on recherche.

Le menu est identique au menu de la page d’accueil. On affiche le nom de la service (H1) puis
le texte de présentation, tous les services sur une seule page.

Figure 2 - Maquette de la page service

5
FSJEGJ Chapitre 1 : Cadre de projet

Page contact :

Figure 3 - Maquette de la page contact

6
FSJEGJ Chapitre 1 : Cadre de projet

Page register :

Figure 4 - Maquette de la page register

7
FSJEGJ Chapitre 1 : Cadre de projet

Page login

Figure 5 - Maquette de la page login

8
FSJEGJ Chapitre 1 : Cadre de projet

4 Solution proposée

Comme solution nous proposons de développer un site web responsive"Data2AI",

pour but de faciliter la communication entre les équipes, les consultants et les clients ce
site permet à DATA2AI d’exposer les différents services pourtant sur qui sont basées
sur les nouvelles Technologies, les plateformes Cloud, Big Data et le Machine Learning.

5 Approche méthodologique

5.1 Etude comparative de quelques méthodologies

Description Points Forts Points Faibles

RUP - Une méthodologie de Propose des modèles de Couteux à

conduite et de documents et des canevas personnaliser et très
développement de pour des projets types. axé processus.
projets.
- Un outil prêt à l’emploi.

XP - Représente un ensemble - Itératif. Ne couvre pas les

de pratiques de - Simple à mettre en phases en amont et en
développement. œuvre. aval au
- Cible des projets de moins développement.
de 5 personnes

2TUP S’articule autour de Fait une large place à la Ne propose pas

l’architecture. technologie et à la gestion du documents types.
risque.

Scrum - 5 à 9 personnes - Itérative et incrément - Développement

- Autogérée - Développement d’un imprécis, influence
- Les décisions sont prises backlog de produit de développement
collectivement - Travail en équipe et rapide sur les
- Contient toutes les responsabilité membres de l’équipe
compétences nécessaires collective. de développement.
pour terminer le sprint - Plus de souplesse et de
- Ne change pas pendant créativité.
un Sprint - Augmentation
de productivité.

Tableau 1 - Etude comparatif de quelque méthodologie

9
FSJEGJ Chapitre 1 : Cadre de projet

5.2 Choix de la méthodologie Scrum

Le terme Scrum signifie mêlée au rugby. Il exploite les valeurs et l’esprit du rugby et les
adapte aux projets de développement. Comme le pack lors d’un ballon porté rugby, l’équipe
chargée du développement travaille de façon collective, soudée vers un objectif précis.

Comme un demi mêlé, le Scrum Master aiguillonne les membres de l’équipe, les repositionne
dans la bonne direction et donne le temps pour assurer la réussite du projet.
Scrum se base sur la théorie du contrôle empirique de processus. L’empirisme mentionne que
les connaissances proviennent de l’expérience et d’une prise de décision basée sur des faits
connus. Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et
contrôler le risque.

Trois piliers soutiennent l’implémentations d’un contrôle empirique de processus : la

Transparence, l’inspection et l’adaptation.
• La transparence : requiert la définition d’un standard commun de pour ces aspects
afin que les observateurs partagent une compréhension commune de ce qui observé.
• L’inspection : les résultats de Scrum doivent fréquemment inspecter les
artéfacts Scrum.

- L’état d’avancement par rapport à un objectif de Sprint (Sprint Global) afin de détecter les
écarts indésirables. La fréquence de ces inspections ne devrait pas gêner le travail en cours. Ces
inspections son bénéfiques lorsqu'elles sont effectuées de manière diligente sur les lieux du
travail par les personnes qualifiées.

• L’adaptation : si un inspecteur détermine qu’un ou plusieurs aspects du processus

dérivent hors des limites acceptables, et que le produit qui en résulte sera
inacceptable, le processus ou e matériel utilisé par le processus doit être ajusté. Un
ajustement doit être fais dès que possible afin de minimiser le risque d’autres
dérives.

10
FSJEGJ Chapitre 1 : Cadre de projet

5.3 Processus Scrum

La figure si dessous décrit le principe de Scrum qui se résume comme suit :

- Propriétaire de produit (Le Product Owner) crée une liste des taches prioritaires appelés
Product Backlog.

- Pendant le Sprint Planning, l’équipe prend une partie des taches du Product Backlog
pour préparer le Sprint Backlog et discuter la manière d’implémentation de ces taches.

- L’équipe a une certaine période de deux à quatre semaines (Sprint) pour achever le
travail, mais elle se réunit chaque jour pour évaluer le progrès (DailyScrum).

— Tout au long de la p ́période, le Scrum Master essaie de maintenir l’équipe concentrée sur
son objectif.
— A la fin de chaque sprint, le travail devrait être potentiellement livrable.

— Au départ du Sprint suivant, l’équipe prend une autre partie des taches de Product Backlog
et répété les étapes précédentes.
— Au-delà du Sprint, le cycle se répété jusqu’à ce que la liste des tâches du Product Backlog
soit achevée ou le budget du projet soit épuisé ou une date limite soit atteinte. L’un de ces
Milestone marque la fin du travail sur le projet. Peu importe la cause de Clôture, Scrum assure
que le travail le plus important a été achevé de la fin du projet.

Figure 6 - Processus Scrum

11
FSJEGJ Chapitre 1 : Cadre de projet

5.4 Le langage UML

UML est un standard de modélisation graphique. Nous avons choisi ce langage pour la
modélisation de notre conception du fait qu’il est idéal pour le contexte orienté objet. Il permet
de présenter un logiciel sous forme graphique compréhensible et simple.

6 Conclusion
Dans ce premier chapitre, nous avons étudié le système et le marché pour dégager les
limites des solution existantes et proposer une solution plus adéquate. Par la suite, nous avons
présenté une analyse de méthodologie de développement pour effectuer le choix de la
méthodologie qui sera adoptée durant le développement de notre système. Dans le chapitre
suivant, nous entamerons l’étude des besoins fonctionnels et non fonctionnels.

12
 FSJEGJ Chapitre 2 : Analyse et spécification des besoins

Chapitre 2 | Analyse et spécification des besoins

1 Introduction

Dans ce chapitre, nous présentons les besoins des utilisateurs à travers une spécification des
besoins fonctionnels afin d’aboutir à une application performante et satisfaisante.
Ensuite, nous identifions les acteurs de notre application. Enfin, nous détaillons le travail par la
méthodologie choisie dans le chapitre précédent.

Ce chapitre va traiter l’environnement matériel et logiciel lié à la phase d’implémentation de

notre application. Nous commençons par une présentation de l’architecture matérielle. Ensuite,
nous présentons les différents outils logiciels qui seront utilisés tout au long de la réalisation.

2 Identification des acteurs

Un acteur définit un rôle qu’une entité extérieure assume lors de son interaction avec le
système. En se basant sur cette définition, nous avons dégagé la liste des acteurs de notre
système

Acteurs Rôles

Administrateur C’est la personne responsable de contrôler la totalité

du système
Client C’est toute personne inscrit dans le site et peut
bénéficier par les services offerts par le site.

Tableau 2 - Identification des besoins

13
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

2.3 Analyse des besoins

Nous allons identifier dans cette partie les acteurs et leurs rôles. Par la suite, nous répondrons
aux questions suivantes << que doit faire le système ?>> et << quelles sont les contraintes ?>>
afin d’expliquer les différents besoins fonctionnels et non fonctionnels que notre application à
satisfaire.

2.3.1 Besoins fonctionnels

Les besoins fonctionnels expriment les attentes des utilisateurs envers le futur système.

Notre site assurera à l’administrateur les fonctionnalités suivantes :

L’administrateur a le droit de Controller n’importe quelle action dans l’application aussi que :
• S’authentifier : il peut accéder à son interface personnelle tout simplement en saisir son
login et son mot de passe.
• Gérer utilisateur : l’administrateur a la possibilité d’ajouter, modifier, supprimer, bloquer
un utilisateur
• Configurer les statistiques.
Notre site assurera aux clients les fonctionnalités suivantes :
• Se connecter au site.
• Consulter les différentes catégories des services.
• Consulter les services.
• Rechercher un service.
• Consulter les news.
• Contacter l’assistance technique.
• Gérer réclamation
• Créé un compte (S’inscrire).
• Accéder à l’espace membre (S’authentifier).
• Gérer son profil.
• Se déconnecter
• Gérer son profil.
• Se déconnecter

14
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

2.3.2 Besoins non fonctionnels

Futur système doit répondre aux critères suivants :

• Rapidité : le site doit optimiser les traitements pour un temps d’exécution raisonnable.
• Sécurité : les clients doivent s’authentifier pour accéder à certaines fonctionnalités du site.
• Ergonomie : à fin que l’utilisateur de l’application puisse être aisé, celle-ci devra :

• Présenter des interfaces ergonomiques.

• Permettre à l’utilisateur un accès simple.

• Assurer l’homogénéité et la cohérence entre les interfaces.

15
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

2.4 Diagramme de cas d’utilisation globale

Le diagramme de cas d’utilisation est une représentation graphique du comportement fonctionnel

du système.
Dans cette partie, nous présentons les fonctionnalités du système dans un diagramme de cas
d’utilisation globale permettant de modéliser les besoins de client de manière formelle et de
donner une vision du comportement fonctionnel de notre système.

Figure 7 - Diagramme de cas d'utilisation globale

16
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

2.5 Le Backlog du produit

SCRUM utilise une approche fonctionnelle pour récolter les besoins des utilisateurs.
L’objectif est d’établir une liste de fonctionnalités à réaliser que l’on appelle backlog de produit.
Le backlog de produit est la liste des fonctionnalités attendus d’un produit. Plus exactement,
au-delà de cet aspect fonctionnel, il contient tous les éléments qui vont nécessiter du travail.
Les éléments sont classés par priorité ce qui permet de définir l’ordre de la réalisation.
Le tableau ci-dessous résume le Backlog produit de notre application.

ID Cas d’utilisation User Story Priorité

1 S’inscrire En tant qu’client je veux inscrire 1
2 Authentification En tant que client je veux être s’authentifier 1

3 Gérer service En tant qu’administrateur je veux gérer les 1

services

4 Consulter service En tant que client je veux consulter les services 1

5 Consulter projet En tant que client je veux consulter le projet 3

6 Gérer client En tant qu’administrateur je veux gérer les 3

clients
7 Consulter statistiques En tant qu’administrateur je veux consulter les 3
statistiques

8 Gérer projet En tant que client je veux modifier les services 2

9 Créer projet En tant que client je veux créer les projets 2

10 Gérer réclamation En tant qu’administrateur je veux gérer les 2

réclamations
11 Passer réclamation En tant que client je veux passer une 3
réclamation.

Tableau 3 - Backlog du produit

17
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

Scrum master : c’est qu’il n’est jamais fait mention de technique, et qu’il ne produit rien. En
revanche, on peut noter qu’il doit être au service de l’équipe et du PO mais aussi de
l’organisation

- Il est sachant, c’est-à-dire qu’il connait bien (très bien même) Scrum, le guide
scrum et qu’il est garant de la bonne application de scrum dans son équipe, et plus
largement il est garant de l’Agilité de l’équipe
- Il est coach, formateur, accompagnant, il permet à l’équipe de gagner en autonomie.
- Il est servant Leader, il doit être au service (de l’équipe, du PO, de l’organisation),
comme celui qui organiserait une grosse fête chez lui ferait pour que la soirée se
passe bien pour tout le monde

Product owner : est le responsable de son PB et son maintien. Il est également

responsable de la formation des utilisateurs afin qu’ils puissent exploiter toutes les
fonctionnalités du produit.

18
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

3.1 Livrables du projet

Phase Livrable Responsable

Etude des besoins Analyse et spécification des

besoins

Analyse et conception Diagrammes UML Mahjoubi Ranya

Code et tests Site web

Documentation Rapport du projet

Tableau 4 - Livrables du projet

3.2 Risques du projet

Les risques Type Impact sur projet Action correctives

Performance de mon Non bloquant Retard de livraison Changement de pc
pc par rapport à
l’environnement
Manque de Non bloquant Retard de livraison L’utilisation d’une
formation plate-forme
d’apprentissage

Tableau 5 - Risques du projet

19
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

4. Environnement de travail

Dans cette partie, nous présentons les outils matériels pour réaliser notre projet.

4.1 environnement matériel

Pendant les différentes phases de notre projet, nous disposons d’un ordinateur portable ayant les
caractéristiques suivantes :
- Marque : Asus
- Processeur [U+202F] : Intel® Core ™ i3-6006U @2.00GHz 1.99GHz - Mémoire
[U+202F] : 8.00 GO.
- Système d’exploitation [U+202F] : Windows 10 Pro ,64-bit.

Figure 8 - Caractéristique du PC

4.2 environnement logiciel

Dans cette partie nous présentons les différents outils logiciels utilisés pour développer notre
solution

• WampServer : est une plateforme de développement Web de type wamp

(‘Windows’,’Apache’,’MySQL’,’PHP’) qui permet de développer des sites internet
dynamiques. Au sein de l’application, on retrouve Apache http Server en tant que
serveur http, PHP pour le langage de script, MySQL pour le système de gestion des
bases de données (SGBD) ainsi que l’application Web phpMyAdmin pour la gestion
des SGBD MySQL. [1]

20
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

Figure 9 - Logo wampserver

• StarUML
Est un logiciel de modélisation UML (Unified Modeling Language) open source qui peut
remplacer dans bien des situations des logiciels commerciaux et couteux comme Rational Rose.
Etant simple d’utilisation, nécessitant peu de ressources système, supportant UML 2, ce logiciel
constitue une excellente option pour une familiarisation à la modélisation.
Cependant, seule une version Windows est disponible. [2]

Figure 10 - Logo StarUML

• Visual Studio Code

Visual Studio Code est un éditeur de code extensible développé par Microsoft pour Windows,
Linux et MacOs. Les fonctionnalités incluent la prise en charge du débogage, la mise en
évidence de la syntaxe, la complétion intelligente du code, les snippets, la refactorisation du
code et Git intégrer. [3]

Figure 11 - Logo Visual Studio Code

21
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

• Lucidchart : est une plateforme de collaboration en ligne, basée sur le Cloud,

permettant la création de diagrammes et la visualisation de données, et autres schémas
conceptuels.

Un schéma conceptuel, ou carte conceptuelle est une représentation structurée d’un ensemble de
concepts reliés sémantiquement. [5]

Figure 12 - Logo Lucidchart

• Trello : est un outil d’organisation collaboratif simple et gratuit. Trello est un outil
collaboratif qui organise tous vos projets en une série de listes partagées.
D’un seul coup Trello vous renseignera sur tous vos projets, sur leur état d’avancement et
vous dira qui travaille sur quoi dans votre équipe. [6]

Figure 13 - Logo Trello

22
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

• Gantt Project : Gantt est un logiciel libre de gestion de projet écrit en Java, ce qui
permet de l’utilisateur sur divers systèmes d’exploitation (Windows, Linux, MacOs). Il
permet d’étudier un diagramme de Gantt qui organise le projet selon des dates fixées.

Figure 14 - Logo Gantt Project

4.3 Système de gestion de base de données

- MySQL : MySQL est un système de gestion de base de données. Il fait partie des logiciels de
de gestion de base de données les plus utilisés au monde, dans les applications Web
principalement, en concurrence avec Oracle ou Microsoft SQL Server. MySQL est un serveur
de bases de données relationnelles SQL développé dans un soucis de performances élevées en
lecture. Son architecture logicielle le rend extrêmement rapide et facile à personnaliser. Les
principaux avantages de MySQL sont sa rapidité, sa robustesse et sa facilité d’utilisation et
d’administration. Un autre avantage majeur de MySQL est sa documentation très complète et
bien construite.

4.4 Choix technologiques

- Symfony : Symfony est un ensemble de composants PHP ainsi qu'un Framework MVC
libre écrit en PHP. Il fournit des fonctionnalités modulables et adaptables qui permettent de
faciliter et d’accélérer le développement d'un site web.
- Twig : twig est un langage de Template qui se compile en code PHP optimisé. Il est
principalement utilisé pour générer du HTML, mais peut également être utilisé pour générer
tout autre format basé sur du texte.

23
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

4.5 Organigramme des taches

Figure 15 - Organigramme des taches

4.6 Planifications de projet :

Pour bien organiser le déroulement de différentes étapes de notre projet on a réalisé une
planification
Nous avons découpé notre projet en plusieurs tache afin d’assurer son déroulement. Au début
nous avons commencé avec notre sprint 0, puis on a découpé notre projet en 3 sprints dure
chacune () jours pour que nous puisons à la fin avoir un projet complet à livrer.

4.7 Diagramme de Gantt :

Le diagramme de Gantt est un outil utilisé en ordonnancement et en gestion de projet et

permettant de visualiser dans le temps les diverses taches composant un projet, il s’agit d’une
représentation d’un graphe connexe, permet de représenter graphiquement l’avancement du
projet

24
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

Le diagramme permet :
-De déterminer les dates de réalisation d’un projet
-D’identifier les marges existantes sur certaines taches

-Visualiser d’un coup d’œil le retard ou l’avancement des travaux

Figure 16 - Diagramme de Gantt

4.8 Architecture de l’application

Dans cette partie, nous présentons l’architecture de notre application << le style de
l’architecture en tiers spécifie l’organisation des composants d’exploitation mise en œuvre pour
réaliser le système >>

4.8.1 Architecture 3-tiers

Dans notre application, nous avons utilisé une architecture 3-tiers qui vise à décomposer le système
en trois couches différentes :

25
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

- Couche présentation : c’est la partie de l’application visible par les utilisateurs.

- Couche métier : constitue l’ensemble des règles de la logique applicative, elle vérifie donc
l’intégrité et la validité des données.

- Couche d’accès aux données : représente les données à conserver et à stocker et qui
souvent à l’implémentation du logique métier...

Le navigateur envoie l’adresse que le client a tapée. Le serveur web cherche si le fichier existe,
et si celui-ci porte une extension reconnue comme une application PHP. Si c’est le cas, le
serveur transmet ce fichier.
PHP analyse et exécute le code. Si ce code contient des requêtes SQL. La base de données
revoie les informations voulues au script qui peut les exploiter (pour les afficher par exemple).
PHP continue de parser la page, puis retourne le fichier dépourvu du code PHP au serveur web
qui génère une page HTML et le renvoie au navigateur qui l’interprète et l’affiche. [7]

Figure 17 - Architecture 3-tiers

4.8.2 Architecture logicielle : MVC

Nous avons applique le modèle Model-View-Control (MVC) pour le développement de

l’application :
- M : modèle de données

- V : pour la présentation, l’interface utilisateur

- C : pour la logique de contrôle, gestion des évènements et la synchronisation

26
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

L’architecture MVC offre un cadre pour structurer une application, il impose la séparation entre les
données, la présentation et les

Traitements ce qui donne trois parties de l’application finales : modèle, vue et contrôleur

Le Modèle : c’est le comportement de l’application : traitement de données, interaction avec base

de données. Il décrit les données manipulées par l’application.
Le Vue : correspond à l’interface avec lequel l’utilisateur interagit. Sa première tâche est de
présenter les résultats reçus du modèle, puis il reçoit toutes les actions de l’utilisateurs.

Le Contrôleur : reçoit tous les événements de l’utilisateur [8]

Figure 18 - Schéma du modèle MVC

27
FSJEGJ Chapitre 2 : Analyse et spécification des besoins

5. Conclusion

Dans ce chapitre, nous avons identifié les besoins fonctionnels et non fonctionnels de notre
système ainsi que les acteurs principaux et leurs rôles. Ensuite, nous avons détaillé la première
étape de la méthodologie que nous avons choisie, à savoir, l’identification de l’équipe de travail
et la réalisation de backlog du produit et des sprints. Dans le chapitre suivant, nous entamons
l’étude du sprint 1.

28
 FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Chapitre 3 |Mise en œuvre de sprint 1

1 Introduction

Ce chapitre fait l’objet d’une présentation du premier sprint du projet qui est la distribution et
le contrôle des droits d’accès. L’étude de se sprint couvre l’analyse, la conception, la réalisation
et les tests fonctionnels.

2 Backlog de sprint

Un sprint est une courte période de durée fixe durant laquelle vont s’enchaîner un certain nombre
d’activités et se terminant par la livraison d’un incrément de produit qui fonctionne
Dans cette partie nous allons présenter le Backlog du sprint qui correspond à une liste des
fonctionnalité attendus d’un sprint. Le tableau ci-dessus résume le Backlog du sprint relatif à
notre livrable.
ID Fonctionnalité Tache Date début Date fin Responsable

1 S’inscrire 01/03/2022 08/03/2022

2 S’authentifier 09/03/2022 16/03/2022

Ranya
3 Gérer utilisateur Ajouter utilisateur 17/03/2022 24/03/2022 Mahjoubi
Modifier utilisateur

Supprimer utilisateur

Bloquer utilisateur

Tableau 6 - Backlog du sprint 1

31
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

3 Tableau des taches

Le tableau des taches et un affichage visuel de la progression de l’équipe Scrum au cours d’un sprint
Il est composé de 3 colonnes :

• A faire : liste des taches à traiter

• En cours de traitement : liste des taches en cours de développement
• Terminée : liste des taches terminées

Figure 19 - Tableau des taches

4.1 Identification des acteurs

Les acteurs qui interagissent dans le sprint 1 sont :

- Utilisateur : c’est l’acteur principale de notre application, qui permet de s’inscrire et s’authentifier
- Administrateur : c’est l’acteur du back office de contrôler et configurer l’accès du les utilisateurs.

32
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

4.1.1 Raffinement des cas d’utilisation de sprint 1 :

Figure 20 - Diagramme de cas d'utilisation de sprint 1

33
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Raffinement de cas d’utilisation inscription

- Diagramme de cas d’utilisation <<inscription>> pour l’acteur utilisateur :

Pour accéder aux fonctions, l’utilisateur doit s’inscrire en remplissant un formulaire donné

Figure 21 - Diagramme de cas d'utilisation <<s'inscrire>>

Les scénarios d’exécution du cas d’utilisation << s’inscrire>> sont décrits par le tableau suivant
représentant la fiche descriptive de cas

Nom Description
Acteur Utilisateur
Objectif Le site doit permettre aux utilisateurs de s’inscrire
Pré-condition Utilisateur non inscrit
Post-condition Compte utilisateur crée
Scénario Nominal 1. L’utilisateur accède au site
2. Le système affiche l’interface d’inscription
3. L’utilisateur remplit le formulaire
4. Le système affiche un
message de confirmation
Scénario Alternatif Champs vide
3.1 le système affiche un message d’erreur
3.2 le scénario recommence du point 1 du scénario
nominal
Tableau 7 - Description textuelle du cas d'utilisation <<S'inscrire>>

34
 FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Raffinement de cas d’utilisation << S’authentifier >> :

Figure 22 - Diagramme de cas d'utilisation <<Authentification>>

Nom Authentification
Acteur Administrateur, utilisateur
Objectif Autorisation d’accès
Pré-condition Utilisateur inscrit
Post-condition Accès au système
Scénario Nominal 1. Le système demande de saisir login et mot de
passe
2. L’utilisateur saisit non-login et mot de passe
3. Le système vérifie les paramètres
4. Le système affiche l’interface choisit
Scénario Alternatif Champs vides, paramètre non valide 3.1 le
système affiche un message d’erreur
3.2 le scénario recommence du point 1 du scénario
nominal

Tableau 8 - Description textuelle de cas d'utilisation <<s'authentifier>>

35
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Raffinement de cas d’utilisation << Gérer utilisateur >> pour l’acteur <<
Administrateur >>

Figure 23 - Diagramme de cas d'utilisation <<Gérer utilisateur>>

Les scénarios d’exécution du cas d’utilisation <<bloquer utilisateur>> sont décrits par les tableaux
suivants représentant les fiches descriptives du cas :
Description textuelle de cas d’utilisation <<bloquer utilisateur>> pour les acteurs
<<administrateur>>

36
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Nom Bloquer utilisateur

Acteur Administrateur
Objectif L’administrateur contrôle et gère les utilisateur
Pré-condition - L’administrateur doit être authentifié
- L’administrateur doit accéder à l’interface
bloqué l’utilisateur.
Post-condition Le compte de l’utilisateur et bloqué
Scénario Nominal 1. L’administrateur consulte la liste des
utilisateurs
2. L’administrateur demande le blockage d’un
client
3. Le système demande la confirmation
4. L’administrateur confirme son choix
5. Le système envoie une requête de
modification au SGBD
6. Système envoie un message de confirmation
à l’administrateur
Scénario Alternatif 1 l’administrateur annule la mise à jour :
. Le cas d’utilisation se termine avec échec.

Tableau 9 - Description textuelle du cas d'utilisation <<Bloquer utilisateur>>

37
 FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Les scénarios d’exécution du cas d’utilisation <<débloquer utilisateur>> sont décrits par les tableaux
suivants représentant les fiches descriptives du cas :
Description textuelle de cas d’utilisation <<débloquer utilisateur>> pour les acteurs
<<administrateur>>

Nom Débloquer utilisateur

Acteur Administrateur

Objectif L’administrateur contrôle et gère les utilisateurs

Pré-condition - L’administrateur doit s’authentifié

Post-condition Le compte de l’utilisateur est débloqué

Scénario Nominal 1. L’administrateur consulte la liste des

utilisateurs
2. L’administrateur demande le déblocage
d’un client
3. Le système demande la confirmation

4. L’administrateur confirme son choix

5. Le système envoie une requête de
modification au SGBD
6. Système envoie un message de
confirmation à l’administrateur

Scénario Alternatif 1 l’administrateur annule la mise à jour :

. Le cas d’utilisation se termine avec échec.

Tableau 10 - Description textuelle du cas d'utilisation <<Débloquer utilisateur>>

38
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

4 Conception

4.1 Conception statique

4.1.1 Diagramme de classe de sprint 1

Une classe est un ensemble de fonctionsde données (attributs) qui sont liée ensemble par un champ
sémantique. Les classes sont utilisées dans la programmation orientée objet.

Une classe est représentée par un rectangle séparé en trois parties :

- Première partie contient le nom de la classe
- La seconde contient les attributs de la classe
- La dernière contient les méthodes de la classe

Figure 24 - Diagramme de classe de sprint 1

39
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

4.1.2 Dictionnaire des données du sprint 1

Le dictionnaire des données est un document qui décrit la base de données ou une collection des bases
de données.
Les tableaux présentés ci-dessous illustrent le dictionnaire de données associé à notre base de données.

Utilisateur

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Nomprénom CHAR 50 Oui

Email Varchar 255 Oui

Téléphone Int 8 Oui

Password VARCHAR 255 Oui

Tableau 11 - Dictionnaire de données <<utilisateur>>

Administrateur

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Email Varchar 255 Oui

Password VARCHAR 255 Oui

Tableau 12 - Dictionnaire de données <<administrateur>>

40
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

5 Conception dynamique

5.1 Diagramme de séquence du sprint 1

Pour notre site, nous allons élaborer les diagrammes de séquence pour déterminer la
dynamique du système. Ce diagramme met en valeur les échanges de messages entre acteurs et
objets de manière chronologique.
Le principe de ce diagramme est de détailler de séquence système, il permet de découper le système en
trois objets :
- Interface
- Contrôle
- Entité

Figure 25 - Principe de diagramme de séquence

41
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Message asynchrone : il n’attend pas de réponse et ne bloque pas l’émetteur qui ne sait pas si le
message arrivera à destination.

Figure 26 - Exemple message asynchrone

Message synchrone : l’émetteur reste alors bloqué le temps que dure l’invocation de l’opération

42
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

- Diagramme de séquence <<inscription>> : Ce scénario commence lorsque l’utilisateur

demande d’afficher le formulaire d’inscription. Dès que le formulaire sera affiché, l’utilisateur
remplit les champs demandés. Par a suite le système vérifie les champs (type, forme) ainsi que la
vérification des champs obligatoires qui doivent être non vide. Si tout est correcte, le système
envoie les données entrées à la base de données pour être enregistrer et enfin l’affichage de
message d’inscription avec succès. La figure ci-dessous illustre de diagramme de séquence
associé à ce scénario

Figure 27 - Diagramme de séquence <<S'inscrire>>

43
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

- Diagramme de séquence <<S’authentifier>> : ce diagramme décrit les scénarios possibles lors

de l’authentification par son email et son mot de passe via le serveur d’application qui prend en
charge de vérifier et consulter la base de données. S’il accepté, il y’aura l’accès au système et à
l’application du menu correspondant. Sinon le serveur d’application lui affiche un message
d’erreur.

Figure 28 - Diagramme de séquence <<S'authentifier>>

44
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

- Diagramme de séquence <<bloquer utilisateur>> :

Ce diagramme décrit les scénarii possibles lors d’une opération de blocage d’un profil, une fois
l’administrateur choisit le blocage, le système lui affiche une fenêtre de confirmation de blocage s’il
confirme, le profil sera bloqué. Dans la figure suivante nous présentons le diagramme de séquence
bloqué profil.

Figure 29 - Diagramme de séquence <<Bloquer utilisateur>>

45
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Ce diagramme décrit les scénarios possibles lors d’une opération de déblocage d’un
profil. Une fois l’administrateur choisit le déblocage, le système lui affiche une fenêtre
de confirmation de déblocage, s’il confirme, le profil sera débloqué. Dans la figure
suivante, nous présentons le diagramme de séquence débloqué profil.

Figure 30 - Diagramme de séquence <<Débloquer utilisateur>>

46
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

5.2 Diagramme d’activité

Le diagramme d’activité est un diagramme comportemental d’UML, permettant de représenter

le déclenchement d’évènements en fonction des états du système et de modéliser des
comportements parallélisables (multithreads ou multiprocessus). Le diagramme d’activité est
également utilisé pour décrire un flux de travail (workflow).

A- Diagramme d’activité <<inscription>>

La figure ci-dessous présente le diagramme d’activité <<inscription>>

Figure 31 - Diagramme d'activité <<S'inscrire>>

47
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

B – Diagramme d’activité << Authentification>>

La figure ci-dessous présente le diagramme d’activité d’authentification

Figure 32 - Diagramme d'activité <<Authentification>>

48
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

C – Diagramme d’activité <<bloquer utilisateur>>

La figure ci-dessous présente le diagramme d’activité <<bloquer utilisateur>>

Figure 33 - Diagramme d'activité <<Bloquer utilisateur>>

49
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

6 Réalisation du sprint

6.1 Les interfaces

Dans cette partie, nous allons présenter quelques interfaces de site afin de montrer le résultat de
ce sprint.

6.2 Interface inscription

La figure ci-dessous présente les erreurs syntaxiques

Figure 34 - interface signup

50
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

6.3 Interface d’authentification

Cette interface permet à l’utilisateur de taper son login et mot de passe correctement pour pouvoir
accéder à son espace privée sinon elle affiche un message d’erreur

Figure 35 - Interface Authentification

51
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Interface espace privée :

Figure 36 – Interface user

52
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

7 Test et validation

Le test d’un produit logiciel est processus consistant qui vise à garantir le bon fonctionnement du
système à travers une comparaison des comportements attendu et des résultats obtenus.
Le tableau ci-dessous présente le fiche test fonctionnel de l’interface inscription

Id : Type fonctionnel
inscription
Testeur : Ranya Mahjoubi
Object attendu : l’utilisateur doit insère un login et un mot de passe pour créer un compte

Description : Après le développement de l’interface d’inscription on va introduire les informations

nécessaires dans le formulaire et on va faire des tests. (Test sur la syntaxe de chaque champ)

Règle métier
Règle 1 : l’utilisateur accède à l’interface inscription

Règle 2 : l’utilisateur doit remplir le formulaire d’inscription

Règle 3 : l’utilisateur doit respecter les contrôles de saisis
Tests d’acceptation sur l’entité :
Nom de scénario 1 : contrôle syntaxique des champs lorsque l’utilisateur remplie le formulaire il doit
respecter les champs suivants :

- Nom : l’utilisateur doit écrire 255 caractères composer par des lettres [a..z] ou [A..Z]
- Prénom : l’utilisateur doit écrire 255 caractères composer par des lettres [a..z] ou [A..Z]
- Email : l’utilisateur doit écrire 255 caractères composer par des lettres [a..z] ou [A..Z] et : ou
[0..9], ce champs doivent contenir aussi le << @ >>
- Téléphone : l’utilisateur doit écrire 11 caractères composer par des numéros [0..9]
- Login : l’utilisateur écrit 255 caractères composer par des lettres [a..z] ou [A..Z] et : ou [0..9]
- Password : l’utilisateur doit écrire 255 caractères composer par des lettres [a..z] ou [A..Z] et : ou
[0..9] Nom de scénario :

- L’utilisateur doit compléter le processus d’inscription

- L’utilisateur doit remplir tous les champs
- L’utilisateur doit cliquer sur le bouton << s’inscrire >>

Tableau 13 - Fiche test fonctionnel de l'interface <<Inscrire>>

53
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Le tableau ci-dessous présente le fiche test fonctionnel de l’interface blocage

Id : blocage Type fonctionnel

Testeur : Ranya Mahjoubi

Object attendu : l’administrateur doit bloquer utilisateur désiré

Description : Après le développement de l’interface de blocage on va vérifier toutes les

interactions de système après la consultation de la liste des utilisateurs, choisir un utilisateur le
système demande la confirmation de blocage, l’administrateur valider le blocage.

Règle métier
Règle 1 : l’administrateur accède à l’interface bloquer utilisateur
Règle 2 : l’administrateur consulte la liste de utilisateurs
Règle 3 : l’administrateur choisie un utilisateur
Règle 4 : l’administrateur confirme le blocage
Tests d’acceptation sur l’entité : utilisateur

Nom de scénario : l’administrateur confirme le blocage

- L’administrateur consulte la liste des utilisateurs

- Choisir un utilisateur
- L’administrateur demande le blocage
- L’administrateur confirmer le blocage
- Dans la table utilisateur : l’état d’utilisateur doit être modifié : blocage=bloquer

Tableau 14 - Fiche test fonctionnel de l'interface <<Blocage>>

54
 FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

Le tableau ci-dessous présente le fiche test fonctionnel de l’interface déblocage

Id : déblocage Type fonctionnel

Testeur : Ranya Mahjoubi

Object attendu : l’administrateur doit débloquer utilisateur désiré

Description : Après le développement de l’interface de déblocage on va vérifier toutes les

interactions de système après la consultation de la liste des utilisateurs, choisir un utilisateur le
système demande la confirmation de déblocage, l’administrateur valider le déblocage.

Règle métier
Règle 1 : l’administrateur accède à l’interface débloquer utilisateur
Règle 2 : l’administrateur consulte la liste de utilisateurs
Règle 3 : l’administrateur choisie un utilisateur
Règle 4 : l’administrateur confirme le déblocage
Tests d’acceptation sur l’entité : utilisateur

Nom de scénario : l’administrateur confirme le déblocage

- L’administrateur consulte la liste des utilisateurs

- Choisir un utilisateur

- L’administrateur demande le déblocage

- L’administrateur confirmer le déblocage

- Dans la table utilisateur : l’état d’utilisateur doit être modifié : déblocage=débloquer

Tableau 15 - Fiche test fonctionnel de l'interface <<Déblocage>>

55
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1

8 Conclusion

Au cours de ce chapitre, nous avons présenté le premier sprint. Pour ce faire, nous avons passé par la
présentation du Backlog Product, la spécification des besoins, la conception et la réalisation. Dans le
chapitre suivant nous entamons le deuxième sprint.

56
 FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

Chapitre 4 | Mise en œuvre du sprint 2

1 Introduction
Durant ce chapitre, nous entamons le deuxième sprint. Pour cela, nous commençons par le
Backlog du sprint, nous passons ensuite aux parties analyse et conception, pour terminer enfin
par les parties réalisation et revue de sprint

2 Backlog du sprint 2
Dans cette partie nous allons présenter le Backlog du sprint qui correspond à une liste des
fonctionnalités attendus d’un sprint. Le tableau ci-dessus résume le backlog du sprint relatif à
notre livrable.

Id Fonctionnalité Tache Date début Date fin Responsable

1 Créer projet 25/03/2022 01/04/2022

2 Gérer projet 04/04/2022 11/04/2022 Mahjoubi Ranya

-Accepter projet

-Refuser projet

3 Consulter projet 12/04/2022 19/04/2022

Tableau 16 - Backlog du sprint 2

59
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

3 Tableau des taches

Le tableau de taches est un affichage visuel de la progression de l’équipe Scrum au cours d’un
sprint.
Il est divisé en trois colonnes : les taches à réaliser, les tâches en cours et les tâches réalisé.
La figure ci-dessous présente le tableau des taches du sprint 2

Figure 37 - Tableau des taches

60
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

4 Phase Analyse

Dans cette partie, nous présentons les diagrammes de cas d’utilisation et la description textuelle
de certain d’entre eux.

4.1 Indentification des acteurs

Les principaux acteurs de ce sprint sont

Utilisateur : l’acteur déclencheur de ce sprint, il crée un projet après authentification

Administrateur : c’est l’acteur responsable de la gestion et de filtrage des projets après

authentification

4.1.1 Raffinement des cas d’utilisation de sprint 2 :

La figure ci-dessous présente le diagramme de cas d’utilisation de sprint 2 :

Figure 38 - Diagramme de cas d'utilisation de sprint 2

61
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

Raffinement de cas d’utilisation << créer projet >>

Figure 39 - Diagramme de cas d'utilisation

Description textuelle de cas d’utilisation <<Créer projet>> pour l’acteur <<client>>

Les scénarios d’exécution du cas d’utilisation <<créer projet>> sont décrits par le tableau
suivant représentant la fiche descriptive du cas :

Nom Créer projet

Acteur Utilisateur

Objectif La création d’un projet

Pré-condition Ce cas d’utilisation commence lorsque

l’utilisateur demande au système de faire la
création des projets :

1. L’utilisateur demande de la
création d’un projet
2. Le système affiche un formulaire
de création de projet
3. L’utilisateur remplit le formulaire
Le système vérifie les données
syntaxiquement

Post-condition Projet crée avec succès

Scénario Nominal L’utilisateur annule la création de projet :

. Le cas d’utilisation se termine avec échec

Tableau 17 -Description textuelle de cas d'utilisation <<créer projet>>

62
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

Raffinement de cas d’utilisation << Gérer projet>>

Figure 40 - Diagramme de cas d'utilisation <<Gérer projet >>

63
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

Les scénarios d’exécution du cas d’utilisation <<accepter projet>> sont décrits par les tableaux
suivants représentants les fiches descriptives du cas :

Description textuelle de cas d’utilisation <<accepter projet>> pour l’acteur

<<l’administrateur>>
Nom Accepter projet

Acteur Administrateur

Objectif L’administrateur contrôle et gère les

projets

Pré-condition Projet accepté

Post-condition Projet créer avec succès

Scénario Nominal Ce cas d’utilisation commence lorsque

l’administrateur demande au système de
faire l’acceptation des projets :

1. L’administrateur consulte
la liste des projets
2. L’administrateur demande
l’acceptation d’un projet
3. Le système demande la
confirmation
4. L’administrateur confirme
son choix
5. Le système envoie une
requête de modification au
SGBD

Scénario Alternatif L’administrateur annule la mise à jour :

. Le cas d’utilisation se termine avec échec

Tableau 18 - Description textuelle de cas d'utilisation <<Accepter projet>>

Description textuelle de cas d’utilisation <<refuser projet>> pour :

64
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

Tableau 21 : Description textuelle de cas d'utilisation <<Refuser projet>>

Nom Refuser projet

Acteur Administrateur

Objectif L’administrateur contrôle et gère les projets

Pré-condition Projet refusé

Post-condition Projet créer avec succès

Scénario Nominal Ce cas d’utilisation commence lorsque

l’administrateur demande au système de faire
le refuse des projets :

1. L’administrateur consulte
la liste des projets
2. L’administrateur demande
le refuse d’un projet
3. Le système demande la
confirmation
4. L’administrateur confirme
son choix
5. Le système envoie une
requête de modification au
SGBD

Scénario Alternatif L’administrateur annule la mise à jour :

. Le cas d’utilisation se termine avec échec

Tableau 19 - Description textuelle de cas d'utilisation <<Refuser projet>>

65
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

Raffinement de cas d’utilisation <<consulter projet>> pour l’acteur

<<utilisateur>>

Figure 41 - Diagramme de cas d'utilisation <<Consulter projet>>

Nom Consulter projet

Acteur Utilisateur

Objectif Consultation des projets

Pré-condition -L’utilisateur doit être authentifié

Post-condition Liste des projets affichés

Scénario Nominal Ce cas d’utilisation commence lorsque

l’utilisateur demande au système de faire la
consultation des projets :

1. L’utilisateur demande de
consulter la liste des projets
2. L’utilisateur envoi une requête
de sélection à l’entité projet
3. Le système affiche la liste des
projets
Scénario Alternatif L’utilisateur annule la consultation :
. Le cas d’utilisation se termine avec échec
. le système affiche un message d’erreur

Tableau 20 - Description textuelle de cas d'utilisation <<Consulter projet>>

66
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

5 Conception

5.1 Conception statique :

5.1.1 Diagramme de classe de sprint 2

Cette figure représente le diagramme de classe utilisé pour le développement du sprint

Figure 42 - Diagramme de classe du sprint 2

67
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

5.1.2 Dictionnaire des données du sprint 2

Les tableaux présentés ci-dessous illustrent le dictionnaire de données associé à notre base de
données.

Utilisateur

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Nomprénom CHAR 50 Oui

Email Varchar 255 Oui

Téléphone Int 8 Oui

Password VARCHAR 255 Oui

Tableau 21 - Dictionnaire de données <<utilisateur>>

Administrateur

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Email Varchar 255 Oui

Password VARCHAR 255 Oui

Tableau 22 - Dictionnaire de données <<administrateur>>

68
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

Projet

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Nom CHAR 50 Oui

Description Varchar 255 Oui

Tableau 23 - Dictionnaire des données <<projet>>

Service

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Titre CHAR 50 Oui

Description Varchar 255 Oui

Date Date Oui

création

Tableau 24 - Dictionnaire de données <<service>>

69
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

5.2 Conception dynamique

5.2.1 Diagramme de séquence

- diagramme de séquence << créer projet>> : Ce scénario décrit l’opération de création d’un
projet. Si le client demande la création d’un projet, le système affiche un formulaire à remplir
le client saisie les données et le système prend en charge la vérification des champs saisie le
système envoyer un message de succées de l’opération ou échec de l’opération

Figure 43 - Diagramme de séquence <<créer projet>>

70
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

Diagramme de séquence <<consulter projet>> : ce scénario décrit l’opération de

consultation d’un projet

Figure 44 - Diagramme de séquence <<Consulter projet>>

71
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

-Diagramme de séquence <<accepter projet>>

Ce diagramme décrit les scénarios possibles lors d’une opération d’acceptation d’un projet

Figure 45 - Diagramme de séquence <<Accepter projet>>

72
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

-Diagramme de séquence <<refuser projet>>

Ce diagramme décrit les scénarios possibles lors d’une opération le refuse d’un projet

Figure 46 - Diagramme de séquence <<Refuser projet>>

73
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

5.2.2 Le diagramme d’activité

Diagramme d’activité <<créer projet >>

La figure ci-dessous présente le diagramme d’activité de la création d’un projet

Figure 47 - Diagramme d'activité <<Créer projet>>

Diagramme d’activité <<accepter projet>>

74
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

La figure ci-dessous présente le diagramme d’activité de l’acceptation d’un projet

Figure 48 - Diagramme d'activité <<Accepter projet>>

75
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

6 Réalisation de sprint

6.1 Les interfaces

Dans cette partie, nous allons présenter quelques interfaces de site afin de montrer le
résultat de ce sprint

La figure ci-dessous présente l’acceptation ou le refus d’un projet

Figure 49 - Interface gérer projet

76
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

6.2 Interface <<consulter projet>>

La figure ci-dessous présente la consultation d’une liste des projets pour l’acteur utilisateur

Figure 50 - Interface consulter projet

77
 FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

7 - Test et validation

Le tableau ci-dessous présente le fiche test fonctionnel de l’interface acceptation

Id accepté Type fonctionnel

Testeur : Ranya Mahjoubi

Object attendu : l’administrateur doit accepter le projet désiré

Description : après le développement de l’interface d’acceptation on va vérifier toutes les

interactions de système après la consultation de la liste des projets, choisir un projet le système
demande la confirmation d’acceptation. L’administrateur valider l’acceptation
Règles métier :
Règle 1 : l’administrateur accède à l’interface accepter projet
Règle 2 : l’administrateur consulte la liste des projets
Règle 3 : l’administrateur choisie un projet
Règle 4 : l’administrateur confirme l’acceptation
Tests d’acceptation sur l’entité : projet

Nom de scénario : l’administrateur confirme l’acceptation

- L’administrateur consulte la liste des projets

- Choisir un projet
- L’administrateur demande l’acceptation
- L’administrateur confirme l’acceptation

Tableau 25 - Test fonctionnel de l'interface <<Acceptation>>

78
FSJEGJ Chapitre 4 : Mise en œuvre de sprint 2

8 Conclusion

Au cours de ce chapitre, nous avons présenté le deuxième sprint. Pour ce faire, nous avons
passé par la spécification, la conception et la réalisation. Dans le chapitre suivant nous entamons
le troisième sprint.

79
 FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

Chapitre 5 | Mise en œuvre de sprint 3

1 Introduction :

En partant sur le même principe que les deux sprints précédents. Pour cela, nous commençons
par le backlog du sprint, ensuite nous passons à l’analyse et la conception. Nous terminons par
la réalisation et le test.

2 Backlog du sprint 3 :

Id Fonctionnalité Tache Date début Date fin Responsable

1 Gérer service -Modifier service 20/04/2022 27/04/2022

-supprimer
service
Mahjoubi Ranya
-Ajouter service

2 Passer 28/04/2022 05/05/2022

réclamation

3 Consulter 06/05/2022 13/05/2022

statistique

Tableau 26 - Backlog du sprint 3

85
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

3 Tableau des taches :

Le tableau de taches est un affichage visuel de la progression de l’équipe Scrum au cours d’un
sprint.
Il est divisé en trois colonnes : les taches à réaliser, les tâches en cours et les tâches réalisé. La
figure ci-dessous présente le tableau des taches du sprint 3

Figure 51 - Tableau des taches du sprint 3

4 Phase d’analyse :

Dans cette partie, nous présentons les diagrammes de cas d’utilisation et la description
textuelle de certain d’entre eux.

4.1 Identification des acteurs

Les principaux acteurs de ce sprint sont :

Utilisateur : l’acteur déclencheur de ce sprint, il passe une réclamation après

authentification

Administrateur : c’est l’acteur responsable de la modification, suppression et l’ajout des

services aussi la consultation des statistiques après authentification

86
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

4.1.2 Raffinement de cas d’utilisation du sprint 3

La figure ci-dessous présente le diagramme de cas d’utilisation de sprint 3 :

Raffinement de cas d’utilisation Gérer service :

Figure 52 - Diagramme de cas d'utilisation <<Gérer service>>

87
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

Nom Gérer service

Acteur Administrateur

Objectif Le site doit permettre à l’administrateur

d’ajouter, modifier et supprimer des
produits

Pré-condition Administrateur authentifié

Post-condition Service ajouté, modifié et supprimé

Scénario Nominal Ajouter service

1. Le système affiche l’interface

d’ajout
2. L’administrateur saisit les données
et valide
3. Le système enregistre le nouveau
service
Modifier service
1. L’administrateur demande de
modifier un service
2. Le système redirige vers la page des
mise-a-jour
3. L’administrateur choisir le service a
modifié
4. Le système enregistre les
modifications
Supprimer service
1. L’administrateur supprime un
service
2. Le système supprime le service de la
base de données
Scénario Alternatif Ajouter produit : produit existant :
2.1 Le système affiche un message
d’erreur
2.2 Le scénario recommence du point 1
du scénario nominal

Tableau 27 - Description textuelle de cas d'utilisation <<Gérer service>>

88
 FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

Raffinement de cas d’utilisation Passer réclamation :

Figure 53 - Diagramme de cas d'utilisation <<Passer réclamation>>

Description textuelle de cas d’utilisation << passer réclamation >> pour l’acteur
<<utilisateur>>

Nom Passer réclamation

Acteur Utilisateur

Objectif Le site doit permettre à l’utilisateur

d’envoyer des réclamation

Pré-condition Utilisateur authentifié

Post-condition Réclamation envoyé

Scénario Nominal 1. Le client demande de passer une

réclamation
2. Le système affiche le formulaire
3. Le client saisit son message et
valide
4. Le système affiche un message de
confirmation d’envoi

Tableau 28 - Description textuelle de cas d'utilisation <<Passer réclamation>>

89
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

Raffinement de cas d’utilisation <<consulter statistique>>

Figure 54 - Diagramme de cas d'utilisation <<Consulter statistique>>

Description textuelle de cas d’utilisation <<consulter statistique>> pour l’acteur

<<administrateur>>

Nom Consulter statistique

Acteur Administrateur

Objectif Consulter les statistiques

Pré-condition Administrateur authentifié

Post-condition Les statistiques sont consultées

Scénario Nominal 1. L’administrateur demande au

système de consulter les statiques
2. Le système affiche l’interface de
consultation
3. Le système affiche les statistiques
Scénario alternatif Le système affiche message erreur

Tableau 29 - Description textuelle de cas d'utilisation <<Consulter statistique>>

90
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

5 Conception

5.1 Conception statique

5.1.1 Diagramme de classe globale :

Le figure ci-dessous présente le diagramme de classe globale :

Figure 55 - Diagramme de classe globale

91
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

5.1.2 Dictionnaire de données de sprint 3

Les tableaux présentés ci-dessous illustrent le dictionnaire de données associé à notre base de
données.

Utilisateur

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Nomprénom CHAR 50 Oui

Email Varchar 255 Oui

Téléphone Int 8 Oui

Password VARCHAR 255 Oui

Tableau 30 - Dictionnaire de données <<utilisateur>>

Administrateur

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Email Varchar 255 Oui

Password VARCHAR 255 Oui

Tableau 31 - Dictionnaire de données <<administrateur>>

92
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

Projet

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Nom CHAR 50 Oui

Description Varchar 255 Oui

Tableau 32 - Dictionnaire des données <<projet>>

Service

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Titre CHAR 50 Oui

Description Varchar 255 Oui

Date Date Oui

création

Tableau 33 - Dictionnaire de données <<service>

Réclamation

Attribut Type Taille Obligatoire Clé

Id BIGINT 20 Oui Clé primaire

Titre CHAR 50 Oui

Contenu Varchar 255 Oui

Date Date Oui

Tableau 34 - Dictionnaire des données <<réclamation>>

93
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

6 Conception dynamique

6.1 Diagramme de séquence

Figure 56 - diagramme de séquence <<ajouter service>>

94
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

Figure 57 - diagramme de cas d’utilisation <<passer réclamation>>

95
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

Figure 58 - diagramme de séquence <<consulter statistique>>

96
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

6.2 Diagramme d’activité

Diagramme d’activité <<Modifier service >>

La figure ci-dessous présente le diagramme d’activité de la modification d’un service :

Figure 59 - Diagramme d'activité <<Modifier service>>

97
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

Diagramme d’activité <<Passer réclamation>>

La figure ci-dessous présente le diagramme d’activité de passer une réclamation :

Figure 60 - Diagramme d'activité <<Passer réclamation>>

98
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

7 Réalisation du sprint

7.2 les interfaces :

Dans cette partie, nous allons présenter quelques interfaces de site afin de montrer le résultat de
ce sprint

7.2.1 Interface Gérer service :

La figure ci-dessous présente l’interface de gérer service

Figure 61 - Interface gérer service

99
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

7.2.2 Interface consulter statistiques

Figure 62 - Interface consulter statistiques

100
 FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

8 Test et validation

Id réclamation Type fonctionnel

Testeur : Ranya Mahjoubi

Object attendu : l’utilisateur passer une réclamation

Description : après le développement de l’interface de réclamation l’utilisateur va passer une réclamation

Règles métier :
Règle 1 : l’utilisateur accède à l’interface réclamation
Règle 2 : l’utilisateur consulte l’interface de réclamation
Règle 3 : l’utilisateur passer une réclamation

Tableau 35 – Test fonctionnel de l’interface <<réclamation>>

101
FSJEGJ Chapitre 5 : Mise en œuvre de sprint 3

9 Conclusion
Au cours de ce chapitre, nous avons présenté le troisième sprint. Pour ce faire, nous avons passé
par la spécification, la conception et la réalisation.

102
Conclusion générale

Ce projet nous a permis d’approfondir nos connaissances théoriques dans la conception et le

développement des sites web.
Ce dernier était bénéfique pour nous dans plusieurs sens. Il nous a permis de
- Nous perfectionner en améliorant nos connaissances en programmation et en conception
- De bien comprendre et mettre en œuvre le déroulement d’un cycle de vie d’un logiciel

Nous avons essayé de réaliser ce projet pour le but de faciliter la demande de création des projets
(Solution IT) et pour connaitre plus d’information à propos notre Startup Data2ai. On a appliqué
au maximum possible les règles de bases permettant d’avoir une application performante. Nous
avons appliqué UML pour concevoir une grande partie de notre travail.
Grâce aux architectures que nous avons utilisées (architecture 3-tiers) notre application peut
avoir des extensions ou des modifications dans le futur.
Notons enfin, nous espérons que ce projet satisfera mon encadrant et les membres de jury, et
servira comme outils pour faciliter les taches aux clients

103
Bibliographie

[1] WampServer [Link]

[2] StarUml [Link]
[3] Visual Studio code [Link]
[4] LucidChart [Link]
[5] Trello [Link]
[6] Gantt Project [Link]
[7] Architecture 3-tier
[Link]
[8] MVC [Link]

104
105
106
107