A

PROJECT

ON

ONLINE EXAMINATION SYSTEM

(TEST4U)

By:

Prabhnoor Sidhu(02/IT/0041323107)
Jugpreet Singh(03/IT/0051323107)
Harkirat Singh(42/IT/0471323107)

Department of Computer Science & Engineering

Guru Tegh Bahadur Institute of Technology

Guru Gobind Singh Indraprastha University

Kashmere Gate,New Delhi
Year 2009-2010
 ACKNOWLEDGEMENT

We would like to express our great gratitude towards our supervisor and trainer,
Mr. Rakesh Malik , who has given us the required knowledge, support and suggestions for the
project. Without his help, we could not have presented this dissertation upto the present standard.
We also take this opportunity to give thanks to all others who gave us support for the project or
in other aspects of our study at the institute, Microsoft IT Academy.

Date: 22nd September 2010

Prabhnoor Sidhu
(02/GTBIT/2007)
[email protected]

Jugpreet Singh
(03/GTBIT/2007)
[email protected]

Harkirat Singh
(42/GTBIT/2007)
[email protected]
 ABSTRACT
ONLINE EXAMINATION SYSTEM as the name suggests is an online Product that allows
students to appear for certification examination. This project also enables an Examination
conductor to register for an exam and conduct the same for the registered students.
The project’s objective is to provide a platform for students to test their knowledge in a particular
subject and be a certified professional.

This project has got three major modules:

Administrator Module: It maintains the complete information of the website, information

about various test conductors and registered students. It also enables the administrator to manage
the student result centerwise. It maintains records of various test conductors and tests conducted.

Test Conductor(Agent) Module: It allows the Agent to register for a exam on the required
date for a fixed number of students and a subject. The Agent provides students with username
and password. The Agent conduts the exam it at his location on a specified date, and manages
the result of all students for the different tests.

Student Module: This module manages the registered students. The Student can appear for the
test only once and any subsequent request by the student allows him to see the result only. The
Student can register for a new test anytime with the Test Conductor.
 LIST OF FIGURES AND TABLES

Fig No Figure Name Page

Fig 2.1 Stages Of Waterfall Model 4

Fig 3.1 Logical Database Design 11
Fig 3.2 ER Diagram 12
Fig 3.3 Level 0 DFD 17
Fig 3.4 Level 1 DFD 18
Fig 3.5 Menu Flow Diagram 21
Fig 3.6 Use Case Diagram 28
Fig 6.1 Home Page 44
Fig 6.2 Add Subject Page 45
Fig 6.3 Edit Subject Page 46
Fig 6.4 Add Question Page 47
Fig 6.5 Complete Result Page 48
Fig 6.6 Register for Test Page-1 49
Fig 6.7 Register for Test Page-2 50
Fig 6.8 Enter Student Details 51
Fig 6.9 Centre Result Page 52
Fig 6.10 Add Details Page(Student) 53
Fig 6.11 Change Password Page 54
Fig 6.12 Rules Page 55
Fig 6.13 Appear For test Page 56
Fig 6.14 User Result Page 57
 LIST OF TABLES

Table No. Description Page No.

3.1 Admin_Login 13
3.2 Agent_Info 13
3.3 Agent_Login 13
3.4 Options 14
3.5 Question 14
3.6 Student_Info 14
3.7 Student_Response 15
3.8 Student_Result 15
3.9 Subject_Info 15
 CONTENTS

Chapter Page No.

Title Page
Certificate ii
Acknowledgement v
Abstract vi
List of Tables and Figures vii
Contents ix

1. Introduction 1

1.1 Problem Statement 1

1.2 Proposed Solution 1
1.3 Deliverables 3

2. Requirement Analysis (SRS) 4

2.1 Methodology And Tools Used 4

2.2 ASP.NET 2005 6

3. System Design (Client Server Architecture, ERD, DFD) 11

3.1 Logical Database Design 11

3.2 Entity Relationship Diagram 11
3.3 Table Structures 13
3.4 Data Flow Diagram 16
3.5 Input Design 18
3.6 Output Design 20
3.7 Menu Flow Diagram 21
3.8 Use Case Description 22
4. Body of Thesis 29

4.1 System Interfaces 29

4.2 System Specifications 30
4.3 Constraints 31
4.4 Assumptions & Dependencies 31
4.5 User Characteristics 32

5. Testing 33

5.1 Testing Methodology 33

5.2 Unit Testing 33
5.3 Integration Testing 35
5.4 System Testing 35
5.5 User Acceptance Testing 40
5.6 Implementation 41

6. Results and Observations 42

6.1 Conclusion 42
6.2 Limitations of the System 42
6.3 Future Scope for Modification 42
6.4 References & Bibliography 42

7. Appendix 44
 Chapter One

INTRODUCTION
1.1 Problem Statement:

 Only knowledge about a particular subject may not be enough, an individual needs to be
certified in the particular field.

 With cut-throat competetion in the professional field, an individual needs to have a

proper cerification.

 So there is a need for a website where an individual can appear for certification exams.

 The individual must be able to register for an exam of his choice.

 The website should be user-friendly.

 The website should also allow the individual to update his personal information and
review his result.

 The test should be conducted at an examiner’s location.

1.2 Proposed Solution:

 TEST4U is our initiative towards providing students with a platform to appear for a
certification exam.

 The Website provides a wide variety of questions on a number of subjects.

 An Agent can register for a particular exam to be conducted for a number of students on a
particular date.

 The student can appear for the certification exam at the registered Agent’s location.

 The student can review his result and register for a new exam anytime with the Agent.

The website has different features which helps it to achieve its objectives, these are:

ADD/EDIT SUBJECTS(Administrator): The Administrator can add/update/delete different

subjetcs to provide cerification on.

ADD/EDIT QUESTIONS(Administrator): The Administrator can add/update/delete questions

for different subjects.
EDIT AGENT DETAILS(Administrator): The details of the registered Agent can be edited by
the Administrator.

REGISTER FOR TEST(Agent): The Agent registers for a particular test, on a specified date for
a given number of students. The Agent makes the payment using demand draft or credit card.

ADD/EDIT STUDENT DETAILS(Agent): The details of the registered Student can be added/
edited by the agent.

ADD DETAILS(Student): Registered students can add/update their details.

APPEAR FOR TEST(Student): The registered student appears for a given test on a specified
date for a particular subject.

RESULTS: The registered Student can view only his result, Agent can view the complete result
of the its centre and the Administrator can view the complete result of all appeared students
centre-wise.

JUSTIFICATION AND NEED FOR THE SYSTEM

 The Web-site was build so that the student can appear for the certification for a particular
subject on a specified date.

 To provide better service to their users.

 To provide a user-friendly interface.

 To allow only authorized access to the system.

 To allow an individual to review his performance.

ADVANTAGES OF THE PROPOSED SYSTEM

 Reduces paper and manual work.

 It provides security through passwords to restrict unauthorized access to data.

 Reduces overall processing time.

 Performance is high.

 Comparing the results of registered students centre-wise.

 The constraints and checks lead to a valid database.

1.3 Deliverables:

 Table of contents
 Use Case Diagram
 Context diagram
 Data flow diagrams
 Input Screen Designs
 Output Design snapshots
 Test Plan
 Chapter Two

REQUIREMENT ANALYSIS (SRS)

2.1 Methodology and Tools Used
The model that is basically being followed is the WATERFALL MODEL, which states that
the phases are organized in a linear order. First of all the feasibility study is done. Once the part
is over the Requirement Analysis and Project Planning begins. The design starts after the
requirements analysis is complete and the coding begins after the design is complete. Once the
coding is completed, the testing is done. In this model the sequence of activities performed in
software development project are as follows:

1. Requirement Analysis.
2. Project Planning.
3. System Design.
4. Coding.
5. Unit Testing.
6. System Integration and Testing.

Here the linear ordering of these activities is critical. Output of one phase is the input of
another phase. The output of each phase is to be consistent with overall requirement of the
system. Some of the qualities of spiral model are also incorporated like after ‘Interface
designing’ the user was asked to validate the design as per the requirements. Interaction with
the user is also done from time to time for identifying further requirements. WATERFALL
Model was being chosen because all the requirements were known beforehand and the
objective of our software development is the computerization/automation of an already
existing manual working system.

Requirement Analysis & Specification

Design

Implementation & Unit testing

Integration & System Testing

Fig.1.1.Stages of WATERFALL MODEL Operation & Maintenance

2.1.1 Requirement Analysis & Specification Phase
The goal of this phase is to understand the exact requirements of the customer and to
document them properly. The requirements describe the “what” of the system, not the “how”.
This phase produces a large document, written in a natural language, contains a description of
what the system will do without describing how it will be done. The resultant document is
known as Software Requirement Specification (SRS).
The SRS document may act as a contract between the developer & customer.

2.1.2 Design Phase

The goal of this phase is to transform the requirements specification into a structure that is
suitable for implementation in some programming language.
Here, overall software architecture is defined, and the high level and detailed design work is
performed. This work is documented and known as software design description (SDD)
document.

2.1.3 Implementation & Unit testing Phase

During this phase, design is implemented. If SDD is complete, the implementation or coding
phase proceeds smoothly.
During Testing, the major activities are centered on the examination and modification of the
code. Initially small modules are tested in isolation from the rest of the software product.

2.1.4 Integration & System testing Phase

This is a very important phase. Effective testing will contribute to the delivery of higher
quality software products, more satisfied users, lower maintenance costs, a and more accurate
and reliable results. It is a very expensive activity and consumes one third to one-half of the cost
of a typical developments project.
As we know, the purpose of unit testing is to determine that each independent module
is correctly implemented. This gives a little chance to determine that the interface between
modules is also correct, and for this reason integration testing of the entire system is done
whereas software is part of the system. This is essential to build confidence in the developers
before software is delivered to the customer or released in the market.

2.1.5 Operation & Maintenance Phase

Software maintenance is a task that every development group has to face, when the software
is delivered to the customer’s site, installed and is operational. Therefore, release of software
inaugurates the operation and maintenance phase of the life cycle .The time spent and effort
required to keep the software operational after is very significant. Despite the fact that it is very
important and challenging task; it is routinely the poorly managed headache that nobody wants to
face.
Software maintenance is a very broad activity that includes error correction, enhancement of
capabilities and optimization. The purpose of this phase is to preserve the value of the software
overtime. This phase of the software may be 5-50 years whereas development may be 1-3 years.

2.2 ASP.NET 2008

DOT NET Concepts:
.Net initiative has tried to build the gap in interoperability between applications. It aims at
integrating various programming languages and services. It is designed to make significant
improvements in code reuse, code specialization, resource management, multi language
development, security, deployment and administration.
The .Net infrastructure consists of all the technologies that help in creating & running robust
scalable and distributed applications. The core of the .Net infrastructure is the .Net framework
which is a collection of services and classes. It exists as a layer between .Net applications and
underlying operating system.

The .Net Framework consists of a Web Forms, Windows Forms, and Console applications that
pertain to the presentation layer of an application. Web Forms are used in Web-based
applications that pertain to the presentation layer of an application. Web forms are used in Web-
based applications, whereas Windows
Forms are used in Windows-based applications for providing an interactive user interface. In
addition, you can create character-based console applications that can be executed from the
command line.
.NET Framework, a set of objects and blueprints from Microsoft for building applications.
The .NET Framework provides the underlying functionality of ASP.NET. All applications
developed under the .NET Framework; including ASP.NET applications, have certain key
features that ensure compatibility, security, and stability. Let's examine these features
individually.
According to the Microsoft .NET Framework is:
A platform for building, deploying, and running web services and applications. It provides a
highly productive, standards-based, multi-language environment for integrating existing
investments with next-generation applications and services as well as the ability to solve the
challenges of deployment and operation of Internet-scale applications.
The Microsoft .NET Framework consist of two main parts:
1) Common Language Runtime:
1. Common Type System (data types at MSIL)
2. Common Language Specifications (rules to be taken care of for using the language)
Version control (multiple dUs can be maintained through metadata)
3. Automatic garbage Collection
2) Base Class Library:
.NET class library, which is sometimes called "Base Framework";

( I ) COMMON LANGUAGE RUNTIME:

The Common Language Runtime (CLR) is an environment that manages the execution of code.
In other words, it runs and maintains any code that you write.
Traditionally, when you create an application, you write some code in a programming language
(such as Visual Basic), compile it into a format that the computer can understand (1's and O's),
and then execute it. Note that different types of computers speak different languages (for
instance, PCs and Macintoshes). This means that every time you want to use an application on a
different type of computer, you have to recompile it to the new computer's language. In the .NET
Framework, things work a little differently.
With the .NET Framework and CLR, you still write code and compile it. However, instead of
compiling it into something the computer understands, you compile it into a language called the
Microsoft Intermediate Language (MSIL). This language is a shorthand way of representing all
the code you've written. ASP.NET pages are compiled into MSIL as well. When you compile to
MSIL, your application produces something called metadata. This is descriptive information
about your application. It tells what the application can do, where it belongs, and so on.
Along with MSIL and metadata, a new class of programming language compilers has been
created-for C#, COBOL, and so on. These compilers are similar to existing ones, but now can
output MSIL as well as compiled code.
Then, when you want to run your program, the Common Language Runtime takes over and
compiles the code once more into the computer's native language. This way MSIL can go on any
type of computer. The CLR can speak many different computer languages and does all the
compiling for you. Once you compile your application, you can bring it to any other computer!
The CLR uses the metadata to find out how to run the application, which makes it very easy to
install programs. The traditional method required information about the application to be stored
in a registry or a central depository for application information. Unfortunately, the registry would
be invalidated whenever an aspect of your application changed (its directory was moved, a new
component was installed, and so on), and the application wouldn't run properly. With metadata,
there's no need for the registry. All necessary information is stored with the application files, so
any changes you make are put into effect automatically. Imagine installing a new application just
by copying some files!
(II) BASE CLASS LIBRARIES
The .NET Framework contains common class libraries - like ADO. NET, ASP.NET and
Windows Forms - to provide advanced standard services that can be integrated into a variety of
computer systems.
The .NET Framework is language neutral. Currently it supports C++, C#, Visual Basic, JScript
(The Microsoft version of JavaScript) and COBOL. Third-party languages - like Eiffel, Perl,
Python, Smalltalk, and others - will also be available for building future .NET Framework
applications.
The .Net Class Framework consists of a class library that works with any .Net language, such as
Visual Basic.Net and C#. This class library is built on the object-oriented nature of the runtime.
One of the important features of the .Net Framework class library is that it can be used in a
consistent manner across multiple languages. This means that you can use the same set of classes
for performing a specific task in Visual Basic as well as in Visual C++.
The Common Language Runtime is one of the most essential components of the .Net
Framework. The CLR or the runtime provides functionality such as exception handling, security,
debugging and versioning support to any language that targets it This means that the runtime can
host a variety of language and offer a common set of tools across these languages, ensuring
interoperability between the codes.

SQL Server 2008

Microsoft SQL Server 2008 extends the performance, reliability, availability, programmability,
and ease-of-use of SQL Server 2005. SQL Server 2008 includes several new features that make
it an excellent database platform for large-scale online transactional processing (OLTP), data
warehousing, and e-commerce applications.
2.4.6.5 New Features
SQL Server 2008 combines the functionality of the following SQL Server 2005 tools: Server
Network Utility, Client Network Utility, and Services Manager. SQL Server Configuration
Manager also includes the ability to set service properties for the following services:
• SQL Server
• SQL Server Agent
• Analysis Services
• Report Server
• Microsoft Search
• Microsoft Distributed Transaction Coordinator (MS DTC)
• Full-Text Search
NET Framework Common Language Runtime Integration
• The .NET Framework's common language runtime (CLR) is now hosted in the SQL Server
Database Engine. This CLR integrated environment supports procedural database objects,
including functions, stored procedures, and triggers, written in .NET languages, such as
Microsoft Visual C# and Microsoft Visual Basic .NET. .NET languages support logic and
features that are not available in the Transact-SQL language, meaning that more complex logic
can now be incorporated in database objects. User-defined types and aggregates can also be
written in .NET languages to build more complex data types than were available in earlier
versions of SQL Server.
• The CLR programming environment is integrated into the Visual Studio development
environment. Developers use the same tools for developing and debugging database objects as
they use to develop client or middle-tier .NET components and services.
 Chapter Three

SYSTEM DESIGN
3.1 Logical Database Design

Fig 3.1 – Logical Database Design

3.2 Entity Relationship Diagram

An entity-relationship (ER) diagram is a specialized graphic that illustrates the

interrelationships between entities in a database. ER diagrams often use symbols to
represent three different types of information. Boxes are commonly used to represent
entities. Diamonds are normally used to represent relationships and ovals are used to
represent attributes
 TEST
COD NAM
E E
USERNAME PASSWORD SUBJECT

QUESTION OPTION
MANAGE S
S
ADMINISTRATOR QUESTIONS

Q.No.
ANSWE
R
NAME
AGENT ROLES

AGENT
ID

COMPLET CENTRE
E RESULT RESULT
PASSWOR VIEWS
D
RESULTS

INDIVIDUAL TEST
RESULT RESUL
NAM T
E
DOE
NO OF
S
STUDENT
STUDENTS APPEAR S
S
ID

LOGIN PASSWORD
TEST
TEST CODE

DATE
REGISTE TEST
R ID

Fig 3.2 – ER Diagram

3.3 Table Structures

Table 3.3.1
Admin_Login

Table 3.3.2
Agent_Info

Table 3.3.3
Agent_Login
Table 3.3.4
Options

Table 3.3.5
Question

Table 3.3.6
Student_Info
Table 3.3.7
Student_Response

Table 3.3.8
Student_Result

Table 3.3.9
Subject_Info
3.4 Data Flow Diagrams
Data flow diagrams (DFDs) are one of the three essential perspectives of SSADM. The sponsor
of a project and the end users will need to be briefed and consulted throughout all stages of a
systems evolution. With a dataflow diagram, users are able to visualise in a physical visual form
how the system will operate, what the system will accomplish and how the system will be
implemented. Old system dataflow diagrams can be drawn up and compared with the new
systems dataflow diagrams to draw comparisons to implement a more efficient system. Dataflow
diagrams can be used to provide the end user with a physical idea of where the data they input,
ultimately has an effect upon the structure of the whole system from order to dispatch to restock
how any system is developed can be determined through a dataflow diagram.
The components of a data flow diagram (DFD) are:
1. Processes
2. Flows
3. Stores
4. Terminators (sometimes called sources and sinks)

Terminators are outside of the system being modeled. Terminators represent where information
comes from and where it goes. In designing a system, we have no idea about what these
terminators do or how they do it.
Processes  modify the inputs in the process of generating the outputs .
Stores represent a place in the process where data comes to rest. A DFD doesn't say anything
about the relative timing of the processes, so a store might be a place to accumulate data over a
year for the annual accounting process.
Flows are how data moves between terminators, processes, and stores.
It is recommended that every page in an DFD contain fewer than 10 components. If a process has
more than 10 components, then one or more components (typically a process) should be
combined into one and another DFD be generated that describes that component in more detail.
Each component should be numbered, as should each subcomponent, and so on.
ADMINISTRATOR
AGENT

Manage Subjects TEST Register for test

Students
Manage Questions
4U Manage

Manage Agents View Results

View Results

Add/Edit details
U
Change Password S
E
View Results R

Fig 3.3 – Level 0 DFD

3.5 Input Design

3.5.1 Input Design (1)

3.5.1.1 Layout Name : Login
3.5.1.2 Purpose: By this layout the administrator ,agent or the student of the proposed
system gets logged in to the system.
3.5.1.3 Description of Fields :
Username: Here username is entered by the administrator, agent or the student.
Password: Here password is entered by the administrator, agent or the student.
Sign in as: Here user select the role:Administrator,Agent or Student.
3.5.1.4 Validation Checks:
 Both username and password are entered by the user.
 Username is unique for every user.

3.5.2 Input Design (2)

3.5.2.1 Layout Name : Register as Agent

3.5.2.2 Purpose: By this layout a new user is able to create his account as agent.
3.5.2.3 Description of Fields :
Centre Name: Here name for the centre is provided.
Centre ID: Here username is entered by the user.
Password: Here password is entered by the user.
Confirm Password: Here user enters the password again.
Email: Here user enters his email id.
Phone No.: Here user the phone no.
Address: Here user enters the address.
3.5.2.4 Validation Checks:
 All the entries are entered by the user.
 Centre ID is unique for every user.
 Both password and confirm password must match.
 The email entered is unique and is in proper format.
3.5.3 Input Design (3)

3.5.3.1 Layout Name : Add Question

3.5.3.2 Purpose: By this layout adminsitrator is able to add questions.
3.5.3.3 Description of Fields :
Test Code: Here Test code of the subject is Selected.
Question: Here Question is entered by the Administrator.
Options: Here options are entered by the Administrator.
Correct Answer: Here Correct Option is selected..
3.5.3.4 Validation Checks:
 All the entries are entered by the user.
 There should be value of option corresponding to correct answer.

3.5.4 Input Design (4)

3.5.4.1 Layout Name : Add Subject

3.5.4.2 Purpose: By this layout adminsitrator is able to add subject.
3.5.4.3 Description of Fields :
Subject Name: Here Subject name is provided.
Test Level: Here Test level is selected by the Administrator.
Cost: Here cost is entered by the Administrator.
3.5.4.4 Validation Checks:
 All the entries are entered by the user.

3.5.5 Input Design (5)

3.5.5.1 Layout Name : Register for new test

3.5.5.2 Purpose: By this layout agent is able to register for a new test.
3.5.5.3 Description of Fields :
Test Code: Here Test Code is selected.
Date: Here Date of exam is selected by the Agent.
 No of Students: Here number of students to appear for examcost is entered by the
Agent.
Mode of Payment: Credit Card/Debit card or Demand Draft
3.5.5.4 Validation Checks:
 All the entries are entered by the user.
 Future date should be selected.

3.6 Output design

3.6.1 Output Design (1)

3.6.1.1 Layout Name: Results

3.6.1.2 Purpose: By this layout a student views his result.
3.6.1.3 Description of Fields:
 Student Name: This column displays Student’s name.
 Fathers Name: This column displays name of student’s father.
 Test ID: This column displays TestID for which examis given.
 Test Code: This column displays TestCode for which examis given.
 Marks: This column displays Marks Obtained.
 Questions Attempted: This column displays no. of Question Attempted.
 Questions Correct: This column displays no. of Question Correct.
 Result: This column displays result of the student: PASS/FAIL.
3.7 Menu Flow Diagrams

HOME

ADMINISTRATOR TEST USER

CONDUCTOR

ADD SIGN UP ADD

SUBJECT DETAILS

ADD REGISTER EDIT

QUESTION FOR TEST DETAILS

EDIT/DELETE ADD CHANGE

SUBJECT DETAILS PASSWORD

EDIT/DELETE EDIT APPEAR

QUESTION DETAILS FOR TEST

AGENT TEST RESULT

DETAILS RESULT

TEST RESULT CENTRE

RESULT

CENTRE
RESULT

COMPLETE
RESULT

Fig.3.5: Menu Flow Diagram

3.8 Use Case Description

(I) Use Case: Login

3.2.1 Purpose
 This use case is used for logging in by the user Administrator,
Agent or Student.
3.2.2 Actors
 Administrator
 Agent
 Student
3.2.3 Preconditions
 User should have a valid user name and password
3.2.4 Post Conditions
 User has successfully logged in
3.2.5 Basic flow
 User enters the user name
 User enters the password
 They are successfully logged in
3.2.6 Alternate flows
 User is the new user of the system

(II) Use Case: Manage Subjects

3.2.1 Purpose
 This use case is used by Administrator to add, edit or delete the
subjects.

3.2.2 Actors
  Administrator
3.2.3 Preconditions
 The administrator must be logged into the web site.
3.2.4 Post Conditions
 None
3.2.5 Basic flow
1. Administrator can add a new subject or select the Subject.
2. Administrator can edit or delete the selected subject.
3.2.6 Alternate flows
 None

(III) Use Case: Manage Questions

3.2.1 Purpose
 This use case is used by Administrator to add, edit or delete the
questions.
3.2.2 Actors
 Administrator
3.2.3 Preconditions
 The administrator must be logged into the web site.
3.2.4 Post Conditions
 None
3.2.5 Basic flow
1. Administrator can add new questions or select the
question.
2. Administrator can edit or delete the selected question.
3.2.6 Alternate flows
 None
 (IV) Use Case : Manage Agent Details
3.2.1 Purpose
 This use case is used by Administrator to add, edit or delete the
agents.
3.2.2 Actors
 Administrator
3.2.3 Preconditions
 The administrator must be logged into the web site.
3.2.4 Post Conditions
 None
3.2.5 Basic flow
1. Administrator can select the agent.
2. Administrator can edit the details or delete the selected
agent.
3.2.6 Alternate flows
 None

(V) Use Case: Register for Test

3.2.1 Purpose
 This use case is used for registering for a new test by the agent.
3.2.2 Actors
 Agent
3.2.3 Preconditions
 Agent must have logged into the web site.
3.2.4 Post Conditions
 Agent has successfully Register for a new test.
 Test ID is provided.
 3.2.5 Basic flow
 Agent select the option: register for a test.
 Agent enters the test code, date of exam, no of students and
based on that agent makes the payment.
 Test ID is generated.
3.2.6 Alternate flows
 None

(VI) Use Case : Manage Student Details

3.2.1 Purpose
 This use case is used by Agent to add, edit or delete the Students.
3.2.2 Actors
 Agent
3.2.3 Preconditions
 The Agent must be logged into the web site.
 Agent must have registered for a test.
3.2.4 Post Conditions
 None
3.2.5 Basic flow
 Agent can add student details for registered test select the
student.
 Agent can edit the details or delete the selected students.
3.2.6 Alternate flows
 None
(VII) Use Case: Edit Details
3.2.1 Purpose
 This use case is used for adding details or to change password by
the student.
3.2.2 Actors
 Student
3.2.3 Preconditions
 Student must have logged into the web site.
3.2.4 Post Conditions
 Student has successfully logged out.
3.2.5 Basic flow
 Student selects one of the various options given on the page i.e
add details, edit details(change password).
 Student can add the details or change the password according to
the option selected.
3.2.6 Alternate flows
 None

(VIII) Use Case: Appear for Test

3.2.1 Purpose
 This use case is used to give test by the Student.
3.2.2 Actors
 Student
3.2.3 Preconditions
 Student must have logged into the web site.
 Student must not have appeared for the test before.
3.2.4 Post Conditions
  Student has successfully completed the test.
 Result is generated.

3.2.5 Basic flow

 Student clicks on appear for the test option given on the page.
 Student selects the correct option for the question and submits
the test.
3.2.6 Alternate flows
 None

(IX) Use Case: View Result

3.2.1 Purpose
 This use case is used for logging outto view result by the
Administrator, Agent and Student.
3.2.2 Actors
 Administrator
 Agent
 Student
3.2.3 Preconditions
 User must have logged into the web site.
 At least there should be one student who have appeared for the
test.
3.2.4 Post Conditions
 None.
3.2.5 Basic flow
 User clicks on View Result option given on the choice page.
 Administrator can select: Test Result, Centre Result or Complete
Result.
  Agent can select: Test Result or Centre Result.
 Student canonly view his own result.

3.2.6 Alternate flows

 None

Sign Up

Edit
Questions
Edit
Subjects

Administrator
Unregistered User Manage Agent
Details

Register for
Test
View
Results

Login

Manage
Student
Details
Agent (Test Conductor) Edit Details
Student

Give Test
 Fig 3.6 Use Case Diagram

Chapter Four
BODY OF THESIS
4.1 System Interfaces

4.1.1 Feasibility Study:

Feasibility study is a preliminary study undertaken before the real work of a project starts to
ascertain the likelihood of the project's success. It is an analysis of all possible solutions to a
problem and a recommendation on the best solution to use. It involves evaluating how the
solution will fit into the corporation.
It is used to determine if the project should get the go-ahead. If the project is to proceed, the
feasibility study will produce a project plan and budget estimates for the future stages of
development.

4.1.1.1 Technical Feasibility:

The key customer benefits kept in mind while envisaging this architecture were:-
1. Higher maintainability, extensibility and configurability.
2. Improved performance and scalability.
3. Lower Cost of Ownership.
4. Better productivity.
5. Lower business risk.
6. System Performance.
7. System Interfaces.
8. Development Processes.
9. Risk Assessment.
10. Staff Qualifications.
11. Failure Immunity.
12. Customer Support.
13. Security.

4.1.1.2 Economical Feasibility

Cost Benefit Analysis was done in this stage. Following activities were performed during this
stage:-
1. Each phase of the project was analyzed for the cost involved in it.
2. This was calculated based upon resources and infrastructure used.
3. Benefits of each phase which were the end products were analyzed and listed.
4. Both cost involved and benefits obtained were compared to the details to get the final result.

4.1.1.3 Operational Feasibility

How well the solution will work in the organization and how the end-users and managers
feel about the system.
This is important because a workable solution can be thrown away because of end-user or
management doesn’t want the system. Therefore usability is another important factor.
Usability analysis is often performed with a working prototype of the proposed system. Test
of system’s user interfaces and measured in how easy they are to learn and to use and how they
support the desired productivity levels of users. Easy to learn, use and user satisfaction are other
things which are considered here.

4.1.1.4 Other Feasibility Dimensions

Scheduling Feasibility was one of the dimensions. Measure of how reasonable the project
timetable is. Schedule can be mandatory or desirable. It’s better to deliver a properly functioning
information system later than to deliver an error-prone.
1. Measure of how reasonable the project timetable is.
2. Gantt chart was made.
3. Work allocation was finalized.
4. Time value for money was analyzed.

4.2 System Specifications:

4.2.1 Hardware Requirements

 SERVER
 A Server with Pentium 500 MHz or higher processor, 512MB RAM.
 Minimum 10 GB Hard Disk Space recommended.
 1024x768 Pixels Screen Resolution for proper viewing of Screens.
 CLIENT
 A PC with Pentium/Celeron Processor, 256MB RAM.
 1024x768 Pixels Screen Resolution for proper viewing of Screens.

4.2.2 Software Requirements

 Operating System : Windows XP service pack 2
 RDBMS : Microsoft SQL Server 2008
 Scripting language : Visual C#
 Web technology used : ASP.Net
 Web server to be used : Microsoft visual web developer
 Web Browser : Microsoft Internet explorer 7.0
or Mozilla Firefox 3.5 or Higher
4.3 Constraints:

1. Admin will have to implement a security policy to safeguard the customer’s information. It
should not be modified or used by unauthorized users (by means of gaining access to backend
database). These days’ data is very important to companies and wrong use of data can take away
our esteemed customers from us.
2. We should have proper backup of the essential details and all the information, since any
information lost can affect the business very heavily.
3. The admin has to update the details shows regularly so that user is provided with various
details whenever he views the web site.

4.4 Assumptions & Dependencies

 User must know internet browsing fundamentals

 User must be having internet access.
4.5 User Characteristics
 User must know internet browsing fundamentals
 Registered user must have a valid registration id obtained by registering with
the website and must remember his password
 Administrator must remember his secure password
Chapter Five
TESTING
5.1 Testing Methodology:

Software testing is the process used to help identify the correctness, completeness, security
and quality of developed computer software. Testing is a set of activities that can be planned in
advance and conducted systematically. Testing can never completely establish the correctness of
arbitrary computer software. In other words, testing is criticism or comparison that is comparing
the actual value with an expected one. Testing is the process of exercising the software item to
detect the differences between its behavior and the desired behavior as stipulated by the
requirements specifications- 'what is' and 'what should be'. To achieve a very high standard in
quality of delivery, a comprehensive and planned testing will be carried out during project
execution. The Testing phase follows the coding and unit-testing phase. Testing a program
basically consists of providing the program with set of test inputs or the test cases and observing
whether the program behaves in the normal and expected manner. The condition under which the
programs behaves in an unexpected manner and deviates from its normal course is noted for
debugging and correction.

The objective is to design tests that systematically uncover different classes of errors and do
so with a minimum amount of time.

Performance requirements appear to have been met Data collection during testing provides a
good indication of software reliability and some indication of software quality. Testing cannot
show the absence of defects, it can only show that software defects are present.

5.2 Unit Testing:

Unit testing is a procedure used to validate that the individual modules or units of source
code or functions are working properly. Ideally, each test case is independent from the others;
mock objects can be used to assist testing a module or a piece of a module in isolation. Unit
testing is typically done by the developers and not by end-users.

The purpose of unit testing is to identify and correct as many internal logic errors as
possible. Unit tests would be repeatable and may be conducted at any point in the
implementation process in accordance with the approved unit test plan for the module I project
The goal for unit testing by developers is to perform selected path testing in which every affected
branch is navigated in all possible directions at least once and every affected line of code is
executed at least once. The developer would do unit testing at time of coding.

Definition of a unit
1. Screens with its associated services, which help to display, add, modify, delete, authorize
or list data.
2. Any function, which encapsulates business logic for a batch job or a service.
3. Batch jobs separated as a unit.
4. Library functions being provided by any module to be considered as a unit.

Aim of Unit Testing

1. To test a unit of code after coding of that unit is completed.
2. To utilize a finite number of test cases to detect the maximum number of errors using
minimum resources.
3. To achieve maximum test coverage.

Pre-requisite to Unit Testing

1. Unit test Plan and Unit Test specifications reviewed by QA are available.
2. Reviewed code with all the identified defects fixed.
3. The data setup is in place for the unit testing
4. Stubs used by the unit are ready.

Unit Testing Deliverables

The deliverables from the unit testing will be:
1. Unit test logs.
2. Unit tested code.
3. Product delivery note to move the unit to system testing environment.
5.3 Integration Testing

Definition of an Integrated Unit

1. A Batch job
2. All the screens of a particular module.
3. All screens which provide the facility to access screens of another module.

Aim of Integration Testing

To prove that the various programs making up the system are compatible, fit together and the
interfaces between the programs are correct

Integration Testing Constituents

To check if the integrated unit technically and functionally achieves its purpose.

Pre-requisite to Integration Testing

1. Integration test plan and specifications reviewed by QA are available.
2. Unit tested and verified code.
3. Compile scripts for the units under the Integrated Unit.

Integration Testing Deliverables

The deliverables from the Integration testing will be:
1. Integration test logs.
2. Tested code.

5.4 System Testing

System testing is testing conducted on a complete, integrated system to evaluate the system's
compliance with its specified requirements. System testing falls within the scope of Black box
testing, and as such, should require no knowledge of the inner design of the code or logic. It
requires testing the system as a whole.
Objective of System Testing

Test the system requirements and the resilience of the software

Integration Testing Constituents

To check if the integrated unit technically and functionally achieves its purpose.

Pre-requisite to System Testing

Integration testing is completed and specifications for each node.

System Testing Deliverables

The deliverables from the Integration testing will be:
1. System Test Plans
2. System Test Specs

FUNCTIONAL TESTING

The objective of this test is to ensure that each element of the application meets the
functional requirements as outlined in system specifications. Functional testing covers the
aspects of the system executing functions it is supposed to execute-including user commands,
data manipulation, searches and business processes, user screens, and integrations. Functional
testing covers the obvious surface type of functions, as well as the back-end operations (such as
security and how upgrades affect the system). Before executing the system test cases in full, a
limited functional testing will be performed with a subset of system test case where the system
will be run on two (or may be more is to be decided) business days and covering end-to-end two
(or may be more is to be decided) event types. This is done to verify if all the components of the
system is installed properly and to do a basic functionality testing. This will conclude high-level
testing. It will be followed by detailed-level tests, which will aim to test the individual processes
and data flows.
AUTOMATED TESTING

In software testing, automated testing is performed, to a greater or lesser extent by a

computer. Software testing involves devising a test case (or, more likely, a set of test cases),
running the program with the test case, and checking that the performance of the software with
the test case as input is as expected. All three aspects of testing can be automated to a greater or
lesser extent. The most straightforward aspect of testing to

automate is the execution of test cases. For programs which do not normally interact directly
with users (and instead "respond" to the contents of a disk file or instructions passed over a
network, or take input as text from a keyboard), it is relatively simple to write small programs
(usually called test scripts) to provide the appropriate input. It is somewhat more complex for
programs with a graphical user interface (GUI) to do similarly, but specialized scripting tools for
controlling GUI programs exist and are commonly used for performing testing on this class of
applications.

INTERFACE TESTING
The various programs that facilitate the exchange of data between the interfacing systems
will be tested through the Interface sub testing. The process of Interface testing will be
interlinked to the system testing activity, by incorporating the messaging requirements within the
system test conditions.
Non-Functional Testing: Besides testing to check whether the application meets all the functional
requirements, following Non-Functional Testing would be carried out in this phase:

INSTALLATION TESTING

Installation testing can simply be defined as any testing that occurs outside of the
development environment. Such testing will frequently occur on the computer system the
software product will eventually be installed on. While the ideal installation might simply appear
to be to run a setup program, the generation of that setup program itself and its efficacy in a
variety of machine and operating system environments can require extensive testing before it can
be used with confidence.

In distributed systems, particularly where software is to be released into an already live target
environment (such as an operational web site) installation (or deployment as it is

sometimes called) can involve database schema changes as well as the installation of new
software. Deployment plans in such circumstances may include back-out procedures whose use
is intended to roll the target environment back in the event that the deployment is unsuccessful.
Ideally, the deployment plan itself should be tested in an environment that is a replica of the live
environment. A factor that can increase the organizational requirements of such an exercise is the
need to synchronize the data in the test deployment environment with that in the live
environment with minimum disruption to live operation. Installation Testing is testing of full,
partial or upgrades install/uninstall processes.

1. To check ease of installation

2. To check whether the Installation can be carried out as per the installation Manual
3. To check whether data migration is done successfully
4. To check whether Installation can be done on multiple platforms (for instance on AIX
and Mainframe)

PERFORMANCE TESTING

Performance testing is perhaps the biggest area of testing. The different types of
performance testing that can be done:

1. Classic performance testing, which measures response times and transaction rates.
2. Load testing, which measures the system's ability to handle varied workloads.
3. Stress testing, which looks for errors produced by low resources or competition for
resources.
 4. Volume testing, which subjects the software to larger and larger amounts of data to
determine its point of failure.

USER INTERFACE TESTING

1. To check whether the User Manual co-relates with the user interface.
2. To check the ease of use in cases of large volumes of data
3. To check the ease of usage of the User Interface under Normal loads.

SYSTEM INTEGRATED TESTING

The System Integration Testing is a testing process that shakes down source code developed and
fixes any variance before proceeding to the next testing phase. To complete (or exit) SIT; there
must be fewer variances than can be tolerated. Various components will be integrated with each
other and with external system via external interfaces.

Integration testing will be performed to ensure:

1. Various modules making up the application fit together.

2. Interfaces with external systems are working as per the expectations.

The purpose of this testing is to verify functional, performance and reliability requirements
placed on major design items. These "design items", Le. assemblages (or groups of units), are
exercised through their interfaces using Black box testing, success and error cases being
simulated via appropriate parameter and data inputs. Simulated usage of shared data areas and
inter-process communication is tested; individual subsystems are exercised through their input
interface. All test cases are constructed to test that all components within assemblages interact
correctly.
REGRESSION TESTING

Regression testing is any type of software testing which seeks to uncover regression bugs.
Regression bugs occur whenever software functionality that previously worked as

desired stops working or no longer works in the same way that was previously planned.
Typically regression bugs occur as an unintended consequence of program changes. Common
methods of regression testing include rerunning previously run tests and checking weather
previously fixed faults have reemerged. Therefore, in most software development situations it is
considered good practice that when a bug is located and fixed, a test that exposes the bug is
recorded and regularly retested after subsequent changes to the program. Although this may be
done through manual testing procedures using programming techniques, it is often done using
automated testing tools. Regression testing is an integral part of the extreme programming
software development methodology.

5.5 User Acceptance Testing (UAT)

User Acceptance Testing (UAT) is a process to obtain confirmation by test, through trial or
review, that the modification or addition requirements. In, UAT is one of the final stages of a
project will often occur before a client or customer accepts a new system. Users of the system
will pert developers have derived from the client's contract or the user requirement. The idea is
that if the software works as intended and without issue during a simulation of normal use ,it will
work just the same production. These tests are not of problems (spelling mistakes, cosmetic
problems) or showstopper software crashing, software will not run etc.). Developers should have
during unit testing and integration testing. The results of these tests will confidence to the
customers of how the system will perform in production. Client will carry out acceptance of
deliverables. Defects, if any, observed by Client, will be notified 0 the immediate previous
baseline or acceptance whichever is later.
5.6 Implementation

5.6.1 Acquisition

The project is developed on the system having following configuration:

Operating System: Microsoft Windows XP Service Pack 2

Processor: Intel Dual core

1. CPU: 1.5GHz
2. RAM: 1.0 GB
3. HDD: 160 GB

5.6.2 Training Needs

1. User must have good knowledge of English Language, as the system developed contains
textual data in English language only.

2. User must have basic knowledge of internet access.

5.6.3 User manual

1. You must have internet explorer and the basic knowledge of accessing Internet.

2. You must have good knowledge of English language, as the site is totally developed in
English language.

3. Enter the path of the site in the browser window.

4. Front page of site appears, select the relevant link which you need to access.
 Chapter Six
RESULTS AND OBSERVATIONS
6.1 Conclusion
Online Examination System is user friendly. Various validations checks are provided
whenever any data entry is made. Error messages are displayed on the screen for incorrect
entries. Password facility is provided for security at various levels. It provides efficient and
quicker service to all users. It provides easy access to the database. It provides flexibility to
accommodate future needs. It eliminates duplication of works and provides a convenient and an
effective information system.

6.2 Limitations of the System

In this project all the transactions are done via credit/debit card. For this credit/debit card
system is required to be developed, which requires a web service and some transactions with the
banks also. So this feature is not considered here.

6.3 Future Scope for Modification

This project ‘Online examination System’ is very much flexible and simple that it is easy to
understand, easy to handle databases and if any changes required that can be easily formulated.
This project can also be enhanced to generate daily, weekly or monthly reports of the
transactions made for the administrator.
We can also include practice test and tutorilas for students to practice. Also study
material can be provided.

6.4 References & Bibliography

Books
1. Microsoft® Visual C#® 2008 – Donis Marshall
2. Wrox Professional – Beginning ASP.NET 3.5 in C# & VB

3. Microsoft ASP.NET 3.5 – Dino Esposito

Websites
1. http://www.codereference.com/book/csharp.aspx
2. http://www.programmersheaven.com/2/CSharpBook
3. http://www.w3schools.com/sql/sql_intro.asp
4. http://www.sql-tutorial.net/
 Appendix A

SCREEN SHOTS

SCREEN SHOTS
Fig. 6.1 Home Page
Fig. 6.2 Add Subject Page
Fig. 6.3 Edit Subjects Page
Fig. 6.4 Add Question Page
Fig. 6.5 Complete Result Page
Fig. 6.6 Register For a Test Page-1
Fig. 6.7 Register for a Test Page-2
Fig. 6.8 Enter Student Details Page
Fig. 6.9 Centre Result Page
Fig. 6.10 Add Details Page(Student)
Fig. 6.11 Change Password Page
Fig. 6.12 Rules Page
Fig. 6.13 Appear Test Page
Fig. 6.14 User Result Page