Exam Timetable, Seating and Invigilation System with MySQL
Graph colouring for the timetable, a chessboard for the seating, and the measurement showing the shortest timetable is the cruellest one.
One-time purchase — source code, database, the written report and everything below, all in a single ZIP.
No account needed — pay & download instantly
Look inside the report
Showing the first 12 pages of 52. Tap any page to read it full size — this is the actual Word file you get, not a mock-up.
Screenshots
Tap any screenshot to open it full size. These are from the project actually running — not mockups.
About this project
An examination system that produces three things a college actually has to publish: a clash-free timetable, a seating plan for every room, and an invigilation duty chart. All three come out of one idea. Two papers conflict when at least one student sits both, so build that as a graph and colour it - each colour is a session, and no student can ever be in two rooms at once. Four colouring strategies are implemented from scratch: greedy, Welsh-Powell, DSATUR and simulated annealing. There is no scheduling library anywhere in it.
The project does not stop at "it works". It computes a lower bound from a clique in the conflict graph, so when DSATUR returns 16 slots and the bound is also 16, that is not a comparison against other heuristics - it is a proof that no timetable of any kind can be shorter. A fifth strategy is included deliberately broken: it schedules by semester the way a person would by hand, ignores the enrolments completely, and produces a timetable that is shorter than every correct one - 8 slots instead of 16 - while putting 1,868 students in two rooms at the same moment. It is on a dropdown so the comparison can be seen rather than claimed.
The central measurement is that the shortest timetable is the worst one for students. Colouring packs each branch-and-semester group into consecutive slots, because those papers are all mutually conflicting, so students end up sitting exam after exam. Measured: 2,557 back-to-back exam pairs. Rearranging the same papers inside the same 16 slots by simulated annealing brings that to 1,031 - 59.7% fewer, and the exam session is not one day longer.
Seating rests on a small piece of proof rather than shuffling. The seat grid's neighbour graph is bipartite, so colour it like a chessboard and two seats of one colour never touch; a paper whose students all sit on one colour therefore cannot have its own students adjacent. That makes zero violations a guarantee when the papers can be packed into the two colour classes - and it makes the impossible cases identifiable instead of silently bad. A paper with more than half a room's seats can never fit, and it is subtler than that: three papers of 12 in a 36-seat room each fit a colour class and still cannot be split 18 and 18, because it is a subset-sum, not just a pigeonhole. When packing fails the system says so and says why.
Invigilation produced the result that was most surprising. Duty goes to whoever has the fewest so far, so within an eligible pool it is even. Yet the college-wide spread stays wide, and the cause is the rule everyone agrees with - nobody invigilates their own department's paper. It runs backwards: the department setting 28 papers does 1.83 duties per teacher, while one setting 4 papers does 5.80. The department carrying the most examination load carries the least invigilation.
Every figure above is produced by one command and re-runnable from the admin panel, so nothing in the report has to be taken on trust. MySQL is used properly throughout: InnoDB with real foreign keys, a UNIQUE key that makes a duplicate enrolment impossible, another that makes two students in one seat impossible, and every query parameterised.
Features
- ✓Timetable, seating plan and duty chart, all from one conflict graph
- ✓Four colouring strategies written from scratch - greedy, Welsh-Powell, DSATUR, simulated annealing
- ✓A proven lower bound from a clique, so "optimal" is a proof and not a comparison
- ✓One strategy is deliberately broken and clashes on purpose, so the comparison can be seen
- ✓The broken one is shorter - 8 slots against 16 - and clashes 1,868 times
- ✓Measured: the shortest timetable gives students 2,557 back-to-back exams
- ✓Rearranging inside the same 16 slots cuts that to 1,031, at zero extra days
- ✓A clashing timetable is stored but can never be published - the guard is in the code, not the instructions
- ✓Clash report names the student, the two papers and the session
- ✓Seating by checkerboard packing, proven zero violations when packable
- ✓Exact subset-sum decides packability, so feasible and infeasible are told apart correctly
- ✓When zero is impossible the system says so and explains why, instead of quietly producing a bad plan
- ✓Papers are spread across rooms, because filling a room with one paper makes clean seating unreachable
- ✓Measured: mixing gave 0 violations in 4 rooms, one-paper-per-room gave 188 in 5
- ✓Invigilation balanced by load, never in your own department, never in two rooms at once
- ✓Measured: the own-department rule itself is the main source of unfairness, and it is inverted
- ✓Unfillable duties are reported rather than handed to someone ineligible
- ✓Slot numbers become real dates, and Sundays are skipped
- ✓Students get one page: date, session, room and seat number
- ✓Printable seating plans and duty charts
- ✓The five studies re-run from the admin panel and the numbers appear in front of you
- ✓No figure is typed into the report - all of them come from evaluation/results.json
- ✓Real AKTU subject codes, including papers shared by two branches
- ✓Backlog students modelled, because they are what makes the problem hard at all
- ✓REST API with X-API-Key for timetable, seating and a student's own schedule
- ✓MySQL with InnoDB, real foreign keys and ON DELETE CASCADE throughout
- ✓UNIQUE keys make a duplicate enrolment and a double-booked seat impossible
- ✓PBKDF2-SHA256 password hashing with a per-user salt
- ✓Every query parameterised; a SQL injection attempt is part of the test suite
- ✓54 automated self-tests you can run in front of the examiner
- ✓No CDN anywhere - the whole UI works with the internet switched off
Modules
Tools
- • Python 3.8+
- • Flask (web framework)
- • MySQL / MariaDB (XAMPP works out of the box)
- • PyMySQL (database driver)
- • Real AKTU subject codes (ship inside the project)
- • VS Code (or any editor)
- • Any web browser
Requirements
Python 3.8 or newer, and MySQL. XAMPP is the easiest way to get MySQL - install it, open the Control Panel and press Start next to MySQL. Then one command installs the libraries: pip install -r requirements.txt (Flask and PyMySQL, about 8 MB - there is no NumPy, no scheduling library and nothing to compile). The AKTU paper list ships inside the project, so there is nothing to download. The database, all its tables and the paper import happen automatically on first run - there is no .sql file to import. Works on Windows, Linux and Mac.
How to run
1. Extract the ZIP.
2. Start MySQL - open the XAMPP Control Panel and press Start next to MySQL.
3. Open CMD and go to the folder: cd path\to\exam-timetable-scheduler
4. Install the libraries: pip install -r requirements.txt
5. Check everything is ready: python check_setup.py
6. Load the demo data and build a timetable: python demo.py
7. Start the app: python app.py
8. Open http://127.0.0.1:5000 in your browser.
9. Login: admin / admin123 (the exam cell) | the two student logins are printed by demo.py
demo.py takes about five seconds - it creates 1,200 students, 5,831 enrolments and builds the timetable.
If MySQL uses a password on your machine, set it once before step 5:
set ETS_DB_PASSWORD=yourpassword
Before a viva, also run 'python selftest.py' - 54 checks pass in front of the examiner. To regenerate the research numbers used in the report, run 'python -m evaluation.study'.The same steps are in README.md inside the ZIP, along with a troubleshooting table.
What you get in the ZIP
- 📁 Full source code — commented throughout, so you can explain it in the viva
- 🗄️ Database — the schema builds itself on first run, with sample data
- 📖 README.md — step-by-step run instructions, database design and troubleshooting
- 📄 Full project report (Word) — Written out and formatted for AKTU — not an outline you have to fill in
- 📊 Presentation (PPT) — Ready for the final viva presentation
- 📝 Synopsis (Word) — The short write-up your guide asks for before approval
- ❓ Viva questions with answers — The questions examiners actually ask about this project
- 📐 13 ready-made diagrams — DFD, ER, use case, sequence and architecture, as images you can paste straight into the report