Sucharitha Project

A MINI-PROJECT REPORT ON
INSURANCE MANAGEMENT SYSTEM

Submitted in partial fulfillment of requirements
for the award of the degree of
MASTER OF COMPUTER APPLICATIONS
Submitted by:
ULLI SUCHARITHA
(22091F0052)
Under the Guidance of

Dr. P. PRATHAP NAIDU M.Tech.,Ph.D.
Associate. Professor in Dept. of CSE
DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS

RAJEEV GANDHI MEMORIAL COLLEGE OF ENGINEERING & TECHNOLOGY
(AUTONOMOUS)
AFFILIATED TO J.N.T UNIVERSITY ANANTAPUR. ACCREDITED BY NBA (TIER-1) &
NAAC OF UGC. NEW DELHI, WITH A+ GRADE
RECOGNIZED UGC-DDU KAUSHAL KENDRA
NANDYAL-518501, (Estd-1995)
YEAR: 2023-2024
Rajeev Gandhi Memorial College of Engineering &Technology
(AUTONOMOUS)
AFFILIATED TO J.N.T UNIVERSITY ANANTAPUR. ACCREDITED BY NBA (TIER-1) &
NAAC OF UGC. NEW DELHI, WITH A+ GRADE
RECOGNIZED UGC-DDU KAUSHAL KENDRA
NANDYAL-518501, (Estd-1995)
(ESTD – 1995)
DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS
CERTIFICATE
This is to certify that ULLI SUCHARITHA (22091F0052), of MCA III- semester, has carried
out the mini-project work entitled “INSURANCE MANAGEMENT SYSTEM” under the
supervision and guidance of Dr.P.PRATHAPNAIDU,Associate.Professor,CSE Department, in
partial fulfillment of the requirements for the award of Degree of Master of Computer
Applications from Rajeev Gandhi Memorial College of Engineering & Technology
(Autonomous), Nandyal is a bonafied record of the work done by her during 2023-2024.
Project Guide Head of the Department
Dr.P.Prathap Naidu M.Tech.,Ph.D. Dr. K. Subba Reddy MTech, Ph.D.
Associate Professor, Professor, Dept. of CSE

Dept. of CSE
Place: Nandyal
Date:
External Examiner
ACKNOWLEDGEMENT
I manifest my heartier thankfulness pertaining to your contentment over my project guide

Dr.P.Prathap Naidu,M.Tech.,Associative.Prof, in Department of CSE with whose adroit
concomitance the excellence has been exemplified in bringing out this project to work with
artistry.
I express my gratitude to Dr. K. Subba Reddy garu, Head of the Department of Computer
Science Engineering & MCA departments, all teaching and non-teaching staff of the Computer
Science Engineering department of Rajeev Gandhi memorial College of Engineering and
Technology for providing continuous encouragement and cooperation at various steps of my
project.
Involuntarily, I am perspicuous to divulge my sincere gratefulness to our Principal, Dr.

T. Jaya Chandra Prasad garu, who has been observed posing virtue in abundance towards my
individuality to acknowledge my project work tangentially.
At the outset I thank to honorable Chairman Dr. M. SanthiRamudu garu, for providing us
with exceptional faculty and moral support throughout the course.
Finally, I extend my sincere thanks to all the Staff Members of MCA & CSE
Departments who have co-operated and encouraged us in making my project successful.
Whatever one does, whatever one achieves, the first credit goes to the Parents be it not for
their love and affection, nothing would have been responsible. I have seen every good that happens
to us their love and blessings.
BY
ULLI SUCHARITHA (22091F0052)
CONTENTS
CHAPTERS PAGE NO
1. INTRODUCTION 1
1.1. About the project 1
1.2. Project description 2
2. LITERATURE REVIEW 4
2.1. Existing System 4
2.2. Proposed System 4
3. SYSTEM ANALYSIS 6
3.1 Software development life cycle (SDLC) 6-9
3.2 Feasibility study 10
3.2.1 Technical Feasibility 10
3.2.2 Economical Feasibility 11
3.2.3 Operational Feasibility 11
3.2.4 Social Feasibility 11
3.3 Requirement Analysis 12
3.3.1 Functional Requirements 12
3.3.2 Non-Functional Requirements 12
3.3.3 User Interfaces 12
3.3.4 Software Interfaces 12
3.3.5 Manpower Requirements 13
3.4 Modules 13
3.4.1 Administration Functions 13
3.4.2 Agent Function 13
3.4.3 Customer Function 14

3.5 System Designing 15
3.5.1 System Design Aspects 15
3.5.2 Design of Database 16
3.5.3 Design of the code 16
3.5.4 Design of input 16
3.5.5 Design of output 17
3.5.6 Design of control 17
3.6 UML Diagrams 17
3.6.1 Class Diagram 18
3.6.2 Use case Diagram 18
3.6.3 Sequence Diagram 21
3.6.4 Activity Diagram 22
3.7 System Requirements 23
3.7.1 Software Requirements 23
3.7.2 Hardware Requirements 23
4. IMPLEMENTATION 24
4.1 Programming Language 24
4.2 What is JDBC 27
4.3 HTML 32
5. TESTING 34
5.1 Software Testing techniques 34
5.1.1 Testing Objectives 34
5.1.2 Test Case Design 34
5.1.2.1 White box Testing 34

5.1.2.2 Black box Testing 34
5.2 Software Testing strategies 35
5.2.1 Unit Testing 35
5.2.2 Integration Testing 35
5.2.3 Validation Testing 36
5.2.3.1 Validation Test Criteria 36
5.2.3.2 Configuration Review 36
5.2.3.3 Alpha and Beta Testing 37
7. FUTURE ENHANCEMENT 38
8.CONCLUSION 39
9. PROJECT SCREENSHOTS 40
10. REFERENCE 48
LIST OF FIGURES
FIG NO. NAME OF THE FIGURE PAGE NO.
Fig: 1 Manual Process 2
Fig: 2 Software development life cycle 6
Fig: 3 Spiral Model 9
Fig: 4 Class Diagram 18
Fig: 5 Use case Diagram for agent 19
Fig: 6 Use case Diagram for policy holder 20
Fig:7 Sequence diagram for administration 21
Fig:8 Sequence diagrams for agent 21
Fig:9 Sequence diagram for customer 22
Fig:10 Activity diagram 23
Fig:11 Java Server Page 26
Fig:12 Servlet 26
Fig:13 JAVA2 Platform,Enterprise Edition Development 30
Fig:14 Life cycle of a SFSB 31

ABSTRACT
Insurance Management system is an intranet based private web application, which is

designed by a group of insurance Agent agents, to make their application work of insurance
policies and claims process easier and flexible. The web-based application is used within
their organization under the distributed accessibility to check the status of the customers who
have taken new policies and their proper track and reminding of policy premium payments
and claim conditions. The system is actually developed to cater to the process speed up in
their Business process such that the customer satisfaction rates increase and the generic flow
of customers into this domain follows a smooth and steady fashion. The major problem under
the manual process is to keep track of the existing insurance policy holders, and remaining
them at regular intervals about their policy premium payments. In order to render the
ordinary services also it takes a great lot of time in just searching through the registers for the
existing customers base. If the process of data storage can be automated and follow up of
search can be increased, there is always a heavy chance of getting extra customers in turn,
which can increase the profits ratio upon the organization.
1. INTRODUCTION
1.1 ABOUT THE PROJECT

Insurance Management system is an intranet based private web application, which is
designed by a group of insurance Agent agents, to make their application work of insurance
policies and claims process easier and flexible. The web based application is used within their
organization under the distributed accessibility to check the status of the customers who have
taken new policies and their proper track and reminding of policy premium payments and
claim conditions. The system is actually developed to cater to the process speed up in their
Business process such that the customer satisfaction rates increase and the generic flow of
customers into this domain follows a smooth and steady fashion. The major problem under
the manual process is to keep track of the existing insurance policy holders, and remaining
them at regular intervals about their policy premium payments. In order to render the
ordinary services also it takes a great lot of time in just searching through the registers for the
existing customers base. If the process of data storage can be automated and follow up of
search can be increased, there is always a heavy chance of getting extra customers in turn,
which can increase the profits ratio upon the organization.
The actual purpose of going for this system is to make the organizational process to
get speed up. The Agents can have the expected information at its desk at any time, with
respect to any instance. Generating required reports as per the operational requirements
becomes much easier and information availability at hand. The system not only becomes
false proof, and higher levels of satisfaction prevail at the side of customer. The application is
also security oriented and gets associated within the system, as the general structure of
accessibility is fastly demandable.
Any registered Agent within the organization can get on to the system to know the
specific information, which he feels that it is requirement with respect to the business policies.
The referential information also gets ported on to the forms, where the search criteria are
greatly reduced.
The total portal has been planned to be associated through the conceptual constant of
the JSP network and databases technologies, the concept handles the late trends that are set
for higher date transfer rates optimized bandwidth utilizations of the network by using the
technologies like JSP the web content is applied through dynamic with oriental usage of JSP
at various stages.
DEPT. OF MCA, RGMCET, NANDYAL PAGE 1

1.2.PROJECT DESCRIPTION
Online Insurance Management is a web application to be developed for insurance
companies to process their entire business activities with insurance agents and customers
through a web portal. The current manually system which described in the given chart
having many drawbacks.
Explains the
Customer policy details
Physically
Waits for response
visits
 Dispatches the
Information
With the
Continues on the one
or two follow-ups
Insurance
company
Registers him with If customer approve to

a insurance policy take a policy
of the customer
choice
Regularly checks Prepare a list of

her ledgers to cross all the customers
check the premium
payment customers
for that month
Details the
information
related to the
Sends the Checks and verifies
 reminders through
port
the portal addresses
Fig.1. manual process

As the above diagrams depict, it is a very tedious process for the Agent to keep track
through the system, related to what is happening and the required information that generically
may be needed at all stages. In the customer base increases the manual search process is too
tedious and time consuming which can frustrate the Agent as well as the customer many
times.
This system can be used by various organizations whether Government or Private
insurance companies.

2.LITERATURE REVIEW
2.1 EXISTED SYSTEM
The Current System is a computerized system but which is maintained at individual

databases. The system doesn’t provide complete online services like online reports, and
centralized database. In the current all the data is maintained mostly manual and in Excel
Sheets. The data security and data accessing is very slow.
2.1.1 Limitations in Existing System
 The current manually system involves lot of expenditure and manpower.
 The data accessing from the database is very slow.
 The current system takes time in retrieving a single record from the database.
2.2 PROPOSED SYSTEM
The proposed system is developing an Internet web based application for Insurance
companies. The entire project will be developed using the concept of distributed client server
computing technologies. The software application has been developed to out as bridge
between the agents and the companies, companies and the customers and the agents and
customers. The normal latency that exists in the system is eliminated and also the job
scheduling standards becomes very faster within the system.
The proposed system gives a fast Internet communication between persons involved.
The system gives a channel to Insurance Company, Insurance Agents and Customers and the
entire process between users will be online.
2.2.1 Features of the proposed system
Maintains and manages the information of all the insurance companies that exists in the
industry.
Maintains and manages the list of agents who are designated upon the system for executing
the business along with applicable avocation of company that belongs to.
Maintains and manages the list of all insurance policies exist in the industry, along with the
association of the company that executes the specific policy.

Maintains and manages the list of all customers who have availed the policies and the
associated nominees and dependents.
Maintains and manages the information of the customers premium payment standards and the
claims if any executed by the policyholders.
Specifically maintains the list of agents, who are associated with policy.
The Agent at any time can view the required information whether it is policies, or customers
at the click of a mouse and instance of a second.
If planned in an organized manner the customers can be provided an online terminal where
they can access the information at their own hands with out the basic intervention manually.
 The customers or policyholder’s reminders can be generated at lightening speed just
by query for the specific customers.
 The information while it is collected can referentially be segregated into their
respective databases from single window, saving the time of multiple data entries.
 The customers policy premium payment status can be viewed in a systematized
manner by the Agents and cross verify the defaulters.
 The claim status raised by a specific policyholder can be tracked very clearly in a
transparent manner, and checked until the claim is settled.
 Above all the overall system can at any time provide consistent and reliable
information authenticated upon its operations.

3.SYSTEM ANALYSIS
System Analysis is first stage according to System Development Life Cycle model.
This system Analysis is a process that starts with the analyst. Analysis is a detailed study of
the various operations performed by a system and their relationships within and outside the
system. One aspect of analysis is defining the boundaries of the system and determining
whether or not a candidate should consider other related systems. During analysis, data is
collected from the available files, decision points, and transactions handled by the present
system. Logical system models and tools are used in analysis. Training, experience, and
common sense are required for collection of the information needed to do the analysis.
3.1. Software Development Life Cycle
Software Development Life Cycle (SDLC) is a process used by the software industry
to design, develop and test high quality software’s. The SDLC aims to produce a high-
quality software that meets or exceeds customer expectations, reaches completion within
times and cost estimates.
What is SDLC?
SDLC is a process followed for a software project, within a software organization. It
consists of a detailed plan describing how to develop, maintain, replace and alter or enhance
specific software. The life cycle defines a methodology for improving the quality of
software and the overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.
Fig 2. software development life cycle

A typical Software Development Life Cycle consists of the following stages:
Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is
performed by the senior members of the team with inputs from the customer, the sales
department, market surveys and domain experts in the industry. This information is then
used to plan the basic project approach and to conduct product feasibility study in the
economical, operationaland technical areas.
Planning for the quality assurance requirements and identification of the risks
associated withthe project is also done in the planning stage. The outcome of the technical
feasibility study is to define the various technical approaches that can be followed to
implement the project successfully with minimum risks.
Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document
the product requirements and get them approved from the customer or the market analysts.
Thisis done through an SRS (Software Requirement Specification) document which consists
of allthe product requirements to be designed and developed during the project life cycle.
Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and documented in a DDS - Design
Document Specification.
This DDS is reviewed by all the important stakeholders and based on various
parameters as risk assessment, product robustness, design modularity, budget and time
constraints, the best design approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along
with its communication and data flow representation with the external and third-party
modules (if any). The internal design of all the modules of the proposed architecture should
be clearly defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is performed in a
detailed and organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers, etc. are used to generate the code.
Different high level programming languages such as C, C++, Pascal, Java and PHP are used
for coding. The programming language is chosen with respect to the type of software being
developed.
Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the
testing activities are mostly involved in all the stages of SDLC. However, this stage refers to
the testing only stage of the product where product defects are reported, tracked, fixed and
retested, until the product reaches the quality standards defined in the SRS.
Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the
appropriate market. Sometimes product deployment happens in stages as per the business
strategy of that organization. The product may first be released in a limited segment and
tested in the real business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the market,
its maintenance is done for the existing customer base.
There are different software development life cycle models to specify and design, which are
followed during the software development phase. These models are also called "Software
Development Process Models". Each process model follows a series of phase unique to its
type to ensure success in the step of software development.
 Waterfall Model
 RAD Model
 Spiral Model
 Incremental Model

 Iterative Model
Among all these models Spiral Model is the one of the best model Spiral Model.
Fig 3: Spiral Model
This SDLC model helps the group to adopt elements of one of more process models
like a waterfall, incremental. The spiral technique is a combination of rapid prototyping and
concurrency in design and development activities. Each cycle in the spiral begins with the
identification of objective for that cycle.Among all the models spiral model is the one of the
best model which provides support for Risk Handling. In its diagrammatic representation, it
looks like a spiral with many loops. The exact number of loops of the spiral is unknown and
can vary from project to project. Each loop of the spiral is called a Phase of the software
development process.
The Spiral Model is a Software Development Life Cycle (SDLC) model that provides
a systematic and iterative approach to software development. It is based on the idea of a spiral,
with each iteration of the spiral representing a complete software development cycle, from
requirements gathering and analysis to design, implementation, testing, and maintenance.
3.2 FEASIBILITY STUDY
All projects are feasible – given unlimited resources and infinite time! Unfortunately,
the development of computer-based system or product is more likely plagued by a scarcity of
resources and difficult delivery dates. It is both necessary and prudent to evaluate the

feasibility of a project at the earliest possible time. Months or years of effort, thousands or
millions of dollars, and untold professional embarrassment can be averted if an ill-conceived
system is recognized early in the definition phase.
Feasibility and risk analysis are related in many ways. If project risk is great the
feasibility of producing quality software is reduced. During product engineering, however,
we concentrate our attention on four primary areas of interest:
All projects are feasible – given unlimited resources and infinite time! Unfortunately,
the development of computer-based system or product is more likely plagued by a scarcity of
resources and difficult delivery dates. It is both necessary and prudent to evaluate the
feasibility of a project at the earliest possible time. Months or years of effort, thousands or
millions of dollars, and untold professional embarrassment can be averted if an ill-conceived
system is recognized early in the definition phase.
Feasibility and risk analysis are related in many ways. If project risk is great the
feasibility of producing quality software is reduced. During product engineering, however, we
concentrate our attention on four primary areas of interest.
3.2.1. TECHNICAL FEASIBILITY:
This application in going to be used in an Internet environment called www (World
Wide Web). So, it is necessary to use a technology that is capable of providing the networking
facility to the application. This application as also able to work on distributed environment.
Application on developed with J2EE (Java 2 Enterprise Edition platform) Technology. One
major advantage in application is platform neutral. We can deploy and used it in any
operating system.
GUI is developed using HTML.to capture the information from the customer. HTML
is used to display the content on the browser. It uses TCP/IP protocol. It is an interpreted
language. It is very easy to develop a page/document using HTML some RAD(Rapid
Application Development) tools are provided to quickly design/develop our application. So
many objects such as button, text fields, and text area etc are provide to capture the
information from the customer.
We can use this application in any OS. They can have their own security and
transactional advantages. But are the responsible for selecting suitable and secured OS, which
is suitable to our application.

The back-end Oracle 8i and front-end application are platform independent. So we can
port this enterprise application in any environment. Both are having their individual
configuration to get better performance and backup issues.
3.2.2 ECONOMICAL FEASIBILITY

In present system dealer need to go to bsnl office to purchases stock or to monitor
stock and view reports of his account. So he/she needs to spend some time to complete this
protocol. It is time consuming process some times customer not able to spend that much of
time.
Maintains of information manually requires number of staff members which increases
the expenditure and if an electronic system is introduced the total information can be
maintained by a single person. When we compare with manually process the electronic
process economical less.
3.2.3 OPERATIONAL FEASIBILITY
In our application front end is developed using GUI. So it is very easy to the customer
to enter the necessary information. But customer has some knowledge on using web
applications before going to use our application.
3.2.4 SOCIAL FEASIBILITY
It is a determination of whether the people will accept a proposed project or not.
3.3 REQUIREMENT ANALYSIS

Requirements analysis is the process of defining out and what the user requires from
the system and defining the requirements clearly and in an unambiguous state. The outcome
of the requirement analysis is the software developing activities. Thus it deals with
understanding the problem goals and constrains. This specification part mainly focuses on
what had been found during analysis.A requirement is a relatively short and concise piece of
information, expressed as a fact. It can be written as a sentence or can be expressed using
some kind of diagram.
Requirements are divided into two major types functional and non-functional.
3.3.1 FUNCTIONAL REQUIREMENTS
Functional requirements describe what the system should do. The functional
requirements can be further categorized as follows:
 What inputs the system should accept.

 What outputs the system should produce.

 What data the system must store.
 What are the computations to be done?
 The timing and synchronization of above.
3.3.2 NON-FUNCTIONAL REQUIREMENTS
Non-functional requirements are the constraints that must be adhered during
development. They limit what resources can be used and set bounds on aspects of the
software’s quality.
3.3.3 USER INTERFACES
The User Interface is a GUI developed using HTML
3.3.4 SOFTWARE INTERFACE:
The main processing is done on the server side using apache tomcat and the
programming environment java is used, for backend database oracle.
3.3.5. MANPOWER REQUIREMENTS

5 members can complete this in 2 – 4 months if they work fulltime on it.
3.4. MODULES OF THE PROJECT
The major function that product executes are divided into three categories.
 Administrative Functions.
 Agents Functions
 Policy Holder Functions
3.4.1. ADMINISTRATOR FUNCTIONS
The functions take care of the actual date interpretation standards at the level of the
administrative officer area. All these transactions that need consistency function the system
existence. All the master table transaction with respect to then data insertion, deletion and
updations are totally managed by the system administrators. The generic information
maintained by the administrations is:
 Companies information management
 Agents information management
 Customer information management
 Policies information management

 Policy payment module

 Policy payment’s information management
 Security information management
 A Mail communication between Agents and Customers
3.4.2. AGENT FUNCTIONS
The general functions that are taken care of at the user level are the agent can process
business transaction at any time. The system helps the Agents to just view the standardized
information of the customer with whom he has established business policies etc.
 View Companies information
 View list of new policies and their details
 Process take of policies for customers online
 Claim for policy through online
 Checkout the details whether claim is approved or rejected.
 View Agents information
 View Commission Reports
 View Customer policies information
 View Policy payment Details
 A Mail communication between Administrator and Customers
3.4.3. CUSTOMER FUNCTIONS
The general functions that are taken care of at the user level are the customer can view
their respective policy information at any time. The customers can also view their premium
payment standards and the claims duration strategy.
 View Companies information
 View list of new policies and their details
 View Agents information
 View Installments Details
 View Premium Details
 View Customers Details
 Claim for policy
 Checkout the details whether claim is approved or rejected.

 View Customer policies information

 View Policy payment Details
 A Mail communication between Agents and Customers
The above functionalities are detailed expressed below:
1. Insurance companies master: This database maintains the list of all unique
insurance companies that participate under the business.
2. Agent Master: This database maintains the list of all the Agents, which are registered
with the company. Each Agent uniquely identified within the system.
3. Customer master: This database gives the information of all the customers who are
coming upon the system for the executing the standards of the insurance policies.
4. Customer dependent master: This database maintains the information related to the
dependent the customer provides.
5. Policies master: This database maintains all the unique policies that are raised by the
companies as the part of the insurance business.
6. Customer policies master: This database provides the information related to which
customer has adopted which policy through association of which Agent.
7. Nominees’ details master: The database provides the information related to the legal
heirs that are represented by the customers.
8. Policy payments master: The database provides the information related to all
premium payments that are executed by the customers.
9. Policy claim master: This database maintains the information that is raised by the
policy, holders for claim of their policy as soon as the policy is matured.
10. Claim status code: This database specifically states what are the different statuses
that a policy can have while it is under operation.
11. Agent security master: The database maintains the status give information of the
Agent login standards.
12. Customer security master: The database maintains the information related to the
customer login standards.

3.5. SYSTEM DESIGNING

3.5.1. SYSTEM DESIGN ASPECTS
Once the analysis stage is completed, the next stage is to determine in broad outline
form how the problem might be solved. During system design , we are beginning to move
from the logical to physical level.
System design involves architectural and detailed design of the system. Architectural
design involves identifying software components, decomposing them into processing
modules and conceptual data structures, and specifying the interconnections among
components.
Detailed design is concerned with how to package processing modules and how to
implement the processing algorithms, data structures and interconnections of standard
algorithms, invention of new algorithms, design of data representations and packaging of
software products. Two kinds of approaches are available:
1. Top down approach
2. Bottom up aaproach
3.5.2. DESIGN OF DATABASE
The design of database includes decision about the nature and content of the table,
such as whether they are to be used for storing current information details, reference
information of historical data.
Database design involves the following decisions
Which data entity to include in table and which entity to be the key. Characteristics of
each entity such as name, data type and length. Relationships between the data entities of
different tables and databases. Normalization techniques to be adopted in designing the
database. The Data Flow Diagrams have been drawn and analyzed and the relationships
between the entities have been identified. The objective in the development of database
technology has been to treat data as an organizational resource and as an integrated whole.
Database is an integrated collection of data. The database for the “eLearn and Earn”
consists of data, which are organized with an aim to achieve three major objectives – Data
integrity, Data consistency and data independence.
3.5.3. DESIGN OF CODE
Since information systems projects are designed with space, time and cost saving in
mind, coding methods in which conditions, words, ideas or control errors and speed the entire
process. The purpose of the code is to facilitate the identification and retrieval of the

information. A code is an ordered collection of symbols designed to provide unique

identification of an entity or an attribute.
3.5.4. DESIGN OF INPUT
 Design of input involves the following decisions economical feasibility.
 Input data.
 Input medium
 The way data should be arranged or coded.
 Validation needed to detect every step to follow when error occurs.
E-learn and Earn input controls provide ways to ensure that only authorized users
access the system guarantee the valid transactions, validate the data for accuracy and
determine whether any necessary data has been omitted. The primary input medium chosen is
display. Screens have been developed for input of data using HTML. The validations for all –
important inputs are taken care of through various events using JSP controls.
3.5.5. DESIGN OF OUTPUT
Design of output involves the following decisions
 Information to present
 Output medium
 Output layout
Output of this system is given in easily understandable, user-friendly manner, Layout of the
output is decided through the discussions with the different users.
3.5.6. DESIGN OF CONTROL
The system should offer the means of detecting and handling errors.
Input controls provides ways to
 Valid transactions are only acceptable.
 Validates the accuracy of data.
 Ensures that all mandatory data have been captured.
All entities to the system will be validated. And updating of tables is allowed for only
valid entries. Means have been provided to correct, if any by change incorrect entries have
been entered into the system, they can be edited.
3.6 UML diagram
Why we have to use UML in projects?
As the strategic value of software increases for many companies, the industry looks
for techniques to automate the production of software and to improve quality and reduce cost

and time-to-market. These techniques include component technology, visual programming,

patterns and frameworks.
Businesses also seek techniques to manage the complexity of systems as they increase in
scope and scale. In particular, they recognize the need to solve recurring architectural
problems, such as physical distribution, concurrency, replication, security, load balancing and
fault tolerance.
The Unified Modeling Language (UML) was designed to respond to these needs. Simply,
Systems design refers to the process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements which can be done easily
through UML diagrams.
In the project four basic UML diagrams have been explained among the following list:
 Class Diagram
 Use Case Diagram
 Sequence Diagram
 Activity Diagram
3.6.1 Class diagram
 In software engineering, a class diagram in the Unified Modeling Language (UML) is
a type of static structure diagram that describes the structure of a system by showing
the system's classes, their attributes, and the relationships between the classes.
 This is one of the most important of the diagrams in development. The diagram
breaks the class into three layers.
 The relationships are drawn between the classes. Developers use the Class Diagram to
develop the classes. Analyses use it to show the details of the system.

Fig 4: Class Diagram
3.6.2 Use case Model

 In software engineering, a use case diagram in the Unified Modelling Language
(UML) is a type of behavioral diagram defined by and created from a Use-case
analysis. Its purpose is to present a graphical overview of the functionality provided
by a system in terms of actors, their goals (represented as use cases), and any
dependencies between those use cases.
 The main purpose of a use case diagram is to show what system functions are
performed for which actor. Roles of the actors in the system can be depicted. Use
cases are used during requirements elicitation and analysis to represent the
functionality of the system. Use cases focus on the behavior of the system from the
external point of view.The actors who have been recognized within the system are
Agent
This actor acts as a bridge between the companies’ policies and the policyholders who have
taken the policies.

Login
Companies’
information
Policies
Information
Agent
Customer
policies
Policy types
information
Fig.5.Usecase diagram for agent

Policy Holder
This actor is the outer who insures himself or any item with a specific policy. He goes
for policy premium payments and policy claims from time to time.

Login
Policies
information
Policies
Registration
Policy Holder
Nominees
information
Policy payments
Policy claims
Fig.6.Usecase diagram for policy holder

3.6.3 Sequence Diagram:
Fig.7.Sequence diagram for administrator
Fig.8.Sequence diagram for agents

Fig.9.Sequence diagram for customer

3.6.4. Activity Diagram
Activity diagrams are a loosely defined diagram technique for showing workflows of
stepwise activities and actions, with support for choice, iteration and concurrency. In the
Unified Modelling Language, activity diagrams can be used to describe the business and
operational step-by-step workflows of components in a system. An activity diagram shows
the overall flow of control.

Fig.10.Activity diagram
3.7. SYSTEM REQUIRMENTS
The project is web-based application. When we talk about hardware and software, we have
to mention requirements on both the Client and Server part.
3.7.1. HARDWARE SPECIFICATIONS
Processor : Intel Pentium IV Processor or more, IBM Cyri
(Intel compatible)
Hard Disk : 80 GB hard disk recommended for Primary partition.
RAM : Minimum 1 GB ram recommended for data processing.
3.7.2. SOFTWARE SPECIFICATIONS

Operating System : Microsoft Windows 98/2000/XP
Front End : HTML, DHTML,JSP
Back End : Oracle
Web server : Apache Tomcat
Web browsers : Netscape Navigator Or Internet Explorer
Scripting language : Java Script
Database drivers : Jdbc-Odbc Driver, Microsoft Odbc Oracle Driver

4.IMPLEMENTATION
4.1 Programming Language
Java Technology
The Internet helped catapult Java to the forefront of programming and Java in turn has
had a profound effect on the Internet. The reason is simple: Java expands the universe of
objects that can move about freely in cyberspace. In a network, there are two broad categories
of objects transmitted between the Server and your Personal Computer: passive information
and dynamic, active programs like an object that can be transmitted to your computer, which
is a dynamic, self-executing program. Such a program would be an active agent ton the client
computer, yet the server would initiate it. As desirable as dynamic, networked programs are,
they also present serious problems in the areas of security and portability. Prior to Java
cyberspace was effectively closed to half the entities that now live there. Java addresses these
concerns and doing so, has opened the door to an exiting a new form of program.
The rise of server-side Java applications is one of the latest and most exciting trends
in Java programming. It was first hyped as a language for developing elaborate client-side
web content in the form of applets. Now, Java is coming into its own as a language ideally
suited for server-side development. Businesses in particular have been quick to recognize
Java’s potential on the server-Java is inherently suited for large client/server applications.
The cross platform nature of Java is extremely useful for organizations that have a
heterogeneous collection of servers running various flavors of the Unix of Windows
operating systems. Java’s modern, object-oriented, memory-protected design allows
developers to cut development cycles and increase reliability. In addition, Java’s built-in
support for networking and enterprise API provides access to legacy data, easing the
transition from older client/server systems.
Java Servlets are a key component of server-side java development. A Servlets is a
small, plug gable extension to a server that enhances the server’s functionality. Servlets allow
developers to extend and customize and Java enabled server a web server, a mail server, an
application server, or any custom server with a hitherto unknown degree of portability,
flexibility and ease.

JAVA SERVER PAGE (JSP):

Java Server Pages is a simple, yet powerful technology for creating and maintaining
dynamic-content web pages. Based on the Java programming language, Java Server Pages
offers proven portability, open standards, and a mature re-usable component model.
PORTABILITY:
Java Server Pages files can be run on any web server or web-enabled application
server that provides support for them. Dubbed the JSP engine, this support involves
recognition, translation and management of the Java Server Pages lifecycle and its interaction
with associated components.
The JSP engine for a particular server might be built-in or might be provided through
a 3rd –party add-on. As long as the server on which you plan to execute the Java Server Pages
supports the same specification level as that to which the file was written, no change should
be necessary as you move your files from server to server. Note, however, that instructions
for the setup and configuration of the files may differ between files.
COMPOSITION:
It was mentioned earlier that the Java Server Pages architecture could include
reusable Java components. The architecture also allows for the embedding of a scripting
language directly into the Java Server Pages file. The components current supported include
Java Beans and Serves. As the default scripting language, Java Server Pages use the Java
Programming language. This means that scripting on the server side can take advantage of
the full set of capabilities that the Java programming language offers.
PROCESSING:
A Java Server Pages file is essentially an HTML document with JSP scripting or tags.
It may have associated components in the form of class, .jar, or .ser files- -or it may not. The
use of components is not required.
The Java Server Pages file has a .jsp extension to identify it to the server as a Java
Server Pages file. Before the page is served, the Java Server Pages syntax is parsed and
processed into a servlet on the server side. The servlet that is generated, outputs real content
in straight HTML for responding to the customer. Because it is standard HTML, the
dynamically generated response looks no different to the customer browser than a static
response.

ACCESS MODELS:
A Java Server Pages file may be accessed in at least two different ways: A client
request comes directly into a Java Server Page.
Fig.11.java server page
In this scenario, suppose the page accessed reusable Java Bean components that perform
particular well-defined computations like accessing a database. The result of the Bean’s
computations, called result sets is stored within the Bean as properties. The page uses such
Beans to generate dynamic content and present it back to the client. A request comes through
a Servlets.
Fig.12.servlet
The servlet generates the dynamic content. To handle the response to the client, the
servlet creates a Bean and stores the dynamic content (sometimes called the result set) in the

Bean. The servlet then invokes a Java Server Page that will present the content along with the
Bean containing the generated from the servlet.
There are two APIs to support this model of request processing using Java Server
Pages. One API facilitates passing context between the invoking servlet and the Java Server
Page. The other API lets the invoking servlet specify which Java Server Page to use.
In both of the above cases, the page could also contain any valid Java code. The Java
Server Pages architecture separation of content from presentation- -it does not mandate it.
JDBC requires that the SQL statements be passed as Strings to Java methods. For
example, our application might present a menu of database tasks from which to choose. After
a task is selected, the application presents prompts and blanks for filling information needed
to carry out the selected task. With the requested input typed in, the application then
automatically invokes the necessary commands.
In this project we have implemented three-tier model, commands are sent to a
“middle tier” of services, which then send SQL statements to the database. The database
process the SQL statements and sends the results back to the middle tier, which then sends
them to the user. JDBC is important to allow database access from a Java middle tier.
4.2 What Is JDBCTM?
JDBCTM is a JavaTM API for executing SQL statements. (As a point of interest, JDBC
is a trademarked name and is not an acronym; nevertheless, JDBC is often thought of as
standing for "Java Database Connectivity".) It consists of a set of classes and interfaces
written in the Java programming language. JDBC provides a standard API for tool/database
developers and makes it possible to write database applications using a pure Java API.
Using JDBC, it is easy to send SQL statements to virtually any relational database. In
other words, with the JDBC API, it isn't necessary to write one program to access a Sybase
database, another program to access an Oracle database, another program to access an
Informix database, and so on. One can write a single program using the JDBC API, and the
program will be able to send SQL statements to the appropriate database. And, with an
application written in the Java programming language, one also doesn't have to worry about
writing different applications to run on different platforms. The combination of Java and
JDBC lets a programmer write it once and run it anywhere.
Java being robust, secure, easy to use, easy to understand, and automatically
downloadable on a network, is an excellent language basis for database applications. What is

needed is a way for Java applications to talk to a variety of different databases. JDBC is the
mechanism for doing this.
JDBC extends what can be done in Java. For example, with Java and the JDBC API,
it is possible to publish a web page containing an applet that uses information obtained from a
remote database. Or an enterprise can use JDBC to connect all its employees (even if they are
using a conglomeration of Windows, Macintosh, and UNIX machines) to one or more
internal databases via an intranet. With more and more programmers using the Java
programming language, the need for easy database access from Java is continuing to grow.
MIS managers like the combination of Java and JDBC because it makes
disseminating information easy and economical. Businesses can continue to use their
installed databases and access information easily even if it is stored on different database
management systems. Development time for new applications is short. Installation and
version control are greatly simplified. A programmer can write an application or an update
once, put it on the server, and everybody has access to the latest version. And for businesses
selling information services, Java and JDBC offer a better way of getting out information
updates to external customers.
CONNECTION:
A connection object represents a connection with a database. A connection session
includes the SQL statements that are executed and the results that are returned over the
connection. A single application can have one or more connections with a single database, or
it can have connections with many different databases.
OPENING A CONNECTION:
The standard way to establish a connection with a database is to call the method
DriverManager.getConnection. This method takes a string containing a URL. The Driver
Manager class, referred to a the JDBC management layer, attempts to locate a driver than can
connect to the database represented Driver classes, and when the method get Connection is
called, it checks with each driver in the list until it finds one that can connect uses this URL to
actually establish the connection.
<Sub protocol>-usually the driver or the database connectivity mechanism, which may be
supported by one or more drivers. A prominent example of a sub protocol name is “oracle”,
which has been reserved for URLs that specify “thin”-style data source names.

<Sub name>- a way to identify the database.

The sub names can vary, depending on the sub protocol, and it can have a sub name
with any internal syntax the driver writer chooses. The point of a sub name is to give enough
information to locate the database.
SENDING STATEMENT:
Once a connection is established, it is used to pass SQL statements to its underlying
database. JDBC does not put any restrictions on the kinds of SQL statements that can be sent;
this provides a great deal of flexibility, allowing the use of database-specific statements or
even non-SQL statements. It requires, however, that the user be responsible for making sure
that the underlying database can process the SQL statements being sent and suffer the
consequences if it cannot.
DRIVER MANAGER:
The Driver Manager class is the management layer of JDBC, working between the
user and the drivers. It keeps track of the drivers that are available and handles establishing a
connection between a database and the appropriate driver. It addition, the driver manager
class attends to things like driver login time limits and the printing of log and tracing
messages. The only method in this class that a general programmer needs to use directly is
DriverManager.getConnection. As its name implies, this method establishes a connection to a
database.

Fig.13: A JAVA2 Platform, Enterprise Edition Deployment

Fig 14: Life cycle of a SFSB

4.3 HTML:
Hypertext Markup Language (HTML), the languages of the World Wide Web
(WWW), allows users to produces Web pages that include text, graphics and pointer to other
Web pages (Hyperlinks).
HTML is not a programming language but it is an application of ISO Standard 8879,
SGML (Standard Generalized Markup Language), but specialized to hypertext and adapted to
the Web. The idea behind Hypertext is that instead of reading text in rigid linear structure, we
can easily jump from one point to another point. We can navigate through the information
based on our interest and preference. A markup language is simply a series of elements, each
delimited with special characters, that define how text or other items enclosed within the
elements should be displayed. Hyperlinks are underlined or emphasized works that load to
other documents or some portions of the same document.
HTML can be used to display any type of document on the host computer, which can
be geographically at a different location. It is a versatile language and can be used on any
platform or desktop.
HTML provides tags (special codes) to make the document look attractive. HTML
tags are not case-sensitive. Using graphics, fonts, different sizes, color, etc., can enhance the
presentation of the document. Anything that is not a tag is part of the document itself.
Basic HTML Tags :
 Specifies comments
<A>……….</A> Creates hypertext links
<B>……….</B> Formats text as bold
<BIG>……….</BIG> Formats text in large font.
<BODY>…</BODY> Contains all tags and text in the HTML document
<CENTER>...</CENTER> Creates text
<DD>…</DD> Definition of a term
<DL>...</DL> Creates definition list
<FONT>…</FONT> Formats text with a particular font
<FORM>...</FORM> Encloses a fill-out form
<FRAME>...</FRAME> Defines a particular frame in a set of frames
<H#>…</H#> Creates headings of different levels
<HEAD>...</HEAD> Contains tags that specify information about a document
<HR>...</HR> Creates a horizontal rule

<HTML>…</HTML> Contains all other HTML tags

<META>...</META> Provides meta-information about a document
<SCRIPT>…</SCRIPT> Contains client-side or server-side script
<TABLE>…</TABLE> Creates a table
<TD>…</TD> Indicates table data in a table
<TR>…</TR> Designates a table row
<TH>…</TH> Creates a heading in a table
ADVANTAGES
 A HTML document is small and hence easy to send over the net. It is small because it does
not include formatted information.
 HTML is platform independent.

 HTML tags are not case-sensitive.

5.TESTING
5.1 SOFTWARE TESTING TECHNIQUES:
Software testing is a critical element of software quality assurance and represents the
ultimate review of specification, designing and coding.
5.1.1 TESTING OBJECTIVES:
1. Testing is process of executing a program with the intent of finding an error.
2. A good test case design is one that has a probability of finding an as yet undiscovered
error.
3. A successful test is one that uncovers an as yet undiscovered error.
5.1.2 TEST CASE DESIGN:
Any engineering product can be tested in one of two ways:
5.1.2.1. White Box Testing:
This testing is also called as glass box testing. In this testing, by knowing the specified
function that a product has been designed to perform test can be conducted that demonstrates
each function is fully operation at the same time searching for errors in each function. It is a
test case design method that uses the control structure of the procedural design to derive test
cases. Basis path testing is a white box testing.
Basis Path Testing:
 Flow graph notation
 Cyclomatic Complexity
 Deriving test cases
 Graph matrices
Control Structure Testing:
 Condition testing
 Data flow testing
 Loop testing
5.1.2.2 Black Box Testing:
In this testing by knowing the internal operation of a product, tests can be
conducted to ensure that “ all gears mesh”, that is the internal operation performs
according to specification and all internal components have been adequately exercised.
It fundamentally focuses on the functional requirements of the software.
The steps involved in black box test case design are:

 Graph based testing methods

 Equivalence partitioning
 Boundary value analysis
 Comparison testing
5.2 SOFTWARE TESTING STRATEGIES:
A software testing strategy provides a road map for the software developer. Testing is a
set of activities that can be planned in advance and conducted systematically. For this reason
a template for software testing a set of steps into which we can place specific test case design
methods should be defined for software engineering process. Any software testing strategy
should have the following characteristics:
1. Testing begins at the module level and works “outward” toward the integration of the
entire computer based system.
2. Different testing techniques are appropriate at different points in time.
3. The developer of the software and an independent test group conducts testing.
4. Testing and Debugging are different activities but debugging must be accommodated
in any testing strategy.
5.2.1 Unit Testing:
Unit testing focuses verification efforts in smallest unit of software design (module).
1. Unit test considerations
2. Unit test procedures
5.2.2 Integration Testing:

Integration testing is a systematic technique for constructing the program structure
while conducting tests to uncover errors associated with interfacing. There are two types of
integration testing:
1. Top-Down Integration: Top down integration is an incremental approach to construction
of program structures. Modules are integrated by moving down wards throw the control
hierarchy beginning with the main control module.
2. Bottom-Up Integration: Bottom up integration as its name implies, begins construction
and testing with automatic modules.
3. Regression Testing: In this contest of an integration test strategy, regression testing is the
re execution of some subset of test that have already been conducted to ensure that
changes have not propagate unintended side effects.
5.2.3 Validation Testing:
At the culmination of integration testing, software is completely assembled as a

package; interfacing errors have been uncovered and corrected, and a final series of software
tests – validation testing may begin. Validation can be fined in many ways, but a simple
definition is that validation succeeds when software functions in a manner that can be
reasonably expected by the customer.
Reasonable expectation is defined in the software requirement specification – a
document that describes all user-visible attributes of the software. The specification contains
a section titled “Validation Criteria”. Information contained in that section forms the basis for
a validation testing approach.
5.2.3.1 Validation Test Criteria:
Software validation is achieved through a series of black-box tests that demonstrate
conformity with requirement. A test plan outlines the classes of tests to be conducted, and a
test procedure defines specific test cases that will be used in an attempt to uncover errors in
conformity with requirements. Both the plan and procedure are designed to ensure that all
functional requirements are satisfied; all performance requirements are achieved;
documentation is correct and human-engineered; and other requirements are met.
After each validation test case has been conducted, one of two possible conditions
exists: (1) The function or performance characteristics conform to specification and are
accepted, or (2) a deviation from specification is uncovered and a deficiency list is created.
Deviation or error discovered at this stage in a project can rarely be corrected prior to
scheduled completion. It is often necessary to negotiate with the customer to establish a
method for resolving deficiencies.
5.2.3.2 Configuration Review:
An important element of the validation process is a configuration review. The intent
of the review is to ensure that all elements of the software configuration have been properly
developed, are catalogued, and have the necessary detail to support the maintenance phase of
the software life cycle. The configuration review sometimes called an audit.

5.2.3.3 Alpha and Beta Testing:

It is virtually impossible for a software developer to foresee how the customer will
really use a program. Instructions for use may be misinterpreted; strange combination of data
may be regularly used; and output that seemed clear to the tester may be unintelligible to a
user in the field.
When custom software is built for one customer, a series of acceptance tests are
conducted to enable the customer to validate all requirements. Conducted by the end user
rather than the system developer, an acceptance test can range from an informal “test drive”
to a planned and systematically executed series of tests. In fact, acceptance testing can be
conducted over a period of weeks or months, thereby uncovering cumulative errors that might
degrade the system over time.
If software is developed as a product to be used by many customers, it is impractical
to perform formal acceptance tests with each one. Most software product builders use a
process called alpha and beta testing to uncover errors that only the end user seems able to
find.
The beta test is conducted at one or more customer sites by the end user of the
software. Unlike alpha testing, the developer is generally not present. Therefore, the beta test
is a “live” application of the software in an environment that cannot be controlled by the
developer. The customer records all problems that are encountered during beta testing and
reports these to the developer at regular intervals. As a result of problems reported during
bets test, the software developer makes modification and then prepares for release of the
software product to the entire customer base.

7. FUTURE ENHANCEMENT
Insurers will engage in more process automation across marketing, distribution,

underwriting, claiming, and policy servicing. Leading insurers will use automation and
empathy during the next decade to reach outcomes such as driving revenues and policies in
force, optimizing expenses, and minimizing risks.
In order to understand the fundamental challenges of the modern competitive
environment, it is necessary to make the distinction between multinational and global
competition.

8. CONCLUSION
We have successfully designed the system which is capable of taking Insurance

management The project is very much useful for Insurance companies to maintain their
policy details and activities of the company.
It should helpful for the agents and customers to look over their policy details, commision
reports etc.

APPENDIX-A: PROJECT SCREENSHOTS
SCREEN 1: HOME PAGE

SCREEN 2: ADMIN MODULE

SCREEN 3: COMPANY REGISTRATION

SCREEN 4: COMPANY INFORMATION REPORT

SCREEN 5: AGENT DETAILS ADDITION FORM

SCREEN 6: CUSTOMER DETAILS ADDITION FORM

SCREEN 7: POLICY PAYMENT DETAILS

SCREEN 8: AGENT INBOX

9.REFERENCES
1. Roger S Pressman, “Software Engineering – A Practitioner’s approach” McGraw

– Hill International Editions, Fifth Edition, 2001.
2. Henry F Korth, S. Sudharshan, “Database System Concepts” McGraw – Hill
International Editions, Fourth Edition, 2002.
3. George Koch, Kevin Loney, “Oracle – The Complete Reference”, Tata McGraw
Hill, Third Edition, 2001.
4. Herbert Schildt & Patrick Naughton, “Java2 Complete Reference”, Tmh 3/e, 1998.
5. James Jawroski, “Mastering Java Script”, Tmh 3/e, 2000.
WEB SITES REFERRED:
www.java2s.com
www.javacode.com
www.jsptut.com
www.htmlref.com

Sucharitha Project

Uploaded by

Copyright:

Available Formats

Sucharitha Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sucharitha Project

Uploaded by

Copyright:

Available Formats

A MINI-PROJECT REPORT ON

INSURANCE MANAGEMENT SYSTEM

MASTER OF COMPUTER APPLICATIONS

Under the Guidance of

DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS

DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS

Project Guide Head of the Department

Dr.P.Prathap Naidu M.Tech.,Ph.D. Dr. K. Subba Reddy MTech, Ph.D.

Associate Professor, Professor, Dept. of CSE

I manifest my heartier thankfulness pertaining to your contentment over my project guide

Involuntarily, I am perspicuous to divulge my sincere gratefulness to our Principal, Dr.

1.1. About the project 1

1.2. Project description 2

2.1. Existing System 4

2.2. Proposed System 4

3.1 Software development life cycle (SDLC) 6-9

3.2 Feasibility study 10

3.2.1 Technical Feasibility 10

3.2.2 Economical Feasibility 11

3.2.3 Operational Feasibility 11

3.2.4 Social Feasibility 11

3.3 Requirement Analysis 12

3.3.1 Functional Requirements 12

3.3.2 Non-Functional Requirements 12

3.3.3 User Interfaces 12

3.3.4 Software Interfaces 12

3.3.5 Manpower Requirements 13

3.4.1 Administration Functions 13

3.4.2 Agent Function 13

3.4.3 Customer Function 14

3.5.1 System Design Aspects 15

3.5.2 Design of Database 16

3.5.3 Design of the code 16

3.5.4 Design of input 16

3.5.5 Design of output 17

3.5.6 Design of control 17

3.6 UML Diagrams 17

3.6.1 Class Diagram 18

3.6.2 Use case Diagram 18

3.6.3 Sequence Diagram 21

3.6.4 Activity Diagram 22

3.7 System Requirements 23

3.7.1 Software Requirements 23

3.7.2 Hardware Requirements 23

4.1 Programming Language 24

4.2 What is JDBC 27

5.1 Software Testing techniques 34

5.1.1 Testing Objectives 34

5.1.2 Test Case Design 34

5.1.2.1 White box Testing 34

5.2 Software Testing strategies 35

5.2.1 Unit Testing 35

5.2.2 Integration Testing 35

5.2.3 Validation Testing 36

5.2.3.1 Validation Test Criteria 36

5.2.3.2 Configuration Review 36

5.2.3.3 Alpha and Beta Testing 37

FIG NO. NAME OF THE FIGURE PAGE NO.

Fig: 1 Manual Process 2