1

Chapter 1 INTRODUCTION

1.1 PURPOSE

The purpose of Electronic Descriptive Examination Management System is to achieve

better transparency, security and maintainability. It also saves lot of manpower, time and
logistics to conduct the examination, evaluate the answer scripts and announcing the results.

1.2 SCOPE

Proposed system allows the students to type the answers in the space provided for each
question. When students submit the exam, system automatically collects all the questions
and corresponding answers into a file and converts it into pdf and then uploads it to the
server by encrypting the person-specific details. Staff related to corresponding subject can
only access these answer sheets for evaluation and allots marks base on the performance.

Students can view their answer script and marks obtained for each question, when the
results are announced. It improves transparency and credibility on the examination system.
It will minimize the utilization of manpower to great extent.

1.3 EXISTING PROBLEMS

Present system conducts the exam manually where the student has to write the exams on the
paper with a pen. Answer sheets of all the students will be handed over to the invigilator.
The invigilator will submit the bundle to the university. There the concerned staff will do
evaluation of the papers. The person who evaluated the paper has to sign on the paper
indicating that he himself has evaluated the paper. After evaluating marks are allotted to the
student basing on his performance and then feed into the system
 2

1.4 STATEMENT OF THE PROBLEM

In this current system entire examination process is being conducted manually where there
is a lot of scope for security threats, improper evaluation. This system places lot of burden
over students in writing their exam, staff in evaluating the answers and entering the marks
separately in the system. It requires lot of man power to conduct the exam. . It provides less
security to the answer sheets of the students from third party manipulations. As mentioned
earlier, it takes extrinsic parameters like handwriting, presentation into consideration for
evaluation. It provides less transparency to the students from the evaluation process. It also
requires lot of man power for conducting the exams.

1.5 SIGNIFICANCE OF THE PROJECT

1. It is well secured pattern of conducting examinations, because once the student

submits the exam nobody has a right to change the content of the paper.
2. It also protects the answer sheets by hiding them from others except administrator and
the concerned staff.
3. It is very easy to handle the exams using this system because it reduces man power,
cost, and burden to all the stakeholders in handling the examinations.
4. It doesn’t take unnecessary parameters like handwriting into consideration in allotting
marks to the student, thereby providing efficiency in evaluating the paper.
5. It reduces the redundancy of work to great extent.
6. It also provides security and justice in evaluating the answer-sheets by encoding the
hall ticket number so that the evaluator can not know to whom this paper belongs.
7. It provides good user-friendliness to students in writing the examinations, staff in
evaluating the examinations, administrator in changing the settings of the system.
8. It allows administrator to change the question paper model, staff, students and loading
question paper into the database with less burden
 3

Chapter 2 REQUIREMENT SPECIFICATION

2.1 Product Perspective:

Electronic descriptive examination managing system is a computerized way of

conducting present day paper-based descriptive examinations in a university by providing
much user-friendliness to students, staff, invigilators and administrator.

Every student has to submit his user id, course, year of study, branch, and subject-code
details before taking the exam. After entering into the system he can answer to the question
paper. He has to answer the question paper in the text area provided to him for each question.
After writing the exam, the student has to upload answered document to the server. To protect
the answer sheet from illegitimate modifications, we have to convert it into PDF before
storing in the server.

Depending on the subject code, answer sheets belonging to a particular subject are
automatically uploaded to corresponding staff’s user. Staff member who is going to correct
this particular subject can access these answer sheets by logging into his account. After
evaluating the paper, marks are allotted for each answer depending on his performance. These
marks will be entered into the database by the staff after correcting the paper. Invigilator after
writing the exam gives the feedback about the examination process, which will be collected
by staff when he logged into the system.

In the evaluation process, staff after need to input marks obtained for each question
irrespective of choice, the system automatically chooses answers with highest marks into
account thereby reducing burden on the staff. Administrator maintains the system in order to
allot require resources for achieving the functionality.

2.2 Product Functions:

1. Identify a responsible administrator.

2. Register and maintain students, staffs, invigilators.
3. Admin needs to maintain student details.
4. Admin needs to maintain staff details.

1
)
.
 4

5. Admin needs to maintain invigilator details.

6. Student needs to login and take exam.
7. Staff needs to login and evaluate answer sheets.
8. Invigilator needs to login and report feedback after the exam.
9. Student can view his result after the evaluation of answer sheets by logging in.

2.3 User Classes and Characteristics:

The application involves different kinds of users namely Admin who maintains the system,
Student who can take an exam by logging into the system, Staff who can evaluate answer
sheets of students by logging into the system, Invigilator can report feedback after the
examination to the system.

Operating Environment

Software Requirement:

Programming Languages : Java

Operating System : Windows 95/98/XP
Server : Apache Tomcat 5.0
Data Base : Oracle 10g

Hardware Requirement (Minimum):

Hard Disk Drive : 40 to 80 Gb

Processor : 2.2 GHz Pentium P3 (or) P4.
Ram : 256MB Minimum
Faster Internet Connection : 128 kbps

2.4 Design and Implementation Constraints:

The application runs on java runtime interface .The web server Oracle10g should be
installed and started access should be made with the database .Any browser that allows state
management.
 5

2.5 User Documentation:

The product is provided with built-in manual that would help the end user use the system for
functioning.

2.6 External Interface Requirements:

2.6.1 User Interfaces:

The application is provided with keyboard shortcuts and a facility to use the mouse to trigger
the required actions. They act as shortcuts and provide an easy navigation within the software.

2.6.2 Hardware Interfaces:

The application concentrates on handling examination’s online and does have dependency on
the network and protocols. The application can also be executed from a standalone machine
without the above dependency.

2.6.3 Software Interfaces:

The incoming data to the product would be raw text data and outgoing data would be the
same data but HTML formatted. Java and Html provides with the required web forms.
Controls are used in them for user friendliness. The middle tier is Oracle 10g and acts as a
request/response oriented server. The data is stored, processed from the Ms-access database.

2.7 System Features:

2.7.1 Registration and security module:

This module identifies an administration user/account who is

responsible for the maintenance of the databases as well as the pilots. Maintenance of the
flights, the sectors and pilots are done through this module which performs the following:

2.7.2 Student:
a) Writing the exam
b) Uploading the answer paper
c) Viewing the results
 6

2.7.3 Staff:
a) Evaluating the answer papers
b) Allotting marks
c) Viewing Marks
d) Updating Marks
e) View Attendance

2.7.4 Admin:

a) Update student details

b) Update staff details
c) Update invigilator details
d) Load question paper

2.7.5 Invigilator:

a) Feedback on absentees students

b) Feedback on debarred students
c) Feedback on technical problems

2.8 OTHER NON FUNCTIONAL REQUIREMENTS:

2.8.1 Performance Requirements:

Good band width, less congestion on the network. Identifying the shortest route to
reach the destination.

2.8.2 Safety Requirements:

No harm is expected from the use of the product either to the OS or any data.

2.8.3 Product Security Requirements:

The product is protected from un-authorized users from using it. The system allows

only authenticated users to work on the application.

2.8.4 Software Quality Attributes:

The product is user friendly and its accessibility is from the client. The application is
reliable and ensures conducting of examinations smoothly. As it is developed in Java
it is highly interoperable with OS that have provided support for MSIL (Server
side)The system requires less maintenance as it is not installed on the client but
hosted on the ISP. The firewall, antivirus protection etc is provided by the ISP
 7

Chapter 3 METHODOLOGY

3.1 ANAYSIS:

Analysis is concerned with the primary abstractions and mechanism that are present in

the problem. The classes that are models these are identified along with their

Relationships to each other. In the analysis, only classes that are in the problem domain

are modeled. Analysis design contains:

 Use-case model
 Analysis model

3.1.1 USE CASE MODEL:

Listing the use cases that are involved in the use case diagram.

3.1.1.1 LIST OF USE CASES:

1. Login
2. Student details
3. Staff details
4. Exam settings
5. Invigilator details
6. Take exam
7. Submit exam
8. Cancel exam
9. View results
10. Evaluate paper
11. Change marks
12. Report feedback
13. Invigilate
14. View marks
 8

3.1.1.2 USE CASE DESCRIPTION TABLES :

1. Admin login:
 9
USE CASE NAME: Admin login USE CASE ID: 1
PARTICIPATING The Administrator, EOC, login (db).
ACTORS:
DESCRIPTION: The admin logs into the system and maintains the database.

PRE-CONDITION: The user must be an administrator

TYPICAL COURSE
OF EVENTS(Main Actor Action System Response
Flow):
Step 1: The admin clicks on admin
login
Step 2: The system displays the login page

Step 3: The admin needs to enter the

admin id, password and click on
login.
Step 4: The system authenticates and displays
admin homepage.

ALTERNATE FLOW :
AF 1: If admin presses others login
AF 2: If the admin types wrong password

POST-CONDITION: The system displays profile according to which the admin has asked.
NON FUNCTIONAL --------------------------------------------------------------------
REQ.

2. Others login:

USE CASE NAME: Others login. USE CASE ID: 2

PARTICIPATING Student, Staff, Invigilator, EOC, login(db)
ACTORS:
DESCRIPTION: The system authorizes the registered user according to the roles.
PRE-CONDITION: The user must be a registered user.
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: The user must click on others
login.
Step 2: The system displays the login interface.
Step 3: The users need to enter his
details according to his roles.
Step 4: Authenticates and displays the user home
page.
ALTERNATE FLOW :
AF 1: If the user enters other pages.
AF 2: If the user enters wrong details.

POST-CONDITION: The system opens profile according to the roles the users has been assigned.
-----------------------------------------------------------------------
NON FUNCTIONAL REQ.
 10

3. Student details:

USE CASE NAME: Student details. USE CASE ID: 3

PARTICIPATING The admin, EOC, database.
ACTORS:
DESCRIPTION: The admin will make student settings.
PRE-CONDITION: Only the admin can do the student settings.
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: The admin must login into the
system.
Step 2: The system displays the admin home page.
Step 3: The admin must click on student
details.
Step 4: The system displays the student details
page.
Step 5: The admin can do changes to the
students in the database.

ALTERNATE FLOW :
AF 1: The admin may not click on student details.

POST-CONDITION: Only the admin can view the student details.

NON FUNCTIONAL REQ. The logged in user must be an admin.

4. Staff details:

USE CASE NAME: Staff details USE CASE ID: 4

PARTICIPATING The admin, EOC, database.
ACTORS:
DESCRIPTION: The admin will make staff settings.
PRE-CONDITION: The registered user must be an admin.
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: The admin must log into the
system.
Step 2: The system displays the admin home page.
Step 3: The admin must click on staff
details.
Step 4: The system displays the staff details page.
Step 5: The admin may make changes to

the staff in the database.

ALTERNATE FLOW :
AF 1: The admin may not click on staff details.

POST-CONDITION: Only the admin may view the staff details.

NON FUNCTIONAL REQ. The logged in user must be an admin.
 11

5. Invigilator details:

USE CASE NAME: Invigilator details USE CASE ID: 5

PARTICIPATING The admin, EOC, the database.
ACTORS:
DESCRIPTION: The admin will make invigilator settings.
PRE-CONDITION: The registered user must be an admin.
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: The admin must log on to the
system.
Step 2: The system displays the admin home page.
Step 3: The admin must click on the
invigilator details.
Step 4: The invigilator details page will be
displayed.
ALTERNATE FLOW :
AF 1: The admin may not click on invigilator details.
POST-CONDITOIN : Only the admin can view the invigilator details.
NON FUNCTIONAL REQ. The logged in user must be an admin.

6. Exam settings:

USE CASE NAME: Exam settings USE CASE ID: 6

PARTICIPATING The admin, EOC, database.
ACTORS:
DESCRIPTION: The admin will make exam settings.
PRE-CONDITION: The registered user must be an admin
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: The must log onto the system.
Step 2: The system displays the admin home page.
Step 3: The admin must click on the
exam settings.
Step 4: The system displays exam settings page.
Step 5: The admin must perform the
necessary actions for setting an
exam

ALTERNATE FLOW :
AF 1: The admin may not click on exam settings.
POST-CONDITION: Only the admin can view the exam settings.
NON FUNCTIONAL REQ. The logged in user must be an admin.
 12

7. Take exam:

USE CASE NAME: Take exam USE CASE ID: 7

PARTICIPATING Student, EOC, the database.
ACTORS:
DESCRIPTION: The student must log onto the system an take exam.
PRE-CONDITION: The logged in user must be a student.
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: Student need to click on others
login and submit his details.
Step 2: The system displays the student home
page.
Step 3: Student must click on take exam.
Step 4: The system displays the exam paper
depending upon subject code and student
code.

ALTERNATE FLOW :
AF 1: The student might click on view instructions.
AF 2: The student might click on view marks.
POST-CONDITION: Only the student can take an exam.
NON FUNCTIONAL REQ. The logged in user must be a student.

8. Evaluate and allocate marks:

USE CASE NAME: Evaluate and allocate marks. USE CASE ID: 8
PARTICIPATING Staff, EOC, the database.
ACTORS:
DESCRIPTION: The staff will evaluate the answer sheets and allocate marks.
PRE-CONDITION: The logged in user must be a staff member.
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: The user must click on Others
login and enter his details and log
onto the system.
Step 2: The system displays the staff home page.
Step 3: The staff must click on evaluate
Step 4: The system displays the answer sheet.
ALTERNATE FLOW :
AF 1: The user might click on view results.
POST-CONDITION: Only the staff can evaluate and allocate marks.
NON FUNCTIONAL REQ. The logged in user must be a staff.
 13

9. View marks:

USE CASE NAME: View marks USE CASE ID: 9

PARTICIPATING Staff, EOC, the database
ACTORS:
DESCRIPTION: The staff will view marks of a student.
PRE-CONDITION: The logged user must be a staff.
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: The user must enter his details
and click on submit
Step 2: The system displays the staff home page.
Step 3: The user must click on view
marks and enter user id.
Step 4: The system displays the marks.
ALTERNATE FLOW :
AF 1: The user might click on evaluate and allocate marks.
POST-CONDITION: Only the staff can view marks.
NON FUNCTIONAL REQ. The logged in user must be a staff

10. Invigilate and report feedback:

USE CASE NAME: Invigilate and report feedback USE CASE ID: 10
PARTICIPATING Invigilator, EOC, the database.
ACTORS:
DESCRIPTION: Invigilator must log in and report feedback.
PRE-CONDITION: The logged in user must be an invigilator.
TYPICAL COURSE
Actor Action System Response
OF EVENTS(Main Flow):
Step 1: The user must enter the invigilator
details.
Step 2: The system displays the invigilator home
page.
Step 3: The invigilator must click on
report feedback.
Step 4: The system displays the feedback page.
Step 5: User might click on report
absentees, debarred and any
technical problems.
ALTERNATE FLOW :
AF 1: The logged in user might not be an invigilator.
POST-CONDITION: Only invigilator can report feedback.
NON FUNCTIONAL REQ. The logged in user might not be an invigilator.
 14

3.1.1.3 USE CASE DIAGRAM:

 15

3.1.2 ACTIVITY DIAGRAM :

Administrator Invigilator Student Staff

login
administrator

check type

staff
invigilator student

invigilate the write exam

exam

submit answer
paper

set staff assign set student set question

details invigilators details paper report get feedback
feedback

evaluate answer
paper

view result submit

results
 16

3.1.3. ANALYSIS MODEL:

3.1.3.1 Collaboration diagrams:

Login:

Student details:
 17

Staff details:

Exam settings:
 18

Invigilator details:

Take exam:
 19

Submit exam:

Cancel exam:
 20

View results:

Evaluate paper:
 21

Change marks:

View marks:
 22

Invigilate:

Report feedback:
 23

3.1.3.2. Sequence diagrams:

Login:
 24

Student details:

Staff details:
 25

Invigilator details:

Exam settings:
 26

Take exam:

Submit exam:
 27

Cancel exam:

View results:
 28

Evaluate paper:

Change marks:
 29

View marks:

Invigilate:
 30

Report feedback:
 31

Chapter 4 DESIGN MODEL

4.1 Architectural design:

4.1.1 Three-Tier Architecture:

The three-tier software architecture (a.k.a. three layer architectures) emerged in the
1990s to overcome the limitations of the two-tier architecture. The third tier (middle tier
server) is between the user interface (client) and the data management (server) components.
This middle tier provides process management where business logic and rules are executed
and can accommodate hundreds of users (as compared to only 100 users with the two tier
architecture) by providing functions such as queuing, application execution, and database
staging.

Fig 4.1 Three Tier Architecture

The three tier architecture is used when an effective distributed client/server design is
needed that provides (when compared to the two tier) increased performance, flexibility,
maintainability, reusability, and scalability, while hiding the complexity of distributed
processing from the user. These characteristics have made three layer architectures a popular
choice for Internet applications and net-centric information systems.
 32

Technical Details:

A three tier distributed client/server architecture includes a user system interface top
tier where user services (such as session, text input, dialog, and display management) reside .

Fig 3.2.2 Three tier distributed client/server architecture depiction

Advantages of Three-Tier:

 Separates functionality from presentation.

 Clear separation - better understanding.

 Changes limited to well define components.

 Can be running on WWW.

 Effective network performance.

4.1.2 Functional Architecture:-

FUNCTIONAL VIEW OF REGISTRATION:

A request for Registration is sent to the server from the client.
These client details from registration server are stored in database.
The server retrieves the Employee details and sends it back to the client after
registration is done successfully.
 33

Request for register

Stores
as a student
Student details
Generates user-id,
Generates user-id,
Registration password, course,
password, course, branch year & sem
branch year & sem

CLIENT SERVER RDBMS

Fig 3.2.3 Functional Architecture

HTTP
JDBC
Request
HTTP JDBC
Response

SERVER
CLIENT RDBMS

Fig 3.2.4 TECHNICAL DIAGRAM

 34

4.2 Data design:

4.2.1 Data Dictionary:

Features of data dictionary:

The volume of data in most information system applications is substantially more
than a single user can easily keep track of data dictionaries are an integral component of
structural analysis since dataflow diagrams by themselves do not fully describe the subject of
the investigation. The data dictionary provides additional information about the system.

What is data dictionary?

A data dictionary is a repository of the elements in the system. As the name suggest,
these elements center on data and the way they are structured to meet user requirements and
organization needs. In a data dictionary we will find a list of all elements composing the data
flowing through a system. The major elements are data flows, data stores and process. The
data dictionary stores details and descriptions of these elements.

Why is data dictionary important?

Analysis use data dictionaries for five important reasons
1. To manage the details in large systems
2. To communicate a common meaning for all elements
3. To document the features of the system
4. To facilitate analysis of details in order to evaluate characteristics and determine
where the changes are made.
5. To locate errors and omissions in the system.
 35

4.2.2 Tables

STUDENT TABLE

Attribute Data type Size Mandatory Key

Name Varchar2 15 Not null

User-id Varchar2 15 Not null Primary key

Password Varchar2 15 Not null

Course Varchar2 5 Not null References

courses(course)
Branch Varchar2 15 Not null

Year Number 1 Not null

Semester Number 1 Not null

TABLE 4.2.2.1

STAFF TABLE

Attribute Data type Size Mandatory Key

Name Varchar2 15 Not null

Use-rid Varchar2 15 Not null Primary key

Password Varchar2 15 Not null

Sub-code Varchar2 5 Not null Unique,

References
subcds(sbcode)
TABLE 4.2.2.2
 36

COURSES TABLE

Attribute Data type Size Mandatory Key

Courses Varchar2 15 Not null Primary key

TABLE.4.2.2.3

BRANCHES TABLE

Attribute Data type Size Mandatory Key

Branch Varchar2 15 Not null Primary key

TABLE 4.2.2.4

SUBCODES TABLE

Attribute Data type Size Mandatory Key

Subcode Varchar2 10 Not null Primary key

Course Varchar2 5 Not null References

courses(course)
Branch Varchar2 15 Not null

Year Number 1 Not null

Semester Number 1 Not null

TABLE 4.2.2.5
 37

INVIGILATOR TABLE

Attribute Data type Size Mandatory Key

Invi-id Varchar2 15 Not null Primary key

references
staff(userid)
Password Varchar2 15 Not null

Userid Varchar2 15 Not null References

staff(userid)

TABLE 4.2.2.6

ADMIN TABLE

Attribute Data type Size Mandatory Key

Userid Varchar2 15 Not null Primary key

Password Varchar2 15 Not null

TABLE 4.2.2.7
 38

SECTION1 TABLE

Attribute Data type Size Mandatory Key

Subcode Varchar2 5 Not null Primary key

references
sbcode(sbcode)
Q1 Varchar2 150 Not null
Q2 Varchar2 150 Not null
Q3 Varchar2 150 Not null
Q4 Varchar2 150 Not null
Q5 Varchar2 150 Not null
Q6 Varchar2 150 Not null
Q7 Varchar2 150 Not null
Q8 Varchar2 150 Not null
Q9 Varchar2 150 Not null
Q10 Varchar2 150 Not null
Q11 Varchar2 150 Not null
Q12 Varchar2 150 Not null
Q13 Varchar2 150 Not null
Q14 Varchar2 150 Not null
TABLE 4.2.2.8

SECTION2 TABLE

Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
Q21 Varchar2 150 Not null

Q22 Varchar2 150 Not null

TABLE 4.2.2.9
 39

SECTION3 TABLE

Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
Q31 Varchar2 150 Not null

Q32 Varchar2 150 Not null

TABLE 4.2.2.10

SECTION4 TABLE

Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
Q41 Varchar2 150 Not null

Q42 Varchar2 150 Not null

TABLE 4.2.2.11

SECTION5 TABLE

Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
Q51 Varchar2 150 Not null

Q52 Varchar2 150 Not null

TABLE 4.2.2.12
 40

SECTION1MARKS TABLE
Attribute Data type Size Mandatory Key
Subcode Varchar2 5 Not null references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
Q1 Number 1 Not null
Q2 Number 1 Not null
Q3 Number 1 Not null
Q4 Number 1 Not null
Q5 Number 1 Not null
Q6 Number 1 Not null
Q7 Number 1 Not null
Q8 Number 1 Not null
Q9 Number 1 Not null
Q10 Number 1 Not null
Q11 Number 1 Not null
Q12 Number 1 Not null
Q13 Number 1 Not null
Q14 Number 1 Not null
Primary key is the combination of both subcode & user-id
TABLE 4.2.2.13

SECTION2MARKS TABLE
Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
Q21 Number 2 Not null

Q22 Number 2 Not null

Primary key is the combination of both subcode & user-id

TABLE 4.2.2.14
 41

SECTION3MARKS TABLE
Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
Q31 Number 2 Not null

Q32 Number 2 Not null

Primary key is the combination of both subcode & user-id

TABLE 4.2.2.15

SECTION4MARKS TABLE

Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
Q41 Number 2 Not null

Q42 Number 2 Not null

Primary key is the combination of both subcode & user-id

TABLE 4.2.2.16
 42

SECTION5MARKS TABLE

Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
Q51 Number 2 Not null

Q52 Number 2 Not null

Primary key is the combination of both subcode & user-id

TABLE 4.2.2.17

TOTALMARKS TABLE
Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
TOTALMARK Number 2 Not null

Primary key is the combination of both subcode & user-id

TABLE 4.2.2.18

ABSENTIES TABLE
Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
Primary key is the combination of both subcode & user-id
TABLE 4.2.2.19
 43

DEBARRED TABLE

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)

TABLE 4.2.2.20

TECHPROB TABLE
Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
Primary key is the combination of both subcode & user-id
TABLE 4.2.2.21

PDFFILES TABLE
Attribute Data type Size Mandatory Key

Subcode Varchar2 15 Not null Primary key

references
sbcode(sbcode)
User-id Varchar2 15 Not null References
student(userid)
Files Long raw Not null

Primary key is a combination of userid & password

Table 4.2.2.22
 44

4.3 Component diagram:

 45

4.4 Deployment diagram:

 46

Chapter 5 TESTING

TESTING:

Testing is the process of detecting errors. Testing performs a very critical

role for quality assurance and for ensuring the reliability of software. The results of testing are

used later on during maintenance also.

5.1 PSYCHOLOGY OF TESTING

The aim of testing is often to demonstrate that a program works by showing that it has
no errors. The basic purpose of testing phase is to detect the errors that may be present in the
program. Hence one should not start testing with the intent of showing that a program works,
but the intent should be to show that a program doesn’t work. Testing is the process of
executing a program with the intent of finding errors.

5.2 TESTING OBJECTIVES

The main objective of testing is to uncover a host of errors, systematically and
with minimum effort and time. Stating formally, we can say,

1. Testing is a process of executing a program with the intent of finding an error.

2. A successful test is one that uncovers an as yet undiscovered error.
3. A good test case is one that has a high probability of finding error, if it exists.
4. The tests are inadequate to detect possibly present errors.
5. The software more or less confirms to the quality and reliable standards.

5.3 LEVELS OF TESTING

In order to uncover the errors present in different phases we have the concept of
levels of testing. The basic levels of testing are as shown below…
 Acceptance 47
Testing
Client Needs

System Testing
Requirements

Integration Testing
Design

Unit Testing
Code

5.4 TYPES OF TESTING

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

5.4.1 Unit Testing

Unit testing focuses verification effort on the smallest unit of software i.e. the
module. Using the detailed design and the process specifications testing is done to uncover
errors within the boundary of the module. All modules must be successful in the unit test
before the start of the integration testing begins.

In this project each service can be thought of a module. There are so many modules
like Login, Admin module which further involves student details, staff details, invigilator
details, exam settings etc, student module which contains exam and results sub modules, staff
module and invigilator module. As a part of unit testing we tested every program or function
separately after coding of that particular program. We tested whether the program is meeting
the requirements placed by the requirements phase. If not we modified programs according to
our requirements.

In this application developer tests the programs up as system. Software units in a

system are the modules and routines that are assembled and integrated to form a specific
function. Unit testing is first done on modules, independent of one another to locate errors.
This enables to detect errors. Through this, errors resulting from interaction between modules
initially avoided. We followed basic flow testing where we Showed screens for every path of
flow for login page thereby proving cyclometer complexity of the program.
 48

Login paper

Login with out entering user-id

 49

Login without password

Login without type

 50

Login without year

Login without sub code

 51

Login with invalid userid & password

Login page after all entries are submitted correctly

 52

Results of Testing for our Application

1. Others login (successful)

Test Case: Others Login (successful)

Test Description: provide student/staff/invigilator rights by checking type
Pre Conditions: Database Connectivity
Action Performed: Enter valid login details without leaving any field

Expected Results: Success login

Conditions Verified: yes
Result: Success

2. Others login (unsuccessful)

Test Case: Others Login (unsuccessful)

Test Description: Report error message

Pre Conditions: Database Connectivity

Action Performed: Enter invalid login details\leave any field without blank

Expected Results: Display error message\alert box regarding the error

Conditions Verified: yes

Result: Success

3. Set question paper (successful)

Test Case: Set question paper (successful)

Test Description: Provide access for load successfully
Pre Conditions: Database Connectivity
Action Performed: select fields course, branch, year, sem and subject, enter all
questions
Expected Results: Give acknowledgement to admin after loading questions
Conditions Verified: yes
Result: Success
 53

4. Set question paper (unsuccessful)

Test Case: Set question paper (unsuccessful)

Test Description: Restrict access access to load successfully\display error message

Pre Conditions: Database Connectivity

Action Performed: leaving details \ leave any field blank\ already existing

Expected Results: Give proper error message describing the error

Conditions Verified: yes

Result: Success

5. Take Exam (successful)

Test Case: Take Exam (successful)

Test Description: Allow the student to take test
Pre Conditions: Database Connectivity, login as student, set question paper
Action Performed: Submit valid Student details like user-id, password, subcode etc.
Expected Results: Allow student to take exam
Conditions Verified: yes
Result: Success

6. Take Exam (unsuccessful)

Test Case: Take Exam (unsuccessful)

Test Description: Restrict the student to take test
Pre Conditions: Database Connectivity, login as student, set question paper
Action Performed: Submit Invalid details like user-id, password, subcode etc.

Expected Results: Give warning message like invalid user/ question paper not set
Conditions Verified: yes
Result: Success
 54

7. Submit exam (successful)

Test Case: Submit exam (successful)

Test Description: Disable the user to submit question paper with error message \ alert box
Pre Conditions: Student login, Database Connectivity, take exam
Action Performed: Submit the answer paper with in given time 3 hours

Expected Results: Give “successfully uploaded your answer sheet” message

Conditions Verified: yes
Result: Success

8. Submit exam (unsuccessful)

Test Case: Submit exam (unsuccessful)

Test Description: Disable the user to submit question paper with error message \ alert box
Pre Conditions: Database connectivity, student login, access take exam link
Action Performed: Submitting the answer sheet after time out

Expected Results: Report error message

Conditions Verified: yes
Result: Success

5.4.2 Integration Testing:

After the unit testing we have to perform integration testing. The goal here is to see if modules can
be integrated properly, the emphasis being on testing interfaces between modules. This testing activity can
be considered as testing the design and hence the emphasis on testing module interactions.

In this project integrating all the modules forms the main system. When integrating all the modules
I have checked whether the integration effects working of any of the services by giving different
combinations of inputs with which the two services run perfectly before Integration.

 After the completion of unit testing, we tested the functionality of entire system by integrating all
the modules.
 For example, in order a student to write an exam for a subject first he must be added as a student to
that course by admin, and also question paper must also be loaded into the database for that subject.
So here student module is depending on admin module. So we checked whether all students added
by the admin are able to access the system to write the exams of their respective courses or not.
 55

 In this way integration testing is followed also to test the interaction among all modules so
that the functionality of one module may not affect the functionality of another module in adverse
way.

5.4.3 System Testing:

Here the entire software system is tested. The reference document for this process is the
requirements document, and the goal as to see if software meets its requirements.

In the system testing we tested the entire system basing on System requirements specification
document i.e., whether the functionality we proposed in document is achieved or not. Here we achieved
everything whatever we specified write from the login, taking exam, pdf conversion, evaluation to viewing
results by the student.

5.4.4 Acceptance Testing:

Acceptance Test is performed with realistic data of the client to demonstrate that the software is
working satisfactorily. Testing here is focused on external behavior of the system; the internal logic of
program is not emphasized.

Test cases should be selected so that the largest number of attributes of an equivalence class is
exercised at once. The testing phase is an important part of software development. It is the process of
finding errors and missing operations and also a complete verification to determine whether the objectives
are met and the user requirements are satisfied. Our system underwent acceptance test from people who are
not involved in the project.

5.5 Criteria Satisfied by Test Cases:

1) Test cases that reduced by a count that is greater than one, the number of additional test
cases that much be designed to achieve reasonable testing.

2) Test cases that tell us something about the presence or absence of classes of errors, rather
than an error associated only with the specific test at hand.

In order to test the overall system only one method of testing is not enough, so we have done wide range of
tests to validate the functionality of the system.
 56

Chapter 6 GUI SCREENS

Home page
 57

Admin Login

Admin Invalid Login Page

 58

Admin First Page

Student details page

 59

Add Student Page

Add Student output

 60

Delete Student page

Delete Student output

 61

View all students page

View all students output

 62

Staff Details
 63

Add Staff page

Add Staff output

 64

View all Staffs Page

View all Staffs output

 65

View Staff

View staff output

 66

Exam Setting Page

 67

Add new subject

Add new subject output

 68

Delete Question Paper

Delete question paper failure page

 69

Load Question Paper

Load question paper Submit

 70

Load question paper acknowledgement

View Question paper

 71

View Question paper output

Students Login
 72

Students First Page

Question paper & answer space

 73

Submit Answer sheet

Submit test with alert

 74

Submit test Acknowledgement page

PDF Generation in server

 75

Answer Sheet in PDF format along with questions

Staff Login
 76

Staff first page

Allotment & submitting of marks

 77

Staffs view of students’ marks

View of Marks allotted

 78

View results by students after login

 79

Chapter 7 CONCLUSION & FUTURE WORK

Proposed Electronic Descriptive Examination Management System achieved better transparency,

security and maintainability. It also saves lot of manpower, time and logistics to conduct the examination,
evaluate the answer scripts and announcing the results.

In the proposed system we are unable to include rich text editor, which supports drawings. So this
can be carried out in future. We can extend the system to different levels of stakeholders with different
privileges.
 80

Chapter 8 BIBILOGRAPHY

1. Ali Bahraini (2003),”Object Oriented Analysis and Design using UML”, 2nd Edition Tata McGraw-
Hill.
2. Herbert Schildt (2002),”Java 2 Programmers Reference”, 1st edition, McGraw -Hill companies.
3. Jason Hunter William Crawford and Paula Ferguson (1999) ,”Java Servlet Programming”, 2nd
Edition.
4. Roger S.Pressman (2002),”Software Engineering: A Practioners Approach”, 5th Edition, Tata
McGraw-Hill.

WEBSITES

1. WWW.java.sun.com
2. WWW.w3schools.com
81