Complaint Management System - A Project on JAVA Standard Edition

Developed By Abhishek Roy Madhurya Datta Gupta Nilanjan Sengupta Subhajit Naskar

Acknowledgement

I take this opportunity to express my deep gratitude and sincerest thank to my project mentor, Amitava Chatterjee for giving most valuable suggestion, helpful guidance and encouragement in the execution of this project work. I will like to give a special mention to my colleagues. Last but not the least I am grateful to all the faculty members of Ardent Computech Pvt. Ltd. or their support.

Index
Overview Current System Limitations of Current System Proposed Solution Process Design Design description Entity Relationship Diagram Use Case Diagram Use of Logger Screen Shots Software Used References Conclusion

Overview

The project is aimed at creating efficient software portal for addressing the grievances of the students/faculty members for various purposes like broken furniture problem in class, microphone issues, projector problems, plumbing in hostels, electricity issues, and other hostel, mess & classroom related problems etc.

Current System

In the current scenario there is very less system operating for the registration of complaints. Presently complaint register process is done through telephone where a complaint is raised by calling the administration. This requires a manual effort and can lead to confusions for the students.

Limitations of the Current System

There is no accountability for the complaints as to when a complaint was raised and when it was resolved. Most of the times students call in the morning or afternoon and at that time there is no one to register the complaint. There is usually a lot of time lag between problem identification and the action taken to resolve it. Some complaints require high priority action which is not possible in the current system.

Proposed Solution
The idea is to automate the entire complaint process from telephonic medium to electronic medium in order to increase efficiency and reduce the response time. There would be basically 5-6 main categories for the selection of complaint type. Then we will also provide the priority based on its severity for a particular complaint/issue. If the severity/priority is high then it would take a time of around 1 hours to 3 hours and if its having less priority then it would have one-two days time. Validation is done for unique user id generation and registration Validation of user id and password is done with user database This would be having a student rules & regulations tab which would consist of all the rules mentioned in student constitution. A unique complaint number would be generated for a particular complaint. User would be able to check the status of his/her complaint. Basically this would be a one stop solution for both students and faculty member to make authority aware of existing issue at a particular time.

Option of registering and signing up is available for first time users.

Return option is provided to cancel the registration process midway.

Process Design

Design Description
The complaint registration and resolution model has the following major modules. Sign Up/Login (for All Users) Module: Sign Up page contain four fields: Verification field is used to check the genuinity of user and other three fields are User ID and Password and Confirm Passwords. Login age is expected to contain two mandatory fields: User ID and Password, along with 3 radio buttons that will indicate whether the user is a Student, Faculty Member or the Administrator.

For Administrator & Other Users:

Complaint Registration Module: This page shall allow the users to create new queries or go to a page that provides the status of an existing query. This page shall contain fields like Department to be notified for the query and the Specific Field pertaining to the query. It shall also allow the user to decide on the priority of the notification. A high priority complaint is expected to be solved in a few hours. Medium priority is expected to get solved within a day whereas a low priority complaint is expected to be resolved in 2-3 days. This is followed by a dialogue box that enables the user to give a detailed description of the exact nature of the complaint. When the user clicks on Submit, he is guided to the next page with a unique Complaint Registration Number (CR No.).

Continued
Complaint Status Check: This page can be reached from Page 2 or Page 3. It has one mandatory field of complaint registration number (CR No.) which, when submitted, provides the information on the status of the query as Under Process or Finished. For Administrator: Complaint Resolution Module: This page shall contain the list of queries along with their priorities and department to be referred to, status as per the department. The queries with finished as the final status are automatically moved to the solved sheet. The administrator can click on the status field of each query except his own complaint. This page shall contain the details about the status of the query like Finished or Pending or Unallocated. The Administrator can change the Present Status of the query. For Master Administrator: Master Mode: There is only one master administrator who generates the verification code for sign up process and has the ultimate power to control the total system. He can manage complaints and has the ability to remove complaints from the database regardless of the complaint status.

Entity Relationship Diagram

Use Case Diagram

Use Case Diagram for User

Use Case Diagram for Administrator

Use of Logger
The purpose of logging is to keep track of the history of a process execution. As the runtime data of a process execution changes, all the deltas are stored in the logs. Software logging traces the execution of a software program (usually for debugging purposes).

Screen Shots

Continued

Software Used

Java SDK Tool (Release 7 Update - 25) Apache Derby Eclipse IDE Apache log4j GIMP

References

http://www.google.co.in/ http://stackoverflow.com/ http://www.coderanch.com/

Conclusion
There are some crucial aspects which were left out due to the short time span of project submission duration. The following features may be added in future for the enrichment of this software. First of all a Management System which consists of multiple Administrators should be available on-line i.e. should be connected via internet for concurrent usage of resources. As we are using JSE platform which is highly unlikely to obtain.

The Derby Database used in the project is not secured up to the per which makes the user data vulnerable to malicious users.
The software lacks inbuilt update management for fixing bugs and adding additional feature in the future. However this is our one of the earliest effort in making such a software in such platform, we hope for future betterment.