République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Stage de Fin d’Études

Présenté en vue de l’obtention du

diplôme national de licence appliquée en Sciences et Technologies

Mention : Informatique Industrielle
Spécialité : Systèmes Embarqués

Par

Tahar SASSI

Développement d’une application mobile de gestion

des ressources humaines

Encadrant professionnel : Mme Inaam BEN CHEHIDA

Encadrant académique : Mme Zohra CHANNOUF

Réalisé au sein de Centre National de l’Informatique

Année Universitaire 2020 - 2021

 République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Stage de Fin d’Études

Présenté en vue de l’obtention du

diplôme national de licence appliquée en Sciences et Technologies

Mention : Informatique Industrielle
Spécialité : Systèmes Embarqués

Par

Tahar SASSI

Développement d’une application mobile de gestion

des ressources humaines

Encadrant professionnel : Mme Inaam BEN CHEHIDA

Encadrant académique : Mme Zohra CHANNOUF

Réalisé au sein de Centre National de l’Informatique

Année Universitaire 2020 - 2021

J’autorise l’étudiant à déposer son rapport de stage en vue d’une soutenance.

Encadrant professionnel, Mme Inaam BEN CHEHIDA

Signature et cachet

J’autorise l’étudiant à déposer son rapport de stage en vue d’une soutenance.

Encadrant académique, Mme Zohra CHANNOUF

Signature
Dédicaces

Je dédie ce travail à :

À ma chère mère Naima, ma raison d’être, mon héroïne. Aucun hommage ne puisse
exprimer ma reconnaissance pour tous les énormes sacrifices qu’elle a fait pour moi,
À mon cher père Mohamed, mon idole, qui n’arrête jamais de se dévouer son temps et
ses efforts pour mon confort et l’achèvement de mes études et formation.
A mes soeurs sahar et nesrine avec qui je partage toutes mes sensations, sentiments
et souvenirs d’enfance.
À tous mes copains et copines du Club ArtBox qui m’ont été une famille solidaire tout
au long de ces années d’études universitaires et qui m’ont supporté et offert un soutien moral
dans des moments délicats. Avec eux, j’ai vécu des expériences merveilleuses et agréables.
À tous mes amis fidèles. Qu’ils apercevront dans ce projet le fruit de leurs supports et
encouragements durant toute la période précédente.

Tahar SASSI

ii
Remerciements

A l’occasion de cette présentation, je profite d’exprimer de tout mon coeur mes sincères
remerciements et mes grandes gratitudes aux personnes qui ont contribué, de prés ou de loin, à
mon succès dans mon cursus universitaire.
Tout d’abord, Monsieur Walid BOUDICHE, le chef département développement mobile, qui
a cru en moi et en mes compétences, qui m’a accueilli dans l’endroit de travail et qui m’a mis dans
le cadre de projet.
J’adresse aussi mes vifs remerciements à mon encadrante Madame Inaam Ben CHEHIDA
pour ses consultations importantes qui m’ont mis le pied à l’étrier, ainsi pour sa patience, sa
générosité et ses encouragements au cours des jours d’encadrement.
Pareillement, je tiens à exprimer mes grandes gratitudes à mon encadrante académique
Madame Zohra CHANNOUF pour son encadrement, ses conseils et ses directives, sa gentillesse
et son sens de responsabilité tout au long de la rédaction du rapport de stage.

iii
Table des matières

Introduction générale 1

1 Cadre du projet 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Création et forme juridique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 la méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.2 la méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Analyse et spécification des besoins 13

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Pilotage de projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Les rôles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 Acteurs de l’équipe Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

iv
 2.6 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.1 Architecture physique de la solution . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.2 Architecture logique de la solution . . . . . . . . . . . . . . . . . . . . . . . . 23
2.7 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 SPRINT 1 29
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . . . . . . . 31
3.2.2 Raffinement du cas d’utilisation
«Demander document administratif» . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 Raffinement du cas d’utilisation "Valider document administratif" . . . . . . 35
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Diagrammes de séquences systèmes . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Diagramme de classe du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4 Sprint 2 52
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1 Diagramme de cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . . . . . . 54
4.2.2 Raffinement du cas d’utilisation «Traiter demande» . . . . . . . . . . . . . . . 56
4.2.3 Raffinement du cas d’utilisation «Consulter données personnelles» . . . . . . 58
4.2.4 Raffinement du cas d’utilisation «Gérer utilisateur» . . . . . . . . . . . . . . . 60
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.1 Diagramme de séquences système . . . . . . . . . . . . . . . . . . . . . . . . . 64

v
 4.3.2 Diagramme de classe du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Conclusion générale 78

Bibliographie 79

vi
Table des figures

1.1 Logo de l’établissement CNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Formulaire de demande d’attestation de travail . . . . . . . . . . . . . . . . . . . . . 7
1.4 Interface de demande de congé (partie 1 ) . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Interface de demande de congé (partie 2) . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Cycle de vie Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Cycle de vie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

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

2.2 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Dart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9 Star UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 XAMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 Photoshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Diagramme de cas d’utilisation de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Raffinement du cas d’utilisation « Demander document administratif » . . . . . . . 33
3.3 Raffinement du cas d’utilisation «Valider document administratif » . . . . . . . . . . 35
3.4 Diagramme de séquence système du cas d’utilisation «S’authentifier » . . . . . . . . 37
3.5 Diagramme de séquence système du cas d’utilisation «Demander document administratif» 38
3.6 Diagramme de séquence système du cas d’utilisation «Valider document administratif» 39
3.7 Diagramme de classe de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Splash screen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9 Splash screen 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.10 Splash screen 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

vii
Table des figures

3.11 Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.12 Saisie de paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.13 Affichage message d’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.14 liste de fonctionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.15 liste d’agent DAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.16 liste d’administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.17 accueil de fonctionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.18 accueil d’agent DAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.19 accueil d’administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.20 formulaire de demande de congé partie 1 . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.21 formulaire de demande de congé partie 2 . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.22 sélecteur de date de congé de repos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.23 formulaire de demande d’attestation de travail . . . . . . . . . . . . . . . . . . . . . . 47
3.24 liste de demande de congé de repos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.25 informations sur demandeur de congé de repos . . . . . . . . . . . . . . . . . . . . . 48
3.26 liste de demandes d’attestation de travail (à valider) . . . . . . . . . . . . . . . . . . 49
3.27 informations sur demandeur d’attestation de travail . . . . . . . . . . . . . . . . . . . 49
3.28 notification (1) d’envoi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.29 notification (2) de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2 Raffinement du cas d’utilisation «Traiter demande» . . . . . . . . . . . . . . . . . . . 56
4.3 Raffinement du cas d’utilisation «Consulter données personnelles» . . . . . . . . . . 58
4.4 Raffinement du cas d’utilisation «Gérer utilisateurs» . . . . . . . . . . . . . . . . . . 60
4.5 Diagramme de séquence système du cas d’utilisation «Traiter document administratif» 64
4.6 Diagramme de séquence système du cas d’utilisation «Consulter données personnelles» 65
4.7 Diagramme de séquence système du cas d’utilisation «Ajouter d’utilisateur» . . . . . 66
4.8 Diagramme de séquence système du cas d’utilisation «Modifier utilisateur» . . . . . . 67
4.9 Diagramme de séquence système du cas d’utilisation «Supprimer utilisateur» . . . . 68
4.10 Diagramme de classe de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.11 liste de demandes d’attestation de travail . . . . . . . . . . . . . . . . . . . . . . . . 70
4.12 page de traitement d’attestation de travail . . . . . . . . . . . . . . . . . . . . . . . . 70

viii
4.13 panneau d’utilisateur (partie 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.14 panneau d’utilisateur (partie 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.15 formulaire de demande d’attestation de travail . . . . . . . . . . . . . . . . . . . . . . 72
4.16 appui sur l’icône d’ajout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.17 saisie de coordonnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.18 ajout effectué avec succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.19 appui sur l’icône de modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.20 modification de coordonnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.21 modification effectué avec succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.22 appui sur l’icône de suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.23 suppression effectué avec succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.24 notification d’envoi de document par e-mail . . . . . . . . . . . . . . . . . . . . . . . 76
4.25 document d’attestation de travail bien reçu en boite mail de demandeur . . . . . . . 76
4.26 document d’attestation de travail traité (en emulateur mobile) . . . . . . . . . . . . . 77
4.27 document d’attestation de travail traité (en format PDF) . . . . . . . . . . . . . . . 77

ix
Liste des tableaux

1.1 Tableau comparatif entre les méthodes classiques et les méthodes Agiles . . . . . . . 11

2.1 Acteurs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 correspondance entre l’estimation Fibonacci et les degrés de difficulté . . . . . . . . . 19
2.3 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Description de cas d’utilisation «S’authentifier» . . . . . . . . . . . . . . . . . . . . . 33
3.3 Description de cas d’utilisation «Demander document administratif» . . . . . . . . . 34
3.4 Description de cas d’utilisation «Valider demande» . . . . . . . . . . . . . . . . . . . 36

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.2 Description de cas d’utilisation «Traiter demande» . . . . . . . . . . . . . . . . . . . 57
4.3 Description de cas d’utilisation «Consulter données utilisateurs» . . . . . . . . . . . . 59
4.4 Description de cas d’utilisation «Ajouter utilisateur» . . . . . . . . . . . . . . . . . . 61
4.5 Description de cas d’utilisation «Supprimer utilisateur» . . . . . . . . . . . . . . . . 62
4.6 Description de cas d’utilisation «Modifier utilisateur» . . . . . . . . . . . . . . . . . . 63

x
Liste des abréviations

— API = Application Programming Interface

— AS = Attestation de Salaire

— AT = Attestation de Travail

— CNI = Centre National de L’informatique

— Cg = Congé de repos

— FP = Fiche de Paie

— MVC = Model View Controller

— SDDAF = Système de Demande de Documents Administratifs et Financiers

— UI = User Interface

xi
Introduction générale

L’informatique est devenue aujourd’hui un outil très important qui permet d’améliorer la
rentabilité et la productivité dans l’entreprise. En effet elle offre un gain de temps, une meilleure
visibilité sur le plan national et international.
La tendance courante des entreprises est de migrer l’informatisation de leur systèmes web ou desktop
vers les systèmes mobiles afin de rendre le flux de travail plus synchronisé, plus actif et plus
rapide. Cette migration vers le mobile est Justifiée en plusieurs raisons, nous mentionnons les plus
importantes.
D’une part, les applications mobiles améliorent la communication entre les employées à travers les
services de notification, aussi elles garantissent une meilleure performance (rapidité et fonctionnalité)
que les applications web.
D’autre part, les applications mobiles offrent une disponibilité totale à gérer les exigences de travail
critiques, à tout moment. Aucun problème de lieu ou temps d’utilisation d’applications mobiles tant
que la zone d’utilisation de smart phone est couverte par un réseau internet.
Pour suivre cette évolution technologique le centre national de l’informatique (CNI) a décidé de
réaliser une application mobile permettant de gérer les demandes des documents administratifs et
financiers de ses employés. Cette application va diminuer la charge de demandes sur le système de
gestion classique (site web) et offre un gain en temps et en ressources à la fois.
Notre sujet de fin d’études s’inscrit autour de cette nouvelle vision du CNI qui nous permettra de
satisfaire ses besoins et d’appliquer toutes les notions que nous avons appris durant nos trois ans
d’études.
Notre sujet vise à créer une application mobile de gestion des ressources humaines et plus spécifiquement
les demandes des congés et des documents administratifs tel que les attestations de travail.
Ce rapport présentera les différentes étapes de la réalisation de ce projet en 4 chapitre.
Le premier chapitre, intitulé «Cadre de projet», dédié pour la présentation de l’organisme d’accueil,
le sujet et la méthodologie de travail adoptée.
Le deuxième chapitre, intitulé «Analyse et spécification des besoins», est consacré à l’extraction
des différents besoins fonctionnels et non fonctionnels, la présentation de Backlog du produit et des
sprints, l’architecture de la solution et la mise en place de l’environnement matériel et logiciel.
les deux derniers chapitres 3 et 4,«Sprint 1 et 2» constituent le corps de notre rapport. Ces deux

1
Introduction générale

chapitres seront consacrés aux sprints planifiés en exposant pour chacun l’analyse,la conception,et
la réalisation à travers les interfaces graphiques.

2
 Chapitre 1

Cadre du projet

Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapitre 1. Cadre du projet

Introduction

Dans ce chapitre, nous allons mettre le travail dans son cadre général . D’abord nous allons
présenter l’organisme d’accueil où se déroulé le stage. Ensuite, nous allons introduire les limites de
l’application actuel et la solution proposé . Enfin , nous allons montrer la méthodologie adoptée lors
de la réalisation du notre projet.

1.1 Organisme d’accueil

le CNI représente un principal opérateur consacré en concrétisation, développement et configuration

des techniques, stratégies et systèmes informatiques propre aux entités et organismes étatiques.

1.1.1 Création et forme juridique

Institué le 30 Décembre 1975, le Centre National de l’Informatique est un établissement public

à caractère non administratif doté de la personnalité civile et de l’autonomie financière. Le CNI est
un organisme placé sous la tutelle du Ministre des Technologies de la Communication, et opérant
dans les domaines du secteur de l’informatique et des technologies de la communication et certifié
ISO 9001version 2015.[1]

Figure 1.1: Logo de l’établissement CNI

4
Chapitre 1. Cadre du projet

1.1.2 Missions

Comme principal appui aux structures publiques de l’administration dans la réalisation, le

déploiement et l’exploitation des systèmes d’information, le CNI assure les activités suivantes :

— Maîtrise d’ouvrage déléguée et Pilotage de projet.

— Audit de système d’information et faire l’étude d’opportunité, l’étude préalable et l’étude

organisationnelle.

— Élaboration des Cahiers des charges réseaux et sécurité Assistance à la réception et à l’installation
de réseaux.

— Développement et Maintenance des systèmes d’Informations.

— Hébergement des serveurs , des applications et des données avec ou sans exploitation.

— Assurer la continuité de fonctionnement des applications nationales en cas de sinistre.

— Réalisation des Formation sur les applications nationales et des Séminaires d’expertise.

— Déploiement et mise en oeuvre les applications développées pour le compte de l’administration

en vue de leur exploitation.

1.2 Étude de l’existant

l’étude de l’existant est une étude nécessaire qui nous aide à mieux comprendre le fonctionnement
et à découvrir les imperfections dans le système actuel afin de créer des solutions efficaces et plus
optimisées.

1.2.1 Description de l’existant

l’application existante présente un site web, ce site offre plusieurs services des demandes de
documents et ces services sont accessible aux tous fonctionnaires de CNI.
Aussi, nous trouvons l’unité de gestion et de traitement de demandes,accessible seulement aux agents
DAF (gestionnaire de documents).

5
Chapitre 1. Cadre du projet

Ce site est représenté par une interface utilisateur qui indique les modules suivants :

— Authentification.

— Services administratifs.

— Services financiers.

— Panneau utilisateur.

— Espace utilisateur.

Figure 1.2: Interface d’authentification

6
Chapitre 1. Cadre du projet

Figure 1.3: Formulaire de demande d’attestation de travail

Figure 1.4: Interface de demande de congé (partie 1 )

7
Chapitre 1. Cadre du projet

Figure 1.5: Interface de demande de congé (partie 2)

1.2.2 Critique de l’existant

lors de l’analyse de l’application web existante, nous avons observé plusieurs défaillances tels
que :

— La lenteur : si on résume la performance d’un site web, c’est la vitesse d’exécution de ses
fonctions. En effet, le site existant prend beaucoup de temps à démarrer et à fonctionner ce
qui est un grand inconvénient et désagréable pour l’utilisateur de cette application. Ce défaut
est présent car il existe un seul serveur web pour stocker toutes ces données. Au contraire,
notre application mobile sera plus performante car elle va stocker ses données sur deux espaces
mémoire (localement sur les mémoires des smart phones et externe sur le serveur web).

— L’absence d’information à propos de services offerts par le site existant.

— Le manque d’indicateur d’alertes : Lorsque nous faisons une saisie incorrecte des champs(nom,
prénom, adresse, mot de passe, e-mails, etc) aucun contrôle de saisie n’est fait. Cette absence
de contrôle n’aide pas l’utilisateur à corriger l’erreur..

— L’absence de notifications : les validateurs des demandes oublient souvent de voir la liste des
nouvelles demandes par la suite la demande sera bloquée, cet blocage peut impliquer des soucis
pour le demandeur.

8
Chapitre 1. Cadre du projet

— Il y a des modules et des sous modules qui présentent des défaillances a cause de défauts
techniques. les modules tels que :
— l’espace utilisateur et le panneau utilisateur.
les sous modules tels que :
— services financières (sous la module de services).
— demandes encore de traitement (sous modules de validation)

C’est pour cela qu’on trouve des erreurs fréquentes lors d’évaluation des salariés .
Par conséquent nous chercherons à développer une solution qui sera bien organisée et fonctionnelle
en utilisant des technologies et des services récents .

1.3 Solution

Afin de remédier ces défaillances, le CNI a choisit comme solution de développer une application
mobile qui compense et complète le site web. Bien entendu, cette application corrigera les lacunes du
ce site et réparera ses défauts, grâce au progrès continu et à l’évolution énorme de la programmation
mobile qui garantissent une bonne rapidité et une haute efficacité qui peut surpasser les propriétés
des sites web . D’une façon plus précise l’application mobile sera développée pour avoir : Une capacité
à envoyer (par fonctionnaire) et valider(par agent DAF) les demandes par leurs smart phones, dans
ou en dehors d’établissement, et à tout moment.
— Une facilité d’envoi les notifications et les alertes .
— Une fonctionnement plus rapide que le site web existant.
— Une personnalisation à meilleure entre les fonctionnaires et les agent DAF à l’échelle de tableau
de bord et selon leurs privilèges

1.4 Méthodologie de travail

Pour assurer un bon déroulement de travail, il faut choisir une méthodologie de travail bien
adapté.
Au niveau de cette partie nous allons présenté la méthodologie Agile, puis nous allons mentionner
l’une de ses méthodes appelé Scrum qui sera appliqué tout au long du projet.

9
Chapitre 1. Cadre du projet

1.4.1 la méthode Agile

La méthode Agile se base sur un cycle de développement qui porte le client au centre. Le
client est impliqué dans la réalisation du début à la fin du projet. Grâce à la méthode agile le
demandeur obtient une meilleure visibilité de la gestion des travaux qu’avec une méthode classique.
L’implication du client dans le processus permet à l’équipe d’obtenir un feedback régulier afin
d’appliquer directement les changements nécessaires. Cette méthode vise à accélérer le développement
d’un logiciel. De plus, elle assure la réalisation d’un logiciel fonctionnel tout au long de la durée de
sa création.[2]

Figure 1.6: Cycle de vie Agile

10
Chapitre 1. Cadre du projet

Tableau 1.1: Tableau comparatif entre les méthodes classiques et les méthodes Agiles

Thème Approche classique Approche Agile

Phases séquentielles permettant les Développement itératif et

Cycle de vie retours en arrière incrémental permettant des
(difficile en paramétrage) ajustements durant les sprints.

Prédictif : définie dès le début du

Adaptative tout au long du projet
Planification projet sur la base d’un périmètre et
en fonction es évolutions.
d’exigences stables

Changement invulnérable au changement. accepte le changement.

Gestion des Processus district et rigoureux de Gestion des risques intégrée dans le
risques gestion des risques. processus global.

Respect des engagements initiaux en

Satisfaction du client par la livraison
Mesure des succès termes de coûts, de budget et de
de valeur souhaitée.
niveau de qualité.

Équipe responsabilisée, ou
Équipe avec ressources spécialisés l’initiative et la communication
Équipe
dirigées par un chef de projet. sont privilégiées , soutenue par le
chef de projet.

Contrôle qualité à la fin de cycle de Contrôle qualité permanent au

Qualité
développement. niveau du produit et du processus

11
Chapitre 1. Cadre du projet

1.4.2 la méthode Scrum

Bien entendu, la méthode Scrum est conforme aux principes des méthodes agiles. Comme
toutes les méthodes agiles, Scrum privilégie la livraison rapide d’un prototype, opérationnel par
définition, afin que les clients, donneurs d’ordre et membres de l’équipe puissent l’évaluer. Cette
démarche participative active est un atout fondamental. Elle garantit pour le client le juste équilibre
entre l’investissement prévu et le produit finalement livré. L’étude du prototype permet l’évaluation
des fonctionnalités réalisées, et facilite la réflexion commune sur l’opportunité de futurs développements.
D’autre part, l’étroite intimité entre les clients utilisateurs et les prestataires développeurs facilite
l’appropriation future de l’outil.[3]

Figure 1.7: Cycle de vie Scrum

Conclusion

Ce chapitre a caractérisé une partie introductive de ce projet dans lequel on a présenté

d’abord l’organisme d’accueil, ensuite on a fait l’étude du projet qui décrit le site web existant et
ses défaillances. Enfin on a expliqué la méthodologie adoptée. Dans le chapitre suivant, nous allons
identifier les besoins fonctionnels et non fonctionnels , décrire le Backlog du produit et planifier les
sprints qu’on suivra tout au long du ce projet.

12
 Chapitre 2

Analyse et spécification des besoins

Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1 Pilotage de projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 17

4 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Chapitre 2. Analyse et spécification des besoins

Introduction

Ce chapitre représente une partie analytique ciblant à décortiquer les différentes phases de
notre projet et à interpréter et simplifier nos tâches. ainsi Elle vise à identifier, définir et exposer les
acteurs, le Backlog du produit et les différents besoins fonctionnels et non fonctionnels. Aussi elle
présente la planification des différents sprints. Aussi bien que ça, ce chapitre nous donne un bref
aperçu sur les technologies et les langages de programmation adoptés pour la mise en place de notre
projet.

2.1 Pilotage de projet avec Scrum

Dans cette étape , nous allons mentionner les parties principales de la méthodologie Scrum
en en définissant les taches et le Backlog du produit et la planification des sprints.

2.1.1 Les rôles Scrum

• Product owner (Le propriétaire du produit) : c’est le personne qui représente le client officiellement.
Il peut aussi joue le rôle de client et et d’utilisateur à la fois . comme rôle , il détermine, met en
ordre et transfère les fonctionnalités du produit les dans une liste du priorité et d’estimation
afin de charger le Backlog du produit.

• Scrum master(Le directeur de produit) : IL joue le rôle de coach ou formateur de l’équipe. c’est
le personne qui aide toute la groupe à apprendre les taches requis et avancer dans le travail ,
dans des meilleures conditions , en respectant chaque sprint.

• Scrum team(L’équipe de Scrum ) : c’est l’ensemble des personnes responsables à la construction

du projet défini par le propriétaire de produit. cette équipe est auto-organisée, garde un grand
degré d’autonomie .Aussi bien elle est responsable et disciplinée. Il est noter que l’équipe Scrum
doit livrer les fonctionnalités attendus à la fin de chaque sprint.

2.1.2 Acteurs de l’équipe Scrum

14
Chapitre 2. Analyse et spécification des besoins

Tableau 2.1: Acteurs du projet

Rôle Mission Acteur

définir les besoins et les

Product owner Walid BOUDICHE
fonctionnalités à développer

Scrum master évaluer et piloter le projet Inaam BEN CHEHIDA

réaliser la conception, le
Scrum team développement, les tests de Tahar SASSI
validation et le déploiement

2.2 Identification des besoins

Cette partie nous permet d’identifier différents besoins afin d’avancer correctement dans dans
l’achèvement de projet .

2.2.1 les besoins fonctionnels

les besoins fonctionnels représente les fonctionnalités qui sont évidentes dans l’application et
qu’on ne peuvent pas les ignorées en raison de leur valeur importante dans l’application.
Dans notre cas :
L’application doit permettre au fonctionnaire de :
- S’authentifier.
- Consulter les modules et les services.
- Envoyer une demande d’attestation de travail ou de congé de repos.
- Recevoir une première notification indiquant l’acceptation ou le rejet de la demande envoyée.
- Dans le cas d’acceptation de demande envoyée, recevoir le document demandé par e-mail et en
format PDF.
L’application doit permettre l’agent DAF de :
- S’authentifier
- Valider les demandes envoyées.
- Traiter les demandes validées.
- Avoir une alerte (rappel) s’il existe de(s) demande(s) non validée(s) ou non traitée(s).

15
Chapitre 2. Analyse et spécification des besoins

L’application doit permettre à l’administrateur de :

- S’authentifier.
- Gérer les utilisateurs.
Remarque : l’agent DAAF profite des tous les services spéciaux de fonctionnaires tels que la
demande de document, la consultation de panneau ou d’espace d’utilisateur. Il faut noter qu’un
agent DAAF ne peut ni valider ni traiter ses propres demandes.

2.2.2 Les besoins non fonctionnels

Les besoins non fonctionnels présentent toutes les contraintes auxquelles sont soumis le
système pour garantir son bon fonctionnement. Parmi ces besoins, nous citons :

• Disponibilité

L’application sera évidement accessible et disponible à :

- n’importe quel jour et heure, en considérant les week-ends, les vacances, et les périodes de maintenance.
- n’importe quel espace couvert par le réseau internet.

• Sécurité

Puisque notre application emmagasine des données confidentielles tels que : adresse, e-mail, mot de
passe, numéro de CIN, Identifiant unique. Toutes ces informations seront protégées.

• Performance

Comme toute applications mobile, notre application a un système de stockage de données

divisé entre serveur et mémoire de l’appareil qui assure une récupération des données techniquement
plus rapide que le site web. Ce système nous offre un performance élevée.

• Portabilité et compatibilité

Notre application doit être portable, fonctionnelle et compatible sur les différents appareils
(Samsung, iPhone, OPPO, etc) et avec les plus important systèmes d’exploitation mobiles de monde
(Android et iOS).

• Ergonomie

L’ergonomie couvre plusieurs éléments tels que la densité d’éléments sur les écrans, la disposition
et le flux, l’Interface Utilisateur et les couleurs. Bien évidement tous ces éléments seront, claires,
simples et agréables.

16
Chapitre 2. Analyse et spécification des besoins

2.3 Modélisation des besoins fonctionnels

Le diagramme de cas d’utilisation est une représente graphiquement accès simple qui aide
toutes les participants dans le travail à comprendre leurs projet . En effet , c’est une modélisation
des interactions entre les utilisateurs et le système, il nous donne une vision globale du fonctionnel
du système en décrivant les besoin , pointant sur les grandes fonctions et identifiant les acteurs.

2.3.1 Identification des acteurs du système

les acteurs désignent les entités externes qui interagissent avec le système. Comme réponse
à l’action d’acteur, le système fournit un service qui couvert ses besoins. Notre application contient
deux acteurs :

• Fonctionnaire : C’est l’acteur qui envoi des demandes , en cas de besoin , aussi bien qu’il peut
consulter le panneau et l’espace d’utilisateur .

• Agent DAF : C’est l’acteur qui valide et traite les demandes des fonctionnaires, nous devons
également mentionner que l’agent DAAF ainsi que ses privilèges, il possède tous les privilèges
de fonctionnaire.

• Administrateur : C’est le responsable de la gestion personnel. son rôle est présenté en ajout,
suppression ou modification d’utilisateur (agent DAAF ou fonctionnaire).

17
Chapitre 2. Analyse et spécification des besoins

2.3.2 Diagramme des cas d’utilisation global

Le diagramme de cas d’utilisation est un diagramme global résume les fonctionnalités de

notre système.

Figure 2.1: Diagramme de cas d’utilisation global

2.4 Backlog du produit

C’est le pilier le plus important de la méthodologie Scrum, il présente l’ensemble des caractéristiques
fonctionnelles appelées des histoires utilisateurs (user storys) qui comporte le produit souhaité. Dans
le tableau ci-dessous , on exprime les champs du Backlog :

• ID : désigne un nombre unique pour chaque user story.

• Histoire Utilisateur (User story) : présente la phrase qui décrit le travail désiré,

• La Priorité : c’est une caractéristique représente l’ordre de réalisation des tâches.

• L’estimation : c’est une caractéristique désigne le degré de difficulté des tâches .

l’estimation adopté de notre système est calculé en fonction de la suite Fibonacci.

18
Chapitre 2. Analyse et spécification des besoins

Tableau 2.2: correspondance entre l’estimation Fibonacci et les degrés de difficulté

Nombre Fibonacci Degré difficulté
2 très facile
3 facile
5 moyenne
8 difficile
13 très difficile

Tableau 2.3: Backlog du produit

Id Thème Histoire utilisateur Priorité Estimation

En tant que fonctionnaire, agent DAF ou

1 Authentification. administrateur je veux m’authentifier afin 1 8
d’accéder à l’application.

En tant que fonctionnaire je veux

Demande de document
2 demander un document administratif 1 5
administratif.
(attestation de travail, congé de repos).

En tant que fonctionnaire je veux

Demande de document
3 demander une document financier 1 5
financier.
(attestation de salaire, fiche de paie).

En tant que agent DAF je veux recevoir

Activation de
4 une notification quand une nouvelle 2 5
notification (1).
demande est envoyée.

En tant que Agent DAF je veux accepter

Validation de document
5 ou refuser la demande de document 1 5
administratif.
administratif envoyée.

En tant que Agent DAF je veux accepter

Validation de document
6 ou refuser la demande de document 1 5
financier.
financier envoyée.

En tant que fonctionnaire je veux recevoir

Activation de
7 une notification indiquant l’acceptation ou 2 5
notification (2).
le refus de mon demande.

En tant que Agent DAF je veux traiter le

Traitement de
8 document administratif validé et l’envoyer 1 8
document administratif.
au demandeur par e-mail.
19
Chapitre 2. Analyse et spécification des besoins

Id Thème Histoire utilisateur Priorité Estimation

En tant que Agent DAF

je veux traiter le document
9 Traitement de document financier. 1 8
financier validé et l’envoyer au
demandeur par e-mail.

En tant que fonctionnaire je

veux recevoir une notification
10 Activation de notification (3). 2 5
indique que ma demande est
traité et envoyé en boite mail.

En tant que fonctionnaire je

Consultation de données personnelles veux consulter mes données
11 2 3
(partie 1) : Panneau utilisateur. personnelles (statistiques de
demandes).

En tant que fonctionnaire je

Consultation de données personnelles veux suivre l’état de mes
12 2 3
(partie 2) : Espace utilisateur. demandes (refusée, acceptée
ou en attente)

Gestion du personnel partie 1 : En tant que administrateur je

13 2 5
Ajout. veux ajouter d’utilisateur.

Gestion du personnel partie 2 : En tant que administrateur je

14 2 5
Suppression veux supprimer d’utilisateur.

Gestion du personnel partie 3 : En tant que administrateur je

15 2 5
Modification. modifier d’utilisateur.

2.5 Planification des sprints

Notre projet est découpé en trois sprint . Le tableau 2.3 définit pour chaque histoire utilisateur
(user story) l’itération durant laquelle était effectué.

20
Chapitre 2. Analyse et spécification des besoins

Tableau 2.4: Planification des sprints

Sprint 0 Sprint 1 sprint 2

01/02/2021 –> 27/02/2021 01/03/2021 –> 27/03/2021 01/04/2021 –> 27/04/2021

Traitement de document
Mise en contexte du projet. Authentification.
administratif.
Traitement de document
financier.

Etude de site web Demande de document

Activation notification (3).
existant. administratif.

Consultation de données
Formation en méthodologie de Demande de document
personnelles (partie 1) :
travail adopté. financier.
- Panneau utilisateur.

Mise en place de Consultation de données

l’environnement de travail Activation de notification (1). personnelles (partie 2) :
matériel. - Espace utilisateur.

Mise en place de Gestion du personnel

Validation de document
l’environnement de travail (partie 1) :
administratif.
logiciel. - Ajouter utilisateur.

Gestion du personnel
Validation de document
Planification de sprint 1. (partie 2) :
financier.
- Supprimer utilisateur.

Gestion du personnel
Planification de sprint 2. Activation de notification (2). (partie 3) :
- Modifier utilisateur.

2.6 Architecture de la solution

Après avoir montré les grandes lignes de phase de spécification de besoins, nous mettons
l’accent ,dans cette partie , sur l’architecture physique et logique de la solution.

21
Chapitre 2. Analyse et spécification des besoins

2.6.1 Architecture physique de la solution

Les applications mobiles nécessitent d’être évolutif à causes du changement du besoin. Pour
cela mettre en place une architecture est un besoin vital. Le système est conçu selon l’architecture 3
tiers qui est composée de 3 couches indépendantes les unes des autres : couche présentation, couche
traitement, couche base de données. Ce modèle assure la flexibilité, la sécurité et une meilleure
performance puisque les taches sont partagées. Comme le montre la figure ci-dessous, Dans cette
architecture on distingue :

La figure ci-dessous présente l’architecture physique n-tiers de notre application.

Figure 2.2: Architecture physique

22
Chapitre 2. Analyse et spécification des besoins

• Couche présentation : c’est la partie visible et interactive de point de vue utilisateur qui
représente l’application Mobile SDDAF. Elle envoie les requêtes à la couche traitement selon
les actions exécuter par l’utilisateur. Puis elle prend en charge l’affichage des informations
reçus. Dont sa création est basée sur le langage DART.
La couche présentation permet d’avoir une interaction entre le serveur et l’utilisateur en
assurant une communication avec les autres couches à travers l’API.

• Couche traitement : Correspond à la partie fonctionnelle du système. Elle implémente la

logique métier et applique les règles de gestion des interactions. Cette couche comporte les
objets et contrôles nécessaires pour répondre aux requêtes de la couche présentation. Elle
représente le serveur d’application chargé de fournir les ressources à la couche présentation en
faisant appel au serveur de base de données.

• Couche de données : Elle représente le serveur de base de données qui fournit au serveur
d’application les données dont il a besoin.[4]

2.6.2 Architecture logique de la solution

L’architecture logique de notre application c’est l’architecture MVC (Modele-View-Controller).

C’est une approche de conception de systèmes informatiques qui se caractéristique par l’ensemble
des avantages suivantes :
-Rapidité du développement
-Facilité d’évolution
-Facilité de maintenance
-Clarté du code
MVC est un pattern d’architecture logicielle très répondu et très utilisé qui intervient comme une
solution pour la réalisation d’une application. Il permet de faciliter les taches de développements en
séparant les données(modèle), de l’affichage(vue), des actions (Contrôleur). Cela permet d’avoir une
application évolutif facile à comprendre, à gérer et flexible pour des changements ultérieurs.

23
Chapitre 2. Analyse et spécification des besoins

La figure 2.3 ci-dessous présente les composants de l’architecture MVC et résume les interactions
entre elles.

Figure 2.3: Architecture MVC

• Modèle : c’est la partie de l’application qui met en œuvre la logique de l’application de données
de domaine. Elle représente les données dans notre application.

• Vues : c’est l’élément qui affiche l’interface utilisateur (UI). C’est en fait un utilisateur qui
consomme les web APIs.

• contrôleur : c’est un composant qui gère l’interaction avec l’utilisateur, travaille avec le modèle
et, finalement, sélectionne la vue qui va permettre de faire un rendu de l’interface utilisateur.[5]

2.7 Environnement de travail

Dans cette étape de ce projet , nous représentons l’environnement matériel et logiciel de

travail.

2.7.1 Environnement matériel

Pour la conception et la réalisation de ce projet, nous allons spécifier l’environnement matériel

utilisé.

24
Chapitre 2. Analyse et spécification des besoins

Tableau 2.5 : Environnement matériel

Fabriquant Hp

Processeur Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz 2.90 GHz

Ram 8,00 Go

Systeme d’exploitation Microsoft Windows 10 (64 bits)

2.7.2 Environnement logiciel

Cette partie est dédié à la présentation des logiciels et outils utilisés lors de la réalisation de
notre projet.
Visual Studio Code : Éditeur de code extensible supporte plusieurs de langages de
programmation comme C/C++ Html/Css/Java script et Dart la langage avec laquelle notre application
était développée.

Figure 2.4: Visual Studio Code

Dart : langage de programmation optimisé pour les applications sur plusieurs plateformes. Il est
développé par Google et est utilisé pour créer des applications mobiles, de bureau, de serveur et
web.[6]

Figure 2.5: Dart

25
Chapitre 2. Analyse et spécification des besoins

Flutter : Kit de développement de logiciel (SDK) d’interface utilisateur open-source créé par
Google. Il est utilisé pour développer des applications pour Android, iOS, Linux, Mac, Windows,
Google Fuchsia et le web à partir d’une seule base de code.[7]

Figure 2.6: Flutter

MySQL : c’est un Système de Gestion de Bases de Données Relationnelles (SGBDR) basé

sur le modèle client-serveur.[8]

Figure 2.7: MySQL

PHP : langage de programmation libre, impératif et orienté objet,

principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP, mais pouvant
également fonctionner comme n’importe quel langage interprété de façon locale.[9]

Figure 2.8: PHP

26
Chapitre 2. Analyse et spécification des besoins

StarUML : Logiciel de modélisation UML (Unified Modeling Language) open source ce

logiciel constitue une excellente option pour une familiarisation à la modélisation.[10]

Figure 2.9: Star UML

XAMPP : c’est un ensemble de logiciels permettant de mettre en place un serveur web local,
un serveur FTP et un serveur de messagerie é[Link] s’agit d’une distribution de logiciels libres
(X (cross) Apache MariaDB Perl PHP) offrant une bonne souplesse d’utilisation, réputée pour son
installation simple et rapide.[11]

Figure 2.10: XAMPP

Photoshop : Photoshop est un logiciel de retouche, de traitement et de dessin assisté par ordinateur,
lancé en 1990 sur MacOS puis en 1992 sur Windows. Édité par Adobe, il est principalement
utilisé pour le traitement des photographies numériques, mais sert également à la création ex nihilo
d’images.[12]

Figure 2.11: Photoshop

27
Chapitre 2. Analyse et spécification des besoins

Conclusion

Dans ce chapitre nous avons détaillé la méthodologie que nous avons opté pour notre application
à savoir les membres de l’équipe de travail, définie les besoins fonctionnel et non fonctionnels, le
diagramme de cas d’utilisation global, le Backlog de produit et la planification des sprints pour finir
avec l’environnement du travail et l’architecture de l’application. Le chapitre suivant est dédié pour
les travaux effectués durant le premier sprint.

28
 Chapitre 3

SPRINT 1

Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Chapitre 3. SPRINT 1

Introduction

Ce chapitre présente les travaux effectués durant le premier sprint. Pour cela, nous spécifions,
dans un premier lieu, le Backlog de sprint. Nous passons par suite à une phase de spécification
fonctionnelle et une phase de conception. Enfin, nous présentons quelques interfaces réalisés au
cours du ce sprint.

3.1 Backlog du sprint 1

Après avoir planifié les sprints dans le premier chapitre, nous présentons dans cette partie
le Backlog de sprint 1. C’est une liste qui réunit toutes les histoires utilisateur à développer et les
tâches à réaliser.

30
Chapitre 3. SPRINT 1

3.2 Spécification fonctionnelle

Dans cette phase , nous exposons le diagramme de cas d’utilisation générale ainsi que le
raffinement de ses cas. Nous traduisons par suite nos diagrammes de cas d’utilisation par des
descriptions textuelles.

3.2.1 Diagramme de cas d’utilisation du sprint 1

Le diagramme de cas d’utilisation suivant résume les besoins fonctionnels à réaliser pendant ce sprint.

Figure 3.1: Diagramme de cas d’utilisation de sprint 1

31
Chapitre 3. SPRINT 1

Tableau 3.1: Backlog du sprint 1

estimation
Id user story Id tache tache priorité
(par jours)
En tant que fonctionnaire, Développer le module
1.1 1 3
1 agent DAF ou administrateur d’authentification.
je veux m’authentifier afin
1.2 Test et validation. 2 1
d’accéder à l’application.
Développer les
En tant que fonctionnaire
interfaces appropriés
je demander un document 1.1 1 3
2 (page d’accueil, liste de
administratif tels que :
services, formulaires)
- l’attestation de travail.
1.2 Test et validation. 2 1
- le congé de repos.
Développer les
En tant que fonctionnaire je
interfaces appropriés
veux demander un document 1.1 1 3
3 (page d’accueil, liste de
financier tels que :
services, formulaires)
- l’attestation de salaire.
1.2 Test et validation. 2 1
- la fiche de paie.
Développer une fonction
qui renvoie au agent
En tant que Agent DAF je veux
DAF, une notification
recevoir de notification s’il y a 1.1 1 2
4 quand il y a une
une nouvelle demande envoyée.
nouvelle demande
envoyée.
1.2 Test et validation. 2 1
En tant que Agent DAF Développer le module
je veux valider la demande de validation de
1.1 1 3.5
5 de document administratif demandes de documents
envoyée. administratifs.
1.2 Test et validation. 2 1
Développer le module
En tant que Agent DAF je
de validation de
veux valider la demande de 1.1 1 3.5
6 demandes de documents
document financier envoyée.
financiers.
1.2 Test et validation. 2 1
Développer une
En tant que fonctionnaire je fonction qui renvoie
veux recevoir une notification au demandeur, la
1.1 1 2
7 indiquant l’acceptation ou le décision d’agents DAF
refus de ma demande. (acceptation ou refus)
de ma demande.
1.2 Test et validation. 2 1

32
Chapitre 3. SPRINT 1

Tableau 3.2: Description de cas d’utilisation «S’authentifier»

Titre : S’authentifier

Le fonctionnaire, l’agents DAF ou

Résumé l’administrateur s’authentifie pour accéder à
l’application.

Acteur : Fonctionnaire / agent DAF / administrateur

Description des enchaînements

Pré condition Post condition

L’utilisateur doit être créé dans la base de données

et connaît ses paramètres identifiants en tant que Affichage de la page d’accueil.
fonctionnaire, agent DAF ou administrateur.

Scénario nominal :

1.L’utilisateur saisie ses paramètres d’identification et clique sur « Se connecter » .

[Link] système vérifie les informations saisies par l’utilisateur, puis il affiche la page d’accueil.

Scénario alternative :

2.a [paramètre(s) d’identification incorrect(s)] : Le système affiche un message d’erreur et redemande

les paramètres. Reprise à l’étape 1 du scénario nominal.

3.2.2 Raffinement du cas d’utilisation

«Demander document administratif»

Figure 3.2: Raffinement du cas d’utilisation « Demander document administratif »

33
Chapitre 3. SPRINT 1

Tableau 3.3: Description de cas d’utilisation «Demander document administratif»

Titre : Demander document administratif
Le fonctionnaire demande une attestation de
Résumé
travail ou un congé de repos.
Acteur : fonctionnaire
Description des enchaînements
Pré condition Post condition
le fonctionnaire est authentifié. Demande envoyé.
Scénario nominal :
[Link] fonctionnaire sélectionne les services des demandes administratives.
[Link] système affiche les types des demandes administratives.
[Link] fonctionnaire choisit le type de demande (attestation de travail, fiche de paie).
[Link] système affiche le formulaire spécifique au demande choisie.
[Link] fonctionnaire remplit les champs de formulaire correctement.
[Link] fonctionnaire clique sur le bouton "Envoyer demande".
[Link] système vérifie les champs de formulaire.
[Link] système assure le contrôle de saisie.
[Link] la demande pour profiter un congé de repos.
Le système affirme le droit de fonctionnaire à profiter un congé de repos.
(Il faut que le nombre de jours de congé restant de travail ne dépasse une seule pas pendant le trois
derniers mois).
[Link] système affiche le message "Demande envoyée".
[Link] système enregistre la demande dans la base de données.
[Link] système envoie une notifications au agent DAF, indiquant qu’il y a une demande administratives
envoyées.
Scénario alternatif :
[Link] fonctionnaire saisit des données incorrects par rapport au contrôle de saisie du formulaire.
[Link] système affiche un message d’erreur indique que les données saisies sont incorrects. Reprise
à l’étape 3 du scénario nominal.
[Link] système affiche un message d’erreur indique que le nombre de jours de congés restants est
moins de nombre de limite (3 jours) pour avoir un congé de repos.

34
Chapitre 3. SPRINT 1

3.2.3 Raffinement du cas d’utilisation "Valider document administratif"

Figure 3.3: Raffinement du cas d’utilisation «Valider document administratif »

35
Chapitre 3. SPRINT 1

Tableau 3.4: Description de cas d’utilisation «Valider demande»

Titre : Valider document administratif

l’agents DAF valide la demande de document

Résumé
administratif par l’acceptation ou le refus.

Acteur : agent DAF

Description des enchaînements

Pré condition Post condition

Il existe au moins une demande envoyé dans la liste de

Demande validé.
demandes de statut en attente.

Scénario nominal :

1.L’agent DAF lire la demande et la valide par clique sur «Accepter» ou «Refuser» .
[Link] système envoie une notifications au demandeur (fonctionnaire ou agent DAF) , indiquant la
décision concernant leur demande (acceptation ou refuse).

3.3 Conception

La conception est une phase primordiale dans la réalisation d’une application qui nous donne
une meilleur vision sur son fonctionnement . Pour cela ,nous présentons dans cette section les
diagrammes de séquences systèmes des cas d’utilisations déjà décrites textuellement .Ensuite nous
présentons le diagramme de classe de sprint 1 .

36
Chapitre 3. SPRINT 1

3.3.1 Diagrammes de séquences systèmes

Diagramme de séquence système du cas d’utilisation « s’authentifier»

Figure 3.4: Diagramme de séquence système du cas d’utilisation «S’authentifier »

37
Chapitre 3. SPRINT 1

Diagramme de séquence système du cas d’utilisation

«Demander document administratif»

Figure 3.5: Diagramme de séquence système du cas d’utilisation «Demander document

administratif»

38
Chapitre 3. SPRINT 1

Diagramme de séquence système du cas d’utilisation

«Valider document administrative»

Figure 3.6: Diagramme de séquence système du cas d’utilisation «Valider document

administratif»

39
Chapitre 3. SPRINT 1

3.3.2 Diagramme de classe du Sprint 1

Dans cette partie nous présentons le diagramme de classe de sprint 1, la figure suivante
représente le diagramme relatif au développement du premier sprint :

Figure 3.7: Diagramme de classe de sprint 1

40
Chapitre 3. SPRINT 1

3.4 Réalisation

Dans cette section du chapitre nous allons présenter les interfaces réalisées durant le premier
sprint.

• Splashs screens : Ces figures représentent les écrans de démarrage qui contient des informations
à propos de notre application, ses fonctions et services.

Figure 3.8: Splash screen 1 Figure 3.9: Splash screen 2 Figure 3.10: Splash screen 3

41
Chapitre 3. SPRINT 1

• Login screen : cette figure représente l’interface d’authentification de notre application "SDDAF".

Figure 3.11: Login Screen

42
Chapitre 3. SPRINT 1

• Contrôle de saisie : ces figure représentent le cas ou les paramètres d’identification sont
incorrects.

Figure 3.12: Saisie de paramètres Figure 3.13: Affichage message d’erreur

43
Chapitre 3. SPRINT 1

• Interfaces : Ces figure représentent les interfaces et les listes des fonctions d’utilisateurs selon
leurs rôles (fonctionnaire, agent DAF, administrateur).

Figure 3.14: liste de Figure 3.15: liste d’agent Figure 3.16: liste
fonctionnaire DAF d’administrateur

44
Chapitre 3. SPRINT 1

• écrans d’accueil d’utilisateurs : ces figure représentent les écrans d’accueil d’utilisateurs
selon leurs rôles (fonctionnaire, agent DAF, administrateur)

Figure 3.17: accueil de Figure 3.18: accueil d’agent Figure 3.19: accueil
fonctionnaire DAF d’administrateur

45
Chapitre 3. SPRINT 1

• formulaire (1) : ces figure représentent la formulaire de demande de congé de repos.

Figure 3.20: formulaire de Figure 3.21: formulaire de Figure 3.22: sélecteur de date
demande de congé partie 1 demande de congé partie 2 de congé de repos

46
Chapitre 3. SPRINT 1

• formulaire(2) : cette figure représente la formulaire de demande d’attestation de travail.

Figure 3.23: formulaire de demande d’attestation de travail

47
Chapitre 3. SPRINT 1

• Interfaces de validation de congé de repos : ces figures représentent la liste de demandes

de congés à valider et l’interface d’informations sur demandeur.

Figure 3.24: liste de demande de congé de Figure 3.25: informations sur demandeur de
repos congé de repos

48
Chapitre 3. SPRINT 1

• Interfaces de validation d’attestation de travail : ces figures représentent la liste de

demandes d’attestation de travail à valider et l’interface d’informations sur demandeur.²

Figure 3.26: liste de demandes d’attestation Figure 3.27: informations sur demandeur
de travail (à valider) d’attestation de travail

49
Chapitre 3. SPRINT 1

• Service de notification : ces figures représentent la notification (1) envoyée au agent DAF
dans le cas d’envoi d’une nouvelle demande et la notification (2) envoyée au fonctionnaire dans
le cas d’acceptation de cette demande de document.

Figure 3.28: notification (1) d’envoi Figure 3.29: notification (2) de validation

50
Chapitre 3. SPRINT 1

Conclusion

Dans ce chapitre, nous avons présenté le développement de notre premier sprint en commençant
par l’analyse et la conception de nos besoins fonctionnelles pour arriver à l’étape de la réalisation.

51
 Chapitre 4

Sprint 2

Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Chapitre 4. Sprint 2

Introduction

Dans ce chapitre nous allons présenter les travaux effectués pendant le deuxième sprint,
c’est pour ça que nous allons suivre les mêmes étapes du premier sprint pour implémenter les
cas d’utilisation "traiter document administratif", "Consulter données personnelles", et "Gérer
utilisateurs", nous commençons par une présentation du Backlog du sprint.

4.1 Backlog du sprint

Nous présentons dans cette partie du deuxième sprint le Backlog du sprint qui définie
l’ensemble des taches à déterminer.

53
Chapitre 4. Sprint 2

4.2 Spécification fonctionnelle

Nous présentons dans cette partie les différentes fonctionnalités à réaliser dans ce sprint sous
forme de diagrammes de cas d’utilisation .

4.2.1 Diagramme de cas d’utilisation du Sprint 2

Dans cette partie on va présenter le diagramme de cas d’utilisation à avoir dans ce deuxième
sprint .
Le diagramme de cas d’utilisation suivant montre les cas à avoirs durant ce deuxième sprint.

Figure 4.1: Diagramme de cas d’utilisation du sprint 2

54
Chapitre 4. Sprint 2

Tableau 4.1: Backlog du sprint 2

estimation
Id user story Id tache tache priorité
(par jours)
En tant que agent DAF
Développer le module
je traiter le document
1.1 de traitement de 1 3
1 administrative et l’envoyer
document administratif.
au demandeur par e-mail.
(document en format PDF). 1.2 Test et validation. 2 1
En tant que agent DAF je
Développer le module
traiter le document financier
1.1 de traitement de 1 3
2 et l’envoyer au demandeur par
document financier.
e-mail.
(document en format PDF). 1.2 Test et validation. 2 1
Développer une
En tant que fonctionnaire je
fonction qui renvoie
veux recevoir de notification
1.1 au fonctionnaire, une 1 2
3 indique que ma demande était
notification quand son
traitée.
demande était traitée.
1.2 Test et validation. 2 1
En tant que fonctionnaire je
veux consulter mes données Développer le panneau
1.1 1 3
4 personnelles qui contient les d’utilisateur.
statistiques de mes demandes
(panneau utilisateur). 1.2 Test et validation. 2 1
En tant que fonctionnaire je
veux consulter mes données
Développer l’espace
personnelles qui contient les 1.1 1 3
5 d’utilisateur financière.
états de mes demandes :
acceptée, refusée , en attente .
(espace utilisateur). 1.2 Test et validation. 2 1
Développer la partie 1
En tant que Administrateur je
1.1 de module de gestion du 1 2
6 veux ajouter un utilisateur
personnel (add user).
(fonctionnaire ou agent DAF). 1.2 Test et validation. 2 1
Développer la partie 2
En tant que Administrateur je
1.1 de module de gestion du 1 2
7 veux supprimer un utilisateur.
personnel (delete user).
(fonctionnaire ou agent DAF). 1.2 Test et validation. 2 1
Développer la partie 3
En tant que administrateur je
1.1 de module de gestion du 1 2
8 veux modifier un utilisateur.
personnel (edit user).
(fonctionnaire ou agent DAF). 1.2 Test et validation. 2 1

55
Chapitre 4. Sprint 2

4.2.2 Raffinement du cas d’utilisation «Traiter demande»

Figure 4.2: Raffinement du cas d’utilisation «Traiter demande»

56
Chapitre 4. Sprint 2

Tableau 4.2: Description de cas d’utilisation «Traiter demande»

Titre : Traiter demande administrative

L’agent traite valide une attestation de travail

Résumé ou un congé de repos.
(demande administrative).

Acteur : agent DAF

Description des enchaînements

Pré condition Post condition

1.L’utilisateur est authentifié en tant que agent DAF.

[Link] existe au moins une demande dans la liste de Demande traitée et envoyée au demandeur.
demandes administratives validées.

Scénario nominal :

1.L’agent DAF sélectionne la liste demandes de administratives validée.

[Link] système affiche la liste de demandes administratives validée .
3.L’agent DAF sélectionne la demande souhaitée à traiter.
[Link] système affiche la formulaire de traitement.
5.L’agent DAF remplit les champs de formulaire de traitement.
6.L’agent DAF clique sur le bouton "Traiter et Envoyer document" pour l’envoyer au demandeur par
e-mail.
[Link] système vérifie les champs de traitement.
7.1Le système assure le contrôle de saisie.
[Link] système envoie une notification au fonctionnaire, indiquant que sa demande administrative est
traitée et envoyée en boite mail.

Scénario alternatif :

7.A.L’agent DAF saisit des données incorrects par rapport au contrôle de saisie du formulaire de
traitement.
[Link] système affiche un message d’erreur indique que les données saisies sont incorrects. Reprise
à l’étape 4 du scénario nominal.

57
Chapitre 4. Sprint 2

4.2.3 Raffinement du cas d’utilisation «Consulter données personnelles»

Figure 4.3: Raffinement du cas d’utilisation «Consulter données personnelles»

58
Chapitre 4. Sprint 2

Tableau 4.3: Description de cas d’utilisation «Consulter données utilisateurs»

Titre : Consulter panneau d’utilisateur

En tant que fonctionnaire ou agent DAF,

je veux consulter mes données personnelles
Résumé
tels que les statistiques ou les états de mes
demandes (panneau ou espace d’utilisateur)

Acteur : Fonctionnaire / agent DAF

Description des enchaînements

Pré condition Post condition

L’utilisateur est authentifié en tant que fonctionnaire

Affiche de données personnels.
ou agent DAF.

Scénario nominal :

1.L’utilisateur clique sur «Données personnelles» pour l’accède.

[Link] système affiche la liste de page de données personnelles (Panneau utilisateur ou Espace
utilisateur).
3.L’utilisateur choisit la page de données qui souhaite la consulter. (Panneau utilisateur ou Espace
utilisateur).
[Link] système affiche la page de données personnelles sélectionnée.

59
Chapitre 4. Sprint 2

4.2.4 Raffinement du cas d’utilisation «Gérer utilisateur»

Figure 4.4: Raffinement du cas d’utilisation «Gérer utilisateurs»

60
Chapitre 4. Sprint 2

Tableau 4.4: Description de cas d’utilisation «Ajouter utilisateur»

Titre : Ajouter utilisateur

En tant que Administrateur, je veux ajouter

Résumé
de(s)utilisateur(s)

Acteur : Administrateur

Description des enchaînements

Pré condition Post condition

L’utilisateur est authentifié en tant que Utilisateur ajouté

administrateur. (fonctionnaire ou agent DAF) .

Scénario nominal :

1.L’administrateur clique sur "Gestion du personnel".

[Link] système affiche la liste d’utilisateur.
3.L’administrateur clique sur le bouton d’ajout "Add Icon".
[Link] système affiche le formulaire d’ajout.
5.L’administrateur remplit les champs du formulaire d’ajout et clique sur le bouton "Ajouter".
[Link] système assure le contrôle de saisie de formulaire d’ajout.
[Link] système enregistre le nouveau utilisateur dans la table d’utilisateurs de base de données et affiche
le message "utilisateur ajouté".

Scénario alternatif :

5.A.L’administrateur saisit des données incorrects par rapport au contrôle de saisie du formulaire
d’ajout.
[Link] système affiche un message d’erreur indique que les données saisies sont incorrects. Reprise à
l’étape 4 du scénario nominal.

61
Chapitre 4. Sprint 2

Tableau 4.5: Description de cas d’utilisation «Supprimer utilisateur»

Titre : Supprimer utilisateur

En tant que Administrateur, je veux

Résumé
supprimer de(s)utilisateur(s)

Acteur : Administrateur

Description des enchaînements

Pré condition Post condition

1.L’utilisateur est authentifié en tant que

administrateur. Utilisateur supprimé
[Link] existe au moins un utilisateur dans la table (Fonctionnaire ou Agent DAF).
d’utilisateurs dans la base de données

Scénario nominal :

1.L’administrateur clique sur "Gestion du personnel".

[Link] système affiche la liste d’utilisateur.
3.L’administrateur clique sur le bouton de suppression "Delete Icon".
[Link] système supprime l’utilisateur de la table d’utilisateurs de base de données et affiche le message
"utilisateur supprimé".

62
Chapitre 4. Sprint 2

Tableau 4.6: Description de cas d’utilisation «Modifier utilisateur»

Titre : Modifier utilisateur

En tant que Administrateur, je veux ajouter,

Résumé
supprimer ou modifier de(s)utilisateur(s)

Acteur : Administrateur

Description des enchaînements

Pré condition Post condition

1.L’utilisateur est authentifié en tant que

administrateur.
Utilisateur modifié.
[Link] existe au moins un utilisateur dans la table
d’utilisateurs dans la base de données

Scénario nominal :

1.L’administrateur clique sur "Gestion du personnel".

[Link] système affiche la liste d’utilisateur.
3.L’administrateur clique sur le bouton d’ajout "Edit Icon".
[Link] système affiche le formulaire de modification.
5.L’administrateur modifier les champs du formulaire de modification et clique sur le bouton
"Modifier".
[Link] système assure le contrôle de saisie de formulaire de modification.
[Link] système enregistre la modification d’utilisateur dans la table d’utilisateurs de base de données
et affiche le message "utilisateur modifié".

Scénario alternatif :

5.A.L’administrateur saisit des données incorrects par rapport au contrôle de saisie du formulaire
d’ajout.
[Link] système affiche un message d’erreur indique que les données saisies sont incorrects. Reprise à
l’étape 4 du scénario nominal.

63
Chapitre 4. Sprint 2

4.3 Conception

Dans cette partie de conception, nous présentons les diagrammes de séquence détaillés des
fonctionnalité de ce deuxième sprint.

4.3.1 Diagramme de séquences système

Diagramme de séquence système du cas d’utilisation

«Traiter document administratif»

Figure 4.5: Diagramme de séquence système du cas d’utilisation «Traiter document administratif»

64
Chapitre 4. Sprint 2

Diagramme de séquence système du cas d’utilisation

«Consulter données personnelles»

Figure 4.6: Diagramme de séquence système du cas d’utilisation «Consulter données personnelles»

65
Chapitre 4. Sprint 2

Diagramme de séquence système du cas d’utilisation

«Ajouter d’utilisateur»

Figure 4.7: Diagramme de séquence système du cas d’utilisation «Ajouter d’utilisateur»

66
Chapitre 4. Sprint 2

Diagramme de séquence système du cas d’utilisation

«Modifier d’utilisateur»

Figure 4.8: Diagramme de séquence système du cas d’utilisation «Modifier utilisateur»

67
Chapitre 4. Sprint 2

Diagramme de séquence système du cas d’utilisation

«Supprimer utilisateur»

Figure 4.9: Diagramme de séquence système du cas d’utilisation «Supprimer utilisateur»

68
Chapitre 4. Sprint 2

4.3.2 Diagramme de classe du Sprint 2

Nous allons présenter dans la figure suivante le diagramme de classe relatif au développement
de deuxième sprint :

Figure 4.10: Diagramme de classe de sprint 2

69
Chapitre 4. Sprint 2

4.4 Réalisation

Dans cette section du chapitre , nous montrons quelques interfaces réalisées durant le deuxième
sprint .

• Interfaces de traitement d’attestation de travail : ces figures représentent la liste de

demandes de congés à traiter et l’interface de traitement de document.

Figure 4.11: liste de demandes d’attestation Figure 4.12: page de traitement d’attestation
de travail de travail

70
Chapitre 4. Sprint 2

• Interface de données personnelles (panneau utilisateur) : ces figures représentent les

illustrations graphique à propos la validation de demandes de documents.

Figure 4.13: panneau d’utilisateur (partie 1) Figure 4.14: panneau d’utilisateur (partie 2)

71
Chapitre 4. Sprint 2

• Interface de données personnelles (Espace utilisateur) : cette figure représente la liste

annuelle de demandes de documents administratifs validés.

Figure 4.15: formulaire de demande d’attestation de travail

72
Chapitre 4. Sprint 2

• Ajouter utilisateur : ces figures représentent les figures d’ajout d’un utilisateur
( fonctionnaire ou agent DAF).

Figure 4.16: appui sur l’icône Figure 4.17: saisie de Figure 4.18: ajout effectué
d’ajout coordonnées avec succès

73
Chapitre 4. Sprint 2

• Modifier utilisateur : ces figures représentent les figures de modification d’un utilisateur
( fonctionnaire ou agent DAF).

Figure 4.19: appui sur l’icône Figure 4.20: modification de Figure 4.21: modification
de modification coordonnées effectué avec succès

74
Chapitre 4. Sprint 2

• Supprimer utilisateur : ces figures représentent les figures de suppression d’un utilisateur
(fonctionnaire ou agent DAF).

Figure 4.22: appui sur l’icône de suppression Figure 4.23: suppression effectué avec succès

75
Chapitre 4. Sprint 2

• service de notification : ces figures représentent la notification (3) envoyée au fonctionnaire

dans le cas ou leur document a été traité et la vérification de la boite mails.

Figure 4.24: notification d’envoi de document Figure 4.25: document d’attestation de

par e-mail travail bien reçu en boite mail de demandeur

76
Chapitre 4. Sprint 2

• exemple de document administratif : ces figures représentent le document d’attestation

de travail fournisse par l’application.

Figure 4.27: document d’attestation de

travail traité (en format PDF)

Figure 4.26: document d’attestation de

travail traité (en emulateur mobile)

Conclusion

Dans ce présent chapitre, nous avons développé le deuxième sprint, nous avons donc réussi à
avoir le dernier sprint à livrer.

77
Conclusion générale

Dans le cadre de sujet de fin d’étude, nous avons conçu et réalisé une application mobile de
gestion des ressources humaines au sein de l’établissement de centre national de l’informatique pour
les fonctionnaires de CNI en se basant sur la méthodologie itérative Scrum.
L’application , appelée SDDAF, propose des fonctionnalités riches et un meilleur service au fonctionnaires.
Elle englobe plusieurs modules. En fait, nous avons développer une application mobile, qui nous à
permis de demander les documents administratifs, financiers, et de consulter le panneau et l’espace
d’utilisateur. Comme étant notre première réelle expérience dans le domaine de développement
mobile.
Lors de ce stage nous avons pu mettre en pratique nos connaissances théoriques acquises durant notre
formation à l’Institut Supérieur d’Informatique, tout en étant vécu la cohérence entre les membres
d’équipes et confronté les difficultés réelles du monde du travail.
Par ailleurs, nous avons découvrir, tout au long du stage, la vie professionnelle au sein de centre
national de l’informatique qui nous a mis dans un cadre professionnel afin d’améliorer notre esprit
d’analyse, de décision et de réflexion. En outre, au niveau des perspectives futures, nous pouvons
développer la présente application réalisé pour les fonctionnaires de CNI, pour être utilisable pour
tout les fonctionnaires publiques dans le domaine des gestion de ressources humaines.

78
Bibliographie

[1] (). « Création et forme juridique de CNI. » [Accès le 12-Février-2021], adresse : [Link]
[Link]/[Link]/fr/layout-3/presentation-du-cni-2.

[2] (). « Principe de base de la méthode Agile. » [Accès le 13-Février-2021], adresse : https :
//[Link]/actualites/2015/01/methodes-agiles-definition/.

[3] (). « Principes de la méthode Scrum. » [Accès le 13-Février-2021], adresse : [Link]

[Link]/projet/methode/[Link]#:~:text=Bien.

[4] (). « Architecture physique de la solution. » [Accès le 18-Février-2021], adresse : [Link]

/Users/MediaStudio/Downloads/pfe123.

[5] (). « Architecture logique de la solution. » [Accès le 19-Février-2021], adresse : [Link]

/Users/MediaStudio/Desktop/[Link].

[6] (). « Dart (langage). » [Accès le 22-Février-2021], adresse : https : / / fr . wikipedia . org /
wiki/Dart_(langage).

[7] (). « Flutter (logiciel). » [Accès le 22-Février-2021], adresse : [Link]

wiki/Flutter_(logiciel).

[8] (). « MySQL. » [Accès le 22-Février-2021], adresse : https : / / openclassrooms . com / fr /

courses/1959476-administrez-vos-bases-de-donnees-avec-mysql/1959710-decouvrez-
mysql.

[9] (). « PHP. » [Accès le 22-Février-2021], adresse : [Link]

[10] (). « StarUML. » [Accès le 22-Février-2021], adresse : [Link]

php?file=2014/01/[Link].

[11] (). « XAMPP. » [Accès le 22-Février-2021], adresse : https : / / fr . wikipedia . org / wiki /
XAMPP.

[12] (). « Adobe Photoshop. » [Accès le 22-Février-2021], adresse : [Link]

wiki/Adobe_Photoshop.

79
 PÌl›
 wkt§ .Ayw˜wnkt˜ ¤ wl`˜ ¨ TyqybWt˜ ­EA¯ Ylˆ šwOl˜ ®ˆ²˜ ¨nVw˜ z•rm˜ ™ ™m`˜ @¡ EAž œ
T§rKb˜ C wm˜A Tql`tm˜ Tfltm˜ r}An`˜ ­C  Ÿ› Ty˜Am˜ ¤ T§C ³  dntsm˜ lV A\ž Ymsm˜ Š¤rKm˜
TŒ˜  dtF œ d’¤ .Ÿy›dtsm˜ ­C ¤ dtsm˜ ºAS ¤ Tw˜ fO¤ , Ty˜Am˜ ¤ T§C ³  dntsm˜ lV ™›
.Š¤rKm˜ r§wW ¤ T›r ™
Ÿ› ŕdF r® Åw" C Å T›rb˜
—dF r® , C : yAf› Aml•

Résumé
Ce travail a été réalisé au sein de centre national de l’informatique et ce pour l’obtention du
Diplôme National de Licence Appliquée en Sciences et Technologies. Le projet nommé Système
de demande de documents administratifs et financiers, consiste à gérer les différents éléments
liés aux ressources humaines tel que la demande de documents administratifs et financiers,la
consultation de panneau et d’espace d’utilisateur, et l’administration d’utilisateurs.
Cette solution utilise le langage de programmation DART et en exploitant le SDK Flutter.

Mots clés : DART , SDK Flutter

Abstract
This work was carried out within the national computer center to obtain the National Diploma
of Applied License in Sciences and Technologies. The project called System of request for ad-
ministrative and financial documents, consists of manage the various elements related to human
resources such as the request for administrative and financial documents, the consultation of
panel and user space, and user administration. This solution uses the language of DART pro-
gramming and leveraging the Flutter SDK.

Keywords : DART , SDK Flutter

contact@[Link] : ¨ž¤rtk˜¯ d§rb˜ 71 222 222 : H•Af˜ 71 111 111 : Ah˜ Hžw - ­ryb˜ ‘AfR -   C®› ­ry hž
Rue du Lac Malaren, Les Berges du Lac 1053 Tunis Tél : 71 111 111 Fax : 71 222 222 Email : contact@[Link]
isi@[Link] : ¨ž¤rtk˜¯ d§rb˜ 71 706 698 : H•Af˜ 71 706 164 : Ah˜ TžA§C
2080 ¨ž¤CAb˜  A§r˜ w
hž 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@[Link]