Rapport PFE Ilef Ben Slima

Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
  
Université de Carthage
  
Institut National des Sciences
Appliquées et de Technologie
Projet de Fin d’Etudes
Pour l’obtention du
Diplôme National d’Ingénieur
en Sciences Appliquées et en Technologie
Filière : Génie Logiciel
Sujet :
Conception et développement d’une application
interactive de gestion de Sprint de la méthode
SCRUM et partage de connaissances
Réalisé par : Ilef BEN SLIMA
Entreprise d’accueil :
TELNET
Soutenu le 12/06/2013
Responsable à l’entreprise:
Madame : Leila MEFTEH
Responsable à l’INSAT:
Madame : Fatma BAKLOUTI
Année Universitaire : 2012/2013

Table des matières
Introduction 12
1 Présentation du cadre de projet 14
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Organisme d'accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.1 Présentation de Telnet . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.2 Présentation de l'activité Défense & Avionique . . . . . . . . . . . . 15
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.2 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Etude préalable 18
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 Méthodologie Agile Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Méthode de gestion de projet dans Telnet . . . . . . . . . . . . . . . . . . 22
2.2.1 Gestion de projet dans Telnet . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Analyse de la méthode de gestion de projet de Telnet . . . . . . . . 25
2.2.3 Comparaison avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Inventaire des logiciels de gestion de projet existants . . . . . . . . . . . . 28
2.3.1 Outils payants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2 Outils gratuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.3 Récapitulatif des outils et de leurs limites . . . . . . . . . . . . . . . 31
2.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Spécication des besoins 34
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.1 Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3

Table des matières
3.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Cas d'utilisation globaux . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.2 Cas d'utilisation détaillés . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Planication du cycle de vie du projet . . . . . . . . . . . . . . . . . . . . 58
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4 Architecture et conception 60
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.2 Architecture détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2 Conception générale : Diagramme de Package . . . . . . . . . . . . . . . . 64
4.3 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.1 Conception statique . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.2 Conception dynamique . . . . . . . . . . . . . . . . . . . . . . . . . 76
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5 Réalisation et test 84
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1 Environnement matériel et logiciel . . . . . . . . . . . . . . . . . . . . . . . 84
5.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3 Phase d'implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.1 Couche de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.2 Couche métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.3 Couche de présentation . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.4 Scénarios d'exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.5 Tests réalisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Conclusion 123
4

Liste des gures
1 Le cycle de vie d'un projet géré selon la méthode Scrum . . . . . . . . . . 17
2 Exemple de backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Exemple de Post-it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Processus de travail de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Exemple de chier Backlog d'un projet chez Telnet . . . . . . . . . . . . . 23
6 Exemple de chier Planication de sprint d'un projet chez Telnet . . . . . 23
7 Exemple de chier de performance Scrum d'un projet chez Telnet . . . . . 24
8 Participation des acteurs aux modules fournis par l'application . . . . . . 35
9 Répartition des cas d'utilisation globaux en packages . . . . . . . . . . . . 40
10 Diagramme de cas d'utilisation global du package Gestion de projet . 41
11 Diagramme de cas d'utilisation global du package Gestion de ressources 42
12 Diagramme de cas d'utilisation global du package Gestion de sprint . . 43
13 Diagramme de cas d'utilisation global du package Partage de connais-
sances et d'informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
14 Diagramme détaillé du cas d'utilisation Créer un projet . . . . . . . . . 45
15 Diagramme de cas d'utilisation Visualiser les congés d'une ressource . . 46
16 Diagramme de cas d'utilisation Visualiser login et password d'une res-
source pour un environnement externe . . . . . . . . . . . . . . . . . . . . 47
17 Diagramme de séquence système détaillant le cas Visualiser login et pass-
word d'une ressource pour un environnement externe . . . . . . . . . . . . 47
18 Diagramme de cas d'utilisation Gérer login et password d'une ressource
pour un environnement externe . . . . . . . . . . . . . . . . . . . . . . . 48
19 Diagramme de cas d'utilisation Visualiser planication et suivi de sprint 50
20 Diagramme de cas d'utilisation Visualiser les statistiques . . . . . . . . 51
21 Diagramme de cas d'utilisation Planier un sprint . . . . . . . . . . . . 52
22 Diagramme de séquence Planier un sprint . . . . . . . . . . . . . . . . 53
5

Liste des gures
23 Diagramme de séquence Aecter une tâche . . . . . . . . . . . . . . . . 54
24 Diagramme de cas d'utilisation Remplissage du chier Backlog . . . . . 54
25 Diagramme de cas d'utilisation Déplacer sa tâche . . . . . . . . . . . . 55
26 Diagramme de cas d'utilisation Déclencher une discussion . . . . . . . . 56
27 Diagramme de cas d'utilisation Approuver un commentaire . . . . . . . 57
28 Diagramme de séquence Approuver un commentaire . . . . . . . . . . . 58
29 Architecture générale de l'application Web Application de gestion de pro-
jet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
30 Architecture de la couche de données . . . . . . . . . . . . . . . . . . . . . 62
31 Modèle de conception Modèle-Vue-Contrôleur . . . . . . . . . . . . . . . . 63
32 Diagramme de package global . . . . . . . . . . . . . . . . . . . . . . . . . 64
33 Diagramme des package de la base de données . . . . . . . . . . . . . . . . 65
34 Diagramme des package de la couche de données . . . . . . . . . . . . . . . 65
35 Diagramme des package de la couche de présentation . . . . . . . . . . . . 66
36 Interaction entre les diérentes couches de l'architecture . . . . . . . . . . 67
37 Diagramme de classe du package Gestion de ressources . . . . . . . . . 68
38 Diagramme de classe du package Gestion et suivi de sprint . . . . . . . 69
39 Diagramme de classe Partage de connaissances . . . . . . . . . . . . . . . . 70
40 Diagramme de classe Partage d'informations . . . . . . . . . . . . . . . . . 71
41 Diagramme de classe représentant les implémentations des DAO . . . . . . 72
42 Exemple de Classe DAO et son interface . . . . . . . . . . . . . . . . . . . 73
43 Portion du diagramme de classe complet de la couche DAO . . . . . . . . . 73
44 Diagramme de classe de la couche métier . . . . . . . . . . . . . . . . . . . 75
45 Diagramme de classe des contrôleurs de la couche présentation . . . . . . . 76
46 Diagramme de séquence Planier un sprint . . . . . . . . . . . . . . . . 78
47 Diagramme de séquence Aecter une tâche . . . . . . . . . . . . . . . . 79
48 Diagramme de séquence Approuver un commentaire . . . . . . . . . . . 80
49 Diagramme de séquence Créer un projet . . . . . . . . . . . . . . . . . 81
50 Diagramme d'état transition Etat d'une tâche aectée . . . . . . . . . . 82
51 Diagramme d'état transition Etat de la discussion . . . . . . . . . . . . 83
52 Référence du projet de la couche de données dans le projet Couche Métier 88
53 Structure du projet de la couche de données . . . . . . . . . . . . . . . . . 89
54 Entête commune de l'application dénit par la master page, aché pour
utilisateur non authentié . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6

Liste des gures
55 Exemple d'utilisation de Nested master page . . . . . . . . . . . . . . . . . 91
56 Exemple de post-it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
57 Tableau de post-it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
58 Exemple d'une courbe BurnDown Chart . . . . . . . . . . . . . . . . . . . 96
59 Exemple d'une courbe d'Avancement . . . . . . . . . . . . . . . . . . . . . 97
60 Exemple d'un graphe d'états de tâches . . . . . . . . . . . . . . . . . . . . 98
61 Exemple d'un graphe de dépassement de délai . . . . . . . . . . . . . . . . 99
62 Exemple d'un graphe de Performance de sprint . . . . . . . . . . . . . . . . 100
63 Exemple d'un graphe de Performance de Telnet . . . . . . . . . . . . . . . 101
64 Exemple de Backlog exporté en chier Excel . . . . . . . . . . . . . . . . . 102
65 Exemple de graphe exporté en chier Excel . . . . . . . . . . . . . . . . . . 102
66 Interface de l'ajout d'un chef de projet . . . . . . . . . . . . . . . . . . . . 103
67 Interface de l'ajout d'un nouveau projet . . . . . . . . . . . . . . . . . . . 104
68 Interface de la sélection d'une date de début du projet à travers un calendrier104
69 Interface de l'ajout des ressources au projet . . . . . . . . . . . . . . . . . 105
70 Interface d'ajout d'une nouvelle ressource . . . . . . . . . . . . . . . . . . . 105
71 Interface de la page d'accueil d'un chef de projet . . . . . . . . . . . . . . . 106
72 Interface de la page Espace de projet . . . . . . . . . . . . . . . . . . . . . 107
73 Interface de la page Backlog du sprint courant . . . . . . . . . . . . . . . . 107
74 Interface de l'ajout d'une tâche au Backlog . . . . . . . . . . . . . . . . . . 108
75 Exportation du Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
76 Fichier Excel d'un Backlog exporté . . . . . . . . . . . . . . . . . . . . . . 109
77 Ajout d'un congé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
78 Choix de la date de début du sprint à planier . . . . . . . . . . . . . . . . 110
79 Interface de la planication d'un sprint . . . . . . . . . . . . . . . . . . . . 111
80 Aectation d'une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
81 Sauvegarde du sprint et des tâches aectées . . . . . . . . . . . . . . . . . 112
82 Tableau de planication de sprint . . . . . . . . . . . . . . . . . . . . . . . 113
83 Tableau de de bord d'un développeur . . . . . . . . . . . . . . . . . . . . . 113
84 Tableau de planication de sprint avec des post-it présentant les tâches . . 114
85 Editer une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
86 Tâche bloquée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
87 Statistiques de suivi du sprint en cours . . . . . . . . . . . . . . . . . . . . 116
88 Statistiques d'évaluation du sprint clôturé . . . . . . . . . . . . . . . . . . 117
7

Liste des gures
89 Déclenchement d'une notication suite à l'évènement de terminaison d'une
tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
90 Nouvelle notication ajoutée . . . . . . . . . . . . . . . . . . . . . . . . . . 118
91 Lancement d'une nouvelle discussion . . . . . . . . . . . . . . . . . . . . . 119
92 Réception d'une notication suite à l'évènement de l'ouverture d'une nou-
velle discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
93 Nouvelle notication ajoutée . . . . . . . . . . . . . . . . . . . . . . . . . . 119
94 Exemple de test réussi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
95 Exemple de test échoué . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
96 Message d'erreur suite au choix d'une date de début non valide . . . . . . . 121
97 Message de conrmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
98 Messages de validation de la saisie de champs obligatoires . . . . . . . . . . 122
8

Liste des tableaux
I Comparaison entre les rôles de Scrum et les rôles chez Telnet . . . . . . . . 26
II Comparaison des cérémonies utilisées dans Telnet avec les cérémonies de
Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
III Comparaison des estimations de Scrum aux estimations utilisées dans Telnet 28
IV Points forts et points faibles de Mingle . . . . . . . . . . . . . . . . . . . . 29
V Points forts et points faibles de Pivotal Tracker . . . . . . . . . . . . . . . 29
VI Points forts et points faibles d'IceScrum . . . . . . . . . . . . . . . . . . . 30
VII Points forts et points faibles d'Agilefant . . . . . . . . . . . . . . . . . . . . 31
VIII Comparaison entre les rôles de Scrum et les rôles chez Telnet . . . . . . . . 32
IX Planication du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9

Glossaire
Sprint : Le Scrum est utilisé dans un contexte agile et repose sur un mode fonctionnement
itératif. Chaque itération est appelée Sprint. Un sprint possède une durée dénie qui
varie selon les projets et les environnements (généralement 2 ou 4 semaines). Sur cette
période dénie, l'équipe doit aboutir à créer un incrément du produit potentiellement
livrable.
Release : Un release correspond à la livraison d'une version. Par habitude, on parle
de release pour considérer la période de temps qui va du début du travail sur cette
version jusqu'à sa livraison et qui passe par une série de sprints successifs. En français
on garde release.
User Story : Une User story est description concise d'une fonctionnalité orant une
valeur à l'utilisateur du produit. Exemple de User Story : En tant que recruteur, je
peux déposer des ores d'emploi.
Epic : C'est une grosse User Story en attente de décomposition en User Story plus petites.
Backlog : Liste ordonnée de toutes les choses à faire. En Scrum, on parle de deux types
de Backlog : le backlog de produit et le backlog de sprint. En anglais backlog. En
français, il y a eu des tentatives pour traduire en cahier, en retard cumulé, mais
l'usage de loin le plus courant est de conserver backlog.
Product Backlog : Il énumère les exigences avec le point de vue du client. Le product
backlog représente une réserve de fonctionnalités priorisées qui sont à implémenter
prochainement par les membres de l'équipe.
Sprint Backlog : Le Sprint backlog représente l'ensemble des tâches sélectionnées depuis
le product backlog lors de la réunion de planication an d'améliorer le produit avec
de nouvelles fonctionnalités.
Sprint Planning : Avant chaque début de Sprint, il faut dénir les objectifs à atteindre
et les tâches à réaliser. Ces tâches à réaliser sont piochées dans le product backlog
et transférées ensuite dans le sprint backlog. Le volume et les éléments à prendre
en compte sont déterminés en fonction de la priorisation du product owner et de la
capacité des membres de l'équipe à délivrer. Chaque fonctionnalité peut être éclatée
en diérentes tâches si elle est trop complexe. Ces tâches sont chirées par tout le
monde an d'assurer une estimation plus précise.
10

Glossaire
BurnDown chart : Le burndown chart est un graphe qui montre, sur une période donnée
(ex : un sprint), l'évolution des fonctionnalités restant à implémenter dans le produit.
Ce graphe est composé de deux courbes : la courbe théorique et la courbe réelle. Les
courbes sont décroissantes et lorsque la courbe réelle atteint 0, c'est que toutes les
tâches ont été réalisées.
Product owner : C'est le représentant des clients. Littéralement le propriétaire du pro-
duit. Le Product Owner possède une vision complète du produit, de ce à quoi le
produit doit ressembler et ce qu'il doit comporter. Il détient également toutes les
spécications associées au produit. Généralement ce rôle est détenu par la maîtrise
d'ouvrage (MOA).
Scrum Master : Animateur, facilitateur d'une équipe Scrum. Littéralement le maître de
Scrum. Le Scrum Master est responsable de l'application quotidienne des directives
Scrum. C'est lui qui est en charge d'assurer un environnement de travail agréable
pour l'ensemble des membres de l'équipe.
Team Member : C'est bien beau d'avoir Scrum master et un product owner ultra com-
pétents, mais ces derniers ne pourront pas à eux seul développer le produit. Les
membres de l'équipe restent au centre de ce dispositif. Ce sont eux qui possèdent les
compétences et le temps nécessaire pour développer le produit.
Story points : Représente une estimation de l'eort nécessaire, à une équipe, pour im-
plémenter une fonctionnalité (story). Cette estimation ne possède pas une unité, elle
se fait en valeur relative (suivant un intervalle dénie par l'équipe).
Vélocité : Mesure du nombre de points nis pendant un sprint, c'est-à-dire la somme
des points des tâches que l'équipe a pu réaliser en un sprint.
Planning Poker : Réunion pendant laquelle les membres de l'équipe se mettent d'accord
sur l'estimation en Story Point de chaque fonctionnalité [2]
11

Introduction Générale
Chaque jour et partout dans le monde, de nouveaux projets sont nés, de nouvelles
idées sont inventées et de nouveaux objectifs sont xés, mais malheureusement, un grand
nombre de ces projets échouent. Selon l'analyse faite par le cabinet Standish Group en
2009, seulement 38% des projets informatiques réussissent en respectant les coûts, les
délais et les spécications prédénies [7]. La complexité du milieu dans lequel se déroule
le projet est souvent à l'origine de ces échecs : les divers acteurs du projet, les dié-
rentes ressources, le temps,... An de surmonter ces dicultés, les entreprises recourent
aux méthodologies de gestion de projet. Rémi Bachelet dénit la gestion de projet ou
conduite de projet comme une démarche visant à structurer, assurer et optimiser le bon
déroulement d'un projet [8]. La gestion du projet vise essentiellement à bien planier
les tâches, à dénir les responsabilités, à assurer la communication entre les diérents ac-
teurs de l'équipe, à contrôler les ressources, les délais et les coûts et à maîtriser les risques
du projet. Parmi les méthodologies de gestion de projet, se présentent les méthodologies
Agile. Selon Messager, une méthode agile est une approche itérative et incrémentale, qui
est menée dans un esprit collaboratif, avec juste ce qu'il faut de formalisme. Elle génère
un produit de haute qualité tout en prenant en compte l'évolution des besoins des clients
[1] .Ces méthodologies sont basées sur quatre valeurs : l'équipe (l'interaction avec les per-
sonnes plutôt que les processus et les outils), l'application (une production opérationnelle
plutôt qu'une documentation complète), la collaboration (la collaboration avec le client
plutôt que le respect du contrat) et l'acceptation du changement (réagir au changement
plutôt que suivre un plan) [15]. L'une des méthodologies Agile les plus utilisées est la
méthodologie SCRUM. C'est un processus incrémental et itératif qui permet, à la n de
chaque itération, de livrer un ensemble de fonctions utilisables [9]. La méthodologie Agile
SCRUM est utilisée par le groupe Telnet pour la gestion des projets. En adaptant légère-
ment cette méthodologie à ses besoins, le groupe cherche à garantir le bon déroulement
des projets en respectant les valeurs et les principes de SCRUM.
La mise en place de la méthode SCRUM dans Telnet se base essentiellement sur
l'utilisation de chiers Excel et les diérentes tâches sont eectuées manuellement : la
rédaction du chier Excel pour la planication des tâches, l'aectation des tâches aux
employés, la vérication de la disponibilité des employés, les graphes de performance de
l'équipe et du déroulement du sprint, ... L'équipe de Telnet désire avoir un outil dédié à la
gestion de projet et se basant sur la méthodologie SCRUM. Cet outil doit être interactif
et doit aussi gérer le partage d'informations et de connaissances.
12

Introduction Générale
C'est dans ce contexte que s'inscrit le projet de n d'étude, ce projet a pour objectif
de développer une plateforme de gestion de projet qui englobe la gestion des ressources
humaines d'un projet, la gestion de la planication d'un sprint (itération dans Scrum) et
le partage de connaissances.
Cette plateforme est conçue pour faciliter de manière signicative la gestion de pro-
jet pour les équipes de Telnet, elle cherche à automatiser toutes les tâches du chef de
projet concernant les artefacts de Scrum, à fournir un environnement web qui permet la
communication entre les membres d'une équipe et à permettre le suivi actuel de l'avan-
cement d'un projet. Des statistiques sur la performance d'un sprint doivent être fournies
automatiquement par l'outil à la n de chaque sprint. Le présent rapport est composé de
cinq chapitres. Dans le premier chapitre, nous présentons l'organisme d'accueil Telnet
, l'objectif du projet et la méthodologie de travail. Le deuxième chapitre est une étude
de l'existant dans l'organisme ainsi que dans le monde entier. Dans le troisième chapitre,
nous exposons les spécications des besoins de notre projet. Une conception architectu-
rale et détaillée fera l'objet du quatrième chapitre. Le cinquième chapitre portera sur la
réalisation du projet. Il décrit l'environnement de travail, la phase d'implémentation et
les tests réalisés.
13

CHAPITRE
1 Présentation du cadre de
projet
Introduction
L'idée d'un projet vient généralement d'un besoin exprimé par le client. Dans ce cha-
pitre, nous allons mettre le projet dans son contexte et nous allons indiquer les diérents
besoins qui ont déclenché sa mise en place. Nous présentons tout d'abord l'organisme d'ac-
cueil Telnet et spéciquement le secteur d'activité Défense . Nous présentons ensuite
le cadre général du projet et nous décrivons son objectif. Enn, nous nous intéressons à
l'aspect organisationnel en spéciant la méthodologie de gestion de projet adoptée durant
le stage.
1.1 Organisme d'accueil
1.1.1 Présentation de Telnet
TELNET HOLDING est une société d'ingénierie spécialisée dans le domaine des tech-
nologies de l'information, des systèmes embarqués, de l'électronique et la mécanique, en
plus de l'intégration et le déploiement de systèmes de réseau et de télécommunications.
Crée en 1994, TELNET est rapidement devenu leader dans son coeur de métier à
l'échelle nationale.
TELNET a cherché depuis sa création à élargir ses champs de compétences an de
proposer à ses clients des prestations de qualité et diversiées selon les spécications
demandées.
Elle est considérée comme un acteur majeur dans le domaine des hautes technologies
et occupe un positionnement de plus en plus important à l'échelle régionale.
TELNET dispose d'un centre de développement qui a été certié CMMi niveau 5 en
2006 et ISO 9001 version 2008, ce qui lui permet de garantir la sécurité, la condentialité
et la propriété intellectuelle de ses prestations. [25]
Le groupe Telnet dispose d'un ensemble de départements variés :
14

Chapitre 1. Présentation du cadre de projet
− Département Technologie Systèmes
− Département Déploiement
− Bureau d'étude électronique
− Bureau d'études Microélectroniques
− Bureau d'études mécaniques
Le département Technologie systèmes a pour mission le développement logiciel dans
le domaine des technologies de l'information (TI), de l'informatique scientique et tech-
nique et des systèmes embarqués temps réel ainsi que des tests unitaires pour des appli-
cations critiques. Les domaines d'activités de ce département sont :
− Télécommunications
− Multimédia
− Transport Automobile
− Défense Avionique
− Sécurité carte à puce
− Industrie
− Systèmes d'information
Ce stage a été eectué au sein du département Technologie Systèmes, et en parti-
culier dans l'activité Défense et Avionique.
1.1.2 Présentation de l'activité Défense Avionique
L'activité Défense et Avionique de Telnet est un pôle de recherche et de développement
applicatif et embarqué constituée d'une équipe d'ingénieurs opérants dans les domaines de
défense et de l'avionique. Cette activité assure, depuis une dizaine d'année, des prestations
pour le compte du groupe SAFRAN sur des projets à haut niveau de criticité.
Le service Défense et avionique inclus une équipe spécialisée en :
− développement de systèmes avioniques embarqués
− développement de banc d'essai : développement logiciel des applications de tests des
équipements et participation à la dénition Hardware des bancs et des outils de
mesures.
− développement d'un simulateur : l'idée est de développer un banc qui permet la
simulation de tous les équipements de l'avion qui s'interfacent avec ce service.
− En général, le développement d'applications utilisées dans le domaine de la défense
ou de l'avionique comme CDU (Unité de données de commande) pour l'interfaçage
et la gestion d'inertie.
15

1.2 Présentation du projet
1.2.1 Cadre du projet
Pour garantir la réussite de ses projets, Telnet recourt à la méthodologie agile Scrum,
essentiellement dédiée à la gestion de projets informatiques. Cependant, en se basant sur
des chiers Excel comme outil de Scrum, l'équipe de Telnet a rencontré des problèmes
dus aux limites de cet outil et elle a senti la nécessité d'utiliser un outil plus automatisé
et plus performant.
De plus, Telnet a adapté la méthodologie Scrum à ses besoins sans respecter exacte-
ment les artefacts de Scrum, c'est pour cela qu'elle a décidé de développer son propre
outil de gestion de projet.
C'est dans ce contexte que s'inscrit le projet de n d'étude proposé par l'entreprise
Telnet.
1.2.2 Objectif du projet
Ce projet, intitulé développement d'une plateforme de gestion de sprint et de partage
de connaissances , a pour objectif de développer une plateforme complète pour la gestion
de projet. Cette plateforme doit se baser sur les principes de Scrum et répondre aux besoins
exprimés par Telnet. Elle doit assurer à la fois l'aspect de gestion de projet et l'aspect
interactif qui permettra de faciliter la communication et l'échange entre les membres d'une
équipe. Elle doit aussi être utilisable à la fois par le chef de projet et par les membres
de l'équipe. Dans le cadre d'un projet, ces deux acteurs collaborent ensemble et s'auto-
organisent pour garantir le bon déroulement du projet tout en bénéciant des services
oerts par l'application.
1.3 Méthodologie de travail
Durant sa réalisation, tout projet nécessite une méthode de gestion qui s'assure de son
bon déroulement dans les délais et en respectant les besoins exprimés. Pour les projets
de longue durée, il est courant que les besoins évoluent au court du temps. Il est donc
important de garder un contact fréquent avec le client et lui fournir un livrable des fonc-
tionnalités réalisées après chaque itération du projet. Ceci permettra de valider le produit
dans son état actuel, ou bien de dénir les évolutions souhaitées avant d'avancer dans le
projet. C'est pour cela que la méthodologie agile Scrum présente l'une des méthodologies
les plus utilisés.
Vu que la méthodologie Scrum est celle utilisée par Telnet pour la gestion de ses projets,
nous avons choisi cette méthodologie pour la gestion de notre projet de n d'étude.
D'une manière générale, Scrum est un processus agile qui permet de produire la plus
grande valeur métier dans la durée la plus courte. Il permet de développer un logiciel de
16

manière incrémentale et itérative avec des livraisons très fréquentes; le client reçoit un
logiciel à chaque itération. Ainsi, les évolutions peuvent être facilement intégrées.
La méthode Scrum utilise une planication à trois niveaux : projet, release et sprint
(Figure 1).
Figure 1 Le cycle de vie d'un projet géré selon la méthode Scrum
Pour notre projet, nous avons décomposé le travail en des sprints (itérations) directe-
ment sans dénir les release. C'est ainsi que procède Telnet dans son travail; elle décom-
pose ses projets en des sprints directement. Nous décrivons cette décomposition en sprints
à la n du chapitre trois après la dénition des fonctionnalités du produit à réaliser.
Une réunion avec l'encadreur de l'entreprise est organisée à la n de chaque sprint.
Pendant cette réunion, nous faisons une démonstration des fonctionnalités réalisées durant
cette itération. L'encadreur, qui joue le rôle du client, valide ce livrable et exprime les
points à améliorer. Le besoin peut ainsi évoluer et les évolutions seront planiées pour le
sprint suivant.
Conclusion
Dans ce chapitre, nous avons dénit l'objectif du projet à savoir le développement
d'un outil de gestion de projet. Nous avons aussi situé le projet dans son contexte géné-
ral : organisme d'accueil, cadre de la mise en place du projet et méthodologie de gestion
adoptée.
L'objectif du projet étant dénit, il fallait faire une étude préalable qui permettra de
recenser l'existant (les solutions déjà mises en oeuvre dans l'entreprise) et de dégager les
besoins notamment en termes de fonctionnalités nouvelles. Cette étude fera l'objet du
chapitre suivant.
17

CHAPITRE
2 Etude préalable
Introduction
Dans le cadre de la gestion de ses projets, l'équipe Telnet a choisi d'adopter la métho-
dologie Scrum (avec une adaptation à leurs besoins). Sans utiliser aucun logiciel spécique
de Scrum, la méthode de Telnet se base essentiellement sur l'utilisation des chiers Excel
et les diérentes tâches se font manuellement. Dans ce chapitre, nous présentons tout
d'abord la méthodologie Agile Scrum. Ensuite, nous analysons la méthode de gestion de
projet actuelle de Telnet d'une part, et faisons un inventaire des outils de Scrum existants
d'une autre part. Cette étude nous permettra d'évaluer les limites de la méthode de tra-
vail de Telnet, et les limites de chaque outil existant par rapport à leurs besoins, an de
proposer un outil qui répondra mieux à leurs attentes.
2.1 Méthodologie Agile Scrum
La méthodologie SCRUM est une méthodologie Agile, qui permet à une équipe de
collaborer pour atteindre un objectif commun dans un cycle itératif. Le terme SCRUM
est issu du terme mêlée , Rugby en anglais; il signie le fait d'avancer ensemble
vers un but commun. Le vocabulaire de Scrum est en langue anglaise à la base, donc, tout
au long du rapport nous utiliserons les termes tels qu'ils le sont en anglais.
Chaque itération dans SCRUM est présentée par un Sprint d'une durée de 2 à 4
semaines. À la n de chaque sprint, un logiciel opérationnel doit être livré au client pour
décider soit de le livrer dans l'état, soit de continuer à l'améliorer pendant le sprint suivant.
Dans cette section, nous décrivons la méthodologie Scrum en présentant ses principes,
ses acteurs, ses outils de base, les cérémonies mises en place et les estimations utilisés.
I Les principes de SCRUM
La méthodologie Scrum se base sur les principes suivants [9] :
− C'est une méthode itérative et incrémentale
− A la n de chaque itération, un ensemble de fonctions en état de marche est
livrées.
18

Chapitre 2. Etude préalable
− Au début de chaque Sprint, l'équipe SCRUM s'engage sur la réalisation d'un
certain nombre de fonctions durant le Sprint. Celles-ci sont renseignées dans le
BACKLOG de SPRINT qui décrit les tâches sous forme de liste de tâches à
réaliser.
− La méthodologie SCRUM nécessite souvent un contact avec le client.
I Les rôles de Scrum
Dans un projet se basant sur la méthodologie SCRUM, trois rôles principaux sont
présents.
Le premier rôle est le directeur de produit (Product owner). C'est le représentant des
clients; il se pose souvent la question : Quel sont les fonctionnalités qui ont le plus de
valeur pour l'utilisateur nal?. Il doit être capable de répondre aux interrogations
des membres de l'équipe concernant le produit nal [3]. An de valider le livrable de
chaque sprint, le product owner doit participer aux réunions de n de sprint dans
lesquelles une démonstration du produit livré est présentée.
Le second rôle est le facilitateur de processus (Scrum Master). Jouant le rôle de l'ani-
mateur de l'équipe, il veille à ce que chaque membre de l'équipe puisse travailler
dans les meilleures conditions en éliminant les obstacles et perturbations. Il se pose
constamment la question : Comment faire pour y arriver à livrer ce qui est demandé
dans les délais impartis?. Il organise et anime les réunions qui présentent les céré-
monies de SCRUM (scrum quotidien, planication du sprint, rétrospective et revue
de sprint).
Le troisième rôle est l'Equipe. Il s'agit d'un groupe de personnes qui collaborent
ensemble pour la mise en place d'un objectif commun. L'équipe réunit les diérents
rôles d'un projet, à savoir le développeur, le concepteur, l'architecte,...Une équipe de
SCRUM est capable de s'auto-diriger et s'auto-organiser tout au long du sprint.
Un autre rôle peut être présent dans un projet basé sur Scrum, c'est celui des inter-
venants. Les intervenants présentent toutes les personnes qui sont intéressées par le
projet. Ils peuvent assister aux réunions mais sans déranger l'équipe [2]
I Les outils de base de Scrum
Lors de la mise en oeuvre de la méthode de SCRUM, les acteurs du projet utilisent
principalement trois outils.
Le premier outil est le journal produit (Backlog produit) : il s'agit d'une liste
évolutive des éléments fonctionnels à implémenter. Chaque fonctionnalité de la liste
possède une priorité. Les éléments de la liste peuvent évoluer au cours du projet.
Cette liste est sous la responsabilité du directeur de produit the product owner .
Le deuxième outil est le Backlog de Sprint : il présente la liste des activités à
faire durant un sprint. Cette liste est sous la responsabilité de l'équipe. Le backlog
de sprint est généralement représenté sous forme de tableau blanc avec trois colonnes
(Figure 2) : une première pour les tâches prévues, une deuxième colonne pour les
tâches en cours de réalisation et une autre pour les tâches terminées. L'avancement
19

d'une tâche donne lieu à une mise à jour du backlog de sprint et détermine ainsi ce
qui reste à faire pour la tâche en question.
Figure 2 Exemple de backlog de sprint
De plus, les tâches du backlog sont représentées sous forme de post-it (Figure3). Cette
représentation permet une visibilité meilleure et une gestion facile des tâches et de
leurs déplacements dans le tableau du backlog de sprint.
Figure 3 Exemple de Post-it
Le troisième outil est la courbe de Reste à faire (Burndown Chart) : Cette courbe
représente le reste à faire au fur et à mesure de l'avancement du sprint. Elle est mise
à jour quotidiennement.
I Les cérémonies de Scrum
Dans le but de garantir une bonne collaboration entre les diérents acteurs du projet,
et an de fournir les moyens de communication et d'auto-organisation, un ensemble
de cérémonies est mis en place tout au long du projet.
La première cérémonie est le Scrum quotidien (Scrum meeting) : c'est une réunion
de quinze minutes qui a lieu chaque jour pendant laquelle chaque intervenant (ayant
l'un des trois rôles dénis précédemment) doit répondre à ces questions :
− Qu'ai-je fais depuis le dernier scrum meeting ?
− Qu'est-ce que je vais faire jusqu'au prochain scrum meeting?
− Ai-je rencontré des problèmes?
20

Cette réunion a donc un aspect informatif, chaque intervenant informe ces collègues
de l'avancement de son travail et des obstacles qu'il a rencontrés.
La seconde cérémonie est la planication du sprint : cette réunion a lieu au début de
chaque sprint. Au cours de laquelle, les intervenants dénissent les fonctionnalités à
réaliser pendant le sprint suivant. Ils préparent par la suite le backlog (journal) du
Sprint.
La troisième cérémonie est la revue de sprint : la cérémonie revue de sprint est
organisée à la n de chaque sprint. Elle permet de faire une démonstration des fonc-
tionnalités réalisées au cours du sprint.
La quatrième cérémonie est la rétrospective de sprint : cette dernière réunion a lieu
également à la n de chaque sprint. Elle a pour objectif de spécier ce qui a bien
marché durant le dernier sprint, et ce qui n'a pas marché. Elle sert à planier des
améliorations pour le sprint suivant.
L'image suivante (Figure 4) est un schéma qui illustre le processus de travail de
SCRUM, elle résume les artefacts et les réunions de SCRUM.
Figure 4 Processus de travail de Scrum
I Les estimations de Scrum
La méthodologie Scrum fait appel à deux notions pour l'estimation de la valeur (ou
bien la charge nécessaire) à chaque fonctionnalité. Ces deux notions sont : Story point
et Vélocité.
Story Point permet d'estimer l'eort nécessaire à une équipe pour implémenter une
fonctionnalité. Cette estimation prend en compte [5] :
21

− l'eort pour le développement
− la complexité du développement
− Le risque / l'inconnu
Cette estimation se fait en valeur relative. Le recours dans Scrum à une estimation en
points au lieu du temps est dû au fait que le temps varie en fonction de la taille et de
l'expérience de l'équipe. En d'autres termes, un développeur Junior peut estimer une
tâche à trois jours alors qu'un développeur ayant plus d'expérience (ou plus ancien
sur le projet) estimera la même tâche à une journée de travail [5].
L'estimation des fonctionnalités en Story point se fait lors d'une réunion appelée
Planning Poker. Au cours de cette réunion, les fonctionnalités sont exposées une par
une, tous les membres de l'équipe donnent leurs estimations en même temps sur
la complexité d'une fonctionnalité, puis ils se mettent d'accord sur une valeur de
l'estimation.
La Vélocité s'exprime par le nombre de points d'histoires (Story point) nis pendant
un sprint. Cette mesure peut aider par la suite à estimer la capacité de l'équipe
pour les prochaines itérations. Elle permet aussi de déduire le nombre d'itérations
théoriquement nécessaires pour livrer l'ensemble des fonctionnalités du produit.
2.2 Méthode de gestion de projet dans Telnet
Dans cette section, nous présentons une étude de la méthode de travail adoptée par
l'équipe de Telnet pour la gestion de ses projets. Nous analysons par la suite cette méthode,
et nous la comparons aux principes et au processus de la méthodologie Scrum. Cette
comparaison permet de vérier à quel degré la méthode adoptée par Telnet respecte la
méthodologie Scrum.
2.2.1 Gestion de projet dans Telnet
Telnet utilise la méthodologie Agile Scrum pour la gestion de ses projets. Généra-
lement, elle décompose le projet en Sprints de durée d'une semaine. Durant un sprint,
l'équipe de Telnet prépare trois chiers principaux pour présenter les artefacts de Scrum :
− un chier qui présente le Backlog de sprint
− un chier pour la planication d'un sprint
− un chier destiné à fournir des statistiques sous forme de graphes sur le déroulement
du sprint.
Ces trois chiers sont des chiers Excel qui sont préparés manuellement par le chef
de projet. Le chier de Backlog (voir Figure 5) de sprint est préparé au début de chaque
sprint. Il contient les intitulés des tâches, la charge prévue pour chaque tâche, la charge
22

réalisé, le statut et un commentaire s'il y en a. La charge réalisée et le statut sont à remplir
à la n du sprint lors d'une réunion de n de Sprint.
Figure 5 Exemple de chier Backlog d'un projet chez Telnet
Le deuxième chier correspondant à la planication de sprint permet de lister les tâches
à réaliser pendant le sprint, à spécier la ressource aectée à chaque tâche et à introduire
l'avancement quotidien dans la réalisation d'une tâche 6.
Figure 6 Exemple de chier Planication de sprint d'un projet chez Telnet
La diérence entre le chier Backlog de sprint et le chier de planication de Sprint
réside dans le fait que le premier chier est utile au début et à la n du sprint, alors que
le deuxième chier suit l'avancement du travail au cours du sprint. Le chier du Backlog
de sprint contient les tâches à réaliser pendant le sprint, sans les détails de réalisation
et d'avancement; il est destiné au représentant du client qui n'est pas supposé savoir
les détails du travail et de l'avancement au cours du sprint. Par contre, le chier de
planication de sprint contient les tâches du Backlog, mais aectées à des ressources,
planiées avec une date de début et de n, et contient l'avancement au cours du sprint.
Ce chier est destiné aux membres de l'équipe, non pas au client.
Enn, le troisième chier qui présente les graphes de performance des sprints est pré-
paré à la n de chaque sprint. Il donne, à travers des courbes et des graphes, une idée
sur le travail réalisé, sur le travail reporté ou à reprendre, sur les objectifs non atteints et
fournit d'autres statistiques qui servent à évaluer la performance de l'équipe pendant le
sprint. Ce chier est proposé par l'équipe de Telnet et contient quatre graphiques :
− le premier représente la performance du sprint, il expose le travail réalisé, le travail
à reprendre et les objectifs non atteints (Figure7)
23

− le deuxième montre l'ensemble du travail à refaire pour chaque sprint.
− le troisième est une courbe qui illustre le cumul du travail réalisé. Elle est intitulé
Backlog Burnout
− le quatrième graphique résume la performance de l'équipe au cours du sprint, la
performance de la planication, et la performance globale de Telnet.
Figure 7 Exemple de chier de performance Scrum d'un projet chez Telnet
An de collaborer ensemble et an de s'informer de l'avancement de chaque membre,
l'équipe se réunie chaque jour pour une durée de 15 minutes dans le cadre de la réunion
de Scrum connue par Scrum quotidien. La réunion a lieu au même endroit et à la même
heure. Pendant cette réunion, les membres de l'équipe répondent aux questions suivantes :
− sur quoi ai-je travaillé hier?
− sur quoi je vais travailler aujourd'hui?
− Ai-je rencontré des problèmes?
− Quelle est mon pourcentage d'avancement sur la tâche?
− Que reste-t-il à faire pour ma tâche?
24

A la n de chaque sprint, une réunion est organisée entre les diérents acteurs de
l'équipe. Puisque chaque sprint débute le Mardi et dure une semaine, cette réunion a lieu
chaque Mardi matin. Pendant la réunion, une démonstration des tâches faites pendant le
sprint précédent est faite. Le chef de projet cherche à analyser, avec l'aide des membres
de l'équipe, ce qui a bien marché pendant le sprint précédent et ce qui peut être amélioré
pour le sprint suivant.
De plus, le chef de projet remplie à la main les colonnes de la charge réalisée et du
statut de chaque tâche dans le chier Backlog du sprint précédent. Il prépare, par la
suite, le chier backlog du nouveau sprint et aecte les tâches aux ressources selon le
chier Backlog déjà préparé et selon les congés des membres de l'équipe. Le remplissage
et la préparation de ces chiers se font manuellement et nécessite de la réexion de la part
du chef de projet.
2.2.2 Analyse de la méthode de gestion de projet de Telnet
La gestion de projet chez Telnet se base sur la méthodologie Scrum. Le projet est
décomposé en des sprints d'une semaine chacun. Les membres de l'équipe travaillent dans
un cycle itératif et incrémental et fournissent à la n de chaque sprint un ensemble de
fonctionnalités. Ils travaillent dans un esprit collaboratif et font des réunions quotidiennes
ce qui leurs facilitent le partage d'information.
Ces acteurs utilisent aussi des artefacts pour la méthodologie de gestion de projet avec
la mise en place des trois chiers cités dans le paragraphe précédent : le Backlog, la plani-
cation de Sprint et la performance du sprint. La préparation de ces chiers Excel se fait
manuellement et il est souvent dicile de manipuler ces chiers pour diérentes raisons.
D'une part, cette méthode ne permet pas de contrôler l'accès aux chiers; l'utilisateur
peut aussi bien modier les données relatives à ses propres tâches (avancement, statut)
que celles de ses collègues, ce qui peut perturber le bon déroulement du projet. An d'évi-
ter ce problème, le chef de projet peut, lui-même, saisir l'avancement des membres de
ses équipes dans les chiers Excel. Au cours de la réunion quotidienne Daily Scrum ,
il doit alors récupérer les pourcentages d'avancement de chaque membre pour les saisir
ultérieurement dans le chier Excel ce qui n'est pas du tout pratique.
D'autre part, la gestion simultanée de trois chiers Excel n'est pas toujours facile sur-
tout s'ils contiennent des données liées, la mise à jour d'un chier nécessite la mise à jour
des autres chiers. De plus, la gestion de chiers comprend de nombreux risques. L'utili-
sateur peut oublier de sauvegarder les modications ou bien supprimer une information
sans s'en rendre compte. Il peut aussi être obligé d'examiner tous les chiers enregistrés
pour trouver une information ancienne.
Enn, le Reporting dans Excel nécessite une maîtrise de l'outil, il est nécessaire
de saisir manuellement toutes les données d'entrées ainsi que les équations des diérentes
courbes,... Même si cette opération ne se fait qu'une seule fois au début de chaque projet,
elle reste néanmoins peu pratique en la comparant à ce que Scrum ore comme outils
spécialisés, ces outils créent automatiquement plusieurs graphiques sans aucun eort de
25

la part de l'utilisateur.
Contrairement à ce que propose la méthodologie Scrum, la présentation des tâches
d'un sprint chez Telnet ne se fait pas par un tableau blanc avec des post-it. Les tâches
sont simplement énumérées dans un chier Excel, alors que la présentation sous forme de
post-it fournit une meilleure lisibilité, et une manipulation plus facile des tâches.
L'aectation des tâches aux ressources humaines de l'équipe se fait par le chef de projet.
Ce dernier répartit les tâches dans l'équipe en examinant deux chiers principaux : le cher
Backlog de sprint pour sélectionner les tâches à réaliser et le chier de planication des
congés pour vérier la disponibilité d'un membre de l'équipe pour la réalisation d'une
tâche à une date spécique. Cette méthode n'est cependant pas toujours able, le chef de
projet peut commettre des erreurs en aectant une tâche deux fois, ou bien en choisissant
une ressource qui est en congé ou qui possède déjà une autre tâche à la même date.
Enn, malgré les réunions quotidiennes organisées tout au long du projet, l'interactivité
entre les membres d'une équipe reste faible dans la mesure où si un problème survient, le
développeur doit attendre la réunion suivante pour provoquer le problème. Ce temps perdu
pourra être évité grâce à un forum; l'utilisateur pourra alors évoquer son problème et
trouver une solution sans être bloqué dans son travail. De plus, si la réalisation d'une tâche
nécessite que la tâche précédente soit nie, l'utilisateur peut être notié instantanément
sans être obligé d'attendre la prochaine réunion pour être informé.
2.2.3 Comparaison avec Scrum
Après avoir analysé la méthode de gestion de projet chez Telnet, nous la comparons
dans ce qui suit avec les artefacts et principes de Scrum.
Telnet utilise une version modié de Scrum qu'elle adapte à ses besoins, la méthodo-
logie de gestion de projet de Telnet respecte les principes de Scrum mais les rôles, les
artefacts et les cérémonies sont légèrement modiés.
Les principes se Scrum sont respectés par Telnet dans la mesure où le projet est
décomposé en sprints et la gestion du projet suit un cycle itératif et incrémental. De plus,
à la n de chaque sprint, l'équipe fournit un ensemble de fonctionnalités et le chef de
projet garde un contact continu avec le client.
Les rôles intervenant dans l'équipe Telnet sont le chef de projet qui représente le
Scrum master, le client dans le rôle de Product Owner et les autres acteurs comme les
développeurs, les testeurs et les architectes qui jouent le rôle de l'Equipe (Tableau I).
Rôle de Scrum Rôle chez Telnet
Scrum Master Le chef de projet
Product Owner Le client
Equipe développeurs, testeurs, architectes,...
Tableau I Comparaison entre les rôles de Scrum et les rôles chez Telnet
En ce qui concerne les artefacts de Scrum, nous avons déjà mentionné dans la pré-
26

sentation de la méthodologie de Scrum, que cette méthodologie fournit trois artefacts
principaux :
− le Backlog Produit : la liste de toutes les tâches du projet
− Le backlog Sprint : liste des tâches à réaliser pour un sprint
− Burndown chart : courbe du reste à faire
Telnet ne dénit pas de Backlog produit (ne fait pas une liste de toutes les tâches du
projet), mais dénit les tâches de chaque sprint en fonction du résultat du sprint précédent
jusqu'à atteindre les objectifs du projet. De ce fait, le chier Backlog qu'elle prépare est
celui du Backlog de sprint.
L'artefact de Burndown chart n'est pas présent dans la méthode de Telnet. Cependant,
elle fournit un chier de Performance Scrum qui contient un ensemble de graphiques
qui évaluent la performance de l'équipe pendant le sprint (voir paragraphe Gestion de
projet dans Telnet).
Comme dernier artefact, Telnet utilise le chier de planication de sprint, qui montre
les ressources aectées aux tâches et présente l'avancement de l'équipe durant le sprint.
Dans la méthodologie Scrum, chaque sprint contient quatre réunions appelées cérémonies.
Ces cérémonies sont : Scrum quotidien, planication de sprint, revue de sprint et la rétros-
pective. L'équipe de Telnet n'organise que deux réunions : la réunion journalière connue
dans Scrum sous le nom de Scrum quotidien, et la réunion de n de sprint qui remplace
les trois autres réunions (la planication de sprint, la revue de sprint et la rétrospective).
Le tableau II résume les cérémonies de Scrum et leurs équivalents dans la méthode de
Telnet.
Cérémonies
de Scrum
Fréquence Objectif Cérémonies chez Telnet
Scrum quoti-
dien
Chaque jour
Informations sur l'avancement quo-
tidien.
Réunion de 15 minutes chaque
jour à 12h15min.
Planication
du sprint
Avant
chaque
sprint
Dénition des fonctionnalités à réa-
liser pendant le nouveau sprint.
Réunion qui se déroule
chaque mardi, au début du
nouveau sprint. Elle sert à
remplir le backlog du sprint
précédent, préparer le backlog
du nouveau sprint, et aecter
les tâches aux ressources.
Revue de
sprint
A la n du
sprint
- Démonstration du produit
- Mesure de l'avancement du projet
Rétrospective
A la n du
sprint
Réexion sur le processus de travail :
- Qu'est-ce qui fonctionne bien?
- Qu'est-ce qui peut être amélioré?
TableauII Comparaison des cérémonies utilisées dans Telnet avec les cérémonies
de Scrum
Enn, en ce qui concerne les méthodes d'estimations de tâches dénies dans Scrum,
nous avons vu que Scrum fournit deux types d'estimations : Story points qui représente
une estimation de l'eort nécessaire pour implémenter une tâche, vélocité qui représente
la mesure de la somme de points réalisés par une équipe pendant un sprint.
27

Nous présentons, à travers le tableau suivant (Tableau III), une comparaison entre
Scrum et la méthode de Telnet concernant ces estimations.
Estimation Scrum Méthode de Telnet
- Une fonctionnalité est estimée en Story
points qui est d'unité relative, prise selon un
intervalle déni par l'équipe.
- Une fonctionnalité est estimée en jour (le
nombre de jour nécessaire pour nir la tâche).
Cette valeur représente la charge estimée.
- La vélocité se calcule en additionnant les
Story points des tâches nies pendant un
sprint.
- La vélocité est calculée en additionnant l'en-
semble des charges estimées des tâches nies
pendant le sprint.
- Elle est exprimée en valeur relative - Elle est exprimée en jours.
Tableau III Comparaison des estimations de Scrum aux estimations utilisées
dans Telnet
Nous observons, d'après le tableau II, que Telnet recourt à l'estimation les fonction-
nalités en jours et non pas en valeur relative.
2.3 Inventaire des logiciels de gestion de projet exis-
tants
An d'avoir une vision globale sur les outils SCRUM, nous avons choisi d'exposer
quelques outils payants et outils gratuits parmi les plus connus et les plus utilisés sur le
marché. On se propose d'étudier les caractéristiques et les avantages et inconvénients de
chaque outil. Nous analysons, par la suite, l'adaptabilité de chaque outil à la méthode de
gestion de projet utilisée par Telnet.
2.3.1 Outils payants
I Mingle
Mingle se caractérise par une présentation hiérarchique des tâches et une présentation
arborescente des itérations (ou sprints), ce qui rend la compréhension du plan de
projet très facile. Il fournit un tableau de bord qui est connu dans SCRUM par un
mur de cartes : ce mur expose l'ensemble des tâches du projet, chaque tâche est
présentée sous forme d'une carte (post-it) multidimensionnelle (une dimension pour
la face de la carte, une dimension pour le dos); ces cartes peuvent être déplacées
dans le tableau de bord pour modier l'état de la tâche correspondante (tâche en
cours, tâche nie,..). [18]. De plus, l'outil Mingle fournit des rapports et des graphes
ce qui permet de donner une bonne visibilité de l'avancement du projet. Enn, cet
outil permet de partager des conversations entre les utilisateurs et de les capturer; il
permet aussi le partage d'information via des alertes envoyées par mail. Mingle est
un outil payant, il coute 240$ USD par année et par utilisateur. Les points forts et
les points faibles de l'outil Mingle sont récapitulés dans le tableau IV.
28

Les points forts Les points faibles
- Présentation des tâches sous forme de ta-
bleau de bord similaire au tableau proposé
par Scrum. .
- Pas de fonctionnalité de suivi des problèmes
(Bugs Tracking)
- Gestion des tâches facile grâce l'utilisation
du glisser-déplacer.
- Pas de module de gestion des ressources.
- Possibilité de suivre ce que les membres de
l'équipe font via des e-mails
Tableau IV Points forts et points faibles de Mingle
Adaptabilité de l'outil aux besoins de Telnet :
Mingle peut répondre au besoin de Telnet dans la mesure où il fournit un outil qui
contient un tableau blanc pour la présentation des tâches sous forme de post-it et qu'il
est possible de manipuler ces tâches avec un simple glisser-déplacer. Il contient aussi
un forum de discussion comme le souhaite l'équipe de Telnet. Cependant, Telnet
souhaite avoir un outil qui soit gratuit et qui ne nécessite pas de payer les frais
d'utilisation à chaque mois et pour chaque utilisateur.
I Pivotal Tracker
Comme Mingle, l'outil Pivotal Tracker fournit une présentation des tâches selon trois
blocks : un block qui contient les tâches qu'il serait possible de réaliser, un block qui
contient les tâches en attentes et un dernier block qui contient les tâches à réaliser.
Mais la présentation des tâches n'est pas sous forme de post-it comme le cas de
Mingle. Pivotal Tracker permet de suivre les tâches en cours d'un membre de l'équipe.
Il permet aussi d'exporter des chiers csv par projet, par membre et selon divers
critères. De plus, l'outil fournit un ensemble riche de fonctionnalité pour le calcul de
vélocité dans le cadre de l'estimation des poids des tâches [11].
− Possibilité d'exporter des chiers CSV
− Plusieurs fonctionnalités de calcul de
vélocité.
− Gestion des rôles des utilisateurs
− Possibilité pour l'utilisateur d'acher
ses propres tâches
− Backlog n'est pas similaire à un backlog
réel (tableau de bord avec des post-it)
− Les tâches ne sont pas représentées par
des post-it.
Tableau V Points forts et points faibles de Pivotal Tracker
Comme fonctionnalité primordiale de l'outil attendu, Telnet exige que l'outil fournisse
un tableau blanc pour la présentation des tâches, que ces tâches soient présentées
29

sous forme de post-it et qu'on puisse les glisser facilement d'une colonne à une autre.
Malheureusement, Pivotal Tracker ne permet pas une telle présentation. De plus, cet
outil est coûteux (payant)(Tableau VI).
2.3.2 Outils gratuits
I IceScrum
Etant le plus connu des outils gratuits, IceScrum représente les tâches d'une itération
(ou sprint) sous forme d'un tableau blanc permettant de glisser et déplacer les tâches
d'une colonne à une autre. Dans le tableau blanc, les tâches sont représentées sous
forme de Post-it. IceScrum fournit un ensemble riche de fonctionnalités qu'on peut
appliquer à une tâche. Ces fonctionnalités sont accessibles via un clic droit sur le post-
it de la tâche. L'utilisation de ce menu n'est pas intuitive puisque le menu n'est visible
qu'à travers un clic droit, ce qui peut être dicile à remarquer par l'utilisateur. La
gestion de rôles est aussi présente dans cet outil : les utilisateurs d'IceScrum peuvent
avoir l'un des rôles Scrum (Product Owner, Scrum Master, membre de l'équipe, les
intervenants). Ainsi, des rôles personnalisés peuvent être créés [4].
− Riche en fonctionnalités
− Backlog de sprint ressemble à un ta-
bleau de bord réel avec des post-it
− Prise en charge le classement des stries
selon l'état d'avancement (en cours, à
faire, nie) par le glisser-déplacer et les
estimations de points du Stor.
− Certaines fonctionnalités ne sont pas
intuitives. Le menu contextuel du clic
droit n'est pas évident, mais il est fa-
cile à utiliser une fois que l'utilisateur le
découvre.
− n'est pas adapté pour les grands projets
où plusieurs équipes travaillant sur un
seul produit. En eet, l'outil ne permet
qu'à un seul Release et un seul
Sprint d'être actif à la fois.
Tableau VI Points forts et points faibles d'IceScrum
Parmi les fonctionnalités que doit fournir l'outil de gestion de projet basé sur Scrum,
Telnet exige un forum intégré dans l'outil pour faciliter le partage de connaissances
et les discussions à distance. Cependant, IceScrum ne fournit pas un tel forum, il ne
peut donc pas être choisi.
I Agilefant
Agilefant est un outil de gestion de projet gratuit; Il s'eorce d'être aussi simple que
possible. Il fournit un ensemble riche de fonctionnalités. Il expose une vue du travail
quotidien d'un utilisateur, lui permettant de placer et de hiérarchiser ses tâches.
30

Agilefant dispose d'un système intégré de suivi du temps et de l'avancement. Il permet
la génération de rapports; le contenu de ces rapports peut être exporté dans un
chier Excel. Cet outil expose une vue du Backlog sur 3 niveaux : produit, version
(release) et itération. Il est mieux adapté pour les grands projets multi-équipes avec
les produits de longue durée; Cependant, il manque la fonction d'hiérarchisation des
stories (tâches) [16].
- Riche en fonctionnalités
- Pas de drag and drop pour la réorganisa-
tion des story .
- Convient pour les grandes organisations et
projets.
- Pas de tableau des tâches similaire au ta-
bleau réel de Scrum.
- raisonnablement intuitif et facile à utiliser.
- Pas de distinction entre les rôles des utilisa-
teurs.
Tableau VII Points forts et points faibles d'Agilefant
Comme Pivotal Tracker, AgileFant ne contient pas un tableau blanc pour la pré-
sentation des tâches sous forme de post-it. Même avec la liste des User Stories qu'il
fournit, cet outil ne permet pas le glisser-déposer des tâches.
2.3.3 Récapitulatif des outils et de leurs limites
31

Outil
Coût
mensuel
Adéquation
à
Scrum
Gestion
de
Rôles
Fonctionnalité
de
Support
(Blog,
Forum,...)
Limites
par
rapport
au
besoin
de
Telnet
Etats
stan-
dards
(Ba-
cklog,
todo,
current,
done)
Décomp.
en
Sprint
Valuation
des
taches
Calcul
de
vélocité
Burn-
Down
chart
Mingle
20$
par
utilisateur
X
X
X
X
Forum
payant
Pivotal
Tracker
50$
X
X
X
X
X
X
Blog,
FAQs,
Forum
payant
Agilefant
0
Pas
de
vue
de
tableau
de
tâche,
No
drag
and
drop
×
X
X
story
points
X
×
Email,
forums
pas
de
ta-
bleau
de
bord
avec
des
post-it
IceScrum
0
X
X
X
X
X
X
Email
pas
de
Forum
Tableau
VIII

Comparaison
entre
les
rôles
de
Scrum
et
les
rôles
chez
Telnet
32

2.4 Solution proposée
Pour la gestion de ses projets, Telnet se base sur la méthodologie Scrum. Cependant,
elle n'utilise aucun outil spécialisé à Scrum, mais plutôt des chiers Excel comme arte-
facts de sa méthode. Comme nous l'avons déjà évoqué, une telle méthode a ses limites.
C'est pourquoi, Telnet décide de développer un outil basé sur les principes de Scrum qui
facilite la gestion de ses projets et qui répond à ses exigences. Parmi ces exigences, l'ou-
til doit fournir une vue de sprint sous forme de tableau blanc qui ache les tâches du
sprint sous forme de post-it déplaçables. La manipulation des post-it doit être facile et
chaque utilisateur ne peut manipuler que ses propres tâches. De plus, l'outil doit avoir un
aspect interactif; il doit permettre la réception de notications pour faciliter le partage
d'information et doit contenir un forum intégré pour permettre les discussions à distance
et l'échange de connaissances, ainsi qu'une boite de messagerie pour chaque utilisateur
authentié.
Après avoir étudié quelques outils existants de Scrum et analysé les limites de chaque
outil, nous avons constaté que chaque outil possède un inconvénient majeur qui l'empêche
de répondre aux besoins et aux exigences de Telnet. De plus, bien qu'elle se base sur
les principes de Scrum, la méthode de gestion de projet ne respecte pas parfaitement les
artefacts de Scrum et de ce fait, aucun des outils existants de Scrum ne peut être appliqué
à la méthode de Telnet.
An de répondre aux exigences de Telnet, nous allons donc proposer un outil pour
la gestion de ses projets. Cet outil doit se baser sur les principes de Scrum et doit être
conforme aux artefacts utilisés par Telnet. Il doit faciliter les tâches du chef de projet et
automatiser certaines actions comme le remplissage du chier Backlog à la n du sprint
et la vérication de la disponibilité des ressources. Les graphes de performance du sprint
et de l'équipe seront générés automatiquement, et pourront être exportés à la demande.
L'outil proposé doit aussi être interactif; il doit fournir, à toute l'équipe, un environnement
favorable pour échanger les informations et les connaissances.
Conclusion
Dans ce chapitre, nous avons étudié la méthodologie de gestion de projet adoptée par
Telnet. Nous avons mis l'accent sur les diérentes problématiques de cette méthode. Nous
avons de plus présenté un ensemble d'outils de Scrum existants sur le marché et nous
avons exposé pour chaque outil ses limites par rapport aux besoins exprimés par Telnet.
Cette étude a permis d'exprimer le besoin de Telnet qui consiste à développer son propre
outil de gestion de projet.
Dans le chapitre suivant, nous développons l'analyse de besoins fonctionnels et non
fonctionnels du produit à réaliser.
33

CHAPITRE
3 Spécication des besoins
Introduction
Avant le développement de tout logiciel, il fallait dénir le périmètre du projet en cou-
vrant les fonctionnalités attendues par l'utilisateur. Dans ce contexte, ce chapitre a pour
but d'analyser les besoins fonctionnels et non fonctionnels de notre projet. Nous dénis-
sons d'abord les besoins de notre application sous forme textuelle et nous les modélisons
par la suite par des diagrammes UML.
3.1 Analyse des besoins
Dans cette partie, nous présentons les besoins que doit satisfaire notre application Web.
D'abord, nous identions les acteurs du système, puis, nous exposons les spécications
fonctionnelles et non fonctionnelles de notre application.
3.1.1 Identication des acteurs
L'application que nous allons réaliser est une plateforme Web. L'utilisateur doit être
authentié an d'accéder à la plateforme. Il doit avoir l'un des rôles suivants :
− Chef de projet : Cet acteur est chargé de mener un projet et de gérer son bon
déroulement. Il possède plus de privilèges que les autres acteurs sans pour autant
avoir tous les droits dans l'application.
− Développeur : cet acteur est un membre d'une équipe spécique. Il peut être un déve-
loppeur, un testeur, un architecte, un responsable technique,... par abus de langage :
développeur.
− Administrateur : son rôle consiste uniquement à nommer les chefs de projets dans
l'application et il est le seul à avoir ce droit. De ce fait, il n'apparaît pas comme
acteur principal.
3.1.2 Besoins fonctionnels
L'application fournira aux utilisateurs quatre modules :
34

Chapitre 3. Spécication des besoins
− Gestion de projet
− Gestion de ressources
− Gestion et suivi de sprint
− Partage d'informations et de connaissances
Tous les acteurs n'ont pas accès à tous les modules. Le schéma suivant ( Figure 8)
décrit la participation de chaque acteur aux modules fournis par l'application.
Figure 8 Participation des acteurs aux modules fournis par l'application
Nous commençons par présenter chaque module puis nous détaillons ses fonctionnali-
tés.
3.1.2.1 Gestion de projet
Ce module est spécique au chef de projet. Ce dernier peut gérer uniquement les
projets qu'il dirige, il peut aussi créer de nouveaux projets.
Ce module est primordial dans la mesure où les trois autres modules nécessitent la
mise en place d'un cadre général dans lequel s'organisent les ressources et se partagent les
informations.
Seul le chef de projet a le droit d'accès à ce module, il peut ainsi :
− Créer un nouveau projet
− Ajouter des ressources à un projet
− Gérer un projet créé auparavant
• Il peut ajouter, au cours du projet, une nouvelle ressource
35

• Il peut enlever, au cours du projet, une ressource
• Il peut modier les paramètres du projet (son nom, sa description, ses dates de
début et de n). - Clôturer un projet.
3.1.2.2 Gestion de ressources
Ce module concerne la gestion de ressources humaines. Il représente l'ensemble de
pratiques que notre application met en place pour administrer et organiser les personnels
participants aux projets. Les trois acteurs (chef de projet, développeur et administrateur)
ont accès à ce module. Le module concerne l'ajout de nouvelles ressources, la planication
des congés et la gestion des informations relatives aux ressources. Le chef de projet joue le
rôle de gestionnaire des ressources humaines de ses projets. Le développeur, quand à lui,
a la capacité de consulter ses congés et ses informations personnelles avec la possibilité
de modier ces informations.
L'administrateur s'occupe de l'ajout des chefs de projet à l'application. A leur tour,
les chefs de projet vont ajouter de nouveaux développeurs lors de la création des projets.
En plus des informations de connexions et de prols liés à l'application, Telnet doit
être capable de gérer les coordonnées de connexion des membres des équipes dans d'autres
environnements de travail externes à l'application tel que l'outil de gestion de versions
SVN, l'outil Europe, Sun,... Le chef de projet a besoin, dans certains cas, d'accéder au
prol d'une ressource dans un de ces environnements an de voir son avancement, son
travail,... Pour faciliter l'acquisition des identiants d'une ressource dans un environne-
ment externe quelconque, il est souhaitable que notre application fournisse un espace dans
lequel le chef de projet puisse consulter directement ces identiants.
Une ressource doit être capable de gérer son mot de passe et son login non seulement
ceux permettant l'accès à l'application elle-même, mais aussi ceux des environnements
externes. Le chef de projet a la possibilité de saisir les login et les mots de passe des
ressources pour ces environnements externes.
Nous présentons les fonctionnalités fournies dans le cadre de ce module en les organi-
sant selon les acteurs.
− Fonctionnalités permises au chef de projet
• Consulter son prol
• Modier son mot de passe
• Enregistrer un nouveau congé
• Annuler un congé
• Visualiser tous les congés par ressource pour une semaine spécique.
• Visualiser le login et le mot de passe d'un membre de l'équipe pour un environ-
nement externe
36

• Saisir les login et les mots de passe des diérentes ressources dans tous les
environnements externes. Il peut ainsi ajouter un nouvel environnement externe
de connexion.
• Inscrire une ressource : saisir le nom et le prénom, et le système aecte automati-
quement un login et un mot de passe selon le format suivant : prénom.nom pour
le login et prno (les deux premières lettres du prénom puis les deux premières
lettres du nom) pour le mot de passe.
− Fonctionnalités permises au développeur :
• Consulter son prol
• Visualiser ses congés par semaine
• Gérer ses coordonnées de connexion des environnements externes
Saisir son login et son mot de passe dans un environnement externe
Modier son login et/ou son mot de passe dans un environnement externe
− Fonctionnalités permises à l'administrateur :
• Inscrire un chef de projet : saisir le nom et le prénom et le système aecte auto-
matiquement un login et un mot de passe selon le format suivant : prénom.nom
pour le login et prno pour le mot de passe.
3.1.2.3 Gestion et suivi de sprint
Ce module, ayant la taille la plus importante, concerne la gestion de la planication
d'une itération (Sprint) et de l'avancement tout au long du sprint. Il fournit aussi des
statistiques qui concernent aussi bien l'avancement au cours du sprint, que le résultat
obtenu à la n du sprint. Les acteurs qui se présentent dans ce module sont le chef de
projet et le développeur.
− Fonctionnalités communes au chef de projet et au développeur :
• Visualiser le chier Backlog du sprint en cours
• Exporter le chier Backlog en chier Excel
• Visualiser la planication du sprint en cours, avec les tâches sous forme de post-it
• Visualiser l'avancement quotidien de chaque tâche du sprint actuel.
• Savoir la dépendance entre les tâches.
• Visualiser les tâches bloquées
• Visualiser les statistiques au cours de sprint et en n de sprint.
37

• Exporter les graphes de statistique en chiers Excel.
− Fonctionnalités permises au chef de projet seulement :
• Créer un nouveau Backlog de sprint
• Ajouter une tâche au Backlog
• Editer ou supprimer une tâche du Backlog
• Planier le sprint
Dénir la date de début du sprint. La date de n se calcule automatiquement
à partir de la durée du sprint dénit dans les paramètres du projet
Aecter les ressources aux tâches, en fonction de la planication des congés
et des capacités des ressources
• Modier la ressource aectée à une tâche dans le cas où la tâche n'a pas débuté.
− Fonctionnalités permises au développeur seulement :
• Modier l'état de sa propre tâche en à faire , en cours ou ni . Cette
modication d'état doit être faite par un simple glisser et déposer dans l'une
des colonnes du tableau de planication de sprint.
• Saisir, quotidiennement, l'avancement de ses propres tâches en cours.
• Indiquer un état bloqué d'une tâche, saisir un commentaire pour décrire la
cause du blocage.
3.1.2.4 Partage d'informations et de connaissances
Vu le manque d'interactivité entre les membres d'une équipe, l'application développée
doit fournir un module permettant de préparer un environnement Web favorable au par-
tage d'informations et de connaissances. Cet environnement facilitera la communication
et l'échange d'idées entre les membres d'une équipe à travers un forum. Le partage d'in-
formations peut aussi être garantit par l'envoi de notications automatiques aux membres
d'une équipe suite à des évènements importants. De plus, il sera possible d'envoyer des
messages privés via une boite de messagerie propre à chaque utilisateur authentié.
Ce module ne distingue pas entre le chef de projet et les développeurs, ces acteurs ont
accès aux mêmes fonctionnalités et ont les mêmes droits. Le module ore à l'utilisateur
les fonctionnalités suivantes :
− Déclencher une discussion autour d'un problème rencontré
− Visualiser une discussion autour d'un problème pas encore clôturé.
− Commenter une discussion existante.
− Permettre au déclencheur d'une discussion d'approuver un commentaire et de le mar-
quer comme solution du problème. Il peut aussi modier le texte du commentaire
approuvé avant de le valider.
38

− Envoyer, par mail et par message dans l'application, une information à une ou plu-
sieurs membres de l'équipe.
− Eectuer une recherche avec des mots clés sur les problèmes existants et résolus.
De plus, en réponse à certaines actions des utilisateurs, l'application permet de :
− Envoyer automatiquement une notication lorsqu'une tâche atteint l'état nie
(100%). Cette notication est envoyée au chef de projet et à la ressource (développeur)
qui a la tâche suivante. Si la tâche n'a pas de dépendance temporelle avec une autre
tâche, la notication sera envoyée uniquement au chef de projet.
− Déclencher automatiquement une alerte dès qu'un nouveau problème est ouvert.
− Envoyer automatiquement une notication annonçant l'existence d'un problème ou-
vert, cette notication ne disparait que lorsque le problème est résolu.
3.1.3 Besoins non fonctionnels
− Evolutivité :
L'application doit être évolutive pour permettre facilement les améliorations et les
évolutions futures possibles.
− Performance :
Le temps de réponses aux actions des utilisateurs doit être raisonnable.
− Sécurité :
L'application doit gérer l'authentication et l'autorisation des utilisateurs. Tout uti-
lisateur voulant accéder à la plateforme doit être d'abord authentié. L'application
doit aussi gérer les rôles des utilisateurs et les privilèges associés à chaque rôle.
− Ergonomie :
Les interfaces de notre application Web doivent être intuitives, faciles à utiliser. Les
mots utilisés doivent être compréhensibles et doivent fournir les informations utiles
pour guider l'utilisateur tout au long de son utilisation de l'application Web. Les
messages d'erreur doivent être précis et clairs. L'organisation des pages doit être
cohérente et doit donner, à première vue, une idée claire sur les diérents blocs ou
espaces de la plateforme.
3.2 Modélisation des besoins
Dans cette partie, nous allons modéliser les fonctionnalités de l'application, cités au-
paravant, sous forme de diagrammes de cas d'utilisation. Nous commençons par présenter
les diagrammes de cas d'utilisation globaux, puis nous détaillons chaque diagramme par
une description textuelle ou par des diagrammes de séquence système.
39

3.2.1 Cas d'utilisation globaux
Vu le nombre important de fonctionnalités exposées par l'application, nous avons re-
groupé les cas d'utilisation en packages (gure 9). Chaque package représente un des
quatre modules cités dans le paragraphe précédent Analyse des besoins .
Figure 9 Répartition des cas d'utilisation globaux en packages
Maintenant, nous montrons le diagramme de cas d'utilisation global de chaque package.
3.2.1.1 Gestion de projet
Comme nous l'avons décrit dans une étape précédente, le module Gestion de projet
concerne la gestion des projets par les chefs responsables. Cette gestion inclut la création,
40

l'édit, la clôture des projets, ainsi que l'intégration ou l'élimination de ressources de ces
projets.
Le seul acteur qui contribue à ce module est le chef de projet.
Figure 10 Diagramme de cas d'utilisation global du package Gestion de projet

La gestion de ressources est une dimension primordiale dans l'application de gestion
de projet, elle réunit la gestion de congés, la gestion d'informations de connexions et
l'intégration des ressources à la plateforme. Le schéma suivant illustre les diérents cas
d'utilisation de ce package.
41

Figure 11 Diagramme de cas d'utilisation global du package Gestion de res-
sources
3.2.1.3 Gestion et suivi de Sprint
Etant le module principal de l'application, ce package expose un nombre important de
fonctionnalités. La Figure 12 montre que ce module fournit des fonctionnalités communes
aux chefs de projets et aux développeurs, des fonctionnalités spéciques aux chefs de
projet et d'autres spéciques aux développeurs. Comme le cas de tous les autres modules,
l'accès à ces fonctionnalités nécessite une authentication de l'utilisateur.
42

Figure
12

Diagramme
de
cas
d'utilisation
global
du
package

Gestion
de
sprint
43

3.2.1.4 Partage de connaissances et d'informations
Les fonctionnalités de ce package permettent l'échange et l'interactivité entre les
membres d'une équipe. L'acteur qui contribue à ce module est, de ce fait, l'utilisateur
en général sans distinction entre le chef du projet et le développeur.
Figure13 Diagramme de cas d'utilisation global du package Partage de connais-
sances et d'informations
3.2.2 Cas d'utilisation détaillés
Dans la partie précédente, nous avons exposé les fonctionnalités globales de l'appli-
cation. Comme nous l'avons vu, ces diagrammes comprennent un nombre important de
cas d'utilisation, nous détaillons donc, dans ce paragraphe, les cas d'utilisation les plus
importants.
3.2.2.1 Gestion de projets
La fonctionnalité la plus importante dans ce package est la création d'un nouveau
projet qui, par sa création, déclenche l'apparition de toutes les autres fonctionnalités. On
ne peut donc pas parler de gestion de projet sans projet.
44

− Cas d'utilisation : Créer un projet
Figure 14 Diagramme détaillé du cas d'utilisation Créer un projet
Acteur : Chef de projet
Préconditions :
L'utilisateur doit être authentié en tant que chef de projet.
Scénario principal :
1. Après avoir été authentié, le chef de projet accède à la page qui contient tous
les projets qu'il dirige, cette page contient un lien Ajouter un projet .
2. Le chef de projet clique sur le lien Ajouter un projet, un formulaire à remplir
lui est alors aché.
3. Il remplit les champs du formulaire (nom du projet, date de début et date de
n du projet, durée des sprints, le jour de la semaine de début d'un sprint et le
nombre de ressources).
4. En cliquant sur le bouton Ajouter, le système lui redirige vers la page d'ajout
des ressources.
5. Le chef de projet choisit les ressources qui vont participer au projet et clique
sur le bouton Valider.
Scénario alternatif A :
A l'étape 5, si le nombre de ressources ajoutés n'est pas égal au nombre de ressources
introduit dans le formulaire de création d'un projet, alors un message s'ache pour
indiquer au chef de projet que le nombre de ressources introduits n'est pas valide.
Il peut alors valider et enregistrer ce nouveau nombre, ou bien annuler et ajuster le
nombre de ressources.
Scénario alternatif B :
A l'étape 5, si le chef de projet veut ajouter une ressource qui est nouvelle et donc
n'est pas enregistrée dans l'application, il peut l'ajouter en appuyant sur un lien
Ajouter une nouvelle ressource . Ce lien lui redirige vers un autre page où il introduit
le nom et le prénom de la ressource et l'enregistre.
45

Post-conditions :
Le projet sera ajouté dans la base de données et sera aché dans la liste des projets
de l'utilisateur chef de projet authentié.
Nous détaillons quelques cas d'utilisation pour ce module.
− Cas d'utilisation : Visualiser les congés d'une ressource
Le chef de projet peut consulter les congés des ressources appartenant à ses projets.
L'achage des congés dépend de deux critères : la semaine au cours de laquelle sont
planiés les congés et les ressources participant à un projet spécique. Le chef de
projet choisit alors les valeurs de ces deux critères et en retour l'application ache
les congés des ressources.
Figure15 Diagramme de cas d'utilisation Visualiser les congés d'une ressource
Préconditions :
1. Le chef de projet accède à la page de gestion de congés.
2. Le chef de projet choisit la date par laquelle débute la semaine voulue.
3. L'application change alors les valeurs du tableau en fonction de la semaine
choisie.
4. Le chef de projet choisit le projet auquel appartiennent les ressources dont
il cherche à connaître les congés.
5. L'application modie les valeurs du tableau selon le projet choisit.
Post-conditions :
Un tableau achant les congés sera retourné à l'utilisateur.
46

− Cas d'utilisation : Visualiser login et password d'une ressource pour un
environnement externe
Figure 16 Diagramme de cas d'utilisation Visualiser login et password d'une
ressource pour un environnement externe
Nous détaillons ce cas d'utilisation par un diagramme de séquence système.
Figure 17 Diagramme de séquence système détaillant le cas Visualiser login et
password d'une ressource pour un environnement externe
47

− Cas d'utilisation : Gérer login et password d'une ressource pour un
environnement externe
Comme l'application permet de consulter les coordonnées de connexion à des envi-
ronnements externes, il est nécessaire d'introduire ces coordonnées (login et mot de
passe) dans l'application. Notre application donne au chef de projet la possibilité
d'introduire ces coordonnées. Etant donné que ces informations peuvent être modi-
ées dans les autres environnements, il fallait alors pouvoir les mettre à jour dans
l'application, le chef de projet ou la ressource elle-même, peut alors modier ou bien
supprimer ces coordonnées.
La gestion de ces coordonnées de connexion peut donc correspondre soit à leurs ajouts
à la plateforme, soit à leurs modications, soit à leurs suppressions. Nous décrivons
les trois scénarios possibles de ce cas d'utilisation.
Figure 18 Diagramme de cas d'utilisation Gérer login et password d'une res-
source pour un environnement externe
Préconditions :
Scénario principal A :
1. Le chef de projet accède à la page de Gestion des environnements externes.
2. Il choisit d'ajouter un nouveau login et mot de passe d'une ressource.
3. Il choisit un environnement externe parmi l'ensemble des environnements
existants.
4. Il saisit le nom et prénom de la ressource.
48

5. Il saisit le login de cette ressource.
6. Et il entre le mot de passe lié à l'environnement choisit de la ressource en
question.
7. Enn, il appuie sur le bouton Enregistrer.
Scénario principal B :
2. Il choisir de modier le login et le mot de passe d'une ressource.
3. Il choisit la ressource correspondante.
4. Il choisit l'environnement externe
5. L'application lui ache le login et le mot de passe
6. Pour modier le login, il clique sur le lien Modier cité devant le login,
saisit la nouvelle valeur et appui sur Valider.
7. Pour modier le mot de passe, il clique sur le lien Modier cité devant le
mot de passe, saisit la nouvelle valeur et appui sur Valider.
Scénario principal C :
2. Il choisit de supprimer un login et mot de passe d'une ressource.
3. Il choisit la ressource correspondante
4. Il choisit l'environnement externe
5. Il clique sur le bouton Supprimer.
Scénario alternatif :
Concernant le scénario principal A, à l'étape 3, si le chef de projet ne trouve pas
l'environnement qu'il cherche dans la liste déroulante, il peut ajouter un nouvel
environnement. Il clique alors sur le lien Ajouter un nouvel environnement,
saisit le nom de l'environnement et appuie sur Enregistrer. Il poursuit les
étapes de 4 à 7 pour ajouter les coordonnées de la ressource dans ce nouvel
environnement.
Post-conditions :
A la n de cette manipulation, les coordonnées de la ressource seront ajoutées,
modiés ou supprimés, selon le choix de la fonctionnalité par l'utilisateur.
49

3.2.2.3 Gestion et suivi de sprint
− Cas d'utilisation : Visualiser la planication et suivi de sprint :
Figure 19 Diagramme de cas d'utilisation Visualiser planication et suivi de
sprint
Ce cas d'utilisation permet, tout au long du projet, de consulter le déroulement
du sprint, et de donner une indication sur sa planication, et sur l'avancement par
rapport à la planication.
Dans l'espace de la planication du sprint, l'application expose toutes les tâches du
sprint. Elle fournit une indication visuelle sur l'état courant de chaque tâche (tâche à
faire pas encre débutée, tâche en cours, et tâche nie). De plus, l'utilisateur est capable
de voir les tâches qui sont bloquées. Il peut aussi savoir la ressource responsable et
l'avancement courant de chaque tâche.
Comme scénario possible, l'utilisateur peut cliquer sur un lien Graphe de dépen-
dance . Ce lien le redirige vers une page qui, à travers un graphe, présente les liens
de dépendance entre les diérentes tâches. Ainsi, l'utilisateur peut savoir s'il y a des
tâches qui débutent après la complétude d'autres tâches. Cas d'utilisation : Visuali-
ser les statistiques Notre application permet d'exposer un ensemble de graphes qui
présentent des statistiques portant sur, soit l'avancement en cours du sprint, soit sur
la totalité du sprint à sa n.
− Cas d'utilisation : Visualiser les statistiques :
Notre application permet d'exposer un ensemble de graphes qui présentent des statis-
tiques portant sur, soit l'avancement en cours du sprint, soit sur la totalité du sprint
à sa n.
50

Figure 20 Diagramme de cas d'utilisation Visualiser les statistiques
Acteur : Chef de projet ou développeur
Préconditions : L'utilisateur doit être authentié en tant que chef de projet ou en
tant que développeur.
1. Si c'est un chef de projet, il doit accéder à un de ses projets courants.
2. Si c'est un développeur, il doit appartenir à un projet; après authentica-
tion, il se trouve directement dans le projet auquel il appartient actuelle-
ment.
1. L'utilisateur accède à la page de Performances de sprint.
2. Une page contenant des graphes lui sera achée. Ces graphes concernent le
sprint courant.
Si le sprint courant n'est pas encore clôturé, l'application ache des
graphes sur l'avancement en cours du sprint. Ces graphes donnent des
statistiques sur le reste à faire, sur l'avancement réel par rapport à
l'avancement prévu,...
- Si le sprint est clôturé, l'application ache des graphes qui résument la
performance globale du sprint. Ces graphes fournissent des statistiques
sur : la performance de l'équipe, la performance de la planication, la
somme du travail à reprendre, l'ensemble des objectifs non atteints,...
3. L'utilisateur choisit un graphe spécique.
4. L'application lui ache le graphe souhaité.
Scénario alternatif :
Si l'utilisateur désire exporter un des graphes achés, il peut cliquer sur le lien
Exporter en chier Excel. Cette action permet d'exporter, en chier Excel,
les images des graphes, ainsi que les valeurs calculées dans le graphe.
51

Post-conditions :
En réponse au scénario principal, une page contenant les graphes sera achée
à l'utilisateur. En réponse au scénario alternatif, un chier Excel contenant le
graphe et ses valeurs sera ouvert et enregistré dans l'ordinateur.
− Cas d'utilisation : Planier un sprint
Figure 21 Diagramme de cas d'utilisation Planier un sprint
Au début de chaque sprint, le chef de projet doit planier les tâches qui vont être
réalisées pendant le sprint, il aecte la date de début et de n de chaque tâche, ainsi
que la ressource qui va la réaliser.
La planication du sprint dépend donc du chier Backlog (les tâches à planiées
sont celles introduites dans le Backlog), elle dépend aussi des congés des ressources
pendant la durée du sprint.
Le chef de projet planie les tâches et l'application se charge de calculer les congés,
vérier les disponibilités des ressources, calculer les dates de n (à partir de dates de
début saisit par le chef et en fonction des durées enregistrées), vérier la cohérence
des dates, etc...
Vu que ce cas d'utilisation nécessite un scénario complexe, nous l'illustrons par deux
diagrammes de séquence. Le premier diagramme de séquence Planier sprint
(Figure 22) fait référence au second diagramme Aecter une tâche (Figure 23)
an de simplier sa représentation.
52

Figure 22 Diagramme de séquence Planier un sprint
53

Figure 23 Diagramme de séquence Aecter une tâche
− Cas d'utilisation : Remplissage du chier Backlog
Cette action est une action automatique générée par le système de notre application
suite à un évènement spécique. L'évènement est la clôture de sprint.
Comme nous l'avons déni auparavant, le chier Backlog de sprint est créé par le chef
de projet. Ce dernier le rempli en ajoutant les tâches qui vont être réalisées pendant
le sprint. Le chier Backlog est représenté sous forme de tableau et deux colonnes
de ce tableau restent vides pour être remplis à la n du sprint (c'est-à-dire lorsque
le sprint soit clôturé). Ces deux colonnes contiennent la charge réelle réalisée pour
chaque tâche et le statut de chaque tâche. Le statut représente l'état nal de la tâche
et peut être OK, KO ou reporté.
Figure 24 Diagramme de cas d'utilisation Remplissage du chier Backlog
A la clôture du sprint, l'application récupère la charge qui a été réalisée pour accom-
54

plir une tâche. Cette charge est enregistrée dans la colonne charge réalisée dans
le chier Backlog et ce pour chaque tâche.
L'application récupère aussi l'état de chaque tâche à la n du sprint et rempli la
colonne Statut selon la valeur de l'état; certaines tâches sont entièrement nies,
d'autre bloquées et d'autre pas encore débutées.
Pour les tâches nies, le statut enregistré est OK
Pour les tâches bloquées, le statut correspondant est KO
Pour les tâches pas encore débutées, le statut est Reporté
− Cas d'utilisation : Modier l'état de sa tâche
Comme le propose Scrum, notre application fournira une représentation des tâches
sous forme de post-it. Ces post-it sont organisés dans un tableau de trois colonnes qui
représentent les états des diérentes tâches. La première colonne concerne les tâches
à faire (pas encore débutées), la deuxième colonne correspond aux tâches en cours de
traitement et la dernière colonne contient les tâches nies.
Figure 25 Diagramme de cas d'utilisation Déplacer sa tâche
La modication de l'état d'une tâche se fait par son déplacement vers l'une des trois
colonnes du tableau. Déplacer une tâche vers une colonne entraîne automatiquement
la modication de son état. Par exemple, le déplacement d'une tâche pas encore
débutée vers la colonne des tâches en cours, entraîne la modication automatique de
son état qui devient en cours .
55

Chaque développeur ne peut déplacer que les tâches qui lui sont aectées. De plus,
si l'état de la tâche devient ni , alors une notication sera générée automati-
quement. Cette notication sert à informer que la tâche a été terminée. Concernant
l'identication de l'acteur auquel la notication sera envoyée, deux cas se présentent :
si la tâche possède un successeur (tâche dépendante d'elle), alors la notication
est envoyée au chef du projet et à la ressource qui possède la tâche suivante.
si la tâche ne possède pas de successeur, alors la notication est envoyée seule-
ment au chef de projet.
3.2.2.4 Partage de connaissances et d'informations
− Cas d'utilisation : Ouvrir une discussion
Pour discuter autour des problèmes rencontrés, un forum est conçu dans notre ap-
plication. Chaque utilisateur (développeur ou chef de projet) peut déclencher une
nouvelle discussion. L'ouverture d'une discussion entraîne la génération d'une noti-
cation. Cette notication sera envoyée à tous les membres de l'équipe autre que le
déclencheur lui-même.
Figure 26 Diagramme de cas d'utilisation Déclencher une discussion
Acteur : Utilisateur général
Préconditions :
L'utilisateur doit être authentié. Il doit appartenir à un projet et à une équipe,
la discussion se fait entre les membres de l'équipe du projet en question.
Si c'est un développeur, il doit appartenir à un projet; après authentication, il se
trouve directement dans le projet auquel il appartient actuellement.
56

1. L'utilisateur accède à la page Discussion
2. Il clique sur le lien Ouvrir une nouvelle discussion
3. Un formulaire lui sera aché
4. Il remplit le formulaire en saisissant le titre de la discussion et l'énoncé du
problème.
5. Il clique sur le bouton Valider
Post-conditions :
Le problème sera enregistré dans la base de données avec un état Ouvert , le
déclencheur et la date de publication sont aussi enregistrés.
L'application envoie une notication à tous les autres membres de l'équipe. Cette
notication indique qu'une nouvelle discussion a été ouverte.
− Cas d'utilisation : Approuver un commentaire
Lorsqu'une discussion est ouverte, les membres de l'équipe peuvent poster des com-
mentaires. Si l'un de ces commentaires peut résoudre le problème évoqué dans la
discussion, le déclencheur de la discussion a la possibilité d'approuver ce commen-
taire et le valider comme solution du problème. La résolution du problème entraîne
la clôture de la discussion en question.
Figure 27 Diagramme de cas d'utilisation Approuver un commentaire
57

Figure 28 Diagramme de séquence Approuver un commentaire
3.3 Planication du cycle de vie du projet
Comme nous avons adopté la méthodologie Scrum pour la gestion de notre projet de
n d'étude, nous avons décomposé le travail durant ce projet en des sprints. Chaque sprint
fournit à sa n un ensemble de fonctionnalités en état de marche. La réunion de n de
sprint a permis de valider les fonctionnalités de chaque sprint.
58

Rapport PFE Ilef Ben Slima

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Rapport PFE Ilef Ben Slima

Semelhante a Rapport PFE Ilef Ben Slima (20)

Rapport PFE Ilef Ben Slima