i

An Information Systems Documentation submitted in partial satisfaction of the award of a

Bachelor of Business Information Technology.

Project Title: CityMatrp

A Mobile Matatu Route Management System

By

Student Name: Julie Otieno

Submitted to:

Project Coordinator: Mr.

Submission Date: 8th Nov 2013

ii

Abstract

This paper is a system documentation for the development of CityMatrp, a mobile application

for a Mobile Route Management System. The application provides the functionalities of a route

management system on a mobile device without compromising any capabilities of the route

management system. By using this application each waiting time can be converted into a route

management session at the palm of your hands. The application is developed in an android

environment and therefore will be accessible to any smartphones and tablets that run android

system.

Public use of mobile computing devices such as laptops, PDAs and Tablet PCs is increasing.

Such devices, taken in a higher manageability context, have the potential for a major impact on

route management; it will also help the traffic police in tracking down traffic defaulters as well

as managing traffic.

iii

Declaration

I hereby affirm that this system documentation document is duly my original work and therefore

has not been submitted in any institution for the satisfaction of any academic award.

Student Name: ________________________ Signature: _________________

Date: _____________________

Supervisor Name: ________________________ Signature: _________________

Date: _____________________

iv

Table of Contents

Table of Contents

Abstract ........................................................................................................................................................ ii

Declaration.................................................................................................................................................. iii

Table of Contents ....................................................................................................................................... iv

List of figures .............................................................................................................................................. vi

Abbreviations ............................................................................................................................................ vii

Chapter 1: Introduction ............................................................................................................................. 8

1.1 Background Information ............................................................................................................ 8

1.2 Problem Statement ............................................................................................................................ 8

1.3 Aim ..................................................................................................................................................... 9

1.4 Specific objectives ............................................................................................................................. 9

1.4.1 Project objective ........................................................................................................................... 9

1.4.2 System objective .......................................................................................................................... 9

1.5 Justification ....................................................................................................................................... 9

1.6 Scope ................................................................................................................................................ 10

Chapter 2: Literature Review ................................................................................................................. 11

2.1 Definition of Mobile Route Management System (M-RMS) ....................................................... 11

2.2 The Matatu industry and its stakeholders .................................................................................... 11

2.3 The Concept of Route Management Systems ............................................................................... 12

2.4 The Growth in mobile technology ................................................................................................. 12

2.5 The Mobile platforms ..................................................................................................................... 13

2.5.1 Android ...................................................................................................................................... 13

2.5.2 iOS ............................................................................................................................................. 13

2.5.3 BlackBerry ................................................................................................................................. 13

2.5.4 Windows Phone ......................................................................................................................... 14

2.5.5 Why Android ............................................................................................................................. 14

2.6 Advantages of deploying mobile route management systems ..................................................... 14

Chapter 3: Methodology ........................................................................................................................... 16

3.1 Software Development Life Cycle (SDLC) approach. ................................................................. 16

3.2 Data Collection ................................................................................................................................ 17

3.3 Requirements & Analysis ............................................................................................................... 18

v

3.3.1 Functional System Requirements ............................................................................................... 18

3.3.2 Non-Functional system Requirements ....................................................................................... 18

3.4 Design ............................................................................................................................................... 18

34.1 Architecture ................................................................................................................................. 18

3.5 Deliverables ..................................................................................................................................... 19

3.5.1 System modules ......................................................................................................................... 19

3.6 Development Tools .......................................................................................................................... 20

Chapter 4: System Analysis and Design Description ............................................................................. 21

4.1 Analysis ............................................................................................................................................ 21

4.2 Design ............................................................................................................................................... 22

4.2.1 Architectural Design Approach .................................................................................................. 22

4.2.2 Class diagram ............................................................................................................................... 23

4.2.3 Sequence diagram ........................................................................................................................ 24

4.2.4 Data Dictionary ............................................................................................................................ 25

4.2.5 Database schema .......................................................................................................................... 26

4.2.6 Data Flow Diagram ...................................................................................................................... 27

Chapter 5: Implementation and Testing ................................................................................................. 31

5.1 Implementation methodology ........................................................................................................ 31

5.1.1 Tasks .......................................................................................................................................... 31

5.1.2 A web-based application produced ............................................................................................ 31

5.1.3 A mobile application produced .................................................................................................. 31

5.1.4 Features not implemented .......................................................................................................... 32

5.2 Testing .............................................................................................................................................. 32

5.2.1 Test Basis ................................................................................................................................... 32

5.2.2 Test Approach ............................................................................................................................ 32

Chapter 6: Summary Conclusions and Recommendations ................................................................... 34

References .................................................................................................................................................. 35

Appendices ................................................................................................................................................. 36

Appendix A: Website ............................................................................................................................ 36

Appendix B: Android Mobile Devices ................................................................................................. 37

vi

List of figures

Figure 1: Android ........................................................................................................................................ 14

Figure 2: waterfall model ............................................................................................................................ 16

Figure 3:Architectural design ..................................................................................................................... 22

Figure 4:Class diagram ............................................................................................................................... 23

Figure 5:Sequence diagram ......................................................................................................................... 24

Figure 6:Data dictionary ............................................................................................................................. 25

Figure 7:Database schema .......................................................................................................................... 26

Figure 8:Data flow diagram ........................................................................................................................ 27

Figure 9:Mainpage ...................................................................................................................................... 28

Figure 10:Login page .................................................................................................................................. 29

Figure 11:Administrator .............................................................................................................................. 30

Figure 12:Website ....................................................................................................................................... 36

Figure 14:Android Mobile Devices ............................................................................................................ 37

vii

Abbreviations/Acronyms

ADT - Android Development Tools

SDK : Software Development Kit

SDLC : Software Development Life Cycle

App(s): Acronym for mobile applications

Mat: Acronym for Matatu a Swahili word for a van.

API: Application Programming Interface.

8

Chapter 1: Introduction

1.1 Background Information

CityMatrp is be a mobile application that serves as a Mobile Route Management System

(M-RMS). This app is set to provide the basic functionalities of an online route management

system within a mobile device. It is be aiming to avail information about matatus, connections,

routes, online route maps and for free. Now you can search for any route to any destination

around Nairobi.

Mobile guides through the use of wireless mobile technology allow anyone to access

information and directions at any time. As a result, there are reduced frustrations experienced by

people when travelling. With mobile route management system, people are able to know where

to find the bus stations to their various destinations and get alerts from respective personnel in

charge of the various routes whenever and wherever they want. City council officials, traffic

police and drivers are empowered since they can use the mobile technology to communicate with

the public from anywhere and at any time. At the same time, all users of the application can

share their frustrations, report unlawful acts and post traffic alerts on the application’s forum.

1.2 Problem Statement

Nairobi City is well known for its congestion around East Africa. This causes a big

nightmare to travelers from upcountry, students and visitor who come to the city for the first

time. The situations in the bus stations are usually chaotic and tend to intimidate the public. The

city council of Nairobi introduced a system where all routes within the county shall be uniquely

number and vehicles registered to specific routes. This system was effective in the past but as the

number of vehicles increased the more the more the increase in paperwork. Currently the

paperwork has overwhelmed the county officers and they have since stopped registering Matatu.

This has made it difficult to enforce some measure to tame the situation. The public has also

since stopped receiving announcement about the various routes within the city through the public

address systems in the bus stations. The process of registering matatus to the various routes

wastes time and is inherently error prone, creating a data maintenance nightmare. A mobile

9

application that run on largely used platform, aiming to avail information about matatus,

connections, routes, online route maps and for free, could effectively solve this problem.

1.3 Aim

The objective of this project is to develop a Mobile Route Management System aiming to avail

information about matatus, connections, routes, online route maps and for free. Enable the public

to search for any route to any destination around Nairobi Metropolitan area.

1.4 Specific objectives

1.4.1 Project Objectives

i. To identify ways to control and organize matatu organization.

ii. Analyze ways to maximize productivity for all the stakeholders in the matatu

industry.

1.4.2 System Objectives

i. To design a system architecture consisting of a centralized route numbers

repository based on the routes information

ii. To solve the issues arising when registering matatus to various routes through the

use of their mobile phones.

iii. To create a notification system to allow users of the app to get announcements

using their mobile phones.

iv. To create a standard model of a route management system in a mobile

environment

v. To test the system

1.5 Justification

Building a Mobile Route Management System to augment the current existing web-based route

management system will ease the access to routes information and reduce paperwork involved in

10

rout registration. It will also help the police in tracking down traffic defaulters as well as

managing traffic.

1.6 Scope

This project is specifically be about development of a route management system in a mobile

application without compromising any capabilities of the route management system. Additional

modules may be added to create the interactive capabilities of a mobile system. Since a mobile

route management system must always have a web-based route management system as its

backbone, I have develop a route management system in a web environment to support this

mobile application.

11

Chapter 2: Literature Review

2.1 Introduction

2.2 Definition of Mobile Route Management System (M-RMS)

Mobile Route Management System (M-RMS) is a type of management information system that

in focused on route administration and route information that happens when the users of the

system are not at a fixed, predetermined location, or route management functionality that

happens when the user takes advantage of the opportunities offered by mobile technologies. In

other words, mobile route management system decreases limitation of route administration

location with the mobility of general portable devices.

M-RMS is not intended to replace the web-based route management systems but instead

augment the latter by presenting the functionalities of the web-based route management systems

on a mobile device. Through the use of mobile technologies, the public and route directors have

a simplified experience as they can access avail information about matatus, connections, routes,

online route maps anytime anywhere.

2.2 The Matatu industry and its stakeholders

The Matatu industry in Nairobi city could be described as organized chaos. However, by getting

to understand its stakeholders and networks, it becomes easier to understand how the industry is

actually organized. The stakeholders in this industry include the matatu owners, matatu drivers,

matatu conductors, touts, the traffic police, the county government and the public. This creates a

need for a well-planned and organized system that will enable all the stakeholders to be

seamlessly incorporated in a timely manner. This will lessen the complexity involved in the

process of managing the matatus and ultimately, the true economic potential of the city can be in

turn realized. The mobile app will also seek to address the lack of data and transport knowledge.

There has been no consistent data available regarding matatus this has led to the complexity of

12

the system. It also hinders the stakeholders from making informed choices concerning

acquisition of matatus, which route to register or total number of matatus in the city.

2.3 The Concept of Route Management Systems

Route Management Systems are computer systems, designed to plan a (optimal) route between

two geographical locations using a journey planning engine, typically specialized for road

networks as a road route planner. It can typically provide a list of places one will pass by, with

crossroads and directions that must be followed, road numbers etc. It also usually provides an

interactive map with a suggested route marked on it (“Route planning software”, n.d., para

1).This concept cannot be automatically implemented in the transport system in Nairobi that is

more of a paratransit system. This is because it supplements larger public transit systems by

providing individualized rides without fixed routes or timetables. Thus, a tailored well-planned

and easily accessible system that will seek to address the issue is needed in urgency. By creating

CityMatrp, I will tackle the situation effectively as there are a number of android mobile users in

the city currently. Users may however need to keep the data in their devices up to date this may

involve some operator charges.

2.4 The Growth in mobile technology

The twenty-first century has been characterized by the rapid rate of technology and social

change. This has also seen the rise in mobile industry as a tool for internet access than a tool for

voice communication/telephony. As a result communities are no longer only based on

geographic proximity and new “tribes” (Rheingold, 2002) are developing. Mobile phones free

users from the boundaries of desktops (Mehta, 2008) and allow accomplishing tasks from

anywhere. Power of computing is continuing to be more mobile as more sophisticated gadgets

get smaller. This has seen change in the way developers tackle the existing problems in the

society through mobile apps. The documentation of the existing mobile architecture and

frameworks has led to an increase in mobile developers both globally and locally. The current

13

system user tends to go for more convenient ways to tackle their daily life problems. Now any

waiting time, even in a restaurant, can be used to manage and get matatu route information.

2.5 The Mobile platforms

A mobile platform is also described as an operating system. It includes a hardware architecture

and application framework, where the combination allows applications to run. It is crucial in

application development as it offers the developer an undertaking that logic code will run

consistently as long as the platform is in place (Lashkari & Moradhasheil, 2011).The major types

of mobile platforms are:

2.5.1 Android

Android is a free and open source platform from Google Inc. It is a Linux based operating

system designed for touchscreen mobile devices. This open source code allows software to be

freely modified and distributed by device manufacturer. Android applications are written in java

programming language. For software development, it provides Android SDK.

2.5.2 iOS

iOS is a mobile operating system developed and distributed by Apple Inc. It was primarily

introduced in 2007 for the iPhone but has been extended to support other Apple devices. It does

not license installation on non-Apple devices. It boasts the largest app store with over 500,000

applications (Lashkari & Moradhasheil, 2011).

2.5.3 BlackBerry

It is a proprietary mobile operating system developed by BlackBerry Ltd. (recently RIM) for its

BlackBerry line of smartphone held devices. The available BlackBerry API classes enable third-

party developers to create apps for BlackBerry devices.

14

Figure 1: Android

2.5.4 Windows Phone

Windows Phone is a series of proprietary mobile operating systems developed by Microsoft. It is

the successor to the Windows Mobile operating system and targets consumer market. It supports

c# as its development language (Lashkari & Moradhasheil, 2011).

2.5.5 Why Android

First it is inexpensive; the cost of a device running on android is relative cheaper than the cost of

a device running on blackberry, IOS or windows operating system.

This has been major factor to the buyers of

new smart phones in Kenya than the features

of various systems. Secondly android is

most flexible with a wider market base, it is

the best segment to target as many people

can get access to an android smart phone.

2.6 Advantages of deploying mobile route management systems

i. Majority of city residents have mobile phone compared to PC or laptop

ii. Mobile phones are of smaller size and lighter in weight and therefore can be carried around

anywhere.

iii. Increased visibility; Today’s route managers need to make quicker decisions based on real-time data.

With increased visibility, matatu routes become more agile and more responsive to changes.

iv. Organization in the matatu industry as the county officials can directly have control on matatu

registration.

15

v. Reduced traffic congestion as matatu can be blocked from registering in routes with high number of

matatu.

16

Chapter 3: Research Methodology

3.1 Software Development Life Cycle (SDLC) approach.

The SDLC methodology to be deployed is the Waterfall Methodology. Using this methodology I developed

the mobile application through is a sequential design approach. It was very simple to understand and use. In

a waterfall model, each phase must be completed fully before the next phase can begin. At the end of each

phase, a review takes place to determine if the project is on the right path. Below is a diagram to illustrate

this process:

Figure 2: waterfall model

I chose to use the waterfall development methodology because:

i. It is simple to understand and use.

ii. Easy to manage due to the rigidity of the model – each phase has specific deliverables and a

review process.

iii. Works well for smaller projects where requirements are very well understood

17

iv. Phases are processed and completed at one time

3.2 Data Collection

In order to understand the requirements specification for this mobile application, I collected various data

from the target users prior to the design phase of the development. The data collection methods used

included:

a) Interviews.

This involved both formal and informal interviews to collect the views and opinions of different users about

the idea of a mobile route managing system and possibly identify what areas to put emphasis on during

implementation. I asked questions relating to:

i. Current route management processes.

ii. Technical expertise and development capabilities.

iii. Likes and dislikes about current system/methods.

iv. Communicating events within the bus stations

v. Route numbers used in Nairobi

vi. Design recommendations

b) Questionnaires.

Closed-type questionnaires were mostly used to assess the system modules that this mobile application

should have and also identify any preferences from the target user.

c) Online research.

I did a thorough research on the already existing mobile route management solutions and identifying the

insufficiencies that may be compensated for in this new system. This involved carrying out a bench mark

assessment of any route management system, fleet management and vehicle tracking systems deployed in

various part of the world.

18

3.3 Requirements & Analysis

System requirement are all the capabilities that the news system must have. The purpose is to provide

information for the next steps in the analysis phase to define the scope of the system. An analysis strategy

consists of require analysis techniques and information gathering techniques.

3.3.1 Functional System Requirements

The functional system requirements are:

i. Availing matatu route information.

ii. Registering matatu to various routes

iii. Displaying number of matatu registered to a specific route.

3.3.2 Non-Functional system Requirements

The non-functional system requirements are:

i. Security – Some users are be require to go through an authentication process to login the app.

ii. Consistency of the routes – users may have to keep their app update so as to have the changes made

to the route updated.

3.4 Design

34.1 Architecture

The architecture of our system is centered on a Nairobi city routes repository. This relational database will

contain tables with the different routes information and matatu details. All routes registered in the system

will store their data in this repository. This will enable all app users to access the route data. It will be

necessary to use SQLite database for this type of system be successful.

The application can be used to manage the route information within the repository. Routes created with the

app will be hosted on a central server connects to the routes information repository using a physical three tier

architecture (Olson, 2012) . Thus, apps will have a URL that reflects the central server's name.

19

3.5 Deliverables

3.5.1 System modules

The mobile route management system modules to be delivered in this project include but not limited to:

Public module

This interface displays information about the different routes. It is accessible to all users of the app;

Main Activity (Page) and Tracking system for matatus.

Route director module

Enables route directors to register matatus in the various routes in the city. Route directors are able to

track no. of matatus in their respective routes.

Administrator module

Administrators are able to add/create new routes into the system. They can register new route

directors into the system.

Sms module

Enable all app users to post alerts and announcements about routes, traffic updates, matatus strikes

and report traffic defaulters; that can be received by all app users.

20

3.6 Development Tools

The mobile application was developed by the following development tools:

a) Android development Kit (ADT)

ADT (Android Developer Tools) is a plug-in for Eclipse that provides a suite of tools that are integrated with

the Eclipse IDE. It offers you access to many features that help you develop Android applications quickly.

ADT provides GUI access to many of the command line SDK tools as well as a UI design tool for rapid

prototyping, designing, and building of your application's user interface.

b) Android SDK

Android Software Development Kit (SDK) is set of development tools comprising of debuggers and libraries

for Java programming applications.

c) Eclipse IDE

Eclipse Integrated Development Environment (IDE) is a base workspace for developing applications in Java

and other programming languages (via plug-ins).It is the best IDE to integrate with the android SDK; hence

the decision to include it in this project.

21

Chapter 4: System Analysis and Design Description

4.1 Analysis

The requirements for a system refer to the descriptions of what the system should do—the services that it

provides and the constraints on its operation. These requirements reflect the needs of customers for a system

that serves a certain purpose. Software Requirements Analysis is the process of finding out, analyzing,

documenting and checking these services and constraints. There are two system requirements appreciated

during the development ie. Functional system requirements and Non-functional system requirements

(Extensively covered in Chap. 3.3)

So as to fully understand the various functions the program should perform the following tools were used:

Feasibility Studies – determining whether the product or project is worth the time and effort. It describes

features and benefits of the product, itemizes costs, resources and staffing then describes the projects

potential profits or value to the organization.

Flowcharts – this is the diagrammatic representation of a process. It describes a series of steps or

decisions in visual form in a manner that facilitates communication.

Requirements Lists - should be organized by categories. As the list grows, this list helps the analyst

understand the customer's needs and helps limit what features are necessary and which are not.

22

4.2 Design

4.2.1 Architectural Design Approach

Public

Route director

Administrator

Android device

Android device

Android device

Network Provider

DatabaseRoute repository

Figure 3:Architectural design

23

4.2.2 Class diagram

+get name() : string

+get email() : string

+Staff_id : int

+Email : string

+Name : string

-Password : char

Administrator

+getroute_location() : string

+getroute_no() : char

+getroute_director() : string

+Route_id : int

+Route_director : string

+Route_location : string

+Route_no : char

Route

+getmatatu_regno() : char

+getmatatu_routeno() : char

+getmatatu_driver() : string

#Matatu_regno : char

#Matatu_driver : string

#Route_no : char

Matatu

+getname() : string

+Name : string

+Email : string

+Route_no : char

Director1 M 1 1

1

M

Adds route Has a

1

0..*

Adds matatu

Figure 4: Class diagram

24

4.2.3 Sequence diagram

Mobile Route Information

SystemRoutes repository

Request Route info

Display route info

submit Sql query

Retrive route information

System administrator

commuter

Add route

Status message

Figure 5: Sequence diagram

25

4.2.4 Data Dictionary

Figure 6: Data dictionary

26

4.2.5 Database schema

Figure 7: Database schema

27

4.2.6 Data Flow Diagram

Administrator Add route

Add matatu

Check for

validity

Check for

Validity

Director

Commuter

Route

Matatu

Process

request

Route detailsValid route

details Route details

Matatu details

Valid matatu

details

Matatu details

Matatu info

Invalid detail

Route info

Invalid details

Request route

details

Submit query

Retrieve route

details

Route details

Process

request

Request matatu

details

Request matatu

details

Submit query

Submit queryMatatu details

Matatu details

Figure 8: Data flow diagram

28

Figure 9: Mainpage

29

Figure 10: Login page

30

Figure 11: Administrator

31

Chapter 5: Implementation and Testing

5.1 Implementation methodology

5.1.1 Tasks

Similar to the design methodology, an incremental approach to the implementation of the

mobile application was used. A basic mobile route management system was first implemented

and after being tested and debugged the other features were added to the system. After sufficient

number of features for the mobile application were implemented, work on the GUI started. Every

feature was tested individually and in conjunction with the rest of the system as it was added.

Features had then added and modified in both subsystems until a mobile route management

system was produced, which matched the specification. The subsystems were divided as per

modules. The modules in this project included:

i. Public module

ii. Route director module

iii. Administrator module

iv. Database module

v. User Authentication module

5.1.2 A web-based application produced

A fully operation web-based route management system was produced. The web-based route

management system was produced with PHP backend server script. The implementation of

the GUI subsystem was done using GUI done using html and css3. Certain basic features re-

used as there were many available open source PHP route management frameworks. The web

page was developed to provide supplement the functionality of the mobile application and

where the application can be downloaded.

5.1.3 A mobile application produced

The mobile route management system was produced. The mobile route management system

was produced with PHP backend server script and JSON Arrays to fetch data from the

remote database. Certain basic features had to be implemented from scratch since Android

did not provide convenient packages that implemented them. This include populating spinner

dynamically with data from the remote database. The functionalities and subsystems of the

application was later complied and coupled into a single package. The application will be

distributed as CityMatrp.apk.

32

5.1.4 Features not implemented

A number of features of the CityMatrp were not implemented because of time constraints.

The mapping activity in the application main page was one of these features.

The track matatu functionality was also not implemented, because the select query on schema

was not going through and because the time for completion of the project was running out.

The blog module was also not implemented because of lack in time and limited

documentation on using the blogging framework on Android platform. I decided to use a sms

platform to provide communication between the app users.

5.2 Testing

5.2.1 Test Basis

The testing of the CityMatrp was done as it was implemented. Every element of the system was

individually tested for statement coverage and its functionality verified. Features were only

integrated to the system after they passed the test criteria.

When a feature failed the test criteria, the implementation was debugged and in some occasions

the design revised, until the cause of the error is found and removed.

5.2.2 Test Approach

I used two testing approaches to test the system.

i. Functional testing

ii. Intergrtion testing

Functional Testing

Functional testing was thoroughly performed on the system as a whole. The GUI was tested

whether the appropriate API levels preferences are correctly set.

Most of the functional testing effort was concentrated around the access to the necessary data

either from the local database of remote database.

33

Intergration Testing

I verified the functionality of the app against a target system and platforms. This was in order so

as to get to see the the app performance in different environs based on different density pixels

and API levels

34

Chapter 6: Summary Conclusions and Recommendations

Developing the CityMatrp has been a good learning experience. As the research was done, I

became so fascinated with the level of organisation our city matatu can adapt further study in

this field was considered.

During the course of implementation certain issues came to light that would have enabled a

radical re-design of the system. If the project had to be done again, less time would have been

wasted on learning the basics of the programming language choice, since that took a reasonable

time of this project.

Because of lack in time some features were not implemented that would have made the

CityMatrp a better tool. However these features can be easily added to the system, as well as

some other features mentioned previously later on.

Overall the aim of the project was accomplished and a Mobile Route Management System

aiming to avail information about matatus, connections, routes, online route maps and for free

developed. A reasonably easy to use GUI provided the front end of the system.

However all the work done for this project hardly solve major issues with matatus in the city, and

much further work can be done on this project.

35

References

Gowell J. & McWherther (2009). Professional mobile application development (3rd ed.). USA:

Wiley Publishers.

Lashkari A. & Moradhaseli M. (2011). Mobile Operating Systems and Programming: Mobile

Communications.India: VDM Verlag.

Mehta N. (2008).Mobile Web Development (5th ed.).Great Britain: Pack Publishing.

Rheingold, H (2002) .Smart Mobs:The Next Social Revelution. Arizona: Phoenix.

Route planning software. (2013, July 13). In Wikipedia, The Free Encyclopedia. Retrieved from:

http://en.wikipedia.org/w/index.php?title=Route_planning_softwar

e&oldid=564159275

Rudy De Waele (2013).How Mobile Technology is transforming Africa. Retrieved from:

http://thenextweb.com/africa/2013/07/17/how-mobile-technology-

is-transforming-africa/

Scott Ambler (2007). The Agile System Development Life Cycle. Retrieved from:

http://www.ambysoft.com/essays/agileLifecycle.html

36

Appendices

Appendix A: Website

Figure 12:Website

37

Appendix B: Android Mobile Devices

Figure 13:Android Mobile Devices