Rapport pfe

REPUBLIQUE TUNISIENNE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE

SCIENTIFIQUE

DIRECTION GENERALE DES ETUDES TECHNOLOGIQUES

INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES DE RADES

Rapport de projet de fin d’études

Filière : développement systèmes d’informations

Intitulé du sujet :

Elaboré par:

Houssem Fathalli

Encadré par:

Encadreur de l’Entreprise : Souheyeb Mimouni

Enseignant Encadreur : Hamdi Ben Mefteh

Année universitaire : 2013/2014

Planification et Timesheet des projets de développement

informatique

ISET Radés | 2013-2014 Page | I

Dédicace

A mon père

Celui qui m’a indiqué la bonne voie en me rappelant que la volonté fait

toujours les grands hommes…

A ma Mère

Qui a attendu longtemps pour me voir terminer mes études avec

succès...

A toute ma famille, à tous mes amis et à tous ceux qui me sont si

chers…

Que Dieu les garde.

Houssem Fathalli

ISET Radés | 2013-2014 Page | II

Remerciements

Tout d’abord nous tenons à remercier l’entreprise d’accueil qui nous a offert cette

occasion si propice pour vivre une expérience professionnelle assez intéressante.

Un remerciement assez particulier est à adresser au Directeur du service de

l’informatique de la TRANSTU ainsi qu’au encadreur SOUHEYB MIMOUNI pour

tous les efforts consentis de leurs parts pour en nous garantissant toutes les

conditions nécessaires pour la réussite de ce projet.

De même des messages de respect sont à adresser aux enseignants de l’’ISET

RADES et en particulier notre enseignant encadreur Mr. HAMDI BEN MEFTAH

pour l'attention qu'il a apportée à notre projet tout au long de ses divers stades

allant de la conception à la réalisation et pour ces précieux conseils.

Toutefois nous sommes honorés par l'intérêt porté à ce rapport par les membres

du jury qui ont pris la peine d'évaluer cette étude, auxquels nous présentons notre

gratitude et notre profond respect.

ISET Radés | 2013-2014 Page | III

Sommaire

Introduction générale ................................................................................................................... 1

L’organisme d’accueil ................................................................................................................... 2

Introduction ......................................................................................................................................... 2

I. Présentation générale ............................................................................................................. 2

II. Présentation de la division informatique ................................................................................ 2

1. Définition ............................................................................................................................. 2

2. Organigramme ..................................................................................................................... 3

Etude préalable ............................................................................................................................ 4

Introduction ......................................................................................................................................... 4

I. Etude de l’existant ................................................................................................................... 4

II. Critique de l’existant ............................................................................................................... 6

III. Solution proposé ................................................................................................................. 6

IV. Chronogramme.................................................................................................................... 6

Conclusion ........................................................................................................................................... 7

Analyseet spécification des besoins .............................................................................................. 8

Introduction ......................................................................................................................................... 8

I. Méthode de conduite de projet .............................................................................................. 8

II. Identification des acteurs ........................................................................................................ 9

III. Les besoins fonctionnels et non fonctionnels ..................................................................... 9

1. Les besoins fonctionnels.................................................................................................... 10

2. Les besoins non fonctionnels ............................................................................................ 11

IV. Diagramme de cas d’utilisation globale ............................................................................ 12

V. Analyse du cas d’utilisation : Authentification ...................................................................... 14

VI. Analyse du cas d’utilisation : Gérer les comptes utilisateurs ............................................ 15

VII. Analyse du cas d’utilisation : Gérer les menus et modules ............................................... 18

VIII. Analyse du cas d’utilisation : Gérer les droits d’accès ....................................................... 21

IX. Analyse du cas d’utilisation : Gérer les projets ................................................................. 24

X. Analyse du cas d’utilisation : Affecter les taches aux collaborateurs ................................... 26

XI. Analyse du cas d’utilisation : Consulter diagramme de Gantt .......................................... 27

ISET Radés | 2013-2014 Page | IV

Conclusion ......................................................................................................................................... 28

Conception de « AGP » ............................................................................................................... 29

Introduction ....................................................................................................................................... 29

I. Choix de la méthodologie de conception .............................................................................. 29

1. UML ................................................................................................................................... 29

2. Les diagrammes UML ........................................................................................................ 30

II. Les diagrammes de séquences .............................................................................................. 30

1. Diagramme de séquences « S’authentifier » .................................................................... 31

2. Diagramme de séquences « créer un projet » .................................................................. 32

3. Diagramme de séquences « créer un module » ................................................................ 33

4. Diagramme de séquences « Créer une tache » ................................................................. 34

5. Diagramme de séquences « Saisir Timesheet » ................................................................ 35

6. Diagramme de séquence « Valider Timesheet » ............................................................... 36

III. Diagramme de classe ......................................................................................................... 38

Conclusion ......................................................................................................................................... 40

Réalisation de « AGP » ............................................................................................................... 41

Introduction ....................................................................................................................................... 41

I. Architecture du notre système.............................................................................................. 41

1. Architecture 3-tiers ........................................................................................................... 41

2. Approche MCV................................................................................................................... 42

II. Environnement de développement ...................................................................................... 43

1. Environnement matériel ................................................................................................... 43

2. Environment logiciel .......................................................................................................... 43

3. Les langages utilisés........................................................................................................... 44

4. Les API utilisés ................................................................................................................... 46

III. Présentation des interfaces ............................................................................................... 47

1. Interface « authentification » ............................................................................................ 47

2. Back-office de l’application ............................................................................................... 47

3. Front office de l’application .............................................................................................. 49

Conclusion ......................................................................................................................................... 55

Conclusion générale ................................................................................................................... 56

Bibliographies ............................................................................................................................ 57

Nethographies ........................................................................................................................... 58

ISET Radés | 2013-2014 Page | V

Liste des figures

Figure 1 : Organigramme ........................................................................................................... 3

Figure 2 : Interface du logiciel MS Project .................................................................................. 5

Figure 3 : Planning prévisionnel ................................................................................................. 7

Figure 4 : Cycle de vie du processus unifié.................................................................................. 9

Figure 5 : Diagramme de cas d’utilisation général .................................................................... 13

Figure 6 : Diagramme de cas d’utilisation « gérer les comptes utilisateurs » ............................. 15

Figure 7 : Diagramme de cas d’utilisation « gérer les menus et modules» ................................. 18

Figure 8 : Diagramme de cas d’utilisation « gérer les droits d’accès» ........................................ 21

Figure 9 : Diagramme de cas d’utilisation « gérer les projets » ................................................. 24

Figure 10 : Diagramme de séquences « s’authentifier » ............................................................. 31

Figure 11 : Diagramme de séquences « créer un projet » ........................................................... 32

Figure 12 : Diagramme de séquences « créer un module » ......................................................... 33

Figure 13 : Diagramme de séquences « créer une tache » .......................................................... 34

Figure 14 : Diagramme de séquences « Saisir Timesheet » ......................................................... 35

Figure 15 : Diagramme de séquences « Valider Timesheet » ...................................................... 37

Figure 16 : Diagramme des classes............................................................................................. 39

Figure 17 : L’architecture Trois-Tiers ......................................................................................... 42

Figure 18 : Page authentification .............................................................................................. 47

Figure 19 : Interface gestion des menus .................................................................................... 48

Figure 20 : Interface gestion des modules et droits ................................................................... 48

Figure 21 : Interface Affectation des droits ............................................................................... 49

Figure 22 : Page Menu principal................................................................................................ 49

Figure 23 : Page de création projet ........................................................................................... 50

Figure 24 : Page de création module ......................................................................................... 50

Figure 25 : Page de création Tache............................................................................................ 51

Figure 26 : Page gestion projets ................................................................................................ 51

Figure 27 : Page gestion Taches ................................................................................................ 52

Figure 28 : Interface affectation des Taches .............................................................................. 52

Figure 29 : Interface Consulter diagramme Gantt ...................................................................... 53

Figure 30 : Interface du Timesheet............................................................................................ 54

Figure 31 : Page Valider Timeshhet ........................................................................................... 55

ISET Radés | 2013-2014 Page | VI

Liste des tableaux

Tableau 1 : Tableau descriptif du cas d’utilisation «Authentification» ..................................... 14

Tableau 2 : Tableau descriptif du cas d’utilisation «Ajouter un nouveau compte utilisateur» ... 16

Tableau 3 : Tableau descriptif du cas d’utilisation «supprimer compte utilisateur» .................. 17

Tableau 4 : Tableau descriptif du cas d’utilisation «modifier compte utilisateur»..................... 18

Tableau 5 : Tableau descriptif du cas d’utilisation «Créer un menu» ........................................ 20

Tableau 6 : Tableau descriptif du cas d’utilisation «Créer un module» ..................................... 21

Tableau 7 : Tableau descriptif du cas d’utilisation «Créer un groupe des droits» ...................... 22

Tableau 8 : Tableau descriptif du cas d’utilisation «Créer un nouveau» ................................... 23

Tableau 9 : Tableau descriptif du cas d’utilisation «Affecter les droits aux profiles» ................. 23

Tableau 10 : Tableau descriptif du cas d’utilisation «Créer un projet» ....................................... 25

Tableau 11 : Tableau descriptif du cas d’utilisation «supprimer un projet» ................................ 26

Tableau 12 : Tableau descriptif du cas d’utilisation «affecter les taches aux collaborateurs» ...... 27

Tableau 13 : Tableau descriptif du cas d’utilisation «consulter diagramme de Gantt» ................ 28

Tableau 14 : Environnement de développement ....................................................................... 43

ISET Radés | 2013-2014 Page | VII

Liste des acronymes

UML : Unified Modeling Language

SI: Systèmes informations

MVC: Model-View-Controller:

JSON: JavaScript Object Notation

AJAX: Asynchronous JavaScript and Xml

ISET Radés | 2013-2014 Page | 1

Introduction générale

De nos jours, plusieurs faits conduisent à ce s’un projet puisse réussir ou échouer. En

effet les éléments clés pour les deux situations se trouvent centré sur le concept de gestion de

projet

La gestion de projet constitue donc pour les professionnels un véritable créneau à ne

pas manquer. Parmi ces nombreux avantages, elle permet notamment de réaliser des projets

de qualités qui répondent aux besoins des clients en respectant des deadlines, de bien gérer les

ressources nécessaires en terme du cout, du temps et de ressources humaines.

les entreprises cherchent à développer leurs environnements technologiques en terme

du gestion de projet afin de faciliter le bon déroulement des projets durant ses phases, limiter

les problèmes de retard, suivi et contrôler l’avancement du travail par les collaborateurs grâce

à une planification,..

C’est dans cette optique que se situe notre projet qui consiste à développer une

plateforme web pour la gestion des projets informatiques chez « Transtu ». Ce rapport

synthétise tout le travail que nous avons réalisé au cours de ce projet.

Afin de mener à terme notre projet, nous avons procédé à une étude qui s’étale sur

cinq volets essentiels. On commence par une partie concernant la présentation de l’entreprise

TRANSTU suivi d’une étude préalable. L’analyse et la spécification des besoins est traitée

dans le troisième chapitre, ensuite on expliquera d’une maniéré approfondie les

fonctionnalités de notre application.

Le dernier chapitre « réalisation » qui décrit l’environnement du travail, explique

techniquement le fonctionnement de notre application et présente ses principaux aperçus

graphiques. Enfin, nous clôturerons ce rapport par une conclusion générale qui synthétise le

présent travail et présente les perspectives envisagées.


Chapitre 1

L’organisme d’accueil

Introduction

Ce premier chapitre est consacré à la présentation de la société des Transports de

Tunis « TRANSTU » ainsi qu’une présentation un peu plus détaillée sur sa hiérarchie et son

domaine d’activité.

I. Présentation générale

La Société des Transports de Tunis dont la dénomination commerciale est Transtu, est

une entreprise publique chargée de la gestion du transport des passagers sur les réseaux

d'autobus et de métro léger de l’agglomération de Tunis ainsi que l'exploitation de la ligne

ferroviaire TGM.

Née en 2003 de la fusion entre la société nationale des transports(SNT) et la société du

métro léger de Tunis(SMLT), elle transporte chaque année 460 million de passagers.

II. Présentation de la division informatique

1. Définition

Le département informatique de la société des transports de Tunis veille à développer

un système d’information en utilisant des outils de traitement de l’information tout en

optimisant son temps de réponse. En plus, il veille au développement, la mise en place et la

mise à jour du manuel des procédures de l’entreprise.

Le département est composé de deux directions la première s’appelle Direction

informatique. Elle supervise le développement des logiciels et les outils de traitement de

l’information avec la qualité et la sécurité requises en matière de logiciels et de données. La

seconde direction c’est la direction organisation, elle assure le développement du Système

d’information.


2. Organigramme

L’organigramme ci-dessous (Figure1) présente un ensemble de deux directions centrales composées de différentes directions.

Figure 1 : Organigramme

Departement systéme

d'information

Direction organisation

Division gestion du systéme

d'information

Service du système

d'information

Service gestion des postes et des

droits d'accés

Direction informatique

Division exploitation informatiue

Service central exploitation informatique

Servic e exploitation des

sites annexes

Service maintenance du

matériel informatique

Division des réseaux

informatiques

Service administratif des bases de données

Service sécurité et gestion du

réseau

Division étude informatiue

Service développment

Service maintenance des

logiciels


Chapitre 2

Etude préalable

Introduction

Avant de prendre en charge un projet, une étude approfondie du marché et des

différentes solutions disponibles s’impose pour la réussite de ce dernier. C’est pour ce là,

dans ce chapitre nous présenterons l’étude approfondie que nous avons menée sur les

solutions existantes et nous terminerons en proposant une solution expliquée au maximum.

I. Etude de l’existant

La division informatique de la société des transports de Tunis lance des projets

informatiques tels que le développement de nouveaux logiciels, la maintenance des logiciels

existants et l’amélioration des systèmes. Elle confronte souvent à des contraintes de gestion

du projet, c’est-à-dire qu’un projet dépasse le délai limite proclamé de réalisation, la mal

gestion de l’équipe, la difficulté de suivi l’avancement du travail pour chaque agent. Tous ces

problèmes aboutissent à des solutions et produits de qualité médiocre. C’est pour cela, elle a

besoin d’un outil de gestion du projet qui répond à tous ses besoins.

Donc, une étude de l’existant permet une compréhension approfondie du domaine

d’études et un bilan critique de ce dernier, en d’autre terme, elle permet de connaître les

insuffisances et proposer des solutions pour les résoudre.

De nos jours, il existe des solutions et logiciels de gestion de projet qui sont devenus

essentiels à la mise en œuvre des activités de l'entreprise en termes de suivi et coordination

des travaux de groupe, contrôle des flux d’informations, respect des deadlines et maitrise des

couts.

Ses outils de gestion de projet offrent des fonctionnalités tels que :


Planification et monitoring des activités :

C'est l'une des principales fonctionnalités des logiciels de gestion de projet, qui sont en

premier lieu des outils de gestion du temps, ils permettent de :

Maitrise des couts :

La gestion du temps, des ressources humaines, et des personnes est bien sûr imbriquée

aux aspects de gestion financière d'un projet. Ces logiciels sont censés permettre de finaliser

l'ensemble d'un projet dans les délais correspondant au budget alloué à celui-ci.

Distribution, partage et gestion des flux d’informations:

Les logiciels de gestion de projet permettent de fournir des informations de différents

niveaux (partagées ou non) aux membres d'un projet -managers et/ou collaborateurs. [B1]

L’étude approfondie des solutions disponibles jusqu’à présentes montre qu’il Ya une

multitude des solutions qui répond à tous les besoins espérés par les clients dans ce secteur.

On cite par exemple, le célébré et le fameux logiciel édité par Microsoft « MS Project », il

permet aux chefs de projet et aux planificateurs de planifier et piloter les projets, de gérer les

ressources et le budget, ainsi que d'analyser et communiquer les données des projets.

Primavera ProjectPlaner qui est aussi un logiciel complet et très performant, il est réservé

néanmoins aux spécialistes.

Autres : planView, Genius Project, Gantt Project, ProjectLibre,..

Figure 2 : Interface du logiciel MS Project


II. Critique de l’existant

En effet, et malgré de tous ses outils que ce soit gratuits ou payants, il n’y a pas encore

de solution parfaite qui répond à tous les besoins espérés par les entreprises, tels que dans

notre cas : la gestion des collaborateurs et des droits accès, la saisie du Timesheet, le suivi de

l’avancement selon des critères,..

III. Solution proposé

Notre proposition consiste à : Concevoir et implémenter une plateforme de gestion de

projet qui apporte une solution efficace, répond aux exigences de l’entreprise, simple à utiliser

et moins coûteuse que celles commercialisées actuellement. Cette dernière permet à son

utilisateur « société Transtu » de gérer ses projets informatiques et contrôler l’avancement de

ses projets par les membres de l’équipe.

En résumé, l’application offre à l’entreprise un bouquet de fonctions très utiles tel

que :

Une décomposition des projets en des sous-projets « Modules » et en des taches.

Permet de planifier les projets en ordonnançant les taches, estimation des charges

en termes de temps et ressources humaines et affecter ses ressources aux taches.

Permet de visualiser une présentation graphique détaillé et structuré d’un projet

grâce à un diagramme de Gantt.

Remplissage d’un calendrier de tâches « Timesheet »par un collaborateur qui

montre ses activités pour les taches qui lui affecté.

Offre une meilleure solution pour le suivi de l’avancement du projet.

Nous appellerons notre application « AGP ».

IV. Chronogramme

La clé principale de la réussite d’un projet est un bon planning. En effet, le planning

aide à bien subdiviser le travail et séparer les taches à réaliser, il offre une meilleure

estimation et gestion de temps nécessaire pour chaque tâche. De plus, il donne assez de

visibilité permettant d’estimer approximativement la date d’achèvement de chaque tâche.


Dans notre projet, nous avons estimé de réaliser notre application dans une durée

approximative de 4 mois. Le diagramme ci-dessous montre le planning que nous avons adapté

pour mener à bien notre réalisation des différentes parties du projet :

L’étude préalable : le résultat de cette phase est la détermination des objectifs à

atteindre dans notre future application en partant de l’existant.

Conception : il s’agit de détailler les spécifications des fonctions ainsi que la structure

des données, des contrôles et des interfaces.

Réalisation : il s’agit de réaliser l’implémentation des programmes et effectuer les

tests unitaires.

Test et validation : il s ‘agit de tester notre plateforme.

Rédaction du rapport : description détaillée de notre travail.

Le chronogramme ci-après schématise la chronologie de ces étapes durant la période

du projet.

Figure 3 : Planning prévisionnel

Conclusion

A travers ce chapitre nous avons établi une étude détaillée des différentes solutions

disponibles, nous avons aussi mis le projet dans son cadre général, défini les objectifs à

atteindre et les principales fonctionnalités.

Dans le chapitre qui suit nous allons détailler l’analyse des besoins de notre

application.


Chapitre3

Analyse et spécification des besoins

Introduction

L'analyse des besoins, première phase de réalisation d'un projet, conditionne sa

réussite dans la mesure où elle définit les besoins réels de ceux qui vont utiliser le résultat

final. C’est la phase de communication et d'échange, elle est souvent le reflet du résultat final.

Nécessitant rigueur et méthode, c'est l'une des phases les plus difficiles de la conduite de

projet.

I. Méthode de conduite de projet

Au cours du développement des projets informatiques, il est impératif de respecter la

démarche qui a été élaborée dans la phase de préparation. De ce fait, dans notre projet, nous

avons tracé et suivi un plan de travail minutieux, qui nous a permis de mieux gérer les

différentes phases de réalisation de l’application.

Le cycle de vie d’un projet informatique est une succession ordonnée d’étapes

dynamiques, évolutives et toujours progressives, permet de détecter les erreurs au plus tôt et

de les maîtriser pour une meilleure qualité du logiciel, les délais de sa réalisation et les coûts

associés. Le cycle de vie a été découpé en une série d’étapes en vue de définir des jalons

intermédiaires permettant la validation du logiciel (la conformité du logiciel au cahier des

charges) et la vérification du processus de développement (adéquation des méthodes mises en

œuvre). La séquence et la présence de chacune de ces activités dans le cycle de vie dépendent

du choix d'un modèle de cycle de vie entre le client et l'équipe de développement.

On peut regrouper les diverses modèle de conduite d’un projet informatique qui

existes en deux grandes familles : les méthodes séquentielles et les méthodes itératives.

Le processus que nous proposons de suivre pour le développement de notre

application est le processus unifié (UP, Unified Process). Ce dernier est un processus de


développement logiciel « itératif et incrémental, centré sur l’architecture, conduit par les cas

d’utilisation et piloté par les risques ». [N1]

Figure 4 : Cycle de vie du processus unifié

II. Identification des acteurs

Pour notre cas, il existe quatre types d’utilisateurs

L’administrateur : il est responsable de la gestion des comptes utilisateurs et

des droits d’accès, la gestion des menus et des modules.

Planificateur : c’est la personne qui gère les projets et ses modules en

l’affectant à des collaborateurs.

Collaborateur : c’est l’utilisateur qui enregistre ses activités dans un

timesheet.

Superviseur : c’est le super-collaborateur qui consulte les projets auxquels il

est affecté ainsi que ses collaborateurs et valider le timesheet.

III. Les besoins fonctionnels et non fonctionnels

L’étude faite durant la phase de pré-analyse sert généralement de point de départ pour

décrire sans ambiguïté l’application à développer. C’est pourquoi il est fondamental, au cours

de ces phases, de déterminer l’adéquation entre les besoins exprimés des utilisateurs et les


traitements envisageables. Pour assurer cet objectif, il est essentiel d’avoir une vue claire et

précise des besoins.

1. Les besoins fonctionnels

Notre application devra regrouper toutes les fonctionnalités qui permettent de

satisfaire tous les besoins de l’entreprise

S’authentifier : Par crainte d’une mauvaise manipulation ou un accès non autorisé, la

phase de l’authentification sévère primordiale lors du lancement de l’application pour

contrôler l’accès.

a. Besoins du point de vue collaborateur

Consulter diagramme de Gantt : chaque collaborateur et superviseur peuvent voir le

diagramme de Gantt associé afin de consulter les taches auxquels ils sont affectés.

Saisir Timesheet : après avoir consulté ces Diagrammes de Gantt, le superviseur et les

collaborateurs auront la possibilitéde saisir ces activités dans un calendrier « Time

Sheet ».

Valider Timesheet : Le superviseur aura la possibilité de valider le timesheet de ces

collaborateurs en faisant une comparaison de ce qui est planifié ainsi de ce qui est fait.

b. Besoins du point de vue planificateur

Gérer les projets : Ce module permet au planificateur de gérer les projets (créer,

modifier et supprimer).

Gérer les modules : Cette partie assure la gestion des modules pour chaque projet

(créer, modifier et supprimer).

Gérer les taches : Similaire à la dernière fonction, celle-ci permet la gestion des

taches de ces modules ainsi des taches séparés qui sont non reliés à des projets (créer,


Affecter les taches aux collaborateurs : grâce à ce module, le planificateur est

capable d’affecter des taches à des collaborateurs et superviseur.

Elaborer un diagramme de Gantt : seul le planificateur a le droit de générer un

diagramme de Gantt détaillé d’un projet qui contient la liste des modules et ses taches

pour chaque projet.


c. Besoins du point de vue administrateur

Gérer les menus et modules : cette section permet à l’administrateur de créer des

menus qui sont dynamiques et des modules et d’affecter les interfaces de ces modules

à des menus.

Gérer les comptes utilisateurs : grâce à des interfaces agréables et faciles,

l’administrateur sera chargé de gérer les différents comptes des utilisateurs (ajouter,


Gérer les droits d’accès : l’administrateur sera chargé aussi des créer des droits et de

l’affecter à des profils.

2. Les besoins non fonctionnels

Les besoins non fonctionnels présentent les exigences internes qui ne concernent pas

spécifiquement le comportement du système vis-à-vis de l’utilisateur, qui doivent avoir des

valeurs qualitatives et qui sont cachées aux utilisateurs.

Les besoins non fonctionnels ou options de notre application s’appuient

principalement sur trois points :

1. La convivialité : L’application doit être facile à utiliser. Les interfaces doivent être

conviviales, simples, ergonomiques, et adaptées à l’utilisateur.

2. La performance : La plateforme à développer doit être performante à travers ses

fonctionnalités et répond à toutes les exigences des usagers d’une manière optimale.

3. La sécurité : chaque utilisateur doit s’identifier avant d’accéder à sa propre interface.

Maintenant nous expliquons les besoins en les classant en deux groupes :

a. Contraintes ergonomiques :

L’interface de notre application doit assurer une interaction avec l’utilisateur en

présentant, des informations claires et précises.

L’utilisateur est guidé lors de la saisie de certaines informations, afin de respecter les

formats des champs de la base de données.

b. Contraintes techniques

Le système doit assurer la sécurité et la confidentialité des données.

L’accès à la base de données doit être souple et rapide.


Le choix se fera sur une liste de valeurs rattachées aux champs afin d’assurer le

contrôle de la saisie.

La flexibilité : il doit exister des facilités de modifier l’application.

Espace de stockage des données suffisant.

Temps de réponse minimum.

IV. Diagramme de cas d’utilisation globale

Chaque usage que l’acteur fait du système est représenté par un cas d’utilisation.

Chaque cas d’utilisation représente une fonctionnalité qui lui est offerte afin de produire le

résultat escompté.

Ainsi, le diagramme de cas d’utilisation décrit l’interaction entre le système et l’acteur

en déterminant les besoins de l’utilisateur.

La Figure 5, donne une représentation du diagramme de cas d’utilisation général de

notre système :


.

Figure 5 : Diagramme de cas d’utilisation général


V. Analyse du cas d’utilisation : Authentification

Description :

Sommaire d’identification

Titre : Authentification

Résumé : Le système s’assure de l’identité de l’utilisateur à travers son login et son mot de

passe.

Acteurs : Tout acteur

Pré-conditions :

Chaque utilisateur doit avoir un compte.

Post-condition :

L’administrateur accède à la partie administration.

Le planificateur accède à l’interface de gestion des projets.

Le collaborateur accède à son compte personnel.

Description des enchaînements :

Scénario nominal

Action de l’acteur Réactions du système

1. L’utilisateur demande l’accès à

l’application.

3. Saisie son login et son mot de passe.

2. Affiche le formulaire d’authentification.

4. Vérifie les champs.

5. Affiche l’interface principale appropriée.

Enchaînement alternatif :

1. Les champs login et mot de passe sont non valides et/ou vides

a. Le système affiche un message d’erreur.

b. Le scénario reprend à partir de 2.

Tableau 1 : Tableau descriptif du cas d’utilisation «Authentification»


VI. Analyse du cas d’utilisation : Gérer les comptes utilisateurs

La figure 6 représente le diagramme de cas d’utilisation relatif au cas « Gérer les

comptes utilisateurs ».

Figure 6 : Diagramme de cas d’utilisation « gérer les comptes utilisateurs »

Description 1:


Titre : Ajouter un nouveau compte utilisateur.

Résumé : Un nouveau compte pour un nouvel utilisateur.

Acteurs : Administrateur.

Pré conditions :

Authentification réussie.

Seul l’administrateur (qui dispose d’un accès absolu) peut ajouter, modifier ou

supprimer des comptes (les planificateurs et les collaborateurs ne peuvent pas

modifier leurs comptes, les modifier ou les supprimer).

L’administrateur choisit le service puis le profil approprié.

Post-condition :

Un message s’affiche pour informer que le compte a été bien crée.


Scénario nominal


1. L’administrateur demande la fenêtre de

création d’un nouveau compte.


3. Introduit les informations.

2. Affiche une fenêtre contenant des champs

vides.

4. Vérifie si les champs obligatoires ont été

remplis.

5. Vérifie si le compte existe déjà.

6. Enregistre les informations du nouveau

compte dans sa base de données.

7. Affiche un message pour informer

l’utilisateur de la bonne exécution de

l’opération.


1. Si l’administrateur oublie un ou des champs obligatoires :

a. Le système affiche un message l’invitant à les compléter.


2. Si le compte existe déjà :

a. Le système on informe l’administrateur.


Tableau 2 : Tableau descriptif du cas d’utilisation «Ajouter un nouveau compte utilisateur»

Description 2:


Titre : Supprimer un compte utilisateur.

Résumé : L’administrateur peut supprimer le compte d’un utilisateur.

Acteurs : L’administrateur.

Pré conditions :


Le compte qu’on désir supprimer existe.

Post-condition :

Le compte en question est supprimé.



Scénario nominal


1. Demande la liste des comptes existants.

3. Sélectionner un compte et demander au

système de le supprimer.

2. le système affiche une fenêtre contenant

une liste des comptes.

4. Demande de confirmation.

5. Le système supprime le compte choisi au

niveau du page web et de la base de données.



l’opération.

Tableau 3 : Tableau descriptif du cas d’utilisation «supprimer compte utilisateur»

Description 3:


Titre : Modifier un compte utilisateur.

Résumé : L’administrateur peut modifier le compte d’un utilisateur.


Pré conditions :


Le compte qu’on désire modifier existe.

Post-condition :

Le compte est modifié.


Scénario nominal


1. Demande la liste des comptes existants.

2. L’administrateur sélectionne un compte et


demande la fenêtre de modification.

3. réintroduire les informations.

3. Affiche une fenêtre contenant des champs

non vides.

4. Vérifie si les champs obligatoires sont

remplis.

5. Modifie les informations du compte dans

la page web et dans sa base de données.



l’opération.


1. Si l’utilisateur oublie un champ obligatoire :

c. Le système affiche un message l’invitant à les remplir.

d. Le scénario reprend à partir de 2.

Tableau 4 : Tableau descriptif du cas d’utilisation «modifier compte utilisateur»

VII. Analyse du cas d’utilisation : Gérer les menus et modules

La figure 7 représente le diagramme de cas d’utilisation relatif au cas « Gérer les

menus et modules ».

Figure 7 : Diagramme de cas d’utilisation « gérer les menus et modules»


Description 1:


Titre : Créer un menu

Résumé : Permettre à l’administrateur de créer de nouveaux menus qui sont dynamiques.


Pré conditions :


Seul l’administrateur qui peut ajouter des menus.

Post-condition :

Un message s’affiche pour informer que le menu a été bien crée.


Scénario nominal



création d’un nouveau menu.

3. Introduit le nom du menu.

2. Affiche une fenêtre contenant un champ

vide pour le nom du menu.

4. Vérifie si le champ a été bien rempli.

5. Vérifie si le nom existe déjà.

6. Enregistre le nouveau menu dans la liste

des menus et dans la base de données.



l’opération.


1. Si l’administrateur laisse le champ vide:

e. Le système affiche un message l’invitant à le saisir.

f. Le scénario reprend à partir de 3.

2. Si le menu existe déjà :

c. Le système on informe l’administrateur.


d. Le scénario reprend à partir de 3.

Tableau 5 : Tableau descriptif du cas d’utilisation «Créer un menu»

De même l’administrateur peut renommer au supprimer chaque menu.

Description 2:


Titre : Créer un nouveau module.

Résumé : Cette partie assure la création des modules qui contient tous les interfaces et les

fonctions programmables.


Pré conditions :


Seul l’administrateur qui peut créer des modules.

Post-condition :

Un message s’affiche pour informer que le module a été bien ajouté.


Scénario nominal


1. Demande la fenêtre d’ajout d’un nouveau

module.

3. Saisie le nom du module.

2. Affiche la fenêtre désirée contenant un

champ vide.

4. Vérifie si le champ a été bien rempli.

5. Crée un package dans l’arborescence du

projet

6. Informe l’admin du résultat de l’action.



1. Si le propriétaire laisse le champ vide:

a. Le système affiche un message l’invitant à remplir la donnée.


Tableau 6 : Tableau descriptif du cas d’utilisation «Créer un module»

VIII. Analyse du cas d’utilisation : Gérer les droits d’accès

La figure 8 représente le diagramme de cas d’utilisation relatif au cas « Gérer les droits

d’accès».

Figure 8 : Diagramme de cas d’utilisation « gérer les droits d’accès»

Description 1 :


Titre : Créer un groupe de droits.

Résumé : L’administrateur peut ajouter un groupe de droits qui renferme un ensemble de droits.


Pré conditions :


Post-condition :

Un message s’affiche pour informer que le groupe de droits a été bien crée.



Scénario nominal



création du groupe de droits.

3. remplit le champ du formulaire.

2. Affiche une fenêtre contenant un champ vide.

4. Enregistre le groupe des droits dans la liste et

dans la base de données.

Tableau 7 : Tableau descriptif du cas d’utilisation «Créer un groupe des droits»

De même, l’administrateur peut supprimer un groupe des droits.

Description 2 :


Titre : Créer un nouveau droit.

Résumé : L’administrateur peut créer un droit.


Pré conditions :


Groupe de droits existe.

Post-condition :

Un message s’affiche pour informer que le droit a été bien crée.


Scénario nominal


1. L’administrateur accède à la liste du

groupe des droits.

2. Choisit un groupe des droits

3. Demande l’interface de création du

nouveau droit.


5. Saisit le nom du droit.

4. Affiche une fenêtre contenant un champ vide.

4. Enregistre le droit dans la liste et dans la base

de données.

Tableau 8 : Tableau descriptif du cas d’utilisation «Créer un nouveau»

Description 3 :


Titre : Affecter les droits aux profiles.

Résumé : L’administrateur affecte un ensemble des droits à des profiles


Pré conditions : Authentification réussie.

Post-condition : Un profile possède des droits d’accès.


Scénario nominal


1. Demande l’interface d’affectation des

droits.

2. Choisir un profile.

4. sélectionne les droits à affecter.

3. charge une liste des droits sur les fonctions

et les interfaces.

5. Enregistre la modification dans la base de

données.

Tableau 9 : Tableau descriptif du cas d’utilisation «Affecter les droits aux profiles»


IX. Analyse du cas d’utilisation : Gérer les projets

La figure 9 représente le diagramme de cas d’utilisation relatif au cas « gérer les projets ».

Figure 9 : Diagramme de cas d’utilisation « gérer les projets »

Description 1 :


Titre : Ajouter un nouveau projet.

Résumé : Permet au planificateur de créer un nouveau projet.

Acteurs : Planificateur.


Seul le planificateur a le droit d’ajouter un nouveau projet.

Post-condition :

Le nouveau projet est créé.


Scénario nominal


1. Demande la fenêtre de création d’un

projet.

2. Affiche la fenêtre avec des champs vides.


3. Introduit les informations nécessaires (titre

du projet et les dates de début et de fin).

4. Vérifie si le nouveau projet est enregistré.

5. Ajoute le nouveau projet dans la base de

données.

6. Informe le planificateur du résultat de

l’action.

Enchaînement alternatif : 1. Si le planificateur oublie un/des champs obligatoires:

a. Le système affiche un message pour l’invitera saisir l’information manquante.


2. Si le projet existe déjà :

a. Le système on informe l’administrateur.


Tableau 10 : Tableau descriptif du cas d’utilisation «Créer un projet»

Description 2 :


Titre : Supprimer un projet.

Résumé : Permet au planificateur de supprimer une pièce.

Acteurs : planificateur.


Le projet existe déjà.

Post-condition : Le projet en question est supprimé.


Scénario nominal


1. Demande la liste des projets.


3. Choisie un projet et demande sa

suppression.

2. Affiche une fenêtre contenant la liste des

projets enregistrés.

4. Demande de confirmation de l’action.

5. Supprime le projet au niveau de la basse

de données de l’application.

6. Informe le propriétaire du résultat de

l’action.

Tableau 11 : Tableau descriptif du cas d’utilisation «supprimer un projet»

De même, le planificateur peut gérer les modules des projets (ajouter-modifier-supprimer) et

les taches (ajouter-modifier-supprimer).

X. Analyse du cas d’utilisation : Affecter les taches aux

collaborateurs

Description :


Titre : Affecter les taches aux collaborateurs.

Résumé : Le planificateur affecte les taches aux collaborateurs.

Acteurs : Le planificateur.


Listes des taches non pas encore affectés existent.

Les collaborateurs en question existent.

Post-condition : Taches affectés


Scénario nominal


1. Demande l’interface d’affectation.


4. Affecte les taches aux collaborateurs.

2. Charge la liste des taches non affectés et

l’afficher.

3. Charge la listes des collaborateurs et

l’affecter.

5. Supprime les taches au niveau des listes

des non affectés

6. Enregistre la modification dans la base de

données.

Tableau 12 : Tableau descriptif du cas d’utilisation «affecter les taches aux collaborateurs»

XI. Analyse du cas d’utilisation : Consulter diagramme de Gantt

Description :


Titre : Consulter diagramme de Gantt

Résumé : L’utilisateur visualise le diagramme de Gantt du chaque projet, et des tache non

liée.

Acteurs : Le planificateur, le collaborateur et superviseur.


Seul le planificateur a le droit de visualiser le diagramme de Gantt de tous les projets

Le collaborateur visualise son propre diagramme de Gantt.

Le superviseur consulte son diagramme de Gantt ainsi de ses collaborateurs.

Post-condition : Diagramme de Gantt affiché.


Scénario nominal


1. Demande l’interface de consultation

diagramme de Gantt.

2. Affiche l’interface appropriée.


3. Sélectionne un projet ou bien tache non

liée.

4. Affiche un diagramme de Gantt détaillé.

Tableau 13 : Tableau descriptif du cas d’utilisation «consulter diagramme de Gantt»

Conclusion

L’analyse présentée dans ce chapitre nous a permis de créer une spécification

complète des besoins issus du diagramme de cas d’utilisation et de les structurer sous une

forme qui facilite la compréhension et qui ébauche la partie de conception. Dans le chapitre

qui suit, nous nous intéresserons à la conception.


Chapitre 4

Conception de « AGP »

Introduction

Après avoir étudié les besoins et choisi une solution qui répond à la problématique,

nous nous aborderons la phase de conception. Dans cette partie, nous allons décrire la

structure physique du système via des diagrammes de classes, ainsi que le fonctionnement du

système via des diagrammes de séquences.

Cette section est primordiale pour comprendre la manière de fonctionnement de notre

application. En d’autres termes, elle présente les aspects statiques et dynamiques du système.

I. Choix de la méthodologie de conception

La modélisation consiste à créer une représentation virtuelle d'une réalité de telle façon

à faire ressortir les points auxquels nous nous intéressons. Elle nous offre un support évolutif

des données nécessaires pour la réalisation de l’application.

On trouve de nos jours plusieurs méthodes de modélisation, mais nous allons limiter

notre étude au modèle le plus reconnu « UML » (Unified Modeling Language) car il est la

plus utilisée par la majorité des programmeurs.

1. UML

UML est un langage de modélisation utilisé à la fois par l’homme et les machines.

Nous avons sélectionné l’UML pour le fait qu’il n'impose pas de méthode de travail

particulière car il peut être intégré à n'importe quel processus de développement de logiciel de

manière transparente, comme une boîte à outils qui permet d'améliorer progressivement les

méthodes de travail, tout en préservant les modes de fonctionnement.


2. Les diagrammes UML

Une vue est constituée d'un ou plusieurs diagrammes. On distingue deux types de vues: [B2]

La vue statiques, permettant de représenter le système physiquement :

Diagrammes de classes: représentent des collections d'éléments de modélisation

statiques (classes, paquetages...), qui montrent la structure d'un modèle.

Diagrammes d'objets: ces diagrammes montrent des objets (instances classes

dans un état particulier) et des liens (relations sémantiques) entre objets.

Diagrammes de cas d'utilisation: identifient les utilisateurs du système (acteurs)

et leurs interactions avec le système.

Diagrammes de composants: permettent de décrire l'architecture physique

statique d'une application en termes de modules : fichiers sources, librairie

exécutables, etc.

Diagrammes de déploiement: montrent la disposition physique du matériel qui

compose le système et la répartition des composants sur ce matériel.

La vue dynamiques, montrant le fonctionnement du système :

Diagrammes de collaboration: montrent des interactions entre objet (instances

de classes et acteurs).

Diagrammes de séquence: permettent de représenter des collaborations eu objets

selon un point de vue temporel, on y met l'accent sur la chronologie (envois de

messages).

Diagrammes d'états-transitions: permettent de décrire les changements d'états

d'un objet ou d'un composant, en réponse aux interactions avec d'autres

objets/composants ou avec des acteurs.

Diagrammes d'activités: (une variante des diagrammes d'états-transitions)

servent à représenter graphiquement le comportement d'une méthode ou

déroulement d'un cas d'utilisation.

II. Les diagrammes de séquences

Le diagramme de séquences permet de représenter des collaborations entre objets

selon un point de vue temporel, on y met l’accent sur la chronologie des envois des messages.


Il peut servir à illustrer un cas d’utilisation. En effet, l’identification des cas d’utilisation de

notre système dans le chapitre spécification et leurs représentations graphiques apporte

seulement une connaissance sur l’interface externe de l’application. Nous allons donc montrer

les plus importants scénarios qui peuvent avoir lieu. [N2]

1. Diagramme de séquences « S’authentifier »

Afin d’accéder à l’application, l’utilisateur doit introduire son login et mot de passe

pour accéder chacun à son interface adéquate. Une fois les paramètres sont introduits le

système vérifie l’existence dans la base de données, si l’authentification est réussie l’interface

principale est affichée.

La figure 10 représente le diagramme de séquence relatif au cas « S’authentifier ».

Figure 10 : Diagramme de séquences « s’authentifier »


2. Diagramme de séquences « créer un projet »

Après avoir être authentifié, Le planificateur peut créer de nouveaux projets. Il accède

à sa partie personnelle et il remplit un formulaire contenant quelques informations concernant

les détails d’un projet.

La figure 11 représente le diagramme de séquence relatif au cas « Créer un nouveau

projet ».

Figure 11 : Diagramme de séquences « créer un projet »


3. Diagramme de séquences « créer un module »

Une fois, le projet est créé, le planificateur doit créer les modules du chaque projet. Il

doit remplir un formulaire qui contient les détails d’un module tels que titre, date de début et

date de fin.

La figure 12 représente le diagramme de séquence relatif au cas « Créer un module ».

Figure 12 : Diagramme de séquences « créer un module »


4. Diagramme de séquences « Créer une tache »

La chose qui reste, c’est de créer les taches des modules. Pour ce faire, le planificateur

doit saisir les données d’une tache en choisissant le module parent et la tache antécédente.

La figure 13 représente le diagramme de séquence relatif au cas « Créer une tache ».

Figure 13 : Diagramme de séquences « créer une tache »


5. Diagramme de séquences « Saisir Timesheet »

Le planificateur doit modifier le planning de ses taches dans le calendrier en saisissant

les dates de réalisation. Le système vérifie l’état de la tâche, Si la tâche a été validé par le

superviseur, le système ne lui permet pas de la modifier.

La figure 14 représente le diagramme de séquence relatif au cas « Saisir timesheet ».

Figure 14 : Diagramme de séquences « Saisir Timesheet »


6. Diagramme de séquence « Valider Timesheet »

Une fois, le planificateur termine son timesheet, son superviseur doit valider le travail.

Pour ce faire, le système récupère la liste des collaborateurs, et la listes des projets pour

chaque collaborateur afin de valider ses taches.

La figure 15 représente le diagramme de séquence relatif au cas « valider timesheet ».


Figure 15 : Diagramme de séquences « Valider Timesheet »

sd_valider timesheet

chousir_tache(idtache)

modifier_tache(idtache,idetat)

afficher(msg)

return(msg)


envoyer(idtache,idetat)

choisir_etat_tache(idetat)

afficher_listTaches()

return(lisTaches)

selectioner_list_tache(idUtil,idModule)recuperer_listTaches(idUtil,idModule)

envoyer(idUtil,idModule)

choisir_module(idModule)

afficher_listModules()

return(listModules)

selectioner_listModule(idUtil,idProjet)récupérer_listModules(idUtil,idProjet)

envoyer(idUtil,idProjet)

choisir_ projet(idProjet)

afficher_listprojets()

return(listprojets)

Selectioner_listProjet()

récupérer_listprojets(idutil)

envoyer(idutil)

choisir_collaborateur(idutil)

afficher(listCollaborateurs)

return(listCollaborateurs)

selectionner_listCollaborateurs()

récupérer_listCollaborateurs()

Planificateur

Interface validation

timesheetcontroller Timesheet :Tache:Projet :Module:util isateur

chousir_tache(idtache)


afficher(msg)

return(msg)


envoyer(idtache,idetat)

choisir_etat_tache(idetat)

afficher_listTaches()

return(lisTaches)

selectioner_list_tache(idUtil,idModule)recuperer_listTaches(idUtil,idModule)

envoyer(idUtil,idModule)

choisir_module(idModule)

afficher_listModules()

return(listModules)

selectioner_listModule(idUtil,idProjet)récupérer_listModules(idUtil,idProjet)

envoyer(idUtil,idProjet)

choisir_ projet(idProjet)

afficher_listprojets()

return(listprojets)

Selectioner_listProjet()

récupérer_listprojets(idutil)

envoyer(idutil)

choisir_collaborateur(idutil)

afficher(listCollaborateurs)

return(listCollaborateurs)

selectionner_listCollaborateurs()

récupérer_listCollaborateurs()


III. Diagramme de classe

Un diagramme de classes dans le langage de modélisation unifié (UML) est un type de

diagramme de structure statique qui décrit la structure d'un système en montrant le système de

classes , leurs attributs, les opérations (ou) les méthodes et les relations entre les classes. [N2]

La figure 16 représente le diagramme des classes.


Figure 16 : Diagramme des classes


Conclusion

Dans ce chapitre, nous avons mis le point la conception de notre application

moyennant un diagramme dynamique « diagramme de séquence » et un outre statique

« diagramme de classe ». A ce stade, nous pouvons aborder une phase essentielle de notre

projet qui est la réalisation.


Chapitre 5

Réalisation de « AGP »

Introduction

Une des étapes de la vie d’un projet, aussi importante que la conception, est la phase

de développement. Cette étape constitue la phase d’achèvement et d’aboutissement du projet.

Pour accomplir cette tâche avec succès, il faut bien choisir et utiliser les outils adéquats et

nécessaires. Ce choix d’outils peut influencer la qualité du produit obtenu, donc cette

opération nécessite une attention particulière et doit se baser sur les besoins du projet et le

résultat désiré.

Ce chapitre sera consacré alors en premier lieu à la présentation de l’environnement

technique du travail ainsi qu’aux choix retenus en matière d’environnement logiciel. Par la

suite, nous présenterons le principe de fonctionnement du projet et nous terminerons par une

démonstration des on fonctionnement.

I. Architecture du notre système

Il existe diverses architectures logicielles, certaines d’entre elles peuvent être

appliquées dans notre application.

1. Architecture 3-tiers

Tout système d’information nécessite la réalisation de trois groupes de fonctions : le

stockage des données, la logique applicative et la présentation. Ces trois parties sont

indépendantes les unes des autres : on peut ainsi modifier la présentation sans modifier la

logique applicative. La conception de chaque partie doit également être indépendante. Cette

architecture est résumée dans la figure 17.


Figure 17 : L’architecture Trois-Tiers

Le principe d’une architecture Trois-Tiers est relativement simple : il consiste à

séparer la réalisation des trois parties vues précédemment. Ainsi une architecture 3-tiers est

découpée en trois couches:

1. La couche de présentation est la partie visible de l’application qui permet à un

utilisateur d’interagir avec le système. Elle relaie les requêtes de l’utilisateur à

destination de la couche métier, et en retour lui présente les résultats renvoyés par les

traitements.

2. La couche de traitement métier correspond à la partie fonctionnelle ou métier de

l’application. Elle implémente la logique et les règles de gestion permettant de

répondre aux requêtes de la couche présentation.

3. La couche de données Cette couche contient les données sauvegardées physiquement

sur disque (c’est-à-dire la base de données). Ces données peuvent aussi être gérées de

manière externe. Le système considéré ne les géres pas mais s’appuie sur la capacité

d’un autre système à fournir ces informations.

2. Approche MCV

L’architecture MVC est un concept très puissant qui intervient dans la réalisation

d’une application. Son principal intérêt est la séparation des données (modèle), de l’affichage

(vue) et des actions (contrôleur). L’architecture MVC est donc composée de trois éléments :

Le modèle : Le modèle correspond aux données, la plupart du temps stockées dans

une base de données. Celle-si peuvent également être contenues dans un fichier XML ou dans

des fichiers texte. Les données peuvent être exploitées sous forme de classes, dans un langage

de programmation orienté objet.

Partie

présentation Partie logique

applicative

Partie stockage des

données


Le contrôleur : Le contrôleur est l’élément qui va utiliser les données pour les

envoyer à la vue. Son rôle est de récupérer les informations, de les traiter en fonction des

paramètres demandés par l’utilisateur, et enfin de renvoyer à la vue les données afin d’être

affichées.

La vue : La vue prend les informations en provenance du modèle et les présente à

l’utilisateur.

II. Environnement de développement

1. Environnement matériel

Tout au long de notre projet, nous avons utilisé deux PC portables ayant les

caractéristiques suivantes :

PC SAMSUNG RV510 DELL Inspiron 3521

OS Windows 7 Home premium Windows 7 intégral

Disque Dur 320 GO 500 GO

Processeur Intel Pentium Dual core Intel core i5

RAM 3 GO 4 GO

Tableau 14 : Environnement de développement

2. Environment logiciel

Nous avons utilisé les environnements suivants :

PowerAMC :

Le logiciel PowerAMC est un logiciel de modélisation (modeleur) de Sybase. Il inclut

les modélisations de bases de données (MPD, MCD), permet de dessiner différents types de

diagrammes UML. Il permet aussi de générer un code source et d'élaborer la documentation à

partir d’un ou plusieurs diagrammes, etc.


NetBeans IDE 7.4 :

NetBeans est un environnement de développement intégré (EDI), placé en open source

par Sun en juin.

En plus de Java, NetBeans permet également de supporter différents autres langages,

comme Python, C, C++, JavaScript, XML, Ruby, PHP et HTML. Il comprend toutes les

caractéristiques d'un IDE moderne (éditeur en couleur, projets multi-langage, refactoring,

éditeur graphique d'interfaces et de pages Web).

MySQL Workbench :

C’est un logiciel de gestion et d'administration de bases de données MySQL créé

en 2004. Via une interface graphique intuitive, il permet, entre autres, de créer, modifier ou

supprimer des tables, des comptes utilisateurs, et d'effectuer toutes les opérations inhérentes à

la gestion d'une base de données. Pour ce faire, il doit être connecté à un serveur MySQL.

WampServer :

WampServer est une plate-forme de développement Web sous Windows. Elle dispose

de PHPMyAdmin pour gérer plus facilement la base de données. Elle est équipée d’un serveur

Apache2, du langage de scripts PHP et d'une base de données MySQL afin de permettre aux

développeurs web de réaliser des applications Web dynamiques. Ce qui le différencie des

autres solutions disponibles, la possibilité de reproduire fidèlement le serveur de production.

Une fois la base installée, on a la possibilité d'ajouter autant de versions d’Apache.

3. Les langages utilisés

Pour développer « AGP » (le nom de notre application) nous avons eu recours aux

différents langages de programmation:

PHP :

PHP: HyperText Preprocessor, plus connu sous son sigle PHP (acronyme récursif), est

un langage de programmation libre principalement utilisé pour produire des pages Web

dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe

quel langage interprété de façon locale. PHP est un langage impératif orienté-objet.


Zend Framework :

Le Zend Framework est un Framework pour PHP 5 créé en mars 2006 par Zend

Technologies. Il est distribué sous la Licence BSD Modifiée.

Le Zend Framework, aussi nommé ZF, a été développé dans le but de simplifier le

développement Web tout en recommandant les bonnes pratiques et la conception orientée

objets en offrant des outils aux développeurs. [B3]

ZF permet aussi d'utiliser nativement le principe de MVC (Modèle-Vue-Contrôleur)

mais ne l'oblige pas. [N3]

Ce Framework permet de faciliter et de fiabiliser le développement des sites

dynamiques en PHP.

Elle des fonctions principales tels que :

Organisation du code : l’organisation des répertoires et des classes suit certaines

normes. On peut ainsi construire son application par assemblage de blocs

indépendants bien organisés entre eux.

Séparation MVC (Model-View-Controller) : le Zend Framework offre de base offre de

base une architecture MVC. C’est-à-dire qu’il sépare la présentation, la navigation et

l’accès aux données.

Accès en base de données, Authentification, droits d’accès,… [N3]

JQuery :

JQuery est une bibliothèque JavaScript libre qui porte sur l'interaction entre JavaScript

(comprenant Ajax) et HTML, et a pour but de simplifier des commandes communes de

JavaScript.JQuery : écrivez moins pour faire plus !

Bootstrap :

Twitter Bootstrap est une collection d'outils utile à la création de sites web et

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. C'est l'un des projets les plus populaires sur la plate-forme de gestion de

développement GitHub. [N4]


4. Les API utilisés

Nous avons utilisé les API suivants :

JSON :

JSON ,JavaScript Object Notation, est un format léger d'échanges de données. Il est

facile à lire et à écrire pour des utilisateurs ordinaires et aisément analysable ou générable par

des machines. Il est basé sur un sous-ensemble du langage de programmation JavaScript.

Ces structures de données sont universelles. Pratiquement tous les langages de

programmation modernes les proposent sous une forme ou une autre. Il est raisonnable qu'un

format de données interchangeable avec des langages de programmation se base aussi sur ces

structures.

JQuery Gantt Chart :

JQuery Gantt est un plugin permettant de créer des diagrammes de Gantt web

interactifs et avancées.

Ce plugin possède une navigation bien pensée, avec un système de zoom et dé-zoom

pour avoir une vue plus générale des différentes taches. Un slider permet d’évoluer facilement

dans la chronologie du diagramme avec la souris.

Sur le hover de la souris, on peut afficher plus de détail sur la tâche. [N5]

JQuery Frontier Calendar :

JQuery Frontier Calendar est un plugin jquery permettant de créer rapidement un

calendrier riche à la google agenda. [N6]

Nous avons l’utiliser pour la partie « Timesheet » du notre application.

JSTree :

jsTree est plugin jQuery, qui fournit des arbres interactifs. Il est absolument gratuit,

open source et distribué sous la licence MIT. jsTree est facilement extensible et configurable,

il prend en charge les sources de données HTML et JSON et AJAX. [N7]

http://javascript.crockford.com/


III. Présentation des interfaces

Nous allons présenter dans cette partie les différentes interfaces développées dans

notre application.

1. Interface « authentification »

C’est la première interface qui s’affiche à tous les utilisateurs du système. Afin de

pouvoir accéder à l’application, chaque utilisateur est invité à saisir son login et son mot de

passe afin d’accéder à son propre interface principale.

Figure 18 : Page authentification

2. Back-office de l’application

Une fois authentifié, l’administrateur accède à cette interface là où il peut gérer les

différents menus de l’application qui sont affichés en FrontOffice, il peut ajouter des menus et

sous menus. Ainsi de gérer les différents composants de l’application.


Figure 19 : Interface gestion des menus

L’administrateur peut gérer les droits d’accès en créant un ensemble des droits et

affecter ces derniers aux composants des modules, c’est-à-dire les interfaces et les fonctions.

Figure 20 : Interface gestion des modules et droits


A ce stade-là, l’administrateur peut créer des profils regroupant chacun un ensemble

des utilisateurs, et affecter les droits aux différents profils.

Figure 21 : Interface Affectation des droits

3. Front office de l’application

Une fois l’utilisateur s’est authentifié avec succès, il sera redirigé vers la page

d’accueil ou il trouvera le menu déroulant de l’application qui est propre à chacun utilisateur

(planificateur ou collaborateur).

Figure 22 : Page Menu principal


Pour pouvoir créer un projet, le planificateur s’adresse au menu projet oùil peut

remplir le formulaire d’ajout. Suite à une validation de ça part, le système vérifie les données

entrées et lui renvoi un message du bon déroulement de l’action.

Figure 23 : Page de création projet

Après la création du projet, le planificateur peut créer les modules qui renferment par

la suite les taches.

Figure 24 : Page de création module


La chose qui reste, c’est de créer les taches des modules en remplissant un formulaire

de données.

Figure 25 : Page de création Tache

La procédure de création est terminée, le planificateur peut consulter les listes des

projets créés et il peut modifier les données de chaque projet ou le supprimer.

Figure 26 : Page gestion projets


Le planificateur a la possibilité de gérer les taches

Figure 27 : Page gestion Taches

La fonction la plus importante de la part du planificateur, c’est d’affecter les Taches

aux collaborateurs. A travers cette interface qui est développé par le plugin Jstree, il glisse un

tache et l’affecter à un collaborateur.

Figure 28 : Interface affectation des Taches


Le planificateur peut aussi visualiser chaque projet aves ces modules et taches à l’aide

du fameux diagramme « Diagramme de Gantt ».

On passe maintenant par les fonctionnalités qui sont assurés par un simple

collaborateur. Tous d’abord, le collaborateur que ce soit (concepteur, développeur, testeur,

designer,..) doit consulter son propre diagramme de Gantt afin de remplir ses activités dans

une feuille du temps « Timesheet ».

Pour ce faire, il se dirige vers l’interface de ‘consultation taches’ et sélectionner le

projet auquel il est affecté et générer le diagramme de Gantt. Ce dernier illustre de façon

détaillé le séquencèrent des taches avec ses dates de début et dates de fin.

Figure 29 : Interface Consulter diagramme Gantt


L’action qui suit par le collaborateur, c’est la saisie d’un timesheet : c’est un calendrier

dynamique développé par le plugin Jquery frontier calendar. Pour ce faire il accède à

l’interface du timesheet dans laquelle il enregistre ses activités par jour/ semaine/ mois.

La tâche qui est en vert dans le calendrier signifie qu’elle est validée.

La tâche qui est en rouge dans le calendrier signifie qu’elle est refusée.

Figure 30 : Interface du Timesheet


Le superviseur, c’est un super-collaborateur a pour rôle de valider le timesheet de ses

collaborateurs, pour ce faire il doit accéder à l’interface de validation timesheet et choisit l’un

de ses collaborateurs afin de valider son Timesheet.

La validation se fait selon des conditions :

Si la date de fin de réalisation d’une tache égale ou inférieure à la date de fin de

planification d’une tache, le superviseur doit valider le timesheet.

Si la date de fin de réalisation d’une tache dépasse sa date de fin de planification, le

superviseur doit refuser le Timesheet.

Figure 31 : Page Valider Timeshhet

Conclusion

Dans ce chapitre nous avons présenté l’environnement technique et logiciel utilisé lors

du projet. Nous avons également détaillé son principe de fonctionnement ainsi que des

captures d’écran montrant le bon fonctionnement de notre application.


Conclusion générale

Ce rapport a présenté le travail réalisé dans le cadre d’un projet de fin des études en

licence appliqué effectué au sein de la société « TRANSTU ». Ce projet consiste à la

conception et la réalisation d’une plateforme de gestion du projet par le langage PHP orienté

objet et le Framework Zend.

Pour la réalisation de ce système, une étude préalable des applications proposant le

même service était très utile pour dégager les fonctionnalités à mettre en œuvre et définir les

spécifications de notre application.

L’adoption de la méthode « UP » comme méthodologie de développement nous a

permis d’avoir en permanence un vue générale sur l’état d’avancement de notre projet et

d’accélérer son développement.

La méthode UML, utilisée dans la phase de la conception, nous a permis de bien modéliser

notre système de manière à ce que sa compréhension devienne facile.

Sur un plan technique, ce projet nous a été une occasion pour apprendre et maîtriser le

langage PHP5.Nous avons pu apprendre les bases du Framework Zend. Compte tenu de la

contrainte de temps dont nous disposions, nous n’avons pas pu pousser notre approche trop

loin mais nous avons quand même eu le temps de juger son utilité.

Finalement, ce projet a été une bonne expérience, dans la mesure où il nous a permis

de mettre en pratique les connaissances théoriques et les compétences acquises au fil de

trois ans d’études à l’Institut Supérieur des études technologiques de Rades. En plus, il a été

une occasion pour une ouverture sur le monde professionnel et pour approfondir nos

connaissances avec des nouvelles technologies.


Bibliographies

[B1] : Madame Sonia Gannar- Cours gestion de projet -2013-2014

[B2] : Laurent Audibert - UML 2 de l’apprentissage à la pratique - Édition : Dunod -,

1re

édition, 13 avril 2008

[B3] : Blanchon Vincent - Au cœur de Zend Framework 2


Nethographies

[N1]http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/ , Consulter le 02/03/2014

[N2] http://uml.free.fr/cours/i-p19.html , Consulter le 25/02/2014

[N3] http://www.z-f.fr/page/quest_ce_que_le_zf , Consulter le 08/03/2014

[N4] http://www.atlantismultimedia.fr/bootstrap/ , Consulter le 17/03/2014

[N5]http://www.lafermeduweb.net/billet/jquery-gantt-creez-des-diagrammes-de-gantt-

avances-avec-jquery-1384.html , Consulter le 10/05/2014

[N6] http://www.lafermeduweb.net/billet/jquery-frontier-calendar-un-calendrier-complet-a-la-

google-agenda-1032.html , Consulter le 05/04/2014

[N7] http://www.jstree.com/ , Consulter le 11/04/2014

http://uml.free.fr/cours/i-p19.html

http://www.z-f.fr/page/quest_ce_que_le_zf

http://www.jstree.com/

Engineering

Rapport pfe