Rapport EPS VERSION Finale - Abderrahmen

République Tunisienne
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
RAPPORT DE PROJET DE FIN D’ETUDES

Pour l’obtention du Diplôme National d’Ingénieur en
Génie Informatique de Gestion
Sujet :
Conception et développement d'une
plateforme web de Craftsmen-Customer
Relation Management
Réalisé Par : Zorgati Abderrahmenne
Encadrant Académique : Mr. Malek BEN SALEM
Encadrant Professionnel : Mr. Samy Dghim
Année Universitaire : 2020 - 2021

Dédicaces
À ma Mère, « kahloun Sihem »

Tu m’as donné la vie, la tendresse et le courage pour réussir. Tout ce que je peux t’offrir ne
pourra exprimer l’amour et la reconnaissance que je te porte. En témoignage, je t’offre ce
modeste travail pour te remercier pour tes sacrifices et pour l’affection dont tu m’as toujours
entourée.
À mon Père, « Zorgati Lotfi »

L’épaule solide, l’œil attentif compréhensif et la personne la plus digne de mon estime et de
mon respect. Aucune dédicace ne saurait exprimer mes sentiments, que Dieu te Préserve et
te procure santé et longue vie.
A mon cher et unique Frère « Zorgati Thameur »

Merci mon chère pour votre patience, votre aide et votre respect. Je vous souhaite beaucoup
de bonheur et de réussite.
Zorgati Abderrahmenne
Remerciements
Avant d’entamer ce rapport, nous profitons de l’occasion pour remercier tout d’abord notre
enseignant monsieur Malek BEN SALEM qui n’a pas cessé de nous encourager pendant la
durée du projet ainsi pour sa générosité en matière de formation et d’encadrement. Nous le
remercions également pour l’aide et les conseils concernant les missions évoquées dans ce
rapport, qu’il nous a apporté lors des différents suivis, et la confiance qu’il nous a témoigné.
Nous tenons à exprimer une sincère reconnaissance à monsieur Anwar MANSOURI, le

directeur général de la société « Com&Dev », pour la confiance qu'il nous a accordée
pendant notre stage ainsi que pour l'expérience enrichissante et pleine d'intérêt qu'il nous a
fait vivre durant ces quatre mois. Nous le remercions pour sa participation active à
l'élaboration de ce rapport.
Nous tenons à exprimer une sincère reconnaissance à notre encadrant professionnel

monsieur Samy DGHIM pour son accueil et sa générosité en termes de partage d’expertise
et du temps qu’il nous a pleinement consacré.
Nos remerciements vont à toute l’équipe pédagogique et administrative de l’Ecole

Polytechnique de Sousse et les intervenants professionnels responsables de la formation du
cycle d’ingénieur en Informatique de Gestion.
Ce travail sera évalué par mes chers enseignants, qu’ils soient vivement remerciés pour avoir
accepté de faire partie du jury, en espérant qu’ils trouvent dans ce rapport la valeur ajoutée
qu’ils attendent.
Table des matières
Introduction Générale --------------------------------------------------------------------------------------------- 9
Chapitre 1 : Cadre général du projet -------------------------------------------------------------------------- 10
Introduction : ----------------------------------------------------------------------------------------------------- 11
1.1 Présentation de la société d’accueil ------------------------------------------------------------------- 11
1.2 Sujet du projet et problématique ----------------------------------------------------------------------- 12
1.3 Etude de l’existant --------------------------------------------------------------------------------------- 12
1.3.1 Les applications existantes dans le marché ---------------------------------------------------------- 13
1.3.2 Critique de l’existant et la solution à proposer ------------------------------------------------------ 14
1.4 Méthodologie existante pour la gestion de projet --------------------------------------------------- 16
1.5 Méthodologie choisie pour la mise en œuvre du projet -------------------------------------------- 18
1.5.1 Principe de « Agile SCRUM »------------------------------------------------------------------------- 19
1.5.2 Organisation du travail avec « Agile Scrum »------------------------------------------------------- 19
Conclusion -------------------------------------------------------------------------------------------------------- 20
Chapitre 2 : Pilotage de projet avec Agile SCRUM -------------------------------------------------------- 21
Introduction ------------------------------------------------------------------------------------------------------- 22
2.1 Outils utilisés dans la gestion du projet -------------------------------------------------------------- 22
2.2 Diagramme de Gantt : ----------------------------------------------------------------------------------- 24
2.3 Définition des équipes et des rôles -------------------------------------------------------------------- 25
2.4 Le Backlog de produit ----------------------------------------------------------------------------------- 25
2.4.1 Identification des acteurs ------------------------------------------------------------------------------- 25
2.4.2 Identification des User Stories ------------------------------------------------------------------------- 26
2.5 Planification des releases et des sprints -------------------------------------------------------------- 28
2.6 Environnements de travail ------------------------------------------------------------------------------ 29
2.6.1 Environnement logiciel --------------------------------------------------------------------------------- 30
2.6.2 Technologies de développement ---------------------------------------------------------------------- 31
2.6.3 Architecture physique ----------------------------------------------------------------------------------- 32
Conclusion -------------------------------------------------------------------------------------------------------- 34
1|Page
Chapitre 3 : Realise 1 ------------------------------------------------------------------------------------------- 35
Système de métier et de recherche des techniciens --------------------------------------------------------- 35
3.1 Mise en œuvre du sprint 1 : Système d’utilisateur et des métiers -------------------------------- 36
3.1.1 Spécification fonctionnelle ----------------------------------------------------------------------------- 36
3.1.1.1 Backlog du sprint 1 ------------------------------------------------------------------------------------- 36
3.1.1.2 Spécification des cas d’utilisation du sprint 1 ------------------------------------------------------ 37
3.1.1.3 Description textuelle des cas de besoins ------------------------------------------------------------ 37
a) Analyse de cas d’utilisation « S’authentifier » ------------------------------------------------------ 38
b) Analyse de cas d’utilisation « Ajouter Job » -------------------------------------------------------- 38
c) Analyse de cas d’utilisation « Modifier Jobs » ------------------------------------------------------ 39
d) Analyse de cas d’utilisation « Supprimer Job » ----------------------------------------------------- 40
e) Analyse de cas d’utilisation « Consulter la liste des Jobs » --------------------------------------- 40
3.1.2 Conception du sprint 1 ---------------------------------------------------------------------------------- 41
3.1.2.1 Diagrammes de séquences du sprint 1 -------------------------------------------------------------- 42
a. Diagramme de séquence « Authentification »------------------------------------------------------- 43
b. Diagramme de séquence « Ajouter Job » ------------------------------------------------------------ 43
c. Diagramme de séquence « Modifier job » ----------------------------------------------------------- 44
d. Diagramme de séquence « Consulter la liste des Jobs » ------------------------------------------- 45
e. Diagramme de séquence « Supprimer Job » --------------------------------------------------------- 45
3.1.2.2 Diagramme de classes relatif au sprint 1 ------------------------------------------------------------ 46
3.1.2.3 Diagramme d’activité ---------------------------------------------------------------------------------- 46
3.1.3 Revue du Sprint 1 ---------------------------------------------------------------------------------------- 47
3.2 Mise en œuvre du sprint 2 : recherche technicien et l’envoie une demande -------------------- 51
3.2.1.3 Description textuelle du scénario -------------------------------------------------------------------- 52
a. Analyse de cas d’utilisation « Ajout un JobProfile » ----------------------------------------------- 52
b. Analyse de cas d’utilisation « Consulter JobProfile »---------------------------------------------- 53
2|Page
c. Analyse de cas d’utilisation « Modifier JobProfile »----------------------------------------------- 54
d. Analyse de cas d’utilisation « Supprimer JobProfile »--------------------------------------------- 55
3.2.2 Conception du Sprint 2---------------------------------------------------------------------------------- 55
3.2.2.1 Diagramme de séquence du Sprint 2 ---------------------------------------------------------------- 56
a. Diagramme de séquence « Recherche Technicien » ----------------------------------------------- 56
3.2.2.2 Diagramme de Classe du Sprint 2-------------------------------------------------------------------- 56
3.2.2.3 Diagramme d’activité ---------------------------------------------------------------------------------- 58
3.2.3 Revue du Sprint 2 ---------------------------------------------------------------------------------------- 58
Conclusion -------------------------------------------------------------------------------------------------------- 62
Chapitre 4 : Realise 2 ------------------------------------------------------------------------------------------- 63
Système d’interaction entre les intervenants et système de Planning------------------------------------ 63
4.1 Mise en œuvre du sprint 3 : Système d’interaction entre les intervenants ---------------------- 64
a. Analyse de cas d’utilisation « Ajout un Commentaire »------------------------------------------- 65
b. Analyse de cas d’utilisation « Supprimer Commentaire »----------------------------------------- 66
a. Diagramme de séquence « Ajouter Commentaire » ------------------------------------------------ 67
b. Diagramme de séquence « Supprimer Commentaire » -------------------------------------------- 68
4.1.2.2 Diagramme de classe du sprint 3 --------------------------------------------------------------------- 68
4.1.3 Revue du sprint 3 ---------------------------------------------------------------------------------------- 69
4.2 Mise en œuvre du sprint 4 : Planning de la disponibilité de technicien ------------------------- 71
3|Page
a. Analyse de cas d’utilisation « Ajout un Planning » ------------------------------------------------ 72
b. Analyse de cas d’utilisation « Supprimer Commentaire »----------------------------------------- 73
a. Diagramme de séquence « Ajouter Planning » ------------------------------------------------------ 74
b. Diagramme de séquence « Supprimer Planning » -------------------------------------------------- 74
4.2.3 Diagramme de classe du sprint 4 ---------------------------------------------------------------------- 75
4.2.4 Revue du sprint 4 ---------------------------------------------------------------------------------------- 76
Conclusion -------------------------------------------------------------------------------------------------------- 76
Conclusion générale et perspectives -------------------------------------------------------------------------- 77
4|Page
Liste des Figures
Figure 1 : Logo de la société « Com&dev » ----------------------------------------------------------------- 11
Figure 2 : L'interface de l'application « snay3i.tn » -------------------------------------------------------- 13
Figure 3 : L'interface de l’application « Jobartisans » ----------------------------------------------------- 13
Figure 4 : Captures de l'application « Tunisie Travail » --------------------------------------------------- 14
Figure 5 : Logo de « Agile SCRUM »------------------------------------------------------------------------ 18
Figure 6 : Cycle de vie de SCRUM --------------------------------------------------------------------------- 19
Figure 7 : une interface de la plateforme « GitHub » ------------------------------------------------------ 23
Figure 8 : l’interface de l’outil de communication Slack -------------------------------------------------- 23
Figure 9 : interface Google Meet ------------------------------------------------------------------------------ 24
Figure 10 : Diagramme de « GANNT » ---------------------------------------------------------------------- 24
Figure 11 : L’équipe de développement de la solution « Work » ---------------------------------------- 25
Figure 12 : Environnement Matériel -------------------------------------------------------------------------- 29
Figure 13 : Logo de la technologie « Ruby On Rails » --------------------------------------------------- 31
Figure 14 : L'architecture MVC ------------------------------------------------------------------------------- 32
Figure 15 : Architecture de l’application en couches ------------------------------------------------------ 33
Figure 16 : Architecture physique de la solution « Work » ----------------------------------------------- 34
Figure 18 : Raffinement de cas d'utilisation du « Sprint 1 » ---------------------------------------------- 37
Figure 19 : Vue 4+1 Kruchten --------------------------------------------------------------------------------- 41
Figure 20 : Diagramme de séquence « Authentification » ------------------------------------------------ 43
Figure 21 : Diagramme de séquence « Ajout d'un job » --------------------------------------------------- 44
Figure 22 : Diagramme de séquence « Modifier job » ----------------------------------------------------- 44
Figure 23 : Diagramme de séquence « Consultation liste Jobs » ----------------------------------------- 45
Figure 24 : Diagramme de Séquence « Suppression d'un Job » ------------------------------------------ 45
Figure 25 : Diagramme de Classes du « Sprint 1 » --------------------------------------------------------- 46
Figure 26 : Diagramme d'activité « Authentification » ---------------------------------------------------- 47
Figure 27 : Interface de page d'accueil de la plateforme « Work » -------------------------------------- 48
Figure 28 : Interface « d'authentification » ------------------------------------------------------------------ 49
Figure 29 : Interface de la « liste des utilisateurs » --------------------------------------------------------- 49
Figure 30 : interface « d'ajout Job » -------------------------------------------------------------------------- 50
Figure 31 : Interface de la « liste des Jobs » ----------------------------------------------------------------- 50
Figure 33 : Diagramme de Séquence « Recherche Technicien »----------------------------------------- 56
Figure 34 : Diagramme de classe du « Sprint 2 » ----------------------------------------------------------- 57
Figure 35 : Diagramme d'activité « Ajout Demande » ----------------------------------------------------- 58
5|Page
Figure 36 : interface « d’ajout JobProfile » ------------------------------------------------------------------ 59
Figure 37 : interface de la « liste de JobProfile » ----------------------------------------------------------- 59
Figure 38 : interface de « recherche un fournisseur de service » ----------------------------------------- 60
Figure 39 : interface « d’ajout demande » ------------------------------------------------------------------- 60
Figure 40 interface de « notification email » --------------------------------------------------------------- 61
Figure 41 : interface de la « liste des demandes » ---------------------------------------------------------- 61
Figure 43 : Diagramme de séquence « Ajouter Commentaire » ------------------------------------------ 67
Figure 44 : Diagramme de séquence « Supprimer Commentaire » -------------------------------------- 68
Figure 46 : interface de la « liste des conversations »------------------------------------------------------ 69
Figure 47 : interface d’interaction entre les intervenants -------------------------------------------------- 70
Figure 48 : interface « d’ajout commentaire » -------------------------------------------------------------- 70
Figure 49 Raffinement de cas d'utilisation du Sprint 4---------------------------------------------------- 72
Figure 50 : Diagramme de séquence « Ajouter Planning » ----------------------------------------------- 74
Figure 51 : Diagramme de séquence « Supprimer Planning » -------------------------------------------- 75
Figure 53 : interface de la « liste des plannings » ---------------------------------------------------------- 76
Figure 54 : interface « d’ajout planning »-------------------------------------------------------------------- 76
6|Page
Liste des tableaux
Tableau 1 : Comparatif des solutions existantes ------------------------------------------------------------ 14
Tableau 2 : Comparatif entre les principales méthodologies --------------------------------------------- 17
Tableau 3 : Backlog des Produits ----------------------------------------------------------------------------- 26
Tableau 4 : Planification des « Release » et des « Sprint » ----------------------------------------------- 29
Tableau 5 : Backlog du « sprint 1 » --------------------------------------------------------------------------- 36
Tableau 6 : Description de cas d'utilisation « Authentification » ---------------------------------------- 38
Tableau 7 : Description de cas d'utilisation « Ajout Job » ------------------------------------------------ 38
Tableau 8 : Description de cas d'utilisation « Modifier Job »--------------------------------------------- 39
Tableau 9 : Description de cas d'utilisation « Supprimer Job » ------------------------------------------ 40
Tableau 10 : Description de cas d'utilisation « Consultation Job » -------------------------------------- 40
Tableau 11 : Backlog « Sprint 2 »----------------------------------------------------------------------------- 51
Tableau 12 : Description de cas d'utilisation « Ajout JobProfile »--------------------------------------- 53
Tableau 13 : Description de cas d'utilisation « Consultation la liste des JobProfiles » --------------- 53
Tableau 14 : Description de cas d'utilisation « Modifier JobProfile » ----------------------------------- 54
Tableau 15 : Description de cas d'utilisation « Supprimer JobProfile » --------------------------------- 55
Tableau 16 : Backlog du « sprint 3 » ------------------------------------------------------------------------- 64
Tableau 17 : Description de cas d'utilisation « Ajout Commentaire »----------------------------------- 65
Tableau 18 : Description de cas d'utilisation « Supprimer Commentaire »----------------------------- 66
Tableau 19 : Backlog du « sprint 4 » ------------------------------------------------------------------------- 71
Tableau 20 : Description de cas d'utilisation « Ajout Planning » ---------------------------------------- 72
Tableau 21 : Description de cas d'utilisation « Supprimer Planning » ---------------------------------- 73
7|Page
Glossaire
MVC : Model-View-Controller
UML : Unified Modeling Language
CU : Cas D‘utilisation
RoR : Ruby On Rails
SEO : Search Engine Optimisation
CMS : Système de Gestion de Contenu
HTML : HyperText Markup Language
HTTP : Hypertext Transfer Protocol
PHP : Hypertext Preprocessor
IDE : Integrated Development Environment
PERT : Program Evaluation and Review Technic
IDEF0 : Integration Definition for Function Modeling
CSS : Cascading Style Sheets
8|Page
Introduction Générale
Personne ne peut plus douter que l'informatique est une révolution fondamentale et
innovante qui a touché considérablement la vie humaine durant le dernier siècle. En effet,
loin d'être un phénomène effervescent, ou une tendance passagère, l'informatique vient d'être
exploitée dans tous les aspects de la vie. Aucun domaine n'est resté à l'abri de cette politique
qui facilite les tâches aussi bien pour l'entreprise que pour le personnel.
Dans le marché tunisien, la concurrence devient de plus en plus forte, ce qui oblige les
entreprises à offrir des services de très haute qualité afin de satisfaire leur clientèle. Pour cela
elles doivent être constituées d'un ensemble de services et départements fiables tels que le
service clientèle, le service après-vente, etc.
A cet effet, le travail que nous préparons, dans le cadre du projet de fin d’études à l’école
Polytechnique de Sousse en vue de l'obtention du diplôme d’ingénieur en informatique de
gestion, consiste à développer une plateforme web de « Craftsmen-Customer Relation
Management ». Le présent rapport vient couronner un projet réalisé durant quatre mois. Ce
présent rapport s'articulera autour de quatre chapitres. Le premier chapitre présente
l’organisme d’accueil, le cadre du projet ainsi que la méthodologie de travail utilisée. Un
deuxième chapitre est défini présentant ainsi un pilotage du projet avec la méthode « Agile
SCRUM » à travers l’identification des acteurs, la définition des besoins fonctionnels ainsi
les besoins techniques. Le troisième chapitre est consacré au premier « release » qui est
composé de deux premiers « sprints » à travers lesquels nous mettons l’accent sur la
spécification fonctionnelle, la conception et la réalisation. Le quatrième chapitre présente le
deuxième release qui implémente le module de conversation entre les deux intervenants et
le suivi de technicien à travers « review » de coté de la satisfaction d’un client.
9|Page
Chapitre 1 : Cadre général
du projet
Chapitre 1 : cadre général du projet
Introduction :
Nous allons essayer tout d'abord de mettre notre application dans son contexte général. Ainsi,
dans ce premier chapitre, nous présentons l'organisme d'accueil, suivi par une étude et une
critique de l’existant menant ainsi à décrire la problématique de ce projet. De même, nous
présentons la méthodologie utilisée dans l’élaboration du projet.
1.1 Présentation de la société d’accueil
Logo A. Filiale Tunisie Logo B. Siège France
Figure 1 : Logo de la société « Com&dev »
« Com&dev » est une société de services et d’ingénieur en informatique basé à Sousse et

fondée en 2015 spécialisée en développement web et mobile, réseau et administration des
systèmes, markéting digitale et télémarketing. Elle est une filiale de la société française
« ALTAGEM » qui est une entreprise de développement informatique et organisme de
formation située en région lyonnaise et spécialisée dans le développement de solution à la
gestion d’équipe mobiles.
« Com&dev » préconisé et met en œuvre des solutions techniques pour concevoir des
applications web et mobile sur mesure ou pour adapter des solutions techniques existantes.
A ce titre, elle est responsable de :
❖ L’analyse des besoins,
❖ Le choix de la solution technique,
❖ Le développement de toutes les fonctionnalités techniques,
❖ Le respect des bons pratiques de codage,
❖ Les tests et la validation de fonctionnalités développés,
❖ L’intégration CMS, e-commerce,
❖ L’optimisation et le SEO,
❖ La maintenance évolutive des applications,
❖ La formation du client lorsque l’application lui est libéré,
11 | P a g e
❖ Corrections des problèmes remontés par le client,
❖ Support technique.
Grace à un expertise métier et technique, « Com&Dev » offre à ses clients une solution
adapté à leurs besoins dans différents secteurs d’activités, même elle garantit également une
bonne communication et un service de support de qualité pour toute réclamation ou
demande.
1.2 Sujet du projet et problématique

Suite à une étude préalable sur le marché tunisien, on trouve plusieurs métiers non organisés
par exemple les métiers artisanaux. Dans ce sens, il est très remarquable l’existence d’une
faible interaction entre les intervenants de ce métier : le fournisseur de service et le client.
Parmi les insuffisances dans ce type d’interactions, si un client veut chercher un fournisseur
de service dans un métier spécialisé (plomberie, maçonnerie, etc.), selon sa région, permet
de manquer beaucoup de temps afin de rechercher ce fournisseur de service. En outre, les
procédures de contact entre les intervenants dans le cadre d’un même métier peuvent ne pas
aider un tel client à acquérir un ensemble suffisant d’informations sur les compétences du
fournisseur de services. On confirme que la technologie n’est pas vraiment présente au sein
du domaine artisan.
Dans le but de répondre à ces exigences de ce domaine, La société « Com&Dev » m’a confié
d’étudier la mise en place d’une solution permettant d’instaurer une bonne mise en relation
entre tous les intervenants du domaine des métiers artisanaux (les clients et les fournisseurs
de service). Cette mise en place d’une telle solution, qui est le sujet du projet décrit dans ce
présent rapport, doit être guidée par une étude préalable où, on effectue une analyse des
applications existantes dans le marché, une critique de ces applications ainsi qu’une décision
pour lancer un projet de développement ou non.
1.3 Etude de l’existant

L’étude de l’existant permet de déterminer les points faibles et les points forts d’un produit
actuel pour pouvoir déterminer les besoins du client, en vue d’en prendre en considération
lors de la conception et la réalisation de notre application. Dans cette section, Nous
présentons une analyse de quelques exemples d’applications marchandes. Ensuite, Nous
formulerons une solution de la problématique.
12 | P a g e
1.3.1 Les applications existantes dans le marché

Afin de bien étudier la faisabilité de l’application il faut effectuer une étude de l’existante
des applications sur le marché de ce fait, dans cette section nous allons présenter une brève
description sur ces application-là.
❖ L’application « snay3i.tn »
C’est une application web nationale, l’étendus de son utilisation, elle couvert sur la
région de la Tunisie basé sur le « google maps ».
Figure 2 : L'interface de l'application « snay3i.tn »
❖ L’application « Jobartisans »
C’est une application web international, permet de trouver un emploi dans les métiers de
l’artisanat et des services qui recrutent.
Figure 3 : L'interface de l’application « Jobartisans »
13 | P a g e
❖ L’application « Tunisie Travail »

C’est une application mobile permet de gérer des différents métiers pour plusieurs personne.
Figure 4 : Captures de l'application « Tunisie Travail »
1.3.2 Critique de l’existant et la solution à proposer

Notre critique de l’existant est effectuée via un comparatif entre les solutions existantes on
se basant sur un ensemble de critères. Le tableau numéro 1 présente ce comparatif où on a
utilisé deux symboles : un premier symbole (✔) signifie que le critère est garanti par
l’application, un deuxième symbole (X) qui signifie que le critère n’est pas garanti par
l’application.
Tableau 1 : Comparatif des solutions existantes
Solution
Critère
Temps de réponse ✔ X X
Désigne ✔ X X
Maps ✔ X X
Sécurité
X X ✔
Facilité d’utilisation
X ✔ ✔
14 | P a g e
Ce comparatif des applications existantes, nous a permis de retirer un certain nombre de

lacunes dans ces applications :
❖ Perte des données et d’informations,
❖ Mauvaise exploitation des ressources humaines et matérielles,
❖ Prise de décision lentes au niveau de profile technicien,
❖ Interface utilisateur lourde,
❖ Coût de maintenance très élevé,
❖ Problème des interactions entre le client et le technicien,
❖ L’indication de service n’est pas dynamique,
❖ Frais d’utilisation très élevée à court terme,
❖ Quelques applications présentent un dysfonctionnement de quelques fonctionnalités.
Suite à une étude de lacune de différente solution proposé la société d’accueil nous a confié
de développer une solution personnalisée qui consiste à une application web permettent de
gérer les différentes ressources impliquer pour assurer une meilleure efficacité. Cette
solution permettra de :
❖ Réaliser une application web utilisée par l’administrateur permettant d’ajouter des
clients, des techniciens, des métiers et lui permettent de consulter l’interaction entre
technicien et client. De même, un client peut consulter la liste de « JobProfile » et il
peut choisir un technicien afin de l’envoyer une demande,
❖ La solution sera à la portée de tout le monde,
❖ Elle dispose d’une plateforme qui facilite la mise en place des profiles technicien
(Job Profile),
❖ Cette solution peut être un point de contact entre le client et le technicien a fin de
fluidifier les échanges entre eux,
❖ La solution permet aussi de permettre aux clients de pouvoir accéder aux services
offerts par les techniciens.
De même, la solution à proposer présente un ensemble de besoins non fonctionnels tels que :
15 | P a g e
❖ Sécurité : « Work » assure un contrôle d’accès basé sur des politiques

d’authentification et des privilèges entre les acteurs. Chaque utilisateur a un mot de
passe et un login pour son compte afin d'assurer la sécurité, aussi tous les mots
dépasses sont crypté, et pour s’authentifier on utilisera des sessions,
❖ Ergonomie : Notre application doit obéir aux contraintes suivantes afin d’équilibrer
entre ses fonctionnalités, les interfaces associées ainsi que leur prise en main par
l’utilisateur :
Avoir des interfaces simples, non encombrées, compréhensibles et

représentables de Point de vue design.
Bien organiser et structurer les rubriques afin de guider nos utilisateurs.
❖ Disponibilité : Exigence de disponibilité 24/24, 7/7 et informations en temps réel,
❖ Le temps de réponse : L’application doit être fiable et exacte en termes de résultats

fournis,
❖ Fiabilité : Il faut garantir la qualité du contenu et la pertinence des informations,
❖ Flexibilité : Possibilité d'intégrer des nouveaux modules ou des nouveaux services

aux modules existants.
1.4 Méthodologie existante pour la gestion de projet

Pour assurer un bon rendement de développement en termes de qualité et de productivité, le
choix d’une approche de travail est indispensable vu la complexité des systèmes de nos jours,
le génie logiciel doit tenter de remédier à cette complexité en offrant une démarche à suivre
avec des étapes bien précises. C’est le principe des méthodologies de gestion de projet.
Dans ce sens, on a effectué une brève étude comparative entre quatre méthodes de gestion
de projet afin de choisir parmi elles une méthode qui garantit des résultats satisfaisants et
efficaces. Le tableau numéro 2 présente comparatif entre les principales méthodologies.
16 | P a g e
Tableau 2 : Comparatif entre les principales méthodologies
Méthodologie Caractéristiques Avantages/inconvénients
Scrum Avantages
- Isolement de l’équipe de - Augmentation de la productivité,

développement, - Chaque équipe a son lot de
- Développement progressif, responsabilité,
- Travail est control -Détection rapide des anomalies.

quotidiennement. Inconvénients
- Il est bon pour les petits projets, car il ne

fonctionne bien qu’avec une petite équipe,
- Budget important.
eXtreme - les tests unitaires sont Avantages

Programming développés avant de coder les - implication massive du client,
(XP) fonctionnalités du système,
- processus itératif simple et court.
- Cible des projets de moins de
Inconvénients
10 personnes.
- exige un budget important.
Rational Unified - Cible des projets de plus de 10 Avantages

Process (RUP) personnes, - Amélioration quotidienne et continue et
- un pilotage par les cas adaptation aux changements.
d’utilisation, Inconvénients
- une démarche centrée - Personnalisation coutant.
sur l’architecture,
- une approche itérative et

incrémentale visant en priorité à
réduire les incertitudes.
17 | P a g e
Two Tracks - Propose un cycle de Avantages

Unified Process développement en Y, - Itératif,
(2TUP) - Prend en considération la - Fait une large place à 'la technologie et à
technologie et la gestion du la gestion du risque,
risque,
- Définit les profiles des intervenants, les
- Cible des projets de toutes livrables, les plannings, les prototypes.
tailles.
Inconvénients
- Plutôt superficiel sur les phases situées en

amont et en aval du développement :
capture des besoins, support, maintenance,
gestion du changement,
- Ne propose pas de documents types.
Suite à l’étude des quatre méthodes mentionnées ci-dessus et de leur convenance à notre
projet, nous avons opté pour l’utilisation de la méthode « Agile SCRUM ».
1.5 Méthodologie choisie pour la mise en œuvre du projet

« Agile SCRUM » est la méthodologie la plus utilisée parmi les méthodes Agiles existantes.
Le terme Scrum (qui signifie mêlée) apparaît pour la première fois en 1986 dans une
publication de « Hirotaka Takeuchi et Ikujiro Nonaka » qui décrit une nouvelle approche
plus rapide et flexible pour le développement de nouveaux produits. Ils comparent alors cette
nouvelle méthode au rugby à XV, le principe de base étant que l'équipe avance ensemble et
soit toujours prête à réorienter le projet au fur-et-à-mesure de sa progression, tel un ballon
de rugby qui doit passer de main en main jusqu'à marquer un essai. La figure numéro 5
présente logo de « Agile Scrum ».
Figure 5 : Logo de « Agile SCRUM »
18 | P a g e
1.5.1 Principe de « Agile SCRUM »

Evidemment, l’approche « Agile Scrum » suit les principes de la méthodologie Agile, c'est-
à-dire l'implication et la participation active du client tout au long du projet.
Considéré comme un cadre (Framework en anglais) de gestion de projet, Scrum se compose

de plusieurs éléments fondamentaux :
❖ Des rôles,
❖ Des événements,
❖ Des artefacts,
❖ Des règles.
Il s'agit d'une approche empirique (c'est-à-dire qui se base sur l'expérience), dynamique et
participative de la conduite du projet. Au rugby, la mêlée est une phase indispensable car
elle permet au jeu de repartir sur d'autres bases. Même chose pour Scrum : l'équipe se réunit
quotidiennement lors d'une réunion de synchronisation, appelée mêlée quotidienne, afin de
suivre l'avancement du projet. La figure numéro 6 présente le cycle de vie d’agile Scrum.
Figure 6 : Cycle de vie de SCRUM
1.5.2 Organisation du travail avec « Agile Scrum »

L'équipe Scrum est auto-organisée et pluridisciplinaire, c'est-à-dire qu'elle choisit la
meilleure façon d’accomplir son travail et qu'elle possède toutes les compétences nécessaires
à l'accomplissement du projet. La flexibilité, la créativité et la productivité de l'équipe sont
ainsi optimisées. L'équipe Scrum est composée de trois catégories de membres ;
❖ Le Scrum Master est responsable de la compréhension, de l'adhésion et de la mise

en œuvre de la méthode Scrum qu'il maîtrise parfaitement. Il veille à ce que les
19 | P a g e
principes et les valeurs de la méthodologie sont respectés. C'est un facilitateur qui

aide à améliorer la communication au sein de l’équipe et cherche à maximiser la
productivité et le savoir-faire de celle-ci. Il est considéré comme le coach de l'équipe
de développement.
❖ Le Product Owner porte la vision du produit à réaliser. Il travaille en interaction

avec l’équipe de développement qui doit suivre ses instructions. C'est lui qui établit
la priorité des fonctionnalités à développer ou à corriger, et qui valide les
fonctionnalités terminées. Il est responsable de la gestion du product backlog (ou
carnet de produit en français).
❖ L'équipe de développement est chargée de transformer les besoins définis par le

Product Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et possède
toutes les compétences nécessaires pour réaliser le projet, sans faire appel à des
prestations externes. Parmi ses membres, on trouve un architecte, un développeur, un
testeur, etc. La taille idéale de l'équipe de développement est de 3 à 9 personnes. Il
n'y a pas de notion de hiérarchie, toutes les décisions sont prises ensemble.
Conclusion
Ce premier chapitre nous donne une vue générale sur notre projet, une vue globale très
détaillée sur l’organisme d’accueil ainsi qu’une idée sur les différentes méthodologies de
gestion de projet. Dans le chapitre suivant nous allons présenter une mise en pratique de la
méthodologie de gestion de projet choisie.
20 | P a g e
Chapitre 2 : Pilotage de
projet avec Agile SCRUM
Chapitre 2 : Pilotage de projet avec Agile SCRUM
Introduction
Ce chapitre a pour objectif de faire une mise en pratique de la méthodologie agile pour
l’élaboration de notre projet de fin d’étude. La mise en œuvre de la méthodologie « Agile
Scrum » nécessite le suivi de plusieurs étapes depuis la spécification de « Backlog », vers la
planification des releases ainsi que l’indentification des différents « Sprints ». Enfin, nous
allons clôturer ce chapitre par la spécification des différents environnements matériels,
logiciels les mieux adaptés pour le produit visé et souhaités par le client.
2.1 Outils utilisés dans la gestion du projet

❖ La plateforme « GitHub »
Dans notre projet, nous avons choisi « GitHub » comme outil de gestion de code source. Une
interface de cette solution est affichée par la « figure numéro 7 » Parmi ces caractéristiques
on trouve :
Git est un système de contrôle de version open source,
Lorsque les développeurs créent un produit, ils modifient constamment le

code, publiant de nouvelles versions les unes après les autres,
Utiliser un système de contrôle des versions permet de stocker un historique des

modifications dans un référentiel central. Cela permet aux développeurs
de collaborer facilement,
C’est donc un outil un peu plus technique mais qui est, aussi, un très bon support
pour manager des projets Agiles. Beaucoup d’équipes l’utilisent en plus de Jira
car il s’intègre très bien aux outils de gestion de projet « Agile »,
« GitHub » est le système de contrôle de version préféré de la plupart des

développeurs, car il stocke en temps réel les modifications de fichiers.
Il permet également d’avoir un espace privé pour l’équipe ou un espace public où les
membres de la communauté peuvent vous aider à améliorer votre code.
En ce qui concerne des fonctionnalités plus « Agiles » GitHub permet de :
Créer des mentions et des étiquettes,
22 | Page
Suivre leur réalisation grâce à un workflow personnalisable [2].
Figure 7 : une interface de la plateforme « GitHub »
❖ La plateforme Slack : Il est un outil de communication collaborative. L’outil

regroupe dans un même endroit des fonctionnalités de messagerie instantanée,
d’outils de travail et de partage de fichier. La fonctionnalité « phare de Slack » est
la possibilité de créer différents « canaux » de conversation. La figure 8 c’est
représenté l’interface de l’outil de communication Slack [2].
Figure 8 : l’interface de l’outil de communication Slack
❖ La plateforme Google meet : Google Meet il est un outil de

communication, qu’on a utilisé afin de réussir le déroulement de projet, entre les
différente intervenant dans notre projet fin d’étude.la figure 9 représente l’interface
de google meet [2].
23 | Page
Figure 9 : interface Google Meet
2.2 Diagramme de Gantt :

Nous montrons dans cette figure la planification structurelle de notre projet. Comme
le montre ce diagramme, nous avons commencé notre projet par la recherche, ensuite
viennent les phases de conception et réalisation de l’application. La rédaction du
rapport prend cours tout au long du projet.
Figure 10 : Diagramme de « Gantt »
24 | Page
2.3 Définition des équipes et des rôles

On présente dans la figure 11, les trois intervenants de l’équipe de développement de la
solution « Work ».
Figure 11 : L’équipe de développement de la solution « Work »

❖ Le Product Owner : C’est le propriétaire du produit, il est la seule personne respon-
sable de la gestion de la liste des tâches du produit (Backlog produit).
❖ Le Scrum master : C’est le chef d’une équipe Scrum, il est chargé de défendre un
projet, de fournir des conseils à l’équipe et au propriétaire du produit, et de s’assurer
que toutes les pratiques agiles sont suivies par les membres de l’équipe.
❖ Le Scrum Team : C’est l’équipe de développement possédant des experts qui four-
nissent chaque incrément de produit en un Sprint terminé qui sera livré. Seuls les
membres de l’équipe de développement peuvent ajouter des incréments.
2.4 Le Backlog de produit

Le « Backlog » d’un produit est utilisé pour identifier la liste des fonctionnalités prévues
pour le produit et attendus par l’utilisateur final. Le tableau 3 représente le Backlog produit.
2.4.1 Identification des acteurs

Un acteur est une personne ou un système qui interagit avec l’application en échangeant de
l’information. Les intervenants du système sont :
❖ L’administrateur système : c’est la personne qui gère la totalité du système.
❖ Le technicien : Un utilisateur qui peut mettre son profil de travail, mettre leur planning
suite de leur disponibilité, de même un technicien peut accepter ou bien refuser une
demande d’un client.
❖ Le Client : c’est la personne qui cherche un technicien spécialisé dans un domaine

particulier suite à cette recherche le client permet d’envoyer une demande au technicien
25 | Page
qui choisit. De même, un client permet de noter un technicien selon leur travail à travers
un « rating » et peut commenter le profil de technicien.
2.4.2 Identification des User Stories

Le « Backlog de produit » ou (Product Backlog) est un élément clé de tout projet. Il contient
la liste des fonctionnalités intervenant dans la construction du système, ainsi que tous les
éléments nécessitant l’intervention de l’équipe projet. Nous avons commencé par lister les
exigences du client dans le tableau 3 qui résume le backlog produit de « Work » où nous
nous focalisons sur les histoires utilisateurs en indiquant leurs priorités.
Tableau 3 : Backlog des Produits
ID Fonctionnalité User Story Acteur Priorité
1 Authentification Entant qu’Administrateur ou Administrateur Elevée

Utilisateur, je veux ,Technicien, Client
m’authentifier afin d’accéder
à mon espace.
2 Gestion des En tant qu’Administrateur, je Administrateur Elevée

comptes veux ajouter des nouveaux
utilisateurs utilisateurs.
3 Gestion des Jobs Administrateur Elevée

- En tant qu’Administrateur
, je veux ajouter un job afin de
l’enregistrer dans la base des
données.
- En tant qu’Administrateur, je
veux consulter la liste des Jobs
ajoutées.
veux modifier un job ajouté.
26 | Page
veux supprimer un job de la
liste affichée.
4 Gestion des - En tant que Technicien Administrateur Elevée

JobProfiles
, je veux ajouter un jobProfiles ,Technicien, Client
afin de l’enregistrer dans la
base des données.
- En tant qu’Administrateur ou
bien Client je veux consulter
la liste des JobProfiles
ajoutées.
bien Technicien, je veux
modifier un jobProfiles ajouté.
supprimer un jobProfiles de la
liste affichée.
5 Gestion des - En tant que Client, je veux Administrateur, Elevée

demandes ajouter une demande associée
Technicien, Client
à un seul technicien que j’ai
choisi afin de l’enregistrer
dans la base des données.
bien Technicien je veux
consulter la liste des demandes
ajoutées.
6 Gestion des Cette fonctionnalité Administrateur, Moyenne

Conversation implémente la conversation
Technicien,
entre plusieurs utilisateurs.
Client
7 Gestion des Un client peut consulter la Administrateur, Moyenne

commentaires liste de JobProfile
Technicien,
Client
27 | Page
Et il peut commenter un
JobProfile spécifique à un
technicien particulier
8 Gestion des - En tant que Technicien Administrateur, Moyenne

Planning
, je veux ajouter un Planning Technicien,
afin de l’enregistrer dans la Client
base des données.
bien Client je veux consulter
la liste des Planning de chaque
JobProfile ajoutées.
modifier un Planning ajouté.
supprimer un Planning de la
liste affichée.
2.5 Planification des releases et des sprints

La méthode « SCRUM » implique que le projet progresse à travers la mise en place de séries
de « Sprint » qui peuvent durer entre deux et quatre semaines et qui peuvent être par la suite
classée sous forme de « Release » constituant une version du système. A chaque « Sprint »,
nous commençons par sélectionner les fonctionnalités du Backlog de produit qui
appartiennent à ce « Sprint ». Le tableau 4 représente la planification des « Release » et des
« Sprint ».
28 | Page
Tableau 4 : Planification des « Release » et des « Sprint »
Release Sprint Objectif du Sprint

Gestion des comptes
Sprint 1 Gestion des Jobs

Release 1 Gestion des JobProfiles
Sprint 2 Gestion des Demandes
Gestion des conversations
Sprint 3
Gestion des commentaires
Release 2
Sprint 4 Gestion des Planning
2.6 Environnements de travail

Dans cette partie, nous présentons l'environnement matériel et technique relatif à la
réalisation de notre solution proposée. La figure 12 présente l’environnement matériel
exploité pour la réalisation de la solution proposée.
Figure 12 : Environnement Matériel
29 | Page
2.6.1 Environnement logiciel
PHPMyAdmin est une application web de gestion pour le système de

gestion de base de données MySQL réalisée principalement en PHP. Il
s'agit de l'une des plus célèbres interfaces pour gérer une base de données
MySQL sur un serveur PHP. De nombreux hébergeurs, gratuits comme
payants, le proposent ce qui évite à l'utilisateur d'avoir à l'installer [4].
RubyMine - est l'IDE Ruby and Rails dédié qui fournit une
assistance intelligente à l'édition de code Ruby et des outils pour le
développement d'applications Web avec Ruby on Rails. Pour en
savoir plus, consultez le site Web officiel. IntelliJ IDEA fournit des
fonctionnalités similaires avec le plugin Ruby installé [5].
Microsoft Visio est un programme qui fait partie de la suite Microsoft

Office mais se vend séparément et qui permet de créer des diagrammes à
l’aide de graphiques vectoriels. On peut aussi créer des diagrammes de
Gantt, des réseaux de PERT ou encore des diagrammes IDEFO [6].
Bootstrap est une collection d’outils utile à la création du design

(graphisme, animation et interactions avec la page dans le navigateur ...
etc. ...) de sites et d’applications web. C'est un ensemble qui contient des
codes HTML et CSS, des formulaires, boutons, outils de navigation et
autres éléments interactifs, ainsi que des extensions JavaScript en option
[7].
MailDev est un moyen simple de tester les e-mails générés par votre
projet pendant le développement avec une interface Web facile à
utiliser qui s'exécute sur votre machine.
Redis-rails fournit un ensemble complet de magasins (Cache, Session,

HTTP Cache) pour Ruby on Rails. Consultez le fichier readme principal
de redis-store pour les instructions générales.
30 | Page
2.6.2 Technologies de développement

« Ruby on Rails », également appelé RoR ou Rails, est un Framework web libre écrit
en Ruby. Il suit le motif de conception Modèle-Vue-Contrôleur (en anglais appelé Model-
View-Controller ou MVC), qui est présenté par la figure 14. Il propose une structure qui
permet de développer rapidement et intuitivement. Cependant, il impose un grand niveau
d'abstraction dans la programmation qui apporte en contrepartie l'économie d'écrire soi-
même la plupart des routines obligatoires d'une application web. La figure numéro 13
représente la technologie utilisée qui est Ruby On Rails [1].
Figure 13 : Logo de la technologie « Ruby On Rails »
La technologie Ruby On Rails est implémentée à travers une architecture logicielle en se

basant sur le modèle conceptuel MVC sachant que cette architecture consiste en :
❖ Les modèles sont les classes assurant la gestion des données. En général la structure de
ces classes est déterminée automatiquement par Rails à partir d'une base de données. Les
relations entre les tables sont explicitement spécifiées (has_many belongs_to). Spécifier
ces relations permet à « ActiveRecord » de précharger des éléments de classes enfants
ou parent.
❖ Les vues correspondent à la manière d'afficher les informations à l'utilisateur. Il s'agit
généralement d'une combinaison de code HTML et de Ruby dans des (fichiers.html.erb).
Il est aussi possible de les programmer en Ruby pur avec Builder. Enfin il existe une
multitude de plugins de systèmes d'écriture de HTML simplifié.
❖ Les contrôleurs réagissent aux actions des utilisateurs, ils vont chercher les données dans
la base et les mettent à disposition des vues.
31 | Page
Figure 14 : L'architecture MVC
2.6.3 Architecture physique

Dans le cadre de la solution à développer, nous avons utilisé une architecture physique de
type trois-tiers ou trois couches qui sont : la couche de présentation, la couche métier et
couche d’accès aux données. La figure numéro 15 représente les technologies qui sont
implémenté pour chaque couche, ainsi que la figure numéro 16 présente l’implantation
physique des différents nœuds.
32 | Page
Figure 15 : Architecture de l’application en couches
33 | Page
Figure 16 : Architecture physique de la solution « Work »
Conclusion
Ce chapitre nous a permis de bien délimiter le périmètre du projet et d'avoir une vision plus
claire sur le sujet. Nous avons décrit la liste des acteurs, la liste des backlog de produit, les
différents « user stories » qui décrit dans le cadre de backlog de produit, puis présenter
l’architecture logicielle et l’architecture physique. Dans le chapitre suivant nous présentons
la réalisation de release numéro 1 qui consiste en deux sprints.
34 | Page
Chapitre 3 : Realise 1
Système de métier et de
recherche des techniciens
Chapitre 3 : Système de métier et de recherche des techniciens
Introduction
Après avoir achevé les préparatifs précédents qui nous ont permis de bien identifier les axes
principaux de notre projet et de bien assimiler la notion de conception visant à obtenir une
solution prête à être exploitée, nous allons entamer la phase de l’implémentation du système.
Nous proposons principalement deux releases. Dans ce chapitre, nous présentons les deux
sprints du premier release. La réalisation de chaque sprint est effectuée sur quatre phases ;
la spécification fonctionnelle, la conception, l’implémentation, et la validation.
3.1 Mise en œuvre du sprint 1 : Système d’utilisateur et des

métiers
3.1.1 Spécification fonctionnelle
À la fin de ce sprint, le super-administrateur peut gérer les comptes, les métiers (jobs), gérer
« JobProfile » et en fin consulter la liste des demandes. Tout technicien peut gérer son
« JobProfile » ainsi qu’il peut consulter la liste des demandes associée à un seul client et
renvoie l’état des demandes quel que soit il est accepté ou il est refusé. Par ailleurs un client
permet d’ajouter une demande associée à un seul technicien, et permet de donner une note
c.-à-d. un avis de chaque technicien.
3.1.1.1 Backlog du sprint 1

Le tableau 5 illustre les récits du premier sprint.
Tableau 5 : Backlog du sprint 1
ID Récits Estimation(/J)
Authentification
ID1 10
Implémentation du module utilisateurs

ID2 14
ID3 Implémentation du module jobs 6
36 | P a g e
3.1.1.2 Spécification des cas d’utilisation du sprint 1

Le diagramme de cas d’utilisation sont des diagrammes UML utilisés pour. Donner une
vision globale du comportement fonctionnel d’un système. Un cas d’utilisation est la
description d'un ensemble de séquences d'actions qu'un système effectue pour produire un
résultat observable à un acteur. Il représente une exigence fonctionnelle de notre système
dans son ensemble. Les diagrammes de cas d'utilisation décrivent ce qu'un système fait du
point de vue d'un observateur externe. L'accent est mis sur ce qu'un système fait, plutôt que
sur la façon dont il le fait. La figure 18 présente le diagramme de cas d’utilisation du premier
sprint.
Figure 17 : Raffinement de cas d'utilisation du « Sprint 1 »
3.1.1.3 Description textuelle des cas de besoins

La description textuelle des cas d’utilisation met en évidence les interactions entre les actions
de l’utilisateur et le système. On a choisi d’expliquer ces scénarios à travers un tableau qui
démontre clairement ce qui est effectué par l’utilisateur et ce qui est du ressort du système.
Les tableaux suivants présentent les patrons textuels des cas d’utilisation les plus importants
du sprint 1.
37 | P a g e
a) Analyse de cas d’utilisation « S’authentifier »
Le tableau numéro 6 décrit le scénario d’exécution du cas d’utilisation authentification.
Tableau 6 : Description de cas d'utilisation « Authentification »
Identification
Titre Authentification
Acteurs SupAdmin - Technicien - Client
Objectif Authentification et autorisation d’accès.
Description des scénarios
Précondition Postcondition
Autorisation d’accès. Accès à l’interface d’accueil
Scénario nominal
1.L’utilisateur demande l’interface d’authentification.

2. Le système affiche l’interface.
3. L’utilisateur fournit les champs nécessaires et valides.
4. Le système vérifie les données d’identification.
5. Le système affiche l’interface d’accueil propre à l’acteur
Enchainement d’exception
4. E-mail ou mot de passe non valide :

- Le système affiche un message d’erreur.
- Retour à l’étape 3 du scénario de base
b) Analyse de cas d’utilisation « Ajouter Job »

Le tableau numéro 7 décrit le scénario d’exécution du cas d’utilisation ajouter job.
Tableau 7 : Description de cas d'utilisation « Ajout Job »
Identification
Titre Ajouter Job
Acteurs SupAdmin
Objectif À tout moment, le SupAdmin doit pouvoir ajouter de nouveaux Jobs.
38 | P a g e
- Opération d’ajout choisie. Job ajoutée.

- l’acteur authentifié.
Scénario nominal
1. « include » s’authentifier.
2. L’acteur introduit les données relatives de jobs.
3. Le SupAdmin valide l’opération.
4. Le système vérifie la saisie.
5. Le système enregistre les données des Jobs.
6. Le système affiche un message de « Succès d’ajout »
4.1. Données non valides :

- Le système affiche un message d’erreur :
« Champ manquant » ou « incohérence ».
- Retour à l’étape 2 du scénario de base.
c) Analyse de cas d’utilisation « Modifier Jobs »

Le tableau numéro 8 décrit le scénario d’exécution du cas d’utilisation modifier job.
Tableau 8 : Description de cas d'utilisation « Modifier Job »
Identification
Titre Modifier Job
Acteurs SupAdmin
Objectif Le SupAdmin a la possibilité de modifier les données des jobs
- Acteur authentifié Job à modifiée.

- Opération de modification
choisie.
Scénario nominal
2. consulter job.
3. Le SupAdmin modifie les données de job sélectionné.
4. Le SupAdmin valide la modification.
5. Le système vérifie la modification.
6. Le système enregistre la modification.
7. Le système affiche un message de « succès ».
5. Modification non valide

- Le système affiche un message d’erreur « champs manquants ou incohérents ».
- Retour à l’étape 3 de scénario de base.
39 | P a g e
d) Analyse de cas d’utilisation « Supprimer Job »

Le tableau numéro 9 décrit le scénario d’exécution du cas d’utilisation supprimer job.
Tableau 9 : Description de cas d'utilisation « Supprimer Job »
Identification
Titre Supprimer job
Acteurs SupAdmin
Objectif Le SupAdmin a la possibilité de supprimer les données d’un job. Pour ce faire, il doit
consulter la liste des jobs et sélectionner celui à supprimer.
- L’Acteur authentifié. Job supprimée.

- Opération de suppression
choisie.
Scénario nominal
2. consulter produit.
3. Le SupAdmin supprime les données de job sélectionnée.
4. Le système demande la confirmation de la suppression.
5. Le SupAdmin valide la suppression.
6. Le système supprime les informations de job de la base de données.
7. Le système affiche un message de « succès de suppression »
5. Le SupAdmin annule la suppression :

e) Analyse de cas d’utilisation « Consulter la liste des Jobs »

Le tableau numéro 10 décrit le scénario d’exécution du cas d’utilisation consulter la
liste des jobs.
Tableau 10 : Description de cas d'utilisation « Consultation Job »
Identification
Titre Consulter la liste des Jobs.
Acteurs SupAdmin
Objectif L’acteur sélectionne un job parmi ceux affichés dans la liste.
40 | P a g e
- Acteur authentifié. Job consultée.

- Opération de consultation
choisie
Scénario nominal
2. L’acteur demande la consultation des jobs.
3. Le système affiche une liste des jobs.
4. L’acteur sélectionne un job à consulter.
5. Le système fournit la fiche technique détaillée
3. La liste des Jobs est vide :

3.1.2 Conception du sprint 1
Le modèle « 4+1 » vues, dit de Kruchten, illustrés par la figure 19, d’un système
informatique permet d’organiser la description du système en plusieurs vues
complémentaires, chacune présentant le système selon un point de vue différent.
L’utilisation de vues permet de traiter séparément les intérêts des divers groupes
d’intervenants (architectes, utilisateurs, développeurs, chefs de projets, etc.) et ainsi de
mieux séparer les préoccupations fonctionnelles (le domaine d’application ou métier ciblé
par le système, par exemple la banque ou le contrôle aérien) et les préoccupations extra
fonctionnelles (les propriétés techniques telles que la sûreté de fonctionnement) [8].
Figure 18 : Vue 4+1 Kruchten

41 | P a g e
La figure schématise le modèle « 4+1 » vues. Ce modèle est composé de cinq vues.
• La vue « logique » décrit les aspects statiques et dynamiques d’un système en termes
de classes, d’objets, de connexions et de communications. Elle se concentre sur
l’abstraction et l’encapsulation.
• La vue « processus » capte les aspects de concurrence et de synchronisation, et les

décompose en flux d’exécution (processus, fil d’exécution, etc.). Elle se rapporte aux
objets actifs et aux interactions. La vue « développement » représente l’organisation
statique des modules (exécutable, codes source, paquetages, etc.) dans
l’environnement de développement.
• La vue « physique » décrit les différentes ressources matérielles et l’implantation

logicielle tenant compte de ces ressources. Donc, elle se rapporte aux nœuds
physiques d’exécution et au placement des objets sur les nœuds.
• La dernière vue, appelée « cas d’utilisation », se concentre sur la cohérence en

présentant des scénarios d’utilisation qui mettent en œuvre les éléments des quatre
premières vues. Les scénarios sont une abstraction des exigences fonctionnelles de
l’application. Cette dernière vue valide en quelque sorte les autres vues et assure la
cohérence globale. C’est aussi cette dernière vue qui est construite en premier, juste
après l’établissement du cahier des charges, pour fixer les contours du système à
réaliser avec ses fonctionnalités appelées, dans la terminologie UML, des cas
d’utilisation.
Nous présentons dans la deuxième activité de ce sprint, la conception, les diagrammes de

séquence, les diagrammes de classe ainsi que les diagrammes d’activité.
3.1.2.1 Diagrammes de séquences du sprint 1
Les diagrammes de séquences permettent de représenter des collaborations entre objets
Selon un point de vue temporel, on y met l'accent sur la chronologie des envois des messages.
En effet, les diagrammes de séquence peuvent être représentés pour décrire le déroulement
des différentes actions entre les acteurs. Dans cette partie, nous allons mettre l’accent sur les
plus importantes fonctionnalités fournies par notre système.
42 | P a g e
a. Diagramme de séquence « Authentification »
La figure numéro 20 représente la phase d’authentification. Chaque utilisateur doit

obligatoirement passer par cette étape pour accéder à son compte.
Il saisit le login et le mot de passe, puis en appuyant sur le bouton « Login », le système
vérifie leur existence, s’ils existent il lui crée une Session et lui donne accès à l’interface
corresponde, sinon il l’affiche un message d’erreur.
Figure 19 : Diagramme de séquence « Authentification »
b. Diagramme de séquence « Ajouter Job »
Le cas d’utilisation Gérer métier (Job) permet au super-administrateur d’ajouter un nouveau

métier. La figure 21 illustre le diagramme de séquence du scénario d’ajouter job.
43 | P a g e
Figure 20 : Diagramme de séquence « Ajout d'un job »
c. Diagramme de séquence « Modifier job »
Le système affiche le formulaire de modification, où l’utilisateur peut modifier les

informations existantes tout en respectant les règles de validités des données saisies. La
figure numéro 22 permet de décrire le scénario du CU Modifier job.
Figure 21 : Diagramme de séquence « Modifier job »
44 | P a g e
d. Diagramme de séquence « Consulter la liste des Jobs »
Le cas d’utilisation lister les Jobs permet au super-administrateur d’avoir une vision globale
sur l’ensemble des Jobs à condition que la liste ne soit pas vide. La figure numéro 23 permet
de décrire le scénario du consulter job.
Figure 22 : Diagramme de séquence « Consultation liste Jobs »
e. Diagramme de séquence « Supprimer Job »
La figure numéro 24 permet de décrire le scénario du CU Supprimer Job.
Figure 23 : Diagramme de Séquence « Suppression d'un Job »
45 | P a g e
3.1.2.2 Diagramme de classes relatif au sprint 1
Pour assurer une vue globale de notre système, nous présentons les classes intervenantes et
les différentes relations entre elles. En adoptant Scrum le diagramme de classe n’apparait
pas totalement détaillé car il sera construit au fur et à mesure durant l’avancement dans les
Sprints par l’intégration des classes intervenant dans la réalisation de chaque Sprint.la figure
numéro 25 représente diagramme de classes du sprint numéro 1.
Figure 24 : Diagramme de Classes du « Sprint 1 »
3.1.2.3 Diagramme d’activité
Un diagramme d’activité numéro 26 permet de spécifier comment le système accomplit les

fonctionnalités demandées. Il montre également les actions à un haut niveau d’abstraction
avec les interactions entre elles. Dans la pratique, les diagrammes d’activité sont bien adaptés
à cette phase de l’analyse qui consiste en l’expression des processus métier comme un
ensemble d’actions coordonnées pour atteindre un but. La figure montre le diagramme
d’authentification.
46 | P a g e
Figure 25 : Diagramme d'activité « Authentification »
3.1.3 Revue du Sprint 1
Le but de la revue est de montrer les résultats de ce sprint en exposant quelques interfaces
Homme-Machine à travers des imprimés écrans. C’est figure numéro 27 représente
l’interface d’accueil pour accéder au service de notre plateforme.
47 | P a g e
Figure 26 : Interface de page d'accueil de la plateforme « Work »
48 | P a g e
La figure numéro 28 représente l’interface de connexion permettant aux utilisateurs

d’accéder à leurs espaces dédiés selon leurs rôles.
Figure 27 : Interface « d'authentification »
La figure 29 présente l’interface d’ajout d’un nouvel utilisateur où l’administrateur doit

remplir toutes les informations personnelles de son collaborateur ainsi que son rôle qui
désigne son poste actuel.
Figure 28 : Interface de la « liste des utilisateurs »
49 | P a g e
De même cette figure numéro 30 montre l’interface d’ajout d’un nouvel job où
l’administrateur doit remplir toutes les informations.
Figure 29 : interface « d'ajout Job »
La figure 31 donne une vue globale sur l’ensemble des métiers ajoutés. Le super-
administrateur peut avoir le choix d’ajouter un nouveau métier, modifier le métier existant
ou le supprimer complétement.
Figure 30 : Interface de la « liste des Jobs »
50 | P a g e
3.2 Mise en œuvre du sprint 2 : recherche technicien et

l’envoie une demande
Ce Sprint a pour objectif, dans un premier lieu, gère le module de JobProfile c.-à-d. un
technicien mettre son profil de travail sur la plateforme, dans un second lieu un client peut
envoyer une ou plusieurs demandes à un technicien particulier.

Tableau 11 : Backlog « Sprint 2 »
ID4 Implémentation du module Jobprofiles 10
ID5 Implémentation du module demandes 8

La figure 32 illustre un diagramme de cas d’utilisation montrant les différentes
fonctionnalités détaillées pour la gestion des jobProfile et des demandes.
51 | P a g e
3.2.1.3 Description textuelle du scénario
Nous expliquons dans ce qui suit les cas d’utilisation d’ajout et la consultation de la liste des
JobProfile en identifiant les acteurs avec les scénarios possibles.
a. Analyse de cas d’utilisation « Ajout un JobProfile »

Le tableaux numéro 12 décrit le scénario d’exécution du cas d’utilisation ajouter un
jobprofile.
52 | P a g e
Tableau 12 : Description de cas d'utilisation « Ajout JobProfile »

Identification
Titre Ajouter JobProfile
Acteurs Technicien, SupAdmin
Objectif À tout moment, l’acteur doit pouvoir ajouter de nouveaux JobProfiles.
- Opération d’ajout choisie. JobProfiles ajoutée.

Scénario nominal
2. L’acteur introduit les données relatives de jobProfiles.
3. L’acteur valide l’opération.
5. Le système enregistre les données des Jobprofiles.

b. Analyse de cas d’utilisation « Consulter JobProfile »

Le tableau numéro 13 décrit le scénario d’exécution du cas d’utilisation consulter la
liste des jobprofiles.
Tableau 13 : Description de cas d'utilisation « Consultation la liste des JobProfiles »
Identification
Titre Consulter la liste des JobProfiles.
Acteurs Technicien, SupAdmin, Client
Objectif L’acteur sélectionne un jobprofile parmi ceux affichés dans la liste.
- Acteur authentifié. JobProfile consultée.
53 | P a g e
- Opération de consultation
choisie
Scénario nominal
2. L’acteur demande la consultation des jobProfiles.
3. Le système affiche une liste des jobProfiles.
4. L’acteur sélectionne un job à consulter.
5. Le système fournit la fiche technique détaillée
3. La liste des jobprofiles est vide :

c. Analyse de cas d’utilisation « Modifier JobProfile »

Le tableau numéro 14 décrit le scénario d’exécution du cas d’utilisation modifier
jobprofile.
Tableau 14 : Description de cas d'utilisation « Modifier JobProfile »
Identification
Titre Modifier JobProfile
Acteurs SupAdmin, Technicien
Objectif L’acteur a la possibilité de modifier les données des JobProfiles.
- Acteur authentifié JobProfiles à modifiée.

- Opération de modification
choisie.
Scénario nominal
2. consulter jobprofile.
3. L’acteur modifie les données de JobProfile sélectionné.
4. L’acteur valide la modification.
5. Le système vérifie la modification.
6. Le système enregistre la modification.
7. Le système affiche un message de « succès ».
5. Modification non valide

- Le système affiche un message d’erreur « champs manquants ou incohérents ».
54 | P a g e
d. Analyse de cas d’utilisation « Supprimer JobProfile »

Le tableau numéro 15 décrit le scénario d’exécution du cas d’utilisation ajouter jobprofile.
Tableau 15 : Description de cas d'utilisation « Supprimer JobProfile »
Identification
Titre Supprimer JobProfile
Objectif Le SupAdmin a la possibilité de supprimer les données d’un jobprofile. Pour ce faire, il
doit consulter la liste des jobprofile et sélectionner celui à supprimer.
- L’Acteur authentifié. JobProfile supprimée.

choisie.
Scénario nominal
2. consulter produit.
3. L’acteur supprime les données de jobProfile sélectionnée.
6. Le système supprime les informations de jobProfile de la base de données.

3.2.2 Conception du Sprint 2

La seconde activité consiste à produire les diagrammes de séquence, d’activité et de classes
afin de présenter les interactions entre l’acteur et les différents composants du système.
55 | P a g e
3.2.2.1 Diagramme de séquence du Sprint 2

a. Diagramme de séquence « Recherche Technicien »
Le cas d’utilisation « rechercher Technicien » permet au Client de trouver le technicien

cherché à partir de leur « JobProfile ». La figure 33 illustre la recherche du technicien qui
s’effectue en saisissant l’une des informations clés du technicien.
Figure 32 : Diagramme de Séquence « Recherche Technicien »
3.2.2.2 Diagramme de Classe du Sprint 2

La figure numéro 34 présente une modélisation statique de notre système, en définissant
l’ensemble des classes ainsi que les relations entre elles afin de dégager les entités qui
modélisent notre application.
56 | P a g e
Figure 33 : Diagramme de classe du « Sprint 2 »
57 | P a g e
3.2.2.3 Diagramme d’activité

La figure 35 présente le diagramme d’activité d’ajout demande au fournisseur de service.
Nous expliquons le déroulement des activités d’ajout, en indiquant le comportement de
chaque objet.
Figure 34 : Diagramme d'activité « Ajout Demande »
3.2.3 Revue du Sprint 2

L’interface présentée par la figure 36 expose le formulaire d’ajout d’un nouvel jobProfile
spécifique à chaque technicien (fournisseur de service).
58 | P a g e
Figure 35 : interface « d’ajout JobProfile »
Cette interface illustrée par la figure 37 offre au fournisseur de service la possibilité de

parcourir leur jobProfile.
Figure 36 : interface de la « liste de JobProfile »
Les interfaces présentant par la figure 38, 39,40, suite à la recherche de technicien à travers
le google maps, et la consultation de profile de fournisseur de service un client peut envoyer
une demande au fournisseur de service, par ailleurs un email envoyé au fournisseur de
service.
59 | P a g e
Figure 37 : interface de « recherche un fournisseur de service »
Figure 38 : interface « d’ajout demande »
60 | P a g e
Figure 39 interface de « notification email »

parcourir leur demande, le fournisseur de service peut accepter ou refuser la demande de
client.
Figure 40 : interface de la « liste des demandes »
61 | P a g e
Conclusion
Dans ce chapitre, nous avons montré les fonctionnalités à exécuter dans la liste des tâches
de sprint et montré la partie conception en détail à travers quelques diagrammes UML
illustratifs.
62 | P a g e
Chapitre 4 : Realise 2
Système d’interaction entre les
intervenants et système de
Planning
Chapitre 4 : Système d’interaction entre les intervenants et le système de planning
Introduction
Ce chapitre traite les trois sprints qui sont le déroulement du « Realse 2 ». À cette fin, nous
commencerons par la spécification fonctionnelle, puis le « back log » de sprint, qui est utilisé
pour identifier les fonctions à implémenter par le système, puis par la conception en générant
des diagrammes UML et des descriptions de texte, et terminerons ce chapitre en affichant
l’écran imprimé. Expliquez le sprint réalisable.
4.1 Mise en œuvre du sprint 3 : Système d’interaction entre les

intervenants
Ce Sprint a pour objectif, dans un premier lieu, gérer une conversation entre les différente
intervenant, suite à la consultation et la recherche d’un profil de technicien un client peut
ajouter un commentaire et une note.
Le tableau 16 illustre les récits du premier sprint.
Tableau 16 : Backlog du « sprint 3 »
Implémentation du module
ID1 conversations 10
Implémentation du module commentaire

ID2 10

fonctionnalités détaillées pour la gestion des conversations et des commentaires.
64 | P a g e

JobProfile pour mettre un commentaire et les avis associées à chaque jobProfile en
identifiant les acteurs avec les scénarios possibles.
a. Analyse de cas d’utilisation « Ajout un Commentaire »
Le tableau numéro 17 décrit le scénario d’exécution du cas d’utilisation ajouter
commentaire.
Tableau 17 : Description de cas d'utilisation « Ajout Commentaire »
Identification
Titre Ajouter Commentaire
Acteurs Client, SupAdmin
Objectif À tout moment, l’acteur doit pouvoir ajouter de nouveau commentaire.
65 | P a g e
- Opération d’ajout choisie. Commentaire ajoutée.

Scénario nominal
2. L’acteur introduit les données relatives de commentaire.
5. Le système enregistre les données des commentaires.

b. Analyse de cas d’utilisation « Supprimer Commentaire »

Le tableau numéro 18 décrit le scénario d’exécution du cas d’utilisation supprimer
commentaire.
Tableau 18 : Description de cas d'utilisation « Supprimer Commentaire »
Identification
Titre Supprimer commentaire
Acteurs SupAdmin,
Objectif Le SupAdmin a la possibilité de supprimer les données d’un commentaire. Pour ce faire,
il doit consulter la liste des jobProfiles et sélectionner celui à supprimer.
- L’Acteur authentifié. Commentaire supprimée.

choisie.
Scénario nominal
2. consulter commentaire.
3. L’acteur supprime les données de commentaire sélectionnée.
6. Le système supprime les informations de commentaire de la base de données.
66 | P a g e

La seconde activité consiste à produire les diagrammes de séquence, d’activité et de classes

afin de présenter les interactions entre l’acteur et les différents composants du système.
a. Diagramme de séquence « Ajouter Commentaire »
La figure numéro 43 permet de décrire le scénario d’ajouter commentaire spécifique à un

technicien.
Figure 42 : Diagramme de séquence « Ajouter Commentaire »
67 | P a g e
b. Diagramme de séquence « Supprimer Commentaire »
Le figure 44 illustre de diagramme de séquence du scénario de supprimer un commentaire.
Figure 43 : Diagramme de séquence « Supprimer Commentaire »
4.1.2.2 Diagramme de classe du sprint 3
Le diagramme de classes est un sous ensemble d'UML qui s'attache à la description statique
d'un modèle de données représentées par des classes d’objets. La figure 45 illustre le
diagramme des classes du sprint 3.
68 | P a g e
4.1.3 Revue du sprint 3
Cette interface illustrée par la figure 46 offre au client la possibilité de parcourir toutes les
conversations.
Figure 45 : interface de la « liste des conversations »
69 | P a g e
Cette interface illustrée par la figure 47 est un point de contact entre le client et le fournisseur
de service afin de fluidifier les échanges entre eux.
Figure 46 : interface d’interaction entre les intervenants
Cette interface illustrée par la figure 48 offre au client d’ajouter un commentaire et noter le
travail de fournisseur de service.
Figure 47 : interface « d’ajout commentaire »
70 | P a g e
4.2 Mise en œuvre du sprint 4 : Planning de la disponibilité de

technicien
Ce Sprint a pour objectif, dans un premier lieu, un technicien mettre son planning de travail
selon leur disponibilité, dans un second lieu, avant d’envoyer une demande a un technicien
qui choisit, un client peut consulter la disponibilité de technicien selon une date précise.
Le tableau 19 illustre les récits du premier sprint
Tableau 19 : Backlog du « sprint 4 »
Implémentation du module Planning de

ID1 la disponibilité de technicien 10

fonctionnalités détaillées pour la gestion des plannings.
71 | P a g e
Figure 48 Raffinement de cas d'utilisation du Sprint 4

plannings pour mettre une demande à chaque jobProfile en identifiant les acteurs avec les
scénarios possibles.
a. Analyse de cas d’utilisation « Ajout un Planning »
Le tableau numéro 20 décrit le scénario d’exécution du cas d’utilisation ajouter planning.
Tableau 20 : Description de cas d'utilisation « Ajout Planning »
Identification
Titre Ajouter planning
Acteurs Technicein, SupAdmin
Objectif À tout moment, l’acteur doit pouvoir ajouter de nouveau planning.
- Opération d’ajout choisie. Planning ajoutée.

72 | P a g e
Scénario nominal
2. L’acteur introduit les données relatives de planning.
5. Le système enregistre les données des plannings.

b. Analyse de cas d’utilisation « Supprimer Commentaire »

Le tableau numéro 21 décrit le scénario d’exécution du cas d’utilisation supprimer
planning.
Tableau 21 : Description de cas d'utilisation « Supprimer Planning »
Identification
Titre Supprimer planning
Objectif L’acteur a la possibilité de supprimer les données d’un planning. Pour ce faire, il doit
consulter la liste des plannings et sélectionner celui à supprimer.
- L’Acteur authentifié. Planning supprimée.

choisie.
Scénario nominal
2. consulter planning.
3. L’acteur supprime les données de planning sélectionnée.
5. L’acteur valide la suppression.
6. Le système supprime les informations de planning de la base de données.
5. L’acteur annule la suppression :

73 | P a g e
La seconde activité consiste à produire les diagrammes de séquence, de classes afin de

présenter les interactions entre l’acteur et les différents composants du système.
a. Diagramme de séquence « Ajouter Planning »
La figure numéro 50 permet de décrire le scénario du ajouter planning spécifique à un

technicien.
Figure 49 : Diagramme de séquence « Ajouter Planning »
b. Diagramme de séquence « Supprimer Planning »
Le figure 51 illustre de diagramme de séquence du scénario de supprimer un planning.
74 | P a g e
Figure 50 : Diagramme de séquence « Supprimer Planning »
4.2.3 Diagramme de classe du sprint 4
Le diagramme de classes est un sous ensemble d'UML qui s'attache à la description statique
d'un modèle de données représentées par des classes d’objets. La figure 52 illustre le
diagramme des classes du sprint 4.
75 | P a g e
4.2.4 Revue du sprint 4

parcourir tous les plannings.
Figure 52 : interface de la « liste des plannings »
Cette interface illustrée par la figure 54 offre au fournisseur d’ajout d’un nouvel planning
selon leur disponibilité.
Figure 53 : interface « d’ajout planning »
Conclusion
A ce stade, nous avons abordé les divers le système d’interaction entre les intervenants et le
système de planning permettant de mieux comprendre les différents concepts manipulés dans
la mise en œuvre du système « Work ».
Nous clôturons ce rapport par une conclusion générale.
76 | P a g e
Conclusion générale et perspectives
Ce rapport représente la synthèse de notre projet de fin d’étude qui consiste au
«développement d'une plateforme web de Craftsmen-Customer Relation Management ».
L’idée de notre projet est de créer une application répons de besoin de client simple et facile
d’utiliser. Nous avons essayé tout au long de ce travail de présenter tout d’abord la société
« Com&Dev », la société qui nous a accueillis, avant de se focaliser à la présentation du
contexte générale du projet dans laquelle nous avons précisé les différents besoins. Cette
dernière présentait une première ébauche à la conception de notre système. Ensuite, nous
avons procédé à une étude conceptuelle détaillée du système à mettre en œuvre. Enfin, nous
avons abordé l’étape de l’implémentation au cours de laquelle nous avons traduit notre
modélisation conceptuelle en une implémentation physique moyennant les différentes
technologies adoptées et présentant quelques interfaces du travail réalisé. Ce projet nous a
donné l’opportunité de nous initier à la vie professionnelle dans un milieu réel pour une
expérience significative dans des nouvelles technologies. Nous avons eu également
l’opportunité d’apprendre, d’approfondir et de mettre en pratique nos connaissances acquises
en termes de recherche, analyse, conception et programmation et enfin d’améliorer la
communication et l’échange de l’information.
En guise de conclusion, il est utile d’accentuer que la réalisation de ce projet ne fut qu’un
essaye et que nous espérons que notre travail ait accompli ses objectifs, mais, comme tout
travail humain, il ne peut prétendre à la perfection. C’est dans cette perspective que nous
signalons que l’application que nous avons développés durant ce stage de fin d’études est
évolutive et peut être portée à des nouvelles extensions. Il est également possible de penser
à développer une application mobile.
77 | P a g e
Bibliographie
[1] « Technologies de développement »
https://fr.wikipedia.org/wiki/Ruby_on_Rails [Accès le 15/04/2021].
[2] « Outils utilisés dans la gestion du projet »
https://blog-gestion-de-projet.com/outils-de-gestion-de-projet-agile/ [Accès le 20/04/2021].
[3] « Environnement logiciel »
http://glossaire.infowebmaster.fr/jquery/ [Accès le 01/05/2021].
https://fr.wikipedia.org/wiki/PhpMyAdmin [Accès le 10/05/2021].
https://fr.wikipedia.org/wiki/IntelliJ_IDEA [Accès le 10/05/2021].
https://fr.wikipedia.org/wiki/Microsoft_Visio [Accès le 10/05/2021].
https://fr.wikipedia.org/wiki/Bootstrap_(framework) [Accès le 10/05/2021].
[8] « Conception du sprint 1 »
http://www-inf.it-sudparis.eu/COURS/CSC4002/EnLigne/Cours/CoursUML/3.4.html
[Accès le 10/05/2021].
78 | P a g e

Rapport EPS VERSION Finale - Abderrahmen

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport EPS VERSION Finale - Abderrahmen

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

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

RAPPORT DE PROJET DE FIN D’ETUDES

Réalisé Par : Zorgati Abderrahmenne

Encadrant Académique : Mr. Malek BEN SALEM

Encadrant Professionnel : Mr. Samy Dghim

Année Universitaire : 2020 - 2021

À ma Mère, « kahloun Sihem »

À mon Père, « Zorgati Lotfi »

A mon cher et unique Frère « Zorgati Thameur »

Nous tenons à exprimer une sincère reconnaissance à monsieur Anwar MANSOURI, le

Nous tenons à exprimer une sincère reconnaissance à notre encadrant professionnel

Nos remerciements vont à toute l’équipe pédagogique et administrative de l’Ecole

Chapitre 1 : Cadre général du projet -------------------------------------------------------------------------- 10

1.1 Présentation de la société d’accueil ------------------------------------------------------------------- 11

1.2 Sujet du projet et problématique ----------------------------------------------------------------------- 12

1.3 Etude de l’existant --------------------------------------------------------------------------------------- 12

1.3.1 Les applications existantes dans le marché ---------------------------------------------------------- 13

1.3.2 Critique de l’existant et la solution à proposer ------------------------------------------------------ 14

1.4 Méthodologie existante pour la gestion de projet --------------------------------------------------- 16

1.5 Méthodologie choisie pour la mise en œuvre du projet -------------------------------------------- 18

1.5.1 Principe de « Agile SCRUM »------------------------------------------------------------------------- 19

1.5.2 Organisation du travail avec « Agile Scrum »------------------------------------------------------- 19

Chapitre 2 : Pilotage de projet avec Agile SCRUM -------------------------------------------------------- 21

2.1 Outils utilisés dans la gestion du projet -------------------------------------------------------------- 22

2.2 Diagramme de Gantt : ----------------------------------------------------------------------------------- 24

2.3 Définition des équipes et des rôles -------------------------------------------------------------------- 25

2.4 Le Backlog de produit ----------------------------------------------------------------------------------- 25

2.4.1 Identification des acteurs ------------------------------------------------------------------------------- 25

2.4.2 Identification des User Stories ------------------------------------------------------------------------- 26

2.5 Planification des releases et des sprints -------------------------------------------------------------- 28

2.6 Environnements de travail ------------------------------------------------------------------------------ 29

2.6.1 Environnement logiciel --------------------------------------------------------------------------------- 30

2.6.2 Technologies de développement ---------------------------------------------------------------------- 31

2.6.3 Architecture physique ----------------------------------------------------------------------------------- 32

Système de métier et de recherche des techniciens --------------------------------------------------------- 35

3.1 Mise en œuvre du sprint 1 : Système d’utilisateur et des métiers -------------------------------- 36

3.1.1 Spécification fonctionnelle ----------------------------------------------------------------------------- 36

3.1.1.1 Backlog du sprint 1 ------------------------------------------------------------------------------------- 36

3.1.1.2 Spécification des cas d’utilisation du sprint 1 ------------------------------------------------------ 37

3.1.1.3 Description textuelle des cas de besoins ------------------------------------------------------------ 37

a) Analyse de cas d’utilisation « S’authentifier » ------------------------------------------------------ 38

b) Analyse de cas d’utilisation « Ajouter Job » -------------------------------------------------------- 38

c) Analyse de cas d’utilisation « Modifier Jobs » ------------------------------------------------------ 39

d) Analyse de cas d’utilisation « Supprimer Job » ----------------------------------------------------- 40

e) Analyse de cas d’utilisation « Consulter la liste des Jobs » --------------------------------------- 40

3.1.2 Conception du sprint 1 ---------------------------------------------------------------------------------- 41

3.1.2.1 Diagrammes de séquences du sprint 1 -------------------------------------------------------------- 42

a. Diagramme de séquence « Authentification »------------------------------------------------------- 43

b. Diagramme de séquence « Ajouter Job » ------------------------------------------------------------ 43

c. Diagramme de séquence « Modifier job » ----------------------------------------------------------- 44

d. Diagramme de séquence « Consulter la liste des Jobs » ------------------------------------------- 45

e. Diagramme de séquence « Supprimer Job » --------------------------------------------------------- 45

3.1.2.2 Diagramme de classes relatif au sprint 1 ------------------------------------------------------------ 46

3.1.2.3 Diagramme d’activité ---------------------------------------------------------------------------------- 46

3.1.3 Revue du Sprint 1 ---------------------------------------------------------------------------------------- 47

3.2.1 Spécification fonctionnelle ----------------------------------------------------------------------------- 51

3.2.1.1 Backlog du sprint 2 ------------------------------------------------------------------------------------- 51

3.2.1.2 Spécification des cas d’utilisation du sprint 2 ------------------------------------------------------ 51

3.2.1.3 Description textuelle du scénario -------------------------------------------------------------------- 52

a. Analyse de cas d’utilisation « Ajout un JobProfile » ----------------------------------------------- 52

b. Analyse de cas d’utilisation « Consulter JobProfile »---------------------------------------------- 53

d. Analyse de cas d’utilisation « Supprimer JobProfile »--------------------------------------------- 55