online examination system (project report)

| 1 P a g e

NIT Calicut, MCA 2014

OES | VIVEKA NAND KUMAR

| 1 P 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.

| 2 P 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.

| 3 P 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.

| 4 P 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.

Stimulus/Response sequences

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.

| 5 P 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.

| 6 P 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.

| 7 P 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.

| 8 P 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.

| 9 P 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.

| 10 P 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.

| 11 P a g e



3. DESIGN DOCUMENT

3.1 CLASS DIAGRAM

Fig. 3.1 Class Diagram (Created by gliffy online software)

| 12 P 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)

| 13 P a g e



3.3 USE CASE DIAGRAM

Fig. 3.4 Use Case Diagram (Created by Umlet software)

| 14 P a g e



3.4 ACTIVITY DIAGRAM

Fig. 3.5 Activity Diagram for Add question (Created by Umlet soft)

| 15 P a g e



Fig. 3.6 Activity Diagram for Exam (Created by Umlet software)

| 16 P a g e



Fig. 3.7 Activity Diagram Evaluation (Created by Umlet software)

| 17 P a g e



3.5 E-R DIAGRAM

Fig. 3.8 E-r Diagram (Created by gliffy online software)

| 18 P 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

| 19 P 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

| 20 P 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

| 21 P 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

| 22 P a g e



7. Notice:

8. Course Registration:

Attribute Name Data Types Length Key Constraint


Roll Number Varchar 10

Primary Key Session 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

| 23 P 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

| 24 P 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

| 25 P 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

| 26 P 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

| 27 P 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

| 28 P 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.

| 29 P 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=‟‟;

| 30 P 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);

| 31 P 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.

| 32 P 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.

| 33 P 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.

| 34 P 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.

| 35 P 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.

| 36 P 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

http://www.jsptut.com/index.html

http://www.tutorialspoint.com/ajax/

http://www.roseindia.net/jsp/