Ministère de l’Enseignement supérieur, de la recherche scientifique

Université de Monastir

Institut Supérieur d’Informatique et de Mathématiques de

Monastir

Rapport de Stage de fin d’étude

Conception et développement d’une application web
budgétaire
Présente en vue de l’obtention du diplôme de
licence appliquée en informatique
Spécialité : génie logiciel et système informatique
Réalisé par :
Hiba Horchani
Sous la direction de :
Dr. HAMEL Lazhar - ISIMM
Mr. BOULABIAR Sadok – PGH
Réalise au sein de Poulina Group Holding

1
 Dédicace
Je dédie mon modeste travail a

Mon très cher père

Aucune dédicace ne saurait exprimer l’amour, L’estime, le dévouement et
le respect que j’ai toujours eu pour vous. Rien au monde ne vaut les efforts
fournis jour et nuit pour mon éducation et mon bien être. Ce travail est le
fruit de vos sacrifices que vous avez consenti pour mon éducation et ma
formation.

Ma très chère Mère

Affable, honorable et aimable : vous représentez pour moi le symbole de la
bonté par excellence, la source de tendresse et l’exemple du dévouement qui
n’a pas cessé de m’encourager et de prier pour moi. Votre prière et votre
bénédiction m’ont été d’un grand secours pour mener à bien mes études.
Aucune dédicace ne saurait être assez élégante pour exprimer ce que vous
méritez pour tous les sacrifices que vous n’avez cessé de me donner depuis
ma naissance. Je te dédie ce travail en témoignage de mon profond amour.
Puisse Dieu, le tout puissant, vous préserver et vous accorder santé, longue
vie et bonheur.

Tous les membres de ma famille

Veuillez trouver dans ce modeste travail l’expression de mon affection.

Hiba Horchani

2
Remerciement
La réalisation de ce travail a été possible grâce à la participation de plusieurs

personnes auxquelles nous voudrions témoigner toute notre reconnaissance.

A notre encadrant Monsieur Boulabiar Sadok de notre société d’accueil PGH.

Vous avez aimablement accepté de nous diriger et de nous donner ce sujet de fin d’étude,

vous avez manifesté beaucoup d’intérêt à notre égard. Votre disponibilité, votre gentillesse et

votre grande patiente nous a marqué. Nous vous remercions pour toute l’aide que vous avez

apporté, veuillez trouver ici l’expression de notre vive reconnaissance et de notre respect.

On tient également à adresser nos remerciements et notre gratitude à mon professeur

Monsieur

Mahmoudi Ramzi et mon Encadrant Monsieur Hamel Lazhar pour leurs disponibilités, leurs

soutiens, leurs aides précieuses et leurs conseils judicieux tout au long de ce projet.

A tous les membres de jury, pour l’amabilité pour laquelle ils ont accepté de juger ce

travail.

A tous les professeurs de l’Institut Supérieur d’Informatique et de Mathématiques de Monastir

Qui nous a enseigné et qui par leurs compétences nous ont soutenu et augmenté nos savoir

durant ces trois ans d’études.

Notre sincère remerciement s’adresse aussi à tous les amis et collègues qui ont contribués de

près ou de loin à la réalisation de ce travail par leur support moral et intellectuel.

Hiba Horchani

3
 Introduction générale :

L’organisation financière dans les sociétés de taille plus importante est

primordiale afin d'assurer un processus aux décisions stratégiques, s’occuper
de la réalisation du budget et réaliser des Reporting sous une fiabilité et
exactitude du déroulement de l'application qui est rechercher par la plupart
des entreprises dans la totalité de leurs services.

Dans le cadre de mon projet de fin d’étude, la société POULINA HOLDING

GROUP au sein de laquelle je fais mon stage dont le projet s'intègre dans le
département du développement informatique, décide de réaliser une
application web WF_Budget pour l'adapter à ses nouveaux besoins dont
l'objectif de définir les démarches à entreprendre pour déterminer dans quelle
mesure une organisation attient ses objectifs sur le plan financier et ces
niveaux des filiales de PGH.

Dans ce contexte la tache de réaliser la conception ainsi que l'implémentation

de cette application m’a été attribuer.

Cette dernière sera présentée autour de quatre chapitres :

 Le premier chapitre assure la description et la mise en œuvre de
l'application, présenter le travail demandé et la problématique ainsi que
la méthodologie de développement utilisée.
 Le second chapitre est consacré à l'analyse et critique de l'existant et
spécifications des besoins fonctionnels, non fonctionnels et techniques.
 Le troisième chapitre est dédier à la conception de notre application.
 Le quatrième est le dernier chapitre de notre rapport décrira les étapes
de la réalisation de l'application et tous les choix technologiques,
l'environnement logiciel utilisé.
 Enfin, une conclusion récapitulative du travail globale sera mise en
œuvre.

4
5
CHAPITRE 1 TABLE DES MATIÈRES

1 Cadre generale du projet.................................................................................................................................11

1. Introduction................................................................................................................................................12
1. Presentation du cadre du projet :................................................................................................................12
1.1.1. Presentation generale de l’entreprise................................................................................................12
1.1.1 Historique..........................................................................................................................................12
1.1.2 Les activites de l’entreprise...............................................................................................................12
1.1.3 Service d’accueil...............................................................................................................................15
1.2 Problematique........................................................................................................................................16
1.3 Analyse et Critique de de l’existant.......................................................................................................16
1.3.1 Analyse de l’Existant........................................................................................................................16
1.3.2 Critique de l’Existant.........................................................................................................................18
1.4 Solution..................................................................................................................................................18
1.5 Methodologie de Developpement........................................................................................................20
1.5.1 Les differentes cycles du developements.........................................................................................20
1.5.2 Tableau comparative.........................................................................................................................23
1.5.3 Choix du cycle de developpement....................................................................................................23
1.6 Diagramme de Gantt.............................................................................................................................24
1.7 Conclusion.............................................................................................................................................24
2 Analyse et specifications des besoins.............................................................................................................26
2.1 Introduction...........................................................................................................................................27
2.2 Specifications des besoins.....................................................................................................................27
2.3 Besoins Fonctionnelles..........................................................................................................................27
2.4 Besoins Non Fonctionnels.....................................................................................................................28
2.5 Besoins Techniques...............................................................................................................................29
2.5.1 Modele-vue-vue-modele..................................................................................................................29
2.5.2 Modele-Vue-Contrôleur....................................................................................................................30
2.5.3 Modele-vue-presenter......................................................................................................................31
2.6 Choix du modele conceptuelle..............................................................................................................32
2.7 Choix du langage du developpement....................................................................................................32
2.8 Conclusion.............................................................................................................................................33
3 Conception......................................................................................................................................................34
3.1 Introduction...........................................................................................................................................35
3.2 Conception generale.............................................................................................................................35
3.2.1 Figma.................................................................................................................................................35
3.2.2 Conception des maquette préliminaire............................................................................................36

6
 3.3 Langage UML.........................................................................................................................................37
3.3.1 Les 4+1 vues de kruchten..................................................................................................................37
3.4 Digramme de cas d’utilisation...............................................................................................................38
3.4.1 Identificatons des acteurs.................................................................................................................39
3.5 Cas d’utilisation globale.........................................................................................................................39
3.5.1 Raffinement de cas d’utilisation « authentification ».......................................................................40
3.5.2 Raffinement de cas d’utilisation « gerer les utilisateurs »................................................................41
3.5.3 Raffinement de cas d’utilisation « Workflow des demandes »........................................................42
3.5.4 Raffinement de cas d’utilisation « receptionner les demandes »....................................................43
3.5.5 Raffinement de cas d’utilisation « traiter les demandes »...............................................................44
3.6 Diagramme de séquence.......................................................................................................................45
3.6.1 Diagramme de séquence du processus « Authentification »...........................................................46
3.6.2 Diagramme de séquence au processus «  AJOUTER un utilisateur »...............................................46
3.6.3 Diagramme de séquance au processus « MODIFIER un utilisateur »...............................................47
3.6.4 Diagramme de séqance au processus « SUPPRIMER un utilisateur »..............................................48
3.6.5 Diagramme de séquence au processus « Ajout Workflow »............................................................49
3.7 Diagramme de classe.............................................................................................................................50
3.8 Diagramme de package.........................................................................................................................51
3.9 Conclusion.............................................................................................................................................51
4 Réalisation technique......................................................................................................................................53
4.1 Introduction...........................................................................................................................................55
4.2 environnement Du travail :....................................................................................................................55
4.2.1 Environnement Matériel...................................................................................................................55
4.2.2 Choix Technique...............................................................................................................................55
4.2.3 environnement Logiciel....................................................................................................................56
4.3 Illustration De l’utilisation e l’application..............................................................................................57
4.3.1 Interface d’authentification..............................................................................................................57
4.3.2 Interface administrateur...................................................................................................................58
4.3.3 Interface Workflow...........................................................................................................................59
4.3.4 Interface demandeur........................................................................................................................59
4.3.5 Interface Validateur..........................................................................................................................61
4.3.6 Interface Historique..........................................................................................................................62
4.4 Conclusion.............................................................................................................................................64
5 Conclusion Generale.......................................................................................................................................65
6 Bibliographie...................................................................................................................................................66

7
8
9
Liste des figures
Figure 1 Les Secteurs d’activités de l'entreprise.....................................................................................................14
Figure 2 répartition des secteurs PGH....................................................................................................................16
Figure 3 Organisation de service de l'informatique du groupe PGH......................................................................17
Figure 4 WF_Budget non améliorer........................................................................................................................17
Figure 5 Linox..........................................................................................................................................................18
Figure 6 Bankin........................................................................................................................................................18
Figure 7 Wallet........................................................................................................................................................19
Figure 8 circuit de l'application WF.........................................................................................................................20
Figure 9 Fonctionnement globale de l'application.................................................................................................21
Figure 10 Scrum......................................................................................................................................................22
Figure 11 T2UP........................................................................................................................................................23
Figure 12 XP Extreme Programming.......................................................................................................................23
Figure 13 XP.............................................................................................................................................................25
Figure 14 Diagramme de Gantt...............................................................................................................................25
Figure 15 MVVM.....................................................................................................................................................30
Figure 16 MVC.........................................................................................................................................................31
Figure 17 MVP.........................................................................................................................................................32
Figure 18 Figma.......................................................................................................................................................36
Figure 19 Proposition maquette pour page Home.................................................................................................37
Figure 20 Proposition maquette pour page Login..................................................................................................38
Figure 21 Vues de Kruchten....................................................................................................................................39
Figure 22 Exemple de diagramme de cas d'utilisation...........................................................................................40
Figure 23 cas d'utilisation globale...........................................................................................................................41
Figure 24 Raffinement cas d’utilisation authentification........................................................................................42
Figure 25 raffinement cas d’utilisation gérer les utilisateurs.................................................................................43
Figure 26 Raffinement cas d’utilisation pour le Workflow des demandes.............................................................44
Figure 27 Raffinement cas d’utilisation pour la réception d’une demande...........................................................45
Figure 28 Raffinement cas d’utilisation traiter une demande................................................................................46
Figure 29 Diagramme de séquence "authentification"..........................................................................................47
Figure 30 Diagramme de séquence ajouter un utilisateur.....................................................................................48
Figure 31 Diagramme de séquence modifier un utilisateur...................................................................................49
Figure 32 Diagramme de séquence supprimer un utilisateur................................................................................50
Figure 33 diagramme de séquence ajout workflow...............................................................................................51
Figure 34 Diagramme de classe générale...............................................................................................................52

10
Figure 35 Diagramme de Package...........................................................................................................................52
Figure 36 Architecture du Framework.Net.............................................................................................................57
Figure 37 Interface d'authentification....................................................................................................................58
Figure 38 Interface administrateur.........................................................................................................................59
Figure 39 Interface ajout Utilisateur.......................................................................................................................59
Figure 40 Ajout utilisateur.......................................................................................................................................60
Figure 41 Interface Modifier un utilisateur.............................................................................................................60
Figure 42 Interface Workflow.................................................................................................................................60
Figure 43 Interface demandeur..............................................................................................................................61
Figure 44 Interface demande..................................................................................................................................61
Figure 45 Interface Passer une demande...............................................................................................................62
Figure 46 Interface valider......................................................................................................................................62
Figure 47 Interface Validateur................................................................................................................................63
Figure 48 Interface Valider demande.....................................................................................................................63
Figure 49 Interface de validation............................................................................................................................63
Figure 50 Interface Historique................................................................................................................................64
Figure 51 Interface Historique demande................................................................................................................64

11
Listes des Tableaux
Tableau 1 Comparaison des solutions....................................................................................................................18
Tableau 2 tableau comparative de Cycle................................................................................................................23
Tableau 3 Besoins Fonctionnelles...........................................................................................................................27
Tableau 4 Besoins Non Fonctionnels......................................................................................................................28
Tableau 6 Tableau comparatives des langages.......................................................................................................32
Tableau 7 Identification des acteurs.......................................................................................................................38
Tableau 8 Authentification......................................................................................................................................40
Tableau 9 gérer utilisateurs par l'administrateur...................................................................................................41
Tableau 10 Workflow des demandes......................................................................................................................42
Tableau 11 réception d’une demande....................................................................................................................43
Tableau 12 traiter une demande............................................................................................................................44

12
1 CADRE GENERALE DU PROJET

13
1. INTRODUCTION
Au cours de ce chapitre, Je vais présenter le cadre de la réalisation de ce projet ainsi les
problématiques rencontrer qui ont poussé l'organisme à réaliser cette application.

Ainsi la présentation de la solution afin de nous mener à déterminer la méthodologie du

développement utilisé.

1. PRESENTATION DU CADRE DU PROJET :

1.1.1. PRESENTATION GENERALE DE L’ENTREPRISE

Le groupe Poulina, officiellement connu sous le nom de Poulina Group Holding (PGH)
depuis le 24 juin 2008, est un groupement industriel des innovateurs hommes et femmes qui
réalise des services communs pour la construction d'une entreprise moderne tunisien.
Originellement spécialisé dans l'aviculture, le groupe s'est peu à peu diversifié pour devenir le
premier groupe à capitaux privés du pays et qui rivalise en termes de qualité de management
et efficacité avec d'autres entreprises des pays les plus développés.

1.1.1 HISTORIQUE

Poulina Group Holding a est fondé en 1967 pour commencer avec l'aviculture qui peu à peu
amenant le groupe à se lancer dans l'industrie et a fortement diversifie ses produits pour ne
pas seulement être un producteur mais aussi un fournisseur aux éleveurs tous les services
nécessaires.[ CITATION 1 \l 1036 ]

Suite à cette logique de diversification il intégrer des métiers différents, En 1980 s'est
développée dans des départements plus industrialisés pour un grand nombre d'activités
économiques aussi d'autres diverses phases de diversification a été entamée.

Pour en 2008 le groupe s'introduit en bourse afin de réorganiser le groupe en Holding tout en
regroupant ces filiales pour être chapeauter par une holding principale Poulina Group
Holding.

En 2010 PGH a lancé une reconstitution qui a devisé le groupe en 9 métiers pour améliorer la
gestion et le suivi des performances. Ces métiers sont l'ensembles des produits de grande
consommation. Le groupe possède en effet 24 filiales à l'étranger notamment au :

Maroc (4), Algérie (4), Libye (10), France (2), Chine (3).

1.1.2 LES ACTIVITES DE L’ENTREPRISE

La figure 1 montre la structure des activités de groupe PGH :

14
 Figure 1 Les Secteurs d’activités de l'entreprise.

1. Secteur intégration avicole :

Ce secteur assure le stock du pays Tunisien en viande, Ainsi PGH assimile tout son
processus d’avicole de la production jusqu’à la distribution de la nutrition animale.

PGH possède une longue expérience dans cette activité qui la met en avant et capitalise sur
plusieurs avantages compétitifs afin d’être le leader Tunisien et demeure l’acteur principale
de la marche.

2. Secteur de l’emballage :
Ce métier regroupe plusieurs entreprises qui sont spécialisé dans cette activité qui
représente cinq diverses matières de base pour la transformation : le papier, carton,
plastique, verre, métal.
Ce secteur a connu une croissance importante au cours de ces dernières années citant les
principales sociétés dans ce métier : UNIPACK, SUDPACK, NAPACK...
Tel que UNIPACK est la société pionnière tunisienne dans le domaine de l’emballage.
3. Secteur bois et bien d’équipements :
Ce secteur est au cœur des activités PGH.
Il dépond principalement de la société industrielle GAN dont son essor date depuis 1975.
Qui se devise en deux différentes activités :
-L’électroménagère.
-Le mobilier du bureau.
PGH est le majeur fournisseur des Industriels tunisiens de la filière bois et répond a 60%

15
 du besoins marche.
Cette dernière fabrique des produits sous la marque Mont Blanc pour électroménagère
domestiques et Equipements industriels.
4. Secteur matériaux de construction :
Ce métier occupe une position de leader sur le marché, Carthago céramique est un
producteur et distributeur de carreaux de céramique.
Suite a son succès de ses produits, la société a connu un développement international
remarquablement réussi.
Elle exporte plus de 30% de la production dans plus de trente pays à travers le monde tel
que : La France, Le Maghreb et les pays arabe.
5. Secteur Immobilier :
Poulina Group Holding s’est lancé dans le métier de l’immobilier à travers sa filiale
ETTAAMIR, créée en 1997.Ainsi, plusieurs projets de haut standing ont été réalisés dans
les quartiers les plus huppés de la Tunisie, comme :
 Projet LES COLOMBES au LAC II, qui totalisera une surface de 6000m².
 Projet LE GOLF, à la Soukra, Surface 10 800 m².
 Projet LES JASMINS du CREPUSCULE à Hammamet, surface 10 100 m².

À travers sa filiale ETTAAMIR, PGH est devenu un acteur incontournable du secteur

immobilier en Tunisie.

6. Secteur Produits et grande consommation :

A travers ce métier plusieurs produits sont devenus une habitude alimentaire des
tunisiens tel que crème glacées, yaourt, déserts, produits laitiers.
Parmi ces produits qui sont élaborent et commercialiser par PGH, On peut citer GIPA
une société phare dans cette activité qui est devenu une référence dans le secteur
agroalimentaire.
Pour qu’aujourd’hui deux grandes marques lui appartiennent : SELJA, OLA.
Enfin plusieurs sociétés sont en cours de développement parmi eux MED FOOD qui a
pour mission d’embouteiller et de commercialiser en Chine l’huile d’olive tunisienne.
7. Secteur Commerce et Services :
Le Groupe possède plusieurs sociétés qui opèrent dans le commerce international, la
représentation, l’import, le conditionnement et les nouvelles technologies de
l’information et de la communication.
 Poulina group holding s’attaque aux nouvelles technologies de l’information et de la
communication (NTIC). Tout a commencé par la création, en 2012, du plus grand Data
center en Tunisie (bénéficiant de la technologie Tier 3+) à travers la société Dataxion.
Poulina Group Holding (PGH) est également actionnaire depuis 2007 à travers sa filiale
MED INVEST COMPANY, de la société MAGASIN GÉNÉRAL.

Comme le montre la figure 2 ci-dessous :

16
 Figure 2 répartition des secteurs PGH

1.1.3 SERVICE D’ACCUEIL

Cette application sera sous la direction du département de l’informatique qui m’a accueilli
durant ce stage ce dernière qui est élaborer pour la gestion des systèmes informatiques du
groupe PGH. Comme le montre bien cette figure 3 ci-dessous :

17
 Figure 3 Organisation de service de l'informatique du groupe PGH

1.2 PROBLEMATIQUE
L’entreprise d’accueil a besoin de mieux organiser et adapter ces taches budgétaires. Pour but
qu’elles soient mieux en mieux traiter par ces personnels, ainsi l’accès à ces données doit être
plus faciles et aussi remplacer support papier auparavant par un fonctionnement digital pour la
gestion des personnels, gestion des demandes et leur déroulement dans le système afin d’être
plus approprié, suit la tendance informatique et sécurisé. Cette figure 4 ci-dessous schématise
plus la problématique :

Figure 4 WF_Budget non améliorer

1.3 ANALYSE ET CRITIQUE DE DE L’EXISTANT

1.3.1 ANALYSE DE L’EXISTANT

Cette étape est primordiale pour la phase de l’analyse d’un projet et la mise en route de tout
projet informatique ou autre, ainsi pour définir le contexte du travail afin de dégager tout
imperfections dans le système pour les corriger.

1.3.1.1 LINOX

18
Cette application comme le montre la figure 5 suivante est lancé en 2010.Elle offre des
nombreuses fonctionnalités pour une des primordiale c’est la catégorisation automatique des
dépenses et accompagne de graphique interactif. Mais pour des inconvénients talque il faut
devenir un membre « premium » et payer une somme de 2.50 euros par mois et restriction des
fonctionnalité pour les abonnements gratuit.[ CITATION linxo \l 1036 ]

Figure 5 Linox

1.3.1.2 BANKIN

Bankin est une application pour gérer son budget en ligne. C’est une application qui offre des
comptes sont accessibles depuis la même interface, avoir une vue d’ensemble sur tous les
dépenses ainsi avoir un agent coach budget vous aide à mieux gérer votre argent qui est
payant et voici l’interface de cette application dans la figure 6 ci-dessous :[ CITATION bankin \l
1036 ]

Figure 6 Bankin

1.3.1.3 WALLET

Cette application Wallet comme la montre la figure 7 présente vise à aider les utilisateurs à la
gestion de leurs besoins financiers en synchroniser leurs soldes et leurs transactions avec leurs
banques. Il existe une version gratuite et largement suffisante qui offre une utilisation simple
et facile aux utilisateurs, mais on trouve aussi un bug lors de la connexion un compte avec
certaine banque.[ CITATION wallet \l 1036 ]

19
 Figure 7 Wallet

1.3.2 CRITIQUE DE L’EXISTANT

En premier lieu tous ces applications trouvées par une simple recherche sur google sont toutes
des applications mobiles d’où il est rare de trouver une application web budgétaire open
source. Ainsi on remarque que toutes ces applications et autres aussi sont payantes et limitée à
des fonctionnalités et certaine comme WALLET l’un de ces inconvénients présentent un bug
pour un besoin primaire de sa création. De plus ces applications ne sont pas spécifiques et
présente une manipulation assez difficile et complexe à comprendre d’où l’existant ne répond
pas à notre problème pour cela l’intérêt de la réaliser de notre application qui réponds à ces
critères comme le montre le tableau comparatif suivant :

LINOX BANKIN WALLET

Sécurité
Manipulation facile
Gestion des
comptes avec les
banques
Gratuit
Tableau 1 Comparaison des solutions

1.4 SOLUTION

La critique précédente des solutions existantes montre qu’aucune de ces solutions ne répond
convenablement à la problématique soulevée d’où l’intérêt de développement notre propre
application WF_Budget.

En effet les applications informatiques se sont imposées dans les entreprises pour répondre à
des besoins bien précise, d’où rarement qu’on trouve pour une société de gestion qui ne
possède pas une application ou un site qui gère la gestion de son fonctionnement, En revanche
ce domaine tend toujours à être innovant et plus développé.

D’où mise en œuvre d’une application budgétaire pour facilite et traduire l’engagement du
responsable afin d’atteindre ses objectifs, la procédure budgétaire couvre la totalité des
activités de l’entreprise qui est fixer sous un objectif financier afin d’évaluer les revenus.

Durant ce stage, Nous allons réaliser une application web qui gouverne les budgets des
différentes filiales de PGH ainsi gère les différentes demandes traiter par les personnels qui
sont rattacher à plusieurs sites sous un contrôle pour examiner l’état de chaque demande en
passant par un circuit de workflow bien déterminer qui se présente comme suit :

20
  Saisie d’une demande spécifique par un demandeur.
 Envoie de cette demande au validateur Filiale pour la consulter.
 Identification des conditions afin de soit refuser, accepter ou modifier cette demande.
 Transfer au validateur siège pour donner son approbation.
 Tout acheminement est signalé devant le demandeur.
 Cette étape de workflow est en effet modélisée dans la figure 8 suivante :

Figure 8 circuit de l'application WF

Et pour un fonctionnement global de cette application présenter dans cette figure 9

suivante en utilisation des pictogramme [ CITATION picto \l 1036 ]:

21
 Figure 9 Fonctionnement globale de l'application

1.5 METHODOLOGIE DE DEVELOPPEMENT

Le nombre des méthodes disponible, qui nous assure un rendement efficace de développement
en termes de qualité, productivité et gain de temps sont nombreux. Pour cela nous étudions
quelques méthodes de développement et suite à cette étude nous choisissons la méthodologie
la plus adéquate pour le développement de notre application.

1.5.1 LES DIFFERENTES CYCLES DU DEVELOPEMENTS

1.5.1.1 SCRUM

C’est un schéma d’organisation de développement de produits complexe. Son principe

s’appuie sur le découplage d’un projet en Sprint (Time Boxing) c’est un bloc de temps limité,
volontairement limite qui est destiner à réaliser une activité bien déterminer

Pour cela ce le cycle de vie d’un projet Scrum est divise en trois parties comme la montre la
figure 10 suivante :

1. Initialisation : déterminer les inputs/outputs pour les processus.

2. Sprint : technique de planification du projet, le développement.
3. Clôture : les processus sont définis pour une démonstration de ce qui est achevée.

22
 Figure 10 Scrum

1.5.1.2 T2UP

Two Tracks Unified Process, processus de développement logiciel pour un cycle en Y, il

découpe les contraintes fonctionnelles des contraintes techniques enfin pour une conception
préliminaire.

Cette méthode est définie autour de trois phases essentielles comme est montrer dans la figure
11 qui suit :

1. Branche technique : capture de besoins techniques, Analyse.

2. Branche fonctionnelle : capture de besoins fonctionnels, conception générique.
3. Phase de réalisation : conception préliminaire, conception détaillée, codage et tests.

23
 Figure 11 T2UP

1.5.1.3 PROGRAMMATION EXTREME(XP)

Cette méthodologie de développement qui vise à améliorer la qualité du logiciel et la

réactivité aux exigences changeantes des clients. En effet il est destiné à décrire des nouvelles
versions du produit suites à ces nouveaux besoins.

Parmi autres notion de programmation extrême est la révision du code, les tests unitaires et
repose sur des cycles rapides de développement dont les étapes sont les suivantes comme la
montre l’image suivante :

1. Phase d’exploitation des besoins.

2. Développement des taches.
3. Phase de test pour un produit achevée.

Figure 12 XP Extreme Programming

24
1.5.2 TABLEAU COMPARATIVE
Processus Description
Scrum Tout l’accent est mis sur
la bonne pratique de la
programmation avec un
déroulement par
itérations courtes et
gérées collectivement.
T2UP Processus de
développement en Y et
qui implémente le
processus unifie.
XP Une méthode agile
oriente sur l’aspect
réalisation d’une
application qui tend à
avoir des besoins
changeants.
Tableau 2 tableau comparative de Cycle
Avantages Inconvénients
-Simplicité des processus -Violation des
responsabilités.
-Règles définis
clairement. -l’équipe ne se prête pas
au SCUM.
-Organisation
personnelle
-Chaque équipe a son lot
de responsabilité.
-Fait une large place a la -Ne propose pas de
technologie et a la documents types.
gestion du risque.
-Améliore la phase de -Frein de productivité en
conception vu son cycle termes de temps.
d’observation.
-Moins des bugs et
imperfections.

1.5.3 CHOIX DU CYCLE DE DEVELOPPEMENT

Après cette étude sur quelques méthodologies et d’après ce tableau comparatif On a

opté pour la méthode XP car c’est la plus adapter pour ce projet puisque les besoins de
notre application peuvent changer au cours du temps ainsi des nouvelles modifications
et fonctionnalité peuvent être appliquée. Et cette méthode tend à rendre le projet plus
flexible et tolèrent à des au changements comme la montre cette figure les différentes
étapes de ce cycle.

25
 Figure 13 XP

1.6 DIAGRAMME DE GANTT

Le diagramme de Gantt est un outil d’ordonnancement et gestion des projets qui permet de
bien visualiser dans le temps les différentes tâches à réaliser pour un certain temps bien
déterminer pour enfin qu’il soit présenté d’une manière graphique sur l’avancement du projet.
Dans ce diagramme de Gantt on représente[ CITATION gantt \l 1036 ] :

Figure 14 Diagramme de Gantt

1.7 CONCLUSION

Dans ce chapitre nous avons mis notre projet dans son contexte, présenter l’entreprise dans
laquelle on effectue le stage. Ensuite après une description détailler du travail demande et les
problématiques ainsi que les solutions adoptées. On a discuté les différentes méthodologies
pour enfin la méthode XP qui est la plus adéquate.

26
Le chapitre suivant présente l’analyse et la spécification des besoins fonctionnels et non
fonctionnels ainsi les besoins techniques.

27
2 ANALYSE ET SPECIFICATIONS DES BESOINS

28
2.1 INTRODUCTION

Le présent chapitre présente une analyse qui joue un rôle important dans la démarche
ergonomique du développement d'une application.

Dont le choix et la mise en pratique de la méthodologie XP qu’on a choisie nous amène à

cette étape pour donc avoir comme objectif de permettre de formaliser les étapes préliminaires
du développement d'un système afin de rendre ce développement plus fidèle aux besoins du
client qui sont divisés en besoins fonctionnels, besoins non fonctionnels et besoins techniques.

2.2 SPECIFICATIONS DES BESOINS

Vu la complexité et la difficulté de gestion budgétaire dans une grande entreprise comme

PGH. Les personnels ont besoins d’un moyen plus facile pour gérer ces fonctionnalités et
éviter les erreurs humaines.

2.3 BESOINS FONCTIONNELLES

Ces besoins fonctionnels sont fortement utiles pour le développement de l’application comme
montre ce tableau suivant :

Administrateur
S’authentifier L’administrateur accède à l’application avec un login
et un mot de passe.
Gérer les utilisateurs L’admin est le seul qui a le droit de gérer les comptes
des utilisateurs (attribuer un rôle, Ajouter,
Supprimer, Modifier, Consulter).
Gérer les Droits d'accès L’admin est la seule personne qui a le droit de gérer
les droits d’accès des utilisateurs sur la SGBD.
Gérer les workflow demandes L’admin est la seule personne qui pouvais gérer les
WF des demandes (Ajouter, Supprimer, Modifier,
Consulter).
Gérer les Sociétés L’admin a le droit de gérer les sociétés (Ajouter,
Supprimer).
Agent Filiale
S’authentifier Chaque agent filial accède à l’application avec un
login et un mot de passe.
Réceptionner les demandes L’agent filiale a le droit de recevoir les demandes
saisies par le demandeur
Traiter les demandes L’agent filiale a le droit selon son rôle de traiter les
demandes qu’il a reçu (accepter, refuser, modifier).
Envoyer les demandes L’agent filiale peut envoyer les demandes autres
agents.

29
 Agent siège
S’authentifier Chaque Agent siège accède à l’application avec un
login et un mot de passe.
Réceptionner les demandes L’agent siège a le droit de recevoir les demandes de
la part de l’agent filiale.
Traiter les demandes L’agent siège a le droit selon son rôle de traiter les
demandes qu’il a reçu (accepter, refuser, modifier).
Envoyer les demandes L’agent siège peut envoyer les demandes autres
agents.
Demandeur
S’authentifier Chaque demandeur accède à l’application avec un
login et un mot de passe.
Saisir une demande Le demandeur a le droit de saisir une demande
parmi 4 choix (Les demandes :
-Révision Budget.
-Déblocage Solde.
-Débocage Exceptionnelle.
-Escompte.)
Tableau 3 Besoins Fonctionnelles

2.4 BESOINS NON FONCTIONNELS

Les besoins non fonctionnels sont très importants même s’ils agissent de manière indirecte
pour le résultat finale de l’application et son rendement ce qui fait qu’ils ne doivent pas être
négligés pour cela il faut répondre aux exigences suivantes comme le montre ce tableau :

Les Besoins Non Fonctionnels

Performance Une application doit être avant tout performante et
répondre aux exigences utilisateurs d’une manière
optimale.
Exigences Technique *Environnement de développement :
ASP.net.
*Base Donnée :
SQL SERVER 2012.
Contrainte Temporelle Ce projet doit être réaliser pendant une durée de
temps qui ne dépasse pas 4 mois.
Sécurité Cette application doit respecter la confidentialité des
données, et le contrôle de traçabilité.
Interface utilisateur *L’application doit est ordonné de point de vue
ergonomie, la qualité est un facteur primordial.
*L’accès aux données et à l’application doivent être
facile pour l’utilisateur ainsi pour une interface
graphique claire.

30
 Tableau 4 Besoins Non Fonctionnels

2.5 BESOINS TECHNIQUES

Capture des différentes choix techniques utilisés :

Langage utiliser ainsi le Framework approprier.

2.5.1 MODELE-VUE-VUE-MODELE

MVVM est un design Pattern ou patron de conception introduit par Microsoft qui a pour but
en générale d’améliorer la séparation entre les données et la vue (View) qui les affichent par
un mécanisme assez connu le Binding ce dernier fait des liaisons entres des données de
manière dynamique, MVVM simplifier l’écriture des interfaces graphique.

Soit les composantes de MVVM comme la montre la figure 15 suivante :

Figure 15 MVVM

 Model (Modèle en français) : le modèle contient les données. Généralement, ces

données proviennent d’une base de données ou d’un service externe comme un API.
 View (Vue en français) : la vue correspond à ce qui est affiché (la page web dans notre
cas). La vue contient les différents composants graphiques (boutons, liens, listes) ainsi
que le texte.
 ViewModel (Vue-Modèle en français) : ce composant fait le lien entre le modèle et la
vue. Il s’occupe de gérer les liaisons de données et les éventuelles conversions. C’est ici
qu’intervient le binding.
Enfin il faut retenir que l’idée de MVVM est que la vue ne doit jamais traiter de données.

31
2.5.2 MODELE-VUE-CONTRÔLEUR

MVC est un modèle de conception de logiciel dont la logique du contrôleur et le modelé sont
séparés de l’interface de l’utilisateur et par conséquence la maintenance et les tests deviennent
simple et plus facile.

Ce modèle divise une application sur trois aspects comme montre cette figure 16 :

Figure 16 MVC

Model :

Le modèle représente une collection de classes qui explique la logique métier, à savoir le
modèle métier et le modèle de données (opérations d’accès aux données). Il définit également
les règles métier pour les moyens de données comme la façon dont les données peuvent être
modifiées et manipulées.

Vue :

La vue représente les composants de l’interface utilisateur tels que CSS, jQuery, HTML. La
vue affiche les données reçues du contrôleur comme résultat. Cela modifie également le (s)
modèle (s) dans l’interface utilisateur.

Controller :

32
La responsabilité du contrôleur est de traiter les demandes entrantes. Il obtient l’entrée des
utilisateurs via la vue, puis traite les données de l’utilisateur via le modèle, en renvoyant les
résultats à View. Il agit normalement comme un médiateur entre la vue et le modèle
[ CITATION mvc1 \l 1036 ].

2.5.3 MODELE-VUE-PRESENTER

MVP est un modèle qui est identique au modèle MVC dont le contrôleur de MVC est
remplacé par le présentateur qui effectue la liaison entre une vue et le modèle.

Ce modèle est aussi divisé en trois couches comme le présente cette figure 17:

Figure 17 MVP

Model :

Le modèle représente une collection de classes qui explique le modèle métier et le modèle de
données. Il définit également les règles métier pour les moyens de données comme la façon
dont les données peuvent être modifiées et manipulées.

Vue :

La vue représente les composants de l’interface utilisateur tels que CSS, jQuery, HTML. La
vue affiche les données reçues du contrôleur comme résultat. Cela modifie également le (s)
modèle (s) dans l’interface utilisateur.

Prester :

Le présentateur est chargé d’adresser tous les événements de l’interface utilisateur au nom de
la vue. Il reçoit les entrées des utilisateurs via la vue, puis traite les données de l’utilisateur via

33
le modèle qui renvoie les résultats à la vue. La vue et le présentateur sont complètement
séparés, contrairement à la vue et au contrôleur, l’un de l’autre et communiquent entre eux par
une interface. Le Présenter ne gère pas non plus le trafic de requête entrant comme le
contrôleur.

2.6 CHOIX DU MODELE CONCEPTUELLE

Notre choix s’oriente vers le modèle MVC car il présente un concept très puisant qui
intervient à la réalisation de notre application et que chaque partie est distincte avec ce
modèle, dont les données peuvent provenir d’une base différente qui est le cas avec notre
application ainsi la modification ou la création des pages ne modifie par certainement la
totalité de la structure de l’application, toute modification est isolée.

Cette approche apporte en effet de réels avantage telque une conception claire et efficace, un
gain de temps de maintenance et une très grande souplesse pour l’organisation du
développement de l’application.

2.7 CHOIX DU LANGAGE DU DEVELOPPEMENT

La spécification technique est primordiale pour la conception d’architecture, cette étape

regroupe toutes les contraintes sur les choix de la conception du système et son
développement.

Il y a des nombreuses alternatives pour créer des applications web et c’est grâce à la diversité
des technologies et le choix multiples de langage de développement, pour cela nous allons
étudier en cette partie le plus important type de langage :

Description Avantages inconvénients

PHP HyperText -Langage gratuit. -des failles de
Preprocessor -Son hébergement sécurité.
Ce langage est est supporté presque -manque de structure
interprété pour partout. il faut implémenter
création d’un site des cadres
web dynamique, la d’applications.
syntaxe provient du
langage C, perl et de
java. Ce langage est
soit associée a une
base de donnée tel
que MySQL dont la
possibilité d’inclure
le script PHP au sein

34
 d’une page HTML
pour une simplicité
d’interfaçage.
PYTHON Un langage de -Langage gratuit -Il faut implémenter
programmation objet -Simple à des cadres
multi-paradigme et comprendre. d’applications.
multiplateformes, il
favorise la -langage soutenu par
programmation Google.
oriente objet.
La syntaxe est
clairement séparée
des mécanismes de
bas niveau.
ASP.NET Il utiliser pour mettre -Ce code a une autre -Besoin d’une
en œuvre la création possibilité de licence pas gratuit.
des site web développer en -Son hébergement
dynamique, web VB.NET, est unique sur
services XML et des Framework.NET et Windows Server
applications web. c#. 2003,2008..
Cree par l’entreprise -Rapidité
Microsoft. d’exécution.

Tableau 5 Tableau comparatives des langages

Cette étude profonde nous dirige à choisir ASP.NET comme une technologie de
développement pour notre application.

2.8 CONCLUSION

Dans ce chapitre on a réalisé l’étude de l’existant et capturer les besoins du projet à réaliser.

En premier nous avons commencé par l’existant ensuite expose les besoins fonctionnels, non
fonctionnels et techniques de notre l’application.

Le prochain chapitre présentera la conception de l’application.

35
3 CONCEPTION

36
3.1 INTRODUCTION

Après avoir représenté la phase de spécification des besoins dans le chapitre précédant. Dans
ce chapitre nous décrirons d’une manière schématique les différents éléments du système en
s’appuyant sur le modèle des cinq vues introduites par Kruchten.

3.2 CONCEPTION GENERALE

3.2.1 FIGMA

Figma est une application de conception d’interface en ligne mais elle est en réalité plus que
ça, permet une collaboration en temps réel et en direct en équipe. Elle fournit des outils assez
faciles à comprendre, de prototypage et de génération du code pour un processus de
conception bien lisible.

Soit bien qu’elle s’exécute dans le navigateur il existe des versions de bureau Windows, MAC
OS.

L’un de ces atouts Figma offre une connectivité avec le client pour lancer une conception en
même temps s’il veut faire une suggestion en y apportant simultanément des modifications
pour ces conceptions et pour enfin mettre en œuvre immédiatement.

D’où un autre avantage primordial c’est la synchronisation ainsi le transfert des fichiers.

Et voilà comme le montre la figure18 l’interface de l’application Figma :

Figure 18 Figma

37
3.2.2 CONCEPTION DES MAQUETTE PRÉLIMINAIRE

Le graphisme d’une application web n’est pas juste artistique mais aussi une application qui
réponds aux qualités d’utilisation doit être bien facile et lisible pour un simple utilisateur.

Cette figure 19 représente le premier essai pour la page ajout user, après que l’administrateur
se connecte et il se dirige vers cette interface ou on trouve toutes les informations des
utilisateurs afin d’ajouter un nouvel utilisateur ou supprimer un utilisateur :

Figure 19 Proposition maquette pour page Home

Cette figure 20 représente le premier essai pour la page Login web afin de se connecter il faut
saisir son matricule :

38
 Figure 20 Proposition maquette pour page Login

3.3 LANGAGE UML

 Unified Modeling Language (UML) est connu comme un langage de modélisation descriptif
et textuel pour décrire et comprendre des besoins. Il est en effet utilisé en phase d’analyse et
conception.

Durant cette phase du projet nous avons choisi de travailler avec l’UML puisqu’il s’agit d’un
standard de modélisation et dispose de vues de haut niveau qui favorise la communication des
différents acteurs du système et qui a l’intérêt pour spécifier et visualiser les bons documents
pour un bon développement.

[ CITATION uml \l 1036 ]

3.3.1 LES 4+1 VUES DE KRUCHTEN

Le modelé 4+1 dit aussi de Kruchten .il permet d’élaborer le système en plusieurs vues
additionnel mais que chacune présente un point de vue différents qui permet chacune à leur
part de traiter séparément des divers intérêts en séparant en effet les préoccupations
fonctionnelles et les préoccupations extra fonctionnelles.

La figure 21 schématise les vues 4+1 de Kruchten :

39
 Figure 21 Vues de Kruchten

Ce modèle est composé de 5 vues :

 (1) Besoins des utilisateurs, se concentre sur la cohérence en présentant des scénarios
d’utilisation qui mettent en œuvre les éléments des quatre premières vues. Les
scénarios sont une abstraction des exigences fonctionnelles de l’application. Cette
dernière vue valide en quelque sorte les autres vues et assure la cohérence globale.
C’est aussi cette dernière vue qui est construite en premier, juste après l’établissement
du cahier des charges, pour fixer les contours du système à réaliser avec ses
fonctionnalités appelées, dans la terminologie UML, des cas d’utilisation.
 (2) vue logique, décrit les aspects statiques et dynamiques d’un système en termes de
classes, d’objets, de connexions et de communications. Elle se concentre sur
l’abstraction et l’encapsulation.
 (3) vue des processus, capte les aspects de concurrence et de synchronisation, et les
décompose en flux d’exécution (processus, fil d’exécution, etc.). Elle se rapporte aux
objets actifs et aux interactions
 (4) vu composant, représente l’organisation statique des modules (exécutable, codes
source, paquetages, etc.) dans l’environnement de développement
(5) vue de déploiement, décrit les différentes ressources matérielles et l’implantation
logicielle tenant compte de ces ressources. Donc, elle se rapporte aux nœuds physiques
d’exécution et au placement des objets sur les nœuds.[ CITATION kru \l 1036 ]

3.4 DIGRAMME DE CAS D’UTILISATION

Les diagrammes de cas d’utilisations donnent une vision globale du mouvement fonctionnelle
du système logiciel, d’où c’est élément essentiel de la modélisation. Un cas d’utilisation
permet l’interaction entre l’utilisateur au sens large (Acteurs) et un système.

40
Il relit les opérations faites par les utilisateurs et la sortie attendu par le système. Il se compose
de :

1. Un cas d’utilisation : représente un processus fourni par le système, décrit par un verbe
a l’infinitif affile par un complément pour description complète d’un besoin précis.
2. Un acteur : représente un rôle externe au système qui interagit avec ce dernier, un
même acteur peut jouer plusieurs rôles.
3. Une association : afin de relier les acteurs avec des cas d’utilisations, représenter par
une ligne qui relie un acteur avec son cas d’utilisation.

Cette figure 22 nous montre un exemple de ces trois éléments de base pour former un
diagramme de cas d’utilisation :

Figure 22 Exemple de diagramme de cas d'utilisation

3.4.1 IDENTIFICATONS DES ACTEURS

Acteurs Description
Administrateur C’est l’ordonnateur de l’application, il a l’accès totale
sur la base de données, gère tout le système et
détermine les utilisateurs et leur droit.
Agent filiale L’agent filiale c’est l’acteur qui a le droit
d’approuver, recevoir et envoyer les demandes a
l’agent siège.
Agent siège L’agent siège c’est l’acteur qui a le droit de prendre
la décision finale sur l’acceptation d’une demande
qui l’a reçu après sa vérification.
Demandeur Le demandeur c’est l’acteur qui a le droit de saisir
une demande et l’envoyer pour qu’elle soit traitée.
Tableau 6 Identification des acteurs

3.5 CAS D’UTILISATION GLOBALE

Le diagramme de la figure 23 présente les différentes fonctionnalités offertes à

l’administrateur mais ainsi aux utilisateurs. L’administrateur peut les utilisateurs, droits
d’accès, les Workflow en ajoutant, modifiant ou supprimer l’un d’eux.

41
Un utilisateur peut aussi gérer, envoyer et réceptionner des demandes.

Ce digramme suivant illustre ces opérations effectuées par ces acteurs :

Figure 23 cas d'utilisation globale

3.5.1 RAFFINEMENT DE CAS D’UTILISATION «  AUTHENTIFICATION  »

42
 Figure 24 Raffinement cas d’utilisation authentification

Acteur Administrateur/utilisateur
Précondition Authentification Windows ou entre login et mot de
passe.
Postcondition Ouverture de la session personnel
Scenario normal Ce cas est réalisé lorsque l’authentification Windows
ou saisie du login
Le système récupère la session de ce dernier et valide
les données saisies.
Scenario alternatif Ce cas lorsque la vérification des données saisies est
incorrecte d’où message d’erreur suite à l’échec
d’entrer.

Tableau 7 Authentification

3.5.2 RAFFINEMENT DE CAS D’UTILISATION «  GERER LES UTILISATEURS  »

43
 Figure 25 raffinement cas d’utilisation gérer les utilisateurs

Acteur Administrateur
Précondition Administrateur authentifier
Postcondition Ajouter/supprimer/modifier effectuer
Scenario normal L’administrateur doit saisir les informations
nécessaires selon le type d’utilisateur.

Scenario alternatif Si la saisie est invalide le système signale une erreur.

Tableau 8 gérer utilisateurs par l'administrateur

3.5.3 RAFFINEMENT DE CAS D’UTILISATION «  WORKFLOW DES DEMANDES »

44
 Figure 26 Raffinement cas d’utilisation pour le Workflow des demandes

Acteur Administrateur
Précondition Administrateur s’authentifier
Postcondition Réaliser un circuit pour l’ajout/supprimer/modifier
bien déterminer sur 3 acteurs :
-Demandeur
-Agent filiale
-Agent siège
Scenario normal Ce cas lorsque tous les donnes sont bien saisies et le
circuit (WF) est terminer.
Scenario alternatif Ce cas manque des informations sur le circuit,
message d’erreur.
Tableau 9 Workflow des demandes

3.5.4 RAFFINEMENT DE CAS D’UTILISATION «  RECEPTIONNER LES DEMANDES  »

45
 Figure 27 Raffinement cas d’utilisation pour la réception d’une demande

Acteur Agent filiale / Agent siège

Précondition S’authentifier selon son droit d’accès son interface
personnel est ouverte.
Postcondition La demande est reçue
Scenario normal L’agent est connecté et selon ces privilèges il reçoit
des demandes pour les traiter afin de les vérifier pour
enfin les envoyer suivant le circuit (WF) déterminer
auparavant.
Scenario alternatif Dans ce cas lors de l’envoi de demande manque des
informations à saisir, d’où un message d’erreur qui
s’affiche.
Tableau 10 réception d’une demande

3.5.5 RAFFINEMENT DE CAS D’UTILISATION «  TRAITER LES DEMANDES  »

46
 Figure 28 Raffinement cas d’utilisation traiter une demande

Acteur Agent filiale/ Agent siège

Précondition S’authentifier selon son droit d’accès son interface
personnel est ouverte.
Postcondition Une demande traiter et vérifier
Scenario normal L’agent a le droit de traiter les demandes qu’il l’a
reçu selon des critères soit l’accepter, modifier, ou la
refuser.
Pour enfin l’envoyer a l’agent d’après et que toute
décision prise est signalée devant le demandeur de
cette demande.
Scenario alternatif Dans ce cas soit l’agent ne détermine pas sa décision
sur la demande (favorable ou défavorable) d’où un
message d’erreur s’affiche pour lui demander de bien
saisir sa décision.
Tableau 11 traiter une demande

3.6 DIAGRAMME DE SÉQUENCE

Diagramme de séquence est un diagramme UML qui modélise dynamiquement une

application et identifie ces objets, pour représenter les messages entre les objets en cours
d’interaction plus particulièrement l’enchainement de ces objets entre elles.

Ce diagramme a deux dimensions :

1. Verticale : représente le temps c’est l’ordre d’envoi d’un message qui est déterminer
par la position sur l’axe verticale du diagramme qui s’écoule de haut en bas de cet axe.

47
 2. Horizontale : représente les acteurs, les objets leur ordres est sans importance.

Pour bien comprendre notre système nous proposons les diagrammes de séquences dans
les figures suivantes.

3.6.1 DIAGRAMME DE SÉQUENCE DU PROCESSUS «  AUTHENTIFICATION »

Figure 29 Diagramme de séquence "authentification"

3.6.2 DIAGRAMME DE SÉQUENCE AU PROCESSUS  « AJOUTER UN UTILISATEUR »

48
 Figure 30 Diagramme de séquence ajouter un utilisateur

3.6.3 DIAGRAMME DE SÉQUANCE AU PROCESSUS «  MODIFIER UN UTILISATEUR  »

49
 Figure 31 Diagramme de séquence modifier un utilisateur

3.6.4 DIAGRAMME DE SÉQANCE AU PROCESSUS «  SUPPRIMER UN UTILISATEUR  »

50
 Figure 32 Diagramme de séquence supprimer un utilisateur

3.6.5 DIAGRAMME DE SÉQUENCE AU PROCESSUS «  AJOUT WORKFLOW »

51
 Figure 33 diagramme de séquence ajout workflow

3.7 DIAGRAMME DE CLASSE

C’est une représentation statique des éléments qui composent un système et leurs relations et
qui permet de représenter toutes les entités d’un système.

Le diagramme de classe décrit les classe et les relations entre les classes, le fonctionnement
dynamique d’une classe pourra être modélise à travers des diagrammes d’état ou d’activités.

Les éléments du diagramme de classe sont :

Classe : s’agit d’un regroupement d’objet ayant le même caractéristique et le même

comportement.

Attribut : c’est une caractéristique, type associée simple.

Opération : c’est un comportement demande vers une autre classe.

52
 Figure 34 Diagramme de classe générale

3.8 DIAGRAMME DE PACKAGE

Pour bien structurer le modelé de données et regrouper des couches de présentation,

contrôleur et métier afin d’illustrer les différentes couches du système. Pour ce faire nous
utilisons la notion de package entant que concept générale d’UML.

En effet nous allons structurer les classes en trois couches principales :

Présentation, rassemblant toutes les classes dialogues.

Logique applicative, rassemblant toutes les classes contrôles.

Logique métier, rassemblant toutes les classes entités.

L’architecture logique de notre étude est représentée par ce diagramme de package comme
illustre par la figure 35 ;

Figure 35 Diagramme de Package

3.9 CONCLUSION

Dans ce chapitre nous avons décrit le processus de conception de notre application en

détaillant les diagrammes de cas d’utilisations, séquences et classes. Une phase très
importante est bien réalisée à ce stade.

53
Dans le chapitre suivant nous décririons à réalisation de notre application.

54
4 RÉALISATION TECHNIQUE

55
56
4.1 INTRODUCTION

Dans ce chapitre on présente l’environnement technique du travail ainsi le choix

d’environnement logiciel, puisque cette phase d’implémentation est la concrétisation finale du
projet d’où il faut savoir bien choisir les outils adéquats car ce choix influe sur la qualité du
produit finale et fait référence au résultat désiré.

Pour finir nous présentons quelques interfaces réaliser.

4.2 ENVIRONNEMENT DU TRAVAIL :

4.2.1 ENVIRONNEMENT MATÉRIEL

Pour la réalisation de notre projet, nous avons utilisé le matériel suivant :

Ordinateur portable HP : Caractéristique :

Système d’exploitation : Windows 7

Processus : Intel® core™ i5-5200U CPU @2.20GHz
RAM : 6.00Go

4.2.2 CHOIX TECHNIQUE

Pour la réalisation de notre application nous avons utilisé la technologie .Net de Microsoft
version 4,5.

Le Framework .Net :
Le Framework .Net est un Framework logiciel (structure) proposer par Microsoft qui
fonctionne principalement sur Microsoft Windows et il inclut une large bibliothèque
de classe (FCL) et assure l’interopérabilité des langages notamment les langages de
programmations. .Net permet de déployer et construire des application web, des
services web qui d’exécutes sur Windows, ainsi les .Net servers sont la nouvelle
génération des servers Microsoft.[ CITATION frameworknet \l 1036 ]
Cette figure 35 montre la structure du Framework.Net :

57
 Figure 36 Architecture du Framework.Net

Asp.Net :
C’est Framework qui permet d’engendre la demande des pages web dynamiques, des
applications web et web services XML. Lancé par Microsoft et accessible grâce à
l’installation d’un service web compatible ASP(IIS).[ CITATION Aspnet \l 1036 ]
Ajax :
AJAX (acronyme d'asynchronous JavaScript and XML : JavaScript et XML
asynchrones) [ CITATION ajax \l 1036 ]
C’est une architecture, méthode qui se base sur l’utilisation du javascript par des
requêtes, permet de construire des applications web et des sites web dynamiques sur le
poste client ainsi il offre une ergonomie dont seulement la modification de la partie de
page web qui nécessite d’être mise à jour par des requêtes HTTP locale soit en
modifiant tout ou une partie précise.

4.2.3 ENVIRONNEMENT LOGICIEL

Lors du développement de cette application, nous avons utilisé les outils logiciels suivants :

Visual Studio 2013 :

Un environnement de développement logiciel proposer par Microsoft qui est a la fois
numérique et de Reporting avec lequel le développement .Net devient plus facile et
simple.
Avec Visual Studio 13 on peut également :

58
  Gérer l’évolution des besoins tout au long du projet.
 Tester la qualité et la facilite des applications.

SQL Server 2012 :

SQL Server 2012 est un système de gestion des base données relationnelles (SGBD).
Développée et commercialisée par la société Microsoft.
Il intégrer des nouvelles fonctionnalités pour augmenter la puissance et la productivité
des développeurs et maintien des système de stockage de donnée
Il fonctionne sous les OS Windows et Linux (depuis mars 2016)[ CITATION sql12 \l 1036 ]
ISS 8.0 Express :
Internet Information Services, anciennement Internet Information Server,
communément appelé IIS [ CITATION iis \l 1036 ]
Le système d’exploitation Seven inclut le serveur web iis version 8 pour le routage
asp.net du MVC afin de router les requêtes qui proviennent du navigateur vers les
contrôleurs.

4.3 ILLUSTRATION DE L’UTILISATION E L’APPLICATION

Dans cette section qui suit, nous allons présenter un aperçu des interfaces fonctionnelles de
notre application.

4.3.1 INTERFACE D’AUTHENTIFICATION

Cette figure 36 montre la page de connexion de l’application Workflow Budget chaque

utilisateur introduit ces informations pour se connecter et bénéficier des différents services.

Figure 37 Interface d'authentification

59
4.3.2 INTERFACE ADMINISTRATEUR

Figure 38 Interface administrateur

En effet l’interface administrateur lui permet d’ajouter, supprimer et modifier un utilisateur.

Comme le montre la figure 38 suivante

Figure 39 Interface ajout Utilisateur

L’ajout d’un utilisateur en cliquant sur le bouton « Ajouter un utilisateur » comme la montre

la figure 39 suivante :

60
 Figure 40 Ajout utilisateur

L’administrateur a aussi le privilège de modifier les informations d’un utilisateur comme le

montre la figure 40 suivante :

Figure 41 Interface Modifier un utilisateur

4.3.3 INTERFACE WORKFLOW

Seul l’administrateur a le droit d’ajouter ou supprimer un circuit Workflow comme montre

cette figure 41 :

Figure 42 Interface Workflow

4.3.4 INTERFACE DEMANDEUR

61
Un utilisateur avec le rôle demandeur se dirige vers cette interface comme le montre la figure
42 suivante :

Figure 43 Interface demandeur

Suite à son choix de ces quatre types des demandes l’interface s’ouvre comme la montre cette
figure 43 :

Figure 44 Interface demande

Enfin pour passer une demande un formulaire s’ouvre en cliquant sur « Réviser » afin de
remplir les champs et valider sa demande comme montre ces deux figures 44/45 :

62
 Figure 45 Interface Passer une demande

Figure 46 Interface valider

4.3.5 INTERFACE VALIDATEUR

De même un utilisateur avec le rôle Validateur se trouve automatiquement dans cette interface
figure 46 :

63
 Figure 47 Interface Validateur

Un validateur filial ou siège doit traiter la demande dans le quelle il appartient dans le circuit
du workflow en cliquant sur « Valider » comme montre cette figure 47 et 48 :

Figure 48 Interface Valider demande

Figure 49 Interface de validation

4.3.6 INTERFACE HISTORIQUE

Afin de faire la suivie des demandes ont proposé d’afficher les historiques de chaque

demande saisit en cliquant sur « View » comme la montre ces deux figures 49  et 50:

64
 Figure 50 Interface Historique

Figure 51 Interface Historique demande

65
4.4 CONCLUSION

Dans ce dernier chapitre nous avons décrit l’environnement et les choix logiciels optes pour la
réalisation du projet.

Cependant il faut continuer à suivre et superviser l’application car cette phase de réalisation
ne sera jamais l’étape finale du processus d’un développement d’un bon logiciel afin
d’améliorer le produit et dans le but de détecter les éventuels bugs et anomalie pour assurer la
fiabilité du système.

66
5 CONCLUSION GENERALE

Ce rapport présente le travail réalisé dans le cadre d’un projet de fin d’études à l’institut
supérieur d’informatique et mathématique à Monastir, ce stage est effectué au sein de Poulina
Group Holding.

Notre projet de fin d’études consistant en l’analyse, la conception, réalisation et la mise en

œuvre d’un système de gestion budgétaire de PGH.

Pour la côte technologique, nous avons travaillé avec la technologie de Microsoft : ASP.Net
MVC qui introduit le concept Model View Control ayant comme caractéristique de travailler
avec les plus récentes normes mondiales.

Pour la réalisation des deux parties analyse et conception nous avons opté pour UML comme
langage de modélisation et XP comme processus de développement, durant la phase de
réalisation qui est à la fois enrichissante et instructive elle était une opportunité de travailler
dans un nouveau domaine qui nous a permis d’acquérir une importante expérience pour
familiariser avec des nouvelles technologies.

En effet il est possible d’ajouter des autres rebrique afin d’améliorer le système que nous
avons conçu, il est utile d’ajouter :

 Des alertes afin d’avertir les agents de toutes nouvelles actions faites.
 Opération de Reporting.
 Fonctionnalité de recherche.

67
6 BIBLIOGRAPHIE

[En ligne]. - http://www.poulinagroupholding.com/fr/structureholding/.

[En ligne]. - https://www.linxo.com/.

[En ligne]. - https://bankin.com/.

[En ligne]. - https://play.google.com/store/apps/details?id=ru.cardsmobile.mw3&hl=en_US.

[En ligne]. - https://publicdomainvectors.org/fr/tag/pictogramme.

[En ligne]. - https://jeremymouzin.com/blog/quel-langage-de-programmation-choisir-en-2019/.

[En ligne]. - https://medium.com/@saklynejmeddinne/mcv-mvp-ou-mvvm-quel-sch%C3%A9ma-de-d

%C3%A9veloppement-utilisez-vous-actuellement-44f6fe47cae3.

[En ligne]. - https://medium.com/@saklynejmeddinne/mcv-mvp-ou-mvvm-quel-sch%C3%A9ma-de-d

%C3%A9veloppement-utilisez-vous-actuellement-44f6fe47cae3.

[En ligne]. - https://fr.wikipedia.org/wiki/Framework_.NET.

[En ligne]. - https://fr.wikipedia.org/wiki/ASP.NET.

[En ligne]. - https://fr.wikipedia.org/wiki/Ajax_(informatique).

[En ligne]. - https://fr.wikipedia.org/wiki/Microsoft_SQL_Server.

[En ligne]. - https://fr.wikipedia.org/wiki/Internet_Information_Services.

DiagClasse [En ligne]. - https://fr.wikipedia.org/wiki/Diagramme_de_classes.

Figma Figma [En ligne] // Figma. - https://www.figma.com/files/recent.

instagantt [En ligne]. - https://instagantt.com/r#projects/5caa4dde99344c7468b5bc49/1117538842925700.

kruchten [En ligne] // kruchten. - http://www-inf.it-

sudparis.eu/COURS/CSC4002/EnLigne/Cours/CoursUML/3.4.html.

uml [En ligne] // uml. - https://fr.wikipedia.org/wiki/UML_(informatique).

68