Complaint Management System Miniproject (16mca47)

COMPLAINT MANAGEMENT SYSTEM Miniproject [16MCA47]
CHAPTER 1
INTRODUCTION:
1.1 OBJECTIVE:
An effective complaints management system is integral to providing quality customer service. It

helps to measure customer satisfaction and is a useful source of information and feedback for
improving services. Often customers are the first to identify when things are not working
properly.
The project tries to accomplish all the following features:

1) Smooth flow of data without any hurdles.
2) Adequate validation checks for data entry.
3) Adequate security of data.
4) Facility to update data from time to time.
5) Prompt and specific retrieval of data.
6) Flexibility in the system according to the changing environment.
7) Controlling redundancy in storing the same data multiple times.
8) Accuracy, timeliness and comprehensiveness of the system output.
9) Stability and operability by people of average intelligence.
10) Enhancement in the completion of work within the constraints of time.
The scope of the system is quite wide. It can be implemented on a WAP-enabled mobile handset,
thus providing the Customers and the Providers, the ease of accessing the projects and their
status without any difficulty and within no time.
Admin Panel
1. Admin Login: Admin can login through login form.
2. Category: Admin can manage categories (Add, update, delete)
3. Sub Category: Admin can manage Subcategories (Add, update, delete)
4. State: Admin can manage states (Add, update, delete)
5. Manage Complaints: Access Complaint info, Change Complaint status.
1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 1

6. Manage the Users: Admin can manage the all the Users Profile. Take a print out of all
profiles.
7. Userslog: Admin can also view user log information.
8. Change Password: Admin can own password.
User Panel
1. User Registration: User can register through user registration form

2. User Login: User can login through login form
3. Forgot Password:User can retrieve password through forgot password link
4. User Dashboard: User can view the on process of complaint details lodged weather it is
processing, processed and closed.
5. User Profile: User can manage own profile
6. Lodge Complaint: User can Lodge his/her Complaint.
7. Complaint History: User can view lodged complaint and status.
8. Change Password: User Can change own password.
1.2 SCOPE OF THE PROJECT:
 The application is made as simple as surfing a website. There by non-technical

persons can also interact with the processing on the application easily.
 Provides instant information regarding the work under process regarding the
complaint.
 Easy management of data as located at a server.

CHAPTER 2
REQUIREMENT SPECIFICATION:
2.1 HARDWARE REQUIREMENT:
Processor : Pentium 4
RAM : 256MB
Hard disk : 80 GB or more
Monitor : 15CRT or LCD monitor
Keyboard : Normal or Multimedia
Mouse : Compatible mouse
2.2 SOFTWARE REQUIREMENT:
Front End : PHP Script
Back End : MySQL
Browser : Firefox, Chrome, IE or any other
Operating System : Windows Xp/Above
Tools : Notepad ++
Server : XAMPP Server to host the web-page.

CHAPTER 3
SOFTWARE REQUIREMENTS SPECIFICATION
3.1 FUNCTION REQUIREMENTS:
The functional requirements specify relationship between the inputs and outputs. All the
operations to be performed on the input data to obtain output are to be specified. This includes
specifying the validity checks on the input and output data, parameters affected by the operations
and the other operations, which must be used to transform the inputs into outputs. Functional
requirements specify the behavior of the system for valid input and outputs.
The complete system can be divided into three halves on basis of access levels.
A) Administrator
B) User
Administrator:
An administrator is the main controller of the application. When compared to
other types of users an administrator has an additional privilege to acess new
complaints manage applications and provide notifications. The user management
sections involve creating new users and managing existing users in terms of
privilege given to them and changing passwords.Application configuration
involves placing the complaint list category with a status values. The different
statuses are processing, processed and closed etc.
User:
A User is a restricted member of the application where in the user has no
privileges to change the status of the complaint or placement of the application
from one category to other category. A User can only be able to register and lodge
the complaint and can view the status of the complaint.
1. Admin:
Administrator in the operator who will take care of the system.
 Login.
 Logout.
 Change password.
 Manage the Task.
 Manage the User.
 View the User details, Complaint and Update the status.

1. User:
 Login.
 Logout.
 Change Password.
 Lodge the complaint
 View the complaint history and the status
3.2 NONFUNCTION REQUIREMENTS:
3.2.1 RELIABILITY REQUIREMENTS:
The Performance and response rate of the system should remain constant even as the
number of concurrent users or data levels increase. Architecture used to build the system should
be flexible enough to allow integration with other systems if need be in the future.
3.2.2 USABILITY REQUIREMENTS:
The system should have an attractive, user friendly and interactive graphical user
interface and it should be easy to use even with the person with least knowledge of
computers.
3.2.3 SECURITY REQUIREMENTS:
This system must be highly secured in the login part. This is because some of the
privileges are only allowed for the admin level.
3.2.4 IMPLEMENTATION REQUIREMENTS:
In implementing the system, it uses php, html, cascading style sheet as the main
programming language and tools. This forms the front-end and the middleware at the back-end,
MYSQL is used to maintain the information in the database. This is formed by the databases and
other data stores.
3.2.5 PORTABILITY REQUIREMENT:
The system needs to be portable on all major platforms. This system should not be restricted by
any specific technology such as database, web server and operating system.

CHAPTER 4
SYSTEM ANALYSIS
4.1 EXISTING SYSTEM
This software has been developed for a company concerning all the details given by company.
By this software anyone can handle customer complaint details without any difficulty. To
maintain customer complaint details and to generate the complaint report to the clients they have
to maintain the following information in various files:
In the first file they record the client’s personnel information, such as client code, client name,
address, etc. this details are entered in this file when the new client comes into the organization.
The second file is used to record the product details of each individual product, this file, this file
contain the detail like the product code and all other details concerning about products.
4.2 LIMITATION ON EXISTING SYSTEM

Identification of the drawbacks of the existing system leads to the designing of
computerized system that will be compatible to the existing system with the system which is
more user friendly and more GUI oriented. We can improve the efficiency of the system, thus
overcome the following drawbacks of the existing system.
 more human error.
 more strength and strain of manual labour needed
 Repetition of the same procedures.
 low security
 Data redundancy
 difficult to handle
 difficult to update data
 Record keeping is difficult
 Backup data can be easily generated

4.3 PURPOSE OF THE PROJECT

 To develop a common interface for different sections of the firm.
 The system should provide help in managing different complaints as well as the
user associated with the complaint.
 Instant status of involvements of a user regarding the complaint.
 Security to the confidential information.
 Reduce the redundancy of making the entries of the activities which are done
manually.
 To speed up the processing based on the user complaints.

CHAPTER 5
SYSTEM DESIGN:
The system design is divided in to two portions. The Administrator section and the Usersection.
Administrator
1. The Administrator can manage all user and complaints.
2. He can access complaint info and change the status of complaints.
3. He can control the status of the complaints.
A process of converting user originated inputs to a computer-based format. Input design is an

important part of development process since inaccurate input data are the most common cause of errors in
data processing. Erroneous entries can be controlled by input design. It consists of developing
specifications and procedures for entering data into a system and must be in simple format. The goal of
input data design is to make data entry as easy, logical and free from errors as possible. In input data
design, we design the source document that capture the data and then select the media used to enter them
into the computer.
There are two major approaches for entering data in to the computer. They are
· Menus.
· Dialog Boxes.
Menus
A menu is a selection list that simplifies computer data access or entry. Instead of
remembering what to enter, the user chooses from a list of options. A menu limits a user choice
of response but reduce the chances for error in data entry.
Dialog Box
Dialog boxes are windows and these windows are mainly popup, which appear in response
to certain conditions that occur when a program is run. It allows the display of bitmaps and
pictures. It can have various controls like buttons, text boxes, list boxes and combo boxes. Using
these controls we can make a ‘dialog’ with the program.
The proposed system has three major inputs. They are Machine Registration, Machine
Scheduling and Request Form.

Process Design
Process design plays an important role in project development. In order to understand the
working procedure, process design is necessary. Data Flow Diagram and System Flow chart are
the tools used for process design.
System Flow Chart is a graphical representation of the system showing the overall flow of
controlin processing at the job level; specifies what activities must be done to convert from a
physical to logical model.
Data Flow Diagram is the logical representation of the data flow of the project. The DFD
isdrawn using various symbols. It has a source and a destination. The process is represented
using circles and source and destination are represented using squares. The data flow is
represented using arrows. One reader can easily get the idea about the project through
Data Flow Diagram.

5.1 USE CASE DIAGRAMS
FIGURE:1 USE CASE DIAGRAM FOR USER
FIGURE:2. USE CASE DIAGRAM FOR ADMIN

5.2 DATA FLOW DIAGRAM
Applicant
Complaint
Manageme
nt
Administrator
FIGURE:3 DFD

5.3 E-R DIAGRAM:
An ER model is typically implemented as a database. In the case of a relational database, which

stores data in tables, every row of each table represents one instance of an entity. Some data
fields in these tables point to indexes in other tables; such pointers represent the relationships.
COM_TYPE
DATE AND TIME
USERNAME COM_STATUS
PH.NO
COMPLAINT_ID
PASSWORD
NAME
N N
M
1
N
NAME
N M
1
CHANGE PASS
PASSWORD UPDATE
FIGURE 4: E-R DIAGRAM

CHAPTER 6
IMPLEMENTATIONS
6.1 SOURCE CODE:
1. Index page
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="">
<meta name="author" content="">
<title>Complaint Management System</title>
<link href="css/bootstrap.min.css" rel="stylesheet">
<link href="css/half-slider.css" rel="stylesheet">
</head>
<body>

<nav class="navbar navbar-inverse navbar-fixed-top" role="navigation">
<div class="container">

<div class="navbar-header">

<button type="button" class="navbar-toggle" data-toggle="collapse" data-

target="#bs-example-navbar-collapse-1">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="#">Complaint Management Sysytem</a>
</div>

<div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1">
<ul class="nav navbar-nav">
<li>
<a href="http://localhost/cms/users/">User Login</a>
</li>
<li>
<a href="http://localhost/cms/users/registration.php">User Registration</a>
</li>
<li>
<a href="http://localhost/cms/admin/">admin</a>
</li>
</ul>
</div>

</div>


</nav>

<header id="myCarousel" class="carousel slide">

<ol class="carousel-indicators">
<li data-target="#myCarousel" data-slide-to="0" class="active"></li>
<li data-target="#myCarousel" data-slide-to="1"></li>
<li data-target="#myCarousel" data-slide-to="2"></li>
</ol>

<div class="carousel-inner">
<div class="item active">

<div class="fill" style="background-

image:url('http://localhost/cms/img/c2.png');"></div>
<div class="carousel-caption">
</div>
</div>
<div class="item">

<div class="fill" style="background-

image:url('http://localhost/cms/img/c1.jpg');"></div>
<div class="carousel-caption">
</div>
</div>

</div>

<a class="left carousel-control" href="#myCarousel" data-slide="prev">
<span class="icon-prev"></span>
</a>
<a class="right carousel-control" href="#myCarousel" data-slide="next">
<span class="icon-next"></span>
</a>
</header>

<div class="container">
<div class="row">
<div class="col-lg-12">
<h1>Complaint Management System</h1>
</div>
</div>
<hr>

<footer>
<div class="row">
<div class="col-lg-12">
<p>Copyright © <a

href="http://www.phpgurukul.com/">PHPGURUKUL</a> | Complaint
Management System 2017</p>
</div>
</div>


</footer>
</div>


<script src="js/jquery.js"></script>

<script src="js/bootstrap.min.js"></script>

<script>
$('.carousel').carousel({
interval: 5000 //changes the speed
})
</script>
</body>
</html>

CHAPTER 7
TESTING
Testing is the process of executing then programs with the intention of finding out errors. During
the process, the project is executed with set of test and the output of the website is evaluated to
determine if the project is performing as expected. Testing makes a logical assumption that if all
the parts of the module are correct then goal will be successfully achieved. Testing includes after
the completion of the coding phase. The project was tested from the very beginning and also at
each step by entering different type of data. In the testing phase some mistakes were found,
which did not come to knowledge at the time of coding the project. Then changes were made in
the project coding so that it may take all the relevant data and gives the required result. All the
forms were tested one by one and made all the required changes.
Testing is vital to the success of the system. Testing makes a logical assumption that if all the
parts of the system are correct, the goal will be successfully achieved. A small system error can
conceivably explode into a much larger problem. Effective testing early in the process translates
directly into long-term cost savings from a reduced number of errors. For the verification and
validation of data various-nesting task are performed. Testing is itself capable of finding the
syntactical mistakes in the system but user need to test the system for logical checking.
7.1 LEVELS OF TESTING:
The aim of the testing process is to identify all the defects in the website. It is not practical to test
the website with respect to each value that the input request data may assume. Testing provides a
practical way of reducing defects in the website and increasing the user’s confidence in a
developed system. Testing consists of subjecting the website to a set of test inputs and observing
if the program behaves as expected. If the program fails to Testing behave as expected then
conditions under which failure occurs are noted for later debugging and correction. The
following things are associated with testing:
Failure is a manifestation of an error. But the mere presence of an error may not necessarily lead
to a failure. A test case is the triplet [I, S, O] where I am data input to the system. S is the state of

the state of the system at which the data is input, O is the expected output of the system A test
suite is the set of all test cases with which a given software product is to be tested.
7.2 FUCTIONAL TESTING:
Here the system is a black box whose behavior is determined by studying its inputs and related
outputs. The key problem is to select the inputs that have a huge probability of being members of
a set-in may case; the selection of these test cases is based on the previous studies.
7.3 STRUCTURAL TESTING:
A great deal can be learnt about the strength and the limitation of the application by examinee
the manner in which the system breaks. This type of testing has two limitations.
It tests failure behavior of the system circumstances may arise through an unexpected
combination of events where the node placed on the system exceeds the max. anticipated load.
The structure of each module was checked at every step. Some structures were firstly wrong,
which came to notice at the time of the connectivity.
7.4 UNIT TESTING:
In unit testing the entire individual functions and modules were tested independently. By
following this strategy all the error in coding were identified and corrected. This method was
applied in combination with the white and black box testing techniques to find the errors in each
module.
Unit testing is normally considered an adjunct to the coding step. Unit test case design was
started after source level code had been developed, reviewed, and verified for correct syntax.

Test Cases
Test Test Test Steps Test Data Expected Actual Status

Case ID Scenario Result Result
T1 Check 1.enter user UserId=chethan User User Pass
custome id should successfull
r login Password=1234 login into y logged
with 2.enter the into
valid password application application
data 3.click
submit
T2 Add 1.enter email Username=shash User added User Pass

User i143 successfull
2.enter y added
Password Password=1234
3.Group
4.Position
T3 Add 1.Group Group=networkin Group Group Pass

Group g added created
2.Add Successfull
y
T4 Registra 1,Signup Supply each field Registratio User Pass

tion n registered
2.enert Successful successfull
details y
3.register
4.verify
T5 Verify 1.email Email=chethanku Verified verified Pass

mar22@gmail.co successfull
2.verification m y
code
Verification
3.verify code=2323

CHAPTER 8
SCREEN SHOTS:
 Home Page
It is Home page it has a User login, User Registration and Admin login pages
FIGURE 5: HOME PAGE

 Admin Login Page

It is an admin login home page if entered admin username and password u will be
allowed access the details regarding the complaints.
FIGURE 6 ADMIN LOGIN
 Request processing Page

Request processing page contains the details of the complaints lodged and the request can be
processed by the admin as closed, processed and processing.
FIGURE 7:REQUEST PROCESSING PAGE

 Admin User managing

It enables the admin view the user complaint details and take the action.
FIGURE 8 : ADMIN USER MANAGING PAGE
 User registration page

User can register the details where they can use these details to login and lodge the
complaints.
FIGURE 9 :USER REGISTRATION PAGE

 Lodge complaint page

User can lodge the complaint and can upload the image or the document format based on
nature of their complaint lodged.
FIGURE 10: LODGE COMPLAINT PAGE
 Complaint History
The user can view their complaint history and the status of the complaint.
FIGURE 11: COMPLAINT HISTORY

 User dashboard
In this page the user can be able to view the status of the complaint, weather the
complaint is been processed, closed and are in processing stage.
FIGURE 12: USER DASHBOARD PAGE
 Admin User Log Page

In this page the admin can be able to view the login and logout details of the user.
FIGURE 13: ADMIN USER LOG PAGE

 Admin add category

The admin can add the new category and its discrption.
FIGURE 14: ADMIN ADD CATEGORY PAGE
 User change password

The user can change the password, If he/she wanted to change the password.
FIGURE 15: USER CHANGE PASSWORD PAGE

CHAPTER 9
CONCLUSIONS:
The project has been appreciated by all the users in the organization and user-friendly
screens are provided, it is easy to use, since it uses the GUI provided in the user dialog
and the usage of software increases the efficiency, decreases the effort, It has been
efficiently employed as a Complaint Management System. And It has been thoroughly
tested and implemented.
9.1 FUTURE ENHANCEMENT:
 The application is capable of managing only complaints and the complaint status
are managed. The processed application is still not notified to the user by
message.
 The application can improve in the areas of message communication and
document preservation as well as client maintenance.
 The application can be converted into a Mobile based using ASP.net with which
the deployment of application will be done only on enterprises server and is
accessible to all the users and the organization. The current application is
confined to only one enterprise.

CHAPTER 10
BIBLIOGRAPHY
REFERENCES:
10.1 WEBSITES:
 http://www.w3schools.com/php/php_mysql_intro.asp .
 https://jquery.com/download/
 http://www.w3schools.com/js/js_validation.asp .
10.2 BOOKS:
SOFTWARE ENGINEERING
 By Roger SPressman, Software Engineering: A Practitioner's Approach, 7th edition,

McGraw-hill,2005.
 Chris Bates” Web Programming” Wiley 2000.
 Ian Sommerville “Software Engineering” Person2005.
 Online book references and notes.

Complaint Management System Miniproject (16mca47)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Complaint Management System Miniproject (16mca47)

Uploaded by

Copyright:

Available Formats

COMPLAINT MANAGEMENT SYSTEM Miniproject [16MCA47]

An effective complaints management system is integral to providing quality customer service. It

The project tries to accomplish all the following features:

2. Category: Admin can manage categories (Add, update, delete)

3. Sub Category: Admin can manage Subcategories (Add, update, delete)

4. State: Admin can manage states (Add, update, delete)

5. Manage Complaints: Access Complaint info, Change Complaint status.

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 1

7. Userslog: Admin can also view user log information.

8. Change Password: Admin can own password.

1. User Registration: User can register through user registration form

1.2 SCOPE OF THE PROJECT:

 The application is made as simple as surfing a website. There by non-technical

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 2

2.1 HARDWARE REQUIREMENT:

Hard disk : 80 GB or more

Monitor : 15CRT or LCD monitor

Keyboard : Normal or Multimedia

Mouse : Compatible mouse

2.2 SOFTWARE REQUIREMENT:

Front End : PHP Script

Back End : MySQL

Browser : Firefox, Chrome, IE or any other

Operating System : Windows Xp/Above

Server : XAMPP Server to host the web-page.

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 3

3.1 FUNCTION REQUIREMENTS:

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 4

3.2 NONFUNCTION REQUIREMENTS:

3.2.1 RELIABILITY REQUIREMENTS:

3.2.2 USABILITY REQUIREMENTS:

3.2.3 SECURITY REQUIREMENTS:

3.2.4 IMPLEMENTATION REQUIREMENTS:

3.2.5 PORTABILITY REQUIREMENT:

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 5

4.1 EXISTING SYSTEM

4.2 LIMITATION ON EXISTING SYSTEM

 more human error.

 more strength and strain of manual labour needed

 Repetition of the same procedures.

 difficult to update data

 Record keeping is difficult

 Backup data can be easily generated

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 6

4.3 PURPOSE OF THE PROJECT

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 7

1. The Administrator can manage all user and complaints.

2. He can access complaint info and change the status of complaints.

3. He can control the status of the complaints.

A process of converting user originated inputs to a computer-based format. Input design is an

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 8

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 9

5.1 USE CASE DIAGRAMS

FIGURE:1 USE CASE DIAGRAM FOR USER

FIGURE:2. USE CASE DIAGRAM FOR ADMIN

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 10

5.2 DATA FLOW DIAGRAM

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 11

5.3 E-R DIAGRAM:

An ER model is typically implemented as a database. In the case of a relational database, which

FIGURE 4: E-R DIAGRAM

1MV16MCA18 Dept. of MCA/Sir MVIT/Bangalore Page 12

6.1 SOURCE CODE:

<p>Copyright © <a