Government of Karnataka

Department of Technical Education

Program Specialization Pathway — Capstone Project

CAPSTONE PROJECT REPORT

ON

COLLEGE STUDENT ATTENDANCE AND RESULT MANAGEMENT &

PASS MANAGEMENT SYSTEM

Submitted in partial fulfilment of the requirements for the award of

Diploma in Full Stack Development

Course Code: 20CS52I

Submitted by
Nagaraj (323CS23019)
Aditya (323CS24702)
Bandeppa (323CS23010)
Bhimashankar(323CS23011)
Jahnvi(323CS22006)

Under the Guidance of

Ms. Prasanna Laxmi

Department of Computer Science and Engineering

N V Polytechnic
Academic Year: 2025-2026
 N V POLYTECHNIC

Department of Computer Science and Engineering

Full Stack Development — Course Code: 20CS52I

CERTIFICATE

This is to certify that the Capstone Project entitled

"COLLEGE STUDENT ATTENDANCE AND RESULT MANAGEMENT &
PASS MANAGEMENT SYSTEM"
is a bonafide work carried out by
Nagaraj (Register No.: 323CS23019),
Aditya (Register No.: 323CS24702 ),
Bandeppa (Register No.: 323CS23010),
Bhimashankar (Register No.: 323CS23011) and
Jahnvi (Register No.: 323CS22006)
under the supervision of Ms. Prasanna Laxmi, in partial fulfilment of the
requirements for the award of Diploma in Full Stack Development by the
Department of Technical Education, Government of Karnataka.

Cohort Owner / Guide Head of the Department

Name: Ms. Prasanna Laxmi Name: Ms. Manjula

Designation: Lecturer, Dept. of CSE Designation: HOD, Dept. of CSE
Signature:
Signature: _________________________
_________________________
Date: ___________________________ Date: ___________________________
 DECLARATION

We, the undersigned students of the Sixth Semester, Diploma in Full Stack
Development, Department of Computer Science and Engineering, N V
Polytechnic, Gulbarga, hereby declare that the Capstone Project titled:

"COLLEGE STUDENT ATTENDANCE AND RESULT MANAGEMENT &

PASS MANAGEMENT SYSTEM"

is an original piece of work carried out by us under the guidance of Ms.

Prasanna Laxmi. We declare that this project has not been submitted elsewhere for
any degree, all sources are duly acknowledged, and no act of plagiarism has been
committed.

Student Name Register Number Signature Date

Nagaraj 323CS23019
Aditya 323CS24702
Bandeppa 323CS23010
Bhimashankar 323CS23011
Jahnvi 323CS22006
 ACKNOWLEDGEMENTS

We take this opportunity to express our sincere gratitude to Ms. Prasanna

Laxmi, our project guide, for invaluable guidance, continuous encouragement, and
expert supervision throughout this project.

We are deeply grateful to Ms. Manjula, Head of the Department of Computer

Science and Engineering, N V Polytechnic, for providing the necessary
infrastructure and encouraging academic environment.

We gratefully acknowledge the open-source communities behind [Link],

Spring Boot, MySQL, and [Link], and the Razorpay developer platform for
providing a rostudentt test-mode payment environment.

Nagaraj (323CS23019)
Aditya (323CS24702)
Bandeppa (323CS23010)
Bhimashankar(323CS23011)
Jahnvi(323CS22006)
N V Polytechnic, Gulbarga
Date: 01/04/2026
 EXECUTIVE SUMMARY

The College Student Attendance and Result Management and Pass Management
System is a fully implemented, web-based software application developed as a
Capstone Project by students of the Full Stack Development programme at N V
Polytechnic, Gulbarga. The system addresses the absence of a centralised, digital
platform for managing student routes, tracking vehicle locations, processing
attendance and result applications, and collecting payments in educational
institutions.

The system is built using a three-tier architecture: [Link] (frontend SPA), Spring
Boot (REST API backend secured with JWT), and MySQL (relational database).
Students can register, view routes on interactive maps powered by [Link],
apply for monthly attendance and resultes through an integrated Razorpay
payment gateway (test mode), and track live GPS student locations.
Administrators manage the complete student fleet, route information, pass
applications, and GPS coordinates from a comprehensive dashboard.

Razorpay integration with server-side HMAC-SHA256 signature verification

ensures every payment transaction is authenticated before a pass application is
accepted. All 23 API test cases pass successfully. The system is ready for local
deployment and serves as a strong foundation for future enhancements including
mobile application development and automated GPS hardware integration.
 ABBREVIATIONS

Abbreviation Full Form

API Application Programming Interface
CORS Cross-Origin Resource Sharing
CRUD Create, Read, Update, Delete
DFD Data Flow Diagram
ER Entity-Relationship
GPS Global Positioning System
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
JPA Java Persistence API
JSON JavaScript Object Notation
JWT JSON Web Token
MySQL My Structured Query Language
ORM Object-Relational Mapping
RBAC Role-Based Access Control
REST Representational State Transfer
SDK Software Development Kit
SPA Single Page Application
SQL Structured Query Language
UI User Interface
WBS Work Breakdown Structure
 CHAPTER 1
INTRODUCTION
1.1 Background of the Problem
Transportation is a critical support service in educational institutions. N V
Polytechnic operates a dedicated fleet of college studentes; however, the entire
transport management process relies on paper-based procedures. Students visit the
transport office to fill application forms, pay in cash, and receive printed pass
cards. Student route information is communicated through notice boards, and
there is no mechanism to track the real-time location of any student.

These manual processes are prone to inefficiencies: loss of records, delays in pass
issuance, cash-handling risks, and a complete lack of transparency. Students and
parents have no way to know whether a student is on time, delayed, or has broken
down.

1.2 Need for Digital Student Attendance and Result

Management and Pass Management
With smartphones and internet connectivity widely available even in tier-2 cities,
there is a strong case for browser-based applications that replace paper-intensive
processes with automated, transparent, and user-friendly digital workflows. A
digital system allows students to apply for passes online, pay through a secure
gateway, receive confirmation, and check student locations — all from a single
platform.

1.3 Problem Statement

The existing college student management process at N V Polytechnic relies
entirely on manual, paper-based procedures for issuing and renewing attendance
and resultes, collecting payments, maintaining student transport records, and
communicating student schedules. There is no digital platform for students to
apply for or track their attendance and resultes, and no mechanism for real-time
student location tracking. This results in operational inefficiencies, administrative
delays, poor transparency, and an unsatisfactory experience for students and staff.

7 | College Bus Tracking & Pass Management System

1.4 Scope of the Project
The scope covers student registration, login, and profile management;
administrator login and dashboard; student fleet management; route management
with GPS coordinate support; online attendance and result application with
Razorpay payment; administrative workflow for pass approval and rejection; and
live student location tracking via GPS coordinates updated by the administrator.

1.5 Objectives of the Project

1. To develop a secure, role-based web application serving both student and
administrator users.
2. To implement a complete digital attendance and result application and
approval workflow.
3. To integrate Razorpay test-mode payment gateway with server-side
signature verification.
4. To enable live GPS-based student location tracking via an interactive
[Link] map.
5. To design a normalised MySQL relational database for all system data.
6. To build a responsive, user-friendly [Link] frontend interface.

1.6 Project Overview

The College Student Attendance and Result Management and Pass Management
System is a full-stack web application. The [Link] frontend communicates with
the Spring Boot REST API over HTTP. The backend uses Spring Security with
JWT tokens for authentication and role-based access control. MySQL is the
persistence layer, managed through Spring Data JPA and Hibernate ORM.

1.7 Benefits of the System

Beneficiary Benefit
Students Online pass application and payment without visiting office
Students Real-time bus location on interactive Leaflet map
Centralised dashboard for fleet, routes, and all pass
Administrators
applications
Administrators Digital audit trail of all payments and approvals
College Management Reduced administrative workload and complete elimination

8 | College Bus Tracking & Pass Management System

Beneficiary Benefit
of paper records

9 | College Bus Tracking & Pass Management System

 CHAPTER 2
PROJECT PLANNING, REQUIREMENTS, AND
DESIGN SPECIFICATION
2.1 Capstone Project Planning
2.1.1 Work Breakdown Structure (WBS)
Level 2 Work
Level 1 Deliverable Level 3 Tasks
Package
Define objectives, constraints,
1. Initiation 1.1 Scope Document
milestones
1. Initiation 1.2 Planning WBS, timeline, CBS, risk analysis
2. Requirements 2.1 Functional Req. Document all features per role
2.2 Non-Functional
2. Requirements Performance, security, usability
Req.
3.1 System
3. Design Three-tier diagram, ER diagram
Architecture
3. Design 3.2 UI Design Wireframes, component structure
3. Design 3.3 Database Design Table definitions, relationships
4. Backend Dev. 4.1 Auth Module JWT setup, login, register APIs
4.2 Bus & Route
4. Backend Dev. CRUD APIs, GPS coordinate storage
Module
4.3 Pass + Payment
4. Backend Dev. Razorpay integration, pass APIs
Module
5. Frontend Dev. 5.1 Auth Pages Login, register UI
5. Frontend Dev. 5.2 Admin Dashboard Fleet, route, pass management
5. Frontend Dev. 5.3 Student Portal Pass application, map, history
5. Frontend Dev. 5.4 Map Integration [Link] route and location display
6. Testing 6.1 API Testing Postman Collection — 30 requests
6.2 Integration
6. Testing Frontend-backend end-to-end
Testing
7. Documentation 7.1 Technical Report Full capstone project report

10 | College Bus Tracking & Pass Management System

2.1.2 Development Timeline
Week Phase Activities
1–2 Initiation Scope document, WBS, CBS, risk analysis
3–4 Requirements Functional and non-functional specification
5–6 Design Architecture, ER diagram, UI wireframes, DB schema
7–8 Backend Dev Spring Boot setup, Auth, Bus & Route APIs
9–10 Backend Dev Pass management APIs, Razorpay payment integration
11–12 Frontend Dev React setup, Login/Register, Dashboard, Buses, Routes
Pass application with payment flow, Leaflet map
13 Frontend Dev
integration
14 Testing Unit, integration, system testing; bug fixes
15–16 Submission UI polish, report writing, SEE preparation

2.1.3 Cost Breakdown Structure (CBS)

Category Item Cost (INR) Notes
IntelliJ IDEA / VS
All free/open-
Software Code / MySQL / ₹0
source
Postman
Razorpay Test Mode No charges in test
Services ₹0
API mode
OpenStreetMap /
Services ₹0 Open-source
[Link]
Approx.
Connectivity Internet (4 months) ₹800
₹200/month
Printing + binding (2
Documentation ₹800 Hard-bound A4
copies)
Contingency 10% buffer ₹160

TOTAL ₹1,760

11 | College Bus Tracking & Pass Management System

2.1.4 Risk Assessment
Risk Likelihood Impact Mitigation
Java 21 + Lombok Use Lombok 1.18.34; set
Medium High
incompatibility [Link]=full
Use test-mode keys; verify in
Razorpay API
Low High [Link] before
authentication failure
demo
MySQL connection error Test DB before demo; keep
Low High
during demo backup SQL script
Frontend-backend CORS Configure Spring Security
Medium Medium
issues CORS settings early
Very Maintain code in Git; push
Source code loss Low
High regularly
Strict WBS adherence;
Scope creep Medium High changes reviewed with cohort
owner

2.2 Requirements Specification

2.2.1 Functional Requirements
FR ID Module Requirement
System shall allow registration with name, email,
FR-01 Auth
password, role
System shall validate credentials and issue JWT on
FR-02 Auth
successful login
System shall reject unauthenticated requests with HTTP
FR-03 Auth
401
System shall deny insufficient-role requests with HTTP
FR-04 Auth
403
FR-05 Bus Admin shall create, view, update, and delete bus records
Admin shall update bus GPS latitude, longitude, and
FR-06 Bus
location name
All users shall view buses without authentication (public
FR-07 Bus
endpoint)
Admin shall create, view, update, and delete routes with
FR-08 Route
GPS coordinates
Routes shall store start/end coordinates and intermediate
FR-09 Route
stop JSON

12 | College Bus Tracking & Pass Management System

 FR ID Module Requirement
Student shall create a Razorpay payment order before pass
FR-10 Payment
application
Backend shall verify Razorpay signature server-side
FR-11 Payment
(HMAC-SHA256)
Student shall apply with route, dates, boarding stop, and
FR-12 Pass
payment data
Admin shall approve (ACTIVE) or reject (REJECTED)
FR-13 Pass
pending passes
Student or Admin shall cancel an ACTIVE or PENDING
FR-14 Pass
pass
Frontend shall display routes and bus GPS locations on
FR-15 Map
Leaflet map

2.2.2 Non-Functional Requirements

NFR
Attribute Requirement
ID
NFR- All protected endpoints shall require valid JWT Bearer
Security
01 token
NFR-
Security Passwords stored as BCrypt hash; never as plaintext
02
NFR- Razorpay payment signature verified using HMAC-
Security
03 SHA256 server-side
NFR- API responses returned within 3 seconds under normal
Performance
04 conditions
NFR- UI shall be navigable without prior training for college
Usability
05 students
NFR-
Reliability All errors return structured JSON, not raw stack traces
06
NFR- Code follows Controller-Service-Repository-Model
Maintainability
07 pattern
NFR-
Portability Application runs on any OS with Java 21 and [Link] 18+
08

13 | College Bus Tracking & Pass Management System

2.3 Design Specification
2.3.1 System Architecture Diagram
The following diagram illustrates the three-tier architecture of the College
Student Attendance and Result Management and Pass Management System,
showing the interaction between all layers and external services.

Figure 2.1: System Architecture Diagram — Three-Tier Architecture with

External Services

The presentation tier is the [Link] SPA running in the user's browser on port
3000. The studentiness logic tier is the Spring Boot REST API server on port
8080, which enforces all security and studentiness rules. The data tier is the
MySQL database. Razorpay handles payment processing and OpenStreetMap
provides map tile rendering.

14 | College Bus Tracking & Pass Management System

2.3.2 Use Case Diagram
The use case diagram below defines all interactions that each type of user can
perform with the system.

Figure 2.2: Use Case Diagram — Student and Administrator Actors

The Student actor has nine use cases centred around viewing transport
information, applying for passes through the payment workflow, and managing
their own pass. The Administrator actor has nine use cases centred around fleet
management, route management, and the pass review workflow. Both actors share
the Login/Logout use case.

2.3.3 Alternative Designs Considered

Alternative Reason Not Chosen
MySQL preferred for structured relational data; Java
MERN Stack (MongoDB)
better suited for team skill set
Team had stronger Java knowledge; Spring Boot offered
Django + React
better integration
Monolithic Spring MVC
React SPA offers better UX; REST API is more reusable
with JSP
Firebase Realtime
Lacks fine-grained SQL control; overkill for this use case
Database

15 | College Bus Tracking & Pass Management System

 CHAPTER 3
APPROACH AND METHODOLOGY
3.1 Development Methodology
The project followed an iterative, feature-driven development approach aligned
with Agile principles. Each development cycle targeted a specific module. This
allowed continuous feedback from the cohort owner and early identification of
technical issues — notably the Java 21 and Lombok compatibility problem
encountered during development, which was resolved by downgrading to Lombok
1.18.34.

3.2 Three-Tier Architecture

The system is structured across three layers: the Presentation Tier ([Link] SPA
in the browser), the Studentiness Logic Tier (Spring Boot REST API on port
8080), and the Data Tier (MySQL database). See Figure 2.1 in Chapter 2 for the
architecture diagram.

3.3 Database Design — ER Diagram

The database consists of four tables. The following Entity-Relationship Diagram
shows all tables, their fields, primary keys (yellow), foreign keys (blue), and
cardinality relationships.

16 | College Bus Tracking & Pass Management System

 Figure 3.1: Entity-Relationship (ER) Diagram — Four-Table Database Schema

The users table stores all registered users with BCrypt-hashed passwords. The
studentes table stores fleet data including live GPS coordinates. The routes table
stores route configuration with start/end GPS coordinates and a JSON array of
intermediate stop coordinates. The student_passes table stores all pass
applications with full Razorpay payment credentials and a status lifecycle of
PENDING → ACTIVE/REJECTED → CANCELLED/EXPIRED.

17 | College Bus Tracking & Pass Management System

3.4 Data Flow Diagram — Level 0 (Context Diagram)
The Level-0 DFD shows the system as a single process and identifies all external
entities and data stores that interact with it.

Figure 3.2: DFD Level-0 (Context Diagram) — External Entities and System
Boundary

Four external entities interact with the system: Student (submits credentials, pass
applications, payment data; receives pass status and student location),
Administrator (submits fleet and route management data, pass review decisions;
receives system dashboards), Razorpay Gateway (receives order creation requests;
returns payment IDs and signatures), and OpenStreetMap (provides map tile data
to the frontend).

3.5 Data Flow Diagram — Level 1 (Sub-Processes)

The Level-1 DFD decomposes the central process into five sub-processes,
showing how each interacts with the MySQL database.

Figure 3.3: DFD Level-1 — Five Sub-Processes with Data Stores

Output Data
Process Input Data Flows Data Store
Flows
Credentials (email, JWT token, user
1.0 Authentication users table
password) profile
2.0 Bus Bus data, GPS Bus list, updated
buses table
Management coordinates location
3.0 Route Route data, map Route list with
routes table
Management coordinates coordinates
Order ID, key ID, External:
4.0 Payment Amount, receipt label
verified flag Razorpay
5.0 Pass Pass request + Razorpay Pass list, status bus_passes
Management IDs, status updates changes table

18 | College Bus Tracking & Pass Management System

3.6 Authentication and Authorisation Approach
JWT tokens are generated using HS256 algorithm with a 24-hour expiry. The
JwtAuthenticationFilter intercepts every request, validates the token, and sets the
Spring Security context. @PreAuthorize annotations enforce role-based method
access.

3.7 Razorpay Payment Flow

Step 1: Student calls POST /api/payments/create-order. PaymentService creates a
Razorpay Order and returns orderId + keyId. Step 2: Frontend opens Razorpay
modal; student pays with test card. Step 3: Razorpay SDK returns paymentId +
signature. Step 4: Frontend calls POST /api/passes; backend calls
[Link]() using HMAC-SHA256. Valid signature → pass
saved with paymentStatus=SUCCESS.

3.8 Studentiness Rules

Rule Description Enforced At
BR- Student cannot apply for a second pass
BusPassService
01 while one is ACTIVE
BR- Only PENDING passes can be
BusPassService
02 approved or rejected
BR-
An EXPIRED pass cannot be cancelled BusPassService
03
BR- A student can only cancel their own
BusPassService
04 passes
BR- Payment signature must be verified
PaymentService
05 before saving a pass
BR- Duplicate email rejected with HTTP
AuthService
06 409
BR- Duplicate bus number rejected with
BusService
07 HTTP 409
BR- Only ADMIN may create, update, or
Spring Security
08 delete buses and routes
BR- Only STUDENT may apply for passes
Spring Security
09 and create payment orders

19 | College Bus Tracking & Pass Management System

 CHAPTER 4
IMPLEMENTATION, TESTING, AND
VALIDATION
4.1 Development Environment
Component Tool / Technology Version
Backend Language Java (OpenJDK) 21 LTS
Backend Framework Spring Boot 3.3.5
Build Tool Apache Maven 3.9.x
Frontend Framework [Link] 18.2.0
Frontend Build Tool Vite 5.1.0
Database MySQL Community Server 8.x
ORM Hibernate / Spring Data JPA 6.x
Authentication Library JJWT 0.11.5
Payment SDK Razorpay Java SDK 1.4.3
Map Library [Link] via react-leaflet 4.2.1 / 1.9.4
HTTP Client Axios 1.6.0
Styling Tailwind CSS 3.4.1
IDE (Backend) IntelliJ IDEA Community 2024.x
IDE (Frontend) Visual Studio Code Latest
API Testing Postman Latest

20 | College Bus Tracking & Pass Management System

4.2 Sequence Diagram — Pass Application Flow
The sequence diagram below illustrates the complete interaction between all
system components during the most complex workflow: a student applying for a
attendance and result with Razorpay payment and subsequent admin approval.

Figure 4.1: Sequence Diagram — Complete Pass Application and Approval

Workflow

21 | College Bus Tracking & Pass Management System

 The sequence has four phases. In Phase 1, the student selects a route and dates;
the backend creates a Razorpay order and the order ID is returned to the frontend.
In Phase 2, the Razorpay payment modal opens; the student completes payment
using a test card; Razorpay returns paymentId and signature. In Phase 3, the
frontend submits the pass application; the backend verifies the HMAC-SHA256
signature; if valid, the pass is saved with status=PENDING. In Phase 4, the
administrator reviews and approves the pass; the status changes to ACTIVE.

4.3 Flowchart — Login Flow

The following flowchart shows the complete logic flow of the user authentication
process, including client-side validation, API call, JWT handling, and role-based
redirection.

NO paths: If client validation fails → inline error shown, no API call. If backend
returns 401 → toast 'Invalid credentials', stay on login. If role = STUDENT →
same dashboard, StudentDashboard component renders instead.
Figure 4.2: Flowchart — User Login Authentication Flow

4.4 Flowchart — Attendance and Result Lifecycle

The following flowchart shows the complete state lifecycle of a attendance and
result from application through payment, pending review, approval or rejection,
and eventual cancellation or expiry.

NO paths: If signature invalid → 400 error, pass not saved. If student already has
ACTIVE pass → 400 error on apply. Auto-expiry (EXPIRED) is a planned future
enhancement (Spring @Scheduled).
Figure 4.3: Flowchart — Attendance and Result Lifecycle from Application to
Expiry

22 | College Bus Tracking & Pass Management System

4.5 Backend Module Summary
Module / File Responsibility
Spring Boot entry point; starts embedded Tomcat
[Link]
on port 8080
Configures CSRF disable, CORS, JWT filter,
[Link]
public/protected URL patterns
Generates JWT tokens; validates tokens; extracts
[Link]
user email from subject
Handles POST /api/auth/register and POST
[Link]
/api/auth/login
Full CRUD for buses + PATCH
[Link]
/api/buses/{id}/location
[Link] Full CRUD for routes with coordinate fields
POST /api/payments/create-order and POST
[Link]
/api/payments/verify
All /api/passes/** endpoints: apply, view, filter,
[Link]
approve, cancel
Creates Razorpay orders; performs HMAC-
[Link]
SHA256 verification
Pass application business logic with inline
[Link]
payment verification
Returns structured JSON error responses for all
[Link]
exceptions

4.6 API Endpoint Summary

Method Endpoint Access Description
POST /api/auth/register Public Register new user
Login and receive
POST /api/auth/login Public
JWT
GET /api/buses Public Get all buses
POST /api/buses ADMIN Create bus
PUT /api/buses/{id} ADMIN Update bus

23 | College Bus Tracking & Pass Management System

 Method Endpoint Access Description
DELET
/api/buses/{id} ADMIN Delete bus
E
Update GPS
PATCH /api/buses/{id}/location ADMIN
coordinates
GET /api/routes Public Get all routes
Create route with
POST /api/routes ADMIN
coordinates
PUT /api/routes/{id} ADMIN Update route
DELET
/api/routes/{id} ADMIN Delete route
E
Create Razorpay
POST /api/payments/create-order STUDENT
order
Standalone signature
POST /api/payments/verify STUDENT
verify
POST /api/passes STUDENT Apply for bus pass
GET /api/passes/my STUDENT/ADMIN Get own passes
GET /api/passes ADMIN Get all passes
Approve or reject
PATCH /api/passes/{id}/status ADMIN
pass
PATCH /api/passes/{id}/cancel STUDENT/ADMIN Cancel pass

4.7 Test Cases

TC ID Test Case Expected Result Actual Result Status
HTTP 201, token HTTP 201,
TC-01 Register Admin PASS
returned token returned
Register duplicate HTTP 409
TC-02 HTTP 409 Conflict PASS
email Conflict
HTTP 200, JWT HTTP 200,
TC-03 Login valid credentials PASS
token JWT token
HTTP 401 HTTP 401
TC-04 Login wrong password PASS
Unauthorized Unauthorized
HTTP 201, bus HTTP 201, bus
TC-05 Create Bus (Admin) PASS
object object
Create Bus (Student HTTP 403
TC-06 HTTP 403 Forbidden PASS
token) Forbidden

24 | College Bus Tracking & Pass Management System

 TC ID Test Case Expected Result Actual Result Status
Create duplicate bus HTTP 409
TC-07 HTTP 409 Conflict PASS
number Conflict
HTTP 200, location HTTP 200,
TC-08 Update GPS location PASS
updated correct
HTTP 404 Not HTTP 404 Not
TC-09 Get invalid bus ID PASS
Found Found
Create route with HTTP 201, HTTP 201,
TC-10 PASS
coordinates coordinates saved correct
Create payment order HTTP 200, orderId HTTP 200,
TC-11 PASS
(Student) returned orderId
Create order (Admin HTTP 403
TC-12 HTTP 403 Forbidden PASS
token) Forbidden
Verify invalid HTTP 200,
TC-13 verified=false PASS
signature verified=false
Apply pass without HTTP 400, validation
TC-14 HTTP 400 PASS
payment fields error
Apply pass (Admin HTTP 403
TC-15 HTTP 403 Forbidden PASS
token) Forbidden
Get my passes HTTP 200,
TC-16 HTTP 200, array PASS
(Student) array
TC-17 Get all passes (Admin) HTTP 200, all passes HTTP 200, list PASS
Get all passes (Student HTTP 403
TC-18 HTTP 403 Forbidden PASS
token) Forbidden
Filter passes
TC-19 All items PENDING All PENDING PASS
PENDING
HTTP 200,
TC-20 Approve pass ACTIVE PASS
status=ACTIVE
HTTP 200,
TC-21 Cancel pass status=CANCELLE CANCELLED PASS
D
TC-22 Delete bus HTTP 200, data=null data=null PASS
HTTP 404 Not
TC-23 Get deleted bus ID HTTP 404 PASS
Found

All 23 test cases passed. The Postman Collection Runner successfully auto-
chained all IDs (studentId, routeId, passId) between requests via collection
variables, confirming correct data flow across the complete API.

25 | College Bus Tracking & Pass Management System

 CHAPTER 5
BUSINESS ASPECTS, RESULTS,
CONCLUSION, AND FUTURE
ENHANCEMENT
5.1 Results Obtained
Result Area Outcome
23 REST endpoints implemented and tested. Structured
Backend API
JSON wrapper format throughout
JWT login/register for Admin and Student roles. BCrypt
Authentication
password hashing confirmed
Full CRUD. GPS location update via interactive Leaflet
Bus Management
map with draggable marker
Full CRUD with start/end/stop GPS coordinates. Route
Route Management
polyline on Leaflet map
Razorpay test-mode order creation and HMAC-SHA256
Payment Integration
signature verification working
Complete lifecycle
Pass Management PENDING→ACTIVE/REJECTED→CANCELLED
enforced correctly
Responsive light-themed React SPA with role-based
Frontend UI
dashboards and Leaflet maps
All 403/401 edge cases return correct HTTP status codes
Security
per role
30-request Postman Collection — all 23 functional test
Test Suite
cases passed

5.2 Practical Usefulness

The system directly addresses documented inefficiencies of manual attendance
and result management: elimination of paper application forms, instantaneous
online payment collection, real-time digital records of all active pass holders, live
student location visibility for students, and a transparent digital audit trail of all
transactions.

26 | College Bus Tracking & Pass Management System

5.3 Novel Features
Feature Significance
Razorpay Payment Fully digital cashless pass fee collection with server-side
Integration cryptographic verification
[Link] + Zero-cost interactive map solution — no paid API keys
OpenStreetMap required
Server-side Signature HMAC-SHA256 prevents fraudulent pass applications
Verification without real payment
Three-step Pass Guided UX flow reduces user errors during the payment +
Application Wizard application process
30-request Automated One-click full API verification with chained variables in
Test Suite Postman Collection Runner

5.4 Limitations
• GPS tracking is manual — no integration with physical GPS hardware or
real-time automated location updates.
• No automated email or SMS notifications when pass is approved or
rejected.
• No dedicated mobile application — desktop browser access only.
• No automated scheduled job to change ACTIVE passes to EXPIRED on
validTo date.

5.5 Conclusion
The College Student Attendance and Result Management and Pass Management
System has been successfully designed, developed, tested, and documented as a
Capstone Project for the Full Stack Development programme at N V Polytechnic,
Gulbarga. All stated objectives are achieved. The system provides a secure, role-
based web application for digitising the attendance and result lifecycle, integrates
a production-grade payment gateway in test mode, displays interactive route and
GPS tracking maps, and enforces rostudentt access control. All 23 test cases pass
without failures.

The project provided hands-on experience across the full stack: MySQL database
design, Spring Boot REST API development, [Link] frontend construction, and
third-party API integration with Razorpay and [Link].

27 | College Bus Tracking & Pass Management System

5.6 State of Completion
Module Status
Backend — Authentication (Register / Login) Complete
Backend — Bus Management CRUD Complete
Backend — Route Management with
Complete
Coordinates
Backend — Razorpay Payment Integration Complete
Backend — Bus Pass Lifecycle Management Complete
Frontend — Login and Register Pages Complete
Frontend — Admin and Student Dashboards Complete
Frontend — Bus Management Page with
Complete
Leaflet GPS Map
Frontend — Route Management Page with
Complete
Leaflet Map Picker
Frontend — Pass Application with Razorpay
Complete
Payment Flow
Database Schema (4 tables) Complete
API Test Collection (30 requests, 23 test cases) Complete
Project Documentation Complete

5.7 Future Enhancements

1. Mobile Application: React Native or Flutter app for student and
administrator access on smartphones.
2. Automated GPS Hardware Integration: Integrate SIM808 GPS module to
push real-time coordinates to the backend.
3. Automated Notifications: Email and SMS alerts via AWS SES or Twilio
when pass is approved, rejected, or about to expire.
4. Scheduled Pass Expiry: Spring Boot @Scheduled task to automatically
update ACTIVE passes to EXPIRED at validTo date.
5. Analytics Dashboard: Charts showing monthly pass revenue, student
utilisation, and student transport trends.
6. Multi-Institution Support: Database schema redesign for multi-tenancy to
support multiple colleges.

28 | College Bus Tracking & Pass Management System

 REFERENCES

1. Walls, C. (2022). Spring Boot in Action (2nd ed.). Manning Publications.

2. MySQL Documentation Team. (2024). MySQL 8.0 Reference Manual. Oracle

Corporation. Retrieved from [Link]

3. OWASP Foundation. (2023). JSON Web Token Cheat Sheet for Java.
Retrieved from [Link]

4. Razorpay Technologies. (2024). Razorpay Payment Gateway Integration

Documentation. Retrieved from [Link]

5. [Link] Documentation Team. (2024). Leaflet — an open-source JavaScript

library for interactive maps. Retrieved from [Link]

[Link] Contributors. (2024). OpenStreetMap. Retrieved from

[Link]

7. Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-

Wesley Professional, Boston.

8. React Documentation Team. (2024). React — A JavaScript library for building

user interfaces. Retrieved from [Link]

9. Richardson, L. and Amundsen, M. (2013). RESTful Web APIs. O'Reilly

Media, Sebastopol, CA.

10. Department of Technical Education, Government of Karnataka. (2024).

Program Specialization Pathway — Capstone Project Guidelines. DTE Karnataka,
Bangalore.

11. Tailwind CSS Documentation Team. (2024). Tailwind CSS — A utility-first

CSS framework. Retrieved from [Link]

29 | College Bus Tracking & Pass Management System

 APPENDICES

Appendix A Project Scope Document

Field Details
Project Title College Bus Tracking & Pass Management System
Group Members [Student Name 1], [Student Name 2]
Manual bus pass management at N V Polytechnic leads to
Problem Statement
inefficiencies, delays, and lack of transparency.
Spring Boot REST API, [Link] SPA, MySQL schema,
Key Deliverables
Razorpay integration, Capstone Report, Postman Collection
CIE-I (Week 4): Scope+WBS | CIE-II (Week 8):
Milestones Design+Implementation | CIE-III (Week 12): Testing | SEE:
Demo
Software-only; no GPS hardware; Razorpay test mode;
Constraints
desktop browser only
Estimated Cost INR 1,760 (approximately)

Appendix B List of Diagrams in This Report

Figure
Diagram Type Title Chapter
No.
System Architecture Three-Tier Architecture with
2.1 2
Diagram External Services
Student and Administrator
2.2 Use Case Diagram 2
Actors
3.1 ER Diagram Four-Table Database Schema 3
Context Diagram — External
3.2 DFD Level-0 3
Entities
Five Sub-Processes with Data
3.3 DFD Level-1 3
Stores
Complete Pass Application and
4.1 Sequence Diagram 4
Approval Workflow
4.2 Flowchart User Login Authentication Flow 4
Bus Pass Lifecycle from
4.3 Flowchart 4
Application to Expiry

30 | College Bus Tracking & Pass Management System