Software case study

CIME CBT — a complete computer-based examination platform

A secure, role-based system that helps institutions create, conduct, monitor, and evaluate digital examinations from one streamlined platform.

  • Django
  • 200+ students
  • role-based
  • live monitoring
  • Windows + macOS

Private evidenceProduct model and delivery scope only; no client data or source code.

Context

CIME CBT is a full-stack Django application for institutions that need one dependable system for the complete digital-examination lifecycle. Administrators and teachers prepare, run, monitor, and review assessments; students use a focused examination portal for assigned tests.

CIME CBT sign-in interface
Fig. 1 — Focused entry. A deliberately simple sign-in flow keeps the assessment, rather than the platform, at the centre of the student experience.Source: privacy-safe product interface capture.

Users and question

The central question was operational: how can an institution manage enrolment, reusable question sets, timed delivery, live invigilation, scoring, analysis, and reporting without stitching together fragile tools or relying on specialist operators?

Administrators

Manage classes, bulk CSV import, credentials, login slips, backups, restoration, and local installation.

Teachers and invigilators

Build banks, configure assessments, observe live activity, and intervene when a real session requires it.

Students

Take assigned tests in a responsive, distraction-free interface with a timer, progress state, autosave, and clear submission.

Constraints

  • Exam-day reliability: answers, timing, attempt state, and submissions must survive ordinary interruptions.
  • Institutional operation: staff need bulk enrolment, generated credentials, access controls, retakes, absence handling, and exportable records.
  • Academic flexibility: reusable banks, images, explanations, negative marking, randomised ordering, and mathematical notation must coexist.
  • Local deployment: the system must work with Windows and macOS packaging, local-network operation, backups, restoration, and safe updates.

Role and design decisions

  • Product designDefined role-specific administrative, teacher, invigilator, and student experiences.
  • SoftwareImplemented the Django application across enrolment, examination delivery, persisted attempts, scoring, analysis, and reports.
  • DeploymentPrepared local-network packaging, backups, restoration, and safe-update paths for Windows and macOS.
  • ValidationChecked saving, timing, submission, scoring, recovery, exports, and data-preservation workflows.

The key design decision was to treat an examination as one continuous lifecycle: preparation feeds controlled delivery; persisted attempts feed invigilation; submission feeds automatic scoring, review, ranking, and reporting. Separate roles see only the controls required for their work.

Workflow

Prepare

  1. Import students and create classes.
  2. Build or import reusable question sets.
  3. Schedule assessments with access, duration, marking, and visibility rules.

Conduct

  1. Deliver randomised questions and answers.
  2. Autosave responses and show time, progress, and unanswered items.
  3. Monitor candidate activity and apply authorised interventions.

Review

  1. Score attempts automatically.
  2. Provide ranks, percentages, subject analysis, and answer review.
  3. Export PDF, Excel, and CSV reports; preserve records with backups.

Validation and outcome

The delivered platform supported a cohort of more than 200 students and covered the path from enrolment through reporting, including live assessment monitoring, teacher intervention, and local Windows/macOS packaging. This is an operational delivery claim, not a learning-outcome claim.

Evidence boundary. The public evidence is limited to the disclosed workflow coverage, delivery scope, and privacy-safe interface capture. Institutional records, source code, deployment packages, and pass-rate outcomes remain private.

Privacy boundary

Student records, institutional configuration, internal reports, and the private repository are intentionally excluded. The page is designed to make the product legible without exposing a client’s data or unpublished implementation details.

Implementation appendix

Django · Python · JavaScript · Bootstrap · SQLite/PostgreSQL · MathJax · ECharts · OpenPyXL · ReportLab

Public architecture summary

  • Identity and roles
    Separate permissions and experiences for administrators, teachers, and students.
  • Question banks
    Subjects, sets, CSV import, images, explanations, and mathematics support.
  • Exam engine
    Schedules, duration, assignment, access codes, marking rules, retakes, and randomisation.
  • Attempt state
    Autosaving, recovery, timing, progress, review, and automatic submission.
  • Results and operations
    Scoring, analysis, reports, backup/restore, and local deployment.