Online Complaint Management System

(1)

2.3 Module Description 2.3 Module Description 04 04 2.4 Reports 2.4 Reports 05 05 3

3 REVIEW REVIEW OF OF THE THE STATE STATE OF OF ARTART 07

07

3.1

3.1 Feasibility StudyFeasibility Study 07

07

3.1.1 Economical

3.1.1 Economical FeasibiliFeasibilityty 07

07 3.1.2

3.1.2 Operational FeasibilityOperational Feasibility 07

07 3.1.3

3.1.3 Technical FeasibilityTechnical Feasibility 07

07

3.2

3.2 Software Requirements SpecificationsSoftware Requirements Specifications 08

08 3.3

3.3 Nonfunctional RequirementsNonfunctional Requirements 09

09 3.4

3.4 System Process ModelSystem Process Model 10

10

4

4 SYSTEM DESIGNSYSTEM DESIGN 18 18 4.1 ER Diagram 4.1 ER Diagram 18 18

(2)

4.2 Data Dictionary 4.2 Data Dictionary

18 18

4.3 Data Flow Diagrams 4.3 Data Flow Diagrams

20 20

4.4 Unified Modeling Language 4.4 Unified Modeling Language 21

21

4.4.1 Use Case D

4.4.1 Use Case Diagramiagram 23 23 4.4.2 Activity Diagram 4.4.2 Activity Diagram 26 26 4.4.3 Collaboration Diagram 4.4.3 Collaboration Diagram 27

27 4.4.4 4.4.4 Class Class DiagramDiagram 29 29 4.4.5 Sequence Diagram 4.4.5 Sequence Diagram 30 30 5 5 IMPLEMENTATIONIMPLEMENTATION 32 32 5.1 Coding 5.1 Coding 32 32 6

6 SYSTEM TESTINGSYSTEM TESTING 39 39 6.1 Testing 6.1 Testing 39 39 6.2 Testing Strategy 6.2 Testing Strategy 39 39 6.3 Test Approach 6.3 Test Approach 43 43 6.4 Test Cases 6.4 Test Cases 44 44

(3)

7

7 SCREEN SCREEN SHOTSSHOTS 47 47 7.1 Screens 7.1 Screens 47 47 8 8 CONCLUSIONCONCLUSION 57 57 8.1 Summary 8.1 Summary 57 57 8.2 Future enhancements 8.2 Future enhancements 58 58 REFERENCES REFERENCES 59 59

LIST OF ACRONYMS

S

S NO

NO

Acronym

Description

Page No

1

1 SRS SRS SoftwareSoftware Requirement

Requirement Specification Specification 0808

2

2 DFD DFD Data Data FlowFlow

Diagram 19

3

3 UML UML UnifiedUnified

Modeling

(4)

LIST OF FIGURES AND TABLES

LIST OF FIGURES

S

S NO

NO

Figure

Figure No

No

Figure Name

Figure

Name

Page No

1

3.1

3.1 Spiral

Spiral Model

Model

10

2

3.2

2

3.2

Designing Stage DDesigning Stage D iagramiagram

12

3

3.3

3

3.3

Development Development StageStage Diagram

Diagram

13

4

3.4

4

3.4

Integration StageIntegration Stage 14

14 5

5 3.5 3.5 InstallInstallation ation & & AcceptanceAcceptance 15 15 6 6 4.1 4.1 ER ER DiagramDiagram 17 17 7

7 4.2 4.2 Use Use Case Case DiagramDiagram 23

23

8

8 4.3 4.3 ActiviActivity ty DiagramDiagram 25

25

9

9 4.4 4.4 Class Class DiagraDiagramm 28

28

LIST OF TABLES

S

S NO

NO

Table

Table Number

Number

Table

Table Name

Name

Page No

1

4.1 4.1 Product Product InformatiInformationon 19

(5)

2

2 4.2 4.2 Complaint Complaint DetailsDetails 19

19

ABSRACT

Customers may have complaints about its products. They will be given an product Customers may have complaints about its products. They will be given an product id for each product, where they can send complaint based on the product id when they id for each product, where they can send complaint based on the product id when they find a fault product .The complaints can be assigned to different persons and will get find a fault product .The complaints can be assigned to different persons and will get tracked to closure. The “Online Complaint Management System” (OCMS) software is tracked to closure. The “Online Complaint Management System” (OCMS) software is an independent application. It is a self-contained product.

an independent application. It is a self-contained product.

The traditional forum system consists of public meeting or presentation involving The traditional forum system consists of public meeting or presentation involving a

a discussion discussion usually among usually among experts experts and and often often including including audience audience participation. participation. InIn General the forums may belong to specific issues like WAP forum, MATH forum, General the forums may belong to specific issues like WAP forum, MATH forum, Economic forum, Freedom forum, Software forum etc. In particular, Consumer Forum Economic forum, Freedom forum, Software forum etc. In particular, Consumer Forum deals with customer rights against vendors or the manufactures o

deals with customer rights against vendors or the manufactures o f the faulty products.f the faulty products.

Our Web Enabled Call Center (WECC) does all the jobs that are done in Our Web Enabled Call Center (WECC) does all the jobs that are done in conventional system but, here, everything is done in more formal and efficient conventional system but, here, everything is done in more formal and efficient manner. This system acts as an interface between the customers and call engineers manner. This system acts as an interface between the customers and call engineers thereby enabling them to forward their complaints to the appropriate call engineer. thereby enabling them to forward their complaints to the appropriate call engineer. Hence, making the work easy for both the complaint raiser and the person who Hence, making the work easy for both the complaint raiser and the person who resolves the complaint. Here,

resolves the complaint. Here, in complaint tracking, it in complaint tracking, it fulfillfulfills different requirements os different requirements off administrator and customer more e

administrator and customer more efficifficiently.ently.

Key Words:

Consumer Forum, Economic Forum, Web Enabled Call Center (WECC), Fault Consumer Forum, Economic Forum, Web Enabled Call Center (WECC), Fault

(6)

CHAPTER1

INTRODUCTION

1.1 Introduction 1.1 Introduction

An organization’s customers may have complaints about its products. They will be given An organization’s customers may have complaints about its products. They will be given an product id for each product, where they can send an email when they have a complaint an product id for each product, where they can send an email when they have a complaint to register. The complaint id will get converted to complaints and get assigned to the to register. The complaint id will get converted to complaints and get assigned to the persons handling that product. The complaints can be assigned to different persons and persons handling that product. The complaints can be assigned to different persons and will get tracked to closure. The person handling the complaint will have the facility to will get tracked to closure. The person handling the complaint will have the facility to communicate with the customer via emails through t

communicate with the customer via emails through t he system.he system. 1.2 Product Perspective

1.2 Product Perspective

The “Online Complaint Management System” software is an independent application. It The “Online Complaint Management System” software is an independent application. It is a self-contained product. The system interfaces, user interfaces and hardware interfaces is a self-contained product. The system interfaces, user interfaces and hardware interfaces related with this software are defined as follows.

related with this software are defined as follows.

1.2.1 System Interfaces 1.2.1 System Interfaces

The client systems should be able to share the data available in the data base through the The client systems should be able to share the data available in the data base through the network connection.

network connection.

1.2.2 User Interfaces 1.2.2 User Interfaces

The screen formats and menu structure should be in such a way that even have users will The screen formats and menu structure should be in such a way that even have users will find it easy to use. The product must be use-friendly and very inter-active. The find it easy to use. The product must be use-friendly and very inter-active. The functionality provided by the system like displaying error messages should adapt itself to functionality provided by the system like displaying error messages should adapt itself to the different users of the software.

the different users of the software.

1.2.3 Software Interfaces 1.2.3 Software Interfaces Operating

Operating System System : : Any Any Windows Windows OS.OS.

Client

Client Software Software : : Any Web Any Web Browser Browser (Internet (Internet Explorer).Explorer).

Communication

(7)

Intermediate

Intermediate Language Language : : JVM.JVM.

1.2.4 Memory Constraints 1.2.4 Memory Constraints

The system would require disk space of 10 GB and a 256 MB HDD and 64 MB RAM for The system would require disk space of 10 GB and a 256 MB HDD and 64 MB RAM for client systems.

client systems.

Operation Operation

The users can first make a register a complaint a particular based on the product id. The The users can first make a register a complaint a particular based on the product id. The system provides the customer with a pin code which gives him access to either make any system provides the customer with a pin code which gives him access to either make any changes in his reservation or cancel a reservation. These must also be back up of data to changes in his reservation or cancel a reservation. These must also be back up of data to enable any easy recovery from any features.

enable any easy recovery from any features.

1.3 Site Adaptive Requirements 1.3 Site Adaptive Requirements

The “OCMS” software is an independent and self-contained product and no modification The “OCMS” software is an independent and self-contained product and no modification are required to adapt to

are required to adapt to a particular installation.a particular installation.

Product Functions Product Functions

•• The major functions includeThe major functions include

•• Providing product complaint detailsProviding product complaint details

•• Complaint Complaint registration fregistration for a particular or a particular product id, product id, date and date and time and alstime and alsoo providing with a pin code

providing with a pin code as a customer address.as a customer address.

•• Allowing the customer to view sstatus of the complaint.Allowing the customer to view sstatus of the complaint.

(8)

•• Very less time required.Very less time required. •• Very less cost.Very less cost.

•• Risk is low.Risk is low.

•• No technical knowledge is needed for the user.No technical knowledge is needed for the user. •• Easy to maintainEasy to maintain

CHAPTER2

(9)

LITERATURE SURVEY

2.1 Introduction:

The customer has to visit forums and made complaint against a faulty The customer has to visit forums and made complaint against a faulty product. The complaint will be discussed in the presence of customer, vendor and a team product. The complaint will be discussed in the presence of customer, vendor and a team of expert committee along with judge. The final decision making is a time consuming so of expert committee along with judge. The final decision making is a time consuming so the customer has to revisit the

the customer has to revisit the forum to get the result.forum to get the result.

2.2 Proposed System:

Our Web Enabled Call Center does all the jobs that are done in conventional Our Web Enabled Call Center does all the jobs that are done in conventional system but, here, everything is done in more formal and efficient manner. This system system but, here, everything is done in more formal and efficient manner. This system acts as an interface between the customers and call engineers thereby enabling them to acts as an interface between the customers and call engineers thereby enabling them to forward their complaints to the appropriate call engineer. Hence, making the work easy forward their complaints to the appropriate call engineer. Hence, making the work easy for both the complaint raiser and the person who resolves the complaint. Here, in for both the complaint raiser and the person who resolves the complaint. Here, in complaint tracking, it fulfills different requirements of administrator and customer more complaint tracking, it fulfills different requirements of administrator and customer more efficiently. The specific purpose of the system is to gather and resolve complaints that efficiently. The specific purpose of the system is to gather and resolve complaints that arise in different projects handled by the o

arise in different projects handled by the o rganization.rganization.

2.3 Existing System:

The traditional forum system consists of public meeting or presentation involving The traditional forum system consists of public meeting or presentation involving a discussion usually among experts and often including audience participation. In General a discussion usually among experts and often including audience participation. In General the forums may belong to specific issues like WAP forum, MATH forum, Economic the forums may belong to specific issues like WAP forum, MATH forum, Economic forum, Freedom forum, Software forum etc. In particular, Consumer Forum deals with forum, Freedom forum, Software forum etc. In particular, Consumer Forum deals with customer rights against vendors or the

customer rights against vendors or the manufactures of the faulty products.manufactures of the faulty products.

Disadvantages of Existing System: Disadvantages of Existing System:

The customer has to visit forums and made co

The customer has to visit forums and made co mplainmplaint agat against a faulty product.inst a faulty product. The complaint will be discussed in the presence of customer, vendor and a team of expert The complaint will be discussed in the presence of customer, vendor and a team of expert committee along with judge. T

committee along with judge. The final decision making is a time consuming so the final decision making is a time consuming so t hehe customer has to revisit the forum to get t

(10)

The site would use a database to

The site would use a database to hold customers complaints and reports generatedhold customers complaints and reports generated by the technical tea

by the technical team .online compliant management system contam .online compliant management system contains all complaintins all complaint details .a complain

details .a complaint inventory t inventory contains all complaints wicontains all complaints with its status reports th its status reports .the system.the system provides the facility if the customers gives the wrong information t

provides the facility if the customers gives the wrong information t hen hehen he

��

edit the edit the complaint details

complaint details .to provi.to provide the proper de the proper information information to the syto the system. The mstem. The modern onlineodern online complaint

complaint management symanagement system is stem is comprehensive scomprehensive suite of uite of identify identify the faulthe fault t productsproducts based on the

based on the customers provided information and generating reports for the faultcustomers provided information and generating reports for the fault products. products.

2.4 Module Description:

2.4.1 Registration Module 2.4.1 Registration Module::

This module is dedicated to register all the complaints from the customers This module is dedicated to register all the complaints from the customers whenever they come to compliant. The process of this module is divided into two whenever they come to compliant. The process of this module is divided into two sub processes in which one registers the complete details of the customer who wants sub processes in which one registers the complete details of the customer who wants to submit the compliant, other registers the complete

to submit the compliant, other registers the complete details of the compliantdetails of the compliant

2.4.2 Monitoring Module 2.4.2 Monitoring Module::

This module is dedicated to monitoring the complaints by searching the This module is dedicated to monitoring the complaints by searching the complaints and updating the status of complaints at any time. The process of this module complaints and updating the status of complaints at any time. The process of this module is divided into two sub processes in which one searches for complaints and other updates is divided into two sub processes in which one searches for complaints and other updates the status.

the status.

2.4.3 Reports Module 2.4.3 Reports Module::

Report generation module is dedicated to produce reports based on the Report generation module is dedicated to produce reports based on the information to given by the user. The process of this module is main divided into two sub information to given by the user. The process of this module is main divided into two sub processes in which one g

processes in which one gives summary report other gives the detailed report.ives summary report other gives the detailed report.

2.4.4 Administration Module 2.4.4 Administration Module::

(11)

Administration module is dedicated to administrate the users, divisions, Administration module is dedicated to administrate the users, divisions, categories, sections and Eros etc.

categories, sections and Eros etc.

2.5 Reports:

The reports generated in project depict the up to date information about the The reports generated in project depict the up to date information about the current status of various records. The various types of reports that will be generated in current status of various records. The various types of reports that will be generated in this project are as mentioned below.

this project are as mentioned below.

2.5.1 Time oriented reports 2.5.1 Time oriented reports::

Time oriented reports give the information of complaints according to the time period Time oriented reports give the information of complaints according to the time period given. The time oriented reports are daily, weekly, monthly, yearly and also includes given. The time oriented reports are daily, weekly, monthly, yearly and also includes reports on certain period o

reports on certain period of time etc.f time etc.

2.5.2 Status oriented reports 2.5.2 Status oriented reports::

Status oriented reports give the information of complaints according to the status given. Status oriented reports give the information of complaints according to the status given. The status oriented reports are completed,

The status oriented reports are completed, pending and delayed repopending and delayed reports.rts.

2.5.3 Division wise reports 2.5.3 Division wise reports::

Division wise reports give the information of complaints according to the division Division wise reports give the information of complaints according to the division given.

given.

2.5.4 Compliant wise reports: 2.5.4 Compliant wise reports:

Compliant wise reports give the information of complaints according to the compliant Compliant wise reports give the information of complaints according to the compliant type given.

type given.

2.5.5 Employee wise reports: 2.5.5 Employee wise reports:

Employee wise reports give the information of complaints according to the employee Employee wise reports give the information of complaints according to the employee referred to solve the compliant.

(12)

CHAPTER3

REVIEW OF THE STATE OF ART

3.1 FEASIBILITY STUDY

Feasibility s

Feasibility study is an important phastudy is an important phase in the software devele in the software development process. opment process. It enablesIt enables the developer to h

the developer to have an ave an assessment of assessment of the product being the product being developed. developed. It refIt refers to theers to the feasibility study of the product in terms of outcomes of the product, operational use and feasibility study of the product in terms of outcomes of the product, operational use and technical support required for implementing it.

technical support required for implementing it.

Feasibility study should be performed on the basis of various criteria and parameters. Feasibility study should be performed on the basis of various criteria and parameters. The various feasibility studies are:

The various feasibility studies are: •

• Economic Economic FeasibilityFeasibility •

• Operational Operational FeasibilityFeasibility •

• Technical Technical FeasibilityFeasibility

3.1.1 ECONOMIC FEASIBILITY 3.1.1 ECONOMIC FEASIBILITY

It refers to the benefits or outcomes we are deriving from the product as compared to the It refers to the benefits or outcomes we are deriving from the product as compared to the total cost we are spen

total cost we are spending for developing the product. ding for developing the product. If the benefiIf the benefits are more or less ts are more or less thethe same as the older system, then

same as the older system, then it is not feasible to develop the prodit is not feasible to develop the product.uct.

3.1.2 OPERATIONAL FEASIBILITY 3.1.2 OPERATIONAL FEASIBILITY

It refers

It refers to the feasito the feasibility of the bility of the product to be product to be operational. operational. Some products may Some products may workwork very well at design and

very well at design and implementation but may fail in the realimplementation but may fail in the real

environment.

environment. It iIt includes the ncludes the study of study of additional human additional human resource required resource required and theirand their technical expertise.

technical expertise.

3.1.3 TECHNICAL FEASIBILITY 3.1.3 TECHNICAL FEASIBILITY

It refers to whether the software that is available in the market fully supports the present It refers to whether the software that is available in the market fully supports the present application. It studies the pros and cons of using particular software for the development application. It studies the pros and cons of using particular software for the development

(13)

and its feasibili

and its feasibility. ty. It also studies the addiIt also studies the additional training needed to be given to the peopletional training needed to be given to the people to make the application work.

to make the application work.

3.2. SOFTWARE REQUIREMENTS

3.2. SOFTWARE REQUIREMENTS SPECIFICATIONS

SPECIFICATIONS

Software Requirement Specification (SRS) is the starting point of the software Software Requirement Specification (SRS) is the starting point of the software developing activity. As system grew more complex it became evident that the goal of the developing activity. As system grew more complex it became evident that the goal of the entire system cannot be easily comprehended. Hence the need for the requirement phase entire system cannot be easily comprehended. Hence the need for the requirement phase arose .The software is initiated by the client needs .The SRS is the means of translating arose .The software is initiated by the client needs .The SRS is the means of translating the ideas of the minds of the clients (the i/p) into a formal document (the o/p of the the ideas of the minds of the clients (the i/p) into a formal document (the o/p of the requirement phase).

requirement phase).

The SRS phase consists o

The SRS phase consists of two basic activities:f two basic activities:

Problem or requirement Analysis:

The process is order and more nebulous of the two, deals with The process is order and more nebulous of the two, deals with understand the problem, the goal and constraints.

understand the problem, the goal and constraints.

Requirement Specification

Here, the focus is on specifying what has been found giving analysis Here, the focus is on specifying what has been found giving analysis such as representation, specification languages and tools, and checking the such as representation, specification languages and tools, and checking the specifications are addressed during this activity. The requirement phase terminates specifications are addressed during this activity. The requirement phase terminates with the production of the validate SRS document. Producing the SRS document is with the production of the validate SRS document. Producing the SRS document is the basic goal of this phase.

the basic goal of this phase.

The Software Requirements Specification (SRS) begins the translation The Software Requirements Specification (SRS) begins the translation process that converts the software requirements into the language the developers will process that converts the software requirements into the language the developers will use. The SRS draws on the use-cases from the User Requirement Document (URD) use. The SRS draws on the use-cases from the User Requirement Document (URD) and analyzes the situations from a number of perspectives to discover and eliminate and analyzes the situations from a number of perspectives to discover and eliminate inconsistencies, ambiguities, and omissions before development progresses inconsistencies, ambiguities, and omissions before development progresses significantly under mistaken assumptions.

(14)

Role of SRS:

The Purpose of the software requirement spec

The Purpose of the software requirement specificatiification on is to reduce theis to reduce the communication gap between the clients and developers. Software requirement communication gap between the clients and developers. Software requirement specification is the medium, through which the client and user needs are accurately specification is the medium, through which the client and user needs are accurately specified. It forms the basis of software development. A good SRS should satisfy all specified. It forms the basis of software development. A good SRS should satisfy all the parties involved in the system.

the parties involved in the system.

3.2.1 Software Requirements: 3.2.1 Software Requirements: Operating

Operating System System : : Any Any Windows Windows OS.OS. Client

Client Program Program : : Internet Explorer.Internet Explorer. Server

Server Program Program : : Apache Apache Tomcat Tomcat 6.0.6.0. IDE

IDE : : My My Eclipse Eclipse 8.6.8.6. Editors

Editors : : Adobe Adobe Dreamweaver, Dreamweaver, Photoshop.Photoshop. Language

Language : : JAVA JAVA (JSP (JSP & & JDBC) JDBC) & & HTML.HTML. Client

Client side side Scripting Scripting : : Java Java script.script. Database

Database software’s software’s : : Oracle10g.Oracle10g. Intermediate

Intermediate Language Language : : JVM.JVM. 3.2.2 Hardware Requirements: 3.2.2 Hardware Requirements: Processor Processor : : P4P4 Ram Ram : : 512 MB512 MB Communication

Communication Channel Channel : : InternetInternet Hard

Hard Disk Disk : : 10 10 GBGB Monitor

Monitor : : VGA VGA Color Color (256)(256)

3.3 Non-functional Requirements:

Performance

1.

1. Response time of the Online Complaint Management System should be less than 2 Response time of the Online Complaint Management System should be less than 2 second most of the time. Response time refers to the waiting time while the system second most of the time. Response time refers to the waiting time while the system accesses, queries and retrieves the information from the databases (DB-user, DB accesses, queries and retrieves the information from the databases (DB-user, DB schedule etc) (A local copy of flight schedule database is maintained as DB schedule to schedule etc) (A local copy of flight schedule database is maintained as DB schedule to reduce this access time).

(15)

2.

2. OCMS shall be able to handle at OCMS shall be able to handle at least 1000 transactions/inquiries per second.least 1000 transactions/inquiries per second.

3.

3. OCMS shall show no v OCMS shall show no visiisible deterioration in response time as the ble deterioration in response time as the number of usersnumber of users or flight schedule data increases.

or flight schedule data increases.

Reliability

1.

1. OCMS shall be available 24 hours a day, 7 days a week. OCMS shall be available 24 hours a day, 7 days a week.

2.

2. OCMS shall always provide real time information about flight availability information. OCMS shall always provide real time information about flight availability information.

3.

3. OCMS shall be robust enough to have a high degree of fault tolerance. For example, ifOCMS shall be robust enough to have a high degree of fault tolerance. For example, if the user enters a negative number of passengers or a value too large, the system should the user enters a negative number of passengers or a value too large, the system should not crash and shall ident

not crash and shall identify the invalid input and produce ify the invalid input and produce a suitable error message.a suitable error message.

4.

4. OCMS shall be able to recover from hardware failures, power failures and other OCMS shall be able to recover from hardware failures, power failures and other natural catastrophes and rollback the dat

natural catastrophes and rollback the databases to their most recent valid state.abases to their most recent valid state.

Usability

1.

1. OCMS shall provide a easy-to-use graphical interface similar to other existing OCMS shall provide a easy-to-use graphical interface similar to other existing reservation system so that the users do

reservation system so that the users do not have to learn a new style onot have to learn a new style of interaction.f interaction.

2.

2. The web interface should be intuitive and easily navigable Users should be able to The web interface should be intuitive and easily navigable Users should be able to understand the menu and options provided by OCMS .

understand the menu and options provided by OCMS .

3.

3. Any notification or error messages generated by OCMS shall be clear, succinct, polite Any notification or error messages generated by OCMS shall be clear, succinct, polite and free of jargon.

and free of jargon.

Integrity

1.

1. Only system administer has the right to change system parameters, such as pricing Only system administer has the right to change system parameters, such as pricing policy etc. The system should be secure and must use encryption to protect the databases. policy etc. The system should be secure and must use encryption to protect the databases. 2.

2. Users need to be authenticated Users need to be authenticated before having access to any personal datbefore having access to any personal data.a.

3.4 System Process Model:

The Software Life Cycle The Software Life Cycle

1.

1. Encompasses all activities from initial analysis untEncompasses all activities from initial analysis until obsolescenceil obsolescence 2.

2. Formal process for software developmentFormal process for software development a.

(16)

b.

b. Gives guidelines for how to carry oGives guidelines for how to carry out the phasesut the phases 3.

3. Development processDevelopment process a. a. AnalysisAnalysis b. b. DesignDesign c. c. ImplementationImplementation d. d. TestingTesting e. e. DeploymentDeployment 4.

4. A structured set of activities required to develop A structured set of activities required to develop a software systema software system •• Specification;Specification;

•• Design;Design; •• Validation;Validation; •• Evolution.Evolution.

A software process model is an abstract representation of a process. It presents a A software process model is an abstract representation of a process. It presents a description

description of of a a process process from from some some particular particular perspective.perspective.

Generic software process models

•• The waterfall model and distinct phases oThe waterfall model and distinct phases of specification and development.f specification and development.

•• Evolutionary developmentEvolutionary development

•• Specification, development and validation are interleaved.Specification, development and validation are interleaved. •• Component-based software engineeringComponent-based software engineering

There are many variants of these models e.g. formal development where a waterfall-like There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through process is used but the specification is a formal specification that is refined through several stages to an

several stages to an implementable design.implementable design.

Spiral Model

Each cycle involves the same sequence of steps as the waterfall process model. Breaks Each cycle involves the same sequence of steps as the waterfall process model. Breaks development process down into multiple phases. Early phases focus on the construction development process down into multiple phases. Early phases focus on the construction

(17)

of prototypes. Lessons learned from development of one prototype can be applied to the of prototypes. Lessons learned from development of one prototype can be applied to the next iteration.

next iteration.

Figure 3.1 Spiral model Figure 3.1 Spiral model

Stages in SDLC: Stages in SDLC: ♦

♦ Requirement GatheringRequirement Gathering ♦ ♦ AnalysisAnalysis ♦ ♦ DesigningDesigning ♦ ♦ CodingCoding ♦ ♦ TestingTesting ♦ ♦ MaintenanceMaintenance 3.4.2 Requirements Gathering

3.4.2 Requirements Gathering stage:stage:

The requirements gathering process takes as its input the goals identified in the The requirements gathering process takes as its input the goals identified in the high-level requirements section of the project plan. Each goal will be refined into a set of level requirements section of the project plan. Each goal will be refined into a set of one or more requirements. These requirements define the major functions of the one or more requirements. These requirements define the major functions of the intended application, define operational data areas and reference data areas, and define intended application, define operational data areas and reference data areas, and define

(18)

the initial data entities. Major functions include critical processes to be managed, as the initial data entities. Major functions include critical processes to be managed, as well as mission critical inputs, outputs and reports. A user class hierarchy is developed well as mission critical inputs, outputs and reports. A user class hierarchy is developed and associated with these major functions, data areas, and data entities. Each of these and associated with these major functions, data areas, and data entities. Each of these definitions is termed a Requirement. Requirements are identified by unique definitions is termed a Requirement. Requirements are identified by unique requirement identifiers and, at minimum, contain a requirement title and textual requirement identifiers and, at minimum, contain a requirement title and textual description.

description.

3.4.3 Analysis Stage: 3.4.3 Analysis Stage:

The planning stage establishes a bird's eye view of the intended software product, The planning stage establishes a bird's eye view of the intended software product, and uses this to establish the basic project structure, evaluate feasibility and risks and uses this to establish the basic project structure, evaluate feasibility and risks associated with the project, and describe appropriate management and technical associated with the project, and describe appropriate management and technical approaches .The most critical section of the project plan is a listing of high-level product approaches .The most critical section of the project plan is a listing of high-level product requirements, also referred to as goals. All of the software product requirements to be requirements, also referred to as goals. All of the software product requirements to be developed during the requirements definition stage flow from one or more of these goals. developed during the requirements definition stage flow from one or more of these goals. The minimum information for each goal consists of a title and textual description, The minimum information for each goal consists of a title and textual description, although additional information and references to external documents may be included. although additional information and references to external documents may be included. The outputs of the project planning stage are the configuration management plan, the The outputs of the project planning stage are the configuration management plan, the quality assurance plan, and the project plan and schedule, with a detailed listing of quality assurance plan, and the project plan and schedule, with a detailed listing of scheduled activities for the upcoming Requirements stage, and high level estimates of scheduled activities for the upcoming Requirements stage, and high level estimates of effort for the out stages.

effort for the out stages.

3.4.4 Designing Stage: 3.4.4 Designing Stage:

The design stage takes as its initial input the requirements identified in the approved The design stage takes as its initial input the requirements identified in the approved requirements document. For each requirement, a set of one or more design elements will requirements document. For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops, and/or prototype efforts. Design be produced as a result of interviews, workshops, and/or prototype efforts. Design elements describe the desired software features in detail, and generally include functional elements describe the desired software features in detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo code, and a complete entity-relationship diagram with a full data diagrams, pseudo code, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to describe the software in sufficient dictionary. These design elements are intended to describe the software in sufficient detail that skilled programmers may develop t

(19)

Figure: 3.2 Designing Phase Figure: 3.2 Designing Phase

When the design document is finalized and accepted, the RTM is updated to show that When the design document is finalized and accepted, the RTM is updated to show that each design element is formally associated with a specific requirement. The outputs of each design element is formally associated with a specific requirement. The outputs of the design stage are the design document, an updated RTM, and an updated project plan. the design stage are the design document, an updated RTM, and an updated project plan.

3.4.5 Development (Coding) Stage: 3.4.5 Development (Coding) Stage:

The development stage takes as its primary input the design elements described in the The development stage takes as its primary input the design elements described in the approved design document. For each design element, a set of one or more software approved design document. For each design element, a set of one or more software artifacts will be produced. Software artifacts include but are not limited to menus, artifacts will be produced. Software artifacts include but are not limited to menus, dialogs, data management forms, data reporting formats, and specialized procedures and dialogs, data management forms, data reporting formats, and specialized procedures and functions. Appropriate test cases will be developed for each set of functionally related functions. Appropriate test cases will be developed for each set of functionally related software artifacts, and an online help system will be developed to guide users in their software artifacts, and an online help system will be developed to guide users in their interactions with the so

(20)

Figure: 3.3 Development Stage Figure: 3.3 Development Stage

The RTM will be updated to show that each developed artifact is linked to a The RTM will be updated to show that each developed artifact is linked to a specific design element, and that each developed artifact has one or more specific design element, and that each developed artifact has one or more corresponding test case items. At this point, the RTM is in its final configuration. The corresponding test case items. At this point, the RTM is in its final configuration. The outputs of the development stage include a fully functional set of software that outputs of the development stage include a fully functional set of software that satisfies the requirements and design elements previously documented, an online help satisfies the requirements and design elements previously documented, an online help system that describes the operation of the software, an implementation map that system that describes the operation of the software, an implementation map that identifies the primary code entry points for all major system functions, a test plan that identifies the primary code entry points for all major system functions, a test plan that describes the test cases to be used to validate the correctness and completeness of the describes the test cases to be used to validate the correctness and completeness of the software, an updated RTM, and an updated project plan.

software, an updated RTM, and an updated project plan.

3.4.6 Integration & Test Stage: 3.4.6 Integration & Test Stage:

During the integration and test stage, the software artifacts, online help, and test data During the integration and test stage, the software artifacts, online help, and test data are migrated from the development environment to

are migrated from the development environment to a separate test environment. At thisa separate test environment. At this point, all test cases are run to verify the correctness and completeness of the software. point, all test cases are run to verify the correctness and completeness of the software. Successful execution of the test suite confirms a robust and complete migration Successful execution of the test suite confirms a robust and complete migration

(21)

capability. During this stage, reference data is finalized for production use and capability. During this stage, reference data is finalized for production use and production users are identified and linked to their appropriate roles. The final production users are identified and linked to their appropriate roles. The final reference data (or links to reference data source files) and production user list are reference data (or links to reference data source files) and production user list are compiled into the Production Initiation Plan.

compiled into the Production Initiation Plan.

Figure: 3.4 Integration & Test Stage Figure: 3.4 Integration & Test Stage

The outputs of the integration and test stage include an integrated set of software, an The outputs of the integration and test stage include an integrated set of software, an online help system, an implementation map, a production initiation plan that describes online help system, an implementation map, a production initiation plan that describes reference data and production users, an acceptance plan which contains the final suite of reference data and production users, an acceptance plan which contains the final suite of test cases, and an updated project plan.

test cases, and an updated project plan.

3.4.7 Installation & Acceptance Test: 3.4.7 Installation & Acceptance Test:

During the installation and acceptance stage, the software artifacts, online help, and During the installation and acceptance stage, the software artifacts, online help, and initial production data are loaded onto the production server. At this point, all test cases initial production data are loaded onto the production server. At this point, all test cases

(22)

are run to verify the correctness and completeness of the software. Successful execution are run to verify the correctness and completeness of the software. Successful execution of the test suite is a prerequ

of the test suite is a prerequisiisite to te to acceptance of the software by the custoacceptance of the software by the custo mer.mer.

After customer personnel have verified that the initial production data load is After customer personnel have verified that the initial production data load is correct and the test suite has been executed with satisfactory results, the customer correct and the test suite has been executed with satisfactory results, the customer formally accepts the delivery of the so

formally accepts the delivery of the software.ftware.

Figure: 3.5 Installation & Acceptance St Figure: 3.5 Installation & Acceptance Stageage

The primary outputs of the installation and acceptance stage include a production The primary outputs of the installation and acceptance stage include a production application, completed acceptance test suite, and a memorandum of customer application, completed acceptance test suite, and a memorandum of customer acceptance of the software. Finally, the PDR enters the last of the actual labor data into acceptance of the software. Finally, the PDR enters the last of the actual labor data into the project schedule and locks the project as a permanent project record. At this point the project schedule and locks the project as a permanent project record. At this point the PDR "locks" the project by archi

the PDR "locks" the project by architecture software items tecture software items the implementation map, thethe implementation map, the source code, and the documentation for future reference.

source code, and the documentation for future reference.

3.4.8 Maintenance: 3.4.8 Maintenance:

Outer rectangle represents maintenance of a project, Maintenance team will start with Outer rectangle represents maintenance of a project, Maintenance team will start with requirement study, understanding of documentation later employees will be assigned requirement study, understanding of documentation later employees will be assigned work and they will undergo

(23)

CHAPTER4 CHAPTER4 SYSTEM DESIGN SYSTEM DESIGN 4.1 ER DIAGRAM 4.1 ER DIAGRAM

The ER diagram is drawn to have a better understanding of the whole scenario, it The ER diagram is drawn to have a better understanding of the whole scenario, it was used to conceptualize the phenomena, actions and interactions between various entities was used to conceptualize the phenomena, actions and interactions between various entities and to arrive at the specific requirements in a comprehensive manner. The ER diagram is and to arrive at the specific requirements in a comprehensive manner. The ER diagram is attached with this SRS.

attached with this SRS.

Figure: 4.1 ER Diagram Figure: 4.1 ER Diagram 4.2 DATA

4.2 DATA DICTIONARYDICTIONARY

After carefully understanding the requirements of the client the the entire data After carefully understanding the requirements of the client the the entire data storage requirements are divided into tables. The below tables are normalized to avoid storage requirements are divided into tables. The below tables are normalized to avoid any anomalies during the course of data entry

(24)

Table: 4.1 Product Information Table: 4.1 Product Information

Table: 4.2 Complaint Details Table: 4.2 Complaint Details

(25)

4.3 DATA FLOW DIAGRAMS

A

A data flow diagramdata flow diagram ( (DFDDFD) is a graphical representation of the "flow" of data) is a graphical representation of the "flow" of data through an

through an information syinformation system. A stem. A data fldata flow diagram can ow diagram can also be usalso be used for theed for the visualization of data processing (structured design).

visualization of data processing (structured design).

Dataflow diagrams can be used to provide the end user with a physical idea of Dataflow diagrams can be used to provide the end user with a physical idea of where the

where the data data they input, they input, ultimately ultimately has an has an effect effect upon the upon the structure of structure of the whthe wholeole system from order to dispatch to restock how any system is developed can be system from order to dispatch to restock how any system is developed can be determined through a dataflow diagram.

determined through a dataflow diagram.

4.3.1 Developing a DFD 4.3.1 Developing a DFD

Developing Top-Down Approach Developing Top-Down Approach

•

• The The system system designer designer makes makes a a context lcontext level evel DFD DFD ,which ,which shows shows the the interaction interaction (data(data

flows) between the system (represented by one process) and the system environment flows) between the system (represented by one process) and the system environment (represented by terminator).

(represented by terminator).

•

• The system is decomposed in lower level DFD (Zero) into a set of processes, dataThe system is decomposed in lower level DFD (Zero) into a set of processes, data

stores , and the data

stores , and the data flflows between tows between these processes and data hese processes and data stores.stores.

•

• Each process is then decomposed into an even lower level diagram containing its subEach process is then decomposed into an even lower level diagram containing its sub

process. process.

•

• This approach then continues on the subsequent sub processes , until a necessary andThis approach then continues on the subsequent sub processes , until a necessary and

sufficient level of detail is reached which is called

sufficient level of detail is reached which is called the primitive processthe primitive process

4.3.2 DFD Symbols 4.3.2 DFD Symbols In the DFD, there

In the DFD, there are four symbolsare four symbols

1.

1. A square defines a source(originator) or destination of system dataA square defines a source(originator) or destination of system data

2.

2. An arrow iAn arrow identifies data fldentifies data flow. ow. It is It is the pipeline through which the pipeline through which the informationthe information flows

(26)

3.

3. A circle or a bubble represents a process that transforms incoming data flow intoA circle or a bubble represents a process that transforms incoming data flow into outgoing data flows.

outgoing data flows.

4.

4. An open rectangle is a datAn open rectangle is a data store, data at rest or a store, data at rest or a temporary repository of dataa temporary repository of data

Process that transforms data flow Process that transforms data flow

Source or Destination of data Source or Destination of data

Data flow Data flow

Data Store Data Store

4.4 UNIFIED MODELING LANGUAGE (UML)

The Unified Modeling language is a standard language for specifying, The Unified Modeling language is a standard language for specifying, visualizing, constructing and documenting the software system and its components. It is a visualizing, constructing and documenting the software system and its components. It is a graphical language, which provides a vocabulary and set of semantics and rules. The graphical language, which provides a vocabulary and set of semantics and rules. The UML focuses on the conceptual and physical representation of the system. It captures the UML focuses on the conceptual and physical representation of the system. It captures the

(27)

decisions and understandings about systems that must be constructed. It is used to decisions and understandings about systems that must be constructed. It is used to understand, design, configure, maintain and co

understand, design, configure, maintain and co ntrol informatintrol information about ton about the systems.he systems.

Visualizing: Visualizing:

Through UML we view an existing system and ultimately we visualize how the system Through UML we view an existing system and ultimately we visualize how the system is going to be after implementation. Unless we think, we cannot implement. UML helps to is going to be after implementation. Unless we think, we cannot implement. UML helps to visualize, how the co

visualize, how the components of the system communicate and interact mponents of the system communicate and interact with each other.with each other.

Specifying: Specifying:

Specifying means building models that are precise, unambiguous and complete Specifying means building models that are precise, unambiguous and complete UML addresses the specification of all the important analysis design, implementation UML addresses the specification of all the important analysis design, implementation decisions that must be made

decisions that must be made in developing and deploying a in developing and deploying a software system.software system.

Constructing: Constructing:

UML models can be directly connected to a variety of programming language UML models can be directly connected to a variety of programming language through mapping a model from UML to a programming language like JAVA or C++ or through mapping a model from UML to a programming language like JAVA or C++ or VB. Forward Engineering and Reverse E

VB. Forward Engineering and Reverse Engineering is possible through UML.ngineering is possible through UML.

Documenting: Documenting:

The Deliverables of a project apart from coding are some Artifacts, which are The Deliverables of a project apart from coding are some Artifacts, which are critical in controlling, measuring and communicating about a system during its critical in controlling, measuring and communicating about a system during its development viz. requirements, architecture, desire, source code, project plans, tests, development viz. requirements, architecture, desire, source code, project plans, tests, prototypes, releasers etc.

prototypes, releasers etc.

Diagrams in UML:

Diagrams are graphical presentation of set of elements. Diagrams project a Diagrams are graphical presentation of set of elements. Diagrams project a system, or visualize a system from different angles and perspectives. The UML has 9 system, or visualize a system from different angles and perspectives. The UML has 9 diagrams. These diagrams can be c

(28)

Static: Static: 1. Class Diagrams. 1. Class Diagrams. 2. Object Diagrams. 2. Object Diagrams. 3. Component Diagrams. 3. Component Diagrams. 4. Deployment Diagrams. 4. Deployment Diagrams. Dynamic: Dynamic: 1. Use-Case Diagram. 1. Use-Case Diagram. 2. Sequence Diagram 2. Sequence Diagram 3. Collaboration Diagram. 3. Collaboration Diagram. 4.

4. State State Chart Chart DiagramDiagram

5. Activity Diagram. 5. Activity Diagram.

4.4.1 USE CASE DIAGRAMS

Use case Diagram: Use case Diagram:

These diagrams Shows a set of use cases and actors and their relationships. These diagrams Shows a set of use cases and actors and their relationships. These diagrams illustrate the static use case view of a system and are important in These diagrams illustrate the static use case view of a system and are important in organizing and modeling the behaviors of a system. The Use case diagram is used to organizing and modeling the behaviors of a system. The Use case diagram is used to identify the primary elements and processes that form the system. The primary identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors

(29)

Client Module : Client Module :

Figure: 4.2 Client Module Use Case Diagram Figure: 4.2 Client Module Use Case Diagram

Administrator Module: Administrator Module: RegisterComplaint RegisterComplaint Login Login viewstatus viewstatus Logout Logout client client

(30)

Technical team module: Technical team module:

Figure: 4.4 Technical Team Module Use Case Diagram Figure: 4.4 Technical Team Module Use Case Diagram

4.4.2 ACTIVITY DIAGRAMS 4.4.2 ACTIVITY DIAGRAMS

Activity diagrams are used to represent the flow of statements. These are also Activity diagrams are used to represent the flow of statements. These are also useful to represent the business and operate on step by step work flow of components in a useful to represent the business and operate on step by step work flow of components in a system. It shows the overall flow control.

(31)

Administrator Module: Administrator Module:

Figure: 4.5 Administrator Module Activity Diagram Figure: 4.5 Administrator Module Activity Diagram

Check Check complaints complaints view view complaints complaints send compliants to send compliants to tech team tech team verfification

verfification displayerrodisplayerro rmessage rmessage updtae updtae stauts stauts Send mails Send mails Login\Regi Login\Regi ster ster LogOut LogOut fails fails success success

(32)

Technical team Module: Technical team Module:

Figure: 4.6 Technical Team Module Activity Diagram Figure: 4.6 Technical Team Module Activity Diagram

(33)

4.4.3 Collaboration diagram: 4.4.3 Collaboration diagram:

Figure: 4.7 Collaboration Diagram Figure: 4.7 Collaboration Diagram

admin :

Adminstartor

login : login

Db :

DBUtils

logout :

Logout

mon :

MonitorComplaint

2: status( )

9: commit( )

10:

3: openConnection( )

4: searchComplaintDetails( )

8: update( )

5: report( )

6: createUsers

7: showStatus()

1: login( )

11: logout( )

13: s

13: sessionClose(

essionClose())

12: closeConnection()

(34)

4.4.4 CLASS DIAGRAM 4.4.4 CLASS DIAGRAM

Figure: 4.7 Class Diagram Figure: 4.7 Class Diagram

Coustmer Coustmer productid : String productid : String name : String name : String middlename : String middlename : String lastname : String lastname : String email_id : String email_id : String address : String address : String setProductID() setProductID() setName() setName() setMiddleName() setMiddleName() setLastName() setLastName() setEmail() setEmail() setAddress() setAddress() opname() opname() Adminstartor Adminstartor Username : String Username : String password : String password : String createusers() createusers() createdivisions() createdivisions() opname() opname() RegisterComplaint RegisterComplaint complainttype complainttype description description postcomplaint() postcomplaint() login login username : String username : String password : String password : String conformpasswo conformpassword : rd : StringString check() check() updatestatus updatestatus isupdated : Boolean isupdated : Boolean updateComplaint() updateComplaint() Checkstatus Checkstatus complaintId : java.lang.String complaintId : java.lang.String showComplaints() showComplaints() status() status() remaider() remaider() MonitorComplaint MonitorComplaint complaintid : String complaintid : String complainttype : String complainttype : String date : Date date : Date status() status() report() report() Logout Logout sessionout : Integer sessionout : Integer logout() logout() DBUtils DBUtils isLoggedIn : Boolean isLoggedIn : Boolean isSesstionOut : Boolean isSesstionOut : Boolean openConnection() openConnection() close() close() searchComplaintDetails() searchComplaintDetails() update() update() commit() commit() sendCompalintDatails() sendCompalintDatails() showStatus() showStatus()

(35)

4.4.5 SEQUENCE DIAGRAM 4.4.5 SEQUENCE DIAGRAM

Customer module : Customer module :

Figure: 4.8 Sequence D

Figure: 4.8 Sequence Diagramiagram-Customer Module-Customer Module

: Coustmer

: Coustmer : :

RegisterComplaint RegisterComplaint

: Checkstatus

: Checkstatus _{db : DBUtils}_{db : DBUtils}

checkstatus() checkstatus() openConnection( ) openConnection( ) showcomplaintStatus() showcomplaintStatus() acknowledgement() acknowledgement() update() update() postcomplaint( ) postcomplaint( ) commit() commit() rollb rollback ack ()() login() login() logout logout

(36)

Administrator Module: Administrator Module:

Figure: 4.9 Sequence D

Figure: 4.9 Sequence Diagramiagram-Administrator Module-Administrator Module

admin : admin : Adminstartor Adminstartor

login : login

login : login _{mon :}_{mon :} _{logout : Logout}_{logout : Logout} _{Db : DBUtils}_{Db : DBUtils} MonitorComplaint

MonitorComplaint login( )

login( ) _{status( )}_{status( )}

searchCo

searchComplaintDemplaintDetails( tails( ))

update( ) update( ) commit( ) commit( ) report( ) report( ) showStatus() showStatus() createUsers createUsers openConnection( ) openConnection( ) logout( ) logout( ) closeConnection() closeConnection() sessionClose() sessionClose()

(37)

CHAPTER 5

CHAPTER 5 IMPLEMENTATION

IMPLEMENTATION

Implementation phase will give the idea about how are we doing of

project, in how many phases we are implementing the project.

5.1 CODING:

# MySQL-Front Dump 2.0 # MySQL-Front Dump 2.0

##

## Host: Host: localhost localhost Database: Database: AdminAdmin

#---# Server version 4.0.1-alpha-nt # Server version 4.0.1-alpha-nt

USE schememanager; USE schememanager;

# #

# Table structure for table 'applications' # Table structure for table 'applications'

# #

DROP TABLE IF EXISTS applications; DROP TABLE IF EXISTS applications;

CREATE TABLE IF NOT EXISTS

CREATE TABLE IF NOT EXISTS applications (applications (

ComID int(11) NOT NULL auto_increment, ComID int(11) NOT NULL auto_increment,

ProductID int(20) , ProductID int(20) , CusName varchar(50) , CusName varchar(50) , CusAddress varchar(255) , CusAddress varchar(255) ,

(38)

Status varchar(25) , Status varchar(25) , Remarks varchar(255) , Remarks varchar(255) , EmailID int(10) , EmailID int(10) , TechID int(10) , TechID int(10) , ); );

## Table structure for table 'login' ## Table structure for table 'login'

# #

DROP TABLE IF EXISTS login; DROP TABLE IF EXISTS login;

CREATE TABLE IF NOT EXISTS

CREATE TABLE IF NOT EXISTS login (login (

UserID varchar(50) NOT NULL DEFAULT '' , UserID varchar(50) NOT NULL DEFAULT '' ,

Password varchar(50) NOT NULL DEFAULT '' , Password varchar(50) NOT NULL DEFAULT '' ,

Auth int(11) NOT NULL DEFAULT '1' , Auth int(11) NOT NULL DEFAULT '1' ,

PRIMARY KEY (UserID) PRIMARY KEY (UserID)

); );

# #

# Dumping data for table 'login' # Dumping data for table 'login'

#INSERT INTO login VALUES("admin","admin","0"); #INSERT INTO login VALUES("admin","admin","0");

INSERT INTO login VALUES("ddo","ddo","2"); INSERT INTO login VALUES("ddo","ddo","2");

INSERT INTO login VALUES("gpo","gpo","1"); INSERT INTO login VALUES("gpo","gpo","1");

INSERT INTO login VALUES("normal","normal","3"); INSERT INTO login VALUES("normal","normal","3");

INSERT INTO login VALUES("user","user","3"); INSERT INTO login VALUES("user","user","3");

(39)

INSERT INTO login VALUES("vara","vara","0"); INSERT INTO login VALUES("vara","vara","0");

INSERT INTO login VALUES("sunil","sunil","1"); INSERT INTO login VALUES("sunil","sunil","1");

INSERT INTO login VALUES("ramkumar","ramkumar","2"); INSERT INTO login VALUES("ramkumar","ramkumar","2");

INSERT INTO login VALUES("anil","anil","0"); INSERT INTO login VALUES("anil","anil","0");

INSERT INTO login VALUES("vivek","vivek","2"); INSERT INTO login VALUES("vivek","vivek","2");

INSERT INTO login VALUES("sekar","sekar","3"); INSERT INTO login VALUES("sekar","sekar","3");

INSERT INTO login VALUES("srinu","srinu","1"); INSERT INTO login VALUES("srinu","srinu","1");

INSERT INTO login VALUES("swami","swami","2"); INSERT INTO login VALUES("swami","swami","2");

INSERT INTO login VALUES("pradep","pradep","3"); INSERT INTO login VALUES("pradep","pradep","3");

INSERT INTO login VALUES("sehwag","sehwag","3"); INSERT INTO login VALUES("sehwag","sehwag","3");

INSERT INTO login VALUES("yuvi","yuvi","2"); INSERT INTO login VALUES("yuvi","yuvi","2");

# #

import org.dao.DBDAO; import org.dao.DBDAO;

public cl

public class ass AdminLogin AdminLogin extends Hextends HttpServletttpServlet

{{ /** /** * * */ */

private static final long serialVersionUID = 1L; private static final long serialVersionUID = 1L;

public void doGet( HttpServletRequest request,HttpServletResponse res) public void doGet( HttpServletRequest request,HttpServletResponse res)

(40)

doPost(request,res); doPost(request,res);

}}

public void doPo

public void doPost( HttpServletRequest request,HttpServlst( HttpServletRequest request,HttpServletResponse res)etResponse res)

{{ Connection con=null; Connection con=null; Statement st=null; Statement st=null; PrintWri

PrintWriter ter pw=null;pw=null;

ResultSet rs=null; ResultSet rs=null; try try {{ pw=res.getWriter(); pw=res.getWriter();

DBDAO dao1= new DBDAO(); DBDAO dao1= new DBDAO();

con=dao1.getCon(); con=dao1.getCon();

st =con.createStatement(); st =con.createStatement();

rs=st.executeQuery("s

rs=st.executeQuery("select elect * from product_info1");* from product_info1");

pw.println("<html>"); pw.println("<html>");

pw.println("<table border=2 color = gray>"); pw.println("<table border=2 color = gray>");

pw.println("<tr>"); pw.println("<tr>");

pw.println("<center>"); pw.println("<center>");

pw.println(" <h4><font color=red>"+"complaint details"+" </h4></font>"); pw.println(" <h4><font color=red>"+"complaint details"+" </h4></font>");

pw.println("</center>"); pw.println("</center>");