› ... › final_report_4th_progress_final.docx · web viewpage of approval - flipkarma.comin...

PAGE OF APPROVAL

TRIBHUVAN UNIVERSITYInstitute of Engineering

PULCHOWK CAMPUSLALITPUR, NEPAL

AFINAL YEAR PROJECT REPORT

ON“SMS based communication for eWIN system of UN

WFP in disaster situations”

CODE: CT755

Submitted by:

Abhishes Bikram Bhandari (16203)Gautam Acharya (16215)Sabin Bhandari (16247)

A PROJECT SUBMITTED TO THE DEPARTMENT OF ELECTRONICS AND COMPUTER ENGINEERING IN PARTIAL FULLFILMENT OF THE REQUIREMENT

FOR THE BACHELOR’S DEGREE IN COMPUTER ENGINEERING

DEPARTMENT OF ELECTRONICS AND COMPUTER ENGINNERINGLALITPUR, NEPAL

August 2013

PAGE OF APPROVAL

TRIBHUVAN UNIVERSITY

INSTITUTE OF ENGINEERING

PULCHOWK CAMPUS

DEPARTMENT OF ELECTRONICS AND COMPUTER ENGINEERING

The undersigned certify that they have read and recommended to the Institute of

Engineering for acceptance, a project report entitled “SMS based communication for

eWIN system of UNWFP in disaster situations” submitted by Abhishes Bikram Bhandari,

Gautam Acharya, Sabin Bhandari in partial fulfilment of the requirements for the

Bachelor’s degree in Computer Engineering.

_________________________________________________ Supervisor: Dr. Aman Shakya Deputy Head of Department Department of Electronics and Computer Engineering, Pulchowk Campus

__________________________________________________ Co-Supervisor: Abesh KCInformation Security OfficerFood Security Monitoring and Analysis Unit (FSMAU), UNWFP

______________________________________________________ Internal Examiner: Dr. Sanjeeb Prasad PandeyLecturerDepartment of Electronics and Computer Engineering, Pulchowk Campus

______________________________________________________ External Examiner: Ram Dutta BhattaIT OfficerDepartment of Customs, Nepal

DATE OF APPROVAL:

ii

PAGE OF APPROVAL

COPYRIGHT

The author has agreed that the Library, Department of Electronics and Computer

Engineering, Pulchowk Campus, Institute of Engineering may make this report freely

available for inspection. Moreover, the author has agreed that permission for extensive

copying of this project report for scholarly purpose may be granted by the supervisors who

supervised the project work recorded herein or, in their absence, by the Head of the

Department wherein the project report was done. It is understood that the recognition will

be given to the author of this report and to the Department of Electronics and Computer

Engineering, Pulchowk Campus, Institute of Engineering in any use of the material of this

project report. Copying or publication or the other use of this report for financial gain

without approval of to the Department of Electronics and Computer Engineering,

Pulchowk Campus, Institute of Engineering and authors written permission is prohibited.

Request for permission to copy or to make any other use of the material in this report in

whole or in part should be addressed to:

Dr. Arun K. Timalsina

Head of Department

Department of Electronics and Computer Engineering

Pulchowk Campus, Institute of Engineering

Lalitpur, Kathmandu

Nepal

iii

PAGE OF APPROVAL

ACKNOWLEDGEMENT

We take this opportunity to express our profound gratitude and deep regards to our project

supervisor, Dr. Aman Shakya for his exemplary guidance, monitoring and constant

encouragement throughout the course of this project.

We also would like to express a deep sense of gratitude to Mr. Abesh KC of UNWFP, for

his cordial support, valuable information and guidance, which helped us in completing the

tasks through various stages. We would also like to thank UNWFP, as a whole, for

providing us with volunteer contract and an office space to work on our project.

We are obliged to Mr. Sushil Gopal Parajuli and Mr. Ranjan Shrestha of Nepasoft

Solutions, for the valuable information provided by him related to this project. We are

really grateful for his cooperation during the project.

We would also like to thank Mr. Dhruba K Adhikari and Mr Arvind Sah of JanakiTech

Pvt. Ltd., for assisting in our project by providing us with API to access Sparrow SMS

Gateway, without which the project wouldn’t have been a success.

We are also indebted to Phunka Technologies for providing us with server space for

hosting our project as well as handling the technical issues that incurred during the whole

process. Lastly, we would like to thank all our friends and seniors for their constant

encouragement and support.

iv

PAGE OF APPROVAL

ABSTRACT

UNWFP aims to develop a comprehensive platform to collect, process, analyze and

disseminate field based information. Currently, the UNWFP in Nepal employs a system

called eWIN for the same. However, as of now, the backbone of information

communication for the eWIN system is solely, the Internet. As information communication

is central to the overall operation of the eWIN system, the lack of access to the Internet

either due to disaster or remoteness of the area would inevitably, turn the system

dysfunctional. In order to fulfil the need of information communication in an Internet-

deprived environment, a viable option or medium would be mobile telecommunication

infrastructure, more specifically, SMS.

In short, in this project, the use of SMS for information communication has been

implemented to assist the existing eWIN system. In order to achieve this, first of all, the

existing eWIN system (eWIN server and eWIN tablet client) is studied, then following the

client-server model, a new system called eWIN SMS (eWIN SMS server and eWIN SMS

tablet client) is developed. Finally, the newly developed eWIN SMS system is made to

work in tandem with the existing eWIN system, with Internet as the primary

communication channel, and SMS as the secondary.

It is critical for the readers to understand that this project has some degree of dependency

on the existing eWIN system, and it is subject to integration with the existing eWIN system

eventually. Also, the readers cannot afford to mistake the project for an out-an-out disaster

management tool of any shape, kind or form; because the project, itself is only an

information communication and management system and the term, “disaster” is a mere

motivation for the quick and swift collection of critical information that led to the

conception of the project in the first place.

v

PAGE OF APPROVAL

Keywords: eWIN, SMS, disaster, information collection, visualization

vi

PAGE OF APPROVAL

TABLE OF CONTENTS

COPYRIGHT........................................................................................................................iiiACKNOWLEDGEMENT....................................................................................................ivABSTRACT...........................................................................................................................vLIST OF TABLES..............................................................................................................viiiLIST OF FIGURES..............................................................................................................ixLIST OF ABBREVIATIONS...............................................................................................xi1 INTRODUCTION..........................................................................................................2

1.1 Background..............................................................................................................21.2 Statement of Problem..............................................................................................31.3 Objectives................................................................................................................41.4 Scope of the Project.................................................................................................5

2 BACKGROUND STUDY..............................................................................................72.1 eWIN Information Management System.................................................................7

2.1.1 eWIN Features:................................................................................................83 LITERATURE REVIEW.............................................................................................10

3.1 Introduction...........................................................................................................103.2 SMS-based Information Transfer System.............................................................10

3.2.1 Alert DC.........................................................................................................103.2.2 RapidSMS......................................................................................................11

3.3 Disaster Management System...............................................................................113.3.1 Syria Food distribution using SMS................................................................113.3.2 Sahana............................................................................................................11

3.4 Visualization System.............................................................................................123.4.1 Ushahidi.........................................................................................................123.4.2 StatSilk...........................................................................................................12

4 REQUIREMENT ANALYSIS AND SPECIFICATION.............................................144.1 High Level Requirements......................................................................................14

4.1.1 Features and modules.....................................................................................154.2 Functional Requirements.......................................................................................16

5 METHODOLOGY.......................................................................................................245.1 Project Implementation Methodologies................................................................24

5.1.1 SMS communication to and from the Web server.........................................255.1.2 SMS formation and transfer from Tablet Application...................................265.1.3 Incident Reporting From data retrieval using Mobile Device........................285.1.4 Disaster Data Collection from Public............................................................295.1.5 SMS parsing...................................................................................................30

PAGE OF APPROVAL

5.1.6 Mapping the SMS format to XML format.....................................................305.1.7 Disaster Visualization....................................................................................31

5.2 Project Schedule....................................................................................................336 SYSTEM DESIGN.......................................................................................................35

6.1 System Architecture..............................................................................................356.2 Deployment Diagram............................................................................................376.3 Data Flow Diagram...............................................................................................386.4 Class Diagram.......................................................................................................396.5 Tools and Frameworks Used.................................................................................43

7 OUTPUT.......................................................................................................................457.1 eWIN SMS Client Application..............................................................................457.2 eWIN SMS Server.................................................................................................47

8 SYSTEM EVALUATION, ANALYSIS AND TESTING..........................................508.1 Testing Methodology.............................................................................................50

8.1.1 Exploratory Testing........................................................................................508.2 Test Cases..............................................................................................................51

8.2.1 Functionality and System Tests.....................................................................518.2.2 Stress Tests.....................................................................................................528.2.3 Location Identification Tests..........................................................................52

8.3 Test Results...........................................................................................................538.4 Test Environment..................................................................................................54

9 CONCLUSION.............................................................................................................5610 LIMITATIONS AND FUTURE WORK.....................................................................58REFERENCES.......................................................................................................................IAPPENDIX A: DATA FLOW DIAGRAMS......................................................................IIIAPPENDIX B: SPARROW SMS DOCUMENTATION.....................................................VAPPENDIX C: EWIN SYSTEM DIAGRAMS AND SNAPSHOTS.................................IXAPPENDIX D: PROTOCOLS............................................................................................XIAPPENDIX E: EWIN QUESTIONNAIRE AND ANSWER XML DESCRIPTION.....XIIIAPPENDIX F: GSMCOMM LIBRARY...........................................................................XX

LIST OF TABLES

Table 1: Specification of actor – UNWFP Field Monitor....................................................17Table 2: Specification of actor – eWIN Server....................................................................17Table 3: Specification of actor – eWIN SMS Server...........................................................17Table 4: Specification of Use Case – Transfer information via SMS..................................18Table 5: Specification of Use Case – Log into the system...................................................18Table 6: Specification of Use Case – Update.......................................................................18Table 7: Specification of Use Case – Delete........................................................................19Table 8: Specification of Actor – Administrator..................................................................20Table 9: Specification of Actor – eWIN Server...................................................................20Table 10: Specification of Actor – eWIN SMS Server........................................................20Table 11: Specification of Use Case – Receive text message..............................................21Table 12: Specification of Use Case – Fetch Questionnaire XML......................................21Table 13: Specification of Use Case – Create hash table.....................................................21Table 14: Specification of Use Case – Generate and send answer XML file......................22Table 15: Specification of Use Case – View transfer history and info-graphics.................22Table 16: Specification of Use Case – Log into the system.................................................22Table 17: Brief description of classes used in Application Server......................................40Table 18: Brief description of classes used in Tablet Application.......................................42Table 19: Result of Answer XML generation test...............................................................53Table 20: Result of Webpage Loading without Mapping Elements....................................53Table 21: Result of Webpage Loading with External Elements..........................................54Table 22: Environment Details............................................................................................54Table 23: Matrix Type of Questionnaire............................................................................XV

9

LIST OF FIGURES

Figure 1: eWIN Top Level Architecture................................................................................7Figure 2: eWIN SMS Server simple block diagram............................................................14Figure 3: eWIN SMS Client simple block diagram.............................................................14Figure 4: Use Case Scenario for eWIN SMS Client............................................................16Figure 5: Use Case Scenario for eWIN SMS Server...........................................................19Figure 6: Overall System Block Diagram............................................................................24Figure 7: Steps for SMS communication to and from the Web server................................25Figure 8: Implementation of Incoming SMS API................................................................25Figure 9: Implementation of Outgoing SMS API................................................................26Figure 10: Steps to form and send SMS from Tablet Application.......................................27Figure 11: Steps employed to obtain incident data using Mobile Device............................28Figure 12: Steps employed to obtain disaster data from Public...........................................29Figure 13: Steps to parse SMS message before sending from tablet application................30Figure 14: Steps to parse SMS message after received in server.........................................30Figure 15: Steps to map SMS message to XML..................................................................31Figure 16: Steps to visualize disaster data into Map of Nepal.............................................32Figure 17: Works Completed GANTT Chart.......................................................................33Figure 18: Works Remaining GANTT Chart.......................................................................33Figure 19: System Block Diagram.......................................................................................35Figure 20: Deployment Diagram.........................................................................................37Figure 21: Context Level DFD for Tablet Application........................................................38Figure 22: Context Level DFD for Application Server.......................................................38Figure 23: eWIN SMS Server Class Diagram.....................................................................39Figure 24: eWIN SMS Client Class Diagram......................................................................41Figure 25: Tablet Application Login Interface....................................................................45Figure 26: GUI Showing Unsynchronized Records.............................................................45Figure 27: GUI after ID ‘33257457602’ has been sent as SMS..........................................46Figure 28: Refreshed GUI after SMS has been sent............................................................46Figure 29: Login Interface of Application Server................................................................47Figure 30: Index Page of Application Server.......................................................................47Figure 31: ‘WFP Incident Reporting Form’ Interview Details............................................48Figure 32: Disaster Visualization.........................................................................................48Figure 33: Disaster Details...................................................................................................48Figure 34: Exploratory Testing............................................................................................50Figure 35: Application Server DFD Level-0.......................................................................III

10

Figure 36: Tablet Application DFD Level-0.......................................................................IVFigure 37: eWIN Logo.........................................................................................................IXFigure 38: eWIN Deployment Architecture.........................................................................IXFigure 39: eWIN Home Screen.............................................................................................XFigure 40: eWIN Tablet Application Home Page.................................................................XFigure 41: Web Service Documentation for Validating a User using HTTP GET............XIIFigure 42: Web Service Documentation for getting Questionnaires List using HTTP GET............................................................................................................................................XIIFigure 43: Web Service Documentation for Questionnaire XML retrieval using HTTP GET....................................................................................................................................XIIFigure 44: Questionnaire “PRRO Refugees Food Basket Monitoring Counter Monitoring”...........................................................................................................................................XIIIFigure 45: Questionnaire XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring”.......................................................................................................................XIVFigure 46: Answer XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring”........................................................................................................................XVFigure 47: Sample Questionnaire “IOE_Sample”............................................................XVIFigure 48: XML for Sample Questionnaire “IOE_Sample”............................................XVIIFigure 49: Answer XML for Sample Questionnaire “IOE_Sample”.............................XVIIIFigure 50: Questionnaire “UNWFP Incident Reporting Form”.....................................XVIIIFigure 51: XML for Questionnaire “UNWFP Incident Reporting Form”........................XIXFigure 52: Answer XML for Questionnaire “UNWFP Incident Reporting Form”..........XIX

11

LIST OF ABBREVIATIONS

API Application Programming Interface

CB Cell Broadcast

COM Communication

DC District of Columbia

DEWN Disaster Early Warning Network

DFD Data Flow Diagram

GPRS Global Packet Radio Service

GSM Global System for Mobile Communication

HTTP Hyper Text Transfer Protocol

IT Information Technology

PDA Personal Digital Assistant

SMS Short Messaging Service

SOAP Simple Object Access Protocol

UN United Nations

UNWFP United Nations World Food Program

URL Uniform Resource Locator

XML Extended Markup Language

12

Introduction

13

1 INTRODUCTION

1.1 Background

Disaster, in general comes without prior notice causing significant physical damage, loss of

life, or drastic change to the environment. Each year, these natural or man-made hazards

prove to be one of the major stumbling blocks that stifle the human civilization worldwide.

The effects of these disasters are more prominent and significant in the developing

countries of the South-East Asia, and Nepal is not immune to this fact. To be fair, the

ecological and geological make-up of Nepal makes it liable to various forms of natural

disasters such as flood, landslide, earthquake, and so on.

A disaster management, as such mainly comprises of course of actions to be undertaken:

i. before,

ii. during, and

iii. after a disaster.

The domain of the project has been narrowed down to the post disaster scenario where

quick and effective communication becomes one of the integral parts of disaster

management. The project is concerned with providing a viable alternative solution to an

enterprise-level web-based real time information management system named, eWIN which

is currently employed by UNWFP in Nepal. The task at hand is to develop a SMS-based

version of this system, which currently uses Internet/GPRS as communication medium.

14

1.2 Statement of Problem

In Nepal, UNWFP has been tasked with the job of collecting all the information in the post

disaster scenario. Currently, UNWFP has a number of staffs deployed at various regions of

the country. If and when a major disaster strikes, these staffs are mobilized in the impact

zones to collect information regarding property damage, loss of life, current needs

including medical assistance, relief aid and so on; which are reflected in the questionnaire

already present in the eWIN system. Once the information has been collected, it is updated

back to the system using tablet or handheld PDA. The channel currently in existence for

information communication between the eWIN server and the eWIN tablet clients is

Internet or GPRS.

Having access to the most comprehensive and latest available information is critical when

it comes to making effective decisions in the wake of a disaster. When dozens, hundreds,

or even thousands of lives are on the line, response needs to be as quick and efficient as

possible. No data should be overlooked, and no time should be spared. In this context, a

web-based solution may not always be the ultimate and optimal one. A time-critical

system like this cannot afford to await a favorable situation i.e. Internet/GPRS Availability,

for information transfer. Moreover, considering the reliability of GPRS and the

infrastructure of Nepal where Internet is still in its infancy limited to a few, an alternative

communication channel is mandatory.

Today mobile communication devices have become much more technologically advanced

and offer more features. But apart from voice communication, SMS technology is the only

feature that is supported by all generations of wireless mobile phones. The reach and

penetration that the SMS technology offers in the context of Nepal makes it the most

viable alternative for the system.

15

1.3 Objectives

i. SMS implementation of eWIN system for UNWFP

The current eWIN system, employed by the UNWFP uses the Internet for information

communication. The task at hand is to scale its operability by adding SMS as another

information communication medium.

ii. eWIN SMS server as a bridge between eWIN server and client mobile devices

The eWIN SMS server should be able to construct XML files from the information that

it receives from clients via text messages and then, send the files over to the eWIN

server.

iii. Tablet application development

An extension to the existing tablet application capable of formulating text messages

from the records in the existing data source and sending them over to the eWIN SMS

server is to be developed.

iv. Disaster information collection through public and visualization

As an extension, the system should be able to collect disaster information from the

general public and present info-graphics to depict disaster-hit areas and disaster

information overview.

16

1.4 Scope of the Project

What it does?

1. Allows quick flow of information for eWIN system only in the event of

unavailability of Internet service.

2. Primarily used for post disaster situations, however, can be extended to other

equally sensitive situations too.

3. Provides simple mapping and visualization of disaster information.

What it does not do?

1. Is not an out-an-out disaster management system, rather a platform that facilitates

information transfer (especially, critical) through text messages primarily, in the

event of a disaster.

2. Is not a replacement of the current eWIN system rather complements its limitations.

3. Does not work if mobile telecommunication infrastructure is down.

4. Based on the assumption that the users are literate enough to send text messages.

17

Background Study

2 BACKGROUND STUDY

2.1 eWIN Information Management System

eWIN is an enterprise level web based real-time information management system that

provides a comprehensive platform to collect, process, analyze and disseminate field based

information. eWIN 2.0 is the current version of eWIN. With an integrated monitoring and

evaluation framework, eWIN 2.0 provides a robust programme cycle management starting

from creation of logical framework to real-time monitoring of user defined indicators.

eWIN 2.0 provides state of the art communication infrastructure that is designed to send

and receive information from a wide range of devices including desktops, portable tablets

and smartphones using cellular and satellite networks. eWIN 2.0 is the result of a major

upgrade from its predecessor eWIN which currently contains millions of records from

remote communities and development projects covering a variety of thematic areas such as

food security, market situation, water and sanitation or migration patterns.

19Database Web Server

Internet/3G/GPRS/Satellite Phone

Admin User

Web Services

Data Synchronization/Entry

Internet

Authentication/Validation/Approval

Survey admin

Form Content / Survey Admin / User Management / Reporting

Management

Database/Security/

Monitoring/Report User

Data Processing/Report View

Tablet

workstation

Surveyor

Laptop

Figure 1: eWIN Top Level Architecture

2.1.1 eWIN Features:

a. Versatile Client Application

Tablet PC and smartphones for field surveys.

Data transfer using cellular and satellite networks

Desktop application for data management, analysis and reporting.

GIS surveys with map-based data collection.

User-friendly tile based graphical interface.

b. Robust Server Application

Scalable multi-tiered architecture for national as well as regional

implementation.

Web-based user friendly graphical interface.

Advanced questionnaire management system with support for logic rules,

skip patterns, complex data types and version management.

Multi user system with customizable user roles

c. Versatile Server Application

Complete monitoring cycle management with support for logical

frameworks and monitoring plans.

Indicator based evaluation system with ability to create complex indicators

and monitor programme impact.

Progress tracking system with real-time comparison of monitoring plan

against achievement.

d. Comprehensive Reporting Framework

Personalized user dashboards.

Dynamic graphical reports including 2D and 3D graphs and charts.

20

Literature Review

21

3 LITERATURE REVIEW

3.1 Introduction

SMS technology is not a new technology; in fact SMS has been around since early 1980s

when it was defined as a part of GSM series of standard as a means of sending messages

up to 160 characters. However, its full potential wasn’t fully utilized until just a few years

ago. With the expansion of SMS from just mobile-to-mobile communication to mobile-to-

web and vice versa, SMS-based systems have propped up in wide numbers. It is also an

ideal candidate for implementing systems based on crowd-sourcing and also broadcasting

information of vast number of users.

Even today, most SMS-based systems developed are used as a means to call web services

to get information and polling only. However, there are few other systems that have taken

such concept a step further contributing in sectors that directly affects large number. They

have already been used to provide weather information, emergency alerts, public

infrastructure maintenance notice, reporting misuses and registering complaints and many

such activities. Many countries and independent organizations have implemented SMS-

based systems to provide emergency alerts as well as post-disaster response.

The existing systems that we have researched can mainly be categorized into:

3.2 SMS-based Information Transfer System

3.2.1 Alert DC

The Alert DC system provides rapid text notification and update information during a

major crisis or emergency. This system delivers important emergency alerts, notifications

and updates on a range of devices including mobile devices as text messages. When an

22

incident or emergency occurs, authorized DC Homeland Security & Emergency

Management personnel can rapidly notify you using this community alert system. Alert

DC is available to citizens of the District of Columbia as well as individuals traveling to or

working in the District[1].

3.2.2 RapidSMS

RapidSMS is a toolset for rapidly building SMS (text message) services for data collection,

streamlining complex workflows, and group coordination using basic mobile phones —

and can present information on the internet as soon as it is received. In Uganda, Zambia

among many other African countries, RapidSMS has been used as a platform to test an

emergency response monitoring program[2]. Previously, data collected under the new

Emergency Response Monitoring Checklist was provided via paper or email by aid

organizations.

3.3 Disaster Management System

3.3.1 Syria Food distribution using SMS

Although this is not disaster communication system, we have include this as existing

system taking in mind its clever and effective use of SMS in food distribution to refugee in

war-troubled territory. We also plan on including such communication during epidemics

besides just disaster communication. This system was launched in late-2009 by the United

Nations World Food Programme (UNWFP) as food voucher system using SMS for Iraqi

refugees in Syria[3].

3.3.2 Sahana

23

Sahana software was originally developed by members of the Sri Lankan IT community

who wanted to find a way to apply their talents towards helping their country recover in the

immediate aftermath of the 2004 Indian Ocean earthquake and tsunami[4]. The Sahana

Software Foundation is dedicated to the mission of saving lives by providing information

management solutions that enable organizations and communities to better prepare for and

respond to disasters. The Sahana project aims to provide a set of modular, web-based

disaster management applications. Though not completely based on SMS technology,

Sahana provides a good platform for disaster management. Being open-source is a plus-

point.

3.4 Visualization System

3.4.1 Ushahidi

Ushahidi is a website that was initially developed to map reports of violence in Kenya after

the post-election fallout at the beginning of 2008[5]. It uses the concept of crowdsourcing

for social activism and public accountability, serving as an initial model for what has been

coined as 'activist mapping' - the combination of social activism, citizen journalism and

geospatial information. It accepts information form SMS, emails and tweets and maps

them to their web application.

3.4.2 StatSilk

StatSilk visualization and mapping software which is currently being used by many

organizations including Dell, Cisco, World Bank and other UN Organizations[6]. StatSilk

employs a unique business model which seeks to promote the use of data visualization by

non-profit and government organizations and organizations in low income countries. It

aims to promote the use of visualization for research and educational purposes.

24

Requirement Analysis and

Specification

4 REQUIREMENT ANALYSIS AND SPECIFICATION

4.1 High Level Requirements

The diagram below shows a simple block diagram of the system that shows how the

system will be functioning. Our system is completely based on the sending and receiving a

SMS and works around it. In case of the Tablet Application, the application should be able

to convert the filled interview questionnaires using eWIN tablet application to SMS and

send it to our application server. And in case of our application server, SMS could be

received from either Tablet application or mobile device and either from WFP field

monitors or general public. The system is either to convert the received the SMS to the

XML that is to be sent to the eWIN server or stored in the database for the further

visualization.

26

Figure 2: eWIN SMS Server simple block diagram

Message in specified SMS format

Questionnaire XML from eWIN server

Dependency

Answer XML

OutputInputeWIN SMS Server

Transfer Request

Data from existing local databases of eWIN Client

Dependency

Answer SMS

OutputInputeWIN SMS Client

Figure 3: eWIN SMS Client simple block diagram

4.1.1 Features and modules

The features that the system offers can be listed as below:

New Tablet Application

As the WFP field monitors fill the interview data using the eWIN Tablet

Application, the existing application sends the interview data in form of XML using

internet to the eWIN server. In order to send the interview data using the SMS, we

developed a new tablet application that serves the purpose. Our tablet application

accesses the database of the existing eWIN tablet application and accesses required

fields from different table and finally prepares a SMS to be sent to our application

server. After a SMS is formed, it is sent to our application server using the COM

port where GSM SIM card is installed in the tablet device.

eWIN SMS Server

This server acts as bridge between the Tablet Application and existing eWIN

Server. Since the tablet application sends the data as SMS in plain text, the received

data directly cannot be send to the eWIN server as it is set to accept only the

answers in XML format. So our application server needs to convert the received

SMS into the correct XML format in order for the system to accept it.

Use of Mobile device to send Incident Data

In existing eWIN server, there is an interview form named “WFP Incident

Reporting Form” which is used to collect information such as incident details,

districts of occurrence of incident etc. Rather than using the Tablet application to

send the incident data in case of incidents, it is easy to send the same data using a

simple mobile device following a certain SMS format. So a SMS format is defined

27

just for transferring the incident data by WFP field monitors. And the received SMS

needs to be converted to the proper XML so that the eWIN server accepts it.

Incident information collection from public

We made further enhancement to our project and made it able to store the disaster

information sent by public. For this, we defined a SMS format especially for the

public. SMS sent from the mobile devices following the specified format hits our

server and are stored in the database.

Visualization of Incident data

After gathering the incident data in our server, it is mapped into the Map of Nepal

showing the areas affected with incidents and the details about the incident.

4.2 Functional Requirements

28

eWIN SMS Client

eWIN SMS Server

<<extends>><<extends>>

<<includes>>

UNWFP Field Monitor

DeleteUpdate

Transfer Data via SMS

Login to the System

Figure 4: Use Case Scenario for eWIN SMS Client

eWIN Server

Specification of actors

UNWFP Field Monitor

UNWFP Field MonitorElement Detail

Description UNWFP Field Monitor is the person who conducts survey in the field and uses the client application to transfer

information via SMS

eWIN Server

eWIN serverElement Detail

Description eWIN SMS server is the already existing webserver that validates the login of the UNWFP Field Monitor

into the eWIN SMS client

eWIN SMS Server

eWIN SMS serverElement Detail

Description eWIN SMS server is the newly created webserver that receives text message

from the clients

29

Table 2: Specification of actor – eWIN Server

Table 3: Specification of actor – eWIN SMS Server

Table 1: Specification of actor – UNWFP Field Monitor

Specification of use cases

Transfer information via SMS

Log into the system

Log into the systemElement Detail

Active Actor UNWFP Field MonitorPassive Actor eWIN serverDescription UNWFP Field Monitor logs into the

system with credentials which are validated by communicating with the

eWIN server

Update

UpdateElement Detail

Description Once a particular text message has been sent successfully, the sync status of its associated record is updated in

the eWIN client’s database

30

Table 4: Specification of Use Case – Transfer information via SMS

Table 5: Specification of Use Case – Log into the system

Table 6: Specification of Use Case – Update

Transfer information via SMSElement Detail

Active Actor UNWFP Filed MonitorPassive Actor eWIN SMS serverDescription UNWFP Filed Monitor makes a

request to transfer information via SMS and thus transferred text message is intercepted by the eWIN SMS server

Delete

DeleteElement Detail

Description Once a particular text message has been sent successfully, its associated

record is deleted from the eWIN SMS client’s database

31

eWIN SMS Server

<<includes>>

<<extends>>

<<extends>>

Log into the system

View transfer history and info-graphics

Geneate and send answer XML file

eWIN SMS Client

Administrator

eWIN Server

Fetch Questionnaire XML

Create hash table between received SMS messages and

fetched XML attributes

Receive SMS Messages

Figure 5: Use Case Scenario for eWIN SMS Server

<<extends>>

Table 7: Specification of Use Case – Delete

Specification of actors

Administrator

AdministratorElement Detail

Description Administrator is the person who has successfully logged into the eWIN

SMS server

eWIN Server

eWIN serverElement Detail

Description eWIN server is the already existing webserver that sends the questionnaire XML file to the eWIN SMS server, and receives the answer XML file from it

eWIN SMS Server

eWIN SMS serverElement Detail

Description eWIN SMS server is the newly created webserver that receives text message via SMS from the clients and sends

thus generated answer XML file to the eWIN server

32

Table 8: Specification of Actor – Administrator

Table 9: Specification of Actor – eWIN Server

Table 10: Specification of Actor – eWIN SMS Server

Specification of use cases

Receive text message

Receive text messageElement Detail

Active Actor eWIN SMS clientDescription The text message sent by the eWIN

SMS client via SMS is received by the eWIN SMS server

Fetch questionnaire XML

Fetch questionnaire XMLElement Detail

Passive Actor eWIN serverDescription The questionnaire XML file

corresponding to the questionnaire code contained in the text message is

fetched from the eWIN server

Create hash table

Create hash tableElement Detail

Description When the questionnaire XML file has been fetched successfully, a hash table

is created between the received text message and the fetched XML tags

33

Table 11: Specification of Use Case – Receive text message

Table 12: Specification of Use Case – Fetch Questionnaire XML

Table 13: Specification of Use Case – Create hash table

Generate and send answer XML file

Generate and send answer XML fileElement Detail

Passive Actor eWIN serverDescription The answer XML file is generated

from the hash table and it is sent to the eWIN server

View transfer history and info-graphics

View transfer history and info-graphicsElement Detail

Active Actor AdministratorDescription The administrator is able to view

history of all the information that the eWIN SMS server has received via SMS along with the extended info-

graphics feature

Log into the system

Log into the systemElement Detail

Active Actor AdministratorDescription The administrator needs to log into the

system with the valid credentialso

34

Table 14: Specification of Use Case – Generate and send answer XML file

Table 15: Specification of Use Case – View transfer history and info-graphics

Table 16: Specification of Use Case – Log into the system

Methodology

5 METHODOLOGY

5.1 Project Implementation Methodologies

The above diagram shows the overview of the overall system which is composed of the

existing eWIN system and our developed system. In order to attain various aspects of our

developed system, following methodologies have been employed:

36

Figure 6: Overall System Block Diagram

5.1.1 SMS communication to and from the Web server

The system is supposed to handle two basic instances of SMS transfer one from the

mobile Telecommunication device to the Web server and other from the Web server to the

mobile Telecommunication device. In order to assist the incoming and outgoing of the

SMS messages, to and from the Web Server, an intermediate SMS service called Sparrow

SMS is employed, whose API acts as a bridge between two dissimilar nodes. In order to

achieve the first instance, following steps are employed:

In order to receive SMS in our server, we implemented the Incoming API provided by the

Sparrow SMS. As an SMS is sent to the provided short code in the predefined formats, the

URL of our incoming SMS processing module is invoked and the SMS is grabbed by the

SMS processing module in our server. The module for grabbing the received SMS consists

of following implementation:

37

Figure 7: Steps for SMS communication to and from the Web server

if 'text' in request.GET and request.GET['text']:

SMS = request.GET['text']

Figure 8: Implementation of Incoming SMS API

After receiving the SMS, it is subjected to further processing as needed.

The Documentation of the Incoming API provided by the Sparrow SMS is described in the

Appendix B.

In order to send SMS messages from our server to other Mobile devices, we used the

Outgoing API provided by Sparrow SMS. The Outgoing API is implemented in our server

in the following way:

By providing the required details such as client_id, username, password, SMS_from,

SMS_to and message and calling the URL http://api.sparrowSMS.com/call_in.php

provided in the Outgoing API, message can be successfully pushed to the destination

mobile number.

5.1.2 SMS formation and transfer from Tablet Application

A basic message format for SMS consists of a code-word followed by a number of fields

generally, within permissible limit; which is addressed to a particular short code or cell

number. This format of the message is defined as per the XML of the questionnaire, to be

more precise, the XML of answer set of the questionnaire. Following steps are followed to

achieve the same:

38

url_part = {'client_id':client_id, 'username':username, 'password':password,

'from':SMS_from, 'to':SMS_to, 'text':message}

api_url = 'http://api.sparrowSMS.com/call_in.php?' + urllib.urlencode(url_part)

response = urllib2.urlopen(api_url)

message_response = response.read()

Figure 9: Implementation of Outgoing SMS API

http://api.sparrowsms.com/call_in.php

Following the above stated steps, the SMS message generating from the tablet application

will be in the following format:

WF

P<space>[data_attr1]<space>[data_attr2]<space>[data_attr3]<space>[data_attr4]<

space>[ans1]<space>[ans2]<space>[ans3]……………

<space>[respondent_attr1]<space>[respondent_attr2]<space>[respondent_attr3]<s

pace>[respondent_attr4]………………….

Example:

39

Figure 10: Steps to form and send SMS from Tablet Application

WFP 33257457602 7/21/2013#12:00:00#AM 1 10 0.99|9|9|0|-0|-0|8|98|98|98 19|

99|2|-3|2|-2 2|2|1|2|2 5 X 33476348760 test Y X 193 363 116900103 X X X X

1169001

5.1.3 Incident Reporting From data retrieval using Mobile Device

In order to make our system able to receive incident related data corresponding to

“UNWFP Incident Reporting Form” from mobile device too, following steps are employed

to achieve the same:

For the field monitors to register themselves in the server before sending the answer of the

questionnaire WFP Incident Reporting Form, they need to send their credentials to the

server using the following SMS format:

WFP<space>[username]<space>[password]

After registering, field monitor will receive the following SMS template:

40

Figure 11: Steps employed to obtain incident data using Mobile Device

WFP<space>incident<space>[r.name]<#>[r.type]<#>[r.age]<#>[r.m/

f]<#>[r.ward]<#>[site name]<#>[districts]<#>[reported

by]<#>[occ.date]<#>[details]

The field monitor edits the SMS template with the actual data and sends back the SMS to

the server.

Example:

WFP incident Bakhat Niroula#r.type#23#m#r.ward#Jumla#Lalitpur, Dolakha,

Dang#Bakhat Niroula#2/12/2013#Surkhet Jumla road blocked for 15 days todate

(27th feb 2013). This is causing price hikes in food commodities.

5.1.4 Disaster Data Collection from Public

To obtain disaster related data from the public, a subtle SMS format was needed and

therefore defined in the same way. The whole collection and processing of the disaster

related data are implemented using following steps:

41

Figure 12: Steps employed to obtain disaster data from Public

The SMS format for public is defined as

WFP<space>disaster<space>[disaster occurred address(VDC Name)]<space>

[disaster name]<space>[disaster descriptioin]

Example:

WFP disaster Lubhu,Lalitpur flood 2 house destroyed, 3 missing

42

5.1.5 SMS parsing

While sending the answer SMS from tablet application, some characters need to be

replaced by another according to the design of the system. And in case of the server, it

receives encoded SMS message, which in turn needs to be converted into its original form.

Following steps are employed to achieve these two features:

5.1.6 Mapping the SMS format to XML format

Upon the reception of SMS message at the server side, complete SMS is split into

individual items. In order for the eWIN server to accept the data of the interview, the SMS

received should be converted to the respective XML format that the tablet application

43

Figure 13: Steps to parse SMS message before sending from tablet application

Figure 14: Steps to parse SMS message after received in server

would convert to if it transferred the filled interview to the eWIN server using the internet.

For this purpose, following steps are employed:

5.1.7 Disaster Visualization

The data received public SMS is included in the mapping process. The information

received is first stored in the database. To maintain a level of consistency in the naming of

the VDC names, the received name for the incident location (VDC-level) is mapped to the

closest VDC name in the database and stored as such. The reception of the incident

message is indicated by highlighting the location (Ward or VDC) from which the message

was originated. Following steps are followed in order to map the disaster info into the map

of Nepal.

44

Figure 15: Steps to map SMS message to XML

Implementation of the disaster visualization is done by the use D3. D3.js is a JavaScript

library for manipulating documents based on data. The data here is in TopoJSON format

which was extracted from the Nepal Shapefile.

The topology objects include administrative borders of Nepal and is loaded once JSON file

is loaded. For rendering of the geography path generator and projection is required. The

projection used in our project is Mercator projection as it preserves the angles and shapes

of the projected objects.

d3.geo.path().projection(d3.geo.mercator().center([80,

30]).scale(5000).translate([300, 250]))

The incidents are highlighted in the map by comparing the VDC name in the JSON data

and the VDC name of incident extracted from the database. The incident data form the

database are passed as array which is then processed to obtain the VDC name, disaster

name and incident description.

46

Figure 16: Steps to visualize disaster data into Map of Nepal

5.2 Project Schedule

47

Figure 17: Works Completed GANTT Chart

Figure 18: Works Remaining GANTT Chart

System Design

6 SYSTEM DESIGN

6.1 System Architecture

49

eWIN SMS Client

Database

Data

Answer XML

DataDataData

SMS

SMS SMS

eWIN Server Side

Application Server Side

Client Side

Mobile Devices

Tablet Devices

Native SMS Application

SMS Protocol

Application Database

eWIN Database

eWIN Server

Visualization Tool

Webpage Resources

SMS Parser

SMS to XML Mapper

SMS Validator / Identifier

Web Server

Sparrow SMS API

eWIN SMS Client Application

SMS Protocol

eWIN Client Database

Figure 19: System Block Diagram

The whole system has a client-server architecture where our application web server acts as

both client and server to eWIN entities. It acts as server to tablet’s eWIN SMS client

application and mobile devices and as client to the eWIN server.

The eWIN SMS client application fetches unsynchronized messages from eWIN client

application database, maps them to SMS format and sends them to our application server

via Sparrow SMS gateway. The text messages from native mobile application are received

through same method too.

As the text messages are received on our web server, they are validated and chunked. Then

based on the identifier, the source of the text message is identified. After the questionnaire

code of the text message is identified by SMS Parser, SMS-to-XML mapper requests the

corresponding XML from the eWIN server. The tag and their attributes from XML are

used to create Answer table in the application database. The values from text message are

tallied with the Answer table to generate Answer XML for that particular interview. Thus,

created XML is sent to eWIN server for storage.

The existing components, whose services are used are:

- SMS Protocol in GSM modem for sending text messages from tablet and mobile

devices.

- Sparrow SMS Gateway and API for facilitating communication between

tablet/mobile devices and eWIN SMS application server via text messages.

- eWIN Server for providing web services for communication with eWIN database

for retrieval of placeholder answer XML and storage of generated answer XML.

50

6.2 Deployment Diagram

The application is built around client-server model. The client sends messages to the server

and server processes those messages. Clients can interact with the server through Sparrow

SMS gateway. The client may include tablet, mobile devices and any devices capable of

sending text messages.

Within the Web Server, there are two artifacts namely eWIN SMS Server Website and

SMS-to-XML Mapping Rules. The eWIN SMS Server Website is composed of login

interface, data transfer summary interface and Mapping interface showing the disaster hit

areas in the map of Nepal. And the artifact SMS-to-XML Mapping Rules contains modules

to transform the received Answer SMS to corresponding Answer XML in order to send the

XML to the eWIN server.

51

Figure 20: Deployment Diagram

<<artifact>>: Messaging Service

<<device>>: Mobile Phone

<<artifact>>: SMS Formulating Rules

<<artifact>>: eWIN SMS Client UI

<<device>>: Tablet Client

<<artifact>>: SMS-to-XML Mapping

Rules

<<artifact>>: eWIN SMS Server Website

<<device>>: Web Server

There are mainly two clients, mobile devices and windows tablet. Windows tablet consists

of two artifacts eWIN SMS Client UI and SMS Formulating Rules. The eWIN SMS Client

UI consists of a login interface, settings interface, user details interface and transfer

interface which shows the un-synced data from the eWIN Tablet Client’s database. And

the SMS Formulating Rules contain procedures to collect the data for the required

interview and convert it to the defined SMS format. In case of mobile devices, it consists

of a single artifact Messaging Service, which is native to any mobile device and is

responsible for handling SMS messages in the device.

6.3 Data Flow Diagram

The DFD diagram shown above shows the Tablet eWIN SMS Client as one process and

the external entities such as UNWFP Field Monitors, eWIN SMS Server and eWIN

Client’s Database interact with this process. UNWFP Field Monitor issues the Transfer

Request which in turn transfers the selected interview data to the server through SMS. The

interview Records are retrieved by the Tablet Application from the eWIN Client’s

Database and this system sends the requested interview data to the eWIN SMS Server as

SMS Message.

52

Figure 21: Context Level DFD for Tablet Application

Figure 22: Context Level DFD for Application Server

The diagram above shows the Level-0 DFD for our application server. The server interacts

with external entities eWIN SMS Client and eWIN Server. The server receives the text

message via. SMS from the eWIN SMS Client and using the received SMS Message, it

fetches the Questionnaire XML from the eWIN Server and using the received SMS

Message and Questionnaire XML, forms the Answer XML and conveys the XML to the

eWIN Server.

53

6.4 Class Diagram

The classes involved in the development of our application server along with their

properties and behaviour have been shown below. The overall working of the application

server has been established by the interactions among these classes through their instances

via message passing.

54

Figure 23: eWIN SMS Server Class Diagram

The brief description of the classes used in our Application Server are summarized in the

following table:

S.No. Class Name Purpose

1. Interview_Class To maintain the database about:

which questionnaire’s data is received in

our server using the SMS

the number of interview data received

date and time of the received SMS

device from which SMS is received

whether the data is sent to server or not

2. Answer_Class Prepare the database for a new incoming

Answer SMS

Write the Answer XML using the data from the

database answer table

3. Questionnaire_Class Get Questionnaire XML from eWIN server

Insert the tag’s attributes to the database

questionnaire table

4. Incident_Class Transforms incident related data sent by

UNWFP Field Monitors using Mobile device

to answer XML

5. Database_Lock_Class To prevent multiple incoming SMS Messages

from simultaneously reading and writing in the

database

6. Outgoing_SMS To push a response message to the number

from which SMS is received

7. Public_SMS_Class Handle disaster related data sent by the Public

8. Mapper_Class Provide the mapping library with the address

and disaster description

55

In the following diagram, classes, interfaces, collaborations and the relationships among

them are shown which gives the overview of the Tablet Application we developed.

The brief description of the classes used in our Application Server are summarized in the

following table:


1. eWINDatabase Represent the existing local databases namely,

“UNWFP_db.sdf” and

“UNWFP_geosite_db.sdf” of the eWIN client

Provide methods to retrieve the elements of a

particular record scattered among different data

sources

Update the record status upon synchronization

with the eWIN server

56

Figure 24: eWIN SMS Client Class Diagram


2. Attributes Maintain the ‘Attributes’ table in database

Build SMS Message from the Attributes Table

3. UserInterface Solely used for the GUI

4. SMS Encapsulates methods that handle the sending

of SMS message via serial port (COM) port

Facilitates:

Opening of the serial port

Sending of SMS Message to the serial port

Closing of the serial port

57

Table 18: Brief description of classes used in Tablet Application

6.5 Tools and Frameworks Used

Programming Language(server side): python 2.7

XML Processor: lxml XML toolkit 3.2.0

Programming Language(Tablet Application): c#

Framework: Django 1.5.1/.net framework v4.0

Database: MySQL/ SQL Server Compact Edition v3.5

Versioning: Github(https://github.com/acharyagtm/major_project.git)

UI(Tablet Application): DevExpress

Documentation: MS Word/Excel/PowerPoint

GSM Library(Tablet Application): GsmComm Library

IDE: Aptana Studio, Visual Studio 2010

Webserver: Django development server

Mapping: D3.js, Jquery, Topojson.js, Queue.js

58

Output

7 OUTPUT

7.1 eWIN SMS Client Application

60

Figure 25: Tablet Application Login Interface

Figure 26: GUI Showing Unsynchronized Records

61

Figure 27: GUI after ID ‘33257457602’ has been sent as SMS

Figure 28: Refreshed GUI after SMS has been sent

7.2 eWIN SMS Server

62

Figure 30: Index Page of Application Server

Figure 29: Login Interface of Application Server

63

Figure 31: ‘WFP Incident Reporting Form’ Interview Details

Figure 32: Disaster Visualization

Figure 33: Disaster Details

System Evaluation, Analysis

and Testing

64

8 SYSTEM EVALUATION, ANALYSIS AND TESTING

Testing is an important part of any project whether it a small final year project or a huge

commercial system. Testing is an activity that can go on forever so it is important to test

the areas that are most important and the areas that are most likely to reveal bugs. Like any

project, exhaustive testing is not possible. Testing is a highly strategic activity and

different methodologies are used. The methodology we used to test our system is discussed

here and an overview of the various results and problems discovered are presented.

8.1 Testing Methodology

This project was developed using an iterative approach. However performing testing

during these iterations was limited due to the time constraints associated with a final year

project. Instead we did exploratory testing [12] without any documentation and fixed any

problems we discovered on the fly. The main documented testing was done at the later

stages of the development life cycle similar to the water fall method of development.

8.1.1 Exploratory Testing

Exploratory testing is one of the newer testing methodologies. It is a type of manual testing

where no formal plan is made. It involves ‘exploring’ the product, targeting areas that are

likely to reveal the most bugs, almost like a mission. It is also known as ad hoc testing but

65Figure 34: Exploratory Testing

this word is usually viewed with negative confutations portraying a sloppy and careless

method of testing.

Years ago this form of testing was not respected but since testing is becoming more and

more a complex activity, new forms like exploratory testing are appearing to improve the

problem of exhaustive testing.

James Bach, a well-respected writer in areas of testing wrote an article on exploratory

testing in 2003. He defines exploratory testing as “simultaneous learning, test design and

test execution”. He is pro exploratory testing highlighting that since it is not a scripted

process; it keeps the mind of the tester fresh. He describes it almost like solving a puzzle

and that it begins with a charter that outlines a mission. James Bach does not see testing as

a methodology but more a way of thinking of testing, a mindset. It is important to note that

exploratory testing isn’t sloppy. It does have a strategy and works well under tough time

constraints.

8.2 Test Cases

In order to test our developed system, we developed test cases and used these cases to test

the system at a functionality point. The test cases were designed in such a way that they

cover almost every part of the system and were most likely to produce a bug. The test cases

were to give stress to the system and check whether the system functions as required in

such situations.

The categories of the test cases run are as follows:

8.2.1 Functionality and System Tests

The test cases in this category deal with testing our system’s functionality and ensuring the

all the requirements work correctly. This involves testing every area of functionality that

the end user can perform.

66

8.2.2 Stress Tests

As there are numbers of WFP field monitors working in the field, multiple field monitors

could send the interview data at the same time to the system. Whether to check if the

system functions properly or as expected in these situations where multiple SMS messages

hit the system, stress tests are performed. To cope with these situations, a protective

measure called ‘Locking’ is implemented.

8.2.3 Location Identification Tests

As for the case of disaster data retrieval from Public, although a strict SMS format is

devised, there is high probability that people might not send the exact location names such

as they might append ward no, they might type the name incorrectly etc. So we developed

a module that matches the received location name with the official location names

retrieved from the eWIN database and the best match is stored in the database. In order to

check this, we tested with different location names, sometimes with wrong spellings,

sometimes with missing letters, sometimes with extra word appended etc.

This was a beneficial activity and found quite a few bugs that I didn’t come across with

previous testing. This is discussed further in the following section.

67

8.3 Test Results

The test results for different test cases are summarized below:

Answer XML generation for answer SMS of different questionnaires received from

Tablet

S.No. Questionnaire NameQuestionnaire

Size

Answer XML

Generation Time

Run 1 Run 2 Run 3

1Food price and unskilled wage

rate collection checklist10 KB 4 sec 5 sec 5 sec

2PRRO Refugees Post-

Distribution Monitoring69 KB 26 sec 22 sec 24 sec

3FCFA Activity Monitoring 2012 -

Beneficiaries35 KB 18 sec 15 sec 16 sec

4OLD_NeKSAP Rural Household

Survey Questionnaire55 KB 22 sec 21 sec 20 sec

Total webpage load time without Mapping elements (including external files)

Run Tests Full Document Load time(milliseconds)

Run 1 119

Run 2 115

Run 3 203

68

Table 19: Result of Answer XML generation test

Table 20: Result of Webpage Loading without Mapping Elements

Total webpage load time with mapping elements (including external files and

external data files)

File size of JSON containing data co-ordinates of Nepal : 1414 KB

Total size of included javascript files/libraries : 155 KB

Page Load time for Elements besides map

elements (in milliseconds)

Mapping elements (in

milliseconds)

Run 1 210 1276

Run 2 272 1358

Run 3 285 1395

8.4 Test Environment

The development and testing of our project is done in the following hardware and software

environment:

Application Server

Development

Tablet Application

Development

Visualization

Computer Model HP DV4-2153CL HP EliteBook 8470w Dell N4110

Processor Intel(R) Core(TM)

i3 CPU 2.13GHz

Intel(R) Core(TM) i7

CPU 2.70GHz

Intel(R) Core(TM) i3

CPU 2.70GHz

Physical Memory 1910 MB 4096 MB 6144 MB

OS Windows 8 Pro 64-

bit (6.2, Build 9200)

Windows 8 Pro 64-

bit (6.2, Build 9200)

Windows 8 Pro 64-bit

(6.2, Build 9200)

70

Table 22: Environment Details

Table 21: Result of Webpage Loading with External Elements

Conclusion

9 CONCLUSION

The major accomplishments of the project have been summarized below:

- The SMS implementation of the eWIN system has been achieved successfully

- eWIN SMS server to handle information via SMS text messages has been

created

- eWIN SMS tablet client application for information transfer via SMS text

messages has been developed

- The mapping and visualization of the disaster information sent by public via

SMS text messages has been included

The project has been a great learning curve. Throughout the project, vast amount of

knowledge has been gained and new techniques learnt. The most valuable lesson that has

been learnt through this project is that whenever any project involves work on an existing

system, thorough study of the existing system is vital. Moreover, discussion sessions with

the developers of the existing system provide a great help to comprehend the overall

operation of the system in a simple way and it can also give a head-start towards the

development of the intended system. Likewise, the importance of the background research,

requirement analysis and specification, design concept, and methodology was learnt. Also,

system development, testing, error handling, optimization and probable problem prediction

have been employed. At last, we hope that the developed eWIN SMS system comes out of

the full-fledged testing phase with flying colors and serves to save the lives of many

whenever it is summoned for.

72

Limitation and Future

Work

10 LIMITATIONS AND FUTURE WORK

Due to time and resources-constraint many features couldn’t be incorporated. There are

still few limitations to our system

The processing of the SMS slows as the traffic increases on the input of web server

due to database locking mechanism used.

Skip Rules present in some questionnaire modules are not included due to its

complexity.

Internet is required on the client application on the first use to verify the user

credentials.

Below are the list of things that can be incorporated in the future.

Including skip rules to incorporate all the questionnaire modules

Advance parser to identify the incident type received from public SMS and

categorization of incidents accordingly

Incorporating disaster management features like early disaster warnings, resource

management, relief and rescue management

Interactive visualization for more prevalent form of representing incident status and

meaningful ways to impart those information.

74

References

REFERENCES

[1] Alert DC, Government of the District of Columbia.

https://textalert.ema.dc.gov/index.php .Retrieved 13/02/2013.

[2] RapidSMS Projects. RapidSMS. https://www.rapidsms.org/projects/. Retrieved

13/02/2013.

[3] Syria: Food distribution to start for vulnerable Iraqi refugees. UNHCR Report. 31

August 2007. http://www.irinnews.org/report/86872/syria-wfp-pilots-sms-food-

distribution. Retrieved 9/02/2013.

[4] Sahana. Sahana Software Foundation. http://sahanafoundation.org/. Retrieved

08/02/2013.

[5] Ushahidi. Ushahidi. http://www.ushahidi.com/. Retrieved 08/02/2013.

[6] StatPlanet visualization and mapping software. StatSilk. http://statsilk.com/.

Retrieved 08/05/2013.

[7] SMS Tutorial. Developers Home. http://www.developershome.com/sms/ .

[8] Disaster and Emergency Warning Network (DEWN). Dialog Telekom PLC, Dialog-

University of Moratuwa (UoM) and Mobile Communications Research Laboratory

and Microimage. http://www.dialog.lk/about/responsibility/outreach-cr/dewn.

Retrieved 15/02/2013.

[9] Sparrow SMS API Documentation. Sparrow SMS. http://api.sparrowsms.com/.

[10] Bostock, Michael. D3 Wiki. https://github.com/mbostock/d3/wiki.

[11] Bostock, Mike. Let’s Make a Map. http://bost.ocks.org/mike/map/.

[12] Tinkham, Andy and Cem Kaner (2003). Exploring Exploratory Testing.

76

http://bost.ocks.org/mike/map/

https://github.com/mbostock/d3/wiki

http://api.sparrowsms.com/

http://www.dialog.lk/about/responsibility/outreach-cr/dewn

http://www.developershome.com/sms/

http://statsilk.com/

http://www.ushahidi.com/

http://sahanafoundation.org/

http://www.irinnews.org/report/86872/syria-wfp-pilots-sms-food-distribution

http://www.irinnews.org/report/86872/syria-wfp-pilots-sms-food-distribution

https://www.rapidsms.org/projects/

https://textalert.ema.dc.gov/index.php

Appendix

APPENDIX A: DATA FLOW DIAGRAMS

78

Figure 35: Application Server DFD Level-0

79

Figure 36: Tablet Application DFD Level-0

APPENDIX B: SPARROW SMS DOCUMENTATION

Sparrow SMS Provides API to developers to push SMS content to GSM Networks of

Nepal Telecom and NCell, via the Sparrow SMS Gateway. The API is basically for the

PUSH Service only. However, Sparrow SMS can facilitiate the developers / content-

owners by directing all the incoming requests to particular campaigns, to the web endpoint

provided by the developer/content-provider.

The description of incoming and outgoing APIs are given below:

Incoming API - (Relay approach)

Sparrow SMS provides incoming API in a slight different approach. It’s an interrupt

approach rather than the conventional polling way. When there is an incoming SMS Hit,

the URL provided by content-provider / developer is invoked and any output sent via the

respective URL is delivered to the SMS sender. However, it is not mandatory for the

application to send anything as output. Sparrow SMS can just relay the incoming request

so that the application can keep tracking in its own way.

Following are the arguments augmented to the URL on every Incoming SMS.

1. timestamp

a. timestamp of the time when the incoming SMS hits the Sparrow SMS

Gateway server

2. keyword

a. The first word of the incoming SMS text

80

3. text

a. The text after shifting the first word of the SMS content

4. from

a. Phone number of the SMS Sender

5. to

a. The shortcode to which the SMS was received

Possible Conditions to relay the Incoming SMS

Sparrow SMS can handle the conditions/validations for every incoming SMS so as to

reduce traffic on to the application server. Following are the conditions one or more

than one of which can be

1. All Incoming Requests ( External Relay )

2. When a valid keyword was hit ( Keyword Relay )

3. When some validation pattern was matched, for example. numbers or

alphabets, or any alphanumeric word .etc. ( Validation Relay )

Outgoing (Push) API Parameters and Endpoint

1. API Endpoint

a. call_in http://api.sparrowSMS.com/call_in.php

Use this endpoint when required to track response to each API calls.

81

http://api.sparrowsms.com/call_in.php

2. Parameters

a. username

Username provided during the API signup

b. Password

Password provided during the API signup

c. client_id

client_id provided during the API signup

d. from

used when multiple senders are allowed

‘from’ parameter needs to be supplied at the time of each API request

e. identity

sending identity not used if ‘from’ is defined for the account

f. to

the number to send SMS to

must be a urlencoded comma separated list of phone numbers each of

the numbers being either of the following formats

1. 10 digits phone number

eg. 9841000000

2. 10 digits phone number and a ‘+’ at the beginning

eg. +9841000000

3. 10 digits phone number and country code ‘977’ or ‘+977’ at the

beginning

eg. 9779841000000, +9779841000000

characters ‘space’ and ‘hyphens’ will be removed automatically and the

10 digits mentioned in the point above counts after removing these

characters. It means, following numbers are valid too

1. 9841-00-00-00

2. 9841 00 00 00

3. +9841 00 00 00

4. +9841-00-00-00

5. +9779841 00 00 00

82

6. +9779841-00-00-00

7. 9779841 00 00 00

8. 9779841-00-00-00

anything other than these formats is regarded as an Invalid Number

g. text

the text to be sent

must be urlencoded

3. Access Limitations

a. The API usage access is restricted under the following domains

Username / password

username and password must match with the details provided during

signup and aren’t changeable

client_id

provided during the API signup

IP Address

IP address limitation is on highest level and the API access is limited to

the whitelisted IP addresses only.

Credits

SMS is delivered only if there is credit available to send the SMS. Only prepaid credits

are available and need to contact Sparrow SMS to add credits to the corresponding API

account. A single credits means a single SMS allowed to be sent to any of the available

operators.

83

APPENDIX C: EWIN SYSTEM DIAGRAMS AND SNAPSHOTS

Database

Web Server

Internet/3G/GPRS/Satellite Phone

Web Services

Data Synchronization/Entry

Authentication/Validation/Approval

Surveyor

WorkstationLaptopTablet PCManual (Paper Based)

Data processing/Reporting Manager

Admin User

Monitoring/Report User

Firewall

Firewall

BackupDatabase

Https connection

84

Figure 38: eWIN Deployment Architecture

Figure 37: eWIN Logo

85

Figure 39: eWIN Home Screen

Figure 40: eWIN Tablet Application Home Page

APPENDIX D: PROTOCOLS

Protocols

The existing eWIN system developer Nepasoft Solutions has developed some Web

Services to aid the functionality of the existing system. The developed Web Services

provides functionality such as checking whether the provided user credentials are valid of

not, getting the list of respondent types, getting the XML of the requested questionnaire

with skip rules or without it etc. The list of all the Web Services available are listed below:

CheckValidUser GetFileLists GetFileListsString GetFileListsStringOracle GetStringXml GetStringXmlOracle LoadMultiMediaData LoadXmlString SyncRespondentMgmtData getAllRespondents getMonitoringPlanListXML getQuestionnaireWithRule getQuestionnaireWithSkipXml getQuestionnaireXml getRespondentType

These Web Services are capable of operating using different protocols such as SOAP 1.1,

SOAP 1.2, HTTP GET and HTTP POST.

Among these Web Services provided in the existing eWIN system, only some of the Web

Services are useful to our system. We have utilized some essential Web Services for our

project in order to accomplish tasks such as validating the user, getting list of all the

86

questionnaires available in the system and getting specific questionnaire XML. The list of

Web Services we have used are:

CheckValidUser GetFileListsStringOracle getQuestionnaireXml

We have implemented these Web Services using HTTP GET protocols. The

Documentation of these Web Services using HTTP GET proctocol are listed below:

87

Figure 41: Web Service Documentation for Validating a User using HTTP GET

Figure 42: Web Service Documentation for getting Questionnaires List using HTTP GET

Figure 43: Web Service Documentation for Questionnaire XML retrieval using HTTP GET

APPENDIX E: EWIN QUESTIONNAIRE AND ANSWER XML

DESCRIPTION

The main objective of the eWIN system is to facilitate the collection, processing, analyzing

and dissemination of field based information. For the collection of the field based

information different questionnaires for different contexts are developed. These

questionnaires are filled during an interview and later the filled data are sent to the server

for further processing.

An image of a questionnaire titled “PRRO Refugees Food Basket Monitoring Counter

Monitoring” available in the eWIN system is shown below:

88

Figure 44: Questionnaire “PRRO Refugees Food Basket Monitoring Counter Monitoring”

The corresponding XML for the above questionnaire is shown below:

Questionnaire XML starts with the <questionnaire> tag and different other tags are

included within this tag. Inside the <questionnaire> tag there are different modules that

constitute of questionnaires in different forms such as text, check box, group

questionnaires, matrix questionnaires etc. Following are the types of question depending

on the answer type:

Text

Simple text as answer

Large Text

Long text as answer

Numeric

Number as answer

Combo Box

Single choice answer

89

Figure 45: Questionnaire XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring”

Radio button

Single choice answer with all

answer shown at a time

Check Box

Multiple choice answers

Date

Date type answer

GPS

GPS Coordinate as answer

Group

Grouping of questions like

Number of committee members

Total __

Female __

Dalit __

Janajati __

Matrix

Matrix type of question like

Rice Sugar Wheat

Kathmandu

Lalitpur

Bhaktapur

After a questionnaire is filled using the eWIN Tablet Application, it is sent to the eWIN

server in XML form. The sample answer XML for the questionnaire “PRRO Refugees

Food Basket Monitoring Counter Monitoring” is shown below:

91

Table 23: Matrix Type of Questionnaire

Figure 46: Answer XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring”

The answer XML contains <datacollection> tag as the root. Within this tag there is <data>

tag that contains information about the interview data such as data id, date of visit, revision

no and field monitor id. Inside the <data> tag, there resides the actual interview data that is

filled in the questionnaire. The data for each question inside the interview are stored inside

corresponding tags of the question such as <QN_547_0>. There also exists the respondent

data inside the <data> tag. Respondent data are stored inside <respondent> tag as

attributes. Some of the respondent attributes are respondent id, name, type, site code etc.

During the development phase, we used a sample questionnaire with its questionnaire

XML and its answer XML. The image of the sample questionnaire, its XML and its answer

XML are shown below:

92

Figure 47: Sample Questionnaire “IOE_Sample”

93

Figure 48: XML for Sample Questionnaire “IOE_Sample”

Using the questionnaire titled “UNWFP Incident Reporting Form” we developed module which is capable of receiving incident related data from the mobile devices too, using certain predefined message template. The questionnaire image, its XML and its answer XML is shown below:

94

Figure 50: Questionnaire “UNWFP Incident Reporting Form”

95

Figure 51: XML for Questionnaire “UNWFP Incident Reporting Form”

Figure 52: Answer XML for Questionnaire “UNWFP Incident Reporting Form”

APPENDIX F: GSMCOMM LIBRARY

GSMComm is a collection of components to aid developers in performing short message

(SMS) related tasks with GSM phones or modems. The project utilizes following

namespaces of GSMComm Library:

PDU Converter

GSM Communication

1. PDU Converter Namespace

The GsmComm.PduConverter namespace is responsible for creating and decoding SMS

messages. No communication is done here. It contains a special namespace

GsmComm.PduConverter.SmartMessaging to create and parse “Smart Messaging”

complaint and related messages.

1.1. SMSSubmitPdu Class

It represents an SMS-SUBMIT PDU, an outgoing short message.

1.2. SMSSubmitPdu(String, String) Constructor

Initializes a new instance of the SMSSubmitPdu class using the specified text and

destination address.

1.3. SmartMessageFactory Class

It creates messages based on Smart Messaging specification and related messages.

1.4. SmartMessageFactory() Constructor

It initializes a new instance of the SmartMessageFactory class.

1.5. CreateConcatTextMessage(String, String)

It creates concatenated text messages.

96

2. GSM Communication Namespace

It communicates with the phone or modem. For proper operation, a GSM phone or modem

with AT command support is required.

2.1. GsmCommMain Class

It interacts with the GSM modem or phone to execute various functions.

2.2. GsmCommMain(String, Int32, Int32) Constructor

It initializes a new instance of the class using the specified parameters.

2.3. Close() Method

It closes the connection to the device.

2.4. IsConnected() Method

It determines if there is actually a device connected that responds to commands.

2.5. IsOpen() Method

It determines if the port is currently open.

2.6. Open() Method

It opens the connection to the device.

2.7. SendMessages(OutgoingSMSPdu[]) Method

It sends multiple messages in succession. The sending of the messaged stops at the first

error.

2.8. MessageReceived Event

The event occurs when a new message was received.

2.9. MessageSendComplete Event

The event occurs after a successful message transfer.

2.10. MessageSendFailed Event

The event occurs after a failed message transfer.

97

› ... › final_report_4th_progress_final.docx · web viewpage of approval - flipkarma.comin...

Documents