Vous êtes sur la page 1sur 130

République Tunisienne

Ministère de l’Enseignement Supérieur


et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de fin d’Éudes

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques


Spécialité : Génie Logiciel et Systèmes d’Information

Par

Mouadh BENSALEM

Conception et Réalisation d’une Solution


Modulaire sous Odoo et d’une Application Android
« O’School »

Encadrant professionnel : Monsieur Amine KAMMOUN Chef de projet


Encadrant académique : Madame Héla HACHICHA Maître Assistante

Réalisé au sein de 716Solutions

Année Universitaire 2016 - 2017


République Tunisienne

Ministère de l’Enseignement Supérieur


et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de fin d’Éudes

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques


Spécialité : Génie Logiciel et Systèmes d’Information

Par

Mouadh BENSALEM

Conception et Réalisation d’une Solution


Modulaire sous Odoo et d’une Application Android
« O’School »

Encadrant professionnel : Monsieur Amine KAMMOUN Chef de projet


Encadrant académique : Madame Héla HACHICHA Maître Assistante

Réalisé au sein de 716Solutions

Année Universitaire 2016 - 2017


J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Encadrant professionnel, Monsieur Amine KAMOUN

Signature et cachet

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Encadrant académique, Madame Héla HACHICHA

Signature
Dédicaces

Ce travail n’aurait pu aboutir sans l’aide de plusieurs personnes. En commençant par rendre grâce
à Dieu pour m’avoir donné la force de travailler et faire de mon mieux.

Je dédie ce travail. . .

Á mes chers parents Fatima et Ezzedine

L’épaule solide, l’œil attentif compréhensif et les personnes les plus dignes de mon estime et de
mon respect. J’espère qu’un jour, je peux leurs rendre un peu de ce qu’ils ont fait pour moi, que
dieu leur prête bonheur et longue vie.

Je dédie aussi ce travail à tous ceux qui m’ont aidé à dépasser les moments difficiles.

Á tous ceux qui auraient voulu partager ma joie. . .

Qu’ils trouvent en ce travail l’expression de ma gratitude pour l’attention qu’ils portent


constamment à mes réussites.

Mouadh BENSALEM

ii
Remerciements

Avant tout,Je tiens à remercier Monsieur le président de jury qui à accepté

d’évaluer ce travail.
Les membres de jury qui ont accepté de juger ce projet à sa propre valeur.

Cependants s’il ya des personnes à qui je tiens à exprimer mes sentiments de


gratitude et respect,c’est bien mon encadrant du projet Monsieur Amine

KAMMOUN pour son suivi, sa disponibilité et ses recommandations tout au


long du stage et Madame Héla HACHICHA pour sa suivi et ses conseils tout

au long de la réalisation de rapport de stage.


Je présente un remerciement particulier à toutes les membres au sein de

716Solutions pour l’accueil et la coopération dont ils ont fait preuve.


Finalement, j’exprime mes vifs et sincères remerciements à toute personne

ayant participé de près ou de loin au bon déroulement de ce stage et à la


réalisation de ce modeste travail.

iii
Table des matières

Introduction générale 1

1 Etat de l’art 3
1.1 Introduction au monde des ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Les ERP libres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Etude comparative entre quelques ERP existants sur le marché . . . . . . . . 5
1.2 La plateforme Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Odoo et ses modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 Architecture fonctionnelle et technique d’Odoo . . . . . . . . . . . . . . . . . 8
1.2.3 Structure d’un module Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Les ERP Éducatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.1 OpenEduCat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.2 Fedena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.3 OpenSchool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Etude Préalable 15
2.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Présentation de 716Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Activités et services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Architecture de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Problématique du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Objectifs à atteindre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.1 Approche agile vs approche classique . . . . . . . . . . . . . . . . . . . . . . . 22

iv
2.6.2 Choix de la méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Sprint 0 25
3.1 Plan d’action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 Identification des acteurs et des fonctionnalités . . . . . . . . . . . . . . . . . 30
3.2.2 Exigences non-fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3 Diagramme cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 Environnement Matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.2 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.3 Langage de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Sprint 1 : Module O’School Évènement 41


4.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 User Story de sprint 1 : Module Évènement . . . . . . . . . . . . . . . . . . . 47
4.2.2 Raffinement des cas d’utilisations . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.1 Diagramme de classe partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.2 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.1 Intefaces O’School Evénement sous Odoo . . . . . . . . . . . . . . . . . . . . 52
4.4.2 Intefaces O’School Evénement sous Android . . . . . . . . . . . . . . . . . . . 56

5 Sprint 2 : Module O’School Admission 58


5.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.1 User Story de sprint 2 : Module Admission . . . . . . . . . . . . . . . . . . . 63
5.2.2 Raffinement des cas d’utilisations . . . . . . . . . . . . . . . . . . . . . . . . . 63

v
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.1 Diagramme de classe partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.2 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.1 Interfaces O’School Admission sous Odoo . . . . . . . . . . . . . . . . . . . . 69
5.4.2 Interfaces O’School Admission sous Android . . . . . . . . . . . . . . . . . . . 71

6 Sprint 3 : Module O’School Transport 74


6.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2.1 User Story de sprint 3 : O’School Transport . . . . . . . . . . . . . . . . . . . 78
6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.1 Diagramme de classe partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.2 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.4.1 Interfaces O’School Transport sous odoo . . . . . . . . . . . . . . . . . . . . . 85
6.4.2 Interfaces O’School Transport sous Android . . . . . . . . . . . . . . . . . . . 86

7 Sprint 4 : Module O’School Application Mobile 89


7.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.2.1 User Story de sprint 4 : O’School Mobile Application . . . . . . . . . . . . . . 91
7.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.3.1 Diagramme de classe partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.3.2 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.4.1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Conclusion générale 103

Bibliographie 105

Annexes 108
Annexe 1. Comparaison entre les méthodologies agile les plus utilisé . . . . . . . . . . . . 108

vi
Annexe 2. Rapports de service de Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Annexe 3. Site Web : Partie Commerciale de projet . . . . . . . . . . . . . . . . . . . . . 112
Annexe 4. Sécurité sous Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

vii
Table des figures

1.1 Taux d’intérêt de recherche effectuées odoo/OpenBravo/Dolibarr/WebERP/ERPNEXT 6


1.2 Taux d’intérêt de recherche effectuées sur odoo/openerp/tinyerp . . . . . . . . . . . . 7
1.3 Nombre de résultats sur le nombre de recherche Google pour le terme odoo . . . . . 7
1.4 Modules Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Protocole de transport d’Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Architecture de déploiement Odoo [10] . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Structure d’un module Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Structure d’un module Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.9 Interface de OpenEducat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.10 Page d’accueil de Fedena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.11 Page d’accueil de openschool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Organigramme de l’entreprise «716Solutions» . . . . . . . . . . . . . . . . . . . . . . 17


2.2 Espace Parent de plateforme Educanet . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Fonctionnalités de notre système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Méthodologie agile vs. Classique [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Méthode SCRUM [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Echelle de complexité utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


3.2 Diagramme cas d’utilisation global de la partie systéme . . . . . . . . . . . . . . . . 33
3.3 Diagramme cas d’utilisation global de la partie Mobile . . . . . . . . . . . . . . . . . 34
3.4 Architecture globale de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Diagramme de cas d’utilisation « Gérer événements » . . . . . . . . . . . . . . . . . . 47


4.2 Diagramme de séquence « Ajouter événements » . . . . . . . . . . . . . . . . . . . . 48
4.3 Diagramme de cas d’utilisation « Consulter liste des demandes de participation aux
événements» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Diagramme de classe sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Diagramme de séquence « Consulter liste des événements » . . . . . . . . . . . . . . 52
4.6 Page d’accueil et d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

viii
Table des figures

4.7 Liste des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54


4.8 Liste des demandes de participations à un événement . . . . . . . . . . . . . . . . . . 54
4.9 Ajouter un événement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10 Vue du calendrier des événements disponible . . . . . . . . . . . . . . . . . . . . . . . 55
a Liste des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
b Détail d’un événement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.12 Consulatation des événements disponibles ainsi que leurs détails . . . . . . . . . . . . 56
a Liste de mes événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
b Détail d’un événement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.14 Consulatation de mes participations ainsi que leurs détails . . . . . . . . . . . . . . . 57

5.1 Diagramme de cas d’utilisation Consulter liste des demandes d’admission . . . . . . . 63


5.2 Diagramme de séquence « Consulter liste des demandes d’admission » . . . . . . . . 64
5.3 Diagramme de cas d’utilisation Consulter liste des élèves . . . . . . . . . . . . . . . . 64
5.4 Diagramme de séquence « Générer la carte d’élève» . . . . . . . . . . . . . . . . . . . 65
5.5 Diagramme de classe de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6 Diagramme de séquence « Traiter demandes d’admission » . . . . . . . . . . . . . . . 69
5.7 Liste des demandes d’admissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.8 Traitement d’une demande d’admission . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.9 Carte d’élève . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
a Liste de demande admission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
b Détail d’une demande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.11 Consultation demande d’admission ainsi que ainsi que leurs détails . . . . . . . . . . 72
5.13 Profil élève . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.1 Diagramme de cas d’utilisation «Paramétrer les informations du service du transport» 79


6.2 Diagramme de cas d’utilisation «Gérer les abonnements au service du transport» . . 81
6.3 Diagramme de séquence « Ajouter un itinéraire » . . . . . . . . . . . . . . . . . . . . 83
6.4 Diagramme de classe de Sprint 3 : Transport . . . . . . . . . . . . . . . . . . . . . . 84
6.5 Diagramme de séquence d’objets « Consulter liste des itinéraires » » . . . . . . . . . 85
6.6 Liste des Itinéraires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.7 Inscription aux Transports (Responsable) . . . . . . . . . . . . . . . . . . . . . . . . 86

ix
Table des figures

6.8 Inscription aux Transports (Parent) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86


a Liste des demandes au transport . . . . . . . . . . . . . . . . . . . . . . . . . 87
b Détail d’une demande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.10 Consultation demande d’abonnement au service de transport ainsi que ainsi que leurs
détails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
a Liste des routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
b Détail de routier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.12 Consultation demande d’abonnement au service de transport ainsi que ainsi que leurs
détails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.1 Diagramme de cas d’utilisation «Consulter les services à proximité» . . . . . . . . . . 91


7.2 Diagramme de séquence « Consulter Services à proximité» . . . . . . . . . . . . . . . 93
7.3 Diagramme de cas d’utilisation «Consulter liste des numéros de téléphone» . . . . . 94
7.4 Diagramme de classe partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.5 Diagramme de séquence « Consulter Services à proximité» . . . . . . . . . . . . . . . 97
a Splash Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
b Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.7 Interfaces d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
a Interface d’authentification d’élève . . . . . . . . . . . . . . . . . . . . . . . . 99
b Interface d’authentification de parent . . . . . . . . . . . . . . . . . . . . . . . 99
7.9 Interfaces d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
a Liste des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
b Géolocaliser les services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.11 Interfaces d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
a Inscription au service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
b Ajouter numéro de contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.13 Interfaces de service de suivi des enfants . . . . . . . . . . . . . . . . . . . . . . . . . 101
a Liste des enfants suivis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
b Géolocaliser des enfants suivis . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.15 Interfaces de localisation des enfants . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8.1 Rapport des Informations de Transport . . . . . . . . . . . . . . . . . . . . . . . . . 110

x
8.2 Rapport des Informations de véhicule . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.3 Charte graphique de site web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.4 Ajouter contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.5 Permissions des groupes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

xi
Liste des tableaux

1.1 Comparaison de quelques ERP open source . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Produit Backlog de notre application . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


3.2 Les quatre sprints et leurs Durée d’exécution . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Les différents acteurs interagissant avec notre système . . . . . . . . . . . . . . . . . 31
3.4 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 Produit Backlog de Module Évènement . . . . . . . . . . . . . . . . . . . . . . . . . . 42


4.2 Consulter liste des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Consulter liste des demandes de participations . . . . . . . . . . . . . . . . . . . . . . 50

5.1 Produit Backlog de Module Admission . . . . . . . . . . . . . . . . . . . . . . . . . . 59


5.2 Accepter demande d’admission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1 Produit Backlog de Module Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 76


6.2 Paramétrer la liste des chauffeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3 Ajouter un abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.1 Produit Backlog de Module O’School . . . . . . . . . . . . . . . . . . . . . . . . . . . 90


7.2 Services à proximité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.3 Localiser un élève( numéro ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8.1 Comparaison entre les méthodologies agile les plus utilisées à savoir : RAD, 2TUP,
XP et Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

xii
Liste des abréviations

— CSV = CommaSeparated Values

— ERP = Entreprise Ressource Planning

— GPS = GlobalPositioning Satellite System

— MVC = Modèle Vue Controleur

— RUP = Rational Unified d’Process

— XML = ExtensibleMarkup Language

=
— XML-RPC ExtensibleMarkup Language Remote Procedure Call

— XUP = EXtreme Unified d’Process

xiii
Introduction générale

Les technologies de l’information changent le monde entier autour de nous, devenant désormais
un facteur principal du développement qui touche tous les secteurs de la société. L’éducation est
parmi les domaines qui profitent de l’utilisation de ces nouvelles technologies et ce afin de faciliter
tous les processus des établissements éducatifs, depuis l’admission des nouveaux étudiants ou élèves
à la génération des diplômes lors de la fin des études.
Nous constatons de la situation des systèmes éducatifs actuels des collèges et des écoles que ces
systèmes souffrent de plusieurs problèmes qui ne devraient pas exister dans une époque d’émergence
de la technologie.
Parmi ces problèmes, nous notons l’utilisation encore d’une gestion manuelle des documents
( Inscription, suivi de l’état des demandes envoyées, ...).Également, nous rencontrons un manque
important de synchronisation entre les différents services au sein d’un même établissement.En plus,
nous avons remarqué l’absence d’un système permettant la communication et l’interaction avec les
parents et les élèves.
De plus, le besoin de la mise en place d’un système d’information se fait de plus en plus
ressentir. En effet,en Tunisie,et selon l’institut de sondage Sigma Conseil, en 5 ans, depuis l’année
scolaire 2010/2011 à l’année scolaire 2014/2015, le nombre des écoles primaires privées a plus que
doublé, il est passé de 109 à 263 en Tunisie, soit une croissance de 141% et le nombre d’élèves du
primaire dans le secteur privé est passé de 24.953 en 2010/2011 à 48.390 en 2014/2015, soit une
progression de 94 % en 2010/2011, l’enseignement primaire privé concernait 2,4 % de l’ensemble
des élèves du cycle, alors qu’en 2014/2015 la part du nombre d’élèves évoluant dans le secteur
privé représente 4,3% [1]. Ces statistiques prouvent la présence d’un marché très important pour
commercialiser notre produit.
C’est dans ce cadre que ce projet a pris naissance. Nous proposons la réalisation de notre
solution O’School pour la gestion des activités au sein d’un établissement scolaire avec une application
mobile(Android) pour que les élèves et leurs parents peuvent interagir avec les écoles.Nous proposons
également de développer un site web afin de publier les services offerts par les écoles.
Le présent rapport est structuré en quatre chapitres, comme suit :
— le premier chapitre intitulé Etat de l’art, où nous allons introduire le monde des ERP ainsi que
quelques solutions ERP existantes afin de pouvoir réaliser notre projet et nous terminerons

1
Introduction générale

par description quelques ERP éducative similaire à notre solution ;

— Le deuxième chapitre intitulé Étude Préalable où nous allons introduire le cadre général de
notre projet à savoir son contexte, sa problématique ainsi que les principaux objectifs de notre
solution logicielle et nous terminerons par la description de la méthodologie de travail pour
laquelle nous allons opter ;

— Dans le chapitre suivant, nous examinerons le fonctionnement de notre application à travers le


Backlog du produit qui met en clair les exigences de notre projet en vue de préparer le chemin
à une bonne étude technique ;

— Quand aux trois derniers chapitres, chacun d’entre eux traite une itération de notre projet.
Nous spécifierons et nous analyserons d’abord nos exigences. Ensuite nous présenterons la
démarche conceptuelle pour aboutir enfin à la description de la phase de réalisation.

2
Chapitre 1

Etat de l’art

Plan
1 Introduction au monde des ERP . . . . . . . . . . . . . . . . . . . . . . . 4

2 La plateforme Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Les ERP Éducatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11


Chapitre 1. Etat de l’art

Introduction

Dans ce chapitre, nous commoncons par une présentation des ERP ainsi que quelques solutions
ERP existantes afin de pouvoir réaliser notre projet. Ensuite, nous élaborons une étude comparative
de quelques Progiciels libre afin de justifier notre choix de travailler avec ERp Odoo. Enfin, nous
décrivons quelques ERP éducatifs similaire à notre solution.

1.1 Introduction au monde des ERP

L’acronyme ERP signifie Enterprise Ressource Planning traduit en français par Progiciel de
Gestion Intégré ou PGI. ERP est le terme le plus couramment utilisé. Un ERP est un progiciel
qui permet de gérer d’une manière centralisée l’ensemble des processus d’une entreprise intégrant
l’ensemble de ses fonctions comme la gestion des ressources humaines, la gestion financière et
comptable, l’aide à la décision, la vente, la distribution, l’approvisionnement, la production ou encore
du e-commerce. Le principe fondateur d’un ERP est de construire des applications informatiques
correspondant aux diverses fonctions citées précédemment de manière modulaire sachant que ces
modules sont indépendants entre eux, tout en partageant une base de données unique et commune
au sens logique. L’autre principe qui caractérise un ERP est l’usage de ce qu’on appelle un moteur
de workflow et qui permet, lorsqu’une donnée est enregistrée dans le système d’information, de la
propager dans les modules qui en ont l’utilité, selon une programmation prédéfinie [2].
Ainsi, on peut parler d’ERP lorsqu’on est en présence d’un système d’information composé de
plusieurs applications partageant une seule et même base de données, par le biais d’un système
automatisé prédéfini et éventuellement paramétrable.

1.1.1 Les ERP libres

Selon FSF (Free Software Foundation), à l’origine du concept, le logiciel libre est un logiciel
fourni avec l’autorisation pour quiconque l’utiliser, le copier, le distribuer, soit sous une forme
conforme à l’original, soit avec des modifications, ou encore gratuitement ou contre un certain
montant.
Pour être libre, un logiciel doit respecter quatre libertés fondamentales :

4
Chapitre 1. Etat de l’art

• La liberté d’exécution,

• La liberté d’étude,

• La liberté de redistribution des copies,

• La liberté d’amélioration.

De plus, comme tout logiciel libre, les ERP libres donnent la garantie de travailler sur des standards
ouverts et donc inter opérables qui offre des avantages stratégiques pour beaucoup d’entreprise [3].

1.1.2 Etude comparative entre quelques ERP existants sur le marché

Les logiciels ERP sont particulièrement adaptés aux PME qui veulent maîtriser et optimiser
leur chaîne de production et avoir de la visibilité sur le projet qu’elles veulent concevoir et développer.
Côté secteurs, les logiciels ERP sont particulièrement prisés par les entreprises du domaine des
services, des domaines de l’informatique et de l’Internet. Elles doivent en effet gérer des projets sur
le long terme. De manière globale, les logiciels ERP s’adressent aux entreprises menant des projets
nécessitant de multiples compétences et devant coordonner le travail de plusieurs équipes ou au
moins de plusieurs personnes. On peut considérer qu’un logiciel ERP est nécessaire pour conduire
un projet où une dizaine de personnes doit intervenir.
Le tableau 3.3 présente les principaux ERP et outils CRM en open source

Tableau 1.1: Comparaison de quelques ERP open source

ERP Open source Couverture fonctionnelle Environnement de travail

OpenBravo [4] (Année de Comptabilité, finance, achat, vente, J2EE, Postgresql ou oracle
création : 2001) stock, production, CRM, point de
vente

Dolibarr [5] (Année de Comptabilité, finance, achat, vente, PHP, Postgresql


création :2003) stock, production, CRM

Odoo [6] (Année de création :2002) Comptabilité, finance, achat, vente, Python, XML, Postgresql
stock, production, CRM, point de
vente, GED, e-commerce, RH

WebERP [7] (Année de Comptabilité, finance, achat, vente, J2EE, JBoss


création :2003) stock, production, RH

5
Chapitre 1. Etat de l’art

ERPNEXT [8] (Année de Comptabilité, finance, achat, vente, J2EE, JBoss


création :2008) stock, production, RH

Pour réaliser cette étude comparative entre les ERP nous avons utilisé «Google trends », cet
outils va nous permettre de savoir la fréquence de recherche de ces termes sur le moteur de recherche
Google. Ainsi les résultats nous ont donnés une idée globale sur le Framework le plus utilisé ou
autrement dit le Framework qui a la plus grande quantité de ressources sur internet.
La figure 1.1 montre la fréquence de recherche de quelques ERP open source.

Figure 1.1: Taux d’intérêt de recherche effectuées


odoo/OpenBravo/Dolibarr/WebERP/ERPNEXT

La figure 1.2 présente le changement marque de «TinyERP» à «OpenERP » en 2008 puis


vers « Odoo » en 2014, sans aucun impact significatif sur l’activité.

6
Chapitre 1. Etat de l’art

Figure 1.2: Taux d’intérêt de recherche effectuées sur odoo/openerp/tinyerp

Pour avoir une idée sur le nombre de ressources qui sont archivés dans le Datacenter de
Google. nous avons utilisé le moteur de recherche directement et on a obtenu les résultats suivants
La figure 1.3 montre le nombre de résultats sur le nombre de recherche Google pour le terme
odoo

Figure 1.3: Nombre de résultats sur le nombre de recherche Google pour le terme odoo

Après une comparaison approfondie entre les progiciels que nous avons mentionnés dans le
tableau précèdent, nous avons choisi de travailler avec « Odoo » pour les avantages qu’il possède :

• Capacité fonctionnelle,

• Fiabilité,

• Facilité d’utilisation,

• Facilité d’utilisation,

• Rendement/Efficacité,

• Maintenabilité.

7
Chapitre 1. Etat de l’art

1.2 La plateforme Odoo

Créée en 2002 par Fabien PINCKAERS, anciennement connu sous le nom TinyERP, Odoo est
un Progiciel de Gestion intégré (PGI) en anglais Enterprise Ressource Planning (ERP), Open Source,
il permet de construire des applications informatiques (gestion des commandes, des stocks, de la paie,
de la comptabilité, etc), modulaire et intégrée au niveau des traitements offerts (les différents modules
qui le composent sont indépendants mais parfaitement compatibles entre eux),ainsi rigoureux et
cohérent au niveau des données gérées (partage d’une base de données unique et commune), Fournir
à l’ensemble des acteurs de l’entreprise une image unique,en plus il est cohérente et homogène
de l’ensemble de l’information, Fédérer l’ensemble des processus de l’entreprise dans chacun des
domaines qui la constituent et ce, dans une approche transversale qui optimise sa productivité,
logiciel dans lequel le code source est à la disposition du grand public, généralement un effort de
collaboration où les programmeurs améliorent ensemble le code source.

1.2.1 Odoo et ses modules

Grâce à la communauté open source, le catalogue de logiciels d’Odoo s’était développé bien
plus rapidement que pour un éditeur de logiciels dits «propriétaires» (comme ceux de SAP,Microsoft,
Sage, Oracle) pas moins de 500 modules étaient déjà à disposition des entreprises. On notait déjà
plus de 1000 installations par jour, devenant le logiciel de gestion le plus installé au monde [6].
La figure 1.4 présente les modules Odoo.

1.2.2 Architecture fonctionnelle et technique d’Odoo

Odoo possède une structure modulaire qui permet d’ajouter de nouveaux modules facilement
pour étendre les fonctionnalités. Un module est un dossier avec une structure prédéfinie contenant
du code Python et des fichiers XML, qui permet de définir la structure de données, formulaires,
rapports, menus, procédures, flux de travail, etc. Lors de la première installation,on installe le noyau
d’Odoo avec un certain nombre de modules selon le profil d’installation choisit.
Comme précédemment expliqués, nous avons choisi de travailler avec odoo version 8 pour les
avantages qu’il présente :

• Répondant aux besoins de notre solution O’School en premier lieu,

• La stabilité par rapport à la version 9 et 10 en second lieu.

8
Chapitre 1. Etat de l’art

Figure 1.4: Modules Odoo

Odoo est basé sur une architecture client/serveur. Le serveur et le client communiquent via le
protocole XML-RPC. XML-RPC c’est un simple protocole qui permet au client de faire des appels
aux Procédures. Une fois la fonction est appelée, ses arguments et ses résultats sont envoyés par le
protocole http, eux-mêmes sont encodés par le langage XML [9].
La figure 1.5 présente le protocole de transport d’Odoo

Figure 1.5: Protocole de transport d’Odoo

La logique d’odoo est entièrement du côté serveur. La tâche du client se résume à demander
les données (formulaire ou listes) au serveur et de les renvoyer. Avec cette approche, presque tout
le développement est fait du côté serveur,ce qui rend Odoo plus simple au développement et à la
maintenance.
La figure 1.6 présente l’architecture de déploiement Odoo.

9
Chapitre 1. Etat de l’art

Figure 1.6: Architecture de déploiement Odoo [10]

1.2.3 Structure d’un module Odoo

La figure 1.7 présente la structure d’un module Odoo

Figure 1.7: Structure d’un module Odoo

Pour créer un module Odoo, il y’a des étapes essentielles à suivre :

• Créer un package python dans le répertoire /addons portant le nom de votre module,

• Créer un fichier de description du module openerp.py,

• Créer le fichier Python contenant les modèles (Classes + Méthodes),

• Créer des fichiers .XML pour définir les menus, les vues et les actions,

10
Chapitre 1. Etat de l’art

• Créer éventuellement des rapports, des assistants (Wizard) ou des flux de travail(Workflow)[10].

La figure 1.8 présente la structure d’un module Odoo

Figure 1.8: Structure d’un module Odoo

1.3 Les ERP Éducatifs

L’ERP pour l’éducation prend de l’avance partout dans le monde. ERP offre un contrôle
centralisé de l’entreprise. Il peut s’agir de l’école, du collège, de l’organisation ou de tout institut.
Aujourd’hui, nous discuterons de la solution ERP en tant que meilleur système d’information
étudiante disponible. De plus, notre attention sera uniquement centrée sur les solutions open source.
La source ouverte est le principal facteur par lequel l’innovation se déroule dans l’industrie. De plus
en plus de développeurs contribuent à la scène open source, ce qui en fait un excellent écosystème
pour tous L’ERP pour l’éducation prend de l’avance partout dans le monde. ERP offre un contrôle
centralisé de l’entreprise. Il peut s’agir de l’école, du collège, de l’organisation ou de tout institut.
Aujourd’hui, nous discuterons de la solution ERP en tant que meilleur système d’information
étudiante disponible. De plus, notre attention sera uniquement centrée sur les solutions open source.
La source ouverte est le principal facteur par lequel l’innovation se déroule dans l’industrie. De plus
en plus de développeurs contribuent à la scène open source, ce qui en fait un excellent écosystème
pour tous.
Commençons par les meilleur systèmes de gestion scolaire open source et la solution ERP
disponibles sur le marché.

11
Chapitre 1. Etat de l’art

1.3.1 OpenEduCat

OpenEducat est une solution de gestion des écoles.Il est doté de fonctionnalités telles que la
gestion de la classe,des bibliothèques et bien plus encore.
Le système ERP est développé utilisant Python, JavaScript et XML. OpenEducat permet aux
écoles d’utiliser facilement les modules Odoo pour leurs besoins. La personnalisation est également
facile par rapport aux autres solutions ERP open source pour l’école [11].
La figure 1.9 présente l’interface de la rubrique étudiants.

Figure 1.9: Interface de OpenEducat

1.3.2 Fedena

Fedena est une autre solution open source à prendre en compte. Il est livré avec beaucoup des
fonctionnalités, y compris une bonne administration, la gestion financière, les ressources humaines.
La solution est créée à l’aide de Ruby on Rails. La plate-forme prend en charge des tonnes de
modules, mais la version gratuite de la plate-forme limite dans une certaine mesure [12]

12
Chapitre 1. Etat de l’art

La figure 1.10 présente page d’accueil de Fedena.

Figure 1.10: Page d’accueil de Fedena

1.3.3 OpenSchool

OpenSchool est notre prochaine entrée dans la liste. C’est une solution pour les écoles qui
cherchent à automatiser leurs processus scolaires. Avec quatre versions différentes, OpenSchool
permet à l’école de choisir son produit en conséquence. Les quatre versions comprennent la communauté,
le professionnel avec frais, OEM et premium [13].
La figure 1.11 présente page d’accueil de OpenSchool.

13
Chapitre 1. Etat de l’art

Figure 1.11: Page d’accueil de openschool

Conclusion

Dans ce chapitre, nous avons fait une étude comparative de quelques ERP et spécifier le choix
de ces dernier pour réaliser notre application.Ensuite, nous avons cité quelques solutions des ERP
éducatives dans le marché.
Nous passons par la suite au chapitre suivant où nous allons faire l’étude préalable de notre projet.

14
Chapitre 2

Etude Préalable

Plan
1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Objectifs à atteindre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapitre 2. Etude Préalable

Introduction

Dans ce chapitre, nous commençons par présenter l’organisme d’accueil ainsi que ses services.
Ensuite, nous présentons l’étude de l’existant suivit d’une critique de ce dernier. Enfin, nous décrivons
notre solution proposée et les objectifs à atteindre ainsi que la méthodologie adoptée.

2.1 Organisme d’accueil

Cette section sera consacré à la présentation de l’organisme d’accueil ainsi que les services
qu’il offre.

2.1.1 Présentation de 716Solutions

Notre projet a été réalisé au sein de la société 716 Solutions, société de services IT spécialisée
dans l’intégration de solutions open source hébergées dans le Cloud, elle propose aux entreprises
des solutions durables et efficaces pour répondre à leurs problématiques de modernisation et de
déploiement de systèmes d’information dans un contexte international.

2.1.2 Activités et services

Au vu des avancées technologiques qui ont modifié les attentes des utilisateurs et des pressions
importantes sur les budgets, 716 Solutions a pour but d’atteindre le niveau d’exigence de ses clients,
qui n’a jamais été aussi élevé, elle a acquis un savoir-faire susceptible de lui permettre l’implantation
de logiciels libres dans les différents secteurs. Conscient de l’importance de leurs engagements vis-à-vis
de leurs clients, leurs apports couvrent les catégories suivantes [14] :

• Open source :Il constitue le cœur métier de 716 Solutions et comprend le développement,
l’intégration et l’adaptation. L’entreprise utilise l’ERP open source Odoo, elle adapte celui-ci
à la législation tunisienne et aux besoins spécifiques des PME,

• Formation et conseil : L’offre des formations, techniques et fonctionnelles, permet d’accompagner


les organisations qui disposent d’équipes opérationnelles capables de mener à bien des projets.
Ces formations peuvent être établies sous forme de transferts de compétences, en phases avals
des projets,

• Développement : L’objectif de 716 Solutions est de développer des solutions informatiques


soit sur la base de logiciels libres soit sur des plateformes de développement, de portails

16
Chapitre 2. Etude Préalable

collaboratifs Internet ou Intranet, avec des composantes de publication web.

2.1.3 Architecture de l’entreprise

716 Solutions dispose d’une ressource humaine capable de répondre rapidement aux besoins
des entreprises, de même qu’aux changements technologiques imposés par le marché.
La figure 2.1 représente l’organigramme de l’entreprise «716Solutions».

Figure 2.1: Organigramme de l’entreprise «716Solutions»

2.2 Présentation du projet

Notre projet consiste à concevoir et à développer des modules sous Odoo ERP, une application
Mobile sous Android destinées essentiellement pour les écoles primaires ainsi qu’une partie web
commerciale (Voir Annexe 3). Cet ERP éducatif permet d’informatiser le processus scolaire allant
des activités pédagogiques à la gestion des ressources humaines (absence, les congés,les notes,etc).
L’application mobile offre une vue simple et mobile pour accéder aux fonctionnalités de base et
d’autre fonctionnalités supplémentaire autour de l’élève et le parent (services à proximités, localisation,
etc).

2.3 Étude de l’existant

Pour parvenir à présenter une bonne spécification des besoins, nous sommes tenus d’organiser
et de bien analyser les fonctionnalités et les résultats attendus par notre projet. Dans cette optique,

17
Chapitre 2. Etude Préalable

nous allons commencer par une étude des outils et des solutions existantes pour pouvoir en dégager
les défauts et mettre en valeur l’apport de notre solution.

2.3.1 Présentation de l’existant

Actuellement, les écoles tunisienne utilise la plateforme Educanet afin de gérer son processus
d’enseignement.
La plateforme web Educanet est un système de gestion éducatif tunisien pour un cadre
d’enseignement primaire, secondaire et universitaire.
Techniquement Educanet a été développé avec ASP.net et J2EE utilisant une base de données
MySQL ou Oracle avec un serveur web Microsoft IIS Server.
Avec Educanet la Direction peut supervise et contrôle le flux d’informations entre les élèves,
les parents et les enseignants,les élèves peuvent consulter leurs notes,leurs absences et les changements
d’emplois des temps.Peuvent aussi communiquer avec leurs enseignants, entre eux dans un contexte
pédagogique bien surveillé,les parents Accèdent aux notes, moyennes, appréciations des enseignants.
Finallement les Enseignants peuvent A tout moment réservent les salles et les labos. Saisissent
et consultent les notes et les moyennes de leurs classes et élèves.
La figure 2.2 représente l’espace parent de plateforme Educanet

Figure 2.2: Espace Parent de plateforme Educanet

18
Chapitre 2. Etude Préalable

2.3.2 Critiques de l’existant

En étudiant la solution existante,nous avons constaté qu’elle a des imperfections au niveau des
fonctionnalités vu que cette solution citée ci-dessus se limite a des fonctionnalités administratives.Educanet
ne tient pas compte des besoins affectant la vie quotidienne de l’élève tels que les services des
transports,gestion des abonnements et des événements avec un tableau de bord représentant des
statistiques concernant les modules de système.Concernant l’application mobile de Educanet qui
exploite les services de système sans bénéficier de la puissance de smart-phone.

2.3.3 Problématique du projet

Le système éducatif tunisien identifier plusieurs problèmes qui devrez pas exister dans une
époque d’émergence de la technologie et de l’informatique . Parmi ces problème on peut citer
l’adaptation d’une gestion manuelle sur papier des services . D’autre part on constate l’absence
d’un système permettant la communication et l’interaction avec les parents et les élèves. Nous
rencontrons aussi un grand manque de synchronisation entre les différents services au sein d’un même
établissement scolaire. Ces derniers n’utilisent pas des solutions modulaires facilitant les traitements
et l’automatisation des services , un concept permettant une coordination temps réel et une bonne
synchronisation . Les parant pouvant ainsi se bénéficier de ce concept et accédant directement à
l’administration. Tout ce mécanisme de travail n’as pas encore vu le jour ce qui crée plusieurs
défaillances dans l’établissement éducatif .
Suite aux problèmes précités précédemment, nous nous intéressons, dans le cadre de ce projet
à développer un ERP éducatif dédié au écoles primaires présentées dans la section suivante.

2.4 Solution proposée

Notre solution nommé " O’School " est une application de gestion scolaire pour les établissements
d’enseignement. C’est une solution de gestion complète pour les écoles,il est possible de gérer au
sein d’un même logiciel tous les aspects du fonctionnement de votre établissement scolaire. Avec
la partie Système, O’School offre une application mobile(Android) qui exploite les services autour
de l’élève et le parent à travers les web services avec des autres services supplémentaire (service à
proximité,localiser fils,etc).
Les différents modules représentant les fonctionnalité de notre système sont synthétisées par
la figure 2.3 suivante :

19
Chapitre 2. Etude Préalable

Figure 2.3: Fonctionnalités de notre système

O’School dispose de toutes les fonctionnalités pour gérer efficacement l’ établissement scolaire.
Ces modules sont :

— Basic : Ce module offre des fonctionnalité divers tel que la gestion des listes des élèves et des
parents,des niveaux scolaires et des classes,aussi la gestion des caisses de ventes,

— Events : A travers le module Le module, il est possible de définir des événements (Excursion,
Fête de fin d’année,etc) ainsi que leurs prix ,la gestion des inscriptions ainsi que l’analyse des
inscriptions par niveau, classe,etc,

— Transportation : Le module de Transport fourni des fonctionnalité des gestion des bus, des

20
Chapitre 2. Etude Préalable

chauffeurs, la Définition des types d’abonnements selon le nombre des navettes ainsi que leurs
prix avec la génération des reçus de paiement imprimable,

— Admission : Ce module répartie sur deux plateforme (web et Odoo) affin de soumettre une
demande d’admission et le traitement de ce dernier,

— Schooling : Le module O’school Études offre les fonctionnalités tel que la définition des types
des études ainsi que leurs prix,gestion des emploi,des calendrier des examens et de temps
avec ma génération des reçus de paiement imprimable et l’analyse des inscriptions par niveau,
classe,etc

— Extra : Ce module permet de fournir des fonctionnalités supplémentaire tel que les ventes des
articles (Tablier, livres. . . )

Dans cette partie, nous avons présenté la description des modules de la partie client (application
mobile Android).
O’School Mobile exploite les services autour de l’élève et le parent à travers les web services
on ajoutant d’autre fonctionnalité profitant la puissance des smartphones :

— Trouver mon fils : Aidez les parents à suivre leurs enfants en mode en ligne et hors ligne ;

— Lieu le plus proche : Aidez les utilisateurs à découvrir les endroits proches ;

— Système de notification : Permet aux utilisateurs de rester à jour avec des nouvelles modifications ;

— Sécurité et Disponibilité : Sécuriser et protéger la vie privée des utilisateurs. Système disponible
24h / 24 ;

— Interaction avec les réseaux sociaux afin de partager des publications.

2.5 Objectifs à atteindre

Les objectifs de notre solutions ne se restreignent pas uniquement au niveau de la richesse


des fonctionnalités qu’elle porte, elle en arrive à recouvrir d’autre apport technique comme suit :

— Fournir toutes les fonctionnalités nécessaires à l’institut d’enseignement,

— Rendre plus simple et plus efficace la gestion des activités,

— Gain de temps certain,

— Aide les parents à suivre leur enfant,

— Facilite et accélère le travail des employeurs et des enseignants,

21
Chapitre 2. Etude Préalable

— Avoir des tableau de bord avec des résultats et des statistique plus pertinents,

— Langage de programmation : Contrairement à d’autre produit existant dans le marché, le choix


du langage lui permet de bénéficier d’un code source flexible, maintenable et évolutif.

2.6 Choix de la méthodologie

Pour pouvoir choisir la bonne méthodologie, il faut avoir une idée sur les avantages et les
inconvénients de quelques-unes et savoir ainsi laquelle répond aux contraintes et aux exigences de
notre projet. Ci-dessous nous présentons un aperçu sur les différentes méthodologies.

2.6.1 Approche agile vs approche classique

Depuis toujours, les projets sont gérés avec des méthodologies classiques qui se caractérisent
par recueillir les besoins, définir le produit, le développer et le tester avant de le livrer. Ces méthodologies
sont appelées aussi les approche prédicative. En effet, comme son nom l’indique, il s’agit ici de prévoir
des phases séquentielles où il faut valider l’étape précédente pour passer à la suivante. On doit alors
s’engager sur un planning précis de réalisation du projet en prévoyant des jalons de débuts et fins
de phases ainsi que les tâches à effectuer.
De plus, elles sont axées principalement sur le périmètre du projet, son coût et sa planification.
Les méthodes Agiles quant à elles font des méthodes "classiques" une contrainte. Ainsi on voit le
coût, le périmètre et la planification comme des contraintes sur lesquelles on va se focaliser tout
en étudiant en parallèle la valeur ajoutée cliente et la qualité du produit livre. On ne choisit pas
directement de livrer un projet, on s’assure d’apporter la valeur cliente nécessaire avec un produit
de qualité en optimisant nos coûts, notre temps et surtout les risques liés au projet. Le client obtient
donc une place importante au sein d’une organisation Agile. Son avis est compté et respecté. Les
protagonistes (internes et externes) doivent accepter l’apprentissage et doivent être préparés au
changement) [15].
Brièvement, les méthodologies agiles sont basées sur 4 valeurs clé qui les différencient des
approches classiques :

• L’interaction avec les personnes plutôt que les processus et les outils,

• Un produit opérationnel plutôt qu’une documentation pléthorique,

• La collaboration avec le client plutôt que la négociation de contrat,

• La réactivité face au changement plutôt que le suivi d’un plan.

22
Chapitre 2. Etude Préalable

La figure 2.4 présente une Comparaison entre méthode "classique" et méthode Agile

Figure 2.4: Méthodologie agile vs. Classique [16]

Par conséquent, on a choisi d’adopter une méthodologie agile car elle définit un cadre moins
rigide que les méthodes traditionnelles et elle est plus pragmatique que ces derniers de sorte qu’elle
assure la satisfaction du client en facilitant la gestion du projet, améliorant la qualité de développement
et s’adaptant mieux aux imprévus du projet.

2.6.2 Choix de la méthodologie Scrum

Scrum [17] est une méthode agile qui vise à satisfaire au mieux les besoins du client tout en
maximisant les probabilités de réussite du projet. Elle suppose que le développement d’un logiciel
n’est pas prévisible et ne peut donc pas suivre de processus défini. Ainsi, le résultat du projet n’est
pas connu au départ, il dépend des réorientations que lui donne le client en cours de route.(Voir
Annexe 1)
Comme le client classe lui-même les fonctionnalités par ordre d’importance, il est certain
d’obtenir un logiciel à forte valeur ajoutée en fin de projet.
La figure 2.5 montre de quoi se compose SCRUM
Le principe de base de Scrum est de se focaliser de façon régulière sur un ensemble de
fonctionnalités à réaliser appelées Sprints. Chaque Sprin possède des buts à atteindre à partir

23
Chapitre 2. Etude Préalable

Figure 2.5: Méthode SCRUM [18]

desquels sont choisies les fonctionnalités à implémenter. Ces fonctionnalités sont définies sous forme
d’User Story. Un sprint aboutit toujours sur la livraison d’un produit partiellement fonctionnel.
Justification du choix
Le choix de la méthodologie Scrum fournit plusieurs avantages pour les clients :

• La méthodologie scrum fournit au client de tester l’application des que le développeur finit la
premier partie de chaque sprint. Ainsi garantie le travail concret avec le client. Nous minimisons
les problèmes de compréhension de la conception. En plus le client peut ajouter ou modifier
des fonctionnalités au début ou à la fin de chaque sprint,

• Scrum assure une qualité de produit grâce à la transparence du processus nous pouvons
visualiser des lacunes d’un livrable et l’amélioration se fera dès le prochain livrable.

Conclusion

Tout au long de ce chapitre, nous avons présenté l’organisme d’accueil «716Solutions» puis
nous avons fait une étude de l’existant pour mettre en valeur notre solution.Face à ces problèmes
nous avons proposé de concevoir et développer notre système en adoptant la méthodologie Scrum
Nous passons par la suite au Sprint0 où nous allons présenter notre produit backlog qui va
nous servir à bien spécifier et analyser nos exigences.

24
Chapitre 3

Sprint 0

Plan
1 Plan d’action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 35

4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapitre 3. Sprint 0

Introduction

Dans ce chapitre, nous allons tout d’abord, présenter le backlog du produit qui regroupe
toutes les exigences à réaliser par notre système. Ensuite, nous allons passer à la phase d’analyse de
la solution et la détermination des besoins fonctionnels et non fonctionnels. Enfin, nous décrivons la
spécification du diagramme de cas d’utilisation général ainsi que l’environnement de développement.

3.1 Plan d’action

3.1.1 Backlog Produit

Le backlog de produit est la liste des fonctionnalités attendues par notre application. Il
contient toutes les tâches qui seront développées par l’équipe. Elles y sont classées par priorité ce
qui permet de définir l’ordre de réalisation. Les tâches ainsi que ces priorités sont dégagées suite à
des réunions avec le client et le chef de projet.
Le backlog de produit permet de produire le plan de chaque sprint qui contient les différentes
fonctionnalités qu’on estime finir à la date précisée pour le sprint.
L’effort indique l’estimation de la complexité technique d’une histoire utilisateur sur une
échelle de valeur relative.Dans notre cas on a utilisé cette échelle.
La figure 3.1 montre l’échelle de complexité utilisée

Figure 3.1: Echelle de complexité utilisée

Le produit Backlog de notre application se présente comme le suit :

Tableau 3.1: Produit Backlog de notre application

ID User Story Priority Estimation

1 En tant que Responsable,je peux gérer les événements. 8 3 jours

2 En tant que Responsable,je peux consulter la liste des 4 1 jours


événements.

26
Chapitre 3. Sprint 0

3 En tant que Responsable,je peux consulter les détails d’un 4 1 jours


événements.

4 En tant que Responsable,je peux chercher un événement. 4 4 heures

5 En tant que Responsable,je peux participer à un événement 8 2 jours


gratuit.

6 En tant que Responsable,je peux Envoyer une demande de 9 1 jour


participation à un événement payant.

7 En tant que Responsable,je peux annuler ma demande de 7 1 jour


participation à un événement.

8 En tant que Responsable,je peux consulter les demandes de 7 1 jour


participation à un événement.

9 En tant que Responsable,je peux traiter une demande de 8 1 jour


participation.

10 En tant que élève,je peux consulter la liste des événements. 4 2 jours

11 En tant que élève,je peux consulter les détails d’un 8 2 jours


événements.

12 En tant que élève,je peux chercher un événement. 4 4 heures

13 En tant que élève,je peux participer à un événement gratuit. 9 1 jour

14 En tant que élève,je peux Envoyer une demande de 10 1 jour


participation à un événement payant.

15 En tant que élève,je peux annuler ma demande de 7 1 jour


participation à un événement.

16 En tant que élève,je peux consulter mes demandes de 9 1 jour


participation à un événement.

17 En tant que Responsable,je peux consulter la liste des 9 1 jour


demandes d’admission.

18 En tant que Responsable,je peux gérer les demandes 9 1 jour


d’admission.

19 En tant que Responsable,je peux consulter les détails des 9 1 jour


demandes d’admission.

27
Chapitre 3. Sprint 0

20 En tant que Responsable,je peux ajouter une demandes 9 1 jour


d’admission.

21 En tant que Responsable,je peux Traiter les demandes 9 1 jour


d’admission.

22 En tant que Responsable,je peux accepter une demandes 9 1 jour


d’admission.

23 En tant que Responsable,je peux réfuser une demandes 9 1 jour


d’admission.

24 En tant que Responsable,je peux configurer les informations 9 1 jour


de module admission

25 En tant que Responsable,je peux consulter les listes des 9 1 jour


élèves

26 En tant que Responsable,je peux configurer les informations 9 1 jour


de l’école.

27 En tant que Responsable,je peux chercher un élève par 9 1 jour


nom,par genre..

28 En tant que Responsable,je peux consulter les détails d’un 9 1 jour


élève.

29 En tant que Responsable,je peux générer la carte d’élève. 9 1 jour

30 En tant que parent,je peux soumettre une demande 9 1 jour


d’admission.

31 En tant que parent,je peux consulter mon profil 9 1 jour

32 En tant que parent,je peux modifier mes informations. 9 1 jour

33 En tant que Responsable,je peux configurer les informations 9 1 jour


du services de transport.

34 En tant que Responsable,je peux consulter la liste des 9 1 jour


abonnements au service de transport.

35 En tant que Responsable,je peux gérer les abonnements. 9 1 jour

36 En tant que Responsable,je peux consulter les détails d’un 9 1 jour


abonnement

28
Chapitre 3. Sprint 0

37 En tant que Responsable,je peux modifier les détails d’un 9 1 jour


abonnement.

38 En tant que Responsable,je peux générer les rapports du 9 1 jour


services de transport

39 En tant que parent ,je peux consulter les circuits disponibles 9 1 jour

40 En tant que parent ,je peux m’abonner au service de 9 1 jour


transport

41 En tant que élève ,je peux consulter les services à proximité 9 1 jour

42 En tant que élève ,sélectionner le types de service à proximité 9 1 jour

43 En tant que parent ,je peux localiser mon fils à tout moment. 9 1 jour

44 En tant que parent ,je peux ajouter et localiser tous mes 9 2 jour
enfants.

45 En tant que parent ,je peux suivre l’état de ma demande 9 1 jour


d’admission

3.1.2 Planification des sprints

Suite à la définition du backlog de produit nous avons élaboré la plannification des sprints
selon l’ordre logique de dévelopement.
Ce projet est décomposé en quatre sprints chaque module doit être réalisé dans un sprint :
Le tableau 6.1 présente les quatre sprints et leurs Durée d’exécution

Tableau 3.2: Les quatre sprints et leurs Durée d’exécution

Itérations Titre Durée en jours

Sprint 1 Module O’School Evènements 30 jours

Sprint 2 Module O’School Admission 30 jours

Sprint 3 Module O’School Transport 30 jours

Sprint 4 Application Mobile 30 jours

29
Chapitre 3. Sprint 0

3.2 Spécification des besoins

La spécifications des besoins comprend la détermination des besoins fonctionnels,les besoins


non fonctionnels et l’identification des acteurs.

3.2.1 Identification des acteurs et des fonctionnalités

Dans ce qui suit,nous allons présenter les différents acteurs interagissant avec notre système.En
en effet,un acteur peut consulter et ou modifier directement l’état du système, en émettant ou en
recevant des messages éventuellement porteurs de données.
Les principaux acteurs du notre système projeté ainsi que ses rôles sont présentés dans le
tableau 3.3 suivant :

30
Chapitre 3. Sprint 0

Tableau 3.3: Les différents acteurs interagissant avec notre système

Acteurs Fonctionnalités Modules

Responsable et Éleve Module O’School Événement

— Gestion des évènements et


leurs détails

— Traitement des demandes de


participation aux évènement

— Envoi et suivi d’une demande


de participation

— Consultation des évènements

Responsable et Parent Module O’School Admission

— Traitement des demandes


d’admission des élèves

— Envoi et suivie d’une demande


d’admission

Responsable et Parent Module O’School Transport

— Gestion des bus et liste des


zones et circuits

— Gestion des demandes


d’abonnements

— Envoi et suivie d’une


demandes d’abonnement

3.2.2 Exigences non-fonctionnelles

En plus des besoins fonctionnels explicités, le produit livré à la fin de chaque sprint doit
pouvoir assurer les exigences non fonctionnelles suivantes :

31
Chapitre 3. Sprint 0

• Intégrité : une partie essentielle de n’importe quelle application est de s’assurer que toutes les
opérations effectuées sont exécutées correctement,

• Ergonomie et simplicité : il faut prendre en considération tous les types des utilisateurs pour
cette raison notre application doit être simple à manipuler contenant les données nécessaires
pour effectuer une opération,

• Sécurité : Elle est assurée par un système d’authentification et d’autorisation pour protéger les
données personnelles (pour plus de détails voir Annexe 4),

• Performance et efficacité : Contenir un minimum d’erreurs, satisfaire les spécifications et


remplir ses missions, permette d’effectuer les opérations rapidement et de manière efficace
pour gagner du temps,

• Testabilité : Faciliter les procédures de test permettant de s’assurer de l’adéquation des fonctionnalités.

3.2.3 Diagramme cas d’utilisation général

Le diagramme de cas d’utilisation suivant permet de synthétiser les spécifications générales


de notre application ainsi que les fonctionnalités de chaque utilisateur de système.
La figure 3.2 présente diagramme de cas d’utilisation global de la partie système

32
Chapitre 3. Sprint 0

Figure 3.2: Diagramme cas d’utilisation global de la partie systéme

33
Chapitre 3. Sprint 0

La figure 3.3 présente diagramme de cas d’utilisation global de la partie Mobile

Figure 3.3: Diagramme cas d’utilisation global de la partie Mobile

34
Chapitre 3. Sprint 0

3.3 Environnement de développement

L’analyse des besoins techniques couvre la spécification des technologies à utiliser ainsi que
la structure applicative pour donner une vision globale sur l’architecture de notre projet
Avant de se lancer dans la conception et l’implémentation de notre projet nous allons décrire
l’environnement et les outils du travail. On va commencer par définir l’environnement matériel puis
on passe à celui logiciel qui est bien riche.

3.3.1 Environnement Matériel

Concernant la partie matérielle, il faut utiliser un matériel performant au niveau processeur


et mémoire pour gagner au niveau du temps de réponse de l’exécution de l’application. Ainsi
notre environnement matériel est constitué par un ordinateur portable et un Smartphone ayant
les caractéristiques suivantes :
Le tableau 3.4 présente l’environnement matériel

Tableau 3.4: Environnement matériel

PC ASUS — Disque dur : 1TB

— Processeur : Intel i7

— CPU : 3.0 GHz

— RAM 8 Go

— Système d’exploitation : Windows 10

Smartphone — Mémoire RAM : 2GO


EverTeK
— Mémoire ROM : 16GO

— Système d’exploitation : Google Android 6.0 (lollipop)

— CPU : Processeur Quatrecoeurs 1GHZ

3.3.2 Environnement Logiciel

Le tableau 3.5 présente l’environnement de développement

35
Chapitre 3. Sprint 0

Tableau 3.5: Environnement de développement

Logiciel Description

Afin de modéliser notre travail en langage UML, nous


avons utilisé un logiciel complet de modélisation intitulé
Power AMC dans sa version 15.1. C’est un outil tout-en-un
de modélisation d’entreprise et de gestion de métadonnées
destiné à documenter l’architecture d’entreprise[19]

Nous avons utilisé PostgeSQL dans sa version 9.3 comme


système de gestion de base de données relationnel objet
(SGBDRO)[20]
PostgreSQL peut stocker plus de types de données que les
types traditionnels : entiers,caractères...

Eclipse neon est une nouvelle version d’Eclipse, elle est


un Environnement de développement libre permettant
potentiellement de créer des projets de développement
mettant en oeuvre n’importe quel langage de programmation
(Java, C++, PHP, Python). [21]

Android Studio est un environnement de développement


dédié au développement des applications mobile (Android).
Le 8 décembre 2014, Android Studio passe de version
bêta à version stable 1.0. L’environnement devient alors
conseillé par Google, et Eclipse est délaissé. Android Studio,
maintenant, est à sa version 2.2.1. Android Studio permet
principalement d’éditer les fichiers Java et les fichiers de
configuration d’une application Android[22]

36
Chapitre 3. Sprint 0

Firebase est une API qui permet de stocker des données dans
le cloud. L’avantage se situe dans le fait que ses données sont
accessibles facilement et sont synchronisées en temps réel sur
tous les appareils connectés.
Le service firebase se charge d’héberger les données que
vous allez lui confier sous forme d’un objet JSON. Tout
l’intérêt de la solution est le côté temps réel. Par exemple, si
une donnée est ajoutée ou mise à jour, les autres appareils
connectés recevront ses données instantanément. [23]

Rapid PHP est conçu pour modifier rapidement les codes


sources des pages web. Il met à disposition de nombreux
outils qui permettent de faciliter l’édition. [24]

3.3.3 Langage de développement

Tableau 3.6: Environnement de développement

Logiciel Description

Le Framework d’Odoo utilise le langage Python (version


2.7) ; plus précisément, il impose que les modules soient écrits
en Python et il est lui-même codé en Python.
Python est un langage de programmation libre et orienté
objet, qui est connu pour être lisible et facile à utiliser pour
le développeur. Il est livré avec un débugger intégré, qui
permet de travailler efficacement sur les bug[25]

Est un pack d’outils pour le développement d’application


via le langage Java. Il a les composants nécessaires à la
conception et au test de projets avec diverses caractéristiques
[26].

37
Chapitre 3. Sprint 0

Odoo utilise XML pour la description des données, la


description des interfaces, la description des rapports et
la description des workflow. XML (eXtensible Markup
Language et en Français Langage à balises étendu, ou
Langage à balises extensible) est un langage simple
et puissant de description et d’échange de documents
structurés de n’importe quel domaine de données grâce à son
extensibilité, il décrit cette structure à l’aide d’un système
de balises[27]

3.4 Architecture de l’application

L’application doit nécessairement pouvoir communiquer entre eux. Ainsi le travail sera divisé
en trois parties :
Un site web qui représente la partie descriptive de projet ainsi la pré inscription en ligne.
Une application mobile qui s’exécute sur le téléphone portable Android et qui permet la
connexion au serveur de base de données avec d’autres fonctionnalités.
Une application Odoo où se trouve les différentes modules composant notre système.
La figure 3.4 présente l’architecture globale de la solution

38
Chapitre 3. Sprint 0

Figure 3.4: Architecture globale de la solution

Odoo adopte le modèle MVC avec une séparation stricte entre le modèle de données, la vue
et les traitements, alors on peut appliquer cette sémantique de Model-View-Controller avec :

• Modèle : les modèles sont les objets déclarés dans Odoo. Ils sont également des tables
PostgreSQL,

• Vue : les vues sont définies en fichiers XML dans Odoo,

• Sécurité : Elle est assurée par un système d’authentification et d’autorisation pour protéger les
données personnelles,

• Contrôleur : le contrôleur est Python qui contrôle Odoo.

L’avantage majeur apporté par ce modèle est la clarté de l’architecture qu’il impose, ce qui
simplifie la tâche pour les développeurs souhaitant effectuer une maintenance ou une prochaine
amélioration sur le projet.
Autres avantages offerts par ce modèle, il permet de profiter d’une grande robustesse ainsi
que la possibilité de réutiliser le code aussi souvent que nécessaire.
L’avantage essentiel d’un tel découpage est de séparer les objets graphiques des objets métier,
afin de pouvoir les faire évoluer indépendamment et les réutiliser[28]. Cela apporte également un
gain de temps en cas de besoin de maintenance de l’application

39
Chapitre 3. Sprint 0

Conclusion

A la fin de cette phase, nous avons effectué une présentation en clair de nos besoins et de la
solution proposée. En premier lieu nous avons identifié le plan d’action. Ensuite, nous avons présenté
la spécification des besoins ainsi que la conception générale.Enfin, nous avons exposé l’environnement
matériel et logiciel de notre projet. Dans le chapitre suivant nous allons passer à la description des
étapes de réalisation du premier sprint de notre projet.

40
Chapitre 4

Sprint 1 : Module O’School


Évènement

Plan
1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Chapitre 4. Sprint 1 : Module O’School Évènement

Introduction

Dans ce chapitre nous avons choisi d’entamer le sprint 1 , notre premier module intitulé
O’School Événement. Donc nous avons présenté les deux phases de conception et de réalisation vu
que nous avons choisi comme méthodologie celle SCRUM agile dont le principe est de faire les deux
étapes pour chaque itération du projet.

4.1 Sprint backlog

Le Sprint Backlog de Sprint 1 : Module Évènement présente comme le suit :

Tableau 4.1: Produit Backlog de Module Évènement

ID User Story Priority Estimation

1 En tant que Responsable,je peux gérer les événements. 8 3 jours

1) Ajouter un événement

a. Creer la vue (formuaire) de l’ajout ;

b. Creer l’entité "Event" ;

c. Ajouter une action sur le bouton d’ajout ;

d. Stocker les informations dans la base de données.

2) Modifier un événement

a. Creer le bouton de modification d’un événement ;

b. Ajouter une action sur le bouton de modification


d’un événement ;

c. Modifier les informations de l’événement ;

d. Sauvegarder les modifications dans la base de


données.

3) Annuler un événement

a. Creer le bouton d’annulation de l’événement


b. Ajouter l’action sur le bouton d’annulation

42
Chapitre 4. Sprint 1 : Module O’School Évènement

2 En tant que responsable je peux consulter liste d’événement 4 1 jour

a. Création de l’interface

b. Récupérer les données à partir de la base de données

c. Implémentation des données avec l’interface

3 En tant que responsable je peux consulter les détailes d’un 4 1 jour


événement

a. Création de l’interface

b. Récupérer les données de l’événement sélectionner

c. Récupérer les données à partir de la base de données

d. Implémentation des données avec l’interface

4 En tant que responsable je peux chercher un event par titre 4 4 heures

a. Création le champ de recherche

b. Creer l’action de recherche

c. Associer l’action au champ

5 En tant que responsable je peux participer à un événement 8 2 jours


gratuit

a. Créer le bouton de participation à un événement


gratuit

b. Creer l’action de participation

c. Associer l’action avec le bouton

d. Sauvegarder les informations dans la base de données

43
Chapitre 4. Sprint 1 : Module O’School Évènement

6 En tant que responsable je peux participer à un événement 9 1 jour


payant

a. Créer le bouton de participation à un événement


gratuit

b. Creer l’action de participation

c. Associer l’action avec le bouton

d. Sauvegarder les informations dans la base de données

7 En tant que responsable je peux annuler ma participation à 7 1 jour


un événement

a. Créer le bouton d’annulation d’un événement

b. Creer l’action pour annuler un événement

c. Associer l’action avec le bouton

d. Sauvegarder les informations dans la base de données

8 En tant que responsable je peux consulter les demandes de 7 1 jour


participation à un événement

a. Créer les vues de participation à un événement

b. Creer l’entité "registration"

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

44
Chapitre 4. Sprint 1 : Module O’School Évènement

9 En tant que responsable je peux traiter les demandes de 8 1 jour


participation à un événement

a. Créer les boutons de validation ou de refus d’une


demande de participation à un événement

b. Creer les deux actions de validation et de refus

c. Associer actions aux boutons

d. Modifier l’état de la demande de participation

10 En tant que élève,je peux consulter la liste des événements 4 2 jours

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

11 En tant que élève,je peux consulter les détails d’un 8 2 jours


événements.

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

12 En tant que élève,je peux chercher un événement. 4 4 heures

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

45
Chapitre 4. Sprint 1 : Module O’School Évènement

13 En tant que élève,je peux participer à un événement gratuit 9 1 jour

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

14 En tant que élève,je peux soumettre une demande 10 1 jour


departicipation à un événement payant

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

15 En tant que élève,je peux annuler ma demande 7 1 jour


departicipation à un événement

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

16 En tant que élève,je peux consulter mes demandes 9 1 jour


departicipation à un événement.

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

46
Chapitre 4. Sprint 1 : Module O’School Évènement

4.2 Analyse

4.2.1 User Story de sprint 1 : Module Évènement

Dans ce qui suit,nous allons détailler les users story de module évènement en présentant ses
descriptions textuelles ainsi que les diagrammes de séquence et quelques imprimes écran réalisés.

4.2.2 Raffinement des cas d’utilisations

Vu que notre sprint est très riche et qu’il a des fonctionnalités importantes et obligatoires
nous avons présenté, par détail Les différents cas d’utilisation.
Diagramme cas d’utilisation « gérer les événements »
La figure 4.1 présente le diagramme de cas d’utilisation « gérer les événements »

Figure 4.1: Diagramme de cas d’utilisation « Gérer événements »

47
Chapitre 4. Sprint 1 : Module O’School Évènement

La figure 4.2 shématise la déroulement du cas d’utilisation « Ajouter un événement ».


Aprés s’authentifier le responsable peut ajouter un événement.Il remplit le formulaire en suivant
les étapes. Le systéme controle les données et affiche en cas de détection d’une information erronée
une notification précisant le champ incorrecte. Dans le cas ou les données sont persistés avec succés,le
reponsable peut modifier ou supprimer un événement selon l’action demandée.

Figure 4.2: Diagramme de séquence « Ajouter événements »

48
Chapitre 4. Sprint 1 : Module O’School Évènement

Le tableau 4.2 présente la desciption textuelle de cas d’utilisation « Consulter liste des
événements»

Tableau 4.2: Consulter liste des événements

Titre Consulter liste des événements

Acteurs Responsable,Elève

Partie prenante Ce cas d’utilisation permet de Consulter liste des événements


et intéret disponibles

Pré Condition Le responsable et l’élève doivent être authentifié pour


consulter liste des événements.

Post Condition Lister les événements disponibles

Scénario
principal 1) Le responsable accéde à l’interface de O’school
événement ;

2) Le systéme affiche la liste des événements existent.

Scénario Informer le responsable ou bien l’élève s’il n’y a aucune


alternatif événement.

Scénario Erreur de connexion


d’exception

Diagramme cas d’utilisation «Consulter liste des demandes de participation aux


événements »
La figure 4.3 présente le diagramme de cas d’utilisation « Consulter liste des demandes de
participation aux événements »

49
Chapitre 4. Sprint 1 : Module O’School Évènement

Figure 4.3: Diagramme de cas d’utilisation « Consulter liste des demandes de participation aux
événements»

Le tableau 4.3 présente la desciption textuelle de cas d’utilisation «Consulter liste des demandes
de participations»

Tableau 4.3: Consulter liste des demandes de participations

Titre Consulter liste des demandes de participations

Acteurs Responsable

Partie prenante Ce cas d’utilisation permet de Consulter liste des demandes


et intéret de participations

Pré Condition Le responsable doit être authentifié pour Consulter liste des
demandes de participations.

Post Condition Lister les demandes de participation aux événements.

Scénario
principal 1) Le responsable accéde à l’interface de O’school
événement ;

2) Le systéme affiche la liste des demande de participation


aux événements existent.

Scénario Informer le responsable q’il n’y a aucune demande de


alternatif participation à un événement

Scénario Erreur de connexion


d’exception

50
Chapitre 4. Sprint 1 : Module O’School Évènement

4.3 Conception

4.3.1 Diagramme de classe partiel

Avant de se lancer dans la programmation de ce Sprint, nous réfléchissons aux différents


concepts qui y sont exprimés pour en déduire l’architecture des classes que nous aurons besoin de
créer. On aura ce diagramme de classe.
La figure 4.4 présente le diagramme de classe sprint 1

Figure 4.4: Diagramme de classe sprint 1

51
Chapitre 4. Sprint 1 : Module O’School Évènement

4.3.2 Diagrammes de séquence

Consulter liste des événements


Ce diagramme montre la séquence des interactions qui se produisent lorsque l’élève (ou le
reponsbale) veut consulter la liste des événements
La figure 4.5 présente le diagramme de séquence d’objets « Consulter liste des événements »

Figure 4.5: Diagramme de séquence « Consulter liste des événements »

4.4 Réalisation

Dans cette partie nous allons présenter les différentes interfaces et les fonctionnalités de notre
module O-School Evénement ainsi que les tâches effectuées par chaque utilisateur selon son rôle.

4.4.1 Intefaces O’School Evénement sous Odoo

Interface d’authentification
La figure 4.6 montre l’interface d’authentification, à partir de cette fenêtre, l’utilisateur peut
se connecter à notre application en tant que : Administrateur, Elève,Parent. Selon l’utilisateur
connecté notre application fait la redirection au menu de l’utilisateur connecté.

52
Chapitre 4. Sprint 1 : Module O’School Évènement

Figure 4.6: Page d’accueil et d’authentification

Interface des événements disponible


La figure 4.7 montre la liste des événements disponible, à partir de cette fenêtre, l’utilisateur
peut lister les événements disponible en tant que : responsable,l’élève et parent.

53
Chapitre 4. Sprint 1 : Module O’School Évènement

Figure 4.7: Liste des événements

Consulter liste des demandes de participations à un événement


La figure 4.8 présente la liste ddes demandes de participations à un événement, à partir de
cette fenêtre, le responsable peut lister les demandes comme il peut les gérer(Accepter ou refuser)

Figure 4.8: Liste des demandes de participations à un événement

Ajouter un événement
La figure 4.9 présente la formulaire d’ajout d’un événement. Seul ,le responsable peut ajouter
un événement comme il peut le modifier

54
Chapitre 4. Sprint 1 : Module O’School Évènement

Figure 4.9: Ajouter un événement

Vue du calendrier des événements disponible


La figure 4.10 présente la Vue du calendrier des événements disponible.

Figure 4.10: Vue du calendrier des événements disponible

55
Chapitre 4. Sprint 1 : Module O’School Évènement

4.4.2 Intefaces O’School Evénement sous Android

La figure 4.12 présente les interfaces de consulatation des événements disponibles ainsi que
leurs détails

Liste des événements Détail d’un événement


Figure 4.12: Consulatation des événements disponibles ainsi que leurs détails

La figure 4.14 présente les interfaces de mes participations ainsi que leurs détails

56
Chapitre 4. Sprint 1 : Module O’School Évènement

Liste de mes événements Détail d’un événement


Figure 4.14: Consulatation de mes participations ainsi que leurs détails

Conclusion

L’enchaînement développé dans ce sprint permet d’assurer le service O’School Évènement.La


livraison n’a pas respecté la date fixée à cause des interfaces qui ont été bien soignées et raffinées.
Après avoir terminé le premier sprint en implémentant toutes les exigences demandées, nous pouvons
poursuivre notre travail et passer au sprint 2 qui fait l’objet du chapitre suivant.

57
Chapitre 5

Sprint 2 : Module O’School


Admission

Plan
1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Chapitre 5. Sprint 2 : Module O’School Admission

Introduction

Ce chapitre a pour objectif d’exposer la deuxième itération de notre projet,module O’School


Admission. Pour ce faire, nous commençons par la description et l’analyse des exigences ce qui
permet de bien préparer le terrain pour la phase de conception. Enfin, nous clôturons ce chapitre
par la présentation des quelques interfaces.

5.1 Sprint backlog

Le Sprint Backlog de Sprint 2 : Module Admission se présente comme le suit :

Tableau 5.1: Produit Backlog de Module Admission

ID User Story Priority Estimation

1 En tant que Responsable,je peux configurer les informations 10 6jours


basiques de l’admission

1) Configurer les informations basiques de l’année


universitaire

a. Creer la vue (formuaire) de l’ajout ;

b. Creer l’entité année universitaire ;

c. Ajouter une action sur le bouton d’ajout ;

d. Stocker les informations dans la base de données.

2) Configurer les informations basiques de l’école

a. Creer la vue (formuaire) de l’ajout ;

b. Creer l’entité école ;

c. Ajouter une action sur le bouton d’ajout ;

d. Stocker les informations de l’école dans la base de


données.

59
Chapitre 5. Sprint 2 : Module O’School Admission

2 En tant que responsable je peux consulter liste de demande 4 1 jour


d’admission

a. Création de l’interface

b. Récupérer les données à partir de la base de données

c. Implémentation des données avec l’interface

3 En tant que responsable je peux Traiter une demande 4 1 jour


d’admission

a. Créer les boutons de validation ou de refus d’une


demande d’admission

b. Creer les deux actions de validation et de refus

c. Associer actions aux boutons

d. Modifier l’état de la demande d’admission

4 En tant que responsable je peux Ajouter une demande 4 1 jour


d’admission

a. Creer la vue (formuaire) de l’ajout ;

b. Creer l’entité "school" ;

c. Ajouter une action sur le bouton d’ajout ;

d. Stocker les informations dans la base de données.

5 En tant que responsable je peux consulter les liste des élèves 8 2 jours

a. Création de l’interface

b. Récupérer les données à partir de la base de données

c. Implémentation des données avec l’interface.

60
Chapitre 5. Sprint 2 : Module O’School Admission

6 En tant que responsable je peux chercher un élève 9 1 jour

a. Création le champ de recherche

b. Creer l’action de recherche

c. Associer l’action au champ

7 En tant que Responsable,je peux consulter les détails des 7 1 jour


demandes d’admission

a. Création de l’interface

b. Récupérer les données à partir de la base de données

c. Implémentation des données avec l’interface.

8 En tant que responsable je peux générer la carte d’élève 7 1 jour

a. Créer template de carte d’élève

b. Associer les champs à imprimer au template (carte


d’élève)

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

9 En tant que Responsable,je peux consulter les détails des 8 1 jour


demandes d’admission

a. Création de l’interface

b. Récupérer les données de la demande sélectionner

c. Ajouter le bouton d’annulation de l’événement

d. Implémentation des données avec l’interface

61
Chapitre 5. Sprint 2 : Module O’School Admission

10 En tant que Responsable,je peux consulter les détails d’un 8 1 jour


élève.

a. Création de l’interface

b. Récupérer les données de l’élève sélectionner

c. Récupérer les données à partir de la base de données

d. Implémentation des données avec l’interface

11 En tant que parent je peux soumettre une demande 8 1 jour


d’admission

a. Créer la formulaire d’admission

b. Creer l’action de demande d’admission

c. Associer actions au formulaire

d. Sauvegarder les informations dans la base de données

12 En tant que parent,je peux consulter Mon profile 4 1 jour

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

13 En tant que parent ,je peux modifier mes informations 8 2 jours

a. Créer les interfaces

b. Implémentation du modéle de données

c. Récupérer les données de la base de données

d. Implémentation des données avec l’interface

62
Chapitre 5. Sprint 2 : Module O’School Admission

5.2 Analyse

5.2.1 User Story de sprint 2 : Module Admission

Dans ce qui suit,nous allons détailler les users story de module admission en présentant ses
descriptions textuelles ainsi que les diagrammes de séquence et quelques imprimes écran réalisés.

5.2.2 Raffinement des cas d’utilisations

Vu que notre sprint est très riche et qu’il a des tâches importantes et obligatoires on va
présenter, par détail Les différents cas d’utilisation.
Consulter liste des demandes d’admission
La figure 5.1 présente le diagramme cas d’utilisation « Consulter liste des demandes d’admission
»

Figure 5.1: Diagramme de cas d’utilisation Consulter liste des demandes d’admission

La figure 5.2 présente la déroulement du cas d’utilisation « Consulter liste des demandes
d’admission »
Aprés s’authentifier le responsable peut conulter la liste des demandes d’admission

63
Chapitre 5. Sprint 2 : Module O’School Admission

Figure 5.2: Diagramme de séquence « Consulter liste des demandes d’admission »

Consulter liste des élèves


La figure 5.3 présente le diagramme cas d’utilisation « Consulter liste des élèves »

Figure 5.3: Diagramme de cas d’utilisation Consulter liste des élèves

64
Chapitre 5. Sprint 2 : Module O’School Admission

La figure 5.4 présente la déroulement du cas d’utilisation «Générer la carte d’élève »


Aprés s’authentifier le responsable peut conulter la liste des élève ensuite peut générer les
cartes d’élève

Figure 5.4: Diagramme de séquence « Générer la carte d’élève»

Le tableau 5.2 présente la desciption textuelle de cas d’utilisation «Accepter demande d’admission»

65
Chapitre 5. Sprint 2 : Module O’School Admission

Tableau 5.2: Accepter demande d’admission

Titre Accepter demande d’admission

Acteurs Responsable

Partie prenante Ce cas d’utilisation permet d’accepter une demande


et intérêt d’admission.

Pré Condition Le responsable doit être authentifié pour accepter une


demande d’admission.

Post Condition Lister les demandes d’admission ; Consulter les détailles


d’une demande.

Scénario
principal 1) Le responsable accède à l’interface de O’school
admission,

2) Le système affiche la liste des demande de participation


aux événements existent,

3) Le responsable consulter les détailles d’un événement


sélectionner,

4) Le système affiche les détailles d’une demande,

5) Le responsable choisi l’action " Accepter ",

6) Le système valide l’action,

7) Le système lister le demande avec avec état


"Accepter".

Scénario Informer le responsable q’il n’y a aucune demande


alternatif d’admission avec une liste vide.

Scénario Erreur de connexion


d’exception

66
Chapitre 5. Sprint 2 : Module O’School Admission

5.3 Conception

Après avoir fini notre spécification et analyse des besoins et avant de passer à l’implémentation
de cette itération .Nous allons concevoir les exigences à réaliser.

5.3.1 Diagramme de classe partiel

La figure 5.5 présente le diagramme de classe de sprint 2 : O’School Admission

67
Chapitre 5. Sprint 2 : Module O’School Admission

Figure 5.5: Diagramme de classe de sprint 2

68
Chapitre 5. Sprint 2 : Module O’School Admission

5.3.2 Diagrammes de séquence

La figure 5.6 présente le diagramme de séquence «Traiter demandes d’admission »

Figure 5.6: Diagramme de séquence « Traiter demandes d’admission »

5.4 Réalisation

5.4.1 Interfaces O’School Admission sous Odoo

Interface de liste de demande d’admission


La figure 5.7 présente une vue Kanban d’un élève ayant un état confirmer.

69
Chapitre 5. Sprint 2 : Module O’School Admission

Figure 5.7: Liste des demandes d’admissions

Interface de traitement d’une demande d’admission


La figure 5.8 présente une vue Kanban d’un élève avec l’état confirmer

Figure 5.8: Traitement d’une demande d’admission

Carte élève
La figure 5.9 présente la carte d’élève

70
Chapitre 5. Sprint 2 : Module O’School Admission

Figure 5.9: Carte d’élève

5.4.2 Interfaces O’School Admission sous Android

La figure 5.11 présente les interfaces de consultation des demandes d’admissions ainsi que
leurs détails

71
Chapitre 5. Sprint 2 : Module O’School Admission

Liste de demande admission Détail d’une demande


Figure 5.11: Consultation demande d’admission ainsi que ainsi que leurs détails

72
Chapitre 5. Sprint 2 : Module O’School Admission

La figure 5.13 présente les interfaces de profil d’un élève.

Figure 5.13: Profil élève

Conclusion

Durant ce chapitre intitulé Sprint 2 : Module O’School Admission nous avons commencé par
définir notre ligne de travail grâce au Sprint Backlog. Ensuite, nous avons fait l’analyse détaillée de
ce dernier pour aboutir enfin à l’étude conceptuelle et la réalisation de cette itération. Après avoir
terminé le premier sprint en implémentant toutes les exigences demandées, nous pouvons poursuivre
notre travail et passer au sprint 3 qui fait l’objet du chapitre suivant.

73
Chapitre 6

Sprint 3 : Module O’School


Transport

Plan
1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Chapitre 6. Sprint 3 : Module O’School Transport

Introduction

Au niveau de ce chapitre nous allons passer à la troisième itération de notre solution. Pour ce
faire, nous commençons par la description et l’analyse des exigences ce qui permet de bien préparer
le terrain pour la phase de conception. Enfin, nous clôturons ce chapitre par la présentation des
quelques interfaces.

6.1 Sprint backlog

Le Sprint Backlog de Sprint 3 : Module Transport se présente comme le suit :

75
Chapitre 6. Sprint 3 : Module O’School Transport

Tableau 6.1: Produit Backlog de Module Transport

ID User Story Priority Estimation

1 En tant que Responsable,je peux configurer les informations 8 5 jours


du services de transport.

1) Configurer la liste des chauffeurs

a. Implémentation du modèle de données ;

b. Creer l’interface ;

c. Implémentation des services CRUD ;

d. Stocker les informations dans la base de données.

2) Configurer la liste des véhicules

a. Implémentation du modèle de données ;

b. Creer l’interface ;

c. Implémentation des services CRUD ;

d. Stocker les informations dans la base de données.

3) Génerer les rapports du service du transport (Voir


Annexe 2 )

a. Créer le squelette de rapport (vue xml) ;

b. Associer les champs à imprimer au template ;

c. Récupérer les données de la base de données ;

d. Implémentation des données avec l’interface.

4) Configurer la liste des arrets

a. Implémentation du modèle de données ;

b. Creer l’interface ;

c. Implémentation des services CRUD ;

d. Stocker les informations dans la base de données.

76
Chapitre 6. Sprint 3 : Module O’School Transport

2 En tant que Responsable,je peux consulter la liste des 4 1 jour


abonnements au service de transport.

a. Création de l’interface

b. Récupérer les données à partir de la base de données

c. Implémentation des données avec l’interface

3 En tant que Responsable,je peux gérer les abonnements. 7 2 jours

a. Implémentation du modèle de données ;

b. Creer l’interface ;

c. Implémentation des services CRUD ;

4 En tant que Responsable,je peux consulter les détails d’un 5 2 jours


abonnement

a. Création de l’interface

b. Récupérer les données d’un abonnement sélectionner

c. Récupérer les données à partir de la base de données

d. Iplémentation des données avec l’interface

5 En tant que Responsable,je peux modifier les détails d’un 8 3 jours


abonnement.

a. Création de l’interface

b. Récupérer les données d’un abonnement sélectionner

c. Récupérer les données à partir de la base de données

d. Iplémentation des données avec l’interface

e. Sauvegarder les modifications dans la base de données

77
Chapitre 6. Sprint 3 : Module O’School Transport

6 En tant que parent ,je peux consulter les circuits disponibles 9 2 jours

a. Creer de l’interface ;

b. Implémentation du modèle de données ;

c. Récupérer les données à partir de la base de données ;

d. mplémentation des données avec l’interface.

7 En tant que parent ,je peux m’abonner au service de 6 5 jours


transport

a. Creer la vue (formuaire) de l’ajout ;

b. Creer le bouton de participation ;

c. Associer l’action avec le bouton

d. Sauvegarder les informations dans la base de données

6.2 Analyse

6.2.1 User Story de sprint 3 : O’School Transport

Dans ce qui suit,nous allons détailler les users story de module transport en présentant ses
descriptions textuelles ainsi que les diagrammes de séquence et quelques imprimes écran réalisés.

6.2.1.1 Raffinement des cas d’utilisations

Vu que notre sprint est très riche et qu’il a des tâches importantes et obligatoires on va
présenter, par détail Les différents cas d’utilisation.
Diagramme cas d’utilisation « paramétrer les informations du service transport
»
La figure 6.1 présente le diagramme cas d’utilisation « paramétrer les informations du service
du transport »

78
Chapitre 6. Sprint 3 : Module O’School Transport

Figure 6.1: Diagramme de cas d’utilisation «Paramétrer les informations du service du


transport»

Le tableau 6.2 présente la desciption textuelle de cas d’utilisation «paramétrer la liste des
chauffeurs»

Tableau 6.2: Paramétrer la liste des chauffeurs

Titre paramétrer la liste des chauffeurs

Acteurs Responsable

Partie prenante Ce cas d’utilisation permet de configurer la liste des


et intéret chauffeurs.

Pré Condition Le responsable doit être authentifié pour consulter la liste


des chauffeur et les gérer.

Post Condition Lister les chauffeurs disponibles

79
Chapitre 6. Sprint 3 : Module O’School Transport

Scénario
principal 1) Le responsable accède à l’interface de O’school
Transport,

2) Le responsable accède à l’interface de configuration de


O’school Transport,

3) Le système lister les chauffeurs disponibles,

4) Le responsable choisi l’action d’ajout ou de


modification,

5) Le système affiche une formulaire à remplir ,

6) Le responsable saisie les champs obligatoires


définissant la rubrique ,

7) Le responsable mettre à jour les données,

8) Le système valide le formulaire et enregistre les


données.

Scénario Le saisie est erronée ; Le scénario reprend au point 6 du


alternatif scénario principal

Scénario Erreur de connexion


d’exception

Diagramme cas d’utilisation «Gérer les abonnements au service du transport »


La figure 6.2 présente le diagramme cas d’utilisation «Gérer les abonnements au service du
transport »

80
Chapitre 6. Sprint 3 : Module O’School Transport

Figure 6.2: Diagramme de cas d’utilisation «Gérer les abonnements au service du transport»

Le tableau 6.3 présente la desciption textuelle de cas d’utilisation «Ajouter un abonnement»

Tableau 6.3: Ajouter un abonnement

Titre Ajouter un abonnement

Acteurs Responsable,Parent

Partie prenante Ce cas d’utilisation permet d’ajouter un abonnements aux


et intéret transport.

Pré Condition Le responsable ou le parent doit être authentifié pour ajouter


un abonnements aux transport.

Post Condition L’opération d’ajout est effectué avec succès

81
Chapitre 6. Sprint 3 : Module O’School Transport

Scénario
principal 1) Le responsable accéde à l’interface de O’school
Transport ;

2) Le système affiche liste des itineraires ;

3) Le responsable choisit le menu d’Inscription aux


Transports ;

4) Le système affiche une formulaire à remplir ;

5) Le responsable saisie les champs obligatoires


définissant la rubrique ;

6) Le système valide le formulaire et enregistre les


données.

Scénario Le saisie est erronée ; Le scénario reprend au point 4 du


alternatif scénario principal

Scénario Erreur de connexion


d’exception

La figure 6.3 schématise la déroulement du cas d’utilisation « Ajouter un itinéraire ». Après


authentifier le responsable peut ajouter un itinéraire.Il remplit le formulaire en suivant les étapes. Le
système contrôle les données et affiche en cas de détection d’une information erronée une notification
précisant le champ incorrecte. Dans le cas ou les données sont persistes avec succès,le responsable
peut modifier ou supprimer un itinéraire selon l’action demandée.

82
Chapitre 6. Sprint 3 : Module O’School Transport

Figure 6.3: Diagramme de séquence « Ajouter un itinéraire »

6.3 Conception

6.3.1 Diagramme de classe partiel

Avant de se lancer dans la programmation de ce Sprint, nous réfléchissons aux différents


concepts qui y sont exprimés pour en déduire l’architecture des classes que nous aurons besoin de
créer. On aura ce diagramme de classe.

83
Chapitre 6. Sprint 3 : Module O’School Transport

Figure 6.4: Diagramme de classe de Sprint 3 : Transport

6.3.2 Diagrammes de séquence

Consulter liste des itinéraire


Ce diagramme montre la séquence des interactions qui se produisent lorsque le responsable
veut consulter la liste des itinéraires
La figure 6.5 présente le diagramme de séquence « Consulter liste des itinéraires »

84
Chapitre 6. Sprint 3 : Module O’School Transport

Figure 6.5: Diagramme de séquence d’objets « Consulter liste des itinéraires » »

6.4 Réalisation

6.4.1 Interfaces O’School Transport sous odoo

Interface des Itinéraire disponible


La figure 6.6 montre la liste des Itinéraire disponible, à partir de cette fenêtre, l’utilisateur
peut lister les Itinéraires disponible en tant que : responsable et parent.

Figure 6.6: Liste des Itinéraires

Interface d’inscription aux Transports


La figure 6.7 montre la formulaire d’inscription aux Transports. l’utilisateur peut lister les
Itinéraires disponible en tant que : responsable et parent.

85
Chapitre 6. Sprint 3 : Module O’School Transport

Figure 6.7: Inscription aux Transports (Responsable)

Figure 6.8: Inscription aux Transports (Parent)

6.4.2 Interfaces O’School Transport sous Android

La figure 6.12 présente les interfaces de consultation des demandes d’abonnement au service
de transport ainsi que leurs détailles

86
Chapitre 6. Sprint 3 : Module O’School Transport

Liste des demandes au transport Détail d’une demande


Figure 6.10: Consultation demande d’abonnement au service de transport ainsi que ainsi que
leurs détails

87
Chapitre 6. Sprint 3 : Module O’School Transport

La figure 6.12 présente les interfaces de consultation des routes disponibles ainsi que leurs
détailles

Liste des routes Détail de routier


Figure 6.12: Consultation demande d’abonnement au service de transport ainsi que ainsi que
leurs détails

Conclusion

Durant ce chapitre intitulé Sprint 3 : Module O’School Transport nous avons commencé par
définir notre ligne de travail grâce au Sprint Backlog. Ensuite, nous avons fait l’analyse détaillée de
ce dernier pour aboutir enfin à l’étude conceptuelle et la réalisation de cette itération. Après avoir
terminé le premier sprint en implémentant toutes les exigences demandées, nous pouvons poursuivre
notre travail et passer au sprint 4 qui fait l’objet du chapitre suivant.

88
Chapitre 7

Sprint 4 : Module O’School


Application Mobile

Plan
1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Chapitre 7. Sprint 4 : Module O’School Application Mobile

Introduction

Ce chapitre a pour objectif d’exposer le travail achevé durant la quatrième itération de notre
projet. Pour ce faire, nous commençons par la description et l’analyse des exigences ce qui permet
de bien préparer le terrain pour la phase de conception. Enfin, nous clôturons ce chapitre par la
présentation des quelques interfaces.

7.1 Sprint backlog

Le Sprint Backlog de Sprint 4 : Module O’School Mobile se présente comme le suit :

Tableau 7.1: Produit Backlog de Module O’School

ID User Story Priority Estimation

1 En tant que élève ,je peux consulter les services à proximité 9 5 jours

a. Création de l’interface

b. Récupérer les données à partir de la base de données

c. Implémentation des données avec l’interface

2 En tant que élève ,sélectionner le types de service à proximité 8 3 jours

a. Création de l’interface

b. Récupérer les données à partir de la base de données

c. Implémentation des données avec l’interface

3 En tant que parent ,je peux localiser mon fils à tout moment. 15 8 jours

a. Création de la base de données

b. Création de l’interface de l’application

c. Implémentation des données avec l’interface

90
Chapitre 7. Sprint 4 : Module O’School Application Mobile

4 En tant que parent ,je peux ajouter et localiser tous mes 8 4 jours
enfants.

a. Récupérer les données à partir de la base de données

b. Creer l’action de localisation

c. Associer l’action avec le l’interface

d. Sauvegarder les informations dans la base de données

7.2 Analyse

7.2.1 User Story de sprint 4 : O’School Mobile Application

Dans ce qui suit,nous allons détailler les users story de module évènement en présentant ses
descriptions textuelles ainsi que les diagrammes de séquence et quelques imprimes écran réalisés.

7.2.1.1 Raffinement des cas d’utilisations

Vu que notre sprint est très riche et qu’il a des tâches importantes et obligatoires on va
présenter, par détail Les différents cas d’utilisation.
Consulter les services à proximité
La figure 7.1 présente le diagramme cas d’utilisation «Consulter les services à proximité»

Figure 7.1: Diagramme de cas d’utilisation «Consulter les services à proximité»

91
Chapitre 7. Sprint 4 : Module O’School Application Mobile

Le tableau 7.2 présente la desciption textuelle de cas d’utilisation «Consulter les Services à
proximité »

Tableau 7.2: Services à proximité

Titre Services à proximité

Acteurs Elève , Parents

Partie prenante L’élève peut consulter les services à proximité sur la carte
et intéret géographique

Pré Condition L’élève doit s’authentifier affin de consulter la liste des


services

Post Condition Localisation des services sur Map

Scénario
principal 1) L’élève clique sur le bouton de l’affichage des services
à proximité dans le menu ;

2) Le système affiche la liste des types des services ;

3) L’élève choisi le type voulu ;

4) L’élève valide son choix ;

5) Le système récupère les données à partir de l’API ;

6) Le système affiche les services à proximité sur la carte


géographique.

Scénario Le système retourne une carte géographique vide


alternatif

Scénario Erreur de connexion


d’exception

La figure 7.2 shématise la déroulement du cas d’utilisation « Consulter Services à proximité


». Aprés s’authentifier l’élève peut consulter n’importe quelle service .
Dans le cas ou les données sont récupèré à partir de l’API alors le système affiche les services
à proximité sur la cartegéographique si non le système affiche la carte vide.

92
Chapitre 7. Sprint 4 : Module O’School Application Mobile

Figure 7.2: Diagramme de séquence « Consulter Services à proximité»

93
Chapitre 7. Sprint 4 : Module O’School Application Mobile

Consulter liste des numéros de téléphone


La figure 7.3 présente le diagramme cas d’utilisation «case Consulter liste des numéros de
téléphone»

Figure 7.3: Diagramme de cas d’utilisation «Consulter liste des numéros de téléphone»

Le tableau 7.3 présente la desciption textuelle de cas d’utilisation «Localiser mon fils ( numéro

Tableau 7.3: Localiser un élève( numéro )

Titre Localiser l’élève fils

Acteurs Parents

Partie prenante Le parent peut localiser son fils en temps réel


et intéret

Pré Condition Le parent doit s’authentifier affin de localiser son fils en


temps réel

Post Condition Localisation des fils sur Map

94
Chapitre 7. Sprint 4 : Module O’School Application Mobile

Scénario
principal 1) Le parent clique sur le bouton de l’affichage des liste
des numéros à localiser ;

2) Le système affiche la liste des numéro disponibles ;

3) Le parent choisi un numéro ;

4) Le systéme localiser le numéro choisi sur la carte


géographique.

Scénario Le système affiche liste vide ; Le scenario reprend au point 2


alternatif du scénario principal

Scénario Erreur de connexion


d’exception

7.3 Conception

7.3.1 Diagramme de classe partiel

Avant de se lancer dans la programmation de ce Sprint, nous réfléchissons aux différents


concepts qui y sont exprimés pour en déduire l’architecture des classes que nous aurons besoin de
créer. On aura ce diagramme de classe
La figure 7.4 schématise la diagramme de classe de ce sprint.

95
Chapitre 7. Sprint 4 : Module O’School Application Mobile

Figure 7.4: Diagramme de classe partiel

7.3.2 Diagrammes de séquence

Ce diagramme montre la séquence des interactions qui se produisent lorsque l’utilisateur veut
consulter Services à proximité
La figure 7.5 schématise la déroulement du cas d’utilisation « Consulter Services à proximité
».
Aprés s’authentifier l’utilisateur peut consulter Services à proximité.

96
Chapitre 7. Sprint 4 : Module O’School Application Mobile

]
Figure 7.5: Diagramme de séquence « Consulter Services à proximité»

97
Chapitre 7. Sprint 4 : Module O’School Application Mobile

7.4 Réalisation

7.4.1 Interfaces

La figure 7.7 présente les interfaces d’accueil de notre application mobile

Splash Screen Interface d’accueil


Figure 7.7: Interfaces d’accueil

98
Chapitre 7. Sprint 4 : Module O’School Application Mobile

La figure 7.9 présente les interfaces d’authentification des élèves et des parents

Interface d’authentification d’élève Interface d’authentification de parent


Figure 7.9: Interfaces d’accueil

99
Chapitre 7. Sprint 4 : Module O’School Application Mobile

La figure 7.11 présente les interfaces des services à proximités

Liste des services Géolocaliser les services


Figure 7.11: Interfaces d’accueil

100
Chapitre 7. Sprint 4 : Module O’School Application Mobile

La figure 7.13 présente les interfaces de service de suivi des enfants

Inscription au service Ajouter numéro de contact


Figure 7.13: Interfaces de service de suivi des enfants

101
Chapitre 7. Sprint 4 : Module O’School Application Mobile

La figure 7.15 présente les interfaces de localisation des enfants

Liste des enfants suivis Géolocaliser des enfants suivis


Figure 7.15: Interfaces de localisation des enfants

Conclusion

Durant ce chapitre intitulé Sprint 4 : Module O’School Mobile Application nous avons
commencé par définir notre ligne de travail grâce au Sprint Backlog. Ensuite, nous avons fait l’analyse
détaillée de ce dernier pour aboutir enfin à l’étude conceptuelle et la réalisation de cette itération.

102
Conclusion générale et perspectives

Ce présent travail, s’intégrant dans le cadre du projet de fin d’études au sein de la société
716Solutions et en vue d’obtention du diplôme national d’ingénieur, avait pour objectif de proposer
une solution de gestion des divers processus métiers d’un établissement scolaire.
La mise en place d’un système d’information complet a été la réponse adéquate à cette
problématique. En effet la solution en question englobe le développement spécifique d’un ERP, d’une
application mobile Android, ainsi qu’une partie web commerciale. Pour ce faire, nous avons d’abord
effectué une étude comparative entre les principaux progiciels de gestion intégrés open source pour
choisir l’ERP «Odoo» étant celui qui correspond le plus aux besoins du futur système.
Par la suite, nous étions amenés à suivre une démarche pour mettre en place une telle solution
et avions opté pour l’approche «Scrum» qui permet de piloter le développement par les besoins
métiers tout en facilitant la réutilisation des modules.
La mise en place de notre projet a nécessité subdivision de ce dernier en quatre sprints à
savoir : sprint O’School Evénement,Sprint O’School Admission,sprint O’School Transport et sprint
Application Mobile.
Ce travail nous a été très instructif de point de vue des connaissances acquises, il nous a donné
l’occasion d’avoir une idée approfondie sur le développement sous Odoo ERP et la synchronisation
des données avec les terminaux mobiles.
Pour finir, je tiens à exprimer ma grande fierté du travail réalisé dont je garderai un excellent
souvenir et ma satisfaction d’avoir pu travailler à 716Solutions dans des bonnes conditions et dans
un environnement agréable.

103
Conclusion générale

Perspectives
En termes des perspectives, bien que la solution réalisée présente une réponse claire au cahier
de charges, nous pourrions améliorer la solution de différentes manières afin de progresser vers des
nouvelles versions plus matures.
En ce qui concerne la partie Système(Odoo),le système développé actuellement incomplet,
il nous reste d’autre module a réalisé par exemple module de gestion des examens, des emploi de
temps, des statistique plus précises et d’autre plusieurs fonctionnalités.
En ce qui concerne la partie mobile, avec la consommation des données de système nous
devons plus utilisé la puissance des terminaux mobiles comme l ’ajout de plate-forme mobile de
E-learning.
Notre système se trouve limité au niveau des notifications système et mobile.Cette fonctionnalité
doit êtree pris en considération.

104
Bibliographie

[1] Tekiano. (8 septembre 2015). Tunisie : le nombre d’écoles privées a plus que doublé en 5
ans. [Accès le 27-Avril-2017], adresse : http://www.tekiano.com/2015/09/08/tunisie-le-
nombre-decoles-privees-a-plus-que-double-en-5-ans/.

[2] C. Auffray. (7 novembre 2006). Présentation générale des erp et leur architecture modulaire.
[Accès le 27-Avril-2017], adresse : http://fablain.developpez.com/tutoriel/presenterp/.

[3] F. pour le logiciel libre (FSF). (18 novembre 2016). Catégories de logiciels libres et non libres.
[Accès le 27-Avril-2017], adresse : https://www.gnu.org/philosophy/categories.fr.html.

[4] Openbravo. (mars 2017). Openbravo. [Accès le 27-Avril-2017], adresse : https : / / fr .


wikipedia.org/wiki/Openbravo.

[5] Dolibarr. (2014). Dolibarr. [Accès le 27-Avril-2017], adresse : https://www.dolibarr.fr.

[6] D. Reis. (Avril 2015). Odoo developpement essentials. [Accès le 27-Avril-2017].

[7] WebERP. (2013). Weberp. [Accès le 27-Avril-2017], adresse : http://www.weberp.org.

[8] ERPNext. (2014). Erpnext. [Accès le 27-Avril-2017], adresse : http://frappe.github.io/


erpnext/user/manual/en/introduction/.

[9] OpenERP. (29 Novembre 2009). Architecture technique et modulaire. [Accès le 27-Avril-2017],
adresse : http : / / myopenerp . blogspot . com / 2009 / 11 / architecture - technique - et -
modulaire.html.

[10] D. Reis. (Jun 10, 2014). Improving the performance of odoo deployments. [Accès le 27-Avril-2017],
adresse : https://www.slideshare.net/openobject/performance2014-35689113.

[11] OpenEduCat. (Novembre 2015). Openeducat. [Accès le 27-Avril-2017], adresse : https://


www.openeducat.org/.

[12] fedena. (Janvier 2014). Fedena. [Accès le 27-Avril-2017], adresse : https://www.fedena.


com/.

[13] OpenSchool. (Mars 2013). Openschool. [Accès le 27-Avril-2017], adresse : https://open-


school.org.

[14] 716Solutions. (Mars 2015). 716solutions. [Accès le 27-Avril-2017], adresse : http://www.


716solutions.com/.

105
Bibliographie

[15] access-dev. (19 Février 2013). La gestion de projet :methodes classiques vs methodes agiles.
[Accès le 27-Avril-2017], adresse : http://www.access-dev.com/access-dev/la-gestion-
de-projet-methodes-classiques-vs-methodes-agiles/.

[16] E. de CASI. (Novembre. 2016). Les méthodes agiles sont-elles une arnaque ? [Accès le 27-Avril-2017],
adresse : https : / / manurenaux . wp . imt . fr / 2013 / 09 / 30 / les - methodes - agiles - sont -
elles-une-arnaque/.

[17] igm.univ. (Mars 2015). Scrum : qu’est ce que c’est ? [Accès le 21-Novembre-2016], adresse :
http://www-igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/presentation.php.

[18] wikipedia. (17 avril 2015). Scrum (boite à outils). [Accès le 28-Avril-2017], adresse : https:
//fr.wikipedia.org/wiki/Scrum_(Boite_%C3%A0_outils).

[19] clubic. (Mars 2015). Poweramc : modélisation et gestion de métadonnées. [Accès le 1-Mai-2017],
adresse : http://www.clubic.com/telecharger-fiche170752-poweramc.html.

[20] docs.postgresql. (Avril 2014). Documentation postgresql 9.3.16. [Accès le 1-Mai-2017],


adresse : http://docs.postgresql.fr/9.3/.

[21] doc.ubuntu. (Jun . 2015). Ide : eclipse. [Accès le 1-Mai-2017], adresse : https://doc.ubuntu-
fr.org/eclipse.

[22] wikipedia. (Jan. 2016). Android studio. [Accès le 1-Mai-2017], adresse : https : / / fr .
wikipedia.org/wiki/Android_Studio.

[23] firebase. (2011). Firebase. [Accès le 1-Mai-2017], adresse : https://firebase.google.com/


docs/.

[24] B. Software. (2014). Rapid php editor. [Accès le 1-Mai-2017], adresse : http : / / www .
commentcamarche.net/download/telecharger-34068155-rapid-php-editor.

[25] H. WAHSISS. (19 nov. 2015). Python et son intégration avec odoo. [Accès le 1-Mai-2017],
adresse : https://fr.slideshare.net/hassanwahsiss/python-et-son-intgration-avec-
odoo.

[26] Oracle. (Octobre. 2015). Java, qu’est-ce que c’est ? [Accès le 1-Mai-2017], adresse : https:
//www.java.com/fr/.

106
Bibliographie

[27] L. Roland. (Jan. 2016). Structurez vos données avec xml. [Accès le 1-Mai-2017], adresse :
https://openclassrooms.com/courses/structurez-vos-donnees-avec-xml/qu-est-ce-
que-le-xml.

[28] O. s.a. (2012). Openerp as a multitenant three-tiers architecture. [Accès le 1-Mai-2017],


adresse : http://odoo-docs.readthedocs.io/en/latest/02_architecture.html.

107
Annexes

Annexe 1. Comparaison entre les méthodologies agile les plus

utilisés

Tableau 8.1: Comparaison entre les méthodologies agile les plus utilisées à savoir : RAD, 2TUP,
XP et Scrum.

Méthodologie Description Avantages Inconvénients


agile

RAD — Approche — Client sur site — Délais de livraison entre


incrémentale (comme XP) 90 et 120 jours
donnant la — Dimension et — L’entreprise doit
première place maturité variable recourir un consultant
aux personnes et à la des groupes de indépendant comme
communication travail en fonction animateur/expert RAD
— Cycle de des phases — L’informaticien doit
développement passer d’un rôle de
court et fondé sur 3 décideur à celui de
phases conseiller

XP XP repose sur des — Itérations courtes et — Coût assez élevé de


itérations de quelques gérées collectivement déploiement de la
semaines méthode
— Rythme durable

— Livraison fréquente — Feedback long ou

des versions difficile à obtenir

logicielles — Travail en binôme

— Conception simple provoque très peu de


temps à l’autonomie
— Test unitaires

108
Annexes

2TUP — Propose un cycle de — Dissociation des — Superficiel sur les phases


développement en Y aspects fonctionnels situées en amont et en

— S’articule autour de et techniques aval du développement

l’architecture — Services réutilisables, — Ne propose pas des


conception générique documents types
(Framework –Design
pattern)

Scrum — Diviser le Backlog — Client présenté par — Pas Techniques


produit en ensembles un Product Owner extrêmes de qualité
d’itérations(Sprints) — le client classe du code

— Chaque sprint lui-même les — La Mise en œuvre du


contient des fonctionnalités par développement n’est pas
fonctionnalités ordre d’importance précisée, seule compte
à implémenter — Réunion quotidienne la gestion des ressources
appelées User stories de motivation, de humaines

— La livraison d’un synchronisation, — Le développement


produit partiellement de déblocage et rapide et répétitif se
fonctionnel à la fin de partage de traduit par une forte
de chaque Sprint connaissances pression

109
Annexes

Annexe 2. Rapports de service de Transport

La figure 8.1 présente le rapport contenant toute les informations sur le service Transport

Figure 8.1: Rapport des Informations de Transport

110
Annexes

La figure 8.2 présente le rapport contenant toute les informations sur le véhicule

Figure 8.2: Rapport des Informations de véhicule

111
Annexes

Annexe 3. Site Web : Partie Commerciale de projet

La figure 8.3 illustre la charte graphique de site web

Figure 8.3: Charte graphique de site web

112
Annexes

Annexe 4. Sécurité sous Odoo

Les mécanismes e contrôle d’accès doivent être combinés pour atteindre une politique e
sécurité cohérente.
Mécanismes de contrôle d’accès basés sur les groupes
Les groupes sont créés comme des enregistrements normaux sue le modèle res.groups et l’accès
aux menus via la définition de ces derniers.Cependant même sans menu, les objets peuvent rester
accessible indirectement, c’est pourquoi des véritables permissions par objet(creat,read,write,unlink)
doivent etre définies pour les groupes.
Elles sont généralement insérées via des fichiers CSV présents dans les modules.Il est également
possible de restreindre les accès à certains champs ou objets en utilisant l’attribut groups sur les
champs.
La figure 8.4 illustre l’ajout d’un groupe de sécurité "Parent"

Figure 8.4: Ajouter contrôle d’accès

La figure 8.5 montre l’ensemble des permissions définies pour les groupes sous forme de fichier
CSV "ir.model.access.csv"

Figure 8.5: Permissions des groupes de sécurité

113
Résumé
Le présent rapport décrit les différentes fonctionnalités réalisées dans mon projet de fin d’études.
Ce dernier consiste à développer une application modulaire sous l’ERP odoo et une application
Android« O’School » permettant de faciliter la gestion de l’activité de l’établissement scolaire.
Ce service offre aux utilisateurs la gestion de leurs établissements scolaires.Les utilisateurs de
l’application mobile d’O’School ont aussi la possibilité de chercher les services à proximité
(hôpital , café , librairie , restaurant..) par le biais des coordonnées GPS offrant aux parents
la possibilité d’interagir avec leurs enfants dans les établissements scolaires et les localiser.Ce
travail a été réalisé dans le cadre d’un stage de fin d’études en vue de l’obtention du diplôme
national d’ingénieur de l’Institut Supérieur d’Informatique .La solution proposée a été modélisée
par UML en adoptant la méthodologie Scrum.

Mots clés : Android, Odoo, GPS, UML, Scrum

Abstract
The present report describes the various features realized in my project of the end of studies.
It aims to develop a modular application under the ERP odoo and an Android " O’ School
" application allowing to facilitate the management of the activity of the school. This service
provides users with the management of their schools. Users of O’School Mobile App also have the
possibility to seek the nearby services (hospital, coffee, bookstore, restaurant..) through the GPS
coordinates and provides parents to locate their son in real time. This work was realized in the
order the obtaining of engineer’s national diploma from the Higher Institute of computer science.
The solution proposed has been modeling with UML by adopting the methodology Scrum.

Keywords : Android, Odoo, GPS, UML, Scrum

isi@isim.rnu.tn : ¨ž¤rtk˜¯ d§rb˜ 71 706 698 : H•Af˜ 71 706 164 :  Ah˜ TžA§C 2080 ¨ž¤CAb˜  A§r˜ w hž 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn

Vous aimerez peut-être aussi