Rapport_finale.docx

REPUBLIQUE TUNISIENNE
********
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR, DE LA
RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE
********
DIRECTION GENERALE DES ETUDES TECHNOLOGIQUES
********
INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES
DE CHARGUIA
********
Département Technologies de l’Informatique
RAPPORT DE
Projet de Fin d’Etudes
Présenté en vue de l’obtention du diplôme De
Licence appliquée en technologies d’informatique
Sujet
Conception et développement d’un outil de

gestion de projet Scrum
Encadré Par: Elaboré par :
Mme Ahlem Tayachi Saber Gannouni
Mr. Radhouani Aref Mohamed baha

eddine oueslati
Société d’accueil : " Centre National de Formation de Formateurs et d’Ingénierie

de Formation à Rades "
Année Universitaire : 2016/2017

Remerciements
On profite par le biais de ce rapport d’exprimer nos vifs remerciements à toute personne
contribuant de près ou de loin à la réalisation de ce projet.
On tient à remercier vivement Mme Ahlem Tayachi, notre cher professeur et encadrant, qui a
contribué, énormément, à la réalisation de ce projet. Un grand merci pour ses remarques, ses
directives, sa bienveillance, et l’intérêt qu’elle porte à ses étudiants.
Un merci bien particulier adressé également à Mr. Radhouani Aref pour sa disponibilité, ses
conseils et l’aide qu’il nous a accordés et surtout pour sa patience terminables qui a été déterminantes
dans l’élaboration de ce travail.
On tient, également à remercier tous nos amis(e)s qui ont fait de ces trois années à l’ISET
Charguia des années pleines de bons souvenirs.
Finalement, on présente toute nos gratitudes au corps pédagogique et administratif de l’ISET

Charguia pour leur formation et leur encadrement durant les trois années.
Résumé
Ce rapport décrit le travail qu’on a réalisé dans le cadre de l’obtention de notre licence appliquée en
technologie de l'informatique ISETCH, il s’est déroulé du 6 Février au 12 mai 2017 effectué au sein de
Centre National de Formation de Formateurs et d’Ingénierie de Formation à rades. Durant les trois
mois, notre mission consiste à développer une application de gestion de projet dans un cadre de
développement agile. L’application va permettre aux équipes de développement de collaborer sur
des projets pilotés selon la méthodologie agile Scrum. Le but de l’application est de faciliter le
pilotage des projets en offrant une version numérique des nombreux artefacts de la méthode Scrum
(Carnet du produit, Itérations, Cartes, Taches, tableau des taches etc.)Ce rapport se propose de
décrire les différentes étapes par lesquelles le projet a passé dans le but d’atteindre la solution
actuelle.
Abstract
This report describes the work we carried out in the context of obtaining our ISETCH Computer
Technology License, which took place from 6 February to 12 May 2017 at the National Training
Center Trainers and Engineering Training in rades.Over the next three months, our mission is to
develop a project management application with an agile development framework. The application
will enable development teams to collaborate on projects piloted using Scrum agile methodology.
The purpose of the application is to facilitate the project management by offering a digital version of
the numerous artifacts of the Scrum method (Product Log, Iterations, Maps, Tasks and Task Table
etc.)The purpose of this report is to describe the different stages in which the project was carried out
in order to achieve the present solution.
‫تلخيص‬
‫ العالي‬:‫يصف هذا التقرير العمل الذي قمنا بتنفيذه للحصول على االجازة التطبيقية لتطوير االنظمة المعلوماتية بالمعهد‬
‫للدراسات التكنولوجية بالشرقية وقد تم اجراء هذا المشروع في المركز الوطني للتدريب المدربين والموانئ في هندسة‬
‫ التطبيق سوف لفرق‬.‫ مهمتنا كانت تطوير اداة إلدارة المشاريع في إطار الطرق الرشيقة‬،‫ خالل األشهر الثالثة‬.‫التكوين‬
‫العمل على قيادة مشاريعهم والغرض من هذا التطبيق هو تسهيل إدارة المشاريع من خالل تقديم نسخة رقمية االداة سكروم‬
‫وهذا التقرير هو لوصف مختلف الخطوات التي اجتازها المشروع كي يصل إلى النتيجة الحالية‬.
Table des matières
INTRODUCTION GÉNÉRALE.............................................................................................................................1
CHAPITRE 1 PRÉSENTATION DU CADRE DU PROJET.................................................................3
Introduction..............................................................................................................................................................4
I. Présentation de la société................................................................................................................................4
I.1 Historique....................................................................................................................................................4
I.2 Missions.......................................................................................................................................................4
II. Etude de marché..............................................................................................................................................5

II.1 Le marché visé.........................................................................................................................................5
II.1.1 Rally....................................................................................................................................................5
II.1.2 VersionOne.........................................................................................................................................6
II.1.3 ScrumDesk..........................................................................................................................................6
II.1.4 ScrumWorks........................................................................................................................................7
II.1.5 Agilo....................................................................................................................................................8
II.2 Etudier la concurrence............................................................................................................................8
II.3 Solution proposée..................................................................................................................................11
III. Méthodologie adoptée...............................................................................................................................12

III.1 Tableau comparatif...............................................................................................................................13
III.2 Notre choix............................................................................................................................................13
III.3 Le langage de modélisation UML.........................................................................................................14
CHAPITRE 2 INTRODUCTION AUX MÉTHODES AGILES ET SCRUM......................................16
Introduction............................................................................................................................................................17
I. Que sont les méthodes agiles ?......................................................................................................................17
II. Pourquoi utiliser les méthodes agiles ?.........................................................................................................17

II.1 Les différentes méthodes agiles.............................................................................................................17
II.2 La méthode SCRUM..............................................................................................................................18
II.2.1 Les valeurs de la méthode SCRUM..................................................................................................18
II.2.2 Qu'est-ce que la méthode SCRUM....................................................................................................18
II.2.3 Les rôles............................................................................................................................................19
II.2.4 Les artéfacts......................................................................................................................................21
II.2.4.1 Storie « user story »................................................................................................................21
II.2.4.2 Les tâches.................................................................................................................................21
II.2.4.3 Backlog....................................................................................................................................22
II.2.4.4 Graphique d'avancement.........................................................................................................23
Conclusion..............................................................................................................................................................25
CHAPITRE 3 SPÉCIFICATION DES BESOINS................................................................................26
Introduction............................................................................................................................................................27
I. Etude des besoins...........................................................................................................................................27

I.1 Besoins fonctionnels..................................................................................................................................27
I.2 Besoins non fonctionnels....................................................................................................................30
II. Les diagrammes de cas d’utilisation..............................................................................................................30
II.1 Présentation des acteurs.......................................................................................................................30
II.2 Description des cas d’utilisation...........................................................................................................31
II.2.1 Diagramme de cas d’utilisation général..........................................................................................31
II.2.2 Raffinement des cas d’utilisation......................................................................................................32
II.2.2.1 Cas d’utilisation "Créer un projet "........................................................................................33
II.2.2.2 Cas d’utilisation "Supprimer un projet ".................................................................................34
II.2.2.3 Cas d’utilisation "quitter un projet ".......................................................................................34
II.2.2.4 Cas d’utilisation "Gérer équipe".............................................................................................35
II.2.2.5 Cas d’utilisation "Gérer itération"..........................................................................................37
II.2.2.6 Cas d’utilisation "Gérer stories "............................................................................................38
II.2.2.7 Cas d’utilisation "Gérer taches "............................................................................................38
II.2.2.8 Cas d’utilisation « Visualiser les graphiques »......................................................................42
II.2.3 Diagrammes de séquences système..................................................................................................42
II.2.3.1 Diagramme de séquences système « S’authentifier ».............................................................42
II.2.3.2 Diagramme de séquences système « Associer une storie a une itération »............................44
II.2.3.3 Diagramme de séquences système « démarrer une itération »...............................................45
II.2.3.4 Diagramme de séquences système « restaurer storie »..........................................................46
II.2.3.5 Diagramme de séquences système « Ajouter tache »............................................................48
CHAPITRE 4 CONCEPTION................................................................................................................50
Introduction............................................................................................................................................................51
I. Architecture globale de la solution................................................................................................................51
II. Conception du niveau données......................................................................................................................53

II.1 Description des classes.........................................................................................................................53
II.2 Règle de gestion....................................................................................................................................55
II.3 Diagramme de classe............................................................................................................................56
II.4 Schéma relationnel................................................................................................................................57
III. Conception du niveau application.............................................................................................................58

III.1 Digrammes de séquences......................................................................................................................58
III.1.1 Digramme de séquence objet « S’authentifier »..........................................................................59
III.1.2 Digramme de séquence objet « Accéder à un projet »................................................................60
III.1.3 Digramme de séquence objet « S’engager à une tache »............................................................61
III.1.4 Digramme de séquence objet« Terminer une tâche ».................................................................62
III.2 Diagramme d’activités..........................................................................................................................63
III.2.1 Diagramme d’activité « Compléter une storie ».........................................................................64
III.2.2 Diagramme d’activité « Compléter une iteration ».....................................................................65
III.2.3 Diagramme d’activité « Compléter un projet»............................................................................66
IV. Conception du niveau présentation...........................................................................................................66

IV.1 Tableau de bord projet..........................................................................................................................66
IV.2 Tableau de bord Itération.....................................................................................................................67
IV.3 Tableau de bord storie..........................................................................................................................68
IV.4 Page de graphique de vélocité..............................................................................................................69
IV.5 Page de graphique d’avancement.........................................................................................................70
V. Déploiement...................................................................................................................................................71
Conclusion..............................................................................................................................................................72
CHAPITRE 5 LA RÉALISATION........................................................................................................73
Introduction............................................................................................................................................................74
I. Environnement de développement.................................................................................................................74
I.1 Environnement matériel............................................................................................................................74
I.2 Environnement logiciel..............................................................................................................................75
I.2.1 Les Framework.................................................................................................................................75
I.2.2 Les Outils..........................................................................................................................................76
II. Les interfaces.................................................................................................................................................77

II.1 La page d’index.....................................................................................................................................77
II.2 L’interface de connexion.......................................................................................................................78
II.3 Tableau de bord projet..........................................................................................................................79
II.4 Page d’accueil.......................................................................................................................................79
II.5 Page d’équipe........................................................................................................................................80
II.6 Page de graphique d’avancement.........................................................................................................80
II.7 Page de graphique de vélocité..............................................................................................................81
II.8 Tableau de bord storie..........................................................................................................................82
II.9 Page rétrospectives...............................................................................................................................82
III. Chronogramme..........................................................................................................................................83
Conclusion..............................................................................................................................................................84
CONCLUSION GÉNÉRALE................................................................................................................................85
BIBLIOGRAPHIE ET NÉOGRAPHIE...............................................................................................................86
Liste des figures
Figure 1 Interface grafique de Rally.......................................................................................................5
Figure 2 Interface grafique VersionOne.................................................................................................6
Figure 3 Interface grafique ScrumDesk..................................................................................................6
Figure 4 Interface grafique ScrumWorks...............................................................................................7
Figure 5 Interface grafique Agilo...........................................................................................................8
Figure 6 sommaire des outils évalués.....................................................................................................8
Figure 7 critères d'evaluation................................................................................................................11
Figure 8 diagramme de cote totale pour chaque outil...........................................................................11
Figure 10 Graphique d’effort individuel...............................................................................................12
Figure 11 Tableau comparatif...............................................................................................................13
Figure 12 Cycle en cascade..................................................................................................................14
Figure 13 : Diagramme UML utilisé....................................................................................................15
Figure 14 Processus de développement « scrum »................................................................................19
Figure 15 Exemple de décomposition d'une storie en tâches................................................................22
Figure 16 Exemple de Backlog Produit................................................................................................23
Figure 17 Burndown Chart...................................................................................................................24
Figure 18 Graphique de vélocité...........................................................................................................25
Figure 19 Les acteurs...........................................................................................................................28
Figure 20 Diagramme de cas d’utilisation générale..............................................................................32
Figure 21 : Diagramme de cas d'utilisation " Gestion d’équipe ".........................................................35
Figure 22 Diagramme de cas d'utilisation " gérer itération".................................................................38
Figure 23 Diagramme de cas d'utilisation " Gérer stories"...................................................................38
Figure 24 Diagramme de cas d'utilisation " Gérer taches"....................................................................39
Figure 25 diagramme de cas d’utilisation « visualiser artéfacts ».........................................................42
Figure 26 Diagramme séquence système « S’authentifier»..................................................................43
Figure 27 Diagramme séquence système « Associer une storie â une itération ».................................44
Figure 28 Diagramme séquence système « démarré une itération ».....................................................45
Figure 29 Diagramme séquence système « Restaurer storie»...............................................................47
Figure 30 Diagramme séquence système « Ajouter tache »..................................................................48
Figure 31:architecture Java EE d’une application web en trois couches...............................................52
Figure 32 Diagramme de classe............................................................................................................57
Figure 33 Digramme de séquence objet « S’authentifier »...................................................................59
Figure 34 Digramme de séquence objet « Accéder à un projet »..........................................................60
Figure 35 Diagramme de séquences « S’engager à une tache »............................................................61
Figure 36 Digramme de séquence objet« Terminer une tâche »...........................................................62
Figure 37 Diagramme d'activité "Compléter une storie"......................................................................64
Figure 38 Diagramme d’activité « Compléter une iteration »...............................................................65
Figure 39 Diagramme d’activité « Compléter un projet »....................................................................66
Figure 40 Charte graphique "Dashbord projet"....................................................................................67
Figure 41 Charte graphique "Dashbord iteration".................................................................................68
Figure 42 Charte graphique "Tableau de bord storie"...........................................................................69
Figure 43 Chart graphique "grafique de vélocité"...............................................................................70
Figure 44 Charte graphique "graphique d'avancement"........................................................................71
Figure 45 Diagramme de déploiement..................................................................................................72
Figure 46 Interface graphique « Page d'index »....................................................................................78
Figure 47 Interface graphique « Page d’authentification »...................................................................78
Figure 48 Interface graphique « Tableau de bord projet »....................................................................79
Figure 49 Interface graphique « Page d'accueil ».................................................................................80
Figure 50 Interface graphique « Page d'équipe »..................................................................................80
Figure 51 Interface graphique « Page de graphique d'avancement »....................................................81
Figure 52 Interface graphique « Page de vélocité »..............................................................................81
Figure 53 Interface graphique « Tableau de bord storie »....................................................................82
Figure 54 Interface graphique « Page rétrospectives ».........................................................................82
Figure 55 Diagramme de Gant.............................................................................................................84
Introduction générale
Les entreprises en développement logiciel sont en croissance constante et poursuivent
le but de livrer du logiciel de qualité qui répond au besoin de l’utilisateur, dans les temps
prescrits par le client.
Afin de répondre à ces critères, les entreprises doivent utiliser des processus de
développements logiciel stricts. Il y a plusieurs processus disponibles qui apportent leurs
avantages et leurs inconvénients. Depuis quelques années, l’utilisation de la méthodologie
SCRUM semble gagner en popularité, mais peu d’entreprises s’y aventurent.
SCRUM présente une solution intéressante pour les grandes entreprises qui aimeraient
gagner en flexibilité. En utilisant une méthode évolutive de développement qui implique une
plus grande participation du client dans le processus de développement, les deux parties
voient leurs chances de succès augmentées proportionnellement à la qualité de leurs
communications et de leurs relations.
En utilisant la méthodologie SCRUM dans les grandes entreprises, la qualité du
logiciel est accrue et les nouveaux besoins commandés par la réalité changeante du client sont
considérés tout au long du processus. Une synergie qui gagnerait à être reconnue.
Notre projet de fin d’étude consiste à mettre en place une application de gestion de
projet SCRUM en utilisant la plateforme Java Enterprise Edition. Ce rapport est structuré
comme suit :
Le premier chapitre " La présentation du cadre du projet" qui permet de placer le projet dans
son contexte général en présentant l'organisme d'accueil ainsi qu'une brève description du
projet.
Le second chapitre " Introduction au méthodes agiles et SCRUM " constitue à
présenter de quoi il s’agit les methode agiles et Scrum qui va être la base de notre application
Le troisième chapitre " La spécification des besoins " constitue la première phase de
l’analyse des besoins fonctionnels et non fonctionnels. Dans ce chapitre, on va dévoiler les
principales exigences de notre plateforme et présenter une analyse de ses exigences grâce à
des diagrammes de cas d’utilisation détaillés.
Le troisième chapitre " La conception " constitue le corps du rapport. Ce chapitre sera
consacré à la conception détaillée de la plateforme.
Le dernier chapitre " La réalisation" détaille tous les outils utilisés pour la conception
et le développement de la plateforme ainsi que quelques captures écran de la version finale de
notre système.
2
Chapitre 1
Présentation du cadre du projet
3
Introduction
Au cours de ce premier chapitre, on va présenter, tout d’abord, l’entreprise d’accueil ensuite
notre projet d’une manière succincte ainsi que l’étude de l’existant du projet, suivie d’une
critique pour pouvoir dégager les contraintes à respecter dans le développement de
l’application. La méthodologie adoptée pour la réalisation du projet sera par la suite décrite.
I. Présentation de la société
Le Centre National de Formation de Formateurs et d’Ingénierie de Formation (CENAFFIF)
est un établissement public relevant du Ministère de la Formation Professionnelle et de
l’Emploi tunisien.
I.1 Historique
 1964 : création de l’Institut National de la formation, du perfectionnement
professionnel et de la productivité,
 1993 : promulgation de la Loi n° 12 – 93 qui le transforme en Centre National de
formation de formateurs et d’ingénierie de formation.
 2003 : promulgation de la Loi n° 77 –03 qui en fait un établissement public non
administratif (EPNA), à l’instar des deux autres organismes nationaux de formation
professionnelle : l’Agence Tunisienne de formation professionnelle (ATFP) et le
Centre National de formation continue et de promotion professionnelle (CNFCPP).
I.2 Missions
 Arrêter les méthodologies relatives aux différents domaines de l'ingénierie de la
formation.
 Elaborer et actualiser les programmes de formation professionnelle et aider à leur
implantation dans les établissements de formation.
 Produire les outils et moyens pédagogiques et didactiques nécessaires à la bonne
application des programmes de formation.
 Elaborer les plans de formation technique, pédagogique et fonctionnelle visant la
qualification et le recyclage des personnels de formation relevant des secteurs public
et privé, les mettre en œuvre et en évaluer les résultats.
 Promouvoir la recherche appliquée à l'ingénierie et à l'innovation pédagogique dans le
domaine de la formation et assister les établissements de formation dans l'implantation
des nouveaux modes d’organisation pédagogique.
4
II. Etude de marché
Une étude de marché est un travail de collecte et d’analyse d’informations ayant pour but
d’identifier les caractéristiques d’un marché. Le terme d’étude de marché recouvre dans la
pratique de nombreux types d’études de nature différentes. L’étude de marché peut se situer
sur un plan général et aborder les grandes composantes d’un marché existant (demande,
concurrence, produits, environnement, distribution, taille du marché, etc.).Elle peut également
se situer dans une logique de projet commercial et viser à mesurer les chances de réussite du
lancement d’un nouveau produit et les potentialités de ce futur marché.
II.1 Le marché visé

Ces dernières années nous assistons à une explosion de l’outillage en matière de gestion de
projet de développement. C’est difficile d’établir un comparatif exhaustif étant donné la
quantité d’outils sur le marché, on a choisi donc seulement cinq outils populaires à comparer.
II.1.1 Rally
Figure 1 Interface grafique de Rally
Rally est une offre assez séduisante sur le papier (à vérifier à l’usage. Il s’engage bien sûr à
garantir performance et confidentialité. Si nécessaire, il peut cependant être vendu dans sa
version d’installation sur site, les tarifs diffèrent sans doute dans ce cas de figure La
couverture en terme de fonctionnalités est très large et les possibilités d’intégration avec
d’autres outils sont relativement nombreuses (Gestionnaires de version, de plan de test, outils
d’intégration continue,…). Une version Community gratuite mais limitée permet de se faire
une bonne idée de l’outil. Un autre avantage avec Rally est l’accompagnement
5
méthodologique Agile. Rally est particulièrement actif dans la communautés Agile : livres
blancs, séminaires, articles, etc.[2]
II.1.2 VersionOne
Figure 2 Interface grafique VersionOne
VersionOne, créé en 2002, connue pour son sondage State of Agile Survey, est également une
application web de product management agile, pour les équipes de développement de toutes
tailles.Version one est surtout utilisé dans les grand groupe et les PME. Il est assez peu utilisé
en France (d’après mes informations) .VersionOne est très orienté Scrum dans sa gestion de
projet/produit. [2]
II.1.3 ScrumDesk
6
Figure 3 Interface grafique ScrumDesk
Les développeurs de Mountain Goat offre logicielle ScrumDesk , un outil de gestion de projet
scrum utilisé pour des projets d'équipe, scénarisation , la planification , le suivi des progrès ,
l'intégration et rétrospection . Dans une interface storyboard de style , ScrumDesk propose des
cartes d'histoire , la visualisation du carnet de commandes et les différentes méthodes
d'affichage de données visuelles , y compris vue de bureau , vue grille , le conseil de la tâche
et styles de carte d'arbres. ScrumDesk suivi de l'avancement du projet via des feuilles de
temps , des carnets , des camemberts d'état. et des rapports de comparaison . Disponible en
ligne , ScrumDesk vient dans des versions gratuites et d'abonnement , et fonctionne sur les
plates-formes Windows XP et Vista ..[1]
II.1.4 ScrumWorks
Figure 4 Interface grafique ScrumWorks
Danube propose deux versions de ScrumWorks, une version limitée appelée Basic et une
version complète payante appelée Pro. Pour la version payante pour une équipe de 10
personnes sur un an, il faut compter 2 050 €. A ce prix là, j’ai presque envie de dire :
« pourquoi s’en priver ? » mais tout dépend du coût du projet bien évidemment. ScrumWorks
ne couvre cependant pas les besoins suivants : organisation et déroulement des plans de test,
suivi des anomalies, wiki (centralisation des informations du projet).[2]
7
II.1.5 Agilo
Figure 5 Interface grafique Agilo
Cet outil dispose de plusieurs fonctionnalités intéressantes comme la chronologie, le

graphique et le tableau de bord, wiki intégré, le concept derrière Agilo présente plusieurs
défauts. Il n'y a pas de projets dans le système, cela signifie que si vous avez plusieurs projets,
vous devrez mettre en œuvre une solution de contournement. Les versions d'itération et
d'ordonnancement sont lourdes, il n'est pas facile de trouver comment créer un plan itératif.
Agilo est un bon outil gratuit pour le développement agile. [2]
II.2 Etudier la concurrence
Outil Méthode Licence Plateforme

VersionOne Scrum, XP commerciale Windows,Linux,Mac OS X
Scrumworks Scrum Commerciale, gratuit Windows,Linux,Mac OS X
Rally Scrum Commerciale, gratuit Windows,Linux,Mac OS X
Scrumdesk Scrum, XP, FDD, Commerciale, gratuit Windows

Kanban
Agileo Scrum gratuit Windows,Linux,Mac OS X
Figure 6 sommaire des outils évalués
On va évaluer nos outils à partir de vingt et un critères :
8
• L'extensibilité se référant à savoir si l'outil peut être modifié ou étendu. Ici, nous avons
évalué si un outil fourni un accès au code source, et s'il était offert sur une licence
commerciale ou open source.
• L'utilisabilité concernant l'utilité générale de l'outil. Ici, nous avons évalué les outils
uniquement pour leur facilité d'utilisation, aussi en tenant compte du fait qu'il fallait étudier
l’outil (Documentation et tutoriels).
•La connectivité décrivant les connecteurs, ou les plug-ins, fournis par les fournisseurs
d'outils tels que les environnements de développement (IDE), systèmes de suivi des bugs.Ici,
nous avons évalué la disponibilité de ces connecteurs; Nous avons également pris en compte à
la fois leur nombre et leur variété.
• La recherche faisant référence aux capacités de recherche de l’outil. Ici, nous avons évalué
la disponibilité de la recherche, en tenant compte des facteurs de recherche.
• Le Groupement debout pour pouvoir regrouper les éléments dans un carnet de produits.
Nous avons évalué si l'outil était activé le regroupement d'articles de carnet de produits.
• L'édition simultanée implique si plusieurs utilisateurs pourraient éditer simultanément le
même artefact dans l'outil. Bien que cela puisse sembler une exigence fondamentale pour les
outils.
• La Suivi de l'état de l'histoire en se référant à l'opportunité de suivre l'état d'une histoire.
Ici, nous avons évalué si l'outil permet d'enregistrer la progression de l'histoire. Le statut
Pourrait simplement être représenté comme une chaîne,
• La suivi général de l'état Avoir une vue globale sur l’avancement d’un projet, nombre
d’itérations, nombres des stories achevés.
• Backlog du sprint traitant de la capacité de créer et Gérer les stories d’une itération. Ici,
nous avons évalué si la possibilité de classer par ordre de priorité ces éléments.
• Estimation concernant la capacité d'estimation des stories et tâches. Pour ce critère, nous
avons évalué si il’était possible de saisir des estimations d'histoires et de tâches.
• Stories. Ici, nous avons évalué les options proposées pour créer et décrire des stories.
• Tâches faisant référence aux tâches requises pour la mise en œuvre d'un storie. Nous avons
évalué s'il était possible d’abaisser les histoires d'utilisateurs dans des tâches plus petites dans
un d’itération.
• Les équipes se réfèrent à la gestion de l'équipe. Pour ce critère, nous avons évalué s'il était
possible de créer des équipes au sein de l'outil, assigner les membres de l'équipe et apporter
des modifications à la capacité de l'équipe au fil du temps.
9
• Planification couvrant la capacité à supporter la planification de l’itération, c'est-à-dire
sélectionner les éléments du backlog et en les entrant dans une nouvelle itération. Nous avons
évalué si l’était possible, et si la capacité de l’itération créée était automatiquement assortie à
l'équipe affectée à cette itération.
• Progrès relatifs à l'état du storie ou de la tâche à un plus grand détail. Ici, nous avons évalué
si l'outil a permis d'entrer la quantité de travail effectuée sur une histoire ou une tâche, et s'il
était également possible de voir la quantité de travail restante.
• Tableau de bord couvrant la fourniture d'un tableau de tâches virtuel pour Stockant les
stories et les tâches des utilisateurs. Ici, nous avons évalué La disponibilité d'un tableau de
bord, et, dans l'affirmative, qu'il s'agisse Interactif et s'il était possible de faire glisser et
déposer Les tâches et les stories sur ce tableau.
• Burndown décrivant si l'outil fait des mis a jours et les enregistre sur un graphique
d’avancement en agissant avec toutes la modification possible.
• Lieu de travail à distance relatif à la possibilité d'accéder à l’outil À distance. Le plus
souvent, cela implique qu'un outil doit Être déployé en tant qu'application Web afin que
l'utilisateur puisse accéder même en dehors du réseau de bureau. Ici, nous avons évalué si une
telle opportunité était disponible. [3]
Les critères Version One ScrumWorks Rally ScrumDesk Agilo
L'extensibilité 0,0 0,0 0,0 0,0 10,0

L'utilisabilité 5,0 10,0 3,0 5,0 4,0
La connectivité 10,0 7,0 5,0 6,0 5,0
La recherche 8,0 6,0 10,0 6,0 4,0
Le Groupement 10,0 9,0 7,0 0,0 4,0
L'édition simultanée 9,0 10,0 10,0 10,0 9,0
La Suivi de l'état de l'histoire 9,0 10,0 9,0 9,0 4,0
Le suivi général de l'état 8,0 5,0 9,0 9,0 0,0
Backlog du sprint 6,0 7,0 5,0 7,0 3,0
Stories 9,0 10,0 7,0 7,0 3,0
Estimation 6,0 5,0 8,0 9,0 6,0
Tâches 9,0 10,0 8,0 10,0 8,0
Les équipes 5,0 7,0 7,0 8,0 10,0
10
Planification 6,0 4,0 7,0 7,0 4,0
Progrès 10,0 6,0 8,0 6,0 5,0
Tableau de bord 8,0 10,0 0,0 9,0 6,0
Burndown 10,0 8,0 10,0 9,0 9,0
Lieu de travail à distance 10,0 10,0 10,0 10,0 10,0
Notation totale 163,0 151,0 145,0 145,0 111,0
Cote totale normalisée 7,8 7,2 6,9 6,9 5,3

Figure 7 critères d'evaluation
Cote totale normalisée pour chaque outil

9
0
Version One ScrumWorks Rally Scrum Desk Agilo
Figure 8 diagramme de cote totale pour chaque outil
L'évaluation nous a conduits à deux conclusions importantes. Tout d'abord, nous avons
remarqué que les outils étaient ciblés vers les maitres de mêlée et l’équipes de développement
plutôt que les propriétaires du produit. La deuxième conclusion, concernant L'utilisabilité des
outils étudiés, on a remarqué que la richesse au niveau de fonctionnalités affecte négativement
la facilité de l’utilisation. Pour cela on va réfléchir a une solution qui comble ce vide.
11
II.3 Solution proposée
Notre solution va être de développeur un outil de gestion de projet agile selon le modèle
Scrum(la méthode agile de développement logiciel) qui va être facile à utiliser et nécessitant
le moins de travail possible,
 Interface agronomique, interactifs et captivants
 Contrôle d’accès selon les rôles, oblige une équipe Scrum à respecter les limites de chaque
rôle afin de les impliquer tous dans le déroulement d’un projet.
 Répond aux demandes de changement et évalue leurs impacts.
 Capable de dessiner des graphiques d’avancement claire et compréhensible [Fig9]

 Capable de dessiner des graphiques de vélocité claire et compréhensible [Fig15]
 Capable de calculer automatiquement la capacité de l’équipe dans une itération à partir du
travail demandé, On a choisi le calcule automatique afin de facilité le travail pour nos
utilisateurs.
 Capable de calculer automatiquement la vélocité d’équipe dans une itération celons cette
formule {Somme des points livrables des itérations terminée}/Nombre des itérations [Ref
velocité] terminée. On a trouvé que cette formule est tout d’abord simple et elle va
garantir le bon suivi de la progression d’un projet Scrum.
 Capable de dessiner les graphiques d’effort individuel qui présentent le taux de travails
réalisé pour chaque membre d’équipe. Ce diagramme n’est pas d’origine Scrum, Nous
avons choisi d’inventer car il va jouer un rôle important à détecter les problèmes de mal
collaboration entre l’équipe de développement Scrum.[fig. 10]
12
Graphique d'effort individuel
Utilisateur 4
10%
Utilisateur 3 Utilisateur 1
20% 40%
Utilisateur 2
30%
Utilisateur 1 Utilisateur 2 Utilisateur 3 Utilisateur 4
Figure 10 Graphique d’effort individuel
III. Méthodologie adoptée

Une méthode d'analyse et de conception est un procédé qui a pour objectif de permettre de
formaliser les étapes préliminaires du développement d'un système afin de rendre ce
développement plus fidèle aux besoins du client. Ces méthodes peuvent reposer sur des
modèles de développement. Un modèle est une suite d’étapes que le développeur doit suivre
pour garantir la réussite de son projet.
III.1 Tableau comparatif

Il existe un grand nombre de modèles de développement dont nous citons le modèle de la
cascade et le modèle en V. Le choix d’un modèle se fait selon les besoins du projet en cours
de développement et son habilité à garantir la bonne conception et le bon déroulement du
projet.
Voici dessus un tableau comparatif de quelques modèles les plus utilisés[4] :
Méthode Description Points forts Points faibles
Le modèle de la Ce modèle a été mis sur  La documentation est produite  On ne peut pas revenir
à chaque étape de l'élaboration en arrière, si la phase de
pied et formalisé dans les
du modèle cascade ; conception a mal tourné ;
Cascade
années 1970. Dans ce  Le montant des ressources  De petits
modèle, nécessaires pour mettre en changements ou des
œuvre ce modèle est minime. erreurs qui surviennent
chaque phase se termine dans le logiciel rempli
après un délai fixé. À la peut causer beaucoup de
problème.
13
fin de chaque étape, des
documents ou alors des
logiciels sont produits.
Le cycle en V est une  C’est simple à contractualiser ;  C’est une délégation totale
amélioration du modèle  On met l’équipe en face de ses du projet ;
responsabilités ;  Mauvaise gestion des
en cascade.  Il se découpe en plusieurs risques.
Le Modèle en V Il permet, en cas phases identifiées dès le
démarrage du projet ;
d'anomalie, de limiter un  Il permet de limiter les retours
retour aux étapes aux étapes précédentes.
précédentes
Figure 11 Tableau comparatif
III.2 Notre choix

Le choix du cycle de vie en Cascade pour la conception et le développement s’est fait vu que
on a une expérience avec ce modèle ce qui va garantir le bon déroulement de notre projet, on
veut produire la documentation dans chaque étape de l’élaboration, on n’a pas besoins de
revenir en arrière, on ne va pas avoir des changements qui affecte l’avancement du projet et
vue qu’il est facile à comprendre et a l’appliquer.
Figure 12 Cycle en cascade
III.3 Le langage de modélisation UML

UML, Unified Modeling Language, langage de modélisation objet unifié est une
démarche orientée objet. La modélisation et la formalisation à l'aide d'un vocabulaire
standardisé et de surcroît orienté objet confèrent à la méthode tout son intérêt. La
14
formalisation et la modélisation facilitent en effet la définition du problème à traiter et la
compréhension par l'ensemble des principales parties prenantes, sous réserve que chaque
partie maitrise son formalisme.Une fois, le modèle est bien défini, il est plus aisé de s'y référer
lors du développement afin de s'assurer de la conformité de ce dernier. Un outil précieux qui
explique à lui seul l'essor de la démarche UML.
UML couvre les trois axes qui représentent les points de vue du développeur, à
savoir [Figure8]:
o L’axe statique : qui décrit le système dans son état statique
o L’axe dynamique : qui décrit le comportement du système
o L’axe fonctionnel : qui représente les fonctions fournies par le système
Chacun de ces axes est décrit par un ensemble de diagrammes UML. Dans le cas de notre
projet, les diagrammes UML utilisés sont définis dans la figure suivante[5] :
Figure 13 : Diagramme UML utilisé
Conclusion
Dans ce chapitre, on a présenté le cadre général de notre projet en déterminant la
problématique et en proposant une solution envisagée pour faire face à la situation courante.
Ensuite, on a dévoilé la méthodologie de conception et le langage de modélisation.
15
16
Chapitre 2
Introduction aux méthodes agiles
et Scrum
Introduction
Les méthodes agiles sont un ensemble de pratiques qui permettent d’impliquer le client
tout au long du projet et permettent de fournir à chaque itération un rendu de projet
opérationnel à ce client. Elles sont itératives, c’est-à-dire qu’à chaque itération un livrable
applicatif permet de valider le résultat. Elles sont incrémentales, c’est-à-dire qu’à chaque
itération de nouvelles fonctionnalités sont ajoutées au livrable. Elles sont collaboratives, c’est-
à-dire que le client, l’équipe de production et le chef de projet travaillent en toute confiance
pour mener à bien le projet.
17
I. Que sont les méthodes agiles ?
Les méthodes agiles sont un ensemble de pratiques qui permettent d’impliquer le client tout
au long du projet et permettent de fournir à chaque itération un rendu de projet opérationnel à
ce client. Elles sont itératives, c’est-à-dire qu’à chaque itération un livrable applicatif permet
de valider le résultat. Elles sont incrémentales, c’est-à-dire qu’à chaque itération de nouvelles
fonctionnalités sont ajoutées au livrable. Elles sont collaboratives, c’est-à-dire que le client,
l’équipe de production et le chef de projet travaillent en toute confiance pour mener à bien le
projet [6].
IV. Pourquoi utiliser les méthodes agiles ?

Ces méthodes permettent de pallier aux anomalies que créent les méthodes traditionnelles
(cycles en V, modèle en cascade).
Les méthodes traditionnelles : Le client intervient au début du projet, pour le définir puis à
la fin du projet pour le recevoir.
Les méthodes agiles : Le client intervient après chaque itération pour voir si l’objectif est
accompli et si le projet peut continuer [6].
IV.1 Les différentes méthodes agiles

Il y a différentes méthodes agiles qui correspondent à différentes façons de travailler.
 La méthode Scrum que nous allons voir.
 La méthode EXtreme Programming (appelé XP) permet de réduire les coûts liés au
changement. Elle complète très souvent la méthode SCRUM.
 Rapid Application Development (RAD) est la méthode la plus ancienne. Elle permet
de choisir la solution la moins risquée, la plus fiable, la moins couteuse et avec un
délai moindre. Et bien d'autres encore à découvrir.[6]
IV.2 La méthode SCRUM

Elle tient son nom du Rugby qui signifie « mélée ». Les grands principes de la méthode
SCRUM ont été définis dans les années 90 par Jeff Sutherland et Ken Schwaber. En 2001, la
méthode SCRUM fut publiée dans le livre Agile Software Developpent qui regroupe un
ensemble de méthodes agiles [6].
IV.2.1 Les valeurs de la méthode SCRUM

 L’équipe : Cette méthode demande une grande cohésion et un esprit d’équipe entre les
membres d’un même projet.
18
 Le cahier des charges : Le cahier des charges n’est qu’un support pour aider à la
réalisation cependant il ne doit pas être négligé et doit subir de constantes mises à jour
à chaque itération. Le plus important est que l’application soit fonctionnelle.
 La collaboration : Le client est au cœur du projet pour aider à prendre les décisions
tout au long du projet. Il travaille avec l’équipe et fournit un compte-rendu en continu
sur ses attentes par rapport au livrable.
 Le changement : Le livrable doit resté flexible pour permettre l’évolution de la
demande du client.
IV.2.2 Qu'est-ce que la méthode SCRUM

La méthode SCRUM fait partie des méthodes agiles. Comme toutes les méthodes agiles, elle
implique le client dans toutes les décisions pour mener à bien le projet.
La méthode SCRUM va s’organiser de la manière suivante (schéma ci-dessous). Durant le
Backlog du produit, on définit avec le client le projet, il cherche à donner une plus-value à son
produit (ébauche du cahier des charges). Lors du Backlog d’une itération, l’équipe se charge
de transformer ces besoins en plusieurs tâches incluses dans différents itérations. Chaque
itération possède une durée de quelques semaines où sera réalisé une partie du projet. Durant
ces itérations, il y a quotidiennement des Mêlées qui permettent de faire le point sur le
déroulement de l’itération. À la fin d’une itération nous obtenons un livrable fonctionnel pour
le client [6].
Figure 14 Processus de développement « scrum »
IV.2.3 Les rôles

Scrum définit trois rôles : le propriétaire du produit le maitre de mélée et le développeur. Il est
à noter que le rôle de développeur couvre plusieurs métiers d'une organisation traditionnelle
 Propriétaire du produit
19
Le propriétaire du produit est le représentant des clients et des utilisateurs. Il est « responsable
de maximiser la valeur du produit et du travail de l'équipe de développement »7. Il s'agit
d'« une personne et non d'un comité ». Il est seul à diriger l'activité de l'équipe de
développement à qui il n'est « pas permis de suivre les instructions d'une autre personne. »
De ce fait, cet acteur se charge de différents rôles et responsabilités.
o Il explicite les éléments (items) du carnet du produit.
o C'est lui qui définit l'ordre dans lequel les fonctionnalités seront développées.
Il prend les décisions importantes concernant l'orientation du projet.
o Il s'assure que le carnet du produit est visible et compris de l'équipe de
développement.
C'est également lui qui, en accord avec l'équipe, fixe les objectifs d'un incrément (itération) au
début de celui-ci. Si ces objectifs deviennent obsolètes pendant l’itération, il a alors la
possibilité d'interrompre l’itération en cours.Dans l'idéal, le propriétaire du produit travaille
dans la même pièce que l'équipe. Il est important qu'il reste très disponible pour répondre aux
questions de l'équipe et pour lui donner son avis sur divers aspects du logiciel [7].
 Maître de mêlée
Le maître de mêlée est responsable de la compréhension, de l'adhésion et de la mise en œuvre
de la méthode. C'est un « leader au service de l'équipe », il assiste chaque rôle de l'équipe
SCRUM dans son activité Son autorité s'exerce sur le processus de développement (définition
de la durée des iterations, des modalités de tenues et de l'ordre du jour des réunions
SCRUM…), mais il ne dispose d'aucune autorité sur les autres membres de l'équipe SCRUM.
Ce n'est pas un chef de projet, ni un développeur, ni un intermédiaire de communication avec
les clients. Le rôle de SCRUM master ne peut pas être cumulé avec celui de propriétaire du
produit. Les attributions du « chef de projet » présent dans d'autres approches sont distribuées
dans les différents rôles de l'équipe SCRUM. L'existence du rôle de chef de projet dans un
contexte SCRUM est le signe d'une « méconnaissance fondamentale de SCRUM » et est
perçue comme contre-productive et menant à de « piètres résultats ».En tant que facilitateur, il
aide l'équipe à déterminer quelles interactions avec l’extérieur lui sont utiles, et lesquelles sont
freinantes. Il aide alors à maximiser la valeur produite par l'équipe.
Parmi ses attributions :
o communiquer la vision et les objectifs à l'équipe ;
o apprendre au propriétaire du produit à rédiger les composantes du carnet du
produit ;
20
o faciliter les rituels de SCRUM ;
o coacher l'équipe de développement ;
o faciliter son intégration à l'entreprise, surtout si celle-ci n'est pas pleinement
agile ;
o écarter les éléments pouvant perturber l'équipe ;
o aider l'adoption des méthodes agiles au niveau de l'entreprise ;
o travailler avec les autres Facilitateurs/animateurs pour coordonner plusieurs
équipes, s'il y a lieu [7].
 Équipe de développement
L'équipe de développement est constituée de 3 à 9 personnes et a pour responsabilité de livrer
à chaque fin d'itération une nouvelle version de l'application enrichie de nouvelles
fonctionnalités et respectant le niveau de qualité nécessaire pour être livré. L’équipe ne
comporte pas de rôles prédéfinis ; elle est « structurée et habilitée par l'entreprise à organiser
et gérer son propre travail ».Elle est auto-organisée et choisit la façon d'accomplir son travail,
sans que ce soit imposé par une personne externe. Il n'y a pas non plus de notion de hiérarchie
interne : toutes les décisions sont prises ensemble. Ce mode d'organisation a pour objectif
d'augmenter l'efficacité de travail de l'équipe. Elle est pluridisciplinaire et comporte toutes les
compétences pour réaliser son projet, sans faire appel à des personnes externes à celle-ci.
L’objectif de l'équipe est de livrer le produit par petits incréments. Ainsi, à tout instant, il
existe une version du produit « potentiellement utilisable » disponible. L’équipe s'adresse
directement au propriétaire du produit, et ne prend ses instructions que de lui. Son activité est
issue du carnet de produit uniquement. Elle ne peut pas être multi-produite[7].
IV.2.4 Les artéfacts
IV.2.4.1 Storie « user story »
Est un fragment livrable du produit elle se présente par une phrase simple dans le langage de
tous les jours permettant de décrire avec suffisamment de précision le contenu d'une
fonctionnalité à développer. La phrase contient généralement trois éléments descriptifs de la
fonctionnalité : Qui ? Quoi ? Pourquoi ?
Exemple : « En tant qu'utilisateur, Je veux pouvoir rechercher mes clients par leur prénom et
leur nom de famille afin de les retrouver rapidement lorsque je reçois un appel de leur part. »
Elle contient généralement les informations suivantes :
 ID un identifiant unique
21
 Titre un nom court (entre 2 et 10 mots), descriptif de la fonctionnalité attendue par le
client, Le nom doit être suffisamment clair pour que les membres de l’équipe
comprennent de quelle fonction il s’agit. Le nom ne doit pas introduire d’ambigüités.
 Priorité un entier qui fixe la priorité des Stories. La priorité d’une storie peut être
changée en cours de réalisation du projet.
 Storie point « Story point » Un storie point sert à estimer l’effort nécessaire à une
équipe pour implémenter une fonctionnalité Cette estimation prend en compte :
l’effort pour le développement, la complexité du développement, Le risque / l’inconnu
Par abus de langage, on dit que le storie point sert à estimer la “taille” d’une
fonctionnalité [8].
IV.2.4.2 Les tâches
Sont des choses non livrables, ou des choses auxquelles le maitre de mêlée ne s'intéresse pas.
Elles sont créées par les développeurs suite à la décomposition d'une storie afin de mieux
attaquer la dernière. Elle contient généralement les informations suivantes
 Libellé un nom court (entre 2 et 10 mots) et compréhensible
 Estimation qui sert à mesurer la tâche en temps(heurs/jours).
Figure 15 Exemple de décomposition d'une storie en tâches
22
IV.2.4.3 Backlog
En quelques mots voici ce que constitue un Backlog de Produit [9] :

1. Une liste de tout ce qui va entraîner du travail au projet
2. Chaque élément doit apporter de la valeur aux utilisateurs ou clients du produit
3. Les priorités sont définies par le directeur produit
4. Les priorités sont revues à chaque itération
Exemple de Backlog Produit :
Elément de Backlog Estimation
Un invité peut faire une réservation 3
En tant qu'invité, j'annule une réservation 5
En tant qu'invité, je change les dates d'une réservation. 3
En tant qu'employé de l'hôtel, je produis les rapports de revenu par

8
chambre
Améliorer la gestion des exceptions 8
Figure 16 Exemple de Backlog Produit
IV.2.4.4 Graphique d'avancement
Le graphique d'avancement est une représentation graphique de l'évolution de quantité de

travail restante par rapport au temps sur une période de temps donnée. Le travail restant se
situe en général sur l'axe vertical, alors que le temps est sur l'axe horizontal. Une
interprétation simple (régression linéaire) permet d'avoir une prévision de l'état d'avancement
à la fin de la période d'activité. Ce type de représentation est souvent utilisé pour suivre une
activité gérée en boite de temps, puisque la quantité de travail à réaliser ainsi que la date de
fin sont connues dès le début de la période couverte par le graphique.
 Les axes
L'axe X représente la ligne du temps du projet. L'unité dépend de la fréquence de ré-
estimation du reste à faire. Pour un burndown d'itération, l'unité est souvent le jour, pour un
burndown de release, l'unité est l’itération (le reste à faire pour compléter la release est
recalculé à chaque début d'itération).
23
Le travail qui doit être complété pour terminer le projet, représenté en temps ou en points2,
est introduit à travers l'axe Y.
 Points de départ et final
Le point de départ est le tout premier point à gauche indiqué sur le jour 0 du graphique, alors
que le point final est le plus à droite et représente une prédiction du dernier jour du projet.
 Lignes du travail restant
Il existe deux types de ligne :
 Ligne du travail restant idéal : C'est une droite qui passe par le point de départ et le
point final. Au point de départ, elle montre la somme de toutes les tâches qui doivent
être complétées, alors qu'au point final il n'y a plus de travail restant. La pente de la
droite est proportionnelle à la productivité estimée de l'équipe sur la période.
 Ligne du travail restant effectif : Cette ligne montre le travail restant effectif. Le
point de départ est le même que pour la ligne idéale, cependant, quand le temps
avance, cette ligne à tendance à être au-dessus ou au-dessous de la ligne idéale. En
général, un nouveau point est ajouté à la suite de cette ligne chaque jour. Ce point peut
être calculé soit par la ré-estimation du reste à faire total, soit par la soustraction de ce
qui a été produit du reste à faire initial [10].
24
Graphique d'avancement
Idéale Courant
90
80
70
60
Heurs de travail total
50
40
30
20
10
0
Jour 0 Jour 1 Jour 2 Jour 3 Jour 4 Jour 4 Jour 5 Jour 6 Jour 7
Axis Title
Figure 17 Burndown Chart
 Graphique de vélocité
La vélocité est la mesure de la capacité de l'équipe pendant une itération. Elle se calcule juste
après la démonstration lors de la revue d’une itération. La démonstration permet de décider si
une fonctionnalité montrée est finie ou pas. Si elle est finie, on prend en compte l'estimation
en points de cette fonctionnalité. La vélocité s'obtient simplement en faisant la somme des
points de chaque fonctionnalité présentée avec succès. Le diagramme de la vélocité est un
autre moyen de visualiser et de suivre la vitesse de progression du
projet. (Mathématiquement, cela revient à visualiser la dérivée de la courbe d’avancement.)Ce
diagramme a pour origine SCRUM, la méthode agile de développement logiciel. Dans cette
méthode, il est utilisé le plus souvent pour détecter un problème de qualité. En effet, une
baisse de la vélocité traduirait un manque d’évolutivité du logiciel ou l’apparition de
nombreux bugs [11].
25
Graphique de vélocité
Points prévus Points livrés
45
40 40
40
35
30
30
25
Storie points
25 23
20 20
20
15
15
10
0
Iteration #1 (velocite) Iteration #2 (velocite) Iteration #3 (velocite) Iteration #4 (velocite)
Axis Title
Figure 18 Graphique de vélocité
Conclusion
La méthode SCRUM permet donc de réaliser un projet en très peu de temps et avec peu de
ressources humaines. Elle s’adresse à de petites équipes d’une dizaine de personnes environ.
Cependant, du fait qu’elle n’est applicable que sur des petites équipes, elle n’est pas
applicable pour des projets de grande envergure. La force de la méthode SCRUM est qu'à
chaque fin d’une itération, une partie du projet est disponible pour le client ce qui lui permet
de décider de continuer à développer le projet ou de s'arrêter pour diverses raisons. La
méthode SCRUM permet de canaliser l'équipe et de la garder concentrée sur ce qu'elle a à
faire grâce aux itérations. Après avoir présenté les méthodes agiles et la méthode SCRUM
maintenant on va passer à la spécification des besoins.
26
Chapitre 3
Spécification des besoins
27
Introduction
Après avoir présenté présenter brièvement les méthodes agiles et la méthode SCRUM, on va
entamer la phase de spécification et d’analyse des besoins.
La spécification et l’analyse des besoins est la première phase dans le cycle de développement
du projet, au cours de laquelle les besoins de l’utilisateur sont identifiés et bien précisés.
I. Etude des besoins
IV.3 Besoins fonctionnels

Il s'agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement
d'entrée / sortie du Système.
On a trois acteurs (Internaute, Utilisateur, Membre d’équipe)[ fig. 18]
Figure 19 Les acteurs
Les besoins fonctionnelles de notre application sont
 S’inscrire : Notre système offre pour chaque internaute la possibilité de s’enregistrer

dans notre système en saisissant quelques informations telles que le nom et le prénom,
l’email, un pseudo unique et mot de passe.
28
 Gérer son profile : Notre système offre à ses utilisateurs les possibilités de modifier
ses information et même de télécharger et changer la photo du profil.
 Créer un projet : Notre système offre à ses utilisateurs la possibilité de créer un

espace de travail SCRUM qui va contenir les différents éléments agile.
 Avoir un rôle SCRUM dans un projet : Notre système offre à ses utilisateurs un
espace de gestion des différents éléments SCRUM dans un projet qui se diffère d’un
rôle à un autre, tout court on va présenter les espaces de gestion pour chaque rôle
o Maitre de mêlée : Gestion équipe, Gestion itérations,
o Propriétaire du produit : Gestion stories,
o Développeur : Gestion taches.
 Gérer son équipe: Notre système offre à au maitres de mêlée dans leur projets les
privilèges d’ajouter des membres d’équipes, définir leur rôles et même les supprimer
afin d’avoir un contrôle complet sur son équipe.
 gérer les stories : Notre système offre aux propriétaires du produit les privilèges de
gérer les stories en ajoutant, supprimant, modifiant et restaurant les stories afin d’voir
un contrôle complet sur les stories du projet.
 Gérer les itérations : Notre système offre aux maitres de mêlée le privilège de créer
des itérations, les démarrer, associer des stories à des itérations et même les supprimer
pour avoir le contrôle complet sur les déroulements d’un projet.
 Gérer les tâches d’une sortie : Notre système offre aux développeurs dans un projet
le privilège de créer des taches, les modifier, les supprimer, s’engager à des taches et
les terminer.
 Commenter les stories Notre système offre aux utilisateurs la possibilité de publier
des commentaires dans chaque stories afin d’avoir un moyen de communication
interne entre le membre d’équipe dans un projet, ce besoins va être important pour
minimiser les risques de la mal compréhension des stories, enregistrer les différents
remarques, et d’établir une bonne relation entre les stories et ses taches.
29
 Visualiser les artefacts Notre système offre aux utilisateurs la possibilité de
consulter les statistique qui donne une idée sur l’avancement d’un projet,
spécifiquement le système va offrir des graphiques d’avancement simple qui trace de
la charge de travail restante heures en fonction du temps (en jours),des graphiques de
vélocité simple qui trace les points livrées et la vélocité de chaque itération terminée,
des graphiques d’effort individuel qui trace les nombre d’heures de travail réaliser
pour chaque développeur dans une itération.
 Imprimer les artefacts Notre système offre aux utilisateurs la possibilité d’imprimer
les artéfacts important tel que le backlog, le graphiques d’avancement, le graphiques
de vélocité, et le graphiques d’effort individuel
IV.4 Besoins non fonctionnels

Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les
contraintes d'implémentation (langage de programmation, type SGBD, de système
d'Exploitation...)
Notre application doit satisfaire plusieurs besoins non fonctionnels dont on cite :
o Besoin de performance : Un logiciel doit être avant tout performant c'est-à-
dire à travers ses fonctionnalités, répond à toutes les exigences des usagers
d'une manière optimale.
o Besoin de fiabilité : l’application doit fonctionner de façon cohérente sans
erreurs.
o Besoin d’utilisation : l’application doit offrir une interface conviviale,
ergonomique et facile à manipuler par les utilisateurs.
o Besoin d’évolutivité : le code doit être clair pour permettre de futures
évolutions ou améliorations.
o Besoin de fiabilité : l’application doit garantir l’intégrité et la cohérence des
données à chaque mise à jour et à chaque insertion.
o Besoin de sécurité : l’application doit garantir la sécurité des données des
utilisateurs.
30
V. Les diagrammes de cas d’utilisation
Le diagramme de cas d’utilisation(CU) est un modèle de communication. Il permet de
modéliser les besoins, les points de vue de l’utilisateur et de définir les limites précises du
système tout en utilisant Une notation simple et compréhensible par tous.
V.1 Présentation des acteurs

Les acteurs d’un système sont les entités externes à ce système qui interagissent avec lui par
l’envoi des événements et la récupération des informations de la part du système.
Dans ce projet on a quatre acteurs primaires Internaute, Utilisateur, Membre d’équipe et
le cadenceur.
1. Internaute est un utilisateur du réseau Internet qui navigue sur l’espace publique de
l’application.
2. Utilisateur est une personne identifié qui utilise l’application.
3. Membre d’équipe est un Utilisateur de l’application qui est en train d’interagir avec
un projet, suite â cette interaction il perd les privilèges d’Utilisateur et prend les
privilèges de Membre d’équipe.réélement le membre d’équipe n’existe que au-
dessus projet pour cela il ne partage pas des cas d’utilisation avec l’utilisateur.
Ce membre d’équipe peut porter dans un projet l’un de ces rôles qui définissent son
privilège.
o Propriétaire du produit: Personne ayant la responsabilité de produire et de
maintenir à jour le carnet de produit. C'est lui qui détermine les priorités et qui
prend les décisions d'orientation du projet.
o Maitre de mêlée: Membre de l'équipe dont l'objectif principal est de la protéger
des perturbations extérieures. Il est complètement transparent pour la
communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur
l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de
l'équipe.
o Développeur : Le développeur a pour responsabilité de livrer à chaque fin
d'itération une nouvelle version de l'application enrichie de nouvelles
fonctionnalités et respectant le niveau de qualité nécessaire pour être livré.
4. Le cadenceur est un acteur qui déclenche le cas d’utilisation de façon périodique,
dans notre outil cet acteur va jouer un rôle important en déclenchant quotidiennement
31
des mis a jours pour maintenir l’avancement des projets, c’est à lui d’avancer les
itérations, évaluer l'impact des changements et mettre à jours les différents graphiques.
V.2 Description des cas d’utilisation

Les cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont
donc une vision orientée utilisateur de ce besoin au contraire d'une vision informatique.
32
V.2.1 Diagramme de cas d’utilisation général
33
La figure suivante [Figure 12] représente l'ensemble des cas d'utilisation générale de la
plateforme résumant les fonctionnalités du système et les interactions avec les acteurs.
34
 Création d’un nouveau projet
Pré- conditions
 L’utilisateur est authentifié.
Enchaînement
Action acteur Action système

1. L’utilisateur s’identifie
2. Le système affiche la page de d’accueil
3. L’utilisateur demande la page

de gestion des projets
4. Le système affiche la page de gestion des
projets
5. L’utilisateur saisit le nom du

projet
6. L’utilisateur crée un projet
7. Le système ajoute le projet
8. Le système ajoute l’utilisateur au projet crée en

tant que maitre de mêlée.
Enchaînement d’exception
E1 : Si le nom du projet est vide
Par un message le système demande à l’utilisateur de saisir nom de projet valide.

L’enchaînement E1 démarre au point 5 du scénario nominal.
Post- conditions
Les projets relative à cet utilisateur sont mise a jours.
V.2.2.2 Cas d’utilisation "Supprimer un projet "
Acteurs
 Utilisateur
But
 Supprimer un projet avec tous ses composants.
35
Pré- conditions
 Le maître de mêlée est authentifié.
Enchaînement

1. Le maître de mêlée demande
la page de gestion des projets
projets
3. L’utilisateur confirme la
suppression d’un projet
4. Le système supprime le projet
Aucun Enchaînement.
Post- conditions
Les projets relative à cet utilisateur sont mise a jours.
V.2.2.3 Cas d’utilisation "quitter un projet "
Acteurs
 Développeur
But
 Quitter un projet
Pré- conditions
 Les acteurs sont authentifié.
Enchaînement

1. L’acteur demande la page de
gestion des projets
36
projets
3. L’acteur confirme de quitter un

projet
4. Le système supprime enlève l’acteur du projet.
Post- conditions
 Les projets relative à ce Développeur sont mise à jours.
V.2.2.4 Cas d’utilisation "Gérer équipe"
Gérer équipe
Accéder a un
projet
<Include>
Maître de mélée
Gérer equipe
<Extends> <Extends> <Extends>

Modifier le role d'un
membre
Ajouter un membre Retirer un membre
Figure 21 : Diagramme de cas d'utilisation " Gestion d’équipe "
 Ajouter un utilisateur
Acteurs
But
 Ajouter un membre dans un projet.
Pré- conditions
 Accéder à un projet.
 Nombre d’équipe égale à huit.
37
Enchaînement

1. Le maître de mêlée demande
page de gestion d’équipe
2. Le système affiche la page de gestion d’équipe
3. Le système affiche l’utilisateur recherché.
4. Le maître de mêlée confirme

l’ajout
5. Le système ajoute l’utilisateur recherché et il

devient un membre d’équipe dans le projet
courant en tant que développeur
Post- conditions
L’équipe est mise à jours.
 Modifier le rôle d’un membre
Acteurs
But
 Modifier le rôle d’un membre dans un projet.
Pré- conditions
 Accéder à un projet.
Enchaînement

1. Le Maitre de mêlée demande
page de gestion d’équipe
38
2. Le système affiche page de gestion d’équipe
3. Le système change le rôle d’un

membre
4. Le système vérifie la disponibité du rôle choisit
5. Le système modifie le rôle du membre

sélectionné.
E1 : Si le rôle n’est pas disponible
Post- conditions
L’équipe est mise à jours.
V.2.2.5 Cas d’utilisation "Gérer itération"
39
Gérer itération
Maitre de mélée <Extends>

Gérer Iteration Supprimer une iteration
<Extends>
<Extends>
Demarrer une iteration
Créer une iteration
Figure 22 Diagramme de cas d'utilisation " gérer itération"
V.2.2.6 Cas d’utilisation "Gérer stories "
Gérer storie
Créer storie Modifier storie
<Extends> Supprimer storie

<Extends> <Extends>
Gérer storie définir l'ordre dans lequel les

stories seront développées.
Propriétaire du produit <Extends>
<Extends>
Restaurer storie
Figure 23 Diagramme de cas d'utilisation " Gérer stories"
V.2.2.7 Cas d’utilisation "Gérer taches "
40
Outil de gestion de projet agile
Ajouter tache
<Extends>
Supprimer tache
<Extends>
Gérer taches
<Extends>
Développeur
Modifier les details d'une
tache
<Extends>
<Extends>
s'engager à une tâche
Terminer une
tache
Figure 24 Diagramme de cas d'utilisation " Gérer taches"
 Ajouter une tache
Acteurs
 Développeur
But
 Remplir une sortie par des taches.
Pré- conditions
 La tache appartient à une storie non terminée dans une itération non terminée
Enchaînement

1. Le développeur demander la
page Dashboard storie d'une
storie spécifique
41
2. Le système affiche la page Dashboard storie
3. Le développeur saisit label et

estimation et confirme l’ajout
4. Le système régénère les listes des taches.
E1 : Le développeur essayé d’ajouter avec tache sans estimation ou sans label
Post- conditions
List des taches est mise à jours.
 S’engager à une tache.
Acteurs
 Développeur
But
 S’engager d’une tache
Pré- conditions
 La tache appartient à une storie en cours dans une itération non terminée
Enchaînement

5. Le développeur demander la
storie spécifique
7. Le développeur s’engage à une

tache
8. Le système change l’etat du tache de « A
faire » vers « En cours »
42
Aucun enchaînement.
Post- conditions
 Terminer une tache
Acteurs
 Développeur
But
 Terminer une tache
Pré- conditions
La tache appartient à ce développeur et appartient à une storie non terminée dans
une itération non terminée
Enchaînement

1. Le dévéloppeur demande la
storie spécifique.
3. Le développeur termine une

tache
4. Le système change l’etat du tache de « En
cours » vers « Terminée »
5. Le système Enregistre les modifications.
Aucun enchaînement.
Post- conditions
V.2.2.8 Cas d’utilisation « Visualiser les graphiques »
43
Visualiser les graphiques
Visualiser le graphique d’effort

individuel
<Extends>
Imprimer le graphique d'effort

individuel
Visualiser les graphiques

Membre d'equipe
Visualiser le graphique d'avancement
<Extends>
Imprimer le graphique d'avancement

Visualiser le graphique
de vélocité
<Extends>
Imprimer le grafique de vélocité
Figure 25 diagramme de cas d’utilisation « visualiser artéfacts »
V.2.3 Diagrammes de séquences système

Les diagrammes de séquences système sont la représentation graphique des interactions entre
les acteurs et le système selon un ordre chronologique dans la formulation Unified Modeling
Language.
V.2.3.1 Diagramme de séquences système « S’authentifier »
44
S'authentifier
Systeme
Utilisateur
Demander page login(1)
Afficher page login(2)
S'authentifer(3)
alt Authentification echouée
Afficher message d'erreur(4)
Authentification réussite
Afficher page d'accueil(5)
Figure 26 Diagramme séquence système « S’authentifier»
1. L’utilisateur demande page login

2. Le système affiche la page login
3. L’utilisateur saisit son pseudo et son mot de passe et essaye de s’authentifier
Si l’authentification est échouée
4. le système affiche un message d’erreur.
Sinon
5. le système affiche la page d’accueil.
V.2.3.2 Diagramme de séquences système « Associer une storie a une itération »
45
Associer une storie a une iteration
Systeme
Maître de mélée
ref <<S'authentifier>>
Accéder a un projet(1)
Afficher tableau de bord du projet(2)
Accéder a une iteration non terminée(3)

Affiche le tableau de bord de cet
iteration(4)
Associer une storie a l'iteration(5)
Relier la storie avec l'iteration(6)
Changer l'etat du storie vers "A faire"

(7)
Mettre â jours l'iteration(8)
Rafrechir le tableau de bord(9)
opt [Si l'iteration est en cours]
Mettre â jours le graphique d'avancement

(10)
Figure 27 Diagramme séquence système « Associer une storie â une itération »
Après l’authentification
1. Le maitre de mêlée accède à un projet.

2. Le système affiche le tableau de bord du projet.
3. Le maitre de mêlée accède à une itération non commencée.
4. Le système affiche le tableau de bord de l’itération.
5. Le maitre de mêlée associe une storie à une itération.
6. Le système relie la storie avec l’itération.
7. Le système change l’état du storie vers « Â faire ».
8. Le système mise à jour l’itération.
9. Le système rafraichit le tableau de bord de l’itération.
Si l’itération est en cours
10. Le système mise à jour le graphique d’avancement.
46
V.2.3.3 Diagramme de séquences système « démarrer une itération »
Démarrer une iteration
Systeme
Maître de mélée
Démarrer une iteration()
Accéder a un projet
Afficher tableau de bord du projet
Accéder a une iteration non commencée

Affiche le tableau de bord de cet
iteration
ref <<Associer une storie a une iteration>>
Saisir date fin de l'iteration
Démarrer l'iteration
Calculer la durée de l'iteration
alt Si la durée entre un et trois semaines
Enregistrement
Rafrechir le tableau de bord
Sinon
afficher un Message d'erreur
Figure 28 Diagramme séquence système « démarré une itération »
11. Le maitre de mêlée accède à un projet

12. Le système affiche le tableau de bord du projet
13. Le maitre de mêlée accède à une itération non commencée
14. Le système affiche le tableau de bord de l’itération
Pour que le système donne au maitre de mêlée la possibilité de démarrer l’itération il faut
qu’il associe au moins une storie à cette itération.
15. Le maitre de mêlée saisit date fin de l’itération

16. Le maitre de mêlée essaye de démarrer l’itération
47
17. Le système calcul la durée de l’itération à partir la date courant et le date fin saisit
Si la durée de l’itération entre sept et vingt et un jours
18. Le système accepte le démarrage, change l’état de l’itération de « non commencée »

vers « en cours »
19. Rafraîchit le tableau de bord.
Sinon
20. Le système informe le maitre de mêlée par un message que la date fin saisit est
invalide.
V.2.3.4 Diagramme de séquences système « restaurer storie »

Restaurer stori e
Systeme
Propri etai re du produi t
ref <<S'authenti fier>>

Restaurer stori e()
Afficher tableau de bord du proj et(2)
Accéder a une i terati on terminée(3)

Affi cher l e tabl eau de bord de l'
i teration(4)
Demander page de rétrospectives(5)
Affi che l a page de rétrospecti ves(6)
Restaurer stori e non termi née(7)
Changer l'etat du stori e vers "Non

assignée"(8)
Suppri mer l a rel ati on entre l a storie et l'

iterati on(9)
l oop [Pour chaque taches dans cette stori e avec l 'etat "En cours"]
Changer l 'etat du tache vers "À fai re"(9)
Suppri mer l a rel ation entre la tache et l e

dével oppeur qui l 'occupe(10)
Rafrechir l a page de rétrospecti ves(11)
Figure 29 Diagramme séquence système « Restaurer storie»
48
1. Le propriétaire du produit accède à un projet
2. Le système affiche le tableau de bord du projet
3. Le propriétaire du produit accède à une itération terminée
4. Le système affiche le tableau de bord de l’itération
5. Le propriétaire du produit demande page de rétrospectives
6. Le système affiche la page de rétrospectives
7. Le propriétaire du produit restaure une storie non terminée
8. Le système change l’état du storie vers « non commencée »
9. Le système supprime la relation entre la storie et l’itération
10. Le système initialise les taches avec l’état « en cours qui appartient à cette storie.
V.2.3.5 Diagramme de séquences système « Ajouter tache »

Aj outer une ta che
Systeme
Dével op peur
ref <<S'au thenti fi er>>
Accéde r a un proj e t (1)
Affi cher l e tab l eau de bord du proj et (2)
Accéd er a u ne stori e non term i née (3)
Affi cher l e tabl eau d e b ord du stori e(4)
a j outer une tach e(5)
Ve ri fi cati on(6)
al t Si l e l i bel l é ou l 'esti m ati on sont vi d es
Affi che r m essage d'erreur(7)
Si non
Enreg i strement(8)
Rafré chi r l i ste des taches(9)
o pt [Si l a stori e est assi gnée â un e i terati on non dém arrée]
mi se â j ours i terati on(10)
opt [Si l a stori e est associ é e a une i terati on en cours]

mi se â j ours i terati on(11)
m i se a j ours l e g rafi qu e d'avanceme nt(12)
Figure 30 Diagramme séquence système « Ajouter tache »
49
1. Le développeur accède à un projet.
2. Le système affiche le tableau de bord du projet.
3. Le développeur accède à une storie non terminée.
4. Le système affiche le tableau de bord du storie.
5. Le développeur saisit libellé et l’estimation en heurs et puis il valide l’ajout.
6. Le système vérifie les données saisit.
Si le libellé ou l’estimation sont vides
7. Le système affiche un message d’erreur.
Sinon
8. Le système enregistre l’ajout.
Si la storie est assignée â une iteration non démarrée
9. Le système mettre à jours l’itération.
Si la storie est assignée â une iteration en cours
10. Le système mettre à jours l’itération.

11. Le système mettre à jours le graphique d’avancement.
Conclusion
Dans ce chapitre, on a présenté les besoins offerts par le système. On a également fourni une
analyse plus détaillée des besoins non fonctionelles grâce aux diagrammes de cas d'utilisation
et diagrammes des séquences système.
Dans le chapitre suivant, on va aborder le chapitre relatif à la " Conception ".
50
Chapitre 4
Conception
51
Introduction
Après avoir identifié les besoins fonctionnels et non fonctionnels que notre système doit
satisfaire et établit les diagrammes de cas d’utilisations pour chaque acteur, il est temps de
passer à la conception de notre système.
Une bonne conception est la clé d’un développement de logiciel efficace donc un système
bien conçu est facile à maintenir, facile à comprendre et fiable. La phase de conception
représente alors la phase la plus cruciale du processus de développement d’un logiciel.
I. Architecture globale de la solution

Le rôle principal d’une architecture est d’entraîner une démarche de conception, à la fois
formelle et opérationnelle (lors de sa conception, de sa mise au point et de sa maintenance).
La définition d’une architecture logicielle passe donc par la réponse à la question suivante :
Quelles règles doit-on suivre pour réussir à développer des systèmes qui répondent à toutes
les exigences fonctionnelles (les services à rendre) et non fonctionnelles (performance et
extensibilité du système par exemple).
Notre application est constituée de trois couches. Ces trois couches se conforment à
l’architecture de couches fermées «Closed layer architecture» (une couche peut communiquer
seulement avec la couche qui lui est adjacente). La figure suivante présente l’architecture Java
EE d’une application web en trois couches :
52
Figure 31:architecture Java EE d’une application web en trois couches
Le concept de partitionner une application en couches et de garder toute la logique de

l’application dans ces couches distinctes et séparées, a été introduite bien avant l’approche
orientée objet.
Ainsi une application est divisée en trois couches logiques, chacune traitant des fonctions
spécifiques :
 Présentation : interface usager et présentation.
 Logique du logiciel à produire (besoins, services de l’entreprise) : les
règlements de l’entreprise et la logique de l’application.
 Logique des données : Base de données et intégration des services de
l’entreprise.
Ce concept nous permet de créer des composants indépendants et de les déployer sur des
plates-formes différentes. En fait, ce concept est très utilisé dans le développement des
applications multi-tiers. Plus tard, il fut adapté au modèle de conception Model-View-
Controller (MVC) qui est un modèle très commun pour développer des applications
distribuées et multi-tiers [12].
53
VI. Conception du niveau données
La conception du niveau donnée permet de mieux spécifier la structure du système en
décrivant son diagramme de classe.
VI.1 Description des classes

Un diagramme de classes est défini comme étant un schéma représentant toutes les classes
d’un programme, leurs attributs, leurs méthodes, ainsi que les relations qui les relies.
Classe Description Attributs Méthodes
Utilisateur Cette classe contient  Id_utlisateur Login()

les détails d’un  Pseudo Inscripriton()
utilisateur.  Motdepasse Modifier()
 Nom GetAllUsers()
 Prenom UsernameExist()
 Email GetUserByusername()
 Datelogin GetUserById()
DetDateLogin()
 dateinscri
GetusersByProject()
GetRole()
GetImageId()
HasImage()
Image_profile Cette classe contient  id_image_profile InsertImage()

les information du  image_name UpdateImage()
photo de profile d’un  image DispalyImage()
utilisateur.
Projet Cette classe contient  id_projet AddProject()
les détails d’un  nom DeleteProject()
projet.  datecreation RenameProject()
GetTeam()
GetNonTeam()
GetAllbyUserutilisateur()
GetProjetByname()
AddMember()
SetRoleMember()
DeleteMember()
GetProjetById()
UserProject C’est une classe  Date(Date d’inscription d’un

d’association entre utilisateur a un projet)
Projet et utilisateur
Permet d’enregistrer
l’inscription d’un
utilisateur dans un
projet avec son rôle.
ProjetStatus C’est une classe qui  Id_projet_status
contient les statuts  label
54
disponibles pour un
projet
Role Cette classe contient  Id_role GetALLWithString()
les rôles disponibles  Label GetRoleBylabel()
dans un projet
Iteration Cette classe contient  id_iteration AddIteration()
les informations  code DeleteIteration()
Nécessaires d’une  mission GetIterationsBy()
iteration.  debut GetFinishedIterations()
 fin GetiterationsVelocity()
 joursrestant GetallIteration()
 joursrestant GetIteration()
SetDebutFin()
 storiesterminer
SetMission()
 heurstravailtotale
SetIterationStatus()
 heurstravailrestant SetDurée()
 pointsprevus SetJoursRestant()
 pointterminer SetNbrStories()
 velocite SetNbrStoriesTerminer()
SetHTravailsTotale()
SetHTravailsRestant()
SetPointsPrevus()
SetPointsTerminer()
SetVelocity()
IterationStatus Classe qui presente  id_iteration_status
les status  label
d’une iteration
Avancement Classe qui presente  id_avancement AddAvancement()
les details des point  heursrestant UpdateAvancement()
de burndownchart  datejour GetAvByIteration()
 jouractuel LastOne()
Storie Cette classe contient  id_storie AddUserstory ()

les informations  titre UpdateUserstory ()
Nécessaires d’une  role AssosiateUserstoryToIteration()
sorie.  objectif SetPoint()
 benefices Setetat()
 Criteres_acceptation DeleteUserstory()
GetUserstorysBy()
GetUserstorysByIteration()
Setdefault()
GeUStIteration()
GetUserstorysByEtat()
GetUserstorysNonAssossier()
Storie_Etat Classe qui presente  id_storie_etat
l’etat d’une storie  type
points Classe qui présente  id_point GetALL()

Les storie Points  npoint
d’une storie.
Commentaire Cette classe contient  text AddCommentaire()
les commentaire  date DeleteCommentaire()
publier par les  ptime GetAllByStorie()
utilisateurs dans une
storie
Tache Classe qui présente  id tache Addtache()
Les détails d’une  label Setetat()
tache.  estimation Deletetache()
GettachesByus()
55
AssositeTouser()
GettacheEtat()
Storie_Etat Classe qui présente  id_storie_etat
l’état d’une tache  type
VI.2 Règle de gestion

1. Un utilisateur peut avoir une image_profile.
2. Un utilisateur peut avoir plusieurs projet dans lequel il peut doit avoir un role, toutes
ces informations seront enregistrer dans UserProjet.
3. Un projet peut contenir des stories.
4. Un projet peut contenir des itérations.
5. Une itération peut avoir des avancements qui enregistrent les modifications
quotidiennes.
6. Une itération peut être reliée à des stories.
7. Une itération doit avoir une iteration_status.
8. Une storie doit avoir un storie point.
9. Une storie doit avoir une storie_etat.
10. Une storie peut contenir plusieurs tâches.
11. Une storie peut contenir plusieurs Commentaires publié par des utilisateurs.
12. Une Tâche peut être reliée à un utilisateur.
13. Une tâche doit avoir une tâche_etat.
56
VI.3 Diagramme de classe
Le diagramme de classe est une représentation statique des éléments qui composent un
système et de leurs relations. Chaque application qui va mettre en œuvre le système sera une
instance des différentes classes qui le compose.
57
Role
- id_role : int
- label : String 0..1
ProjetStatus
- id_projet_status : int
1..1 - label : String
Image_profile Utilisateur UserProjet
- id_image_profile : int - id_utilisateur : int
0..1 - Date : Date
- image_name : String - pseudo : String
- image : LongBlob 1..1 1..1
- motdepasse : String
0..*
- nom : String
- prenom : String
- email : String Projet
- datelogin : Date 1..* - id_projet : int
- dateinscri : Date
0..1 0..* - nom : String
- datecreation : Date
1..1
0..*
1..1
Commentaire Avancement
- text : String - id_avancement
- date : Date - heursrestant
- datejour
- jouractuel
0..*
0..* 0..*
0..* 1..1 0..*
Storie
Tache Iteration
- id_storie : int 0..*
- id_tache : int 0..* - titre : String - id_iteration : int
0..1
- label : String - code : int
1..1 - role : String
- estimation : int - mission : String
- objectif : String
- benefices : String 0..* - debut : Date
- Criteres_acceptation : String - fin : Date
- joursrestant : int
0..* 1..1 - nbrstories : int
- storiesterminer : int
0..*
Point - heurstravailtotale : int
- heurstravailrestant : int
- id_point : int
- pointsprevus : int
- npoint : int
- pointterminer : int
- velocite : double
0..*
1..1 1..1 1..1
Tache_etat Storie_etat Iteration_status

- id_tache_etat : int - id_storie_etat : int - id_iteration_status : int
- type : String - type : String - label : String
Figure 32 Diagramme de classe
VI.4 Schéma relationnel

Utilisateur(id_utilisateur, pseudo, motdepasse, nom, prenom, email, dateinscri, datelogin)
Image_profile(id_image_profile, image_name, image,# id_utilisateur)
58
Projet(id_projet, nom, datecreation, #id_projet-status)
Projet_Status(id_projet-status, nom, datecreation)
Userprojet(id_userprojet,# id_utilisateur,# id_projet,# id_role, date)
Role(id_role, label)
Iteration(id_iteration,code,mission, debut, fin, durée, joursrestant, nbrstories, storiesterminer,
heurstravailtotale, pointsprevus, pointterminer, velocite,# id_projet, #id_iteration_status)
Iteration_status(id_iteration_status , label)
Avancement (id_avancement , heursrestant, datejour, datejour, jouractuel,
#iteration)
Storie(id_storie , titre, role, objectif, benefices, Criteres_acceptation, #id_projet,
#id_iteration,# id_storie_etat, #id_point)
Storie_etat(id_storie_etat, type)
Point(id_point, npoint)
Commentaire(id_commentaire ,# id_utilisateur,# id_storie, text, date)
Tache(id_tache, label, #id_utilisateur, #id_storie,# id_tache_etat, estimation)
Tache_etat(id_tache_etat, type)
VII. Conception du niveau application
VII.1 Digrammes de séquences

Ce diagramme permet de bien présenter les interactions entre les acteurs et le système
selon un ordre chronologique bien défini. Il sert à décrire les cas d'utilisation, à modéliser la
59
mise en œuvre d'une classe, et plus généralement, à ajouter un aspect dynamique à la
modélisation d'un système.
VII.1.1 Digramme de séquence objet « S’authentifier »

S'authentifier
Modele Vue Vue

Controlleur Utilisateur Page d'authentification Page d'accueil
Utilisateur
S'authentifier(1)
Afficher(2)
Saisir données(3)
Instanciation(4)
Verification(5)
envoyer résultat(6)
alt Authentification echouée
Afficher message erreur(7)
Authentification réussie
Afficher(8)
Figure 33 Digramme de séquence objet « S’authentifier »
Pour s’authentifier
1. L’utilisateur demande la page d’authentification.
2. Le contrôleur affiche la page d’authentification.
3. L’utilisateur saisit ses données (pseudo et mot de passe)
4. Le contrôleur instancie le modèle utilisateur
5. Le modèle utilisateur vérifie les données saisies.
6. Le modèle utilisateur envoie au contrôleur le résultat de vérification.
Si les données sont correctes
60
7. Le contrôleur affiche la page d’accueil.
Sinon
8. Le contrôleur affiche un message d’échec d’authentification.
VII.1.2 Digramme de séquence objet « Accéder à un projet »

Accéder à un projet
Modele Vue Vue

Tableau de bord
Controlleur Projet projet Page d'accueil
Membre d'équipe
Accéder à un projet()
Demander liste des projets(1)
Charger la liste des projets(2)
Instanciation(4)
Afficher(5)
Filtrer les composants(6)
Figure 34 Digramme de séquence objet « Accéder à un projet »
1. Le membre d’équipe demande la liste des projets.
2. Le contrôleur charge la liste des projets.
3. L’utilisateur accède à un projet.
4. Le contrôleur instancie le modèle projet
5. Le contrôleur affiche le tableau de bord du projet.
6. Le contrôleur filtre composant de la page selon le rôle du Membre d’équipe dans ce
projet.
VII.1.3 Digramme de séquence objet « S’engager à une tache »
61
S'engager â une tâche
Modele Vue Vue Vue

Tableau de bord Tableau de bord Tableau de bord
Controlleur Tâche
projet iteration storie
Développeur
ref <<Accéder a un projet>>

S'engager â une tâche()
Demander la liste des iterations(1)
Charger la liste des iterations(2)
Accéder a une iteration en cours(3)

afficher(4)
Charger la liste des stories assosiées a

cette iteration(5)
Accéder a une storie(6)
Afficher(7)
Charger les tâches par état(8)
S'engager â une tâche(9)
Changer état vers "En cours"(10)
Relier la tâche avec ce développeur(11)
Rafrechir(12)
Figure 35 Diagramme de séquences « S’engager à une tache »
Après avoir authentifier et accéder à son projet
1. Le développeur demande la liste des itérations.

2. Le contrôleur charge la liste des itérations.
3. Le développeur accède â une itération en cours.
4. Le contrôleur affiche le tableau de bord de cette itération
5. Le contrôleur charge les stories associées à cette itération par état
6. Le développeur accède à une sortie
7. Le système affiche le tableau de bord de cette sortie
8. Le système charge les tâches de cette sortie par état.
9. Le développeur s’engage à une tache
62
10. Le contrôleur change l’état de cette tache vers « en cours »
11. Le contrôleur relie la tâche avec ce développeur.
12. Le contrôleur rafraîchit le tableau de bord du storie.
VII.1.4 Digramme de séquence objet« Terminer une tâche »

Terminer une tache
Modele Modele Modele Vue Vue Vue
Tableau de Tableau de Tableau de
Controlleur Tâche Iteration Avancement
bord projet bord iteration bord storie
Développeur
ref <<Authentification>>
ref <<Accéder a un projet>>
Demander la liste des iterations(1)

Charger la liste des iterations(2)
Accéder â une iteration en cours(3)

afficher(4)
Charger les stories assosiées a cette

iteration par état(5)
Accéder a une storie non terminée(6)
Afficher(7)
Charger les tâches par état(8)
Terminer une tâche(9)
Changer l'état vers "Terminer"(10)
Mettre â jours(12)
Mettre â jours(13)
Rafrechir(14)
Figure 36 Digramme de séquence objet« Terminer une tâche »
Après avoir authentifier et accéder à son projet
1. Le développeur demande la liste des itérations.

2. Le contrôleur charge la liste des itérations.
3. Le développeur accède â une itération en cours.
4. Le contrôleur affiche le tableau de bord de cette itération.
63
5. Le contrôleur charge les stories associées à cette itération par état.
6. Le développeur accède à une sortie non terminée.
7. Le système affiche le tableau de bord de cette sortie.
8. Le système charge les tâches de cette sortie par état.
9. Le développeur termine une tâche en cours qui lui appartient.
10. Le contrôleur change l’état de cette tâche vers « Terminée ».
11. Le contrôleur mettre à jours l’itération.
12. Le contrôleur mettre à jours le modèle avancement.
13. Le contrôleur rafraîchit le tableau de bord de la sortie.
VII.2 Diagramme d’activités

Un diagramme d'activités permet de modéliser un processus interactif, global ou partiel
pour un système donné (logiciel, système d'information). Il est recommandable pour exprimer
une dimension temporelle sur une partie du modèle, à partir de diagrammes de classes ou de
cas d'utilisation
64
VII.2.1 Diagramme d’activité « Compléter une storie »
Propriétaire du produit Maitre de mélée Développeur Systeme
Créer un storie
Remplir la storie par des taches
assosier la storie a une

iteration en cours
S'engager a des taches
Terminer des taches
[Toutes les taches d'une storie sont

terminée]
La storie est terminée
[Les taches d'une storie ne sont pas tous

terminées]
Terminer l'iteration
la storie n'est pas terminée
Restaurer la storie
Figure 37 Diagramme d'activité "Compléter une storie"
65
VII.2.2 Diagramme d’activité « Compléter une iteration »
Maitre de mélée Développeur Systeme Cadenceur
Associer une storie

a cette iteration
Accéder a une storie

non terminée
S'engager d'une tâche
Terminer une tâche
Terminer une storie
Mettre a jours l'iteration

Si toutes les
Si la storie Si l'iteration
tâches d'une
contient des contient des
tâches non storie sont
terminées stories non
terminées terminées
Mettre â jours le
Decision_3 Decision_2 graphique d'avancement
Si toutes les
stories dans
l'iteration sont Si les jours restants dans l'iteration
terminées supérieur â zero
Terminer l'iteration
Si les jours restants dans l'iteration egale
â zero
Calculer la velocité
Figure 38 Diagramme d’activité « Compléter une iteration »
66
VII.2.3 Diagramme d’activité « Compléter un projet»
Propriétaire du produit Maitre de mélée Développeur Systeme
Créer des stories
Créer une iteration

Les stories du projet sont non
terminées
Terminer des tâches
Assosier des stories a une iteration

Terminer stories
Terminer iteration
Restaurer stories
Les stories du projet sont terminées
Terminer le projet
Figure 39 Diagramme d’activité « Compléter un projet »
67
VIII. Conception du niveau présentation
Les chartes graphiques est une étape importante dans la conception de ce système. Il s’agit
de concevoir la maquette qui va définir l’aspect global de l’application. Le but d’une charte
graphique est de concevoir une cohérence graphique entre les réalisations graphiques d’un
même projet.
VIII.1 Tableau de bord projet

 L’entête de cette page va contenir la barre de navigation, l’image du profile de
l’utilisateur ainsi que son nom.
 La barre gauche va contenir l’équipe et les stories du projet
 Le contenu du page va contenir la liste des itérations, bouton de création d’une
nouvelle itération ainsi que une horloge serveur.
Figure 40 Charte graphique "Dashbord projet"
68
VIII.2 Tableau de bord Itération
 La barre gauche va contenir les détails d’une itération ainsi que le bouton de
démarrage.
 Le contenu de la page va contenir les stories triées selon état, bouton qui affiche la
page de graphique d’avancement et une horloge serveur.
Figure 41 Charte graphique "Dashbord iteration"
69
VIII.3 Tableau de bord storie
 La barre gauche va contenir les détails d’une storie et les commentaires.
 Le contenu de la page va contenir les tâches qui sont (glissables/déposables) triées par
état, bouton pour ajouter une tâche et une horloge serveur.
Figure 42 Charte graphique "Tableau de bord storie"
70
VIII.4 Page de graphique de vélocité
 La barre gauche va contenir l’équipe et les stories du projet
 Le contenu du page va contenir le graphique d’avancement ainsi que une horloge
serveur.
Figure 43 Chart graphique "grafique de vélocité"
71
VIII.5 Page de graphique d’avancement
 La barre gauche va contenir les détails d’une itération.
 Le contenu de la page va contenir le graphique d’avancement et une horloge serveur.
Figure 44 Charte graphique "graphique d'avancement"
72
IX. Déploiement
Le diagramme de déploiement est une vue statique qui sert à représenter l’infrastructure
physique du système et la manière dont les composants du système sont répartis ainsi que
leurs relations entre eux.
Client
Web Browser
HTTP
Application server
Tomcat server
JDBC
Database Server
Mysql database
Figure 45 Diagramme de déploiement
Conclusion
Dans ce chapitre, on a présenté une vue sur la conception de la plateforme en utilisant le
langage UML. On a indiqué l’architecture jee. On a également détaillé les différents modules,
en élaborant les diagrammes de classes, les diagrammes de séquences et les diagrammes
d’activités.
Dans le chapitre suivant, on va s’appuier sur le développement et le travail réalisé, c’est le
chapitre« Réalisation ».
73
Chapitre 5
La Réalisation
74
Introduction
Après avoir terminé la phase de la conception, il est temps de passer au développement et

à la partie de la réalisation.
Ce chapitre constitue la dernière partie du rapport. Il a pour objet d’exposer le travail réalisé.
Je vais présenter donc l’environnement matériel du projet ainsi que les outils de
développement utilisés. Je vais ensuite montrer les différents aperçus d’écran illustrant les
fonctionnalités de la plateforme.
I. Environnement de développement
IX.1 Environnement matériel

Pour la réalisation de ce projet, Nous avons utilisé :
Marque Asus
Processeur dur I5
Mémoire 6Go
Disque 500Go
Marque Hp
Processeur dur I5
Mémoire 4Go
Disque 500Go
75
IX.2 Environnement logiciel
IX.2.1 Les Framework
1. bootsfaces
Une Framework JSF puissant et léger basé sur Bootstrap 3 et jQuery UI, Qui vous permet
de développer des applications d'entreprise front-end rapidement et facilement[13]
2. Primefaces
PrimeFaces est une bibliothèque de composants d'interface utilisateur (UI) open source
pour les applications JavaServer Faces (JSF), créée par PrimeTek, Turquie [14].
C'est un Framework qui offre
o Un point de vue différent,
o Simplicité et Performance ,
o Facilité d'utilisation.
3. JSF
Java Server Faces est un Framework de développement d’application Web en Java permettant de
respecter le modèle d’architecture MVC et basé sur des composants côté présentation[15].
4. Facelet
 Technologie de présentation pour le développement d'applications web en Java .
 Système de templating : permet de définir des vues de JSF en utilisant des calibres du
modèle HTML .
 Réduit la quantité de code nécessaire pour intégrer des composants dans la vue.
IX.2.2 Les Outils
76
1. TOMCAT
L'utilisation d'un serveur Java EE est obligatoire pour le développement de pages
Web dynamiques en Java EE. Un serveur HTTP classique reçoit des requêtes
HTTP et renvoie des réponses mais il ne connait pas les Servlets, les JSP... Il est
donc essentiel d'utiliser un programme appelé moteur de Servlets qui est contenu
dans le serveur Java EE et qui permet de pallier ce manque[16].
2. APACHE
Apache est le serveur Web le plus utilisé sur Internet. Dans une architecture en
production, il est recommandé d'utiliser un serveur Web en frontal d'un serveur
d'applications. Ces recommandations sont également appliquées dans le cas de
l'utilisation d'un conteneur Web comme Tomcat. Développement d’une application
JAVA EE – Plan de projet Page 18 sur 19 OFPPT L'utilisation d'un serveur Web
en frontal est nécessaire dans ce projet pour des raisons de performance, de
sécurité et de flexibilité.
3. Coupler Tomcat et le serveur web Apache

L'intégration d'un serveur Tomcat avec un serveur Web se fait au travers d'un
connecteur configuré au sein de Tomcat et d'une extension ajoutée au serveur
Web. Un connecteur Tomcat est une classe Java qui supporte un protocole réseau
spécifique et propriétaire. La librairie d'extension du serveur Web permet un
dialogue entre les deux serveurs.
4. MySQL
Le SGBD MySQL est supporté par un large éventail d'outils. MySQL est surtout
installé pour les applications Web, ce SGBD est solide et utilisé par de grands
groupes spécialisés dans l'Internet. Plusieurs pilotes natifs de type 4 sont
disponibles pour MySQL et sont conseillés pour une utilisation en Java [17].
77
5. ECLIPSE
Eclipse est l'environnement de développement (spécialisé pour le langage Java)

qui sera utilisé dans ce projet. Le choix d'Eclipse repose essentiellement sur sa
gratuité, sa facilité d'utilisation, sa puissance de développement et surtout ses
nombreux plugins (bibliothèques additives)[18].
6. PowerAMC
PowerAMC est un de conception créé par la société SDP, qui permet de
modéliser les traitements informatiques et leurs associées.
7. Themeroller
Cet éditeur de thème très pratique va nous permettre de customiser notre thème.
X. Les interfaces
Cette partie présente les principales interfaces graphiques de note application
78
X.1 La page d’index
Cette page offre aux internautes la possibilité d’avoir une idée sur notre outil.
Figure 46 Interface graphique « Page d'index »
X.2 L’interface de connexion

Cette page permet à l’utilisateur de s’authentifier et accéder à son tableau de bord.
Figure 47 Interface graphique « Page d’authentification »
X.3 Tableau de bord projet

Cette interface offre une idée générale sur les éléments d’un projet et un espace de gestion des
itérations.
79
Figure 48 Interface graphique « Tableau de bord projet »
X.4 Page d’accueil

Cette interface offre une idée générale sur les dernières statistiques qui concerne l’utilisateur.
Figure 49 Interface graphique « Page d'accueil »
X.5 Page d’équipe

Cette page offre un espace de gestion d’équipe pour le maitre de mêlée.
80
Figure 50 Interface graphique « Page d'équipe »
X.6 Page de graphique d’avancement

Cette page affiche le graphique de d’avancement d’une itération.
Figure 51 Interface graphique « Page de graphique d'avancement »
X.7 Page de graphique de vélocité

Cette page affiche le graphique de vélocité d’un projet.
81
Figure 52 Interface graphique « Page de vélocité »
X.8 Tableau de bord storie

Cette page offre un tableau de manipulation des taches ainsi que un espace pour publier
quelques commentaires.
Figure 53 Interface graphique « Tableau de bord storie »
X.9 Page rétrospectives

Cette page offre toutes les outils nécessaires pour que faire de bonnes rétrospectives.
82
Figure 54 Interface graphique « Page rétrospectives »
XI. Chronogramme
La clé principale de la réussite d'un projet est un bon planning.
En effet, le planning aide à bien subdiviser le travail et séparer les taches à réaliser, il
offre une meilleure estimation et gestion de temps nécessaire pour chaque tache. De plus,
il donne assez de visibilité permettant d'estimer approximativement la date d'achèvement de
chaque tache.
Dans notre projet, nous avons estimé à réaliser notre application dans une durée
approximative de 3 moins. Le diagramme ci-dessous montre le planning que nous avons
adapté pour mener à bien notre réalisation des différentes parties du projet:
Recueil des besoins: le résultat de cette phase est de bien étude le marché et définir les
besoins globale de l’application
Analyse détaillée: le résultat de cette phase est de définir les besoins détaillés afin de clarifier
les fonctionnalités attendu par l’application.
Conception détaillée: il s'agit de détailler les spécifications des fonctions ainsi que la
structure des données, des contrôles et des interfaces.
Développement: il s'agit de de traduire la partie conceptuel dans un produit exécutable.
Test et validation : il s'agit de tester notre application et la valider avec nos encadreurs.
83
Rédaction du rapport : description détaillée de notre travail.
Le chronogramme ci-après schématise la chronologie de ces étapes durant la période du
projet.
Figure 55 Diagramme de Gant
Conclusion
Dans ce chapitre, on a présenté la phase de réalisation du projet en présentant l’environnement

matériel et l’environnement logiciel, notre chronogramme ainsi que les interfaces qui ont été
développé.
84
Conclusion générale
Pour conclure, On rappelle que ce projet a été effectué au sein de Centre National de
Formation de Formateurs et d’Ingénierie de Formation à Rades. Il consiste à développer un
outil de gestion de projet agile selon le modèle SCRUM, destinée aux équipes agiles.
Au niveau du développement, on a utilisé le langage de programmation Java. On a

profité pleinement du Framework JSF, grâce aux librairies Primefaces et bootfaces pour
réaliser la couche présentation, Mysql pour gérer notre base de données.
La réalisation de ce travail a été bénéfique sur plusieurs plans ; En effet, nous avons
appris comment surmonter les difficultés techniques que on a rencontré et surtout comment
faire face aux ambigüités et aux contraintes techniques pour tester de nouvelles alternatives
aboutissant à l’accomplissement du projet.
Le travail était très intéressant puisqu’il nous a permis d’approfondir nos

connaissances en méthodes agiles et surtout SCRUM.
Au futur, il sera possible d’utiliser cet outil et de bénéficier des fonctionnalités offert
gratuitement.
85
Bibliographie et néographie
[1] http://www.ordinateur.cc/Logiciel/Logiciels-de-productivité/163559.html
[2] http://www.agiliste.fr/outils-gestion-de-projet/
[3] https://www.thinkmind.org/download.php?articleid=icsea_2012_21_40_10376
[4] http://www.responsive-mind.fr/cycles-developpement-informatique/
[5] http://www.piloter.org/projet/methode/uml.htm
[6] http://www.supinfo.com/articles/single/461-introduction-methode-scrum
[7] https://fr.wikipedia.org/wiki/Scrum_(Boite_à_outils)
[8] https://fr.wikipedia.org/wiki/Récit_utilisateur
[9] http://www.aubryconseil.com/post/Le-backlog-de-produit
[10] https://fr.wikipedia.org/wiki/Burndown_chart
[11] http://www.aubryconseil.com/post/2007/01/29/168-la-velocite-d-un-sprint
[12] https://fr.wikipedia.org/wiki/Modèle-vue-contrôleur
[13] https://www.bootsfaces.net
[14] https://www.primefaces.org
[15] http://gardeux-vincent.eu/Documents/ProjetJEE/HPV_JSF_Castor/jsf.html
[16] http://www.chercheinfo.com/uploads/1968-724e861856.pdf
[17] https://fr.wikipedia.org/wiki/MySQL
[18] https://fr.wikipedia.org/wiki/Eclipse_(projet)
86
Résumé
Ce rapport décrit le travail qu’on a réalisé dans le cadre de l’obtention de notre licence
appliquée en technologie de l'informatique ISETCH, il s’est déroulé du 6 Février au 12 mai
2017 effectué au sein de Centre National de Formation de Formateurs et d’Ingénierie de
Formation à rades. Durant les trois mois, notre mission consiste à développer une application
de gestion de projet dans un cadre de développement agile. L’application va permettre aux
équipes de développement de collaborer sur des projets pilotés selon la méthodologie agile
Scrum. Le but de l’application est de faciliter le pilotage des projets en offrant une version
numérique des nombreux artefacts de la méthode Scrum (Carnet du produit, Itérations, Cartes,
Taches, tableau des taches etc.)Ce rapport se propose de décrire les différentes étapes par
lesquelles le projet a passé dans le but d’atteindre la solution actuelle.
Abstract
This report describes the work we carried out in the context of obtaining our ISETCH
Computer Technology License, which took place from 6 February to 12 May 2017 at the
National Training Center Trainers and Engineering Training in rades.Over the next three
months, our mission is to develop a project management application with an agile
development framework. The application will enable development teams to collaborate on
projects piloted using Scrum agile methodology. The purpose of the application is to facilitate
the project management by offering a digital version of the numerous artifacts of the Scrum
method (Product Log, Iterations, Maps, Tasks and Task Table etc.)The purpose of this report
is to describe the different stages in which the project was carried out in order to achieve the
present solution.
‫تلخيص‬
‫يصف هذا التقرير العمل الذي قمنا بتنفيذه للحصول على االجازة التطبيقية لتطوير االنظمة المعلوماتية بالمعهد العالي‬
‫للدراسات التكنولوجية بالشرقية وقد تم اجراء هذا المشروع في المركز الوطني للتدريب المدربين والموانئ في هندسة‬
‫ التطبيق سوف لفرق‬.‫ مهمتنا كانت تطوير اداة إلدارة المشاريع في إطار الطرق الرشيقة‬،‫ خالل األشهر الثالثة‬.‫التكوين‬
‫العمل على قيادة مشاريعهم والغرض من هذا التطبيق هو تسهيل إدارة المشاريع من خالل تقديم نسخة رقمية االداة سكروم‬
‫وهذا التقرير هو لوصف مختلف الخطوات التي اجتازها المشروع كي يصل إلى النتيجة الحالية‬.
87

Langue

Bienvenue sur Scribd !

Rapport_finale.docx

Transféré par

Informations du document

Date du transfert

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Rapport_finale.docx

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Titres liés

REPUBLIQUE TUNISIENNE

Conception et développement d’un outil de

Encadré Par: Elaboré par :

Mme Ahlem Tayachi Saber Gannouni

Mr. Radhouani Aref Mohamed baha

Société d’accueil : " Centre National de Formation de Formateurs et d’Ingénierie

Année Universitaire : 2016/2017

Finalement, on présente toute nos gratitudes au corps pédagogique et administratif de l’ISET

CHAPITRE 1 PRÉSENTATION DU CADRE DU PROJET.................................................................3

II. Etude de marché..............................................................................................................................................5

III. Méthodologie adoptée...............................................................................................................................12

CHAPITRE 2 INTRODUCTION AUX MÉTHODES AGILES ET SCRUM......................................16

I. Que sont les méthodes agiles ?......................................................................................................................17

II. Pourquoi utiliser les méthodes agiles ?.........................................................................................................17

CHAPITRE 3 SPÉCIFICATION DES BESOINS................................................................................26

I. Etude des besoins...........................................................................................................................................27

I. Architecture globale de la solution................................................................................................................51

II. Conception du niveau données......................................................................................................................53

III. Conception du niveau application.............................................................................................................58

IV. Conception du niveau présentation...........................................................................................................66

II. Les interfaces.................................................................................................................................................77

II.1 Le marché visé

Figure 1 Interface grafique de Rally

Figure 2 Interface grafique VersionOne

Figure 4 Interface grafique ScrumWorks

Figure 5 Interface grafique Agilo

Cet outil dispose de plusieurs fonctionnalités intéressantes comme la chronologie, le

II.2 Etudier la concurrence

Outil Méthode Licence Plateforme

Scrumworks Scrum Commerciale, gratuit Windows,Linux,Mac OS X

Rally Scrum Commerciale, gratuit Windows,Linux,Mac OS X

Scrumdesk Scrum, XP, FDD, Commerciale, gratuit Windows

On va évaluer nos outils à partir de vingt et un critères :

Les critères Version One ScrumWorks Rally ScrumDesk Agilo

L'extensibilité 0,0 0,0 0,0 0,0 10,0

La connectivité 10,0 7,0 5,0 6,0 5,0

La recherche 8,0 6,0 10,0 6,0 4,0

Le Groupement 10,0 9,0 7,0 0,0 4,0

L'édition simultanée 9,0 10,0 10,0 10,0 9,0

La Suivi de l'état de l'histoire 9,0 10,0 9,0 9,0 4,0

Le suivi général de l'état 8,0 5,0 9,0 9,0 0,0

Backlog du sprint 6,0 7,0 5,0 7,0 3,0

Stories 9,0 10,0 7,0 7,0 3,0

Estimation 6,0 5,0 8,0 9,0 6,0

Tâches 9,0 10,0 8,0 10,0 8,0

Les équipes 5,0 7,0 7,0 8,0 10,0

Progrès 10,0 6,0 8,0 6,0 5,0

Tableau de bord 8,0 10,0 0,0 9,0 6,0

Burndown 10,0 8,0 10,0 9,0 9,0

Lieu de travail à distance 10,0 10,0 10,0 10,0 10,0

Notation totale 163,0 151,0 145,0 145,0 111,0

Cote totale normalisée 7,8 7,2 6,9 6,9 5,3

Cote totale normalisée pour chaque outil

Figure 8 diagramme de cote totale pour chaque outil

 Répond aux demandes de changement et évalue leurs impacts.

 Capable de dessiner des graphiques d’avancement claire et compréhensible [Fig9]

Utilisateur 1 Utilisateur 2 Utilisateur 3 Utilisateur 4

Figure 10 Graphique d’effort individuel