Flipkarma



TRIBHUVAN UNIVERSITYInstitute of EngineeringPULCHOWK CAMPUSLALITPUR, NEPAL23882352349500AFINAL YEAR PROJECT REPORT ON“SMS based communication for eWIN system of UN WFP in disaster situations”CODE: CT755Submitted 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 ENGINEERINGDEPARTMENT OF ELECTRONICS AND COMPUTER ENGINNERINGLALITPUR, NEPALAugust 2013TRIBHUVAN UNIVERSITYINSTITUTE OF ENGINEERINGPULCHOWK CAMPUSDEPARTMENT OF ELECTRONICS AND COMPUTER ENGINEERINGThe 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, NepalDATE OF APPROVAL:COPYRIGHTThe 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. TimalsinaHead of Department Department of Electronics and Computer Engineering Pulchowk Campus, Institute of Engineering Lalitpur, Kathmandu Nepal ACKNOWLEDGEMENTWe 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.ABSTRACTUNWFP 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.Keywords: eWIN, SMS, disaster, information collection, visualizationTABLE OF CONTENTS TOC \o "1-3" \h \z \u COPYRIGHT PAGEREF _Toc365289765 \h iiiACKNOWLEDGEMENT PAGEREF _Toc365289766 \h ivABSTRACT PAGEREF _Toc365289767 \h vLIST OF TABLES PAGEREF _Toc365289768 \h viiiLIST OF FIGURES PAGEREF _Toc365289769 \h ixLIST OF ABBREVIATIONS PAGEREF _Toc365289770 \h xi1INTRODUCTION PAGEREF _Toc365289771 \h 21.1Background PAGEREF _Toc365289772 \h 21.2Statement of Problem PAGEREF _Toc365289773 \h 31.3Objectives PAGEREF _Toc365289774 \h 41.4Scope of the Project PAGEREF _Toc365289775 \h 52BACKGROUND STUDY PAGEREF _Toc365289776 \h 72.1eWIN Information Management System PAGEREF _Toc365289777 \h 72.1.1eWIN Features: PAGEREF _Toc365289778 \h 83LITERATURE REVIEW PAGEREF _Toc365289779 \h 103.1Introduction PAGEREF _Toc365289780 \h 103.2SMS-based Information Transfer System PAGEREF _Toc365289781 \h 103.2.1Alert DC PAGEREF _Toc365289782 \h 103.2.2RapidSMS PAGEREF _Toc365289783 \h 113.3Disaster Management System PAGEREF _Toc365289784 \h 113.3.1Syria Food distribution using SMS PAGEREF _Toc365289785 \h 113.3.2Sahana PAGEREF _Toc365289786 \h 113.4Visualization System PAGEREF _Toc365289787 \h 123.4.1Ushahidi PAGEREF _Toc365289788 \h 123.4.2StatSilk PAGEREF _Toc365289789 \h 124REQUIREMENT ANALYSIS AND SPECIFICATION PAGEREF _Toc365289790 \h 144.1High Level Requirements PAGEREF _Toc365289791 \h 144.1.1Features and modules PAGEREF _Toc365289792 \h 154.2Functional Requirements PAGEREF _Toc365289793 \h 165METHODOLOGY PAGEREF _Toc365289794 \h 245.1Project Implementation Methodologies PAGEREF _Toc365289795 \h 245.1.1SMS communication to and from the Web server PAGEREF _Toc365289796 \h 255.1.2SMS formation and transfer from Tablet Application PAGEREF _Toc365289797 \h 265.1.3Incident Reporting From data retrieval using Mobile Device PAGEREF _Toc365289798 \h 285.1.4Disaster Data Collection from Public PAGEREF _Toc365289799 \h 295.1.5SMS parsing PAGEREF _Toc365289800 \h 305.1.6Mapping the SMS format to XML format PAGEREF _Toc365289801 \h 305.1.7Disaster Visualization PAGEREF _Toc365289802 \h 315.2Project Schedule PAGEREF _Toc365289803 \h 336SYSTEM DESIGN PAGEREF _Toc365289804 \h 356.1System Architecture PAGEREF _Toc365289805 \h 356.2Deployment Diagram PAGEREF _Toc365289806 \h 376.3Data Flow Diagram PAGEREF _Toc365289807 \h 386.4Class Diagram PAGEREF _Toc365289808 \h 396.5Tools and Frameworks Used PAGEREF _Toc365289809 \h 437OUTPUT PAGEREF _Toc365289810 \h 457.1eWIN SMS Client Application PAGEREF _Toc365289811 \h 457.2eWIN SMS Server PAGEREF _Toc365289812 \h 478SYSTEM EVALUATION, ANALYSIS AND TESTING PAGEREF _Toc365289813 \h 508.1Testing Methodology PAGEREF _Toc365289814 \h 508.1.1Exploratory Testing PAGEREF _Toc365289815 \h 508.2Test Cases PAGEREF _Toc365289816 \h 518.2.1Functionality and System Tests PAGEREF _Toc365289817 \h 518.2.2Stress Tests PAGEREF _Toc365289818 \h 528.2.3Location Identification Tests PAGEREF _Toc365289819 \h 528.3Test Results PAGEREF _Toc365289820 \h 538.4Test Environment PAGEREF _Toc365289821 \h 549CONCLUSION PAGEREF _Toc365289822 \h 5610LIMITATIONS AND FUTURE WORK PAGEREF _Toc365289823 \h 58REFERENCES PAGEREF _Toc365289824 \h IAPPENDIX A: DATA FLOW DIAGRAMS PAGEREF _Toc365289825 \h IIIAPPENDIX B: SPARROW SMS DOCUMENTATION PAGEREF _Toc365289826 \h VAPPENDIX C: EWIN SYSTEM DIAGRAMS AND SNAPSHOTS PAGEREF _Toc365289827 \h IXAPPENDIX D: PROTOCOLS PAGEREF _Toc365289828 \h XIAPPENDIX E: EWIN QUESTIONNAIRE AND ANSWER XML DESCRIPTION PAGEREF _Toc365289829 \h XIIIAPPENDIX F: GSMCOMM LIBRARY PAGEREF _Toc365289830 \h XXLIST OF TABLES TOC \f T \h \z \t "Heading 6" \c Table 1: Specification of actor – UNWFP Field Monitor PAGEREF _Toc365289849 \h 17Table 2: Specification of actor – eWIN Server PAGEREF _Toc365289850 \h 17Table 3: Specification of actor – eWIN SMS Server PAGEREF _Toc365289851 \h 17Table 4: Specification of Use Case – Transfer information via SMS PAGEREF _Toc365289852 \h 18Table 5: Specification of Use Case – Log into the system PAGEREF _Toc365289853 \h 18Table 6: Specification of Use Case – Update PAGEREF _Toc365289854 \h 18Table 7: Specification of Use Case – Delete PAGEREF _Toc365289855 \h 19Table 8: Specification of Actor – Administrator PAGEREF _Toc365289856 \h 20Table 9: Specification of Actor – eWIN Server PAGEREF _Toc365289857 \h 20Table 10: Specification of Actor – eWIN SMS Server PAGEREF _Toc365289858 \h 20Table 11: Specification of Use Case – Receive text message PAGEREF _Toc365289859 \h 21Table 12: Specification of Use Case – Fetch Questionnaire XML PAGEREF _Toc365289860 \h 21Table 13: Specification of Use Case – Create hash table PAGEREF _Toc365289861 \h 21Table 14: Specification of Use Case – Generate and send answer XML file PAGEREF _Toc365289862 \h 22Table 15: Specification of Use Case – View transfer history and info-graphics PAGEREF _Toc365289863 \h 22Table 16: Specification of Use Case – Log into the system PAGEREF _Toc365289864 \h 22Table 17: Brief description of classes used in Application Server PAGEREF _Toc365289865 \h 40Table 18: Brief description of classes used in Tablet Application PAGEREF _Toc365289866 \h 42Table 19: Result of Answer XML generation test PAGEREF _Toc365289867 \h 53Table 20: Result of Webpage Loading without Mapping Elements PAGEREF _Toc365289868 \h 53Table 21: Result of Webpage Loading with External Elements PAGEREF _Toc365289869 \h 54Table 22: Environment Details PAGEREF _Toc365289870 \h 54Table 23: Matrix Type of Questionnaire PAGEREF _Toc365289871 \h XVLIST OF FIGURES TOC \f F \h \z \t "Heading 5" \c TOC \h \z \t "Heading 5" \c Figure 1: eWIN Top Level Architecture PAGEREF _Toc365289872 \h 7Figure 2: eWIN SMS Server simple block diagram PAGEREF _Toc365289873 \h 14Figure 3: eWIN SMS Client simple block diagram PAGEREF _Toc365289874 \h 14Figure 4: Use Case Scenario for eWIN SMS Client PAGEREF _Toc365289875 \h 16Figure 5: Use Case Scenario for eWIN SMS Server PAGEREF _Toc365289876 \h 19Figure 6: Overall System Block Diagram PAGEREF _Toc365289877 \h 24Figure 7: Steps for SMS communication to and from the Web server PAGEREF _Toc365289878 \h 25Figure 8: Implementation of Incoming SMS API PAGEREF _Toc365289879 \h 25Figure 9: Implementation of Outgoing SMS API PAGEREF _Toc365289880 \h 26Figure 10: Steps to form and send SMS from Tablet Application PAGEREF _Toc365289881 \h 27Figure 11: Steps employed to obtain incident data using Mobile Device PAGEREF _Toc365289882 \h 28Figure 12: Steps employed to obtain disaster data from Public PAGEREF _Toc365289883 \h 29Figure 13: Steps to parse SMS message before sending from tablet application PAGEREF _Toc365289884 \h 30Figure 14: Steps to parse SMS message after received in server PAGEREF _Toc365289885 \h 30Figure 15: Steps to map SMS message to XML PAGEREF _Toc365289886 \h 31Figure 16: Steps to visualize disaster data into Map of Nepal PAGEREF _Toc365289887 \h 32Figure 17: Works Completed GANTT Chart PAGEREF _Toc365289888 \h 33Figure 18: Works Remaining GANTT Chart PAGEREF _Toc365289889 \h 33Figure 19: System Block Diagram PAGEREF _Toc365289890 \h 35Figure 20: Deployment Diagram PAGEREF _Toc365289891 \h 37Figure 21: Context Level DFD for Tablet Application PAGEREF _Toc365289892 \h 38Figure 22: Context Level DFD for Application Server PAGEREF _Toc365289893 \h 38Figure 23: eWIN SMS Server Class Diagram PAGEREF _Toc365289894 \h 39Figure 24: eWIN SMS Client Class Diagram PAGEREF _Toc365289895 \h 41Figure 25: Tablet Application Login Interface PAGEREF _Toc365289896 \h 45Figure 26: GUI Showing Unsynchronized Records PAGEREF _Toc365289897 \h 45Figure 27: GUI after ID ‘33257457602’ has been sent as SMS PAGEREF _Toc365289898 \h 46Figure 28: Refreshed GUI after SMS has been sent PAGEREF _Toc365289899 \h 46Figure 29: Login Interface of Application Server PAGEREF _Toc365289900 \h 47Figure 30: Index Page of Application Server PAGEREF _Toc365289901 \h 47Figure 31: ‘WFP Incident Reporting Form’ Interview Details PAGEREF _Toc365289902 \h 48Figure 32: Disaster Visualization PAGEREF _Toc365289903 \h 48Figure 33: Disaster Details PAGEREF _Toc365289904 \h 48Figure 34: Exploratory Testing PAGEREF _Toc365289905 \h 50Figure 35: Application Server DFD Level-0 PAGEREF _Toc365289906 \h IIIFigure 36: Tablet Application DFD Level-0 PAGEREF _Toc365289907 \h IVFigure 37: eWIN Logo PAGEREF _Toc365289908 \h IXFigure 38: eWIN Deployment Architecture PAGEREF _Toc365289909 \h IXFigure 39: eWIN Home Screen PAGEREF _Toc365289910 \h XFigure 40: eWIN Tablet Application Home Page PAGEREF _Toc365289911 \h XFigure 41: Web Service Documentation for Validating a User using HTTP GET PAGEREF _Toc365289912 \h XIIFigure 42: Web Service Documentation for getting Questionnaires List using HTTP GET PAGEREF _Toc365289913 \h XIIFigure 43: Web Service Documentation for Questionnaire XML retrieval using HTTP GET PAGEREF _Toc365289914 \h XIIFigure 44: Questionnaire “PRRO Refugees Food Basket Monitoring Counter Monitoring” PAGEREF _Toc365289915 \h XIIIFigure 45: Questionnaire XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring” PAGEREF _Toc365289916 \h XIVFigure 46: Answer XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring” PAGEREF _Toc365289917 \h XVFigure 47: Sample Questionnaire “IOE_Sample” PAGEREF _Toc365289918 \h XVIFigure 48: XML for Sample Questionnaire “IOE_Sample” PAGEREF _Toc365289919 \h XVIIFigure 49: Answer XML for Sample Questionnaire “IOE_Sample” PAGEREF _Toc365289920 \h XVIIIFigure 50: Questionnaire “UNWFP Incident Reporting Form” PAGEREF _Toc365289921 \h XVIIIFigure 51: XML for Questionnaire “UNWFP Incident Reporting Form” PAGEREF _Toc365289922 \h XIXFigure 52: Answer XML for Questionnaire “UNWFP Incident Reporting Form” PAGEREF _Toc365289923 \h XIXLIST OF ABBREVIATIONSAPIApplication Programming InterfaceCBCell BroadcastCOMCommunicationDCDistrict of ColumbiaDEWNDisaster Early Warning NetworkDFDData Flow DiagramGPRSGlobal Packet Radio ServiceGSMGlobal System for Mobile CommunicationHTTPHyper Text Transfer ProtocolITInformation TechnologyPDAPersonal Digital AssistantSMSShort Messaging ServiceSOAPSimple Object Access ProtocolUNUnited NationsUNWFPUnited Nations World Food ProgramURLUniform Resource LocatorXMLExtended Markup LanguageIntroductionINTRODUCTION BackgroundDisaster, 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. 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.ObjectivesSMS implementation of eWIN system for UNWFPThe 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.eWIN SMS server as a bridge between eWIN server and client mobile devicesThe 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.Tablet application developmentAn 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.Disaster information collection through public and visualizationAs 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.Scope of the ProjectWhat it does?Allows quick flow of information for eWIN system only in the event of unavailability of Internet service.Primarily used for post disaster situations, however, can be extended to other equally sensitive situations too.Provides simple mapping and visualization of disaster information.What it does not do?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.Is not a replacement of the current eWIN system rather complements its limitations. Does not work if mobile telecommunication infrastructure is down.Based on the assumption that the users are literate enough to send text messages.Background StudyBACKGROUND STUDYeWIN Information Management System390042317421400eWIN 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.10642603076271Figure 1: eWIN Top Level Architecture0Figure 1: eWIN Top Level ArchitectureeWIN Features:a. Versatile Client ApplicationTablet PC and smartphones for field surveys. Data transfer using cellular and satellite networksDesktop application for data management, analysis and reporting.GIS surveys with map-based data collection.User-friendly tile based graphical interface.b. Robust Server ApplicationScalable 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 rolesc. Versatile Server ApplicationComplete 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 FrameworkPersonalized user dashboards.Dynamic graphical reports including 2D and 3D graphs and charts.Literature ReviewLITERATURE REVIEWIntroductionSMS 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: SMS-based Information Transfer SystemAlert DCThe 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 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].RapidSMSRapidSMS 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.Disaster Management System Syria Food distribution using SMSAlthough 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].SahanaSahana 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. Visualization SystemUshahidiUshahidi 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. StatSilkStatSilk 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. Requirement Analysis and SpecificationREQUIREMENT ANALYSIS AND SPECIFICATIONHigh Level RequirementsThe 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.495300167983eWIN SMS ServerInputOutputAnswer XMLDependencyQuestionnaire XML from eWIN serverMessage in specified SMS formatFigure 2: eWIN SMS Server simple block diagrameWIN SMS ServerInputOutputAnswer XMLDependencyQuestionnaire XML from eWIN serverMessage in specified SMS formatFigure 2: eWIN SMS Server simple block diagram663408322077Figure 3: eWIN SMS Client simple block diagrameWIN SMS ClientInputOutputAnswer SMSDependencyData from existing local databases of eWIN ClientTransfer Request0Figure 3: eWIN SMS Client simple block diagrameWIN SMS ClientInputOutputAnswer SMSDependencyData from existing local databases of eWIN ClientTransfer RequestFeatures and modulesThe features that the system offers can be listed as below:New Tablet ApplicationAs 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 ServerThis 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 DataIn 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 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 publicWe 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 dataAfter 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.Functional Requirements53975944317eWIN ServerFigure 4: Use Case Scenario for eWIN SMS ClientLogin to the SystemTransfer Data via SMSUpdateDeleteUNWFP Field Monitor<<includes>><<extends>><<extends>>eWIN SMS ServereWIN SMS Client00eWIN ServerFigure 4: Use Case Scenario for eWIN SMS ClientLogin to the SystemTransfer Data via SMSUpdateDeleteUNWFP Field Monitor<<includes>><<extends>><<extends>>eWIN SMS ServereWIN SMS ClientSpecification of actorsUNWFP Field MonitorUNWFP Field MonitorElementDetailDescriptionUNWFP Field Monitor is the person who conducts survey in the field and uses the client application to transfer information via SMS120765431214Table 1: Specification of actor – UNWFP Field Monitor00Table 1: Specification of actor – UNWFP Field MonitoreWIN ServereWIN serverElementDetailDescriptioneWIN SMS server is the already existing webserver that validates the login of the UNWFP Field Monitor into the eWIN SMS client14809859690Table 2: Specification of actor – eWIN Server00Table 2: Specification of actor – eWIN ServereWIN SMS ServereWIN SMS serverElementDetailDescriptioneWIN SMS server is the newly created webserver that receives text message from the clients126550632385Table 3: Specification of actor – eWIN SMS Server00Table 3: Specification of actor – eWIN SMS ServerSpecification of use casesTransfer information via SMSTransfer information via SMSElementDetailActive ActorUNWFP Filed MonitorPassive ActoreWIN SMS serverDescriptionUNWFP Filed Monitor makes a request to transfer information via SMS and thus transferred text message is intercepted by the eWIN SMS server7804152082602Table 4: Specification of Use Case – Transfer information via SMS00Table 4: Specification of Use Case – Transfer information via SMS Log into the systemLog into the systemElementDetailActive ActorUNWFP Field MonitorPassive ActoreWIN serverDescriptionUNWFP Field Monitor logs into the system with credentials which are validated by communicating with the eWIN server1165118-2540Table 5: Specification of Use Case – Log into the system00Table 5: Specification of Use Case – Log into the systemUpdateUpdateElementDetailDescriptionOnce a particular text message has been sent successfully, the sync status of its associated record is updated in the eWIN client’s database143825038504Table 6: Specification of Use Case – Update00Table 6: Specification of Use Case – UpdateDeleteDeleteElementDetailDescriptionOnce a particular text message has been sent successfully, its associated record is deleted from the eWIN SMS client’s database140245945815Table 7: Specification of Use Case – Delete00Table 7: Specification of Use Case – Delete-20320403860<<extends>>Figure 5: Use Case Scenario for eWIN SMS ServerReceive SMS MessagesCreate hash table between received SMS messages and fetched XML attributesFetch Questionnaire XMLeWIN ServerAdministratoreWIN SMS ClientGeneate and send answer XML fileView transfer history and info-graphicsLog into the system<<extends>><<extends>><<includes>>eWIN SMS Server00<<extends>>Figure 5: Use Case Scenario for eWIN SMS ServerReceive SMS MessagesCreate hash table between received SMS messages and fetched XML attributesFetch Questionnaire XMLeWIN ServerAdministratoreWIN SMS ClientGeneate and send answer XML fileView transfer history and info-graphicsLog into the system<<extends>><<extends>><<includes>>eWIN SMS ServerSpecification of actorsAdministratorAdministratorElementDetailDescriptionAdministrator is the person who has successfully logged into the eWIN SMS server1450340-6350Table 8: Specification of Actor – Administrator00Table 8: Specification of Actor – AdministratoreWIN ServereWIN serverElementDetailDescriptioneWIN server is the already existing webserver that sends the questionnaire XML file to the eWIN SMS server, and receives the answer XML file from it145778715240Table 9: Specification of Actor – eWIN Server00Table 9: Specification of Actor – eWIN ServereWIN SMS ServereWIN SMS serverElementDetailDescriptioneWIN 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 server130340817631Table 10: Specification of Actor – eWIN SMS Server00Table 10: Specification of Actor – eWIN SMS ServerSpecification of use casesReceive text messageReceive text messageElementDetailActive ActoreWIN SMS client542973700813Table 11: Specification of Use Case – Receive text message00Table 11: Specification of Use Case – Receive text messageDescriptionThe text message sent by the eWIN SMS client via SMS is received by the eWIN SMS serverFetch questionnaire XMLFetch questionnaire XMLElementDetailPassive ActoreWIN serverDescriptionThe questionnaire XML file corresponding to the questionnaire code contained in the text message is fetched from the eWIN server93540318822Table 12: Specification of Use Case – Fetch Questionnaire XML00Table 12: Specification of Use Case – Fetch Questionnaire XMLCreate hash table Create hash tableElementDetailDescriptionWhen the questionnaire XML file has been fetched successfully, a hash table is created between the received text message and the fetched XML tags107785963731Table 13: Specification of Use Case – Create hash table00Table 13: Specification of Use Case – Create hash tableGenerate and send answer XML fileGenerate and send answer XML fileElementDetailPassive ActoreWIN serverDescriptionThe answer XML file is generated from the hash table and it is sent to the eWIN server73025071120Table 14: Specification of Use Case – Generate and send answer XML file00Table 14: Specification of Use Case – Generate and send answer XML fileView transfer history and info-graphicsView transfer history and info-graphicsElementDetailActive ActorAdministratorDescriptionThe 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 feature53190018712Table 15: Specification of Use Case – View transfer history and info-graphics00Table 15: Specification of Use Case – View transfer history and info-graphicsLog into the systemLog into the systemElementDetailActive ActorAdministratorDescriptionThe administrator needs to log into the system with the valid credentials1022985189230Table 16: Specification of Use Case – Log into the system00Table 16: Specification of Use Case – Log into the systemMethodologyMETHODOLOGYProject Implementation Methodologies27962120002511569703515183Figure 6: Overall System Block DiagramFigure 6: Overall System Block DiagramThe 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:SMS communication to and from the Web server1344863165608000The system is supposed to handle two basic instances of SMS transferone 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: 8787733462020Figure 7: Steps for SMS communication to and from the Web server00Figure 7: Steps for SMS communication to and from the Web serverIn 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:106461131674if 'text' in request.GET and request.GET['text']:SMS = request.GET['text']00if 'text' in request.GET and request.GET['text']:SMS = request.GET['text']1114681393671Figure 8: Implementation of Incoming SMS API00Figure 8: Implementation of Incoming SMS APIAfter 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:12312651599565Figure 9: Implementation of Outgoing SMS API00Figure 9: Implementation of Outgoing SMS API348615179705url_part = {'client_id':client_id, 'username':username, 'password':password, 'from':SMS_from, 'to':SMS_to, 'text':message}api_url = '?' + urllib.urlencode(url_part)response = urllib2.urlopen(api_url)message_response = response.read()00url_part = {'client_id':client_id, 'username':username, 'password':password, 'from':SMS_from, 'to':SMS_to, 'text':message}api_url = '?' + urllib.urlencode(url_part)response = urllib2.urlopen(api_url)message_response = response.read()By providing the required details such as client_id, username, password, SMS_from, SMS_to and message and calling the URL provided in the Outgoing API, message can be successfully pushed to the destination mobile number.SMS formation and transfer from Tablet ApplicationA 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:7169150Figure 10: Steps to form and send SMS from Tablet Application0Figure 10: Steps to form and send SMS from Tablet ApplicationFollowing the above stated steps, the SMS message generating from the tablet application will be in the following format:WFP<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]<space>[respondent_attr4]………………….Example: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 1169001Incident Reporting From data retrieval using Mobile Device3919473845433Figure 11: Steps employed to obtain incident data using Mobile Device00Figure 11: Steps employed to obtain incident data using Mobile Device1010241706471In 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: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.Disaster Data Collection from PublicTo 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: 1896183179227Figure 12: Steps employed to obtain disaster data from Public00Figure 12: Steps employed to obtain disaster data from Public105837420000The SMS format for public is defined asWFP<space>disaster<space>[disaster occurred address(VDC Name)]<space> [disaster name]<space>[disaster descriptioin]Example:WFP disaster Lubhu,Lalitpur flood 2 house destroyed, 3 missingSMS parsingWhile 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:2881630284480002032028501600209553950970Figure 13: Steps to parse SMS message before sending from tablet application00Figure 13: Steps to parse SMS message before sending from tablet application30727653950335Figure 14: Steps to parse SMS message after received in server00Figure 14: Steps to parse SMS message after received in serverMapping the SMS format to XML formatUpon 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 would convert to if it transferred the filled interview to the eWIN server using the internet. For this purpose, following steps are employed:5902214675505Figure 15: Steps to map SMS message to XML00Figure 15: Steps to map SMS message to XML1243512000Disaster VisualizationThe 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.3403603215664Figure 16: Steps to visualize disaster data into Map of Nepal00Figure 16: Steps to visualize disaster data into Map of Nepal143347643700Implementation 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.Project Schedule352975816Figure 17: Works Completed GANTT Chart0Figure 17: Works Completed GANTT Chart1736502685415Figure 18: Works Remaining GANTT ChartFigure 18: Works Remaining GANTT ChartSystem DesignSYSTEM DESIGN-157340253678Figure 19: System Block DiagrameWIN Client DatabaseSMS ProtocoleWIN SMS Client ApplicationSparrow SMS APIWeb ServerSMS Validator / IdentifierSMS to XML Mapper SMS Parser Webpage ResourcesVisualization TooleWIN Server eWIN DatabaseApplication DatabaseSMS ProtocolNative SMS ApplicationTablet DevicesMobile DevicesClient SideApplication Server SideeWIN Server SideSMSSMSSMSDataDataDataAnswer XMLDataeWIN SMS Client Database0Figure 19: System Block DiagrameWIN Client DatabaseSMS ProtocoleWIN SMS Client ApplicationSparrow SMS APIWeb ServerSMS Validator / IdentifierSMS to XML Mapper SMS Parser Webpage ResourcesVisualization TooleWIN Server eWIN DatabaseApplication DatabaseSMS ProtocolNative SMS ApplicationTablet DevicesMobile DevicesClient SideApplication Server SideeWIN Server SideSMSSMSSMSDataDataDataAnswer XMLDataeWIN SMS Client DatabaseSystem ArchitectureThe 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.Deployment Diagram55308535560<<device>>: Web Server<<artifact>>: eWIN SMS Server Website<<artifact>>: SMS-to-XML Mapping Rules<<device>>: Tablet Client<<artifact>>: eWIN SMS Client UI<<artifact>>: SMS Formulating Rules<<device>>: Mobile Phone<<artifact>>: Messaging Service00<<device>>: Web Server<<artifact>>: eWIN SMS Server Website<<artifact>>: SMS-to-XML Mapping Rules<<device>>: Tablet Client<<artifact>>: eWIN SMS Client UI<<artifact>>: SMS Formulating Rules<<device>>: Mobile Phone<<artifact>>: Messaging Service142430532385Figure 20: Deployment Diagram0Figure 20: Deployment DiagramThe 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.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.7946501678495Figure 21: Context Level DFD for Tablet Application00Figure 21: Context Level DFD for Tablet Application79848932554600Data Flow Diagram737235186118500The 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.965466808535Figure 22: Context Level DFD for Application Server00Figure 22: Context Level DFD for Application ServerThe 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.Class Diagram5044971006650The 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. 12297114824095Figure 23: eWIN SMS Server Class Diagram0Figure 23: eWIN SMS Server Class DiagramThe brief description of the classes used in our Application Server are summarized in the following table:S.No.Class NamePurpose1.Interview_ClassTo maintain the database about:which questionnaire’s data is received in our server using the SMSthe number of interview data receiveddate and time of the received SMSdevice from which SMS is received whether the data is sent to server or not2.Answer_ClassPrepare the database for a new incoming Answer SMSWrite the Answer XML using the data from the database answer table3.Questionnaire_ClassGet Questionnaire XML from eWIN serverInsert the tag’s attributes to the database questionnaire table4.Incident_ClassTransforms incident related data sent by UNWFP Field Monitors using Mobile device to answer XML5.Database_Lock_ClassTo prevent multiple incoming SMS Messages from simultaneously reading and writing in the database6.Outgoing_SMSTo push a response message to the number from which SMS is received7.Public_SMS_ClassHandle disaster related data sent by the Public8.Mapper_ClassProvide the mapping library with the address and disaster description4245677225030Table 17: Brief description of classes used in Application Server00Table 17: Brief description of classes used in Application Server621030636270Figure 24: eWIN SMS Client Class DiagramFigure 24: eWIN SMS Client Class DiagramIn 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:S.No.Class NamePurpose1.eWINDatabaseRepresent the existing local databases namely, “UNWFP_db.sdf” and “UNWFP_geosite_db.sdf” of the eWIN clientProvide methods to retrieve the elements of a particular record scattered among different data sourcesUpdate the record status upon synchronization with the eWIN serverS.No.Class NamePurpose2.AttributesMaintain the ‘Attributes’ table in databaseBuild SMS Message from the Attributes Table3.UserInterfaceSolely used for the GUI4.SMSEncapsulates methods that handle the sending of SMS message via serial port (COM) portFacilitates:Opening of the serial portSending of SMS Message to the serial portClosing of the serial port6832602761881Table 18: Brief description of classes used in Tablet Application00Table 18: Brief description of classes used in Tablet ApplicationTools and Frameworks UsedProgramming Language(server side): python 2.7XML Processor: lxml XML toolkit 3.2.0Programming Language(Tablet Application): c#Framework: Django 1.5.1/.net framework v4.0Database: MySQL/ SQL Server Compact Edition v3.5Versioning: Github()UI(Tablet Application): DevExpressDocumentation: MS Word/Excel/PowerPoint GSM Library(Tablet Application): GsmComm LibraryIDE: Aptana Studio, Visual Studio 2010Webserver: Django development serverMapping: D3.js, Jquery, Topojson.js, Queue.jsOutputOUTPUT1519384483907eWIN SMS Client Application15206542036918Figure 25: Tablet Application Login InterfaceFigure 25: Tablet Application Login Interface814269160000Figure 26: GUI Showing Unsynchronized Records0Figure 26: GUI Showing Unsynchronized Records6261100Figure 27: GUI after ID ‘33257457602’ has been sent as SMS0Figure 27: GUI after ID ‘33257457602’ has been sent as SMS12522204639945Figure 28: Refreshed GUI after SMS has been sent0Figure 28: Refreshed GUI after SMS has been sent523677772143eWIN SMS Server-6151240656Figure 29: Login Interface of Application ServerFigure 29: Login Interface of Application Server-46723720048Figure 30: Index Page of Application Server0Figure 30: Index Page of Application Server60515528187650011010902453640Figure 31: ‘WFP Incident Reporting Form’ Interview Details00Figure 31: ‘WFP Incident Reporting Form’ Interview Details-44450001558290135255Figure 32: Disaster Visualization00Figure 32: Disaster Visualization17145003066415Figure 33: Disaster Details 00Figure 33: Disaster Details 50990546609000System Evaluation, Analysis and TestingSYSTEM EVALUATION, ANALYSIS AND TESTINGTesting 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.Testing MethodologyThis 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.Exploratory Testing17145002170070Figure 34: Exploratory Testing00Figure 34: Exploratory Testing128968580127500Exploratory 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 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. Test CasesIn 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:Functionality and System TestsThe 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.Stress TestsAs 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.Location Identification TestsAs 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.Test ResultsThe test results for different test cases are summarized below:Answer XML generation for answer SMS of different questionnaires received from TabletS.No.Questionnaire NameQuestionnaire SizeAnswer XML Generation TimeRun 1Run 2Run 31Food price and unskilled wage rate collection checklist10 KB4 sec5 sec5 sec2PRRO Refugees Post-Distribution Monitoring69 KB26 sec22 sec24 sec3FCFA Activity Monitoring 2012 - Beneficiaries35 KB18 sec15 sec16 sec4OLD_NeKSAP Rural Household Survey Questionnaire55 KB22 sec21 sec20 sec135069557678Table 19: Result of Answer XML generation test00Table 19: Result of Answer XML generation testTotal webpage load time without Mapping elements (including external files)Run TestsFull Document Load time(milliseconds)Run 1119Run 2115Run 3203768350141473Table 20: Result of Webpage Loading without Mapping Elements00Table 20: Result of Webpage Loading without Mapping ElementsTotal webpage load time with mapping elements (including external files and external data files)File size of JSON containing data co-ordinates of Nepal : 1414 KBTotal size of included javascript files/libraries : 155 KBPage Load time for Elements besides map elements (in milliseconds)Mapping elements (in milliseconds)Run 12101276Run 22721358Run 328513951008981144279Table 21: Result of Webpage Loading with External Elements00Table 21: Result of Webpage Loading with External ElementsTest EnvironmentThe development and testing of our project is done in the following hardware and software environment:Application Server DevelopmentTablet Application DevelopmentVisualizationComputer ModelHP DV4-2153CLHP EliteBook 8470wDell N4110ProcessorIntel(R) Core(TM) i3 CPU 2.13GHzIntel(R) Core(TM) i7 CPU 2.70GHzIntel(R) Core(TM) i3 CPU 2.70GHzPhysical Memory1910 MB4096 MB6144 MBOSWindows 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)1709898141795Table 22: Environment Details00Table 22: Environment DetailsConclusionCONCLUSIONThe major accomplishments of the project have been summarized below:The SMS implementation of the eWIN system has been achieved successfullyeWIN SMS server to handle information via SMS text messages has been createdeWIN SMS tablet client application for information transfer via SMS text messages has been developedThe mapping and visualization of the disaster information sent by public via SMS text messages has been includedThe 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.Limitation and Future WorkLIMITATIONS AND FUTURE WORKDue to time and resources-constraint many features couldn’t be incorporated. There are still few limitations to our systemThe 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 modulesAdvance parser to identify the incident type received from public SMS and categorization of incidents accordinglyIncorporating disaster management features like early disaster warnings, resource management, relief and rescue managementInteractive visualization for more prevalent form of representing incident status and meaningful ways to impart those information.ReferencesREFERENCESAlert DC, Government of the District of Columbia. .Retrieved 13/02/2013.RapidSMS Projects. RapidSMS. . Retrieved 13/02/2013.Syria: Food distribution to start for vulnerable Iraqi refugees. UNHCR Report. 31 August 2007. . Retrieved 9/02/2013.Sahana. Sahana Software Foundation. . Retrieved 08/02/2013.Ushahidi. Ushahidi. . Retrieved 08/02/2013.StatPlanet visualization and mapping software. StatSilk. . Retrieved 08/05/2013.SMS Tutorial. Developers Home. .Disaster and Emergency Warning Network (DEWN). Dialog Telekom PLC, Dialog-University of Moratuwa (UoM) and Mobile Communications Research Laboratory and Microimage. . Retrieved 15/02/2013. Sparrow SMS API Documentation. Sparrow SMS. , Michael. D3 Wiki. , Mike. Let’s Make a Map. , Andy and Cem Kaner (2003). Exploring Exploratory Testing.Appendix45974095885000APPENDIX A: DATA FLOW DIAGRAMS13550024937760Figure 35: Application Server DFD Level-000Figure 35: Application Server DFD Level-011644506290219Figure 36: Tablet Application DFD Level-000Figure 36: Tablet Application DFD Level-0-2961214APPENDIX B: SPARROW SMS DOCUMENTATIONSparrow 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.timestamptimestamp of the time when the incoming SMS hits the Sparrow SMS Gateway serverkeywordThe first word of the incoming SMS texttextThe text after shifting the first word of the SMS contentfromPhone number of the SMS SendertoThe shortcode to which the SMS was receivedPossible Conditions to relay the Incoming SMSSparrow 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 beAll Incoming Requests ( External Relay )When a valid keyword was hit ( Keyword Relay )When some validation pattern was matched, for example. numbers or alphabets, or any alphanumeric word .etc. ( Validation Relay )Outgoing (Push) API Parameters and EndpointAPI Endpointcall_in? this endpoint when required to track response to each API calls.ParametersusernameUsername provided during the API signupPasswordPassword provided during the API signupclient_idclient_id provided during the API signupfromused when multiple senders are allowed‘from’ parameter needs to be supplied at the time of each API requestidentitysending identitynot used if ‘from’ is defined for the accounttothe number to send SMS tomust be a urlencoded comma separated list of phone numbers each of the numbers being either of the following formats10 digits phone number eg. 984100000010 digits phone number and a ‘+’ at the beginning eg. +984100000010 digits phone number and country code ‘977’ or ‘+977’ at the beginning eg. 9779841000000, +9779841000000characters ‘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 too9841-00-00-009841 00 00 00+9841 00 00 00+9841-00-00-00+9779841 00 00 00+9779841-00-00-009779841 00 00 009779841-00-00-00anything other than these formats is regarded as an Invalid Numbertextthe text to be sentmust be urlencodedAccess LimitationsThe API usage access is restricted under the following domainsUsername / passwordusername and password must match with the details provided during signup and aren’t changeableclient_idprovided during the API signupIP AddressIP address limitation is on highest level and the API access is limited to the whitelisted IP addresses only.CreditsSMS 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.APPENDIX C: EWIN SYSTEM DIAGRAMS AND SNAPSHOTS16047213138981962785416560Figure 37: eWIN Logo00Figure 37: eWIN Logo17348203897630Figure 38: eWIN Deployment Architecture00Figure 38: eWIN Deployment Architecture17281633565087Figure 39: eWIN Home Screen00Figure 39: eWIN Home Screen-25403568949931983575008Figure 40: eWIN Tablet Application Home Page00Figure 40: eWIN Tablet Application Home PageAPPENDIX D: PROTOCOLSProtocolsThe 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:CheckValidUserGetFileListsGetFileListsStringGetFileListsStringOracleGetStringXmlGetStringXmlOracleLoadMultiMediaDataLoadXmlStringSyncRespondentMgmtDatagetAllRespondentsgetMonitoringPlanListXMLgetQuestionnaireWithRulegetQuestionnaireWithSkipXmlgetQuestionnaireXmlgetRespondentTypeThese 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 questionnaires available in the system and getting specific questionnaire XML. The list of Web Services we have used are:CheckValidUserGetFileListsStringOraclegetQuestionnaireXmlWe have implemented these Web Services using HTTP GET protocols. The Documentation of these Web Services using HTTP GET proctocol are listed below:2857501781810Figure 41: Web Service Documentation for Validating a User using HTTP GET00Figure 41: Web Service Documentation for Validating a User using HTTP GET2576571756081Figure 42: Web Service Documentation for getting Questionnaires List using HTTP GET00Figure 42: Web Service Documentation for getting Questionnaires List using HTTP GET1556841776730Figure 43: Web Service Documentation for Questionnaire XML retrieval using HTTP GET00Figure 43: Web Service Documentation for Questionnaire XML retrieval using HTTP GETAPPENDIX E: EWIN QUESTIONNAIRE AND ANSWER XML DESCRIPTIONThe 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.43011347371000An image of a questionnaire titled “PRRO Refugees Food Basket Monitoring Counter Monitoring” available in the eWIN system is shown below:-25404680357Figure 44: Questionnaire “PRRO Refugees Food Basket Monitoring Counter Monitoring”00Figure 44: Questionnaire “PRRO Refugees Food Basket Monitoring Counter Monitoring”The corresponding XML for the above questionnaire is shown below:-29614381030Figure 45: Questionnaire XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring”00Figure 45: Questionnaire XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring”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 Radio button Single choice answer with all answer shown at a timeCheck Box Multiple choice answers Date Date type answer GPS GPS Coordinate as answer Group Grouping of questions likeNumber of committee members Total __ Female __ Dalit __ Janajati __Matrix Matrix type of question likeRiceSugarWheatKathmanduLalitpurBhaktapur118177976375Table 23: Matrix Type of Questionnaire00Table 23: Matrix Type of QuestionnaireAfter 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 -3175958850Figure 46: Answer XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring”00Figure 46: Answer XML for “PRRO Refugees Food Basket Monitoring Counter Monitoring”Basket Monitoring Counter Monitoring” is shown below: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.257942736600Figure 47: Sample Questionnaire “IOE_Sample”00Figure 47: Sample Questionnaire “IOE_Sample”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: 7831966449060Figure 48: XML for Sample Questionnaire “IOE_Sample”00Figure 48: XML for Sample Questionnaire “IOE_Sample”-6350000457758-2540Figure 49: Answer XML for Sample Questionnaire “IOE_Sample”00Figure 49: Answer 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:62599529787Figure 50: Questionnaire “UNWFP Incident Reporting Form”00Figure 50: Questionnaire “UNWFP Incident Reporting Form”5028554517499Figure 51: XML for Questionnaire “UNWFP Incident Reporting Form”00Figure 51: XML for Questionnaire “UNWFP Incident Reporting Form”-5715308857002517442303145Figure 52: Answer XML for Questionnaire “UNWFP Incident Reporting Form”00Figure 52: Answer XML for Questionnaire “UNWFP Incident Reporting Form”APPENDIX F: GSMCOMM LIBRARYGSMComm 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 ConverterGSM CommunicationPDU Converter NamespaceThe 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. SMSSubmitPdu ClassIt represents an SMS-SUBMIT PDU, an outgoing short message.SMSSubmitPdu(String, String) ConstructorInitializes a new instance of the SMSSubmitPdu class using the specified text and destination address.SmartMessageFactory ClassIt creates messages based on Smart Messaging specification and related messages.SmartMessageFactory() Constructor It initializes a new instance of the SmartMessageFactory class.CreateConcatTextMessage(String, String)It creates concatenated text messages. GSM Communication NamespaceIt communicates with the phone or modem. For proper operation, a GSM phone or modem with AT command support is required.GsmCommMain ClassIt interacts with the GSM modem or phone to execute various functions.GsmCommMain(String, Int32, Int32) ConstructorIt initializes a new instance of the class using the specified parameters.Close() MethodIt closes the connection to the device.IsConnected() MethodIt determines if there is actually a device connected that responds to commands. IsOpen() Method It determines if the port is currently open.Open() MethodIt opens the connection to the device.SendMessages(OutgoingSMSPdu[]) MethodIt sends multiple messages in succession. The sending of the messaged stops at the first error. MessageReceived EventThe event occurs when a new message was received.MessageSendComplete EventThe event occurs after a successful message transfer.MessageSendFailed EventThe event occurs after a failed message transfer. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download