Online Complaint Management System

2.3 Module Description 04 2.4 Reports 05

3

REVIEW OF THE STATE OF ART 07

3.1 Feasibility Study 07 3.1.1 Economical Feasibility Feasibility 07 3.1.2 Operational Feasibility 07 3.1.3 Technical Feasibility 07

3.2 Software Requirements Specifications 08 3.3 Nonfunctional Requirements 09 3.4 System Process Model 10

4

SYSTEM DESIGN 18

4.1 ER Diagram 18 �������������

���� �

4.2 Data Dictionary 18 4.3 Data Flow Diagrams 20 4.4 Unified Modeling Language 21 4.4.1 Use Case Diagram D iagram 23 4.4.2 Activity Diagram 26 4.4.3 Collaboration Diagram 27

4.4.4 Class Diagram

29 4.4.5 Sequence Diagram 30 5

IMPLEMENTATION 32

5.1 Coding 32

6

SYSTEM TESTING 39

6.1 Testing 39 6.2 Testing Strategy 39 6.3 Test Approach 43 6.4 Test Cases 44 �������������

���� �

7

SCREEN SHOTS

47

7.1 Screens 47

8

CONCLUSION 57

8.1 Summary 57 8.2 Future enhancements 58

REFERENCES 59

LIST OF ACRONYMS S NO Page No

Acronym

1 Requirement Specification 2 Diagram 3 Modeling Language

�������������

SRS

Description Software

08 DFD

Data Flow

19 UML

Unified

20

���� �

LIST OF FIGURES AND TABLES LIST OF FIGURES S NO

Figure No Page No

Figure Name

1 10

3.1

Spiral Model

2

3.2

Designing Stage D iagram

3

3.3

Development Stage

12 13

Diagram

4

3.4

5

3.5

6

4.1

7

4.2

Use Case Diagram

8

4.3

Activity Activity Diagram

9

4.4

Class Diagram Diagra m

Integration Stage

14 Installation Installation & Acceptance

15 ER Diagram

17

23

25

28

LIST OF TABLES S NO

1

Table Number Page No 4.1

Table Name

Product Information Information

19

�������������

���� �

2

4.2

Complaint Details 19

ABSRACT 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 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 an independent application. It is a self-contained product. The traditional forum system consists of public meeting or presentation involving 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 forum, Freedom forum, Software forum etc. In particular, Consumer Forum deals with customer rights against vendors or the manufactures o f the faulty products. 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 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. Hence, making the work easy for both the complaint raiser and the person who resolves the complaint. Here, in complaint tracking, it fulfills fulfills different requirements of of administrator and customer more effici e fficiently. ently.

Key Words: Consumer Forum, Economic Forum, Web Enabled Call Center (WECC), Fault Product, Freedom Forum, Software So ftware Forum. �������������

���� �

CHAPTER1 INTRODUCTION 1.1 Introduction

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 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 will get tracked to closure. The person handling the complaint will have the facility to communicate with the customer via emails through t he system. 1.2 Product Perspective

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

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

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 functionality provided by the system like displaying error messages should adapt itself to the different users of the software. 1.2.3 Software Interfaces

Operating System

:

Any Windows OS.

Client Software

:

Any Web Browser (Internet Explorer).

Communication Network

:

Internet.

�������������

���� �

Intermediate Language

:

JVM.

1.2.4 Memory Constraints

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

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 changes in his reservation or cancel a reservation. These must also be back up of data to enable any easy recovery from any features. 1.3 Site Adaptive Requirements

The “OCMS” software is an independent and self-contained product and no modification are required to adapt to a particular installation. Product Functions

•

The major functions include

•

Providing product complaint details

•

Complaint registration for for a particular product id, date and time and also also providing with a pin code as a customer address.

•

Allowing the customer to view sstatus of the complaint.

•

Displaying a report of the number of o f complaints for a particular product.

Advantages: �������������

���� �

•

Very less time required.

•

Very less cost.

•

Risk is low.

•

No technical knowledge is needed for the user.

•

Easy to maintain

CHAPTER2 �������������

���� �

LITERATURE SURVEY 2.1 Introduction: 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 of expert committee along with judge. The final decision making is a time consuming so the customer has to revisit the forum to get the result.

2.2 Proposed System: 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 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 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 efficiently. The specific purpose of the system is to gather and resolve complaints that arise in different projects handled by the o rganization.

2.3 Existing System: The traditional forum system consists of public meeting or presentation involving 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 forum, Freedom forum, Software forum etc. In particular, Consumer Forum deals with customer rights against vendors or the manufactures of the faulty products. Disadvantages of Existing System:

The customer has to visit forums and made co mplaint mplaint against aga inst a faulty product. The complaint will be discussed in the presence of customer, vendor and a team of expert committee along with judge. The T he final decision making is a time consuming so t he customer has to revisit the forum to get t he result. �������������

���� ��

The site would use a database to hold customers complaints and reports generated by the technical team tea m .online compliant management system contains conta ins all complaint details .a complaint complaint inventory contains all complaints with with its status reports .the system provides the facility if the customers gives the wrong information t hen he ���� edit the complaint details .to provide provide the proper information to the system. system. The modern modern online complaint management system system is comprehensive suite suite of identify the fault fault products based on the customers provided information and generating reports for the fault products.

2.4 Module Description: 2.4.1 Registration Module:

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 sub processes in which one registers the complete details of the customer who wants to submit the compliant, other registers the complete details of the compliant 2.4.2 Monitoring Module:

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 is divided into two sub processes in which one searches for complaints and other updates the status. 2.4.3 Reports Module:

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 processes in which one gives g ives summary report other gives the detailed report.

2.4.4 Administration Module:

�������������

���� ��

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

2.5 Reports: 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 this project are as mentioned below. 2.5.1 Time oriented reports:

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 reports on certain period of o f time etc. 2.5.2 Status oriented reports:

Status oriented reports give the information of complaints according to the status given. The status oriented reports are completed, pending and delayed reports. repo rts. 2.5.3 Division wise reports:

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

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

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

�������������

���� ��

CHAPTER3 REVIEW OF THE STATE OF ART

3.1 FEASIBILITY STUDY Feasibility study study is an important phase phase in the software development development process. It enables the developer to have have an assessment of the product being developed. It refers refers to the feasibility study of the product in terms of outcomes of the product, operational use and technical support required for implementing it. Feasibility study should be performed on the basis of various criteria and parameters. The various feasibility studies are: •

Economic Feasibility

•

Operational Feasibility

•

Technical Feasibility 3.1.1 ECONOMIC FEASIBILITY

It refers to the benefits or outcomes we are deriving from the product as compared to the total cost we are spending spending for developing the product. If the benefits benefits are more or less the same as the older system, then it is not feasible to develop the product. prod uct. 3.1.2 OPERATIONAL FEASIBILITY

It refers to the feasibility feasibility of the product to be operational. Some products may work very well at design and implementation but may fail in the real environment.

It includes includes the study of additional human resource required and their

technical expertise. 3.1.3 TECHNICAL FEASIBILITY

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

�������������

���� ��

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

3.2. SOFTWARE REQUIREMENTS SPECIFICATIONS 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 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 the ideas of the minds of the clients (the i/p) into a formal document (the o/p of the requirement phase).

The SRS phase consists of o f two basic activities:

Problem or requirement Analysis: The process is order and more nebulous of the two, deals with understand the problem, the goal and constraints.

Requirement Specification Here, the focus is on specifying what has been found giving analysis such as representation, specification languages and tools, and checking the specifications are addressed during this activity. The requirement phase terminates with the production of the validate SRS document. Producing the SRS document is the basic goal of this phase. The Software Requirements Specification (SRS) begins the translation 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) and analyzes the situations from a number of perspectives to discover and eliminate inconsistencies,

ambiguities,

and

omissions

before

development

progresses

significantly under mistaken assumptions.

�������������

���� ��

Role of SRS: The Purpose of the software requirement specificati spec ification on is to reduce the communication gap between the clients and developers. Software requirement 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 the parties involved in the system. 3.2.1 Software Requirements:

Operating System

:

Any Windows OS.

Client Program

:

Internet Explorer.

Server Program

:

Apache Tomcat 6.0.

IDE

:

My Eclipse 8.6.

Editors

:

Adobe Dreamweaver, Photoshop.

Language

:

JAVA (JSP & JDBC) & HTML.

Client side Scripting

:

Java script.

Database software’s

:

Oracle10g.

Intermediate Language

:

JVM.

3.2.2 Hardware Requirements:

Processor

:

P4

Ram

:

512 MB

Communication Channel

:

Internet

Hard Disk

:

10 GB

Monitor

:

VGA Color (256)

3.3 Non-functional Requirements: Performance 1. 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 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 reduce this access time). �������������

���� ��

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

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

Reliability 1. OCMS shall be available 24 hours a day, 7 days a week. 2. OCMS shall always provide real time information about flight availability information. 3. OCMS 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 not crash and shall identify ident ify the invalid input and produce a suitable error message. 4.  OCMS shall be able to recover from hardware failures, power failures and other

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

Usability 1.  OCMS shall provide a easy-to-use graphical interface similar to other existing

reservation system so that the users do not have to learn a new style of o f interaction. 2.  The web interface should be intuitive and easily navigable Users should be able to

understand the menu and options provided by OCMS . 3. Any notification or error messages generated by OCMS shall be clear, succinct, polite

and free of jargon.

Integrity 1.  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. dat a. 2. Users need to be authenticated before having access to any personal data.

3.4 System Process Model: The Software Life Cycle

1.

Encompasses all activities from initial analysis unt il obsolescence

2. Formal process for software development a. Describes phases of the development process �������������

���� ��

b. Gives guidelines for how to carry out o ut the phases 3. Development process a. Analysis b. Design c. Implementation d. Testing e. Deployment

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

Specification;

•

Design;

•

Validation;

•

Evolution.

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

process from some particular perspective.

Generic software process models •

The waterfall model and distinct phases of o f specification and development.

•

Evolutionary development

•

Specification, development and validation are interleaved.

•

Component-based software engineering

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 several stages to an implementable design.

Spiral Model 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 �������������

���� ��

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

Figure 3.1 Spiral model Stages in SDLC: ♦

Requirement Gathering

♦

Analysis

♦

Designing

♦

Coding

♦

Testing

♦

Maintenance

3.4.2 Requirements Gathering stage:

The requirements gathering process takes as its input the goals identified in the highlevel 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 intended application, define operational data areas and reference data areas, and define �������������

���� ��

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 and associated with these major functions, data areas, and data entities. Each of these definitions is termed a Requirement. Requirements are identified by unique requirement identifiers and, at minimum, contain a requirement title and textual description. 3.4.3 Analysis Stage:

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 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 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. The minimum information for each goal consists of a title and textual description, although additional information and references to external documents may be included. 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 scheduled activities for the upcoming Requirements stage, and high level estimates of effort for the out stages. 3.4.4 Designing Stage:

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 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 hierarchy diagrams, screen layout diagrams, tables of business rules, business process 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 detail that skilled programmers may develop the t he software with minimal additional input.

�������������

���� ��

Figure: 3.2 Designing Phase 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 the design stage are the design document, an updated RTM, and an updated project plan. 3.4.5 Development (Coding) Stage:

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 artifacts will be produced. Software artifacts include but are not limited to menus, dialogs, data management forms, data reporting formats, and specialized procedures and 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 interactions with the software. so ftware.

�������������

���� ��

Figure: 3.3 Development Stage 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 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 satisfies the requirements and design elements previously documented, an online help 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 describes the test cases to be used to validate the correctness and completeness of the software, an updated RTM, and an updated project plan. 3.4.6 Integration & Test Stage:

During the integration and test stage, the software artifacts, online help, and test data are migrated from the development environment to a separate test environment. At this 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 �������������

���� ��

capability. During this stage, reference data is finalized for production use and 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 compiled into the Production Initiation Plan.

Figure: 3.4 Integration & Test Stage 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 reference data and production users, an acceptance plan which contains the final suite of test cases, and an updated project plan. 3.4.7 Installation & Acceptance Test:

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

�������������

���� ��

are run to verify the correctness and completeness of the software. Successful execution of the test suite is a prerequisi prerequ isite te to acceptance of the software by the custo mer. 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 formally accepts the delivery of the software. so ftware.

Figure: 3.5 Installation & Acceptance Stage St age The primary outputs of the installation and acceptance stage include a production 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 the project schedule and locks the project as a permanent project record. At this point the PDR "locks" the project by architecture architecture software items the implementation map, the source code, and the documentation for future reference. 3.4.8 Maintenance:

Outer rectangle represents maintenance of a project, Maintenance team will start with requirement study, understanding of documentation later employees will be assigned work and they will undergo training on that particular assigned category. �������������

���� ��

CHAPTER4 SYSTEM DESIGN 4.1 ER DIAGRAM

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 and to arrive at the specific requirements in a comprehensive manner. The ER diagram is attached with this SRS.

Figure: 4.1 ER Diagram 4.2 DATA DICTIONARY

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 any anomalies during the course of data entry

�������������

���� ��

Table: 4.1 Product Information

Table: 4.2 Complaint Details

�������������

���� ��

4.3 DATA FLOW DIAGRAMS A data flow diagram ( DFD) is a graphical representation of the "flow" of data through an

information system. system. A data flow flow diagram can also be used used for the

visualization of data processing (structured design). Dataflow diagrams can be used to provide the end user with a physical idea of where the data

they input, ultimately has an effect upon the structure of the whole whole

system from order to dispatch to restock how any system is developed can be determined through a dataflow diagram. 4.3.1 Developing a DFD

Developing Top-Down Approach •

The system designer makes a context level level DFD ,which shows the interaction

(data

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

The system is decomposed in lower level DFD (Zero) into a set of processes, data stores , and the data flows flows between these t hese processes and data stores.

•

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

•

This approach then continues on the subsequent sub processes , until a necessary and sufficient level of detail is reached which is called the primitive process

4.3.2 DFD Symbols

In the DFD, there are four symbols 1. A square defines a source(originator) or destination of system data 2. An arrow identifies identifies data flow. flow. It is the pipeline through which the information flows

�������������

���� ��

3. A circle or a bubble represents a process that transforms incoming data flow into outgoing data flows. 4. An open rectangle is a data dat a store, data at rest or a temporary repository of data

Process that transforms data flow

Source or Destination of data

Data flow

Data Store

4.4 UNIFIED MODELING LANGUAGE (UML) The Unified Modeling language is a standard language for specifying, 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 UML focuses on the conceptual and physical representation of the system. It captures the �������������

���� ��

decisions and understandings about systems that must be constructed. It is used to understand, design, configure, maintain and co ntrol information information about the t he systems. Visualizing:

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 visualize, how the components co mponents of the system communicate and interact with each other. Specifying:

Specifying means building models that are precise, unambiguous and complete UML addresses the specification of all the important analysis design, implementation decisions that must be made in developing and deploying a software system. Constructing:

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 VB. Forward Engineering and Reverse Engineering E ngineering is possible through UML. Documenting:

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

Diagrams in UML: 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 diagrams. These diagrams can be classified c lassified into the following groups.

�������������

���� ��

Static:

1. Class Diagrams. 2. Object Diagrams. 3. Component Diagrams. 4. Deployment Diagrams. Dynamic:

1. Use-Case Diagram. 2. Sequence Diagram 3. Collaboration Diagram. 4. State Chart Diagram 5. Activity Diagram.

4.4.1 USE CASE DIAGRAMS Use case Diagram:

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 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 elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case.

�������������

���� ��

Client Module :

Login

RegisterComplaint

client

viewstatus

Logout

Figure: 4.2 Client Module Use Case Diagram Administrator Module:

Figure: 4.3 Administrator Module Use Case Diagram �������������

���� ��

Technical team module:

Figure: 4.4 Technical Team Module Use Case Diagram

4.4.2 ACTIVITY DIAGRAMS

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 system. It shows the overall flow control.

�������������

���� ��

Administrator Module:

Login\Regi ster fails

success

displayerro rmessage

verfification

Check complaints

view complaints

send compliants to tech team

updtae stauts

Send mails

LogOut

Figure: 4.5 Administrator Module Activity Diagram

�������������

���� ��

Technical team Module:

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

���� ��

4.4.3 Collaboration diagram:

9: commit( ) login : login

10:

1: login( ) Db : DBUtils admin : Adminstartor

2: status( ) 11: logout( 13: sessionClose( s essionClose() ) )

3: openConnection( )

12: closeConnection()

5: report( )

6: createUsers 8: update( )

7: showStatus()

4: searchComplaintDetails( ) logout : Logout mon : MonitorComplaint

Figure: 4.7 Collaboration Diagram

�������������

���� ��

4.4.4 CLASS DIAGRAM

Coustmer productid : String name : String middlename : String lastname : String email_id : String address : String

MonitorComplaint complaintid : String complainttype : String date : Date status() report()

setProductID() setName() setMiddleName() setLastName() setEmail() setAddress() opname()

updatestatus

Adminstartor

isupdated : Boolean

Username : String password : String

updateComplaint()

createusers() createdivisions() opname()

Logout

Checkstatus

RegisterComplaint complainttype description

complaintId : java.lang.String

sessionout : Integer

showComplaints() status() remaider()

logout()

postcomplaint()

DBUtils isLoggedIn : Boolean isSesstionOut : Boolean openConnection() close() searchComplaintDetails() update() commit() sendCompalintDatails() showStatus()

login username : String password : String conformpassword conformpassword : String check()

Figure: 4.7 Class Diagram

�������������

���� ��

4.4.5 SEQUENCE DIAGRAM Customer module :

: Coustmer

: Checkstatus

 : RegisterComplaint

db : DBUtils

postcomplaint( )

checkstatus()

login()

openConnection( )

acknowledgement()

showcomplaintStatus()

rollback rollback ()

update()

commit()

logout

Figure: 4.8 Sequence D Diagram iagram-Customer -Customer Module

�������������

���� ��

Administrator Module:

admin : Adminstartor

login : login

login( )

mon : MonitorComplaint

logout : Logout

Db : DBUtils

status( ) openConnection( )

searchComplaintDe searchComplaintDetails( tails( ) report( ) showStatus()

update( ) commit( )

createUsers logout( ) closeConnection()

sessionClose()

Figure: 4.9 Sequence D Diagram iagram-Administrator -Administrator Module

�������������

���� ��

CHAPTER 5 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 ## Host: localhost Database: Admin #-------------------------------------------------------# Server version 4.0.1-alpha-nt USE schememanager; # # Table structure for table 'applications' # DROP TABLE IF EXISTS applications; CREATE TABLE IF NOT EXISTS applications ( ComID int(11) NOT NULL auto_increment, ProductID int(20) , CusName varchar(50) , CusAddress varchar(255) , CusNo varchar(20) , �������������

���� ��

Status varchar(25) , Remarks varchar(255) , EmailID int(10) , TechID int(10) , ); ## Table structure for table 'login' # DROP TABLE IF EXISTS login; CREATE TABLE IF NOT EXISTS login ( UserID varchar(50) NOT NULL DEFAULT '' , Password varchar(50) NOT NULL DEFAULT '' , Auth int(11) NOT NULL DEFAULT '1' , PRIMARY KEY (UserID) ); # # Dumping data for table 'login' #INSERT INTO login VALUES("admin","admin","0"); INSERT INTO login VALUES("ddo","ddo","2"); INSERT INTO login VALUES("gpo","gpo","1"); INSERT INTO login VALUES("normal","normal","3"); INSERT INTO login VALUES("user","user","3"); �������������

���� ��

INSERT INTO login VALUES("vara","vara","0"); INSERT INTO login VALUES("sunil","sunil","1"); INSERT INTO login VALUES("ramkumar","ramkumar","2"); INSERT INTO login VALUES("anil","anil","0"); INSERT INTO login VALUES("vivek","vivek","2"); INSERT INTO login VALUES("sekar","sekar","3"); INSERT INTO login VALUES("srinu","srinu","1"); INSERT INTO login VALUES("swami","swami","2"); INSERT INTO login VALUES("pradep","pradep","3"); INSERT INTO login VALUES("sehwag","sehwag","3"); INSERT INTO login VALUES("yuvi","yuvi","2"); # import org.dao.DBDAO; public class class AdminLogin extends HttpServlet HttpServlet {  /** * */ private static final long serialVersionUID = 1L; public void doGet( HttpServletRequest request,HttpServletResponse res) { �������������

���� ��

doPost(request,res); } public void doPost( doPo st( HttpServletRequest request,HttpServletResponse request,HttpServletResponse res) { Connection con=null; Statement st=null; PrintWriter PrintWriter pw=null; ResultSet rs=null; try { pw=res.getWriter(); DBDAO dao1= new DBDAO(); con=dao1.getCon(); st =con.createStatement(); rs=st.executeQuery("select rs=st.executeQuery("select * from product_info1"); pw.println(""); pw.println(""); pw.println(""); pw.println(""); pw.println(" "+"complaint details"+" "); pw.println(""); �������������

���� ��

pw.println(""); pw.println(""); pw.println(""+"coustmer id"+""); pw.println(""+"name"+""); pw.println(""+"lastname"+""); pw.println(""+"email"+""); pw.println(""+"address"+""); pw.println(""+"city"+""); pw.println(""+"contact"+""); pw.println(""+"username"+""); pw.println(""+"type"+""); pw.println(""+"puchase"+""); pw.println(""+"fault"+""); pw.println(""+"date"+""); pw.println(""+"status"+""); pw.println(""); while(rs.next()) { pw.println(""); pw.println(""); pw.println(""+rs.getString(10)+""); �������������

���� ��

pw.println(""+rs.getString(11)+""); pw.println(""+rs.getString(12)+""); pw.println(""+rs.getString(13)+""); pw.println(""+rs.getString(15)+""); pw.println(""); pw.println(""); }//while pw.println(""); pw.println(""); pw.println(""+" go back"+""); con.close(); st.close(); }//try catch(Exception e) { pw.println(" user id is wrong:"); e.printStackTrace(); }//catch }//method }//class

�������������

���� ��

Java Script Validations:

JavaScript is the most popular scripting language on the internet, and works in all major browsers, such as Internet Explorer, Firefox, Chrome, Opera, and Safari. •

JavaScript was designed to add interactivity interactivity to HTML pages.

•

JavaScript is a scripting language.

•

A scripting language is a lightweight programming language.

•

JavaScript is usually embedded directly into HTML pages.

•

JavaScript is an interpreted language (means that scripts execute without preliminary compilation).

•

Everyone can use JavaScript without purchasing a license.

•

JavaScript gives HTML designers a programming tool - HTML authors are normally not programmers, but JavaScript is a scripting language with a very simple syntax! Almost anyone can put small "snippets" of code into their HTML pages.

•

JavaScript can put dynamic text into an HTML page - A JavaScript statement like this: document. write("" + name + "") can write a variable text into an HTML page.

•

JavaScript can react to events - A JavaScript can be set to execute when something happens, like when a page has finished loading or when a user clicks on an HTML element.

•

JavaScript can read and write HTML elements - A JavaScript can read and change the content of an HTML element

�������������

���� ��

CHAPTER6 SYSTEM TESTING

6.1 TESTING Testing is the process of detecting errors. Testing performs a very critical role for quality assurance and for ensuring the reliability of software .The results of testing are used later on during maintenance also. TESTING OBJECTIVES

The main objective of testing is to uncover a host of errors, systematically and with minimum effort effort and time. Stating formally, we can say, Testing is a process of executing a program with intent of finding an error a successful test is one that uncovers an as yet undiscovered error. A good test case is one that has a high probability of finding an error, if it exists. The tests are inadequate to detect possibly present errors. The software more or less confirms to the quality and reliable standards.

6.2 TESTING STRATAGIE 1 Unit Testing

Unit testing focuses verification effort on the smallest unit of software i.e. the module. Using the detailed design and the process specification testing is done to uncover errors with in the boundary of the module. All modules must be successful in the unit test. •

Entry module

:

Various cases of errors like like invalid agents etc are verified. verified.

•

Update module

:

The test cases of entry module also apply here along with

View module

:

Only those reports could be viewed that are valid. This

property is

ensured.

update constraints. •

�������������

���� ��

2. System Testing

Here the entire software system is tested. The reference document for this process is the requirements document, and the goal OS to see a software meets its requirements. This project is tested in Linux OS and works well in this OS environment. 3. Acceptance Testing

Acceptance test is performed with realistic data of the client to demonstrate that the software is working satisfactorily. Testing here is focus on external behavior of the system; the internal logic of program is not emphasized. Test cases should be selected so that the largest number of attributes of an equivalence class is exercised at once. The testing phase is an important part of software development .It is the process of finding errors and missing operations and also a complete verification to determine whether the objectives are met and the user requirements are satisfied. Acceptance testing is performed along with the client to show that to see that all requirements are satisfied Whatever may be the attributes its working well provided all the attributes are valid. If not it displays corresponding message for getting valid attributes. 4. White Box Testing

This is the unit testing method where a unit will be taken at a time and tested thoroughly at a statement level to find the maximum possible errors. We tested step wise every piece of code, taking care that every statement in the code is executed at least once, the white box testing is also called GLASS BOX Testing. 5. Black Box Testing

This testing method considers a module as a single unit and checks the unit at interface and communication with other modules rather getting into details as statement level. Here the module will be treated as a black box that will take some

�������������

���� ��

input and generate output. Output for a given set of input combinations are forwarded to other module. We have performed black box testing by taking different combinations of inputs such that the input passed will be t ransferred to different modules and is used correctly.

SYSTEM TEST PLAN

The entire software system is tested. Test Condition

Description of coverage

Expected results

Covered by script

ID

Verification

If a particular record This

of a particular already 1

record

exists

it {$verify}

displays a message

type of test in procedure

in

every jsp file where a record is inserted via an interface.

Updating of a 2

This type of test is All the details should

particular

not be updated.

record

covered in all the jsp files where updations are made.

Validity login 3

of

Only the authorized

This is covered in the

persons must access

login procedure for the

system.

validity of a user.

Table: 6.1 Testing For Entire Software �������������

���� ��

UNIT TEST

The Unit testing checks that one co mponent of a product performs as desired.

Test

description of coverage

Condition

Expected

Script

results

ID

Transaction

1

entries Should

should allow the user to allow

not

Should

not

allow

duplicate records

add the details of the duplicate farmers.

2

records

Transaction

updates

should allow the user to modify some of the details

only

to

The respective fields Updating and etc

be .

are

disabled

allowing

before

them

to

update

updated

Table: 6.2 Unit Testing

INTEGRATION TEST

This testing activity can be considered as testing the design and hence emphasis on testing module interaction.

�������������

���� ��

Condition

Description

of

coverage

Expected results

Covered by script

ID

Completeness 1

of Should

not

allow A proper message has

details: Whether all entering the details if to be displayed for deta ils.. the required values required details are requesting all details are provided or not Correctness

of

Details: 2

not provided. Should not allow to

Proper

message

insert the details if

has to be displayed

the entered details

for

are invalid in terms

exact details.

requesting

of date or entry method Transfer of data: Should

not

allow

Whether the data duplicate values to be given 3

is

being transferred.

Message has to be displayed

after

transferring

data

transferred

between modules is

between modules

complete.

correctly without any loss or not.

4

Report

Should

Generation:

duplicate reports.

Whether

not

the

reports generated

allow

Verification procedure is done while

generating

the reports.

are containing the correct results are not to be checked. Table: 6.3 Integration Test �������������

���� ��

Testing commence with a test plan and terminates with acceptance testing. Test plan is a general document for the entire project that defines the scope, approach to be taken and the schedule of testing as well identifies the test item for the entire testing process and the personal responsible for the different activities of testing. The test planning can be done in parallel with the coding and design phases. The inputs forming the test plan are Test unit specification •

Features to be tested

•

Approaches for testing

•

Test deliverables

•

Schedule

•

Personal allocation One of the most important activities of the test plan is to identify the test

units. Test Plan Document

A test plan is a general document for a entire project, which defines the scope, approach to be taken and the schedule of testing, as well as identifying the test items for entire testing process and the personal responsible for the different activities of testing. A test plan should contain the following: Test Unit Specification

A test unit is a set of one or more modules together with associated data which are from a single program pro gram and which are the object of o f testing. Features to Be Tested

Features to be tested include all software features and combination of features that should be tested. A software feature is software characteristics specified or simplified by the requirements of design documents. These may include functionality, performance, design constraints and attributes. �������������

���� ��

All the functional features specified in the requirements document are tested .No testing will be done for the performance. APPROACH FOR TESTING

The approach for testing specifies the overall approach to be followed in the current project. This is sometimes called testing criteria. All the tastings are done one by one in an order as mentioned above. Test Deliverables

Testing deliverables should be specified the test plan, before the actual testing begins. Deliverables could be a list of test cases that were user detail results of testing. Test summary report, test log and data about the code coverage. Various cases of errors like non-existent can, invalid agents etc. are verified .All the update constraints must be satisfied. Only those reports could be viewed that are valid. This property is ensured. A completely working code without errors will be provided ie. Satisfying all their requirements. Schedule

The test log provides chronological record of relevant details about the execution of test case. Different activities of testing and testing of different units that have identified. Different test cases are identified and applied to each module of the project do that each and every case of the project is verified correctly and is working well. Personal Allocation

Personal allocation identifies the person responsible for performing the different activities. In our project the person responsible for performing different activities differs from time to time. t ime.

�������������

���� ��

6.3 TEST APPROACH

Testing can be done in two ways: Bottom up approach

•

Top down approach

•

Bottom up approach

Testing can be performed starting from smallest and lowest level modules and proceeding one

at a time for each module in bottom up testing a short program program

executes the module and provides the needed data so that the module is asked to perform the way it will when embedded within the larger system. When the bottom level modules are tested attention turn to those on the next level that use the lower level once they are tested individually and then linked with a previously examined lower level modules.

Top down approach

This type of testing starts from upper level modules. Since the detailed activities usually performed in the lower level routines are not provided stubs are written.

�������������

���� ��

6.4 TEST CASES Administrator module:

Table: 6.4 Test Case For Administrator Module �������������

���� ��

Client Module:

Table: 6.5 Test Case for Client Module Modu le

�������������

���� ��

CHAPTER7 SCREEN SHOTS

This Section deals with the User Interfaces. In this project there are few Graphical User Interfaces which gives esteemed interaction to the user without explicit knowledge about the background programs.

7.1 Screens

Figure: 7.1 Home Page of the Software S oftware �������������

���� ��

Registration:

Figure: 7.2 Registration Form To Complaint about any faulty product, the Customer need to register first. Then the above screen appears to the Customer. The Customer has to fill the details of the registration Form.

�������������

���� ��

Administrator Login

Figure: 7.3 Administrator Login Page

The above screen shows that administrator login to the site. The administrator has full control on the site. By entering user id and password the administrator page will be open. �������������

���� ��

Forgot password for Customer module:

Figure: 7.4 Customer Login

The above screen tells about the Customer Login .Similarly Administrator every user or customer has his/her own user id and password. After entering the user id and password the user interface will appear on o n the console.

�������������

���� ��

Customer Complaint editing:

Figure: 7.5 Complaint Editing

The above screen tells about the customer complaint editing. The customer can edit his/her complaint easily. To edit users their own complaint, first they need to enter their user id and password to access their user interface.

�������������

���� ��

Check status:

Figure: 7.6 Complaint Status

The above figure tells about the user’s or customer’s complaints status. Whether the complaint has solved successfully or not. To know the complaint status user or customer has to login in the site by e ntering user id and password. �������������

���� ��

Administrator Activities:

Figure: 7.7 Administrator Activities Activities The above figure tells about the administrator the Administrator Activities in this project. The Administrator has several activities in this project like to see all complaints, send to technical team, add vendor, delete complaints, update complaints, status oriented reports, date oriented reports, see all vendors. �������������

���� ��

Check complaints:

Figure: 7.8 Check Customer Complaints Delete compliant:

Figure: 7.9 Delete Complaint �������������

���� ��

Forward complaint to technical team:

Figure: 7.10 Forward to technical Team The above figure tells about the Administrator activities. The administrator forwards the complaint to the technical team, to check the complaint and to solve the complaint.

�������������

���� ��

Technical team Module:

Figure: 7.11 Technical team login page

�������������

���� ��

CHAPTER8 CONCLUSION 8.1 Summary It meets the information requirements specified to a great extent. The system has been designed keeping in view the present and future requirements in mind and made very flexible. The system has been divided in modules so that each module has a separate entity making the modifications easy without affecting its design. There is always room for improvements in software, however efficient it may be. The CRM for online compliant management system is a web-based application for primarily providing training to the employees who provide customized solutions to meet organizational needs. This application software has been computed successfully and was also tested successfully by taking “test cases”. It is user friendly, and has required options, which can be utilized by the user to perform the desired operations. The software is developed using Java as front end and Oracle as back end in Windows environment. The goals that are achieved by the software are: •

Instant access.

•

Improved productivity.

•

Optimum utilization of resources.

•

Efficient management of records.

•

Simplification of the operations.

•

Less processing time and getting required information.

•

User friendly.

•

Portable and flexible for further enhancement.

�������������

���� ��

8.2 Future Enhancements Some of the future enhancements that can be done to this system are: OMS shall be made more more flexible in complaint registration handling, handling, and it will save time .The registration handling capability of OMS shall be made more advanced, by enabling it to send requests requests to the complaint registration registration to make a complaint ,and assign the customer id to each customer based on the complaint registration .

•

The telephonic interface of the OMS shall be improved to support more functionality like allowing the customers to customer customer updates

etc., by

incorporating security measures.

•

OMS shall be made more dynamic and helpful to the users by enabling it to send instant messages to the customers , of a cancelled or rescheduled flight, through email, phone, fax etc., informing them about the change, and providing them with other feasible alternatives.

•

At present one customer can able compliant only on one product at a time in the feature for any number number of products he can able to give the complaint complaint .

•

Provide service integration with auto rental agencies and hotel chains

•

Interface for the travel agents shall be provided in the future versions with additional features like informing them of any availability of seats on a flight which was earlier booked to capacity.

•

Customers can able to see the compliant processing in until which it is processed.The OMS shall be able to handle the situation where the fault products are avilable in in the surroundings

�������������

���� ��

REFERENCES

[1] www.oraclesun.com. [2] www.w3schools.com. [3] H. Kim, Kim, P. Howland, and H. Park, “Dimension Reduction in in TextClassification TextClassification with Support Vector Machines,” J. Machine Learning Research, vol. 6, pp. 37-53, 2005. [4] F. Sebastiani, Sebastiani, “Machine Learning in Automated Text Categorization,” Categorization,” ACM Computing Surveys, vol. 34, no. 1, pp. 1-47, 2002 [5]

B.Y. Ricardo Ricardo and R.N. Berthier, Modern Information Information Retrieval. Retrieval. Addison Addison

Wesley Longman, 1999 [6] A.L. Blum and P. Langley, “Selection of Relevant Features and Examples in Machine Learning,” Aritficial Intelligence, vol. 97, nos. 1/2, pp. 245-271, 1997. [7]

E.F. Combarro, Combarro, E. Montan˜ Montan˜ e´s, e´s, I. Dı´az, Dı´az, J. Ranilla, and R. Mones,

“Introducing a Family of Linear Measures for Feature Selection in Text Categorization,” IEEE Trans. Trans. Knowledge and Data Eng., vol. 17, no. 9, pp. 12231232, Sept. 2005. [8] K. Daphne and M. Sahami, Sahami, “Toward Optimal Feature Selection,” Proc. 13th 13th Int’l Conf. Machine Learning, pp. 284-292, 1996. [9] R. Kohavi and G. John, “Wrappers for for Feature Subset Selection,” Aritficial Aritficial Intelligence, vol. 97, no. 1-2, pp. 273-324, 1997. [10] Y. Yang and J.O. Pedersen, “A Comparative Study on Feature Selection in Text Categorization,” Proc. 14th Int’l Conf. Machine Learning, pp. 412-420, 1997. [11]

D.D. Lewis, “Feature Selection and Feature Feature Extraction for Text

Categorization,” Proc. Workshop Speech and Natural Language, pp. 212-217, 1992 [12] H. Li, Li, T. Jiang, and K. K. Zang, “Efficient “Efficient and Robust Feature Feature Extraction by Maximum Margin Criterion,” T. Sebastian, S.Lawrence, and S. Bernhard eds. Advances in Neural Information Processing System, pp. 97-104 , Springer, 2004. [13] E. Oja, Sub Methods of Pattern Recognition. Research Studies Studies Press, 1983. �������������

���� ��