Le document présente la mise en place d'un système de travail collaboratif au sein de la société Runmyprocess pour améliorer l'efficacité dans le développement de logiciels. Le projet a été réalisé par Slimane Akali dans le cadre de son stage de fin d'études en ingénierie logicielle, et il décrit les méthodologies agiles adoptées, notamment Scrum et XP. Le rapport détaille chaque étape de conception et de réalisation, ainsi que les remerciements aux encadrants et aux collègues.

1. Sujet :
La mise en place d'un système de travail
collaboratif dans l'IDE de la société
RunMyProcess
Filière d’ingénieur :
Ingénierie Logicielle et Intégration des Systèmes Informatiques
Mémoire de Projet Cadre
Année universitaire : 2017 / 2018
Encadrant pédagogique :
Mr. Omar EL BEGGAR
Examinateur :
Mr. Cherkaoui LEGHRIS
Rapporteur :
Mme. DOUZI KHADIJA
Encadrant professionnel :
Mr. Abdelhakim RHANIZARRéalisé par :
Slimane AKALIÂ

2. D´edicaces
`A la m´emoire de mon p`ere Sidi Mohammed l’ˆetre le plus cher au monde. Aucune d´edicace ne
saurait exprimer l’amour, l’estime, le d´evouement que j’ai toujours eu pour vous.
`A ma tr`es ch`ere m`ere Lalla Zahra, affable, honorable, aimable : Tu repr´esentes pour moi le
symbole de la bont´e par excellence, la source de tendresse et l’exemple du d´evouement qui n’a pas
cess´e de m’encourager et de prier pour moi.
`A ma ch`ere sœur Mouna et mon cher fr`ere Hamza, qu’ils trouvent ici l’expression de ma pro-
fonde gratitude et ma reconnaissance infinie.
`A tous mes ami(e)s, en souvenir de tout moment qu’on s’est partag´e.
`A tous ceux qui m’ont donn´e un jour un coup de pousse, de pr`es ou de loin.
Je d´edie ce modeste travail, en signe de ma vive reconnaissance et ma profonde estime.
Slimane AKALI ˆA

3. Remerciements
C’est d’abord grˆace `a Dieu, que je voie ce projet cadre s’achever.
Je tiens `a remercier tout particuli`erement et `a t´emoigner toute ma reconnaissance aux personnes
suivantes, pour l’exp´erience enrichissante et plein d’int´erˆet qu’ils m’ont fait vivre durant ces deux
mois de stage :
`A Mr Omar EL BEGGAR, mon encadrant et mon professeur `a l’FSTM. Je le remercie pour
sa patience, pour le suivi ininterrompue de ce projet, pour ses conseils judicieux qui m’ont aid´e `a
mener `a bout ce travail et son appuie toute au long de ce projet.
`A Mr Abdelhakim RHANIZAR, le fondateur et le directeur g´en´erale de l’entreprise Sanad-
Tech pour son inspiration et son support concernant la mission ´evoqu´ee dans ce rapport, qu’il m’a
apport´e lors des diff´erents suivis.
`A tous mes enseignants de la facult´e des sciences et techniques de Mohammedia qui n’ont jamais
cess´e de m’aider.
`A l’ensemble du personnel de SanadTech pour leur accueil sympathique et leur coop´eration
professionnelle tout au long de ce stage.

4. Table des mati`eres
Introduction g´en´erale 1
1 Pr´esentation g´en´erale du projet 3
1.1 Pr´esentation d’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Pr´esentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Etude pr´eliminaire 7
2.1 Cahier de charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Pourquoi adopter une m´ethode agile ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Pourquoi SCRUM ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Pourquoi SCRUM-XP ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Mod´elisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Etude technique 15
3.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Environnements de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5. TABLE DES MATI`ERES
4 Mise en place du Release 1.0 : Backend du syst`eme 23
4.1 Sprint 1 : Verrouillage d’acc`es `a une ressource (Partie serveur) . . . . . . . . . . . . . 23
4.2 Sprint 2 : Gestion des demandes d’acc`es en modification `a une ressource (Partie serveur) 29
4.3 Sprint 3 : Partage des modifications en temps r´eel (Partie serveur) . . . . . . . . . . . 36
Conclusion g´en´erale 39
A Annexe : Notions et d´efinitions 41
A.1 Transformation digitale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2 Processus m´etier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.3 Business Process Model and Notation – BPMN . . . . . . . . . . . . . . . . . . . . . 41
B Annexe : Le Framework SCRUM 42
B.1 Valeurs de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.2 Les responsabilit´es dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.3 Les livrables dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.4 Les it´erations de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.5 Les manifestations dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C Annexe : Extreme programming XP 46
C.1 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.2 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.3 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Bibliographie 49

6. Table des figures
1.1 Logos de RunMyProcess et de SanadTech . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 L’IDE Digital suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Le diagramme de cas d’utilisation g´en´erale . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Architecture physique du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Architecture logique du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Partie client du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Partie serveur du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Diagramme de d´eploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Diagramme de s´equence syst`eme : ”Premi`ere visite d’un utilisateur” . . . . . . . . . . 25
4.2 Diagramme de paquetage pour le sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Diagramme de classe BO du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Exemple des tests unitaires pour le sprint 1 . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Diagramme de s´equence syst`eme : ”Demande d’acc`es `a une ressource” partie 1 . . . . 31
4.6 Diagramme de s´equence syst`eme : ”Demande d’acc`es `a une ressource” partie 2 . . . . 32
4.7 Diagramme de classe Sprint 2 : Couche BO . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8 Diagramme de classe Sprint 2 : Couche DAO . . . . . . . . . . . . . . . . . . . . . . . 34
4.9 Diagramme de classe Sprint 2 : Couche EventHandlers . . . . . . . . . . . . . . . . . 34

7. TABLE DES FIGURES
4.10 Exemple des tests unitaires pour le sprint 2 . . . . . . . . . . . . . . . . . . . . . . . 35
4.11 Diagramme de s´equence syst`eme : ”Enregistrement effectu´e par un utilisateur principal” 37

8. Liste des tableaux
1.1 Fiche signal´etique de SanadTech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Product backlog partie 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Product backlog partie 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Sprint 1 backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Sprint 1 : Tests fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Sprint 2 backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Sprint 2 : Test fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Sprint 3 backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9. Liste des abr´eviations
NTIC : Nouvelles Technologies d’Information et de Communication
SARL : Soci´et´e `A Responsabilit´e Limit´ee
BPMN : Business Process Model and Notation
API : Application Programming Interface
XP : eXtreme Programming
Pub-Sub : Publish-Subscribe
BO : Business Object
DAO : Data Access Object
RAM : Random Access Memory
HTML : HyperText Markup Language

10. Introduction g´en´erale
L’organisation du travail en mode projet consiste `a mobiliser des comp´etences multiples - parfois
externes `a l’entreprise - travaillant ensemble sur une mˆeme id´ee divis´ee en s´equences, activit´es ou
tˆaches, born´ees dans le temps par un d´ebut et une fin. Ce qui implique un partage d’information
entre les diff´erents services afin de construire une vision partag´ee des objectifs `a atteindre.
D’autre part, le monde industriel se caract´erise souvent par la dispersion g´eographique des ac-
tivit´es, les entreprises sp´ecialis´ees dans la NTIC font partie. Elles externalisent leurs activit´es de
production, mais ´egalement de conception `a des bureaux d’´etudes g´eographiquement proches de leurs
clients, de mani`ere `a adapter le produit aux attentes du consommateur final et de diminuer les coˆuts
de production. Dans ce cadre, le travail collaboratif peut ˆetre consid´er´e comme solution pour diminuer
les coˆuts li´es aux d´eplacements physiques et ainsi r´eduire le temps de mise sur le march´e d’un produit.
C’est dans ce contexte que l’entreprise Fujitsu RunMyProcess a d´el´egu´e la mise en place d’un
syst`eme de travail collaboratif dans son environnement de d´eveloppement Digital suite `a la startup
SanadTech, o`u j’avais la mission de concevoir et r´ealiser une solution informatique qui r´epond `a ce
besoin.
La mise en place de ce syst`eme rentre dans le cadre d’un stage projet qui vient conclure notre
formation de deuxi`eme ann´ee cycle d’ing´enieur d’´etat en informatique `a la facult´e des sciences et
1

11. Introduction g´en´erale
techniques de Mohammedia.
Le pr´esent rapport d´ecrit les ´etapes de conception et de r´ealisation de ce syst`eme en cinq chapitres :
Le premier chapitre ”Pr´esentation g´en´erale du projet” est un chapitre introductif qui donne
une br`eve description de l’organisme d’accueil. Ensuite, nous exposons le cadre g´en´eral du projet et
la solution propos´ee.
Le second chapitre nomm´e ”Etude pr´eliminaire” pr´esente le cahier des charges du projet et
d´ecrit la m´ethodologie adopt´ee pour la mise en place de la solution.
Le troisi`eme chapitre est consacr´e `a une ´etude technique du projet, o`u nous montrons l’architec-
ture physique et logique du syst`eme et l’environnement du travail.
Les deux derniers chapitres sont d´edi´es aux diff´erentes it´erations suivies lors du d´eveloppement
de la solution.
Nous clˆoturons ce rapport par une conclusion g´en´erale dans laquelle nous ´evaluerons les r´esultats
atteints et nous exposerons les ´eventuelles perspectives du pr´esent projet.
2

12. Chapitre 1
Pr´esentation g´en´erale du projet
Introduction
Le premier chapitre pr´esente le contexte g´en´eral du projet. Il se compose de deux parties. La
premi`ere a pour but de pr´esenter l’organisme d’accueil, et la deuxi`eme partie d´ecrit la probl´ematique
et la solution propos´ee.
1.1 Pr´esentation d’organisme d’accueil
SanadTech est une soci´et´e `a responsabilit´e limit´ee sp´ecialis´ee dans la conception et la r´ealisation
des solutions Cloud, Web et mobile. Depuis 2013, SanadTech travaille en partenariat exclusif avec
la soci´et´e fran¸caise Fujitsu RunMyProcess.
Figure 1.1 – Logos de RunMyProcess et de SanadTech
En effet, RunMyProcess propose aux entreprises une plate-forme de d´eveloppement permettant
de mettre en œuvre rapidement et sans code des applications m´etiers en se basant sur des mod`eles
3

13. Chapitre 1. Pr´esentation g´en´erale du projet
BPMN [1].
Le tableau 1.1 pr´esente la fiche signal´etique de SanadTech en exposant l’ensemble de ses infor-
mations cl´es.
Raison sociale SANADTECH
Forme juridique SARL
Adresse 34 Avenue Oqba Ibn Naafi, 5 `eme ´etage, APT 15, Agdal, Rabat, 10000, Maroc
Activit´e Mat´eriels, Logiciels et Services informatiques
Directeur g´en´eral ABDELHAKIM RHANIZAR
Ann´ee de cr´eation 2013
Site web www.sanadtech.com
Tableau 1.1 – Fiche signal´etique de SanadTech
1.2 Pr´esentation du projet
1.2.1 Probl´ematique
Etude de l’existant
Afin de faciliter la cr´eation des applications web m´etiers d´eploy´ees en cloud, RunMyrocess
propose Digital suite un environnement de d´eveloppement en ligne permettant de :
— Construire des diagrammes BPMN.
— Cr´eer des applications web connect´ees `a des APIs cloud (Office 365, Google Apps, Salesforce
management system ...) avec le principe drag & drop (Glisser-d´eposer).
— Convertir des diagrammes BPMN `a des interfaces web.
4

14. Chapitre 1. Pr´esentation g´en´erale du projet
Pour utiliser cet environnement, une entreprise doit payer un abonnement mensuel ou annuel. De
plus, l’acc`es `a la plateforme se fait en tant que utilisateur ou administrateur.
La figure 1.2 pr´esente l’interface de cet IDE.
Figure 1.2 – L’IDE Digital suite
Critique de l’existant
L’environnement de d´eveloppement propos´e par RunMyProcess pr´esente un ensemble de probl`emes
concernant le d´eveloppement collaboratif dans le mˆeme projet :
— Absence d’un syst`eme de communication entre les d´eveloppeurs.
— Risque de perte d’int´egrit´e d’informations en cas de conflit de sauvegarde entre plusieurs
d´eveloppeurs.
— Manque de partage de modifications en temps r´eel entre les d´eveloppeurs.
5

15. Chapitre 1. Pr´esentation g´en´erale du projet
1.2.2 Solution propos´ee
En se concentrant sur ce th`eme et pour rem´edier aux probl`emes pr´ec´edemment cit´es, SanadTech
m’a confi´e la mission de concevoir et de r´ealiser un syst`eme de communication complet qui sera int´egr´e
dans l’IDE de RunMyProcess.
Ce syst`eme est divis´e en 4 modules :
1. Verrouillage d’acc`es `a une ressource.
2. Gestion des demandes d’acc`es en modification `a une ressource.
3. Partage des modifications en temps r´eel.
4. Communication entre les utilisateurs de la mˆeme ressource (texte).
De plus, Notre syst`eme sera con¸cu de telle fa¸con `a s’adapter aux diff´erentes parties de l’IDE
(Cr´eation des diagrammes BPMN, Cr´eation des interfaces web, Gestion des utilisateurs par les ad-
ministrateurs ...).
Conclusion
Dans ce chapitre, nous avons pr´esent´e l’organisme d’accueil et ses principales activit´es. Par ailleurs,
nous avons pu d´egager le contexte g´en´eral du projet, cerner la probl´ematique et proposer une solution
ad´equate.
Le chapitre suivant sera consacr´e `a une ´etude pr´eliminaire d´etaill´ee.
6

16. Chapitre 2
Etude pr´eliminaire
Introduction
Apr`es la d´efinition du contexte g´en´eral de notre projet, l’objectif de ce chapitre est d’analyser ses
objectifs pour adapter la solution au besoin.
Il sera question de pr´esenter le cahier de charges du projet en pr´ecisant les diff´erentes r`egles de
gestion fonctionnelles et non fonctionnelles, ainsi que la m´ethodologie de d´eveloppement choisie en
justifiant ce choix.
2.1 Cahier de charges
2.1.1 R`egles de gestion fonctionnelles
1. Pour un projet donn´e et une ressource donn´ee, il faut donner l’acc`es total au premier utilisateur
qui rentre.
2. Les utilisateurs autre que le premier utilisateur, ne doivent avoir aucun droit de modification
sur la ressource.
3. Si le premier utilisateur enregistre ses modifications, alors les autres utilisateurs doivent rece-
voir les nouvelles modifications en temps r´eel sans actualiser la page.
7

17. Chapitre 2. Etude pr´eliminaire
4. Apr`es que le premier utilisateur quitte la page de la ressource, les droits de modification sont
automatiquement donn´es `a l’utilisateur suivant selon l’ordre de visite.
5. `A chaque moment, n’importe quel utilisateur peut demander les droits d’acc`es `a une ressource.
6. Le premier utilisateur peut accepter ou rejeter une demande d’acc`es.
7. En cas d’acceptation, les droits de modification sont affect´es au demandeur et le premier
utilisateur n’aura plus de droits sur la ressource en question.
8. En cas de rejet, le demandeur doit recevoir un message.
9. Si le premier utilisateur n’a pas r´epondu `a une demande d’acc`es pour 5 minutes, alors, les droits
de modification doivent ˆetre automatiquement donn´es `a l’utilisateur suivant selon l’ordre de
visite.
10. Les utilisateurs connect´es `a une ressource doivent avoir la possibilit´e de communication par
texte.
2.1.2 R`egles de gestion non fonctionnelles
Pour compl´eter les r`egles de gestion fonctionnelles, notre projet devra respecter un ensemble de
propri´et´es contribuant `a une meilleure qualit´e de la solution obtenue. Parmi ces crit`eres on retrouve :
1. La fiabilit´e : la capacit´e du notre syst`eme de rendre des r´esultats corrects mˆeme en ´etant
handicap´e par la panne d’un composant (logiciel ou mat´eriel).
2. La facilit´e d’utilisation : la capacit´e du syst`eme d’ˆetre manipul´e avec le minimum d’effort.
3. L’´evolutivit´e : la capacit´e du syst`eme `a maintenir ses fonctionnalit´es et ses performances en
cas de forte demande.
2.2 Pourquoi adopter une m´ethode agile ?
Le choix d’une m´ethode de d´eveloppement constitue une ´etape tr`es importante permettant d’avoir
une meilleure organisation des diff´erentes phases du projet.
8

18. Chapitre 2. Etude pr´eliminaire
Selon les approches traditionnelles, tout est planifi´e avant le d´ebut du projet. Une fois le cahier
des charges est cr´e´e et le contrat est sign´e, l’entreprise a la responsabilit´e de livrer ce qui est pr´evu.
Le probl`eme, c’est que cette approche ne laisse aucune place aux impr´evus. Mˆeme si les conditions
du march´e changent ou les besoins du client ´evoluent, l’entreprise doit suivre ce qui est stipul´e au
contrat.
`A l’oppos´e des approches traditionnelles, la gestion de projets Agile propose au client de v´erifier
au fur et `a mesure que le projet ´evolue dans la bonne direction tout en tol´erant le changement des
besoins.
2.3 Pourquoi SCRUM ?
Le choix de la m´ethode SCRUM est justifi´e par les raisons ci-dessus :
2.3.1 Simplicit´e et l´eg`eret´e
L’un des points forts de SCRUM c’est sa simplicit´e. En effet, le guide officiel de SCRUM ne fait
que 19 pages. Par ailleurs, SCRUM comporte peu de rˆoles et il est tr`es facile `a comprendre.
2.3.2 Outil de suivis performants
SCRUM pr´esente des outils performants pour suivre l’avancement du travail :
— Product backlog
— Sprint backlog
— Daily meeting
— Sprint review
2.3.3 Transparence
Un principe fort des m´ethodes agiles est la participation active du client. SCRUM garantit cette
participation avec les pratiques suivantes :
9

19. Chapitre 2. Etude pr´eliminaire
— Un rˆole d´edi´e pour repr´esenter la voie du client (Product owner)
— Une r´eunion avec le Product owner apr`es chaque it´eration (Sprint review)
— Une d´efinition de fonctionnalit´es `a r´ealiser avant chaque it´eration (Sprint backlog)
2.4 Pourquoi SCRUM-XP ?
Bien que le Framework SCRUM est orient´e organisation, il manque de pratiques techniques qui
nous permettraient de rendre possible un d´eveloppement agile soutenable [?].
Alors c’est d’ici d’o`u vient l’id´ee d’adopter une m´ethode hybride SCRUM-XP pour combiner les
deux aspects : technique et organisationnel.
2.5 Product backlog
Le Product backlog correspond `a une liste prioris´ee des besoins et des exigences du client. Les
´el´ements du Backlog de produit, appel´e aussi les histoires utilisateurs, sont formul´es en une ou deux
phrases d´ecrivant de mani`ere claire et pr´ecises la fonctionnalit´e d´esir´ee par le client, g´en´eralement,
´ecrit sous la forme suivante En tant que X, je veux Y, afin de Z [3].
Le Product backlog de notre projet est pr´esent´e dans les tableaux 2.1 et 2.2.
ID User story Feature Priorit´e
1 En tant que utilisateur principal, je veux ˆetre
le seul qui peut modifier ma ressource.
Verrouillage d’acc`es `a une res-
source
Must
2 En tant que utilisateur secondaire, je veux
demander l’acc`es en modification `a une res-
source.
Gestion des demandes d’acc`es en
modification `a une ressource
Should
Tableau 2.1 – Product backlog partie 1
10

20. Chapitre 2. Etude pr´eliminaire
ID User story Feature Priorit´e
3 En tant que utilisateur principal, je veux
avoir la possibilit´e d’accepter ou de rejeter
les demandes d’acc`es en modification `a ma
ressource.
Gestion des demandes d’acc`es en
modification `a une ressource
Should
4 En tant que utilisateur principal, je veux par-
tager mes modifications avec les utilisateurs
secondaires.
Partage des modifications en
temps r´eel.
Should
5 En tant que utilisateur, je veux communiquer
par texte avec les autres utilisateurs qui tra-
vaillent sur le mˆeme projet
Communication entre les utilisa-
teurs de la mˆeme ressource
Could
6 En tant que utilisateur secondaire, je veux
savoir les derni`eres modifications effectu´ees
sur une ressource par l’utilisateur principal
en temps r´eel sans actualiser ma page.
Partage des modifications en
temps r´eel.
Should
7 En tant que abonn´e avec RunMyProcess,
je veux que mes d´eveloppeurs puissent tra-
vailler sur le mˆeme projet simultan´ement
sans que la page web soit lente.
Performance Must
8 En tant que abonn´e avec RunMyProcess, je
veux une int´egrit´e d’information dans mes
projets.
Gestion d’acc`es concurrent Must
9 En tant que abonn´e avec RunMyProcess,
je veux une gestion automatique des droits
d’acc`es en modification.
Passage automatique des droits. Must
Tableau 2.2 – Product backlog partie 2
11

21. Chapitre 2. Etude pr´eliminaire
2.6 Planification des sprints
Les ”User stories” pr´ec´edemment d´efinies dans le product backlog sont tri´es par ordre de priorit´e.
Le but ´etant d’impl´ementer en premier ce qui a le plus de valeur. Le travail sera planifi´e selon des
sprints que nous avons d´efinis et chacun dure une `a deux semaines. Apr`es une r´eunion avec l’´equipe,
nous avons identifi´e deux releases et 8 sprints. Le tableau 2.3 montre la planification de nos sprints.
Release Sprint Nom du sprint P´eriode
Release 1.0
Sprint 0 Etude pr´eliminaire 23/4/2018 - 20/5/2018
Sprint 1 Partie serveur : Verrouillage d’acc`es `a une res-
source
21/5/2018 - 2/6/2018
Sprint 2 Partie serveur : Gestion des demandes d’acc`es
en modification `a une ressource
4/6/2018 - 16/6/2018
Sprint 3 Partie serveur : Partage des modifications en
temps r´eel
18/6/2018 - 23/6/2018
Sprint 4 Partie serveur : Communication texte entre les
utilisateurs de la mˆeme ressource
25/6/2018 - 30/6/2018
Release 2.0
Sprint 5 Partie client : Verrouillage d’acc`es `a une res-
source
2/7/2018 - 7/7/2018
Sprint 6 Partie client : Gestion des demandes d’acc`es en
modification `a une ressource
9/7/2018 - 14/7/2018
Sprint 7 Partie client : Partage des modifications en
temps r´eel
16/7/2018 - 21/7/2018
Sprint 8 Partie client : Communication texte entre les uti-
lisateurs de la mˆeme ressource
22/7/2018 - 28/7/2018
Tableau 2.3 – Planification des sprints
12

22. Chapitre 2. Etude pr´eliminaire
2.7 Mod´elisation des besoins fonctionnels
2.7.1 Diagramme de cas d’utilisation g´en´erale
Un diagramme de cas d’utilisation mod´elise les interactions fonctionnelles entre les acteurs et le
syst`eme. Il d´ecrit un ensemble d’actions qui produisent un r´esultat observable [4].
Notions et d´efinitions
— Ressource : tout ´el´ement qui peut ˆetre manipul´e par des utilisateurs de l’IDE (un mod`ele,
une page web, un tableau de bord . . .)
— Utilisateur connect´e : un utilisateur qui utilise une ressource soit en mode lecture ou en
mode ´ecriture.
— Utilisateur principale : le seul utilisateur qui a le droit d’utiliser une ressource en mode
´ecriture.
— Utilisateur secondaire : un utilisateur qui a seulement l’acc`es en lecture `a une ressource.
Diagramme de cas d’utilisation
La figure 2.1 montre le diagramme de cas d’utilisation g´en´erale du projet.
13

23. Chapitre 2. Etude pr´eliminaire
Figure 2.1 – Le diagramme de cas d’utilisation g´en´erale
Conclusion
Ce chapitre a fait l’objet d’une pr´esentation du cahier de charges du projet, une description de la
m´ethodologie adopt´ee dans la r´ealisation de solution et la justification de ce choix.
`A partir des user stories, nous avons pu extraire les diff´erentes it´erations (Sprints) de notre
syst`eme, ainsi qu’une planification par incr´ement tout en respectant les exigences du client par
priorit´e.
Le chapitre suivant pr´esentera une ´etude technique avant d’entamer la phase de r´ealisation.
14

24. Chapitre 3
Etude technique
Introduction
Nous consacrons ce chapitre `a l’´etude technique du projet et la mise en place de l’environnement
de d´eveloppement, l’architecture physique et logique de la solution ainsi que nos choix technologiques
vont ˆetre expliqu´es par la suite.
3.1 Architecture physique
L’architecture physique que nous avons adopt´e pour la r´ealisation de notre solution est de type
multi-tiers. Nous y trouvons :
— Un client l´eger : qui n’est autre qu’un navigateur web permettant `a son utilisateur de
b´en´eficier de notre syst`eme en utilisant Digital Suite via internet.
— Load balancer : Un load balancer a pour tˆache de r´epartir la charge de travail entre plusieurs
serveurs [5].
— Serveur websocket : le serveur d’application qui h´eberge toutes les couches du syst`eme `a
d´evelopper.
— Serveur PubSub : Un serveur de stockage et de transmission de donn´ees qui utilise le
m´ecanisme Publish-subscribe. Publish-subscribe est un m´ecanisme de publication de
15

25. Chapitre 3. Etude technique
messages et d’abonnement `a ces derniers dans lequel les diffuseurs (publishers) ne destinent
pas a priori les messages `a des destinataires (subscribers). `A la place, une cat´egorie est associ´ee
aux messages ´emis sans savoir s’il y a des destinataires. De la mˆeme mani`ere, les destinataires
s’abonnent aux cat´egories les int´eressant et ne re¸coivent que les messages correspondant, sans
savoir s’il y a des diffuseurs [6].
La Figure 3.1 repr´esente l’architecture physique du syst`eme.
Figure 3.1 – Architecture physique du syst`eme
3.1.1 Pourquoi adopter une architecture multi-tiers ?
1. Une forte augmentation du niveau de la fiabilit´e : plusieurs serveurs donc une limitation
de l’arrˆet total du service.
2. Une s´eparation de logique applicative de la pr´esentation : facilit´e de maintenance
´evolutive ou corrective.
3. Assurer une ´evolutivit´e du syst`eme : Si nous voulons b´en´eficier du syst`eme par d’autre
types de clients (application mobile par exemple), il suffit d’impl´ementer le cˆot´e client et
consommer nos services d´ej`a d´evelopp´es.
16

26. Chapitre 3. Etude technique
3.1.2 Pourquoi utiliser un serveur pub-sub ?
L’utilisation d’un serveur pub-sub permet d’´eviter la redondance et l’incoh´erence des donn´ees
entre diff´erents serveurs. La modification d’une donn´ee dans un serveur (Publisher) est diffus´ee au-
tomatiquement aux autres serveurs (Subscribers).
3.2 Architecture logique
La d´efinition de l’architecture de l’application constitue une ´etape importante dans le processus
de conception. Elle d´epend d’un certain nombre de facteurs `a savoir les exigences en mati`ere de
performance et les perspectives d’´evolutivit´e et d’extensibilit´e.
La Figure 3.2 illustre une repr´esentation de l’architecture logique de l’application.
Figure 3.2 – Architecture logique du syst`eme
Cette architecture favorise une s´eparation claire des responsabilit´es :
3.2.1 Couche pr´esentation (Client) :
La couche client assure la logique de navigation. Elle se compose de deux parties :
17

27. Chapitre 3. Etude technique
Higher-order components : le plugin client `a ajouter dans Digital suite.
Tests : la partie consacr´ee aux testes unitaires et d’int´egration.
Figure 3.3 – Partie client du syst`eme
3.2.2 Serveur WebSocket
Couche contrˆoleur (EventHandlers) : Permet de g´erer les ´ev´enements des websockets pour
faire des mises a jour au niveau du mod`ele ou de la vue.
Couche mod`ele (BO et DAO) : Cette couche contient la logique en rapport avec les donn´ees :
validation, lecture et enregistrement.
Tests : La partie consacr´ee aux tests unitaires et d’int´egration.
18

28. Chapitre 3. Etude technique
Figure 3.4 – Partie serveur du syst`eme
3.2.3 Diagramme de d´eploiement
Les diagrammes de d´eploiement sont utilis´es pour d´ecrire l’architecture physique d’un syst`eme.
Ils montrent la distribution des composants logiciels sur la base d’unit´e d’ex´ecution [7].
La figure 3.5 pr´esente le diagramme de d´eploiement de notre syst`eme.
Figure 3.5 – Diagramme de d´eploiement
19

29. Chapitre 3. Etude technique
3.3 Environnements de travail
Dans cette partie, nous pr´esenterons l’environnement mat´eriel et technique relatif `a la r´ealisation
du projet.
3.3.1 Environnement mat´eriel
Durant la r´ealisation du pr´esent travail, on dispose d’un ordinateur DELL embarquant un syst`eme
d’exploitation Windows 10 et ayant les caract´eristiques suivantes :
— Processeur : Intel Celeron
— Fr´equence processeur : 1.60 GHz
— M´emoire RAM : 6GB
— Syst`eme : 64 bits
3.3.2 Environnement technique
Dans cette partie, nous allons pr´esenter les diff´erents outils et langages de programmation que
nous avons utilis´e pour la mise en place de notre syst`eme.
React
Une biblioth`eque JavaScript libre d´evelopp´ee par Facebook depuis 2013. Le but principal de cette
biblioth`eque est de faciliter la cr´eation d’application web, via la cr´eation de composants d´ependant
d’un ´etat et g´en´erant une page (ou portion) HTML `a chaque changement d’´etat [8].
Redux
Une biblioth`eque JavaScript pour bien organiser le d´eveloppement des applications web, elle est
utilis´ee souvent avec react ou angular [9].
20

30. Chapitre 3. Etude technique
Jest
C’est la solution propos´ee par Facebook pour tester les applications React [10].
Nginx
Un serveur web d’application divis´e en plusieurs modules (le load balancing est parmi ces modules)
[11, 12].
Node js
Une plateforme logicielle libre et ´ev´enementielle en JavaScript orient´ee vers les applications r´eseau
qui doivent pouvoir monter en charge. Concr`etement, Node.js est un environnement permettant
l’ex´ecution de JavaScript cˆot´e serveur [13].
Socket.io
Une biblioth`eque JavaScript pour les applications Web real-time. Il permet une communication
bidirectionnelle en temps r´eel entre les clients Web et les serveurs [14].
Mocha
Un framework de test JavaScript riche en fonctionnalit´es fonctionnant sur Node.js, rendant les
tests asynchrones simples. Les tests mocha s’ex´ecutent en s´erie, ce qui permet des rapports flexibles
et pr´ecis [15].
Chai
Une biblioth`eque d’assertion qui peut ˆetre associ´ee `a n’importe quel framework de test javascript
[16].
21

31. Chapitre 3. Etude technique
Redis
Un syst`eme de gestion de base de donn´ees cl´e-valeur performant, ´ecrit en C ANSI et distribu´e
sous licence BSD. Il fait partie de la mouvance NoSQL et vise `a fournir les performances les plus
´elev´ees possibles [17].
Conclusion
Au cours de ce chapitre nous avons pr´esent´e l’architecture logique et physique de notre applica-
tion, ainsi que l’environnement de travail.
Dans le chapitre suivant, nous allons pr´esenter les it´erations suivies lors de la r´ealisation de la
premi`ere release du syst`eme.
22

32. Chapitre 4
Mise en place du Release 1.0 : Backend du syst`eme
Introduction
Ce chapitre fait l’objet d’une pr´esentation des diff´erentes it´erations suivies afin de mettre en place
la premi`ere release de notre syst`eme concernant la partie backend.
4.1 Sprint 1 : Verrouillage d’acc`es `a une ressource (Partie
serveur)
Ce sprint a pour but de d´evelopper la premi`ere partie de la premi`ere release qui est le verrouillage
d’acc`es `a une ressource cˆot´e serveur.
4.1.1 Backlog du sprint 1
Le Backlog du sprint pr´esent´e dans le tableau 4.1 contient une liste des tˆaches qui devront ˆetre
r´ealis´ees avant la fin de sprint.
23

33. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
ID User story ID Tˆache Tˆache
1
1.1 ´Elaborer un diagramme de s´equence
1.2 ´Elaborer un diagramme de classe
1.3 Pr´eparer les tests BO
1.4 Coder la couche BO
1.5 Tests unitaires de la couche BO
1.6 Pr´eparer les tests DAO
1.7 Coder la couche DAO
1.8 Tests unitaires de la couche DAO
1.9 Tests d’int´egration de DAO avec BO
1.10 Pr´eparer les tests pour le m´ecanisme Pub-Sub
1.11 Coder le m´ecanisme Pub-Sub dans le DAO
1.12 Tester le m´ecanisme Pub-Sub avec le DAO et BO
1.13 Pr´eparer les tests pour la couche EventHandlers
1.14 Coder la couche EventHandlers
1.15 Test unitaires de la couche EventHandlers
1.16 Test fonctionnels
Tableau 4.1 – Sprint 1 backlog
4.1.2 Analyse
Le diagramme de s´equence permet de montrer les interactions d’objets dans le cadre d’un sc´enario
d’un diagramme des cas d’utilisation. Le but ´etant de d´ecrire comment se d´eroulent les actions entre
les acteurs ou les objets [18].
24

34. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
Diagrammes de s´equence
Sc´enario 1 : Premi`ere visite d’un utilisateur
Figure 4.1 – Diagramme de s´equence syst`eme : ”Premi`ere visite d’un utilisateur”
25

35. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
4.1.3 Conception
Diagramme de paquetage
Le diagramme de paquetage est la repr´esentation graphique des relations existant entre les pa-
quetages (ou espaces de nommage) composant un syst`eme [19].
La figure 4.2 montre le diagramme de paquetage correspond `a ce sprint.
Figure 4.2 – Diagramme de paquetage pour le sprint 1
La partie serveur se compose de 3 parties :
— EventHandlers : qui se charge de traiter les ´ev´enements websocket.
— BO (business objects) : qui pr´esente la logique m´etier.
— DAO (data access object) : qui permet de manipuler les donn´ees `a partir du Redis.
26

36. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
Diagrammes de classes
Diagramme de classes BO :
Le diagramme de classes est utilis´e pour pr´esenter les classes et les interfaces des syst`emes ainsi
que les diff´erentes relations entre celles-ci [20].
La figure 4.3 montre le diagramme de classe de la couche m´etier du syst`eme.
Figure 4.3 – Diagramme de classe BO du sprint 1
4.1.4 Test et validation
Le test d’un produit logiciel est un processus consistant qui vise `a garantir le bon fonctionnement
du syst`eme `a travers une comparaison des comportements attendu et des r´esultats obtenus. `A la fin
de chaque tˆache nous avons cod´e des tests r´eutilisables avec Mocha et Chai.
27

37. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
Tests unitaires
Un test unitaire est une proc´edure permettant de v´erifier le bon fonctionnement d’une partie
pr´ecise d’un syst`eme. La figure 4.4 montre un exemple des tests unitaires pour le MegaHandler. Pour
relancer tous les tests unitaires il suffit d’ex´ecuter la commande npm test.
Figure 4.4 – Exemple des tests unitaires pour le sprint 1
Tests fonctionnels
Les tests fonctionnels v´erifient que le comportement d’un syst`eme ”en boite blanche” est conforme
`a ses sp´ecifications. En se basant sur les diagrammes de s´equence de sprint, nous avons ´elabor´e un
tableau montrant tous les sc´enarios possibles d’utilisation et le comportement attendu du syst`eme.
Le tableau 4.2 montre en d´etail les tests fonctionnels du premier sprint.
28

38. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
Cas de test Comportement attendu R´esultat
Premier chargement d’une ressource libre Attribution des droits de modification
au visiteur
Conforme
Chargement d’une ressource verrouill´ee Envoi de signal BUSY RESOURCE
au demandeur
Conforme
D´econnexion d’un utilisateur principal et
confirmation imm´ediate de l’utilisateur sui-
vant
Attribution des droits de modification
au deuxi`eme utilisateur par ordre de vi-
site
Conforme
D´econnexion d’un utilisateur principal, ab-
sence de confirmation de l’utilisateur suivant
et confirmation de troisi`eme utilisateur
Attribution des droits de modification
`a l’utilisateur qui confirme
Conforme
D´econnexion d’un utilisateur secondaire Garder le mˆeme verrouillage de la res-
source
Conforme
Tableau 4.2 – Sprint 1 : Tests fonctionnels
4.2 Sprint 2 : Gestion des demandes d’acc`es en modification
`a une ressource (Partie serveur)
Ce sprint a pour but de d´evelopper la deuxi`eme partie de la premi`ere release qui est la gestion
des demandes d’acc`es en modification `a une ressource, ces demandes sont ´emises par les utilisateurs
secondaires et re¸cues par un utilisateur principal.
4.2.1 Backlog du sprint 2
Le Backlog du sprint pr´esent´e dans le tableau 4.3 contient une liste des tˆaches qui devront ˆetre
r´ealis´ees avant la fin de sprint.
29

39. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
ID User stories ID Tˆache Tˆache
2, 3
2.1 ´Elaborer un diagramme de s´equence syst`eme
2.2 Discuter le diagramme de s´equence avec le product owner
2.3 Ajuster le diagramme de classe
2.4 Pr´eparer les tests BO
2.5 Coder la couche BO
2.6 Tests unitaires de la couche BO
2.7 Pr´eparer les tests DAO
2.8 Coder la couche DAO
2.9 Tests unitaires de la couche DAO
2.10 Tests d’int´egration de DAO avec BO
2.11 Pr´eparer les tests pour la couche EventHandlers
2.12 Coder la couche EventHandlers
2.13 Test unitaires de la couche EventHandlers
2.14 Test fonctionnels
Tableau 4.3 – Sprint 2 backlog
4.2.2 Analyse
Diagrammes de s´equence
Les figures 4.5 et 4.6 montrent le diagramme de s´equence syst`eme pour le sc´enario d’une demande
d’acc`es en modification d’un utilisateur secondaire.
30

40. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
Sc´enario : Demande d’acc`es en modification `a une ressource
Figure 4.5 – Diagramme de s´equence syst`eme : ”Demande d’acc`es `a une ressource” partie 1
31

41. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
Figure 4.6 – Diagramme de s´equence syst`eme : ”Demande d’acc`es `a une ressource” partie 2
32

42. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
4.2.3 Conception
Modifications du diagramme de classes
Pour r´epondre aux besoins de ce sprint, nous avons ajout´e des classes dans chaque paquetage. La
figure 4.7 montre les modifications effectu´ees sous la couche m´etier. Nous avons ajout´e une nouvelle
classe ModificationRequest qui repr´esente une demande d’acc`es en modification `a une ressource.
Figure 4.7 – Diagramme de classe Sprint 2 : Couche BO
La figure 4.8 montre les modifications effectu´ees sous la couche d’acc`es aux donn´ees. La classe
ModificationRequest doˆıt ˆetre persist´ee sous Redis, ce qui justifie l’ajout d’un nouvel DAO
(ModificationRequestDAO).
33

43. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
Figure 4.8 – Diagramme de classe Sprint 2 : Couche DAO
La figure 4.9 montre les modifications effectu´ees sous la couche EventHandlers. Nous utiliserons
la classe ModificationRequestEventHandler pour traiter les demandes envoy´ees par une web-
socket.
Figure 4.9 – Diagramme de classe Sprint 2 : Couche EventHandlers
34

44. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
4.2.4 Test et validation
Tests unitaires
La figure 4.10 montre un exemple des tests unitaires pour le ModificationRequestDAO. Pour
relancer tous les tests unitaires il suffit d’ex´ecuter la commande npm test.
Figure 4.10 – Exemple des tests unitaires pour le sprint 2
Tests fonctionnels
Le tableau 4.4 montre en d´etail les tests fonctionnels du deuxi`eme sprint.
Cas de test Comportement attendu R´esultat
L’utilisateur principal accepte
imm´ediatement la demande d’acc`es en-
voy´ee par un utilisateur secondaire
Le demandeur a tous les droits de mo-
dification et l’utilisateur principal de-
vient secondaire
Conforme
L’utilisateur principal n’a pas accus´e la
r´eception de la demande d’un utilisateur se-
condaire
Le demandeur sera le nouvel utilisateur
principal et l’utilisateur principal de-
vient secondaire
Conforme
L’utilisateur principal refuse la demande
d’un utilisateur secondaire
L’utilisateur principal a toujours les
droits de modification et le demandeur
est notifi´e par un message texte ´ecrit
par l’utilisateur principal
Conforme
Tableau 4.4 – Sprint 2 : Test fonctionnels
35

45. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
4.3 Sprint 3 : Partage des modifications en temps r´eel (Par-
tie serveur)
Ce sprint a pour but de d´evelopper la troisi`eme partie de la premi`ere release, qui est le partage
des modifications effectu´ees par un utilisateur principal avec les utilisateurs secondaires connect´es
`a la mˆeme ressource. `A chaque enregistrement effectu´e par l’utilisateur principal, les utilisateurs
secondaires doivent avoir le dernier ´etat de leur ressource.
4.3.1 Backlog du sprint 3
Le Backlog du sprint pr´esent´e dans le tableau 4.5 contient une liste des tˆaches qui devront ˆetre
r´ealis´ees avant la fin de sprint.
ID User sto-
ries
ID Tˆache Tˆache
4, 6
3.1 ´Elaborer un diagramme de s´equence syst`eme
3.2 Discuter le diagramme de s´equence avec le product owner
3.3 Ajuster le diagramme de classe
3.4 Pr´eparer les tests pour la couche EventHandlers
3.5 Coder la couche EventHandlers
3.6 Test unitaires de la couche EventHandlers
3.7 Test fonctionnels du sprint
Tableau 4.5 – Sprint 3 backlog
36

46. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
4.3.2 Analyse
Diagrammes de s´equence
La figure 4.11 montre le diagramme de s´equence syst`eme pour le sc´enario d’un enregistrement
effectu´e par un utilisateur principal.
Sc´enario : Enregistrement effectu´e par un utilisateur principal
Figure 4.11 – Diagramme de s´equence syst`eme : ”Enregistrement effectu´e par un utilisateur princi-
pal”
37

47. Chapitre 4. Mise en place du Release 1.0 : Backend du syst`eme
4.3.3 Conception
Modifications du diagramme de classes
Pour r´epondre aux besoins de ce sprint, nous avons ajout´e la classe SaveEventHandler, cette
classe se charge de tout ce qui concerne le partage de modifications en assurant la r´eception correcte
des signaux par les utilisateurs secondaires.
38

48. Conclusion g´en´erale
Le pr´esent document est une pr´esentation du travail r´ealis´e durant notre projet cadre au sein de
l’entreprise SanadTech. Le projet a pour objectif de r´ealiser un syst`eme de communication pour la
plateforme de d´eveloppement web de RunMyProcess.
Ce syst`eme va rendre le travail collaboratif dans cette plateforme possible, ce qui permettra la
satisfaction des clients actuels de RunMyProcess ainsi que l’attraction de nouveaux clients qui
exigent un travail collaboratif dans leurs projets.
En effet, nous avons d´ebut´e par comprendre le contexte g´en´eral du projet et les diff´erentes exi-
gences du futur syst`eme en ´elaborant un cahier de charges avec toutes les r`egles de gestion.
Par la suite, nous avons ´etudi´e le choix d’un cadre m´ethodologique hybride (SCRUM-XP), ainsi
que la pr´eparation d’un planning de travail en respectant les priorit´es des besoins d´ej`a fix´es.
Par ailleurs, il y avait une discussion avec toute l’´equipe de RunMyProcess concernant les choix
technologiques et l’architecture du syst`eme (logique et physique). Et en dernier lieu, nous avons com-
menc´e la mise en place de la premi`ere release du syst`eme tout en respectant le mod`ele it´eratif du
cadre m´ethodologique adopt´e.
Malgr´e les contraintes du temps et les difficult´es techniques que nous avons rencontr´e qui se
r´esument principalement dans la compr´ehension du sujet et la maˆıtrise des m´ethodes agiles, nous
39

49. Chapitre 4. Conclusion g´en´erale
avons r´eussi `a respecter la totalit´e des exigences du client concernant la premi`ere release (partie
back-end).
Le travail dans le contexte de ce projet cadre, ´etait d’une importance consid´erable dans la mesure
o`u il nous a servi comme portail vers le monde professionnel.
De plus, nous avons sorti du contexte classique ”D´evelopper un syst`eme de A `a Z”, en fait, nous
avons vu pour la premi`ere fois comment contribuer `a un grand syst`eme en cours de d´eveloppement,
tout en respectant les diff´erentes contraintes fonctionnelles et non fonctionnelles d´efinies par d’autres
collaborateurs.
De point de vue technique, il nous a permis de mettre en oeuvre les acquis th´eoriques que nous
avons appris tout au long de notre cursus universitaire et de les enrichir et approfondir des connais-
sances dans des nouvelles technologies de d´eveloppement web temps-r´eel. Outre, ce projet ´etait aussi
enrichissant pour les bonnes pratiques de la gestion de projet agile vu que nous avons eu l’opportunit´e
d’organiser son d´eroulement d`es le d´ebut.
Notre travail ne s’arrˆete pas `a ce niveau, le d´eveloppement et l’int´egration du deuxi`eme release
sont planifi´es dans les prochaines deux mois.
40

50. Annexe A
Annexe : Notions et d´efinitions
A.1 Transformation digitale
La transformation digitale, parfois appel´ee transformation num´erique, d´esigne le processus qui
consiste, pour une organisation, `a int´egrer pleinement les technologies digitales dans l’ensemble de
ses activit´es [21].
A.2 Processus m´etier
Un processus m´etier, ´egalement appel´e processus d’affaires ou processus d’entreprise, d´esigne un
ensemble d’activit´es en interaction qui contribue aux finalit´es des affaires d’une organisation [22].
A.3 Business Process Model and Notation – BPMN
Le BPMN est un mod`ele de processus m´etier et une notation pour d´ecrire les activit´es m´etier
d’une organisation sous forme d’une repr´esentation graphique standardis´ee [23].
41

51. Annexe B
Annexe : Le Framework SCRUM
Scrum est un cadre m´ethodologique agile utilis´e pour la gestion de projet dans le secteur IT.
B.1 Valeurs de SCRUM
Les valeurs de SCRUM sont :[24]
— Concentration
— Courage
— Ouverture
— Engagement
— Respect
B.2 Les responsabilit´es dans SCRUM
B.2.1 Product owner
Le repr´esentant du client. Il d´etermine ce qui doit ˆetre r´ealis´e [25].
42

52. Chapitre B. Annexe : Le Framework SCRUM
B.2.2 SCRUM master
Le responsable du d´eroulement du processus. Il garantit l’efficacit´e de la collaboration entre les
membres de l’´equipe [25].
B.2.3 SCRUM team
Les d´eveloppeurs charg´es de la construction du logiciel et d’en faire une d´emonstration [25].
B.3 Les livrables dans SCRUM
B.3.1 Product backlog
Tout le travail est encadr´e par le backlog. En effet, tout le projet est d´ecoup´e en un ensemble de
”User Stories” (histoires d’utilisateur) class´es par priorit´e et list´es dans le backlog [25]. Le product
backlog comprend les champs suivants
User story
C’est une phrase d´ecrivant la fonctionnalit´e d´esir´ee par le client [25].
Feature
La fonctionnalit´e / Qualit´e exactement d´esir´ee par le client (deux ”user stories” peuvent d´ecrire
la mˆeme ”Feature”) [25].
Priorit´e
C’est une valeur m´etier qui dirige la priorisation du d´eveloppement des histoires utilisateurs
suivant les attentes et les besoins du client. Elle est repr´esent´ee suivant la m´ethode ”MoSCoW” qui
est une technique poss´edant un objectif qui s’articule autour d’un accord entre le client et l’entreprise
sur l’importance des tˆaches `a r´ealiser par rapport aux d´elais pr´evus [27].
MoSCoW a pour signification :
43

53. Chapitre B. Annexe : Le Framework SCRUM
— M (Must) : doit ˆetre fait (vital).
— S (Should) : devrait ˆetre fait dans la mesure du possible (essentiel).
— C (Could) : pourrait ˆetre fait dans la mesure o`u cela n’a pas d’impact sur les autres tˆaches
(confort).
— W (Won’t have) : ne sera pas fait cette fois mais sera fait plus tard (luxe, c’est la zone
d’optimisation budg´etaire).
B.3.2 Sprint backlog
Une s´election de tˆaches retenues du ”Product backlog” pour construire l’objectif du sprint [25].
B.4 Les it´erations de SCRUM
B.4.1 Sprint
Intervalle de temps court (1 mois maximum, souvent appel´e it´eration), pendant lequel la SCRUM
Team va concevoir, r´ealiser et tester de nouvelles fonctionnalit´es [25].
B.4.2 Release
Une s´erie de sprints successifs constituant une version [25].
B.5 Les manifestations dans SCRUM
B.5.1 Daily meeting
C’est un point quotidien qui permet de mettre le point sur ce qui a ´et´e r´ealis´e, les probl`emes
rencontr´es et les objectifs de la journ´ee [25].
44

54. Chapitre B. Annexe : Le Framework SCRUM
B.5.2 Sprint Review
C’est une r´eunion programm´ee `a la fin de chaque sprint durant laquelle l’´equipe projet pr´esente
son travail pour un sprint. Sur la base de cette d´emonstration, le ”Product owner” valide ce qui
a ´et´e r´ealis´e et d´etermine le nouvel objectif en se basant sur le ”Product backlog” et si jamais il
y a un ajout ou bien une modification dans ce dernier [25].
45

55. Annexe C
Annexe : Extreme programming XP
Extreme programming (XP) est une m´ethode agile plus particuli`erement orient´ee sur l’aspect
r´ealisation d’une application. XP est adapt´e aux ´equipes r´eduites avec des besoins changeants [28].
Les activit´es de la m´ethode XP sont :
C.1 Conception
Cette activit´e consiste `a cr´eer des structures qui organisent de fa¸con logique les parties du syst`eme,
elle englobe les pratiques suivantes :
C.1.1 Conception simple
Il faut toujours impl´ementer la solution la plus simple qui puisse fonctionner [28].
C.1.2 M´etaphores
Les m´etaphores permettent de d´ecrire l’architecture du syst`eme et d’utiliser des m´etaphores pour
que tout le monde puisse bien se comprendre [28].
46

56. Chapitre C. Annexe : Extreme programming XP
C.2 Codage
Cette activit´e comprend les pratiques suivantes :
C.2.1 Refactoring du code
Cette pratique consiste `a retravailler le code un peu chaque jour pour le rendre plus lisible, propre
et plus robuste [28].
C.2.2 Standardiser le code
Au cours de la phase du d´eveloppement d’un projet, il faut respecter des normes de nommage et
de programmation standards, pour que chacun puisse lire et comprendre facilement le code produit
par les autres [28].
C.2.3 Propri´et´e collective du code
Tous est sens´es de connaˆıtre les diff´erentes parties du code plus ou moins dans le d´etail [28].
C.3 Tests
Il faut bien que le logiciel produit fonctionne, c’est la raison pour laquelle cette activit´e est pr´esente
[28].
C.3.1 Tests unitaires
La m´ethode XP pr´econise d’´ecrire les tests avant la fonction `a tester (Test Driven Develope-
ment). Ceci permet de v´erifier la qualit´e et la fiabilit´e du code ainsi que de cerner le probl`eme avant
d’´ecrire le code et apporter rapidement des changements dans l’application. Ecrire les tests puis
coder : si vous ne le faites pas, vous n’ˆetes pas un Extreme Programmer dit Kent Beck [29].
47

57. Chapitre C. Annexe : Extreme programming XP
C.3.2 Test fonctionnel
Il est cr´e´e `a partir de l’histoire d’utilisateur. Ce test permet d’impliquer le client dans le projet
puisqu’il a la responsabilit´e de valider l’exactitude des tests [28].
48

58. Bibliographie
[1] RunMyProcess : https://goo.gl/qS7Z6x
[2] Orientation de SCRUM : https://goo.gl/rJ7rMM
[3] Product backlog : https://www.scrum-institute.org/The Scrum Product Backlog.php
[4] Diagramme de cas d’utilisation : https://goo.gl/fok98A
[5] Load balancing : https://goo.gl/YMV5Dv
[6] Publish-Subscribe pattern : https://www.youtube.com/watch?v=aooPutfcQjg
[7] Diagramme de d´eploiement : https://goo.gl/3hifFm
[8] React js : https://goo.gl/vmmspT
[9] Redux : https://redux.js.org
[10] Jest : https://facebook.github.io/jest/docs/en/tutorial-react.html
[11] Nginx : https://nginx.org/en
[12] Load balancing dans Nginx : https://nginx.org/en/docs/http/load balancing.html
[13] Node.js : https://fr.wikipedia.org/wiki/Node.js
[14] Socket.io : https://goo.gl/M64Eod
[15] Mocha js : https://mochajs.org/
[16] Chai js : http://www.chaijs.com/
[17] Redis : https://fr.wikipedia.org/wiki/Redis
49

59. Chapitre C. BIBLIOGRAPHIE
[18] Diagramme de s´equence : https://goo.gl/qF6Rpw
[19] Diagramme de paquetage : https://fr.wikipedia.org/wiki/Diagramme des paquetages
[20] Diagramme de classes : https://fr.wikipedia.org/wiki/Diagramme de classes
[21] Transformation digitale : https://goo.gl/Xxe3jS
[22] Processus m´etier : https://goo.gl/VFmL3Q
[23] BPMN : https://fr.wikipedia.org/wiki/Business process model and notation
[24] Valeurs de SCRUM : https://scrumalliance.org/learn-about-scrum/scrum-values
[25] Ken SCHWABER and Jeff SUTHERLAND, The SCRUM guide
[26] Vasan Subramanian, Pro MERN Stack
[27] M´ethode MoSCoW : https://fr.wikipedia.org/wiki/M%C3%A9thode MoSCoW
[28] Extreme programming (XP) : https://www.agilealliance.org/glossary/xp/
[29] Principes de l’XP : http://extremeprogramming.free.fr/page.php?page=principes
50