Automated score compilation
Structure continuous assessment and examination scores, calculate totals, and apply grading rules consistently.
About the project
AureScore began as my final-year Computer Science project.
This page documents why I built it, the academic problem I chose to address, and how I expanded the work to develop stronger backend architecture and application-security skills.
Project report
AureScore: Automatic Score Sheet for Nigerian Universities
A Project Report on Automated Score Compilation, GPA/CGPA Processing, Result Approval and Transcript Generation.
- Student
- Okoye Chukwuemeka David
- Department
- Computer Science
- Faculty
- Physical Sciences
- Supervisor
- Dr Okorie
Submitted in partial fulfilment of the requirements for the award of a Bachelor of Science degree in Computer Science.
Problem context
Why I chose result processing.
Result processing is a suitable automation problem because it combines calculation, record keeping, review, and institutional responsibility. A mistake does not affect only a spreadsheet; it can affect a student's GPA, progression, graduation, or transcript.
I designed AureScore around a common university workflow: lecturers compile scores, exam officers review submissions, academic leaders approve results, and students receive only the final approved record. The project investigates how one system can connect those stages while reducing repeated calculations and disconnected file transfers.
The initial scope focuses on Nigerian universities, where the application must accommodate institutional grading rules and a formal hierarchy of academic review.
GPA and CGPA processing
Derive semester and cumulative performance from approved course results while reducing repetitive manual calculation.
Approval and transcripts
Represent the review path for submitted results and use approved records as the basis for transcript generation.
Engineering extension
What I added beyond the report requirements.
After defining the original academic workflow, I expanded the project to reinforce concepts that matter in larger SaaS applications. A system serving several institutions cannot be treated as a single shared database with unrestricted users.
This changed the project from a narrow score-calculation tool into an architecture exercise involving tenant boundaries, role-based authorisation, protected operations, and auditable state transitions. It also gave me a practical reason to pivot my backend learning toward NestJS.
Multi-tenant design
I extended the data model beyond a single department so that separate institutions and private workspaces can remain logically isolated.
NestJS learning pivot
I chose NestJS for the planned backend to strengthen my understanding of modular architecture, dependency injection, validation, guards, and domain boundaries.
Role-based authorisation
The system distinguishes students, lecturers, exam officers, HODs, deans, and administrators because each role performs different academic actions.
Access-control boundaries
The expanded design treats tenant isolation, least privilege, protected operations, and traceable approval decisions as core requirements.
Current status and learning outcome
The interface shows the product direction; the engineering work defines how it should become dependable.
The current application is a functional product prototype. It demonstrates the user journeys, academic roles, result states, approval model, and responsive interface that the complete system is intended to support.
Production use still requires the planned NestJS backend, persistent storage, verified tenant isolation, authentication, server-side authorisation, audit logging, tests, and operational security controls. I document that boundary deliberately rather than presenting unfinished functionality as complete.