UNIVERSITY OF ELDORET

MAIN CAMPUS
SCHOOL OF SCIENCE
MATHEMATICS AND COMPUTER SCIENCE DEPARTMENT.
KIPTOO NICKSON
INF/039/17

COURSE NAME: PROJECT CORE

COURSE CODE: INF 490

PROJECT TITLE

CAR RENTAL SYSTEM.

DECLARATION
I declare that this project is my original work and has not been presented in any other learning
institution.

Signature……………………………….... Date ……………………………

KIPTOO NICKSON

INF/039 /17

Declaration by the Supervisor

This project has been submitted for examination with my approval as project Supervisor.

Signature……………………………….... Date ……………………………

DR KITUR

Supervisor
ACKNOWLEDGMENT
First and foremost, I thank Almighty God for life, health, and the ability to acquire
knowledge through learning. To my dear parents for the moral, financial, physical and
psychological support they accorded me, my supervisor Dr kitur for his time, dedication
and the guidance he gave me while carrying out this project.

Thank you all and may our Lord God bless you.
ABSTRACT

This project is aimed at developing a car rental system where a customer can rent a car of his
choice based on the location he wants or he is. Also a car dealer can also register and rent his car.
The system has two login section as a customer and as a car dealer. A person can register as a car
dealer or as a customer.
Car dealer can register his vehicle by including type, description and location. Customer can
request a vehicle of his choice in a location he is based in mentioning the days he will be using it.
It will automate the price and the dealer can approve the request.
The user will see the approved request in his dashboard.
 TABLE OF CONTENTS

DECLARATION ....................................................................................................................... ii
ACKNOWLEDGMENT ............................................................................................................iv
ABSTRACT ................................................................................................................................v

CHAPTER ONE INTRODUCTION ........................................................................................ 13

1.0 Introduction ........................................................................................................................ 13

1.1 Background of the study .................................................................................................... 13
1.2 Statement of the problem ................................................................................................... 15
1.3 Research Objective. ............................................................................................................ 16
1.4 Research Questions ............................................................................................................ 16
1.5 Justification and Significance of the Study ........................................................................ 16
1.6 Scope of the Study.............................................................................................................. 18
1.7 Limitations of the Study ..................................................................................................... 18

CHAPTER TWO LITERATURE REVIEW .......................................................................... 20

2.0 Introduction ........................................................................................................................ 20

2.1 Theoretical Review ............................................................................................................ 20
2.2 Empirical Literature Review .............................................................................................. 23
2.3 Research gaps ..................................................................................................................... 28
2.5 Scope of the study .............................................................................................................. 29
2.6 Chapter Summary and Criticisms ...................................................................................... 30
CHAPTER THREE RESEARCH METHODOLOGY .......................................................... 32

3.0 Introduction ........................................................................................................................ 32

3.1 Research Design ................................................................................................................. 32
3.2 Target Population ............................................................................................................... 32
3.4 Instruments ......................................................................................................................... 33
3.5 Validity and Reliability Test .............................................................................................. 33
3.6 Data Collection Procedures ................................................................................................ 34
3.7 Data Processing and analysis ............................................................................................. 34
 CHAPTER FOUR DATA ANALYSIS AND PRESENTATION OF FINDINGS ........... 35
4.1 Introduction ........................................................................................................................ 35
4.2 Presentation of findings from staff and customers general information ............................ 35
4.3 Presentation of Data from Equity Staff .............................................................................. 38
4.4 Presentation of findings from Equity bank customers ....................................................... 47
4.5 Summary of Data Analysis ................................................................................................ 57

CHAPTER FIVESUMMARY AND CONCLUSIONS OF THE FINDINGS ...................... 61

5.1 Introduction ........................................................................................................................ 61

5.2 Summary of findings .......................................................................................................... 61
5.3 Conclusion .......................................................................................................................... 62
5.4 Recommendations .............................................................................................................. 64
5.5 Suggestion .......................................................................................................................... 65

REFERENCES ............................................................................................................................66

APPENDICES .............................................................................................................................69

LIST OF FIGURES
LIST OF TABLES
 CHAPTER 1

INTRODUCTION
1.1 Background Study
Car rental agencies are companies which rent cars for a short period of time for a fee to their
customers. In Kenya car rental services is increasingly becoming popular and a prefered option more so
to the recent employees as they cannot afford to buy their own and using of taxis is costly as well as its
inconsistency of arrival time. Also with the current covid 19 pandemic that doesn’t allow crowding
traveling with a private car is the best option. With the growth of this business it requires good and
improved monitoring system.

However some car rental agencies still use manual system to manage car rental operations. This manual
method is wasting money and time to both the car dealer and the customer. Therefore I proposed to
develop a system that can be used to provide ordering /booking and management to make work easier
for both parties. This system takes the information of the customer and the car dealer through filling of
their details. A customer being registered in the website has the ability to book a vehicle as required by
him. Car dealer as well can register their car to advertise and make it available to the user or customer.
The system will help them find car based on a location they are or want.
1.2 Problem Statement
Most of car rental agencies uses manual method for car renting process. This manual method is
tiresome and takes time as the car dealer goes out advertising about the available car to local residents
only. Customer also is required to contact the car dealer and contract out for a car and this will delay the
process of renting car. This method also consumes time and costly for both the customer and a car
dealer.
1.3 Objectives
The main objective of this project is to develop a system that allows a car dealer to advertise their
cars and allow customers to search any type of the car they want in the system.

1.3.1 Specific objectives

 To propose a system to manage a car rental business
 to allow customer to search and check the available cars
 generate reports of the business
 compute the total cost of renting a certain vehicle based on the number of days
1.4 Scope of the project.
The scope for this project are identified to make the system development process easier.

The scope of this project is explained as follows.

I. Admin.
 Manage and monitor the application
 Admin can view the report.
II. Car dealer.
 Register and login profile
 Register, update and delete car details.
 Approve booking status.
III. Customer.
 Register and login profile
 Search cars based on the city.
 Book the desired car
1.5 Limitation of the System
There is several limitation that is associated with this system.

Internet connection. This system requires the use of internet connection which may not be accessed by
most users.

This system also provide a minimum payment system.

 CHAPTER 2

LITERATURE REVIEW

2.1. Mobile Emerging Technologies

Mobile technologies such as global positioning systems (GPS), general packet radio service
(GPRS) and geography information systems (GIS), coupled with advanced Internet solutions,
provide both transparency and more specific information to supply chain collaborators in terms
of the instant localisation and traceability of shipments and also delivery status. Tsai (2006:526),
Durr and Giannopoulos (2003:175) and Skinner, Bryant and Richey (2008) have all concluded
that tracking physical goods in real time greatly improves logistical performance, cost efficiency
and customer satisfaction.
GPS are space-based, radio positioning systems that provide 24-hour three-dimensional position,
velocity and time information to suitably equipped users anywhere on the surface of the earth
(Malladi & Agrawal, 2002:10). The impact of these mobile technologies is all the more marked
on contemporary, sophisticated logistics which include multi-tiered suppliers and manufacturers
that are globally dispersed. It is, thus, apparent that, with the increase in global integration and
complex business networks, it imperative to develop network options beyond the boundaries of
internal logistics. This brings with it both new opportunities and also the risks inherent in
implementing new logistics. According to Turner (1996:51), other emerging techniques include
the following:

2.2 Electronic Distance Measuring Instruments

The integration of an electronic distance measuring instrument (DMI) with the floating car
technique provides an easier and safer way in which to collect detailed travel time information.
The sensor of the electronic DMI is attached to the test vehicle’s transmission with the DMI
being able to provide instantaneous speeds up to every 0.5 seconds (Thurgood, 1994). This
detailed travel time information can be automatically downloaded to a portable computer in an
easy-to-use data format. An electronic DMI coupled with a portable computer enables travel time
runs to be performed with a driver only. This technique provides detailed travel time and delay
information that is particularly valuable for the purposes of bottleneck identification and
intersection evaluation.
2.3 Cellular Phone Tracking.
The increasing popularity of cellular phones has enabled their widespread utilisation for the
purposes of traffic monitoring and travel time prediction (Robinson, Ewald, Gravely & Carter,
1993). In some areas there are dedicated numbers for cellular phone users to report either
emergencies or accidents. Cellular phones can also be used by motorists to report their positions
at designated checkpoints, thus allowing a traffic operations centre to estimate travel times based
on several cellular phone reports (Leveine, McCasland & Smalley, 1993:26). According to
Mondragon et al., (2009:229), mobile systems for vehicle tracking, also known as telematics,
constitutes an industry in the United States of America that will be worth US$41 billion by the
end of the first decade of the 21st century (Bisdikian et al., 2002:15).
 CHAPTER THREE

METHODOLOGY

3.1 Introduction
A methodology is a standard process followed to solve a particular problem. It is a method
showing the steps needed to analyze, design and maintain information systems. This chapter
entails a set of procedures, styles, rules, techniques, tools and documentation which will be
followed, they will help in the development and implementation of the proposed System

The establishment and use of sound engineering principles in order to obtain economically
developed software that is reliable and works efficiently on real machines is called software
engineering.

Software engineering is the discipline whose aim is:

i. Production of quality software
ii. Software that is delivered on time
iii. Cost within the budget
iv. Satisfies all requirements.

Software process is the way in which we produce the software. Apart from hiring smart,
knowledgeable engineers and buying the latest development tools, effective software
development process is also needed, so that engineers can systematically use the best technical
and managerial practices to successfully complete their projects.

A software life cycle is the series of identifiable stages that a software product undergoes during
its lifetime. A software lifecycle model is a descriptive and diagrammatic representation of the
software life cycle. A life cycle model represents all the activities required to make a software
product transit through its lifecycle phases. It also captures the order in which these activities are
to be taken.
3.2 Life Cycle Models
A number of software development methodologies that will possibly be used are as under:
A. The Waterfall Model
B. The Spiral Model
C. The Incremental Model
D. Structured Systems Analysis and Design Method (SSADM)
E. Object Oriented Analysis And Design OOAD)
F. The Prototype Model

3.2.1. Waterfall Model

It is also known as linear sequential model. The waterfall model derives its name due to the
cascading effect from one phase to the other. In this model each phase is well defined starting
and ending point, with identifiable deliveries to the next phase.
Figure 3.0: www.tutorialspoint.com
3.2.2. The Prototype Model
It involves coming up with a mockup of a product (software). A prototype is a working model
that is functionally equivalent to a component of the product. In many instances the client only
has a general view of what is expected from the software product. In such a scenario where there
is an absence of detailed information regarding the input to the system, the processing needs and
the output requirements, the prototyping model may be employed.
 CHANGED
REQUIREMENTS REQUIREMENTS
(verify)

RAPID
PROTOTYPING SPECIFICATIONS
(verify) (verify)

DESIGN (verify)

IMPLEMENTATION
(test)

INTEGRATION
(test)

MAINTENANCE

Figure 3.1: The prototype model

3.2.3. The Incremental Model

This model derives its name from the way in which the software is built. More specifically, the
model is designed, implemented and tested as a series of incremental builds until the product is
finished. A build consists of pieces of code from various modules that interact together to
provide a specific function. At each stage of the incremental model a new build is coded and then
integrated into the structure, which is tested as a whole.
The figure of incremental model is as under:

Implement and test

first build

Implement, integrate
and test successive builds
until product is complete

MAINTENANCE

Figure 3.3: The Incremental Approach

3.2.3.1 Advantages of Incremental Model

a) Incremental Model is more flexible
b) Incremental Model is easier to test and debug
c) Incremental Model has lower initial delivery cost
d) With Incremental Model, it is easier to manage risks.
3.2.3.2 Disadvantages of Incremental Model
a) Needs good planning and design,
b) Total cost is higher than waterfall,

3.2.3.3 When to use the Incremental Model

a) When there is need to get a product to market early,
b) When a new technology is being used,
c) When there are high risk features and goals,
d) Resources with needed skills set are not available.

3.2.4. Structured Systems Analysis and Design Method (SSADM)

In Structured Systems Analysis and Design Method (SSADM), system analysis and design is
realized through the use of tools such as Data Flow Diagrams (DFD) and Transform Analysis.
SSADM makes it easier to go back to earlier phases in the life cycle when necessary. There’s
portioning the problem into smaller units and making distinction between physical and logical
design. It is also referred to as a waterfall method for the production of an Information System
design. SSADM can be thought to represent a pinnacle of the rigorous document-led approach to
system design.

3.2.5. Object Oriented Analysis and Design

This refers to a process-oriented and data-oriented approach. It combines data and processes as a
single entity called an object. Unified Modeling Language (UML) is used in standard OOAD.

3.2.6 The Spiral Model

This model incorporates risk factors of each individual level. Some of the advantages of Spiral
model includes: -
 Easy to monitor progress through the use of milestones.
 Limited wastage of time since developers strictly work within specified time limits to
complete each and every phase.
 Simple and easy to understand and use.
 Easy to manage due to rigidity of the model i.e. each phase has a deliverable.
 Works well for small projects where user needs are clearly understood.
 High amount of risk analysis.
 Good for large and mission- critical projects.
  Strong approval and documentation control.
 Additional functionality can be added at a later date.
 Software is produced early.

Figure 3.4: Spiral Model Diagram

3.3 Solution Strategy and Choice of Methodology.

The various models discussed in this chapter have their merits and demerits. However, I will
recommend and approve the use of and implementation of Waterfall Model for my proposed
development due to the reasons below:

 Waterfall model will ensure every activity is done to completion before moving to the
next stage.
 Waterfall model will allow me to easily detects errors.
 Waterfall model is simple and easy to understand and use.

The Waterfall Model is simple to understand, since the step by step approach will make it viable
to use in development of System.

Despite its efficiency, it has several demerits that might trigger late delivery of the software.
These limitations are as shown below: -
3.3.1 Demerits of waterfall model
a) Customers does not know what they want, hence, it may encourage a re-work that is
expensive and time consuming.
b) It is often difficult to amend in an event of change in user needs.
c) Feasible designs may be actually difficult to implement.
d) It is not realistic since the system is developed by different parties e.g. programmers,
designers, system analysts among others.
e) No working software is produced until late during the life cycle.
f) Poor models for long and ongoing projects.

3.3.2 How to overcome criticism in Waterfall Model

To overcome the challenges that will be encountered while using the waterfall method I propose
the following solutions: -
 Proper requirement elicitation to capture all the user needs.
 Proper requirements analysis to avoid any incompleteness, inconsistency and ambiguity
that might result in re-work.
 Requirements review to capture any change in user need at an early stage.
 Designing the system to accommodate any change in an event that they arise.

3.3.3 When to use Waterfall Model

 When the project is short.
 When the user requirements are short, clear and constant.
 When the problem definition is stable.
 When there are no ambiguous requirements.
 When ample resources and requirements are readily available.

3.4 Criticism of the other models.

The reasons why the other models will not be preferred to Waterfall Model are as stated below:

 Spiral model: is a costly model to use and requires highly specific expertise. Waterfall
Model is cheaper and simple to use.
  Incremental Model: Its total cost is higher than it is in waterfall model which is much
cheaper to use.
 Prototype Model: is wasteful in terms of resources i.e. time, and costly too unlike the
Waterfall Model.

3.5 Requirements Elicitation

These are user descriptions of user needs and specification of software to satisfy those needs.

The process of requirement engineering will entails the following strategies: -

 Interviews
 Questionnaires
 Observation
 Use cases
 Scenarios

3.5.1 Interviews
Interviewing is a face-to-face interrogation with respondent or a verbal method of information
gathering that involves asking of questions to the stakeholders of the system. It is verbal. This
method is not easy because most of those to interview have to create time for the interview. In
the contrary one get to ask questions in cases where there is something that is not clear.

3.5.2 Observation
Observation is a method of eliciting information by simply seeing what is happening. The
observer has to be physically there to see how the operations are conducted.

3.5.3 Scenarios

A scenario is a narrative describing foreseeable interactions of types of users and the system.
Scenarios attempts to reflect on or portray the way in which a system is used in the context of
daily activity.
The following are scenarios of some operations that will be encountered in the system:

3.5.3.1 Scenario 1: User Login Process

 A user clicks on the login link

 Log in form is loaded
 User enters password and username to gain entry into the system
 If details entered are correct, customer account is loaded, otherwise a dialog box
displaying error message is displayed on the screen.
 A customer can log out of the account by clicking on the log out tab.

3.6 Tools and Software

This are the tools and software’s that will be used to do the proposed system.
 A Complete and Functional Laptop/Desktop PC: To save programs and the project itself
 Printer: For output of printouts.
 Microsoft Visio 2007: for drawing flowcharts, DFDs, ERD and use cases diagrams
 Microsoft Project Professional: For Project Scheduling & Planning and Charts
generation.
 Compilers and Editors.

3.7 Possible StrategiesWeb, Distributed, Files

A. GUI, Distributed, Files

B. Web, Distributed, Database

C. GUI, Distributed, Database

D. Web, Standalone, Database

E. GUI, Standalone, Database

STRATEGY ECONOMIC SECURITY TECHNOLOGY TOTALS

A 7 4 3 14
B 6 6 7 19
C 9 2 9 20
D 3 8 4 15
E 5 6 2 13
 F 9 7 5 21
Strategies Comparison Table

Table 3.1: Strategy Comparison

The strategy labelled (F) i.e. GUI, standalone and database is the most applicable than the
others. The reasons being that it is economical, secure and technologically less complex and
modern.
 CHAPTER FOUR

4.0 ANALYSIS AND DESIGN

4.1 Introduction

A software design is a meaningful engineering representation of software product that is to be

built. During the design process the software specifications are transformed into design models
that describe the details of the data structures, system architecture, interface, and components.
Each design product is reviewed for quality before moving to the next phase of software
development. Design focuses on four major areas. These are

o Data design – In this stage emphasis is placed on the patterns as they relate to the
application to be built.
o Architecture design- it involves relationships between components of the system
o Interface design -in this case human ergonomics often dictate the design approach
employed.
o Component design – in this stage the design is concerned with a “programming
approach” which leads to effective data and procedural designs.

4.2 Data Design

It is created by transforming the analysis information model (data dictionary and ERD) into data
structures required to implement the software. MySQL database is used to construct and store the
database. Entity Relationship Diagram and data dictionary forms the basis of the data design
used.

4.3 Architectural Design

It defines the relationships among the major structural elements of the software, the “design
patterns” than can be used to achieve the requirements that have been defined for the system, and
the constraints that affect the way in which the architectural patterns can be applied. It is derived
from the system specification, the analysis model, and the subsystem interactions defined in the
analysis model (DFD).
4.3.1 System Modules
The modules that make up this system architecture are:

4.3.1.1 Players Registration Module

This is of important use when it comes to players’ registration. This is where the user enters
details of the players and uploads their documents and photos.

4.3.1.2 Staff Sign in Modules

This module is of importance to user with credentials and they can log in and out any time. They
are free to interact with the system when serving clients.

4.3.1.3 User Registration Module

It gives opportunity to new users to acquire their credentials for the first time so that they can
enjoy the benefits of the system.

4.4 Interface Design

It describes how the software elements communicate with each other, with other systems, and
with human users. The System uses the Graphical user interface (GUI).

4.5 Component-Level Design

This level is created by transforming the structural elements defined by the software architecture
into procedural descriptions of software components. A component could be a mathematical
function. The basis for this level of design is the Process Specification (PSPEC), the CSPEC
(control specification), and State Transition Diagrams (STDs).
The following design tools have been used:
 Pseudo codes
 Structured flowcharts
4.5.1 Pseudo codes
The following pseudo codes have been used to provide procedural description of the software
components used in the system.

Pseudo codes for Login Process

Begin
Enter User_Name
Enter Password
If User Name and Password are correct, then
{
Open User Account
Choose Options in account
}
Else
{
Display: “Incorrect User Name or Password
}
End

4.5.2 Structured Flow Charts

A flowchart is a diagrammatic representation of a pseudo code. Flowcharts are used to show the
flow of execution carried out by a specific module. There are various symbols associated with
flowcharts, each with different function and meaning.
User Login Flowchart

START

E n ter U se rN a m e a n d
P a ssw o rd

U serN am e o r
U serN a m e & NO
P a ssw ord In co rect.
P a ssw o rd C o rrect?
P le a s e t r y a g a in

YES

U ser A cco u n t STO P

Figure 4.2: User Login Flowchart

It describes all activities ranging from authentication of user login credentials i.e. User Name and
Password to allow access to user accounts. This is meant to enforce security in the system.
Vehicle ordering Evaluation Process

START

Enter the car type

No

Vehicle found? No Vehicle

found

yes

Order vahicle

STOP
System Flowchart.

This flowchart gives the general and summarized functionality of the entire system, ranging from
user login to user logout.
4.6 DATA FLOW DIAGRAMS
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modeling its process aspects. They are used to create an overview of the
system. DFDs are also used for the visualization of data processing (structured design).
A DFD shows what kinds of data will be input to and output from the system, where the data will
come from and go to, and where the data will be stored.

4.6.1 Components of Dataflow Diagrams

Luckily there are only four different symbols that are normally used on a DFD. The elements
represented are:

 External entities
 Processes
 Data stores
 Data flows
The four symbols used in DFDs represent data flows, data stores, processes, and sources/sinks.

4.6.2 Level-0 DFD (Context diagram)

The highest level DFD is called a context diagram. It represents the system as a single process,
with all the related entities and the data flows in and out of the system. Since the data stores of
the system are conceptually inside the one process, no data stores appear on a context diagram.
Context diagram shows the system boundaries, external entities that interact with the system and
major information flows between entities and the system.
This Dataflow Diagram provides an overview of the data entering and leaving the system. It also
shows the entities that are providing or receiving that data. These correspond usually to the
people that are using the system already developed. The context diagram helps to define our
system boundary to show what is included in, and what is excluded from, our system. The
diagram consists of a rectangle representing the system boundary, the external entities interacting
with the system and the data which flows into and out of the system.
4.7 ENTITY RELATIONSHIP DIAGRAM (ERD)
An entity-relationship diagram (ERD) is a type of data modeling that shows a graphical
representation of objects or concepts within an information system or organization and their
relationship to one another. It is also a graphical representation of an information system that
shows the relationship between people, objects, places, concepts or events within that system.
Entity-Relationship Diagram (ERD) is composed of entities, attributes and relationship among
them. It is a data modeling technique that can help define business processes and can be used as
the foundation for a relational database.
 Employs

Name User_Name DEPARTMENT

Communicates
CLIENT MANAGER
With

Names

Manages
Department

OTHER STAFFS Sends reports to

UserName Official_Name

While useful for organizing data that can be represented by a relational structure, an entity-
relationship diagram can't sufficiently represent semi-structured or unstructured data, and an
ERD is unlikely to be helpful on its own in integrating data into a pre-existing information
system.

4.8 USE CASES

Use cases are diagrams that represent how the software functions from users’ point of view. It
shows a pictorial view of operations that are carried out in the system by the user and how the
system responds.
Use cases for Admin

processes orders and

issues receipts

Views all orders

Administrator

adds/deletes/vehicl
es vehicles/stock