Conception et realisation d'une application web /mobile de gestion de tâches et calcul du rendement des employés au sein d'une entreprise

1. Ministère de l'Enseignement Supérieur et de la Recherche
Scientifique
Université de Tunis El Manar
Département des Technologies de l’Information et de la Communication
Projet de fin d'année
Présenté Par
Labiedh Kais & Hermessi Wafa
Intitulé
Conception et développement d’une application web/mobile de gestion de
tâches
Encadrant : M. Moez Ben Haj Hmida
Année universitaire : 2015/2016

2. 2
Signature de l’encadrant

3. 3
Liste des tableaux :
Université de Tunis El Manar.......................................................................................................... 1
Liste des tableaux :.................................................................................................................................. 3
Listes des figures..................................................................................................................................... 5
Liste des tables ........................................................................................................................................ 6
Introduction générale............................................................................................................................ 7
Chapitre I : Présentation du projet ..................................................................................................... 8
I.1 Introduction.................................................................................................................................. 8
I.2 Présentation générale du projet.................................................................................................. 8
I.2.1 Problématique....................................................................................................................... 8
I.2.2 Etude de l’existant................................................................................................................. 8
I.3 Objectifs du projet....................................................................................................................... 9
I.4 Solution proposée......................................................................................................................... 9
Conclusion.......................................................................................................................................... 9
Chapitre II : Spécification des besoins............................................................................................... 10
II.1 Introduction.............................................................................................................................. 10
II.2 Besoins fonctionnels ................................................................................................................. 10
II.3 Besoins non-fonctionnels.......................................................................................................... 10
II.4 Traduction des besoins en diagrammes de cas d'utilisation................................................. 11
II.4.1 Description des acteurs................................................................................................ 11
II.4.2. Diagramme de cas d'utilisation global .................................................................... 11
II.3.2 Diagramme des cas d’utilisation raffiné.......................................................................... 13
Conclusion : ..................................................................................................................................... 14
Chapitre III : Architecture et conception ......................................................................................... 15
III.1Introduction.............................................................................................................................. 15
III.2 Conception générale ............................................................................................................... 15
III.3. Architecture logicielle ........................................................................................................ 16
III.3.1. Conception générale de l’application Web................................................................... 16
III.3.2 Conception générale de l’application mobile ........................................................ 17
III.4. Conception détaillée............................................................................................................... 19
III.4.1. Diagramme de classes..................................................................................................... 19
III.4.2 Digramme de séquences .................................................................................................. 21
III.4.3 Digramme d’activité ........................................................................................................ 22
Conclusion........................................................................................................................................ 23

4. 4
Chapitre IV : Réalisation et tests ....................................................................................................... 24
Introduction...................................................................................................................................... 24
IV.1 Réalisation................................................................................................................................. 24
IV.1.2. Environnement logiciel ..................................................................................................... 24
IV.1.3. Environnement technique .............................................................................................. 24
IV.1.4. Travail réalisé :................................................................................................................ 27
VI.2.-Tests réalisés: ........................................................................................................................ 30
VI.2.1.Définition :........................................................................................................................ 30
VI.2.2 Tests unitaires : ................................................................................................................ 30
VI.2.3 Test d'intégration............................................................................................................. 34
Conclusion : ..................................................................................................................................... 38
Bibliographie........................................................................................................................................ 40

5. 5
Listes des figures
Figure 1Diagramme des cas d’utilisation global.................................................................................... 12
Figure 2:cas d’utilisation raffiné............................................................................................................ 13
Figure 3 :Rest API.................................................................................................................................. 15
Figure 4:Graphe décrivant le design pattern MVVM [reference] ......................................................... 17
Figure 5:Architecture de l’application mobile : Patron MVC ................................................................ 18
Figure 6:Diagramme de classes............................................................................................................. 20
Figure 7:diagramme de séquences : Affichage des tâches affectées à un technicien.......................... 21
Figure 8:Diagramme d’activité : Approuver une tâche......................................................................... 22
Figure 9:Graphe de l’architecture de l’application web........................................................................ 26
Figure 10:Rôle de Mongoose ................................................................................................................ 27
Figure 11:Interface d’accueil de l’application Web............................................................................... 28
Figure 12:Interface d’accueil de l’application mobile ........................................................................... 29
Figure 13:Liste des tâches ..................................................................................................................... 29
Figure 14:Interface des paramètres...................................................................................................... 30
Figure 15:Logo de mocha...................................................................................................................... 31
Figure 16:Code source de la vérification du remplissage des champs d’une tâche.............................. 31
Figure 17:Résultat du test : vérification du remplissage des champs d’une tâche............................... 32
Figure 18:Code source de la vérification du remplissage des champs d’un utilisateur........................ 33
Figure 19:Résultat du test : vérification du remplissage des champs................................................... 33
Figure 20:Logo Supertest....................................................................................................................... 34
Figure 21:Séparation des bases de données......................................................................................... 35
Figure 22:Code source : insertion des champs par défaut.................................................................... 35
Figure 23:Insertion des champs avec succès......................................................................................... 36
Figure 24:code source : Accès à la page d’accueil................................................................................. 36
Figure 25:Résultat du test : Succès de l’accès à la page d’accueil ........................................................ 37
Figure 26:Code source de la vérification de l’existence des routes saisies........................................... 37
Figure 27:Résultat du test : Erreur 404 ................................................................................................. 38

6. 6
Liste des tables
Tableau 1Description du diagramme des cas d’utilisation ................................................................... 12
Tableau 2:Description du diagramme des cas d’utilisation raffiné....................................................... 14

7. 7
Introduction générale
De nos jours, chaque entreprise cherche le meilleur moyen pour augmenter sa
production et de confronter les différents conflits qui peuvent être engendrés par le
manque de coordination et d’organisation au sein de ses différentes équipes. En
effet, vu la croissance des activités au sein des entreprises, la tâche de gérer
efficacement toutes ces actions s’avère de plus en plus complexe. En plus, le
pilotage des données, aujourd’hui, n’est plus une mince affaire. Pour surpasser ces
difficultés, une entreprise doit utiliser des outils optimisés et adaptés, facilitant les
tâches et offrant des fonctionnalités riches et utiles.
Pour cela, nous cherchons à créer une application de gestion des tâches des
employés qui aide à fixer les objectifs à atteindre pour chaque tâche et qui
synchronise le travail de chaque membre auprès de son employeur.
Cette application peut être intéressante surtout pour les entreprises fournissant un
service sur le champ ce qui nécessite le déplacement des employés et la validation
instantanée de leurs tâches. Ceci peut s’avérer intéressant aussi pour les entreprises
à activités critiques telles que la finance, le service technique…
Le présent rapport synthétise le travail que nous avons effectué. Il est organisé en
chapitres comme suit :
– Le premier chapitre donne une présentation générale du projet.
– Le deuxième chapitre intitulé « Spécification des besoins », présente les différents
besoins fonctionnels et non fonctionnels auxquels doit satisfaire l’application.
– La conception de notre solution sera présentée dans le chapitre trois.
– Le quatrième chapitre décrit les tâches accomplies et les tests réalisés.
– Et nous allons finir par une conclusion et des perspectives.

8. 8
Chapitre I : Présentation du projet
I.1 Introduction
Ce chapitre a pour objectif de situer le projet dans son contexte général, à
savoir la problématique qui a inspiré la création de notre application, la description du
projet et les objectifs à atteindre.
I.2 Présentation générale du projet
I.2.1 Problématique
Le souci principal de chaque moyenne ou grande entreprise se réduit
essentiellement à la gestion du personnel et à la coordination de leurs tâches afin de
maintenir une ambiance favorable à la productivité et l’évolution de l’entreprise.
Ceci nécessite alors la communication continue entre chaque employé et son patron.
Une telle communication peut s’avérer coûteuse en termes de ressources financières
de l’entreprise ainsi qu’en termes du temps mis pour exécuter une tâche.
Ce temps perdu est en fait expliqué soit par le déplacement des employés, d’où la
difficulté de réaliser des réunions pour discuter les tâches, soit par le manque de
contrôle des délais et de performance de chaque employé.
I.2.2 Etude de l’existant
Les entreprises à structure hiérarchique rencontrent souvent le problème de
communication entre patron et employés, surtout lorsque ces employés sont portés à
se déplacer au cours de leurs journées de travail.
La communication se fait dans ce cas par l’une ou la combinaison des méthodes
suivantes :
- Par téléphone, ce qui peut être coûteux pour une entreprise à grande activité
-Par e-mail que l’employé doit consulter constamment pour être au courant des
nouveaux messages de la part de son patron.
-Par certaines applications web qui présentent une plateforme de communication et
de partage de travail entre les membres d’une équipe dans une entreprise. On peut
Citer comme exemple «Orange Scrum » [1] qui est une application destinée à
faciliter la gestion des projets ainsi que la communication entre les membres.
Mais cette solution reste toujours limitée car elle n’a pas mis en considération le
déplacement des employés. En effet, dans la plupart des entreprises modernes les
employés se déplacent durant leur travail. Ce déplacement est un acteur crucial à la
flexibilité du travail et la décentralisation des services de l’entreprise.

9. 9
I.3 Objectifs du projet
Les problèmes mentionnés précédemment peuvent être résolus par un moyen
qui garantit :
- L’affectation rapide de chaque tâche à l’employé concerné.
-La disponibilité de l’énoncé de chaque tâche ainsi que sa documentation auprès de
l’employé concerné.
-La communication instantanée avec les employés distants.
-Le contrôle du rendement de chaque employé par rapport à l’exécution des tâches
qui lui sont affectées.
I.4 Solution proposée
Ce projet consiste à concevoir et développer une application web/mobile
permettant de gérer les tâches effectuées au sein d’une entreprise. Elle doit aussi
offrir la possibilité d’organiser l’affectation des tâches aux employés ainsi que le suivi
de l’avancement de chaque tâche.
Cette application vise essentiellement à diminuer le temps que prend un rapport de
mission ou une validation verbale de l’accomplissement d’une tâche. Ceci va donc
améliorer considérablement le dynamisme du travail et va créer un espace
d’interaction entre les employés afin de garantir une meilleure productivité et clarté
du travail.
L’application présente aussi des statistiques concernant l’accomplissement des
tâches attribuées aux différents employés. Cette méthode permettra à l’entreprise de
documenter son travail et d’accorder à chaque employé la rémunération ou la prime
de rendement qu’il mérite.
Notre application est destinée essentiellement aux entreprises dans lesquelles les
employés se déplacent souvent, à savoir les techniciens quel que soit leur domaine
d’expertise. Ces employés sont appelés à être présents sur le champ et l’entreprise à
laquelle ils appartiennent doit contrôler les tâches individuelles dont ils sont
responsables.
Conclusion
Tout au long de ce chapitre, nous avons mis notre projet dans son cadre général, à
savoir la présentation du projet et ses objectifs, et nous allons spécifier dans le
prochain chapitre les différents besoins auxquels doit répondre notre application.

10. 10
Chapitre II : Spécification des besoins
II.1 Introduction
La réussite de tout projet dépend de la qualité de son départ. De ce fait,
l’étape de spécification des besoins constitue la base de départ de notre
travail, elle doit décrire sans ambiguïté le logiciel à développer.
Pour assurer les objectifs attendus, il est essentiel que nous parvenions
à une vue claire des différents besoins escomptés de notre projet. Au cours de
ce chapitre, nous allons dégager les fonctionnalités attendues du module "
Gestion des tâches" en définissant les différents cas d’utilisation et quelques
scénarios qui expliquent ces cas.
II.2 Besoins fonctionnels
Le module gestion des tâches doit permettre aux utilisateurs de
consulter les tableaux de bords des tâches et des missions. Ce module doit
mettre à la disposition des acteurs les fonctionnalités suivantes :
-Un administrateur peut créer, modifier ou supprimer un technicien.
-Un administrateur peut créer, modifier ou supprimer des tâches.
-Un administrateur affecte les tâches créées aux techniciens.
-Un administrateur peut envoyer des fiches techniques (pdf, xls..) aux
techniciens.
-Un administrateur peut visualiser les statistiques relatives :
-aux tâches achevées.
-au rendement des employés.
-Un technicien peut accéder à la liste de ses tâches affectées par
l'administrateur.
-Un technicien peut créer et modifier son profil.
-Un technicien peut visualiser les statistiques relatives à ses propres tâches.
-Un technicien peut communiquer avec l'administrateur ou avec ses collègues
à travers un service de messagerie.
-Un technicien peut envoyer un compte-rendu décrivant la réalisation de ses tâches
(tâche effectuée, les problèmes rencontrés dans le cas contraire…).
II.3 Besoins non-fonctionnels
-L’application doit être facile à utiliser.

11. 11
-Le temps de réponse de l’application doit être le plus rapide possible.
-L’application doit être portable.
-Possibilité d’optimiser l’application plus tard.
-L’application doit sécuriser les informations de ses utilisateurs.
II.4 Traduction des besoins en diagrammes de cas d'utilisation
Le diagramme des cas d’utilisation est un modèle simplifié du
fonctionnement de l’application qui spécifie les acteurs qui l’utilisent et les
services qu’il leur offre.
II.4.1 Description des acteurs
Un acteur représente une abstraction d'un rôle joué par des entités
externes au système qui interagissent directement avec lui.
Dans cette application, nous identifions deux types d’acteurs : le technicien et
l’administrateur
Technicien: Il s’agit d’un employé de l’entreprise qui est chargé d’accomplir
les tâches qui lui sont assignées.
L’application lui offre plusieurs fonctionnalités telles que consulter ses propres
tâches, envoyer des messages et rédiger un rapport concernant chaque
tâche.
Administrateur: C’est l’acteur qui gère les tâches ainsi que les employés. Il
se charge aussi de contrôler l’avancement du travail au sein de l’entreprise.
La fonctionnalité la plus importante qu’il a est d’affecter les tâches aux employés et
de recevoir les rapports d’exécution de chaque tâche.
II.4.2. Diagramme de cas d'utilisation global
Le diagramme de la figure 1 illustre le rôle de chaque acteur ainsi que
l’étendue de ses responsabilités.

12. 12
Figure 1Diagramme des cas d’utilisation global
Ce diagramme est développé davantage par le tableau 1 :
Titre Accéder aux services de l’application
Description Ce cas d’utilisation permet aux utilisateurs ayant le rôle
technicien ainsi que le rôle administrateur d’accéder à
leurs comptes sur l’application.
Acteurs Technicien, administrateur
Pré-conditions -L’utilisateur doit être authentifié.
-L’utilisateur doit avoir le rôle « Administrateur » pour
gérer les tâches de tous les utilisateurs.
Scénario nominal 1. L’utilisateur s’authentifie.
2. L’utilisateur choisit le module « Tâches » dans le menu
de la page d’accueil.
3. L’utilisateur est conduit à la page principale du module
où il peut visualiser ses différentes tâches ainsi que des
statistiques sur leur progrès.
Tableau 1Description du diagramme des cas d’utilisation

13. 13
II.3.2 Diagramme des cas d’utilisation raffiné
Nous avons choisi d’étudier le cas d’utilisation qui définit le rôle de l’administrateur à
savoir la gestion des utilisateurs.
Le diagramme de la figure 2 en décrit les détails :
Figure 2:cas d’utilisation raffiné

14. 14
Le tableau 2 traduit et explique la figure 2 :
Cas d’utilisation : Gérer les utilisateurs
Objectifs : Permettre à l’administrateur de gérer les utilisateurs de la
plateforme (ajout, suppression, modification).
Acteur Administrateur
Pré-condition : L’utilisateur est authentifié en tant que administrateur
Post-condition Mise à jour de la base de données
Scénarios nominaux : 1. Consulter la liste des utilisateurs : L’administrateur
demande la liste des utilisateurs. Le système retourne la liste de
tous les utilisateurs ainsi que les informations relatives.
2. Ajouter un utilisateur : L’administrateur demande d’ajouter
un nouvel utilisateur, il choisit le type d’utilisateur à ajouter et
remplit le formulaire d’ajout retourné par le système. Le système
valide les informations saisies et confirme l’ajout de l’utilisateur
en cas de réussite.
3. Modifier un utilisateur : L’administrateur choisit un compte à
éditer, modifie les
informations désirées et enregistre la modification. Le système
valide les informations modifiées et confirme la modification en
cas de réussite.
4. Supprimer un utilisateur L’administrateur choisit un compte
à effacer. Le système confirme la suppression en cas de
réussite.
Tableau 2:Description du diagramme des cas d’utilisation raffiné
Conclusion :
Ce chapitre nous a permis de couvrir les différents besoins fonctionnels et non fonctionnels
auxquels doit satisfaire notre application. Nous avons aussi détaillé ces besoins à travers des
diagrammes de cas d’utilisation pour passer par la suite à la conception de notre application
qui sera présentée dans le chapitre suivant.

15. 15
Chapitre III : Architecture et conception
III.1Introduction
Dans le présent chapitre, nous allons entamer une partie importante du
développement de l’application qui constitue un pont entre la spécification et la
réalisation. Nous allons présenter dans un premier temps la conception générale de
notre application, puis la conception détaillée comprenant les vues statiques via les
diagrammes de classes.
III.2 Conception générale
Notre application consiste en un module web et un autre mobile qui sont en
interaction à travers des services web.
Le mode d’interaction ainsi que la modélisation de l’application peuvent être décrits
par ce graphe :
Figure 3 :Rest API

16. 16
III.3. Architecture logicielle
Nous avons opté pour l’architecture REST pour le développement de notre
application.
L’architecture REST (REpresentational State Transfer) est un style d’architecture
pour les systèmes distribués que nous avons choisi pour ces avantages qui
concernent notre application:
 L'application est plus simple à entretenir, parce qu’elle sépare la partie client de
la partie serveur.
 Elle permet aussi de ne pas avoir à maintenir une connexion permanente entre le
client et le serveur. Le serveur peut ainsi répondre à d'autres requêtes venant
d'autres clients sans saturer l'ensemble de ses ports de communication.
 Une meilleure évolutivité et tolérance aux pannes (un serveur peut être ajouté
facilement pour augmenter la capacité de traitement, ou pour en remplacer un
autre).
 Dans un contexte Web :
 l'utilisation du protocole HTTP permet de tirer parti de son enveloppe et ses
en-têtes.
 l'utilisation d'URI comme représentant d'une ressource permet d'avoir un
système universel d'identification des éléments de l'application [1].
III.3.1. Conception générale de l’application Web
III.3.1.1.Choix de patron de conception
Un patron de conception ou un design pattern est un concept destiné à
résoudre les problèmes récurrents du génie logiciel suivant le paradigme objet. Les
patrons de conception décrivent des solutions standards pour répondre à des
problèmes d’architecture et de conception des logiciels par une formalisation de
bonnes pratiques, ce qui signifie que l’on privilégie les solutions éprouvées (un
patron de conception n’est considéré comme « prouvé » qu’une fois qu’il a été utilisé
avec succès au moins dans trois cas)[4].
Pour l’application web, nous avons choisi le patron MVVM.
MVVM(MODEL VIEW VIEWMODEL) :

17. 17
Ce patron de conception permet, comme le modèle MVC (Modèle-Vue-Contrôleur),
de séparer la vue de la logique et de l’accès aux données en accentuant les
principes de binding et d’événements.
La différence entre MVVM et MVC est le fait que le MVVM se repose sur le
DataBinding et l’évènementiel. Pour plus de clarté, nous détaillant les composants de
ce modèle dans ce qui suit :
 MODEL : correspond aux données. Il s’agit en général de plusieurs classes
qui permettent d’accéder aux données.
 VIEW : Couche PRÉSENTATION. C’est la présentation graphique de
l’application (l’interface utilisateur)
 VIEWMODEL : Peut être simulé à la colle entre le modèle et la vue. Il s’agit
d’une classe qui fournit une abstraction de la vue, il s’appuie sur la puissance
du binding pour mettre à disposition de la vue les données du modèle.
Nous présenterons plus de détail sur le patron de conception MVC dans
l’architecture de l’application mobile.
Figure 4:Graphe décrivant le design pattern MVVM [reference]
III.3.2 Conception générale de l’application mobile
L’architecture de l’application mobile peut être illustrée par le graphique de la
figure 5

18. 18
Figure 5:Architecture de l’application mobile : Patron MVC
Pour l’application mobile, nous avons choisi de travailler avec le patron de
Conception MVC.
Le Modèle-Vue-Contrôleur (en abrégé MVC, de l’anglais Model-View-Controller) est
une architecture et une méthode de conception qui organise l’interface homme-
machine (IHM) d’une application logicielle. Ce paradigme divise l’IHM en
un modèle (modèle de données), une vue (présentation, interface utilisateur) et un
contrôleur (logique de contrôle, gestion des événements, synchronisation), chacun
ayant un rôle précis dans l’interface. Cette méthode a été mise au point
en 1979 par Trygve Reenskaug [12].
Nous l’avons choisi vu ses avantages nombreux :
-Il permet de formaliser l’application et de faciliter la compréhension de son mode de
fonctionnement.
-Il permet de délimiter les différents modules de l’application et de simplifier leur
création.
-La séparation des modules nous permet d’effectuer des changements sur l’un d’eux
sans affecter le reste du code ou le fonctionnement global de l’application.

19. 19
Les composant du modèle MVC sont :
 Model : La base de l’application. Il décrit les données et contrôle leur intégrité.
Il comporte la base de données.
 Vue : L’interface avec laquelle interagit l’utilisateur. Elle est en interaction avec
le modèle ainsi que le contrôleur.
 Contrôleur : Responsable de la synchronisation entre le modèle et la vue. Il
gère les événements reçus par la vue et demande les changements
nécessaires au modèle.
III.4. Conception détaillée
III.4.1. Diagramme de classes
La figure 6 représente le diagramme de classes des entités utilisées dans
notre système :

20. 20
Figure 6:Diagramme de classes
-Utilisateur : c’est la classe qui représente un utilisateur de l’application qui est soit
un technicien soit un administrateur.
-Tâche : c’est l’entité qui représente les tâches gérées par l’administrateur et
affectées au technicien.
-Document : certaines tâches peuvent être accompagnées de documents qui
servent soit à clarifier certains détails ou qui sont à remplir par le technicien
responsable de ces tâches (fiche technique, cahier des charges, contrat…).
-Message : c’est la classe qui définit les messages échangés entre les utilisateurs à
travers un service de messagerie dans l’application.

21. 21
-Rapport : la classe Rapport désigne le compte-rendu retourné par le technicien à
l’administrateur qui décrit le déroulement de sa mission et son résultat : soit la tâche
est accomplie soit elle a présenté certains problèmes que le technicien doit
mentionner.
III.4.2 Digramme de séquences
Le diagramme des séquences suivant décrit le scénario de consultation de la
fiche d’un technicien par l’administrateur:
Figure 7:diagramme de séquences : Affichage des tâches affectées à un technicien
Ce diagramme décrit le déroulement de la recherche d’un technicien et l’affichage de
ses données ainsi que ses tâches.
Il est à noter que l’administrateur peut aussi visualiser les statistiques de progrès de
chaque technicien ce qui permet le calcul juste et efficace des primes de rendement
des employés.

22. 22
III.4.3 Digramme d’activité
Le digramme de la figure 8 illustre le scénario d’approbation d’une tâche qui
met en jeu l’administrateur, le technicien ainsi que le système qui gère l’application.
Figure 8:Diagramme d’activité : Approuver une tâche

23. 23
Après avoir créé une tâche, l’administrateur choisit le technicien à l’effectuer.
Lorsque le technicien concerné reçoit la notification de la nouvelle tâche, il peut
confirmer ou nier sa disponibilité.
Cas idéal :
Le technicien confirme sa disponibilité pour effectuer la tâche.
Le technicien achève la tâche et confirme son exécution.
Si l’entreprise ne reçoit pas de réclamations de la part du client concerné après 24
heures, la tâche est validée et enregistrée dans la fiche du technicien.
Cas alternatifs :
1. Le technicien n’a pas confirmé sa disponibilité : Une notification est envoyée à
l’administrateur qui choisira par la suite un autre technicien pour effectuer la
tâche.
2. Le technicien n’a pas confirmé l’exécution de la tâche : dans le cas où certains
problèmes peuvent surgir lors de l’exécution de la tâche, le technicien rédige
un rapport décrivant ce problème et l’envoie à l’administrateur pour y
remédier.
3. L’entreprise reçoit une réclamation de la part du client dans les 24 heures qui
suivent l’exécution de la tâche : la tâche sera alors marquée comme
inachevée et sera affectée de nouveau à l’un des techniciens disponibles (y
compris celui qui l’a exécutée la première fois).
Notons que chaque tâche, achevée ou non, sera enregistrée dans la fiche de
chaque technicien pour bien suivre son progrès et calculer son rendement.
Conclusion
Dans ce chapitre, nous avons modélisé le fonctionnement de l’application afin
d’avoir une vue globale et simplifiée du système. Nous avons aussi détaillé les
différents modules de l’application ce qui nous a permis d’organiser le travail et
d’avoir une idée claire sur le travail à réaliser. Ce travail est décrit plus précisément
dans le chapitre qui suit.

24. 24
Chapitre IV : Réalisation et tests
Introduction
Après l’étape de conception de l’application, nous allons, dans ce chapitre,
décrire la phase de réalisation. Nous allons présenter, en premier lieu,
l’environnement du travail utilisé pour le développement de l’application, ensuite,
nous allons donner un aperçu sur le travail accompli à travers des captures d’écran.
IV.1 Réalisation
IV.1.2. Environnement logiciel
Dans ce paragraphe nous décrivons les différents outils et logiciels utilisés
pour la mise en œuvre de l’application.
-Enterprise Architect [13] :
Pour les besoins de notre projet, nous avons utilisé l’outil de modélisation "Enterprise
Architect" qui nous a permis de concevoir l’architecture de notre plateforme ainsi que
les différents diagrammes contenus dans ce rapport.
-Adobe Photoshop CS6 [14] :
Adobe Photoshop est un logiciel de traitement d'image. Cette application permet de
créer et de modifier des images. Elle nous a été utile lors de la création du logo de
l’application ainsi que pour ajuster certaines icones et photos utilisées dans
l’application.
-Android Studio (version 1.5.1) [15] :
Comme environnement de développement mobile, nous avons opté pour Android
Studio vu qu’il facilite la correction du code et qu’il fournit un aperçu instantané après
chaque changement sur l’application.
Il nous a aidés aussi à travers son émulateur intégré qui simule un appareil mobile
avec toutes ses fonctionnalités ce qui nous a permis de mieux tester notre travail.
-Web Storm (version 10.0.4)[16] :
WebStorm est un IDE pour les langages Web (HTML, CSS et JavaScript), développé
par l'entreprise JetBrains et basé sur la plateforme IntelliJ IDEA.
IV.1.3. Environnement technique

25. 25
-HTML5/CSS3 [17] :
Ce sont les deux langages utilisés pour créer et mettre en forme (respectivement) les
pages de l’application web.
-Java [18] :
C’est un langage de programmation orienté objet caractérisé essentiellement par sa
portabilité. Nous l’avons utilisé pour coder notre application mobile.
-Node Js [18] :
Node.js est une technologie qui permet d’écrire du javascript coté serveur pour
réaliser des applications webs.Node.js est particulièrement adapté aux projets ayant
besoin de temps réel. Il supporte nativement des technologies comme les
websockets, ce qui permet de créer facilement des applications réactives [5].
-Express Js [19] :
C'est un micro framework pour construire des applications web en Node.js,
-Angular Js [20] :
AngularJS est un framework Javascript très populaire actuellement, visant à
structurer et simplifier le développement d’applications mono-pages (Single Page
Application – SPA).
Il est développé par Google sous licence open-source, il offre les outils nécessaires
pour développer du code bien organisé, modulaire, basé sur l’injection de
dépendances et prêt pour les tests unitaires. [7]
Nous avons utilisé les trois derniers outils mentionnés ci-dessus dans partie web qui
peut être mieux simplifiée à travers ce schéma :

26. 26
Figure 9:Graphe de l’architecture de l’application web
-MongoDB [21] :
C'est un système de gestion de base de données orientée documents, répartissable
sur un nombre quelconque d'ordinateurs et ne nécessitant pas de schéma prédéfini
des données (schemaless).
Il est écrit en C++. Le serveur et les outils sont distribués sous licence AGPL, les
pilotes sous licence Apache et la documentation sous licence Creative Commons2. Il
fait partie de la mouvance NoSQL [8].
Nous l’avons choisi parce qu’il offre plus de souplesse dans le contenu de la base de
données vu qu’il ne se base pas sur un schéma prédéterminé. Il contient aussi des
mécanismes d’agrégation qui facilitent efficacement le code et diminuent le temps de
traitement.
-Mongoose [24] :
Mongoose, est un progiciel open-source de Node.js qui fournit une structure et un
modèle aux données de l’application enregistrées par MongoDB.
Mongoose traduit les données dans la base de données en objets
JavaScript pour être utilisés dans l’application.

27. 27
Figure 10:Rôle de Mongoose
-Xml [22] :
C’est un métalangage en balises qui permet de faciliter l’échange de données entre
de différents systèmes informatiques hétérogènes.
-JSON [23] :
C’est un format de données qui est léger, facile à lire et écrire pour les humains et il
est aisément analysable par les machines. Il est basé sur le langage JavaScript. [1]
Nous l’avons utilisé vu qu’il est la base du langage MongoDB que nous avons choisi
pour traiter la base de données, ainsi que pour manipuler le transfert de données
dans la coté mobile de l’application.
-SQLite [25] :
C’est une bibliothèque écrite en C qui propose un moteur de base de données
rationnelle accessible par le langage SQL [2].
Elle nous a été utile dans l’application mobile vu qu’elle diminue considérablement le
nombre de requêtes vers la base de données en stockant certaines données d’où, la
diminution le temps de traitement et de réponse du système.
-Materialize :
Materialize est un framework créé par Google basé sur le material design qui a servi
comme outil de design du coté web de l’application. Nous l’avons choisi parce qu’il
est riche en composantes simples, modernes et diverses.
IV.1.4. Travail réalisé :

28. 28
Introduction :
Cette partie est consacrée à présenter quelques interfaces de l’application réalisée.
IV.1.4.1. Interfaces Web :
Les différentes interfaces de l’application web ont été créées à l’aide du framework
Materialize dans lequel nous avons choisi des éléments clairs et visuellement
simples.
Les couleurs choisies pour le coté web ainsi que mobile sont principalement:
- un bleu sombre (code hex. #050229)
-un bleu turquoise (code hex. #199a95)
-un rose magenta (code hex. #941152)
Figure 11:Interface d’accueil de l’application Web
IV.1.4.2. Interfaces Mobile :
Les interfaces mobiles ont été créées directement à l’aide du logiciel Android Studio
En respectant les mêmes conventions d’apparence de l’application Web.

29. 29
La figure 12 représente la première interface de l’application mobile, c’est celle qui
permet à l’utilisateur de s’identifier et d’accéder à son espace personnel qui contient
ses tâches, son profil, ses messages ainsi que d’autres services :
Figure 12:Interface d’accueil de l’application mobile
La figure 13 montre la première interface affichée après la connexion de l’utilisateur.
Il s’agit de la liste des tâches affectées à l’utilisateur qu’elles soient effectuées ou
pas, triées par date.Chaque élément de cette liste redirige l’utilisateurs au détails de
la tâche sélectionnée.
Figure 13:Liste des tâches

30. 30
La figure suivante décrit l’interface des paramètres que l’utilisateur peut configurer,
allant de l’affichage des tâches jusqu’à la modification de ses données personnelles
et les informations sur l’application.
Figure 14:Interface des paramètres
VI.2.-Tests réalisés:
Nous allons commencer cette partie par une définition des tests et voir leur
importance dans le cycle de développement d'une application.
VI.2.1.Définition :
« Tester, c'est exécuter le programme dans l'intention d'y trouver des
anomalies ou des défauts ». [9]
Le plan de test définit les étapes à valider par le testeur pour vérifier le bon
fonctionnement de l'application et pour détecter ainsi les erreurs qui pourraient
survenir lors d'une utilisation « normale »de l'application.
Il existe plusieurs types de tests, pour notre application nous avons réalisé des tests
unitaires et des tests d'intégration.
VI.2.2 Tests unitaires :
Le test unitaire est une procédure permettant de vérifier le bon fonctionnement
d'une partie précise d'un logiciel ou d'une portion d'un programme.
V.2.2.1. Outils de test :
Dans notre application nous avons effectué nos tests unitaires en utilisant le
fameux framework de test JavaScript mocha .

31. 31
Figure 15:Logo de mocha
VI.2.2.2. Cas de test :
 Test du « TaskController » :
Objectif : Ce test nous permet de vérifier si on peut créer une tâche sans
donner sa description
Scénario:
On va créer une tâche avec la méthode « post » du « Task controller » avec
tous ses attributs sauf sa description.
La figure suivante illustre le code source du processus de test:
Figure 16:Code source de la vérification du remplissage des champs d’une tâche

32. 32
En utilisant Mocha pour tester ce code, nous avons obtenu le résultat représenté
dans la figure 17 :
Figure 17:Résultat du test : vérification du remplissage des champs d’une tâche
Ce résultat montre bien qu’on ne peut pas passer une nouvelle tâche par la méthode
« post » savoir fournir sa description, ce qui est clair dans le message fourni par le
testeur.
 Test du « UserController »
Objectif : Ce test nous permet de vérifier si on peut créer un utilisateur sans
donner son nom.
Scénario:
On va ajouter un utilisateur avec la méthode « post » du « User controller »
avec tous ses attributs sauf son nom.
Le code source est donné par la figure 18 :

33. 33
Figure 18:Code source de la vérification du remplissage des champs d’un utilisateur
Après le lancement du test avec Mocha nous avons obtenu le résultat représenté
dans la figure 19 :
Figure 19:Résultat du test : vérification du remplissage des champs

34. 34
Comme le montre la figure précédente, le test a abouti à une erreur : « Bad Status
201 ».Cette type d’erreurs signifie une erreur dans les données envoyées à la base
de données. Dans notre cas, elle a été bien accompagnée avec un message qui
explique qu’on ne peut pas envoyer une requête « post » sans le champ « nom »
rempli.
VI.2.3 Test d'intégration
Dans le monde du développement informatique, le test d'intégration est une
phase dans les tests, qui est précédée des tests unitaires et est généralement
suivie par les tests de validation.
Dans le test unitaire, on vérifie le bon fonctionnement d'une partie précise d'un
logiciel ou d'une portion d'un programme (appelée « unité » ou « module »), dans le
test d’intégration chacun des modules indépendants du logiciel sont assemblés et
testés dans l’ensemble.
VI.2.3.1. Outils de test :
Pour les tests d'intégrations, nous avons choisi d’utiliser Supertest, un package
Node.js qui permet de simplifier l’écriture des requêtes HTTP (une surcouche au
package http disponible dans Node.js).
Figure 20:Logo Supertest
1.3.2 Cas des tests :
 Test d’intégration de la base de données :
Objectif : Tester lors de l'ajout d'un utilisateur qu’au niveau de la base de
données:
- l'ajout de l’attribut « _id » est automatique.
- l'ajout de l'attribut « isactif » avec la valeur « false » est automatique.
Pour cela nous allons séparer l'environnement de développement de
l'environnement de production en créant une copie de test de notre base de
données.
La figure 20 montre qu’on a choisi de se connecter à la base appelée
« pfaAPI_test » si on est dans un environnement de développement et à la

35. 35
base d’origine, appelée « pfaApi » si on est dans un environnement de
production.
Figure 21:Séparation des bases de données
La figure suivante montre le code mis en œuvre pour réaliser les conditions à vérifier
qui sont : l’ajout du champ « _id » et « isactif » avec une valeur « false » par défaut.
Figure 22:Code source : insertion des champs par défaut
L’exécution de ce code donne un résultat affirmant la création de l’utilisateur avec les
champs mentionnés avec succès.

36. 36
Ceci est illustré dans la figure 23 :
Figure 23:Insertion des champs avec succès
 Test de la route de la page d’accueil
Objectif : On va utiliser la route « '/' » avec la méthode « http Get » pour
accéder à la page d’accueil.
Le code source décrit par la figure 24 consiste à créer cette route pour
pouvoir accéder à la page d’accueil.
Figure 24:code source : Accès à la page d’accueil

37. 37
Après l’exécution de ce code avec l’outil Supertest, nous avons confirmé qu’on peut
maintenant accéder à la page d’accueil avec la route « ‘/ ‘» comme montré dans la
figure 25 :
Figure 25:Résultat du test : Succès de l’accès à la page d’accueil
 404 Error :
Objectif : Vérifier si on peut passer dans l’adresse URL une route qui n'est
définie dans nos routes. Si la route n’existe pas, il faut que l’utilisateur reçoive une
erreur « 404 error » qui signifie que l’adresse qu’il cherche est introuvable.
Scénario :
Nous allons choisir une route « /random » qui n'est pas définie dans nos
routes et on va la tester.
La figure 26 décrit le code source de cette vérification.
Figure 26:Code source de la vérification de l’existence des routes saisies

38. 38
Le résultat de ce test est donné par la figure 27.
Figure 27:Résultat du test : Erreur 404
Comme le montre la figure précédente, la route que nous avons choisie n’existe pas,
d’où le système a retourné une erreur 404.
Conclusion :
Dans ce chapitre, nous avons présenté quelques interfaces de du coté web et
mobile de l'application et nous avons démontré quelques scénarios de tests que
nous avons appliqué pour vérifier que l'application fonctionne correctement.

39. 39
Conclusion et perspectives
Dans ce rapport, nous avons exposé les étapes de conception et de développement
de notre application qui consiste à créer une application mobile/web pour la gestion
des tâches dans une entreprise. C'est un exemple concret du rôle des TIC dans le
domaine du développement utile dans la vie courante.
Notre travail s'est déroulé sur trois étapes. Nous avons commencé par une étude de
l'existant, suivie de la proposition d'une solution adéquate.
Dans la deuxième phase, nous avons spécifié les besoins fonctionnels et non
fonctionnels que doit respecter l’application suivis par des diagrammes des cas
d’utilisation mettant en jeu les acteurs qui interagissent avec le système.
La troisième étape concernait la conception de notre application en utilisant des
diagrammes de cas d'utilisation, de classes et de séquences.
Dans la dernière phase, nous avons évoqué les différentes technologies utilisées
ainsi que l'implémentation de notre système.
Ce projet se situe en effet, dans le cadre du projet de fin de la deuxième année du
cycle ingénieur en informatique. Ce projet était une véritable expérience de travail en
collaboration, qui nous a permis de bien gérer la répartition des tâches et de
renforcer l'esprit de partage de connaissances ainsi que la synchronisation de notre
travail.
Cependant, nous pouvons encore améliorer cette application en ajoutant un système
automatique de détection de l’emplacement de chaque employé afin d’optimaliser
l’affectation des tâches en fonction de l’emplacement le plus proche par rapport à
celui de l’employé.
Une autre amélioration concernerait les statistiques du progrès de chaque employé.
On peut certainement améliorer l’algorithme de calcul de ce progrès en ajoutant de
nouvelles variables ou bien par l’ajustement des paramètres utilisés dans le calcul

40. 40
Bibliographie
[1] http://www.orangescrum.com/ (consulté le 15/4/2016 à 12 :26)
[1] https://fr.wikipedia.org/wiki/Representational_State_Transfer (consulté le 2/4/2016
à 19:26)
[1] http://www.json.org/json-fr.html (consulté le 2/4/2016 à 20:00)
[2] https://fr.wikipedia.org/wiki/SQLite (consulté le 2/4/2016 à 20:06)
[4] https://fr.wikipedia.org/wiki/Patron_de_conception (consulté le 7/4/2016 à 19:45)
[5] http://www.toam.fr/06-04-2014-bien-demarer-avec-nodejs/ (consulté le 7/4/2016 à
20 :10)
[7] http://www.opentuto.com/apprenez-a-developper-des-applications-angularjs/ (consulté
le 7/4/2016 à 20:12)
[8] https://fr.wikipedia.org/wiki/MongoDB (consulté le 7/4/2016 à 20:19)
[9] http://perso.ens-lyon.fr/christophe.alias/verif/bardin.pdf (consulté le 7/4/2016 à 20:38)
[12] https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur (consulté le
16/4/2016 à 19 :55)
[13] http://www.sparxsystems.com.au/products/ea/ (consulté le 17/4/2016 à 11:22)
[14] http://www.adobe.com/fr/products/photoshop.html (consulté le 17/4/2016 à 11:26)
[15] http://developer.android.com/sdk/index.html (consulté le 17/4/2016 à 11:30)
[16] https://www.jetbrains.com/webstorm/whatsnew/ (consulté le 17/4/2016 à 11:31)
[17] https://fr.wikipedia.org/wiki/HTML5 (consulté le 17/4/2016 à 11:26)
[18] https://www.java.com/fr/ (consulté le 17/4/2016 à 11:33)
[19] http://expressjs.com/ (consulté le 17/4/2016 à 11:34)
[20] https://angularjs.org/ (consulté le 17/4/2016 à 11:26)
[21] https://www.mongodb.org/ (consulté le 17/4/2016 à 11:35)
[22] https://fr.wikipedia.org/wiki/Extensible_Markup_Language (consulté le 17/4/2016
à 11:35)
[23] https://fr.wikipedia.org/wiki/JavaScript_Object_Notation (consulté le 17/4/2016 à
11:37)
[24] http://mongoosejs.com/ (consulté le 17/4/2016 à 11:37)
[25] https://www.sqlite.org/ (consulté le 17/4/2016 à 11:37)