Faculty Feedback Management System Report
Faculty Feedback Management System Report
BENGALURU-560059
(Autonomous Institution Affiliated to VTU, Belagavi)
Submitted By
Bachelor of Engineering
in
CERTIFICATE
Certified that the project work titled “Faculty Feedback Management System” is carried out
by Avinash Anish (1RV23IS145) and Mohammed Huzaif S (1RV23IS073) who are bonafide
students of RV College of Engineering, Bengaluru, in partial fulfilment for the award of degree
of Bachelor of Engineering in Information Science and Engineering of the Visvesvaraya
Technological University, Belagavi during the academic year 2025-26. It is certified that all
corrections/suggestions indicated for the Internal Assessment have been incorporated in the
report deposited in the departmental library. The report has been approved as it satisfies the
academic requirements in respect of experiential learning work prescribed by the institution for
the said degree.
Dr Padmashree T Dr Mamatha GS
Associate Professor Head of the Department
Department of ISE, Department of ISE,
RVCE, Bengaluru-59 RVCE, Bengaluru-59
External Viva
DECLARATION
We, Avinash Anish and Mohammed Huzaif S, students of 5th semester B.E., Department
of Information Science and Engineering, RV College of Engineering, Bengaluru, hereby de-
clare that the Experiential Learning (EL) project titled “Faculty Feedback Management Sys-
tem” has been carried out by us and submitted in partial fulfillment for the award of degree of
Bachelor of Engineering in Information Science and Engineering during the academic year
2025-26.
We also declare that any Intellectual Property Rights generated out of this project carried out
at RVCE will be the property of RV College of Engineering, Bengaluru and we will be one of
the authors of the same.
Place: Bengaluru
Date:
Name Signature
CONTENTS
1 Introduction 1
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 Scope and Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Requirement Specification 5
2.1 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Application Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Design 10
3.1 E-R Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Entities and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 Flow of Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 DFD Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 DFD Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 DFD Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4 Data Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Relational Schema and Normalization . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1 First Normal Form (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2 Second Normal Form (2NF) . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3 Third Normal Form (3NF) . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.4 Boyce-Codd Normal Form (BCNF) . . . . . . . . . . . . . . . . . . . 22
3.3.5 Final Normalization Summary . . . . . . . . . . . . . . . . . . . . . . 22
3.3.6 Schema after Normalization . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Front End Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2 User Interface Components . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Implementation Details 26
4.1 Database Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1 Table Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2 Table Population . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.3 Query Execution and Output . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.4 Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Front End Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Form Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Connectivity to the Database . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.3 Report Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.4 Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6 Conclusion 48
6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Future Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A Code Snippets 52
A.1 Source Code Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.2 Frontend Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.2.3 Environment Configuration . . . . . . . . . . . . . . . . . . . . . . . . 52
A.2.4 Database Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.2.5 Run the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.3 Backend Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.3.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.3.3 Environment Configuration . . . . . . . . . . . . . . . . . . . . . . . . 54
A.3.4 Run the Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.4 Docker Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
B Screenshots 55
Faculty Feedback Management System DBMS
INTRODUCTION
1.1 Terminology
The following terms and abbreviations are used throughout this report:
Term Definition
RBAC Role-Based Access Control – a method of regulating access
to resources based on the roles of individual users within
the system.
OAuth Open Authorization – an open standard for access delega-
tion, commonly used for token-based authentication.
OTP One-Time Password – a password valid for a single login
session or transaction.
PWA Progressive Web Application – a web application that uses
modern web technologies to deliver app-like experiences.
LLM Large Language Model – an AI model trained on vast
amounts of text data, capable of understanding and generat-
ing human-like text.
API Application Programming Interface – a set of protocols and
tools for building software applications.
NLP Natural Language Processing – a branch of AI that enables
computers to understand, interpret, and respond to human
language.
USN University Serial Number – a unique identifier assigned to
each student in the institution.
1.2 Purpose
The Faculty Feedback Management System is a web-based platform designed to automate
student feedback collection and analysis at RV College of Engineering. The system enables fac-
ulty to dynamically create course-specific feedback forms and assign them to enrolled students.
Students log in securely, submit feedback with complete anonymity, and receive confirmation.
The platform automates the entire workflow, from form creation to AI-based result analysis,
ensuring fairness, transparency, and efficiency in the feedback process.
1.3 Motivation
Currently, RVCE relies on platforms like Google Forms and Quiklrn for collecting student
feedback. While these tools provide basic data collection capabilities, they present several
limitations:
1. Limited Analytics: These platforms only provide raw data export without any automated
analysis, summarization, or visualization of feedback trends.
4. No Integrated Notifications: Faculty must manually track submissions and send re-
minder emails, leading to lower response rates.
5. Fragmented Workflow: Form creation, distribution, collection, and analysis are discon-
nected processes requiring manual intervention at each step.
These limitations motivated the development of a dedicated system that integrates AI-
powered analysis, guaranteed anonymity, and an automated end-to-end workflow.
There is a need for a unified platform that addresses these gaps while providing a seamless
experience for administrators, faculty, and students.
1.5 Objectives
The objectives of the Faculty Feedback Management System are:
• To develop a web application with role-based access for administrators, faculty, and stu-
dents.
• To automate the feedback workflow including form creation, distribution, and notifica-
tions.
Scope
This project focuses on developing a feedback management system specifically for RVCE with
the following boundaries:
• The system covers feedback collection for courses offered within the institution.
• AI features are limited to form creation assistance, response summarization, and senti-
ment analysis.
• The system does not replace existing academic management systems but integrates as a
standalone feedback platform.
Assumptions
• Users have access to devices with internet connectivity.
• Students have valid institutional USNs and email addresses for authentication.
• Faculty members and their course assignments are registered in the system by adminis-
trators.
Relevance
This project is relevant to RVCE as it:
• Encourages greater student participation through guaranteed anonymity and ease of ac-
cess.
REQUIREMENT SPECIFICATION
Administrator Module
The administrator has full control over system configuration and user management.
• The system shall allow administrators to create, update, and delete user accounts for
faculty and students.
• The system shall provide a user approval workflow where new registrations require ad-
ministrator approval before activation.
• The system shall allow administrators to define and manage academic structure including
departments and courses.
• The system shall enable administrators to assign faculty members to specific courses.
• The system shall provide administrators with system-wide analytics and feedback reports
across all departments.
• The system shall allow administrators to control feedback cycles by setting global dead-
lines and activation periods.
• The system shall provide administrators the ability to send announcements and notifica-
tions to all users.
Faculty Module
Faculty members can create feedback forms, distribute them to students, and analyze responses.
• The system shall allow faculty to create course-specific feedback forms with customiz-
able question types (rating scale, multiple choice, text response).
• The system shall provide an AI-powered form builder that assists faculty in generating
questions based on natural language prompts.
• The system shall allow faculty to assign feedback forms to specific student batches en-
rolled in their courses.
• The system shall enable faculty to set deadlines and activation periods for each feedback
form.
• The system shall provide real-time tracking of submission status showing completed and
pending responses.
• The system shall display an analytics dashboard with visualizations of feedback trends,
ratings distribution, and comparative metrics.
• The system shall allow faculty to export feedback reports in PDF format for academic
reviews.
Student Module
Students can securely access and submit feedback for their enrolled courses.
• The system shall authenticate students using their USN and institutional email with OTP
verification.
• The system shall display only active feedback forms for courses in which the student is
enrolled.
• The system shall allow students to submit feedback responses with guaranteed anonymity.
• The system shall prevent duplicate submissions by tracking form completion status per
student.
• The system shall send confirmation notifications upon successful feedback submission.
• The system shall send reminder notifications for pending feedback forms before dead-
lines.
AI Assistant Module
The AI assistant provides intelligent features for form creation and response analysis.
• The system shall provide a conversational AI interface for faculty to describe feedback
requirements in natural language.
• The system shall generate structured feedback form questions based on AI interpretation
of faculty requirements.
• The system shall analyze submitted text responses and provide sentiment classification
(positive, negative, neutral).
• The system shall generate concise summaries of qualitative feedback highlighting key
themes and suggestions.
• The system shall provide actionable insights and recommendations based on feedback
analysis.
• Performance: The system shall handle a minimum of 500 concurrent users. Page load
time shall not exceed 3 seconds, and API responses shall complete within 2 seconds.
• Security: All data transmission shall be encrypted using HTTPS/TLS. Role-based access
control shall be enforced, and feedback responses shall be stored anonymously, decou-
pling student identity from responses.
• Usability: The interface shall be intuitive, responsive across devices (desktop, tablet,
mobile), and installable as a Progressive Web Application (PWA).
• Reliability: The system shall maintain 99% uptime during academic sessions with daily
automated backups and graceful error handling.
• Maintainability: The codebase shall follow modular architecture with the database de-
signed in Third Normal Form (3NF) to ensure data integrity.
Component Specification
Processor 2+ vCPUs (Intel/AMD x86 64)
RAM 4 GB minimum (8 GB recommended)
Storage 20 GB SSD (scalable based on data volume)
Network 100 Mbps stable internet connection
2.3.3 Deployment
DESIGN
• Attributes:
– dept code (Primary Key)
– name
2. FACULTIES
• Attributes:
– faculty id (Primary Key)
– dept code (Foreign Key referencing DEPARTMENTS)
– first name
– last name
– phone no
3. STUDENTS
• Attributes:
– student id (Primary Key)
– first name
– last name
– semester
– dept code (Foreign Key referencing DEPARTMENTS)
4. COURSES
• Attributes:
– course code (Primary Key)
– title
– dept code (Foreign Key referencing DEPARTMENTS)
– faculty id (Foreign Key referencing FACULTIES)
5. FEEDBACK FORMS
• Attributes:
– form id (Primary Key)
– is active
– semester
– academic year
– created by
– course code (Foreign Key referencing COURSES)
6. FORM QUESTIONS
• Attributes:
– question id (Primary Key)
– question
– type
3.1.2 Relationships
1. FACULTIES and DEPARTMENTS (belong to):
• Many-to-One: Multiple faculty members can belong to one department, but each
faculty member belongs to exactly one department.
• One-to-Many: A department can offer multiple courses, but each course is offered
by exactly one department.
• One-to-Many: A department can have multiple students enrolled, but each student
belongs to exactly one department.
• Many-to-Many: A student can enroll in multiple courses, and a course can have
multiple students enrolled. This relationship has additional attributes:
– grade - The grade obtained by the student in the course
– date - The date of enrollment
• One-to-Many: A student can fill multiple feedback forms, but each feedback sub-
mission is associated with one student.
• One-to-Many: A course can have multiple feedback forms associated with it (for
different semesters/years), but each feedback form is linked to exactly one course.
• One-to-Many: A feedback form can contain multiple questions, and questions can
be reused across multiple forms.
• Departments form the organizational backbone of the system. Each department has
a unique code and name, and serves as the parent entity for faculties, students, and
courses.
2. Faculty Management:
• Faculty members are registered under specific departments. Their personal infor-
mation including name and contact details are stored for identification and commu-
nication purposes.
3. Student Management:
• Students are enrolled in departments and their semester information is tracked. This
allows the system to identify which courses a student should provide feedback for.
4. Course Management:
• Courses are offered by departments and taught by faculty members. The relation-
ship between courses and faculty enables the feedback system to link student re-
sponses to specific instructors.
• The enrollment relationship between students and courses tracks academic partici-
pation. Grade and date attributes ensure that feedback can be collected only from
students who have completed the course.
6. Feedback Collection:
• Feedback forms are created for specific courses and academic periods. The is active
flag controls whether a form is currently accepting responses. Students fill these
forms to provide their evaluation of the course and instructor.
7. Question Management:
• Form questions define the structure of feedback forms. The type attribute allows
for different question formats (e.g., rating scale, multiple choice, text response),
enabling comprehensive and structured feedback collection.
modifications, and where it’s stored. The primary aim of a DFD is to delineate the scope and
boundaries of a system comprehensively. DFDs are hierarchical, with each layer delving deeper
into the system or data. Typically, these layers are represented as Levels 0 through 2, each
progressively revealing more intricate details about the system’s components and operations.
1. Student Interaction
2. Faculty Interaction
3. Admin Interaction
• Admin provides course data, user details, and department data to the system.
• Admin manages course enrollments for students.
• The system generates reports and analytics for administrative review.
• Handles user authentication by receiving credentials from Admin, Faculty, and Stu-
dents.
• Manages user data including registration, profile updates, and role assignments.
• Stores and retrieves user information from the Users data store.
• 1.1 Verify OTP: Verifies the one-time password sent to user email for authentica-
tion.
• 1.2 Get User Role: Retrieves the role (admin/faculty/student) of a user from the
database.
• 1.3 Update User Role: Allows admin to update user roles in the system.
• 1.4 Create Student Profile: Creates a new student profile with semester and de-
partment info.
• 1.5 Create Faculty Profile: Creates a new faculty profile with department associa-
tion.
• 2.5 Manage Enrollments: Enroll and unenroll students in courses with date track-
ing.
• 2.6 Assign Faculty: Assign faculty members to specific courses.
• 3.1 Get My Forms: Faculty retrieves all feedback forms they have created.
• 3.2 Get Form Details: Retrieves a specific form with all questions and options.
• 3.3 Save Form: Creates new or updates existing feedback forms.
• 3.4 Validate Form: Validates form structure, required fields, and question configu-
rations.
• 3.5 Manage Questions: Creates, updates, or deletes questions within a form.
• 3.6 Manage Options: Handles options for choice-type questions (radio, checkbox,
dropdown).
• 4.1 Get Available Forms: Retrieves all active feedback forms for enrolled courses.
• 4.2 Get Form for Student: Retrieves a specific form with questions for completion.
• 4.3 Validate Enrollment: Verifies that student is enrolled in the course.
• 4.4 Validate Answers: Validates that all required questions have been answered.
• 4.5 Submit Feedback: Creates submission record and stores all responses.
• 4.6 Normalize Responses: Normalizes response data (text trimming, number pars-
ing).
• 5.1 Get Form Results: Retrieves form details and all associated submissions.
• 5.2 Aggregate Responses: Coordinates aggregation of all response types into statis-
tics.
• 5.3 Calculate Statistics: Computes statistics for numeric/rating type questions.
• 5.4 Count Options: Counts selections for each option in choice questions.
• 5.5 Compile Text Answers: Collects and compiles all text responses.
1. Users: Stores information about all system users including students, faculty, and admin-
istrators along with their authentication credentials and roles.
4. Feedback Data: Stores feedback form configurations, questions, and submitted responses.
This is the central repository for all feedback-related information.
• This violates atomicity, we need to separate options into another table QUESTION OPTIONS.
• It is already in 1NF.
• All non-key attributes are fully functionally dependent on the primary key (no partial
dependencies).
• The course title depends only on course code, not on the primary key enrollment id.
• It is already in 2NF.
• There are no transitive dependencies (non-key attributes should not depend on other
non-key attributes).
faculty id user id first name last name department code dept name
F001 U001 Padmashree T ISE Information Science
F002 U002 Anala M ISE Information Science
• It is already in 3NF.
Figure 3.5: Normalized Relational Schema for Faculty Feedback Management System
2. Intuitive Navigation: Clear navigation menus and breadcrumbs ensure users can easily
find and access features.
2. Student Dashboard:
3. Faculty Dashboard:
4. Administrator Dashboard:
• Quick Actions: Floating action buttons and shortcuts for frequently used operations
IMPLEMENTATION DETAILS
’rating’
)
),
is_required BOOLEAN DEFAULT FALSE,
display_order INT NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW(),
FOREIGN KEY (form_id) REFERENCES feedback_forms(form_id) ON
DELETE CASCADE
);
role
student
Profile Management
Admin Dashboard
UPDATE students
SET first_name = ’Avinash’, last_name = ’A’, semester = 6
WHERE student_id = ’1RV23IS145’;
Notifications
1. UUID Primary Keys: All primary keys use UUIDs generated by gen random uuid(),
making them unpredictable and resistant to enumeration attacks.
2. Role-Based Access Control: The users table enforces role constraints using CHECK
constraints, limiting roles to ’admin’, ’faculty’, or ’student’.
3. Referential Integrity: Foreign key constraints ensure data consistency across related ta-
bles. CASCADE delete operations are used where appropriate to maintain data integrity.
4. Unique Constraints: Strategic unique constraints prevent duplicate entries, such as:
6. Row Level Security (RLS): Supabase RLS policies restrict data access based on authen-
ticated user roles and ownership.
7. Prepared Statements: The application uses parameterized queries through the Supabase
client library, preventing SQL injection attacks.
The authentication form provides a unified interface for both new and returning users. The
form adapts based on user actions and supports multiple authentication methods.
Form Fields:
• Email Address: A text input field for the user’s institutional email address. The field
includes validation for proper email format and domain restrictions (e.g., @[Link]).
• OTP Input: Upon email submission, users receive a 6-digit One-Time Password via
email. A numeric input field is displayed for OTP entry with automatic focus progression.
• Google OAuth Button: A social login button that initiates the Google OAuth 2.0 au-
thentication flow for users with Google accounts.
Form Behavior:
The form builder allows faculty members to create customized feedback forms with a drag-
and-drop interface and real-time preview.
Figure 4.2: Feedback Form Builder Interface – An intuitive drag-and-drop interface allowing
faculty to create customized feedback forms with various question types and real-time preview.
• Form Title: Text input for the feedback form name (e.g., ”Mid-Term Feedback”)
• Course Selection: Dropdown to select the associated course from faculty’s assigned
courses
• Options List: Dynamic list for adding choices (for radio, checkbox, dropdown types)
Question Actions:
• Delete question
[Link] Server Actions are used to handle database operations securely on the server side. This
approach provides several benefits:
"use server";
if (error) {
[Link]("Error fetching user role:", error);
return null;
}
The application leverages Supabase’s real-time capabilities for live updates. When a student
submits feedback, faculty dashboards are automatically updated without requiring manual re-
fresh.
Analytics Dashboard
Faculty members can view aggregated feedback statistics through an intuitive dashboard inter-
face. The results page displays:
The dashboard provides real-time updates as students submit their feedback, allowing fac-
ulty to monitor response rates and preliminary results during an active feedback collection
period.
AI-Assisted Analysis
Export Capabilities
Authentication
2. Email OTP: One-time password authentication via email for users without Google ac-
counts
3. Session Management: Secure server-side session handling with automatic token refresh
Authorization
1. Role-Based Access Control: Different interfaces for admin, faculty, and student roles
3. API Protection: All server actions verify user authentication and role before processing
requests
Data Protection
2. Input Sanitization: All user inputs are validated and sanitized before processing
Admin Dashboard
2. Faculty: Creates and activates feedback form with multiple question types
Result: All data flows correctly between modules. Submissions recorded, analytics calcu-
lated accurately. PASS
Security Tests
All test cases passed successfully, demonstrating the reliability of the Faculty Feedback Man-
agement System.
CONCLUSION
6.1 Conclusion
The Faculty Feedback Management System has been successfully designed and implemented
to streamline the feedback collection process at RVCE. The system addresses the limitations
of traditional paper-based feedback methods by providing a digital, efficient, and user-friendly
platform for all stakeholders.
The key achievements of this project include:
• Dynamic Form Builder: A flexible form creation tool that allows faculty to design
custom feedback forms with multiple question types including text, ratings, and multiple-
choice options.
The system was built using modern web technologies including [Link], React, TypeScript,
and Tailwind CSS for the frontend, with PostgreSQL on Supabase providing a robust and scal-
able backend. All 39 test cases across database, frontend, and system testing passed success-
fully, validating the reliability of the implementation.
6.2 Limitations
While the system meets its primary objectives, some limitations exist:
• Internet Dependency: The system requires an active internet connection for all opera-
tions. Offline functionality is not currently supported.
• Limited Report Formats: Currently, feedback reports can only be exported as JSON
and CSV. PDF report generation with custom formatting is not yet implemented.
• Single Institution Focus: The system is designed specifically for RVCE’s structure.
Adapting it for other institutions would require modifications to the department and
course hierarchy.
• No Comparative Analytics: The system does not currently support comparing feedback
across different semesters or academic years for trend analysis.
• Offline Support: Implement service workers to enable offline form viewing and queued
submission when connectivity is restored.
• Trend Analysis: Implement comparative analytics to track feedback trends across semesters
and academic years, helping identify long-term improvements or concerns.
• Integration with LMS: Integrate with existing Learning Management Systems for seam-
less course and enrollment data synchronization.
In conclusion, the Faculty Feedback Management System successfully digitizes and en-
hances the feedback collection process, providing a foundation that can be extended with addi-
tional features to further improve the teaching-learning experience at educational institutions.
BIBLIOGRAPHY
[1] Vercel, “[Link] Documentation – The React Framework for the Web,” 2024. Available:
[Link]
[2] Meta Platforms, Inc., “React – A JavaScript library for building user interfaces,” 2024.
Available: [Link]
[3] Microsoft, “TypeScript: JavaScript With Syntax For Types,” 2024. Available: https:
//[Link]/docs/
[4] Tailwind Labs, “Tailwind CSS – A utility-first CSS framework,” 2024. Available:
[Link]
[5] shadcn, “shadcn/ui – Beautifully designed components built with Radix UI and Tailwind
CSS,” 2024. Available: [Link]
[6] Supabase, Inc., “Supabase Documentation – The Open Source Firebase Alternative,”
2024. Available: [Link]
[7] The PostgreSQL Global Development Group, “PostgreSQL: The World’s Most Advanced
Open Source Relational Database,” 2024. Available: [Link]
org/docs/
[8] Supabase, Inc., “Supabase Auth – User Management and Authentication,” 2024. Avail-
able: [Link]
[10] Google, “Gemini API Documentation – Google AI for Developers,” 2024. Available:
[Link]
[11] Vercel, “AI SDK – The AI Toolkit for TypeScript,” 2024. Available: [Link]
[Link]/docs
[12] Resend, Inc., “Resend – Email for developers,” 2024. Available: [Link]
com/docs
[13] M. Thomson, E. Damaggio, and B. Raymor, “Generic Event Delivery Using HTTP
Push,” IETF RFC 8030, 2017. Available: [Link]
doc/html/rfc8030
[15] Mozilla Developer Network, “Service Worker API,” 2024. Available: https://
[Link]/en-US/docs/Web/API/Service_Worker_API
[16] D. Hardt, Ed., “The OAuth 2.0 Authorization Framework,” IETF RFC 6749, Oct. 2012.
Available: [Link]
[17] Google, “Using OAuth 2.0 to Access Google APIs,” 2024. Available: https://
[Link]/identity/protocols/oauth2
[18] E. F. Codd, “A Relational Model of Data for Large Shared Data Banks,” Communications
of the ACM, vol. 13, no. 6, pp. 377–387, Jun. 1970.
[19] A. Silberschatz, H. F. Korth, and S. Sudarshan, Database System Concepts, 7th ed.
McGraw-Hill Education, 2019.
[21] React DnD, “React DnD – Drag and Drop for React,” 2024. Available: https://
[Link]/react-dnd/about
[22] Recharts, “Recharts – A composable charting library built on React components,” 2024.
Available: [Link]
[23] Vercel, “Vercel Documentation – Develop. Preview. Ship.,” 2024. Available: https:
//[Link]/docs
CODE SNIPPETS
[Link]
The repository contains the full implementation including the frontend application, backend
API, and database schema.
A.2.1 Prerequisites
• [Link] (v18 or higher)
A.2.2 Installation
cp [Link] .env
frontend/lib/supabase/migrations/[Link]
A.3.1 Prerequisites
• Python 3.10 or higher
A.3.2 Installation
cd faculty-feedback-system/faculty-feedback-backend
pip install -r [Link]
python [Link]
# API available at [Link]
docker-compose up --build
Docker Deployment
SCREENSHOTS
This appendix provides a comprehensive visual walkthrough of the Faculty Feedback System,
showcasing the key interfaces and features available to different user roles.
Figure B.1: Faculty Feedback System Landing Page – The main entry point featuring a modern,
intuitive interface that welcomes users and provides navigation to sign-in functionality.
Figure B.2: User Authentication Interface – Secure sign-in page supporting role-based authen-
tication for administrators, faculty members, and students.
Figure B.3: Administrator Dashboard – The central control panel for system administrators,
providing an overview of system metrics, user statistics, and quick access to management func-
tions.
Figure B.4: Role Management Interface – Administrators can assign and manage user roles,
ensuring proper access control across the system for faculty and student accounts.
Figure B.6: Faculty Forms List – A comprehensive view of all feedback forms created by the
faculty member, with options to view responses, edit, share, or delete forms.
Figure B.7: Form Builder Interface – An intuitive drag-and-drop form builder allowing faculty
to create custom feedback forms with various question types, including multiple choice, rating
scales, and open-ended questions.
Figure B.8: AI Form Creation Assistant – The intelligent assistant interface that helps faculty
members generate feedback forms through natural language prompts, streamlining the form
creation process.
Figure B.9: AI Form Summary View – The assistant provides a comprehensive summary of the
generated form, allowing faculty to review and refine questions before publishing.
Figure B.10: Feedback Results Dashboard – Detailed analytics and visualizations of student
responses, including response distributions, average ratings, and sentiment analysis of open-
ended feedback.
Figure B.11: Student Dashboard – The student’s personalized view showing pending feedback
forms assigned by faculty, completed submissions, and navigation options.
Figure B.12: Student Feedback Form – The clean, accessible interface students use to submit
their feedback, featuring clear instructions, progress indicators, and anonymous submission
options.
The system supports three user roles: Administrator, Faculty, and Student. Administrators can create, update, and delete user accounts, manage academic structures, assign faculty to courses, control feedback cycles, and send notifications . Faculty members can create feedback forms, distribute them, and analyze responses . Students can authenticate to the system, submit feedback for their enrolled courses, and view information about their assigned courses .
The testing methodologies included database integrity testing, front-end functionality testing, and system integration testing. Key outcomes were a 100% pass rate across 39 test cases, which validated the reliability of the system . Database testing ensured the correctness and integrity of the database, front-end testing checked user interface functionality, and system testing evaluated end-to-end workflows.
Feedback data is stored in a central repository that includes form configurations, questions, and submission responses. The system aggregates data from feedback submissions to generate reports on faculty performance, course effectiveness, and student satisfaction . This involves normalizing responses, aggregating responses into statistics, and utilizing AI to provide comprehensive analytics and insights.
The main objectives of the Faculty Feedback Management System are to develop a web application with role-based access for administrators, faculty, and students; implement AI-powered feedback analysis with sentiment detection and automated summarization; ensure complete anonymity for students during feedback submission; provide real-time analytics dashboards for faculty to visualize feedback trends; and automate the feedback workflow including form creation, distribution, and notifications .
The security measures include authentication through OAuth 2.0 and email OTP, role-based access control, route protection to prevent unauthorized access, API protection, HTTPS for data in transit, input sanitization, and anonymous feedback . These measures ensure secure authentication and authorization, protect data integrity and confidentiality, and guard against threats like SQL injection and cross-site scripting.
The system ensures student anonymity during feedback submission by protecting student identities in feedback submissions and only displaying aggregated data to faculty . This means that while individual responses are collected, they are anonymized before being displayed, thus ensuring that students cannot be identified based on their feedback.
DFDs assist by visually representing the flow of information within the system, detailing how data enters and exits the system and where it traverses. Level 0 DFDs provide an overview, while subsequent levels delve deeper into processes and data structures, enabling stakeholders to comprehend the system comprehensively . This understanding aids in identifying integration points and ensuring that all data exchanges comply with system requirements.
The limitations include internet dependency for system operations, limited report formats (JSON and CSV, but not PDF with custom formatting), and being specifically designed for RVCE . These limitations could impact deployment by constraining usage without internet access, limiting the usability of exported data outside digital environments, and reducing scalability to other institutions without significant modifications.
PWA functionality enables the system to be accessible as an application on mobile and desktop environments, providing enhanced accessibility and user convenience . Benefits include mobile installation and push notifications for timely feedback collection, thus increasing user engagement and ensuring that users are kept informed about feedback processes.
AI integration improves the system by allowing automatic summarization of feedback, identification of common themes and sentiments, and generation of actionable suggestions. Additionally, it can create natural language reports from statistical data . These capabilities enhance the usability and effectiveness of feedback analysis by providing faculty with immediate and insightful analyses of feedback.