République Tunisienne

Ministère de l’enseignement supérieur et de la recherche scientifique

Université de Jendouba
Faculté des Sciences juridique économique et de Gestion de Jendouba

RAPPORT DE PROJET DE FIN D’ETUDES

En vue d’obtenir un diplôme
"Licence fondamentale en informatique de gestion (Business computing) "
spécialité : Business Information Systems

Application Web de digitalisation du

système de management de la qualité

Réalisé au sein de :
"Université de jendouba"

Réalisée par :Raja Khazri

Encadré par :[Link] Marzouki
Encadrant du stage :M. Rabii Tebai

L’année Universitaire :2023/2024

Remerciements

Je tiens à exprimer ma profonde gratitude envers toutes les personnes qui ont contribué
à la réalisation de ce projet de fin d’études.

Ce parcours académique n’aurait pas été le même sans le soutien et les conseils précieux
de nombreuses personnes.

Je tiens tout d’abord à remercier Mr Sofien Marzouki et Mr Rabie Tebai , mon supervi-
seur, pour leur guidance experte et leur soutien constant.

Leurs conseils éclairés et leur disponibilité ont été essentiels pour m’aider à comprendre
les tenants et aboutissants de ce projet.

Un grand merci à ma famille et à mes amis pour leur soutien indéfectible tout au long de
cette aventure académique.

Leurs encouragements et leur compréhension m’ont permis de surmonter les défis et d’at-
teindre mes objectifs.

Enfin, je tiens à exprimer ma reconnaissance envers l’ensemble du corps professoral et du

personnel de la Faculte des Sciences Juridiques Economiques Et Gestion de Jendouba
pour leur dévouement à l’excellence académique et leur engagement envers le succès des
étudiants.

Merci à tous ceux qui ont contribué de près ou de loin à la réalisation de ce projet.
Votre impact restera gravé dans mon parcours académique et professionnel.

i
Dédicace

Au nom de mon Créateur qui a facilité mes affaires et préservé mon destin,
je lui adresse toute ma louange et ma gratitude.

Louange à Allah par amour, reconnaissance et gratitude pour le commencement et la fin.

La dernière invocation sera : « Louange à Allah, Seigneur de l’univers ».

Ma carrière universitaire a atteint son terme après beaucoup de travail et d’efforts.

Aujourd’hui, je marque les derniers instants de mon projet de fin d’études avec détermina-
tion et engagement.

Je dédie ce succès d’abord à moi-même, et je suis reconnaissant envers tous ceux qui ont
contribué à mon parcours, même modestement.

Le chemin du projet a été parsemé d’obstacles, mais j’ai tenté de les surmonter avec fer-
meté grâce à Allah et à leur soutien.

Certains méritent notre gratitude, en premier lieu mes parents Maryem et Houcine leur
mérite est immense car leur présence est une clé du succès dans cette vie et dans l’au-delà.

Je remercie ceux qui m’ont encouragé et ont contribué sans attendre de contrepartie, ainsi
que mes sœurs et mon frère qui ont été partie prenante de ces victoires.

Je ne saurais exprimer suffisamment ma gratitude et mon appréciation envers mes prin-

cipaux superviseurs, ni oublier mes enseignants qui ont joué un rôle primordial en me sou-
tenant et en me fournissant des informations précieuses.

Je prie le Tout-Puissant de prolonger vos vies et de vous accorder le meilleur.

Je vous présente donc ma recherche."

ii
Table des matières

Remerciement i

Dédicace ii

Table des matières iii

Table des figures vi

Liste des tableaux viii

Introduction générale 1

1 Présentation du cadre du projet 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Université de Jendouba . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Organigramme de l’université . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 La critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Choix du modèle de développement . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Justification du choix de la méthode Scrum . . . . . . . . . . . . . . . . 5
1.5 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.1 Définition d’UML (Unified Modeling language) . . . . . . . . . . . . . 6
1.5.2 Objectifs de l’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3 Diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Cartographie et architecture de l’application . . . . . . . . . . . . . . . . . . . 8
1.6.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Sprint 0 : Planification de Projet 11

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Analyse et spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Les Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Les Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . 13
2.3 Pilotage du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

iii
0 TABLE DES MATIÈRES

2.3.1 Organigramme des taches . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 Diagramme de Gant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Équipe de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Environnement technologique . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Sprint 1 : Les cas de priorité 1 21

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Backlog de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Diagramme des cas d’utilisation de sprint 1 . . . . . . . . . . . . . . . . 22
3.2.3 Raffinement et description de cas d’utilisation globale du sprint 1 . . . 22
3.3 Conception statique de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Conception dynamique du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.1 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.2 Diagrammes d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.2 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.3 Interface Ajouter un utilisateur . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.4 Interface des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.5 Interface de Modifier utilisateurs . . . . . . . . . . . . . . . . . . . . . . 37
3.5.6 Interface de suppression utilisateur . . . . . . . . . . . . . . . . . . . . 38
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Sprint 2 : Les cas de priorité 2 39

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Diagramme des cas d’utilisation du deuxième sprint . . . . . . . . . . 40
4.2.3 Raffinement et description de cas d’utilisation globale du sprint 2 . . 40
4.2.4 Raffinement du modèle du cas d’utilisation «Affectuer les pilotes» . . 41
4.2.5 Raffinement du modèle du cas d’utilisation «Gérer documents» . . . . 42
4.3 Conception statique de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1 Diagramme des classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.3 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Conception dynamique du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.1 Diagramme de séquence de cas «Gérer processus» . . . . . . . . . . . . 46
4.4.2 Diagramme de séquence de cas «Affecter Pilotes» . . . . . . . . . . . . 49
4.4.3 Diagramme de séquence de cas «Gérer documents» . . . . . . . . . . . 50
4.5 Diagrammes d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.1 Diagramme d’activité «Gérer processus» . . . . . . . . . . . . . . . . . 52
4.5.2 Diagramme d’activité « Affecter pilotes» . . . . . . . . . . . . . . . . . 55

iv
0 TABLE DES MATIÈRES

4.5.3 Diagramme d’activité «Gérer documents» . . . . . . . . . . . . . . . . 56

4.6 Interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6.1 Interface ajouter un processus . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6.2 Interface Liste des processus . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6.3 Interface modifier un processus . . . . . . . . . . . . . . . . . . . . . . . 58
4.6.4 Interface supprimer un processus . . . . . . . . . . . . . . . . . . . . . 58
4.6.5 Interface Affecter les pilotes . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.6 Interface Ajouter documents . . . . . . . . . . . . . . . . . . . . . . . . 60
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Sprint 3 : Les cas de priorité 3 61

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.1 Backlog de sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.2 Diagramme des cas d’utilisation du troisième sprint . . . . . . . . . . . 62
5.2.3 Raffinement et description de cas d’utilisation globale du sprint 3 . . . 62
5.3 Conception statique de sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Conception dynamique du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4.1 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4.2 Diagrammes d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5.1 L’interface Ajouter un indicateur . . . . . . . . . . . . . . . . . . . . . . 75
5.5.2 L’interface de remplir un indicateur . . . . . . . . . . . . . . . . . . . . 75
5.5.3 L’interface Téléchargement du document . . . . . . . . . . . . . . . . . 76
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6 Sprint 4 :Les cas de priorité 4 77

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.1 Backlog de sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.2 Diagramme des cas d’utilisation quatrième sprint . . . . . . . . . . . . 78
6.2.3 Raffinement et description de cas d’utilisation globale du sprint 4 . . 78
6.3 Conception statique de sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.3.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.3.2 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4 Conception dynamique du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4.1 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4.2 Diagrammes d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.5 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.5.1 L’interface de Consulter les statisques . . . . . . . . . . . . . . . . . . . 84
6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.7 Diagramme de classe globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Conclusion generale 86

Bibliographie 87

v
Table des figures

1.1 Organigramme de l’université . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Méthode en cascade vs Méthode agile . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Logo UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 3 Tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Organigramme des taches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Diagramme de Gant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Diagramme de Gant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 WampServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8 Node js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.10 [Link] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.11 Gantproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.12 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.13 Logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Cas d’utilisation du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Raffinement du modèle du cas d’utilisation «S’authentifier» . . . . . . . . . . 22
3.3 Diagramme de cas d’utilisation «Gérer les utilisateurs» . . . . . . . . . . . . . 23
3.4 Diagramme de Classe Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Didramme de séquence «S’authentifier» . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Didramme de séquence «Ajouter un utilisateur» . . . . . . . . . . . . . . . . . 29
3.7 Diagramme de séquence «Modifier un utilisateur» . . . . . . . . . . . . . . . . 30
3.8 Diagramme de séquence «Supprimer un utilisateur» . . . . . . . . . . . . . . . 31
3.9 Diagramme d’activité « s’authentifier » . . . . . . . . . . . . . . . . . . . . . . 32
3.10 Diagramme d’activité «Ajouter un utilisateur» . . . . . . . . . . . . . . . . . . 33
3.11 Diagramme d’activité «Modifier un utilisateur» . . . . . . . . . . . . . . . . . 34
3.12 Diagramme d’activité «Supprimer un utilisateur» . . . . . . . . . . . . . . . . 35
3.13 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.14 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.15 Interface Ajouter un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.16 Interface des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.17 Interface de Modifier un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.18 Interface de suppression un utilisateur . . . . . . . . . . . . . . . . . . . . . . . 38

4.1 Cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

vi
0 TABLE DES FIGURES

4.2 Raffinement du modèle du cas d’utilisation «Gérer les processus» . . . . . . . 40

4.3 Raffinement du modèle du cas d’utilisation «Affecter pilotes» . . . . . . . . . 41
4.4 Raffinement du modèle du cas d’utilisation «Gérer documents» . . . . . . . . 42
4.5 Diagramme de classe de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6 Diagramme de séquence de cas «Ajouter un processus» . . . . . . . . . . . . . 47
4.7 Diagramme de séquence « Modifier un processus» . . . . . . . . . . . . . . . . 48
4.8 Diagramme de séquence « Supprimer un processus» . . . . . . . . . . . . . . . 49
4.9 Diagramme de séquence de cas «Affecter un pilote» . . . . . . . . . . . . . . . 50
4.10 Diagramme de séquence de cas «Ajouter un document» . . . . . . . . . . . . . 51
4.11 Diagramme de séquence de cas «Supprimer un document» . . . . . . . . . . . 52
4.12 Diagramme d’activité «Ajouter un processus» . . . . . . . . . . . . . . . . . . 53
4.13 Diagramme d’activité «Modifier un processus» . . . . . . . . . . . . . . . . . . 54
4.14 Diagramme d’activité «supprimer un processus» . . . . . . . . . . . . . . . . . 55
4.15 Diagramme d’activité «affecter un pilote» . . . . . . . . . . . . . . . . . . . . . 55
4.16 Diagramme d’activité «Ajouter un document» . . . . . . . . . . . . . . . . . . 56
4.17 Diagramme d’activité «Supprimer un document» . . . . . . . . . . . . . . . . 57
4.18 Interface ajouter un processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.19 Interface Liste des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.20 Interface modifier un processus . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.21 Interface supprimer un processus . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.22 Interface Affecter les pilotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.23 Interface Ajouter documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1 Diagramme des cas d’utilisation du sprint 3 . . . . . . . . . . . . . . . . . . . . 62

5.2 Raffinement du modèle du cas d’utilisation «Gérer indicateurs» . . . . . . . . 62
5.3 Raffinement du modèle du cas d’utilisation «Remplir indicateurs» . . . . . . . 63
5.4 Raffinement du modèle du cas d’utilisation «Consulter documents» . . . . . . 64
5.5 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6 Diagrammes de séquence «Ajouter indicateurs» . . . . . . . . . . . . . . . . . 67
5.7 Diagrammes de séquence «Modifier indicateurs» . . . . . . . . . . . . . . . . . 68
5.8 Diagrammes de séquence «Supprimer indicateurs» . . . . . . . . . . . . . . . 69
5.9 Diagramme de séquence « Consulter l’historique documentaire» . . . . . . . . 70
5.10 Diagramme d’activité «Ajouter un indicateur» . . . . . . . . . . . . . . . . . . 71
5.11 Diagramme d’activité «Modifier un indicateur» . . . . . . . . . . . . . . . . . 72
5.12 Diagramme d’activité «Supprimer un indicateur» . . . . . . . . . . . . . . . . 73
5.13 Diagramme d’activité «consulter l’historique documentaire» . . . . . . . . . . 73
5.14 Diagramme d’activité «Remplir un indicateur» . . . . . . . . . . . . . . . . . . 74
5.15 L’interface «Ajouter un indicateur» . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.16 L’interface «Remplir un indicateur» . . . . . . . . . . . . . . . . . . . . . . . . 75
5.17 Téléchargement du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.1 Diagramme des cas d’utilisation du sprint 4 . . . . . . . . . . . . . . . . . . . . 78

6.2 Raffinement du modèle du cas d’utilisation «Consulter statisques» . . . . . . 78
6.3 Raffinement du modèle du cas d’utilisation «Consulter notifications» . . . . . 79
6.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.5 Diagrammes de séquence «Consulter statistiques» . . . . . . . . . . . . . . . . 81
6.6 Diagramme de séquence « Consulter notifications » . . . . . . . . . . . . . . . 82
6.7 Diagramme d’activité «Consulter statistiques » . . . . . . . . . . . . . . . . . . 83
6.8 Diagramme d’activité «Consulter notifications» . . . . . . . . . . . . . . . . . 83
6.9 L’interface «dashboard» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.10 L’interface «Diagramme de classe globale» . . . . . . . . . . . . . . . . . . . . 85

vii
Liste des tableaux

1.1 Méthodes Scrum VS Méthode classiques . . . . . . . . . . . . . . . . . . . . . 6

2.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Backlog de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Description textuelle de cas d’utilisation «s’authentifier». . . . . . . . . . . . . 23
3.3 Description textuelle de l’opération «Ajouter un utilisateur». . . . . . . . . . . 24
3.4 Description textuelle de l’opération «modifier un utilisateur». . . . . . . . . . 24
3.5 Description textuelle de l’opération «supprimier un utilisateur». . . . . . . . 25
3.6 Dictionnaire de données : Administrateur . . . . . . . . . . . . . . . . . . . . . 26
3.7 Dictionnaire de données : Utilisateur . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Dictionnaire de données : RMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9 Dictionnaire de données :Pilote de Processus . . . . . . . . . . . . . . . . . . . 27

4.1 Backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Description textuelle de l’opération «Gérer les processus» . . . . . . . . . . . . 41
4.3 Description textuelle de «Affecter pilotes». . . . . . . . . . . . . . . . . . . . . 42
4.4 Description textuelle de l’opération «Gérer documents» . . . . . . . . . . . . . 43
4.5 Dictionnaire de données : Utilisateur . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Dictionnaire de données : RMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.7 Dictionnaire de données : Pilote de processus . . . . . . . . . . . . . . . . . . . 45
4.8 Dictionnaire de données : Pilote de processus . . . . . . . . . . . . . . . . . . . 46
4.9 Dictionnaire de données : processus . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 Backlog de sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2 Description textuelle «Gérer indicateurs» . . . . . . . . . . . . . . . . . . . . . 63
5.3 Description textuelle de «Remplir indicateur». . . . . . . . . . . . . . . . . . . 64
5.4 Description textuelle de «Consulter l’historique documentaire». . . . . . . . . 64

6.1 Backlog de sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.2 Description textuelle de «Consulter statistiques». . . . . . . . . . . . . . . . . 79
6.3 Description textuelle de «Gérer notifications». . . . . . . . . . . . . . . . . . . 79

viii
Introduction générale

Dans le cadre des réformes de modernisation du gouvernement tunisien, l’objectif est de

dématérialiser les procédures administratives et d’élargir les services en ligne en introdui-
sant le concept d’identité numérique.

Concrètement, la transformation numérique vise à simplifier et accélérer les procédures ad-

ministratives tout en renforçant leur fiabilité.

En automatisant les procédures administratives et en numérisant les services publics, le gou-

vernement cherche à réduire les risques d’erreurs et d’inefficacités.

De plus, l’automatisation et la numérisation des services publics les rendent plus agiles,
efficaces et intelligents, soulignant ainsi l’importance de la numérisation des procédures ad-
ministratives.

Dans ce contexte, ce projet de fin d’études s’est concentré sur la contribution au dévelop-
pement d’une application web dédiée à la surveillance du système de management de la
qualité.

L’objectif de cette application est de simplifier et de centraliser les données, automatiser

les tâches répétitives, et faciliter la surveillance du système de management de la qualité
ainsi que la génération de rapports.

Elle offrira également une interface conviviale aux utilisateurs, gérée en ligne pour l’Uni-
versité de Jendouba.

Ce manuscrit est structuré en six chapitres. le première chapitre présente le cadre général
du projet, y compris la recherche préliminaire, la présentation de l’organisme d’accueil , les
solutions mises en œuvre et le processus de développement utilisé.

Le deuxième chapitre contient la planification du projet .

Il recense également les parties prenantes et expose leurs besoins fonctionnels et techniques,
ainsi que l’environnement de developpement fournissant ainsi un soutien aux chapitres sui-
vants des sprints 1, 2, 3 et 4 qui décrivent les différentes phases d’analyse, de conception et
de réalisation de chaque sprint.

Nous clôturons ce rapport par une conclusion générale et quelques perspectives futures
qui peuvent ouvrir des horizons pour d’éventuelles améliorations ou maintenances de l’ap-
plication que nous avons mise en place.

1
Chapitre 1

Présentation du cadre du projet

1.1 Introduction
Dans ce projet dans le premier chapitre, où nous explorerons et améliorerons les pro-
cessus existants. Découvrez l’organigramme de l’université Jendouba, suivi d’une étude cri-
tique et de solutions innovantes. Notre choix méthodologique, Scrum, sera justifié, et l’UML
guidera la modélisation. Enfin, plongez dans l’architecture de l’application pour un aperçu
clair du projet à venir. Une aventure prometteuse vers l’efficacité et l’innovation.

1.2 Présentation de l’organisme d’accueil

1.2.1 Université de Jendouba
L’Université de Jendouba a été créée par le décret numéro 1662-2003 du 4 août 2003,
concrétisant ainsi la politique de l’État dans sa volonté de décentraliser le savoir et la tech-
nologie, et de promouvoir le rôle vital de l’université dans la région du Nord-Ouest regrou-
pant quatre gouvernorats (Jendouba, Béja, Kef et Siliana).

Depuis sa création, l’Université de Jendouba a connu un développement significatif tant

en termes du nombre d’institutions créées que du nombre d’étudiants, d’enseignants et de
personnel administratif.

L’Université de Jendouba compte 14 établissements académiques (1 faculté, 2 écoles et

11 instituts), dont 5 sont en cotutelle : 3 avec le ministère de l’Agriculture, 1 avec le ministère
de la Santé et 1 avec le ministère de la Jeunesse et des Sports.[1].
— Faculté des Sciences Juridiques, Économiques et de Gestion de Jendouba (FSJEGJ)
— Institut Supérieur des Sciences Humaines de Jendouba (ISSHJ)
— Institut Sylvo- Pastoral de Tabarka (ISPT)
— Institut Supérieur des Langues Appliquées et d’Informatique de Béja (ISLAIB)
— Institut Supérieur de Biotechnologie de Béja (ISBB)
— École Supérieure des Ingénieurs de Medjez El Bab (ESIMB)
— Institut Supérieur des Études Appliquées en Humanités du Kef (ISEAHK)
— Institut Supérieur de Musique et de Théâtre du Kef (ISMTK)
— Institut Supérieur de l’Informatique du Kef (ISIK)
— Institut national des technologies et des sciences du Kef (INTEK)

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

— Institut Supérieur du Sport et de l’Éducation Physique du Kef (ISSEPK)

— École Supérieure d’Agriculture du Kef (ESAK)
— Institut Supérieur des Sciences Infirmières du Kef (ISSIK)
— Institut Supérieur des Arts et Métiers de Siliana (ISAMS)

1.2.2 Organigramme de l’université

F IGURE 1.1 – Organigramme de l’université

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

1.3 Présentation du projet

1.3.1 Étude de l’existant
J’ai effectué mon stage au rectorat de Jendouba, plus précisément dans le service du
système de management de la qualité. Au cours de ce stage, nous avons remarqué que :
— La surveillance du système de management de la qualité est effectuée de manière tra-
ditionnelle.
— La surveillance du système de management de la qualité repose sur des documents
papier.
— L’affectation des pilotes à chaque processus est réalisée de manière manuelle.
— Les documents et les indicateurs liés à chaque processus sont classés dans un ordre
spécifique pour garantir qu’aucun document n’est oublié.
— La comparaison des indicateurs avec leur seuil et la sortie des résultats pour prendre
des décisions se fait de manière traditionnelle sur papier.
— IL y avait des problèmes de sécurité au travail, car plusieurs personnes pouvaient voir
chaque processus.

1.3.2 La critique de l’existant

L’université de Jendouba a révélé plusieurs défis dans la surveillance du système de
management qualité :
— L’utilisation de méthodes traditionnelles est devenue obsolète et inefficace.
— Des retards, des pertes et des dommages sont constatés.
— Le suivi systématique des indicateurs de performance de chaque processus est com-
plexe.
— L’attribution efficace des pilotes à chaque processus est complexe.
— L’organisation et la consultation de l’historique documentaire des processus sont Pro-
blématiques.

1.3.3 Solution proposée

De ce fait à développer une application web pour faciliter la surveillance du système de
management qualité au sein de l’université de Jendouba.
Cette application sera conçue pour gérer plusieurs processus, chacun ayant ses propres do-
cuments et indicateurs spécifiques.
Grâce à notre application, les responsables du management qualité pourront facilement af-
fecter les pilotes aux différents processus et suivre de près les indicateurs de performance.
De plus, ils auront accès à un historique documentaire détaillé pour chaque processus.
Les documents étaient physiques, mais ils sont devenus numériques dans l’application.
Le travail est devenu plus sécurisé, ce qui signifie que chaque processus est désormais vi-
sible uniquement par la personne responsable.

1.4 Choix du modèle de développement

Avant de mettre en œuvre le choix de la méthodologie pour le développement de notre
projet, nous allons énumérer et établir une description des différentes méthodologies exis-
tantes dans les sections suivantes :

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

1.4.1 Méthode Scrum

La méthode Scrum est une méthode agile de gestion de projets informatiques qui facilite
la communication pour faciliter un ajustement opportun de la direction : c’est désormais la
méthode privilégiée. Pour les méthodes dites « agiles ». Forte de son succès en informatique,
elle Désormais déployé dans l’entreprise en tant que nouvelle organisation opérationnelle
"Mode Projet" Premièrement, il permet une meilleure collaboration et communication entre
les différentes équipes travaillant sur les projets de l’entreprise. Deuxièmement, cette ap-
proche convient au travail de groupe, aux réunions quotidiennes et au suivi continu du pro-
jet. Cela facilite donc la gestion des changements fréquents. De plus, fournir des produits de
haute qualité répondra aux besoins et aux attentes des clients. Le projet sera réalisé indivi-
duellement en adaptant Scrum à nos besoins spécifiques, pour lesquels nous considérerons
les pratiques suivantes :[2] :
1. près la création du backlog produit, extraire les fonctionnalités à développer.
2. Diviser le projet en sprints.
3. Décomposer chaque sprint en histoires utilisateur.
4. Tenir une réunion en début de semaine pour discuter des tâches achevées, des défis
rencontrés et des tâches à planifier.

F IGURE 1.2 – Méthode Scrum

1.4.2 Justification du choix de la méthode Scrum

Afin de gérer correctement notre projet et de garantir son bon déroulement, nous avons
choisi d’utiliser la méthode SCRUM. Ce choix sera justifié dans le tableau suivant, qui pré-
sente une comparaison entre les deux approches célèbres, classique et agile.

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

F IGURE 1.3 – Méthode en cascade vs Méthode agile

Caractéristiques
Méthodes Scrum Méthode classiquess
Approche Agile, itérative et incrémentale. Prédictive, linéaire et séquentielle
Phases distinctes et séquentielles (ex :
Structure Cadre de travail flexible et adaptatif
Waterfall)
Livraison incrémentale de fonction-
Livraison Livraison finale à la fin du projet
nalités à chaque sprint
Faible flexibilité pour les change-
Flexibilité Adaptabilité élevée aux changements
ments en cours de route
Informelle, transparente et collabora-
Communication Formalisée et hiérarchique
tive
RAuto-organisée, multidisciplinaire
Équipe Spécialisée et hiérarchisée
et collaborative
Gestion de pro- Basée sur la collaboration, l’adapta- Basée sur la planification et le suivi de
jet tion et la communication tâches définies
Risques gérés de manière continue et Risques identifiés en amont et gérés
Risques
flexible de manière rigide
Implication Collaboration étroite tout au long du Implication principalement en début
client projet et fin de projet
Flexible, possibilité d’ajustement à Rigide, peu de possibilité d’ajuste-
Cycle de vie
chaque sprint ment en cours de route
TABLE 1.1: Méthodes Scrum VS Méthode classiques

1.5 Langage de modélisation

1.5.1 Définition d’UML (Unified Modeling language)
Le Langage de Modélisation Unifié (UML) a été conçu pour être un langage de modéli-
sation visuelle commun, riche sur le plan sémantique et syntaxique, destiné à l’architecture,
à la conception et à la mise en œuvre de systèmes logiciels complexes tant au niveau de leur
structure que de leur comportement. L’UML n’est pas un langage de programmation, mais

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

il existe des outils qui peuvent être utilisés pour générer du code dans plusieurs langues
à partir de diagrammes UML. L’UML a une relation directe avec l’analyse et la conception
orientées objet.[3].

F IGURE 1.4 – Logo UML

1.5.2 Objectifs de l’UML

L’objectif principal du diagramme UML (Unified Modeling Language) est de fournir une
représentation visuelle des différents aspects d’un système logiciel. Voici quelques mots-clés
qui résument les objectifs du diagramme UML :
— Modélisation : Représenter visuellement les éléments clés d’un système logiciel.
— Abstraction : Simplifier la complexité en utilisant des modèles pour décrire le système
à un niveau d’abstraction approprié.
— Communication : Fournir un langage commun entre les membres de l’équipe de dé-
veloppement et les parties prenantes pour comprendre et discuter de la conception.
— Documentation : Servir de support visuel pour documenter l’architecture, les relations
et les comportements du système.
— Analyse : Faciliter l’analyse et la compréhension des différents aspects du système, y
compris les classes, les objets, les relations, les comportements, etc.
— Conception : Aider à concevoir et organiser la structure du système en identifiant les
classes, les interfaces, les relations et les collaborations.
— Évolution : Permettre d’anticiper les modifications futures en fournissant une repré-
sentation flexible et adaptable du système.
— Normalisation : Fournir une notation normalisée et universellement acceptée pour la
modélisation des systèmes logiciels.

1.5.3 Diagrammes UML

Un diagramme UML est un diagramme basé sur l’UML (Unified Modeling Language)
ayant pour objectif de représenter visuellement un système avec ses acteurs principaux,
rôles, actions, artefacts ou classes, dans le but de mieux comprendre, modifier, maintenir ou
documenter des informations sur le système.
— Diagramme de cas d’utilisation

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

— Diagramme de séquence
— Diagramme d’activité
— Diagramme de composants
— Diagramme de déploiement
— Diagramme d’états-transitions
— Diagramme de communication
— Diagramme de packages
— Diagramme d’objets
— Diagramme de structure composite
— Diagramme de timing (chronologie)
— Diagramme d’aperçu d’interaction
— Diagramme de profil

1.6 Cartographie et architecture de l’application

Cette section est consacrée à l’initialisation du projet et à la mise en place de l’environ-
nement de développement. Cela inclut l’architecture, ainsi que l’environnement matériel et
logiciel.

1.6.1 Architecture logique

L’architecture 3-tiers appelée aussi architecture à trois niveaux ou architecture à trois
couches basées sur l’environnement client-serveur, est composée de trois éléments, ou plus
précisément dans ce cadre-là de trois couches. En effet dans ce contexte, et dans la philo-
sophie qui guidé l’élaboration de cette architecture, il est plus adéquat de parler de couche
fonctionnelle où à chacune d’elle est attachée un élément/entité logique. Donc dans le mo-
dèle 3-tiers if faut distinguer trois couches/élément :
— La couche présentation (ou affichage si l’on souhaite) associée au client : Un client,
c’est-à-dire l’ordinateur demandeur de ressources, équipe d’une interface utilisateur
chargée de la présentation.
— La couche fonctionnelle liée au serveur, comprend le serveur d’applications ou midd-
leware ou encore serveur intermédiaire, chargé de fournir la ressource mais faisant
appel à un autre serveur.
— La couche de données liée au serveur de base de données. Fournissant au serveur
d’application les dont il a besoin.

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

F IGURE 1.5 – 3 Tier architecture

1.6.2 Architecture logicielle

La définition de l’architecture logicielle d’un système consiste à décrire son organisa-
tion générale et sa décomposition en sous-systèmes ou composants. Il s’agit également de
déterminer les interfaces entre les sous-systèmes ou composants, ainsi que les interactions
et les flux de contrôle entre ces sous-systèmes. Dans le cadre de notre projet, nous avons
choisi l’architecture MVC (Modèle/Vue/Contrôleur). L’architecture MVC est un motif de
conception très courant pour la création de sites web. Ce motif de conception est une solu-
tion éprouvée et reconnue pour séparer l’affichage de l’information et des actions de l’accès
aux données. [4]

— Modèle : Le modèle représente les données et la logique métier de l’application. Dans

Angular, le modèle est généralement implémenté à l’aide de services et de modèles de
données.
— Vue : La vue est responsable du rendu de l’interface utilisateur et de l’affichage des
données à l’utilisateur. Dans Angular, la vue est créée à l’aide de modèles HTML et
améliorée avec des directives et des liaisons de données.
— Contrôleur : Le contrôleur gère l’interaction entre le modèle et la vue. Dans Angular,
le contrôleur est implémenté sous forme de composants qui encapsulent la logique et
le comportement d’une partie spécifique de l’interface utilisateur.

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

F IGURE 1.6 – Modèle MVC

1.7 Conclusion
En conclusion, ce chapitre établit une base solide en présentant l’organisme d’accueil, en
décrivant le projet, en justifiant le choix de la méthode Scrum, en introduisant le langage
de modélisation UML, et en exposant l’architecture de l’application. Ces éléments posent
les fondations nécessaires pour la compréhension et la mise en œuvre du projet au sein de
l’Université de Jendouba.

10
Chapitre 2

Sprint 0 : Planification de Projet

2.1 Introduction
Dans ce deuxième chapitre, nous explorons l’analyse des besoins et la gestion de projet.
Nous identifions les acteurs, spécifions les besoins fonctionnels et non fonctionnels, et pré-
sentons un diagramme de cas d’utilisation global. Le pilotage du projet est ensuite abordé
à travers l’organigramme des tâches, le diagramme de Gantt, l’équipe projet, et le backlog
du produit. Enfin, nous examinons l’environnement de développement, incluant les aspects
matériels et techniques essentiels à la réalisation de projet.

2.2 Analyse et spécification des besoins

Un acteur représente l’abstraction d’un rôle joué par des entités externes qui interagissent
directement avec le système étudié. Dans cette section, nous dresserons la liste des acteurs
susceptibles d’interagir avec le système :

2.2.1 Identification des acteurs

Un acteur représente l’abstraction d’un rôle joué par des entités externes qui interagissent
directement avec le système étudié. Dans cette section, nous énumérerons les acteurs sus-
ceptibles d’interagir avec le système.
— Administrateur : Cet acteur est responsable de la gestion des utilisateurs de l’appli-
cation. Il peut avoir des autorisations pour ajouter, supprimer ou modifier des utilisa-
teurs, et affecter le rôle de chaque utilisateur.
— Responsable management qualité : Le responsable du management qualité est au
cœur de l’application. Cette personne utilise l’application pour gérer les processus, af-
fecter les pilotes de processus, gérer les documents et les indicateurs, ainsi que pour
consulter les statistiques afin de surveiller les indicateurs de chaque processus de l’uni-
versité.
— Pilote de processus : Utilisent l’application pour remplir les indicateurs et consulter
l’historique des documents associés à leur processus.

11
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

2.2.2 Les Besoins fonctionnels

1. Administrateur :
- Gérer utilisateurs
— Permet à l’administrateur d’ajouter, modifier ou supprimer un utilisateur.
2. Responsable Management Qualité (RMQ) :
- Gérer les processus
— Permet au RMQ de créer, modifier ou supprimer des processus .
- Gérer les documents
— Permet au RMQ de gérer les documents relative les processus, y compris l’ajout
et la suppression de documents.
-Affecter les pilotes de processus
— Permet au RMQ d’assigner des pilotes spécifiques à chaque processus.
- Gérer les indicateurs
— Permet au RMQ de ajouter, modifier et supprimer des indicateurs .
- Consulter les statistiques
— Consulter les statistiques afin de surveiller les indicateurs de chaque processus.
3. Pilote de processus :
- Remplir les indicateurs
— Permettez au pilote de processus de remlir les indicateurs associés à son
processus.
- Consulter l’historique des documents
— Permet au pilote de processus de consulter l’historique des documents associés à
son processus.
4. Systeme :
— Il a la capacité d’envoyer des notifications

2.2.3 Les Besoins non fonctionnels

Pour réussir dans notre tâche, l’application doit vérifier certaines propriétés et tenir
compte de certaines contraintes et exigences.
— Interface Riche : L’interface de l’application doit comporter toutes les fonctionnalités
d’une interface client riche, incluant la gestion de la synchronisation entre les vues, la
gestion des menus, et la gestion des notifications.
— Utilisabilité : Afin de réussir dans notre tâche, l’application doit vérifier certaines pro-
priétés et tenir compte de contraintes et exigences spécifiques.
— Ergonomie : L’utilisation de l’application doit être facile, claire, et ne nécessiter aucune
connaissance spécialisée en informatique.
— Fiabilité : L’application doit fonctionner même dans des conditions inattendues.
— Sécurité : L’application doit fournir un espace sécurisé pour ses utilisateurs en assurant
un processus d’authentification rigoureux.
— Performance : L’application doit être efficace et optimisée, réagissant avec un délai
précis indépendamment des actions de l’utilisateur.
— Accessibilité : L’application devrait être accessible aux utilisateurs en situation de han-
dicap, respectant les normes d’accessibilité telles que les WCAG (Web Content Acces-
sibility Guidelines).

12
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

2.2.4 Diagramme de cas d’utilisation global

F IGURE 2.1 – Diagramme de cas d’utilisation global

13
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

2.3 Pilotage du projet

2.3.1 Organigramme des taches

F IGURE 2.2 – Organigramme des taches

2.3.2 Diagramme de Gant

F IGURE 2.3 – Diagramme de Gant

14
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

F IGURE 2.4 – Diagramme de Gant

2.3.3 Équipe de projet

— Développeur
Le développeur est un technicien chargé de la réalisation d’un système ou d’une appli-
cation : site web, application mobile, logiciel embarqué, jeu vidéo, distributeur auto-
matique de billets, etc. Durant la conception d’un projet, on exprime les besoins fonc-
tionnels, on détaille ce qu’il doit afficher, ce qui doit se produire.[5].
— Product owner
A product owner is a role on a Scrum team that is responsible for the project’s outcome.
The product owner seeks to maximize a product’s value by managing and optimizing
the product backlog. Scrum is an Agile software development framework that enables
a team to communicate and self-organize[5].
— Scrum Master
Le Scrum Master est le rôle au sein de l’équipe responsable de veiller à ce que l’équipe
adopte les valeurs et les principes agiles, ainsi que de suivre les processus et les pra-
tiques convenus par l’équipe. Les responsabilités de ce rôle comprennent :
éliminer les obstacles, établir un environnement où l’équipe peut être efficace.[5].

— Nom du projet :Application Web de digitalisation du système de management de la

qualité
— Product owner : M. Rabii Tebai
— Scrum Master :M. Sofien Marzouki
— Membre de l’équipe :Raja khazri

15
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

2.3.4 Backlog du produit

backlog produit est une liste priorisée de fonctionnalités, d’améliorations et de correc-
tions qui doivent être développées et mises en œuvre dans un produit.

ID
ID Fonctionnalité User User Story Priorité
Story
En tant qu’administrateur, je peux
1 Authentification 1.1 1
me connecter à l’application
En tant qu’utilisateur, je peux me
1.2 1
connecter à l’application
En tant qu’administrateur, je peux
2 Gérer utilisateur 2.1 1
consulter la liste des utilisateurs
En tant qu’administrateur, je peux
2.2 1
ajouter un utilisateur
En tant qu’administrateur, je peux
2.3 1
modifier un utilisateur
En tant qu’administrateur, je peux
2.4 1
supprimer un utilisateur
En tant queResponsable Manage-
Consulter statis- ment Qualité, je peux Consulter les
3 3.1 4
tiques statistiques afin de surveiller les indi-
cateurs de chaque processus.
En tant que Responsable Manage-
4 Gérer processus 4.1 ment Qualité, je peux gérer les pro- 2
cessus .
En tant queResponsable Manage-
5 Gérer documents 5.1 ment Qualité, je peux ajouter, consul- 2
ter et supprimer des documents.
En tant que Responsable Manage-
6 Affecter pilotes 6.1 ment Qualité , je peux Affecter des pi- 2
lotes de processus .
En tant que Responsable Manage-
7 Gérer indicateurs 7.1 ment Qualité, je peux gérer les indi- 3
cateurs .
En tant que Pilote de processus, je
8 Remplir indicateurs 8.1 peux remplir les indicateurs associés 3
à mon processus.
En tant que pilote de processus, je
Consulter l’histo-
9 9.1 peux consulter l’historique des docu- 3
rique documentaire
ments liés à mon processus.
En tant que Systéme, je peux gérer les
10 Gérer notifications 10 4
notifications
TABLE 2.1: Backlog du produit

16
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

2.4 Environnement de développement

2.4.1 Environnement matériel
Le projet a été développé sur une machine ayant les caractéristiques décrites dans le ta-
bleau ci-dessous :

Composants Caractéristiques
Marque Lenovo
Processeur Intel(R) Celeron(R) N4020 CPU @ 1.10 GHz
Système d’exploitation Windows 10
RAM 4 GB
Carte graphique Intel(R) graphics

2.4.2 Environnement technologique

[Link] WampServer
WampServer est l’un des serveurs web multiplateformes largement utilisés qui permet
aux développeurs de créer et de tester leurs programmes sur un serveur web local. Il a été
développé par les Apache Friends, et son code source natif peut être révisé ou modifié par
le public. Il se compose du serveur HTTP Apache, de MariaDB et d’un interpréteur pour
différents langages de programmation tels que PHP et Perl.[6].

F IGURE 2.5 – WampServer

[Link] Visual Studio Code

Visual Studio Code est un éditeur de code source léger mais puissant qui s’exécute sur
votre bureau et est disponible pour Windows, macOS et Linux. Il dispose d’une prise en
charge intégrée pour JavaScript, TypeScript et [Link], et possède un écosystème riche en
extensions pour d’autres langages et environnements d’exécution (comme C++, C, Java, Py-
thon, PHP, .NET).[7].

F IGURE 2.6 – Visual Studio Code

17
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

[Link] Angular
Angular est un framework client open source basé sur TypeScript et co-dirigé par l’équipe
du projet Angular chez Google ainsi que par une communauté de particuliers et d’entre-
prises.
[8].

F IGURE 2.7 – Angular

[Link] Node js
[Link] est une plateforme logicielle libre en JavaScript, orientée vers des applications ré-
seau fortement concurrentes et basées sur des événements, devant être capables de s’adapter
à des échelles importantes.[9].

F IGURE 2.8 – Node js

[Link] Overleaf
Overleaf est une plateforme en ligne gratuite permettant de modifier du texte en LATEX
sans nécessiter de téléchargement d’application. C’est une manière facile et professionnelle
de créer un excellent rapport.[10].

F IGURE 2.9 – Overleaf

[Link] [Link]
[Link] est un logiciel de diagramme en ligne gratuit pour créer des organigrammes,
des diagrammes de processus, des schémas organisationnels, des diagrammes UML, des
diagrammes ER et des diagrammes de réseau.[11]

18
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

F IGURE 2.10 – [Link]

[Link] Gantproject
GanttProject est un logiciel de gestion de projet dont la principale fonctionnalité est la
création de plannings à l’aide de diagrammes de Gantt.[12]

F IGURE 2.11 – Gantproject

[Link] MySQL :
MySQL : est un système de gestion de base de données. Son rôle est de stocker les don-
nées, sous forme de tables, et de permettre la manipulation de ces données à travers le
langage de requête SQL. Le SQL dans "MySQL" signifie "Structured Query Language" le
langage standard pour les traitements de bases de données[16]

F IGURE 2.12 – MySQL

19
2 CHAPITRE 2. SPRINT 0 : PLANIFICATION DE PROJET

[Link] Postman
Postman est une plateforme API pour la création et l’utilisation des APIs. Postman sim-
plifie chaque étape du cycle de vie des API et rationalise la collaboration pour que vous
puissiez créer de meilleures APIs - plus rapidement.[17]

F IGURE 2.13 – Logo Postman

2.5 Conclusion
Dans ce chapitre, nous avons consacré du temps à l’identification des besoins fonction-
nels et non fonctionnels, établissant ainsi les bases de notre projet. La création du backlog
produit et la planification des sprints nous ont permis de définir clairement la feuille de
route pour le développement à venir. Dans le prochain chapitre, nous entrerons dans le vif
du sujet en entamant le développement du sprint 1 de la release 1.

20
Chapitre 3

Sprint 1 : Les cas de priorité 1

3.1 Introduction
Dans ce chapitre, nous avons l’intention de présenter le premier sprint de notre projet,
au cours duquel nous décrirons la conception des tâches suivantes : Authentification, Gérer
les utilisateurs. Ce sprint englobe l’analyse, la conception (diagrammes de cas d’utilisation,
de classes, de séquence et d’activité), la mise en œuvre et les tests fonctionnels.

3.2 Analyse
Cette section met l’accent sur le raffinement des cas d’utilisation et de leurs descriptions
textuelles. Nous présentons également le backlog du premier Sprint ainsi que les prototypes
d’interfaces qui y sont associés.

3.2.1 Backlog de sprint 1

Le Backlog de la Release 1 Sprint 1 contient une liste de tâches identifiées par l’équipe
Scrum qui doivent être complétées avant la fin du sprint.

ID User Story Id Tache Tache Effort

1 En tant qu’administrateur , je peux 1.1 Authentification de l’administra- 3 jours
me connecter a l’application teur
2 En tant que Responsable Manage- 2.1 Authentification de Responsable- 3 jours
ment Qualite, je peux me connecter Management Qualite
a l’application
3 En tant que Pilote de processus, je 3.1 Authentificationde Pilote de pro- 2 jours
peux me connecter a l’application cessus
4 En tant qu’administrateur, je peux 4.1 Ajouter utilisateur 4 jours
ajouter un utilisateur.
5 En tant qu’administrateur, je peux 5.1 Consulter la liste des utilisateurs 2 jours
consulter les utilisateurs.
6 En tant qu’administrateur, je peux 6.1 Modifier les informations de l’utili- 3 jours
modifier un utilisateur sateur
4 En tant qu’administrateur, je peux 4.1 Supprimer l’utilisateur sélectionné 3 jours
supprimer un utilisateur
TABLE 3.1: Backlog de sprint 1

21
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

3.2.2 Diagramme des cas d’utilisation de sprint 1

Le diagramme de cas d’utilisation fait partie des diagrammes structurels d’UML et sert
à modéliser le comportement du systè[Link] présentons dans la figure ci-dessous le dia-
gramme des cas d’utilisation pour ce premier sprint :

F IGURE 3.1 – Cas d’utilisation du Sprint 1

3.2.3 Raffinement et description de cas d’utilisation globale du sprint 1

Dans cette partie on va décrire les scénarios de chaque cas d’utilisation de ce sprint :

[Link] Raffinement du modèle du cas d’utilisation «S’authentifier»

L’accès à certains services de l’application exige une vérification d’identité, que l’utili-
sateur soit un administrateur, un responsable management qualité ou pilote de processus,
dans le but de garantir les objectifs de sécurité. Les utilisateurs doivent d’abord s’authenti-
fier. La figure ci-dessous présente le diagramme de cas d’utilisation pour le processus d’au-
thentification.

F IGURE 3.2 – Raffinement du modèle du cas d’utilisation «S’authentifier»

22
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

[Link] Description textuelle «S’authentifier»

Nous présentons dans cette partie la réalisation de descriptions textuelles pour le cas
d’utilisation "s’authentifier" à partir de ce tableau :

Cas d’utilisation Authentification

Acteur Administrateur/Responsable Management Qualite/Pilote de processus
Pré-condition Utilisateur Authentifié
1- L’utilisateur saisit son adresse e-mail et son mot de passe
et clique sur le bouton « S’authentfier».
Scénario de Base 2 - L’utilisateur valide l’authentification.
3 - Le système vérifie les données saisies.
4 - Le système affiche l’espace personnel du L’utilisateur.
Post-condition L’utilisateur est redirigé vers son espace privé.
Échec d’enregistrement dans la base de données
Scénario alternatif
Le système génère un message d’erreur. page

TABLE 3.2 – Description textuelle de cas d’utilisation «s’authentifier».

[Link] Raffinement de modèle de cas d’utilisation « Gérer les utilisateurs »

La figure suivante est un diagramme de cas d’utilisation relatif à l’acteur «Administra-
teur». Notre application lui permet de gérer tous les utilisateurs,consulter , supprimer,modifier
ou ajouter un nouvel utilisateur.

F IGURE 3.3 – Diagramme de cas d’utilisation «Gérer les utilisateurs»

[Link] Description textuelle du cas d’utilisation "Gérer les utilisateurs"

Nous présentons dans cette partie la réalisation de descriptions textuelles pour le cas
d’utilisation "Gérer les utilisateurs" afin d’obtenir une description approfondie des diffé-
rents scénarios possibles.

- Description textuelle "Ajouter utilisateur"

23
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Nous présentons dans cette partie la réalisation de descriptions textuelles pour le cas d’uti-
lisation "Ajouter utilisateur" à partir de ce tableau :

Cas d’utilisation Ajouter un utilisateur

Acteur Administrateur
Pré-condition Administrateur Authentifié
1- L’administrateur accède a l’interface Utilisateurs
2 - L’administrateur clique sur ajouter un utilisateur
Scénario de Base 3 - Le système affiche le formulaire d’ajout d’un nouvel utilisateur
4 -L’administrateur remplir les champs de formulaire
5- Il clique sur bouton "Ajouter".
Post-condition Utilisateur ajouté avec succès.
1-Erreur d’enregistrement du nouvel utilisateur dans la base
de données
Scénario alternatif
2- Le système génère un message d’erreur
3- L’administrateur quitte la page d’ajout d’un nouvel utilisateur.

TABLE 3.3 – Description textuelle de l’opération «Ajouter un utilisateur».

- Description textuelle " Modifier utilisateur"

Nous présentons dans cette partie la réalisation de descriptions textuelles pour le cas d’uti-
lisation "Modifier utilisateur" à partir de ce tableau :

Cas d’utilisation Modifier un utilisateur

Acteur Administrateur
Pré-condition Administrateur Authentifié
1- L’administrateur accède a l’interface Utilisateurs
2 - L’administrateur clique sur le bouton Modifier un utilisateur
Scénario de Base 3 - Le système affiche le formulaire de modifier d’un utilisateur
4 -L’administrateur remplir les champs de formulaire
5- Il clique sur bouton modifier.
Post-condition Utilisateur de modifié avec succès.
1-Erreur de modification d’un utilisateur dans la base de données
Scénario alternatif 2- Le système génère un message d’erreur
3- L’administrateur quitte la page modifier un utilisateur.

TABLE 3.4 – Description textuelle de l’opération «modifier un utilisateur».

24
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

- Description textuelle "Supprimier utilisateur"

Nous présentons dans cette partie la réalisation de descriptions textuelles pour le cas d’uti-
lisation "Supprimer utilisateur" à partir de ce tableau :

Cas d’utilisation Supprimier un utilisateur

Acteur Administrateur
Pré-condition Administrateur Authentifié
1- L’administrateur accède a l’interface Utilisateurs
2 - L’administrateur clique sur le bouton Supprimier un utilisateur
Scénario de Base 3 - Le système affiche le formulaire de suppression d’un utilisateur
4 -L’administrateur remplir les champs de formulaire
5- Il clique sur bouton Supprimier.
Post-condition Utilisateur Supprimé avec succès.
1-Erreur de suppression d’un utilisateur dans la base de données
Scénario alternatif 2- Le système génère un message d’erreur
3- L’administrateur quitte la page supprimier un utilisateur.

TABLE 3.5 – Description textuelle de l’opération «supprimier un utilisateur».

3.3 Conception statique de sprint 1

Dans la première étape de notre projet (sprint 1), nous avons dessiné un schéma qui
montre comment différentes parties de notre système sont connectées (diagramme de classe).
De plus, nous avons créé un plan pour organiser les informations dans notre base de don-
nées (schéma relationnel). Pour rendre ces informations plus faciles à comprendre, nous
avons également fait une liste qui explique ce que contiennent les principales parties de
notre base de données (dictionnaire de données).

3.3.1 Diagramme de classe

Un diagramme de classe est un type de diagramme UML qui décrit un système en visua-
lisant les différents types d’objets au sein d’un système et les types de relations statiques qui
existent entre eux. Il illustre également les opérations et les attributs des classes, représentées
par la figure ci-dessous que nous avons conçue lors du premier sprint[13].

25
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

F IGURE 3.4 – Diagramme de Classe Sprint 1

3.3.2 Schéma relationnel

Le schéma relationnel englobe toutes les relations qui existent dans une base de données.
Il est constitué de l’ensemble des schémas de relation présents dans cette base de données.
— Administrateur(id,email,Mot de passe)
— Utilisateur(idU,cin,Nom,Prenom, email, Mot de passe, role)
— RMQ(idR,Email,Mot de passe,#idU)
— Pilote de Processus(idP, email, Mot de passe,#idU)

3.3.3 Dictionnaire de données

Le dictionnaire des données est un document qui regroupe toutes les données que vous
aurez à conserver dans votre base de donnée relationnelle.

Administrateur(id,email,Mot de passe)

Nom de la colonne Type de donnée Constraint

id int Primary Key Auto Increment
E-mail varchar NOT NULL
Mot de passe varchar NOT NULL

TABLE 3.6 – Dictionnaire de données : Administrateur

26
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Utilisateur(id,Cin,Nom,Prenom, email, Mot de passe, role)

Nom de la colonne Type de donnée Constraint

id int Primary Key Auto Increment
Cin int NOT NULL
Nom varchar NOT NULL
Prenom varchar NOT NULL
Mot de passe varchar NOT NULL
E-mail varchar NOT NULL
Role varchar NOT NULL

TABLE 3.7 – Dictionnaire de données : Utilisateur

RMQ(idR email, Mot de passe,#idU)

Nom de la colonne Type de donnée Constraint

idR int Primary Key Auto Increment
E-mail varchar NOT NULL
Mot de passe varchar NOT NULL
idU int Foreigh key References Utilisateur(idU)

TABLE 3.8 – Dictionnaire de données : RMQ

Pilote de Processus(idP ,email, Mot de passe,#idU)

Nom de la colonne Type de donnée Constraint

idP int Primary Key Auto Increment
E-mail varchar NOT NULL
Mot de passe varchar NOT NULL
idU int Foreigh key References Utilisateur(idU)

TABLE 3.9 – Dictionnaire de données :Pilote de Processus

3.4 Conception dynamique du sprint 1

Les diagrammes de séquence sont une solution de modélisation dynamique populaire
dans le langage UML, car ils se concentrent de manière plus précise sur les lignes de vie,
les processus et les objets qui coexistent, ainsi que sur les messages qu’ils échangent pour
exécuter une fonction avant la fin de la ligne de vie.

3.4.1 Diagrammes de séquence

Un diagramme de séquence est un type de diagramme d’interaction, car il décrit com-
ment et dans quel ordre plusieurs objets fonctionnent ensemble. Ces diagrammes sont uti-
lisés à la fois par les développeurs logiciels et les managers d’entreprises pour analyser les
besoins d’un nouveau système ou documenter un processus existant. Les diagrammes de
séquence sont parfois appelés diagrammes d’événements ou scénarios d’événements.[14]

Diagramme de séquence «S’authentifier»

27
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Ce diagramme décrit les scénarios possible de l’authentification. L’utilisateur (par exemple

le Responsable) doit tout d’abord s’identifier par son Adresse E-mail et son mot de passe.
Le contrôleur prend en charge la vérification et consulte la base de données. S’il est accepté,
il y’aura l’accès au système. Sinon il lui affiche un message d’erreur afin de rectifier ses don-
nées puis l’autorise la connexion en lui dirigeant vers son espace personnel.

F IGURE 3.5 – Didramme de séquence «S’authentifier»

28
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Diagramme de séquence «Ajouter un utilisateur»

L’administrateur peut ajouter des informations en remplissant un formulaire après s’être

connecté. Le système vérifie la validité des données et les enregistre si elles sont nouvelles.
Un message confirme ensuite la réussite de l’opération.

F IGURE 3.6 – Didramme de séquence «Ajouter un utilisateur»

29
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Diagramme de séquence «Modifier un utilisateur»

Une fois connecté, l’administrateur a la possibilité de gérer les utilisateurs qu’il souhaite
et d’apporter des modifications. Pour cela, il doit accéder à l’interface de gestion des utilisa-
teurs. Ensuite, il remplit un formulaire avec les nouvelles informations et le système s’assure
que les champs ne sont ni vides ni invalides. Les données sont ensuite envoyées au contrô-
leur qui vérifie si elles existent déjà dans la base de données. Si les données sont valides, le
système procède à la mise à jour des informations.

F IGURE 3.7 – Diagramme de séquence «Modifier un utilisateur»

30
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Diagramme de séquence «Supprimer un utilisateur»

Lorsque l’administrateur choisit un utilisateur à supprimer, le système vérifie la requête

de suppression de l’administrateur et la transmet au contrôleur. Si la demande est validée,
le contrôleur procède à la suppression de l’utilisateur sélectionné après confirmation.

F IGURE 3.8 – Diagramme de séquence «Supprimer un utilisateur»

31
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

3.4.2 Diagrammes d’activités

Un diagramme d’activité est une représentation graphique d’un ensemble d’activités sys-
témiques exécutées et est considéré comme une variation du diagramme de flux de l’état.
Les diagrammes d’activité décrivent des activités parallèles et conditionnelles, des cas d’uti-
lisation et des fonctions système à un niveau détaillé.[15].

Diagramme d’activité « s’authentifier »

La figure ci-dessous illustre le diagramme d’activité d’authentification :

F IGURE 3.9 – Diagramme d’activité « s’authentifier »

32
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Diagramme d’activité «Ajouter un utilisateur»

La figure ci-dessous illustre le diagramme d’activité d’ajouter un utilisateur :

F IGURE 3.10 – Diagramme d’activité «Ajouter un utilisateur»

33
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Diagramme d’activité «Modifier un utilisateur»

La figure ci-dessous illustre le diagramme d’activité de modification un utilisateur :

F IGURE 3.11 – Diagramme d’activité «Modifier un utilisateur»

34
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

Diagramme d’activité «Supprimer un utilisateur»

La figure ci-dessous illustre le diagramme d’activité de suppression un utilisateur :

F IGURE 3.12 – Diagramme d’activité «Supprimer un utilisateur»

3.5 interfaces graphiques

3.5.1 Interface d’accueil

F IGURE 3.13 – Interface d’accueil

35
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

3.5.2 Interface d’authentification

L’interface "Authentification" illustrée dans la figure ci-dessous comprend un champ
pour l’adresse e-mail de l’utilisateur, un champ de saisie du mot de passe, et un bouton
"S’authentifier".

F IGURE 3.14 – Interface d’authentification

3.5.3 Interface Ajouter un utilisateur

F IGURE 3.15 – Interface Ajouter un utilisateur

36
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

3.5.4 Interface des utilisateurs

F IGURE 3.16 – Interface des utilisateurs

3.5.5 Interface de Modifier utilisateurs

F IGURE 3.17 – Interface de Modifier un utilisateur

37
3 CHAPITRE 3. SPRINT 1 : LES CAS DE PRIORITÉ 1

3.5.6 Interface de suppression utilisateur

F IGURE 3.18 – Interface de suppression un utilisateur

3.6 Conclusion
Durant ce chapitre, nous avons entamé le premier sprint de notre projet et analysé minu-
tieusement ses diverses fonctionnalités, étayées par des diagrammes informatifs. Ce sprint
initial s’est révélé être d’une importance capitale, en particulier grâce aux fonctionnalités es-
sentielles telles que l’authentification des utilisateurs et la gestion des comptes. Ces éléments
ont jeté les fondations nécessaires pour la réussite globale du projet..

38
Chapitre 4

Sprint 2 : Les cas de priorité 2

4.1 Introduction
Dans ce chapitre, nous avons l’intention de présenter le deuxième sprint de notre projet,
où nous décrirons la conception des tâches suivantes : Gérer processus, Affecter pilotes et
Gérer documents Ce sprint couvre l’analyse, la conception (diagrammes de cas d’utilisa-
tion, de classe, de séquence et d’activité), la mise en œuvre et les tests fonctionnels.

4.2 Analyse
Cette section est consacrée au raffinement des cas d’utilisations et leur descriptions tex-
tuelles ,Nous illustrons aussi le backlog du deuxième Sprint et les prototypes des interfaces
y relatives.

4.2.1 Backlog de sprint 2

Le Backlog du Sprint 2 contient une liste de tâches identifiées par l’équipe Scrum qui
doivent être complétées avant la fin du sprint.

ID User Story Id Taches Tache Effort

1 En tant que responsable ma- 1.1 Ajouter un processus
nagement qualite , je peux gé-
rer des processus
1.2 Modifier un processus
1.3 Supprimer un processus 10 jours
2 En tant que responsable ma- 2.1 Affecter pilotes 6jours
nagement qualite , je peux Af-
fecter des pilotes
3 En tant que responsable ma- 3.1 Ajouter un document
nagement qualite , je peux gé-
rer documents
3.2 Supprimer un document 6 jours
TABLE 4.1: Backlog de sprint 2

39
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

4.2.2 Diagramme des cas d’utilisation du deuxième sprint

Le diagramme de cas d’utilisation est l’un des diagrammes structurels d’UML utilisé
pour représenter le comportement du système. La figure ci-dessous montre le diagramme
des cas d’utilisation pour ce deuxième sprint :

F IGURE 4.1 – Cas d’utilisation du Sprint 2

4.2.3 Raffinement et description de cas d’utilisation globale du sprint 2

Dans cette partie on va décrire les scénarios de chaque cas d’utilisation de ce sprint :

[Link] Raffinement du modèle du cas d’utilisation «Gérer processus»

La figure suivante est un diagramme de cas d’utilisation relatif à l’acteur «Responsable
Mangement Qualité ». Notre application lui permet de gérer tous les processus ,consulter ,
supprimer ,modifier ou ajouter un processus.

F IGURE 4.2 – Raffinement du modèle du cas d’utilisation «Gérer les processus»

40
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

[Link] Description textuelle "Gérer les processus"

Cas d’utilisation Gérer les processus

Acteur Responsable Mangement Qualité
Pré-condition Responsable mangement qualité Authentifié
Ajouter Modifier Supprimer
[Link] responsable [Link] responsable
mangement mangement
qualité accède qualité accède a
a l’interface processus. l’interface processus. [Link] responsable
2. le responsable 2. le responsable mangement
clique sur le bouton clique sur le bouton qualité accède
ajouter . modifier . a l’interface processus.
[Link] système affiche [Link] système affiche [Link]
Scénario de Base
le formulaire le formulaire les données
d’ajout d’un nouvel de modification à supprimer
processus. un processus. 3. Cliquez sur
[Link] responsable remplit [Link] responsable "Supprimer" puis
les champs de remplit les champs sur "Valider".
formulaire . de formulaire .
5. Il clique sur 5. Il clique sur
bouton "Ajouter". bouton "Modifier".
Post-condition ajouté avec succès modifié avec succès supprimé avec succès
Scénario alternatif Le système génère un message d’erreur .

TABLE 4.2 – Description textuelle de l’opération «Gérer les processus»

4.2.4 Raffinement du modèle du cas d’utilisation «Affectuer les pilotes»

La figure suivante est un diagramme de cas d’utilisation relatif à l’acteur «Responsable
Mangement Qualité ». Notre application lui permet d’affectuer les pilotes .

F IGURE 4.3 – Raffinement du modèle du cas d’utilisation «Affecter pilotes»

41
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

[Link] Description textuelle de «Affecter pilotes»

Cas d’utilisation Affecter les pilotes

Acteur Responsable Mangement Qualité
Pré-condition Responsable mangement qualité Authentifié
1- Le responsable mangement qualité accède a l’interface pilote.
2 - le responsable clique sur le bouton affecter
Scénario de Base 3 - Le système affiche le formulaire d’affectation d’un pilote.
4 -Le responsable remplit les champs de formulaire
5- Il clique sur bouton "Affecter".
Post-condition Pilote affectué avec succès.
Scénario alternatif 1-Le système génère un message d’erreur .

TABLE 4.3 – Description textuelle de «Affecter pilotes».

4.2.5 Raffinement du modèle du cas d’utilisation «Gérer documents»

La figure suivante est un diagramme de cas d’utilisation relatif à l’acteur «Responsable
Mangement Qualité ». Notre application lui permet de gérer tous les documents ,consulter ,
supprimer , ajouter un document

F IGURE 4.4 – Raffinement du modèle du cas d’utilisation «Gérer documents»

42
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

[Link] Description textuelle de «Gérer documents»

Cas d’utilisation Gérer les documents

Acteur Responsable Mangement Qualité
Pré-condition Responsable mangement qualité Authentifié
Ajouter Supprimer
[Link] responsable mangement
qualité accède a l’interface
documents.
[Link] responsable mangement
2. le responsable clique
qualité accède a l’interface documents.
sur le bouton "ajouter".
Scénario de Base [Link] Choisi le ducument à supprimer
[Link] système affiche le formulaire
[Link] Clique sur "Supprimer"
d’ajout d’un nouvel documents.
puis sur "Valider".
4. Le responsable remplit
les champs de formulaire .
5. Il clique sur bouton "Ajouter"
Post-considion ajouté avec succès supprimé avec succès
Scénario alternatif Le système génère un message d’erreur .

TABLE 4.4 – Description textuelle de l’opération «Gérer documents»

4.3 Conception statique de sprint 2

Dans la phase de conception statique du sprint 2, nous avons élaboré un diagramme de
classe pour représenter les structures des classes utilisées dans cette itération. Nous avons
également créé un schéma relationnel pour organiser et structurer les données dans notre
base de données. Pour faciliter la compréhension des données, nous avons préparé un dic-
tionnaire répertoriant les informations clés des principales tables du sprint 2.

4.3.1 Diagramme des classe

Le diagramme de classe est la représentation graphique de la structure interne d’un sys-
tème. Les principaux éléments de cette vue statique sont les classes et les différentes relations
entre elles représentées par la figure ci-dessous que nous avons conçue lors du deuxième
sprint.

43
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.5 – Diagramme de classe de sprint 2

44
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

4.3.2 Schéma relationnel

— Utilisateur(idU,cin,Nom,Prenom, email, Mot de passe, role)
— RMQ(idR,Email,Mot de passe,#idU)
— Pilote de Processus(idP, pilote,copilote,#idprocessus)
— document(iddoc, nom-fichier)
— processus(idprocessus,nom,version,pilote,copilote,domaine,moyens,types,objectifs , fi-
nalites)

4.3.3 Dictionnaire de données

Le dictionnaire de données est un document qui regroupe toutes les données que vous
devrez conserver dans votre base de données relationnelle.

Utilisateur(id,Cin,Nom,Prenom, email, Mot de passe, role)

Nom de la colonne Type de donnée Constraint

id int Primary Key Auto Increment
Cin int NOT NULL
Nom varchar NOT NULL
Prenom varchar NOT NULL
Mot de passe varchar NOT NULL
E-mail varchar NOT NULL
Role varchar NOT NULL

TABLE 4.5 – Dictionnaire de données : Utilisateur

RMQ(idR, Email, Mot de passe,#idU)

Nom de la colonne Type de donnée Constraint

idR int Primary Key Auto Increment
Mot de passe varchar NOT NULL
E-mail varchar NOT NULL
idU int Foreigh key References Utilisateur(idU)

TABLE 4.6 – Dictionnaire de données : RMQ

Pilote de processus(idp, pilote, copilote,#idprocessus)

Nom de la colonne Type de donnée Constraint

idp int Primary Key Auto Increment
pitote varchar NOT NULL
copilote varchar NOT NULL
idprocessus int Foreigh key References processus(idprocessus)

TABLE 4.7 – Dictionnaire de données : Pilote de processus

document(iddoc, nom-fichier)

45
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

Nom de la colonne Type de donnée Constraint

iddoc int Primary Key Auto Increment
nom-fichier varchar NOT NULL

TABLE 4.8 – Dictionnaire de données : Pilote de processus

processus(idprocessus,nom,version,pilote,copilote,domaine,moyens,types,objectifs ,
finalites)

Nom de la colonne Type de donnée Constraint

idprocessus int Primary Key Auto Increment
nom varchar NOT NULL
version int NOT NULL
pilote varchar NOT NULL
copilote varchar NOT NULL
demaine varchar NOT NULL
moyens varchar NOT NULL
types varchar NOT NULL
objectifs varchar NOT NULL
finalites varchar NOT NULL

TABLE 4.9 – Dictionnaire de données : processus

4.4 Conception dynamique du sprint 2

Les diagrammes de séquence sont une solution de modélisation dynamique populaire
dans le langage UML car ils représentent précisément les interactions entre les lignes de vie,
les processus et les objets qui existent simultanément. Ils illustrent les messages échangés
entre ces entités pour effectuer des fonctions dans la durée de vie de la ligne de vie.

4.4.1 Diagramme de séquence de cas «Gérer processus»

[Link] Diagramme de séquence de cas «Ajouter un processus»
Une fois authentifié, le responsable du management de la qualité a la possibilité d’ajou-
ter un processus. Pour cela, il doit accéder à l’interface d’ajout d’un processus. Le système
se charge de vérifier la validité des champs, y compris la présence de champs vides ou
[Link], une requête est envoyée à la base de données contenant les données à
enregistrer dans la table "processus", suivie d’une réponse contenant le résultat de l’enregis-
trement dans un [Link] figure suivante illustre le diagramme de séquence «Ajouter un
processus».

46
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.6 – Diagramme de séquence de cas «Ajouter un processus»

[Link] Diagramme de séquence « Modifier un processus»

Une fois authentifié, le responsable du management de la qualité a la possibilité de
consulter et de modifier les processus. Pour cela, il doit accéder à l’interface de modification
où il complète un formulaire avec les nouvelles données. Le système se charge de vérifier
la validité des champs, y compris la présence de champs vides ou [Link], une
requête est envoyée à la base de données contenant les données à enregistrer dans la table
"processus", suivie d’une réponse contenant le résultat de l’enregistrement dans un mes-
[Link] figure suivante illustre le diagramme de séquence « Modifier un processus».

47
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.7 – Diagramme de séquence « Modifier un processus»

[Link] Diagramme de séquence « Supprimer un processus»

Responsable du management de la qualité sélectionne le processus qu’il souhaite sup-
primer. Le système vérifie la demande de suppression de Responsable du management de
la qualité et envoie les données au contrôleur. Si le contrôleur confirme la demande, le pro-
cessus sélectionnée sera supprimé[Link] figure suivante illustre le diagramme de séquence «
Supprimer un processus». .

48
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.8 – Diagramme de séquence « Supprimer un processus»

4.4.2 Diagramme de séquence de cas «Affecter Pilotes»

[Link] Diagramme de séquence de cas «Affecter un pilote»
Une fois authentifié, le responsable du management qualité peut remplir le formulaire
d’affectation affiché par le système. Le système vérifie alors si les champs sont vides ou
contiennent des données invalides. Ensuite, il enregistre les données saisies dans la base
de données et affiche finalement un message de [Link] figure suivante illustre le
diagramme de séquence «Affecter Pilotes».

49
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.9 – Diagramme de séquence de cas «Affecter un pilote»

4.4.3 Diagramme de séquence de cas «Gérer documents»

[Link] Diagramme de séquence de cas «Ajouter un document»
Une fois authentifié, le responsable du management qualité peut choisir le fichier à télé-
charger. Le système vérifie alors si les champs sont vides ou invalides. Ensuite, il enregistre
le fichier dans la base de données et affiche finalement un message. La figure suivante illustre
le diagramme de séquence « Ajouter un document».

50
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.10 – Diagramme de séquence de cas «Ajouter un document»

[Link] Diagramme de séquence « Supprimer un document»

Responsable du management de la qualité sélectionne un document qu’il souhaite suppri-
mer. Le système vérifie la demande de suppression de Responsable du management de la
qualité et envoie les données au contrôleur. Si le contrôleur confirme la demande, un docu-
ment sélectionnée sera supprimée.

51
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.11 – Diagramme de séquence de cas «Supprimer un document»

4.5 Diagrammes d’activités

Un diagramme d’activité est une représentation graphique d’un ensemble d’activités
procédurales exécutées et est considéré comme une variante du diagramme de flux d’états.
Les diagrammes d’activité décrivent les activités parallèles et conditionnelles, les cas d’uti-
lisation et les fonctions système à un niveau détaillé.

4.5.1 Diagramme d’activité «Gérer processus»

[Link] Diagramme d’activité «Ajouter un processus»
La figure ci-dessous illustre le diagramme d’activité pour l’ajout d’un processus :

52
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.12 – Diagramme d’activité «Ajouter un processus»

[Link] Diagramme d’activité «Modifier un processus»

La figure ci-dessous illustre le Diagramme d’activité "Modifier une processus" :

53
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.13 – Diagramme d’activité «Modifier un processus»

[Link] Diagramme d’activité «supprimer un processus»

La figure ci-dessous illustre le Diagramme d’activité "Supprimer un processus" :

54
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.14 – Diagramme d’activité «supprimer un processus»

4.5.2 Diagramme d’activité « Affecter pilotes»

[Link] Diagramme d’activité «Affecter un pilote»
La figure ci-dessous illustre le Diagramme d’activité "Affecter un pilote" :

F IGURE 4.15 – Diagramme d’activité «affecter un pilote»

55
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

4.5.3 Diagramme d’activité «Gérer documents»

[Link] Diagramme d’activité «Ajouter un document»
La figure ci-dessous illustre le Diagramme d’activité "Ajouter un document" :

F IGURE 4.16 – Diagramme d’activité «Ajouter un document»

[Link] Diagramme d’activité «Supprimer un document»

La figure ci-dessous illustre le Diagramme d’activité "Supprimer un document" :

56
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.17 – Diagramme d’activité «Supprimer un document»

4.6 Interfaces graphiques

4.6.1 Interface ajouter un processus
L’interface «ajouter un processus» représentée par la figure ci-dessous :

F IGURE 4.18 – Interface ajouter un processus

57
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

4.6.2 Interface Liste des processus

L’interface «Liste des processus» représentée par la figure ci-dessous :

F IGURE 4.19 – Interface Liste des processus

4.6.3 Interface modifier un processus

L’interface «modifier un processus» représentée par la figure ci-dessous :

F IGURE 4.20 – Interface modifier un processus

4.6.4 Interface supprimer un processus

L’interface «supprimer un processus» représentée par la figure ci-dessous :

58
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

F IGURE 4.21 – Interface supprimer un processus

4.6.5 Interface Affecter les pilotes

L’interface «Affecter les pilotes» représentée par la figure ci-dessous :

F IGURE 4.22 – Interface Affecter les pilotes

59
4 CHAPITRE 4. SPRINT 2 : LES CAS DE PRIORITÉ 2

4.6.6 Interface Ajouter documents

L’interface «Ajouter documents» représentée par la figure ci-dessous :

F IGURE 4.23 – Interface Ajouter documents

4.7 Conclusion
En résumé, ce chapitre a couvert l’analyse et la conception statique et dynamique des
cas d’utilisation de priorité "2", ainsi que la préparation à la mise en œuvre du deuxième
sprint avec un accent sur les interfaces graphiques. Ces étapes ont contribué à faire avancer
le développement du projet.

60
Chapitre 5

Sprint 3 : Les cas de priorité 3

5.1 Introduction
Dans ce chapitre, nous avons l’intention de présenter le troisième sprint de notre pro-
jet, où nous décrirons la conception des tâches suivantes : Gérer indicateurs,remplir in-
dicateurs ,Consulter l’historique documentaire. Ce sprint couvre l’analyse, la conception
(diagrammes de cas d’utilisation, de classes, de séquence et d’activité).

5.2 Analyse
Cette section met l’accent sur le raffinement des cas d’utilisation et de leurs descriptions
textuelles. Nous présentons également le backlog du troisième Sprint ainsi que les proto-
types d’interfaces qui y sont associés.

5.2.1 Backlog de sprint 3

Le Backlog de sprint 3 contient une liste de tâches identifiées par l’équipe Scrum qui
doivent être complétées avant la fin du sprint.

ID User Story Id Tache Taches Effort

1 En tant que Responsable Man- 1.1 Ajouter un indicateur
gement Qualit, je peux Gérer les
indicateurs
1.2 Modifier un indicateur
1.3 Supprimer un indicateur 5 jours
2 En tant que Pilote de Proces- 2.1 Consulter l’historique documen- 3 jours
sus, je peux Consulter l’histo- taire
rique documentaire
3 En tant que Pilote de Processus, 3.1 remplir les indicateurs 5 jours
je peux remplir les indicateurs
TABLE 5.1: Backlog de sprint 3

61
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

5.2.2 Diagramme des cas d’utilisation du troisième sprint

Le diagramme de cas d’utilisation est l’un des diagrammes structuraux d’UML, utilisé
pour modéliser le comportement d’un système. La figure ci-dessous présente le diagramme
des cas d’utilisation pour ce troisième sprint :

F IGURE 5.1 – Diagramme des cas d’utilisation du sprint 3

5.2.3 Raffinement et description de cas d’utilisation globale du sprint 3

Dans cette partie on va décrire les scénarios de chaque cas d’utilisation de ce sprint :

[Link] Raffinement du modèle du cas d’utilisation «Gérer indicateurs»

F IGURE 5.2 – Raffinement du modèle du cas d’utilisation «Gérer indicateurs»

62
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

[Link] Description textuelle «Gérer indicateurs»

Cas d’utilisation Gérer indicateurs

Acteur Responsable management qualité
Pré-condition Responsable management qualité Authentifié
Ajouter Modifier Supprimer
[Link]
accède a l’interface
1. RMQ accède a
processus .
l’interface indicateurs.
2. RMQ 1. RMQ
2. RMQ clique sur
clique sur le bouton accède a l’interface
le bouton " modifier"
"ajouter" . indicateurs.
3..Le système affiche
[Link] système affiche [Link] Choisi
le formulaire de
Scénario de Base le formulaire d’ajout les données
modification
d’un nouvel à supprimer
d’indicateur.
indicateur. [Link] Clique sur
4. RMQ remplit les champs
4. .RMQ "Supprimer" puis
de formulaire .
remplit les champs sur "Valider".
5. Il clique sur
de formulaire .
bouton "Modifier"
5. Il clique sur
bouton "Ajouter"
Post-condition ajouté avec succès modifié avec succès supprimé avec succès
Scénario alternatif Le système génère un message d’erreur .

TABLE 5.2 – Description textuelle «Gérer indicateurs»

[Link] Raffinement du modèle du cas d’utilisation «Remplir indicateurs»

F IGURE 5.3 – Raffinement du modèle du cas d’utilisation «Remplir indicateurs»

63
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

[Link] Description textuelle de «Remplir indicateur»

Cas d’utilisation Remplir indicateur

Acteur pilote de processus
Pré-condition pilote de processus Authentifié
1- Le pilote de processus accède a l’interface indicateur.
2 - le pilote clique sur remplir indicateur
3 - Le système affiche les details associes a son processus.
Scénario de Base
4-Le pilote cliquer sur botton "Liste des indicateurs".
5 -Le pilote remplit les champs de l’indicateur
6- Il clique sur bouton "Envoyer".
Post-condition L’indicateur est remplir avec succès.
Scénario alternatif 1-Le système génère un message d’erreur .

TABLE 5.3 – Description textuelle de «Remplir indicateur».

[Link] Raffinement du modèle du cas d’utilisation «Consulter l’historique documen-

taire»

F IGURE 5.4 – Raffinement du modèle du cas d’utilisation «Consulter documents»

[Link] Description textuelle de «Consulter l’historique documentaire»

Cas d’utilisation Consulter l’historique documentaire

Acteur pilote de processus
Pré-condition pilote de processus Authentifié
1- Le pilote de processus accède a l’interface cosulter les documents.
Scénario de Base
2- il clique consulter les documents
Post-condition S’affiche les documents avec succès.
Scénario alternatif 1-Le système génère un message d’erreur .

TABLE 5.4 – Description textuelle de «Consulter l’historique documentaire».

64
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

5.3 Conception statique de sprint 3

5.3.1 Diagramme de classe

F IGURE 5.5 – Diagramme de classe

5.3.2 Schéma relationnel

— Utilisateur(idU,cin,Nom,Prenom, email, Mot de passe, role)
— RMQ(idR,Email,Mot de passe,#idU)

65
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

— Pilote de Processus(idp,Email,Mot de passe,#idU)

— document(iddoc, nom-fichier)
— processus(idprocessus,nom,version,pilote,copilote,domaine,moyens,types,objectifs , fi-
nalites)
— indicateur(idindicateur, objectif, indicateur,mode-calcul, seuil, fréquence-suivi, responsable-
suivi,date-insertion, résultat,#idprocessus)

5.4 Conception dynamique du sprint 3

La phase de conception dynamique du troisième sprint fait appel à deux types de dia-
grammes pour représenter le comportement des systèmes : les diagrammes de séquence et
les diagrammes d’activités. Ces diagrammes sont largement utilisés dans le langage UML
(Unified Modeling Language) pour illustrer l’interaction entre les différents acteurs, objets
et processus au sein d’un système.

5.4.1 Diagrammes de séquence

Les diagrammes de séquence sont largement utilisés comme solution de modélisation
dynamique dans le langage UML, en se concentrant sur les lifelines, les processus et les
objets qui coexistent simultanément. Ils mettent en lumière les échanges de messages entre
ces éléments pour accomplir une fonction avant la fin de la lifeline.

[Link] Diagrammes de séquence «Ajouter indicateurs»

La figure suivante, nous présentons le diagramme de séquence de ajouter un indicateur :

66
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

F IGURE 5.6 – Diagrammes de séquence «Ajouter indicateurs»

[Link] Diagrammes de séquence «Modifier indicateurs»

La figure suivante, nous présentons le diagramme de séquence de modifier un indica-
teur :

67
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

F IGURE 5.7 – Diagrammes de séquence «Modifier indicateurs»

[Link] Diagrammes de séquence «Supprimer indicateurs»

La figure suivante, nous présentons le diagramme de séquence de supprimer un indica-
teur :

68
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

F IGURE 5.8 – Diagrammes de séquence «Supprimer indicateurs»

[Link] Diagramme de séquence « Consulter l’historique documentaire»

La figure suivante, nous présentons le diagramme de séquence de consulter l’historique
documentaire :

69
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

F IGURE 5.9 – Diagramme de séquence « Consulter l’historique documentaire»

5.4.2 Diagrammes d’activités

Un diagramme d’activité est une représentation graphique d’un ensemble d’activités sys-
témiques procédurales exécutées, et il est considéré comme une variante du diagramme de
flux d’états. Les diagrammes d’activité décrivent les activités parallèles et conditionnelles,
les cas d’utilisation et les fonctions système à un niveau détaillé.

70
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

[Link] Diagramme d’activité «Ajouter un indicateur»

La figure suivante, nous présentons le diagramme d’activité d’ajouter un indicateur.

F IGURE 5.10 – Diagramme d’activité «Ajouter un indicateur»

71
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

[Link] Diagramme d’activité «Modifier un indicateur»

La figure suivante, nous présentons le diagramme d’activité de modifier un indicateur.

F IGURE 5.11 – Diagramme d’activité «Modifier un indicateur»

72
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

[Link] Diagramme d’activité «Supprimer un indicateur»

La figure suivante, nous présentons le diagramme d’activité de supprimer un indicateur.

F IGURE 5.12 – Diagramme d’activité «Supprimer un indicateur»

[Link] Diagramme d’activité «consulter l’historique documentaire»

La figure suivante, nous présentons le diagramme d’activité de l’historique .

F IGURE 5.13 – Diagramme d’activité «consulter l’historique documentaire»

73
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

[Link] Diagramme d’activité «Remplir un indicateur»

La figure suivante, nous présentons le diagramme d’activité de remplir un indicateur.

F IGURE 5.14 – Diagramme d’activité «Remplir un indicateur»

74
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

5.5 Interface graphique

5.5.1 L’interface Ajouter un indicateur
L’interface «Ajouter un indicateur» représentée par la figure ci-dessous :

F IGURE 5.15 – L’interface «Ajouter un indicateur»

5.5.2 L’interface de remplir un indicateur

L’interface «Remplir un idicateur» représentée par la figure ci-dessous :

F IGURE 5.16 – L’interface «Remplir un indicateur»

75
5 CHAPITRE 5. SPRINT 3 : LES CAS DE PRIORITÉ 3

5.5.3 L’interface Téléchargement du document

L’interface «Téléchargement du document» représentée par la figure ci-dessous :

F IGURE 5.17 – Téléchargement du document

5.6 Conclusion
Ce chapitre a traité divers aspects du troisième sprint du projet. Nous avons débuté
par l’analyse et le raffinement des modèles des cas d’utilisation de sprint 3. Ensuite, nous
avons exposé la conception statique avec le diagramme de classe et le schéma relationnel. La
conception dynamique a été explorée à travers les diagrammes de séquence et d’activités.
Enfin, nous avons abordé la mise en œuvre en mettant l’accent sur les interfaces graphiques.
Ces étapes ont permis de faire avancer le développement du projet et de préparer la réalisa-
tion du troisième sprint.

76
Chapitre 6

Sprint 4 :Les cas de priorité 4

6.1 Introduction
Dans ce chapitre, nous avons l’intention de présenter le quatrième sprint de notre projet,
où nous décrirons la conception des tâches suivantes : Consulter les notification,Consulter
des statistiques . Ce sprint couvre l’analyse, la conception (diagrammes de cas d’utilisation,
de classes, de séquence et d’activité).

6.2 Analyse
6.2.1 Backlog de sprint 4
Le Backlog de sprint 4 contient une liste de tâches identifiées par l’équipe Scrum qui
doivent être complétées avant la fin du sprint.

ID User Story Id Tache Taches Effort

2 En tant que responsable du 2.1 Consulter les statistiques 8 jours
management qualité, je peux
consulter les statistiques des in-
dicateurs associés à tous les pro-
cessus dans le système de mana-
gement qualité.
3 En tant que pilote de processus, 3.1 Consulter notifications 3 jours
je peux Consulter une notifica-
tion
TABLE 6.1: Backlog de sprint 4

77
6 CHAPITRE 6. SPRINT 4 :LES CAS DE PRIORITÉ 4

6.2.2 Diagramme des cas d’utilisation quatrième sprint

Le diagramme de cas d’utilisation, un outil structurel d’UML, est employé pour repré-
senter le fonctionnement d’un système. Ci-dessous, vous trouverez le diagramme de cas
d’utilisation pour le quatrième sprint :

F IGURE 6.1 – Diagramme des cas d’utilisation du sprint 4

6.2.3 Raffinement et description de cas d’utilisation globale du sprint 4

Dans cette partie on va décrire les scénarios de chaque cas d’utilisation de ce sprint :

[Link] Raffinement du modèle du cas d’utilisation «Consulter statisques»

F IGURE 6.2 – Raffinement du modèle du cas d’utilisation «Consulter statisques»

78
6 CHAPITRE 6. SPRINT 4 :LES CAS DE PRIORITÉ 4

[Link] Description textuelle de «Consulter les statistiques»

Cas d’utilisation Consulter les statistiques

Acteur Responsable management qualité
Pré-condition Responsable management qualité Authentifié
1- Responsable management qualité de l’Université
accède à l’interface de dashboard pour
Consulter les statistiques
Scénario de Base
2 - l’utilisateur clique sur «dashboard»
3 - le systéme redrige le Responsable management qualité vers
l’interface des statistique.
Post-condition l’interface de statistique affichée avec succès.
Scénario alternatif 1-Le système génère erreur d’affichage d’interface .

TABLE 6.2 – Description textuelle de «Consulter statistiques».

[Link] Raffinement du modèle du cas d’utilisation «Consulter notifications»

F IGURE 6.3 – Raffinement du modèle du cas d’utilisation «Consulter notifications»

[Link] Description textuelle de «Consulter notifications»

Cas d’utilisation Consulter notifications

Acteur Pilote de processus
Pré-condition Pilote de processus authentifié
1- l’utilisateur clique sur "Mes notification".
Scénario de Base 2-Le systéme redrige pilote de processus vers l’interface des
notifications.
Post-condition l’interface de notification affichée avec succès.
Scénario alternatif 1-Le système génère erreur d’affichage d’interface .

TABLE 6.3 – Description textuelle de «Gérer notifications».

79
6 CHAPITRE 6. SPRINT 4 :LES CAS DE PRIORITÉ 4

6.3 Conception statique de sprint 4

6.3.1 Diagramme de classe

F IGURE 6.4 – Diagramme de classe

6.3.2 Schéma relationnel

— RMQ(idR,Email,Mot de passe)
— indicateur(idindicateur, objectif, indicateur,mode-calcul, seuil, fréquence-suivi, responsable-
suivi,date-insertion, résultat)

6.4 Conception dynamique du sprint 4

La phase de conception dynamique du quatrième sprint fait appel à deux types de dia-
grammes pour représenter le comportement des systèmes : les diagrammes de séquence et
les diagrammes d’activités. Ces diagrammes sont largement utilisés dans le langage UML
(Unified Modeling Language) pour illustrer l’interaction entre les différents acteurs, objets
et processus au sein d’un système.

6.4.1 Diagrammes de séquence

Les diagrammes de séquence sont largement utilisés comme solution de modélisation
dynamique dans le langage UML, en se concentrant sur les lifelines, les processus et les
objets qui coexistent simultanément. Ils mettent en lumière les échanges de messages entre
ces éléments pour accomplir une fonction avant la fin de la lifeline.

[Link] Diagrammes de séquence « Consulter statistiques »»

Le diagramme illustre la consultation des statistiques. Le responsable du management
qualité souhaite visualiser les statistiques des indicateurs associés aux processus du système
de management qualité d’université de jendouba, sous forme de graphiques. Le système
envoie les données à la base de données, puis récupère les statistiques dans le tableau de
bord, où ces graphiques sont affichés de manière dynamique.

80
6 CHAPITRE 6. SPRINT 4 :LES CAS DE PRIORITÉ 4

F IGURE 6.5 – Diagrammes de séquence «Consulter statistiques»

[Link] Diagramme de séquence « Consulter notifications »

Le diagramme illustre le processus de notification automatique lorsqu’un pilote de pro-
cessus ne remplit pas les indicateurs à la date spécifiée. Des e-mails automatiques sont en-
voyés aux pilotes de processus concernés. Ces e-mails contiennent une alerte pour remplir
les indicateurs à une date spécifiée.

81
6 CHAPITRE 6. SPRINT 4 :LES CAS DE PRIORITÉ 4

F IGURE 6.6 – Diagramme de séquence « Consulter notifications »

6.4.2 Diagrammes d’activités

Un diagramme d’activité est une représentation graphique d’un ensemble d’activités sys-
témiques procédurales exécutées, et il est considéré comme une variante du diagramme de
flux d’états. Les diagrammes d’activité décrivent les activités parallèles et conditionnelles,
les cas d’utilisation et les fonctions système à un niveau détaillé.

[Link] Diagramme d’activité «Consulter statistiques »

La figure suivante, nous présentons le diagramme d’activité de Consulter statistiques .

82
6 CHAPITRE 6. SPRINT 4 :LES CAS DE PRIORITÉ 4

F IGURE 6.7 – Diagramme d’activité «Consulter statistiques »

[Link] Diagramme d’activité «Consulter notifications »

La figure suivante, nous présentons le diagramme d’activité Consulter les notifications .

F IGURE 6.8 – Diagramme d’activité «Consulter notifications»

83
6 CHAPITRE 6. SPRINT 4 :LES CAS DE PRIORITÉ 4

6.5 Interface graphique

6.5.1 L’interface de Consulter les statisques
L’interface «dashboard» représentée par la figure ci-dessous :

F IGURE 6.9 – L’interface «dashboard»

6.6 Conclusion
Ce chapitre a traité divers aspects du quatrième sprint du projet. Nous avons débuté par
l’analyse et le raffinement des modèles des cas d’utilisation de priorité "4". Ensuite, nous
avons exposé la conception statique avec le diagramme de classe et le schéma relationnel.
La conception dynamique a été explorée à travers les diagrammes de séquence et d’activités.
Enfin, nous avons abordé la mise en œuvre en mettant l’accent sur les interfaces graphiques.
Ces étapes ont permis de faire avancer le développement du projet et de préparer la réalisa-
tion du troisième sprint.

84
6 CHAPITRE 6. SPRINT 4 :LES CAS DE PRIORITÉ 4

6.7 Diagramme de classe globale

L’interface «Diagramme de classe globale» représentée par la figure ci-dessous :

F IGURE 6.10 – L’interface «Diagramme de classe globale»

85
Conclusion générale

Ce rapport est le résultat de notre travail dans le cadre de notre projet de fin d’études en
licence fondamentale en informatique appliquée à la gestion.

Grâce à nos connaissances théoriques acquises pendant notre formation, nous avons conçu
et développé une solution web dédiée à la surveillance du système de management de la
qualité de l’Université de Jendouba.

Pour mener à bien ce projet, nous avons choisi la méthode Scrum comme approche de
développement, en utilisant l’UML comme langage de modélisation.

Notre application a été développée en Angular et [Link] avec Visual Studio comme en-
vironnement de développement, tandis que la base de données a été mise en place avec
MySQL.

Notre démarche a débuté par la présentation du cadre général du projet, suivi de la spé-
cification des besoins et de l’identification des acteurs pour garantir une conception solide.

Ensuite, nous avons procédé à l’implémentation et à la réalisation de chaque Sprint men-

tionné dans le Backlog du Produit, en suivant une architecture MVC claire et standardisée.

L’application que nous avons créée pour la surveillance du système de management de

la qualité vise à être pratique et efficace.

Elle simplifie et centralise les données, automatise les tâches répétitives et facilite la sur-
veillance des indicateurs liés à chaque processus.

En offrant aux responsables du management qualité un accès aux seuils des indicateurs et
un historique documentaire détaillé, notre application leur permet de prendre des décisions
éclairées et de mieux contrôler les processus.

Ce projet a été très bénéfique pour nous, car il nous a permis d’explorer un domaine pra-
tique, complexe et riche en procédures.

Il a également consolidé nos connaissances acquises à la faculté des sciences juridiques, éco-
nomiques et de gestion de Jendouba.

86
Bibliographie

[1] [Link]

[2] https ://[Link]/resources/what-scrum-module

[3] https ://[Link]/definition

[4] https ://[Link]/en-US/docs/Glossary/MVC

[5] https ://[Link]/Article/scrum-team

[6] https ://[Link]

[7] https ://[Link]

[8] https ://[Link]/docs

[9] https ://[Link]/définition

[10] https ://[Link]/définition

[11] https ://[Link]/définition

[12] https ://[Link]/définition

[13] https ://[Link]/blog/fr/uncategorized-fr/tutoriel-sur-les-diagrammes-de-classe/définition

[14] https ://[Link]/pages/fr/diagramme-de-sequence-uml

[15] https ://[Link]/pages/fr/diagramme-dactivite-uml

[16] https ://[Link]/fr/what-is-mysql/.

[17] https ://[Link]/

87