Conclusion :
Ce chapitre présente une phase préparatoire de
notre projet pour mieux comprendre le système, au cours duquel nous
avons bien présenté l'architecture de notre application,
l'environnement du travail et une conception d'analyse globale. Le chapitre
suivant sera dédié à l'étude des sprints 1 et 2.
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
34
Chapitre 3 : Conception et Réalisation du
sprint 1 et 2
35
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
Chapitre 3 : Conception et Réalisation des
sprints 1 et 2
Introduction
Après avoir présenté les concepts et les
technologies nécessaires à notre projet, nous pouvons maintenant
nous lancer dans les travaux nécessaires pour produire les trois
premiers sprints. Le premier sprint sera composé de deux cas
d'utilisation, nous allons donner une vision statique, dynamique et
fonctionnelle de chaque cas à travers les diagrammes de cas
d'utilisation détaillés et les diagrammes de séquences.
Ensuite, dans le deuxième sprint, nous aurons les cas d'utilisation et
nous allons traiter ces derniers pour avoir à la fin de ce sprint les
tâches d'établissements que nous intégrerons à notre
application.
Enfin, pour terminer les sprints, nous présentons les
interfaces relatives aux fonctionnalités implantées à ce
stade.
3.1 Développement du Sprint 1
Le sprint 1 permet d'effectuer l'authentification et gérer
les utilisateurs.
3.1.1 Sprint backlog produit « sprints
1»
Le tableau 4 regroupe tous les fonctionnalités qui seront
réalisé au sien du premier sprint :
Tableau 4: Sprint backlog « sprint1
»
ID User Story
|
User story
|
1.1
|
En tant que développeur, nous devons préparer
l'environnement de travail.
|
1.2
|
En tant qu'utilisateur de l'application, nous devons
s'authentifier.
|
1.3
|
En tant qu'administrateur, nous pouvons ajouter un compte
utilisateur.
|
1.4
|
En tant qu'administrateur, nous pouvons modifier un compte
utilisateur.
|
1.5
|
|
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
|
En tant qu'administrateur, nous pouvons supprimer un compte
utilisateur.
|
1.6
|
En tant qu'administrateur, nous pouvons consulter la liste des
comptes utilisateurs.
|
3.1.2 Analyse
Pour mieux comprendre les fonctionnalités du sprint 1,
nous allons maintenant passer à la partie analyse commençant par
le diagramme de cas d'utilisation.
3.1.2.1 Analyse de cas d'utilisation du sprint
1
La figure 7 illustre le diagramme de cas d'utilisation pour ce
premier sprint :
Figure 7 Diagramme de cas d'utilisation du sprint
1
36
37
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
3.1.2.2 Analyse de cas d'utilisation «
Authentification »
Dans la figure 8 nous allons détailler le cas
d'utilisation « s'authentifier
».
Figure 8: Diagramme de cas d'utilisation
authentification
? Description textuelle dans le cas d'utilisations «
Authentification »
Le tableau 5 présente la documentation textuelle du cas
d'utilisation pour l'authentification.
Tableau 5 Documentation textuelle du cas
d'utilisation « Authentification »
Cas d'utilisation
|
<<authentification>>
|
Résumé
|
Après succès d'authentification l'utilisateur peut
avoir son tableau de bord.
|
Acteur
|
Tous les acteurs.
|
Précondition
|
Besoin d'authentification.
|
Post condition
|
La mise à jour de la base de données est
effectuée selon la tâche choisie.
|
Scénario principale
|
1. Le système affiche la page login.
2. Le système enregistre les informations et affiche le
message de retour.
|
Exception
|
Des erreurs peuvent être produites lors d'un contrôle
de saisie par exemple.
|
38
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
3.1.2.3 Analyse de cas d'utilisation « Gérer
utilisateur »
Dans la figure 9 nous allons détailler le cas
d'utilisation « gérer utilisateur
».
Figure 9 Diagramme de cas d'utilisation «
Gérer Compte utilisateur » ? Description textuelle du cas
d'utilisations « gérer utilisateur»
Le tableau 6 présente l'acteur principal du cas
d'utilisation : « Gérer les utilisateurs », les
précautions, le scénario nominal, alternatif, le résultat
attendu de ce cas d'utilisation, ainsi qu'une description textuelle.
Tableau 6 Documentation textuelle du cas
d'utilisation «Gérer les utilisateurs»
Cas d'utilisation
|
«Gérer les utilisateurs».
|
Résumé
|
Après succès de l'authentification,
l'administrateur gère la liste des utilisateurs de notre application
web.
|
Acteurs
|
Administrateur.
|
Pré condition
|
L'administrateur a besoin de s'authentifier.
|
Post condition
|
La mise à jour de la base de données est
effectuée selon la tâche choisie.
|
Scénario principale
|
1. Le système affiche la page de gestion des
utilisateurs.
2. L'administrateur choisit et valide la tâche à
effectuer.
3. Le système enregistre les informations et affiche le
message de retour.
|
Exception
|
Des erreurs peuvent être produites : contrôle de
saisie et utilisateur existent déjà.
|
39
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
3.1.3 Conception dynamique du premier sprint
1
Cette partie sera consacrée à une étude
détaillée de notre système. Pour cela, nous avons choisi
deux cas d'utilisation du sprint1 : l'authentification, la gestion de
l'utilisateur.
3.1.3.1 Diagramme de séquences objet relatif au
cas d'utilisation « Authentification » Il permet de
décrire les interactions entre un groupe d'objets en montrant de
façon séquentielle les envois des messages qui interviennent
entre les objets. Le diagramme peut également montrer les flux des
données échangées lors des envois de messages.
Pour s'authentifier, l'utilisateur accède à
l'application ; ensuite, saisit son login et son mot de passe. Si les
données saisies sont correctes, le système redirige l'utilisateur
vers son compte, sinon, un message d'erreur s'affiche.
Figure 10 Diagramme de séquence objet relatif
au cas d'utilisation « Authentification »
3.1.3.2 Diagramme de séquences relatif au cas
d'utilisation « ajout utilisateur ».
Après l'authentification, l'administrateur demande le
formulaire d'ajout puis l'application affiche le formulaire d'ajout pour que
l'administrateur puisse saisir les nouvelles données. Ensuite,
l'application envoie la requête pour stocker les données au niveau
de la base de données. Enfin, l'application confirme
l'enregistrement.
40
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
Figure 11 Diagramme de séquence objet relatif
au cas d'utilisation « ajout utilisateur »
3.1.3.3 Diagramme d'activité «
Authentification »
Le diagramme d'activité « Authentification »,
nous permet de voir les comportements internes du système, lors du
démarrage de l'application par l'administrateur. Le système lui
affiche le formulaire d'authentification.
Figure 12 Diagramme d'activité «
Authentification »
Après que le login et mot de passe sont saisis, le
système vérifie la validité de ces données et lui
donne la page d'administration. Sinon, il affiche un message d'erreur et lui
demande de retaper le login et le mot de passe.
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
3.1.3.4 Diagramme d'activité « ajout
utilisateur ».
Après une demande d'ajout d'un utilisateur par
l'administrateur, le système lui affiche le formulaire d'ajout pour
qu'il puisse saisir ces données et confirmer leur enregistrement au
niveau de la base de données.
Figure 13 Diagramme d'activité « ajout
utilisateur »
3.1.4 Représentation des interfaces
Dans cette partie, nous allons présenter quelques
interfaces qui sont développées dans le sprint 1 et 2.
41
3.1.4.1 Vue d'accueil :
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
Figure 14: La page d'accueil
C'est la page d'accueil qui s'affiche dès l'accès
à notre application web
3.1.4.2 Vue authentification
Cette page permet à l'utilisateur de se connecter afin
d'accéder à l'application en introduisant le nom d'utilisateur et
son mot de passe avec un aspect de sécurité tout en limitant
l'accès aux utilisateurs non authentifiés.
42
Figure 15 Interface
d'authentification
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
43
Figure 16 Interface d'authentification cas de champ
vide
Cette page permet à tous les acteurs de s'authentifier
dans la base de données pour pouvoir ajouter des données. La
figure 16 présente le cas où l'un des champs ou les deux sont
vides :
3.1.4.3 Vue de la gestion des utilisateurs
Les figures 17 et 18 illustres la partie de gestion des
utilisateurs
Figure 17 Interface de consultation des
utilisateurs
44
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
Figure 18 Interface d'ajout
utilisateur
Cette partie est très intéressante dans notre
application, car l'administrateur peut avoir une vision sur la liste des
utilisateurs et la possibilité d'ajouter, modifier ou supprimer un
utilisateur et rechercher un utilisateur souhaité. Les figures 16 et 17
représentent les interfaces d'administration de notre application.
45
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
3.2 Développement sprint 2
Ce chapitre nous présente la deuxième partie de
notre application, le sprint backlog, la conception, l'implémentation et
la réalisation des interfaces utilisateur
3.2.1 Sprint block produit sprint 2
Le tableau 7 présente le backlog du sprint 2 qui a comme
objectif de regrouper les tâches d'un établissement dans notre
application web.
Tableau 7 Sprint backlog « sprint2
»
ID User Story
|
User story
|
2.1
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier, supprimer, consulter) des
élèves.
|
2.2
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier, supprimer, consulter) des absences
élèves.
|
2.3
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier,
supprimer, consulter) les sanctions des
élèves.
|
2.4
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier,
supprimer, consulter) les enseignant.
|
2.5
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier, supprimer, consulter) les absences des
enseignants.
|
2.6
|
|
46
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier, supprimer, consulter) les cadres.
|
2.7
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier, supprimer, consulter) les absences des
cadres.
|
2.8
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier, supprimer, consulter) les dettes.
|
2.9
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier, supprimer, consulter) les
protestations.
|
2.10
|
En tant qu'établissement, nous pouvons
gérer (ajouter, modifier, supprimer, consulter) les cas de
violence.
|
3.2.2 Analyse
Le deuxième sprint comporte les cas d'utilisations
suivants :
V' Gestion des élèves
V' Gestion des absences des élèves
V' Gestion des enseignants
V' Gestion des absences des enseignants
V' Gestion des cadres
V' Gestion des absences des cadres
V' Gestion des sanctions des élèves
V' Gestion des dettes
V' Gestion des protestations
V' Gestion des propositions
V' Gestion des cas de violences
3.2.2.1 Diagramme de cas d'utilisation du sprint
2
La figure 19 illustre le diagramme de cas d'utilisation global
pour le sprint 2:
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
Figure 19 Diagramme de cas d'utilisation globale du
sprint 2
3.2.2.2 Analyse de cas d'utilisation « Gérer
les enseignants ».
Dans la figure 20, nous allons expliquer le cas d'utilisation de
la gestion des enseignants, composé de l'ajout, la suppression, la mise
à jour et la consultation de la liste des enseignants. Ces
fonctionnalités nécessitent une authentification par
l'utilisateur (établissement).
47
Figure 20 Diagramme de cas d'utilisation «
Gérer les enseignants »
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
? La description textuelle de cas d'utilisation «
gérer les enseignants ».
Le tableau 8 représente la description textuelle de cas
d'utilisation « gérer les enseignants ».
Tableau 8 La description textuelle de cas
d'utilisation «gérer les enseignants»
Cas d'utilisation
|
«Gérer les enseignants».
|
Résumé
|
Après succès de l'authentification,
l'établissement gère la liste des enseignants.
|
Acteurs
|
L'établissement.
|
Pré condition
|
L'établissement a besoin de s'authentifier.
|
Post condition
|
La mise à jour de la base de données est
effectuée selon la tâche choisie.
|
Scénario principal
|
1. Le système affiche la page de gestion des
enseignants.
2. L'établissement choisit et valide la tâche
à effectuer.
3. Le système enregistre les informations et affiche le
message de retour.
|
Exception
|
Des erreurs peuvent être produites : contrôle de
saisie et utilisateur existent déjà.
|
3.2.2.3 Analyse de cas d'utilisation « Gérer
les sanctions des élèves ».
Dans la figure 21, nous allons expliquer le cas d'utilisation
de la gestion des sanctions des élèves qui permettra à
l'établissement d'ajouter les sanctions des élèves,
modifier, et consulter la liste des sanctions.
48
Figure 21 Diagramme de cas d'utilisation «
Gérer les sanctions des élèves »
49
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
? Description textuelle du cas d'utilisations «
gérer les sanctions des élèves ».
Le tableau 9 représente la description textuelle de cas
d'utilisation « gérer les sanctions des élèves
».
Tableau 9 La description textuelle de cas
d'utilisation «gérer les sanctions des
élèves»
Cas d'utilisation
|
«Gérer les sanctions des
élèves».
|
Résumé
|
Après succès de l'authentification,
l'établissement gère la liste des sanctions des
élèves.
|
Acteurs
|
L'établissement.
|
Pré condition
|
L'établissement a besoin de s'authentifier.
|
Post condition
|
La mise à jour de la base de données est
effectuée selon la tâche choisie.
|
Scénario principale
|
1. Le système affiche la page de gestion des sanctions
des élèves.
2. L'établissement choisit et valide la tâche
à effectuer.
3. Le système enregistre les informations et affiche le
message de retour.
|
Exception
|
Des erreurs peuvent être produites : contrôle de
saisie et utilisateur existent déjà.
|
3.2.3 Conception dynamique du deuxième
sprint.
Cette partie sera consacrée à une étude
détaillée de notre système. Pour cela, nous avons choisi
trois cas d'utilisation du sprint1 et sprint2 : l'authentification, la gestion
de l'utilisateur et la gestion enseignant.
3.2.3.1 Diagramme de séquences d'objet relatif au
cas d'utilisation «modifier l'enseignant »
La figure 22 illustre le diagramme de séquences relatives
au cas d'utilisation « modifier l'enseignant
» et les interactions entre l'établissement et le
système.
50
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
Figure 22 Diagramme de séquences d'objet
relatif au cas d'utilisation «modifier l'enseignant
»
3.2.3.2 Diagramme d'activité « modifier
l'enseignant ».
Après une demande de modification d'un enseignant par
l'établissement, le système lui affiche le formulaire de
modification pour qu'il puisse saisir ces données et confirmer la
modification au niveau de la base de données.
Figure 23 Diagramme d'activité « modifier
l'enseignant »
3.2.4 Représentation des interfaces de
l'application
Dans cette partie, nous allons présenter quelques
interfaces qui sont développées dans le sprint2.
51
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
3.2.4.1 Interface tableau de bord de
l'établissement
Dans cette partie, l'utilisateur peut ajouter toutes les
données relatives à l'établissement :
Figure 24 Interface tableau de bord de
l'établissement
3.2.4.2 Interface d'ajout d'un enseignant
Dans cette partie, l'utilisateur peut ajouter un enseignant :
Figure 25 Interface ajout d'un
enseignant
3.2.4.3 Interface de gestion des sanctions des
élèves.
Cet écran présente la liste des sanctions des
différents élèves.
52
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
Figure 26 Interface de gestion des sanctions des
élèves
3.3 Conclusion
Au cours de ce chapitre, nous avons terminé le premier et
le deuxième sprint de notre projet qui comporte les
fonctionnalités de l'administrateur et de l'établissement.
Le chapitre suivant sera consacré à
présenter le reste des sprints (sprint3, sprint 4 et sprint 5).
Mastère Professionnel : « Systèmes de
Télécommunications et Réseaux »
53
|