Electronic Descriptive Examination Management System final1

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

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

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.

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.

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

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

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

3.1.1.2 USE CASE DESCRIPTION TABLES:

1. Admin login:

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):

Step 1: The admin clicks on admin

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.

--------------------------------------------------------------------

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):

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:

DESCRIPTION: The admin will make staff settings. PRE-CONDITION: The registered user must be an admin. TYPICAL COURSE 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.

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):

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:

DESCRIPTION: The admin will make exam settings. PRE-CONDITION: The registered user must be an admin TYPICAL COURSE 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.

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):

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):

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.

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):

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):

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.

3.1.1.3 USE CASE DIAGRAM:

3.1.2 ACTIVITY DIAGRAM:

set staff details

assign invigilators

set question paper

invigilate the exam

check type

invigilator

report feedback

write exam

student

submit answer paper

view result

get feedback

evaluate answer paper

submit results

administrator

set student details

StaffStudentInv igilatorAdministrator

3.1.3. ANALYSIS MODEL:

3.1.3.1 Collaboration diagrams:

Login:

Student details:

Staff details:

Exam settings:

Invigilator details:

Take exam:

Submit exam:

Cancel exam:

View results:

Evaluate paper:

Change marks:

View marks:

Invigilate:

Report feedback:

3.1.3.2. Sequence diagrams:

Login:

Student details:

Staff details:

Invigilator details:

Exam settings:

Take exam:

Submit exam:

Cancel exam:

View results:

Evaluate paper:

Change marks:

View marks:

Invigilate:

Report feedback:

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.

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.

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

Request

Response JDBC

SERVER RDBMS CLIENT

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.

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

Name Varchar2 15 Not null

Use-rid Varchar2 15 Not null Primary key

Sub-code Varchar2 5 Not null Unique,

References

subcds(sbcode)

TABLE 4.2.2.2

COURSES TABLE

Courses Varchar2 15 Not null Primary key

TABLE.4.2.2.3

BRANCHES TABLE

Branch Varchar2 15 Not null Primary key

TABLE 4.2.2.4

SUBCODES TABLE

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

INVIGILATOR TABLE

Invi-id Varchar2 15 Not null Primary key

references

staff(userid)

Userid Varchar2 15 Not null References

staff(userid)

TABLE 4.2.2.6

ADMIN TABLE

Userid Varchar2 15 Not null Primary key

TABLE 4.2.2.7

SECTION1 TABLE

references

sbcode(sbcode)

Q1 Varchar2 150 Not null

TABLE 4.2.2.8

SECTION2 TABLE

references

sbcode(sbcode)

TABLE 4.2.2.9

SECTION3 TABLE

Subcode

Varchar2 15 Not null Primary key

references

sbcode(sbcode)

TABLE 4.2.2.10

SECTION4 TABLE

references

sbcode(sbcode)

TABLE 4.2.2.11

SECTION5 TABLE

references

sbcode(sbcode)

TABLE 4.2.2.12

SECTION1MARKS TABLE

Subcode Varchar2 5 Not null references

sbcode(sbcode)

User-id Varchar2 15 Not null References

student(userid)

Q1 Number 1 Not null

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

TABLE 4.2.2.13

SECTION2MARKS TABLE

references

sbcode(sbcode)

student(userid)

TABLE 4.2.2.14

SECTION3MARKS TABLE

references

sbcode(sbcode)

student(userid)

TABLE 4.2.2.15

SECTION4MARKS TABLE

references

sbcode(sbcode)

student(userid)

TABLE 4.2.2.16

SECTION5MARKS TABLE

references

sbcode(sbcode)

student(userid)

TABLE 4.2.2.17

TOTALMARKS TABLE

references

sbcode(sbcode)

student(userid)

TOTALMARK Number 2 Not null

TABLE 4.2.2.18

ABSENTIES TABLE

references

sbcode(sbcode)

student(userid)

TABLE 4.2.2.19

DEBARRED TABLE

references

sbcode(sbcode)

student(userid)

TABLE 4.2.2.20

TABLE 4.2.2.21

Table 4.2.2.22

TECHPROB TABLE

references

sbcode(sbcode)

student(userid)

PDFFILES TABLE

references

sbcode(sbcode)

student(userid)

Files Long raw Not null

Primary key is a combination of userid & password

4.3 Component diagram:

4.4 Deployment diagram:

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…

Client Needs

Requirements

Design

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

Login paper

Login with out entering user-id

Login without password

Login without type

Login without year

Login without sub code

Login with invalid userid & password

Login page after all entries are submitted correctly

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

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

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

Test Description: Report error message

Test Case: Others Login (unsuccessful)

Result: Success

Expected Results: Give acknowledgement to admin after loading questions

Action Performed: select fields course, branch, year, sem and subject, enter all

questions

Test Description: Provide access for load successfully

Test Case: Set question paper (successful)

4. Set question paper (unsuccessful)

5. Take Exam (successful)

6. Take Exam (unsuccessful)

Result: Success

Expected Results: Give proper error message describing the error

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

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

Test Case: Set question paper (unsuccessful)

Result: Success

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

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)

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

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

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)

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

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.

Chapter 6 GUI SCREENS

Home page

Admin Login

Admin Invalid Login Page

Admin First Page

Student details page

Add Student Page

Add Student output

Delete Student page

Delete Student output

View all students page

View all students output

Staff Details

Add Staff page

Add Staff output

View all Staffs Page

View all Staffs output

View Staff

View staff output

Exam Setting Page

Add new subject

Add new subject output

Delete Question Paper

Delete question paper failure page

Load Question Paper

Load question paper Submit

Load question paper acknowledgement

View Question paper

View Question paper output

Students Login

Students First Page

Question paper & answer space

Submit Answer sheet

Submit test with alert

Submit test Acknowledgement page

PDF Generation in server

Answer Sheet in PDF format along with questions

Staff Login

Staff first page

Allotment & submitting of marks

Staffs view of students’ marks

View of Marks allotted

View results by students after login

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.

Chapter 8 BIBILOGRAPHY

1. Ali Bahraini (2003),”Object Oriented Analysis and Design using UML”, 2nd

Edition Tata McGraw-

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

Electronic Descriptive Examination Management System final1

Documents

ARCHE FINAL1

IDRF final1

EarlyCivilizationsMatrix Final1

wap final1

WBS FINAL1

Proyecto final1

Nss final1

CDS -Final1

Media Final1

Vzavalacrespo final1

Descriptive Word Mark - Examination Procedure - Industrial.....

KFA final1

Final1 tomasi

ABB Final1

Uml Final1

Transversales final1