Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Direction Générale des Etudes Technologiques

Institut Supérieur des Etudes Technologiques de Bizerte
Département Technologies de l'Informatique

Guide de Rédaction du rapport de Projet de Fin

d’Etudes

pour la spécialité DSI

(Développement des Systèmes d’informations)

Réalisé par :

Mme Zeineb Langar, unité PFE

Mme Amal Lahouel, unité PFE

Mme Afef gafsi, unité pédagogique

Mme Nadia Hachani, Unité pédagogique

 Plan du guide

1. PAGES DE COUVERTURE & RÉSUMÉS.......................................................................................................... 1

2. DÉDICACES (OPTIONNELLE)........................................................................................................................ 1

3. REMERCIEMENTS....................................................................................................................................... 1

4. MODÈLE DE PAGE DE GARDE...................................................................................................................... 1

5. TABLE DES MATIÈRES................................................................................................................................. 0

6. LISTE DES FIGURES..................................................................................................................................... 3

7. LISTE DES TABLEAUX.................................................................................................................................. 3

8. INTRODUCTION GÉNÉRALE........................................................................................................................ 3

9. DÉVELOPPEMENT DES CHAPITRES.............................................................................................................. 4

10. CONCLUSION GÉNÉRALE.......................................................................................................................... 4

11. BIBLIOGRAPHIE ET NETOGRAPHIE............................................................................................................ 4

12. ANNEXES................................................................................................................................................. 5

13. PROPOSITION DE MISE EN FORME........................................................................................................... 5

ANNEXE : MODÈLE EXTRAIT D’UN RAPPORT PFE POUR ILLUSTRER BACKLOG PRODUIT ET SPRINTS.................0
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

1. Pages de couverture & Résumés

a. Page de couverture principale (page de garde)
Voir Modèle (page suivante du guide). Chaque section a sa couleur de fond spécifique
Exemple DSI en rose, RSI en vert et SEM en jaune. (Voir avec l’unité PFE).
b. Deuxième page de couverture
Cette page (verso du rapport) doit contenir un résumé (de 100 à 150 mots) du travail
effectué, exprimé dans les trois langues : arabe (‫) ملخص‬, français (Résumé), anglais
(Abstract). Le résumé situe le projet dans son contexte, présente ses objectifs, sa ou ses
méthode(s) et résume les principaux résultats des travaux. Il doit être complet et suffisamment
informatif pour être compris indépendamment du rapport du projet. Chaque résumé doit finir
par une liste de mots clés.

2. Dédicaces (optionnelle)
La page Dédicaces est réservée à l’expression de la gratitude de l’auteur envers ses parents,
ses amis, etc.

3. Remerciements
La page Remerciements est réservée à l’expression de la gratitude de l’auteur envers ses
encadrants , ses enseignants, le représentant de la société, du service ou du laboratoire au sein
duquel il a effectué son stage, le personnel technique ou administratif auprès duquel il a
trouvé aide et appui au cours de son travail. Ces remerciements sont exprimés en une dizaine
de lignes au maximum, de la façon la plus simple possible, sans platitude ni exagération.

4. Modèle de page de garde

1
 Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Logo de la
Direction Générale des Etudes Technologiques société
Institut Supérieur des Etudes Technologiques de Bizerte d’accueil
Département Technologies de l'Informatique

Référen Dép TI
ce .
AN 2013
N° .13

Rapport de
PROJET DE FIN D’ETUDES
En vue de l’obtention de :
Licence Appliquée en [SECTION]

(Titre)

Elaboré par :
Prénom1 NOM1
&
Prénom2 NOM2

Encadré par :
Couleur de la page de garde
Mme/Mr Prénom NOM (ISET) RSI DSI SEM
Mme/Mr Prénom NOM (vert) (blanc) (orange)
(ENTREPRISE)

Effectué à :
Entreprise : (NOM DE L’ENTREPRISE)
 Adresse : (ADRESSE DE L’ENTREPRISE)
 Tel : (TELEPHONE DE L’ENTREPRISE)
 Mail : (MAIL DE L’ENTREPRISE)
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

Année universitaire : 2012/2013

1
Département Technologies de l’Informatique Unité PFE

5. Table des matières

5.1 Forme
La table des matières (sommaire) permet, grâce à la pagination, de retrouver l’endroit où se
trouve un élément recherché par le lecteur. La table des matières doit être générée d’une

façon automatique. Elle ne doit pas présenter plus que trois niveaux de sous-titres.

Exemple de squelette de la table des matières

Sommaire
Introduction générale .............................................................................................................1
Chapitre 1 : Présentation du cadre du projet.......................................................................2
I. Présentation de la société.....................................................................................................2
II. Etude de l’existant..............................................................................................................2
II.1. Description de l’existant ........................................................................................2
II.2. Critique de l’existant..............................................................................................2
II.3. Solution proposée...................................................................................................2
III. [Méthodologie adoptée]....................................................................................................3
IV. Planification du projet ......................................................................................................3
…………………
…………………
…………………

Conclusion générale..............................................................................................................13
Bibliographie et Nétographie ..............................................................................................14
ANNEXES ............................................................................................................................15
ANNEXE A :..............................................................................................................16
ANNEXE B :..............................................................................................................17
ANNEXE C :..............................................................................................................19
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

5.2 Contenu
Le plan du rapport et son contenu sont à valider avec l’encadrant académique de l’institut,
cependant les membres de l’unité PFE et l’unité pédagogique ont opté à la nécessité de suivre
une méthodologie pour la gestion et la conception du projet.
 Pour la gestion de projet, le framework SCRUM a été proposé. Ainsi ses éléments
essentiels tels que : Le backlog Produit, les sprints et éventuellement les release
doivent figurer.
 Pour ce qui est de la conception, le choix s’est porté sur le Processus unifié afin de
suivre l’enchainement logique de ses diagrammes qui sont présentés par le langage de
modélisation UML
Les éléments de contenu proposés sont les suivants :
Remarque : Ces éléments ne sont pas exhaustifs. Ce plan peut être modifié selon ce que
l’encadrant juge comme pertinent. Il est judicieux de remarquer que les éléments du backlog
produit ainsi que les sprints peuvent varier au fur et à mesure de l’avancement du projet et de
là vient l’intérêt de l’agilité de SCRUM.

Remerciements
Table Des Matières
Table Des Figures
Tableaux
Introduction Générale
Chapitre I : Etude Préalable
Introduction
I. Présentation du projet, problématique et solution
II. Méthodologie Utilisée
1. Méthode de gestion de projet Agile Scrum
2. Méthode de modélisation et de conception
III. Etat De L’art [Optionnel]
IV. Technologies Et Outils De Travail
1. Environnement matériel
2. Environnement logiciel
V. Architecture de l’application
Conclusion

1
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

Chapitre II : Planification du backlog produit

Introduction
I. Identification des Profils utilisateurs
II. Les User Stories
III. Le Backlog Produit
Conclusion
Chapitre III : Release 1
Introduction
I. Sprint 1
1. Expression Des Besoins
2. Analyse Detaillée
3. Conception
4. Réalisation et Tests
[ II. Sprint 2
1. Expression Des Besoins
2. Analyse Détaillée
3. Conception
4. Réalisation et Tests
………………] optionnel si le release contient plus d’un sprint
Conclusion
Chapitre IV : Release 2
Introduction
I. Sprint 3
1. Expression Des Besoins
2. Analyse Détaillée
3. Conception
4. Réalisation et Tests
…….
Conclusion
……………
(continuer tant que nous avons d’autres release ou sprints
Conclusion Générale
Bibliographie & Netographie
Annexes

2
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

Remarques !
1) La conception globale de l’application (par exemple diagramme de classe global doit
figurer vers la fin du dernier release car nous n’aurons tous les besoins définis qu’au
niveau du dernier sprint.
2) Pour avoir une idée plus concrète sur les éléments du contenu vous trouvez en
Annexe un modèle de rapport où l’on trouve les parties du backlog Produit et les étapes
pour un release.

6. Liste des figures

Cette rubrique n’est pas obligatoire si le nombre de figures est inférieur à cinq (04). Elle est
générée automatiquement. Notez que le titre de la figure doit être placé en dessous de la
figure.
Exemple :
Liste des figures
Fig 1. Organigramme………….. ………..…4
Fig 2. Schéma de la solution………..……...25
Fig 3. Modèle Conceptuel de Données…….41

Remarque : vous pouvez utiliser « Figure » à la place de « Fig »,

7. Liste des tableaux

Cette rubrique n’est pas obligatoire si le nombre de tableaux est inférieur à cinq (04). Elle est
générée automatiquement. Notez que le titre du tableau doit être placé en dessus du tableau.
Exemple :
Liste des tableaux
Tab 1. Tableau récapitulatif de l’existant …20
Tab 2. Tableau des valeurs possibles……...25
Tab 3. Dictionnaire de données……………40

8. Introduction générale
L’introduction générale présente le sujet par des renseignements précis et pose le problème à
résoudre sans évocation de résultats. Une fois le problème posé avec clarté, les grands traits
de la démarche vers l’objectif sont décrits. En effet, le contenu de chaque chapitre est annoncé
brièvement. [Il faut éviter impérativement les introductions « passe partout »]

3
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

9. Développement des chapitres

C’est la partie essentielle du rapport. Le rapport est généralement constitué en chapitres, mais
aussi peut être subdivisé en parties et sous-parties. Chaque chapitre est structuré de façon à
rester lié avec ce qui précède et avec ce qui suit. Le contenu et l’enchaînement des chapitres
doivent être conformes à la méthodologie suivie pour l’élaboration du projet (en ce qui
concerne les étapes et les modèles).
Chaque chapitre comprend :
- Une introduction qui présente le contenu du chapitre ;
- Le développement du contenu du chapitre ;
- Une conclusion qui résume les principaux résultats du chapitre et qui introduit le
chapitre suivant.
La numérotation à l’intérieur d’un chapitre doit être faite sous forme hiérarchique
Exemple :
I. aaaaaa
II. xxxxx
II.1. yyyyy
II.1.1 zzzzz
II.1.2. zzzzz

10. Conclusion générale

La conclusion générale doit comprendre les points suivants :
- Récapitulation de la démarche complète annoncée par l’introduction générale ;
- Présentation des résultats : Réponses aux problèmes posés au début ;
- Les problèmes rencontrés lors de la réalisation du projet
- Les apports (techniques et autres)
- Perspectives d’approfondissement ou d’élargissement du sujet.

11. Bibliographie et Netographie

a. Bibliographie : Ouvrages et articles consultés lors de l’élaboration du projet, classés par
ordre alphabétique du nom de l’auteur, selon le modèle suivant :
[i] NOM_AUTEUR1, NOM_AUTEUR2, « Titre de l’ouvrage », lieu de publication, nom
de l’éditeur, année de publication, nombre de tomes, numéro de pages.

4
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

Exemple :
[1] REEVES, Hubert. « Bases de données relationnelles », Paris, Editions du seuil, 1988,
288p.

b. Netographie : Sites Web visités lors de l’élaboration du projet, avec une brève
description du thème consulté (une ou deux lignes au maximum), date de mise à jour du
site, plus la date de la dernière visite.
Exemple :
[2] [Link] : Fondements du langage [Link]. DV :Janvier 2011 consulté le
03 mars 2012

Il est impératif de référencer la bibliographie et nétographie au

niveau du rapport !!
Exemple : ….les bases de données ….. Intégrité … requête [1].
A ne pas mentionner !!!! :
• Les moteurs de recherche tels que [Link] ou [Link]
• Les cours étudiés au niveau de l’ISET ;

12. Annexes
Liste des documents explicatifs, diagrammes, fiches complémentaires, etc. Chaque annexe
doit avoir un titre.
Les annexes peuvent avoir une numérotation différente du reste du rapport.

13. Proposition de mise en forme

1. Corps du texte
- Justifié
- Interligne : Simple ou 1.5
- Police: Times New Roman, 12 pts

2. Marges
- 2.5 (haut, bas), 3 (gauche), 2 (droite)

5
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

3. Espacement entre les paragraphes

- Uniformiser l’espacement entre les titres et les paragraphes. (exp. 6pts avant et après)

4. Entête et pied de page

- L’entête peut contenir :
Gauche : titre du chapitre courant
Une ligne le séparant du texte de la page
- Le pied de page peut contenir le numéro de page centré
Rappel sur les règles de ponctuation :
1 Cas de ponctuation simple (‘.’ et ‘,’) : pas d’espace avant et un espace après.
2 Cas de ponctuation double (‘ ;’, ‘ :’, ‘ ?’, ‘ !’) : espace avant et espace après

5. Les puces et les numéros

Uniformiser l’utilisation des puces et des numéros (forme par niveau et espacement). Utiliser
des puces standard (point, cercle, tiret, carré)
1 N1
o N2
o N2
N3
6. Titre du chapitre
Chapitre i. Titre Avec i = 1, 2, …
Remarque : Si vous allez utiliser des pages de titre ces dernières ne doivent pas contenir ni
entête ni pied de page.
7. Titres et sous-titres
- Les titres et sous-titres doivent être sur le même niveau vertical
- On peut distinguer les niveaux de titres et sous-titres par la taille de police (Titre gras 16
pts, sous titre gras 14 pts)
- Eviter d’utiliser « : » à la fin d’un titre ou sous-titre

8. Conseils divers : Dans le texte du rapport

- N’utilisez pas « on »
-Utilisez « nous » pour la présentation de vos travaux même si le stage PFE est effectué par
un seul étudiant.

6
Département Technologies de l’Informatique Unité PFE, Unité Pédagogique

- Le temps à employer au niveau du rapport est impérativement le présent

- Utiliser « il » pour présenter le mode de fonctionnement …
- N’utilisez pas le soulignement de titre ou des parties de phrase.
- N’utilisez pas les couleurs pour les titres des chapitres :
- Encadrez la figures et les centrer.
- Essayez d’écrire des chapitres équilibrés de point de vue volume (nombre de pages)
- Evitez les paragraphes courts (2 ou 3 lignes).
- Chaque figure doit être référencée dans le texte (exemple : … comme le montre la
figure 6 ….).
- Evitez les « … » et le remplacer par « etc. »
- Mettez le texte complet des acronymes que vous utilisez lors de la première occurrence.
- Eviter le maximum possible les notes de bas de page
- Evitez les zones vides dans les pages (cause des figures) il faut déplacer les figures pour ne
pas laisser des zones blanches au milieu des chapitres.
- La numérotation commence à partir de la page « Introduction générale » : page 1
- Nombre de pages :
Introduction: 1-2 pages
Chapitres: 12-15 pages (pas plus de 3-4 chapitres dont au moins deux sur le travail personnel)
Conclusion:1-2 pages
9. Couleurs
A éviter sauf en cas de besoin (Courbes, Interfaces graphique de l’application, etc.
BON TRAVAIL
« LE BUT FAIT OUBLIER L’EFFORT »


7
Département Technologies de l’Informatique Unité PFE

Annexe : Modèle extrait d’un rapport PFE pour illustrer backlog produit et
sprints

Ce rapport est intitulé « ….. », réalisé par l’étudiant et encadré par Mme Nadia Hachani.

Product Backlog
Le carnet de produit est une liste ordonnée de tout ce qui pourrait être requis dans le produit
et est l'unique source des besoins pour tous les changements à effectuer sur le produit. C'est
un document qui évolue constamment au cours de la vie du produit et n'est jamais fini.

Chaque élément du carnet représente une fonctionnalité, besoin, amélioration et correctif,

auquel sont associés une description, une estimation de l'effort nécessaire à la réalisation de
l'élément et une grandeur permettant d'ordonner les éléments entre eux. Le carnet de produit,
son évolution et sa publication sont de la responsabilité du propriétaire du produit. Il peut
changer à discrétion l'ordre des éléments, ajouter, modifier le découpage en éléments,
modifier leur description, ou supprimer des éléments qui n'ont pas encore été réalisés par
l'équipe de développement. Les éléments en tête du carnet de produit sont destinés à être
traités dans la prochaine itération et sont les plus finement décrits et estimés. Ils sont dits
« prêts » dans la terminologie Scrum. Les éléments moins prioritaires peuvent être découpés
plus grossièrement en attendant de devenir prioritaires et affinés à leur tour.

L'activité d'affinage du carnet de produit et de ses éléments est effectuée conjointement par le
propriétaire du produit et par l'équipe de réalisation. C'est notamment elle seule qui a le mot
final sur les estimations des éléments du carnet du produit.
Backlog Product
 Back-Log Produit

Complexité
RELEASE

Semaine
Module

Priorité

Sprints
ID Story NOM Stories Type

En tant que Scrum Team on doit se documenter et s’auto-former sur les

Auto- 01 Documentation et Technical Sprint 1

Medium

W1/3
différents éléments qui identifient mon projet

TOP
-
Auto- 02 Autoformation story Sprint 2

En tant qu’administrateur je peux ajouter les informations personnelles des

Administr

Medium

Medium
étudiants et les enseignants afin de les identifier

ation
User story

W4
RELEASE 1

Gestion de En tant qu’administrateur je peux affecter les enseignants et les étudiants

Administr

W4-5
aux cours et aux salles de classes

ation
Auto- 03 l’administration de User story Sprint 3

Top

Top
l’université

En tant qu’administrateur je peux consulter le site web de la plateforme

Administr
ation
User story

Top

Top

W5
 Enseignant
Gestion des En tant que enseignant, je peux consulter et ajouter des cours et remplir les Sprint

W 6-9
Auto- 04 User story

Top

Top
enseignants fiche d’absences 4
RELEAE 2

Financier
Gestion du Sprint

Medium

W9-10
Auto- 05 En tant que financier, je peux consulter les tranches payé par les étudiants User story

Top
financier 5

Sprint
RELEASE 3

Admission
6

Medium

W11
Auto-06 Gestion des clubs En tant que étudiant, je peux consulter et s’inscrire dans un club User story

Top
Sprint
7

Librairie
Gestion des Sprint

W 12
Low

Low
Auto- 07 En tant que étudiant, je peux consulter mes notes d’examen User story
étudiants 8
RELEASE 4

En tant que parent, je peux consulter les activités et les notes de mes Sprint

Parent

W13
Low

Low
Auto- 08 Gestion des parents User story
enfants 9

Back-log produit

3
 CHAPITRE III : RELEASE 1

I. Introduction
Un release correspond à la livraison d'une version. Par habitude, on parle de release pour
considérer la période de temps qui va du début du travail sur cette version jusqu'à sa livraison
et qui passe par une série de sprints successifs.

Notre premier release porte sur deux points. Le premier s’agit de se documenter et s’auto-
former sur l’Odoo, les environnements et langages de développement et aussi de faire une
analyse et de tester les produits déjà présents sur le marché. Le deuxième consiste à
développer et concevoir une interface web pour la plateforme, aussi à configurer cette
dernière pour l’administration et l’accès.

Degré de difficulté
Id SPRINT

Release
Semaine
Id Story

Nom

Sprints
User Stories
Sprint

1 Documentation sur OpenERP M 1 S1 W1

Documentation et mise
en marche d’OpenERP

2 Installation d’OpenERP, Python et Pycharm D 1 S1 W1-3

Auto-01

3 Synchronisation entre les fonctions déjà présentes dans OpenERP M 1 S1 W3

4 Redéfinition des paramètres des fonctions F 1 S1 W3

5 Familiarisation avec l’environnement et les modules présent M 1 S1 W3

6 Etude sur les modules déjà présents et adaptation des besoins M 1 S1 W3

Release 1
7 Documentation et autoformation sur ubuntu et python D 1 S2 W3-4
marche de

8 Installation d’odoo8 sur ubuntu

Pycharm

D 1 S2 W4
Auto-02

Mise en

9 Paramétrage de pycharm sur ubuntu et instalation d’OpenEduCat D 1 S2 W4

10 découverte et correction des erreurs de programmation des modules D 1 S2 W4

Gestion 11 Création d’un site web pour la plateforme D 1 S3 W5

de
Auto-03

12 Création d’un onglet pour les documents D 1 S4 W6

l’adminis
13 Gestion et génération des papiers (relevé de note, inscription, attestation de
tration D 1 S4 W6
de présence…)
l’universi
té

11 Création d’un site web pour la plateforme D 1 S3 W5

Auto-03

12 Création d’un onglet pour les documents D 1 S4 W6

13 Gestion et génération des papiers (relevé de note, inscription, attestation de D 1 S4 W6

présence…)
 14 Gestion des droits d’accès et des permissions pour tous les membres de
F 2 S4 W6
l’université
15 Gestion (l’ajout, suppression et la modification) des étudiants et des salles F 2 S4 W6

16 Affectation des
étudiants par
salle, niveau et
filière

M 2 S4 W6

17 Gestion des droits d’accès et des permissions pour tous les étudiants M 2 S4 W6

1er RELEASE

II. Expression des besoins

1. Introduction
L'objectif de cette activité est de décrire textuellement, pour chaque Sprint, les scénarios

du cas d'utilisation. Il faut indiquer comment ce scenario démarre, comment il se termine et

les interactions de l’utilisateur avec l’application.

Description textuelle

Cas d’utilisation « Gérer Site web »

Acteur principal : L’administrateur.

Pré condition : L’administrateur ouvre le site web de la plateforme et s’authentifie

Post condition : Lancement de l’application et accès à l'interface principale.

Description : L’administrateur se connecte sur le site web de la plateforme, après il a la
possibilité de modifier son site web en appuyant sur le bouton « Edit » qui se trouve en haut
de la page

Cas d’utilisation « Gérer dossier »

Acteur principal : L’administrateur.

Pré condition : L’administrateur ouvre le site web de la plateforme et s’authentifie

Post condition : Lancement de l’application et accès à l'interface principale.

Description : L’administrateur gère les dossiers en choisissant un étudiant ou un enseignant à

affecter, si l’étudiant est déjà inscrit pour cette promotion donc il aura le droit de générer ses
documents et consulter son état financier

Conclusion
Au cours de cette activité, nous avons pu ressortir les principaux besoins des utilisateurs.
Nous avons essayé de décrire les principales fonctionnalités du système. Les résultats de cette
activité nous serviront de base pour l'élaboration de la prochaine.

III. ANALYSE
1. Introduction
Dans activité, nous allons présenter une description du processus actuel afin de faciliter la
phase de conception et d'implémentation de ce cas d’utilisation. Toutefois, au cours de cette
activité, nous allons effectuer l'analyse de différents cas d'utilisation en utilisant le diagramme
de classes et le diagramme de collaboration.

 Diagramme de classes
Ce diagramme exprime de manière générale la structure statique d’un système, en termes de
classes et de relations entre ces différentes classes.
 Diagramme de collaboration
Ce diagramme permet de mettre en évidence les interactions entre les différents objets du
système étudié, ainsi que les messages qu’ils échangent entre eux. Il permet donc de
représenter l'aspect dynamique du système .

Diagramme de classes du CU

Diagramme de classes du CU « Gérer Site web »

Diagramme de classes du CU « Gérer dossier »

Diagramme de collaboration du CU

Diagramme de collaboration du CU « Gérer Site web : Modifier une page web»

Diagramme de collaboration du CU « Gérer dossier : Génération d’une attestation

d’inscription »

Conclusion

Dans cette activité, nous avons réalisé l'analyse des cas d'utilisations « Gérer le site web » et
« Gérer dossier », étape essentielle pour la prochaine activité, la conception.
Conception
1. Introduction
Au cours de ce chapitre, nous allons représenter les diagrammes du modèle de conception des
cas d'utilisations « Gérer le site web» et « Gérer dossier », nous achèverons avec la
conception de la classe impliquée dans notre système et ses interactions.

Conception des cas d'utilisation

Cette activité consiste à détailler la structure statique du système sous forme de sous-
systèmes, classes et interfaces. Pour réaliser ceci, nous allons nous baser sur le diagramme de
classes détaillés et le diagramme de séquences. Ce dernier représente l'interaction entre les
différents objets en mettant l'accent sur le classement du message dans le temps durant
l'exécution du système.

Diagramme de classe de conception du CU « Gérer dossier»

Diagramme de séquence du CU

Diagramme de séquence du CU « Gérer site web »

 Diagramme de séquence du CU « Gérer dossier »

Conclusion

Dans ce qui précède, nous avons réalisé l'activité de conception des cas d’utilisations « Gérer
site web» et « Gérer dossier ». Le chapitre suivant sera consacré à la description du prochain
cas d’utilisation.

Réalisation
2. Introduction
Cette section présente les test et le résultat de toute cette analyse et conception précédemment
effectué. Après configuration et codage de nos besoins, nous avons produit un résultat satisfaisant
que nous présentons avec les imprimes écrans ci-dessous.
Les Test
Le test est une activité importante dont le but est d’arriver à un produit « zéro défaut ».

C'est la limite idéaliste vers laquelle on tend pour la qualité du logiciel. Généralement 40% du
budget global est consacré à l’effort de test.

Cycle de développement de test

Test « Boite noire »
Le test de la boîte noire est utilisé en programmation informatique et en génie logiciel, pour
tester un programme en vérifiant que les sorties obtenues sont bien celles prévues pour des
entrées données.

Principe :

 On considère le programme dans son aspect fonctionnel et non plus structurel.

 On partitionne le domaine (DE) en classes.

 On génère des cas de test aux limites de classe.

Interface utilisateur
Installation

Maintenant que le codage est terminé, on peut passer à l’installation des modules
personnalisés « CRM, Rh, comptabilité », qui installera d’abord les modules auxquels il est
lié, ensuite ajoutera ses propres fonctionnalités. Avant de lancer le serveur d’Odoo, on doit
copier les dossiers de ces modules dans le dossier « Addons » d’Odoo, ensuite on lance le
serveur (fichier [Link]), et nous pourrons à ce stade, installer notre nouveau
module.

Bien évidemment, on doit d’abord se connecter puis accéder aux paramètres. Une fois
connecté, on se rend aux paramètres, puis dans le menu modules, on lance une mise à jour de
la liste des modules, afin qu’on puisse trouver celui qu’on vient d’ajouter parmi la liste, puis
on lance l’installation des modules concernés

Interface « Installation local module »

Interface web

Dans ce volet nous pouvons consulter notre page d’accueil, ainsi que le forum, banques aux
questions et les évènements organisés par les clubs universitaires. Enfin nous envoyer nos
questions ou demandes à travers l’onglet « contact us »
Interface « page d’accueil »

Interface « Forum »
 Interface « Contact us »
Interface plateforme « odoo »

L’utilisateur se connecte sur son profil ainsi il pourra consulter ses informations et générer ces
documents

Interface « gérer document étudiant »

Après avoir cliqué sur le document souhaité, un téléchargement de ce dernier sous forme de
PDF sera effectué.
Interface « Carte étudiant »
 Interface « Générer certificat de présence »

Conclusion
Ce chapitre a été
le point de départ de notre
projet. Tout au long
de ces sections et
titres, nous nous sommes
documentés et
auto formés sur de
nouvelles technologies et
méthodes intervenants
dans le projet comme
la méthode Agile-Scrum
ou encore le langage de

programmation Python. Par la suite, nous avons mis en place une interface complète et dédiée
au site web et à la gestion de dossier des étudiants développé en partant d’analyse et
conception de nos user stories. A présent nous avons pu valider cette partie du projet et le
considérer comme livrable auprès du product owner et du scrum master.