Vehicle Management

MULTIMEDIA UNIVERSITY OF KENYA
FACULTY OF BUSINESS AND LAW

DEPARTMENT OF ACCOUNTING AND FINANCE
BACHELOR OF BUSINESS INFORMATION TECHNOLOGY

VEHICLE REGISTRATION AND INVESTIGATION SYSTEM
MWANGI DUNCAN NJOROGE

BUS-242-035/2012
PROJECT SUPERVISOR: MR. ADUNYA. J
MAY- SEPTEMBER 2012
Contents
LIST OF FIGURES
Figure 1.1: Gannt Chart for the Schedule. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 17
Figure 4.1: Context Diagram. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -28
Figure 4.2: Program Data flow Diagram. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -29
Figure 4.3: Program Flowchart. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 30
Figure 4.4: Entity relationship model of Motor Vehicle Licensing System - - - - - - - - -31
Figure 4.5: admin login- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 34
Figure 4.6: Home Page - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 35
Figure 4.7: Overview model of registration module. - - - - - - - - - - - - - - - - - - - - - - - - 36
Figure 4.8: Overview model of vehicle module. - - - - - - - - - - - - - - - - - - - - - - - - - - - -37
Figure 4.9: Complaints Module- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -38
LIST OF TABLES
Table 1.1: Economic Feasibility - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -16
Table 1.2: Schedule Feasibility - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 17

Table 4.1: Admin Log in- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 31
Table 4.2: Vehicle Owners - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -31
Table 4.3: Vehicles- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 32
Table 4.4: Stolen Vehicles- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -32
Table 5.1: requirements summary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 42
Table 6.1: white box testing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 44
CHAPTER ONE
1.0.
INTRODUCTION ..........................................................................................................9
1.1.
VISION STATEMENT .................................................................................................. 10
1.2.
MISSION STATEMENT................................................................................................ 10
1.3.
OVERVIEW OF THE EXISTING SYSTEM. ....................................................................... 11
1.4.
PROBLEM DEFINITION ............................................................................................... 11
1.5.
SYSTEM OBJECTIVES.................................................................................................. 11
1.5.1.
Aim of the system..................................................................................................... 12
1.5.2.
Objectives of the system. ......................................................................................... 12
1.6.
JUSTIFICATION .......................................................................................................... 14
1.7.
SCOPE OF THE SYSTEM .............................................................................................. 14
1.8.
LIMITATIONS OF THE PROPOSED SYSTEM .................................................................. 15
1.9.
FEASIBILITY REPORT .................................................................................................. 15
1.9.1.
Economic Feasibility ............................................................................................... 15
1.9.2.
Schedule feasibility .................................................................................................. 17
1.9.3.
Gannt Chart for the Schedule. ............................................................................... 17
1.9.4.
Technical feasibility. ................................................................................................ 18
1.10.
CONCLUSION......................................................................................................... 18
2.0.
LITERATURE REVIEW ................................................................................................. 19
2.2.
Automation And Law Enforcement ............................................................................ 19
2.3.
The Need for Vehicle Registration and Investigation System in................................... 21
2.3.1.
Home Office Large Major Enquiry System (HOLMES) ..................................... 21
2.3.2.
Violent Criminal Apprehension System (VICAP) ................................................ 21
2.3.3.
Crime Report Information System (CRIS) ........................................................... 22
2.3.4.
Crime Pattern Analysis System (CPAS) ................................................................ 22
2.4.
Proposed System Desirable Features ......................................................................... 23
2.5.
Conclusion ................................................................................................................ 24
3.0.
ANALYSIS .................................................................................................................. 25
3.1.
Introduction ............................................................................................................. 25
3.2.
Overview .................................................................................................................. 25
3.3.
Requirements specification ....................................................................................... 25
3.3.1.
Non-Functional Requirements ............................................................................... 26
3.3.2.
Specific Requirements ............................................................................................. 26
4.0.
DESIGN ..................................................................................................................... 27
4.1.
DESIGN METHODOLOGY ........................................................................................... 27
4.2.
System Architecture Description ............................................................................... 27
4.2.1.
Context Diagram ..................................................................................................... 27
4.2.2.
Data Flow Diagram ................................................................................................. 28
4.3.
DATABASE DESIGN .................................................................................................... 31
4.4.
Entity relationship diagrams ..................................................................................... 33
4.5.
INTERFACE DESIGN ................................................................................................... 34
4.5.1.
Admin Login ............................................................................................................ 34
4.5.2.
Home page ................................................................................................................ 35
4.5.3.
Owner Details Registration.................................................................................... 35
4.5.4.
Vehicle Details Form .............................................................................................. 36
4.5.5.
Complaints Form .................................................................................................... 37
5.0.
SYSTEM IMPLEMENTATION ....................................................................................... 38
5.1.
Introduction ............................................................................................................. 38
5.2.
Implementation Overview ........................................................................................ 38
5.3.
Description of Implementation.................................................................................. 38
5.4.
Justification for the Changeover Method ................................................................... 39
5.5.
Major Tasks in Implementation ................................................................................. 39
5.5.1.
Installation................................................................................................................ 39
5.5.2.
Training .................................................................................................................... 39
5.5.3.
Execution .................................................................................................................. 39
5.5.4.
Review....................................................................................................................... 39
5.6.
System Requirements ............................................................................................... 39
5.6.1.
Software Requirements ........................................................................................... 39
5.6.2.
Hardware Requirements......................................................................................... 40
5.7.
Choice of Development Tools .................................................................................... 41
5.8.
Coding ...................................................................................................................... 42
5.9.
Integrating Modules.................................................................................................. 43
6.0.
SYSTEM TESTING....................................................................................................... 44
6.1.
Introduction ............................................................................................................. 44
6.2.
Unit Testing .............................................................................................................. 44
6.2.1.
Black-Box Testing.................................................................................................... 44
6.2.2.
White-Box Testing ................................................................................................... 47
6.2.3.
Integration Testing .................................................................................................. 47
6.2.4.
Registration Window Test ...................................................................................... 48
6.2.5.
Login Window Test ................................................................................................. 48
6.2.6.
General User Window Test..................................................................................... 48
6.3.
System Testing .......................................................................................................... 48
7.0.
PROBLEMS ENCOUNTERED IN DEVELOPMENT PROCESS ............................................. 50
Inadequate time ................................................................................................... 50
Power failure........................................................................................................ 50
7.1.
Limitations and Achievements of the System ............................................................. 50
8.0.
USER GUIDE .............................................................................................................. 52
8.1.
INTRODUCTION ........................................................................................................ 52
8.2.
System Installation ................................................................................................... 52
8.3.
LOADING/UNLOADING THE SYSTEM .......................................................................... 53
9.0.
BIBLIOGRAPHY .......................................................................................................... 59
APPENDIX ............................................................................................................................ 61
DEDICATION
I dedicate this project to my family for their love, understanding and support during the
entire project period.
God bless my entire family.
ACKNOWLEDGEMENT
I would like to express my sincere appreciation to the following people whose

contribution helped me greatly in compiling, transcription, editing, review and
presentation of the project.
My Friends and my family for their financial and moral support.
My classmates for their support during discussions and all those other members
of MMU in fraternity who offered constructive criticism which resulted to the
success of this project.
Finally my vote of thanks goes to all my lecturers and more so Mr. Adunya who
guided me throughout my entire project.
Above all I give all the glory and honor to the almighty God for everything.
DECLARATION
This entire documentation is the authors original work and therefore no one shall have the right
to copy, reproduce or present this project documentation without the authors knowledge and
authority.
Author..
Sign...
Date
1.0.
CHAPTER ONE
INTRODUCTION
NAIROBI AREA POLICE HEADQUARTERS serves as the headquarters of the

Kenya Police in charge of Nairobi County and its immediate environs. The headquarters
are located at the New Nairobi Area Police Headquarters along Milimani Road. It is
mandated to discharge its duties according to the Police Act, section 14 which stipulates
that its responsibility is to:
Maintain law and order
Preserve peace
Protect life and property
Prevent and detect crime
Apprehend offenders
Enforce all law and regulations with which we are charged.
Apart from the above-mentioned functions, being in the capital city it is also undertake
all special operations for state and coverage of international functions.
The Kenya police began its operations between 1887 and 1902, by the Imperial British
East Africa (I.B.E.A.) Company. It was until 1907 that Kenya police was organized along
military line and the training was military in nature. In 1906 the Kenya police was legally
constituted by police ordnance. The Nairobi provincial police headquarter had its first
Provincial Police Officer (P.P.O). In 1958, until late 1960s they were known as Chief
Police Officers. To date, it has had a total of eighteen (18) provincial police officers.
Covering a large area Nairobi area is divided into different divisions and units in order to
curb crime effectively. In October 2004 Nairobi was extended to a Greater Nairobi
covering Magadi, Mlolongo, Syokimau, Kiamumbi and Kinoo taking up parts of Rift
valley, Eastern and Central provinces respectively. Currently it has a total of nine (9)
police divisions, which include:
1. Gigiri Police division.

2. Langata Police Division.
3. Ngong Police Division.
4. Kasarani Police Division.
5. Embakasi Police Division.
6. Central Police Division.
7. Kayole Police Division.
8. Buruburu Police Division.
9. Kasarani Police Division.
There are also special units which deals specifically with particular criminal activities.
This project is based on, or will cover the registration of new vehicles and investigation
of stolen vehicles within Nairobi and its immediate environs in the Police Divisions;
which is one of their roles as stipulated in the Police Act, section 14.
1.1.
VISION STATEMENT
Nairobi Area Police headquarters vision is to create a secure Nairobi with effective and
efficient police service, which is proactive in reducing crime as well as being disaster
prepared.
1.2.
MISSION STATEMENT
To reduce crime and promote development by providing high quality police service
through:
10
Upholding and applying the law fairly and firmly and

Creating and maintaining community solidarity through corporation with police
and local leaders.
1.3.
OVERVIEW OF THE EXISTING SYSTEM.
All the Nairobi Area Police Divisions are currently using a paper based system where
only the stolen or lost vehicle records are manually filled on paper files or the Occurrence
Book with absolutely no amount of automation.
1.4.
PROBLEM DEFINITION.
The following problems were sighted in the current system and have since then
influenced the need for a new system to be developed to address these problems. It was
found that with the current system;
Lack of Data Integrity- the Nairobi Police Headquarters does not maintain a
parallel Database of all the registered vehicles in the country with Kenya Revenue
Authority and as such it becomes a problem in identifying the real vehicle owner
in case of theft or act of terrorism.
Storage space and retrieval of information- The current system stores
information in file cabinets and this makes it time consuming to retrieve a record
of a previously stored records this makes it even more difficult for an Officer in
Charge of a crime to update record in the archives whenever a vehicle is found.
Data duplication- This arises when information on a stolen vehicle to be
recorded in more than one police station leading to data redundancy.
Loss of Occurrence Book (OB) - as it is the case with traditional filling system
used by the Police Divisions, a very high risk of data loss is eminent in case of
any natural catastrophe as all records are kept in one place and its not easy to
make backups.
Poor services to Citizens Complaint services rendered to their people were
slow and hence leading to constant complaint from them as well as queue in the
service desk. This has now started to translate to frustration and loss of trust with
the police.
1.5.
11
SYSTEM OBJECTIVES
This section outlines what the system should accomplish. This was determined on basis
of understanding how the current system works and what its problems were. This
information has been used to implement improvements on the manual system.
1.5.1. Aim of the system.

The proposed system aims at automating the vehicle crime investigation department of all
the nine divisions in the county. The new system will be aimed at making Nairobi Area
Police Headquarters more operative in its service delivery and in achieving its role of as
stipulated in the Police Act. This system is marked at helping the Police meet its
objective of serving Nairobi Residents and keeping a proper update of all vehicles. The
proposed system has been computerized.
1.5.2. Objectives of the system.

The system should enable the Officer on Duty manning the desk to input the vehicles
details using the car registration numbers as unique keys to identify a record.
The system should eliminate the use of manual Occurrence Book (OB) as it is in the
current system in registering complaints of stolen vehicles.
The system should automatically generate an authentication document after an
individual places a complaint of a lost vehicle of which should be handed to the
individual.
The system should be able to search vehicle records and clearly indicate its current
status within five seconds hence improving public services.
All transactions in the various Divisions within Nairobi should update the
Headquarters central database. The system should enable faster data integration,
access and management by use of a database.
The system should introduce a user name and password as log in parameters to
enhance data security.
12
The system should provide for safe storage of data by allowing data is stored in
diskettes, magnetic tapes and CDs and these should be conveniently stored away from
the police stations for integrity purposes.
The system should enable police officers to keep track of area susceptible to vehicle
theft.
The system should detect and a report error to the automatically once incorrect data
has been inputted. E.g. when an individual tries to register an already registered
vehicle.
The new system should support proper utilization of computer resources by allowing
multiprocessing.
To develop a user-friendly system that will simplify some of the stressful
tasks such as continuous searching of misplaced vehicle records.
To produce a system that will allow the registration and deregistration of vehicles
whenever they are written off by insurance companies.
Consequently the proposed system should be able to do the following tasks:Register new vehicles, owner details as well as stolen vehicles.
Enable the Officer manning the desk to check on the status of a stolen
vehicle.
Display all registered and stolen vehicles.
Automatically generate a report on the vehicles for monitoring and
planning.
Automatically generate an authentication report upon submission of a
stolen vehicle complaint.
13
1.6. JUSTIFICATION
This project is indeed timely for it comes at a time when the National Police Service is
undergoing major reforms and when the force is under intense pressure to perform as per the
expectations of the country. In line with that is the recent involvement of vehicles in the
recent wave terrorist attacks within and without the county and thereby providing a need for
independency from Kenya Revenue Authority for vehicle identification. The system is
important and comes with various benefits one of them being effective and efficient
management of the vehicles that enter or belong to the residents of Nairobi and its environs.
The benefits of the project overshadow the costs that will be incurred in the course of its
development and operation. This is because it will be able to reduce car theft and citizens
buying stolen second hand vehicles as any interested party can walk into the police station
and counter check on validity of owners information.
This project has to be completed because it will enable the police officers to monitor and
occurrence of vehicle related crimes and hereby make decisions on where to conduct regular
patrols as well as scheduling of operations.
The project offers a prospect for application of the knowledge gained and realization of
more skills with an aim of satisfying the users. It facilitates the appreciation of the theory
behind system development and demonstrates the challenges encountered in the
development of a system.
1.7. SCOPE OF THE SYSTEM

The proposed system targets computerizing the Vehicle crime investigation Department
which will essentially address all the issues concerning registration of vehicles, take in
complaints of stolen vehicles as well as check status of a vehicle reported to be stolen.
It also aims at automating the vehicle Occurrence Book (OB) therein addressing the
issues of automated complaint registration processing as well as production of accurate
and timely on demand reports needed for deployment of Patrol cars on areas rampant
with vehicle theft as well as generate an authentication document for a stolen vehicle
complaint.
14
As such the system does not aim to automate the entire Occurrence Book but only the
section that concerns itself with vehicles.
1.8.
LIMITATIONS OF THE PROPOSED SYSTEM.
Though the system will greatly help solve the Nairobi Area police problems, there are
disadvantages it will bring along. This includes:
a) An act of parliament may be necessary to mandate the Kenya Police to have a
parallel database as that of KRA and as well as make it mandatory for everyone
owning a vehicle to register it with the Force.
b) The system will lead to overdependence i.e. it is foreseen that the officers will
entirely depend on the system to protect public property.
c) The system will call for additional costs required for training the police officers.
d) The file transfer process will be cumbersome as all previous records of stolen
vehicles are all in paper files.
e) A cost has to be incurred in purchasing new hardware and software. Also the cost
of hiring experts to maintain and administrate the system
f) A public awareness campaign has to be carried out to help the public familiarize
themselves with the new system and hence a new added cost.
g) The public as it is the norm may be reluctant to register the vehicles with Kenya
police.
It is necessary to note that the above limitations will have a short time implication and as
such should not worry the management.
1.9. FEASIBILITY REPORT
1.9.1. Economic Feasibility

Looking at the financial assessment of the project in terms of its benefits it is basically to
ensure that;
15
The system will be affordable to the Nairobi area Police Headquarters.

The benefits of the system when implemented would outweigh the cost of
development and acquisition.
The following benefits should be realizable from the new system:
Palpable reimbursements: they would include reduced vehicle theft, increased security
monitoring, fraud prevention in case of need to purchasing a second hand vehicle, faster
and larger complaint processing.
Impalpable reimbursements: They included improved decision making, data

consistency, better competitiveness, data security, data accuracy and easier record
reconciliation.
The following is a list of all item required for the project;

Item
Cost per unit
No. Of items
Total cost
Pc Computers
18,000.00
10
180,000.00
Hp LaserJet printer
4,500.00
10
45,000.00
Networking
20,000
20,000.00
MYSQL Database management

system
16,000.00
16,000.00
Documentation
2,000.00
2,000.00
Ms windows 7
8,000.00
8,000.00
Web service; WAMP server
Open source
Training costs
6,000.00
6,000.00
TOTAL COSTS
Table 1.1
16
277,000.00
1.9.2. Schedule feasibility.

This study looks into the time available for the project development and impact of delays.
It was established the system would be fully developed within the allocated time since all
the required equipment and personnel could be available at the project commencement.
This schedule will only include the expected time of each activity and the project.
Activity
Start date
End date
Feasibility study
15/05/2014
25/05/2014
Analysis
26/05/2014
02/06/2014
Database design
03/06/2014
10/06/2014
System design
11/06/2014
06/07/2014
Test strategy
05/07/2014
12/07/2014
Coding
13/07/2014
20/07/2014
Document and test cases
21/07/2014
28/07/2014
Installation
29/07/2014
05/08/2014
Implementation_ testing
06/08/2014
13/08/2014
Maintenance
After installation.
Table 1.2: Schedule
1.9.3. Gannt Chart for the Schedule.

System
Investigation
Feasibility study
System analysis
System design
Coding
Testing
Implementation
and installation
No. of weeks
17
10
11 12
1.9.4. Technical feasibility.

Software needed for project development (PHP for Developers, Wamp server, editor,
operating system.) can indeed be obtainable and so is with the hardware comprising of
computers, disks and printers. It also established that there existed no immediate
technical risks linked with the system which could be currently identified.
1.10. CONCLUSION
It is possible to conclude that the project and the entire venture is a worthwhile
undertaking for the Area police department since it would reduce to enormous extent the
problems currently eminent in the present system. From observation carried out it can be
noted that the current system is inaccurate, insecure in terms of information access and
transactions and as such a need to repeal it.
18
2.0.
Abstract
CHAPTER TWO
LITERATURE REVIEW
This review provides an overview of the role computer software plays within police
forces with particular attention paid to crime and vehicle registration and investigation
computer systems. Illustrative systems that are in practical use for tackling both major
and volume crimes are described. Particular attention is paid to the attempts that have
been made to automate the police force in dealing with crime. It concludes by looking at
the desired features of the proposed system in relation to already existing crime
investigation systems. A topic of current research is the use of data mining techniques for
automatically detecting patterns in reported vehicle crimes.
2.1.
Introduction
Recent years have seen an increasing use of computers within police forces, not just in
general administration -payroll, personnel, e-mail, and general office suites- but also as a
tool to assist the core business activity of policing preventing and solving crime.
Increasing crime rates and the greater awareness of modern criminals puts a strain on
existing methods and techniques. There is, therefore, a clear need for the application of
advanced software technologies in order to make the best use of limited resources.
2.2.
Automation And Law Enforcement
Cronkhite (2013) stated that information is the life blood of any law enforcement agency.
The accurate and rapid flow of information is essential for effective law enforcement.
Without information, police work would come to a standstill.
Without a fast and reliable means of obtaining and communicating police information,
manpower is wasted and police operations are degraded. As the rate at which vehicle
crime increased from 2004 through 2011 (53.7% increase in major vehicle crimes
nationally) so has the amount of information the police have to handle -World Atlas,
19
Kenya Crime Statistics (2012). It has reached such volume in most police agencies that
information no longer can be manually manipulated with any degree of accuracy and
efficiency. Automation can assist law enforcement to be more effective, particularly in
relationship to four major problems areas:
Reducing crime.
Optimizing police manpower.
Tracking Vehicle Information.
Gathering information to locate owners of recovered vehicles.
Ensuring efficient transition in the change of ownership of vehicle and facilitate
the sale of second hand vehicles.
But, one problem which seems to wave all of the automation systems was the length of
time it took to get data into the computer. Northrop (2000) in a study conducted
discussing the effectiveness of police computer use and the problems that exist with this
use. It was found in that study that the respondents in forty four cities across the United
States view computers as a major force in the fight against crime. This too could be
applied in Nairobi County if properly established and managed.
Cronkhite (2013) concluded that automation is not a remedy but rather just a tool for:
Rapidly correlating crime and criminal information from massive amounts of data
Quickly locating and dispatching field forces
Storing, correlating, manipulating and retrieving massive amounts of data
accurately and promptly.
Speedily transmitting and interchanging information from field personnel to data
files and from one agency to another.
20
2.3.
The Need for Vehicle Registration and Investigation System in

Nairobi
According to Ratledge et al. (2012), a variety of technologies have been tested and used
by many law enforcement agencies in the world. This includes:
2.3.1. Home Office Large Major Enquiry System (HOLMES)
All 43 UK police forces use the current HOLMES system that is approximately 12 years
old. There are five variant main systems produced by Bull, ICL, CGS UK Ltd, Unisys
and MDIS each using its own proprietary database, programming and query language.
Information cannot easily be transferred between systems; in fact, there is only a limited
linking facility between systems from the same manufacturer.
HOLMES uses a Bull utility, transaction processing system (TPS), to extract text from
the files and compile the status database. To search for a vehicle record, the system will
instigate a procedure, which is transparent to the user, by firstly searching the vehicle file
and then the status database.
Within the present HOLMES systems all data is limited to a single incident, no searching
can occur across incidents thereby imposing obvious limitations.
2.3.2. Violent Criminal Apprehension System (VICAP)
The Federal Bureau of Investigation developed the VICAP system that uses pattern
analysis to monitor case activity enabling the investigators to trace the travelling criminal
who is actively involved in major violent crime.
When a new case is entered, the system simultaneously compares and contrasts 188
variables relating to MO categories against those held in the database. The output is a
listing of the ten cases that most resemble the one being entered. The VICAP system has
21
case management administration facilities, investigation support and facilitates crime

investigation training.
2.3.3. Crime Report Information System (CRIS)
In the late 1980s the London Metropolitan Police conceived CRIS (1997) as a
computerized system to replace the paper-based crime reporting system with a database
covering the entire Metropolitan Police area.
The system produced information that led to many arrests; the first reported being related
to car crime (Daily Telegraph, 1996). Officers used the system to build up a picture of a
vehicle crime wave in Surbiton, Southwest London and found that they followed a
pattern of time, location, method and type of vehicle stolen. The police established a
decoy vehicle and caught the offenders within two hours. This is an illustrative example
of how computerized criminal investigation software can be used for proactive policing.
2.3.4. Crime Pattern Analysis System (CPAS)
The West Midlands police use CPAS which provides digital maps to display all or
specific types of crime that occur in a defined area. The system will analyze the data and
produce a coloured graphical overlay on the map to show the density of crime. It also has
the facility, using statistical techniques, to extrapolate total crime figures for a series of
dates and predict where crime will occur tomorrow.
The prediction is overlaid onto the map. This information can be used to aid manpower
planning and resource allocation. It is currently used for solving crimes or series of
crimes committed by vehicle crime offenders.
Need for technology
At the beginning, these systems seem to be the best solution to all the registration and
investigation system for vehicle crimes problems because of the advanced technology.
22
However, it still has its limitation as they have not met up with the demands to the masses
that spend endless time anxiously waiting for their demands to be met at Kenya Revenue
Authority and the are still working under the mercies of the registrar of motor vehicles
whenever in need of any information regarding any vehicle or vehicle owner.
Hence, the full computerization have not been effected as expected while technology and
software programming has advanced in other countries.
Shall we continue to wait for the criminals to get away with our stolen vehicles? Shall the
law enforcement agency continue with their dependency on other institution in order to
obtain vital information on the citizen? Shall the police force spend endless time
searching for owners of whose vehicles have been recovered when software can be
developed to tackle such problem like these? Shall inconsistency in on information
continue to be the norm of the Law Enforcement agency?
2.4.
Proposed System Desirable Features
It has been shown how investigation systems are being developed to harness the power of
the computer as a tool to aid the solution of both major and volume crimes. Identifying
characteristics in volume crime where there are no clear suspects is quite difficult due to
specific series of crimes being lost in the morass of all reported crimes.
From the stance of investigating crime, there is a set of features that would be most
desirable in any computer system for the police:
The ability to interface with incongruent, existing systems. It is quite common, at
present, to check four or five different systems to establish the history of and
information about a single address or person.
The ability to use natural language for queries and the competence for any
submitted query to have the capability of searching through all tables in the
database without the requirement to establish relationship links would bring
complex searching into the domain of the untrained user. It would also require a
complex indexing system to ensure acceptable retrieval times.
23
When data is entered into the system a useful facility would be the automatic
matching of any new information to existing information based on user defined
criteria. Examples being the entry of a vehicle registration number.
2.5.
Conclusion
The computer, as a tool, plays an essential part in the investigation of both major and
volume crime. The majority of current systems are designed to be used in the
investigation or registration of either these categories of crime. The proposed system
however, is intended to do both registration and investigation of motor vehicle crimes in
Nairobi and its environs.
This requires increasing sophistication and specialization to obtain the best results from
the software and gain confidence in the procedures.
Future systems should now exploit AI techniques that will enable the automatic
examination and presentation of information. However, in the past AI systems have been
viewed with a great deal of skepticism within the police force.
This is partly due to a general lack of computer literacy and also due to systems requiring
a substantial amount of hand crafted knowledge with which users may disagree or the
knowledge becoming dated and difficult to update.
24
CHAPTER THREE
ANALYSIS
3.1. Introduction
This chapter will briefly discuss what has been learnt from the literature review and the
review of existing products. The information will then be used to set the requirements
specification.
3.0.
3.2. Overview
The literature review highlighted many key areas. The review exposed the need to use a
specific system tailor-made for the registration and investigation of vehicles. It brought
to the forefront the need to for the police force to have a self-sufficient system for vehicle
management in the Nairobi area police department. Vehicle details should be accessible
to as many police officers as possible.
The review of existing systems revealed important features that are similar across the
majority of their functionality. These features included the use of robust, universal and
integrated components. Where possible these features should be included or adapted for
the implementation. The review also gave an insight into the weaknesses. Many of the
systems only dealt with human criminal investigations and identification. If they the
offender was to use a vehicle, it would take the intervention of other third parties to
recognize the said person and the vehicle. The existing systems depended on other
systems from other government agencies to conduct their investigation. None of the
systems had a self -sufficient database for their Operation.
3.3. Requirements specification

User requirements are statements, in a natural language plus diagrams, of what services
the system is expected to provide to system users and the constraints under which it must
operate. That describes user goals or tasks that the users must be able to perform with the
system. User requirements therefore describe what the user will be able to do with the
system.
The requirements specification is broken into two parts:
25
3.3.1. Non-Functional Requirements
Non-functional requirements are requirements that are not directly concerned with the
specific services delivered by the system to its users. They may relate to emergent system
properties such as reliability, response time, and store occupancy. Alternatively, they may
define constraints on the system implementation such as the capabilities of I/O devices or
the data representations used in interfaces with other systems. Non-functional
requirements, such as performance, security, or availability, usually specify or constrain
characteristics of the system as a whole. They include:
Usability- The system provides a help and support menu in all interfaces for the
user to interact with the system.
Security- The system provides username and password to prevent the system from
unauthorized access.
Performance- The system response time for every instruction conducted by the
user must not exceed more than a minimum of 10 seconds.
Availability- The system should always be available for access at 24 hours, 7 days
a week. Also in the occurrence of any major system malfunctioning, the system
should be available in 1 to 2 working days, so that business process is not severely
affected.
3.3.2.
Specific Requirements
These are statements of services the system should provide, how the system should react
to particular inputs, and how the system should behave in particular situations. It
specifies the software functionality that the developers must build into the product to
enable users to accomplish their tasks. This includes;
Vehicle investigation.
Allow for user to register a complaint on lost vehicle.
Transfer plates between vehicles and vehicles between different persons
Collect vehicle and vehicle owner information
Process certain complaints and registration certificate.
Change details in the database, if necessary
Vehicle registration
26
CHAPTER FOUR
DESIGN
4.1. DESIGN METHODOLOGY
The analysis and design of a system involve various methodologies. The methodology
4.0.
used in the analysis and design of this system is the Structured System Analysis and
Design Methodology (SSADM). This methodology uses a systematic and structured
manner to analyze and design a system. The methodology which uses a linear life circle,
divided the whole project task into various stages or phases.
This stage is meant to come up with a system structure in terms of database design,
interface design and a process flow that is reflective of a systematically organized
sequence. This activity is succeeded by a program design that should facilitate data entry,
processing and subsequence storage in the format that will ensure uniformity and
maximum accuracy of entries. Database interface and program design
This is done to show the systems flow of information. The requirements were used to
create the basis for the new system. Its main objective is to design a system which
delivers the functions required by the users to support the business objectives of their
organization this activity is affected using process description tools e.g. (DFD) and
context diagrams.
The design area covered includes the following:
Interface modeling
Program modeling
Data modeling
Process modeling
4.2. System Architecture Description
4.2.1. Context Diagram
This system is based on two main components:
Database: Contain all the data and information about vehicles in Nairobi
Area.
User Interface: enables the Officer on Duty or any other relevant Officer to
access the various parts of the system, which perform various functions and
operations.
The Officer inputs data using the GUI, which interacts with the system and/or database to
give output. There is one database, which is a data store.
27
VEHICLE REGISTRATION
Context Diagram
AND INVESTIGATION
Register owner and vehicle details

SYSTEM
View vehicles registered
OFFICER ON
Registered vehicles
DUTY
Interface, processes and

database
Register stolen vehicle complaint

View stolen vehicles
Stolen vehicle details
Check status of stolen vehicle
Status of stolen vehicle
Request
Reports
Reports
SENIOR OFFICERS
Figure 4.1:Context diagram
4.2.2. Data Flow Diagram

Data flow diagrams show the movement of data between processes and files and are
sometimes called information flow diagrams.
In the Design of this system, the original Gane and Sarson notation will be used.
Detailed Design
28
Level 1 DFD
1
Vehicle management system
Owner details
D1
Register vehicle owner

Owner details
owners
2
Delete vehicle details
reg. No
D2
Police Officer
file on duty
Vehicle details
Vehicles
vehicle details
Register vehicle details

Reg. No
view vehicles
4
Vehicle status
complaints
Register stolen vehicle complaint

D3
Stolen
vehicle
Vehicle status.
5
Check status of stolen vehicle
Figure 4.2: Data flow diagram
29
Reg. No.
Figure 4.3: Flowchart diagram
Start
Enter User Name

and Password
And User ID
No
Valid?
Error
message
Yes
Register
owner
Yes
Register owner?
No
Register
vehicle
Yes
Register vehicle?
No
Yes
Record
complaint
Record a vehicle
complaint?
No
Check
status
Yes
Check status?
No
Yes
Update
records
Update records?
No
30
END
4.3. DATABASE DESIGN

Admin Login Table
column
Data type
size
null
description
adminID
Varchar
no
Officer login id
Password
Varchar
no
Set login password
Table 4.1 Admin Login

Vehicle owners table
Column
Data Type
size
null
description
idNo
Varchar
25
no
Owner identification number-primary key
fName
Varchar
50
no
First Name
oNames
Varchar
50
no
Other Names
Nationality
Varchar
50
no
Owner Nationality of Origin
pNumber
Varchar
25
no
Phone Number
email
Varchar
50
no
Email address
address
Varchar
50
no
Address in the form of 353666-20100
town
Varchar
50
no
Town of residence
Table 4.2: Vehicle Owners
31
Table3 Vehicles table

Column
Data type
size
null description
rNo
Varchar
25
no
Vehicle registration number- primary key
Make
Varchar
50
no
Make of the vehicle
model
Varchar
50
no
Vehicle model
yOM
date
no
Year of manufacture
engineCC
Varchar
50
no
Engine capacity
chesisNo
Varchar
50
no
Chassis number form of BH-
color
Varchar
50
no
Vehicle color
wheels
Varchar
50
no
Number of wheels
insuranceC
Varchar
50
no
Insurance company
idNo
Varchar
25
no
Identification number of owner- foreign key
Table 4.3: Vehicles

Table4 stolenv Stolen Vehicles Table
Column Data type
size null
description
rNo
Varchar
25
no
Vehicle registration number- foreign key from

vehicles
area
Varchar
50
no
Area vehicle was stolen
date
date
no
Date of theft
idNo
Varchar
no
Identification number of owner- foreign key owners

table
25
Table 4.4: Stolen Vehicles
32
4.4.
Entity relationship diagrams
Admin
Vehicles
Register
Is registered
Is owned
Registers
is registered
Owns
Owners
Figure 4.4: entity relationship diagram
33
4.5. INTERFACE DESIGN

This is meant to show the diagrammatic appearance of all the input forms and output
screens of the system. The input screens show the forms that will be used to capture data
regarding different aspects of the system. On the other hand, the output screens show the
reports that will be displayed/printed on the basis of data manipulation.
The figures below represent all the input screens used in data captures for this system:
4.5.1. Admin Login
Admin Login
Username
Password
LOGIN
Figure 4.5: Admin Login
34
4.5.2. Home page
VEHICLE INVESTIGATION AND REGISTRATION SYSTEM

HOME
REGISTER VEHICLE
VIEW VEHICLES
RIGISETR
COMLAINT
VIEW STOLEN
VEHICLES
CHECK VEHICLE
STSTUS
EXIT
Figure 4.6:Home page

4.5.3. Owner Details Registration
Owners Details
First Name
Other Names
ID/Passport No.
Nationality
Phone Number
Email Address
Address
Town
NEXT
35
RESET
4.5.4. Vehicle Details Form
Vehicle Details;
Registration No.
Make
Model
Year of Manufacture
Chassis No
Engine capacity
Color
No. of Wheels
Insurance Company
Owner IdNo
SUBMIT
Figure 4.7: Vehicle registration form
36
CANCEL
4.5.5. Complaints Form

Stolen Vehicle Complaint Form
Vehicle Reg. No
Area Stolen
Date Stolen
Id No. Of Owner
Submit
Figure 4.8: Complaints form
37
CHAPTER FIVE
5.0.
SYSTEM IMPLEMENTATION
5.1. Introduction
System implementation is a collection of inter-dependent physical devices together with
their programming which provides the functionality and performance for which the
system was designed. It covers all the activities necessary to set the system that has been
analyzed and designed to be fully functional to the users.
Implementation develops the system to be functional to attain the objectives. It is done by
acquiring hardware and installing software required to develop the system. It is then
followed by developing database and coding the modules and integrating the modules.
5.2. Implementation Overview
Nairobi Area Police Department has relied on a Manual method of Record Keeping since
its inception. A major consideration in the automated systems implementation was the
fact that the organizations registry and record department has been using the manual
system all this years over which no other system has been introduced. The subsequent
sections provide a description of the implementation approach and Tasks that will be
involved.
5.3. Description of Implementation
With all the above stated factors put into consideration, the Parallel Changeover method
will be the most convenient implementation method for the system. The Parallel
Changeover runs both the existing system and the new system side by side. Since two
systems are available, one acts as backup to the other and as a benchmark for comparison
of how well they function. If the new system fails, the existing system remains in place to
take over processing.
Parallel changeover is typically the choice for applications considered critical to the
projects success. However, Parallel Changeover has its disadvantages. It is the most
expensive changeover method. It may require additional personnel and Executing
systems side by side is time consuming and costly.
38
5.4. Justification for the Changeover Method

The major reason for choosing the parallel changeover method is based on the fact that
the Police Department has depended on the Manual system for a long period of time. Due
to this fact a direct changeover could carry greater risks if implemented. A parallel
changeover method will thus allow for a gradual analysis and comparison of the two
systems with time.
5.5.
Major Tasks in Implementation
5.5.1. Installation
This will involve both Hardware and Software Installation and will be carried out by the
system developer.
5.5.2. Training
The training phase of Implementation will involve introducing the police staff to the
system and its functionality. Training will be carried out by the system developer.
5.5.3. Execution
This will involve the actual operation of the system in parallel with the manual system.
The execution phase will be performed by the Officer in charge.
5.5.4. Review
During the Review phase, the System developer and the Officer in charge will analyze
and compare the Manual system to the automated system and draw conclusions on the
changeover.
5.6.
System Requirements
5.6.1. Software Requirements

A windows 7 or higher version operating system
MySQL Server
Web browser
Eclipse for PHP developers
PHP scripting language
39
5.6.2. Hardware Requirements

The software designed needed the following hardware for an effective operation of the
newly designed system.
Pentium IV system
At least 512MB of RAM
Enhanced keyboard
40GB hard disk space
LCD monitor
Mouse
Software and Hardware Requirements Summary
System Requirement
Specification
Purpose
1. Personal Laptop
- Processor minimum 1.5
- Mobility in development
GHz
- RAM minimum 512MB
- Hard disk minimum
40GB
- Monitor minimum 15
- Easy to take the system

to anywhere during
development for
suggestions
- Handy for the developer.
LCD
2. Printer
- Laser or DeskJet
- Should be able to print
- To test the system for

printing reports.
A4 size paper.
3. PHP scripting language
The programming language

used to program and
develop the system.
40
4. MySQL Server
It is use for the database

design and data storage for
the system
5. Eclipse for PHP

developers
It is used to design the

system and related draw
diagrams. Example:
Interface design, system
architecture, navigation
diagrams. etc.
Table 5.1: Requirements summary
5.7. Choice of Development Tools

The development tools are the necessary requirement tools used during the design to
enable us achieve the system design. The listed packages was used because of their
features, accessibility and also because it is more effective.
1. Eclipse for PHP developers
2. MySQL database application
3. PHP scripting Language
4. HTML language
MySQL Database Server: MySQL is the database construct that enables PHP and
Apache to work together to access and display data in a readable format to a browser. It is
a Structured Query Language server designed for heavy loads and processing of complex
queries. As a relational database system, MySQL allows many different tables to be
joined together for maximum efficiency and speed.
MySQL is the perfect choice for providing data via the Internet because of its ability to
handle heavy loads and its advanced security measures.
PHP: PHP is a server-side scripting language that allows Website to be truly dynamic.
PHP stands for PHP: Hypertext Preprocessor Its flexibility and relatively small learning
make it one of the most popular scripting languages around.
41
HTML Language: Hypertext Markup Language (HTML), the standard text-formatting

language for documents on the interconnected computing network known as the World
Wide Web. HTML documents are text files that contain content that is meant to be
rendered on a computer screen.
5.8. Coding
The system is programmed using PHP. The system requires authentication to use it.
There is only one level of users Administrator. When at login, username and passwords
are submitted, based on the registered this level, the system allows all functions for the
users.
Figure 5.1 shows the coding for login authentication check when the users log in. The
passwords are stored in the database encrypted when the users are registered to the
system by the administrator.
Figure 5.1: Coding for Login Authentication Check
<?php
session_start();
// dBase file
include("connect.php");
// Grab User submitted information
$adminID = $_POST["adminID"];
$password = $_POST["password"];
$result = mysql_query("SELECT * FROM login");
$row = mysql_fetch_array($result);
if (false === $result) {
echo mysql_error();
}
if($row["adminID"]==$adminID && $row["password"]==$password)
Header("Location: home.php");
Else{
echo"Sorry, your credentials are not valid, Please try
again.";}
?>
42
5.9. Integrating Modules

After coding and testing every module, the module is integrated to the other modules
with which it has to work. When all the modules are coded the system will be intergraded
for system testing.
43
CHAPTER SIX
SYSTEM TESTING
6.1. Introduction
Developing a good and logically sound test plan is very vital to developing a bug free
software system. The testing of the system includes unit testing, integration testing,
system testing and acceptance testing. The following sections describe the testing for the
system.
6.0.
6.2. Unit Testing

Unit testing is to check whether the particular module is working properly. There are
mainly two methods to do unit testing, namely black-box testing and white-box testing.
Following sections describe the two tests for the system.
6.2.1. Black-Box Testing
Black-box testing is carried as a formal unit testing. Black-box testing will be carried out
to see if the unit undergoing the test gives the expected output from the specified input.
Table 6.1 shows the Black-box testing for the system.
Table 6.1: Black-Box Testing For the System.

Module
Searching
Sub-module
Testing
Expected Output
Search by
Search each
Load documents
categories
category with
based on the searched
applicable data
category and search
Testin
g
Result
Passed
string
Search each
Load nothing and
category with
give display as zero
non-applicable
books found.
data
44
Passed
Add/Edit
Add New
Enter and submit
Save vehicle data to
vehicle
Vehicle
vehicle data to
database.
Update /
Passed
save.
vehicle
View vehicles
Update vehicle
The data in database
Data.
will be updated.
Search by owner
Show vehicles with
ID number
similar ID
Add Vehicle Add New
Enter and submit
Save borrower data to
Owner
Vehicle
owner data to
database.
Owner
save
Edit/Update
Update owner
The data in database
owner
data
will be updated.
Search by owner
Show owner with
ID number
supplied ID
Record a
Record
Enter vehicle
Data updated in
stolen
complaint
Registration No.
database
Enter owner ID
Data updated in
Vehicle
Complaint
Passed
Passed
Passed
Passed
Passed
Passed
database
Report
Monthly
Check vehicles
Show the vehicles
Generating
reports
registered and
stolen and registered
stolen complaints
45
Passed
Print if option
Passed
selected.
Log on
Login as
Enter username
Check username and
administrator
and password
password.
Passed
Allow log in.

Show administrator
interface
Enter wrong
Check username and
username and
password.
password
Log off
Exit
Passed
Give error message.

Should log off the
Passed
user and close the

working screen
Back up
Backup
Back up
Show location to
back up.
System saves
database to specified
location.
Shows success
message.
If fails, fail message
46
Passed
6.2.2. White-Box Testing

White-box testing looks inside the program to test its major elements. It is to look inside
the module to review the code itself. The tester may discover errors or assumptions not
immediately obvious to someone treating the class as a black box. White-box testing
conducted for the system is as follows.
i.
Check logical paths of the coding after coding and when any change is made.
Errors are fixed and result showed well working.
ii.
Check the loops whether it works intended. Result showed well working.
iii.
Check logical decisions working correct or not. Result showed all the
conditions are working well.
iv.
Check overall internal program structure for the whole system. Result showed
all the connectivity and structure working well.
6.2.3. Integration Testing

Integration testing is to carry out, user interface testing, interaction testing, system
interface testing.
User interface testing was done by moving through each and every menu item in the
interface by both top-down and bottom-up manner. The test result showed it works well.
Interaction testing was done as each unit of program is coded to see if it works with other
program units. When each unit was completed it was added and run test data. The results
were compared to the correct results. The result showed the integration working well.
System interface testing was done to see if the system works well when it exchanges data
with the database. The result showed the data exchanged correctly and working well.
47
During the testing I was concerned about the inputs and expected outputs. Emphasis is on
the testing where I input the data and compared the output with the expected results. I
tested for the acceptance of unexpected data and the reaction from the program.
I kept checking the database manually during testing whether it works according to the
rules that I established in the relationships.
6.2.4. Registration Window Test

An important test was that only valid registration keys were accepted. Sometimes,
administrator could type in any combination of text and numbers for this key. The
program needed to discern valid keys from errors.
6.2.5. Login Window Test
I used several different names to log into the system. I used correct and incorrect User
Names and Passwords to access the software and thus access the database.
I was not allowed to log in using incorrect passwords and an error message was shown.
When the correct password is presented I was able to log in to the next window.
6.2.6. General User Window Test
I did various different types of searches and checked if our expected output result
matched with the presented output by the program.
I included various strings in the text fields as a means of testing the validity of the search
function.
6.3. System Testing
System testing is done by doing, requirements testing, usability testing, security testing,
performance testing, and document testing.
A requirement testing was done to test whether original business requirements are
met. It ensured that changes made as a result of integration resting did not create
48
new errors. The test also performed improper actions to ensure the system is
immune to invalid actions like adding blank records.
Usability testing was done to test how convenient the system is to use. It was done
in users point of view. It was tested for easy interface, short cuts, and handy
commands. It was also tested if one task can be done in an alternative way for
users choice.
Security testing is to test disaster recovery and unauthorized access. The system
offers back up.
49
CHAPTER SEVEN
7.0.
PROBLEMS ENCOUNTERED IN DEVELOPMENT PROCESS
While carrying out the project development several problems and experiences were
encountered. Below are some of the problems encountered and how they were overcome.
Inadequate time
During the project there was shortage of time to develop and finish the project. Extra
time was spared during the weekends and at night to proceed with the project.
Power failure
This was a very major problem in the project development. There was frequent
power failure which always interrupted with the project timetable and the short
time allocation, sometimes some data would get lost in the process forcing one to
redo the job again.
Lack of enough resources
The machines needed to work out the project were not enough. Besides that
development work required a lot of money, which was not adequately available.
7.1.
Limitations and Achievements of the System
The system can only be used by trained end users therefore there have to be retraining
of the workers in the organization. The users must be computer literate so that they
can maneuver through the system with ease.
It was not currently possible to implement the system to work in a networked
environment.
The system has managed to carry out all the procedures as expected in all the types of
files e.g. searching the customer records, displaying the found records, deleting the
unwanted records
Security is enhanced in the system by use of passwords.
Alert messages for the user to confirm if certain data should be deleted prevent data
loss.
Due to existence of the above limitations, it was concluded that the development team
should continue looking up with methodologies of ensuring that the system will
efficiently be used in a networked environment, they should be seeing into it that the
50
system can be in a position to assign user rights to different users to restrict their access
to the information in the system.
The developers should also look into developing of on demand report to address real time
management needs.
New technology that is coming up in the fast growing computer world can be included in
the system to make it more efficient and fast e.g. use of automatic teller machines which
can be used by the customers to inquire their bills and payments cash using them.
51
CHAPTER EIGHT
8.0.
USER GUIDE
The application is user-friendly enabling user to easily navigate through the program.
This ease the workload of the user having to initiate the commands himself/herself, as
programming language used is object oriented therefore command driven.
8.1. INTRODUCTION
This is a guide to users on how to load the software platform on which the system is to
run on, how to load the system and how to use the system.
This section explains the system installation and maintenance procedures for the
administrator.
8.2. System Installation
The system will come with an installation CD. Steps to install the system are as follows.
i.
Insert the CD to CD Drive.
ii.
It will pop up a window.
iii.
Choose Install from the menu.
iv.
Follow the installation wizard.
After installation, the short cut for the programme will be stored in Start menu > All
Programs > NAPDVRS. When program is run at the first time, it will ask for login.
Figure 7.1 shows the log in form
User has to fill all the necessary fields. The Website URL given during the login will
appear in about window and will allow opening it in default browser when clicked. The
registration key will be checked for correct key while being typed and will show valid if
correct otherwise cross.
52
Figure 7.1: login Form

8.3.
LOADING/UNLOADING THE SYSTEM
When loading the system first ensure that the computer machine is in good working
condition and that there is power.
Procedure
Switch on the computer

From the task bar, click on the start button
Select programs
Select Wamp Server
Then select Open a web Browser
Type the URL Localhost:81
Load the admin Page
Wait as the loading bar shows progress until it completes
Navigation through the System

The Main Splash Form for the System.
This form will allow a admin load the other modules of the system.
Login form.
This where the admin name and the password are typed to allow the user to navigate
through the project the password and the user name are defined in the database in that not
any name can be entered and access granted. This enhances security.
53
Figure 7.1: login Form
What Happens if Access is Denied

This will happen if you type the incorrect password or username from
The ones defined in the database.
Figure 7.2: Error message
54
Main Menu Form
Figure 7.3: Home page
Interaction pages.
55
Complaint form.
This form allows the admin to interact with the system when handling people complaints.
Vehicle owner registration
form
Figure 7.4: Vehicle Owner registration
56
Vehicle registration form
Figure 7.5: vehicle registration form
57
Searching
This enables an individual to search records.
Figure 7.1: Vehicle search
58
9.0.
BIBLIOGRAPHY
Atkinson, B (2009) Cyber cops make house calls", The Globe and Mail, Science and
Criminology.
Bell, D. (2005). Database Software for Microcomputer Systems. McGraw-Hill Book
Company, USA.
Cronkhite, C.J (2013). Automation and Law Enforcement, Pennsauken, New Jersey.
CRIS Sales Promotion Literature (2012), Department of Technology, Metropolitan Police,
London.
Daily Telegraph, (1996), "Computer feeling collars", Daily Telegraph,
Here Maps for Life. (2014) Country and City retrieved from
http://here.com/directions/
Keller, J. J. (2001). Federal Motor Carrier Safety Regulations Pocketbook. Academic
Press, Ibadan.
Lerk Mark and Deeks David (3rd Edition)-Introduction to System Analysis and DesignPearson Education (2010).
Northrop et al., 2000, Journal of Criminal Justice, Vol. 23, Iss. pgs. 209- 309.
Oladipo, O. I. (2011). Road Transportation in South Western Nigeria, 1900 1960: its
Role, Nature and Impact on the Economy. Nicholas Brealey Publishing, London.
Pratelli, A. & Brebbia, C. A. (2011). Urban Transport and the Environment. Academic
Press New York, USA.
Pressman, R.S., Software Engineering: A Practitioners Approach, 7th Edition, McGraw
Hill, New Delhi, 2011
59
Ratledge, E.C, Jacoby, J.E (2012), Handbook on Artificial Intelligence and Expert Systems
in Law Enforcement, Greenwood Press, Westport, CO.
Rudman, J. (2004). Motor Vehicle Licensing Supervisor. Gower Publishing Limited, Lagos.
World Data Atlas, Kenya Crime Statistics (2012) retrieved from
http://www.knoema.com/atlas/kenya/statistics at18th June, 2014; 17:05hrs
Ramkrishna.R& Johannes G. Database Management Systems. - McGraw-Hill (2012).
Summerville, I., Software Engineering 9th Edition, Pearson Education, Delhi, 2010.
The Kenya Police. (2014) Nairobi retrieved from
http://www.kenyapolice.go.ke/Nairobi.asp/
Thomas Mathiba. (2012)Developing and Implementing an IT Based Project
Management System retrieved from
http://www.wrseta.org.za/
60
APPENDIX
Sample Code
<?php
session_start()
?>
<html>
<head>
<link href="Newfile.css" rel="stylesheet" type="text/css">
<title>Admin Login</title>
</head>
<form action="loginpro.php" method="post" class="login-Container">
<legend>Admin Login</legend>
<label><span>User Name</span><br><input type="text" name="adminID"
REQUIRED></label><br>
<label><span>Password</span><br><input type="password" name="password"
REQUIRED></label>
<label><span></span><br><input type="submit" name="login" value="LOGIN"
id="login"></label>
</form>
</html>
<?php
session_start();
// dBase file
include("connect.php");
// Grab User submitted information
$adminID = $_POST["adminID"];
$password = $_POST["password"];
$result = mysql_query("SELECT * FROM login");
$row = mysql_fetch_array($result);
if (false === $result) {
echo mysql_error();
}
if($row["adminID"]==$adminID && $row["password"]==$password)
Header("Location: home.php");
else echo "<center><img src= 8.png WIDTH='200'
BLINK><br></center>";
print "<center><b>Sorry, your Login Credentials Are NOT VALID,
Please CHECK AND try AGAIN<b></center>";
?>
<?php
session_start();
?>
<html>
<head>
61
<title>Vehicle Registration Investigation and System</title>

<link href="newfile.css" rel="stylesheet" type="text/css">
<body>
<div class="wrapper-home">
<h1>NAIROBI AREA POLICE<BR> VEHICLE REGISTRATION
AND INVESTIGATION SYSTEM</h1>
<div id= "logo">
<img src="flag.gif" alt="logo" width="" height="150" position=
"center">
</div>
<div id="navhome">
<TABLE CELLPADDING= "20" >
<TR>
<TD><a href= "span.php"><button id="button"> New Owner
Registration</button></a></TD>
<TD><a href="stolenv.php"><button id="button">Stolen Vehicle
Complaint</button></a></TD>
<TD><a href="status.php"><button id="button">Check Status of Stolen
Vehicle</button></a></TD>
<TD><a href="viewvehicles.php"><button id="button">View Registered
Vehicles</button></a></TD>
</TR>
<TR>
<TD><a href="viewstolen.php"><button id="button">View Stolen
Vehicles</button></a></TD>
<TD><a href= "newfile.php"><button id="button">Fetch
Record</button></a></TD>
<TD></TD>
<TD><a href="adminlogin.php"><button id="button">Exit</button></a></TD>
</TR>
</TABLE>
</div>
<?php include("Footer.php"); ?>
</div>
</body>
<html>
<head>
<title>New Owner registration</title>
</head>
<link rel="stylesheet" type="text/css" href="newfile.css">
<body>
<div class="wrapper-home">
<div id= "main-Container">
<h3>NAIROBI AREA POLICE<BR> VEHICLE REGISTRATION
AND INVESTIGATION SYSTEM</h3>
<div id="nav">
<a href= "home.php"><button>Home</button></a><br>
<a href="stolenv.php"><button>Stolen Vehicle Complaint</button></a><br>
62
<a href="viewvehicles.php"><button>View Registered

Vehicles</button></a><br>
<a href="viewstolen.php"><button>View Stolen Vehicles</button></a><br>
<a href="status.php"><button>Check Status of Stolen
Vehicle</button></a><br>
<a href="adminlogin.php"><button>Exit</button></a><br>
</div>
<div >
<form action="processreg.php" method="post" class="form">
<legend>New Owner Registration</legend>
<label><span>First Name</span><input name="fName" type="text" required
/></label>
<label><span>Other Names</span><input type="text" name="oNames"
required /></label>
<label><span>ID/Passport Number</span><input type="text" name="idNo"
required pattern="[0-9]{8}"/></label><br>
<label><span>Nationality</span><br><select name="nationality" ><option
selected>-----Select Your Nationality----- <option>Afghanistan<option>
Albania<option>Algeria<option>Andorra<option>Angola<option>Antigua<opti
on>Argentina<option>Armenia<option>Australia<option>Austria<option>
Azerbaijan<option>Benin<option>Bhutan<option>Bolivia<option>Botswana<op
tion>Brazil<option>Burkina
Faso<option>Burundi<option>Kenya<option>Rwanda
<option>Tanzania<option>Uganda </select>
</label><br>
<label><span>Mobile Number</span><input type="text" name="pNumber"
required pattern="[0-9]{10}"/></label>
<label><span>Email</span><input type="email" name="email"
required/></label>
<label><span>Parmanent Address</span><input type="text" name="address"
required /></label>
<label><span>Town</span><input type="text" name="town" required
/></label><br>
<table cellpadding="10">
<tr><td><input type="submit" name="add" value="Next"
id="Register"></td>
<td><input name="reset" type="Reset" id="Reset"
value="Reset"></td></tr>
</table>
</div>
</form>
</div>
</div>
</body>
</html>
<?php
$fName=($_POST["fName"]);
$oNames=($_POST["oNames"]);
$idNo=($_POST["idNo"]);
$nationality=($_POST["nationality"]);
$pNumber=($_POST["pNumber"]);
63
$email=($_POST["email"]);
$address=($_POST["address"]);
$town=($_POST["town"]);
$username='root';
$password='';
$host="localhost";
$databaseName='system_project';
$connect=mysql_connect($host,$username,$password);
if ($connect){
$db=mysql_select_db($databaseName);
}
else{
echo "could not connect to server";
}
$query="INSERT INTO owners
VALUES('$fName','$oNames','$nationality','$idNo','$pNumber','$email','$
address','$town')";
$result= mysql_query($query);
if ($result){
header("Location:vehiclereg.php");
}
else { die(mysql_error());
}
exit();
?>
64

Vehicle Management

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Vehicle Management

Hochgeladen von

Copyright:

Verfügbare Formate

MULTIMEDIA UNIVERSITY OF KENYA

FACULTY OF BUSINESS AND LAW

BACHELOR OF BUSINESS INFORMATION TECHNOLOGY

MWANGI DUNCAN NJOROGE

PROJECT SUPERVISOR: MR. ADUNYA. J

MAY- SEPTEMBER 2012

VEHICLE REGISTRATION AND INVESTIGATION SYSTEM

MWANGI DUNCAN NJOROGE

VEHICLE REGISTRATION AND INVESTIGATION SYSTEM

Table 1.2: Schedule Feasibility - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 17

VISION STATEMENT .................................................................................................. 10

OVERVIEW OF THE EXISTING SYSTEM. ....................................................................... 11

PROBLEM DEFINITION ............................................................................................... 11

Aim of the system..................................................................................................... 12

Objectives of the system. ......................................................................................... 12

SCOPE OF THE SYSTEM .............................................................................................. 14

LIMITATIONS OF THE PROPOSED SYSTEM .................................................................. 15

FEASIBILITY REPORT .................................................................................................. 15

Economic Feasibility ............................................................................................... 15

Schedule feasibility .................................................................................................. 17

MWANGI DUNCAN NJOROGE

VEHICLE REGISTRATION AND INVESTIGATION SYSTEM

Gannt Chart for the Schedule. ............................................................................... 17

Technical feasibility. ................................................................................................ 18

LITERATURE REVIEW ................................................................................................. 19

Automation And Law Enforcement ............................................................................ 19

The Need for Vehicle Registration and Investigation System in................................... 21

Home Office Large Major Enquiry System (HOLMES) ..................................... 21

Violent Criminal Apprehension System (VICAP) ................................................ 21

Crime Report Information System (CRIS) ........................................................... 22

Crime Pattern Analysis System (CPAS) ................................................................ 22

Proposed System Desirable Features ......................................................................... 23

Requirements specification ....................................................................................... 25

Non-Functional Requirements ............................................................................... 26

Specific Requirements ............................................................................................. 26

DESIGN METHODOLOGY ........................................................................................... 27

System Architecture Description ............................................................................... 27

Context Diagram ..................................................................................................... 27

Data Flow Diagram ................................................................................................. 28

DATABASE DESIGN .................................................................................................... 31

MWANGI DUNCAN NJOROGE

VEHICLE REGISTRATION AND INVESTIGATION SYSTEM

Entity relationship diagrams ..................................................................................... 33

INTERFACE DESIGN ................................................................................................... 34

Admin Login ............................................................................................................ 34

Home page ................................................................................................................ 35

Owner Details Registration.................................................................................... 35

Vehicle Details Form .............................................................................................. 36

Complaints Form .................................................................................................... 37

SYSTEM IMPLEMENTATION ....................................................................................... 38

Implementation Overview ........................................................................................ 38

Justification for the Changeover Method ................................................................... 39

Major Tasks in Implementation ................................................................................. 39

System Requirements ............................................................................................... 39

Software Requirements ........................................................................................... 39

Choice of Development Tools .................................................................................... 41

MWANGI DUNCAN NJOROGE

VEHICLE REGISTRATION AND INVESTIGATION SYSTEM

Unit Testing .............................................................................................................. 44

White-Box Testing ................................................................................................... 47

Integration Testing .................................................................................................. 47

Registration Window Test ...................................................................................... 48

Login Window Test ................................................................................................. 48