AMBO UNIVERSITIY

HACHALU HUNDESSA CAMPUS

SCHOOL OF INFORMATICS AND ELECTRICAL ENGINEERING

DEPARTMENT OF COMPUTER SCIENCE

A PROJECT SUBMITTED TO DEPARTMENT OF COMPUTER

SCIENCE IN PARTIAL FULFILLMENT FOR THE BACHLOR DEGREE
IN COMPUTER SCIENCE

PROJECT ON

FLEET MANGEMENT SYSTEM FOR AMBO UNVERSITY

SUBMITED BY: -

1. DESALEGN TARIKU…………………………. TUS/11857/11

2. TIRUALEM DIRESS…………………………… TUS/11773/11
3. REDIET ABABU………………………………. TUS/11606/11
4. DEMEKE DAGNE……………………………… TUS/11778/11
5. GIZEW MASRESHA…………………………... TUS/01721/09
6. MULALEM ASSEFA……………………………BRT/0182/10

Advisor name: - Wakjira Bekele (MSc)

FLEET MANAGEMENT SYSTEM FOR AU

Approval page

Name Signature
1. Desalegn Tariku ---------------------------
2. Tirualem Diress ---------------------------
3. Rediet Ababu ---------------------------
4. Demeke Dagne ---------------------------
5. Gizew Masresha ---------------------------
6. Mulalem Assefa ----------------------------
The project has been submitted for examination with my approval as university advisor.
Advisor Name: ____________________signature______________date_____________________

Name Signature

Project coordinator

---------------------------- ---------------------------

Advisor

---------------------------- ---------------------------

Examiner

---------------------------- ---------------------------

i
FLEET MANAGEMENT SYSTEM FOR AU

Acknowledgment
First of all we would like to thank Almighty GOD for the strength, he has given us
throughout our life and this project; nothing could happen without the help of GOD.
Secondly, we would like to express our gratitude to our advisor Mr. Wakjira Bekele
(MSc) for his help, willingness, and commitment in giving his precious time to help us to
accomplish this work. We are also very grateful and would like to extend our sincere
thanks to department of computer science staff members and students of our Department
of Computer Science for sharing their ideas, suggestions, and support and especially for
their commitment. We really give a great respect and credit to everyone who involved in
our project tasks.

ii
FLEET MANAGEMENT SYSTEM FOR AU

List of Table
Table 1 Time schedule ....................................................................................................... 7
Table 2 Hard ware Requirements ................................................................................... 15
Table 3 Software Requirements------------------------------------------------------------------16
Table 4 Hardware Cost .................................................................................................... 16
Table 5 Software Cost ...................................................................................................... 17
Table 6 Use case description for Login ........................................................................... 22
Table 7 Use case description for Calculating fuel balance ............................................ 23
Table 8 Use case description for Request maintenance record ...................................... 24
Table 9 Use case description for prepare vehicle schedule ............................................ 25
Table 10 Use case description for Vehicle registration .................................................. 26
Table 11 Use case description for update vehicle record ............................................... 27
Table 12 Use case description for generate report.......................................................... 28
Table 13 Use case description for create user account................................................... 29
Table 14 Use case description for delete user account ................................................... 30
Table 15 Use case description for View exit request....................................................... 31
Table 16 Use case description for notify exit permission ............................................... 32
Table 17 Use case description for Request for exit ......................................................... 33
Table 18 Use case description for update user account ................................................. 34
Table 19 Class responsibility collaboration (CRC) ......................................................... 38

iii
FLEET MANAGEMENT SYSTEM FOR AU

List of Figures
Figure 1 Use Case Diagram ........................................................................................... 21
Figure 2 Class diagram.................................................................................................... 37
Figure 3 Sequence diagram for Login ............................................................................ 41
Figure 4 Sequence diagram for Prepare schedule ......................................................... 42
Figure 5 Sequence diagram for vehicle registration ...................................................... 43
Figure 6 Activity diagram for Balance sheet ................................................................. 45
Figure 7 Activity diagram for vehicle registration ......................................................... 46
Figure 8 Activity diagram for Update vehicle ................................................................. 47
Figure 9 Activity diagram for Generate report ............................................................... 48
Figure 10 Activity diagram for view reserved vehicle .................................................... 49
Figure 11 State chart diagram for login ......................................................................... 51
Figure 12 State chart diagram for admin for adding user account ............................... 52
Figure 13 State-chart diagram for scheduling ............................................................... 53
Figure 14 Sequence diagram for generate report........................................................... 55
Figure 15 Activity diagram for Administrator create user account ............................... 56
Figure 16 Proposed software architecture ...................................................................... 59
Figure 17 subsystem decomposition ................................................................................ 61
Figure 18 component diagram ........................................................................................ 62
Figure 19 Deployment diagram....................................................................................... 63
Figure 20 Persistence modeling for object-oriented database ....................................... 65

iv
FLEET MANAGEMENT SYSTEM FOR AU

Acronyms/Abbreviations
AU: -Ambo University
CD: -Class Diagram
CRC: - Class responsibility collaboration

CSS: - cascade style sheet

FMSAU: - Fleet Management System of Ambo University

GSM: -General Service Manager

HTML: -Hyper Text Markup Language

MySQL: - My Structured Query Language

OOP: - Objected Oriented Programming

OOPL: - Objected Oriented Programming Language

PHP: -Hyper Text Preprocessor

SRS: -System Requirement Specifications

UC: -Use Case

UML: -Unified Modeling Language

v
FLEET MANAGEMENT SYSTEM FOR AU

Contents
Approval page ................................................................................................................................... i
Acknowledgment ............................................................................................................................. ii
List of Table ..................................................................................................................................... iii
List of Figures .................................................................................................................................. iv
Acronyms/Abbreviations ................................................................................................................. v
Abstract ............................................................................................................................................ x
CHAPTER ONE .................................................................................................................................. 1
1. INTRODUCTION ........................................................................................................................ 1
1.1 BACKGROUND OF THE ORGANIAZTION ........................................................................... 1
1.2 Statement of the problem ............................................................................................... 2
1.3 Objective of the project ................................................................................................... 3
1.3.1 General objective ..................................................................................................... 3
1.3.2 Specific objectives .................................................................................................... 3
1.4 Scope and limitation of the project ................................................................................. 3
1.4.1 Scope of the project ................................................................................................. 3
1.4.2 Limitation of the Project........................................................................................... 3
1.5 Risks and Contingencies ................................................................................................... 4
1.5.1 Risk ........................................................................................................................... 4
1.5.2 Contingencies ........................................................................................................... 4
1.6 Assumptions and constraints ........................................................................................... 4
1.6.1 Assumptions: ............................................................................................................ 4
1.6.2 Constraints: .............................................................................................................. 4
1.7 The significance of the project ......................................................................................... 4
1.7.1 Target Beneficiaries of the system ........................................................................... 5
1.8 Methodology.................................................................................................................... 5
1.8.1 Data Collection ......................................................................................................... 5
1.8.2 System Analysis and Design Methodology............................................................... 6
1.9 Tools and Techniques ...................................................................................................... 6
1.10 Task and schedule ............................................................................................................ 7
CHAPTER TWO ................................................................................................................................. 8

vi
FLEET MANAGEMENT SYSTEM FOR AU

2 The existing system .................................................................................................................. 8

2.1 Existing system description .............................................................................................. 8
2.2 Players of the existing system .......................................................................................... 8
2.2.1 Major functions/activities in the existing system .................................................... 9
2.2.2 Business Rule ............................................................................................................ 9
2.2.3 Report generated in the existing system................................................................ 10
2.2.4 Bottlenecks of the existing system ......................................................................... 10
2.3 Practices to be preserved .............................................................................................. 11
2.4 Proposed solution of the new system that address problems of the existing system .. 11
2.5 Feasibility of the project ................................................................................................ 12
2.5.1 Operational Feasibility ........................................................................................... 12
2.5.2 Technical Feasibility ............................................................................................... 12
2.5.3 Economic Feasibility ............................................................................................... 12
2.5.4 Behavioral/Political feasibility ............................................................................... 13
2.5.5 Schedule feasibility ................................................................................................. 13
2.5.6 Legal feasibility ...................................................................................................... 13
2.6 Requirements of the Proposed System ......................................................................... 14
2.6.1 Functional requirements ........................................................................................ 14
2.6.2 Non-functional requirements ................................................................................. 14
2.7 Hardware and Software Requirement ........................................................................... 15
2.7.1 Hard ware requirements ........................................................................................ 15
2.7.2 Software requirements .......................................................................................... 16
2.8. Cost Budgeting .................................................................................................................... 16
CHAPTER THREE ............................................................................................................................. 18
3. SYSTEM ANALYSIS ...................................................................................................................... 18
3.1 Introduction ......................................................................................................................... 18
3.2. System requirement specification (SRS) ........................................................................ 18
3.3. Production function ....................................................................................................... 18
3.4. User characteristics ........................................................................................................ 19
3.5. General constraints ........................................................................................................ 19
3.5.1. Communication interface ....................................................................................... 20

vii
FLEET MANAGEMENT SYSTEM FOR AU

3.6. Use cases ........................................................................................................................ 20

3.6.1. Actors in the system ............................................................................................... 20
3.6.2. Use case description ............................................................................................... 21
3.7. Object diagram .............................................................................................................. 35
3.8. Class diagram ................................................................................................................. 36
3.8.1. Class Responsibility Collaborator (CRC) Cards ....................................................... 38
3.9. Sequence diagram.......................................................................................................... 40
3.10. Activity diagram ......................................................................................................... 44
3.11. State Chart Diagram ................................................................................................... 50
3.12. Analysis Model ........................................................................................................... 54
3.12.1. Sequence Diagram ................................................................................................. 55
3.12.2. Activity Diagram..................................................................................................... 56
CHAPTER FOUR .............................................................................................................................. 57
4. System design ........................................................................................................................ 57
4.1. Introduction ................................................................................................................... 57
4.1.1. Purpose of the system ............................................................................................ 57
4.1.2. Design goals ........................................................................................................... 57
4.2. Current software architecture ....................................................................................... 58
4.3. Proposed software architecture .................................................................................... 58
4.3.1. Subsystem Decomposition ..................................................................................... 59
4.3.2. Hardware/ Software Mapping ............................................................................... 62
4.3.3. Persistence modeling for object-oriented database .............................................. 63
4.3.4. Access control and security .................................................................................... 65
4.3.5. Global Software Control ......................................................................................... 65
4.3.6. Boundary Conditions .............................................................................................. 66
CHAPTER FIVE ................................................................................................................................ 68
5. TESTING AND IIMPLIMENTATION .............................................................................................. 68
5.1. Testing ................................................................................................................................. 68
5.1.1 Hardware Software Acquisition .................................................................................... 69
5.1.2. User Manual Preparation............................................................................................. 70
5.2. Training ............................................................................................................................... 72

viii
FLEET MANAGEMENT SYSTEM FOR AU

5.3. Installation .......................................................................................................................... 73

5.4. Startup Strategies ............................................................................................................... 73
CHAPTER SIX................................................................................................................................... 76
6. CONCLUSION AND RECOMMANDATION ................................................................................... 76
6.1. Conclusion ...................................................................................................................... 76
6.2. Recommendation........................................................................................................... 77
Reference ....................................................................................................................................... 78
Appendix ........................................................................................................................................ 79

ix
FLEET MANAGEMENT SYSTEM FOR AU

Abstract
The ideal solution for Fleet Management System is specially designed to realize web-
based fleet managing, controlling and supervision for Ambo university vehicles and to
carry out further services such as maintenance and scheduling. The main purpose of this
system is to develop a web-based Fleet Management System for Ambo University. The
purpose of developing this application will help to modernize the vehicle management
process in our organization and avoid any human errors. Vehicle information manually,
especially when many vehicles are there for the organization, is a tedious process. One of
the major tasks is sending the vehicles for servicing. In manual process there is no
provision to know that the vehicle should be sent for servicing that is why the vehicle
record is verified manually.
The project involves methods like data/requirement collection, system analysis and
design(object oriented approach).It also includes the use of hardware and software‟s like
operating system, Database Management System ,application software,
PhpMyAdmininstration and the likes. DBMS for the purpose of database implementation.
To do this system we have used different methodology to get information about the
system and to analysis, use software tools like notepad++ to write the HTML and PHP
code, Google chrome to test the function of the system, and we have used different
languages and scripting language like html, MySQL, XAMPP server, to develop system.
, we have used hardware tools like computer, USB flash to write and store our data.

x
FLEET MANAGEMENT SYSTEM FOR AU

CHAPTER ONE

1. INTRODUCTION

1.1 BACKGROUND OF THE ORGANIAZTION

Ambo University is situated 110 kilometers north of Addis Ababa, in a mountainous

landscape. The university is one of the well-known higher educational institutions in
Ethiopia providing quality services to its customers. Hopeful to be one of the leading
higher learning institutions in Ethiopia, Ambo University developed both in physical
infrastructures, human resources and in its service provisions to the community. The
University nowadays is performing expansion and development plan which expects a
combined effort of different sectors with. Now, Technology is spreading its wings in
almost every walk of human life activity. Those activities are done using new technology
in order to fulfill the need of human being, organization, and enterprise. As today‟s world
there are many organizations and each need to be preferable, computable, and work on
faster way in order to satisfy user interest. Therefore, they should have to facilitate their
activity in computerized way. In Ambo University, employers use transportation or get
service from university itself. Currently the university use manual system like scheduling
to give service, by filling written form for vehicle maintenance, putting detail information
of each vehicle. While giving those activities it stores the data in a file cabinet which
creates inefficiency in terms of access, track, and store information in the working
environment. During they use this manual system they couldn‟t control how many
kilometers the vehicle traveled and fuel consumed. By observing those problems this
project is going to solve the above problems. The fuel is given to driver depending on
distance in kilometer, but they don‟t know by what speed the driver drives the vehicle
and fuel consumed, also the driver uses different forms for maintenance then it can be
maintained in two ways. These are preventive maintenance and breakdown maintenance,
gradually the number of forms in the operation creates complicated file handling system
which is difficult in organization and creating different queries.

1
FLEET MANAGEMENT SYSTEM FOR AU

Keeping in view of all such problems, the existing system translated to automated system
for information process, management, and distribution. The data processing structure
should be centralized and function in accordance with hierarchal structure.

Fleet management is one of the core functions of any logistics company. Companies that
operate large fleets of vehicles need to have easy access to a variety of data, ranging from
the location of their vehicles to the Return on Investment (ROI) each vehicle is providing
the company. This data is crucial to the functioning of the company as it helps fleet
managers make crucial decisions like the required fleet size at any point or how to
redirect resources to meet requirements [1].

The new system must state a privilege and authentication mechanism through which
different clients react on hierarchical basis and be able to generate specific reports about
their actual task.

We will design and implement a working automated model of the system in the problem
area which calculation fuel balance and it show how much the fuel consumed.

1.2 Statement of the problem

 In Vehicle management offices information exchange and service control is

processed in manual way and which makes the communication of the
working environment difficult to manage and control.
 Difficulty to get the required detailed information about specific vehicle or
item at one place in a short period of time. And due to the presence of data
redundancy under different titles about the same object, the creation of
summary and the process of generating report about individual item has
become a challenge in the existing system
 It takes time to prepare the schedule of maintenance for vehicles and the
vehicles to run extra service time and this would increase the possibility of
vehicle failure.
 Files are randomly processed despite the position and hierarchy of workers or
clients in the existing system.

2
FLEET MANAGEMENT SYSTEM FOR AU

1.3 Objective of the project

1.3.1 General objective

The main aim of this project is to develop web-based Fleet management system for
Ambo University.

1.3.2 Specific objectives

To achieve the above general objective, we will use the following specific objectives.
 Identifying problems of the Existing System to design the new system.
 Developing database system for vehicle system
 Design interactive user interface for Fleet management system
 Test and evaluate the performance of the system

1.4 Scope and limitation of the project

1.4.1 Scope of the project

As the working system makes use of manual operations in Fleet management system,
therefore the scope of our project plans and targets in developing and implementing web-
based system to replace and solve the problems within the existing manual system.
 Prepare regular maintenance.
 Managing vehicle information.
 Calculate fuel consumption.
 Updating registered vehicles.
 Enabling the users to submit the required information in computerized way.
 Facilitates concise report for higher level decision making quickly and
efficiently without waiting for working hours or days.

1.4.2 Limitation of the Project

In case of our project the system does not support the following activities:
 The system does not ring for servants if they are busy of worker
 The system is only understandable by those who can read and write English well.

3
FLEET MANAGEMENT SYSTEM FOR AU

1.5 Risks and Contingencies

1.5.1 Risk
 Finance: the group members don‟t have income.
 Power: there might not be enough power supply.
 Schedule: we might not finish the project in time.
 Resource: there might be not information available.

1.5.2 Contingencies
 Network access might suddenly be closed
 Instant loss of power

1.6 Assumptions and constraints

1.6.1 Assumptions:
We are assuming that everybody has access to the internet

 We are assuming that everybody can understand English

 We are assuming that everybody has a smart phone, personal computer, or access
to a desktop

1.6.2 Constraints:
 No enough experience.
 The reference and materials available might not be sufficient or enough.

1.7 The significance of the project

 Avoiding improper resource consumption.

 Avoiding data loss because of improper data storage.
 Minimize cost of operations.
 Minimize time delay in getting information/reports.
 Anyone anywhere can get the status report of the vehicles only by authorization.

4
FLEET MANAGEMENT SYSTEM FOR AU

 Improve fast communication between internal departments of the organization.

 Higher authority can get summarized information via manager for quick decision-
making process.

1.7.1 Target Beneficiaries of the system

 The University

The university get beneficiary from this system the first is cost reduction from fuel
consumption and tangible benefits like paper and pen reduction.

Working will be easy for the staff so user will be satisfied.

 Vehicle management office

First the environment will be changed the system to computerized, which improve the
quality of internal operation as well as service distributed between workers in the office.

 Vehicle scheduler

For the vehicle scheduler it reduces time and power which wasting on the paper they can
easily schedule on the computer.

 Deriver

The system is any time available so derivers don‟t have to wait working time to get
approval.

1.8 Methodology

Among the different methodologies in practice, we thoughtfully pay our time to work on
Object Oriented Programming (OOP) approach for achieving effective and reliable
working system in the future.

1.8.1 Data Collection

We have taken the forms from the existing system.
Fact Finding Techniques

5
FLEET MANAGEMENT SYSTEM FOR AU

Interview: - we will gather information by asking personnel in vehicle management

offices at Ambo University and other experts.
Questionnaires: we will prepare some questions for the fleet management office and, we
will gather different information. Such questions are raised like:
 What seems like is the work flow in the organization?
 What tasks are performed in the organization?
 Is there any work division in the system?
 What are the problems in your current system? Is that manual or
computerized?
 What kind of maintenance can take place?
 In what way the fuel and other resources are distributed to the drivers?

1.8.2 System Analysis and Design Methodology

Among the different methodologies available we will use the object-oriented design
methodology for the development of our system. Because it is best way to construct,
manage and assemble objects that are implemented in our system, and the composition of
objects and collaboration between objects on the system.
OOP stands for Object-Oriented Programming. As you can guess from its name it
breaks the program based on the objects in it. It mainly works on Class, Object,
Polymorphism, Abstraction, Encapsulation, and Inheritance. Its aim is to bind together
the data and functions to operate on them [2].

1.9 Tools and Techniques

Through the development of our project, we used the following: -

Tools

 Microsoft office word

 Chrome
 Laptop
 desktop
 Visual studio code
 Sublime text editor
 Adobe Photoshop

6
FLEET MANAGEMENT SYSTEM FOR AU

Techniques

 Analyze the current vehicle management technique

 Develop through testing progress
 Developing in team

1.10 Task and schedule

This project would be feasible because we hope that it will be completed within the time
scheduled given below: -

Table 1 Time schedule

ID Activities Start Finish 2022 2023

Nov Dec Jan Feb Mar Apr May Jun Jul

1 Preparing Proposal 16/11/2022 23/12/2022

2 Proposal presentation 24/1/2023 24/1/2023

3 Analysis 16/1/2022 25/1/2023

4 Design 25/1/2023 14/2/2023
5 Documentation 15/2/2023 15/2/2023
presentation
6 Implementation & coding 14/3/2023 7/6/2023

7 Testing 7/6/2023 15/6/2023

8 Project closure 16/6/2023 16/6/2023

7
FLEET MANAGEMENT SYSTEM FOR AU

CHAPTER TWO

2 The existing system

2.1 Existing system description

The fleet management system has a full responsibility over addressing and reporting
about each typical vehicle which undergone maintenance process and organizes
information, which has ended up under spare part offices for sake of report generating
and creating deployment plans. The head of vehicle management office (manager) has a
crucial role and responsibility to control and coordinate the overall process generated in
the system.
The working system however literally faces different problems while managing and
controlling distributed data. Vehicle management office has unordered data also in its
system about a single entity and sorting the functional vehicles at work. The currently
working manual system is making use of different forms and memos for same
applications and gradually the number of forms in the operation creates complicated file
handling system which is so difficult in organization and creating different queries. If an
authorized person needs information about a specific vehicle must go through all the
records manually which is so exhaustive and inefficient.

2.2 Players of the existing system

The actors in the current system are: -

 Vehicle scheduler
 GSM
 Driver
 Property worker

8
FLEET MANAGEMENT SYSTEM FOR AU

2.2.1 Major functions/activities in the existing system

The following section will summarize the function of existing system with their input,
process, and output:
Vehicle scheduler
 Input: -receive number of available vehicles from GSM which is ready for
transportation.
 Process: - schedule the vehicles.
 Output: - give dispatch for the vehicles.
GSM
 Input: - accesses all information of the entire system from the
organization and generate reports.
 Process: - control all functions.
 Output: -send report to the respected body.
Driver
 Input: - inform about the vehicle damage requires maintenance if
damaged.
 Process: - fill spare parts (that he/she need to maintain) in the form.
 Output: - after filling the form the driver passes the form to GSM for
confirmation [3].

2.2.2 Business Rule

 Vehicles should be maintained when they are damaged or based on
schedule maintenance report.
 A driver should report and fill a given form in case of maintenance and
fuel refilling.
 Vehicle scheduler should receive a status of vehicle information and must
prepare a deployment plan according to the data gathered.
 Different forms and documents should be fulfilled by the respected body.

9
FLEET MANAGEMENT SYSTEM FOR AU

2.2.3 Report generated in the existing system

In the manual system reports are practically generated from vehicle maintenance and
vehicle safety and transport service to general service team per month, per 2 weeks, per 1
week, quarter year and generally yearly [4]. The general service team has responsibility
to send the report to managing director office in the University for further Consideration
in decision making processes. The Forms and other documents of the existing system
such as Vehicle deployment schedule form shown at [Appendix one], generated report
Form shown at [Appendix two].

2.2.4 Bottlenecks of the existing system

 Performance (Response time)

In terms of performance, the existing/manual system is not a satisfactory because it is

slow/time consuming, energy consuming and does not support computerized information
system about the availability of vehicles and their status in anywhere anytime fashion. In
such cases it delays other systems in their duties.
 Input (Inaccurate/redundant/inflexible) and Output (Inaccurate)

In the current system of Ambo University Fleet management system, the information of a
certain vehicle could be inaccurate, redundant and inflexible and these inputs may leads
to create confusion and unnecessary burden on employees and produce inaccurate output.
 Security and Controls

Since every file and record of the status of vehicles is stored in the manual way, it is
difficult to control and secure these manual files/data. Any unexpected disaster may
collapse the whole database.

 Efficiency

Existing system has limitations in terms of speed, 24/7 online, and lower abilities. But the
new system will give 24/7 services and better abilities.

10
FLEET MANAGEMENT SYSTEM FOR AU

2.3 Practices to be preserved

The existing system of this project use file and forms that is used to perform the business
rules, describe the operations, definitions and constraints that apply in the maintenance
and deployment system. Team member preserves (keeps) the following practices from
the existing system.
 Every driver assigned to a vehicle passes check point if and only if he is able to
deliver letter to the guards at gates.
 The priority of scheduling a vehicle is dependent on the importance of a mission
in the university. The one that is more sensitive and convincing mission always
served firstly. Besides in case of emergency vehicle scheduling is highly affected.

2.4 Proposed solution of the new system that address problems of the
existing system

The new system addresses the problems of the existing system by supporting the vehicle
management with a web-based technology by providing well organized, flexible, and
effective means of communication. This includes: -
 Changing the manual system in to web-based system without affecting the
structure of the organization.
 Developing easily accessible information/documents that is clear to
employees when accessing data in 24/7 model.
 Avoiding wastage of time during searching information due to holidays/
office time restrictions.
 To avoid redundancy of records in the working system as the proposed
system provides mechanisms to sort files in database system.
 To avoid wastage of paper work on records in the system.
 Control unauthorized access by providing authentication and authorization.

11
FLEET MANAGEMENT SYSTEM FOR AU

2.5 Feasibility of the project

2.5.1 Operational Feasibility

The new system operations are highly likely accepted by users regarding providing better
performance relative to the existing system enhancing the efficiency and effectiveness of
task processing by making the whole system user acceptable and make them happy by
using it.
The system will be also tested on different basis and mechanisms of testing a module and
the team founds the already built system to fit any investigations and expectations.

2.5.2 Technical Feasibility

The new system works every activity in simple and technical manner. The system does
not require more professional person to process the implemented system. That means the
organization worker can performs the system without the need of any professional man
from the outside. As much as possible the system is easily understandable. So, every
customer in the organization can access without any confusion. Since the University has
sufficient computer hardware and software facilities for the betterment of the application
usage. So we are attempt to make the system technical feasible without any extra efforts

2.5.3 Economic Feasibility

The system to be developed is economically feasible and the benefit is balancing the cost.
Since this project already computerizes the existing system, by reducing cost for
materials used in manual operation becomes beneficiary to the organization.
Generally, the system we developed for fleet management office brought several
Tangible and intangible benefits.
Tangible benefits
 Reduction of paper and pen.
 Reduction of space needed to record data
Intangible benefit:
 Makes the employers more satisfied
 Give better and effective service
 Error reduction

12
FLEET MANAGEMENT SYSTEM FOR AU

 Increase security
 Increase speed

2.5.4 Behavioral/Political feasibility

Different concerned individuals such as the manager, secretary and other employees of
the association have good approach and view towards this project and they wish to play
an important role on this system by giving good ideas to produce better and efficient
results.

2.5.5 Schedule feasibility

Schedule feasibility is concerned with analyzing the expected completion date of the
project and

The constraints that may bring change to this date .we have so many fixed schedule to
work together

The project with all groups within each day and for the simplicity and fast developing
purpose.

The schedule for this project is feasible due to rich information exchange between the
organization and the developing team

2.5.6 Legal feasibility

The system is exactly comfortable with any legal or rule and regulation.

The system complies the rule and regulation of the data processing system. Therefore,
since the system does not conflict with any rules and regulation then the system is legally
feasible.

13
FLEET MANAGEMENT SYSTEM FOR AU

2.6 Requirements of the Proposed System

2.6.1 Functional requirements

Functional requirements describe what the system will do and specify behavior or
function. And, functional requirements drive the application architecture of a system. A
requirement specifies a function that a system or component must be able to perform.
Functional requirements specify specific behavior or functions. The functional
requirements of the proposed system are listed as follows: -
 Calculating fuel consumption per liter.
 Vehicle registration.
 Filling Fuel Cost
 Update vehicle record.
 Scheduling vehicles daily.
 Maintenance request record.
 View Maintenance request.
 Managing user accounts.
 Generate report.
 Create, Update, and User account
 Approve exist request
 Prepare Vehicle schedule
 Request Maintenance
 Login
 Logout

2.6.2 Non-functional requirements

Non-functional requirements are quality attributes or aspects of how the system is
designed, built, or implemented. In systems engineering and requirements engineering, a
non-functional requirement is a requirement that specifies criteria that can be used to

14
FLEET MANAGEMENT SYSTEM FOR AU

judge the operation of a system, rather than specific behaviors. This should be contrasted
with functional requirements that define specific behavior or functions. In this system
user interface is designed user-friendly so that every user should feel comfort to use it
The architecture of this system presents better performance and quality outputs reports
and information dissemination framework in terms of: -
Performance
This system proposed to maintain the following nonfunctional standards towards: -
 Timelines
 Accuracy.
 24 hours within 7 days model availability.
 Authorization restriction and privileges.
 Security and usability of information.
 Testability, maintainability, and scalability.

2.7 Hardware and Software Requirement

2.7.1 Hard ware requirements

In this project the following development hardware tools will be used: -
Table 2 Hard ware Requirements

Item Unit Quantity

Laptop Number 2

Server Number -

SanDisk Flesh Number 1

Pen and paper Number -

15
FLEET MANAGEMENT SYSTEM FOR AU

2.7.2 Software requirements

In this project the following development software tools will be used: -
Table 3 Software Requirements

Applications Software Tools

Client Side Scripting HTML, CSS, JavaScript

Any Operating System MS Windows

Database Server MySQL

Web server Apache

Server-Side scripting PHP

Browsers MS Edge, Chrome,

Editors Sublime editor visual code editor

User Interface Design HTML, bootstrap

2.8. Cost Budgeting

 Hardware cost

Table 4 Hardware Cost

Item Unit Quantity Unit Price Total Price

Laptop Number 2 30,000.00 60,000.00

SanDisk Flesh Number 1 450 450.00

Pen and paper Number - - 200.00

Total Cost 60,650.00

16
FLEET MANAGEMENT SYSTEM FOR AU

 Software Cost

Table 5 Software Cost

Item Price (ETB)

Windows 10 Pro Free
Microsoft Office 2021 Free
MySQL database server Free
Notepad++ Free
Apache Free

HTML -
PHP -
Total Cost -

17
FLEET MANAGEMENT SYSTEM FOR AU

CHAPTER THREE

3. SYSTEM ANALYSIS
3.1 Introduction

The project development team used an object-oriented system development

methodology. Because the Object system development approach gives easier and
natural way to break down problems into simple, small, and manageable components
so that it reduces the unclear appearance of the big problem. Moreover, it is
predominately used and popular method in present software development trend.

3.2. System requirement specification (SRS)

The SRS for the FMSU is database for storing data, Employees of AU to use the system, admins
for controlling the system and university to implement and use the system. And there are
functional and non-functional requirements required to use the system.

3.3. Production function

The system should enable:

The admin to

 Create or Delete account for all the users

 Monitor the number of users
 Update Users information

The General Service Manager to

 View request maintenance

 Generate report
 Prepare vehicle schedule
 View exit request
 Update Vehicle record
 Approve exit request
 Calculate fuel balance

18
FLEET MANAGEMENT SYSTEM FOR AU

The scheduler to

 View scheduled Vehicle

 Prepare vehicle schedule
 Fill Fuel Cost

The Driver

 View scheduled vehicle

 Request for exit
 Request maintenance record

3.4. User characteristics

User to system: For all users to use the FMSAU, they must first login with the account
that is given by the admin after that they can perform several tasks as permitted their
privilege.

System to User: The system will verify if the login of the user is correct then provides
necessary access to the all actors in the system.

3.5. General constraints

Constraints on the FMSU are restriction on the accessibility and usage freedom of the
system like constraints on requirements resources, knowledge, and experience. And as a
general level, those

Constraints will be

 Control and regulation

 Safety and security authorization and protection
 The requirements consistency
 Accessibility and language requirement
 Technology and system advancement

19
FLEET MANAGEMENT SYSTEM FOR AU

3.5.1. Communication interface

Since the FMSAU is an online and web-based application, it will use the HTTP protocol
for communication over the internet and TCP/IP protocol for the intranet communication.

3.6. Use cases

In software and system engineering, a use case is defined as a list of steps, typically
defining interaction between a role (known in UML as an “actor”) and a system, to
achieve a goal. The actor can be a human or an external system. In system engineering,
use cases are used at a higher level than within software engineering, often representing
missions or stakeholder goals [5].

3.6.1. Actors in the system

The actors in the systems are: -

System Admin: is managing the system and managing user account.

Vehicle scheduler: Receive number of available vehicles from GSM which is ready for
transportation and scheduling vehicles and give dispatch for the vehicles
General Service manager: a person who accesses the information of all vehicles and
managing them.
Driver: the driver informs information about the damaged vehicle for the GSM.
After filling the form, the driver passes the form to GSM for confirmation.
Property manager: is responsible for managing properties like fuel

20
FLEET MANAGEMENT SYSTEM FOR AU

Figure 1 Use Case Diagram

3.6.2. Use case description

21
FLEET MANAGEMENT SYSTEM FOR AU

1. Use case description for Login

Table 6 Use case description for Login

Use case name Login

Use case number UC1

Actor(s) System administrator, General Service manager, Driver, Scheduler,

property worker.
Description The authentication for authorized users in the system and deliver them the
right to visit their specified windows.
Basic course of Actor’s action systems response
action Step 1: Actors initiate to login Step 2: The system displays the
Step 3: User enter user name and login page.
password and click login button. Step 4: The system checks the
validity of the entry and then verifies
whether the user is authenticated and
authorized.
Step 5: If the user is authenticated
& authorized for the tasks the
system displays the main page for
further action.

Alternate courses of Step 4: If user enter invalid user name and Password then the system
action displays error message and return to step 2.
Pre-condition Firstly, the user should be registered.
Post condition User able to access the required main page.

22
FLEET MANAGEMENT SYSTEM FOR AU

2. Use case description for Calculating fuel balance

Table 5 Use case description for Calculating fuel balance

Use case name Calculating fuel balance

Use case number UC2

Actor(s) General Service manager

Description The fuel balance form takes and compares two reading of current entry
and the previous saved reading and produces fuel balance data.
Basic course of Actor Action System Response
action Step1: GSM manager visit fuel Step2: System display the page
balance page Step4: System checks the
Step3: enter the data to be calculated validity the entered data
and click calculate button Step5: The system saves the
computed data and store the
status of fuel.

Alternative courses Step 4: if the input is invalid or incorrect the system displays “invalid
of action input” message and return to step3.
Pre-condition GSM must get information of vehicles status
Post condition The fuel balance will be calculated

23
FLEET MANAGEMENT SYSTEM FOR AU

3. Use case description for Request maintenance record

Table 6 Use case description for Request maintenance record

Use case name Request maintenance record

Use case number UC3

Actor(s) Driver

Description A driver formulate request to repair vehicle. The request describes briefly the
vehicle problem

Basic course of Actor Action System Response

action Step1: Driver initiate maintenance Step2: System display vehicle
form page maintenance page.
Step3: Driver enter information Step 4: System checks validity of
related to the maintenance request for the information
the vehicle and click submit button Step 5: System store the data in the
database

Alternate courses of Step 4: if the data is invalid or incorrect the system displays “invalid input”
action message and return to step 3.
Pre-condition vehicle & Driver must be registered
Post condition Request maintenance record will be accomplished.

24
FLEET MANAGEMENT SYSTEM FOR AU

4. Use case description for prepare vehicle schedule

Table 7 Use case description for prepare vehicle schedule

Use case name Prepare Vehicle schedule

Use case number UC5

Actor(s) Scheduler

Description This use case describing the process of scheduling vehicles.

Basic course of Actor Action System Response

action Step1: scheduler initiates the Step2: System display vehicle schedule
schedule page. page.
Step3: scheduler view the vehicles Step4: System display schedule form
to be schedule and decide to schedule Step6: System checks validate of vehicle
Step5: scheduler fill the form and information
click submit Step 7 : System schedule the vehicles

Alternative courses Step 6: if the input is not validated and verified, the system displays “invalid
of action input” message and go to step5
Pre-condition Scheduler must be registered
Post condition Vehicles will be scheduled

25
FLEET MANAGEMENT SYSTEM FOR AU

5. Use case description for Vehicle registration

Table 8 Use case description for Vehicle registration

Use case name Vehicle registration

Use case number UC7

Actor(s) GSM

Description This use case describes to register the status of detail information of the
vehicle.
Basic course of Actor Action System Response
action Step1: GSM initiate vehicle Step2: System display vehicle
registration page registration page.
Step3: Manager fill all the necessary Step4: System checks the
information about the vehicle validity of the information
Step5: System registered the
vehicle

Alternative courses Step 4: If the required input is not valid the system displays error
of action message and go to step3
Pre-condition GSM should be authorized
Post condition Vehicles will be registered.

26
FLEET MANAGEMENT SYSTEM FOR AU

6. Use case description for update vehicle record

Table 9 Use case description for update vehicle record

Use case name Update vehicle record

Use case number UC8

Actor(s) GSM

Description GSM modify vehicle information when it is necessary

Basic course of Actor Action System Response

action Step1: GSM initiate update vehicle Step2: System display update
page vehicle page.
Step3: GSM click edit button Step4: System displays the
Step5: GSM updates the vehicle vehicle record to be updated
field Step6: System validates
information
Step7: System updates the
vehicle record.

Alternate courses of Step 6: if the input is not validated and verified, the system displays
action “invalid input” message and go to step5
Pre-condition GSM should be authorized
Post condition Vehicle record will be updated

27
FLEET MANAGEMENT SYSTEM FOR AU

7. Use case description for generate report

Table 10 Use case description for generate report

Use case name Generate report

Use case UC9
number
Actor(s) GSM and Admin

Description This process is initialized GSM and scheduler want to generate report
about the tasks performed on the system.
Basic course of Actor Action System Response
action Step1: GSM/Admin initiate Step2: System displays generate
generate report page report page.
Step3: GSM/ Admin fill the report Step4: System display reports.
forms and click submit button

Pre-condition GSM/Admin should be registered

Post condition Reports will be viewed

28
FLEET MANAGEMENT SYSTEM FOR AU

8. Use case description for create user account

Table 11 Use case description for create user account

Use case name Create user account

Use case number UC10

Actor System administrator

Description This activity is performed when the administrator wants to create a new
user.
Basic course of action Actor action System response

Step1: System administrator initiate Step2: System displays create

create user account page. account page.
Step3: System administrator enter user Step4: system validate the
information and click submit entered information
Step5:System creates user
account
Alternative course of Step4: if the information is not valid , system display error message and
action go to step3

Pre-condition System administrator should be authorized

Post condition New user account will be created.

29
FLEET MANAGEMENT SYSTEM FOR AU

9. Use case description for delete user account

Table 12 Use case description for delete user account

Use case name Delete user account

Use case number UC11
Actor System administrator
Description This use case describes when administrator want to delete an
existing account
Basic course of action Actor action System response
Step1: System administrator Step2: System display delete
select delete user account page user account page.
Step3:System administrator click Step4: System checks the user
delete button account
Step5: System deletes the
account
Alternative course of Step4: If not go to step2
action

Pre-condition System administrator must be authorized

Post condition A user‟s account will be deleted

30
FLEET MANAGEMENT SYSTEM FOR AU

10. Use case description for View exit request

Table 13 Use case description for View exit request

Use case name View exit request

Use case number UC13

Actor(s) GSM

Description This use case describes viewing of drivers exit request

Basic course of Actor Action System Response

action Step1: GSM click view exit Step2: System display view exit
request page request page.
Step4.System displays the
request information to exit

Pre-condition User should be registered

Post condition Exit request will be viewed

31
FLEET MANAGEMENT SYSTEM FOR AU

11. Use case description for notify exit permission

Table 14 Use case description for notify exit permission

Use case name notify exit permission

Use case number UC14

Actor(s) GSM

Description This use case describes notification of exit permission

Basic course of Actor Action System Response

action Step1: the GSM click view exit Step2: System display view exit
request page request page
Step 4: The manager views the Step:3 system displays the
exit request information and request information to exit
decide to permit Step5: system display
Step6: The manager fills the permission page
form and click submit button Step7: System check the
validate the entered information
Step8: System save the data on
database
Alternative course Step7: if the information is not valid, system display error message
of action and go to step6
Pre-condition The manager should be authorized
Post condition Exit permission will be viewed

32
FLEET MANAGEMENT SYSTEM FOR AU

12. Use case description for Request for exit permission

Table 15 Use case description for Request for exit

Use case name Request for exit permission

Use case number UC15

Actor(s) Driver
Description This use case describes asking of getting permission to exit from the
campus.
Basic course of Actor Action System Response
action Step1: driver initiate exit Step2: System display request of
request page exit page.
Step3: The driver fills the form Step4: System check the
to exit and click submit button validate of entered information
Step5: System send the request
Alternative course Step4: if the information is not valid, system display error message
of action and go to step3
Pre-condition Driver should be registered
Post condition Request will be sent

33
FLEET MANAGEMENT SYSTEM FOR AU

17 Use case description for update user account

Table 16 Use case description for update user account

Use case name Update user account

Use case number UC17

Actor(s) System admin

Description This use case describes updating of user account

Basic course of Actor Action System Response

action Step1: System admin click update Step2: System display update
user account page user account page.
Step3: System admin click edit Step4: System displays
button information about user
Step4: System admin enter account.
information related to the record to Step5: System validates
be updated information
Step6: System updates user
account
Step 5: If the required input is not valid the system displays error
message and go to step4
Pre-condition System admin should be authorized
Post condition Updated account will be viewed

34
FLEET MANAGEMENT SYSTEM FOR AU

3.7. Object diagram

Classes describe the behavior of objects which are real-world entities. We can't define an
object without knowing what class it belongs to. The class diagram represents the overall
top or bird‟s eye view of the developed system. It doesn‟t go deep and give all detail; it
gives the abstract view of the system. An object diagram illustrates a class's instance. It
depicts the system's specific capability [6].

35
FLEET MANAGEMENT SYSTEM FOR AU

3.8. Class diagram

Class diagrams are used to describe the structure of the system. Classes are abstractions
that specify the common structure and behavior of a set of objects in the new system.

36
FLEET MANAGEMENT SYSTEM FOR AU

Figure 2 Class diagram

37
FLEET MANAGEMENT SYSTEM FOR AU

3.8.1. Class Responsibility Collaborator (CRC) Cards

A collection of CRC cards that model all or part of a system. A CRC card is a standard
index card that has been divided into three sections, one indicating the name of the class
the card represents, one listing the responsibilities of the class, and the third listing the
names of the other classes that this one collaborates with to fulfill its responsibilities.

Class responsibility collaboration (CRC)

Table 17 Class responsibility collaboration (CRC)

Class name
Responsibility Collaborator

Vehicle registration Vehicle schedule

-plate number GSM -Driver name Schedule

-Vehicle type -Driver_id
-Model -Driver phone number
-Chassis number -Vehicle type
-Engine number -Engine number
-Owner Place of start
-Condition -Place of arrival
-Capacity -Date
-Fuel tank -Entrance Time
- Production date -Outgoing Time
-Engine power +Prepare schedule ()
+View schedule()

+View vehicle
info()
+Register vehicle ()

38
FLEET MANAGEMENT SYSTEM FOR AU

Request maintenance Calculate fuel balance

-Date GSM
-Driver_id Driver -Traveled km
-Date -price/liter
-vehicle type -Given fuel by Liter
-Engine number
-plate number
-Problem of vehicle
+Calculate total fuel
+Maintenance
consumption ()
request record()
+Register vehicle
+View maintenance
traveled KMs ()
request()
+Delete ()
+Delete()

Administrator
User account
-First name Administrator
-First name Administrator -Last name
-Last name Driver -Username
-User name GSM -Password
-Password Scheduler
Property Worker

+Get user name() +Create account()

+Get password() +Delete account()
+View reserved +Update
vehicle() account()

39
FLEET MANAGEMENT SYSTEM FOR AU

3.9. Sequence diagram

A sequence diagram in a unified modeling language (UML) is a kind of interaction

diagram that shows how processes operate with one another and in what order. It is a
construct of a Message Sequence Chart. A sequence diagram shows object interactions
arranged in time sequence. It depicts the objects and classes involved in the scenario and
the sequence of messages exchanged between the objects needed to carry out the
functionality of the scenario. Sequence diagrams typically are associated with use case
realizations in the Logical View of the system under development [7].

40
FLEET MANAGEMENT SYSTEM FOR AU

1 Sequence diagram for Login

Login Validation Account Main page

Actor <<UI>> <<controller>> <<DB>> <<UI>>

Click

enter check validty

username &
password invalid
(username&
password)
valid

Display

Figure 3 Sequence diagram for Login

41
FLEET MANAGEMENT SYSTEM FOR AU

4. Sequence diagram for Prepare schedule

Vehicle
Main page schedule Validation Database
Scheduler <<UI>> <<controller>>

click

fill data
click submit

Save
Invalid(data)

Success fully
scheduled

Figure 4 Sequence diagram for Prepare schedule

42
FLEET MANAGEMENT SYSTEM FOR AU

5. Sequence diagram for vehicle registration

Vehicle
Validation
Main page registration Database
Manager <<Controller>>
<<UI>>

fill
click
appropriate
data
click submit

Register
Invalid(data)

Succes sfully
registe red

Figure 5 Sequence diagram for vehicle registration

43
FLEET MANAGEMENT SYSTEM FOR AU

3.10. Activity diagram

The purpose of the activity diagram is to model the procedural flow of actions that are
part of a larger activity. In projects in which use cases are present, activity diagrams can
model a specific use case at a more detailed level.

44
FLEET MANAGEMENT SYSTEM FOR AU

1 Activity diagram for Balance sheet

Enter user name &

password

Incorrect user name

& password
Error message
Correct

Display calculating
fuel balance page

Enter inputs

Incorrect input
Invalid inputs

Correct input

Calculate &store
vehicle travelled KMs

Figure 6 Activity diagram for Balance sheet

45
FLEET MANAGEMENT SYSTEM FOR AU

2 Activity diagram for vehicle registration

Enter user name &

password

Incorrect
Error message
Correct

Display vehicle
registration page

Fill the neccessary data

Incorrect
Incorrect input

Correct

Register vehicles

Figure 7 Activity diagram for vehicle registration

46
FLEET MANAGEMENT SYSTEM FOR AU

3 Activity diagram for Update vehicle

Enter user name &

password

Incorrect
Error message
Correct
Display update
vehicle information
page

Enter information related to

the record to be updated

Invalid
Error message

valid

Update the vehicle

record

Figure 8 Activity diagram for Update vehicle

47
FLEET MANAGEMENT SYSTEM FOR AU

4 Activity diagram for Generate report

Enter user name &

password

Incorrect
Error message
Correct

Click on generate
report botton

Display generate report page

System display report

Figure 9 Activity diagram for Generate report

48
FLEET MANAGEMENT SYSTEM FOR AU

5 Activity diagram for view reserved vehicle

Enter user name &

password

Incorrect
Error message

Correct

Display reserved
vehicle page

Enter input

Incorrect
Invalid input

Correct

View reserved vehicle

Figure 10 Activity diagram for view reserved vehicle

49
FLEET MANAGEMENT SYSTEM FOR AU

3.11. State Chart Diagram

State chart diagram describes the flow of control from one state to another state. States
are defined as a condition in which an object exists and it changes when some event is
triggered.

State chart diagrams are also used for forward and reverse engineering of a system. But
the main purpose is to model reactive system.

50
FLEET MANAGEMENT SYSTEM FOR AU

1 State Chart Diagram for Login

Figure 11 State chart diagram for login

51
FLEET MANAGEMENT SYSTEM FOR AU

2 State Chart Diagram for Adding User Account

Figure 12 State chart diagram for admin for adding user account

52
FLEET MANAGEMENT SYSTEM FOR AU

3 State Chart Diagram for scheduling

Figure 13 State-chart diagram for scheduling

53
FLEET MANAGEMENT SYSTEM FOR AU

3.12. Analysis Model

Analysis model is a technical representation of system. We use Analysis model to define

the models, functions, requirements needed by the system when it is in the process design
modeling.

Objective of analysis model is to establish a way of creating software design, to describe

the requirements of the customer, to define a set of requirements that can be validated
after the development of the software.

54
FLEET MANAGEMENT SYSTEM FOR AU

3.12.1. Sequence Diagram

Main page Generate report Validation

<<UI>> <<Controller>> Database
Manager&Admin

click
fill date
click search

Generate
Invalid(data)

Succes sfully
generated

Figure 14 Sequence diagram for generate report

55
FLEET MANAGEMENT SYSTEM FOR AU

3.12.2. Activity Diagram

Enter user name &

password

Incorrect
Error message

Correct

Display admin page

Select new user account

page

Enter user
information

Incorrect
Incorrect information

Correct

System create user

account

Dispaly successful
message

Figure 15 Activity diagram for Administrator create user account

56
FLEET MANAGEMENT SYSTEM FOR AU

CHAPTER FOUR

4. System design
4.1. Introduction

4.1.1. Purpose of the system

This system design document is developed for the purpose of describing the system
design activities carried out during the design phase for fleet management system of AU.

Simply the purpose of system design is to describe

 The primary design goals for the project

 Subsystem decomposition, Hardware/ software mapping
 Persistence modeling for object-oriented database and the access control

Finally, it also describes object design model and database design

4.1.2. Design goals

The objective of design is to model a system within a qualified way. Implementing of
high-quality system depends on the nature of the design created by the designer. If one
wants to make changes to the system after it has been put into operation is dependent on
the quality of the system design. So, if the system is designed perfectly, it will be easy to
make changes to it [8].

The goal of the system design is to manage complexity by decomposing the system into
manageable pieces.

Some of the goals are listed below.

 Maintainability: The system should be extensible enough to incorporate

additional functionalities such as identifying the exact position of vehicles using

57
FLEET MANAGEMENT SYSTEM FOR AU

GPS technology without affecting the general framework of the system. It should
be also easily modifiable.
 Performance: The system should be able to give response (error message) when
the user enters incorrect input. This recommends the user to enter correct input.
 Dependability: The system should be available for twenty four (24) hours of a
day so that the users can have access to it at any time. The system should also be
designed to prompt the user with password and user name. This provides security
in such a way that unauthorized users can not have access to the system‟s
resources. Moreover, the system should be designed to reject invalid user inputs
to ensure the system‟s robustness for all interacting users.
 End user: The system should provide user friendly and self-explanatory
graphical user interface that eases the interaction of the user with the system. In
addition the system should be flexible, efficient, and reliable.

4.2. Current software architecture

Currently ambo university transport service uses a manual process work. So that the
manual system does not have any software architecture.

4.3. Proposed software architecture

The existing system of the Ambo university vehicle management system is

manual system and hence there is no current software architecture that will be
considered. As a result, we only describe the software architecture of the
newly proposed system.

The proposed system is expected to replace the existing system by an automated system.
It is mainly based on the system Analysis part of this system document. The architecture
used for the system is a three (3) tier Client/Server Architecture where a client can use
Internet browsers to access the online report provided by the system using the Internet or
LAN. Figure 24 indicates the three tier architectures consist of three components

58
FLEET MANAGEMENT SYSTEM FOR AU

distributed in 3 layers: client (requester of services) the business logic (data handler) and
server (provider of services).
These are:-
User System Interface (such as text input, dialog, and display management
services)
Processing Management (such as process development, process enactment,
process monitoring, and process resource services)
Database Management (such as data and file services)
Why we choose 3-tier architecture is?
 The system works on homogeneous environments with processing rules
(business rules) that do not change very often.
 Separation of business logic from application logic minimizes the work load
of server and enhances the security of data

Figure 16 Proposed software architecture

4.3.1. Subsystem Decomposition
Subsystem‟s decomposition is a general approach to solve a problem by breaking it up
into smaller ones and solving each of the smaller ones separately, either in parallel or
sequentially. Subsystem decompositions will help reduce the complexity of the system.
The subsystems can be considered as packages holding related classes or objects. The
fleet management system is decomposed into the following subsystems.

59
FLEET MANAGEMENT SYSTEM FOR AU

 System administrator subsystem: This subsystem concerns on the activities

of creating, updating, and deleting user accounts. In additional it enables the
administrator to view the scheduled vehicles.
 General Service manager subsystem: this subsystem focuses on the
operations of register vehicles, update vehicle information, Add Cupon No,
view maintenance request, calculate fuel balance and generate report.
 Scheduler subsystem: The scheduler subsystem provides the way to prepare
vehicle schedule, view scheduled vehicle, Fill Fuel cost
 Driver subsystem: The driver subsystem enables the driver to view
schedule, to request exit permission, to send maintenance request to the
concern body.
 Property workers: the property worker sub system enable fill the coupon
for the drivers.
1. Subsystem decomposition

60
FLEET MANAGEMENT SYSTEM FOR AU

Figure 17 subsystem decomposition

Component diagram

Component diagram are used to provide physical view of current model. The purpose of
component diagram is to visualize the components of a system and relationships of the
components.

61
FLEET MANAGEMENT SYSTEM FOR AU

Figure 18 component diagram

4.3.2. Hardware/ Software Mapping
Hardware/Software Mapping are used to visualize the topology of the physical
components of a system where the software components are deployed. So the mapping is
used to describe the static deployment view of a system. It shows a static view of the
run-time configuration of processing nodes and the components that run on those nodes.
In other words, hardware/software mapping shows the hardware for our system, the
software installed on that hardware, and the middleware used to connect the disparate
machines to one another. As it is described in the very beginning of this document, the

62
FLEET MANAGEMENT SYSTEM FOR AU

hardware configuration of the system will be using a client machine and a server
machine. For the effective communication between these nodes, we use a LAN under
TCP/IP (internet) infrastructure.

To describe the hardware/ software mapping of our system we use the diagram below

Figure 19 Deployment diagram

4.3.3. Persistence modeling for object-oriented database
Persistence refers to the characteristic of state that outlives the process that created it.
This is achieved in practice by storing the state as data in computer data storage.
Programs have to transfer data to and from storage devices and have to provide mappings
from the native programming-language data structures to the storage device data

63
FLEET MANAGEMENT SYSTEM FOR AU

structures. Persistent information management deals with how the persistent data (file,
database, etc) are stored and managed. Information related to Fleet management system
basic information, vehicle registration system, scheduling vehicles and management
account produced and other related information are persistent data and hence stored on a
database management system

Administrator
Request maintenance -User_id:varchar
Request maintenance
<<Table>> -First_name:varchar
-Last_name:varchar
-Driver_id:int -Driver_id:int -User_name:varchar
-Date:varchar -Date:varchar -Password:varchar
-vehicle type:varchar -vehicle type:varchar
-Engine_no:int -Engine_no:int
-plate_no:varchar -plate_no:varchar(Fk)
-Problem of vehicle:varchar -Problem of vehicle:varchar
-Mechanic_name:string -Mechanic_name:string

Vehicle registration
Vehicle registration Administrator
<<Table>>
<<Table>>
-plate_no:varchar -plate_no:varchar(pk) -User_id:varchar(pk)
-Vehicle_type:varchar -Vehicle_type:varchar -First_name:varchar
-Model:varchar -Model:varchar -Last_name:varchar
-Chassis_no:varchar -Chassis_no:varchar -User_name:varchar
-Engine_no:varchar -Engine_no:varchar -Password:varchar
-Owner:string -Owner:string
-Condition:string -Condition:string
-Capacity:varchar -Capacity:varchar
-Production_date:varchar -Production_date:varchar
-Engine_power:bigint -Engine_power:bigint User account

-User_id:varchar
-First_name:varchar
-Last_name:varchar
Vehicle schedule
Vehicle schedule -User_name:varchar
<<Table>>
-Driver_name:string -Password:varchar
-Driver_id:int -Driver_name:string
-Driver_phoneNo:int -Driver_id:int
-Vehicle_type:varchar -Driver_phoneNo:int
-Plate_No:varchar -Vehicle_type:varchar
-Place of start:string -Plate_No:varchar(Fk)
-Place of arrival:string -Place of start:string
-Date:int -Place of arrival:string
-Enterance_Time:int -Date:int
-Outgoing_Time:int -Enterance_Time:int
-Outgoing_Time:int
User account
<<Table>>

Calculate fuel balance -User_id:varchar(pk)

Calculate fuel balance -First_name:varchar
<<Table>>
-Last_name:varchar
-Date:varchar -Date:varchar -User_name:varchar
-Traveled km:float -Traveled km:float -Password:varchar
-price/liter:float -price/liter:float
-Given fuel by L:float -Given fuel by L:float

64
FLEET MANAGEMENT SYSTEM FOR AU

Figure 20 Persistence modeling for object-oriented database

4.3.4. Access control and security

In our proposed systems, all actors have their own accessibility to different
functionalities. The following table explains the accessibility of Actors to perform
particular act ionize

Class Account vehicle Request calculate view Schedule

actor
System Create account() View report()
admin Update View schedule()
account()
Delete account()
GSM Register Calculate View report()
vehicle() fuel() View schedule()
Update vehicle() View request()
Delete vehicle() View message()
Scheduler View schedule() Schedule
View message() vehicle()
Driver Maintenance View message()
request()
Exist request()

4.3.5. Global Software Control

The fleet Management System architecture have an explicit, centralized software control.
The system's dynamic control is distributed among different controllers such that each
object delegates some responsibility to other objects. The request initiations are event-
driven:

 The admin initiates the UI Subsystem by logging into the system.

65
FLEET MANAGEMENT SYSTEM FOR AU

 The Main Subsystem is initiated when a request is delivered

 The Main Subsystem initiates the employee subsystem by checking the
availability and notifying of the Response.
 The Database Subsystem can be initiated at any point by all Subsystems except
the UI Subsystem. Any request (add/update/delete/retrieve) to the repository
initiates the Database Subsystem. The system stores its contents in the database
between executions. When the application is run again, it retrieves the contents
from the previous execution. Any change in the contents during this execution
updates the database.

4.3.6. Boundary Conditions

The administrator initiates the web server using the appropriate administrator username
and password that enables to register, update, and delete employees, and generate reports.
Manger performs different activities like register, update, and delete vehicle information,
calculate fuel balance and generate report.

Scheduler performs Fill Fuel Cost, schedule vehicle, and generate report.

Driver performs request for maintenance, request for exit permission and view schedule.

The System is Client–Server architecture and allows a remote access. The following
requirements are mandatory on both Client and Server side.
Client slide

 Internet connection should be available on the client side

 Web browser is demanding to connect with the web server of the system
 The user should be legitimate and having an account provided by the
system
 It should give the URL (Uniform Resource Locator) address of the web
site.
 The user communicates the different hyperlinks/pages using the
homepage.

66
FLEET MANAGEMENT SYSTEM FOR AU

Server Side

 The system administrator/Web Master initiates and updates the system

using his/her preferred privileges
 The server side should be registered on the local or any other service
provider.
 It should have Internet connection and database driven-website for remote
access.
It automatically saves the changes and take backups

67
FLEET MANAGEMENT SYSTEM FOR AU

CHAPTER FIVE

5. TESTING AND IIMPLIMENTATION

5.1. Testing

Final phase of implementation is testing. Software testing is the process of analyzing a

software item to detect the differences between existing and required conditions (that is,
bugs) and to evaluate the features of the software item. Software testing is an activity that
should be done throughout the whole development process.
Testing is a process to show the correctness of the program. Testing is checking of the
system workability in an attempt to discover errors and avoiding such errors from the
system. In this the team members tested the entire system as a whole with all forms, code,
modules. In this we tested all the functionalities in the System. All errors in the forms,
functions, modules have been tested. The following are different testing strategies.
Unit Testing

Unit testing is every module of the System is separately tested. It is often done by the
programmer to test that the unit he/she has implemented is producing expected output
against given input.
System Testing

It is the final step of testing. In this the team members tests the entire system as a whole
with all forms, code, modules. This form of testing is popularly known as Black Box
testing or System tests. In this the team members tests all the functionalities in the
System. All errors in the forms, functions, modules are tested. Integration Testing:
Integration testing

The process of testing the interaction between different modules or components of a

software application. It aims to identify any defects or issues that may arise when

68
FLEET MANAGEMENT SYSTEM FOR AU

Functional Testing

Functional testing focuses on validating the software application's features, functions,

and capabilities, ensuring that they work as specified in the requirements. This type of
testing verifies that the software operates according to the expected user behavior. Rent
units of code are combined and integrated into a single system Performance Testing:

Performance testing

The process of testing the software application's performance, such as its responsiveness,
speed, and stability, under various load conditions. The purpose is to ensure that the
software meets the performance and reliability requirements when subjected to different
levels of user traffic and system load.

5.1.1 Hardware Software Acquisition

In order to implement and use the entire system, different hardware and software are
required as it was described in „Hardware and Software requirement‟ in Chapter one. Any
user who are intended to use this system must have the following hardware and software
to implement and use the complete system.

Software

 XAMPP(X-os, Apache, MySQL, PHP server and Perl).

 Internet Browser ( i.e. Google chrome).
 OS (i.e windows).

Hardware

 Server Computer
 Hard disk with enough storage and flash disk.
 Switch and internet cable or wireless network.

69
FLEET MANAGEMENT SYSTEM FOR AU

5.1.2. User Manual Preparation

User manual is used to show each procedure of the system for the simplicity of
performing the operation of the system easily. The user manual describes as the
followings:
To Open Homepage
Step 1: open browser and browse System URL. Locallhost/FleetManagement
USER INTERFACE FOR HOMEPAGE

70
FLEET MANAGEMENT SYSTEM FOR AU

Tologin
Step 1: Browse the system URL.
Locallhost/FleetManagement

Step2: select login menu

Step 3: fill the form User Name and Password then press login button

71
FLEET MANAGEMENT SYSTEM FOR AU

Step 6: access successfully

5.2. Training

Training is the process of teaching or learning a skill or job. Training is needed for two
reasons:

72
FLEET MANAGEMENT SYSTEM FOR AU

 If users are not adequately trained they will not operate with the system
correctly or efficiently.
 If users fill the task they are being asked to perform are outside their
capabilities, they may become demoralized and separated. User training
must be provide to user of the system in order to help make them to
equate with the system. Users are vital part of any system

5.3. Installation

Process After all hardware and software requirements has been fulfilled, you can install
simply by following steps:

Step1: Install XAMPP (X-os, Apache Sever, MySQL, PHP and Perl) on computer.

Step2: Get the folder “fleet management “which contains files and source code of the
system from the Developers Team.

Step 2: Past the folder in the C:\Xampp\htdocs.

Step3: Run XAMPP control panel and start all services.

Step4: Installation is finished

5.4. Startup Strategies

Startup means the process to make the new system begin to operate. It is the process of
how to start the system and has the following steps:

1. Activate XAMPP server from the Desktop or Start up Menu if it‟s not activated by
clicking on XAMPP control panel then Start the Apache and MYSQL.

73
FLEET MANAGEMENT SYSTEM FOR AU

2. Start Apache and MySQL services by clicking start button on XAMPP control panel

74
FLEET MANAGEMENT SYSTEM FOR AU

3. You Can Interact with the system as follows

75
FLEET MANAGEMENT SYSTEM FOR AU

CHAPTER SIX

6. CONCLUSION AND RECOMMANDATION

6.1. Conclusion

In this Chapter we summarize the result of the study that has been found in the analysis.
Based on the result rational suggestions and recommendations have been forwarded. The
project is partitioned into two phases and each phase has a specific deliverable which is
essential and base for the next phase.
The first phase is the Introduction in this part the major works are: describing about
background where the new system is intended to be built on, the problems in the system
have been identified, the feasibility part studies building a new system is possible or not
from different perspectives, after the scope of the proposed system has been defined the
selected programming tools , methods are stated ,analyzing Current system and prior
related work with their strengthen and weakens of related work, over view of proposed
system with their Functional Requirements, Non Functional Requirements, Object
Oriented System Modeling With Use case diagram and dynamic diagram and the
project‟s phases with their respective deliverables are stated.

The second phase is conducted based on the first phase. In this phase we design the actual
implementation of the system by using detailed class diagram, proposed architecture,
component diagram, deployment diagram and persistent data modeling. After designing
the next stage is implementation. In the implementation stage we change the above
design into coding to make good interactive interface and store the data into the database.
After we have written the actual code, we tested all controls and subsystems of the
system by using different testing mechanisms. Such as unit testing, and system testing. by
following the above steps, we have developed the system. This developed system has
solved the problems that we have stated in the statement of problems.

76
FLEET MANAGEMENT SYSTEM FOR AU

6.2. Recommendation

The system that we are trying to develop is not a fully executed system. Because we were
new to the system, we missed out some parts which should be included in the system.
This is mainly due to limited development capacity, shortage of resource and shortage of
time. Therefore, we suggest the following features need to be incorporated in any further
revision to be real system
 Detecting the exact location of vehicles using ground positioning system (GPS)
technology.
 The system we developed doesn‟t connect with internet; we recommend that
someone who improves this project should have to connect to the internet that
means the system we have developed is not an online system it is a web based.
 The systems have to be mobile based to be advanced system

77
FLEET MANAGEMENT SYSTEM FOR AU

Reference

[1] S. Shuban, "Technogroups," 05 March 2020. [Online]. Available:

https://technosoups.com/introduction-to-fleet-management-and-fleet-maintenance/.
[Accessed 14 January 2023].

[2] Archsion999, "GeegsforGeegs," 02 March 2022. [Online]. Available:

https://www.geeksforgeeks.org/benefits-advantages-of-oop/. [Accessed 14 January 2023].

[3] M. Mintesnot, Interviewee, Existing Fleet MGMT system. [Interview]. 2 February 2023.

[4] G. S. Manager, Interviewee, Existing fleet managemant in AU. [Interview]. 6 February 2023.

[5] k. brush, "TechTarget Network," 23 januray 2022. [Online]. Available:

https://www.techtarget.com/searchsoftwarequality/definition/use-case. [Accessed 14 may
2023].

[6] I. D. m. architect, "IBM," 23 may 2020. [Online]. Available:

https://www.ibm.com/docs/en/dma. [Accessed 23 feb 2023].

[7] microsoft, "microsoft 365 suport," 10 july 2007. [Online]. Available:

https://support.microsoft.com/en-us/office/create-a-uml-sequence-diagram-c61c371b-
b150-4958-b128-902000133b26. [Accessed 3 april 2023].

[8] j. spacey, "simplicable," 3 december 2018. [Online]. Available:

https://simplicable.com/design/design-goals. [Accessed 27 may 2023].

78
FLEET MANAGEMENT SYSTEM FOR AU

Appendix
Appendix one

Exit requisition form

79
FLEET MANAGEMENT SYSTEM FOR AU

Appendix two

Report

80