Computer Lab Booking and Usage Analytics System for an Engineering College

LabBook is a web application that manages the booking of computer labs in an engineering college and, for the first time, measures how those labs are actually used. A typical college runs 10–14 labs of 30–70 machines each — programming, database, project and IoT labs — booked for classes, practical exams, workshops and placement training. Today that booking lives in a paper register or Excel sheet, so two faculty routinely arrive to find the same lab promised to both, evening slots go unused because nobody knows they are free, and the department buys machines with no utilisation data.

The system keeps a lab directory (capacity, machines, installed software), shows a weekly slot grid for every lab, and lets faculty request a slot online. The lab in-charge approves or rejects, and the system blocks any booking that clashes with the class timetable (imported from a CSV) or an approved booking. Because every booking is a database row, the analytics module can answer questions the register never could: utilisation per lab, busiest hours of the week, how much evening capacity sits idle, and whether the machine count matches demand.

It is built with Python and Django on MySQL — the Anna R2021 stack (CCS375 Web Technologies, CS3481 DBMS Lab) — with server-rendered HTML pages and Chart.js, an industry-standard charting library, for the dashboards. The scope is deliberately compact, which suits a beginner team: clean CRUD, one approval workflow and one analytics module, each fully implemented and defensible.

An engineering college with 12 computer labs and roughly 700 machines books labs through a register held by each lab in-charge. Because faculty cannot see the register, bookings are made by phone or visit, and clashes — two approvals for the same lab and slot — surface only when both batches arrive. Regular class timetables are not linked to the register, so ad-hoc bookings sometimes displace scheduled classes, and evening slots stay dark because nobody knows they are free. When the department requests new machines, it cites anecdotes, because no record of utilisation exists.

There is a need for a simple, role-based web application that maintains a lab directory, lets faculty book slots online, rejects clash-prone bookings automatically against both the class timetable and approved bookings, and converts booking history into utilisation analytics the HOD can use for timetabling and procurement.

Abstract

Computer labs are among the most expensive shared resources of an engineering college, yet most colleges still book them through a register kept by the lab in-charge. This causes double bookings, unused evening capacity and — most damaging — procurement decisions taken with no utilisation data. LabBook is a Django + MySQL web application that digitises lab booking with clash detection and produces usage analytics: utilisation per lab, peak hours, idle capacity and software-demand signals. Three roles use it: the HOD/admin who owns labs and reports, the lab in-charge who approves bookings, and faculty who request slots.

Introduction

Labs serve fixed class timetables and ad-hoc requests — remedial classes, project work, placement tests, workshops and practical-exam slots. The register cannot reconcile the two: it is not visible to everyone, it cannot warn about clashes, and it records bookings but not usage. The result is familiar to every department: a booked-but-empty lab while another turnaway happens next door, and a new-lab proposal justified by anecdote.

Existing System

• Bookings are entered in a physical register or a shared Excel file; faculty must physically visit or phone the lab in-charge.
• No clash detection: two approvals for the same lab and slot are discovered only when both groups arrive.
• The class timetable is not linked, so regular classes are sometimes displaced by ad-hoc bookings.
• Limitations: no central view, no conflict checks, no usage history, and no data to support budget requests or space planning.

Proposed System

• A lab directory with capacity, machine count and installed software, maintained by the admin.
• A weekly slot grid per lab; faculty raise booking requests with purpose and batch size.
• The lab in-charge approves or rejects; the system rejects any request that clashes with the class timetable (imported as CSV) or an already-approved booking — enforced in the database, not by vigilance.
• Usage analytics: utilisation percentage per lab and hour, peak-hour heatmap, idle evening capacity, and CSV export for department meetings.
• Role-based dashboards and email-style in-app notifications on approval decisions.

Feasibility Study

• Technical: Django, MySQL and HTML/CSS/JavaScript are all covered by CCS375 and CS3481, so the team builds on known tools. The app runs on any machine with Python 3.12 and MySQL 8, and SQLite mode makes first-run demos trivial.
• Economic: no licence cost; the college can host it on an existing server. It replaces paper, not paid software.
• Operational: the flow is request → approve → see it on the grid; faculty need no training, and the lab in-charge's work shrinks because clash checking is automatic.

In scope

• One college, up to ~15 labs; three roles (HOD/Admin, Lab In-charge, Faculty).
• Lab directory with capacity, machine count and installed software list.
• Weekly slot grid, booking requests, approval/rejection with a remark, cancellation.
• Class-timetable import from CSV and automatic clash rejection.
• Utilisation analytics per lab/hour with Chart.js dashboards and CSV export.

Out of scope (v1)

• Individual machine-level allocation and fault/maintenance tracking.
• Non-computer resources (seminar halls, projectors) — the schema leaves room but v1 targets computer labs.
• Single sign-on with the college LDAP and SMS/WhatsApp notifications.
• Mobile apps (the UI is responsive, server-rendered HTML).

The team follows the Incremental SDLC model — three small increments, each ending in something runnable that the guide reviews. The 12-week plan fits the CS3811 semester window (10 credits, ~300 periods of project work in Semester 8).

Testing approach: unit tests for the clash rules and utilisation maths; integration tests for the booking flow through Django's test client; and a black-box test table for each screen. The critical test is adversarial — two overlapping requests for the same lab/slot, where exactly one must win.

LabBook uses Django's MTV (Model–Template–View) pattern, a three-tier structure in which Django itself provides the application tier and the ORM is the only path to the database.

1. Presentation tier — server-rendered Django templates with HTML/CSS and a little vanilla JavaScript; charts are drawn client-side by Chart.js from JSON endpoints.
2. Application tier — Django views and forms enforce the roles and the clash rules; a transaction.atomic block plus a uniqueness constraint makes double booking impossible even under concurrent requests.
3. Data tier — MySQL through the Django ORM, with foreign keys and indexes on (lab, date, slot).

flowchart LR
  U["Browser: HOD / Lab In-charge / Faculty"] -->|HTTPS| V[Django views and forms]
  V --> R[Role and permission checks]
  R --> B[Booking rules - clash validation]
  B --> O[Django ORM]
  O --> DB[(MySQL)]
  V --> J[JSON endpoints]
  J --> C[Chart.js dashboards]

ER diagram

erDiagram
  USER ||--o{ BOOKING : requests
  USER ||--o{ BOOKING : "approves"
  LAB ||--o{ BOOKING : "is booked in"
  LAB ||--o{ CLASS_SLOT : hosts
  LAB ||--o{ LAB_SOFTWARE : "has installed"

  USER {
    int id PK
    string name
    string email UK
    string role
  }
  LAB {
    int id PK
    string name
    string block
    int machineCount
    string inChargeId FK
  }
  LAB_SOFTWARE {
    int id PK
    int labId FK
    string name
    string version
  }
  CLASS_SLOT {
    int id PK
    int labId FK
    string dayOfWeek
    int period
    string className
    string subject
  }
  BOOKING {
    int id PK
    int labId FK
    int requesterId FK
    date bookingDate
    int slot
    string purpose
    int batchSize
    string status
    string approverRemark
  }

Design points to defend in the viva: the class timetable (CLASS_SLOT) is kept separate from BOOKING because one is fixed by the department and the other is a request that changes state; the unique constraint on (lab, date, slot) among active bookings is the last line of defence against double booking; and utilisation is computed from stored bookings, so reports need no extra logging.

• Machine-level booking of individual systems for placement tests and certification exams.
• Maintenance/fault module so lab in-charges log broken machines, feeding a repair-priority list.
• LDAP/roll-number login and automatic user sync with the college records.
• WhatsApp/email notifications on approval and cancellation.
• Forecasting: predict next semester's demand per lab from this semester's bookings (a natural CS3361/pandas extension).
• Generalisation to seminar halls and projectors, turning LabBook into a college-wide resource scheduler.