Project KNOT

Team

Supervisor

Table of Contents

  1. Introduction
  2. Solution Architecture
  3. Software Designs
  4. Testing
  5. Conclusion
  6. Links

Introduction

The Problem

Universities and large educational institutions often suffer from highly fragmented administrative systems. Currently, the processes for booking academic resources (such as lecture halls, labs, and seminar rooms) and reporting infrastructure faults are disconnected. This leads to severe coordination issues between students, academic staff (lecturers), administrative registries (AR), and maintenance technicians. The real-world consequences include double-booked lecture halls, untracked maintenance requests that take weeks to resolve, and a general lack of transparency regarding the status of requests.

The Solution

Project KNOT is a unified, centralized resource and maintenance management platform. It solves this fragmentation by offering a single, Role-Based Access Control (RBAC) ecosystem.

Solution Architecture

Project KNOT utilizes a modern, decoupled Client-Server Architecture to ensure scalability and maintainability.

Software Designs

3.1 User Interface (UI) Design

The system employs a “View-Based Navigation” architecture. Rather than building completely separate physical pages, the dashboards utilize dynamic component rendering to seamlessly switch between views (e.g., switching from “Pending Approvals” to “Room Management”). The UI relies heavily on conditional rendering to display specific tools based on the user’s role (Student, Lecturer, Booking Admin, Maintenance Admin).

3.2 Database Schema Design

The relational database is normalized into four primary tables:

3.3 Business Logic & Workflow Design

The core software design revolves around the Multi-Tier Endorsement Workflow.

  1. Initiation: Student creates a booking.
  2. Academic Filter: If an assigned_lecturer is tagged, the request sits in a Pending state visible only to that lecturer.
  3. Administrative Filter: Once the lecturer approves, the state shifts to Pending AR, passing it to the Booking Admin queue.
  4. Validation: The backend executes a strict conflict-prevention algorithm checking against existing Approved records for the same room and time before finalizing the booking.

Testing

Testing was conducted across multiple layers of the application to ensure a stable Minimum Viable Product (MVP).

Summarized Results

Conclusion

What Was Achieved

We successfully designed, developed, and deployed the MVP of Project KNOT. We transitioned a set of fragmented, disparate systems into a single, cohesive platform. We achieved our primary goal of establishing a secure, role-based ecosystem that handles complex academic booking workflows and real-time maintenance ticketing seamlessly.

Future Developments

While the MVP is fully functional, future iterations of Project KNOT will aim to include:

Commercialization Plans

Project KNOT’s flexible RBAC architecture makes it highly adaptable. Beyond our university, the platform can be white-labeled and licensed as a B2B Software-as-a-Service (SaaS) product. Target markets include other universities, large corporate campuses, or co-working spaces that require internal oversight for shared resources and facility maintenance.