Le document présente un projet de fin d'études en génie logiciel portant sur la conception et le développement d'une application interactive de gestion de sprint utilisant la méthode Scrum. Il détaille le cadre du projet, la méthodologie de travail et inclut une analyse des besoins et une architecture du système. Le projet a été réalisé en collaboration avec l'entreprise Telnet et a été soutenu en juin 2013.

1. 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

2. 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

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

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

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

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

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

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

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

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

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

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

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

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

15. Chapitre 1. Présentation du cadre de projet
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

16. Chapitre 1. Présentation du cadre de projet
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

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

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

19. Chapitre 2. Etude préalable
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

20. Chapitre 2. Etude préalable
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

21. Chapitre 2. Etude préalable
− 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

22. Chapitre 2. Etude préalable
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

23. Chapitre 2. Etude préalable
− 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

24. Chapitre 2. Etude préalable
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

25. Chapitre 2. Etude préalable
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

26. Chapitre 2. Etude préalable
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

27. Chapitre 2. Etude préalable
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

28. Chapitre 2. Etude préalable
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].
Les points forts Les points faibles
− 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
Adaptabilité de l'outil aux besoins de Telnet :
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

29. Chapitre 2. Etude préalable
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].
Les points forts Les points faibles
− 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
Adaptabilité de l'outil aux besoins de Telnet :
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

30. Chapitre 2. Etude préalable
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].
Les points forts Les points faibles
- 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
Adaptabilité de l'outil aux besoins de Telnet :
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

31. Chapitre 2. Etude préalable
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

32. Chapitre 2. Etude préalable
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

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

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

35. Chapitre 3. Spécication des besoins
• 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

36. Chapitre 3. Spécication des besoins
• 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
• Modier son mot de passe
• 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 :
• Modier son mot de passe
• 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

37. Chapitre 3. Spécication des besoins
• 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

38. Chapitre 3. Spécication des besoins
− 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

39. Chapitre 3. Spécication des besoins
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

40. Chapitre 3. Spécication des besoins
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
3.2.1.2 Gestion de ressources
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

41. Chapitre 3. Spécication des besoins
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

42. Chapitre 3. Spécication des besoins
Figure
12
Diagramme
de
cas
d'utilisation
global
du
package
Gestion
de
sprint
43

43. Chapitre 3. Spécication des besoins
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

44. Chapitre 3. Spécication des besoins
− 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

45. Chapitre 3. Spécication des besoins
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é.
3.2.2.2 Gestion de ressources
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
Acteur : Chef de projet
Préconditions :
L'utilisateur doit être authentié en tant que chef de projet.
Scénario principal :
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

46. Chapitre 3. Spécication des besoins
− 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

47. Chapitre 3. Spécication des besoins
− 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
Acteur : Chef de projet
Préconditions :
L'utilisateur doit être authentié en tant que chef de projet.
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

48. Chapitre 3. Spécication des besoins
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 :
1. Le chef de projet accède à la page de Gestion des environnements externes.
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 :
1. Le chef de projet accède à la page de Gestion des environnements externes.
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

49. Chapitre 3. Spécication des besoins
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

50. Chapitre 3. Spécication des besoins
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.
Scénario principal :
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

51. Chapitre 3. Spécication des besoins
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

52. Chapitre 3. Spécication des besoins
Figure 22 Diagramme de séquence Planier un sprint
53

53. Chapitre 3. Spécication des besoins
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

54. Chapitre 3. Spécication des besoins
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

55. Chapitre 3. Spécication des besoins
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.
Scénario principal :
56

56. Chapitre 3. Spécication des besoins
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

57. Chapitre 3. Spécication des besoins
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

58. Chapitre 3. Spécication des besoins
Sprint 1 User Story 1 : Authentication d'un utilisateur
User Story 2 : Création et gestion d'un projet
User Story 3 : Inscription des ressources
User Story 4 : Gestion et enregistrement des congés
Sprint 2 User Story 1 : Création et mise à jour du Backlog
User Story 2 : Planier un sprint
User Story 3 : Clôture du sprint et remplissage du Backlog
User Story 4 : Exporter le chier Backlog
Sprint 3 User Story 1 : Présentation des tâches sous forme de post-it
User Story 2 : Drag and drop des tâches
User Story 3 : Editer une tâche et modier son avancement
Sprint 4 User Story 1 : Créer les courbes
User Story 2 : Exporter les courbes
Sprint 5 User Story 1 : Générer les notications
User Story 2 : Envoie de message privé
Sprint 6 User Story 1 : Déclencher une discussion
User Story 2 : Commenter une discussion
User Story 3 : Approuver un commentaire et clôturer la dis-
cussion
Tableau IX Planication du projet
Conclusion
Au cours de ce chapitre, nous avons énuméré les diérentes fonctionnalités que l'uti-
lisateur s'attend de notre application et nous avons exposé une spécication détaillée de
certaines de ces fonctionnalités. L'analyse a touché aussi les spécications non fonction-
nelles que doit garantir l'application.
Ayant dénit le périmètre du projet, nous passons dans le chapitre suivant à modéliser
la structure et le comportement de notre projet en se basant sur le langage de modélisation
UML.
59

59. CHAPITRE
4 Architecture et conception
Introduction
Le présent chapitre est consacré à la présentation de l'architecture générale et à la
conception détaillée de l'application. Il permet de décrire la structure des éléments qui
composent la solution proposée, leurs comportements et les interactions entre eux. Ces dif-
férents éléments sont modélisés en adoptant le langage Unied Modeling Langage (UML),
formalisme de modélisation objet qui fournit un ensemble de diagrammes permettant de
modéliser la structure et le comportement d'un système.
4.1 Architecture de la solution
4.1.1 Architecture globale
Les applications Web sont en pleine évolution et deviennent de plus en plus com-
plexes. L'architecture logicielle joue un rôle important dans la réussite et la survie d'une
application Web.
Notre application Web Application de gestion de projet expose un nombre impor-
tants de fonctionnalités et elle est dédiée à plusieurs utilisateurs, de diérents statuts et
de diérents privilèges. Le but dans la mise en place de l'architecture est de garantir l'évo-
lutivité de l'application et sa maintenabilité. Un couplage faible est nécessaire entre les
diérentes logiques de l'application an de faciliter les changements et les améliorations
futures.
Dans ce contexte, une architecture en couches est appropriée. D'une part, cette ar-
chitecture garanti une répartition des rôles entre les couches et une réduction des dépen-
dances. De ce fait, tout changement dans une couche n'aecte pas les autres couches.
D'autre part, une telle architecture facilite la phase de développement dans la mesure
où elle permet les tests unitaires. Chaque couche peut être alors testée indépendamment
des autres couches; sans cette séparation des couches, on devrait eectuer des tests sur
l'interface graphique pour vérier le fonctionnement de l'accès à la base. Enn, les trai-
tements métier et les données sont encapsulés; le client ne peut donc accéder qu'à la
couche de présentation. Ainsi, l'architecture multicouche garantit la séparation entre les
60

60. Chapitre 4. Architecture et conception
interfaces graphiques en contact direct avec le client et le code qui contient les traitements
applicatifs.
Nous illustrons cette architecture en couches par le schéma de la gure 29.
Figure 29 Architecture générale de l'application Web Application de gestion de
projet
Comme le montre le schéma précédent, l'architecture que nous avons conçue est une
architecture en trois couches :
− la couche de données : cette couche regroupe les mécanismes de gestion de la persis-
tance des données et les mécanismes d'accès aux données.
− la couche métier : elle concerne les traitements à réaliser par l'application, quel que
soit les traitements sur les données ou bien les traitements en réponse aux actions de
l'utilisateur.
− la couche présentation : c'est au niveau de cette couche que réside la gestion des
achages des données et des interactions avec l'utilisateur.
Nous avons développé chaque couche dans un projet indépendant, et pour pouvoir
appler un projet par un autre, nous avons ajouté son Dll dans les références du projet
appelant. Nous détaillons les composants et les patrons de conception utilisés dans chaque
couche.
4.1.2 Architecture détaillée
4.1.2.1 Couche de données
Ayant adopté la programmation orienté objet, on devait garantir la gestion des données
persistantes et le passage du monde objet (les classes entités) au monde relationnel (les
tables de la base) ce qui peut nécessiter des traitements complexes.
La couche de données est la couche responsable des mécanismes d'enregistrement, de
récupération et de gestion des données persistantes dans une base de données. Cette couche
permet, non seulement d'eectuer la correspondance (Mapping) entre les objets et la base
de données, mais aussi de prendre en charge l'accès aux données et leur manipulation.
61

61. Chapitre 4. Architecture et conception
Cette couche est elle-même découpée en modules indépendants (Figure 30) :
− système de gestion de base de données (SGBD), qui stocke les données utilisées par
l'application,
− module de persistance, qui assure la correspondance entre les objets et les données
de la base,
− module d'accès aux données : gère la manipulation des données.
Figure 30 Architecture de la couche de données
Au niveau du module d'accès aux données, nous avons utilisé le modèle de conception
DAO (Data Access Object).
F Objets d'Accès aux Données (DAO)
Le modèle DAO est un patron de conception qui permet de séparer l'application de la
base de données. Il permet d'implémenter les mécanismes d'accès aux données à travers
la création d'une classe DAO pour chaque objet métier. Chaque classe DAO contient les
méthodes de liaison avec la base de données permettant la manipulation de cet objet (sa
création, sa mise à jour, sa suppression, sa récupération,...).
Ainsi, pour chaque classe entité (représentant une table de la base de données), nous
implémentons une classe DAO qui sera responsable de la manipulation des données liées
à cette entité.
La logique de gestion des données et d'accès aux données est alors isolée des autres
couches de l'application.
Ce patron donne aussi une grande exibilité pour changer le mécanisme de persistance
à n'importe quel moment, sans devoir mettre à jour les modules qui interagissent avec la
couche de données.
4.1.2.2 Couche Métier
La couche métier gère la logique de l'application et les traitements à eectuer. Elle se
situe entre la couche de présentation et la couche de données. La couche de présentation
62

62. Chapitre 4. Architecture et conception
appelle les traitements depuis la couche métier qui interagit avec la couche de données
et eectue des traitements sur ses données et ceci indépendamment de la provenance des
données et de la façon dont elles sont manipulées.
La couche métier expose un ensemble d'interfaces à travers lesquels la couche de pré-
sentation accède à ses méthodes. Mieux, on peut changer l'implémentation des composants
métier sans perturber le fonctionnement de la couche présentation.
4.1.2.3 Couche présentation
Cette couche permet de fournir au client les interfaces graphiques et de gérer sa liaison
avec la couche métier pour pouvoir appeler les traitements nécessaires.
Vu le nombre important d'actions et de fonctionnalités fournies par l'application, il
s'avère utile de recourir au design pattern MVC. Ce modèle permettra de séparer les vues
(interfaces graphiques) du code, de bien organiser les ux d'échange entre le client et les
services métier de l'application et de fournir une structuration meilleure de l'application.
L'implémentation de la couche présentation sera donc basée sur le modèle de concep-
tion MVC (Model-View-Control).
F Le modèle MVC (Modèle- Vue- Contrôleur)
MVC est un modèle de conception (design pattern) utilisé généralement dans le do-
maine de conception d'interface utilisateur (IHM : Interface Homme Machine). Il a pour
but d'isoler la donnée elle-même de sa présentation, et de distinguer la consultation d'une
donnée de sa modication.
Figure 31 Modèle de conception Modèle-Vue-Contrôleur
Ce modèle décompose les responsabilités de l'IHM en 3 composantes [20], [10]
− Modèle : il représente la structure d'une donnée. Il permet donc d'encapsuler ses
propriétés.
− Vue : la vue reçoit les actions de l'utilisateur et ache dans une interface graphique,
les données provenant exclusivement du modèle
63

63. Chapitre 4. Architecture et conception
− Contrôleur : Il traite les événements en provenance de l'interface utilisateur, appelle
la couche métier pour faire les traitements nécessaires, prépare les valeurs du modèle
et envoie la vue correspondante à l'utilisateur.
4.2 Conception générale : Diagramme de Package
I Diagramme de package global
Comme nous avons adopté une architecture multicouches, nous décomposons les dia-
grammes de conception en des packages (Figure 32).
Figure 32 Diagramme de package global
Comme le montre la gure précédente, le coeur du serveur d'application contient trois
packages qui représentent respectivement la couche de présentation, la couche métier
et la couche de données. Nous dénissons aussi un package qui représente les entités
persistantes dans la base de données.
I Diagramme de package da la base de données :
Le diagramme de la base de données (Figure 33) est lui-même décomposé en packages
vu le nombre important d'entités persistantes.
Le classes persistantes de la base de données sont décomposées en trois packages. Ces
packages concernent les quatre modules détaillés dans le chapitre Spécication des
besoins à savoir le module de gestion et suivi de sprint, le module de gestion de
projet , le module de gestion de ressource et le module de partage de connaissances
et d'information. Nous avons inclus le module de gestion de projet dans le module
de gestion de ressources.
64

64. Chapitre 4. Architecture et conception
Figure 33 Diagramme des package de la base de données
I Diagramme de package da la couche de données
Un zoom eectué sur la couche de données montre deux parties principales, une
première partie qui gère la persistance des données et une deuxième partie qui repré-
sente les mécanismes d'accès aux données. De plus, l'appel aux mécanismes d'accès
aux données se fait via des interfaces. En eet, la couche métier appelle souvent
les classes DAO de la couche de données; celle-là ne voit que les interfaces de la
couche dao an d'assurer l'indépendance entre les deux couches et d'encapsuler l'im-
plémentation des classes dao. Par ailleurs, tout changement dans l'implémentation
n'a aucune incidence sur la couche métier.
Figure 34 Diagramme des package de la couche de données
65

65. Chapitre 4. Architecture et conception
I Diagramme de package da la couche de présentation
La couche présentation est basée sur le patron MVC. De ce fait, elle est aussi décom-
posé en trois packages : un premier package contient les classes modèles, un deuxième
package représente les contrôleurs et un troisième package englobe les vues. Le dia-
gramme de package suivant illustre cette structure.
Figure 35 Diagramme des package de la couche de présentation
Les classes entités du domaine étant déjà constituées dans la couche de données, leur
reconstruction dans la partie Modèle du MVC n'est donc pas nécessaire. Cependant,
nous allons utiliser les modèles de cette couche comme modèle de Vue (ViewMo-
del). Un ViewModel ne représente pas l'entité de la base en entier, mais contient
seulement les données de l'entité qu'on souhaite acher dans une vue. Ce modèle
favorise la possibilité de décorer ses attributs par des règles de validation spéciques
via l'utilisation d'annotations.
Pour résumer les interactions générales entre les diérentes couches, nous allons citer
les étapes qui se déclenchent suite à une requête de l'utilisateur. Ces interactions sont
illustrées dans la gure 36.
66

66. Chapitre 4. Architecture et conception
Figure 36 Interaction entre les diérentes couches de l'architecture
− L'utilisateur déclenche une action à travers l'interface web. Cette action fait
appel au contrôleur.
− Le contrôleur traite la demande de l'utilisateur, il accède aux services de la
couche métier pour exécuter, si besoin, un traitement spécique. La couche
métier peut accéder aux classes DAO de la couche d'accès aux données qui
manipulent ou mettent à jour les données de la base, si nécessaire.
− Après avoir exécuté les traitements nécessaires, le contrôleur prépare la réponse
à l'utilisateur. Pour ce faire, il choisit la vue correspondante, charge le modèle
nécessaire à la vue et remplit ses valeurs. Il demande par la suite à la vue de
s'acher à l'utilisateur.
− Utilisant le modèle préparé par le contrôleur, la vue se génère et ache la réponse
appropriée à l'utilisateur.
4.3 Conception détaillée
4.3.1 Conception statique
Dans ce paragraphe, nous détaillons les classes de chaque package, ainsi que leurs
méthodes et leurs attributs.
4.3.1.1 Diagramme de classes de la base de données
Commençons par les entités persistantes de la base de données. Comme nous l'avons
montré dans le diagramme de package, ces entités se décomposent en 3 packages : un
package de gestion et de suivi de sprint, un package de gestion des ressources et un
package de partage d'informations et de connaissances.
Nous représentons le diagramme de classes de chaque package ainsi que les classes qui
permettent son interaction avec les autres packages.
67

67. Chapitre 4. Architecture et conception
I Gestion de ressources
Figure 37 Diagramme de classe du package Gestion de ressources
Lors de la création d'un nouveau projet, le chef de projet introduit les ressources qui
vont participer au projet. Un projet contient plusieurs ressources et chaque ressource
appartient à un seul projet à la fois.
Une ressource possède un statut spécique qui peut être chef de projet, développeur,
ou administrateur. Le chef de projet peut diriger plusieurs projets. Il en résulte la pré-
sence de deux relations entre une ressource et un projet; une relation d'appartenance
dans laquelle la ressource a le rôle développeur et une relation de direction dans
laquelle la ressource a le rôle chef de projet . Une contrainte est dénit au niveau
de la dernière relation, la ressource qui crée et dirige un projet doit obligatoirement
avoir le statut chef de projet.
Une ressource peut avoir plusieurs congés et un congé peut être conrmé ou bien
annulé.
Les ressources peuvent se connecter à plusieurs environnements comme SVN, Eu-
rope, SUN, etc...Ses environnements sont utilisés dans les diérents projets. Pour
chaque environnement, la ressource possède des identiants (login et mot de passe)
qui lui permettent d'être authentiée. Ainsi, il existe une classe d'association entre
la ressource et l'environnement, cette classe indique les coordonnées d'identication
de la ressource pour cet environnement spécique, comme le montre le diagramme
ci- dessus (Figure 37).
68

68. Chapitre 4. Architecture et conception
I Gestion et suivi de sprint
Figure 38 Diagramme de classe du package Gestion et suivi de sprint
Ce package interagit avec le package de Gestion de ressource via les classes Res-
source et Projet.
Selon la méthodologie Scrum, le projet est décomposé en plusieurs sprints. L'équipe
travaille alors dans le cadre d'un sprint et à la n de ce sprint, elle dénit un nouveau
sprint. Pour déclencher un nouveau sprint dans Telnet, le chef de projet ne crée pas
un nouveau sprint mais crée un nouveau Backlog. Il introduit alors les tâches de ce
Backlog et lorsque celui-ci est prêt, le chef de projet aecte les tâches aux ressources
participantes au projet. L'ensemble de ces aectations constituent le nouveau sprint.
De ce fait, le projet est un ensemble de Backlog (Backlog de sprint) où chaque Backlog
dénit un ensemble de tâches. Chaque tâche peut être aectée à une ressource, ce
qui dénit l'entité Aectation. La planication de toutes les aectations constituent
le sprint.
Une entité tâche ne contient ni la ressource responsable d'une tâche, ni la date de
début et de n de la tâche, ni l'avancement du travail, mais contient principalement
la description de la tâche, la charge prévue pour sa réalisation et le statut de la tâche
à la n du sprint. L'équipe peut partager le Backlog avec le client mais le sprint est
69

69. Chapitre 4. Architecture et conception
spécique à l'équipe et permet la gestion du travail de l'équipe tout au long de la
période du sprint.
L'entité aectation illustre, quant à elle, la charge réalisée, la date de début et de n de
sa réalisation et l'avancement régulier et nal de la charge. Une aectation possède
plusieurs avancements réguliers, la ressource indique chaque jour son avancement
total dans l'aectation, ce qui permet de calculer son avancement pour le jour en
cours. Cette valeur est nécessaire pour pouvoir calculer l'avancement de l'équipe
pour chaque jour du sprint et pour pouvoir, par la suite, construire la courbe qui
illustre l'avancement réel de l'équipe au cours d'un sprint.
I Partage de connaissances et d'informations
Nous avons décomposé le package de partage de connaissances et d'informations entre
les membres d'une équipe en deux parties. La première partie concerne le partage de
connaissances pour la résolution de problèmes existants. Si, au cours d'une tâche, un
membre de l'équipe rencontre un problème, il peut le partager à toute l'équipe et si
ce problème a été déjà résolu, il peut trouver rapidement la solution à son problème,
en eectuant une recherche indexée, et gagner ainsi du temps.
La deuxième partie concerne l'échange d'informations, tel que les informations gé-
nérales, la notication de n de tâche, la notication d'ouverture d'une nouvelle
discussion ou sa fermeture (résolution du souci), etc...
Figure 39 Diagramme de classe Partage de connaissances
Une discussion est déclenchée par une seule ressource et possède un état spécique.
Elle peut être Ouverte (ouverte et pas encore résolue), Résolue (donc fermée) ou
fermée non résolue (si elle a dépassé un seuil de 2 semaines sans être résolue). Si
une discussion est ouverte, toutes les ressources peuvent envoyer des commentaires.
Si un commentaire est approuvé par le déclencheur de la discussion alors ce
commentaire est bien la solution du problème déclenché.
70

70. Chapitre 4. Architecture et conception
Figure 40 Diagramme de classe Partage d'informations
Une ressource peut recevoir un message privé qui peut aussi être envoyé à plusieurs
ressources ou bien à toute l'équipe. Ce message est envoyé par une seule ressource qui
a le rôle de l'émetteur du message. La ressource peut aussi recevoir des notications.
La notication est déclenchée automatiquement pas l'application et elle concerne
plusieurs cas d'informations possibles :
− Informer qu'une tâche est terminée. Cette information est envoyée à la ressource
qui a la tâche suivante et au chef de projet (responsable hiérarchique)
− Informer de l'ouverture d'une nouvelle discussion autour d'un problème.
− Informer de la résolution d'un problème.
4.3.1.2 Diagramme de classes de la couche de données
Nous avons vu auparavant que cette couche contient trois packages : le premier repré-
sente les entités persistantes, le deuxième concerne les classes DAO et le troisième contient
leurs interfaces. Comme les classes entités du domaine sont équivalentes aux entités de
la base de données, leur diagramme de classe va être identique à celui de la base de don-
nées. Nous nous intéressons donc au diagramme de classe de la partie d'accès aux données
(gure 41, 42 et 43).
71

71. Chapitre 4. Architecture et conception
Figure
41
Diagramme
de
classe
représentant
les
implémentations
des
DAO
72

72. Chapitre 4. Architecture et conception
Les diérentes classes DAO héritent de la classe mère DAOT (gure 41). T corres-
pond à une entité quelconque. Cet héritage est conçu pour la simple raison que ces classes
DAO partagent les méthodes de création, de modication et de suppression des entités.
De plus, chaque classe EntitéDAO implémente une interface qui permet d'encap-
suler ses méthodes (Figure 42). Par exemple, la classe RessourceDAO hérite de la classe
IRessourceDAO.
Figure 42 Exemple de Classe DAO et son interface
An d'éviter que la couche métier n'instancie directement ces classes DAO, nous avons
créé une classe DaoFactory qui sera responsable de leurs instanciations (gure 43). Cette
classe, hérite de l'interface IDaoFactory et implémente toutes ses méthodes qui permettent
d'instancier les diérentes classes DAO. Nous avons utilisé le patron de conception Fa-
brique (Factory en anglais).
Figure 43 Portion du diagramme de classe complet de la couche DAO
73

73. Chapitre 4. Architecture et conception
Pour simplier le diagramme (gure 43), nous avons mis seulement deux classes
concrètes DAO qui héritent de la classe DAOT. Le rôle du diagramme ci-dessus est
de montrer que la classe DaoFactory est responsable d'instancier toutes les classes DAO
concrètes à travers la relation instantiate entre la fabrique et la DAO.
Le motif Fabrique est un modèle de création d'objets. Il se charge d'instancier des
objets depuis une classe particulière. Ce motif permet de découpler le client des classes
concrètes à instancier et ore un gain de exibilité pour des évolutions futures de ces
classes.
Ce modèle de conception rend possible la modication future de ces classes ou l'ajout
d'une nouvelle classe DAO correspondant à une nouvelle entité de la base. Grâce à ce
modèle, les instances concrètes (utilisation du mot clé new) se font à un seul endroit!
Donc, si nous devons faire des changements, ils ne se feront qu'à un seul endroit.
4.3.1.3 Diagramme de classes de la couche métier
La couche métier contient le logique métier de l'application et fournit tous les trai-
tements fonctionnels nécessaires. Pour des raisons de simplication du diagramme, nous
n'avons mis dans les opérations de classes que les méthodes de traitements les plus im-
portantes.
La couche métier expose des interfaces à travers lesquels communique la couche de
présentation. Chaque classe concrète implémente les méthodes de son interface. Les mé-
thodes Save(), Update() et Delete() sont communes aux diérentes classes services et font
appel aux méthodes Save(T) Update(T) et Delete(T) de la couche DAO.
74

74. Chapitre 4. Architecture et conception
Figure
44
Diagramme
de
classe
de
la
couche
métier
75

75. Chapitre 4. Architecture et conception
4.3.1.4 Diagramme de classes de la couche présentation
Nous avons exposé auparavant le diagramme de package de la couche présentation.
Ce dernier contient trois packages qui représentent les trois parties du modèle MVC : les
Modèles, les Contrôleurs et les Vues.
Dans ce paragraphe, nous détaillons le diagramme de classe de la partie Contrôleur
(gure 45) an de présenter les opérations les plus importantes qui permettent de traiter
les actions des utilisateurs.
Figure 45 Diagramme de classe des contrôleurs de la couche présentation
Nous avons conçu un premier contrôleur (LogOnController) pour la gestion de
connexion et d'authentication des utilisateurs. Un deuxième contrôleur est conçu pour
la création des graphes des statistiques que l'utilisateur demande de visualiser (Charts-
Controller).
De plus, nous avons créé un contrôleur pour gérer les demandes qui sont spéciques
au chef de projet (ChefController), un autre spécique à l'administrateur (AdminCon-
troller) et un dernier pour gérer les actions qui ne sont possibles que par le développeur
(DévelopperController). Les autres contrôleurs sont communs pour les trois acteurs.
4.3.2 Conception dynamique
Au cours de ce chapitre, nous avons détaillé les éléments statiques de la conception.
Maintenant, nous modélisons, via des diagrammes de séquences et d'états transition, le
76

76. Chapitre 4. Architecture et conception
comportement dynamique du système.
4.3.2.1 Diagrammes de séquence
Commençons par les diagrammes de séquence, ceux-ci mettent en évidence la chrono-
logie des messages échangés entre les objets du système. Nous avons choisi de décrire trois
scénarios principaux : la planication d'un sprint, l'approbation d'un commentaire dans
une discussion et la création d'un nouveau projet.
• Scénario 1 : planication d'un sprint
Le premier diagramme de séquence illustre les échanges entre les objets dans le cadre
de la planication d'un sprint. Comme le diagramme est de grande taille, nous l'avons
décomposé en deux diagrammes. Le premier diagramme global Planier un sprint
fait référence au deuxième diagramme Aecter Tâche .
77

77. Chapitre 4. Architecture et conception
Figure 46 Diagramme de séquence Planier un sprint
78

78. Chapitre 4. Architecture et conception
Figure 47 Diagramme de séquence Aecter une tâche
• Scénario 2 : approbation d'un commentaire
Le deuxième scénario modélisé est celui de l'approbation d'un commentaire pour une
discussion spécique. L'acteur qui provoque ce scénario doit être celui qui a déclenché
la discussion. En d'autres termes, seul celui qui a rencontré un problème et a déclenché
la discussion peut décider d'approuver un commentaire et le marquer comme solution
au problème.
79

79. Chapitre 4. Architecture et conception
Figure 48 Diagramme de séquence Approuver un commentaire
• Scénario 3 : création d'un nouveau projet
Finalement, la création d'un nouveau projet nécessite plusieurs étapes. Le chef de
projet est l'acteur principal de cette fonctionnalité. Ce scénario englobe la création
d'un nouveau projet et l'aectation des ressources à ce projet.
80

80. Chapitre 4. Architecture et conception
Figure 49 Diagramme de séquence Créer un projet
81

81. Chapitre 4. Architecture et conception
4.3.2.2 Diagrammes d'état transition
Les diagrammes de séquence permettent de modéliser les interactions entre un groupe
d'objets en mettant en valeurs les messages échangés et ordonnés dans un cadre temporel.
Quant aux diagrammes d'états-transitions, ils sont utilisés pour décrire le comportement
d'un objet individuel en insistant sur les états par lesquels passe l'objet durant sa vie.
Parmi les objets qui changent continuellement d'état dans notre application on trouve
l'Aectation. L'aectation est une tâche aectée à une ressource. Elle est dénie, durant
le sprint, par un état spécique qui peut être à faire si la tâche est planiée mais pas
encore débutée, en cours si la tâche est en cours de réalisation, Fini si la tâche est
totalement eectuée ou Bloquée si le responsable de la tâche a rencontré un problème
et a suspendu temporellement sa réalisation.
An de modéliser les diérents états d'une Aectation et an de montrer les évène-
ments qui permettent de passer d'un état à un autre, nous illustrons le cycle de vie d'une
Aectation par un diagramme d'états transition.
Figure 50 Diagramme d'état transition Etat d'une tâche aectée
Comme l'entité Aectation, la Discussion est marquée par son état qui prend une
importance majeure dans l'application. En eet, chaque nouvelle discussion est sauve-
82

82. Chapitre 4. Architecture et conception
gardée avec un état Ouvert . Elle reste achée tant que le problème n'est pas résolu
et qu'elle n'a pas dépassé deux semaines depuis son déclenchement. L'approbation d'un
commentaire déclenche le changement de l'état de discussion qui devient Résolue . Les
discussions résolues permettent à l'utilisateur d'eectuer des recherches sur les problèmes
résolus, ce n'est pas le cas des discussions fermées avant d'être résolues puisqu'elles ne
contiennent pas de solutions aux problèmes.
Figure 51 Diagramme d'état transition Etat de la discussion
Conclusion
Dans ce chapitre, nous avons, tout d'abord, présenté l'architecture globale de notre ap-
plication. Nous avons ensuite décrit la modélisation statique du système avec l'utilisation
de diagrammes de classes. Enn, nous avons présenté la dynamique du système par l'éla-
boration de quelques scénarios jugés importants en les modélisant par des diagrammes de
séquence et par le traitement du changement des états déterminants de quelques éléments
du système à travers des diagrammes d'états transition.
Le chapitre suivant met en évidence le travail réalisé pour la mise en place de l'appli-
cation de gestion de projet.
83

83. CHAPITRE
5 Réalisation et test
Introduction
Après avoir décrit les besoins fonctionnels de notre application et après avoir élaboré
la conception et l'architecture du système, nous arrivons maintenant au dernier chapitre
qui décrit le travail réalisé pour la mise en place de l'application.
Ce chapitre met en évidence les diérentes technologies, Framework et bibliothèques
utilisées pour l'élaboration de ce projet. Il illustre aussi les scénarios d'exécution possibles
lors de l'utilisation de l'application développée. Il présente enn les tests réalisés pour
la vérication du code développé et pour la validation des fonctionnalités oertes via les
interfaces homme machine mises en place.
5.1 Environnement matériel et logiciel
I Matériel utilisé
Pour l'élaboration de ce projet, nous avons utilisé un ordinateur portable de système
d'exploitation Windows 7 et ayant les caractéristiques suivantes :
− Processeur : Core i7
− RAM : 8Go
− Type de système : Système d'exploitation 64 bits
I Outil de conception
Pour la réalisation des diérents diagrammes de la phase de conception, nous avons
utilisé l'outil Entreprise Architect. C'est un outil de création de modèles dont le
langage est UML ou Langage de Modèle Unié. Il permet de réaliser des modèles
orientés vers le milieu professionnel, de générer ou d'importer du code pour certains
langages et de gérer une base de données relationnelle.
I Outil de base de données
Dans le cadre de la création et de l'administration de notre base de données, nous
avons utilisé SQL Server 2008 R2 comme système de gestion de base de données
(SGBD).
84

84. Chapitre 5. Réalisation et test
SQL Server 2008 R2 est un système de gestion de base de données commercialisé par
la société Microsoft. Il utilise le langage T-SQL (Transact-SQL) et ore un ensemble
complet de fonctionnalités pour stocker, traiter et sécuriser les données. Il fournit des
accès contrôlés et des traitements de transactions rapides permettant de répondre
aux besoins des applications les plus gourmandes en données et utilisées au sein des
entreprises.
Avec ce SGBD, nous avons eu recourt au logiciel SQL Server Management Studio
qui associe un groupe d'outils graphiques pour permettre aux développeurs et aux
administrateurs d'avoir accès à SQL Server.
I Outils et bibliothèques de développement
IDE : Microsoft Visual Studio 2010
Durant la phase de développement, nous avons utilisé l'IDE Microsoft Visual Studio
2010. Il s'agit d'un environnement de développement intégré qui permet de générer
des applications Web ASP.NET, des Services Web XML, des applications bureau-
tiques et des applications mobiles. Il facilite la création de solutions à plusieurs lan-
gages. Ces langages utilisent les fonctionnalités du .NET Framework, qui fournit un
accès à des technologies clés simpliant le développement.
Outil de Test : Unit Test Framework
Unit Test est le Framework de tests unitaires intégré dans Visual Studio. Il est utilisé
pour tester le code des méthodes implémentées. Un explorateur de test (Test Ex-
plorer) est fourni avec ce Framework. Il permet d'exécuter les tests unitaires et de
visualiser leurs résultats dans une interface spécialisée.
Bibliothèque de création de graphiques : ZedGraph
La librairie ZedGraph est une bibliothèque qui permet de représenter et de congurer
tout type de graphes (graphique en courbes, en secteurs, en bars, en nuages de points,
...). Elle est destinée aux développements .NET et elle fournit un ensemble de classes
souples et paramétrables qui permettent la représentation de ces graphes.
Bibliothèque d'exportation en Excel : NPOI
NPOI est la version .Net équivalente à POI Java Project. Cette dernière a pour
objectif de permettre d'écrire et lire des chiers d'extensions xls, doc et ppt.
NPOI est une bibliothèque libre qui permet de générer des rapports Excel. Cette
bibliothèque est convenable pour les applications Web puisqu'elle ne nécessite pas
que le bureau Microsoft soit installé sur le serveur partagé.
Bibliothèque pour traitement de requêtes en temps réel : Node.js
Node.js représente un interpréteur de JavaScript coté serveur. Son principe consiste
à utiliser un modèle IO (Input/Output) non bloquant pour gérer les évènements
(requêtes) entrants et sortants, ce qui le rend léger et ecace. Node.js est idéal pour
les applications où des données intensives parviennent en temps réel depuis diérents
dispositifs distribués. Il fournit de nombreux modules comme Socket.IO. Socket.IO
permet de faire des applications en temps réel et possible dans tous les navigateurs.
85

85. Chapitre 5. Réalisation et test
Nous avons utilisé Node.js et particulièrement le module Socket.IO pour permettre
l'envoi de notications en temps réel aux diérents utilisateurs suite à des évènements
déclencheurs.
5.2 Choix technologiques
Framework .Net :
Etant un standard proposé par la société Microsoft, le Framework .Net fournit un
ensemble de bibliothèques et de règles de développement qui permettent un développement
rapide et performant d'une application. Le Framework .Net fait appel à diérents langages
de programmation tel que C + +, C], VB, Python. Pour le développement de notre
application Web, nous avons choisi de travailler avec le Framework .Net et d'utiliser le
langage C].
Entity Framework :
L'application Web ne peut pas manipuler automatiquement des entités de la base de
données. La manipulation directe nécessite beaucoup de requêtes SQL ce qui est lourd
et gênant. La technologie ORM, qui désigne la correspondance entre l'objet dans le code
et l'entité relationnelle de la base, permet de gérer, automatiquement et d'une manière
transparente, la persistance des données de la base.
Object-Relational Mapper (ORM) est une technologie qui a les avantages suivants :
− le code manipule des objets de la base de données d'une manière transparente
− charge/décharge les objets relationnels depuis/vers une base SQL
− pas de SQL au milieu du code
− indépendance du code par rapport à la base de données. [11]
Dans le cadre de notre application Web, nous avons choisi d'utiliser l'ORM Entity
Framwork. Notre choix a porté sur cet ORM parce que, d'une part, il contient un designer
graphique puissant qui permet de créer visuellement un pseudo diagramme de classes (les
classes correspondantes aux tables de la base de données), et d'autre part il est intégré
dans Visual Studio 2010. Il est de ce fait gratuit contrairement à certains ORM, comme
NHibernate, qui sont payants ou qui donnent une version gratuite mais limitent le nombre
d'entités.
Le but de ce Framework est de fournir la couche d'abstraction nécessaire aux dévelop-
peurs pour qu'ils n'accèdent plus directement à la base de données, mais par l'intermé-
diaire d'entités dénies par un modèle appelé EDM (Entity Data Model). [13]
Ce modèle EDM permet de décomposer cette mécanique d'abstraction en trois parties :
− Le schéma conceptuel : Il regroupe la dénition des entités et des fonctions utilisées.
− Le schéma logique : correspond à la dénition des tables, vues et procédures stockées
déclarées dans la base de données.
86

86. Chapitre 5. Réalisation et test
− Schéma de liaison : Il dénit les liaisons entre le schéma conceptuel et le schéma
logique.
ASP.Net MVC :[21]
ASP.Net MVC est un Framework de développement web basé sur le design-pattern
MVC modèle / vue / contrôleur. Ce design pattern permet le découpage des responsa-
bilités entre les données métier (le modèle), le traitement et le routage des éléments d'une
application (le contrôleur) et la présentation de l'information (la vue).
Nous avons adopté le Framework ASP.Net MVC 3 pour le développement de notre
application Web et spéciquement au niveau de la couche de présentation pour diérentes
raisons. D'une part, ce Framework garantit l'extensibilité et l'évolutivité de l'application
dans la mesure où il assure la segmentation des diérentes responsabilités et isole la
problématique de l'achage des autres rôles/contrôles. D'autre part, ASP.Net MVC est
conçu pour faciliter la rédaction des tests unitaires. De plus, il s'agit d'une extension à la
plateforme ASP.Net et bénécie, de ce fait, de tous ses atouts (la gestion des utilisateurs
et des sessions, la gestion du cache, le code orienté objet, le débogage, etc...).
JavaScript : [22]
JavaScript est un langage de programmation de scripts incorporé dans un document
HTML. Il permet d'apporter des améliorations au langage HTML en permettant d'exécu-
ter des commandes du côté client, c'est-à-dire au niveau du navigateur et non du serveur
web.
JQuery : [23]
JQuery est un Framework JavaScript libre. Ce Framework permet de coder rapidement
et simplement des traitements à base de code JavaScript pour dynamiser et améliorer
l'ergonomie des sites internet. Il permet notamment de :
− parcourir et manipuler le DOM (l'arbre des éléments HTML)
− gérer des événements utilisateurs (clic souris, changement de la valeur d'une liste
déroulante, Drag and drop...)
− ajouter des eets et animations visuels (fondu, disparation,...)
− gérer les styles CSS et attributs des balises HTML
− gérer des interactions AJAX (communication asynchrone avec le serveur)
HTML5 :
Le HTML5 est un langage de base pour la création de site internet qui permet de
structurer le document Web. C'est la dernière version en date du langage de développe-
ment web HTML. Les balises HTML sont utilisées pour structurer le document, et non
pas pour préciser son apparence. Ce sont les feuilles de style (CSS) qui servent à décrire
la forme du document.
CSS3 (feuilles de style) :
87

87. Chapitre 5. Réalisation et test
Pour la structuration du contenu de nos pages web, nous avons utilisé la technologie
html5, par contre, la spécication de la forme et de la présentation des pages a été faite par
l'utilisation des feuilles de style. Les feuilles de styles servent, par exemple, à spécier le
type de la police d'un paragraphe, la couleur d'un titre, les marges, les tailles,... Dans notre
cas, nous avons utilisé la version CSS 3 qui est compatible avec HTML5. CSS3 ore un
ensemble de nouveautés qui améliorent l'apparence d'un site web. Parmis ses nouveautés,
CSS3 permet d'automatiser des eets visuels avancés coome les coins arrondis, l'opacité
des objets, les arrières plans multiples, les eets textuels, etc...
5.3 Phase d'implémentation
La phase de réalisation de notre application Web consiste en l'implémentation des trois
couches décrites dans l'architecture générale.
Chaque couche étant implémentée dans un projet indépendant, il est nécessaire de
garantir la communication entre ces projets. Ainsi, chaque projet doit avoir le chier dll
d'un autre projet dans ses références pour pouvoir utiliser ses classes et ses méthodes.
Nous avons donc ajouté le chier dll du projet de la couche de données dans les
références du projet de la couche métier (gure 52). De la même façon, nous avons ajouté
les chiers dll des deux projets de la couche de données et la couche métier dans le projet
de la couche présentation.
Figure 52 Référence du projet de la couche de données dans le projet Couche
Métier
En ce qui concerne la création de la base de données, nous avons lancé un script SQL
sous SQL Server 2008 R2. Ce script a été généré automatiquement depuis le diagramme
de classes conçu dans l'outil Enterprise Architect.
5.3.1 Couche de données
En ce qui concerne la couche de données, nous avons implémenté les classes Dao et
leurs interfaces, comme décrit dans le chapitre Conception. Pour la partie Domain, nous
avons utilisé l'ORM Entity Framework. A travers son designer graphique, nous faisons
appel au serveur de la base de données, à la base correspondante et aux tables de la base
de données SQL. L'outil génère automatiquement les classes entités correspondantes à ces
88

88. Chapitre 5. Réalisation et test
tables. Nous obtenons alors le modèle EDM, un pseudo diagramme de classes, similaire
à celui de la base. Nous obtenons aussi un chier qui décrit les dénitions des entités de
ce diagramme et les relations de clés primaires et de clés étrangères de chaque entité. Les
diérents packages de ce projet se présentent comme le montre la gure 53.
Figure 53 Structure du projet de la couche de données
5.3.2 Couche métier
Dans la couche métier, nous avons implémenté les classes et les interfaces présentées
dans le chapitre précédent (gure 44). Les méthodes dénies dans les classes métier cor-
respondent aux traitements fonctionnels que nécessite l'application.
Cette couche est composée de deux packages : un premier package qui contient le
contrat (les interfaces) et un deuxième package qui contient les implémentations. Les
méthodes fonctionnelles sont donc encapsulées par les interfaces pour les découpler de la
couche de présentation.
De plus, la couche métier fait appel aux classes dao de la couche d'accès aux données
pour manipuler ou mettre à jour les données de la base. Elle a donc besoin des instances
de classes dao; cependant, elle ne s'occupe pas de leurs instanciations qui sont plutôt
faites par une classe Fabrique grâce au pattron de conception Factory. Une description
de ce patron a été présentée dans le chapitre précédent.
5.3.3 Couche de présentation
Durant l'implémentation de la couche présentation, nous avons utilisé diérents
concepts, bibliothèques et principes pour la mise en place des fonctionnalités fournies
à l'utilisateur. Nous avons choisi de détailler les concepts les plus importants dans ce qui
suit.
5.3.3.1 Authentication et autorisation des utilisateurs
An de bénécier des services de notre application, un utilisateur doit s'authentier.
S'authentier, c'est apporter la preuve de son identité. L'application est destinée à être
utilisé entre les membres des équipes dans Telnet, en réseau local. Chaque utilisateur
89

89. Chapitre 5. Réalisation et test
possède et manipule ses propres données. Puisque l'application tourne en local, nous avons
choisi de mettre en place une authentication simple par mot de passe. Les utilisateurs
connus par l'application sont stockés dans notre base de données et plus spéciquement
dans la Table Ressource.
Lors de la validation de l'identité d'un utilisateur, un ticket d'authentication lui sera
attribué et sera ajouté à la collection de cookies du navigateur. A sa déconnexion, le ticket
fournit sera supprimé de la collection des cookies.
L'utilisateur authentié doit aussi avoir l'un des trois rôles autorisés par l'application
à savoir le rôle de Chef de projet, de développeur, ou d'administrateur du site. Le rôle est
enregistré dans la même table Ressource de la base de données sous forme d'attribut
nommé statut.
An de gérer les rôles des utilisateurs, nous avons créé un fournisseur de rôle person-
nalisé qui hérite de la classe RoleProvider prédénie dans ASP.Net.
D'un autre côté, nous avons créé des règles d'autorisations dans le chier Web.cong
pour interdire l'accès à notre application par des utilisateurs anonymes.
Enn, l'appel des pages web se fait via les contrôleurs. Donc, pour dénir les pages
permises à chaque rôle, nous avons décoré les contrôleurs par l'attribut [Authorize]. Cet
attribut indique les rôles autorisés pour accéder aux vues appelées par ce contrôleur. Si
les actions du contrôleur ne sont pas toutes permises aux mêmes rôles, alors l'appel de
l'attribut [Authorize] se fait au niveau de la méthode et non pas au niveau du contrôleur.
5.3.3.2 Master Page et Nested Master Page
Une master page (ou page maître) est une page qui contient à la fois, des éléments
qui s'achent de la même manière sur une partie ou sur la totalité du site web, et des
éléments qui varient dans le site. Une Master Page donne alors la possibilité de dénir une
structure commune et des éléments d'interfaces pour tout le site pouvant être partagés
entre autant de pages souhaité.
Pour l'achage d'une entête commune à toutes les pages du site, nous avons déni
une page mère, de laquelle héritent toutes les pages de notre site. Cette entête contient le
nom de l'application, le logo de Telnet et les liens vers les fonctionnalités de connexion,
de déconnexion et d'accès au prol présentes dans toutes les pages de notre application
(Figure 54).
Figure 54 Entête commune de l'application dénit par la master page, aché
pour utilisateur non authentié
Dans certains cas, un ensemble de pages, et non toutes les pages du site, partagent
90

90. Chapitre 5. Réalisation et test
une section du site. Dans ce cas, la section ne peut pas être décrite dans la page maître et
nous avons besoin d'une sous page maître qui hérite de la première et qui fournit de plus
des éléments communs à un ensemble particulier de pages web. Cette sous page maître
correspond à l'élément Nested Master Page fournit par ASP.Net. C'est un concept simple
mais puissant qui permet d'avoir une hiérarchie de pages maîtres.
Dans ce contexte, notre application contient un espace de projet, à partir duquel, nous
pouvons accéder à la page qui ache le chier Backlog du projet, à la page de planication
du sprint et à la page qui contient les graphes de performance du projet, ... Toutes ces
pages doivent avoir une section commune qui permet de naviguer entre les diérentes
zones de cet espace.
La gure suivante montre un exemple d'utilisation de Nested Master page que nous
avons appliqué dans notre projet. La partie cadrée en rouge représente la section commune
fournie par ce concept.
Figure 55 Exemple d'utilisation de Nested master page
5.3.3.3 User story sous forme de Post-it
Dans les concepts de Scrum, les user story (fonctionnalité du produit à réaliser)
sont présentées sous forme de post-it, comme nous l'avons décrit précédemment dans le
chapitre étude préalable. Tous ces post-it doivent être exposés dans un tableau de trois
colonnes : une colonne pour les tâches à faire, une autre pour les tâches en cours, et une
dernière colonne pour les tâches nies. De plus, chaque post-it doit être déplaçable et
éditable.
Cette représentation impose que chaque story soit créé indépendamment des autres,
pour pouvoir l'éditer et la déplacer. Chaque story doit aussi contenir des données spéci-
ques.
91

91. Chapitre 5. Réalisation et test
De ce fait, nous avons créé un composant graphique indépendant pour chaque post-it.
Ce composant est implémenté à travers le principe de vue partielle (partial view) dénit
dans ASP.Net MVC3.
Une vue partielle permet de dénir une vue qui sera restituée dans une vue parente.
C'est une façon pratique de dénir une présentation une seule fois, puis de la réutiliser
dans plusieurs parties de l'application. [24].
L'implémentation de notre vue partielle, avec l'utilisation d'une image de post-it
comme fond de la page, a permis de créer les story sous forme de post-it, ce qui a abouti
au résultat suivant :
Figure 56 Exemple de post-it
Grâce à cette méthode, nous avons pu exposer diérentes story dans une seule page
parente, en appelant pour chaque story une vue partielle, avec les données de la tâche
correspondante.
Dans une story, nous avons mis diérentes informations tel que l'intitulé de la tâche,
la ressource responsable de la réalisation de la tâche, la charge estimé et la charge réalisée
(en jour) et l'avancement dans la réalisation de la tâche sous la forme d'une barre de
progression. Les données de ces story sont aussi éditables via l'appui sur l'image de crayon
en haut à droite et chaque user story est déplaçable dans le tableau qui le contient. Seule
la ressource responsable de la réalisation d'une tâche peut éditer et déplacer une Story. Le
déplacement d'une story vers la colonne des tâches nies change sa couleur en vert pour
montrer qu'elle a été bien réalisée et met à jour l'avancement à 100%.
Ces évènements (déplacement de la story, capture de sa position, modication de sa
couleur et de son avancement,...) se font à travers l'utilisation de la bibliothèque JQuery.
5.3.3.4 Evènements détectés et gérés avec JQuery
Nous avons choisi d'utiliser JQuery pour permettre le déplacement des post-it dans le
tableau blanc de sprint vu qu'il s'agit d'un générateur puissant d'évènements d'utilisateur.
Ce déplacement se fait grâce au plugin drag-and-drop (glisser et déposer en langue
Française) disponible en JQuery sous la forme de deux parties distinctes, à savoir le
plugin Draggable et le plugin Droppable.
Le plugin Draggable permet à un élément d'être déplaçable en l'appelant de la manière
92

92. Chapitre 5. Réalisation et test
suivante :
$ ( ' element ' ) . draggable ( ) ;
Grâce aux options oertes par ce plugin, nous avons pu limiter la zone de déplacement
des post-it an d'interdire l'utilisateur de glisser les story en dehors du tableau des post-it
(gure 57).
Le plugin draggable permet de glisser un objet, il fallait alors dénir un élément qui
servira de zone dans laquelle sera déposé cet objet. Cet élément peut être dénit en
utilisant le plugin droppable de la manière suivante :
$ (. Afaire , . enCours , . f i n i e ). droppable ( ) ;
Dans notre cas, les éléments qui peuvent accueillir les objets déplaçables sont les trois
colonnes du tableau de sprint : la colonne qui contient les story à faire, celle qui contient
celles en cours de réalisation et la colonne qui comprend les story nies (gure 57).
Figure 57 Tableau de post-it
Une fois le déplacement du post-it terminé, nous avons besoin de changer sa couleur,
ainsi que l'avancement dans la barre de progression, s'il est déplacé dans la colonne Finie.
Dans ce contexte, le plugin droppable fournit la possibilité d'appeler une fonction, qui sera
responsable d'eectuer ces changements, à la n de l'action drag and drop.
Nous avons aussi besoin d'appeler une méthode côté serveur pour modier l'état de la
tâche en fonction de la colonne accueillante. Cette action se fait via l'appel d'une fonction
Ajax : la fonction est $.post. Cette fonction permet d'envoyer une requête de type POST
au serveur, la requête correspond à une demande d'exécuter la méthode qui modie l'état
de la tâche selon les paramètres envoyées dans la requête.
93

93. Chapitre 5. Réalisation et test
D'autres traitements ont été réalisés avec JQuery, comme la création d'une barre de
progression qui se fait via le plugin progressbar, l'appel d'un calendrier via le plugin
jQuery UI Datepicker, ...
5.3.3.5 Détecter les notications avec le plugin Node.js
Suite à des évènements spéciques, des notications se génèrent et s'envoient automa-
tiquement aux utilisateurs concernés. La réception de notication se fait en temps réel
dès le déclenchement de l'évènement. Dans notre cas, l'évènement déclencheur d'une no-
tication peut être la terminaison d'une tâche, l'ouverture d'une discussion ou bien la
résolution d'une discussion.
An de garantir la réception immédiate des notications suite à ces évènements, nous
avons utilisé le plugin Node.js et spéciquement le module qui y est intégré Socket.IO.
Node.js nous a permis de créer un serveur http et le mettre en écoute sur un port spéci-
que. Ce serveur reste en marche tant que des utilisateurs sont connectés à l'application.
Ensuite, nous avons créé un socket qui reste en écoute sur ce serveur. Lorsqu'un évène-
ment se déclenche du coté client, le socket envoie un message au serveur lui indiquant
qu'un évènement a été déclenché, le serveur génère une notication et envoie un message
aux navigateurs des autres utilisateurs pour leurs demander d'acher la notication aux
clients.
5.3.3.6 Graphes de statistiques
Pour chaque sprint, le chef de projet souhaite évaluer le travail de son équipe tout au
long du sprint. Il désire avoir une idée sur l'avancement réel par rapport à ce qui a été
prévu, savoir le pourcentage des objectifs non atteints par rapport aux objectifs planiés,
calculer le travail à reprendre, et d'une manière générale, évaluer la performance globale
de son équipe et de sa planication.
Dans le but d'aider le chef de projet à analyser la situation réelle de son projet, nous
avons mis à sa disposition un ensemble de graphes de diérents types. Chaque graphe
concerne un point spécique de l'analyse et se crée automatiquement sans l'intervention
de l'utilisateur. Les données utilisées pour calculer les valeurs du graphe sont prises depuis
les données stockées pendant l'utilisation des autres fonctionnalités du site.
Pour la création de ces graphes, nous avons utilisé la bibliothèque ZedGraph. C'est
une librairie puissante qui permet de représenter et de congurer tout type de graphique.
Nous avons mis en place deux familles de graphes : la première concerne le suivi du
sprint au cours de sa réalisation et la deuxième concerne l'analyser du sprint en entier à
sa n.
Commençons par décrire les graphes du suivi du sprint courant. Au cours du sprint,
quatre graphes sont fournis à l'utilisateur.
1. Burndown Chart (ou graphe du reste à faire)
Cette courbe, citée parmi les artefacts les plus importants de la méthodologie Scrum,
94

94. Chapitre 5. Réalisation et test
donne une idée sur ce qui reste à faire pour le sprint courant. Le reste à faire est re-
présenté en heure et correspond à la somme des heures restantes pour nir l'ensemble
des tâches. Par exemple, si pour un sprint quelconque, huit tâches ont été planiées
et chaque tâche nécessite 24 heures (un jour) pour être nie, alors le nombre d'heures
total est 192 heures. Puis, chaque jour du sprint, on diminue le nombre d'heure tra-
vaillée réellement pendant ce jour.
Le calcul de l'équation de la courbe (gure 58) se fait comme suit :
(a) La valeur initiale (SHP) est la somme des nombres d'heures prévues pour toutes
les tâches du sprint.
SHP =
X
tâches du sprint
charge estimé (1)
(b) À chaque jour du sprint, nous eectuons le calcul suivant
• Pour chaque tâche prévue pour ce jour, nous calculons :
− L'avancement réel (avanReel) de la tâche pendant ce jour : il est ré-
cupéré à partir de la table AvancementRégulier de la base de données.
Cet avancement régulier correspond au pourcentage du travail que la
ressource a pu réaliser pour ce jour.
− L'avancement prévu (avanPrevu) pour la tâche qui est aussi récupéré
de la base. Il correspond au pourcentage du travail que la ressource doit
eectuer pendant ce jour.
avanPrevu =
100
charge estimé
(2)
− Le nombre d'heure travaillé pour cette tâche pendant ce jour (HT) est
calculé par l'équation suivante :
HT =
100
charge estimé
∗ 8h (3)
• Le nombre d'heures total travaillés dans ce jour (HTJ) est la somme de
toutes les valeurs de HT.
HTJ =
X
tâches de ce jour
HT (4)
(c) La valeur présentée dans la courbe est celle du reste à faire (RAF). Donc, pour
chaque jour du sprint, nous aectons le calcul suivant :
RAF = SHP − HTJ (5)
95

95. Chapitre 5. Réalisation et test
Figure 58 Exemple d'une courbe BurnDown Chart
2. Courbe d'avancement
Idéalement, l'équipe eectue le même pourcentage de travail chaque jour, jusqu'à
atteindre la n du sprint (pour un sprint de 8 jours, l'équipe eectue idéalement
12.5% du travail chaque jour : 100% divisé par le nombre de jours qui est égal à 8).
La courbe d'avancement montre l'avancement réel de l'équipe par rapport à l'avance-
ment idéel (voir gure 59). Elle contient donc deux courbes qui représentent respec-
tivement l'avancement idéal et l'avancement réel. L'achage des deux courbes dans
un même graphe permet de faciliter la comparaison des deux avancements.
Pour calculer l'équation de la courbe d'avancement idéal, nous suivons ces étapes :
(a) Calculer le pourcentage du travail qui peut être réalisé dans le cas idéal (AI :
Avancement Idéal), et ce pour un jour du sprint.
AI =
100%
nombre de jours du sprint
(6)
(b) Calculer la valeur du cumul de l'avancement pour chaque jour du sprint (CAI :
Cumul Avancement Idéal), qui est égale à l'avancement de ce jour, additionné
aux avancements des jours précédents. Cette valeur est celle qui va être repré-
senté dans la courbe.
CAI = (
X
Jours précédents
AI) + AI (7)
Nous nous intéressons maintenant à l'équation de la courbe d'avancement réel. Celle-
ci se calcule à travers les étapes suivantes :
(a) Pour chaque jour du sprint, nous devons :
96

96. Chapitre 5. Réalisation et test
• Récupérer les tâches qui sont présentes pendant ce jour
• Pour chaque tâche, calculer :
− L'avancement prévu (avanPrevu) pour la tâche pour ce jour.
avanPrevu =
100
charge estimé
(8)
− L'avancement réel (avanReel) eectué pendant ce jour qui se récupère
à partir de la table AvancementRégulier de la base de données.
− La fraction du travail eectué pour la tâche (FR)
avanPrevu =
avanReel
avanprevu
(9)
• Calculer la fraction réelle totale (de toutes les tâches) qui est égal à la somme
des FR
HTJ =
X
tâches de ce jour
FR (10)
• Calculer la fraction idéale totale qui correspond au nombre d'aectations
(tâches) prévues pour ce jour.
FIT =
X
aectations prévues pour ce jour (11)
• Enn, l'avancement réel de ce jour (AR) est calculé de la façon suivante :
AR =
FRT
FIT
∗ AI (12)
(b) La valeur présentée dans la courbe est celle du cumul de l'avancement réel
(CAR). Donc, pour chaque jour du sprint, nous aectons le calcul suivant :
CAR = AR +
X
Jours précédents
AI (13)
Figure 59 Exemple d'une courbe d'Avancement
97

97. Chapitre 5. Réalisation et test
3. Graphe d'états de tâches
Ce graphe donne une vision globale sur les proportions des diérents états des tâches
du sprint en cours, les états possibles étant à faire , en cours , ni et
bloqué . Un exemple de ce graphe est illustré par la gure 60.
Le graphe comprend ainsi quatre secteurs dont les équations sont les suivantes :
secteur d'état à faire =
nombre de tâches à faire
nombre de tâches
(14)
secteur d'état en cours =
nombre de tâches en cours
nombre de tâches
(15)
secteur d'état ni =
nombre de tâches ni
nombre de tâches
(16)
secteur d'état bloqué =
nombre de tâches bloquées
nombre de tâches
(17)
Figure 60 Exemple d'un graphe d'états de tâches
4. Graphe de dépassement de délais
La représentation en barres (Figure 61) montre le pourcentage des tâches qui ont
dépassé le délai, le pourcentage des tâches qui ont respecté le délai prévu et le pour-
centage des tâches qui ont dépassé le délai sans être débutés.
Le dépassement de délai vérie la condition suivante : si la charge réalisée de la tâche
a dépassé la valeur de la charge estimée, alors la tâche est considérée en dépassement
de délai. Elle vérie donc la relation suivante :
charge réalisé actuelle charge estimé (18)
98

98. Chapitre 5. Réalisation et test
Figure 61 Exemple d'un graphe de dépassement de délai
Nous passons maintenant à la description des graphes qui permettent d'analyser le
sprint à sa n.
5. Performance du sprint
Ce graphe donne un récapitulatif sur la performance du sprint : travail réalisé, travail
reporté, travail à reprendre ou travail avec objectif non atteint. Ces valeurs sont
exposées en nombre de jours de travail.
Les états des tâches sont pris à la n du sprint. Certaines tâches sont alors nies.
D'autres tâches n'ont pas encore débutés et seront reportées. On peut aussi avoir des
tâches bloquées qui nécessitent d'être repris et des tâches qui ont été ajoutés au cours
du sprint et qui ne sont pas planiés.
Le calcul des valeurs des barres se fait comme suit :
travail planié =
X
tâches planiés au début du sprint
chargé estimée (19)
travail réalisé =
X
tâches nies
chargé estimée (20)
travail reporté =
X
tâches à faire
chargé estimée (21)
travail à reprendre =
X
tâches bloquées
chargé estimée (22)
objectif non atteint = Travail reporté + travail à reprendre (23)
99

99. Chapitre 5. Réalisation et test
Figure 62 Exemple d'un graphe de Performance de sprint
6. Performance de Telnet
Ce dernier graphe concerne l'évaluation de la performance de Telnet en général (voir
Figure 63) Cette évaluation repose sur trois critères. Le premier expose la performance
de l'équipe qui a travaillé durant le sprint c'est à dire le travail qu'elle a pu réaliser par
rapport à sa capacité maximale. Le deuxième critère concerne la performance de la
planication du chef de projet, celle-ci évalue la correspondance entre la planication
et ce que l'équipe a pu eectuer réellement. Le troisième critère est la performance
de l'entreprise en général, il correspond au travail qu'elle a pu faire, qu'il soit planié
à l'avance ou pas, par rapport à la capacité de l'équipe.
Pour le calcul des valeurs de ces trois critères, nous avons eu recours aux grandeurs
calculées dans le graphe précédent (travail réalisé, travail reporté, travail à reprendre
et objectif non atteint). Nous avons besoin deux autres paramètres qui représentent
le travail non planié et la capacité de l'équipe.
travail non planié =
X
tâches non planiés au début du sprint
chargé estimée (24)
capacité = nombre de jours du sprint ∗ nombre de ressources (25)
Donc, les valeurs des trois critères se calculent à partir des équations suivantes :
Performance de l'équipe =
Travail réalisé
capacité
∗ 100 (26)
Performance de planication =
Travail réalisé
Travail planié
∗ 100 (27)
100

100. Chapitre 5. Réalisation et test
Performance de Telnet =
Travail non planié réalisé + Travail à reprendre + Travail réalisé
capacité
∗100
(28)
Figure 63 Exemple d'un graphe de Performance de Telnet
5.3.3.7 Export de chier Excel
An de conserver les résultats fournis par l'application dans des chiers plats et pour
permettre la communication de quelques informations du projet avec des acteurs externes
à l'application, nous avons donné la possibilité d'exporter quelques résultats en chiers
Excel. Ces résultats sont le chier Backlog et les graphes d'un sprint.
Pour l'exportation de ces données, nous avons utilisé une bibliothèque spécique NPOI.
Celle-ci permet d'écrire et lire des chiers d'extensions xls, doc et ppt.
1. Exportation du chier Backlog
Le chier Backlog contient l'ensemble des tâches planiées pour un sprint spécique.
Il expose les informations des tâches sans entrer dans les détails de la réalisation.
Ce chier peut être communiqué au client. Comme ce dernier n'a pas accès à la
plateforme, il s'avère nécessaire d'exporter ces informations en chier Excel.
L'appel à la bibliothèque NPOI a permis de créé ce chier par la programmation.
Chaque ligne du chier Excel correspond à une tâche et chaque colonne contient un
attribut de la tâche (son intitulé, son estimation, sa charge réalisée, son statut et un
commentaire).
De plus, nous avons pu, par la programmation aussi, dénir le format du chier,
c'est-à-dire, l'entête du chier Excel, la taille de la police, la largeur des colonnes, la
bordure du tableau,...
Nous illustrons un exemple de chier Excel que nous avons pu exporter.
101

101. Chapitre 5. Réalisation et test
Figure 64 Exemple de Backlog exporté en chier Excel
2. Exportation des graphiques
En plus du chier Backlog, les graphiques d'évaluation du sprint décrits dans le
paragraphe précédent peuvent être exportés.
De la même façon, l'exportation de ces graphes se fait par la création d'un chier
Excel, la dénition de son format et l'ajout des informations utiles. Tout cela se fait
à l'aide des classes fournies par la bibliothèque NPOI.
Figure 65 Exemple de graphe exporté en chier Excel
Le chier Excel généré contient d'une part l'image du graphe et d'autre part un
tableau contenant les paramètres représentés dans le graphe ainsi que leurs valeurs.
102

102. Chapitre 5. Réalisation et test
Un exemple de graphe exporté en chier Excel est donné dans la gure 65. Ce graphe
correspond à la performance du sprint. Les données représentant les cinq barres sont
fournis dans un tableau avec les valeurs correspondantes.
5.4 Scénarios d'exécution
Au cours de ce paragraphe, nous décrivons les scénarios possibles dans notre applica-
tion.
I Scénario 1 : L'administrateur peut ajouter un chef de projet à la plateforme
Figure 66 Interface de l'ajout d'un chef de projet
L'administrateur saisit le nom et le prénom du chef de projet, et clique sur le bouton
Ajouter. L'application se charge d'attribuer au chef de projet un login et un mot
de passe sous un format spécique. Le login correspond au format prénom.nom, et
le mot de passe prend la structure prno. L'utilisateur ajouté par un administrateur
prend automatiquement le rôle de chef de projet.
I Scénario 2 : Le chef de projet peut ajouter un nouveau projet.
L'interface ci-dessous (gure 67) permet au chef de projet, après s'être authentié, de
saisir les coordonnées d'un projet et de conrmer son ajout. Pour ce faire, il doit saisir
l'intitulé du projet, ses dates de début et de n, la durée d'un sprint appartenant à
ce projet, le jour de la semaine par lequel débute un sprint et le nombre de ressources
qui vont participer à ce projet. La saisie d'une description du projet est optionnelle.
103

103. Chapitre 5. Réalisation et test
Figure 67 Interface de l'ajout d'un nouveau projet
Pour la spécication des dates de début et de n, l'application lui permet d'ajouter
une date depuis un calendrier, comme le montre la gure suivante.
Figure 68 Interface de la sélection d'une date de début du projet à travers un
calendrier
Nous avons programmé le calendrier de telle sorte que les weekends et les jours fériés
soient grisés et ceci an d'empêcher l'utilisateur de choisir, sans le savoir, des dates
non valides.
Après avoir saisi les données du projet et appui sur le bouton Ajouter, le chef de projet
se redirige vers une deuxième page qui concerne l'ajout des ressources au projet ainsi
créé.
L'interface illustrée par la gure 69 fournit l'ensemble des ressources libres (qui ne
sont pas aectés à d'autres projets). Le chef de projet sélectionne une ressource parmi
la liste à gauche. Il clique sur la èche droite, la ressource se déplace alors vers la liste
104

104. Chapitre 5. Réalisation et test
à droite et disparaît de la première liste. Il refait la même procédure jusqu'à ajouter
toutes les ressources participantes. Dans le cas où il a ajouté une ressource à la liste
de droite puis il a changé d'avis, il peut l'enlever et la renvoyer vers la liste gauche
en utilisant la èche en bas.
Figure 69 Interface de l'ajout des ressources au projet
Dans le cas où le chef de projet veut ajouter une nouvelle ressource n'ayant participé
à aucun ancien projet, il clique sur le lien en bleu Ajouter une ressource. Cela le
redirige vers une autre page.
Figure 70 Interface d'ajout d'une nouvelle ressource
105

105. Chapitre 5. Réalisation et test
Retournons à l'interface de la gure 69, après avoir introduit toutes les ressources
au projet, le chef de projet clique sur le bouton Valider. Les ressources sont ainsi
ajoutées au projet.
I Scénario 3 : Le chef de projet peut gérer un projet.
La page d'accueil de l'acteur Chef de projet (Figure 71) lui ache la liste des projets
qu'il dirige actuellement. Le chef de projet peut éditer les paramètres du projet
(modier sa date de début ou de n, modier les ressources y participant,...). Il peut
aussi accéder à l'espace du projet en cliquant sur le lien Ouvrir. Enn, il a la
possibilité de clôturer le projet lorsqu'il juge qu'il a atteint sa n.
Figure 71 Interface de la page d'accueil d'un chef de projet
L'espace d'un projet quelconque (Figure 72) contient un menu permettant d'accéder
aux diérentes pages qui décrivent l'état du projet et ses diérents éléments. Dans
cet espace, le chef de projet peut suivre le travail au cours du sprint courant, il peut
aussi gérer le chier Backlog du sprint ou encore visualiser les graphes de statistiques
du sprint en cours. De plus, un tableau de bord est aché (gure 72), il présente le
projet d'une façon générale, ses ressources, les notications de n de tâches et donne
une idée générale sur l'avancement du sprint courant.
Pour acher l'une de ces pages, il clique sur l'un des liens fournis à gauche : Tableau
de bord, Backlog, Planication Sprint, Performance du sprint.
Nous allons présenter chacune de ces pages lors de la description des scénarios dans
ce qui suit.
106

106. Chapitre 5. Réalisation et test
Figure 72 Interface de la page Espace de projet
I Scénario 4 : Le chef de projet ajoute les tâches au chier Backlog.
En cliquant sur le lien Backlog du menu à gauche, le backlog du sprint courant
s'ache (Figure 73). Un premier Backlog doit être crée au début du projet et les
tâches planiées pour ce Backlog sont ajoutées par le chef de projet. Pour cela, il
appui sur le lien entouré par un cercle jaune, un formulaire d'ajout d'une tâche sera
aché (gure 74).
Figure 73 Interface de la page Backlog du sprint courant
107

107. Chapitre 5. Réalisation et test
Le chef de projet saisit les paramètres de la tâche (gure 74), puis appui sur le bouton
Ajouter pour enregistrer la tâche et revenir au Backlog. Pour ajouter plusieurs
tâches sans revenir à chaque fois au chier Backlog, il clique sur le bouton Ajouter
et poursuivre et saisi les coordonnées d'une nouvelle tâche et ainsi de suite.
Figure 74 Interface de l'ajout d'une tâche au Backlog
I Scénario 5 : Le chef de projet peut exporter le Backlog en chier Excel.
Etant donné que le Backlog peut être communiqué au le client, notre application
donne la possibilité de l'exporter en chier Excel pour être stocké en externe. Pour
ce faire, le chef de projet clique sur le lien Exporter en chier Excel entouré par le
cercle en vert (gure 73). La fenêtre Ouverture de Backlog.xls demande à l'utilisa-
teur soit d'ouvrir le chier ou bien de l'enregistrer sur l'ordinateur (gure 75).
Figure 75 Exportation du Backlog
108

108. Chapitre 5. Réalisation et test
Nous obtenons un chier Excel (gure 76) dont l'entête contient le numéro du backlog
et le nom du projet correspondant. Ce chier représente un tableau dans lequel chaque
ligne représente une tâche du backlog. Toutes les données courantes des tâches du
backlog seront enregistrées dans ce chier.
Figure 76 Fichier Excel d'un Backlog exporté
I Scénario 6 : Le chef de projet peut ajouter un congé
Le chef de projet a la possibilité d'enregistrer un congé pour un développeur. Pour ce
faire, il choisit le nom du développeur correspondant depuis la liste déroulante (gure
77), il choisit la date de début du congé, il peut aussi spécier si le congé commence
le matin ou bien l'après-midi. Enn, il choisit la date de n du congé et indique si le
congé se prolonge pour la matinée ou bien jusqu'à la n de la journée.
Figure 77 Ajout d'un congé
109

109. Chapitre 5. Réalisation et test
I Scénario 7 : Le chef de projet planie le sprint lié au Backlog ainsi créé.
Avant de commencer le travail des tâches introduites dans le Backlog, il faut planier
le sprint. Le chef de projet est le responsable de la planication d'un sprint. Pour ce
faire, il aecte les tâches du Backlog aux ressources qu'il choisit depuis les ressources
participantes au projet. Le système s'assure de la disponibilité de chaque ressource; il
vérie que la personne n'est pas en congé et n'a pas d'autres tâches en même temps.
Avant de commencer la procédure, le chef de projet doit xer la date de début du
sprint (gure 78). L'application se charge de calculer la date de n du sprint selon
la durée de sprint enregistrée dans les paramètres du projet. De plus, l'application
récupère les congés des développeurs durant la période du sprint et les ache dans
un tableau (gure 79) pour mettre le chef de projet au courant de ces congés.
Figure 78 Choix de la date de début du sprint à planier
En cliquant sur le bouton Valider (gure 78), l'utilisateur sera redirigé vers une
interface qui contient les diérents éléments contribuant à la planication du sprint
(gure 79). Le premier panneau Période du sprint spécie la date de début et de n
du sprint. Le deuxième panneau contient d'une part la partie d'aectation des tâches,
et d'autre part un tableau qui présente les congés durant le sprint. Enn, le dernier
panneau regroupe les aectations planiées (dans la gure, aucune aectation n'est
planiée pour le moment).
110

110. Chapitre 5. Réalisation et test
Figure 79 Interface de la planication d'un sprint
Figure 80 Aectation d'une tâche
111

111. Chapitre 5. Réalisation et test
On commence par aecter les tâches une par une (gure 80). Lorsque le chef de
projet choisit une tâche depuis la première liste déroulante, la durée de la tâche sera
achée dans le champ Durée de la tâche. Puis, il choisit la date de début de la
réalisation de la tâche, il peut même choisir de commencer la tâche le matin ou bien
l'après-midi à travers la liste déroulante Heure. Selon la date et l'heure choisies,
le système vérie la disponibilité des ressources et ache une liste déroulante qui ne
contient que les ressources disponibles. L'exemple de la gure 80 montre que la tâche
choisie est d'une durée de trois jours, et ache les ressources disponibles pendant les
trois jours commençant à partir du 22/05. On remarque que le développeur Karim
n'appartient pas à la liste, et ceci est normal puisqu'il est en congé comme le montre
le tableau des congés à droite.
Toutes les tâches étant aectées, il fallait alors valider toute l'opération en cliquant
sur le bouton Sauvegarder le sprint en bas à droite (gure 81).
Figure 81 Sauvegarde du sprint et des tâches aectées
La sauvegarde de la planication sprint entraîne directement la création de toutes
les aectations sous forme de post-it et leurs organisations dans le tableau de sprint
(gure 82). Au départ, toutes les aectations sont en état à faire et donc sont
placées dans la colonne Tâches à faire du tableau.
112

112. Chapitre 5. Réalisation et test
Figure 82 Tableau de planication de sprint
I Scénario 8 : Le développeur accède à l'espace du projet auquel il appartient
Figure 83 Tableau de de bord d'un développeur
113

113. Chapitre 5. Réalisation et test
En se connectant, le développeur est redirigé directement vers l'espace du projet
auquel il participe puisqu'il ne peut appartenir qu'à un seul projet en même temps.
Le tableau de bord d'un développeur (gure 83) contient quatre panneaux : le premier
contient une description rapide du projet courant, le deuxième panneau liste les tâches
du développeur connecté durant le sprint en cours ainsi que leurs états actuels (à faire,
en cours ou nie), le troisième (celui à droite) expose les ressources qui participent au
projet, et enn le quatrième montre l'avancement du sprint courant via une courbe
qui calcule le reste à faire pour les tâches du sprint.
I Scénario 9 : Le développeur peut déplacer sa tâche dans les colonnes du tableau de
sprint an de modier son état.
Figure84 Tableau de planication de sprint avec des post-it présentant les tâches
Le déplacement d'une tâche d'une colonne à une autre entraîne la modication de
son état qui prend la valeur de l'état des tâches de cette colonne. Les tâches à faire
prennent la couleur jaune, les tâches en cours sont présentées en couleur orangé et
les tâches nies sont marquées en vert. Chaque développeur ne peut déplacer que ses
propres tâches, le nom de la ressource au-dessous de la petite image d'avatar marque
le nom du développeur responsable de la tâche. Le déplacement d'une tâche se fait
par un simple drag and drop .
114

114. Chapitre 5. Réalisation et test
I Scénario 10 : Modier l'avancement de sa tâche
Chaque ressource peut aussi éditer sa propre tâche. Le petit pinceau en haut à droite
du post-it indique que la tâche peut être éditée par la ressource connectée. On observe
dans l'interface ci-dessus (gure 84) que seule la dernière tâche qui est jaune possède
l'image du pinceau. Cette tâche porte le nom Najla qui correspond bien au nom
de l'utilisateur connecté.
Figure 85 Editer une tâche
Le développeur peut alors modier l'avancement dans la tâche, il introduit le pour-
centage qu'il a atteint dans la réalisation de la tâche. Il peut aussi modier l'état de
la tâche à partir de cette interface. Pour cela, il change l'état depuis la liste dérou-
lante Statut. Enn, le développeur peut marquer qu'il a rencontré un problème en
sélectionnant la case à cocher Problème . La sélection de cette case change l'état
de la tâche en état bloquée, le post-it devient rouge.
Figure 86 Tâche bloquée
115

115. Chapitre 5. Réalisation et test
I Scénario 11 : L'utilisateur peut visualiser les statistiques de performance du sprint
L'application fournit des graphes de statistiques qui décrivent l'avancement du sprint
en cours, et des graphes qui évaluent la performance de la totalité du sprint à sa n.
Lorsque le sprint n'est pas encore clôturé, un ensemble de graphes qui décrivent
l'avancement quotidien du travail un ensemble de graphes qui décrivent l'avancement
quotidien du travail est mis à notre disposition. Des icônes présentant les types des
courbes fournies sont exposées dans un panel en haut de la page. En cliquant sur
une de ces icones, nous obtenons le graphe correspondant en grande taille (gure 87).
Chaque courbe est décrite seule dans le paragraphe Phase d'implémentation.
Figure 87 Statistiques de suivi du sprint en cours
Lorsque le sprint est clôturé, nous obtenons d'autres graphes qui montrent la perfor-
mance du sprint, de l'équipe et de l'entreprise en général (gure 88).
116

116. Chapitre 5. Réalisation et test
Figure 88 Statistiques d'évaluation du sprint clôturé
I Scénario 12 : L'utilisateur peut exporter un graphe en chier Excel
Pour exporter un graphe en chier Excel, il sut de cliquer sur le lien entouré en
cercle rouge (gure 88). Le chier exporté contiendra d'une part l'image du graphe
exporté, et d'autre part, les valeurs des paramètres présentés dans le graphe (voir
gure 65).
I Scénario 13 : L'utilisateur reçoit une notication
Suite à un évènement spécique, l'utilisateur reçoit une notication. Ces évènements
peuvent correspondre à la terminaison d'une tâche, à l'ouverture d'une discussion ou
la résolution d'une discussion. Nous présentons ce scénario en lançant deux naviga-
teurs diérents, chaque navigateur représente un utilisateur connecté.
Nous avons lancé deux navigateurs pour deux utilisateurs diérents (gure 89). Le
nom de chaque utilisateur est encadré par un cadre jaune, l'utilisateur du naviga-
teur à droite représente le chef du projet auquel participe l'utilisateur du naviga-
teur à gauche. Lorsque l'utilisateur déplae sa tâche dans la colonne des tâches nies
(première étape marquée par la èche rouge), un plus apparaît sur l'icône des no-
tications du chef de projet (étape deux marquée par le cercle rouge). Ce plus
signie que l'utilisateur a reçu une nouvelle notication. En cliquant sur l'icône des
notications, le chef de projet trouve une nouvelle notication marquée en couleur
117

117. Chapitre 5. Réalisation et test
diérente (gure 90). Cette notication est de type tâche nie, elle indique que la
tâche exporter backlog du développeur Karim a été terminée.
Figure 89 Déclenchement d'une notication suite à l'évènement de terminaison
d'une tâche
Figure 90 Nouvelle notication ajoutée
Nous faisons un deuxième test qui concerne la génération d'une notication lors
du déclenchement d'une nouvelle discussion. Cette fois-ci, nous avons lancé deux
navigateurs pour deux développeurs d'une même équipe (gure 90).
118

118. Chapitre 5. Réalisation et test
Figure 91 Lancement d'une nouvelle discussion
L'utilisateur du navigateur à gauche introduit le titre de la discussion et l'énoncé de
son problème. En cliquant sur le bouton Déclencher, tous les utilisateurs du projet
auquel il participe vont être notiés par l'ouverture de cette discussion. Faisons un
zoom sur le navigateur à droite, nous voyons qu'une nouvelle notication a été ajoutée
(gure 92 et 93).
Figure 92 Réception d'une notication suite à l'évènement de l'ouverture d'une
nouvelle discussion
Figure 93 Nouvelle notication ajoutée
119

119. Chapitre 5. Réalisation et test
5.5 Tests réalisés
I Tests unitaires
Tester une application c'est vérier son bon fonctionnement. Il existe diérents types
de tests : test unitaire, test d'intégration, test fonctionnel. Le test unitaire représente
la plus petite unité de test possible, il s'assure que chaque classe ou chaque méthode
fonctionne correctement. Il permet d'améliorer la qualité du code et garantir sa abi-
lité. De manière très concrète, les test unitaires sont des fonctions ou des classes qui
testent le résultat d'une fonction ou d'une classe en passant des données en entrée et
en comparant les données en sortie. Si, en passant A j'obtiens B alors que j'attendais
C, le test est faux. Au contraire, si en passant A j'obtiens C, le test est vrai [14].
Durant notre projet, nous avons réalisé des tests unitaires sur les méthodes de la
couche d'accès aux données et la couche métier. Par exemple, dans la couche d'accès
aux données, pour chaque classe DAO nous avons créé une classe de test. Nous
présentons dans ce paragraphe quelques exemples de tests unitaires.
Nous nous intéressons à la classe AectationDAO comme exemple de classe testée;
une classe de test a été créée pour tester les méthodes de cette classe. En lançant le
test de la méthode Save(), nous obtenons un résultat réussi comme le montre le mot
Passed entouré par un cercle rouge dans le panneau de résultat de test (gure
94).
Figure 94 Exemple de test réussi
Comme un exemple de test échoué, nous présentons celui de la méthode qui récupère
les ressources participantes à un projet. Nous avons spécié dans la méthode de
test que le résultat attendu est : deux ressources, alors que le nombre de ressources
eectives pour ce projet est quatre. Le test nous ache alors un échec et nous indique
que le nombre actuel est quatre (gure 95).
120

120. Chapitre 5. Réalisation et test
Figure 95 Exemple de test échoué
I Tests fonctionnels :
Conduits dans un contexte le plus proche possible de l'utilisateur nal, les tests
fonctionnels permettent de dégager les problèmes que peut rencontrer l'utilisateur et
les questions qu'il peut se poser durant son utilisation de l'application. Ces tests ont
permis d'améliorer l'ergonomie des interfaces et faciliter leurs utilisations. Dans ce qui
suit, nous présentons quelques cas où nous avons enrichi l'interface avec des messages
qui améliorent la communication avec l'utilisateur et le guide durant l'utilisation de
notre application.
− Message d'erreur lors de la planication d'un sprint :
Lors de la planication des tâches du sprint et dans le cas où l'utilisateur choisit
une date de début de la tâche qui n'est pas incluse dans la période du sprint.
Suite à l'appui sur le bouton Ajouter Aectation , un message d'erreur s'af-
che en rouge pour le prévenir que la date qu'il a choisi est non valide (gure
96).
Figure 96 Message d'erreur suite au choix d'une date de début non valide
121

121. Chapitre 5. Réalisation et test
− Message de conrmation suite à l'ajout des ressources à un projet créé :
Dans le cas où les ressources ajoutées au projet ne sont pas égaux au nombre
de ressources introduit dans les paramètres du projet (Figure 67), un message
de conrmation s'ache. Ce message attire l'attention du chef de projet qu'il
n'a pas obéit au nombre de ressources qu'il a saisi auparavant et lui demande
de conrmer ce nouveau nombre ou d'annuler et régler les ressources ajoutées.
Figure 97 Message de conrmation
− Message de validation durant l'ajout d'un chef de projet :
Lorsqu'un administrateur ajoute un chef de projet, l'application vérie s'il a bien
saisi le nom et le prénom du chef de projet. Si ce n'est pas le cas, un message
de validation de saisi sera aché pour lui informer que l'introduction de ces
champs est obligatoire.
Figure 98 Messages de validation de la saisie de champs obligatoires
122

122. Chapitre 5. Réalisation et test
Conclusion
Ce dernier chapitre nous a servi à présenter les résultats de la réalisation de notre
application. Nous avons commencé par décrire l'environnement matériel et logiciel qui a
permis de mettre en place le projet. Nous avons ensuite expliqué le travail eectué pendant
la phase d'implémentation. L'implémentation du code a été validée par des tests unitaires
qui ont permis de garantir la abilité de chaque composant indépendamment de l'intégrité
du code de l'application. Enn, des tests fonctionnels ont été eectués sur l'application
réalisée an de vérier l'ergonomie, l'utilisabilité et l'ecience de ses diérentes interfaces.
Nous cloturons notre rapport par une conclusion générale et les perspectives de notre
projet.
123

123. Conclusion et perspectives
Le nombre de projets devient de plus en plus important et les entreprises se mettent
en concurrence dans un marché énorme. Face à cette croissance et cette concurrence,
la conduite de ses projets présente l'issu majeur de toute entreprise voulant garantir la
réussite de ses projets.
Adopter une méthodologie de gestion de projet est primordial pour pouvoir mener une
équipe et atteindre avec ecacité les objectifs tout en répondant aux exigences du marché.
De plus, l'utilisation d'un outil spécialisé de la méthodologie choisie est important dans
la mesure où il facilite les tâches du gestionnaire du projet et ore à l'équipe un cadre de
collaboration qui leur permet d'atteindre le but commun à savoir la réussite du projet.
C'est dans ce contexte que ce projet de n d'étude a été mené. Le but de ce projet était
donc de mettre en place une plateforme web qui permet la gestion des projets de Telnet.
SCRUM étant la méthodologie de gestion de projet adopté par Telnet, l'application web
développée s'est alors basée sur les principes et artefacts de Scrum avec une adaptation
selon les besoins exprimés par l'entreprise. L'outil a intégré aussi un aspect interactif
qui favorise un cadre pour l'échange d'information et de connaissances entre les membres
d'une équipe.
Ce travail a été très instructif dans la mesure où il m'a permis de me familiariser
avec le développement Web et de maîtriser un ensemble important de technologies qui
contribuent à l'amélioration des applications Web. Ce stage était une opportunité pour
moi pour d'une part m'initier au monde réel de l'entreprise et d'autre part vivre les
diérentes phases du cycle de vie d'un projet, dès son étude jusqu'à son déploiement.
A l'issu de ce travail, plusieurs perspectives peuvent être envisagées. Une première
amélioration possible est l'intégration d'un module qui permet de mener les réunions
journalière et de n de sprint entre les membres d'une équipe à travers l'application elle-
même. Ce module correspond à un système de conférence permettant aux membres d'une
équipe d'assister aux réunions à distance. Cette amélioration sera importante surtout
pour les projets dont l'équipe est distribuée entre deux pays ou plus. Comme deuxième
idée d'évolution de l'application, nous pouvons mettre en place un système d'alerte qui
permet de prévoir le développeur des tâches qu'il fallait réaliser pour le jour actuel. En-
n, une dernière amélioration pouvant être intégrée est celle de fournir un agenda dans
lequel l'utilisateur peut noter ses rendez-vous. Cet agenda sert essentiellement à rappeler
l'utilisateur des dates et heures des réunions auxquelles il doit assister.
124

124. Bibliographie
[1] Veronique Messager Rota, Méthodes AGILES : une belle dénition, Gestion de
projet : Vers les méthodes agiles, (2007).
[2] Freddy, http://freddy.yimo.fr/pro/2009/11/23/scrum-le-vocabulaire-tournant-
autour-du-scrum, (consulté le
11/02/2013).
[3] Claude Aubry,
http://www.aubryconseil.com/post/2007/01/07/148-le-role-de-scrummaster,
(consulté le 10/02/2013).
[4] Brad Swanson, http://www.openlogic.com/wazi/bid/188152 , (consulté le
13/02/2013).
[5] Amine Chaghal, http://blog.neoxia.com/story-points-5-minutes-pour-comprendre,
(consulté le 10/02/2013).
[6] Claude Aubry,
http://www.aubryconseil.com/post/2007/07/17/262-glossaire-scrum, (consulté le
09/02/2013).
[7] Axel Ullern,
http://www.journaldunet.com/solutions/expert/50420/projets-informatiques-sans-
gouvernance-ni-conduite-du-changementle-deraillement-assure.shtml, (consulté le
05/05/2013).
[8] Rémi Bachelet, http://gestiondeprojet.pm, (consulté le 05/05/2013).
[9] Daniel FAYEN, http://danielfayen.com/scrum.htm, (consulté le 05/05/2013).
[10] Bruno Mermet,
https://mermet.users.greyc.fr/Enseignement/CoursPDF/MVC.pdf, (consulté le
14/05/2013).
[11] Olivier Mengué, http://journeesperl.fr/fpw2006/slides/intro-orm.html, (consulté
le 18/05/2013).
125

125. Bibliographie
[12] Stéphane THIROUX,
http://www.realstudio-fr.com/orm-le-mapping-objet-relationnel, (consulté le
20/05/2013).
[13] Paul Musso,
http://pmusso.developpez.com/tutoriels/dotnet/entity-framework/introduction/,
(consulté le 19/05/2013).
[14] Nicolas Hachet, http://blog.nicolashachet.com/2013/01/18/methodes/a-propos-
des-tests-unitaires-automatises, (consulté le
26/05/2013).
[15] http://www.techno-science.net/?onglet = glossairedefinition = 743, (consulté le
05/05/2013).
[16] http://www.agilefant.org/wiki/display/AEF/Features, (consulté le 04/02/2013).
[17] http://www.versionone.com/Product/agile-program-management-tools, (consulté le
04/02/2013).
[18] http://www.thoughtworks-studios.com/mingle-agile-project-management/features-
benets, (consulté le
04/02/2013).
[19] http://bertrandkeller.info/2009/12/22/1705-pivotal-tracker-la-collaboration-en-
temps-reel, (consulté le
05/02/2013).
[20] http://esi.namok.be/brol/java/Guide-MVC.pdf, (consulté le 14/05/2013).
[21] http://www.mcnext.com/pole_dotnet/dotnet/Pages/ASPNet-MVC.aspx, (consulté
le 18/05/2013).
[22] http://www.commentcamarche.net/contents/577-javascript-introduction-au-langage-
javascript, (consulté le
20/05/2013).
[23] http://www.yoja-web.com/fr/javascript/jquery-presentation, (consulté le
19/05/2013).
[24] http://msdn.microsoft.com/fr-fr/library/dd410123(v=vs.98).aspx, (consulté le
19/05/2013).
[25] http://www.groupe-telnet.com/, (consulté le 27/05/2013).
126