AUTOMATED BUS SCHEDULING AND ROUTE

MANAGEMENT SYSTEM FOR DELHI TRANSPORT

CORPORATION

A PROJECT REPORT

Submitted by

ANUGRAHA P [RA2211030010138]
JOEL JACOB [RA2211030010182]

Under the Guidance of

DR. DAYANA D.S

(Assistant Professor, Networking And Communications)

in partial fulfillment of the requirements for the degree of

BACHELOR OF TECHNOLOGY
in
COMPUTER SCIENCE ENGINEERING
with specialization in CYBER SECURITY

DEPARTMENT OF NETWORKING AND COMMUNICATIONS

COLLEGE OF ENGINEERING AND TECHNOLOGY
SRM INSTITUTE OF SCIENCE AND TECHNOLOGY

KATTANKULATHUR- 603 203

MAY 2025
 Department of Networking and Communications
SRM Institute of Science & Technology
Own Work Declaration Form

Degree/ Course : [Link]/ Computer Sceince Engineering Specialization In

Cyber Security
Student Name : Anugraha P, Joel Jacob

Registration Number : RA2211030010138, RA2211030010182

Title of Work : Automated Bus Scheduling and Route Management System for
Delhi Transport Corporation

We hereby certify that this assessment compiles with the University’s Rules and Regulations
relating to Academic misconduct and plagiarism, as listed in the University Website, Regulations,
and the Education Committee guidelines.
We confirm that all the work contained in this assessment is our own except where indicated, and
that we have met the following conditions:
 Clearly referenced / listed all sources as appropriate

 Referenced and put in inverted commas all quoted text (from books, web, etc)

 Given the sources of all pictures, data etc. that are not my own

 Not made any use of the report(s) or essay(s) of any other student(s) either past or present

 Acknowledged in appropriate places any help that We have received from others
([Link] students, technicians, statisticians, external sources)
 Compiled with any other plagiarism criteria specified in the Course handbook /
University website

W e understand that any false claim for this work will be penalized in accordance with the University
policies and regulations.
DECLARATION:
We are aware of and understand the University’s policy on Academic misconduct and plagiarism and We certify that
this assessment is our own work, except where indicated by referring, and that We have followed the good academic
practices noted above.
RA2211030010138

RA2211030010182
 SRM INSTITUTE OF SCIENCE AND TECHNOLOGY
KATTANKULATHUR – 603 203
BONAFIDE CERTIFICATE

Certified that 21CSP302L - Project report titled “AUTOMATED BUS

SCHEDULING AND ROUTE MANAGEMENT SYSTEM FOR DELHI
TRANSPORT CORPORATION” is the bonafide work of “ANUGRAHA P
[RA2211030010138], JOEL JACOB [RA2211030010182]” who carried out the
project work under my supervision. Certified further, that to the best of my knowledge
the work reported herein does not form any other project report or dissertation on the
basis of which a degree or award was conferred on an earlier occasion on this or any
other candidate.

SIGNATURE SIGNATURE

DR. M. LAKSHMI
DR. DAYANA D.S
SUPERVISOR PROFESSOR & HEAD

Assistant Professor Department of

Networking and Communications Networking and Communications

ons ons

Examiner 1 Examiner 2
 ACKNOWLEDGEMENTS
We express our humble gratitude to Dr. C. Muthamizhchelvan, Vice-Chancellor, SRM Institute of
Science and Technology, for the facilities extended for the project work and his continued support.

We extend our sincere thanks to Dr. Leenus Jesu Martin M, Dean-CET, SRM Institute of Science and
Technology, for his invaluable support.

We wish to thank Dr. Revathi Venkataraman, Professor and Chairperson, School of Computing, SRM
Institute of Science and Technology, for her support throughout the project work.

We encompass our sincere thanks to, Dr. M. Pushpalatha, Professor and Associate Chairperson - CS,
School of Computing and Dr. Lakshmi, Professor and Associate Chairperson -AI, School of
Computing, SRM Institute of Science and Technology, for their invaluable support.

We are incredibly grateful to our Head of the Department, Dr. M. Lakshmi , Department of
Networking and Communications, SRM Institute of Science and Technology, for her suggestions and
encouragement at all the stages of the project work.

We want to convey our thanks to our Project Coordinators, Panel Head Dr. P. Visalakshi, Associate
Professor, and Panel Members Dr. G. Abinaya, Assistant Professor, Dr. G. Ramya, Assistant Professor,
Department of Networking and Communications, SRM Institute of Science and Technology, for their
inputs during the project reviews and support.

We register our immeasurable thanks to our Faculty Advisor, Dr. Gowri A.S, Department of
Networking And Communications, SRM Institute of Science and Technology, for leading and helping
us to complete our course.

Our inexpressible respect and thanks to our guide, Dr. Dayana D.S, Department of Networking And
Communications, SRM Institute of Science and Technology, for providing us with an opportunity to
pursue our project under her mentorship. She provided us with the freedom and support to explore the
research topics of our interest. Her passion for solving problems and making a difference in the world
has always been inspiring.

We sincerely thank all the staff members of Networking and Communications, School of Computing,
S.R.M Institute of Science and Technology, for their help during our project. Finally, we would like to
thank our parents, family members, and friends for their unconditional love, constant support and
encouragement

Anugraha P

Joel Jacob
 ABSTRACT
The Bus Scheduling System is an intelligent, web-based system that is scalable and meant to
upgrade the infrastructure supporting public transport planning and operations. Wherever bus
services are an integral part of daily commute in a region, the lack of automation creates
inefficiencies in the form of scheduling conflicts, underutilization of resources, and fragmented
route management. This project fills the gaps by providing a digital platform through which
transport authorities can outline routes, dispatch crews, operate schedules, and monitor
operations with accuracy and real-time visibility.

Developed on a solid technology stack—Python for backend processing and HTML/CSS for
the user interface—the system provides accessibility, performance, and compatibility across
platforms. Its modular design allows for seamless integration of emerging technologies such
as GPS tracking and predictive analytics, supporting ongoing infrastructure innovation. By
reducing manual intervention, the platform improves accuracy and operational consistency.

One of the main drivers of this project is to aid Sustainable Development Goal 9 (SDG 9):
Industry, Innovation, and Infrastructure, focusing on developing resilient infrastructure,
facilitating inclusive and sustainable industrialization, and encouraging innovation. The Bus
Scheduling System helps achieve this by automating conventional transit processes,
minimizing downtime, and optimizing resource allocation—setting the groundwork for more
intelligent, technology-led transport systems.

This framework is particularly important in facilitating the shift to smart urban and rural
transport networks. It utilizes real-time data collection and decision-making through the
system, allowing transport administrators to maximize fleet performance, minimize
bottlenecks in operations, and accommodate infrastructure expansion. Additionally, it sets a
model for scalable transport solutions in various industries, including school transportation,
industrial workforce shuttles, and intercity bus systems—hence stimulating innovation and
infrastructure development in mobility management

i
 TABLE OF CONTENTS

ABSTRACT i
TABLE OF CONTENTS ii
LIST OF TABLES v
LIST OF FIGURES vi

CHAPTER NO. TITLE PAGE NO.

1 INTRODUCTION

1.1 Introduction to Project 1

1.2 Motivation 2
1.3 Sustainable Development Goal of the Project 3
1.4 Product Vision Statement 3
1.5 Product Goal 5
1.6 Product Backlog (Key User Stories with Desired Outcomes) 6
1.7 Product Release Plan 7

2 SPRINT PLANNING AND EXECUTION

2.1 Sprint 1
2.1.1 Sprint Goal with User Stories of Sprint 1 8

2.1.2 Functional Document 11

2.1.3 Architecture Document 16

2.1.4 UI Design 19

2.1.5 Functional Test Cases 21

2.1.6 Daily Call Progress 23

2.1.7 Committed vs Completed User Stories 24

2.1.8 Sprint Retrospective 24

ii
 2.2 Sprint 2

2.2.1 Sprint Goal with User Stories of Sprint 2 26

2.2.2 Functional Document 30

2.2.3 Architecture Document 34

2.2.4 UI Design 37

2.2.5 Functional Test Cases 38

2.2.6 Daily Call Progress 40

2.2.7 Committed vs Completed User Stories 41

2.2.8 Sprint Retrospective 41

2.3 Sprint 3

2.3.1 Sprint Goal with User Stories of Sprint 3 42

2.3.2 Functional Document 46

2.3.3 Architecture Document 49

2.3.4 UI Design 52

2.3.5 Functional Test Cases 55

2.3.6 Daily Call Progress 57

2.3.7 Committed vs Completed User Stories 58

2.3.8 Sprint Retrospective 58

3. RESULTS AND DISCUSSIONS

3.1 Project Outcomes (Justification of outcomes and how they align 60

with the goals)

3.2 Committed vs Completed User Stories 62

iii
4 CONCLUSIONS & FUTURE ENHANCEMENT 63

REFERENCES 65

APPENDIX

A. PAPER COMMUNICATION PROOF 66

B. SAMPLE CODING 67

C. PLAGIARISM REPORT 72

iv
 LIST OF TABLES

CHAPTER NO TITLE PAGE NO.

1 1.1 Product backlog 7

2 2.1 User stories of sprint 1 9

2 2.2 Access level 16

authorization matrix.

2 2.3 Functional Test Case 23

2 2.4 Sprint retrospective 26

2 2.5 User stories of sprint 2 28

2 2.6 Access level 35

authorization matrix.

2 2.7 Functional Test case 40

2 2.8 Sprint retrospective 43

2 2.9 User stories of sprint 3 45

2 2.10 Access level 52

authorization matrix.

2 2.11 Functional Test case 58

2 2.12 sprint retrospective 61

v
 LIST OF FIGURES

CHAPTER NO. TITLE PAGE NO.

1 1.1 Release plan 8
2 2.1 User story 1 10
2 2.2 User story 2 11
2 2.3 User story 3 12
2 2.4 Architecture diagram 19
2 2.5 UI design for Home 21
Page
2 2.6 UI design for Routes 22
page
2 2.7 UI design for Crew page 22
2 2.8 Standup Meetings 25
2 2.9 Committed vs 26
Completed graph
2 2.10 User story 1 29
2 2.11 User story 2 30
2 2.12 User story 2 31
2 2.13 Sequence diagram for 37
sprint 2
2 2.14 UI design for stop 39
request via voice
2 2.15 UI design for Dynamic 40
stops page
2 2.16 Standup Meetings 42
2 2.17 Committed vs 43
Completed graph
2 2.18 User story 1 46
2 2.19 User story 2 47
2 2.20 User story 3 48

vi
2 2.21 Use case for sprint 3 54
2 2.22 UI design for Crowd 56
page
2 2.23 UI design for Heatmap 56
Integration
2 2.24 UI design for Maps 57
page
2 2.25 UI for Inspector 57
dashboard
2 2.26 Standup Meetings 60
2 2.27 Committed vs 61
Completed graph
3 3.2.1 Final Committed vs 65
Completed graph

vii
 CHAPTER 1

INTRODUCTION

1.1 Developing Transportation Infrastructure with Smart

Scheduling and Automation
With the accelerated urbanization and rising mobility needs of the time, modernizing public
transport infrastructure has become unavoidable. Conventional bus networks, though
extensively adopted, tend to suffer from inefficiencies in manual scheduling, rigid route
planning, and the absence of real-time tracking. Such inefficiencies create barriers to
operational productivity and contribute to underused resources and passenger discontent.

The Bus Scheduling System tackles these infrastructure constraints head-on with a centralized,
web-based platform that automates and optimizes planning, scheduling, and monitoring of bus
services. The system is specifically designed to support transport authorities, operators, and
planners by enabling users to set dynamic routes, assign buses and staff, control timetables,
and monitor fleet activity in real time. By digitizing the entire workflow, the platform fosters
transparency, enhances decision-making, and reduces human error, ultimately strengthening
the resilience of transit infrastructure.

Consistent with Sustainable Development Goal 9 (SDG 9): Industry, Innovation, and
Infrastructure, the project facilitates the growth of robust, sustainable, and technology-based
transport systems. It provides scalable digital infrastructure that optimizes operational
efficiency while facilitating innovation in mobility management. Its flexible architecture
positions it for use in a variety of use cases, such as school transport, industrial shuttles, and
public bus systems in urban and rural environments.

As urban and regional centers become integrated smart ecosystems, the Bus Scheduling System
helps construct smarter transportation networks—setting the stage for more resilient, equitable,
and visionary transit systems.

1
1.2 Motivation

The motivation behind developing the Bus Scheduling System stems from the growing
challenges faced by urban and semi-urban transportation networks. Public transportation
systems, especially buses, often rely on outdated manual scheduling methods that are prone to
inefficiency, delays, and miscommunication. These issues not only disrupt commuter
experiences but also lead to resource underutilization, increased operational costs, and
environmental concerns.

With the rapid growth of cities, traffic congestion and environmental sustainability have
become major concerns. As urban areas expand, efficient public transportation systems are
critical for reducing carbon footprints and promoting greener, more sustainable commuting.
However, without a centralized and automated system, managing bus routes, schedules, and
fleet resources becomes increasingly complex. This project is motivated by the need to create
a reliable, scalable, and automated solution that optimizes bus operations, minimizes delays,
and enhances the overall service for passengers.

Moreover, with urbanization, the expectation for modern and responsive transportation systems
has increased. Passengers today expect real-time updates, predictable service, and streamlined
operations. The Bus Scheduling System aims to meet these expectations by integrating
automation and data analytics to improve the accuracy and reliability of public transit, making
it a more attractive option for daily commuters. By addressing the fundamental issues of
manual scheduling and operational inefficiencies, the system seeks to foster a more sustainable
and effective urban transport ecosystem.

2
1.3 Sustainable Development Goal of the Project
The Bus Scheduling System plays an important role in supporting the United Nations
Sustainable Development Goal 9: Industry, Innovation, and Infrastructure, which aims at
developing resilient infrastructure, fostering inclusive and sustainable industrialization, and
encouraging innovation. In most urban and semi-urban cities growing in size, the growing need
for complexity in handling public transportation requires contemporary technology-based
solutions. This system provides a revolutionary solution by computerizing the entire route
management and scheduling process, thus streamlining operations and eliminating logistical
blockages.

Through the elimination of old, labor-intensive manual scheduling practices in favor of a

unified, automated system, the system reduces errors due to human interference and maximizes
the utilization of transport resources. This not only enhances the reliability and responsiveness
of public transport services but also encourages the growth of adaptive infrastructure that is
capable of adapting to changing urban dynamics. The system facilitates enhanced service
delivery and management of resources through its use of real-time tracking, dynamic stop
management, and voice input for accessibility—features that align with SDG 9's focus on
technological innovation in infrastructure.

Additionally, the project utilizes scalable software architecture developed using Python,
PostgreSQL, and web-based interfaces, supporting a cost-efficient and adaptable base that may
be deployed in different settings such as city fleets, school buses, or institutional transport
systems. Its modularity supports transport authorities in being able to scale operations
smoothly, add new routes, or implement additional features such as real-time crowd monitoring
and map-based analytics.

By promoting the use of intelligent systems in transportation planning and management, the
Bus Scheduling System captures the spirit of innovation mandated by SDG 9.

1.4 Product Vision Statement

1.4.1. Audience

 Primary Audience:
o Urban transport officials and city planners that require effective, scalable
solutions for public transport.

3
 o IT administrators that operate transit systems over growing urban areas.
 Secondary Audience:
o Commuters, students, and workers that depend on timely and consistent bus
transport.
o Public and private fleet operators such as schools, companies, and municipal
authorities.

1.4.2. Needs

 Primary Needs:
o Route planning and scheduling that is automated to minimize human error and
enhance efficiency.
o Real-time monitoring of fleets and stop request handling through dynamic and
voice-based inputs.
o Integrated dashboards to manage crew deployment and transit infrastructure.
 Secondary Requirements:
o Infrastructure scalable to accommodate growth in population and transit.
o Crowd reporting capabilities and map-based visualizations for routing
optimization decision-making.
o Usage trend, performance monitoring, and infrastructure planning analytics.

1.4.3. Products

 Core Product:
o Web-based route management and bus scheduling system with route creation
modules, crew management, dynamic stop requests, and real-time monitoring
of operations.
 Additional Features:
o Voice input accessibility and natural submission of stop requests.
o Heatmap creation from crowd reports for data-driven route optimization.
o PostgreSQL-supported database with Flask and SQLAlchemy integration for
scalable, modular backend.
o Mobile-responsive UI with interactive map visualizations and dashboards for
inspectors and admins.

4
1.4.4. Values

 Core Values:
o Innovation: Bringing smart scheduling and automation to transform public
transit infrastructure.
o Efficiency: Optimizing operations and reducing downtime through technology
and data-driven tools.
o Scalability: Building infrastructure that can scale with urban demand and
technological advancements.
 Differentiators:
o Automation First: Full digitization of scheduling and crew assignment with real-
time monitoring.
o Dynamic Input Handling: Combination of manual and voice-based stop request
systems.
o Insight-Driven Infrastructure: Utilizing crowd reports, heatmaps, and analytics
for better decision-making and service delivery.

1.5 Product Goal

The primary goal of the Bus Scheduling System is to create a highly efficient, automated, and
scalable platform that optimizes bus route management, reduces operational costs, and
improves commuter satisfaction in urban and semi-urban environments. The system is
designed to streamline the scheduling process, eliminating manual errors and inefficiencies,
while ensuring that buses run on time, at optimal capacity, and with minimal delays.

This system also aims to reduce traffic congestion and environmental impact by promoting the
use of public transportation over private vehicles. Through real-time tracking and data
analytics, it will provide valuable insights to transport authorities, allowing them to fine-tune
operations based on actual commuter demand, weather conditions, and traffic patterns.

Additionally, the system aspires to be highly adaptable, able to scale with growing urban
populations and integrate new technologies such as GPS tracking, mobile applications, and
predictive analytics. The ultimate goal is to contribute to the development of smart, sustainable
cities by providing a tool that can enhance both the efficiency and accessibility of public
transport networks.

5
Lastly, the Bus Scheduling System aims to be a user-centric platform that ensures ease of use
for both transport operators and commuters. By offering a seamless interface, real-time
updates, and proactive communication, it seeks to improve the overall transportation
experience, making public transit a reliable, eco-friendly, and preferred option for urban travel.

1.6 Product Backlog

Table 1.1 Detailed Product Backlog

[Link] User Stories of Automated Bus scheduling and Route management system
for Delhi Transport Corporation
#US 1 As an administrator, I want to authenticate users and assign roles to ensure proper
access control.

#US 2 As an admin, I want to create and manage bus routes to allocate buses effectively
and ensure efficient operation.
#US 3 As an admin, I want to automate and manage bus schedules, ensuring they are
aligned with peak times and demand.
#US 4 As an operator, I want to monitor bus locations in real-time to ensure buses are on
time and reroute if needed.
#US 5 As an operator, I want the system to optimize bus allocation to minimize idle time
and reduce fuel consumption.
#US 6 As a passenger, I want to receive real-time updates about bus arrivals and delays
via notifications.
#US 7 As an admin, I want a dashboard that shows key metrics to help me optimize routes
and monitor performance.

#US 8 As a passenger, I want to access the bus schedules and track buses through a mobile
app for convenience.

#US 9 As a passenger, I want to pay for my ticket digitally to avoid carrying cash and
streamline the process.
#US 10 As a passenger, I want to leave feedback about the service to help improve the
system.
#US 11 As an admin, I want the system to be scalable so that it can accommodate new
routes and vehicles as the city grows.

6
The product backlog of Automated Bus Scheduling and Route Management System for Delhi
Transport Corporation was configured using the MS planner Agile Board which is represented
in the following Table 1.1. The Product Backlog consists of the complete user stories of the
Application.

1.7 Product Release Plan

The following Figure 1.1 depicts the release plan of the project

Figure 1.1 Release plan of the Application

7
 CHAPTER 2

SPRINT PLANNING AND EXECUTION

2.1 Sprint 1

2.1.1 Sprint Goal with User Stories of Sprint 1

The goal of the first sprint was to establish the foundational structure of the project by
implementing core data models, creating the database schema using Flask-SQLAlchemy, and
enabling the basic functionality for route and crew management. This sprint focused on setting
up a stable backend with a simple user interface for managing route information and assigning
crew.

Table 2.1 Detailed User Stories of Sprint 1

[Link] Detailed User Stories

US #1 As an admin, I want a clean dashboard to manage different modules so that I can
easily navigate and monitor the system.
US #2 As an admin, I want to create and manage bus routes so that buses can follow
defined paths.
US #3 As an admin, I want to assign drivers and conductors to routes so that each bus route
has an associated crew

The given Table 2.1 represents the detailed user stories to be implemented for the Sprint 1.

8
Planner Board representation of user stories are mentioned below figures 2.1,2.2 and 2.3

Figure 2.1 User story for creating dashboard

9
Figure 2.2 User story for route management

10
 Figure 2.3 User story for assigning crew to different routes

2.1.2 Functional Document

[Link]. Introduction

The goal of the Bus Scheduling System project is to improve passenger experience, staff
allocation, and route administration in order to completely transform public transportation
management. Using speech technology and real-time data visualization, this all-inclusive

11
system focuses on putting important enhancements into route planning, dynamic stop
management, and crowd monitoring capabilities.

[Link]. Product Goal

This system's main objective is to improve bus operations' efficiency and expedite the process
of managing transportation resources, which will help achieve the larger goal of offering a
responsive, adaptable, and user-centric public transportation experience. In addition to
providing passengers with real-time information and the ability to request services, the system
will empower transport authorities to make data-driven decisions.

[Link]. Demography (Users, Location)

Users

• Transport Administrators: Responsible for route planning and system management

• Crew Members: Bus drivers and conductors who operate the vehicles

• Passengers: End-users of the public transport system

• System Operators: Technical staff who maintain and monitor the system

User Characteristics

• Diverse technical proficiency levels

• Various roles requiring different access permissions

• Range of devices used to access the system (desktop, mobile)

Location

• Target Location: Urban and suburban areas with established public transport networks

• Deployment Focus: Initially for single transport authorities with potential for multi-region
expansion

[Link]. Business Processes

The most important business processes are:

Route Management:

• Process for planning, designing, and changing bus routes

12
• Procedure for plotting stops, determining distances, and estimating travel times

• Workflow for approving and reviewing route changes

Crew Assignment:

• Process for assigning drivers and conductors to particular routes and shifts

• Procedure for monitoring staff availability and qualifications

• Workflow for managing shift changes and emergency staff reassignments

Stop Request Management:

• Process for receiving and assessing dynamic stop requests from passengers

• Procedure to approve/reject stop requests against operational viability

• Process of informing status to passengers and indicating on dashboard

Crowd Monitoring:

• Procedure for collating and interpreting reports of crowd level

• Workflow for visualization of crowd statistics onto maps and dashboard

• Workflow for adaptation of services by responding to crowds

[Link]. Features

This project focuses on implementing the following key features:

Feature 1: Route and Crew Management System

Description:

This module integrates the Route Management and Crew Management features into one
administrative tool. It offers an all-encompassing interface for transport administrators to
create, edit, and manage bus routes, each characterized by a distinct route ID, starting and

ending points, and in-between stops. At the same time, the system facilitates the assignment of
drivers and conductors to particular routes and shifts, as well as the storage of crucial crew
information like contact numbers, timetables, and allocated buses. All this is done in a
centralized manner for effective workforce planning and operational coordination.

13
User Story:

As a transport administrator, I want to establish and administer bus routes and allocate crew
members to particular shifts, so that the public transport services can be run smoothly and
efficiently.

Feature 2: Voice-Based Dynamic Stop Requests and Dashboard

Description:

This feature includes voice-activated dynamic stop requests for passengers to make stop
requests using mobile voice input. Voice inputs are filtered and shown separately from manual
inputs on a real-time admin dashboard. The dashboard shows details such as user ID, location
coordinates, timestamp, and current status of each request (pending/approved/rejected),
offering the ability for transport managers to review and manage them easily. This reduces
manual errors and enhances system responsiveness to dynamic passenger needs.

User Story:

As a rider, I would like to make bus stop requests via voice commands on my mobile device
so I can easily inform my destination. As an administrator, I would like to see and control all
incoming stop requests from one central dashboard so that I can instantly decide on route
adjustments.

Feature 3: Real-Time Crowd Reporting and Heatmap Visualization

Description:

This functionality allows travelers to report in real-time the crowd density at bus stops through
voice or button inputs. Every report is geotagged and saved in the database. The system
consolidates this information and displays crowd density using an interactive OpenStreetMap
and OpenRouteService APIs-powered heatmap. The heatmap enables planners to track
congestion levels and make informed decisions about frequency adjustments and capacity
planning based on real-time demand.

User Story:

As a passenger, I would like to report and see crowd levels at bus stops so that I can steer clear
of busy areas. As a transport planner, I would like to see crowd density throughout the network
in a heatmap so that I can make resource allocation and route optimization decisions.

14
[Link]. Authorization Matrix

Define the roles and their corresponding access levels:

Table 2.2 Access level Authorization Matrix

Role Access Level

System Administrator Full access to all system features and configuration settings

Transport Manager Access to route management, crew assignments, and analytical reports

Dispatcher Access to dynamic stop requests, crowd monitoring, and crew management

Driver/Conductor Limited access to assigned routes, schedules, and basic status updates

Passenger Access to crowd reporting, stop requests, and public information views

Guest User Limited access to public transport information only

The above given table 2.2 represents the Authorization Matrix for Sprint 1 with access given
to each roles.

[Link]. Assumptions

• The development environment and infrastructure will remain stable throughout the project
implementation.

• Mobile devices with voice input for stop requests and crowd reporting will be accessible to
users.

• The APIs of OpenStreetMap and OpenRouteService will continue to be available and have
their existing functionality.

• The transport authorities will ensure that there is accurate and current information regarding
existing routes and stops.

• Development team members have the required expertise and resources to carry out the
assigned development work.

• Proper testing will be done to provide voice recognition accuracy for varying accents and
environments.

• Internet connectivity will be widely available to the target deployment users.

15
2.1.3 Architecture Document

[Link]. Application

The Automated Bus Route Planning and Route Management System is built with a
microservices architecture, in which individual functionalities are encapsulated as independent,
loosely coupled services. This facilitates independent scaling, rapid deployment, and better
maintainability.

Important Microservices are:

 Route Management Service:

Handles creation, editing, visualization, and deletion of bus routes through OpenStreetMap
integration. Supports geographic mapping and route optimization.

 Crew Management Service:

Handles assigning drivers and conductors to routes and shifts, saves crew timetables, and
enforces rest and shift rules compliance.

 Voice-Based Stop Request Service:

Processes voice commands entered by riders for dynamic stop requests, screens them out
from manual inputs, and tracks their status (pending/approved/rejected) in real time.

 Stop Request Dashboard Service:

Provides an interactive admin dashboard to track, filter, and handle incoming stop requests,
coupled with real-time updates through APIs.

 Crowd Reporting Service:

Captures crowd level reports submitted by users (voice/button) and associates them with
particular bus stop locations for data collection and tracking.

 Heatmap Visualization Service:

Creates dynamic heatmaps via Leaflet and OpenStreetMap APIs to visualize crowd density
between bus stops for real-time decision-making.

16
[Link] System Architecture

The following figure 2.4 represents the System architecture diagram of the project. This
emphasizes all the features and functionalities included in the project which serves as a
backbone of the project.

Figure 2.4 System Architecture Diagram

17
[Link] Data Exchange Contract

Data Exchange Frequency:

 Real-Time Exchanges:
o Dynamic submission of stop requests and updating status.
o Instantaneous voice-based stop commands.
o Updating heatmaps and visualizing routes.
o Live dashboard interaction and filtering.
 Periodic Syncs:
o Crew shift and rest schedule syncing daily.
o Periodic aggregation of crowd levels for analytics and archival purposes.

Data Sets:

 Route Data:
o Contains route ID, source and destination, midpoints, and real-world
geolocation points retrieved from OpenStreetMap. Updated upon creation and
optimization of the route.
 Crew Data:
o Includes crew names, contact details, shift times, and bus allocations. Traded
during crew scheduling and schedule changes.
 Stop Request Data:
o Records request timestamps, user ID, location from GPS, voice/manual source,
and approved status. Handled in real-time for real-time stop management.
 Crowd Report Data:
o Bundles up reports associated with particular bus stops, such as timestamp, user
ID, and reported crowd level.

Mode of Exchanges (API, File, Queue, etc.):

 API:
o RESTful APIs manage frontend and backend communication.
o Route updates, crew assignments, and stop requests are transferred via secure
JSON-based REST APIs.

18
  Message Queues:
o Asynchronous execution of crowd reports, voice command interpretations, and
notification triggers is handled by services such as RabbitMQ or Celery
(Python).
 File-Based Exchanges:
o Bulk data (e.g., historic route data or crew shift data) is uploaded by admins
through CSV files for batch processing.

2.1.4 UI DESIGN

The following figures 2.5, 2.6 and 2.7 represents the UI Design for the Home page, Routes
page and Crew page with all data included.

Figure 2.5 UI Design for Home page

19
Figure 2.6 UI Design for Routes page

Figure 2.7 UI Design for Crew details

20
2.1.5 Functional Test Cases

Table 2.3 Detailed Functional Test Case

Steps to
Expected Actual More
Feature Test Case Execute Test Status
Output Output Information
Case

1. Navigate to
‘Route
Management’ New route is Validations
Route added
page. saved to the prevent
successfully,
2. Click ‘Add database and duplicate or
Route Add New appears on
Route’. shown in the Pass blank entries.
Management Bus Route dashboard
3. Enter route list with all Stop list
with correct
name, start, provided displayed in
route info.
end, and stops. details. correct order.
4. Click
‘Submit’.

1. Go to ‘Route
Management’.
2. Click ‘Edit’ Updated Auto-refresh
Changes
Edit on an existing route info is triggers after
Route saved, UI
Existing route. saved and Pass update. Route
Management updated with
Route 3. Update reflected in data verified
new data.
values. the table. in DB.
4. Click ‘Save
Changes’.

21
 Steps to
Expected Actual More
Feature Test Case Execute Test Status
Output Output Information
Case

1. Navigate to
‘Crew
Management’ Crew
Crew
page. member is Crew conflict
assigned
Allocate 2. Click linked to the validation
Crew successfully
Crew to ‘Assign Crew’. selected route Pass handled;
Management and shown in
Route 3. Select crew and shown in cannot double
allocation
member and the allocation assign.
table.
route. list.
4. Click
‘Assign’.

1. Attempt to
Error Shift clash
assign the same Error
Prevent message handling is
crew member triggered
Crew Crew shown; functional.
to two routes correctly; Pass
Management Shift second Alert shown
with assignment
Conflict assignment is via modal
overlapping prevented.
blocked. popup.
times.

1. Modify a
model field. Migration
Schema Migration
Database 2. Run flask db history logged
updated succeeded
Migration migrate. and verified.
System successfully and structure
with 3. Run flask db Pass Tested with
Setup without reflected
Flask- upgrade. PostgreSQL
affecting correctly in
Migrate 4. Verify locally and on
existing data. DB.
changes in deployment.
database.

22
 Steps to
Expected Actual More
Feature Test Case Execute Test Status
Output Output Information
Case

1. Add route or Flask routes

crew member correctly
Data added
from UI. serve UI data.
via frontend Sync
Backend- 2. Check Flask Testing with
System is reflected in successful
Frontend log and DB for Pass Postman also
Integration backend between UI
Link Test entries. confirmed
database and and backend.
3. View consistent
vice versa.
updated data on backend
page reload. behavior.

The table 2.3 given above represents the functional test case for Sprint 1 which includes all
the test cases to be performed on the implementation of Sprint 1.

2.1.6 Daily Call Progress

The below figure 2.8 depicts the details on the daily scrum meetings held for the Sprint 1
recorded on Onenote.

Figure 2.8 Standup meetings

23
2.1.7 Committed Vs Completed User Stories
The given figure 2.9 represents the comparison between committed and completed features of
Sprint 1.

Figure 2.9 Bar graph for Committed Vs Completed User Stories

2.1.8 Sprint Retrospective

Table 2.4 Sprint Retrospective for the Sprint 1

What ideas do you How should we take

What went well What went poorly
have action

Flask project was Original PostgreSQL Utilize a Dockerized Set up a Docker

configured connection was environment to Compose file with
successfully with having compatibility ensure standardized PostgreSQL and Flask
clean structure to problems with setups for services already
accommodate Windows development configured for local
modular expansion. environments. systems. development.

Attribute sharp Sustain sprint-by-sprint

GitHub was well There were merge
ownership over task allocation and
utilized for version conflicts while
certain enforce PR (Pull
control and developing the
files/modules to Request) checks prior to
collaboration. backend models and
minimize merges.

24
 frontend forms overlapping
simultaneously. changes.

Core route and crew Utilize a common

Refactor forms and
management Frontend was initially CSS stylesheet or
pages utilizing common
modules were inconsistent in styling utility-first
styles and components;
implemented with forms and making framework such as
establish UI standards
CRUD operations them responsive. TailwindCSS for
early on.
and validation. consistent design.

Document ER diagrams
Flask-SQLAlchemy Maintain a
Confusion regarding and include summaries
and Flask-Migrate changelog of
data model alterations of migrations in sprint
were properly set up migration scripts
under schema notes to ensure more
for smooth database and document
evolution. visibility and
migrations. model associations.
comprehension.

Backend and
frontend integration Time was under- Enhance estimation
Divide frontend
for display and estimated for frontend process by adding buffer
tasks into sub-
insertion of bus integration because of time and promoting peer
stories with defined
routes and crews Flask template walkthrough before
deliverables.
functioned as problems. implementation.
intended.

The above given table 2.4 represents the sprint retrospective for the Sprint 1. It includes all
the sprints to be reviewed after the successful implementation.

25
2.2 SPRINT 2

2.2.1 Sprint Goal with User Stories of Sprint 2

The objective of the second sprint is to introduce the voice-enabled stop request system and
dynamic stop request dashboard. This involves capturing user voice input, isolating it from
manual inputs, saving requests in a structured format, and allowing administrators to view,
approve, or reject them via a responsive web dashboard.

Table 2.5 Detailed User Stories of Sprint 2

S.
Detailed User Stories
No.

US As a passenger, I want to submit a stop request using voice so that I don't need to type
#1 on the go.

US As an admin, I want to view only voice-based stop requests so that I can ensure data
#2 integrity.

US As an admin, I want to approve or reject dynamic stop requests so that I can manage
#3 spontaneous changes.

The given Table 2.5 represents the detailed user stories to be implemented for the Sprint 2.

26
Planner Board representation of user stories are mentioned below figures 2.10, 2.11 and 2.12

Figure 2.10 User story for submit stop request via voice command

27
Figure 2.11 User story to view only stops requested in Dynamic Stops page

28
Figure 2.12 User story for enabling crew to manage and update status of stops

29
2.2.2 Functional Document

[Link]. Introduction

The goal of the Bus Scheduling System project is to improve passenger experience, staff
allocation, and route administration in order to completely transform public transportation
management. Using speech technology and real-time data visualization, this all-inclusive
system focuses on putting important enhancements into route planning, dynamic stop
management, and crowd monitoring capabilities.

[Link]. Product Goal

This system's main objective is to improve bus operations' efficiency and expedite the process
of managing transportation resources, which will help achieve the larger goal of offering a
responsive, adaptable, and user-centric public transportation experience. In addition to
providing passengers with real-time information and the ability to request services, the system
will empower transport authorities to make data-driven decisions.

[Link]. Demography (Users, Location)

Users

• Transport Administrators: Responsible for route planning and system management

• Crew Members: Bus drivers and conductors who operate the vehicles

• Passengers: End-users of the public transport system

• System Operators: Technical staff who maintain and monitor the system

User Characteristics

• Diverse technical proficiency levels

• Various roles requiring different access permissions

• Range of devices used to access the system (desktop, mobile)

Location

• Target Location: Urban and suburban areas with established public transport networks

• Deployment Focus: Initially for single transport authorities with potential for multi-region
expansion

30
[Link]. Business Processes

The most important business processes are:

Route Management:

• Process for planning, designing, and changing bus routes

• Procedure for plotting stops, determining distances, and estimating travel times

• Workflow for approving and reviewing route changes

Crew Assignment:

• Process for assigning drivers and conductors to particular routes and shifts

• Procedure for monitoring staff availability and qualifications

• Workflow for managing shift changes and emergency staff reassignments

Stop Request Management:

• Process for receiving and assessing dynamic stop requests from passengers

• Procedure to approve/reject stop requests against operational viability

• Process of informing status to passengers and indicating on dashboard

Crowd Monitoring:

• Procedure for collating and interpreting reports of crowd level

• Workflow for visualization of crowd statistics onto maps and dashboard

• Workflow for adaptation of services by responding to crowds

[Link]. Features

This project focuses on implementing the following key features:

Feature 1: Route and Crew Management System

Description:

This module integrates the Route Management and Crew Management features into one
administrative tool. It offers an all-encompassing interface for transport administrators to
create, edit, and manage bus routes, each characterized by a distinct route ID, starting and

31
ending points, and in-between stops. At the same time, the system facilitates the assignment of
drivers and conductors to particular routes and shifts, as well as the storage of crucial crew
information like contact numbers, timetables, and allocated buses. All this is done in a
centralized manner for effective workforce planning and operational coordination.

User Story:

As a transport administrator, I want to establish and administer bus routes and allocate crew
members to particular shifts, so that the public transport services can be run smoothly and
efficiently.

Feature 2: Voice-Based Dynamic Stop Requests and Dashboard

Description:

This feature includes voice-activated dynamic stop requests for passengers to make stop
requests using mobile voice input. Voice inputs are filtered and shown separately from manual
inputs on a real-time admin dashboard. The dashboard shows details such as user ID, location
coordinates, timestamp, and current status of each request (pending/approved/rejected),
offering the ability for transport managers to review and manage them easily. This reduces
manual errors and enhances system responsiveness to dynamic passenger needs.

User Story:

As a rider, I would like to make bus stop requests via voice commands on my mobile device
so I can easily inform my destination. As an administrator, I would like to see and control all
incoming stop requests from one central dashboard so that I can instantly decide on route
adjustments.

Feature 3: Real-Time Crowd Reporting and Heatmap Visualization

Description:

This functionality allows travelers to report in real-time the crowd density at bus stops through
voice or button inputs. Every report is geotagged and saved in the database. The system
consolidates this information and displays crowd density using an interactive OpenStreetMap
and OpenRouteService APIs-powered heatmap. The heatmap enables planners to track
congestion levels and make informed decisions about frequency adjustments and capacity
planning based on real-time demand.

32
User Story:

As a passenger, I would like to report and see crowd levels at bus stops so that I can steer clear
of busy areas. As a transport planner, I would like to see crowd density throughout the network
in a heatmap so that I can make resource allocation and route optimization decisions.

[Link]. Authorization Matrix

Define the roles and their corresponding access levels:

Table 2.6 Access level Authorization Matrix

Role Access Level

System Full access to all system modules, including dashboards and user
Administrator management

Transport Manager Approve/Reject stop requests, view heatmap, access operational reports

Monitor dashboard, manage stop requests, moderate voice/manual

Dispatcher
inputs

Passenger Submit stop requests, report crowd levels, view public transport info

Guest User Access to public route and crowd visibility information only

The above given table 2.6 represents the Authorization matrix for Sprint 2 with access given to
different roles.

[Link]. Assumptions

• The development environment and infrastructure will remain stable throughout the project
implementation.

• Mobile devices with voice input for stop requests and crowd reporting will be accessible to
users.

• The APIs of OpenStreetMap and OpenRouteService will continue to be available and have
their existing functionality.

33
• The transport authorities will ensure that there is accurate and current information regarding
existing routes and stops.

• Development team members have the required expertise and resources to carry out the
assigned development work.

• Proper testing will be done to provide voice recognition accuracy for varying accents and
environments.

2.2.3 Architecture Document

[Link]. Application

The Automated Bus Route Planning and Route Management System is built with a
microservices architecture, in which individual functionalities are encapsulated as independent,
loosely coupled services. This facilitates independent scaling, rapid deployment, and better
maintainability.

Important Microservices are:

 Route Management Service:

Handles creation, editing, visualization, and deletion of bus routes through OpenStreetMap
integration. Supports geographic mapping and route optimization.

 Crew Management Service:

Handles assigning drivers and conductors to routes and shifts, saves crew timetables, and
enforces rest and shift rules compliance.

 Voice-Based Stop Request Service:

Processes voice commands entered by riders for dynamic stop requests, screens them out from
manual inputs, and tracks their status (pending/approved/rejected) in real time.

 Stop Request Dashboard Service:

Provides an interactive admin dashboard to track, filter, and handle incoming stop requests,
coupled with real-time updates through APIs.

34
  Crowd Reporting Service:

Captures crowd level reports submitted by users (voice/button) and associates them with
particular bus stop locations for data collection and tracking.

 Heatmap Visualization Service:

Creates dynamic heatmaps via Leaflet and OpenStreetMap APIs to visualize crowd density
between bus stops for real-time decision-making.

[Link] System Architecture

The given figure 2.13 depicts the Sequence diagram for the sprint 2. This emphasizes all the
features and functionalities included in the Sprint with actors, lifelines and messages.

Figure 2.13 Sequence Diagram of Sprint 2

35
[Link] Data Exchange Contract

Data Exchange Frequency:

 Real-Time Exchanges:

o Dynamic submission of stop requests and updating status.

o Instantaneous voice-based stop commands.

o Updating heatmaps and visualizing routes.

o Live dashboard interaction and filtering.

 Periodic Syncs:

o Crew shift and rest schedule syncing daily.

o Periodic aggregation of crowd levels for analytics and archival purposes.

Data Sets:

 Route Data:

o Contains route ID, source and destination, midpoints, and real-world

geolocation points retrieved from OpenStreetMap. Updated upon creation and
optimization of the route.

 Crew Data:

o Includes crew names, contact details, shift times, and bus allocations. Traded
during crew scheduling and schedule changes.

 Stop Request Data:

o Records request timestamps, user ID, location from GPS, voice/manual source,
and approved status. Handled in real-time for real-time stop management.

 Crowd Report Data:

o Bundles up reports associated with particular bus stops, such as timestamp, user
ID, and reported crowd level.

36
Mode of Exchanges (API, File, Queue, etc.):

 API:

o RESTful APIs manage frontend and backend communication.

o Route updates, crew assignments, and stop requests are transferred via secure
JSON-based REST APIs.

 Message Queues:

o Asynchronous execution of crowd reports, voice command interpretations, and

notification triggers is handled by services such as RabbitMQ or Celery
(Python).

 File-Based Exchanges:

o Bulk data (e.g., historic route data or crew shift data) is uploaded by admins
through CSV files for batch processing.

2.2.4 UI Design
The following figure 2.14 and 2.15 depicts the UI design of requested stops made through
voice command and then saved in the dynamic stops page.

Figure 2.14 UI Design for Requesting stops through voice command

37
 Figure 2.15 Requested stops stored in Dynamic Stops Page for Crew

2.2.5 Functional Test Cases

Table 2.7 Detailed Functional Test Case

Steps to
Test Expected Actual
Feature execute test Status More Information
Case Output Output
case

1. Navigate
to ‘Dynamic
Stop Request’
Stop request
page. Stop request is
saved
2. Click on saved and
Submit correctly and Validations prevent
Dynamic ‘Add shown in the
Stop appears in blank or duplicate
Stop Request’. request Pass
Request dashboard entries. DB entry
Requests 3. Enter stop dashboard with
via UI with verified.
name and status
timestamp
preferred ‘Pending’.
and user info.
time.
4. Click
‘Submit’.

38
 Steps to
Test Expected Actual
Feature execute test Status More Information
Case Output Output
case

1. Open Voice request

Voice is
‘Voice Stop accepted,
parsed; stop
Request’ parsed
Submit name is Tested with
page. successfully,
Voice-Based Stop extracted and accented input.
2. Click on tagged as
Stop Request logged with tag Pass Invalid or silent
‘Record’. voice_input.
Requests via ‘voice_input’. audio triggers error
3. Speak the Displayed in
Voice Appears in message.
stop name. dashboard
admin
4. Click with proper
dashboard.
‘Submit’. status.

1. Go to
Admin Status
Dashboard. updated
Status changes
Approve 2. Filter by successfully, Tooltip shows user
to ‘Approved’,
Stop Request Voice ‘voice_input’ reflected and time info; map
and linked stop Pass
Management Stop tag. immediately refresh smooth and
is highlighted
Request 3. Click on UI. Map accurate.
on the map.
‘Approve’ shows stop
next to with icon.
desired entry.

1. Open
All stop Voice and
‘Dynamic
requests (UI & manual Tooltip shows
View Stop Map’.
voice) are requests metadata. Filtering
Map Stop 2. Ensure
shown as map shown with Pass by request type
Visualization Request stop requests
markers with unique icons; tested and
on Map exist.
color-coded statuses functional.
3. View stops
statuses. accurate.
marked on

39
 Steps to
Test Expected Actual
Feature execute test Status More Information
Case Output Output
case

the map with

status
indicators.

The following table 2.7 shows the detailed functional test cases implemented for the Sprint 2
which includes all the test cases to be performed on the implementation.

2.2.6 Daily Call Progress

The following figure 2.16 shows the daily scrum meetings held for the Sprint 2 and the
details are noted using Onenote.

Figure 2.16 Standup meetings

40
2.2.7 Committed vs completed user stories
The following figure 2.17 shows the comparison between committed and completed features
of the Sprint 2.

Figure 2.17 Bar graph for Committed Vs Completed User Stories

2.2.8 Sprint Retrospective

Table 2.8 Sprint Retrospective for the Sprint 2

What ideas do you How should we take

What went well What went poorly
have action

Voice input
Initial voice Implement a noise Use a noise cancellation
integration worked
recognition accuracy filtering or library or prompt user to
smoothly and was
was low for noisy confirmation step for confirm the recognized
parsed correctly in
environments. voice input. stop before submission.
most test cases.

Admin dashboard for Some delays in

Integrate geolocation Add optional dropdown
managing stop linking voice requests
or allow user to of nearby stops after
requests was to the correct bus stop
manually select stop voice recognition for
intuitive and easy to due to ambiguous
if ambiguity arises. confirmation.
use. names.

41
 What ideas do you How should we take
What went well What went poorly
have action

Map visualization of Map markers became Introduce clustering Use Leaflet marker
requests was visually cluttered when of map markers and clustering plugin to
appealing and multiple requests were zoom-based manage high-density
responsive. close together. expansion. visuals.

Unified data model Add real-time toast Implement frontend

Lack of user feedback
handled both manual notifications or notifications using Flask
on submission success
and voice requests confirmations after + JavaScript alerts or
led to confusion.
efficiently. submission. [Link].

Minor merge conflicts Assign ownership of Clearly divide frontend

Git collaboration and
due to concurrent specific UI responsibilities and
code review process
edits on admin panel components to enforce pull request
was effective.
files. individuals. discussions.

The above given table 2.8 represents the Sprint retrospective conducted for the Sprint 2. It
includes all the sprints to be reviewed after the successful implementation.

2.3 Sprint 3

2.3.1 Sprint Goal with User Stories of Sprint 3

The objective of the third sprint is the deployment of real-time monitoring of crowd sizes, data
visualization using interactive heatmaps, and completion of frontend development for an
integrated user interface. The aim of this sprint is to streamline usability and offer actionable
information through the Inspector Dashboard, with all modules presented in a uniform and
refined interface.

42
 Table 2.9 Detailed User Stories of Sprint 3

[Link] Detailed User Stories

US As a user, I want to report crowd levels at a bus stop so that others can make
#1 informed boarding decisions.

US As a user, I want to view a heatmap of crowd levels at stops so that I can plan less
#2 crowded routes.

US As an admin, I want to fetch bus stops using OpenStreetMap data so that I can create
#3 accurate routes.

The following table 2.9 represents the detailed user stories of the Sprint 3.

Planner Board representation of user stories are mentioned below figures 2.18, 2.19 and 2.20

Figure 2.18 User story for creating crowd levels

43
Figure 2.19 User story for integrating heatmap of crowd levels

44
Figure 2.20 User story for fetching routes based on the stops

45
2.3.2 Functional Document

[Link] Introduction

The Automated Bus Scheduling and Route Management System project seeks to streamline
urban public transport operations with intelligent data reporting and real-time crowd tracking.
During Sprint 3, the project seeks to improve commuter experience through enabling real-time
crowd reporting at bus stops, visualizing the same on interactive heatmaps, and enabling transit
inspectors to gain actionable insights through a separate dashboard. These enhancements seek
to make travel more efficient, informed, and user-friendly.

[Link] Product Goal

The main objective of Sprint 3 is to improve the current bus management platform by:

 Enabling real-time crowd reporting through voice and button inputs.

 Displaying congestion data on a dynamic heatmap.
 Enabling transit authorities with an Inspector Dashboard for making decisions.
 Integrating and refining the frontend UI across all modules.

[Link] Demography (Users, Location)

Users:

 Daily commuters traveling on public transport (bus stop users).

 Transit officials and administrators tracking and regulating bus stop usage.
 System maintainers and developers enhancing system stability.

User Characteristics:

 Different digital literacy levels.

 Multilingual and diverse socio-economic profiles.
 Usage through both desktop and mobile platforms.

Location:

 Initial deployment in urban areas (e.g., Delhi).

 Extendable to other areas with comparable transit infrastructure.

46
[Link] Business Processes

Real-Time Crowd Reporting:

 Commuters can report crowd levels with button presses or voice input.
 Reports are associated with particular bus stops with geolocation or manual selection.

Heatmap Visualization:

 Crowdsourced information is aggregated and visualized with intensity-based heatmaps.

 Heatmaps assist commuters with selecting less busy stops and routes.

Inspector Dashboard Monitoring:

 Inspectors can view a dashboard of highly congested stops.

 Allows sorting, filtering, and displaying timestamps of most recent reports.

Frontend UI Integration:

 A uniform visual style is used throughout all modules.

 Navbar and page transitions provide a unified user experience.

[Link] Features

This project focuses on implementing the following key features:

Feature 1: Real-Time Crowd Reporting

1. Description:

 Enables crowd level reporting through UI or voice.

2. User Story:

 As a user, I want to report crowd levels at a bus stop so that others can make informed
boarding decisions.

Feature 2: Heatmap Visualization

1. Description:

 Presents crowd levels across stops through dynamic heatmap rendering.

47
2. User Story:

 As a user, I'd like to see a heatmap of crowds at stops so that I can take less crowded
routes.

Feature 3: OpenStreetMap Stop Integration

1. Description:

 Retrieves precise bus stop coordinates using OSM APIs for route and stop mapping.

2. User Story:

 As an admin, I want to retrieve bus stops from OpenStreetMap data so that I can build
precise routes.

Feature 4: Inspector Dashboard

1. Description:

 A distinct dashboard for transport authorities to view and prioritize congested bus stops.

2. User Story:

 As an inspector, I want to see the most congested stops so that I can act accordingly.

Feature 5: Final Frontend Enhancements

1. Description:

 Consistent styling, responsive, and improved interactivity throughout all modules.

2. User Story:

 As a user, I want the platform to be seamless and visually intuitive, regardless of device
or module.

48
[Link] Authorization Matrix
Define the roles and their corresponding access levels:

Table 2.10 Access level Authorization Matrix

Role Access Level

Complete access to route information, crowd reports, stop

Administrator
mapping, and platform settings.

Dashboard view, heatmap, and real-time reporting

Inspector
analytics access.

Commuter/User Ability to submit crowd reports and see heatmaps.

May only see public crowd visualizations and system basic

Guest User
information.

The above given table 2.10 represents the Authorization Matrix for Sprint 3 with access given
to each roles.

[Link] Assumptions

 Crowd heatmap depends on regular and genuine commuter submissions.

 The APIs of OpenStreetMap will continue to be available for stop and route integration.
 Mobile responsiveness is essential since most consumers will access the platform
through smartphones.
 Transit authorities will utilize the Inspector Dashboard on a routine basis for field-level
decisions.
 Every system feature will adhere to privacy laws and data handling guidelines.

2.3.3 Architecture Document

[Link]. Application

The Automated Bus Route Planning and Route Management System is built with a
microservices architecture, in which individual functionalities are encapsulated as independent,

49
loosely coupled services. This facilitates independent scaling, rapid deployment, and better
maintainability.

Important Microservices are:

 Route Management Service:

o Handles creation, editing, visualization, and deletion of bus routes through
OpenStreetMap integration. Supports geographic mapping and route
optimization.
 Crew Management Service:
o Handles assigning drivers and conductors to routes and shifts, saves crew
timetables, and enforces rest and shift rules compliance.
 Voice-Based Stop Request Service:
o Processes voice commands entered by riders for dynamic stop requests, screens
them out from manual inputs, and tracks their status
(pending/approved/rejected) in real time.
 Stop Request Dashboard Service:
o Provides an interactive admin dashboard to track, filter, and handle incoming
stop requests, coupled with real-time updates through APIs.
 Crowd Reporting Service:
o Captures crowd level reports submitted by users (voice/button) and associates
them with particular bus stop locations for data collection and tracking.
 Heatmap Visualization Service:
o Creates dynamic heatmaps via Leaflet and OpenStreetMap APIs to visualize
crowd density between bus stops for real-time decision-making.

[Link] System Architecture

The following figure 2.21 represents the Use case diagram of the sprint 3. This emphasizes all
the features and functionalities included in the sprint with actors, use cases and relationships.

50
 Figure 2.21 Use case diagram of sprint 3

[Link] Data Exchange Contract

Data Exchange Frequency:

 Real-Time Exchanges:
o Dynamic submission of stop requests and updating status.
o Instantaneous voice-based stop commands.
o Updating heatmaps and visualizing routes.
o Live dashboard interaction and filtering.
 Periodic Syncs:
o Crew shift and rest schedule syncing daily.
o Periodic aggregation of crowd levels for analytics and archival purposes.

Data Sets:

 Route Data:
o Contains route ID, source and destination, midpoints, and real-world
geolocation points retrieved from OpenStreetMap. Updated upon creation and
optimization of the route.

51
  Crew Data:
o Includes crew names, contact details, shift times, and bus allocations. Traded
during crew scheduling and schedule changes.
 Stop Request Data:
o Records request timestamps, user ID, location from GPS, voice/manual source,
and approved status. Handled in real-time for real-time stop management.
 Crowd Report Data:
o Bundles up reports associated with particular bus stops, such as timestamp, user
ID, and reported crowd level.

Mode of Exchanges (API, File, Queue, etc.):

 API:
o RESTful APIs manage frontend and backend communication.
o Route updates, crew assignments, and stop requests are transferred via secure
JSON-based REST APIs.

 Message Queues:
o Asynchronous execution of crowd reports, voice command interpretations, and
notification triggers is handled by services such as RabbitMQ or Celery
(Python).
 File-Based Exchanges:
o Bulk data (e.g., historic route data or crew shift data) is uploaded by admins
through CSV files for batch processing.

2.3.4 UI Design
The following figures 2.22, 2.23, 2.24 and 2.25 represents the UI Design for the Crowd
reporting page, Crowd level heatmap page, map page for finding routes and Inspector
dashboard page for monitoring the status of busses with all data included respectively.

52
 Figure 2.22 Crowd reporting page

Figure 2.23 Crowd level integration using heatmap

53
 Figure 2.24 Map page for finding routes and other information

Figure 2.25 Inspector dashboard for monitoring the status of buses

54
2.3.5 Functional Test Cases

Table 2.11 Detailed Functional Test Case

Test Steps to Execute Expected More

Feature Actual Output Status
Case Test Case Output Information

Crowd report
1. Go to 'Crowd
saved, user Save Validation of
Report' page.
Submit ID tagged, successful, input
Crowd Crowd 2. Pick a bus stop. timestamp referencing complete.
Pass
Reporting Report 3. Pick crowd level marked, selected stop, Drop-down
(UI) (Low/Medium/High). viewable in proper level choices
admin and metadata. enforced.
4. Submit.
dashboard.

Voice parsed
1. Open 'Voice successfully,
Submit Crowd Report' page. crowd level Voice parsed Tested on
Crowd Crowd and stop successfully. various
2. Press 'Record'.
Reporting Report identified, Data saved Pass accents. Errors
3. Say: "Crowded at
(Voice) via report with location indicated for
[Stop Name]".
Voice recorded and crowd tag. poor audio.
4. Press 'Submit'. with voice
tag.

55
 Test Steps to Execute Expected More
Feature Actual Output Status
Case Test Case Output Information

1. Navigate to Heatmap
'Crowd Heatmap' shown with
Heatmap Simulated data
page. different
Display intensity is a tested. Color
Heatmap colors
Crowd 2. Make sure there good Pass scale
Visualization depending on
Heatmap are reports. representation calibrated and
crowd at
of data density. responsive.
3. Check intensity on stops. levels
map. at stops.

Reports
1. Launch 'Inspector
appear with Filters are
Dashboard'. Dashboard
View filter operational,
permits real-
Inspector and 2. Filter using crowd requirements, report
Pass time
Dashboard Filter level or stop. such as information is
refreshing and
Reports crowd level, presented
3. Look at detailed sorting.
location, and understandably.
list of reports.
timestamp.

1. Navigate across all

Smooth UI Smooth
modules.
behavior transitions,
2. Check consistent Dark mode
Unified between consistent
Frontend navbar, styling, tested. Mobile
UI pages. layout and Pass
Integration transitions. responsiveness
Testing Transitions buttons
3. Perform actions confirmed.
and styling between
(submit, view,
consistent. modules.
approve).

56
 Test Steps to Execute Expected More
Feature Actual Output Status
Case Test Case Output Information

Bus stop
1. Admin opens stop
coordinates Network
Retrieve management module. OSM data
and names errors
Bus retrieved
OpenStreetMap 2. Click 'Fetch from retrieved managed
Stops successfully Pass
Integration OSM'. from OSM gracefully
through and displayed
and with
API 3. View retrieved on map.
displayed in messages.
stops.
table.

The table 2.11 given above represents the functional test case for Sprint 3 which includes all
the test cases to be performed on the implementation.

2.3.6 Daily Call Progress

The below figure 2.26 depicts the details on the daily scrum meetings held for the Sprint 3
recorded on Onenote.

Figure 2.26 Standup meetings

57
2.3.7 Committed Vs Completed User Stories
The given figure 2.27 represents the comparison between committed and completed features
of Sprint 3.

Figure 2.27 Bar graph for Committed Vs Completed User Stories

2.3.8 Sprint Retrospective

Table 2.12 Sprint Retrospective for the Sprint 3

What ideas do you How should we take

What went well What went poorly
have action

Use a noise
Voice input integration
Initial voice Implement a noise cancellation library or
functioned well and
recognition accuracy filtering or prompt user to
was correctly parsed
was low for noisy confirmation step for confirm the
in the majority of test
environments. voice input. recognized stop
scenarios.
before submission.

Minor delays in Incorporate Include optional

Admin stop request
associating voice geolocation or dropdown list of
management
requests with the right provide option to nearby stops

58
 What ideas do you How should we take
What went well What went poorly
have action

dashboard was user- bus stop because of manually choose following voice
friendly and simple. similar names. stop if ambiguity recognition for
occurs. verification.

Visualization of Map markers got Implement clustering Implement Leaflet

requests on a map was congested when of map markers and marker clustering
pleasing to the eye and requests were close to expansion based on plugin to handle high-
interactive. each other. zoom. density visuals.

Have frontend
Single data model Absence of user Provide real-time
notifications done
managed voice and feedback upon toast notification or
through Flask +
manual requests submission success confirmation after
JavaScript alerts or
smoothly. resulted in confusion. submission.
[Link].

Minor merge conflicts Assign a specific UI Clearly separate

Git collaboration and
because of component's frontend work and
code review process
simultaneous editing ownership to the enforce pull request
was working.
on admin panel files. person. discussion.

The above given table 2.12 represents the sprint retrospective for the Sprint 1. It includes all
the sprints to be reviewed after the successful implementation.

59
 CHAPTER 3

RESULTS AND DISCUSSION

3.1 Project Outcomes

The "Automated Bus Scheduling and Route Management System for Delhi Transport
Corporation" was designed over three sprints, each with precise goals that align with SDG 9 –
Industry, Innovation, and Infrastructure, which focuses on developing resilient infrastructure,
fostering inclusive and sustainable industrialization, and encouraging innovation.

Every sprint increasingly worked on improving urban mobility infrastructure via digital
innovation, real-time responsiveness, and user interaction.

Sprint 1: Ground-Level Setup and Route Management

Outcome Explanation: This sprint built the technological and structural base by creating a
scalable backend, adding a strong database, and creating user interfaces for fundamental
modules. Automating route and crew management, the project started addressing SDG 9's
emphasis on robust and innovative transport infrastructure.

Major Outcomes:

 Flask-based backend infrastructure and GitHub versioning.

 Use of PostgreSQL with SQLAlchemy for effective data management.
 Functional UI for crew and route management with validation.

Alignment with SDG 9: This sprint brought innovation through the digitalization of
conventional scheduling practices, improving operational efficiency, and facilitating scalable
infrastructure development in public transport.

Sprint 2: Dynamic Stop Requests and Voice Input Integration

Outcome Justification: Within this sprint, the overall system transitioned from static
infrastructure to interactive and adaptive routing, enabling travelers using technology. Dynamic
stop requests and voice input spearheaded user-led innovation in harmony with SDG 9's pillar
of utilizing inclusive technologies for public services.

60
Key Outcomes:

 Manual and voice-controlled stop request feature.

 Admin interface for reviewing and approving dynamic requests.
 Map-based visualization of user-submitted requests via Leaflet.

Alignment with SDG 9: Through facilitating voice control and map-based dynamic routing,
the sprint promoted innovation in public transportation systems and enabled more responsive
and inclusive transport planning to real-time demand.

Sprint 3: Real-Time Crowd Reporting, Heatmaps & UI Improvements

Outcome Justification: This sprint pushed the system into smart city ground, utilizing real-time
crowd analytics and geospatial visualization to enhance travel decisions. The inspector
dashboard and responsive design further highlighted infrastructure modernization and public
resource monitoring.

Key Outcomes:

 Voice/manual input-based crowd reporting module.

 Heatmap visualization of crowd density for route planning.
 Integration with OpenStreetMap for precise stop data..

Alignment with SDG 9: This final dash reinforced urban infrastructure through the
establishment of intelligent and data-based decision-making instruments, sustainable
innovation promotion, and enhancement of access to public services through digital means.

61
3.2 Committed Vs Completed User stories
The figure 3.2.1 shows the comparison and ensures all the committed features are completed
successfully.

Figure 3.2.1 Committed vs Completed

62
 CHAPTER 4

CONCLUSION & FUTURE ENHANCEMENTS

4.1 Conclusion
Real-time management of public transport is a critical part of city infrastructure, particularly
in densely populated cities such as Delhi, where accessibility and efficiency have a direct
bearing on commuters. The Automated Bus Scheduling and Route Management System offers
a technologically advanced and intelligent system for optimizing transit by incorporating
digital stop requests, voice input processing, map displays, and real-time crowd monitoring.

With three intense development spurts, we were able to deploy key features like dynamic stop
request handling through both user interface and voice-based input, integration of
OpenStreetMap for live route plotting, and an easy-to-use admin dashboard for request and
crew management. In addition, we created a heatmap-based crowd visualization tool, allowing
passengers to make intelligent travel decisions based on stop congestion. The whole system
has been combined with a responsive and user-friendly frontend interface developed using
Flask and PostgreSQL as its backbone.

The system greatly enhances conventional manual scheduling practices by adding automation,
transparency, and user-provided feedback. Voice commands enable contactless interaction,
while visual feedback such as heatmaps on a digital map enhance planning and routing for both
passengers and the Delhi Transport Corporation.

4.2 Future Enhancements

 Though the present implementation creates a strong base for a smart transit solution,
some improvements can enhance its efficiency, accessibility, and scalability:
 IoT Integration: Installing IoT-capable sensors at stops can mechanize the measurement
of crowd sizes and bus arrival times, decreasing dependence on manual or user-
provided reports.
 Mobile Application Development: Developing a mobile app interface of the system
would give end-users real-time bus tracking, stop alerts, and the opportunity to report
on stops and crowd on the mobile.

63
 AI-Based Predictive Analytics: Usage of machine learning models could predict route
congestion or bus delays from historical data and thereby enhance schedules and alert
precision.
 Multilingual Voice Recognition: Extending the voice interface to accommodate
multiple regional languages would enhance accessibility for a wider audience.
 Smart Crew Allocation: Dynamically allocate crew members using AI, taking into
account route demand, historical performance, and availability, minimizing human
error and optimizing resource utilization.
 Integration with Other Transit Systems: Connecting the platform with metro, tram, or
shared mobility services can provide end-to-end multimodal transport planning for
users.
 By pursuing these future directions, the project can scale up from a university-level
prototype to a scalable, smart city solution, revolutionizing urban commuting through
data-driven automation, accessibility, and real-time insights.

64
 REFERENCES
1. Flask Documentation – Flask Web Framework for Python

[Link]

2. SQLAlchemy – SQL Toolkit and Object Relational Mapper

[Link]

3. Flask-Migrate – SQLAlchemy database migrations for Flask applications using Alembic

[Link]

4. PostgreSQL – Open-source relational database system

[Link]

5. OpenStreetMap – Collaborative mapping data for bus stop geolocation

[Link]

6. [Link] – JavaScript library for interactive map rendering

[Link]

7. [Link] – Plugin for clustering markers on Leaflet maps

[Link]

8. Web Speech API (SpeechRecognition) – Used for voice-based stop requests

[Link]

9. [Link] – Lightweight toast notification library for JavaScript

[Link]

10. HTML5, CSS3, JavaScript – Technologies used for frontend development

[Link]

11. United Nations Sustainable Development Goals (SDG 9) – Industry, Innovation and
Infrastructure

[Link]

65
 APPENDIX

A. PAPER COMMUNICATED PROOF

66
 B. SAMPLE CODING

B.1 Route Management Module

67
B.2 Dynamic Stop Request Handling

68
B.3 Crowd Reporting and Heatmap

69
70
B.4 Inspector Dashboard

71
C. PLAGIARISM REPORT

72
73
 Format - I
S R M I N S T I T U T E O F S C I E N C E A N D T E C H N O L O GY
(Deemed to be University u/ s 3 of UGC Act, 1956)

Office of Controller of Examinations

REPORT FOR PLAGIARISM CHECK ON THE DISSERTATION/PROJECT REPORTS FOR UG/PG PROGRAMMES
(To be attached in the dissertation/ project report)
1. ANUGRAHA P
Name of the Candidate (IN BLOCK
1
LETTERS)
2. JOEL JACOB

1. Sms Pg, Potheri

2 Address of the Candidate 2. Malligai Hostel, Srmist

1. RA2211030010138
3 Registration Number 2. RA2211030010182
1. 29/03/2004
4 Date of Birth 2. 29/09/2004

5 Department Networking and Communications

6 Faculty Engineering and Technology, School of Computing

Automated Bus Scheduling and Route Management

7 Title of the Dissertation/Project
System for Delhi Transport Corporation

Individual or group :
(Strike whichever is not applicable)

a) If the project/ dissertation is done in

Whether the above project /dissertation is group, then how many students together
8
done by completed the project : 2
b) Mention the Name & Register number of
other candidates :

RA2211030010138
RA2211030010182

Mail id: dayanad@[Link]

Name and address of the Supervisor / Mobile Number:9486951976
9
Guide

Name and address of Co-Supervisor /

10
Co- Guide (if any) Mail ID: -
Mobile Number:-
11 Software Used Turnitin

74
 12 Date of Verification 25/04/2025

13 Plagiarism Details: (to attach the final report from the software)

Percentage of Percentage of % of plagiarism

similarity index similarity index after excluding
Chapter Title of the Chapter (including self (Excluding self- Quotes,
citation) citation) Bibliography, etc.,

1
INTRODUCTION 4.62 4.62 4.6

2 SPRINT PLANNING AND 2.14 2.14 2.1

EXECUTION
3 RESULTS AND DISCUSSIONS 1.04 1.04 1.04

4 CONCLUSIONS AND 1.26 1.26 1.26

FUTURE
ENHANCEMENTS
5

10

Appendices

We declare that the above information have been verified and found true to the best of our knowledge.

Name & Signature of the Staff (Who

Signature of the Candidate uses the plagiarism check software)

Name & Signature of the Co-Supervisor/Co-

Name & Signature of the Supervisor/ Guide Guide

Name & Signature of the HOD

75