UNITY UNIVERSITY

College of Engineering and Technology and Computational Science

Department of Computer Science and MIS

Project Title: Bus Tracker Android Application

Final Project Documentation

Submitted to department of computer science and MIS in partial fulfillment

of the requirement for the degree of bachelor science in computer science

Prepared By Id number

1. Aboma Djima UU88771R

2. Adonias Atsbaha UU87714R

3. Bezawit Alemayehu UU87504R

4. Bezawit Tsebelu UU87743R

5. Fikir Kindu UU87943R

Submission Date: 15th July, 2024

Advisor: Ato. Getahun Gezu
AddisAbaba,Ethiopia
1
 Abstract

In today's urban environments, efficient public transportation systems are essential for managing traffic
congestion and improving commuter experiences. The Bus Tracker Android App aims to enhance the
accessibility and reliability of public bus services by providing real-time tracking and information to
users.

The app leverages GPS technology to track the location of buses in real time, allowing users to view
bus routes, estimated arrival times, and current locations on an interactive map. Users can easily plan
their journeys, track bus arrivals, and receive notifications for service updates.

Key features include user-friendly interface design, integration with Firebase for real-time data updates,
and secure user authentication for personalized experiences. The app not only benefits commuters by
reducing waiting times and improving travel planning but also provides valuable analytics to
transportation authorities for optimizing bus routes and schedules.

The Bus Tracker Android App represents a significant advancement in urban mobility solutions,
promoting sustainable and efficient public transportation for city dwellers.

1
 Acknowledgement

We extend our heartfelt gratitude to all those who have contributed to the success of this group project.
Each member of our team has played a crucial role, and we would like to express our sincere
appreciation to everyone involved.

First and foremost, we are grateful to our project Advisor, Ato. Getahun Gezu, for their invaluable
guidance, support, and encouragement throughout the duration of this project.

We would like to thank our fellow team members, for their dedication, collaboration, and commitment
to excellence. Each member brought unique skills and perspectives, contributing to the project's success
and making it a rewarding collaborative effort.

We also acknowledge the support of our friends and family members who have stood by us with
patience and understanding, offering encouragement and motivation throughout this journey.

Lastly, Thank you all for your unwavering support, teamwork, and dedication to making this group
project a success.

1
1
List of Abbreviations
AACATA – Addis Ababa City Administration Transport Authority

Apps - Applications

AR – Augmented Reality

BCA – Basic course of Action

CD – Continuous Development

CSS – Cascading Style Sheet

ETA – Estimated Time of Arrival

ETB – Ethiopian Birr

GPS – Global Positioning System

HD – High Definition

HTML – Hypertext Markup Language

HTTPS – Hypertext Transfer Protocol Secure.

IDEs – Integrated Development Environments

LTE – Long-Term Evolution

Ms – Microsoft

OTP – One Time Password

RAM – Random Access Memory

RIS – Risk Information Sheet

RMMM – Risk Mitigation, Monitoring and Management

SSR – Server Side Rendered

SysML – System Modeling Language

UI – User Interface

UML – Unified Modeling Language

Vs Code – Visual studio Code

WBS – Work Breakdown Structure

WIFI
1
I
Table of Contents
Chapter one: Introduction ............................................................................................................... 1

1.1 Background Information ........................................................................................................... 1

1.2 Statement of problem ................................................................................................................ 1

1.3 Objective .................................................................................................................................... 1

1.3.1 General objective................................................................................................................ 1

1.3.2 Specific objective ............................................................................................................... 1

1.4 Scope ......................................................................................................................................... 1

1.5 Tools and Methodologies .......................................................................................................... 1

1.5.1 Data collection method....................................................................................................... 1

1. Interview............................................................................................................................... 1

2. Observations ......................................................................................................................... 2

3. Document analyses ............................................................................................................... 2

1.5.2 System development method ............................................................................................. 2

II
 ..................................................................................................................................................... 3

1.5.3 Development tools.............................................................................................................. 3

1.6 Beneficiaries ............................................................................................................................. 3

1.7 Schedule .................................................................................................................................... 4

Chapter Two: Project Management ................................................................................................ 5

2.1 Introduction ............................................................................................................................... 5

2.2 project planning ........................................................................................................................ 5

Work breakdown structure .......................................................................................................... 5

2.3 Resource planning ................................................................................................................... 12

2.3.1 Human Resource Planning ............................................................................................... 12

2.3.2 Material / Equipment planning ......................................................................................... 13

2.3.2.1 Hardware Resources ................................................................................................... 13

2.3.2.2 Software Resources .................................................................................................... 13

2.4 Financial planning ................................................................................................................... 14

2.4.1 Human resource financial plan ......................................................................................... 14

2.4.2 Material / Equipment Financial Plan ................................................................................ 14

2.4.2.1 Hardware equipment and services purchase estimates .............................................. 14

2.4.2.2 Software purchase estimates ...................................................................................... 14

2.4.2.3 Internet service ........................................................................................................... 15

2.4.3. Resource budget estimates ........................................................................................... 15

2.5 Team Organization................................................................................................................ 15

2.6 Process Model ......................................................................................................................... 16

2.7 Risk MMM plan...................................................................................................................... 16

2.7.1 Risk Items Table ............................................................................................................... 17

2.7.2 Risk Mitigation, Monitoring & Management plan Table ................................................. 17

III
Chapter Three................................................................................................................................ 20

3.1 Introduction ............................................................................................................................. 20

3.2 Current system overview ........................................................................................................ 21

3.3 proposed system ...................................................................................................................... 21

3.3.1 Functional Requirements .................................................................................................. 21

3.3.2 Non-functional Requirements........................................................................................... 21

3.4 system models – Requirement Determination ........................................................................ 22

3.4.1 Essential Use Case Modeling ........................................................................................... 22

3.4.1.1 Use Case Diagram ......................................................................................................... 22

3.4.1.2 Use Case Documentation ........................................................................................... 23

3.4.2 Essential UI prototype ...................................................................................................... 25

3.4.3 User Interface Flow Diagram ........................................................................................... 28

3.4.4 Supplementary specifications ........................................................................................... 29

3.4.4.1 Business rules ............................................................................................................. 29

3.4.4.2 Constraints.................................................................................................................. 30

3.4.4.3 Change Case ............................................................................................................... 31

3.5.1.2 Use Case Documentation ........................................................................................... 33

3.5.2 Sequence Diagram ............................................................................................................ 39

3.5.3 Activity Diagram .............................................................................................................. 44

IV
List of Tables
Table 1: WBS ................................................................................................................................ 11

Table 2: Human Resource Plan..................................................................................................... 13

Table 3: Hardware Resource Plan ................................................................................................. 13

Table 4: Software Resource Plan .................................................................................................. 14

Table 5: Human resource financial plan ....................................................................................... 14

Table 6: hardware equipment and services purchase estimate ..................................................... 14

Table 7: Software purchase estimates ........................................................................................... 15

Table 8: Internet service................................................................................................................ 15

Table 9: Resource budget estimates .............................................................................................. 15

Table 10: Team organization ........................................................................................................ 16

Table 11: Risk Items list ............................................................................................................... 17

Table 12:Inaccurate schedule estimation ...................................................................................... 17

Table 13:Making sequence mistakes ............................................................................................ 18

Table 14:assigning wrong resources ............................................................................................. 18

Table 15:cost estimation errors ..................................................................................................... 18

Table 16:project execution failure ................................................................................................ 19

Table 17:inadequate planning ....................................................................................................... 19

Table 18:poor definition of scoop ................................................................................................. 19

Table 19:absence of leadership ..................................................................................................... 20

Table 20:lack of experience .......................................................................................................... 20

Table 21:lack of communication .................................................................................................. 20

Table 22:Get on a bus ................................................................................................................... 24

Table 23:Search seat ..................................................................................................................... 24

V
Table 24:Check the bus ................................................................................................................. 25

Table 25:Assign route ................................................................................................................... 25

Table 26:View report .................................................................................................................... 25

Table 27:change case 1 ................................................................................................................. 32

Table 28:change case 2 ................................................................................................................. 32

Table 29:change case 3 ................................................................................................................. 32

Table 30:change case 4 ................................................................................................................. 33

VI
Table 31:Use Case Description for login ...................................................................................... 34

Table 32:Use Case Description for Create Account ..................................................................... 35

Table 33:Use Case Description for Manage database .................................................................. 35

Table 34:Use Case Description for Generate report ..................................................................... 36

Table 35:Use Case Description for Assign bus ............................................................................ 36

Table 36:Use Case Description for Track Location ..................................................................... 37

Table 37:Use case documentation for Reserve a seat ................................................................... 37

Table 38:Use case documentation for select route ....................................................................... 38

Table 39:Use case documentation for Cancel Reservation ........................................................... 38

Table 40:Use Case Description for Logout .................................................................................. 39

VI
I
List of Figures
Figure 1: system development life cycle methodology .................................................................. 3

Figure 2:gantt chart ......................................................................................................................... 4

Figure 3:Essential use case diagram ............................................................................................. 23

Figure 4:home page UI ................................................................................................................. 26

Figure 5:Location and track list page UI ...................................................................................... 27

Figure 6:reservation, verification and notification UI .................................................................. 28

Figure 7:UI flow diagram ............................................................................................................. 29

Figure 8:System use case diagram ................................................................................................ 33

Figure 9:Create account sequence diagram .................................................................................. 39

Figure 10:Login sequence diagram ............................................................................................... 40

Figure 11:Assign bus sequence diagram ....................................................................................... 41

Figure 12:Reserve seat sequence diagram .................................................................................... 42

Figure 13:Cancel reservation sequence diagram .......................................................................... 42

Figure 14:Select route sequence diagram ..................................................................................... 43

Figure 15:Track location sequence diagram ................................................................................. 43

Figure 16:Logout sequence diagram ............................................................................................. 44

Figure 17:Create account activity diagram ................................................................................... 45

Figure 18:Manage database activity diagram ............................................................................... 46

Figure 19:Generate report activity diagram .................................................................................. 47

Figure 20:Login activity diagram ................................................................................................. 48

Figure 21:Assign bus activity diagram ......................................................................................... 49

Figure 22:Track location activity diagram .................................................................................... 50

Figure 23:Reserve seat activity diagram ....................................................................................... 51

VI
II
Figure 24:Select route activity diagram ........................................................................................ 52

Figure 25:Search bus activity diagram.......................................................................................... 53

Figure 26:Cancel reservation activity diagram ............................................................................. 54

Figure 27:Logout activity diagram ............................................................................................... 55

IX
 Chapter one: Introduction

1.1 Background Information

Transportation is one of service sector that provides an important element for social, economic
and environmental sustainability. It is an absolute necessary means to an end and allows people
to carry out the diverse range of activities that makes up daily life. It is a means to access business
activities, education, employment & recreational opportunities.
Similarly, Public transport is of all transport facilities, it is a situation in which passengers do
not use their personal means of transportation to travel. It is popular means of travelling in the
city or across the country because of its relative cheapness compared to other means of transport.
This includes mini buses, taxis.
Addis Ababa, the capital city of Ethiopia, is a bustling metropolis with a rapidly growing
population. As the city continues to expand, the need for efficient and reliable transportation
becomes increasingly important. One of the key modes of transportation in Addis Ababa is the
city bus system, which plays a vital role in connecting residents to various parts of the city.
The city bus transportation system in Addis Ababa serves as a lifeline for many residents,
providing them with an affordable and accessible means of commuting. It plays a crucial role in
reducing traffic congestion, improving air quality, and promoting sustainable urban development.
Additionally, the bus system contributes to the social and economic development of the city by
connecting people to employment centers, educational institutions, healthcare facilities, and other
essential services.

1.2 Statement of problem

In all service giving organization, quality is the major issue that concerns customer. Because of
this, the organizations which have direct contact with customer have to be focus the issue of
quality service delivery by understanding what actually goes in customer mind. Public transport
is also one of the service sector which is highly depend of its customer in regard with service
delivery and have to focus on their customer wants by keeping the provision of quality service.
In Ethiopia, the existing reality shows that in many of the transport provider companies,
specifically, public bus services are observed with major problems seeking the good attention of

1
the sector. Some of the problems are; the user is unable to view or locate nearby buses in their
vicinity, hindering their ability to plan and navigate their daily commute effectively, the user is
unable to view the real-time location of a bus, users are unable to determine whether the bus
they intend to board is already full or has available seating, users are unable to reserve a place in
a bus, resulting in inconvenience and potential disruption to their travel plans.
Therefore, there is a pressing need to develop a comprehensive bus tracker application thatcan
address these issues and improve the overall quality of the bus transportation system.

1.3 Objective

1
1.3.1 General objective
The general objective of this project is to develop a real time bus tracker and reservation android
application for city buses.

1.3.2 Specific objective

 To provide real-time information on the location of buses.
 To allow users to track the progress of their bus see when it is expected to
arrive at their stop.
 To improve the efficiency of the bus system by providing real timeinformation
to rides.
 To reduce the amount of time that riders spend waiting for buses.
 To solve problems face in the existing system.
 To satisfy customers by saving their time.

1.4 Scope
The system exclusively supports the English language. This means that all features,
functionalities, and content within the application will be available and accessible only in English.
The user interface, instructions, prompts, and any other form of communication within the
application will be in English. The application will not provide any support or translation forother
languages.
The system is limited to Addis Ababa. The features and functionalities of the application are
specifically designed to cater to the needs and requirements of the residents and businesses in
Addis Ababa. The application may not be compatible or relevant for users outside of the city.
By focusing solely on Addis Ababa, the application can provide more accurate and localized
information, services, and solutions.
The Application only supported by android devices running version 4 and above. Users with
android devices running on version 4 or any subsequent versions can easily access and utilize the
application. By targeting the specific range of android versions, large majority of users can benefit
from the features and functionalities offered by the application.

1
1.5 Tools and Methodologies

1.5.1 Data collection method

1. Interview
We are going to use these data collection method on the first two phase of system development
life cycle. On these data collection method we are going to interview different persons on the
sector. We use the interview method because of many advantages on it hence we can find

1
pure and neat data it’s also the most effective way to collect data.

 To gather additional information by asking open-ended questions. These questions

allowed the interviewee to provide detailed responses, enabling us to gain deeper
understanding of the topic at hand.

 To observe physical expression of the interviewee. Nonverbal cues such as facial

expressions, body language, and gestures can provide valuable insights into a person’s
emotions, attitudes, and overall demeanor.

2. Observations
The next method to collected data is observation. Observation has many advantages to be
chosen on our research some of them are us followed:-
 The data can be recorded systematically.
 To find a reliable information.
 It’s easy to observer certain group or individual whom are difficult to access.
 It’s also important to identify peoples to be interviewed
 Have a very low cost in compared to others.

3. Document analyses
The last way of data collection method to be used on the project. These data collection method
helps us to understand the existing system implementation. The way to implement document
analyses by taking different data’s from the city bus provider. These method also helps as to
analyze documents done before to find reliable information.

1.5.2 System development method

For our project we decided to use object oriented system development methodology. This
methodology is most widely being popular now a days and it’s also more decretive than others so
that to make our system popular and widely used we must use object oriented system
development method. When we say the method is more decretive it’s because of the diagrams to
be implemented on the document like the use case diagram and others.

2
 Figure 1: system development life cycle methodology

1.5.3 Development tools

Development tools are software applications that assist developers in creating, debugging, maintaining,
and managing software applications and systems. They include integrated development environments
(IDEs), code editors, version control systems, testing tools, and continuous integration/continuous
deployment (CI/CD) tools. These tools streamline the software development process, improve
productivity, and ensure code quality and reliability. [] Developing a bus tracker android app involves
using a combination of tools and technologies.
Documentation tools:
- MS word 365
- MS powerpoint 365
- Lucid chart
- Figma
Application tools:
Android Studio: The official Integrated Development Environment (IDE) for Android app
development. It provides comprehensive tools for coding, debugging, and testing our app.
Flutter: The UI toolkit for building natively compiled applications for mobile, web, and desktop from a

3
single codebase.
Dart: The programming language used by Flutter.
Firebase: A suite of cloud-based tools by Google, often used with Flutter apps. For our bus tracker app,
we use:
- Firestore: A NoSQL database to store user, bus, track, route, and other related data.
- Firebase Authentication: To handle user authentication and authorization.
- Firebase Cloud Messaging: To send push notifications to users.
- Firebase Analytics: To track user interactions within the app
Website tool:
React: popular javascript frameworks/libraries for building interactive user interface and single – page
application.
Next.js: is a react based framework that enable developers to build server side rendered (SSR) and static
web applications.
Tailwind css: is a utility first css framework for rapidly building customer user interfaces. Instead of
writing custom css, we use predefined classes to style our HTML element directly.
Code editor:
VS code: a popular code editor with many extension for web and app development.

1.6 Beneficiaries
Bus tracker applications provide a wide range of benefits some of them are:-
Stakeholders
For the enterprise:
 Get more customer
 Based on customer request distribute bus to more traffic
For customer:
 Get information for the bus
 To save the wasting time
 When the bus is wait the user take another option
For government
 Convert traditional system to automated system
 Increase customer need
4
 For the team develop the program
 Enhance knowledge and skill
Tangible benefits
It is project benefit that can convert into monetary values. For this project, we have identified

5
the following tangible benefits (per year).

 Decrease in labor cost.

 Reduced stationary coat.
 Reduction of error.

Intangible benefits

It is our project benefit that cannot convert into monetary values.

 Enhance reliability.
 Knowledge gain by project developer.
 Increasing the competiveness of the individual.
 More timely, update and accurate information.
 Improved productivity.
 Improved the morale of our team.
 Facilitating information processing of our team.
 Faster decision making on the team member
 Enhance customer satisfaction
 Minimize error prone
 Provide secure and reliable service
 Reduce dispute among passenger when they use hand recording.
 Progress customer service
 Provide convenient way to use the application

1.7 Schedule

6
 Project Implem
intiation Develop entation
and ment and
plannin System System and mainten
g analysis design testing ance

Figure 2: gantt chart

11/1/20 12/2/20 1/18/20 2/15/20 4/26/20
23 23 24 24 24

12/1/2023
4/25/2024

3/4/2024
5/30/2024

1/7/2024

0
10
20
Duration(Days)

30
40
50
60

7
Chapter Two: Project Management

2.1 Introduction
A project is a unique, transient endeavor undertaken to achieve planned objectives, which could
be defined in terms of outputs, outcomes or benefits. A project is usually deemed to be a success
if it achieves the objectives according to their acceptance criteria, within an agreed timescale and
budget. Time, cost and quality are the building blocks of every project and projectmanagement is
the application of processes, methods, skills, knowledge and experience to achieve specific
project objectives according to the project acceptance criteria within agreed parameters. Project
management has final deliverables that are constrained to a finite timescale and budget, A key
factor that distinguishes project management from management is that it hasa final deliverable
and a finite timespan, unlike management which is an ongoing process. Because of this a project
professional needs a wide range of skills; often technical skills, and certainly people management
skills and good business awareness.
In order to create the aforementioned final deliverables, project management has various core
components and subtasks undertaken by the project manager or the project management team
starting with defining the reason why a project is necessary; then capturing project requirements
followed by specifying quality of the deliverables themselves once that is done estimating
resources and timescales that are needed to fulfill the deliverables is required; then preparing a
business case to justify the investment is made, after which securing corporate agreement and
funding commences. It is also important to be developing and implementing a management plan
for the project to ensure project success and throughout every step of the way leading and
motivating the project delivery team is an activity that shouldn’t be ignored.
Project management can be used by anyone to manage projects, even if they are not formally
called a ‘project manager’ in order to ensure project success regardless of the title a person
assuming the position of ‘project manager’ must balance the triple constraint and be able to make
effective tradeoffs with respect to the project goals. It is also important to understand the project
context or environment which refers to the influences which will affect the project both internally
and externally that can be environmental, social, technological and economic.

2.2 Project planning

8
Work breakdown structure
Work breakdown structure (WBS) in project management is a method for completing a complex,
multi-step project. The goal of WBS is to make a large project more manageable. Breaking it
down into smaller chunks means work can be done simultaneously by different team members,
leading to better team productivity and easier project management.
The WBS on our project was built using the top-down approach because the order which we will
be preparing our project document has been predetermined by the academic committee, this
approach will make it easier for us to organize our work.

9
Activitie Phases Activities or task Duratio Depen Deliverables
s n dence
Number
1 Project  Background research 21 days - Chapter one
initiation  Data collection documentation
 Identify data collection
methodology
 Understanding the
problem of existing
system
 Scheduling
 Making ready the
interview questions
2 Project  Develop WBS 10 days 1 Chapter two
planning  Prepare and document documentation
resource plan
 Prepare and document
financial plan.
 Identify and document
team organization
structure
 Identify and document
process model
 Prepare and document
risk management plan

3 System  Analyzing the existing 21 days 2 Chapter three

analyses problem documentation
 Identifying requirement
 Delivering the interview
questions

10
  Modeling diagrams

4 System design  Define and document 15 days 3 Chapter four

design goal documentation
 Subsystem
decomposition
 Class model
 Persistent model
 UI design
 Deployment diagram
 Network diagram

5 Implementatio  Connect App with 10 days 4 Chapter five

n database and build user documentation
and data management
components
 Coding
 Integration testing of all
components

6 Conclusion  Document conclusion 10 days 5 Chapter six documentation

and and recommendation
recommendati  Analyze project
on performance and work
done
 Document conclusion
and write
recommendation for
future use

11
Table1:WBS

12
2.3 Resource planning
Resource planning involves determining what physical resources and what quantities of each
should be used and when they would be needed to perform project activities.

2.3.1 Human Resource Planning

Human resource planning refers to a project management process that involves the careful and
deliberate identification, categorization and ultimately, documentation of the entire of all project
roles assigned to all individual members of the project work team.
Task ID Roles Task Description Estimated
Team
Members
Project Manager  Oversee the entire project and ensure 1
alignment with goals.

1  Coordinate communication between

team members and stakeholders.
 Monitor project timelines and manage
risks.
System Analysts  Conduct literature reviews and market 1
analyses.

2  Document current and proposed

system overviews.
 Develop system models and
requirements.
3 Frontend  Design and implement the user 2
Developer interface.
4 Backend  Develop server-side logic and APIs. 2
Developers
5 Database  Design the database structure. 1

13
 Designer  Optimize database performance.

UI/UX Designer • Design user friendly interfaces for the 1

mobile application

6 • Collaborate with developers to ensure

14
 the design is implemented accurately.
• Conduct user research and incorporate
user feedback into the design.
Quality  Develop and execute test plans. 1
7 Assurance  Identify and report bugs or issues.
Specialist  Collaborate with developers to address
concerns.
Table 2: Human Resource Plan

2.3.2 Material / Equipment planning

Material/Equipment planning enables the project team to fulfill the objectives of their project by
providing them with a system that estimates the quantities of resource necessary to undertake it.

2.3.2.1 Hardware Resources

Item Quantity Specification Justification

Laptops 4  Minimum Intel  Used to write and debug code,
core i5 or i7 prepare documentation and UI
processor, Full designs.
HD resolution,  Used to test the web version
8GB of RAM interface of the system.
Android 5  Android 5.1  Used to test the android
phones application interface designed
for the system.
Printer 1  HP LaserJet  To print various
p1102 documentations.
Portable 1  Transcend 2TB  To save data backups.
Hard disk HDD
Drive
Stationary  Paper, stapler,  Used during documentation
pens and pencils. preparation.
Table 3:Hardware Resource Plan

15
2.3.2.2 Software Resources

Software Specification Justification

MS office suite  MS office  Used in document preparation
Visual studio code  Used as a source code editor
Google docs  Used to collaborate on
preparing documentation
remotely
Windows 10/11 and  Windows 10/11  To be used as an environment to
Android OS run and test system upon

16
  Android version
5.1 or higher
Telegram Desktop  Used to exchange information
and ideas among team members
Table 4:Software Resource Plan

2.4 Financial planning

Financial planning is the process of determining project costs and developing a budget. It has
many benefits, including estimating profit, reducing financial risk, and planning for unexpected
costs.

2.4.1 Human resource financial plan

Profession Head Working Weekly Total salary
count duration salary(ETB) costs (ETB)
Frontend developer 2 22 3000 132,000
Backend developer 2 22 3000 132,000
Database engineer 2 22 3000 132,000
Mobile app developer 1 22 2000 44,000
UI/UX designer 2 12 3000 72,000
Project manager 1 22 5000 110,000
System tester 2 4 2000 16,000
Total 638,000
Table 5:Human resource financial plan

2.4.2 Material / Equipment Financial Plan

2.4.2.1 Hardware equipment and services purchase estimates

Item Quantity Unity price(ETB) Total (ETB)

Laptop 4 30,000 120,000
Android phone 5 20,000 100,000
Portable hard disk 1 5,200 5,200
drive
17
Printer 1 6,000 6,000
GSP - - -
Total 231,200
Table 6: Hardware equipment and services purchase estimate

2.4.2.2 Software purchase estimates

Software Quantity Unity price Total (ETB)

MS office - Free -
Google Dos - Free -

18
Windows 10/11 and - Free -
android OS
Telegram desktop - Free -
Table 7: Software purchase estimates

2.4.2.3 Internet service

Service Amount Specification Justification Price (ETB)

Internet services Unlimited Portable router For research, 6500
internet with 4G LTE development
package and sharing
resources
Total 6500
Table 8: Internet service

2.4.3. Resource budget estimates

Resource type Total (ETB))

Human resource financial plan 638,000
Hardware resource financial plan 231,200
Software resource financial plan 0
Internet service financial plan 6500
Grad total 875,700
Table 9: Resource budget estimates

2.5 Team Organization

An organizational information table for a transport company is an important tool used to optimize
operations and ensure efficient use of resources. It enables the team to assign tasks and
responsibilities to different departments, outlining their roles and the reporting structure. The table
can also indicate the strategically important positions within the organization and make sure each
person’s roles are properly represented. so, it provides clarity and helps the company reach its
goals in an efficient manner.
We used democratic decentralization to organize our team. Democratic decentralization can be a
valuable tool for improving collaboration and innovation. By giving team members more

19
autonomy and decision-making power, democratic decentralization can help to create a more
flexible and responsive project environment.

Name Role Responsibility Contact

1. Aboma Djima Project Manager Overall project • +251 945205867
coordination and •abomadjima30@gmail.com
management
2.Adoniyas Development lead and manage • +251 928655322
Atsbaha Manager the team of • adoniyas21@gmail.co

20
 software
developers who are
working on the
frontend and
backend of the
software
3.Bezawit Design Manager Overseeing the • +251 927000768
Alemayehu and Business design process of • bezawit27@gmail.com
Analyst the project, fromthe
initial idea to
the final product
4. Bezawit Testing Manager lead and managethe • +251 927865543
Tsebelu testing process and • bezat12@gmail.com
strategy for the
software project
5. Fikir Kindu Marketing manager lead and managethe • +251 90 637 4823
and testing process and • fikirkin11@gmail.com
Customer Support strategy for the
software project
Table 10: Team organization

2.6 Process Model

The process model we use in this project is object-oriented modeling. It is an established approach
to document the information systems. In an object model, a system is captured in terms of object
types and associations, state machines collaboration diagrams etc. the object oriented modeling
approach creates the union of the application and database development and transforms it into a
unified data model and language environment. Object oriented modeling allows us for object
identification and communication while supporting data abstraction, inheritance and
encapsulation.

2.7 Risk MMM plan

21
A risk management technique is usually seen in the software project plan. This can be divided
into risk mitigation, monitoring and management plan. In this project all works are done as part
of risk analysis. As part of the overall project plan project manager generally uses this risk MMM
plan.

In some software teams, risk is documented with the help of a Risk Information Sheet (RIS). This
RIS is controlled by using a database system for easier management of information i.e creation,
priority ordering, searching, and other analysis. After documentation of RMMM and start of a
project, risk mitigation and monitoring steps will start.

22
 2.7.1 Risk Items Table
The table describes the risk related with the project.

Risk type Risk ID Likelihood of Impact if the Risk rating

risk occurring risk occurs
Schedule R1 Medium High Medium
Sequence R2 Low High Medium
Technical R3 High High High
Budget R4 Medium High Medium
Performance R5 Medium High High
External R6 Low High Medium
Poor scope R7 Low High Medium
definition
Absence of R8 Low High Medium
leadership
Lack of R9 Medium Medium Medium
experience
Lack of R10 Low High Medium
communication

Table 11:Risk Items list

2.7.2 Risk Mitigation, Monitoring & Management plan Table

Risk ID:R1 Risk name: Inaccurate

Schedule
Risk Mitigation

-Proper supervision and honest communication among members regarding deadlines and
ramping up work
Risk Monitoring
-Regular checkups by project manager to see if deadlines are being met

23
 Risk Management
-Update the schedule accordingly when change occurs

Table 12:Inaccurate schedule estimation

Risk ID:R2 Risk name: Making

sequence mistakes
Risk Mitigation

24
- Prioritize tasks or activities requiring more attention
Risk Monitoring
-consulting schedule before and after performing an activity to check for proper sequencing
of activities
Risk Management
-Go back to previous activity and track the next activity in the sequence and then proceed to
performing the proper activities sequentially
Table 13:Making sequence mistakes

Risk ID:R3 Risk name: assigning

Wrong resources

Risk Mitigation
-Follow predetermined resource plan
Risk Monitoring
-perform resource allocation checkup
Risk Management
Reallocate resource to their desired purpose

Table 14:assigning wrong resources

Risk ID:R4 Risk name: cost

estimation

Error

Risk Mitigation
-be sensitive and accurate during estimating costs
Risk Monitoring
-continually assess expenses

25
Risk Management
-recalibrate budget in accordance with the market at the time
-Reduce extra expenses
Table 15:cost estimation errors

Risk ID:R5 Risk name: project

execution

Failures

Risk Mitigation
-plan resources

26
-have a clear goal and objectives
Risk Monitoring
-continuously track resource utilization and communicate goal and objectives b/n teammembers
-use appropriate integration method

Risk Management
-consult experts regarding integration

Table 16:project execution failure

Risk ID:R6 Risk name: inadequate

planning
Risk Mitigation
- gather information about the project before planning and see sample that set out a clear plan.
Risk Monitoring
-check every detail of planning process.
Risk Management
-work on revising the entire plan.
Table 17: Inadequate planning

Risk ID:R7 Risk name: poor definition

of scoop
Risk Mitigation
- focus on defining the scope clearly without any vague activity.
Risk Monitoring
-check the scope definition line by line and correct when poor definition found.
Risk Management
-clearly combine the object and the requirement the project needed.
Table 18: Poor definition of scoop

27
Risk ID:R8 Risk name: absence of
leadership
Risk Mitigation
- focus on choosing the right leader that have what it take to be a leader and check if they
have the experience.
Risk Monitoring

28
-check if the chosen leader has any problem that can make them absent.
Risk Management
-give the leader appropriate task that can make the leader more interested and help him on the
leader need.
Table 19: Absence of leadership

Risk ID:R9 Risk name: lack of

experience
Risk Mitigation
- The development learn will learn the tools and the language required for the project in the
first semester.
Risk Monitoring
-making sure everyone is self-learning their role.
Risk Management
-Using a well-know working framework.
Table 20: Lack of experience

Risk ID:R10 Risk name: lack of

communication
Risk Mitigation
- creating an environment where individuals in the group can communicate well.
Risk Monitoring
-prepare team member meeting schedule and follow it.
Risk Management
-reorganizing the team to have good communication.
Table 21: Lack of communication

29
 Chapter Three

3.1 Introduction
System analysis answers the question of who will use the system, what the system will do, and
where and when it will be used. During this phase, the project team investigates any current
system(s), identifies opportunities for improvement, and develops a concept for the new system.
The system proposal is the initial deliverable that describes what business requirements the new
system should meet. System analysis is conducted for the purpose of studying a system or its parts
in order to identify its objectives. It is a problem solving technique that improves the system and
ensures that all the components of the system work efficiently to accomplish their purpose.

30
In this chapter we have included information about the current system and proposed system,
functional and non-functional requirements to describe how the system will accomplish the
objectives described in the first chapter.

3.2 Current system overview

The current city bus system in Addis Ababa is operated by the Addis Ababa City Administration
Transport Authority (AACATA). The bus system in Addis Ababa is known for being affordable
and accessible to a wide range of residents. However, the system does face challenges such as
overcrowding during peak hours, limited routes to certain areas of the city, and occasional delays
due to traffic congestion.
The buses are equipped with seating for both standing and seated passengers, as well as overhead.
The buses are generally well-maintained and provide a relatively comfortable ride for passengers.
The bus routes are divided into different zones, with each zone serving a specific area of the city.
The buses operate on a fixed schedule, with designated stops along each route. Deployers play a
crucial role in the efficient operation of city buses by assigning routes to drivers and ensuring that
all buses are running on schedule. They are responsible for coordinating the daily operations of the
bus fleet, including monitoring driver performance. They generate daily, weekly and monthly
reports of the deployment process.

31
Ensuring that buses arrive on time to their designated routes is crucial for maintaining efficiency
and customer satisfaction. This task falls into the hands of controllers, who play a vital role in
monitoring and managing the movement of buses to ensure they adhere to their schedules without
any delays. Controllers are responsible for overseeing the entire operation of bus services, from
monitoring the progress of buses in real-time to making quick decisions to address any issues that
may arise. They work closely with drivers, deployers, and other staff members to coordinate the
smooth running of services and minimize disruptions that could lead to delays.
In the event of a maintenance issue occurring, the driver is responsible for promptly reporting the
issue to the deployer. The deployer will then escalate the report to the deployment manager, who
will assess the severity of the issue and determine the appropriate course of action. If necessary, the
deployment manager will notify the maintenance body to address and resolve the maintenance issue
efficiently and maintenance body will address the issue and resolve it in a timely manner. This
structured reporting process ensures that maintenance issues are promptly addressed and resolved
to maintain the safety and operational efficiency of the vehicles.
The bus system in Addis Ababa is known for being affordable and accessible to a wide range of
residents. However, the system does face challenges such as overcrowding during peak hours,
limited routes to certain areas of the city, and occasional delays due to traffic congestion.
Currently there is no dedicated public bus tracker system with in the country, Passengers waiting at
bus stops often find themselves in a state of uncertainty and frustration when they are unaware of

32
the arrival time of their bus. Without a real-time bus tracking system in place, passengers are left to
rely on outdated schedules or simply wait without any indication of when their bus will arrive. This
lack of information can lead to long wait times, missed connections, and overall dissatisfaction with
the public transportation system. Implementing a real-time bus tracking system would greatly
improve the passenger experience, providing them with accurate and up-to-date information on the
arrival times of buses, reducing wait times, and increasing overall efficiency and satisfaction for all
passengers.
Overall, the city bus system in Addis Ababa plays a crucial role in providing transportation for
residents and visitors alike, and efforts are being made to improve and expand the system in order
to better serve the growing population of the city.
3.3 Proposed system

3.3.1 Functional Requirements

Functional requirements refer to the functionalities that must apply to a system. The functional
requirements of bus tracking system are stated below.
 The system shall allow the user to create account.
 The system shall allow the user to login using their required account detail.
 The system shall allow users to register in the system.
 The system shall allow deployer to add buses.
 The system shall allow deployer to assign buses, drivers and routes.
 The system shall allow ticketer to update number of passengers.
 The system shall allow users to logout.
 The system must be able to show information to user in real time.
 The system must be able to process the position data received from bus positioning
module.
 The system must calculate the estimated distance and time to user and display the position
on maps.
 The system must be able to allow user retrieve information from mobile.
 The system must be able to send notification when the bus is near to the station.

3.3.2 Non-functional Requirements

33
Non-functional requirements are specifications that describe the system’s operation capabilities
and constraints that enhance its functionality.
The non-functional requirements of the proposed system are listed as follows:
 Accuracy: The system should provide the accurate estimated bus arrival time to user.
 Security: The system shall have authentication based on password logins with a
mechanism of identifying roles to maintain data access privileges.
 Localization: The system shall be limited to Addis Ababa’s geography and the launch
version will only feature one language(English).
 Availability: The system shall be available 24 hours a day, 7 days a week.
 Usability: The system will have an easy-to-use interface with controllers that are easy to
understand for users familiar with most social media apps.
 Response time: The system should provide response in 2 seconds for any user action.

34
  Reliability: The application should be reliable for users whenever they need it. It should
minimize system failures and users can access the application consistently.
 Integration: The application should be able to integrate with external systems such as
goggle map, to provide accurate information to users.
 Scalability: The application should be able to handle an increasing demand without
degradation in its performance.
 Learnability: the system should be learnable in one week.

3.4 System models – Requirement Determination

Requirement determination is the process of turning the very high-level explanation of the
business requirements stated in the system request into a more precise list of requirements that
can be used as inputs to the rest of the analysis. This expansion of the requirements ultimately
leads to the design of the system.

3.4.1 Essential Use Case Modeling

Essential use case modeling is the process of preparing a complete, meaningful and well-
designated use case model from the point-of-view of users in some role or roles in relation to a
system and that embodies the purpose or intentions underlying the interaction, our team has
depicted the essential use case model using diagrams along with tables depicting each use case as
follows.

3.4.1.1 Use Case Diagram

Use case diagram describe the high-level functions and scope of the system. The diagram also
identify the interactions between the system and its actors. The use case and actors in use case
diagram describe what the system does and how the actors use it, but not how the system operates
internally.

35
Figure 3:Essential use case diagram
3.4.1.2 Use Case Documentation
Use case name: Uses bus
Use case Id: UC01
Description: user use this use case to use bus
Pre-condition:
Post-condition: user will use the bus
Actor: Passenger
Basic course of action:
1. The passenger wants to use bus
2. The passenger goes to bus stop

36
3. The passenger wait a bus
4. The passenger checks the route of the bus when the bus comes
5. Get on a bus
6. Use case ends
Alternative course of action:
A: The bus does not go to the direction passenger wants
A4. The passenger does not get on the bus
A5. Use case continues on step 3 of BCA.
Table 22:Uses bus

Use case name: Buy ticket

Use case Id: UC02
Description: User use this use case to buy ticket
Pre-condition: The passenger is physically present at bus stop
Post-condition: The passenger buy ticketor
Actor: Passenger, Ticketer
Basic course of action:
1. Passenger waits bus at bus stop
2. The bus arrives
3. Passenger request a ticket
4. Ticketer checks if the bus is full
5. The bus is not full
6. Ticketer ask passenger to pay
7. Passenger pays for the ticket
8. Ticketer provide ticket for the passenger
9. Passenger receives the ticket
10. Use case ends
Alternative course of action:

37
 A: The bus is full
A4. The ticketer informs the passenger there is no free
space
A5. Use case continues on step 1 of BCA
Table 24:Check the bus

Use case name: Assign bus

Use case Id: UC03
Description: User use this use case to assign bus
Pre-condition: The user has permission to assign bus
Post-condition: User will assign bus
Actor: Deployer
Basic course of action:
1. The deployer want to assign bus
2. Deployer checks available buses
3. The bus is available
4. Deployer select route and departure time for bus
5. Deployer notifies to relevant personnel
6. Use case ends
Alternative course of action:
A: there is no available bus
A2. Use case ends

Table 25:Assign route

Use case name: Assign driver

Use Case ID: UC-004
Description: Deployer use this use case to assign bus

Pre-condition: The user has permission to assign bus

Post-condition User will assign bus
Actor: Deployer, Driver
Basic course of action:
1. The deployer want to assign driver
2. Deployer checks available driver
3. The driver is available
4. Deployer selects bus for driver
5. Deployer notifies to driver
6. Use case ends

38
Alternative course of action:
A: there is no available driver
A2. Use case ends

Use case name: Inform malfunction

Use case ID: UC005
Description: user uses this use case to inform malfunction
Pre-condition:
Post-condition:
Actor: Driver, Deployer
Basic course of action
1. The driver wants to inform malfunction.
2. The driver identifies a malfunction.
3. The driver inform details about malfunction to deployer.
4. Use case ends
Alternative course of action

Use case name: Generate report

Use case ID: UC006
Description: user uses this use case to generate report
Pre-condition:
Post-condition:
Actor: Deployer
Basic course of action
5. The deployer wants to generate report.
6. The deployer gathers the necessary data.
7. The deployer creates the report.
8. Ehe deployer reviews the report for accuracy and completeness.
9. The deployer submit the report to the manager.
10. Use case ends.
Alternative course of action

Use case name: View report

Use case Id: UC06
Description: User use this use case to view report
Pre-condition: Report must be generated
Post-condition: user will view report
Actor: Manager

39
Basic course of action:
1. The manager want to view report
2. The manager check if there is generated report
3. The manager view the report
4. Use case ends
Alternative course of action:
A: There is no generated report
A2. The manager asks employee to generate report
A3. The Employee gives the generated report to the
manager
A4. Use case continues on step 3 of BCA
Table 26:View report

3.4.2 Essential UI prototype

An essential user interface prototype also known as an abstract prototype or paper prototype, is
a low-fidelity model, or prototype, of the UI for a system. It represents it general ideas behind

40
the UI, but not the exact details. Essential UI prototype represent user interface requirements in
a technology independent manner, just as essential use case models do for behavioral
requirements. An essential user interface prototype is effectively the initial state-the beginning
point-of the user interface prototype for a system.it models user interface requirements,
requirements that are evolved through analysis and design to result in the final user interface for
a system, enabling the team to explore usability aspects of the system. Below you will find an
array of UI prototype depicting the various component the android app.

Figure 4:Verification page UI

41
Figure 5: Home and Station page UI

42
Figure 6: Buses and Bus information UI

Figure 7: Track bus and Feedback UI

43
Figure 8: Sign in and Driver UI

Figure 9: Route UI

44
Figure 9: Feedback UI

45
Figure 10: Ticketer page UI

3.4.3 User Interface Flow Diagram

User interface flow diagram for the mobile application:-

46
Figure 7:UI flow diagram

47
Figure 8:UI flow diagram

3.4.4 Supplementary specifications

3.4.4.1 Business rules
Business rules guide the everyday decision-marking within businesses by outlining the
relationships between objects, such as customer name and their corresponding orders. This
translation of an organization’s business activities into concrete business logic allows software
engineers and business analysts to apply these ruler within workflow tools or other applications
to enable process automation.
ID: T001
Name: Real-time Tracking
Description: The app must provide real-time updates on the location of buses to users.
ID: T002
Name: Accuracy

48
Description: The location data provided by the app should be accurate and reliable to ensure users
can trust the information

49
 ID: T003
Name: User Privacy
Description: The app must adhere to privacy regulations and not share user location data with third
parties without explicit consent.
ID: T004
Name: Accessibility
Description: The app should be accessible to all users, including those with disabilities, by following
accessibility guidelines and standards.
ID: T005
Name: Notifications
Description: Users should receive timely notifications about changes in bus schedules, delays, or
other relevant information.
ID: T006
Name: User Authentication
Description: If the app includes features like saving favorite routes or personalized settings, it should
implement secure user authentication mechanisms.
ID: T007
Name: Feedback Mechanism
Description: Users should be able to provide feedback about the app's performance, accuracy, and
usability to help improve its quality.
ID: T008
Name: Data Usage
Description: The app should use data efficiently to minimize bandwidth usage and reduce data
costs for users.
ID: T008
Name: Compliance
Description: Ensure compliance with local regulations and laws governing public transportation
apps, including data protection and accessibility standards.

3.4.4.2 Constraints
A constraint is a restriction on the degree of freedom we have in providing a solution, these are
some of the constraint that apply to our project:-
1. ID: A001
Name: Device Compatibility
Description: The app should be compatible with a wide range of Android devices to ensure
accessibility for all users.

50
 2. ID: A002
Name: Location Accuracy
Description: Depending on the device's GPS capabilities and environmental factors, the app
should provide accurate location data to track buses effectively.
3. ID: A003
Name: Server Reliability
Description: The backend server responsible for collecting and disseminating bus location
data should be robust and reliable to minimize downtime and disruptions.
4. ID: 004
Name: Battery Consumption
Description: The app should minimize battery consumption to ensure it doesn't drain the user's
device quickly, especially during prolonged usage.
5. ID: A005
Name: Data Encryption for Privacy
Description: Implement a check to ensure that sensitive user data, especially location
information, is encrypted during transmission and storage. This check adds an extra
layer of security, safeguarding user privacy and preventing unauthorized access to
sensitive information within the bus tracker app.
6. ID: A006
Name: Consistent Data Format
Description: Enforce a check to ensure that data received from various transit providers
follows a consistent format. This ensures that the app's data processing logic remains
stable and can effectively handle information from different sources, minimizing errors
and enhancing the overall reliability of the bus tracker system.

3.4.4.3 Change Case

Change cases are used to describe new potential requirements for a system or modification
to existing requirement. Change cases are models in a simple manner. You describe the
potential change to your existing requirements, indicate the likeliness ofthat change
occurring.

Id B001

Description Changing the user interface (UI) design to

enhance visual appeal and usability may
positively impact user experience,
attracting more users to the bus tracker

51
 app.

Likelihood Within the next 3 months

Impact Improved user experience, increased user
engagement.

Table 27:change case 1

Id B002

Description Introducing an offline mode to the bus

tracker app allows users to access
previously viewed routes and bus
information without an active internet
connection.

Likelihood Between 6 to 12

Impact Improved user accessibility, especially in

areas with poor network coverage.

Table 28:change case 2

Id B003
Description Implementing multi-language support in
the bus tracker app can have a positive
impact by increasing user accessibility
and expanding the user base to speakers
of various languages.
Likelihood Between 1 to 2 year since launch.
Impact A common feature in global applications.
Table 29:change case 3

Id B004
Description Introducing augmented reality (AR) way
finding in the bus tracker app can have a
groundbreaking positive impact by
revolutionizing user experience and
providing enhanced navigation
capabilities.
Likelihood Between 6 months to 2 year since

52
 Impact Revolutionary user experience, improved
navigation for users.

Table 30:change case 4

Figure 8: System use case diagram

3.5.1.2 Use Case Documentation

Use Case Name: Register staff

Use Case Id: SUC-001

Description: The admin register new staff members in to the system by adding their personal
details and assigning relevant roles.

Pre-Condition(s): The admin must be logged into the system with appropriate permissions

53
 The admin must have all requested personal details of the new staff members

Post-Condition: The new staff member is successfully registered in the system.

Actor(s): Admin

Includes: Login

Extends:

Basic course of action:

1. The admin wants to register new staff member.

2. The admin accesses the staff management section in the system.

3. The system displays the option to register new staff member.

4. The admin selects the option to register a new staff member.

5. The system prompts the admin to fill in details of the new staff.

6. The admin fills all the requested details accurately.

7. The admin submits the information to the system.

8. The system validates the entered information and registers the new staff member.

9. The system displays a success message.

10. Use case ends.

Alternative course of action:

A. The admin entered invalid or incomplete information.

A8. The system prompts the admin to correct the errors.

A9. Use case continues from BCA-6.

Table: Use case description for Register staff

Use Case Name: Delete staff

Use Case Id: SUC-002

Description: The admin deletes staff members from the system.

Pre-Condition(s): The admin must logged into the system.

The staff member to be deleted must exist in the system.

54
 Post-Condition: Staff member successfully deleted from the system.

Actor(s): Admin

Includes: Login

Extends:

Basic course of action:

1. The admin wants to delete staff member.

2. The admin accesses the staff management section in the system.

3. The system displays a list of all staff members registered in the system.

4. The admin selects the staff member to delete from the system.

5. The system prompts the admin for confirmation before deleting the staff member.

6. The admin confirms the selection to delete the staff member.

7. The system deletes the staff member successfully.

8. Use case ends.

Alternative course of action:

A. The admin selects wrong staff member to delete.

A5. The admin cancels the operation.

A6. The admin selects a different staff member to delete.

A7. Use case continuous from BCA-5.

Table: Use case description for Delete staff

Use Case Name: Add bus

Use Case Id: SUC-003

Description: The user add new bus in to the system by adding their details.

Pre-Condition(s): The admin must be logged into the system with appropriate permissions
The admin must have all requested personal details of the new bus

Post-Condition: The new bus is successfully registered in the system.

Actor(s): Admin
55
 Includes: Login

Extends:

Basic course of action:

1. The user wants to register new bus.

2. The user accesses the bus management section in the system.

3. The system displays the option to register new bus.

4. The user selects the option to register a new bus.

5. The system prompts the admin to fill in details of the new bus.
6. The user fills all the requested details accurately.

7. The user submits the information to the system.

8. The system validates the entered information and registers the new bus.

9. The system displays a success message.

10. Use case ends.

Alternative course of action:

A. The user entered invalid or incomplete information.

A8. The system prompts the user to correct the errors.

A9. Use case continues from BCA-6.

Table: Use case description for Add bus

Use Case Name: Update bus

Use Case Id: SUC-004

Description: The user updates the details of an existing bus in the system.

Pre-Condition(s): The user must be logged into the system with appropriate permissions

The bus to be updated must already exist in the system

Post-Condition: The bus information is successfully updated.

Actor(s): Admin

Includes: Login
56
 Extends:

Basic course of action:

1. The user wants to update bus information.

2. The user accesses the bus management section in the system.

3. The system displays a list of buses registered in the system.

4. The user selects the bus for which he/she want to update the information.

5. The system prompts the user to edit details of the selected bus.

6. The user make necessary changes to the bus information

7. The user submits the updated information to the system.

8. The system validates the changes and updates the bus information.

9. The system displays a success message.

10. Use case ends.

Alternative course of action:

A. The user entered invalid information.

A8. The system prompts the user to correct the errors.

A9. Use case continues from BCA-6.

Table: Use case description for Update bus

Use Case Name: Delete bus

Use Case Id: SUC-005

Description: The user deletes the details of an existing bus in the system.

Pre-Condition(s): The user must be logged into the system with appropriate permissions
The bus to be deleted must already exist in the system

Post-Condition: The bus is successfully deleted.

Actor(s): Admin

Includes: Login

Extends:
57
 Basic course of action:
1. The user wants to delete bus.

2. The administrator selects the bus option.

3. The system presents a list of buses for the administrator to choose from.

4. The administrator selects the bus to be deleted.

5. The system prompts the administrator for confirmation.

6. The administrator confirms the deletion.

7. The system removes the selected bus from the database.

8. The system displays a success message confirming the deletion.

9. Use case ends

Alternative course of action:

A. The user entered invalid information.

A8. The system prompts the user to correct the errors.

A9. Use case continues from BCA-6.

Table: Use case description for Delete bus

Use Case Name: Assign bus

Use Case Id: SUC-006

Description: The user assigns bus.

Pre-Condition(s): The user must be logged into the system with appropriate permissions

Post-Condition: The bus is successfully assigned.

Actor(s): Admin

Includes: Login

Extends:

Basic course of action:

1. The user wants to assign bus.

2. The user selects the bus option.

58
 3. The system presents a list of buses to choose from.

4. The user selects the bus to be assigned.

5. The system displays form to be filled.

6. The user fills the assignment form.

7. The user submits the form.

8. The system validates the form.

9. The bus assigned successfully.

10. Use case ends

Alternative course of action:

A. The user entered invalid information.

A8. The system prompts the user to correct the errors.

A9. Use case continues from BCA-6.

Table: Use case description for Assign bus

Use Case Name: Login
Use Case ID: SUC-007

Description: It is authenticating that allows user to login to the system

Pre-Condition(s): The user must have their user name and password.
Post condition: The user successfully login to the system.

Actor(s): Admin, Manager, Driver, Ticketer, passenger

Includes :

Extends : Register staff

Basic course of action:

1. User wants to login into the system.
2. User search the system
3. The system displays ”login” form with login button
4. User fills user name and password
5. User clicks on ”login” button

59
 6. The system validates the form
7. The system checks user name and password from database entity
8. The system display home page
9. Use Case end
Alternative course of Action :
A: The provided user name or password is invalid
A6: The system informs the user the provided user name/password is invalid.
A7: use case continues from BCA-3.

Table: Use case description for Login

Use Case name: Track bus
Use Case ID: SUC-008
Description: This use case describes the process of user track bus location.
Pre-condition: User must be logged in successfully
Post-condition: User track bus successfully
Actor: Admin, Passenger
Includes: Login
Extends:
Basic flow of action
1. The passenger wants to select bus.
2. The passenger opens the application
3. The passenger select get your bus button
4. The system displays nearby stations
5. The passenger select specific station
6. The system display buses in the station
7. The passenger selects a bus
8. user clicks track location button
9. The system displays map and start tracking.
10. Use Case ends
Alternative Course Of Action:
A: There is no bus in the station
A6: the system displays “there is no bus in this station” message
A5: use case continues from BCA-5
Table: Use case description for Track bus
Use Case name: View Report
Use Case ID: SUC-009
Description: The system display report for the department daily, weekly, monthly and yearly
Pre-condition: The user must log to the system
Post condition Read detail information that recording system database

60
 Actor Admin, Manager
Include: Login

Extend
Basic flow of action
1.The user must login
2.User click on trip
3.The system read details all of information from system database
4. Display the report
Table: Use Case Description for view report
Use Case name: Registering a passenger
Use Case ID: SUC-010
Description: This use case describes how a new user registered into the system
Pre-condition: The user must have the application in his phone
Post-condition: The user registered successfully
Actor: Passenger
Includes:
Extends:
Basic course of action
1. The passenger wants to be registered in the system.
2. The passenger opens the app
2. The system prompts the user to enter their phone number.
3. The passenger enters their phone number and clicks on the "login" button.
4. The system checks users phone number
5. The system sends a verification code to the user's phone number via text message.
6. The passenger receives the verification code
7. The passenger enters the verification code.
8. The system verifies the code and confirms the user's phone number.
9. The passenger is prompted to insert name.
10. The passenger enters name and click next.
11. The system displays the home page.
12. use case ends.
Alternative Course Of Action
A: Passenger enters incorrect phone number
A4: The system prompts them to enter the phone number again
A5: use case continues from BCA-3
B: Passenger enters incorrect verification code
B7. The system prompts them to enter verification code again
B8. Use case continues from BCA-7
Table: Use Case Description for registering a passenger

61
 Use Case name: Update passenger number
Use Case ID: Suc-011
Description: The ticketer updates the current number of passengers in the bus
Pre-condition: The ticketer must be logged into the system with appropriate permissions
Post-condition: The ticketer update the number of passengers
Actor: Ticketer
Include: Login
Extend:

Basic course of action

1. The user wants to update number of passengers in the bus.
2. The user opens the system on their device.
3. The user select start trip option.
4. The system displays list of numbers in the screen.
5. The user enters current number of passengers in the bus
6. The system updates the passenger number
7. Use case ends
Alternative Course Of Action
A: User select end trip option.
A3. The system deactivates list of numbers in the screen.
A4. Use case ends
Table: Use Case Description for update passenger number
Use Case name: view assigned bus
Use Case ID: Suc-012
Description: This use case allows user to see assigned bus.
Pre-condition: The user must be logged into the system.
Post-condition: -The user see assigned bus.
Actor: Driver, Ticketer
Include: Login
Extend:
Basic course of action
1. The user wants to see assigned bus.
2. The user login to the system.
3. The user select profile.
4. The system display user information with the assigned bus.
5. The user view assigned bus.
6. Use case ends.
Alternative Course Of Action
A. No bus is assigned.
A4. The system displays no bus is assigned message.
62
 A5. Use case ends
Table : Use case documentation for view assigned bus
Use Case name: Add route
Use Case ID: Suc-013
Description: This use case allows the user to add route in the system.
Pre-condition: The user must be logged into the system with appropriate permissions.
Post-condition: The user has successfully added a route.
Actor: Admin
Include: Login
Extend:
Basic Course of Action
1. The admin wants to add route.
2. The admin access route management page.
3. The admin select add route.
4. The system display route registration form.
5. The admin fill the form and submit.
6. The system checks the form.
7. Route added successfully.
8. use case ends
Alternative Course Of Action
A. The form is invalid.
A2. The system displays a message indicating the information in the form is invalid.
A3. Use case continues from BCA-5.
Table : Use case documentation for add route
Use Case name: Add station
Use Case ID: Suc-014
Description: This use case allows the user to add station in the system.
Pre-condition: The user must be logged into the system with appropriate permissions.
Post-condition: The user has successfully added a station.
Actor: Admin
Include: Add route
Extend:

63
 Basic Course of Action
1. The user wants to add station.
2. The user access route management page.
3. The user select Station.
4. The system display station registration form.
5. The user fill the form and submit.
6. The system checks the form.
7. Station added successfully.
8. use case ends
Alternative Course Of Action
A. The form is invalid.
A2. The system displays a message indicating the information in the form is invalid.
A3. Use case continues from BCA-5.
Table: Use case description for add station
Use Case name: Receive notification
Use Case ID: Suc-015
Description: This use case allows the passenger to cancel their reservation in the bus track system.
Pre-condition: The passenger must have an existing reservation in the bus track system.
Post-condition: The reservation is successfully cancelled in the bus track system.
Actor Passenger
Include:
Extend:
Basic course of action
1. The user wants to receive notification.
2. The user opens the app.
3. The user selects specific bus.
4. The user enables “notify me” feature.
5. The system send notification when the bus is approaching.
6. The user receives notification.
7. use case ends
Alternative Course Of Action
A. The user does not enable “notify me” feature.
A6. The user does not receive notification.
A7. Use case ends.

Table : Use case documentation for receive notification

Use Case name: Logout
Use Case ID: Suc-016
Description: This use case describes the process of logging out from the system.
Pre-condition: The user must be logged in to the system

64
 Post-condition: The user is logged out of the system and their session is terminated.
Actor: Admin, Manager, Driver, Ticketer, Passenger
Include: Login
Extend:
Basic course of action
1. The user selects the "Logout" option from the system's user interface.
2. The system displays a confirmation message asking the user if they want to log out.
3. The user confirms their intention to log out.
4. The system terminates the user's session and clears any user-specific data.
5. The system redirects the user to the login page.
6. use case ends
Alternative course of action
A. The user cancels the logout process
A2. The system returns to the previous state and the user remains logged in.
A3. Use case continues from use case 1 of BCA.
Table: Use Case Description for Logout

3.5.2 Sequence Diagram

A sequence diagram is an interaction diagram that details how operations are carried out in a
system; it is used primarily to show the interactions between objects in the sequential order that
those interactions occur.
Register staff

Figure Register staff sequence diagram

65
 Delete staff

Figure 10:Login sequence diagram

Add bus

66
Figure : Add bus sequence diagram
Update bus

67
Figure : Update bus sequence diagram
Delete bus

68
Figure : Delete bus sequence diagram
Assign bus

69
Figure : Assign bus sequence diagram
Login

70
Figure :Login sequence diagram
Track bus

71
Figure :Track bus sequence diagram
View report

72
Figure : View report sequence diagram
Registering passenger

Figure: Registering passenger sequence diagram

Update passenger number
73
Figure :Update passenger number sequence diagram
View assigned bus

74
Figure :View assigned bus sequence diagram

Add route

Figure :Add route sequence diagram

Add station

75
Figure :Add station sequence diagram

Receive notification

Figure :Receive notification sequence diagram

Logout

76
Figure :Logout sequence diagram

3.5.2 Activity Diagram

77
Figure: Register staff activity diagram

78
Figure: Register route activity diagram

79
Figure: Track bus activity diagram

80
Figure: Login activity diagram

81
Figure: Add route activity diagram

82
 Chapter Four
System Design
4.1 Introduction
System design is the process of designing the element of a system such as the architecture, module
and component, the different of those components and the data that given through that system. The
purpose of this process is to provide sufficient detailed data and information about the system and
its elements to enable an implementation consistent with the model and views of the system
architecture.
Some of graphical modeling language are:
a. Flowchart: is a diagrammatic representation of a problem or a problem or algorithm that
illustrates the sequence of operation to be performed.
b. Unified modeling language (UML): is a standardized modeling language consisting of an
integrated set of diagrams, developed to help system and software developers for
specifying, visualizing, constructing and documenting the artifacts of a system.
c. System modeling language (sysML): is a general-purpose graphical modeling language for
specifying, analyzing, designing and verifying complex systems. It provider graphical
representation with a semantic foundation for modeling system requirements. sysML is
used by system engineering applications.

4.2 System design goals

Design goals used are target for design work. These are typically agreed upon by stakeholders as
the criteria for comparing design alternative and evaluating design outcome. Some of the design
goals we have chosen are as follows:
 Usability: both the mobile application and web dashboard will have an easy-to-use
interface to make it easier for many people with a range of online experiences to
use them.
 Reliability and Availability: ensure high availability with minimal downtime
through robust server architecture. Implement failover mechanisms and
redundancy to handle server failures gracefully.

83
  Cohesion: both the mobile application and website follow a specific thematic
design to ensure any new feature added will follow a strict design procedure to
maintain consistency and familiarity.
 Portability: the mobile application will be compatible with android platforms
granting user groups access.
 Real-time tracking: the app should provide user with real-time information on bus
locations and estimated arrival times. This allow user to plan their journeys more
effectively.
 User-friendly interface: the app should have an intuitive, easy-to-navigate interface
that allows user to quickly access the information they need.
 Performance and responsiveness: the app should be fast and responsive, providing
updates and information without significant delays.
 Customization: allowing user to customize their experience, such as saving
favorite routes or setting alert for specific buses, can enhance the user experience.
 Learnability: the system will follow a familiar UI design to ensure.

4.3 Design trade offs

Functionality vs. usability
We might not include complex functionalities at launch to ensure a high level of usability to ensure
a large user base.
Real-time Data vs. App Performance
Continuously pulling real-time data for bus locations can make the app more useful, but it can also
slow down app performance, especially on older devices. A balance between data refresh rate and
performance is necessary.
User Interface Complexity vs. Ease of Use
Offering many features like different map views, route options, and bus schedules can enhance the
app's functionality, but too many options can overwhelm users. Streamlining the interface for a
smooth, intuitive experience is important.
Privacy vs. Functionality
The app may require access to the user's location to provide personalized tracking and route
suggestions. Ensuring the app respects user privacy while offering the desired functionality is
essential.

84
Customization vs. Consistency
Allowing users to customize the app (e.g., favorite routes, notifications) can enhance user
satisfaction, but it may require additional complexity in app design and maintenance.
Data Sources vs. Data Quality
Using multiple data sources can improve the app's robustness and accuracy, but it may introduce
inconsistencies if the sources differ in data quality or timing.
Usability vs. Development Time
Streamlining the app for a smooth user experience may require additional development time to
optimize the app's functionality and performance.
Security vs. Convenience
Implementing secure authentication and data storage practices can protect user data but may also
add complexity to the user experience.
4.4 subsystem decomposition
System decomposition begins by decomposing the system into cohesive, well-defined subsystems.
Subsystem are then decomposed into cohesive, well-defined components. Components are then
decomposed into cohesive, well-defined sub-components. This allows for better maintenance and
scalability of the system as it is being built.
1. User Interface (UI) Subsystem:
- Manages the presentation layer of the app.
- Handles views such as maps, lists, and other visual elements.
- Enables user interactions like selecting routes, searching for stops, and setting preferences.

2. Data Management Subsystem:

- Responsible for handling bus route, schedule, and location data.
3. Real-time Tracking Subsystem:
- Tracks real-time bus locations and movements.
- Interfaces with external APIs or data sources to receive live updates.
- Processes real-time data and provides updates to the UI.
4. Navigation and Route Planning Subsystem:
- Helps users plan their journeys and find optimal routes.
- Offers directions, stop information, and estimated time of arrival (ETA).

85
 - Provides route suggestions based on user preferences and real-time data.
5. Notifications Subsystem:
- Manages alerts and notifications (e.g., bus arrival times).
- Can handle scheduling and sending push notifications.
6. Location Services Subsystem:
- Handles access to the device's location services.
- Provides the user's current location to the app for personalized tracking and navigation.
- Ensures user privacy and security when accessing location data.
7. Settings and Preferences Subsystem:
- Allows users to customize app settings (e.g., favorite routes, notification preferences).
- Manages the storage of user preferences and settings.
- Ensures user preferences are respected throughout the app.
8. Analytics and Reporting Subsystem:
- Gathers data on user interactions and app performance.
- Provides insights for improving the app based on user feedback.
9. Security and Privacy Subsystem:
- Ensures secure handling of user data and sensitive information.
- Implements user authentication and authorization mechanisms.
- Handles data encryption and secure communication with external services.
4.5 Design phase models
The design model is an object model describing the realization of use cases, and serves as
abstraction of the implementation model and its source code. The design model is used as essential
input to activities in implementation and test. Some of the design phase model include:
 class diagram
 persistence model
 user interface
 deployment diagram
 network diagram

4.5.1 Class diagram

Class diagram are one of six of structural diagram that are fundamental to the object modeling
process and model the static structure of a system. Depending on the complexity of a system, we

86
can use a single class diagram to model an entire system, or we can use several class diagram to
model the components of a system. We have chosen to use a single class diagram to model our
system since it has a rather low complexity.

Figure: class diagram

87
 4.5.2 Persistence model
The database we use (firestore) is firebase database that is suite of service, create a unified
experiences for our users across both the app and website, with shared data, authentication, and
functionality.
Firebase can certainly be used as part of the persistent model for a bus tracker android app,
particularly for storing and syncing real-time data such as bus location, routes and schedules.
Firebase is the perfect choice for the persistent model depends on the specific requirements and
constraints of your bus tracker app. It's important to consider factors such as scalability, cost, and
integration with other services when making this decision.

Figure: persistence model

88
 4.5.2.1 Mapping class diagram to relation
Mapping a class diagram to a relational model involves translating the classes, attributes, and
associations defined in a UML class diagram into tables, columns, and relationships in a relational
database schema.
To create a mapping class diagram to relations (tables) for the entities mentioned (Bus, Route,
Station, User, track, admin, feedback, manager, ticketer, driver), we can represent each entity as a
table in a relational database.
NO Table Name Columns

1 Bus Id(primary key), name, model, capacity, currentLocation, startTime,

endTime, isAvailable, plateNumber, assignedDriver, assignedRoute,
assignedStations, assignedTicketer, assignedStation, routeId(foreign
key)
2 Route routeID(primary key), name, EAT, endLocation, startLocation

3 Track ID(primary key), assignedBus, assignedBusPlate,

numberOfPassenger, startingForm, routeId(foreing key),
busId(foreign key)
4 User userId(primary key), Phone, username

5 Station Id(primary key), location, name, routeId(foreign key)

6 Admin Id(primary key), contactNumber, email, name, role

7 Feedback Feedback, timestamp, userId(foreign key)

8 Manager Id(primary key), address, contactNumber, email, name, role

9 Ticketer Id(primary key), address, assignedBus, assignedBusPlate,

contactNumber, email, name, role

89
 10 Driver Id(primary key), address, assignedBus, assignedBusPlate,
contactNumber, email, name, role, isOnline

Table: mapping class diagram to relation

4.5.2.2 Normalization
Normalization is the process of organizing data in a database efficiently. The goal of normalization
is to minimize redundancy and dependency by organizing data into tables and defining
relationships between them. This helps ensure data integrity and avoids data anomalies such as
update, insertion, and deletion anomalies.

First normal form

Rule for first normal form
 rule 1: single valued attribute
 rule 2: attribute domain should not changed
 rule 3: unique name for attribute(column)
 rule 4: order doesn’t matter

Second normal form

Rule for second normal form
 The table should be in the first normal form
 There should be no partial dependency (partial dependency, where an attribute in a table
depend on a part of the primary key and not on the whole key)

Third normal form

Rule for third normal form:
 It should be in the second normal form
 And it should not have transitive dependency (when a non-prime attribute depends on other
non-prime attribute rather than depending upon the prime attribute or primary key)

Bus:
Column name Data type

90
Id(primary key) string

Name string

Model String

Capacity number

currentLocation geoPonit

startTime TimeStamp

endTime TimeStamp

isAvailable boolean

plateNumber number

assignedDriver string

assignedRoute string

assignedStations array

assignedTicketer string

routeId(foreign key) string

Route:

91
 Column name Data type

routeID(primary key) string

Name string

EAT number

startLocation string

endLocation string

Station:
Column name Data type

ID(primary key) string

RouteID(foreign key) string

Location geoPoint

Name string

User:
Column name Data type

userID(primary key) string

92
Username string

phone number

Track:
Column name Data type

ID(primary key) string

assignedBus string

assignedBusPlate string

endTo string

numberOfPassenger string

startingForm string

Admin:
Column name Data type

ID(primary key) string

contactNumber number

email string

93
 Name string

Role string

Feedback:
Column name Data type

ID(primary key) string

UserID(foreign key) string

feedback string

timestamp TimeStamp

Driver:
Column name Data type

ID(primary key) string

address string

assignedBus string

assignedBusPlate string

contactNumber number

94
 Email string

IsOnline boolean

Name string

Role string

Manager:
Column name Data type

Id(primary key) string

Name string

Address string

Email string

contactNumber number

Role string

Ticketer:
Column name Data type

Id(primary key) string

95
 Name string

Email string

Address string

assignedBusPlate string

assignedBus string

contactNumber number

Role string

Table: normalization table

All table attribute directly related so there’s no transitive dependency. Therefore it is already in
3NF
4.5.3 User interface design
User interface (UI) design is the process designers use to build interface in software or
computerized devices, focusing on looks or style. Designers aim to create interface which users
find easy to use and pleasurable. UI design refers to graphical user interface and other

96
Figure: sign in mobile UI

Figure: SMS verification and registration mobile UI

97
Figure: home and bus station list mobile UI

Figure: bus information, tracking and sign out moblie UI

98
Figure: admin login web UI

Figure: driver list web UI

99
Figure: route list web UI

Figure: Track number of passenger web UI

10
0
Figure: feedback web UI

Figure: profile web UI

4.5.4 Deployment diagram

Deployment diagram illustrates how the software components of the app are deployed across

10
1
different nodes or hardware devices in a system. It shows the physical architecture of the system
and how the various components interact with each other.
1. Bus Tracking System:
-This is the overall system encompassing all components involved in the bus tracking application.
2. Mobile Device:
Android App:
-This is the application installed on the user's Android device.
-It allows users to track buses in real-time, see bus location, routes, and receive notifications.
-The app communicates with the backend API to fetch and display relevant data.
3. Server:
Backend API:
-This server-side component handles requests from the Android app and the GPS devices.
-It processes data, applies business logic, and interacts with the Firebase database to store and
retrieve data.
-It acts as a mediator between the mobile app, GPS devices, and the Firebase database.
4. Firebase:
Firebase Database:
-This is a cloud-based NoSQL database provided by Google.
-It stores all the data related to the bus tracking system, including user information, bus estimated
time, real-time bus locations, and administrative data.
-It provides real-time data synchronization making it suitable for mobile and web applications.
5. Bus:
GPS Device:
-Each bus is equipped with a GPS device that sends real-time location data.
-These devices communicate with the backend API using HTTP to transmit their location data at
regular intervals.
6. Admin Panel:
Web Application:
-This is a web-based interface used by administrators to manage the bus tracking system.
-It provides functionalities such as adding or removing buses, updating schedules, viewing
analytics, and managing user data.

10
2
-The admin panel interacts directly with the Firebase database to perform CRUD (Create, Read,
Update, and Delete) operations.

Figure: deployment diagram

4.5.5 Network design

Network design involves planning and implementing the infrastructure that enables
communication and data transfer between different components of a system or between different
systems. In the context of a bus tracker Android app, network design involves designing the
network infrastructure to support communication between the app's client-side (Android devices)
and server-side components (backend server, database server, etc.).
1. Client Devices (Android Devices):
- These are the mobile devices (such as smartphones and tablets) running the bus tracker Android
app.

10
3
 - Key elements: Mobile network connectivity (3G, 4G, 5G), Wi-Fi connectivity, GPS for
location tracking.
2. Backend Server:
- This is the server where the backend application logic of the bus tracker app resides.
- Key elements: Internet connectivity, sufficient processing power and memory, firewall and
security measures, load balancers for distributing traffic (if needed).
3. Database Server:
- This is the server where the data related to buses, routes, station, users, etc., is stored.
- Key elements: Database management system (NoSQL and Cloud firebase), sufficient storage
capacity, backup and recovery mechanisms, access control.
4. Bus Tracking Backend API:
- This is the backend API responsible for tracking buses' real-time locations and providing data
to the Android app.
- Key elements: Web server (Node.js), RESTful API endpoints, secure communication
(HTTPS), and scalability for handling concurrent requests.

Figure: Network design

10
4
Chapter Five - Implementation
5.1 Introduction
Software implementation can be defined as the process and producers needed to take software
application and tools from planning and development to the production stage. As such our team
has worked hard to use the tool at our disposal to turn the concepts elaborated in the previous
chapters into real world application that can benefit society. We have used a variety of
programming language such as flutter, dart and react, some integrated development environment
such as visual studio and cloud service such as firebase and a lot of internet research in the process
and in this chapter, you will find the result illustrated in the form of sample codes.
5.2 Sample Code
In this section we have include sample code for components of our mobile application and web
dashboard which are important and the sample codes can be found below.
Bus model
Description: The class is used to represent and manage information related to buses within an
Android app.
Parameter: id, name, bus number, plateNumber, capacity, isAvailability, startTime and endTimes,
numberOfPassenger, availableSite, startingForm and endTo.
Code:
import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:google_maps_flutter/google_maps_flutter.dart';

class BusInformationModel {
final String id;
final String? name;
final String? busNumber;
final String? plateNumber;
final String? capacity;
final bool? isAvailable;
final DateTime? startTime;
final DateTime? endTime;
final String? numberOfPassengers;
final String? availableSits;
final String? startingFrom;
final String? endTo;

LatLng? location;

10
5
 BusInformationModel({
this.location,
required this.id,
this.name,
this.busNumber,
this.plateNumber,
this.capacity,
this.isAvailable,
this.startTime,
this.endTime,
this.numberOfPassengers,
this.availableSits,
this.startingFrom,
this.endTo,
});

// Factory method to create a BusInformationModel instance from a Firestore

document
factory BusInformationModel.fromDocument(DocumentSnapshot doc) {
Map<String, dynamic> data = doc.data() as Map<String, dynamic>;
GeoPoint geoPoint = data['currentLocation'];
return BusInformationModel(
name: data['name'] as String?,
busNumber: data['model'] as String?,
plateNumber: data['plateNumber'] as String?,
capacity: data['capacity'] as String?,
isAvailable: data['isAvailable'] as bool?,
// startTime: (data['startTime'] as Timestamp?)?.toDate(),
//endTime: (data['endTime'] as Timestamp?)?.toDate(),
numberOfPassengers: data['numberOfPassengers'] as String?,
availableSits: data['availableSits'] as String?,
startingFrom: data['startingFrom'] as String?,
endTo: data['endTo'] as String?,
location: LatLng(geoPoint.latitude, geoPoint.longitude),
id: doc.id,
);
}

// Method to convert a BusInformationModel instance to a Firestore document

Map<String, dynamic> toDocument() {
return {
'name': name,
'busNumber': busNumber,
'plateNumber': plateNumber,

10
6
 'capacity': capacity,
'isAvailable': isAvailable,
'startTime': startTime != null ? Timestamp.fromDate(startTime!) : null,
'endTime': endTime != null ? Timestamp.fromDate(endTime!) : null,
'numberOfPassengers': numberOfPassengers,
'availableSits': availableSits,
'startingFrom': startingFrom,
'endTo': endTo,
};
}

// Method to create a copy of a BusInformationModel instance with updated

fields
BusInformationModel copyWith(
{String? name,
String? busNumber,
String? plateNumber,
String? capacity,
bool? isAvailable,
DateTime? startTime,
DateTime? endTime,
String? numberOfPassengers,
String? availableSits,
String? startingFrom,
String? endTo,
LatLng? location,
String? id}) {
return BusInformationModel(
name: name ?? this.name,
busNumber: busNumber ?? this.busNumber,
plateNumber: plateNumber ?? this.plateNumber,
capacity: capacity ?? this.capacity,
isAvailable: isAvailable ?? this.isAvailable,
startTime: startTime ?? this.startTime,
endTime: endTime ?? this.endTime,
numberOfPassengers: numberOfPassengers ?? this.numberOfPassengers,
availableSits: availableSits ?? this.availableSits,
startingFrom: startingFrom ?? this.startingFrom,
endTo: endTo ?? this.endTo,
id: id ?? this.id,
location: location ?? this.location);
}
}

10
7
Current_user model
Description: This class is likely used within an authentication system to manage the currently
authenticated user. It encapsulates information related to the user, such as their authentication
status and associated data.
Parameter: user
Code:
import 'package:bus_tracking_app_client/repos/auth_repo.dart';
import 'package:firebase_auth/firebase_auth.dart';

class CurrentUser {
final User? user;

CurrentUser(this.user);
}

Station model
Description: class represents a station with location information and an optional list of associated
buses
Parameter: location, name and bus
Code:
import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:google_maps_flutter/google_maps_flutter.dart';
import './bus_model.dart';

class StationModel {
final LatLng? location;
final String? name;
final List<BusInformationModel>? busses;

StationModel({this.location, this.name, this.busses});

// Factory method to create a StationModel instance from a Firestore document

factory StationModel.fromDocument(DocumentSnapshot doc) {
Map<String, dynamic> data = doc.data() as Map<String, dynamic>;

// Convert GeoPoint to LatLng

GeoPoint geoPoint = data['location'];
LatLng location = LatLng(geoPoint.latitude, geoPoint.longitude);

// Convert list of bus data to list of BusInformationModel

10
8
 return StationModel(
location: location,
name: data['name'] ?? '',
);
}

// Method to convert a StationModel instance to a Firestore document

Map<String, dynamic> toDocument() {
return {
'location':
GeoPoint(location?.latitude ?? 0.0, location?.longitude ?? 0.0),
'name': name,
'busses': busses?.map((bus) => bus.toDocument()).toList(),
};
}

// Method to create a copy of a StationModel instance with updated fields

StationModel copyWith({
LatLng? location,
String? name,
List<BusInformationModel>? busses,
}) {
return StationModel(
location: location ?? this.location,
name: name ?? this.name,
busses: busses ?? this.busses,
);
}
}

10
9
Chapter six - Conclusion and Recommendation

6.1 Conclusion

This project has met its conclusion as of 09/08/2024, As such the final deliverables have been
prepared, tested and examined and here are some conclusions we have arrived at:
 The system can only be useful if public buses are equipped with GPS or other tracking
technology to accurately monitor location and movement.
 The system can be expanded by ensuring accessibility to all users, including those with
disabilities, by incorporating features such as voice commands, screen readers and
alternative language options.
 We strongly believe that the system offer a multitude of benefits for both passengers and
transport companies by providing real-time information for passengers and transport
company can use data collected from the App to improve service quality and enhance
overall customer satisfaction.

6.2 Recommendation
We have some insight regarding the topic of our project. Here are our recommendations:
 When working on similar project, time management and effective communication are
essential for successful completion.
 We recommend, if possible, to work on projects like this with commitment to ensure the
highest quality outcome.
 The application should be continuously improved by gathering feedback and making
improvements to further enhance user experience.

11
0
Reference

11
1