Sprint 0 : Phase de Préparation
I. Introduction :
Dans le deuxième chapitre, nous avons choisi d’adopter la méthodologie Scrum
pour concevoir notre futur système. Dans ce chapitre, nous présentons les
phases de planification et d’architecture. Nous déterminons les principales
fonctionnalités à fin de générer le backlog produit et la première
planification des sprints, et définissons les outils utilisés pour mettre en œuvre le
projet.
II. Modélisation du contexte :
1. Identification des acteurs :
L’application met en interaction 2 acteurs :
Utilisateurs : Ce sont les personnes qui utilisent la bibliothèque pour effectuer
un dépôt d’une demande d’intervention, consulter l’etat de demande en ligne,
effectuer des modifications sur la demande, etc.
Administrateur: Ce sont les personnes responsables de la gestion quotidienne
de site. Ils sont chargés de tâches telles que l'ajout d’acces pour les divers
parties (demandeur) dans l’entreprise, la mise à jour des informations sur la
demande, la gestion des comptes utilisateurs,diriger la demande vers le service
spécifié, etc.
Responsable d’intervention: ce sont les personnes qui contrôlent les
interventions et décident soit l’accepter ou non , Ils affectent l’intervention à un
ou plusieurs intervenants et assurent son suivi .
Intervenantes: : Ce sont les personnes responsables d’assurer les ressources
nécessaires (matérielle ,humaine) et après la partie de planifier et réaliser
l’intervention.
II.1.2 spécification des besoins :
Notre projet a pour but de faire l’analyse, la conception et la réalisation d’une
plateforme ”Games Gâte”. La solution que nous développons doit répondre aux
exigences et aux besoins que nous avons déterminés tout au long de la phase
de recherche
L’application que nous proposons doit principalement fournir les exigences
fonctionnelles et non
fonctionnelles suivantes :
Utilisateurs
Recherche de sa demande Consultation de l’état de demande
Gestion du compte utilisateur Avoir un compte de utilisateur
Donnés son avis
Administrateur
Gestion des comptes utilisateurs et des Personnalisation et configuration
ressources
Gestion des demandes prêtes Gestion des catégories et des
classifications
Donner l’acces a des nouveaux Assurer le suivi des demandes de ses
demandeurs collaborateur
Responsable d’intervention
Accepter les interventions ou non Affecter l’intervention a un ou plusieurs
intervenantes
Assurer le suivi de l’intervention
Intervenant
Assurer les ressources nécessaires Planifier et réaliser l’intervention
(materielle,humaine)
Consulter la liste des interventions
prétes
II.1.3 Diagramme de cas d’utilisation général :
Dans cette section, nous décrivons les exigences du système de manière formelle
en utilisant le
diagramme de cas d’utilisation global. La figure III.1 suivante montre toutes les
fonctions fournies par l’application.
0000000000(diagramme de cas d’utilisation)
FIGURE 1 : Diagramme de cas d’utilisation Global du sprint 0.
Nous présentons, dans ce qui suit une analyse globale comportant le diagramme
de classes ainsi que
l’architecture de la solution.
III. Analyse Globale :
1. Diagramme de classes d’analyse :
Après avoir modélisé le cas d’utilisation, nous arrivons au diagramme de classes
d’analyse illustré par la figure III.2 suivantes. Notons bien que les classes en bleu
sont du sprint 1, alors que les classes en rose sont du sprint 2 et 3.
0000000000(diagramme de classe)
FIGURE 2 : Diagramme de classes d’analyse.
IV. Pilotage du projet avec SCRUM :
1. Backlog produit :
Le Scrum Backlog a pour objectif de collecter tous les besoins des clients
auxquels l’équipe projet doit répondre. Par conséquent, il contient une liste des
fonctionnalités impliquées dans la composition du produit, ainsi que tous les
éléments qui nécessitent l’intervention de l’équipe projet. Les user-stories sont
caractérisés par :
Identifiant : qui est un identifiant unique pour l’user story
Description : elle décrit le besoin
Priorité : elle est utilisée pour définir l’ordre de réalisation
Estimation : elle estime la complexité de la tâche
Nous présentons le Backlog produit dans le tableau ci-dessous :
Fonctionnalités ID User stories Priorités
1 Authentification et gestion 1.1 En tant qu'utilisateur, je veux
de profile créer mon
compte
1.2 En tant qu'utilisateur, je veux
consulter
mon profil
1.3 En tant qu'utilisateur, je veux
modifier
mon profil.
En tant que administrateur, je
veux créer mon compte
En tant que administrateur, je
veux consulter mon profil
En tant que administrateur, je
veux modifier mon profil.
En tant que responsable
d’intervention, je veux consulter
mon profil
En tant que responsable
d’intervention, je veux modifier
mon profil.
En tant que intervenante, je veux
consulter mon profil
En tant que intervenante, je veux
modifier mon profil.
1.4 En tant que utilisateur, je veux
m’authentifier
1.5 En tant qu'administrateur, je veux
m’authentifier
1,6 En tant qu’un responsable
d’intervention ,je veux
m’authentifier
1,7 En tant que intervenante ,je veux
m’authentifier
2 Gestion du compte 2.1 En tant qu'utilisateur, je veux
créer mon
compte
2.2 En tant qu'utilisateur, je veux
consulter
mon profil
2.3 En tant qu'utilisateur, je veux
modifier
mon profil.
3 Gestion des demandes 3.1 En tant qu’utilisateur, je veux
avoir effectuer un dépôt de
demande d’intervention
3.2 En tant qu’utilisateur, je veux
consulter
mon demande
3.3 En tant qu’utilisateur, je veux
pouvoir
modifier ma demande
3.4 En tant qu’utilisateur, je veux
pouvoir
annuler ma demande
3.5 En tant qu’utilisateur, je veux
pouvoir
donner mon avis après la fin de
travaux
4 Gestion des Dashboards 4.1 En tant qu’utilisateur, je veux
consulter et
gérer mes demandes
4.2 En tant que administrateur, je
veux
pouvoir gérer les comptes, les
demandes et les utilisateurs
Sprint 1 Sprint 2 Sprint 3
• Authentification • Gestion des • Gestion des
demandes Dashboard
• Gestion du compte.
TABLE 1 : backlog produit
V. Planification des Sprints :
L’évènement le plus important de Scrum est la réunion de la planification du
sprint pendant lequel nous définissons les User-Stories à développer pendant la
période du sprint. Selon la charge de travail et notre estimation, nous avons
découpé notre projet en trois sprints de quatre semaines chacun. Nous avons
réparti les user-stories comme suit :
Sprint 1 : Gestion des comptes
I. Backlog du Sprint 1 :
Après avoir défini les objectifs du Sprint, nous avons décidé sur les user-stories à
inclure au premier sprint.
Nous présentons dans le tableau ci-dessous le backlog sprint1.
User stories Tasks Estimation/jour
Story less Installer l’environnement
de
travail
Créer la base des données
Implémenter les fichiers
nécessaires
Tester
Implémenter les interfaces
de
la navigation
En tant que utilisateur, je Implémenter la méthode
veux
d’authentification coté
m’authentifier web
service
Tester
Implémenter l’interface de
login avec le contrôle de la
saisie et la consommation
du web service
Implémenter la méthode
de
déconnexion
Tester
En tant que utilisateur, je Implémenter la méthode
veux de
créer mon compte création de compte coté
web service
Tester
Implémenter l’interface de
création de l’utilisateur
avec le contrôle de saisie
et la consommation du
web service
Tester
En tant que utilisateur, je Implémenter la méthode
veux de
consulter mon profile récupération et affichage
du profile coté web
service
Implémenter l’interface de
création d’affichage du
profile
Tester
En tant que utilisateur, je Implémenter la méthode
veux de
modifier mon profile modification du profil coté
web service
Implémenter l’interface de
modification du profile
Tester
En tant que utilisateur, je Implémenter la méthode
veux consulter la page de récupération et
Home l’affichage de
la page home coté web
service
Implémenter l’interface de
la
page home
Tester
Table 1 : Backlog du Sprint 1
II. Analyse et spécification des besoins :
Dans un projet numérique, une spécification fonctionnelle permet d’approfondir
le détail du
fonctionnement de l’application. Dans cette partie nous décrivons les
fonctionnalités du sprint ainsi que les observés et leurs cas d’utilisation
1. Diagramme de cas d’utilisation global du sprint 1 :
La figure IV.1 suivante fournit une représentation graphique des différents cas
d’utilisation de notion sprint
000000000000000(diagramme de cas d’utilisation)
FIGURE 1 : Diagramme des cas d’utilisations global du Sprint 1
II.2 Description textuelle de cas d’utilisation ”consulter un demande” :
Titre Consulter une demande
Acteurs Utilisateurs
Objectif Permettre aux utilisateurs de consulter une demande
Préconditions Le client doit avoir un compte, il saisit ses droits d’accès
(login et mot de
passe)
Titre Consulter une demande
Acteurs Utilisateurs
Objectif Permettre aux utilisateurs de consulter une demande
Préconditions Le client doit avoir un compte, il saisit ses droits d’accès
(login et mot de
passe)
Table 2 : Description textuelle ” consulter un demande”
II.3 Conception (Diagramme de séquence du sprint1) :
0000000000000(Diagramme de séquence)
FIGURE 2 : Diagramme de séquance s’authentifier.
Sprint 2 :Gestion des demandes
I. Introduction :
Dans ce chapitre, nous continuerons la mise en œuvre du deuxième Sprint, au
cours duquel nous suivrons le même processus de présentation. Ce sprint a pour
objectif la gestion des demandes. Pour atteindre le fini du sprint, nous allons
développer, tester et valider les fonctionnaliser de ce sprint
II. Backlog du Sprint 2 :
Nous allons premièrement présenter dans le tableau V.1 suivant, le Backlog du
sprint2
User stories Tasks Estimation/jour
En tant que utilisateur, je Implémenter la méthode
veux
nécessaire pour afficher le
consulter les demandes formulaire d'abonnements
Tester
Implémenter l’interface
d'abonnements.
Tester
En tant que utilisateur, je Implémenter la méthode
veux du
Déposer une demande déposition d’une demande
Tester
Implémenter l’interface de
déposition
Tester
En tant que utilisateur , je Implémenter la méthode
veux de
modifier une demande modification
Tester
Implémenter le Button de
modification
Tester
Table 1 : Backlog du Sprint 2.
III. Analyse et spécification des besoins :
1. Diagramme de cas d’utilisation global du sprint 2 :
Le diagrame V.1 : évoque le diagramme de cas d’utilisation global du deuxième
sprint.
00000000000000(Diagramme de cas d’utilisation)
FIGURE 1 : Diagramme des cas d’utilisations global du Sprint 2.
III.3 Description textuelle de cas d’utilisation ”déposer une demande” :
Titre ”déposer une demande”
Acteurs utilisateur
Objectif Permettre aux utilisateur d'avoir déposé une demande
Pré-conditions Le utilisateur doit être authentifié
Post-conditions Redirection vers le formulaire de déposition des demandes
Scénario de base Le utilisateur accédé a la home-page
Le utilisateur va cliquer sur bouton "déposer" en haut de page
"navbar"
Le système rédiger le utilisateur vers le formulaire de
déposition des demandes
Le utilisateur va remplir le formulaire
Le système va vérifier que tous les champs sont remplis , En
cas d’erreur
afficher ”Exception1”.
Le système va afficher un message de validation au
utilisateur et va le diriger
vers la page home.
Scénario message d’erreur « Remplissage du formulaire est obligatoire
d’exception »
1
Table 2 : Description textuelle ” déposer une demande”
III. Conception (Diagramme de séquence du sprint 2) :
Le diagramme V.2 suivant évoque le diagramme de séquence du deuxième sprint
0000000000(Diagramme de sequence)
Sprint 3 : Gestion des Dashboard
I. Introduction :
Après avoir terminé le développement et la conception du deuxième sprint de
notre application, nous passons maintenant au troisième Sprint qui possède la
gestion des Dashboard .
II. Backlog du Sprint 3 :
Nous allons identifier les ”user stories” qui sont incluses dans cette liste des
tâches relatives au troisième Sprint. Le tableau VI.1 suivant récapitule la liste
des taches à développer.
User Stories Tasks Estimation\jour
En tant que utilisateur, je Implémenter la méthode
veux
nécessaire pour afficher
consulter ma demande: les demandes.
Tester.
Implémenter l’interface
pour
consulter les demandes.
Tester.
En tant que utilisateur, je Implémenter la méthode
veux
nécessaire pour déposer
déposer et gérer mes une demande
demandes :
Tester.
Implémenter l'interface
pour
Déposer une demande.
Tester.
Implémenter l'interface
pour
gérer les demandes.
Tester.
En tant qu’administrateur, Implémenter la méthode
je
nécessaire pour ajouter
veux ajouter et gérer les un compte
comptes:
Tester.
Implémenter l'interface
nécessaire pour ajouter un
compte
Tester.
Implémenter l’interface
pour
gérer les comptes
Tester.
En tant qu’administrateur, Implémenter la méthode
je
nécessaire pour afficher
veux consulter les les utilisateurs.
utilisateurs :
Tester.
Implémenter l’interface du
consulter les utilisateurs.
Tester.
Implémenter la méthode
necessaire chercher une
demande.
Tester.
Implémenter la méthode
nécessaire pour modifier
un
demande.
Tester.
Implémenter la méthode
nécessaire pour suprimer
une demande
Tester.
Implémenter l’interface
pour
gérer les demandes.
Tester.
Implémenter la méthode
nécessaire pour chercher
une intervention
Tester
Implémenter la méthode
nécessaire pour vérifier
l’intervention
Tester
Implémenter l’interface
pour accepter
l’intervention
Tester
Implémenter la méthode
nécessaire pour chercher
une intervention
Tester
Implémenter la méthode
nécessaire pour vérifier
l’intervention
Tester
Implémenter l’interface
pour accepter
l’intervention
Tester
Implémenter la méthode
nécessaire pour chercher
une intervention
Tester
Implémenter la méthode
nécessaire pour vérifier
l’intervention
Tester
Implémenter l’interface
pour assurer le suivi de
l’intervention
Tester
Implémenter la méthode
nécessaire pour chercher
les ressources nécessaires
pour l’intervention
Tester
Implémenter la méthode
nécessaire pour choisir les
ressources nécessaires
Tester
Implémenter l’interface
pour choisir les ressources
pour l’intervention
Tester
Table VI.1 : Backlog du Sprint 3.
III. Analyse et spécification des besoins :
Dans cette section, nous visons à déterminer formellement le stade initial de
développement du sprint à fin que ce développement soit plus en phase avec
nos besoins
1. Diagramme de cas d’utilisation global du sprint 3 :
Nous illustrons dans la figure VI.1 suivante le diagramme de cas d’utilisation du
sprint3.
000000000(Cas d’utilisation)
FIGURE 1 : Diagramme de cas d’utilisation global du sprint 3
VI.3.2 Description textuelle de cas d’utilisation gérer demande
Titre ”gérer demande”
Acteurs utilisateur
Objectif Permettre aux utilisateur de gérer leurs demandes.
Pré-conditions Le utilisateur doit être connecté.
le utilisateur doit avoir au moins un demande.
Post- Redirection vers l’interface de la gérer des demandes.
conditions
Scénario de le utilisateur demande l’accès a l’interface compte.
base
le système va afficher l’ensemble des demandes.
le système va afficher l’interface du Dashboard utilisateur.
Table 2 : Description textuelle ”gérer demande”
IV. Conception (Diagramme de séquence de sprint 3) :
0000000(Diagramme de sequence)
V. Conclusion :
Au cours de ce chapitre, nous avons entamé la présentation de notre troisième et
dernier sprint selon la méthodologie de gestion de projet SCRUM, en présentant
la conception, le développement et les interfaces relatives a ce sprint.
