“ONLINE FEEDBACK SYSTEM” (OFS.

com)
A Project Report
Submitted in the partial fulfillment for the award of the degree of
B. Tech(Information Technology)

Submitted By

Group ID: IT03

Devanshi Bansal (1813257)

Dishika Singh (1813260)

Manasvi Shahi (1813282)

Meet Patel (1813285)

Under the supervision of

Mrs. Karuna Sharma

(Assistant Professor, Department of Computer Science)

Department of Mathematics & Computing

Banasthali Vidyapith
Banasthali-304022
Session:2020-2021
Page 2

ABSTRACT

The project primarily focuses on collecting the feedback of the students regarding
their faculty and wardens. The main aim is to reduce the paper consumption as well
as the time of the authorities concerned to regulate the whole feedback collecting
process.
The project walks through the student entering details and then further fills the
feedback. If the process of the feedback is not completed by the student and he exists
without filling all the forms, he can fill the feedback of remaining teacher/warden by
revisiting the site. But if he will not be able to fill the feedback within the due date,
then she will receive a reminder mail. If already filled, she will not be able fill the
forms again.
The admin can activate the filling form for the students which will otherwise be
disabled i.e. the students cannot access the forms until the permission is granted by
the administrator. The admin can add new teachers to the database and the students as
well. The admin also has the ability to generate the results of the feedbacks once
everything has been collected, and much other functionality.
The teachers can access their feedback results through login and password which
have been provided to them through the administrator. They can update their profiles
as well and then logout once all has been done.
Page 3

ACKNOWLEDGEMENT

We take this opportunity to express our gratitude towards all

those people who in various ways have helped in successful
completion of our project.
We express gratitude to our project guide Ms. Karuna
Sharma whose inspiration, suggestion and invaluable
guidance enabled us to develop the present software.
We hereby offer our sincere compliment to all our friends for
their useful suggestion and cooperation.
Last but not the least; we owe debt toward our revered
parents for their moral support and constant encouragement
that has made it possible for us to attain this usage this stage
of academic achievement in our life.

Team Members: -
Devanshi Bansal (1813257)
Dishika Singh (1813260)
Manasvi Shahi (1813282)
Meet Patel (1813285)
Page 4

TABLE OF CONTENTS

[Link]. DESCRIPTION
1 Project Objective
2. Software Requirement Specification
2.1 Introduction
2.1.1 Purpose
2.1.2 Document Conventions
2.1.3 Intended Audience and Reading Suggestions
2.1.4 Product Scope
2.2 Overall Description
2.2.1 Product Perspective
2.2.2 Product Functions
2.2.3 User Classes and Characteristics
2.2.4 Operating Environment
2.2.5 Design and Implementation Constraints
2.3 External Interface Requirements
2.3.1 User Interfaces
2.3.2 Hardware Interfaces
2.3.3 Software Interfaces
2.3.4 Communications Interfaces
2.4 Feasibility Study
2.5 System Features
2.4.1 Use case Diagram
2.6 Other Non-Functional Requirements
2.6.1 Performance Requirements
2.6.2 Security Requirements
3. Software Design Specification
3.1 Introduction
3.1.1 Purpose of this document
3.1.2 Scope of the development project
3.1.3 Definitions, acronyms, and abbreviations
3.1.4 Overview of the document
3.2 System Architecture Description
3.2.1 Structure Chart
3.2.2 Decomposition Description
Page 5

[Link] Data Flow Diagram

4. Data Design
4.1 ER Diagram
4.2 Databases
5. Interfaces
6. References

1. Project Objective
Page 6

Problem Statement:-

The Online feedback System is developed for the purpose of giving feedback
of faculty and wardens. The project represents the information regarding the
submission of feedback forms to lecturers and instructors of all the
Departments and wardens of all the hostels of Banasthali Vidyapith. A typical
feedback form consists some questions where students have to give a rank in a
range 1 to 5. Lecturers/instructors would like to see feedbacks in addition to
going through them individually. One student is allowed to give only one time
feedback. They are not allowed to change it at any time later. In addition, you
will have to consider factors such as courses conducted by more than one
teacher and Students belong to different departments.
Purpose:-
This project is design for the purpose to reduce the lecturer’s time and to
reduce the burden of maintaining huge amount of records of students.
As the comparison with manual feedback or existing feedback system, the
new system is easier way to manage whole things in a particular manner. As
per the existing system it
is very easy process to save each and every record of individual student by the
use of database.

2. Requirement Analysis (SRS)

Page 7

2.1 Introduction

2.1.1 Purpose

The purpose of this document is to describe the software

requirement in developing the website for “ONLINE
FEEDBACK SYSTEM”. This document describes the
functionality, requirements, and general interface of the
project.

2.1.2 Document Conventions

 HTML: Hypertext Markup Language is a markup

language used to design web pages.
 CSS: Cascading Style Sheets are used to style web
pages.
 JSP: Java Server Page

 HTTP: Hypertext Transfer Protocol is a transaction-

oriented client/server protocol between a web browser
& a Web Server.

 WWW: World Wide Web.

 HTTPS: Secure Hypertext Transfer Protocol is an

HTTP over SSL (secure socket layer).

 TCP/IP: Transmission Control Protocol/Internet

Protocol, the suite of communication protocols used to
connect hosts on the Internet. TCP/IP uses several
protocols, the two main ones being TCP and IP.
Page 8

 DB: Database

 RAM: Random Access Memory

 HDD: Hard Disk Drive

 IE: Internet Explorer

 IEEE: Institute of Electrical and Electronics Engineers.

 OS: Operating System

2.1.3 Intended Audience and Reading Suggestions

Admin, Teachers and Students

2.1.4 Product Scope

“OFS” is a web-based service that aims to make the

feedback collection system labour-saving, cost-effective, and
time-efficient.
The scope of the project can be listed as under:
 This site aims to provide special functionality to Banasthali
users of filling the feedback form online and analyzing that data
simultaneously.
 Non-Banasthalites will not be able to gain any functionality of
the software due to confidentiality of information.
 The identity of the student and their individual response will
not be disclosed.
 Reminders will be mailed to the students who have not yet
filled the feedback form before the closing of the portal.
Page 9

 Admin will be responsible to update the overall database of the

website which includes the updating of faculty and warden details.
 As per the department entered by the student, the name of the
teachers will be fetched from the database.
 As per the hostel entered by the student, the name of the
wardens will be fetched from the database.
 This facility increases the overall accuracy of the feedback
collection procedure.
 Three types of users will be using this website:
1) Admin
2) Teacher
3) Student

2.2 Overall Description

2.2.1 Product Perspective

This website is mainly intended for students and faculty of

Banasthali.
This website will be ergonomic and authentic.

Derby
Glassfish Server
Page 10

Client Side Application Server

Database Server

2.2.2 Product Functions

“OFS” will allow:

1. A welcome page will redirect the user to avail the
displayed functionalities
2. On clicking the login button the admin will be
redirected to the login page
2.1. The admin can view the response of the feedback of
every faculty and warden individually.
2.2. The admin can view the list of students who are yet to
submit the feedback.
2.3. Admin can finally log out and land on the home page.
3. Students will fill in their details.
3.1. Students will be redirected to fill in the feedback for
teachers and wardens.
3.2. Confirmation mail would be sent out once the
submission is complete
3.3. They will be directed to a thank you page after
submitting feedback
3.4. Reminders will be mailed to the students who are yet to
give feedback.
4. Teachers will be able to log in.
4.1 Teachers will be able to view their performance
subject-wise.
4.2 Teachers can also update their profiles.
Page 11

2.2.3 User Classes and Characteristics

Users of this software can be categorized as following:

 STUDENTS
These users are to fill in the details and give feedback to both
teachers and wardens.

 ADMIN
These users are responsible for maintaining, updating the
database, and viewing the results of the feedback. They
administer the whole website. They can update any data at any
time without creating any conflict or any confusion for the rest
of the users.

 TEACHERS
These users will be able to view their performances subject
wise after logging in with their login information and can even
update their profiles.

2.2.4 Operating Environment

Internet, phone/laptop/computer, android/iOS is required to access software.

2.2.5 Design and Implementation Constraints

1. Higher Order Language Functions: The [Link] will be

used for developing the web-pages with the help of
NetBeans8.2 and for the database information Derby
database 10.4.x will be used.

2. Criticality of the Application: The s

Page 12

3. erver application will be available 24 X 7 but the feedback

portal for the students would be available for a week.

4. Safety and Security Considerations: The password and a

valid username are the security provision.

5. External users will not be able to gain any functionality of

the website.

6. Any substantial enhancement in website will require

approval of the administrator.

Technologies Used

 Front End: [Link] with Java`

 Back End: Derby database 10.4.x

 Design Tool: Netbeans8.2

 Web Server: Glassfish server 4.1.1

2.3 External Interface Requirements

2.3.1 User Interfaces

 Welcome Page
 Admin Signup and login page
 Teacher Login Page
 Feedback Form Page
Page 13

 Evaluation Page
 Page for sending activation mail and reminder mail.

2.3.2 Hardware Interfaces

Server Side:
 RAM: 512 MB
 HDD: 5 GB or more (Free space excluding data size)
 Processor: 1-2 GHz (P4) or onwards

Client Side:
 RAM: 128 MB
 HDD: 1 GB or more (Free space excluding data size)
 Processor: 450 GHz (P2)

2.3.3 Software Interfaces

Server Side:

 OS: Windows Server 2000 or onwards

 Web Server: Glassfish 4.1.1 or onwards with [Link]

framework

Client Side:

 OS: Any OS

 Browser: Any browser compatible with IE 5.0 or

onwards
Page 14

2.3.4 Communications Interfaces

 Client on Internet will be using HTTP/HTTPS protocol.

 Client on Intranet will be using TCP/IP protocol.

2.4 Feasibility Study

Feasibility Study is a preliminary study undertaken to determine a
project's viability. The term feasibility study is also used to refer to
the resulting document. These results of this study are used to
make a decision whether to proceed with the project, or not. If it
indeed leads to a project being approved it will (before the real
work of the proposed project starts) be used to ascertain the
likelihood of the project's success. It is an analysis of possible
alternative solutions to a problem and a recommendation on the
best alternative.

Operational Feasibility

We have used a simple user-friendly interface that will help

students to give feedback easily.

Technical Feasibility

This involves questions such as whether the technology needed for

the system exists, how difficult it will be to build, and whether the
firm has enough experience using that technology. This web
application has been developed on Windows 10 platform and a
high configuration of 8GB RAM on Intel(R) core i3 processor.
This is technically [Link] project is feasible through the use
of a computer which is the hardware.
Page 15

Financial And Economical Feasibility

Users will need not to handle any extra software or hardware apart
from having a stable high-speed internet connection and a
technical device i.e. PC or laptop with minimum requirements. In
the fast-paced world today there is a great need for online facilities.
Thus, the benefits of this project
in the current scenario make it economically feasible.

Handling Infeasible Projects

We did not face any infeasibility during this project because we

used NetBeans IDE 8.1 to build this project. We installed it on our
laptop easily because it is available free of cost. Whenever we got
errors or difficulties in our project, project guide helped and
provided the way to proceed.
Page 16

2.5System Features

2.5.1 Use-CaseDiagrams:

Figure 1:Use-Case Diagram for overall project

Page 17

Figure 2: Use-Case Diagram of Admin

Page 18

Figure 3:Use-Case Diagram of Teacher

Page 19

Figure 4: Use-Case Diagram of Student

 Page 20

Sign-Up:
Use Case No 1

Use Case Name Sign up

Actors: Admin

Descriptions This module helps the admin to create new accounts.

Input Name, smart card ID, Login id and password, email id.

Normal Course Events 1. Users enter their e-mail address.

2. Users enter their passwords.
3. User enters other required Information.
4. Users click sign up button.
5. System connects to database.
6. A message appears which shows the
Membership applied.

Alternative Courses 1. Same Login-id exists in database

2. Error message appears.
3. Continue with step 1 in the normal course
Events.

1. An error may occur during the database

Operation.
2. System shows error messages.

Output New user account will be created.

Table 1: Use Case of Sign-up Function

Use Case No 2
 Page 21

Use Case Name Login

Actors: Admin, Teachers

Descriptions This module helps the admin and the teachers to login.

Pre-conditions The user must be a member of the system.

Input Login id and password.

Normal Course Events 1. Users enter their login-id.

2. Users enter their password.
3. Users click login button.
4. System connects to database.
5. Subsequent page displayed.

Alternative Courses 1. User enters incorrect user name and/or

password.
2. Error message appears.
3. Continue with step 1 in the normal course
events.
4. An error may occur during the database
operation.
5. System shows error messages.

Output Subsequent page will be displayed.

Login:

Table 2: Use Case of Login Function

 Page 22

Logout:
Use Case No. 3
Use Case Name Logout
Actors: Admin, Teacher
Descriptions This module helps the admin and Teacher to Logout.
Pre-conditions The user must be Logged in to the website.
Normal Course Events 1. The user clicks on Logout button.
2. DB connection terminated.
3. The website users Logout successfully.
4. The website will be directed to homepage.

Alternative Courses In case, user accidentally closes the tab then the user will be
automatically logout from her/his
account but it is recommended to Sign out from the account using
“Sign Out” option for security
Purposes.

Table 3: Use Case of Logout Function

Database Updating:
Use Case No 4
Use Case Name Database Updating
Actors: Admin
Descriptions This module helps the admin to maintain and update the
database.
Pre-conditions The user must be a member of the system.
Input Updated data
Normal Course Events 1. Users enters data to be updated
2. Users clicks on update button
3. Data stored into database

Alternative Courses 1. Incorrect data is entered.

2. Error message appears.
3. If, connection to the database fails, system
error message appears.
4. Continue with step 1 in the normal course
Events.
Output Database is successfully updated

Table 4: Use Case of Database Updating Function

 Page 23

Profile Updating:
Use Case No 5
Use Case Name Profile Updating
Actors: Admin, Teacher
Descriptions This module helps admin and teacher to update their profile.
Pre-conditions The user must be logged on to the system.
Input Information to be modified.
Normal Course Events 1. The user must be logged on to the system
which is defined in use case 1.
2. Users click on their Profile picture or the
Profile tab.
3. The system retrieves user information from
DB and shows the information on new page.
4. The user clicks on Update Profile button.
5. The user can update his/her profile in desired
information field.
6. The user clicks on Save Button.
7. The user profile is updated.

Alternative Courses 1. The system cannot access the DB.

2. The system redirects to the homepage.
3. The system puts a message on the top of the window about
the problem.
4. Continue with step 2 in the normal course
events.

Output User Profile Information will be updated.

Table 5: Use Case of Profile Updating Function

 Page 24

View:
Use Case No 6

Use Case Name View

Actors: Admin, Student, Teacher

Descriptions This module helps the admin to view the performance of the staff based on the feedback.
This module helps the teacher to view their feedbacks subject
wise.
This module helps the students to review the form that
they have filled.

Pre-conditions Admin should be logged on to the system.

Student should have filled their details correctly.

Input Click of a button

Normal Course 1. The Admin selects the name of the concerned

Events staff for viewing his performance both individually and department-wise.
2. The Student can view the feedback before clicking on the submit button.
3. The teacher can view their feedbacks subject
wise.

Alternative Courses
1. An error message appears.
2. The user will not be able to view the desired page.

Output The pages are displayed successfully.

Table 6: Use-Case of View Function

 Page 25

Activation of Portal:

Use Case No 7
Use Case Name Activation of Portal

Actors: Admin
Descriptions This module activates the feedback portal to accept responses from
students and informs the students that the portal has been activated.
Pre-conditions The user must be logged on to the system.
Input Click of the button.
Normal Course Events As the “activate portal” button is clicked, the portal is activated
and the mail to students is sent simultaneously.
Alternative Courses An error message appears if mails are not sent successfully.

Output Portal is activated along with a timer showing the time for which
portal is activated.

Table 7: Activation of Portal

Entering Details:

Use Case No 8
Use Case Name Entering Details

Actors: Student
Descriptions This module helps the admin to enter their
details
Input Name, smart card ID
Normal Course Events 1. Users enter the details.
2. Users click button.
3. System connects to database.
4. Their details are validated.
[Link] proceeds to use-case 11
Alternative Courses 1. Incorrect details entered.
2. Database connection not established.
3. Error message appears.
3. An error may occur during the database
operation.
4. System shows error messages.
Output The user successfully directed to feedback filling page.

Table 8: Entering Details

 Page 26

Filling Feedback Form:

Use Case No 9
Use Case Name Filling Feedback
Actors Student
Descriptions This module helps the students to fill the feedback-form online.
Pre-conditions The student should already fill their details.
Input Response of the feedback
Normal Course Events 1. The user can select the button either warden or teacher.
2. For the teachers, minimum five responses are
given by the user.
3. For the teachers, minimum three responses are
given by the user.
4. The user clicks the Submit Button.
Alternative Courses 1. The Feedback is not recorded successfully.
2. The user clicks the Submit Button without entering the
appropriate input.
3. Database connectivity failure.
4. Error message will appear.

Output The user is directed to use case 10.

Table 9: Filling Feedback Form

Receiving Confirmation:

Use Case No 10
Use Case Name Receiving Confirmation

Actors: Student

Descriptions This module sends the feedback submission

confirmation mail.
Input As soon as use case 9 is completed
Normal Course Events Automatic mail is sent.

Alternative Courses Error message appears when mail is not sent.

Output The mail is sent successfully.

Table 10: Receiving Confirmation

Receiving reminders:
 Page 27

Use Case No 11
Use Case Name Receiving reminders
Actors: Student
Descriptions This module will send the mail to the students who have not
filled the feedback form on the given time period.
Pre-conditions Students should not have filled the form.
Input No input
Normal Course Events 1. The students are selected from DB to whom the mail is
to be sent.
2. The mail will be sent to the selected students.

Alternative Courses 1. The student will not receive the mail.

2. Error message appears.

Output Mail is successfully sent.

Table 11: Receiving Reminders

2.6Other Nonfunctional Requirements

2.6.1 Performance Requirements

It will be attainable only at the end of semester. Admin should

have an account to enter the system; if user does not have an
account then user can only see the information which will be
displayed on the homepage of the web-site. Student will be
able to fill the feedback while the portal is activated.

2.6.2 Security Requirements

The authorization mechanism of the system will block the

unwanted attempts to the server and also the system will
authorize privileges to the user. For different types of users,
Page 28

there are different levels of authorization. The confidentiality

of the student will be guaranteed.
3. Software Design Specification

The Software Design Specification (SDS) sections provide you with guidelines
related to the structure and the contents of SDS document. The Software Design
Specification document includes at least these sections.

For the project, your team may have good reasons for wanting to deviate from this
proposed outline. If a section is not applicable in your case, do not delete it;
instead, give the topic heading and write "Not applicable".

You will note that there is some overlap in the content between different
documents (i.e. the User Requirements Specification Document and the Software
Design Specification Document.) This redundancy allows each document to stand
on its own.

The Software Design Specification Outline

3.1 Introduction

3.1.1 Purpose of this document

 The purpose of the Software Design Document is to provide a
description of the design of a system fully enough to allow for
software development to proceed with an understanding of what is
to be built and how it is expected to built.
 The SDS shows how the software system will be structured to
satisfy the requirements identified in the SRS.
 It is a translation of requirements into a description of software
structure, software components, interfaces and data necessary for
Page 29

the implementation phase.  Thus, SDS is the blue print for the
implementation activity.

3.1.2 Scope of the development project

“OFS” is a web-based service which aims to make the feedback
collection system labour-saving, cost effective and time efficient.
The scope of the project can be listed as under:
 This site aims to provide a special functionality to Banasthali
users of filling the feedback form online and analyzing that data
simultaneously.
 Non-Banasthalites will not be able to gain any functionality of
the software due to confidentiality of information.
 The identity of the student and their individual response will
not be disclosed.
 Reminders will be mailed to the students who have not yet
filled the feedback form before the closing of the portal.
 Admin will be responsible to update overall database of the
website which includes the updating of faculty and warden details.
 As per the department entered by the student, the name of the
teachers will be fetched from the database.
 As per the hostel entered by the student, the name of the
wardens will be fetched from the database.
 This facility increases the overall accuracy of the feedback
collection procedure.
 Three types of users will be using this website:
4) Admin
5) Teacher
6) Student

3.1.3 Definitions, acronyms, and abbreviations

 DFD- Data Flow Diagram
Page 30

 JSP- Java Server Page

 E-R Diagram- Entity Relationship Diagram
 SDS- Software design specifications
 Admin- The person who can access all areas of product. He is the person
who maintains the software and has the maximum rights.
 Database- Collection of interrelated data that provide a way to look at
and interact with all the information on the World Wide Web.

3.1.4 Overview of document

Overview of document The rest of the SDS consists of the
following parts:-
 System Architecture Design includes Architectural
design, Structure Chart & DFD.
 Data Design includes E-R diagrams and Database
Description.
 User Interface Designs

3.2 System architecture description:

Page 31

User 1-TIER

Webserver (Glassfish 2-TIER

with JSP)

3-TIER
DERBY DATABASE

3.2.1 STRUCTURE CHART

Page 32

3.2.2 Decomposition Description:

[Link] Data Flow Diagram-
 DFD is a graphical representation of a system that shows data
flows to, from and within the system.
 These are used to depict specific data flows from both
physical & logical view point.
 The DFD's are divided into different levels starting from 0th
level until we get the final description of system.

0-LEVEL DFD FOR ONLINE FEEDBACK SYSTEM

Page 33

1-LEVEL DFD FOR ONLINE FEEDBACK SYSTEM

Page 34

2-LEVEL DFD FOR ADMIN AFTER LOGIN

Page 35

2-LEVEL DFD FOR ADMIN'S VIEW PERFORMANCE

Page 36

2-LEVEL DFD FOR STUDENT FILLING TEACHER’S FORM

2-LEVEL DFD FOR STUDENT FILLING WARDEN’S FORM

Page 37

2-LEVEL DFD FOR STUDENT GIVING FEEDBACK

Page 38

4. Data Design:
4.1 E-R DIAGRAM-
Representations of cardinality used:
 1: N - one to many
 1:1 - one to one
 N: N - many to many
Page 39

4.2 Databases:
 In this we include, maintain & format Databases and its tables.
 The tables corresponding to each of the entity, holding the information
about them are designed.
 The tables have the fields, their description, and their data type as well as
integrity constraints.
 Page 40

STUDENT TABLE

Field Type Constraints Description

S_id Varchar (20) Primary key Smart card id of the

Student

S_fname Varchar(20) Not Null First name of the

Student

S_lname Varchar (20) Last name of the

Student

Course Varchar (20) Not Null Course of the Student

Sem Numeric (2) Not Null Semester of student

enrollment

Dept Varchar (20) Not Null Department of the

student

Email Varchar (20) Not Null Email id of the

Student

H_name Varchar (20) Not Null Hostel of the student

chk Boolean Student has filled the

feedback or not

TEACHER TABLE

Field Type Constraints Description

T_id Varchar(20) Primary key Smart card id of the

Staff member
T_name Varchar(20) Not Null First name of the Staff
member
Dept Varchar(20) Not Null Department
 Page 41

Gender Char(1) Not Null Gender

Ph_no Numeric(10) Phone no. of the Staff

member
Email_id Varchar(20) Not Null Email id of the Staff
member
pass Varchar(20) Not Null Password of the Staff
member
SUBJECT TABLE

Field Type Constraints Description

T_id Varchar(10) Foreign Key Smart card id of the

Teacher
Sub_id Varchar(10) Primary key Id of the Subject

Sub_name Varchar(30) Not Null Teaching subject of the

teacher

WARDEN TABLE

Field Type Constraints Description

W_id Varchar(10) Primary key Smart card id of the

Warden
W_name Varchar(20) Not Null name of the Warden

h_name Varchar(20) Not Null hostel of the Warden

email Varchar(20) Not Null Email of the Warden

ADMIN TABLE

Field Type Constraints Description

 Page 42

A_id Varchar(10) Primary key Smart card id of the

Admin
E_id Varchar(20) Not Null E-mail of the Admin

Name Varchar(20) Not Null Name of the Admin

Password Varchar(20) Not Null Password of the

Admin

TEMP_T_PERFORMANCE TABLE

Field Type Constraints Description

T_id Varchar(10) Not Null Smartcard ID of

the Teacher

Sub_id Varchar(10) Not Null Subject ID of the

Student

Q1 Numeric(3) Not Null Points given to the

teacher in the given
question

Q2 Numeric(3) Not Null Points given to the

teacher in the given
question

Q3 Numeric(3) Not Null Points given to the

teacher in the given
question

Q4 Numeric(3) Not Null Points given to the

teacher in the given
question
 Page 43

Q5 Numeric(3) Not Null Points given to the

teacher in the given
question

Q6 Numeric(3) Not Null Points given to the

teacher in the given
question

Q7 Numeric(3) Not Null Points given to

the teacher in
the given
question
Q8 Numeric(3) Not Null Points given to
the teacher in
the given
question
Q9 Numeric(3) Not Null Points given to
the teacher in
the given
question
Q10 Numeric(3) Not Null Points given to
the teacher in
the given
question
Q11 Numeric(3) Not Null Points given to
the teacher in
the given
question
Q12 Numeric(3) Not Null Points given to
the teacher in
the given
question
Q13 Numeric(3) Not Null Points given to
the teacher in
the given
question
Q14 Numeric(3) Not Null Points given to
the teacher in
the given
question
Q15 Numeric(3) Not Null Points given to
the teacher in
the given
question
 Page 44

FINAL_T_PERFORMANCE TABLE

Field Type Constraints Description

T_id Varchar(10) Not Null Smartcard ID of

the Teacher

Sub_id Varchar(10) Not Null Subject ID of the

Student

Q1 Numeric(4,2) Not Null Average points

given to the teacher
in the given
question
Q2 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q3 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q4 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q5 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q6 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q7 Numeric(4,2) Not Null Average points
given to the teacher
in the given
 Page 45

question
Q8 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q9 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q10 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q11 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q12 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q13 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q14 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Q15 Numeric(4,2) Not Null Average points
given to the teacher
in the given
question
Percentage Numeric(4,2) Not Null Final Evaluated
Percentage of
Teacher

IND_WARDEN_PERFORMANCE TABLE

Field Type Constraints Description

W_id Varchar(10) Not Null Smartcard ID of the

Warden
 Page 46

h_name Varchar(10) Not Null Hostel of the Student

Q1 Numeric(3) Not Null Points given to warden in

the given question
Q2 Numeric(3) Not Null Points given to warden in
the given question
Q3 Numeric(3) Not Null Points given to warden in
the given question
Q4 Numeric(3) Not Null Points given to warden in
the given question
Q5 Numeric(3) Not Null Points given to warden in
the given question
Q6 Numeric(3) Not Null Points given to warden in
the given question
Q7 Numeric(3) Not Null Points given to warden in
the given question
Q8 Numeric(3) Not Null Points given to warden in
the given question
Q9 Numeric(3) Not Null Points given to warden in
the given question
Q10 Numeric(3) Not Null Points given to warden in
the given question

FINAL_W_PERFORMANCE TABLE

Field Type Constraints Description

W_id Varchar(10) Not Null Smartcard ID of the

Warden
h_name Varchar(10) Not Null Hostel of the Student

Q1 Numeric(4,2) Not Null Average of points given

to warden in the given
question
Q2 Numeric(4,2) Not Null Average of points given
to warden in the given
question
Q3 Numeric(4,2) Not Null Average of points given
to warden in the given
question
Q4 Numeric(4,2) Not Null Average of points given
to warden in the given
question
Q5 Numeric(4,2) Not Null Average of points given
to warden in the given
 Page 47

question
Q6 Numeric(4,2) Not Null Average of points given
to warden in the given
question
Q7 Numeric(4,2) Not Null Average of points given
to warden in the given
question
Q8 Numeric(4,2) Not Null Average of points given
to warden in the given
question
Q9 Numeric(4,2) Not Null Average of points given
to warden in the given
question
Q10 Numeric(4,2) Not Null Average of points given
to warden in the given
question
Percentage Numeric(4,2) Not Null Final Evaluated
Percentage of Warden

HOSTEL TABLE

Field Type Constraints Description

H_name Varchar(10) Primary key Hostel of the

Student

COURSE TABLE

Field Type Constraints Description

C_id Varchar(10) Primary key Course ID of

the Student
cname Varchar(20) Not Null Course name of
student
Page 48

5. User Interface
[Link] Page

[Link] Interface
2.1 Login Page

2.3Welcome Page
Page 49

2.3Insert Student

2.4Send Mail
Page 50

2.5Send Remainder Mail

2.4Teacher’s Evaluation Page

Page 51

2.5Warden’s Evaluation Page

Page 52

3. Teacher Interface
3.1 Login Page

3.2 View Performance

Page 53

4. Student Interface
4.1Student Entering Page
Page 54

4.2 Filling Form

4.2.1 For Teacher

4.2.2 For Warden

Page 55

After Filling all the Feedbacks-----------------

4.3Thank You Page

5. Help Page
Page 56

6. References
[1] Pressman Roger S., Software Engineering “A Practitioner’s
Approach”
Fifth Edition, McGraw-Hill Publication, 2000.
[2] NavatheShamkant B., Fundamentals of Database Systems,
Fifth Edition, Pearson Publication.
[3] Schildt Herbert, the Complete Reference Java 3.0
Third Edition, Tata McGraw-Hill.
[4] IEEE STD 830-1998, IEEE Recommended Practice for
Software Requirement Specifications.
[5] Pressman Roger S., Software Engineering “A Practitioner’s Approach”
Fifth Edition, McGraw-Hill Publication, 2000.
[6] NavatheShamkant B., Fundamentals of Database Systems,
Fifth Edition, Pearson Publication.
[7] IEEE STD 830-1998, IEEE Recommended Practice for Software
Requirement Specifications.