CHAPTER 1

INTRODUCTION

The development of Rwanda today has took another level in all fields, the integrant of
technology in all those field has made contribution to the good quality of services and put the
country on top in the country which are developing fast.

As also the population of Rwanda increasing we need to come-up with technical solutions to
enhance the quality of services offered in all fields especially in health and security of the
services has an impact to the Rwandan citizens.

When the population of the country is increasing the number of the service requests also
increase, and the old fashion of providing those services become inefficient, that is the reason we
need other new solutions to improve the way of provide good services to many citizens in the
shortest time possible, and the use of technology is the reliable solution.

In order to achieve Rwanda’s long-term goals for development of the country, Rwanda needs
some improvement in giving good services, innovations, use of technology, and so on. For those
reasons this project will focus on the use of the technology by providing good services especially
in the field of security and health where the process of calling the police for emergencies help
still an inefficient way of serving Rwandan citizens.

Background of the emergency police services

Rwanda has established a fast way of helping the citizens in case where the thieves attach any
home, in case of the accidents or any emergencies that require the police help to the citizen, and
today in Rwanda police stations have one or more trap cars bait to help in transportation when
they have any emergency.

If any thieves are going on or if any accident or any emergency occur the citizens are advised to
call the ambulance on a free call number of police (112 emergency, 113 traffic accident), the
those number was provided by Rwanda national police to help the citizens in case of
emergencies that require a police help in order to save citizens lives and security as quick as
possible.
In general, the Rwanda national police has a division that handles the emergence calls and when
the emergency call is received the caller is required to provide the location where the emergency
police help needed, and at the police emergency call center, an agent is the one to find the nearest
available police helper according to the address provided by the caller.

Statement of the Problem

 Due to the very long loop or cycle of calls from the location of the emergency calling to
the police emergency call center and the center’ agent searching for the available police
helper for the provided location, so the process took long time putting in consideration
that someone’s life is in danger.
 Basing on the emergency location provided by the caller, the police can lose its way to
the emergency location due to the misunderstanding or misguidance about the emergency
location or the police helper in charge of that area they can be on another field helping
and may not be the nearest due to the misguidance about the emergency.

So here down there are some issues caused by this actual system:

o Loss of lives due to latency

o Resource wasting due to misguidance about the location.
o Inefficient use of time due to long processes.

Motivation

As every Rwanda citizen it is my duty to contribute to the development of my country, and as an

undergraduate candidate from AUCA am motivated to contribute to my country’s development
by using the technology to prove the technical solutions and best services to the society
especially in the security sectors.

This study will be used by other student as a reference in order to guide them especially for those
who will need to improve this work those who will have related topics.

This study will help the Rwanda national police to make a good and well-structured management
heling in case of emergency and follow-up will be easier, this study will simplify the process and
make the services faster and efficient.
 Objectives

This study has general and specific objectives as they are stated in the following subsections:

General objectives:

General objectives of this project as they are to design and implement nearest police helper
Tracking System for emergency case in Rwanda to help the Rwanda national police to provide
a modern way of helping the citizens.

Specific objectives:

o To implement an android application used for tracking nearest available police helper.
o To develop an application capable of providing the coordinate of the emergency.
o To develop an application that can handle many requests at the same time.
o To generate a periodic report the Rwanda national police can use.
o To develop an application that provides fast services to save the times wasted.

Project scope

This project is focusing on the way the emergency requesting the police help were handled and
how can we use the technology to provide an efficient way of helping Rwanda citizens, and the
system will provide the report of information regarding to the system using the new android
application; the system will be accessed using mobile-phone or any android devices (tablets, ets)
and internet.

Time scope: As far as the system analysis has been done. The development time is 4 months.

Geographical scope: since the project’s case study is in Rwanda, geographical scope will be
limited in Rwanda.

Challenges

The most crucial challenge I have faced in this work is that the developing such system requires
enough information, analysis and understanding, so it took many to avoid system errors
providing good analysis.
 Requirement collection techniques

Data collection can be gathered from a number of sources, which including documents, the
workplace, focus groups, field notes, questionnaires and social interaction or interviews. The
followings are techniques used in the analysis of existing system.

Documentation

Documentation is oriented towards a methodical diggings of all writings linked with the research
domain and it helped me to collect useful documents (prescription forms) related to how
emergency police call center system works.

Interview

Interview is used as a systematic conversation between me and the RNP in order to obtaining
relevant to this research project.

Expected results

The new system is expected to give the following results:

 The police stations will be able to upload the information of their trap helping cars.
 The citizens will be able to create their accounts and upload their information.
 Citizens will be able to track the nearest available trap helping cars.
 The police helper team will be able to get the exact coordinates of the citizen requesting
help.
 The system is expected to provide the reports automatically.
 No more mistakes as the correction will be done by the system.
 No more claims because the system will generate accurate information.
 The system will provide different reports for the Rwanda national police.

Organization of the work

The first chapter gives the general description of the work, includes an introduction, the
background of the study, Statement of problem, the motivation of the problem (motivation), the
objective of the work, challenges, limitation of the study.
The second chapter will highlight in details how the existing information system works and
proposed solution to problems found in the existing system.

It is in the same chapter that definitions of the keywords used in this project will be found. This
analysis of existing system brings us to the third chapter. This chapter, use to emphasis in a clear
and concise way the whole process followed to achieve our goal.

The third chapter is made up by the design of the new system to solve the problems of the
existing system. It is about the design of the system and the conception of the system of
information.

The fourth chapter will come to highlight the implementation of the newly designed information
system which will be developed to resolve problems found in the existing system and to add
more facilities.

Finally, the fifth chapter will contain a conclusion and recommendation related to result.
 CHAPTER 2

ANALYSIS OF THE EXISTING SYSTEM

Introduction

This chapter contains two important elements: The analysis of the existing system and the newly
proposed system. This study is about the conception of a new system for the nearest police
helper tracking system. This cannot be achieved without going through the analysis of the
existing system in order to get all necessary requirements of the new system.

In this chapter, I will illustrate in a clear way the organization in which the system will be used
by showing, a brief history, how the existing system was being used, the problem of existing
system and solutions to be brought by the new system.

Description of the current system environment

History

The service was created on 16 June 2000 by law No. 09 of 2000 and merged three earlier forces,
the Gendarmerie National of the Ministry of Defense, the Communal Police of the Ministry of
Internal Affairs and the Judicial Police of the Ministry of Justice

Mission

The mission of this study is: To provide Rwandan citizens with the highest quality pre-hospital
care and police helping services through a unified team of caring professionals, and to easy the
communication between citizens, and the police emergency helping team.

Vision
The vision of this study is to provide an efficient fast way of accessing security care services to
increase rapid intervention in cases of emergency such as thieves, accidents and many other
security-related crises that may befall Rwandans.

Methodology Used

The Iterative Waterfall Model is the development methodology that will be used in this project to
implement The Nearest police helper Tracking System. This model is derived from the evolution
of the Traditional Waterfall Model. It consists of five phases, which includes; the Requirement
and Definition, System and Software Design, Implementation and testing, System testing,
Operation and maintenance. Each of these phases is repeated if an error is discovered, this
enables the correction of errors before moving to the next phase.

Description of the current system

The process of requesting the police for emergencies is currently done in the following ways: the
RNP has a division that handles the emergency calls, when a call is received requesting for the
help, the citizen is required to provide the location where the helping team is needed, and at the
police emergency call center an agent is the one to find the nearest available police helping team
according to the address provided by the caller.
The above figure shows the process of the current way of emergency police helper service where
the citizen or the police has to call the trap car emergency communication center, and at the
center they search for the nearby available trap car helper and dispatch the that team to help the
citizen or to catch the thieves and put them in prison.

Problems of the current system

Long cycle of calls: Due to the very long cycle of calls from the citizen requesting the help to
the police emergency communication call center and the center’ agent searching for the available
police team according to the provided address, so the process took long time putting in
consideration that someone’s life is in danger.

Misguidance: Basing on the emergency address provided by the citizen, the helping team can
lose its way to the emergency address due to the misunderstanding or misguidance about the
emergency address, or the police team called may not be the nearest due to the misguidance

Inefficient usage of time: time is wasted in the cycle where citizens have to call to the police
emergency communication call center and the center call the available police team.

Data recording: there is no way of recording citizens helped by the emergency police team.

Poor Reporting: there is no way of providing efficient reports for evaluation purpose

Proposed Solution
No cycle of calls: the new system will provide a direct contact between the citizen and the police
helper team.

Best guidance: the system will provide for the police helping team the exact coordinate of the
citizen requesting the help.

Efficient usage of time: time will be save due to the faster and few process for requesting the
help.

Data recording: the new system will provide a way of recording citizen’s information.

Better reporting: the system will provide efficient report for evaluate the quality of the services
given to citizens.

Requirements of the New System

Functional Requirements

Police station

 Police station should be able to upload their trap cars and helping team information.
 Police station should be able to view and update, delete their traps cars and helping team
information.
 Police station should get a report of their trap cars and helping team’s activities.

Citizen

 Citizens should be able to upload their personal information.

 Citizen should be able to view the nearest available helping team.

System

 The system must only allow a user to login by using a valid username and password.
 The system should track the nearest police helper team using Google map.
 The system should provide the exact coordinates of the alerting user.
 The user should be able to logout once he/she finishes the alert.
 The system should be able to assignee a new password once is needed.
 The system must be able to retrieve the information from the database.
  They system must be able to validate while entering the information.

Non Functional Requirements

Maintainability:

 The system should be easily to maintain it, once is needed

Security:

 The system must be able to hide the users information

 The system includes all available safeguards from viruses, worms and Trojans Etc.
 The System will block you once you clicks 3 times on login steps

Operational:

 The system should be able to run on any android OS.

User friendly:

 The System will be user friendly

 The system must be easy for a user to user.

Privacy:

 The system shall be able to protect the users privacy

Availability:

 The system shall have high availability

 The system shall not have unexpected downtime
 The system shall have downtime at most 3 hours/month
 CHAPTER 3

ANALYSIS AND DESIGN OF THE NEW SYSTEM

Introduction

After understanding the current system, its failure, its weakness, and the needed improvement to make it
more efficient by analysis, the next step will be the design of the new system. Deep analysis of users’
needs will most of the time lead to a useful software development as a system might give perfect result.
By knowing the input needed by the system, how will be processed and their output will leads in knowing
plan to implement new system. This chapter will focus on how the system will accomplish objectives
through designing.

System design is the process of defining the architecture, components, modules, interfaces, and data for a
system to satisfy specific requirement. System design is done from the study of the existing system in
order to determine what changes will be needed to incorporate the user needs that were not met by the
existing one. The output of this phase will consist of the specifications, which must describe both what
the proposed system will do and how it will work actually defining the solutions.[ CITATION Dou05 \l
1033 ]

Analysis and Design Methodology

Object-Oriented Methodology (OOM)

There are many system development approaches that can be used in the development of software. But we,
we are going to focus to the Object-Oriented which use a language called Unified Modeling Language
(UML) to describe the system concept as a collection of objects. Incorporating data, process and the
Unified process (UP) will be also used for our software.

The Unified Modeling Language (UML) is a general-purpose modeling language in the field of software
engineering. It provides a set of graphic notation techniques to create visual models of object-oriented
software-intensive systems. It was developed by Grady Booch, Ivan Jacobson and James Rumbaugh at
Rational Software in the 1990s. It was adopted by the Object Management Group (OMG) in 1997, and
has been managed by this organization ever since. In 2000 the

Unified Modeling Language was accepted by the International Organization for Standardization (ISO) as
a standard for modeling software-intensive systems. [ CITATION Jam06 \l 1033 ]

The Unified Modeling Language (UML) offers a standard way to visualize a system's architectural
blueprints, including elements such as:

 Activities
 Actors
 Business processes
 Database schemas
 (logical) components
 Programming language statements
 Reusable software components.

Object-oriented analysis and design

Object-oriented analysis and design (OOAD) is a popular technical approach to analyzing, designing an
application, system, or business by applying the object-oriented paradigm and visual modeling throughout
the development life cycles to foster better stakeholder communication and product quality. There are a
number of different notations for representing these models, but our case the Unified Modeling language
(UML) will be used as mentioned above.[ CITATION Ala12 \l 1033 ]

Object-oriented analysis

Used of modeling to define and analyze the requirements necessary for success of a system. Object-
oriented analysis is a process that groups items that interact with one another, typically by class, data or
behavior, to create a model that accurately represents the intended purpose of the system as a whole.
Object-oriented analysis does not factor implementation limitations into the model.[CITATION BAR12 \l
1033 ]

Object-oriented design

Object-oriented design is the process of planning a system of interacting objects for the purpose of
solving a software problem. Start with the candidate objects defined during analysis, but add much more
rigor to their definitions. Then you add or change objects as needed to redefine a solution. Object-oriented
design (OOD) elaborates the analysis models to produce implementation specifications. While OOA
focuses on what the system does, OOD focuses on how the system does it.[ CITATION Ala12 \l 1033 ]

Object-oriented programming (OOP)

Object-oriented programming (OOP) is a programming paradigm that represents concepts as "objects"

that have data fields (attributes that describe the object) and associated procedures known as methods.
Objects, which are usually instances of classes, are used to interact with one another to design
applications and computer programs: C++, Objective-C, Smalltalk, Java, C#, Perl, Python, Ruby and PHP
are examples of object-oriented programming languages. Object-oriented programming (OOP) is a
programming language model organized around objects rather than "actions" and data rather than logic.
[ CITATION Ala12 \l 1033 ]

Historically, a program has been viewed as a logical procedure that takes input data, processes it, and
produces output data. The Unified Modeling Language is a graphical modeling that provides us with
syntax for describing the major elements of software systems. The UML is used to specify, visualize,
modify, construct and document the artifacts of an object-oriented software-intensive system under
development.

intensive system under development.

UML Concepts

The description of the object-oriented programming has highlighted the extent of the necessary
conceptual work: defining classes, relationships, attributes and methods, interfaces etc.

The following are UML useful notations:

Class: is a description of a collection of objects with common attributes and behaviors. A class is divided
in three parts as shown below:

Class Name
Attributes

Operations()

 The upper part holds the name of the class.

 The middle part contains the attribute of the class.
  The last part gives the method or operation the class can take or undertake.
An attribute is a named property of a class that describes a range of values that instances of the property
may hold. A method is the implementation of a service that can be requested from any object to the class
to affect behavior.
An attribute is a named property of a class that describes a range of values that instances of the property
may hold.
A method is the implementation of a service that can be requested from any object to the class to affect
behavior.
Relationships:
A relationship is a connection among things.
The three most important relationships are association, generalization and dependency
A primary purpose of a class diagram is to show the relationships, or associations, that classes have with
one another[ CITATION Spr07 \l 1033 ]. These are depicted on the diagram by drawing lines between
classes.
 Association
Use cases are connected to actors through association relationships; these relationships show with which
use cases the actors interact. A line drawn from an actor to a use case depicts an association. The
association typically represents two-way communication between the use case and the actor.
It is represented by the following line.

 Generalization
Generalization is a relationship between a general kind of thing (called the super class or parent)
and a more specific kind of thing (called the subclass or child). It is denoted by as the following:

 Aggregation

It is a plain association between two classes represents a structural relationship between peers, meaning
that both classes are conceptually at the same level, no one more important than the other

1 *

 Composition
This is a form of aggregation, with strong ownership and coincident lifetime as part of the whole.

1 *

 Dependency
Dependence is a weaker form of relationship which indicates that one class depends on another
because it uses it at some point of time.

 Extend

In another form of interaction, a given use case (the extension) may extend another. The relationship
indicates that the behavior of the extension use case may be inserted in the extended use case under some
conditions. The notation is a dashed arrow from the extension to the extended use case, with the label
«extend». The notes or constraints may be associated with this relationship to illustrate the conditions
under which this behavior will be executed.[ CITATION Ala12 \l 1033 ]

Modelers use the «extend» relationship to indicate use cases that are "optional" to the base use case.
Depending on the modeler's approach "optional" may mean "potentially not executed with the base use
case" or it may mean "not required to achieve the base use Case goal".

«Extends»

Actor: An actor is not a specific user, but instead is a role that a user can play while interacting with the
system. An actor can also represent another system in which the current system interacts. In this
case, the actor optionally can be represented by the following stick figure labeled with the actor
name: [ CITATION Jam06 \l 1033 ]
Use Case: is a major process that the system will perform that benefits an actor or actors in some way and
it is labeled using a descriptive verb–noun phrase, it also represents a major piece of system
functionality.[CITATION BAR12 \l 1033 ] It is represented as follow

System boundary boxes (optional)

A rectangle is drawn around the use cases, called the system boundary box, to indicate the scope
of system. Anything within the box represents functionality that is in scope and anything outside
the box is not.[ CITATION Jam06 \l 1033 ]

System

But in this project we will focus only on Actor, Use Case, and System boundary as UML
notations.
Software development process
In software engineering, Software development process is a division of software development work into
distinct phases or stages containing activities with the intent of better planning and
management[ CITATION Kra09 \l 1033 ]. It is often considered a subset of the systems development life
cycle. The methodology may include the pre-definition of specific deliverables and artifacts that are
created and completed by a project team to develop or maintain an application. In my concerning, I am
going to develop an application which will meet the user’s needs.

Object-oriented approaches to developing information systems, technically speaking, can use any of the
traditional methodologies (waterfall development, parallel development, phased development,
prototyping, and throwaway prototyping). However, the object oriented approaches are most associated
with a phased development RAD methodology.[ CITATION Ala12 \l 1033 ]
The primary difference between a traditional approach like structured design and an object oriented
approach is how a problem is decomposed. In traditional approaches, the problem decomposition process
is either process centric or data centric. However, processes and data are so closely related that it is
difficult to pick one or the other as the primary focus. Based on this lack of congruence with the real
world, new object-oriented methodologies have emerged that use the RAD-based sequence of SDLC
phases but attempt to balance the emphasis between process and data by focusing the decomposition of
problems on objects that contain both data and processes. Both approaches are valid approaches to
developing information systems. In this book, we focus only on object-oriented approaches.[ CITATION
Jam06 \l 1033 ]

Unified Process (UP)

Unified process (UP) is a software development process (SDP) also known as software engineering
process (SEP), SDP is the process in which we turn user requirements into software[ CITATION BAR12 \l
1033 ]. It tells the workers, activities, and artifacts that is needed to utilize, perform or create in order to
model a software system (It defines the Who, What, When, and How of a software development).

One of its characteristics is that UP is an iterative and incremental development process. Iterative aspect
means that the project has to be broken into small subprojects (called iterations) which are easier to
manage and to complete successfully. UP is incremental because each iteration generates a baseline that
comprises a partially complete version of the final system and any associated project documentation.
Baselines build on each other over successive iterations until the final finished system is achieved.
[ CITATION Jam06 \l 1033 ]

UP phases (Inception, Elaboration, Construction and Transition) are divided into a series of time boxed
iterations. Each iteration results in an increment, which is of the system that contains added or improved
functionality compared with the previous release.[ CITATION Ala12 \l 1033 ]

Analysis of the new system

The analysis phase answers the question of who will use the system, what the system will do, and where it
will be used.

Systems analysis is the dissection of a system into its component pieces to study how those component
pieces interact and work. Those pieces are called use case.
A very powerful UML tool is the Use Case. A Use Case is simply a description of a set of interactions
between a user and the system. [ CITATION Jam06 \l 1033 ]

Use case
A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements. The use case is made up of a set of possible sequences of interactions between systems and
users in a particular environment and related to a particular goal. The use case should contain all system
activities that have significance to the users. A use case can be thought of as a collection of possible
scenarios related to a particular goal[ CITATION Eil06 \l 1033 ].

A use case is the description of the model "View" by the actors in the system. It corresponds to the
expected needs of each actor (the WHAT and WHO). Use cases are used to represent the operation of the
system vis-à-vis the user, so this is a view of the system in its external environment.

The symbols below are used in use case diagram:

Description Shape
An actor:
 Is a Person or system that derives benefit from
and is external to the subject.
 Is depicted as either a stick figure (default) or if a
nonhuman Action is involved, as a rectangle with
« actor » in it (alternative).
 Can be associated with other actors using a Actor Name
specialization/superclass Field, denoted by an
Arrow with a hollow arrowhead.
A use case:
 Represents a major piece of system functionality
 Can extend another use case
Use Case
 Can include another use case.
 Is placed inside the system boundary
 Is labeled with a descriptive verb–noun phrase.
 A boundary: Boundary

 It is a box drawn around the use case to

denote the edge or boundary of the system
being modeled.
 Includes the name of the subject inside or on
top.
 Represents the scope of the subject, e.g. a
system or an individual business process.
An Field relationship:
 Links an actor with the use case(s) with
which it interacts.
1 Table: Use case symbol