Rapport de Projet de Fin D'études: Université de Tunis Institut Supérieur de Gestion

Université de Tunis
Institut Supérieur de Gestion
Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention de la
Licence Fondamentale en Informatique de Gestion
Conception et Développement d’une Application

Android de Gestion de Projets Agiles
Présenté par :
Chourouk Ben Messaoud
réalisé au sein de l’entreprise Sagemcom
Sous la direction de :
Ahmed Badreddine Professeur, ISG Tunis Encadrant pédagogique
Christian Jannot Directeur, Sagemcom Encadrant professionnel
Année Universitaire 2019-2020

Dédicace
“ Je dédie ce travail :
À ma chère mère, à qui je dois la vie et une part

essentielle de ma personnalité. Qu’elle sache que
l’amour qu’elle me donne continue à m’animer.
À mon cher père, décédé trop tôt, j’espère du

monde qui est sien maintenant, il apprécie cet
humble geste comme preuve de reconnaissance.
À mon frère, mes grands-parents, ma famille qui

me donnent de l’amour et de la vivacité.
À tous mes amis , à qui je souhaite plus de succès.
Qu’ils trouvent ici le témoignage de ma profonde

gratitude et reconnaissance.
Merci !
”
- Chourouk
2
Remerciements
Au terme de ce travail, je remercie les personnes qui m’ont apporté leurs

soutiens. Qu’ils trouvent ici l’expression de toute ma reconnaissance.
Je tiens à exprimer toute ma reconnaissance et remerciements à M. Chris-

tian Jannot, mon encadrant professionnel, pour la précieuse expérience qu’il
m’a fait vivre durant la période du stage, pour tous les précieux conseils et
les informations qu’il m’a prodigués et d’avoir consacré du temps à l’enca-
drement et le suivi de ce travail.
Je tiens à remercier également M. Ahmed Badreddine, mon professeur

encadrant, pour son aide, pour les conseils et les informations qu’ils m’a pro-
digués.
D’une autre part, je remercie l’ensemble du corps administratif et ensei-

gnant de l’Institut Supérieur de Gestion de Tunis pour avoir porté un
vif intérêt à notre formation.
Que les membres du jury trouvent ici l’expression de ma gratitude d’avoir

pris le temps d’évaluer l’honneur de ce travail.
3
Table des matières
Introduction générale 14
1 Contexte général du projet 16

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.1 Présentation générale de Sagemcom . . . . . . . . . . . 17
1.1.2 Domaines d’activités de Sagemcom . . . . . . . . . . . 17
1.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Description de l’existant . . . . . . . . . . . . . . . . . 18
1.2.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . 18
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . 19
1.3 Langage et méthodologie de conception . . . . . . . . . . . . . 20
1.3.1 Présentation de la méthode Scrum . . . . . . . . . . . 20
1.3.2 L’équipe Scrum . . . . . . . . . . . . . . . . . . . . . . 21
1.3.3 Les artefacts de la méthodologie Scrum . . . . . . . . . 22
1.3.4 Les événements Scrum . . . . . . . . . . . . . . . . . . 22
1.3.5 Langage de modélisation . . . . . . . . . . . . . . . . . 23
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Sprint 0 : Planification et architecture 24

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Description du contexte . . . . . . . . . . . . . . . . . 25
4
Table des matières 5
2.3 Identification des besoins fonctionnels et non fonctionnels . . . 25

2.3.1 Identification des acteurs . . . . . . . . . . . . . . . . . 25
2.3.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . 26
2.3.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . 27
2.4 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.1 Planification des sprints . . . . . . . . . . . . . . . . . 31
2.5 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . 32
2.6 Diagramme de classes global . . . . . . . . . . . . . . . . . . . 33
2.7 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7.1 Architecture matérielle . . . . . . . . . . . . . . . . . . 34
2.7.2 Protocole et format de données . . . . . . . . . . . . . 35
2.7.3 Architecture Android MVP . . . . . . . . . . . . . . . 36
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 Sprint 1 Authentification, Inscription et gestion de profil 38

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1 Diagramme de cas d’utilisation du Sprint 1 . . . . . . . 40
3.3.2 Raffinement du cas d’utilisation « S’inscrire » . . . . . 41
3.3.3 Raffinement du cas d’utilisation « S’authentifier » . . . 42
3.3.4 Raffinement du cas d’utilisation « Gérer profil » . . . 43
3.3.5 Prototypes des interfaces . . . . . . . . . . . . . . . . . 44
3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.1 Diagramme de séquence détaillé du cas d’utilisation «
S’inscrire » . . . . . . . . . . . . . . . . . . . . . . . . 45
S’authentifier » . . . . . . . . . . . . . . . . . . . . . . 46
3.4.3 Diagramme de séquence détaillée du cas d’utilisation «
Gérer profil » . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.4 Diagramme de classes du premier sprint . . . . . . . . 48

3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.1 Interfaces du Sprint . . . . . . . . . . . . . . . . . . . . 48
3.6 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Sprint 2 : Application dédiée au Product Owner 52

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.2 Raffinement du cas d’utilisation « Gérer projets » . . . 55
4.3.3 Raffinement du cas « Gérer ressources » . . . . . . . . 57
4.3.4 Raffinement du cas d’utilisation « Suivre les projets et
le Dashboard » . . . . . . . . . . . . . . . . . . . . . . 59
4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Gérer projets » . . . . . . . . . . . . . . . . . . . . . . 61
Affecter ressources» . . . . . . . . . . . . . . . . . . . . 62
Attribuer rôle » . . . . . . . . . . . . . . . . . . . . . . 63
Suivre les projets » . . . . . . . . . . . . . . . . . . . . 63
4.4.5 Diagramme de classes du deuxième sprint . . . . . . . 64
4.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5 Sprint 3 : Application dédiée au Scrum Master 67

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.2 Raffinement du cas d’utilisation « Gérer Sprint » . . . 71
5.3.3 Raffinement du cas d’utilisation « Gérer user-stories et
Consulter Backlog produit » . . . . . . . . . . . . . . . 72
5.3.4 Raffinement du cas d’utilisation « Gérer tâches » . . . 73
5.3.5 Raffinement du cas d’utilisation « Consulter Velocity
Chart» . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.6 Raffinement du cas d’utilisation « Consulter Tableau
de Kanban » . . . . . . . . . . . . . . . . . . . . . . . 75
5.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Gérer sprints » . . . . . . . . . . . . . . . . . . . . . . 77
5.4.2 Diagramme de séquence détaillée du cas d’utilisation
« Gérer User-stories » . . . . . . . . . . . . . . . . . . 79
5.4.3 Diagramme de séquence détaillée du cas d’utili-sation
« Assigner tâche » . . . . . . . . . . . . . . . . . . . . 80
5.4.4 Diagramme de séquence détaillée du cas d’utilisation
« Consulter Tableau de Kanban » . . . . . . . . . . . 81
5.4.5 Diagramme de classes du troisième sprint . . . . . . . . 82
5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6 Sprint 4 : Application décidée aux développeurs 87

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.3.2 Raffinement du cas d’utilisation « Consulter mes tâches

» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3.3 Raffinement du cas d’utilisation « Mettre à jour mes
tâches» . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3.4 Raffinement du cas d’utilisation « Consulter le nombre
d’heures passées et restantes » . . . . . . . . . . . . . . 91
6.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Consulter mes tâches » . . . . . . . . . . . . . . . . . . 93
Mettre à jour mes tâches » . . . . . . . . . . . . . . . . 94
Consulter le nombre d’heures passées et restantes . . . 95
6.4.4 Diagramme de classes du quatrième sprint . . . . . . . 96
6.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.6 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7 Rétrospective 99
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.2 Environnement de développement . . . . . . . . . . . . . . . . 100
7.2.1 Environnement matériel . . . . . . . . . . . . . . . . . 100
7.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . 100
7.2.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . 102
7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Conclusion générale 104
Webographie 105
Table des figures
1.1 Logo de Sagemcom. . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 Produits de Sagemcom . . . . . . . . . . . . . . . . . . . . . . 17
1.3 (a) Trello (b) Asana (c) Jira . . . . . . . . . . . . . . . . . . . 18
1.4 Processus scrum. . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1 L’expérience utilisateur . . . . . . . . . . . . . . . . . . . . . . 28

2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . 31
2.3 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . 32
2.4 Diagramme de classe global . . . . . . . . . . . . . . . . . . . 33
2.5 Architecture de l’application . . . . . . . . . . . . . . . . . . . 34
2.6 Fonctionnement de l’architecture . . . . . . . . . . . . . . . . 35
2.7 Architecture MVP . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . 40

3.2 Raffinement du cas d’utilisation « S’inscrire » . . . . . . . . . 41
3.3 Raffinement du cas d’utilisation « S’authentifier » . . . . . . . 42
3.4 Raffinement du cas d’utilisation « Gérer profil » . . . . . . . . 43
3.5 Maquette des interfaces du premier Sprint . . . . . . . . . . . 44
3.6 Diagramme de séquence détaillé du cas d’utilisation « S’ins-
crire » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.7 Diagramme de séquence détaillé du cas d’utilisation « S’au-
thentifier » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9
Table des figures 10
3.8 Diagramme de séquence détaillé du cas d’utilisation « Gérer

profil » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.9 Diagramme de classes du premier sprint . . . . . . . . . . . . 48
3.10 Interfaces de l’authentification . . . . . . . . . . . . . . . . . 49
3.11 Interfaces d’inscription . . . . . . . . . . . . . . . . . . . . . . 49
3.12 (a) Interface d’accueil (b) Menu . . . . . . . . . . . . . . . . . 50
3.13 (a) Consulter profil (b) Modifier profil . . . . . . . . . . . . . 51
4.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . 54

4.2 Raffinement du cas d’utilisation « Gérer projets » . . . . . . . 55
4.3 Raffinement du cas d’utilisation « Gérer ressources » . . . . . 57
4.4 Raffinement du cas d’utilisation « Suivre les projets » . . . . . 59
4.5 Maquettes des interfaces du deuxième Sprint . . . . . . . . . . 60
4.6 Diagramme de séquence du cas "Gérer les projets" . . . . . . 61
4.7 Diagramme de séquence du cas "Affecter ressources" . . . . . 62
4.8 Diagramme de séquence du cas "Attribuer rôle" . . . . . . . . 63
4.9 Diagramme de séquence du cas "Suivre les projets" . . . . . . 63
4.10 Diagramme de classes du deuxième sprint . . . . . . . . . . . 64
4.11 (a) Consulter les projets (b) Créer un projet (c) Supprimer un
projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.12 (a) Consulter les ressources (b) Créer une ressource (c) Affec-
ter une ressource . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.13 (a) Tableau de bord (b) Liste des projets . . . . . . . . . . . 66
5.1 Diagramme de cas d’utilisation global du « Sprint 3 » . . . . . 70

5.2 Raffinement du cas « Gérer sprint » . . . . . . . . . . . . . . . 71
5.3 Raffinement du cas « Gérer user-stories» . . . . . . . . . . . . 72
5.4 Raffinement du cas d’utilisation « Gérer tâches » . . . . . . . 73
5.5 Diagramme de cas d’utilisation du cas « Consulter Velocity
Chart » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6 Raffinement du cas « Consulter Tableau de Kanban » . . . . . 75
Table des figures 11
5.7 Maquettes des interfaces du troisième Sprint . . . . . . . . . . 76

5.8 Diagramme de séquence du cas « Gérer Sprint » . . . . . . . . 78
5.9 Diagramme de séquence du cas « Gérer user-stories » . . . . . 79
5.10 Diagramme de séquence du cas « Assigner tâche » . . . . . . . 80
5.11 Diagramme de séquence du cas « Consulter le tableau de Kan-
ban » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.12 Diagramme de classes du troisième sprint . . . . . . . . . . . . 82
5.13 (a) Liste des Sprints (b) Créer sprint (c) Modifier sprint . . . 83
5.14 (a) Liste des user-stories (b) Supprimer user-story (c) Créer
user-story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.15 (a) Liste des tâches (b) Créer une tâche (c) Supprimer une
tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.16 To do (a) In Progress (b) Done (c) . . . . . . . . . . . . . . . 85
5.17 Velocity Chart . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1 Diagramme de cas d’utilisation du quatrième Sprint . . . . . . 89

6.2 Raffinement du cas d’utilisation « Consulter mes tâches » . . . 89
6.3 Raffinement du cas d’utilisation « Mettre à jour mes tâches » 90
6.4 Raffinement du cas d’utilisation « Consulter le nombre d’heures
passées et restantes » . . . . . . . . . . . . . . . . . . . . . . . 91
6.5 Maquettes des interfaces du quatrième sprint . . . . . . . . . 92
6.6 Diagramme de séquence du cas « Consulter mes tâches » . . . 93
6.7 Diagramme de séquence du cas « Mettre à jour mes tâches » . 94
6.8 Diagramme de séquence du cas « Consulter le nombre d’heures
passées et restantes » . . . . . . . . . . . . . . . . . . . . . . . 95
6.9 Diagramme de classes du quatrième sprint . . . . . . . . . . . 96
6.10 (a) Tableau de bord (b) Liste des projets . . . . . . . . . . . 97
6.11 (a) Liste des tâches (b) Mettre à jour la tâche (c) Consulter
la tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Liste des tableaux
1.1 Différence entre XP et Scrum . . . . . . . . . . . . . . . . . . 20
2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Sprint Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . 39

3.2 Description textuelle du cas d’utilisation "S’inscrire" . . . . . 41
3.3 Description textuelle du cas d’utilisation "S’authentifier" . . . 42
3.4 Description textuelle du cas d’utilisation "Consulter profil" . . 43
3.5 Description textuelle du cas d’utilisation "Modifier profil" . . . 44

4.2 Description textuelle du cas d’utilisation "Consulter projet" . 55
4.3 Description textuelle du cas d’utilisation "Supprimer un projet" 56
4.4 Description textuelle du cas d’utilisation "Attribuer rôles" . . 57
4.5 Description textuelle du cas d’utilisation " Affecter les Res-
sources" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6 Description textuelle du cas d’utilisation "Suivre les projets" . 59

5.2 Description textuelle du cas "Consulter Sprint" . . . . . . . . 71
5.3 Description textuelle du cas d’utilisation "Créer Sprint" . . . . 72
5.4 Description textuelle du cas d’utilisation "Modifier user-story" 73
5.5 Description textuelle du cas d’utilisation "Consulter tâches" . 74
12
Liste des tableaux 13
5.6 Description textuelle du cas d’utilisation "Consulter Velocity

Chart" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.7 Description textuelle du cas d’utilisation "Consulter Tableau
de Kanban" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.2 Description textuelle du cas d’utilisation "Consulter mes tâches" 90
6.3 Description textuelle du cas d’utilisation "Mettre à jour mes
tâches" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.4 Description textuelle du cas d’utilisation "Consulter le nombre
d’heures passées et restantes" . . . . . . . . . . . . . . . . . . 92
Introduction
La méthode agile précisément la méthode SCRUM, intervient depuis

quelques années dans les entreprises. Elle tend à devenir l’outil indispensable.
Souvent synonyme de rapidité, cette méthode permet à une entreprise de
piloter un projet dans des délais réduits tout en impliquant son client dans
le processus.
Cependant, la maîtrise de cette méthode peut dérouter les nouveaux ar-
rivants, étant donné la complication de la nomenclature.
Sagemcom, l’entreprise qui m’a accueilli pendant plus que 4 mois de

stage, organise régulièrement des formations afin de former les salariés et les
nouveaux arrivants.
Dans ce cadre, L’entreprise m’a confié la mission de conception et de dé-
veloppement d’une application Android de gestion de projets agiles, qui a
pour but d’initier à l’agilité les stagiaires des centres Elife (et du centre de
formation Sagemcom).
Le présent rapport est organisé en sept chapitres : Le premier chapitre,

intitulé "Contexte général du projet" sera consacré à la description de l’or-
ganisme d’accueil. Ensuite, nous identifierons les problématiques afin de pro-
poser la solution adéquate et nous présenterons la méthodologie de travail
adoptée.
Le deuxième chapitre, intitulé "Sprint 0 : Planification et architecture",
nous nous intéressons à définir le plan de réalisation et à produire le Backlog
produit, et à présenter une vue architecturale de notre application.
Les quatre chapitres qui suivent, se concentreront sur l’étude et la réali-
sation des sprints de notre projet.
Le dernier chapitre représente la phase de clôtures, dans lequel nous allons
14
Introduction 15
présenter les différents outils utilisés pour la réalisation de notre projet.

L’étape finale est une conclusion générale dans laquelle nous évaluerons notre
travail ainsi que les objectifs atteints.
Chapitre 1
Contexte général du projet
1.1 Introduction
Ce chapitre représente un premier aperçu du projet réalisé. En

“ effet, nous commençons par une brève présentation de l’orga-
nisme d’accueil. Nous enchaînons ensuite par une description
et une critique de l’existant, qui va nous guider vers la solu-
tion proposée et la méthodologie de conception adoptée.
”
16
1.1. Introduction 17
1.1.1 Présentation générale de Sagemcom
Figure 1.1: Logo de Sagemcom.
Sagemcom dont le logo est présenté dans la figure 1.1 est un groupe fran-
çais leader européen sur le marché des terminaux communicants, répondant
à des besoins essentiels au monde qui nous entoure : décodeurs, box Inter-
net et compteurs communicants multi-énergies."Le chiffre d’affaires total du
groupe s’élève à 2,1 milliards d’euros. L’effectif de 5 500 personnes est réparti
dans plus de 50 pays."[1]
1.1.2 Domaines d’activités de Sagemcom

Sagemcom opère principalement sur trois marchés majeurs : le broadband,
l’énergie et le retail, comme le montre la figure 1.2.
— Sagemcom Broadband offre à ses clients des produits customisés,

intégrant les dernières ruptures technologiques.[2]
— Sagemcom Energy & Telecom met à disposition de ses clients
une compétence exclusive dans le développement et l’intégration de
solutions hardware et software.[3]
— Sagemcom Audio et vidéo solutions propose aux clients, une
gamme de décodeurs personnalisables pour toutes les technologies de
transmission.[4]
Figure 1.2: Produits de Sagemcom

1.2. Etude de l’existant 18
1.2 Etude de l’existant

L’étude de l’existant permet de déterminer les points faibles et les points
forts d’un projet. Elle permet d’identifier les différentes imperfections dans
un système existant afin de les corriger.
1.2.1 Description de l’existant

Les méthodes agiles sont très populaires en usage aujourd’hui. Cependant
il est très important de disposer des bons outils pour mener un projet agile
correctement. Dans cette partie, nous présentons des cas de figures des 3
meilleurs outils de gestion de projets agiles à l’échelle internationale.
— Trello : Il consiste sur le découpage du projet en plusieurs tâches

et mini tâches, représentées par des cartes. Ces cartes peuvent être
contenu dans des planches qui définissent l’état ou le type de ces
tâches. [5]
— Asana : C’est un outil de gestion de projet SCRUM qui permet aux
équipe d’avoir un suivi sur leur travail. [5]
— Jira : C’est une application de gestion de projet. Jira permet égale-
ment de faire le suivi de bugs, la gestion des incidents et l’affectation
des tâches aux différents collaborateurs d’un projet.[5]
(a) (b) (c)
Figure 1.3: (a) Trello (b) Asana (c) Jira
1.2.2 Critiques de l’existant

Lors de l’étude que nous avons menée dans la section précédente, nous
avons relevé les problèmes suivants :
Critique de l’application Jira

— La difficulté de la prise en main de l’application.
1.2. Etude de l’existant 19
— Il faut du temps pour s’habituer à son utilisation.

— Son ergonomie est trop complexe.
Critique de l’application Asana
— Les limites de l’offre gratuite de l’outil.

— Difficulté dans la différenciation de certaines fonctionnalités.
Critique de l’application Trello
— Absence de gestion des ressources.

— Absence de suivi du temps et la gestion d’équipe est faible.
— Une seule interface ce qui limite la flexibilité de l’application.
— Prise en charge limitée.
En général, ces applications sont conçues pour des clients expérimentés. En
plus de cela, les applications de gestion de projets agiles sont généralement
des applications hybrides ou bien web et non pas des applications natives.
1.2.3 Solution proposée
Les applications mentionnées ci-dessus, ne répondent pas à notre besoin.

En effet, nous avons besoin d’une application mobile, simple d’utilisa-
tion que nous pourrons utiliser pour initier à l’agilité les stagiaires des centres
Elife (et du centre de formation Sagemcom). Comme solution, nous pro-
posons une application mobile Android, gratuite, de gestion de projets agiles
destinée aux trois acteurs de l’équipe Scrum (Product Owner, Scrum Master
et Développeurs) qui dispose de ces fonctionnalités fondamentales :
— Gestion et suivi des projets.
— Gestion et suivi des ressources.
— Gestion et suivi des sprints.
— Gestion et suivi des user stories.
— Gestion et suivi des tâches.
— Rapports du temps.
— Suivi des statistiques et du tableau de bord.
— Suivi du tableau de Kanban.
1.3. Langage et méthodologie de conception 20
1.3 Langage et méthodologie de conception

La méthodologie est l’ensemble des processus qui offre la possibilité de pi-
loter et d’organiser le développement d’un projet. On distingue deux familles
de méthodes :
— Les méthodes classiques : C’est les méthodes les plus répandues en
management et gestion de projet. Elles reposent sur le principe de la
définition de phases séquentielles où il faut valider l’étape précédente
afin de passer à la suivante.[6]
— Les méthodes Agiles : Elles reposent sur le principe du dévelop-
pement itératif dans lequel on divise un projet en plusieurs étapes
appelées itérations.[6]
Suite à l’étude comparative des deux approches, nous avons penché pour l’uti-
lisation d’une méthode agile. Cependant il existe plusieurs méthodes agiles
différentes, dont les plus utilisées sont Scrum et Extreme Programming (XP)
[7].
Le tableau 1.1, clarifie les différences entre ces deux méthodes [8] :
Méthode XP Méthode Scrum

Durée de l’itération (1 à 2 semaines) Durée de l’itération (2 à 4 semaines)
Possibilités de changer des scénarios Il est interdit de
en cours de l’itération changer les fonctionnalités durant l’itération
Différents rôles attribués Seulement trois rôles sont définis
aux membres de l’équipe (Scrum-master, Product-owner
(programmeur, testeur, coach etc.) et l’équipe)
Table 1.1: Différence entre XP et Scrum
Ces deux méthodes améliorent la transparence et l’adaptabilité des pro-

jets informatiques. Elles valorisent la coopération dans le travail de l’équipe
et l’adaptation aux changements. Pour bien mener notre projet, nous avons
préféré utiliser Scrum comme méthode de conception et de développement.
1.3.1 Présentation de la méthode Scrum

Scrum est une méthode agile qui consiste à découper un projet complexe
en plusieurs cycles ou itérations. Ces cycles peuvent alterner entre plusieurs
phases avec un rythme assez rapide. De nos jours, Scrum est la méthode
agile la plus populaire.[9] La figure 1.4 ci-dessous illustre la mise en place de
Scrum.
Figure 1.4: Processus scrum.
1.3.2 L’équipe Scrum
L’équipe Scrum est pluridisciplinaire, elle comprend trois acteurs,un pro-

priétaire de produit, une équipe de développement et un Scrum Master .[10]
? Le Product Owner : le propriétaire du produit est le gérant du car-

net du produit. C’est lui qui accepte ou refuse le travail présenté.[10]
? Le Scrum Master : Le Scrum Master est responsable de la bonne
compréhension et application de Scrum. [10]
? Équipe de développement : Elle peut contenir plusieurs rôle tels
que les concepteurs ou bien les développeurs.[10]
Dans le contexte de notre projet, Mr Christian Jannot, notre encadrant

du stage est à la fois le Scrum Master et le Product Owner, et nous sommes,
l’équipe de développement.
1.3.3 Les artefacts de la méthodologie Scrum

? Le Backlog de produit : Le Backlog contient une liste qui en-
globe les exigences imposées par le client, et les fonctionnalités a
implémenter.[11]
? Le Backlog de sprint : Il contient la liste des user-stories présentes
dans le Backlog de produit. [10]
? Burndown Chart : Le graphique d’avancement illustré par la fi-
gure 1.5, est un graphique qui permet d’illustrer la progression de
l’équipe.[10]
Figure 1.5: Burndown Chart
1.3.4 Les événements Scrum

? Le Sprint : C’est le coeur de Scrum. L’itération dure entre deux et
quatre semaines. Au bout d’un sprint, une version du produit utilisable
est livrée.[10]
? Le sprint planning : C’est un évènement qui précède le début du
sprint et permet de fixer les objectifs de ce dernier.[10]
? La mêlée quotidienne (Daily Scrum) : C’est une réunion courte
d’environs quinze minutes qui permet d’avoir une vue d’ensemble de
l’avancement du projet.[10]
? Revue du Sprint : C’est une réunion faite à chaque sprint, au cours
de laquelle on clôture ce dernier en faisant un bilan détaillé, et on en
entame un nouveau. [10]
? Rétrospective de Sprint : Une réunion de 45 minutes par semaine
de sprint. Le Scrum Master coordonne cette réunion. Elle a pour but
1.4. Conclusion 23
de mettre en valeur les idées de chacun et de soulever d’éventuels

obstacles rencontrés.[10]
1.3.5 Langage de modélisation

Pour concevoir notre application, nous avons choisi UML [Unified Mode-
ling Language] qui est un langage de modélisation, qui permet de définir les
modèles objets à travers un ensemble de diagrammes.[12]
En effet, c’est la méthode la plus convenable à notre projet qui se base sur le
principe de la programmation orientée objet. Ce langage possède une variété
de diagrammes qui couvrent nos besoins.
1.4 Conclusion
Dans ce chapitre, nous avons présenté l’organisme d’accueil ainsi que ses
différentes activités. Nous avons également présenté le cadre général de notre
projet et la méthodologie qui sera adoptée.
Chapitre 2
Sprint 0 : Planification et
architecture
2.1 Introduction
Ce chapitre vise à identifier les besoins, cerner les rôles des

“ utilisateurs préparer le plan de réalisation. Dans un premier
temps, nous allons identifier les acteurs de notre projet et ceux
qui toucheront de façon directe à notre application. Dans un
second temps, nous allons lister les besoins fonctionnels et
non fonctionnels de l’application. Nous présenterons par la
suite, les besoins de notre système et nous finirons par pro-
duire le Backlog produit ainsi qu’une première planification
des sprints.
”
24
2.2. Analyse des besoins 25
2.2 Analyse des besoins

Tout au long de cette partie, nous allons identifier et préciser les besoins
à satisfaire représentant les fonctionnalités à réaliser dans notre application.
2.2.1 Description du contexte

Dans le cadre de la formation ELIFE, Sagemcom fera une formation sur
le management de projet agile. L’entreprise nous a confié le développement
d’une application Android qui permettra aux étudiants de comprendre les
concepts de base de l’agilité, de les mettre en application et de visualiser
l’avancement en mode projet et multi-projets.
2.3 Identification des besoins fonctionnels et non

fonctionnels
Dans cette section, nous allons définir les principaux acteurs de notre
application et identifier les besoins fonctionnels et non fonctionnels.
2.3.1 Identification des acteurs

? Le Product Owner : Dans notre application, il est aussi l’adminis-
trateur. Il possède une vue synthétique de l’avancement de ses projets.
Il peut gérer des projets, définir les objectifs, nommer le Scrum Mas-
ter, affecter l’équipe et assigner les rôles.
? Le Scrum Master : Il possède une vue synthétique sur ses projets et
une vue détaillée sur les sprints et les user-stories en cours. Il peut gérer
des user-stories, gérer des sprints, définir les tâches par user-story et
allouer les tâches aux membres de l’équipe. Il supervise l’avancement
des sprints, des user-stories et des tâches.
? Le développeur : Il possède une vue synthétique sur ses projets,
sprints, user-stories et une vue détaillée sur ses tâches. Il a la possibi-
lité de mettre à jour l’avancement sur les tâches. Il peut ainsi consulter
le nombre d’heures passées, heures restantes et le pourcentage de com-
plétude prévu et estimé de chaque tâche.
2.3. Identification des besoins fonctionnels et non fonctionnels 26
2.3.2 Les besoins fonctionnels

Dans cette partie, nous allons identifier les fonctionnalités des acteurs de
l’application. Un besoin fonctionnel c’est un cas d’utilisation en termes de
UML. La phase d’identification des acteurs nous a permis de repérer trois
acteurs qui sont le Product Owner, le Scrum Master et l’équipe de dévelop-
pement. Par conséquent, les fonctionnalités à assurer par l’application sont
regroupées en trois catégories comme suit :
Les fonctionnalités du Product Owner

— Authentification et gestion de profil : Le Product Owner doit
s’authentifier pour accéder à son compte. Il peut par la suite consulter
son profil et modifier ses cordonnées.
— Gestion des projets : Le Product Owner peut consulter la liste
de ses projets, créer, modifier ou bien supprimer des projets. Il peut
également suivre le pourcentage de complétude de chaque projet.
— Gestion des ressources : Le Product Owner peut consulter la liste
des utilisateurs. Nommer le Scrum Master de chaque projet, affecter
les développeurs à des projets. Il peut également assigner les rôles.
— Consultation du tableau de bord et suivi de l’avancement des
projets : Le Product Owner peut suivre l’avancement de ses projets
grâce à un tableau de bord qui lui permet de visualiser les statistiques
de complétude sous forme d’un diagramme circulaire (Chart Pie).
Les fonctionnalités du Scrum Master

— Authentification, Inscription et gestion de profil : Le Scrum
Master doit s’authentifier pour accéder à son compte ou s’inscrire. il
peut par la suite consulter son profil et modifier ses cordonnées.
— Consultation de la vue synthétique des projets : Le Scrum
Master peut consulter une vue globale de ses projets, il peut ainsi
suivre le pourcentage de complétude de chaque projet.
— Gestion des sprints : Le Scrum Master peut consulter la liste de
ses sprints, créer, modifier ou bien supprimer des sprints. Il peut éga-
lement suivre le pourcentage de complétude de chaque sprint.
— Gestion des user-stories : Le Scrum Master peut consulter la liste

de ses user-stories, créer, modifier ou bien supprimer des user-stories.
— Gestion des tâcbes : Le Scrum Master peut consulter la liste des
tâches, créer, modifier ou bien supprimer et assigner des tâches aux
développeurs.
— Suivi du Velocity chart : Le Scrum Master peut consulter un Ve-
locity Chart pour suivre l’avancement de ses sprints.
— Suivi du Backlog et du tableau de Kanban : Le Scrum Master
peut consulter son Backlog produit et suivre le tableau de Kanban qui
lui indique l’état de chaque user-story.
Les fonctionnalités des développeurs

— Authentification, Inscription et gestion de profil : Le dévelop-
peur doit s’authentifier pour accéder à son compte ou s’inscrire. Il
peut par la suite consulter son profil et modifier ses cordonnées.
— Consultation de la vue synthétique des projets, sprints et
user stories : Le développeur peut consulter une vue globale de ses
projets, sprints et user-stories.
— Consultation des tâches : Le développeur possède une vue détaillée
sur les tâches qui lui sont assignées.
— Mise à jour des tâches : Le développeur peut mettre à jour l’état
de ses tâches.
— Suivi de la complétude des tâches : Le développeur peut consulter
le nombre d’heures passées, la charge restante et le pourcentage de
complétude relative à chaque tâche.
2.3.3 Les besoins non fonctionnels

Ce sont les normes de base qui garantissent un meilleur fonctionnement
de notre application Parmi ces besoins, on peut citer :
— Design de l’expérience utilisateur : Il s’agit de prévoir les exi-

gences et le comportement des utilisateurs afin de rendre l’interface
plus ergonomique et facile d’utilisation. L’UX design se base sur les
objectifs stratégiques de l’application, des facteurs technologiques et
des problématiques de design et de conception.[13]

Le diagramme 2.1 , résume l’expérience utilisateur 3 catégories :
Figure 2.1: L’expérience utilisateur
— Design de l’nterface utilisateur : L’UI représente le point de contact

visuel entre l’utilisateur et le produit qu’il utilise. L’interface utilisa-
teur est donc toute la partie graphique d’un site web, d’une application
ou d’une interface quelconque.[14]
Pour créer un bon design UI nous devons respecter les normes ergo-
nomiques tel que :
? la hiérarchie
? les contrastes
? le positionnement
— La sécurité : Nous devons sécuriser notre application. D’où le be-
soin de procéder à l’authentification des différents utilisateurs. Il faut
aussi assurer la confidentialité des données, et ce en appliquant des
cryptages au niveau de la base de données.
— L’extensibilité : C’est de pouvoir ajouter des nouvelles fonctionna-
lités ou de mettre à jour celles existantes.
— La fiabilité : Nous devons tester notre application avant de la livrer
aux clients afin d’éviter les bugs.
2.4. Backlog produit 29
2.4 Backlog produit

Le Backlog produit est l’artefact le plus important de Scrum. En effet,
il liste toutes les fonctionnalités et les besoins attendus du produit.[11] Le
Backlog comprend les champs de base suivants :
— Le champ ID détermine un identifiant unique pour chaque user-
story.
— Le champ User-story décrit la fonctionnalité désirée par l’utilisa-
teur.
— Le champ Priorité Pour aider à déterminer l’échelle que l’on va
utiliser, on peut se fixer 3 seuils :
— 60 : user-story de priorité élevée.
— 40 <=X <=60 : user-story de priorité moyenne.
— < 40 : user-story de priorité faible.
Le Tableau 2.1 représente le Backlog de notre application :
Nom du Cas ID User-story Priorité

En tant qu’utilisateur
Inscription 1.1 80
je voudrais m’inscrire
En tant qu’utilisateur,
Authentification 2.1 80
je voudrais m’authentifier
3.1 50
Gestion de profil je veux consulter mon profil
3.2 50
je veux modifier mon profil
En tant que Product Owner,
4.1 je veux consulter 80
la liste de mes projets
Gestion de projet
4.2 80
je veux créer un projet
4.3 60
je veux modifier un projet
4.4 60
je veux supprimer un projet
5.1 je veux consulter la liste 80
des utilisateurs inscrits
Gestion des ressources

5.2 80
je veux nommer le Scrum Master
5.3 80
je veux affecter les développeurs
5.4 60
je veux créer des ressources
Suivre l’avancement
6.1 je souhaite suivre l’avancement 60
des projets
de mes projets.
En tant que Scrum Master,
7.1 70
je veux créer un sprint
Gérer les sprints
7.2 70
je veux modifier un sprint
En tant que Scrum master,
7.3 70
je veux supprimer un sprint
8.1 70
je veux créer une user story
Gérer les User-stories
8.2 70
je veux modifier une user story
8.3 70
je veux supprimer une user story
9.1 70
je veux créer une tâche
9.2 70
je veux modifier une tâche
9.3 70
je veux supprimer une tâche
Gérer les tâches En tant que Scrum Master,
9.4 je veux affecter une 70
tâche à un développeur
Consulter Velocity chart 10.1 30
je veux consulter un Velocity Chart
Consulter un tableau En tant que Scrum Master,
11.1 50
de Kanban je veux consulter un tableau de Kanban
Consulter backlog 12.1 50
je veux consulter un backlog produit

En tant que Scrum Maser,
Consulter mes projets 13.1 50
je veux consulter mes projets
En tant que développeur,
Consulter mes tâches 14.1 70
je veux consulter mes tâches
En tant que développeur,
Mettre à jour mes tâches 15.1 70
je veux mettre à jour mes tâches
Consulter une vue global En tant que développeur,
des mes projets,sprints, 16.1 je veux consulter mes projets,sprints 60
users-stories et user stories
Table 2.1: Backlog produit
2.4.1 Planification des sprints

Durant la réunion de planification des sprints, nous avons décidé de dé-
couper notre projet en 4 sprints, comme le montre la figure 2.2 .
Figure 2.2: Planification des sprints

2.5. Diagramme de cas d’utilisation global 32
2.5 Diagramme de cas d’utilisation global

Le diagramme de cas d’utilisation global de la figure 2.3, donne une vue
d’ensemble des fonctionnalités de notre application.
Figure 2.3: Diagramme de cas d’utilisation global

2.6. Diagramme de classes global 33
2.6 Diagramme de classes global

Le diagramme de classes est très important dans la modélisation orientée
objet. Il permet de représenter les objets du système. La figure 2.4 présente
le diagramme de classe global de notre application.
Figure 2.4: Diagramme de classe global
2.7 Architecture
Les besoins fonctionnels de notre système ayant été définis, il est temps
de définir notre architecture logicielle et matérielle.
2.7. Architecture 34
2.7.1 Architecture matérielle

Notre application se présente sous la forme d’une architecture trois
tiers ou ce qu’on appelle également architecture à trois niveaux (voir
figure 2.5).
Figure 2.5: Architecture de l’application
L’architecture trois tiers est l’application la plus répandue du modèle

multitiers. Plus spécifiquement c’est une architecture partagée entre :
1. Le client : C’est l’outil demandeur de ressources. C’est la partie visible

de l’utilisateur et elle est équipé d’une interface utilisateur. [15]
2. Le serveur de base de données : Ce serveur permet de centraliser et
de restituer les données. Il permet de fournir au serveur d’application
les données demandées.[15]
3. Le serveur de l’application : Ce serveur permet la récupération de
la ressource demandée par le client en faisant appel au serveur de la
base de données. Il est composé d’un programme ou d’un ensemble de
scripts qui constitue les traitements métier.[15]
Fonctionnement de l’architecture
Figure 2.6: Fonctionnement de l’architecture
Comme le montre la figure 2.6, nos clients, font des requêtes HTTP (les
flèches pleines) vers le serveur. Il faut spécifier une URL et attendre à recevoir
une réponse (les flèches vides). La requête passe par l’API qui possède un
processus qui se charge d’associer la forme de l’URL à une action à réaliser.
( Exemple : gestion d’un projet ou d’une ressource dans REST). Ensuite,
L’API va dialoguer avec le serveur afin de récupérer les données. Finalement,
Elle récupère le résultat et le formate dans un format de données spécifique
comme le JSON.[16]
2.7.2 Protocole et format de données
Protocole
Dans notre projet, nous avons utilisé le protocole HTTP, afin de com-
muniquer les données entre la partie cliente mobile et le serveur web. En
effet, Le HTTP (HyperText Transfer Protocol) est un protocole qui per-
met la communication entre un serveur et un client (facilite le dispatch des
fonctions).[17]
Format de données communiquées
JSON (JavaScript Object Notation) est un format d’échange de données

performant, qui est pratique pour la sérialisation des données.[18]
2.7.3 Architecture Android MVP

Le modèle de conception architecturale (MVP) est un modèle de concep-
tion très populaire dans le développement sur Android. En introduisant un
intermédiaire appelé Présenter, il permet de faire la distinction entre la lo-
gique métier (modèle) de la logique de vue (fragment/activité).[19] Cette
architecture peut être décrite par la figure 2.7.
Figure 2.7: Architecture MVP
L’architecture Model-View-Presenter est divisé en trois couches diffé-

rentes définies comme suit :
1. Un modèle (Model) : Le modèle est responsable de la gestion de la

logique métier.[19]
2. Une vue (View) : Dans Android, View peut être un adaptateur d’ac-
tivité, de fragment ou de RecyclerView.[19]
3. un présentateur (Presenter) : Le présentateur est un intermédiaire
entre la vue et le modèle.[19]
2.8. Conclusion 37
2.8 Conclusion
Dans ce chapitre nous avons détaillé les besoins fonctionnels et non fonc-
tionnels de notre projet. Nous avons aussi précisé les acteurs de notre appli-
cation, ainsi que le Backlog du produit et l’architecture adoptée.
Chapitre 3
Sprint 1 Authentification,
Inscription et gestion de profil
3.1 Introduction
Ce chapitre résumera les travaux effectués durant le premier

“ sprint. Nous traitons la phase d’analyse, la phase de concep-
tion et la phase de réalisation dans laquelle nous présenterons
quelques interfaces réalisées.
”
38
3.2. Sprint Backlog 39
3.2 Sprint Backlog

Le sprint Backlog est un outil qui simplifie l’attribution des tâches et
affine le travail. Notre sprint Backlog pour ce chapitre se présente comme
suit 3.1.
ID User story ID Tache

Réaliser les diagrammes de cas d’utilisation,
1.1 de séquences et de classes
de la fonctionnalité "S’inscrire"
1 1.2 Développer le cas "S’inscrire"
je voudrais m’inscrire
1.3 Tester le cas "S’inscrire"
de la fonctionnalité "S’authentifier"
2 2.2 Développer le cas "S’authentifier"
je voudrais m’authentifier
2.3 Tester le cas "S’authentifier"
de la fonctionnalité "Consulter profil"
3 3.2 Développer le cas "Consulter profil"
je voudrais consulter mon profil
3.3 Tester le cas "Consulter profil"
de la fonctionnalité "Modifier profil"
4 4.2 Développer le cas "Modifier profil"
je voudrais modifier mon profil
4.3 Tester le cas "Modifier profil"
Table 3.1: Sprint Backlog du Sprint 1

3.3. Analyse 40
3.3 Analyse
Dans cette section, nous allons présenter le diagramme du cas d’utilisation
du premier sprint, le raffinement de chaque cas d’utilisation et les prototypes
des interfaces.
3.3.1 Diagramme de cas d’utilisation du Sprint 1

La figure 3.1 clarifie le diagramme de cas d’utilisation du premier sprint.
Figure 3.1: Diagramme de cas d’utilisation du sprint 1

3.3. Analyse 41
3.3.2 Raffinement du cas d’utilisation « S’inscrire »

La figure 3.2 illustre le raffinement du cas d’utilisation « S’inscrire ».
Figure 3.2: Raffinement du cas d’utilisation « S’inscrire »
Le tableau 3.2 présente la description textuelle du cas d’utilisation «

S’inscrire »
Acteur Tous les acteurs
L’utilisateur doit créer un compte pour accéder aux différentes
Objectif
fonctionnalités de l’application
Pré-condition Interface d’inscription consultée
Post-condition Utilisateur inscrit
1. L’utilisateur saisit son email, nom prénom, numéro de téléphone
et mot de passe,
2. Il confirme en cliquant sur le bouton « S’inscrire »,
Scénario nominal 3. Le système vérifie si les champs sont vides et fait un signe,
4. Le système envoie ses paramètres d’accès vers
la base de données pour la vérification des données,
5. Le système affiche l’interface d’accueil.
Le système affiche un message d’erreur informant l’utilisateur
que son email est déjà utilisé.
Scénario alternatif
Le système affiche un message d’erreur informant l’utilisateur
qu’il a laissé des champs vides.
Table 3.2: Description textuelle du cas d’utilisation "S’inscrire"

3.3. Analyse 42
3.3.3 Raffinement du cas d’utilisation « S’authentifier

»
Pour pouvoir accéder à l’application, l’utilisateur doit procéder à une
authentification. Les utilisateurs nouvellement inscrits, doivent attendre l’at-
tribution d’un rôle, afin d’accéder à l’interface d’accueil. La figure 3.3 illustre
le diagramme du cas d’utilisation « S’authentifier ».
Figure 3.3: Raffinement du cas d’utilisation « S’authentifier »

S’authentifier »
L’utilisateur doit s’authentifier pour accéder aux différentes
Objectif
fonctionnalités de l’application.
Pré-condition L’utilisateur doit s’inscrire et doit être connecté à internet
Post-condition Utilisateur Authentifié
1. L’utilisateur saisit son email et mot de passe,
2. Il confirme en cliquant sur le bouton « Login »,
3. Le système vérifie si les champs sont vides et fait un signe,
Scénario nominal
4. Le système envoie ses paramètres d’accès vers
la base de données pour la vérification des données,
5. Le système affiche l’interface propre à l’utilisateur.
-Le système affiche un message d’erreur informant l’utilisateur
que son login ou mot de passe sont incorrects.
Table 3.3: Description textuelle du cas d’utilisation "S’authentifier"

3.3. Analyse 43
3.3.4 Raffinement du cas d’utilisation « Gérer profil »

Après avoir terminer le processus d’authentification, une interface d’ac-
cueil s’affiche en fonction du rôle de l’utilisateur. À ce stade, il peut effectuer
différentes opérations, notamment la gestion de ses données personnelles. La
figure 3.4 illustre le raffinement du cas d’utilisation « Gérer profil ».
Figure 3.4: Raffinement du cas d’utilisation « Gérer profil »

Consulter profil »

Objectif L’utilisateur peut accéder à son profil
Pré-condition L’utilisateur doit être authentifié
Post-condition Coordonnées affichées
1. L’utilisateur accède à l’interface du profil,
Scénario nominal 2. Le système affiche l’interface correspondante
et les données
Le serveur de base de données est indisponible :
Le système affiche un message d’erreur
Table 3.4: Description textuelle du cas d’utilisation "Consulter profil"

3.3. Analyse 44

Modifier profil »

Objectif L’utilisateur peut modifier son profil
Pré-condition L’utilisateur doit être authentifié
Post-condition Coordonnées modifiées
1. L’utilisateur accéde à l’interface du profil,
2. L’utilisateur clique sur le bouton « Modifier »,
Scénario nominal 3. L’utilisateur apporte des modifications,
4. L’utilisateur valide en cliquant sur le bouton « Valider »,
5. Le système affiche un message de succès.
le serveur de base données est indisponible :
Table 3.5: Description textuelle du cas d’utilisation "Modifier profil"
3.3.5 Prototypes des interfaces
La création des maquettes d’IHM permet de faciliter la conception des

interfaces. Nous présenterons dans la figure 3.5 les maquettes du premier
Sprint.
Figure 3.5: Maquette des interfaces du premier Sprint

3.4. Conception 45
3.4 Conception
La conception est la deuxième activité du sprint 1. En premier lieu, nous
allons présenter les diagrammes de séquences détaillés des cas d’utilisation
raffinés précédemment. En second lieu, nous présenterons le diagramme de
classes global de ce sprint.
3.4.1 Diagramme de séquence détaillé du cas d’utilisa-

tion « S’inscrire »
La figure 3.6, représente les différentes séquences qui se produisent lors-
qu’un utilisateur appuie sur le bouton s’inscrire de l’interface d’inscription.
Figure 3.6: Diagramme de séquence détaillé du cas d’utilisation « S’inscrire

»
3.4. Conception 46

tion « S’authentifier »
La figure 3.7 représente le diagramme de séquence du cas « S’authentifier
».
Figure 3.7: Diagramme de séquence détaillé du cas d’utilisation « S’authen-

tifier »
3.4. Conception 47
3.4.3 Diagramme de séquence détaillée du cas d’utilisa-

tion « Gérer profil »
La figure 3.8 illustre le diagramme de séquence du cas d’utilisation «
Gérer profil »
Figure 3.8: Diagramme de séquence détaillé du cas d’utilisation « Gérer

profil »
3.5. Réalisation 48
3.4.4 Diagramme de classes du premier sprint

Nous présentons dans la figure 3.9 le diagramme de classes du premier
sprint :
Figure 3.9: Diagramme de classes du premier sprint
3.5 Réalisation
Dans cette partie, nous présentons les différentes interfaces réalisées au
cours de ce Sprint.
3.5.1 Interfaces du Sprint

Interfaces de l’authentification
L’interface 3.10 permet à l’utilisateur d’accéder à l’application après une

validation de son email et de son mot de passe.
(a) (b)
Figure 3.10: Interfaces de l’authentification
Interfaces d’inscription
L’interface 3.11 permet à l’utilisateur de s’inscrire et de créer son compte

utilisateur.
(a) (b)
Figure 3.11: Interfaces d’inscription

Interface d’accueil et menu coulissant
Après avoir réussi la phase d’authentification, l’interface d’accueil s’affiche

sur l’écran de l’utilisateur. Les interfaces varient selon le rôle de l’utilisateur.
Afin d’améliorer l’expérience utilisateur, nous avons ajouté un menu, comme
le montre la figure 3.12.
(a) (b)
Figure 3.12: (a) Interface d’accueil (b) Menu
Interfaces de Gestion de profil
L’utilisateur peut consulter son profil et modifier ses informations, à l’ex-

ception de son rôle, comme le montre les interfaces de la figure 3.13.
3.6. CONCLUSION 51
(a) (b)
Figure 3.13: (a) Consulter profil (b) Modifier profil
3.6 CONCLUSION
Dans ce chapitre, nous avons présenté l’analyse, la conception et la réali-
sation du premier sprint. Le chapitre suivant sera consacré à la réalisation du
deuxième sprint qui englobe les fonctionnalités exécutées par notre premier
acteur "le Product Owner".
Chapitre 4
Sprint 2 : Application dédiée au

Product Owner
4.1 Introduction
Ce chapitre est consacré à la présentation du deuxième Sprint,

“ qui englobe toutes les fonctionnalités exécutes par le Product
Owner. Comme le sprint précèdent, nous présenterons le sprint
Backlog. Nous passons par une phase d’analyse, une phase de
conception et une phase de réalisation, dans laquelle nous pré-
senterons quelques interfaces réalisées.
”
52
4.2 Sprint Backlog

Notre sprint Backlog pour ce chapitre est présenté dans le tableau 4.1.
ID « User stories » ID Tâche

1.1 de séquence, de classes de la fonctionnalité
1 « Gérer projets »
je voudrais gérer mes projets
1.2 Développer le cas « Gérer projets »
1.3 Tester le cas « Gérer projets »
En tant que Product Owner, 2.1 de séquence, de classes de la fonctionnalité
2 je voudrais consulter «Consulter ressources »
mes ressources 2.2 Développer le cas « Consulter ressources »
2.3 Tester le cas « Consulter ressources »
3 je voudrais affecter et gérer « Gérer ressources »
mes ressources 3.2 Développer le cas « Gérer ressources »
3.3 Tester le cas « Gérer ressources »
4 je souhaite suivre l’avancement « Suivre l’avancement des projets »
de mes projets à travers Développer le cas « Suivre l’avancement des
4.2
un graphique projets »
Tester le cas
4.3
« Suivre l’avancement des projets »

4.3. Analyse 54
4.3 Analyse
Dans cette section, nous allons illustrer le diagramme de cas d’utilisation
du deuxième Sprint et le raffinement de quelques cas d’utilisation.

La figure 4.1 clarifie le diagramme de cas d’utilisation du deuxième Sprint.
Figure 4.1: Diagramme de cas d’utilisation du sprint 2

4.3. Analyse 55
4.3.2 Raffinement du cas d’utilisation « Gérer projets

»
La figure 4.2 présente le raffinement du cas d’utilisation « Gérer projets
».
Figure 4.2: Raffinement du cas d’utilisation « Gérer projets »
Le tableau 4.2 présente la description textuelle du cas « Consulter projet

»
Acteur Product Owner
Objectif Permettre au Product Owner de consulter ses projets
Pré-condition Product Owner authentifié
Post-condition Liste des projets affichée
1. Le Product Owner accède à l’interface des projets,
Scénario nominal
2. Le système charge la liste des projets
Le serveur de base données est indisponible :
Table 4.2: Description textuelle du cas d’utilisation "Consulter projet"

4.3. Analyse 56

Supprimer un projet »

Objectif Permettre au Product Owner de supprimer un projet
Post-condition Le projet est supprimé
2. Le système charge la liste de tous les projets,
3. Le Product Owner choisit un projet et clique sur
l’icône du pop-up menu,
Scénario nominal 4. Le Product Owner sélectionne l’option « Supprimer
ce projet »
5. Le système affiche une boite de dialogue,
6. Le Product Owner valide son choix,
7. Le système charge les modifications.
Table 4.3: Description textuelle du cas d’utilisation "Supprimer un projet"

4.3. Analyse 57
4.3.3 Raffinement du cas « Gérer ressources »

Le figure 4.3 illustre le raffinement du cas d’utilisation « Gérer ressources
».
Figure 4.3: Raffinement du cas d’utilisation « Gérer ressources »

Attribuer rôle »
Permettre au Product Owner d’attribuer les rôles aux
Objectif
utilisateurs
Post-condition Rôles attribués
1. Le Product Owner accède à l’interface des ressources,
2. Il clique sur le bouton flottant de l’ajout,
3. Le système charge l’interface de l’ajout,
Scénario nominal
4. Le Product Owner sélectionne un utilisateur et un rôle,
5. Le Product Owner clique sur le bouton « Valider »,
6. Le système charge les données.
Table 4.4: Description textuelle du cas d’utilisation "Attribuer rôles"

4.3. Analyse 58
Le tableau 4 présente la description textuelle du cas d’utilisation « Affec-

ter les Ressources »
Permettre au Product Owner d’affecter les développeurs et
Objectif
d’assigner les Scrum Master à des projets.
Post-condition Ressources affectées
Première Possibilité
1. Le Product Owner accède à l’interface des ressources,
2. Le Product Owner choisit et clique sur un utilisateur,
3. Le Product Owner choisit un projet et clique sur le
bouton « Affecter »
Deuxième Possibilité
Scénario nominal
2. Le système charge la liste de tous les projets,
3. Le Product Owner choisit un projet et clique sur l’icône
du pop-up menu,
4. Le Product Owner sélectionne l’option Affecter des
Ressources
5. Le Product Owner choisit un utilisateur et clique sur le
bouton « Affecter »
6. Le système charge les données
Table 4.5: Description textuelle du cas d’utilisation " Affecter les Res-
sources"
4.3. Analyse 59
4.3.4 Raffinement du cas d’utilisation « Suivre les pro-

jets et le Dashboard »
La figure 4.4 présente le raffinement du cas d’utilisation « Suivre les pro-
jets ».
Figure 4.4: Raffinement du cas d’utilisation « Suivre les projets »
Le tableau 4.6 présente la description textuelle du cas « Suivre les projets

»
Objectif Permettre au Product Owner de suivre ses projets
Post-condition Statistiques affichées
1. Le Product Owner accède à l’interface Dashboard,
2. Le système charge les statistiques,
Scénario nominal Suivi des projets par catégorie
1. Le Product Owner clique sur une catégorie,
2. Le système charge les projets selon leur statut.
Serveur de base de données indisponible :
Table 4.6: Description textuelle du cas d’utilisation "Suivre les projets"

4.4. Conception 60

Nous présenterons dans la figure 5.7 quelques maquettes des interfaces du
deuxième Sprint.
Figure 4.5: Maquettes des interfaces du deuxième Sprint
4.4 Conception
La conception du deuxième Sprint met en évidence le diagramme de sé-
quence de la gestion et du suivi des projets, la gestion des ressources, et le
diagramme de classes du deuxième Sprint.
4.4. Conception 61

tion « Gérer projets »
La figure 4.6 présente le diagramme de séquence du cas «Gérer les projets»
Figure 4.6: Diagramme de séquence du cas "Gérer les projets"

4.4. Conception 62
Il existe deux façons d’affecter les ressources, soit via l’interface des res-
sources, soit via l’interface des projets.

tion « Affecter ressources»
La figure 4.7 présente le diagramme de séquence du cas « Affecter res-
sources »
Figure 4.7: Diagramme de séquence du cas "Affecter ressources"

4.4. Conception 63

tion « Attribuer rôle »
Figure 4.8: Diagramme de séquence du cas "Attribuer rôle"

tion « Suivre les projets »
Figure 4.9: Diagramme de séquence du cas "Suivre les projets"

4.4.5 Diagramme de classes du deuxième sprint

La figure illustre 4.10 le diagramme des classes du deuxième sprint :
Figure 4.10: Diagramme de classes du deuxième sprint
4.5 Réalisation
Dans cette section, nous allons montrer quelques les interfaces réalisées
au cours de ce sprint.

Interfaces de la gestion des projets
La figure 4.11, montre quelques interfaces relatives à la gestion des projets.

Grâce au bouton flottant, le Product Owner peut créer un projet et le pop-up
menu lui permet de supprimer ou bien de modifier un projet.
(a) (b) (c)
Figure 4.11: (a) Consulter les projets (b) Créer un projet (c) Supprimer un
projet
Interfaces de la gestion des ressources
La figure 4.12 montre quelques interfaces relatives à la gestion des res-

sources.
(a) (b) (c)
Figure 4.12: (a) Consulter les ressources (b) Créer une ressource (c) Affecter
une ressource
4.6. Conclusion 66
Interfaces du Dashboard et suivi des projets
La figure 4.13 montre le tableau de bord qui permet au Product Owner

de visualiser l’avancement de ses projets.
(a) (b)
Figure 4.13: (a) Tableau de bord (b) Liste des projets
4.6 Conclusion
Dans ce chapitre, nous avons présenté l’analyse, la conception et la réa-
lisation du deuxième Sprint. À ce niveau, la partie qui concerne le Product
Owner de notre projet est prête à être exploitée. Le chapitre suivant sera
consacré à la réalisation du troisième sprint qui concerne l’application du
Scrum Master.
Chapitre 5
Sprint 3 : Application dédiée au

Scrum Master
5.1 Introduction
Ce chapitre est dédié au troisième sprint. Il englobe toutes

“ les fonctions exécutées par le Scrum master. Comme dans le
chapitre précédent, nous présenterons le sprint Backlog. Nous
passons par une phase d’analyse, une phase de conception et
une phase de réalisation dans laquelle nous allons introduire
quelques interfaces réalisées.
”
67
5.2 Sprint Backlog

Notre sprint Backlog pour ce chapitre se présente comme suit :
ID « User stories » ID Tache

Réaliser les diagrammes
1.1 de cas d’utilisation, de séquence, de classes
1 de la fonctionnalité « Gérer sprint »
je voudrais gérer mes sprints
1.2 Développer le cas « Gérer sprint »
1.3 Tester le cas « Gérer sprint »
2.1 de séquence, de classes
2 de la fonctionnalité « Gérer user stories »
je voudrais gérer mes user stories
2.2 Développer le cas « Gérer user stories »
2.3 Tester le cas « Gérer user stories »
3.1 de cas d’utilisation,de séquence,de classes
3 de la fonctionnalité « Gérer tâches »
je voudrais gérer mes tâches
3.2 Développer le cas « Gérer tâches »
3.3 Tester le cas « Gérer tâches »
En tant que Scrum master, 4.1 de séquence, de classes
4 je voudrais assigner les tâches de la fonctionnalité « Assigner tâches »
aux membres de l’équipe 4.2 Développer le cas « Assigner tâches »
4.3 Tester le cas « Assigner tâches »
En tant que Scrum master, 5.1 de séquence, de classes de la fonctionnalité
5 je voudrais suivre « Suivre l’avancement des tâches »
l’avancement des tâches Développer le cas
5.2
« Suivre l’avancement des tâches »
Tester le cas
5.3
« Suivre l’avancement des tâches »
6.1 de séquence, de classes de la fonctionnalité
6 « Consulter projets »
je voudrais consulter mes projets
6.2 Développer le cas « Consulter projets »
6.3 Tester le cas « Consulter projets ».
5.3. Analyse 69

de cas d’utilisation, de séquence,
En tant que Scrum master, 7.1
de classess de la fonctionnalité
7 je voudrais consulter
« Consulter Velocity Chart »
mon Velocity Chart.
7.2 Développer le cas « Velocity Chart »
7.3 Tester le cas « Velocity Chart ».
de classes de la fonctionnalité
« Consulter tableau de Kanban ».
mon tableau de Kanban
Développer le cas
8.2
« Consulter tableau de Kanban »
Tester le cas
8.3
« Consulter tableau de Kanban ».
de classes de la fonctionnalité
« Consulter Backlog produit »
mon Backlog produit
Développer le cas
9.2
Tester le cas
9.3
5.3 Analyse
Dans cette section, nous allons illustrer le diagramme de cas d’utilisation
du troisième Sprint et le raffinement de quelques cas d’utilisation.
5.3. Analyse 70

La figure 5.1 clarifie le diagramme de cas d’utilisation du troisième Sprint.
Figure 5.1: Diagramme de cas d’utilisation global du « Sprint 3 »

5.3. Analyse 71
5.3.2 Raffinement du cas d’utilisation « Gérer Sprint »

La figure 5.2 illustre le diagramme du cas d’utilisation « Gérer Sprint ».
Figure 5.2: Raffinement du cas « Gérer sprint »
Le tableau 5.2 présente la description textuelle du cas « Consulter sprint

»
Acteur Scrum Master
Objectif Permettre au Scrum Master de consulter ses sprints
Préc-condition Scrum Master authentifié
Post-condition Liste des sprints affichée
Sprint Backlog (vue globale)
1.Le Scrum Master accède à l’interface des sprints,
2.Le système charge la liste de tous les sprints.
Sprint par projet
1.Le Scrum Master accède à l’interface des projets,
Scénario nominale
2.Le système charge les projets,
3.Le Scrum Master choisit un projet,
4.Le Scrum Master sélectionne l’option
« consulter mes sprint » du pop menu,
5.Le système charge la liste des sprints
Le système affiche un message d’erreur.
Table 5.2: Description textuelle du cas "Consulter Sprint"

5.3. Analyse 72
Le tableau 5.3 présente la description textuelle du cas d’utilisation « Créer

un sprint »
Acteur Scrum Master

Objectif Permettre au Scrum Master de créer un sprint
Post-condition Le sprint est crée
1. Le Scrum Master accède à l’interface
des sprints,
2. Il clique sur le bouton flottant de l’ajout,
3. Le système affiche les champs à remplir,
Scénario nominale 4. Le Scrum Master remplit les champs,
5. Le Scrum Master sélectionne un projet,
6. Le Scrum Master clique sur le bouton
« Créer » et valide son choix,
Table 5.3: Description textuelle du cas d’utilisation "Créer Sprint"
5.3.3 Raffinement du cas d’utilisation « Gérer user-stories

et Consulter Backlog produit »
La figure 5.3 illustre le raffinement du cas « Gérer user-stories et Consulter

Backlog produit ».
Figure 5.3: Raffinement du cas « Gérer user-stories»

5.3. Analyse 73

Modifier user-story »
Acteur Scrum Master

Objectif Permettre au Scrum Master de modifier une user-story
Post-condition user-story est modifiée
1. Le Scrum Master accède à l’interface des user-stories,
2. Le système charge la liste des user-stories,
3. Le Scrum Master choisit une user-story
et clique sur l’icône du pop-up menu,
4. Le Scrum Master sélectionne l’option
Scénario nominale « Modifier cette user-story »
5. Le système affiche une nouvelle interface
et charge les données,
6. Le Scrum Master Modifie les champs,
7. Le Scrum Master clique sur le bouton « Modifier »,
Table 5.4: Description textuelle du cas d’utilisation "Modifier user-story"
5.3.4 Raffinement du cas d’utilisation « Gérer tâches »

La figure 5.4 illustre le diagramme du cas d’utilisation « Gérer tâches ».
Figure 5.4: Raffinement du cas d’utilisation « Gérer tâches »

5.3. Analyse 74
Le tableau 5.5 représente la description textuelle du cas d’utilisation «

Consulter tâches »
Acteur Scrum Master
Objectif Permettre au Scrum Master de consulter les tâches
Post-condition Liste des tâches affichée
1. Le Scrum Master accède à l’interface des user stories,
2. Le système charge les user stories,
3. Le Scrum Master choisit une user story,
Scénario nominale
4. Le Scrum Master sélectionne l’option « Consulter les
tâches de cette user story » du pop menu,
5. Le système charge la liste des tâches
Table 5.5: Description textuelle du cas d’utilisation "Consulter tâches"
5.3.5 Raffinement du cas d’utilisation « Consulter Ve-

locity Chart»
La figure 5.6 illustre le raffinement du cas « Consulter Velocity Chart ».
Figure 5.5: Diagramme de cas d’utilisation du cas « Consulter Velocity

Chart »
5.3. Analyse 75
Le tableau 5.6 présente la description textuelle du cas « Consulter Velocity

Chart »
Acteur Scrum Master
Objectif Permettre au Scrum Master de consulter Velocity Chart
Post-condition Velocity Chart affichée
1. Le Scrum Master accède à l’interface du Velocity Chart,
Scénario nominale
2. Le système charge les statistiques.
Table 5.6: Description textuelle du cas d’utilisation "Consulter Velocity

Chart"
5.3.6 Raffinement du cas d’utilisation « Consulter Ta-

bleau de Kanban »
La figure 5.6 présente le raffinement du cas « Consulter Tableau de Kan-
ban ».
Figure 5.6: Raffinement du cas « Consulter Tableau de Kanban »

Consulter tableau de kanban »
Acteur Scrum Master
Permettre au Scrum Master de consulter
Objectif
le tableau de Kanban
5.3. Analyse 76

Post-condition Tableau de Kanban affiché
1. Le Scrum Master accède à l’interface du Backlog Produit,
2. Le système charge la « TO DO LIST » des user-stories
IN PROGRESS LIST :
3.1. Le Scrum master clique sur l’entête tu fragment
Scénario nominale
« IN PROGRESS »
DONE LIST :
3.2. Le Scrum master clique sur l’entête du fragment « DONE »
4. Le système charge les user-stories selon leurs catégories.
Table 5.7: Description textuelle du cas d’utilisation "Consulter Tableau de

Kanban"
Nous présenterons dans la figure 5.7 quelques maquettes du troisième

Sprint.
Figure 5.7: Maquettes des interfaces du troisième Sprint

5.4. Conception 77
5.4 Conception
La conception du troisième Sprint met en évidence le diagramme de sé-
quence détaillé de la gestion des sprints, des user stories, la consultation
du tableau de Kanban, du Velocity chart, le suivi des projets ainsi que le
diagramme de classes global du Sprint.

tion « Gérer sprints »
La figure 5.8 représente diagramme de séquence du cas d’utilisation «
Gérer sprints ».
5.4. Conception 78
5.4. Conception 79
5.4.2 Diagramme de séquence détaillée du cas d’utili-

sation « Gérer User-stories »
La figure 5.9 représente diagramme de séquence du cas « Gérer User-
stories ».
Figure 5.9: Diagramme de séquence du cas « Gérer user-stories »

5.4. Conception 80

sation « Assigner tâche »
La figure 5.10 représente le diagramme de séquence du cas « Assigner

tâche ».
Figure 5.10: Diagramme de séquence du cas « Assigner tâche »

5.4. Conception 81

sation « Consulter Tableau de Kanban »
La figure 5.11 représente le diagramme de séquence du cas « Consulter

tableau de Kanban ».
Figure 5.11: Diagramme de séquence du cas « Consulter le tableau de Kan-

ban »
5.4.5 Diagramme de classes du troisième sprint
Nous présentons dans la figure 5.12 le diagramme de classes du troisième

sprint :
Figure 5.12: Diagramme de classes du troisième sprint
5.5 Réalisation
Dans cette partie, nous présentons les différentes interfaces réalisées dans
le troisième sprint.

Interfaces de gestion des sprints
La figure 5.13 montre les interfaces relatives à la gestion des sprints. Le

Scrum Master peut consulter la liste de ses sprints. Grace au pop-up menu,
il peut modifier ou supprimer un sprint. Pour créer un nouveau sprint, il
faut cliquer sur le bouton flottant et une nouvelle interface de type "Bottom
sheet" apparaîtra sur l’écran.
(a) (b) (c)
Figure 5.13: (a) Liste des Sprints (b) Créer sprint (c) Modifier sprint
Interfaces de gestion des user-stories
La figure 5.14 montre quelques interfaces relatives à la gestion des user-

stories.
(a) (b) (c)
Figure 5.14: (a) Liste des user-stories (b) Supprimer user-story (c) Créer
user-story
Interfaces de gestion des tâches
La figure 5.15 montre quelques interfaces relatives à la gestion des tâches.
(a) (b) (c)
Figure 5.15: (a) Liste des tâches (b) Créer une tâche (c) Supprimer une
tâche
Interfaces Tableau Kanban
Chaque colonne du tableau représente un fragment spécifique qui consti-

tue un « workflow ». Les workflows sont « To Do », « In Progress » et «
Done ».
(a) (b) (c)
Figure 5.16: To do (a) In Progress (b) Done (c)
Interface Velocity Chart
Le Velocity Chart de l’interface 5.17 permet d’afficher la quantité de va-

leur livrée dans chaque sprint, elle permet le Scrum Master de prévoir la
quantité de travail que l’équipe pourra effectuer dans les sprints futurs.
Figure 5.17: Velocity Chart

5.6. Conclusion 86
5.6 Conclusion
Dans ce chapitre, nous avons présenté l’analyse, la conception et la réa-
lisation du troisième Sprint. À ce niveau, la partie qui concerne le Scrum
Master est prête à être exploitée.
Chapitre 6
Sprint 4 : Application décidée aux

développeurs
6.1 Introduction
Ce chapitre est consacré à la présentation du dernier sprint.

“ Il englobe toutes les fonctionnalités des développeurs, dont la
consultation, la mise a jour et le suivi des tâches. Comme
dans les chapitres précédents nous présenterons le sprint Ba-
cklog. Nous passons par une phase d’analyse, une phase de
conception et une phase de réalisation dans laquelle nous al-
lons introduire quelques interfaces réalisées
”
87
6.3. Analyse 88
6.2 Sprint Backlog

Notre sprint Backlog pour ce chapitre se présente comme suit :
ID « User stories » ID Tâche

En tant que développeur, 1.1 de séquence, de classes de la fonctionnalité
1 je voudrais consulter « Consulter mes tâches »
mes tâches 1.2 Développer le cas « Consulter mes tâches»
1.3 Tester le cas « Consulter mes tâches »
2 je voudrais mettre à jour « Mettre à jour mes tâches »
mes tâches 2.2 Développer le cas « Mettre à jour mes tâches »
2.3 Tester le cas « Mettre à jour mes tâches »
3 je voudrais consulter « Consulter les heures passées et restantes »
les heures passées Développer le cas « Consulter les heures
3.2
et restantes passées et restantes »
Tester le cas « Consulter les heures
3.3
passées et restantes »
6.3 Analyse
Dans cette section, nous allons illustrer le diagramme de cas d’utilisa-
tion du quatrième Sprint, le raffinement de quelques cas d’utilisation et les
prototypes des interfaces.
6.3. Analyse 89

La figure 6.1 clarifie le diagramme de cas d’utilisation du quatrième
Sprint.
Figure 6.1: Diagramme de cas d’utilisation du quatrième Sprint
6.3.2 Raffinement du cas d’utilisation « Consulter mes

tâches »
La figure 6.2 illustre le raffinement du cas d’utilisation « Consulter mes
tâches ».
Figure 6.2: Raffinement du cas d’utilisation « Consulter mes tâches »

6.3. Analyse 90

Consulter mes tâches »
Acteur Développeur
Objectif Permettre au développeur de consulter ses tâches
Pré-condition Développeur authentifié
Post-condition Liste des tâches affichée
1. Le développeur accède à l’interface des tâches,
Scénario nominal
2. Le système charge la liste des tâches.
Table 6.2: Description textuelle du cas d’utilisation "Consulter mes tâches"
6.3.3 Raffinement du cas d’utilisation « Mettre à jour

mes tâches»
La figure 6.3 illustre le raffinement du cas d’utilisation « Mettre à jour
mes tâches ».
Figure 6.3: Raffinement du cas d’utilisation « Mettre à jour mes tâches »

6.3. Analyse 91

Mettre à jour mes tâches »
Acteur Développeur
Objectif Permettre au développeur de mettre à jour ses tâches
Post-condition Tâche mise à jour
1. Le développeur accède à l’interface des tâches,
2. Le système charge la liste des tâches,
3. Le développeur choisit une tâche et choisit
l’option "Mettre à jour ma tâche",
Scénario nominal
4. Le système affiche une nouvelle interface et charge les données,
5. Le développeur, modifie le nombre d’heures passées ou le statut,
6. Le développeur valide en cliquant sur le bouton «Modifier»,
Table 6.3: Description textuelle du cas d’utilisation "Mettre à jour mes

tâches"
6.3.4 Raffinement du cas d’utilisation « Consulter le

nombre d’heures passées et restantes »
La figure 6.4 illustre le raffinement du cas d’utilisation « Consulter le

nombre d’heures passées et restantes »
Figure 6.4: Raffinement du cas d’utilisation « Consulter le nombre d’heures

6.3. Analyse 92

Consulter le nombre d’heures passées et restantes »
Acteur Développeur
Permettre au développeur de consulter
Objectif
le nombre d’heures passées et restantes
Post-condition statistiques et charge affichées
1. Le développeur accède à l’interface des statistiques,
Scénario nominal
Table 6.4: Description textuelle du cas d’utilisation "Consulter le nombre

d’heures passées et restantes"
Nous présenterons ci-dessous les maquettes de ce Sprint, pour mettre en

évidence les fonctionnalités du développeur et bien les assimiler.
Figure 6.5: Maquettes des interfaces du quatrième sprint

6.4. Conception 93
6.4 Conception
La conception du quatrième Sprint met en évidence le diagramme de
séquence détaillé de la consultation des tâches, la mise à jour des tâches, la
consultation du nombre d’heures passées et restantes, ainsi que le diagramme
de classes global du Sprint.

tion « Consulter mes tâches »
La figure 6.6 présente le diagramme de séquence du cas d’utilisation «
Consulter mes tâches »
Figure 6.6: Diagramme de séquence du cas « Consulter mes tâches »

6.4. Conception 94
6.4.2 Diagramme de séquence détaillée du cas d’utilisa-

tion « Mettre à jour mes tâches »
Mettre à jour mes tâches »
Figure 6.7: Diagramme de séquence du cas « Mettre à jour mes tâches »

6.4. Conception 95

sation « Consulter le nombre d’heures passées et
restantes
Consulter le nombre d’heures passées et restantes »
Figure 6.8: Diagramme de séquence du cas « Consulter le nombre d’heures

6.4. Conception 96
6.4.4 Diagramme de classes du quatrième sprint

Nous présentons dans la figure 6.9 le diagramme de classes du quatrième
sprint :
Figure 6.9: Diagramme de classes du quatrième sprint

6.5 Réalisation
Dans cette section, nous allons montrer quelques interfaces réalisées au
cours de ce sprint.

Interfaces Tableau de bord et vue globale des projets
L’interface 6.10 permet au développeur de consulter un tableau de bord

et d’avoir une vue globale sur ses projets, ses sprints et ses user-stories.
(a) (b)
Figure 6.10: (a) Tableau de bord (b) Liste des projets
Interfaces Consultation et mise à jour des tâches
Le développeur peut consulter la liste de ses tâches. Il peut consulter

les informations d’une tâche ou bien la modifier. Si le développeur choisit
l’une des options précédentes, une nouvelle interface de type (Bottom Sheet
Fragment) sera chargée, comme illustré à la figure 6.11.
6.6. CONCLUSION 98
(a) (b) (c)
Figure 6.11: (a) Liste des tâches (b) Mettre à jour la tâche (c) Consulter la
tâche
6.6 CONCLUSION
À ce niveau, la partie qui concerne le développeur est prête à être ex-
ploitée. Par la finalisation de ce sprint, nous avons réussi à élaborer tous les
besoins fonctionnels dégagés au niveau de la phase de spécification du projet
et arrivons à la clôture de notre projet.
Chapitre 7
Rétrospective
7.1 Introduction
La phase de clôture est la dernière dans notre projet. Dans le

“ cadre de ce chapitre, nous allons présenter les langages et les
outils de programmation utilisés pour la réalisation de notre
projet.
”
99
7.2. Environnement de développement 100
7.2 Environnement de développement

Dans cette section, nous présenterons deux types d’environnements de
développement.
7.2.1 Environnement matériel
Notre application a été développée sur une machine possédant les carac-
téristiques suivantes :
— Marque : DELL
— Processeur : Intel Core i5-7300
— Disque dur : 1 To
— Mémoire vive : 8 GO
— Système d’exploitation : Windows 10 Entreprise
7.2.2 Environnement logiciel
Nous avons utilisé plusieurs outils et logiciels pour le développement de

notre applications, dont nous citons :
Android Studio
Android Studio est l’environnement de développement spécifique à An-

droid basé sur IntelliJ IDEA (cet environnement est connu de la communauté
des développeurs Java).[20]
PhpStorm
PhpStorm est un IDE PHP qui "comprend" votre code. Il est idéal pour
travailler avec Symfony.[21]
MySQL
MySQL est un Système de Gestion de Base de Données (SGBD) parmi

les plus populaires au monde.[22]
phpMyAdmin
C’est un logiciel libre écrit en PHP qui a pour rôle de s’occuper de l’ad-
ministration d’un serveur de base de données MySQL ou MariaDB. Il inclut
la création de base de données, l’exécution de demandes, et la création de
comptes utilisateur.[23]
Gitlab
C’est une plate-forme permettant d’héberger et de gérer des projets. Elle

offre la possibilité de gérer ses dépôts Git[24]
Visual Paradigm
C’est un outil de conception et de gestion puissant, qui fournit aux dé-

veloppeurs de logiciels la plate-forme de développement de pointe pour créer
des applications de qualité plus rapidement.[25]
PostMan
Postman permet de créer et envoyer des requêtes HTTP. C’est un outil

très pratique pour tester rapidement une API.[26]
Adobe Illustrator
C’est un logiciel de dessin vectoriel qui sert à la création et à l’édition de

toute conception artistique (ou graphique) à base de tracé vectoriel.[27]
Adobe XD
Adobe XD est une solution d’UX/UI design complète pour la conception

de sites web et d’applications mobiles.[28]
Symfony
Symfony est un ensemble de composants PHP ainsi qu’un framework

MVC libre écrit en PHP. Il fournit des fonctionnalités modulables et adap-
tables qui permettent de faciliter le développement d’un site web.[29]
Balsamiq
Balsamiq est un logiciel de conception d’interface utilisateur pour la créa-

tion de wireframes. Il permet de générer des croquis numériques. [30]
Composer
Composer est une gestionnaire de dépendances pour PHP. Il permet de

télécharger des librairies tiers et d’installer automatiquement les librairies
dépendantes de cette dernière [31].
Overleaf-Latex
Overleaf est une plateforme en ligne gratuite permettant d’éditer du texte

en LATEX sans aucun téléchargement d’application.[32].
7.2.3 Technologies utilisées

Java
C’est un langage de programmation orienté objet, conçu par Sun Mi-

crosystems. Il offre la possibilité de créer des logiciels compatibles avec de
nombreux systèmes d’exploitations. [33]
XML
L’Extensible Markup Language (XML) est une évolution du langage SGML

qui permet aux concepteurs de documents HTML d’identifier leurs propres
marqueurs, dans le but de définir la structure des données qu’ils comptent
présenter.[34]
PHP
Le PHP " Hypertext Preprocessor" est un langage informatique utilisé

sur l’internet. Ce langage est principalement utilisé pour produire un site
web. Il est souvent associé à une base de données, tel que MySQL et il est
souvent exécuté du côté serveur (l’endroit où est hébergé le site).[35]
7.3. Conclusion 103
7.3 Conclusion
Dans ce chapitre nous avons présenté les différentes technologies utili-
sées dans l’implémentation de notre projet ainsi que dans la rédaction de ce
rapport. Ce qui engendre la fin du cycle de vie du développement de l’appli-
cation.
Conclusion générale
Tout au long de la préparation de mon projet de fin d’études, j’ai essayé

de mettre en pratique les connaissances acquises au cours de mes études
universitaires et cela dans le but de concevoir et développer une application
de gestion de projets agiles au sein de l’entreprise Sagemcom.
Mon projet intitulé Agile-app est une application mobile conçue dans le
cadre d’une formation ELIFE qui se concentre sur la méthode agile SCRUM
et qui sera organisée par l’entreprise. L’objectif principal de cette dernière
est d’initier les étudiants à la méthode SCRUM, elle permet d’appréhender la
démarche agile dans sa globalité. La formation sera introduite sous la forme
d’un atelier pratique, qui simulera la situation réelle d’un projet élaboré l’aide
de SCRUM.
Sur le plan des nouvelles technologies, cette expérience m’a permis de

renforcer mes connaissances en programmation, d’apprendre d’avantage sur le
développement Android et aussi la conception des API REST. D’autre part,
j’ai appris à travailler dans l’environnement AGILE, et de mieux comprendre
la méthode SCRUM.
En conclusion, je peux encore améliorer l’application, en développent des

modules de statistiques plus avancés, en implémentant un "searchView" afin
d’améliorer la gestion des (projets, sprints, user-stories et tâches). Je peux
également améliorer le design de l’application et ce en concevant un "Dark
Mode".
La prochaine étape sera l’utilisation de l’application dans le campus Sa-

gemcom en septembre et dans le centre Elife pour la prochaine promotion.
104
Webographie
[1] S. site web, “Sagemcom : Qui sommes-nous ?.” https://www.sagemcom.

com/fr/qui-sommes-nous. [Consulté le 13 juin 2020].
[2] Sagemcom, “Solutions broadband.” https://www.sagemcom.com/fr/
solutions-broadband. [Consulté le 17 juin 2020].
[3] Sagemcom, “Smart city.” https://www.sagemcom.com/old/fr/
smart-city/. [Consulté le 17 juin 2020].
[4] Sagemcom, “Audio et video solutions.” https://www.sagemcom.com/
old/fr/broadband/audio-video-solutions/. [Consulté le 17 juin
2020].
[5] L. F. du net, “Comparatif des meilleurs outils de gestion
de projet agile.” https://www.lafabriquedunet.fr/blog/
comparatif-outils-gestion-projet-agile/. [Consulté le 17
juin 2020].
[6] E. de la Jeunesse Congolaise, “La diference entre
les methodes agiles et la methode sequentielle.”
http://bellone-ntembe.over-blog.com/2017/12/
la-diference-entre-les-methodes-agiles-et-la-methode-sequentielle.
html. [Consulté le 12 juin 2020].
[7] C. Aubry, “The tex scrum le guide pratique de la méthode agile la plus
populaire. dunod, 2010..” [Consulté le 10 juin 2020].
[8] “differences-between-scrum-and-extreme-programming.”
https://www.mountaingoatsoftware.com/blog/
differences-between-scrum-and-extreme-programming. [Consulté
le 12 juin 2020].
[9] M. Cohn, “Le blog de mike cohn’s.” https://www.
mountaingoatsoftware.com/blog. [Consulté le 10 juin 2020].
105
Webographie 106
[10] J. S. Ken Schawber, “Le guide scrum de ken schwaber et jeff

sutherland..” https://www.scrumguides.org/docs/scrumguide/v1/
Scrum-Guide-FR.pdf. [Consulté le 10 juin 2020].
[11] L. éditoriale, “Qu’est ce qu’un backlog scrum.” https://www.nutcache.
com/fr/blog/quest-ce-quun-backlog-scrum/. [Consulté le 16 juin
2020].
[12] M. MAAOUYA, “C’est quoi uml ?.” https://www.supinfo.com/
articles/single/1860-ngage-uml. [Consulté le 16 juin 2020].
[13] Emmanuelle, “L’ux design, qu’est-ce que c’est ?.” https://www.creads.
fr/blog/tendance-design-graphique/ux-design. [Consulté le 16
juin 2020].
[14] F. Kiecken, “Qu’est-ce que l’ui design ?.” https://www.sdlv.fr/blog/
ui-design/ui-design. [Consulté le 16 juin 2020].
[15] “l’architecture à trois niveaux.” https://stph.scenari-community.
org/bdd/lap2/co/webUC003archi.html. [Consulté le 15 juin 2020].
[16] “Communication entre android et php/mysql.”
https://zestedesavoir.com/tutoriels/1140/
communication-entre-android-et-php-mysql/. [Consulté le 14
juin 2020].
[17] “Le protocole http.” https://www.commentcamarche.net/contents/
520-le-protocole-http. [Consulté le 14 juin 2020].
[18] P. giraud, “Qu’est-ce que json ?.” https://www.pierre-giraud.com/
javascript-apprendre-coder-cours/json/. [Consulté le 17 juin
2020].
[19] A. M. Android, “Mvp.” https://android.jlelse.eu/
architectural-guidelines-to-follow-for-mvp-pattern-in-android-2374848a0157.
[Consulté le 16 juin 2020].
[20] Eni, “Android studio.” https://www.editions-eni.fr/open/
mediabook.aspx?idR=6fbbbdbbea4683295c74840f81bd04ab.
[21] JetBrains, “Phpstorm.” https://www.jetbrains.com/fr-fr/
phpstorm/features/. [Consulté le 15 juin 2020].
[22] “Mysql.” https://sql.sh/sgbd/mysql. [Consulté le 17 juin 2020].
[23] “phpmyadmin.” https://phpmyadmin-french.readthedocs.io/fr/
latest/intro.html. [Consulté le 16 juin 2020].
Webographie 107
[24] “What is gitlab ?.” https://about.gitlab.com/what-is-gitlab/.

[25] V. Paradigm, “Visual paradigm.” https://www.visual-paradigm.
com/support/documents/vpuserguide/12/13/5963_visualparadi.
html. [Consulté le 16 juin 2020].
[26] ProAbono, “Postman.” https://docs.proabono.com/fr/
presentation-de-postman-pour-api-proabono/. [Consulté le
16 juin 2020].
[27] tutoquest, “Illustrator.” https://tutoquest.com/
illustrator-quest-ce-que-cest-presentation-dadobe-illustrator/.
[28] Adobe, “Adobe xd.” https://helpx.adobe.com/fr/xd/how-to/
what-is-xd.html. [Consulté le 14 juin 2020].
[29] grafikart, “Symfony.” https://www.grafikart.fr/tutoriels/
symfony. [Consulté le 16 juin 2020].
[30] “Balsamiq.” https://balsamiq.com/wireframes/desktop/docs/
intro/. [Consulté le 14 juin 2020].
[31] grafikart, “Composer.” https://www.grafikart.fr/tutoriels/
composer. [Consulté le 15 juin 2020].
[32] Sportail, “Overleaf.” https://paris-sorbonne.libguides.com/c.
php?g=497641&p=4637541. [Consulté le 16 juin 2020].
[33] F. TECH, “Java.” https://www.futura-sciences.com/tech/
definitions/internet-java-485/. [Consulté le 16 juin 2020].
[34] F. TECH, “Xml).” https://www.futura-sciences.com/tech/
definitions/internet-xml-3997/. [Consulté le 15 juin 2020].
[35] I. Master, “Php.” http://glossaire.infowebmaster.fr/php/.

Langue

Rapport de Projet de Fin D'études: Université de Tunis Institut Supérieur de Gestion

Transféré par

Informations du document

Titre original

Copyright

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 :

Rapport de Projet de Fin D'études: Université de Tunis Institut Supérieur de Gestion

Transféré par

Droits d'auteur :

Université de Tunis

Institut Supérieur de Gestion

Rapport de Projet de Fin d’Études

Licence Fondamentale en Informatique de Gestion

Conception et Développement d’une Application

Chourouk Ben Messaoud

réalisé au sein de l’entreprise Sagemcom

Ahmed Badreddine Professeur, ISG Tunis Encadrant pédagogique

Christian Jannot Directeur, Sagemcom Encadrant professionnel

Année Universitaire 2019-2020

À ma chère mère, à qui je dois la vie et une part

À mon cher père, décédé trop tôt, j’espère du

À mon frère, mes grands-parents, ma famille qui

À tous mes amis , à qui je souhaite plus de succès.

Qu’ils trouvent ici le témoignage de ma profonde

Au terme de ce travail, je remercie les personnes qui m’ont apporté leurs

Je tiens à exprimer toute ma reconnaissance et remerciements à M. Chris-

Je tiens à remercier également M. Ahmed Badreddine, mon professeur

D’une autre part, je remercie l’ensemble du corps administratif et ensei-

Que les membres du jury trouvent ici l’expression de ma gratitude d’avoir

1 Contexte général du projet 16

2 Sprint 0 : Planification et architecture 24

2.3 Identification des besoins fonctionnels et non fonctionnels . . . 25

3 Sprint 1 Authentification, Inscription et gestion de profil 38

3.4.4 Diagramme de classes du premier sprint . . . . . . . . 48

4 Sprint 2 : Application dédiée au Product Owner 52

5 Sprint 3 : Application dédiée au Scrum Master 67

5.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6 Sprint 4 : Application décidée aux développeurs 87

6.3.2 Raffinement du cas d’utilisation « Consulter mes tâches

Conclusion générale 104

1.1 Logo de Sagemcom. . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 L’expérience utilisateur . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . 40

3.8 Diagramme de séquence détaillé du cas d’utilisation « Gérer

4.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . 54

5.1 Diagramme de cas d’utilisation global du « Sprint 3 » . . . . . 70

5.7 Maquettes des interfaces du troisième Sprint . . . . . . . . . . 76

6.1 Diagramme de cas d’utilisation du quatrième Sprint . . . . . . 89

1.1 Différence entre XP et Scrum . . . . . . . . . . . . . . . . . . 20

2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1 Sprint Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . 39

4.1 Sprint Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . 53

5.1 Sprint Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . 69

5.6 Description textuelle du cas d’utilisation "Consulter Velocity

6.1 Sprint Backlog du Sprint 4 . . . . . . . . . . . . . . . . . . . . 88

La méthode agile précisément la méthode SCRUM, intervient depuis

Sagemcom, l’entreprise qui m’a accueilli pendant plus que 4 mois de

Le présent rapport est organisé en sept chapitres : Le premier chapitre,

présenter les différents outils utilisés pour la réalisation de notre projet.

Contexte général du projet

Ce chapitre représente un premier aperçu du projet réalisé. En

1.1.1 Présentation générale de Sagemcom

Figure 1.1: Logo de Sagemcom.

1.1.2 Domaines d’activités de Sagemcom

— Sagemcom Broadband offre à ses clients des produits customisés,

Figure 1.2: Produits de Sagemcom

1.2 Etude de l’existant

1.2.1 Description de l’existant

— Trello : Il consiste sur le découpage du projet en plusieurs tâches

(a) (b) (c)

Figure 1.3: (a) Trello (b) Asana (c) Jira

1.2.2 Critiques de l’existant

Critique de l’application Jira

— Il faut du temps pour s’habituer à son utilisation.