online Examination System (project report)

| 1P a g e
NIT Calicut, MCA 2014
OES | VIVEKA NAND KUMAR

| 1P a g e
1. INTRODUCTION
1.1 PROBLEM DEFINITION
Online Examination System (OES) is an online project built to help to conduct online
examination. After having this solution student can complete the examination and get the
result in less expected time. Users of this project will be student, faculty and administrator.
Details of the project with respect to each aspect are as follows.
Objective of implementing OES is to help in efficient use of resources by multiple users on
same time. It fulfills the requirements of the institutes and boards to conduct the exams
online. This system allows candidates to register and take an examination in an online
manner where the traditional paper and pen need not be used.
High Level Functional Specifications
a) User should be able to login into the system.
b) User authentication.
c) Upload/download study material.
d) Get faculty information.
e) Faculty set the question paper and store with specific paper code and store in question
bank.
f) User will appear in examination and feed answer in database.
f) Each user has separate profile.
g) System will keep previous test paper and student record, that is more secure than existing
system.
h) System automatically select question from database.
i) The logs of appeared candidates and their marks store in database for future use.
j) System also store attendance record of student, who will appear in examination.
The whole project will be implemented in JSP and Mysql.

| 2P a g e
1.2 BACKGROUND
To understand more about the project first should know background details like why it is
necessary to build such kind of software, what are the problems in the traditional system. The
traditional system is an offline system which allows the institute to conduct exam manually.
In traditional examination system student and institute need to purchase paper and some
objects related to exams. In traditional examination system faculty provide question paper
and answer sheets to students, after completion of examination, they collect all answer sheets
and evaluate one by one, so it will take much time to publish the results. All student‟s report
are kept in register and marks details are kept on a paper. If missed the scorecard and again
want to take scorecard then it will take long time and some penalty also, because institute
provide scorecard to students only once.
Observation
a) Result processing is slow due to paperwork.
b) Reviewing become time consuming.
c) Searching of any student‟s scorecard as well as answer sheets is tedious.
d) Students request more minute after the normal examination‟s time that is un-authorized.
e) Excessive use of paper contributes large number of environment problems.
f) The chance of paper leakage are more in current system as compared to proposed system.
1.3 MOTIVATION
This system will be able to handle many services to take care of all student‟s records in a
quick manner. This system will save time and paper work and make examination more
systematic and disciplined. The web enabled examination system can be accessed from
anywhere through the internet. Online examination system is cheaper than traditional system.
On completion of this online examination system institution can save money and many hours
of human work. In this system students get the result just after completion of examination in
objective test. This system support objective as well as short descriptive question. At present
time many companies are following automatic system for aptitude test in placement.

| 3P a g e
2. SOFTWARE REQUIREMENT SPECIFICATION
Criticality Scale: Very Low (1) – Low (2) – Medium (3) – High (4) – Very High (5)
1. Very Low: Items that can be eliminated should serious system constraints encountered.
2. Low: Items that are extra functionalities that may be evaluated for possible elimination.
3. Medium: Items that are strongly desired by the users of the system.
4. High: Items which are required in the system in order for lower criticalities to function.
5. Very High: Items that are mission critical and that the system cannot function without.
2.1 FUNCTIONAL REQUIREMENTS
2.1.1 Display homepage of OES.
Description
This feature provides an entry point to the user from where he can login into
OES to appear in examination.
Stimulus/Response sequences
As user opens his browser and he enters the domain name in the address bar, the DNS
server will map the domain to IP address of the host server and an TCP connection is
setup between the user browser and the server. Then using HTTP protocol the server
will send the Homepage of OES to the user‟s browser and if everything goes well user
will be able to see the homepage.
Criticality
3
Technical issues
Precondition: The user enters the domain name of OES in the address bar of browser.
Post condition: The browser properly displays the website‟s homepage.
Risks: The browser is unable to render homepage properly because it is very old version.

| 4P a g e
2.1.2 User Login
Description
User must login with a valid login id and password in order to appear in examination.
User comes across the login button on the homepage of OES, on clicking it the user is
directed to the login page of the system. He/ She type his/her respective user id and
password and clicks on login button.
Criticality
5
Technical issues
Precondition: The user is a valid user and has entered his login credentials in the fields
provided.
Post-condition: The user has successfully logged into the system.
Risks: The system may authenticate an unauthorized user.
2.1.3 User authentication.
Description
This feature will authenticate whether the user is a valid user or not by validating if he
has already registered with the OES or not.
As user opens the website and clicks on the login button he/she will be directed to login
verification page. System will check from database the combination of login id and
password entered, if details are found correct then system will direct the user tothe
welcome user page, Otherwise he will be shown an error message.
Criticality
5
Technical issues
Precondition: The user is directed to login page.
Post-condition: The system shall either accept or reject the user‟s credential if user input is
wrong then system give a message „your information is not available‟.
Risks: The connectivity between front end and database may not work correctly.

| 5P a g e
2.1.4 User registration
Description
This feature allows user registration. If user is not registered he will not be able to appear in
examination, once he/she has registered himself he/she will be able to appear in examination.
User visits the homepage of OES where he will see Login/ Register button. By clicking
the Login/ register button he will be directed to registration cum login page. User enters
his correct details and click register. If all the fields are filled in correct format the
system will register the user and store his information in the database, if the entered
details are not according to the mentioned format he will be shown alert messages
indicating the correct format of the inputs system expect.
Criticality
4
Technical issues
Precondition: User fills in his/her information and click register.
Post-condition: The system is able to successfully store user‟s information in database or
otherwise show an error.
Risks: The system might fail to connect to database.

| 6P a g e
2.1.5 Update Profile
Description
This feature allows users to update their profile.
User visits OES. He then enters his login credentials and if the entered credentials are
correct then, he is directed to his user page. There he has an option of updating his
profile. He clicks on the update profile button.
Criticality
4
Technical issues
Precondition: User clicks on the update profile button.
Post-condition: The system updates user‟s new details in the database.
Risks: The system might fail to connect to database.
2.1.6 Examination
Description
This feature allows users to appear in examination.
correct then, he is directed to his user page. There he has an option of examination after
click on this option one another page open, in this page user fill all record then, he
clicks on the submit button.
Criticality
4
Technical issues
Precondition: User clicks on the examination button.
Post-condition: After select/write the answer then system save his/her response in the
database.
Risks: The system might fail to save response in database.

| 7P a g e
2.1.7 Add Question
Description
This feature allows users to add question paper for examination.
correct then he is directed to his user page. There he has an option of add question. He
clicks on the add question button and add enter subjective/objective question and then,
he click on submit button.
Criticality
4
Technical issues
Precondition: User clicks on the add question button.
Post-condition: The system add question details in the database.
Risks: The system might fail to enter question in database.
2.1.8 Evaluation
Description
This feature allows users to evaluate subjective question paper.
correct then he is directed to his user page. There he has an option of evaluation. He
clicks on the evaluation button and evaluate subjunctive‟s answer and then, he click on
submit button for store marks and comments in database.
Criticality
4
Technical issues
Precondition: User clicks on the evaluation button.
Post-condition: The system submit all evaluation details in the database.
Risks: The system might fail to enter evaluation response in database.

| 8P a g e
2.1.9 Upload Result
Description
This feature allows users to upload result.
correct then he is directed to his user page. There he has an option of upload result. He
clicks on the upload result button and upload all record related to result and then, he
click on submit button for store marks in database.
Criticality
4
Technical issues
Precondition: User clicks on the upload result button.
Post-condition: The system submit all result details in the database.
Risks: The system might fail to enter result in database.

| 9P a g e
2.2 NON FUNCTIONAL REQUIREMENTS
2.2.1 Performance Requirements
 The system shall function in real time, any operation on the stored information,
triggered by the user shall complete in less than 10 seconds. 
 The system shall allow simultaneous use by at least 100 users, without any problem. 
 The system will try to retain the integrity of data by ensuring backups. 
 The software shall be compatible with Windows, Linux or any other OS, with 256
MB RAM or above. 

2.2.2 Security Requirements
 In order to appear in examination, users must first authenticate themselves by entering
a username and password. The system shall not allow access if the user fails to
provide correct login information. 
 Only administrator will be allowed to change the database directly to maintain the
integrity of data. 
 All the confidential details will be encrypted and then only stored in the database.
The system shall never send an unencrypted password over the internet. 


| 10P a g e
2.2.3 Software Quality Attributes
 Flexibility: The system shall be flexible enough so that there is a scope of making
Changes in the system easily so that it will work fine for coming next 5 Years at
least. 
 Maintainability: The system shall be easily maintainable by the administrator. Other
programmers shall be capable of easily modifying and updating code by using the
documentation provided with the system. 
 Testability: The system shall be tested with different types of users using it. 
 Reliability: The system shall be accessible at any time, with the help of internet. 
 Usability: The system shall be user friendly i.e it should be easy to use. 
 Portability: The system shall be compatible with the following web browsers:
Internet Explorer, Mozilla Firefox, Google Chrome, Safari and Opera and the
following Operating systems: Windows (XP, Vista, 7, 8), Linux, Mac OS. 
 Reusability: The system shall be properly coded and well-documented so that in
future it can be used by other college too.




















| 11P a g e
3. DESIGN DOCUMENT
3.1 CLASS DIAGRAM
Fig. 3.1 Class Diagram (Created by gliffy online software)

| 12P a g e
3.2 DATA FLOW DIAGRAM
3.2.1 Context level
Fig. 3.2 Context Diagram (Created by Edraw Max 7.5 software)
3.2.2 Level 1
Fig. 3.3 Level 1 Diagram (Created by Edraw Max 7.5 software)

| 13P a g e
3.3 USE CASE DIAGRAM
Fig. 3.4 Use Case Diagram (Created by Umlet software)

| 14P a g e
3.4 ACTIVITY DIAGRAM
Fig. 3.5 Activity Diagram for Add question (Created by Umlet soft)

| 15P a g e
Fig. 3.6 Activity Diagram for Exam (Created by Umlet software)

| 16P a g e
Fig. 3.7 Activity Diagram Evaluation (Created by Umlet software)

| 17P a g e
3.5 E-R DIAGRAM
Fig. 3.8 E-r Diagram (Created by gliffy online software)

| 18P a g e
3.6 DATABASE DESIGN
1. Student:
Attribute name Data type Length Key Constraint
Name Varchar 40 Not null
Roll Number Varchar 12 Primary Key
Date-of-Birth Date DB default Not null
Gender Char 8 Not null
Department Varchar 40 Not null
Country Varchar 30 Not null
Course Varchar 30 Not null
E-mail Varchar 25 Not null
Mobile Integer 13 Not null
Image LongBlob DB default Not null
User-Id Varchar 15 Not null
Password Varchar 20 Not null

| 19P a g e
2. Faculty:
Designation Varchar 12 Not null
Date-of-Birth Date DB default Not null
Gender Char 8 Not null
Specialty Varchar 30 Not null
E-mail Varchar 25 Not null
Mobile Integer 13 Primary key
Image LongBlob DB default Not null
User-Id Varchar 15 Not null
Password Varchar 20 Not null

| 20P a g e
3. Objective Test:
Paper Code Varchar 15 Primary Key
Question Number Integer DB default
Question Varchar 150 Not null
Answer Varchar 3 Not null
Option-1 Varchar 30 Not null
4. Subjective Test:
Attribute Name Paper Code Question Number Question
Data type Varchar Integer Varchar
Length 30 DB default 200
Key Constraint
Primary Key
Not null

| 21P a g e
5. Permission:
Attribute Name Faculty Name Date-Of-Birth Secure-Code
Data type Varchar Date Varchar
Length 40 DB default 20
Key Constraint Not null Not null
Primary Key
6. Store(Result):
Attribute Name Data Type Length Key Consraint
Scorecard-
Id(Auto_increment)
Integer DB default
Primary Key
Roll Number Varchar 15
Semester Varchar 20
Subject Code Varchar 15
Full Marks Integer DB default Not null
Obtained Marks Integer DB default Not null
Grade Integer 2 Not null

| 22P a g e
7. Notice:
8. Course Registration:
Attribute Name Data Types Length Key Constraint
Roll Number Varchar 10
Primary KeySession Varchar 15
Subject Code Varchar 10
Subject Name Varchar 40 Not null
Attribute Name Member-Type Department Messege Messege-
Id(Auto_increment)
Data type Varchar Varchar Varchar Integer
Length 20 40 100 DB default
Key Constraint Not null Not null Not null Primary key

| 23P a g e
9. Exam Routine:
Centre-Name Varchar 30 Not null
Date-of-Exam Date DB default Not null
Subject-Name Varchar 40 Not null
Centre-Id Varchar 10
Primary Key
Subject-Code Varchar 10
Time Time DB default
10. Feedback:
Attribute
Name
Messageid(Auto
_increment)
From Point To Point Department Feedback
Data type Varchar Varchar Varchar Varchar Varchar
Length 10 40 40 40 100
Key
Constraint Primary Key
Not null Not null Not null

| 24P a g e
11. Solution:
Attribute Name Comment-
id(Auto_increment)
E-mail Comment
Data type Integer Varchar Varchar
Length DB default 30 100
Key Constraint
Primary key
Not null
12. Store-Faculty (Course-Registration)
Subject-Name Varchar 30 Not null
Designation Varchar 30 Not null
Name Varchar 40
Primary Key
Subject-Code Varchar 10
Session Varchar 15

| 25P a g e
13. Subjective Answer:
14. Secure Code:
Attribute
Name
Paper-Code Exam Type One-Time-Password
Data type Varchar Varchar Varchar
Length 20 30 20
Key
Constraint
Primary Key Not null Not null
15. Attendance:
Roll
number
Subject-
code
Subject-
name
Date-of-
exam
Course Department Test Name
Varchar Varchar Varchar Date Varchar Varchar Varchar
10 10 40 Db default 40 40 15
Primary Key Not null Not null Not null Not null Not null
Attribute
Name
Answerid(Auto
_increment)
Roll-Number Paper-Code Subject Code Answer
Data type Integer Varchar Varchar varchar Varchar
Length DB default 10 10 10 200
Key
Constraint
Primary Key Not null Not null Not null Not null

| 26P a g e
16. Exam-Routine:
Department Course Date-of-Exam Semester Exam_centre
Varchar Varchar Varchar Varchar Varchar
40 30 Date 10 40
Primary key Not null Not null Not null
17. Objective Answer:
Answer-
id(Auto_incr
ement)
Roll Number Paper-code Subject-
code
Answer Question
No:
Integer Varchar Varchar Varchar Char Integer
DB default 10 10 10 4 DB default
Primary Key Not null Not null
18. Objective Result:
Answerid(Auto
_increment)
Roll Number Paper-
Code
Attempted Total
Question
Mark-
Obtained
Integer Varchar Varchar Integer Integer Integer
DB default 10 10 DB default DB default DB default
Primary Key Not null Not null Not null Not null

| 27P a g e
19. Pdf Store:
Document-id(Auto-
Increment)
Roll/Name-of-faculty Document name Document
Integer Varchar Varchar LongBlob
DB default 30 30 DB default
Primary key Not null Not null Not null
20. Tested Record
Record-Id Roll Number Paper-Code Subject-Code Marks
Integer Varchar Varchar Varchar Integer
DB default 10 10 10 DB default
Primary Key Not null Not null Not null

| 28P a g e
4. IMPLEMENTATION
4.1 SOFTWARE INTERFACE
 Back-end is managed by MySQL 5.0.3.
 To make interactive menu we will be using Jquery menu maker.
 Supported Browser versions- Chrome Latest release, Mozilla Firefox 4.0 +, Internet
Explorer 10+, Safari 5.0+.
 Operating System- Windows(XP, Vista, 7,8), Linux, MacOS.
4.2 IMPLEMENTATION CONSTRAINT
 Front-end will be implemented in JSP, HTML, CSS3, JavaScript and Ajax.
 Programming language JAVA 1.7 and higher.
 Dedicated server with a minimum of 30 GB free space.
4.3 REAL CHALENGES
Readability
This characteristics measures how easy is to read and understand the code and it‟s
purpose. The main factors that affect the readability are: consistent coding standards,
consistent coding standards, clean logic. The higher the readability, the less time a
new developer will need to understand what the current code is doing.
Extensibility
This characteristic measures how easy is to add new functionality, a good design will
likely provide high extensibility. The higher the extensibility, the less time for a
developer to add new functionality as changes in current code shouldn‟t be necessary.
User friendly GUI( Graphical User Interface)
Good GUI doesn‟t mean good looking GUI. Through good looking GUI is very much
needed but, A good website must be user friendly because the whole point of web
development is based on it.

| 29P a g e
Security of application
These days, high-profile security blunder seem to crop up on a daily basis. We‟ve seen
viruses spread with amazing speed, swarms of compromised computers wielded as weapons,
a never-ending arms race against spammers, and many, many reports of identity theft from
hacked Web sites.
Every Web developer needs to treat security as a fundamental aspect of Web programming.
Unfortunately, it turns out that implementing security is hard – attackers need to find only a
single vulnerability, but defenders have to protect every single one.
I‟ll give a short synopsis of security problems as they apply to website.
SQL Injection
SQL injection is a common exploit in which an attacker alters Web page parameters (such as
GET/POST data or URLs) to insert arbitrary SQL snippets that a naive Web application
executes in its database directly. It‟s probably the most dangerous – and, unfortunately, one
of the most common – vulnerabilities out there.
This vulnerability most commonly crops up when constructing SQL “by hand” from user
input. For example, imagine writing a function to gather a list of contact information from a
contact search page:
First, our attempt at protecting our entire user records list that will fail with a cleverly
constructed query. Think about what happens if an attacker types "' OR 'a'='a" into the query
box. In that case, the query that the string interpolation will construct will be:
Because we allowed unsecured SQL into the string, the attacker‟s added OR clause ensures
that every single row is returned.
However, that‟s the least scary attack. Imagine what will happen if the attacker submits:
Yikes! Our entire contact list would be deleted instantly.
SELECT * FROM student WHERE username = '' OR 'a' = 'a';
Delete from student where „a‟=‟a‟; or Select * from student where username=‟‟;

| 30P a g e
The Solution:
Login(request):
User=request.getParameter(“username”);
Pass=request.getParameter(“password”);
Select * from student where username=? And password=?;
User=rs.getString(1);
Pass=rs.getString(2);

| 31P a g e
4.4 SCREENSHOT OF THE TOOL
Figure 4.4.1
This is the home page of the website. Here user can register himself, download study
material, see faculty interested area, exam schedule and login.
Figure 4.4.2
This is the login page of this website. Here all user can login himself and change password.

| 32P a g e
Figure 4.4.3
This is the admin page. Here he can use all privilege. Such as: provide permission to faculty
for registration, respond query, view question bank e.t.c.
Figure 4.4.4
This is profile page of faculty. Here he can use all given privilege, such as add question,
evaluate
subjective answer-sheet, edit question and view previous papers.

| 33P a g e
Figure 4.4.5
This is the objective exam page. Here student can select answer in given option and submit.
Figure 4.4.6
This is the subjective exam page. Here student can feed answer in given textbox and submit.

| 34P a g e
Figure 4.4.7
This is the scorecard. That will generate by system.
Figure 4.4.8
This is objective question writer. Here faculty enter question, answer, and four option.

| 35P a g e
5. CONCLUSION
Basically, the system being developed is focusing on basic functionalities that are expected
by any of the possible user of the system. This software is web-based software with easily
extendible module. It can be used in any institution for conducting online examination. A
user friendly GUI is provided and all the functionality given in the functional requirement has
been implemented. It makes ease of work of conducting online examination of students and
publish result at the same time. It will reduce user work load and keep student record very
secure.

| 36P a g e
6. REFERENCES
[1] Pankaj Jalote, A concise introduction to software engineering, Springer, 2008.
[2] Shivam Sood MCA (2011-13), Final Project report on RMS,MCA Project report
2013,NIT Calicut.
[3] Vivek chopra, Jon eaves, Rupert jones, John t. bell: Beginning Javaserver Page Willey
Dreamtech India (p) Ltd. Edition 2005
[4] Utilizing Online Exams : Journal of college teaching and learning-2009 David L. Ralph,
Ph.D., Pepperdine University, USA
[5] Case study of a computer based examination system-2009 Andrew fluck, Darren pullen
and colleen harper, university of Tasmania.
[6] http://www.jsptut.com/index.html, Accessed on 13/1/2014 – 2/2/2014
[7] http:// www.tutorialspoint.com/ajax/ accessed on 15/4/2014
[8] http:// www.roseindia.net/jsp/ accessed on 18/3/2014-12/4/2014

online Examination System (project report)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to online Examination System (project report)

Similar to online Examination System (project report) (20)

Recently uploaded

Recently uploaded (20)

online Examination System (project report)