electronic descriptive examination management system final1
TRANSCRIPT
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
)
.
U
s
e
c
a
s
e
d
i
a
g
r
a
m
U
s
e
c
a
s
e
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
2. Others login:
USE CASE NAME: Others login. USE CASE ID: 2 PARTICIPATING ACTORS:
Student, Staff, Invigilator, EOC, login(db)
DESCRIPTION: The system authorizes the registered user according to the roles. PRE-CONDITION: The user must be a registered user. TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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.
-----------------------------------------------------------------------
USE CASE NAME: Admin login USE CASE ID: 1
PARTICIPATING ACTORS:
The Administrator, EOC, login (db).
DESCRIPTION: The admin logs into the system and maintains the database.
PRE-CONDITION: The user must be an administrator
TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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.
--------------------------------------------------------------------
10
3. Student details:
USE CASE NAME: Student details. USE CASE ID: 3 PARTICIPATING ACTORS:
The admin, EOC, database.
DESCRIPTION: The admin will make student settings. PRE-CONDITION: Only the admin can do the student settings. TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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 ACTORS:
The admin, EOC, database.
DESCRIPTION: The admin will make staff settings. PRE-CONDITION: The registered user must be an admin. TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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 ACTORS:
The admin, EOC, the database.
DESCRIPTION: The admin will make invigilator settings. PRE-CONDITION: The registered user must be an admin. TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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 ACTORS:
The admin, EOC, database.
DESCRIPTION: The admin will make exam settings. PRE-CONDITION: The registered user must be an admin TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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 ACTORS:
Student, EOC, the database.
DESCRIPTION: The student must log onto the system an take exam. PRE-CONDITION: The logged in user must be a student. TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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 ACTORS:
Staff, EOC, the database.
DESCRIPTION: The staff will evaluate the answer sheets and allocate marks. PRE-CONDITION: The logged in user must be a staff member. TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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 ACTORS:
Staff, EOC, the database
DESCRIPTION: The staff will view marks of a student. PRE-CONDITION: The logged user must be a staff. TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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 ACTORS:
Invigilator, EOC, the database.
DESCRIPTION: Invigilator must log in and report feedback. PRE-CONDITION: The logged in user must be an invigilator. TYPICAL COURSE OF EVENTS(Main Flow):
Actor Action System Response
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:
set staff details
assign invigilators
set question paper
invigilate the exam
login
check type
invigilator
report feedback
write exam
student
submit answer paper
view result
get feedback
staff
evaluate answer paper
submit results
administrator
set student details
StaffStudentInv igilatorAdministrator
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
Fig 3.2.3 Functional Architecture
Fig 3.2.4 TECHNICAL DIAGRAM
Request for register
as a student
Registration Generates user-id,
password, course,
branch year & sem
Generates user-id,
password, course,
branch year & sem
Stores
Student details
SERVER RDBMS CLIENT
HTTP
Request
HTTP
Response JDBC
JDBC
SERVER RDBMS CLIENT
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
TABLE 4.2.2.21
Table 4.2.2.22
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
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
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…
47
Client Needs
Requirements
Design
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.
Acceptance
Testing
System Testing
Integration Testing
Unit Testing
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)
2. Others login (unsuccessful)
3. Set question paper (successful)
Result: Success
Conditions Verified: yes
Expected Results: Success login
Action Performed: Enter valid login details without leaving any field
Pre Conditions: Database Connectivity
Test Description: provide student/staff/invigilator rights by checking type
Test Case: Others Login (successful)
Result: Success
Conditions Verified: yes
Expected Results: Display error message\alert box regarding the error
Action Performed: Enter invalid login details\leave any field without blank
Pre Conditions: Database Connectivity
Test Description: Report error message
Test Case: Others Login (unsuccessful)
Result: Success
Conditions Verified: yes
Expected Results: Give acknowledgement to admin after loading questions
Action Performed: select fields course, branch, year, sem and subject, enter all
questions
Pre Conditions: Database Connectivity
Test Description: Provide access for load successfully
Test Case: Set question paper (successful)
53
4. Set question paper (unsuccessful)
5. Take Exam (successful)
6. Take Exam (unsuccessful)
Result: Success
Conditions Verified: yes
Expected Results: Give proper error message describing the error
Action Performed: leaving details \ leave any field blank\ already existing
Pre Conditions: Database Connectivity
Test Description: Restrict access access to load successfully\display error message
Test Case: Set question paper (unsuccessful)
Result: Success
Conditions Verified: yes
Expected Results: Allow student to take exam
Action Performed: Submit valid Student details like user-id, password, subcode etc.
Pre Conditions: Database Connectivity, login as student, set question paper
Test Description: Allow the student to take test
Test Case: Take Exam (successful)
Result: Success
Conditions Verified: yes
Expected Results: Give warning message like invalid user/ question paper not set
Action Performed: Submit Invalid details like user-id, password, subcode etc.
Pre Conditions: Database Connectivity, login as student, set question paper
Test Description: Restrict the student to take test
Test Case: Take Exam (unsuccessful)
54
7. Submit exam (successful)
8. Submit exam (unsuccessful)
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.
Result: Success
Conditions Verified: yes
Expected Results: Give “successfully uploaded your answer sheet” message
Action Performed: Submit the answer paper with in given time 3 hours
Pre Conditions: Student login, Database Connectivity, take exam
Test Description: Disable the user to submit question paper with error message \ alert box
Test Case: Submit exam (successful)
Result: Success
Conditions Verified: yes
Expected Results: Report error message
Action Performed: Submitting the answer sheet after time out
Pre Conditions: Database connectivity, student login, access take exam link
Test Description: Disable the user to submit question paper with error message \ alert box
Test Case: Submit exam (unsuccessful)
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