:

Zero Reporting

MINISTERE DE LEDUCATION,
DE LA JEUNESSE ET DES SPORTS
INSTITUT DE TECHNOLOGIE DU CAMBODGE

DEPARTEMENT GENIE INFORMATIQUE ET COMMUNICATION

MEMOIRE DE FIN DETUDES

Titre

Systme de Gestion du Rapport des Maladies Zero Reporting

Etudiante

Mlle. ENG Thyda

Spcialit

Informatique et Communication

Matre de stage :

M. HAO Jeudi

Anne scolaire :

2013 2014

: .............

_____________________
_
____

: Zero Reporting
: InSTEDD iLab Southeast Asia iLabSEA

MINISTERE DE LEDUCATION
DE LA JEUNESSE ET DES SPORTS
INSTITUT DE TECHNOLOGIE DU CAMBODGE
DEPARTEMENT GENIE INFORMATIQUE ET COMMUNICATION

MEMOIRE DE FIN DETUDES

DE Mlle. ENG Thyda

Date de soutenance : le 30 juin 2014

Autorise la soutenance du mmoire

Directeur de lInstitut : Dr. OM Romny

Phnom Penh, le

Titre

2014

: Systme de Gestion du Rapport des Maladies

Zero Reporting

Etablissement du Stage : InSTEDD iLab Southeast Asia

iLabSEA

Chef du dpartement

M. LAY Heng

Professeur encadrant du projet

M. HAO Jeudi

Responsable dans ltablissement

M. RUM Sokha

PHNOM PENH

REMERCIEMENTS
Premirement, je tiendrais exprimer tout particulirement mes reconnaissances et ma profonde
gratitude toutes les personnes qui mont aid et mont conseille pendant le stage comme :
Son Excellence Mme. PHOEURNG Sackona, secrtaire dEtat du Ministre de lEducation, de la
Jeunesse et des Sports et prsidente du Conseil dAdministration de linstitut de technologie du
Cambodge, pour ses efforts considrables qui contribuent davantage au dveloppement durable de
lITC et qui font de lITC un ple technologique reconnu pour sa qualit de formation lchelle
nationale, rgionale et internationale.
Son Excellence Dr. OM Romny, directeur de lITC pour sa bonne gestion de linstitut et ses
bonnes cooprations avec les universits partenaires au niveau local, rgional et international qui
renforce la qualit de la formation des ingnieurs et des techniciens suprieurs.

M. LAY Heng, chef du dpartement Gnie Informatique et Communication, et M. SENG

Sopheap, ancien chef du dpartement Gnie Informatique et Communication, pour ses bonne
gestion et ses fait partie intgrante de lenseignement.
M. HAO Jeudi, mon matre de stage, de mavoir expliqu des techniques permettant deffectuer
mon stage. Je le salue galement pour ses remarques et corrections qui ont permis l'laboration de
ce rapport.

M. RUM Sokha, mon tuteur de stage, de m'avoir donn toujours des conseils trs prcieux pour
rsoudre des problmes pendant les trois mois de stage. Merci les employes de InSTEDD qui
aident et conseillent toujours de moi.
Merci tous les enseignants de gnie information et communication lITC de me transmettre des
connaissances trs prcieuses pendant mes tudes.

Finalement, je voudrais exprimer spcialement ma reconnaissance mes parents pour me donner le

support financire, lencouragement et la motivation.

RESUME
Le stage est effectu pendant trois mois partir du 10 fvrier jusquau 09 aot 2014 InSTEDD.
Le projet de stage porte sur Gestion du rapport des maladies, Zero Reporting. Ce projet concerne
la visualisation des donnes communiques sur les maladies infectieuses des centres de sant.
L'objectif de ce projet, il nous aider obtenir des informations sur les maladies infectieuses
rapidement et tre prts les prvenir.

Pour dvelopper cette application, nous avons utilis Ruby on Rail, car il est conu pour rendre les
applications Web de programmation plus facile, avec d'autres technologies telles que: Google
Visualization, AJAX, JQuery, CSS et Twitter Bootstrap.

ABSTRACT
The internship is taken place at InSTEDD during three months, starting from February the 10th
until May the 09th 2014. During this internship I was assigned to develop a web application for
manage the report of infectious diseases, which called Zero Reporting. This project concerns on
the visualization of reported data about infectious diseases from any health centers. The objective
of this project it help us to get the information about the infectious diseases quickly and be ready to
prevent them.

To develop this application, we have used Ruby on Rail, since it is designed to make programming
web applications easier by making assumptions about what every developer needs to get started,
with some other technologies such as: Google Visualization, AJAX, JQuery, Css and Twitter
Bootstrap.

II

CONTENTS
REMERCIEMENTS .......................................................................................................................... I
RESUME ........................................................................................................................................... II
ABSTRACT ...................................................................................................................................... II
LISTE DES ILLUSTRATIONS .................................................................................................... III
LISTE DES TABLEAUX ............................................................................................................... IV
LISTE DES ABBREVIATIONS ..................................................................................................... V
I. Prsentation Gnrale .................................................................................................................... 1
1. Prsentation du stage ............................................................................................................... 1
2. Prsentation de lentreprise ..................................................................................................... 1
2.1

Introduction lentreprise ........................................................................................... 1

2.2

Activit et services de lentreprise .............................................................................. 2

2.3

Situation gographique et contact ............................................................................... 2

II. Prsentation du Projet.................................................................................................................... 3

1. Problmatique.......................................................................................................................... 3
2. Objectif .................................................................................................................................... 3
III. Analyse et Spcification des Besoins ............................................................................................ 4
1. tude des besoins .................................................................................................................... 4
1.1

Besoins fonctionnels ................................................................................................... 4

1.2

Besoins non fonctionnels ............................................................................................ 4

2. Diagramme de cas dutilisation ............................................................................................... 4

2.1

Acteurs ........................................................................................................................ 5

2.2

Spcification de chaque cas dutilisation .................................................................... 6

3. Planification ............................................................................................................................ 7
IV. Conception Detaille ....................................................................................................................... 8
1. Mthodologies de dveloppement ........................................................................................... 8
2. Technologies utilises ........................................................................................................... 10
3. Architecture du systme ........................................................................................................ 11
3.1

Architecture physique ............................................................................................... 11

3.2

Architecture logique .................................................................................................. 12

4. Conception de base de donne .............................................................................................. 13

5. Implmentation du projet ...................................................................................................... 15
5.1

Crer et traiter le rapport ........................................................................................... 15

5.2

Utiliser Google Visualisation ................................................................................. 15

5.3

Localisation ............................................................................................................... 16

5.4

Comment on teste le systme .................................................................................... 17

5.5

Rake tach ................................................................................................................. 18

V. Bilan et Conclusion ..................................................................................................................... 20

1. Bilan ...................................................................................................................................... 20
2. Difficults .............................................................................................................................. 20
3. Expriences ........................................................................................................................... 20
4. Conclusion ............................................................................................................................. 21
REFERENCES BIBLIOGRAPHIQUES ............................................................................................. i
ANNEXE ............................................................................................................................................ ii

LISTE DES ILLUSTRATIONS

Figure 1. Logo de InSTEDD ............................................................................................................ 2

Figure 2. Diagramme de case d'utilisation de Zero Reporting ......................................................... 5
Figure 3. Processus de Scrum ........................................................................................................... 8
Figure 4. Architecture physique du systme ................................................................................... 11
Figure 5. Message du tlphone ..................................................................................................... 11
Figure 6. Le message ...................................................................................................................... 12
Figure 7. Architecture logique du systme ..................................................................................... 12
Figure 8. Conception de base de donnes ....................................................................................... 13
Figure 9. Bibliothque de Google Visualisation............................................................................. 16
Figure 10. Fichier de traduction en anglais ...................................................................................... 17
Figure 11. Fichier de traduction en khmer........................................................................................ 17
Figure 12. Fichier test report ............................................................................................................ 18
Figure 13. Data Migration ................................................................................................................ 19
Figure 14. Importer des donnes ...................................................................................................... 19
Figure 15. Le lign de command ........................................................................................................ 19
Figure 16. Page de login ..................................................................................................................... ii
Figure 17. Page rapport en Khmer ...................................................................................................... ii
Figure 18. Page rapport par PHD ...................................................................................................... iii
Figure 19. Page rapport par OD ......................................................................................................... iii
Figure 20. Page rapport par HC ........................................................................................................ iii
Figure 21. Page diagramme des maladies comparaison .................................................................... iii
Figure 22. Page diagramme des maladies des centres de la sant comparaison ................................ iii
Figure 23. Page la gestion structure de sant ..................................................................................... iii
Figure 24. Page ajouter de centre de la sant ..................................................................................... iii
Figure 25. Page modifier de centre de la sant .................................................................................. iii
Figure 26. Page gestion des utilisateur .............................................................................................. iii
Figure 27. Page ajouter de l'utilisateur .............................................................................................. iii
Figure 28. Page modifier de l'utilisateur ............................................................................................ iii
Figure 29. Page modifier de mot de passe ......................................................................................... iii

III

LISTE DES TABLEAUX

Tableau 1. Planification....................................................................................................................... 7

IV

LISTE DES ABBREVIATIONS

ITC
GIC
InSTEDD
iLab
PHD
OD
HC
BD
TDD
API
HTTP

:
:
:
:
:
:
:
:
:
:
:

Institut de Technologie du Cambodge

Gnie Informatique et Communication
InSTEDD iLab Southeast Asia
Innovation Lab
Provincial Health Department
Operational District
Health Center
Base de Donns
Test Driven Developement
Application Programing Interface
HyperText Transfer Protocol

I.

Prsentation Gnrale
Cette partie parle en bref de la prsentation du stage et elle porte galement sur

lintroduction de lentreprise o mon stage a t effectu, ses activits et services, et aussi son
adresse et contact.

1.

Prsentation du stage

Obligatoirement, les tudiants en cinquime anne dans le dpartement Gnie Informatique

et Communication (GIC), doivent faire un stage de fin dtudes pendant trois mois au minimum au
deuxime semestre. Le stage peut tre fait dans un tablissement public, une organisation, ou une
entreprise prive. Lobjective du stage est non seulement de faire lintgration entre les tudes
thoriques lcole et la vie professionnelle lentreprise, mais encore de donner des grandes
opportunits aux tudiants dacqurir des nouveaux connaissances aussi que des nouvelles
technologies. la fin du stage fin dtudes, les tudiants doivent raliser un rapport et une
prsentation de ce quils ont fait.
Mon stage est ralis pendant 3 mois du 10 fvrier au 09 mai 2014 InSTEDD iLab
Southeast Asia, iLabSEA . Jai t encadr par :

Matre de stage : M. HAO Jeudi, enseignent du dpartement Gnie Informatique et

Communication

Tuteur de stage : M. RUM Sokha, chef du projet InSTEDD.

2.

Prsentation de lentreprise
2.1

Introduction lentreprise

InSTEDD est un non profit organisation sponsorise par le gouvernement amricain, cr

en 2006. Elle a install le laboratoire au Cambodge en 2007. Sa mission est damliorer la sant, la
scurit et dveloppement durable par :

Renforcement des capacits au sein des communauts pour favoriser une culture locale de
l'innovation

Cration de technologies de collaboration pour le bien social

Collaboration avec les utilisateurs finaux par le succs de design conception et le processus
de dveloppement

Assurance dutilit et l'impact grce la recherche et l'valuation

Figure 1. Logo de InSTEDD

2.2

Activit et services de lentreprise

InSTEDD se concentre sur l'amlioration de la sant, la scurit et le dveloppement grce

une combinaison de la conception centre sur l'humain, le dveloppement agile et la collaboration
intersectorielle. Il a dvelopp beaucoup de logiciel pour aide la socit comme suivante :

Geochat : un outil de collaboration qui permet de discuter, rapport et obtenir des alertes sur
leur tlphone.

Riff : un outil qui aide les groupes analyser et de visualiser de multiples streams
d'informations.

Nuntium : un outil qui permet quiconque de construire une application de messagerie

robuste et volutive.

Mesh4x : est un ensemble de bibliothques. servies et des applications qui permettent aux
donnes d'tre synchronises sur les applications multiples, des bases de donnes.

Seentags : est un service qui permet d'extraire des informations prcises partir des
rapports de texte.

Resource Map : aide les gens suivre leur travail, leurs ressources et les rsultats sur le
plan gographique dans un environnement collaboratif accessible de partout.

Reporting Wheel : est un appareil non-lectronique qui simplifie la communication des

donnes pour les travailleurs les plus recules.

Veegilo : est un outil simple qui vous aide contenir les pidmies rapidement en collectant
des informations sur les cas d'une manire simple et unifie.
2.3

Situation gographique et contact

On peut contacter InSTEDD par ladresse ci-dessous:

Adresse

Phnom Penh Center, 4th Floor Building C, Corner Preah Sihanouk

Blvd (274) & Sothearos, Khan Chamkarmon, Phnom Penh, Cambodia

Tlphone

(+855) 23 996 750

E-mail

ilabsea@instedd.org

Site Web

www.ilabsoutheastasia.org
2

II.

Prsentation du Projet
1.

Problmatique

Kean Svay Operational District est un lieu o le contrle sur les centres de sant dans
Kean Svay district. Il y a 18 centres de sant relevant de sa responsabilit. Ils habituellement
rapportent 12 infectieux cas de maladies chaque semaine OD. Avant, pour rapporter sur chaque
endroit, ils ont rapport par le radio de HVF (talkie-walkie), tlphonique, ou en papier base. Le
rapport de base peut rpandre lentement que les maladies qui pourraient causer plus contagieux et il
est coteux pour les travailleurs au niveau de la base. Autrement, les donnes pourraient perdre
facilement. Donc, InSTEDD les a aids implmenter un logiciel qui les aident rapporter
facilement et rapidement par le message du tlphone et il peut visualiser tous les donn sur
lapplication web. Cependant, cette systme ne sont pas trs efficaces et non plus dynamiques. Elle
est trs difficile utiliser et grer. Autrement, il a seulement gr sur loprationnel district Kean
Svay.

2.

Objectif

A cause des problmes ci-dessus, l'objectif principal de notre projet est d'tendre les

fonctionnalits pour grer le systme entirement, faire la meilleure visualisation des donnes et
d'amliorer l'interface pour end-user. Dans ce systme, les employes des centres de la sant
veulent voir les donnes comme la liste de rapport et aussi le diagramme. Ils veulent voir la
comparaison diagramme par les maladies et aussi par la structure de sant. En outre, ils veulent
grer la hirarchie de la structure de la sant et des utilisateurs qui sont impliqus dans ce systme.
Donc, il peut grer le rapport du centre de sant dans la diffrence de nombreux oprationnel
district. De plus, lapplication doit tre dynamique, cest--dire, les tches sont faites
automatiquement par le systme pour la facilit de lutilisateur.

III. Analyse et Spcification des Besoins

1.

tude des besoins

1.1

Besoins fonctionnels

Les besoins fonctionnels sont les besoins demands par notre chef du produit et ces sont les
fonctions qui doivent tre implmentes. Il est trs important de bien dfinir des besoins
fonctionnels car ils doivent rpondre et garantir lobjective du projet. En utilisant ces besoins et la
rfrence de lobjective du projet, on peut dfinir des besoins suivante :

Visualiser les donnes de rapports sur le web-base. Ils peuvent considrer comme
hebdomadaire, mensuelle et annuelle. L'utilisateur peut consulter le rapport que le tableau
de rapport et aussi le diagramme graphique visualisez.

Visualiser le diagramme de comparaison entre chaque centre de sant.

Visualiser la srie de points de donnes que la ligne graphique de chaque maladie dans le
centre de sant.

Gestion de la structure de sant.

Gestion des utilisateurs.

1.2

Besoins non-fonctionnels

Aprs avoir list tous les besoins fonctionnels, alors dans cette partie on va parler des
besoins non-fonctionnels. Les besoins non-fonctionnels ce sont les besoins quon dfinit pour
amliorer la performance de notre systme. Ils sont :

Localisation

: la traduction du systme dans diffrentes langues, anglais ou Khmer.

Ergonomie

: linterface graphique intressant qui est facile comprendre et utiliser.

Documentation : le rapport analyse et technique et les autres documents ncessaires.

2.

Diagramme de cas dutilisation

Le diagramme de cas dutilisation est un modle qui dcrit les besoins fonctionnels dun
systme dans le terme de cas dutilisation.

Figure 2. Diagramme de case d'utilisation de Zero Reporting

2.1

Acteurs

Aprs la capture de besoins, on trouve quil est ncessaire davoir un type dacteur :

Administrateur
Administrateur est le super-utilisateur.
Il/Elle peut faire lopration CRUD sur la gestion de lutilisateur et la structure de sant.
Il/Elle peut voir la liste de rapport qui rsume la quantit de maladies infectieux dans
chaque centre de sant par PHD.

Les utilisateurs de PHD

Ils peuvent grer les utilisateurs dans les infrieur OD ou HC.
Ils peuvent grer les infrieur OD ou HC.
Ils peuvent voir le rapport par OD et la comparaison graphique des maladies dans
chaque centre de sant qui appartient cette PHD.

Les utilisateurs dOD

Ils peuvent grer les utilisateurs dans les HC qui appartiennent cette OD.
Ils peuvent faire le CRUD sur les utilisateurs dans cette HC.
Ils peuvent voir le rapport par HC et la srie des maladies dans la ligne graphique.

Les utilisateurs de HC
Ils sont rle comme les reporters. Ils rapportent sur les cas de la maladie dans chaque
centre de sant par leur tlphone mobile au systme.
5

2.2

Spcification de chaque cas dutilisation

Gestion des utilisateurs

La gestion de l'utilisateur permet l'authentification du systme en fonction de chaque

privilge de lutilisateur. Il nous permet de crer le nouvel utilisateur, afficher, modifier, supprimer
les utilisateurs par leur privilge, et changer leur mot de passe. Chaque utilisateur appartient un
endroit, ils peuvent grer le rapport de cet endroit, leurs utilisateurs et les lieux.

Gestion de la structure de sant

Le systme est utilis pour visualiser les donnes de la structure de sant comme PHD, le

district oprationnel, et la centre de sant, donc qu'ils veulent le site qu'ils pourraient grer le
nouveau site de sant facilement.

Gestion de rapport
Le systme permet l'utilisateur de visualiser les donnes de rapports. Ils peuvent voir

comme hebdomadaire, mensuelle et annuelle. L'utilisateur peut voir le rapport que le tableau et
aussi le diagramme visualisez. Le rapport est affich par le niveau de l'utilisateur.
Les donnes de rcuprer le tlphone sera insr dans le systme.
Le rapport hebdomadaire sera affich par le mercredi jusqu'au mardi de la semaine
suivante.
Le rapport mensuel sera afficher par le premier jour du mois jusqu' la fin du mois.
Le rapport annuel sera afficher par le premier jour de l'anne jusqu' la fin de l'anne.

3.

Planification
Tche
1

Semaine
5 6 7 8 9 10 11 12

tudier des Technologies

Installer de lenvironnement de dveloppement
tudier de Keansvay OD systme

Implmenter

Gestion de la structure de sant :

CRUD
Gestion du contact de la
structure de sant: Ajouter,
Supprimer
Gestion dutilisateur : CRUD
Rapport : Visualiser le rapport
Rapport : Visualiser la
comparaison diagramme du
centre de sant
Report : Visualiser la
comparaison diagramme des
maladies du centre de sant
Stylesheet

Tableau 1. Planification

IV. Conception Detaille

1.

Mthodologies de dveloppement

Pour dvelopper une Application plus efficace, on doit avoir une mthodologie de travail.
Quand il existe beaucoup de mthodologies de dveloppement, on doit choisir un parmi eux. Pour le
projet InSTEDD, on utilise Scrum pour dvelopper toutes les Applications.

Cest quoi Scrum ?

Scrum est une mthode agile ddie la gestion de projets qui existe beaucoup des

avantages comme ci-dessous:

Le travail itratif et incrmentale
La productivit plus leve
Lamlioration engagement de l'quipe et la satisfaction du travail
La rduction du temps de mise sur le march
Concentrer sur la satisfaction du client

Figure 3. Processus de Scrum

Il y a 3 rles principaux qui participent dans le droulement de dveloppement:

Product owner (Le propritaire du produit): est le reprsentant des clients et des
utilisateurs et ce qui crit des User Stories, les priorise et les ajoute au Product Backlog. Il
sait la logique de business et les souhaits de l'utilisateur. Son objectif est de maximiser la
valeur du produit dvelopp.

Team (quipe): Celui qui est charge de distribuer le produit avec croix-fonctionnelle
comptences et qui font le travail rel (analyser, concevoir, dvelopper et tester). En plus il
doit tre l'auto-organisation et autodirig.
8

Scrum Master: Il est responsable de la mthode Scrum. Il doit s'assurer que celle-ci est
comprise, et bien mise en Application. Ce n'est pas un chef de projet, ni un intermdiaire de
communication avec les clients En tant quun facilitateur, il aide l'quipe dterminer
quelles interactions avec lextrieur sont utiles, et lesquelles sont obstacles. Il aide alors
maximiser la valeur de produit par l'quipe.
Product Backlog: cest la liste des User Stories avec la priorit qui dfinit par le

propritaire du produit.
User Story: il concentre sur le souhait dutilisateur. La forme dUser Story peut tre
diffrente de lun lautre.
Sprint Backlog: il est la liste des User Stories avec la priorit qui slectionne partir de
Product pour chaque Sprint.

Comment Scrum marche ?

Aprs avoir analys les besoins qui sont demands par le client, le propritaire de produit va

crer le Product Backlog qui contient les User Stories avec les priorits.
Daprs le Product Backlog, le Scrum Master et lquipe vont faire la runion de Sprint
pour slectionner les travaux ou bien les User Stories faire selon les priorits et les mettre dans le
Sprint Backlog avec le dtail du temps qu'il faudra pour le faire. La moyenne pour dfinir le
priode pour chaque lment (User Story) de Sprint est faite selon le planning Poker. Le planning
poker est une mthode que lquipe et le Scrum Master se discutent fin destimer le temps pour
finir chaque fonctionnalit. Normalement, le Scrum Master prfre le plus court, en revanche
lquipe veut plus que a, donc lquipe doit exprimer les raisons pourquoi a prend beaucoup de
temps.
Donc on a le Sprint Backlog qui est la liste des travaux que l'quipe doit tenir compte lors
du Sprint suivant. Aprs le Sprint Backlog est fait, lquipe doit le suivre particulirement le temps
dfinit pour chaque User Story.
Tous les jours, le Scrum Master et lquipe doit avoir une runion qui sApplicationnelle
Scrum quotidien. Scrum quotidien est une technique trs efficace de contrler pendant le
dveloppement dApplication. Pendant 15 minutes au maximum, le Scrum Master pose quelques
questions comme ces 3 questions: Quest-ce que avez-vous fait depuis hier? Quest-ce vous allez
faire aujourd'hui? Avez-vous des problmes qui vous empchent de l'accomplissement de votre
objectif ?
Ensuite, quand le temps pour le premier Sprint est atteint, le Scrum Master doit faire une
autre runion quon Applicationnelle la runion de rvision de Sprint. Ce quon doit faire dans
cette runion est de rviser le travail qui est termin et n'est pas termin et faire une dmo pour
9

valider les fonctionnalits qui ont fait. Aprs la fin de chaque Sprint on doit obligatoirement
obtenir un produit qui peut tre fait une dmo pour montrer au client lavancement du projet. Pour
le travail qui nont pas encore termin, quon a 2 possibilits: on peut mettre a dans le Sprint
suivant sils sont les fonctionnalits principales ou bien on peut refaire a aprs on a termin les
autres.

2.

Technologies utilises

Cette partie parle de la technologie que lon a utilise pour raliser notre projet. Elle porte
aussi sur les langages et les outils qui aident au dveloppement de lapplication. Pour dvelopper
cet outil, nous avons utilis Ruby on Rail.

Rail 3.2.3 : Il sagit dun cadre de dveloppement dapplications web crites dans le
langage Ruby. Il est conu pour rendre la programmation dapplications Web plus facile en
faisant des hypothses sur ce que chaque dveloppeur doit commencer. Il vous permet
dcrire moins de code tout en accomplissant plus de nombreuses autres langues et des
cadres.

Ruby 1.9.2 : Ruby est une dynamique et open source langage en mettant laccent sur la
simplicit et la productivit. Il a la lgante syntaxe qui est naturel lire et facile crire.

Google Visualization : Il est un outil graphique de Google pour l'affichage graphique de

l'application Web. C'est gratuit et facile utiliser.

Twitter Bootstrap 2.3.2 : Il est lgant puissant et intuitif cadre frontal, pour le
dveloppement web rapide et plus facile sensible.

JQuery : une bibliothque libre de JavaScript, dont la syntaxe est trs courte et dont les
noms des fonctions sont intuitifs.

Ajax (Asynchronous JavaScript and XML) : en effet la technologie web entire est base
sur le modle de laller-retour nous utilisons lAjax dans le systme qui peut rcuprer des
donnes par une requte serveur rapide.-

JavaScript : sutilise dans le contexte du web principalement travers dun navigateur

internet. Il permet lexcution de code information intgr a des pages web et il est un des
outils permettant de dvelopper du web dynamique .

CSS (Cascading Style Sheets) : un langage qui permet de dcrire la prsentation de

documents structure en format HTML et dans un langage dapplication XML. Avec
laquelle, nous pouvons crer la feuille de style qui fournit la solution pour le dveloppeur de
la manier simple a utilisateur son style qui peut sparer la logique applicative de la
prsentation.

HTML (Hyper Text Mark up Language) : un langage de base pour crer la page web.
10

Postgresql : est un systme de gestion de base de donnes relationnelle et objet SGBD.

C'est un outil libre.

3.

Architecture du systme
3.1

Architecture physique

Larchitecture physique donne lide globale comment le systme fonctionne et elle

prsente les composants physiques participant.

Figure 4. Architecture physique du systme

Zero Reporting est une sorte de systme du rapport qui utilise le tlphone mobile sms. Le
sms transmet travers deux systmes, GeoChat et Reporting Wheel, avant de pousser Zero
Reporting. Le sms a t diffuse un groupe de numro de tlphone et aussi envoye au serveur
et ils pourraient galement voir le rapport sur Web-base. Le rapport est lanc depuis le tlphone
l'envoi de SMS avec le format cod comme un exemple dans l'image:

Figure 5. Message du tlphone

11

Les emploes de sant utilisent Reporting Wheel pour voir le code de la maladie et de la
quantit, donc le sms est cod avec le code de Wheel et l'envoyer systme appel GeoChat.
GeoChat est un outil de collaboration qui permet quiconque de discuter, rapport et obtenir des
alertes sur leur tlphone. GeoChat va pousser le message cod un autre systme appel
Reporting Wheel. Reporting Wheel dcode le code de SMS et transfre le SMS la fin du
point, Zero Reporting par la requte de poste.

Figure 6. Le message

Zero Reporting rcupr les donnes, et stocke dans la base de donnes et, en fin,
l'administrateur de la structure de sant pourrait voir le rapport sur le navigateur Web.
3.2

Architecture logique

Ruby on Rails utilise le Modle-Vue-Contrleur (MVC). Le modle centralise le logique

mtier; La vue gre la logique d'affichage, alors que le contrleur traite des flux d'application. Le
MVC permet une sparation claire des proccupations, dans la faon dont il conserve le logique
mtier spar de vue HTML. En outre, il amliore le dcouplage et d'essais.

Figure 7. Architecture logique du systme

12

Modle
La couche du modle porte le logique mtier de l'application et les rgles pour manipuler les

donnes. En Ruby on Rails, les modles sont utiliss pour grer l'interaction avec leurs lments
correspondants dans la base de donnes. Les modles reprsentent les informations dans la base de
donnes et faire les validations appropries.

Vue
Le vue est le front-end de l'application, soit de l'interface utilisateur. En Ruby on Rails, vues

sont des fichiers HTML avec le code Ruby embarqu. Le code Ruby embarqu dans les HTMLs est
assez simple (boucles et instructions conditionnelles). Elle n'est utilise que pour afficher des
donnes l'utilisateur sous la forme de vues. Les vues sont utilises pour fournir les donnes aux
navigateurs qui ont demand les pages web. Vues pouvez contenu du serveur dans plusieurs
formats, tels que HTML, PDF, XML, RSS et plus.

Contrleur
Contrleurs d'interagir avec des modles et des points de vue. Les demandes reues partir

des navigateurs sont traits par les contrleurs, qui traitent les donnes des modles et passer la
vue de prsentation.

4.

Conception de base de donne

Cette partie vous prsente la conception de la base de donnes et la figure suivante indique
le diagramme de Modle Conception de Donnes de notre base de donnes. Ce diagramme est
dvelopp par logiciel de BD-main qui nous permet de savoir la relation en les tables ou entits.

Figure 8. Conception de base de donnes

13

tbl_place
Le tbl_place est utilis pour stocker les informations de la sant structure qui fournit les

informations relevant du systme. La hirarchie de la structure de sant est organise en 3 niveaux :

PHD : il est le parent dOD.
OD: elle est le parent de HC.
HC : Le rapport sera somme par chaque centre de sant, HC et envoyer via le tlphone
le systme.
Les champs de cette table sont numrs ci-dessous :
id : il est utilis pour stocker la cl identifi pour chaque lieu.
name : il est utilis pour stocker le nom de l'endroit.
parent_id : il est utilis pour stocker le parent lieu id.
type : il est utilis pour stocker le type de lieu.
created_at : il est utilis pour stocker la date de l'enregistrement est insr.
updated_at : il est utilis pour stocker la date laquelle le dossier est mis jour.

tbl_user
Le tbl_user est utilis pour stocker les informations de l'utilisateur qui sont s'authentifier

pour utiliser le systme. Ce tableau se compose du champ suivant :

id : il est la cl d'identifier pour chaque utilisateur.
name : il est utilis pour stocker le nom d'utilisateur pour chaque utilisateur qui utilise
pour se connecter au systme.
password : il est utilis pour stocker le mot de passe de connexion pour chaque
utilisateur.
can_login : il est utilis pour stocker l'tat de connexion
level : il est utilis pour stocker le niveau de utilisateur
created_at : il est utilis pour stocker la date de l'enregistrement est insr.
updated_at : il est utilis pour stocker la date laquelle le dossier est mis jour.

tbl_contact
Le tbl_contact est utilis pour stocker les informations de contact sur chaque centre de

sant. Chaque centre de sant a plus d'un numro de tlphone qui sont en mesure d'envoyer le
rapport au systme.
id : il est la cl pour identifier les contacts de chaque lieu.
telephone_number : il est utilis pour stocker le numro de tlphone.
place_id : il est utilis pour stocker l'id de l'endroit.
created_at : il est utilis pour stocker la date de l'enregistrement est insr.
updated_at : il est utilis pour stocker la date laquelle le dossier est mis jour.
14

tbl_report
Le tbl_report est utilis pour stocker le rapport rcuprer partir du tlphone. Le rapport

est identifi par le champ ci-dessous:

id : il est la cl d'identifier pour chaque rapport.
sender : il est utilis pour stocker le nom de l'expditeur du rapport.
disease : il est utilis pour stocker le nom de la maladie.
quantity : elle est utilise pour stocker la quantit de la maladie dclare.
from : il est utilis pour stocker le numro de tlphone de l'expditeur.
to : il est utilis pour stocker le numro de tlphone de larrt
lat: il est utilis pour stocker la latitude des lieux signals.
lan : il est utilis pour stocker la longitude des lieux signals.
user_id : il est utilis pour stocker le user_id signal.
place_id : elle est utilise pour stocker le place_id rapport.
created_at : il est utilis pour stocker la date de l'enregistrement est insr.

5.

Implmentation du projet

Cette partie prsente toutes les techniques dimplmentation aprs avoir trouv des
solutions qui permettent de rsoudre les problmes. On ne prsente que les parties importantes du
systme et limplmentation des composants de larchitecture logique.
5.1

Crer et traiter le rapport

Le personnel des centres de sant envoient le rapport que le sms avec leur tlphone mobile.
Le sms est configur avec le Geochat et Reporting Wheel. Parmi ces donnes vont enfin pousser
Zero Reporting. Chaque fois que le systme rcupre les donnes, il vrifie dans la semaine de
donnes si ce cas signals a dj exist ou pas encore. Si le cas rapport est dj indiqu dans la
semaine, il mettra jour ce cas rapports avec le nouveau numro de la maladie infectieuse. Sinon,
il va insrer ce cas signal que le nouvel enregistrement dans le systme. Toutefois, si le dossier est
envoy avec la cl de No Disease, alors tous les cas dclars de ce centre de sant au cours de
cette semaine seront mis '0 '.
5.2

Utiliser Google Visualisation

Google Graphiques fournit un moyen idal pour visualiser des donnes de votre site. De
graphiques simples en ligne aux cartes hirarchiques complexes d'arbres, la galerie de tableau
fournit un grand nombre de types de graphiques prts l'emploi.
Le moyen le plus courant d'utiliser Google Chart est avec JavaScript simple que vous
incorporez dans votre page. Vous chargez des bibliothques de Google Chart, les donnes tre
cartographis, slectionnez les options pour personnaliser votre thme, et enfin de crer un objet
15

graphique avec un id que vous choisissez. Puis, plus tard dans la page, vous crez un <div> avec
cet identifiant pour afficher le graphique de Google.
Un Chart ncessite trois bibliothques:

L'API Google JSAPI

La bibliothque de visualisation de Google

La bibliothque de la carte elle-mme

Ces bibliothques sont charges l'aide de deux liens <script> dans le code de votre page,

comme indiqu ici:

La premire balise script charge la bibliothque JSAPI.

Le deuxime script charge la visualisation de Google et les bibliothques de tableau.

Toutes les cartes ont besoin de donnes. Google Outils de graphique graphiques ont besoin

de donnes pour tre envelopp dans une classe JavaScript appel google.visualization.DataTable.

Figure 9. Bibliothque de Google Visualisation

5.3

Localisation

Une des caractristiques raliser dans ce projet est la localisation. La localisation, cest le
processus de la traduction. I18n est la solution de l'internationalisation par dfaut pour Ruby on
Rails. I18n fournit un cadre facile utiliser et extensible pour la traduction de votre application
une seule langue personnalise autre que l'anglais ou de fournir un soutien multi-langue dans
l'application. Rails ajoute tous les fichiers. Yml de la config / locales rpertoire de chemin
traductions de charge, automatiquement. Voici les tapes faire la localisation dans Rail:

Installer la bibliothque de gem si elle ne l'installe pas par le dfaut de Rails

Configurer la bibliothque I18n o il peut trouver les fichiers de traduction personnalis,

vous pouvez spcifier le chemin de charge partout dans l'application - assurez-vous qu'il soit
lanc avant que les traductions sont effectivement lev les yeux. Si nous voulons changer la
langue par dfaut, la chose la plus simple possible est de mettre le texte suivant dans un
initialiseur:
16

Crer fichier yml, les fichiers YAML sont utiliss pour stocker les traductions SimpleStore.

Figure 10. Fichier de traduction en anglais

Figure 11. Fichier de traduction en khmer

5.4

Comment on teste le systme

Rails rend trs facile crire vos tests. Il commence par la production de code de test de
squelette pendant que vous crez vos modles et contrleur. Rails utilise une bibliothque de spec
rspec-rails pour TDD. Test-Driven Development (TDD) est une faon de conduire la
conception de code en crivant un essai qui exprime ce que vous avez l'intention de faire le code, ce
qui passe de test, et la refactorisation continue garder le design aussi simple que possible. TDD
peut s'appliquer plusieurs niveaux, par exemple, des essais de clients, Tests d'intgration, tests
unitaires.
17

Figure 12. Fichier test report

5.5

Rake tach

Rake est Ruby Make, un utilitaire Ruby autonome qui remplace l'utilitaire Unix 'make', et
utilise un Rakefile et .Rake fichiers pour crer une liste de tches. Dans Rails, Rake est utilis
pour les tches d'administration courantes, en particulier les plus sophistiqus qui construisent hors
de l'autre. Vous pouvez obtenir une liste de tches Rake disponibles pour vous, qui dpendra
souvent de votre rpertoire courant, en tapant rake tches. Chaque tche a une description, et
devrait vous aider trouver la chose que vous devez.
Dans cette application on a implment un rake tche rake db :data_migration pour
migr les donnes dans la systme prcdant au nouvel systme. La migration tche lit les donnes
dans le ancien BD, manipuler et insrer dans la nouvel BD selon le nouvel structure de BD.
Finalement on peut migrer des donnes par le ligne de commande rake db :data_migration .

18

Figure 13. Data Migration

Figure 14. Importer des donnes

Figure 15. Le lign de command

19

V.

Bilan et Conclusion
Dans cette partie, elle vous prsente le rsum de la ralisation du projet avec le bilan . Il

sagit aussi dexprimer les expriences quon a obtenu pendant le stage, les difficults rencontrs et
dernire est la perspective. Ce projet est considr comme succs, puisque toutes les tches et
fonctionnalits de base sont ralises. Toutefois, lapplication a encore des points qui sont obligs
d'amliorer et de modifier pour tre parfait.

1.

Bilan

Ce projet est considr comme succs, puisque toutes les tches et fonctionnalits de base
sont ralises. Toutefois, lapplication a encore des points qui sont obligs d'amliorer et de
modifier pour tre parfait. On espre quand mme que cette application peut totalement aider les
employes de la sant grer plus facilement du rapport des maladies. Maintenant, on va faire le
bilan de la ralisation du projet qui vous montre dans la liste de travail ralis :

Visualiser le rapport

Gestion des utilisateurs

Gestion de la structure de sant

Localisation

Amlioration de linterface

2.

Difficults

En vrit, cest normal que le dveloppeur toujours rencontre avec les points difficiles
pendant le processus de dveloppement. a mest gal, jai eu aussi la confrontation avec les
difficults pendant mon travail. Quelques problmes sont mineur mais quelques sont grandes et je
dois trouver les solutions appropris pour les rsoudre. Parmi tous, jai confront deux problmes
qui sont les plus graves. Le premier est que je ne jamais travaill avec Ruby on Rail. Bien que ce
framework soit facile apprendre, il a pros de temps pour tudier toutes ses fonctionnalits et sa
structure. Le deuxime est la migration de systme prcdant nouvel systme comme elle a
beaucoup des donnes exist.

3.

Expriences

Tout l'accomplissement j'ai rencontr avec ces difficults mentionnes ci-dessus me fournir
beaucoup d'expriences prcieuses comptences lis l'informatique ainsi que la socit de travail.
De plus, je peux appliquer la thorie dans la pratique relle, sais comment faire face aux problmes
et comment bien travailler en quipe. Plus important encore, je reois plus de connaissances sur le
dveloppement Web, en utilisant Ruby on Rail et les outils techniques qui utiliss dans
l'environnement de travail.
20

4.

Conclusion

Dans l'ensemble, je pourrais dire que j'ai grandi plus mature pour tre prt pour tous les
dfis dans ce domaine grce cette opportunit inestimable. En fait, j'ai rencontr plus de
problmes que de bonnes choses au cours de ce stage, mais ces problmes m'apprendre beaucoup la
faon de surmonter mes faiblesses, problmes et amliorer mes comptences pour obtenir le
succs dans l'avenir. Ce stage est trs utile pour tous les lves, car il est une tape pour nous de
construire notre premire exprience professionnelle et personnelle.

21

REFERENCES BIBLIOGRAPHIQUES
Livres (Ressources de Ruby on Rails)

Michael Hartl (2010), Ruby on Rails Tutorial, Learn Rails by Example, MIT
License

Dave Thomas (2013), Programming Ruby 1.9 & 2.0, LLC License

Internet

Ruby on Rails Getting Started

https://www.ruby-lang.org/en/documentation/quickstart/
guides.rubyonrails.org/getting_started.html

Ruby Gem Library

https://rubygems.org/

Ruby on Rails Screencasts

http://railscasts.com/

Twitter Bootstrap 2.3.2

http://getbootstrap.com/2.3.2/

Google Visualization
https://developers.google.com/chart/interactive/docs/reference

Forum
stackoverflow.com
https://www.ruby-forum.com/

InSTEDD information
http://instedd.org/

ANNEXE

Figure 16. Page de login

Figure 17. Page rapport en Khmer

ii

Figure 18. Page rapport par PHD

Figure 19. Page rapport par OD

iii

Figure 20. Page rapport par HC

Figure 21. Page diagramme des maladies comparaison

iv

Figure 22. Page diagramme des maladies des centres de la sant comparaison

Figure 23. Page la gestion structure de sant

Figure 24. Page ajouter de centre de la sant

Figure 25. Page modifier de centre de la sant

vi

Figure 26. Page gestion des utilisateur

Figure 27. Page ajouter de l'utilisateur

vii

Figure 28. Page modifier de l'utilisateur

Figure 29. Page modifier de mot de passe

viii