REPUBLIQUE TUNISIENNE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITE DE JENDOUBA

FACULTE DES SCIENCES JURIDIQUES, ECONOMIQUES ET GESTION DE

JENDOUBA

DEPARTEMENT D’INFORMATIQUE

Projet De Fin D’études

Présenté en vue de l’obtention du

Diplôme De Licence en Informatique Appliquée à la Gestion (Business Computing)

Spécialité : Electronic business

TITRE
Conception et réalisation d’une application
de facturation d’eau
Réalisé par : Ilhem Kahlaoui

Encadrant pédagogique : Dr. Chaker katar Encadrant professionnel : Hosni Aloui

Année Universitaire 2022/2023

 Dédicaces
A mes chers parents,
Que nulle dédicace ne puisse exprimer ce que je leurs dois,
Pour leur bienveillance, leur affection et leur soutien...
Trésors de bonté, de générosité et de tendresse, en
Témoignage de mon profond amour et ma grande
Reconnaissance « Que Dieu vous garde ».

A tous mes amis,

Pour leur aide et leur soutien moral durant
L’élaboration du stage.

A toute ma Famille…

A tous mes amis…

A tous ceux qui m'aiment.

 Remerciements
Je tiens tout d’abord à remercier, toute l’équipe Pédagogique
de la FSJEGJ et les intervenants professionnels Responsable de
stage CRDA.

Mes remerciements vont également à mon encadrant Monsieur

Chaker katar pour L’aide et les conseils concernant les missions
évoquées dans ceRapport, Il a partagé avec moi ses
connaissances et ses expériences dans ce domaine.

Mes profondes reconnaissances vont également aux membres du jury pour

avoir accepté d’examiner mon ouvrage.
Table des matières
Introduction générale...................................................................................................................... 1
Chapitre1 : présentation de projet.......................................................................................................... 1
Introduction ......................................................................................................................................... 2
1.1 Présentation de la société ................................................................................................... 2
1.1.1 Présentation du CRDA ................................................................................................. 2
1.1.2 Organigramme............................................................................................................. 2
1.1.3 Les divisions de CRDA : ................................................................................................ 4
1.2 Présentation de projet ........................................................................................................ 4
1.2.1 Etude de l’existant ....................................................................................................... 4
1.2.2 Problématique ............................................................................................................. 4
1.2.3 Solution........................................................................................................................ 4
1.3 Méthodologie de projet :..................................................................................................... 4
1.3.1 Méthodes classiques : .................................................................................................. 4
1.3.2 Méthodes Agiles : ........................................................................................................ 5
1.3.3 Méthode SCRUM : ....................................................................................................... 5
1.4 La méthode adaptée :.......................................................................................................... 7
1.5 Le langage approuvé (UML) :............................................................................................... 8
Conclusion........................................................................................................................................... 8
Chapitre2 : analyse et spécification des besoins..................................................................................... 9
Introduction ......................................................................................................................................... 9
1.1 Analyse des besoins............................................................................................................. 9
1.1.1 Identification des acteurs ............................................................................................ 9
1.2 Spécification des besoins .................................................................................................. 10
1.2.1 Besoins fonctionnels.................................................................................................. 10
1.2.2 Besoins non fonctionnels .......................................................................................... 11
1.3 Diagramme des cas d’utilisation globale ........................................................................... 11
1.4 Backlog produit................................................................................................................. 13
1.5 Planification des sprints .................................................................................................... 14
1.5.1 Structuration de projet en sprints ............................................................................. 14
1.5.2 Diagramme de Gantt ................................................................................................. 15
1.6 Architecture générale de l’application .............................................................................. 15
1.6.1 Architecture logicielle................................................................................................ 15
1.6.2 Architecture matérielle ............................................................................................. 16
 1.7 Environnement de travail .................................................................................................. 17
1.7.1 Environnement matériel ........................................................................................... 17
1.7.2 Environnement de développement .......................................................................... 17
Conclusion......................................................................................................................................... 19
Chapitre 3 : Étude et réalisation du Sprint 1 ......................................................................................... 20
Introduction ....................................................................................................................................... 20
1.1 Backlog de produit de sprint 1 .......................................................................................... 20
1.2 Spécification Fonctionnelle :.............................................................................................. 21
1.3 Diagramme de cas d’utilisation global de sprint 1 ............................................................ 21
1.4 Conception des cas d’utilisation ........................................................................................ 31
1.4.1 Diagramme de classe d’analyse ................................................................................ 31
1.4.2 Diagramme de classe d’analyse d’authentification................................................... 31
1.4.3 Diagramme de séquences ......................................................................................... 31
1.4.4 Diagramme de séquence authentification ................................................................ 32
1.4.5 Diagramme de classe d’analyse « gérer borne »...................................................... 32
1.4.6 Diagramme de séquence « ajouter borne ».............................................................. 33
1.4.7 Diagramme de séquence « modifier borne » ........................................................... 34
1.4.8 Diagramme de séquence « supprimer borne » ........................................................ 35
1.4.9 Diagramme de classe d’analyse « gérer client » ....................................................... 35
1.4.10 Diagramme de séquence « ajouter client » ................................................................ 36
1.4.11 Diagramme de séquence « modifier client » ........................................................... 37
1.4.12 Diagramme de séquence « supprimer client »......................................................... 37
1.4.13 Diagramme de classe d’analyse « gérer utilisateur » .............................................. 38
1.4.14 Diagramme de séquence « ajouter utilisateur » ....................................................... 38
1.4.15 Diagramme de séquence « consulter utilisateur »................................................... 39
1.4.16 Diagramme de séquence « modifier utilisateur » .................................................... 39
1.4.17 Diagramme de séquence « supprimer utilisateur » .................................................. 40
1.5 Les interfaces graphiques du sprint 1................................................................................ 40
Conclusion......................................................................................................................................... 42
Chapitre 4 : Étude et réalisation du Sprint 2 ......................................................................................... 43
Introduction ....................................................................................................................................... 43
1.1 Backlog produit de sprint 2 ............................................................................................... 43
1.2 Spécification Fonctionnelle................................................................................................ 43
1.3 Diagramme de cas d’utilisation global de sprint 2 ............................................................ 43
1.4 Conception des cas d’utilisation ........................................................................................ 46
1.4.1 Diagramme de classe d’analyse « paiement » .......................................................... 46
 1.4.2 Diagramme de séquence «paiement» ...................................................................... 47
1.4.3 Diagramme de classe d’analyse du cas d’utilisation « valider paiement » ............... 47
1.4.4 Diagramme de séquence «valider paiement» .......................................................... 48
1.4.5 Diagramme de classe d’analyse du cas d’utilisation « facturation »......................... 48
1.4.6 Diagramme de séquence «facturation» .................................................................... 49
1.5 Les interfaces graphiques du sprint 2................................................................................ 49
Conclusion......................................................................................................................................... 51
Chapitre 5 : Etude et réalisation de sprint 3 ......................................................................................... 52
Introduction ....................................................................................................................................... 52
1.1 Backlog produit de sprint 3 ............................................................................................... 52
1.2 Spécification Fonctionnelle................................................................................................ 52
1.3 Diagramme de cas d’utilisation global de sprint 3 ............................................................ 52
1.4 Conception des cas d’utilisation ........................................................................................ 53
1.4.1 Diagramme de classe d’analyse du cas d’utilisation « suivi consommation » ......... 53
1.4.2 Diagramme de séquence « suivi consommation ».................................................... 54
1.5 Les interfaces graphiques de sprint 3 ................................................................................ 54
1.6 Diagramme de classe global .............................................................................................. 55
Conclusion......................................................................................................................................... 55
Conclusion générale ...................................................................................................................... 56
Bibliographie.................................................................................................................................. 57
 Liste des figures
Figure 1 : logo de CRDA ........................................................................................................................... 2
Figure 2 : Organigramme de L’Organism ............................................................................................... 3
Figure 3 : fonctionnement de SCRUM .................................................................................................... 6
Figure 4 : Comparaison entre méthodes agiles et méthodes classiques ................................................ 7
Figure 5 : Langage UML ......................................................................................................................... 8
Figure 6 : Diagramme de cas d'utilisation général ................................................................................ 12
Figure 8 : Diagramme de Gantt ............................................................................................................ 15
Figure 9 :l’architecture logicielle .......................................................................................................... 16
Figure 10 : Architecture matérielle........................................................................................................ 16
Figure 11 : Logo visual paradigm.......................................................................................................... 17
Figure 12 : Logo de l’outil Angular......................................................................................................... 17
Figure 13 : Logo de l’outil Bootstrap ..................................................................................................... 18
Figure 14 : Logo visuel studio code ........................................................................................................ 18
Figure 15 : Logo Word .......................................................................................................................... 18
Figure 16 : Logo node JS ....................................................................................................................... 18
Figure 17 : Logo Mongo DB .................................................................................................................. 19
Figure 18 : Logo TeamGantt ................................................................................................................. 19
Figure 19 : Diagramme de cas d’utilisation global de sprint 1 .............................................................. 21
Figure 20 : Diagramme raffiné du cas d’utilisation « s’authentifier »..................................................... 22
Figure 21 : Diagramme raffiné du cas d’utilisation « gérer utilisateur » ................................................ 23
Figure 22 : Diagramme raffiné du cas d’utilisation «gérer client » ........................................................ 26
Figure 23 : Diagramme raffiné du cas d’utilisation «gérer borne» ......................................................... 28
Figure 24 : Diagramme de classe d’analyse « authentification » .......................................................... 31
Figure 25 : Diagramme de séquence « authentification » ...................................................................... 32
Figure 26 : Diagramme de classe d’analyse « gérer borne » ................................................................. 32
Figure 27 : Diagramme de séquence « ajouter borne ».......................................................................... 33
Figure 28 : Diagramme de séquence « modifier borne » ...................................................................... 34
Figure 29 : Diagramme de séquence « supprimer borne » .................................................................... 35
Figure 30 : Diagramme de classe d’analyse « ajouter client » .............................................................. 35
Figure 31 : Diagramme de séquence « ajouter client » ......................................................................... 36
Figure 32 : Diagramme de séquence «modifier client »........................................................................ 37
Figure 33 : Diagramme de séquence « supprimer client » .................................................................... 37
Figure 34 : Diagramme de classe d’analyse « gérer utilisateur » ......................................................... 38
Figure 35 : Diagramme de séquence « ajouter utilisateur » .................................................................. 38
Figure 36 : Diagramme de séquence « consulter utilisateur ».............................................................. 39
Figure 37 : Diagramme de séquence « modifier utilisateur »................................................................ 39
Figure 38 : Diagramme de séquence « supprimer utilisateur » ............................................................. 40
Figure 39 : capture de base de données ................................................................................................. 41
Figure 40 : Interface s’authentifier ........................................................................................................ 41
Figure 41 : Interface ajouter borne ........................................................................................................ 42
Figure 42 : Diagramme de cas d’utilisation global de sprint 2 .............................................................. 43
Figure 43 : Diagramme raffiné du cas d’utilisation «paiement » .............................................................. 44
Figure 44: Diagramme raffiné du cas d’utilisation «valider paiement »...................................................... 44
Figure 45 : Diagramme raffiné du cas d’utilisation «facturation » ............................................................ 45
Figure 46 : Diagramme de classe d’analyse « paiement » .................................................................... 46
Figure 47 : Diagramme de séquence « paiement »................................................................................ 47
Figure 48: Diagramme de classe d’analyse du cas d’utilisation« valider paiement» ............................ 47
Figure 49: diagramme de séquence « valider paiement » ..................................................................... 48
Figure 50 : Diagramme de classe d’analyse du cas d’utilisation « facturation » .................................. 48
Figure 51 : capture de bade de données................................................................................................. 50
Figure 52 : Interface facturation ............................................................................................................ 51
Figure 53 : Interface valider paiement.................................................................................................. 51
Figure 54 : Diagramme de cas d’utilisation global de sprint 3 .............................................................. 52
Figure 55: Diagramme de classe d’analyse « suivi consommation » .................................................... 53
Figure 56 : Diagramme de séquence «suivi consommation» ................................................................ 54
Figure 57 : Interface suivi consommation ............................................................................................. 54
Figure 58 : Diagramme de classe globale.............................................................................................. 55

Liste des tableaux

Tableau 1 : Identification des acteurs ...................................................................................................... 9
Tableau 2 : Backlog de produit ............................................................................................................. 14
Tableau 3 : Planification des sprints ...................................................................................................... 15
Tableau 4 : Backlog produit de sprint 1 ................................................................................................ 21
Tableau 5 : Description de cas d’utilisation « s’authentifier » .............................................................. 22
Tableau 6 : Description de cas d’utilisation « Ajouter utilisateur » ...................................................... 23
Tableau 7 : Description de cas d’utilisation « consulter utilisateur » .................................................... 24
Tableau 8 : Description de cas d’utilisation « modifier utilisateur » .................................................... 25
Tableau 9 : Description de cas d’utilisation « supprimer utilisateur» .................................................. 25
Tableau 10 : Description de cas d’utilisation « modifier client » ......................................................... 26
Tableau 11 : Description de cas d’utilisation « supprimer client »....................................................... 27
Tableau 12 : Description de cas d’utilisation « Ajouter client » ........................................................... 27
Tableau 13 : Description de cas d’utilisation «consulter client » .......................................................... 28
Tableau 14 : Description de cas d’utilisation « Ajouter borne » ........................................................... 29
Tableau 15 : Description de cas d’utilisation « Ajouter borne » ........................................................... 29
Tableau 16 : Description de cas d’utilisation « modifier borne».......................................................... 30
Tableau 17 : Description de cas d’utilisation « supprimer borne» ....................................................... 31
Tableau 18 : Backlog produit de sprint 2 .............................................................................................. 43
Tableau 19 : Description de cas d’utilisation « facturation » ................................................................ 46
Tableau 20 : Description de cas d’utilisation « paiement» .................................................................... 44
Tableau 21 : Backlog produit de sprint 3 .............................................................................................. 52
Tableau 22 : Description de cas d’utilisation « suivi consommation » ................................................. 53
 Introduction générale

Avec le progrès scientifique dans plusieurs et divers domaines, les solutions apportées par les
technologies de l’informatique et de la communication s’avèrent de plus en plus
incontournables et urgentes. De même, l’informatique est une discipline à la mode, très variée
et très riche, elle est devenue indispensable dans tous les domaines étant donné ses avantages
majeurs.

Les outils informatiques sont plus en plus appliqués dans la plupart des domaines de la vie
professionnelle et privée. Elle occupe bien évidemment une grande place dans la plupart des
domaines de gestion agricole.

C’est dans ce contexte s’intègre notre projet de fin d’études, qui a pour objectif la mise en
place d’une solution permettant de facturer l’eau dans le Commissariat Régional au
Développement Agricole Jendouba.

Notre rapport se compose de cinq chapitres divisé comme suit :

 Chapitre1 : ce chapitre sera consacré tout d’abord à la présentation de l’entreprise au

sein du quel le projet set effectué, par la suite les objectifs et les avantages de notre
application.
 Chapitre 2 : dans ce chapitre nous avons l’intérêt de présenter les différents acteurs de
notre projet, les besoins fonctionnels ainsi que les besoins non fonctionnels, la
planification du projet ainsi que la planification de sprint.
 Chapitre 3 : le troisième chapitre se concentre sur la réalisation du premier sprint du
projet tel que le Backlog de produit, les spécifications fonctionnelles, la conception et
des interfaces graphiques du sprint 1.
 Chapitre 4 : le quatrième chapitre se concentre sur la réalisation du deuxième sprint
du projet tel que le Backlog, les spécifications fonctionnelles, la conception et des
interfaces graphiques du sprint 2.
 Chapitre 5 : le cinquième chapitre se concentre sur la réalisation du troisième sprint
du projet tel que le Backlog, les spécifications fonctionnelles, la conception et des
interfaces graphiques du sprint 3.

Enfin, nous concluons le rapport par une conclusion générale.

1
 Chapitre1 : présentation de projet
Introduction
Dans ce chapitre, nous allons définir le cadre du projet en déterminant tout d’abord la
problématique. Ensuite, on va la critiquer et proposer les solutions apportées à ces problèmes.
L’analyse et le critique de l’existant nous ont permis de cerner nos objectifs afin de
développer un système de qualité dans le futur. Par la suite, nous expliquons le choix de la
méthode de conception la plus adéquate à notre projet.

1.1 Présentation de la société

1.1.1 Présentation du CRDA

Le Commissariat Régional au Développement Agricole (CRDA) est un établissement public à

caractère administratif doté de la personnalité morale et de l’autonomie financière. Il est créé
par la loi n°89-44 du 8 mars 1989 portant création des Commissariats Régionaux au
Développement Agricole.

Figure 1 : logo de CRDA

1.1.2 Organigramme
La figure 2 illustre l’organigramme général du CRDA qui comporte cinq divisions. Chaque
division comprend des arrondissements tels que chaque arrondissement contient ses propres
activités.

2
 Direction générale
du CRDA

Division de la Division de Division du Division des études Division des Unité diverse
vulgarisation et de l’hydraulique et de reboisement et de et du affaires relèvent du CRDA
la production l’équipement rural la protection des développement administratives et
agricole sols agricole financières

Arrondissement de Arrondissement des Arrondissement des Arrondissement du Unité par objectif

Arrondissement études et des Barrage Barbara
la production forets Jendouba personnel
du génie rural statistiques
végétale
agricoles
Arrondissement des Unité par objectif
Arrondissement Barrage Zargua
Arrondissement des forets Ain Draham
financier
Arrondissement de
ressources en eau
la production
animale Arrondissement de
Arrondissement des Cellule informatique
Arrondissement de la conservation des
bâtiments et du Mr Hosni Aloui
l’exploitation des eaux et de sol
Arrondissement du matériel
périmètres irrigue
financement et des
encouragements Arrondissement des
Arrondissement de sols
la maintenance des Bureau technique
Unité de équipements
coordination des
activités de
vulgarisation Arrondissement
pêche

Unité céréale
Figure 2 : Organigramme de L’Organisme

3
1.1.4 Les divisions de CRDA :
Division vulgarisation et promotion à la production agricole

Division Reboisement et protection des sols

Division Etudes et Développement Agricole

Division affaires Administratives et Financières

Division Hydraulique et Equipement Rural

1.2 Présentation de projet

1.2.1 Etude de l’existant

La Commissariat Régional au Développement Agricole Jendouba est une société dotée de
plusieurs services et un ensemble des activités. Lors de notre étude de l’existant et à partir de
mes observations on a réalisé qu’il existe plusieurs contraintes. J’ai remarqué aussi qu’il
existe un système de facturation avec le langage vb.net ce qui engendre nombreuses
difficultés.

1.2.2 Problématique
L’étude de l’existant a permis de dégager un certain nombre de problème qu’on présentera ci-
dessous :

 Difficultés de recherche et d’accès à l’information.

 Un niveau moyen d’organisation des informations.
 Des graphiques en texte brut.

1.2.3 Solution
Après une étude minutieuse et attentive, on s’est trouvé dans l’obligation de chercher une
solution pour surmonter la perte des données et les différents points critiques qui s’appuient
sur une base de données en créant une application client-serveur.

1.3 Méthodologie de projet :

1.3.1 Méthodes classiques :

Les méthodes classiques on a un aspect séquentiel de plusieurs étapes successive, et
dépend des résultats de la phase précédents.les étapes de projet est sont résumés comme suit :
 Cahier de charge

4
  Réalisation
 Test
 Mise en production
Parmi ces méthodes de projet on a : modèle en cascade, Le modèle en v.

1.3.2 Méthodes Agiles :

La méthode agile est une méthodologie de gestion de projet et de développement la plus
utilisées dans les entreprises. Il permet d’effectuer un pilotage plus sécurisée, car plus régulier
de chef de projet. Alors que le découpage en sprints courts donne une meilleure visibilité du
respect du planning et de la gestion des risques. En d’autre terme, la méthode agile sera
mieux adoptée lorsque la rapidité et le principal critère de succès, elle permet une grande
réactivité à ses demandes et une prise de décision plus rapide. Cette méthode repose un cycle
de développement itératif.
Parmi ces méthodes de projet on a : Rational Unified Process (RUP) et SCRUM.

1.3.3 Méthode SCRUM :

SCRUM est un cadre de travail pour le développement et la maintenance de produits
complexes.il se compose de plusieurs éléments que sont l’Équipe SCRUM et ses rôles
associés, les événements, les artéfacts et les règles. Chaque élément a une raison d’être
spécifique qui le rend indispensable à la réussite de l’application de SCRUM.

 Les événements de SCRUM :

 Le sprint planning : C’est une réunion de SCRUM pendant le Product Owner et
l’équipe de développement pour pouvoir la planification d’une nouvelle de récurrence
urée fixe qui prend généralement 2 à 4 semaines.
 Le Daily Scrum : C’est une réunion de l’équipe devant un tableau sous la forme des
notes : tâches à faire, tâches en cours, tâches détermines. ils ont réalisé un rapport ce
qu’il fait dans les derniers 24 heures et ce qu’il prévoyait les 24 heures prochaines.
 Le sprint review : C’est une réunion finale de sprint qui permet d’adapter en continu
et de rester réactive et pertinente dans le développement de produit. Alors que toutes
les personnes ont discuté de ce qui réalisé lors de sprint en présence de toute les
parties. La rétrospective de sprint : C’est une réunion d’évaluation du sprint tout ce
qui s’est passé pendant le sprint pour une amélioration continue. Alors que, il a un but
principal d’obtenir un maximum de retours de chacun des membres d’équipe.
 Burndown chart : C’est un graphique permettant de représenter l’avancement du
5
 développement d’un produit réalisé avec méthode Scrum.

 Les artefacts de SCRUM

Les artefacts de SCRUM sont spécialement conçus pour maximiser la transparence
d’informations essentielles afin que tous en aient la même compréhension. Les artefacts de
SCRUM sont :
 Le Product Backlog : liste toutes les fonctionnalités, besoins, améliorations et
correctifscorrespondant aux changements devant être appliqués au produit lors de
livraisons futures.Les items du Product Backlog incluent une description, un ordre,
une estimation de la complexité et de la valeur. Le Product Backlog évolue au fur et à
mesure que le produit et le contexte dans lequel il sera utilisé évoluent.
 Le Sprint Backlog : Le Sprint Backlog est une prévision que l’Equipe de
Développement fait de la fonctionnalité qui sera présente dans le prochain incrément
et le travail nécessairepour livrer cette fonctionnalité dans un incrément « terminé ».

 Fonctionnement de SCRUM :
La figure 3 met en œuvre tous les éléments afin de montrer le déroulement de travail au sein
de SCRUM.

Figure 3 : fonctionnement de SCRUM

 Les rôles de SCRUM :

 Le Product Owner : Le chef de projet, représente le client, il est responsable les

6
 spécifications fonctionnelles, établis la liste des priorités de ce qu’il faut développer et
assure la validation.

 Le Scrum master : Le chef d’équipe, il s’assure une bonne communication de

l’équipe de développent dans le cadre des projets IT.

 L’équipe de développement : C’est l’équipe qui définit les « users stories», il dirigé
dans un but commun à la réalisation de sprint et assure la livraison d’un incrément à la
fin de chaque sprint.

 Comparaison entre méthodes agiles et méthodes classiques :

Figure 4 : Comparaison entre méthodes agiles et méthodes classiques

1.4 La méthode adaptée :

Dans cette partie, nous présentons notre méthode de développement adoptée. Notre choix
s’est porté sur la méthode Scrum car elle répond aux caractéristiques des méthodes agiles
définies dans la section précédente. Nous avons choisi la méthode Scrum pour les raisons
suivantes :

✓ Développer et tester les courtes itérations.

7
✓ Produire le maximum du travail dans la durée la plus courte.

✓ Augmenter de la productivité.

✓ Adapter le logiciel crée suivant l’évolution du projet.

1.5 Le langage approuvé (UML) :

Le langage UML est un langage de modélisation graphique inclure des diagrammes brute
utilisés par les développeurs informatiques pour faciliter la visualisation des données dans un
logiciel utilisé.

Figure 5 : Langage UML

Conclusion
Dans ce premier chapitre, nous avons présenté l’organisme d’accueil au sein du quel nous
avons passé notre stage. Ensuite, nous avons étudié le système actuel et le marché pour
dégager les limites des solutions existantes et proposer une solution plus adéquate. Dans le
chapitre suivant, nous entamerons l’étude des besoins fonctionnels et non fonctionnels.

8
 Chapitre 2 : analyse et spécification des besoins
Introduction
Dans ce chapitre nous présentons les besoins des utilisateurs à travers une spécification des
besoins fonctionnels et non fonctionnels afin d’aboutir à une application performante et
satisfaisante .Ensuite, nous identifiions les acteurs de notre application.

Enfin, nous détaillons le travail par la méthodologie choisie dans le chapitre précédent.

1.1 Analyse des besoins

L’analyse des besoins est l’une des premières étapes du déroulement d’un projet.la
complexité de l’analyse des besoins est exprimés naturellement, des besoins implicites, des
besoins inavoués et tout simplement des besoins dont les utilisateurs n’ont même pas
conscience. Elle est alors une démarche qui consiste à rechercher et à caractériser les
fonctions offertes par un projet pour satisfaire les besoins de son utilisateur.

1.1.1 Identification des acteurs

Acteurs Rôles
Authentification
Gérer des utilisateurs
Administrateur

Authentification
Valider paiement
Agent comptable

Authentification
Régisseur Paiement
Authentification
Utilisateur Local Gérer de borne
Authentification
Gérer du client
Utilisateur central Facturation
Suivi consommation
Tableau 1 : Identification des acteurs

9
1.2 Spécification des besoins
Dans cette partie on va présenter les besoins fonctionnels et non fonctionnels de notre
application.

1.2.1 Besoins fonctionnels

Le besoin d’une application de facturation d’eau a pour but de gérer les clients et leurs
factures dans un temps très court avec une bonne performance. Les utilisateurs, s’appuient sur
une base de données. Cette application doit permettre à chaque utilisateur des taches bien
déterminées :

 Espace administrateur

S’authentifier avec un login et mot de passe pour garantir la sécurité de ses données.

Gérer des utilisateurs.

 Espace utilisateur central

S’authentifier avec un login et mot de passe pour garantir la sécurité de ses données.

Gérer les clients.

Facturation.

Suivi consommation.

 Espace utilisateur local

S’authentifier avec un login et mot de passe pour garantir la sécurité de ses données.

Gérer les bornes.

 Espace agent comptable

S’authentifier avec un login et mot de passe pour garantir la sécurité de ses données.

Valider paiement.

 Espace régisseur

S’authentifier avec un login et mot de passe pour garantir la sécurité de ses données.

Paiement.

10
1.2.2 Besoins non fonctionnels
Les besoins non fonctionnels présentent les exigences internes pour le système et primordiales
pour atteindre notre objectif. Parmi ces besoins on cite :

Ergonomie : L’interface de l’application doit être simple et utilisable pour les utilisateurs
pour qu’ils puissent l’exploiter.

Fiabilité : l’application doit assurer l’échange des données et n’en perdre aucun détail.

Configuration : la configuration du logiciel ne doit présenter aucune difficulté pour un simple

utilisateur non expert.

1.3 Diagramme des cas d’utilisation globale

Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour donner une
vision statique et globale du comportement fonctionnel d’un système logiciel. Ce diagramme
illustre les différents acteurs ainsi que les cas d’utilisations affectés à chacun de ces acteurs.

11
 Figure 6 : Diagramme de cas d'utilisation général

Dans cette partie, on a noté la détermination par le diagramme de cas d’utilisation qui
permettra de concevoir le système de vue d’un utilisateur et les rapports entre le système et
l’environnement.
Pour montrer les interactions fonctionnelles entre les acteurs et le système à l’étude on a :

 Acteur : C’est un rôle joué par un utilisateur humain ou un autre système qui interagit
directement avec le système étudié. Un acteur participe à au moins un cas
d’utilisation.
 Cas d’utilisation (use case) : C’est un ensemble de séquences d’actions réalisées par
le système produisant un résultat observable intéressant pour un acteur particulier.
Collections des scénarios reliés par un objectif utilisateurs communs.
 Association : utilisé dans ce type de diagramme pour relier les acteurs et les cas
d’utilisation par une relation qui signifie simplement « participer à ».

12
  Inclusion : le cas d’utilisation de base en incorpore explicitement un autre, de façon
obligatoire, à un endroit spécifié dans ses enchaînements.
 Extension : le cas d’utilisation de base en incorpore implicitement un autre, de façon
optionnelle, à un endroit spécifié indirectement dans celui qui précède à l’extension.
 Généralisation : les cas d’utilisation descendants héritent de la description de leur
parent commun. Chacun d’entre eux peut néanmoins comprendre des relations
spécifiques supplémentaires avec d’autres acteurs ou cas d’utilisations.

1.4 Backlog produit

Id Use case Id User story Priorité
1 S’authentifier 1.1 En tant que administrateur, je veux Forte
m’authentifier
1 S’authentifier 1.2 En tant que agent comptable, je veux Forte
m’authentifier
1 S’authentifier 1.3 En tant que régisseur, je veux m’authentifier Forte
1 S’authentifier 1.4 En tant que utilisateur local, je veux Forte
m’authentifier
1 S’authentifier 1.5 En tant que utilisateur central, je veux Forte
m’authentifier
2 Gérer 2.1 En tant que administrateur, je veux modifier un Forte
utilisateur utilisateur

2 Gérer 2.2 En tant que administrateur, je veux ajouter un Forte

utilisateur utilisateur
2 Gérer 2.3 En tant que administrateur, je veux supprimer un Forte
utilisateur utilisateur
2 Gérer 2.4 En tant que administrateur, je veux consulter un Forte
utilisateur utilisateur
3 Valider 3.1 En tant que agent comptable, je veux valider Faible
paiement paiement
4 Paiement 4.1 En tant que régisseur, je veux payer facture Forte
5 Gérer borne 5.1 En tant que utilisateur local, je veux ajouter une Forte
borne
5 Gérer borne 5.2 En tant que utilisateur local, je veux modifier Forte
une borne
5 Gérer borne 5.3 En tant que utilisateur local, je veux supprimer Forte
une borne

13
5 Gérer borne 5.4 En tant que utilisateur local, je veux consulter Forte
une borne
6 Gérer client 6.1 En tant que utilisateur central, je veux ajouter un Forte
client

6 Gérer client 6.2 En tant que utilisateur central, je veux consulter Forte
un client

6 Gérer client 6.3 En tant que utilisateur central, je veux modifier Forte
un client

6 Gérer client 6.4 En tant que utilisateur central, je veux supprimer Forte
un client
7 Facturation 7.1 En tant que utilisateur central, je veux préparer Forte
une facture
8 Suivi 8.1 En tant que utilisateur central, je veux Suivi Forte
consommation consommation
Tableau 2 : Backlog de produit

Dans cette partie, on a noté la détermination par le Backlog de produit qui permettra de
recueillir les attentes du marchés, des clients, à écrire les user stories qui correspondent et
travailler avec le client à les prioriser.

1.5 Planification des sprints

1.5.1 Structuration de projet en sprints

Une fois le Backlog de produit terminé, nous devons établir la réunion de planification. Le but
de cette réunion est de construire le Backlog de sprint en se basant sur le Backlog de produit
réalisé par le propriétaire du produit. Suite à cette réunion, nous avons identifié les durées
prévisionnelles du travail à effectuer durant chaque sprint. Pour notre projet, nous avons
divisé le travail sur deux releases.

14
 Relrase1 Relrase2

Sprint1 Sprint2 Sprint3

Authentification Facturation Suivi consommation

Gérer borne Paiement

Gérer client Valider paiement

Gérer utilisateur

Tableau 3 : Planification des sprints

1.5.2 Diagramme de Gantt

Pour la planification des différentes tâches, il est nécessaire de fixer un calendrier pour
notre projet. Pour cela, nous avons organisé le diagramme de Gant qui comprend les
différentes tâches à effectuer :

Figure 7 : Diagramme de Gantt

1.6 Architecture générale de l’application

1.6.1 Architecture logicielle
Modèle-vue-contrôleur ou MVC est un motif d'architecture logicielle destiné aux
interfaces graphiques lancé en 1978 et très populaire pour les applications web. Le
motif est composé de trois types de modules ayant trois responsabilités différentes :
les modèles, les vues et les contrôleurs.
• Un modèle (Model) : contient les données à afficher.
• Une vue (View) : contient la présentation de l'interface graphique.
• Un contrôleur (Controller) : contient la logique concernant les actions effectuées par

15
 l'utilisateur.
Cette figure représente l’architecture logicielle :

Figure 8 :l’architecture logicielle

1.6.2 Architecture matérielle

L’application à développer doit se connecter à un serveur de bases de données distant, via
Internet, afin de récupérer les données. Ce qui nécessite aussi l’intégration d’un serveur web
entre l’application client et le serveur de bases de données.

D’où l’architecture de mon application est à 3 niveaux (architecture 3-tiers), elle est partagée
entre :

 User : l'utilisateur accéder a l'interface web.

 Front end : c’est la couche métier, elle gère la communication entre Angular js et le
serveur node js à travers la connexion API.
 Serveur de données : elle gère la communication entre node js et le serveur de bases
de données Mongo DB à travers l’interroger et recevoir des données.
 Cette figure représente l’architecture matérielle :

Figure 9 : Architecture matérielle

16
1.7 Environnement de travail

1.7.1 Environnement matériel

Pour réaliser notre projet, nous avons utilisée un ordinateur portable qui dispose les
caractéristiques suivantes :
Machine : ASUS Intel Core i7
Mémoire : 8Go
Système d’exploitation : Windows 11

1.7.2 Environnement de développement

Dans cette section, nous présentons les principaux logiciels utilisés pour la
conception, ledéveloppement, et la rédaction de ce rapport.
 Visual Paradigm: un langage de création des diagrammes de modélisation
UML.[1]

Figure 10 : Logo visual paradigm

 Angular :
Est un Framework pour clients, open source, basé sur typescript et codirigé par l’équipe du
projet « Angular » chez Google .Il permet la création d’applications web et plus
particulièrement d’applications web monopages.

Figure 11 : Logo de l’outil Angular

 Bootstrap :
Bootstrap est une collection d'outils utiles à la création du design (graphisme,
animation et interactions avec la page dans le navigateur, etc.) de sites et d'applications
web. C'est un ensemble qui contient des codes HTML et CSS, des formulaires,
boutons, outils de navigation et autres éléments interactifs, ainsi que des extensions
JavaScript en option.[2]

17
 Figure 12 : Logo de l’outil Bootstrap

 Visual Studio Code :

Visual Studio Code est un éditeur de code extensible développé par Microsoft pour
Windows, Linux et MacOs. Les fonctionnalités incluent la prise en charge du
débogage, la mise en évidence de la syntaxe, la complétion intelligente du code.

Figure 13 : Logo visuel studio code

 Word :
Word est le logiciel phare de la suite Bureautique Microsoft Office. C'est l'un des logiciels les
plus utilisés dans le monde et permet de rédiger des lettres, CV, rapports et tous types de
documents texte.

Figure 14 : Logo Word

 Node.JS :

Node.js un langage de programmation utilisant la syntaxe de JavaScript.

C’est plateforme logicielle libre en JavaScript orientée vers les applications. [3]

Figure 15 : Logo node JS

18
  Mongo DB :

Est un système de gestion de base de données orienté documents. Il est écrit en C++.fait partie
de la mouvance No SQL. [4]

Figure 16 : Logo Mongo DB

 TeamGantt :

Est un logiciel de collaboration et de planification des projets utilisant principalement la

création des diagrammes de Gantt.

Figure 17 : Logo TeamGantt

Conclusion
Dans ce chapitre nous avons préparé notre plan de travail. Nous avons identifié les besoins
fonctionnels et non fonctionnels de notre application ainsi les rôles des utilisateurs, et par la
suite nous avons préparé le Backlog de produit ainsi que le plan des releases de notre projet
.le chapitre suivant expliquera la suite de la démarche SCRUM par la présentation de sprint 1.

19
 Chapitre 3 : Étude et réalisation du Sprint 1
Introduction
Dans ce chapitre, nous détaillerons le premier sprint en spécifiant ses besoins à travers le
Backlog, la conception et la réalisation pour aboutir à un incrément potentiellement livrable
qui assure l’authentification, gestion des clients, gestion des utilisateurs, gestion des bornes.

1.1 Backlog de produit de sprint 1

Le tableau 4 représente le Backlog de produit du sprint 1 .le sprint 1 comporte quatre use
case. Tous les use case possède la même priorité forte.

Id Use case Id User story Priorité

1 S’authentifier 1.1 En tant que administrateur, je Forte
veux m’authentifier
1 S’authentifier 1.2 En tant que agent comptable, je Forte
veux m’authentifier
1 S’authentifier 1.3 En tant que régisseur, je veux Forte
m’authentifier
1 S’authentifier 1.4 En tant que utilisateur local, je Forte
veux m’authentifier
1 S’authentifier 1.5 En tant que utilisateur central, je Forte
veux m’authentifier
2 Gérer 2.1 En tant que administrateur, je Forte
utilisateur veux modifier un utilisateur

2 Gérer 2.2 En tant que administrateur, je Forte

utilisateur veux ajouter un utilisateur
2 Gérer 2.3 En tant que administrateur, je Forte
utilisateur veux supprimer un utilisateur
2 Gérer 2.4 En tant que administrateur, je Forte
utilisateur veux consulter un utilisateur
3 Gérer borne 3.1 En tant que utilisateur local, je Forte
veux ajouter une borne
3 Gérer borne 3.2 En tant que utilisateur local, je Forte
veux modifier une borne
3 Gérer borne 3.3 En tant que utilisateur local, je Forte
veux supprimer une borne
3 Gérer borne 3.4 En tant que utilisateur local, je Forte
veux consulter une borne

20
4 Gérer 4.1 En tant que utilisateur central, je Forte
veux ajouter un client
Client
4 Gérer client 4.2 En tant que utilisateur central, je Forte
veux modifier un client

4 Gérer client 4.3 En tant que utilisateur central, je Forte

veux supprimer un client
4 Gérer client 4.4 En tant que utilisateur central, je Forte
veux consulter un client
Tableau 4 : Backlog de produit de sprint 1

1.2 Spécification Fonctionnelle :

L’objectif de cette partie est de détailler les spécifications fonctionnelles du sprint 1 qui sont
présentées par un diagramme de cas d’utilisation globale de sprint 1 avec les raffinements de
chaque cas d’utilisation.

1.3 Diagramme de cas d’utilisation global de sprint 1

Figure 18 : Diagramme de cas d’utilisation global de sprint 1

 Diagramme raffiné du cas d’utilisation « s’authentifier »

21
 Figure 19 : Diagramme raffiné du cas d’utilisation « s’authentifier »

 Description textuelle de cas d’utilisation « s’authentifier »

Titre Authentification
Administrateur, Agent comptable,
Acteur Régisseur, Utilisateur Local, Utilisateur
central
Chacun de ses acteurs doit avoir un login et
Pré-condition
un mot de passe
Post-condition Acteur authentifié.
Scenario nominal
1. L’acteur doit se connecter au système.
2. Le système affiche la page d’authentification.
3. L’acteur remplit les champs (login, mot de passe).
4. Le système vérifie les informations insérées par l’acteur
5. Le système affiche la page d’accueil de l’application.
6. Le système enregistre l’événement.
Scénario alternatif
Si le login et mot de passe sont erronés alors le système affiche un message d’erreur
Message d’erreur si les informations sont incorrectes.
Tableau 5 : Description de cas d’utilisation « s’authentifier »

 Diagramme raffiné du cas d’utilisation « gérer utilisateur »

22
 Figure 20 : Diagramme raffiné du cas d’utilisation « gérer utilisateur »

 Description textuelle de cas d’utilisation « Ajouter utilisateur »

Titre Ajouter utilisateur
Acteur Administrateur
L’administrateur doit être authentifié.
Pré-condition L’administrateur est sur la page de gestion
des utilisateurs.
Post-condition Utilisateur ajouté.
Scénario nominal
1. L’administrateur demande l’interface d’ajout d’un utilisateur.
2. Le système lui affiche l’interface
3. L’administrateur remplit le formulaire
4. L’administrateur valide l’ajout
5. Le système vérifie les données et ajoute l’utilisateur.
6. Le système enregistre l’événement.
Scénario alternatif
Au cours de l’étape 4, si les champs obligatoires non valides et/ou vides, le système affiche
un message d’erreur.
Tableau 6 : Description de cas d’utilisation « Ajouter utilisateur »

 Description textuelle de cas d’utilisation « consulter utilisateur »

Titre consulter utilisateur

Acteur Administrateur
Pré-condition L’administrateur doit être authentifié.

23
 L’administrateur est sur la page de gestion
des utilisateurs.
Post-condition Utilisateur consulté
Scénario nominal
1. L’administrateur demande l’interface d’ajout d’un utilisateur.
2. Le système lui affiche l’interface
3. L’administrateur consulte le formulaire
4. L’administrateur valide la consultation
5. Le système vérifie les données
6. Le système enregistre l’événement.
Scénario alternatif
Au cours de l’étape 4, si les champs obligatoires non valides et/ou vides, le système affiche
un message d’erreur.
Tableau 7 : Description de cas d’utilisation « consulter utilisateur »

 Description textuelle de cas d’utilisation « modifier utilisateur »

Titre modifier utilisateur
Acteur Administrateur
L’administrateur doit être authentifié.
Pré-condition L’administrateur est sur la page de gestion
des utilisateurs.
Post-condition Utilisateur est modifié.
Scenario nominal
1. L’administrateur sélectionne l’utilisateur
2. L’administrateur demande l’interface de modifier d’un utilisateur.
3. Le système lui affiche l’interface
4. Le système affiche les données de cet utilisateur.
5. L’administrateur effectue la modification puis valider.
6. Le système enregistre les modifications.
7. Le système enregistre l’événement.
Scenario alternatif

24
Au cours de l’étape 6, si les champs obligatoires non valides et/ou vides, le système affiche
un message d’erreur.
Tableau 8 : Description de cas d’utilisation « modifier utilisateur »

 Description textuelle de cas d’utilisation « supprimer utilisateur»

Titre supprimer utilisateur
Acteur Administrateur
L’administrateur doit être authentifié.
Pré-condition L’administrateur est sur la page de gestion
des utilisateurs.
Post-condition Utilisateur est supprimé.
Scenario nominal
1. L’administrateur sélectionne l’utilisateur
2. L’administrateur demande la suppression d’un utilisateur
3. Le système demande la confirmation de la suppression
4. L’administrateur confirme
5. Le système supprime l’utilisateur et le redirige sur la page de gestion des utilisateurs
6. Le système enregistre l’événement.
Scénario alternatif
Au cours de l’étape 3, si l’acteur ne confirme pas alors le système annule l’opération.
Tableau 9 : Description de cas d’utilisation « supprimer utilisateur»

 Diagramme raffiné du cas d’utilisation «gérer client »

25
 Figure 21 : Diagramme raffiné du cas d’utilisation «gérer client »

 Description textuelle de cas d’utilisation « modifier client »

Titre modifier client
Acteur Utilisateur central
L’acteur doit être authentifié
Pré-condition
L’acteur est sur la page de gestion des clients.
Post-condition client est modifié.
Scenario nominal
1. L’acteur sélectionne le client
2. L’utilisateur central demande l’interface de modifier d’un client.
3. Le système affiche les données de ce client.
4. L’acteur effectue la modification puis valider.
5. Le système vérifie les données et enregistre les modifications.
6. Le système enregistre l’événement.
Scénario alternatif
Au cours de l’étape 4, si les champs obligatoires non valides et/ou vides, le système affiche un
message d’erreur.
Tableau 10 : Description de cas d’utilisation « modifier client »

 Description textuelle de cas d’utilisation « supprimer client »

Titre supprimer client
Acteur L’utilisateur central
Pré-condition L’utilisateur central doit être authentifié.

26
 L’acteur est sur la page de gestion des clients.
Post-condition Client est supprimé.
Scénario nominal
1. L’acteur sélectionne le client
2. L’administrateur demande de supprimer de client.
3. Le système demande la confirmation de la suppression
4. L’administrateur confirme
5. Le système supprime le client et le redirige sur la page de gestion des clients.
6. Le système enregistre l’événement.
Scénario alternatif

Au cours de l’étape 3, si l’acteur ne confirme pas alors le système annule l’opération.

Tableau 11 : Description de cas d’utilisation « supprimer client »

 Description textuelle de cas d’utilisation « Ajouter client »

Titre Ajouter client
Acteur utilisateur central
Pré-condition L’acteur doit être authentifié
Post-condition Client ajouté.
Scenario nominal
1. L’acteur demande l’interface d’ajout d’un client.
2. Le système lui affiche l’interface
3. L’acteur remplit le formulaire
4. L’acteur valide l’ajout
5. Le système ajoute le client.
6. Le système enregistre l’événement.
Scenario alternatif
Au cours de l’étape 4, si les champs obligatoires non valides et/ou vides, le système affiche
un message d’erreur.
Tableau 12 : Description de cas d’utilisation « Ajouter client »

 Description textuelle de cas d’utilisation « consulter client »

Titre Consulter client

27
Acteur utilisateur central
Pré-condition L’acteur doit être authentifié
Post-condition Client consulté
Scenario nominal
1. L’acteur demande l’interface de consulter d’un client.
2. Le système lui affiche l’interface
3. L’acteur consulté le formulaire
4. L’acteur valide la consultation
5. Le système enregistre l’événement.
Scenario alternatif
Au cours de l’étape 4, si les champs obligatoires non valides et/ou vides, le système affiche
un message d’erreur.
Tableau 13 : Description de cas d’utilisation «consulter client »

 Diagramme raffiné du cas d’utilisation «gérer borne» :

Figure 22 : Diagramme raffiné du cas d’utilisation «gérer borne»

 Description textuelle de cas d’utilisation « ajouter borne »

Titre Ajouter borne
Acteur Utilisateur local

L’acteur doit être authentifié

Pré-condition
L’acteur est sur la page de gestion des bornes

Post-condition Borne ajouté.

Scenario nominal

28
1. L’acteur demande l’interface d’ajout d’une borne.
2. Le système lui affiche l’interface
3. L’acteur remplit le formulaire
4. L’acteur valide l’ajout
5. Le système ajoute la borne.
6. Le système enregistre l’événement.
Scenario alternatif
Au cours de l’étape 4, si les champs obligatoires non valides et/ou vides, le système affiche
un message d’erreur.
Tableau 14 : Description de cas d’utilisation « Ajouter borne »

 Description textuelle de cas d’utilisation « consulter borne »

Titre Consulter borne

Acteur Utilisateur local

L’acteur doit être authentifié

Pré-condition
L’acteur est sur la page de gestion des bornes

Post-condition Borne consulté

Scenario nominal
1. L’acteur demande l’interface de consulter d’une borne.
2. Le système lui affiche l’interface
3. L’acteur consulte le formulaire
4. L’acteur valide la consultation
5. Le système consulte la borne.
6. Le système enregistre l’événement.
Scenario alternatif
Au cours de l’étape 4, si les champs obligatoires non valides et/ou vides, le système affiche
un message d’erreur.
Tableau 15 : Description de cas d’utilisation « Ajouter borne »

 Description textuelle de cas d’utilisation « modifier borne »

Titre modifier borne

29
Acteur Utilisateur local
L’acteur doit être authentifié
Pré-condition
L’acteur est sur la page de gestion des bornes.
Post-condition Borne est modifié.
Scenario nominal
1. L’acteur sélectionne la borne
2. L’administrateur demande l’interface de modifier d’une borne.
3. Le système affiche les données de cette borne.
4. L’acteur effectue la modification puis valider.
5. Le système vérifie les données et enregistre les modifications.
6. Le système enregistre l’événement.
Scénario alternatif
Au cours de l’étape 4, si les champs obligatoires non valides et/ou vides, le système affiche un
message d’erreur.
Tableau 16 : Description de cas d’utilisation « modifier borne»

 Description textuelle de cas d’utilisation « supprimer borne »

Titre supprimer borne
Acteur L’utilisateur local
L’utilisateur local doit être authentifié.
Pré-condition
L’acteur est sur la page de gestion des bornes.
Post-condition Borne est supprimé.
Scénario nominal
1. L’acteur sélectionne la borne
2. l’administrateur demande de supprimer de borne.
3. Le système demande la confirmation de la suppression
4. l’administrateur confirme
5. Le système supprime la borne et le redirige sur la page de gestion des bornes.
6. Le système enregistre l’événement.
Scénario alternatif

30
Au cours de l’étape 3, si l’acteur ne confirme pas alors le système annule l’opération.

Tableau 17 : Description de cas d’utilisation « supprimer borne»

1.4 Conception des cas d’utilisation

Cette partie comporte la conception de sprint1 qui définit les besoins fonctionnelles.

1.4.1 Diagramme de classe d’analyse

Identifier et distinguer trois types de classes d’analyses (interface, contrôle et entité).ce sont
les classes dont on aura besoin pour réaliser les cas d’utilisation.

1.4.2 Diagramme de classe d’analyse d’authentification

Figure 23 : Diagramme de classe d’analyse « authentification »

1.4.3 Diagramme de séquences

Un diagramme de séquence est un diagramme d’interaction dont le but est de décrire
comment les objets collaborent au cours du temps et quelles responsabilités ils assument. Il
décrit un scénario d’un cas d’utilisation. Par ailleurs, en particulier les cadres d’interaction
(avec l’opération, Alt par exemple), ainsi que les différents messages représentés par un
diagramme de séquence sont :

Message asynchrone : il n’attend pas de réponse et ne bloque pas l’émetteur qui ne sait pas si
le message arrivera à destination

Message synchrone : L’émetteur reste alors bloqué le temps que dure l’invocation de
l’opération.

Message de création et destruction : La création d’un objet est matérialisée par une flèche
qui pointe sur le sommet d’une ligne de vie et la destruction d’un objet est matérialisée par un
choix qui marque la fin de la ligne de vie.

31
1.4.4 Diagramme de séquence authentification

Figure 24 : Diagramme de séquence « authentification »

1.4.5 Diagramme de classe d’analyse « gérer borne »

Figure 25 : Diagramme de classe d’analyse « gérer borne »

32
1.4.6 Diagramme de séquence « ajouter borne »

Figure 26 : Diagramme de séquence « ajouter borne »

33
1.4.7 Diagramme de séquence « modifier borne »

Figure 27 : Diagramme de séquence « modifier borne »

34
1.4.8 Diagramme de séquence « supprimer borne »

Figure 28 : Diagramme de séquence « supprimer borne »

1.4.9 Diagramme de classe d’analyse « gérer client »

Figure 29 : Diagramme de classe d’analyse « ajouter client »

35
1.4.10 Diagramme de séquence « ajouter client »

Figure 30 : Diagramme de séquence « ajouter client »

36
1.4.11 Diagramme de séquence « modifier client »

Figure 31 : Diagramme de séquence «modifier client »

1.4.12 Diagramme de séquence « supprimer client »

Figure 32 : Diagramme de séquence « supprimer client »

37
1.4.13 Diagramme de classe d’analyse « gérer utilisateur »

Figure 33 : Diagramme de classe d’analyse « gérer utilisateur »

1.4.14 Diagramme de séquence « ajouter utilisateur »

Figure 34 : Diagramme de séquence « ajouter utilisateur »

38
1.4.15 Diagramme de séquence « consulter utilisateur »

Figure 35 : Diagramme de séquence « consulter utilisateur »

1.4.16 Diagramme de séquence « modifier utilisateur »

Figure 36 : Diagramme de séquence « modifier utilisateur »

39
1.4.17 Diagramme de séquence « supprimer utilisateur »

Figure 37 : Diagramme de séquence « supprimer utilisateur »

1.5 Les interfaces graphiques du sprint 1

Cette interface représente la base de données

40
 Figure 38 : capture de base de données

Cette interface permet à l’utilisateur d’accéder à l’application après une validation de son
login et son password.

Figure 39 : Interface s’authentifier

Cette interface permet à l’utilisateur local d’ajouter borne à l’application après un remplissage
de formulaire.

41
 Figure 40 : Interface ajouter borne

Conclusion
Au cours de ce chapitre, nous avons présenté le premier sprint. Pour ce faire, nous
avons passé par l’analyse, la conception et la réalisation. Dans le chapitre suivant,
nous entamons le deuxième sprint.

42
 Chapitre 4 : Étude et réalisation du Sprint 2
Introduction
Dans ce chapitre, nous détaillerons le deuxième sprint en spécifiant ses besoins à travers le
Backlog, la conception et la réalisation pour aboutir à un incrément potentiellement livrable
qui assure la facturation, paiement et valider paiement.

1.1 Backlog produit de sprint 2

Id Use case Id User story Priorité
1 Facturation 1.1 En tant que Utilisateur centrale, Forte
je veux préparer la facture
2 Paiement 2.1 En tant que régisseur, je veux Forte
payer facture
3 Valider 3.1 En tant que agent comptable, je Faible
Paiement veux valider paiement
Tableau 18 : Backlog produit de sprint 2

1.2 Spécification Fonctionnelle

L’objectif de cette partie est de détailler les spécifications fonctionnelles du sprint 2 qui sont
présentées par un diagramme de cas d’utilisation globale de sprint 2 avec les raffinements de
chaque cas d’utilisation.

1.3 Diagramme de cas d’utilisation global de sprint 2

Figure 41 : Diagramme de cas d’utilisation global de sprint 2

43
  Diagramme raffiné du cas d’utilisation «paiement »

Figure 42 : Diagramme raffiné du cas d’utilisation «paiement »

 Description de cas d’utilisation « paiement »

Titre Paiement
Acteur Régisseur, agent comptable
L’acteur doit être authentifié.
Pré-condition
L’acteur est sur la page de gestion des clients.
Post-condition Montant payer
Scenario nominal
1. L’acteur sélectionne le client
2. L’acteur demande l’interface pour payer
3. Le système lui affiche l’interface
4. L’acteur remplit le formulaire
5. L’acteur valide l’ajout.
6. Le système vérifie les données et enregistre les données.
7. Le système enregistre l’événement.
Scénario alternatif
Au cours de l’étape 4, si l’acteur ne confirme pas alors le système annule l’opération.
Tableau 19 : Description de cas d’utilisation « paiement»

 Diagramme raffiné du cas d’utilisation «valider paiement»

Figure 43: Diagramme raffiné du cas d’utilisation «valider paiement »

 Description de cas d’utilisation « valider paiement »

Titre Valider paiement

44
Acteur Agent comptable

L’acteur doit être authentifié

Pré-condition
L’acteur est sur la page de gestion des clients.

Post-condition Validation ajouté.

Scenario nominal

1. L’acteur sélectionne le client.

2. L’acteur demande l’interface de valider paiement
3. Le système lui affiche l’interface
4. Le système lui affiche les données de la validation
5. L’acteur remplit le formulaire.
6. L’acteur valide la validation
7. Le système enregistre l’événement.

Scénario alternatif

Au cours de l’étape 3, si les champs obligatoires non valides et/ou vides, le système affiche un
message d’erreur.

Tableau 20 : Description de cas d’utilisation « valider paiement »

 Diagramme raffiné du cas d’utilisation «facturation »

Figure 44 : Diagramme raffiné du cas d’utilisation «facturation »

 Description de cas d’utilisation « facturation »

Titre Facturation
Acteur Utilisateur central

L’acteur doit être authentifié

Pré-condition
L’acteur est sur la page de gestion des clients.

45
Post-condition Facture ajouté.
Scenario nominal

1. L’acteur sélectionne le client.

2. L’acteur demande l’interface de facturation
3. Le système lui affiche l’interface
4. Le système lui affiche les données de la facture
5. L’acteur remplit le formulaire.
6. L’acteur valide l’ajout
7. Le système enregistre l’événement.

Scénario alternatif

Au cours de l’étape 3, si les champs obligatoires non valides et/ou vides, le système affiche un
message d’erreur.

Tableau 21 : Description de cas d’utilisation « facturation »

1.4 Conception des cas d’utilisation

Cette partie comporte la conception de sprint2 que définissent les besoins fonctionnelles.

1.4.1 Diagramme de classe d’analyse « paiement »

Figure 45 : Diagramme de classe d’analyse « paiement »

46
1.4.2 Diagramme de séquence «paiement»

Figure 46 : Diagramme de séquence « paiement »

1.4.3 Diagramme de classe d’analyse du cas d’utilisation « valider paiement »

Figure 47: Diagramme de classe d’analyse du cas d’utilisation« valider paiement»

47
1.4.4 Diagramme de séquence «valider paiement»

Figure 48: diagramme de séquence « valider paiement »

1.4.5 Diagramme de classe d’analyse du cas d’utilisation « facturation »

Figure 49 : Diagramme de classe d’analyse du cas d’utilisation « facturation »

48
1.4.6 Diagramme de séquence «facturation»

Figure 49: Diagramme de séquence «facturation»

1.5 Les interfaces graphiques du sprint 2

Cette interface représente le table facture

49
 Figure 50 : capture de bade de données

Cette interface permet à l’utilisateur central d’ajouter facture à l’application après un

remplissage de formulaire.

50
 Figure 51 : Interface facturation
Cette interface permet à l’agent comptable de valider le paiement d’une facture payé.

Figure 52 : Interface valider paiement

Conclusion
Au cours de ce chapitre, nous avons présenté le deuxième sprint. Pour ce faire, nous avons
passé par l’analyse, la conception et la réalisation. Dans le chapitre suivant, nous entamons le
troisième sprint.

51
 Chapitre 5 : Etude et réalisation de sprint 3

Introduction
Dans ce chapitre, nous détaillerons le troisième sprint en spécifiant ses besoins à travers le
Backlog, la conception et la réalisation pour aboutir à un incrément potentiellement livrable
qui assure suivi consommation.

1.1 Backlog produit de sprint 3

Id Use case Id User story Priorité
1 Suivi 1.1 En tant que utilisateur central, je Faible
consommation veux suivi consommation
Tableau 22 : Backlog produit de sprint 3

1.2 Spécification Fonctionnelle

L’objectif de cette partie est de détailler les spécifications fonctionnelles du sprint 3 qui sont
présentées par un diagramme de cas d’utilisation globale de sprint 3.

1.3 Diagramme de cas d’utilisation global de sprint 3

Figure 53 : Diagramme de cas d’utilisation global de sprint 3

 Description de cas d’utilisation « suivi consommation »

Titre Suivi consommation
Acteur Utilisateur central
L’acteur doit être authentifié
Pré-condition L’acteur est sur la page de suivi
consommation.
Post-condition consommation surveillé
Scenario nominal

52
1. L’acteur sélectionne le client.
2. L’acteur demande l’interface de consommation
3. Le système lui affiche l’interface
4. Le système lui affiche les données de la consommation
5. L’acteur remplit le formulaire.
6. L’acteur valide l’ajout
7. Le système enregistre l’événement.

Scénario alternatif

Au cours de l’étape 3, si les champs obligatoires non valides et/ou vides, le système affiche un
message d’erreur.

Tableau 23 : Description de cas d’utilisation « suivi consommation »

1.4 Conception des cas d’utilisation

Cette partie comporte la conception de sprint3 qui définit les besoins fonctionnelles.

1.4.1 Diagramme de classe d’analyse du cas d’utilisation « suivi consommation »

Figure 54: Diagramme de classe d’analyse « suivi consommation »

53
1.4.2 Diagramme de séquence « suivi consommation »

Figure 55 : Diagramme de séquence «suivi consommation»

1.5 Les interfaces graphiques de sprint 3

Cette interface permet à l’utilisateur central de suivre la consommation de client.

Figure 56 : Interface suivi consommation

54
1.6 Diagramme de classe global
Le diagramme de classe est une représentation statique des éléments qui composent un
système et de leurs relations. D’autre part le diagramme de classe est une description de la
base des données. Ce diagramme est caractérisée par :

Une classe : Elle est représentée par un rectangle séparé en trois parties :

 La première partie contient le nom de la classe

 La seconde contient les attributs de la classe
 La dernière contient les méthodes de la classe

Une association : C’est une relation entre deux classes, qui décrit un ensemble de liens entre
instances. Elle est représente par un simple trait. Une association est bidirectionnelle.

Multiplicité : le nombre d’objet (minimum, maximum) qui peuvent participer à une relation
avec un autre objet dans le cadre d’une association. Multiplicités fréquentes :

 0..1 = optionnel
 = exactement 1
 0..*=* quelconque
 1..*= au moins 1

Figure 57 : Diagramme de classe globale

Conclusion
Au cours de ce chapitre, nous avons présenté le troisième sprint. Pour ce faire, nous avons
passé par l’analyse, la conception et la réalisation.
55
 Conclusion générale

Ce projet de fin d’études a été réalisé au sein de Commissariat Régional au Développement

Agricole Jendouba.

C’est dans ce contexte s’intègre notre projet de fin d’études, qui a pour objectif la mise en
place une application de facturation d’eau.

Le présent rapport détaille toutes les étapes par lesquelles nous sommes passés pour arriver au
résultat attendu. Nous avons commencé par comprendre le contexte général du projet et
identifié les différentes exigences du futur système. Nous avons préparé, par la suite, un
Backlog produit en respectant les priorités des besoins. Malgré les contraintes de temps et les
difficultés techniques qui se résument principalement dans la compréhension du sujet et
surtout la tâche d’exécution des processus, nous avons réussi à réaliser la totalité de
l’application.

Outre, ce projet nous a permis d’approfondir nos connaissances dans les bonnes pratiques de
la gestion de projet vu que nous avons eu l’opportunité d’organiser son déroulement dès le
début et l’utilisation des technologie moderne Angular js , node js et base de données Mongo
DB pour la réalisation de l’application.

Finalement, vu l’accomplissement de projet, nous souhaitons très fortement qu’il soit le fruit
du progrès, de l’évolution et qu’il reste à la hauteur, nous souhaitons par ailleurs la
satisfaction des membres de jury.

56
 Bibliographie

[1] https://www.commentcamarche.net/telecharger/bureautique/23283-visual-
paradigm/
[2] https://getbootstrap.com/
[3]https://fr.search.yahoo.com/search?fr=mcafee&type=E211FR885G0&p=node+js/
[4] https://www.mongodb.com/fr-fr

57