RAPPORT DE PROJET DE FIN

D’Année

Sujet:

Réalisé par

Nom : BahaEddine

Prénom : Jbali

Encadré par : Ben Mansour Ramzi

Soutenu le : …./…./……. devant le jury composé de :

Président : ………………… Rapporteur : ………………

Remerciements :
La réalisation de ce projet a été possible grâce au concours de plusieurs personnes
à qui me voudra témoigner toute ma reconnaissance. Je tiens tout spécialement à
exprimer mon plus grand respect et ma gratitude à mon encadrant, avec qui m’ai eu
l'honneur de travailler. A Mr Ben Mansour Ramzi, pour son encadrement, sa
disponibilité, et la confiance qu’il m’a donné ainsi que pour tous ses conseils
précieux et son soutien et son sens d'orientation durant la réalisation de mon projet.
Avec beaucoup d’égard, je ne manque pas d’exprimer ma grande reconnaissance à
tous les enseignants de l’institut supérieur au Kef et plus particulièrement aux
membres du jury qui ont accepté de juger ce modeste travail.

2
 Sommaire

Table de matière

1.1 Cadre du projet………………………………………………………………………………

1.2 Problématique………………………………………………………………………………..

1.3 Choix de la méthodologie et du langage de développement…………..

1.3.1 SCRUM…………………………………………………………………………….

1.3.2 Les réunions……………………………………………………………………..

1.3.3 Les acteurs ……………………………………………………………………...

1.3.4 Le backlog du produit……………………………………………………….

1.4 Présentation Entreprise…………………………………………………………..

1.5 Objectifs
…………………………………………………………………………………………

1.6 Conclusion ……………………………………………………………………………………..

2.1 Capture des besoins ……………………………………………………………………….

2.1.1 Les besoins fonctionnels……………………………………………………

2.1.2 Les besoins non fonctionnels…………………………………………….

2.2 Diagrammes de cas d’utilisation ……………………………………………………

2.2.1 Diagramme de cas d’utilisation global……………………………….

2.2.2 Sous-système 1 : Gérer les demandes ………………………………

2.2.3 Sous-système 2 : Gérer les offres de stage ……………………………….

3
 2.2.4 Sous-système 3 : Gérer les employées …………………………

2.2.5 Sous-système 4 : Gérer les authentifications …………………………….

2.3 Descriptions textuelles……………………………………………………………………

2.3.1 Gestion des demandes de stage ……………………………………….

2.3.2 Gestion des stages …………………………………………………………….

2.3.3 Authentification………………………………………………………………

2.3.4 Gestion des employées………………………………………………………………

2.4 Diagrammes séquence système………………………………………………………

2.5 Conclusion
………………………………………………………………………………………

3.1 Architecture conceptuelle………………………………………………………………

3.2 Conception architecturale………………………………………………………………..

3.3Conception technique détaillée………………………………………………………

3.3.1 Représentation statique……………………………………………………

3.3.2 Représentation de la vue dynamique………………………………

3.3.2.1 Authentification…………………………………………………..

3.3.2.2 Ajouter employé……………………………………………….

3.3.2.3 Demander stage………………………………………………….

3.3.2.4 Modifier stagiaire………………………………………………….

3.3.2.5 Supprimer stagiaire…………………………………………….

4
3.4
Conclusion………………………………………………………………………………………

4.1 Environnement de travail……………………………………………………………….

4.1.1 Environnement matériel ……………………………………………………………

4.1.2 Environnement logiciel et outils de travail ………………………………

4.2 Diagramme de déploiement……………………………………………………………

4.3 Description des interfaces principales…………………………………………..

Conclusion………………………………………………………………………………………

Liste des figures

Figure 1.1 : Vue Globale de

SCRUM……………………………………………………………………………………..

Figure 1.2 : Représentation génerale de la Tunisie Teleccom

Figure 2 : Diagramme de Cas D’utilisation

Global……………………………………………………………

Figure 3 : Diagramme de Cas D’utilisation: Gestion des

Demandes…………………………………

Figure 4: Diagramme de Cas D’utilisation: Gestion des Offres de

Stage……………………………

Figure 5 : Diagramme de Cas D’utilisation: Gestion des

Employés………………………………….

Figure 6 : Diagramme de Cas D’utilisation: Gestion des

Authentifications………………………..

Figure 7 : Diagramme Séquence Système …………………………………….

5
 Figure 8: Diagramme D'activité " Ajouter Employé"…………………………..

Figure 9: Diagramme D'activité " Demander stage"…………………………………

Figure10: Diagramme D'activité "Modifier Employé"…………………

Figure 11: Diagramme D'activité supprimer stages"…………………………………

FIGURE 12 : HOME………………………………………………………………

FIGURE 13: Inscription……………………………………………………

FIGURE 14: Connection……………………………………………

FIGURE 15: Espace Administrateur…………………………………

FIGURE 16: Liste Employés………………………………………………………………

FIGURE 17: Ajouter employés……………………………………………………….

FIGURE 18: Liste demande de stage ……………………………………………………

FIGURE 19:Demander un stage……………………………………………….

FIGURE 20: Chat………………………………………………

Liste des tableaux Tableau

Tableau 1 : Description textuelle du cas d'utilisation " Gestion des Demandes de Stages

Tableau 2 : Description textuelle du cas d'utilisation " Gestion de stage

Tableau 3 : Description textuelle du cas d'utilisation " Authentification "

Tableau 4 : Description textuelle du cas d'utilisation " gestion des employées

Tableau 5 : Description détaillée des classes…………………………………………

6
 Introduction générale

Le monde connaît une avance technologique considérable dans tous les secteurs et qui évolue
grâce à l'informatique ; il s’agit d’une science qui étudie les techniques du traitement
automatique de l'information.

Elle joue un rôle important dans le développement de l'entreprise et d'autres établissements. Elle
intervient dans tous les domaines et tous les secteurs pour rendre le travail plus facile, plus précis
et surtout bien géré.

Avant l'invention de l'ordinateur, on enregistrait toutes les informations manuellement sur des
supports en papiers ; ceci engendrait beaucoup de problèmes : tels que la perte de temps
considérable dans la recherche de ces informations ou la dégradation de ces dernières.

Ainsi, jusqu'à présent, l'ordinateur reste le moyen le plus sûr pour le traitement et la sauvegarde
de l'information.

Cette invention a permis d'informatiser la gestion des données des entreprises. Cette gestion
présente la tâche la plus importante dans le développement des systèmes d’information de ces
entreprises.

En effet, les sociétés cherchent à améliorer la gestion de leurs activités en les informatisant.
Toute entreprise est confrontée à des problèmes liés à ses tâches administratives. C’est pour cela
que les applications et les systèmes informatiques sont des solutions idéales pour rendre plus
efficace cette tâche.

La définition usuelle d'un système d'information (SI) ressemblait à ceci: ``Le système
d'information est l'ensemble des informations formalisables circulant dans l'entreprise et
caractérisées par des liens de dépendance, ainsi que des procédures et des moyens nécessaires
pour les définir, les rechercher, les formaliser, les conserver, les distribuer ''.

Le présent travail se situe dans le cadre de notre projet de fin d’année qui consiste à développer
une application web qui gère ces activités. Ce travail assure : la gestion des employées et des
stagiaires.

7
Le premier chapitre " Etude préalable " sera consacré à mettre le projet dans son cadre général :
présenter le projet.

Le deuxième chapitre nommé : sprint 0 décrit : « analyse et spécification des besoins " : dans ce
chapitre nous détaillerons les différents besoins fonctionnels et non fonctionnels du projet. Pour
cela, nous aurons recours aux diagrammes de cas d’utilisation UML et des diagrammes de
séquences systèmes.

Le troisième chapitre : nommé sprint 1 " Conception " sera consacré à la partie conception du
système à travers une présentation de l’architecture utilisée, de la description détaillée des
classes, des règles de gestion, du diagramme de classe et des diagrammes d’activités.

Le quatrième et dernier chapitre nommé : sprint 2 "Réalisation et tests " suivra à décrire
l’environnement du travail et tous les aspects techniques ainsi que le diagramme de déploiement.
L’évaluation de la qualité du processus de développement suivra dans ce chapitre.

8
Chapitre 1 : Cadre général du projet

Ce chapitre a pour objectif de mettre le projet dans son cadre général : je présente mon projet.

1. Cadre du projet :

Dans le cadre professionnel actuel, les entreprises tentent de tous informatiser afin de faciliter le
contact avec les clients, les partenaires, les stagiaires… Dans ce cadre et en guise de la
réalisation de mon projet de fin d’année, j’ai été invité à concevoir et développer une application
web permettant la gestion des stagiaires et des employées au sein d’une entreprise.

2. Problématique :

Il s’agit de la réalisation d’une application web facile et simple à manipuler qui permet de gérer
les demandes de stagiaires et la gestions des employées et leur attribuer des stages adéquats :
consulter et mettre à jour les stagiaires et les employées…

3. Choix de la méthodologie et du langage de développement :

Le développement de cette solution doit passer par une phase ultime de modélisation du
système, qui permettra de faciliter l’étude et la documentation. Une méthodologie est une
démarche qui répond à ces exigences et permet la construction d’application, sur le plan
fonctionnel et technique, conforme aux attentes des divers intervenants du projet. A ce fait j’ai
adopté le modèle de cycle de vie SCRUM comme processus de travail et UML comme langage
de modélisation.

a. SCRUM :

J’ai opté pour le processus SCRUM pour plusieurs raisons [1]. Ce processus fait en sorte
d’atteindre les objectifs d’affaires grâce au travail sur les fonctionnalités qui ont la plus grande
valeur ajoutée et assure aussi que le projet s’adapte aux exigences changeantes et il est
transparent pour toutes les parties prenantes et procure de nouvelles fonctionnalités à des
intervalles réguliers. SCRUM est une méthode de management de projet conçue pour les projets
de développement logiciels. Elle s'applique toutefois théoriquement à n'importe quel contexte où

9
un groupe de personnes travaillant ensemble pour atteindre un objectif commun. Cette technique
est reconnue pour sa flexibilité et son efficacité, par exemple:

 La planification régulière de réunions dont l'objectif est définie en fonction du cycle courant
qui favorise la communication entre les membres de l'équipe ainsi que le transfert de
connaissances, et permet de détecter les risques dans le développement du projet, afin d'anticiper
d'éventuels retards.

 Les exigences du client ne sont pas figées dès la planification du projet ; celle-ci peuvent
évoluer (de manière raisonnable), et le client est inclus dans le processus de développement, ce
qui procure une meilleure visibilité des progrès et difficultés rencontrées, et favorise donc le
dialogue entre les deux parties.

b. Les réunions :
10
Quatre réunions sont définies dans le modèle SCRUM :

 Le Daily SCRUM : réunion quotidienne qui a pour objectif de faire le point sur l'avancement
et les difficultés rencontrés par chacun des membres. Réunion limitée à 20 minutes.

 Le Sprint planning meeting : réunion qui précède le commencement de chaque cycle de

développement et qui vise à établir le sprint backlog. Réunion limitée à 2 heures.

 Le Sprint review meeting : réunion qui conclut un cycle de développement et qui a pour
objectif de faire le point sur le travail accompli, de définir un démonstrateur pour le stakeholder
et pour le Product owner. Réunion limitée à 1 heure.

 Le Sprint rétrospective : réunion où tous les membres du groupe réfléchissent sur les points
positifs et négatifs qui ont caractérisé le dernier sprint en matière d'organisation et de
coopération. Réunion limitée à 1h30.

c. Les acteurs :

SCRUM définit les rôles suivants :

 Directeur de produit : c’est le représentant des clients et utilisateurs. C'est lui qui définit l'ordre
dans lequel les fonctionnalités seront développées, et qui prend les décisions importantes
concernant l'orientation du projet.

 SCRUM Master : c’est lui qui est chargé de protéger l'équipe de tous les éléments
perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non techniques (administratifs
par exemple). Il doit aussi veiller à ce que les valeurs de SCRUM soient appliquées, mais il n'est
ni un chef de projet ni un intermédiaire de communication avec les clients.

 L’Équipe : ne comporte pas de rôles prédéfinis, elle est autogérée. Toutes les décisions sont
prises ensemble ; nous n’avons pas de notion d’hiérarchie interne.

 Intervenants : Les Intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue
sur le projet sans réellement s'investir dedans. Il peut s'agir par exemple d'experts techniques,
d'agents de direction qui souhaitent avoir une vue très éloignée de l'avancement du projet.

11
d. Le backlog du produit :

Le backlog du produit est la liste des fonctionnalités attendues d'un produit. Plus exactement,
au-delà de cet aspect fonctionnel, il contient tous les éléments qui vont nécessiter du travail pour
l'équipe. Les éléments y sont classés par priorité ce qui permet de définir l'ordre de réalisation.
Le backlog du produit est sous la responsabilité du Product owner. Chacun peut contribuer à
collecter des éléments, mais c'est le Product owner qui les accepte finalement et c'est lui qui
définit les priorités. Le backlog est élaboré avant le lancement des sprints, dans la phase de
préparation (ou sprint0). Il est utilisé pour planifier la release, puis à chaque sprint, lors de la
réunion de planification du sprint pour décider du sous-ensemble qui sera réalisé. C'est donc un
outil essentiel pour la planification. Mais il est aussi, par sa nature, un maillon de la gestion des
exigences, puisqu'on y collecte ce que doit faire le produit.

4. Présentation entreprise

La Société National des TELECOM est un établissement public à caractère industriel. Il a été
créé par la loi 95-36 du 17 Avril 1995 et certifié son nom commercial TUNISIE TELECOM,
dont l’objectif est de satisfaire les besoins des différentes catégories de clientèles avec une
meilleure qualité et l’informatisation de tous ses services.Tunisie Télécom propose des services
dans le domaine des télécommunications fixes et mobiles.

Objectif de la région :

* Servir les clients et augmenter leur satisfaction.

* Appliquer les politiques générales et atteindre les objectifs fixés d’un commun accord.

* Représenter l’entreprise à l’échelon régional et protéger ses intérêts.

* Maintenir la bonne qualité des réseaux.

* Maintenir la cohésion et la motivation des équipes.

12
* Assurer une veille concurrentielle et être force de proposition.

* Rechercher l’excellence opérationnelle.

5. Objectifs :

Mon projet a pour objectifs :

* Diffuser des offres de stages.

13
* Faciliter l’envoi des demandes de candidature.

* Administrer les demandes de candidature.

*Faciliter la gestion des employers.

* Organiser les tâches,

6. Conclusion :

Ce chapitre résume l’étude préliminaire que j’ai mené lors des premiers jours. Ceci m’a permis
de mettre le projet dans son contexte général, d'identifier sa problématique, d’étudier les
applications existantes, cerner les défaillances des systèmes existants et de conclure par la
proposition d’une solution.

Chapitre 2 : Analyse et spécifications des besoins

Ce chapitre représente la spécification détaillée des besoins des futurs utilisateurs du système à
concevoir, les différents besoins fonctionnels et non-fonctionnels qui perfectionnent la qualité
logicielle du système ainsi que la gestion du projet avec la méthodologie SCRUM.
14
1. Capture des besoins :

La capture des besoins est une étape primordiale dans le cycle de développement d’un produit
ou d’un service. Cette phase de spécification est la traduction des besoins utilisateurs en
documentations conceptuelles et techniques.

a. Les besoins fonctionnels :

Les besoins fonctionnels répondent aux points précis du cahier des charges, et sont donc requis
par mon utilisateur final et lui sont indispensables. En d’autres termes, ce sont les besoins
obligatoires ou encore les fonctionnalités de l’application. A cet égard, mon application doit
répondre aux besoins fonctionnels suivants

 Gérer les demandes :

 Accepter une demande.

 Rejeter une demande.

 Afficher la liste des demandes.

 Gérer les offres de stage :

 Ajouter une offre.

 Supprimer une offre.

 Mettre à jour une offre.

 Afficher la liste des offres.

 Gérer les stagiaires :

 Supprimer un stagiaire.

 Modifier un stagiaire.

 Rechercher un stagiaire.

15
 Gérer les stages demandés :

 Annuler une demande.

 Modifier une demande.

 Consulter sa demande.

 Gérer les authentifications :

 Modifier mot de passe.

 Modifier adresse e-mail.

 Gérer les employées :

 Ajouter un employé.

 Supprimer un employé.

 Rechercher un employé.

 Afficher la liste des employées.

b. Les besoins non fonctionnels :

Ce sont des exigences liées à la production ainsi qu'à l'utilisation et qui ne concernent pas
spécifiquement le comportement du système mais plutôt identifient ses contraintes internes et
externes. Dans cette partie j’ai opté de se baser sur la norme ISO 25000 pour créer le modèle de
qualité du système.

 Présentation de la norme :

ISO 25000 est un modèle de qualité ayant pour objectif de poser le cadre et la référence
pour définir les exigences qualité d’un logiciel (ISO 9126) et la manière dont ces exigences
seront évaluées (ISO 14598). Cette norme offre un cadre pour l’intégration des évolutions des
16
 normes ISO 9126, la qualité logicielle, et ISO 14598, l’évaluation de la qualité logicielle .En
suivant les 25 exigences du modèle Square je m’intéresse à l’exigence liée à la production ainsi
que l’exigence à l’utilisation.

 Exigences de la qualité liées à la production : D’après la norme ISO_25000, les

principales exigences liées à la production de mon application se résument dans les points
suivants:

 Caractéristiques externes : Ce sont les caractéristiques évoluées au cours du processus test en

indiquant le poids de chacune :

H:Haut

M:Moyen

F: Faible

  Pertinence fonctionnelle : sous caractéristiques :

 Précision : Toutes les fonctionnalités fournissent un résultat précis.

Poids: H

Métrique: Nombre d'interfaces non accessibles.

 Adéquation : Les fonctionnalités devraient être en adéquation avec les besoins spécifiés.

Poids: H

Métrique: Nombre de fonctionnalité existante et non utilisée par les utilisateurs finaux.

 Performance : sous caractéristiques:

17
 Rapidité : Le temps de réponse d'une requête devrait être convenable.

Poids: H

Métrique: Moyenne de temps en seconde pour se connecter ou effectuer une tâche.

 Utilisabilité: sous caractéristiques:

 Apprentissage: L'utilisateur devrait apprendre à utiliser l'application facilement.

Poids: M

Métrique: Nombre de fonctionnalités maitrisées après une période d’utilisation

 Fiabilité : sous caractéristiques:

 Tolérance aux fautes: L'application ne devrait se planter ou perdre des données.

Poids: H

Métrique: Possibilité de récupérer un travail après erreur.

 Sécurité : sous caractéristiques:

 Confidentialité: les informations confidentielles de l'utilisateur devraient être sécurisées.

Poids: H

18
Métrique: Probabilité de trouver la clé de chiffrement ou la signature électronique.

2. Diagrammes de cas d’utilisation :

a. Diagramme de cas d'utilisation global:

Les diagrammes de cas d’utilisation décrivent ce qu’un

système fait de point vue observateur externe. La figure
représente le diagramme global de notre application web.

19
FIGURE 1 : DIAGRAMME DE CAS D'UTILISATION GLOBAL

20
b. Sous-système 1: Gérer les demandes :

FIGURE 2: DIAGRAMME DE CAS D'UTILISATION : GESTION DES

DEMANDES

21
c. Sous-système 2 : Gérer les offres de stage :

FIGURE 3 : DIAGRAMME DE CAS D'UTILISATION : GESTION DES

OFFRES DE STAGE

d. Sous-système 3 : Gérer les employées :

22
FIGURE 4 : DIAGRAMME DE CAS D'UTILISATION :
GESTION DES employées

23
e. Sous-système 4 : Gérer les authentifications

FIGURE 5 : DIAGRAMME DE CAS D'UTILISATION :

GESTION DES AUTHENTIFICATION

24
3. Descriptions textuelles :

a. Gestion des demandes de stage :

Cas d’utilisation Gestion des demandes de stages

Acteur Administrateur du système
Précondition Authentification réussie
Post-conditions Un Stagiaire a été ajouté dans la base de
données ou une demande de stage a été
rejetée
Scénario 1. L'administrateur se connecte à l'interface de
gestion des demandes de stage.
2. Le système affiche la liste des demandes de
stage reçues, triée par critère voulu.
3. L'administrateur peut sélectionner une
demande de stage pour voir les détails, tels
que le nom et les coordonnées de l'étudiant, le
poste demandé, la durée et les compétences
de l'étudiant.
4. Si l'étudiant répond aux exigences,
l'administrateur peut planifier un entretien
pour évaluer ses compétences.
TABLEAU 1 : DESCRIPTION TEXTUELLE DU CAS D'UTILISATION " GESTION
DES DEMANDES DE STAGES "

25
b. Gestion des stages:

Cas d’utilisation Gestion des stages

Acteur Administrateur du système
Précondition Authentification réussie
Post-conditions Une offre de stage a été ajouté dans la base de
données ou a été supprimée ou mise à jour
Scénario 1. L'administrateur se connecte à l'interface de
gestion des demandes de stage.
2. L'administrateur consulte les offres de
stages existantes pour voir si elles doivent être
mises à jour ou retirées.
3. L'administrateur peut modifier une offre de
stage en modifiant les informations telles que
la description, la durée, les compétences
requises, les avantages offerts, etc.
4. L'administrateur peut ajouter une nouvelle
offre de stage en remplissant les informations
requises, telles que le nom, la description, la
durée, les compétences requises et les
avantages offerts aux stagiaires.
5. L'administrateur peut retirer une offre de
stage si elle n'est plus disponible ou si elle a
été pourvue. 6. Après les changements le
système met à jour la liste des offres de stages
TABLEAU 2 : DESCRIPTION TEXTUELLE DU CAS D'UTILISATION " GESTION DE
STAGE "

26
c. Authentification:

Cas d’utilisation Authentification

Acteur Etudiant, Stagiaire, Admin
Précondition Avoir les informations (nom,
prenom,numero,cin,email, mot de passe)
enregistrés dans la base de données
Post-conditions L’utilisateur est connecté à mon application
Scénario 1. L’utilisateur lance l’application
2. Le système affiche l’interface de connexion
3. L’utilisateur saisie son email et mot de
passe et les autres coordonnés
4. Le système vérifie les informations entrées
5. Si les informations sont correctes
6. Le système affiche la page home (Admin,
Etudiant, Stagiaire)
6.1 Si les informations sont incorrectes le
système affiche un message d’erreur à
l’utilisateur
6.2 Retour au scénario numéro
Tableau 3 : Description textuelle du cas d'utilisation " Authentification

27
d.Gestion des employees:

Cas d’utilisation Gestion des employees

Acteur Admin
Précondition Avoir les informations (nom,
prenom,numero,cin,email, mot de passe)
enregistrés dans la base de données
Post-conditions L’employé est enregistré à mon application
Scénario 1. L’admin géré le grade de l’employé
2. L’admin gère le service de l’employé
3. L’admin enregistre tous les coordonnés de
l’employé dans la base donnée
Tableau 4 : Description textuelle du cas d'utilisation " Gestion des employées "

28
4. Diagrammes séquence système :

FIGURE 14: DIAGRAMME SEQUENCE SYSTEME

29
5. Conclusion :

Dans ce chapitre, j’ai débuté par une spécification détaillée des besoins fonctionnels et non-
fonctionnels de mon projet. Ensuite, j’ai identifié les acteurs et les cas d'utilisations du système à
travers les diagrammes de cas d'utilisations et les diagrammes de séquences système. J’ai fini par
une explication du processus de gestion de mon projet avec la méthodologie SCRUM.

30
Chapitre 3 : Conception de la solution
Après avoir déterminé les besoins fonctionnels et non fonctionnels de mon projet, j’ai passé à
l'étape de la conception du système. En premier lieu, j’ai décri l'architecture sur laquelle est basé
mon système. En second lieu, j’ai présenté la conception technique détaillée de mon projet en
présentant la vue statique à l'aide de diagramme de classe ainsi que la vue dynamique et ceci à
travers les diagrammes de séquence objet et les diagrammes d'activités.

1. Architecture conceptuelle :

Une application multi couches qui nécessite plusieurs serveurs logiciels appelés
Middleware et dans laquelle je distingue différents rôles pour chaque composant logiciel.
Je présente ci-dessous les principaux composants :

PhpMyAdmin : sert à administrer mes bases de données, je l’ai

Configuré de la façon la plus standard possible, je peux y accéder depuis une

interface Web.
 Apache, est un logiciel libre que l’on installe sur le serveur qui

fait office de serveur http, il va donc accueillir notre Site Web et

c’est lui qui va faire en sorte qu’il soit accessible via notre

navigateur.

 PHP, il est indispensable pour que notre serveur puisse

communiquer avec notre site et nos bases de données.

2. Conception architecturale :

L'architecture trois tiers est un modèle logique d'architecture applicative qui vise à
modéliser une application comme un empilement de trois couches logicielles.

Mon application a une architecture 3 tiers qui est composée de 3 niveaux dont le rôle est
clairement défini :
31
 La couche présentation: Cette couche correspond à l'interaction entre homme et
machine.

 La couche métier : Cette couche correspond à la mise en œuvre de l'ensemble des

règles de gestion et de la logique applicative.

 La couche accès aux données persistantes : Cette couche correspond aux données qui
sont destinées à être conservées sur la durée, voire de manière définitive

3. Conception technique détaillée :

a. Représentation statique :

Cette étape consiste à détailler la conception de mon application tout en débutant par la
représentation statique du système accompagnée par la suite de quelques scénarios
utilisant une représentation dynamique de mes modules. La représentation statique est
consacrée à décrire soigneusement et précisément les classes, les règles de gestion ainsi
que les diagrammes de classes qui expliquent à leur tour les différents rôles et
associations entre les modules.

 Diagramme de classe :

Le diagramme de classe est une représentation statique des éléments qui composent un
système et qui définissent sa structure interne contrairement au diagramme de cas
d'utilisation qui montre le système de point de vue acteur et de leurs relations. Il est
considéré comme le plus important de la modélisation orientée objet .C'est le seul
diagramme obligatoire lors d'une telle modélisation.

32
33
 Description détaillée des classes:

Classes Propriétés
Personne Matricule
Nom
prenom
code_grade
libelle_grade
code_service
libelle_service
created
Contacts id
code_grade
libelle_grade
created
Service id
code_service
libelle_service
created
Admin id
nom
prenom
mail
cin
password
User id
nom
prenom
mail
cin
password

34
Msg id
unique id
img
username
email
pass
status
Stage nom
prenom
mail
cin
nom
type
created
Tableau 9 : Description détaillée des classes

 Règles de gestion :

 Une personne peut avoir un seul compte.

 Un admin peut gérer aucun ou plusieurs Employées.

 Un admin peut gérer aucune ou plusieurs Demandes.

 Un admin peut gérer aucun ou plusieurs Stages.

 Un admin peut gérer un ou plusieurs Stagiaires.

 Un étudiant peut consulter une et une seule demande.

 Chaque employé a un grade spécifique.

 Chaque employé a un service spécifique.

35
b. Représentation de la vue dynamique :

Afin de mieux décrire le déroulement du processus de mon projet et des cas

d’utilisations, j’ai eu recours au diagramme d'activité qui est un moyen graphique
permettant de donner une vision globale sur l'ensemble des scénarios possibles.

Pour gérer un stagiaire ou un employé, l'utilisateur clique sur l'application stagiaire ou

employé. Le système va lui afficher une liste ainsi qu'un ensemble d'actions telles
qu’ajouter, modifier et supprimer un stagiaire.

Dans le cas d'ajout d’un stagiaire, le système affiche un formulaire. L'utilisateur remplit
les champs du formulaire et valide son choix. Si les champs sont valides, le système
ajoute le stagiaire et le sauvegarde. Sinon, l'utilisateur doit remplir de nouveau les
champs manquants.

Dans le cas de suppression, l’administrateur choisit "Supprimer un stagiaire". Le système

sauvegarde le choix de l'utilisateur et le stagiaire est par la suite supprimé

36
Authentification :

FIGURE 18: DIAGRAMME D'ACTIVITE “AUTHENTIFICATION"

. Ajouter employé:

37
FIGURE 19: DIAGRAMME D'ACTIVITE " AJOUTER EMPLOYE"

38
. Demander stage:

FIGURE 21:DIAGRAMME D'ACTIVITE " DEMANDER STAGE"

39
. Modifier stagiaire:

FIGURE 23 : DIAGRAMME D'ACTIVITE "MODIFIER EMPLOYE"

40
. Supprimer stagiaire:

FIGURE 26:DIAGRAMME D'ACTIVITE " SUPPRIMER STAGIAIRE"

4. Conclusion :

Dans ce chapitre, j’ai commencé par une conception technique de mon système. Ensuite, j’ai
détaillé la conception à travers les diagrammes de classe et d’activités. Dans le prochain chapitre,
je vais présenter l’environnement du développement matériel et logiciel ainsi que la description
et l’évaluation de la qualité travail réalisé.

Chapitre 4 : Réalisation et tests

41
Après avoir achevé l’étude et la conception de l’application, je vais présenter l’étape de la
réalisation et la mise en œuvre de mon travail. Dans ce but, je commence par l’environnement de
travail ainsi que les outils utilisés. Par la suite, je présente quelques interfaces du travail réalisé et

du résultat obtenu.

1. Environnement de travail :

Je présente, dans cette section, l’environnement matériel et logiciel utilisé pour le développement

de la solution.

a. Environnement matériel :

 machine :

 Processeur : Intel(R) Core™ i5-11260H CPU @2.60GHz 2.61 GHz

 Mémoire installée : 16,0Go

 Type de système : Système d’exploitation 64 bits, processeur x64.

b. Environnement logiciel et outils de travail :

 Système d’exploitation : Windows 10.

 Outils de gestion base de données: Oracle.

 Outils de conception : StarUML pour la modélisation des diagrammes.

 Architecture 3-tiers:

Le marché des logiciels libres professionnels continue de se développer à un rythme soutenu.

Après avoir investi initialement les couches basses du système d'information (middleware), les
solutions Open Source commencent maintenant à concurrencer sérieusement les produits
propriétaires dans toute une gamme d'applications d'entreprise, et jusqu'aux logiciels grand
public. Le modèle d'architecture 3-tiers a pour objectif de répondre aux préoccupations
suivantes :
42
1) Allégement du poste de travail client (notamment vis-à-vis des architectures classiques
client-serveur de données typiques des applications dans un contexte Oracle/Unix).

2) Prise en compte de l'hétérogénéité des plates-formes (serveurs, clients, langages, etc.).

Introduction de clients dits légers (plus liée aux technologies Intranet/HTML qu'au 3-tiers
proprement dit).

3) Amélioration de la sécurité des données, en supprimant le lien entre le client et les

données. Le serveur a pour tâche, en plus des traitements purement métiers, de vérifier
l'intégrité et la validité des données avant de les envoyer dans la couche de données.

4) Rupture du lien de propriété exclusive entre application et données. Dans ce modèle, la

base de données peut être plus facilement normalisée et intégrée à un entrepôt de
données. Et enfin, meilleure répartition de la charge entre différents serveurs
d'application. C'est pour cette raison, qu’on s'est orienté vers les applications 3 tiers.

Star UML:

StarUML est un outil spécialisé dans la modélisation UML pratique dans le domaine du
développement d'applications. Il gère la plupart des diagrammes spécifiés dans l’UML.

2. Description des interfaces principales :

43
 Figure 12 : Home

Figue 13 : Inscription

44
Figue 14 : Connection

45
Figue 15 : Espace Administrateur

Figue 16 : Liste des employés

46
Figue 17 : Ajouter employé

Figue 18 : Liste de demande de stages

47
Figue 19 : Demander un stage

Figue 20 : Chat

48
 Conclusion générale
Ce rapport est le fruit d'un travail réalisé dans le cadre de mon projet fin d'année à l’ISI.
L'objectif principal de mon travail était de concevoir et développer une application web
qui permet la gestion des stagiaires et des employés au sein de la société. J’ai commencé
en premier lieu par identifier le cadre de mon projet et déterminer les solutions et les
objectifs. Ensuite, j’ai analysé et spécifié les besoins fonctionnels à l'aide des diagrammes
UML et non fonctionnels à travers la norme ISO 25000. L'avancement de mon travail
était d'une façon incrémentale en suivant les principes de la méthodologie SCRUM. La
conception graphique et architecturale nous a aidés à réaliser et implémenter les
différentes parties de mon travail. Tout au long de la période de réalisation du projet, j’ai
rencontré plusieurs difficultés aussi bien sur le plan conceptuel que sur le plan de la
réalisation. Mais tout de même, j’ai pu les surmonter -grâce à mes efforts pour présenter à
la fin un système fonctionnel et opérationnel. Certes, Cette application ne prend pas fin
avec l'achèvement du présent projet mais, plusieurs améliorations restent envisageables
telles que la synchronisation du calendrier des rendez-vous avec l'application mobiles
"Google Calendar", le développement d'une application qui gère la relation avec la

clientèle en offrant un espace de communication instantanée. Ce projet était

une réelle occasion pour intégrer mes compétences et découvrir le
monde professionnel dans un cadre dynamique, rigoureux et très
professionnel. Les situations de blocage, les problèmes techniques
et la pression des délais j’ai appris à mieux gérer le temps, à
découvrir de nouveaux logiciels et méthodes de développement, à
approfondir mes connaissances dans la pratique du développement
et de la gestion, à adopter une méthodologie de travail et à
respecter les spécifications.

49