CHAPTER I

INTRODUCTION

Page 1
1. INTRODUCTION

This project entitled UNIVERSITY ONLINE ADMISSION SYSTEM

aims at developing an online admission application for a university. This system is
an online system that can be accessed throughout the organization and outside as
well with proper login provided. Our system has two type of accessing modes,
administrator and user. Student management system is managed by an
administrator. It is the job of the administrator to admit and monitor the whole
process. When a user log in to the system. He would only view details of the
student. He can't perform any changes .The system has two modules. They are
User and Administrator. Students logging is to apply for the course by filling an
application form provided by online. University administrator logging in may also
access/search information put up by the students. The process begins with a
potential student completing an application form through the colleges admission
service ,the first step for students is to apply directly to the college through a
custom online form. The next phase is for the admission service center has to
review the application and ensure that all of the required information has been
provided, from the form itself to the supplementary documentation, such as address
and HS certificate .If any of the required information is missing, it is the secretary
for the department to which the application concerns that contacts the potential
students and arranges for the delivery of the outstanding data. The application in its
entirely is then forwarded ,complete with recommendation ,to the respective
departments admission tutor ,who has the finally say as to whether each potential
student is accepted or rejected .Before making a decision ,the admission tutor
reviews the application and the additional documentation ,comparing the academic
credentials to a list of college rankings and previous ,similar application.

Page 2
CHAPTER II
OBJECTIVES

Page 3
OBJECTIVES

The main objectives of the project are to develop a system that incorporates
the time of the UNIVERSITY ONLINE ADMISSION SYSTEM of Bodoland
University is:

To replace the age-old manual system by an efficient modern

computerized system.
To case the management from time consuming manual system.
To store data with less redundancy.
To generate reports automatically with less time at any time.
To overcome the problems of reliability, accuracy, searching,
updating, modification deletion of record etc.
Manage large number of students details.
Creates student accounts and maintain the data effectively.
View all the details of the students
Create the statistical reports to facilitate the finance department work.
Reduce the work load in interview the students for selection and
counseling should be very effective rather than direct methods.
The system must support undo the previous activities if any problem
occurs.

Page 4
 CHAPTER III
PROBLEM STATEMENT

Page 5
PROBLEM DEFINITION

A new system has to create based on the guidelines laid down the existing
system and at the same time identify and remove the various limitation of the
existing one. The system has to create the new needs of the users and take steps in
reduction of coding and data entry. The basic for the candidate system is
recognized of the need for improving and information system or procedure. This
need lead to the preliminary or survey and initial investigation to determine
whether an alternative system can solve the problem.

EXISTING SYSTEM

The existing system is a manual system and any manual system requires
numerous papers writing works, with stored data. So there is need of initial training
required for the staff to become familiar with the paper works and a fair bit of time
required to physically complete and manage. Before a system development process
begins, there must be a significant expression of need. This expression of need
comes from perceiving a problem from the existing system. Therefore the system
developer must investigate and find out the problems at the very beginning of his
development process. Then he will be able to define clearly the goals required to
meet the objectives.

Some of the problems of manual systems are:

Difficulty in proper maintenance of records.

Earlier, data pertaining to students was maintained manually.
Manual system was not efficient.
Cost of maintaining data manually was bigger or huge.
Large manpower was required.
The procedure was error prone, it was not accurate.
Manual system was not suited for electronic exchange of data.
Data inconsistency can occur due to the duplication of records
Entire work is time consuming.
Lake of strong security.

Page 6
 Automatic report generation is not possible.

PROPOSED SYTEM

DESCRIPTION

Now a day it is seen that all modern offices are "Paperless. That means they
are maintaining a system where there is no use of any paper work. They dont
maintain any paper files to keep records and data. Every single record can be found
in a computer screen just at click of mouse with lightening speed.

SCOPE OF THE PROPOSED SYSTEM

The system under development must include all those activities that are
necessary for smooth functioning. The most important aspects of the proposed
system is to provide more efficient in the application field in order to save time and
manual labour in records maintenance of a huge amount of records, speeding up
queries and faster processing are key factors relating to the development process.
All the functions, related to the system, must be closely integrated and all the
records must be stored in a centralized database. In contrast to this and above
mentioned objectives the system deals in the following aspects such as:
Increasing efficiency in data storing.

Accuracy of data and their fast updating.

Developing an easy to use and time saving computerized system.
Manage large number of student details.
Manage all details of students who registered for the course.
View all the details of the students.

ADVANTAGES OF THE PROPOSED SYSTEM

The aim of the proposed system is to overcome the limitation of the existing
system. The requirements for the system have been gathered from the defects

Page 7
recorded in the past and also based on the feedback from users of previous metrics
tools. Following are the objectives of the proposed system:

Reach to geographically scattered students: One of the important

objectives of the online admission system is communicate with all
the students scattered geographically.
Reducing time in activity: Reduce the time taken process the
application of students, admitting a student, conducting the online
examination, verify student marks, and send call letters to selected
students.
Centralized data handling: Transfer the data smoothly to all the
departments involved and handle the data centralized way.
Paperless admission with reduced manpower: Reduce the
manpower needed to perform all the admission and administration
task by reducing the paper works needed.
Cost cutting: Reduce the cost involved in the admission process.
Operational efficiency: Improve the operational efficiency by
improving the quality of the process.

Page 8
 CHAPTER IV
REQUIREMENT ANALYSIS

Page 9
INTRODUCTION

Requirement analysis is done in order to understand the problem the

software system is to solve. The problem could be automating and existing manual
process, developing a new automated system. The emphasis in requirements
analysis is an identifying what is needed from the system, not how the system will
achieve its goals. This task is complicated by the fact that there are often at least
two parties involved in software development a client and a developer. The
developer has to develop the system to satisfy a clients need. The developer
doesnt understand the clients problem and the client doesnt understand the issues
involved in software systems. This causes a communication gap, which has to be
adequately bridged during system analysis. The establishment and use of sound
engineering principles in order to obtain economically developed software that is
reliable and works efficiently on real machines is called software engineering.
Software engineering is the discipline whose aim is:

Production of quality software.

Software that is delivered on time.
Cost within the budget
Satisfies all requirements.

Software process is the way in which we produce the software. Apart from hiring
smart, knowledgeable engineers and buying the latest development tools, effective
software development process is also needed. So that engineers can systematically
use the best technical and managerial practices to successfully complete their
projects. A software life cycle is a descriptive and diagrammatic representation of
the software life cycle. A life cycle model represents all the activities required to
make a software product transit through its life cycle phases. It also captures the
order in which these activities are to be taken.

SOFTWARE REQUIREMENT SPECIFICATION

This document aims at defining overall software requirement for

UNIVERSITY ONLINE ADMISSION SYSTEM. Efforts have been made to
define the requirements exhaustively and in this document and assumptions for any

Page
10
additional functionality/feature should not be made by any of the parties involved
in developing/testing/implementing/using this product.

The following subsections of the SRS document provide an overview of the

entire SRS.

Purpose: The purpose of the project is to provide online facility to

Bodoland University to conduct admission online. Administrator can
enter, edit and update students information. Students can login and
find their results of the selected student for the admission
Scope: The web application provides facility to institutes to manage
online admission by providing a unique id too. All the information
entered can be later edited by the administrator.
Benefits: This website reduces the manual work, maintaining
accuracy, increasing efficiency and saving time. Also institutes need
not go to develop new software each time; instead they just register
and manage the result. For students, it saves time of going
too far away for view their result from home.
Overview: The rest of this SRS document describes the various
system requirements, interface, features and functionalities in detail.

SOFTWARE AND HARDWARE REQUIREMENTS:

The entire application was developed and deployed in a client/server

environment. A combination of GUI tools, data base server software is necessary
in a typical client/server application.

SOFTWARE REQUIREMENTS (for development)

Operating System: Windows

Database: MySQL
Server: Wamp
Application program: Notapad ++

Page
11
HARDWARE REQUIREMENTS

The hardware configuration of a system on which the package was

developed is as follows.

For the server:

Pentium PC
32 GB RAM
256 KB external cache memory
Operating System: Windows8/Windows7
4GB hard disk
32 bit Ethernet control

For the client:

Pentium PC
2GB RAM
4GB hard disk
Operating System: Windows
1 serial port(for the mouse connection)
1 parallel port(for the printer)
LAN connection
Browser

Page
12
 CHAPTER IV
FEASIBILITY STUDY

Page
13
INTRODUCTION

Feasibility is the test of the system, it helps in deciding whether it is viable

to go through the project or not. Feasibility study studies the system & tells
whether to develop the system or not. It can be described as the test of the system
& if the system passes in the test then it is viable to develop the project otherwise
not or we can say feasibility study checks whether project is feasible or not.
Feasibility has the following types

Technical Feasibility:

This system uses one of the simplest technologies in use, for the
development purpose it uses simple to use & easily available technology. This
system is based on windows like interface, which is very easy to use. The package
is been developed for the department, which is not very familiar with software
hence technology used, must be easily understandable, because of which windows
like interface has been chosen. The technology used in this project is Visual Studio
2012(ASP.net) using VB.net, M S Access & DAO controls. Visual Basic helps in
providing windows like environment. This system uses menu-based approach in
which everything is given with the help of menus.

Economic Feasibility:

This dimension measures the system in respect to money or we can say

funds. This dimension checks whether its viable to spend the required amount on
the system or it will be a waste. There is no problem of finance in this project
because it uses simple technology, which is very easy to install. This system is
been developed for a standalone computer hence for this system hardware
requirement is very low. For this system to be developed & installed properly we
require very easily available technologies & very basic hardware and all these
requirements dont cost much.

Behavioral Feasibility:

The behavioral feasibility should also be judged in order to estimate the

mentality of the people to whom the system is being carried out as well as ultimate
beneficiaries. My project is behavioral feasibility because my project can be used
by people.

Page
14
 In case if they are not motivate to use the propose system, the whole
proposed system would be messy and the project will be a failure.

Page
15
 CHAPTER VI
SYSTEM ANALYSIS

Page
16
SYSTEM ANALYSIS

It is the most critical phase of the system development life cycle. Analysis
involves a detailed study of the current system, leading to specification of a new
system. Analysis is a delayed study of various operations performed by a system
and their relationship. The analysis of the project begins with a series of modeling
tasks that lead to a complete specification of requirements and a comprehensive
design representation for the software to be built.

The analysis model achieves two primary objectives:

To establish a basis for the creation of a software design, and

To define a set of requirements that can be validate once the software
is built.

Two dominant analysis modeling method are very common:

Structural analysis
Object oriented analysis

STRUCTURAL ANALYSIS:

Structural analysis is a set of techniques and graphical tools that allow the
analyst develop a new kind of specification that is easily understandable to the
users.

In this phase of the system development a team comprising of the concerned

students under the supervisor of a guide has conducted an in-depth analysis of the
proposed system. The team has reviewed the area of information needs the users,
data volume, integration requirement etc.

Here is the phase we represent the context diagram and the DFD of the
system to conceptualize the proposed system easily. The processes are partitioned
so that we have a clear picture of the application under development. To achieve
these a rigorous study of the user area has been made, so that no major flaws occur
in the later part of the system development.

Page
17
 The main features of structural analysis are:

It is graphical. The DFD, for example, depicts a picture of what is

being specified and makes it conceptually easy to understand the logic
of the application.
The process is partitioned so that we have a clear picture of
progression from general to specific in the system flow.
It is logical rather than physical. The element of the system does not
depend on the hardware. They specify the system in a precise, concise
and highly readable manner.
It collects for the rigorous study of the user area, a commitment that
is often taken lightly in the traditional form of system analysis.
Certain task that is normally carried out late in the system
development cycle is moved to the analysis phase. For example,
users procedures are documented during analysis rather than later in
the application.

The end of result structured analysis produces a structured specification that uses
several basic tools such as:

Process description
Data dictionary
Decision table
Decision tree

CONTEXT DIAGRAM:

Context diagram is the starting in the structured analysis. They are

constructed to show the highest-level model of the system. They are used to
represent pictorially the scope or the boundaries of the system. Actually the system
shown by the context diagram does not describe the system in detail. For more
details it is necessary to identify the major system process and draw a data flow
diagram made up of these processes and the data flow between them. Such a
diagram is called Top-Level DFD. We can go on expanding each process of the
top-level DFD into a more detailed DFD.

Page
18
DATA FLOW DIAGRAM

A DFD shows the flow of data through a system. It views the system as a
function that transforms the inputs into desired outputs. The DFD aims to capture
the transformations that take place in a system to the input data so that eventually
the output data is produced. A DFD does not represent procedural information.
Loops and decisions must be ignored. While drawing DFD the designer has to
specify the major transformation in the path of data flowing from input to the
output. How does transformations are performed is not an issue when one is
drawing Data flow diagram.

Process: A circle or bubble represents a process that transforms incoming

data to outgoing data. Process shows a part of the system that transforms inputs to
outputs.

Data flow: The data flow is used to describe the movement of information
from one part of the system to another part. Flows represent data in motion. It is a
pipe line through which information flows.

Source or sink: The data store represents a logical file. A logical file can
represent either a data store symbol which can represent either a data structure or a
physical file on disk. The data store is used to collect data at rest or a temporary
repository of data. It is represented by open rectangle.

External entity: A square defines a source or destination of system data.

External entity represents any entity that supplies or received information from the
system but is not a part of the system.

SYMBOL REPRESENTATION

Circle or Oval Process

Page
19
Arrow- Data flow

Open Rectangle Data store (Source or Sink)

Closed Rectangle External Entry

Context Diagram:

The context diagram or Level 0 DFD is a special case of DFD. In the

diagram given below the circle labelled UNIVERSITY ONLINE ADMISION
SYSTEM (UOAS) for university represents the entire system.

Create profile
& form fillup Manage

Applicant OAS Admin

Get Response Selection result

Fig. Level 0 or context diagram of University online admission system.

Page
20
Level 1 DFD for UOAS

Read/ update
1.0
Manage Course datastore
Mange course
Admin
Read

Read/ update 2.0 Update

Applicant
Form fillup
Application datastore

Get selection
info.
Select

3.0

Selection of
application

Fig. Level 1 DFD for UOAS

Page
21
Level 2 DFD of 2.0 for UOAS

2.1
Read
Course datastore
Course
selection
Applicant

Details of
applicant
2.2 Update
Application datastore
Form fillup
(Entry)

Give ID &

Password

2.3

Generate ID

Page
22
System flow chart of student.

Start

View Admission Information

No Is
Interested?

Yes

Fill Admission Form

View Merit List

Stop

Page
23
Flow Chart for admin

Start

Username/
Password

Is Valid? No

Yes

Manage Information

Review Admission Form

Yes No
Is Eligible?

Select Candidate Reject Candidate

Generate Selected Candidate List

Post announcement to Website

Stop

Page
24
CHAPTER VII
SYSTEM DESIGN

Page
25
SYSTEM ANALYSIS

Software design is a process through which requirements are translated into

a representation of software. It may be define as the process of applying various
techniques for the purpose of defining a device, a process or a system in sufficient
detail to permit its physical realization. It facilities the understanding and provide
the procedural details necessary for implementation of the system recommended in
the feasibility study. Emphasis is given on translating the performance
requirements into design specification.

Design goes through logical and physical stages of development. Logical

design reviews the present physical system; prepares input and output
specification, make edit, security and control specifications; details the
implementation plane, and prepare logical design walk through. The physical
design maps out the details of the physical system, planes the system
implementation plane and specifies any hardware and software. System design
translates the system requirements into a ways of the system recommended in the
feasibility study. So system design is a translation from a user-oriented document
to a document oriented to a programmers or database personal. System design is
highly creative processes which can be greatly facilitate by the following:

Strong problem definition

Pictorial description of the existing system
Set of requirements of the new system

The database design phase covers E-R diagram, database design and
integrity constraint diagram. Similarly architectural design covers menu hierarchy
design, form design, report format design, application flow diagram and security
measures.

LOGICAL DESIGN With data is no system, but some data must provide in
the right screen for input and the information produces must be in a format
acceptable to the user. The screen carries some data, which come from the people;
the information output of the system goes to the people. Screen is a physical carries
of data of information.

Page
26
 ENTITY-RELATION (E-R) DIAGRAM Entity-relation (E-R) diagram
shows the different entities with their attributes and their attributes in the system
and their relationship. E-R diagram is frequently used for conceptual design of data
base application.

Entities and Attributes: The basic object that the E-R model represents is
an entity, which is a thing in particular property that describes it.

Several types of attributes in the E-R model are:

Simple or Composite: Composite attributes can be divided into smaller

subparts, which represents more basic attribute with independent meaning.
Attributes that are not divisible are called simple or atomic attributes

Simple valued vs Multi valued attributes: Most attributes have a signal

value for a particular entity; such attributes are called as single valued. In some
cases an attribute can have asset of values for a same entity.

Stored vs Derived attribute: In some cases two attribute values are related.
For example the age and birth date attributes of a person. For particular person
entity, the value of age can be determined from current that and the values of
persons birth date. The age attribute is hence called stored attribute.

CARDINALITY

Cardinality: The data model must be capable of representing the number of

occurrences of objects in a given relationship. The cardinality of an object-
relationship pair are:

One-to-one (1:1): An occurrence of object A can relate to one and

only one occurrence of object B and an occurrence of B can relate
to only one occurrence of A.
One-to-many (1:N): One occurrence of object A can relate to one or
many occurrences of object B but an occurrence of B can relate to
only one occurrence of A.

Page
27
 Many-to-many (M: N): An occurrence of object A can relate to one
or more occurrences of B, while an occurrence of B can relate to or
more occurrences of A.

Cardinality defines the maximum number of object relationships that can

participate in a relationship.

Particular constraints specify whether the existence of an entity dependence on its

being related to another entity via the relationship type. There are two types of
partition constraints-total or partial.

Total participation means that an entity exists only when it participates in the
relationship specified. It also called existence dependency. Partial participation
means that an entity can exists independently even if some of the instances do not
participate in the relationship specified.

WEAK ENTITY TYPE:

Entities types that do not have any key attributes of their own are called
weak entity. Being related to specific entities from other identifies entities
belonging to a weak entity type are in combination with some of their attribute
value.

MODALITY

The modality of a relationship is zero if there is no explicit need for the

relationship to occur or the relationship is optional. The modality is 1 if an
occurrence of the relationship is mandatory

Page
28
ER Diagram:

Course Father Mother

name Name
Course
Code Description

PO

ID
Applicant
Contact
Course Login ID

1
Password
Apply for
Vill
Course ID
have

have
M Selected

Application
ID
Apply date

Fees Application No Applicant ID

Fees
amount

Page
29
DATA DICTIONARY

A data dictionary is a structured repository of data about data. It is a set of

rigorous definition of all DFD data elements and structures. A data dictionary has
many advantages. The most obvious is documentation; it is a valuable reference in
any organization. Another advantage is improving analyst user communication by
establishing consistent definitions of various elements, teams and procedures. Also
a data dictionary a data dictionary is an important step in building a database.
Three classes are to be defined in a Data dictionary. They are:

Data elements: It is the smallest unit of data that provides for no further
decomposition.

Data structure: It is a group of data element handled as a unit.

Data flow and data stores: They are data structure in motion and data structure in
rest respectively. In constructing the Data dictionary the analyst have to consider
several points:

Each data flow in the DFD has one Data dictionary entry.
Definition must be readily accessible by name.
There should not be data redundancy in the data definition.
The procedures for writing definition should be precise.

DATABASE DESIGN: The collection of data is usually referred to as the

database. The objective of database is accuracy and integrity, successful recovery
from failure, privacy and security of data and good overall performance. The
database contains information about the particular enterprise. Database systems are
designed to store and manage large volume of information. The management of
data involves both the definition of structures of the storage of information and
provides mechanism for the manipulation of information. In addition, the database
system must be responsible for safety of information stored in the database, despite
system crashes or unauthorized access.

As regard the system under consideration, as it is to be developed and

installed on a relational DBMS. The database has been designed in the form of
some normalized relational tables. For the purpose, the system has been analysed

Page
30
to determine the entities and their attributes. After the considering the relationship
between different entities as depicted while studying the existing system and
talking in to account the requirements of the proposed system.

announcement
Column Type Null Default Comments
announcement_id (Primary) int(20) No
announcement_name varchar(255) No
announcement_description text No
date_posted date No
announcement_doc text No

Indexes

Uniqu Packe Cardinalit Collatio Nul Commen

Keyname Type Column
e d y n l t
PRIMAR BTRE announcement_i
Yes No 2 A No
Y E d

applicant
Column Type Null Default Comments
applicantID (Primary) int(11) No
session_id int(11) No
session_year varchar(255) No
course varchar(255) No
programme varchar(255) No

Page
31
applicantName varchar(255) No
popName varchar(255) No
momName varchar(255) No
guardianName varchar(255) Yes NULL
dob text No
gender varchar(255) No
religion varchar(255) No
nationality varchar(255) No
caste varchar(255) No
board_university_10 varchar(255) No
passingyear_10 varchar(255) No
marksobtained_10 varchar(255) No
percentage_10 varchar(255) No
grade_10 varchar(255) No
board_university_12 varchar(255) Yes NULL
passingyear_12 varchar(255) Yes NULL
marksobtained_12 varchar(255) Yes NULL
percentage_12 varchar(255) Yes NULL
grade_12 varchar(255) Yes NULL
board_university_UG varchar(255) Yes NULL
passingyear_UG varchar(255) Yes NULL
marksobtained_UG varchar(255) Yes NULL
percentage_UG varchar(255) Yes NULL
grade_UG varchar(255) Yes NULL
board_university_PG varchar(255) Yes NULL
passingyear_PG varchar(255) Yes NULL
marksobtained_PG varchar(255) Yes NULL
percentage_PG varchar(255) Yes NULL
grade_PG varchar(255) Yes NULL
board_university_Other1 varchar(255) Yes NULL
passingyear_Other1 varchar(255) Yes NULL
marksobtained_Other1 varchar(255) Yes NULL

Page
32
percentage_Other1 varchar(255) Yes NULL
grade_Other1 varchar(255) Yes NULL
board_university_Other2 varchar(255) Yes NULL
passingyear_Other2 varchar(255) Yes NULL
marksobtained_Other2 varchar(255) Yes NULL
percentage_Other2 varchar(255) Yes NULL
grade_Other2 varchar(255) Yes NULL
permanentaddress text No
permanentPIN varchar(255) No
currentaddress text Yes NULL
currentPIN varchar(255) Yes NULL
emailID varchar(255) No
contactnumber varchar(255) No
currentstate varchar(255) Yes NULL
alternatecontact varchar(255) Yes NULL
passport text No
declaration varchar(255) No
applicantStatus varchar(255) No
subissiondate varchar(255) No

Indexes

Keyname Type Unique Packed Column Cardinality Collation Null Comment

PRIMARY BTREE Yes No applicantID 9 A No
session_id BTREE No No session_id 1 A No

Page
33
courses
Column Type Null Default Comments
courseID (Primary) int(255) No
courseName varchar(255) No
courseProgramme varchar(255) No
courseDescription text No
CourseEligibility text No

Indexes

Keyname Type Unique Packed Column Cardinality Collation Null Comment

PRIMARY BTREE Yes No courseID 3 A No

login
Column Type Null Default Comments
loginID (Primary) int(11) No
username varchar(255) No
pasword varchar(255) No

news
Column Type Null Default Comments
news_id (Primary) int(20) No
news_title varchar(255) No
news_description text No
news_date date No
images text No

Page
34
username varchar(255) No

Indexes

Keyname Type Unique Packed Column Cardinality Collation Null Comment

PRIMARY BTREE Yes No news_id 1 A No

session
Column Type Null Default Comments
session_id (Primary) int(11) No
session_year varchar(255) No
session_status varchar(255) No

student
Column Type Null Default Comments
StudentID (Primary) int(11) No
StudentName varchar(255) No
course varchar(255) No
programme varchar(255) No
gender varchar(255) No
emailID varchar(255) No
contact varchar(255) No
address text No

Page
35
CHAPTER VIII
TESTING

Page
36
TESTING

Testing is the process of executing the programs with the intention of

finding out errors. During testing, the program to be tested is executed with a set of
test cases and the output of the programs for the test case is evaluated to determine
if the program is performing as it is expected to be. As the software is created and
added to the developing system, testing is performed to ensure that it is working
correctly and efficiently. Testing is generally focused on two areas, internal
efficiency and external effectiveness. The goal of external effectiveness testing is
to verify that the software is functioning according to system design, and that it is
performing all the required functions. The goal of internal testing is to make sure
that the computer code is efficient, standardized, and well documented. Testing can
be a labor intensive process due to its iterative nature.

TEST PLAN

A Software project test plan is a document that describes the objectives,

scope, approach and focus of software testing effort. The process of preparing a
test plan is a useful way to think through the efforts needed to validate the
acceptability of a software product. The complement document will help people
outside the test group understand the why and how of product validation. It
should be through enough to be useful but not so through that no one outside the
test group will read it.

These different levels of testing attempt to detect different types of faults.

The relations of faults introduced in different levels of testing are as shown below:

LEVELS OF TESTING

UNIT TESTING

The first level of testing is called unit testing. In this, different modules are
tested against the specifications produced during design for the modules. Unit
testing is essential for verification of the code produced during the coding phase,
and the goal is set to test the internal logic of the modules.

Page
37
 INTEGRATION TESTING The next level of testing is often called the
integration testing. In this many tested modules are combined into subsystems,
which are then tested. The goal here is to see if the modules can be integrated
properly, the emphasis being on testing interfaces between modules. This testing
activity can be considered as testing design and hence the emphasis on testing
interactions.

VALIDATION TESTING

During validation testing, the system is used experimentally to ensure that

the software does not fail, i.e. will run according to its specifications and in the
way users accepts, special test data input for processing, and the results examined.
A limited number of users may be allowed to use the system so analysts can see
whether they try to use it in unforeseen ways. System validation checks the quality
of the software in both simulated and live environments. First the software goes
through a phase in which error and failures based on simulated user requirements
are verified and studied, called alpha testing. The modified software is then
subjected to two phase in the actual users site or a live environment, called beta
testing.

SYSTEM TESTING A series of different tests whose function is to verify that all
system elements have been properly integrated and perform allocated functions.

TESTING OF UNIVERSITY ONLINE ADMISSION SYSTEM

In case of Student data management package, I performed unit testing to

each individual function to see that whether they are working properly or not. We
examined each loop, which occurred in the functions for every possible value.
Integration testing was also being performed by combining the different modules
and the results were examined. Some steps are taken for testing:

Proper validation is done or not.

Exceptions are handled or not.
Correct menus open or not.

Page
38
 Records are properly updated & saved or not.
Is system able to detect Intruder.

Page
39